Si quieres crear tu propio chatbot estilo ChatGPT con código abierto
(hacks.mozilla.org)- Un pequeño equipo del grupo de innovación de Mozilla creó un prototipo de chatbot interno durante un hackatón de una semana, probando una configuración para ejecutar LLM de código abierto dentro de la nube de Mozilla sin APIs de terceros
- Al excluir AI SaaS externos, tuvieron que montar servidores directamente dentro de la cuenta de GCP de Mozilla, y cambiaron de Hugging Face text-generation-inference a llama.cpp, que podía ponerse en marcha más rápido
- La selección del modelo quedó determinada antes por la licencia y la compatibilidad del runtime que por la calidad, y tras evaluar manualmente candidatos de la familia LLaMA aptos para uso comercial, eligieron LLaMA 2
- La integración de conocimiento interno se implementó con embeddings y búsqueda vectorial, combinando all-mpnet-base-v2, SentenceTransformers, LangChain y FAISS para usar parte del wiki de la empresa en las respuestas
- El prototipo quedó listo, pero para crear un chatbot de código abierto confiable todavía hay muchas áreas que decidir por cuenta propia, desde hosting y evaluación de modelos hasta sesgos, prompts y UI
El chatbot interno que Mozilla quería construir
- Mozilla plantea principios de trustworthy AI según los cuales los sistemas de IA deben ser transparentes sobre los datos que usan y sus decisiones, respetar la privacidad, autonomía y seguridad de las personas usuarias, y reducir sesgos para mejorar la equidad
- Para mucha gente, la principal vía para experimentar la IA más reciente son los chatbots de IA generativa como ChatGPT y Bard, y los servicios dominantes suelen estar operados por grandes empresas tecnológicas y depender de tecnología propietaria
- Mozilla considera que el código abierto es una forma de empoderar a las personas usuarias, aumentar la transparencia y evitar que la tecnología evolucione solo según la visión del mundo y los incentivos financieros de unas pocas empresas
- El objetivo directo del hackatón era crear un prototipo de chatbot interno que cumpliera las siguientes condiciones
- Ejecutarse completamente en la infraestructura cloud de Mozilla, sin depender de APIs ni servicios de terceros
- Estar construido con LLM y herramientas gratuitas de código abierto
- Reflejar el Mozilla Manifesto y los principios de trustworthy AI
- Integrar parte del conocimiento interno de Mozilla para poder responder preguntas de empleados
Hosting: servidores propios en GCP en lugar de SaaS externo
- Hay muchos servicios para alojar aplicaciones de machine learning, pero MLOps es difícil, y una app de IA mal configurada puede volverse lenta, costosa o de baja calidad
- El objetivo explícito del equipo era la seguridad y privacidad: que ninguna parte externa pudiera enterarse de cómo se usaba, recopilar datos de usuarios o inspeccionar el uso
- Por eso no usaron hosting AI SaaS de terceros y en su lugar configuraron sus propios servidores virtuales dentro de la cuenta existente de Google Cloud Platform de Mozilla
- Esta decisión les hizo asumir directamente MLOps, pero a cambio permitió que Mozilla mantuviera el sistema bajo su control y en privado
Runtime: cambio de Hugging Face a llama.cpp
- Las aplicaciones con LLM necesitaban un motor de runtime para ejecutar el modelo, y por restricciones de tiempo el equipo se enfocó en llama.cpp y el ecosistema de Hugging Face
- Hugging Face ofrece una biblioteca de modelos, documentación, tutoriales y APIs de inferencia alojadas
- En vez de la API alojada, el equipo probó el proyecto open source text-generation-inference
- text-generation-inference soporta varios modelos y arquitecturas, y puede desplegarse con Docker, pero durante la ejecución del servidor hubo muchos problemas de configuración del entorno
- Al ser una herramienta con aceleración por GPU, requería una combinación compatible de OS, hardware y drivers del servidor
- Requería el CUDA toolkit de NVIDIA
- Pasaron buena parte de un día en la configuración y, aun cuando logró ejecutarse, la salida era más lenta de lo esperado y la calidad de los resultados no era buena
- Por la limitación de tiempo, cambiaron de rumbo hacia llama.cpp, iniciado por Georgi Gerganov
- llama.cpp facilita ejecutar ciertas familias de LLM en hardware de consumo
- Puede usar CPU en lugar de GPU de gama alta, y ejecuta relativamente bien modelos open source modernos y pequeños, especialmente en CPU Apple Silicon como M1 y M2
- llama-cpp-python ofrece una implementación de la OpenAI API specification, lo que facilita reemplazar ChatGPT por un LLM propio
- Al final, en lugar de lidiar con versiones de CUDA y costosas GPU de hosting, ejecutaron llama.cpp rápidamente en un servidor virtual AMD multinúcleo
Selección del modelo: restricciones de licencia y arquitectura
- Una vez elegido llama.cpp, los modelos disponibles se limitaron a modelos basados en la arquitectura LLaMA
- Facebook presentó LLaMA a finales de 2022, y LLaMA puede separarse entre datos del modelo y arquitectura
- La arquitectura LLaMA se publicó como open source, pero los weights del modelo no eran open source
- Para usar esos weights había que pedir autorización y estaban restringidos a fines no comerciales
- LLaMA impulsó muchas innovaciones de modelos, como Alpaca de Stanford y Vicuna de LMSYS
- Pero como estos modelos se desarrollaron usando los weights de Facebook, heredaban las restricciones legales de esos weights originales
- No podían usarse con fines comerciales, así que quedaron fuera de los candidatos del equipo de Mozilla
- Como la propia arquitectura LLaMA es código open source, otros grupos pudieron entrenar modelos desde cero y publicarlos con licencias MIT, Apache 2.0 o Creative Commons
- Modelos basados en otras arquitecturas, como MPT, Falcon y Open Assistant, quedaron fuera porque en ese momento no podían ejecutarse en llama.cpp
Evaluación de calidad, sesgos y seguridad del modelo
- La selección del modelo afecta directamente la confiabilidad, además de la licencia y la compatibilidad
- Los LLM se entrenan con enormes volúmenes de datos y luego se ajustan con entradas adicionales para producir ciertos comportamientos y salidas
- Esa selección de datos ya es en sí misma una curaduría y contiene distintos sesgos
- Los modelos muestran características distintas según sus fuentes de entrenamiento
- Pueden generar respuestas sin sentido, como alucinaciones
- Pueden derivar en contenido tóxico, desinformación o compartir información peligrosa o dañina
- Pueden mostrar sesgos hacia conceptos o grupos de personas
- El hecho de que la mayor parte del material de aprendizaje en línea esté en inglés afecta tanto la utilidad de la herramienta como la visión del mundo a la que expone
- Existen recursos para evaluar rendimiento y calidad, como el Open LLM leaderboard de Hugging Face, pero sigue siendo difícil comparar modelos según sus orígenes y sesgos
- El equipo de Mozilla acotó la búsqueda a modelos abiertos aptos para uso comercial y compatibles con la arquitectura LLaMA, y luego realizó una evaluación manual haciendo varias preguntas para observar toxicidad, sesgo, desinformación y resistencia a contenido peligroso
- La elección final fue LLaMA 2 de Facebook, pero no puede verse necesariamente como una recomendación, porque la metodología de evaluación bajo tiempo limitado pudo tener fallas y tampoco se sentían completamente cómodos con las condiciones de licencia
Integración de conocimiento interno: embeddings y búsqueda vectorial
- El equipo de Mozilla quería conectar parcialmente el chatbot con datos internos de Mozilla a los que el personal sí podía acceder, pero que un LLM general no podía conocer
- El enfoque elegido fue usar embeddings y búsqueda vectorial para aprovechar documentos externos durante la generación de respuestas
- El flujo básico era el siguiente
- Extraer los datos a usar desde su repositorio original y convertirlos con un modelo de embeddings
- Indexar esos embeddings en una base de datos vectorial accesible para el chatbot
- Cuando una persona usuaria hace una pregunta, el chatbot busca contenido relacionado en la base de datos vectorial
- El contenido relacionado recuperado se inserta en la ventana de contexto del modelo base para generar la respuesta
- Para mantener el control de los datos, el equipo no usó servicios de embeddings ni bases de datos vectoriales de terceros
- La solución que implementaron directamente en Python utilizó las siguientes herramientas
- Modelo de embeddings all-mpnet-base-v2
- Biblioteca de embeddings SentenceTransformers
- LangChain
- Base de datos vectorial FAISS
- Como solo cargaron algunos documentos del wiki interno de la empresa, el alcance fue limitado, pero funcionó como prueba de concepto
Prompt engineering y ventana de contexto
- Los LLM empiezan cada vez sin recordar la conversación anterior ni a la persona usuaria, así que para que un chatbot pueda mantener una conversación, los desarrolladores deben encargarse de la gestión de memoria
- El system prompt es una instrucción inicial en texto plano que define las capacidades y el comportamiento del chatbot
- El equipo de Mozilla diseñó el system prompt para que el chatbot siguiera el Mozilla Manifesto, se comportara con respeto y cumpliera políticas de no discriminación
- Ante una pregunta sobre la teoría de que el alunizaje del Apollo fue falsificado, cuando tenía la instrucción de rechazar desinformación respondió que el alunizaje no fue montado
- Al quitar del mismo modelo la indicación de no difundir desinformación, entregó una lista típica de argumentos negacionistas sobre Apollo
- El system prompt incluía el nombre Mozilla Assistant, adhesión a los principios del Mozilla Manifesto, respeto, profesionalismo e inclusión, rechazo a acciones dañinas, inmorales, antiéticas o posiblemente ilegales, y prohibición de desinformación y lenguaje discriminatorio
- Todos los LLM tienen una ventana de contexto, que es la longitud máxima que pueden recordar dentro de la conversación actual
- En la mayoría de los casos se define al momento del entrenamiento y luego no puede cambiarse
- Cuanto mayor es la ventana de contexto, por más tiempo puede referirse a preguntas y respuestas previas
- También permite incluir fragmentos más grandes de contenido recuperado desde la búsqueda vectorial
- La ventana de contexto de LLaMA 2 era de 4096 tokens, aproximadamente 3000 palabras
- Para ahorrar espacio en la ventana de contexto, el equipo fue reduciendo repetidamente la longitud del system prompt, y planea evaluar en el futuro modelos con soporte para ventanas de contexto más amplias
Orquestación y elección de UI
- Un chatbot completo necesita orquestación para coordinar varias capas, como inyección de prompts del agente, gestión de la ventana de contexto, embeddings de contenido interno, llamadas al LLM y procesamiento de respuestas
- LangChain, una de las herramientas más representativas del área LLM, es potente y flexible, pero también compleja
- El equipo de Mozilla usó LangChain de forma mínima, solo para embeddings y búsqueda vectorial
- Como era un proyecto corto y con muchas restricciones, la mayor parte la resolvieron con código Python escrito por ellos mismos
- Si hubieran tenido más tiempo, probablemente no habrían hecho todo manualmente
- La UI requiere más funciones de las que parece a simple vista, como mostrar conversaciones, seguir hilos anteriores y manejar procesamiento de backend con velocidad de salida irregular
- Entre las UI open source para chatbots, chatbot-ui implementa la OpenAI API y puede usarse como reemplazo de la UI de ChatGPT, además de servir fácilmente como frontend para un sistema LLM propio
- Normalmente el equipo de Mozilla habría usado un proyecto como chatbot-ui, pero como contaban con el código del chatbot experimental interno Companion y con su autor, usaron eso como UI
- Companion les permitió iterar y experimentar rápidamente con la interfaz
Resultado del hackatón y tareas pendientes
- Al terminar el hackatón, el equipo de Mozilla completó un chatbot prototipo para uso interno
- Totalmente alojado dentro de Mozilla
- Seguro y usable de forma privada
- Diseñado para intentar reflejar los valores de Mozilla en su comportamiento
- Lograr esos objetivos exigió varias decisiones difíciles y compromisos
- Lo aprendido puede resumirse en tres puntos
- Los chatbots open source siguen evolucionando, todavía hay mucho por decidir, falta documentación clara y hay muchas formas de equivocarse
- Es demasiado difícil evaluar y elegir modelos con criterios distintos al rendimiento bruto, por lo que también es difícil tomar las decisiones correctas para aplicaciones de IA confiables
- Por ahora, el prompt engineering efectivo es importante para el éxito de un chatbot
- Mozilla empezó a trabajar en formas de facilitar la entrada de desarrolladores al ecosistema open source de machine learning, y quiere contribuir a la comunidad open source a partir del trabajo del hackatón
- En un contexto donde los LLM open source están ampliamente disponibles, para construir un futuro mejor hace falta que todos participemos de forma colectiva y activa en cómo se les da forma
1 comentarios
Opiniones de Hacker News
Si uno intenta contactar a una empresa, es porque no pudo encontrar la respuesta en el sitio o porque necesita pedirle a una persona responsable algo que no se puede hacer desde el sitio web. Por ejemplo, cancelar un servicio
Una página de FAQ conversacional parece un intento de cubrir una mala experiencia de usuario, y si la empresa no puso en el sitio web la información que busco, es muy probable que tampoco la haya puesto en el chatbot
Dicho eso, un chatbot puede ayudar a conectar con la persona adecuada, pero ponerlo como barrera antes de recibir ayuda humana me parece un antipatrón
Por eso muchos sitios muestran un montón de preguntas que recomiendan respuestas relevantes según la descripción antes de contactar a soporte, y el soporte de AWS también lo hace así
Los bots pueden ser molestos, pero también pueden reducir mucho los costos de atención al cliente. Si la experiencia de usuario es buena y, cuando el bot no puede responder, se puede escalar rápido a un agente, estoy a favor. Claro, siempre bajo la premisa de que el bot no alucine ni diga información falsa
Uso un chatbot porque no tengo personal de soporte que responda preguntas. Si no fuera por el bot, no habría nada
En cambio, monitoreo los logs del bot. Si falta alguna función en el producto o en el sitio web, la agrego para que los usuarios posteriores puedan resolverlo completamente en autoservicio
Los usuarios pueden cancelar su cuenta o recibir un reembolso en cualquier momento
Para ese tipo de preguntas, un modelo de lenguaje grande encaja casi a la perfección. Aunque me gustaría que mejoraran para detectar mejor las preguntas que el bot no puede responder directamente
Por supuesto, hay casos en los que un chatbot puede reemplazar a una persona o a una FAQ bien redactada. Pero esta autocomplacencia pasa por alto la razón principal por la que el soporte es horrible: porque fue diseñado así desde el principio
Si tomamos como ejemplo “solo se puede cancelar por teléfono”, registrarse o hacer upsell es un problema técnicamente más difícil, y aun así está hecho para ser mucho más fácil. El objetivo es agregar fricción a las acciones que se ven como costos o pérdidas a corto plazo. Las empresas saben que, si hay fricción, mucha gente se rinde o lo pospone
Esto es el paradigma del nudge y los patrones oscuros. Basta ver cómo en la mayoría de los banners de cookies la opción “rechazar todo” está escondida. El nudge permite que las empresas parezcan cumplir la ley y, al mismo tiempo, eviten el efecto total a costa del tiempo y la atención de los usuarios
Los chatbots no son más que otra capa añadida al laberinto del soporte
No me entusiasma en absoluto un futuro en el que todas las empresas tengan soporte por chatbot
Ya es bastante común y frustrante, pero al menos todavía, más o menos la mitad de las veces, uno sabe que no entiende la pregunta y hay una vía de escape hacia una persona
La era de “la computadora dice que no” ya llegó
Agrego que no quiero sonar únicamente negativo ni salirme del tema: el artículo en sí parece bastante bueno. Aplausos para el autor. La ingeniería es genial; simplemente detesto cómo se usa en la práctica
Los chatbots no son una solución mágica, pero pueden reducir mucho ruido innecesario. Lo que se necesita es algo que pueda responder preguntas básicas que hace un usuario promedio en un dominio específico
Mi trabajo anterior era en una empresa bastante grande y la instancia de Confluence era enorme. Perdíamos mucho tiempo buscando información allí. Si hubiera existido un chatbot entrenado con toda esa información, creo que habría sido bastante útil
Se me viene a la mente Amazon. Fui cliente durante mucho tiempo y hace poco recibí un periférico de computadora defectuoso
Le expliqué brevemente el problema al chatbot y de inmediato generó un nuevo pedido, me dijo que podía quedarme con el artículo recibido y que lo enviarían con entrega prioritaria sin costo adicional
Eso fue todo; llegó al día siguiente y funcionó bien
Claro, seguramente sabían que era un cliente antiguo y que ya había gastado bastante dinero, pero fue una experiencia casi tan indolora como se puede imaginar. Mucho mejor que avanzar haciendo clic en opciones a través de varias páginas web
“Su señoría, toda mi argumentación era basura y cité artículos legales inexistentes, pero fue porque usé ChatGPT” — fue un abogado real, y ni siquiera le quitaron la licencia para ejercer
La expresión “ya está cambiando la web que conocíamos y amábamos” es hilar fino y claramente salirse del tema, pero no amo la web actual
La web está cada vez más controlada por unas pocas empresas. Ellas deciden qué contenido se muestra (Meta, Google) y qué correos van al filtro de spam (MS, Google)
La web actual está muy lejos de ser algo digno de amor. Tengo que pelear constantemente para llegar incluso a las personas que eligieron seguirme
Al final, la mayor parte de mi comunicación ocurre en el mundo real o en chats privados. Y, de paso, también quiero decir lo horribles e inestables que son los messenger para negocios
Algo tiene que pasar con la web de hoy. No sé qué ni cómo, pero sin duda recibiría con gusto un cambio
Aun así, también deberías ofrecer todas las demás formas por las que la gente pueda seguirte, pero si promocionas el feed RSS, la gente podría empezar a usarlo
Si quieres probar algo más técnico, puedes configurar un puente ActivityPub para que también puedan seguirte desde redes sociales. Si usas Wordpress, está https://wordpress.org/plugins/activitypub/
Como parece que la mayoría de los comentarios principales son negativos hacia los chatbots, diré esto: en mi trabajo sí había un chatbot realmente bueno.
Para mí era mucho mejor que buscar en Confluence, y también podía responder preguntas sobre datos dinámicos, como cuántos días de vacaciones me quedaban o qué tanto iba adelantado o atrasado con mis horas de trabajo.
Según recuerdo, por detrás usaba la tecnología de forma inteligente, así que entendía la mayoría de las cosas aunque le preguntaras en lenguaje natural.
La búsqueda de Confluence es un chiste total, y uno malo.
Los clientes usan chatbots porque la UI del sitio web es confusa. Quieren obtener información, pero no encuentran cómo.
Antes buscaban en Google “nombre del servicio + teléfono” o “nombre del servicio + cancelar suscripción”.
Nueve de cada diez veces, el sitio web no quiere darte fácilmente el número de teléfono ni facilitar la cancelación de la suscripción. Si desde el principio no quieres que el cliente haga una acción que tienes escondida, ¿para qué sirve entonces el chatbot?
Trabajé durante el auge de los chatbots, y tuve que decirles a varios clientes que, si no tenían la voluntad de ayudar realmente al cliente, no había mucho que pudiéramos hacer.
Al menos en empresas que tratan con personas, el verdadero objetivo de los chatbots es desplazar la UI web y de apps móviles como primer punto de contacto.
El usuario debería poder hablar con la empresa usando una sola identidad, por SMS o un chat similar, o mediante una llamada telefónica.
La web y las apps móviles no son más que utilidades secundarias o terciarias que complementan el método principal de comunicación.
La razón por la que antes las empresas no podían hacer esto era que la precisión en la comprensión del lenguaje no era suficiente. Los modelos de lenguaje grandes resolvieron ese límite.
Que el bot reduzca un poco las interacciones con agentes mediante reglas prácticas basadas en la experiencia es un extra. Gracias a mejores modelos de lenguaje grandes, la tasa de desvío de contactos también va aumentando poco a poco.
El molesto widget de chatbot pegado abajo a la derecha es una solución temporal hasta que se ofrezca un único número de teléfono y la comunicación por ese medio sea fluida.
Por último, el título es engañoso. No se trata de crear un chatbot open source, sino de crear un chatbot usando solo bibliotecas open source en lugar de herramientas cerradas/comerciales, por el bien de la comunidad y de un avance más rápido de la IA.
Dijeron: “Levantamos nuestro propio servidor virtual dentro de la cuenta existente de Google Cloud Platform (GCP) de Mozilla. Con eso, en la práctica decidimos encargarnos nosotros mismos de MLOps. Pero pudimos avanzar con la certeza de que el sistema era privado y estaba completamente bajo nuestro control”. ¿Cómo es que levantar un servidor dentro de la infraestructura de Google es privado y está completamente bajo el control de Mozilla?
Explicar hasta cómo hacer self-hosting en bare metal queda fuera del alcance de un artículo sobre construir un chatbot, y fingir que un VPS de Google Cloud no es seguro es un poco forzado.
ISO 27001 es el estándar internacional para sistemas de gestión de seguridad de la información, y el cumplimiento de GCP demuestra su compromiso con la seguridad de la información.
ISO 27017 está especializada en seguridad en la nube y se enfoca en controles específicos para proveedores de servicios cloud.
ISO 27018 es un estándar relacionado con la protección de información de identificación personal en nubes públicas.
Los informes SOC 2 pueden brindar confianza sobre controles relacionados con seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad.
Si manejas información médica, necesitas cumplir con HIPAA; si manejas datos de Europa o de ciudadanos europeos, el cumplimiento de GDPR es importante.
Para clientes del gobierno de Estados Unidos, el cumplimiento de FedRAMP puede ser obligatorio, y si procesas información de tarjetas de crédito, el cumplimiento de PCI DSS es importante.
Hay que verificar que los servicios que se usarán dentro de GCP estén incluidos en el alcance de las certificaciones necesarias para la industria o el caso de uso correspondiente. Estas certificaciones normalmente se pueden consultar en el sitio web de Google Cloud, y si se necesita documentación oficial, también se puede obtener a través del equipo de ventas o soporte de Google.
Si te interesa cómo se construye realmente un modelo de chat con base de datos vectorial de este tipo, en un livestream de la semana pasada mostré el proceso de hacerlo casi desde cero en un entorno Colab y usar Llama 2 para la inferencia: https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
El gran desafío de esta configuración es realizar búsquedas de similitud semántica a gran escala. Pinecone tiene documentación bastante buena sobre estructuras de datos para escalar bases de datos vectoriales grandes.
Estaba esperando que Mozilla se sumara a esta corriente y desarrollara su propio modelo de lenguaje grande. Si pensamos en la misión de la organización de “mantener internet abierto y accesible para todos”, tiene muchísimo sentido. Aunque no sé si tienen los recursos o la voluntad para hacerlo.
Dijeron: “Hay una razón por la que las operaciones de machine learning, es decir MLOps, son un campo en crecimiento. Implementar y administrar este tipo de apps es difícil. Requiere conocimientos y habilidades específicos que muchos desarrolladores y responsables de operaciones todavía no tienen”. ¿Qué es lo que lo hace tan difícil o diferente?
Yo lo entendía como ejecutar una API web que carga un modelo, que es un activo compilado. En ese sentido, no parece tan distinto.