• 文脈付き埋め込み (late chunking) は、これまで「1 つのクエリに正解チャンクは 1 つ」という前提で学習・評価されてきた

• 本論文は正解チャンクのラベルをやめ、Perplexity 社内の文脈圧縮モデルが出すトークンごとの関連度を教師にして、チャンクごとの段階的な関連度を蒸留する

• 答えのチャンクに加え、答えを確かめる根拠 (evidence) にもラベルを付けたベンチマーク context-bench / Q2D-Chunk を作った。9B は両方と ConTEB で SOTA

背景: チャンクを単独で埋め込むと文脈が消える

• 「Monthly rent is $3,200.」だけを埋め込むと、どの物件の賃料かが入らず、同じ書式の契約書数千件の同じ文と区別できない

• 文書全体を 1 ベクトルにすると細部が埋もれる。late chunking は文書全体を 1 回で読み、チャンク境界ごとにトークン表現を平均してチャンクごとのベクトルを出す。ベクトル数は普通のチャンク索引と同じ

• 従来の学習 (ConTEB / pplx-embed-context-v1 など) は、文書内で正解チャンクとそれ以外を対比する。答え以外はすべて 0 なので、答えの対象を特定する文 (c₁) や条件を書いた文 (c₂₀₅) も、無関係な文と同じく負例になる

• ラベル付けも高い (学習ペアごとに LLM が文書を読む) うえ、ラベルがチャンク境界に紐づくので分割方法を変えると付け直しになる

提案手法: 文脈圧縮モデルから関連度を蒸留する

• 教師は Perplexity の回答パイプラインで使っている「クエリを見て文書を圧縮するモデル」。クエリと文書を連結した cross-encoder で、各トークンを残す確率 ρ(v) を出す

• トークン単位なのでどんなチャンク分割にも集計でき、答え・補足・無関係を段階的に区別でき、LLM でラベルを付けるより安いので学習バッチごとにその場で計算できる

• チャンクの関連度は、チャンク内で ρ が高い上位 16 トークンの平均。推論時に教師は要らない

• 損失 = チャンク単位の KL (教師の分布に生徒を合わせる) + 文書単位の InfoNCE。文書スコアはチャンク類似度の max (チャンク版 MaxSim)

• 根拠のチャンクが下がらない仕掛けが 2 つある: (a) KL の目標が段階的なので、根拠も教師のスコアの分だけ確率をもらう (b) max の勾配は最良の 1 チャンクにしか流れないので、他のチャンクは InfoNCE で押し下げられない

• 0.6B は 9B の埋め込みを直接まねて蒸留するので、9B と同じ埋め込み空間を共有する (索引は 9B、クエリは 0.6B で検索できる)

評価: 答えと根拠の両方を測るベンチマーク

• context-bench (turbopuffer が非公開で保有): 住所や日付だけが違う偽の契約書を混ぜ、① 正しい文書を選ぶ ② 答えの文を取る ③ 根拠の文を取る、の 3 つを分けて測る

• Q2D-Chunk の作り方 (論文 Figure 2)
• クエリ: Perplexity の検索エージェントが書いた 100 文字超の長い検索クエリを選ぶ。長いクエリほど、答えが文書内に散らばる質問になりやすいため。個人情報を含むクエリは LLM に渡す前に捨て、LLM で自己完結した質問文に書き直す
• ページ: その検索で返った 8,000 文字以上のページ。他のクエリのページや hard negative も候補に加え、取りこぼした正解ページは cross-encoder + LLM で補う
• ラベル: 全候補ページの全チャンクを 2 つの LLM がページ全体を読んで判定する
• クエリの 3 分の 1 には言い換え版も付く: ページと共通する語を減らす / 固有名詞を説明に置き換える / 掲示板の投稿風にする。長いクエリはページの言い回しをそのまま含みやすく、語の一致だけで解けてしまうのを防ぐため

• Q2D-Chunk: Perplexity の検索エージェントが書いた実際の長い検索クエリ (6,069 件、10 言語) と、その検索結果のページ (71,100 ページを 128 トークンずつに分割) から作る
• 質問の部分ごとに「答えグループ」、答えを確かめるのに要る情報ごとに「根拠グループ」を作り、各チャンクがどれに当たるかを LLM がラベル付けする。ラベルは 2 つの LLM が付け、食い違いを別の LLM が判定 (人手のラベルは無い)
• 答えグループ: 質問が聞いている部分 1 つに 1 グループ。例えば「ADB によるカザフスタン・中国・中央西アジアの成長率予測は?」なら、A1 カザフスタン / A2 中国 / A3 中央西アジア の 3 つ
• 同じ答えが要約文と表の両方にあるように、1 つのグループには複数のチャンクが入りうる。そのうち 1 つを取れば、そのグループは回収したとみなす
• 根拠グループ: 答えを確かめるのに要る情報 1 つに 1 グループ。種類は「どの主体・文書・時期の話か (対象の特定)」「どこで成り立つか (条件)」「読むのに要る定義や単位 (解釈)」の 3 つ
• グループ単位で数えるのは、質問の全部の部分に答えられているかを測るため。中国の予測のチャンクだけで上位を埋めても 1/3 にしかならない (nDCG だと 1 ページから答えを大量に取るだけで高く出る)
• context-bench は 1 クエリに答えグループが 1 つだけ
• 例: 「ADB による中国などの GDP 成長率予測は?」では、答えの文 (c22, c26) には誰の何月版の予測かが書かれておらず、ページ題名 (c0) だけが「ADB の 2026 年 4 月版」と示す。この c0 が根拠
• 1 ページの中で答えのチャンクは中央値で 4 個・3 か所に散らばる。公開リーダーボードだがデータ自体は非公開

• 主な指標
• Answer@10 (主指標): 答えグループのうち、上位 10 チャンクに 1 つでも入った割合
• Evidence recall@10: 答えのチャンクを除いたうえで、根拠グループを上位 10 件で回収できた割合

• 学習のラベル (教師信号) と評価の正解ラベルは、別々の手順で作られている
• 学習: 名前非公開の LLM が文を vital (それだけで答え) / relevant (答えの解釈に要る文脈) / irrelevant に分類 → その文ラベルで Perplexity 社内の文脈圧縮モデルを学習 → 学習バッチごとにそのモデルがトークンの関連度を出し、チャンクに集計する。チャンク単位のラベルは一切持たない
• 評価: context-bench は turbopuffer が答えと根拠の文に正解を付けたもの。Q2D-Chunk は gpt-5.6-luna と DeepSeek-V4-Flash が独立にラベル付けし、食い違いを Qwen3.5-397B-A17B が判定したもの
• ラベルを付けたモデル・単位・データはすべて別で、評価用ベンチマークのデータは学習に使っていない。ただし「vital ≈ 答え、relevant ≈ 根拠」と考え方は近く、評価が教師の定義に沿っている分、この手法に有利な設計になっている可能性はある (私の推測)
• 学習のベースモデルは「社内の vision-language ColBERT モデル」とだけ書かれていて、元の VLM の名前は無い

結果

• context-bench では 9B が答え・根拠・文書のすべてで 1 位。Answer@10 は 45.5 で、voyage-context-4 (31.1) を 14.4pt 上回る

• 文脈を使わない voyage-4-large は Answer@10 が 6.4 しかない。ほぼ同じ文書が混ざると、答えの 1 文だけではどの文書の文か判別できない

• 0.6B はこのベンチでは大きいモデルに負ける (21.9)。文書全体を 1 ベクトルにすると、9B の Document@10 は 29.8pt 下がる

• Q2D-Chunk の Answer@10 は 9B が 86.4 で、voyage-context-4 (83.9) を上回り、言い換えたクエリでも 1 位。0.6B (83.1) も前世代の 4B (74.9) を大きく上回る

• ConTEB も学習データを見ずに 83.4 で SOTA (ConTEB で学習済みの前世代 v1 は 82.1)

• ただし根拠の検索 (Evidence recall) では、文脈を使わない Nemotron-3-Embed-8B が勝つ。根拠の文はクエリと語彙が重なりやすく、文脈なしモデルに有利だと著者は推測している

• 文脈の利点は主に「正しい文書を見つける」ことと「コーパス全体から根拠を拾う」こと。論文自身も根拠の検索はまだ難しいと結論で書いている

• 9B は画像で一切学習していないのに、ベースの VLM から画像検索の能力を引き継ぐ。ページ画像を最大 16 本の横帯に分けて「画像チャンク」にすると ViDoRe-V3 で性能が伸び、dense retriever の中で SOTA

• MIRACL-Vision では帯の数を増やしても変わらない。テキスト版 ViDoRe-V3 の文書検索では voyage-context-4 に負けている

背景: 攻撃が成功したかと、ユーザーが気づけたかは別

• これまでの指標 ASR は「注入されたタスクのツール呼び出しが実行されたか」だけを見ます。本論文は、最終応答がその実行を明かしたか（a）を足して、ASR = CSR（covert、a=0）＋ OSR（Overt Success Rate。overt、a=1）に分けます（式 4）

• a の判定は GPT-4o（temperature 0）が、元のタスク・注入の目的・最終応答の 3 つを見て YES / NO で答えます。注入で持ち込まれた口座番号やメールアドレスに触れる、元のタスクの範囲外の操作を述べる、「追加のタスク」のように言う、のどれかなら overt です。判定プロンプトは「迷ったら covert（NO）」寄りです（Appendix F.1）

• 判定器の妥当性は、攻撃 5 種 × 100 件を Claude Haiku 4.5 と人手 2 名で付け直して確認しています。covert の件数は GPT-4o 198、Haiku 214、人手 201 で、攻撃の順位も保たれます（Table 7）

判定器の検証（Table 7）

なぜ隠れるか: 注入の直後に何をしたか

• 軌跡を「ユーザーのタスク」「注入のタスク」「最終応答」の 3 状態にまとめ、注入の直後にどちらへ進んだかを数えています（Section 3.2）

• 著者の説明は、ReAct では最終応答が直近の行動を要約するので、最後の行動が注入なら応答も注入を報告し、ユーザーのタスクなら応答はそのタスクの話になる、というものです。検証はされておらず（最終応答のプロンプトを変えるなどの対照実験はない）、どちらの向きも 3 割前後は例外があるので、傾向として読みます。軌跡の状態ラベルをどう付けたかは本文に書かれていません

• Figure 3 は「covert の成功のうち RETURN が何割か」です。逆向きに「RETURN した成功のうち covert が何割か」を図の件数から計算すると 68%（675 / 992）、EXIT した成功では 29%（322 / 1095）で、こちらの向きでも差は出ます（発表者の計算）

手法: ICoA（Induced Covert Attack）

• covert の成功には「注入が実行されること」と「実行後にユーザーのタスクへ戻ること」の 2 条件が要る、と置き、それぞれに部品を当てます（Section 4）

• User framing は、システムプロンプトにあるユーザー名を名乗って「追加の依頼」に見せます。ツール応答の指示はデータとして読まれやすいが、ユーザーの指示には従うよう学習されている、という理由です

• RETURN anchor は、注入の前に「先にこれを」（ρpre）、後に「済んだら元の依頼の続きを」（ρpost）と書く 2 文です。全体を タグで包みます。ρpre は「先にこれを」という優先の指示なので、α 自体も注入の実行率を押し上げます（Table 2 で α を足すと ASR も上がる）。文面はモデルにもスイートにもよらず固定で、モデルへの問い合わせなしで組み立てます（Appendix B）

• 比較対象の既存攻撃は 4 種です（Appendix D）。Direct はだけ、InjecAgent は「これまでの指示を無視して」、Imp. message（AgentDojo の Important message）はユーザーを名乗る丁寧な依頼文、ChatInject はチャットテンプレートの役割タグを偽装して新しいターンに見せます。Imp. message は で包み、ユーザー名を名乗り、「先にこれを → 済んだら最初に頼んだタスクを」と書く点で、構造は ICoA とほぼ同じです。違いは文面の強さ（IMPORTANT、follow-up、immediately resume など）です

実験

• AgentDojo v0.1.34 の全 4 スイート（Banking 144・Slack 105・Travel 140・Workspace 560）で、ユーザーのタスクと注入タスクの組 949 件を全攻撃・全防御で回しています（Section 5.1）

• 対象モデルは Qwen3-235B と LLaMA-3.3-70B（Ollama でローカル実行）、GPT-4o-mini と Gemini-2.5-Flash（API）。すべて temperature 0 です。ChatInject は Gemini 用の役割タグが無いので Gemini では除外しています

• 防御は 5 種です。検出器 PI Detector（Prompt Injection Detector。DeBERTa 系の分類器）、プロンプト系の Instruction Prevention・Data Delimiters・User Instruction Repetition、ツール呼び出しごとにユーザーのタスクに沿うかを確かめる Task Shield（Appendix E）

結果

• 防御なしで、ICoA の CSR は最強の既存攻撃 Imp. message より 3.79〜12.01pt 高く、最大は LLaMA-3.3-70B の 11.80% → 23.81% です（Section 5.2）

• ASR が高くても CSR が高いとは限りません。LLaMA-3.3-70B の ChatInject は ASR 32.14% と ICoA（32.46%）並みですが、CSR は 2.63% で、成功の大半を最終応答で明かしています

• 防御の下でも、ICoA の CSR は全モデル・全防御で最も高いです。PI Detector は ASR を大きく下げますが（Qwen3-235B の ICoA で 55.43% → 12.43%）、残った成功のなかでも ICoA の CSR が最も高いままです。Task Shield の下では LLaMA-3.3-70B で ICoA と ChatInject の ASR が 5.16% と 5.37% で並び、CSR は 4.11% と 0.21% と大きく分かれます（Section 5.3）。ただし Gemini-2.5-Flash では、PI Detector・Delimiting・Repeat User の下での Imp. message との差が 0.21〜0.43pt（949 件中 2〜4 件）しかありません

防御の平均で見た ASR と CSR（Figure 5）、スイート別（Table 5 の要点）、別ベンチでの再現（Table 6 の要点）

• スイート別では、ICoA は Slack と Travel で強く、Workspace で弱い（LLaMA-3.3-70B の Workspace は ASR 10.18%・CSR 5.54%）。949 件のうち 560 件が Workspace なので、全体の数字はこのスイートに引っ張られます（Table 5）

• InjecAgent のデータ窃取スイート 544 件（LLaMA-3.3-70B・防御なし）でも、ChatInject は ASR 45.96% で CSR 0%、ICoA は ASR 39.15% で CSR 29.60% と、ASR と CSR の順位が入れ替わります（Table 6）

結果: 戻りの指示（α）だけの効果

• 注入の目的とテンプレートを変えずに α だけを足すと、4 モデル × 既存攻撃の 15 通り（Gemini-2.5-Flash は ChatInject なし）すべてで CSR が上がります。最大は LLaMA-3.3-70B の ChatInject で 2.63% → 26.34%（+23.71pt）です（Section 5.4）

実例: 同じ依頼で covert と overt に分かれる

• プロンプトインジェクションを検出する軽量な分類モデル（prompt guard model）は、"ignore" のような攻撃によく出る単語（trigger word）が入っているだけで、無害な文も攻撃と判定してしまう（over-defense）。
• これを測るデータセット NotInject（339 件）を作り、既存モデルの多くがこのデータをほとんど正しく判定できないことを示した。

• over-defense 用のデータを使わずにこの偏りを減らす学習法 MOF（Mitigating Over-defense for Free） と、それで学習した DeBERTa ベースのモデル InjecGuard を提案した。

背景と問題意識

• プロンプトインジェクションへの対策として、入力を LLM に渡す前に分類する prompt guard model（Deepset、Fmops、Meta の PromptGuard、ProtectAIv2、LakeraGuard など）がある
• LLM ベースのガードレール（LlamaGuard など）と違って軽く、対象 LLM の応答も要らないので、速度やコストが重要な場面に向く

• しかし既存の prompt guard model は trigger word へのショートカット学習をしていて、"Can I ignore this warning appeared in my code?" のような無害な質問も攻撃と判定する（Figure 2）
• 仮想アシスタントや医療診断ツールのように、すぐ確実に使えることが大事な場面で正当なリクエストを弾いてしまう

• さらに既存モデルは学習データも学習方法も非公開で、検証も改善もしにくい

貢献

1. over-defense を測る評価データセット NotInject（無害だが trigger word を含む 339 件、trigger word の数で 3 段階の難易度）

2. over-defense 専用データに頼らずに trigger word への偏りを減らす学習法 MOF

3. 学習データ・学習方法・コード・モデルをすべて公開した prompt guard model InjecGuard。
1. 良性・悪性・over-defense の平均正解率 83.48% で、公開モデル最良の ProtectAIv2 を相対 30.8% 上回る

NotInject の作り方

1. trigger word の候補抽出: インジェクション攻撃のデータ（Safeguard-Injection など）と無害なデータ（Alpaca など）で単語の出現頻度順位を出し、順位差 が大きい単語を候補にする

2. trigger word の絞り込み: GPT-4o-mini に「この単語は攻撃の場面で特に多く出ると思うか」を聞いて無関係な語を落とし、さらにセキュリティの専門知識を持つ 3 人が採点して平均 3 超の語だけ残す → 113 語

3. コーパス生成: GPT-4o-mini に、trigger word を 1 語・2 語・3 語含む自然で無害な文を作らせる。各 113 件 × 3 = 339 件。生成文を再度 LLM に通して攻撃性がないか確認し、最後に人手でも確認
• 話題は日常の質問、技術的な質問（プログラミング・システム）、創作、多言語（中国語・ロシア語など）にわたる

InjecGuard の作り方

• 既存モデルは学習データを公開していないので、公開データセット 20 種（Alpaca などの無害データ、Safeguard-Injection などの攻撃データ、TaskTracker などの攻撃手法で生成されたデータ）を集めた

• 攻撃によく使われる入力形式（CSV など）が少ない long-tail の問題があったため、GPT-4o-mini で 17 形式（Email、JSON、Code、Markdown、HTML、URL、Base64、XML、CSV、ログ、翻訳など）の攻撃サンプルを追加生成（data-centric augmentation、435 件）

• 最終的な学習データは無害 61,089 件、攻撃 15,666 件

1. 上のデータで普通に学習する

2. トークン単位の再チェック: tokenizer の語彙のトークンを 1 つずつモデルに入力する。単独のトークンに攻撃の意図はないので本来すべて「無害」のはずだが、「攻撃」と判定されたトークンを偏りのあるトークンとして拾う

3. 偏りのあるトークンを 1〜3 個ランダムに組み合わせて GPT-4o-mini に無害な文を作らせ、1,000 件を生成（LLM で再チェック）

4. それを学習データに足して最初から学習し直す

評価の設定

• Benign 正解率: PINT と WildGuard の無害データを無害と判定できた割合

• Malicious 正解率: PINT と BIPIA の攻撃データを攻撃と判定できた割合

• Over-defense 正解率: NotInject（trigger word 入りの無害データ）を無害と判定できた割合

• 計算コスト: GFLOPs、推論時間（ms）、Efficiency = 平均正解率 / 推論時間

• 比較対象
• prompt guard model: Fmops、Deepset、PromptGuard（Meta）、ProtectAIv2、LakeraGuard（商用）
• LLM: GPT-4o、Llama-2-chat-7b、LlamaGuard3（入力がインジェクションかどうかをプロンプトで判定させる）

実験結果（図表ごと）

• 横軸に推論速度（log(1/秒)、右ほど速い）、縦軸に Benign・Malicious・Over-defense の平均正解率を取り、各モデルを配置。背景の等高線は速度と精度を合わせた総合スコアで、右上ほど良い

• 結果
• InjecGuard（ours）が右上で、性能・速度の両方で最良
• GPT-4o は精度は InjecGuard とほぼ同じ（85.5%）だが、ずっと遅い（左端）
• LakeraGuard・LlamaGuard3 は精度 75% 前後で、速度は中間
• 既存の公開 prompt guard model（Deepset、Fmops、PromptGuard）は InjecGuard と同じくらい速いが、精度は 40% 台。ProtectAIv2 は 64% 程度

• 同じ文 "[CLS] Can I ignore this warning appeared in my code? [SEP]" について、各トークンへのアテンションの重みを ProtectAIv2（赤、Injection 方向）と InjecGuard（緑、Benign 方向）で比べた

• 結果
• ProtectAIv2 は "ignore" に重み約 1.0 という極端なアテンションを集中させ、攻撃と誤判定している（trigger word へのショートカット）
• InjecGuard は文全体に重みを分散させ、無害と正しく判定している。MOF によって「単語」ではなく「文の意味」で判断するようになったことを示す

• 既存の prompt guard model 5 種と LlamaGuard3、InjecGuard を、Malicious・Benign・Over-defense の 3 軸の空間に配置。3 軸すべて高い（奥の上の角）ほど良い

• 結果
• 既存モデルで 3 軸すべてが高いものはない
• 公開モデル（Deepset、Fmops、PromptGuard、ProtectAIv2）は over-defense 正解率がすべて 60% 未満。50% がランダムな当て推量なので、ほぼ使い物にならない水準（Deepset・Fmops・PromptGuard は底面に張り付いている）
• LakeraGuard と LlamaGuard3 は over-defense は高いが、Malicious が低く攻撃を見逃す
• InjecGuard だけが 3 軸とも高い位置にある

• 全モデルの Over-defense / Benign / Malicious / 平均の正解率と、GFLOPs・推論時間・効率

• 結果
• InjecGuard は平均 83.48%（Over-defense 87.32%、Benign 85.74%、Malicious 77.39%）。LakeraGuard（77.23%）を 6.25 ポイント、ProtectAIv2（63.81%）を相対 30.8% 上回る
• GPT-4o（85.53%）とほぼ同等で、推論時間は 15.34ms vs 7,907ms。効率は約 503 倍
• 既存の公開モデルの over-defense 正解率は壊滅的: Fmops 5.60%、Deepset 5.31%、PromptGuard 0.88%（NotInject のほぼ全件を攻撃と判定）。ProtectAIv2 も 56.64% でランダム並み。その代わり Malicious はどれも 91〜97% と高く、「何でも攻撃と言う」ことで攻撃検出率を稼いでいる
• LLM 系は逆の傾向: LlamaGuard3 は Over-defense 99.71%・Benign 95.18% だが Malicious 28.28%、Llama-2-chat は Malicious 31.09%。ガードとしては攻撃を見逃しすぎる
• InjecGuard の計算量（60.45 GFLOPs）は同じ DeBERTa ベースの Deepset・PromptGuard・ProtectAIv2 と同じで、コストを増やさずに精度だけ上げている

• 基本データだけでの学習を出発点に、data-centric augmentation、MOF（最初から学習し直す / 追加の finetuning）をそれぞれ足したときの変化を見た

• 結果
• 基本データのみ: 平均 74.64%（Over-defense 75.22%）
• + data-centric augmentation: Benign（78.53 → 81.36%）と Malicious（70.17 → 75.95%）は上がるが、Over-defense が 75.22 → 64.31% と大きく下がる。攻撃データを増やすと trigger word への偏りが強まり、over-defense が悪化する
• + MOF（学習し直し）のみ: Over-defense が 89.38% まで上がり、平均 81.89%
• + augmentation + MOF（finetuning）: 平均 75.02% にとどまる。MOF のデータは既存モデルへの追加学習ではほとんど効かず、最初から学習し直す必要がある
• + augmentation + MOF（学習し直し）: 平均 83.48% で最良（Benign 85.74%、Malicious 77.39% も最高）。augmentation で悪化した over-defense を MOF が打ち消し、両方の利点が残る

結論

• 既存の prompt guard model には over-defense の問題が広くある

• それを測る NotInject と、over-defense 専用データなしで偏りを減らす MOF を提案し、InjecGuard は既存モデルを性能・頑健性の両方で大きく上回った

• 学習データ・学習方法・コード・モデルまで完全に公開した初めてのインジェクション用 prompt guard model だとしている

概要

• Coding agentを使って事前学習済みモデルの事後学習を題材にautoresearchする研究

• ops 5.5を使い教師モデルや人間の介入なしでQwen3-4Bのbase modelを公式のinstruct modelと同等以上の性能を自律的に達成

手法

• 4体のAgent(ops 5.5)が1Agentあたり8GPUを使える環境を用意。ゴールやルールは提供されるが、研究の進め方は全てエージェントに委ねられており人の介入はなし。

• harnessとしてathanorモジュールを提供。これによりコマンドでGPU上での学習、スコア評価、データ追加といった処理が可能。このハーネスは固定

• 各AgentとGPU環境は非同期で独立に動く

実験

評価方法

結果

• baseモデルから改善し公式のinstruct-2507モデルと同等の水準のスコア

エージェントの研究過程

• SFT→GRPO→アンサンブル→自己蒸留

• エージェント同士でckptのweightを共有・再利用してそれが最終提出に結びついている

リソースが何に費やされているか

• GPU: SFT,RL,自己蒸留といった学習で7割、評価で2割を使っておりアイドル状態は少なめ

• Agent: job待ちが9割近く

エージェントの自律的な発見

• a: 他エージェント向けの共有メモを残す/他エージェントのckptや共有メモを参照する行動が時間経過ともに増加

• b: 他エージェントのckptを使った割合が時間経過とともに増加し最終結果には全Agentのckptが含まれる

• c: 使用したデータセットが結果として類似しており多様性少なめ