広聴AIのパブコメDDoS攻撃対策の議論
3行まとめ by ChatGPT.icon
攻撃レベル1〜4を定義し、まず「テンプレの一部変更」（レベル2）を編集距離やembeddingでフィルタするクイックウィンデモを作成する方針
tokoroten.iconがSentence Transformer＋コサイン類似度で重複排除実装を共有し、閾値調整やDBSCAN／AgglomerativeClustering適用案を議論
最終的に「類似度閾値でマージした際のデータ量削減率」を示すスライドを作成し、100万～300万件規模を一晩で処理可能なバッチ要件を確定、PR提出とテストデータ生成へ
nishio.icon
パブコメ大量投稿攻撃にはレベルがある
1: 単なるテンプレ同一文言: 同一かのチェックでフィルタ容易
2: テンプレの一部変更: 編集距離ベースでフィルタ容易, embeddingでもいけると思う
3: 同一プロンプトからのLLMで複数人が生成(ここから対処が難しくなってくる)
4: 十分賢い単一のLMMが適切に散らばらせて意見生成
前回bikeshedデータセットで僕がやったのは4の対処が困難ということ、nasukaさんが今やってるのは3だと思う。2はイージーだと思うのでクイックウィン的にまずこれをやっつけるデモをつくろうかと思った。
tokoroten.icon
tokoroten.icon
スレの上の方にパブコメのデータがあるので、これでちょっと重複排除をやってみます。
https://gyazo.com/048a54ace3137805f49e6b010afa8e13
nishio.icon
着地点として「コサイン類似度x以下の意見をマージすると全体のデータ量がxx%に減る。コサイン類似度xとはたとえばこの意見とこの意見の類似度だ」という1枚スライドがあると広報の武器になりそう
tokoroten.icon
環境のほうのもやってみた。
nishio.icon
これってフィルタリングして数を減らすところまでやってくれる感じですか？(そこのアルゴリズムは気になってる)
tokoroten.icon
現状の実装は次の通りです。
- N個の文章に対して、それぞれエンベデッドベクトルを求める
- エンベデッドベクトルを掛け算して、N*Nのコサイン類似度の行列を求める
- コサイン類似度行列を舐めて、閾値以上のインデックスを拾ってくる
- 対象のインデックスの値を出力する
そのため、フィルタリングや、集約はやっていません。
コサイン類似度行列を距離行列（の逆数）だとみなせば、DB-SCANなどの距離ベースのクラスタリングアルゴリズムが適用できるはずです。 （編集済み） 出てきた表から、IDが若いものを活かして、大きいものを除去する、というようにすれば、実質的に集約になると思います。
とりあえず、目視で閾値をどれくらいにするべきかを見てくるか
nishio.icon
こういうのはどう？
距離行列を作る
各クラスタから適当に(or クラスタ中央付近の)代表データを選出
フィルタしたCSVと、各代表店にマージされて消えたデータに関するレポートを出力する
カットの閾値はユーザが選択できるようにするか、3パターンくらい出力して選んでもらうか
tokoroten.icon
おっと、コードが間違ってて、要約文の類似度をしていた。原文の類似度を出すコードに修正した。
tokoroten.icon
とりあえずそれっぽいことはできました。
コード
nishio.icon
いいですね、この後どう着地するイメージですか？
tokoroten.icon
現在は、これの検証ができた状態なので、ここから先はどなたかにお願いしたいです。
（午前中のミーティングがキャンセルになったので、目についた課題で遊んでいただけなので……）
tokoroten.icon
とはいえ、これだと現在のいどばたと同じものが出来上がってしまっただけだなぁ……
nishio.icon
いちおうPRのこの承諾がもらえればPRがあってマージしたという扱いにできると思う
本リポジトリへのコントリビュートには、コントリビューターライセンス契約（CLA）に同意することが必須です。 内容をお読みいただき、下記のチェックボックスにチェックをつける（“- [ ]” を “- [x]” に書き換える）ことで同意したものとみなします。
あとは引き継いで適当に加工して適当なところに格納しときます
tokoroten.icon
はい、同意しますので、よろしくお願いいたします。
この辺の文脈だったのかと、今更レポジトリを見て理解しました
tokoroten.icon
なんとなくのメモ
- 類似するパブコメを集約するには、埋め込みベクトルで距離が一定以下のものが一定数あるか、という判定が必要、総当たりなのでO(N^2)
- 新規にコメントが入ってきたときに、既存コメントの全件のマッチングを行って距離が一定以下のものを探すのはコストが高いが、それでもO(N)の世界
- すでに文脈埋め込みベクトルがあるのであれば、10万件くらいまでなら全件舐めても余裕かも
- アプローチによる戦略の違い
- 既存コメントの距離ベクトルの計算はO(N^2)、クラスタリグはそれより上のオーダー
- 代表点に集約してからクラスタリングをしたほうが良いので、前処理が必要
- 新規コメントが追加されたときに重複判定をするのはO(N)なので、愚直なアルゴリズムで良い
- 既存のコメントを全部ベクトルDBに詰めてしまって、近傍探索に投げるでもよい （編集済み）
nishio.icon
HNSWで計算量を下げるのは(例えばローカルqdrantに突っ込むなど)手ではあるが、想定されるユースケースが「省庁がパブコメを締め切ったら100万件あった、職員が手で作業する前に前処理したい」というものだと思うので、重たいバッチを1回走らせて翌日に結果が得られれば十分だと考えると高速化のニーズはそれほど高くないのではいか。 むしろ素朴な方法でもHNSWでもメモリ要求量が問題になりそうではある、一般職員のマシンで動かそうとしないで欲しい気はする
tokoroten.icon
なるほど、そうすると、こんなのが要件になる感じでしょうか。
- 1000万件のデータを一晩くらいで処理できる
- pythonのコードをexeで固めて、一般職員のマシンで実行できる
- 一般職員のマシンで実行できる程度のメモリ消費量（10GB程度？）
- ディスクは数十ギガを使ってよい
nishio.icon
(二人とも余裕を持った要件にした結果、観測されてるものの2桁デカい処理能力になってるけどw)
一般職員のマシンがどの程度のものかはよくわからないな感がある、OSSのexeを実行できるのかは怪しい
とりあえずファーストアクションとしては、我々のいないところで実行可能なバイナリを作るより、すでに手元にあるパブコメデータで「こういう出力が出せる」と省庁に対して説明できる形にすることじゃないかな
安野貴博.icon
横からですが、１０００万件はなくても大丈夫そうではあります（１００万件いければいけそうです！）
今の最大集まったパブコメが３０万件ぐらいだったと思うので
nishio.icon
yes、僕が安全係数かけて100万って言って、ところてんがさらに安全係数をかけて1000万にしたからかなりオーバーキルの仕様になったw
tokoroten.icon
ひとまずPRを切っておきました。
tokoroten.icon
とりあえず、邪悪なテストデータが欲しいので、100万件くらいまで増強されたデータが欲しいです。 ローカルLLMにやらせようかな……
nishio.icon
邪悪なテストデータ、作りたいよね(朝作りかけてその後ダウンした)
tokoroten.icon
nishio.icon
ここにGPT4.5で生成したものがあるけど、GPT4.5が生成すると「うまく散らばってて解決できなさそう」という気持ちになった
あーこれ、分析結果のリンクがその後のセットアップで変更されてて見れないな
nasuka.icon
小規模ですが、環境パブコメを337件 -> 447件まで増やしたデータもこちらに置いています。
環境パブコメの77種類のクラス（=要約カラム）のうち1クラスだけを指定して、LLMでデータ拡張しています。 （編集済み）
nasuka.icon
tokorotenさんのスクリプトで上記のデータ拡張したデータに対して重複検知をかけてみましたが、類似度上位のペアはだいたいaugmentationされたもの同士になっていて（もしくはそもそも類似度が高いテキスト）、良い感じですね。
（厳密にはaugmentされたか否かではなく拡張元と拡張先が一致しているかで見たほうが良いですが、内容見る限りは同じことを言っているペアがちゃんと上位にきていそう）
プロダクト導入を考えるとしきい値設定をどうするか問題はありつつ、nishio sanが記載されていたような方向性で解決できる気はするので、embeddingを使ってまとめる方向性は良さそうに思いました。 （編集済み）
https://gyazo.com/02e6bb4b1599e7940b8a7da31b940182
nishio.icon
カットの閾値はユーザが選択できるようにするか、3パターンくらい出力して選んでもらうか
tokoroten.icon
https://gyazo.com/ffe2e5ea9129272b505518605f3dc2ad
（ChatGPTに投げて、金で殴ったほうが早いよなぁと思いつつ）
nishio.icon
おー、なるほど > local LLM
local LLMで無料で使えるようにしてngrokとかでサービスを立てて「ここで生成されてるのを上から使ってね」という扇動をやると効率的に攻撃できるな （編集済み）
tokoroten.icon
LM Studioを立ち上げて、Developper Modeにして、statusをrunningにするだけで、OpenAIの互換サーバが立ち上がります。 （編集済み）
https://gyazo.com/ed9ca6e43230c089d2ab5c571e47b1cf
nishio.icon
投稿するところにCAPTCHAがあって自動化ハードル高いから、そこをネット上の人にさせる構図にしたくなる
tokoroten.icon
文章→文脈ベクトル→文脈ベクトルから文章を再構成、とかで、いい感じの文章ができないかなぁと思って試行錯誤していた。
tokoroten.icon
ローカルLLMによるバリアント作成のコードも、当該PRに入れておきました。
RTX3070で、20件作るのに60秒かかってるので、しんどいなー感ある RTX3070が1枚で20*60*24=28800件/日の邪悪バリアントを作成できるmtane0412.icon
攻撃者がこれだけのコストをかけて作成したものを効率よく捌けること自体が防御になる
これらの邪悪バリアントの投稿の自動化をreCAPTCHAが阻んでいるのでそこも一応壁になっている
一行目が原文、それ以降がLLMが生成した邪悪バリアントです。
めっちゃ面白いmtane0412.icon
ローカルのLM Studioを殴っているコードは以下です。
正直、普通にOpenAIに投げれば良かった、Elyza llama3 8Bでは性能が足りなかった
tokoroten.icon
シングルショットだと、OpenAIのAPIを投げるのも、ローカルLLMも速度はそれほど変わらないなぁ
OpenAIは10並列とかで投げられるので、10倍くらいの速度は出ますが。
tokoroten.icon
ブラウザにinclude されたgemini nanoはまだ英語だけですが、近いうちに日本語対応されると思うので、そうするとブラウザ単体でバリエーションのある文章は生成されるようになると思います。 こんな感じ（自分の手持ちの資料から）
https://gyazo.com/737426903780c90057b944cc318c85fb