Prácticas recomendadas para índices vectoriales
Las siguientes recomendaciones ayudan a diseñar índices vectoriales que sean precisos, eficaces y rentables.
Elección primero del modelo y las dimensiones de incrustación
El modelo de incrustación que utilice determina el número de dimensiones que tienen los vectores y establece Dimensions al crear el índice. No puede cambiar el número de dimensiones después de la creación. Elija un modelo de incrustación antes de crear el índice y utilice el mismo modelo para generar tanto los vectores almacenados como los vectores de consulta. Un menor número de dimensiones reduce los costos de búsqueda, escritura y almacenamiento, pero los modelos de mayor dimensión pueden capturar más detalles semánticos. Elija el menor número de dimensiones que cumpla con los requisitos de relevancia. Consulte Generación de incrustaciones vectoriales.
Hacer coincidir la función de distancia con las incrustaciones
Elija la función de distancia que coincida con la forma en que el modelo de incrustación representa la similitud. COSINE compara la dirección e ignora la magnitud, lo que se adapta a la mayoría de los modelos de incrustación de texto. EUCLIDEAN mide la distancia absoluta y es sensible a la magnitud. DOT_PRODUCT también es sensible a la magnitud. Si lo usa, normalice las incrustaciones a una longitud unitaria para que las puntuaciones reflejen la dirección en lugar de la longitud vectorial. No puede cambiar la función de distancia después de crear el índice, así que valide primero su elección con un conjunto de datos representativo. Consulte Cómo clasifican los resultados las funciones de distancia.
Elección de una clave de partición que coincida con los patrones de consulta
Una clave de partición restringe cada llamada de SearchVectors a la parte del índice vectorial que pertenece a un único valor de clave de partición. La llamada no busca en todo el índice. Buscar menos datos reduce los costos, puede mejorar la latencia y la recuperación, y escala horizontalmente el rendimiento en función de los valores de las claves de partición.
Debe suministrar el valor de la clave de partición en SearchConditionExpression en cada búsqueda. Cada búsqueda se limita exactamente a un valor de clave de partición. Elija una clave de partición que coincida con los patrones de consulta que la aplicación admite.
Por ejemplo, si almacena datos basados en la ubicación por estado de EE. UU., tiene aproximadamente 50 valores de clave de partición. Cada estado contiene un número significativo de vectores para una buena recuperación. Las 50 particiones proporcionan un escalado de rendimiento horizontal de hasta aproximadamente 50 veces. Esto funciona cuando cada búsqueda se dirige a un solo estado.
Evite la cardinalidad extrema en cualquier dirección:
-
Demasiado alto (por ejemplo, un ID de elemento único): cada partición contiene un único elemento sin vecinos con los que comparar, lo que provoca una mala recuperación.
-
Demasiado bajo (por ejemplo, un booleano): la mayoría de los elementos se encuentran en una partición, lo que limita el escalado del rendimiento y reduce la latencia y los beneficios en términos de costos.
Para filtrar más dentro de una partición, utilice los atributos de filtro en línea.
Ejemplo de rendimiento. Tenga en cuenta un modelo de incrustación de 768 dimensiones (como Cohere Embed v3) con 1 KB de datos de elementos no vectoriales, lo que arroja un tamaño total del elemento de aproximadamente 4 KB (768 dimensiones × 4 bytes + 1 KB). Con este tamaño de elemento, los límites por clave de partición se traducen en:
-
Búsqueda: 1 GBps ÷ 4 KB ≈ 250 000 vectores examinados por segundo por valor de clave de partición. A medida que aumenta el número de vectores en una partición, cada búsqueda examina más datos y se acercará antes a este límite.
-
Escritura: 10 MBps ÷ 4 KB ≈ 2500 escrituras vectoriales por segundo por valor de clave de partición
Al distribuir los datos entre más valores de clave de partición, se multiplican estos límites. Por ejemplo, 50 valores de clave de partición proporcionan hasta 50 veces el rendimiento total de búsqueda y escritura. Si la carga de trabajo supera estos límites por clave de partición, contacte con AWS Support.
Mantenimiento de las incrustaciones sincronizadas con el contenido de origen
DynamoDB no vuelve a calcular las incrustaciones por usted. Siempre que cambie el contenido de origen que representa una incrustación, regenere el vector con el mismo modelo de incrustación y vuelva a escribirlo en el elemento. De lo contrario, el índice seguirá devolviendo resultados basados en el vector obsoleto. Considere la posibilidad de capturar los cambios de contenido con DynamoDB Streams y utilizar un proceso posterior para regenerar y reescribir las incrustaciones afectadas.
Proyección solo de los atributos que se necesiten
SearchVectors no puede devolver los atributos que no se proyecten en el índice vectorial. La proyección de más atributos aumenta el costo de almacenamiento y escritura del índice. Proyecte los atributos que la aplicación lee directamente de los resultados de búsqueda y recupere el resto con un seguimiento GetItem o BatchGetItem en la tabla base cuando los necesite.
Uso de varios índices para comparar los modelos de incrustación
Puede crear un máximo de 5 índices vectoriales en una sola tabla. Utilice índices independientes para evaluar diferentes modelos de incrustación o versiones de modelos uno al lado del otro. Almacene las incrustaciones de cada modelo en un atributo vectorial diferente y cree un índice vectorial para cada una de ellas. Esto permite comparar la calidad de búsqueda entre modelos con los mismos datos subyacentes sin migrar el índice de producción.
Por ejemplo, al actualizar de una versión del modelo a otra, cree un segundo índice con las dimensiones y la función de distancia del nuevo modelo. Rellénelo con incrustaciones del nuevo modelo, ejecute consultas de prueba con ambos índices y compare la relevancia. Una vez satisfecho, migre la aplicación al nuevo índice y elimine el antiguo.
