· Hernán Pérez Rodal · Engineering · 3 min read
RAG sobre 10+ bases de datos: lo que producción nos enseñó
Por qué RAG vector-only no escala en compliance, cómo diseñamos retrieval híbrido sobre múltiples stores, y las decisiones arquitectónicas que funcionaron en producción.
TL;DR — En 2026 el consenso es claro: RAG vector-only no escala en producción. En Darwin construimos un sistema agentic de compliance con retrieval híbrido sobre 10+ bases de datos. Las mejores decisiones que tomamos no tuvieron que ver con el modelo, sino con la capa de datos.
El problema
Nuestro sistema agentic de compliance tiene que responder preguntas como:
“¿Qué lotes de mango del productor X, procesados entre mayo y julio, cumplieron con los CTEs exigidos por FSMA 204, y cuáles tienen gaps de evidencia?”
Una sola pregunta que combina:
- Conocimiento regulatorio (FSMA 204 CTE/KDE definitions — texto estructurado)
- Eventos de trazabilidad (CTEs registrados con timestamp, geolocalización, proveedor, lote)
- Reglas de negocio internas (gap analysis, risk scoring — lógica dinámica)
- Relaciones entre entidades (productor → planta → envío → retailer)
Un vector store con embeddings de todo mezclado no sirve para responder eso bien. La respuesta correcta requiere join de datos estructurados + retrieval semántico + cálculo agregado.
La arquitectura
Nuestro stack de retrieval:
| Fuente | Tipo | Uso |
|---|---|---|
| Qdrant | Vector store | Regulaciones, doctrina, casos históricos (datos no estructurados) |
| PostgreSQL | Relacional | Eventos de trazabilidad (CTE/KDE con timestamps, IDs, geo) |
| Firebase/Firestore | Documento | Configuración por cliente, UI state |
| Cloud Storage | Blob | PDFs originales, audit trails, evidencia digital |
| On-chain (Polygon) | Immutable | Attestations críticas, firmas digitales |
El agente no sabe dónde vive cada cosa — el orchestrator lo resuelve.
LangGraph como orchestrator
Usamos LangGraph para rutear queries en múltiples pasos:
- Classify — qué tipo de pregunta es (regulatoria / operacional / mixta)
- Plan — qué retrievals son necesarios (vector + SQL + graph traversal)
- Fan-out — ejecutar retrievals en paralelo
- Synthesize — pasar resultados al LLM con contexto estructurado
- Validate — guardrails para prevenir hallucinations en datos numéricos
El paso clave fue #2: darle al LLM un query planner que decide la estrategia de retrieval antes de ir a buscar. Sin eso, el modelo alucina datos o trae contexto irrelevante.
Lo que no funcionó
Vector-only con chunking agresivo — nuestro primer intento. Falló en dos dimensiones:
- Counting / aggregation queries (¿cuántos lotes? ¿promedio por semana?) — LLM inventaba números cuando no los tenía explícitos en contexto
- Joins relacionales (productor X + ventana temporal Y + certificación Z) — imposible sin query estructurada
La solución no fue “mejor chunking” — fue separar retrieval semántico de consultas estructuradas.
Lo que sí funcionó
Query routing explícito → el planner decide si una pregunta requiere vector search, SQL, graph traversal, o combinación.
Guardrails numéricos → si la respuesta del LLM contiene números, verificamos que coincidan con lo que devolvió la query estructurada. Si no, fallamos fast en lugar de devolver datos incorrectos.
Semantic caching en el nivel de preguntas similares → reduce costos de LLM ~40% sin impacto en calidad.
Observabilidad full-trace con OpenTelemetry → cada query se trackea end-to-end (planner → retrieval → LLM → guardrails). Crítico para debug.
Lessons learned
- El bottleneck de RAG en producción no es el retrieval — es la decisión de qué retrieval usar
- Los guardrails numéricos salvan vidas cuando la correctness de la respuesta afecta decisiones regulatorias
- LangGraph es mejor que cadenas lineales para orchestrar retrievals condicionales
- Multi-store + planner > single vector store con mejor chunking
- Los LLMs van a alucinar sobre aggregations estructuradas — no importa cuán bueno sea el modelo
¿Y ahora?
La próxima iteración es reemplazar algunas reglas del planner por fine-tuning del router con ejemplos reales de producción. El planner como LLM es flexible pero caro — cachear sus decisiones en un modelo más chico es un step lógico.
Si estás construyendo RAG para dominios regulados, mi consejo es: empezá por el query planner, no por el vector store.
¿Estás construyendo algo similar? Hablemos — estamos abiertos a compartir arquitectura y aprender de otros casos.
