"Queremos algo como ChatGPT pero que responda con nuestros propios manuales y contratos." Es uno de los pedidos más frecuentes que recibimos en 2026 y casi siempre se resuelve con RAG, retrieval-augmented generation. Lo que la mayoría de los proveedores "enterprise" no te dice es que hacer RAG bien no requiere ni un vector database fancy ni una suscripción de 2.000 dólares por mes. Para el 90% de las PyMEs, un stack de piezas simples resuelve el problema con costo casi despreciable.
Este post describe cómo pensamos RAG para clientes que no están a escala de Google.
Qué es RAG en tres líneas
Cuando le preguntás algo a un LLM, contesta con lo que sabe de su entrenamiento, que puede o no incluir tu información. RAG le permite al LLM buscar en tus documentos en el momento de la consulta y basar la respuesta en lo que encuentra. El flujo es: pregunta del usuario → buscar fragmentos relevantes en tu repositorio → pasárselos al LLM junto con la pregunta → el LLM responde citando esos fragmentos.
El valor no es que el modelo sea "más inteligente". Es que la respuesta se apoya en tu verdad, no en lo que el modelo asumió durante entrenamiento.
Por qué casi ninguna PyME lo necesita a escala
Cuando leés papers de RAG en 2026, o cuando te muestran una demo de algún proveedor enterprise, asumen volúmenes de millones de documentos, queries por segundo, actualizaciones constantes. Para eso necesitás infraestructura seria: vector databases dedicados, clusters distribuidos, pipelines de reindexación.
La realidad de la PyME típica: 500 a 5.000 documentos. Unas cuantas queries por día, a lo sumo unas decenas. Los documentos se actualizan de manera esporádica. A esa escala, la infraestructura "enterprise" es infraestructura disfrazada de problema; el problema real está en otro lado.
Nuestra regla: por debajo de 10.000 documentos, Postgres con la extensión pgvector alcanza y sobra. Por arriba de 100.000 documentos empezá a evaluar Qdrant, Weaviate o Pinecone. En el medio, depende del patrón de queries.
Stack mínimo que funciona
Para el caso típico (PyME con ~2.000 documentos PDF/DOCX, consultas internas de empleados):
- Postgres como base de datos principal (el cliente probablemente ya tiene uno).
- pgvector como extensión para almacenar y buscar embeddings.
- OpenAI text-embedding-3-small o un modelo equivalente para generar embeddings.
- n8n o un script simple para orquestar ingestión y query.
- GPT-4o-mini o Claude Haiku como modelo final de respuesta.
Esto corre en el VPS que ya tenés. El costo mensual real suele ser menos de 10 USD si el volumen de consultas es razonable.
Las 4 decisiones que importan
Cualquier tutorial básico de RAG se centra en el happy path. Lo que distingue un RAG que funciona de uno que "responde cosas raras" son cuatro decisiones que casi nadie explica.
1. Chunking (cómo partís los documentos)
Los LLMs no pueden buscar sobre documentos enteros: tenés que partirlos en fragmentos (chunks) y indexar cada uno. La manera más naíve es partir cada 500 caracteres. Funciona mal: cortás en la mitad de una oración, perdés contexto, los chunks no tienen unidad de significado.
Lo que usamos nosotros: chunks por estructura semántica (párrafo o sección), con solapamiento del 10-15% entre chunks consecutivos para no perder contexto. Para documentos largos con headings claros (manuales, políticas internas), cortamos por heading y preservamos el path jerárquico en metadata.
La prueba de humo: si mirás un chunk al azar, ¿tiene sentido leerlo solo? Si no, estás cortando mal.
2. Modelo de embeddings
Los embeddings son vectores que representan el significado de un texto para que puedas buscar por similitud. No todos los modelos son iguales.
Para español, las opciones razonables en 2026:
- text-embedding-3-small de OpenAI: barato, calidad sólida, buena performance en español. Es nuestro default.
- text-embedding-3-large: 6x más caro, mejor en casos de matices sutiles. Rara vez lo justifica.
- multilingual-e5-large open-source: gratis si lo self-hosteás, calidad comparable a OpenAI small en español. Lo usamos cuando hay restricciones de datos.
Lo que importa más que el modelo exacto: que los embeddings de la consulta y los embeddings de los documentos se generen con el mismo modelo. Parece obvio y no lo es: hemos visto sistemas donde alguien cambió el modelo para nuevos documentos y rompió todo.
3. Retrieval (cuántos y cómo)
Cuando llega una consulta, tenés que decidir cuántos chunks pasarle al LLM. Demasiados y el contexto se diluye (el LLM pierde foco y es más caro). Muy pocos y la respuesta no tiene información suficiente.
Empezamos siempre con top-5 (cinco chunks más similares) y medimos. Si las respuestas son pobres, subimos a top-10. Si son buenas, bajamos a top-3. Es un hyperparámetro que se calibra con casos reales, no con intuición.
Otro detalle: similarity search por embeddings (cosine distance) capta similitud semántica pero pierde coincidencias exactas de keywords. Para preguntas que dependen de términos específicos (códigos de producto, nombres de normas, números de ley), combiná similarity search con BM25 o full-text search y quedate con la unión. Es "hybrid search" y mejora mucho el recall.
4. Reranking (opcional pero potente)
Después del retrieval tenés, digamos, 10 chunks candidatos. Antes de pasárselos al LLM, podés aplicar un reranker: un modelo más caro pero más preciso que te reordena esos 10 y se queda con los 3 mejores. Es un paso extra pero puede mejorar la calidad del output significativamente sin cambiar el resto.
Nosotros empezamos sin reranker y lo agregamos solo si la calidad después de ajustar chunking y retrieval no alcanza. Es una optimización, no un requisito inicial.
Errores típicos
Las cosas que vemos que fallan con más frecuencia en proyectos de RAG PyME:
Indexar PDFs mal parseados. Muchos PDFs, especialmente escaneados, vienen con texto corrupto, saltos de línea raros, columnas mezcladas. Si indexás eso directo, el retrieval devuelve basura. Antes de indexar, abrí tres PDFs al azar y leé el texto extraído. Si no se entiende, pasá los PDFs por OCR bueno (Azure Document Intelligence, AWS Textract, o Marker) antes de chunking.
No versionar el índice. Cuando actualizás un documento, tenés que re-generar sus chunks y sus embeddings, y borrar los viejos. Si no lo hacés bien, terminás con información contradictoria en el índice y el LLM responde con la versión vieja.
No validar la respuesta contra los chunks recuperados. El LLM a veces "inventa" citas que no estaban en los chunks que le pasaste. Para casos sensibles, hacemos un paso extra: después de la respuesta, verificamos que las frases citadas existan literalmente en los chunks. Si no, marcamos la respuesta como "no verificable" y la descartamos.
No medir calidad en casos reales. El equipo suele probar el RAG con las mismas tres preguntas todos los días y se siente orgulloso. La evaluación real requiere un set de 30-50 preguntas con respuestas esperadas, que corrés cada vez que cambiás algo.
Cuándo sí conviene un vector DB serio
Las señales de que Postgres + pgvector ya no alcanza:
- Más de 100.000 chunks indexados.
- Latencia de búsqueda consistentemente mayor a 500ms.
- Necesidad de filtros avanzados (multi-tenant, geo, tipo de documento) combinados con similarity.
- Queries por segundo en el orden de decenas o más.
En esos casos, Qdrant (self-hosted) o Pinecone (managed) son las opciones naturales. Ninguna de las dos es enterprise-expensive; Qdrant es gratis self-hosteado y Pinecone Starter arranca en 70 USD/mes.
Costo real para ~2.000 documentos
Un cálculo aproximado del costo mensual para un caso típico (2.000 documentos, promedio 5 chunks por doc = 10.000 chunks, 50 consultas por día):
- Indexación inicial (one-time): 10.000 embeddings × costo text-embedding-3-small = menos de 1 USD.
- Consultas: 50 queries × (1 embedding de query + ~5 chunks de contexto × 500 tokens promedio + respuesta) = ~5 USD por mes con GPT-4o-mini.
- Postgres: ya lo tenés, costo marginal 0.
- VPS: el que ya usás para n8n.
Total: alrededor de 6 USD por mes en costo variable. El mismo caso con un proveedor enterprise de RAG te puede salir 500 USD o más. La diferencia no es calidad; es que te cobran por packaging y soporte que una PyME casi nunca necesita.
El punto
RAG no es magia ni requiere infraestructura de Silicon Valley. Es cuatro decisiones (chunking, embeddings, retrieval, validación) que aplicás con criterio sobre un stack común. Hacerlo bien requiere iteración y medición contra casos reales, pero no requiere gastar miles. Si un proveedor te cobra cuatro cifras por mes para "RAG empresarial" sobre 2.000 documentos, hay una altísima probabilidad de que te esté cobrando por el sticker, no por el valor.