Partilhar via


Recuperação dirigida por agentes na Pesquisa de Inteligência Artificial do Azure

Observação

Esta funcionalidade está atualmente em pré-visualização pública. Esta pré-visualização é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Algumas funcionalidades poderão não ser suportadas ou poderão ter capacidades limitadas. Para obter mais informações, veja Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.

O que é recuperação agentica? No Azure AI Search, a recuperação agêntica é um novo pipeline de múltiplas consultas projetado para perguntas complexas feitas por utilizadores ou agentes em aplicativos de bate-papo e copiloto. Destina-se a padrões de Geração Aumentada de Recuperação (RAG) e fluxos de trabalho de agente para agente.

Veja o que ele faz:

  • Usa um modelo de linguagem grande (LLM) para dividir uma consulta complexa em subconsultas menores e focadas para uma melhor cobertura sobre seu conteúdo indexado. As subconsultas podem incluir o histórico de bate-papo 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 com seu conteúdo proprietário.

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

Este pipeline de alto desempenho ajuda a gerar dados de referência de alta qualidade (ou uma resposta) para a sua aplicação de chat, com a capacidade de responder rapidamente a perguntas complexas.

Programaticamente, a recuperação agêncica é suportada através de um novo objeto Knowledge Base na pré-visualização de 2025-11-01 e nos pacotes de pré-visualização do Azure SDK que fornecem a funcionalidade. A resposta de recuperação de uma base de conhecimento é concebida para utilização por agentes e aplicações de chat subsequentes.

Por que usar a recuperação agênica

Você deve usar a recuperação orientada ao agente quando quiser fornecer aos agentes e aplicativos o conteúdo mais relevante para responder a perguntas mais difíceis, aproveitando o contexto da conversa e o seu conteúdo proprietário.

O aspeto agentic é uma etapa de raciocínio no processamento de planejamento de consultas que é executado por um modelo de linguagem grande (LLM) suportado que você fornece. O LLM analisa todo o thread de bate-papo para identificar a necessidade de informações subjacentes. Em vez de uma única consulta abrangente, o LLM divide as perguntas compostas em subconsultas focadas com base em: perguntas do usuário, histórico de bate-papo e parâmetros na solicitação. As subconsultas destinam-se aos seus documentos indexados (texto simples e vetores) no Azure AI Search. Esta abordagem híbrida garante que você destaque tanto as correspondências de palavras-chave quanto as semelhanças semânticas de uma só vez, melhorando drasticamente a recordação.

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

A expansão de consultas e a execução paralela, além da resposta de recuperação, são os principais recursos da recuperação agentica que a tornam a melhor escolha para aplicativos de IA generativa (RAG).

Diagrama de uma consulta complexa com contexto implícito e um erro de digitação intencional.

A recuperação por agentes adiciona latência ao processamento de consultas, mas compensa ao adicionar estas capacidades:

  • Lê no histórico de bate-papo como uma entrada para o pipeline de recuperação.
  • Desconstrói uma consulta complexa que contém várias solicitações em componentes separados. Por exemplo: "encontre-me um hotel perto da praia, com transporte para o aeroporto, e que esteja a uma curta distância de restaurantes vegetarianos."
  • Reescreve uma consulta original em várias subconsultas usando mapas de sinónimos (opcional) e paráfrase gerada por modelos de linguagem LLM.
  • Corrige erros ortográficos.
  • 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. Os metadados sobre a execução da consulta e os dados de referência são incluídos na resposta.

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

Observação

A inclusão de um LLM no planejamento de consultas adiciona latência a um pipeline de consulta. Você pode mitigar os efeitos usando modelos mais rápidos, como o gpt-4o-mini, e resumindo as conversas. Pode minimizar a latência e os custos definindo propriedades que limitam o processamento dos LLMs. Também podes excluir completamente o processamento de LLM, mantendo apenas o texto, a pesquisa híbrida e a tua própria lógica de planeamento de consultas.

Arquitetura e fluxo de trabalho

A recuperação baseada em agente foi projetada para experiências de pesquisa conversacional que usam um LLM para quebrar consultas complexas de forma inteligente. O sistema coordena vários serviços do Azure para fornecer resultados de pesquisa abrangentes.

Diagrama do fluxo de trabalho de recuperação agentic usando uma consulta de exemplo.

Como funciona

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

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

  2. Planeamento de consultas: Uma base de conhecimento envia o seu histórico de consultas e conversas para um LLM, que analisa o contexto e divide perguntas complexas em subconsultas focadas. Esta etapa é automatizada e não personalizável.

  3. Execução de consultas: A base de conhecimento envia as subconsultas para as suas fontes de conhecimento. Todas as subconsultas são executadas simultaneamente e podem ser palavra-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 retidas 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.

Seu índice de pesquisa determina a execução da consulta e quaisquer otimizações que ocorram durante a execução da consulta. Especificamente, se o índice incluir texto pesquisável e campos vetoriais, uma consulta híbrida será executada. Se o único campo pesquisável é um campo vetorial, então apenas a pesquisa vetorial pura é 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. Você deve ter nomeado padrões para uma configuração semântica e um perfil de pontuação.

Componentes necessários

Componente Serviço Funções
LLM Azure OpenAI Cria subconsultas a partir do contexto da conversa e, posteriormente, usa dados de aterramento para geração de respostas
Base de conhecimento Pesquisa de IA do Azure Orquestra o pipeline, conectando-se ao seu LLM e gerenciando parâmetros de consulta
Fonte de conhecimento Pesquisa de IA do Azure Envolve o índice de pesquisa com propriedades relativas à utilização da base de conhecimento
Índice de pesquisa Pesquisa de IA do Azure Armazena seu conteúdo pesquisável (texto e vetores) com configuração semântica
Classificador semântico Pesquisa de IA do Azure Componente necessário que reclassifica os resultados em termos de relevância (reclassificação L2)

Requisitos de integração

A sua aplicação controla o pipeline ao chamar a base de conhecimento e processar a resposta. O pipeline retorna dados de aterramento que você passa para um LLM para geração de respostas em sua interface de conversação. Para detalhes de implementação, veja Tutorial: Construir uma solução de recuperação agential de ponta a ponta.

Observação

Apenas os modelos das séries gpt-4o, gpt-4.1 e gpt-5 são suportados para o planeamento de consultas. Você pode usar qualquer modelo para geração de resposta final.

Como começar

Para criar uma solução de recuperação agencial, pode usar o portal do Azure, as mais recentes APIs REST de pré-visualização, ou um pacote de SDK do Azure de pré-visualização que forneça a funcionalidade.

Atualmente, o portal apenas suporta a criação de fontes de conhecimento de blobs e de índices de pesquisa. Outros tipos de fontes de conhecimento devem ser criados programáticamente.

Disponibilidade e preços

A recolha de agentes 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 serviço.

Depende de funcionalidades premium. Se desativares o ranqueamento semântico no teu serviço de pesquisa, desativas efetivamente a recuperação agentiva.

Plan Description
Gratuito Um serviço de pesquisa de camada gratuita fornece 50 milhões de tokens de raciocínio agentivo gratuitos por mês. Nos níveis superiores, pode escolher entre o plano gratuito (padrão) e o plano padrão.
Standard O plano padrão é o preço pay-as-you-go depois de consumir a quota mensal gratuita. Depois de esgotada a quota gratuita, é-lhe cobrada uma taxa adicional por cada milhão adicional de tokens de raciocínio agente. Não és notificado quando a transição ocorre. Para mais informações sobre cobranças por moeda, consulte a página de preços do Azure AI Search.

A faturação baseada em tokens para o planeamento de consultas e a síntese de respostas baseados em LLM (opcional) é paga conforme o uso no Azure OpenAI. É baseado em tokens tanto para entrada como para saída. O modelo que atribuis à base de conhecimento é aquele cobrado pelo uso de tokens. Por exemplo, se você usar gpt-4o, a cobrança do token aparecerá na fatura do gpt-4o.

A faturação baseada em tokens para recuperação agential é o número de tokens devolvidos por cada subconsulta.

Aspeto Pipeline clássico de consulta única Pipeline de recuperação agentiva de múltiplas consultas
Unidade Baseado em consulta (1.000 consultas) por unidade de moeda Baseado em token (1 milhão de tokens por unidade de moeda)
Custo por unidade Custo uniforme por consulta Custo uniforme por token
Estimativa de custos Estimar a contagem de consultas Estimar o uso do token
Escalão gratuito 1.000 consultas gratuitas 50 milhões de tokens grátis

Exemplo: Estimar custos

A recuperação agentiva tem dois modelos de faturação: faturação a partir do Azure OpenAI (planeamento de consultas e, se ativado, síntese de respostas) e faturação a partir do Azure AI Search para a recuperação agentiva.

Este exemplo de definição de preço omite a síntese da resposta, mas ajuda a ilustrar o processo de estimativa. Os seus custos podem ser mais baixos. Para obter o preço real das transações, consulte Preços do Azure OpenAI.

Custos de faturamento estimados para planejamento de consultas

Para estimar os custos do plano de consultas no modelo de pagamento conforme o uso no Azure OpenAI, vamos supor 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 no chat.
  • 350 tokens para o tamanho médio do plano de saída.

Custos de cobrança estimados para execução de consultas

Para estimar a contagem de tokens de recuperação agente, tenha uma ideia de como é um documento médio no seu índice. Por exemplo, você pode aproximar:

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

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

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

  2. Reclassifique 50 blocos por subconsulta, o que representa um total de 300.000 blocos.

  3. O bloco médio é de 500 tokens, então 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 para 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 agentic equivalem a 4 milhões de tokens de entrada para um total de 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 agênticas, obteremos 700.000 tokens produzidos, com um custo total de 42 cêntimos.

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

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 SharePoint baseada na identidade do utilizador, o que pode afetar a reprodução das consultas.

  • Reduza o número de fontes de conhecimento (índices); consolidar conteúdos pode diminuir a ramificação e o volume 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 selecionadas).