Pg_vectorize: búsqueda vectorial y RAG en Postgres

Artículo original ↗ Discusión en Hacker News ↗

Postgres se está impulsando cada vez más hacia el papel de base de datos vectorial, con proyectos como pg_vectorize que se apoyan en pgvector para añadir APIs de alto nivel para embeddings, búsqueda vectorial y generación aumentada por recuperación (RAG) directamente dentro de la base de datos. Quienes comentan comparten experiencias reales con pgvector a escala, lo comparan con servicios especializados como Pinecone o Meilisearch, y profundizan en cuestiones prácticas como estrategias de chunking, recall, ajuste de rendimiento y control de costes. Hay entusiasmo por consolidar la búsqueda y la recuperación en Postgres, pero también preocupación por ocultar llamadas complejas a LLM dentro de extensiones de la base de datos y escepticismo sobre cuán fiablemente RAG mejora los resultados frente a usar simplemente ventanas de contexto más grandes o modelos ajustados.

Reacción general a pg_vectorize y Postgres para vectores

  • Muchos ven con buenos ojos impulsar Postgres como plataforma de vectores/RAG, considerándolo una forma de empoderar a los desarrolladores frente a productos propietarios de “vector DB”.
  • pg_vectorize se percibe como un envoltorio de alto nivel y conveniente sobre pgvector, que gestiona la generación de embeddings, la administración de índices y la orquestación de consultas.
  • Algunos prefieren usar pgvector directamente para conservar el control y evitar complejidades ocultas.

Costes, alojamiento y arquitectura

  • RAG puede ser caro: pagas una vez para incrustar el corpus y luego por cada consulta por los embeddings y los tokens del LLM.
  • Los modelos de embeddings autoalojados (y, con el tiempo, también los modelos de chat) se destacan como una forma de controlar costes y mantener los datos privados, aunque añaden complejidad operativa.
  • Hay debate sobre si el embedding + retrieval deberían vivir dentro de la base de datos; a algunos les gusta la arquitectura más simple, mientras que otros prefieren firmemente una separación limpia y que no haya llamadas de red salientes desde Postgres.

pgvector a escala

  • Hay múltiples informes de pgvector funcionando en producción, incluyendo decenas a cientos de millones de filas.
  • Fortalezas: código abierto, indexación transparente, integración con datos relacionales y buena observabilidad.
  • Puntos débiles: fuerte dependencia de vacuum, construcciones de índices HNSW grandes/lentas, soporte débil para ANN filtrado y algo de fricción en la API (por ejemplo, Python + numpy).

Eficacia de RAG y alternativas

  • Experiencias mixtas: algunos consideran que el RAG ingenuo es “malo” o decepcionante; otros reportan resultados excelentes, especialmente para PDFs internos y grandes corpus técnicos.
  • Los sistemas más sólidos combinan RAG con estructura de dominio (por ejemplo, registros de soporte técnico, grafos de conocimiento, refuerzo mediante señales de expertos), logrando una recuperación mucho mayor que el “RAG puramente vectorial”.
  • Algunos sugieren que el uso directo de LLM con grandes ventanas de contexto puede igualar o superar a RAG en ciertos dominios, pero otros sostienen que RAG sigue siendo más barato, rápido y escalable para corpus grandes.

Chunking y estrategias de recuperación

  • El chunking simple de tamaño fijo suele rendir peor; varios comentarios insisten en:
    • Chunking jerárquico / semántico (por encabezados, secciones o clústeres de contexto).
    • Uso de modelos pequeños para realizar chunking semántico y resúmenes con conciencia del contexto.
    • Enfoques de “context cluster” / basados en árboles y resúmenes jerárquicos (por ejemplo, ideas tipo RAPTOR).
    • Selección cuidadosa de qué chunks encajan en el contexto (optimización estilo knapsack).
  • Algunos proyectos usan embeddings a nivel de frase seguidos de clustering e indexación de centroides.

Conceptos y malentendidos sobre RAG

  • Se aclara que RAG no es solo “LLM delante de una búsqueda”, sino generación con LLM condicionada por contexto recuperado y ordenado por vectores.
  • Varios señalan que la “R” (retrieval) es un problema difícil, y que la similitud vectorial es solo una parte; a menudo se necesita recuperación híbrida (palabras clave, estructura, vectores).

Comparaciones, herramientas y alternativas

  • pg_vectorize vs PostgresML: pg_vectorize descarga los modelos a servicios externos y se centra en embeddings/RAG; PostgresML ejecuta modelos en el host de la base de datos y admite ML más amplio (por ejemplo, entrenamiento supervisado).
  • Alternativas sugeridas para casos de uso más pequeños o distintos: sqlite con extensiones (sqlite-vss), DuckDB, Meilisearch, Elasticsearch/OpenSearch y bases de datos vectoriales dedicadas.
  • Algunos argumentan que Postgres es “suficientemente bueno” y atractivo porque ya está en la pila; otros prefieren motores de búsqueda especializados para cargas de trabajo grandes y complejas.