Skip to main content
El problema de encontrar los N puntos más cercanos en un espacio multidimensional (vectorial) para un punto dado se conoce como búsqueda del vecino más cercano o, de forma abreviada, búsqueda vectorial. Existen dos enfoques generales para resolver la búsqueda vectorial:
  • La búsqueda vectorial exacta calcula la distancia entre el punto dado y todos los puntos del espacio vectorial. Esto garantiza la máxima precisión posible; es decir, los puntos devueltos son necesariamente los vecinos más cercanos reales. Como el espacio vectorial se recorre de forma exhaustiva, la búsqueda vectorial exacta puede resultar demasiado lenta para su uso en escenarios reales.
  • La búsqueda vectorial aproximada engloba un conjunto de técnicas (por ejemplo, estructuras de datos especiales como grafos y bosques aleatorios) que calculan resultados mucho más rápido que la búsqueda vectorial exacta. Por lo general, la precisión del resultado es “lo bastante buena” para un uso práctico. Muchas técnicas aproximadas ofrecen parámetros para ajustar el equilibrio entre la precisión del resultado y el tiempo de búsqueda.
Una búsqueda vectorial (exacta o aproximada) puede expresarse en SQL de la siguiente manera:
Los puntos del espacio vectorial se almacenan en una columna vectors de tipo Array, p. ej., Array(Float64), Array(Float32) o Array(BFloat16). El vector de referencia es un Array constante y se define como una expresión de tabla común. <DistanceFunction> calcula la distancia entre el punto de referencia y todos los puntos almacenados. Para ello, puede utilizarse cualquiera de las funciones de distancia disponibles. <N> especifica cuántos vecinos se deben devolver. Se puede realizar una búsqueda vectorial exacta usando la consulta SELECT anterior tal cual. El tiempo de ejecución de estas consultas suele ser proporcional al número de vectores almacenados y a su dimensión, es decir, al número de elementos del array. Además, dado que ClickHouse realiza un escaneo por fuerza bruta de todos los vectores, el tiempo de ejecución también depende del número de hilos que utiliza la consulta (consulta la configuración max_threads).

Ejemplo

devuelve

Índices de similitud vectorial

ClickHouse proporciona un índice especial de “similitud vectorial” para realizar búsqueda vectorial aproximada.
Los índices de similitud vectorial están disponibles en la versión 25.8 de ClickHouse y posteriores. Si tiene algún problema, abra una incidencia en el repositorio de ClickHouse.

Crear un índice de similitud vectorial

Se puede crear un índice de similitud vectorial en una tabla nueva de esta forma:
Como alternativa, para añadir un índice de similitud vectorial a una tabla existente:
Los índices de similitud vectorial son tipos especiales de índices de omisión de datos (consulta aquí y aquí). En consecuencia, la sentencia ALTER TABLE anterior solo hace que el índice se construya para los nuevos datos que se inserten en la tabla a partir de ese momento. Para construir también el índice para los datos existentes, debes materializarlo:
La función <distance_function> debe ser
  • L2Distance, la distancia euclidiana, que representa la longitud de una recta entre dos puntos en el espacio euclidiano,
  • cosineDistance, la distancia de coseno, que representa el ángulo entre dos vectores no nulos, o
  • dotProduct, el producto escalar (producto interno), que representa la suma de los productos elemento a elemento de dos vectores. Es equivalente a cosineDistance en datos normalizados.
Para datos normalizados, L2Distance suele ser la mejor opción; en caso contrario, se recomienda cosineDistance para compensar la escala.
Para las funciones de distancia L2Distance y cosineDistance, un valor más pequeño implica una mayor similitud, mientras que para dotProduct, un valor más alto implica una mayor similitud. Como resultado, los índices vectoriales con L2Distance y cosineDistance solo pueden ser utilizados por consultas SELECT [...] ORDER BY [...] ASC (ASC es el valor predeterminado de ORDER BY), mientras que los índices vectoriales creados para dotProduct solo pueden ser utilizados por consultas SELECT [...] ORDER BY [...] DESC.
<dimensions> especifica la cardinalidad del array (número de elementos) en la columna subyacente. Si ClickHouse encuentra un array con una cardinalidad distinta durante la creación del índice, el índice se descarta y se devuelve un error. El parámetro opcional GRANULARITY <N> se refiere al tamaño de los gránulos del índice (consulte aquí). A diferencia de los skip indexes normales, que usan una granularidad de índice predeterminada de 1, los índices de similitud vectorial usan 100 millones como granularidad de índice predeterminada. Este valor garantiza que internamente solo se creen unos pocos índices, incluso para partes grandes. Recomendamos cambiar la granularidad del índice solo a usuarios avanzados que comprendan las implicaciones de lo que están haciendo (consulte abajo). Los índices de similitud vectorial son genéricos en el sentido de que pueden admitir distintos métodos de búsqueda aproximada. El método que se usa realmente se especifica mediante el parámetro <type>. Por ahora, el único método disponible es HNSW (artículo académico), una técnica popular y de última generación para la búsqueda vectorial aproximada basada en grafos jerárquicos de proximidad. Si se usa HNSW como tipo, los usuarios pueden especificar opcionalmente más parámetros específicos de HNSW:
Estos son los parámetros específicos de HNSW disponibles:
  • <quantization> controla la cuantización de los vectores en el grafo de proximidad. Los valores posibles son f64, f32, f16, bf16, i8 o b1. El valor predeterminado es bf16. Tenga en cuenta que este parámetro no afecta a la representación de los vectores en la columna subyacente.
  • <hnsw_max_connections_per_layer> controla el número de vecinos por nodo del grafo, también conocido como el hiperparámetro M de HNSW. El valor predeterminado es 32. El valor 0 significa que se usa el valor predeterminado.
  • <hnsw_candidate_list_size_for_construction> controla el tamaño de la lista dinámica de candidatos durante la construcción del grafo HNSW, también conocido como el hiperparámetro ef_construction de HNSW. El valor predeterminado es 128. El valor 0 significa que se usa el valor predeterminado.
Los valores predeterminados de todos los parámetros específicos de HNSW funcionan razonablemente bien en la mayoría de los casos de uso. Por lo tanto, no recomendamos personalizar los parámetros específicos de HNSW. Se aplican restricciones adicionales:
  • Los índices de similitud vectorial solo pueden crearse sobre columnas de tipo Array(Float32), Array(Float64) o Array(BFloat16). No se permiten Arrays de valores de coma flotante Nullable ni LowCardinality, como Array(Nullable(Float32)) y Array(LowCardinality(Float32)).
  • Los índices de similitud vectorial deben crearse sobre una única columna.
  • Los índices de similitud vectorial pueden crearse sobre expresiones calculadas (p. ej., INDEX index_name arraySort(vectors) TYPE vector_similarity([...])), pero esos índices no podrán usarse más adelante para la búsqueda aproximada de vecinos.
  • Los índices de similitud vectorial requieren que todos los arrays de la columna subyacente tengan <dimension> elementos; esto se comprueba durante la creación del índice. Para detectar incumplimientos de este requisito lo antes posible, los usuarios pueden añadir una restricción a la columna del vector, por ejemplo, CONSTRAINT same_length CHECK length(vectors) = 256.
  • Del mismo modo, los valores de array de la columna subyacente no deben estar vacíos ([]) ni tener un valor predeterminado (también []).
Estimación del consumo de almacenamiento y memoria Un vector generado para usarse con un modelo típico de IA (p. ej., un Large Language Model, LLMs) consta de cientos o miles de valores de coma flotante. Por lo tanto, un único valor vectorial puede consumir varios kilobytes de memoria. Los usuarios que deseen estimar el almacenamiento necesario para la columna vectorial subyacente de la tabla, así como la memoria principal necesaria para el índice de similitud vectorial, pueden usar las dos fórmulas siguientes: Consumo de almacenamiento de la columna vectorial en la tabla (sin comprimir):
Ejemplo del conjunto de datos dbpedia:
El índice de similitud vectorial debe cargarse por completo desde el disco en la memoria principal para poder realizar búsquedas. Del mismo modo, el índice vectorial también se construye íntegramente en memoria y luego se guarda en el disco. Consumo de memoria necesario para cargar un índice vectorial:
Ejemplo con el conjunto de datos dbpedia:
La fórmula anterior no contempla la memoria adicional que necesitan los índices de similitud vectorial para asignar estructuras de datos en tiempo de ejecución, como búferes y cachés preasignados.

Uso de un índice de similitud vectorial

Para usar índices de similitud vectorial, la configuración compatibility debe estar establecida en '' (el valor predeterminado), o en '25.1' o una versión posterior.
Los índices de similitud vectorial admiten consultas SELECT con la siguiente forma:
El optimizador de consultas de ClickHouse intenta hacer coincidir la plantilla de consulta anterior y aprovechar los índices de similitud vectorial disponibles. Una consulta solo puede usar un índice de similitud vectorial si la función de distancia en la consulta SELECT coincide con la función de distancia especificada en la definición del índice. Los usuarios avanzados pueden proporcionar un valor personalizado para el parámetro hnsw_candidate_list_size_for_search (también conocido como el hiperparámetro HNSW “ef_search”) para ajustar el tamaño de la lista de candidatos durante la búsqueda (p. ej., SELECT [...] SETTINGS hnsw_candidate_list_size_for_search = <value>). El valor predeterminado de 256 para este parámetro funciona bien en la mayoría de los casos de uso. Valores más altos implican mayor precisión a costa de un rendimiento más lento. Si la consulta puede utilizar un índice de similitud vectorial, ClickHouse comprueba que el LIMIT <N> proporcionado en las consultas SELECT esté dentro de límites razonables. Más concretamente, se devuelve un error si <N> es mayor que el valor del parámetro max_limit_for_vector_search_queries, cuyo valor predeterminado es 100. Valores de LIMIT demasiado grandes pueden ralentizar las búsquedas y, por lo general, indican un error de uso. Para comprobar si una consulta SELECT utiliza un índice de similitud vectorial, puede agregar el prefijo EXPLAIN indexes = 1 a la consulta. A modo de ejemplo, consulta
puede devolver
En este ejemplo, 1 millón de vectores del dataset dbpedia, cada uno con dimensión 1536, se almacenan en 575 granules, es decir, 1,7k filas por granule. La consulta solicita 10 vecinos y el índice de similitud vectorial los encuentra en 10 granules distintos. Estos 10 granules se leerán durante la ejecución de la consulta. Los índices de similitud vectorial se utilizan si la salida contiene Skip y el nombre y tipo del índice vectorial (en el ejemplo, idx y vector_similarity). En este caso, el índice de similitud vectorial descartó dos de cuatro gránulos, es decir, el 50 % de los datos. Cuantos más gránulos se puedan descartar, más efectivo será el uso del índice.
Para forzar el uso del índice, puedes ejecutar la consulta SELECT con la configuración force_data_skipping_indexes (indica el nombre del índice como valor de la configuración).
Post-filtrado y pre-filtrado Los usuarios pueden especificar opcionalmente una cláusula WHERE con condiciones de filtro adicionales para la consulta SELECT. ClickHouse evaluará estas condiciones de filtro mediante la estrategia de post-filtering o pre-filtering. En resumen, ambas estrategias determinan el orden en que se evalúan los filtros:
  • El posfiltrado significa que primero se evalúa el índice de similitud vectorial y, después, ClickHouse evalúa los filtros adicionales especificados en la cláusula WHERE.
  • Con el prefiltrado, el orden de evaluación del filtro es el contrario.
Cada estrategia tiene sus propias ventajas y desventajas:
  • El posfiltrado tiene el problema general de que puede devolver menos filas de las solicitadas en la cláusula LIMIT <N>. Esta situación se produce cuando una o más filas de resultado devueltas por el índice de similitud vectorial no cumplen los filtros adicionales.
  • El prefiltrado es, por lo general, un problema no resuelto. Algunas bases de datos vectoriales especializadas proporcionan algoritmos de prefiltrado, pero la mayoría de las bases de datos relacionales (incluido ClickHouse) recurren a la búsqueda exacta de vecinos, es decir, a un escaneo por fuerza bruta sin índice.
La estrategia utilizada depende de la condición de filtrado. Los filtros adicionales forman parte de la clave de partición Si la condición de filtrado adicional forma parte de la clave de partición, ClickHouse aplicará la poda de particiones. Por ejemplo, una tabla está particionada por rango según la columna year y se ejecuta la siguiente consulta:
ClickHouse descartará todas las particiones excepto la de 2025. Los filtros adicionales no pueden evaluarse mediante índices Si las condiciones de filtro adicionales no pueden evaluarse mediante índices (índice de clave primaria, índice de omisión de dato), ClickHouse aplicará postfiltrado. Los filtros adicionales pueden evaluarse mediante el índice de clave primaria Si las condiciones de filtro adicionales pueden evaluarse mediante la clave primaria (es decir, si forman un prefijo de la clave primaria) y
  • la condición de filtro elimina al menos una fila dentro de una parte, ClickHouse recurrirá al prefiltrado para los rangos “supervivientes” dentro de la parte,
  • la condición de filtro no elimina ninguna fila dentro de una parte, ClickHouse realizará postfiltrado para esa parte.
En la práctica, este último caso es bastante poco probable. Los filtros adicionales pueden evaluarse mediante índices de omisión de dato Si las condiciones de filtro adicionales pueden evaluarse mediante índices de omisión de dato (índice minmax, índice Set, etc.), ClickHouse realiza postfiltrado. En esos casos, el índice de similitud vectorial se evalúa primero, ya que se espera que descarte más filas que los demás índices de omisión de dato. Para un control más preciso del postfiltrado frente al prefiltrado, pueden usarse dos configuraciones: La configuración vector_search_filter_strategy (valor predeterminado: auto, que implementa las heurísticas anteriores) puede establecerse en prefilter. Esto resulta útil para forzar el prefiltrado en los casos en que las condiciones de filtro adicionales son extremadamente selectivas. Como ejemplo, la siguiente consulta puede beneficiarse del prefiltrado:
Suponiendo que solo un número muy pequeño de libros cuesta menos de 2 dólares, el posfiltrado puede devolver cero filas porque las 10 coincidencias principales devueltas por el índice vectorial podrían tener todas un precio superior a 2 dólares. Al forzar el prefiltrado (añada SETTINGS vector_search_filter_strategy = 'prefilter' a la consulta), ClickHouse primero encuentra todos los libros con un precio inferior a 2 dólares y luego ejecuta una búsqueda vectorial por fuerza bruta sobre los libros encontrados. Como enfoque alternativo para resolver el problema anterior, vector_search_index_fetch_multiplier (valor predeterminado: 1.0, máximo: 1000.0) puede configurarse con un valor > 1.0 (por ejemplo, 2.0). La cantidad de vecinos más cercanos obtenidos del índice vectorial se multiplica por el valor de esta configuración y, a continuación, se aplica el filtro adicional sobre esas filas para devolver tantas filas como indique LIMIT. Por ejemplo, podemos volver a ejecutar la consulta, pero con un multiplicador de 3.0:
ClickHouse recuperará 3.0 x 10 = 30 vecinos más cercanos del índice vectorial en cada parte y, después, evaluará los filtros adicionales. Solo se devolverán los diez vecinos más cercanos. Cabe señalar que configurar vector_search_index_fetch_multiplier puede mitigar el problema, pero en casos extremos (una condición WHERE muy selectiva) sigue siendo posible que se devuelvan menos de N filas de las solicitadas. Reclasificación Los índices de omisión de dato en ClickHouse suelen filtrar a nivel de gránulo; es decir, una búsqueda en un índice de omisión de dato (internamente) devuelve una lista de gránulos que podrían coincidir, lo que reduce la cantidad de datos leídos en el escaneo posterior. Esto funciona bien para los índices de omisión de dato en general, pero en el caso de los índices de similitud vectorial, crea un “desajuste de granularidad”. En más detalle, el índice de similitud vectorial determina los números de fila de los N vectores más similares para un vector de referencia dado. Con la configuración vector_search_with_rescoring = 1, ClickHouse lee los vectores originales de precisión completa para las filas candidatas y calcula la distancia final en la canalización SQL habitual. Cuando el plan de consulta lo permite, ClickHouse filtra el escaneo a las filas candidatas devueltas por el índice vectorial antes del cálculo final de la distancia. Este paso se llama rescoring y puede mejorar la exactitud, especialmente con índices vectoriales cuantizados, porque la clasificación final usa los vectores almacenados en lugar de las distancias del índice. Si filtros adicionales eliminan demasiados candidatos o se necesita una mayor exhaustividad, aumente la configuración vector_search_index_fetch_multiplier para que el índice vectorial devuelva más filas candidatas para el rescoring. Por lo tanto, ClickHouse proporciona una optimización que desactiva el rescoring y devuelve los vectores más similares y sus distancias directamente desde el índice. La optimización está habilitada de forma predeterminada; consulte la configuración vector_search_with_rescoring. A grandes rasgos, funciona así: ClickHouse pone los vectores más similares y sus distancias a disposición como una columna virtual _distance. Para verlo, ejecute una consulta de búsqueda vectorial con EXPLAIN header = 1:
Una consulta ejecutada sin rescoring (vector_search_with_rescoring = 0) y con las réplicas paralelas habilitadas puede recurrir al rescoring.

Optimización del rendimiento

Ajuste de la compresión En prácticamente todos los casos de uso, los vectores de la columna subyacente son densos y no se comprimen bien. Como resultado, la compresión ralentiza las inserciones y las lecturas de la columna de vectores. Por lo tanto, recomendamos desactivar la compresión. Para ello, especifique CODEC(NONE) para la columna de vectores de esta manera:
Ajuste de la creación de índices El ciclo de vida de los índices de similitud vectorial está vinculado al ciclo de vida de las partes. En otras palabras, cada vez que se crea una nueva parte con un índice de similitud vectorial definido, ese índice también se crea. Esto suele ocurrir cuando los datos se insertan o durante las fusiones. Por desgracia, HNSW es conocido por sus prolongados tiempos de creación de índices, lo que puede ralentizar considerablemente las inserciones y las fusiones. Lo ideal es usar índices de similitud vectorial solo si los datos son inmutables o cambian rara vez. Para acelerar la creación de índices, se pueden utilizar las siguientes técnicas: En primer lugar, la creación de índices puede paralelizarse. El número máximo de hilos para la creación de índices puede configurarse mediante la configuración del servidor max_build_vector_similarity_index_thread_pool_size. Para obtener un rendimiento óptimo, el valor de esta configuración debe ajustarse al número de núcleos de CPU. En segundo lugar, para acelerar las sentencias INSERT, los usuarios pueden desactivar la creación de índices de omisión de dato en las partes recién insertadas mediante la configuración de sesión materialize_skip_indexes_on_insert. Las consultas SELECT sobre esas partes recurrirán a la búsqueda exacta. Dado que las partes insertadas suelen ser pequeñas en comparación con el tamaño total de la tabla, se espera que el impacto en el rendimiento sea insignificante. En tercer lugar, para acelerar las fusiones, los usuarios pueden desactivar la creación de índices de omisión de dato en las partes fusionadas mediante la configuración de sesión materialize_skip_indexes_on_merge. Esto, junto con la sentencia ALTER TABLE […] MATERIALIZE INDEX […], proporciona un control explícito sobre el ciclo de vida de los índices de similitud vectorial. Por ejemplo, la creación de índices puede posponerse hasta que se hayan ingestado todos los datos o hasta un periodo de baja carga del sistema, como el fin de semana. Ajuste del uso de índices Las consultas SELECT necesitan cargar los índices de similitud vectorial en la memoria principal para poder utilizarlos. Para evitar que el mismo índice de similitud vectorial se cargue repetidamente en la memoria principal, ClickHouse proporciona una caché en memoria específica para estos índices. Cuanto mayor sea esta caché, menos cargas innecesarias se producirán. El tamaño máximo de la caché puede configurarse mediante la configuración del servidor vector_similarity_index_cache_size. De forma predeterminada, la caché puede crecer hasta 5 GB. Los siguientes mensajes de registro (system.text_log) indican que se está cargando el índice de similitud vectorial. Si estos mensajes aparecen repetidamente para distintas consultas de búsqueda vectorial, esto indica que el tamaño de la caché es demasiado pequeño.
La caché del índice de similitud vectorial almacena gránulos del índice vectorial. Si los gránulos individuales del índice vectorial son más grandes que la caché, no se almacenarán en caché. Por lo tanto, asegúrese de calcular el tamaño del índice vectorial (según la fórmula de “Estimación del consumo de almacenamiento y memoria” o system.data_skipping_indices) y dimensionar la caché en consecuencia.
Reiteramos que verificar y, si es necesario, aumentar la caché del índice vectorial debe ser el primer paso al investigar consultas lentas de búsqueda vectorial. El tamaño actual de la caché del índice de similitud vectorial se muestra en system.metrics:
Los aciertos y fallos de caché de una consulta con un identificador de consulta determinado se pueden obtener de system.query_log:
Para casos de uso en producción, recomendamos dimensionar la caché lo suficientemente grande para que todos los índices vectoriales permanezcan en memoria en todo momento. Ajuste de la cuantización La cuantización es una técnica para reducir la huella de memoria de los vectores y los costes computacionales de crear y recorrer índices vectoriales. Los índices vectoriales de ClickHouse admiten las siguientes opciones de cuantización: La cuantización reduce la precisión de las búsquedas vectoriales en comparación con la búsqueda sobre los valores originales de coma flotante de precisión completa (f32). Sin embargo, en la mayoría de los conjuntos de datos, la cuantización brain float de precisión media (bf16) da como resultado una pérdida de precisión insignificante, por lo que los índices de similitud vectorial usan esta técnica de cuantización de forma predeterminada. La cuantización de cuarto de precisión (i8) y la cuantización binaria (b1) provocan una pérdida de precisión apreciable en las búsquedas vectoriales. Recomendamos ambas cuantizaciones solo si el tamaño del índice de similitud vectorial es significativamente mayor que la DRAM disponible. En ese caso, también sugerimos habilitar el rescoring (vector_search_index_fetch_multiplier, vector_search_with_rescoring) para mejorar la precisión. La cuantización binaria solo se recomienda para 1) embeddings normalizados (es decir, longitud del vector = 1; los modelos de OpenAI suelen estar normalizados), y 2) si se utiliza la distancia de coseno como función de distancia. La cuantización binaria usa internamente la distancia de Hamming para construir el grafo de proximidad y buscar en él. El paso de rescoring utiliza los vectores originales de precisión completa almacenados en la tabla para identificar los vecinos más cercanos mediante la distancia de coseno. Ajuste de la transferencia de datos El vector de referencia en una consulta de búsqueda vectorial lo proporciona el usuario y, por lo general, se obtiene mediante una llamada a un Large Language Model (LLM). El código Python típico que ejecuta una búsqueda vectorial en ClickHouse podría verse así
Los vectores de embedding (search_v en el fragmento anterior) pueden tener una dimensión muy grande. Por ejemplo, OpenAI ofrece modelos que generan vectores de embeddings con 1536 o incluso 3072 dimensiones. En el código anterior, el driver de Python de ClickHouse sustituye el vector de embedding por una cadena legible para las personas y luego envía la consulta SELECT completa como una cadena. Suponiendo que el vector de embedding consta de 1536 valores de coma flotante de precisión simple, la cadena enviada alcanza una longitud de 20 kB. Esto genera un uso elevado de CPU para la tokenización, el análisis sintáctico y la realización de miles de conversiones de cadena a float. Además, se requiere una cantidad considerable de espacio en el archivo de registro del servidor de ClickHouse, lo que también provoca un aumento de tamaño en system.query_log. Tenga en cuenta que la mayoría de los modelos LLM devuelven un vector de embedding como una lista o un array de NumPy de floats nativos. Por lo tanto, recomendamos que las aplicaciones de Python vinculen el parámetro del vector de referencia en formato binario usando el siguiente estilo:
En el ejemplo, el vector de referencia se envía tal cual en formato binario y se reinterpreta como un array de números de coma flotante en el servidor. Esto ahorra tiempo de CPU en el servidor y evita generar volumen innecesario en los logs del servidor y en system.query_log.

Administración y monitorización

El tamaño en disco de los índices de similitud vectorial puede consultarse en system.data_skipping_indices:
Salida de ejemplo:

Diferencias con los índices de omisión de datos normales

Como todos los índices de omisión de datos normales, los índices de similitud vectorial se construyen sobre gránulos, y cada bloque indexado consta de GRANULARITY = [N] gránulos ([N] = 1 de forma predeterminada para los índices de omisión de datos normales). Por ejemplo, si la granularidad del índice primario de la tabla es 8192 (configuración index_granularity = 8192) y GRANULARITY = 2, entonces cada bloque indexado contendrá 16384 filas. Sin embargo, las estructuras de datos y los algoritmos para la búsqueda aproximada de vecinos son intrínsecamente orientados a filas. Almacenan una representación compacta de un conjunto de filas y también devuelven filas para las consultas de búsqueda vectorial. Esto da lugar a algunas diferencias poco intuitivas en la forma en que se comportan los índices de similitud vectorial en comparación con los índices de omisión de datos normales. Cuando un usuario define un índice de similitud vectorial sobre una columna, ClickHouse crea internamente un “subíndice” de similitud vectorial para cada bloque de índice. El subíndice es “local” en el sentido de que solo conoce las filas del bloque de índice al que pertenece. En el ejemplo anterior, y suponiendo que una columna tiene 65536 filas, obtenemos cuatro bloques de índice (que abarcan ocho gránulos) y un subíndice de similitud vectorial para cada bloque de índice. En teoría, un subíndice puede devolver directamente las filas con los N puntos más cercanos dentro de su bloque de índice. Para las consultas con vector_search_with_rescoring = 1, ClickHouse puede usar estas posiciones de fila para filtrar filas antes de calcular la distancia final a partir de los vectores almacenados cuando el plan de consulta permite esta optimización. Sin rescoring, ClickHouse usa directamente las distancias del índice vectorial mediante la columna virtual _distance. Ambos modos siguen usando los rangos de gránulos circundantes para programar las lecturas, lo que difiere de los índices de omisión de datos normales, que omiten datos con la granularidad de los bloques de índice. El parámetro GRANULARITY determina cuántos subíndices de similitud vectorial se crean. Los valores más grandes de GRANULARITY implican menos subíndices de similitud vectorial, pero más grandes, hasta el punto en que una columna (o una parte de datos de una columna) tiene un único subíndice. En ese caso, el subíndice tiene una vista “global” de todas las filas de la columna y puede devolver directamente todos los gránulos de la columna (parte) con filas relevantes (hay como máximo LIMIT [N] gránulos de este tipo). Con vector_search_with_rescoring = 1, ClickHouse puede entonces leer las posiciones de fila coincidentes y calcular la distancia exacta para esas filas. Con un valor pequeño de GRANULARITY, cada subíndice puede devolver hasta LIMIT N filas candidatas. Como resultado, puede ser necesario leer más filas candidatas y posfiltrarlas. Tenga en cuenta que la exactitud de la búsqueda es igual de buena en ambos casos; solo difiere el rendimiento del procesamiento. En general, se recomienda usar un valor grande de GRANULARITY para los índices de similitud vectorial y recurrir a valores más pequeños de GRANULARITY solo en caso de problemas, como un consumo excesivo de memoria de las estructuras de similitud vectorial. Si no se especifica GRANULARITY para los índices de similitud vectorial, el valor predeterminado es 100 millones.

Ejemplo

Consultas:
Query
Response
Más conjuntos de datos de ejemplo que usan búsqueda vectorial aproximada:

Búsqueda vectorial con códecs cuantizados

El códec Quantized es experimental. Habilítalo con SET allow_experimental_codecs = 1. Si tienes algún problema, abre un issue en el repositorio de ClickHouse.

Introducción

Un índice de similitud vectorial responde a una consulta de vecino más cercano recorriendo un grafo y ofrece un rendimiento muy bueno cuando el grafo puede mantenerse en memoria. Dos condiciones limitan su aplicabilidad:
  • Escala. El tiempo necesario para construir el grafo y la memoria requerida para almacenarlo — además de los propios vectores — pasan a ser el costo dominante.
  • Filtrado. Con un filtro WHERE selectivo, el recorrido del grafo deja de ser eficaz, porque o bien no puede alcanzar el pequeño conjunto de filas que satisfacen el predicado, o bien debe inspeccionar un número desproporcionado de candidatos para encontrarlas.
Un escaneo exhaustivo no está sujeto a ninguna de estas limitaciones: no requiere ninguna estructura auxiliar, las partes se fusionan por concatenación y un filtro simplemente reduce el número de filas que hay que escanear. Su única desventaja es el volumen de datos que debe leer: un escaneo sobre vectores almacenados con precisión Float32 completa está dominado por la E/S de almacenamiento, porque toda la columna de vectores debe leerse desde disco (o almacenamiento de objetos) — en una columna de embedding denso, esa es la columna más grande de la tabla y se comprime mal. El códec de columna Quantized soluciona esta desventaja. Cada vector se almacena dos veces: los valores originales con precisión completa, sin cambios, junto con un código cuantizado compacto en un stream complementario. Una consulta de búsqueda vectorial primero escanea los códigos mediante una función de distancia de bajo costo y compatible con SIMD para formar una lista reducida de los candidatos más prometedores, y luego vuelve a ordenar esa lista reducida comparándola con los vectores de precisión completa. Como un código ocupa solo una fracción del tamaño del vector sin procesar, el escaneo de la lista reducida lee muchos menos bytes del almacenamiento — y solo accede a la columna de precisión completa para el pequeño conjunto de candidatos preseleccionados — mientras que la clasificación final sigue siendo precisa.

Declarar el códec

Adjunte un códec Quantized(...) a una columna Array(Float32) (o Array(Float64) / Array(BFloat16)). El códec es experimental, así que primero habilite allow_experimental_codecs:
Los datos de precisión completa se almacenan como siempre; el códec solo añade el flujo complementario de códigos. El códec se fija al crear la tabla y no se puede añadir ni cambiar con ALTER TABLE.

Métodos de cuantización

Cada método representa un equilibrio distinto entre tamaño, exactitud y métrica. El argumento dimensions es la longitud del vector.
  • Quantized('rabitq', dimensions) — un bit de signo por coordenada más un factor de corrección de coseno no sesgado (dimensions/8 + 4 bytes). Una opción predeterminada sólida, pequeña y barata de evaluar con popcount. Solo cosineDistance.
  • Quantized('turboquant', dimensions) — dos bits por coordenada (un código MSE de 1 bit y un código residual de 1 bit) para candidatos de mayor fidelidad (dimensions/4 + 4 bytes). Solo cosineDistance.
  • Quantized('int8', dimensions) — un código Int8 por coordenada más la norma del vector (dimensions + 4 bytes); el código plano más grande, pero también el más fiel. Admite L2Distance y cosineDistance.
  • Quantized('prefix', dimensions, leading_dimensions, 'int8'|'bf16') — Matryoshka: conserva solo las primeras leading_dimensions coordenadas, como Int8 (con una escala por vector) o BFloat16. Códigos diminutos para embeddings entrenados con Matryoshka Representation Learning. Admite L2Distance y cosineDistance.
  • Quantized('product', dimensions, nbits, m) — cuantización de producto: un diccionario de códigos por partición entrenado con k-means; cada vector se convierte en m códigos de nbits bits (por lo que dimensions debe ser múltiplo de m). La opción más compacta y con mayor recall por byte, a costa de un paso de entrenamiento durante la inserción. Admite L2Distance y cosineDistance.
rabitq y turboquant requieren que dimensions sea múltiplo de 8.

Buscar de forma transparente

No hay una sintaxis de consulta especial; usa la misma consulta top-k que usarías para la búsqueda exacta:
Con vector_search_use_quantized_codes = 1, el optimizador reescribe automáticamente la consulta en un plan de dos etapas: escanea los códigos cuantizados para recopilar una lista reducida y luego vuelve a puntuar la lista reducida con vec de precisión completa. La configuración está desactivada de forma predeterminada, por lo que, sin ella, la misma consulta se ejecuta como un scan exacto simple: el codec nunca cambia los resultados, solo ofrece una vía más rápida cuando decides activarlo. Usa una función de distancia compatible con el method elegido: cosineDistance para todos los methods, y L2Distance además para int8, prefix y product.

Configuración

  • allow_experimental_codecs — debe estar activado para declarar un códec Quantized (predeterminado: 0).
  • vector_search_use_quantized_codes — habilita la reescritura en dos etapas de lista reducida y reevaluación (predeterminado: 0). Cuando está desactivado, las consultas de búsqueda examinan exactamente los vectores de precisión completa.
  • vector_search_index_fetch_multiplier — cuántos candidatos poner en lista reducida en relación con el LIMIT de la consulta: el escaneo conserva los LIMIT × multiplicador códigos principales antes de la reevaluación. Los valores más altos mejoran el recall a costa de una mayor reevaluación. El valor predeterminado es 1 (sin sobremuestreo), por lo que normalmente es necesario aumentarlo —por ejemplo, a 10 o más— para obtener un buen recall.

Diseñado para escalar

Este códec encaja bien con ClickHouse porque la parte costosa —el escaneo— es exactamente aquello que el motor de ClickHouse está diseñado para hacer bien:
  • Vectorizado. Los kernels de escaneo están escritos para SIMD, con despacho en tiempo de ejecución a las instrucciones más amplias que admite la CPU: un popcount por hardware para los métodos de código de signo (rabitq, turboquant) y operaciones amplias de multiplicación-suma fusionada para los demás.
  • En paralelo entre núcleos y partes. Un escaneo plano es trivialmente paralelizable, y ClickHouse lo trata como tal: las distancias se calculan en todos los threads disponibles y sobre todas las partes de una tabla a la vez, y solo se serializa la fusión final del top-k.
  • Distribuido. En un clúster segmentado, el trabajo se reparte entre máquinas: cada segmento escanea su propia porción en paralelo y el coordinador fusiona las listas reducidas.
  • Columnar y compatible con filtros. Los códigos cuantizados ocupan su propia columna, se comprimen y se leen por la misma ruta de E/S que cualquier otra columna, de modo que un WHERE selectivo simplemente deja menos códigos por escanear.
  • Sin una fase de construcción independiente. Los códigos se generan a medida que se escriben los vectores y se fusionan por concatenación; no hay ningún índice que construir, ajustar ni reconstruir, por lo que una tabla queda lista para la búsqueda en cuanto llegan sus datos.
Los códigos solo actúan como generadores de candidatos; la columna de precisión completa, conservada en su lugar, proporciona la clasificación final precisa.

Bit cuantizado (QBit)

Un enfoque habitual para acelerar la búsqueda vectorial exacta es usar un tipo de dato float de menor precisión. Por ejemplo, si los vectores se almacenan como Array(BFloat16) en lugar de Array(Float32), el tamaño de los datos se reduce a la mitad y cabe esperar que los tiempos de ejecución de las consultas disminuyan proporcionalmente. Este método se conoce como cuantización. Aunque acelera el procesamiento, puede reducir la precisión de los resultados a pesar de realizar un escaneo exhaustivo de todos los vectores. Con la cuantización tradicional, perdemos precisión tanto durante la búsqueda como al almacenar los datos. En el ejemplo anterior, almacenaríamos BFloat16 en lugar de Float32, lo que significa que nunca podríamos realizar después una búsqueda más precisa, aunque lo quisiéramos. Otra alternativa es almacenar dos copias de los datos: una cuantizada y otra con precisión completa. Aunque esto funciona, requiere almacenamiento redundante. Imagina un caso en el que tenemos Float64 como dato original y queremos ejecutar búsquedas con distinta precisión (16 bits, 32 bits o los 64 bits completos). Necesitaríamos almacenar tres copias independientes de los datos. ClickHouse ofrece el tipo de dato Quantized Bit (QBit), que resuelve estas limitaciones de la siguiente manera:
  1. Almacena los datos originales con precisión completa.
  2. Permite especificar la precisión de cuantización en tiempo de consulta.
Esto se consigue almacenando los datos en un formato agrupado por bits (es decir, todos los bits en la posición i de todos los vectores se almacenan juntos), lo que permite leer los datos solo con el nivel de precisión solicitado. Así se obtienen las ventajas de velocidad derivadas de la reducción de E/S y de procesamiento que aporta la cuantización, manteniendo al mismo tiempo disponibles todos los datos originales cuando hagan falta. Cuando se selecciona la precisión máxima, la búsqueda pasa a ser exacta. Para declarar una columna de tipo QBit, usa la siguiente sintaxis:
Donde:
  • element_type – el tipo de cada elemento del vector. Los tipos admitidos son Int8, BFloat16, Float32 y Float64
  • dimension – la cantidad de elementos de cada vector
  • stride – opcional. Un divisor de dimension que particiona las dimensiones en dimension / stride grupos contiguos almacenados en flujos separados, de modo que una búsqueda solo sobre las dimensiones iniciales lea menos flujos (útil para los embeddings Matryoshka). El valor predeterminado es dimension, en cuyo caso el tipo es idéntico, byte por byte, a un QBit sin stride. Consulta la página del tipo de dato QBit para obtener más información.

Creación de una tabla QBit y adición de datos

Busquemos los vecinos más cercanos a un vector que representa la palabra ‘lemon’ mediante la distancia L2. El tercer parámetro de la función de distancia especifica la precisión en bits: los valores más altos ofrecen mayor precisión, pero requieren más procesamiento. Puedes encontrar todas las funciones de distancia disponibles para QBit aquí. Búsqueda con precisión completa (64 bits):
Búsqueda con precisión reducida:
Observa que, con una cuantización de 12 bits, obtenemos una buena aproximación de las distancias y las consultas se ejecutan más rápido. El orden relativo se mantiene prácticamente igual, y ‘apple’ sigue siendo la coincidencia más cercana.

Consideraciones de rendimiento

La mejora de rendimiento de QBit se debe a la reducción de las operaciones de E/S, ya que al usar una precisión menor es necesario leer menos datos desde el almacenamiento. Además, cuando QBit contiene datos Float32, si el parámetro de precisión es 16 o menos, se obtienen beneficios adicionales al reducirse el cómputo. El parámetro de precisión controla directamente el equilibrio entre exactitud y velocidad:
  • Mayor precisión (más cercana al ancho original de los datos): resultados más precisos, consultas más lentas
  • Menor precisión: consultas más rápidas con resultados aproximados y menor uso de memoria

Referencias

Blogs:
Última modificación el 23 de julio de 2026