• ACL 2026 Open Review

概要

1. optimizer モデルの差は、経由するコーディングハーネスの差より大きい（約 1.8 倍）

2. ネイティブハーネスは一貫して優位ではない（20 ペア中 11 勝 9 敗）

3. ゲインはタスクと seed の性質によって大きく変動する

なぜ「ハーネス最適化」が固有の難しさを持つのか

• 通常のコーディング: テストスイートが安価に「その変更は正しいか」を返す

• ハーネス最適化: 変更の効果を知るには、確率的なエージェントを多数のケースで実行しなければならず、コストが高くノイズも乗る

ベンチマークスイート

全体結果： 正規化ゲイン(seedからの伸びしろ)

RQ1: フロンティアモデルは区別できるか

• タスクとハーネスを固定してモデルを変えると、ゲインは平均 0.142 動く

• タスクとモデルを固定してハーネスを変えると、ゲインは平均 0.079 動く

• → モデルのコントラストは約 1.8 倍大きい

RQ2: 現在の optimizer はどこで力不足か

① 広く探索するほどゲインが大きい

プロンプト / コンテキスト管理 / ステップ上限 / リトライ・タイムアウト方針 / ツールスキーマ / 回答抽出 / 検索方針 / reasoning effort

② トレース読解はゲインと関連しない

③ 制約するのは「評価呼び出し回数」ではなく「ケースパス」

• 中央値の optimizer は 8 回 (4%) の呼び出ししか使わない

• 一方で ケース割当の 82% を使う

• 100 セル中 55 セルが少なくとも一方のパーティションのケース予算を使い切る

④ 可視の validation スコアは楽観的

Powered by the Cordis meta-framework, DeepSeek Harness is an agent harness built around one core idea: Everything is a plugin. Models, tools, skills, sessions, sandboxes, filesystems, loops, orchestration, and UI are ALL implemented as plugins, and can be mixed, matched, replaced, and extended.

• RAGの検索エンコーダ（クエリ・文書のベクトル化モデル）の学習

• 新しいドメインのデータをどのように取り込むか
• フルデータで再学習: 学習コストが重い
• 新データで追加学習: 過去の知識が失われる可能性（catastrophic forgetting）

• 既存: メモリベース継続学習
• hard memory: 固定のクエリ集合と正解文書のペア
• 新しいデータで学習しつつ時々hard memoryからも過去のペアをリプレイすることで忘却を防ぐ
• 課題
• hard memoryは事前に決めたクエリ集合に紐づくため、その後に登場した未知のトピックへの汎化力が乏しい。
• 正解文書ラベル（ground truth）を継続的に人手で用意する必要があり、リアルタイム運用では現実的でない。

• 提案: CREAM: Soft Memoryベースの継続学習



• Soft Memory: クエリと文書を意味的な近さで動的にクラスタリングしたもの
• セッションの流れ
1. 現在のエンコーダで検索
2. Soft Memory 更新（クラスタリング更新）
3. 擬似ラベル作成
4. エンコーダ再学習
• 類似度計算
• トークンレベル類似度: クエリの各トークン埋め込み  について、文書側の全トークン  との内積（コサイン類似度相当）の最大値を取り、 それをクエリの全トークンで足し合わせる。
• 「クエリの各語が、文書中で最もよく一致する語とどれだけ似ているか」の総和であり、 文脈に応じた細かい意味の一致を捉えられる
• 既存手法の Random Projection Locality-Sensitive Hashing で計算量削減
• H = 12 個のランダムな向きのベクトルを用意する
• 各トークン埋め込みについて、12 個それぞれのベクトルとの内積を符号を並べた12次元ベクトルを作る → 同じ結果のトークン同士が同じbucketとして扱われる
• [0, 1, 1, 0, … , 1, 0, 0]
• 向きが似ているベクトルが同じbucketに入る
• データ量によらず 2^H のbucketに固定される
• 同じbucketのベクトル同士を合計・正規化したものがprototype。prototypeとの距離から、各書類のクラスタが決まる。
• 参考: pineconeRandom Projection for Locality Sensitive Hashing
• 学習
• ソフトメモリに貯まった全クエリ・文書で毎回学習するのは非効率なので、CREAMはクラスタサイズに比例して代表クエリを選び （大きいクラスタに偏らせない）、選んだクエリごとに「トップ1類似文書=正例、下位k-1件=負例」を構成する
• 損失は対照学習

• 実験
• 実験はLoTTE（5ドメインのQ&A: Writing/Recreation/Science/Technology/Lifestyle）とMSMARCO （5ドメインのBing検索QA）を、それぞれ10セッションのストリーミング設定に再構成して評価している。
• 指標は Success@5（上位5件に正解が1件でも含まれるか）とRecall@10（上位10件中の正解網羅率）。
• 結果: 教師あり最良手法にほぼ匹敵する水準まで教師なしのまま到達

背景と課題

提案手法：オントロジーメモリ拡張型フレームワーク

評価

データセット

結果

• 性能: 10通りのバックボーンモデルと設定の組み合わせのうち9つで、提案手法は直接補正（Direct Correction）を上回った。特に Qwen2.5-14B においては、ゼロショット設定で CER (Character Error Rate) を大幅に削減した。
• この研究では、FS（Few-Shot） 設定が必ずしも精度向上に繋がらないケースがあることが示されています。
• 過剰修正の誘発: FS設定では、モデルがより積極的に編集を行うようになりますが、同時に CER（文字誤り率）を悪化させる有害な編集（Worsen@Edit）も増加する傾向があります 。
• オントロジーメモリとの相互作用: Qwen3.5-9Bなどの一部のモデルでは、ZSでは提案手法が有効だった一方で、FSでは Direct 手法を下回る結果となりました。これは、少数のデモンストレーションがメモリからのガイダンスと干渉し、推論時に不要な修正を助長してしまう可能性を示唆しています 。

• 特性: 提案手法は単なる書き換えではなく、メモリ上の証拠に基づいた選択的かつ精度の高い補正を実現していることが、Edit behavior の分析から明らかになった。

• 計算コスト: オンライン推論において、メモリ検索と更新に伴うレイテンシは発生するものの、音声入力のウィンドウ時間内に計算を隠蔽できるため、ユーザーが知覚する遅延は1秒以下に抑制されている。

要約

背景と課題

• 現行スタックは数千の特徴量と専用アーキテクチャ（シーケンスモデル、特徴交互作用、マルチタスク）で構成され、新コンテンツ種別・新サーフェスの追加コストが高い。

• 素の LLM は推薦には不十分：人気作偏重、カタログ外のハルシネーション、ビジネス制約の無視、パーソナライズ不足。

• タスクはフルカタログ（または top-K）ランキング。ユーザー u・履歴 H・コンテキスト τ（デバイス、サーフェス、ロケール、時刻）からカタログ全体の順位 π を出し、短期エンゲージメントでなく長期メンバー効用を最適化する。

2フェーズ学習

学習データとコンテキストエンジニアリング

• 数千億件の interaction ログ（視聴、再生時間、thumbs、リスト追加、離脱等）を「ユーザーと推薦システムの会話」形式に変換。user メッセージ＝言語化されたコンテキスト・履歴・タスク、assistant メッセージ＝実際のエンゲージメント。推論時は assistant をデコードせず scoring head でランク付け。

• トークン予算が新しい「特徴量予算」になる。高シグナルイベント（長時間再生、thumbs-up）は詳細に保持、低シグナル（短時間再生、hover）は削除、反復行動（binge）は圧縮、重要・cold-start アイテムは選択的に詳述。prefix caching を効かせるプロンプト構造も工夫。

学習目的（多目的損失）

1. カタログ認識ランキング目的：高価値エンゲージメントを正例とし、カタログ/候補集合上の cross-entropy でスコア学習。

2. 言語モデリング目的：言語理解の維持と、将来の説明生成などに備える。

3. 報酬重み付き損失：生ログだけで学習すると binge 偏重や単一コンテンツ種別偏重が起きる。別個の reward model から (a) 長期満足プロキシ（再訪、カタログ探索、持続的視聴）と (b) 行動リバランス（games vs movies、新作 vs 定番）のスカラー重みを算出し、例ごとに損失をスケール。フル RL より単純・低コストで有効。GRPO 等の RL 手法は追加ゲインを確認済みだがコスト面で future work。

アーキテクチャとサービング

• decoder-only Transformer backbone ＋ カタログ認識 scoring head。言語化テキスト x → pooled hidden state h → 各アイテム埋め込み eᵢ と dot product / 小 MLP でスコア sᵢ → softmax でランキング。backbone・head・埋め込みを joint 学習。大カタログには sampled softmax / 候補集合。カタログ外推薦を構造的に防ぐ。

• vLLM 上の内部 LLM スタックで提供。コスト対策は 3 つ：(1) 小型・蒸留モデル、(2) 積極的なコンテキスト圧縮、(3) prefill-only 推論（自己回帰デコードなしにプロンプト 1 回の forward で候補全体をスコアリング）。

実験結果・アブレーション

• オフライン：Phase-2 ラベル約 40 分の 1 で MRR +1.6%。データ・信号を増やすとさらに改善。

• オンライン：バッチ計算サーフェスで ~10% トラフィック・~4 週間の A/B。低データ・低シグナル構成でも短期・長期指標とも有意に改善。

• スケーリング：~1B と ~10B backbone とも Phase-2 データ増で MRR 単調改善。固定学習予算下では大きい backbone が一貫して優位。

• Phase 寄与：Phase-1（Netflix 適応）は OSS 直開始比で offline 指標 10–20% 改善。Phase-2 は Phase-1 直後評価で追加 35–50%、Phase-1 が陳腐化する 2 週間後には相対効果が約 80% に拡大。

• データ効率：強い Phase-1 から始めると、本番ランカー同等以上を 10–40 分の 1 の Phase-2 ラベルで達成。

• コンテキスト長最適化：イベントのクリーニング→MRR vs イベント数の「elbow point」特定→保持イベントの verbosity 調整、の 3 段階で、トークンを約 3 分の 1 に削減しても offline 指標はほぼ劣化なし。サービングコストも同比率で削減（コストはコンテキスト長にほぼ比例）。

図1: GenRec と本番モデルとのオンライン指標比較

示唆：LLM-native 推薦への転換

• feature engineering → context engineering：プロンプトが新しい特徴ベクトル。どの信号をどこまで遡り、どう圧縮するかが設計の中心に。

• タスク別カスタムアーキテクチャ（two-tower, DLRM 等）→ 共通 foundation backbone：差別化はデータ・言語化・post-training・推論最適化で行い、自然言語による steering への道も開く。

• スケーリング則が設計指針に：sparse ID や特化アーキで頭打ちしやすい従来型と違い、データ・モデル増で一貫して品質向上。

• RecSys インフラ → LLM インフラ：GPU、vLLM/Triton、バッチング・キャッシング中心の構成へ。

monoke の感想

• そもそも素の LLM 自体だと rerank 低いんだな
• 素の LLM → 独自context で継続学習で +10%
• 独自context → Rerank 向けSFTで +20~80%

• context の最適化が興味深い
• イベントのクリーニングと圧縮: シグナルの弱いエンゲージメントを除外し、繰り返し発生する行動を圧縮することで、整理されたイベント系列を作成する。
• エルボーポイントの探索: 含める過去イベント数を変化させながらMRRをプロットし、それ以上イベント数を増やしても効果が逓減するエルボーポイントを特定する(図5参照)。
• 冗長性の最適化: 残したイベントについて、詳細度の異なる表現や簡略化した文言を試し、それぞれMRRを測定する。
• context を 1/3 まで削減しても指標の劣化はごくわずかだった