Vectores y almacenamiento

Elegir un almacén de vectores: cuatro preguntas que lo deciden

Las tablas de benchmarks publicadas comparan la recuperación en conjuntos de datos públicos, que no son tus datos, tus filtros ni tu distribución de consultas. Cuatro preguntas operativas lo deciden en su lugar.

Por qué las tablas de benchmark son engañosas

Casi todas las comparaciones que encontrarás miden la recuperación y las consultas por segundo en un conjunto de datos público sin filtros de metadatos. Tu aplicación tiene un corpus específico, filtros selectivos en la mayoría de las consultas y un presupuesto de latencia que incluye la red y la reordenación. En esas condiciones, el ranking en una tabla de benchmark a menudo se invierte.

Esto no es un argumento en contra de medir. Es un argumento a favor de medir lo que realmente ejecutarás.

Pregunta uno: ¿cuán grande es el corpus, medido?

Cuenta los fragmentos, no los documentos, y multiplica por dimensiones y precisión para obtener una estimación aproximada de la huella de memoria. Si el resultado cabe cómodamente en la memoria de las máquinas que ya ejecutas, una opción de un solo nodo será más simple y económica que cualquier cosa distribuida. Los equipos adoptan tiendas distribuidas años antes de que las necesiten y pagan por ello en superficie operativa en lugar de dinero.

Pregunta dos: ¿la mayoría de las consultas llevan un filtro?

Esta es la pregunta que separa las tiendas. Si cada consulta está restringida por inquilino, permiso o recencia, necesitas filtrado en el índice en lugar de después de la búsqueda, y debes probar con tu selectividad de filtro real. Una tienda que parece rápida en la búsqueda sin filtro puede descomponerse cuando se excluyen el noventa y nueve por ciento de los candidatos.

Pregunta tres: ¿quién la opera?

Sé honesto sobre la llamada. Si nadie quiere ejecutar un sistema distribuido, un servicio administrado o una extensión a una base de datos que ya operas es la respuesta correcta, independientemente de qué gane una comparación de rendimiento. La tienda más barata es la que tu equipo no despertará.

Pregunta cuatro: ¿cuál es el costo de salida?

Antes de comprometerte, sabe cómo saldrías. ¿Puedes exportar vectores y reconstruir en otro lugar? ¿Es el lenguaje de consulta portable, o el SDK posee tu código? Una tienda que es barata de entrar y costosa de salir es una responsabilidad que aparece en el momento exacto — cuando tienes tráfico y no tienes influencia.

Cómo ejecutar la prueba

Toma doscientas consultas reales con sus filtros de permiso reales. Carga tu corpus real en dos tiendas candidatas. Mide la latencia de extremo a extremo desde tu aplicación, la recuperación en el k que usarás y los pasos operativos para agregar un millón de vectores. Una tarde de esto supera cualquier tabla publicada.

Qué hacer con esto

  • Los benchmarks públicos omiten tus filtros y tu presupuesto de latencia, y a menudo se invierten en condiciones reales
  • Mide el tamaño del corpus en bloques y memoria, no en documentos
  • Si la mayoría de las consultas están filtradas, prueba el filtrado dentro del índice con tu selectividad real
  • Conoce el costo de salida antes de comprometerte — exportación, portabilidad y quién posee el lenguaje de consulta
Packs recomendados

Manual de RAG en producción

Estrategias de chunking, configuraciones de reranking, arneses de evaluación y los siete modos de fallo que matan cualquier demo de RAG en la tercera semana.

$19 Verlo →