O que é RAG e por que é necessário?

Ganhos:

• Explicando que o RAG injeta contexto sem alterar os pesos do modelo e funciona com uma lógica de ‘exame de livro aberto’
• Comparando RAG com abordagens de ajuste fino e contexto longo de acordo com custo, oportunidade e cenário de uso
• Listando as etapas de um pipeline RAG típico que consiste em fases de indexação e consulta

Não importa quão poderoso seja um modelo de linguagem (inteligência artificial que entende e produz texto; vamos chamá-lo de modelo de agora em diante), ele não conhece o contrato que sua empresa assinou ontem, sua página wiki interna (base de conhecimento interna) ou a nota de lançamento publicada esta manhã. O modelo limita-se ao conhecimento geral até a data do treinamento; Isso é chamado de “data limite para a educação”. O RAG (Retrieval-Augmented Generation) preenche exatamente essa lacuna: encontra os documentos da empresa relacionados à questão, dá-os ao modelo como contexto (ou seja, o texto adicional que irá ler ao produzir a resposta) e tem a resposta produzida com base neste contexto.

Nesta unidade, veremos claramente o que é RAG, quando é preferível a quais alternativas e as etapas de um pipeline RAG típico. Todas as unidades subsequentes irão aprofundar as partes deste mapa, uma por uma.

A ideia básica do RAG: exame de livro aberto

Vamos explicar o RAG em uma frase: "Primeiro encontre o documento relevante, depois peça ao modelo que leia esse documento e imprima a resposta de acordo."

A analogia mais útil é esta: RAG move o modelo de um “exame de consulta fechada” para um “exame de consulta aberta”. Na prova presencial o aluno responde apenas de memória; Existe um grande risco de inventar o que você não lembra. Na prova sem consulta, o aluno responde olhando a fonte colocada à sua frente. No RAG, o modelo não responde mais pela própria memória, mas pelo texto atual e específico que você lhe fornece.

Ponto crítico: o RAG não altera os pesos do modelo, ou seja, os bilhões de parâmetros numéricos que o modelo aprendeu. Você não treina novamente o modelo. Para cada pergunta, você injeta pedaços de texto relevantes para aquela pergunta no prompt (texto de instrução enviado ao modelo). Assim, você não precisa treinar novamente o modelo quando um documento for atualizado; você simplesmente atualiza o registro relevante no banco de dados de pesquisa.

Dica: Duas questões determinam a qualidade do RAG: (1) Você encontrou o documento certo? (2) O modelo leu corretamente? O primeiro é “qualidade de recuperação”, o segundo é “qualidade de geração”. Os dois são medidos e melhorados separadamente.

RAG, ajuste fino ou contexto longo?

Três caminhos são frequentemente confundidos quando se procura uma solução para um problema organizacional. Vamos esclarecer suas diferenças. O ajuste fino é atualizar os pesos do modelo com seus dados e ensinar-lhe um novo comportamento/estilo. Contexto longo significa preencher todos os documentos diretamente no prompt, sem qualquer seleção.

Abordagem

O que faz

Quando é apropriado?

Custo/Risco

pano

Injeta o documento relevante como contexto

Informações frequentemente alteradas, extensas e específicas

Baixo; fácil de atualizar, a fonte pode ser citada

Ajuste fino

Atualiza pesos com novos dados

Estilo/formato/ensino de idiomas fixos

Alto; Retreinamento necessário a cada atualização

Somente contexto longo

Preenche todos os documentos no prompt

Conjunto de documentos pequeno e fixo

O custo do token e o risco de “perder a parte intermediária” aumentam

Via de regra: o ajuste fino ensina o modelo a falar; RAG diz ao modelo o que saber. Na maioria dos cenários empresariais, o RAG é testado primeiro porque é barato, atualizável e pode mostrar a fonte da resposta. O contexto longo é razoável se o conjunto de documentos for realmente pequeno e fixo (por exemplo, um único manual de 20 páginas); Mas com milhares de páginas é caro e o modelo pode perder informações no meio de um texto longo.

Um pipeline RAG típico

O RAG consiste em duas fases principais: indexação (preparação, feita uma vez ou periodicamente) e consulta (executada em cada pergunta do usuário).

Indexação passo a passo (offline, sem espera do usuário):

1. Coletar: extraia documentos de fontes (PDF, wiki, sistema de tickets, banco de dados, email).
2. Chunking: divida o texto longo em pedaços menores e gerenciáveis.
3. Incorporar: Converta cada parte em incorporação (o vetor numérico que carrega o significado do texto).
4. Salvar: Grave os vetores junto com o texto e os metadados (fonte, data, informações de autorização) no banco de dados de vetores.

Consulta passo a passo (online, enquanto o usuário espera):

1. Converta a pergunta do usuário em incorporação.
2. Recupere as partes mais semelhantes do banco de dados vetorial.
3. Coloque essas peças + pergunta em um modelo de prompt.
4. Obtenha a resposta contextual e suas fontes do modelo.

# Esboço conceitual da fase de consulta (não dependente do idioma)question = "Quantos dias de férias anuais?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # most similar partsprompt = f"""Responda à PERGUNTA usando o CONTEXTO abaixo. Se a resposta não estiver no contexto, diga "Não tenho informações sobre isso." Adequação.CONTEXTO:{partes}PERGUNTA: {question}"""resposta = model.uret(prompt) # por exemplo. modelo: claude-opus-4-8

Este fluxo é um mapa de cada etapa, que iremos descompactar um por um nas unidades subsequentes.

Alerta Fraco/Prompt Forte

Mesmo com o mesmo contexto RAG, a qualidade do prompt altera a resposta.

Prompt fraco (aberto para ajuste de modelo, não requer recursos):

Use estas informações e diga férias anuais: {partes}. Pergunta: {pergunta}

Prompt poderoso (aterramento + permissão "Não sei" + solicitação de recurso):

Responda apenas com base no CONTEXTO abaixo. Se não houver uma resposta clara no contexto, escreva “Não consegui encontrar informações sobre isso na documentação”; Não adivinhe. Adicione a tag [Source: file_name] da peça em que você está confiando no final de sua resposta. CONTEXTO: {peças} PERGUNTA: {pergunta}

Três Mini Estojos

Caso 1 — Assistente de RH (Recursos Humanos). Uma empresa possui um manual de RH de 340 páginas e os funcionários fazem em média 90 perguntas por dia. Tentaram-se ajustes finos, mas como o manual era atualizado mensalmente, era necessário um novo treinamento a cada vez; O custo chegou a milhares de dólares por mês. Após a mudança para RAG, a atualização foi reduzida para a etapa “reindexar o documento” (minutos) e a taxa de acertos aumentou de 71% para 93% na medição manual.

Caso 2 — Suporte ao cliente. A equipe de suporte possui 12.000 tickets resolvidos e 800 artigos de ajuda. Um representante leva em média 4 minutos para encontrar uma resposta manualmente. Quando o assistente do RAG trouxe os 5 registros mais relevantes e produziu um rascunho de resposta, o tempo foi reduzido para 40 segundos; Mas a equipe percebeu o risco de “parecer insegura ao trazer o artigo errado” e tornou obrigatória a citação da fonte.

Caso 3 — Direito. Uma equipe contratante perguntou “em quais contratos a cláusula de confidencialidade dura 5 anos?” ele faz a pergunta. No longo contexto de teste, 60 contratos foram preenchidos em um único prompt; o modelo pulou os dois contratos intermediários. Quando apenas os itens relevantes foram introduzidos com RAG, o custo do token diminuiu em 80% e o salto ausente foi redefinido.

Por que o RAG é necessário?

• Atualidade: você acessa as informações após a data limite do treinamento.
• Informações especiais: Seus documentos internos não estão incluídos no treinamento de nenhum modelo; Só você pode dar.
• Verificabilidade: Você pode citar a fonte da resposta (citação) — essencial para auditoria e confiança.
• Controle de alucinações: Baseia-se no texto colocado à sua frente, em vez de constituir um modelo.
• Custo: É muito mais barato e rápido de colocar em operação do que o ajuste fino.

Cuidado: RAG não é mágico. Se você trouxer a peça errada, o modelo chegará à resposta errada parecendo “confiante”. Tenha em mente a frase “Qualidade de recuperação = qualidade RAG”.

Erros comuns

• Confundindo RAG com ajuste fino: RAG não altera os pesos; Apenas adiciona contexto. Confundir esses dois levará à escolha da arquitetura errada.
• Não permitir "Não sei": Se o prompt deixar o modelo livre para preencher o espaço em branco, ele fará as pazes.
• Não citar fontes: Uma resposta sem fonte não pode ser verificada; O usuário não consegue perceber o erro.
• Reunir tudo em um único prompt: contexto longo parece barato, mas é caro e perde as informações intermediárias.
• Ficar preso na geração sem medir a recuperação: Se a resposta for ruim, pergunte primeiro "Chegou a parte certa?" deveria ser perguntado.

Em resumo

• RAG é uma abordagem que injeta documentos relevantes para a questão no modelo como contexto; não altera os pesos (“exame de consulta aberta”).
• O ajuste fino ensina estilo/formato, RAG fornece informações atuais e específicas; contexto longo funciona bem para pequenos conjuntos fixos. Na maioria dos cenários, o RAG é tentado primeiro.
• O pipeline tem duas fases: indexação offline (pedaço + incorporação + salvamento) e consulta online (recuperação + prompt + geração).
• O RAG fornece pontualidade, informações específicas, verificabilidade, controle de alucinações e baixo custo.
• A qualidade do sistema depende diretamente da qualidade da recuperação: peça errada significa resposta errada.

Tarefa de aplicativo

Escolha uma fonte genuína de informações de sua própria equipe (por exemplo, um documento de procedimento ou uma página de perguntas frequentes). (1) Escreva 5 questões factuais sobre esta fonte. (2) Observe qual parte do documento contém a resposta correta para cada pergunta – esta se torna sua lista de “respostas de ouro”. (3) Usando o modelo de "prompt forte" acima, cole manualmente a seção relevante como contexto e pergunte a um modelo. (4) Compare a resposta dada pelo modelo com a resposta dourada e marque como verdadeiro/falso. Esta é a primeira versão manual da avaliação que você automatizará em unidades futuras.

lista de verificação

• [ ] Posso explicar em uma frase que o RAG não altera os pesos, apenas adiciona contexto.
• [ ] Consigo distinguir entre RAG, ajuste fino e contexto longo e quando é apropriado.
• [] Posso contar as fases de indexação (coletar-destruir-incorporar-salvar) e de consulta (incorporar-buscar-prompt-gerar) em ordem.
• [] Eu sei por que adicionei as instruções "se não estiver no contexto, diga que não sei" e "cite a fonte" ao prompt.
• [] Posso adaptar o princípio de "Qualidade de recuperação = qualidade RAG" ao meu próprio caso.