デイリーAIダイジェスト — 2026-07-01
arXiv ハイライト
Orca: The World is in Your Mind
Orcaは「世界基盤モデル（world foundation model）」を提案しており、学習済み潜在空間における次状態予測（next-state prediction）という単一の目的のもとで、理解・予測・行動を統合します。次トークン（LLMs）、次フレーム（video models）、次行動（policies）の予測にそれぞれコミットするのではなく、Orcaはこれらすべてを状態遷移をモデル化する共有潜在空間からの読み出し（readout）として扱います。提案の核心はアーキテクチャにあります：事前学習後にバックボーンを凍結し、テキスト・画像・行動に対してそれぞれ軽量なモダリティ固有のdecoderを接続するというものです。
定式化
マルチモーダル信号 \mathcal{X}=\{X^m\}_{m\in\mathcal{M}} が与えられたとき、encoderは潜在状態 \mathcal{S}=f_\theta(\mathcal{X}) を生成します。状態の発展は、暗黙的ダイナミクス z_t（物理法則、物体の性質、シーン内の力）と明示的条件 c_t（指示、イベント）のもとで双方向にモデル化されます：
S_{t+\Delta}\sim p_\Theta(S_{t+\Delta}\mid S_t, z_t, c_t),\quad \Delta\in\mathbb{Z}_{\neq 0}.
\Delta>0（順方向予測）と \Delta<0（逆方向追跡）の両方がサポートされています。この双方向の定式化は珍しいものです——ほとんどのworld modelは順方向のみで学習します——が、おそらくmasked/denoisingの目的関数と同じ理由に基づいています：対称的な予測は、状態からダイナミクスを分離するためのより強いシグナルとなります。
2つの学習パラダイム
Orcaは事前学習を無意識的（unconscious）学習と意識的（conscious）学習に分割します。これは、密でラベルなしのダイナミクス（動画）と、疎で言語ラベル付きのダイナミクス（イベント、VQA）との区別に対応しています。
具体的には、VLMバックボーンは <visual token>, <Query 1>, <Instruction>, <Query 2> という形式のトークン列を入力として受け取ります。ここで <Query 1> と <Query 2> はスクラッチから学習される学習可能なクエリベクトルです。3つの目的関数が積み重ねられています：
観測のみの状態遷移（無意識的）。 フレームembedding v_t とクエリ q_1 が与えられたとき、q_1 の最終層の隠れ状態が2層MLPを経て \hat{v}^l_{t+1} を予測します。教師信号 v^l_{t+1} は凍結された vision encoder から得られます。連続的な動画が、運動・遮蔽・物体間相互作用に対する密な監督を提供します。
イベント条件付き状態遷移（意識的）。 v_t、q_1、イベント記述 e_{t+\Delta}、および q_2 が与えられたとき、q_2 の最終層の隠れ状態が2層MLPを経て \hat{v}^l_{t+\Delta} を予測します。e_{t+\Delta} はタスクの意図、記述、または因果的前提となり得ます。
VQA応答生成。 LM headを用いて (V, l_q) を条件とした l_a に対する標準的な次トークンloss。
目的関数（1）と（2）はピクセル空間ではなく、凍結された vision encoder の潜在空間で教師あり学習されます。これが鍵となるモデリング上の判断です：ピクセルを予測する代わりに意味的embeddingを予測することで、lossが高周波再構成に計算量を費やすことを回避し、代わりに状態レベルの構造に集中します。これは本質的に、言語条件付きブランチを追加したJEPAスタイルの潜在予測です。
データとスケール
事前学習には125K時間の動画と1億6000万件のイベントアノテーション、およびVQAデータが使用されます。動画は目的関数（1）を、動画＋イベントは（2）を、VQAは（3）をそれぞれサポートします。
スケーリング挙動
本論文の中心的な実験的主張は、データ量およびモデルサイズの増加とともに複合lossがなめらかに減少するというものです。0.8Bおよび4Bパラメータのモデルにおいて、3つの目的関数の合計である総loss（論文中の式2）は動画時間数のスケールアップに伴い単調に減少し、4Bのカーブは学習全体を通じて0.8Bのカーブを厳密に下回っています。プラトーは報告されておらず——著者らはOrcaが「急速には収束しない」とし、より多くのデータから継続的に恩恵を受けることを強調しています。これはクリーンなスケーリング則（提供されている抜粋では指数は fitting されていません）よりも弱い主張ですが、定性的な形状は基盤モデルのレシピとして望ましいものです。
下流タスクの評価プロトコルではバックボーンを凍結し、モダリティ固有のdecoderのみ（テキスト、画像、行動）を学習します。これは潜在表現が真に汎用的であるかを検証する正しいテストです：凍結した特徴量が転移するならばworld-latent仮説は支持され、そうでなければ能力の大部分はタスク固有のheadに宿ることになります。抜粋では問い（Q1.1：有効性・スケーリング、Q1.2：潜在品質→下流性能）が設定され、Q1.1には肯定的な答えが与えられていますが、3つの読み出しに関する具体的な下流数値は、本稿で提供されているセクションには含まれていません。
限界と未解決の問い
いくつかの懸念点を指摘しておく価値があります。第一に、潜在空間の予測ターゲットは凍結された vision encoder によって定義されており、Orcaが表現できる上限はそのencoderの帰納バイアスによって制約されます——したがって、そのencoderには見えないダイナミクス（細粒度の物理現象、サブピクセルの動き）は復元できません。第二に、「無意識的/意識的」というフレーミングは示唆的ですが、メカニズム上の違いは言語トークンを条件とするかどうかに還元されており、生物学的アナロジーはほとんど付加価値をもたらしません。第三に、abstractにはビジョン/言語以外のモダリティ（音声、力、赤外線）が列挙されているものの、この実装には含まれておらず、ここでの「世界」は動画＋テキストに過ぎません。第四に、下流結果に関する論文自体の記述は提供されているセクションでは切り捨てられており、標準ベンチマーク（embodied actionの成功率、画像予測のFID/LPIPS、テキスト生成品質）における数値に照らした凍結バックボーン主張の強さは今後の判断を待つ必要があります。最後に、双方向の \Delta<0 目的関数は記述されていますが、その貢献は示されているアブレーションでは検証されていません。
なぜ重要か
潜在空間における次状態予測が、共有凍結バックボーンによって次トークン・次フレーム・次行動の予測を真に包含するならば、3つのモデルファミリーが一つに集約され、マルチモーダル事前学習の枠組みが再構成から動力学へとシフトします。スケーリングカーブは、これが単なるスローガン以上であることを示す最初の証拠です；凍結された潜在表現が専門モデルのお膝元で競合できるかどうかが、決定的な問いとなります。
Source: https://arxiv.org/abs/2606.30534
Dockerless: コーディングエージェントのための環境不要プログラム検証器
問題
SWE-bench スタイルのタスクにおけるコーディングエージェントの post-training は、SFT トラジェクトリのフィルタリングと RL 報酬の計算という2つの時点でプログラム検証器に依存しています。事実上の標準となっている検証器は実行ベースであり、ピン留めされた依存関係を持つリポジトリ固有の Docker イメージ E_x の中でホールドアウトされた unit テストを実行します：
r_{\text{env}}(x,y) = \mathbb{1}[\text{tests in } E_x \text{ pass under } y].
すべてのリポジトリに対して E_x を構築することが、SWE 学習データのスケールアップにおける支配的なコストとなっています。実世界の多くのリポジトリでは再現可能な環境や利用可能なテストスイートが存在しないため、環境ベースの手法はキュレーションされたベンチマークを超えて容易にスケールできません。ロールアウト側はすでにほぼ解決されており、著者らは OpenHands 上のフロンティアエージェントがリポジトリごとの環境を取り除いた場合でも resolve-rate の低下がわずか 3.0〜13.9 ポイントに留まることを示しています。ボトルネックは検証にあります。既存の LLM スコアラーは Docker を回避していますが、リポジトリを検査せずに差分テキストや issue テキストといった表面的な特徴からパッチを評価するため、性能が大幅に劣ります。
手法
Dockerless は、エージェント的かつ非実行型の検証器 r_\phi(x,y)\in[0,1] であり、コードベースを積極的に読み込むことで、issue x と参照パッチ y_{\text{ref}} に対して候補パッチ y を評価します。
アーキテクチャは2段階の分解から構成されます：
- 質問生成と探索。 (x, y_{\text{ref}}, y) を条件として、検証器はまず K 個の検証質問を提案します。これらの質問は、正しいパッチと一見もっともらしい誤ったパッチを区別できる挙動を対象としています（例：「パッチは
foo.py内で参照パッチが修正している空入力分岐を処理しているか？」）。並列サブエージェントがそれぞれ1つの質問を担当し、リポジトリを探索して——ファイルの読み込み、呼び出し元のトレース、関連テストの検査——証拠に基づく回答を返します。 - 判定。 最終ジャッジが x、y_{\text{ref}}、y、および K 個の質問・回答ペアを条件として正誤の判定を出力します。
学習は ground-truth の環境ベースラベルに対する rejection sampling を用いた distillation で行われます。教師モデルが完全な質問・回答・判定のトラジェクトリを生成し、予測された判定が ground-truth の合否ラベルと一致するトラジェクトリのみが保持され、ベースモデルはこれらのフィルタリングされたトラジェクトリで SFT されます。
特筆すべき点として、検証器自体は環境不要な体制で動作します——サブエージェントはピン留めされた依存関係や動作するテストランナーを必要とせず、最小限のベースイメージ上で実行されます。これにより、post-training パイプライン全体（SFT フィルタリング + RL 報酬）を Docker 不要にすることが可能になります。
結果
検証器の品質は、バランスの取れた776サンプルのトラジェクトリベンチマーク（SWE-bench Verified から500件、Multi-SWE-bench Flash から276件）で評価されています。Dockerless は最も強力なオープンソース検証器を AUC で14.3ポイント上回っています。
Qwen3.5-9B を起点とした完全な post-training パイプラインに組み込んだ結果、Dockerless-RL-9B は以下を達成しています：
- SWE-bench Verified: 62.0%（ベースから +2.4）
- SWE-bench Multilingual: 50.0%（+8.7）
- SWE-bench Pro: 35.2%（+2.9）
次点のオープンソース SWE スペシャリストである SWE-Lego-8B（41.2 / 19.0 / 16.1）と比較すると、それぞれ +20.8、+31.0、+19.1 ポイントの改善です。従来の7Bスペシャリスト（SWE-Gym-7B、SWE-Dev-7B）は11.4 / 3.0 / 3.3 および 10.6 / 4.2 / 4.0 と大幅に下回っています。
Table 1 における制御比較が特に興味深い点です：
- SFT ソース。 Env-SFT-9B（環境検証済みロールアウトで SFT）は 60.0 / 48.3 / 33.9 に達し、Dockerless-SFT-9B（Dockerless 検証済みロールアウトで SFT）は 60.6 / 47.7 / 35.3 に達しています。環境不要なフィルタリングは環境ベースのフィルタリングに匹敵しています。
- RL 報酬ソース。 Dockerless-SFT-9B を開始ポリシーとして、DeepSWE-Verifier を報酬として使用した場合は 60.6 / 47.3 / 34.1 となり、RL による改善が見られません。テスト実行を報酬として使用した場合は 62.4 / 51.3 / 35.7 となります。Dockerless を報酬として使用した場合は 62.0 / 50.0 / 35.2 となり、実行ベースの上限から 0.4〜1.3 ポイント以内に収まり、代替の環境不要報酬よりも大幅に優れています。
つまり、エンドツーエンドの環境不要パイプラインは、SFT と RL の両段階において、リポジトリごとの Docker 検証が提供する利益のほぼすべてを回復できています。
制限事項と未解決の問題
- 検証器は ground-truth の環境ベースラベルに対する rejection sampling による distillation で学習されるため、最初の Dockerless モデルのブートストラップには依然として環境ベースのラベル付きコーパスが必要です。環境不要なスケーリングがダウンストリームに適用されるという主張であり、Docker が完全に不要になるという主張ではありません。
- 最終エージェントの評価は SWE-bench 上の環境ベーススコアリングを使用しており、参照パッチ y_{\text{ref}} が存在しない非ベンチマークリポジトリにおける検証器の残存エラーモードは直接測定されていません——また、説明されている手法は検証時に y_{\text{ref}} を消費するため、gold パッチが存在する設定への適用性が制限されます。
- Test-Execution RL は3つのベンチマーク全てで依然として Dockerless RL を上回っています（62.4 / 51.3 / 35.7 対 62.0 / 50.0 / 35.2）。差は小さいですが一貫しています。
- コスト計算：候補パッチごとに K 個の並列サブエージェントによるエージェント的探索は無料ではありません。論文のフレーミングでは、このコストはリポジトリごとの Docker セットアップと比べて有利なトレードオフであるとされていますが、具体的な検証器の計算コストはここでは明示されていません。
重要性
検証が——ロールアウトではなく——Docker を構造的に必要とする SWE post-training の最後のピースであるとすれば、それを取り除くことで、再現可能な環境を持たない実世界リポジトリの長いテールに対してコーディングエージェントを学習させる道が開かれます。Dockerless は、そうすることによる損失が実行ベースの報酬と比べて resolve-rate で約1ポイント未満であることを示しており、桁違いに多くの学習データを得るためには十分に価値のあるトレードオフと言えるでしょう。
Source: https://arxiv.org/abs/2606.28436
GEAR: Guided End-to-End AutoRegression for Image Synthesis
問題設定
二段階の視覚生成 — VQトークナイザーを再構成のために学習し、それを固定した上でその索引に対してautoregressive (AR) transformerを適合させる — は、トークナイザーの索引分布がcausalにモデル化しやすいという暗黙の仮定を置いています。しかし実際にはそうではありません。トークナイザーはピクセル忠実度とコードブック利用率のみを目的として最適化されており、どの索引シーケンスがnext-token prediction (NTP)の下で学習可能かという信号は一切与えられていません。\arg\min代入に対するstraight-through estimator (STE)を用いてこのループを閉じようとすると崩壊してしまいます。GEARは、安定した勾配経路を用いてトークナイザーとARをend-to-endで共同学習し、さらにDINOv2特徴への表現アライメント（REPA）によって誘導することでこの問題に対処します。
手法
VQトークナイザーは標準的なものです。エンコーダ \mathcal{E} が \mathbf{x}\in\mathbb{R}^{H\times W\times 3} を \mathbf{Z}\in\mathbb{R}^{N\times d} に写像し、コードブック \mathcal{C}=\{\mathbf{c}_k\}_{k=1}^K に対して
q_i = \arg\min_k \lVert \mathbf{z}_i - \mathbf{c}_k \rVert_2^2, \quad \hat{\mathbf{z}}_i = \mathbf{c}_{q_i},
と量子化され、複合lossは
\mathcal{L}_{\mathrm{VQ}} = \mathcal{L}_{\mathrm{rec}} + 0.1\mathcal{L}_{\mathrm{LPIPS}} + 0.1\mathcal{L}_{\mathrm{GAN}} + 0.05\mathcal{L}_{\mathrm{ent}} + 0.25\mathcal{L}_{\mathrm{commit}}
となります。ARは独自のembeddingテーブル \mathbf{E}\in\mathbb{R}^{K\times d}（\mathcal{C}とは結合されていない）を持ち、索引 q_i を入力として p_\theta(q_i \mid \mathbf{q}_{<i}, c) を予測します。
核心となるメカニズムはコードブック代入のデュアル読み出しです（Figure 2c）。各位置において、GEARは \arg\min からハードなone-hot代入 \mathbf{a}^{\text{hard}}_i \in \{0,1\}^K と、温度スケーリングされたソフト代入
\mathbf{a}^{\text{soft}}_i = \mathrm{softmax}\!\left(-\lVert \mathbf{z}_i - \mathbf{c}_k \rVert_2^2 / \tau\right), \quad \tau = 0.1
の両方を形成します。ハード分岐はNTPと、ARのみを更新する「ハード」REPA loss（トークナイザーはstop-grad）を駆動します。ソフト分岐はARの上位causalブロックを迂回し、トークナイザーのみを更新するために逆伝播する微分可能なREPA lossを持ちます。
具体的には、ソフトREPA lossからの勾配はソフト代入行列を通じて \mathcal{E} と \mathcal{C} に到達できますが、ARパラメータを決して変更しないようにゲートされており、また \arg\min を通じた微分不可能なNTP勾配がトークナイザーに流れ込もうとすることもありません。ナイーブなSTEによるend-to-endアプローチはまさにこれを行うため崩壊してしまいます。このクリーンな分割によって、ARはトークナイザーの索引分布を自身が予測しやすいものへと誘導し、一方でトークナイザー自身の表現アライメント負担は減少します。すなわち、トークナイザーの特徴はDINOv2らしさが薄れ、ARの内部特徴がよりDINOv2らしくなるという、diffusion側のREPAレシピを逆転させた現象が生じます。
学習は二つのレジームで行われます。アブレーション実験ではトークナイザーとARを共同でfine-tuningします。メインテーブルの比較では、GEARは共同フェーズを400kステップ実行し、その後得られたトークナイザーを固定して、LlamaGen-REPAが固定ウォームアップトークナイザーに使用するのと同一のbudgetで新たなARを学習します。LlamaGen-REPAとGEARの間のギャップは、トークナイザーの寄与を分離することになります。
結果
ImageNet-1K 256×256クラス条件付き生成において、GEARの改善されたトークナイザーは標準的な固定トークナイザーパイプラインに転移でき、LlamaGen-REPAのARbudgetと同等の条件で比較されています。トークナイザーの変化はコードブック統計に現れています。共同fine-tuningの過程で、top-1およびtop-10の累積代入マスが増加し、利用エントロピー H がnats単位で低下し、有効コードブックサイズ \exp(H) が縮小します。すなわち、分布が高い有用性を持つコードの小さな集合へと鋭く集中していきます。
効率面の恩恵は、1億枚規模のGPICコーパスでの学習ダイナミクスに最もよく現れています。LlamaGen-REPAとGEARはエンコーダ、ARアーキテクチャ、1エポック（390kステップ）のbudgetを共有し、固定トークナイザーのみが異なります。
ベースラインの最終NTP lossに達するまでの速さはGEARが 2.5\times 速く、最終REPAアライメントlossに達するまでの速さは 11.1\times 速くなっています。この非対称性はメカニズムと一致しています。GEARはアライメントコストの一部をトークナイザー内部で事前に支払っているため、ARはDINOv2へのアライメントに使う容量が減り、NTPにより多くを費やすことができます。評価にはImageNetに対して50k ADMサンプルによるgFID/sFID/IS/Precision/Recall、GPICに対してFD-DINOv2、Precision、Recall、Density、Coverage、MMD、さらにtext-to-imageタスクではGenEval、DPG-Bench、COCO CLIP/FIDを使用しています。
限界と未解決の問題
- 最大規模での完全な共同学習は実施されていません。報告されている性能向上は事後的に固定されたトークナイザーを介して転移されるものであり、end-to-endコストを回避していますが、より長い共同スケジュールによって性能向上が累積するかどうかは未解決のままです。
- 本手法はDINOv2アライメントターゲットに依存しており、表現事前学習の選択（自己教師あり vs. 教師あり、ViT vs. ConvNet）に対する感度は、提供されている記述の範囲では特性評価されていません。
- 温度 \tau=0.1 がsoftmax読み出しを制御しており、ソフト代入はARが実際に消費するハード索引と一致するようにトークナイザーの誘導信号が十分に鋭くなければなりません。\tau に関する安定性の包絡線、およびコードブックエントロピー重み（0.05）との相互作用は十分に解明されていません。
- コードブック利用の集中（Figure 4）は有効語彙サイズを縮小させますが、これが高解像度における再構成品質の上限とトレードオフになるかどうかは不明です。
- このメカニズムは原理的には任意の離散索引生成器（masked、hybrid）に一般化できますが、本論文ではcausal ARにのみ実装されています。
重要性
GEARはハードとソフトの代入パスを分割することで、微分不可能な量子化ボトルネックを越えたend-to-end学習のクリーンなレシピを提供し、ARの画像モデルにおいて表現アライメント事前情報はジェネレーターではなくトークナイザーに投入すべきであることを経験的に示しています。得られたトークナイザーはドロップインで利用可能なアーティファクトであり、同一budgetの下でdownstreamのAR学習を 2.5–11\times 高速化します。これはこの技術を採用しやすくするデカップリングの一形態です。
Source: https://arxiv.org/abs/2606.32039
Evolution Fine-Tuning: 371個の最適化タスクにわたる発見の学習
問題設定
LLMを活用した進化的探索（FunSearch、AlphaEvolve、OpenEvolve）は、未解決の数学的問題、GPUカーネル設計、組み合わせ最適化において最先端の結果を生み出してきました。これらのシステムでは、モデルは凍結された突然変異オペレータであり、スキャフォールドが探索ロジック——どの親を選択するか、どの領域を突然変異させるか、いつバックトラックするか——を管理しています。新しいタスクのたびにゼロから再出発し、探索中に構築された推論はランの終了とともに破棄されます。著者らは、突然変異ポリシー自体——いかに解を進化させるかを知ること——をモデルの重みに組み込めるかどうか、またそのようなポリシーが異種の最適化ドメイン間で転移できるかどうかを問います。
手法
Evolution Fine-Tuning（EFT）は、進化的軌跡に対する教師あり中間学習です。パイプライン（図4）は以下のとおりです：
- タスク仕様、初期候補解、評価器、および設定ファイルをそれぞれ持つ371個のシード最適化タスクを収集します。
- OpenEvolveを実行して親から子への遷移を生成します。各遷移はプロンプト、親コード、生成された子、評価器の出力、スコア変化 \Delta s = s(\text{child}) - s(\text{parent})、および実行アーティファクトを記録します。
- 回復不能な軌跡、構文的な破損、体系的なエラー（例：タイムアウト）をフィルタリングし、教師信号が退化した突然変異に支配されないようにします。
得られたFinch Collectionは10ドメインにわたる約156Kの軌跡を含みます。Fine-tuningは遷移を条件付き生成問題として扱います：プロンプト（タスク仕様、親、フィードバック）が与えられた際に子を予測するというものです。軌跡は、生産的なバックトラックや成功した突然変異を含む情報量の多い遷移を保持するようフィルタリングされているため、モデルは評価器のフィードバックが与えられたときにどの編集が解を改善するかについての暗黙的なポリシーを学習します。重要なことに、EFTはテスト時のスキャフォールドとは直交しています：得られたFinchモデルは凍結された重みでOpenEvolveに組み込むことも、テスト時のRLでさらに学習することも可能です。
結果
著者らはQwen3/Qwen3.5を2B、4B、8B、9Bでfine-tuneし、5つのドメイン（Mathematical Discovery、Algorithm Engineering、System Performance、Competitive Programming、Algorithmic Heuristics）にわたる22個のhold-outタスクにおいて、OpenEvolve内の同一ベースモデルと比較しました。表3のハイライトを以下に示します：
- Erdős minimum overlap。 Finch-4Bは目的関数を 0.4169 から 0.3865（+7.31\%）に削減し、Finch-8Bは 0.3812 に到達し、最良の既知の人間による下界 0.3809 およびClaude-Opus-4.6（0.3819）とほぼ同等です。
- Circle packing n{=}26。 Finch-9Bはスコアを 1.173（Qwen3.5-9B）から 1.936（+65.1\%）に改善し、GPT-5/Gemini-3-Pro（2.54）およびClaude-Opus-4.6（2.63）との差を大きく縮めています。
- Hadamard max-determinant。 Finch-8B：0.502 対ベース 0.452（+10.9\%）、Finch-9B：0.481 対 0.397（+21.0\%）。すべてのサイズが恩恵を受けるわけではなく、Finch-4Bは 0.146 に後退しており、このタスクにおける小規模スケールでの不安定性を示唆しています。
- ahc058（algorithm engineering）。 ベースのQwen3.5-9Bのスコアは 1.34\times10^8、Finch-9Bは 5.25\times10^8（+290\%）に到達します。ベースの2B/4B/8Bはすべてスコア 0 であり、著者らはこれを平均から除外しています。
- System performance。 Transactionにおいて、Finch-4Bは 2732 から 4762（+74.3\%）に跳ね上がり、GPT-5（4237）を上回りますが、Gemini-3-Pro（4274）には及びません。
- 総合。 同サイズのベースモデルに対する平均相対利得は +1.56\%（2B）から +10.24\%（9B）の範囲であり、モデルサイズに対して単調です。
特筆すべきことに、いくつかのオープンなFinchのバリアントは、同一のスキャフォールド内でプロプライエタリモデルに匹敵するか、それを上回っています：Finch-8B/9BはErdősでClaude-Opus-4.6を上回り、Finch-4BはTransactionで3つのプロプライエタリモデルすべてを上回ります。スキャフォールドが固定されているため、この差は重みに埋め込まれた突然変異オペレータポリシーのみに起因するものであり、これは重要な意味を持ちます。
スケーリングと転移
第5節では、学習タスク数に対する正のスケーリングが報告されています：AC2、CP（n{=}26）、PRISMにおけるパフォーマンスは、Finch Collectionの使用量が増えるにつれて単調に向上します。表3のサイズスケーリングと組み合わせると、コレクションは飽和しておらず、利得が学習タスクに類似したタスクに集中していないことが示唆されます——評価セットは学習セットとほぼ非重複です。競技プログラミングの結果（CALICO P263およびFrontierCS P301–305）は、ドメイン横断転移のストレステストとして使用されており、Finchは数学およびシステムタスクで学習した戦略を、NP困難なコンテスト問題に取り組む際に組み合わせているように見えます。
限界と未解決の課題
- 論文は局所的な後退（4BでのHadamard、2BでのAhc039、9BでのEPLB）を報告しており、「Avg. Gain」はベーススコアがゼロであるためahc058を除外しています。タスク・サイズをまたいだ分散は完全には特徴付けられていません。
- 教師信号はFinch Collectionを構築したLLMによって生成されたOpenEvolveのトレースの模倣であり、EFTの上限はRLと組み合わせない限り教師の分布に制約されます。
- 論文の抜粋では loss の詳細（子に対する全シーケンスのLM loss？ \Delta s による重み付け？）が記述されていませんが、これは再現性にとって重要です。破損・タイムアウト以外のフィルタリング基準も詳細が不足しています。
- テスト時のRL単独との直接比較がないため、RLの事前初期化としてのEFTの限界価値は推定であり、実測値ではありません。
- 371個の学習タスクと22個の評価タスクの間のデータ汚染については「可能な限り」最小化されたと主張されていますが、定量的に監査されていません。
なぜこれが重要か
EFTは、進化的スキャフォールドに暗黙的に存在する「発見ポリシー」——突然変異の選択、フィードバックの解釈、バックトラック——が、フィルタリングされた探索トレースへのSFTによって2〜9Bのオープンモデルに内在化できることを具体的に示しています。これにより、Erdősや円充填のようなタスクにおいて、同一のスキャフォールド内でフロンティアのプロプライエタリモデルとの差を縮めることができます。報告されたタスク数スケーリングが成立するならば、これは進化的探索をタスクごとのテスト時手続きから中間学習のデータソースへと再定義するものです。
Source: https://arxiv.org/abs/2606.29082
強化学習とメタ認知フィードバックによるLLMの忠実な不確実性表現の引き出し
問題
LLMが表現する確信度は、内部（固有）の不確実性と乖離しています。すなわち、確信を持って幻覚を生成したり、知っていることに対して曖昧な表現を用いたりします。本論文が対象とするのは、忠実なキャリブレーション（Faithful Calibration, FC）です。FCは、グラウンドトゥルースとの整合性（標準的なキャリブレーション）ではなく、表現された確信度と応答の一貫性から推定される固有の確信度との整合性として定義されます。FCそれ自体がメタ認知的タスクであり、モデルは自身の正解確率を監視しなければなりません。このFCは、最先端モデルでさえ十分に達成されていません（Table 1によると、Gemini-3.1-Proの平均cMFG*は0.70、Gemini-3-Flashは0.66、GPT-5は0.61と報告されています）。
手法
パイプラインは2段階から構成されます。（1）数値で表現された文レベルの確信度に対するRL、次いで（2）数値スコアを言語的ヘッジに変換する書き直し段階です。この分離により、ユーザーのヘッジスタイルの好みが変化した際にRLを再実行する必要がなくなり、また語彙的ヘッジに対するGRPOのmode-collapseの傾向も緩和されます。
RL の設定。 クエリ q が与えられると、モデル M_\theta は G 個の補完を生成します。各補完は（文、確信度）ペアの系列です： r_g = \{(s_1,c_1),\ldots,(s_{N_g},c_{N_g})\},\quad g=1,\ldots,G. 文ごとの固有の確信度は、G 個のロールアウト全体にわたるサンプル間の一貫性から推定されます（GRPOグループの二重利用）。各 r_g には、（i）表現された確信度と固有の確信度の忠実性、（ii）正確性、（iii）事実的キャリブレーション（既知の事実的/忠実なトレードオフへの対抗）、および（iv）フォーマット遵守を組み合わせた複合スカラー報酬 \rho_g が与えられます。
Liu et al. に倣い、正規化なしのGRPO advantage を使用します： A_g = \rho_g - \bar{\boldsymbol{\rho}}, 困難度バイアスを低減するために \text{std}(\boldsymbol{\rho}) の分母を省略しています。
RLMF — メタ認知フィードバック。 中心的な新規性は、\rho_g をランキング信号としてそのまま受け入れるのではなく、RLMFがモデル自身の補完品質の判断によって advantage を変調する点にあります。具体的には、モデルにグループに対する自己判断を問い合わせ、その判断が A_g で使用されるグループ相対ランキングを再重み付けします。これにより、監視信号（自己評価）が調整信号（policy gradient の再重み付け）に変換され、自身のパフォーマンスを正確に判断できるモデルはより効果的に改善できるという論文の主張が実装されます。
メタ認知データ選択。 同じ自己判断メカニズムを用いて、高価値な学習事例、すなわちモデルの自己評価が候補間でよく識別できる事例を選択します。これは素朴な能動学習の選択を上回ると報告されています。
書き直し段階。 第1段階で忠実な数値スコアが得られた後、別の書き直しステップが c_i を言語的不確実性表現に変換します。これにより語彙的多様性が保たれます。cMFG* メトリクスは本来、繰り返しにペナルティを与えるものではないためです。
結果
主要メトリクスはcMFG*（忠実な生成のための複合メトリクス、高いほど良い）であり、劣化確認のために精度（Acc）とBrierスコア（BS）が追跡されています。
- Llama3.1-8B-Instruct: ベースラインcMFG* = 0.60 → RLMF 0.84 → RLMF+Rewrite 0.82。精度は0.31 → 0.41に向上し、BSは0.33 → 0.26に低下。
- Qwen3-8B: ベースライン0.54 → RLMF 0.83。精度0.55 → 0.57、BS 0.31 → 0.19。
- メタ認知的advantage スケーリングなしのアブレーション（RL行）: Qwen3-8Bは平均0.51まで崩壊（HE = 0.20、AC = 0.32、SG = 0.38）し、これらの報酬に対する素のGRPOが不安定であること、そしてメタ認知的再重み付けこそが学習を安定化・汎化させていることが確認されました。
- ベースラインとの比較: prompting（MetaFaith）に対して平均29%、SFT（FUT）に対して平均25%の改善。
- プロプライエタリモデルとの比較: 8BのRLMFは、後者が特化したpromptingを使用しているにもかかわらず、平均cMFG*においてGPT-5を37%、Gemini-3-Flashを25%、Gemini-3.1-Proを17%上回っています。
- OOD汎化: PopQAのみで学習されたRLMFは、FUTとは異なり、MATH、SimpleQA、その他のタスクでも性能を維持します。FUTの改善は学習に近いQAフォーマットに集中しています。
- 学習タスクの堅牢性（Table 2）: 学習データをPopQAからSelfAwareに切り替えると、Llama3.1-8BでcMFG*は0.81（PopQA使用時の0.84と比較）となり、手法が特定の監督分布に敏感でないことが示されています。
信頼性ダイアグラムは、FUTとベースモデルが低い固有確信度において系統的に過大評価すること（低い確信度を表現できない）を示す一方、RLMFの表現された確信度と固有の確信度の曲線は [0,1] の全範囲にわたって対角線を追従していることを示しています。これは、改善が単なる平均化の副産物ではなく、両端において忠実な単調挙動を反映していることを示す最も明確な証拠です。
限界と未解決の問題
- 固有の確信度はGRPOグループ全体の応答一貫性によって代理されており、これは認識論的不確実性とサンプリング温度・フォーマット分散を混同しています。FCはこの代理指標と同程度の意味しか持ちません。
- 学習されるのは8Bクラスのオープンモデルのみであり、メタ認知シグナル自体がより信頼性が高く、異なるダイナミクスをもたらし得る最先端規模のモデルに対してRLMFを学習した結果は報告されていません。
- 書き直しモジュールは別途学習・promptingされており、分布シフト（長文推論、コード、マルチターン）における忠実性はここではストレステストされていません。
- 複合報酬の重み付けは §C.1.1 で固定されており、メタ認知的advantage 再重み付けと報酬混合係数の相互作用は切り離されていません。
- advantage の再重み付けに使用される自己判断はモデル自身の出力です。モデルの監視が系統的に偏っている場合、RLMFはその偏りを強化する可能性があります。これは信頼性ダイアグラムが部分的にしか対処していない未解決の問題です。
なぜ重要なのか
忠実なキャリブレーションは、下流の信頼行動（委任、ツール使用、拒否）の前提条件であると主張できます。先行手法は、分布内でのみ有効（FUT）であったか、精度を劣化させた（MetaFaith）かのいずれかでした。RLMFは、モデル自身の自己判断をGRPOのadvantage 推定に組み込むことで、精度を損なうことなく8BモデルをFCにおいてプロプライエタリの最先端モデルを超えるまで押し上げられる十分に強いシグナルとなることを示しています。これは、監督としてのメタ認知が哲学的な枠組みにとどまらず、実用的なRLのprimitiveであることの証拠です。
Source: https://arxiv.org/abs/2606.32032
PolyFlow: アーティストスタイルのメッシュ生成のための連続トポロジー Embedding Flow Matching
問題
アーティスト品質のメッシュ生成は現在、メッシュ \mathcal{M} = (\mathcal{V}, \mathcal{F}) を固定の z-y-x 頂点順序のもとでトークン列 \mathbf{s} = (s_1, \dots, s_L) に変換し、p(\mathbf{s}) = \prod_{i} p(s_i \mid s_{<i}) を因数分解する自己回帰 Transformer（MeshGPT、MeshAnything およびその後継）が主流です。これにより生成されるトポロジーはクリーンですが、デコードは厳密に逐次的であり、L は面数に対して線形に増加するため、並列生成器と比べて推論が数桁遅くなります。並列デコードを実現できる flow matching や拡散は、メッシュを直接入力として扱えません：隣接構造 \mathcal{F} は離散的な組合せ論的オブジェクトであり、ガウスノイズに対して閉じていないからです。PolyFlow の目標は、ユークリッド近傍構造が離散的な隣接関係をエンコードするような連続状態を得ることで、標準的な flow-matching Transformer がジオメトリとトポロジーを同時に並列でデノイズできるようにすることです。
手法
連続トポロジー embedder。 核心となるアイデアは、各頂点 v_j（位置と法線を含む）を連続ベクトル \mathbf{e}_j \in \mathbb{R}^{d} にマッピングする事前学習済み・凍結済み embedder であり、embedding ペア間の時空間距離をしきい値処理することで元の離散エッジ集合を復元できます。具体的には、エッジ (v_j, v_k) \in \mathcal{E} は、学習済みまたは固定のしきい値 \tau に対して d(\mathbf{e}_j, \mathbf{e}_k) < \tau が成立する場合にのみデコードされます。ここで「時空間」とはユークリッド位置と学習された embedding チャンネルを組み合わせたものです。これにより隣接関係が連続ベクトル上のメトリック近傍述語に変換され、小さな摂動に対して安定となります——これはまさに拡散/flow モデルが収束付近で生成するものです。
結合 flow 状態。 embedder を事前学習して凍結した後、各メッシュは頂点ごとのテンソル \mathbf{z} = [\mathrm{xyz},\, \mathrm{normals},\, \mathrm{emb}] \in \mathbb{R}^{B \times V \times D} となります。3 つのチャンネルグループすべてが 1 つの連続状態として扱われ、独立した離散ブランチは存在しません。
Flow-matching Transformer。 線形補間 \mathbf{x}_t = (1-t)\mathbf{x}_0 + t\mathbf{z}、\mathbf{x}_0 \sim \mathcal{N}(0, \mathbf{I})、目標速度 \mathbf{v}^\star = \mathbf{z} - \mathbf{x}_0 を用いた条件付き flow-matching 目的関数が使用されます。Transformer v_\theta は以下の損失で学習されます： \mathcal{L} = \mathbb{E}_{t, \mathbf{x}_0, \mathbf{z}, c} \big\lVert v_\theta(\mathbf{x}_t, t, c) - (\mathbf{z} - \mathbf{x}_0) \big\rVert_2^2, ここで c は凍結された条件エンコーダ（学習時にメッシュ表面からサンプリングされた点群）からの点群特徴量です。
推論。 ユーザーは目標頂点数 \hat{V} を指定します。モデルはガウスノイズから (B, \hat{V}, D) の形状を持つ \hat{V} 個のトークンを初期化し、Transformer の EMA コピーを用いて 50 ステップの Euler 法で ODE \frac{d\mathbf{x}_t}{dt} = v_\theta(\mathbf{x}_t, t, c) を積分します。得られた \mathbf{z} はチャンネルごとに位置・法線・embedding に分割され、エッジと面は embedding ブロックに対する時空間距離しきい値処理によって読み出されます。すべての頂点が同時にデノイズされるため、コストは attention のスケーリングを除けばおおよそ V に依存しません。これは自己回帰ベースラインが必要とする \mathcal{O}(L) 回のデコーダパスとは対照的です。頂点数の制御は厳密であり——これは自己回帰モデルが早期停止によってのみ近似できる特性です。
Figure 3 は機械的な観点から注目に値します：隣接関係は連続 embedding のしきい値処理に由来するため、embedding クラスタが収束するにつれて接続性が徐々に出現します。初期ステップではノイズの多い面を持つもっともらしい点群が生成され、後期ステップでは離散的な再サンプリングなしにエッジが所定の位置に確定します。
結果
学習には公開および有償の 3D アセットリポジトリから収集した約 500 万メッシュが使用され、評価はホールドアウトされた Toys4K で行われます。条件付けは目標表面から一様サンプリングされた点群です。アブストラクトとパイプラインの説明は 2 つの操作上の主張をしています：(i) L 回の自己回帰ステップではなく単一のデノイズ軌跡による完全並列頂点生成、および (ii) ユーザー指定の \hat{V} によって駆動される推論時の厳密な頂点数制御です。ティーザー図は、秒単位のウォールクロックレイテンシでアーティストスタイルのトポロジー（規則的なクワッドのようなレイアウト、クリーンなエッジループ）を示しており、これは以前は自己回帰メッシュ Transformer にのみ許された定性的な領域でした。
制限と未解決の問題
- embedder は事前学習済みで凍結されており、その容量が flow が表現できるトポロジー的複雑さの上限を決定します。embedder の学習セットで十分にカバーされていない隣接パターンを持つメッシュは、flow がいかにうまくデノイズしても復元できません。
- 時空間距離しきい値処理は局所的なペアワイズルールです。3 つ以上の頂点が互いに \tau 以内にある場合に面（エッジとは異なる）がどのように区別されるかは明確ではなく、面の抽出には抜粋中で詳述されていない追加の組合せ論的後処理が必要である可能性があります。
- ユーザーは \hat{V} を指定する必要があります。これは制御可能性の観点からは利点ですが、オープンエンドな生成においては負担となります。モデルが V を自ら選択するための明確なメカニズムは存在しません。
- 提供された抜粋には定量的な比較（Chamfer 距離、法線一貫性、トポロジー指標、MeshAnything/EdgeRunner との対比におけるレイテンシ数値）が含まれていません。自己回帰ベースラインに対する効率性の主張は、示されたセクションにおいて実験的に裏付けられておらず、アーキテクチャ的な議論にとどまっています。
- 部分的なデノイズ下でのしきい値処理のロバスト性、および高次ソルバーや distillation によって ODE のステップ数 50 を削減できるかどうかは未解決です。
なぜこれが重要か
PolyFlow は、\mathcal{F} の離散性を学習された連続 embedding 上のメトリック述語に押し込めることで、アーティストスタイルのメッシュトポロジーと並列的な flow-matching スタイルのデコードを組み合わせる最初の有力なアプローチです。embedder が汎化するならば、これは高精度なメッシュ生成をインタラクティブなツールにとって非現実的にしてきた逐次デコードのボトルネックを解消します。
Source: https://arxiv.org/abs/2606.30673
BrainJanus: 脳・視覚・言語にわたる理解と生成のための統合モデル
問題設定
脳エンコーディング（刺激 \to 神経応答）と脳デコーディング（神経応答 \to 刺激）は、これまで独立したパイプラインとして扱われてきました。デコーディング研究は一般に、fMRI encoder を凍結された CLIP/unCLIP/diffusion スタック（例：MindEye2）に接続する形で構築されており、エンコーディングモデルは画像特徴からボクセル活動を回帰します。しかし、このような分離設計は、皮質が視覚情報と言語情報を共有された表現多様体の中で統合しているという事実を無視しています――この主張はHuth et al. (2016) のようなセマンティックタイリングの結果によって支持されています。著者らは、image\leftrightarrowbrain と text\leftrightarrowbrain の四方向すべてを一つのモデルで扱うことが、計算論的により忠実なアナロジーであり、タスク間で統計的な強みを共有できると主張しています。
手法
BrainJanus は二段階・離散トークン・自己回帰型システムです。(x_B, x_V, x_L) \in \mathcal{B} \times \mathcal{V} \times \mathcal{L} を fMRI・画像・キャプションの三つ組とします。
ステージ1 — 統合脳トークナイザー。 連続ボクセル応答 x_B \in \mathbb{R}^{N_v} を、視覚トークンおよび言語トークンと共有される「Omni」コードブックに属する離散コード列 z_B \in \{1,\dots,K\}^{T_B} へと量子化します。具体的には、トークナイザーが埋め込み e_B = f_\theta(x_B) を生成し、ベクトル量子化の前に事前学習済みの視覚・テキストトークン埋め込みとアライメントを取ります。これにより、脳トークンのインデックス k は、画像パッチやテキストパッチから到達した同一インデックスと同等のセマンティックな役割を持ちます。アライメントの目的関数は、x_B に対する再構成項と、e_B を Omni 空間内の対応する画像・キャプション埋め込みへと引き寄せるコントラスティブ/回帰項を組み合わせたものです。
ステージ2 — オールインワン自己回帰 transformer。 トークナイザーを用いることで、任意のモダリティが離散列に変換されます。学習時には、[\text{task}] \, z_{\text{src}} \, [\text{sep}] \, z_{\text{tgt}} の形式にタスクタグを付与した列を連結し、標準的な次トークン予測 loss
\mathcal{L} = -\sum_{t} \log p_\phi(z_t \mid z_{<t})
を最適化します。SFT 中は image\tobrain、text\tobrain、brain\toimage、brain\totext の四タスクが混合されます。トークナイザー・語彙・目的関数が共有されているため、任意の方向への推論は同一のバックボーンからの条件付き生成として行われます――diffusion prior も unCLIP head も不要です。
データとキャプション。 実験には Natural Scenes Dataset（NSD）を使用し、被験者 1、2、5、7 に対して MindEye2 プロトコルに従い、9,000 枚のユニークな訓練画像と共有1,000枚のテストセット（各3試行）を使います。元の COCO キャプションが簡素であることから、著者らは Qwen3-VL-235B-A22B-Instruct を用いて NSD の73k 画像プールを再キャプションし、生成されたキャプションが COCO オリジナルよりも高い画像・キャプション間セマンティック類似度を持つことを示しています。
結果
Brain-to-image 再構成（Table 3、NSD テストセット）。 BrainJanus は比較対象の中で唯一の完全自己回帰型 brain-to-image システムです。diffusion ベースの SOTA（MindEye2、UMBRAE、Ozcelik and VanRullen、Takagi and Nishimoto）と比較して、PixCorr 0.173、SSIM 0.292、AlexNet(2) 90.3%、AlexNet(5) 97.1%、Inception 94.7%、CLIP 94.4%、EfficientNet 0.656、SwAV 0.372 を報告しています。MindEye2 は低レベルピクセル指標（PixCorr 0.322、SSIM 0.431）で依然として上回っていますが、BrainJanus は高レベルセマンティック指標では競合的ないし優位です――AlexNet(5) 97.1% vs. 98.6%、Inception 94.7% vs. 95.4%、CLIP 94.4% vs. 93.0%。特筆すべきは、BrainJanus が AlexNet(2/5) において Qwen3-VL-235B による「caption\toimage」オラクルを上回ること（90.3/97.1 vs. 85.0/94.2）であり、デコードされた latent がキャプションから再構成される情報を超えた情報を保有していることを示唆しています。
ゼロショット brain-to-image。 brain-to-text ペアのみで訓練し、推論時に画像を生成すると、PixCorr 0.077、SSIM 0.257、AlexNet(2) 69.3%、CLIP 77.3% が得られます。教師あり設定より劣りますが、偶然水準を大幅に上回り、セマンティック指標では初期の diffusion ベースライン複数を超えており――共有 Omni 空間が暗黙的に方向性を転移させる証拠となっています。
Brain-to-text。 MindEye2、UMBRAE、MindLLM との定性比較では、物体識別の誤りが少なく、行動属性の保存が良好です。詳細な数値言語指標は抜粋中には示されていませんが、図はセマンティックマッチの一貫した向上を強調しています。
限界と未解決の問題
- 低レベル忠実度は MindEye2 に劣ります（PixCorr 0.173 vs. 0.322）。適度なコードブック解像度での離散トークン化は、ピクセルレベルの diffusion デコーダが保持する細かい空間的詳細を失います。
- 評価対象は NSD の4被験者のみであり、トークナイザーの被験者間汎化や Omni 空間が被験者不変かどうかは、示されたテーブルでは定量化されていません。
- トークナイザーの学習は (x_B, x_V, x_L) のペアリングされた三つ組に依存しており、ペアデータが乏しいモダリティ（テキスト付き EEG、MEG など）へのスケーリングは、「脳信号」という枠組みにもかかわらず未検証です。
- エンコーディング結果（image\tobrain、text\tobrain）は抜粋中でカバーされておらず、結合学習が特化型エンコーダと比べて順方向に寄与するか損なうかは不明です。
- Qwen3-VL による合成キャプションへの依存は分布シフトをもたらします。報告された CLIP/Inception の向上は、COCO グラウンドトゥルースよりも豊かなキャプションとのマッチングに向けて訓練されたことを部分的に反映しています。
重要性
脳エンコーディングと脳デコーディングを共有された離散空間における次トークン予測として再定式化することで、断片化されたスタック（CLIP + unCLIP + diffusion prior + captioner）が、競争力のあるセマンティック性能とネイティブな任意対任意推論（非自明なゼロショット brain-to-image 転移を含む）を持つ一つの自己回帰モデルへと集約されます。Omni 空間のアライメントが被験者とモダリティをまたいで成立するならば、タスク固有のパイプラインよりも、マルチモーダル皮質表現を研究するための洗練された基盤を提供します。
Source: https://arxiv.org/abs/2606.30319
Hacker News Signals
Claude Codeはリクエストをステガノグラフィ的にマーキングしている
AnthropicのClaude Code CLIは、APIに送信されるプロンプトに隠しメタデータを埋め込んでいます——これはアプリケーション層におけるステガノグラフィ的な透かし（ウォーターマーキング）の一形態です。thereallo.devに記録されたこの発見によると、同ツールはリクエストがネットワークに到達する前に、不可視のUnicode文字（具体的にはゼロ幅文字やvariation-selectorコードポイント）をシステムプロンプトまたはユーザーターンのテキストに挿入しています。これらの文字は、リクエストの送信元、おそらくはツールのバージョン、セッションコンテキスト、またはオペレータのIDに関する構造化された情報をエンコードしています。
実際的な結果として、AnthropicはHTTPヘッダーやAPIキーのメタデータだけに頼ることなく、Claude Codeに由来するトラフィックと生のAPIコールとを区別できるようになります。なお、ヘッダーやAPIキーのメタデータはいずれも容易に偽造・除去が可能です。これはレート制限、不正利用の検出、そして潜在的には挙動のチューニングにも関わります——モデルまたはサービングインフラが、検出した送信元情報に基づいてレスポンスを変化させる可能性があります。
セキュリティの観点から見ると、この技術はインバンド通信に隠されたアウトオブバンドシグナリングの一形態です。この透かしはプロンプトテキストのコピー＆ペーストを経ても保持されます——それがこの手法の要点であり、ヘッダーよりも堅牢です。ただし、UTF-8バイトストリーム内の非印刷Unicodeを探すことさえ知っていれば簡単に検出でき、Unicodeノーマライザーやコードポイントのホワイトリストフィルターによって同様に容易に除去できます。
スレッドで提起されているより広範な懸念は、同意と透明性に関するものです。Claude Codeのユーザーは、自分のプロンプトに送信元を示す埋め込みマーカーが含まれていることを知らされていません。これはサプライチェーントラストの問題に触れています——Claude Codeの出力を別のシステムのプロンプトに転送した場合、Anthropicのメタデータを知らぬうちに転送していることになります。また、不可視の文字がコンテンツハッシュを変化させるため、プロンプトのフィンガープリントや監査を行うダウンストリームシステムへの影響も存在します。
技術的には、これは新しい手法ではありません——ステガノグラフィ的なUnicode悪用は、prompt injectionの研究や情報漏洩のPoC（概念実証）においてすでに記録されています——しかし、ファーストパーティの本番CLIへの展開は注目に値します。
Source: https://thereallo.dev/blog/claude-code-prompt-steganography
脳波から言葉へ：手術なしにコミュニケーションを実現する新たな道
MetaのBrain2Qwertyプロジェクトは、非侵襲的なEEGおよびMEG記録から、想像または試みられたタイピングのキーストロークをデコードします。このシステムは、閉じ込め症候群や重度の運動障害を持つユーザーを対象としており、インプラントなしで動作します。コアとなるパイプラインは、高密度センサーデータをニューラルシーケンスモデルで処理し、脳信号の時間的パターンをQWERTYレイアウト上の文字レベルの出力にマッピングします。これは、特定のキーに対する想像上の指の動きが、識別可能な皮質シグネチャを生成するという事実を利用しています。
MEG（磁気脳波計）は、EEGよりも高い空間・時間分解能を提供しますが、大型で高価な超伝導ハードウェアを必要とします。モデルアーキテクチャは、センサーアレイの空間フィルタリングのための畳み込みフロントエンドで構成されており、時間的シーケンスモデル（ブログ記事の元となる論文によればtransformerベース）に入力されます。このモデルは、神経活動のウィンドウからキーの同一性を予測するように訓練されています。さらに、言語モデルによる再スコアリング段階が、妥当な文字シーケンスに対する事前確率を適用することで、生のデコードエラー率を低減します。
報告されている精度は、言語モデルによる再スコアリングを用いたMEGでの文字レベル正解率が約80%に達しますが、EEGのみでは大幅に低下します。スループットは低く、毎秒数文字程度であり、コミュニケーション用途としては実用的ですが、汎用テキスト入力としてはまだ不十分です。
主な制限事項として、MEGは装着可能でなく、専門的な研究室以外での利用は困難です。EEGの精度は大幅に劣ります。このシステムは被験者ごとのキャリブレーションが必要で、相当量の訓練データ収集を要します。信号の非定常性により、セッションをまたいだ日々の汎化は依然として未解決の問題です。「手術なし」という表現は正確ですが、誤解を招く可能性があります——MEGはベッドサイドや家庭用のデバイスではありません。技術的な観点からの興味深い問いは、このアプローチが乾式電極を用いたポータブルEEGシステムに転用できるかどうかであり、それが実際の実用化への道筋となるでしょう。
Source: https://ai.meta.com/blog/brain2qwerty-brain-ai-human-communication/
Zluda 6 リリース（未改変のCUDAアプリケーションをNvidia以外のGPUで実行）
ZLUDAは、未改変のCUDAバイナリをAMD（および過去にはIntel）GPUで実行可能にするドロップイン型CUDA互換レイヤーです。バージョン6は、AMDによるスポンサーシップ終了後もプロジェクトが独立した軌跡を歩み続けていることを示しています。その仕組みは、CUDAランタイムおよびドライバAPI（libcuda.so / nvcuda.dll シム）の再実装であり、CUDA呼び出しをROCm/HIPへとランタイム変換します。PTX（Parallel Thread Execution）およびSASSは、NVIDIAの仮想ISAをAMDのRDNA/CDNA ISAへとLLVMを通じて変換するIR変換レイヤーにより処理されます。
update-q1q2-2026の投稿では、いくつかの改善が詳述されています。具体的には、以前はサポートされていなかったアトミック演算やwarpレベルプリミティブを含むPTXカバレッジの向上、変換レイヤーにおけるバッファエイリアシングの改善によるメモリ集約型カーネルのパフォーマンス向上、そしてCUDAストリームおよびイベント同期モデルの修正（以前はメモリ一貫性セマンティクスの違いによりAMDハードウェア上でレース状態を引き起こしていたもの）などが挙げられています。
正確性こそが難しい問題です。CUDAのメモリモデルとAMDのメモリモデルは、特にアトミックの強度や__threadfenceの挙動において同一ではありません。ZLUDAは場合によって、より強力な（よりコストのかかる）AMDフェンスを使用してNVIDIAセマンティクスをエミュレートする必要があります。同期の指定が不十分なアプリケーション——実際には一般的です——に対しては、パフォーマンスを犠牲にしつつ正しい結果を生成します。
実用的なターゲットユーザーは、ソースへのアクセスなしにAMDハードウェア上でビルド済みのCUDAバイナリ（PyTorch、コンパイル済みMLカーネル、商用ソフトウェア）を実行する必要があるユーザーです。オープンソースのコードであれば、HIPやROCmで再コンパイルする方が一般的に望ましいです。ZLUDAはパフォーマンスの同等性を保証しておらず、変換オーバーヘッドは現実的に存在し、Nvidiaが特定のCUDAパターンに対して適用するドライバレベルの最適化は再現されません。
Source: https://vosen.github.io/ZLUDA/blog/zluda-update-q1q2-2026/
KubernetesをブラウザにポーティングしてみたM
このngrokのエンジニアリングブログ記事では、WebAssemblyを使ってブラウザのタブ内でKubernetesコントロールプレーンを動作させる手法について解説しています。関連するGoベースのKubernetesコンポーネント（kube-apiserver、etcd、controller-manager、scheduler）をWASMターゲットにコンパイルし、メインスレッドをブロックしないようWeb Workerで実行し、実際のソケットを使わずにインメモリのネットワークスタックでコンポーネント間を接続するアプローチをとっています。
技術的に難しい点は以下の通りです：(1) etcdはファイルI/Oを行うbboltに依存しているため、インメモリストアによるシム置き換えが必要でした；(2) Goランタイムのgoroutineスケジューラおよびタイマー機構はWASM上でも動作しますが、ネイティブよりオーバーヘッドが大きくなります；(3) コンテナランタイムが存在しないため、kubeletや実際のPodスケジューリングはブラウザ内では動作せず、デモは純粋にコントロールプレーンのみであり、実際のワークロードをスケジュールすることはできません。
紹介されているユースケースは、インタラクティブなKubernetes APIドキュメントおよびチュートリアルツールです。ユーザーはサーバーサイドのインフラを一切必要とせず、ブラウザ内でローカルに動作する実際のAPIサーバーに対して kubectl apply を実行できます。これは技術的に正当なアプローチです：WASMコントロールプレーンは正確なAPIセマンティクスで応答し、実際のスキーマに対してマニフェストを検証し、正しいwatch/listレスポンスを返します。
大規模なGoプログラムをWASMにコンパイルするためのエンジニアリング上の課題は容易ではありません：build tag、CGO依存関係、ファイルシステムアクセスパターン、およびネットワークsyscallのすべてにスタブが必要です。どのシムが必要だったかについて、この記事はそれなりに詳細に説明しています。メモリ使用量は相当なものであり、etcdとapiserverをブラウザのタブで実行すると数百MBを消費します。パフォーマンスはインタラクティブな用途には許容範囲内ですが、負荷時のベンチマークは行われていません。
これは、WASMをパフォーマンス最適化の手段としてではなく、サンドボックス化された組み込みランタイムとして活用する好例といえます。
Source: https://ngrok.com/blog/i-ported-kubernetes-to-the-browser
hyper HTTPライブラリにバグを発見
Cloudflareのブログ記事は、RustのHTTPライブラリ hyper におけるHTTP/1.1リクエストパイプライニングとコネクション再利用に関する正確性のバグを解説しています。このバグは、クライアントがkeep-alive接続でパイプライン化されたリクエストを送信し、サーバーがパイプラインの途中で接続を閉じた場合に顕在化します。特定のタイミング条件下で、hyperはパイプライン内の誤ったリクエストにレスポンスを紐付け、レスポンスボディのデータを誤った呼び出し元に届けてしまいます。
根本原因は、処理中のパイプライン化されたリクエストを追跡するhyperの内部ステートマシンにあります。コネクションクローズシグナルの後に受信されたレスポンスが、スロットのリサイクルロジックがパイプラインのフラッシュ完了前に実行された場合、保留中のリクエストスロットに誤ってマッチングされる可能性があります。これはデータレースではなく論理的なレース条件です――hyperはそれ以外の点ではメモリ安全です――しかし、ある呼び出し元が別の呼び出し元のレスポンスボディのバイト列を受け取るという結果をもたらし、多重化されたコンテキスト（例えば、複数テナントにサービスを提供するリバースプロキシ）では深刻な機密性の問題となります。
Cloudflareの検出経路は興味深いものです。彼らは自社のプロキシ層内部のアカウンティングにおいてレスポンスボディ長の不一致に気づき、それが内部整合性チェックの異常を引き起こしました。このバグはTokioのエグゼキュータにおける非同期タスクのポーリングのインターリーブに依存するため、純粋なユニットテストでは確実に検出できません。
修正は、コネクション状態が安定した後にレスポンスとリクエストのマッチングが検証されるよう、パイプラインステートマシンの順序保証を厳格化することです。この記事は、Rustの所有権モデルが防ぐことのできないバグの典型例として優れた事例です。論理的なプロトコルステートマシンのエラーはメモリ安全性の違反ではありません。
Source: https://blog.cloudflare.com/hyper-bug/
Zig SPIR-V バックエンドの進捗
ZigコンパイラのSPIR-Vコード生成バックエンド — Vulkan/OpenCLを経由したGPUコンピュートをターゲットとする — が、非自明なZigプログラムをGPU実行向けにコンパイルできる十分な完成度に達しました。このdevlogエントリでは最近の進捗として、SPIR-Vコンテキストにおけるigのcomptime評価の処理改善、SPIR-Vの厳格なアラインメント規則に対応した構造体レイアウトの正確性、およびdeferやエラーユニオンを含むZigの制御フロー構文のより広範なサポートについて説明しています。
SPIR-Vは、明示的なエントリポイント、実行モデル、およびケーパビリティ宣言を持つ型付きSSA IRです。ZigのセマンティクスをSPIR-Vにマッピングすることは、LLVM IRへのマッピングよりも困難です。これはSPIR-Vの制約がより厳しいためです：再帰なし、限定的なポインタ演算、明示的なアドレス空間（Function、Private、Workgroup、StorageBuffer）、動的ディスパッチなし、といった制限があります。Zigのcomptimeシステムはここで役立ちます — 他の言語ではランタイムジェネリクスを必要とする処理の多くがコンパイル時に解決され、モデルにきれいに適合する単相化されたSPIR-Vを生成します。
現時点での未対応事項として挙げられているのは、GPUコード上でのZigのアロケータインターフェースのサポートなし（SPIR-Vでは動的アロケーションが利用できないため想定通り）、限定的なデバッグ情報の出力、およびSPIR-VターゲットにおけるZig標準ライブラリのカバレッジの不完全さです。このバックエンドはzig build -target spirv64-vulkan形式の呼び出しをターゲットとしており、シェーダコード向けのspirv-crossを経由する既存のパスを置き換えるか補完することを意図しています。
システム/GPUプログラミングコミュニティにとって、これは重要な意味を持ちます：Zigの明示的なメモリ管理、隠れた制御フローのなさ、comptimeメタプログラミングは、バックエンドがプロダクション品質に達した場合、GPUカーネルに技術的に適した言語であることを示しています。
Source: https://ziglang.org/devlog/2026/#2026-06-26
Postgresの内部を読む：データベースクラスタ、データベース、およびテーブル
このウォークスルーでは、PostgreSQLデータベースクラスタのディスク上の物理的なレイアウトを取り上げます。これは、ストレージ問題のデバッグ、拡張機能の作成、あるいはページレベルでのPostgresのパフォーマンス理解に取り組むすべての方に直接関係する内容です。Postgresクラスタは、1つのpostmasterプロセスによって管理される単一の$PGDATAディレクトリであり、複数のデータベースを含んでいます。各データベースは$PGDATA/base/以下のOIDで名付けられたサブディレクトリにマッピングされています。
各テーブルは1つ以上の8 KBのページファイル（デフォルトでは最大1 GBのセグメント）として格納されます。ヒープファイルのフォーマットには、WAL用のLSN、チェックサム、空きスペースポインタ、およびラインポインタ配列を含む固定のページヘッダ（PageHeaderData）があります。タプルはページの末尾から先頭に向かって格納され、ラインポインタ配列（アイテム識別子）は先頭から末尾に向かって伸びます。この双方向の成長により、空きスペースはページの中央に位置し、pg_freespaceを通じて確認できます。
各タプルは独自のヘッダ（HeapTupleHeaderData）を持ち、MVCCの可視性判定のためのxmin/xmaxトランザクションID、ctid（更新後の転送用の物理位置）、nullビットマップ、およびテーブルがOIDを持つ場合はそのOIDを保持しています。MVCCモデルでは、行の更新はその場での上書きを行わず、新しいタプルバージョンを書き込み、古いタプルにxmaxを設定します。Vacuumingは、xmaxがコミット済みであり、かつどのアクティブなトランザクションも古いバージョンを参照できないタプルをスキャンすることで、デッドタプルのスペースを回収します。
また、OIDを人間が読める名前にマッピングするpg_class、pg_attribute、およびpg_namespaceカタログテーブルについても解説されており、psqlで\d tablenameを実行した際に物理ストレージへどのように変換されるかを理解するための正しい入口となっています。
Source: https://www.buraksen.dev/articles/internals-of-postgresql-db-cluster-and-tables
Linuxカーネルからstrncpyの全インスタンスを除去するまで6年と360パッチ
strncpyは実際のほぼすべての用途において危険な設計を持っています。指定した長さまでヌルバイトで宛先をパディングしますが、ソースが宛先より長い場合にはヌル終端を保証しません。つまり、strncpy(dst, src, n)がヌル終端文字列を生成すると仮定するコードは、strlen(src) >= nのときに常に誤動作しますが、これはまさにバッファの安全性が最も重要となる条件です。
Linuxカーネルには数十年にわたって何百ものstrncpy呼び出し箇所が蓄積されていました。約6年間・〜360パッチにわたって完了した置き換えキャンペーンでは、カーネル4.3で導入されたstrscpyを代替として採用しました。strscpyは常にヌル終端し、書き込んだ長さを返すか、切り捨て時に-E2BIGを返し、ヌルパディングを行いません。これにより切り捨ての検出が扱いやすくなります。呼び出し元は暗黙のデータ破損に頼るのではなく、戻り値をチェックできます。
困難だったのは機械的な置き換えではなく、各呼び出し箇所の監査でした。一部の用途はヌルパディングの動作に意図的に依存していました（ゼロパディングが必要な固定サイズのプロトコルフィールドに対してはstrncpyが正しい選択です）。また、戻り値を誤って使用していた箇所や、strscpyの異なるセマンティクスによって露わになる微妙な長さの算術エラーを含む箇所もありました。各パッチは周辺コードの不変条件を理解する必要がありました。
これはCの安全性是正における「ロングテール」の事例研究です。コンパイラは一般的なケースでstrncpyについて警告できません。なぜなら、その危険性は構文的ではなく意味的なものだからです。GCCとClangは一部のパターンを検出する-Wstringop-truncationを追加しましたが、すべてを網羅はできません。カーネルの解決策は、技術的であるのと同様に社会的・手続き的なものでした。単一の自動変換ではなく、複数年にわたる継続的なレビュー活動によって達成されたのです。
Source: https://smist08.wordpress.com/2026/06/25/linux-kills-strncpy/
注目の新しいリポジトリ
myccarl/ai-shortVideo-pipeline
自動化されたショート動画制作のためのエンドツーエンドパイプラインです。FastAPIオーケストレーション層とSpring Boot APIゲートウェイを備えたマイクロサービスアーキテクチャを基盤として設計されています。このシステムは、複数の生成モデル（画像、動画、TTS、音楽）をマルチモデルフェイルオーバー戦略とサーキットブレーカーの背後に統合しており、プロバイダーのエンドポイントが劣化しても制作が停止しないようになっています。メータリングと分散トレーシングはファーストクラスの機能として扱われており、オブザーバビリティスタックはリクエストごとのレイテンシ、トークンコスト、モデル固有のエラーレートをカバーしています。
AIによる品質ゲーティングは、技術的に最も興味深い層です。プロンプトアンカリングは、下流のモデル呼び出しを正規の意味的テンプレートに結び付け、カット間での被写体のドリフトを低減します。CLIPによる一貫性スコアリングは、セグメントを受理する前にフレーム間および音声カバーの意味的アライメントを計測します。AVシンク自動修復は、生成された音声と動画のタイムスタンプ間のドリフトを検出し、クリップ全体を再生成することなく再アライメントを試みます。
単純なルールベースフィルターを超えた品質チェックを求めながら、プロダクション向け動画自動化サービスを構築する人にとって、合理的な出発点となります。サーキットブレーカーとフェイルオーバーのロジックは、マルチプロバイダーのLLMや生成メディアバックエンドであれば直接再利用可能です。
Source: https://github.com/myccarl/ai-shortVideo-pipeline
NotASithLord/peerd
Peerdはブラウザ拡張機能（ChromeおよびFirefox）としてAIエージェントループを実行し、従来のバックエンドサーバーをアーキテクチャから排除します。エージェントはWebExtensions APIをアクションスペースとして使用し、DOMの状態の読み取り、クリック、フォームへの入力など、ブラウザタブを直接操作できます。クライアントサイドではサンドボックス化されたコンピューティングが利用可能です：JavaScriptノートブックおよびWASMコンパイルされたLinux VM（おそらくv86または類似のエミュレータを使用）により、エージェントは外部へのコンピューティング呼び出しを一切行わずにコードを実行できます。
出力アーティファクトは中央サーバーを介さずにピアツーピアで共有されます。おそらくWebRTCデータチャネルまたは類似のブラウザネイティブトランスポートを使用していると思われます。BYOK（Bring Your Own Key）により、モデル推論の呼び出しはブラウザからプロバイダーのエンドポイントへ直接行われ、テレメトリやプロキシのレイヤーは存在しません。
セキュリティモデルは精査に値します：ブラウザネイティブのエージェント実行は、エージェントとユーザーの認証済みセッション間の分離境界を崩壊させます。しかし、ローカル専用または低信頼サーフェスのユースケースでは、このトレードオフによって大幅なシンプルさが得られます。このアーキテクチャは永続的なバックエンドを運用する運用上のオーバーヘッドを排除し、拡張機能とWASMイメージが一度ロードされれば完全なエアギャップ環境にも対応しています。
Source: https://github.com/NotASithLord/peerd
cobusgreyling/loop-engineering
Loop engineeringは、人間・エージェント・ツールのインタラクションサイクルの構造化に特化した設計ディシプリンです。具体的には、AIコーディングエージェントが実質的な作業を行う際に、prompt、context window、tool call、およびレビューステップをどのように組み合わせるべきかを扱います。このリポジトリは、実践的なパターン、スターターテンプレート、およびそのワークフローを対象とした3つのCLIツールをまとめたものです。
loop-initはエージェントを意識した構造でプロジェクトをscaffoldします（おそらくsystem-promptファイル、tool manifest、context budgeting設定などが含まれます）。loop-auditは既存のagent loopについて、contextの無制限な増大、レビューゲートの欠如、tool descriptionの曖昧さといった一般的な障害モードを分析します。loop-costは実行前に指定されたloop設定のトークンコストおよび金銭的コストを見積もります。
概念的なフレームワークはAddy OsmaniとBoris Chernyによるai assisted開発ワークフローに関する研究に基づいています。汎用のLLM promptライブラリとの違いは、一度限りの生成ではなく、prompt・実行・観察・再promptというイテレーティブなloop構造に明示的に焦点を当てている点です。4600以上のスターを獲得しており、コーディングエージェントをCIや開発パイプラインに正式に統合しようとするチームのリファレンスとして注目されています。
Source: https://github.com/cobusgreyling/loop-engineering
DSB-117/brainblast
Brainblastは、AIを活用したソフトウェア開発における特定の見過ごされがちな障害モード、すなわちコンパイルおよびデプロイは正常に通過するものの意味的に誤った「サイレント統合トラップ」を標的としています。典型的な例としては、ゼロ売上の課金設定（例：決して請求が発生しない決済統合）、有効なコードに見える認証バイパス、そして生成時に組み込まれてしまう取り消し不能なアーキテクチャの選択が挙げられます。
このツールは、特定のAIエージェントが導入しそうなトラップを予測するリサーチ／分析フェーズ（おそらく静的解析、既知のエージェント障害モードに対するパターンマッチング、またはLLMを活用したレビューによるもの）と、一度検出されたトラップが修正されたまま維持されることを保証するチェックを組み込むCI強制フェーズを組み合わせています。npx brainblast CLIにより、Node.jsベースのプロジェクトへのドロップイン導入が可能です。
この価値提案は、品質ゲートを本番環境より前にシフトすることにあります。誤設定されたStripe webhookをポストモーテムで発見するのではなく、トラップをエージェント生成時に特定してピン留めします。CIとの統合により、リグレッションは自動的に検出されます。これは、エージェントが外部サービス統合を伴う非自明なビジネスロジックを記述している組織において最も有用です。
Source: https://github.com/DSB-117/brainblast
eli-labz/Third-Eye
Third-Eyeは、複数のインテリジェンスドメインにわたって同時に状況認識を提供する、プロダクショングレードのOSINT（オープンソースインテリジェンス）集約プラットフォームです。「マルチドメイン」という枠組みは、ネットワークインテリジェンス（IPレピュテーション、BGP、証明書透明性）、ソーシャル/Webインテリジェンス、地理空間シグナル、そしてダークウェブやペーストサイトの監視といったデータを取り込み、相関させることを示唆しています。
ここでいうプロダクショングレードとは、アドホックなクエリではなく継続的な運用を想定して設計されていることを意味します。具体的には、永続的なデータストア、スケジュール実行によるデータ収集ジョブ、そしてIPアドレス・ドメイン・ソーシャルハンドルを統一された脅威・エンティティグラフへと紐付けられる、正規化されたクロスドメインのエンティティ解決機能が含まれます。約900スターを獲得しており、セキュリティおよびスレットインテリジェンスコミュニティから大きな注目を集めています。
実用的な観点では、このツールは単一目的のOSINTツール（ShodanクエリやWHOIS検索など）と高価な商用プラットフォームの間のギャップを埋めるものです。複数の独立したAPIラッパーをつなぎ合わせることなくドメイン横断でシグナルを相関させる必要があるレッドチーム、SOCアナリスト、あるいは研究者にとって、共通データモデルを持つ統合プラットフォームは実際の運用上の価値があります。
Source: https://github.com/eli-labz/Third-Eye
datalab-to/lift
Liftは、Datalabチームが開発したドキュメント構造化データ抽出ライブラリです。PDF、スキャン画像、HTML等の異種ドキュメント形式から、型付きかつスキーマ準拠のレコードを取り出すという一般的な問題を対象としており、レイアウトや書式が付随的なものではなく情報構造の一部をなすケースを想定しています。
アーキテクチャは、vision-language modelまたはドキュメント理解モデル（おそらくMarker、あるいはDatalabの同系統パイプライン）を、JSON SchemaまたはPydantic形式の型制約を強制する構造化出力レイヤーでラップしたものと考えられます。速度と精度の両立を重視している点から、抽出バックエンドは純粋なAPIパススルーではなくバッチ推論向けに最適化されていることが示唆されます。
JSON schemaを指定した生のGPT-4o呼び出しとの実質的な差別化ポイントは、パイプラインレベルの信頼性にあります。すなわち、ドキュメントレイアウトのバリエーションを越えた一貫したフィールド抽出、複数ページにまたがるテーブルの処理、そして返却前に抽出された構造が正しく形成されているかの検証が挙げられます。687スターという数字が示す採用増加は、データ取り込みパイプラインを構築する開発者にとって、生のOCRより上位かつ本格的なドキュメント処理プラットフォームより下位という、ちょうど適切な抽象レベルに位置していることが理由と考えられます。
Source: https://github.com/datalab-to/lift
dongshuyan/compass-skills
COMPASS（司南）は、AIエージェント向けのパーソナルアラインメントスキルオペレーティングシステムです。タスク固有の振る舞いモジュール（「スキル」）を定義・構成・ルーティングするためのフレームワークであり、エージェントの応答や行動を細粒度のレベルでパーソナライズおよび制御することを可能にします。「パーソナルアラインメント」という位置づけは、汎用エージェントフレームワークとの差別化点です。単一のグローバルな目標に最適化するのではなく、個々のユーザーの好み・作業スタイル・タスクの文脈にエージェントの振る舞いを適応させることを目指しています。
技術的には、本文脈における「スキルOS」とは、パラメータ化されたプロンプトモジュールまたはツール呼び出しパターンのレジストリ、タスク分類に基づいてスキルを選択・構成するルーティング層、そしてユーザー固有のキャリブレーションを保存する永続化層を意味すると考えられます。総控（そうこん）という名称は、個々のスキルモジュールの上位にメタエージェントまたはオーケストレーターが存在し、実行順序の管理・コンテキストの注入・スキル間のコンフリクト解消を担うことを示唆しています。
506スターを獲得し、中英バイリンガルのドキュメントを備える本プロジェクトは、研究成果としてだけでなく、パーソナライズされたエージェントシステムを構築するための実践的な出発点としても位置づけられており、特に生産性や知識労働のアプリケーションに適しています。
Source: https://github.com/dongshuyan/compass-skills
Nigh/show-me-the-story
単一のGoバイナリと組み込みのWeb UIとして配布される、セルフホスト型の長編フィクション生成ツールです。アーキテクチャは意図的にミニマルに設計されており、データベース依存もクラウドサービスも不要で、OpenAI互換のAPIエンドポイント（ローカルまたはリモート）に接続するバイナリ単体で動作します。そのため、Ollama、LM Studio、あるいはその他のセルフホスト型推論バックエンドとも互換性があります。
生成パイプラインは多段階かつ編集者的な構造を持っており、モデルはまず階層的なアウトラインを生成し、その後章ごとに執筆を進め、各章は承認される前にレビュー、伏線の一貫性チェック、ファクトチェックの工程を経ます。全章が完成した後には、書籍全体の最終的な仕上げパスが実行されます。この段階的なアプローチは、LLMによる長編生成においてよく知られた失敗パターン、すなわち数万トークンにわたる非一貫性や矛盾の蓄積という問題に対して、全文を一度に生成するのではなく構造化された中間表現を維持することで対処しています。
中国語と英語のバイリンガルサポートが組み込まれています。Goによる単一バイナリ配布により、デプロイメントはファイルを一つコピーするだけで完結し、ランタイム依存関係は一切ありません。LLMの物語的一貫性を研究する研究者や、執筆ツールを開発する開発者にとって、アウトラインに基づく反復的生成のクリーンなリファレンス実装を提供するものです。