1. この論文は何を問題にしているか

問題は、知識パックに付いた電子署名が「誰が出したか」は保証しても、「中身の数字が本文どおりか」は保証しないことである。インターネットにつながらない機器の上で動く RAG（検索拡張生成）では、知識の更新を、署名付きの「知識パック」を配って行う設計がある。パックには文書の本文と、あらかじめ計算した埋め込みベクトルが入っている。機器の側は署名を確かめてからパックを取り込み、質問が来るとベクトルの近さで文書を探し、見つけた文書を言語モデルに渡して答えを作る[4]。

著者らは、この設計に穴があると指摘する。署名は発行者が本物であることを示すが、パックの中のベクトルが本文の意味を正しく表しているかまでは示さない。本文は無害なまま、ベクトルだけを細工すれば、検索の結果を思う方向へ動かせる。著者らはこれを「本文とベクトルの整合性の穴」（text-vector integrity gap）と呼んだ[1]。公開されたリポジトリの説明では、想定する攻撃者は、乗っ取られた発行者か、保存されたベクトルを書き込める立場の者である[2]。

同じ著者らは前作で、正しく署名された毒入りのパックが、パック単位の確認をすべて通ってしまったと報告していた[3]。今回の論文は、その問題のうち「ベクトルが本文と食い違う」という部分に絞って、どれだけ危ないかを測り、どう塞ぐかを示そうとしている。本記事が扱うのは arXiv に公開された査読前のプレプリントであり、以下は著者らの主張として読む。

2. 何を提案しているか

手法の芯は、浮動小数点のベクトルを「許容誤差つき」で照合するのをやめ、量子化したあとの符号を照合することである。素直な対策は、機器の側で本文からベクトルを計算し直し、パックのベクトルと比べることだ。ただし同じモデルでも、計算機の種類や一度に処理する件数が違うと、ベクトルの値はわずかにずれる。著者らは、一般的な浮動小数点や動的な INT8 の推論は、バッチの大きさや計算機の構造が変わるとビット単位では一致しないことを確かめている[1]。だから照合には「コサイン類似度がこの範囲なら同じとみなす」という許容幅が要る。

問題は、その許容幅がそのまま攻撃者の取り分になることである。著者らは、許容幅の内側でベクトルをずらしたときに検索結果を乗っ取れる質問の割合は、検索の「角度の余裕」（正解の文書と次点の文書の間の角度の差）の分布で決まると示し、これを margin law と名づけた[1]。

そこで著者らは、照合の対象を、量子化して得られる符号に移す。値が境目に近くてどちらの符号にもなりうる場合は、発行者ではなく検証する側が決める。そのうえで、較正したガードバンド（境目の周りの保留帯）と、表現を一つに揃える正規化を組み合わせる。こうすると、発行者が複数の表現の中から都合のよいものを選ぶ余地がなくなる、と著者らは述べている[1]。

3. 何を示したか ── abstract に書かれた範囲だけ

abstract が示す結果は、許容誤差による照合の弱さ、圧縮したベクトル索引の監査の弱さ、符号照合の結果、の三つに分けられる[1]。

このほか、回答を控える仕組み（abstention）、文脈の刈り込み、意味に基づく選別という三つの対策について、事前登録したうえで効果が出なかった結果も報告している。

4. 具体例で見る

製薬企業の医薬情報の部門が、電波の届きにくい場所でも使える質問応答の端末を用意し、添付文書や社内の Q&A を知識パックとして配る場面を考える。以下は説明のための仮定であり、論文の実験ではない。

情報システム担当：「知識パックには署名を付けています。端末は署名が正しくないパックを受け付けないので、改ざんの心配はありません」
品質保証担当：「署名で分かるのは、配ったのがうちの部門だということですよね。パックの中のベクトルが本文どおりに計算されたものかは、どこで確かめていますか」
情報システム担当：「端末で本文から計算し直して、近ければ同じとみなしています。端末によって値が少しずれるので、幅を持たせています」
品質保証担当：「その幅の中で、別の文書が先に出るようにずらされたら、照合は通ってしまいませんか。本文は正しいのに、質問に対して違う文書の答えが返ることになります」

品質保証担当が突いているのが、論文の言う整合性の穴である。論文の提案は、照合の基準を量子化後の符号に移し、境目の判断を検証側が持つことで、この幅を攻撃者に渡さないようにするものだ。

5. 何が新しくないか／限界はどこか

「署名は発行元を保証するが内容の正しさは保証しない」という区別自体は、情報セキュリティでは以前から知られている。直積量子化が近似であり、圧縮した索引が元のベクトルを完全には再現しないことも、FAISS の解説で述べられている性質である[5]。この論文が加えたのは、その区別がオフライン RAG で具体的にどれだけの質問を危険にさらすかを margin law として量で示した点と、許容幅を使わずに照合する手順を示した点にある。

限界は少なくとも四つある。第一に、この論文が塞ぐのはベクトルと本文の食い違いであって、本文そのものの誤りではない。前作が示した「正しく署名された毒入りの本文」は、符号を照合しても見つからない[3]。第二に、符号照合が正直なベクトルをすべて受け入れたのは「著者らの試料で」「三つのプラットフォームで」の範囲であり、どの機器・どのモデルでも成り立つとは abstract からは言えない。第三に、端末で本文からベクトルを計算し直す費用が abstract には書かれていない。前作では、端末でパックの文章を埋め込む処理に、署名の確認よりはるかに長い時間がかかっていた[3]。第四に、実験の題材はリポジトリの説明によれば SQuAD をもとにしたコーパスであり[2]、専門文書で角度の余裕がどう分布するかは別に確かめる必要がある。

6. この主題が今なぜ束になっているか

結論から言うと、この論文は束になっていない。収集の仕組みの中で同じ問いを扱う論文は見つからず、束の大きさは 1 だった。Hugging Face での票は 4、コメントは 6、GitHub のスターは 1 である。当サイトの設計は、互いに独立した複数の信号が同時に立ち上がった状態を hot topic と定義しているが、この論文はその条件を満たしていない。選ばれたのは、読者の議論が比較的活発だったという単独の信号による。票やスターは話題性を測る数字であり、正しさや重要さを測るものではない。

それでも主題として扱う理由はある。生成 AI を端末に載せて、ネットにつながらない場所で使う動きがあり、同じ著者らの前作もその設定を扱っていた[3]。端末側の RAG では、ベクトルをあらかじめ計算して配るほうが端末の負担は軽い。その便利さと引き換えに、人が読まない数字の正しさをどう担保するかという問いが残る。この論文は、その問いに具体的な測り方を一つ与えた例として読める。

7. 製薬・規制の現場から見ると何が接続するか

最も近い接続先は、データインテグリティの考え方である。製薬の品質保証では、電子署名は「誰がその記録に責任を持つか」を示すものであり、記録の中身が正しいかどうかは別の手順で確かめる。この論文が示したのは、同じ区別が RAG の知識パックにも当てはまるということだ。署名の確認を通ったことを、パックの中身が正しいことの証拠として扱うと、ベクトルの細工という抜け道が残る。

もう一つの接続は、コンピュータ化システムのバリデーションで「同じ入力から同じ出力が得られるか」を確かめる手順である。著者らは、推論がバッチの大きさや計算機の構造でビット単位では一致しないことを示した。つまり、端末ごとに埋め込みの値がわずかに違うことは前提として扱う必要がある。

この論文から、医薬情報の端末をどう設計すべきかが直接導けるわけではない。言えるのは、署名で確かめられるのは発行元までであり、ベクトルが本文どおりかは別に確かめる必要がある、というところまでである。符号照合がその手段になりうるかは、著者らが公開したコードで、自社の文書と端末を使って確かめてから判断することになる。