Conteúdo da trilha
8 minNarração em inglês, legenda em portuguêsPodcast (RSS)
Capítulos
  1. 0:00Abertura
  2. 1:05A ideia
  3. 1:38Como quebra
  4. 2:46Por que acontece
  5. 3:24Um desafio
  6. 4:11O tratamento
  7. 5:14Quando manter o RAG
  8. 6:26Em produção
  9. 7:04Fechamento
Transcrição

Abertura

Um assistente jurídico responde perguntas sobre um contrato de serviços. Dezoito páginas. Uns doze mil tokens.

O time montou do jeito que os tutoriais ensinam. Quebrar o contrato em pedaços pequenos, virar cada pedaço um embedding, guardar num banco vetorial. A cada pergunta, buscar os quatro pedaços mais parecidos e deixar o modelo responder.

Aí um usuário pergunta. Posso rescindir sem multa se o fornecedor atrasar a entrega? A busca traz a cláusula de rescisão. Não traz a cláusula de multas, que fica em outra página e fala em inadimplemento contratual, não em atraso.

O modelo responde sim, sem multa. A cláusula 14.3 diz o contrário. E aqui está o detalhe que faz disso um smell. O contrato inteiro cabia com folga no contexto do modelo. Nesta aula, você vai aprender a notar quando a busca é uma aposta que você não precisava fazer.

A ideia

O centro da questão é este. A busca acha pedaços parecidos com a pergunta. Ela não acha os pedaços de que você precisa para responder.

Atrasar a entrega soa perto de prazo e rescisão. A cláusula de multas fala em inadimplemento, e no espaço vetorial ela fica longe. Então o modelo responde com um quinto do contrato, e não sabe o que ficou de fora.

Quando o documento inteiro cabe, deixe o modelo que leu tudo decidir o que é relevante. Não uma busca que só leu a pergunta.

Como quebra

Vamos andar pelo pipeline.

Começa com um material pequeno e completo. Um contrato, todas as cláusulas ali.

Depois ele é quebrado. E a quebra separa cláusulas que dependem uma da outra. A regra está na página quatro, a exceção na página onze.

Os pedaços viram vetores e vão para o banco.

A cada pergunta, a busca escolhe alguns. E erra quando as palavras não batem, mesmo quando o sentido bate.

E o modelo responde com uma fração do material, com toda a confiança. Nada no prompt diz a ele que a cláusula 14 existe.

Então, os sinais. O conteúdo total é pequeno, dezenas de páginas, e caberia inteiro na janela de contexto.

Tem chunking, embeddings e banco vetorial para meia dúzia de documentos.

As respostas erradas vêm da busca perdendo o trecho certo. Principalmente perguntas que juntam partes distantes do documento.

E o time gasta mais tempo ajustando tamanho de pedaço do que resolvendo o problema do usuário.

Por que acontece

Ninguém monta isso por descuido. Tem bons motivos.

RAG virou a resposta padrão para IA sobre documentos. É a primeira arquitetura que todo tutorial mostra.

As janelas cresceram. O que precisava de busca há poucos anos hoje cabe inteiro, com sobra.

Foi pensado para uma escala futura. E se forem mil contratos? Talvez sejam. Hoje é um.

E o custo do contexto foi mal calculado. Mandar o documento inteiro em toda pergunta parece caro, até você contar o cache de prompt.

Um desafio

Uma pergunta para você. O assistente erra uma pergunta porque a cláusula de exceção não voltou da busca. Um colega propõe subir de quatro para oito pedaços por pergunta. O contrato inteiro tem 24 pedaços. O que você responde?

Oito pedaços resolve esta pergunta. A próxima pode depender do nono. Você continua apostando que a busca acerta, para um material que já cabia inteiro.

E trocar o modelo de embedding também não resolve. Um embedding melhor aproxima palavras parecidas. Ele não liga uma cláusula a uma exceção que não se parece nada com a pergunta. Com doze mil tokens, mande tudo e meça no eval.

O tratamento

O tratamento é a refatoração da próxima aula. Trocar RAG por contexto direto. Mande o documento inteiro e use cache de prompt para não pagar a leitura cheia em toda pergunta.

Um detalhe decide se o cache funciona. O documento precisa ficar no começo do prompt, igualzinho em toda chamada.

A pergunta vem depois. Se a pergunta vem primeiro, o começo do prompt muda toda vez e o cache nunca acerta.

Um time aprendeu isso do jeito difícil. Trocou para o contrato inteiro, e a conta subiu muito além do esperado. O trace mostrou a pergunta na frente do contrato. A correção não foi voltar para o RAG. Foi mudar uma linha de lugar.

O que você ganha vale a pena. O modelo vê as ligações entre as cláusulas. Não tem chunking, nem índice, nem busca para ajustar. E as citações ficam mais precisas, porque o modelo vê cada cláusula com número e página.

Quando manter o RAG

Agora o outro lado. Isso não é uma regra contra RAG.

Se o material não cabe, ou cresce rápido, você precisa de busca. Uma base de quatro mil artigos que muda toda semana, com busca híbrida, não é este smell. Ali, a busca se paga.

O controle de acesso é o caso sutil. Um manual de RH de trinta páginas cabe fácil. Mas se cada funcionário só pode ver a seção do próprio cargo, mandar tudo mostra ao modelo seções que essa pessoa não pode ver. Busca filtrada, ou um contexto montado por cargo no código, é como você garante a permissão.

E se o cache não se aplica ao seu tráfego, e o volume de perguntas é muito alto, calcule o custo por pergunta antes de decidir.

E o erro comum também vai no sentido contrário. Um manual de quarenta páginas, perguntas sobre seções isoladas, busca quase sempre certa, custo baixo. Material pequeno, sozinho, não é motivo para refazer. Rode as duas versões no eval. Se o contexto direto acerta mais pelo mesmo custo, troque. Se empatar, fique com a que é mais simples de manter.

Em produção

O que observar. No eval, marque cada resposta errada pela causa. O trecho certo estava no prompt ou não? Se a maioria dos erros é trecho que nunca chegou, é este smell, em números.

Mantenha um conjunto de perguntas que precisam de duas seções distantes, como a regra e a exceção. São essas que o chunking quebra primeiro.

E depois da troca, olhe a taxa de acerto do cache no trace. Uma taxa perto de zero quer dizer que algo no começo do prompt está mudando. Uma data, o nome do usuário, ou a pergunta no lugar errado.

Fechamento

Então, a ideia para levar. Busca é uma aposta de que ela vai achar o que a resposta precisa. Quando o documento cabe na janela, você não precisa fazer essa aposta. Dê ao modelo o documento inteiro e deixe ele decidir o que importa.

Na próxima aula, a gente faz a refatoração passo a passo, com segurança e o cache no lugar certo: trocar RAG por contexto direto. Até lá.

SmellDispensáveis

RAG Desnecessário

RAG for Small Data

RAG Desnecessário (RAG for Small Data) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Dispensáveis. Um pipeline de busca vetorial para 20 páginas que cabem inteiras no contexto.

Elemento
21/37
Nível
Iniciante
Leitura
5 min
Atualizado
Nesta página 7
  1. 01Como reconhecer
  2. 02Por que acontece
  3. 03Quanto custa ignorar
  4. 04Tratamento
  5. 05O que você ganha
  6. 06Quando ignorar
  7. 07É esse smell?
  8. ··Perguntas rápidas

Como reconhecer

Um assistente jurídico responde perguntas sobre um contrato de prestação de serviços de 18 páginas. A arquitetura (anonimizada):

contrato.pdf (18 páginas, ~12 mil tokens)
  -> quebrado em pedaços de 500 tokens
  -> embeddings num banco vetorial
pergunta -> busca os 4 pedaços mais parecidos -> modelo responde

Pergunta: “Posso rescindir sem multa se o fornecedor atrasar a entrega?”. A busca trouxe a cláusula de rescisão, mas não a de penalidades, que ficava em outra página e falava de “inadimplemento” em vez de “atraso”. O modelo respondeu “sim, sem multa”. A cláusula 14.3 dizia o contrário.

O contrato inteiro cabia no contexto do modelo com folga. Quatro pedaços de 500 tokens são 2 mil dos 12 mil: o modelo respondeu olhando para um sexto do documento, sem saber disso.

Sinais de RAG Desnecessário:

  • O conteúdo total é pequeno (dezenas de páginas) e caberia inteiro na janela de contexto.
  • O pipeline tem chunking, embeddings e banco vetorial para poucos documentos.
  • Respostas erradas acontecem porque a busca não trouxe o trecho certo.
  • Perguntas que exigem juntar partes distantes do documento falham.
  • O time passa mais tempo ajustando chunking que resolvendo o problema do usuário.
flowchart LR
  D(["1. Contrato de 18 páginas"]):::io --> C["2. Cortar em pedaços"]:::tool
  C --> V[("3. Banco vetorial")]:::store
  Q(["Pergunta"]):::io --> S["4. Buscar 4 pedaços"]:::tool
  V --> S
  S --> M(["5. Modelo vê um sexto do contrato"]):::llm
  1. O material é pequeno e completo.
  2. Ele é cortado, e o corte separa cláusulas que dependem umas das outras.
  3. Os pedaços viram vetores.
  4. A busca escolhe alguns, e erra quando as palavras não batem.
  5. O modelo responde com uma fração do material, sem saber o que ficou de fora.

Por que a busca perdeu a cláusula

A busca vetorial acha pedaços parecidos com a pergunta. Ela não acha pedaços necessários para responder. “Atrasar a entrega” é parecido com a cláusula de prazos e de rescisão. A cláusula de penalidades fala de “inadimplemento contratual”, e fica longe na distância entre vetores.

Contratos são cheios disso: uma cláusula define um termo, outra aplica, uma terceira abre exceção. Responder certo exige ler as três juntas. Quando o documento inteiro cabe no contexto, quem decide o que é relevante é o modelo, que leu tudo, e não a busca, que leu só a pergunta.

Checagem +20 XP de primeiraO assistente jurídico erra uma pergunta porque a cláusula de exceção não veio na busca. Um colega propõe subir de 4 para 8 pedaços por pergunta. O contrato tem 24 pedaços no total. O que você diz?

Por que acontece

  • RAG virou o padrão para “IA sobre documentos”. É a primeira arquitetura que aparece em tutoriais, e o time já sai montando o banco vetorial.
  • Janelas de contexto cresceram. O que exigia busca há alguns anos hoje cabe inteiro, com espaço de sobra.
  • Projeto pensado para escala futura. “E se forem mil contratos?” Talvez sejam; hoje é um.
  • Custo de contexto mal estimado. Mandar o documento inteiro parece caro, sem contar o cache de prompt.

A própria Anthropic, no post em que apresentou o Contextual Retrieval (setembro de 2024), recomenda o caminho simples: se a base tem menos de 200 mil tokens (cerca de 500 páginas), inclua tudo no prompt e use cache, sem busca.

Quanto custa ignorar

  • Respostas erradas quando a busca perde o trecho relevante, principalmente em perguntas que cruzam seções. Num assistente jurídico, “sim, sem multa” errado vira prejuízo real.
  • Complexidade sem retorno. Chunking, embeddings, índice e reordenação para manter. Cada peça tem parâmetros, versões e jeitos próprios de falhar.
  • Confiança baixa. O usuário não sabe se a resposta considerou o documento inteiro. Nem o time sabe.
  • Atualização frágil. Quando sai um aditivo ao contrato, alguém precisa reindexar. Se esquecer, o assistente responde com a versão antiga.

Tratamento

Refatoração Escolha quando
Trocar RAG por Contexto Direto O material cabe na janela com folga. Mande o documento inteiro e use cache de prompt para não pagar a leitura a cada pergunta. Para ligar o cache, veja Introduzir Cache.

Faça a conta antes de decidir

O medo de mandar tudo é o custo. Faça a conta com o seu caso. Exemplo com o contrato de 12 mil tokens e uma sessão de 30 perguntas:

Tokens de entrada lidos Observação
Contexto direto sem cache 360 mil 12 mil vezes 30 perguntas
Contexto direto com cache 12 mil escritos, 348 mil lidos do cache A leitura de cache custa uma fração do preço normal
RAG com 4 pedaços 60 mil, mais embeddings e infraestrutura Mais barato por chamada, e erra a cláusula 14.3

Na Anthropic, por exemplo, ler do cache custa 10% do preço normal de entrada, e escrever no cache custa um pouco mais que o preço normal. Com essas proporções, as 30 perguntas com cache custam em entrada algo perto de 50 mil tokens a preço cheio. Confira a tabela do seu provedor, porque proporções e tempo de expiração do cache mudam de um para outro.

Para o cache funcionar, o documento precisa estar no começo do prompt, igual em toda chamada. A pergunta vem depois.

A armadilha do outro extremo

Contexto direto não é “jogue tudo e esqueça”. O paper “Lost in the Middle” (Liu et al., 2023) mostrou que modelos usam pior a informação no meio de contextos longos do que no começo e no fim. Modelos mais novos melhoraram nisso, mas o efeito vale ser medido no seu eval.

Duas práticas ajudam: mantenha a estrutura do documento (números de cláusula, títulos de seção) e peça que a resposta cite a cláusula usada. Uma citação errada aparece rápido na revisão.

Checagem +20 XP de primeiraO time trocou o RAG pelo contrato inteiro no prompt. A conta subiu bem mais do que o previsto. O trace mostra que a pergunta do usuário vem antes do contrato no prompt. Qual é o diagnóstico?

O que você ganha

  • O modelo vê o documento inteiro, inclusive as relações entre cláusulas.
  • Menos peças: sem chunking, sem índice, sem ajuste de busca.
  • Com cache de prompt, custo e latência por pergunta baixos depois da primeira.
  • Citações mais precisas, porque o modelo vê a página e a cláusula de cada trecho.
  • Atualizar o material é trocar um arquivo, sem reindexar.

Quando ignorar

  • O material não cabe ou cresce rápido. Milhares de documentos, ou uma base que muda todo dia, precisam de busca. Veja RAG e, para melhorar a busca, Chunking Contextual.
  • Controle de acesso por trecho. Se cada usuário só pode ver partes do material, a busca com filtro é a forma de aplicar a permissão.
  • Volume muito alto de perguntas sem cache. Se o cache não se aplica ao seu caso, faça a conta do custo por pergunta antes de decidir.

É esse smell?

Checagem +20 XP de primeiraUma base de conhecimento tem 4 mil artigos e cresce toda semana. O time usa RAG com busca híbrida. É RAG Desnecessário?

Checagem +20 XP de primeiraUm assistente responde sobre um manual de 40 páginas. As perguntas são sobre seções isoladas, e a busca acerta quase sempre. O custo por pergunta é baixo. Vale trocar?

Checagem +20 XP de primeiraO sistema manda o contrato inteiro em toda pergunta, sem cache, e cada usuário faz em média 30 perguntas por sessão. Qual é o ajuste?

Checagem +20 XP de primeiraUm app de RH responde sobre o regulamento interno de 30 páginas. Cada funcionário só pode ver a seção do próprio cargo. É RAG Desnecessário?

Perguntas rápidas

O que é RAG Desnecessário?

RAG Desnecessário (RAG for Small Data) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Dispensáveis. Um pipeline de busca vetorial para 20 páginas que cabem inteiras no contexto.

Como corrigir RAG Desnecessário?

Com Trocar RAG por Contexto Direto. Cada refatoração traz o passo a passo seguro, com eval antes e depois.

Onde RAG Desnecessário aparece na prática?

Nos cenários reais Assistente jurídico.

Para ir além

Relações

Refatorações que tratam 1
Aparece nos cenários 1
Aparece nas trilhas 1
Buscar