デイリーAIダイジェスト — 2026-08-12
arXiv ハイライト
ピクセルを超えて：動画の事前分布から4次元世界へ
4D生成——テキストまたは画像を条件として、一貫したカメラ軌跡を持つ時変3D形状を生成すること——は現在、2つの流派に分かれています。Generate-then-reconstructパイプラインは、動画 diffusion の潜在表現をRGBにデコードした後、4D再構成器を適用します。専門化パイプラインは、形状を直接出力できるよう動画生成器を再学習させます。前者はデコードのコストを支払います：VAEのアーティファクトやコーデックレベルの分布シフトが形状に伝播するのです。後者は4Dモデルを特定の生成器と条件付け体制に結合させるため、バックボーンに変更を加えるたびに再学習が必要となります。本論文はその中間的なアプローチを提案します：動画 diffusion モデルの最終デノイズ済み潜在表現をインターフェースとして扱い、その潜在表現から事前学習済み4Dデコーダのトークングリッドへの直接マップを学習することで、RGBを完全にバイパスします。
問題設定
(E_v, D_v) を動画生成器の時空間VAEおよび潜在空間 \mathcal{Z}_v とし、\mathcal{Z}_{4D} を事前学習済み4D再構成器（本論文では4RCを使用）の構造化トークン空間とします。2つの空間は時間解像度、空間ストライド、および特徴次元が異なります。著者たちはアライメントマップを学習します。
\mathcal{A}_\phi: \mathcal{Z}_v \rightarrow \mathcal{Z}_{4D}, \quad \mathbf{Q}^{(0)} = \mathcal{A}_\phi(\mathbf{z}_v),
その出力は精緻化され、4Dシーンへとデコードされます。
\mathcal{Y} = \{(\mathbf{C}_t, \mathbf{P}_t)\}_{t=1}^T, \quad \mathbf{P}_t \in \mathbb{R}^{H\times W\times 3},
ここで \mathbf{C}_t はカメラ、\mathbf{P}_t は密なワールド座標系における点マップです。Generate-then-reconstructのベースラインは代わりに \widehat{\mathcal{Y}}_{\mathrm{rgb}} = R(D_v(\mathbf{z}_v)) を計算しますが、これがまさに著者たちが回避しようとしているRGBの境界です。
手法：L4AR
Latent-to-4Dは、凍結された動画VAEと凍結された事前学習済み4Dバックボーンの周囲に3つのコンポーネントを組み合わせます（図2参照）。
- アライメントモジュール。 学習された3D畳み込みが動画VAEの潜在グリッドを4D再構成器のトークンレイアウトに合わせて変形します。これにより、各アライン済みトークンが4RCの位置エンコーディングおよび時間エンコーディングと整合した時空間パッチに対応します。
- 凍結されたカメラトークンと時間トークン。 これらは4RCの階層からそのまま再利用され、ベースモデルが大規模再構成の事前学習中に獲得した幾何学的な事前分布が保持されます。
- 精緻化階層。 4RCから初期化された31ブロックのスタックが、フレームごとの attention（フレーム内空間整合性）とグローバルな時空間 attention（フレーム間整合性）を交互に適用します。この階層はrank-16 LoRAで適応化され、アライメントモジュールと予測ヘッドのみがスクラッチから学習されます。動画生成器と4RCのベース重みは完全に凍結されます。
学習は6つのデータセットから得られた約1,143本の再構成クリップのみを使用し、カメラと点マップに対する形状教師あり学習を行います。重要な点として、学習時にはモジュールに実動画のVAEエンコーディングを入力し、推論時には同じVAEを共有する任意のDiTからの最終デノイズ済み潜在表現を入力するため、単一のチェックポイントがWan2.1-T2V-14B、Wan2.1-T2V-1.3B、Wan2.2-I2V-A14Bにわたって再学習なしで転移可能です。
結果
Text4D-200およびI4D-200（それぞれ200件の固定ケース。2台のオフアクシスカメラから点シーケンスをレンダリングし、生成されたRGBリファレンスに対してCLIP/DINOの一致度を評価）において、Latent-to-4Dはすべての指標で同一潜在表現を用いたWan+4RCカスケードを上回っています（表1）。
Wan2.1-14Bを使用したtext-to-4Dでは、DINO F1が53.56（Wan+4RC）から57.01へ（+3.45）向上し、Wan2.1-1.3Bでは54.21から57.09へ（+2.88）向上しています。代替手法である \pi^3 とAny4Dはさらに低い値（Wan2.1-14Bでそれぞれ47.50と45.55）にとどまっています。Wan2.2-I2V-A14Bを使用したimage-to-4Dでは、DINO F1が55.79から61.60へ（+5.81）大幅に向上し、DINOグローバル類似度も47.83から54.85へ向上しています。特化型image-to-4Dモデルである4DNeXのDINO F1はわずか28.33にすぎません。Text CLIPも緩やかに改善しており（例：Wan2.1-14Bで28.116 → 28.544）、潜在表現を経由するパスがRGBの往復よりも条件忠実度をよく保持することが示唆されます。ユーザースタディ（表2）では、提案手法への支持率がtext-to-4Dで全体の65.7%、image-to-4Dで70.6%となっています。
7-ScenesおよびNRGBD上のコンポーネントアブレーション（表3）が各貢献を分離しています。3D畳み込みアライナーを除去すると、精度が7-Scenesで3.121 cmから6.944 cmへ、NRGBDで5.202 cmから12.439 cmへと悪化します。フレームごとの attention を除去するとcompletion誤差がそれぞれ20.806 cmと36.982 cmへと増加し、グローバル attention の除去も同様の影響を与えます。グリッドの再利用（位置/時間トークン）の寄与は最も小さいものの、それでも精度が約0.7 cm低下します。NRGBDにおけるフレーム attention なしの法線整合性は0.766から0.502へ低下しており、両方の attention スコープが重要な役割を担っていることが確認されます。
制限事項
DINOベースのオフアクシススコアは、可視的な幾何学的整合性に対する外観依存の代理指標であり、メトリックな4D精度ではありません——著者たちはこの点を認識しており、ユーザースタディと7-Scenes/NRGBDのグランドトゥルースを用いて補完的な検証を行っています。このアプローチはVAEファミリーに縛られています：Wanのバリアント間での転移は自由ですが、VAEが変わると再学習が必要です。学習セットが小さく（約1Kクリップ）、これが絶対的な形状品質の上限となっている可能性があり、再構成の教師あり学習をスケールアップすることでメトリック精度のある4D再構成との残差ギャップが埋まるかどうかは未検証です。また、この手法は最終デノイズ済み潜在表現に十分な形状関連シグナルが含まれていることを前提としており、Wanでは経験的に正しいことが示されていますが、知覚的圧縮のために最適化された潜在空間では保証されません。
重要性
本論文は、動画 diffusion の潜在表現がRGBよりも下流の3D/4Dタスクにとってより優れたインターフェースであることを主張し、実証しています。1Kクリップで学習された小さな単一のアダプターが、VAEファミリー内の任意のDiTを事前学習済み4Dバックボーンに接続できるならば、深度、トラッキング、物理シミュレーションといった形状認識型の下流ヘッドが、再学習なしに生成器の世代を超えて再利用可能となり、世界モデルの開発と生成器の開発が切り離される可能性があります。
Source: https://arxiv.org/abs/2608.10744
AdvFD: 敵対的Fréchet距離Lossによる視覚生成の強化
問題：生成器のpost-trainingにおけるFréchetハッキング
Fréchet距離（FD）lossは視覚生成器のpost-trainingにおける標準的なツールとなっています。これらは、凍結されたエンコーダ空間 \phi において、実データ p と生成データ q_\theta の間の一次・二次の特徴統計量を整合させるものであり、ペアの再構成ターゲットを必要としません。ただし、いかなる静的なエンコーダセットも、真の分布間ギャップに対する固定された不完全な視点しか定義できません。生成器は、エンコーダが見えない方向でメトリクスを下げる一方で、エンコーダが観察できない方向では品質が劣化するという事態が起こり得ます。
本論文はこの失敗を具体的に示しています。事前学習済みのpMF-B生成器を凍結し、Inception FIDに対してのみ普遍的な加法的摂動を最適化すると、FIDは3.31から2.56へと低下する一方で、明らかに可視的な高周波アーティファクトが発生します。これはInception表現における悪用可能な盲方向の直接的な存在証明です。JiT-BのリアルなPost-trainingでは、50kから75kステップの間にFD-r-Inceptionが29.4%低下する一方、FD-r-CLIPが8.5%上昇します。
単に凍結エンコーダを増やすことでカバレッジは拡大しますが、根本的な問題——エンコーダが q_\theta の進化に合わせて適応しないこと——は解決されません。
手法：敵対的Fréchet距離
AdvFDは、静的なFD目的関数を、敵対的に学習される学習可能な表現 \psi_{\omega} で補完します。\mathcal{F} を凍結エンコーダセット（本論文ではSigLIP + MAE + Inception、“SIM”を使用）とします。静的な項は
D_{\mathrm{static}}(p,q_\theta) = \sum_{\phi \in \mathcal{F}} \lambda_\phi D_{\mathrm{FD}}^\phi(p,q_\theta)
です。イテレーション t において適応的な項 D_{\mathrm{adv}}(p, q_\theta; \omega_t) が加えられ、
\mathcal{L}_t(\theta;\omega_t) = D_{\mathrm{static}}(p,q_\theta) + \lambda_{\mathrm{adv}} D_{\mathrm{adv}}(p,q_\theta;\omega_t)
となります。
Trainingは二つのステップを交互に行います：
- G-step: \mathcal{F} と \psi_{\omega_t} を凍結し、\nabla_\theta \mathcal{L}_t を降下させることで \theta を更新します。
- D-step: \theta を凍結し、D_{\mathrm{adv}} を最大化するように \omega を更新し、固定エンコーダが見逃した残差的な不一致を露出させます。
これはGAN的なゲームですが、「discriminator」は特徴抽出器であり、報酬は分類lossではなくその特徴上のFréchet距離です。abstractでは、敵対的エンコーダが特徴ノルムの増幅によって目的関数を自明に膨張させることを防ぐ較正メカニズムについて言及されています（提供された抜粋では詳細は省略）。これは本質的です——そうでなければ \omega は単純に \psi_\omega の出力をスケールさせるだけになります。
\psi_\omega は事前学習済みの視覚エンコーダから初期化されるため、adversaryはランダムな射影ではなく意味的に意味のある空間から始まり、これにより初期trainingが安定化されると考えられます。生成器はgradientを生成サンプルのみを通じて受け取り、実サンプルはFréchet統計量を通じてのみ入力されます。
結果
評価は、JiTおよびpixel MeanFlow（pMF）バックボーンのB/L/Hスケールを用いた 256\times256 のクラス条件付きImageNet-1Kで行われ、1ステップ（1-NFE）サンプリングと評価ごとに5万枚の生成サンプルを使用します。報告されるメトリクスは三つです：
- FID（Inception、training内エンコーダ）
- FD-r6: 6つのエンコーダ（Inception、ConvNeXt、DINOv2、MAE、SigLIP、CLIP）にわたる正規化FDの平均
- FD-r3: ConvNeXt、DINOv2、CLIPに限定した同様の平均——これらはSIM training lossで使用されていないエンコーダです。FD-r3はKey転移メトリクスであり、gainがtraining特徴空間の外に汎化するかどうかを測定します。
静的FD-lossベースラインに対するFD-r3 / FD-r6の相対的な低減率：
- JiT-L: 41.4% / 38.0%
- JiT-H: 34.0% / 32.1%
FD-r6よりFD-r3の方が大きく低下しているのがポイントです。これは、モデルがtrainingしていないエンコーダで改善が最も顕著であることを示しており、敵対的項がSIM特徴空間に過学習するのではなく、真の分布ギャップを埋めていることを示唆しています。定性的には、JiT-L + AdvFDは静的FDベースラインよりもよりクリーンで一貫性のある1-NFEサンプルを生成します。
限界と未解決の問題
- 提供された抜粋では \psi_\omega の較正メカニズムが省略されています。スペクトル正規化、特徴ノルム正則化、またはEMA制約のいずれであるかは、再現性と安定性に大きく影響します。
- 評価は1-NFE生成器を用いた 256^2 のImageNet-1Kのみです。AdvFDが多ステップdiffusionサンプリングや高解像度のtext-to-imageモデルを改善するかどうかは未検証です。
- 敵対的表現はtraining loopに完全なエンコーダを追加するため、計算量とメモリが増加します。追加の凍結エンコーダで \mathcal{F} を拡張した場合との実時間比較はここでは報告されていません。
- FD-r3は依然として固定エンコーダを使用しており、十分に敵対的なオプティマイザは原理的にSIM ∪ ConvNeXt ∪ DINOv2 ∪ CLIPの和集合における盲方向を悪用する可能性があります。敵対的シグナルが知覚品質を追跡しているという主張を強化するためには、人間による評価が有効です。
- 同じ生成器に対する古典的なGAN post-training（例：標準的なdiscriminator）との比較は抜粋された節に含まれておらず、どれほどのgainが敵対的な特徴統計量マッチングによるものか、または敵対的trainingによるものかを明確にするためにそれが必要です。
なぜ重要か
Fréchetベースのpost-trainingは1ステップ生成器の仕上げステップとして一般的になっていますが、凍結エンコーダへの依存はGoodhart的な明確な失敗を生み出します。すなわち、品質が改善されないままメトリクスが低下するという現象です。AdvFDは固定された特徴バンクを統計空間におけるGANのdiscriminator側として再定式化し、分布マッチングの安定性を放棄することなく適応性を回復します。保留エンコーダにおける30〜40%のFD-r3 gainは、これがFD lossを拡張する上で正しい軸であることを示唆しています。
Source: https://arxiv.org/abs/2608.11205
Mendel Gödel Machine: 比較進化による再帰的自己改善コーディングエージェント
問題設定
アーカイブベースの自己改善コーディングエージェント（Gödel Machineスタイルのシステム：HGM、DGM）は、エージェントのscaffoldの系統木を維持します。各scaffoldはソースコード（遺伝型）として保存され、評価トレース（表現型）を持ち、反復的に自己を書き換えます。主流の自己修正の基本単位は、単一の失敗軌跡を条件とした編集です：失敗したタスク \tau を選択し、そのトレースをエディタLLMに与え、新しいエージェントを生成します。このアプローチはアーカイブを有効活用できていません。単一の失敗トレースだけでは、多くの可能な原因（局所化の失敗、修正の弱さ、検証の欠如など）が混在しているため、単一軌跡による編集はノイズの多い診断となります。本論文では、アーカイブ全体にわたる比較的な証拠——同一エージェントによる複数タスク、または異なるエージェントによる同一タスク——が、より信頼性の高い自己編集をもたらすかどうかを検討します。
手法
MGMは標準的な木探索構造（選択 \pi、評価 \varphi、展開 \Phi）を維持しつつ、\Phi を診断証拠 E の種類に応じた3つのオペレータに分割します：
- Clonal mutation \Phi_{\rm CM}：基準となる単一エージェント・単一タスクの編集。証拠 E_{\rm CM}(i,\tau)=\{(\varphi(a_i,\tau), r(a_i,\tau))\} から a' \leftarrow \Phi_{\rm CM}(a_i, E_{\rm CM}) を生成します。アーカイブが比較を形成するには小さすぎる場合に使用されます。
- Reaction-norm mutation \Phi_{\rm RM}：同一エージェント・複数タスク。エディタは複数のタスクにわたるエージェントの軌跡を同時に参照し、不変的な弱点（例：異なる環境での繰り返される失敗パターン）を特定するよう求められます。これは数量遺伝学における環境横断的な遺伝型の反応規範を読み取ることに類似しています。
- Cross-lineage hybridization \Phi_{\rm CH}：同一タスク・異なるエージェント。タスク \tau に対して選択されたエージェントの失敗トレースと、異なる系統から \tau に成功（または異なる形で失敗）する参照エージェントを与え、エディタはその差分を診断シグナルとして欠けている能力をインポートします。
Cross-lineage hybridizationは系統間で共通の診断タスクを必要とします。本論文では、参照ペアを構築するために共通診断タスク（例：javascript__queen-attack）の結果によって色付けされたノードを選択します。
加法的適応度ランドスケープ分析
LLMの確率性による交絡なしに設計の妥当性を示すため、本論文は代替モデルを導入します。各エージェントは遺伝型 \mathbf{g}\in\{0,1\}^L を持ち、オラクルは \mathbf{g}^*=\mathbf{1}、距離は d(\mathbf{g})=\sum_\ell \mathbf{1}[g_\ell\ne g^*_\ell] です。タスク \tau は k 個の遺伝子座 R_\tau\subseteq[L] を検査し、R_\tau\cap M(a)=\emptyset の場合にのみ解かれ、次式を与えます：
P(r=1\mid d)=\Big(\tfrac{L-d}{L}\Big)^k.
\Phi-展開は検査された遺伝子座を反転させ、一定確率でミスマッチを修正または正しい遺伝子座を破損させます。このモデルのもとで、単一軌跡のclonal mutationは一つの R_\tau 内の遺伝子座しか参照できません。Reaction-norm mutationは \bigcup_\tau R_\tau を参照し、実際にミスマッチしている遺伝子座に関する事後確率を鋭くします。Cross-lineage hybridizationはさらに異なる M(\cdot) を持つエージェントとの比較によってこれを制約します。本論文は、2つの比較オペレータのもとで有効な修正確率が上昇し、オラクルへの期待到達時間が短縮されることを証明・シミュレーションによって示しています。
結果
実験では、Qwen3.6-35B-A3B をエディタ/エージェントのバックボーンとして使用し、SWE-bench Verified-60 および Polyglot-60 上で評価しました。HGM との比較は、200回の \varphi-評価・24回の \Phi-展開という予算のもと、同一の祖先scaffoldから開始して行われました。
- SWE-bench Verified-60：初期68.3% → HGM 73.3%（+5.0）→ MGM 78.3%（+10.0）。相対改善率はそれぞれ7.3%対14.6%。
- Polyglot-60：初期50.8% → HGM 77.9%（+27.1）→ MGM 93.2%（+42.4）。相対改善率は53.3%対83.5%。
- 2タスクの平均：59.6 → 75.6（HGM）→ 85.8（MGM）、すなわちMGMで+26.2 pp対HGMで+16.0 pp。
実行時間のコストは同程度です（Polyglot：HGMが44.20時間、MGMが40.14時間、8×H100使用；SWE-bench：93.02時間対96.11時間）。HGMとMGMのオペレータごとのトークン分布は同じオーダーであり、「より多くのトークン」が原因ではないことが排除されます。評価回数と展開回数が同一であることから、改善は比較証拠の情報量に起因するものであり、より大きな探索予算によるものではありません。本論文では、この傾向が225タスクのPolyglotベンチマーク全体においても保持されることが報告されています。
限界と今後の課題
- バックボーンは1種類（Qwen3.6-35B-A3B）のみで、200回の評価に限定されています。系統の多様性が \Phi_{\rm CH} により重要になるはずの長い時間軸での挙動は十分に特徴付けられていません。
- 加法的適応度モデルは独立な遺伝子座と R_\tau の一様サンプリングを仮定していますが、実際のコーディング能力は絡み合っており非加法的であるため、理論的な修正確率の優位性はせいぜい方向性を示す議論にとどまります。
- Cross-lineage hybridizationは共通の診断タスクと複数の系統を必要としますが、本論文ではMGMが系統のブートストラップ戦略や参照エージェントの選択にどの程度敏感であるかを定量化していません。
- SWE-bench/Polyglotと事前学習データ間のテスト汚染は認識されていますが、監査はされていません。
- 非メンデル的アーカイブ活用ベースライン（例：軌跡クラスタリングエディタ、k 件の失敗に対するcontrastive prompting）との比較はありません。
なぜ重要か
自己改善エージェントはこれまで、各自己編集を1つの失敗への反応として扱い、維持するために既に計算コストを払っているアーカイブを無視するというボトルネックを抱えていました。MGMは、アーカイブされた軌跡を制御された比較——1つのエージェントに対するタスク横断、1つのタスクに対する系統横断——として再利用することで、追加の評価やトークン消費なしに単位計算あたりの改善量をほぼ2倍にできることを示しています（Polyglot：+42.4対+27.1 pp）。これは、再帰的自己改善における次のスケーリングの軸が、より多くのロールアウトではなく証拠の構造にあることを示唆しています。
Source: https://arxiv.org/abs/2608.07645
VibeLifeBench: あなたのライフエージェントは生きた世界でプロアクティブかつ持続的に行動できるか？
問題設定
既存のエージェントベンチマーク（τ-bench、AgentBench、WebArena など）は、短い自己完結型のツール使用エピソードを評価対象としています。すなわち、ユーザーがリクエストを発行し、エージェントが応答し、その間世界は静止したままです。しかし、実際のパーソナルアシスタントのワークロードはこの三つの前提をすべて満たしません。タスクは数週間にわたって続き、プロンプトとプロンプトの間に世界は変化し（フライトが再スケジュールされ、ポリシーが変わり、フィッシングメールが届く）、多くの制約（パスポートの有効期限、インスリンの税関申告など）は一切明示されません。リアクティブなシングルターンのツール使用に最適化されたエージェントは、状態を再確認したり、適切な場面では沈黙を保ったり、数ヶ月にわたるステージを通じて計画の一貫性を維持したりするインセンティブを持ちません。
VibeLifeBench は、まさにこのギャップを埋めることを目的とし、10 の生活ドメイン（キャリア、試験準備、財務、フィットネス、訴訟、リノベーション、賃貸、ショッピング、チームビルディング、旅行）にわたる 200 件のスクリプト化されたマルチウィークタスクを、独自のクロックを持つ 22 のモックサービスからなるシミュレーテッドワールドで実行します。
手法
タスクはプロンプトではなく、クロックを持つ世界です。各ステージ内では、ユーザーメッセージ、世界の観察、通知、そして最も重要な変異（mutations）という 4 種類のイベントが発生します。変異はエージェントのターンを起こさず、通知もなく世界の状態を変化させます。自発的にサービスを再確認するエージェントのみがそれを検知できます。何もする必要がない場合に沈黙を保つことも正解として採点されます。
採点はエージェントが残した観察可能なアーティファクト（予約、下書き、メッセージ、ファイル）のみを対象とし、内部の推論トレースは一切参照しません。チェックは三つの階層で構成されます：
- per-stage：ステージ終了時のローカルな結果、
- cross-stage：ステージをまたいだ一貫性（3 日目に修正された計画は 20 日目でも有効でなければならない）、
- final：タスク終了時のエンドステート正確性。
cross-stage と final のチェックは全チェック数の 19.1% を占めますが、総重みの 26.8% を担っています。各タスクは 3 回実行され、\text{avg@3}、\text{max@3}、\text{min@3}、およびタスク内標準偏差 \sigma（各タスクの複数実行にわたるスコアの SD をタスク全体で平均したもの）が報告されます。
サービス層は幅広く使用されますが、頻度はロングテールであり、ドメインによってホライズン、イベント数、サービス数、チェック数が異なります。
結果
7 つのフロンティアモデルが、最強の推論設定でネイティブのツール呼び出しスキャフォールドを用いて実行されました。すべてのモデルが低いスコアを記録しています：
| モデル | avg@3 | max@3 | min@3 | \sigma | コンテキスト (M) | ツール呼び出し数 | ターン数 |
|---|---|---|---|---|---|---|---|
| Claude Opus 5 | 32.5 | 41.2 | 23.8 | 9.8 | 30.2 | 316 | 210 |
| GPT-5.5 | 30.1 | 38.8 | 21.5 | 10.0 | 17.6 | 332 | 146 |
| Gemini 3.5 Flash | 27.5 | 35.6 | 20.1 | 8.3 | 41.2 | 243 | 227 |
| Claude Opus 4.8 | 27.5 | 34.3 | 20.3 | 7.5 | 28.8 | 228 | 111 |
| GLM-5.2 | 25.4 | 29.9 | 20.9 | 4.8 | 22.3 | 288 | 141 |
| Kimi-K2.6 | 22.6 | 27.1 | 18.4 | 4.6 | 21.8 | 231 | 166 |
| DeepSeek-V4-Pro | 21.1 | 24.7 | 17.7 | 3.7 | 13.7 | 203 | 101 |
三つの知見が際立っています。
上限は低く、下限は非常に低い。 最良モデルでも avg@3 = 32.5 に留まり、\text{max@3} = 41.2 でさえも同様です。すべてのモデルで \text{min@3} \leq 23.8：すべてのシステムで 3 回の実行のうち少なくとも 1 回はフロアに近い値を示しています。7 モデルすべてが 21〜33 のバンドに集中しており、モデル間の差は、いずれのモデルと真の能力との距離よりも小さくなっています。
不信頼性は本質的なものである。 タスク内 SD は GPT-5.5 で 10.0、Claude Opus 5 で 9.8 に達します。より大規模でコストの高いモデルが一貫性を持つわけではなく、推論をより多く行う Anthropic および OpenAI のシステムが最も高い \sigma を示す一方、より安価なモデル（DeepSeek-V4-Pro、\sigma = 3.7）は安定した平凡さを示しています。長期ホライズンのアシスタントが最も必要とする性質である持続性と自己一貫性は、現在のモデルが最も弱い点に他なりません。
ドメイン別の能力は大きく不均一である。 Claude Opus 5 でさえ、チームビルディングでは 21.8 からショッピングでは 51.1 まで幅があります。易しい順から難しい順への序列はモデル間で安定しており、ショッピング・旅行・リノベーションは扱いやすく、チームビルディング・賃貸・試験準備が最も難しくなっています。あるドメインでの強さは、広い汎用性を意味しません。
セクション 5 の失敗モード分析はそのメカニズムを確認しています。通過率は cross-stage および final の階層で最も低く、これはまさに、無音で変異した状態を再確認し、数週間にわたって計画の一貫性を維持することを要求するチェックです。現在のモデルが最適化されている能力である流暢なシングルターンのツール使用は、長期ホライズンにわたる持続的でプロアクティブな行動には合成されません。
限界とオープンクエスチョン
この世界は 22 のモックサービスからなるスクリプト化されたシミュレーションであるため、結果は実際の本番 API の混乱ではなく、設計された無音変異の分布下でのエージェント行動を測定したものです。残されたアーティファクトに対する採点は、正しく推論したものの状態の永続化に失敗したエージェントにペナルティを与えます。その裏返しとして、観察可能なアクションを生み出さなかった適切な判断を評価することはできません。このベンチマークはまた、「モデルが再確認すべきであることを知らない」場合と「スキャフォールドが定期的な再確認をスケジュールしない」場合を切り分けることもできません。固定間隔でサービスをポーリングする専用スキャフォールドは、基盤モデルを変えることなくそのギャップの多くを埋めてしまう可能性があります。無音変異のトラジェクトリに対する RL fine-tuning や、明示的な再確認ポリシーを持つメモリ拡張プランナーが、完全正解までの 40 ポイントのギャップを埋めるかどうかは未解決の問題です。
なぜこれが重要か
VibeLifeBench は、リアクティブなツール呼び出し器と、自分が注視していない間に変化する世界において一貫した計画を維持するエージェントとの違いを操作的に定義します。7 つのフロンティアモデルにわたる avg@3 = 21〜33 のバンドと、最大 10 に達する \sigma は、現在の LLM エージェントが生の model quality にかかわらず、セッションを超える長いホライズンにおいて信頼できるパーソナルアシスタントにはまだなっていないことを具体的に示す測定値です。
Source: https://arxiv.org/abs/2608.10875
SkillZip: 再利用可能な構造の発見による自己進化エージェントのEvaluation-Free Skill圧縮
問題
自己進化エージェント（ACE、SkillRL、SkillClaw、SkillOpt、Memento-Skillsなど）は、パッチを追記することで手続き的知識を蓄積していきます。具体的には、ツール失敗後の警告、フォーマット違反後の例示、稀な成功後の新しい分岐といった形です。各編集はローカルには妥当ですが、成果物はメンテナンスされたプログラムではなく、追記専用のノートブックへと変質していきます。「ソースファイルを上書きしない」というような同一の不変条件が、導入部、複数のワークフロー分岐、そして例示の中で繰り返し記述されます。また、検証・修復・確認というシーケンスが細かな変形を伴いながらコピーされます。ロードされたskillは呼び出しのたびにコンテキストに配置されるため、これによってprefillコストが膨らみ、有効な指示が希釈されてしまいます。
著者らは、テキスト的な成長と手続き的な成長の間に系統的なギャップがあることを記録しています。つまり、genuinely新しいコンテンツがほぼ安定した後も、skillの長さは増加し続けます。この問題に対して既存のツールは適合しません。汎用のprompt圧縮器（LLMLingua方式）は単一のクエリに対してどのトークンが重要かを判断しますが、skillはそのタスククラスにおける全ての将来のクエリに対して有効であり続けなければなりません。Evaluation-guided圧縮（SkillReducer）は生成されたタスクとrolloutを用いて動作を保護しますが、これにより圧縮されたskillは圧縮時のevaluation setに結合され、rolloutコストも発生します。SkillZipは、skillそれ自体の構造——インターフェース、ワークフロー、ツール・出力コントラクト、分岐ガードなど——が、下流のevaluationなしに圧縮するための十分なシグナルを提供できるかどうかを問いかけます。
手法
核心的な観察は、skillはフラットな文章ではなく、型付きコントラクトであるという点です。
ある例示を削除できるのは、その例示が一意に表現している全ての要件がコントラクトの他の部分で表現されている場合に限られます。これが「一度述べ、多くで参照する」という原則を生み出します。各ルールはそれが適用されるスコープで記述し、繰り返されるアクションシーケンスは共有プロシージャへとファクタリングし、差異は明示的な例外として保持するというものです。
形式的には、圧縮されたskillはペア (\mathcal{K}, \mathcal{R}) であり、\mathcal{K} は再利用可能なコントラクト要素のライブラリ（共有ルール、ワークフロー断片、ツールコントラクト、出力フィールド、インターフェースエントリ）、\mathcal{R} はユニークな・例外的な・曖昧なコンテンツのためのresidualです。SkillZipは型付きminimum-description-length問題を解きます：
(\mathcal{K}^*,\mathcal{R}^*) = \arg\min_{(\mathcal{K},\mathcal{R})\in\mathcal{H}(S)} \big[L(\mathcal{K}) + L(\mathcal{R}\mid\mathcal{K})\big]
ハードなカバレッジ制約のもとで
a \preceq (\mathcal{K},\mathcal{R}), \quad \forall a \in \mathcal{A}_{\mathrm{req}}(S),
ここで \mathcal{A}_{\mathrm{req}}(S) はソースから抽出された必須コントラクトアトムの集合、\mathcal{H}(S) は候補表現を列挙し、L(\cdot) はデプロイ用tokenizerのもとで定義・参照・スコープアノテーションのオーバーヘッドを含む描画済みトークンコストです。この制約こそがprompt圧縮との違いです。ユニークな要件は、短いからといって、あるいはサンプルされたタスクがそれを行使しないからといって、削除することはできません。圧縮は要件の書き方を変えることはできますが、それが表現されるかどうかを変えることはできません。
パイプラインには2つのモードがあります。One-shot圧縮は、SKILL.MD に対する決定論的なスキャナから始まり、フロントマター、見出し、ネストしたリスト、コードブロック、テーブル、ファイル参照をパースします。name/descriptionをインターフェース候補としてコピーし、Markdownのネストを予備的なスコープツリーへと変換し、ソースブロックに安定した識別子を割り当てます。番号付きリストと時制マーカーがワークフローのヒントを提供します。このパスの後にはじめて言語モデルが構造化されたコントラクト抽出を行うため、全ての下流の圧縮決定は特定のソーススパンにトレース可能です。そのうえでMDL最適化がこの型付き表現に対して動作し、テキストに再描画します。
Zip-on-Writeは継続的なバリアントです。各受信パッチは影響を受けるコントラクトの近傍と比較され、永続化される前に統合されます。時折行われる「repacking」ランは、複数のパッチが蓄積された後にのみ可視化される再利用を処理します。曖昧なスパンは言い換えられるのではなく \mathcal{R} にそのまま保持されるため、保証の境界が明示的になります。
評価プロトコル
実験セクションでは5つの研究課題を定義しています。RQ1は自己進化中のskillの成長を定量化し、RQ2は圧縮と忠実度のトレードオフを研究し、RQ3は圧縮コストを測定し、RQ4はbaselineに対して圧縮されたskillの汎化を検証し、RQ5は継続的なZip-on-Writeを評価します。モデルはQwen3.7-Max、Qwen3.6-Plus、Kimi K2.6であり、同一ファミリー内での2つの能力ティアとクロスファミリーでの確認を網羅しています。ベンチマークは3つの手続き的レジームにわたります：BFCL-v4 Web Search（標準化されたツールを用いたマルチステップ検索）、LiveMathematicianBench（量化子・同値推論を含む定理に基づくMCQ）、SpreadsheetBench（ワークブック操作）。各モデル–ベンチマークペアでは、全てのskill条件がモデルのスナップショット、スキャフォールド、システムプロンプト、ツール定義、インタラクションバジェット、デコーディング設定を共有します。
提供された抜粋には数値結果のテーブルは含まれていません。成長傾向の図は、SkillOptとMemento-Skillsにおける定性的なRQ1の主張を示しています。手続き的な新規性が飽和した後もskillの長さが増加し続けるという事実が、統合を獲得とは別個の問題として動機付けています。
限界とオープンクエスチョン
保証は構造的なものであり、動作的なものではありません。SkillZipは抽出された全てのコントラクトアトムを保持しますが、アトムの抽出自体は決定論的スキャニングの後にLLMが行うため、抽出エラーはサイレントに伝播します。曖昧なスパンはそのまま保持されるため、最悪ケースのダメージは制限されますが、達成可能な圧縮もキャップされます。MDL目的関数は固定tokenizerのもとでの描画済みトークンコストによって候補表現をランク付けします。異なるtokenizerを持つバックボーン間での移植可能性は主張されていますが、提供されたテキストでは示されていません。また、例示の中にのみ暗黙的に含まれる要件——たとえば3回示されているが一度も明記されていないフォーマット制約——を本手法がどのように扱うかも不明です。カバレッジ制約は抽出されたアトムに対して動作するためです。最後に、Zip-on-Writeのrepackingスケジュールは定性的にしか記述されておらず、どのくらいの頻度でrepacking を発火させるべきか、また敵対的なパッチシーケンスのもとで退行しないかどうかは未解決のままです。
なぜ重要か
自己進化エージェントフレームワークは現在、手続き的コンテンツが飽和している一方でトークン数が単調に増加するskillを日常的に生成しており、evaluation-guided圧縮はこれらのフレームワークが削減しようとしていたrolloutコストとevaluation setへの結合を再導入してしまいます。skill圧縮をハードなカバレッジを伴う型付きMDLとして定式化することで、skillは文章ではなくコントラクトであるという事実を尊重した、クリーンでevaluation-freeな目標が得られます。
Source: https://arxiv.org/abs/2608.11079
Not Worth Another Token: 効率的なDeep Research Agentのための限界価値推定
反復的な「分解→検索→集約→統合」ループに基づいて構築されたdeep research agentは、コンテキストを積極的に蓄積します。各サブクエリは検索を生成し、検索はさらなるサブクエリを生成し、蓄積されたコンテキスト C_t はツリーの深さに対して超線形に増大します。しかし、k 番目に検索されたパッセージの限界効用は急速に減衰します。その大部分は冗長であったり、本題から外れていたり、または最終的なレポートを改善することなく統合コストを膨らませるノイズとなる矛盾した情報です。本論文は、狭いながらも実践的な問いを立てます。固定されたパイプライン（GPT-Researcherスタイルのツリー探索）において、コンテキストのフィルタリングにどの段階で計算資源を投入すべきか、そしてスコアリングルールの選択は段階の選択よりも重要なのかどうかという問いです。
問題の定式化
パイプラインはクエリ Q をサブクエリ \mathcal{S} に分解し、反復的に s_t \in \mathcal{S} を選択して C_{s_t} を検索し、蓄積コンテキスト C_{t+1} = C_t \cup C_{s_t} へと統合します。目的関数はラグランジアン形式で表されます。
\max_{C_T} \mathcal{R}(C_T, Q) - \eta\,\operatorname{Cost}(C_T),
ここで \operatorname{Cost} はトークン数、検索呼び出し回数、およびレイテンシを合算します。部分集合の結合最適化は扱いにくいため、枝刈りは三つの局所的な決定に分解されます。Pre-Retrieval（検索前に価値の低いサブクエリを除去）、Post-Retrieval（C_t に取り込まれてさらなる分岐を生む前に価値の低いアイテムを除去）、そしてPre-Synthesis（レポート生成前に C_T を圧縮）です。
非効率性を具体的に示す測定結果として、枝刈りなしのパイプラインは29.0ノードを探索し、1レポートあたり375.4kトークンを消費し、3422.6秒を要します。パイプラインに組み込まれたpre-synthesis trimming処理はすでにコンテキストを66.10アイテムから44.08アイテムへ削減（アイテム数33.3%減、トークン数34.06%減）しています。しかしこれはトークンコストを支配する検索と処理のコストがすでに支払われた後に発生します。
枝刈り戦略
すべてのスコアリングルールは e(\cdot) \in \mathbb{R}^d のembeddingおよびコサイン類似度を使用し、q = e(Q) とします。スカラーの関連度重みは w(x) = \max(\mathrm{sim}(e(x), q), 0) です。本論文では以下を比較します。
- MMR: V_{\mathrm{MMR}}(x \mid C, Q) = \lambda\,\mathrm{sim}(e(x), q) - (1-\lambda)\max_{c \in C}\mathrm{sim}(e(x), e(c))、クエリへの関連度と保持済みコンテキストに対する冗長性のバランスを取ります。
- Graph-Relevance Novelty (GRN)、Coverage Diversification (CD)、Semantic Coverage (SC)、および w(x) で重み付けされた \ell_2 正規化embedding Gramマトリクスを用いた DPP カーネル。
- 上記の Combined および Hybrid 集約。
- 限界価値を自然言語で判断する LLM スコアラー。
- 限界貢献度を予測するよう学習された value model。
これらは各段階および段階の組み合わせ（Post-Retrievalのみ、Pre-Synthesisのみ、Post+Pre、および全三段階）で評価されます。Pre-Retrievalのみの評価は除外されています。その判断が検索されたコンテキストに条件付けされずに行われるため、誤り感度が最も高くなるからです。
結果
評価はDeepResearchGymの1,000件のResearchy Questionsからサンプリングした100クエリに対して行われ、総合品質についてはルーブリックベースのLLMジャッジ、キーポイントの再現率・カバレッジにはKPR+KPC、そして引用忠実性も評価指標として用いられます。
一段階の比較表は、品質最適設定と効率最適設定を明確に分離します。Pre-Synthesis Hybridは60.68（ベースライン57.83、+2.85）で品質を最大化しますが、トークン数は332.3kにしか削減されず、ランタイムは3834.1秒に留まります。後段の枝刈りでは上流の検索コストを回収できません。Post-Retrieval MMRが効率面での勝者です。トークン数114.6k（−69.5%）、探索ノード数8.84（29.0から削減）、ランタイム1379.8秒（−59.7%）を達成しつつ、総合品質56.62、すなわちベースラインの97.9%を維持します。abstractで言及される「最大73%のトークン削減」はより積極的な多段階設定から得られたものです。
二つの構造的な知見が特筆に値します。第一に、段階はルールよりも支配的です。Post-Retrieval内では、MMR（114.6kトークン、品質56.62）とCombined heuristic（117.8k、56.03）はほとんど区別できない一方、同じルールをPre-Synthesisに適用すると根本的に異なるコストプロファイルが生じます（探索が影響を受けないためノード数は29.0に固定）。第二に、KPR+KPC（キーポイント再現率・カバレッジ）は総合品質よりも枝刈りに対して敏感です。Post-Retrieval MMRはKPR+KPCを63.49（ベースライン70.23）に維持しますが、GRN、CD、SC、DPPは総合品質スコアが同程度であるにもかかわらず41〜48の範囲に落ち込みます。これは、ルーブリックベースのジャッジが不足している根拠を部分的に補完しており、キーポイントカバレッジが枝刈りの実際のコストを測る、より厳格な代替指標であることを示唆します。引用忠実性は、ほぼすべての設定で90〜95という顕著な安定性を維持します。
LLMベースのスコアラーは注目すべきことに競争力がありません。Post-Retrievalにおいて211.8kトークンと2310.7秒を消費しながら品質59.65を達成するに過ぎず、スコアリングのオーバーヘッドが節約効果のほとんどを食い潰しています。
限界
評価では利用可能な1,000クエリのうち100クエリのみを使用しているため、約1〜2ポイント以内の品質差はノイズとして扱うべきです。パイプラインは単一のツリー構造システム（GPT-Researcher）であり、「段階 > ルール」という結論が異なる分岐係数を持つエージェントループや非ツリーアーキテクチャ（例：グラフベースの集約、プランナー・クリティックシステム）に移転するかどうかは未検証です。学習済みvalue modelの学習手順は提示された抜粋では詳細が不足しており、品質・効率・忠実性のすべてにおいて単一の手法が支配するわけではないため、オペレーターはフロンティア上で明示的に \eta を選択する必要があります。最後に、積極的な設定でのキーポイント再現率の約7ポイントの低下は、網羅性が重要な領域（系統的レビュー、法的調査）では無視できません。
なぜ重要か
長期的な検索エージェントを本番環境にデプロイする人々にとって、本論文は最もレバレッジの高い最適化は優れた関連度スコアラーではなく、枝刈りの判断を早い段階に移すことであると主張します。Post-RetrievalにおけるシンプルなMMRフィルターは約70%のトークン削減を約2%の品質コストで実現するのに対し、後段に適用された高度なLLMベースの価値推定は厳密に劣後します。段階を意識した分解、およびスコアリングルールが二次的であるという知見は、エージェントシステムにおけるコンテキスト管理の有用な設計指針となります。
Source: https://arxiv.org/abs/2608.08389
多言語機械翻訳のためのオープン大規模言語モデルの参照なしポスト学習
問題設定
多言語MTのためのオープンLLMのポスト学習は、一般的に参照訳を含む対訳データ、または参照訳に対して学習された reward model に依存しています。本論文は、QEモデルと言語識別ゲートを組み合わせた純粋に参照なしの reward が、オープンな強力なベースライン（Seed-X、HY-MT2、TranslateGemma）および独自システム（Google Translate、Gemini 3 Pro、GPT-5）を46言語にわたって超えることができるかどうかを問います。参照収集がMTをロングテール言語ペアにスケールアップする際の制約となっているため、この設定は重要です。
手法
1B、4B、12Bスケールの SFT ベースライン MiLMMT-46-v0.1 を出発点として、著者らは参照なしの reward を用いてGRPOを適用します。各ソース x に対して、G 個の候補 \{y_1,\dots,y_G\} が \pi_{\theta_{\text{old}}} からサンプリングされ、reward R_i は2つのQEモデルの平均値として取得され、言語識別チェックによるゲート処理が行われます（すなわち、誤った目標言語での出力にはペナルティが課されます）。Advantage \hat A_{i,t} は \{R_i\} からグループ正規化されます。学習目的は標準的なGRPOの形式です：
\mathcal{J}(\theta) = \mathbb{E}_{x,\{y_i\}}\!\left[\tfrac{1}{G}\sum_{i=1}^{G}\tfrac{1}{|y_i|}\sum_{t=1}^{|y_i|}\!\Big\{\min[r_{i,t}\hat A_{i,t}, \operatorname{clip}(r_{i,t},1{-}\epsilon,1{+}\epsilon)\hat A_{i,t}] - \beta\,\mathbb{D}_{\text{KL}}(\pi_\theta\|\pi_{\text{ref}})\Big\}\right]
ここで、トークンレベルの重要度比は r_{i,t}(\theta) = \pi_\theta(y_{i,t}|x,y_{i,<t}) / \pi_{\theta_{\text{old}}}(y_{i,t}|x,y_{i,<t}) であり、\pi_{\text{ref}} は SFT モデルに固定されています。
第2の要素は線形チェックポイント補間です。純粋なRLモデルをそのまま使用するのではなく、著者らは \alpha\cdot\theta_{\text{SFT}} + (1-\alpha)\cdot\theta_{\text{RL}} として MiLMMT-46-v1.0 を構成します。これはよく知られた SFT–RL のトレードオフによって動機付けられています：RLは学習された品質指標を改善しますが、語彙的指標が好む表層形式からは乖離します。
reward カーブはスケール全体で安定した改善を示しており、12Bの実験が予想通り最も高い検証 reward に到達しています。\alpha を変化させることで得られる spBLEU と参照ありXCOMETのパレートフロントは、補間の動機付けを具体的に示しています：
純粋なRLは高いXCOMETだが spBLEU が低下した位置にあり、小さな \alpha>0 により品質向上の多くを維持しつつ語彙的重複の大部分を回復できます。
結果
1B/4B/12Bスケールで平均した46言語全体において、v1.0 は v0.1 に対して以下の改善を示しています：
- WMT24++（参照なし）：XCOMET +2.75、COMETKiwi +2.44。
- FLORES+（en→xx、xx→en、zh→xx、xx→zhの平均）：参照ありXCOMET +1.17、参照なしXCOMET +1.41、COMETKiwi +1.17、ただし spBLEU −1.21。
spBLEU の低下はQEのみの reward では予想されるものです——モデルは単一の参照訳から言い換えを行う自由があります。参照ありおよび参照なしの両バリアントにおける一貫したXCOMETおよびCOMETKiwiの向上は、この変化が単一のQEモデルへの reward hacking ではなく真の品質改善であることを示唆しています（LIDゲートとQEアンサンブルがここで有効に機能していると考えられます）。
外部システムとの比較において、v1.0 は評価された独自システム（Google Translate、Gemini 3 Pro、GPT-5を含む）において参照なしスコアでトップを取り、比較ブロックごとに使用された共有言語サブセットにおいてSeed-X、HY-MT2、TranslateGemmaを上回っています。
オンポリシー蒸留
著者らは、12B v1.0 の教師モデルが、スケールごとに個別のRL実行を避けつつ、オンポリシー蒸留によって1B/4Bの生徒モデルに改善を転移できるかどうかを検討します。PG-OPDを使用して、トークンごとの reward は単一サンプルの逆KL推定量です：
r_t = -\operatorname{sg}\!\big(\log\pi_\theta(y_t|s_t) - \log\pi_\phi(y_t|s_t)\big),
同一のGRPOの仕組みで最適化されます。著者らは、v0.1 からのOPD単独、v1.0 からのOPD、および結合目的 \mathcal{L}=\mathcal{L}_{\text{policy}}+\lambda\mathcal{L}_{\text{distill}} による RL+OPD を比較しています。
結果（WMT24++ 参照なしXCOMET / FLORES+ spBLEU / 参照ありXCOMET、46言語平均）：
- 1B：v1.0 = 79.01、30.51/85.94；OPD(v0.1) = 77.67、30.47/85.22；RL+OPD(v0.1) = 78.25、30.49/85.67；OPD(v1.0) = 77.86、30.39/85.42。
- 4B：v1.0 = 85.86、33.96/90.91；OPD(v0.1) = 85.42、34.17/90.82；RL+OPD(v0.1) = 85.85、33.98/90.98；OPD(v1.0) = 85.37、34.16/90.79。
4Bでは RL+OPD は v1.0 と誤差の範囲内で一致していますが、1Bでは直接的なRL＋補間がどのOPDバリアントよりも明らかに優れています。OPDはRL＋チェックポイント補間が設定したフロンティアに到達しますが、それを超えることはありません。
限界と未解決の問題
- reward は2つのQEモデルとLIDゲートによって定義されており、アンサンブルが単一指標への hacking を軽減するものの、評価自体もXCOMET/COMETKiwiに大きく依存しています。spBLEU の低下と学習済み指標への依存は、特にQEモデル自体が弱い低リソース言語ペアにおいて、人間の評価者が同意するかどうかという問題を未解決のまま残しています。
- KLアンカー \beta と補間重み \alpha は、どちらもSFTに近い状態を保つという同じ方向を向いた2つのパラメータです。本論文はこれらを切り分けていないようです：補間は単に大きな \beta の安価な代替物に過ぎないのでしょうか？
- 1BでOPDがRL＋補間を下回る理由は完全には説明されていません。はるかに大きな教師モデルからの逆KLは、生徒が教師の分布を表現できない場合に不良な学習シグナルとなる可能性があります。
- 言語カバレッジは46言語で止まっており、QEモデルが劣化する真の低リソース言語ペアでの挙動は引用された内容では特徴付けられていません。
重要性
QEアンサンブル reward と SFT–RL チェックポイント補間を用いた参照なしポスト学習は、RL時に対訳参照を必要とせずに、学習済み品質指標において46言語にわたってフロンティアの独自MTとのギャップを埋め、さらに超えるシンプルなレシピです。QE指標の向上が人間評価においても維持されるならば、これはオープンMTをロングテールにスケールアップするための実用的な道筋となります。
Source: https://arxiv.org/abs/2608.10812
Hacker News Signals
プロプライエタリLLM APIからの推論トレース盗取
主要な主張： o1/o3などのAPIから漏洩するchain-of-thought推論トレースは、プロバイダが最終レスポンスでそれらを抑制していても抽出可能である。この攻撃はタイミングサイドチャネルとトークン確率の差分を利用する。モデルを特定の推論ブランチに誘導するようプロンプトを巧妙に構築し、多数のクエリにわたってレイテンシ分布を計測することで、攻撃者は内部スクラッチパッドを部分的に再構築できる。第二の攻撃ベクトルはlogprobプロービングであり、候補となる推論スニペットに対する継続確率をクエリすることで、抑制されたトレース内にそれらが存在するか否かを確認する。どちらの攻撃も、標準的なcompletionsエンドポイント以上の特別なAPIアクセスを必要としない。
脅威モデルは現実的である。OpenAIのようなプロバイダは「hidden reasoning」を一つの機能として販売しており（ユーザーはコンピュートに対して料金を支払うが、CoTを検査することはできない）、これらのトレースには中間的な結論、ツール呼び出しの計画、そして場合によってはユーザーデータの逐語的な反映が含まれる。部分的なトレースの再構築であっても、競合他社がdistillationに利用できるモデル内部情報を漏洩させることになる。
議論されている緩和策としては、レイテンシへのキャリブレーションされたノイズの付加、トークン生成を固定時間バケットに離散化すること、logprobアクセスの制限などが挙げられるが、いずれもスループットまたはユーティリティのコストを伴う。当該サイトにはライブエンドポイントに対する再現可能なPoC（概念実証）コードが掲載されている。HNのスレッドでは、プロバイダがトレースの機密性を正式に保証したことはないという観点から、これが「脆弱性」に該当するか否かが議論されているが、法的な解釈にかかわらず、実際のdistillationリスクは現実のものである。
Source: https://stolen-thoughts.com/
H3-metal – Apple Silicon向けネイティブMiniMax-H3推論
Antirez（Salvatore Sanfilippo、Redisの作者）は、Metalを介してApple SiliconをターゲットとしたMiniMax-H3推論のpure-C実装を公開しました。H3はハイブリッドSSMアーキテクチャであり、乗算的attention layerとS4から派生したH3 state-space layerを交互に組み合わせ、シーケンスの大部分においてO(n^2)のattentionカーネルをO(n)の再帰的状態遷移で置き換えます。
この実装はllama.cppおよびMetal Performance Shadersのラッパーを完全に回避し、MSL computeカーネルを手書きしています。主な設計方針として、再帰的SSM状態はdecodeステップ間で単一の永続バッファに保持され、それらのlayerのKV-cacheを完全に排除しています。またattention layerでは、M系統のunified memoryバンド幅に最適化されたtiled matmulカーネルを使用しています。コードベースは意図的に最小限に抑えられており、CとMSLを合わせて3,000行未満であるため、コンシューマー向けハードウェア上でのSSM推論を学ぶ上で読みやすいリファレンスとなっています。
READMEに記載されたパフォーマンス数値では、同等のパラメータ数を持つtransformerモデルにおいてllama.cppと競争力のあるtokens/secを示しています。これは、状態が構築された後のSSM decodeが理論的にはトークンあたりのコストが低いことを踏まえると注目に値します。ただし欠点としてprefillがあります。SSM layerのchunked convolutionはGPU上でのattentionよりも並列化が難しいため、長いプロンプトでは最初のトークンが出力されるまでの時間が遅くなります。
このプロジェクトはまた、MiniMax-H3のweightが標準的なpost-training quantizationでSSMモデルを悩ませる数値不安定性の問題なしに4-bit量子化できることも実証しています。antirezは状態遷移行列の量子化前にper-channelスケーリングを適用しています。
Source: https://github.com/antirez/h3.c
Apple SiliconとmacOS VM：llama.cppによる高速LLM推論
このブログ記事は、cuaプロジェクトによるもので、Apple Siliconホスト上で動作するmacOS VMへのGPUパススルーについて解説しています。根本的な問題として、Mシリーズチップ上の仮想化では、歴史的にゲストVMがGPUにアクセスできなかったため、VM内のllama.cppはCPUのみのパスを使用せざるを得ず、Metalによる5〜10倍のスループット優位性を失っていました。
解決策として、Appleのcom.apple.hypervisorフレームワークとVZVirtualMachineConfiguration、そして最近安定化したVZMacGraphicsDisplayConfigurationおよびVZMacOSBootLoaderを組み合わせることで、仮想化されたmacOSゲストにGPUを公開します。主要な知見は、適切なentitlementとmacOS 14以降のゲストを用いることで、VM内のllama.cppがMetalを呼び出せるようになり、ベアメタルの約85%以内のスループットを達成できるというものです。具体的には、M3 Proにおいてネイティブの〜42 tok/sに対し、7B Q4モデルで〜35 tok/sが計測されています。
実用的なユースケースは、サンドボックス化されたエージェントの実行です。つまり、ホストのファイルシステムを破壊できないよう、LLMを利用したコーディングエージェントを使い捨てのVM内で動かしつつ、推論レイテンシの大きなペナルティを払わずに済みます。この記事では、必要なentitlement plist、VirtualizationフレームワークのAPI呼び出し、およびllama.cppのビルドフラグ（LLAMA_METAL=1、Apple Siliconではホストとゲストのアーキテクチャが同一であるためクロスコンパイルは不要）について詳述しています。
認識されている制限事項として、Linuxゲストはこの方法でGPUにアクセスできません。この手法はmacOSゲスト専用です。また、MetalコンテキストがライブのままVMステートをスナップショット・リストアすることはサポートされておらず、クラッシュを引き起こします。
Source: https://github.com/trycua/cua/blob/main/blog/gpu-passthrough-macos-vms.md
コーディングエージェントに最適なプログラミング言語とは？
Dan Luuの記事は、「エージェント親和性」に対して具体的かつ測定可能な代理指標、すなわちtoken効率を適用しています。中心的な主張は、コーディングエージェントがLLMのコンテキストウィンドウを通じてコードを消費・生成する以上、同等のプログラムをより少ないtokenで表現できる言語の方が運用コストが低く、より多くのコンテキストを収められるという点です。彼はGPT-4oのtokenizer（BPEベースで言語非依存）を用いて、代表的なアルゴリズムタスクについて各言語のtoken数を計算しています。
結果は一部で直感に反するものです。Pythonの冗長なキーワード構文（def、return、self）や有意な空白は、多くのパターンでLisp系言語よりもtokenizeの効率が悪くなります。Rustはlifetime annotationやtrait boundのせいでtokenizeの効率が低くなります。ゴルフ言語を除けば、簡潔かつ読みやすい構文を持つ言語——APLの派生言語や特定のLisp方言——が高スコアを示しますが、それらの言語におけるLLMの流暢さは低い水準にとどまっています。
Luuの副次的な論点は、token数がエラー面積と相関しているというものです。tokenが多いほど、モデルが誤ったtokenを幻覚する位置が増え、自己回帰的な生成においてエラーが累積します。彼は1tokenあたりのエラー率を一定と仮定した大まかなモデルを示しており、全体のエラー確率はn tokenに対して 1 - (1-\epsilon)^n となるため、n を最小化することが直接的に失敗確率の最小化につながると論じています。
この記事は意図的に、LLMがPython中心のコーパスで学習されており、token効率が悪いにもかかわらずPythonでより高い精度を発揮する可能性があるという交絡因子を回避しています。HNのスレッドでは、このトレードオフと、コンパクトなDSLに対するfine-tuningによって両方の利点を両立できるかどうかが活発に議論されています。
Source: http://danluu.com/pl-tokens/
Mistralの「コードとして実装されたtool calls」に関する特許
USPTOはMistral AIに対し、モデルのテキスト出力内でtool/function callsを構造化されたコード文字列としてエンコードする技術をカバーする米国特許US12670045を付与しました。これは具体的には、特殊な区切り文字でタグ付けされたJSONブロブではなく、プログラミング言語における関数呼び出しに構文的に類似した形式でモデルに出力させ、それをインタプリタ経由で実行するというものです。
クレームは広範なものとなっています。独立クレーム1は、LLMがコード形式で外部関数の呼び出しを含む出力を生成し、ランタイムがそれを解析・実行し、結果がフィードバックされる任意のシステムをカバーしています。これは多数のオープンソースフレームワーク（LangChainのtool use、OpenAIのfunction calling、Anthropicのtool use）で使用されているメカニズムと本質的に同一であり、ReActスタイルのpromptingやToolformer（2023年、Mistralの出願日以前）によって先行されているとも言えます。
HNでの議論が白熱しているのは当然の理由があります。先行技術としての主張は強力なものに見えます。ToolformerのarXivプレプリント（2023年2月）はまさにこのメカニズムを実証しています。新規性を判断するうえで出願日が重要であり、複数のコメント投稿者がMistralの優先日を確認するために調べています。より広い懸念としては、LLMのインタラクションパターンに関する広範なソフトウェア特許は、その技術が先行技術を踏まえれば自明であったとしても、オープンソースのエージェントフレームワークにライセンスリスクをもたらすという点です。
純粋に技術的な観点からは、コード形式のtool callsはJSONスキーマに対して実際の優位性を持っています。モデルのtraining distributionには、JSON APIの仕様よりもはるかに多くのコードが含まれているため、正式なコード呼び出しに対するトークン確率が高くなり、不正形式の出力率が低下します。
Source: https://patentsgazette.uspto.gov/week26/OG/html/1547-5/US12670045-20260630.html
llama.cpp
llama.appドメインは現在、llama.cppのための洗練されたWebフロントエンドとして機能しており、CLIを使わないユーザーにもプロジェクトを届けています。HNのスレッドは主に、ランディングページよりもプロジェクトの現在の技術的な状態について議論されています。議論された注目すべき最近の開発としては、過去1年間の混乱を経たGGUFフォーマットの安定化、小さなdraftモデルを用いたspeculative decodingの追加によるCPUバックエンドでの平均レイテンシの30〜40%削減、そして新しいllama-serverバイナリが挙げられます。このllama-serverはOpenAI互換のHTTP APIをstreaming付きで公開しており、OpenAI SDKをターゲットとする任意のクライアントに対するドロップイン型のローカルバックエンドとして機能します。
quantization面では、Q4_K_MおよびQ6_KフォーマットがいまやつはK-quantsは感度分析に基づいてweightのクラス（attention対FFN）ごとに異なるビット幅を適用しており、単純な4-bit quantizationによって失われる品質のほとんどを回復しています。IQ（importance-weighted）quantsはさらに一歩進み、層ごとのFisher情報量の推定値を用いて非均一にビットを割り当てることで、一部のモデルでは3.5 bits/weightにおいてfp16に近いperplexityを達成しています。
バックエンドのサポートはCUDA、Metal、Vulkan、SYCL、およびCPU（AVX-512およびARM NEONパス付き）にまで拡張されています。VulkanバックエンドはLinux上のAMD GPUユーザーにとって重要です。これらのユーザーはこれまでROCmを使用せざるを得ませんでしたが、ROCmはサーバー向けSKU以外ではドライバーサポートが歴史的に貧弱でした。
Source: https://llama.app
Show HN: Ante、オフラインで動作するシングルバイナリのコーディングエージェント
Anteは、ランタイム依存関係を一切持たない単一の静的リンクバイナリとして配布される、自己完結型のコーディングエージェントです。そのアーキテクチャは、小規模なLLM（READMEによればQwen2.5-Coder 1.5Bおよび7BのGGUFバリアント）を静的ライブラリとしてコンパイルされたllama.cppを用いてバイナリに直接埋め込み、ファイルの読み書き、シェル実行、diff適用ループを処理するツール実行ハーネスと組み合わせた構成になっています。
エージェントループは標準的なReActスタイルのobserve-reason-actサイクルです。モデルはタスクの説明と、リポジトリ上の軽量BM25検索ステップによって選択された関連ファイルスニペットを含むcontext windowを受け取り、ツール呼び出しまたは最終回答を出力します。ハーネスはツールを実行して結果を追記し、モデルがstop tokenを出力するかステップ数の上限に達するまでサイクルが繰り返されます。これらすべてが完全オフラインで動作し、APIコールもテレメトリも発生しません。
シングルバイナリ配布は、重みを量子化してデータセクションとしてパックするビルドプロセスによって実現されています。1.5Bバリアントのバイナリサイズは約1.1 GBです。オフライン制約がこの設計における核心的な不変条件であり、エアギャップ環境、ローカルCI、または外部APIへのコード送信を望まないユーザーにとって有用です。
制約はモデルのスケールに起因する明白なものです。1.5Bパラメータでは、長距離の推論を必要とするマルチファイルのリファクタリングタスクを安定して処理することはできません。7Bバリアントはこれを改善しますが、バイナリサイズは4.5 GBになります。HNスレッドでは、重みをバイナリに埋め込む方式が別途モデルパスを設ける方式より優れているかどうかが議論されており、反論としては再現性と単一アーティファクトでのデプロイが挙げられています。
Source: https://github.com/AntigmaLabs/ante
Show HN: Git-knife – コミットメッセージ、作者、日付をスプレッドシートのように編集する
Git-knifeは、リポジトリのコミットログをハッシュ、author名、author email、committer date、メッセージといったカラムを持つ編集可能なスプレッドシートとしてレンダリングするターミナルUIです。インプレース編集に対応しています。内部的には、変更内容に応じて各編集がgit filter-branchまたはgit filter-repoによる書き換えをトリガーし、影響を受けたコミットが再ハッシュされます。UIはTUIフレームワーク（リポジトリ構造からRustのTUIクレートと思われます）で構築されており、目的の状態とHEADとの差分を取ってバッチ書き換えを行い、冗長なパスを回避しています。
技術的な課題として、gitのコミットはコンテンツアドレス型であるため、コミットの任意フィールドを変更するとSHA-1が変わり、その影響がすべての子孫コミットに連鎖します。Git-knifeはこれを、変更セットをトポロジカルソートして最も古いものから新しいものへ単一パスで書き換え、その後refを強制更新することで対処しています。これはgit rebase -iが行うことと本質的に同等ですが、テキストエディタではなくテーブルとして公開されています。
実用的な用途としては、会社のメールアドレス変更後のauthor emailの一括修正、内部リポジトリをオープンソース化する前のタイムスタンプの均一化、あるいは各コミットに対してインタラクティブなrebaseを呼び出すことなく多数の不正なコミットメッセージを修正するといったケースが挙げられます。このツールはgit filter-repoが提供する機能を超える新たな能力を追加するものではありませんが、UXによってバッチ編集のエラー率を大幅に低減できます。スプレッドシートのセルを編集する方が、git filter-repo --commit-callback向けにPythonのコールバックを書くよりもエラーが生じにくいためです。
スレッドからのセキュリティに関する注記：書き換えを行うと既存のコミット署名が無効になります。これはgit verify-commitを使用しているプロジェクトにとって重要な点です。
注目の新規リポジトリ
ShawnPana/phone-harness
物理デバイスまたはエミュレートされたAndroid/iOSデバイスをソフトウェアエージェントがプログラム的に制御するためのハーネス層です。コアとなる抽象化では、ADB（Android）およびおそらくxcrun/simctl（iOS）を介して、tap、swipe、type、screenshot、back、homeという統一されたaction spaceを公開しており、LLMベースのエージェントがアプリ固有のカスタムAPIを必要とせず実際のモバイルUIを操作できます。設計パターンはOpenAIのoperatorやAnthropicのcomputer-useインターフェースに類似していますが、モバイルに特化したスコープとなっています。実際の動作としては、エージェントがscreenshotによる観測を受け取り、構造化されたactionを出力し、ハーネスがそれを実行して次のフレームを返すという形で、クローズドループなモバイルタスク自動化が実現されます。モバイルGUIエージェントの構築、自動化されたQAパイプライン、あるいは実世界のスマートフォンタスクにおけるマルチモーダルモデルのベンチマーキングに有用です。薄いハーネス設計により、任意のエージェントバックボーンを組み込むことが可能です。主な制限事項として、実デバイス制御はOSバージョンやOEMのUIスキンによって本質的に不安定になりやすく、実験の再現性にはエミュレータのスナップショットを固定することが必要です。
Source: https://github.com/ShawnPana/phone-harness
Kylin010/tcpfit
一般的なレシピを適用するのではなく、各マシンで経験的にパラメータを導出するTCPチューニングツールです。中心的な洞察は、最適なTCPバッファサイズはパスの実際の帯域幅遅延積に一致すべきという点にあります：BDP = bandwidth \times RTT。このツールはホスト上で直接これを計測し、その後レートリミッターの変曲点——バッファをさらに増やしても利得が得られなくなるスループットの膝点——を探索して、tcp_rmem/tcp_wmem および関連するカーネルパラメータを設定します。これにより、バッファ不足（スループット制限）とバッファ過剰（bufferbloat）の両方を回避できます。マシンごとの計測アプローチは、NICの速度、カーネルバージョン、ネットワークトポロジがノード間で異なる異種データセンターやクラウド環境において価値があります。このツールは、静的なチューニングガイド（均質なハードウェアを前提とする）と、協調するリモートエンドポイントを必要とするnetperfやiperf（本格的なツール）との間のギャップを埋めるものです。制限事項：変曲点の検出はローカルループバックまたは到達可能なピアに依存するため、WANパスに対する方法論の明確化が必要です。
Source: https://github.com/Kylin010/tcpfit
starling-build/starling
Swiftで書かれた新しいLinuxデスクトップ環境で、カスタムWaylandコンポジター、Swiftネイティブのシェル、およびFlutterウィジェットフレームワークをSwiftに移植したもの（Flutter-to-Swiftフレームワークポート）から構成されています。コンポジターはwlrootsをラップするのではなく、ゼロから構築されており、レンダーパイプラインとウィンドウ管理プロトコル拡張に対するフルコントロールをプロジェクトに与えています。シェルとコンポジターをSwiftで記述することで、GCポーズのないメモリ安全性が確保され、システム層とアプリケーション層をまたいで言語ツールチェーンを共有できます。Flutter-to-Swiftポートにより、既存のFlutterアプリ開発者はC++エンジンの代わりにSwiftバックエンドを使ってデスクトップをターゲットにできるため、実行時オーバーヘッドの削減とより密なプラットフォーム統合が期待できます。ファーストパーティアプリ（ファイルマネージャー、設定など）も同一のSwiftコードベースで提供されており、APIサーフェスの一貫性が保たれています。コンポジターとアプリケーションランタイムを同時に置き換えるという点で、これはアーキテクチャ的に野心的な試みです。主なリスクはエコシステムの断片化であり、Swift Linuxツールチェーンおよび Flutter-to-Swiftバインディング層のメンテナンスは非自明な負担となります。
Source: https://github.com/starling-build/starling
guillaumemeyer/watermarks-remover
テキストおよびバイナリファイルからAI起源の出所信号を除去するための多層ツールです。対象とする信号クラスは3種類あります：Unicodeステガノグラフィ（ゼロ幅文字、ホモグリフ、テキストに埋め込まれたvariation selector）、統計的watermark（Kirchenbauer et al.のgreen-listアプローチのような手法を無効化するためにtoken分布を書き換えるフック）、そしてラスタ画像（PNG、JPEG）、ベクタグラフィクス（SVG）、ドキュメント（PDF、DOCX）、マークアップ（HTML、Markdown）に含まれるC2PA/EXIF/XMPメタデータです。Unicodeの衛生処理パスは正規形に正規化し、コピー＆ペーストを経ても残存する隠しチャネルを除去します。統計的な書き換えフックはよりヒューリスティックなアプローチです——検出器の秘密鍵にアクセスせずに真の統計的watermarkを除去することはオープンな研究課題であるため、このレイヤーはおそらく言い換えやtoken置換を適用していると考えられます。C2PAの除去は、Adobe Content Credentialsなどのツールによって埋め込まれた暗号的な出所チェーンを取り除きます。プライバシーを重視したドキュメントパイプラインに有用ですが、鍵付きwatermarkに対する統計的レイヤーの有効性は未検証です。
Source: https://github.com/guillaumemeyer/watermarks-remover
oversecured/Samsung_Vulnerabilities
Oversecuredの静的解析サービスによって発見された、Samsungのプリインストール済みAndroidアプリケーションにおける176件の脆弱性を公開したディスクロージャーリポジトリです。報告内容は、不十分なパーミッションチェックを持つexportedコンポーネントを介した権限昇格、ファイルプロバイダーにおけるパストラバーサル、intent リダイレクション、安全でないデシリアライゼーション、および資格情報の漏洩にわたっており、これらはすべて、システムレベルまたはシグネチャレベルの昇格した権限を持ち、エンドユーザーがアンインストールできないアプリに存在します。各エントリには、影響を受けるパッケージ、脆弱性クラス、割り当てられている場合はCVE、およびパッチの適用状況が記載されています。セキュリティリサーチとしての価値は二重にあります。単一のOEMのプリインストール済みサーフェスにおける膨大な発見件数は、ユーザーが何もインストールする前の攻撃対象領域がいかに広大であるかを示しており、また分類されたデータセットは、静的解析器のトレーニングや実際のAndroidコードに対するテイント解析ツールの評価に有用です。本リポジトリにはエクスプロイトのPoC コードは含まれていませんが、セキュリティエンジニアが緩和策を再現・検証するのに十分な詳細情報が提供されています。
Source: https://github.com/oversecured/Samsung_Vulnerabilities
denialwm/denial
Flutterで書かれたWaylandコンポジタです。FlutterをコンポジタのなかでG動くアプリケーションフレームワークとしてではなく、コンポジタそのものとして位置づけています。アーキテクチャはFlutterのレンダーツリーをディスプレイサーバのルートに置く構造になっており、他のWaylandクライアントからのウィンドウはFlutter widgetのサブツリーとしてコンポジットされます。そのため、ウィンドウデコレーション、アニメーション、シェルUIはFlutterのアニメーションおよびレイアウトプリミティブを用いてDartで表現されます。これによりモーションモデルが統一され、コンポジタのアニメーションとアプリUIが同一のフレームスケジューラとイージングカーブを共有できます。また、従来のデスクトップ環境で見られるシェルのクロームとアプリケーションコンテンツ間のインピーダンスミスマッチも解消されます。実装においては、Waylandプロトコルの処理（おそらくlibwayland向けのネイティブプラグインまたはFFI経由）、WaylandサーフェスのFlutter textureへのマッピング、および入力イベントの転送を扱う必要があります。主要な技術的リスクはレイテンシです。Flutterのラスタースレッドおよびdart GCのポーズは、ディスプレイサーバが求める厳格なフレームデッドライン要件を考慮して設計されていません。同様のオールインワンアプローチを取りながらSwiftを使用する、上述のStarlingと比較してみてください。
Source: https://github.com/denialwm/denial
inbjo/MirrorProxy
アダプターパターンを中心に構築された、オールインワンのミラー高速化プロキシです。共有プロキシコアがHTTP(S)リクエストのルーティング、キャッシュ、リライトを担当し、エコシステムごとのアダプターが上流レジストリを模倣するために必要なプロトコル固有のロジックを実装しています。対応しているのは、GitHubのrelease/rawエンドポイント、Docker/OCI distribution API（manifestおよびblobのリライトを含む）、npm、PyPI、Cargo、Goモジュールプロキシプロトコル（GOPROXY）、Composer、およびOSパッケージミラーです。各アダプターはリダイレクトURLのリライト、認証の注入、blobのローカルキャッシュが可能であるため、クライアントは単一の内部ホスト名を設定するだけで、すべてのエコシステムへの高速アクセスが得られます。エコシステムごとに個別のNexus/Artifactoryインスタンスを運用するよりも一体感があり、商用プロキシよりもセルフホストが容易です。アダプターの抽象化により、新しいエコシステムの追加も簡単で、対象レジストリプロトコルのリライトルールとキャッシュキースキームを実装するだけで済みます。エアギャップ環境、外部通信に制限がある企業ネットワーク、あるいはnpm/PyPI/DockerHubへの接続性が低い地域で役立ちます。
Source: https://github.com/inbjo/MirrorProxy
QuantumByteOSS/quantumbyte
自然言語による意図と実行可能なアプリケーションの間のギャップを埋めることを目的とした、オープンソースのアプリケーションビルダーエンジンです。掲げられた目標は、高レベルの記述から動作するアプリを生成することであり、商用のローコード/AIアプリ生成プラットフォームに対するオープンな代替手段として位置づけられています。技術的なアプローチとしては、コード生成パイプライン（スキャフォールドコードを生成するLLMバックエンド）と、ユーザーが生成されたコンポーネントを洗練できるビジュアルエディタ、および出力を実行するランタイムを組み合わせているようです。「エンジン」というフレーミングは、コア生成・実行ロジックが純粋なホスト型SaaSではなく、組み込み可能な形で設計されていることを示唆しています。MLエンジニアにとって興味深いエンジニアリング上の問題は、意図からコードへのマッピングをどのように信頼性高く処理するか、すなわち意図とコードの間に構造化された中間表現（例：コンポーネントグラフやDSL）を用いているかどうかという点です。そのような中間表現があれば、生のコード合成よりも生成をより制御しやすくなります。このリポジトリは初期段階にあり、アーキテクチャおよびサポートされる出力ターゲット（web、モバイル、デスクトップ）については、プロダクション対応を評価するためにさらなるドキュメントが必要です。