# Sistemas RAG Empresariales: Arquitectura, Trampas y Qué Funciona de Verdad en 2026 | Alher Tech > La mayoría de demos RAG quedan bonitas y fallan en producción. Qué separa un piloto RAG fallido de un millón $ de un despliegue empresarial que funciona: estrategia de chunking, retrieval, evaluación y arquitecturas híbridas que ganan. - Canonical page: https://alhertech.com/es/guias-ia/sistemas-rag-empresariales/ - Site: Alher Tech (custom software, AI agents and SEO engineering, https://alhertech.com/) - Contact: https://alhertech.com/es/contacto/ --- 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 - [Agentes IA empresariales: casos reales y ROI](https://alhertech.com/es/guias-ia/agentes-ia-empresas/) - [Coste de integrar IA: guía 2026](https://alhertech.com/es/guias-ia/cuanto-cuesta-integrar-ia/) - [Nuestros servicios de agentes IA](https://alhertech.com/es/servicios/agentes-ia/) - [Hablemos de tu proyecto RAG](https://alhertech.com/es/contacto/)