Code-along : Intégrez l’IA contenue sur l’appareil à votre app à l’aide du framework de Foundation Models

Bonjour, je m’appelle Naomy. Entrons dans le monde de SwiftUI et de l’intelligence embarquée. Dans cette séance de code, nous allons voir comment intégrer de nouvelles fonctionnalités à vos apps avec le framework Foundation Models. Je vais vous montrer un exemple étape par étape en créant une app pour planifier mon prochain voyage. Le framework Foundation Models vous offre un accès direct au puissant modèle de langage intégré d’Apple. Il ouvre ainsi un champ infini de possibilités créatives. Tout est exécuté sur l’appareil afin que les données de vos utilisateurs restent confidentielles. Le modèle est hors ligne et déjà intégré au système d’exploitation. Il n’augmentera pas la taille de vos apps. Ce framework nous permet de créer des fonctionnalités puissantes, confidentielles et performantes sur macOS, iPadOS, iOS et visionOS. Mes amis et moi avons envie de voyager, mais nous cherchons des idées pour choisir notre destination et planifier nos activités. Planifier peut être compliqué, mais utiliser le framework Foundation Models reste simple. Utilisons-le pour créer une app qui s’occupera de toute la planification à notre place. Voici ce que nous allons créer aujourd’hui. Dans mon app, la page de destination affiche plusieurs sites touristiques que nous pouvons parcourir. Oh, ces arbres ont l’air intéressants. Sélectionnons Joshua Tree. Nous pouvons cliquer sur le bouton Générer, et c’est là que le modèle fera le travail pour nous ! Il va créer un itinéraire et, en même temps, utiliser l’outil pour choisir les points les plus intéressants sur notre site touristique. Je suis sûre que mes amis vont adorer cette app. Commençons donc sa création ! Nous allons passer en revue les différentes étapes pour utiliser ce framework. Tout commence par l’ingénierie de prompts. Je vais vous montrer comment perfectionner vos prompts avec le playground de Xcode. Nous allons utiliser l’appel d’outils pour enrichir le modèle en lui permettant de se connecter à des sources externes afin de récupérer des points intéressants sur nos sites touristiques. Et nous afficherons le résultat en continu pour afficher notre itinéraire au fur et à mesure que le modèle le génère. Pour finir, nous allons analyser notre app et apporter des optimisations pour obtenir des performances optimales avec le framework Foundation Models. Un bon prompt est essentiel pour obtenir d’excellents résultats. Créer des prompts peut souvent être une tâche ennuyeuse avec beaucoup d’itérations. Je peux lancer mon app, vérifier le résultat, ajuster mon prompt, relancer l’app et recommencer, mais cela me prendrait toute une journée et je n’aurais plus le temps de voyager. Heureusement, la nouvelle version de la fonctionnalité Playground dans Xcode est là pour vous aider. Pour commencer, assurez-vous que le canevas est activé.

C’est comme Previews pour SwiftUI, mais nous aurons des retours en direct pour le code Swift. Dans n’importe quel fichier de mon projet, je peux importer des Playgrounds et écrire un #Playground à itérer sur mon code.

Commençons par les bases. Je vais importer Foundation Models, créer une session et faire une requête.

Dans mon prompt, je vais dire : « Créer un itinéraire ». La commande s’exécute donc automatiquement et le résultat est visible sur le canevas.

Ma requête était un peu vague, non ? Je vais donc ajouter une destination.

Notre prompt est bien meilleur. Nous avons un itinéraire cette fois-ci. Je suis satisfaite pour l’instant, et je peux toujours revenir pour modifier mon prompt plus tard. Nous avons découvert à quel point il est facile d’utiliser le framework Foundation Models : il suffit d’envoyer un prompt pour obtenir une réponse sous forme de texte. Pour mon itinéraire, je préfère une approche plus organisée. J’aimerais utiliser mes propres structures de données pour représenter le résultat, sans me soucier de l’analyse syntaxique de la sortie du modèle. La génération guidée permet au modèle de créer automatiquement les structures de données souhaitées, à condition que je les annote comme étant Generable. Voyons cela en pratique. Voici une structure d’itinéraire que le modèle doit générer. Importons d’abord Foundation Models et ajoutons l’annotation Generable.

La seule exigence de Generable est que les types de vos propriétés soient également Generable. Heureusement, les types courants tels que String sont Generable. Si vous avez des types imbriqués, comme DayPlan, vous pouvez simplement les rendre Generable aussi. Maintenant que nous avons une hiérarchie de types entièrement Generable, nous pouvons laisser le modèle concevoir des structures d’itinéraires en réponse. Pour mieux contrôler le résultat, la macro Guide vous permet de définir des contraintes sur les valeurs de vos propriétés. Vous pouvez ajouter un guide avec une description par exemple, comme je vais le faire pour le titre ici.

Nous pouvons également limiter une propriété à un sous-ensemble spécifique de valeurs.

Je peux ajouter un nombre pour que mon array Days ait toujours exactement trois éléments, et même utiliser plusieurs guides pour une propriété. Je vais ajouter des guides supplémentaires à mes propriétés.

Les descriptions des guides sont un autre moyen de transmettre un prompt au modèle. Je vous recommande vivement de regarder la vidéo approfondie, où Louis vous dira tout sur la génération guidée. Et maintenant que nous avons notre prompt et notre type Generable, nous pouvons tout assembler.

Voici notre planificateur d’itinéraire, où nous conserverons toute notre logique Foundation Models.

Créons une session.

Et donnons-lui des instructions. Je peux utiliser l’API Builder pour créer mes instructions facilement. Dans cette fermeture, je peux passer plusieurs chaînes de caractères, et même des instances de mon type Generable. Les instructions sont une forme de prompt plus élaborée. Je vais définir la tâche du modèle.

Nous aimerions avoir un itinéraire, et je vais donner au modèle quelques informations sur le site touristique sélectionné.

Inclure un exemple est très utile, car cela permet au modèle de mieux saisir le type de réponse que j’attends.

Je peux également passer une instance de la structure de mon itinéraire, qui est décrite ci-dessous pour un voyage au Japon.

Ma structure d’itinéraire étant Generable, Foundation Models la convertira automatiquement en un texte compréhensible par le modèle. Nous sommes prêts à faire notre requête, avec notre type Generable en sortie.

Dans notre prompt, nous demanderons explicitement un itinéraire au modèle.

Et pour lier le tout, définissons notre itinéraire en fonction de la réponse du modèle.

Notre dernière étape consiste à l’afficher dans notre UI. Rendons notre ItineraryPlanner observable, afin que notre UI puisse savoir quand notre itinéraire est généré.

Et ajoutons-le en tant que propriété d’état à notre LandmarkTripView, afin que notre vue soit mise à jour au fur et à mesure que le contenu du planificateur change.

Si nous l’initialisons ici, il sera recréé inutilement même lorsque la vue n’est pas affichée à l’écran, ce qui entraîne un coût de performance indésirable. Il est préférable de différer la création de l’objet à l’aide d’un modificateur de tâche. Ajoutons une tâche et initialisons notre planificateur ici.

Celui-ci ne sera appelé qu’une seule fois lorsque la vue apparaîtra. Lorsque nous recevrons un itinéraire du modèle, nous pouvons l’afficher.

Je vais utiliser une autre vue ici, appelée ItineraryView. Je vais y afficher mon titre, puis je vais ajouter un peu de style.

Je vais faire de même pour ma description et mon raisonnement.

Je vais afficher mes propriétés d’itinéraire restantes de la même manière en utilisant mes autres vues. C’est un bon début, et le modèle va utiliser la description que nous avons fournie dans les instructions pour générer un itinéraire de base. Allons un peu plus loin. Le framework offre un protocole d’outil flexible qui permet au modèle d’inclure des informations externes dans ses réponses. Vous pouvez faire preuve d’une grande créativité, que ce soit en utilisant les contacts de votre téléphone, les évènements de votre calendrier ou même le contenu en ligne. Le modèle décide de manière autonome quand il est judicieux d’appeler vos outils et à quelle fréquence. Pour spécialiser davantage mon app de planification, je vais créer un outil qui fait appel à MapKit pour trouver les points les plus intéressants sur un site touristique. Pour créer un outil, vous devez respecter le protocole établi.

Vous devez lui attribuer un nom unique pour l’identifier, fournir une description claire en langage naturel précisant quand l’utiliser, et définir une fonction d’appel qui déterminera comment le modèle activera votre outil avec les arguments choisis. Commençons par composer notre outil. Nous allons importer Foundation Models et MapKit.

J’ai une structure de données conforme au protocole de l’outil, avec un nom et une description.

Le framework place automatiquement ces chaînes dans les instructions, afin que le modèle puisse comprendre ce que fait votre outil et décider quand l’appeler. Un outil peut aussi prendre en compte les données de l’utilisateur, comme le site touristique qu’il a sélectionné.

Nous voulons que notre outil récupère différents types de faits intéressants. Ajoutons donc une énumération.

Le modèle va utiliser ses connaissances du monde pour déterminer les catégories les plus prometteuses pour un site spécifique. Il est plus probable de trouver une marina dans la Grande Barrière de Corail que dans un lieu aride comme le désert de Joshua Tree. Le modèle va générer cette énumération. Elle doit donc être Generable.

Nous allons définir ensuite notre structure d’arguments, qui utilise notre énumération, ainsi qu’une requête en langage naturel.

Pour l’implémentation, nous avons la méthode call, qui correspond à la manière dont le modèle va appeler votre outil. J’ai déjà écrit une logique MapKit qui envoie une requête à MapKit en utilisant la requête en langage naturel générée par le modèle comme entrée, ainsi que la catégorie choisie par le modèle, et récupère les points intéressants situés dans un rayon de 20 km autour des coordonnées de mon site touristique.

Nous allons faire une recherche avec les contraintes demandées et renverrons les résultats.

Nous pouvons ensuite implémenter la méthode d’appel. Allons dans MapKit, filtrons nos résultats et renvoyons notre sortie.

C’est vraiment tout ce qu’il faut pour créer un outil qui extrait des informations de MapKit. Pour finir, revenons à notre ItineraryPlanner.

Et voici la session que nous avons déjà créée. Nous allons créer une instance de notre outil avec le point de repère que l’utilisateur a choisi comme entrée.

Nous pouvons ensuite insérer notre outil dans le gestionnaire d’initialisation des sessions.

C’est suffisant pour que le modèle utilise notre outil, mais nous pouvons aussi envoyer des prompts supplémentaires si nous voulons qu’il soit utilisé plus fréquemment. Nous pouvons demander au modèle d’utiliser notre outil et nos catégories.

Et voilà ! Nous sommes prêts pour les tests. Si vous n’avez pas un appareil de test à portée de main, ce n’est pas grave. Si votre machine de développement utilise la dernière version de macOS avec Apple Intelligence, nous pouvons facilement l’exécuter dans les simulateurs iPhone et Vision Pro. Sélectionnons Joshua Tree et demandons un itinéraire.

Vous remarquerez que cette opération prend un certain temps. En effet, le modèle nous fournit toutes les sorties simultanément. Nous attendons donc que chaque activité soit générée avant de recevoir les résultats. Ne vous inquiétez pas, je vous montrerai plus tard comment accélérer les choses. Et voilà, nous avons un itinéraire intéressant.

Mais, nous avons en fait oublié quelque chose d’assez important. Nous avons supposé que le modèle Foundation embarqué est toujours disponible, mais ce n’est pas toujours le cas. La disponibilité du modèle dépend de celle d’Apple Intelligence. De plus, Apple Intelligence peut ne pas être pris en charge, activé ou accessible sur certains appareils. Vous devez donc vérifier l’état du modèle et le gérer dans notre interface utilisateur. Au lieu de devoir tester les appareils physiques ou de désactiver Apple Intelligence uniquement à des fins de test, nous pouvons utiliser une option très pratique dans Xcode.

Dans notre fenêtre, nous pouvons voir le simulateur de la disponibilité des modèles de base. Actuellement, il est désactivé. Mais, chacune de ces trois premières options explique pourquoi les modèles ne sont pas présents sur l’appareil. Choisissons-en une, essayons de générer un itinéraire et voyons ce qui se passe dans notre app.

Cela n’est pas très bon. Nous voyons une erreur pour laquelle il n’existe aucune solution. Je dois réfléchir à la manière dont je vais intégrer la disponibilité dans mon app. Examinons les trois cas que j’ai présentés plus tôt. Si l’appareil n’est pas compatible avec Apple Intelligence, il n’est pas judicieux d’afficher le bouton Générer un itinéraire. Lors de la sélection d’un point de repère, nous allons afficher une brève description en utilisant les données hors ligne de notre app. Dans le second cas, l’appareil est compatible, mais n’a tout simplement pas été connecté à Apple Intelligence. Nous devons informer l’utilisateur que c’est la raison pour laquelle notre planificateur n’est pas disponible. Il pourra ensuite décider s’il souhaite activer cette fonctionnalité. Enfin, « Modèle pas encore prêt » signifie qu’il faut attendre la fin du téléchargement du modèle. Nous pouvons dire à l’utilisateur de réessayer plus tard, car notre fonctionnalité sera bientôt disponible.

Nous pouvons maintenant utiliser l’API de disponibilité pour vérifier l’état de notre appareil, après avoir conçu le comportement de notre app. Je vais donc ajouter une nouvelle variable pour le modèle que j’utilise, dans ce cas, le modèle de langage système.

Nous pouvons ensuite activer l’état de disponibilité. Si le modèle est disponible, nous continuons simplement avec le même comportement qu’auparavant.

Quand Apple Intelligence n’est pas activé, informons l’utilisateur ou l’utilisatrice.

Et si le modèle n’est pas prêt, nous leur dirons de réessayer plus tard.

Sinon, nous masquerons notre bouton d’itinéraire et afficherons simplement notre anecdote.

J’ai déjà défini le remplacement des modèles de base dans mon schéma sur Appareil non compatible. Essayons encore une fois.

C’est beaucoup mieux. Maintenant, nous voyons juste une anecdote et le bouton Générer un itinéraire a été supprimé pour empêcher l’utilisateur de suivre une voie que son appareil ne peut pas prendre en charge. Si nous revenons en arrière, notre app attend que l’itinéraire soit généré avant de l’afficher dans l’interface utilisateur. Heureusement, en affichant l’itinéraire au fur et à mesure, nous pouvons lire les recommandations immédiatement. Pour utiliser le flux, nous allons modifier la méthode de réponse que nous appelons.

Au lieu d’obtenir un itinéraire complet, nous obtenons une version partielle. Nous pouvons utiliser la structure de données PartiallyGenerated qui est automatiquement créée pour nous. C’est votre structure Generable, mais avec toutes les propriétés facultatives. Je vais donc modifier le type de voyage prévu dans mon itinéraire.

Notre résultat sera maintenant une nouvelle séquence asynchrone avec notre type PartiallyGenerated en sortie.

Chaque élément de notre flux est une version mise à jour de notre itinéraire. Par exemple, le premier élément peut avoir un titre, mais les autres propriétés de l’itinéraire sont nulles. Puis, le deuxième élément peut avoir un titre et une description, et ainsi de suite, jusqu’à ce que nous ayons un itinéraire entièrement généré. Maintenant, je dois dévoiler ces propriétés dans mes vues. Il est également bon de déterminer quelles propriétés peuvent être présentées sans les autres. Dans mon cas, l’itinéraire a un titre, suivi d’une description, puis des plannings quotidiens, et cet ordre semble logique. Je vais générer partiellement mon itinéraire, puis je vais dévoiler mon titre, ma description et ma justification.

En ce qui concerne ma liste de jours,

je dois également afficher mes plannings quotidiens partiellement générés. C’est génial que les structures PartiallyGenerable soient automatiquement identifiables, car je n’ai pas à gérer les ID moi-même. Je peux utiliser forEach de SwiftUI avec mes structures partiellement générées.

C’est vraiment très simple. Ajoutons une animation basée sur notre itinéraire.

De plus, certains contenus sont transférés vers nos propriétés pour afficher nos résultats de manière fluide dans nos vues.

Je vais dévoiler toutes les autres propriétés pour arriver à une version proche du produit final. Faisons un test sur mon téléphone. Faisons la même requête que précédemment.

Cette fois-ci, nous allons voir le résultat s’afficher immédiatement dans notre interface utilisateur. En tant qu’utilisateur, je peux commencer à lire le premier jour à mesure que le contenu est généré.

Vous avez peut-être remarqué un léger délai avant que le premier champ ne s’affiche à l’écran. Pour résoudre ce problème, il peut être utile de comprendre ce qui se passe en coulisses.

C’est le moment d’utiliser le nouvel instrument Foundation Models pour mieux comprendre les facteurs qui influencent nos performances. Voyons ce que nous pouvons découvrir en profilant notre app. Plus tôt, nous avons parlé de l’exécution de notre app sur le simulateur. C’est parfait pour tester les fonctionnalités, mais cela peut ne pas donner des résultats de performance précis. Par exemple, un simulateur sur un Mac à puce M4 peut donner des résultats plus rapides qu’un iPhone plus ancien. Vous devez garder ces différences à l’esprit lorsque vous évaluez les performances. Je vais établir le profil sur un iPhone physique.

Pour commencer, j’ai ouvert l’app Instruments sur mon Mac et je connecte mon téléphone.

Nous pouvons ajouter le nouvel instrument Foundation Models, commencer à enregistrer, puis créer un itinéraire.

La piste de chargement des ressources examine le temps nécessaire pour charger les modèles. Le modèle de langage par défaut du système et les mesures de sécurité ont été chargés. La piste d’inférence est également affichée en bleu.

Enfin, la barre violette représente le temps qu’il faut pour appeler des outils. Nous pouvons suivre le temps total nécessaire pour générer l’itinéraire, ainsi que le nombre de jetons d’entrée, qui est proportionnel à la taille de nos instructions et de nos prompts. Au début, ce délai correspondait au temps nécessaire pour charger le modèle de langage du système. Mais, nous pouvons accélérer les choses. Nous avons observé qu’une partie de cette latence était capturée dans la piste de chargement des ressources. Le modèle de langage embarqué est administré par le système d’exploitation et peut être retiré de la mémoire si le système doit exécuter d’autres fonctions essentielles ou s’il n’a pas été utilisé depuis un certain temps. Lorsque j’appelle session.respond, le système d’exploitation charge le modèle s’il n’est pas déjà en mémoire. La préchauffe permet de prendre de l’avance sur votre session en chargeant le modèle avant votre requête. Il est préférable de procéder ainsi lorsque votre app est relativement inactive et juste après que l’utilisateur a clairement indiqué qu’il allait utiliser la session. Un bon exemple de préchauffe se produit juste après qu’un utilisateur commence à taper dans un champ de texte pour créer un prompt. Lorsqu’un utilisateur clique sur un site touristique dans notre app, il est probable qu’il fasse rapidement une requête. Nous pouvons préchauffer le modèle avant qu’il ne clique sur Générer l’itinéraire afin de le charger de manière proactive. Notre modèle sera prêt à être utilisé lorsqu’il aura terminé de lire la description.

La deuxième optimisation peut être ajoutée au moment de la demande. Vous vous souvenez de l’argument générateur des fonctions de réponse. Nous avons utilisé l’itinéraire ici. Eh bien, le framework insère automatiquement les schémas de génération de vos structures de données dans vos prompts. Cela ajoute toutefois plus de jetons, ce qui augmente la latence et la taille du contexte. Si le modèle a déjà une compréhension complète du format de réponse avant que la requête ne soit effectuée, nous pouvons définir IncludeSchemaInPrompt sur false et améliorer les performances.

Quand pouvons-nous appliquer cette optimisation ? Le premier cas concerne les requêtes de même type effectuées successivement dans une conversation à plusieurs tours. La première requête de la session donnait déjà un contexte pour la génération guidée en incluant le schéma dans le prompt. Nous n’avons donc pas besoin de le faire pour les requêtes ultérieures sur cette session. Le deuxième cas est si vos instructions incluent un exemple complet du schéma. Vous vous rappelez que nous avons inclus un exemple d’itinéraire dans nos instructions ? Dans notre cas, c’est suffisant, car notre structure d’itinéraire n’a pas de propriétés facultatives.

Si vous avez des propriétés facultatives dans votre schéma, vous devrez fournir des exemples avec toutes les propriétés facultatives remplies et nulles. Une dernière remarque : définir IncludeSchemaInPrompt sur false signifie que nous perdrons les descriptions que nous avons ajoutées à nos guides. Mais, si vous utilisez un exemple complet, cela ne devrait pas poser de problème. Testons ces optimisations. Nous allons définir l’option IncludeSchemaInPrompt sur false dans notre requête. Nous allons aussi préchauffer notre session pendant que l’utilisateur lit la description du site touristique. Créons rapidement une fonction-enveloppe, puis appelons-la dans la session.

Voyons les résultats. J’ai enregistré tout cela à nouveau et nous pouvons jeter un coup d’œil aux résultats. Le chargement des ressources était déjà en cours avant que je n’appuie sur le bouton Générer. Nous constatons une réduction considérable du nombre de jetons d’entrée et le temps de réponse total est désormais plus court. Grâce aux quelques secondes gagnées avec ces optimisations, nous pouvons être certains d’arriver à l’heure pour notre vol. Et sur ce, je suis prête pour mon voyage.

Mais avant de partir, voici d’autres séances qui peuvent vous intéresser. Si vous ne l’avez pas encore vu, regardez la séance de découverte pour tout savoir sur le framework. Pour aller plus loin, vous avez la présentation approfondie et pour plus de bonnes pratiques, consultez « Création de prompts et sécurité ». Merci de votre attention !