Chatbots con RAG: qué hacer cuando no encuentran información confiable
Un asistente empresarial puede estar conectado a manuales, políticas internas, tickets, contratos o documentación técnica y aun así no encontrar una respuesta confiable. El problema no aparece únicamente cuando el modelo “se equivoca”: también surge cuando la información recuperada está incompleta, es contradictoria, está desactualizada o no responde exactamente a la pregunta del usuario.
En un sistema basado en RAG (Retrieval-Augmented Generation), la confiabilidad no depende solo del modelo generativo. También depende de cómo se recuperan los documentos, cómo se evalúa la evidencia, qué límites se aplican a la respuesta y qué ocurre cuando el sistema no puede sostener una conclusión.
Diseñar ese comportamiento es una decisión de producto, arquitectura y operación. En este artículo veremos cómo manejar la falta de evidencia, cuándo responder con cautela, cuándo solicitar más contexto, cuándo escalar a una persona y qué trazabilidad debería conservar una implementación empresarial.
Qué significa que un chatbot RAG no tenga información confiable
Un sistema RAG normalmente recibe una consulta, busca fragmentos relevantes en una fuente de conocimiento y entrega esos fragmentos al modelo para que genere una respuesta. Este flujo puede fallar de varias maneras, y no todas requieren la misma reacción.
La búsqueda no encuentra documentos relevantes
La consulta puede utilizar términos diferentes a los empleados en la documentación, referirse a un proceso que todavía no está documentado o pedir información que nunca fue incorporada al índice. En este caso, el sistema no tiene evidencia suficiente aunque el modelo sea capaz de producir una respuesta plausible.
La evidencia recuperada es parcial
Un documento puede explicar una política general, pero no cubrir una excepción. También puede describir los pasos de un proceso sin indicar quién tiene autorización para ejecutarlo. Responder como si la información fuera completa puede crear una falsa sensación de certeza.
Las fuentes se contradicen
Es frecuente que una base de conocimiento contenga versiones antiguas y nuevas de un procedimiento, documentos publicados por áreas distintas o reglas que aplican a contextos diferentes. La contradicción no debería resolverse simplemente escogiendo el fragmento que parezca más probable.
La información existe, pero la pregunta es ambigua
“¿Puedo hacer una devolución?” puede depender del país, del tipo de cliente, del producto o del estado de la compra. Antes de recuperar más documentos, el asistente puede necesitar pedir un dato adicional.
Estas situaciones deberían representarse como estados explícitos del sistema. Una respuesta confiable no es solamente un texto: es el resultado de una evaluación sobre la suficiencia y la calidad de la evidencia disponible.
El asistente no debe responder siempre: debe clasificar la evidencia
Un error común consiste en diseñar el flujo con dos únicos resultados: responder o fallar. En un asistente empresarial conviene distinguir varios estados operativos para que cada uno tenga una política clara.
- Evidencia suficiente: los documentos recuperados responden la pregunta y no presentan conflictos relevantes.
- Evidencia parcial: existe información relacionada, pero falta un dato necesario para dar una respuesta completa.
- Evidencia contradictoria: dos o más fuentes proporcionan instrucciones incompatibles o no es posible determinar cuál está vigente.
- Evidencia insuficiente: los resultados no tienen relación suficiente con la consulta o su relevancia es demasiado baja.
- Consulta ambigua: el sistema necesita contexto adicional antes de buscar o interpretar la información.
- Solicitud fuera de alcance: el usuario pide una decisión o una acción que el asistente no está autorizado a realizar.
La clasificación no tiene que depender exclusivamente de una puntuación entregada por el motor de búsqueda. Puede combinar señales como la relevancia de los fragmentos, la cobertura de los requisitos de la pregunta, la vigencia de las fuentes, la coincidencia entre documentos y reglas de negocio.
Es importante no convertir una métrica interna en una garantía de exactitud. Una puntuación alta de similitud indica que un fragmento se parece a la consulta, pero no demuestra que la respuesta sea correcta, completa o aplicable al caso del usuario.
Cómo debe responder cuando la evidencia es insuficiente
Cuando no existe respaldo suficiente, la respuesta debe ser explícita sobre sus límites. Esto no significa mostrar mensajes técnicos ni trasladar toda la complejidad al usuario. Significa evitar afirmar como hecho algo que el sistema no puede justificar.
Una respuesta limitada es mejor que una respuesta inventada
Una respuesta adecuada podría indicar que la documentación disponible no permite confirmar el dato solicitado y explicar qué información sí fue encontrada. Por ejemplo, en lugar de afirmar una fecha de renovación, el asistente puede señalar que la política consultada describe el proceso general, pero no contiene la fecha específica del contrato.
La respuesta debería diferenciar entre:
- lo que está respaldado directamente por las fuentes;
- lo que es una interpretación razonable, si se decide mostrarla;
- lo que no se pudo verificar;
- la acción recomendada para continuar.
En contextos sensibles, como soporte financiero, recursos humanos, cumplimiento, salud o seguridad, puede ser apropiado no ofrecer una interpretación tentativa. El asistente debería derivar el caso o pedir una validación humana.
Solicitar contexto antes de volver a buscar
Si la consulta es ambigua, el sistema puede formular una pregunta concreta. No conviene pedir “más detalles” de manera genérica. Es mejor identificar qué dato cambia la respuesta: el país, el número de contrato, el entorno, la versión del producto o el tipo de usuario.
Por ejemplo, un asistente interno que recibe “¿cómo reinicio el servicio?” podría necesitar saber si el usuario se refiere a desarrollo, pruebas o producción. Esa aclaración reduce el riesgo de entregar instrucciones correctas para el entorno equivocado.
Explicar por qué no puede confirmar la respuesta
La transparencia debe ser comprensible y accionable. El usuario necesita saber si el problema se debe a que no se encontró documentación, a que las fuentes discrepan o a que la solicitud requiere autorización.
Una respuesta útil puede incluir:
- el límite encontrado;
- la información que falta;
- la fuente o fuentes consultadas, cuando sea seguro mostrarlas;
- el siguiente paso recomendado;
- una opción para solicitar revisión humana.
Cuándo escalar la conversación a una persona
El escalamiento no debería ser un mensaje genérico que aparezca únicamente cuando el modelo produce un error. Es un componente normal del diseño de un asistente empresarial.
Una conversación puede derivarse cuando:
- las fuentes contienen instrucciones contradictorias;
- la respuesta puede producir una consecuencia financiera, legal, operativa o de seguridad relevante;
- el usuario solicita una excepción no documentada;
- se requiere autorización para ejecutar una acción;
- el asistente no puede validar la identidad o el alcance de permisos;
- el usuario expresa disconformidad después de una respuesta limitada;
- la misma consulta falla repetidamente;
- la información requerida no está disponible en las fuentes conectadas.
Escalar no significa simplemente transferir el chat. La persona que recibe el caso debería contar con el contexto necesario para continuar sin obligar al usuario a repetir toda la conversación.
Qué información incluir en el escalamiento
- la pregunta original;
- el historial relevante de la conversación;
- los documentos recuperados;
- las fuentes que presentaron conflicto;
- la razón del escalamiento;
- las acciones que el asistente ya realizó;
- los datos de contexto que el usuario proporcionó;
- los permisos o restricciones aplicables, cuando corresponda.
También conviene informar al usuario qué ocurrirá después. Si el caso será revisado por soporte, operaciones o un responsable del proceso, esa transición debe ser clara. La experiencia de escalamiento forma parte del producto, no es un detalle posterior de la implementación.
Trazabilidad: cada respuesta debería poder reconstruirse
En un asistente conectado a información interna, almacenar solamente la respuesta final dificulta investigar incidentes. Para operar el sistema se necesita conocer qué consulta se recibió, qué versión de las fuentes se utilizó y cómo se tomó la decisión de responder o no responder.
La trazabilidad puede incluir:
- identificador de la conversación y de la solicitud;
- consulta original y consulta transformada para la búsqueda, si existe;
- filtros aplicados por permisos, área o contexto;
- identificadores de los documentos y fragmentos recuperados;
- fecha de publicación o vigencia de las fuentes, si está disponible;
- resultado de la evaluación de suficiencia;
- respuesta generada y motivo de una eventual negativa;
- decisión de escalar, solicitar aclaración o ejecutar una acción;
- retroalimentación posterior del usuario o del operador humano.
La trazabilidad debe respetar las políticas de privacidad, seguridad y retención de la organización. No toda información interna debe mostrarse al usuario final, y los registros técnicos pueden contener datos sensibles. Es necesario separar lo que se utiliza para auditoría interna de lo que se presenta como fuente en la interfaz.
Mostrar referencias también requiere cuidado. Citar un documento no vuelve correcta una respuesta si el fragmento no respalda la afirmación concreta. Las fuentes deben estar vinculadas a las afirmaciones relevantes, no añadirse como una lista decorativa al final.
Cómo manejar documentos desactualizados o contradictorios
La calidad de un RAG depende en gran medida de la calidad del conocimiento que recupera. Mejorar el modelo no resuelve una base documental que contiene procedimientos obsoletos, duplicados sin dueño o reglas incompatibles.
Definir autoridad y vigencia
Cada tipo de contenido debería tener, cuando sea posible, un responsable, una fecha de revisión y una condición de vigencia. También conviene distinguir documentos normativos, guías operativas, ejemplos y contenido histórico.
Cuando dos fuentes difieren, el sistema puede aplicar reglas explícitas, como priorizar una política vigente sobre un documento archivado. Sin embargo, si los metadatos no permiten determinar cuál fuente tiene autoridad, la opción más segura es reconocer el conflicto y escalarlo.
Separar recuperación de validación
Recuperar fragmentos relevantes y validar que puedan sostener una respuesta son responsabilidades relacionadas, pero distintas. Una arquitectura puede incorporar una etapa de validación que compruebe si la respuesta propuesta está respaldada por los fragmentos recuperados y si respeta restricciones del dominio.
Esta validación no elimina todos los errores. Puede detectar afirmaciones sin respaldo, pero no necesariamente comprender una política compleja o identificar una excepción que falta en la documentación. Por eso debe combinarse con revisiones de contenido y pruebas representativas del negocio.
Probar los casos en los que el sistema debe abstenerse
Las evaluaciones no deberían medir únicamente si el chatbot responde correctamente. También deben medir si evita responder cuando no tiene evidencia suficiente.
Un conjunto de pruebas útil puede contener:
- preguntas cuya respuesta sí está documentada;
- preguntas con información parcialmente disponible;
- consultas sobre documentos antiguos;
- casos con fuentes contradictorias;
- preguntas ambiguas;
- solicitudes fuera del alcance del asistente;
- intentos de acceder a información no autorizada;
- preguntas formuladas con términos distintos a los de la documentación.
La evaluación debería revisar tanto el contenido como la conducta: si el sistema pidió aclaraciones, mostró límites, citó la evidencia adecuada y escaló cuando correspondía.
Errores frecuentes al diseñar asistentes empresariales con RAG
Usar una respuesta genérica para todos los fallos
“No pude procesar tu solicitud” oculta diferencias importantes entre una consulta ambigua, una fuente contradictoria y un problema técnico. Sin una clasificación clara, el equipo no puede mejorar el flujo ni priorizar la corrección adecuada.
Forzar una respuesta para evitar silencios
La presión por mantener una conversación fluida puede llevar a permitir respuestas especulativas. En un contexto empresarial, un silencio explicado o una derivación bien diseñada suele ser preferible a una instrucción incorrecta que provoque una acción operativa.
Confiar en una puntuación como si fuera una prueba
Los umbrales de relevancia pueden ayudar a tomar decisiones, pero deben validarse con casos reales y mantenerse bajo observación. Un umbral adecuado para preguntas frecuentes puede no ser suficiente para decisiones de alto impacto.
Ignorar el contexto del usuario
La misma pregunta puede tener respuestas distintas según el rol, la cuenta, el entorno o el proceso. El contexto debe incorporarse a la recuperación y a las reglas de autorización sin exponer información que el usuario no tiene derecho a consultar.
Conectar fuentes sin un proceso de mantenimiento
Incorporar más documentos no siempre mejora el resultado. Una base extensa y desordenada puede aumentar la ambigüedad. Es preferible establecer responsables, revisar contenido obsoleto y definir qué fuentes son autoritativas antes de ampliar el alcance.
Una estrategia práctica para comenzar
Antes de conectar un asistente a usuarios reales, conviene definir su comportamiento como una política operativa, no como una instrucción aislada para el modelo.
- Delimitar el alcance: especificar qué preguntas puede responder y qué acciones no puede realizar.
- Inventariar las fuentes: identificar responsables, vigencia, permisos y nivel de autoridad de cada conjunto documental.
- Definir estados de evidencia: separar respuesta confirmada, respuesta parcial, ambigüedad, conflicto, ausencia de información y fuera de alcance.
- Diseñar respuestas para cada estado: establecer cuándo aclarar, cuándo abstenerse y cuándo escalar.
- Incorporar trazabilidad: registrar fuentes, decisiones y contexto con controles de privacidad adecuados.
- Construir pruebas de abstención: verificar que el sistema no complete información ausente con suposiciones.
- Operar el feedback: revisar conversaciones fallidas para mejorar la documentación, la recuperación y las reglas de negocio.
Este enfoque permite tratar la confiabilidad como una propiedad del sistema completo. El modelo es solo una parte: también importan las fuentes, los permisos, la recuperación, la validación, la interfaz, el escalamiento y la operación diaria.
Conclusión: la confiabilidad también consiste en saber cuándo no responder
Un chatbot con RAG no se vuelve confiable por estar conectado a muchos documentos ni por utilizar un modelo más capaz. La confiabilidad se construye cuando el sistema puede distinguir entre evidencia suficiente, información parcial, contradicciones, ambigüedad y ausencia de conocimiento.
La decisión principal para una empresa no es únicamente qué modelo o motor de búsqueda utilizar. También es definir qué debe hacer el asistente cuando no puede respaldar una respuesta: pedir contexto, mostrar sus límites, citar las fuentes disponibles, abstenerse o transferir el caso a una persona.
Antes de conectar un asistente a usuarios reales, define qué debe hacer cuando no tenga evidencia suficiente para responder. Esa política será tan importante como la capacidad de generar respuestas y permitirá convertir un prototipo conversacional en un componente operable de un producto o proceso empresarial.
