Blueprints | Mozilla.ai

Qu’est-ce que Mozilla.ai Blueprints ?

Mozilla.ai Blueprints est un ensemble de workflows d’IA open source maintenu par Mozilla.ai, qui aide les développeurs à combiner des modèles, des bibliothèques open source, des paramètres de configuration, une ligne de commande et des interfaces de démonstration pour créer des projets exécutables. Il s’adresse aux développeurs qui commencent à travailler avec les applications d’IA, ainsi qu’aux équipes d’ingénierie souhaitant étudier les choix techniques spécifiques.

Blueprints n’est ni une application de messagerie unifiée, ni une plateforme de hébergement de modèles, ni une API commerciale. Le site est principalement destiné à la découverte et à l’explication ; chaque flux de travail est hébergé dans un répertoire GitHub indépendant, et les utilisateurs doivent le exécuter localement, dans des conteneurs, Codespaces, Colab ou des environnements de démonstration, conformément aux instructions du projet.

L’idée centrale de Blueprint

• Utilisable directement : fournit un point de départ complet, allant de l’installation et de la configuration aux résultats de fonctionnement, plutôt que de se contenter de code conceptuel.
• Extensible : les développeurs peuvent remplacer les modèles, les prompts, les sources de données, l’interface et les composants de traitement.
• Modélisation : le projet doit adopter autant que possible des structures de dossiers, des configurations, une ligne de commande, des documents et des méthodes de test cohérents.
• Propulsion communautaire : les utilisateurs peuvent Forker, soumettre des problèmes, contribuer avec des correctifs ou proposer de nouveaux flux de travail.
• Priorité au logiciel open source : privilégier des modèles et outils transparents et vérifiables pour réduire la dépendance aux services fermés.
• Orientation pratique : Chaque Blueprint est axé sur des tâches concrètes telles que la documentation, la voix, l’aspect visuel, les recommandations ou le fine-tuning.

Que propose Blueprints Hub ?

Workflow open source représentatif

Fonction principale

Implémentation de référence bout en bout

Chaque Blueprint relie plusieurs composants open source pour former un processus complet, qui comprend généralement le traitement des entrées, l’inférence du modèle, la conversion des sorties et une interface interactive. Par rapport aux tutoriels ne contenant que quelques lignes de code d’exemple, il est plus adapté pour comprendre comment les composants travaillent ensemble.

Contrôle de l’IA locale et des données

Plusieurs workflows privilégient le fonctionnement des modèles et des données sur l’appareil du utilisateur lui-même, par exemple pour les podcasts à partir de documents, les questions-réponses basées sur des documents et les algorithmes de chronologie personnelle. Le fait d’être entièrement hors ligne dépend encore du dépôt spécifique, du téléchargement des modèles, de la télémétrie, des sources de données externes et du fait que l’utilisateur ait activé ou non les services cloud.

Les modèles et les outils sont interchangeables

Blueprints met l’accent sur la personnalisation : les développeurs peuvent modifier les paramètres ou le code afin de remplacer les modèles linguistiques, les modèles vocaux, les prompts, les méthodes d’embedding et l’interface. Après remplacement, il est nécessaire de valider à nouveau l’interface, les licences, le matériel, les performances, la qualité des résultats et les limites de sécurité.

Interface de présentation et ligne de commande

Les normes officielles exigent que Blueprint fournisse des démonstrations en Streamlit, Gradio ou Jupyter Notebook, ainsi qu’un support en ligne de commande. Les différentes interfaces s’adressent à l’expérience utilisateur, au développement et à l’automatisation, mais tous les répertoires ne proposent pas les mêmes commandes.

Configuration et structure du projet

Les flux de travail exposent généralement les modèles, les données, les prompts et les paramètres de exécution via des fichiers de configuration, et utilisent pyproject.toml pour gérer les dépendances du projet Python. Une structure unifiée réduit la complexité de lecture, mais les développeurs doivent néanmoins verrouiller les versions pour les projets en production et générer une liste des dépendances.

Tests, qualité du code et documentation

Le modèle Blueprint comprend des tests unitaires, des vérifications avant soumission, des workflows automatisés et une structure de documentation MkDocs. Le modèle ne peut fournir qu’un point de départ en termes de qualité ; la couverture de test, les tests d’intégration, les scans de sécurité et l’observabilité en production doivent encore être complétés par les responsables du projet.

Décisions techniques et justification des compromis

Certaines pages de détails expliquent les raisons du choix du modèle, de la bibliothèque et de l’architecture, ainsi que les solutions abandonnées et les compromis connus. Les développeurs peuvent ainsi déterminer si la confidentialité locale, la vitesse, la qualité et le coût du matériel correspondent à leurs objectifs.

Structure du modèle de plan

Exécuter les tutoriels Blueprint existants

1. Dans le Hub, sélectionnez les workflows par tâche, type d’entrée, complexité, état et conditions matérielles.
2. Ouvrez le dépôt correspondant et lisez attentivement le README, la licence, la fiche du modèle ainsi que les problèmes connus.
3. Vérifier les exigences en matière de système d’exploitation, de version Python, de mémoire, de disque, de GPU, de Docker et de comptes externes.
4. Fork ou téléchargez le dépôt, puis installez les dépendances dans un environnement virtuel isolé, un conteneur ou un Codespace.
5. Utilisez un échantillon minimal non sensible pour effectuer le démarrage rapide officiel, sans importer de données de production dès le début.
6. Vérifier la sortie, les journaux, le cache, le téléchargement des modèles et l’emplacement d’écriture des fichiers locaux.
7. Modifier la configuration et tester le modèle, les suggestions, la langue, les performances et l’utilisation des ressources un par un.
8. Après avoir testé dans l’entrepôt, décider ensuite si intégrer le code dans sa propre application.

Créer un projet à l’aide d’un modèle

1. Créez un nouveau dépôt à partir du modèle Blueprint officiel, et définissez un cas d’usage clair et unique.
2. Redénommez les exemples de paquets, les titres de projet et le contenu de remplacement, puis indiquez la version réelle de Python ainsi que les exigences en matière de matériel.
3. Mettre en œuvre le flux de travail principal dans le répertoire src, en séparant clairement les appels aux modèles, le traitement des données et la logique de sortie.
4. Exposer les modèles, les chemins et les paramètres réglables via des fichiers de configuration, afin d’éviter d’insérer des identifiants dans le code.
5. Fournir une CLI exécutable, et ajouter des démonstrations Streamlit, Gradio ou des notebooks.
6. Écrire des tests pour les scénarios normaux, anormaux, limites et hors ligne, et exécuter des vérifications pré-submission.
7. Améliorer le README, les diagrammes d’architecture, l’installation, les exemples, la licence, ainsi que les risques et la résolution des problèmes.
8. Après avoir reproduit l’installation dans plusieurs environnements propres, soumettez-la à la communauté de Blueprints pour évaluation.

Workflow de conversion de documents en podcast

1. Choisissez un document d’entrée ne contenant pas d’informations sensibles et dont les droits sont clairement définis, puis vérifiez le texte qui peut être extrait.
2. Installez les modèles locaux, les composants de conversion texte en parole et les dépendances de démonstration selon les instructions du entrepôt.
3. Laissez les étapes de prétraitement extraire et nettoyer le texte, en vérifiant que les titres, annotations et tableaux ne sont pas perdus.
4. Un petit modèle linguistique local convertit le contenu en script de dialogue à deux personnes.
5. Vérifier manuellement si le script contient des erreurs factuelles, des attributions erronées ou omet des restrictions importantes.
6. Générer des enregistrements audio de différents locuteurs à l’aide d’un modèle de conversion texte en parole et vérifier la prononciation.
7. Enregistrer les scripts, les configurations, les versions des modèles et l’audio, afin que les résultats puissent être générés à nouveau.

Processus de question-réponse pour les documents locaux

1. Déterminez les fichiers PDF, pages web, texte, Word ou Markdown pris en charge, et supprimez les copies sensibles.
2. Analyser le document et le diviser par titre ou structure, vérifier si le PDF scanné nécessite du OCR.
3. Enregistrer pour chaque fragment le nom du document, le chapitre, le numéro de page et d’autres métadonnées traçables.
4. Après avoir saisi la question, laissez le processus sélectionner le chapitre le plus pertinent ou effectuer une recherche.
5. Restreignez le modèle pour qu’il ne réponde qu’en se basant sur le contenu sélectionné, et conservez l’emplacement d’origine dans l’interface.
6. Utiliser des questions avec des réponses connues pour tester la précision, le refus de répondre, les cas multi-documents et les textes longs.
7. Il est nécessaire d’ajouter des mécanismes de contrôle d’accès, d’audit, de chiffrement et de mise à jour au moment de la production et de l’utilisation.

Processus de reconnaissance vocale et d’ajustement fin

1. Sélectionnez la transcription de base ou le Blueprint d’ajustement de modèle, et vérifiez les conditions CPU, GPU et disque.
2. Préparer des fichiers audio légalement autorisés, des transcriptions précises, des étiquettes linguistiques et des divisions d’entraînement et de validation.
3. Commencez par utiliser le modèle existant pour établir une ligne de référence pour le taux d’erreur de mots, la vitesse et l’utilisation des ressources.
4. Nettoyer l’audio et le texte pour éviter d’introduire des informations personnelles sensibles ainsi que des étiquetages erronés dans l’apprentissage.
5. Définir le modèle, le chemin des données, le nombre d’itérations et l’emplacement de sauvegarde dans la configuration.
6. Exécuter l’entraînement ou la transcription locale, et comparer les résultats sur un ensemble de test inconnu.
7. Enregistrez le modèle, l’ensemble de données, la licence, les indicateurs et les restrictions avant de publier les poids.

À qui s’adresse-t-il

• Développeur débutant en IA : apprendre, à travers des projets complets, comment relier les modèles, les données, l’interface et la configuration.
• Ingénieur en application : commencer par remplacer les modèles avec du code exécutable et valider de nouvelles idées de produits.
• Chercheurs : Comparaison des choix pratiques entre les modèles locaux, l’apprentissage fédéré, ainsi que les solutions vocales et visuelles.
• Enseignants et étudiants : Utiliser Blueprint comme base pour des cours d’IA open source, des expériences ou des devoirs de projet.
• Équipe sensible à la vie privée : explorer des méthodes pour traiter localement les documents, les données vocales et les données de recommandation.
• Mainteneur open source : contribution de correctifs, de documentation, d’adaptations de nouveaux modèles ou de nouveaux Blueprints complets.
• Équipe prototype : valider rapidement la faisabilité du flux de travail avant de décider d’une refonte à l’échelle de production.

Scénarios d'utilisation typiques

• Transformer des matériaux de recherche, des comptes rendus de réunions ou des notes de cours en podcasts locaux.
• Créer un assistant de questions-réponses pour documents personnels qui ne envoie pas les données à des API tierces.
• Convertir l’enregistrement en texte, avec des sous-titres JSON ou SRT marqués de timestamps.
• Ajuster le modèle de reconnaissance vocale de la classe Whisper à l’aide de données linguistiques propres.
• Permettre à plusieurs propriétaires de données d’essayer le micro-ajustement fédéré sans centraliser les données brutes.
• Exécuter une expérience de proxy Python via WebAssembly dans le navigateur.
• Étude des recommandations de chronologie sociale calculées localement et contrôlées par l’utilisateur.
• Publier de nouvelles workflows d’IA open source auprès de la communauté à l’aide d’un template unifié.

Avantages du produit

• Passer d’un exemple de modèle unique à un processus complet incluant l’entrée, le traitement, l’inference, l’interface et la sortie.
• Le code du projet est public, ce qui facilite le choix des techniques d’audit, les dépendances et la mise en œuvre pratique.
• Un modèle unifié réduit les différences de catalogues et de documents entre différents flux de travail.
• Plusieurs cas d’usage sont préférablement exécutés localement, ce qui favorise le contrôle des données et les expériences hors ligne.
• Fournit différentes options d’accès telles que des démos hébergées, Codespaces, Colab, Docker ou exécution locale.
• Couvrant divers domaines tels que le texte, la voix, l’aspect visuel, les recommandations, les agents et l’apprentissage fédéré.
• Encourager le remplacement de modèles, de configurations et de composants, afin de ne pas enfermer les développeurs auprès d’un seul fournisseur.
• Le modèle est sous licence Apache-2.0 et comprend l’infrastructure pour les tests, la documentation et les directives de contribution.

Restrictions d'utilisation et précautions

• Un blueprint est généralement une implémentation de référence ou un prototype, et n’équivaut pas à un produit en production disposant d’SLA, d’audits de sécurité et d’opérations.
• Les exigences en Python, en mémoire, en disque, en GPU et en système varient considérablement d’un projet à l’autre.
• Certaines ressources de démonstration hébergées sont limitées ; leur vitesse, la taille des modèles et leur disponibilité ne reflètent pas les résultats locaux.
• L’exécution locale peut encore nécessiter une connexion Internet pour télécharger des modèles, des ensembles de données, des conteneurs et des dépendances Python.
• Le site privilégie les outils open source, mais autorise également l’examen de modèles ou d’outils qui ne respectent pas pleinement les normes OSI lorsqu’ils présentent une valeur évidente.
• Les licences de code, les poids des modèles, les ensembles de données, les polices, les sons et les droits sur le contenu de sortie doivent être vérifiés séparément.
• Les modèles LLM, vocaux et visuels génèrent des erreurs, des biais, des hallucinations et des sorties imprévisibles.
• Après Fork, il est nécessaire de gérer soi-même les mises à jour des dépendances, les correctifs de sécurité, les versions des modèles et la compatibilité.
• La compatibilité CPU n’est qu’une recommandation ; tous les Blueprints ne peuvent pas être exécutés rapidement sur un ordinateur ordinaire.
• Ouvrir directement l’interface de présentation au réseau public peut manquer d’authentification, de limitation du débit, d’isolation et d’en-têtes de sécurité.

Frais et coûts d’exploitation

Le Mozilla.ai Blueprints Hub, le code open source et les modèles Blueprint ne comportent pas de frais de abonnement commercial ; les utilisateurs peuvent obtenir le code conformément aux licences open source correspondantes. Obtenir le code gratuitement ne signifie pas que les coûts d’exécution sont nuls : le téléchargement des modèles, l’utilisation de GPU, les serveurs cloud, le stockage, la bande passante et la maintenance peuvent encore engendrer des frais.

Plateforme et mode de fonctionnement

Données, vie privée et sécurité

Blueprints met l’accent sur la priorité locale et le contrôle, mais les limites de la confidentialité dépendent des flux de travail spécifiques, des paramétrages et des méthodes de déploiement. Dès que la démo hébergée, Colab, un entrepôt de modèles externe, le stockage cloud ou une API tierce est activé, les données peuvent quitter le dispositif local.

Le code open source peut être examiné, mais cela ne signifie pas automatiquement qu’il n’y a pas de vulnérabilités, de dépendances malveillantes ou de valeurs par défaut non sécurisées. Avant le déploiement, il convient de vérifier le code source, l’arbre des dépendances, les fichiers de modèle, les conteneurs, les requêtes réseau, la télémétrie, le cache et les dossiers de sortie.

• Utilisez d’abord des échantillons fictifs ou masqués pour confirmer quels données le flux de travail lit, écrit et envoie.
• Le téléchargement des modèles et des ensembles de données doit enregistrer le canal, la version, la valeur de vérification et la licence.
• Les clés, les tokens et les mots de passe de base de données ne doivent pas être enregistrés dans un repository, un Notebook ou des exemples de configuration.
• L’application de démonstration doit intégrer une authentification, un contrôle du trafic, une validation des entrées et un isolement des fichiers lorsqu’elle est déployée sur le réseau public.
• Définir des limites de taille, de format, de chemin et de parsing pour les fichiers téléchargés, afin de prévenir les documents malveillants.
• La génération de résultats audio, textuels et visuels doit conserver les enregistrements du modèle, des paramètres de configuration et de la révision humaine.
• L’apprentissage fédéré réduit la transmission des données brutes, mais les gradients, les mises à jour et le modèle peuvent encore divulguer des informations.
• Après le fork du projet, il convient d’activer les mises à jour des dépendances, les vérifications statiques, le balayage des secrets et les processus de correction des vulnérabilités.

API, SDK et situation du logiciel open source

Le Blueprints Hub ne dispose pas d’une API de raisonnement unifiée ni d’un SDK officiel ; chaque workflow fonctionne via son propre paquet Python, sa CLI, une application de démonstration ou des interfaces compatibles locales. Par exemple, le blueprint de transcription vocale peut lancer un service Speaches compatible OpenAI en local, mais cela ne signifie pas que le Hub offre une API hébergée.

Le modèle Blueprint est publié dans l’organisation GitHub officielle de Mozilla.ai, sous la licence Apache-2.0, et comprend des projets Python, des démonstrations, de la documentation, des tests ainsi que des fichiers pour les contributions. Le Blueprint officiel met généralement également son code source à disposition, mais il faut examiner séparément les licences de chaque répertoire, modèle, ensemble de données et dépendance.

Limites des licences open source

Liste de contrôle pour la mise en production

• Déterminer si Blueprint n’est qu’un prototype, un outil interne ou un service officiel destiné aux clients.
• Fixer les versions du code, des dépendances, des modèles, des données et des conteneurs, et conserver une liste de reproductibilité.
• Établir des références réalistes pour la qualité, les délais, la mémoire, le débit, le taux d’erreurs et les coûts.
• Authentification supplémentaire, autorisation, isolation des locataires, audit, chiffrement et suppression des données sensibles.
• Définir des stratégies claires pour les erreurs de modèle, la sécurité du contenu, les droits d’auteur et la mise à niveau manuelle.
• Remplacer le serveur de démonstration, ajouter des files d’attente, une limitation du trafic, un suivi, des sauvegardes et une reprise après sinistre.
• Vérifiez chaque licence, signature, divulgation du code source et conditions commerciales du modèle.
• Mettre en place des processus de mise à jour, d’annonces de sécurité, de correction de vulnérabilités et de rollback.
• Faire effectuer des tests d’accessibilité et d’utilisabilité par les utilisateurs cibles, plutôt que de se contenter de vérifier le fonctionnement technique.

Informations de base

Indice de recommandation

L’indice de recommandation global est de 4,6 sur 5. Mozilla.ai Blueprints convient aux développeurs qui souhaitent comprendre les workflows d’IA locale, de reconnaissance vocale, de documents et d’apprentissage fédéré grâce à du code complet et modifiable, et il permet également de réduire considérablement le temps nécessaire pour l’exploration de prototypes.

Ce n’est pas une plateforme de production sans entretien ; le niveau de maturité des projets et les exigences en ressources varient, et la stack open source présente également des complexités en termes de dépendances et de licences. Avant son utilisation dans des opérations commerciales officielles, il convient d’achever la restructuration en matière de sécurité, de performance, de qualité, de licences et de maintenance.

Questions fréquentes

Mozilla.ai Blueprints est-il un outil d’IA en ligne ?

Il s’agit principalement d’un répertoire de workflows open source et de ressources de développement, et non d’une application en ligne unique. Certaines Blueprints disposent de démonstrations hébergées, mais leur utilisation officielle nécessite généralement d’exécuter soi-même le code.

Les plans sont-ils gratuits ?

Hub et les entrepôts publics ne facturent pas de frais d’abonnement ; le code peut être obtenu sous licence. Les calculs, les services cloud, le stockage, les modèles et la maintenance peuvent toutefois engendrer des coûts.

Faut-il savoir programmer ?

Des compétences en Python, en terminal et en gestion des dépendances sont nécessaires. Les démos ou notebooks hébergés peuvent faciliter l’accès, mais la modification et le déploiement restent des tâches de développement.

Peut-on l’exécuter sur un ordinateur ordinaire ?

Certains projets privilégient le support de la CPU et des appareils locaux, tandis que d’autres workflows de formation, visuels ou de modèles volumineux nécessitent plus de mémoire, d’espace disque ou de GPU. Il convient de consulter les exigences spécifiques de chaque projet.

Tous les Blueprint sont-ils entièrement hors ligne ?

De nombreux projets prennent en charge le traitement local, mais le téléchargement des modèles, les sources de données, la démo hébergée, Colab ou les API optionnelles peuvent encore nécessiter une connexion à Internet. Il faut vérifier la configuration et les requêtes réseau pour savoir s’il s’agit d’un mode entièrement hors ligne.

À quoi sert le modèle Blueprint ?

Il fournit des paquets Python unifiés, des démonstrations, des tests, de la documentation, des vérifications pré-submission et une structure de configuration de projet pour aider les développeurs à démarrer de nouveaux Blueprint. La logique métier doit encore être implémentée manuellement.

Une API unifiée est-elle fournie ?

Non. Chaque projet fonctionne via sa propre CLI, du code Python, une application de démonstration ou une interface locale ; le Hub ne propose pas d’API unique pour l’hébergement du raisonnement.

Les Blueprint sont-ils open source ?

Oui. Selon les sources officielles, chaque Blueprint est hébergé sous licence open source, et le Template est soumis à la licence Apache-2.0 ; il reste néanmoins nécessaire de vérifier les licences spécifiques des dépôts, des modèles et des données.

Peut-on l’utiliser à des fins commerciales ?

Cela dépend de toutes les licences applicables au code, aux modèles, aux ensembles de données et aux matériaux d’entrée utilisés. On ne peut pas en déduire, sur la seule base de la licence Apache-2.0 du Template, que l’ensemble du flux de travail peut être utilisé à des fins commerciales sans restriction.

Est-il adapté pour une mise en production directe ?

En général, il ne faut pas déployer directement une version de démonstration. Pour une utilisation en production, il est nécessaire d’ajouter des authentifications supplémentaires, des permissions, une isolation des entrées, un contrôle du trafic, une surveillance, des sauvegardes, des audits de sécurité et des niveaux de service.

Comment contribuer à de nouveaux Blueprint ?

On peut commencer par un modèle officiel qui fournit une structure de code normalisée, des paramètres de configuration, une CLI, des démonstrations ou des notebooks, un README complet ainsi qu’une licence, puis soumettre la demande d’inclusion via le processus de soumission du Hub.

Les utilisateurs chinois peuvent-ils l’utiliser ?

Les sites web et les documents sont principalement en anglais, mais certains modèles et données vocales prennent en charge plusieurs langues. La qualité en chinois dépend du modèle choisi, des données, de la segmentation des mots, de la police de caractères et des ressources vocales.