Chatbots / IA conversacional / Modelos de lenguaje grandes / Alfabetización en IA
Cómo funcionan realmente los chatbots: reglas, recuperación, LLM, herramientas y transferencia a humanos
Una conversación con un chatbot puede parecer sencilla hasta el momento en que falla. Preguntas dónde está un paquete. El bot repite una política de entrega genérica. Proporcionas el número de pedido. Vuelve a pedir el número de pedido. Después de tres vueltas, la pequeña burbuja de chat que prometía comodidad se ha convertido en una puerta cerrada entre tú y la respuesta.
La experiencia opuesta es casi invisible. El chatbot reconoce que quieres rastrear un pedido, captura el número correcto, consulta un registro actual, explica el resultado en una frase y ofrece una persona si el caso es inusual. La diferencia no es simplemente que un bot tenga más inteligencia artificial. Es que un sistema conversacional tiene una tarea más clara, mejor estado, herramientas confiables, límites más seguros y una forma planificada de recuperarse.
Esta guía mira detrás de la burbuja de chat. Explica los principales tipos de chatbot, sigue un mensaje a través de una arquitectura real y muestra por qué el lenguaje fluido es solo una parte de una conversación confiable.
¿Qué es un chatbot?
Un chatbot es un software que intercambia mensajes con una persona a través de texto, voz u otro canal conversacional. Interpreta una entrada, decide qué debería suceder después y devuelve una respuesta o acción. Esa definición amplia incluye un menú fijo en un widget de soporte, un flujo de voz que recopila un número de cuenta, un asistente de conocimiento que busca en documentos y un sistema de modelo de lenguaje que puede redactar respuestas abiertas.
La conversación es la interfaz, no la tecnología subyacente. Dos chatbots pueden parecer idénticos mientras funcionan de maneras completamente diferentes. Uno sigue un árbol de decisiones. Otro coincide con una intención y llama a un webhook. Un tercero recupera documentos y pide a un modelo de lenguaje grande que escriba una respuesta. Los sistemas más útiles a menudo combinan varios enfoques.
Una lección de ELIZA, sesenta años después
En 1966, Joseph Weizenbaum publicó ELIZA, un programa para la conversación en lenguaje natural. Su conocido script DOCTOR usaba patrones y transformaciones para convertir partes de la declaración de un usuario en una respuesta. Una frase como “no soy feliz” podía coincidir, reorganizarse y reflejarse como una pregunta. El intercambio podía parecer atento aunque el programa tuviera poca información sobre la vida de la persona y ningún modelo de lenguaje moderno.
ELIZA sigue siendo relevante porque las personas responden al lenguaje socialmente. Una pregunta oportuna, una frase comprensiva o una respuesta segura pueden crear una impresión de comprensión que supera la maquinaria subyacente. Los modelos modernos son mucho más capaces, pero la interfaz aún invita al mismo error: juzgar lo que un sistema sabe por lo natural que suena.
Un chatbot profesional debe ganar confianza mediante la finalización correcta de tareas, límites visibles y errores recuperables. La personalidad puede mejorar una interacción. No puede reemplazar el acceso a la información correcta o un proceso seguro.
Tres arquitecturas principales de chatbot
Los chatbots son más fáciles de entender si separamos tres familias arquitectónicas. Estas no son generaciones estrictas donde cada nueva hace obsoletas a las demás. Son herramientas con diferentes fortalezas.
1. Reglas y flujos de conversación
Un chatbot basado en reglas sigue caminos diseñados de antemano. Puede mostrar botones, coincidir palabras clave, completar un formulario o moverse entre estados cuando se cumplen condiciones. La lógica puede ser explícita: si el usuario quiere cambiar una fecha de entrega, recopilar el número de pedido, verificar si el paquete es elegible, mostrar fechas disponibles y pedir confirmación.
Las reglas son valiosas cuando el proceso es limitado y las acciones aceptables son conocidas. Hacen que los pasos de cumplimiento y las acciones destructivas sean más fáciles de controlar. Su debilidad aparece cuando las personas expresan solicitudes de maneras inesperadas o se salen del camino diseñado. Un buen sistema de reglas necesita respaldos, correcciones y rutas de escape, no solo un camino feliz perfecto.
2. Coincidencia de intenciones y recuperación
Un sistema basado en intenciones estima lo que el usuario intenta hacer, luego extrae detalles útiles llamados entidades o parámetros. “Rastrear pedido 4821” puede asignarse a una intención de rastrear pedido y un parámetro de número de pedido. La documentación de intenciones de Dialogflow de Google Cloud describe este patrón como comparar una entrada con frases de entrenamiento para encontrar una coincidencia.
La recuperación agrega una capa de búsqueda. En lugar de responder solo desde una respuesta fija, el sistema encuentra pasajes relevantes, entradas de políticas, artículos de ayuda o registros. Un chatbot de recuperación puede citar una respuesta conocida directamente o pasar material seleccionado a un generador. Su calidad depende de qué se indexó, cómo se formó la consulta, si la fuente está actualizada y si el sistema encontró el pasaje correcto.
3. Modelos de lenguaje, herramientas y sistemas híbridos
Un modelo de lenguaje grande puede interpretar frases variadas y producir respuestas naturales en un rango mucho más amplio de entradas. Puede resumir, explicar, traducir, hacer una pregunta aclaratoria o convertir la salida estructurada de una herramienta en lenguaje legible. Para una explicación más profunda de la generación de tokens y los límites del modelo, consulta ¿Qué es la IA, realmente?.
El modelo aún necesita ayuda con hechos y acciones en vivo. No puede saber la ubicación actual del pedido 4821 a menos que la aplicación proporcione esa información a través de contexto, recuperación o una herramienta. No puede emitir un reembolso de manera segura solo porque puede escribir la frase “Su reembolso está completo”. La aplicación debe conectar el modelo a servicios autorizados y verificar el resultado.
Por eso muchos chatbots modernos son híbridos. Las reglas protegen transiciones críticas. La recuperación proporciona conocimiento actual. Un modelo de lenguaje maneja lenguaje flexible. Las herramientas leen o cambian el estado externo. El código convencional valida permisos y salidas. Un humano toma casos que requieren juicio o autoridad.
Qué sucede durante un turno de chatbot
Sigue un mensaje simple: “¿Dónde está el pedido 4821?” Una implementación real puede combinar o renombrar los pasos, pero las responsabilidades subyacentes siguen siendo reconocibles.
- Recibir y normalizar la entrada. El canal puede proporcionar texto escrito, voz transcrita, selecciones de botones, idioma o metadatos de sesión.
- Identificar el objetivo. El sistema determina si la solicitud se refiere a seguimiento, cancelación, pago, otro tema o algo no compatible.
- Extraer detalles requeridos. En este caso, el número de pedido es 4821. Si falta o es ambiguo, el bot debe preguntar en lugar de inventarlo.
- Verificar el estado de la conversación. El sistema determina lo que ya sabe, lo que puede retener y qué paso está activo.
- Recuperar conocimiento o llamar a una herramienta. Un servicio de seguimiento devuelve el estado actual. El chatbot no debe crear ese estado a partir de patrones de lenguaje.
- Redactar y validar la respuesta. La aplicación convierte el resultado en lenguaje claro, verifica los campos requeridos y evita exponer datos internos o personales.
- Responder, recuperarse o transferir. Un resultado normal regresa al usuario. Un error, caso no compatible o solicitud de una persona sigue una ruta diferente.
Google Cloud usa el término fulfillment para la parte de un turno conversacional que devuelve una respuesta estática, llama a un webhook para información dinámica, establece parámetros o realiza una acción. Su documentación de fulfillment de Dialogflow hace una distinción importante: comprender la solicitud y cumplirla son responsabilidades separadas.
El estado de la conversación no es memoria humana
Un chatbot necesita suficiente estado para evitar comenzar de nuevo en cada turno. El estado de sesión podría registrar que la tarea actual es el seguimiento de paquetes, el número de pedido es 4821 y el usuario ya ha confirmado un código postal. Sin estado, “¿Y el segundo paquete?” no tiene una referencia utilizable.
Ese estado son datos diseñados, no un recuerdo humano. Algunos sistemas mantienen solo la sesión actual. Otros almacenan historial de conversación, resúmenes, preferencias o información de cuenta. Un modelo también puede recibir solo parte de una conversación larga porque su contexto tiene una capacidad finita o porque la aplicación limita deliberadamente lo que se envía.
Los usuarios no deben asumir que un chatbot olvida cuando se cierra una ventana o recuerda porque habla como si lo hiciera. La retención, el vínculo con la cuenta, el uso de entrenamiento y la eliminación dependen del servicio específico. Antes de compartir información sensible, revisa la explicación de privacidad del servicio y usa la información mínima necesaria para la tarea.
Cómo funciona la generación aumentada por recuperación
Los parámetros de un modelo de lenguaje son un mal lugar para mantener una política de devoluciones que cambia con frecuencia. La generación aumentada por recuperación, generalmente abreviada como RAG, aborda esto buscando en una colección externa material relevante y colocando pasajes seleccionados en el contexto del modelo antes de que escriba la respuesta.
El artículo de Generación Aumentada por Recuperación original combinó un generador preentrenado con memoria explícita no paramétrica recuperada de un índice. El patrón amplio ahora aparece en muchos asistentes de conocimiento: buscar primero, generar después.
Un pipeline RAG útil tiene al menos cuatro oportunidades de fallar. La colección de fuentes puede estar incompleta. El documento puede estar desactualizado. La recuperación puede seleccionar un pasaje irrelevante. El generador puede malinterpretar o embellecer lo que recibió. Las citas ayudan solo si apuntan a la fuente de apoyo exacta y el usuario puede inspeccionarla.
Por lo tanto, RAG mejora el acceso a conocimiento actual e inspeccionable, pero no garantiza la verdad. Debe evaluarse de extremo a extremo: ¿la fuente correcta entró en el índice, la búsqueda la encontró, la respuesta se mantuvo dentro de la evidencia y la cita respaldó la afirmación?
Las respuestas y las acciones requieren diferentes niveles de control
Un chatbot que explica una política de reembolso no es lo mismo que un chatbot que emite un reembolso. El segundo sistema puede cambiar el estado externo. Puede llamar a un servicio de cuenta, calendario, sistema de pago, herramienta de mensajería o control de dispositivo. Esa capacidad a veces se describe como agencia, pero la pregunta práctica es más simple: ¿qué puede hacer esta aplicación además de producir texto?
Una ruta de acción segura debe mantener las verificaciones importantes fuera de la prosa del modelo:
- Autenticar al usuario y confirmar que la cuenta o el recurso le pertenece.
- Autorizar la acción específica en lugar de dar al chatbot acceso amplio.
- Validar argumentos de herramientas, montos, destinos y rangos permitidos con código convencional.
- Requerir confirmación explícita antes de acciones irreversibles o costosas.
- Devolver un resultado de herramienta verificado en lugar de asumir que una acción tuvo éxito.
- Registrar suficiente información para investigar fallas sin exponer datos sensibles innecesarios.
La ilustración muestra una arquitectura objetivo, no una promesa sobre ningún chatbot en particular. Un modelo de lenguaje puede sugerir qué herramienta llamar, pero la aplicación circundante debe decidir si la llamada está permitida. Más autonomía aumenta el valor de los límites de permisos, límites de velocidad, confirmación, monitoreo y revisión humana.
Inyección de prompt: cuando el contenido intenta convertirse en una instrucción
Un chatbot que usa herramientas o recuperación puede leer texto proporcionado por usuarios, sitios web, correos electrónicos o documentos. Parte de ese texto puede contener instrucciones dirigidas al modelo, como decirle que ignore reglas anteriores, revele información oculta o llame a una herramienta de manera no intencionada. Esto es inyección de prompt.
El Proyecto de Seguridad GenAI de OWASP enumera la inyección de prompt como un riesgo principal para aplicaciones de modelos de lenguaje. El problema central es que los modelos procesan instrucciones y contenido ordinario a través del mismo canal de lenguaje. Un documento no confiable puede parecer gramaticalmente similar a una instrucción de la aplicación.
Ningún prompt puede reemplazar los controles a nivel de sistema. Las aplicaciones deben tratar el contenido recuperado y proporcionado por el usuario como no confiable, restringir las herramientas disponibles, aplicar privilegio mínimo, validar llamadas a herramientas, aislar operaciones sensibles y pedir confirmación donde las consecuencias importan. El modelo no debe recibir una llave maestra solo porque la interfaz es conversacional.
Por qué los chatbots dan respuestas incorrectas o frustrantes
Malinterpretan la solicitud
El lenguaje es ambiguo. “Cerrar mi cuenta” podría significar cerrar sesión, eliminar un perfil, cancelar una suscripción o cerrar una cuenta financiera. Un chatbot confiable reconoce cuando el costo de adivinar es mayor que el costo de una pregunta aclaratoria.
Les falta la información requerida
Un modelo puede conocer vocabulario general de envío pero carecer del registro de pedido del usuario. La recuperación puede no encontrar la política relevante. Una herramienta puede no estar disponible. La respuesta correcta es indicar la limitación o usar un respaldo, no llenar el vacío con una historia plausible.
Generan una falsedad confiada
NIST llama confabulación al contenido generativo falso o erróneo presentado con confianza. Su Perfil de IA Generativa señala que este comportamiento puede incluir lógica o citas fabricadas. La fluidez hace que estos fallos sean más difíciles de notar, no menos importantes.
Pierden el estado o arrastran el estado incorrecto
Una sesión puede olvidar un detalle, confundir dos pedidos, preservar una suposición incorrecta o aplicar información de una tarea a otra. El estado debe ser lo suficientemente visible para corregirse y lo suficientemente limitado para evitar mezclas no intencionadas.
No tienen una salida elegante
El bucle más doloroso suele ser un fallo de diseño. El bot ha llegado al límite de su capacidad pero sigue reformulando la misma respuesta. Una alternativa debería cambiar el camino: pedir un dato faltante, mostrar una opción admitida, crear un caso o transferir la conversación.
La transferencia a un humano es parte del sistema, no una admisión de derrota
Algunas solicitudes son ambiguas, emocionales, excepcionales o de gran repercusión. Otras requieren autoridad que el chatbot no debería tener. Un especialista humano puede interpretar el contexto, negociar una excepción, asumir la responsabilidad o reconocer que el proceso documentado no se ajusta al caso.
Una transferencia funciona solo si el contexto viaja con ella. La persona debe recibir el objetivo del usuario, los detalles confirmados, los resultados relevantes de las herramientas y el motivo de la escalada. Obligar al usuario a repetir toda la conversación convierte una transferencia técnicamente exitosa en una mala experiencia.
La documentación de transferencia a agente en vivo de Dialogflow trata la transferencia como una transición explícita. Ese principio de diseño es más amplio que una sola plataforma: la escalada debe ser una ruta probada con responsabilidad, no una frase que el bot improvisa cuando se queda atascado.
Cómo juzgar si un chatbot es bueno
Una demostración convincente es fácil de montar. Un chatbot confiable debe manejar la variación ordinaria y el fallo visible. La evaluación debe comenzar con la tarea que el usuario vino a completar.
- Finalización de la tarea: ¿obtuvo el usuario la respuesta o completó la acción correctamente?
- Fundamentación: ¿las afirmaciones factuales siguieron la fuente proporcionada o el resultado verificado de la herramienta?
- Recuperación: ¿la información faltante, los eventos sin coincidencia y los fallos de las herramientas condujeron a un siguiente paso útil?
- Seguridad: ¿la autorización, la confirmación, el manejo de datos y los límites de las herramientas se mantuvieron ante entradas adversarias?
- Calidad de la transferencia: ¿la conversación llegó a la persona adecuada con suficiente contexto?
- Idioma y accesibilidad: ¿el flujo funcionó en los idiomas admitidos, estilos de escritura, condiciones de voz, navegación con teclado y tecnología de asistencia?
- Esfuerzo del usuario: ¿cuántos turnos, repeticiones y correcciones se requirieron para terminar la tarea?
Las conversaciones de prueba deben incluir más que el camino feliz. Use números de pedido faltantes, dos números en un mensaje, errores ortográficos, solicitudes no admitidas, documentos desactualizados, tiempos de espera de herramientas, solicitudes para cambiar de tema, peticiones directas de una persona e instrucciones maliciosas ocultas en el contenido recuperado. La guía de diseño de agentes de Google Cloud recomienda de manera similar el diseño iterativo y los casos de prueba en lugar de intentar diseñar cada camino a la vez.
Cómo usar un chatbot sin renunciar al criterio
- Indique el objetivo y el contexto mínimo relevante. Una solicitud precisa reduce turnos innecesarios.
- No pegue contraseñas, códigos de autenticación, credenciales de pago, claves privadas o registros sensibles a menos que el servicio confiable específico lo exija y proteja explícitamente.
- Distinga una explicación de un resultado en vivo. Pregunte si la respuesta provino de un registro actual, una fuente citada o el conocimiento general del modelo.
- Abra las citas y verifique las afirmaciones de gran repercusión. Un enlace de fuente puede ser irrelevante, desactualizado o inconsistente con la respuesta.
- Revise cada acción antes de confirmarla. Verifique la cuenta, el monto, el destino, la fecha y si el cambio se puede revertir.
- Solicite una persona cuando el bot se repite, carece de autoridad, malinterpreta un tema sensible o no puede mostrar de dónde provino la respuesta.
El modelo mental que vale la pena conservar
Un chatbot no es una personalidad que vive dentro de una burbuja. Es una interfaz conversacional conectada a alguna combinación de flujos, clasificadores, búsqueda, modelos de lenguaje, registros, herramientas, políticas, controles de seguridad y personas. La respuesta que ve es el último paso de ese sistema más amplio.
La mejor pregunta no es «¿Este bot suena humano?». Pregunte si entendió la tarea, usó la evidencia correcta, respetó sus permisos, se recuperó con honestidad y le dejó el control. El lenguaje natural hace que el sistema sea más fácil de abordar. Una buena ingeniería hace que valga la pena usarlo.
Referencias principales y técnicas
- Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
- Google Cloud, Dialogflow CX documentation for intents, fulfillment, agent design, and human handoff.
- OWASP GenAI Security Project, LLM01:2025 Prompt Injection.