¿Por qué mi chatbot responde mal?
Casi siempre se culpa al modelo, y casi nunca es el modelo. Antes de cambiar de proveedor conviene averiguar en cuál de los dos pasos se rompió la respuesta, porque el arreglo es completamente distinto.
En resumen
Una respuesta mala se rompe en uno de dos lugares: el sistema no encontró la información (fallo de recuperación) o la encontró y respondió por encima de ella (fallo de fidelidad). El arreglo es distinto en cada caso.
La prueba cuesta una tarde: treinta preguntas reales, revisar a mano si el fragmento correcto apareció entre lo recuperado. Si no apareció, el problema no es el modelo.
La métrica de la recuperación es recall@k; la de la respuesta es groundedness. Sin esos dos números, cualquier discusión sobre calidad se decide por quién habla más fuerte.
La causa más frecuente de recuperación mala es la segmentación: fragmentos partidos por tamaño en vez de por sentido, que dejan la pregunta en un pedazo y la respuesta en otro.
Cuatro pasos para saber dónde está el fallo
- Juntá treinta preguntas realesDe conversaciones que ya pasaron, no inventadas. Con la respuesta correcta escrita por alguien que conoce el negocio.
- Mirá lo que el sistema recuperóPara cada pregunta, revisá si el fragmento que contenía la respuesta apareció entre lo que se le pasó al modelo. Eso es recall@k a mano.
- Separá los dos montonesPreguntas donde el fragmento correcto no llegó: fallo de recuperación. Preguntas donde llegó y la respuesta igual estuvo mal: fallo de generación.
- Arreglá el montón grande primeroEn la mayoría de los sistemas que llegan a diagnóstico, el montón de recuperación es el grande. Cambiar de modelo no mueve ese montón ni un punto.
Siete fallos concretos y qué los delata
| Síntoma | Causa probable | Qué se hace |
|---|---|---|
| Responde con información de otro producto o cliente | Segmentación por tamaño fijo: la respuesta quedó partida entre dos fragmentos | Resegmentar por estructura del documento, con solape |
| Encuentra lo obvio y falla con sinónimos | Solo búsqueda por vectores, sin coincidencia por palabra | Búsqueda híbrida: vectores más BM25 |
| Trae fragmentos relacionados pero no el que servía | Falta reordenamiento después de la búsqueda | Agregar un reordenador sobre los primeros resultados |
| Inventa datos con seguridad total | El prompt no exige apoyarse en lo recuperado ni permite negarse | Instrucción de negativa explícita y citación de la fuente |
| Responde bien y de golpe empeora | Entraron documentos nuevos y nadie volvió a medir | Reejecución periódica del conjunto de evaluación |
| Contesta distinto a la misma pregunta | Temperatura alta o contexto que arrastra la conversación anterior | Bajar temperatura, acotar el historial que se envía |
| Se cae o tarda en horas pico | Sin límites de tasa, sin caché, sin reintento con espera | Caché de consultas frecuentes y control de concurrencia |
Partir documentos por tamaño rompe respuestas
La forma más rápida de armar un sistema de recuperación es partir cada documento en fragmentos de mil caracteres. Funciona en la demo y falla en producción por un motivo simple: los documentos reales tienen estructura, y esa estructura no cae cada mil caracteres.
Una tabla de precios partida a la mitad deja los encabezados en un fragmento y las cifras en otro. Un artículo de una política queda separado de su excepción. Cuando el usuario pregunta por la excepción, el sistema recupera el artículo y responde exactamente lo contrario de lo que corresponde.
Segmentar por estructura —secciones, artículos, filas completas de tabla— con un poco de solape entre fragmentos suele mover el recall más que cualquier cambio de modelo. Es trabajo aburrido y es donde está el retorno.
Cinco cosas que un asistente en producción debe tener
- Cuando no encuentra, lo dice y escala. Un sistema que siempre responde está inventando en algún porcentaje de los casos.
- Cada respuesta debe poder mostrar de qué documento salió. Es lo que permite auditar sin leer el código.
- Es el entregable de más valor de la operación mensual: dice qué le falta a la base y qué está buscando el cliente.
- Cuando pasa a una persona, esa persona recibe la conversación completa, no un aviso.
- Sin ese número no se puede decidir si conviene un modelo más barato ni cuándo el volumen deja de ser rentable.
Si el sistema entregado es una configuración dentro de la plataforma de un proveedor, sin acceso a los prompts ni a la lógica, no hay mucho que diagnosticar: lo que se puede cambiar es lo que esa plataforma deje cambiar.
También cuando el problema es de fuente: si los documentos sobre los que responde están desactualizados o se contradicen entre sí, ningún ajuste técnico lo arregla. Ahí el trabajo es de contenido, no de ingeniería.
Preguntas frecuentes
¿Por qué mi chatbot inventa respuestas?
Por dos razones que se confunden entre sí. La primera es que no recibió la información correcta: el fragmento que servía nunca llegó al prompt y el modelo respondió con lo que tenía. La segunda es que sí la recibió pero el prompt no le exige apoyarse en ella ni le permite decir que no sabe. La primera se arregla en la recuperación; la segunda, con instrucción de negativa explícita y citación de la fuente.
¿Qué es recall@k y por qué importa?
Mide qué tan seguido el fragmento que contenía la respuesta correcta aparece entre los k que el sistema recuperó. Si recall@5 es 0,6, en cuatro de cada diez preguntas el modelo nunca vio la información que necesitaba. Ningún cambio de modelo, de prompt ni de temperatura mejora ese número: es un problema de búsqueda.
¿Cambiar a un modelo mejor arregla las respuestas malas?
Solo si el fallo es de generación. Cuando el problema es de recuperación, un modelo mejor produce respuestas mejor escritas y igual de equivocadas, y a veces peores: un modelo más capaz rellena huecos con más elegancia. Por eso conviene separar los dos montones antes de tocar nada.
¿Cuánto cuesta diagnosticar un chatbot que ya está en producción?
Un diagnóstico serio son cinco días de trabajo y termina con hallazgos concretos, cada uno con su arreglo y su esfuerzo estimado. En Quarl, si el diagnóstico no llega a al menos tres hallazgos accionables, no se cobra.
¿Cada cuánto hay que volver a medir?
Mensual si la base documental cambia seguido, trimestral si es estable. La degradación no avisa: entran documentos nuevos, cambia la distribución de lo indexado y el recall baja sin que nadie lo note hasta que un cliente se queja. Reejecutar el conjunto de evaluación es lo que convierte esa sorpresa en un número que se ve venir.