RAG en 2025: arquitecturas que funcionan y errores que sigues cometiendo
RAG ya no impresiona por existir. Impresiona cuando devuelve contexto bueno, escala sin locuras y no obliga a perseguir alucinaciones en produccion. La diferencia esta en retrieval, evaluacion y limites claros del sistema.
El mayor error con RAG no es tecnico. Es conceptual: tratarlo como un addon del LLM y no como un sistema de recuperacion de informacion con sus propias reglas. Cuando retrieval falla, el mejor modelo del mundo solo inventa mejor.
La calidad del retrieval pesa mas que la del modelo
En muchos proyectos la mejora mas visible no ha venido de cambiar de modelo, sino de arreglar como se indexaba, troceaba y filtraba el contexto. RAG vive o muere por la relevancia del material que entra en contexto.
Chunking: donde muchos pipelines se rompen sin avisar
Trocear mal la documentacion genera respuestas que parecen plausibles pero mezclan ideas, pierden matices o omiten restricciones importantes. El chunking no es un paso mecanico. Es una decision editorial y tecnica a la vez.
Dividir todo por numero fijo de caracteres y asumir que el embedding lo resolvera solo. Cuando el documento tiene estructura semantica clara, romperla cuesta mucha precision.
Hybrid search ya no es un capricho
En 2025, combinar busqueda vectorial con keyword search suele dar mejores resultados que confiarlo todo a embeddings. Terminos raros, nombres de producto, codigos internos o referencias legales concretas mejoran mucho cuando BM25 o filtros lexicales entran en juego.
Evaluar RAG sin dataset es jugar a adivinar
Si no tienes preguntas reales, respuestas esperadas y algun criterio de grounding, no estas evaluando nada. Solo estas viendo demos bonitas. Un pipeline serio necesita test cases, comparativa entre versiones y alertas si la calidad cae despues de cambios en embeddings o chunking.
[
{
"question": "Cual es el SLA del plan enterprise?",
"expected_context": ["pricing.md", "sla.md"],
"must_include": ["99.9%"]
},
{
"question": "Como se cancela una suscripcion anual?",
"expected_context": ["billing-policy.md"]
}
]
Arquitecturas que nos estan funcionando
Cuando no recomendamos RAG
| Situacion | Por que no |
|---|---|
| Base documental pequena y estable | Una busqueda clasica puede ser suficiente |
| Procesos criticos sin tolerancia al error | Necesitas reglas y validacion fuerte, no solo contexto |
| Sin logs ni evaluacion | No podras saber si realmente mejora algo |
Casos de Uso RAG que dan dinero hoy (B2B)
Dejemos las demos de lado. En Altya Studio hemos visto donde RAG realmente mueve la aguja en empresas medianas y grandes, justificando la inversion tecnica:
El coste real de un sistema RAG en produccion
Uno de los grandes mitos comerciales es que montar RAG es "llamar a la API de OpenAI y listo". Si estas planificando presupuesto para tu empresa, tienes que tener en cuenta estos 3 bloques de coste:
| Componente tecnico | Coste e Implicacion B2B |
|---|---|
| Vector Database | Bases como Pinecone, Qdrant o Weaviate cobran por dimension y almacenamiento. Si tienes millones de documentos, el hosting del indice vectorial puede superar el coste del propio LLM. |
| Embeddings & Computo | Cada vez que entra un PDF nuevo, hay que trocearlo y generar embeddings. Es un coste continuo de proceso. En Altya solemos recomendar modelos open-source (ej. BGE) alojados on-premise si el volumen es muy alto, para evitar peajes por token de API. |
| Coste de LLM (Inferencia) | El modelo generador (GPT-4o, Claude 3.5 Sonnet) cobra por token de entrada y salida. Enviar 10.000 tokens de contexto recuperado en cada pregunta sube la factura rapidamente. El ROI solo sale positivo si el problema que resuelves vale miles de euros en tiempo humano. |
Nuestra Stack recomendada en Altya Studio
Despues de varias iteraciones y despliegues en clientes reales, nuestra arquitectura de referencia en 2025 para RAG B2B se ve asi:
- Orquestacion: LangChain o LlamaIndex (dependiendo de la complejidad de los pipelines documentales). Preferimos vanilla Python si el flujo es altamente determinista.
- Base de Datos Vectorial: Qdrant o Pinecone. Qdrant es excelente si tienes tu propia infraestructura VPS (como en Hetzner) gracias a su version open-source.
- Embeddings: Cohere o modelos locales de HuggingFace si hay privacidad de datos estricta bancaria/medica.
- LLM Generador: Claude 3.5 Sonnet o GPT-4o. Claude destaca enormemente procesando contextos larguisimos sin perder el hilo (evitando el temido efecto 'lost in the middle').
Conclusion: menos magia, mas retrieval serio
RAG funciona muy bien cuando se plantea como una capa de recuperacion bien pensada, no como un accesorio del chatbot. Si el contexto es bueno, la experiencia mejora mucho. Si el contexto es malo, el sistema solo alucina con mas seguridad. La diferencia esta en retrieval, evaluacion y humildad operativa.