Fallbacks para chatbots de IA: Cómo detectar y gestionar con seguridad las lagunas de conocimiento

Un chatbot para sitios web no necesita responder a todas las preguntas. Lo crucial es que reconozca cuándo la base de conocimientos no ofrece una base sólida y que, aun así, siga siendo de ayuda para los visitantes. Rellenar una laguna con una suposición que suena plausible genera un problema de confianza: un plazo de entrega incorrecto, una regla de producto inventada o una indicación de soporte inadecuada pueden causar más trabajo que un límite claro y breve.

Por qué la falta de coincidencias es un problema de producto en sí mismo

En un chatbot de IA basado en conocimientos, existen al menos tres causas distintas para la ausencia de respuesta. En primer lugar, la información puede faltar por completo. En segundo lugar, puede estar disponible, pero no encontrarse debido al idioma, la formulación, los metadatos o la clasificación. En tercer lugar, se puede encontrar, pero no ser suficiente para dar una respuesta segura. En el chat, estos casos parecen similares a primera vista, pero en la práctica requieren medidas diferentes.

Los sistemas de recuperación (retrieval) no evalúan automáticamente si una respuesta es justificable desde el punto de vista del negocio. La descripción general oficial sobre Retrieval-Augmented Generation en Azure AI Search detalla cómo combinar la búsqueda de texto y la búsqueda vectorial para proporcionar fuentes para una respuesta. Esta combinación mejora la búsqueda, pero no sustituye a una regla sobre cuándo un resultado se considera suficiente. Por lo tanto, un chatbot necesita una decisión claramente definida antes de generar texto: responder, solicitar aclaraciones o derivar de forma segura.

El «No-Answer» no es un callejón sin salida

Una respuesta de fallback útil no se limita a decir «No tengo información sobre esto». Se compone de cuatro elementos esenciales: define el límite sin excusas técnicas, evita hacer afirmaciones no verificadas, ofrece una pregunta de aclaración precisa o una alternativa segura y, si es necesario, indica la vía para hablar con una persona. El tono puede ser amable, pero no debe ocultar la incertidumbre.

• Límite: «No encuentro información fiable sobre esto en los datos autorizados.»
• Contexto: «¿Se trata de un pedido, un contrato o una configuración técnica?»
• Paso siguiente: «Si me facilita el nombre del producto, puedo volver a revisar la documentación disponible.»
• Derivación (Handoff): «Para una comprobación vinculante, transferiremos su consulta al equipo correspondiente.»

De este modo, el chat sigue siendo útil sin inventar precios, plazos, consecuencias legales o compromisos. Especialmente en el caso de datos personales, pagos, ofertas individuales y consultas críticas de seguridad, la regla de derivación debe activarse antes de forma consciente. La guía sobre el Human Handoff en el soporte web ayuda a estructurar las transferencias como un proceso claro y no como una salida de emergencia.

Operativizar la decisión antes de responder

Los equipos no deberían adoptar un umbral mágico extraído de una demostración. La puntuación obtenida en la búsqueda es solo una señal y puede cambiar según el índice, el modelo, el idioma y la combinación de consultas. La documentación de Semantic Ranking señala que las distribuciones de puntuación de los rerankers pueden variar. Por este motivo, un umbral debe ir siempre ligado a un conjunto de datos probado y a una clase de error concreta.

Una decisión práctica puede combinar varias comprobaciones. ¿Existe al menos una fuente dentro de un área de contenido permitida? ¿Coincide con el idioma y la versión actual del producto o contrato? ¿Contiene una justificación directa para la respuesta planificada? ¿Los resultados principales son contradictorios entre sí? Solo cuando se cumplen adecuadamente estos criterios, el generador puede formular una respuesta. De lo contrario, el bot formula una pregunta concreta o activa el fallback.

Ejemplo: Información de entrega vinculante

Si un usuario pregunta por la fecha de entrega de un producto específico, un artículo general sobre envíos no es suficiente. El bot puede explicar que no dispone de información vinculante, solicitar el número de pedido o la variante del producto y remitir al soporte. Por el contrario, una respuesta como «Su paquete llegará mañana» no estaría respaldada por la base de conocimientos. El mismo principio se aplica a garantías, cancelaciones, consultas de salud y accesos a cuentas: cuanto mayor sea el daño potencial, mayor debe ser el nivel de comprobación.

Verificar la recuperación antes de reescribir contenidos

Una falta de respuesta («No-Answer») suele ser una excelente señal de medición. Antes de redactar un nuevo prompt, el equipo debería analizar toda la cadena: la pregunta original, el idioma detectado, la consulta de búsqueda normalizada, los filtros aplicados, los mejores resultados, las versiones de las fuentes utilizadas y la salida elegida. De esta forma se visibiliza si falta un documento o si el proceso de recuperación está fallando.

1. Clasificar de forma anonimizada la pregunta y la intención del usuario (por ejemplo, producto, soporte, cuenta o temas legales).
2. Comparar las fuentes esperadas con los resultados recuperados realmente.
3. Registrar los filtros aplicados para idioma, validez, accesos y versión del producto.
4. Comprobar si los principales resultados realmente responden a la pregunta o solo contienen términos similares.
5. Etiquetar el caso como laguna de documentación, problema de recuperación, regla de seguridad o derivación justificada.

Para estas comparaciones resulta muy útil un pequeño «Golden Set» de preguntas reales y previamente depuradas. El artículo sobre la medición de la calidad de respuesta en chatbots de IA explica por qué las preguntas críticas y poco frecuentes no deben quedar diluidas en un promedio. Incluya de forma intencionada preguntas para las que no exista una respuesta adecuada; solo así se puede verificar si el chatbot reacciona de forma controlada cuando desconoce algo.

Integrar las lagunas de conocimiento en un flujo de trabajo editorial

La conversación de un solo chat no justifica la creación de una nueva FAQ. Sin embargo, múltiples fallbacks seguros del mismo tipo indican claramente que falta una información importante o que es difícil de encontrar. Para gestionarlo basta con una lista ajustada a la privacidad que incluya la intención, la clase de error, el idioma afectado, los ID de las fuentes disponibles y el estado. Los historiales de conversación completos, los nombres o los datos bancarios no deben figurar en un panel de análisis general.

El especialista responsable decidirá a continuación si añade una FAQ, precisa una página de producto, mejora los metadatos o ajusta el texto de la derivación. Cada adición debe contar con un responsable (owner), una fuente y una fecha. Para informaciones con sensibilidad temporal, como la disponibilidad o las promociones, es aconsejable establecer una fecha de caducidad. De este modo, el equipo evita que un artículo creado con buena intención se convierta en la siguiente fuente obsoleta.

No utilizar la tasa de alucinaciones como métrica clave de calidad

Una tasa baja de errores visibles puede resultar engañosa si el bot esquiva las respuestas con demasiada frecuencia. Del mismo modo, una alta tasa de respuestas no representa un éxito si estas no están respaldadas por sus fuentes. Es preferible utilizar un conjunto reducido de métricas clave: porcentaje de consultas respondidas con seguridad, porcentaje de fallbacks justificados, tasa de derivación por intención, tiempo hasta la decisión especializada, lagunas recurrentes y resultados de auditorías manuales. La evaluación debe poder desglosarse por idioma, área de producto y clase de riesgo.

El marco NIST AI Risk Management Framework recomienda gestionar los riesgos en su contexto e integrar procesos de medición y gestión continuos. Para los equipos responsables del sitio web, esto no significa guardar cada conversación, sino disponer de responsabilidades claras y criterios verificables para ofrecer respuestas seguras.

Además, las pruebas deben ajustarse a situaciones de uso reales. Una pregunta breve desde un dispositivo móvil suele incluir menos contexto que una consulta detallada desde un ordenador. Las erratas, las abreviaturas de productos y las mezclas de idiomas son entradas previsibles, no casos excepcionales. Por lo tanto, no evalúe solo la pregunta formulada de manera ideal, sino también variantes en las que falte el número de pedido, se incluyan varios nombres de productos o la referencia temporal sea confusa. Cada variante debe activar una respuesta fundamentada, una pregunta de aclaración con sentido o una derivación segura. Un fallback que solo funciona ante preguntas de prueba redactadas a la perfección no protege en el día a día.

Igualmente importante es el retorno de información desde el equipo de soporte. Cuando el personal responde a una consulta derivada, puede categorizar brevemente el motivo: faltaba información, la información estaba desactualizada, se requería un acceso especial o la consulta exigía una decisión individual. Estas categorías conectan el sitio web, la redacción de contenidos y el servicio de atención al cliente sin convertir al usuario en un mero objeto de análisis. Una revisión mensual de las categorías más frecuentes suele ser suficiente para planificar mejoras prioritarias.

Lista de verificación para un fallback seguro

• Las respuestas solo se muestran con fuentes adecuadas, autorizadas y actualizadas.
• Los umbrales y la combinación de señales se han verificado con un Golden Set.
• Las clases de riesgo alto cuentan con reglas propias para preguntas de aclaración y derivación humana.
• Los textos de fallback explican el límite sin simular tecnicismos ni ofrecer una falsa sensación de seguridad.
• Los registros contienen únicamente la información de diagnóstico necesaria y mínima.
• Los casos recurrentes tienen asignado un responsable y un estado de mejora verificable.
• Las nuevas fuentes se vuelven a revisar antes de su publicación, tras realizar cambios y al caducar.

Conclusión: Los límites honestos mejoran la calidad de las respuestas

Un chatbot de IA profesional no busca responder a la mayor cantidad de preguntas posible, sino limitarse a lo que respalda su base de conocimientos verificada. La mejor respuesta de fallback es concreta, útil y transfiere las consultas vinculantes sin fricciones. Cuando los equipos tratan los casos sin respuesta como datos de prueba y señales editoriales, tanto la recuperación como los contenidos mejoran de forma medible. Comience con diez preguntas clave, diez preguntas deliberadamente sin respuesta y un protocolo de derivación claro por cada clase de riesgo. Esto establecerá una base sólida antes de que el chatbot asuma mayor responsabilidad.

Fuentes

• Microsoft Learn: RAG and Generative AI in Azure AI Search
• Microsoft Learn: Semantic Ranking Overview
• Microsoft Learn: Create a Full-Text Query
• NIST: AI Risk Management Framework