Saltar al contenido principal
Esta guía evalúa las APIs de búsqueda de MKA1 frente a un conjunto de datos estándar de recuperación de información. Demuestra RAG con múltiples tecnologías de almacenamiento (Text Store y Tables) y procesamiento de documentos a gran escala — indexando miles de documentos, ejecutando consultas 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 generan con meetkai:functionary-es-mini (4,096 dimensiones).

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 (search_time_ms en el cuerpo de la respuesta) 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. El resto de esta guía muestra cómo se producen estos números, paso a paso.

Configuración

Instala las dependencias y carga las variables de entorno.

Paso 1 — Cargar el conjunto de datos SciFact

Descarga el corpus, las consultas y los juicios de relevancia desde HuggingFace.

Paso 2 — Calcular incrustaciones

Incrusta todos los documentos y consultas usando meetkai:functionary-es-mini. Procesa en lotes para manejar el volumen.

Paso 3 — Evaluar el Text Store

Indexa los 5,183 documentos, luego ejecuta las 300 consultas. Mide el rendimiento de indexado y la latencia de búsqueda.

Indexar documentos

Ejecutar consultas y medir latencia

Cada solicitud de búsqueda devuelve un campo search_time_ms — la duración de la búsqueda en base de datos del lado del servidor, excluyendo el viaje de ida y vuelta de red y cualquier procesamiento adicional. Medimos tanto este tiempo del servidor como el tiempo de respuesta extremo a extremo observado por el cliente.
La diferencia entre la latencia extremo a extremo y la de base de datos es el viaje de ida y vuelta de red y la sobrecarga del gateway.

Paso 4 — Evaluar la API de Tables

Indexa el mismo corpus en un almacén de Tables con esquema explícito e índice vectorial, luego ejecuta las mismas consultas.

Crear tabla e indexar documentos

Ejecutar consultas con búsqueda vectorial

La API de Tables también devuelve searchTimeMs — la duración de la búsqueda en base de datos del lado del servidor.

Paso 5 — Calcular métricas de precisión

Evalúa la calidad de recuperación usando métricas estándar de BEIR: NDCG@10, Recall@10 y MRR@10.

Imprimir resultados

  • Inferencia de incrustación es la misma para ambos backends — ejecuta el mismo modelo.
  • Búsqueda BD es el tiempo puro de base de datos reportado por el servidor (search_time_ms / searchTimeMs). Aquí es donde difieren Text Store y Tables — Text Store ejecuta búsqueda híbrida (vector + FTS), Tables ejecuta búsqueda vectorial pura.
  • Respuesta extremo a extremo incluye viaje de red, sobrecarga de gateway y búsqueda en base de datos. La diferencia entre extremo a extremo y BD es la sobrecarga.

Paso 6 — Limpieza

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.
  • Text Store vs Tables: Text Store agrega búsqueda híbrida (vector + palabra clave) automáticamente. Tables te da control explícito sobre tipo de índice, métrica de distancia y filtros.

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 el backend de almacenamiento.
  2. Búsqueda en base de datos — el tiempo que el motor de búsqueda dedica a encontrar los vecinos más cercanos. Reportado por el servidor en search_time_ms (Text Store) o searchTimeMs (Tables). Es tiempo puro de búsqueda vectorial/híbrida 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. Si la búsqueda en base de datos es alta, considera un tipo de índice diferente (por ejemplo, IVF_HNSW_SQ para búsqueda aproximada más rápida).

Comparación de tecnologías de almacenamiento

Ver también