Recuperação agente no Pesquisa de IA Azure

Em Pesquisa de IA do Azure, recuperação agentiva é um pipeline de múltiplas consultas concebido para perguntas complexas colocadas por utilizadores ou agentes em aplicações de chat e copilot. Destina-se a padrões de geração aumentada por recuperação (RAG) e fluxos de trabalho entre agentes.

Eis o que a recuperação agêntica faz:

• Pode usar um modelo de linguagem grande (LLM) para dividir uma consulta complexa em subconsultas menores e focadas, para melhor cobertura sobre conteúdos proprietários e externos. As subconsultas podem incluir o histórico de conversas para contexto adicional.

• Executa consultas secundárias em paralelo. Cada subquery é reavaliada semanticamente para maximizar as correspondências mais relevantes.

• Combina os melhores resultados numa resposta unificada que um LLM pode usar para gerar respostas fundamentadas.

• Pode devolver referências de origem e um registo de atividade juntamente com o conteúdo consolidado, para que possa usar apenas os dados de fundamentação ou passá-los a um LLM para obter uma resposta completa.

Este pipeline de alto desempenho ajuda-o a gerar dados de grounding ou respostas de elevada qualidade para a sua aplicação de chat, permitindo responder rapidamente a perguntas complexas.

Por que motivo utilizar pesquisa agêntica?

A recuperação agêntica suporta tanto experiências geridas como personalizadas para agentes e aplicações. No portal Microsoft Foundry, alimenta o Foundry IQ como uma camada de conhecimento gerida para agentes. Também pode criar soluções personalizadas de recuperação agêntica utilizando o portal do Azure, a API REST do Serviço de Pesquisa ou um SDK do Azure suportado.

Utilize a recuperação agentiva quando quiser fornecer a agentes e aplicações o conteúdo mais relevante para responder a perguntas mais complexas, com base no contexto do chat, no seu conteúdo proprietário e em fontes externas.

A recuperação por agentes acrescenta latência em comparação com um pipeline com uma única consulta, mas consegue lidar com consultas complexas com que uma única consulta não consegue lidar. Por exemplo, pode lidar:

• Perguntas com várias perguntas, como "arranja-me um hotel perto da praia, com transporte para o aeroporto, e que fique a uma distância a pé de restaurantes vegetarianos."

• Perguntas que dependem do contexto anterior da conversa.

• Consultas que beneficiam da reformulação, recorrendo a mapas de sinónimos e a paráfrases geradas por LLMs para alargar a cobertura em todo o seu conteúdo.

• Erros ortográficos.

Arquitetura e fluxo de trabalho

O processo de recuperação agentica funciona da seguinte forma:

1. Início do fluxo de trabalho: A sua aplicação chama uma base de conhecimento com uma ação de recuperação que fornece um histórico de consulta e conversa.

2. Planeamento de consultas: Com o esforço de raciocínio de recuperação em low e medium, a base de conhecimento envia a sua consulta e o histórico da conversa para um LLM, que gera subconsultas específicas. Em minimal esforço, este passo é ignorado e as consultas são enviadas diretamente às fontes de conhecimento. O esforço de raciocínio tem como predefinição low e é configurado na base de conhecimento.

3. Execução da consulta: A base de conhecimento envia as subconsultas para as tuas fontes de conhecimento. Todas as subconsultas são executadas simultaneamente e podem ser por palavra-chave, vetorial ou pesquisa híbrida. Cada subconsulta sofre uma reclassificação semântica para encontrar as correspondências mais relevantes. As referências são extraídas e mantidas para efeitos de citação.

4. Síntese dos resultados: O sistema combina todos os resultados numa resposta unificada. O conteúdo intercalado é sempre devolvido. Referências de origem e um registo de atividade de execução são opcionais.

Components

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

Requisitos de integração

A sua aplicação gere o pipeline ao chamar a base de conhecimento e tratar da resposta. O pipeline devolve dados de fundamentação que pode passar a um LLM para gerar respostas ou utilizar diretamente na sua interface de conversação. Para detalhes de implementação, veja Tutorial: Construir uma solução de recuperação agential de ponta a ponta.

Disponibilidade e preços

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

Faturamento

A recuperação por agente acarreta cobranças de dois serviços:

• Pesquisa de IA do Azure fatura pelos tokens de recuperação consumidos durante a execução da subconsulta e a classificação semântica. O plano gratuito (por defeito) oferece uma alocação mensal de tokens. O plano padrão permite preços de pagamento conforme o uso após o consumo da franquia gratuita. Para mais informações, consulte Ativar ou desativar a faturação de recuperação agente.

• Azure OpenAI fatura pelos tokens de entrada e de saída usados no planeamento de consultas baseado em LLM e na síntese de respostas. A definição de preços é sempre pay-as-you-go e baseada no modelo que atribuis à base de conhecimento. As cobranças aparecem na sua fatura Azure OpenAI. Para taxas, consulte Azure OpenAI pricing.

A tabela seguinte compara a faturação entre o pipeline clássico de consulta única e o pipeline de consultas múltiplas com recuperação por agente. No pipeline clássico, o componente faturável é o ranker semântico.

Exemplo: Estimar custos

Este exemplo ajuda a ilustrar o processo de estimativa de custos para planeamento e execução de consultas, mas não a síntese de respostas. Os seus custos podem ser mais baixos. Para as taxas atuais, veja preços do Pesquisa de IA do Azure e preços do Azure OpenAI.

Para estimar os custos do plano de consulta como pay-as-you-go no Azure OpenAI, vamos assumir gpt-4o-mini:

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

Custos estimados de faturação para execução de consultas

Para estimar a contagem de tokens de recuperação agential, comece com uma ideia de como é um documento médio no seu índice. Por exemplo, tu podes aproximar:

• 10.000 blocos, onde cada bloco corresponde a um a dois parágrafos de um PDF.
• 500 tokens por segmento.
• Cada subconsulta reclassifica até 50 fragmentos.
• Em média, existem três subconsultas por plano de consulta.

Cálculo do preço de execução

1. Suponha que fazemos 2.000 recuperações agenticas com três subconsultas por plano. Isto dá-nos cerca de 6.000 consultas no total.

2. Reordenar 50 chunks por subquery, o que corresponde a 300.000 chunks no total.

3. O bloco médio é de 500 tokens, por isso o total de tokens para reclassificação é de 150 milhões.

4. Dado um preço hipotético de 0,022 por token, $3,30 é o custo total de 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 agênticas equivalem a 4 milhões de tokens de entrada, totalizando 60 cêntimos.

6. Estima os custos de produção com base numa média de 350 tokens. Se multiplicarmos 350 por 2.000 recuperações agenticas, obtemos 700.000 tokens de saída no total, totalizando 42 cêntimos.

Juntando tudo, pagarias cerca de 3,30 dólares pela recuperação de agentes no Pesquisa de IA do Azure, 60 cêntimos por tokens de entrada no Azure OpenAI e 42 cêntimos por tokens de saída no Azure OpenAI, e 1,02 dólares pelo planeamento total de consultas. O custo combinado da execução total é de 4,32 dólares.

Dicas para controlar custos

• Revise o registo de atividade na resposta para descobrir que consultas foram feitas a que fontes e os parâmetros utilizados. Pode reemitir essas consultas contra os seus índices e usar um tokenizador público para estimar tokens e comparar com o uso reportado pela API. No entanto, a reconstrução precisa de uma pergunta ou resposta não é garantida. Os fatores incluem o tipo de fonte de conhecimento, como dados públicos da web ou uma fonte remota de conhecimento SharePoint baseada na identidade do utilizador, o que pode afetar a reprodução da consulta.

• Reduzir o número de fontes de conhecimento (índices); consolidar conteúdos pode reduzir o volume de propagação e de tokens.

• Reduzir o esforço de raciocínio para reduzir o uso de LLMs durante o planeamento e expansão de consultas (pesquisa iterativa).

• Organize o conteúdo de modo a que a informação mais relevante possa ser encontrada com menos fontes e documentos (por exemplo, resumos ou tabelas curadas).

Como começar

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

Próximo passo