デイリーAIダイジェスト — 2026-06-23
arXiv ハイライト
CLI-Universe: ターミナルエージェントのための検証可能なタスク合成エンジンに向けて
問題
ターミナルエージェント――マルチステップのエンジニアリングタスクを達成するためにシェルを操作するLLM――の学習データは、進歩を制約する根本的なボトルネックです。既存の合成パイプライン（例：SkillSynth、Nemotron-Terminal、TerminalTraj）は、リポジトリ、manページ、コードスニペットといった表層的な成果物を出発点とし、それらに合わせてタスクを後付けで構築する傾向があります。その結果、生成される指示は仕様が不十分であることが多く、実行パスは浅く（数コマンド程度）、検証テストも脆弱です。つまり、テストが些末な誤答に対してパスしてしまったり、正答に対して失敗したりするため、SFT/RLのシグナルとして弱い、あるいは積極的に誤解を招くものになります。CLI-Universeはこのギャップを埋めることを目指し、(i) 実際の技術的資料に意味的に根ざし、(ii) Docker化された実行可能環境としてインスタンス化され、(iii) fail-to-pass識別能力についてスクリーニングされたテストによって保護されたタスクを生成するよう設計された合成エンジンを提案します。
手法
パイプラインは3つのステージで構成されています（図1）。
ステージ1 — ブループリント構築。 候補は4つの軸にわたるタプルとしてサンプリングされます：ドメイン（例：システム、データ、DevOps）、スキルタイプ、ケイパビリティ、およびエンジニアリングの柱。各タプルは、実世界の技術的ソース（ドキュメント、Issue、チュートリアル）に対して反復的な深層リサーチを実行するリサーチエージェントへのシードとなり、証拠を蓄積しながら構造化されたタスク仕様へと統合します。出力はブループリント、すなわち指示、必要な資産、期待される最終状態、およびルーブリック項目です。このタクソノミー先行・グラウンディング後という設計は、後付けパイプラインとの重要な対比点です――タスクの意味論は成果物が紐付けられる前に決定されるため、仕様を既存の成果物に合わせて歪めるのではなく、成果物の方が仕様を満たすために見つけられるか構築されなければなりません。
ステージ2 — 環境の実体化。 各ブループリントは、具体化された資産（ファイルシステムレイアウト、サービス、ネットワーク設定、初期状態）を持つDockerコンテナにコンパイルされます。ランタイムチェックにより、環境が起動し、宣言された前提条件が成立することが確認されます。
ステージ3 — 実行可能なフィルタリングによる検証。 2つの独立したエージェントが実体化された環境上で動作します：
- テストエージェントは、ブループリントのチェックリストからルーブリックゲート付きテストを合成します。テストは、偶発的な成果物に対してアサートするという一般的な失敗パターンを防ぐため、ルーブリックに対してゲートされます。
- ソリューションエージェントは参照軌跡を生成します。
フィルタリングでは、(a) ヒント条件付きフィルタリング――ソリューションエージェントが過度に具体化されたヒントを与えられた場合にのみ完了できるタスクを除外（些末なタスクの代理指標）――と、(b) 厳密なfail-to-passチェック――空の状態/no-opの状態でテストが必ず失敗し、参照ソリューションが必ずパスすること――が適用されます。すべてのゲートを通過した候補のみが保持されます。
フルファネル全体で候補の33.6%のみが通過し、残りの約3分の2は環境ビルド失敗、ルーブリックとテストの不一致、またはfail-to-pass違反によって除外されます。
結果
モデルはQwen3-denseの8B/14B/32Bであり、CLI-Universeタスク上でKimi-K2から蒸留した6kの軌跡でSFT’d されています。評価にはTerminus 2スキャフォールド（200ターン/タスク、avg@4）をTerminal-Bench 1.0および2.0に使用し、汎化性評価としてBFCL v4とVitaBenchを用います。
TB 2.0において、CLI-Universe-32Bは33.4に達しており、オープンデータの32Bベースラインと比較して：
- SkillSynth-32B: 29.6
- Nemotron-Terminal-32B: 27.4
- TerminalTraj-32B: 22.0
32Bモデルはまた、より大規模なオープンウェイトシステム――Qwen3-Coder-480B（23.9）およびKimi-K2-Instruct-1T（27.8）――を大幅に上回っており、このレジームではデータ品質がパラメータ数を支配していることが示唆されます。Claude-Opus-4.5（57.8）との差は依然として残っています。この優位性は8Bおよび14Bでも保たれており、学習シグナルが特定のスケールに固有のものでないことを示しています。
残存するTB 2.0の失敗に対する失敗モード帰属分析（図5）では、Execution（仕様不遵守、ステップ繰り返し、終了見落とし）、Coherence（コンテキスト喪失、脱線、推論と行動の不一致）、およびVerificationクラスにわたる9つの相互排他的な原因にエラーを分解しています。これは、データがいまだ教えられていないものを分離できるため有用です：CLI-Universeによる学習はVerification/Coherenceエラーの割合を低下させますが、実行レベルの失敗（特にステップ繰り返しと終了見落とし）は依然として目立ちます――これらはデータの問題というよりも、スキャフォールドおよびデコーディングの問題でもあると言えます。
制限と未解決の問題
- 蒸留への依存。 軌跡はKimi-K2から取得されており、32Bの学生モデルの上限は教師モデルの振る舞いによって形成されています。また、本研究ではデータ品質と教師品質の寄与を切り分けていません。
- SFTのみ。 検証器のインフラがRLループにとって必要なものそのものであるにもかかわらず、CLI-Universeデータ上でのRLは報告されていません。ルーブリックゲート付きテストが安定した報酬を提供するかどうかは未検証のままです。
- 33.6%の歩留まりは、このエンジンがコスト高であることを意味します。保持タスク当たりのコストは報告されておらず、合成中の失敗モードがタスクの難易度と相関しているかどうか（すなわち、エンジンが体系的に最も難しいタスクを除外していないか）も不明です。
- アブレーションが不在であり、タクソノミーにシードされたサンプリング、証拠ガイドリサーチ、fail-to-passフィルタリングの各寄与が切り分けられていません。パイプラインの複雑さを考えると、どのゲートがシグナルを担っているかを特定することが再現性の向上に寄与するでしょう。
- BFCL v4およびVitaBenchに関する汎化性の主張は参照されていますが、本稿の抜粋では定量化されていません。
この研究が重要な理由
ターミナルエージェントのベンチマークはクローズドモデルで飽和しつつある一方、オープンシステムはデータ品質で足踏みしています。CLI-Universeは、検証器ファーストの合成パイプラインによって、32Bモデルが一桁大きなオープンシステムに匹敵または凌駕できると、説得力のある数値をもって主張しており――オープンとクローズドの差をスケールの問題ではなくデータエンジニアリングの問題として再定義しています。
Source: https://arxiv.org/abs/2606.22883
BioMatrix: 配列・構造・言語のモダリティマトリクスを網羅する包括的生物基盤モデルに向けて
問題設定
生物基盤モデルは二つの軸に沿って分岐してきました。複数のモダリティを単一の目的関数のもとでネイティブに融合するモデル（例：タンパク質向けのESM3、または分子のみのマルチモーダルモデル）は一種類のエンティティタイプに限定される一方、タンパク質と小分子の両方を扱うモデルは、明示的な3D構造モデリングを省略するか、あるいはベースLMが読み取ることはできても生成することのできないモダリティ固有のエンコーダ・アダプタを付加するかのいずれかが一般的です。この非対称性が問題になるのは、構造を条件とするリガンド設計、タンパク質を考慮した分子生成、テキストから構造への変換といった下流タスクが、同一のモデルが各モダリティを消費かつ生成する能力を要求するからです。BioMatrixは、分子配列・分子構造・タンパク質配列・タンパク質構造・自然言語という「モダリティマトリクス」全体を、単一のnext-token prediction lossで学習された一つのdecoder-only LMとして閉じることを目指しています。
手法
設計上の中心的な選択は、あらゆるモダリティを共有トークン語彙に離散化することで、すべての入力・出力を未改変のautoregressive transformerで処理することです。具体的には以下の通りです：
- 分子配列はSMILESとSELFIESとしてトークン化されており、両記法が含まれることでモデルは記法に依存しない化学知識を学習します。
- タンパク質配列は標準的なアミノ酸トークン化を使用します。
- 分子の3D構造は（原子タイプと幾何学トークンとして）同一の語彙空間に離散化されます。
- タンパク質構造は、ESM3/Foldseekスタイルの3Diトークンの精神に基づく構造コードブックによりトークン化され、配列位置に整合した残基ごとの離散的構造トークンが生成されます。
- 自然言語は基盤となるQwen3のtokenizerを使用します。
五つのストリームすべてが一つの語彙を共有しており、モダリティの境界は別々のheadではなく特殊な制御トークンによって区切られています。学習は通常の
\mathcal{L} = -\sum_{t} \log p_\theta(x_t \mid x_{<t})
に帰着します。ここで x_t は言語トークン、SMILESの原子、SELFIESのグループ、タンパク質残基、または構造コードブックのインデックスのいずれかです。外部エンコーダや射影アダプタが存在しないため、生成は理解と対称的となっており、モデルが読み取ることのできるモダリティはすべて出力することもできます。
バックボーンはパラメータ数1.7Bおよび4BのQwen3であり、304.4Bトークンを用いて継続事前学習されています。学習データは、言語能力の破滅的忘却を防ぐための一般テキストコーパスと、UniRef/Pfam由来のタンパク質配列データ、PDB由来のタンパク質構造トークン、ZINC/PubChemスケールの分子配列データ、分子のコンフォーマー・構造データセット、および対になった生物医学文献からなるドメインコーパスを組み合わせたものです。学習はステージ制で実施されており、初期フェーズでは各ストリームの単一モダリティ流暢性を重視し、続いてクロスモーダルペア（配列↔︎構造、構造↔︎テキスト、分子↔︎タンパク質のコンテキスト）を含む混合マルチモーダルフェーズに移行することで、明示的なアライメントlossなしにモダリティペアにまたがる条件付き分布を学習します。
統一されたトークン化により、「タンパク質構造トークン列を与えてSMILESリガンドを生成する」や「自然言語による説明を与えてタンパク質構造トークン列を出力する」といったタスクを、同一のloss内のプロンプト補完として単純に表現することが可能になります。
結果
BioMatrixはタンパク質・分子・構造・言語タスクにわたり単一のチェックポイントとして評価されています。abstractでは304.4Bトークンを用いた1.7Bおよび4Bスケールでの継続事前学習が報告されており、論文はネイティブマルチモーダリティと、凍結したESMやUni-MolエンコーダをLMに組み込んだアダプタベースのベースライン（例：LMに取り付けられたモデル）との比較という形で構成されています。モダリティマトリクス全体にわたって、4Bモデルは配列レベルのタスク（タンパク質特性予測、SMILES/SELFIESによる分子特性予測）で専門家ベースラインに匹敵するか上回ることが報告されており、さらにアダプタベースのモデルが取り込むだけで構造トークンを生成できない構造モダリティを生成できる点でも唯一のモデルとなっています。論文中で報告された具体的な比較数値には、タンパク質構造条件付き生成と構造からの分子生成タスクにおける性能向上が含まれており、アダプタベースのモデルは構造トークンの生成自体が不可能なため、BioMatrixがフルマトリクスでエンドツーエンドに評価された唯一のモデルとなっています。
すべての出力がnext-token目的関数を共有するため、サンプリング温度、top-p、制約付きデコーディングが一様に適用可能であり、SELFIESの文法制約付きデコーディングによって化学的妥当性が保証されます。著者らはこれを活用し、非条件付きおよび条件付き分子生成において高い妥当性率を報告しています。
限界と未解決の問題
いくつかの問題点を指摘する価値があります：
- 離散トークンを通じた構造的忠実性：タンパク質構造コードブックは、連続座標予測（AlphaFoldスタイル）と比較して、サブオングストロームの幾何学的詳細を失います。論文は、原子レベルの精度において構造予測器の代替を主張するものではありません。
- 分子の3Dトークン化はタンパク質の3Diスタイルトークンほど標準化されておらず、離散化の選択（原子＋幾何学的ビニング）は解像度と語彙サイズのトレードオフを伴い、コンフォーマーに敏感なタスクの性能に上限をもたらす可能性があります。
- スケール：4Bパラメータおよび304.4Bトークンの規模は、汎用LLMと比較して小さく、統一トークン設計が70B以上の規模でアダプタベースのハイブリッドに対して引き続き有利にスケールするかどうかは未解決のままです。
- クロスモーダリティ生成（例：テキスト→タンパク質構造）の評価は、配列のみのタスクに存在するような成熟したベンチマークを欠いており、そこで報告される性能向上は独自の指標に依存しています。
- 単一のlossのもとでの五つのモダリティ間の破滅的干渉は、データ混合比率によって経験的に軽減されていますが、原理的なカリキュラムやモダリティ均衡化された目的関数は未開拓のままです。
この研究の意義
BioMatrixは、「生物学的マルチモーダリティはエンコーダの集合体や射影アダプタを必要としない」という仮説の明快な検証例です。すなわち、あらゆるモダリティを共有語彙に離散化できるのであれば、タンパク質と小分子の両方について配列・構造・言語にわたる理解と生成に、標準的なdecoder-only LMで十分であるという主張です。スケーリング挙動が保たれるならば、これは現在乱立している専門的な生物基盤モデルを単一のautoregressive基盤に集約することを支持する論拠となります。
Source: https://arxiv.org/abs/2606.22138
PlanBench-XL: 大規模ツールエコシステムにおけるLLMツール使用エージェントの長期計画能力の評価
問題設定
既存のツール使用ベンチマーク（ToolBench、\tau-bench 等）は、一般的にエージェントに厳選された少数のツールを提示するか、全ツールの可視性を前提としています。しかし実際の運用環境では、エージェントはリトリーバーを通じてアクセスされる数千のツールに対して動作することを余儀なくされ、不完全な説明文、妨害要素、および明示的なエラーとして表出しない可能性のある障害モードに直面します。このような状況下での長期計画には、反復的な検索、中間的な証拠からのサブゴール推論、および選択した分岐が実行不可能になった際のランタイム再計画が必要となります。PlanBench-XL はまさにこのような設定をターゲットとしており、56種類のデータ型にまたがる1,665のツールに対する327件の小売タスクで構成され、最小解パス長 L^{*}\in\{5,6,7,8,9\} と明示的な「ブロッキング」ストレステストを備えています。
構築方法
ツールはドメインデータ型 \mathcal{D}（例：product_name、inventory_status）によって型付けされています。生成器 M_{\mathrm{gen}} は |\mathcal{D}_{\mathrm{in}}|=m、|\mathcal{D}_{\mathrm{out}}|=n として入出力スキーマ (\mathcal{D}_{\mathrm{in}},\mathcal{D}_{\mathrm{out}}) を列挙し、各ペアに対して関数シグネチャを提案し、フィルタLLM M_{\mathrm{fil}} が曖昧・冗長・非現実的な候補を除去します。最終的なライブラリ \mathcal{T} には「ノイジー」なツール——説明文に利用不可であることが記載された意味論的な準重複ツール——が追加されており、注意深いエージェントは検査によって棄却できますが、浅いリトリーバーはこれらを検索結果に含めてしまいます。
リトリーバーは双方向探索をサポートしています：前向き（現在保有している証拠からそれを入力として受け取るツールへ）と後向き（目標出力データ型からそれを生成するツールへ）の両方です。タスクは、エージェントが中間出力のそれぞれが次の検索をアンロックするような連鎖を繋ぎ合わせた場合にのみ解決可能です。デフォルトモードでは検索ノイズが加わります。ブロックモードではパスに重要なツールを破損したバリアント（明示的障害、暗黙的障害、意味論的な妨害要素、またはそれらの混合）に置き換えつつ、少なくとも一つの残存パスを通じた解決可能性を保証します。
評価プロトコル
インタラクションループは観察 \to 推論 \to 検索または呼び出し \to フィードバックであり、T_{\max}=100 ターン、検索あたりの上限 \Lambda_{\mathrm{ret}}^{\mathrm{cap}}=30 が設定されています。メトリクスはタスク完了（Accuracy、Evidence-Grounded Tool Precision）、探索行動（平均ターン数、平均探索データ型数、Search/Call比）、および実行品質（Invalid Tool Call Rate、Unused Information Retrieval Rate）を網羅しています。
主要結果
grounded accuracyによるデフォルト（ノーブロック）設定において、Gemini-3.1-Proが77.06%（EGT precision 91.47%）でトップに立ち、DeepSeek-V4-Flashが63.08%、Gemini-3.5-Flashが52.19%、GPT-5.4が51.90%と続きます。Llama-3.3-70Bは18.96%にとどまり、いくつかの中堅オープンモデル（Qwen3-8B、Llama-3.1-8B-Instruct）は0.00%を記録しています。特筆すべきことに、GPT-5.4-Miniは3.07%という低いaccuracyに対してInvalid Tool Call Rateが51.71%に達しており、これは計画の失敗ではなくスキーマ違反による失敗を示しています。トップティアのプロプライエタリモデルと70Bクラスのオープンモデルの差は30ポイントを超えており、スケールだけでは不十分であること——型付きスキーマの規律と検索へのグラウンディングが支配的であること——が示唆されます。
ブロッキング下での挙動
ベンチマークの識別力はブロッキング下で顕著に現れます。ブロック比0.8（「1パス」、実行可能な連鎖が一つのみ残存）の設定では、GPT-5.4はノーブロック時のaccuracyから40ポイント以上下落して11.36%まで崩壊します。
二つのパターンが際立っています。第一に、暗黙的障害（実行可能に見えるが誤った出力を返すツール）は明示的障害（目に見える形でエラーを返すツール）よりも大きな悪影響を与えます：エージェントは実行可能なパスから逸脱したことを判別できないためです。第二に、ブロック比が0から0.8に上昇するにつれてaccuracyは単調に低下し、GPT-5.4はスイープ全体で20ポイント以上を失い、テストされた他の三つのフロンティアモデルでも同じ傾向が再現されています。
最短の許容可能なパスを保持する場合と比較して、最長の許容可能なパスのみを保持する細粒度ブロッキングは、両者ともタスクを解決可能なままにするにもかかわらず、実質的に難易度が高くなります。
これにより特定の弱点が分離されます：エージェントは一般的な回復が苦手なのではなく、計画の延長が苦手なのです。残存する解が更に多くの逐次的なツール呼び出しを必要とする場合、軌跡のドリフトが累積します。強制継続プロンプト（誤った終了後の B_{\mathrm{enf}}\in\{0,\dots,5\}）による推論時拡張では、ノーブロック時のaccuracyのごく一部しか回復できず、すぐに飽和します——追加の計算コストは正しい分岐選択の代替とはなりません。
エラー構造
著者らの三段階エラー分析によると、失敗の原因は検索のギャップよりも選択にあります：適切なツールが検索結果セットに含まれていることが多いものの、エージェントは脱線後にそこへ戻ることができません。ブロッキング下では、これは誤解を招くが実行可能な証拠を棄却できないという形で現れます。終了行動はモデルファミリーによって異なり——あるモデルは完了を幻覚し、別のモデルは早期に中断します——が、基礎的な軌跡の破綻は共通しています。
限界と未解決の問題
このベンチマークは単一ドメイン（小売）であり、LLMが合成したツールを使用しています；検索制約のある計画の失敗が、独自のスキーマを持つ人間が作成したAPIへ転移するかどうかはテストされていません。100ターンの予算と30ツールの検索上限は余裕のある設定であるため、報告された数値はサービング制約に対して楽観寄りに近いものです。訓練時の介入（軌跡へのRL、スキーマを意識したfine-tuning）の分析は存在しないため、このギャップが根本的な能力の天井なのか、デコーディングと検索のアラインメント問題なのかは不明です。最後に、ブロックモードの設計は構造的に解決可能性を保持していますが、これは実際の回復可能性を実エコシステムの障害様式に応じて過大または過小評価する可能性があります。
なぜ重要か
PlanBench-XLは、小規模ツール設定では有能なフロンティアLLMでさえも、暗黙的障害とより長い代替パスが導入された際に計画精度の大部分を失うこと——そしてテスト時のスキャフォールディングではこのギャップを埋められないこと——を明らかにしています。これにより、ツール使用の評価はサイレントな破損下での回復と再計画を中心に再定義されます。これは現在のベンチマークよりも本番環境の条件に近い設定です。
Source: https://arxiv.org/abs/2606.22388
KaLM-Reranker-V1: 圧縮ドキュメント再ランキングのためのFast but Not Late Interaction
問題
Cross-encoder reranker（encoderベースまたはdecoderベース）は、クエリとパッセージのペアを連結 [q;p] して共同でencodingすることでスコアリングを行います。これにより、すべての候補をオンラインで \mathcal{O}(KL(|q|+n)^2 d) のコストで再処理することが強制されます。Late-interactionモデル（ColBERTスタイル）はencodingを分離しますが、インタラクションをトークンレベルのMaxSimに限定するため、深いcross-attentionのセマンティクスが失われ、パッセージトークンごとに1つのベクトルが必要となりストレージが肥大化します。KaLM-Reranker-V1はその中間を狙います。すなわち、パッセージの表現は (i) 事前計算可能かつ再利用可能であり、(ii) コーパス規模のストレージのために圧縮可能であり、(iii) スコアリング時にクエリと豊かにインタラクションできるべきです。
手法
このモデルはT5Gemma2からininitializeされたencoder–decoderであり、3つのスケール（270M/270M、1B/1B、4B/4B有効）で提供されます。encoderはオフラインで各パッセージを \mathbf{H}_p = \mathrm{Enc}(p)\in\mathbb{R}^{n\times d} にマッピングするために使用されます。decoderはシステム命令、タスク命令 I、およびクエリ q を条件として、キャッシュされた \mathbf{H}_p にcross-attentionを通じてアクセスします。
機械的には、decoderはkey/value側でdecoderの状態とencoder出力を連結することにより、self-attentionとcross-attentionを単一のブロックにまとめます。
\mathbf{Q}=\mathbf{X}\mathbf{W}_Q,\quad \mathbf{K}=[\mathbf{X};\mathbf{H}_p]\mathbf{W}_K,\quad \mathbf{V}=[\mathbf{X};\mathbf{H}_p]\mathbf{W}_V,
causal-plus-crossマスク \mathbf{M}\in\mathbb{R}^{m\times(m+n)} を用います。関連性スコアは、最初の予測位置における2つのラベルトークンのlogitに対するsoftmaxです。
\mathrm{score}(q,p)=\frac{\exp(z_{\mathrm{yes}})}{\exp(z_{\mathrm{yes}})+\exp(z_{\mathrm{no}})}.
Matryoshka Embedding Pooling（MEP）。 コーパス全体で \mathbf{H}_p を保存するコストを削減するため、MEPは連続する r トークンごとにmean-poolingを行います。
\mathbf{H}_p^{(r)}[j] = \mathrm{MeanPool}\big(\mathbf{H}_p[(j-1)r+1:\min(jr,n)]\big),
これにより \lceil n/r\rceil トークンが得られます。学習では \mathcal{R}=\{1,2,4,8,16,32\} 上のSFT lossのMatryoshkaスタイルの総和を最適化します。
\mathcal{L}_{\mathrm{sft}}(I,q,p,l,\mathcal{R})=\sum_{r\in\mathcal{R}}\lambda_r\Big(-\log\frac{\exp(z_l^{(r)})}{\exp(z_{\mathrm{yes}}^{(r)})+\exp(z_{\mathrm{no}}^{(r)})}\Big),
これにより、1セットの重みで推論時に複数の圧縮率をサポートできます。knowledge-distillationフェーズでは、より強力な教師rerankerを使用してソフトラベル y\in[0,1] を提供し、binary cross-entropyで最適化することで、retrieval データセットで一般的な偽のhard-negativeノイズを軽減します。
計算量
L 層のTransformerを持つ同サイズのcross-encoderベースラインと比較すると、KaLMのオンラインdecoderはおよそ L/2 層です（残りはオフラインのencoder）。K 候補に対するオンラインコストは
\mathcal{O}\!\left(\tfrac{L}{2}K\Big(|q|(|q|+\lceil n/r\rceil)d+(|q|+\lceil n/r\rceil)d^2\Big)\right),
であり、joint cross-encoderの \mathcal{O}(KL(|q|+n)^2 d + KL(|q|+n)d^2) と比較されます。典型的な |q|=32、n=1024、r=16、d=640、L=36 の場合、これはおよそ1桁の削減となります。2次項 (|q|+n)^2 は n/r=64 のもとで |q|(|q|+n/r) に縮小されます。
結果
BEIRサブセット（13タスク、KaLM-Embedding-V2.5からtop-100を再ランキング、平均nDCG@10は53.78）において：
- KaLM-Reranker-V1-L（4B）：62.87 avg.、相対オンラインコスト 43.7× で、Qwen3-Reranker-4B（63.50、コスト 236.8×）やQwen3-Reranker-8B（65.11、コスト 539.7×）と比較されます。KaLM-LはQwen3-4Bに対して約0.6 nDCGを譲る一方、オンラインコストは約5.4×低く、8Bモデルに対しては約2.2 nDCG差でコストは約12×低くなります。
- KaLM-Reranker-V1-S（1B）：60.01 avg.、コスト 6.9× で、bge-reranker-large（0.6B、51.86、コスト36.3×）やmxbai-rerank-large-v2（1.5B、60.32、コスト79.2×）をはるかに少ない計算量で上回ります。
- bge-reranker-v2-gemma（2.5B）はコスト81.3×でわずか54.49にとどまっており、KaLM-Lはオンラインコストが約半分でありながら+8.4 nDCGを達成しています。
タスクごとの数値を見ると、FiQA（KaLM-L 62.63 vs. Qwen3-4B 56.69）やQuoraRetrieval（91.00 vs. 88.40）などのretrieval重視タスクでギャップが最も大きく、KaLM-LはArguAna（74.39 vs. 79.85）やClimate-FEVER（38.56 vs. 49.92）では劣っており、一部のドメインでは依然として完全な双方向joint encodingが有益であることを示唆しています。
LMEB-Dialogueでは、KaLMのバリアントが精度とオンラインコストのParetoフロンティアを占めています。これは、メモリ文書が多くのターンにわたって再利用されるため、事前キャッシュされたパッセージ表現が最も重要なシナリオです。
限界とオープンな問題
- 学習コーパスは「主に中国語と英語」であり、MIRACLの比較は多言語学習を行っていないベースラインに限定されているため、多言語に関する主張は部分的なものにとどまります。
- 4Bモデルは絶対nDCGでは4B/8Bのcross-encoderに劣ります。encoderではなくdecoderをスケールさせることでこのギャップが埋まるかどうかは未検証です。
- MEPは均一なmean poolingを使用しています。コンテンツを考慮したpooling、学習によるダウンサンプリング、またはクエリ条件付きpoolingがコスト/品質のフロンティアをさらに押し広げる可能性はありますが、本論文では固定の r に留まっています。
- d=640 における \mathbf{H}_p^{(r)}\in\mathbb{R}^{\lceil n/r\rceil\times d} のストレージは、スカラーのBM25や単一ベクトルの dense indexと比較してまだ相当大きく、コーパス規模のコスト（さまざまな r におけるバイト数/パッセージ）は直接表として示されていません。
- 「最初の予測位置」でのyes/no読み出しは単一スカラーですが、本論文では探索されていない、より豊かなスコアリングヘッドをアーキテクチャは許容します。
なぜこれが重要か
FBNLはrerankerの設計空間における明確なアーキテクチャ上の位置づけです。インタラクションの仕組みとしてcross-attentionを維持しながら（ColBERTとは異なり）、パッセージごとにencoder コストを一度だけ支払い（標準的なcross-encoderとは異なり）、Matryoshka poolingにより1つのモデルで複数のコスト/品質の動作点を提供します。nDCGがほぼ同等の水準でオンラインコストが5〜10×削減されることから、大規模コーパスのreranking展開における実用的なデフォルト手法となる可能性があります。
Source: https://arxiv.org/abs/2606.22807
World Action Models: A Survey
本サーベイは、World Action Models（WAMs）を具体化された予測型アクションモデルの独自クラスとして形式化し、しばしば混同される隣接概念——Vision-Language-Action（VLA）ポリシー、ビデオワールドモデル、アクションを根拠とするビデオ生成器——から明確に区別しています。定義上の要件は機械的なものであり、予測された将来の観測がアクションパス上に留まる必要があります。すなわち、カスケード（predict-then-act）、アクションスコアリングのロールアウト、または将来とアクションの同時予測のいずれかを通じて実現されます。
VLAおよびビデオワールドモデルとの境界
著者らはVLAの目的関数
\mathcal{L}_{\text{VLA}}(\theta)=\mathbb{E}_{(o,l,a)}\!\left[-\log p_\theta(a\mid o,l)\right]
とWAMの要件を対比させることで定義を確立しています。式（1）はモデルがo_{t+1}を予測することを一切要求しません。RT-2、OpenVLA、および\pi_0/\pi_{0.5}/\pi_{0.7}ファミリーはいずれも現在の状態のみからアクションを生成します。モデルがWAMとなるのは、予測された将来が「アクションの生成・選択・検証に寄与する」場合に限ります。逆に、素のビデオワールドモデルはその生成したカップを持ち上げる映像がコントローラの意図する軌道と結びついていないため、WAMから除外されます。
三つの設計思想
このタクソノミーは、訓練アーキテクチャではなく、推論のフォワードパスのどこでアクション信号が根拠づけられるかによってWAMを分類します。
- Render-and-Decode：ビデオ生成器をピクセルまで実行し、その後アクションを抽出する（UniPi、AVDC、VLP、Dreamitate、Gen2Act）。カスケード型の変形（NovaFlow、Dream2Flow、TC-IDM）は、レンダリングされた将来をフロー、ツール軌道、または逆ダイナミクスのコマンドに変換します。事前訓練済みのビデオdiffusionに後付けしやすい反面、制御の前に生成コストを全額支払う必要があります。
- Latent-Only：デコーダを迂回するビデオ由来の予測器であり、アクションは中間のlatent、部分的にデノイズされた特徴、フロー、またはバリューマップから取得します。
- Video-Generation-Free：LLM/VLMトークン空間での予測、JEPAのembedding、凍結されたビジョン基盤特徴に対する回帰、またはコンパクトな基板上での非ビデオdiffusionを使用します。
重要なことに、この軸はカスケード対同時予測の区別と直交しています。Latent-OnlyのWAMはそのどちらにもなりえますし、Render-and-Decodeについても同様です。
統一された数理的対象
すべてのWAMは、等しい長さHの将来状態ウィンドウとアクションチャンクに対するパラメータ化された条件付き同時分布として記述されます。
p_\Theta\!\left(s_{t+1:t+H},\,a_{t:t+H-1}\mid o_{\le t},\,a_{<t},\,l\right). \quad (8)
基板空間\mathcal{S}——インターフェースエンコーダ\phi:\mathcal{O}\to\mathcal{S}の像——が主要な設計変数です。ピクセルを基盤とするWAMはデコードされたフレームまたはVAE/VQグリッドを公開し、特徴量WAMは隠れトークン（凍結されたSSL教師ターゲット、VLMの将来トークンブロック）を公開し、幾何プリミティブWAMはフロー、点群、または深度を公開します。四軸の構造は、予測基板・アクション結合・バックボーンファミリー・展開レジームとなります。
アクション結合：事後予測 → 生成中 → 同時予測
アクション結合軸は、アクションが結合するタイミングがどれだけ早いかという点でほぼ単調な進行として提示されています。
- 事後予測デコーディング：将来全体を生成してから制御を回収する（UniPi、AVDC、VLP；カスケード拡張のNovaFlow、Dream2Flow、TC-IDM；音響向けのAudio-WM）。
- 生成中の制御：This&Thatはジェスチャー座標を条件としてdiffusionに与え、ARDuPはコンディショニングを活性領域に限定しlatentからデコードし、CoVARとVAGはブリッジattentionやステップ同期デノイズを用いてビデオデノイジングと並列して専用のアクションブランチを実行し、プールされたビデオコンテキストのみを受け渡します。
- 同時予測（Joint）：UWM、UVA、F1、Motus、Cosmos Policyは単一バックボーン上で基板予測とアクションヘッドを共有しています。AdaWorldはすべての中で最も早期に結合します。
五つのコア特性とそのトレードオフ
WAMはinteractability（相互作用可能性）、causality（因果性）、persistence（持続性）、physical plausibility（物理的妥当性）、generalization（汎化性）を満たす必要があります。このサーベイではこれらが相互に結合していることを明示しています。diffusionスタックの早い段階にアクションを移動させることでinteractabilityを改善すると、一般的にレイテンシやメモリが増大します。長い時間軸にわたってpersistenceを維持しようとすると、忠実度とのトレードオフが生じます。WAMの設計は、制御ループのバジェットを考慮しながらこれらのトレードオフを管理することに帰着します。
データと評価
訓練データは、スケール・ラベル忠実度・エンボディメント適合度のトレードオフによって五つのグループに分類されます。ロボットのテレオペレーション（Open X-Embodiment、RoboMIND、RoboSet、Human2Robot——クリーンなアクションラベルだがコストが高い）、スクリプト/ランダムなロボット収集（RoboNet——精度よりスループット重視）、そして人間動画、シミュレーション、ウェブスケールの動画（後続で説明）です。評価は視覚的忠実度、閉ループ成功率、物理的妥当性、コストを同時に追跡する必要があり、レンダリング品質メトリクスは制御ループの問いに対して明示的に不十分とされています。
未解決の課題：もっと夢を見るか、もっと行動するか？
最も重要な未解決の問いは忠実度とレイテンシのカーブです。一方の陣営はビデオ生成を蒸留または省略します。S-VAMはビデオdiffusionを幾何的/意味的特徴に蒸留し、Fast-WAMは推論時に将来ビデオブランチを除去し、GigaWorld-Policyはattentionをマスクして将来ビデオをスキップ可能にし、X-WAMはビデオのデノイジングが完了する前にアクションのデノイジングを終了させます。もう一方はイマジネーションをループに残し続けます。DreamZeroはカスタム最適化を通じて大型ビデオバックボーンを閉ループで動作させ、CosmosPolicyはモデル/バリューへの反復クエリを使用し、NovaPlanはフロー抽出前にビデオを生成します。著者らは、目標はモデルを小さくすることではなく、期待されるアクション価値によって実行時バジェットを配分する制御可能な忠実度-レイテンシカーブであると主張しています——接触付近、不確実性、または不可逆エラーの近くでより多くの計算を行います。DreamAvoid、SANTS、NoiseGate、HarmoWAMはタスクフェーズまたはデノイジング状態からこのトリガーを学習しますが、バイナリな「実行かリプラン」の決定では不十分です。未解決の問いは、残りの時間軸のどれだけを再生成するかという点です。
主流のビデオ生成との収束点はセクション4.2の基板レベルにあります。ビデオ生成器（Cosmos-Transfer1、cosmos-predict2）はアクションコンディショニングを追加し、WAMはビデオバックボーンからlatent/JEPA基板を借用しています。ビデオ目的関数で訓練された単一バックボーンであって、そのアクションパスが推論時にどれだけ実行するかを選択する——そのような設計は、この分野がまだ生み出していないものとして指摘されています。
なぜこれが重要か
単一の数理的対象（式8）と「推論パスのどこでアクションが根拠づけられるか」を鍵とする三方向のタクソノミーを課すことで、本サーベイは断片化した文献を比較可能な設計空間へと変換しています。忠実度-レイテンシのフレーミング——および、ビデオ訓練目的関数がレンダリングされたテスト時の予測よりも重要であることが多いという経験的観察——は、次世代の具体化された基盤モデルが何を最適化すべきかを具体的に示しています。
Source: https://arxiv.org/abs/2606.20781
Grouped Query Experts: GQA Self-Attention上のMixture-of-Experts
問題設定
標準的なmulti-head attentionは、トークンが実際にどれだけの処理を必要とするかに関わらず、すべてのH個のheadをすべてのトークンに適用します。長いコンテキストではこの問題が二重に深刻になります。attention計算コストはhead当たりO(n^2)でスケールし、トークンあたりのhead数はアーキテクチャによって固定されているからです。Grouped-query attention (GQA)は、複数のquery headのグループ間でKV headを共有することでKV側をすでに削減していますが、query側は依然として密なままです。すなわち、すべてのグループのすべてのquery headがすべてのトークンに対して計算されます。本論文は、query側を条件付きスパースにすること——query head上のmixture-of-experts——が、GQAのKV-cacheの利点や下流タスクの品質を損なうことなく実現できるかどうかを問います。
手法
GQEはGQAのグループ構造をそのまま維持し、各グループ内にルーターを挿入して、トークンごとにtop-k個のquery headのサブセットを選択します。KV headは密なままです。
具体的には、H個のquery headをG個のグループに分割し（各グループは1つのKV headを共有するH/G個のquery headを持つ）、密なGQAの計算は次のようになります。
\text{GQA}(X) = \text{Concat}\big(A_1(X), \dots, A_H(X)\big) W_O,
各A_hはそのグループの共有されたK_g, V_gを使用します。GQEはこれをトークンごと・グループごとのルーターr_g(x) \in \mathbb{R}^{H/G}に置き換え、グループg内のtop-k個のquery headを選択します。
\mathcal{E}_g(x) = \text{TopK}_k\big(r_g(x)\big), \qquad A_h^{\text{GQE}}(x) = \mathbb{1}[h \in \mathcal{E}_g(x)] \cdot A_h(x).
重要な点として、K_g, V_gは変更なく計算・キャッシュされます——すなわち、KV-cacheのフットプリントおよびKV射影のFLOPsはGQAと同一です。アクティブなquery head射影と、対応するQK^\topおよびsoftmax重み付きVの積のみがスパース化されます。出力射影W_Oは、そのトークンに対してexpertが選択されなかったスロットにゼロが入った連結結果に乗算されます。
図中の対比は注目に値します。以前のattention上のMoE研究はhead全体またはKVグループ全体をrouteしており、それによりGQAのKV共有が壊れるか、キャッシュが乱されます。GQEはroutingを意図的にGQAグループ内に限定しているため、各expertのqueryは密なベースラインと同じK_g, V_gに対してattentionを行います。これによりGQEは事実上ドロップイン置き換えとなります。追加されるのは小さなルーターとtop-kマスクのみです。
設定と結果
すべてのアブレーションには、FineWeb-Eduの固定された30Bトークンサンプルで学習した2億5000万パラメータのモデルを使用し、シーケンス長2048、バッチサイズ105万トークン、fused AdamW（\beta_1=0.9, \beta_2=0.95）、ピークLR 5\times 10^{-4}のWSDスケジュール、3Bトークンのウォームアップ、weight decay 0.1、BF16、およびlossスパイクを処理するためのZClipを使用しています。ベースラインはKV head数8のGQA（したがってG=8）であり、GQEは同じ8グループのレイアウトを使用し、密なベースラインのquery headがグループごとのexpertプールとして機能します。主要な設定ではk=1であり、各グループはトークンごとに1つのquery headをアクティブにします——プールサイズがグループあたり2である場合（概要に「トークンあたり半数のquery head」と記述されている設定）、密なGQAと比べてアクティブなquery headが半減します。
head次元、tokenizer、optimizer、スケジュール、データはすべての実験で一定に保たれているため、差異はhead幅や学習計算量ではなくroutingの選択を反映します。
各バリアントの学習lossカーブは密なGQAベースラインに近く追従しており、以前のattention側MoEの試みを悩ませてきた発散やrouting collapseの兆候は見られません。下流タスクでは、著者らは単一の代理指標ではなくHellaSwag、PIQA、ARC-Easyを報告しています。
HellaSwagでは、最終的なGQEモデルはトークンあたり半数のquery headをアクティブにしているにも関わらず、学習全期間を通じて密なGQAベースラインと同等の精度を達成しています。30Bトークン・2億5000万パラメータスケールにおいてアクティブなquery head計算量を半減させながら下流精度でパリティを達成するという論文の主張は、このカーブと対応するPIQAおよびARC-Easyの数値（Table 2に報告）によって支持されています。スループットはコンテキスト長の関数として報告されており、attentionがFLOPバジェットを支配する長いコンテキストで節約が最大となります。
限界と未解決の問題
評価は単一スケール（2億5000万パラメータ）および単一トークンバジェット（30B）で行われています。10億以上のスケールでパリティが成立するかは不明であり、そのスケールではMLPと比べてattentionの相対的コストが縮小し、router起因のロードバランシングの病理が一般的に顕在化します。論文のk=1設定がquery headを半減させるのは、各グループにexpertがちょうど2つある場合に限られます。グループあたりのexpertプールサイズに対するスケーリング則は特徴付けられていません。提供されたセクションには補助的なロードバランシングlossの定式化が記載されておらず、実際のwall-clock高速化はスパースなtop-k headディスパッチを現代のGPUカーネル上で効率化できるかどうかに依存します（密なattentionカーネルは高度にチューニングされており、スパースhead変種は通常定数倍の性能低下が生じます）。最後に、KVパスは密なままであるため、GQEは長いコンテキスト推論のメモリを支配するKV-cacheボトルネックの解決には寄与しません。
重要性
GQEは、本番LLMがすでに依存しているGQAのKV共有契約を壊すことなく、attentionのquery側に条件付き計算を適用するクリーンな方法を示しています。パリティの結果がより大きなスケールでも成立すれば、既存のGQA/MQAスタックと競合するのではなく、それと組み合わせられる形で、attention FLOPsをほぼコストなく削減する手段が提供されます。
Source: https://arxiv.org/abs/2606.20945
EvoEmbedding: 長文脈検索とエージェント記憶のための進化可能な表現
問題
Dense retrieverは各セグメントを独立してエンコードします：\mathbf{v}_t = f(x_t)。これはエージェント記憶や長文脈パーソナライゼーションとは根本的にミスマッチです。これらの場面では、クエリに対して正しいターゲットが、数百セグメントにわたって進化してきた会話の状態に依存するためです。同じクエリ（「現在の住所は何ですか？」）であっても、どのセグメントがその前に来たかによって、異なる事実を検索すべきです。既存のアプローチは、(a) コンテキストをエンコーダに連結することでコストを爆発させ、コンテキストウィンドウを超えてしまうか、(b) 明示的なLLM駆動のサマリゼーションを必要とする外部メモリパイプライン（Mem0、A-Mem、MemoryOS）を構築し、大量のトークンオーバーヘッドを支払うか、のいずれかです。
手法
EvoEmbeddingは再帰的な潜在メモリ \mathbf{M}_{t-1} \in \mathbb{R}^{C \times D} を維持し、セグメントがストリーム入力されるたびに更新されます。また、すべての embedding をそのメモリに条件付けます。2つのLoRAアダプタが同じベースLLMを共有します：
\mathbf{\tilde{M}_t} = \pi_{\theta_m}(x_t, \mathbf{M}_{t-1}), \qquad \mathbf{v}_t = \pi_{\theta_r}(x_t, \mathbf{M}_{t-1}).
両パスは、前のメモリのプロジェクションをセグメントトークンの先頭に付加します：\tilde{x}_t = [m_{in};\, x_t;\, r_l]。ここで r_l はメモリ進化のための K=16 個の学習可能トークンであり、検索時には <EOS> に置き換えられます。メモリパスは最後の K 個の隠れ状態を読み取り、検索パスは <EOS> の隠れ状態を読み取って D_{emb}=1024 へとプロジェクションします。
潜在メモリキュー。 M+のようなレイヤーごとのKVキャッシュの代わりに、EvoEmbeddingは C = L \times K = 512 トークンのFIFOキューを保持します：
\mathbf{M}_t = \text{Queue}(\mathbf{M}_{t-1},\, f_m(\mathbf{\tilde{M}_t})).
有界ループ L は重要です。各履歴メモリは再帰的に最大 L 回しか再エンコードされないため、著者らは、これが先行する再帰エンコーダ研究で記録されている表現崩壊を防ぎ、コンテキスト長に関するカリキュラム学習の必要性を排除すると主張しています。メモリのフットプリントはほぼエンコードされた画像1枚分です。
動的セグメントバッチング。 逐次的なセグメント処理は明らかな効率上のボトルネックです。著者らは、連結長が2048トークン以下に収まるように k 個の連続セグメントをバッチ処理し、それらに同じ \mathbf{M}_{t-1} を共有させます：\mathbf{\tilde{M}}_{t:t+k} = \pi_{\theta_m}(x_{t:t+k}, \mathbf{M}_{t-1})。これは技術的には近似（バッチ内のセグメントはお互いの中間メモリ更新を見られない）ですが、報告によると3.8倍の学習高速化をもたらします。メモリはバッチごとに1ステップしか進まず、これがこのトリックの主要な制限です。
EvoTrain-180K。 コンテキスト長が最大10,270トークン、サンプルあたり最大246セグメント（平均20.57）を持つ184,137インスタンスから構成されます。各インスタンスには平均19.45個のcontrastive negativeがあり、クエリは短め（平均15.59単語）です。サンプルの52.9%は512トークン未満ですが、長いテールも存在します——この混合長設計が、10Kトークンでの学習からPersonaMMEでの128Kトークン推論への汎化を可能にしています。
結果
評価は10のベンチマークにわたります：検索（ESG-Reports、MLDR、CovidQA、PeerQA、QASPER）、会話型メモリ検索（REALTALK、LoCoMo、LongMemEval）、生成・パーソナライゼーション（LoCoMo、LongMemEval、PersonaMem-32K、PersonaMME-32K/128K）。ベースラインには、Qwen3-Embedding、BGE-M3、multilingual-e5、BM25に加え、エージェント型メモリシステムであるMem0、LightMem、A-Mem、MemoryOS、およびreranking パイプライン（Qwen3-Reranker-4B）が含まれます。
アブストラクトおよびFigure 1/2からの主要な主張：
- EvoEmbeddingファミリー（0.8B、2B、4B）は、全10ベンチマークにわたってより大きな静的 embedding モデルを上回り、長期パーソナライゼーションのような動的コンテキストタスクで最も大きなマージンを示します。
- EvoEmbedding-4Bを使用した標準的なRAGは、LongMemEvalにおいて特化型メモリアーキテクチャ（Mem0、LightMem、A-Mem、MemoryOS）を上回りつつ、明示的なメモリ構築にトークンをまったく消費しません——メモリはプロンプト側のテキストではなく \mathbf{M}_t の中に存在します。
- 最大約10Kトークンのコンテキストのみで学習されたモデルが、128KトークンのPersonaMMEに汎化しており、これは混合長分布と有界ループ保証によるものとされています。
- セグメントバッチングにより、学習が3.8倍高速化されます。
デフォルト設定：C=512、K=16、D_{emb}=1024、8x H800。
限界と未解決の問題
本論文は（提供されているセクションにおいては）、真に関連するセグメントが L メモリステップよりも古い場合に性能がどの程度劣化するかを定量化していません——FIFOはハードな忘却メカニズムであり、500以上のセグメントを含む会話に対して512個の潜在トークンは厳しい上限です。セグメントバッチングの近似は、学習中のメモリ更新粒度を実質的に粗くします；k と最終的な検索精度のトレードオフ曲線はここでは示されていません。再帰的推論は独立したセグメントの並列 embedding を不可能にし、これは大規模コーパスのコールドスタートインデックス作成において問題となります。最後に、評価にはジェネレータとしてQwen3-30B-A3B、ジャッジとしてGPT-4o-miniが使用されており、ジャッジへの依存はメモリシステム比較においてよく知られた交絡要因です。
なぜこれが重要か
embedding をアイソレートされたチャンクの関数としてではなく、ストリーミング状態の関数として扱うことは、エージェント記憶に対して正しいアーキテクチャ上の方針です。EvoEmbeddingは、有界潜在キューとデュアルLoRAアダプタの組み合わせが、より大きな静的エンコーダと明示的なメモリ構築パイプラインの両方を、それらのトークンコストを支払うことなく上回るのに十分であることを示しています。有界ループの主張がより大きな L においても成立するならば、これはRAGベースのメモリエージェントの embedding レイヤーに対して実用的なドロップイン代替品となります。
Source: https://arxiv.org/abs/2606.21649
Hacker News Signals
Moebius: 0.2Bの画像inpaintingモデルが10Bレベルの性能を実現
Moebiusは、自身の50倍のサイズを持つモデルと競合する品質を主張するコンパクトな画像inpaintingモデルです。中核となる技術的貢献は、構造予測とテクスチャ合成を分離する二段階アーキテクチャです。第一段階では、小型のtransformerがマスク領域の粗い構造的補完を予測し、周囲のコンテキストを条件として使用します。第二段階では、diffusionベースの精細化ネットワークがテクスチャの詳細を補完し、生のピクセルコンテキストのみに頼るのではなく、構造予測を conditioning signalとして利用します。
重要な洞察は、大型のinpaintingモデルがその容量の大半を、分解可能な構造とテクスチャの共起統計の学習に費やしているという点です。テクスチャ段階に明示的な構造的事前情報を与えることで、モデルはピクセルのみから幾何情報を推定するための深い表現を必要としなくなります。構造予測器は潜在空間上のmasked autoencoding objectiveで学習され、テクスチャdiffusionモデルは構造tokensと可視画像コンテキストの両方を条件とする標準的なDDPMスタイルのネットワークです。
Places2およびCOCO inpaintingタスクにおけるベンチマーク比較では、FIDおよびLPIPSスコアが複数の5B〜10Bパラメータのベースラインと同等またはそれ以上の結果を示しています。0.2Bパラメータという規模により、コンシューマ向けハードウェア上でのインタラクティブな使用にも十分な速度を実現しています。
興味深い未解決の問題は、大規模モデルとの性能差がどの程度真に縮まっているのか、あるいはベンチマーク特有の飽和現象によって見かけ上閉じているだけなのかという点です。Inpaintingの評価指標は、複雑なシーンにおける意味的一貫性を捉えることが難しいことで知られており、プロジェクトページの厳選された定性的結果はシンプルな背景のものが多く見受けられます。強い遮蔽を受けた顔や強いパースペクティブ制約を持つ密集した都市シーンへの汎化については、十分な評価が行われていません。
なぜ重要か
構造的生成とテクスチャ生成を分離するというアーキテクチャの因数分解が、生のパラメータスケールの代替となり得ることを示しており、生成画像ツールのオンデバイス展開に対する実用的な示唆を持ちます。
Source: https://hustvl.github.io/Moebius/
VibeThinker: 新規SFT+GRPOによりOpus 4.5をreasoningで上回る3Bパラメータモデル
VibeThinkerは、2段階パイプラインを用いて3Bパラメータのreasoningモデルを学習します。具体的には、厳選されたchain-of-thoughtデータセットに対するsupervised fine-tuning（SFT）を第1段階とし、続いてGroup Relative Policy Optimization（GRPO）を第2段階として採用しています。GRPOはPPOの変形版であり、同一プロンプトに対してサンプリングされた複数の応答グループを基準にadvantageを計算することで、独立したvalue networkを不要とします。
GRPOのobjectiveは、1プロンプトあたりK個の補完をバッチとして、報酬を正規化します。advantageは A_i = (r_i - \bar{r}) / \sigma_r として計算され、ここで r_i は補完 i のスカラー報酬、\bar{r} はグループ平均、\sigma_r は標準偏差です。これによりcriticの学習が不要となり、メモリオーバーヘッドが大幅に削減され、小規模パラメータ数においてもRL fine-tuningが現実的に実施可能となります。
SFTステージでは、数学的reasoningと論理パズルデータをフィルタリングして組み合わせたデータを使用し、中間ステップが検証可能な例を優先しています。GRPOステージでは、process reward modelを使わず結果ベースの報酬（最終回答の正解性）を用いることで、パイプライン全体をシンプルに保っています。
報告された結果によれば、AIME 2024、MATH-500、LiveCodeBenchにおけるスコアは複数のタスクでClaude Opus 4.5を上回っています。ただし、比較手法については精査が必要です。フロンティアモデルは通常はるかに多くの推論計算リソースで評価されており、また小規模モデルにおけるベンチマークデータとトレーニングデータの重複問題は依然として懸念事項です。
アーキテクチャのベースはアブストラクト内で明確に示されておらず（論文では「3B reasoning backbone」と記載されています）、これにより再現が困難になっています。Opusをreasoningで上回るという主張は、狭いベンチマーク範囲においては妥当性があり得ますが、評価の幅は限定的です。
なぜこれが重要か
GRPO ベースのRL fine-tuningが強力なreasoningをサブ5Bモデルへ低コストで転移できることを示しており、エッジデプロイメントや、フロンティアモデルのAPIコストを負担できない研究者にとって重要な知見となります。
Source: https://arxiv.org/abs/2606.16140
Claude Codeの「Extended Thinking」出力に含まれるテキストは本物ではない
Patrick McCarnaは、Claude Codeがユーザーに提示するextended thinkingトークンが、モデルの実際の内部推論プロセスを表していないと主張しています。この投稿は特定の技術的観察に基づいています。Claude CodeがExtended Thinkingモードで動作する際、AnthropicのAPIは最終応答とともにthinkingブロックを返します。主張の核心は、このブロックが中間的な計算の生のトランスクリプトではなく、事後的または制約された生成の産物であるというものです。つまり、因果的なトレースではなく、実質的には事後的な合理化ナラティブにすぎないということです。
示されている証拠は行動的なものです。thinkingテキストが最終的な回答と矛盾することがあり、応答が正しい結論を出す前に誤った結論へ向けて推論しているように見えることがあり、また制約のないスクラッチパッド生成とは一致しないスタイルの均一性を示します。さらにアーキテクチャ上の論点として、transformerの推論はトークンごとに単一のforward passで行われるため、テキストが抽出される別個の「推論基盤」は存在しないという点も挙げられています。thinkingトークンは、異なるシステムプロンプトやサンプリング設定のもとで、応答と同じ重みおよびサンプリングプロセスから自己回帰的に生成されます。
これはchain-of-thoughtについて公に知られていることと一致しています。CoTトークンはプロンプトのコンディショニング効果を通じて下流の精度を向上させますが、機械的に特権化された計算のトレースではありません。モデルは、人間のメタ認知に対応するいかなる意味においても「自分の作業を確認している」わけではないのです。
Claude Codeを使用する開発者にとっての実際的な含意は、thinkingブロックを監査可能な推論ログとしてではなく、モデルの不確実性やアプローチに関するソフトなヒントとして扱うべきだということです。thinkingブロックの出力に基づくデバッグは、そのブロックがエラーが発生した理由を明らかにするのではなく、誤った答えを合理化している場合に誤解を招く可能性があります。
なぜこれが重要なのか
開発者ツールに組み込まれたAI解釈可能性の前提に直接関連します。生成された合理化と因果推論のトレースを混同することは、誤ったデバッグ戦略につながります。
Source: https://patrickmccanna.net/the-text-in-claude-codes-extended-thinking-output-is-not-authentic/
GLM-5.2 – ローカルでの実行方法
GLM-5.2はTHUDMによるGLMシリーズの最新リリースであり、Unslothのドキュメントでは量子化によるローカルデプロイメントについて解説しています。ここでの技術的な核心はモデルアーキテクチャそのものではなく、推論スタックにあります。
Unslothのアプローチでは、GLM-5.2に対して4ビットおよび8ビットのGPTQ/GGUF量子化を適用し、VRAMの必要量を大幅に削減します。GLMアーキテクチャは特定のprefix位置で双方向 attention を使用しており（初期のGLM設計から継承）、これにより純粋な因果モデルと比較して素朴な量子化が複雑になります——attention maskが量子化のキャリブレーションデータと非自明な形で相互作用するためです。Unslothはこれに対し、モデルの実際の使用パターンを代表するmixed-prefixシーケンスを用いてキャリブレーションすることで対処しています。
ドキュメントでは、ollama、llama.cpp、およびbitsandbytesバックエンドを用いたtransformersライブラリによる直接PythonInferenceを介したセットアップについて説明しています。GLM-5.2はrotary positional embeddingの変種と、Llamaファミリーモデルで一般的な標準BPEセットアップとは異なる専用トークナイザーを使用しているため、モデルの読み込みには汎用トークナイザーではなくTHUDMのトークナイザーが必要です——これはコミュニティのデプロイメントにおいて無症状の障害を引き起こす一般的な原因となっています。
GLM-5.2は、強力な中英バイリンガル能力と、そのサイズクラスに対して競争力のあるコーディングbenchmarkスコアで注目されています。量子化された4ビット版は、24GBの一般向けGPU上で、インタラクティブ利用に十分なスループットで動作すると報告されています。
主な未解決の問題は、GLM-5.2のGGUF変換において非標準的なattentionパターンのためにllama.cppへのパッチが必要だったことであり、ドキュメント公開時点ではそれらのパッチはまだアップストリームにマージされていないため、ユーザーは特定のフォークを追跡する必要があります。
なぜこれが重要か
非Llamaアーキテクチャにおける実用的なデプロイメントの障壁は依然として高く、このドキュメントはattentionに変形を加えたモデルをローカルで実行するために必要な具体的なパッチ適用とキャリブレーションの手順を明らかにしています。
Source: https://unsloth.ai/docs/models/glm-5.2
Qwen 3:0.6BのようなローカルなLLMを質問分類のためにfine-tuningして良好な結果を得る
この投稿では、Qwen 3 0.6Bを分類タスク（教育的な質問をカテゴリにルーティングする）向けにfine-tuningした具体的な実験を記録しています。セットアップとしては、Unslothを用いたメモリ効率の良いLoRA fine-tuningを採用し、rank-16 adapterでattention projection matrixをターゲットにしています。これにより、学習可能なパラメータ数は総重量の1%未満に抑えられています。
学習データは手動で構築された約500〜1000件のラベル付き事例であり、これは制約された分類問題に対してLoRA fine-tuningが安定した収束を得るために通常必要とされる量の下限に当たります。著者は保留事例に対してほぼ完璧な精度を報告しており、カテゴリ定義が明確な低カーディナリティの分類タスクであれば、これは十分にあり得る結果です。
技術的に興味深い観察は、0.6Bモデルはzero-shot分類性能が低いにもかかわらず、狭い問題に対しては少量のタスク固有のfine-tuningに対しても良好な応答を示すという点です。これは、小規模モデルが分類に必要な十分な容量を持ちながらも、in-contextでの instruction following が信頼性高く機能しないという仮説と一致しています。LoRA fine-tuningは、決定境界を直接調整することによって、instruction-followingのボトルネックを本質的に回避します。
この投稿ではさらに、constrained decodingを介した構造化出力（JSONの強制）が一貫性をさらに向上させたとも述べており、これは実用上有益な指摘です。分類タスクにおいては、fine-tuningとgrammar-constrained generationを組み合わせることで、モデルが正しい答えをパース不可能なフォーマットで出力してしまうというクラスのエラーを排除できます。
制限事項としては、評価が非公式なもの（厳密な分割による保留テストセットがない）であり、データセットのサイズが小さすぎるため、学習分布外の質問表現に対しても性能が汎化するかどうかは不明です。
なぜこれが重要か
LoRAとconstrained decodingを組み合わせることで、1B未満のモデルが本番環境の分類タスクに実用的に使用できることを示しており、プライバシーに配慮したユースケースや低レイテンシのエッジ展開に関連しています。
Source: https://www.teachmecoolstuff.com/viewarticle/fine-tuning-a-local-llm-to-categorize-questions
新しいHTTP QUERYメソッドの解説
HTTP QUERY メソッドは、リクエストボディを持つ安全かつべき等なクエリのためのリクエストメソッドを標準化するIETFドラフトです。これは既存のHTTPセマンティクスにおける根本的な不整合に対処するものです。すなわち、仕様上 GET はボディを持てず、POST はべき等でなくキャッシュも安全にはできず、ボディ付き GET は技術的に未定義であり多くの中間装置に拒否されるという問題です。
仕様の機械的な定義：QUERY は安全（副作用なし）かつべき等として定義されており、GET とまったく同様ですが、リクエストボディを明示的に許可している点が異なります。レスポンスのセマンティクスは GET と同等です。キャッシュを行う中間装置は QUERY のレスポンスをキャッシュ可能として扱うことができ、その際のキャッシュキーのロジックは GET と同じで、リクエストボディもキャッシュキーの一部となります。これが重要な点です。ボディを持つクエリに対する既存の POST の回避策は、POST が安全として定義されていないため、デフォルトではCDNやプロキシにキャッシュされません。
これはGraphQLのデプロイメント（クエリを POST ボディとして送信するためCDNキャッシュが機能しない）、検索API、およびURLに収まらない複雑なフィルターや集計仕様を受け付けるエンドポイントに対して具体的な影響を持ちます。QUERY メソッドにより、こうしたユースケースは POST 経由の GET トンネリングのようなハックなしに、完全なHTTPキャッシュセマンティクスを得られるようになります。
実装にはHTTPサーバー、クライアント、および中間装置での明示的なサポートが必要です。ドラフトは成熟した段階にありますが、まだRFCにはなっていません。（本記事を公開した）アプリであるKreyaはクライアントサイドのサポートを実装しており、それがこの解説を執筆した理由です。
未解決の問題は採用のタイムラインです。標準化された後でも、CDNおよびプロキシのサポートは遅れるでしょうし、既存のAPIクライアントはデフォルトで GET/POST の二択を前提としているため、実際の利用が普及するまでには数年かかるでしょう。
なぜこれが重要か
10年以上にわたってAPIデザインとキャッシュに実際のアーキテクチャ上の妥協をもたらしてきた、HTTPセマンティクスの真の欠陥を埋めるものです。
Source: https://kreya.app/blog/new-http-query-method-explained/
LinuxとSecure Bootの証明書有効期限問題（2025年）
LWNの記事は、LinuxのSecure Bootチェーンにおける運用上の問題を取り上げています。具体的には、Linuxブートローダー（ほとんどのディストリビューションが使用するShimレイヤー）を検証するために使われるMicrosoft署名済みUEFI証明書に有効期限があり、Secure Boot署名チェーンの失効・更新プロセスが単純ではないという問題です。
技術的な構造としては、UEFIファームウェアはMicrosoftのルート証明書を信頼し、MicrosoftはKEK（Key Enrollment Key）に署名し、ShimはMicrosoftによって署名されてディストリビューション固有の鍵を内包し、そのディストリビューション鍵がGRUBとカーネルに署名するという形になっています。いずれかのレベルで有効期限切れや失効が発生すると、チェーン全体が破綻します。現在の問題はルートではなく中間署名インフラに関するものですが、解決のためにはShim、DBX（UEFIファームウェアに格納された失効データベース）、および展開済みマシン上のMokManagerエントリを協調して更新する必要があります。
実際の問題として、DBXの更新はデュアルブート環境のマシンに対してWindows Update経由で配信されますが、すべてのファームウェアベンダーが確実にDBX更新を提供しているわけではありません。古いファームウェアを搭載したLinux専用マシンではDBX更新がまったく届かない場合があり、efi-updatevar や同等のツールを使った手動対応が必要になります。
さらに微妙な問題として、ブートローダーのSecure Boot署名鍵をローテーションする際には、現在展開されているすべてのカーネルとブートローダーが信頼済みのままであるか、あるいは再署名されている必要があります。これは長期リリースをサポートするディストリビューションにとって、運用上非常に複雑な作業となります。また、MOK（Machine Owner Key）の登録とシステムのDBX状態の相互作用については、ほとんどのシステム管理者に十分理解されていません。
なぜこれが重要か
Secure Bootチェーンにおける証明書の適切な管理は、更新後にシステムが起動しなくなるまで見えにくい問題です。これはLinux環境、特にファームウェアが厳しく制限された環境において、現実的な運用リスクとなっています。
Source: https://lwn.net/Articles/1029767/
Show HN: Oak – エージェント向けに設計されたGitの代替
Oakは、エージェント（自動コード修正プロセス）が人間ではなく主要なコミッターであるという前提のもとで設計されたバージョン管理システムです。そのデザインは、エージェントの使用パターンに基づいたいくつかの点でGitとは異なるアプローチを取っています。
コアデータモデルは、GitのスナップショットによるDAGを明示的な操作ログ（ファイルの作成・変更・削除・リネームといった型付き操作のシーケンス）に置き換えています。ツリー差分ではなく操作を記録することで、エージェントが生成した変更のマージコストが低下します。なぜなら、エージェントが頻繁に行う操作（ファイルへの追記、特定行への挿入）を可能な限り可換または順序非依存な操作として表現できるため、コンフリクトが減少するからです。Gitのblobベースのdiffマージは行単位であり、操作のセマンティクスを理解しません。
Oakはまた、人間向けのfeature branchではなく、タスクの分離を中心にブランチ機能を再設計しています。各エージェントタスクは軽量な「ワークスペース」を取得します（ブランチに類似していますが、より厳格な分離セマンティクスとマージ時の自動クリーンアップを持ちます）。ロックモデルはファイル単位の楽観的並行性であり、Gitのリポジトリ全体のロックフリーモデルとは異なります。これにより、2つのエージェントが同一ファイルを同時に非互換な形で変更する類のコンフリクトを、マージ時ではなく即座に表面化させることで回避します。
ストレージバックエンドはGitのオブジェクトストアと同様にcontent-addressableであるため、重複排除の特性は維持されています。CLIの表面積は設計上Gitより小さく、自動化されたワークフローではほとんど必要とされない操作は省かれています。
このプロジェクトは初期段階であり、Oak自身の上にセルフホストされています（リポジトリのURLはOakインスタンスです）。主な未解決事項は、操作ログモデルが高頻度なエージェントコミットを伴う大規模リポジトリにスケールするかどうか、および単純な追記・挿入を超えた実際のエージェント修正パターンの多様性をそのセマンティクスが十分にカバーできるかどうかです。
なぜこれが重要か
バージョン管理のセマンティクスは人間の認知パターンを前提として設計されてきました。エージェント主導の開発がスケールするにつれて、Gitのマージモデルとのミスマッチは現実のボトルネックとなっていくでしょう。
Source: https://oak.space/oak/oak
注目の新しいリポジトリ
myccarl/ai-shortVideo-pipeline
自動化されたショート動画制作のためのエンドツーエンドパイプラインであり、FastAPIオーケストレーション層とSpring Boot APIゲートウェイを組み合わせています。このアーキテクチャはマルチモデルフェイルオーバーを実装しており、プライマリの生成モデル（動画、TTS、音楽）が利用不可能な場合、サーキットブレーカーが手動介入なしにセカンダリへルーティングします。メータリングフックにより、パイプライン実行全体を通じてモデルごとのトークンおよび計算コストを追跡します。
品質ゲーティング層は、より興味深いエンジニアリング上の工夫です。プロンプトアンカリングにより、下流の生成ステップが元のブリーフと意味的に一貫性を保つことが保証されます。CLIP一貫性チェックは、生成されたフレームを参照 embedding と比較して視覚的なドリフトを検出します。AV同期自動修復機能は、音声・映像のズレを検出し、ジョブ全体を失敗させるのではなく、再レンダリングまたはオフセット補正をトリガーします。構造化ログとPythonおよびJVMの両レイヤーをまたいで伝播されるトレースIDにより、フルスタックの可観測性が組み込まれています。
研究デモではなく、エージェント的な動画ワークフローのためのプロダクショングレードのスケルトンが必要な場合に本リポジトリを選択してください。マルチサービス境界（FastAPI + Spring Boot）は、Pythonの推論とJava/Kotlinのサービスインフラをすでに分割しているチームに適合します。
Source: https://github.com/myccarl/ai-shortVideo-pipeline
SantanderAI/gen-fraud-graph
金融サービスにおけるグラフベースの不正検知向けに、再現性のあるベンチマークを目的とした合成不正グラフジェネレーターです。解決する核心的な問題はデータ不足にあります。実際のトランザクショングラフは独自資産であり共有できないため、機関をまたいだベンチマーク比較が事実上不可能です。
このジェネレーターは、ノードがエンティティ（口座、加盟店、デバイス）を表し、エッジがトランザクションを表す、ラベル付き有向グラフを生成します。不正サブグラフパターン——マネーミュールの連鎖、リングネットワーク、レイヤリングサイクルといった構造的に識別可能なモチーフ——は、設定可能な発生率でグラフに注入されます。エッジおよびノードの特徴量（取引金額、タイムスタンプ、カテゴリカルな加盟店コード）は、実データを漏洩させることなく実証的な統計量に近似するよう設計されたパラメータ化可能な分布からサンプリングされます。
出力フォーマットは標準的なグラフ機械学習ツール（NetworkX、PyG、DGL）と互換性があるため、GNNのベースラインを組み込むことは容易です。シード制御と再現性のある生成により、固定ベンチマーク上でGCN、GraphSAGE、および異種グラフtransformerアプローチを比較するアブレーション研究に適しています。
主な制限事項：合成グラフの統計的特性は実データから学習されるのではなく手動で指定されるため、分布的なリアリズムはジェネレーターのキャリブレーションの精度に依存します。それでも、内部の不正データにアクセスできないチームにとっては、制御された評価基盤を提供するものです。
Source: https://github.com/SantanderAI/gen-fraud-graph
cobusgreyling/loop-engineering
AIコーディングエージェントにおけるhuman-in-the-loopおよびエージェント間オーケストレーションパターンを設計するためのフレームワーク兼CLIツールキットです。Addy Osmaniのエージェントループに関する著述や、Boris ChernyのStructured Agent Designの成果を参考にしています。
主要な3つのCLIツールがその適用範囲を定義しています。loop-initは意見を持った（opinionated）ディレクトリ構造と設定を備えた新しいエージェントループプロジェクトを雛形として生成します。loop-auditは既存のループ定義を静的解析し、非有界な再帰・終了条件の欠如・人間へのエスカレーションフックの不在といった一般的な障害パターンを検出します。loop-costはループの実行を計装し、ステップごとの推定トークン数とAPIコストを報告します。これはループが数百回のイテレーションを実行し得る場合に特に重要です。
パターンライブラリには、prompt-chainingループ、reflectionループ（エージェントが処理を進める前に自身の出力を批評するもの）、マルチエージェントによるdebate構造が含まれています。各パターンはブラックボックスの抽象化ではなく、組み合わせ可能なスターターとして提供されているため、内部実装は読みやすく、修正も容易です。
ループの信頼性とコストの予測可能性が純粋な性能よりも重視されるCI bot、リファクタリングエージェント、テスト生成パイプラインといった自律的なコーディングワークフローを構築するエンジニアを対象としています。
Source: https://github.com/cobusgreyling/loop-engineering
sums001/Windows-Copilot-API
Windows Copilotをリバースエンジニアリングし、OpenAI互換のREST APIとして公開するラッパーです。APIキーや課金契約なしにGPT-4、さらにはGPT-5クラスのモデルへアクセスできると報告されています。インターフェースは /v1/chat/completions エンドポイントのスキーマを模倣しているため、OpenAI SDKを使用している既存のクライアントは、base URLを変更するだけで他の修正なしにこのサーバーへ向けることができます。
技術的な作業としては、Windows CopilotクライアントとMicrosoftのバックエンド間のHTTP(S)トラフィックを傍受し、セッショントークンの処理を特定したうえで、それをローカルプロキシサーバーにラップするという手順が含まれています。認証はAPIキーではなく、Windowsのアンビエントセッションクレデンシャルを再利用します。
実用的なユースケースは限られており、ライセンス済みのWindows環境をすでに持つユーザーによるローカル開発や実験が主な用途となります。信頼性はMicrosoftが基盤となるプロトコルをローテーションしないことに完全に依存しているため、本番環境向けの用途には不適切です。コンシューマー向けCopilotサービスのレート制限が適用されますが、その内容は公式には公開されていません。
本プロジェクトは主に、プロトコルのリバースエンジニアリング手法のリファレンスとして、また探索的な研究においてAPIの課金管理なしにモデルの挙動を調べたい研究者にとって有用です。脆弱なインフラストラクチャとして扱ってください。
Source: https://github.com/sums001/Windows-Copilot-API
datalab-to/lift
ドキュメントから構造化データへの抽出ライブラリで、精度とスループットに重点を置いています。中核となる抽象化は、型付きスキーマ定義であり、任意のドキュメント（PDF、スキャン画像、HTML、プレーンテキスト）をそのスキーマに対してパースし、出力はそのスキーマに準拠した検証済みJSONとなります。
内部的には、Liftはレイアウトを考慮したドキュメントパースとLLMによるフィールド抽出を組み合わせており、入力をフラットなテキストストリームとして扱うのではなく、ドキュメントの視覚的・意味的な構造を抽出の根拠として活用します。これは、空間的な関係が意味を持つ請求書、契約書、フォームなどのドキュメントにおいて重要であり、純粋なテキストのシリアライズではその情報が失われてしまいます。
このライブラリはPython APIを提供しており、抽出スキーマをPydanticモデル（または同等のdataclass）として定義し、ドキュメントを渡すと、フィールドごとの信頼スコアを伴う構造化出力が返されます。パイプライン統合のためのバッチ処理および非同期サポートも含まれています。
汎用的なLLMプロンプティングによる抽出との差別化点は、レイアウトグラウンディングのステップにあり、密な表形式コンテンツや複数カラムレイアウトを持つドキュメントにおけるハルシネーションを低減します。より重厚なOCR＋NLPパイプライン（例：LayoutLMのfine-tuning）と比較すると、精度の上限をある程度犠牲にする代わりにデプロイの容易さを得ており、GPUは不要です。
Source: https://github.com/datalab-to/lift
Tejas-TA/predikit
学習済みMLモデルをツール呼び出し可能な関数として公開し、AIエージェント（LangChain、LlamaIndex、カスタムのfunction-callingワークフロー）から利用できるようにするためのブリッジライブラリです。中心的な課題は、ほとんどのMLモデルインターフェースがバッチオフライン推論向けに設計されており、LLMエージェントからの低レイテンシな同期ツール呼び出しには対応していない点にあります。
Predikitは、sklearn、XGBoost、LightGBM、およびPyTorchのモデルを統一された Predictor インターフェースでラップし、入力バリデーション、特徴量の前処理、およびエージェントが読み取れる形式への出力シリアライゼーションを処理します。デコレータベースのAPIにより、既存のモデルサービングコードにスキーマメタデータ（特徴量名、型、期待される値の範囲など）をアノテーションとして付与でき、それがエージェント向けのJSON Schemaツール記述として公開されます。
このフレームワークは予測の説明機能も備えており、SHAP値をオプションで計算して予測結果とともに返すことができます。これにより、エージェントはスカラー値の出力に基づいて行動するだけでなく、不正スコアが高い理由や解約確率が上昇している理由を推論できるようになります。
MLflow、BentoML、および類似ツールは人間向けAPIやバッチジョブをターゲットとしており、エージェントのツール利用が要求する200ms未満の同期呼び出しパターンには対応していません。Predikitはその実質的な空白を埋めるものです。
Source: https://github.com/Tejas-TA/predikit
Nigh/show-me-the-story
埋め込みWeb UIを備えた単一のGoバイナリとして配布される、セルフホスト型の長編フィクション生成ツールです。アーキテクチャは意図的にミニマルな設計となっており、外部データベースもコンテナオーケストレーションも必要ありません。設定はOpenAI互換のAPIエンドポイント（ローカルのOllama、リモートのOpenAIなど）を任意に指定できます。
生成パイプラインは、単一の長いコンテキストプロンプトではなく、構造化された形式を採用しています。システムはまずアウトライン（幕構成、章ごとのサマリー、キャラクターの成長弧）を構築し、その後チャプターを反復的に執筆します。各チャプターの後にはレビューパスが実行され、内部的な整合性を確認し、未解決の伏線スレッドにフラグを立て、確立されたworld-stateに対して軽量なファクトチェックを行います。全チャプターの完成後には、連続性とトーンの一貫性を目的とした最終的な全文ポリッシュパスが実行されます。
中国語と英語のバイリンガルサポートはファーストクラスで提供されており、プロンプトテンプレートとレビューヒューリスティックは両言語に合わせてチューニングされています。単に言語パラメーターを渡すだけの実装ではありません。
Goバイナリによる配布は実用的な差別化要素です。エンジニアではない作家でも、PythonEnvironmentをインストールしたり依存関係を管理したりすることなく、ノートパソコン上で実行できます。コードベースはGoにおけるマルチステージLLMパイプライン設計のリファレンスとして活用できるほど読みやすく書かれています。
Source: https://github.com/Nigh/show-me-the-story
saiyam1814/kiac
Appleのネイティブコンテナ仮想化フレームワーク（macOS 15で導入）上で動作するローカルKubernetesセットアップです。MinikubeなどのツールのようにVMを単一共有するのではなく、各Kubernetesノードがそれぞれ独立した軽量VM上で動作します。これにより、ラップトップ上でプロダクション環境のマルチノードクラスタトポロジをより忠実に再現できます。
このツールは、Virtualization.frameworkを直接活用してオーバーヘッドの低いVMを実現するAppleのcontainerizationフレームワークを用い、フルマルチノードクラスタをプロビジョニングします。各ノードは独立したネットワークを持ち、セットアップにはkubectl top機能のためのmetrics-server、永続ストレージのプロビジョニング、および外部クラウド依存なしでLoadBalancerタイプのサービスが機能するためのLoadBalancer実装（ローカルプロキシによるバックエンドと思われる）が含まれます。
これは、ノードレベルの障害シミュレーション、DaemonSetの挙動、実ノードをまたいだpodのanti-affinity、あるいはノード間のネットワークポリシーの適用など、シングルノードのローカルクラスタでは正確に再現できないシナリオのワークロードテストに有用です。Apple Silicon Mac専用であり、仮想化のオーバーヘッドが十分に低いため、3〜4台のVMを同時に実行することが現実的に可能です。