Contexto longo ou RAG: escolhendo a arquitetura certa para IA em sistemas B2B

Contexto longo ou RAG: escolhendo a arquitetura certa para IA em sistemas B2B

A introdução de modelos de linguagem com janelas de contexto cada vez maiores criou uma falsa impressão de que a recuperação de informação (RAG) se tornou desnecessária. Em sistemas B2B, a decisão entre carregar todos os documentos no prompt ou buscar apenas os trechos relevantes depende de requisitos operacionais, não apenas da capacidade técnica do modelo.

O que muda em cada abordagem

No uso de contexto longo, você envia documentos inteiros — contratos, manuais, históricos de tickets — diretamente na chamada ao modelo. O modelo precisa processar todos os tokens de entrada para gerar a resposta. Isso simplifica o pipeline, pois elimina a etapa de busca e indexação.

Na recuperação de informação, você mantém os documentos em uma base vetorial ou índice de busca. A cada pergunta, um mecanismo seleciona os trechos mais prováveis de conter a resposta, e apenas esses trechos são enviados ao modelo. O prompt fica pequeno, mas há uma dependência crítica da qualidade do buscador.

A escolha não é binária. Muitos sistemas combinam as duas: recuperam um conjunto de candidatos e, se necessário, expandem o contexto com documentos adjacentes ou históricos complementares.

Quando faz sentido usar contexto longo

Contexto longo é vantajoso quando:

• O documento é pequeno o suficiente para caber confortavelmente na janela do modelo, considerando também o histórico da conversa e as instruções do sistema.
• A resposta exige raciocínio sobre o documento inteiro, como comparar cláusulas de um contrato, sumarizar uma reunião longa ou analisar um log completo de erros.
• A latência adicional de uma busca não compensa, porque o usuário já forneceu o texto e espera uma análise imediata.
• A base de conhecimento muda pouco e não justifica a manutenção de um índice vetorial.

Nesses casos, enviar o conteúdo completo evita o risco de o buscador não encontrar o trecho certo — uma falha silenciosa que pode degradar a resposta sem que o usuário perceba.

Exemplo genérico em Python com o SDK da OpenAI:

import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ['BASE_URL'],
    api_key=os.environ['API_KEY'],
)

documento = open('contrato_completo.txt').read()

resposta = client.chat.completions.create(
    model='modelo-definido-pela-sua-equipe',
    messages=[
        {'role': 'system', 'content': 'Analise o documento e responda com precisão.'},
        {'role': 'user', 'content': f'Resuma os riscos deste contrato:\n\n{documento}'},
    ],
    max_tokens=1000,
)
print(resposta.choices[0].message.content)

Quando faz sentido usar recuperação

Recuperação é a escolha natural quando:

• A base de conhecimento é grande, com milhares de páginas, e não cabe em uma única janela, ou caberia mas encareceria cada chamada.
• O conteúdo muda com frequência e você precisa atualizar apenas o índice, sem reescrever prompts.
• A pergunta é pontual e a resposta está em um trecho específico, como uma cláusula, uma instrução de API ou um número de protocolo.
• Você precisa auditar quais trechos foram usados para gerar a resposta, algo importante em setores regulados.

O custo de indexação e busca é diluído quando o volume de consultas é alto e o prompt permanece pequeno.

Exemplo de fluxo com recuperação:

import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ['BASE_URL'],
    api_key=os.environ['API_KEY'],
)

def buscar_trechos(pergunta):
    # Implementação do seu buscador vetorial ou lexical
    # Retorna lista de strings relevantes
    return ['Trecho 1: ...', 'Trecho 2: ...']

pergunta = 'Qual é o prazo de rescisão do contrato?'
contexto = '\n\n'.join(buscar_trechos(pergunta))

resposta = client.chat.completions.create(
    model='modelo-definido-pela-sua-equipe',
    messages=[
        {'role': 'system', 'content': 'Use apenas os trechos fornecidos para responder.'},
        {'role': 'user', 'content': f'Pergunta: {pergunta}\n\nContexto:\n{contexto}'},
    ],
    max_tokens=300,
)
print(resposta.choices[0].message.content)

Efeitos qualitativos em latência e custo

Não vou citar números, porque latência e preço variam por fornecedor e região. O importante é entender o mecanismo.

Latência: em contexto longo, o modelo precisa processar mais tokens de entrada antes de começar a gerar a resposta. Isso aumenta o tempo até o primeiro token. Em recuperação, o prompt é pequeno, mas há o tempo adicional da busca e da leitura dos documentos no índice. Para bases pequenas e buscas em memória, a recuperação pode ser quase instantânea; para índices distribuídos, pode adicionar dezenas ou centenas de milissegundos. O ponto é: se a resposta exige raciocínio sobre muitas partes do documento, a latência do contexto longo pode ser aceitável; se a pergunta é simples, a busca tende a ser mais rápida.

Custo: o custo de uma chamada cresce com o total de tokens processados (entrada + saída). Contexto longo coloca muitos tokens na entrada, o que encarece cada chamada, mesmo que a pergunta seja simples. Recuperação mantém a entrada pequena, mas introduz custos de infraestrutura para indexar, armazenar e buscar documentos — custos que não aparecem diretamente na fatura do modelo. A análise correta compara o custo total de propriedade: para poucas consultas por dia, a simplicidade do contexto longo pode compensar; para milhares de consultas, a recuperação tende a reduzir o gasto com tokens.

Armadilhas comuns

1. Achar que janela grande resolve tudo. Mesmo que o modelo aceite 1 milhão de tokens, a qualidade da atenção pode degradar em trechos muito distantes da pergunta, e o custo de processar tudo pode inviabilizar o uso em produção.

2. Subestimar a qualidade do buscador. Se a recuperação falha, o modelo pode responder com informações incorretas ou dizer que não sabe. Em sistemas B2B, uma resposta errada sobre um prazo ou uma configuração pode ter impacto contratual.

3. Ignorar o tratamento de documentos. PDFs com tabelas, contratos digitalizados e páginas com cabeçalhos confundem tanto o parsing para contexto longo quanto a indexação para RAG. Vale investir em extração limpa de texto.

4. Não medir o comportamento real. Sem telemetria de latência, custo por consulta e taxa de sucesso da busca, você toma decisões no escuro. Monitore quantos tokens entram em cada chamada, o tempo de resposta e a qualidade percebida.

Cenário ilustrativo

Imagine uma empresa de software B2B que oferece um assistente para responder perguntas sobre a documentação de seus produtos. A base tem 8.000 páginas, atualizadas a cada duas semanas.

Se a equipe tentar colocar toda a documentação no prompt a cada pergunta, o custo por chamada será alto, a latência aumentará e o modelo poderá se perder em meio a informações irrelevantes. Nesse caso, RAG é claramente mais adequado.

Por outro lado, a mesma empresa tem um recurso de análise de contratos de clientes. Um contrato tem, em média, 20 páginas. Quando o usuário pede uma comparação entre duas cláusulas, carregar o contrato inteiro no contexto é simples, rápido e evita o risco de o buscador não retornar a cláusula correta. Aqui, contexto longo vence.

A lição é projetar por caso de uso, não por tendência.

Conclusão

Contexto longo e recuperação não são concorrentes; são ferramentas complementares. Em sistemas B2B, a decisão deve considerar tamanho da base, frequência de atualização, tipo de pergunta, requisitos de auditoria e perfil de latência esperado. Teste as duas abordagens com uma amostra real de perguntas antes de comprometer a arquitetura.

A TokenRecarga fornece acesso a modelos de IA para empresas brasileiras, com atendimento e faturamento no Brasil.

Quer entender como a sua empresa pode usar modelos de IA com atendimento e faturamento no Brasil? Fale com a gente — a equipe da TokenRecarga responde em português.