Benchmark de Qdrant Supernova: el recall de FineWeb-10B no es relevancia

Qué puede demostrar realmente un benchmark de Qdrant Supernova

Un benchmark de Qdrant Supernova puede decirte si un sistema vectorial reproduce una clasificación de vecinos definida bajo condiciones conocidas. Eso es útil. También es más estrecho de lo que muchos equipos quieren que sea.

El recall de vecinos exactos no es relevancia humana, y no es corrección de respuestas. Con FineWeb-10B, el trabajo serio empieza antes de cualquier comparación de bases de datos. Hay que definir la carga de trabajo, preservar su identidad y hacer que la regla de puntuación sea auditable. De lo contrario, el benchmark se convierte en una forma pulida de comparar experimentos que no coinciden.

Este es el problema práctico. Un sistema de recuperación puede devolver los pasajes más cercanos al embedding de una pregunta y aun así omitir el pasaje que responde a la pregunta. La clasificación puede ser fiel al espacio de embeddings mientras la aplicación da al usuario una respuesta débil. No es una salvedad menor. Es la línea entre un benchmark vectorial y una evaluación RAG.

Fidelidad de vecinos, relevancia humana y corrección de respuestas

Trátalos como objetivos distintos.

El recall de vecinos mide la concordancia con una referencia exacta para una representación, métrica, filtro y corte especificados. La relevancia humana pregunta si el material recuperado ayuda con la necesidad de información. La corrección de respuestas pregunta si la respuesta final es precisa y está respaldada por la evidencia recuperada.

El anuncio de lanzamiento de Qdrant informa 10.07B vectores densos y 10.07B vectores dispersos. La tarjeta de FineWeb-10B describe referencias exactas top-1000 y 100,000 consultas densas, además de conjuntos separados de consultas dispersas y filtradas. Esas cifras son reportadas por el editor. No son mediciones de Optijara.

Por qué esto es un método, no una tabla de clasificación de bases de datos

Optijara no ha descargado el corpus completo ni ha ejecutado un benchmark completo o por fragmentos para este artículo. Este es un diseño experimental, no un informe de resultados.

El anuncio da la escala. La tarjeta del conjunto de datos define los datos. La guía de recall explica la semántica de puntuación. Este artículo conecta esas fuentes en experimentos acotados y un plan separado de validación en producción. No afirma originalidad exhaustiva. Para la pregunta relacionada sobre selección de modelos, consulta la prueba de aceptación de recuperación con embeddings.

Relaciona los módulos de Supernova con los artefactos del benchmark

La tabla de módulos

El repositorio de Supernova y la documentación de módulos enlazada describen este ciclo de vida. La clave es tratar cada punto de control como evidencia que se debe conservar, no como un comando que ejecutaste una vez y olvidaste.

Fija la documentación antes de copiar comandos

La página principal de documentación y el repositorio exponen distintas generaciones de comandos. Elige un commit, usa esa documentación y luego inspecciona la ayuda de la CLI instalada. La lista de instalación del README raíz no demuestra que nova-bf esté instalado. Ningún comando ejecutable de este artículo ha sido probado mediante instalación.

El soporte de backend también requiere cuidado. La guía de carga documenta el comportamiento de reanudación específico de Qdrant. La guía de recall documenta el informe de empates específico de Qdrant. El soporte para consultar varias bases de datos no significa que todas las funciones se comporten igual en todas partes.

La Benchmark Fidelity Ladder: construye primero el experimento válido más pequeño

La Benchmark Fidelity Ladder es el método editorial propuesto por Optijara, no un estándar de benchmark establecido. Sus peldaños son un fragmento acotado, una referencia exacta del fragmento, cargas de trabajo coincidentes, condiciones operativas comparables y consultas de producción juzgadas por separado.

La versión con criterio es simple: no escales un mal experimento. Un benchmark pequeño con identidad limpia supera a un benchmark grande con uniones ocultas, aritmética desconocida, estado de caché vago y puntuación poco clara.

Acota el corpus y preserva su identidad

Empieza con una lista de archivos inmutable y un conjunto fijo de consultas. No dependas de lo que un lector en streaming encuentre primero. Registra IDs de origen preservados, semillas de selección, dimensiones, normalización, dtype, métrica de distancia, corte solicitado, tokenizer, reglas de filtro y política de empates.

Toma huellas del corpus, los vectores de consulta y las configuraciones por separado. Las sumas de comprobación del texto de consulta no establecen igualdad de embeddings, como advierte la tarjeta de FineWeb-10B. Una consulta puede tener el mismo texto y un vector distinto si cambió la revisión del modelo, el tokenizer, la normalización o el código remoto.

El análisis de reproducibilidad de OpenBind cubre la brecha relacionada entre una etiqueta de benchmark y la validez en el mundo real. Aquí, el manifiesto tiene una sola tarea: hacer recuperable el corpus realmente buscado.

Recalcula la referencia exacta para ese fragmento

No filtres una lista publicada top-1000 de corpus completo a los IDs presentes en tu fragmento y la llames verdad base exacta del fragmento. Ese atajo pierde vecinos que son válidos dentro del fragmento pero nunca aparecieron en la lista global truncada.

Recalcula la referencia sobre exactamente el corpus y los vectores de consulta seleccionados, usando la métrica y los filtros elegidos. Mantén la configuración de generación junto a la referencia. Un archivo llamado ground truth no basta. Necesitas saber cómo se produjeron sus puntuaciones.

Haz coincidir las cargas de trabajo antes de añadir preguntas de producción

Usa esta lista de implementación antes de aumentar la escala. Cada fila debe dejar un artefacto inspeccionable.

Diseña una matriz de pruebas que separe recall, relevancia y operaciones

Experimentos densos, dispersos y filtrados de FineWeb

La tarjeta de FineWeb-10B especifica vectores densos de norma unitaria, que admiten ranking por coseno o producto punto equivalente. También especifica pesos dispersos no normalizados evaluados con producto punto. Preserva esas condiciones. Las clasificaciones exactas densas y dispersas independientes no son verdad base para una regla de fusión híbrida.

La guía de fuerza bruta define la coincidencia de texto como comportamiento AND de tokens de palabras en minúsculas, no como búsqueda de frases. Haz coincidir tokenización, lógica booleana, límites de fechas, manejo de nulos y semántica de pertenencia. Un campo llamado keyword_phrase no anula la operación documentada.

Extensión multi-vector opcional con corpus coincidente

PubMed-MV suministra representaciones densas, dispersas y de vectores de tokens sobre los mismos resúmenes. Usa su definición documentada de MaxSim en un experimento acotado por separado. No compares directamente sus resultados principales con FineWeb ni leas la fidelidad de vecinos como relevancia clínica.

Coyo-VE es otra carga de trabajo distinta. Su tarjeta especifica embeddings y subtítulos, no bytes de imagen. Ningún conjunto de datos complementario permite omitir la identidad de corpus, consulta y representación.

Condiciones justas de carga y consulta

Fija hardware, versiones de backend, replicación, cuantización, configuración de índice, índices de filtro, concurrencia y mezcla de consultas. Define explícitamente protocolos de caché fría y caliente. Una repetición no especificada no es una política de caché representativa.

Si un modelo de lenguaje local consume los pasajes recuperados, mantén su dispositivo y evaluación de runtime separados de los tiempos del motor vectorial. La prueba de realidad de despliegue de MiniCPM5-2B cubre esa pregunta adyacente de despliegue, no el rendimiento de búsqueda de FineWeb.

La guía de carga distingue la indexación posterior a la subida de la contabilidad de ingesta e indexación en línea de Elasticsearch. Por eso, index_seconds por sí solo no es un reloj justo entre backends. Mide la ruta completa desde la configuración hasta la misma condición de listo para consultar, conservando las fases específicas de cada backend.

Usa un plan de medición que mantenga visibles denominadores y fallos:

Para un experimento RAG respaldado por Claude, congela el identificador del modelo, prompt, orden de pasajes recuperados y ajustes de generación. Guarda IDs de pasaje y URLs de origen con cada respuesta. Juzga si las citas respaldan las afirmaciones y si se respondió la excepción solicitada. Registra la latencia de recuperación y generación por separado. Etiqueta esto como un experimento de aplicación, no como un resultado de nova-storm.

En qué se equivocan los equipos al medir el recall de nova-storm

Corte incorrecto, listas cortas y tratamiento desigual de empates

Encontrar un ID devuelto de top-10 en cualquier lugar de una referencia top-1000 no es recall@10. Recall@10 compara el ranking devuelto con el corte exacto correspondiente. La guía actual de recall trunca la verdad base más profunda a top_k e identifica la semántica modificada con schema_version: 2. Concilia definiciones antes de combinar trazas antiguas y actuales.

Informa las consultas de referencia corta por separado de las consultas de profundidad completa y especifica la política de denominador. Conserva los casos sin resultados como pruebas operativas. Una media combinada sin tamaños de grupo oculta qué carga de trabajo se evaluó realmente.

También separa el recall de IDs exactos de los límites tolerantes a empates. Comparar el resultado ajustado por empates de Qdrant con el resultado solo exacto de otro backend cambia la regla de puntuación. No es simplemente una diferencia de base de datos.

Errores de precisión y carga disfrazados de diferencias de búsqueda

Hay un conflicto de procedencia no resuelto: la tarjeta de FineWeb-10B describe aritmética bfloat16 para la verdad base, mientras la documentación actual de recall dice que nova-bf no tiene modo de cómputo bf16/fp16. Solicita la revisión de tiempo de generación y el manifiesto aritmético. No inventes una conciliación ni diagnostiques un bug de base de datos a partir de esta discrepancia.

Distingue IDs duplicados, texto duplicado, embeddings duplicados y puntuaciones empatadas. La tarjeta ascendente de FineWeb describe deduplicación a nivel de rastreo, no eliminación global garantizada de duplicados.

Antes de ajustar un índice, inspecciona archivos omitidos, formas de ID, identidad de vectores de consulta, métrica y filtrado. La tarjeta de FineWeb-10B señala formas distintas de identificadores de corpus y referencia. Una unión fallida sin explicar es un bloqueo de integridad de datos, no una oportunidad de ajuste ANN.

Salvedades, derechos de consulta y criterios de parada de recursos

Revisa por separado las licencias de código, corpus, consulta y modelo

El repositorio de Supernova declara Apache-2.0. FineWeb ascendente especifica ODC-By y términos adicionales de Common Crawl. La tarjeta del modelo gte-multilingual-base declara Apache-2.0 e incluye ejemplos dependientes de código remoto. Nada de esto otorga permiso general para toda entrada.

Los términos de MS MARCO de Microsoft especifican uso de investigación no comercial. Revisa los derechos de consulta antes de adoptar la carga de trabajo publicada. Consultas propias permitidas de primera parte crean un experimento etiquetado por separado, no un benchmark oficial sin cambios. Los conjuntos de datos complementarios necesitan su propia revisión de derechos ascendentes.

Fija modelo, tokenizer y código remoto. Observar una revisión actual del repositorio no prueba qué revisión generó los artefactos publicados. La procedencia de generación ausente limita las afirmaciones de reproducibilidad incluso cuando los archivos se pueden descargar públicamente.

Detente antes de que una muestra inválida se convierta en una ejecución cara

Define techos específicos del proyecto para gasto, tiempo transcurrido, bytes descargados, disco, RAM del host y memoria de GPU antes de la ejecución. Detente al alcanzar un techo, ante fallo persistente de carga, unión de IDs fallida, comportamiento de filtro divergente o discrepancia de referencia sin explicar. Guarda el motivo de parada. No reduzcas la carga de trabajo en silencio manteniendo la etiqueta original.

Un fragmento con caché caliente no puede establecer coste de corpus completo ni latencia de cola. Evaluaciones posteriores deben incluir esfuerzo de implementación, transferencia, construcción de índices, variación de proveedor y hardware, estado o obsolescencia de caché, calidad de evaluación y operaciones continuas. Minimiza datos privados de consulta y mantenlos fuera de artefactos públicos.

Publica un registro de reproducibilidad, no un ganador

Un resumen compacto legible por máquina

Este resumen describe el experimento propuesto. Las observaciones nulas son deliberadas: no se realizó ningún benchmark ni medición de coste.

{
  "framework": "Benchmark Fidelity Ladder",
  "scope": "proposed_bounded_experiment",
  "fullCorpusRun": false,
  "benchmarkExecuted": false,
  "recomputeGroundTruthForShard": true,
  "neighborRecallIsHumanRelevance": false,
  "humanRelevanceIsAnswerCorrectness": false,
  "observedRecall": null,
  "observedP95Ms": null,
  "observedCost": null
}

Entrega juntos el manifiesto inmutable, la configuración versionada, la conciliación de carga, las marcas de tiempo de disponibilidad y las trazas de solicitudes. Incluye semántica de recall, diagnósticos de empates, grupos de consultas, distribuciones de latencia, fallos, contabilidad de recursos y juicios humanos separados.

Qué probar después

Primero, establece una referencia acotada confiable. Luego compara condiciones operativas coincidentes. Después, pregunta si las consultas de producción permitidas recuperan evidencia útil y si las respuestas posteriores usan esa evidencia correctamente. Una muestra válida justifica el siguiente experimento. No justifica una afirmación de rendimiento de corpus completo.