Sistemas RAG Empresariales: Arquitectura, Trampas y Qué Funciona de Verdad en 2026
Las demos de RAG (Retrieval-Augmented Generation) son fáciles. Los sistemas RAG que aguantan contra millones de documentos, cientos de usuarios y preguntas adversariales son muy difíciles. La mayoría de pilotos RAG empresariales en 2024-2025 lanzaron, lucieron en la sala de juntas y murieron silenciosamente en el mes cuatro. Esta es la arquitectura y proceso que usamos en Alher Tech para construir RAG que sobrevive a producción, cubriendo chunking, retrieval, evaluación y los patrones híbridos que funcionan de verdad.
Por Qué Falla la Mayoría de RAG Empresarial
El patrón es consistente: el piloto va bien con un set curado de 100 documentos. La producción tiene 100.000+ documentos con formato sucio, versiones en conflicto y PII. La misma arquitectura que deslumbró en la demo degrada silenciosamente al 60% de accuracy. Tres meses después el proyecto se aparca.
- Suposición errónea: 'simplemente embedea todos los docs y busca'. Los corpus reales necesitan preprocesado, deduplicación y control de versiones.
- Sin evaluación: nadie mide recall, faithfulness o tasa de alucinación a lo largo del tiempo.
- Estrategia de retrieval única: vector search puro pierde docs recientes, queries estructuradas y términos raros.
- Chunking por número de caracteres: parte frases en mitad, destruye contexto.
- Sin re-ranking: los top-5 hits del vector no son las top-5 respuestas.
- Sistema estático: sin feedback loop, sin tuning del retrieval basado en uso real.
La Arquitectura de Referencia Que Funciona
El RAG de producción en 2026 es un pipeline multi-etapa, no un vector search único. Las piezas:
- Ingesta de documentos: Conectores de fuente (SharePoint, Confluence, Drive, Notion, S3). Conversión a texto limpio (Unstructured.io, Llama Parse, Docling). Deduplicación por hash de contenido. Tracking de versiones para que las actualizaciones no doblen.
- Estrategia de chunking: Section-aware: respeta headings, tablas, bullets. Tamaño híbrido: chunks pequeños (200-400 tokens) para retrieval, grandes (1500-3000 tokens) para contexto. Overlap de 10-20% para temas en frontera.
- Embedding multi-vector: Embedea el chunk + una pregunta hipotética (HyDE) + un resumen. Recupera por cualquiera de los tres. Recall 20-30% mayor que single-vector.
- Retrieval híbrido: Vector search (semántico) + BM25 (keyword) + filtros estructurados (metadatos, fechas, categorías). Reciprocal rank fusion para combinar. La mayor palanca de accuracy.
- Re-ranking: Top 50 del retrieval → cross-encoder re-ranker (Cohere Rerank, Voyage Rerank, BGE-Reranker) → top 5 al LLM. Añade 100-300ms de latencia pero 15-25% de accuracy.
- Generación con citas: Fuerza al modelo a citar los chunks recuperados. Fuerza el grounding. Permite a usuarios verificar y a ti medir faithfulness.
- Harness de evaluación: Pares pregunta/respuesta de usuarios reales + sintéticos. Mide recall@k, faithfulness, alucinación, latencia y coste. Cada cambio pasa por aquí.
Eligiendo la Vector DB Correcta
Default a pgvector para proyectos nuevos por debajo de 10M chunks. La simplicidad operativa supera la ganancia marginal de velocidad de las vector DBs dedicadas a esta escala.
Chunking: La Palanca Subestimada
El chunking malo destruye RAG antes de que el retrieval corra. Los patrones que funcionan:
- Respeta la estructura: nunca partas mitad de párrafo si puedes evitarlo. Usa headings de documento para definir chunks.
- Las tablas tienen su propio chunk: no las trozees entre fronteras.
- Los bloques de código tienen su propio chunk: mantenlos intactos.
- Mete metadatos a cada chunk: título, sección, URL, fecha de modificación, autor. El retrieval con filtros depende de esto.
- Multi-granularidad: indexa chunks pequeños para retrieval, sirve chunks padre más grandes (o secciones completas) al LLM.
- Parent-document retrieval: recupera por chunk, manda el padre completo al LLM. Lo mejor de ambos mundos.
Evaluación: Sin Ella, Estás Adivinando
RAG sin evals es inmantenible en producción. Componentes de una suite real:
- Evaluación de retrieval: Recall@k en un set curado de pares pregunta/doc-relevante. Trackea si los docs correctos llegan al LLM.
- Evaluación de respuesta (LLM-as-judge): GPT-5 o Claude Opus puntuando respuestas por corrección, faithfulness, relevancia. Calibrado contra juicio humano en una muestra.
- Detección de alucinación: Cross-check de cada claim contra los chunks recuperados. Rechaza respuestas que metan datos no citados.
- Feedback de usuarios reales: Thumbs up/down + texto libre. Vuelven al eval set para que el sistema mejore.
- Tracking de coste + latencia: Coste por query, p50/p95. Un RAG accurate que tarda 8 segundos es inusable en chat UIs.
Realidad de Costes
| Componente | Coste setup | Coste mensual |
|---|
| Pipeline ingesta + chunking | 15K – 80K $ | 300 – 3K $ |
| Vector DB (pgvector / Pinecone) | 5K – 30K $ | 200 – 5K $ |
| Generación de embeddings (OpenAI / Voyage / Cohere) | 2K – 20K $ inicial | 200 – 2K $ |
| Re-ranking (Cohere Rerank, BGE) | 1K – 5K $ | 200 – 2K $ |
| Generación con LLM (Claude / GPT-5) | N/A | 1K – 20K $ según volumen |
| Harness de evaluación | 20K – 80K $ | 500 – 3K $ |
| Frontend / chat UI / orquestación | 30K – 150K $ | 500 – 5K $ |
Presupuesto total inicial: 80K – 400K $ según escala y complejidad. Anual recurrente: 30K – 300K $ según uso.
RAG Es una Disciplina de Ingeniería
Las empresas que ganan con RAG en 2026 lo tratan como cualquier otro sistema de producción, con medición, observabilidad, evaluación y mejora continua. Las que pierden construyeron un prompt, lo desplegaron y rezaron.
Si arrancas un proyecto RAG empresarial, el playbook de arriba no es opcional. Saltarte cualquier parte es cómo el proyecto termina aparcado.
Preguntas frecuentes
¿Fine-tuneo el modelo o uso RAG?
RAG para hechos que cambian. Fine-tuning para tono, formato y conocimiento de dominio estable. Casi todas las necesidades empresariales son RAG. Fine-tuning rara vez es la primera jugada correcta.
¿Qué modelo de embeddings uso?
OpenAI text-embedding-3-large para inglés general. Voyage-3 para más accuracy a más coste. Cohere embed-multilingual para no-inglés. Open-source (BGE, E5) cuando autohostear importa.
¿Cuánto tarda construir un sistema RAG?
Piloto con 1K-10K docs: 4-6 semanas. Producción con 100K+ docs y eval seria: 12-20 semanas. Suma 4-8 semanas para integración con agente.
¿Qué tamaño de chunk uso?
Empieza con 400-800 tokens para retrieval, con overlap del 10-20%. Ajusta según dominio: código y legal necesitan más pequeños; narrativo se beneficia de más grandes. Valida siempre con tu eval set.
¿Cómo manejo PII y control de acceso?
Filtra en retrieval con metadatos user-aware. Cada chunk tiene un ACL; el retrieval solo devuelve chunks que el usuario puede ver. No confíes en el LLM para redactar. Redacta en ingesta o filtra en retrieval.
Guías relacionadas