TypeChat: plataforma de IA basada en chat

 (microsoft.github.io)
3 puntos por GN⁺ 2023-07-21 | 2 comentarios | Compartir por WhatsApp
  • La mayor dificultad al agregar entrada en lenguaje natural a apps existentes es convertir la intención del usuario en una estructura en la que el software pueda confiar, y TypeChat es una biblioteca que intenta resolver ese punto con tipos de TypeScript
  • Como las respuestas de texto libre de los LLM son inestables para parsear, TypeChat guía la respuesta hacia JSON y le agrega validación de esquema para convertirla en datos que la app pueda procesar
  • Los tipos de TypeScript pueden expresar con precisión estructuras JSON y, como es un formato que los LLM han visto mucho durante su entrenamiento, son útiles como esquema de respuesta
  • Si la respuesta no coincide con el tipo, se pueden volver a enviar los errores del compilador de TypeScript como feedback para corregirla, aumentando la seguridad de tipos antes del posprocesamiento o la confirmación del usuario
  • TypeChat se puede instalar con npm install typechat y está publicado como open source bajo licencia MIT, con integraciones para la API de OpenAI y el servicio Azure OpenAI

Convertir solicitudes en lenguaje natural en datos que una app pueda procesar

  • Los modelos de lenguaje grandes más recientes se pueden conectar fácilmente a asistentes de chat, pero integrar de forma confiable el lenguaje natural en interfaces de apps existentes es un desafío aparte
  • TypeChat se enfoca en convertir las solicitudes de usuarios en una forma que la app pueda procesar, y en permitir acciones en las que desarrolladores y usuarios puedan confiar
  • La biblioteca publicada usa las definiciones de tipos del codebase para obtener respuestas de IA estructuradas, con el objetivo de lograr seguridad de tipos
  • La instalación se puede hacer con el siguiente comando
npm install typechat

Usar JSON y tipos en lugar de parseo de lenguaje natural

  • Los LLM están orientados de base a conversaciones en lenguaje natural, como el inglés, por lo que aunque se incluyan en el prompt reglas como “responde con una lista con viñetas”, para el software común es difícil parsearlas de manera confiable
  • Si se les pide responder en JSON, por lo general pueden generar respuestas en una forma más fácil de manejar para una app
    • En el ejemplo, una solicitud de 1 “blueberry muffin” y 1 “grande latte” se convierte en JSON con un arreglo items
  • Los ejemplos simples ayudan a guiar la estructura, pero no definen suficientemente qué debe devolver la IA ni ofrecen criterios de validación

Usar tipos de TypeScript como esquema de respuesta

  • TypeChat incluye tipos de TypeScript en el prompt para guiar la estructura JSON que debe devolver el LLM
  • En el esquema de ejemplo, el tipo Response incluye items: Item[], y Item tiene los campos name, quantity, y los campos opcionales size y notes
  • TypeScript es adecuado para describir JSON con precisión y, como los LLM han estado expuestos a muchas definiciones de tipos, resulta útil para guiar el formato de respuesta
  • Si la respuesta no coincide con el tipo, el compilador de TypeScript la valida contra las definiciones de tipos, que son código TypeScript válido
  • El feedback de errores del compilador se usa para inducir correcciones en la respuesta, haciendo más robusto el flujo para obtener una respuesta que coincida con los tipos

Forma de uso y ejemplos de TypeChat

  • TypeChat puede usarse con un enfoque de esquema de datos que convierte la intención del usuario en una respuesta estructurada
  • El código de ejemplo define una interfaz SentimentResponse que determina si el sentimiento de una frase ingresada por el usuario es negative, neutral o positive
  • Con createLanguageModel(process.env) se crea un modelo de lenguaje basado en variables de entorno; luego se lee el archivo de esquema y se crea un traductor con createJsonTranslator<SentimentResponse>
  • Si translator.translate(request) tiene éxito, se imprime response.data.sentiment; si falla, se imprime el mensaje de error
  • Además del esquema de datos, también se puede usar un esquema de API para construir programas básicos
  • La forma de uso se puede consultar en docs y examples

Open source y neutralidad de modelo

  • TypeChat es open source bajo licencia MIT y está publicado en GitHub
  • Por conveniencia, ofrece integraciones básicas con la API de OpenAI y el servicio Azure OpenAI
  • Su objetivo de diseño es la neutralidad de modelo, apuntando a un enfoque que pueda usarse con APIs de estilo chat completion
  • Actualmente, TypeChat funciona mejor con modelos entrenados tanto en prosa como en código
  • El paquete está disponible en npm, por lo que se puede probar de inmediato

Lecturas relacionadas

2 comentarios

 
sungwoo 2023-07-26

Jaja, vi la noticia y quise publicarla, pero no puedo seguirle el ritmo a la IA.
 
GN⁺ 2023-07-21
Opiniones de Hacker News

  • No tengo muy claro cuál es el valor agregado aquí.
    El mensaje central que se envía al LLM está aquí: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    Al final parece una forma de hacer que devuelva datos estructurados con un prompt fijo, con un poco de automatización y dependencia de proveedor encima. La mayoría de estas bibliotecas para LLM se parecen más a APIs rudimentarias que envuelven APIs de más bajo nivel; es fácil hacer scripts que hagan lo mismo y son más flexibles a medida que cambian el modelo y las necesidades del usuario.
    Por ejemplo, si quieres cambiar el prompt o usar clases de Python, hay una gran diferencia de trabajo entre estas bibliotecas y un enfoque que eleva al usuario las llamadas a la API y las plantillas de texto (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...).

    • El valor está en esto: 1) ejecuta el verificador de tipos de TypeScript sobre el resultado devuelto por el LLM, 2) si hay errores de tipo, los reúne y crea un “prompt de corrección” para inducir una salida con más probabilidades de pasar la verificación de tipos, 3) maneja limpiamente los casos en que la heurística del punto 2 falla.
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      Por mi experiencia experimentando con la misma idea, la heurística del punto 2 funciona sorprendentemente bien con tipos relativamente simples, es decir, registros y arreglos que no están profundamente anidados, y un uso limitado de variables de tipo. Solo con pedirle al LLM que devuelva valores de tipos relativamente simples se pueden crear aplicaciones útiles, y esta biblioteca tiene valor porque reduce la necesidad de implementar directamente ese patrón de solicitud y ofrece una integración estándar con bases de código en TypeScript.
    • Casi todas las bibliotecas para LLM que se ven hoy son así. Al final todo se reduce a pedirle al LLM que haga algo de una forma específica, y he visto que con condiciones complejas sigue menos las instrucciones y vuelve a su comportamiento predeterminado.
      Aun así, parece que usar bibliotecas es la dirección correcta, así que sigo observando qué enfoque madurará lo suficiente.
    • No entiendo dónde está la dependencia de proveedor. Esto es una biblioteca de código abierto, y el archivo enlazado incluye configuración para dos proveedores: ChatGPT y Bard.
    • El valor está en convertir datos no estructurados en datos estructurados y garantizar que cumplan las restricciones del esquema.
      Por ejemplo, si tienes 1000 respuestas de encuesta en texto libre sobre un producto, puedes crear un esquema y ejecutar TypeChat sobre cada una para obtener un conjunto de datos a partir de ese texto libre. Es tremendamente útil.
    • Cuanto mejores son las abstracciones, más fácil se vuelve programar cosas útiles.

  • Hay una parte que no entiendo.
    No sé por qué pasar por un procedimiento complejo en el que esperas una respuesta válida, agregas un validador en la etapa final para detectar respuestas incorrectas y le ruegas al modelo que por favor responda con la sintaxis deseada.
    Si solo muestreas tokens que encajan con el formato solicitado, puedes garantizar una sintaxis JSON válida. En lugar de elegir de forma codiciosa el token con mayor puntaje en cada paso, eliges el de mayor puntaje entre los tokens que cumplen el formato solicitado.
    Guidance de Microsoft ya hace esto: https://github.com/microsoft/guidance
    Pero OpenAI parece no exponer las puntuaciones completas de todos los tokens, sino solo los tokens con mayor puntaje. Si ejecutas el modelo localmente, usar Guidance es sencillo, puedes garantizar que el JSON sea correcto cada vez y además la generación es más rápida, así que resulta raro.

    • Es parecido a la historia de los M&M marrones[0]. Si el modelo devuelve datos semánticamente correctos, puedes esperar que al menos la sintaxis esté bien. Si no puede hacer eso, de todos modos tienes que descartar la respuesta.
      Además, con ese enfoque parece difícil cubrir toda la complejidad de los tipos de TypeScript.
      [0] https://www.snopes.com/fact-check/brown-out/
    • Con ese método puedes garantizar JSON sintácticamente correcto, pero que sea semánticamente correcto es otro asunto.
      Si el modelo realmente quiere poner otro token y lo obligas a poner {, quizá baje la calidad del texto que se genere después. No estoy seguro; solo lo estoy pensando.
    • Me parece muy prometedor el enfoque de muestrear solo tokens válidos.
      He ajustado finamente un LLM open source para parseo de JSON y, aun sin muestreo guiado de tokens, según el caso de uso un modelo de 70B parámetros puede ser excesivo. Vi resultados bastante buenos incluso con modelos mucho más pequeños, y combinar el fine-tuning de modelos pequeños con muestreo guiado de tokens podría ser interesante.
      Dicho eso, para aplicaciones muy generales el fine-tuning quizá no sea perfecto. Si llega una entrada no prevista en el dataset de entrenamiento, se complica.
    • Los LLM pueden manejar escenarios más complejos. Por ejemplo, en una máquina expendedora, si en lugar de pasar por todo el flujo de pedido simplemente dices lo que quieres, puede inferir expresiones como “unas barras de chocolate” y emparejarlas con el inventario.
      Claro que en la web no tiene sentido. Es mucho más fácil hacer clic con el mouse en algunos productos.
    • Como explicó hace poco Llama.cpp, agregó muestreo basado en gramática para restringir la selección de tokens de modo que sigan un formato fijo.
      https://github.com/ggerganov/llama.cpp/pull/1773

  • Siento que cada vez que se me ocurre algo, Anders Hejlsberg termina creándolo
    Las solicitudes y respuestas estructuradas son, sin duda, la próxima evolución de los LLM. La gente ya se está cansando de los chatbots, y sería increíble poder conectar cualquier backend sin preocuparse por parsear texto ni por los prompts

    • Quiero conectar a un LLM que se ejecute localmente algunas interfaces accionables que yo le proporcione. Cosas como “ver la hora”, “revisar el calendario”, “enviar un mensaje al usuario”
      TypeChat parece ir en la dirección correcta. Puedo imaginar una capa adicional del estilo “ajusta esta entrada JSON a una de las acciones posibles, si se puede”
      Veo un futuro híbrido prolijo en el que un bot, es decir, un LLM y cosas por el estilo, vaya uniendo capas de código reales. A veces como parte de la recolección y el etiquetado, otras veces como parte de la respuesta a una entrada
      En general es un área muy interesante, pero todo se mueve tan rápido que todavía no me he metido a fondo. Siento que conviene esperar a que el polvo se asiente un poco, porque hay mucha gente inteligente trabajando en esto. Aun así, creo que la interfaz para el hogar con la que soñaba ya está en una etapa en la que se puede construir
    • Justo ayer implementé algo parecido, pero me enfoqué más en funciones que en objetos
    • Podría ser enorme si se usa como mapeador dinámico en la capa de backend
      Por ejemplo, intenta seguirle el ritmo a payloads de API que cambian con frecuencia alrededor de un consumidor Java. En banca, con payloads JSON enormes y un entorno de backend en Java, terminé creando una capa separada en NodeJS para conservar la cordura
      El mapeo es un campo donde los LLM pueden brillar
    • Vale la pena echarle un vistazo: https://news.ycombinator.com/item?id=36750083

  • Una lectura polémica sería que estamos entrando poco a poco en la fase de instrumentalización de la IA. La gente se da cuenta de que aquí no hay mucha creación de valor real, pero como se ha invertido demasiado en IA, se sigue metiendo dinero. También es un buen tema para publicar papers académicos, y LangChain es casi un chiste, pero recibió 10 millones de dólares en ronda semilla
    DeFi/crypto pasó por esta etapa hace 2 años. Después de unos años en un limbo raro, la gente irá dándose cuenta lentamente de que la IA no es un producto sino una función, que tiene un alcance limitado y que no va a salvar al mundo. No podremos tener autos autónomos por todos los casos borde, ni cirugía porque puede matar gente
    He dicho una y otra vez que incluso las herramientas de IA más útiles, como Copilot, en el mejor de los casos solo son marginalmente útiles. En el mejor escenario, te ahorran algunos clics en Google, y los agentes no son para nada “inteligentes”. Hace unos años vivimos una burbuja similar con los chatbots[1], y hoy a nadie le importan. El “metaverso” duró mucho menos, pero operó la misma psicología de masas. Pasa de ser “la próxima gran cosa” a no serlo
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • Estoy totalmente en desacuerdo con que la IA sea solo una burbuja de alcance limitado
      Estás eligiendo justo los casos de uso más difíciles para la IA, como autos autónomos y cirugía. El trabajo de la gran mayoría de la gente no implica vida o muerte, así que es muy apto para la automatización. Incluso si el factor humano permanece en profesiones donde hay vidas en juego, es muy probable que se vea reforzado por agentes de IA. Por ejemplo, aunque la cirugía la haga un humano, podría volverse obligatorio que médicos o enfermeros diagnostiquen junto con una IA
      ¿De verdad estás comparando la burbuja de chatbots de hace unos años con lo de ahora? ChatGPT llegó a 100 millones de usuarios en cuestión de meses y muchísima gente lo probó. La burbuja de chatbots de hace unos años ni siquiera tuvo demasiada presencia
      Si Copilot y otros te parecen solo marginalmente útiles, es porque estás viendo la peor versión que van a tener. ChatGPT me cambió la vida, y todavía ni siquiera ejecuta código. Code Interpreter sí lo hace, pero aún no lo he probado
      Para alrededor de 2030, probablemente los humanos ya no tecleen código, sino que le den prompts a las máquinas y dirijan agentes de IA. Para entonces, la mayoría de los trabajos probablemente también puedan automatizarse
      La IA no es una simple moda: va a transformar todas las industrias, y mucho más rápido de lo que la gente cree. El cinismo que minimiza las implicancias de la IA comparándola con el metaverso es absurdo y falto de imaginación. Todavía hay mucho por hacer, especialmente en agentes de IA, pero probablemente lleguemos ahí mucho antes de lo que la gente piensa, y el impacto será enorme
    • Cada vez que uso ChatGPT siento que estoy viendo una tecnología distinta de la que ven los demás. Dicen que responde cualquier pregunta y te enseña cualquier cosa, pero en la práctica se siente como un servicio de granja de contenido. Copilot es parecido: por lo general es más fácil escribir el código uno mismo que buscar el ejemplo menos malo entre varios malos y corregir los bugs
      Dicho eso, AlphaGo no tardó mucho en pasar de “alucinar” malas jugadas a convertirse en el mejor jugador del mundo. Si eso también es posible con los modelos de lenguaje, GPT-x podría barrer con toda la discusión actual
    • Estoy totalmente en desacuerdo con lo de que “no hay creación de valor real”. En mi caso de uso hay un contraejemplo clarísimo
      GPT-4 es increíblemente útil cuando una persona con experiencia realiza tareas periféricas donde sus habilidades en general aplican, pero le falta conocimiento del dominio
      Llevo 10 años programando y hace poco empecé a aprender machine learning por primera vez; uso GPT-4 todos los días y estoy muy satisfecho
      Claro que a veces las partes ásperas pueden molestar. Para mí están en un nivel manejable y no son una gran molestia. Ya me acostumbré a ignorarlas o rodearlas, y definitivamente hay una habilidad en usar este tipo de herramientas
      Creo que el valor que ofrecen seguirá creciendo. Todavía ni siquiera se han recogido todos los frutos de baja y mediana altura
    • La diferencia clave con DeFi/crypto es que, por más impresionante que fuera técnicamente, ahí la gente tenía que cambiar por completo lo que hacía para obtener el primer beneficio
      La IA moderna, en la práctica normalmente los LLM, se puede aplicar de inmediato y de forma amplia en casi todos los sectores de la economía. Por eso mucha gente ya está construyendo y lanzando funciones. Esta tecnología tiene un valor enorme. ¿Va a cambiar el mundo por completo? No, pero sí alcanza para crear nuevas categorías de productos y mejorar de manera fundamental una gran parte de las capacidades de los productos existentes
    • Me parece una interpretación bastante razonable. La IA tiene muchos usos y es realmente buena para algunas cosas, pero no es la solución universal que la gente espera

  • No entiendo por qué, entre los asistentes de voz de Apple, Google, Amazon y Microsoft, todavía ninguno integró un LLM en su servicio, ni por qué OpenAI no lanzó su propio asistente de voz.
    Además, si los sitios web expusieran una URL estándar para interacciones con IA, como RSS, y publicaran su interfaz con TypeChat, creo que se podría avanzar bastante en esa dirección.

    • Es muy probable que OpenAI cree su propio asistente. Viendo lo de Karpathy, “Building a kind of JARVIS @ OреոΑӏ”, parece eso, y Microsoft seguramente también estará trabajando en integrar o reinterpretar Cortana con el LLM de OpenAI.
      Pero la capacidad de realizar acciones en la práctica vale mucho más que un LLM basado en voz. Tomemos Alexa como ejemplo: se necesita un sistema que maneje el control del hogar inteligente de forma predecible y depurable. Si no, la gente se irrita.
      Claramente lo veo posible, pero sistemas como Alexa o Siri actuales, o Cortana, que se usa menos, llevan años acumulando reglas y software sobre modelos menos potentes, usando varios hooks y API. Para hacer que funcione, hay que mejorar manteniendo la calidad actual y, al mismo tiempo, reemplazar partes importantes del sistema, así que lleva tiempo.
      Además, estos asistentes en realidad no generan dinero y, en general, pierden plata. Solo tienen valor para grandes empresas que pueden ganar dinero de otras formas, como teléfonos o compras, o impulsar su negocio, así que hay pocos incentivos para que lo haga una startup.
      En el pasado trabajé tanto en Cortana como en Alexa, y también pensé mucho en crear una nueva versión desde cero basándome en los avances de los LLM. La tecnología en general era intuitiva y había ideas de nuevos casos de uso que ahora se volvieron posibles, pero no encontré un modelo de negocio que funcionara. Así que ahora estoy haciendo algo completamente distinto.
    • Cuando me enteré por primera vez de qué era ChatGPT, pensé: “Ah, así era como Siri debería haber sido desde el principio”.
    • Después de usar ChatGPT y Bing, hablar con Alexa resulta ridículo. Es realmente frustrante ver hardware de buen rendimiento frenado durante años por software pésimo.
    • Microsoft está haciendo eso para reemplazar Cortana en Windows 11.
    • Tengo muchas expectativas por algo que pueda usarse para controlar Home Assistant.
      Pero usar una API basada en la nube para eso me da demasiada inseguridad; quiero que corra en un servidor dentro de mi casa. Al mismo tiempo, el reconocimiento de voz y el tiempo de respuesta tienen que ser muy rápidos, sin que se sienta que estoy esperando.
      Vi varios intentos DIY de asistentes personales, pero siempre tenían bastante latencia, así que creo que si los usara seguido me molestarían rápidamente.

  • Hay una parte que dice que es fácil recibir una respuesta como { "name": "grande latte" }.
    Pero si el tipo es Item = { name: string; ... size?: string; }, no termino de ver cómo eso ayuda a evitar name: "grande latte".
    La respuesta de ejemplo incluye "size": 16 y dice que es “bastante excelente”, pero en realidad ni siquiera devuelve el tipo solicitado. Probablemente sea un typo en el ejemplo, y si es así, la idea en sí parece interesante.

    • Gracias por detectarlo. En una iteración anterior del post del blog usábamos otro esquema donde size estaba especificado por error como number. Cambiamos el esquema, pero no volvimos a ejecutar el prompt, y ahora debería estar corregido.
    • En general, me parece un ejemplo bastante débil. Es un problema que va más allá de un simple typo.
      Para empezar, probablemente no quieras un campo de cadena name. Nada impide recibir valores como { name: “the brown one”, size: “the espresso cup”, … }, y eso es tan malo como parsear la cadena original.
      Probablemente querrías un gran tipo unión de strings que represente los valores conocidos para cada campo. Así podrías hacer que el LLM intente ajustarse a uno de ellos.
      Pero también me pregunto por qué eso tendría que estar atado a la sintaxis de tipos. Algo como Zod, que puede construir esos tipos unión usando datos en runtime, parece más adecuado.
      También hacen falta restricciones como que la cantidad sea un entero positivo y no una fracción. Claro que puedes validar el valor JSON después, pero entonces el usuario ve dos tipos de errores: uno que el LLM expresa con un tono humano fluido, y otro extrañamente técnico como “el valor de cantidad es demasiado grande”.
      La sintaxis de tipos parece el lugar equivocado para expresar todo eso.
    • Parece simplemente un bug de documentación. Da la impresión de que, al final de redactar el anuncio, cambiaron de cantidad en onzas a tamaño estándar y se olvidaron de ajustar el valor de salida.
      Con solo el código proporcionado, el sistema no tiene forma de mapear “grande” a 16, y tampoco parece que 16 se use en otro lado.
    • En el párrafo siguiente tratan “qué pasa si se ignora el tipo”, así que quizá esa era la intención.

  • Parece un enfoque en el que ejecutas el LLM repetidamente hasta que emite algo que pasa la verificación de tipos, y luego vuelves a darle el prompt con el mensaje de error.
    Es una idea simpática y parece que puede funcionar, pero con modelos grandes y prompts de entrada largos el costo puede volverse alto. No parece una solución para todos los escenarios.

    • Al menos en OpenAI, ¿no convendría usar internamente la nueva funcionalidad de llamada a funciones?
    • No sé bien cómo funciona TypeChat, pero Guidance [1] también es un proyecto similar y, de hecho, puede integrarse al muestreo de tokens para forzar el formato.
      [1]: https://github.com/microsoft/guidance
    • Creo que la mayoría de los productos primero se preocuparán por el encaje producto-mercado y después intentarán reducir costos.
      También hay una suposición bastante razonable de que, como el mercado está pidiendo salidas estructuradas, los modelos mejorarán en esa dirección.

  • Esta semana publiqué algo muy parecido para Laravel PHP, aunque con un alcance más pequeño: https://github.com/adrenallen/ai-agents-laravel
    Creo que un ingeniero debería poder levantar fácilmente un nuevo “bot” con un LLM dado. Hay mucho trabajo tedioso en convertir funciones a un formato que ChatGPT pueda entender, procesar las respuestas y volver a parsearlas
    Con un sistema así, puedes enfocarte en escribir código PHP real y agregar algunos comentarios claros; entonces el bot puede usar ese código directamente como herramienta para cualquier tarea
    Además, este enfoque hace mucho más fácil compartir código. Si alguien escribe una función, puedes llevarla a un bot nuevo y usarla de inmediato. Lo bueno es que elimina la “capa que transforma para que el LLM use y entienda”, y acelera mucho la construcción
    Todavía no es perfecto, pero creo que, para aprovechar mejor el código de los demás, al final todo va a ir en esta dirección. Pensando en cómo usamos hoy los gestores de paquetes al programar, me gustaría que hubiera un gestor de paquetes para herramientas específicas de IA. Sería algo como instalar una librería de “obtener el clima”, agregarla a mi bot y que ahora ya pueda obtener el clima

    • Le di estrella porque estoy trabajando en un enfoque similar, pero de alcance un poco más amplio. Algunas ideas son realmente muy elegantes

  • Un momento, ¿esto hace validación en tiempo de ejecución de objetos contra definiciones de tipos de TypeScript? Si se pudiera publicar como librería o funcionalidad independiente, podría cambiar por completo las reglas del juego en bases de código TypeScript para validar payloads de respuestas de API, etc.

  • Me sorprende mucho que aquí no usen guidance [0]
    Podría sugerir completar campos obligatorios, lo que reduciría la necesidad de validación[1] y, al final, también podría ahorrar tiempo de GPU
    Seguro hay una razón, pero realmente me gustaría saberla
    Como comentario aparte, estaba construyendo justo algo así y siento que Microsoft llegó de repente y me quitó el almuerzo
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...