TypeChat : plateforme d’IA basée sur le chat

 (microsoft.github.io)
3 points par GN⁺ 2023-07-21 | 2 commentaires | Partager sur WhatsApp
  • Lorsqu’on ajoute une saisie en langage naturel à des applications existantes, la plus grande difficulté consiste à convertir l’intention utilisateur en une structure fiable pour le logiciel ; TypeChat est une bibliothèque qui cherche à résoudre ce point avec les types TypeScript
  • Les réponses textuelles libres des LLM étant instables à parser, TypeChat oriente les réponses vers du JSON et y ajoute une validation de schéma afin d’en faire des données exploitables par l’application
  • Les types TypeScript permettent de décrire précisément des structures JSON et constituent un bon schéma de réponse, car il s’agit d’un format que les LLM ont beaucoup rencontré durant leur entraînement
  • Si une réponse ne correspond pas au type, il est possible de renvoyer les erreurs du compilateur TypeScript comme feedback pour la corriger, ce qui améliore la sécurité de type avant le post-traitement ou la confirmation par l’utilisateur
  • TypeChat peut être installé avec npm install typechat ; il est publié en open source sous licence MIT et fournit aussi des intégrations avec l’API OpenAI et le service Azure OpenAI

Transformer des requêtes en langage naturel en données traitables par une application

  • Les grands modèles de langage récents s’intègrent facilement à des assistants de chat, mais intégrer de manière fiable le langage naturel dans l’interface d’applications existantes est un défi à part entière
  • TypeChat se concentre sur la transformation des requêtes utilisateur en une forme que l’application peut traiter, afin d’exécuter des actions auxquelles développeurs et utilisateurs peuvent faire confiance
  • La bibliothèque publiée utilise les définitions de types de la base de code pour obtenir des réponses IA structurées, avec pour objectif la sécurité de type
  • L’installation se fait avec la commande suivante
npm install typechat

Utiliser JSON et les types plutôt que le parsing du langage naturel

  • Les LLM sont fondamentalement adaptés aux conversations en langage naturel, comme l’anglais ; même si l’on ajoute au prompt des règles du type « réponds sous forme de liste à puces », il reste difficile pour un logiciel classique de parser cela de manière fiable
  • Demander une réponse en JSON permet généralement d’obtenir une réponse dans un format plus facile à manipuler par une application
    • Dans l’exemple, une demande pour 1 « blueberry muffin » et 1 « grande latte » est convertie en JSON contenant un tableau items
  • Les exemples simples aident à guider la structure, mais ne définissent pas suffisamment ce que l’IA doit retourner et ne fournissent pas non plus de critères de validation

Utiliser les types TypeScript comme schéma de réponse

  • TypeChat inclut les types TypeScript dans le prompt afin de guider la structure JSON que le LLM doit retourner
  • Dans le schéma d’exemple, le type Response contient items: Item[], et Item possède les champs name, quantity, ainsi que les champs optionnels size et notes
  • TypeScript convient bien à la description précise du JSON, et comme les LLM ont vu de nombreuses définitions de types, il est utile pour guider le format de réponse
  • Si la réponse ne correspond pas au type, elle est validée par le compilateur TypeScript à partir des définitions de types, qui sont du code TypeScript valide
  • Le feedback des erreurs du compilateur est utilisé pour guider la correction de la réponse, ce qui rend plus robuste le flux permettant d’obtenir une réponse conforme au type

Mode d’utilisation de TypeChat et exemples

  • TypeChat peut être utilisé selon une approche de schéma de données qui transforme l’intention utilisateur en réponse structurée
  • L’exemple de code définit une interface SentimentResponse qui classe le sentiment d’une phrase saisie par l’utilisateur parmi negative, neutral et positive
  • Il crée un modèle de langage basé sur les variables d’environnement avec createLanguageModel(process.env), lit le fichier de schéma, puis crée un traducteur avec createJsonTranslator<SentimentResponse>
  • Si translator.translate(request) réussit, il affiche response.data.sentiment ; en cas d’échec, il affiche le message d’erreur
  • Outre les schémas de données, il est aussi possible d’utiliser des schémas d’API pour construire des programmes de base
  • Les modes d’utilisation sont disponibles dans la documentation et les exemples

Open source et neutralité vis-à-vis des modèles

  • TypeChat est open source sous licence MIT et publié sur GitHub
  • Par commodité, il fournit des intégrations de base avec l’API OpenAI et le service Azure OpenAI
  • Son objectif de conception est la neutralité vis-à-vis des modèles, avec une approche destinée à fonctionner avec toute API de type chat completion
  • À l’heure actuelle, TypeChat fonctionne le mieux avec des modèles entraînés à la fois sur du texte en prose et du code
  • Le package est disponible sur npm, ce qui permet de l’essayer immédiatement

À lire aussi

2 commentaires

 
sungwoo 2023-07-26

Haha, j’avais vu la news et j’allais la poster, mais impossible de rivaliser avec l’IA.
 
GN⁺ 2023-07-21
Commentaires sur Hacker News

  • Je ne vois pas très bien quelle est la valeur ajoutée ici
    Le message principal envoyé au LLM est ici : https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    Au final, ça ressemble à un prompt fixe pour renvoyer des données structurées, avec un peu d’automatisation et une dépendance au fournisseur par-dessus. La plupart de ces bibliothèques LLM se rapprochent surtout d’API médiocres qui encapsulent des API sous-jacentes, alors qu’un script faisant la même chose est facile à écrire et reste plus flexible à mesure que le modèle et les besoins des utilisateurs évoluent
    Par exemple, si on veut modifier le prompt ou utiliser des classes Python, l’écart de charge de travail est important entre ce genre de bibliothèque et une approche qui expose les appels API et les modèles de texte à l’utilisateur (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...)

    • La valeur est ici : 1) exécuter le vérificateur de types TypeScript sur le résultat renvoyé par le LLM, 2) s’il y a des erreurs de type, les regrouper pour en faire un « prompt de correction » afin d’orienter la sortie vers quelque chose qui a plus de chances de passer la vérification, 3) gérer proprement les cas où l’heuristique de l’étape 2 échoue
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      Pour avoir expérimenté une idée similaire, l’heuristique du point 2 fonctionne étonnamment bien sur des types relativement simples, c’est-à-dire des enregistrements et tableaux peu imbriqués, avec un usage limité des variables de type. Rien qu’en demandant au LLM, via le prompt, de renvoyer une valeur d’un type relativement simple, on peut créer des applications utiles, et cette bibliothèque a de la valeur en ce qu’elle évite d’avoir à implémenter soi-même ce schéma de requête tout en fournissant une intégration standard avec une base de code TypeScript
    • Presque toutes les bibliothèques LLM qu’on voit ces jours-ci fonctionnent ainsi. Au bout du compte, cela revient à demander au LLM d’accomplir une tâche d’une certaine façon, et j’ai vu qu’en présence de conditions complexes, il suit moins bien les instructions et revient à son comportement par défaut
      Cela dit, je pense quand même que passer par des bibliothèques est la bonne direction, donc je continue d’observer quelles approches deviendront suffisamment mûres
    • Je ne vois pas où se situerait la dépendance au fournisseur. C’est une bibliothèque open source, et le fichier lié contient déjà des configurations pour ChatGPT et Bard
    • La valeur réside dans le fait de transformer des données non structurées en données structurées, tout en garantissant qu’elles respectent les contraintes du schéma
      Par exemple, si vous avez 1 000 réponses libres à une enquête sur un produit, vous pouvez définir un schéma, exécuter TypeChat sur chacune d’elles et obtenir un jeu de données à partir de ce texte libre. C’est extrêmement utile
    • Plus les abstractions s’améliorent, plus il devient facile de coder des choses utiles

  • Il y a un point que je ne comprends pas
    Je ne vois pas pourquoi on passe par toute cette procédure compliquée qui consiste à espérer une réponse valide, ajouter un validateur à la dernière étape pour détecter les réponses incorrectes, puis supplier le modèle de répondre dans la syntaxe voulue
    On peut garantir une syntaxe JSON valide en n’échantillonnant que des tokens correspondant au format demandé. Au lieu de choisir de façon gloutonne le token ayant le meilleur score à chaque fois, il suffit de choisir, parmi les tokens conformes au format demandé, celui qui a le meilleur score
    Guidance de Microsoft fait déjà cela : https://github.com/microsoft/guidance
    Mais OpenAI semble ne pas exposer les scores complets de tous les tokens, seulement ceux des meilleurs. En local, il est simple d’utiliser Guidance, on peut garantir que le JSON sera correct à chaque fois, et la génération est aussi plus rapide, ce qui est étrange

    • C’est un peu comme l’histoire des M&M bruns[0]. Si le modèle renvoie des données correctes sur le plan sémantique, on peut au moins s’attendre à ce qu’il respecte la syntaxe. S’il n’en est pas capable, il faut de toute façon jeter la réponse
      Et puis, avec cette méthode, il me semble difficile d’exprimer toute la complexité des types TypeScript
      [0] https://www.snopes.com/fact-check/brown-out/
    • Cette approche peut garantir un JSON syntaxiquement valide, mais la question de savoir s’il est sémantiquement correct est tout autre
      Si le modèle veut vraiment insérer un autre token mais qu’on le force à mettre {, la qualité du texte généré ensuite pourrait aussi se dégrader. Je n’en suis pas sûr, c’est juste une réflexion
    • Je pense que l’échantillonnage limité aux tokens valides est très prometteur
      J’ai déjà affiné un LLM open source pour faire du parsing JSON, et selon l’usage, 70B paramètres peut être excessif même sans échantillonnage guidé. J’ai obtenu de très bons résultats avec des modèles bien plus petits, et combiner le fine-tuning d’un petit modèle avec un échantillonnage guidé des tokens pourrait être intéressant
      Cela dit, pour des applications très généralistes, le fine-tuning n’est peut-être pas idéal. On risque d’être pris au dépourvu si une entrée imprévue par le jeu de données d’entraînement apparaît
    • Les LLM peuvent gérer des scénarios plus complexes. Par exemple, dans un distributeur automatique, on pourrait simplement énoncer une commande sans passer par toute la procédure de commande, et le système pourrait déduire à partir du stock ce que signifie une formule comme « quelques barres chocolatées »
      Bien sûr, sur le web, cela n’a aucun sens. Il est bien plus simple de cliquer sur quelques produits avec la souris
    • Comme Llama.cpp l’a récemment expliqué, ils ont ajouté un échantillonnage basé sur une grammaire qui contraint le choix des tokens afin de respecter un format fixe
      https://github.com/ggerganov/llama.cpp/pull/1773

  • J’ai l’impression qu’à chaque fois que je pense à quelque chose, Anders Hejlsberg finit par le créer
    Les requêtes et réponses structurées sont à 100 % la prochaine évolution des LLM. Les gens en ont déjà assez des chatbots, et si on peut brancher n’importe quel backend sans se soucier du parsing de texte ni des prompts, ce sera énorme

    • J’aimerais connecter un interface exploitable à un LLM qui tourne en local. Des choses comme « vérifier l’heure », « consulter le calendrier », « envoyer un message à l’utilisateur »
      TypeChat semble aller dans la bonne direction. On peut imaginer une couche supplémentaire du genre : « fais correspondre cette entrée JSON à l’une des actions possibles, si tu peux »
      Je vois un futur hybride assez propre où des bots, c’est-à-dire des LLM et autres, relient entre elles de vraies couches de code. Parfois ils feraient partie de la collecte et du tagging, parfois d’un composant qui répond à l’entrée
      Globalement, c’est un domaine très intéressant, mais tout évolue trop vite pour que je m’y sois encore plongé en profondeur. Beaucoup de gens brillants travaillent dessus, donc j’ai l’impression qu’il faut attendre que la poussière retombe un peu. Cela dit, on dirait qu’on a déjà atteint le stade où je pourrais construire l’interface domestique dont je rêvais
    • J’ai justement implémenté quelque chose de similaire hier, mais en me concentrant davantage sur les fonctions que sur les objets
    • Ça pourrait être énorme comme mappeur dynamique pour la couche backend
      Par exemple, regardez des payloads d’API qui changent souvent autour de consommateurs Java. Dans la banque, avec d’énormes payloads JSON, j’ai fini par créer une couche NodeJS à part juste pour garder ma santé mentale dans un environnement backend Java
      Le mapping est un domaine où les LLM peuvent vraiment briller
    • À voir : https://news.ycombinator.com/item?id=36750083

  • Mon interprétation à chaud, c’est qu’on entre progressivement dans la phase d’outillage de l’IA. Les gens se rendent compte qu’il n’y a pas tant de création de valeur réelle que ça, mais comme on a trop investi dans l’IA, l’argent continue d’affluer. C’est aussi un excellent sujet pour publier des articles académiques, et LangChain, qui est presque une blague, a quand même levé 10 millions de dollars en seed
    DeFi/crypto est passé par cette phase il y a deux ans. Il y aura quelques années de limbes bizarres, puis les gens réaliseront lentement que l’IA est une fonctionnalité, pas un produit, que son champ d’application est limité et qu’elle ne sauvera pas le monde. On n’aura pas de voitures autonomes à cause de tous les edge cases, et pas de chirurgie non plus parce que ça peut tuer des gens
    Même les outils d’IA les plus utiles, comme Copilot, ne sont au mieux qu’utilement périphériques. Au mieux, ça vous évite quelques clics sur Google, et les agents ne sont en rien « intelligents ». On a déjà connu une bulle similaire avec les chatbots il y a quelques années[1], et aujourd’hui plus personne n’y pense. Le « métavers » a été bien plus court, mais la même psychologie de foule était à l’œuvre. C’était « le prochain grand truc », puis ça ne l’a pas été
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • Je suis fortement en désaccord avec l’idée que l’IA ne serait qu’une bulle à portée limitée
      Vous ne citez que les cas d’usage les plus difficiles pour l’IA, comme la voiture autonome et la chirurgie. Le travail de la grande majorité des gens n’engage pas la vie ou la mort, donc il se prête très bien à l’automatisation. Même si un élément humain subsiste dans les métiers où la vie est en jeu, ils seront probablement renforcés par des agents IA. Par exemple, même si la chirurgie reste pratiquée par des humains, il pourrait devenir obligatoire pour les médecins ou les infirmiers d’établir un diagnostic avec l’aide de l’IA
      Vous comparez vraiment sérieusement la bulle des chatbots d’il y a quelques années à la situation actuelle ? ChatGPT a atteint 100 millions d’utilisateurs en quelques mois, et énormément de gens l’ont essayé. La bulle des chatbots d’il y a quelques années avait à peine une présence
      Dire que Copilot et consorts ne sont qu’utilement périphériques, c’est regarder leur pire version actuelle. ChatGPT a changé ma vie, et il n’exécute même pas encore de code. Code Interpreter le fait, mais je ne l’ai pas encore testé
      Vers 2030, les humains ne taperont probablement plus de code ; ils donneront des prompts aux machines et piloteront des agents IA. D’ici là, la plupart des métiers auront probablement aussi été automatisés
      L’IA n’est pas une simple mode : elle va transformer toutes les industries, et bien plus vite que les gens ne le pensent. Le cynisme qui consiste à rabaisser les implications de l’IA en la comparant au métavers est absurde et manque d’imagination. Il reste certes beaucoup à faire, surtout du côté des agents IA, mais on y arrivera probablement bien plus vite que les gens ne l’imaginent, et l’impact sera énorme
    • Chaque fois que j’utilise ChatGPT, j’ai l’impression de voir une technologie différente de celle que voient les autres. On dit qu’il répond à toutes les questions et peut tout enseigner, mais en pratique j’ai l’impression d’utiliser un service de ferme à contenu. Copilot me fait un peu le même effet : la plupart du temps, il est plus simple d’écrire le code soi-même que de chercher le moins mauvais exemple parmi de mauvais exemples et corriger les bugs
      Cela dit, AlphaGo n’a pas mis longtemps à passer d’un état où il « hallucinait » de mauvais coups à celui de meilleur joueur du monde. Si la même chose est possible avec les modèles de langage, GPT-x pourrait balayer toute la discussion actuelle
    • Je suis fortement en désaccord avec l’idée qu’il n’y aurait « pas de création de valeur réelle ». J’ai dans mes cas d’usage un contre-exemple très clair
      GPT-4 est incroyablement utile quand une personne expérimentée travaille sur des tâches annexes où ses compétences générales tiennent la route, mais où ses connaissances métier sont faibles
      J’écris du code depuis 10 ans et j’ai commencé récemment à apprendre le machine learning pour la première fois ; j’utilise GPT-4 tous les jours et j’en suis très satisfait
      Bien sûr, ses aspérités peuvent parfois être agaçantes. Pour moi, ça reste gérable et pas particulièrement pénible. Je me suis habitué à les ignorer ou à les contourner, et il y a clairement un savoir-faire pour utiliser ce genre d’outils
      Je pense que la valeur apportée va continuer à croître. On n’a même pas encore cueilli tous les fruits à portée de main, ni même ceux à mi-hauteur
    • La différence essentielle avec DeFi/crypto, c’est que, aussi impressionnante que la technologie ait pu être, il fallait que les gens changent complètement ce qu’ils faisaient pour en tirer un premier bénéfice
      L’IA moderne, en pratique souvent les LLM, est immédiatement applicable de façon large à presque tous les secteurs de l’économie. C’est pour ça que tant de gens construisent déjà des fonctionnalités et les lancent. Cette technologie a une immense valeur. Est-ce qu’elle va totalement changer le monde ? Non, mais c’est largement suffisant pour créer de nouvelles catégories de produits et améliorer en profondeur une grande partie des capacités des produits existants
    • Je trouve que c’est une lecture assez raisonnable. L’IA a de nombreux usages et elle est vraiment bonne pour certaines choses, mais ce n’est pas la solution miracle que les gens espèrent

  • Je ne sais pas pourquoi aucun des assistants vocaux d’Apple, Google, Amazon ou Microsoft n’a encore intégré de LLM dans son service, ni pourquoi OpenAI n’a pas lancé son propre assistant vocal
    Cela dit, si des sites web exposaient, comme avec RSS, une URL standard pour l’interaction avec l’IA et rendaient leur interface publique via TypeChat, j’ai l’impression qu’on pourrait déjà bien avancer dans cette direction

    • Il est très probable qu’OpenAI finisse par créer son propre assistant. Le message de Karpathy, « Building a kind of JARVIS @ OреոΑӏ », va dans ce sens, et Microsoft travaille évidemment aussi à intégrer ou à réinventer Cortana avec les LLM d’OpenAI
      Cela dit, la valeur d’un LLM vocal est bien moindre que sa capacité à effectuer réellement des actions. Prenons Alexa : il faut un système capable de gérer la domotique de façon prévisible et débogable. Sinon, les gens s’énervent
      C’est clairement possible, mais les systèmes actuels comme Alexa ou Siri, et même Cortana qui est moins utilisé, reposent depuis des années sur des règles et du logiciel construits au-dessus de modèles moins puissants, avec de nombreux hooks et API. Pour que cela fonctionne, il faut à la fois améliorer le système sans dégrader la qualité actuelle, tout en refondant ses parties principales, donc cela prend du temps
      En plus, ces assistants ne rapportent pas vraiment d’argent et sont généralement déficitaires. Ils n’ont de valeur que pour de grands groupes capables de se rattraper autrement, via les téléphones, le shopping ou d’autres activités, donc une startup a peu d’incitation à s’y lancer
      J’ai travaillé à la fois sur Cortana et Alexa par le passé, et j’ai beaucoup réfléchi à créer une nouvelle version from scratch en m’appuyant sur les progrès des LLM. La technologie me paraissait globalement intuitive, et j’avais aussi des idées de nouveaux cas d’usage devenus possibles aujourd’hui, mais je n’ai pas trouvé de modèle économique viable. Du coup, je fais maintenant quelque chose de complètement différent
    • Quand j’ai compris pour la première fois ce qu’était ChatGPT, ma réaction a été : « Ah, donc c’est comme ça que Siri aurait dû être depuis le début »
    • Depuis que j’ai utilisé ChatGPT et Bing, parler à Alexa en devient presque ridicule. C’est vraiment frustrant de voir un matériel performant être freiné depuis des années par un logiciel lamentable
    • Microsoft est en train de faire cela pour remplacer Cortana dans Windows 11
    • J’attends vraiment avec impatience quelque chose qui puisse servir à piloter Home Assistant
      En revanche, l’idée d’utiliser pour ça une API cloud m’inquiète trop, donc je voudrais que cela tourne sur un serveur à la maison. En même temps, il faut absolument que la reconnaissance vocale et le temps de réponse soient très rapides, au point de ne jamais avoir l’impression d’attendre
      J’ai déjà vu plusieurs tentatives DIY d’assistant personnel, mais il y a toujours une latence assez importante, au point que ce serait vite agaçant à l’usage

  • Il y a ce point disant qu’il est facile d’obtenir une réponse comme { "name": "grande latte" }
    Mais si le type est Item = { name: string; ... size?: string; }, je ne vois pas bien comment cela empêche name: "grande latte"
    Dans l’exemple de réponse, il y a "size": 16, et ils disent que c’est « plutôt excellent », alors que cela ne renvoie même pas réellement le type demandé. C’est probablement une coquille dans l’exemple, et si c’est le cas, l’idée en elle-même semble intéressante

    • Merci de l’avoir signalé. Dans une version précédente de l’article de blog, on utilisait un autre schéma où size était par erreur défini comme number. On a changé le schéma, mais on n’a pas relancé le prompt, et cela devrait maintenant être corrigé
    • Je trouve que cet exemple est globalement assez faible. Le problème va au-delà d’une simple coquille
      Il est probable que vous ne vouliez pas, au départ, d’un champ chaîne name. Rien n’empêche d’obtenir quelque chose comme { name: “the brown one”, size: “the espresso cup”, … }, et c’est à peu près aussi mauvais que de parser directement la chaîne d’origine
      Vous voudriez probablement plutôt un grand type union de chaînes représentant les valeurs connues pour chaque champ. Le LLM pourrait alors essayer de se conformer à l’une d’elles
      Mais je me demande aussi pourquoi lier cela à une syntaxe de types. Quelque chose comme Zod, qui permet de construire de tels types union à partir de données d’exécution, semblerait plus adapté
      Il faut aussi des contraintes du genre : la quantité doit être un entier positif et ne doit pas être fractionnaire. Bien sûr, on peut valider les valeurs JSON après coup, mais dans ce cas l’utilisateur verra deux types d’erreurs : d’un côté une erreur produite par le LLM dans un langage humain fluide, et de l’autre une erreur étrangement technique du style « la valeur de quantité est trop grande »
      La syntaxe de types ne semble pas être le bon endroit pour exprimer ce genre de choses
    • Ça ressemble juste à un bug de documentation. Ils ont probablement remplacé à la dernière minute les quantités en onces par des tailles standard, puis oublié de mettre à jour les valeurs de sortie
      Avec le code fourni, il n’y a aucun moyen pour le système d’associer « grande » à 16, et 16 ne semble pas non plus utilisé ailleurs
    • Le paragraphe suivant traite de « ce qui se passe quand on ignore les types », donc c’était peut-être l’intention

  • On dirait qu’ils relancent le LLM jusqu’à ce qu’il produise quelque chose qui passe la vérification de types, puis le repromptent avec le message d’erreur
    C’est une idée mignonne et ça a l’air de pouvoir marcher, mais avec de grands modèles et de longs prompts en entrée, le coût peut devenir élevé. Cela ne semble pas être une solution à tous les scénarios

    • Chez OpenAI au moins, n’est-il pas préférable d’utiliser en interne la nouvelle fonction d’appel de fonctions ?
    • Je ne sais pas exactement comment fonctionne TypeChat, mais Guidance [1] est un projet similaire et peut en fait imposer un format en s’intégrant directement à l’échantillonnage des tokens
      [1]: https://github.com/microsoft/guidance
    • La plupart des produits vont sans doute d’abord se soucier de leur adéquation produit-marché, puis chercher à réduire les coûts ensuite
      Il y a aussi l’hypothèse, assez raisonnable, que puisque le marché demande des sorties structurées, les modèles évolueront eux aussi dans cette direction

  • J’ai publié cette semaine quelque chose de très similaire pour Laravel PHP, mais avec un périmètre plus réduit : https://github.com/adrenallen/ai-agents-laravel
    Je pense qu’un ingénieur devrait pouvoir lancer facilement un nouveau « bot » avec le LLM de son choix. Il y a beaucoup de travail fastidieux à convertir des fonctions dans un format que ChatGPT peut comprendre, puis à traiter la réponse pour la parser à nouveau
    Avec ce genre de système, on peut se concentrer sur l’écriture de vrai code PHP et l’ajout de quelques commentaires clairs, puis le bot peut utiliser ce code directement comme un outil pour n’importe quelle tâche
    Cette approche facilite aussi énormément le partage de code. Si quelqu’un écrit une fonction, on peut l’importer dans un nouveau bot et l’utiliser immédiatement. J’adore le fait que cela supprime la « couche de transformation pour que le LLM puisse l’utiliser et la comprendre », et que cela accélère fortement le développement
    Ce n’est pas encore parfait, mais je pense qu’à terme tout ira dans cette direction si on veut mieux réutiliser le code des autres. Quand on pense à la manière dont on utilise aujourd’hui des gestionnaires de paquets pour coder, j’aimerais qu’il existe un gestionnaire de paquets pour les outils dédiés à l’IA. On installerait une bibliothèque « récupérer la météo » et on l’ajouterait à son bot, qui pourrait alors récupérer la météo

    • Je travaille sur une approche similaire mais avec un périmètre un peu plus large, donc j’ai mis une étoile. Certaines idées sont vraiment élégantes

  • Attendez, est-ce que ça fait une validation à l’exécution d’objets à partir de définitions de types TypeScript ? Si cela pouvait être distribué comme bibliothèque autonome ou comme fonctionnalité séparée, ce serait un vrai game changer dans une codebase TypeScript pour des choses comme la validation des payloads de réponse d’API

  • Je suis très surpris qu’ils n’utilisent pas guidance ici [0]
    Cela pourrait suggérer de compléter les champs obligatoires, réduire le besoin de validation [1] et au final probablement économiser du temps GPU
    Il doit sûrement y avoir une raison, et j’aimerais vraiment la connaître
    Soit dit en passant, j’étais justement en train de construire exactement ce genre de chose, et j’ai l’impression que Microsoft a débarqué d’un coup pour me couper l’herbe sous le pied
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...