gpt-5 (4,096 dimensiones).
Resumen de resultados
Una consulta de recuperación pasa por dos etapas: inferencia de embedding (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 ambos.| Métrica | Text Store | Tables |
|---|---|---|
| NDCG@10 | 72.4 | 71.8 |
| Recall@10 | 83.1 | 82.6 |
| MRR@10 | 68.9 | 68.3 |
| Latencia | Text Store | Tables |
|---|---|---|
| Inferencia de embedding (por consulta) | 12 ms | 12 ms |
| Búsqueda en base de datos p50 (lado servidor) | 8 ms | 6 ms |
| Búsqueda en base de datos p95 (lado servidor) | 14 ms | 11 ms |
| Respuesta end-to-end p50 (red + embedding + búsqueda) | 45 ms | 38 ms |
| Respuesta end-to-end p95 (red + embedding + búsqueda) | 82 ms | 71 ms |
| Rendimiento de indexado (5,183 docs) | 182 docs/seg | 166 docs/seg |
search_time_ms en el cuerpo de la respuesta) y excluye la sobrecarga de red y la inferencia de embedding. El tiempo de respuesta end-to-end 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 embeddings
Genera embeddings para todos los documentos y consultas usandogpt-5.
Procesa en lotes para manejar el volumen.
Salida esperada
Salida esperada
Paso 3 — Evaluar el Text Store
Indexa los 5,183 documentos y 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 retorna un camposearch_time_ms — la duración de la búsqueda en base de datos del lado del servidor, excluyendo el viaje de red y cualquier procesamiento adicional.
Medimos tanto este tiempo del servidor como el tiempo total de respuesta observado por el cliente.
Salida esperada
Salida esperada
Paso 4 — Evaluar la API de Tables
Indexa el mismo corpus en un almacén Tables con esquema explícito e índice vectorial, y 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 retornasearchTimeMs — 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 la recuperación usando métricas estándar de BEIR: NDCG@10, Recall@10 y MRR@10.Imprimir resultados
Salida esperada
Salida esperada
- Inferencia de embedding es igual para ambos backends — ejecuta el mismo modelo.
- Búsqueda DB 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 end-to-end incluye viaje de red, sobrecarga de gateway y búsqueda en base de datos. La diferencia entre end-to-end y búsqueda DB es la sobrecarga.
Paso 6 — Limpieza
Interpretando los resultados
Contexto de precisión
El leaderboard de BEIR reporta NDCG@10 en SciFact como referencia:| Modelo | NDCG@10 |
|---|---|
| BM25 (baseline léxico) | ~66.5 |
| text-embedding-ada-002 | ~70–73 |
| text-embedding-3-large | ~74–76 |
| Estado del arte (2024) | ~78–80 |
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 qué tan rápido aparece el primer resultado relevante — importante para búsquedas orientadas al usuario.
- Text Store vs Tables: Text Store agrega búsqueda híbrida (vector + keyword) automáticamente. Tables te da control explícito sobre tipo de índice, métrica de distancia y filtros.
Leyendo el desglose de latencia
Una consulta de recuperación tiene tres componentes de latencia:- Inferencia de embedding — 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 tarda en 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 end-to-end — lo que observa el cliente: viaje de red + enrutamiento del gateway + búsqueda en base de datos.
Comparación de tecnologías de almacenamiento
| Text Store | Tables | |
|---|---|---|
| Configuración | Cero configuración — solo nombre + dimensión | Esquema explícito, tipos de campo, índices |
| Búsqueda | Híbrida (vector + full-text) automática | Composición de operaciones: vector_search, FTS, filtro |
| Mejor para | Prototipado RAG rápido, búsqueda híbrida lista para usar | Esquemas personalizados, búsqueda filtrada, estrategias multi-índice |
| Tipos de índice | Automático | IVF_FLAT, IVF_PQ, IVF_HNSW_PQ, IVF_HNSW_SQ |
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.