La primera pregunta al montar RAG suele ser qué base vectorial usar. Para la mayoría de organizaciones la respuesta es más aburrida de lo esperado.
01. Probablemente basta pgvector
Si ya usa PostgreSQL, pgvector cubre con holgura la mayoría de escenarios empresariales y maneja decenas de millones de vectores sin problema. Conserva sus copias de seguridad y sus permisos y no opera un sistema extra.
02. La opción gestionada
Si no quiere carga operativa, existen servicios gestionados; la instalación y el escalado no son cosa suya. A cambio los datos quedan fuera y el coste crece con el volumen.
03. Escala muy grande
Si necesita miles de millones de vectores en infraestructura propia, se pasa a sistemas diseñados para esa escala. Caen en esa franja muchas menos organizaciones de las que creen.
04. La alternativa del buscador
Si ya tiene una plataforma de búsqueda empresarial, la mayoría admite ya búsqueda vectorial. Construir sobre la inversión existente sin añadir componentes puede ser la vía de menor fricción.
05. Qué decide de verdad la calidad
La elección de base no está entre los tres factores que más determinan la calidad de RAG. La estrategia de fragmentación, el modelo de embeddings y el diseño de búsqueda pesan mucho más. Dedicar semanas aquí es invertir en el sitio equivocado.
06. Manténgala sustituible
Abstraiga la capa de búsqueda de su aplicación. Así, cambiar el almacén cuando crezca el volumen no significará reescribir la aplicación.