RAG en Producción: 7 Problemas Reales Fuera del PoC

El día que tu RAG sale del notebook

El primer demo de RAG sale bien casi siempre. Indexas 50 PDFs, montas un Pinecone o un pgvector, conectas un LLM y haces tres preguntas que ya sabes que están en la documentación. El modelo responde con coherencia. Alguien aplaude. Lo llamamos proof of concept.

El problema empieza el día que ese mismo sistema tiene que responder a un comercial preguntando por un cliente que no existe en la documentación oficial, a un técnico que usa la jerga interna del equipo y a un director financiero que necesita una cifra que vive en una base de datos, no en un PDF. Ese día el RAG deja de ser una demo y se convierte en un problema de ingeniería.

Llevamos un par de años poniendo RAGs en producción en empresas con catálogos de miles de productos, bases documentales pesadas y agentes que ejecutan acciones reales sobre CRMs y ERPs. Estos son los siete problemas que aparecen sistemáticamente entre el PoC y producción — y cómo los resolvemos.

Problema 1: Chunking sin contexto de dominio

El tutorial estándar te dice que partas los documentos en trozos de 500 tokens con 50 de solape. Lo aplicas, indexas, y descubres que el agente devuelve fragmentos sin la información que importa.

El caso típico: un cliente nuestro de retail con un catálogo de unos 12.000 SKUs. Cada ficha de producto tenía nombre, código interno, especificaciones técnicas y precio. El chunking por tamaño cortaba los fragmentos a mitad de tabla, dejando el código del producto en un chunk y las especificaciones en otro. El modelo recuperaba las especificaciones, no sabía a qué producto pertenecían y respondía con un código equivocado.

La solución no es subir el tamaño del chunk — es romper por estructura semántica del documento, no por número de tokens. Para fichas de producto: chunk = ficha completa, con su SKU repetido al inicio como ancla. Para contratos: chunk = cláusula, con la sección y subsección como prefijo. Para Confluence: chunk = sección H2 con el breadcrumb completo metido en el metadata.

Esto requiere un parser propio por tipo de documento. Es trabajo aburrido, pero diferencia un RAG que funciona de uno que adivina.

Problema 2: Embeddings que no entienden tu jerga

Los modelos de embeddings se entrenan sobre internet. Si tu empresa usa el término "orden de pedido" internamente y tus documentos hablan de "OP-2024" o "order intent" indistintamente, el embedding no sabrá que son lo mismo. El usuario pregunta por "OP" y el sistema recupera fragmentos genéricos sobre pedidos en cualquier sector.

Tres formas de atacarlo, en orden de coste creciente:

1. Glosario inyectado en query. Antes de embeddar la pregunta del usuario, expandes la query con sinónimos internos. "¿Cuántas OP tenemos abiertas?" se convierte en "¿Cuántas órdenes de pedido (OP, order intent) tenemos abiertas?". Coste casi cero, resuelve el 70% de los casos.
2. Re-ranker entrenado. Tras la búsqueda vectorial inicial, un modelo más pequeño re-ordena los resultados usando un dataset etiquetado por el equipo. Coste medio, mejora notable.
3. Embeddings finetuneados. Adaptas un modelo de embeddings a tu dominio con pares (query, documento relevante). Coste alto, sólo tiene sentido si la jerga interna es muy especializada (sectores regulados, B2B técnico).

Empieza por la 1. La mayoría de PoCs nunca pasan de ahí — y la mayoría no necesitan más.

Problema 3: Recall alto, precision baja (y cuesta dinero)

El instinto del PoC es subir el top_k a 20. "Más contexto, mejor respuesta". Falso por dos motivos.

Primero, el modelo se confunde. Si le metes 20 fragmentos parecidos en el prompt, el razonamiento se diluye. El LLM termina mezclando información de varios chunks y dando respuestas que parecen coherentes pero son inventadas a partir de pedazos correctos.

Segundo, cuesta dinero. Cada token enviado al modelo se paga. Un agente con top_k=20 y embeddings sobre 1.000 consultas diarias puede multiplicar por 4 la factura del LLM frente a top_k=5 bien afinado.

La fórmula que aplicamos: top_k bajo (3-5) + re-ranker que ordena por relevancia + filtro duro por score mínimo. Si los 3 mejores chunks no superan un umbral de similitud, el agente responde "no tengo información suficiente" en vez de inventar. Esto último es contraintuitivo para quien viene del demo — sentir que el sistema "se rinde" parece un fallo. En producción es lo que protege la confianza del usuario.

Problema 4: Sin citation, no hay confianza

Un agente que responde "el cliente tiene 3 facturas pendientes" sin enlazar a las facturas no se puede usar en una empresa seria. El responsable que lee la respuesta no tiene cómo verificar y no la va a usar para tomar decisiones.

La citation no es decoración. Es la prueba de que el modelo no ha inventado. Y obligar a citar, además, reduce drásticamente las alucinaciones — el modelo "sabe" que va a tener que justificar y se ciñe a los fragmentos.

En proyectos donde el RAG mezcla documentos y datos estructurados (un caso habitual: Confluence + Postgres), el agente debe poder citar las dos cosas: enlace al documento y a la fila SQL. Internamente esto se monta con metadata que viaja con cada chunk y con tools de SQL que devuelven, además del resultado, el query ejecutado. La respuesta final incluye ambas referencias.

Regla operativa: si no se puede citar, no se responde. Y si el modelo intenta responder sin citation, el guardrail lo intercepta y reintenta con un prompt más estricto.

Problema 5: Re-indexación, el coste oculto

El PoC indexa 50 PDFs una sola vez. Producción indexa documentos que cambian todos los días. Si reindexas todo cada noche, pagas embeddings que no han cambiado y bloqueas el sistema durante la reindexación. Si no reindexas, el RAG envejece.

La pieza que falta en casi todos los PoCs es un pipeline de indexación incremental: detectar cambios en la fuente original (Drive, SharePoint, Confluence, Postgres), calcular qué chunks han cambiado, generar solo esos embeddings nuevos y actualizar el vector store. En un cliente con un Drive corporativo de unos 30.000 documentos, este cambio bajó el coste mensual de embeddings un 92% frente a la reindexación completa diaria.

Requisitos para construirlo: hash por chunk para detectar cambios reales (no falsos positivos por metadata), versión por documento, y un job que corre cada N minutos en vez de cada noche. No es trivial, pero sin esto el RAG es caro y siempre va por detrás de la realidad.

Problema 6: Evals continuas, no benchmark único

"Probamos 50 preguntas y respondió bien" no es una métrica. Es un benchmark estático en el día 0.

El problema: el RAG en producción se degrada por motivos que no son obvios. Cambia el proveedor del LLM y modifica el comportamiento de su modelo. Se añaden 200 documentos nuevos que introducen ambigüedades. Un equipo cambia la nomenclatura interna. Cualquiera de esos cambios puede bajar la calidad sin que nadie lo detecte hasta que un usuario se queja.

Lo que sí funciona: un dataset de evaluación curado (50-200 preguntas con respuesta esperada y fragmentos esperados), un pipeline que lo ejecuta automáticamente cada semana o tras cada cambio del prompt, y métricas de retrieval (recall@k, MRR) más métricas de respuesta (groundedness, exactitud factual evaluada por LLM-as-judge calibrado contra revisión humana).

Cuando una métrica cae más de un umbral, se genera una alerta. Esto convierte el RAG en un sistema con SLO técnico, no en un "experimento que parecía ir bien".

Problema 7: Cuándo RAG no es la respuesta

El RAG está sobrevendido. Hay preguntas que la búsqueda vectorial responde mal por diseño — y empeñarse en forzarlas ahí es la causa de muchos PoCs estancados.

Tres ejemplos:

• "¿Cuántos contratos firmamos en marzo?" — Esto es SQL, no RAG. La respuesta vive en una base de datos. El agente debe llamar a una tool que ejecuta SELECT COUNT(*) FROM contracts WHERE month = 3, no recuperar fragmentos.
• "Crea un resumen mensual de incidencias" — Esto es SQL + agregación + generación. RAG no aporta.
• "¿Quién es el responsable de seguridad en infraestructura?" — Esto es búsqueda exacta sobre un sistema de RRHH, no semántica.

El patrón correcto: el agente decide qué herramienta usar según la pregunta. RAG para conocimiento documental, SQL/tool calling para datos estructurados, búsqueda exacta para identificadores. El "RAG-only" es el síntoma de un PoC que no ha madurado a sistema híbrido.

RAG como una de las seis capas de contexto

Hay una visión que diferencia bien un RAG técnico maduro de uno PoC: entender que RAG no es el contexto del modelo, sino una de seis capas de contexto que un agente bien construido orquesta:

1. System prompt — quién es el agente, cómo se comporta, qué puede y qué no
2. Memoria de largo plazo — qué sabe sobre este usuario, esta sesión, este caso
3. RAG — qué documentos son relevantes para la pregunta actual
4. Tools — qué acciones puede ejecutar y qué devuelven
5. Historial de conversación — qué se ha dicho antes
6. User prompt — la pregunta concreta

Esta forma de mirarlo resume bien por qué los PoCs se atascan: tratan RAG como capa única en vez de una pieza dentro de un diseño de contexto completo.

Diseñar bien las seis capas — qué información vive en cada una, cuánto presupuesto de tokens se le asigna, cómo se sincronizan entre sí — es lo que llamamos context engineering. Y es donde está hoy la diferencia entre un agente que funciona y uno que adivina.

Cómo lo construimos en producción

Cuando llegamos a un proyecto de RAG, el primer entregable rara vez es el indexador. Es un mapa de las preguntas que el agente tiene que responder, segmentadas por tipo (documental, dato estructurado, mixto), volumen estimado y nivel de riesgo si falla.

Sobre ese mapa decidimos qué partes son RAG, qué partes son tool calling sobre datos estructurados y qué partes son híbridas. Después montamos el pipeline de indexación incremental, el dataset de evals con casos reales del cliente, los guardrails de citation obligatoria y el panel de métricas.

Detrás de esos pipelines hay un equipo de desarrolladores que cree que la ingeniería seria empieza por entender el negocio, no por elegir el modelo. Antes de embeddings o vector stores, mapeamos cómo decide tu equipo y qué fallo no te puedes permitir. La capa técnica viene después — y la cuidamos como cualquier sistema que tiene que aguantar años en producción.

Producción significa que el sistema sigue funcionando dentro de seis meses, no que respondió bien hoy. Esa es la frontera entre PoC y proyecto.

Si tienes un RAG atascado entre el demo y producción — o si tu equipo está vectorizando todo sin un plan claro de evals, citation y re-indexación — podemos auditar tu pipeline y entregarte el plan para llevarlo a producción con criterio.