Construire son propre Siri en local et on-device, sans cloud

• Comment créer soi-même un assistant vocal personnel exécuté on-device, sans dépendre d’une API LLM ni du cloud
• Cet assistant comprend le langage naturel, effectue des appels de fonctions personnelles et fonctionne uniquement en local, ce qui permet de garantir une confidentialité totale
• Pour cela, le modèle LLaMA 3.1 est affiné avec LoRA, puis Whisper est utilisé pour convertir la voix en texte, avant d’interpréter le tout comme des commandes exécutées directement sur l’appareil
• Le projet se compose de génération du dataset → fine-tuning → connexion de l’interface vocale → tests et déploiement, et il est proposé sous la forme d’une mini-série gratuite en 5 parties
• L’article met en garde contre l’idée reçue selon laquelle « exécution on-device = simplicité » et souligne que même en local, une approche MLOps et un contrôle qualité rigoureux sont indispensables

---

Pourquoi construire maintenant un assistant vocal local ?

• Discuter avec ChatGPT est utile, mais faut-il vraiment envoyer au cloud jusqu’aux commandes les plus simples ?
• Si le modèle est installé directement sur votre appareil, vous gagnez à la fois en vitesse, en confidentialité et en contrôle
• C’est particulièrement utile dans des environnements sensibles comme la santé, le droit ou les outils internes d’entreprise

Vue d’ensemble de l’architecture

Composants du projet

1. Reconnaissance vocale (Whisper) → conversion en texte
2. LLM (LLaMA 3.1) → interprétation des commandes
3. Exécuteur de fonctions → exécution de fonctions réelles comme lock_screen()

Part 1 : architecture et approche MLOps

Pourquoi le MLOps est nécessaire, même en local

• Des problèmes de model drift, de changements de prompts, de fiabilité du dataset et de manque de logs pour le débogage subsistent
• Penser que « le local suffit » est risqué, et une approche structurée est nécessaire

Développement en ligne vs exécution hors ligne

• Le développement (fine-tuning, génération de données) se fait dans le cloud, tandis que l’exécution se fait en local
• Le cœur du MLOps consiste à séparer clairement ces étapes et à les gérer de manière systématique

Génération du dataset (Dataset Generation Flow)

• Il ne s’agit pas simplement de collecter des prompts, mais de concevoir des schémas structurés d’appels de fonctions et des requêtes conversationnelles
• Création d’un dataset de haute qualité couvrant des formulations variées, des intentions diverses et des cas d’échec

Points clés

• lock_screen() → inclure différentes formulations naturelles comme « verrouille l’écran »
• Vérifier, via un moteur de validation automatique, que la sortie correspond bien à la forme attendue

Fine-tuning (Instruction Tuning for Function Calling)

• Affinage d’un petit modèle (méthode SFT) pour assurer une correspondance précise des commandes
• Utilisation d’outils de production tels que Unsloth, W&B et l’export au format GGUF

Objectifs

• Convertir LLaMA 3.1 8B en un modèle 4bit pouvant fonctionner en local
• Viser un allègement suffisant pour cibler jusqu’au Raspberry Pi

Intégration du modèle et exécution réelle

• Whisper convertit l’entrée vocale en texte
• Le LLM fine-tuné interprète la commande
• Connexion à un exécuteur de fonctions API local (lock_screen(), get_battery_status(), etc.)

Résultat

• Possibilité de faire fonctionner un assistant vocal en temps réel
• Aucun réseau nécessaire, aucune fuite de données personnelles, contrôle total pour l’utilisateur

Gestion des risques lors de l’étape hors ligne

• Nécessité de tester sur divers appareils et systèmes d’exploitation
• Mise en place indispensable d’un système de logs (soumission manuelle sur opt-in)
• Avant le déploiement officiel, stress tests et retours utilisateurs pour détecter les problèmes au plus tôt

Plan à venir

• Le cours suivant portera sur un atelier pratique de génération de dataset pour les appels de fonctions
• Construction structurée d’un dataset dédié à l’apprentissage du mapping entre commandes en langage naturel et appels API
• Scraping interdit, uniquement simulation à base de prompts et données validées automatiquement

Conclusion

• Les systèmes d’IA locaux paraissent simples, mais leur stabilité et leur qualité exigent une gestion d’un niveau plus élevé
• Comme ils ne dépendent ni des logs cloud ni des hotfixes, ils exigent davantage de fiabilité et de responsabilité
• Il faut donc appliquer dès le départ une approche MLOps et une conception structurée

> « L’ère des véritables assistants IA centrés sur la confidentialité et pensés local-first est arrivée »
> Le prochain épisode commencera un atelier concret sur la génération de datasets pour le mapping commandes-fonctions.

[asheswook]

La 3.1 est difficile à utiliser pour les utilisateurs non anglophones, et avec la 3.3 ou la 4 le coréen devrait aussi être possible, mais si on veut faire tourner ça on-device, vu que pour les langues non anglaises il faut au moins du 32b ou plus pour que ça ait un vrai intérêt, ça semble encore difficile pour l’instant...

[GN⁺]

Réactions sur Hacker News

• J’aime beaucoup cette idée et j’aimerais la construire moi-même, mais mon expérience avec les petits modèles de Whisper en local a été plutôt décevante. Je me demande si quelqu’un a obtenu des résultats assez bons pour ce type d’usage. Il est possible aussi que mon micro n’ait pas été de bonne qualité.
  • Il faut vraiment revérifier l’état du micro. Dans notre entreprise, on utilise Whisper pour transcrire et traduire des réunions entières en temps réel, et les performances sont excellentes.
  • Je suis curieux de savoir quel modèle vous utilisez. En général, j’utilise le modèle large sur GPU. C’est rapide et ça fonctionne vraiment bien. Il faut toutefois noter qu’il ne peut reconnaître qu’une seule langue à la fois. Si on ne la précise pas, il passe en détection automatique. Les petits modèles sont logiquement moins performants et ne prennent souvent en charge que l’anglais. Pour moi, le modèle large offre les meilleures performances, mais il faut absolument du matériel GPU pour obtenir une vitesse réellement exploitable. C’est pareil avec faster-whisper ou insanely-fast-whisper.
• Ce serait vraiment bien si c’était un produit ou une appli qu’on puisse simplement installer et utiliser. J’aimerais pouvoir tout configurer et entraîner facilement via une UI. Malgré tout, grâce à ce guide, j’ai l’impression de pouvoir construire ce que je veux, donc un grand merci.
• Excellente ressource, je voulais simplement dire merci. Je n’ai pas encore tout suivi jusqu’au bout, mais je me demande si ce modèle tourne vraiment bien sur iPhone. Mon téléphone de 9 ans faisait bien tourner le modèle Qwen 0.6B avec ollama, mais les autres modèles étaient trop lents pour offrir une expérience utilisateur acceptable.
  • Ah, il s’agissait d’un téléphone de 9 ans. J’ai cru un instant qu’un enfant de primaire déployait lui-même des modèles, et ça m’a sidéré. À cet âge-là, j’apprenais encore mes tables de multiplication.
  • D’après la documentation de MLC, des modèles allant jusqu’à 8B peuvent tourner sur iOS. Mais 1 à 3B semble plus réaliste. Référence : https://llm.mlc.ai/docs/deploy/ios.html#bring-your-own-model
• Pourquoi faudrait-il que ce texte ait été écrit par un LLM ? Je me le demande.
  • Ce style de résumé, avec une mise en forme très marquée et (!) tous les paragraphes sous forme de listes à puces, me perturbe énormément. Surtout dans les textes longs, l’écran paraît chargé et monotone à la fois, ce qui nuit à la lisibilité.
• Récemment, et j’ai peut-être raté l’annonce, j’ai découvert que Siri fonctionnait en local au moins pour certaines commandes. Par exemple, il suffit de mettre l’Apple Watch en mode avion puis de demander un minuteur ou un rappel.
  • Siri disposait déjà de fonctions hors ligne limitées au moins depuis iOS 15, mais la plupart des utilisateurs ne s’en rendaient pas compte, parce que la majorité des commandes Siri nécessitent une connexion réseau.
• Je me demande pourquoi Apple n’a pas analysé les données pour prévoir des gestionnaires codés en dur pour, disons, les 1000 cas d’usage les plus fréquents.
  • En réalité, ils le font déjà, mais c’est très lent. Ils ajoutent bien des fonctions liées à la luminosité et à l’alimentation, mais sans vraiment indiquer ce qui peut être utilisé hors ligne. Les utilisateurs doivent passer en mode avion et tout tester eux-mêmes pour le découvrir. L’expérience utilisateur est très mauvaise.
• Beau projet et bonne synthèse.
• Je me demande si Apple autorise le remplacement de Siri par un autre assistant. Sur Android, les assistants autres que ceux de Google ont longtemps été limités pour l’écoute en arrière-plan, les touches physiques, les gestes ou les raccourcis. Je ne sais pas si Google Assistant conserve encore ce traitement de faveur, mais ce ne serait pas très surprenant.
  • Une partie du problème vient du coprocesseur distinct (AOP) qui traite le mot d’activation « hey siri ». Le modèle est aussi compilé dans le firmware. Ce n’est pas techniquement impossible, mais il ne suffit pas de laisser tourner une appli Google en arrière-plan, car les gestes surviennent alors que l’AP est en veille. On pourrait lancer une appli d’assistant via le bouton d’action latéral, par exemple, mais l’expérience ne serait pas satisfaisante (l’appli pourrait ne pas être ouverte, etc.). Voir aussi : https://machinelearning.apple.com/research/hey-siri
  • Le nouveau bouton d’action permet tout de même de lancer assez facilement une appli d’assistant alternative via un raccourci personnalisé.
  • C’est aussi comme ça que fonctionne Perplexity.
• Cela fait un an et demi que j’utilise fidèlement chatGPT sur iPhone, et Siri me frustre tellement que je le supporte de moins en moins. Je me demande quand OpenAI, avec l’aide de Microsoft, sortira un téléphone GPT capable de concurrencer l’iPhone. J’en ai assez de cet iPhone ennuyeux. Il me faut un téléphone GPT où GPT remplace tout directement depuis l’écran de verrouillage. J’attends ça avec impatience. J’espère qu’ils en développent déjà un en secret.