Trust Mechanisms for Offline Generative AI at the Edge: A Connectivity-Regime Framework and an Empirical Study on a Raspberry Pi 5
Abstract
Local retrieval-augmented generation on edge devices using signed knowledge packs and output validators improves efficiency but remains vulnerable to poisoned updates and cannot guarantee evidence truth.
Generative AI and large language models (LLMs) are moving into the Internet of Things, yet most deployments assume cloud connectivity, and many IoT settings have intermittent, restricted, or no connectivity. We propose a connectivity-regime framework (C0-C4), a taxonomy of inference-time trust mechanisms, and signed, versioned knowledge packs as the update channel for disconnected regimes, and evaluate them on a Raspberry Pi 5 running fully local retrieval-augmented generation under network isolation, with three Qwen2.5 model sizes, three context sizes, and 300 SQuAD 2.0 questions. An empirically calibrated retrieval-score gate detects knowledge gaps almost perfectly (AUROC 0.97) but in-topic unanswerable questions poorly (0.68). A deterministic output validator converts malformed outputs into explicit abstentions with no observed loss of correct answers, while the NLI-based verifier we tested adds little; for the 7B model, 96% of substantive answers to unanswerable-labelled questions match normalized spans of the retrieved passages. A 3B model achieves the same gold-answer containment rate as a 7B model at less than half the latency and estimated energy, although the 7B model far more often exceeds a token-F1 threshold of 0.5; five retrieved passages lower correctness from 75% to 52% compared with three. Verifying a signed pack takes about 4.5 ms versus about 29 min for embedding its passages on the device; signature and hash checks alone accept six of nine tested update attacks that layered verification rejects. Yet a validly signed poisoned pack passes every pack check: on 30 previously correct questions, correct answers drop to zero and 14 return the injected answer. None of the mechanisms we evaluated establishes the truth of the evidence. We release code and data.
Community
We study what trust mechanisms do, and cost, for a fully local RAG assistant on a Raspberry Pi 5 running under network isolation (Qwen2.5 1.5B/3B/7B, 300 SQuAD 2.0 questions).
Key findings:
- A calibrated retrieval-score gate detects out-of-corpus queries almost perfectly (AUROC 0.97) but in-topic unanswerable questions poorly (0.68).
- A simple deterministic output validator turns malformed outputs into explicit abstentions at no observed cost in correct answers.
- Signature and hash checks alone accepted 6 of 9 update attacks (rollback, replay, expiry, revoked keys, model incompatibility); layered verification rejected all 9 in about 4.5 ms.
- A validly signed but poisoned knowledge pack passed every check and eliminated correct answers on all 30 targets: integrity establishes provenance, not truth.
Code, per-query outputs, and analysis scripts are open (DOI and GitHub links above); every table value can be regenerated with one command.
Signed knowledge packs solve the wrong half of the problem. Signing tells me the pack came from you; it says nothing about what happens when a bad one lands on a device that's offline for weeks. Key custody on a sealed box is the real puzzle — where does the verification key live so a pack swap can't rewrite it, and who authorizes the rollback when retrieval starts returning confident garbage? I'd want a monotonic counter and a known-good snapshot on partition, not just a version field.
Residency is where I'd expect the numbers to get ugly. Weights, index, and pack all want RAM at once on a Pi 5, and if the model doesn't fit alongside the index, you're reloading per query and that latency dominates any model-size comparison. Did the study measure steady-state resident set under load, or just first-token time after a fresh load? Those are very different products.
Fair point, and the poisoning result says the same thing: a validly signed pack passed every check and broke all 30 targets. Signing gives provenance, not truth, so content trust has to be settled at the publisher before signing.
We do enforce a monotonic sequence number, plus expiry, revocation and model compatibility; signature and hash checks alone let through 6 of the 9 attacks this caught. But we assumed the counter can't be reset and the trust store is updated securely, and we generated the key on the device for convenience. Key custody and authorized rollback to a known-good pack are open, and we found no RAG-specific update profile that covers them.
On memory: with 16 GB everything stayed resident, and the server stayed up across queries, so these are steady-state numbers, not cold starts. The highest resident memory we sampled at query completion was 6.3, 9.4 and 13.6 GiB for 1.5B, 3B and 7B. We didn't report time-to-first-token, and you're right that a smaller board would be a different story.
The signed poisoned pack is the result I keep thinking about: every pack check passes and 14 of 30 previously correct questions return the injected answer. Did you look at a check on the device side, for example comparing a new pack's passages against the previous version and flagging large answer changes on a fixed probe set before switching over? Since embedding a pack takes about 29 minutes on the Pi, that probe could run in the same window. I would also like to know if the 3B model followed the injected passages as often as the 7B one.
We didn't test that, but it's a good idea and cheap enough: a 3B query takes about 22 s on the Pi, so a few dozen probes fit easily in an update window. The catch is coverage, since a targeted attack only changes answers to the targeted questions. Diffing the new passages might catch more, because ours restated the target questions almost word for word.
We only ran the poisoning test with 3B, so we can't say how 7B would behave. It declined more unanswerable questions in the main study, so it's worth checking.
Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper
Spaces citing this paper 0
No Space linking this paper
Collections including this paper 0
No Collection including this paper