Recuperação baseada em agentes no Pesquisa de IA do Azure 

No Pesquisa de IA do Azure, a recuperação por meio de agentes é um pipeline de várias consultas projetado para perguntas complexas feitas por usuários ou agentes em aplicativos de chat e Copilot. Destina-se a padrões de geração aumentada de recuperação (RAG) e fluxos de trabalho de agente para agente.

Veja como a busca orientada por agentes funciona:

• Pode usar um LLM (modelo de linguagem grande) para dividir uma consulta complexa em subconsultas menores e focadas para uma melhor cobertura sobre conteúdo proprietário e externo. As subconsultas podem incluir o histórico de chat para contexto extra.

• Executa 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 fundamentadas.

• Pode retornar referências de origem e um log de atividades juntamente com o conteúdo mesclado, para que você possa usar apenas os dados de fundamentação ou passá-los para um LLM para obter uma resposta completa.

Esse pipeline de alto desempenho ajuda você a gerar dados de embasamento de alta qualidade ou respostas para o seu aplicativo de chat e permite responder rapidamente a perguntas complexas.

Por que usar recuperação agêntica?

A recuperação com agentes oferece suporte a experiências gerenciadas e personalizadas para agentes e aplicativos. No portal do Microsoft Foundry, ele fornece o IQ do Foundry como uma camada de conhecimento gerenciada para agentes. Você também pode criar soluções de recuperação agente personalizadas usando o portal Azure, a API REST do Serviço de Pesquisa ou um SDK do Azure com suporte.

Use a recuperação agêntica quando quiser fornecer a agentes e aplicativos o conteúdo mais relevante para responder a perguntas mais difíceis, com base no contexto do chat, no seu conteúdo proprietário e em fontes externas.

A recuperação por meio de agentes adiciona latência em comparação com um pipeline de consulta única, mas dá conta da complexidade de consultas que uma consulta única não consegue lidar. Por exemplo, ele pode lidar com:

• Perguntas com múltiplas solicitações, como "encontre para mim um hotel perto da praia, com traslado do aeroporto e que fique a uma distância que dê para ir a pé de restaurantes vegetarianos."

• Perguntas que dependem do contexto anterior na conversa.

• Consultas que se beneficiam da reformulação, usando mapas de sinônimos e paráfrases geradas por LLM para ampliar a cobertura em todo o seu conteúdo.

• Erros de ortografia.

Arquitetura e fluxo de trabalho

O processo de recuperação agêntico funciona da seguinte maneira:

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

2. Planejamento de consulta: Nos níveis low e medium de esforço de raciocínio de recuperação, a base de conhecimento envia sua consulta e o histórico da conversa para um LLM, que gera subconsultas direcionadas. Em esforço minimal, essa etapa é ignorada, e as consultas são emitidas diretamente para fontes de conhecimento. O esforço de raciocínio usa como padrão low e está configurado na base de dados de conhecimento.

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 ou 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 retidas para fins de citação.

4. Síntese de resultados: O sistema combina todos os resultados em uma resposta unificada. O conteúdo mesclado sempre é retornado. Referências de origem e um log de atividades de execução são opcionais.

Components

Para todos os cenários de recuperação agêntica, é necessário uma base de conhecimento e pelo menos uma fonte de conhecimento. Outros componentes são opcionais e dependem da configuração.

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ê pode passar para um LLM para gerar respostas ou usar diretamente na sua interface de conversação. Para obter detalhes sobre a implementação, consulte Tutorial: Criar uma solução de recuperação agente de ponta a ponta.

Disponibilidade e preços

A recuperação agentic está disponível em regiões selecionadas. As fontes de conhecimento e as bases de dados de conhecimento também têm limites máximos que variam de acordo com o tipo de preço e o esforço de raciocínio de recuperação.

Faturamento

A recuperação por meio de agentes incorre em cobranças de dois serviços:

• A Pesquisa de IA do Azure cobra pelos tokens de recuperação consumidos durante a execução da subconsulta e a classificação semântica. O plano gratuito (padrão) fornece uma cota mensal de tokens. O plano padrão permite o pagamento conforme o uso após o consumo da franquia gratuita. Para obter mais informações, consulte Habilitar ou desabilitar a cobrança de recuperação por meio de agentes.

• O OpenAI do Azure cobra pelos tokens de entrada e saída usados ​​no planejamento de consultas baseado em LLM e na síntese de respostas. O preço é sempre pago conforme o uso e baseado no modelo que você atribui à base de conhecimento. As cobranças aparecem na sua fatura do Azure OpenAI. Para ver os preços, consulte preços do Azure OpenAI.

A tabela a seguir compara a cobrança entre o pipeline clássico de consulta única e o pipeline de recuperação por meio de agentes com várias consultas. No pipeline clássico, o componente faturável é o classificador semântico.

Exemplo: estimar custos

Este exemplo ajuda a ilustrar o processo de estimativa de custo para planejamento e execução de consultas, mas não a síntese de resposta. Seus custos podem ser menores. Para obter as taxas atuais, consulte os preços do Pesquisa de IA do Azure  e do Azure OpenAI.

Para estimar os custos do plano de consulta no modelo 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 de chat.
• 350 tokens para um tamanho médio de 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 estimar:

• 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 fragmentos.
• 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 de agentes com três subconsultas por plano. Isso nos dá cerca de 6.000 consultas totais.

2. Reordenar 50 blocos por subconsulta, o que totaliza 300.000 blocos.

3. O bloco médio é de 500 tokens, portanto, o total de tokens para o processo de reranqueamento é 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 de agentes resultam em 4 milhões de tokens de entrada, totalizando 60 centavos.

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

Juntando tudo isso, você pagaria cerca de US$ 3,30 pela recuperação agêntica em Pesquisa de IA do Azure , 60 centavos por tokens de entrada em Azure OpenAI e 42 centavos por tokens de saída em Azure OpenAI, totalizando US$ 1,02 para o 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 de SharePoint remota 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); consolidar o conteúdo pode reduzir o fan-out e o volume de tokens.

• Reduza o esforço de raciocínio para diminuir o uso do LLM durante o planejamento e a expansã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).

Como começar

Para criar uma solução de recuperação agente, você pode usar o portal Azure, o portal Microsoft Foundry (novo), as APIs REST ou um pacote SDK do Azure equivalente.

Próxima etapa