Por qué tu RAG no funciona en producción (y cómo arreglarlo)
En sistemas RAG en producción se repite un patrón: retrieval es el 20% del problema, y el 80% restante es lo que nadie enseña en tutoriales.
01. El mito del 20%
Cuando alguien te dice “tengo un RAG funcionando”, casi siempre significa: tengo un notebook donde meto un PDF, hago embeddings, busco por cosine similarity y paso el top-k al LLM. Eso no es un sistema en producción — es una demo convincente.
Los problemas empiezan el día 2. El día 30, si no los has atacado, tu equipo está debuggeando respuestas incorrectas una por una, reactivamente, sin poder reproducir los bugs.
Todo el mundo quiere construir RAG. Nadie quiere operarlo.
02. Evals antes que prompts
Si no puedes medir cuándo el sistema responde bien, no puedes mejorarlo. Los evals son el primer entregable — antes de tocar prompts, antes de decidir el modelo.
Un eval mínimo viable necesita:
- Golden set de 50-200 pares (pregunta, respuesta esperada) validados por expertos de dominio.
- Métricas automatizables: faithfulness, answer relevancy, context precision.
- CI/CD que bloquea merges que regresen evals >5%.
# evals/run.py
def evaluate(dataset, system):
results = []
for q, expected in dataset:
answer = system(q)
results.append({
"faithfulness": score_faithfulness(answer, ctx),
"relevancy": score_relevancy(answer, q),
})
return aggregate(results)03. Caching inteligente
La mayoría de queries en producción son variantes de 20 preguntas recurrentes. Si no cacheas, estás pagando tokens de más y latencia innecesaria.
Tres capas, tres TTLs:
- Query cache (exact match) — TTL largo, invalidación manual.
- Embedding cache (hash del texto) — TTL infinito hasta cambio de modelo.
- Response cache (hash de query + contexto) — TTL medio, invalidación por freshness.
04. Freshness & invalidación
Tu base de conocimiento cambia. Si no tienes estrategia de freshness, servirás respuestas desactualizadas — y eso es peor que no responder.
Dos patrones que funcionan:
- Change Data Capture sobre la fuente, dispara re-embedding incremental.
- Staleness score por documento, prioriza el re-indexing nocturno.
05. MCP servers: la nueva primitiva
Desde finales de 2024, Model Context Protocol cambió cómo pienso los sistemas con LLMs. En vez de meter todo en un RAG monolítico, expongo el contexto a través de MCP servers que cada cliente (Claude, Cursor, tu app) puede consumir.
06. Cuándo NO usar RAG
Si puedes resolver el problema con:
- Un prompt con contexto fijo → no necesitas RAG.
- Una búsqueda full-text tradicional → no necesitas RAG.
- Una tabla de lookup → definitivamente no necesitas RAG.
07. Checklist para producción
- ☑ Golden set > 100 pares validados
- ☑ Evals en CI bloqueando regresiones
- ☑ Observabilidad: traces, tokens, latencia, coste
- ☑ Cache de 3 capas con TTLs diferenciados
- ☑ Estrategia de freshness documentada
- ☑ Feature flag para desactivar RAG en caliente
- ☑ Runbook de incidentes probado
El RAG que funciona no es el más inteligente. Es el más observable.
