Présentation approfondie du framework de Foundation Models

Bonjour, je m’appelle Louis. Aujourd’hui, nous allons voir comment profiter au mieux du framework de Foundation Models.

Comme vous le savez, le framework de Foundation Models permet d’accéder directement au grand modèle de langage embarqué, via une API Swift pratique. Il est disponible sur macOS, iPadOS, iOS et visionOS. Comme il fonctionne en local, il suffit de l’importer dans votre projet pour commencer à l’utiliser. Nous allons voir comment fonctionnent les sessions avec Foundation Models. Comment utiliser Generable pour obtenir des sorties structurées ? Comment obtenir des sorties structurées avec des schémas dynamiques définis à l’exécution et utiliser l’appel d’outils pour permettre au modèle d’invoquer vos fonctions personnalisées ? Commençons simplement par générer du texte avec une session.

Je travaille sur un jeu en pixel art autour d’un café, et je pense que cela pourrait être amusant d’utiliser Foundation Models pour générer des dialogues ou d’autres contenus immersifs !

Nous pouvons demander au modèle de répondre à la question d’un joueur, et ainsi permettre à notre barista d’avoir un dialogue personnalisé. Nous allons créer une LanguageModelSession avec des instructions personnalisées. Cela permet de définir le rôle du modèle pour la session, et comme invite, on utilise l’entrée de l’utilisateur. Et c’est tout ce qu’il faut pour créer un élément de jeu amusant. Demandons au barista « Depuis combien de temps travaillez-vous ici ? », et voyons sa réponse.

Cette réponse est générée entièrement en local. Plutôt impressionnant. Comment cela fonctionne-t-il réellement ? Voyons comment Foundation Models génère du texte et quels sont les points à surveiller. Quand vous invoquez respond(to:), la session prend les instructions et l’invite. Ici, l’entrée utilisateur, et convertit tout cela en jetons. Les jetons sont de petites sous-chaînes, parfois des mots, mais souvent quelques caractères. Un grand modèle de langage prend une séquence de jetons en entrée et génère une nouvelle séquence de jetons en sortie. Vous n’avez pas besoin de vous soucier des jetons avec lesquels Foundation Models fonctionne : l’API s’en charge pour vous. Mais il est important de comprendre que les jetons ont un coût. Chaque jeton de vos instructions et invite ajoute de la latence. Avant de générer une réponse, le modèle doit d’abord traiter tous les jetons d’entrée. Et la génération elle-même a un coût computationnel. C’est pourquoi des sorties longues prennent plus de temps.

Une LanguageModelSession est avec état. Chaque appel respond(to:) est enregistré dans la transcription.

La transcription comprend toutes les invites et réponses d’une session donnée.

Cela peut être utile pour du débogage, ou pour l’afficher dans votre interface utilisateur.

Mais une session a une taille limite. Si vous faites trop de demandes, ou utilisez des invites/réponses volumineuses, vous pouvez atteindre cette limite de contexte.

Si vous dépassez cette limite, une erreur est levée, et il faut pouvoir la gérer. Dans mon jeu, si une erreur survient en plein dialogue, la conversation se coupe... dommage, je commençais à bien connaître le personnage ! Heureusement, on peut gérer cette erreur.

Il faut intercepter l’erreur exceededContextWindowSize.

On peut alors démarrer une nouvelle session, sans historique. Mais dans mon jeu, cela voudrait dire que le personnage oublie toute la conversation.

On peut aussi conserver une partie de la transcription et la réinjecter dans la nouvelle session.

Il suffit de créer un array condensé à partir de l’ancienne transcription.

Pour notre jeu, on peut récupérer la première entrée, les instructions. Et la dernière réponse générée. En les injectant dans une nouvelle session, notre personnage peut poursuivre la conversation. Attention : la première entrée de la transcription est toujours celle contenant les instructions. Si on recrée une transcription, il faut s’assurer d’inclure ces instructions.

Réutiliser quelques éléments pertinents de la transcription est une solution simple et efficace. Mais cela n’est pas toujours aussi facile. Imaginons une transcription avec beaucoup d’entrées. Il faut toujours commencer par conserver les instructions. Mais de nombreuses entrées intermédiaires peuvent être utiles, donc dans ce cas, on peut envisager de résumer la transcription.

Soit avec une bibliothèque externe, soit en utilisant Foundation Models pour résumer certaines parties.

Voilà donc ce que vous pouvez faire avec la transcription d’une session. À présent, regardons rapidement comment les réponses sont réellement générées. Dans notre jeu, quand le joueur interagit avec le barista, il peut poser n’importe quelle question. Mais si vous démarrez deux nouvelles parties et que vous posez exactement la même question, vous obtiendrez probablement deux réponses différentes. Comment est-ce possible ? Cela vient du mécanisme d’échantillonnage.

Lorsqu’il génère une réponse, le modèle procède jeton par jeton. Il génère une distribution de probabilité sur les jetons possibles. Par défaut, Foundation Models choisit une plage de probabilité dans cette distribution. Parfois, il commencera par « Ah », parfois par « Eh bien ». Cela se répète à chaque jeton généré. C’est ce que nous appelons l’échantillonnage. Et par défaut, Foundation Models utilise un échantillonnage aléatoire. Ce qui est super pour les jeux. Mais dans d’autres cas, on peut vouloir un résultat déterministe, par exemple, pour une démo répétable. L’API GenerationOptions permet de contrôler cela. En choisissant greedy, on obtient une réponse déterministe. À condition que l’état de la session soit identique, le modèle générera la même sortie pour la même invite. Mais attention : cela dépend aussi de la version du modèle embarqué. Lors d’une mise à jour du système d’exploitation, votre invite peut générer une sortie différente, même en utilisant l’échantillonnage greedy. Vous pouvez également régler la température pour l’échantillonnage aléatoire. Par exemple, réglez la température sur 0,5 pour limiter les variations, ou sur une valeur plus élevée pour des sorties plus diversifiées. Plus la température est élevée, plus les sorties seront variées. pour la même invite. Si vous utilisez l’entrée utilisateur comme invite, la langue peut ne pas être prise en charge.

Dans ce cas, l’erreur unsupportedLanguageOrLocale dédiée sera détectée. Cela vous permet d’afficher un message d’erreur personnalisé dans la UI. Une API permet aussi de tester si une langue est prise en charge par le modèle. Par exemple, pour vérifier la langue actuelle de l’utilisateur et afficher un avertissement si besoin. Voilà pour l’aperçu des sessions. Vous pouvez soumettre des invites, l’historique est stocké dans la transcription. Et vous pouvez définir le paramètre d’échantillonnage pour contrôler le caractère aléatoire de la sortie de la session. Maintenant, allons plus loin ! Quand le joueur se déplace, on peut générer des PNJ (personnages non-jouables) avec Foundation Models. Mais cette fois, nous voulons une sortie plus complexe. Nous voulons un nom et une commande de café de la part du PNJ, pas juste du texte brut. C’est là que Generable entre en scène. Obtenir une sortie structurée depuis un grand modèle de langage peut devenir un véritable défi. Vous pourriez demander explicitement certains champs et utiliser un code d’analyse pour les extraire. Mais c’est fragile et difficile à maintenir si le code ne retourne pas de clé valide, ce qui ferait échouer toute la méthode. Heureusement, Foundation Models propose une meilleure API appelée Generable. Il suffit d’annoter votre structure avec la macro @Generable. Que veut dire Generable et est-ce que ce mot existe vraiment ? Et bien, oui, il existe vraiment.

Generable est une façon simple de demander au modèle de générer des données structurées, à partir de types Swift. Lors de la compilation, la macro génère un schéma que le modèle peut utiliser pour produire la structure attendue. La macro génère aussi un initialiseur, qui est automatiquement appelé lors de l’envoi d’une requête à une session.

Nous pouvons donc générer des instances de notre structure. Comme précédemment, nous appellerons la méthode respond sur notre session. Mais cette fois, passez l’argument générateur indiquant au modèle le type à générer. Foundation Models ajoutera automatiquement les détails de votre type Generable à l’invite, dans un format spécifique sur lequel le modèle a été entraîné. Pas besoin de lui expliquer les champs de votre type Generable. Dans notre jeu, nous aurons désormais des interactions de PNJ générées de façon réaliste !

Generable est en réalité plus puissant qu’il n’y paraît. À un bas niveau, il utilise le décodage contraint, une technique qui permet au modèle de générer du texte respectant un schéma précis. Ce fameux schéma généré par la macro. Comme nous l’avons vu précédemment, un LLM génère des jetons qui sont ensuite transformés en texte. Avec Generable, ce texte est automatiquement analysé en toute sécurité. Les jetons sont générés dans une boucle appelée boucle de décodage. Sans décodage contraint, le modèle pourrait halluciner un nom de champ invalide. Comme « firstName » au lieu d’un nom. Ce qui empêcherait l’analyse correcte dans le type PNJ.

Mais avec le décodage contraint, le modèle est empêché de produire ce genre d’erreur structurelle. À chaque jeton généré, il y a une distribution de tous les jetons du vocabulaire du modèle. Le décodage contraint masque les jetons non valides. Donc, au lieu de choisir n’importe quel jeton, le modèle ne peut choisir que parmi les jetons valides selon le schéma.

Et tout cela sans devoir analyser manuellement la sortie du modèle. Cela signifie que vous pouvez vous concentrer sur l’essentiel, comme discuter avec des clients virtuels dans votre café virtuel ! Generable est vraiment le meilleur moyen d’obtenir une sortie depuis le LLM embarqué. Et il peut faire bien plus encore. Vous pouvez non seulement l’utiliser sur des structs, mais aussi sur des enums ! Alors, utilisons-cela pour rendre nos rencontres plus dynamiques ! Ici, j’ai ajouté un enum Encounter, avec deux cas. L’enum peut même contenir des valeurs associées. Utilisons-la pour générer une commande de café ou une interaction avec un client demandant à parler au responsable.

Voyons maintenant ce que nous rencontrons dans notre jeu !

Génial, quelqu’un a vraiment besoin d’un café.

À l’évidence, tous les clients ne sont pas faciles à gérer, donc ajoutons des niveaux à nos PNJ. Generable prend en charge par défaut les types Swift les plus courants, y compris Int. Ajoutons donc une propriété de niveau. Mais nous ne voulons pas générer n’importe quel entier. Si nous voulons que le niveau soit dans une plage spécifique, nous pouvons utiliser un Guide. Nous pouvons utiliser la macro Guide sur notre propriété et passer une plage. Le modèle utilisera à nouveau le décodage contraint pour garantir une valeur dans cette plage.

Profitons-en pour ajouter un array d’attributs à notre PNJ.

Nous pouvons à nouveau utiliser un guide pour spécifier que nous voulons exactement trois attributs dans cet array. Gardez à l’esprit que les propriétés de votre type Generable sont générées dans l’ordre où elles apparaissent dans le code source. Ici, le nom sera généré en premier, suivi du niveau, puis des attributs et de la rencontre en dernier.

Cet ordre peut être crucial si la valeur d’une propriété dépend d’une autre. Et vous pouvez même demander une génération propriété par propriété au lieu d’attendre la sortie complète. Le jeu devient vraiment amusant. Je vais bientôt pouvoir le partager avec mes amis. Mais je remarque que les noms des PNJ ne sont pas exactement ceux que j’avais en tête. Je préférerais avoir un prénom et un nom de famille.

Nous pouvons utiliser un guide pour cela, mais cette fois-ci, avec une description en langage naturel.

Nous pouvons dire que notre nom doit être un « nom complet ». Et c’est effectivement une autre façon d’écrire une invite. Au lieu de décrire les différentes propriétés dans votre invite, vous pouvez le faire directement dans le type Generable. Cela donne au modèle un lien plus fort entre les champs et leurs descriptions. Si nous nous promenons dans notre jeu, nous verrons ces nouveaux noms s’afficher. Voici un aperçu de tous les guides que vous pouvez appliquer aux différents types.

Pour les types numériques, tels que Int, on peut spécifier un minimum, un maximum ou une plage. Pour array, on peut contrôler le nombre d’éléments ou des guides spécifiques pour chaque élément.

Pour String, vous pouvez utiliser anyOf pour choisir dans un array ou même contraindre avec une expression régulière.

Les guides utilisant les expressions régulières sont particulièrement puissants. Vous connaissez peut-être les expressions régulières pour vérifier du texte. Avec Foundation Models, vous pouvez utiliser une expression régulière pour définir la structure d’une chaîne à générer. Par exemple, vous pouvez restreindre les noms à certains préfixes. Vous pouvez même utiliser la syntaxe de création de l’expression régulière !

Si cela vous a donné envie de découvrir les expressions régulières, regardez la vidéo « Meet Swift Regex » qui date d’il y a quelques années. Pour récapituler, Generable est une macro que vous appliquez à des structs et des enums pour obtenir des sorties structurées fiables du modèle. Vous n’avez pas à vous soucier de l’analyse, et pour obtenir une sortie encore plus spécifique, vous pouvez appliquer des guides à vos propriétés. Generable est donc parfait quand on connaît la structure au moment de la compilation. La macro génère le schéma et vous obtenez une instance du type sortie. Mais parfois, on ne connaît une structure qu’à l’exécution. C’est là que les schémas dynamiques peuvent vous aider. J’ajoute un créateur de niveau à mon jeu, dans lequel les joueurs peuvent définir dynamiquement des entités à rencontrer pendant l’exploration. Par exemple, un joueur peut créer une structure d’énigme. Dans laquelle une énigme renferme une question et des réponses à choix multiples. Si on connaissait cette structure au moment de la compilation, on pourrait simplement définir une struct Generable pour elle. Mais notre créateur de niveau permet de créer n’importe quelle structure que le joueur imagine.

Nous pouvons utiliser « DynamicGenerationSchema » pour générer un schéma à l’exécution. À l’instar d’une structure définie au moment de la compilation, un schéma dynamique dispose d’une liste de propriétés. Nous pouvons ajouter un créateur de niveau, capable de prendre les entrées d’un joueur.

Chaque propriété dispose d’un nom et de son propre schéma, qui définit son type. Vous pouvez utiliser le schéma pour tout type Generable, y compris les types intégrés comme String.

Un schéma dynamique peut contenir un array, dans lequel vous spécifiez ensuite un schéma pour ses éléments. Et surtout, un schéma dynamique peut référencer d’autres schémas dynamiques. Ici, notre array peut référencer un schéma personnalisé également défini à l’exécution.

À partir des entrées de l’utilisateur, nous pouvons créer un schéma d’énigme avec deux propriétés. La première est la question, une propriété chaîne. Et la seconde, une propriété array d’un type personnalisé nommé Answer. Ensuite, nous créerons la réponse. Il comprend une propriété chaîne et booléenne. Notez que la propriété Réponse de l’énigme fait référence au schéma Réponse par son nom. Nous pouvons créer ensuite les instances DynamicGenerationSchema. Chaque schéma dynamique est indépendant. Autrement dit, le schéma dynamique de l’énigme ne contient pas réellement celui de la réponse. Avant d’inférer du contenu, il faut d’abord convertir nos schémas dynamiques en un schéma validé. Cela peut générer des erreurs en cas d’incohérences dans les schémas dynamiques, tels que des types référencés non définis.

Une fois le schéma validé, nous pouvons lancer une session comme d’habitude. Mais cette fois, le type de sortie est une instance GeneratedContent. Elle contient les valeurs dynamiques générées. Vous pouvez les interroger avec les noms de propriété définis dans vos schémas dynamiques. Encore une fois, Foundation Models utilise une génération guidée pour garantir que la sortie respecte votre schéma. Le modèle ne générera jamais un champ inattendu ! Donc même avec du contenu dynamique, pas besoin d’analyser la sortie manuellement.

Ainsi, lorsque le joueur rencontre un PNJ, le modèle peut générer ce contenu dynamique. Que nous afficherons dans une interface utilisateur dynamique. Voyons ce que nous allons rencontrer. Je suis noir ou au lait, amer ou sucré, je te réveille et je te donne chaud, qui suis-je ? Café ou chocolat chaud. Je pense que la bonne réponse est le café. C’est exact ! Je pense que mes joueurs vont bien s’amuser à créer toutes sortes de niveaux amusants. Pour récapituler, avec la macro Generable, nous pouvons facilement générer une sortie structurée à partir d’un type Swift défini au moment de la compilation. Et en coulisses, Foundation Models gère le schéma et la conversion du GeneratedContent en une instance de votre type. Les schémas dynamiques fonctionnent de manière très similaire, mais vous donnent bien plus de contrôle. Vous contrôlez entièrement le schéma à l’exécution et accédez directement au GeneratedContent. Passons maintenant à l’appel d’outils, qui permet au modèle d’invoquer vos propres fonctions. Je pense créer un DLC, du contenu téléchargeable, pour rendre mon jeu plus personnel. En utilisant l’appel d’outils, je peux laisser le modèle récupérer des informations de manière autonome. Je me dis qu’intégrer les contacts et le calendrier du joueur pourrait être très amusant. Je ne ferais pas ça normalement avec un modèle côté serveur ; mes joueurs n’apprécieraient pas que le jeu charge de telles données personnelles. Mais comme tout est exécuté en local avec Foundation Models, nous pouvons le faire en préservant la confidentialité.

Définir un outil est très simple avec le protocole Tool. Vous commencez par lui donner un nom et une description. C’est ce que l’API inclura automatiquement dans l’invite pour que le modèle décide quand et comment appeler votre outil.

Il est préférable de choisir un nom d’outil court, mais lisible en anglais. Évitez les abréviations et ne faites pas une description trop longue ou contenant les implémentations. Souvenez-vous : ces chaînes sont injectées telles quelles dans l’invite. Donc, plus elles sont longues, plus il y a de jetons, ce qui peut augmenter la latence. À la place, utilisez un verbe dans le nom, tel que findContact. Et votre description devrait tenir en une phrase. Comme toujours, il est important de tester différentes variantes pour voir ce qui fonctionne le mieux pour votre outil spécifique.

Ensuite, nous pouvons définir l’entrée de notre outil. Je souhaite que l’outil récupère les contacts d’une certaine génération, comme les millennials. Le modèle pourra choisir un cas amusant selon l’état du jeu, et je peux ajouter la struct Arguments que je rends Generable. Quand le modèle décide d’invoquer cet outil, il génère les arguments d’entrée. Grâce à Generable, on s’assure que les arguments d’entrée sont toujours valides. Donc, il ne va pas inventer une génération, comme la génération alpha, que nous ne prenons pas en charge dans notre jeu.

Ensuite, je peux implémenter la fonction d’appel. Le modèle appellera cette méthode lorsqu’il décide d’invoquer l’outil. Dans cet exemple, nous faisons appel à Contacts API. Et renvoyons le nom d’un contact correspondant à cette requête.

Pour utiliser notre outil, nous le passons dans l’initialiseur de session. Le modèle invoquera alors notre outil lorsqu’il aura besoin de cette information supplémentaire. C’est plus puissant que de récupérer le contact nous-mêmes, car le modèle ne fera appel à l’outil que lorsqu’il en a besoin pour un PNJ donné, et il peut choisir des arguments d’entrée amusants selon l’état du jeu. Comme la génération d’âge du PNJ.

Notez que nous utilisons l’API Contacts standard, que vous connaissez peut-être déjà. Lorsque notre outil est invoqué pour la première fois, il demande la permission habituelle au joueur. Même si le joueur refuse l’accès à ses contacts, Foundation Models peut quand même générer du contenu comme avant, mais s’il accepte, on le rend plus personnel.

Promenons-nous un peu dans notre jeu jusqu’à ce que nous rencontrions un autre PNJ. Et cette fois, je vais obtenir un nom à partir de mes contacts ! Oh bonjour Naomy ! Voyons ce qu’elle a à nous dire. Je ne savais pas que tu aimais le café. Notez que LanguageModelSession prend une instance d’un outil. Cela signifie que vous contrôlez le cycle de vie de l’outil. L’instance de cet outil reste la même pendant toute la session. Dans cet exemple, comme on récupère un personnage aléatoire avec FindContactTool, il se peut qu’on obtienne parfois le même contact. Il y a maintenant plusieurs Naomy dans notre jeu. Et ce n’est pas acceptable, il ne peut y en avoir qu’une ! Pour corriger cela, on peut suivre les contacts déjà utilisés dans le jeu. Nous pouvons ajouter un état dans notre FindContactTool. Pour cela, nous convertissons d’abord notre FindContactTool en classe. Ainsi, elle peut modifier son état depuis la méthode d’appel. Ensuite, on garde une trace des contacts sélectionnés, et on évite de les reprendre.

Les noms des PNJ sont maintenant basés sur mes contacts ! Mais discuter avec eux ne semble pas encore naturel. Finissons par un autre outil, cette fois pour accéder à mon calendrier.

Pour cet outil, nous transmettons le nom du contact issu du dialogue de notre jeu. Et quand le modèle invoque cet outil, on le laisse générer un jour, un mois et une année pour récupérer les évènements liés à ce contact. Nous passons ensuite cet outil dans la session liée au dialogue avec le PNJ.

Si je demande à « Quoi de neuf ? », elle peut répondre avec de vrais évènements que nous avons planifiés ensemble.

Waouh, c’est comme parler à la vraie Naomy.

Examinons de plus près le fonctionnement de l’appel d’outils. Nous commençons par passer l’outil au lancement de la session, avec les instructions. Pour cet exemple, nous incluons des informations telles que la date du jour. Ensuite, quand l’utilisateur envoie une invite, le modèle l’analyse. Dans cet exemple, le modèle comprend que l’invite porte sur des évènements, il est donc logique d’invoquer le calendrier.

Pour invoquer l’outil, le modèle commence par générer les arguments d’entrée. Ici, il doit générer une date pour laquelle récupérer les évènements. Le modèle peut relier les informations des instructions et de l’invite, et comprendre comment remplir les arguments de l’outil à partir de cela. Dans cet exemple, il peut déduire ce que signifie « demain » en se basant sur la date d’aujourd’hui fournie dans les instructions. Une fois les entrées générées pour votre outil, la méthode d’appel est invoquée. C’est le moment de briller : votre outil peut faire ce qu’il veut. Mais attention, la session attend que votre outil renvoie une réponse avant de générer la suite.

La sortie de votre outil est ensuite ajoutée à la transcription, comme celle du modèle. Et à partir de cette sortie, le modèle peut générer une réponse à l’invite. Notez qu’un outil peut être appelé plusieurs fois pour une seule requête. Et dans ce cas, votre outil est invoqué en parallèle. Gardez cela en tête si vous accédez à des données dans la méthode d’appel de votre outil. Bon, c’était plutôt amusant ! Notre jeu génère maintenant du contenu aléatoire à partir de mes contacts et de mon calendrier personnels. Sans que mes données ne quittent jamais mon appareil. Pour résumer, l’appel d’outils permet au modèle d’invoquer votre code pour accéder à des données externes pendant une requête. Il peut s’agir d’informations privées, comme les contacts, ou des données externes issues du Web. Gardez à l’esprit qu’un outil peut être invoqué plusieurs fois dans une même requête. Le modèle détermine cela en fonction du contexte. Les outils peuvent aussi être invoqués en parallèle, et ils peuvent stocker un état. Cela fait beaucoup d’infos. Prenez peut-être un café avant de reprendre vos activités. Pour en savoir plus, vous pouvez consulter la vidéo dédiée à l’ingénierie de l’invite, avec des conseils de conception et de sécurité. Et si vous souhaitez rencontrer la vraie Naomy, regardez la vidéo de code-along. J’espère que vous vous amuserez autant avec Foundation Models que moi. Merci de votre attention !