デイリーAIダイジェスト — 2026-08-06

公開

2026年8月6日

English · 日本語

arXiv ハイライト

長期ホライズンターミナルタスクの再帰的合成

ターミナルエージェントの学習データが高コストである理由は、単一タスクが互いに整合性を保たなければならない4つの成果物を結合しているためです:自然言語による指示、サンドボックス環境、参照解(シェルの軌跡)、そしてロールアウトを実行可能なチェックで採点するverifierです。人手による作成では1タスクあたり数百〜数千ドルかかり、LLMによる直接生成ではこれら4つの成果物がサイレントに非同期化しがちです(例:verifierが指示で要求された内容をもはや検証しなくなるなど)。RST(Recursive Synthetic Terminal Tasks)は、合成処理を受理済みタスクに対する検証済み書き換えループとして扱うことでこの問題に対処し、15ラウンドにわたって37,484タスクを1タスクあたり約$0.05で生成しながら、難易度をシード分布をはるかに超えるレベルまで引き上げます。

手法

RSTはTerminalWorldから取得した639件の検証済みブートストラップシードから開始します。各合成ラウンド R_r は、R_{r-1} の受理済みプールからサンプリングしたシードに対して4段階の処理を適用します:

  1. オペレータの選択。 実行可能な書き換えオペレータ(例:ワークフローの拡張、依存ステージの追加、検証の厳格化)を選択し、シードの構造に条件付けた期待される結果を宣言します。
  2. 段階的書き換え。 まず実行可能な参照解を拡張し、次にverifier・公開指示・環境を新しい軌跡と整合性が保たれるよう更新します。この順序(解を先に、次にverifier/指示)こそが、指示優先のLLM合成に典型的なドリフトを防ぐものです。
  3. 検証。 候補タスクは静的チェック、アンチショートカット/リーケージ監査(作業を実施しなくても通過できるverifierを検出するため)、および新規サンドボックスでのエンドツーエンド実行を受けます。回復可能な失敗は上限付きの修復を受け、回復不能なものは破棄されます。
  4. 多様性キャップ付き再シーディング。 受理されたタスクは、次のシードプールに追加される前に、親系統・カテゴリ・書き換えファミリー・生成コホートに対するキャップの適用を受けます。

RSTにおける再帰的タスク合成とエージェント学習。

受理されたタスクは2つの下流での役割を果たします:R_{r+1} のシードとして、また学習タスクとして(verifierベースのRLに直接使用し、成功したロールアウトを通じてSFT軌跡としても使用します)。1ラウンドのパイプラインは図3に詳細が示されています。

1回の再帰的合成ラウンドの詳細パイプライン。

スケール・多様性・難易度

このパイプラインを639件のブートストラップタスクに適用すると、R_1 を定義する2,820件の受理済みタスクが得られ、R_{15} まで再帰することで合計37,484件のタスクが生成されます。実証評価における主要な2つの問いは、繰り返し使用によってプールが崩壊しないか、また難易度が実際に増加するか、です。

崩壊について:系統キャップはドメインのバランスをほぼ正確に維持します。19の統合ドメイン全体にわたって、最大ドメインはシードから R_{15} までプールの25%未満に留まり、正規化シャノンエントロピーは0.821から0.817へのわずかな変化にとどまり、有効ドメイン数は11.22から11.09へと推移します。

再帰的ラウンド全体にわたるドメイン構成と安定性。

難易度について:参照解の中央値は67行から374行に増加し、解あたりの実行コマンド数の中央値は40から244へと増加します(軌跡長でおよそ 6\times の増加)。DeepSeek-V4-Pro pass@4は R_1 の90%から R_{15} の2.5%へと急落しており、再帰処理が4回の試行を持ってしても強力なフロンティアモデルの手の届かないタスクを生成していることを示しています。

汚染監査

ターゲットとなるベンチマーク(Terminal-Bench 2、TMax-15KのTerminal-Bench Hard、Long-Horizon Terminal Bench)はターミナルタスクと表面的な特徴を共有しているため、RSTは R_1, R_5, R_{10}, R_{15} を89件のTB2 + 100件のTB-Hard + 46件のLHTBタスクと比較するリーケージ監査を報告しています。正規化13トークンスライディングウィンドウの下では、4つのラウンド全てにおいて完全一致は0/89、0/46、0/100です。最大ペアワイズ5-gram Jaccard類似度は0.009を下回ります(R_1 でのピーク J_5 = 0.0081R_{15} では0.0051まで低下)。各ベンチマークに対するユニグラムJensen–Shannon発散は r とともに単調増加します(TB2: 0.358 → 0.433、LHTB: 0.441 → 0.485、TB Hard: 0.331 → 0.406)。すなわち、再帰的合成はベンチマーク分布に近づくのではなく、遠ざかる方向に進んでいます。下流における性能向上はeval setとの分布収束に起因するものではありません。

限界と未解決の問い

いくつかの点を指摘しておく価値があります。第一に、難易度の代理指標はDeepSeek-V4-Pro pass@4であり、R_{15} での2.5%という通過率は、本当により難しいワークフローを反映しているのか、あるいはサンドボックス内では技術的には解けるが不良設定であるタスクを反映しているのかが不明です。アンチショートカット監査とサンドボックス検証は極端なケースを防ぎますが、中程度の病理(例:verifierの過度な仕様設定)は報告された統計量だけでは排除することが困難です。第二に、多様性は19の手動統合ドメインにわたって測定されており、これは粗い粒度です;そのような粒度でのエントロピー安定性は、ドメイン内での細粒度の書き換えファミリー均質化と両立します。第三に、コスト($0.05/タスク)はサンドボックスコンピュートの償却費用や、639件のブートストラップシードとオペレータライブラリに埋め込まれた人的労力を除外しています。最後に、汎化はSFT + verifierベースのRLで学習されたQwen3.5-27B/122B-A10Bに対してのみ実証されており、再帰深さ r が学習有用性とどのようにトレードオフするか、あるいは R_{15} よりも早い段階で飽和するかどうかは、示されている抜粋からは解決されていません。

この研究の重要性

長期ホライズンエージェントの学習は4成果物整合性問題によってボトルネックとなってきており、RSTは解優先・サンドボックス検証済みの再帰的書き換えループが、ドメイン崩壊やベンチマーク汚染なしにスケール(37kタスク)と難易度(pass@4が90%から2.5%へ)の両方を推し進められることを示しています。学習有用性に関する主張が正しければ、これは決定論的サンドボックスとプログラム的採点器を持つ任意のエージェントドメインに対して、検証可能で実行可能なカリキュラムを生成するための有望なテンプレートとなります。

Source: https://arxiv.org/abs/2608.05466

ABSeeker: Answer-Backtracked Credit Assignmentによる長期ホライズン検索エージェントの学習

問題

長期ホライズン検索エージェントは、クエリごとに数百回のツール呼び出しを実行することが一般的です。具体的には、ウェブ検索の発行、ページのオープン、エンティティのクロスリファレンス、候補のフィルタリングを経て、最終的な回答にコミットします。このようなエージェントを、デモンストレーション軌跡に対するSFTまたは結果報酬によるRLで学習させる場合、軌跡中のすべてのステップに対して同一のシグナルが用いられます。結果報酬

r_{\text{ans}}(\tau) = \begin{cases} 1 & \text{if } a = a^*\\ 0 & \text{otherwise}\end{cases}

は、二つの失敗モードを混同してしまいます。(i) 本質的に有用な中間的発見を含む失敗した軌跡では、それらの正しいステップに対してゼロシグナルしか与えられず、(ii) 冗長または誤誘導的な中間推論を含む成功した軌跡では、そのようなステップが依然として正に強化されてしまいます。ツール呼び出しが最大200回に及ぶ軌跡では、このcredit-assignmentのノイズが学習を支配します。

手法:Answer-Backtracked Credit Assignment (ABC)

ABCは、展開された軌跡 \tau=(s_1,\ldots,s_T,a) における各ステップ s_t に対して、スパースな二値の結果 r_{\text{ans}} を密な per-step 報酬 r_t に変換します。各ステップには、モデルの推論、ツール呼び出し、およびツールの応答が含まれます。

学習パイプラインの概要

パイプラインは二段階で構成されます。

Stage 1 — Answer-Backtracked Clue Recovery. クエリ q と検証済みの回答 a^* が与えられた場合、補助LLM(実験ではDeepSeek-V4-Flash)が a^* から逆向きに推論し、q から a^* への検証済みエビデンスチェーンを構成する中間的なエビデンスクルーの集合 \mathcal{C}=\{c_1,\ldots,c_K\} を生成します。これらのクルーは特定のロールアウトではなくground-truthの回答から導出されるため、軌跡に依存しないアンカーとして機能します。同一の \mathcal{C} が当該問題のすべてのロールアウトを評価するため、per-rolloutのクリティックモデルにおけるドリフトや不一致を回避できます。

複数制約クエリに対するBacktracked clue recoveryとclue-anchored step scoringの例。6つのクルー c1〜c6 と per-step スコアが生成される

Figure 3の例では、複数制約クエリから6つのクルー c_1c_6 が得られており、それぞれが a^* に到達するために解決すべき個別の制約に対応しています。

Stage 2 — Clue-Anchored Step Scoring. 展開された各ステップ s_t に対して、スコアラーLLMはクルー集合 \mathcal{C} のどのサブセットが、そのステップのツール呼び出しと観察によって進展・検証・否定されたかを測定します。これにより、未達成のクルーをステップが顕在化または裏付けた場合には正、冗長な検索に対してはゼロ、確立されたクルーをステップが破棄または否定した場合には負となる、細粒度のスカラー r_t が生成されます。重要な点として、このスコアは最終的な aa^* と一致したかどうかとは独立しています。つまり、失敗した軌跡の有用なステップには正のcreditが与えられ、成功した軌跡における怠惰または誤誘導的なステップにはペナルティが課されます。

Stage 3 — Optimization. 密な r_t シグナルが二つの学習手順を駆動します。ABC-SFTは、収集された軌跡に対してstepレベルのスコアによって模倣lossを再重み付けします(これにより、有用なエビデンス収集を含む失敗軌跡のステップも含め、高い r_t のステップに模倣が集中します)。ABC-RLは次に、ABC-SFTのチェックポイントを起点として、方策最適化における per-step 報酬として r_t を使用します。

実験設定

バックボーンはQwen3.5-4Bです。学習データはOpenSeekerから取得し、正解・不正解両方のロールアウトを保持します(rejection-sampling SFTからの逸脱)。SFTは3エポックで8,500の軌跡を使用し、RLは1,000問に対してそれぞれ8ロールアウトを使用します。軌跡長は200ツール呼び出しを上限とします。評価は4つのスイートにわたります。BrowseComp(複数制約クエリによる英語長期ホライズンブラウジング)、BrowseComp-ZH(中国語版)、xbench(専門的な深層リサーチ)、GAIA テキストのみ。各ベンチマークは3回実行して平均を取ります。

ベースラインは三層にわたります。検索機能付きフロンティア基盤モデル(Gemini-3.1-Pro、GPT-5 High、DeepSeek-V4-Pro-Max、GLM-5、Seed-2.0-Pro)、約30Bの検索エージェント(MiroThinker-1.7-mini、RedSearcher、DeepMiner、Tongyi-DeepResearch、OpenSeeker)、および4Bの検索エージェント(QUEST-4B、DR-Venus、AgentCPM-Explore)です。

結果

BrowseComp、BrowseComp-ZH、xbench、GAIAにわたる4Bおよびより大規模な検索エージェントとABSeekerの比較。縞模様の領域はコンテキスト管理が有効な場合を示す

Figure 1は主要な性能をまとめたものです。ABSeekerは4つのスイートすべてにおいて最強の4Bエージェントであり、概ね一桁大きいエージェントとも競争力を保っています。縞模様のオーバーレイは、コンテキスト管理を有効にした設定を示しており、これにより実効的な軌跡長が生の文脈制限を超えて拡張されます。200ツール呼び出しの予算を考慮すると、これは無視できない要素です。

限界と未解決の課題

クルー回復とステップスコアリングはいずれも強力な補助LLM(DeepSeek-V4-Flash)に依存しています。クルー回復における誤り — 必要な制約の欠落、または余計な制約の導入 — は当該問題のすべての報酬シグナルを汚染しますが、論文ではスコアラー品質に対する感度の定量化や、クルー集合に関する人間の一致率は報告されていません。また、本手法はクエリが離散的な検索可能なクルーの集合に分解可能であることを前提としており、これはマルチホップおよび複数制約ブラウジングベンチマークには適合しますが、「エビデンス」を明確に列挙できない全体的な統合や数値推論を要するタスクには適合度が低くなります。最後に、ABC報酬はロールアウトに対してオフラインで計算されます。スコアラーが学習ループ内で実行される必要があるオンポリシーRLへのスケールアップは、実質的な推論コストを伴いますが、論文ではベースのRL設定に対する計算オーバーヘッドは報告されていません。

なぜ重要か

検証済みの回答から導出された密な per-step credit — 学習済みクリティックや結果マッチングによるものではない — は、長期ホライズン検索が要求する約200ステップの軌跡からシグナルを救済する実用的な方法であり、4Bのエージェントがはるかに大規模なシステムに匹敵することを可能にします。本技術は検索を超えて一般化できます。検証可能な最終回答と分解可能な中間構造を持つ任意のタスク(マルチホップQA、ツール拡張数学、ユニットテスト付きコード)に対して、同様のbacktrackingベースの報酬が適用可能です。

Source: https://arxiv.org/abs/2608.05102

マルチモーダル事前学習の物理学に向けて:知識フロー、モダリティシナジー、早期統合、およびレシピ

本論文は、単一の下流タスクの指標を最適化するのではなく、言語モデリング、画像理解(image→text)、画像生成(text→image)の相互作用を研究対象として、統一マルチモーダル事前学習の制御された実証研究を実施しています。ネイティブ統合モデルの設計空間——いつvisionを導入するか、どのパラメータを共有するか、データをどのように混合するか——は、矛盾する結論をもたらすアドホックなレシピを通じてほぼ探索されてきました。著者らは、Transfusionフレームワーク(テキストに対する離散NTP、画像に対するrectified-flow matching)において固定の1.5B Llama-3スタイルのバックボーンを用い、100B〜2Tトークンにわたって混合実験を行い、レシピの選択に直接結びつく4つの知見を導き出しています。

セットアップ

バックボーンは16層、hidden次元2048、GQA(32 Qヘッド、8 KV)、FFN乗数1.5であり、モダリティ固有のsplit FFN(合計2.3B)を備えています。画像はデフォルトでRAEトークンを使用します:SigLIP-2 ViT-400m/14が16\times 16グリッドの256個のセマンティックトークンを生成し、生成はSigLIP潜在空間でのflow matchingとして行われ、Representation Autoencoderによってデコードされます。flow modelはx-predictionを使用し、velocity変換は v = (x_0 - x_t)/(1 - t) であり、CFG 5.0での25ステップEulerサンプラーを採用しています。flow-matching lossはテキストのcross-entropyに対して3\timesの重み付けがされています。タイムステップにはlogit-normalサンプリングを使用しています。汎用性を確認するために、3種類の代替ビジュアルトークナイザー(生ピクセル、CLIP+SD3 VAE、因果深度ヘッドを持つUniTok RQコード)を使用しています。

知識フローは非対称である

最初の実験ブロックでは、実際のWebデータ(SSTK image–text、DCLM text)上で一度に1つのモダリティをスケールします。

言語のスケーリングは理解ベンチマークと生成ベンチマークの両方を単調に改善します。言語はvisionに対するトレードオフが観測されない普遍的なブースターとして機能します。

図1:言語データのスケーリングが視覚的理解と生成に与える影響。言語の比率を増やすと、両方のvision能力が普遍的に向上します。

理解データのスケーリングは生成に対して大きな利得をもたらします——理解が生成が再利用するセマンティックな事前分布を提供することと一致しています——しかし、容量が転用されることで純粋な言語指標が目に見えて低下します。

図2:視覚的理解データのスケーリングの影響。視覚的生成に大きなメリットをもたらす一方で、純粋な言語性能を低下させます。

生成データのスケーリングは、対照的に、言語およびほとんどの理解タスクにおいてわずかな変動しか生じさせません:生成は他の能力に顕著にフィードバックしません。

図3:視覚的生成データのスケーリングの影響。視覚的生成を追加すると、言語とほとんどの理解タスクにわずかな変動が生じます。

合成レプリケーション(手続き的に生成された概念、概念ごとの評価)は、この相関的な描像を因果的な主張へと変換します:理解ストリームへの概念の挿入/削除はそれらの概念に関する生成性能に伝播しますが、逆方向は成立しません。結果として得られるDAGは language → {understanding, generation} および understanding → generation であり、generationはシンクです。

シナジー vs. 競合

統合が正味プラスになるかどうかは、タスクの複雑さとパラメータ共有に依存します。一方のモダリティにおける単純なタスクはモダリティをまたいでブースターとして機能しますが、十分に複雑なタスクは容量をめぐって競合し、シナジーは干渉によって支配されます。アーキテクチャ的に、本論文は一貫したレシピを見つけています:attention と normalization を共有し、FFN をモダリティごとに分割する。共有されたattention/QK-norm/RMSNormパラメータがクロスモーダルアライメント信号を担い、モダリティ固有のFFNがモダリティ特有の特徴変換を吸収し、2つのトークンストリームが同じMLP容量をめぐって競合することを防ぎます。このパターンはRAE、生ピクセル、CLIP+VAE、UniTokにわたって成立します——すなわち、特定のビジュアルトークナイザーや連続/離散画像モデリングの人工産物ではありません。

早期統合

visionを事前学習の後期段階に遅らせること、または language → understanding → generation を逐次的に学習することは、最初からの同時事前学習に対して一貫して劣るパフォーマンスをもたらします。逐次的カリキュラムは先行ステージで壊滅的忘却を示し、§3で特定された language→generation および understanding→generation の転移を実現できません。これは一般的な「LMを先に学習し、後でvisionを追加する」レシピに対する強い主張です:LM事前分布は、visionのlossがその事前分布を構築するトークンの学習中に存在するときに最も効果を発揮し、学習後ではありません。

スケールでのレシピ

知識フローの非対称性は直接的な予算配分への示唆を持ちます。生成は転移の源ではなく下流の受益者であるため、計算の混合比は言語と理解に大きく傾けるべきであり、生成データはこの共同学習体制においてサンプル効率が非常に高いです。早期統合およびshared-attention/split-FFNパラメータ共有と組み合わせて、著者らはこれをMoEバリアントに拡張して容量競合をさらに軽減し、このレシピが強力な統合ベンチマークに向けてクリーンにスケールすることを報告しています(具体的な最終数値は§6.2に示されていますが、本抜粋では再現されていません)。

限界と未解決の問題

制御実験は最大2Tトークンで1.5B/2.3Bパラメータで行われています;モデルが生成から理解への逆方向転移に十分な容量を発展させ得る30B+スケールで非対称性が弱まるかどうかはテストされていません。Transfusion結合(1つのモデルにおけるNTP + flow matching)は固定されています;「generationはシンクである」という結論は、画像合成の本質的な特性ではなく、flow matchingが表現学習に対して貧弱なgradient信号であることに部分的に起因する可能性があります。3\timesのloss重み付けは観測された非対称性と相互作用する可能性のあるハイパーパラメータです。最後に、「shared attention + split FFN」はテストされたエンドポイントよりも優れていることが検証されていますが、より細粒度の共有(例:FFN up-projのみの共有)は網羅されていません。

なぜこれが重要か

本論文はレシピの民間伝承を、どのモダリティがどれを助けるかについての反証可能な主張の小集合に置き換え、それらを因果的な合成ベンチマークで根拠付けています。もし language→understanding→generation のDAGがスケールで成立するならば、統一マルチモーダル事前学習は現在の「vision税」レシピとは大きく異なるべきです:言語と理解の計算を前面に配置し、早期に統合し、FFNではなくattentionを共有し、生成をほぼ無償の下流能力として扱うべきです。

Source: https://arxiv.org/abs/2608.05000

パーソナライゼーションという幻想:LLMがユーザープロファイルを捏造する仕組みと、自己監視が誤解を招く理由

永続的メモリによるパーソナライゼーションは、現在展開されているLLMアシスタントの標準機能となっています。モデルはセッションをまたいでユーザーに関する事実を蓄積し、その情報ストアに基づいて応答を生成します。これまで検討されてこなかった問いは、モデルの内部的なユーザー表現がユーザーの実際の開示内容と対応しているのか、それとも気づかぬうちに創作へと逸脱しているのか、という点です。本論文はその失敗モード——証拠によって裏付けられていないユーザー属性を主張する過剰推論(Over-Inference: OI)——を切り分け、現在のフロンティアモデル全般にわたって普遍的に発生することを示すとともに、自明な緩和策(自己監査)がモデル選択の観点においては無効どころか逆効果であることを明らかにします。

問題設定

形式的には、ユーザーが事実の集合 E = \{e_1, \ldots, e_k\} を開示し、モデルはユーザーに関する主張 C = \{c_1, \ldots, c_n\} を返します。忠実性は世界の真実ではなく E に対して定義されます——これは古典的な幻覚ではなく、ユーザー単位の根拠なき推論です。著者らは k=3 に固定し、パーソナライゼーションが誘惑的でありながら正当化されない、証拠が希薄なレジームを意図的に対象としています。

各主張は以下の4つの相互排他的なカテゴリのいずれかに分類されます:GroundedE の言い換え)、ReasonableE から常識的に一歩踏み込んだもの)、Stereotype(人口統計的・職業的な事前分布で代替したもの)、Fabricated(証拠的根拠が全くないもの)。

4分類のタクソノミー。下位2カテゴリが合わさって過剰推論を構成します。

過剰推論率は

\mathrm{OI\ Rate}(M) = \frac{\#\textsc{Stereotype} + \#\textsc{Fabricated}}{\#\textsc{Total Claims}}

と定義されます。

Reasonable/Stereotype の境界が操作上最も困難であるため、分類はテスト対象モデルではなく固定された独立Judge(Claude-Opus-4-7)に委託されています。このJudgeは、400件の主張を対象にブラインドの人間アノテーターと比較して検証されています:Cohen’s \kappa = 0.863(4クラス)、\kappa = 0.900(2クラス)。

MirageBench

MirageBenchは150のペルソナと「想像力グラジエント」にまたがる6つのパーソナライゼーションタスクを組み合わせ(モデルあたり900インスタンス)、Probe(明示的な信念の引き出し)、Task(通常使用における暗黙的推論)、Accum(縦断的蓄積)という3つの計測手段を用い、すべての出力をJudgeに送ります。

MirageBenchの評価パイプライン:Probe、Task、Accumが異なる推論モードを引き出し、固定されたJudgeが全主張を分類します。

ペルソナはグラウンドトゥルースとして15の属性プロファイル P を持ち、一人称で述べられた |E|=3 の事実と対応しています。12の属性が組織的に言及されていないため、いかなるパーソナライゼーションも外挿を必要とします。ペルソナはステレオタイプ的なもの50件、カウンターステレオタイプ的なもの50件、中立的なもの50件に層別化されており、「母集団の事前分布としてのOI」と「空白を埋めるためのOI」を明確に分離しています。合計:7ファミリーの12モデルにわたって143,616件の判定済み主張。

過剰推論の普遍性

12モデルすべてが35%から49%の主張において過剰推論を示しています。モデル間の平均OIは41.6%であり、143,616件の主張に対する主張加重マイクロ平均は41.8%です。Qwen3-8BがOI 48.7%でリーダーボードの首位を占め、最も良好な挙動を示したGemini-3.1-proでも35.1%に留まっています。パーソナライズされたコンテンツのうち E に根拠があるものはわずか24%〜31%に過ぎません。ユーザーの視点から見れば、アシスタントが「知っている」ことの約4分の3は、実際には一切伝えていない情報ということになります。

この点を鮮明にする2つの構造的な知見があります。第一に、捏造がステレオタイプを凌駕している点です:平均31.1%が捏造、10.5%がステレオタイプです。モデルは主として人口統計的な事前分布に依拠しているのではなく、発明しているのです。第二に、ペルソナタイプによる層別化が持続的なギャップを生み出しています:ステレオタイプ的なペルソナでOI 44.8%に対し、カウンターステレオタイプ的なペルソナでは37.0%(7.8 ppのギャップで、12モデルすべてに個別に存在し、モデルごとのギャップは +4.0 から +10.5 pp)。カウンターステレオタイプ的なペルソナは、マッチドコントロールではなく実質的なストレステストとして機能しており、「自明な」事前分布が真実と一致している場合、モデルのパフォーマンスが測定可能に向上することがわかります。

自己監視の逆転現象

自然な防御策は、主張をメモリに書き込む前にモデル自身に監査させることです。\mathrm{Gap}(M) = \mathrm{OI}_{\textsc{Judge}}(M) - \mathrm{OI}_{\text{self}}(M) とします。正のギャップ:モデルが自身の過剰推論を検出できていない。負のギャップ:過大報告している。

モデル間の分布は双峰性を示しています:Qwen3-8Bは +35.7 ppの過小報告(自己監査はOI 13.0%と報告するが、Judgeは48.7%と判定)、GPT-4o-miniは +25.0 ppの過小報告である一方、反対の端ではKimi-K2.5が -15.1 ppの過大報告(自己58.2%、Judge 43.1%)、GPT-5.4-nanoが -11.4 ppの過大報告となっています。校正された状態(\pm 1 pp以内)に収まるのは3モデル(DeepSeek-v4-pro、Gemini-3-flash、Qwen3.6-plus)のみです。

最も重要な結果はモデル選択のレベルにあります:自己評価によるOIとJudgeによる測定OIの間のSpearman \rho = -0.60(置換検定による p = 0.044n=12;ブートストラップ95% CI [-0.90, +0.06]、ファミリークラスタリング [-0.87, +0.14])。自己報告された誠実性によってモデルをランク付けすることは、外部OIによるランク付けを期待値として逆転させます。過剰推論が低いと最も自信を持って報告するモデルが、平均的に見てより悪い違反者です。信頼区間はゼロをまたいでいるため、これは決定的なものではなく探索的な知見ですが、定性的なメッセージ——自己監査は外部評価の代替にならない——は明確です。

制限事項と未解決の問い

評価は k=3 に固定されており、証拠密度が増加した場合のスケーリング挙動はここでは特徴づけられていません。また、|E| とともにOIが非自明な形で減衰する可能性もあります。Judgeは単一のフロンティアモデルであり、400件の主張における人間との高い \kappa にもかかわらず、143kの主張に対するJudge起因の系統的バイアスは排除できません。Reasonable/Stereotypeの境界は本論文自身が指摘する弱点です。そして n=12 では、自己監視の逆転現象のCIは広く——信頼すべきは符号であり、大きさではありません。本論文は緩和策を提案しておらず、自己監査が失敗することを示すのみです。

この研究の意義

永続的メモリによるパーソナライゼーション製品は、ユーザーモデルがユーザーを反映しているという前提のもとに出荷されています。本研究は、その前提がスケールにおいて誤りであること(主張の41.8%が裏付けなし)を示し、さらに人間工学的に自明な安全策——モデルに自己チェックを求めること——が、より安全なモデルを選ぶために使いたいランキングを逆転させることを示しています。この失敗モードに対して、外部の一定に保たれた判定は省略できません。

Source: https://arxiv.org/abs/2608.04570

Skill-Native LLMsに向けて:長期的推論のベンチマークおよびトレーニングのためのSkill Entropy

現在のLLMにおける長期的推論トレースは、異質なスキルを頻繁に混在させます。例えば、閉形式の式を導出し、その結果を用いてスケジュールを計画し、出力をJSONとしてフォーマットするといった具合です。既存のベンチマークは各スキルを個別に評価することが多く、そのためモデルのスキルごとの能力と、推論連鎖の途中でスキルを切り替える能力を分離することができません。本論文は、スキル切り替えの難しさをスカラー値かつモデル非依存の尺度(skill entropy)として提案し、それを中心に構築されたベンチマーク(Skill²-Bench)と、同じ量を報酬として利用するRLのレシピ(Skill-Entropy RL)を提案します。

Skill entropy

Skill entropyは、スキル s_a, s_b \in \mathcal{S} に対する有向ペアワイズ量です。固定された参照モデルのもとで、\text{Accuracy}(s) をスキル s に限定した多段階問題上の正答率、\text{Accuracy}(s_a, s_b) を最初に s_a を呼び出し次に s_b を呼び出す2ステップタスクにおけるステップごとの平均正答率とします。Laplaceスムージング \alpha = 0.1 を用いると、

\text{SkE}(s_a, s_b) = \frac{\tfrac{1}{2}\bigl(\text{Accuracy}(s_a) + \text{Accuracy}(s_b)\bigr) + \alpha}{\text{Accuracy}(s_a, s_b) + \alpha}.

\text{SkE} > 1 はスキルの連鎖がスキルごとのベースラインに対して正答率を低下させることを意味し、\text{SkE} \leq 1 は切り替えがほぼコストなしで行えることを意味します。順序は重要であり、一般に \text{SkE}(s_a, s_b) \neq \text{SkE}(s_b, s_a) です。なぜなら2種類の2ステップ合成は異なるタスクだからです。SkEは固定された参照モデルのもとで定義されるため、評価されるすべてのシステムに共通の難易度軸として機能します。

タスクレベルへの拡張では、タスクのスキル系列に沿ってペアワイズSkEを集約し、Skill²-Benchの層別化に使用される3段階の難易度レベルに分位数ビニングします。

Skill²-Bench

このベンチマークは9つのドメインにまたがる558の labeled スキルをカバーしています。数学、科学、コーディング、論理、情報抽出、計画立案(検証可能、OpenR1-Math・MMLU-Pro・LiveCodeBench・ZebraLogicBench・WikiTable/WebSRCおよびNaturalPlanなどのシードを使用)に加え、創作文章作成、文脈検索、指示追従(オープンエンド、ルーブリックによるLLM評価)が含まれます。

ベンチマークとトレーニングの概要

ドメイン間の切り替えは著しく非一様です。ペアワイズSkEのヒートマップは、数学的なソースから特定のドメイン(例:計画立案、創作文章作成)へ切り替える方が、逆方向よりも系統的に難しいことを示しており、ドメインごとの正答率はドメインごとのskill entropyと強く逆相関しています。

ドメイン間のSkill entropy:ペアワイズ(ソース、ターゲット)ヒートマップおよびドメインごとの正答率対skill entropy

8つのフロンティアモデルと4つのオープンソースモデルを評価したところ、タスクレベルのskill entropyが増加するにつれて正答率が単調に低下する「スキル切り替えギャップ」が観察され、これは小規模なオープンソースモデルほど大きいことが分かりました。

Skill-Entropy RL

2つ目の貢献は、skill entropyをトレーニングシグナルに変換することです。クロススキルタスク \tau = ((q_1,a_1),\dots,(q_L,a_L)) は、明示的なスキル宣言とステップごとの回答を交互に配置した構造化フォーマットで回答されます:

<think> ... </think>
<skill> Domain_i, Skill_i </skill><answer> Step_i Answer </answer>

この応答は予測されたスキルプラン \hat\mu(\tau) = (\hat s_1,\dots,\hat s_L) と回答系列にパースされます。GRPOはタスクごとの複合報酬で実行されます:

r = \lambda_{\text{ans}} r_{\text{ans}} + \lambda_{\text{ent}} r_{\text{ent}}, \qquad r_{\text{ent}} = 1 - |\hat\rho - \rho^\star|,

ここで r_{\text{ans}} はドメインごとのスコアラーによるステップごとの平均正答率であり、\hat\rho, \rho^\star \in [0,1] はそれぞれ予測されたおよびゴールドのタスクレベルのskill entropyのトレーニング分布上における経験的ランクです。\hat\rho を計算するために、各予測スキル文字列はまずembedding類似度によって558スキルバンクの最近傍エントリにマッピングされるため、報酬はゴールドスキルの意味的な言い換えを許容します。直感的には、r_{\text{ent}} はモデルに対して単にラベルを当てるのではなく、難易度プロファイルがゴールドプランに一致するスキル系列を計画するよう促します。

結果

Qwen3-4B-Instructを用いたSkill²-Benchでは、ベースモデルが平均34.4を達成します。SFTは55.8、vanilla GRPOは58.8に達し、既存のpost-training手法(Skill-Distill 58.1、SkillRL 59.3、STAT 61.4)はすべて50後半から60前半にまとまっています。Skill-Entropy RLは68.4に達し、最強のベースラインから+7.0の改善を示します。改善は広範囲にわたります:数学44.7→49.3、コーディング42.8→47.8、科学54.6→71.1、論理41.4→47.1、創作文章作成68.8→85.6。Qwen3-1.7Bでも同様の傾向がより顕著に見られます:14.6(ベース)→40.1(Skill-Entropy RL)、一方で最良のベースライン(STAT)は33.0です。特に小規模モデルでは数学が14.3(GRPO)から27.4へ大きく向上しており、スキルプラン報酬がベースポリシーが最も弱い場面でこそ有用な構造を提供することを示唆しています。

定性的には、Figure 3のケーススタディはSkill-Entropy RLが修正する失敗モードを示しています。ベースのQwen3-4Bは、ステップ1で数値的な数学の結果を生成した後、ステップ2の問題が「Theme Creation」と散文的な回答を要求する場合でも、数学スタイルのスキルと短い数値回答を繰り返す傾向があります。トレーニング後は、宣言されたスキルと回答のモダリティの両方を切り替えるようになります。

ケーススタディ:Skill-Entropy RL後のよりクリーンなスキルおよび回答モダリティの切り替え

限界とオープンな問題

SkEは固定された参照モデルに対して定義されており、参照モデルが改善されるにつれて誘導された難易度ランキングが安定するかどうかは未検証です。報酬 r_{\text{ent}} は固定された558スキルバンクへのembeddingベースのマッチングに依存しているため、バンク外のスキルは暗黙のうちに最近傍に射影されます。これにより、創造的だがマニフォールド外のプランへのペナルティが過小評価される可能性があります。Skill entropyはペアワイズに定義され、タスクレベルにヒューリスティックに集約されており、3つ以上のスキルにまたがる高次の相互作用(例:非マルコフ的な依存構造)はモデル化されていません。最後に、オープンエンドドメインにおけるステップごとのスコアリングは依然としてLLM判定に依存しており、ペアワイズSkEの定義もこの問題を引き継いでいます。

なぜこれが重要か

Skill entropyは、これまで暗黙的だったスキル切り替えのコストを直接測定可能かつ直接最適化可能にするシンプルなモデル相対的な量です。この同じスカラーが、切り替えギャップを露わにする評価軸として機能すると同時に、Skill²-Benchにおいてその約7ポイントを縮小するRL報酬としても機能するという事実は、長期的推論においてスキル合成の構造——単なるスキルごとの能力ではなく——が第一級のトレーニングターゲットであることを示唆しています。

Source: https://arxiv.org/abs/2608.05139

教師が誤誘導するとき:Spurious-Signal-Aware On-Policy Distillation

On-policy distillation(OPD)は、大規模な instruction/reasoning モデルを圧縮するための主力手法となっています。学生モデルは軌跡 y \sim \pi_\theta(\cdot\mid x) をサンプリングし、教師モデル \pi_T が学生自身のプレフィックスに対してトークンレベルの密な KL シグナルを提供します。近年の「選択的」OPD の変種は、このシグナルを信頼度・情報量・学習可能性によって枝刈りします。本論文は、こうした選択器がすべて構造的な失敗を見逃していると主張します。すなわち、教師の高ダイバージェンストークンは、x 中の証拠ではなく、入力に依存しない言語的先行分布——フォーマットの習慣、固定化された推論テンプレート、固有名詞のデフォルト——によって引き起こされている可能性があるという点です。そのようなトークンは大きな gradient を生み出し、タスク能力を改善することなく、学生を教師の idiolect へと誘導してしまいます。

Spurious signals の形式化

A_t = \log \pi_\theta(y_t \mid x, y_{<t}) - \log \pi_T(y_t \mid x, y_{<t}) を、学生が訪問したプレフィックス上でサンプリングされた教師–学生の対数比とします。A_t に stop-gradient 処理を施すと、OPD の更新式は次のようになります。 g_t^{\rm OPD} = -A_t \nabla_\theta \log \pi_\theta(y_t \mid x, y_{<t}). 本論文は A_t = A_t^{\rm grd} + A_t^{\rm prior} と分解します。ここで A_t^{\rm grd}x とともに変化し、A_t^{\rm prior} はプレフィックス y_{<t} のみから予測可能です。gradient の線形性により g_t^{\rm OPD} = g_t^{\rm grd} + g_t^{\rm prior} が成り立ちます。|A_t| や教師のエントロピーでランク付けする選択的 OPD 手法は、これら二つの成分を区別できません——A_t^{\rm prior} が大きいトークンは、まさに信頼度が高くダイバージェンスも大きい傾向があるため、重みが増大してしまいます。

Spurious signals の例示:入力画像を除去してもトークンレベルのダイバージェンスがほぼ変化しない様子。

Figure 1 は、VLM の設定においてこの失敗を具体的に示しています。学生のロールアウトに沿った多くのトークンにおいて、教師–学生のダイバージェンスは画像と質問の有無にほぼ不変です。これらのトークンの supervision は入力に依存し得ないことになり、A_t^{\rm prior} がシグナルに成り済ましているわけです。

SA-OPD:入力への根拠性プロキシ

SA-OPD は、安価なアブレーションによってこの分解を具体化します。各ロールアウトについて、残差 no-prompt コンテキスト(x を除いた同じ y_{<t})上で教師と学生の対数確率を再計算します。ダイバージェンスの変化量 \Delta_t = A_t - A_t^{\rm no\text{-}prompt}A_t^{\rm grd} のプロキシとして用います。|\Delta_t| が小さいほど、そのトークンの supervision は先行分布によって支配されていることを意味します。SA-OPD は、次の二条件を同時に満たすトークンをフィルタリングします:(i) 入力への根拠性が低い(|\Delta_t| が閾値未満)、かつ (ii) 最適化への影響が大きい(|A_t| が上位テール)。根拠性が弱くても影響が小さいトークンは無害であるため保持され、根拠性が強ければダイバージェンスが極端に大きくても保持されます。これはそのトークンが真のタスクシグナルを持っているからです。

SA-OPD パイプライン:元のコンテキストと no-prompt コンテキストの両方でダイバージェンスを計算し、根拠性が弱く影響が大きいトークンをフィルタリングする。

機械的なコストとしては、短縮されたコンテキスト上での教師と学生のフォワードパスが各ロールアウトにつき一回ずつ追加されますが、これはサンプリングコストに対して償却可能です。フィルタは式 (1) の reverse-KL loss にトークンごとのマスクとして適用されます。再重み付けや補助的な loss は導入されないため、既存の OPD インフラとの相互作用は最小限に保たれます。

実験設定とダイナミクス

実験では Qwen3 および Qwen3.5 の non-thinking 変種を使用し、主設定として教師/学生ペアに Qwen3-4B-Instruct → Qwen3-1.7B と Qwen3.5-35B-A3B → Qwen3.5-2B を採用しています。汎化性の検証には DeepSeek-R1-0528-Qwen3-8B → Qwen3-1.7B と Qwen3.5-9B → Qwen3.5-2B を使用しています。テキストのみの OPD では難易度 ≥6 にフィルタリングされた約 7K の DeepMath サンプルを使用し、VLM OPD では VERO-600K(キャプショニング/IF、グラウンディング、カウンティング/検索)から 10% のサンプルと視覚推論用の MMRL30k を使用しています。

タスクをまたいだ学習ダイナミクス:SA-OPD は同じステップ数でより高い検証精度を達成し、通常の OPD で見られる学習後期の精度低下を回避する。

Figure 3 は本手法が対象とする定性的なパターンを示しています。vanilla OPD の検証曲線は、prior 主導の gradient が蓄積されるにつれて後期の学習で横ばいになるか低下しますが、SA-OPD の曲線は上昇し続けます。これは機構的な主張と整合しています——g_t^{\rm prior} を除去することで、容易で根拠のあるシグナルが枯渇した後も、学生が教師の入力非依存的なスタイルへと偏移することを防げます。

限界と未解決の問題

no-prompt アブレーションは A_t^{\rm grd} の一次近似プロキシです。これはプレフィックス y_{<t} 自体が入力内容をエンコードしていないことを前提としています。前段の推論が問題を言い換えているような長い chain of thought では、A_t^{\rm no\text{-}prompt} が依然として入力の情報を含んでおり、フィルタがアンダーフィルタリング側に偏る可能性があります。双閾値ルール(|\Delta_t| が低く |A_t| が高い)では、おそらくタスクごとの調整が必要な二つのハイパーパラメータが導入されます。閾値やトークン数バジェットとの相互作用に関する論文中のアブレーションが、どれほど脆弱かを決定するでしょう。さらに、A_t = A_t^{\rm grd} + A_t^{\rm prior} という分解は概念的なものであり、非線形な log-softmax の正規化のもとで、アブレーションが各成分を厳密に復元する保証はありません。

なぜこれが重要か

選択的 OPD はこれまで どの信頼度の高いトークンを保持するか に焦点を当ててきましたが、SA-OPD はその問いを どの信頼度の高いトークンが実際に入力に関するものか として再定式化します。入力への根拠性プロキシが汎化するならば、KD がスタイル的な先行分布を能力とともに転移してしまう傾向——推論タスクやマルチモーダルタスクにおける小規模モデルの distillation で繰り返し見られる失敗パターン——に対する原理的な対抗手段を提供することになります。

Source: https://arxiv.org/abs/2608.03632

Distill Where You Fail: Recovering Learning Signals of Negative RL-Groups from Adaptive Teacher Guidance

問題設定

GRPOは、プロンプトごとに G 個のロールアウトからなるグループ内でアドバンテージを A_i = (r_i - \mu_G)/\sigma_G と推定します。すべてのロールアウトが同一の報酬を共有する場合——RLVRの設定では、これは通常すべてが失敗することを意味します(r_j = 0, \forall j \in G)——アドバンテージはゼロに崩壊し、そのプロンプトはgradientに何も寄与しません。このような「負のゼロ分散」グループは、まさにモデルが最も学習を必要としている難しいプロンプトです。より強力な教師モデルからのon-policy distillation(OPD)は密なトークンレベルの教師信号を提供し、自然な補完手段となります。しかし、単純なGRPO+OPDのハイブリッドは純粋なGRPOを下回ります。Figure 1の学習曲線は、GRPO+OPDがMATHにおいてGRPOより低いところで横ばいになっていることを示しています。

MATHにおける学習ダイナミクス

著者らは3つの失敗モードを診断しています:(i) ほとんどのプロンプトはdistillationを必要とせず、OPDを無差別に混合するとRLの探索が希薄化される;(ii) 教師モデルへのfittingを過度に行うと、方策の探索的な分布が崩壊する;(iii) OPDのトークンごとのアドバンテージは非対称であり——ほとんどの位置では \log \pi_T - \log \pi_S が負になるため、大多数のトークンを抑制してしまう。

手法:RSTG

RSTG(Recovering Learning Signals via Adaptive Teacher Guidance)は、GRPOが機能しないチャネルにのみdistillationをルーティングします。このディスパッチはプロンプトに依存しており、報酬の分散があるプロンプトには標準的なGRPOが適用され、負のゼロ分散プロンプトには別個のRSTGブランチが起動します。

RSTGフレームワーク

サンプルレベルの選択と教師の重み付け。 57kのデータセット \mathcal{D} から、学生のmean@8 = 0となるプロンプトを \mathcal{D}_{\text{sw}}(9k)として定義し、さらにその中で教師のmean@8 = 1となるサブセットを \mathcal{D}_{\text{swtr}}(2k)として定義します。各分割に対してOPDを実行した結果(Figure 3)は、設計を動機付けるアブレーションを与えます:\mathcal{D} の3.63%に過ぎない \mathcal{D}_{\text{swtr}} 上のOPDは、全コーパス上のOPDを上回ります。これはオンライン設定において、負のゼロ分散GRPOグループを特定し、教師の習熟度のソフトな代理指標として教師の実績成功率 \omega_i \in [0,1](教師のmean@8)で重み付けすることによって実装されます:

A_{i,t}^{\text{Hybrid}} = \begin{cases} \beta \cdot \omega_i \cdot A_{i,t}^{\text{OPD}}, & \text{if } r_j = 0, \forall j \in G \\ A_{i,t}^{\text{GRPO}}, & \text{otherwise} \end{cases}

分割データ上のOPD

トークンレベルのフィルタリング。 OPDのアドバンテージをすべてのトークンに伝播させるのではなく、学生の高いエントロピー H(\pi_S)(教師信号が最も有益な不確かな決定箇所)または大きな教師・学生間の乖離(方策が教師と異なる位置)のいずれかを満たすトークンにのみgradientを制限します。これは抑制の非対称性に対処します:フィルタリングなしでは、ほとんどのトークンが負のOPDアドバンテージを受け取り、方策が無差別に教師の方向へ収縮してしまいます。

補助的なSFT。 負のゼロ分散プロンプトに対しては、教師が生成した参照completionをSFTターゲットとして追加し、学生が直接模倣できる少なくとも1つの正しい軌跡を与えます。

結果

MATH(AIME24/25、MATH500、OLYMPIAD)とCODE(APPS、MBPP+)における3つの学生→教師ペアについて:

  • Qwen3-1.7B ← Qwen3-4B-Instruct-2507: RSTGはMATH平均55.39、CODE平均67.11に達し、GRPOの51.57/60.03、GRPO+OPDの51.37/64.55、ReLIFTの52.52/60.58を上回ります。AIME24は34.79(GRPO)から42.98へ上昇します。
  • Qwen3-4B ← Qwen3-4B-Instruct-2507: MATH 66.89 / CODE 82.05、対してGRPOは64.94/71.56、ReLIFTは65.05/80.77。AIME25は45.00 → 47.92へ改善します。
  • Qwen2.5-3B ← Qwen2.5-14B: MATH 28.66 / CODE 63.52、対してGRPOは27.41/51.91。

注目すべきことに、単純なGRPO+OPDはGRPOに対して退行することがあります(ペア❷:MATHで63.37 vs. 64.94)、これはFigure 1の学習ダイナミクスの失敗と一致しています。RSTGは3つのペアすべてにおいて総合平均で支配的な結果を示しています。

限界と未解決の問題

この手法は \omega_i を計算するためにプロンプトごとの教師のmean@8推定値を必要とし、これをオンラインで維持するのはコストがかかります。ここでは固定された57kのプールに対して事前計算されているように見受けられますが、これがオープンエンドな領域や検証不可能な領域にどのようにスケールするかは不明です。トークンフィルタの閾値(エントロピーの分位点、乖離のカットオフ)と \beta はハイパーパラメータであり、示されたセクションではその感度が十分に特性化されていません。評価は教師による検証がコストの低い数学とコードに限定されており、決定論的な検証器のない推論タスクへの拡張は未解決のままです。最後に、Qwen2.5-3BにおけるAIMEの向上は絶対値では控えめであり(8.33 / 5.42)、学生が教師から大きく離れている場合にdistillationが基礎的な能力の欠如を補うことはできないことを示唆しています。

なぜこれが重要か

RSTGはGRPOにおけるゼロgradientグループという繰り返し生じる問題に対して明快な処方箋を提供します:すべてのプロンプトにimitation lossを加えるのではなく、RLが機能せず教師が有能である場合にのみ、正確にそこでdistillationを行うというものです。このフレーミング——OPDを並列な目的関数ではなく、負のゼロ分散グループのgradient回復手段として扱う——は、他のハイブリッドRL+SFTレシピに対しても有用な思考モデルです。

Source: https://arxiv.org/abs/2608.00782

Hacker News Signals

Branchless Rust: if文を除去してフィルタを4倍高速化する

Source: https://www.greyblake.com/blog/branchless-rust/

この記事は、具体的なマイクロ最適化の手法を解説しています。ホットなフィルタループ内の条件分岐を、CPUが投機的実行のストールなしに実行できる算術演算で置き換えるというものです。題材となるのは整数スライスのフィルタリングで、素朴な実装では if を使って要素をpushするかどうかを判断します。これはCPUが予測しなければならない分岐を生み出します。ランダムなデータや敵対的なデータでは、誤予測によるペナルティが支配的になります。

branchlessな書き直しは、Rustにおけるbooleanが 0u8 または 1u8 に変換できるという事実を利用しています。核心となるトリックは、述語からマスクを計算し、分岐なしに条件付き書き込みを行うことです。

// Branchless: 常に書き込み、ポインタを条件付きで進める
*out_ptr = val;
out_ptr = out_ptr.add(predicate as usize);

これにより、制御フロー依存性がデータ依存性に変換されます。現代のアウトオブオーダーCPUはこれをはるかに低いペナルティで処理できます。この記事では criterion を用いてベンチマークを行い、分岐予測の精度が約50%となるランダムデータにおいて、スループットが約4倍改善することを示しています。データがソート済みであるなど予測可能な場合は、分岐予測器がほとんどの場合に成功するため、この改善幅は小さくなります。

実装上、いくつかの詳細が重要です。述語の値にかかわらず書き込みは常に行われなければならないため(出力バッファは最悪ケースのサイズに事前確保する必要があります)、この手法ではraw pointerを直接操作するためにunsafe Rustが必要です。記事では、バッファの初期化を回避するために MaybeUninit を使った安全な抽象化についても解説しています。

より広い教訓はCPUパイプラインアーキテクチャに関するものです。現代のx86における分岐誤予測のコストはおよそ15〜20サイクルであるのに対し、データ依存のポインタインクリメントは1サイクルで済みます。4倍のスピードアップは、ランダムデータにおける約50%の誤予測率と適度なループ本体のコストと一致しています。LLVMは単純なケースでは自動ベクトル化やbranchless化を行うことがありますが、特にtrait境界をまたぐ場合などは、コンパイラがその変換が有効であることを常に証明できるわけではありません。この技法はSIMD/HPC界隈ではよく知られていますが、systems Rustでは十分に活用されていません。


なぜエルデシュ問題がAIによって解かれつつあるのか

Source: https://www.quantamagazine.org/why-the-legendary-erdos-problems-are-falling-to-ai-20260803/

本記事は、AI支援またはAI主導の手法によって、エルデシュのオープン問題カタログに収録された組合せ論の問題が解かれた最近の成果を概観しています。特に、数十年にわたって人間の攻略を退けてきた極値グラフ理論と加法的組合せ論の問題が取り上げられています。技術的な内容は、AIの関与における二つのモードを中心に展開されます。

第一に、LLMによる予想の反復的精緻化です。AlphaProofおよびそれに関連するツールのようなシステムが、候補となる構成や界を繰り返し提案し、形式的なチェッカーまたは明示的な計算によってそれらを検証し、その検証シグナルを探索の誘導に利用します。これは、一般的な意味での「推論」というよりも、数学的対象上のモンテカルロ木探索に近いものです。

第二に、より技術的に興味深いのが、大規模なSAT/SMTソルバーと整数計画法の定式化の活用です。これらは以前は計算不可能でしたが、LLMがコンパクトな表現や対称性破壊制約を提案することで実行可能になります。LLMは実質的にヒューリスティックな前処理器として機能し、探索空間を削減してから厳密なソルバーに引き渡すわけです。

言及されている具体的なエルデシュ問題には、cap setに関する界、Ramsey多重度、および稠密な集合における等差数列が含まれます。cap setに関しては、r_3(n)(3項等差数列を含まない \mathbb{Z}_3^n の部分集合の最大サイズ)に対する改良された上界が、自動探索によって部分的に発見されたテンソル法の構成を用いて精密化されました。

本記事は、現在のシステムが自律的に形式的な証明を生成するわけではなく、人間の数学者が出力を検証・形式化していることを丁寧に指摘しています。未解決の問いは、「解かれやすい」エルデシュ問題(有限探索や代数的操作に帰着できるもの)だけが選別されているのではないか、そして真に新規な証明技法を要するより困難な問題は依然として手の届かないところにあるのではないか、という点です。本記事は実証されたことを過大評価しておらず、その点において一読の価値があります。


Zapscape (CVE-2026-64561): KVM/x86におけるゲストからホストへのエスケープ

Source: https://github.com/V4bel/Zapscape

Zapscapeは、x86上のKVMにおけるゲストからホストへのVMエスケープの公開されたexploitです。CVEは2026年に割り当てられており、最近開示された脆弱性であることを示しています。リポジトリにはproof-of-conceptコードと、根本原因を説明するwriteupが含まれています。

この脆弱性は、KVMによるx86の APIC 仮想化パスの処理、具体的にはハードウェアAPIC仮想化(APICv)が有効な場合にKVM/x86が特定のAPICライトexitを処理する方法に存在します。このバグはuse-after-freeまたは不正な状態遷移であり、正確な分類としては、vCPU APICステートマシンにおけるrace conditionです。仮想APIC構造の部分的なteardownの後に割り込みinjectionパスがトリガーされる可能性があり、ハイパーバイザーが攻撃者制御のデータでdereferenceするstaleポインタが残ります。

exploitチェーンには以下が必要です:(1) APICライトとVM exitの精密なタイミングを用いてゲスト内部からraceをトリガーすること、(2) ホストカーネルのheapを整形して解放されたアドレスに攻撃者制御のデータを配置すること、(3) ホストカーネルコンテキストで任意書き込みまたはコード実行を達成すること。ステップ(1)が新規の貢献であり、PoCはraceウィンドウに確実にヒットするために共有メモリページと同期したゲスト側のbusy-loopを使用します。

実際への影響は重大です:影響を受けるカーネルが動作しているKVMベースの共有クラウドインフラ上のテナントは、VMからエスケープできる可能性があります。影響を受けるカーネルバージョンとパッチの状況はリポジトリに記載されています。修正はAPIC teardownパスへの適切なロックの追加と、隣接する状態遷移の監査を含みます。

このクラスのバグ――ハイパーバイザーの割り込み仮想化コードにおけるrace――は、ウィンドウがシンボリックにモデル化することが難しいハードウェアアクセラレーションされたVM exitのタイミングに依存するため、静的解析での発見が非常に困難です。


Qwen3.8-Max: コーディングおよびコラボレーションの新たな基準

Source: https://qwen.ai/blog?id=qwen3.8

Qwen3.8-Maxは、AlibabによるQwen3シリーズの最新リリースであり、同社最強のコーディングおよびエージェント連携モデルとして位置づけられています。ブログでは、Qwen3のMoE設計——トークンごとに活性化されるパラメータ数は少ないものの、総パラメータ数が大きいスパースな mixture-of-experts——を拡張したアーキテクチャについて説明されており、instruction following、マルチターンのツール使用、コード生成に焦点を当てた学習上の改良が加えられています。

「cowork」というフレーミングは、マルチエージェントによるタスク分解を指しています。このモデルは、オーケストレーター(タスクを分解し、専門エージェントにサブタスクを割り当てる役割)としても、サブエージェント(構造化されたツール呼び出しを受け取り、構造化された出力を返す役割)としても動作するよう学習されています。これには、明示的なロールマーカーを持つ合成マルチエージェントトラジェクトリによる学習が必要であり、現在ではフロンティアラボ全体で標準的な手法となっています。

コーディングベンチマークにおいて、Qwen3.8-MaxはHumanEval、MBPP、LiveCodeBench、SWE-bench Verifiedで最先端もしくはそれに近いスコアを報告しています。注目すべき数値はSWE-bench Verifiedであり、ブログでは70%を超える解決率を主張しています。これが再現可能であれば、大きな飛躍を意味します。このモデルはAPIを通じて利用可能ですが、執筆時点ではブログ内で重みの公開は確認されていません。

MoEアーキテクチャにより、同等のベンチマーク性能を持つ密なモデルと比較してトークンあたりの推論コストが低くなっており、これはデプロイメントにとって重要な点です。HNのディスカッションでは、ベンチマークへの過剰適合に対する懐疑的な意見が予想どおり見られ、複数のコメント投稿者がLiveCodeBenchにはデータのカットオフ問題があると指摘しています——より最近に学習されたモデルは、本質的に評価分布をより多く見ていることになります。「Max」というサフィックスは、最大のAPI専用モデルを小規模なオープンウェイトのリリースと区別するQwenの命名規則に従っています。


MistralのShieldstral:マルチモーダルモデレーション向け3Bオープンウェイトモデル

Source: https://mistral.ai/news/shieldstral/

Shieldstralは、テキストおよび画像入力のコンテンツモデレーション分類器として設計された、Mistralによる3Bパラメータのオープンウェイトモデルです。本研究の核心的な貢献は、小規模かつデプロイ可能なパラメータ数とマルチモーダル機能の組み合わせにあります。これまでのオープンなモデレーションモデルの大半は、テキスト専用か、はるかに大規模なものに限られていました。

このモデルは、Mistralのベースモデルから、人間がラベル付けしたモデレーションデータセットと、より大規模なモデルによって生成されフィルタリングされた合成データを組み合わせてfine-tuningされています。分類のタクソノミーは、標準的なハームカテゴリ(CSAM、暴力、ヘイトスピーチ、自傷行為、違法行為)に加え、ツール呼び出しのコンテキストに関連するエージェント固有のカテゴリ(prompt injection、jailbreakの試み、不正なデータ窃取パターン)も網羅しています。

マルチモーダルのパスは、Mistralの既存のVLM研究と整合した vision encoder を通じて画像を処理します。モデレーションに特化した形で、image encoderは、一般的な視覚的理解とは異なる特徴量を必要とする視覚的ハームシグナル(露骨なコンテンツ、暴力)に感応するよう学習されています。このfine-tuningプロセスでは、意味的内容が類似した無害な画像とポリシー違反の画像のペアに対してcontrastive objectiveを用いています。

3Bパラメータという規模により、Shieldstralは単一のコンシューマ向けGPU上で動作可能であり、インラインリクエストフィルタリング(ネットワークのラウンドトリップと競合するレイテンシ)に十分な速度を備えています。Mistralは、内部の評価セットおよびToxicChatやOpenAIのモデレーション評価を含む公開モデレーションベンチマーク上での精度・再現率の数値を報告しています。オープンウェイトでのリリースは注目に値します。なぜなら、本番グレードのマルチモーダルモデレーションシステムの大半はプロプライエタリなAPIエンドポイントとして提供されているからです。

主な制限として、3Bパラメータという規模は境界線上のコンテンツに対する繊細な判断を制約します。つまり、モデルは曖昧なケースにおいて再現率よりも精度を優先するトレードオフを行っています。また、オープンウェイトという性質上、攻撃者がシステマティックに回避手法を探索できるという問題もあります。


DeepSeek V4 Flash をシングル AMD MI300X 上で動かす

Source: https://github.com/ryanzhou/deepseek-v4-flash-mi300x

このリポジトリは、DeepSeek V3/R1 系譜から派生した蒸留・量子化モデルである DeepSeek V4 Flash を、シングル AMD MI300X GPU(192 GB HBM3)上で動作させる手順をまとめたものです。エンジニアリング上の注目点は、DeepSeek のフル MoE モデルはマルチノードクラスタを必要とするのに対し、Flash バリアントは適切な量子化を施すことで 1 枚の GPU のメモリに収まるほどコンパクトである点です。

セットアップでは、CUDA FlashAttention-2 実装からポーティングされたカスタム attention カーネルを用いた ROCm を使用しています。MI300X の HBM3 帯域幅(約 5.3 TB/s)は、大規模量子化モデルのメモリ帯域幅バウンドな推論に適しています。リポジトリには、エキスパート重みの 4-bit および 8-bit GPTQ 量子化の設定が含まれており、トークンあたりのアクティブパラメータ数を合理的な MFU を維持できる範囲に抑えています。

主要な技術的詳細として、DeepSeek V4 の MoE ルーティングはトークンごとに top-K エキスパートを選択し、学習時に補助的な load-balancing loss を用います。シングル GPU での推論では、すべてのエキスパート重みをデバイスメモリ上に同時に保持する必要があり、これが量子化によって解決すべき制約条件となっています。INT4 エキスパート重みと FP16 attention を組み合わせることで、フルモデルは約 160 GB 以内に収まり、KV cache のためのヘッドルームを確保できます。

報告されているスループットは batch size 1 で毎秒 15〜30 トークン程度であり、インタラクティブな推論に実用的な水準です。またリポジトリには、attention カーネルにおける ROCm のパフォーマンスが同等の CUDA 実装に対してこのワークロードで 10〜20% 遅れているという記録も、具体的なプロファイリングトレースとともに含まれています。本リポジトリの価値は、再現可能なシングルノードのレシピにあります。DeepSeek のデプロイメントドキュメントの大半は NVIDIA マルチ GPU 構成を前提としているためです。


Muse Code と Muse Spark 1.2

Source: https://research.meta.ai/blog/introducing-muse-code-and-muse-spark-1-2

Meta AI Research は、Muse Code と Muse Spark のアップデート版(1.2)をリリースしました。両者はいずれもマルチモーダル生成フレームワークの一部として位置づけられています。Muse Spark 1.2 は、従来の画像・動画生成モデルを拡張し、動画における時間的一貫性の向上と、複数オブジェクトが含まれるシーンに対する prompt への追従精度の改善を実現しています。アーキテクチャは、VQVAE コードブックから得られる離散トークン列を対象とした masked generative transformer(MaskGIT スタイル)を維持しており、1.2 アップデートはアーキテクチャ変更ではなく、token prediction head とトレーニングデータのキュレーションに重点を置いています。

Muse Code はより新規性の高いリリースです。これは生のテキストトークンではなく、構造化されたプログラム表現を対象に動作するコード生成モデルです。このモデルは入力コードベースの tree-sitter パース結果を生成の条件として用いることで、生の文字列ではなく AST を対象とした推論を可能にしています。これは構造的な事前知識を用いたコード補完に関する先行研究と類似したアーキテクチャですが、ファイルおよびリポジトリスケールに適用されている点が異なります。

トレーニングの目標関数は、標準的な next-token prediction と、生成されたコードの AST が予測された構造パターンから逸脱した場合にペナルティを与える structural consistency loss を組み合わせています(例えば、文脈から推論されたシグネチャに違反する関数本体を生成する場合など)。これにはパーサーを通じた微分が必要であり、パース木の構造を近似するように学習されたサロゲートモデルによって処理されます。

HumanEval、SWE-bench、および内部のリポジトリレベル補完評価におけるベンチマーク結果は、従来の Muse バージョンからの改善を示しています。HN のディスカッションでは、HumanEval(独立した関数)と実際のリポジトリレベルのタスクとのギャップについて疑問が提起されています。構造的な条件付けが後者の設定で最も効果を発揮することを考えると、これは正当な懸念といえます。重みと推論コードは公開されておらず、このブログは研究発表となっています。


「クリーン」なコード、ひどいパフォーマンス(2023年)

Source: https://www.computerenhance.com/p/clean-code-horrible-performance

Casey Muratoriのエッセイ(2023年発表、再び話題に)は、いくつかの典型的な「クリーンコード」リファクタリングパターンをベンチマークし、その実行時コストを定量化しています。核心的な主張は哲学的なものではなく実証的なものです。すなわち、クリーンコードの教育において推奨されるOOPイディオム——仮想ディスパッチ階層、過剰な抽象化レイヤー、細かいメソッド——は、ホットパスにおいて累積する計測可能なオーバーヘッドをもたらすというものです。

ベンチマークでは、ポリモーフィズムと仮想メソッドディスパッチを用いた「クリーン」な図形描画実装と、タグ付きユニオンを操作するswitch文バージョンとを比較しています。仮想ディスパッチ版はワークロードに応じておよそ5〜10倍遅くなります。主な原因は、仮想呼び出しがインライン化を妨げ、CPUの分岐ターゲット予測器を無効化する間接分岐を導入するためです。ランダムなディスパッチシーケンス(最悪ケース)では、間接分岐における誤予測率はほぼ100%に達します。

データレイアウトに関する議論も同様に重要です。「クリーン」版は図形オブジェクトをvtableポインタを持つ個別にヒープアロケートされたオブジェクトとして格納するため、本来連続した配列にできるものを断片化させます。これはキャッシュ局所性を破壊します——異種混在のvector<Shape*>上のタイトなループはほぼランダムなアクセスパターンを持つポインタチェイスを引き起こしますが、struct-of-arraysレイアウトでの反復処理とは対照的です。

Muratoriの処方箋は「決して抽象化するな」ではなく、「CPUが実際に何を実行するかを意識せよ」というものです。フラットなタグ付き構造体の配列を用いたSIMDフレンドリーな書き直しは、明示的なベクトル化によって同じワークロードをおよそ 1/10 の時間で処理します。このエッセイの価値は、示された具体的なアセンブリ出力とプロファイラのトレースにあります——主張そのものはパフォーマンスエンジニアリングの分野ではよく知られていますが、定期的に再提起する必要があるようです。HNのコメントスレッドでは、この例が実際のコードベースを代表するものかどうかについての議論が必ず起きますが、それこそがこのエッセイが十分に答えていない興味深い問いです。

注目の新しいリポジトリ

Kritt-ai/open-kritt

コードベース内の表面的なlint警告ではなく、実際に悪用可能な脆弱性を発見するためにAIエージェントをオーケストレーションする、エージェント型セキュリティ解析フレームワークです。本システムは脆弱性発見を専門化されたサブエージェントに分解し、それぞれがレコナサンス、テイント解析、データフロートレース、およびエクスプロイト仮説生成を担当します。そして各エージェントの出力を統合し、再現手順を含む実用的な調査結果を生成します。このアーキテクチャは、静的解析ツール(偽陽性率が高いという問題を抱える)と手動ペネトレーションテスト(スケールしない)の間に存在するギャップを埋めることを目的としています。内部ではコードプロパティグラフを構築し、コンテキストウィンドウ化されたスライスを各エージェントに提供することで、個々のプロンプトを管理可能なトークン予算内に収めつつ、グローバルな状態を維持します。出力はCWE分類、影響を受けるコードパス、および修正案を含む脆弱性レポートとして構造化されます。本プロジェクトはまだ初期段階ですが、既に複数の言語をサポートし、一般的なCIパイプラインとの統合も実現しています。主なユーザーとしては、大規模なコードベースの第一次トリアージを自動化したいセキュリティエンジニアや、手動レビューを補完したいレッドチームが想定されます。全エージェント設計により、発見品質はモデルの能力に応じてスケールするため、新しいフロンティアモデルが登場した際にも容易に差し替えることができます。

Source: https://github.com/Kritt-ai/open-kritt


vshulcz/deja-vu

コーディングエージェントセッションにおけるコールドスタート問題に取り組んでいます。エージェントはセッションをまたいだ永続的なメモリを持たないため、同じサブ問題を繰り返し解いてしまうという課題があります。deja-vuは、17種類の一般的なエージェントハーネス(Cursor、Aider、Claude Codeなど)がディスクに書き出したセッション履歴を、それらのセッションが実行された時点でインストールされていなかった場合も含めて遡及的にインデックス化します。セッション開始時には、過去の関連する解決策を自動的に取得します。検索メカニズムは純粋に字句的・構造的なものであり、embeddingもLLMの呼び出しも使用しないため、システム全体が依存関係ゼロで完全にローカルで動作します。ベンチマーク結果はLongMemEval-SでのhitRate@1が84.9%であり、embedding ベースのアプローチと競争力があり、運用コストはその何分の一にも抑えられています。インデックスは単一のゼロ依存バイナリを用いて生のセッションファイルから構築されるため、デプロイは極めて簡単です。バイナリをコピーして実行するだけで完了です。embedding APIの呼び出しが許容されないエアギャップ環境やプライバシーに敏感な環境でエージェントを運用しているチームにとって、現状このスペースで唯一の実用的な選択肢です。検索アルゴリズムはn-gramおよびトークンオーバーラップのヒューリスティックと、セッション形式の軽量な構造解析を組み合わせているようです。LLM不使用という制約により、実装が乱雑で非構造的なエージェント出力に対してもロバストである必要があります。

Source: https://github.com/vshulcz/deja-vu


MemTensor/memmy-agent

複数の並行するAIコーディングエージェントのための共有メモリ基盤です。中心的な問題として、Claude Code、Codex、およびそれに類するツールはそれぞれ独立したコンテキストウィンドウを維持するため、同じコードベース上で複数のエージェントを実行すると、不整合・冗長・矛盾した状態が生じます。memmy-agentは、すべてのエージェントが統一されたインターフェースを通じて読み書きするローカルメモリハブとして機能し、ユーザー情報・プロジェクトの状態・過去の意思決定に関する同一の永続的表現をすべてのエージェントに提供します。アーキテクチャは、エピソード記憶(セッションのトランスクリプト)、セマンティック記憶(抽出されたファクトと嗜好)、ワーキングメモリ(現在のタスク状態)を分離し、複数のエージェントが同時に更新する際のマージコンフリクトを処理します。すべてはローカルで実行されるため、ユーザーのコンテキストが外部に送信されることはありません。実装はサポートされている環境ではMCP(Model Context Protocol)標準を対象とし、ネイティブなMCPサポートを持たないエージェント向けにはフォールバックアダプターを提供します。これは、エージェント間の一貫性が重要なマルチエージェントワークフロー――例えば、一方のエージェントがテストを書きながら、もう一方が実装をリファクタリングするケースなど――を運用するすべての人に関連します。現時点での主な未解決問題は、2つのエージェントがプロジェクトの状態について矛盾する認識を形成した場合のコンフリクト解決ポリシーであり、現在のアプローチは差分ログを伴うlast-write-winsです。

Source: https://github.com/MemTensor/memmy-agent


aws-samples/sample-specship

Kiro Power(AWSのエージェント拡張フォーマット)としてパッケージ化された、構造化された自律型エンジニアリングワークフローです。このパイプラインは5つのフェーズを順番に実行するよう設計されています:recon(要件と既存コードベースの解析)、plan(明示的な契約を伴うタスク分解の生成)、build(実装の生成)、validate(敵対的な自己批評とテスト実行)、ship(出力前の最終品質ゲート)。TDDとの統合により、build フェーズでは実装の前にテストを生成し、テストがパスするまで反復します。敵対的な validation ステップでは、出力に対して独立した批評エージェントを実行し、スロップパターン(ハルシネーションによるAPIコール、文脈に合わないコピペのボイラープレート、spec のドリフト)を特定して探します。品質ゲートは、モデル自身が主観的に判断するのではなく、プログラム的にチェックされる構造化された述語として定義されています。これが本設計において重要な選択です——モデルが悪い出力を受け入れ可能だと自ら納得してしまう度合いを制限するためです。spec 駆動のフレーミングにより、ワークフロー全体が正式な要件ドキュメントに紐付けられ、長期的なエージェントが当初の意図からドリフトしやすい傾向を抑制します。単一プロンプトのアプローチではなく原則に基づいた構造を求める、社内エージェントパイプラインを構築するチームにとって、リファレンスアーキテクチャとして有用です。

Source: https://github.com/aws-samples/sample-specship


arcships/aimux

Rustで書かれた統合LLMアクセスレイヤーで、325のAIプロバイダーにわたって単一のAPIサーフェスを公開します。その価値提案は運用面にあります。コストルーティング、フォールバック、または機能選択のために複数のプロバイダーを呼び出すプロダクションシステムでは、現状では互換性のないリクエスト/レスポンススキーマを持つプロバイダーごとのSDK統合が必要です。aimuxはこれらを単一のインターフェースに正規化し、変換レイヤーを内部で処理します。Rustで書かれていることにより、サイドカープロセスなしに低レイテンシルーティングが必要なシステムへ直接組み込むことができ、APIキーの処理や大規模なレスポンスストリーミングにおいてメモリ安全性の保証が重要な意味を持ちます。この抽象化は、tool calling、streaming、vision inputs、構造化出力フォーマットといったプロバイダー固有の機能をカバーし、対象プロバイダーが特定の機能を持たない場合はgraceful degradationを行いながら統一スキーマへマッピングします。レイテンシ、コスト、またはモデル固有の強みに基づいてトラフィックをルーティングするLLM非依存なインフラを構築するチームにとって、これは統合に必要な表面積を大幅に削減します。325プロバイダー対応という数字は見出しになるものですが、実際にはより重要なのが、streaming処理やエラーコードにおけるエッジケースを正規化レイヤーが一貫して扱えるかどうかであり、これは関心のある特定のプロバイダーに対して実装を精査することで確認する必要があります。

Source: https://github.com/arcships/aimux


arcships/light-ocr

PP-OCRv6(PaddleOCRの最新世代の検出・認識パイプライン)をベースに構築されたNode.jsおよびC++向けのオフラインOCRで、ハードウェアアクセラレーションbackendとしてApple Silicon向けのCore MLとクロスプラットフォームGPU推論向けのWebGPUをサポートしています。出力にはバウンディングボックス座標、認識テキスト、および領域ごとの confidence scoreが含まれており、単なるブラックボックス型テキスト抽出器としてではなく、ドキュメント処理パイプラインのコンポーネントとして利用するのに適しています。クラウドOCR APIとの主な差別化ポイントは完全オフライン動作であり、呼び出しごとのコストなし、データ外部送信なし、決定論的なレイテンシを実現しています。@arcships/light-ocr としてNode.jsパッケージ化されているため、PythonサブプロセスブリッジなしにJS/TSのサーバーサイドツールに直接統合でき、Node.jsのみのインフラを持つチームにとって重要な利点となります。Core ML backendはアーキテクチャ的に興味深い点があります——PP-OCRv6は二段階パイプライン(DBNetスタイルのセグメンテーションによるテキスト検出、次いでCRNNによる認識)であり、それをCore MLのグラフ形式にマッピングするにはパイプラインをステージ境界で分割する必要があります。WebGPUサポートにより、LinuxおよびWindowsのGPUターゲットへのハードウェアアクセラレーションが拡張されています。ドキュメントの取り込み、スクリーンショットの解析、およびプライバシーに敏感な環境やレイテンシが制約された環境で画像を処理するあらゆるパイプラインに有用です。

Source: https://github.com/arcships/light-ocr


hahhforest/pi-textbook

中国語による実践的な教科書「Hands-on Learning Pi」は、読者がDeepSeek-R1に代表されるPiスタイルのエージェント(reasoning-and-actingループ)をゼロから構築する過程を、15の明確なチェックポイントに沿って案内します。各チェックポイントはシステムの具体的かつ実行可能な状態に対応しており、読者は最終段階だけでなく各段階において、動作する成果物を通じて自身の理解を検証できます。カリキュラムはフルスタックをカバーしており、tokenization、pretraining objectives、推論のためのRLHF/RLAIF fine-tuning、ツール使用の統合、そしてエージェントループ自体が含まれます。Piスタイルのフレームワークは特に、chain-of-thought推論とアクション実行のインターリービングを対象としており、これはバニラな instruction-following とは機構的に異なり、学習時に推論トークンがどのように生成され、マスクされるかを明示的に扱う必要があります。KarpathyのnanoGPTやHugging Faceコースといった英語主体のリソースではエージェント固有の内容が不十分と感じる中国語話者のMLプラクティショナーにとって、本書は実質的な空白を埋めるものです。チェックポイント構造により、コースのスキャフォールドとしても活用できます。短期間で743スターを獲得したことは、この言語においてこうした体系的で構築可能なカリキュラムへの真の需要があることを示しています。

Source: https://github.com/hahhforest/pi-textbook


haoran-zha/Awesome-Spiking-Neural-Networks-Hub

スパイキングニューラルネットワーク(SNN)に関する340本以上の論文をトピック別に整理した、厳選されたバイリンガル(英語および中国語)リファレンスハブです。ニューロモーフィックハードウェアプラットフォーム(Intel Loihi、BrainScaleS、SpiNNaker)、データセット、シミュレーションフレームワーク(NEST、Brian2、SpikingJelly)、および活発な研究グループへのリンクも掲載されています。既存のSNN awesome-listとの差別化要素はバイリンガルによる構成にあり、これにより相当規模の中国語圏ニューロモーフィック研究コミュニティへのアクセシビリティを確保しつつ、英語を主言語とする読者にとっても利用しやすい構成となっています。また、互いの文献検索では表面化しにくい両コミュニティの研究成果を相互参照している点も特徴です。カバレッジはSNN研究の主要な技術的軸をまたいでおり、surrogate gradient training手法(STBPおよびその派生手法)、レート符号化対時間符号化、ANNからの変換、ハードウェアを意識したネットワーク設計、低消費電力推論への応用が含まれます。イベントカメラ処理やエッジ推論といった特定の応用分野でこの分野に参入・調査しようとしている方にとって、構造化された有用な出発点となります。ニューロモーフィックプラットフォームのドキュメントは分散していることが多いため、ハードウェアセクションは特に価値が高く、このハブはデプロイメントに関連する制約情報をアルゴリズム文献とともに集約しています。

Source: https://github.com/haoran-zha/Awesome-Spiking-Neural-Networks-Hub