Un assistant RAG sur WebGPU, du CMS au navigateur.

WebGPU donne au navigateur un accès aux calculs du GPU. Dans ce projet, il sert à l’inférence : appliquer les poids d’un modèle pour produire un embedding ou générer du texte. Cette exécution locale évite d’appeler une API de génération hébergée à chaque réponse. Elle demande cependant un navigateur, un pilote et des ressources GPU compatibles, sur une page servie en HTTPS.

La présence de navigator.gpu ne suffit pas. L’application vérifie l’adaptateur matériel et refuse un adaptateur logiciel de secours. Les essais physiques ont notamment utilisé l’Adreno 830 du Samsung Galaxy S25 Ultra sous Samsung Internet et un GPU NVIDIA Ampere sur ordinateur. Les capacités et les limites de buffers peuvent varier : la marque du navigateur ou la mémoire totale du téléphone ne prouvent pas qu’un export fonctionnera.

Le moteur retenu pour Gemma 4 E2B est LiteRT-LM, avec le SDK @litert-lm/core fixé à la version 0.17.1, le backend GPU_ARTISAN explicitement demandé, une fenêtre de 4 096 tokens et le mode thinking désactivé. L’API Web LiteRT-LM reste une préversion, qualifiée ici sur les appareils testés. Les embeddings E5 suivent un autre chemin : ONNX Runtime Web avec WebGPU. Plusieurs exports ONNX, WebLLM/MLC et moteurs compacts ont été évalués avant ce choix.

Les moteurs compacts expérimentés ont également demandé du travail sur les shaders WGSL, les poids quantifiés et le cache des états du modèle. Le chemin Nanbeige 4.2 doit notamment respecter les deux passages prévus par son architecture : supprimer une passe pour gagner du temps ne serait pas une optimisation équivalente. Un format léger ou un modèle plus petit ne suffit donc pas ; il faut que ses opérations soient correctement exécutées par ce GPU et que le parcours RAG reste fiable.

L’intégration a nécessité deux Web Workers distincts. Le SDK LiteRT utilise importScripts et démarre dans un worker classique ; le worker des embeddings est un module JavaScript. Cette séparation garde le modèle de réponse chargé pendant la recherche E5 et laisse l’interface réactive. L’annulation couvre les deux workers ; une perte du GPU libère les moteurs et signale une erreur exploitable au visiteur.

Le CMS sélectionne les pages publiées, les fiches de connaissances autorisées et les informations de formulaires admissibles. Leur texte est préparé puis découpé avec le véritable tokenizer du modèle d’embedding : passages de 400 tokens avec un recouvrement de 40 tokens, titre borné et vérification de la limite de 512 tokens après ajout du préfixe. L’application refuse un extrait trop long au lieu de tronquer silencieusement les informations.

Le profil actuellement sélectionné, Multilingual E5 Base, produit des vecteurs de 768 dimensions. Les entrées distinguent query: pour une question et passage: pour un document. Les sorties suivent un pooling moyen masqué et une normalisation L2. Ces opérations doivent être identiques à l’indexation et à la recherche : un vecteur de bonne longueur peut néanmoins être numériquement incorrect.

Sur mobile, le chemin MatMulInteger de certains exports quantifiés n’était pas compatible avec le moteur utilisé. Un outil de préparation reproductible conserve les poids INT8 mais adapte les opérations matricielles vers le chemin FP32 portable. Les artefacts E5 sont contrôlés par SHA-256 et comparés à quatre références numériques, avec un cosinus attendu d’au moins 0,999. Ces références sont calculées hors du navigateur ; l’inférence du visiteur reste sur WebGPU.

Les vecteurs sont stockés dans MariaDB, dans une colonne VECTOR(1024). Les dimensions restantes sont complétées par des zéros, ce qui conserve le calcul du cosinus. Chaque index reste associé à son profil d’embedding et chaque passage à son empreinte de contenu. Un lot périmé ou un vecteur non normalisé est refusé.

À chaque question, le serveur classe les passages par distance cosinus, filtre la langue et les sources encore publiées, applique le seuil configuré et limite la concentration de passages d’un même document. La configuration illustrée retient quatre extraits avec un seuil de 0,75. E5 Small, 384 dimensions et environ 118 Mo contre 279 Mo pour Base, est disponible pour d’autres essais ; il exige son propre index et ne se déduit pas en raccourcissant les vecteurs Base.

Une question de suivi comme « et pour la maintenance ? » devient difficile à rechercher sans le sujet précédent. Une première passe du modèle produit une requête autonome à partir de la demande, des échanges récents et de la référence éventuelle. Le nettoyage de cette sortie évite de transmettre un commentaire du modèle comme requête. Si cette reformulation échoue sans erreur fatale de moteur, la recherche peut repartir de la question d’origine.

La recherche conserve la question et sa reformulation lorsque les deux apportent une requête distincte. Le serveur fusionne leurs classements avec une méthode de reciprocal rank fusion : elle combine les rangs des passages plutôt que de laisser une réécriture remplacer entièrement la demande du visiteur. Le résultat réduit le risque qu’un détail important disparaisse lors de la reformulation.

La mémoire persistante est facultative et stockée dans IndexedDB, dans le navigateur du visiteur : jusqu’à 60 échanges pendant 7 jours. Chaque entrée conserve une question, une réponse, son vecteur, sa langue, son profil d’embedding et sa date. Les entrées expirées sont éliminées lors de l’accès ; l’utilisateur peut désactiver ou effacer cette mémoire. Si le stockage est indisponible, la discussion continue sans persistance.

Cette mémoire comporte une recherche sémantique locale. Le vecteur de la question actuelle est comparé aux anciennes questions de la même langue et du même profil ; le meilleur résultat dépassant le seuil du profil peut enrichir le contexte. Les derniers échanges sont prioritaires. Une ancienne réponse générée n’est pas réinjectée comme une source de faits : seule la question ancienne pertinente sert de contexte distant.

Le prompt de rédaction assemble le rôle et les consignes configurés dans le CMS, la dernière demande, l’historique utile et les extraits documentaires. Les passages sont présentés comme des données, séparées des instructions système. Le brouillon est privé : l’interface montre l’état de travail, puis la réponse acceptée. Cette attente inclut donc plusieurs passes d’inférence, et pas seulement la rédaction visible.

Une seconde passe du même modèle évalue si le brouillon répond réellement à la question et si les informations essentielles sont soutenues par les sources. Pour LiteRT, les échanges structurés utilisent un outil local emit_result, sans action externe. Le programme vérifie l’objet JSON et les types des champs attendus. Un JSON valide ne prouve toutefois pas que son jugement est juste.

Un cas concret a révélé une différence de contexte : le rédacteur voyait jusqu’à 1 250 caractères par extrait, tandis que le contrôleur n’en voyait que 650. Une fourchette de prix située plus loin pouvait alors manquer au contrôle. Les deux passes utilisent désormais la même limite de 1 250 caractères et les mêmes sources ; ce correctif évite de demander au juge de vérifier une information qu’on lui a retirée.

Si le brouillon est refusé, le parcours peut lancer une recherche documentaire corrective puis rédiger une seconde version. Le nombre de tentatives reste borné : deux brouillons au maximum et une recherche complémentaire. Les répétitions d’anciennes réponses et les commentaires internes sont également filtrés. En l’absence de réponse admissible, l’assistant indique la limite et propose un contact.

Les compteurs natifs de génération sont conservés ; une sortie vide ou atteignant son plafond est refusée. Aucun signal de fin de génération que le SDK n’expose pas n’est fabriqué. Le contrôle local réduit certains défauts, mais utilise le même modèle que le rédacteur : il peut lui aussi se tromper. Il doit être éprouvé avec des brouillons faux et des informations absentes, et les sources restent consultables.

L’inférence de réponse et la mémoire persistante s’exécutent sur l’appareil. Le service reste connecté : il télécharge des modèles et bibliothèques, envoie les vecteurs de recherche au serveur et reçoit les textes sources. Un embedding n’est pas une garantie d’anonymat. Les questions non couvertes peuvent être enregistrées côté CMS pour améliorer les connaissances, avec une conservation maximale de 90 jours sans nouvelle demande et une limite de 5 000 questions par site.

Les API appliquent le périmètre du site, les contrôles de session administrateur et les protections CSRF adaptées aux opérations. Les vecteurs reçus sont vérifiés : profil, nombre de dimensions, valeurs finies et normalisation. La recherche exclut les pages retirées et les formulaires non autorisés ; les brouillons de connaissances ne sont pas publiés dans les réponses.

Si la lecture de références web est activée, une URL publique fournie par le visiteur peut être lue par le serveur. Les protocoles, les adresses réseau et les redirections sont contrôlés pour bloquer l’accès aux réseaux privés. Le téléchargement est limité en volume et en durée. Le texte utile est extrait sans exécuter les scripts de la page ; il reste une référence externe, pas une nouvelle instruction système.

L’assistant peut aussi aider à préremplir un formulaire autorisé à partir des informations explicitement fournies par le visiteur. Le schéma des champs, la langue, le formulaire cible et la durée de validité sont contrôlés. Les valeurs déjà saisies sont préservées, le consentement n’est pas coché automatiquement et aucun formulaire n’est envoyé sans l’action de l’utilisateur.

Le CMS ne se limite pas à choisir un nom de modèle. Il prépare les sources, reprend les passages à indexer, suit les extraits en attente et propose un test réel. Les profils de réponse mobile/tablette et ordinateur sont indépendants. La détection côté client utilise les informations du navigateur et de l’appareil ; réduire la largeur d’une fenêtre d’ordinateur ne la transforme pas en profil mobile.

Le test est lié au modèle, à la configuration et à la recherche réalisée. Un changement de modèle, de consignes ou d’index remet en cause la validation concernée : un nouveau test puis une réactivation sont nécessaires. Des signatures de configuration empêchent de conserver une activation sur la simple base d’un ancien test. Les réglages purement visuels, eux, conservent la validation des réponses.

La recette a couvert la génération réelle sur GPU, la cohérence numérique des embeddings, des questions de prix et de maintenance, des promesses fausses et des chiffres non publiés. Les corrections mobiles ont aussi été vérifiées avec clavier ouvert, lancement et fermeture de la fenêtre, bouton d’envoi accessible et absence de débordement. Les déploiements sauvegardent le périmètre concerné et contrôlent les pages publiques.

Les pistes restantes sont concrètes : élargir l’ensemble de questions de qualification, mesurer les téléchargements à froid et les quotas, vérifier davantage de couples navigateur/GPU, et comparer de nouveaux exports sur Adreno. Une application native pourrait accéder à d’autres accélérateurs ; un relais d’inférence hébergé pourrait alléger le téléphone. Ces pistes changeraient l’architecture et ne sont pas présentées ici comme déjà livrées.