Arquitectura de un RAG en producción: del POC al sistema real

TL;DR

La arquitectura de un RAG en producción es el conjunto de componentes (ingesta, parsing, chunking, embeddings, vector DB, retrieval híbrido, reranking, generación y evaluación) diseñados para responder con datos propios de la empresa de forma fiable, rápida y auditable, sostenido en el tiempo y bajo carga real. Entre el 60% y el 70% de los proof of concept de RAG que vemos no sobreviven al salto a producción: mueren por chunking ingenuo, ausencia de reranking, falta de evaluación continua o por confundir “responde bien en 5 preguntas” con “está listo”. En este artículo abrimos la arquitectura completa que usamos en Datalvar AI cuando llevamos un RAG de empresa de la demo al sistema que aguanta miles de consultas al día, integrando pgvector, Qdrant, Cohere Rerank, Voyage, RAGAS y patrones de caché y observabilidad concretos. No hay magia: hay ingeniería, evidencia y disciplina.

¿Por qué casi todos los POC de RAG mueren antes de producción?

En Datalvar AI hemos auditado decenas de proyectos de Retrieval Augmented Generation en los últimos dos años, propios y ajenos. El patrón se repite con una uniformidad que ya nos sorprende poco: un equipo ensambla un POC con LangChain o LlamaIndex en una tarde, lo prueba con cinco preguntas curadas, los stakeholders se emocionan y la empresa decide pasarlo a producción. A los tres meses, el sistema responde mal, los usuarios dejan de usarlo, alguien dice que “los LLMs no funcionan” y el proyecto queda enterrado. La causa no es el modelo. La causa es que la arquitectura de un RAG en producción no se parece en casi nada a la de un POC, y muy poca gente lo asume al principio.

El POC valida que el patrón conceptual funciona: meter contexto en el prompt mejora las respuestas. Eso lo logras en un fin de semana. Lo que no logras en un fin de semana es resolver los problemas reales: documentación heterogénea (PDFs escaneados, Word de hace diez años, Confluence con tablas anidadas, intranets sin permisos claros), miles de usuarios concurrentes con preguntas ambiguas, requisitos de latencia por debajo de dos segundos, costes que no se disparen con cada consulta, evaluación continua para detectar degradación y trazabilidad para que un humano pueda auditar de dónde salió cada respuesta. Esa es la arquitectura de un RAG en producción real: capas, métricas, fallbacks y disciplina de ingeniería.

En la práctica, el 80% del esfuerzo de un RAG serio se va en ingesta, evaluación y observabilidad. El LLM es la parte fácil.

Lo que vemos demasiado, y que conviene decir alto, es la confusión entre demo bonita y sistema fiable. Un sistema RAG decente requiere asumir que la calidad de la respuesta depende de una cadena de eslabones donde cada uno tiene su propio modo de fallo, sus métricas, sus optimizaciones y su coste. Si tratas el RAG como “subimos PDFs y preguntamos”, obtienes un juguete. Si lo tratas como un pipeline de datos con un modelo generativo al final, obtienes algo que aguanta. El resto del artículo es eso: la arquitectura de un RAG en producción tal y como la diseñamos, con las decisiones y los errores que hemos cometido para llegar hasta aquí.

¿Qué componentes definen la arquitectura de un RAG en producción?

Cuando dibujamos en pizarra la arquitectura de un RAG en producción para un cliente, siempre aparecen al menos ocho bloques diferenciados: ingesta de fuentes, parsing y limpieza, chunking, generación de embeddings, base vectorial, recuperación híbrida (vectorial más léxica), reranking, generación con el LLM y, transversalmente, evaluación, observabilidad y caché. Cada bloque puede implementarse de varias formas, con trade-offs claros de coste, latencia y calidad. Decir “uso RAG” sin especificar qué hay en cada capa es como decir “uso una base de datos” sin saber si es Postgres o un CSV en S3.

El orden importa porque cada decisión condiciona la siguiente. Si parseas mal un PDF con tablas, el chunking heredará ruido. Si fragmentas con un chunker ingenuo de 1.000 caracteres con solapamiento de 200, romperás secciones semánticas y los embeddings reflejarán esa fragmentación, lo que degradará la recuperación aguas abajo. Si recuperas sin reranker, dejarás que el LLM decida con los 5 chunks “más cercanos” del coseno, cuando los relevantes podrían estar en la posición 27. Si no tienes evaluación automática, no podrás saber si tu último cambio mejoró o empeoró el sistema. Cada eslabón es una palanca y, a la vez, una fuente potencial de degradación silenciosa.

En Datalvar AI llevamos esto al extremo: cada nuevo proyecto de RAG arranca con una hoja donde fijamos, antes de tocar código, qué herramientas vamos a usar en cada capa, qué métrica objetivo perseguimos (faithfulness, context relevancy, answer relevancy de RAGAS, latencia P95, coste por consulta) y qué patrones de fallback aplicaremos si algún componente cae. Esa hoja se convierte en el contrato de arquitectura del proyecto. Sin ese contrato, la arquitectura de un RAG en producción se vuelve un cajón de sastre y, antes o después, alguien añade un componente “porque es lo nuevo” que rompe el equilibrio que tanto costó conseguir.

!IMAGE_TODO[Diagrama de bloques de la arquitectura de un RAG en producción: ingesta, parsing, chunking, embeddings, vector DB, retrieval híbrido, reranking, generación, evaluación y observabilidad]

¿Cómo diseñamos la ingesta de datos sin que se convierta en un cementerio de PDFs?

La ingesta es la parte menos sexy y la que más determina el techo de calidad de la arquitectura de un RAG en producción. En las empresas medianas y grandes con las que trabajamos, la documentación vive repartida entre SharePoint, Google Drive, Confluence, Notion, intranets viejas, repositorios de tickets, mails y, sobre todo, PDFs. Muchos PDFs. Algunos generados desde Word con texto seleccionable, otros escaneados, otros con tablas críticas que se rompen si no las parseas bien, otros con marcas de agua, anexos, índices y portadas que no aportan nada al contenido útil.

El primer principio que aplicamos es: no toda la documentación debe entrar al RAG. Hay una tentación enorme de “subirlo todo” pensando que más contexto es mejor. No lo es. La basura indexada genera basura recuperada, y cuesta dinero almacenarla y procesarla. En cada proyecto hacemos una fase de curación previa donde clasificamos las fuentes por valor de negocio, fecha, autoría, propietario y caducidad. Las fuentes que sobreviven al filtro son las que pasan a la pipeline. Las que no, se quedan fuera con una nota explícita de por qué. Esta decisión, que parece menor, suele recortar entre un 30% y un 50% el volumen indexado y mejora la precisión inmediatamente porque elimina ruido competidor en la recuperación.

El segundo principio es: la ingesta es un pipeline programable, no un upload manual. Diseñamos conectores específicos por fuente con su propia cadencia de sincronización: SharePoint con webhooks o polling, Confluence con la API, repos Git con hooks, bases de datos con CDC cuando aplica. Cada documento queda con metadatos ricos: fuente, autor, fecha de creación, fecha de actualización, departamento, nivel de confidencialidad, idioma y un identificador estable. Esos metadatos viajan con el chunk hasta el momento de la recuperación, y son la única manera honesta de hacer filtrado por permisos, frescura o departamento sin tener que reindexar. Sin metadatos buenos, la arquitectura de un RAG en producción se queda coja para casos reales como “responde solo con documentos posteriores a 2024” o “muéstrame solo política interna del área legal”.

¿Qué herramientas de parsing aguantan documentación real (Unstructured, Docling, LlamaParse)?

Una vez que tienes los documentos, hay que extraer texto, tablas, imágenes y estructura. Aquí es donde casi todos los POC se rompen al pasar a producción. Hemos visto sistemas que funcionaban perfecto con los seis PDFs de prueba del cliente y se derrumbaban en cuanto se metían los 4.000 reales. La razón siempre es la misma: el parser de turno (un PyPDF puesto a las bravas) no entiende layouts complejos, tablas, columnas, footnotes, encabezados y pies, y devuelve un churro de texto donde la columna izquierda se mezcla con la derecha y las tablas se aplastan.

En Datalvar AI usamos principalmente tres herramientas dependiendo del tipo de documentación: Unstructured cuando hay variedad de formatos y queremos un único pipeline para PDF, DOCX, HTML, PPTX, MSG y demás; Docling cuando la documentación es PDF complejo con tablas y queremos preservar estructura jerárquica (Docling devuelve un árbol de elementos que se presta muy bien a chunking estructural); y LlamaParse cuando el cliente tolera procesamiento en la nube y queremos calidad alta en documentos especialmente densos. Cada uno tiene su talón de Aquiles: Unstructured puede ser lento en lotes grandes, Docling consume bastante memoria y LlamaParse implica coste por página y enviar datos a un tercero, lo que para muchos clientes no es aceptable.

La regla práctica que hemos consolidado: parsear con la herramienta más estructurada que el documento permita, evaluar manualmente una muestra de 30-50 documentos antes de chunkear, y mantener visibilidad del parsing como artefacto debuggable (es decir, guardar el output del parser para poder revisar por qué un chunk acabó como acabó). Sin esta inspección periódica, los errores de parsing se camuflan dentro del sistema y aparecen meses después como “el bot no contesta bien sobre el procedimiento X”, cuando lo que pasa es que la tabla del procedimiento X se machacó en la fase de parsing y nunca llegó decentemente al vector store. La arquitectura de un RAG en producción que se respete trata el parsing como código de primera clase, con tests y reglas de calidad.

¿Por qué el chunking ingenuo es el error más caro de un RAG?

El chunking decide cómo se trocea el contenido para indexarlo. Es probablemente la decisión que más impacto tiene en la calidad final y, paradójicamente, la que más equipos resuelven con el primer ejemplo que copian de internet: RecursiveCharacterTextSplitter de LangChain con chunk_size=1000 y chunk_overlap=200. Funciona razonable para una demo, fracasa para producción. El chunking ingenuo parte párrafos por la mitad, separa preguntas de respuestas en un FAQ, rompe tablas, deja huérfanos los encabezados y, sobre todo, ignora la estructura semántica del documento original.

Lo que vemos funcionar mejor en la práctica es chunking estructural: aprovechar la jerarquía que el parser ya extrajo (capítulos, secciones, subsecciones, tablas, listas) y generar chunks que respeten esos límites. Cada chunk lleva en sus metadatos su “ruta jerárquica” (capítulo, sección, página), lo que permite contextualizar la respuesta y, llegado el caso, ofrecer al usuario el camino exacto al fragmento original. Cuando el documento no tiene estructura clara (por ejemplo, una transcripción de reunión), aplicamos chunking semántico: trozos por similitud entre frases consecutivas usando embeddings ligeros, partiendo cuando la similitud cae por debajo de un umbral. Es más caro de calcular, pero la mejora en recuperación lo compensa.

Tamaños: para casos generales nos funcionan chunks de 400-800 tokens con solapamiento mínimo (50-100 tokens) si el chunking es estructural; cuando se usa chunking semántico bien hecho, el solapamiento puede ser cero. Demasiado grande (1.500+ tokens) diluye la señal del embedding y mete contenido irrelevante en el contexto del LLM. Demasiado pequeño (menos de 200) fragmenta ideas y obliga a recuperar muchos chunks por consulta, lo que aumenta latencia y coste. La regla operativa que tenemos en Datalvar AI: empezar por chunking estructural con 500 tokens, evaluar con un test set propio y mover la palanca con datos en la mano, no con intuición. La arquitectura de un RAG en producción no se afina mirando ejemplos, se afina midiendo.

¿Qué modelo de embeddings elegir (OpenAI text-embedding-3-large, Voyage, Cohere)?

El modelo de embeddings convierte texto en vectores que capturan significado. Cambiar el modelo cambia toda la geometría del espacio semántico, así que esta decisión hay que tomarla pronto y con conocimiento. En Datalvar AI hemos probado en producción los principales: OpenAI text-embedding-3-large, Voyage voyage-3 y voyage-large-2, Cohere embed-multilingual-v3 y modelos open-source como bge-large o e5-mistral. No hay un ganador absoluto. Hay un ganador por caso de uso, idioma, presupuesto y restricciones de privacidad.

Para casos en español o multilingüe, los embeddings de Cohere multilingüe y los de Voyage funcionan especialmente bien y, según nuestros benchmarks internos, suelen superar a OpenAI en recall sobre corpus técnico en español por márgenes del 5% al 15% dependiendo del dominio. OpenAI 3-large es una opción razonable de “valor seguro” cuando ya estás dentro del ecosistema y quieres una sola factura, y tiene la ventaja de ofrecer dimensionalidad configurable (puedes reducir vectores de 3.072 a 1.024 con dimensions y ahorrar mucho almacenamiento sin perder demasiada calidad). Si el cliente requiere on-premise por compliance, vamos a open-source con bge-large o variantes finetuneadas sobre su corpus.

La regla más importante: el modelo de embeddings se elige con benchmark sobre datos propios. Nunca con los benchmarks públicos como MTEB tal cual, porque tu dominio probablemente no se parece a los datasets de evaluación pública. En Datalvar AI armamos un dataset de evaluación con 100-300 pares de pregunta-respuesta etiquetados por el cliente y medimos recall@10, recall@20 y nDCG con cada modelo candidato antes de comprometernos. Esa hora invertida en benchmark ahorra meses de iteraciones a ciegas. Y, sobre todo, evita el clásico “cambiamos de modelo porque salió uno nuevo más cool” que reindexar millones de documentos cuesta dinero serio y que rara vez compensa si el actual rinde bien.

¿Qué vector database conviene en producción (pgvector, Qdrant, Pinecone, Weaviate)?

Con los embeddings hay que decidir dónde almacenarlos y cómo buscarlos. El abanico es amplio: pgvector si ya tienes Postgres, Qdrant si quieres open-source autoalojado, Pinecone si prefieres servicio gestionado en la nube, Weaviate si te gusta su modelo de schema y módulos, Milvus para volúmenes masivos, ChromaDB para empezar rápido (no para producción seria), Vespa para casos de búsqueda híbrida muy sofisticada. En Datalvar AI elegimos siempre según volumen previsto, equipo de operaciones, requisitos de latencia y políticas de datos del cliente.

Para volúmenes hasta unos 10 millones de vectores con dimensiones razonables (768-1.536), pgvector sobre Postgres suele ser una opción excelente que la gente subestima. El argumento “Postgres ya está, una caja menos que mantener, transacciones ACID, joins con metadatos relacionales sin malabares” pesa mucho en empresas con equipos de DBA tradicionales. Con índices HNSW e IVF Flat bien configurados, pgvector aguanta cargas de producción decentes. Para volúmenes mayores o cuando necesitamos filtrado avanzado por metadatos y latencias por debajo de los 50 ms a P95, solemos ir a Qdrant autoalojado (excelente rendimiento, filtros muy potentes, escalado horizontal claro) o Pinecone (cero ops, factura predecible si el volumen es estable).

Una decisión clave que cambia muchas veces el resultado: el índice ANN no es gratis. HNSW da búsqueda rapidísima a costa de memoria y tiempos de construcción. IVF es más ligero pero requiere reentrenamiento periódico. En producción medimos recall@k contra exhaustivo en un sample y ajustamos parámetros (ef_construct, M, ef_search en HNSW; nlist, nprobe en IVF) hasta encontrar el punto donde el recall sigue siendo >0.95 con latencia aceptable. Sin esta calibración, la arquitectura de un RAG en producción puede estar perdiendo entre un 10% y un 30% de resultados relevantes simplemente por defaults mal puestos, y nadie se entera porque “el sistema responde” aunque responda peor de lo que debería.

¿Por qué la recuperación híbrida (BM25 + vectorial) bate a la recuperación solo vectorial?

Durante un par de años el discurso dominante fue que los embeddings dejaban obsoleto el viejo BM25 y la búsqueda léxica. La realidad, después de muchos proyectos, es la opuesta: la recuperación híbrida bate sistemáticamente a la recuperación solo vectorial en la mayoría de casos empresariales. Los embeddings son potentísimos para captar similitud semántica, pero fallan en casos donde el término exacto importa: códigos de producto, nombres propios, siglas, números de serie, referencias normativas, jerga interna. El BM25 los borda. Combinar ambos da lo mejor de los dos mundos.

La implementación que usamos en Datalvar AI es un retrieval híbrido con fusión de resultados: lanzamos la consulta en paralelo contra el índice vectorial y contra un índice léxico (Elasticsearch, OpenSearch o el propio Postgres con tsvector y BM25 vía extensiones, dependiendo del stack); cada motor devuelve sus top K candidatos; fusionamos con RRF (Reciprocal Rank Fusion) o con una ponderación lineal calibrada empíricamente. RRF tiene la ventaja de no necesitar tuning de pesos y funcionar razonable casi siempre. Para casos donde queremos exprimir, ponderamos con pesos que aprendemos con un test set etiquetado.

Lo que vemos en proyectos reales: pasar de solo vectorial a híbrido mejora recall@10 entre un 8% y un 25% según el dominio, y mejora especialmente las consultas con términos específicos (referencias, códigos, nombres) donde el sistema solo vectorial fallaba feo. Es una de las palancas con mejor relación esfuerzo/impacto en la arquitectura de un RAG en producción. Y, sin embargo, es la primera que muchos equipos se saltan porque “el embedding ya lo hace todo”. No lo hace. La hibridación es uno de esos detalles donde se nota la diferencia entre un sistema diseñado por alguien con experiencia de producción y uno copiado de un notebook de marketing.

¿Qué aporta el reranking con Cohere o Voyage y por qué casi todos lo saltan?

Recuperar los top 10 chunks por similitud vectorial no significa que esos 10 sean los más relevantes para la pregunta. Significa que están “cerca” en el espacio de embeddings. La similitud coseno es una proxy útil pero ruidosa de la relevancia real. Aquí entra el reranking: un segundo paso donde un modelo más caro pero más preciso (cross-encoder) puntúa la relevancia real de cada candidato frente a la pregunta, y reordena los resultados. Pasamos de recuperar 50-100 candidatos a quedarnos con los 5-10 mejores tras rerankearlos.

En Datalvar AI usamos Cohere Rerank (rerank-multilingual-v3.0) y, cuando aplica, los rerankers de Voyage. Son APIs sencillas, latencia razonable (100-300 ms para 100 candidatos), coste contenido y mejora medible. En los proyectos donde hemos medido con rigor, añadir reranking mejora la métrica context relevancy de RAGAS entre 10 y 30 puntos porcentuales, y reduce drásticamente las alucinaciones porque el LLM recibe contexto verdaderamente relevante en lugar de “cosas que sonaban parecido”. Si tu sistema RAG no tiene reranking, probablemente estés dejando entre un 15% y un 30% de calidad sobre la mesa.

¿Por qué casi todos lo saltan? Porque añade latencia, añade coste y porque el tutorial básico de RAG no lo menciona. Es un componente que requiere disciplina arquitectónica para integrarse bien (paralelización, gestión de timeouts, fallback si el reranker cae) y eso desanima a equipos que ya están luchando por sacar el POC adelante. En la arquitectura de un RAG en producción, el reranking no es opcional para casos serios: es la diferencia entre “responde más o menos” y “responde con el chunk exacto que necesitas”. Cuando rediseñamos sistemas heredados para clientes, añadir un reranker bien integrado es una de las dos o tres palancas que más impacto generan con menos riesgo.

Sin reranking, el LLM trabaja con los “menos malos” del coseno. Con reranking, trabaja con los buenos de verdad.

¿Cómo orquestamos la generación con el LLM sin que alucine?

Con los chunks finales seleccionados, llegamos al LLM. Aquí es donde muchos equipos olvidan que la calidad de la respuesta sigue dependiendo de tres cosas: qué modelo usas, cómo construyes el prompt y cómo gestionas la respuesta. Elegir GPT-4o, Claude Sonnet 4.5, Gemini 1.5 Pro o un modelo open-source como Llama 3.1 70B o Qwen 2.5 cambia coste, latencia, calidad de razonamiento y compliance. En Datalvar AI elegimos por caso de uso y por restricciones del cliente: para alta calidad sin restricción de proveedor, Claude Sonnet suele liderar en respuestas con citas largas; para coste agresivo, GPT-4o mini o un open-source autoalojado; para on-premise total, Llama 3.1 70B sobre infraestructura del cliente.

El prompt importa mucho. No el “prompt engineering” como tema místico, sino la disciplina concreta: un system prompt claro con el rol, las reglas de respuesta (citar fuentes, no inventar, decir “no lo sé” cuando aplique), el formato de salida, restricciones de tono y dominio. Los chunks se pasan numerados y con sus metadatos para que el modelo pueda citarlos. La pregunta del usuario se envía limpia, sin instrucciones inyectadas, y con guardrails básicos contra prompt injection. Un patrón que nos funciona: pedirle al modelo que primero liste qué fragmentos son relevantes para la pregunta, luego que conteste, y finalmente que cite los chunks usados. Reduce alucinación porque obliga a pensar antes de generar.

La gestión de la respuesta también es ingeniería seria: streaming para mejorar la percepción de latencia, parsing de las citaciones para enlazarlas con los documentos originales, post-procesamiento para limpiar formatos raros, y un guardrail final que comprueba si la respuesta cumple criterios mínimos (no menciona información que no estaba en los chunks, no contradice fuentes, no se sale de dominio). Cuando integramos todo esto, la arquitectura de un RAG en producción deja de ser “le pregunto y ya está” para convertirse en un pipeline auditable, debuggable y mejorable. Cada respuesta queda con su trazabilidad: qué chunks se recuperaron, cuáles se rerankearon, cuáles entraron en el contexto, qué modelo respondió, cuánto tiempo tardó y qué coste tuvo.

¿Cómo evaluamos un RAG con RAGAS (faithfulness, context relevancy, answer relevancy)?

Sin evaluación sistemática, un RAG en producción degrada silenciosamente. Cambias el modelo de embeddings, añades documentos nuevos, modificas el prompt y nadie sabe si el sistema está mejor o peor. Después de seis meses, los usuarios reportan que “ya no funciona como antes” y empieza la caza al fantasma. La única solución honesta es evaluación continua, automatizada y con métricas concretas. En Datalvar AI usamos principalmente RAGAS como framework de evaluación, complementado con métricas propias de negocio.

Las métricas que medimos por defecto: faithfulness (¿la respuesta se apoya solo en los chunks recuperados o se inventa cosas?), context relevancy (¿los chunks recuperados son relevantes para la pregunta?), answer relevancy (¿la respuesta contesta lo que se preguntó?), context recall (¿se recuperaron todos los chunks que deberían?) y context precision (¿los chunks relevantes aparecen en las primeras posiciones?). Cada una se calcula con un LLM evaluador (típicamente GPT-4o o Claude Sonnet) sobre un test set construido a medida con el cliente. La inversión inicial en armar un test set decente (200-500 ejemplos) parece costosa pero se amortiza en la primera iteración seria.

La evaluación se integra en CI/CD: cada cambio en chunking, embeddings, prompt o reranker dispara la suite de evaluación y se publican métricas comparadas con la versión anterior. Si una métrica clave cae más de un umbral acordado (típicamente 3-5%), el cambio no se promueve a producción sin revisión. En producción ejecutamos evaluaciones sobre una muestra aleatoria de consultas reales (con anonimización cuando aplica) para detectar drift. Esta disciplina convierte la arquitectura de un RAG en producción en algo medible, mejorable y defendible ante el comité de dirección. Sin ella, todo es opinión y, antes o después, la opinión que pesa es la del que paga, no la del que mide.

¿Qué patrones de caché y latencia aplicamos para escalar?

Un RAG en producción serio tiene que aguantar carga concurrente con latencias razonables. Si cada consulta dispara embedding de la pregunta, búsqueda en el vector store, recuperación léxica, reranking y llamada al LLM en serie, te plantas en 3-6 segundos de latencia. Para muchos casos eso es inaceptable. Las palancas para reducirlo son varias y conviene activarlas con criterio, no todas a la vez.

La primera es el caché de respuestas completas para consultas frecuentes. Si el 30% de las preguntas se repiten textualmente o casi (típico en bots internos), un caché con clave en hash normalizado de la pregunta puede servirlas en milisegundos con cero coste de LLM. La segunda es el caché de embeddings: la pregunta del usuario se embedea para buscarla; si la cacheamos por hash, ahorramos una llamada a la API por cada repetición. La tercera es el caché de chunks rerankeados: si dos consultas similares recuperan los mismos chunks, podemos reutilizar el reranking. La cuarta es paralelización: búsqueda vectorial y léxica simultáneas, reranking solapado con preparación del prompt, etc.

En proyectos grandes añadimos un router semántico delante del RAG: clasificamos la pregunta entrante para decidir si necesita RAG real, si se contesta con FAQ cacheada, si necesita una tool/función específica (cálculo, búsqueda en CRM, consulta a base de datos relacional) o si simplemente es saludo/chitchat que no requiere recuperación. Este routing ahorra entre un 30% y un 60% de las llamadas pesadas al pipeline completo. La arquitectura de un RAG en producción que escala bien se parece más a un sistema de servicios con caché por capas que a un único pipeline lineal. Pensarlo así desde el principio evita rediseños dolorosos cuando llega el tráfico real.

¿Cómo medimos el coste real por consulta y por qué casi siempre se subestima?

El coste de un RAG en producción no es lo que dice la calculadora de OpenAI multiplicado por el número de consultas. Hay coste de embeddings de ingesta (una vez, pero significativo en corpus grandes), coste de re-embeddings cuando cambias de modelo, coste de almacenamiento del vector store (que en clouds gestionados como Pinecone o Weaviate Cloud puede ser sorprendentemente alto a partir de cierto volumen), coste por consulta (embedding de la pregunta + búsqueda + reranking + LLM), coste de la infraestructura de orquestación y coste de las llamadas a LLMs evaluadores en la pipeline de evaluación. Si sumas, la cifra puede ser entre 2 y 5 veces lo que el equipo estimó inicialmente.

En Datalvar AI desglosamos coste por consulta desde el primer día con observabilidad muy fina: cada respuesta queda registrada con tokens de entrada y salida del LLM, llamadas al reranker, llamadas al embedding, hits y misses de caché. Con eso construimos dashboards de coste por usuario, por departamento, por tipo de consulta. Sin este nivel de detalle, las decisiones de optimización son ciegas. Y las optimizaciones importan: pasar de Claude Sonnet a GPT-4o mini en consultas de baja complejidad puede recortar costes un 80% con caída de calidad imperceptible si el routing está bien hecho.

Una recomendación concreta: fija un presupuesto por consulta antes de diseñar la arquitectura. ¿0,005 euros? ¿0,02? ¿0,10? Eso condiciona qué modelos puedes permitirte, qué tamaño de contexto, cuántos chunks recuperar, si puedes permitirte reranking caro, etc. Diseñar la arquitectura de un RAG en producción sin una restricción de coste explícita lleva a sistemas que técnicamente funcionan pero financieramente no son sostenibles, y entonces vienen los recortes traumáticos que degradan la calidad de golpe. Es preferible empezar con presupuesto realista y subir el techo cuando el ROI esté demostrado, que al revés.

¿Qué observabilidad y trazabilidad necesita un RAG empresarial?

En producción tenemos que poder responder a tres preguntas en cualquier momento: por qué el sistema dio esta respuesta concreta, cómo está rindiendo globalmente y dónde está el cuello de botella si algo va lento. Para eso necesitamos observabilidad nativa, no parcheada a posteriori. Cada consulta atraviesa N componentes y cada componente debe emitir traces y métricas que un humano (o un agente) pueda inspeccionar.

Las herramientas que más usamos son LangSmith cuando el cliente acepta servicio gestionado y queremos rapidez, Langfuse cuando preferimos open-source autoalojado, y OpenTelemetry estándar cuando ya hay observabilidad corporativa (Datadog, Grafana, Honeycomb) y queremos integrarnos en su stack. La idea es la misma: trazas distribuidas con cada paso del pipeline (embedding, vector search, BM25 search, fusion, rerank, LLM call), tiempos, costes, parámetros y outputs intermedios. Cuando un usuario reporta “esta respuesta está mal”, abrimos el trace y vemos exactamente qué pasó.

Más allá de traces, montamos dashboards de salud del RAG: latencia P50/P95/P99 por componente, tasa de error, distribución de scores de recuperación, distribución de chunks por documento (para detectar si algún documento “monopoliza” las recuperaciones, señal de problema de chunking), métricas RAGAS sobre muestreo continuo, coste por hora y por día. La arquitectura de un RAG en producción sin observabilidad es una caja negra que tarde o temprano sorprende mal. Con observabilidad, los problemas se detectan antes de que los usuarios los noten, y la mejora continua deja de ser un PowerPoint y se convierte en un proceso de ingeniería normal.

Caso real: cómo rescatamos un RAG de soporte interno que estaba muriendo

Vamos al caso concreto para aterrizar todo lo anterior. Recibimos hace algo más de un año un cliente, una empresa industrial española de tamaño medio (unos 800 empleados, 12 plantas), que llevaba seis meses con un RAG interno para soporte técnico desarrollado por una consultora generalista. El sistema estaba pensado para que los técnicos de campo consultaran manuales, procedimientos y boletines de incidencias. Funcionaba “regular”: el equipo lo usaba a regañadientes, las respuestas eran a menudo imprecisas y los usuarios se quejaban de que “antes preguntaban a un compañero y ahora preguntan al bot y luego preguntan al compañero igual”.

Cuando entramos a auditarlo, encontramos los sospechosos habituales: parsing con PyPDF2 directamente, chunking con RecursiveCharacterTextSplitter(1000, 200) sin respetar estructura, embeddings con un modelo OpenAI v1 antiguo no reembedeado tras la salida de v3, vector store ChromaDB autoalojado sin tuning de índices, recuperación solo vectorial (sin BM25), sin reranking, prompt mínimo sin instrucciones de no alucinar ni citar fuentes, sin evaluación automática, sin observabilidad más allá de logs básicos. Un POC convertido en producción sin nada por medio. La calidad medida con un test set que construimos era pobre: faithfulness en torno a 0.62, context relevancy en 0.55, recall@10 sobre el 47%.

El rediseño llevó tres meses con un equipo de tres personas. Cambiamos parsing a Docling para PDFs técnicos con tablas, reescribimos el chunking a estructural respetando capítulos y secciones de los manuales, migramos a embeddings de Cohere multilingüe v3 (mejor para español técnico), pasamos el vector store a Qdrant autoalojado con índices HNSW calibrados, añadimos BM25 vía OpenSearch para recuperación híbrida con fusión RRF, integramos Cohere Rerank como segundo paso, refactorizamos el prompt con citaciones obligatorias y guardrails, montamos evaluación con RAGAS sobre 350 pares pregunta-respuesta etiquetados con expertos del cliente, e instrumentamos todo con Langfuse autoalojado. Tras el rediseño, faithfulness subió a 0.91, context relevancy a 0.84, recall@10 al 86%, y la latencia P95 bajó de 5,8 segundos a 2,1. Los técnicos pasaron de 30 consultas semanales a más de 600. El sistema empezó a generar ROI real.

La lección que sacamos y que repetimos a cada cliente nuevo: la arquitectura de un RAG en producción no se “actualiza” parcheando componentes sueltos. Se rediseña con criterio. Cambiar solo el chunking habría mejorado algo pero no lo suficiente. Cambiar solo el modelo de embeddings tampoco. La mejora vino de tratar el sistema como lo que es: un pipeline donde cada eslabón cuenta y donde el todo es mayor que la suma de las partes cuando están bien diseñadas. Sin ese rediseño integral, hubiéramos seguido moviendo palancas individuales sin mover la aguja real.

¿Qué errores típicos vemos al diseñar la arquitectura de un RAG en producción?

Repasamos los más comunes, ordenados por frecuencia e impacto. El primero, ya tratado, es chunking ingenuo: aceptar los defaults de la primera librería sin entender el documento. Genera fragmentos cortados a mitad de idea y embeddings degradados desde el origen. Es el equivalente a construir un edificio sobre un suelo sin compactar: lo demás puede estar bien hecho, pero el sistema cojea. Pasar a chunking estructural o semántico es probablemente la mejora individual con mejor retorno.

El segundo, ausencia de reranking. Confiar en que el top-k vectorial es ya el contexto óptimo es como sacar agua de un pozo sin filtrar: a veces sale limpia, a veces no. Añadir un reranker de calidad mejora la métrica de relevancia del contexto de forma medible y, en consecuencia, reduce alucinaciones. Es barato comparado con el coste del LLM y rara vez vemos una razón legítima para no hacerlo en producción seria.

El tercero, falta de evaluación. Un RAG sin RAGAS o equivalente vuela ciego. Funciona el día 1, degrada el día 90, alguien lo nota el día 180 y para entonces el daño reputacional ya está hecho. Montar el harness de evaluación antes de pasar a producción no es opcional. El cuarto, sin observabilidad: imposible debuggear ni optimizar lo que no se mide. El quinto, sobre-confiar en el LLM: pensar que el modelo “se las arreglará” con contexto mediocre. No lo hace. Garbage in, garbage out, ahora con factura mensual. El sexto, indexar todo sin curar: cuanto más basura indexada, peor relevancia, más coste de almacenamiento y más alucinaciones por contexto contaminado. La arquitectura de un RAG en producción no es agregar componentes nuevos; es eliminar fricción y ruido en cada capa.

¿Cómo evoluciona la arquitectura de un RAG en producción hacia patrones agénticos?

Una vez consolidada la arquitectura clásica, el siguiente paso natural es la introducción de patrones agénticos. Hablamos de agentic RAG: en lugar de un pipeline lineal pregunta → recuperación → generación, el LLM (o un orquestador) decide en tiempo de ejecución qué herramientas invocar, qué fuentes consultar, si necesita reformular la pregunta, si necesita varios pasos de recuperación con razonamiento intermedio, o si una pregunta requiere combinar RAG con consulta a una base de datos relacional, llamada a una API externa o ejecución de código.

Los patrones que más usamos en Datalvar AI en proyectos agénticos sobre RAG: query rewriting (reformular la pregunta del usuario para mejorar la recuperación, especialmente útil para preguntas ambiguas o conversacionales), multi-hop retrieval (recuperar, razonar sobre lo recuperado, formular una nueva consulta y recuperar de nuevo), self-correction (el modelo evalúa su propia respuesta y reintenta si detecta problemas), y tool use combinado con RAG (cuando la pregunta requiere datos en tiempo real o estructurados, el agente combina recuperación con llamadas a herramientas). Cada patrón añade latencia y coste, así que se aplican selectivamente, no por defecto.

La transición a patrones agénticos no sustituye la arquitectura clásica: la amplía. Los componentes base (parsing, chunking, embeddings, retrieval híbrido, reranking, evaluación) siguen siendo el cimiento. Lo que cambia es la lógica de orquestación encima. Quien intenta saltar a “agentic RAG” sin tener bien la arquitectura base se encuentra con un sistema impredecible, caro y difícil de evaluar. Quien primero estabiliza la base y luego añade agencia obtiene sistemas potentes y mantenibles. La arquitectura de un RAG en producción evoluciona, no se reemplaza, y la evolución se gana ganando primero la disciplina de fundamentos.

Preguntas frecuentes

¿Cuánto cuesta montar un RAG empresarial bien hecho?

Depende mucho del corpus, del volumen de consultas y del nivel de servicio esperado, pero damos rangos realistas para un proyecto serio. La implementación inicial (auditoría, diseño, ingesta, pipeline, evaluación, despliegue) en un proyecto empresarial mediano (5.000-50.000 documentos, 500-5.000 consultas/día) suele costar entre 40.000 y 120.000 euros en honorarios de consultoría especializada, sin contar infraestructura. La infraestructura mensual (cloud, APIs de LLM, vector store gestionado, observabilidad) puede ir desde 800-1.500 euros/mes en proyectos pequeños hasta 8.000-25.000 euros/mes en proyectos grandes con miles de usuarios activos.

A esto hay que sumar la operación: alguien tiene que ingestar documentos nuevos, monitorizar métricas, atender drift, actualizar prompts, evaluar cambios. Esa operación puede ser interna (típicamente 0,3-1 FTE para un sistema mediano) o externalizada. Hacer trampas en el presupuesto inicial casi siempre lleva a sobrecostes posteriores cuando hay que rediseñar lo que se hizo a la ligera. En Datalvar AI preferimos presupuestos realistas con tramos claros (POC validado, MVP en producción, escalado), de forma que el cliente decida en cada hito si seguir con conocimiento de causa.

¿Qué vector database elegir si empezamos un proyecto nuevo en 2026?

Si ya tienes Postgres en la organización y el volumen previsto está por debajo de 5-10 millones de vectores, empieza con pgvector. Es la opción más simple operativamente, integra con tu infraestructura existente, permite joins con metadatos relacionales y rinde sobradamente para la mayoría de casos. La inversión en aprenderlo y operarlo es mínima si tu equipo ya conoce Postgres.

Si el volumen es mayor, las latencias críticas (por debajo de 50 ms a P95) o necesitas filtrado avanzado por metadatos a escala, valora Qdrant autoalojado (excelente rendimiento, control total, sin lock-in) o Pinecone si prefieres servicio gestionado y predictibilidad operativa. Weaviate es buena opción si te encaja su modelo de schema y módulos. Evita ChromaDB en producción seria; es excelente para prototipos pero no está pensado para cargas empresariales. Y, sea cual sea la elección, calibra los índices con datos reales y mide recall@k contra exhaustivo, porque los defaults rara vez son óptimos.

¿Hace falta fine-tuning del LLM para que el RAG funcione bien?

En el 90% de los casos, no. Un buen RAG con un LLM general (Claude Sonnet, GPT-4o, Gemini 1.5 Pro o equivalentes open-source potentes) bien promptado y con contexto recuperado de calidad supera a un LLM fine-tuneado sin RAG decente. El fine-tuning tiene un retorno marginal frente a invertir el mismo esfuerzo en mejorar la arquitectura del RAG (chunking, reranking, evaluación).

El fine-tuning aporta valor real en casos específicos: tono y formato muy particulares que el system prompt no consigue (por ejemplo, generar JSON con un schema concreto de forma fiable), dominios con vocabulario extremadamente especializado donde el modelo base no maneja bien la jerga, o reducción de coste/latencia entrenando un modelo más pequeño para una tarea acotada. Recomendamos empezar siempre con RAG bien hecho y considerar fine-tuning solo cuando hay un caso de uso claro y medible donde el prompting y el RAG hayan tocado techo.

¿Cuándo tiene sentido un RAG y cuándo no?

Un RAG tiene sentido cuando el conocimiento que necesitas está en documentos (manuales, procedimientos, normativa, base de conocimiento, tickets resueltos, contratos, FAQs), cuando ese conocimiento cambia con frecuencia (un modelo fine-tuneado quedaría obsoleto), cuando necesitas trazabilidad de las respuestas (citar la fuente), y cuando el volumen y heterogeneidad del contenido hace inviable meterlo todo en el contexto del LLM. La mayoría de casos de uso empresariales de “asistente sobre nuestra documentación” caen aquí.

Un RAG no tiene sentido cuando el conocimiento es muy estructurado y se consulta mejor con SQL o APIs (datos transaccionales, métricas de negocio en tiempo real), cuando la tarea es generativa pura sin necesidad de información factual específica (escribir copy creativo), o cuando el volumen de información es tan pequeño que cabe en el contexto del LLM sin más. En estos casos, montar la complejidad de un RAG es ingeniería desproporcionada y casi siempre acaba en sistemas que cuestan más de lo que aportan.

¿Qué KPIs reportamos a negocio sobre un RAG en producción?

Reportamos dos capas. La capa técnica, para asegurar salud del sistema: faithfulness y context relevancy promedio (RAGAS), latencia P50/P95, tasa de error, coste por consulta, hit ratio de caché y volumen procesado. Esta capa nos permite detectar degradación antes de que llegue a usuarios y demostrar que el sistema sigue rindiendo según los SLAs acordados.

La capa de negocio mide el impacto real: adopción (usuarios activos diarios/semanales/mensuales, consultas por usuario), satisfacción (encuestas integradas tipo thumbs up/down con espacio para comentarios), tasa de resolución autónoma (qué porcentaje de consultas se resuelven sin escalado humano) y, cuando se puede instrumentar, horas ahorradas o tickets evitados frente a un baseline previo. Sin estos KPIs de negocio, el RAG se queda en proyecto técnico y nunca se defiende bien en comité. En Datalvar AI cerramos cada proyecto con dashboards de ambas capas porque sin ellas el éxito es una sensación y, en empresa, las sensaciones no se renuevan.

¿Cuánto tiempo lleva pasar un RAG de POC a producción de verdad?

Para un proyecto empresarial mediano con corpus heterogéneo (varias fuentes, miles de documentos, requisitos de permisos, integración con sistemas internos), el camino realista desde POC validado hasta producción estable es de 3 a 6 meses con un equipo dedicado de 2-4 personas (ingenieros de datos, ML engineer y product owner técnico). Los plazos más cortos que circulan en marketing suelen ignorar las fases de evaluación, observabilidad, integración real con permisos corporativos y endurecimiento de producción.

Los plazos se reducen si el cliente tiene infraestructura cloud madura, equipo técnico que puede operar el sistema, documentación ya digital y razonablemente estructurada, y un alcance bien acotado en lugar de “queremos un ChatGPT de toda la empresa”. Se alargan si la documentación está en silos con permisos complicados, si hay que negociar con muchos stakeholders el qué se indexa, si los requisitos de compliance obligan a on-premise total o si el equipo del cliente carece de capacidades MLOps básicas. Antes de comprometer plazos, en Datalvar AI hacemos siempre una fase de discovery de 2-3 semanas que devuelve un plan con hitos concretos basados en evidencia, no en optimismo.

¿Qué frameworks usamos (LangChain, LlamaIndex, propio)?

Para prototipado rápido y POCs, LlamaIndex suele encajar mejor para casos centrados en RAG por sus abstracciones específicas. Para sistemas más complejos con orquestación de agentes y herramientas, LangChain o LangGraph dan flexibilidad. Sin embargo, para producción seria muchas veces acabamos con un stack mixto: ciertas piezas de LlamaIndex o LangChain donde aportan, otras propias para piezas críticas donde el framework añade peso o limita el control.

Nuestra recomendación honesta: los frameworks aceleran el inicio, pero no construyas tu arquitectura asumiendo que dependerás de ellos al 100%. Las APIs de LLMs, vector stores y rerankers son lo suficientemente estables y bien documentadas como para que escribir tu propio orquestador en producción sea perfectamente viable y te dé control fino sobre latencia, observabilidad y costes. La arquitectura de un RAG en producción exitosa no se mide por qué framework usa, sino por las decisiones de diseño y la disciplina de evaluación. El framework es vehículo, no destino.