Raspberry Pi 5 hors ligne : un paquet de connaissances empoisonné mais signé passe tous les contrôles

Qu'advient-il d'un assistant IA local s'il vit sur un appareil sans réseau, alors qu'il faut tout de même pouvoir lui faire confiance ? Les chercheurs Georgios Feredzakis et Alexandros Papaspyridis ont testé cela sur un Raspberry Pi 5 : un RAG entièrement local sous isolation réseau, trois tailles de Qwen2.5 (1.5B, 3B, 7B), trois tailles de contexte et 300 questions issues de SQuAD 2.0. Résultat : une partie des mécanismes de protection fonctionne presque parfaitement, tandis que la protection la plus évidente, la signature numérique, se révèle insuffisante.

Cinq régimes de connectivité et des paquets de connaissances à la place du cloud

La plupart des déploiements d'IA générative dans l'IoT partent du principe que le cloud est à portée de main. Or les appareils réels fonctionnent souvent de manière intermittente, dans des circuits fermés, voire sans connexion du tout. Les auteurs proposent pour cela une échelle de connectivité C0–C4, une taxonomie des mécanismes de confiance au moment de l'inférence, et un canal de mise à jour pour les modes déconnectés : des paquets de connaissances versionnés et signés. L'appareil reçoit un nouveau paquet, le vérifie, et ne le connecte qu'ensuite à la base dont le modèle extrait son contexte.

Où la confiance fonctionne, et où elle échoue

Le premier mécanisme est un filtre basé sur le score de pertinence des fragments retrouvés, calibré empiriquement. Les requêtes totalement absentes du corpus, il les repère presque parfaitement : AUROC de 0,97. Avec les questions sans réponse mais situées dans un sujet familier, il s'en sort nettement moins bien, AUROC de 0,68. Ces questions ressemblent aux documents du corpus, et le score de recherche seul ne permet pas de les distinguer des questions normales.

Le second mécanisme est un validateur de sortie déterministe. Il transforme les réponses « bancales » en refus explicite, sans retirer au modèle une seule bonne réponse. Le modèle de vérification basé sur le NLI, également testé par les auteurs, n'a apporté que peu de valeur ajoutée. Pour le 7B, 96 % des réponses substantielles aux questions étiquetées « sans réponse » correspondaient à des fragments normalisés des passages retrouvés. Le modèle n'invente pas, il puise dans le contexte, même quand aucune réponse n'y figure formellement.

La signature n'équivaut pas à la vérité

La partie la plus exigeante du travail porte sur les mises à jour. Les seules vérifications de signature et de hachage ont accepté 6 attaques sur 9 : retour à une version antérieure, répétition, paquet expiré, clés révoquées, incompatibilité avec le modèle. La vérification multicouche en a rejeté les 9, en environ 4,5 ms.

Mais un paquet empoisonné à la signature valide a passé tous les contrôles et a privé le modèle des bonnes réponses sur les 30 questions ciblées. Les auteurs le formulent ainsi : l'intégrité établit la provenance, mais pas la véracité. La confiance dans le contenu doit être assurée chez l'éditeur avant la signature, pas sur l'appareil. Ce test n'a été mené que sur le 3B, le comportement du 7B reste une question ouverte : dans l'expérience principale, il refusait plus souvent de répondre aux questions sans réponse.

Les chiffres clés de l'étude

• Plateforme : Raspberry Pi 5 avec 16 Go de mémoire, réseau isolé
• Modèles : Qwen2.5 1.5B, 3B, 7B ; trois tailles de contexte
• Données : 300 questions SQuAD 2.0
• Filtre basé sur le score de retrieval : AUROC de 0,97 pour les requêtes hors corpus, 0,68 pour les questions sans réponse dans le sujet
• Validateur de sortie déterministe : zéro bonne réponse perdue
• Vérificateur NLI : apport marginal
• 7B : 96 % des réponses substantielles aux questions sans réponse correspondaient à des fragments de passages
• 3B contre 7B : même proportion de réponses contenant la référence, pour une latence et une énergie estimée inférieures de moitié ; une requête sur le 3B prend environ 22 s
• Mémoire résidente maximale à la fin de la requête : 6,3 / 9,4 / 13,6 Gio pour 1.5B / 3B / 7B
• Attaques de mise à jour : signature et hachage ont laissé passer 6 attaques sur 9, la vérification en couches en a rejeté 9 sur 9 en ~4,5 ms
• Paquet signé empoisonné : a cassé les bonnes réponses sur 30 cibles sur 30

Ce qu'il faut en retenir pour l'ingénieur

Pour les appareils hors ligne, il est plus raisonnable de choisir le 3B plutôt que le 7B : la qualité de confinement est équivalente, et la latence comme l'énergie sont réduites de moitié. Le validateur de sortie est peu coûteux, mieux vaut l'installer d'emblée. Pour les mises à jour, il faut un compteur de version monotone, une date d'expiration, une révocation des clés et une vérification de compatibilité avec le modèle, une simple signature ne suffit pas.

Des questions restent ouvertes : les auteurs reconnaissent que la détention de la clé et le retour autorisé à un paquet connu pour fonctionner ne sont pas résolus, qu'ils n'ont trouvé aucun profil de mise à jour tout fait spécifiquement pour le RAG, et que la clé de l'expérience a été générée sur l'appareil lui-même. Les participants à la discussion proposent de faire tourner en plus un jeu fixe de questions de contrôle avant de basculer vers un nouveau paquet. La fenêtre pour cela existe : l'embedding d'un paquet sur le Pi prend environ 29 minutes.

Tous les chiffres se reproduisent avec une seule commande, le code et les sorties par requête sont publiés.