Affinage de petits modèles de navigateur pour des réponses RAG fiables

Bart de Goede a récemment publié les résultats d'une expérience visant à affiner un petit modèle de langage pour améliorer la génération augmentée par récupération (RAG) directement dans le navigateur. En itérant sur quatre jeux de données d'entraînement distincts sur un Mac local, il a transformé un modèle de 0,6 milliard de paramètres sujet aux hallucinations en un assistant plus fiable qui refuse avec précision les questions sans réponse. Le modèle final, Qwen3-0.6B, alimente désormais la fonction de recherche de son blog avec significativement moins d'erreurs que la version de base.

Ce qui s'est passé

La première tentative d'utilisation de petits modèles de langage pour résumer les résultats de recherche sémantique a échoué car les modèles hallucinaient fréquemment des détails absents du texte source. De Goede a formulé l'hypothèse que l'affinage pourrait apprendre au modèle à respecter strictement les passages fournis ou à indiquer explicitement lorsque l'information manquait. Il s'est alors lancé dans la création d'un jeu de données utilisant des écritures techniques sous licences ouvertes provenant des communautés Go, Rust et Python, en évitant ses propres articles de blog pour prévenir toute fuite de données lors de l'évaluation.

Le processus a impliqué quatre tours d'entraînement, chacun révélant des pièges spécifiques dans la façon dont les petits modèles apprennent à partir de données synthétiques. La première version a dégradé les performances en imitant le style verbeux du modèle enseignant, tandis que les itérations suivantes ont ajusté le format des réponses pour les rendre plus courtes et factuelles. La troisième version s'est avérée être l'équilibre le plus efficace, réduisant les réponses erronées des deux tiers par rapport au modèle de base, même si elle refusait parfois de répondre à des questions auxquelles elle aurait techniquement pu répondre.

Tout le code, les jeux de données et les poids finaux du modèle ont été publiés publiquement. Cela permet à d'autres développeurs de reproduire la configuration, de la tester sur leur propre documentation ou de réentraîner le modèle avec des prompts système personnalisés. L'ensemble du pipeline d'entraînement a tourné localement sur un M4 Mac mini, démontrant que l'affinage de haute qualité pour des tâches RAG spécifiques ne nécessite pas d'importantes ressources de calcul cloud.

Comment cela fonctionne

Le système utilise un mécanisme de récupération qui découpe les documents et les intègre pour la recherche sémantique. Lorsqu'un utilisateur pose une question, le système récupère les quatre passages pertinents les mieux classés. Ces passages, accompagnés d'un prompt système strict, sont transmis au modèle Qwen3-0.6B exécuté dans le navigateur via WebGPU ou WebAssembly. Le prompt instruit le modèle de répondre en deux phrases maximum en utilisant uniquement le texte fourni, ou de refuser de répondre si les passages sont insuffisants.

L'entraînement reposait sur la distillation, où un modèle plus grand, Claude Opus 5.5, générait des réponses idéales pour des milliers de questions synthétiques. De Goede a utilisé LoRA (Low-Rank Adaptation) avec la bibliothèque mlx-lm pour affiner le petit modèle. Chaque session d'entraînement consistait en une époque sur 4 500 exemples, prenant environ 80 minutes. L'insight clé était que le petit modèle ne pouvait pas synthétiser des informations à travers plusieurs passages ; il pouvait seulement extraire des faits spécifiques de passages uniques ou refuser de répondre.

Détails clés

• Le modèle final est Qwen3-0.6B, affiné spécifiquement pour extraire des faits de quatre passages récupérés.
• L'entraînement a utilisé 2 193 documents issus des blogs Go, Rust et Python sous licences permissives.
• La version 3 a atteint 16 réponses fidèles sur 30, égalant la précision du modèle de base mais réduisant les réponses erronées de neuf à trois.
• Le modèle a correctement refusé de répondre à toutes les 15 questions non couvertes par le matériel source.
• Chaque itération d'entraînement a pris environ 1 heure et 20 minutes sur un M4 Mac mini avec 24 Go de RAM.
• Le jeu de données et le code sont publics, permettant à d'autres de réentraîner le modèle pour différents domaines comme les sites de documentation.

Pourquoi c'est important

Pour les ingénieurs construisant des systèmes RAG, cette expérience souligne que la taille du modèle est moins critique que la qualité des données pour des tâches d'extraction spécifiques. Les petits modèles fonctionnant dans le navigateur offrent des avantages en matière de confidentialité et de faible latence, mais ils manquent de capacité de raisonnement pour synthétiser des réponses complexes. En limitant la tâche à une extraction simple et au refus, les développeurs peuvent déployer des modèles légers robustes contre les hallucinations sans avoir besoin d'une inférence coûteuse côté serveur.

L'échec de la perte de validation à prédire les performances réelles est une autre leçon cruciale. Les métriques standard montraient une amélioration tandis que l'utilité réelle du modèle se dégradait, prouvant que les courbes de perte automatisées ne peuvent remplacer une évaluation manuelle sur des ensembles de test réservés. Les développeurs doivent évaluer les points de contrôle en fonction du comportement spécifique souhaité, tel que le refus correct, plutôt que sur la fluidité linguistique générale.

Cette approche démocratise également l'affinage. En montrant que des modèles efficaces peuvent être entraînés sur du matériel grand public en moins de deux heures, elle abaisse la barrière pour les équipes souhaitant personnaliser des modèles open-source pour leurs bases de connaissances spécifiques. Elle déplace l'accent de l'acquisition de modèles plus grands vers la conception de meilleures données d'entraînement adaptées aux limites cognitives des architectures plus petites.

Ce que vous pouvez faire

• Téléchargez le modèle bartdegoede/qwen3-0.6b-small-rag depuis Hugging Face pour une utilisation immédiate dans des applications basées sur le navigateur.
• Créez un petit ensemble d'évaluation de 30 à 50 questions concernant votre propre documentation, y compris certaines sans réponse possible, pour tester les performances de base.
• Générez des données d'entraînement synthétiques à l'aide d'un grand modèle de langage, en veillant à ce que les réponses soient courtes, factuelles et tirées de passages uniques.
• Supprimez les phrases d'atténuation telles que "le texte ne dit pas" des exemples d'entraînement positifs pour empêcher le modèle d'apprendre une verbosité inutile.
• Surveillez manuellement les performances des points de contrôle sur votre ensemble de test spécifique plutôt que de compter uniquement sur les métriques de perte de validation pendant l'entraînement.
• Envisagez de réentraîner le modèle avec des prompts système personnalisés si votre application fait référence à la "documentation" plutôt qu'à un "blog" pour améliorer l'alignement contextuel.