Buscar índices en Búsqueda de Azure AI

En Búsqueda de Azure AI, un índice de búsqueda es el contenido que se puede buscar en un servicio de búsqueda, disponible para el motor de búsqueda para indexación, recuperación autónoma, búsqueda de texto completo, búsqueda vectorial, búsqueda híbrida y consultas filtradas. Un índice se define mediante un esquema que se guarda en el servicio de búsqueda, con la ingesta de datos siguiente como segundo paso. El contenido indexado existe en su servicio de búsqueda, aparte de sus principales almacenes de datos externos, lo cual es necesario para los tiempos de respuesta en milisegundos que se esperan en las aplicaciones de búsqueda modernas. A excepción de los escenarios de indexación controlada por indizadores y recuperación mediante agente remoto, el servicio de búsqueda nunca se conecta a los datos de origen externos o los consulta.

En este artículo se describen los conceptos clave para crear y administrar un índice de búsqueda, entre los que se incluyen:

• Contenido (documentos y esquema)
• Estructura de datos físicos
• Operaciones Básico

Esquema de un índice de búsqueda

En Búsqueda de Azure AI, los índices contienen documentos de búsqueda. Desde un punto de vista conceptual, un documento es una sola unidad de datos habilitada para búsquedas en el índice. Por ejemplo, un distribuidor podría tener un documento para cada producto, una universidad podría tener un documento para cada clase, un sitio de viajes podría tener un documento para cada hotel y destino, etc. Estos conceptos se pueden asignar a conceptos equivalentes de bases de datos más conocidos: un índice de búsqueda equivale a una tabla y los documentos son más o menos equivalentes a las filas de una tabla.

Este es un ejemplo del aspecto de un esquema de índice.

{
  "name": "name_of_index, unique across the service",
  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees.",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true (only Edm.String fields can be keys) | false (default where applicable),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing" (only if 'searchAnalyzer' and 'indexAnalyzer' are not set),
      "searchAnalyzer": "name_of_search_analyzer" (only if 'indexAnalyzer' is set and 'analyzer' is not set),
      "indexAnalyzer": "name_of_indexing_analyzer" (only if 'searchAnalyzer' is set and 'analyzer' is not set),
      "normalizer":  "name_of_normalizer" (applies to fields that are filterable),
      "synonymMaps": "name_of_synonym_map" (optional, only one synonym map per field is currently supported),
      "dimensions": "number of dimensions used by an embedding models" (applies to vector fields of type Collection(Edm.Single)),
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

La fields colección suele ser la parte más grande. Cada campo tiene un nombre, un tipo de datos y atributos que determinan el uso en el momento de la consulta.

Otros elementos se han contraído por motivos de brevedad, pero los vínculos siguientes pueden proporcionar más detalles:

• suggesters admite consultas de escritura anticipada, como la función de autocompletar.
• scoringProfiles se usa para el ajuste por relevancia.
• analyzers se usa para procesar cadenas en tokens según determinadas reglas lingüísticas u otras características que admite el analizador.
• corsOptions, o el scripting remoto entre orígenes (CORS), se usa para aplicaciones que emiten solicitudes desde distintos dominios.
• encryptionKey configura el cifrado doble de contenido confidencial en el índice.
• semantic configura el cambio semántico en texto completo y búsqueda híbrida.
• vectorSearch configura los campos y consultas vectoriales.

Definiciones de campo

Un documento de búsqueda es definido por la colección fields dentro del cuerpo de la solicitud Create Index. Necesitará campos para la identificación de documentos (claves), almacenar texto que permite búsquedas y campos para filtros, facetas y ordenaciones de apoyo. Es posible que también necesite campos para los datos que los usuarios no ven. Por ejemplo, puede que desee campos para márgenes de beneficio o promociones de marketing que puede usar en un perfil de puntuación para aumentar una puntuación de búsqueda.

Si los datos entrantes son jerárquicos por naturaleza, puede representarlos dentro de un índice como un tipo complejo, que se usa para las estructuras anidadas. El conjunto de datos de ejemplo, Hotels, ilustra tipos complejos mediante una dirección (contiene varios subcampos) que tiene una relación uno a uno con cada hotel y una colección compleja Rooms, donde varias habitaciones están asociadas a cada hotel.

Atributos de campo

Los atributos de campo determinan cómo se usa un campo, por ejemplo, si se usa en la búsqueda de texto completo, la navegación por facetas, las operaciones de ordenación, etc.

• Los campos de cadena a menudo se marcan como searchable y retrievable.
• Los campos usados para restringir o ordenar los resultados de búsqueda se marcan como sortable, filterabley facetable.

Aunque puede agregar nuevos campos en cualquier momento, las definiciones de campo existentes se bloquean durante la vigencia del índice. Por este motivo, los desarrolladores suelen usar el portal de Azure para crear índices sencillos, probar ideas o usar las páginas del portal de Azure para buscar una configuración. La iteración frecuente de un diseño de índice es más eficaz si se sigue un enfoque basado en código para poder volver a crear el índice fácilmente.

Procedimientos recomendados para campos confidenciales

Si un campo contiene información sensible o confidencial:

• Habilite solo los atributos de campo requeridos por la aplicación, como searchable, filterableo facetable.
• Configure los atributos de campo explícitamente en lugar de confiar en los valores predeterminados de API o SDK.
• No suponga que excluir un campo de los resultados del documento impide la divulgación a través de todas las características de consulta o formatos de respuesta.
• Revise los requisitos de aplicación y características antes de almacenar información confidencial en el índice de búsqueda.

Estructura física y tamaño

En Búsqueda de Azure AI, la estructura física de un índice es en gran medida una implementación interna. Puede acceder a su esquema, cargar y consultar su contenido, supervisar su tamaño y administrar su capacidad. Sin embargo, Microsoft administra la infraestructura y las estructuras de datos físicas almacenadas con el servicio de búsqueda.

Puede supervisar el tamaño del índice en la página Search management > Indexes en el portal de Azure. Como alternativa, puede emitir una solicitud GET INDEX en el servicio de búsqueda o en una solicitud de estadísticas de servicio para comprobar el valor del tamaño de almacenamiento.

El tamaño de un índice viene determinado por:

• Cantidad y composición de los documentos.
• Atributos en campos individuales: el atributo recuperable no aumenta innecesariamente el tamaño del índice, pero los atributos filtrable, ordenable y facetable requieren más almacenamiento para el texto no tokenizado.
• Configuración del índice. En concreto, si incluye sugeridores o analizadores especializados. Si usa el tokenizador de edgeNgram para almacenar secuencias textuales de caracteres (a, ab, abc, abcd), el índice es mayor que si usa el analizador estándar.

La composición y cantidad de los documentos lo determinará lo que decida importar. Recuerde que un índice de búsqueda solo debe contener contenido útil para la aplicación de búsqueda. Si los datos de origen incluyen campos binarios, omita esos campos a menos que use el enriquecimiento con IA para descifrar y analizar el contenido para crear información que permite búsquedas de texto.

Los atributos de los campos determinan los comportamientos. Para admitir esos comportamientos, el proceso de indexación crea las estructuras de datos necesarias. Por ejemplo, para un campo de tipo Edm.String, "searchable" invoca la búsqueda de texto completo, que examina los índices invertidos para el término tokenizado. Por el contrario, un atributo "filtrable" u "ordenable" admite la iteración en cadenas sin modificar.

Los proveedores de sugerencias son construcciones que admiten consultas de estructura anticipada o con la función de autocompletar. Cuando se incluye un proveedor de sugerencias, el proceso de indexación crea las estructuras de datos necesarias para las coincidencias de caracteres textuales. Los proveedores de sugerencias se implementan en el nivel de campo, así que elija solo los campos que sean razonables para el tipo por adelantado.

Operaciones básicas e interacción

Ahora que tiene una idea mejor de lo que es un índice, en esta sección se presentan las operaciones en tiempo de ejecución del índice, incluida la conexión a un índice único y la protección de un único índice.

Aislamiento de índice

En Búsqueda de Azure AI, trabajas con un índice a la vez. Todas las operaciones relacionadas con el índice tienen como destino un único índice. No hay ningún concepto de índices relacionados ni unión de índices independientes para la indexación o la consulta.

Disponibilidad continua

Un índice está disponible inmediatamente para las consultas en cuanto se indexa el primer documento, pero no está totalmente operativo hasta que se indexan todos los documentos. Internamente, un índice se distribuye entre las particiones y se ejecuta en las réplicas. El índice físico se administra internamente. Tú administras el índice lógico.

Un índice está disponible continuamente y no se puede pausar ni desconectar. Dado que está diseñado para la operación continua, las actualizaciones de su contenido y las adiciones al propio índice se producen en tiempo real. Si una solicitud coincide con una actualización del documento, las consultas podrían devolver temporalmente resultados incompletos.

La continuidad de las consultas existe para las operaciones de documento, como actualizar o eliminar, y para las modificaciones que no afectan a la estructura o integridad existentes de un índice, como agregar nuevos campos. Las actualizaciones estructurales, como cambiar los campos existentes, normalmente se administran mediante un flujo de trabajo de eliminación y recompilación en un entorno de desarrollo o mediante la creación de una nueva versión del índice en el servicio de producción.

Para evitar una reconstrucción del índice, algunos usuarios que realizan pequeños cambios actualizan un campo creando una nueva versión que coexiste con una versión anterior. Con el tiempo, esto conduce a contenido huérfano mediante campos obsoletos y definiciones de analizador personalizadas obsoletas, especialmente en un índice de producción que es costoso de replicar. Puede solucionar estos problemas durante las actualizaciones planeadas en el índice como parte de la administración del ciclo de vida del índice.

Conexión y seguridad de puntos de conexión

Todas las solicitudes de indexación y consulta tienen como destino un índice. Los puntos de conexión suelen ser uno de los siguientes:

Conexión a un índice

1. Comience con el portal de Azure y el panel de control del servicio de búsqueda.

2. Pruebe otros clientes para el acceso mediante programación. Se recomiendan los inicios rápidos para los primeros pasos:

   • Inicio rápido: Conexión a un servicio de búsqueda
   • Inicio rápido: REST
   • Inicio rápido: Búsqueda de texto completo
   • Inicio rápido: Recuperación mediante agente

Pasos siguientes

Puede obtener experiencia práctica en la creación de un índice con casi cualquier ejemplo o tutorial para Búsqueda de Azure AI. En el caso de los iniciadores, puede elegir cualquiera de las guías de inicio rápido de la tabla de contenido.

Pero también querrá familiarizarse con las metodologías para cargar un índice con datos. Las estrategias de definición de índices y de importación de datos se definen en tándem. En los artículos siguientes se proporciona más información sobre la creación y carga de un índice.

• Creación de un índice de búsqueda
• Actualización de un índice
• Creación de un almacén de vectores
• Creación de un alias de índice
• Introducción a la importación de datos: Azure Cognitive Search
• Carga de un índice