¿Su app RAG precisa una base de datos vectorial aparte? Databricks midió la búsqueda en Postgres a 4M pasajes
Un ingeniero de Databricks midió la búsqueda híbrida de vectores y palabras clave en Lakebase Postgres con una app real y corpus público. Los números ayudan a decidir dónde debe vivir la recuperación.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Muchos proyectos empresariales de RAG comienzan con una decisión de arquitectura que nadie examinó: añadir una base de datos vectorial. Los datos de la aplicación permanecen en su base de datos transaccional, los embeddings van a un almacén separado y un pipeline de sincronización los une. Eso son tres sistemas, dos copias de los datos y un problema de frescura antes de que se responda la primera pregunta.
Una publicación de ingeniería de Databricks del 15 de octubre prueba la alternativa con números. Philipp Tiefenbacher dimensionó la búsqueda híbrida, vectorial más búsqueda por palabras clave BM25 fusionadas con Reciprocal Rank Fusion, dentro de Lakebase Postgres, con los datos de la app, el índice vectorial y el índice de palabras clave en una sola instancia. Usó una app interna con unas 23,000 filas de diapositivas y pasajes públicos de MIRACL en inglés en 1, 2 y 4 millones de filas, con índices vectoriales de 5.8, 11.5 y 23 GB. Lakebase Search pasó a disponibilidad general (GA) en septiembre; este es un estudio de medición, no un lanzamiento.
Lo que dicen las mediciones
Cuatro hallazgos merecen tenerse en cuenta en cualquier revisión de diseño, con la advertencia de que provienen de un solo corpus, un solo modelo de embeddings y mezclas de consultas sintéticas:
- Dimensione la caché a partir del índice vectorial, no del número de filas. La relación entre caché y tamaño del índice predijo la tasa de aciertos en distintos tamaños de corpus: 45% con una relación de 0.07, 86% con 0.57 y 97% con 1.14. La latencia vectorial mediana en caliente cayó de 187 ms a 4 ms a medida que aumentaba la relación.
- Menos candidatos cuestan poco. Reducir el grupo de candidatos de 1,000 a 200 mantuvo un 90.5% de solapamiento en los 10 mejores resultados, tocó aproximadamente un tercio de las páginas y redujo la latencia en frío de 740 ms a 387 ms. El solapamiento con el grupo más grande no es lo mismo que la calidad de recuperación, pero es una cota útil.
- El recall es una configuración. El índice predeterminado dio un recall@10 de aproximadamente 0.74 a 0.75; un modo de construcción de calidad lo elevó a 0.80, y a 0.97 con más sondas, a costa de latencia.
- El cuello de botella se mueve. Hasta aproximadamente 4 unidades de cómputo la base de datos era el límite; por encima de 8, lo eran los workers de la app. El pooling de conexiones con 50 usuarios casi duplicó el rendimiento y redujo la latencia p95 de 2.4 a 0.7 segundos.
En cuanto al costo, una prueba de carga de 14 minutos sirvió 109,602 solicitudes por $0.13, de los cuales $0.02 fueron cómputo de Lakebase. Eso cubre una prueba corta, no un mes de producción; el autor recomienda mantener un mínimo siempre activo, de unos $31 a $40 al mes a precio de lista, para evitar arranques en frío de alrededor de un segundo.
Un marco para decidir dónde vive la recuperación
El estudio no compara Lakebase con bases de datos vectoriales dedicadas. Sí hace que la decisión sea lo suficientemente concreta como para enmarcarla:
| Apunta a buscar en la base de datos de la app | Apunta a un servicio aparte | |
|---|---|---|
| Frescura | Los resultados deben reflejar cada escritura de inmediato | Minutos de retraso son aceptables |
| Dónde vive el corpus | En las tablas propias de la app | En muchas fuentes, compartidas por muchas apps |
| Escala | El índice cabe en la memoria que está dispuesto a pagar | El índice supera con creces la caché de una instancia |
| Permisos | Reglas a nivel de fila ya en la base de datos | Un modelo de permisos separado por fuente |
| Equipo | Sin apetito por operar otro sistema | Un equipo de plataforma ya ejecuta la recuperación |
La fila de permisos es la que los equipos subestiman. Cuando la búsqueda se ejecuta en la base de datos que ya aplica quién puede ver qué filas, la recuperación hereda esas reglas. Un índice separado necesita su propia copia del modelo de permisos, mantenida en sincronía, y cada sincronización es una oportunidad de filtración. Esa es la pregunta de custodia aplicada a los embeddings: cada copia es un nuevo lugar donde viven los datos.
Mida antes de elegir
El consejo del propio autor es la parte más transferible: mida el recall con sus propios datos, porque depende del corpus y del modelo de embeddings. Eso se hace eco de nuestro argumento de que la recuperación debe medirse como un sistema propio, con sus propias métricas, antes de que alguien debata qué producto la aloja.
Una secuencia práctica para una nueva aplicación RAG: comience con la búsqueda donde ya viven los datos, construya un pequeño conjunto de evaluación a partir de preguntas reales, mida el recall y la latencia con el tamaño de corpus esperado, y mueva la recuperación a un servicio aparte solo cuando un requisito específico en el lado derecho de la tabla lo fuerce. El sistema adicional debe ser una conclusión, no una suposición inicial.