RAG文書汚染は、なぜoutput filterよりingestion controlが重要なのかを示した
Original: Document poisoning in RAG systems: How attackers corrupt AI's sources View original →
Hacker Newsで注目を集めたAmine Rajiの実験は、document poisoningが小さなRAG stackでも十分に実用的であることを示している。彼はLM Studio、Qwen2.5-7B-Instruct、ChromaDB、そして5本の正常な文書だけが入ったlocal knowledge baseを使い、そこへ3本の偽の「訂正文書」を追加した。その後に会社の業績を尋ねる普通の質問を投げると、システムは本来のQ4 2025売上である$24.7Mではなく、改ざんされた$8.3Mやrestructuring planまで自信を持って返し始めた。
重要なのは、この攻撃がpromptを書き換えたりmodelをjailbreakしたりしなくても成立することだ。勝負はもっと手前、つまりretrievalとsource weightingで決まる。偽文書は正規の財務文書と同じ語彙を使いながら、「CFO-approved correction」や「board update」といった権威づけの表現を加え、modelが誤った文書をより信頼するよう誘導する。著者の計測では20回中19回が成功し、同時に5文書のcorpusは攻撃者に有利なbest caseであるとも明記されている。
もっとも注目されたのは防御側の結果だった。Rajiによれば、prompt hardeningやoutput monitoringの効果は限定的で、新規文書のsemantic overlapをingestion段階で検査するembedding anomaly detectionが、standaloneでの攻撃成功率を95%から20%まで下げたという。さらに5つの防御レイヤーを組み合わせると残余成功率は10%まで落ちた。つまり論点は「modelが悪い回答を拒否できるか」ではなく、「誰がknowledge baseに書き込めるのか、その書き込みをどう検査するか」に移る。
Hacker Newsのコメント欄では、この前提への突っ込みも多かった。knowledge baseへのwrite access自体がすでに特権的だという指摘もあれば、citation UXやprovenanceを強化すればこの種の失敗はもっと早く見抜けるという意見もあった。それでも結論は重い。RAGがConfluence、Slack、SharePoint、内部文書パイプラインとつながるほど、ingestionは独立したattack surfaceになる。原典: Amine Raji。コミュニティ反応: Hacker News。
Related Articles
Anthropicは2026年3月6日、Mozillaとの協力によりClaude Opus 4.6が2週間でFirefoxの脆弱性22件を発見し、そのうち14件が高深刻度だったと発表した。添付の解説は、フロンティアモデルが実運用ソフトの脆弱性発見でも実用段階に入りつつあることを示している。
Launch HNスレッドはRunAnywhereのMetalRTとRCLIを押し上げ、Apple Silicon上でSTT・LLM・TTSをクラウドなしでつなぐ低遅延音声AIスタックに注目を集めた。
Launch HNスレッドでRunAnywhereのRCLIが可視化された。Apple Silicon上でSTT、LLM、TTS、ローカルRAG、38個のmacOS actionをまとめて動かすmacOS向けVoice AIの試みだ。
Comments (0)
No comments yet. Be the first to comment!