Compartir vía

Almacenamiento vectorial en Azure AI Search

  • Artículo

Búsqueda de Azure AI proporciona almacenamiento vectorial y configuraciones para el vector de búsqueda y la búsqueda híbrida. La compatibilidad se implementa en el nivel de campo, lo que significa que puede combinar campos vectoriales y no vectoriales en el mismo corpus de búsqueda.

Los vectores se almacenan en un índice de búsqueda. Use la API REST Create Index o un método del SDK de Azure equivalente para crear el almacén de vectores.

Entre las consideraciones para el almacenamiento de vectores se incluyen los siguientes puntos:

  • Diseñe un esquema para ajustar el caso de uso en función del patrón de recuperación de vectores previsto.
  • Calcule el tamaño del índice y compruebe la capacidad del servicio de búsqueda.
  • Administración de un almacén de vectores
  • Protección de un almacén de vectores

Patrones de recuperación de vectores

En Azure AI Search, hay dos patrones para trabajar con los resultados de la búsqueda.

  • Búsqueda generativa. Los modelos de lenguaje formulan una respuesta a la consulta del usuario y para ello usan datos de Azure AI Search. Este patrón incluye una capa de orquestación para coordinar las solicitudes y mantener el contexto. En este patrón, los resultados de la búsqueda se introducen en flujos de solicitud, recibidos por modelos de chat como GPT y Text-Davinci. Este enfoque se basa en la arquitectura de generación aumentada de recuperación (RAG), donde el índice de búsqueda proporciona los datos de contextualización.

  • Búsqueda clásica mediante una barra de búsqueda, una cadena de entrada de consulta y resultados representados. El motor de búsqueda acepta y ejecuta la consulta vectorial, formula una respuesta y representa esos resultados en una aplicación cliente. En Búsqueda de Azure AI, los resultados se devuelven en un conjunto de filas sin formato y puede elegir qué campos incluir en los resultados de la búsqueda. Dado que no hay ningún modelo de chat, se espera que rellene el almacén de vectores (índice de búsqueda) con contenido de tipo no vector legible en la respuesta. Aunque el motor de búsqueda coincide con los vectores, debe usar valores no vectores para rellenar los resultados de la búsqueda. Las Consultas vectoriales y las consultas híbridas cubren los tipos de solicitudes de consulta que puede formular para escenarios de búsqueda clásicos.

El esquema del índice debe reflejar su caso de uso principal. En la siguiente sección se ponen de manifiesto las diferencias en la composición de campos de las soluciones creadas para la IA generativa o la búsqueda clásica.

Esquema de un almacén de vectores

Un esquema de índice para un almacén de vectores requiere un nombre, un campo clave (cadena), uno o varios campos vectoriales y una configuración de vectores. Los campos no vectoriales se recomiendan para consultas híbridas o para devolver contenido literal legible por humanos que no tenga que pasar por un modelo de lenguaje. Para obtener instrucciones sobre la configuración de vectores, consulte Creación de un almacén de vectores.

Configuración básica de campos vectoriales

Los campos vectoriales se distinguen por su tipo de datos y propiedades específicas del vector. Este es el aspecto de un campo vectorial en una colección de campos:

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

Los campos vectoriales tienen tipos de datos específicos. Actualmente, Collection(Edm.Single) es el más común, pero el uso de tipos de datos estrechos puede ahorrar en el almacenamiento.

Los campos vectoriales deben ser buscables y recuperables, pero no pueden ser filtrables, clasificables u ordenables, o bien tener analizadores, normalizadores o asignaciones de mapa de sinónimos.

Los campos vectoriales deben tener dimensions establecido en el número de incrustaciones generadas por el modelo de inserción. Por ejemplo, text-embedding-ada-002 genera 1536 incrustaciones para cada fragmento de texto.

Los campos vectoriales se indexan mediante algoritmos indicados por un perfil de vector de búsqueda, que se define en otra parte del índice y, por tanto, no se muestran en el ejemplo. Para obtener más información, consulte configuración de vector de búsqueda.

Colección de campos para cargas de trabajo vectoriales básicas

Los almacenes de vectores requieren más campos, además de campos vectoriales. Por ejemplo, un campo de clave ("id" en este ejemplo) es un requisito de índice.

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

Otros campos, como el campo "content", proporciona el equivalente legible humano del campo "content_vector". Si usa modelos de lenguaje exclusivamente para la formulación de respuestas, puede omitir campos de contenido no vector, pero las soluciones que insertan resultados de búsqueda directamente en las aplicaciones cliente deben tener contenido no vector.

Los campos de metadatos son útiles para los filtros, especialmente si los metadatos incluyen información de origen sobre el documento de origen. No se puede filtrar directamente en un campo vectorial, pero puede establecer los modos de prefiltro o postfiltro para filtrar antes o después de la ejecución de la consulta vectorial.

Esquema generado por el Asistente para importar y vectorizar datos

Se recomienda usar el Asistente para importar y vectorizar datos para la evaluación y las pruebas de concepto. El asistente genera el esquema de ejemplo en esta sección.

El sesgo de este esquema es que los documentos de búsqueda se crean en torno a fragmentos de datos. Si un modelo de lenguaje formula la respuesta, como es habitual en las aplicaciones RAG, querrá un esquema diseñado en torno a fragmentos de datos.

La fragmentación de datos es necesaria para mantenerse dentro de los límites de entrada de los modelos de lenguaje, pero también mejora la precisión de la búsqueda de similitudes cuando las consultas se pueden comparar con fragmentos más pequeños de contenido extraídos de varios documentos principales. Por último, si usa el clasificador semántico, el clasificador semántico también tiene límites de token, que se cumplen más fácilmente si la fragmentación de datos forma parte del enfoque.

En el siguiente ejemplo, para cada documento de búsqueda, hay un identificador de fragmento, un fragmento, un título y un campo vectorial. El asistente rellena el identificador de fragmento y el identificador principal mediante la codificación en base 64 de los metadatos de blobs (ruta de acceso). El fragmento y el título se derivan del contenido y del nombre del blob. El campo vectorial es el único elemento que se genera completamente. Es la versión vectorizada del campo de fragmento. Las inserciones se generan mediante una llamada a un modelo de inserción de Azure OpenAI que proporcione.

"name": "example-index-from-import-wizard",
"fields": [
  {"name": "chunk_id",  "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

Esquema para aplicaciones RAG y de estilo de chat

Si va a diseñar el almacenamiento para la búsqueda generativa, puede crear índices independientes para el contenido estático que ha indexado y vectorizado, y un segundo índice para las conversaciones que se pueden usar en los flujos de avisos. Los índices siguientes se crean a partir del acelerador de chat-with-your-data-solution-accelerator.

Captura de pantalla de los índices creados por el acelerador.

Campos del índice de chat que admiten la experiencia de búsqueda generativa:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

Campos del índice de conversaciones que admiten la orquestación y el historial de chat:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

Esta es una captura de pantalla en la que se muestran los resultados de búsqueda en el Explorador de búsqueda para el índice de conversaciones. La puntuación de búsqueda es 1,00 porque la búsqueda no se ha calificado. Observe los campos que existen para admitir flujos de avisos y de orquestación. El id. de conversación identifica un chat específico. "type" indica si el contenido procede del usuario o del asistente. Las fechas se usan para eliminar chats expirados del historial.

Captura de pantalla del Explorador de búsqueda con resultados de un índice diseñado para aplicaciones RAG.

Estructura física y tamaño

En Azure AI Search, 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 la capacidad, pero Microsoft administra internamente los propios clústeres (índices invertidos y vectoriales) y otros archivos y carpetas.

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

  • Cantidad y composición de los documentos
  • Atributos en campos individuales. Por ejemplo, se requiere más almacenamiento para los campos que se pueden filtrar.
  • Configuración de índice, incluida la configuración vectorial que especifica cómo se crean las estructuras de navegación internas en función de si elige HNSW o KNN exhaustiva para la búsqueda de similitud.

Búsqueda de Azure AI impone límites en el almacenamiento vectorial, lo que ayuda a mantener un sistema equilibrado y estable para todas las cargas de trabajo. Para ayudarle a mantenerse dentro de los límites, se realiza un seguimiento del uso de vectores y se notifica por separado en Azure Portal, y también se realiza un seguimiento mediante programación de las estadísticas de servicio e índice.

En la captura de pantalla siguiente se muestra un servicio S1 configurado con una partición y una réplica. Este servicio concreto tiene 24 índices pequeños, con un campo vectorial de media, y cada campo se compone de 1536 inserciones. En el segundo icono se muestra la cuota y el uso de los índices vectoriales. Un índice vectorial es una estructura de datos interna creada para cada campo vectorial. Por lo tanto, el almacenamiento de los índices vectoriales siempre es una fracción del almacenamiento que utiliza el índice en general. Otros campos y estructuras de datos no vectoriales consumen el resto.

Captura de pantalla de los iconos de uso que muestran el almacenamiento, el índice vectorial y el recuento de índices.

Los límites y estimaciones del índice de vectores se tratan en otro artículo, pero hay dos puntos que conviene resaltar por adelantado; el primero es que el almacenamiento máximo varía según el nivel de servicio y, el segundo, que varía también cuando se creó el servicio de búsqueda. Los servicios de mismo nivel más recientes tienen bastante más capacidad para los índices vectoriales. Por estos motivos, debe realizar las acciones siguientes:

  • Comprobar la fecha de implementación del servicio de búsqueda. Si se creó antes del 3 de abril de 2024, considere la posibilidad de crear un nuevo servicio de búsqueda para mayor capacidad.

  • Elegir un nivel escalable si prevé fluctuaciones en los requisitos de almacenamiento vectorial. El nivel Básico se fija en una partición en los servicios de búsqueda más antiguos. Considere el estándar 1 (S1) y versiones posteriores para obtener más flexibilidad y un rendimiento más rápido, o cree un nuevo servicio de búsqueda que use límites más altos y más particiones en cada nivel de nillable.

Operaciones básicas e interacción

En esta sección se presentan las operaciones en tiempo de ejecución de vectores, incluida la conexión a y la protección de un único índice.

Nota:

Al administrar un índice, tenga en cuenta que no hay compatibilidad con el portal o la API para mover o copiar un índice. En su lugar, los clientes suelen orientar su solución de implementación de aplicaciones a un servicio de búsqueda diferente (si se usa el mismo nombre de índice), o bien revisar el nombre para crear una copia en el servicio de búsqueda actual y, a continuación, compilarla.

Disponibilidad continua

Un índice está disponible inmediatamente para las consultas en cuanto se indexa el primer documento, pero no esta 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. El índice lógico lo administra el usuario.

Un índice tiene disponibilidad continua: no se puede pausar ni desconectar. Dado que está diseñado para el funcionamiento continuo, cualquier actualización de su contenido o adiciones al propio índice se hacen en tiempo real. Como resultado, las consultas podrían devolver temporalmente resultados incompletos si una solicitud coincide con una actualización del documento.

Tenga en cuenta que existe continuidad de consultas para las operaciones de documentos (actualización o eliminación) o para las modificaciones que no afectan a la estructura existente y a la integridad del índice actual (como agregar nuevos campos). Si necesita realizar actualizaciones estructurales (cambio de campos existentes), estas se suelen administrar mediante un flujo de trabajo de colocació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 recompilación de índices, algunos clientes que están realizando pequeños cambios eligen "versionar" un campo mediante la creación de uno nuevo que coexista junto con una versión anterior. Con el tiempo, esto conduce a contenido huérfano en forma de campos o definiciones de analizador personalizadas obsoletos, especialmente en un índice de producción, cuya replicación resulta costosa. Puede solucionar estos problemas en las actualizaciones planeadas del índice como parte de la administración del ciclo de vida de los índices.

Conexión de punto de conexión

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

Punto de conexión Conexión y control de acceso
<your-service>.search.windows.net/indexes Tiene como destino la colección de índices. Se usa al crear, mostrar o eliminar un índice. Se requieren derechos de administrador para estas operaciones, disponibles mediante claves de API de administración o un rol de Colaborador de búsqueda.
<your-service>.search.windows.net/indexes/<your-index>/docs Tiene como destino la colección de documentos de un mismo índice. Se usa al consultar un índice o una actualización de datos. Para las consultas, los derechos de lectura son suficientes y están disponibles mediante claves de API de consulta o un rol de lector de datos. Para la actualización de datos, se requieren derechos de administrador.

  1. Asegúrese de que tiene permisos o una clave de acceso de API. A menos que esté consultando un índice existente, necesita derechos de administrador o una asignación de roles de colaborador para administrar y ver contenido en un servicio de búsqueda.

  2. Comience con Azure Portal. La persona que creó el servicio de búsqueda puede ver y administrar el servicio de búsqueda, incluida la concesión de acceso a otros usuarios a través de la página Control de acceso (IAM).

  3. Pase a otros clientes para el acceso mediante programación. Se recomiendan los inicios rápidos y los ejemplos para los primeros pasos:

Acceso seguro a datos vectoriales

Búsqueda de Azure AI implementa el cifrado de datos, las conexiones privadas para escenarios sin Internet y las asignaciones de roles para el acceso seguro mediante Microsoft Entra ID. En Seguridad en Búsqueda de Azure AI se describe la gama completa de características de seguridad empresarial.

Administración de almacenes de vectores

Azure proporciona una plataforma de supervisión que incluye el registro de diagnóstico y las alertas. Se recomiendan los siguientes procedimientos recomendados:

Consulte también