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.Salida esperada
Salida esperada
Paso 2 — Calcular incrustaciones
Incrusta todos los documentos y consultas usandomeetkai:functionary-es-mini.
Procesa en lotes para manejar el volumen.
Salida esperada
Salida esperada
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
Salida esperada
Salida esperada
Ejecutar consultas y medir latencia
Cada solicitud de búsqueda devuelve un camposearch_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.
Salida esperada
Salida esperada
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
Salida esperada
Salida esperada
Ejecutar consultas con búsqueda vectorial
La API de Tables también devuelvesearchTimeMs — la duración de la búsqueda en base de datos del lado del servidor.
Salida esperada
Salida esperada
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
Salida esperada
Salida esperada
- 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:- 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.
- 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) osearchTimeMs(Tables). Es tiempo puro de búsqueda vectorial/híbrida sin sobrecarga de red. - Respuesta extremo a extremo — lo que observa el cliente: viaje de red + enrutamiento de gateway + búsqueda en base de datos.
Comparación de tecnologías de almacenamiento
Ver también
- Indexar y buscar texto para la referencia completa de las APIs de Text Store y Tables.
- Archivos y almacenes vectoriales para la API compatible con vector store de OpenAI.
- Evaluación GraphRAG para benchmarking de recuperación multi-hop.