La Tecnología por Sí Sola No Garantiza la Adopción: Lecciones de la Construcción de un Chatbot de IA Interno

A medida que la adopción de la IA se aceleró en various industrias, desplegar un chatbot para respaldar 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 construidos sobre 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 respaldar la documentación y brindar asistencia al usuario. Conceptualmente, el chatbot se pretendía que sirviera como un reemplazo dinámico de un documento tradicional de Preguntas Frecuentes, 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 básicas necesarias para comenzar a procesar las preguntas de los usuarios.

Basar el Modelo: De la Alucinación a un 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 vectores.

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

Cuando un usuario hacía una pregunta, el sistema convertía la consulta en una representación de vector y la comparaba con las incrustaciones almacenadas. Recuperaba los documentos más semánticamente relevantes e los inyectaba en la llamada del modelo. El modelo generaba entonces una respuesta basada en esos documentos específicos, resumiendo a menudo 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 de 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 refinan 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, la información importante podría perderse. 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 la resumen de mensajes antiguos y la inclusión selectiva de solo las partes más relevantes de la conversación. El contexto era crítico, pero debía manejarse con cuidado.

Ampliar Capacidades y Crear 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 debería pasar por recuperación basada en incrustaciones y cuándo deberí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 técnicamente excepciones y evitar exponer errores del sistema crudos 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 se escribió en inglés, y el modelo de incrustación que seleccionamos se optimizó para la similitud semántica en inglés.

No admitía recuperación cruzada de lenguaje ni comparación semántica entre lenguajes. 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 Exceden el Alcance

Para controlar los costos de uso, implementamos un límite diario en el número 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 llevó a patrones de uso inesperados. Algunos usuarios comenzaron a interactuar con el bot para propósitos personales o de exploración no relacionados con la aplicación. Con el tiempo, las expectativas crecieron más allá del papel previsto del bot, creando una brecha entre lo que los usuarios esperaban que pudiera hacer y lo que estaba diseñado para respaldar.

Esta desalineación redujo gradualmente su utilidad percibida. El uso disminuyó, y el chatbot finalmente se descontinuó, con esfuerzos redirigidos hacia la reingeniería 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 alucinaciones a través de incrustaciones, manejaba llamadas de backend y gestionaba 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 moldeaba claramente las conversaciones. No reforzaba consistentemente su alcance. No guiaba a los usuarios con ejemplos estructurados de lo que podía y no podía hacer. Respondía preguntas, pero no establecía expectativas.

Aprendimos que los sistemas de IA conversacional requieren más que modelos sólidos y datos estructurados. Requieren expectativas diseñadas con cuidado. 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 su 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, recuperación precisa y 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 por sí sola no garantiza la adopción. Un diseño de interacción claro sí.