El 90% del trabajo de un chatbot que no alucina ocurre antes de escribir código: en qué documentos le das y en qué estado. Qué revisar en los tuyos antes de empezar.
Casi todas las conversaciones sobre chatbots con RAG empiezan por el modelo. Cuál usar, cómo se configura, qué guardrails lleva. Es la parte visible y la que se puede enseñar en una demo. Y es la que menos determina si el chatbot va a funcionar.
Lo que decide el resultado es el material que le das. Un chatbot con RAG responde a partir de tus documentos: si esos documentos están mal, la respuesta está mal, y ningún ajuste del modelo lo arregla.
Qué es exactamente el material
En el servicio de chatbots que ofrezco, el RAG se monta sobre tus documentos, con canal web y Telegram, memoria episódica —no solo memoria de la conversación en curso—, handoff humano automático y un pipeline de 14 pasos con safety guardrails. Todo eso es infraestructura. El contenido lo pones tú.
Y ese contenido suele llegar en un estado peor de lo que el cliente cree.
Los cuatro problemas que aparecen siempre
Uno: documentos que se contradicen. El PDF de tarifas de hace dos años dice una cosa y la página web dice otra. Un humano sabe cuál vale. El sistema de recuperación no: encontrará los dos, y responderá con el que se parezca más a la pregunta. Si hay dos verdades en el material, el chatbot elegirá una al azar cada vez.
Dos: información que solo existe en la cabeza de alguien. Las preguntas más frecuentes de tus clientes suelen tener respuestas que nadie ha escrito nunca. Están en la experiencia de la persona que lleva atención al cliente. Si no se escriben, el chatbot no las tendrá, y responderá con lo más parecido que encuentre, que no será suficiente.
Tres: documentos que no dicen lo que parece. Un catálogo comercial está escrito para persuadir, no para informar. Está lleno de adjetivos y corto de datos. Como fuente para responder preguntas concretas rinde mucho menos de lo que su extensión sugiere.
Cuatro: formatos que pierden estructura. Una tabla de precios en PDF maquetado se convierte, al extraerse, en una fila de números sin cabeceras. El dato está y a la vez no está: nadie puede saber a qué corresponde cada cifra.
Qué hacer con cada problema
- Contradicciones: decide cuál es la fuente buena y retira la otra del material. No la corrijas "mentalmente": retírala.
- Conocimiento no escrito: siéntate media hora con quien atiende clientes y escribid juntos las respuestas a esas diez preguntas. Es el documento más rentable del proyecto.
- Material comercial: úsalo para el tono, no como fuente de datos. Los datos van en un documento aparte, escueto y sin adjetivos.
- Tablas y PDF maquetados: pásalos a un formato con estructura explícita, aunque sea un texto plano con etiquetas claras.
Por qué existe el POC de siete días
El servicio incluye una prueba de concepto de 7 días, deducible del setup, con precio 158€. No es un descuento de captación: es la respuesta a este problema.
Un POC sobre tu documentación real, con tus preguntas reales, enseña en una semana lo que ninguna demo enseña: si tu material aguanta. Si en el POC el chatbot responde mal a preguntas que tú sabes contestar, el problema está en el material y aún estás a tiempo de arreglarlo, o de decidir que no compensa.
Después del POC
Si el POC funciona, el setup completo en widget web parte de 529€; con el bot de Telegram añadido, 849€. La cuota mensual va desde 84€, con 190€ en el tramo medio y 423€ en el superior con soporte prioritario. Los tres recurrentes son cancelables cuando quieras.
El resumen incómodo
La calidad de un chatbot con RAG está limitada por la calidad de tu documentación, y esa parte no la puede hacer el proveedor por ti. Puedo montar la infraestructura, los guardrails, la memoria y el handoff. Lo que no puedo es saber cuál de tus dos tablas de precios es la buena.
La buena noticia es que ese trabajo tiene valor aunque no montes el chatbot: una documentación ordenada y sin contradicciones sirve para el equipo, para la web y para cualquier cosa que hagas después.
Dos piezas que la documentación no arregla sola
He insistido en el material porque es donde está el problema que nadie mira. Hay otras dos piezas que sí son infraestructura y que conviene entender, porque cambian mucho la experiencia.
La primera es la memoria episódica. No es lo mismo que recordar la conversación en curso: es que el sistema tenga contexto de interacciones anteriores. La diferencia se nota cuando un cliente vuelve y no tiene que volver a explicarlo todo desde cero.
La segunda es el handoff humano automático. Un chatbot honesto tiene que saber cuándo callarse y pasar la conversación a una persona. Sin handoff, un bot que no sabe la respuesta hace lo peor que puede hacer: improvisar. Con handoff, el caso llega a quien puede resolverlo, y el cliente no se queda dando vueltas.
Los guardrails y por qué son un pipeline
La seguridad no es una casilla que se activa. En este servicio es un pipeline de 14 pasos con safety guardrails: comprobaciones encadenadas antes de que una respuesta salga al cliente. Un único filtro final no basta, porque los problemas aparecen en fases distintas —en lo que se recupera, en lo que se compone y en lo que se dice.
Cómo saber si el material está listo
Una señal práctica: si cuando entra alguien nuevo al equipo puede resolver el 80 por ciento de las consultas leyendo vuestra documentación, el material está listo para un RAG. Si el recién llegado necesita preguntar a un compañero para casi todo, el chatbot va a estar en la misma situación, y sin compañero al que preguntar.
Esa prueba no cuesta nada y ahorra bastantes sorpresas.