La tecnología sola no garantiza la adopción: Lecciones de la creación de un chatbot de IA interno

Con la aceleración de la adopción de la IA en diversas industrias, desplegar un chatbot para apoyar una aplicación interna recién lanzada parecía una decisión lógica. Sin embargo, la aplicación en sí desafió las expectativas convencionales de los usuarios. Introdujo nuevos flujos de trabajo basados en tecnología emergente desconocida para la mayoría de los usuarios.

Para reducir la fricción y mejorar la adopción, el chatbot se diseñó para responder preguntas sobre la aplicación y la tecnología subyacente. El objetivo era ayudar a los usuarios a entender no solo qué hacer, sino también por qué el sistema se comportaba de esa manera. Creíamos que proporcionar explicaciones contextuales aceleraría el aprendizaje y reduciría la confusión.

Desde el principio, el agente de IA se concibió como una solución de alcance limitado. Se diseñó estrictamente para apoyar la documentación y brindar asistencia al usuario. Conceptualmente, el chatbot se pretendía como un reemplazo dinámico de un documento de Preguntas Frecuentes tradicional, ofreciendo una interfaz conversacional, searchable y continuamente disponible con funcionalidad extendida más allá del contenido estático.

Para integrar el agente en el entorno de chat interno de la organización, necesitábamos entender cómo se renderizaban los mensajes estructurados, cómo se almacenaba la historia de conversación y cómo el sistema identificaba a los participantes dentro de los hilos. Esto nos permitió determinar las variables clave necesarias para comenzar a procesar las preguntas de los usuarios.

Basar el modelo: De la alucinación al contexto confiable

Los grandes modelos de lenguaje son poderosos, pero sin anclaje contextual están propensos a alucinaciones. Para abordar esto, implementamos una técnica de incrustación de vector.

Las guías de usuario, la documentación interna y la visión del producto se transformaron en representaciones numéricas vectoriales de texto. Estas incrustaciones capturaron el significado semántico, lo que permitió al sistema emparejar conceptos en lugar de confiar en la coincidencia de palabras simples.

Cuando un usuario hacía una pregunta, el sistema convertía la consulta en una representación vectorial y la comparaba con las incrustaciones almacenadas. Recuperaba los documentos más semánticamente relevantes e inyectaba en la llamada del modelo. El modelo luego generaba una respuesta basada en esos documentos específicos, a menudo resumiendo la información relevante.

Este enfoque mejoró significativamente la precisión de las respuestas. En lugar de generar respuestas basadas puramente en conocimientos generales, el modelo respondía utilizando la documentación de nuestra organización como contexto.

La complejidad oculta de la gestión del contexto

Fue esencial incluir la historia de conversación en la llamada para que el bot pudiera interpretar preguntas de seguimiento y mantener la continuidad. Sin historia, las interacciones se volvían fragmentadas y repetitivas. Los usuarios a menudo refinaban sus preguntas de manera incremental, y sin contexto, el bot no podía interpretar referencias como “esa opción” o “el paso anterior”.

Sin embargo, incluir demasiada historia creó un problema diferente: límites de tokens. Estos ocurren cuando los modelos de lenguaje truncan las entradas que exceden su ventana de contexto máxima. Si una pregunta o conversación se volvía demasiado larga, se podía perder información importante. Esto no producía un error explícito, sino que degradaba la calidad de la respuesta o afectaba la precisión de recuperación.

Para mitigar esto, implementamos estrategias para controlar el tamaño de la llamada, priorizar el contenido relevante y monitorear la longitud de la pregunta. Experimentamos con resumir mensajes antiguos y seleccionar solo las partes más relevantes de la conversación. El contexto era crítico, pero debía manejarse con cuidado.

Ampliando las capacidades y creando confusión

Más allá de responder preguntas basadas en la documentación, extendimos las capacidades del bot agregando funciones de backend que podían extraer cierta información pública directamente de la aplicación. Esto permitió a los usuarios recuperar datos desde el chat sin iniciar sesión en la aplicación en sí. La idea era reducir la fricción y reforzar el chatbot como una interfaz útil, no solo una capa de conocimiento estática.

Esta extensión creó confusión para algunos usuarios, sin embargo. Una vez que el bot comenzó a recuperar datos en vivo, los usuarios empezaron a pedirle que ejecutara acciones que requerían interacción directa dentro de la plataforma. Asumieron que el chatbot podía reemplazar los pasos operativos, incluidos aquellos que requerían autenticación o ejecución deliberada dentro de la plataforma.

El bot nunca estuvo diseñado para realizar esas acciones, pero la distinción entre asistencia informativa y ejecución operativa no siempre estuvo clara.

Integrar datos en vivo también introdujo nuevas consideraciones técnicas. Necesitábamos definir cuándo una pregunta debía pasar por recuperación basada en incrustaciones y cuándo debía desencadenar una llamada de backend. Esa lógica de decisión requirió un diseño cuidadoso. Además, tuvimos que ajustar las respuestas para manejar graciosamente las excepciones técnicas y evitar exponer errores del sistema crudo a los usuarios.

La capacidad multilingüe no es automática

Durante las pruebas, nos dimos cuenta de que el bot funcionaba consistentemente mejor en inglés que en otros idiomas utilizados dentro de Jalasoft. La razón principal era estructural: la mayoría de la documentación utilizada para generar incrustaciones estaba escrita en inglés, y el modelo de incrustaciones que seleccionamos estaba optimizado para la similitud semántica en inglés.

No admitía recuperación cruzada lingüística ni comparación semántica entre idiomas. Como resultado, las consultas no en inglés a menudo recuperaban documentación menos relevante, lo que llevaba a respuestas más débiles.

Esto destacó una idea importante: la capacidad multilingüe no es automática.

Cuando las expectativas se expanden más allá del alcance

Para controlar los costos de uso, implementamos un límite diario en la cantidad de preguntas que los usuarios podían hacer. Sin embargo, no restringimos explícitamente el alcance de esas preguntas. Los usuarios eran libres de preguntar cualquier cosa.

Esta apertura condujo a patrones de uso inesperados. Algunos usuarios comenzaron a interactuar con el bot para fines personales o exploratorios no relacionados con la aplicación. Con el tiempo, las expectativas superaron el papel previsto del bot, creando una brecha entre lo que los usuarios esperaban que pudiera hacer y lo que estaba diseñado para apoyar.

Esta desalineación redujo gradualmente su utilidad percibida. El uso disminuyó, y el chatbot fue finalmente descontinuado, con esfuerzos redirigidos hacia el rediseño de la aplicación en sí para hacerla más intuitiva y fácil de usar.

La lección real: Diseño de interacción.

Desde un punto de vista de ingeniería, el sistema funcionó razonablemente bien. Recuperaba documentación, incorporaba la historia de conversación, reducía las alucinaciones a través de incrustaciones, manejaba llamadas de backend y controlaba el tamaño de la llamada. La arquitectura funcionó como se pretendía.

Pero le faltaba un diseño de interacción intencional.

El bot no moldeó claramente las conversaciones. No reforzó consistentemente su alcance. No guió a los usuarios con ejemplos estructurados de lo que podía y no podía hacer. Respondió preguntas, pero no estableció expectativas.

Aprendimos que los sistemas de IA conversacional requieren más que modelos fuertes y datos estructurados. Requieren expectativas cuidadosamente diseñadas. Los usuarios necesitan claridad sobre el papel del agente, sus límites y sus fortalezas. El sistema debe proporcionar proactivamente ejemplos de llamadas, aclarar limitaciones y redirigir preguntas fuera del alcance de manera consistente.

Sin este marco intencional, incluso una implementación técnicamente sólida puede luchar por mantener el valor. Los usuarios pueden sobreestimar las capacidades o desconectarse cuando las expectativas no declaradas no se cumplen.

La idea central es simple pero poderosa.

Construir IA conversacional no es solo un desafío técnico. Es también un desafío de diseño de interacción.

Un contexto sólido, una recuperación precisa y una arquitectura robusta son necesarios, pero no suficientes. La efectividad del sistema depende igualmente de cómo define su papel, comunica sus límites y moldea las expectativas de los usuarios.

La tecnología sola no garantiza la adopción. Un diseño de interacción claro sí.