Desafios

RAG Explicado para Founders: Como Dar Contexto Empresarial a um LLM

Por Marc Molas·16 de novembro de 2024·10 min de leitura

Você testou o ChatGPT para o seu negócio. É impressionante — até você perguntar sobre SEUS clientes, SEUS produtos, SEUS processos internos. Aí ele começa a inventar. Nomes falsos, dados que não existem, políticas que você nunca teve. Ele alucina porque não tem seus dados.

Não é um bug. É uma limitação fundamental. GPT-4o, Claude 3.5, Llama 3.1 — todos os LLMs têm conhecimento geral enorme mas zero conhecimento da sua empresa. Não sabem quem são seus clientes, o que diz sua documentação interna nem quais são suas políticas de devolução.

A boa notícia: existe uma solução que não exige retreinar nenhum modelo. Chama-se RAG. E provavelmente é a técnica de IA mais relevante para sua startup neste momento.

O problema: um LLM generalista não conhece seu negócio

Pense num LLM como um funcionário extremamente inteligente que sabe de tudo um pouco mas que acabou de chegar na sua empresa. Sabe programar, escrever, analisar dados — mas não tem acesso à sua wiki interna, seu CRM, seus contratos nem sua base de conhecimento.

Se você perguntar "qual é nossa política de reembolso para clientes enterprise?", ele vai inventar uma resposta que soa plausível. Não porque é desonesto, mas porque não tem outra opção. Preenche as lacunas com probabilidades, não com fatos.

Fine-tuning (retreinar o modelo com seus dados) soa como a solução óbvia, mas tem problemas sérios: é caro, exige experiência especializada, os dados ficam desatualizados rápido e você precisa repetir o processo cada vez que sua informação muda.

É aqui que entra o RAG.

O que é RAG e por que importa

RAG (Retrieval-Augmented Generation) é uma técnica que dá ao LLM acesso aos seus documentos no momento de responder uma pergunta. Você não retreina o modelo. Em vez disso, passa a informação relevante como contexto junto com a pergunta do usuário.

É como dar a esse funcionário novo acesso ao arquivo da empresa antes de responder cada pergunta. O modelo continua o mesmo, mas agora tem dados reais para trabalhar.

O conceito é simples. A implementação tem nuances, mas não é ciência de foguete. Qualquer equipe de engenharia sênior consegue construir um sistema RAG funcional em semanas.

Como funciona o RAG: os 3 passos

Passo 1: Indexe seus dados

Pegue os documentos que quer que o LLM possa consultar: PDFs, wikis, bancos de dados, emails, documentação técnica, tickets de suporte. O que for relevante.

Cada documento é dividido em chunks (fragmentos). Um chunk pode ser um parágrafo, uma seção, uma página — depende do seu caso de uso. Depois, cada chunk é convertido num embedding: uma representação numérica (um vetor) que captura o significado semântico do texto.

Você não precisa entender a matemática por trás dos embeddings. O importante é que dois textos com significado similar terão embeddings próximos. "Política de devolução para clientes premium" e "reembolso para contas enterprise" terão vetores parecidos, mesmo usando palavras diferentes.

Passo 2: Armazene os embeddings

Esses vetores são guardados numa base de dados vetorial. As opções mais comuns:

Pinecone: managed, fácil de começar, escala bem.
Weaviate: open source, muito flexível.
Qdrant: open source, excelente desempenho.
pgvector: extensão do PostgreSQL. Se já usa Postgres, pode começar sem adicionar infraestrutura nova.

Para a maioria das startups, pgvector é a opção mais pragmática. Você já tem PostgreSQL. Adicionar uma extensão é muito mais simples do que gerenciar um banco de dados novo.

Passo 3: Consulte em tempo real

Quando um usuário faz uma pergunta:

A pergunta é convertida num embedding (mesmo processo dos documentos).
São buscados os chunks mais similares na base de dados vetorial — os fragmentos dos seus documentos cujo significado é mais próximo da pergunta.
Esses chunks são injetados no prompt do LLM como contexto: "Com base nas seguintes informações, responda a pergunta do usuário: [chunks relevantes]".
O LLM gera uma resposta usando SEUS dados, não seu conhecimento geral.

O resultado: respostas fundamentadas em informação real da sua empresa. Sem alucinações. Sem invenções.

Quando faz sentido implementar RAG

RAG não é a solução para tudo, mas é a solução certa para muitos casos de uso comuns em startups:

Knowledge bases internas: funcionários que consultam documentação, processos, políticas.
Chatbots de suporte ao cliente: respostas baseadas na sua documentação real, não no conhecimento geral do modelo.
Busca em documentos: encontrar informação relevante em milhares de documentos jurídicos, técnicos ou financeiros.
Consultas de compliance: responder perguntas regulatórias usando sua documentação de conformidade normativa.
Sales enablement: dar à sua equipe comercial respostas precisas sobre produtos, preços e comparativos com concorrentes.

O padrão comum: você tem um corpus de documentos que seus usuários (internos ou externos) precisam consultar, e quer uma interface conversacional que dê respostas precisas.

Quando RAG NÃO é suficiente

Há limites. É importante conhecê-los antes de começar:

Quando você precisa que o modelo aprenda padrões novos. RAG dá contexto, não aprendizado. Se precisa que o modelo classifique tickets de suporte segundo categorias específicas da sua empresa, pode ser que precise de fine-tuning.
Quando os dados mudam em tempo real. RAG funciona bem com documentos que são atualizados periodicamente (diária ou semanalmente). Se precisa de dados ao segundo — cotações de bolsa, estoque em tempo real — precisa de um pipeline de streaming, não só RAG.
Quando a precisão precisa ser de 100%. RAG melhora enormemente a precisão, mas não a garante em 100%. Para decisões médicas, jurídicas vinculantes ou financeiras de alto risco, é necessária validação humana no loop.

Erros comuns que você deve evitar

Já vi esses erros se repetirem em quase todas as equipes que implementam RAG pela primeira vez:

Chunks grandes demais. Se cada chunk é um documento inteiro de 20 páginas, você está injetando muito ruído no prompt. O LLM recebe informação irrelevante demais e a resposta perde qualidade. Chunks de 200-500 tokens costumam ser um bom ponto de partida.

Chunks pequenos demais. O extremo oposto: fragmentos de uma única frase perdem contexto. Se um chunk diz "o limite é 30 dias" mas não diz "para reembolsos de clientes enterprise", a resposta será incompleta. Você precisa de equilíbrio entre especificidade e contexto.

Não ter um pipeline de avaliação. Você implementa RAG, "funciona", e coloca em produção. Mas como sabe se realmente está encontrando os documentos corretos? Como mede se as respostas são precisas? Você precisa de métricas: relevance score, faithfulness, answer correctness. Sem avaliação, está voando às cegas.

Não filtrar por relevância. Às vezes a base de dados vetorial retorna os chunks "mais similares", mas nenhum é realmente relevante. Se o score de similaridade é baixo, é melhor que o sistema diga "não tenho informação sobre isso" em vez de forçar uma resposta com dados tangencialmente relacionados.

Confiar que o LLM dirá "não sei". Os LLMs são extremamente ruins em dizer "não sei". Mesmo com contexto RAG, se a resposta não está nos documentos, muitos modelos tentarão responder mesmo assim. Você precisa de guardrails explícitos no seu sistema para lidar com esses casos.

Build vs buy: a decisão prática

Você tem dois caminhos:

Frameworks existentes: LangChain e LlamaIndex são os mais populares. Dão componentes pré-construídos para chunking, embedding, retrieval e geração. Aceleram o desenvolvimento inicial, mas adicionam dependências e às vezes abstração desnecessária.

Pipeline custom: você constrói cada componente separadamente. Mais trabalho inicial, mas controle total. Para casos de uso simples (um chatbot sobre sua documentação), um pipeline custom com pgvector e a API da OpenAI ou Anthropic pode ser mais simples do que um framework.

Minha recomendação: comece com um pipeline simples e custom. Se a complexidade crescer (múltiplas fontes de dados, re-ranking avançado, hybrid search), aí avalie um framework. Não comece pela solução mais complexa.

Quem deveria construir seu sistema RAG

RAG é conceitualmente simples mas os detalhes de implementação importam muito. Chunking strategy, embedding model selection, retrieval tuning, prompt engineering, avaliação — cada decisão afeta a qualidade do resultado final.

Você não precisa de uma equipe de pesquisadores de IA. Precisa de engenheiros seniores que já construíram sistemas RAG em produção e sabem onde estão as armadilhas. Que já iteraram sobre estratégias de chunking, testaram diferentes modelos de embedding e construíram pipelines de avaliação reais.

Na Conectia, os engenheiros que validamos para projetos de IA já trabalharam com implementações reais de RAG — não em demos ou tutoriais. Sabem a diferença entre um protótipo que funciona num notebook e um sistema que funciona em produção com dados reais, em escala e com usuários que fazem perguntas que não estavam no plano original.

Se você está avaliando RAG para seu produto, a diferença entre um bom resultado e uma má experiência de usuário está na experiência da equipe que o constrói. Um engenheiro sênior com experiência em RAG pode economizar meses de iteração e erros que alguém já cometeu antes.

Quer implementar RAG no seu produto mas não tem equipe com experiência em produção? Fale com um CTO — conectamos você com engenheiros seniores que já construíram sistemas RAG reais, prontos para se integrarem em 72 horas.