Recuperação com agentes na Pesquisa de IA do Azure

O que é recuperação por meio de agentes? Na Pesquisa de IA do Azure, a recuperação por meio de agentes é um novo pipeline de várias consultas, criado para perguntas complexas feitas por usuários ou agentes em aplicativos de chat e do copilot. Destina-se a padrões de Geração Aumentada de Recuperação (RAG) e fluxos de trabalho de agente para agente.

Aqui está o que ele faz:

• Usa um LLM (grande modelo de linguagem) para dividir uma consulta complexa em subconsultas menores e mais focadas, garantindo melhor cobertura sobre o conteúdo indexado. As subconsultas podem incluir o histórico de chats para fornecer contexto adicional.

• Executa as subconsultas em paralelo. Cada subconsulta é reclassificada semanticamente para promover as correspondências mais relevantes.

• Combina os melhores resultados em uma resposta unificada que um LLM pode usar para gerar respostas com seu conteúdo proprietário.

• A resposta é modular, mas abrangente em como ela também inclui um plano de consulta e documentos de origem. Você pode optar por usar apenas os resultados da pesquisa como dados de aterramento ou invocar o LLM para formular uma resposta.

Este processo de alta performance ajuda você a gerar dados de base de alta qualidade (ou uma resposta) para seu aplicativo de chat, tendo a capacidade de responder rapidamente a perguntas complexas.

Programaticamente, há suporte para a recuperação agente por meio de um novo objeto da Base de Dados de Conhecimento na versão prévia 2025-11-01 e nos pacotes de visualização do SDK do Azure que fornecem o recurso. A resposta de recuperação de uma base de conhecimento é projetada para consumo downstream por outros agentes e aplicativos de chat.

Por que usar a recuperação com agentes

Você deve usar a recuperação agêntica quando quiser fornecer aos agentes e aplicativos o conteúdo mais relevante para responder a perguntas mais difíceis, aproveitando o contexto do chat e seu conteúdo próprio.

O aspecto com agentes é uma etapa de raciocínio no processamento de planejamento de consultas que é executada por um LLM (grande modelo de linguagem) com suporte que você fornece. O LLM analisa todo o thread de chat para identificar a necessidade de informações subjacentes. Em vez de uma única consulta abrangente, o LLM divide perguntas compostas em subconsultas focadas, com base em perguntas do usuário, histórico de chats e parâmetros da solicitação. As subconsultas direcionam seus documentos indexados (texto sem formatação e vetores) no Azure AI Search. Essa abordagem híbrida garante que você exiba ao mesmo tempo correspondências por palavra-chave e semelhanças semânticas, melhorando significativamente a capacidade de relembrar informações.

O componente de recuperação é a capacidade de executar subconsultas simultaneamente, mesclar resultados, classificar resultados semanticamente e retornar uma resposta de três partes que inclui dados de aterramento para a próxima rodada de conversa, fazer referência a dados para que você possa inspecionar o conteúdo da origem e um plano de atividade que mostra as etapas de execução da consulta.

A expansão de consultas e a execução paralela, juntamente com a resposta de recuperação, são as principais capacidades da recuperação agenteica que a tornam a melhor escolha para aplicativos de IA generativa (RAG).

A recuperação agênica adiciona latência ao processamento de consultas, mas compensa isso adicionando os seguintes recursos:

• Lê no histórico de chats como uma entrada para o pipeline de recuperação.
• Descontrói uma consulta complexa que contém várias "solicitações" em partes do componente. Por exemplo: "encontre-me um hotel perto da praia, com transporte do aeroporto, e isso está a uma curta distância de restaurantes vegetarianos."
• Reescreve uma consulta original em várias subconsultas usando mapas de sinônimos (opcional) e parafraseação gerada por LLM.
• Corrige erros de ortografia.
• Executa todas as subconsultas simultaneamente.
• Gera um resultado unificado como uma única cadeia de caracteres. Como alternativa, você pode extrair partes da resposta para sua solução. Metadados sobre execução de consulta e dados de referência são incluídos na resposta.

A recuperação por meio de agentes invoca todo o pipeline de processamento de consultas várias vezes para cada subconsulta, mas faz isso em paralelo, preservando a eficiência e o desempenho necessários para uma experiência de usuário satisfatória.

Arquitetura e fluxo de trabalho

A recuperação por meio de agentes foi projetada para experiências de pesquisa conversacional que usam um LLM para dividir de forma inteligente consultas complexas. O sistema coordena vários serviços do Azure para entregar resultados de pesquisa abrangentes.

Como funciona

O processo de recuperação agencial funciona da seguinte maneira:

1. Iniciação do fluxo de trabalho: seu aplicativo chama uma base de conhecimento realizando uma ação de recuperação que fornece uma consulta e histórico de conversas.

2. Planejamento de consultas: uma base de dados de conhecimento envia seu histórico de consultas e conversas para uma LLM, que analisa o contexto e divide questões complexas em subconsultas focadas. Esta etapa é automatizada e não pode ser personalizada.

3. Execução da consulta: a base de dados de conhecimento envia as subconsultas para suas fontes de conhecimento. Todas as subconsultas são executadas simultaneamente e podem ser palavras-chave, vetor e pesquisa híbrida. Cada subconsulta passa por uma reclassificação semântica para encontrar as correspondências mais relevantes. As referências são extraídas e mantidas para fins de citação.

4. Síntese de resultados: o sistema combina todos os resultados em uma resposta unificada com três partes: conteúdo mesclado, referências de origem e detalhes de execução.

O índice de pesquisa determina a execução da consulta e as otimizações que ocorrem durante a execução da consulta. Especificamente, se seu índice incluir texto pesquisável e campos de vetor, uma consulta híbrida será executada. Se o único campo pesquisável for um campo de vetor, somente a pesquisa de vetor puro será usada. A configuração semântica do índice, além de perfis de pontuação opcionais, mapas de sinônimos, analisadores e normalizadores (se você adicionar filtros), são usados durante a execução da consulta. É necessário ter padrões nomeados para uma configuração semântica e um perfil de pontuação.

Componentes necessários

Requisitos de integração

Seu aplicativo conduz o pipeline chamando a base de conhecimento e tratando a resposta. O pipeline retorna dados de fundamentação que você repassa a um LLM para geração de respostas na interface da conversa. Para obter detalhes sobre a implementação, consulte Tutorial: Criar uma solução de recuperação agente de ponta a ponta.

Como começar

Para criar uma solução de recuperação agente, você pode usar o portal do Azure, as APIs REST de visualização mais recentes ou um pacote do SDK do Azure de versão prévia que fornece a funcionalidade.

Atualmente, o portal oferece suporte apenas à criação de fontes de conhecimento de índices de pesquisa e de blobs. Outros tipos de fontes de conhecimento devem ser criados programaticamente.

Disponibilidade e preços

A recuperação agentic está disponível em regiões selecionadas. Fontes de conhecimento e bases de dados de conhecimento também têm limites máximos que variam de acordo com a camada de serviço.

Ele depende de recursos premium. Se você desabilitar o classificador semântico para seu serviço de pesquisa, acabará por desabilitar a recuperação automática.

A cobrança baseada em token para o planejamento de consulta baseado em LLM e síntese de resposta (opcional) é baseada em pagamento conforme o uso no OpenAI do Azure. É baseado em token para tokens de entrada e de saída. O modelo que você atribui à base de dados de conhecimento é aquele cobrado pelo uso do token. Por exemplo, se você usar gpt-4o, a cobrança do token será exibida na fatura do gpt-4o.

A cobrança baseada em token para recuperação por meio de agentes é o número de tokens retornados por cada subconsulta.

Exemplo: Estimar custos

A recuperação por meio de agentes tem dois modelos de cobrança: cobrança do OpenAI do Azure (planejamento de consultas e, se habilitada, síntese de resposta) e cobrança da Pesquisa de IA do Azure para recuperação por meio de agentes.

Este exemplo de preço omite a síntese de resposta, mas ajuda a ilustrar o processo de estimativa. Seus custos podem ser menores. Para obter o preço real das transações, consulte os preços do Azure OpenAI.

Custos estimados de cobrança para o planejamento de consultas

Para estimar os custos do plano de consulta como pago conforme o uso no OpenAI do Azure, vamos considerar o gpt-4o-mini:

• 15 centavos por 1 milhão de tokens de entrada.
• 60 centavos por 1 milhão de tokens de saída.
• 2.000 tokens de entrada para o tamanho médio da conversa do chat.
• 350 tokens para o tamanho médio do plano de saída.

Custos estimados de cobrança para execução da consulta

Para estimar as contagens de tokens de recuperação por meio de agentes, comece com uma ideia de como é um documento médio em seu índice. Por exemplo, você pode aproximar:

• 10.000 partes, em que cada parte é de um a dois parágrafos de um PDF.
• 500 tokens por bloco.
• Cada subconsulta reclassifica até 50 partes.
• Em média, há três subconsultas por plano de consulta.

Calculando o preço da execução

1. Suponha que façamos 2.000 recuperações com agentes com três subconsultas por plano. Isso nos dá cerca de 6.000 consultas totais.

2. Reclassifique 50 partes por subconsulta, o que totaliza 300.000 partes.

3. O chunk médio é de 500 tokens, portanto, o total de tokens para a reclassificação é de 150 milhões.

4. Dado um preço hipotético de 0,022 por token, US$ 3,30 é o custo total para a reclassificação em dólares americanos.

5. Passando para os custos do plano de consulta: 2.000 tokens de entrada multiplicados por 2.000 recuperações com agentes equivalem a 4 milhões de tokens de entrada para um total de 60 centavos.

6. Estime os custos de produção com base em uma média de 350 tokens. Se multiplicarmos 350 por 2.000 recuperações com agentes, obteremos 700.000 tokens de saída no total de um total de 42 centavos.

Juntando tudo isso, você pagaria cerca de US$ 3,30 pela recuperação por meio de agentes na Pesquisa de IA do Azure, 60 centavos por tokens de entrada no OpenAI do Azure e 42 centavos por tokens de saída no OpenAI do Azure, resultando em US$ 1,02 para o total de planejamento de consultas. O custo combinado para a execução completa é de US$ 4,32.

Dicas para controlar os custos

• Examine o log de atividades na resposta para descobrir quais consultas foram emitidas para quais fontes e parâmetros foram usados. Você pode reemissar essas consultas em relação aos índices e usar um tokenizador público para estimar tokens e comparar com o uso relatado pela API. No entanto, a reconstrução precisa de uma consulta ou resposta não é garantida. Os fatores incluem o tipo de fonte de conhecimento, como dados da Web públicos ou uma fonte de conhecimento remota do SharePoint que se baseia em uma identidade de usuário, o que pode afetar a reprodução da consulta.

• Reduzir o número de fontes de conhecimento (índices); a consolidação de conteúdo pode diminuir o fan-ou ou o volume de token.

• Reduza o esforço de raciocínio para diminuir o uso de LLM durante o planejamento e a ampliação de consultas (busca iterativa).

• Organize o conteúdo para que as informações mais relevantes possam ser encontradas com menos fontes e documentos (por exemplo, resumos ou tabelas coletados).