Crie um índice para recuperação agential no Pesquisa de IA do Azure

Nota

O Pesquisa de IA do Azure está disponível através do portal Azure, APIs REST e SDKs do Azure. Também sustenta o Foundry IQ, a camada de conhecimento gerida que transforma conteúdos empresariais em bases de conhecimento reutilizáveis e conscientes de permissões para agentes no portal Microsoft Foundry.

Este artigo explica os campos do índice e as configurações necessárias para a pesquisa agêntica. Nenhum destes requisitos é novo. Pode usar um índice existente que cumpra os critérios, mesmo que tenha sido criado com uma versão anterior da API.

Cada fonte de conhecimento indexada depende de um índice subjacente. Dependendo de como configura o seu pipeline, o índice pode ser um dos seguintes:

Critérios para a recuperação agencial

A tabela seguinte organiza os elementos de índice que afetam a recuperação agentical por nível de requisito.

Elemento índice Requisito Notes
searchable e retrievable campos de cadeia de caracteres Obrigatório Usado para execução de consultas e recuperação de resultados.
Configuração semântica Obrigatório Utilize defaultSemanticConfiguration ou substitua a configuração semântica na fonte de conhecimento.
Campos de citação Recomendado Campos definidos pelo utilizador que atribuem respostas ao conteúdo de origem, como nome do documento, número de página ou ID do bloco.
Campos vetoriais e um vetorizador Recomendado Permite a conversão de texto para vetor no momento da consulta.
Perfil de pontuação Opcional Aumenta a relevância para áreas específicas. Definir defaultScoringProfile para aplicar automaticamente.
Analisador Opcional Controla como o texto é tokenizado, como gerir espaços em branco ou caracteres especiais.
Mapas de sinónimos Opcional Alarga as consultas com terminologia ou jargão.

Exemplo de definição de índice

O exemplo seguinte mostra um índice que funciona para a recuperação agêntica. Cumpre os critérios para os elementos exigidos e inclui campos vetoriais como uma boa prática.

{
  "name": "earth_at_night",
  "description": "Contains images and descriptions of our planet in darkness as captured from space by Earth-observing satellites and astronauts on the International Space Station over the past 25 years.",
  "fields": [
    {
      "name": "id", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "key": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
      "analyzer": "en.microsoft",
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk_vector_text_3_large", "type": "Collection(Edm.Single)",
      "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
      "dimensions": 3072,
      "vectorSearchProfile": "hnsw_text_3_large",
      "stored": false,
      "synonymMaps": []
    },
    {
      "name": "page_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "chapter_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    }
  ],
  "semantic": {
    "defaultConfiguration": "semantic_config",
    "configurations": [
      {
        "name": "semantic_config",
        "flightingOptIn": false,
        "prioritizedFields": {
          "prioritizedContentFields": [
            {
              "fieldName": "page_chunk"
            }
          ],
          "prioritizedKeywordsFields": []
        }
      }
    ]
  },
  "vectorSearch": {
    "algorithms": [
      {
        "name": "alg",
        "kind": "hnsw",
        "hnswParameters": {
          "metric": "cosine",
          "m": 4,
          "efConstruction": 400,
          "efSearch": 500
        }
      }
    ],
    "profiles": [
      {
        "name": "hnsw_text_3_large",
        "algorithm": "alg",
        "vectorizer": "azure_openai_text_3_large"
      }
    ],
    "vectorizers": [
      {
        "name": "azure_openai_text_3_large",
        "kind": "azureOpenAI",
        "azureOpenAIParameters": {
          "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
          "deploymentId": "text-embedding-3-large",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "compressions": []
  }
}

Um índice bem concebido para IA generativa ou geração aumentada por recuperação (RAG) tem os seguintes componentes:

  • Uma descrição que um LLM ou agente pode usar para determinar se um índice deve ser usado ou ignorado.

  • Pedaços de texto legíveis por humanos que podes passar como tokens de entrada para um LLM para formulação de respostas.

  • Uma configuração de classificador semântico porque a recuperação por agente usa o ranking semântico de nível 2 (L2) para identificar os fragmentos mais relevantes.

  • (Opcional) Versões vetoriais equivalentes dos blocos de texto legíveis pelo homem para pesquisa vetorial complementar.

O texto em blocos é importante porque os LLMs consomem e emitem cadeias tokenizadas de texto simples legível por humanos. Por esta razão, queres searchable campos que forneçam cadeias de texto simples e que estejam retrievable na resposta. Em Pesquisa de IA do Azure, pode criar texto fragmentado usando soluções incorporadas ou de terceiros.

Uma suposição incorporada para o conteúdo em blocos é que os documentos originais de origem têm grandes quantidades de conteúdo prolixo. Se o seu conteúdo de origem for dados estruturados, como uma base de dados de produtos, o seu índice deve evitar o chunking e incluir em vez disso campos que correspondam à fonte de dados original, como nome de produto, categoria ou descrição. A atribuição de searchable e retrievable também se aplica a dados estruturados. searchable torna o conteúdo elegível para consultas e retrievable adiciona-o aos resultados da pesquisa (dados de fundamentação).

O conteúdo vetorial pode ser útil porque adiciona pesquisa por similaridade à recuperação de informação. No momento da consulta, quando os campos vetoriais estão presentes no índice, o motor de recuperação agentical executa uma consulta vetorial em paralelo à consulta de texto. Como as consultas vetoriais procuram conteúdos semelhantes em vez de palavras correspondentes, uma consulta vetorial pode encontrar um resultado altamente relevante que uma consulta de texto pode ignorar. A adição de vetores pode melhorar e reforçar a qualidade dos seus dados de base, mas não é estritamente necessária. Pesquisa de IA do Azure tem uma abordagem incorporada para vetorização.

Os campos vetoriais são usados apenas para execução de consultas no Pesquisa de IA do Azure. Não precisas do vetor nos resultados porque não é legível nem para humanos nem para LLM. Para minimizar os requisitos de espaço, recomendamos definir retrievable e stored para false. Para mais informações, consulte Otimizar armazenamento e processamento vetorial.

Se usar vetores, ter um vetorizador definido na configuração de pesquisa vetorial é fundamental. Determina se o seu campo vetorial é usado durante a execução da consulta. O vetorizador codifica subconsultas de string em vetores no momento da consulta para pesquisa por similaridade sobre os vetores. O vetorizador deve ser o mesmo modelo de embedding usado para criar os vetores no índice.

Por defeito, todos searchable os campos são incluídos na execução da consulta e todos retrievable os campos são devolvidos nos resultados. Pode escolher quais os campos a usar para cada ação na definição da fonte de conhecimento do índice de pesquisa.

Adicione uma descrição

Um campo de índice description é uma cadeia definida pelo utilizador que pode usar para fornecer orientação a LLMs e servidores Model Context Protocol (MCP) ao decidir usar um índice específico para uma consulta. Este texto legível por humanos é inestimável quando um sistema tem de aceder a vários índices e tomar uma decisão com base na descrição.

Uma descrição do índice é uma atualização do esquema, e podes adicioná-la sem teres de reconstruir todo o índice.

  • O comprimento da cadeia é de 4.000 caracteres no máximo.

  • O conteúdo tem de ser legível por humanos, em Unicode. O seu caso de uso deve determinar qual a língua a usar (por exemplo, inglês ou outra língua).

Adicionar uma configuração semântica

O índice deve ter pelo menos uma configuração semântica. A configuração semântica deve ter:

  • Uma configuração nomeada.
  • Um prioritizedContentFields definido para pelo menos um campo de texto que seja tanto searchable como retrievable.

Existem duas formas de especificar uma configuração semântica pelo nome. Se o índice tiver defaultSemanticConfiguration definido para uma configuração nomeada, a recuperação utiliza-a. Em alternativa, pode especificar a configuração semântica dentro da fonte de conhecimento do índice de pesquisa.

Dentro da configuração, prioritizedContentFields é obrigatório. O título e as palavras-chave são opcionais. Para conteúdo segmentado, poderá não ter nenhum dos dois. No entanto, se adicionar reconhecimento de entidades ou extração de frases-chave, pode ter algumas palavras-chave associadas a cada bloco que podem ser úteis em cenários de pesquisa, talvez num perfil de pontuação.

O exemplo seguinte mostra uma configuração semântica que funciona para a recuperação agentica.

"semantic":{
   "defaultConfiguration":"semantic_config",
   "configurations":[
      {
         "name":"semantic_config",
         "flightingOptIn":false,
         "prioritizedFields":{
            "titleField":{
               "fieldName":""
            },
            "prioritizedContentFields":[
               {
                  "fieldName":"page_chunk"
               }
            ],
            "prioritizedKeywordsFields":[
               {
                  "fieldName":"Category"
               },
               {
                  "fieldName":"Tags"
               },
               {
                  "fieldName":"Location"
               }
            ]
         }
      }
   ]
}

Nota

A resposta fornece title, terms, e content, que correspondem aos campos priorizados nesta configuração.

Adicionar um vetorizador

Se o teu índice contiver campos vetoriais, o plano de consulta inclui esses campos se forem searchable e tiverem uma vectorizer atribuição.

Um vetorizador especifica um modelo de embedding que fornece conversões de texto para vetor no momento da consulta. Deve apontar para o mesmo modelo de embedding usado para codificar o conteúdo vetorial no seu índice. Pode usar qualquer modelo de embedding suportado pelo Pesquisa de IA do Azure. Especificas vectorizadores em campos vetoriais através de um perfil vetorial.

A definição de campo vetorial no exemplo do índice mostra os atributos-chave do campo: dimensions, que é o número de embeddings gerados pelo modelo, e vectorSearchProfile.

  {
    "name": "page_chunk_text_3_large", "type": "Collection(Edm.Single)",
    "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
    "dimensions": 3072,
    "vectorSearchProfile": "hnsw_text_3_large",
    "stored": false,
    "synonymMaps": []
  }

Perfis vetoriais são configurações de vetorizadores, algoritmos e técnicas de compressão. Cada campo vetorial só pode usar um perfil, mas o seu índice pode ter muitos caso queira perfis únicos para cada campo vetorial.

Consultar vetores e chamar um vetorizador adiciona latência ao pedido global, mas se quiseres pesquisa por similaridade, pode valer a pena o compromisso.

O exemplo seguinte mostra um vetorizador que funciona para recuperação agêntica, conforme aparece numa configuração do VectorSearch. Não há nada na definição do vetorizador que precise de ser alterado para funcionar com a recuperação agentica.

"vectorSearch": {
  "algorithms": [
    {
      "name": "alg",
      "kind": "hnsw",
      "hnswParameters": {
        "metric": "cosine",
        "m": 4,
        "efConstruction": 400,
        "efSearch": 500
      }
    }
  ],
  "profiles": [
    {
      "name": "hnsw_text_3_large",
      "algorithm": "alg",
      "vectorizer": "azure_openai_text_3_large"
    }
  ],
  "vectorizers": [
    {
      "name": "azure_openai_text_3_large",
      "kind": "azureOpenAI",
      "azureOpenAIParameters": {
        "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
        "deploymentId": "text-embedding-3-large",
        "modelName": "text-embedding-3-large"
      }
    }
  ],
  "compressions": []
}

Adicionar um perfil de pontuação

Os perfis de pontuação são critérios para aumentar a relevância. São aplicadas a campos não vetoriais (texto e números) e avaliadas durante a execução da consulta, embora o comportamento exato dependa da versão da API usada para criar o índice.

Um perfil de pontuação tem mais probabilidade de acrescentar valor à sua solução se o seu índice for baseado em dados estruturados. Os dados estruturados estão indexados em múltiplos campos distintos, o que significa que o seu perfil de pontuação pode ter critérios que visam o conteúdo ou as características de um campo específico.

Se criar o índice usando 2025-05-01-preview ou posterior, o perfil de pontuação é executado por último. Se o índice for criado usando uma versão anterior da API, os perfis de pontuação são avaliados antes da reclassificação semântica. A ordem real dos resultados classificados semanticamente é determinada pela propriedade de ordem de classificação no índice, que pode ser definida como boostedRerankerScore (foi aplicado um perfil de pontuação) ou rerankerScore (sem perfil de pontuação).

Podes usar qualquer perfil de pontuação que faça sentido para o teu índice. O exemplo seguinte mostra um perfil de pontuação que aumenta a pontuação de pesquisa de uma correspondência se a correspondência for encontrada num campo específico. Os campos são ponderados por multiplicadores de impulso. Por exemplo, se uma correspondência for encontrada no campo "Categoria", a pontuação aumentada é multiplicada por 5.

"scoringProfiles": [
    {
      "name": "boostSearchTerms",
      "text": {
        "weights": {
          "Location": 2,
          "Category": 5
        }
      }
    }
]

Adicionar um analisador

Os analisadores aplicam-se a campos de texto e podem ser analisadores de linguagem ou analisadores personalizados que controlam a tokenização no índice, como a preservação de caracteres especiais ou espaços em branco.

Os analisadores são definidos dentro de um índice de pesquisa e atribuídos a campos. O exemplo da coleção de campos inclui uma referência para o analisador nos segmentos de texto. Neste exemplo, o analisador padrão (Lucene padrão) é substituído por um analisador de línguas da Microsoft para a língua inglesa.

{
  "name": "page_chunk", "type": "Edm.String",
  "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
  "analyzer": "en.microsoft",
  "stored": true,
  "synonymMaps": []
}

Adicionar um mapa de sinónimos

Os mapas de sinónimos expandem as consultas adicionando sinónimos para termos nomeados. Por exemplo, pode ter termos científicos ou médicos para termos comuns.

Os mapas de sinónimos são definidos como um recurso de topo num índice de pesquisa e atribuídos a campos. O exemplo da coleção de campos não inclui um mapa de sinónimos, mas o exemplo seguinte mostra como um mapa de sinónimos com grafias variantes dos nomes dos países/regiões pode ser atribuído a um campo hipotético de "localizações".

{
    "name":"locations",
    "type":"Edm.String",
    "searchable":true,
    "synonymMaps":[ "country-region-synonyms" ]
}

Adicione o seu índice a uma fonte de conhecimento

Se tiver um índice autónomo que já existe e não é gerado por uma fonte de conhecimento, crie os seguintes objetos: