RAG en producción: por qué la demo funciona y el pipeline se rompe

La demo tomó dos semanas. Alguien indexó 40 documentos de producto, puso un paso de retrieval frente a un LLM, y el sistema respondió diez preguntas seguidas sin fallar. Presupuesto aprobado. Noventa días después, ese mismo sistema le dijo a un prospecto que el plan enterprise incluye una funcionalidad deprecada en marzo, y nadie pudo explicar por qué.

Hemos rescatado suficientes de estos sistemas como para que el patrón dejara de ser interesante. La demo no era mentira. Era un sistema distinto al que producción necesita. RAG (retrieval-augmented generation) es la arquitectura correcta para la mayoría de los problemas de conocimiento en empresas B2B: respuestas de soporte, habilitación de ventas, consulta de políticas internas, inteligencia de contratos. Pero la distancia entre "respondió preguntas en una reunión" y "responde 40 mil preguntas al mes sin inventar precios" es donde vive la ingeniería real. Y casi nada de eso tiene que ver con el modelo.

Por qué la demo funciona

Una demo corre bajo condiciones que producción no va a ver nunca más.

El corpus es pequeño y seleccionado a mano, normalmente 20 a 100 documentos que alguien curó la noche anterior. Las preguntas las hacen las personas que escribieron esos documentos, así que formulan las consultas igual que los docs formulan las respuestas. El índice tiene un día de creado, nada está desactualizado. Un usuario, cero concurrencia, y nadie mirando el medidor de costos.

Producción invierte cada una de esas condiciones. El corpus son miles de documentos que nadie curó. Los usuarios preguntan de formas que los documentos nunca anticiparon, en dos idiomas, con errores de tipeo. El índice empieza a envejecer desde el momento en que lo construyes. Y finanzas pregunta cuánto cuesta cada consulta en el mes dos.

Nada de eso se ve en una demo, y justo por eso la demo convence.

Las seis cosas que se rompen en producción

Frescura de los datos. Tus documentos cambian cada semana. Tu índice no se entera. Los pipelines de demo indexan una vez y nunca más; producción necesita una estrategia de sincronización con un SLA de frescura. Para la mayoría de los corpus B2B eso significa actualización por eventos cuando un documento fuente cambia, o como mínimo una reconstrucción nocturna con detección de cambios para no recalcular embeddings de 10 mil páginas que no cambiaron. La falla de arriba, recomendar una funcionalidad deprecada, no fue una alucinación. El retrieval funcionó perfecto contra un índice con cuatro meses de antigüedad. Y si tus datos fuente ya están regados en seis herramientas sin pipeline, arregla eso primero. Escribimos sobre esa secuencia en nuestra guía de infraestructura de datos.

Chunking. Cortar documentos cada 500 tokens es el default de todos los tutoriales, y está mal para la mayoría del contenido de negocio. Los cortes ingenuos separan una tabla de precios del párrafo que dice a qué clientes aplica, o una política de sus excepciones. Los sistemas de producción hacen chunking por estructura del documento: encabezados, secciones, tablas completas, 10 a 20 por ciento de overlap y metadata (fuente, sección, fecha, producto) en cada chunk. Tamaños entre 300 y 800 tokens cubren la mayoría del contenido, pero la respuesta correcta cambia según el tipo de documento. Por eso el chunking es una decisión de diseño, no un valor de configuración.

Calidad de retrieval. Similitud vectorial no es relevancia. La búsqueda vectorial pura falla con identificadores exactos, códigos de producto y términos raros. La búsqueda por keywords pura falla con paráfrasis. Los pipelines de producción corren retrieval híbrido, vectores densos más BM25, con un reranker (un cross-encoder como Cohere Rerank) sobre los 50 mejores candidatos. En nuestros engagements, ese único cambio mueve el hit rate de retrieval más que cualquier upgrade de modelo. Cuando una respuesta sale mal, los equipos culpan al generador. Cerca del 70 por ciento de las veces, el retriever le entregó el contexto equivocado.

Evals. El eval de la demo fue "la sala asintió". Producción necesita un golden set: 150 a 300 preguntas reales con respuestas de referencia y los documentos que deberían recuperarse, medidas por hit rate de retrieval, fidelidad al contexto y relevancia de la respuesta. Ragas, LangSmith o Braintrust convierten eso en un paso de CI/CD, así cada ajuste de prompt, cambio de chunking o swap de modelo corre contra el mismo set antes de salir. Y acá va la opinión, sin rodeos: si no puedes decir tu hit rate de retrieval con un número, no tienes un sistema RAG. Tienes una demo con usuarios.

Guardrails contra alucinaciones. La generación con fundamento necesita enforcement, no buenas intenciones. Eso significa citas obligatorias en la salida, validadas contra los chunks recuperados. Un chequeo de fidelidad antes de que salgan respuestas de alto riesgo. Umbrales de confianza bajo los cuales el sistema dice "no lo sé" y escala a un humano. Logging de cada respuesta con su contexto recuperado para poder auditar fallas. Un sistema que rechaza con honestidad el 5 por ciento de las consultas le gana a uno que responde el 100 por ciento y se equivoca con confianza en el 4 por ciento. Si vendes a industrias reguladas, esta sección es la diferencia entre una herramienta y un pasivo; el lado de políticas está en nuestro post de gobernanza de IA.

Costo por consulta. Una consulta cuesta embeddings más retrieval más reranking más generación. Con modelos frontera y contextos largos, un pipeline descuidado termina entre 0.05 y 0.15 dólares por consulta, que con 100 mil consultas mensuales es dinero real. Los sistemas de producción rutean: cache para preguntas repetidas (el tráfico de soporte se repite muchísimo, un hit rate de cache de 30 a 40 por ciento es normal), un modelo pequeño para consultas fáciles, el modelo frontera solo cuando el router decide que hace falta. El costo por consulta va en el dashboard junto al hit rate, no como sorpresa en la factura.

Cómo se ve un pipeline listo para producción

Siete etapas, cada una con un dueño y una métrica:

1. Ingesta. Conectores a las fuentes reales (wiki, CRM, tickets, contratos) con detección de cambios. Los exports manuales son la razón por la que los índices envejecen.
2. Procesamiento. Chunking por estructura con metadata en cada chunk.
3. Indexación. Una base vectorial acorde a tu escala. pgvector maneja millones de chunks dentro del Postgres que ya corres; Qdrant o Pinecone se ganan su lugar con filtrado y escala más exigentes.
4. Retrieval. Búsqueda híbrida más reranking, medida como recall contra el golden set.
5. Generación. Prompts que exigen fundamento y citas verificables.
6. Evaluación. El golden set corriendo en CI/CD en cada cambio.
7. Observabilidad. Trazas por consulta que muestran qué se recuperó, qué se generó, costo, latencia y feedback del usuario, en un dashboard que alguien de verdad revisa.

Para una empresa B2B con un corpus real, eso es una construcción de 8 a 12 semanas para un primer sistema en producción. La demo es la semana uno. Todo lo que viene después de la semana uno es lo que hace que el sistema sobreviva el contacto con usuarios.

Cuándo RAG es la herramienta equivocada

La mitad de los proyectos RAG que nos piden cotizar no deberían ser RAG.

Si la respuesta vive en una base de datos, quieres tool calling y SQL, no búsqueda semántica sobre exports. "Cuál fue nuestro churn del Q2" es un query, no un problema de retrieval.

Si el corpus tiene menos de 50 documentos estables, mételo en la ventana de contexto y sigue adelante. Los modelos de contexto largo dejaron obsoleto el mini-RAG, y un índice es mantenimiento que te pertenece para siempre.

Si el trabajo es ejecutar acciones y no responder preguntas, necesitas un agente con herramientas, donde el retrieval puede ser una entre varias. Es otra arquitectura, y la cubrimos en agentes de IA para empresas B2B.

Si el contenido fuente está mal o se contradice, RAG va a recuperar la contradicción con total fidelidad. Ningún pipeline arregla un corpus que no se pone de acuerdo consigo mismo.

RAG se gana su complejidad cuando el corpus es grande, cambia seguido y cada respuesta tiene que ser trazable a una fuente. Eso cubre una parte enorme del trabajo de conocimiento B2B. No lo cubre todo, y los equipos que se saltan esta pregunta construyen el sistema equivocado con mucha confianza.

Dónde aterriza esto

La brecha entre demo y producción no es un problema de modelo. Es un problema de ingeniería con seis puntos de falla conocidos y un arreglo conocido para cada uno. Ese es el trabajo para el que existe nuestra práctica de IA: sistemas de IA listos para producción que salen con evals, guardrails y un modelo de costos incluido, porque el ROI medible exige la parte de medir. Y si todavía estás decidiendo si tu capa de datos puede siquiera alimentar un sistema RAG, esa es exactamente la clase de pregunta para la que construimos el DGTL Readiness Index.

Relacionado: Agentes de IA para empresas B2B → · Guía de infraestructura de datos → · Gobernanza de IA →