Vector database vs fine-tuning: cómo elegir la arquitectura RAG sin pagar de más en embeddings

Tu empresa quiere usar un LLM con su propia documentación. La conversación típica empieza con 'hay que hacer fine-tuning del modelo con nuestros datos' y termina 6 meses y $200k USD después con un modelo que sigue alucinando sobre los mismos temas que tenías en el primer intento. La alternativa pragmática — Retrieval Augmented Generation (RAG) con una base de datos vectorial — resuelve el 80% de los casos a una fracción del costo. Pero no todos los casos. Esta es la decisión real detrás de la decisión.

Qué resuelve cada arquitectura

Fine-tuning ajusta los pesos internos del modelo para que 'aprenda' el conocimiento de tus documentos. Una vez entrenado, el modelo responde sin consultar nada externo. Vector RAG deja el modelo intacto y, en cada pregunta, busca en una base vectorial los fragmentos más relevantes de tus documentos y los inyecta en el prompt. Son enfoques fundamentalmente distintos.

Cuándo conviene fine-tuning

Fine-tuning tiene sentido en tres escenarios muy específicos:

1. Cambiar el estilo o formato de respuesta. Por ejemplo, quieres que el modelo responda en un tono específico, con una estructura particular, o siguiendo un formato JSON estricto. Eso es factible con fine-tuning y muy difícil con RAG.
2. Enseñar al modelo un dominio completamente nuevo con datos sintéticos curados. Por ejemplo, entrenar un modelo de soporte técnico en jerga propietaria que no existe en los datos públicos de internet. Esto es lo que hacen los modelos verticales tipo BloombergGPT o los modelos de soporte de hyperscalers.
3. Reducir latencia a costa de calidad. Un modelo fine-tuneado más pequeño (7B parámetros) puede responder en 200 ms con precisión aceptable, mientras que RAG sobre un modelo grande (70B+) tarda 1-3 segundos por el retrieval + la generación.

Cuándo conviene vector RAG

RAG es la opción correcta en la mayoría de los casos comerciales:

1. Documentación que cambia con frecuencia. Con RAG actualizas la base vectorial cuando hay un documento nuevo y el modelo lo 've' inmediatamente. Con fine-tuning, hay que reentrenar, lo que toma semanas.
2. Necesitas atribución de fuentes. RAG puede devolver 'esta respuesta se basa en los párrafos X, Y, Z del documento Q' con citas. Fine-tuning pierde la atribución porque el conocimiento está en los pesos.
3. Documentación grande (>1M de páginas). El fine-tuning tiene un límite práctico de cuántos tokens puede absorber el modelo. RAG escala a millones de documentos sin problema.
4. Presupuesto y tiempo acotados. Un MVP de RAG se construye en 2-4 semanas con un equipo de 2 ingenieros. Un proyecto de fine-tuning tarda 3-6 meses y requiere data engineers, ML engineers y GPUs de entrenamiento.

Cómo elegir tu vector database

Una vez decidida la ruta RAG, el costo operativo depende en gran parte de la base vectorial. Hay tres familias principales:

• Postgres con pgvector. La opción más barata si ya tienes Postgres. Embeddings limitados por RAM (típicamente 1-10M de vectores prácticos). Costo: agregar una extensión + un poco más de RAM. Sin licenciamiento por query.
• Vector DBs dedicadas (Pinecone, Weaviate, Qdrant, Milvus). Optimizadas para búsqueda a escala. Manejan 100M-1B+ de vectores con latencia consistente. Costo: $0.10-0.50 USD por millón de vectores almacenados + costo por query. Requiere operar infraestructura adicional.
• Soluciones híbridas (pgvector + réplicas, OpenSearch, Elasticsearch con kNN). Si ya tienes OpenSearch o Elasticsearch, agregas retrieval vectorial sin nuevo componente operacional.

Cuándo el costo de embeddings te come el ROI

El costo oculto más común de RAG es el de generar embeddings. Para indexar 1M de documentos de 1 página, necesitas ~3M de embeddings (cada documento se corta en chunks de 200-500 tokens). A $0.10 USD por millón de tokens con OpenAI text-embedding-3-small, eso son ~$30 USD. Si lo haces con Cohere o con un modelo open-source en GPU propia, el costo baja a ~$5 USD o gratis en cómputo propio. Pero si tienes que reindexar todo cada vez que actualizas la documentación, el costo se multiplica. La optimización típica es: embeddings para contenido estable + reindexación incremental para contenido que cambia.

El error que mata proyectos RAG

El error más común no es de tecnología, es de expectativa. RAG no 'piensa' sobre los documentos: busca los más similares semánticamente y los inyecta en el prompt. Si tu pregunta requiere cruzar información entre 3 documentos distintos, o si la respuesta depende de un razonamiento lógico sobre los datos (no solo de búsqueda), RAG te va a decepcionar. La solución es descomponer el problema: retrieval para búsqueda factual + tool calling para razonamiento + LLM para la síntesis final. Eso ya no es RAG puro, es 'agentic RAG', y es su propio tema.

Recomendación práctica

Empieza con RAG en Postgres con pgvector. Si tienes menos de 1M de vectores, no necesitas nada más. Si crece, migra a Qdrant o Weaviate self-hosted. Evita Pinecone hasta que tengas un caso de uso validado y presupuesto aprobado, porque el costo por query escala mal cuando tienes adopción real. Y sobre todo: no hagas fine-tuning hasta que tengas evidencia de que RAG no resuelve tu caso. En el 80% de los proyectos, RAG es suficiente.

Fuentes

1. pgvector — GitHub repository (open source vector extension for Postgres) — https://github.com/pgvector/pgvector
2. Pinecone — RAG learning series — https://www.pinecone.io/learn/series/rag/
3. Weaviate — Developer documentation — https://weaviate.io/developers/weaviate