デイリーAIダイジェスト — 2026-08-20
arXiv ハイライト
Zetta ζ: 自己進化する物理知能のための効率的なクローズドループ型エンボディドハーネス
問題設定
凍結されたVLAポリシーをラップするエージェントハーネスは、end-to-endマニピュレーションモデルを長期タスクに拡張するためのデファクトスタンダードになっています。実際のところ、これらのハーネスは実行時にオープンループで動作します。すなわち、タスクを固定されたスキルシーケンスに分解し、それをディスパッチし、エピソードが終了した後にのみ振り返りを行います。この不一致は根本的なものです。物理的な接触イベントは数十Hzのオーダーで展開される一方、大規模なマルチモーダル推論モデルはコール当たり数秒のレイテンシで動作するため、事後的な振り返りではグラスプが滑ったり物体が移動したりした際に介入することができません。Zettaはこの欠けているピースを標的にしています。具体的には、\piを再学習することなくクローズドループによる批評とリカバリーをどのように追加するか、そしてハーネス自体をデプロイ中にどのように進化させるかという問題です。
手法
Zettaは責務を固定されたランタイムコンポーネントと進化可能なコンポーネントに分離します。アクションポリシー a_t = \pi(s_t, g; \theta) は \nabla\theta = 0 を満たし、Orchestrator Agent \mathcal{A}_{orch}（凍結されたマルチモーダル推論器）も同様に不変であり、リアルタイムの証拠に基づいてモード遷移を裁定するだけです。進化するのは「Evolvable Harness」\mathcal{H} = (C, R, T) です。これはアクション周波数で発火するコードベースのCritic、Criticがトリップした際に呼び出されるRecoveryスキル、およびツール・知覚プリミティブで構成されます。
3つのループが異なるタイムスケールで実行されます。
- アクション周波数のガバナンス。 Critic C は知覚出力（接触、姿勢、グリッパー状態）に対する軽量なPythonの述語であり、毎制御ステップで実行され、\pi をプリエンプトしてリカバリー R_i に制御を渡すことができます。
- ロールアウトレベルの提案。 ロールアウトが失敗すると、オフラインの進化エージェントが失敗軌跡をシグネチャによってクラスタリングし、メドイドシードを選択して、新しいCritic/リカバリーコードを提案します。
- 検証ゲート付きスキル更新。 提案されたスキルは開発シード上で再実行され、既存のシードを退行させることなく失敗を成功に転換するもののみが \mathcal{H} に受け入れられます。
オンラインのOrchestratorによる裁定とオフラインの進化エージェントによる最適化というデュアルエージェント構造こそが、デプロイ時の進化を実行可能にしています。高速なCriticはオフラインループによって既にコードに蒸留されているため、オンラインループは内側の制御ループで低速な推論器を呼び出す必要がありません。
Z-Infra
進化ループは帯域を大量に消費します。多数の並行ロールアウト、異種シミュレーター（LIBERO-ProおよびRoboCasa向けのCPU MuJoCo/robosuiteに加え、MJX、ManiSkill、Isaac Lab）、そしてGPUホスト型のVLA推論が必要です。Z-InfraはセッションベースのインターフェースとしてControl PlaneがEnv WorkerとRollout Workerへの呼び出しをルーティングする（reset、policy_step、知覚、プリミティブ）形式を提供します。
この分離こそが要点です。エージェントロジックは一度だけ記述され、CPUバウンドのシミュレーションインスタンスはGPUバウンドのポリシー推論から独立して多重化されるため、8×RTX 4090という小規模なクラスターでもオフライン進化ループに供給するのに十分な並行ロールアウトを維持できます。
結果
ベースポリシーはLIBERO-Proでは \pi_{0.5}、RoboCasaではGR00T N1.5であり、どちらもfine-tuningされていません。評価は厳密にホールドアウトされたシードを使用します。RoboCasaでは開発・進化に50シードを使用し、最終報告には別の50シードを使用しています。進化中に生成された失敗クラスターはメドイドシードのみで診断されます。
報告されている主要な数値： - LIBERO-Proの成功率：90.8%。 - RoboCasaの成功率：93.6%。 - 推論の高速化：ベースラインのエージェントパイプラインに対して11.1×。 - 成功率は自己探索バジェットとともに単調に増加し続けます（ラウンド数が増えるほどホールドアウト成功率が高くなります）。 - 学習されたCritic/リカバリースキルは、同じ失敗モードを共有する未見タスクへゼロショットで転移します。
高速化はステップごとのLLM呼び出しをコードCriticで置き換えることから生じており、精度の向上はオンラインのリカバリー経路と蓄積されたスキルから生じています。\theta が凍結されているため、すべての改善は \mathcal{H} に帰属できます。これは「ハーネス容量」と「ポリシー容量」のクリーンなアブレーションとなっています。
限界と未解決の問題
- Criticは知覚プリミティブに対するコードであるため、現在のツールセット T では観測できない失敗モードを診断することができません。T の拡張は手動で行う必要があります。
- 進化エージェントの提案は、それ自体が微妙な接触ダイナミクスの失敗を見逃す可能性のあるLLMに依存しています。論文では成功率を報告していますが、提案の受理率や偽陽性のCritic発火率については報告していません。
- 開発ではRoboCasaのタスクごとに50シードを使用しますが、ホールドアウトプロトコルにもかかわらず誘導されたCriticライブラリがシード分布に過学習していないかどうかは、より長いテール分布で検証する価値があります。
- すべての実験はシミュレーション（MuJoCo/robosuite）上で行われています。設計が「ハードウェア非依存」であるという主張はアーキテクチャ上のものです。実ロボットのレイテンシ、センサーノイズ、およびリセット不可能な失敗は、検証ゲート付き更新ステップにストレスをかけるでしょう。
- ベースポリシーは2つの特定のVLAです。ハーネスが非常に異なる失敗幾何を持つポリシーファミリー（例：diffusion policiesと自己回帰型VLAなど）にまたがって汎化するかどうかは示されていません。
なぜこれが重要か
Zettaは、デプロイ時の能力成長がハーネスのみ、すなわちオフラインで合成されオンラインで制御周波数でディスパッチされるコードレベルのCriticとリカバリーだけから得られることの具体的なデモンストレーションであり、基盤となるVLAは凍結されたままです。90.8%/93.6%という成功率と並んで11.1×の推論高速化を実現していることは、「エージェントループを高速化し自己修正可能にする」アプローチが、ポリシーのfine-tuningを繰り返すよりも信頼性の高いマニピュレーションへの実行可能な道筋である可能性を示唆しています。
Source: https://arxiv.org/abs/2608.16590
Co-RL: 多様なコホートによるマルチエージェントRLから教師なし推論が出現
問題設定
推論のための自己報酬型RL（self-rewarding RL）— モデル自身の多数決（TTRL）、確信度（Intuitor）、またはエントロピー（RENT）を擬似報酬として用いる手法 — は、検証可能な正解ラベルが不要であることから魅力的です。しかし構造的に不安定です：擬似ラベルは最適化対象であるrollout分布の関数であるため、系統的な誤りが修正されるのではなく強化されてしまいます。経験的にはこれは報酬の崩壊、生成長の劣化、均質化として現れます。本論文は、ラベルなしで独立した学習シグナルをどのように構築するかを問い、独立したパラメータを持つエージェントのコホートが互いに交差教師を行うことで十分であることを示します。
手法
Co-RLは、共有パラメータも勾配も持たない N 個のポリシー \{\pi_{\theta_n}\}_{n=1}^N を訓練します。ラベルなしプロンプト x に対して、各エージェントは K 個のrollout y_n^k をサンプリングし、回答 a_n^k = g(y_n^k) を抽出します。エージェント n の擬似ラベルは、指定されたペア（循環インデックス n-1）から導出されます：
\hat{a}_{-n}(x) \in \arg\max_b \sum_{j=1}^{K} \mathbf{1}[a_{n-1}^j = b].
エージェント n の k 番目の応答への報酬は r_n^k = \mathbf{1}[a_n^k = \hat{a}_{-n}(x)] です。各エージェントはその後、交差エージェント報酬に対してグループ正規化advantageを用いたGRPOを実行します：
\mathcal{J}_{\text{Co-RL}}(\boldsymbol\theta) = \frac{1}{N}\sum_{n=1}^N \mathcal{J}_{\text{GRPO}}(\theta_n; \{y_n^k, r_n^k\}_{k=1}^K).
重要な制約は、エージェント n が \hat{a}_{-n} に何も寄与しないことです。コホートの多様性は、モデルファミリー（Qwen、Llama、InternVL、Gemma）、モデルサイズ、およびプロンプトの言い換えを混合することで直交的に強化され、これらはすべてペア教師間の誤り相関を低減します。
理論的ダイナミクス
本論文の命題1は、この手法が機能する理由を明確に示しています。p_n = \Pr(a=a^\star \mid x) かつ K が奇数の二値正誤結果に帰着させると、自己報酬は次のように発展します：
\dot{p} = \eta\, p(1-p)\, \mathbb{E}_{C\sim\text{Bin}(K,p)}\!\left[\operatorname{sign}(C - K/2)\,\frac{\sqrt{C(K-C)}}{K}\right],
ここで \operatorname{sign} 項は p 自体に依存します — 更新は現在多数派の回答を強化します。Co-RLの下では、
\dot{p}_n = \eta_n\, p_n(1-p_n)\, \mathbb{E}[\operatorname{sign}(Z_{-n} - 1/2)]\, \mathbb{E}_{C_n}\!\left[\frac{\sqrt{C_n(K-C_n)}}{K}\right],
ここで Z_{-n} = \mathbf{1}[\hat{a}_{-n}(x)=a^\star] はペアのみによって決定されます。したがって、エージェント n の更新の符号は p_n から切り離されます：ペアが x において概ね正しければ、エージェント n 自身の多数決が誤りであっても a^\star に向かって引き寄せられます。二エージェントの場合、これは次の連立系に帰着します：
\dot{p}_A = q_K(p_A)\phi_K(p_B), \quad \dot{p}_B = q_K(p_B)\phi_K(p_A),
ここで \phi_K(p) = 2V_K(p)-1 は符号付き多数決方向です。p_A, p_B \in \{0,1\} における不動点は保たれますが、正しい不動点の吸引域は、二つのエージェントの誤りが完全に相関していない場合に厳密に拡大します — これはBlumとMitchellのco-training論証をGRPOに導入したものです。
実験設定と結果
言語モデルはMATHレベル3〜5で訓練され、GSM8K、MATH-500、AMC、HumanEval、MBPP、LiveCodeBench、GPQAで評価されます。VLMはMMR1-MathおよびMultimodal-open-r1で訓練され、MathVision、MathVerse、MathVista、We-Mathで評価されます。設定はテキストにはCo-rewarding（lr 3\times 10^{-6}、バッチ128、K=12、3072トークン上限、2エポック）、VLMにはR1-V（lr 1\times 10^{-6}、K=8、1024トークン上限）に従います。ベースラインはTTRL、Intuitor、RENT、Co-rewarding-II（自己報酬型）、MAPoRLおよびCoMAS（マルチエージェント）、そしてオラクル上限としての正解報酬付きGRPOを含みます。Gemma-3は、rolloutとポリシー分布が乖離するためトークンレベルのimportance samplingによる補正が必要です。
アブストラクトとアブレーションでは、(i) モデルファミリー・サイズ・言い換えにわたる多様性がCo-RLの性能を単調に改善すること、(ii) 自己報酬型ベースラインが崩壊する場面でも訓練ダイナミクスが安定していることが報告されています。アブレーションでは、自己報酬型の実行が複数のテストバックボーンにおいて報酬分散の崩壊と生成長の劣化を示す一方、Co-RLは訓練全体を通じて報酬分散と生成長を維持します；VLMエージェントは部分的な不一致を維持しながら、交換された擬似ラベルの精度が単調に上昇します — これは命題1によって予測された診断的特徴（情報量のある Z_{-n} が持続する）です。
限界と未解決の問題
理論的分析は、クリッピングとKLを省略した固定プロンプト上の二値結果への帰着に限定されています；実際の回答抽出 g(\cdot) を伴う多回答レジームは非公式な議論にとどまっています。報酬はピアの多数決との \{0,1\} 一致であるため、部分的な信用やプロセスレベルのシグナルが破棄され、ピアが誤った回答で一致した場合（多様性が軽減するが排除はできない相関誤りモード）には情報がありません。計算コストはコホートサイズ N に対して線形にスケールし、本論文の実験は8×H100上で N=2 を上限としています。循環的な教師グラフは設計上の選択であり、より密な投票グラフ（全対全、トーナメント）が誤り相関をさらに低減するかどうかは研究されていません。最後に、ここでの「推論」は依然として回答文字列の一致に基づいており、真に難しいプロンプト（どのエージェントもシグナルを持たない場合）でコホートが共通した自信ある誤りに収束することに対する保証はありません。
重要性
Co-RLは、安定性が経験的ではなく導出されたものである、原理的なラベルフリー訓練シグナルを提供します：教師を最適化対象のポリシーから切り離すことが、TTRL型自己報酬の自己確認的不動点を打ち破るのです。推論のためのRLが人間が出力を検証できる領域を超えて進む中、コホートの不一致 — 単一エージェントの内省ではなく — が正解の代替として有望です。
Source: https://arxiv.org/abs/2608.17253
SPADE: Self-Play in Adaptive Synthetic Executable Environments
問題設定
LLM推論エージェントのためのRLVRパイプラインは、その環境プールによってボトルネックになっています。手動でキュレーションされたベンチマーク、静的に合成されたデータセット、および固定されたverifierの設定は、いずれもタスク分布を固定するため、学習者が改善するにつれて訓練シグナルが飽和してしまいます。SPADEはこの問題に対処するため、環境分布そのものを学習・適応可能なオブジェクトとして扱います。すなわち、単一のLLM \pi_\theta が実行可能な環境を交互に生成しながらそれを解くことを学習し、生成タスクをエージェントの能力フロンティア付近に保つregretシグナルによって駆動されます。
手法
SPADEは、システムプロンプトによって選択される同一パラメータ \theta の2つの役割間のself-playとして、カリキュラム生成を定式化します。
- Environment Designer \pi_D：OpenAI Gymスタイルの
reset()/step()を実装するPythonプログラムを出力し、step()内に遷移 T(s'\mid s,a) と報酬 R(s,a) をエンコードします。また、特権的なヒント h（部分的な解のスケッチや構造的な手がかり）も出力します。 - Reasoning Agent \pi_A：マルチターンのアクションを通じて環境 e とインタラクションします。
環境は任意のPythonコードであるため、シングルターンQA（reset() → step(answer) → 終端報酬）と長期的なエージェント型ツール利用はどちらも同一のインターフェースに統合されます。designerは、(i) 高regretシードや難易度が高すぎる/低すぎるネガティブサンプルを含む環境メモリ M と、(ii) 事前学習コーパス C からのグラウンディング文書を条件として受け取ります。
designerの報酬はヒントベースのregretです。
r_D(e) \;=\; \mathbb{E}_{\pi_A}[R(e \mid h)] - \mathbb{E}_{\pi_A}[R(e)]
r_D を最大化することで、designerはヒントが実質的に役立つ環境、すなわち実現可能であるがまだ解けていない環境へと誘導されます。両役割はパラメータ \theta を共有し、GRPO（Shao et al. 2024）で更新されます。各サイクルで、RAはヒントなしで各環境を 16 \times k 回、ヒントありで 16 回プレイします。regretは同一の再生成ステップにおけるヒントなし/ありの平均の対応差を用いて計算されます。designerの更新は k ロールアウト分遅延され（truncated importance samplingを使用）、交互最適化を安定させるためのregretフロアが設けられています。候補となる環境は、構文・実行可能性バリデーターを通過した後にプールに追加されます。
このようにして出現するカリキュラムは質的に非自明です。単一の30B-A3Bの実行において、生成される環境は短いreset-then-answerタスクから状態にゲートされたマルチターンMDPへと変化していきます。
結果
バックボーン：Qwen3-4B-Instruct-2507、Qwen3-8B（thinking on）、Qwen3-30B-A3B-Instruct-2507。訓練：400ロールアウト × 24環境、全訓練期間を通じてホールドアウトベンチマークで評価。
Gamesセッティング（30B-A3B）。 スイート平均58.3、ベースラインから+8.1、最強の固定環境RLVEベースラインから+5.3。競技数学を除くすべてのホールドアウトカテゴリが改善（AIME’25/’26はベース61.5/73.5に対して62.8/74.4で保持）。GPQA-Diamond：75.8対70.4、LiveCodeBench-v6：47.3対43.2、Reasoning-Gym Math：63.3対45.0、Algorithmic：32.1対18.0、Cognitive：37.7対23.0、Logic：72.8対67.0。designerがホールドアウトタスクを一切訓練に使用していないにもかかわらず、性能向上が転移しています。
Tool-useセッティング（30B-A3B）。 ACEBench-Agent +13.9（そのステートフルDB + ツールスキーマ + マルチコール構造が生成環境に最も近い）、BFCL v4マルチターン +5.7（4Bでは+10.3）、\tau^2-bench +3.6。30BのSPADEはBFCL v4マルチターンとACEBench-Agentの両方で専用データ合成システムをリードしています。
スケーリング。 ベースに対する性能向上はモデルサイズに対して単調に増加します：+5.2（4B）、+5.7（8B）、+8.1（30B-A3B）。同等の計算予算での固定環境GRPOは全サイズで約+1.2に頭打ちとなります。静的プールはモデルが適合してしまうと固定シグナルとなり、学習が止まるためです。regret推定値が正を保つのは30B-A3Bのみで、4B/8Bでは有限サンプル推定量が長期間にわたって負に落ち込みますが、それでも性能向上は得られています。
アブレーション（Table 3、games、30B-A3B）。 - SPADE（フル）：58.3。 - 環境メモリなし：53.2。 - コーパスグラウンディングなし：53.5。 - メモリなし・凍結self-designer：40.5 — 未訓練ベースより9.7ポイント低下。共適応を凍結すると訓練が崩壊します。 - コーパス + メモリありの凍結GPT-5.5 designer：53.0で、SPADEの+8.1の約35%しか回復できず、LiveCodeBench-v6では改善に失敗（42.6対ベース43.2）。
部分的なバリアントも早期にピークを迎えてその後低下します（コーパスなしはステップ111付近、GPT-5.5 designerはステップ175付近）が、フルSPADEは訓練後半でも性能を維持します。カリキュラムの多様性も重要で、2スキルカリキュラムは53.7にとどまるのに対し6スキルバージョンは58.3を達成しており、性能向上の大部分は特定のゲームファミリーではなく多様性によるものだと言えます。
限界と未解決の問題
- regret推定量は分散が大きく、4B/8Bでは訓練の長期にわたって経験値が負になるため、designerはノイズの多いシグナルを最適化しています。それでも性能向上が現れるという事実はロバスト性を示唆しますが、メカニズムが完全に理解されているわけではありません。
- アブレーション制御は複数の要因を同時に変化させています（designerを凍結しながらメモリを削除したりモデルを交換したりするなど）。そのため、designerのgradient更新単独の因果的寄与を分離することは困難です。
- 実行可能なコード環境にはバリデーターが必要ですが、スケールでフィルタリングされたreward hackingや退化した環境の数は論文内で定量化されていません。
- Qwen3ファミリー以外のモデルでの結果がなく、\pi_D と \pi_A を別個のパラメータセットに分離した場合の比較もありません。パラメータ共有設計はアブレーションではなく選択です。
- ヒントの品質は、誘発されるregretに対して報酬を受ける同一モデルによって生成されます。designerがヒントチャンネルを悪用する可能性（自身の環境を自明にするようなヒントを書くこと）は直接測定されていません。
この研究の意義
SPADEは、「オープンエンドな改善にはオープンエンドなタスク空間が必要である」というAI-GA的主張を、「環境」がPythonコードに過ぎず「カリキュラム」がregretを最大化するポリシーである具体的なGRPOレシピへと具現化しています。固定環境RLがスケール全体で+1.2に頭打ちになる一方、適応的self-playが30Bで+8.1にスケールするという実証的な結果は、RL後訓練における次の希少リソースがデータ収集ではなく環境生成であることを示す強力な証拠です。
Source: https://arxiv.org/abs/2608.19197
訓練の痕跡：言語モデルの系譜検証のための中心化残差シグネチャ
問題設定
オープンウェイトのチェックポイントは、来歴メタデータをほとんどあるいはまったく持たないまま、日常的にfine-tuning、LoRAマージ、プルーニング、量子化、再配布されています。本論文が取り組む問いは、互換性のある2つのチェックポイントAとB（深さL、幅d、残差アーキテクチャが同一）が与えられたとき、訓練データ、活性化、またはフォワードパスへのアクセスなしに、重みのみから両者が重みレベルの共通祖先を持つかどうかを判定できるか、というものです。検証器は対称的な「Related/Unrelated」の判定を返す必要があり、さらに重要なことに、行動的類似性（例：スクラッチから訓練された蒸留済み生徒モデル）を重みの祖先関係と混同してはなりません。これはサプライチェーン監査における正しい分離基準です：蒸留は関数をコピーするのであって、重みをコピーするのではありません。
手法
核心となる観察は構造的なものです。残差ブロックはx_{\ell+1} = x_\ell + F_\ell(x_\ell)を計算します。ブランチF_\ellが非線形性を挟んだ線形写像W_1,\ldots,W_Kの系列である場合、ブランチ積を
M_\ell = W_K W_{K-1} \cdots W_1 \in \mathbb{R}^{d\times d}
と定義します。M_\ellは残差ストリームをその座標基底に写し返すため、対角成分には意味があります：単位行列とトレースレス行列はFrobeniusの内積のもとで直交しており、あらゆるブランチ積は
M_\ell = \tfrac{\mathrm{tr}(M_\ell)}{d} I + E_\ell,\qquad \mathrm{tr}(E_\ell)=0
と分解されます。スカラーシグネチャは正規化されたトレース集中度、
s(M) = \frac{|\mathrm{tr}(M)|}{\|M\|_F}
であり、これは行列のエネルギーのうちIに整合した割合（\sqrt{d}まで）を測定します。訓練は単位行列成分にエネルギーを集中させます：\|E\|_F \to 0のとき正しいペアのスコアは\sqrt{d}に近づく一方、不一致な射影は\mathbb{E}[s]\approx 1/\sqrt{d}を満たし、幅が大きくなるにつれてマージンが拡大します。
系譜スコアは以下の手順で構築されます：(i) 各ブロックでアーキテクチャに適したMLPブランチ積を抽出する（GELUとSwiGLUの因数分解の違いは合成する因子のみで、付録A.2を参照）、(ii) AとBのブランチ積の間でブロックペアリング行列s(i,j)を形成する、(iii) 中心化を行う——すべての残差訓練の後継が共有するトレース整合の単位行列成分を除去し、チェックポイント固有の残差E_\ellのみを比較する。中心化なしでは、訓練されたすべての残差モデルは互いに類似して見えてしまいます；単位行列成分は訓練レジームのシグネチャであって、系譜のシグネチャではありません。最終スコアは対称化され、独立したチェックポイントの小さなプールに対してキャリブレーションされ、s(i,j)に対するハンガリアンマッチングによってブロック対応関係が復元されます。
不対対・対対のマージンはdに比例してスケールし、ブロック対角構造はモデルスケールを通じて保持されます。
結果
s(i,j)によるブロックペアリングは、GPT-2、BERT、LLaMA-2、Mistral、Qwen2.5、DeepSeek-R1に対して正準MLPパスで100%の精度に達し、ランダム初期化ベースラインの\leq 4\%（表2）を大きく上回ります。AUROCは6ファミリーすべてで1.00（BERTは0.97）です。これにより、トレース集中現象が訓練済み残差スタックのファミリー非依存の特性として確立されます。
制御された系譜ベンチマーク——52のMLPペア（L=16、d=48）と45のGPT-2ペア（30Mパラメータ、L=6、d=384、TinyStories）——において、中心化残差シグネチャは両方でAUROC = 1.00を達成し、Gap-Z = +53.0（MLP）および+31.0（GPT-2）を記録しています。重みコサインはクリーンなベンチマークで競争力があり（Gap-Z = +76.3 MLP、+30.7 GPT-2）、整合Frobeniusはの AUROC = 1.00に達しますが、GPT-2では効果量が崩壊します（Gap-Z=+3.9）。特異値距離はGPT-2でAUROC 0.73に低下します。活性化ベースの手法（SVCCA、CKA）はフォワードパスを必要とし、GPT-2では精度が劣ります（0.99および0.86 AUROC）。決定境界手法であるIPGuardはMLPで最も悪く（AUROC 0.70、Gap-Z=-3.5）。重要なことに、行動的にはその教師モデルに類似している蒸留済み生徒モデルは、正しくUnrelatedとして分類されます。これは行動的手法が原理的に実現できない識別です。
「チェックポイントロンダリング」（素朴な重み比較を無効化するよう設計された関数保存的な重み変換）のもとでは、重みコサインと整合Frobeniusはマージンを失うか失敗するのに対し、中心化スコアは変化せず、GPT-2における最も近い堅牢なベースラインと比べて76\times高速に動作することが報告されています。公開チェックポイントを対象としたLLaMA-2のケーススタディでは、本手法は3つのrelatedモデルと7つのunrelatedモデルを正しく識別しています。
限界
検証器は互換性のあるアーキテクチャ（同一のL、d、残差因数分解）を前提としており、クロスアーキテクチャの系譜検証は対象外です。スコアは対称的であり、方向的な帰属（どちらが祖先か）はメタデータを必要とします。キャリブレーションには少数の独立したルート（GPT-2ベンチマークでは3つ）を使用するため、Gap-Z値は近似的であり、小さなプールから設定された閾値は見かけ上の精度のリスクを持ちます。線形モデルマージは部分的な系譜を生み出しますが、Related/Unrelatedというバイナリな枠組みではこれをきれいに表現できません。ロンダリング実験は著者らが構築したものであり、中心化シグネチャを特定して標的にする適応的な攻撃者（例：関数を保持しつつブロック対角整合を破壊する基底回転）は、報告されたセクションでは評価されていません。最後に、ブランチ積の対角成分への依存は、非残差またはハードリワイヤードされたアーキテクチャに対しては専用の因数分解が必要になる可能性があることを意味します。
重要性
オープンウェイトモデルの来歴検証は、暗号的手法（事前の署名が必要）か行動的手法（蒸留によって混同される）のいずれかでした。重みの祖先関係と出力の模倣を分離するデータフリー、ホワイトボックス、フォワードパス不要のシグネチャ——量子化、プルーニング、LoRAマージをも生き延びる——は、現在のモデルエコシステムのサプライチェーン監査のための具体的なツールです。そして、トレース集中現象そのものが残差訓練の検証可能な経験的規則性であり、理論的な説明に値します。
Source: https://arxiv.org/abs/2608.14929
SkillGate: 長期ホライズンエージェントにおけるin-policyなSkill Selectionの学習
問題：selector credit starvation
現代のエージェントフレームワーク（Claude Code、OpenHands、および類似のもの）は、skillsへの依存をますます高めています。skillsとはインストラクションファイルであり、通常は数千トークン程度で、エージェントがエピソードの途中でオンデマンドに読み込みます。公開ライブラリには現在、数千のskillsが登録されています。したがって、どのskillを読み込むかの選択はトラジェクトリ内で行われるポリシー決定ですが、標準的なoutcome-rewarded RLではそれを学習できません。本論文はこの失敗メカニズムを構造的に特定し、selector credit starvationと命名しています。broadcast形式のsequence-level GRPO advantageのもとでは、選択されたskillの名前を書き込む一握りのトークンがlossの極めて小さな割合しか受け取れず、ホライズンが長くなるにつれてそれらが受け継ぐ符号はますます誤ったものになります。正しいskillを選択することが往々にしてトラジェクトリにおける最も価値ある単一の決定であるにもかかわらず、正しい選択は下流の実行が失敗するたびに罰せられます。著者らは実際の学習成果物において、3つの性質（共有量の消失・符号の反転・大きさの低下）がすべてホライズンに対して単調に増大することを検証しています。
セットアップ：標準的なmixed slate
各タスクにおいて、エージェントにはK=16の候補skillが提示されます。各skill s=(\mathrm{name}(s),\mathrm{desc}(s),\mathrm{body}(s))は名前と一行の説明とともに公開され、bodyはエージェントがファイルを読み込むことを選択した場合にのみ開示されます。slateには、タスクを解くことが検証された1つのoracle s^\star、5つのmisleading hard negatives（話題的には隣接するが機能的には誤ったもの）、5つのrelevant bystanders、および2,045のskillから構成される公開ライブラリからサンプリングされた5つのirrelevant bystandersが含まれます。何も強制されておらず、エージェントは0個、1個、または複数のskillを読み込むことができ、読み込みは通常のtool callとして行われます。試行は30ターン／850秒の予算のもとで実行されます。
手法：2つの独立したcreditチャネル
SkillGateはrollout、報酬、optimizerをそのまま維持し、advantageがトークンに適用される場所を再ルーティングするだけです。学習対象トークンはread-actionのスパンに沿って分割されます：
- Selection tokens \bigcup_{a \in A(\tau)} I(a)：読み込まれるskillの名前を指定するidentityトークン。これらが選択の決定そのものです。
- Execution tokens：すべてのread-callスパンC(a)の外側にあるアシスタントトークン — 推論・他のtool call・作業など。
- tool-callラッパー（call spanからidentity spanを除いた部分）とskillのbody（observationとして届く）は、いずれのチャネルでも学習されません。
各分割は独自のadvantageを持ちます。taskチャネルはプロンプトごとにnのrolloutに対して標準的なgroup-normalized GRPO advantageを使用し、
A^{\mathrm{task}}(\tau) = \frac{R(\tau) - \mu_G}{\sigma_G + \epsilon},
read-callスパン全体を除外した上でexecution tokensのみにbroadcastします。selectionチャネルは各read action aをaction-localかつgroup-centeredなutilityでスコアリングします：
u(a) = \begin{cases} 1, & |A(\tau_a)| = 1 \text{ and } a \text{ reads } s^\star, \\ 0, & \text{otherwise,} \end{cases} \quad A^{\mathrm{sel}}(a) = u(a) - \frac{1}{|A(G)|} \sum_{a' \in A(G)} u(a').
式(1)から3つの設計上の性質が導き出されます。第一に、baselineはトラジェクトリではなくアクションに対するものであり、4つの候補を読み込む「読み過ぎの」sibling rolloutが全員のbaselineを下げます — これによりslate全体のスキャンにコストが課されます。第二に、\sum_a A^{\mathrm{sel}}(a) = 0が構造的に保証されており、このチャネルは読み込む・読み込まないという全般的な圧力を持たず、どの名前を書くかについてのみ作用します。第三に、自己制限的です：あるグループ内のすべてのrolloutがoracleを見逃すかすべてが綺麗に読み込む場合、utilitiesが一致してA^{\mathrm{sel}} \equiv 0となり — シグナルはグループが意見を分けた場所にのみ現れます。A^{\mathrm{sel}}には標準偏差による正規化を適用しません。actionのカウントが少なく、そのばらつきで割ることでノイズが増幅されるためです。両チャネルのトークン重みは混合係数\lambdaが適用される前にNに正規化され、両者は単一のGRPO updateに入力されます。
u(a)における単一読み込み制約は、主要なanti-gamingの仕組みです：oracle加えて他の3つを読み込んだ場合はスコアが0となり、oracleを2回読み込んだ場合も同様です。ポリシーはすべてを読み込むことでselection creditを得ることはできません。
評価プロトコル
5つのagenticsベンチマーク — Claw-Eval・SkillsBench・SETA・SWE・Terminal-Bench 2.0 — においてK=16のmixed slateのもとで評価します。学習にはClaw-Evalと独立した491のタスクを使用します。重要な点として、学習と評価のoracle identityは独立しており、名前とタスクの対応関係の暗記によって性能向上が生じたとは言えません。タスクのoutcomeは385試行プロトコル（56のnon-Clawタスクの4回繰り返し + Claw-Evalの161タスクの1回）で報告されます。読み込み行動の統計も同じ分母を共有し、より詳細なtrial単位の帰属は280試行のサブセット（70タスク × 4回繰り返し）を使用します。
制限と今後の課題
utility関数はタスクごとに既知のoracle s^\starに依存しており、整備された学習データが必要です — この手法はRL経由の教師あきselectorであり、完全に教師なしのskill discovererではありません。単一読み込みゲートによりu(a)は二値かつハードになるため、中間的なケース（文脈として関連するbystander 1つとともにoracleを読み込む場合）はcreditを受け取れず、真に最適な組み合わせ戦略を排除してしまう可能性があります。自己制限的な性質により、selection が一様に良いまたは一様に悪いグループはselectorチャネルに何も寄与しないため、収束付近や自明に難しいタスクでの学習が遅くなる可能性があります。本稿の抜粋では、混合係数\lambda、return decompositionやper-action baselineといった代替手法に対するablation、あるいはoutcome-only GRPOベースラインとの数値比較が開示されていません — これらが実際の差の大きさを決定するものです。
なぜ重要か
selector credit starvationは、少数のトークンが大規模な下流実行を制御するような長期ホライズンエージェント全般における病理であり、SkillGateの解決策 — トークンのサポートを分割して独立したadvantageをルーティングする — はskillファイルをはるかに超えて（tool choice・subagentのdispatch・retrievalクエリの形成など）適用できる明確なテンプレートです。この失敗モードの特定は、具体的な修正方法そのものよりも高い汎用性を持つと言えるでしょう。
Source: https://arxiv.org/abs/2608.18852
SemaPLC: PLCコード生成のためのプロジェクトグラウンド・検証ゲート型エージェントハーネス
問題と動機
プログラマブルロジックコントローラ（PLC）は物理プラントの制御ロジックを実行するため、コードの誤りは物理的な結果をもたらします。LLMベースのPLCコード生成はこれまで、弱いオラクル——典型的にはコンパイル成功と、まれに自己生成されたプロパティチェック——を用いて、孤立したプログラム編成ユニット（POU）上で評価されてきました。この評価では二種類の失敗モードが見落とされます：(i) 孤立したPOUとしてはコンパイルできるが、完全なIEC 61131-3プロジェクトに統合できない生成ロジック（変数の欠如、リソース競合、タスクバインディングの問題）、および (ii) 構文的または自己導出プロパティは満たすが、実際にランタイム上で実行されたときに仕様と意味論的に乖離するロジックです。SemaPLCは、モデル自身の判断ではなく、外部検証——仕様監査、統合コンパイル、ライブランタイムトレース比較——を唯一の完了基準とすることで、この両方に対処します。
手法
SemaPLCは、チャット補完インターフェース経由でアクセスされる汎用イベント駆動ツール使用コア（ReActスタイル）上に置かれたエージェントハーネスです。その上に、エージェントコア（計画・編集・解釈）、プロジェクト／タスクグラウンディング、PLCスキルライブラリ、検証プロセス、および完了ゲートの5つのコンポーネントを追加しています。環境へのアクセスは、構文チェック、コンパイル、デプロイ、ランタイムステータス／ログ、ライブ変数の読み取り／強制、トレースサンプリング、スクリプト化された動作チェックを公開する単一のModel Context Protocolツールサーバーを介して仲介されます。
コアループ（Algorithm 1）は検証ゲート型の修復ループです。要件 R とコンテキスト X（POUインターフェースまたは既存プロジェクト）が与えられると、ハーネスは \Gamma \leftarrow \textsc{Ground}(X) でグラウンディングを行い、L \leftarrow \textsc{Generate}(R, \Gamma) で生成を行います。評決 \mathcal{V} は空の状態から始まります。各イテレーションにおいて、有効な評決を持たない全てのチェック c \in K が再実行され、ログエントリ e_c が評決を確認した場合にのみ \mathcal{V}[c] が設定されます——これは、外部ログ行なしにモデルが成功を主張することを防ぐ「earned claims」ルールです。\mathcal{V} がトラック固有の完了基準を満たすと、ハーネスは L を受理します。そうでなければ、残りリトライのある失敗したチェックが \textsc{Repair}(L, \{e_c\}) に送られます。重要なのは、編集を行うと以前の評決が無効化される（\mathcal{V} \leftarrow \emptyset）ため、失敗したチェックだけでなく全チェックの再検証が強制される点です。ループは、完了時、リトライセット F = \emptyset の枯渇時、またはインタラクションバジェット B の消費時に終了します。
functionトラックのメトリクスはAgents4PLCに従います：V_f をモデル検査によって満たされたと確認された保留プロパティの割合とすると、
\text{VerifiedPass}(L_f) = \mathbb{1}[V_f \geq 0.80],
ここで、不確定評決（サポートされていない構文、変換の失敗、タイムアウト）は失敗としてカウントされ、生成の失敗は分母に残ります。判定は外部であり、ハーネスからは決してクエリされません。projectトラックは65タスクにわたって評価される3つの直交メトリクスを追加します：統合プロジェクトコンパイル、静的動作（アサーションオラクル）、および動的動作——最後のものは、生成されたロジックとリファレンスロジックの両方をライブPLCランタイムにデプロイし、実行されたトレースを比較することで測定されます。
結果
117タスクのfunctionトラックにおいて、SemaPLCは全7つのバックボーンで最高の厳密な検証済みパス率を達成しています。平均は72.6%であり、最強のベースラインAgents4PLCの63.9%を8.8ポイント上回ります。最強のバックボーンGPT-5.5では82.1%対79.5%を達成します。クロスモデル分散は収縮しています：SemaPLCの最悪バックボーン（67.5%）は全ベースラインの平均を上回り、スコアの幅はベースラインの25〜31ポイントに対して14.6ポイントです。完全ハーネスと素のバックボーンを比較すると、全てのモデルが8.5〜33.3ポイントの向上を示し、最弱モデルが最大の改善を得ています（MiniMax-M2.7 +29.9、DeepSeek-V4-Flash +33.3）。素のコンパイル率は平均85.5%から99.2%へ上昇し、クロスモデル分散は37.6から14.6ポイントへ縮小します——これは、ハーネスが特定のバックボーンに調整されたプロンプトではなく、モデルに依存しない信頼性レイヤーとして機能していることと一致しています。
projectコンテキストトラック（Table 2）では、3つの層が明確に分岐します。統合コンパイルは強力なモデルでほぼ飽和状態にあります（SemaPLC平均89.4% 対 Agents4PLC 71.2%、AutoPLC 81.5%）。静的動作スコアは70〜80台に集中しています（SemaPLC平均81.6% 対 ベースラインの71.7〜75.7%）。動的動作が識別力のある層です：SemaPLC平均52.2% 対 22.4（LLM4PLC）、31.4（AutoPLC）、30.3（Agents4PLC）。動的動作における最悪ケースのバックボーンは、ベースラインの3.0〜4.5%からSemaPLCの31.3%へ改善します。全手法にわたる静的スコアと動的スコア間の30〜50ポイントの差は、アサーションオラクルがトレースレベルのランタイム等価性に対して正確性を大幅に過大評価していることを示しています——リファレンス対候補のトレース比較は、プロパティベースのチェックでは検出されない意味論的乖離を捉えます。
制限事項と未解決の問題
本論文はゲインを「ハーネス全体」に帰属させており、分解はRQ3の層アブレーションに委ねています。報告された数値では、仕様監査、統合コンパイル、ランタイムトレース比較の相対的な寄与が明確に分離されていません。動的動作はGPT-5.5でも約65%で頭打ちになるため、リファレンスロジックへのトレース等価性は依然として困難であり、トレース比較オラクル自体もここでは詳述されていない許容度の選択に敏感です。0.80の検証済みパス閾値はAgents4PLCから継承されたものであり、そのカットオフに対する感度は報告されていません。インタラクションコスト（RQ4）は言及されていますが、バジェット B、リトライ制限 r、パス率のトレードオフは抜粋されたセクションでは定量化されていません。最後に、動作するMCPツール層（コンパイラ、ライブランタイム、強制インフラ）への依存性は、クローズドベンダースタックへの転用を制限します。
重要性
外部検証——特にライブランタイムトレース比較——をゲーティング基準とすることで、モデルの自己判断や自己導出プロパティの代わりに、LLM PLCコード生成をもっともらしさの演習から検証済み合成パイプラインに近いものへと変換します。動的動作における22ポイントの平均差と、弱いバックボーンに対する30ポイント超のゲインは、安価な実行可能オラクルを持つドメインでは、ハーネス側の検証がバックボーンのスケールよりも強力なレバーであることを示唆しています。
Source: https://arxiv.org/abs/2608.18565
OmniScientist: An Omni-Modal Omni-Discipline AI Scientist
問題設定
既存の自律型「AIサイエンティスト」パイプライン（SakanaのAI Scientist、エージェント型Kaggleシステム等）は、仮説から論文執筆までの表面的なループを閉じていますが、そのほとんどがテキスト・コード・事前計算済みの表形式サマリーのみを対象としています。著者らは、これが偶発的ではなく構造的な制限であると主張しています。科学的結論を支える証拠の多くは、例えば病理タイルにおける局所的な空間配置、三成分地震記録におけるチャネル間の位相、移動軌跡における時間的順序など、キャプションや順序なし特徴ベクトルへのシリアライズによって失われてしまいます。これらの関係が上流で除去されてしまうと、下流でどれだけ推論を重ねても復元できず、許容される研究課題の空間はそれに応じて縮小します。
本論文はこの問題を、テンソルの形状ではなく要求される推論パラダイムによって整理された、4つの分野横断的証拠ファミリーの分類体系として定式化しています：知覚的（画像、顕微鏡写真、スペクトル、波形、3D構造）、記号的（文書、数式、配列、知識グラフ）、定量的・統計的（表、分布、検定）、手続き的・動的（軌跡、シミュレーション、エージェントトレース）の4種類です。現状のシステムは中間の2つをカバーしており、知覚的ファミリーと手続き的ファミリーはそれらにとってほぼアクセス不可能な状態にあります。
手法
OmniScientistは、アイデア創出 → 実験 → 論文執筆という決定論的な3段階パイプラインであり、各段階が呼び出せる共有知覚レイヤーの上に構築されています。
知覚レイヤーが機構的に興味深い部分です。アーティファクトを積極的に画像にレンダリングしてVLMに投入するのではなく、（ファミリー → モダリティ → 登録済みツール）という階層的なアクセスを組織化しています。デフォルトのパスはネイティブ数値です：信号に対してはFFTピーク・トレンドの変化点・自己相関構造を配列から直接抽出し、表に対してはプロットせずに列の統計量を読み取ります。視覚的レンダリングは、保留中の問いが本質的に空間的またはトポロジー的な場合にのみ呼び出され、目的を絞った検査を強制するためにラン毎に予算制約が設けられています。数値特徴・視覚特徴・またはその両方を表面化するかどうかは、ハードコードされたルールではなくタスクのコンテキストが決定します。重要なのは、知覚バックボーンが全実験を通じて単一モデル（Claude Sonnet 5）に固定されており、推論バックボーンが入れ替えられる点です。これにより、スコアの変動は差分的なグラウンディングではなく推論器に帰因できます。
3つのエージェントはコードで強制された明示的なチェックの下で動作します：
- アイデア創出はマテリアルを観察し、文献を検索し、反証可能な仮説を出力しなければなりません；新規性スクリーニングが検索された文献に対してコードで実行されます。
- 実験はテストを設計し、コードを実行し、結果を検査し、標準出力・図・保存済み配列・設定を含む実行記録を出力します——自然言語のサマリーではなく、来歴オブジェクトです。
- 論文執筆は実行記録のエントリのみに基づいて主張を選択・根拠付けします；報告された数値を記録エントリと照合することで数値的トレーサビリティが強制されます。
これらはそれぞれアイデアチェック、厳密性チェック、主張チェックと呼ばれ、合わせて、より一般的なLLM-as-judge型の自己批評ループを機械的な制約に置き換えます。
Figure 4はこのフレーミングの最も強力な証拠です：地震学（エージェントが特定の到着時刻をフラグする三成分波形）、病理タイル、3D CAD、音声などのケースにわたって、パイプラインは生の記録内の局所的な手がかりを指摘し、そこから検証済みの定量的知見を導き出します——例えば、地震データセットにおいてノイズとラベル付けされたサンプルの21.7%が実際には実イベントであるという発見です。
結果
評価は5分野ファミリー・4証拠ファミリー全体にわたる36ケースを対象としています。分野外の2つのジャッジ（deepseek-v4-flash、gemini-2.5-flash-lite）が複合メトリックで完了したランを採点します。
見出しとなるテーブル（Table 4）は、成功したランのディスパッチから完了までの比率と平均複合スコアの両方を報告しています：
- Claude Sonnet 5：36/36完了、平均6.5。
- GLM 5.2：17/18完了、平均6.7（最高スコアだが、スイートの半数のみ）。
- Kimi K2.7：6/9完了、平均6.5。
- GPT 5.6：9/10完了、平均5.7。
- Qwen3.5 122B：30/34完了、平均5.4；27B：36ケース中32完了で5.3；9Bは32ケース中18完了の4.1に崩壊。
- Gemma-4 31B：36ケース中32完了で5.0；26B：34ケース中25完了で4.3。
2つの観察が導かれます。第一に、Sonnet 5のみがフルスイートを完了するため、部分的なカバレッジにおける平均スコアは直接比較できません——GLMの6.7は失敗しなかったケースのみが対象です。第二に、オープンウェイトファミリーは約30Bのアクティブパラメータ以下で急激な能力の崖を示します：小さいモデルが破綻するのはスコアではなく完了率であり、これはパイプラインが推論器に知覚レイヤーへのツール呼び出しを確実に行うことを求めるという要件と整合しています。
限界と未解決の問題
評価はLLMジャッジに依存しており、テスト対象のシステムとは異なるファミリーから選ばれているものの、複合スコアはドメイン専門家によるレビューに対してキャリブレーションされていません。36ケースのスイートはモダリティの観点では広いですが、各分野の深さは浅く、網羅性は示しているものの貢献の深さは示していません。主張チェックの仕組みは根拠のない主張を防ぎますが、エージェントが正しいデータに対して誤ったテストを選択することは防ぎません。知覚レイヤーは全体を通じてClaude Sonnet 5に固定されているため、「オムニモーダル」という主張が特定の独自モデルと結び付いており、例えばQwen-VLで知覚を提供した場合に同じツールインターフェースが汎化するかどうかは計測されていません。最後に、arxiv id 2608.13558は現在のarXiv番号体系の外にあるため、プレースホルダーか事後的な識別子である可能性があり、確認する価値があります。
なぜ重要か
本論文の実質的な貢献は新たなエージェントループではなく、証拠とエージェントの間のインターフェースこそが科学的推論が静かに切り捨てられる場所であるという主張と、ネイティブ数値と予算制約付きの視覚的アクセスを生のアーティファクトに組み合わせることで、キャプションやベクトルのインターフェースでは表現できない知見（例：地震ノイズの21.7%が誤ラベル）を取り戻せるという実証です。「ワークフローをカバーする」から「関係を保存する」へというその再フレーミングは、AIサイエンティストシステムを評価する上での正しい軸です。
Source: https://arxiv.org/abs/2608.13558
Hacker News Signals
AIの時代における数学
Terence Taoと共同研究者たちによるポジション/サーベイ論文で、AI ツール——主に大規模言語モデルと形式証明支援系——が数学的実践をいかに変容させつつあるかを考察しています。本論文は三つのレジームを区別しています：(1) 形式化における定型的ステップに対する検索/autocomplete ツールとしてのAI（Lean、Coq、Isabelle）、(2) 大規模コーパス上のパターンマッチングによる予想生成器としてのAI、そして(3) AIが真の概念的新規性に貢献できるかという、より困難な問いです。本論文は、証明検証という明確に定義されたタスク（決定可能かつ機械的）と、証明発見（現在のLLMが表面的な流暢さにもかかわらず新規の困難な問題では失敗する）を慎重に区別しています。具体的な主張として、Lean エコシステムとMathlib を組み合わせることで、正しい数学的推論ステップについてモデルを fine-tuning するのに十分な機械可読コーパスが形成され、正しさを検証可能にすることでハルシネーション問題を回避できるというものがあります。また本論文は、フィードバックループについても論じています——AI ツールが形式化のコストを下げることでMathlib の成長を加速し、それがトレーニングデータの質を向上させるというループです。認められている限界としては、最先端の数学的研究の多くが、検証済みの補題の列に分解できない概念的飛躍を伴うという事実、および現在のLLMが真に新規な定義を要する問題に対して低いパフォーマンスを示すという点が挙げられています。本論文が最も鋭く提起するオープンクエスチョンは、ボトルネックがデータにあるのか、アーキテクチャにあるのか、それとも数学的創造性の本質に関するより根本的な何かにあるのか、という問いです。「AI支援数学」が操作的な意味で実際に何を意味するのかという分類法を、一般的な言説と対比して理解するうえで、一読の価値があります。
Source: https://arxiv.org/abs/2608.16753
幾何学とCUDAプログラミングを用いたランダムな島の位置特定
地理位置情報パズルを計算幾何学およびGPUプログラミングの演習へと変換する、詳細なOSINTのウォークスルーです。著者は名前のない島の空撮画像を与えられ、それを特定しなければなりません。目視による形状マッチングを除外した後、アプローチはアルゴリズム的になります。すなわち、画像から島の輪郭を抽出し、正規化された形状記述子（モーメント不変量、アスペクト比、凸性）を計算し、OpenStreetMapの海岸線データから生成された島のポリゴンデータベースと照合します。
工学的に興味深い部分は総当たりマッチングです。世界中に数十万オーダーの島ポリゴンが存在し、各候補に対して著者はProcrustes流のアラインメント（重心への平行移動、スケールの正規化、最小回転距離の探索）を計算します。これは候補ごとに非自明なコストを伴うO(N)スキャンです。これはCUDAを用いてGPU上で並列化されており、各スレッドが1つの候補ポリゴンを担当し、形状類似度スコアを独立に計算します。著者はCUDAカーネルの構造、メモリレイアウト（ポリゴンの頂点はオフセットテーブル付きのフラット配列に格納）、そしてポリゴンサイズが不規則であるためにshared memoryがここでは有効でない理由について詳しく説明しています。
GPU探索の前に追加の制約によって候補集合が絞り込まれます。影の幾何学と太陽角度から推定された島の面積、および画像内の植生の種類から推定された緯度帯がその制約として用いられます。最終的な一致は衛星画像との照合によって確認されています。この記事は、OSINTの問題が明確に定義されたアルゴリズム問題に帰着できること、そして基礎となるデータが幾何学的に不規則であっても、独立した候補に対する総当たり探索にGPU並列処理が自然に適用できることを示す好例です。
Source: https://yassa9.github.io/osint/gralhix-004/
AI生成のGitHub Copilot「Autofix」によりSnowflakeのJiraへの侵害が可能に
WizによるSnowflakeの社内JiraインスタンスへのCI/CD攻撃チェーンに関するred-teamレポートです。このチェーンはGitHub Copilot Autofixの提案を悪用したものです。技術的な経緯は以下の通りです。GitHub Actionsのworkflowがシークレットスキャンのポリシー違反としてGitHubのコードスキャンにフラグを立てられました。Copilot Autofixはシークレットを削除する代わりに、それをGitHub Actionsのシークレット変数に移動するという修正PRを生成しましたが、同時にworkflow YAMLにコマンドインジェクションの脆弱性を導入しました。具体的には、その修正がユーザー制御の入力をクォートなしで直接run:ステップに補間していました。PRを開く権限を持つ攻撃者（公開リポジトリ、または侵害されたコントリビューターアカウント）は、シェルのメタキャラクターを含む細工されたブランチ名でworkflowをトリガーし、runnerコンテキストで任意のコードを実行することが可能でした。runnerからの攻撃は、runner環境で利用可能な認証情報を通じて内部Jiraインスタンスへのピボットへと発展します。このレポートは、脆弱性はCopilot自体にあったのではなく、AI生成のセキュリティ修正を人間によるレビューなしに自動マージするというパターンにあったことを強調しています。Autofixの提案は自動チェックを通過していましたが、それはYAMLコンテキスト内のインジェクションをフラグとして立てる静的解析ツールが存在しなかったためです。技術的な教訓は、YAMLベースのCIワークフローには周知のインジェクションクラス（${{ github.event.pull_request.head.ref }}など）が存在し、インジェクションベクターがコンテキスト依存で構文的に明らかではないため、LLMが見落とすことが常態化しているという点です。より広い懸念は、AI生成コードがセキュリティ修正として提示された場合に、まさにそのために人間によるレビューが疎かになりがちだという点です。
Source: https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug
「RISC-V：もっとうまく設計できたはずだ」への第三世界エンジニアからの反論
RISC-Vの設計上の選択（特にモジュラーISA、圧縮命令拡張、必須機能の欠如）が実際の組み込みシステムには不向きだと主張する投稿への反論記事です。リソースが制約された開発環境で執筆している著者は、いくつかの具体的な技術的主張に対して反論しています。モジュラリティへの批判については、オプション拡張モデルがフラグメンテーションを生むという議論に対し、ARM Cortex-Mも実際には同じ問題を抱えている（Cortex-M0 vs M4 vs M7のソフトウェア移植性はすでに慣例で解決されている問題であり、ISAで解決された問題ではない）と指摘することで反論しています。圧縮命令（RVC）への批判については、元の投稿が16ビットエンコーディングはツールチェーンを複雑にすると主張していたのに対し、反論ではRVCはflashが制約となるマイクロコントローラでコードサイズを大幅に削減し、ツールチェーンの複雑さはGCC/LLVMが吸収するものでアプリケーション開発者が負担するものではないと述べています。最も技術的に重要なセクションでは、割り込みレイテンシとM拡張が必須でないことについて取り上げており、著者はM拡張を持たないRISC-V実装がDSPワークロードで性能が低いことは認めつつも、これはISAの設計上の欠陥ではなく調達・選定の問題だと主張しています。また反論はコストの議論も直接取り上げており、RISC-V MCUは$2対$0.50というMCUのコスト差がプロジェクトの実現可能性に実質的な影響を与える市場のエンジニアにとってアクセスしやすい価格帯で入手可能だと述べています。この投稿は、元の記事による正式仕様の品質やデバッグインフラ（JTAG/RISC-Vデバッグ仕様）への批判にはあまり応えておらず、それらはより説得力のある技術的反論として残ったままです。
Source: https://rvembedded.com/blog_post/12/
Unsloth Dynamic 3.0 GGUFs
UnslothのDynamic 3.0 GGUFフォーマットは、標準的なGGUFにおける静的なビット幅割り当てを超える、レイヤーごと・テンソルごとの混合精度量子化を導入しています。核心となるアイデアは、すべてのtransformerレイヤーを同じビット深度で量子化するのではなく、キャリブレーションパスによってどのレイヤーが量子化誤差に最も敏感であるかを特定し（一般的に最初と最後の数レイヤー、attention projection、およびembeddingテーブル）、それらのテンソルには高いビット幅を割り当てつつ、感度の低いfeed-forwardレイヤーは積極的に量子化するというものです。使用される感度の指標は、キャリブレーションデータセット上でフル精度レイヤーと量子化レイヤーの出力分布間のKLダイバージェンスです。これは原理的に新規なものではありません（GPTQやAWQも同様のことを行っています）が、貢献点は、従来ファイル単位の均一な量子化レベル（Q4_K_M、Q5_K_Sなど）のみをサポートしていたGGUF/llama.cppエコシステムにこれを統合したことにあります。その結果、ビットが重要な箇所に再配分されるため、実効的な重みあたりの平均ビット数は標準的なQ4モデルより低いにもかかわらず、パープレキシティはQ5やQ6に匹敵するモデルが実現されます。報告されている数値として、Llama-3.1-8BにおいてDynamic 3.0の約3.8 bpwは、Wikitext-2上で標準的なQ5_K_M（5 bpw）に近いパープレキシティを達成しています。このフォーマットはメタデータが正しくパースされれば、llama.cppと後方互換性があります。主な制限は、キャリブレーションがデータセットに依存する点です——コーディング特化モデルに対する最適な混合精度割り当ては汎用モデルのものとは異なります——そして、UnslothがリリースしているこれらのGGUFは単一の汎用キャリブレーションセットを使用しています。
Source: https://unsloth.ai/docs/basics/dynamic-3.0-ggufs
Ornith-1.5: 自己スキャフォールディングから自己改善へ
Ornith-1.5は、モデルがタスクパフォーマンスのフィードバックに基づいて自身の推論スキャフォールディング（promptテンプレート、ツール使用ラッパー、chain-of-thought構造）を反復的に書き換え、その改善されたスキャフォールディングを用いて次世代モデルバージョンの学習データを生成するエージェントシステムを説明した、小規模ラボからのリリースです。ループの流れは次のとおりです：(1) 現在のモデルを現在のscaffoldで benchmark タスクセット上で実行する、(2) 失敗事例に対して、critic モデルを使用してエラーがscaffoldロジックにあるかモデルの重みにあるかを特定する、(3) scaffoldに問題がある場合はscaffoldを書き直して再評価する、(4) 改善されたscaffoldのもとでの成功した実行から (input, output) ペアを収集する、(5) このデータで次世代モデルバージョンをfine-tuningする。自己スキャフォールディングコンポーネントは比較的標準的でない部分であり、scaffoldリライターは現在のscaffoldコードと失敗トレースを入力として受け取り、修正されたscaffoldを生成する別途promptされたLLM呼び出しです。ここではreward hackingのリスクが存在し、scaffoldがタスクを見かけ上より簡単に見えるように書き換えられる可能性があります。論文ではscaffoldリライターが一切参照しないテストセットを保留することでこの問題に部分的にしか対処していません。定量的な結果は、内部のエージェント型 benchmark においての改善（1.0比でタスク完了率+12%）を示していますが、当該 benchmark は公開されておらず、他のエージェントフレームワークとの比較も存在しません。この自己改善ループは概念的にはSTaRおよび関連するself-playメソッドと類似していますが、推論トレースではなくスキャフォールディングに適用されている点が異なります。主要な未解決問題は、scaffoldの改善がタスク分布をまたいで汎化するのか、それともキャリブレーション用タスクセットに過適合するのかという点です。
Source: https://ornith.ai/ornith_1_5.html
Bun 1.4 のRust書き直しは問題ありか？
BunがZigからRustへと部分的な書き直しを進めていることについて、プロジェクトの公開開発状況を追っている外部の観察者が書いた批判的分析です。提起されている技術的懸念は具体的なものです。第一に、書き直しは完全なものではなく段階的である点です。Bunのコアとなるホットパス（JavaScriptCoreとのJSエンジン統合、バンドラーパーサー、HTTPレイヤー）はZigのままであり、Rust部分は新しいサブシステムとして追加されています。これにより、ZigとRustの間にFFI境界が生じますが、これはパフォーマンス上の懸念（境界を越えるには慎重なABI管理が必要であり、ゼロコストではありません）であるとともに、メンテナンス上の懸念（2つのビルドシステム、2つのメモリモデル、境界部での手動 unsafe ブロック）でもあります。第二に、著者はRust FFIレイヤーが境界部で微妙なメモリ安全性の違反を引き起こしているとする具体的なGitHub issueやPRを指摘しています。Rustが内部的に提供する安全性の保証はZig/Rustインターフェースをまたいでは有効ではなく、いずれにせよRust側では unsafe が必要になります。第三に、開発速度の問題です。RustサブシステムはBunチームの中の小さなサブセットによって開発されているようであり、PRのマージがZig側の作業に比べて遅い傾向にあります。著者はRustが原則として誤った選択だと主張しているわけではなく、第一の言語（Zig）がすでに手動メモリ管理を提供しているにもかかわらず、パフォーマンスクリティカルなインフラを第二の言語で段階的に書き直すことは、書き直されたサブシステムにRustのエコシステムライブラリ（tokioなど）が活用されていない限り、明確な見返りのない複雑さを生み出すだけだという点を論じています。そして本投稿は、それらが一貫して使用されていないと主張しています。
Source: https://tipiirai.com/writing/bun-rust-rewrite-worries
Go 1.27
Go 1.27にはいくつかの注目すべき変更が含まれています。最も重要なのは、ジェネリック型エイリアス機能の安定化です（以前は実験的な機能でした）：型エイリアスに型パラメータを持たせることができるようになり、type Alias[T any] = SomeGenericType[T] が合法でなかったという長年のギャップが解消されました。これは、APIの互換性のために型エイリアスを使用する大規模なコードベースにとって重要です。以前の回避策はラッパー構造体でしたが、それではinterface satisfactionが損なわれていました。2番目の注目すべき変更は、profile-guided optimization（PGO）の改善です：1.27ではPGOがより多くのインライン化の判断をカバーするように拡張され、PGOモードでのinterfaceコールのdevirtualizationが追加されました。これにより、プロファイリングデータが支配的な型を示している場合に、コンパイラがinterface背後の具体的な型を推測できます。これはJVM JITコンパイラでは標準的ですが、AOTコンパイラとしては新しい試みであり、benchmarkではinterface多用のワークロードで2〜5%のスループット改善が示されています。runtimeに新しいweakパッケージが追加され、GCの収集を妨げないポインタであるweak referenceが提供されます。これはfinalizerのハックなしにキャッシュを実装するのに役立ちます。testingパッケージにはT.Context()が追加され、テスト終了時にキャンセルされるcontextを返します。これにより、ctx, cancel := context.WithCancel(context.Background()); t.Cleanup(cancel) というボイラープレートパターンが不要になります。ツールの変更として：go testが-run-docでdocコメントの内容によるフィルタリングをサポートするようになり、リンカーは改善されたreachability analysisによるデッドコードのより積極的な除去により、netやcrypto/tlsをインポートするプログラムのバイナリサイズを削減しました。
Source: https://go.dev/blog/go1.27
Noteworthy New Repositories
Kylin010/tcpfit
静的なヒューリスティクスを適用するのではなく、実測値からマシンごとのパラメータを導出するデータ駆動型のTCPチューニングツールです。中心となるアイデアはシンプルながら、実際にはあまり活用されていません。各ホストのネットワークパスにおける実際のBandwidth-Delay Product（BDP）を計測し、そのパス上に存在するトラフィックシェーパーやポリサーの正確な変曲点を特定するというものです。これらの計測結果から、tcpfitはtcp_rmem/tcp_wmemバッファサイズ、輻輳ウィンドウの初期値、および関連するsysctlの適切な値を算出します。これにより、オペレーターが自分たちの所有しないハードウェア向けにチューニングされたブログ記事のカーネルパラメータセットをコピーしてしまうという、よくある失敗を回避できます。このツールは、負荷下でのRTTを推定するためのアクティブプローブを実行し、シェーパーが介入するポイントを見つけるためにパスを飽和させ、計測されたBDP（BDP = bandwidth \times RTT）に基づいてバッファの推奨値を適合させます。インスタンスタイプや配置グループごとに実効ネットワークパスが変化するクラウド環境において特に有用です。実装はshell/Pythonで、Linuxをターゲットとしており、リポジトリにはテストスクリプトといくつかの代表的なインスタンスタイプに対するサンプル出力が含まれています。明らかなCPUやNICのボトルネックがないにもかかわらずスループットの上限に達している、レイテンシ重視のサービスや高スループットのデータパイプラインを運用しているエンジニアが主な対象ユーザーです。
Source: https://github.com/Kylin010/tcpfit
ShawnPana/phone-harness
LLMベースのエージェントにAndroid（および部分的にiOS）のデバイス制御を公開するハーネス層です。このアーキテクチャは、ADBコマンドとAndroid Accessibility Serviceを構造化されたアクション空間——tap、swipe、type、scroll、back、screenshot——にラップしており、エージェントはfunction-callingまたはtool-use APIを通じてこれらを呼び出すことができます。スクリーンショットはキャプチャされ、オプションでダウンスケールされた上でvision inputsとして渡され、エージェントはアクショントークンを出力し、ハーネスがそれをデバイスイベントへと変換します。このリポジトリには、タスク分解のためのpromptスキャフォールディング、教師あり demonstration収集のためのシンプルなreplay/recordメカニズム、および異なるVLMバックエンド（GPT-4o、Gemini、Ollamaを介したローカルモデル）を差し替えるためのフックが含まれています。AppiumのようなフルGUI自動化フレームワークとは異なり、phone-harnessはスクリプト化されたテストシーケンスではなく、エージェンティックでオープンエンドなタスク実行に明示的に特化しています。設計上シンプルに保たれており、ハーネス自体はプランナーを実装していないため、ユーザーはすでに持っている任意のエージェントループと組み合わせて使用します。モバイルGUIエージェントの研究者、自然言語駆動のテスト生成を必要とする自動化QAパイプライン、あるいはエミュレータやWeb APIが公開する範囲を超えた実デバイスとのインタラクションを必要とするパーソナルアシスタントアプリケーションを構築している方に関連します。
Source: https://github.com/ShawnPana/phone-harness
Spielewoy/autoprompt-skill
マルチステップのコード生成におけるプロンプトの脆弱性に対処する、コーディングエージェント向けのパッケージ化されたスキルです。中心的な主張は、エージェント型コーディングベンチマークにおけるタスク失敗率を45%削減できるというものです。仕組みとしては、autoprompt-skillがエージェントのプロンプト構築ステップに介入し、軽量な classifier を用いて仕様不足または曖昧な命令パターンを検出し、LLM の呼び出し前にそれらを書き直すか拡張します。また、構造化されたコンテキストウィンドウを維持し、どのファイルが読み込まれたか、どの編集が適用されたか、どのテストが実行されたかを追跡することで、マルチターンセッションの後続ステップで文脈の喪失が起きないようにしています。このスキルは、薄いアダプタインターフェースを介して一般的なエージェントフレームワーク（LangChain、AutoGen、カスタムループ）と互換性のあるドロップインモジュールとして設計されています。実装は Python であり、リポジトリには HumanEval スタイルのマルチステップタスクを用いて報告された数値を再現するためのベンチマークハーネスが同梱されています。45% という数値は、普遍的な主張としてではなく、リポジトリの評価スクリプトに記述されたベースラインエージェントおよびタスクセットに対する相対的な値として解釈する必要があります。このツールは、プロンプトのドリフトがターンをまたいで発生することが、生のモデル性能ではなく支配的な失敗要因となる長期的なタスク（マルチファイルのリファクタリング、テスト生成パイプラインなど）でコーディングエージェントを運用しているチームにとって最も有用です。
Source: https://github.com/Spielewoy/autoprompt-skill
SuchanMadhikarmi/kubernetes-zero-to-production
47のレッスンと35以上のハンズオンラボで構成された、体系的かつ本番環境を意識したKubernetesカリキュラムです。ドキュメント参照スタイルとは異なり、このリポジトリはラーニングパスとして順序立てて構成されています。コントロールプレーンの内部構造から始まり、namespaces、RBAC、ネットワーキング（CNI、Services、Ingress、NetworkPolicies）、ストレージ（PV/PVC、StorageClasses）、ワークロードコントローラー、Helm、GitOpsパターン、可観測性、そしてハードニングへと進んでいきます。各レッスンのディレクトリにはマニフェストファイルが含まれており、ローカルクラスター（minikube、kind、k3s）またはマネージドプロバイダーに対して直接適用できます。アーキテクチャ図がインラインで掲載されており、podスケジューリング、etcdクォーラム、サービスメッシュのデータプレーンといった概念を明確に示しています。また、kubectlコマンドパターンを網羅したチートシート集も含まれており、CKA/CKAD/CKS認定試験の試験目標を具体的に対象としたセクションと、一般的な面接問題集も用意されています。面接対策コンテンツは、概念的な質問とデバッグシナリオ（podがCrashLoopBackOffやOOMKilledで停止する場合、スケジューリング障害など）の両方をカバーしています。アプリケーション開発からプラットフォーム／SREロールへの移行を目指すエンジニアや、Kubernetes認定試験の準備をしている方にとって、ラボ優先の構成は公式ドキュメントを順番に読むよりも実践的に活用できるでしょう。
Source: https://github.com/SuchanMadhikarmi/kubernetes-zero-to-production
guillaumemeyer/watermarks-remover
商用生成システムがコンテンツに埋め込むAIの出所証明シグナルを標的とした、マルチフォーマット対応ツールです。三つの異なるレイヤーで動作します。第一に、Unicodeテキストの浄化：SynthID-Textのようなシステムがトークン選択に統計的透かしを符号化するために使用するゼロ幅文字、ホモグリフ置換、および非印刷コードポイントを除去します。第二に、統計的書き換えフック：Kirchenbauer et al.の方式のように、green/redトークンリストのバイアスに依存する分散的透かしスキームを妨害することを意図した言い換え書き換えを適用します。第三に、メタデータの除去：PNG、JPEG、SVG、PDF、DOCX、HTML、およびMarkdownファイルからC2PA（Coalition for Content Provenance and Authenticity）マニフェストおよび標準的なEXIF/XMPメタデータを除去します。C2PAの除去は技術的に非自明です。なぜならC2PAは暗号署名された出所チェーンを埋め込んでいるため、本ツールはペイロードを除去できますが、有効な代替署名を偽造することはできません。これは明らかなデュアルユースの含意を持つ研究・監査用ツールです。技術的な価値は、これらの出所証明メカニズムがコンテンツにどこでどのように付加されるかを正確に示すリファレンス実装であるという点にあり、透かしの堅牢性を評価する研究者にとって有用です。統計的書き換えコンポーネントの有効性は、使用されている特定の透かしスキームに大きく依存します。
Source: https://github.com/guillaumemeyer/watermarks-remover
0xsline/awesome-deepseek-harness
DeepSeek Harness（DSH）フレームワーク向けのキュレーションされたエコシステムインデックスです。dsh-external/hub organizationおよび dsh-plugin GitHubトピックでタグ付けされたリポジトリから、プラグイン・インフラツール・インテグレーションパターンを集約しています。DSHはDeepSeekモデル向けのプラグインベースの実行ハーネスであり、ツール・検索バックエンド・エージェントスキャフォールディングをモデルのfunction-calling interfaceに接続する方法を標準化するものです。本リポジトリはアノテーション付きのレジストリとして機能しており、エントリはカテゴリ別（RAGコネクタ、コード実行サンドボックス、メモリバックエンド、モニタリング／トレーシングインテグレーション、UIフロントエンド）に整理され、各エントリにはプラグインのインターフェース仕様およびDSHバージョンごとの既知の互換性制約についての簡潔な説明が含まれています。その価値は発見容易性にあります。DSHプラグインエコシステムは多数の小規模リポジトリに分散しており、このリストによって特定のインテグレーションニーズに対してメンテナンスされた実装を探すコストを削減できます。その目的においてawesome-langchainやLlamaHubインデックスと類似していますが、DSHに特化したスコープとなっています。ベクトルストアコネクタ・ツールスキーマ・構造化出力パーサといった標準的な基盤部分を再実装することなく、DeepSeekモデル上でプロダクションシステムを構築するエンジニアが主な対象読者です。
Source: https://github.com/0xsline/awesome-deepseek-harness
Electricitysheep/dsh-handbook
DeepSeek Harness（DSH）フレームワークのバイリンガル（中英PDF）技術ハンドブックであり、インストールから高度なユースケースまでの完全な運用ライフサイクルを網羅しています。内容は実務者向けマニュアルとして構成されており、インストールと環境構築、プラグイン開発（plugin API、スキーマ定義、ライフサイクルフック）、パフォーマンスチューニング（バッチ処理、KV cache設定、量子化の選択とそのレイテンシ/品質トレードオフ）、そして実際のケーススタディが含まれています。注目すべきセクションとして、複数のDeepSeekモデルインスタンスがタスクに協調するマルチエージェント構成の実証的比較が提示されており、パイプライン・ブロードキャスト・階層型といった異なるエージェントトポロジーの選択に対して、実測スループットおよびタスク完了メトリクスが報告されています。これにより、汎用的なLLMデプロイメントガイドとは異なり、推奨事項がDSH固有の実際の挙動に基づいていることが特徴となっています。ハンドブックは静的PDFとmarkdownソースの両形式で提供されており、オフラインでの利用や検索が容易です。本番環境でDSHをデプロイする実務者で、入門パスと非自明なチューニング判断（特にマルチエージェント協調オーバーヘッド周り）のリファレンスの両方を必要とする方にとって、ソースコードの解読や断片的なGitHub issueの参照よりもはるかに即座に役立つでしょう。
Source: https://github.com/Electricitysheep/dsh-handbook
bawadou/ai-data-extractor
独自のローカル形式でデータを保存するAIコーディングアシスタントツールから、会話履歴を抽出・エクスポートするためのユーティリティです。対応ツールはClaude Code、Cursor、Windsurf、Aider、およびCline/Roo Codeです。各アシスタントはチャット履歴をそれぞれ異なる方法で保存しており、SQLiteデータベース、JSONブロブ、JSONLログ、またはプラットフォーム固有のアプリケーションデータディレクトリ内のカスタムバイナリ形式が使われています。このエクストラクターはツールごとにフォーマットパーサーを実装し、出力を共通スキーマ（ターンのロール、タイムスタンプ、メッセージ内容、添付コードコンテキスト、tool call/結果）に正規化した上で、標準形式（JSON、CSV、Markdown）に書き出します。実用的なユースケースとしては、外部APIに送信されたコンテキストの監査（プライバシーおよびコンプライアンス用途）、蓄積されたコーディングセッションからの個人向けfine-tuningデータセットの構築、ツール間での履歴移行、そして自身のコーディングアシスタント利用パターンの分析などが挙げられます。実装はPythonで、クラウド依存なし——すべての処理はローカルで行われます。リポジトリには対応ツールそれぞれのストレージスキーマに関するフォーマットドキュメントが含まれており、抽出コードとは独立した有用なリファレンスとしても機能します。開発者のクエリがローカルに保持されるか送信されるかに関してコンプライアンス要件を持つチーム、および実際のコーディングアシスタントインタラクションデータを研究したい研究者が主なユーザー層です。