RAG ou contexto longo: como escolher na empresa

A escolha começa pelo conjunto de documentos necessário

Uma equipe de suporte responde perguntas sobre um catálogo de manuais. Outra compara um contrato com seus anexos para preparar uma revisão. As duas trabalham com documentos, mas precisam selecionar informação de maneiras diferentes.

No suporte, cada pergunta costuma depender de uma pequena parte do acervo. Na revisão, relações entre cláusulas distantes podem ser centrais. Escolher a mesma arquitetura para os dois trabalhos pode excluir evidência importante ou enviar conteúdo desnecessário em toda consulta.

RAG recupera informação externa antes de gerar a resposta. Contexto longo permite entregar um conjunto maior de informação diretamente ao modelo. A decisão prática é quanto material autorizado precisa participar de cada análise, como esse material muda e qual custo a operação consegue sustentar.

Este guia compara as duas rotas para consulta e análise documental. Ajustar o comportamento do modelo por treinamento é outra decisão, tratada em RAG ou fine-tuning.

O que cada abordagem coloca entre a pergunta e a resposta

Em uma arquitetura de RAG, a aplicação identifica a pergunta, aplica permissões, busca documentos ou trechos e monta um pacote de evidências. O modelo responde a partir desse pacote. A recuperação pode usar texto, vetores, filtros ou outras ferramentas. Um banco vetorial não é obrigatório em todo desenho.

Na abordagem de contexto longo, a aplicação seleciona previamente um conjunto delimitado, como um dossiê, e o envia ao modelo com a tarefa. Há menos dependência de uma busca por trechos dentro desse conjunto, embora continue existindo uma decisão sobre quais arquivos entram.

A documentação de contexto longo do Gemini apresenta o uso de grandes conjuntos de informação diretamente na entrada e discute implicações de latência. Capacidades e limites variam por modelo. A existência de espaço para o material não prova que a análise será correta.

Em ambas as rotas, extração ruim, documento vencido e permissão incorreta continuam sendo problemas da aplicação.

Quando começar por contexto longo

Considere essa opção quando o conjunto de trabalho já estiver delimitado e couber na configuração escolhida com espaço para instruções e resposta.

O usuário já sabe quais arquivos precisam ser analisados

Um contrato e seus anexos aprovados formam um pacote conhecido. Criar uma infraestrutura de indexação apenas para uma revisão eventual pode acrescentar manutenção sem benefício suficiente.

A aplicação ainda precisa validar a versão, a integridade dos arquivos e a autorização de quem os enviou. Documento anexado não ganha autoridade automaticamente.

A pergunta exige relações distribuídas pelo material

Comparar obrigações, localizar contradições ou acompanhar uma sequência de acontecimentos pode exigir passagens que uma busca inicial não reconhece como relevantes. Enviar o conjunto integral reduz uma classe de omissão: o trecho existir no dossiê, mas nunca chegar ao modelo por falha de recuperação.

Isso não elimina omissões na resposta. O modelo pode receber toda a evidência e ainda deixar de utilizá-la. Testes devem cobrar cobertura dos pontos obrigatórios, inclusive os que aparecem longe da pergunta principal.

O volume de consultas é limitado

Uma análise eventual aceita uma estrutura econômica diferente de um atendimento que repete consultas ao longo do dia. Avalie tempo e custo por análise aceita, incluindo revisão humana.

Quando o pacote cresce, reveja o desenho. Um protótipo confortável com poucos arquivos pode se tornar lento e caro ao receber anos de histórico.

Quando começar por RAG

RAG tende a ser um candidato melhor quando o universo consultável é amplo e cada pergunta usa uma parcela pequena dele.

O acervo muda com frequência

Manuais, procedimentos e políticas precisam ser encontrados na versão vigente. Uma rotina de ingestão e atualização pode tornar essa seleção repetível, desde que a publicação da fonte realmente atualize o índice.

Cada pessoa acessa uma parte diferente

A recuperação deve respeitar cliente, unidade, função e finalidade. O filtro precisa impedir que material proibido chegue ao modelo ou a componentes intermediários. Um índice compartilhado sem autorização por documento não resolve esse requisito.

As perguntas são recorrentes e localizadas

Se atendentes perguntam sobre prazos, exceções ou procedimentos específicos, recuperar a seção adequada pode evitar o envio do manual inteiro. A busca híbrida para RAG ajuda quando códigos exatos e descrições informais precisam conviver.

A empresa precisa investigar a seleção da fonte

Um fluxo de recuperação instrumentado mostra candidatos, filtros e trechos escolhidos. Essa trilha ajuda a separar falha de busca de falha de interpretação. Preserve também o que foi efetivamente enviado ao gerador, respeitando a política de retenção.

Compare o custo completo, não apenas tokens

Contexto longo pode simplificar a implantação inicial, mas repetir documentos em várias chamadas aumenta o volume processado. Cache pode mudar essa conta, dependendo de elegibilidade, validade e cobrança do provedor. Não assuma economia sem medir chamadas representativas.

RAG acrescenta extração, divisão de documentos, indexação, armazenamento, busca, atualização e testes. Pode reduzir o contexto enviado por pergunta, mas essa redução precisa pagar o esforço de operar a recuperação.

Inclua na comparação:

• preparação e correção dos documentos;
• infraestrutura e chamadas por consulta;
• tempo até a resposta útil;
• revisão humana necessária;
• manutenção após mudança de fonte;
• custo de investigar uma resposta errada;
• frequência de reprocessamento;
• descarte, revogação e atualização dos dados.

A unidade econômica é uma análise aceita dentro do prazo e do escopo. Uma chamada barata que exige refazer a pesquisa não representa economia operacional.

O desenho combinado costuma ser uma alternativa útil

As abordagens podem ser combinadas sem enviar o acervo inteiro nem depender apenas de fragmentos curtos.

Um fluxo possível seleciona documentos autorizados por cliente, projeto e versão. A busca identifica quais arquivos pertencem à pergunta. Depois, a aplicação envia capítulos completos ou um dossiê pequeno para análise em contexto longo.

Essa composição é útil quando a recuperação localiza o objeto correto, mas trechos isolados perdem relações importantes. Ela exige preservar identidade e ordem dos documentos, além de controlar o tamanho final.

Outro desenho permite começar com evidências curtas e ampliar a leitura diante de uma referência ou exceção. Limite rodadas e tempo de investigação. O gerenciamento da janela de contexto organiza esse orçamento durante a execução.

Evite montar uma combinação sofisticada antes de comparar as alternativas simples. Cada etapa adicional deve corrigir uma falha observada.

Faça um teste de escolha com três configurações

Use o mesmo conjunto autorizado de documentos, as mesmas perguntas e critérios de avaliação definidos antes do teste. Mantenha o modelo de resposta igual quando possível para isolar a contribuição da arquitetura.

Compare:

1. Contexto direto: pacote completo do caso, sem recuperação por trechos.
2. RAG: evidências selecionadas por um fluxo de recuperação definido.
3. Combinação: recuperação de documentos seguida de leitura ampliada das unidades relevantes.

Inclua perguntas localizadas, relações entre seções, conflito entre versões, exceção distante da regra, documento ausente e usuário sem acesso. Prepare também perguntas cuja resposta não existe no material.

Para cada caso, marque a evidência obrigatória e a resposta aceitável. Registre se a evidência entrou no contexto, se foi usada corretamente e se a citação sustenta a afirmação. Avaliar apenas a fluência da resposta esconde falhas importantes.

Meça qualidade por classe de pergunta, custo por caso aceito, tempo de resposta, correção humana e falhas de acesso. Mantenha erros críticos separados da média. Uma configuração não deve ganhar por responder melhor às perguntas fáceis e expor um documento restrito.

Como interpretar o resultado

Se RAG falha antes de entregar a evidência, investigue extração, filtros, busca e chunking dos documentos. Trocar o modelo gerador pode não alterar o problema.

Se o contexto direto contém a evidência e a resposta continua incompleta, teste instruções, estrutura do pacote e avaliação por itens obrigatórios. Aumentar a janela novamente pode acrescentar volume sem resolver a utilização.

Se as duas opções atendem à qualidade, compare manutenção e economia no volume esperado. Prefira o desenho mais simples que preserve acesso, prazo e rastreabilidade.

Se nenhuma atende aos erros impeditivos, mantenha revisão especializada ou reduza o escopo. O teste não precisa terminar com uma compra.

Registre a decisão antes de implantar

O aceite deve informar qual tarefa foi validada, quais documentos entram, quem pode consultá-los, quais configurações foram comparadas e quais limites permanecem. Inclua um responsável e um gatilho de reavaliação: crescimento do acervo, mudança relevante no volume, alteração de permissões ou troca de modelo.

A pergunta mais útil para o fornecedor é: “Em quais casos esta arquitetura deixa de ser adequada, e como vamos detectar isso?”. Uma resposta apoiada no seu conjunto de testes vale mais que uma demonstração com documentos escolhidos para funcionar.

A Júpiter trabalha essa decisão a partir do processo e da evidência necessária. O objetivo é reduzir o esforço para chegar a uma resposta verificável, mantendo a empresa capaz de corrigir fontes, investigar erros e mudar a arquitetura quando o trabalho exigir.