RAG Query Rewriting: Como resolver corretamente perguntas subsequentes em chatbots de IA

Uma pergunta isolada como “E quanto tempo isso vale?” é frequentemente clara para os seres humanos. Eles se lembram do produto discutido anteriormente, da localização e do prazo pretendido. Uma busca de conhecimento, por outro lado, vê inicialmente apenas algumas palavras. Sem o contexto de conversa adequado, ela pode não encontrar nada ou buscar pelo tópico errado. O RAG Query Rewriting resolve esse problema convertendo uma pergunta subsequente dependente do contexto em uma consulta de busca autônoma antes de realizar a pesquisa.

Isso parece uma etapa intermediária pequena, mas frequentemente decide a qualidade de um chat de site de várias etapas. Este guia mostra como as equipes resolvem perguntas subsequentes, quando é melhor pedir esclarecimentos e como evitar que uma reescrita introduza novos fatos, permissões incorretas ou contexto desatualizado na busca.

Por que perguntas subsequentes sobrecarregam a busca de conhecimento

A primeira pergunta do usuário geralmente é concreta: “Qual garantia se aplica ao Modelo A?”. Em seguida, vêm expressões curtas como “E para a variante maior?”, “Isso também se aplica a Portugal?” ou “O que eu preciso para isso?”. Pronomes, sujeitos omitidos e referências a respostas anteriores são naturais em uma conversa. No entanto, como consultas de busca isoladas, são fracos.

Uma pipeline tradicional de busca por palavras-chave, vetorial ou Hybrid Search só pode avaliar o que recebe como consulta. O reranking melhora a ordem dos resultados existentes, mas não substitui o significado ausente de “isso” ou “para isso”. O Query Rewriting fica antes disso: ele molda a pergunta atual e o histórico relevante em uma consulta pesquisável e autônoma.

O que uma boa reescrita deve realizar

Uma consulta reescrita com sucesso é suficientemente completa para a busca (retrieval), mas permanece estritamente fiel à intenção do usuário. Por exemplo, “E para Portugal?” pode se tornar “Quais condições de garantia se aplicam ao Modelo A em Portugal?”, se o Modelo A e a garantia foram claramente estabelecidos no diálogo imediatamente anterior. A reescrita ainda não responde à pergunta. Ela serve exclusivamente para encontrar fontes adequadas.

As diretrizes atuais da arquitetura do Azure sobre Conversational RAG recomendam incluir o histórico de conversa relevante e formular a pergunta atual como uma consulta autônoma com referências resolvidas antes da busca. Importante é a separação também reconhecível ali: a pergunta original do usuário é mantida para a resposta posterior. Dessa forma, o sistema pode verificar se as evidências encontradas realmente correspondem à pergunta feita.

Complementar, mas não inventar

Um reescritor pode adotar informações claramente existentes: produto, versão, país, idioma ou a última operação mencionada. No entanto, ele não deve adicionar um número de cliente ausente, definir uma variante de produto presumida ou transformar uma indicação de tempo incerta em uma data concreta. Uma precisão de som útil, porém inventada, envia a busca com segurança na direção errada.

As permissões permanecem fora do modelo de texto

Tenant, usuário autenticado, áreas de documentos liberadas e funções são determinados no lado do servidor. Eles não devem ser incluídos na consulta reescrita como afirmações livremente formuladas. O backend define os filtros de metadados correspondentes separadamente e de forma inalterável. Nem uma mensagem anterior do chat nem uma reescrita do modelo devem liberar um espaço de busca maior.

O contexto precisa de um orçamento consciente

Enviar todo o histórico do chat sem filtro para o reescritor raramente é uma boa solução. Tópicos antigos podem se sobrepor à pergunta atual, dados pessoais podem ser transmitidos desnecessariamente e históricos longos aumentam a latência e os custos. Como orientação prática, a diretriz da Microsoft menciona de duas a cinco rodadas de conversa recentes e um resumo dos conteúdos mais antigos. Isso não é um limite universal, mas um ponto de partida para seus próprios testes.

Um pacote de contexto compacto pode consistir nos seguintes componentes:

• a pergunta atual inalterada do usuário,
• poucas mensagens do usuário e do assistente diretamente relevantes,
• entidades já confirmadas, como produto, processo ou localização,
• locale e fuso horário como campos técnicos,
• um resumo de vida curta e verificado de partes mais antigas do diálogo e
• a versão da regra de reescrita, índice de conhecimento e configuração de busca.

As permissões reais dos documentos permanecem separadas disso. Da mesma forma, endereços de e-mail não necessários, números de pedidos ou respostas completas devem ser removidos antes da reescrita. Um histórico com economia de dados facilita adicionalmente a posterior depuração de erros.

Um fluxo robusto em seis etapas

1. Verificar a autonomia: Uma nova pergunta clara como “Como altero minha senha?” pode ir direto para a busca. Nem toda mensagem precisa de uma reescrita por modelo.
2. Reconhecer referências: O sistema marca pronomes, elipses, palavras de comparação e referências como “lá”, “ambos” ou “a segunda opção”.
3. Selecionar o contexto relevante: Apenas as mensagens que resolvem plausivelmente essas referências são adotadas. Uma mudança consciente de tópico encerra o contexto antigo.
4. Decidir entre reescrita ou esclarecimento: Se exatamente uma resolução for confiável, uma consulta de busca autônoma é gerada. Se houver vários significados plausíveis, o chatbot faz uma breve pergunta de esclarecimento.
5. Buscar e, se necessário, decompor: A consulta roda via Keyword, Vector ou Hybrid Search. Perguntas de várias partes podem ser decompostas em subperguntas claramente nomeadas.
6. Responder à pergunta original: A resposta é gerada a partir das fontes encontradas, refere-se ao texto original e menciona abertamente incertezas ou falta de evidências.

A visão geral da Microsoft sobre Agentic Retrieval descreve um fluxo semelhante: a consulta e o histórico de conversa fluem para o planejamento, subconsultas focadas são executadas em paralelo e os resultados são consolidados em seguida. O Amazon Bedrock também documenta o planejamento, subconsultas iterativas e a verificação de se os conteúdos encontrados são suficientes para uma resposta. Tais recursos de produto podem assumir partes da pipeline; contudo, as barreiras de qualidade e segurança da sua própria aplicação continuam sendo necessárias.

Rewrite, pergunta de esclarecimento ou Query Decomposition?

Entrada	Reação adequada	Justificativa
“E isso vale em Portugal?” após uma pergunta clara sobre garantia	Formular consulta autônoma	O objeto e a referência são claros.
“E quanto à outra?” após três variantes mencionadas	Fazer uma breve pergunta de esclarecimento	Várias resoluções são plausíveis.
“Compare preço, prazo de entrega e devolução para ambos os modelos”	Decompor em subconsultas focadas	Múltiplos aspectos independentes precisam de resultados confiáveis.
“Novo tópico: Como falo com o suporte?”	Buscar sem o contexto de produto antigo	O usuário sinaliza uma mudança de tópico.

Portanto, Query Decomposition não é o mesmo que Query Rewriting. O Rewriting torna autônoma uma pergunta dependente; a Decomposition divide uma pergunta complexa em várias tarefas de busca. A documentação do Bedrock sobre Query Decomposition mostra que várias subconsultas podem melhorar a cobertura. No entanto, cada consulta adicional precisa de um limite, de um modelo de permissões compartilhado e de uma consolidação rastreável.

Tratar saídas de reescrita como código

Mesmo que o resultado seja apenas texto, ele deve possuir um contrato rigoroso. Um objeto estruturado com campos como standaloneQuery, decision, resolvedReferences e reason é ideal. Decisões permitidas são, por exemplo, SEARCH_AS_IS, REWRITE, CLARIFY e DECOMPOSE. O backend valida tamanho, idioma e campos permitidos antes de iniciar uma busca.

O reescritor não recebe ferramentas e não responde diretamente ao usuário. Instruções do sistema no histórico do chat, textos de documentos inseridos ou solicitações como “Ignore as regras” permanecem sendo dados, não comandos de controle. Para espaços de busca de alto risco, uma regra determinística pode adicionalmente forçar que os filtros de produto, locale ou tenant nunca venham de texto livre.

Testar com um conjunto de testes próprio para perguntas subsequentes

A qualidade não pode ser comprovada com demonstrações isoladas e bem-sucedidas. Adicione diálogos múltiplos reais ao Golden Set para qualidade de resposta existente. Para cada caso, registre o histórico original, a pergunta atual, a decisão de reescrita esperada, as entidades permitidas, as adições proibidas e as fontes esperadas.

• Pronomes e sujeitos omitidos em perguntas subsequentes curtas
• Correções como “Não, eu quis dizer o Modelo B”
• Mudança de tópico e retorno a um tópico anterior
• Variantes ambíguas que exigem obrigatoriamente um esclarecimento
• Mudança de locale, data e fuso horário
• Tentativas não autorizadas de alterar o espaço de busca ou o tenant
• Históricos longos com detalhes antigos irrelevantes
• Perguntas compostas que são decompostas e consolidadas novamente

Meça separadamente: A reescrita corresponde à intenção do usuário? O retrieval encontra as fontes esperadas? Houve pedido de esclarecimento em caso de ambiguidade real? Os filtros de permissão permaneceram inalterados? Quanta latência adicional a etapa causa? O NIST AI RMF Core integra testes repetidos, medição e documentação ao ciclo de vida completo da IA. Para equipes de sites, isso significa: alterar regras de reescrita, modelos ou seleção de contexto apenas com testes de regressão e rollout monitorado.

Checklist compacto para equipes de sites

• A pergunta original do usuário permanece inalterada até a geração da resposta?
• Apenas partes relevantes e com economia de dados do histórico são incluídas?
• O reescritor pode escolher claramente entre reescrita, esclarecimento e decomposição?
• Ele adiciona exclusivamente entidades confirmadas e nenhuma suposição?
• O backend define locale, tenant e permissões independentemente da reescrita?
• Cada subconsulta possui limites fixos de quantidade, tempo e custo?
• Os resultados do retrieval são avaliados em relação à pergunta original?
• Um conjunto de testes de diálogos múltiplos cobre referências, correções e mudanças de tópico?

Conclusão: Primeiro esclareça a consulta de busca, depois responda

O RAG Query Rewriting transforma a brevidade natural de uma conversa em uma consulta de busca confiável. O maior benefício não vem de reescritas extremamente criativas, mas de limites claros: adotar o contexto confirmado, resolver incertezas por meio de perguntas de esclarecimento, manter as permissões no lado do servidor e continuar verificando a resposta em relação à pergunta original. Comece com vinte perguntas subsequentes típicas do seu suporte, marque a decisão esperada e teste cada alteração contra esses mesmos casos. Assim, um chat de várias etapas se torna mais compreensível, sem que a busca responda silenciosamente a uma pergunta diferente.

Fontes

• Microsoft Azure Architecture Center: Prompt Engineering para RAG
• Microsoft Learn: Agentic Retrieval no Azure AI Search
• Amazon Bedrock: Configurar consultas e geração de respostas
• Amazon Bedrock: Agentic Retrieval para bases de conhecimento
• NIST AI Risk Management Framework Core