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