Ask HN: Como faço para treinar um LLM/ChatGPT personalizado nos meus próprios documentos em dez de 2023?
Desenvolvedores que tentam “treinar” modelos no estilo ChatGPT com seus próprios documentos cada vez mais descobrem que o fine-tuning completo raramente é necessário ou custo-efetivo; em vez disso, a maioria das soluções práticas depende de retrieval-augmented generation (RAG), em que dados externos são indexados e injetados nos prompts no momento da consulta. Os participantes comparam frameworks como LlamaIndex, LangChain, Haystack e vários serviços hospedados (AWS Bedrock, Azure AI Studio, OpenAI Assistants, Notion, PrivateGPT etc.), equilibrando facilidade de uso, custo e abertura com questões como limites da janela de contexto, estratégia de chunking, alucinações e escolhas de banco vetorial. Um tema recorrente é que RAG funciona bem para muitos corpora pequenos a médios e para casos de uso de busca/conversa corporativa, enquanto conjuntos de dados muito grandes ou altamente proprietários podem eventualmente precisar de abordagens mais avançadas, como pretraining contínuo ou RAG híbrido + fine-tuning.
O que “treinar nos seus documentos” normalmente significa
- Muitos comentadores enfatizam que a maioria dos produtos que dizem “treinar nos seus docs” na verdade está fazendo RAG (retrieval‑augmented generation), não fine-tuning verdadeiro nem pre-training.
- Fluxo de RAG: ingerir documentos → dividir em chunks + gerar embeddings → armazenar em um banco vetorial → em cada consulta, recuperar chunks relevantes → inserir no prompt do LLM.
- Diz-se que o fine-tuning verdadeiro em documentos brutos sozinho ensina principalmente estilo/padrões, e não uma recordação factual confiável; se fine-tuning for usado, recomenda-se datasets no estilo pergunta e resposta.
- Alguns argumentam que RAG é a abordagem geral correta; uma minoria chama RAG de “fundamentalmente falho” ou adequado principalmente para conjuntos de dados menores.
Soluções em nuvem e gerenciadas
- AWS Bedrock: knowledge bases (RAG) mais “continuous pre-training”; visto como poderoso, mas caro, especialmente modelos personalizados e OpenSearch.
- Alternativas sugeridas: usar pgvector/RDS em vez de OpenSearch; Pinecone como armazenamento vetorial mais barato.
- Outras opções hospedadas mencionadas: Amazon Q, Azure AI Studio + Semantic Kernel, OpenAI Assistants API (RAG embutido), Notion Q&A, NotebookLM, construtores no estilo Office Copilot, várias ferramentas SaaS.
Stacks open-source e locais
- Frameworks de RAG populares: LlamaIndex (amplamente elogiado), LangChain (criticado por ser inchado/instável), Haystack, Langroid, txtai, embedchain, Buster.
- Apps turnkey/locais: PrivateGPT, h2oGPT, Gpt4All, Verba, anything-llm, Khoj, Cheshire Cat, GPT Researcher, camadas seguras de apps RAG.
- Muitos rodam modelos locais via Ollama, llama.cpp ou similares, frequentemente usando modelos como Mistral ou Mixtral.
Desafios técnicos discutidos
- Estratégia de chunking e metadata são vistas como críticas para a qualidade do RAG; chunks fixos ingênuos muitas vezes têm desempenho inferior.
- Problemas de escala: com corpora grandes, apenas alguns chunks entram na janela de contexto; modelos de longo contexto ajudam, mas há preocupações de “lost in the middle”.
- Recuperação híbrida (vetorial + BM25/lexical) é recomendada, especialmente para acrônimos e jargão de domínio.
- Alucinações continuam sem solução; as melhores mitigações são prompts rígidos, restrições de recuperação e avaliação/monitoramento.
- RAG multilíngue depende de modelos de embedding multilíngues; erros de digitação/termos OOV são parcialmente tratados por tokenização em subpalavras e similaridade de embeddings.
Custos, hardware e praticidade
- Fine-tuning hospedado e modelos personalizados podem custar milhares por mês, o que é visto como proibitivo para hobbyistas.
- Modelos prontos + RAG + armazenamento vetorial mais barato são apresentados como o caminho pragmático para a maioria dos casos de uso.