Ask HN: ¿Cómo entreno un LLM/ChatGPT personalizado con mis propios documentos en diciembre de 2023?

Discusión en Hacker News ↗

Los desarrolladores que intentan “entrenar” modelos estilo ChatGPT con sus propios documentos descubren cada vez más que el fine-tuning completo rara vez es necesario o rentable; en cambio, la mayoría de las soluciones prácticas se basan en la generación aumentada por recuperación (RAG), donde los datos externos se indexan y se inyectan en los prompts en tiempo de consulta. Los participantes comparan frameworks como LlamaIndex, LangChain, Haystack y varios servicios alojados (AWS Bedrock, Azure AI Studio, OpenAI Assistants, Notion, PrivateGPT, etc.), sopesando facilidad de uso, coste y apertura frente a problemas como los límites de la ventana de contexto, la estrategia de troceado, las alucinaciones y la elección de bases de datos vectoriales. Un tema recurrente es que RAG funciona bien para muchos corpus pequeños y medianos y para casos de uso de búsqueda/chat empresarial, mientras que los conjuntos de datos muy grandes o altamente propietarios pueden requerir con el tiempo enfoques más avanzados como preentrenamiento continuo o RAG híbrido + fine-tuning.

Qué suele significar “entrenar con tus documentos”

  • Muchos comentaristas subrayan que la mayoría de los productos que afirman “entrenar con tus docs” en realidad están haciendo RAG (generación aumentada por recuperación), no un fine-tuning o preentrenamiento واقعی.
  • Flujo de RAG: ingerir documentos → trocear + generar embeddings → almacenar en una base de datos vectorial → en cada consulta, recuperar los fragmentos relevantes → meterlos en el prompt del LLM.
  • Se dice que el fine-tuning real sobre documentos en bruto principalmente enseña estilo y patrones, no recuperación fiable de hechos; si se usa fine-tuning, se recomiendan conjuntos de datos de preguntas y respuestas.
  • Algunos argumentan que RAG es el enfoque general correcto; una minoría llama a RAG “fundamentalmente defectuoso” o apto sobre todo para conjuntos de datos más pequeños.

Soluciones en la nube y gestionadas

  • AWS Bedrock: bases de conocimiento (RAG) más “continuous pre-training”; se considera potente pero caro, especialmente con modelos personalizados y OpenSearch.
  • Alternativas sugeridas: usar pgvector/RDS en lugar de OpenSearch; Pinecone como almacén vectorial más barato.
  • Otras opciones alojadas mencionadas: Amazon Q, Azure AI Studio + Semantic Kernel, OpenAI Assistants API (RAG integrado), Notion Q&A, NotebookLM, constructores estilo Office Copilot, y varias herramientas SaaS.

Stacks de código abierto y locales

  • Frameworks RAG populares: LlamaIndex (muy elogiado), LangChain (criticado por estar sobrecargado/inestable), Haystack, Langroid, txtai, embedchain, Buster.
  • Apps listas para usar/locales: PrivateGPT, h2oGPT, Gpt4All, Verba, anything-llm, Khoj, Cheshire Cat, GPT Researcher, capas seguras de apps RAG.
  • Muchos ejecutan modelos locales vía Ollama, llama.cpp o similares, a menudo usando modelos como Mistral o Mixtral.

Desafíos técnicos discutidos

  • La estrategia de troceado y los metadatos se consideran críticos para la calidad de RAG; los fragmentos fijos de tamaño ingenuo suelen rendir peor.
  • Problemas de escala: con corpus grandes, solo unos pocos fragmentos entran en la ventana de contexto; los modelos de contexto largo ayudan, pero existe la preocupación de “lost in the middle”.
  • Se recomienda la recuperación híbrida (vector + BM25/léxica), especialmente para acrónimos y jerga de dominio.
  • Las alucinaciones siguen sin resolverse; las mejores mitigaciones son prompts estrictos, restricciones de recuperación y evaluación/monitorización.
  • El RAG multilingüe depende de modelos de embeddings multilingües; los errores tipográficos y términos OOV se manejan parcialmente mediante tokenización por subpalabras y similitud de embeddings.

Costes, hardware y practicidad

  • El fine-tuning alojado y los modelos personalizados pueden costar miles por mes, algo que se considera prohibitivo para aficionados.
  • Los modelos estándar + RAG + almacenes vectoriales más baratos se presentan como el camino práctico para la mayoría de los casos de uso.