RAG en producción: qué se rompe de verdad cuando empiezan a preguntar clientes reales

Puedes construir una demo funcional de Retrieval-Augmented Generation en una tarde. Incrustas unos documentos, los metes en un almacén vectorial, recuperas los cinco fragmentos más parecidos por similitud coseno y los pegas en el prompt. Responde preguntas. En una grabación de pantalla parece magia.

Luego lo pones delante de clientes reales y la distancia se abre.

Alguien pregunta en el tercer idioma que soportas. Alguien pregunta por una política que existe en dos versiones contradictorias en tu propia web. Alguien pregunta algo que tu contenido sencillamente no cubre, y el sistema responde igualmente: con fluidez, con seguridad y con un error. Veinte personas preguntan a la vez mientras se está ejecutando un recrawl. Un PDF escaneado en lugar de escrito se convierte en ruido de recuperación que envenena en silencio todas las respuestas cercanas.

Nada de esto aparece en una demo, porque una demo usa documentos limpios, un idioma, un usuario y preguntas cuya respuesta ya conoce quien la construyó. Todo lo caro de RAG vive en la distancia entre esas dos situaciones.

Esta guía trata precisamente de esa distancia. Da por hecho que ya sabes qué es RAG; si no, empieza por nuestra explicación de qué es un chatbot RAG y cómo funciona y vuelve luego. Lo que sigue es la capa de encima: la ingeniería que decide si un sistema de recuperación sobrevive al contacto con usuarios reales.

Cada vez que crecen las ventanas de contexto, alguien declara obsoleto a RAG. No ha ocurrido, y las razones son estructurales, no temporales.

El contexto utilizable es más pequeño que el contexto anunciado. Un modelo que acepta 200.000 tokens no razona igual de bien sobre los 200.000. El efecto está bien documentado: el trabajo "Lost in the Middle" de Liu et al. (2023) mostró cómo cae la precisión con la información enterrada en mitad de entradas largas, y cada generación posterior de modelos de contexto largo ha llegado con alguna versión de la misma advertencia. La calidad se degrada antes que el límite duro. Y la base de conocimiento real de una empresa mediana no son 200 páginas: son decenas de miles.

El fine-tuning cambia el comportamiento, no el conocimiento. Es el malentendido más caro del sector. El fine-tuning es excelente para enseñar a un modelo un formato, un tono o un patrón de razonamiento. Es una forma pobre y poco fiable de enseñarle hechos, y se degrada mal cuando los hechos cambian, que es lo que hacen cada semana en precios, políticas e inventario.

El coste escala en la dirección equivocada. Meter todo el corpus en cada petición significa pagar por todo el corpus en cada pregunta. Recuperar significa pagar por los pocos miles de tokens relevantes. Con volumen real de mensajes, esa diferencia es todo el margen.

La auditabilidad es un requisito, no una función. En finanzas, sanidad y derecho, una respuesta sin fuente trazable no sirve. La recuperación produce ese rastro gratis, porque el sistema ya sabe de qué documento salió cada pasaje.

Así que la pregunta interesante ya no es si recuperar. Es por qué tantos sistemas de recuperación lo hacen mal.

La causa más común de malas respuestas no es el modelo, ni los embeddings, ni la base vectorial. Es el corpus.

Hemos visto una base de conocimiento de un cliente en la que aproximadamente la mitad de los documentos eran casi duplicados de la otra mitad: la misma política republicada con pequeñas diferencias de formato en una web de marketing, un centro de ayuda y un PDF archivado. La recuperación devolvía obedientemente cinco fragmentos que eran cinco copias del mismo párrafo, así que el modelo veía una franja estrecha de evidencia en vez de cinco perspectivas, y el presupuesto de top-k se gastaba en redundancia. Arreglarlo fue trabajo manual y nada glamuroso de tuberías de datos. Aun así mejoró la calidad de las respuestas más que cualquier ajuste de recuperación que hiciéramos ese mes.

Los reincidentes:

• PDF escaneados y daños de OCR. Un texto que al ojo humano se lee bien puede estar destrozado estructuralmente: orden de columnas revuelto, tablas aplastadas en sopa de palabras. Los embeddings de texto destrozado se recuperan de forma impredecible.
• Plantillas y banners de consentimiento. Rastrea una web de forma ingenua y cada página arrastrará el mismo aviso de cookies, el mismo menú y el mismo pie. Ahora todos los fragmentos comparten un prefijo idéntico y grande, y la similitud semántica entre páginas sin relación sube. Por eso nuestro rastreador elimina consentimiento y estructura antes de indexar nada.
• Muros de acceso y páginas vacías. Una página de inicio de sesión tiene texto, así que una tubería ingenua la ingiere. No aporta nada y lo diluye todo.
• Contradicciones que nadie ha visto. Dos páginas indican plazos de devolución distintos. La recuperación encuentra las dos. El modelo elige una. Elija la que elija, a alguien le van a decir algo incorrecto.

La regla práctica: la puerta de calidad va antes de indexar, en exactamente un lugar del código, y la aplica cualquier ruta capaz de añadir contenido. Cuando las reglas de ingesta viven en tres sitios, derivan, y la diferencia de calidad entre tu onboarding y tu recrawl se convierte en un misterio que nadie sabe reproducir. Para la versión práctica, mira nuestra guía para construir una base de conocimiento limpia.

Una única búsqueda vectorial densa es el primer borrador de la recuperación. En producción, la recuperación es una tubería de cuatro o cinco etapas, y cada una arregla un modo de fallo que las demás no alcanzan.

Expansión de la consulta. Las consultas reales son cortas, con faltas y llenas de jerga interna. Expandir la consulta con sinónimos y siglas desarrolladas antes de incrustarla mejora el recall de forma medible, sobre todo en esas preguntas de dos o tres palabras que dominan el tráfico real de chat.

Búsqueda híbrida: densa más dispersa. Los embeddings densos captan el significado pero fallan con los tokens exactos: SKU, códigos de error, números de modelo, apellidos. La búsqueda por palabras clave (en nuestro caso BM25 sobre un tsvector de Postgres) acierta justo en eso y falla con las paráfrasis. Ejecutar ambas y fusionar los resultados con Reciprocal Rank Fusion es el estándar de producción, no una optimización.

Un detalle que pesa más de lo que debería: la búsqueda por palabras clave depende del idioma. Postgres reduce "precios" a "preci" solo si le dices que el texto está en español. El turco, el alemán, el español, el francés, el italiano y el portugués necesitan cada uno su configuración, y los idiomas sin lematizador integrado —japonés, coreano, chino— necesitan un plan de reserva deliberado, no accidental. Un sistema RAG multilingüe que lematiza cada consulta como si fuera inglés pierde recall en silencio en todos los demás idiomas. Si atiendes más de un mercado, lee junto a esta sección nuestra guía de chatbots multilingües.

Reranking. La fusión te deja veinte o treinta candidatos plausibles. Un reranker cross-encoder puntúa cada uno contra la consulta real y sube de forma rutinaria el pasaje verdaderamente correcto del puesto 15 al top 3. Si tu sistema "siempre cita una página que casi acierta", lo primero que hay que mirar es la etapa de reranking que falta.

Caché, con cuidado. Preguntas idénticas no deberían reejecutar toda la tubería. Pero cachea la recuperación, con clave de consulta y top-k, no la respuesta generada; si no, servirás una respuesta caducada después de que el documento subyacente se haya actualizado.

Todo sistema RAG serio puntúa su recuperación antes de generar y usa esa puntuación para indicarle al modelo cuánto debe fiarse del contexto: responder directamente, responder con matices, o declinar y derivar a una persona. Es la defensa contra alucinaciones más importante que existe.

También es el ajuste con más probabilidades de estar mal, porque los valores por defecto suelen inventarse en lugar de medirse.

Aquí va un error del que merece la pena aprender: es nuestro. Nuestro umbral de "confianza alta" estaba en 0,82 de similitud coseno, un número que suena adecuadamente estricto. Luego lo contrastamos con tráfico real y descubrimos que menos del 2 % de las respuestas reales lo cruzaba. Las coincidencias semánticas densas rara vez superan aproximadamente 0,80, incluso cuando el pasaje recuperado es obvia y exactamente el correcto. Es decir, al modelo se le decía "este contexto solo es parcial" en casi todas las preguntas, y se cubría: respuestas correctas envueltas en una incertidumbre innecesaria. La recuperación estaba bien. El que estaba mal era el metro.

La solución no fue relajarlo todo. Sacamos una muestra de conversaciones reales en la banda ambigua y las leímos: entre 0,64 y 0,68 las respuestas eran concretas y correctas, citando límites de plan exactos y reglas exactas. Pero los huecos genuinos —preguntas sobre una integración que no soportamos— puntuaban en el mismo rango y se cubrían con razón. Así que bajamos el listón alto a un nivel que las coincidencias reales pueden alcanzar, mantuvimos la banda intermedia ambigua como "parcial" y dejamos exactamente donde estaba la protección inferior de "no inventes".

Las lecciones transferibles: calibra los umbrales contra tu propia distribución, no contra tu intuición; lee las conversaciones reales de la banda que estás ajustando, porque las puntuaciones agregadas esconden la diferencia entre una buena respuesta y un fallo bien puntuado; y convierte cada umbral en una variable de entorno, para que una mala calibración sea una reversión de un minuto y no un despliegue.

El troceado (chunking) parece una decisión de formato. En realidad es una decisión de recuperación, y de ahí sale una parte sorprendente de las quejas del tipo "el bot no encuentra algo que está clarísimamente en nuestra documentación".

Cortar a longitud fija cada 500 tokens partirá una tabla por la mitad, separará un encabezado del párrafo que introduce y dividirá un procedimiento numerado en dos fragmentos de modo que ninguno sirva por sí solo. Un troceado consciente de la estructura —respetar primero encabezados y límites de párrafo, luego fusionar hacia el tamaño objetivo y partir los segmentos largos en límites de frase— cuesta un día de implementación y se amortiza de inmediato. Nuestra tubería apunta a unos 800 tokens por fragmento con 200 de solapamiento, un punto de partida razonable para contenido de empresa con mucha prosa.

El problema más sutil es que un fragmento, una vez aislado, pierde el contexto que lo hacía significativo. "El envío estándar tarda de 3 a 5 días laborables" es un objetivo de recuperación inútil si el fragmento no dice de quién es el envío, qué región o qué línea de producto. Recuperado solo, el modelo puede aplicarlo a una pregunta completamente distinta.

La solución es enriquecer cada fragmento con su propia procedencia antes de incrustarlo —título del documento, encabezado de sección, fuente— para que el texto incrustado lleve el contexto que un lector humano habría tenido de la página que lo rodea. Anthropic popularizó una versión de esto como "contextual retrieval" y reportó una caída sustancial de los fallos de recuperación. Y no hace falta una pasada de LLM para que valga la pena: un prefijo determinista construido con los metadatos del propio documento captura buena parte del beneficio a coste marginal cero, que es lo que ejecutamos en producción.

Un aviso desde la experiencia: si cambias tu estrategia de troceado o de contextualización, te has comprado una migración. Todos los fragmentos existentes se incrustaron con el esquema antiguo. Planifica un reindexado dirigido, documento a documento; nunca un reembebido masivo a ciegas de un corpus en producción.

Los equipos discuten sobre calidad de recuperación. Lo que de verdad tumba sistemas es la fiabilidad.

La ingesta es un proceso largo, multietapa y parcialmente externo: descargar, extraer, trocear, incrustar (una llamada de API de pago que puede toparse con límites de tasa), escribir, marcar como completado. Todo lo que corre durante minutos cruzando una frontera de red acabará interrumpiéndose, y esas interrupciones no son raras.

Nuestro fallo más instructivo fue silencioso. Una usuaria lanzó un rastreo de su web y luego navegó a otra página. La función serverless que atendía su petición murió a medio vuelo: después de escribir los fragmentos y los embeddings, pero antes de marcar el documento como procesado. Sin excepción. Sin error en monitorización. Solo un documento completamente indexado que se mostraba de forma permanente como "indexando", y una usuaria que volvió a rastrear el mismo sitio cuatro veces en diecinueve horas intentando que cambiara una etiqueta, y luego se fue.

Esa clase de fallo nos enseñó tres invariantes que merece la pena copiar:

• Ordena las escrituras para fijar primero la verdad que ve el usuario. Cambia la marca de procesado inmediatamente después de escribir el contenido de forma duradera; estadísticas, invalidación de caché y demás contabilidad van después, cada una acotada y de mejor esfuerzo. Nunca dejes un paso opcional entre el trabajo real y la marca que lo registra.
• Haz idempotente cada manejador de trabajos y luego reencola con generosidad. Si un worker muere a mitad, el siguiente barrido debe poder reejecutar el trabajo entero sin riesgo. Los manejadores de "borrar e insertar" hacen que los reintentos salgan gratis.
• Añade un barrido autorreparador. Un trabajo periódico que busque documentos atascados en estado inacabado y los reencole convierte un fallo permanente y visible en un retraso de unos minutos. Es la pieza de fiabilidad con mayor retorno de una tubería RAG, y casi nadie la construye antes de haberse quemado.

Bajo carga concurrente, añade también la infraestructura aburrida: una cola de verdad en lugar de promesas de "lanza y olvida", límites de pool de conexiones que tengan en cuenta que las llamadas de embedding mantienen conexiones abiertas, y aislamiento por inquilino para que el rastreo de 900 páginas de un cliente no ahogue el chat en vivo de todos los demás.

La calidad de un RAG no se juzga a ojo. Todos los equipos creen que pueden, y todos se equivocan, porque el modo de fallo de un mal sistema RAG es una respuesta fluida, plausible y bien formateada que resulta ser falsa. Se lee exactamente igual que una buena.

El montaje mínimo viable de evaluación es más pequeño de lo que la gente teme:

Un conjunto dorado. De treinta a cien preguntas reales con respuestas correctas conocidas, sacadas de tu historial de soporte y no inventadas. Reejecútalo tras cada cambio en recuperación, troceado, prompts o versión del modelo. Es un test de regresión y debe fallar en voz alta.

Separa la puntuación de recuperación de la de respuesta. Cuando cae la calidad necesitas saber si el pasaje correcto no se recuperó o se recuperó y se ignoró. Tienen arreglos completamente distintos, y una única puntuación de extremo a extremo no puede distinguirlos.

Vigila la distribución de confianza en el tiempo. Un desplazamiento en el histograma de puntuaciones de recuperación es un aviso temprano: normalmente alguien ha añadido un lote grande de contenido de baja calidad, o el tráfico se ha movido a temas que tu corpus no cubre.

Trata el "no lo sé" como tu telemetría más valiosa. Cada respuesta de baja confianza y cada escalado es un hueco de contenido ya etiquetado. Los equipos cuyos asistentes mejoran de forma visible mes a mes son, casi sin excepción, los que leen esa lista cada semana y escriben la página que falta. Nuestra guía de analítica de chatbots cubre las métricas que merece la pena mirar.

Y mide la desviación de tickets con honestidad. Una conversación no está resuelta porque el cliente haya dejado de escribir; lo está porque no te escribió un correo una hora después. Si tu plataforma no puede conectar esos dos eventos, estás optimizando un número que te halaga.

Dos sistemas RAG con arquitectura idéntica pueden triunfar y fracasar en el mismo sector. La diferencia no suele estar en la tubería.

El lenguaje del dominio es trabajo real. Las abreviaturas sanitarias, los nombres de instrumentos financieros, los formatos de cita jurídica y las convenciones de SKU rompen la recuperación genérica de maneras muy concretas. Un cliente de finanzas pregunta por "el de tres años" y se refiere a un producto específico; un embedding genérico piensa en tiempo. Eso se arregla con diccionarios de sinónimos, filtros de metadatos y contenido escrito también para la máquina, no con un modelo más grande.

La disciplina de alcance gana a la capacidad. La forma más rápida de destruir la confianza en un asistente es dejar que responda preguntas fuera de lo que realmente sabe. Un límite explícito —este agente responde sobre nuestros productos, políticas y documentación, y deriva todo lo demás— reduce las respuestas embarazosas más que cualquier mejora de recuperación. Es también la corrección que desplegamos tras ver asistentes reales derivando hacia terreno genérico e inútil.

La adopción es un requisito de lanzamiento. Un asistente del que nadie avisó al equipo de soporte acaba saboteado por el equipo de soporte. Alguien tiene que ser dueño de los huecos de contenido, leer los escalados y decidir qué puede prometer el asistente.

La confianza empresarial tiene una lista de comprobación. Acceso por roles para que la recuperación respete quién pregunta, rastros de auditoría que muestren qué fuente produjo qué respuesta, residencia de datos clara, controles de retención y una declaración inequívoca de que las conversaciones de clientes no se usan para entrenar modelos públicos. No son funciones que se añaden tras una revisión de seguridad: son la razón por la que esa revisión se pasa o no. Nuestra guía de seguridad y privacidad de chatbots repasa qué verificar en un proveedor.

Si lo construyes en casa, el alcance honesto no es "una base vectorial y un prompt". Es una puerta de calidad de contenido, una tubería de recuperación multietapa, umbrales de confianza calibrados, una cola de trabajos con manejadores idempotentes y barrido autorreparador, un arnés de evaluación y un bucle de analítica; más la operación continua de todo ello. Merece la pena cuando la calidad de recuperación es tu producto. Es un mal uso del año de un equipo pequeño cuando la recuperación es solo el medio para responder preguntas de clientes.

Si compras, la lista de este artículo se convierte en tu due diligence. Pregunta al proveedor: ¿usáis recuperación híbrida o solo densa? ¿Hay etapa de reranking? ¿Cómo se fija el umbral del "no lo sé" y puedo cambiarlo? ¿Qué le pasa a un documento si la ingesta se interrumpe a medias? ¿Puedo ver qué fuente produjo una respuesta concreta? ¿Qué pasa con la búsqueda por palabras clave en mi idioma? ¿Qué preguntas no supo responder el asistente la semana pasada? Un proveedor que no sepa contestar a eso ha construido una demo.

Esta es la capa que Chatloom existe para asumir. La tubería descrita a lo largo del artículo —troceado consciente de la estructura con enriquecimiento contextual, expansión de consultas, recuperación híbrida densa más dispersa con lematización por idioma, fusión RRF, reranking cross-encoder, confianza calibrada con un "no lo sé" de verdad, trabajos de ingesta idempotentes con barrido autorreparador y un panel que te muestra exactamente qué preguntas quedaron sin responder— es lo que corre detrás de cada agente de la plataforma, en diez idiomas y sin un equipo de ML en tu lado de la mesa.

Pruébalo hoy con tu propio contenido. Crea una cuenta gratis, pega la URL de tu web y mira cómo se ejecuta el bucle completo —rastreo, puerta de calidad, troceado, embeddings, recuperación híbrida— más o menos en el tiempo que te ha llevado leer este artículo. Hazle las cinco preguntas que de verdad hacen tus clientes. Si las respuestas se apoyan en tu contenido y admite lo que no sabe, ya tienes tu evaluación. El plan gratuito no pide tarjeta.

¿Prefieres el detalle primero? Mira cómo funciona nuestro motor RAG o lee la pieza práctica complementaria sobre entrenar un asistente con tus propios datos.