Plateforme · AI Language
LLM, récupération et voix sur appareil.
MOS4 AI Language exécute un modèle de langage quantifié, un pipeline RAG ancré et une reconnaissance vocale multilingue entièrement sur l'appareil. Le cloud est optionnel. Chaque réponse porte un enregistrement de provenance complet.
Pilier 1
LLM sur appareil, offline-first.
Un petit modèle de langage quantifié s'exécute entièrement sur l'appareil. L'accès au cloud est optionnel, derrière trois verrous indépendants. Aucune dépendance cloud pour l'inférence principale.
Modèle de référence : SmolLM2 360M (4 bits quantifié)
S'exécute sur silicium compute-class avec environ 280 Mo d'empreinte RAM. Des modèles plus grands ou plus petits peuvent être substitués sans modification du code — dans les limites de RAM et de latence. Il s'agit d'un critère d'acceptation pour la configuration de référence.
Triple verrou cloud optionnel
Le basculement cloud nécessite une configuration explicite à trois couches indépendantes : le prompt système doit autoriser l'escalade cloud, la liste d'autorisation des outils MCP doit inclure le connecteur cloud, et la politique réseau de l'appareil doit autoriser les requêtes sortantes. Les trois verrous doivent être ouverts. La posture par défaut est hors ligne.
Pilier 2
RAG documenté avec verrou de refus.
Génération augmentée par récupération avec un seuil de similarité calibré. En dessous du seuil, le système refuse de répondre plutôt que d'halluciner.
Seuils de similarité cosinus
Premier chunk : ≥ 0,55. Moyenne des trois premiers : ≥ 0,45. Ce sont des critères d'acceptation calibrés sur un benchmark de 50 questions. Les seuils sont configurables par déploiement.
Verrou de refus
Critère d'acceptation : ≥ 80 % de taux de refus sur les questions hors corpus, ≤ 10 % de faux refus sur les questions en corpus. « Je n'ai pas d'information sur ce sujet » est la bonne réponse quand la récupération échoue.
Modèle d'embedding BGE-small
Le modèle d'embedding de référence est BGE-small, qui s'exécute sur l'appareil. L'index vectoriel est construit à partir des documents fournis par le client pendant la phase d'intégration et mis à jour via OTA quand le corpus change.
Pilier 3
Défense en quatre couches contre l'injection de prompt.
Critère d'acceptation : ≥ 95 % de taux de déflexion sur une suite red-team de 20 prompts. La défense est structurée en couches : entrée, prompt système, corpus et liste d'autorisation des outils.
Action MEP de nettoyage de l'entrée
L'entrée utilisateur passe par une action de règle d'événement MEP qui supprime les motifs d'injection connus avant que le texte n'atteigne le LLM. Liste de refus configurable, rechargeable à chaud sans redémarrage.
Blindage du prompt système
Le modèle de prompt système est scellé cryptographiquement au moment du déploiement. Les tentatives de le remplacer ou d'y ajouter du contenu via l'entrée utilisateur sont bloquées au niveau de la couche d'inférence.
Liste de blocage lors de la construction du corpus
Lors de la construction du corpus, le contenu correspondant à une liste de blocage configurable est exclu de l'index vectoriel. L'injection indirecte via des documents empoisonnés ne peut pas atteindre la récupération.
Liste d'autorisation des outils MCP
Le modèle ne peut appeler que les outils explicitement listés dans la liste d'autorisation MCP. Aucune escalade d'outil n'est possible sans modification de la configuration opérateur. La liste par défaut est minimale.
Pilier 4
Manifeste d'audit par réponse.
Chaque réponse émet un enregistrement de provenance complet sur l'EventBus. Rétention glissante de six mois. Conçu comme preuve pour les obligations de l'AI Act européen §10 et §13.
Topic EventBus : audit.answer.manifest.{session_id}
Chaque réponse publie : IDs de chunks utilisés dans la récupération, chemins de documents, version du modèle, scores de similarité cosinus, motif de refus (le cas échéant) et un horodatage. La provenance est complète et lisible par machine.
Rétention glissante de six mois
Les enregistrements sont conservés six mois par défaut et accessibles via la pile d'observabilité. La fenêtre de rétention est configurable. Les enregistrements sont structurés pour l'export vers des outils de conformité.
Voir la posture AI Act européen pour le mapping de conformité complet.
Pilier 5
Voix industrielle multilingue.
Whisper-tiny multilingue avec enrichissement obligatoire du vocabulaire STT. Critère d'acceptation : WER ≤ 15 % à 70–75 dB de bruit de fond industriel.
Whisper-tiny sur appareil
La reconnaissance vocale s'exécute sur l'appareil avec Whisper-tiny multilingue. Aucune dépendance cloud STT. L'audio ne quitte jamais l'appareil par défaut.
Enrichissement obligatoire du vocabulaire STT
Les termes spécifiques au domaine — numéros de pièce, codes de processus, noms de produits — sont injectés dans le vocabulaire STT au moment du déploiement. La reconnaissance du vocabulaire spécifique au client est une exigence d'intégration, pas une option.
TTS en streaming avec Piper
La synthèse vocale utilise Piper pour la synthèse sur appareil. La cible de latence pour le premier audio est d'environ 200–300 ms. Piper prend en charge plusieurs langues et voix sans dépendance cloud.
Explorer davantage
Capacités associées.
AI Funnel — moteur d'intelligence visuelle
Déclarez votre pipeline IA vision en TOML. Cloud Connect ré-entraîne, package et déploie par OTA. Caméra vers NPU sans copies de pixels CPU.
AI Vision — caméra et suivi de pose
Cinq entrées caméra, recadrage et redimensionnement GPU, inférence NPU sur silicium AI-class, et suivi de pose visuel + inertiel. Le pendant vision de l'intelligence.
Conformité · CRA et AI Act européen
Gestion des vulnérabilités CRA, conformité radio RED, SBOM et la posture AI Act couvrant les preuves du manifeste d'audit et les verrous du modèle de menace.
Matériel — paliers silicium
AI Language s'exécute sur silicium compute-class et AI-class. Voir la page matériel pour les définitions des paliers, les facteurs de forme et les options de connectivité.
SDK — surface développeur en six langages
Étendez AI Language avec des actions MEP personnalisées, des outils MCP et des constructeurs de corpus RAG en utilisant le SDK en six langages incluant Lua 5.4.
Solution Kiosk
Kiosk voix-first avec réponses ancrées, verrou de refus et manifeste d'audit par réponse. AI Language comme plateforme pour une solution verticale complète.
FAQ
Questions fréquentes
-
Le LLM nécessite-t-il une connexion cloud ?
Non. Le LLM s'exécute entièrement sur l'appareil par défaut. L'accès au cloud est optionnel, derrière trois verrous indépendants, et doit être explicitement configuré. Le fonctionnement hors ligne est la posture par défaut.
-
Comment fonctionne le verrou de refus du RAG ?
Chaque requête de récupération vérifie la similarité cosinus avec le corpus indexé : le premier chunk doit atteindre ≥ 0,55, et la moyenne des trois premiers doit atteindre ≥ 0,45. En dessous du seuil, le système répond « Je n'ai pas d'information sur ce sujet » plutôt que d'halluciner. Les seuils sont calibrés sur un benchmark de 50 questions.
-
Quelle précision vocale puis-je attendre dans des environnements industriels ?
Le critère d'acceptation est un WER ≤ 15 % à 70–75 dB de bruit de fond — niveaux typiques d'un atelier industriel. Un enrichissement obligatoire du vocabulaire STT garantit que les termes spécifiques au domaine (numéros de pièce, codes de processus) sont reconnus avec précision. Il s'agit d'un critère d'acceptation pour l'intégration, pas d'une garantie de production pour chaque déploiement.
-
Comment le manifeste d'audit prend-il en charge la conformité à l'AI Act européen ?
Chaque réponse émet un enregistrement de provenance complet sur l'EventBus : IDs de chunks, chemins de documents, version du modèle, scores de similarité et motif de refus le cas échéant. Les enregistrements sont conservés six mois par défaut. Cet enregistrement peut servir de preuve pour les obligations de l'AI Act européen §10 (gouvernance des données) et §13 (transparence). Voir la page conformité pour la posture complète.
-
Quels modèles open source sont pris en charge ?
La configuration de référence utilise un SmolLM2 360M quantifié en 4 bits — environ 280 Mo d'empreinte RAM sur l'appareil. Des modèles quantifiés plus grands ou plus petits peuvent être substitués selon les exigences de RAM et de latence. BGE-small est le modèle d'embedding de référence pour la récupération RAG.
Apportez votre cas d'usage voix-IA.
Montrez-nous le vocabulaire du domaine et l'environnement sonore — l'ingénierie vous guidera dans la configuration RAG, l'enrichissement du vocabulaire et le setup d'audit pour votre déploiement.