RAG frente a chatbot tradicional: qué cambia de verdad

RAG, siglas de generación aumentada por recuperación, es una técnica en la que el sistema busca primero en vuestros documentos los fragmentos relevantes para la pregunta y solo después redacta la respuesta usando ese material. Un chatbot tradicional, en cambio, o sigue un árbol de respuestas escrito a mano o responde con lo que el modelo aprendió durante su entrenamiento. La diferencia práctica es que con RAG la respuesta se apoya en vuestra documentación real y se puede citar la fuente.

Por qué fallan las dos alternativas habituales

El chatbot de reglas se queda corto

El chatbot clásico funciona con intenciones y respuestas predefinidas. Alguien escribe la pregunta esperada y la respuesta que debe darse. Funciona sorprendentemente bien mientras las preguntas caen dentro del guion, y falla de una forma característica: cuando el usuario pregunta algo que nadie previó, responde con la respuesta más parecida que tiene, que suele ser la equivocada.

El problema de fondo no es técnico, es de mantenimiento. Cada nuevo producto, cambio de política o excepción obliga a añadir intenciones a mano. En un catálogo de cierto tamaño, mantener ese árbol se convierte en un trabajo continuo que nadie quiere hacer, y a los seis meses el chatbot responde con información caducada. Es el motivo por el que tantos chatbots corporativos acabaron desconectados sin que nadie los echara de menos.

Un modelo de lenguaje sin contexto inventa

La reacción natural es sustituir las reglas por un modelo de lenguaje. Y ahí aparece el otro fallo. Un modelo genera texto prediciendo la continuación más plausible de lo que ha leído. Si le preguntan por vuestras condiciones de garantía y no las tiene delante, no se calla: produce una respuesta con la forma y el tono de una condición de garantía real, porque ha visto miles. Suena bien y es falsa.

Conviene entender que esto no es un defecto que se corrija con un modelo mejor ni pidiéndole que no invente. Un modelo sin acceso a vuestra información no puede saber lo que no le habéis dado. La solución no es cambiar el modelo, es cambiar lo que le entra en cada pregunta.

Un modelo no miente ni acierta: completa. Si no le damos el documento, completará con lo que resulte verosímil.

Cómo funciona la recuperación, sin tecnicismos

El proceso tiene tres momentos. Primero, una fase previa en la que se recogen los documentos, se parten en fragmentos manejables y se indexan de forma que puedan buscarse por significado y no solo por palabras exactas. Segundo, cuando llega una pregunta, el sistema recupera los fragmentos más relevantes. Tercero, se le pasan al modelo junto con la pregunta y la instrucción de responder solo con ese material y de indicar de dónde sale.

Ese último paso es el que aporta la propiedad más valiosa para una empresa: la respuesta es verificable. Quien la lee puede abrir el documento citado y comprobarla. Cuando alguien pregunta por qué el sistema ha dicho tal cosa, hay una respuesta concreta, y eso cambia por completo la confianza que la organización deposita en la herramienta.

También conviene saber dónde falla la recuperación. El punto débil no suele ser el modelo, sino la búsqueda: si los fragmentos recuperados no contienen la respuesta, no hay generación que lo arregle. La mayor parte del trabajo de afinar un sistema RAG consiste en mejorar cómo se parte la documentación y cómo se recupera, no en tocar el modelo.

Los dos obstáculos que descarrilan proyectos

El problema de los permisos

Este es el asunto que más proyectos descarrila cuando se descubre tarde. Vuestra documentación no es plana: hay carpetas a las que solo accede dirección, nóminas, informes de personal, contratos con condiciones distintas por cliente. Si el índice se construye ignorando eso, cualquier empleado puede obtener por conversación información a la que no tiene acceso por carpeta. Y lo hará sin querer, preguntando algo inocente.

La única forma correcta de resolverlo es que el filtro por permisos se aplique en el momento de recuperar, con la identidad de quien pregunta, antes de que el modelo vea nada. No sirve indexarlo todo y confiar en que el modelo se abstenga: eso no es un control de acceso. Si el proveedor no explica con precisión cómo respeta los permisos del origen, ese es el punto donde hay que insistir.

La calidad documental marca el techo

Un sistema RAG no puede ser mejor que la documentación sobre la que trabaja, y aquí es donde muchas empresas descubren un problema que ya tenían. Si conviven tres versiones del mismo procedimiento, el sistema recuperará alguna de ellas, no necesariamente la vigente. Si la información está en presentaciones con frases sueltas o en capturas de pantalla dentro de un PDF, no hay texto que recuperar. Si el conocimiento está en hilos de correo y en la cabeza de dos personas, no está en ningún sitio del que se pueda leer.

• Duplicados y versiones antiguas conviviendo con la vigente: es el fallo más común y el más dañino.
• PDF escaneados sin texto: requieren reconocimiento óptico previo o quedan fuera del índice.
• Documentos sin fecha ni responsable: imposible saber cuál manda cuando dos se contradicen.
• Conocimiento no escrito: hay que documentarlo antes, y ese trabajo no lo hace la herramienta.

La consecuencia práctica es que un proyecto de RAG suele empezar con una limpieza documental. No es tiempo perdido: esa limpieza tiene valor por sí sola y es la parte que determina si el resultado será útil o mediocre.

RAG o fine-tuning

Son cosas distintas que resuelven problemas distintos, aunque se presenten como alternativas. El ajuste fino modifica el comportamiento del modelo: sirve para fijar un estilo, un formato de salida o un tipo de razonamiento propio de vuestro sector. RAG aporta información. Si el objetivo es que el sistema conozca vuestros precios actuales, el ajuste fino es la herramienta equivocada: no se reentrena un modelo cada vez que cambia una tarifa, y el conocimiento incorporado así no se puede citar ni retirar con facilidad.

La regla razonable es empezar siempre por RAG. Es más barato, se actualiza cambiando un documento, permite citar fuentes y es reversible. El ajuste fino se plantea después, y solo si el problema que queda es de forma y no de contenido.

Cómo saber si responde bien

Sin una forma de medir, la valoración del sistema se reduce a que a unos les parece que responde bien y a otros que no. Lo que funciona es sencillo y no requiere herramientas caras: construir un conjunto de preguntas reales con su respuesta correcta y el documento del que sale, y pasarlo cada vez que se cambie algo.

1. Recoja entre treinta y cien preguntas reales, de las que la gente hace de verdad, no de las que uno imagina.
2. Anote para cada una la respuesta correcta y el documento que la contiene.
3. Mida dos cosas por separado: si el sistema recuperó el documento adecuado y si la respuesta redactada es correcta.
4. Vigile especialmente los casos en los que debería decir que no lo sabe: un sistema que nunca reconoce ignorancia es un sistema que inventará.
5. Repita la medición tras cada cambio de configuración, de documentación o de modelo.

La separación entre recuperación y redacción es lo que hace útil esta medición: dice dónde está el fallo. Si el documento correcto no aparecía entre los recuperados, el problema es de indexación o de troceado. Si aparecía y la respuesta era mala, el problema está en las instrucciones dadas al modelo.

Conclusión práctica

Un chatbot de reglas sigue teniendo sentido para un puñado de preguntas fijas de alto volumen, como el horario o el estado de un pedido. Para todo lo demás, RAG es hoy el enfoque razonable, siempre que se acepten sus dos condiciones: la documentación tiene que estar en orden y los permisos deben aplicarse en la recuperación.

Un arranque prudente es acotar el ámbito a un área con documentación relativamente sana, medir con preguntas reales, dejar visible siempre la fuente de cada respuesta y ampliar solo cuando los números acompañen. Un sistema que responde bien sobre un dominio pequeño genera más confianza, y más uso, que uno que responde regular sobre todo.