Skip to main content
Este informe evalúa el motor de recuperación de MKA1 frente a un conjunto de datos estándar de recuperación de información. Demuestra recuperación de calidad RAG con un alto volumen de documentos — indexando miles de documentos, ejecutando cientos de consultas etiquetadas y midiendo precisión y latencia en cada etapa del flujo. El benchmark utiliza SciFact de la suite BEIR — 5,183 resúmenes científicos con 300 consultas de prueba y juicios de relevancia anotados por humanos. Todas las incrustaciones se generaron con auto (4,096 dimensiones). Se midieron dos configuraciones del motor de recuperación:
  • Almacén híbrido (“Text Store”): almacenamiento sin configuración con recuperación híbrida automática — similitud vectorial combinada con búsqueda de texto completo.
  • Tabla tipada (“Tables”): un esquema explícito (ID de documento, contenido, vector de 4,096 dimensiones) con búsqueda puramente vectorial bajo distancia coseno.
Las aplicaciones acceden a este motor a través de los almacenes vectoriales de la plataforma, que añaden encima la ingesta de archivos, la fragmentación, el aislamiento por tenant y la medición de uso. Los números siguientes miden el motor de recuperación en sí.

​
Resumen de resultados

Una consulta de recuperación pasa por dos etapas: inferencia de incrustación (convertir el texto de la consulta en un vector) y búsqueda en la base de datos (encontrar los vectores más cercanos en el almacén). El tiempo total de respuesta es la suma de ambas. La latencia de búsqueda en base de datos es reportada por el propio servidor y excluye la sobrecarga de red y la inferencia de incrustación. El tiempo de respuesta extremo a extremo incluye todo lo que mediría un cliente.

​
Metodología

Conjunto de datos. El corpus completo de SciFact y su partición de prueba: 5,183 resúmenes científicos, 300 consultas de afirmaciones científicas y los juicios de relevancia binarios oficiales (las 300 consultas tienen etiquetas). Incrustaciones. Cada documento (título + resumen) y cada consulta se incrustó con el modelo de incrustación auto (4,096 dimensiones) a través de la API de embeddings de la plataforma, en lotes de 64. La incrustación del corpus promedió 8.2 ms por documento; la inferencia de incrustación de consultas se midió en 12 ms por consulta. Indexado. El mismo corpus y las mismas incrustaciones precalculadas se indexaron en ambas configuraciones del motor, en lotes de 100 documentos. El rendimiento de indexado se midió sobre la ejecución completa de 5,183 documentos: 182 docs/seg para el almacén híbrido y 166 docs/seg para la tabla tipada. Ejecución de consultas. Las 300 consultas se ejecutaron contra cada configuración, recuperando los 10 mejores resultados. Se registraron dos latencias por consulta: el tiempo de búsqueda en base de datos reportado por el servidor (tiempo puro del motor, sin red) y el tiempo de respuesta extremo a extremo observado por el cliente. Las tablas anteriores reportan p50/p95 sobre las 300 consultas. Puntuación. Los rankings recuperados se puntuaron frente a los juicios de relevancia con las métricas estándar de BEIR — NDCG@10, Recall@10 y MRR@10 — calculadas por consulta y promediadas sobre todas las consultas con etiquetas.

​
Interpretando los resultados

​
Contexto de precisión

El leaderboard de BEIR reporta NDCG@10 en SciFact como referencia: Puntajes NDCG@10 en el rango 70–76 indican una calidad de recuperación fuerte, competitiva con los principales modelos de incrustación.

​
Qué observar

  • NDCG@10 es la métrica principal. Penaliza documentos relevantes que aparecen en posiciones bajas.
  • Recall@10 mide cuántos documentos relevantes aparecen en el top 10 — importante para pipelines RAG donde la generación depende de la recuperación completa.
  • MRR@10 mide cuán rápido aparece el primer resultado relevante — importante para búsquedas de cara al usuario.
  • Híbrida vs vectorial pura: la configuración híbrida combina automáticamente la similitud vectorial con la coincidencia léxica de texto completo; la configuración puramente vectorial cambia eso por una latencia de búsqueda ligeramente menor. Su precisión en este conjunto de datos es casi idéntica — la ventaja de la recuperación híbrida crece en corpus donde los términos exactos importan (nombres, códigos, tokens raros).

​
Cómo leer el desglose de latencia

Una consulta de recuperación tiene tres componentes de latencia:
  1. Inferencia de incrustación — el tiempo para convertir el texto de la consulta en un vector. Es inferencia de modelo y es igual sin importar la configuración de almacenamiento.
  2. Búsqueda en base de datos — el tiempo que el motor dedica a encontrar los vectores más cercanos, según lo reporta el servidor. Es tiempo puro de búsqueda sin sobrecarga de red.
  3. Respuesta extremo a extremo — lo que observa el cliente: viaje de red + enrutamiento de gateway + búsqueda en base de datos.
Si la latencia extremo a extremo es alta pero la búsqueda en base de datos es rápida, el cuello de botella es la red o el gateway. La búsqueda en base de datos en sí puede ajustarse aún más con índices vectoriales aproximados cuando los corpus crecen mucho más.

​
Ver también

  • Archivos y almacenes vectoriales — la superficie de recuperación de la plataforma sobre la que construyen las aplicaciones, incluyendo ingesta de archivos, fragmentación y búsqueda.
  • Evaluación de GraphRAG — recuperación consciente de grafos evaluada frente a RAG plano en preguntas multi-hop.