Reescrita de consultas para RAG: quando usar

A pergunta do usuário nem sempre usa o vocabulário da base

Um colaborador pergunta: “Como peço o dinheiro que gastei na viagem?”. A política interna usa “ressarcimento de despesas de deslocamento”. Outro pergunta “e para quem entrou agora?”, depois de uma conversa sobre benefícios. Procurar essa última frase isoladamente deixa o sistema sem o assunto necessário.

A reescrita de consultas, também chamada de query rewriting, transforma uma pergunta em uma representação mais útil para recuperação. Pode explicitar uma referência da conversa, corrigir um erro de digitação ou acrescentar um termo equivalente do domínio.

Em um fluxo de RAG, seu trabalho termina em consultas de busca. A etapa não deve decidir a resposta nem inventar a condição que o usuário deixou de informar. O ganho esperado é encontrar evidência que já existe, mas não estava sendo recuperada pela formulação original.

Diferencie reescrita, expansão e decomposição

Essas operações podem compartilhar um modelo, mas exigem contratos diferentes.

Reescrita produz uma formulação alternativa da mesma pergunta. “E para quem entrou agora?” pode virar “Qual é a regra de elegibilidade do benefício para colaboradores recém-admitidos?”, desde que o benefício esteja identificado no histórico autorizado.

Expansão acrescenta variantes para procurar o mesmo assunto. Uma consulta sobre ressarcimento pode incluir o termo reembolso, se o glossário da empresa confirmar a equivalência naquele processo.

Decomposição separa uma pergunta composta em buscas menores. “Quais despesas posso pedir e quais comprovantes preciso enviar?” pode exigir consultar elegibilidade e documentação. A resposta final precisa recompor as duas partes, sem tratar uma busca bem-sucedida como solução do pedido inteiro.

Comece pelo mecanismo que resolve a falha observada. Executar todas as operações em cada pergunta aumenta chamadas e dificulta saber qual mudança trouxe benefício.

Onde essa etapa entra no fluxo

Um desenho controlado segue uma sequência simples:

1. receber a pergunta original e identificar o usuário;
2. resolver o escopo de acesso fora do modelo;
3. selecionar apenas o histórico necessário para entender referências;
4. separar campos literais de linguagem descritiva;
5. gerar uma consulta alternativa ou um pequeno conjunto de variantes;
6. validar que a transformação preservou as restrições;
7. recuperar candidatos e registrar a origem de cada busca;
8. selecionar evidência e preparar a resposta à pergunta original.

A busca híbrida para RAG define como combinar mecanismos textuais e vetoriais. A reescrita atua antes: decide como representar a pergunta enviada a esses mecanismos. Já o reranking reordena candidatos que foram encontrados. Se a pergunta foi alterada indevidamente, um ranking excelente pode priorizar evidências para o problema errado.

A documentação do Azure AI Search sobre query rewriting descreve o uso da consulta original junto com variantes geradas. Também alerta que a reescrita pode perder termos exatos, incluindo identificadores e códigos. Na documentação consultada, esse recurso específico está em preview; sua disponibilidade não equivale a uma recomendação de produção para qualquer empresa.

Preserve os campos que não admitem interpretação livre

Em um exemplo hipotético, alguém pergunta: “O erro E-017 tem correção no modelo PX-4, versão 2?”. Uma expansão para “falha de equipamento e atualização de software” pode encontrar muitos documentos, mas perdeu os elementos que distinguiam o caso.

Defina campos protegidos conforme o domínio:

• código de produto, pedido, contrato ou erro;
• versão informada;
• data ou intervalo confirmado;
• unidade de medida;
• negação e condição restritiva;
• entidade identificada sem ambiguidade.

Guarde a pergunta original e mantenha esses valores em estrutura separada. A consulta alternativa pode reorganizar a descrição, mas não deve substituir um identificador por outro semelhante. Quando houver normalização permitida, como retirar espaços de um código, aplique uma regra determinística documentada. Não deixe o modelo “corrigir” o valor por plausibilidade.

A preservação também inclui palavras pequenas com consequência grande. “Sem multa” não pode virar “com multa”. “Antes da renovação” não equivale a “depois da renovação”. Testes precisam verificar o significado dessas condições, além da presença literal dos códigos.

Use o histórico sem carregar a conversa inteira

Perguntas de continuação exigem contexto, mas o histórico pode conter assuntos encerrados, sugestões não aprovadas ou dados de outra tarefa. Selecionar tudo aumenta o risco de preencher uma lacuna com informação antiga.

Mantenha um estado curto da consulta: assunto ativo, entidade confirmada, período relevante e referências ainda ambíguas. Anexe a evidência de onde esses campos vieram. Se duas entidades continuarem possíveis, a reescrita deve preservar a ambiguidade ou pedir esclarecimento.

Considere uma conversa que mencionou dois contratos. O usuário pergunta: “Esse já pode ser cancelado?”. Escolher silenciosamente o último contrato citado pode produzir uma consulta específica, porém incorreta. A pergunta útil é qual contrato ele quer avaliar.

O gerenciamento da janela de contexto em agentes de IA ajuda a limitar o material enviado. Aqui, o critério de seleção é o necessário para reconstruir a pergunta, sem transformar o histórico em fonte de autoridade contratual.

Permissões nunca devem nascer da reescrita

O modelo pode sugerir termos de busca. O escopo autorizado deve vir da identidade e da política da aplicação.

Uma solicitação como “procure também em outras contas” não pode retirar o filtro de cliente. Tampouco uma variante gerada pode escolher um índice privado ou ampliar a classificação dos documentos elegíveis.

Separe filtros obrigatórios de filtros interpretativos. Cliente autorizado e classificação de acesso pertencem à política. Um período mencionado pelo usuário pode ser extraído como critério da busca, sujeito a validação. Misturar as duas classes permite que uma transformação textual altere a fronteira de acesso.

Aplique o mesmo escopo à pergunta original e a todas as variantes. O isolamento entre clientes também deve alcançar caches, logs e qualquer serviço externo usado para reescrever consultas.

Controle a quantidade de buscas e o retorno degradado

Expansão precisa de teto de variantes, tempo total e chamadas por consulta. Gerar buscas adicionais até aparecer algum resultado incentiva a recuperação de material apenas tangencial.

Deduplicate candidatos por documento, versão e trecho. Preserve quais variantes os encontraram para investigar ganho e ruído. Uma passagem repetida por várias formulações não representa várias evidências independentes.

Se o reescritor falhar, a consulta original pode ser uma alternativa, desde que esse caminho esteja validado para a tarefa. Perguntas dependentes de histórico podem exigir esclarecimento em vez de uma busca degradada sem contexto. Saída malformada ou alteração de campo protegido deve ser rejeitada, não corrigida por outra sequência ilimitada de chamadas.

Registre a rota usada. O atendimento precisa saber se recebeu uma resposta completa, uma busca limitada ou um pedido de informação adicional.

Teste se houve ganho sem deslocar a intenção

Monte um conjunto de perguntas com evidência esperada e mantenha fixa a versão da base. Compare a consulta original com uma variante reescrita. Em um segundo teste, avalie expansão limitada. Assim, fica possível atribuir o ganho à mudança.

Inclua linguagem informal, abreviações conhecidas, erros de digitação, negações, códigos parecidos, perguntas de continuação e consultas sem resposta. Reserve casos que não foram usados para ajustar as instruções.

Observe quatro dimensões:

• Fidelidade: assunto, entidade, condição e campos protegidos continuaram iguais?
• Recuperação: a evidência necessária passou a aparecer no conjunto de candidatos?
• Ruído: as variantes acrescentaram passagens que confundem a resposta?
• Economia: tempo, chamadas e revisão por resposta aceita permaneceram viáveis?

Avalie classes separadamente. Melhorar perguntas vagas e piorar códigos exatos pode justificar habilitar reescrita apenas para consultas descritivas. Não há obrigação de usar a etapa em todo o tráfego.

O que precisa ficar pronto antes da implantação

A entrega deve incluir um perfil versionado de transformação, campos protegidos, limite de variantes, política de acesso externa ao modelo e comportamento de falha. O dono da base valida o vocabulário; o responsável técnico valida o contrato; o dono do processo aprova os casos em que a etapa pode operar.

Depois da implantação, guarde exemplos de mudanças indevidas de intenção e de perguntas que continuam sem evidência. Revise o perfil quando o vocabulário ou os produtos mudarem. Não use a reformulação para esconder documentos ausentes ou desatualizados.

A empresa ganha capacidade quando a pessoa pode perguntar na linguagem do trabalho e ainda receber evidência do objeto correto. Esse é o critério para manter a reescrita no fluxo.