Crear un índice para la recuperación proactiva en Búsqueda de Azure AI

En este artículo se explican los campos de índice necesarios y las configuraciones para la recuperación agente. Ninguno de estos requisitos es nuevo. Puede usar un índice existente que cumpla los criterios, incluso si se creó con una versión anterior de la API.

Cada origen de conocimiento indexado depende de un índice subyacente. En función de cómo configure la canalización, el índice puede ser uno de los siguientes:

• Existente: Un índice independiente que se expone a través de un origen de conocimiento del índice de búsqueda. El índice debe cumplir los criterios de este artículo.

• Generado: Índice creado automáticamente por un origen de conocimiento indexado. Los índices generados cumplen todos los criterios de forma predeterminada.

Criterios para la recuperación agente

En la tabla siguiente se organizan los elementos de índice que afectan a la recuperación agentes por nivel de requisito.

Definición de índice de ejemplo

En el ejemplo siguiente se muestra un índice que funciona para la recuperación basada en agentes. Cumple los criterios de los elementos necesarios e incluye campos vectoriales como procedimiento recomendado.

{
  "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": []
  }
}

Un índice bien diseñado para la IA generativa o la generación aumentada mediante recuperación (RAG) tiene los siguientes componentes:

• Descripción que un LLM o agente puede usar para determinar si se debe usar o omitir un índice.

• Fragmentos de texto legible por humanos que puedes proporcionar como tokens de entrada a un LLM para formular respuestas.

• Una configuración de clasificador semántico porque la recuperación de agentes utiliza la clasificación semántica de nivel 2 (L2) para identificar los fragmentos más relevantes.

• (Opcional) Versiones equivalentes a vectores de los fragmentos legibles del texto para la búsqueda vectorial complementaria.

El texto fragmentado es importante porque los LLM consumen y emiten cadenas tokenizadas de contenido de texto sin formato legible. Por este motivo, le conviene disponer de campos searchable que proporcionen cadenas de texto sin formato y que sean retrievable en la respuesta. En Búsqueda de Azure AI, puede crear texto fragmentado mediante soluciones integradas o de terceros.

Una suposición implícita en el contenido fragmentado es que los documentos originales incluyen grandes cantidades de contenido detallado. Si el contenido de origen es datos estructurados, como una base de datos de productos, el índice debe renunciar a la fragmentación y, en su lugar, incluir campos que se asignan al origen de datos original, como un nombre de producto, una categoría o una descripción. La atribución de searchable y retrievable también se aplica a los datos estructurados. searchable convierte el contenido en el ámbito de las consultas y retrievable lo agrega a los resultados de búsqueda (datos de base).

El contenido vectorial puede ser útil porque agrega búsqueda de similitud a la recuperación de información. En el momento de la consulta, cuando los campos vectoriales están presentes en el índice, el motor de recuperación agente ejecuta una consulta vectorial en paralelo a la consulta de texto. Dado que las consultas vectoriales buscan contenido similar en lugar de palabras coincidentes, una consulta vectorial puede encontrar un resultado muy relevante que podría perder una consulta de texto. Añadir vectores puede mejorar la calidad de tus datos de base, pero no es estrictamente necesario. Búsqueda de Azure AI tiene un enfoque integrado para la vectorización.

Los campos vectoriales solo se usan para la ejecución de consultas en Búsqueda de Azure AI. No necesita incluir el vector en los resultados porque no es legible ni para humanos ni para LLM. Para minimizar los requisitos de espacio, se recomienda establecer retrievable y stored en false. Para obtener más información, consulte Optimización del procesamiento y el almacenamiento de vectores.

Si usa vectores, es fundamental tener un vectorizador definido en la configuración de búsqueda de vectores. Determina si el campo vectorial se usa durante la ejecución de la consulta. El vectorizador codifica las subconsultas de cadena en vectores en el momento de la consulta para la búsqueda de similitud en los vectores. El vectorizador debe ser el mismo modelo de inserción que se usa para crear los vectores en el índice.

De forma predeterminada, todos los searchable campos se incluyen en la ejecución de la consulta y todos los retrievable campos se devuelven en los resultados. Puede elegir qué campos usar para cada acción en la definición del origen de conocimiento del índice de búsqueda.

Agregar una descripción

Un campo de índice description es una cadena definida por el usuario que puede usar para proporcionar instrucciones a los servidores LLMs y Model Context Protocol (MCP) al decidir usar un índice específico para una consulta. Este texto legible es muy valioso cuando un sistema debe acceder a varios índices y tomar una decisión basada en la descripción.

Una descripción de índice es una actualización de esquema y puede agregarla sin tener que recompilar todo el índice.

• La longitud de cadena es de 4000 caracteres como máximo.

• El contenido debe ser legible para personas, en Unicode. El caso de uso debe determinar qué idioma usar (por ejemplo, inglés u otro idioma).

Adición de una configuración semántica

El índice debe tener al menos una configuración semántica. La configuración semántica debe tener:

• Una configuración con nombre.
• Se establece prioritizedContentFields en al menos un campo de cadena que sea searchable y retrievable.

Hay dos maneras de especificar una configuración semántica por nombre. Si el índice tiene defaultSemanticConfiguration asignada a una configuración con nombre, se utiliza para la recuperación. Como alternativa, puede especificar la configuración semántica dentro del origen de conocimiento del índice de búsqueda.

Dentro de la configuración, prioritizedContentFields es necesario. El título y las palabras clave son opcionales. En el caso del contenido fragmentado, es posible que tampoco lo tenga. Sin embargo, si agrega reconocimiento de entidades o extracción de frases clave, es posible que tenga algunas palabras clave asociadas a cada fragmento que pueda ser útil en escenarios de búsqueda, quizás en un perfil de puntuación.

El siguiente ejemplo muestra una configuración semántica que funciona para la recuperación agéntica.

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

Agregar un vectorizador

Si el índice contiene campos vectoriales, el plan de consulta incluye estos campos si son searchable y tienen una vectorizer asignación.

Un vectorizador especifica un modelo de inserción que proporciona conversiones de texto a vector en el momento de la consulta. Debe apuntar al mismo modelo de inserción que se usa para codificar el contenido vectorial en el índice. Puede usar cualquier modelo de inserción compatible con Búsqueda de Azure AI. Los vectorizadores se especifican en campos vectoriales mediante un perfil de vector.

La definición de campo vectorial del ejemplo de índice muestra los atributos de campo clave: dimensions, que es el número de incrustaciones generadas por el modelo y 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": []
  }

Los perfiles vectoriales son configuraciones de vectorizadores, algoritmos y técnicas de compresión. Cada campo vectorial solo puede usar un perfil, pero el índice puede tener muchos en caso de que desee perfiles únicos para cada campo vectorial.

Consultar vectores y llamar a un vectorizador añade latencia a la solicitud en su conjunto, pero si se desea realizar una búsqueda por similitud, puede compensar.

En el ejemplo siguiente se muestra un vectorizador que funciona para la recuperación agente tal como aparece en una configuración de vectorSearch. No hay nada en la definición del vectorizador que deba cambiarse para funcionar con la recuperación de agentes.

"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": []
}

Adición de un perfil de puntuación

Los perfiles de puntuación son criterios para aumentar la relevancia. Se aplican a campos no vectoriales (texto y números) y se evalúan durante la ejecución de la consulta, aunque el comportamiento preciso depende de la versión de API usada para crear el índice.

Es más probable que un perfil de puntuación agregue valor a la solución si el índice se basa en datos estructurados. Los datos estructurados se indexan en varios campos discretos, lo que significa que el perfil de puntuación puede tener criterios que tengan como destino el contenido o las características de un campo específico.

Si crea el índice con 2025-05-01-preview o posterior, el perfil de puntuación se ejecuta por última vez. Si el índice se crea con una versión anterior de la API, los perfiles de puntuación se evalúan antes de volver a realizar el cambio semántico. El orden real de los resultados clasificados semánticamente viene determinado por la propiedad rankingOrder en el índice, que está configurado ya sea como boostedRerankerScore (se aplicó un perfil de puntuación) o rerankerScore (sin perfil de puntuación).

Puede usar cualquier perfil de puntuación que tenga sentido para el índice. En el ejemplo siguiente se muestra un perfil de puntuación que aumenta la puntuación de búsqueda de una coincidencia si la coincidencia se encuentra en un campo específico. Los campos se ponderan mediante el uso de multiplicadores potenciadores. Por ejemplo, si se encuentra una coincidencia en el campo "Categoría", la puntuación potenciada se multiplica por 5.

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

Adición de un analizador

Los analizadores se aplican a los campos de texto y pueden ser analizadores de lenguaje o analizadores personalizados que controlan la tokenización en el índice, como conservar caracteres especiales o espacios en blanco.

Los analizadores se definen dentro de un índice de búsqueda y se asignan a los campos. El ejemplo de la recopilación de campos incluye una referencia al analizador en los fragmentos de texto. En este ejemplo, el analizador predeterminado (lucene estándar) se reemplaza por un analizador de idioma Microsoft para el idioma inglés.

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

Agregar un mapa de sinónimos

Los mapas de sinónimos expanden las consultas agregando sinónimos para términos con nombre. Por ejemplo, puede usar términos científicos o médicos en lugar de los términos comunes.

Los mapas de sinónimos se definen como un recurso de nivel superior en un índice de búsqueda y se asignan a campos. El ejemplo de la colección "fields" no incluye ningún mapa de sinónimos, pero en el ejemplo siguiente se muestra cómo podría asignarse un mapa de sinónimos con variantes ortográficas de nombres de países o regiones al campo hipotético "ubicaciones".

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

Añade tu índice a una fuente de conocimiento

Si tiene un índice independiente que ya existe y no lo genera un origen de conocimiento, cree los siguientes objetos:

• Un origen de conocimiento para el índice de búsqueda para encapsular su contenido indexado.
• Una base de conocimiento que representa una o varias fuentes de conocimiento y otras instrucciones para la recuperación agéntica.

Contenido relacionado

• Recuperación de agentes en Azure AI Search
• Agentic RAG: Crear un motor de recuperación de razonamiento con Búsqueda de Azure AI (vídeo de YouTube)
• Demostración de Azure OpenAI con recuperación agentiva