# Assistant IA RAG dans le navigateur | SDX Development > Étude de cas SDX : WebGPU, embeddings E5, reformulation, mémoire locale, contrôle des réponses et tests mobiles pour un assistant RAG administrable. Assistant IA RAG · SDX ## Un assistant RAG sur WebGPU, du CMS au navigateur. Une application IA complète : connaissances dans le CMS, recherche vectorielle, mémoire locale et réponses rédigées puis contrôlées sur le GPU du visiteur. - IA & RAG - Génération dans le navigateur - CMS & mobile [Toutes les réalisations](https://sdx-development.com/realisations) [![Assistant public SDX : question sur le prix d’un site vitrine et réponse générée dans Chrome, avec liens vers les sources.](https://sdx-development.com/media/assistant-rag-sdx/assistant-desktop.webp)Agrandir la capture](https://sdx-development.com/media/assistant-rag-sdx/assistant-desktop.webp) Assistant public SDX : question sur le prix d’un site vitrine et réponse générée dans Chrome, avec liens vers les sources. 01 / RAG ## Transformer les contenus en réponses utiles Les pages d’un site expliquent une offre, ses tarifs et son fonctionnement. Pourtant, le visiteur ne sait pas toujours où chercher. L’objectif était de lui permettre de poser sa question et de retrouver une réponse reliée aux informations publiées. J’ai conçu cette application sur le propre site de SDX Development. C’est une réalisation interne, accessible en production, qui réunit recherche documentaire, modèles locaux, administration des connaissances et interface de conversation. ### Mon intervention Conception du parcours RAG, intégration au CMS, exécution des modèles dans le navigateur, contrôle des réponses et tests sur ordinateur et sur un Samsung Galaxy S25 Ultra. Projet Application interne · SDX Development Usage Questions sur les services et contenus du site Interface Assistant intégré au site et piloté dans le CMS Livraison En production · septembre 2026 02 / RAG ## De la question à une réponse sourcée Le RAG relie la génération de texte à des informations retrouvées dans une base documentaire. Ici, le navigateur et le serveur du site se partagent le travail. 1. ### Connaissances Le CMS prépare un index à partir des contenus sélectionnés et des connaissances ajoutées par l’administrateur. 2. ### Recherche Le navigateur calcule une représentation de la question. Le serveur recherche les passages pertinents dans l’index et renvoie leurs sources. 3. ### Rédaction locale Le modèle exécuté dans le navigateur rédige une réponse à partir des passages retrouvés. Une recherche complémentaire peut enrichir le contexte. 4. ### Vérification Un contrôle local examine le brouillon avant son affichage. Si les informations ne suffisent pas, l’assistant propose de prendre contact. La génération s’exécute sur l’appareil du visiteur, avec accès au GPU. Le service n’est pas entièrement hors ligne : il télécharge des modèles et interroge le serveur pour retrouver les sources. Les questions sans réponse peuvent être conservées pour compléter les connaissances. ### Une chaîne RAG répartie entre navigateur et serveur Le serveur conserve les connaissances et recherche les passages. Le navigateur exécute les modèles de reformulation, d’embedding, de rédaction et de contrôle. La mémoire de conversation est une troisième ressource, locale et facultative : elle aide à suivre la demande, sans remplacer les sources documentaires. 1. Navigateur · GPU local #### Question et contexte récent La demande actuelle, les derniers échanges et, si cette fonction est activée, une référence web publique fournie par le visiteur. 2. Navigateur · GPU local #### Reformulation de la recherche Le modèle transforme la demande en une requête documentaire autonome. La question d’origine est conservée à côté de la reformulation. 3. Navigateur · GPU local #### Embeddings E5 Les requêtes deviennent des vecteurs numériques calculés sur WebGPU. Ce sont ces vecteurs qui partent vers l’API du site. 4. Serveur du site · PHP / MariaDB #### Recherche vectorielle et fusion L’index sélectionne les passages de la bonne langue, applique le seuil de similarité et fusionne les classements. Retour : textes, titres et liens des sources. 5. Navigateur · GPU local #### Mémoire locale pertinente Si le visiteur l’autorise, une ancienne question proche est retrouvée dans IndexedDB. Elle complète les échanges récents, sans importer son ancienne réponse comme preuve. 6. Navigateur · GPU local #### Rédaction d’un brouillon privé Le modèle de réponse utilise les consignes du CMS, la question, le contexte de conversation et les passages retrouvés. Rien de ce brouillon n’est encore affiché. 7. Navigateur · GPU local #### Contrôle et recherche corrective Le même modèle confronte le brouillon aux sources. En cas de refus : au plus une nouvelle recherche et une seconde tentative de rédaction. 8. Navigateur · GPU local #### Réponse, sources et suite proposée Le brouillon accepté est affiché avec les sources. À défaut d’information suffisante, un relais humain est proposé. Un échange admissible peut être mémorisé localement. Avant les questions : l’administrateur prépare les contenus et calcule leurs embeddings dans son navigateur. Les vecteurs documentaires sont enregistrés sur le serveur. Les 855 fragments de l’index validé ne sont donc pas recalculés sur le téléphone de chaque visiteur. EXÉCUTION ## WebGPU : faire réellement tourner l’IA sur l’appareil 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. Les poids Gemma E2B représentent 2 008 432 640 octets, soit environ 2 Go. Ils sont téléchargés en flux et conservés dans Cache Storage lorsque le quota le permet, sans construire un tableau JavaScript de deux Go. La révision et la taille attendue sont vérifiées. Un cache évincé ou indisponible peut imposer un nouveau téléchargement ; ce coût doit être distingué du temps de réponse après chargement. CONNAISSANCES ## Préparer un index fiable, avec des embeddings compatibles 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. Le modèle d’embedding reste commun aux profils mobile et ordinateur dans cette livraison. Deux embeddings choisis selon l’appareil nécessiteraient deux index complets et une validation de leurs résultats. La séparation mobile/ordinateur est déjà disponible pour le modèle qui rédige les réponses. CONTEXTE ## Reformuler la demande et retrouver une mémoire locale pertinente 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. Trois notions sont séparées : les connaissances documentaires font autorité pour les faits ; l’historique récent aide à suivre la conversation ; la mémoire locale aide à retrouver un besoin précédent. Cette mémoire ne modifie ni les poids du modèle ni l’index documentaire du site. QUALITÉ ## Rédiger, contrôler, corriger : une réponse n’est pas affichée dès le premier token 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. Le gain de vitesse a été recherché dans les moteurs, les formats et le chargement. Supprimer les sources ou retirer le contrôle aurait changé le service rendu et aurait rendu les durées incomparables. 03 / CMS ## Un assistant administrable, au-delà de la bulle Le CMS rassemble les réglages qui font vivre l’assistant : ses connaissances, son comportement, ses modèles et son apparence. ### Choisir les connaissances Sélection des contenus, ajout d’informations complémentaires et préparation de l’index documentaire. ### Adapter les modèles Un modèle de réponse pour mobile et un autre pour ordinateur, sélectionnés côté client. Le modèle d’embedding est configurable. ### Tester avant d’activer Tests de réponse et validation dans l’administration avant la mise à disposition de l’assistant. ### Définir le comportement Nom, accueil, consignes et fonctions disponibles, avec possibilité d’orienter la demande vers un contact. ### Accorder l’apparence au site Couleurs, avatar, position et aperçu. Aura réglable : mouvement, direction, vitesse et gonflement maximal. ### Compléter les réponses manquantes Les demandes non couvertes aident à repérer les connaissances à enrichir, puis à retester le parcours. ### Les écrans réels de l’administration Captures du CMS de production dans Chrome, le 27 septembre 2026. Le cadrage montre les fonctions de l’assistant et exclut la barre de compte. Le formulaire de connaissance est vide ; l’aperçu d’apparence affiche une conversation de démonstration. [![Modèles : choix distincts pour ordinateur et mobile, profil E5 Base, quatre extraits et seuil de similarité à 0,75. Index de 855 fragments vectorisés.](https://sdx-development.com/media/assistant-rag-sdx/admin-models.png)Agrandir la capture](https://sdx-development.com/media/assistant-rag-sdx/admin-models.png) Modèles : choix distincts pour ordinateur et mobile, profil E5 Base, quatre extraits et seuil de similarité à 0,75. Index de 855 fragments vectorisés. [![Connaissances : création d’une fiche, import de texte ou Markdown, aide à la rédaction et autorisation explicite d’utilisation par l’assistant.](https://sdx-development.com/media/assistant-rag-sdx/admin-knowledge.png)Agrandir la capture](https://sdx-development.com/media/assistant-rag-sdx/admin-knowledge.png) Connaissances : création d’une fiche, import de texte ou Markdown, aide à la rédaction et autorisation explicite d’utilisation par l’assistant. [![Apparence : avatar, position, couleurs et aperçu de conversation. Les effets et l’invitation disposent de réglages dédiés.](https://sdx-development.com/media/assistant-rag-sdx/admin-appearance.png)Agrandir la capture](https://sdx-development.com/media/assistant-rag-sdx/admin-appearance.png) Apparence : avatar, position, couleurs et aperçu de conversation. Les effets et l’invitation disposent de réglages dédiés. 04 / MOBILE ## Une conversation pensée pour le téléphone Le widget est isolé dans un Shadow DOM pour éviter les conflits de styles avec le site. Sur Android, une interface lisible exige aussi de suivre le clavier et la zone réellement visible. - ### La réponse dispose de l’espace La fenêtre utilise toute la hauteur disponible et le lanceur launcher-shell est masqué pendant la discussion. Les commandes secondaires restent repliées pour laisser de la place aux messages. - ### Le clavier reste utilisable VisualViewport fournit la hauteur et le décalage de la zone visible quand le clavier Android s’ouvre. La fenêtre les suit ; le champ grandit de 44 à 96 px maximum et le bouton d’envoi reste accessible. - ### L’écran reste éveillé si possible Screen Wake Lock est demandé pendant la discussion, repris au retour au premier plan et relâché à la fermeture. Le système et le navigateur peuvent refuser ce verrou ; aucun réglage permanent du téléphone n’est changé. [![La même conversation dans la mise en page mobile : capture du site public à une largeur de 390 px dans Chrome.](https://sdx-development.com/media/assistant-rag-sdx/assistant-mobile.webp)Agrandir la capture](https://sdx-development.com/media/assistant-rag-sdx/assistant-mobile.webp) La même conversation dans la mise en page mobile : capture du site public à une largeur de 390 px dans Chrome. **36 s** pour la question de prix testée sur le S25 Ultra 05 / Mesurer sur un appareil réel ## Mesurer sur un appareil réel Le 27 septembre 2026, dans Samsung Internet, l’assistant public a répondu à une question sur le prix d’un site vitrine professionnel en environ 36 secondes, avec contrôle de la réponse et sources. La fourchette publiée de 1 500 à 5 000 € HT a été retrouvée. Mesure ponctuelle avec les fichiers du modèle déjà téléchargés, et non garantie pour toutes les demandes. Le premier téléchargement est volumineux ; des questions complexes ou une recherche corrective peuvent dépasser une minute. Le matériel et l’accès au GPU du navigateur influencent le résultat. ## Deux profils, une même base de connaissances Mobile Gemma 4 E2B · LiteRT-LM Ordinateur Gemma 4 E2B · LiteRT-LM Recherche documentaire Multilingual E5 Base Configuration de production après les essais du 27 septembre 2026 : Gemma E2B est sélectionné pour les deux profils, qui restent indépendants. Le choix repose sur la qualité du parcours et les mesures réelles. ## Ce que les essais ont changé dans le choix des modèles Mesures du 27 septembre 2026. Les durées ci-dessous correspondent à un parcours RAG jusqu’à sa réponse contrôlée, avec les poids déjà téléchargés. Elles incluent la recherche et plusieurs passes du modèle ; ce ne sont pas des mesures du seul décodage. | Appareil / candidat | Durée observée | Résultat du parcours | | --- | --- | --- | | S25 Ultra · Samsung Internet · Gemma 4 E2B | 36,11 s | Question de prix : réponse complète, contrôlée, 1 500–5 000 € HT. | | Ordinateur · Chrome / NVIDIA Ampere · Gemma 4 E2B | 12,25 s | Même question : 114 tokens ; le contrôle refuse aussi un brouillon au prix faux. | | Même ordinateur · Nanbeige 4.2 Compact | 120,73 s | Réponse nominale correcte, 238 tokens ; acceptation erronée du brouillon faux lors du contre-test. | | Même ordinateur · Gemma E2B · validation finale | 13,06 s | Test réel enregistré dans le CMS, puis activation du modèle commun aux deux profils. | Les réponses ont des longueurs différentes et la reformulation peut changer les passages retrouvés : ces durées ne constituent pas un classement universel des modèles. Le contre-test présentait 15 000–100 000 € HT face à des sources indiquant 1 500–5 000 € HT. La réponse correcte de Nanbeige sur la question simple ne suffisait pas à qualifier son contrôle. Sur cet ordinateur, Gemma E2B a aussi traité une objection de prix en 15,02 s et une question de maintenance en 12,99 s. Une fausse promesse « 24 heures pour 100 euros » et un chiffre d’affaires exact non publié ont mené à un relais humain en 25,91 s et 23,59 s. Ne pas inventer l’information faisait partie du test. Les essais mobiles ont montré que des téléchargements plus petits ne garantissent pas une chaîne fiable : plusieurs candidats ont perdu le GPU, produit des répétitions ou échoué au contrôle. Les exports ONNX de Qwen 3.5 4B et Gemma 3 4B testés sur ordinateur n’ont pas donné de réponse finale dans ce parcours. Ces résultats concernent ces exports et moteurs, pas toutes les utilisations de ces modèles. Les embeddings ont été mesurés séparément sur le S25, avec les poids en cache : Base, 4,275 s pour chargement, vérifications et première question, puis 90–103 ms ; Small, 3,487 s puis 24–27 ms. Le petit test de classement portait sur cinq passages, pas sur les 855 fragments du site. L’essentiel de la longue attente provenait des passes de réponse : remplacer l’embedding seul n’aurait pas résolu ce problème. DONNÉES ## Définir ce qui reste local et ce qui circule vers le serveur 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. Cette architecture n’est ni un service entièrement hors ligne ni une promesse que toute donnée reste sur le téléphone. Les flux documentaires, les références et les questions à compléter sont des fonctions distinctes, à expliquer selon le périmètre retenu. MISE EN PRODUCTION ## Relier les réglages, les tests GPU et l’activation 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. Le résultat est une application intégrée au CMS, avec une chaîne reproductible et des limites connues. Le critère de réussite reste une réponse utile et soutenue par les sources, pas le seul nombre de paramètres du modèle. ## Références techniques Les choix et durées de cette étude proviennent des essais du projet. Ces documentations décrivent les technologies utilisées ; elles ne constituent pas des garanties de performance sur un appareil donné. - [WebGPU · W3C](https://www.w3.org/TR/webgpu/) - [LiteRT-LM · Google AI Edge](https://developers.google.com/edge/litert-lm/js) - [ONNX Runtime · WebGPU](https://onnxruntime.ai/docs/tutorials/web/ep-webgpu.html) - [Multilingual E5 · Microsoft Research](https://huggingface.co/intfloat/multilingual-e5-base) ## Une application concrète du RAG sur un site public Le visiteur peut interroger les contenus et vérifier les sources. L’administrateur peut enrichir les connaissances, régler l’assistant et tester ses réponses. Le projet illustre toute la chaîne, de l’édition du contenu à son utilisation dans une conversation. [Découvrir l’expertise IA & RAG](https://sdx-development.com/ia-rag-vision) ## D’autres réalisations à découvrir ![Idea to Software](https://sdx-development.com/media/idea-to-software/agenda.webp) Logiciels et produits métier ### Idea to Software Un ERP métier qui relie affaires, planning sous contraintes, stocks, facturation et extranet client, avec ITS Report pour l’inspection vidéo. [Explorer le projet : Idea to Software](https://sdx-development.com/realisations/idea-to-software) ![Résiliner](https://sdx-development.com/media/resiliner/home.webp) Sites internet professionnels ### Résiliner Un site industriel avec CMS sur mesure : contenus techniques, méthode C.A.R.E., références, franchise et parcours de demande de diagnostic. [Explorer le projet : Résiliner](https://sdx-development.com/realisations/resiliner) Et votre projet ? ## Vos contenus peuvent devenir une interface de conversation. Documentation, catalogue, procédures ou services : définissons les sources, les utilisateurs et les réponses attendues pour concevoir un assistant utile à votre activité. - Des sources identifiées - Un périmètre adapté à vos usages - Des réponses à tester [Parler de mon assistant IA](https://sdx-development.com/contact)[Découvrir l’approche IA & RAG](https://sdx-development.com/ia-rag-vision) --- [Consulter la page HTML](https://sdx-development.com/realisations/assistant-ia-rag)