Detectar lagunas de conocimiento en chatbots de IA: Cómo cerrar preguntas sin respuesta de forma sistemática

Un chatbot para sitio web solo puede responder con fiabilidad si dispone de información adecuada, aprobada y fácil de recuperar. En la práctica, sin embargo, las lagunas de conocimiento raras veces se presentan como un informe ordenado. Se ocultan tras respuestas de reserva (fallback) seguras, repeticiones de consultas, derivaciones innecesarias a agentes humanos o respuestas que suenan convincentes pero carecen de una fuente sólida. Por eso, limitarse a contar el número de preguntas no respondidas solo muestra una parte del problema.

Por lo tanto, un proceso eficaz combina datos operativos, revisión editorial y pruebas. El objetivo no es copiar de inmediato cada formulación poco habitual en la base de conocimiento, sino detectar necesidades de información recurrentes, determinar su causa raíz y aprobar únicamente aquellas respuestas de las que el equipo pueda hacerse responsable a nivel técnico o especializado. Esta guía muestra un procedimiento práctico para equipos de soporte, contenidos y producto.

¿Qué es una laguna de conocimiento en un chatbot de IA?

Existe una laguna de conocimiento cuando una pregunta legítima del usuario, dentro del ámbito de uso previsto, no se puede responder con fiabilidad mediante una declaración aprobada. Esto puede significar que la información no existe en absoluto. Sin embargo, lo más habitual es que sí exista, pero esté desactualizada, sea demasiado general, tenga una redacción inadecuada, no se pueda rastrear (crawl) o no aparezca en la búsqueda o recuperación (retrieval). Las fuentes contradictorias también constituyen una laguna: en ese caso, el chatbot tiene demasiado conocimiento ambiguo en lugar de poca información.

Este concepto no debe equipararse a cualquier situación sin coincidencia (no-match). Google documenta eventos integrados de «No-Match» en Dialogflow CX cuando una entrada no coincide con ninguna intención (intent). Microsoft utiliza en las analíticas de Copilot Studio el término «unrecognized utterances» (expresiones no reconocidas), es decir, formulaciones que no activan ningún tema propio. Estas señales son puntos de partida muy útiles, pero no demuestran por sí solas que se necesite contenido nuevo. Quizá la pregunta estaba fuera de alcance (scope), la redacción era ambigua o sencillamente no se encontró la fuente existente.

¿Qué señales deben incluirse en el análisis de lagunas?

Respuestas de reserva seguras y preguntas sin contestar

La pista más evidente es una respuesta del tipo «No dispongo de información fiable sobre este tema». Esta respuesta de reserva (fallback) segura es preferible a una afirmación inventada, pero debe registrarse como un evento auditable. Para ello, no solo es relevante la formulación exacta de la pregunta, sino también el idioma, la página afectada, la fecha y hora, el ámbito seleccionado y la evolución posterior de la conversación. Los datos personales o confidenciales no deben transferirse sin filtrar a un sistema de gestión editorial.

Baja confianza y escasez de fuentes

Una respuesta emitida por el sistema también puede revelar una laguna de conocimiento. Algunos ejemplos son la falta de fuentes, un resultado de recuperación con baja concordancia, múltiples coincidencias contradictorias o una respuesta que solo cubre parte de la pregunta. El valor técnico de confianza (confidence score) no basta por sí solo para emitir un juicio: los umbrales varían según el modelo, el sistema y el nivel de riesgo. Lo determinante es si el equipo puede verificar y aprobar la afirmación basándose en una fuente de autoridad.

Repetición de preguntas, abandonos y derivaciones (handoffs)

Si los usuarios reformulan la misma pregunta, repiten la consulta varias veces o solicitan hablar con una persona justo después, es probable que la primera respuesta no haya cubierto sus necesidades. Lo mismo se aplica a una cantidad inusualmente alta de abandonos tras abordar un tema específico. Estas secuencias deben analizarse en su contexto. Una derivación a un agente humano (handoff) puede ser la solución adecuada, por ejemplo, ante decisiones individuales, reclamaciones o datos sensibles. Por lo tanto, no constituye automáticamente un error de contenido.

Diferencias de configuración regional (locale) y de canal

Una respuesta en alemán puede funcionar perfectamente mientras que la variante en francés no existe o utiliza el nombre de un producto de forma distinta. De igual modo, las preguntas formuladas en una página de precios pueden variar respecto a las del centro de ayuda. Por ello, las agrupaciones (clusters) deben poder analizarse al menos por idioma o configuración regional (locale) y por contexto de uso. De lo contrario, un resumen global podría ocultar una laguna claramente localizada.

De la señal bruta al backlog de contenidos priorizados

Un flujo de trabajo ágil evita que el equipo recopile transcripciones de forma sound / indiscriminada o dé una importancia excesiva a observaciones aisladas. Los siguientes siete pasos se pueden ejecutar semanalmente o con mayor frecuencia en caso de volúmenes elevados.

1. Definir la captura: Establezca qué eventos se consideran candidatos: respuestas de reserva seguras, falta de fuentes sólidas, preguntas repetidas, valoraciones negativas de usuarios, derivaciones innecesarias o afirmaciones erróneas reportadas. Documente también qué datos se omiten deliberadamente de la recopilación.
2. Depurar los contenidos: Elimine o enmascare datos personales, números de pedido, datos de contacto y textos libres que no sean necesarios para el análisis. La guía sobre analítica eficiente de chatbots y minimización de datos muestra cómo planificar de forma independiente los eventos, el muestreo y la conservación.
3. Normalizar las preguntas: Agrupe formulaciones con un significado equivalente sin perder matices relevantes. «¿De cuánto tiempo dispongo para hacer una devolución?» y «¿Cuál es el plazo de devolución?» pertenecen probablemente al mismo grupo; en cambio, «¿Puedo devolver un producto personalizado?» puede requerir una regla independiente.
4. Clasificar la causa: Distinga entre falta de contenido, fuente obsoleta, problema de estructuración o recuperación (retrieval), política poco clara, laguna de localización, ámbito excluido intencionadamente o necesidad de intervención humana. Este diagnóstico determinará la acción necesaria.
5. Establecer prioridades: Evalúe la frecuencia, el impacto en el usuario, la relevancia para el negocio y el nivel de riesgo. Una indicación poco frecuente sobre una restricción crítica de seguridad puede ser más prioritaria que una pregunta habitual de conversación informal (smalltalk). La fórmula debe ser comprensible y verificable para su organización, sin complicaciones matemáticas innecesarias.
6. Asignar la responsabilidad de las fuentes: Cada respuesta planificada necesita una fuente de autoridad y una persona o rol con capacidad para aprobar su contenido. Si falta cualquiera de las dos cosas, la entrada permanecerá abierta; un modelo de lenguaje no debe inventar la política aplicable. Un modelo operativo adecuado se describe en la guía de gobernanza de contenidos para chatbots de IA.
7. Crear pruebas de aceptación: Guarde preguntas representativas, afirmaciones clave esperadas, fuentes permitidas y el comportamiento previsto fuera de alcance. Tras cada modificación, verifique si la laguna se ha resuelto y si las respuestas existentes se mantienen estables.

¿Qué campos requiere una buena entrada en el backlog?

Un ticket titulado «El chatbot no sabe el plazo de devolución» es demasiado impreciso. Suele dar lugar a un texto que responde a la consulta de ejemplo, pero pasa por alto variantes, excepciones o responsabilidades. Una entrada lista para ser procesada debe incluir al menos:

• un tema neutro para la agrupación y entre dos y cinco preguntas de ejemplo anonimizadas,
• configuración regional (locale), contexto de la página y ruta del usuario afectada,
• comportamiento observado y comportamiento deseado,
• categoría de la causa raíz y prioridad justificada,
• URL de la fuente de autoridad o el estado «Fuente no disponible»,
• titularidad técnica o de contenidos, rol de revisión y plazo previsto,
• fecha de validez, excepciones conocidas y comportamiento deseado para la derivación (handoff),
• casos de prueba y criterios de aceptación medibles.

De este modo, una simple observación de chat se transforma en una unidad de trabajo editorial. Al mismo tiempo, se mantiene la claridad sobre si el problema se puede resolver realmente con contenido. Un error técnico de recuperación (retrieval), por ejemplo, debe asignarse al equipo de búsqueda o plataforma, mientras que una política de devolución no aclarada debe dirigirse al departamento responsable correspondiente.

Ejemplo práctico: Cómo resolver correctamente las preguntas sobre devoluciones

Supongamos que los usuarios preguntan repetidamente sobre la devolución de productos personalizados. El chatbot responde a veces con el plazo general, otras con una exclusión dudosa y en ocasiones deriva la consulta al soporte. El equipo no debe deducir una regla nueva a partir de esas respuestas previas. Lo primero es aclarar qué política aprobada está vigente, a qué países y grupos de productos se aplica y cuándo se requiere un análisis caso por caso.

A continuación, se crea una fuente estructurada con una regla general, excepciones claramente especificadas, ámbito de validez y criterios de escalado. Los casos de prueba deben contemplar preguntas directas, variantes coloquiales, otra configuración regional y un caso límite que deliberadamente no deba automatizarse. Para dicho caso límite, se espera una derivación a un agente humano (human handoff) transparente, en lugar de una respuesta forzada en modo autoservicio.

Por qué más contenido no significa automáticamente un mejor resultado

Un error frecuente consiste en intentar responder a cada grupo de preguntas creando una nueva entrada de FAQ. Esto puede provocar duplicidades, contradicciones y un deterioro en los resultados de recuperación. Antes de crear nuevo contenido, evalúe si conviene ampliar una página existente, estructurarla mejor o excluirla del alcance del rastreo (crawl scope). El proceso para mantener actualizada una base de conocimiento ayuda en la selección de fuentes, el ritmo de rastreo y el control de contenidos obsoletos (stale content).

Resulta igualmente riesgoso incorporar expresiones reales de usuarios como datos de entrenamiento o prueba sin revisarlas previamente. Google advierte en sus guías de diseño que añadir entradas sin coincidencia (no-match) de forma sound / indiscriminada puede generar un sesgo de intención (intent bias) indeseado. Solo el análisis de la causa raíz determinará si se debe añadir una formulación, depurar una ya existente o corregir una intención competidora incorrecta.

Cerrar el ciclo mediante pruebas de regresión

La laguna no se considera resuelta por el mero hecho de publicar texto nuevo. Se considera resuelta únicamente cuando las preguntas representativas muestran el comportamiento previsto en el contexto adecuado. Google describe casos de prueba con expectativas a nivel de conversación o de turno (turn), comparándolos con un caso de referencia (Golden Case). Para los chatbots en sitios web, este principio se puede aplicar de forma independiente al modelo: se documentan la pregunta, la idea clave esperada, la fuente permitida, la derivación requerida y las afirmaciones no permitidas.

Un conjunto de pruebas reducido y bien mantenido es mucho más valioso que una colección amplia sin verificar. Incorpore las lagunas confirmadas al conjunto de referencia (Golden Set) existente y vuelva a ejecutar los casos relevantes tras realizar cambios en el contenido, los prompts, el modelo o el sistema de recuperación. La guía detallada sobre cómo medir la calidad de respuesta en chatbots de IA profundiza en este flujo de trabajo de revisión.

¿Qué métricas indican un progreso real?

No se limite a supervisar una tasa global de respuestas de reserva (fallback rate). Es mucho más revelador analizar un conjunto reducido de indicadores: agrupaciones priorizadas pendientes, tiempo transcurrido hasta la aclaración técnica o especializada, porcentaje de entradas del backlog con fuente de autoridad, pruebas de regresión superadas y lagunas que vuelven a surgir tras una aprobación. Segmente los resultados según la configuración regional (locale) y la ruta principal de uso, evitando evaluar grupos reducidos con un nivel de detalle que permita identificar personas de forma indirecta.

Microsoft señala las expresiones no reconocidas y los temas con baja tasa de resolución como posibles indicadores de optimización. Al mismo tiempo, el marco AI Risk Management Framework del NIST destaca la importancia de la supervisión continua, los conjuntos de prueba documentados, la retroalimentación y la observación del comportamiento en producción. De ello se deduce una regla de trabajo esencial: las métricas deben respaldar las decisiones, pero nunca sustituir la revisión técnica o especializada de una fuente de información.

Lista de comprobación semanal para equipos de soporte y redacción

• Capturar nuevos candidatos de forma eficiente respetando la minimización de datos y descartar el uso indebido evidente.
• Agrupar por configuración regional (locale) las preguntas con significado equivalente y actualizar las agrupaciones existentes.
• Confirmar la causa raíz, el impacto y el riesgo en las agrupaciones más relevantes.
• Buscar fuentes existentes, señalar contradicciones y definir la titularidad del contenido.
• Publicar únicamente cambios aprobados, manteniendo explícitos el alcance (scope) y las derivaciones (handoffs).
• Ejecutar casos de prueba representativos y documentar los resultados.
• Tras unos días de uso, verificar si la agrupación vuelve a aparecer o si solo ha cambiado de forma.

Conclusión: Las lagunas de conocimiento constituyen un ciclo de control editorial

Las preguntas sin respuesta adquieren valor real cuando el equipo deja de tratarlas como simples registros de chat dispersos y las gestiona como indicios auditarles. Capturar, depurar, agrupar, determinar la causa, priorizar, aprobar la fuente y probar: este ciclo de control conecta la realidad del soporte con una base de conocimiento sólida. No elimina todas las derivaciones ni intenta responder a todas las consultas de forma automatizada; en cambio, aporta visibilidad sobre dónde el chatbot puede prestar ayuda con total fiabilidad y dónde establecer un límite claro ofrece una mejor experiencia al usuario.

Fuentes

• Microsoft Learn: Measure and improve agent performance with KPIs and analytics
• Google Cloud: Dialogflow CX State handlers und No-Match-Ereignisse
• Google Cloud: General agent design best practices
• Google Cloud: Dialogflow CX Test cases
• NIST AIRC: AI Risk Management Framework Core