Fundamentos de la IA
Cómo crear un chatbot: arquitectura, datos, seguridad y evaluación
Añade Unite.AI a tus fuentes preferidas en Google
Un chatbot es una aplicación que recibe un mensaje, determina lo que el usuario necesita y devuelve una respuesta mediante texto o voz. Los sistemas modernos pueden combinar reglas, recuperación, clasificadores, transformers, herramientas y grandes modelos de lenguaje en lugar de depender de un solo modelo.
Construir un chatbot útil es, por lo tanto, un problema de producto y sistemas. La capa de diálogo debe conectarse a conocimientos confiables y acciones empresariales, mientras que la identidad, los permisos, el registro, la evaluación, la alternativa y la escalada humana limitan lo que el bot puede hacer.
Conclusiones clave
- Comience con una tarea de usuario estrecha y un criterio de éxito medible.
- Separe la generación de lenguaje de la recuperación, las herramientas, los permisos y las reglas de negocio.
- Pruebe conversaciones completas, incluyendo ambigüedad, interrupción, rechazo y recuperación.
- Trate los prompts y las salidas del modelo como datos no confiables; supervise la producción y mantenga los caminos de escalada.
Defina el trabajo antes de elegir un modelo
Anote quién es el usuario, qué intenta lograr, a qué datos puede acceder el sistema y qué acciones requieren confirmación. Un bot de preguntas frecuentes, un asistente de estado de pedidos y un agente de gestión de cuentas tienen perfiles de riesgo muy diferentes.
Cree una línea base no IA y un conjunto de aceptación de conversaciones representativas. Mida la finalización de tareas, el soporte de respuestas, la latencia, el abandono, la escalada y el costo de errores dañinos. Una demostración fluida no es evidencia de que el flujo de trabajo funcione de manera fiable.
Utilice una arquitectura en capas
Una canalización típica incluye un adaptador de canal, estado de sesión, validación de entrada, lógica de intención o enrutamiento, recuperación, un modelo de respuesta o política, adaptadores de herramientas y observabilidad. La recuperación puede fundamentar respuestas en documentos aprobados; las herramientas realizan acciones controladas mediante esquemas explícitos.
Mantenga las comprobaciones determinísticas fuera del modelo de lenguaje. La autenticación, autorización, límites de inventario, reembolsos y acciones irreversibles deben ser aplicados por el código de la aplicación. Prompt engineering puede moldear el comportamiento, pero no es un sistema de control de acceso.
Diseñe el diálogo, el conocimiento y la recuperación conjuntamente
Las buenas conversaciones manejan solicitudes incompletas, correcciones, múltiples intenciones y referencias a turnos anteriores. Almacene solo el contexto necesario para la tarea, haga visible la retención y distinga una declaración del usuario de un hecho confiable devuelto por un sistema aprobado.
Cuando la confianza o la evidencia son insuficientes, el bot debe hacer una pregunta focalizada, ofrecer una alternativa segura o transferir a una persona con un resumen conciso. La recuperación es parte de la experiencia central, no un caso marginal añadido después del lanzamiento.
Evalúe y opere el sistema completo
Pruebe la calidad de la recuperación, la selección de herramientas, la precisión de los argumentos, el cumplimiento de políticas, la resistencia a inyecciones de prompts, la filtración de privacidad y los resultados de extremo a extremo. Realice pruebas de equipo rojo con entradas adversarias y verifique que un documento malicioso no pueda sobrescribir silenciosamente las instrucciones del sistema.
Versione los prompts, índices, modelos, políticas y herramientas. Revise conversaciones muestreadas con controles de privacidad, observe el drift y los grupos de fallas, y mantenga la capacidad de retroceso. Esta disciplina operativa vincula el desarrollo de chatbots a AIOps y la respuesta a incidentes.
Componentes centrales del chatbot con más detalle
La capa de canal normaliza la entrada de chat web, aplicaciones móviles, plataformas de mensajería o voz. Una capa de sesión asocia los mensajes con una conversación autenticada o anónima, impone la expiración y almacena solo el estado necesario para la tarea. Los controles de entrada limitan el tamaño y los tipos de archivo, detectan cargas peligrosas y eliminan el marcado que los sistemas posteriores no deben ejecutar.
Un enrutador decide entonces si la solicitud pertenece a un flujo determinístico, búsqueda, generación o una cola humana. Los clasificadores de intención clásicos siguen siendo útiles cuando el conjunto de etiquetas es estable; los modelos de lenguaje son más flexibles pero más difíciles de calibrar. Los enrutadores híbridos pueden reservar tareas reguladas o de alto volumen para flujos de trabajo probados y usar un modelo general para explicaciones abiertas.
La capa de respuesta debe llevar la evidencia y el estado por separado. Una frase generada puede citar un pasaje recuperado, pero la aplicación debe preservar qué fuente y versión lo respaldaron. La memoria de la conversación debe distinguir las preferencias del usuario de los datos de cuenta verificados, y nunca debe permitir que un mensaje anterior del usuario conceda nuevos permisos.
Recuperación, herramientas y transacciones
La calidad de la recuperación comienza antes de la búsqueda vectorial. Los documentos necesitan propiedad, etiquetas de acceso, versiones canónicas, fragmentos útiles y fechas de eliminación. La reescritura de consultas, la búsqueda por palabras clave, los embeddings, los filtros y el reordenamiento pueden combinarse. La evaluación debe medir si se recuperó la evidencia necesaria, si se excluyeron pasajes irrelevantes y si la respuesta realmente sigue la evidencia.
Las herramientas convierten una sugerencia del modelo en una solicitud tipada al código de la aplicación. Cada herramienta necesita un propósito estrecho, un esquema explícito, validación del lado del servidor, credenciales de mínimo privilegio, tiempos de espera, idempotencia cuando sea posible y un resultado claro. El modelo no debe construir consultas directas a bases de datos ni URLs arbitrarias cuando se puede exponer una operación comercial delimitada.
Las transacciones requieren confirmación en el punto de compromiso. Muestre al usuario los campos materiales —destinatario, monto, dirección, fecha o cambio de acceso— y no trate un ‘sí’ anterior como aprobación para una nueva acción. Para trabajos de varios pasos, mantenga una máquina de estados fuera del modelo para que un reintento o mensaje reordenado no pueda omitir una puerta requerida.
Un plan práctico de construcción y evaluación
Comience con veinte a cincuenta tareas representativas e incluya solicitudes fallidas, ambiguas y fuera de alcance. Marque la acción esperada, la evidencia, la escalada y el comportamiento prohibido. Implemente el flujo viable más simple, luego añada recuperación o generación solo donde mejore un resultado medido. Esto produce una suite de regresión reutilizable antes de que la interfaz se complique.
Evalúe los componentes y conversaciones por separado. Las métricas de recuperación, la precisión de llamadas a herramientas, las verificaciones de políticas y el soporte de respuesta diagnostican fallas específicas; la finalización de tareas y el esfuerzo del usuario revelan la calidad a nivel de sistema. Use pruebas de múltiples turnos que corrijan detalles anteriores, interrumpan un flujo, cambien de tema, retengan información requerida y desencadenen fallas de dependencias.
El despliegue en producción debe escalonarse por grupo de usuarios, tarea y permiso. Supervise afirmaciones no admitidas, aclaraciones repetidas, rechazos de herramientas, escalada, latencia y abandono. Revise muestras seguras para la privacidad, mantenga una vía de desactivación de emergencia para cada herramienta y use los hallazgos de incidentes para actualizar prompts, datos, código y el conjunto de pruebas conjuntamente.
Ejemplo práctico: un chatbot de soporte desde prototipo hasta producción
Supongamos que un minorista desea un chatbot que responda preguntas sobre pedidos y devoluciones. Defina primero las intenciones admitidas, condiciones de escalada, conocimiento aprobado, reglas de autenticación y acciones prohibidas. Construya un conjunto de pruebas a partir de preguntas históricas desidentificadas, incluyendo solicitudes vagas, errores ortográficos, entradas multilingües, usuarios enojados, inyección de prompts y preguntas sin respuesta. Una línea base de recuperación debe devolver evidencia antes de que cualquier respuesta generativa pueda afirmar una política o el estado de un pedido.
El tiempo de ejecución puede clasificar la intención, recuperar pasajes de política, solicitar verificación de identidad solo cuando se necesiten datos de la cuenta, llamar a una API de pedidos de alcance limitado, redactar una respuesta y adjuntar citas. Cada llamada a herramienta necesita un esquema explícito, verificación de autorización, tiempo de espera, política de reintento y clave de idempotencia. El modelo nunca debe construir consultas directas a bases de datos ni decidir sus propios permisos. Acciones de alto impacto como cancelaciones o reembolsos requieren confirmación y, por encima de los límites definidos, aprobación humana.
Evalúe la precisión de la intención, la corrección de la respuesta, el soporte de evidencia, la calidad del rechazo, la contención exitosa, la precisión de la escalada, la latencia y el costo por conversación resuelta. Revise los resultados por intención y grupo de usuarios en lugar de un promedio único. En producción, registre trazas conscientes del consentimiento, resultados de herramientas, versiones de documentos recuperados y correcciones de usuarios. Despliegue gradualmente, compare con el canal existente y desactive capacidades cuando se superen los umbrales de error, abuso o dependencias.
Lista de verificación de implementación práctica
Convierta el concepto en un flujo de trabajo delimitado y verificable: defina tarea → enrutar → recuperar → generar → usar herramientas → evaluar. Nombre a un responsable, documente los datos y dependencias, establezca una línea base simple, defina criterios de aceptación y de parada, pruebe fallas representativas y defina monitoreo, retroceso y revisión antes de ampliar el alcance. Registre versiones y suposiciones para que otro equipo pueda reproducir el resultado y entender qué cambió.
Antes del lanzamiento, realice una revisión de preparación documentada con las personas que construyen, operan, aseguran y se ven afectadas por el sistema. Pruebe casos normales, condiciones límite, fallas de dependencias y usos indebidos; preserve la evidencia y los riesgos no resueltos. Defina quién puede aprobar el lanzamiento, cambiar un umbral, sobrescribir una salida o detener la operación. Revise la decisión después de que lleguen datos del mundo real, porque un piloto técnicamente exitoso no garantiza un rendimiento fiable a mayor escala.
- CONOCIMIENTO: fuentes aprobadas y citas.
- ACCIONES: herramientas tipificadas con el mínimo privilegio.
- RECUPERACIÓN: aclarar, rechazar o escalar.
Preguntas frecuentes
¿Necesita un chatbot un modelo de lenguaje grande?
No. Las reglas, la búsqueda, los formularios y los clasificadores pequeños pueden ser más seguros y económicos para tareas estrechas. Un LLM es útil cuando la comprensión o generación flexible del lenguaje aporta un valor medible.
¿Qué debe probarse antes del lanzamiento?
Tareas representativas, solicitudes no admitidas, lenguaje ambiguo, fallas de herramientas, límites de privacidad, prompts adversarios, transferencia a humanos, latencia y la precisión de cada acción consecuente.
Referencias principales
