#vector-search

5 publicacionescon esta etiqueta

La evaluación final: búsqueda híbrida contra los 657,867 documentos, con los 6.73 millones de vectores completos

Once días de cómputo después, la corrida de embeddings terminó y corrimos la evaluación híbrida completa en los cortes v2 y v3 del set. La mejor configuración híbrida supera a cada componente por separado en ambos cortes — pero el peso ganador cambia de un corte al otro (W0.5 en v2, W0.75 en v3), y el mismo tipo de consulta (paráfrasis) favorece pesos opuestos según cómo fue construido el corte. El argumento del peso adaptativo ya no es una hipótesis: es una medición. El set curado v4 (42 preguntas multi-hop con evidencia anotada a mano) confirma el margen de la fusión y delimita dónde el ranking deja de ser el problema.

Joaquín Bravo ContrerasLeer más

La primera evaluación a escala real: BM25 contra 657,867 documentos, de 0.170 a 0.366 al corregir el set

Mientras la corrida de embeddings avanza sobre 6.7 millones de chunks, construimos el índice FTS5 del corpus completo (2.7 GiB) y corrimos la primera evaluación BM25 a escala real. La v2 del set produjo un MRR de 0.170; al corregir títulos falsos y consultas ambiguas, la v3 llegó a 0.366 y el smoke test híbrido parcial a 0.402. En el camino: un COUNT(*) que miente, 32 documentos casi invisibles para el índice, y una poda de tokens que convirtió 21 horas de consultas en 34 minutos sin alterar las métricas.

Joaquín Bravo ContrerasLeer más

657,867 documentos después: el corpus completo en 3.5 GB, 6.7 millones de chunks, y los bugs que solo aparecen a escala real

Construimos las bases de producción sobre los 657,867 documentos del DOF: el corpus comprimido completo ocupa 3.52 GiB, el índice de chunks guarda 6.73 millones de recetas de 91 bytes, y el piloto de vectores binarios confirma que el índice vectorial cabrá en menos de 1 GiB. En el camino: un GROUP BY que consumió 35 GB de disco, un documento que se convertía en 21 GB de chunks, y una lección sobre paridad de resultados.

Joaquín Bravo ContrerasLeer más

Guardar 31 GB de texto en 3 GB (y recuperar cada byte): la prueba de concepto de almacenamiento

Cuarta entrega del benchmark: construimos el corpus comprimido sobre 10,000 documentos reales. sqlite-zstd comprime 10.9x con acceso aleatorio, los chunks se guardan como recetas de 110 bytes en lugar de texto, el índice de búsqueda por palabras resultó 15x más chico de lo temido, y la cuantización TurboQuant empata en calidad con los vectores completos. Todo cabe en ~11 GB.

Joaquín Bravo ContrerasLeer más