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

公開

2026年6月22日

English · 日本語

arXiv ハイライト

GateMem: マルチプリンシパル共有メモリエージェントにおけるメモリガバナンスのベンチマーク

問題設定

LLMエージェント向けの既存メモリベンチマーク(LongMemEval、LoCoMo、MemoryBenchなど)は、単一ユーザーがプライベートなメモリストアに書き込み・読み出しを行うという前提を暗黙的に採用しています。そこで重視される指標は、長時間にわたり時系列的に分散した対話に対する再現性です。この設定ではガバナンスが有用性に帰着してしまいます。つまり、格納されたすべての事実は、構造上、質問者が正当にアクセスできるものとなっています。

共有アシスタントはこの前提を崩します。病棟エージェントは主治医、研修医、看護師、患者に対応し、オフィスアシスタントは管理職、部下、HRに対応し、家庭用ハブは親、子ども、ゲストに対応します。複数のプリンシパルが共通のメモリプールに書き込み、クエリは異なるロール・スコープ・関係的権限のもとで到達します。この状況での正確性には、以下の3つの相互に結びついた性質が求められます。

  1. Utility(有用性): 合法的な長期的リクエストが成功すること。状態の更新(例:投薬変更、成績の上書き)を含む。
  2. アクセス制御: メモリの読み出しが、静的なロールタグだけでなく、文脈的な認可に従うこと。
  3. 能動的な忘却: 明示的な削除リクエストが伝播し、その後のクエリ——削除者自身によるものも含め——が削除済みアイテムを取得・再出力しないこと。

GateMem は、これらの軸における複合的な失敗モードを明らかにすることを目的として構築されています。

ベンチマークの構成

GateMem は、医療・オフィス・教育・家庭という4つの展開ドメインをカバーしています。各エピソードは、プリンシパルがロールと関係性(例:主治医–患者、管理職–部下、教師–生徒–保護者)によって型付けされたマルチパーティの長文インタラクションスクリプトです。メモリへの注入は逐次的であり、事実はあらかじめ構築されたKBではなくターンとして到達します。これにより、あらゆるメモリモジュール(long-context、RAG、要約、階層型ストア、外部スクラッチパッド)が現実的な条件のもとでそれらを取り込みます。

評価は、軌跡中に挿入された隠しチェックポイントを基準としています。

  • Utility チェックポイント: エージェントが最新の有効な状態を使用しているかをテストします。特に、以前の事実を上書きする更新後において検証されます。
  • アクセス制御チェックポイント: ある事実への認可を持たないプリンシパルとしてエージェントにクエリを行います。リーク対象のアノテーションにより、違反を構成する正確な文字列・エンティティが列挙されています。
  • 忘却チェックポイント: 明示的な削除イベントの後、同じ事実について再クエリを行います。認可されたプリンシパルと未認可のプリンシパルの両方から問い合わせることで、検索・要約状態・潜在的な再出力における持続性を検出します。

判定は自由形式ではなく構造化されています。リーク対象のアノテーションにより、判定用LLM(またはプログラムチェッカー)がラベル付きスパンとの精密な照合として違反をスコアリングできます。また、Utility のスコアリングは、過去の状態ではなく更新後のground-truth状態を条件とします。

評価手法

本論文では、共通のバックボーンファミリーを背後に持つ複数のメモリアーキテクチャをベンチマーク評価しています。

  • Long-context prompting: コンテキスト上限まで以前のすべてのターンを連結する。
  • Retrieval-based memory: クエリ時にdense retrievalを用いるチャンク化されたストア。
  • 外部構造化メモリ: 書き込みおよび削除操作を備えた明示的なファクトテーブル/グラフ。
  • 要約 + retrieval のハイブリッドbaseline。

いずれも同一のエージェントハーネスと組み合わせ、Utility U、アクセス制御コンプライアンス A、忘却コンプライアンス F の3つのスコアで評価されます。ガバナンススコアは AFU とは別に集約し、Utility がリークを隠蔽しないようにします。概念的には以下のとおりです。

\text{Governance} = \alpha A + (1-\alpha) F, \quad \text{Overall} = \beta\, U + (1-\beta)\, \text{Governance},

本論文では各成分を個別に報告することで、トレードオフが明確に把握できるようになっています。

所見

主要な結果は、支配的な点が存在しないパレートフロンティアです。すなわち、ドメインとバックボーンを通じて、高い Utility・堅牢なアクセス制御・信頼性の高い忘却を同時に達成する手法は存在しません。

  • Long-context prompting はガバナンスにおいて優位に立つ傾向があります。モデルがロールおよび削除マーカーをin-contextで読み取り、クエリ時にそれらについて推論できるためです。しかし、トークンコストが大きく(エピソード長に比例して全履歴の連結が必要)、コンテキストが増大するにつれて性能が低下します。
  • Retrieval-based手法 はコストを削減しますがリークが発生します。Embedding の類似度は、誰が事実を書いたか、誰が質問しているか、ストリームの後段で削除イベントが発生したかどうかについて無関心です。インデックス内のtombstoneは下流のLLMによって不完全にしか尊重されず、抑制を指示されていても取得したチャンクをしばしば言い換えて出力します。
  • 明示的な削除操作を持つ外部構造化メモリ は忘却に対して最も自然に適合しますが、状態更新および書き込み者が構造化しなかったエントリに対して Utility が低下します。アクセス制御コンプライアンスは認可述語のエンコード方法に依存し、関係性がロール固定でなく文脈的な場合には脆弱になります。

Retrieval および外部メモリのbaselineに共通する失敗モードとして、直接クエリが正しく拒否される場合でも、削除された情報が間接的なクエリ(関連エンティティ、要約、「以前何について話したか」)のもとで再浮上することが挙げられます。これは、ストアからの消去とモデルのコンディショニング軌跡からの消去の間にある、よく知られたギャップを反映しています。

限界と未解決の問題

GateMem はLLM-in-the-loopパイプラインで構築・判定されており、リーク対象のアノテーション品質と判定器のキャリブレーションがボトルネックとなっています。また、ドメインカバレッジが4つの設定に限定されていることも論文中で認められています。認可は関係的にエンコードされていますが、形式的なポリシー言語を用いていないため、ポリシーエンジン統合(OPA、Cedarなど)のストレステストはできません。忘却のセットアップは行動的なコンプライアンスをテストするものであり、パラメータや embedding に対するmachine-unlearning的な保証を与えるものではありません。さらに、結果は現在のバックボーンで報告されており、コンテキストウィンドウの拡大やネイティブなメモリコントローラーのfine-tuningによってガバナンスのギャップが縮小するかどうかは未解決のままです。

この研究の意義

共有アシスタントは、クリニック・学校・職場といった規制環境におけるエージェント型LLMの近未来的な展開形態として最も現実的であり、まさにこのような設定において、再現性のみを測定するベンチマークが誤解を招きます。GateMem はメモリをガバナンス問題として再定式化し、測定可能で分離可能な軸を提供します。そして実証的なパレートギャップは、アーキテクチャ上の研究方向性を示唆しています。すなわち、書き込み・読み出し・削除操作がプリンシパルのアイデンティティ・文脈的認可・来歴に基づいて共同で条件付けられるメモリシステム——プロンプトとして後付けされるのではなく——の設計です。

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

BrainG3N: 制御可能な3D脳MRI生成のための二重目的 tokenizer

問題

3D医療画像向けのlatent diffusionは、tokenizer に相反する要求を課します。encoder は、conditioning や下流のprobingが機能するよう、臨床的に有用なシグナル(遺伝子型、グレード、診断)を保持したlatentを生成しなければなりません。一方、decoder はそれらのlatentを解剖学的に忠実なボクセルへと逆変換しなければなりません。再構成目的関数でend-to-endに学習されたtokenizer――自然画像のlatent diffusionから受け継いだ標準的なCNN-VAEのレシピ――は、encoderを低レベルのテクスチャ特徴に向かわせ、疾患関連タスクが依拠するセマンティックな構造を捨て去ります。コホートが小規模で、サイトが異質であり、臨床的に意味のあるコントラスト(例:IDH1変異、WHOグレード、ADとHCの区別)が微妙な脳MRIにおいて、このトレードオフは生成的データ拡張、反事実シミュレーション、およびプライバシー保護共有における制限要因となっています。

手法

BrainG3Nは、まず3D masked autoencoder(MAE)encoderを学習し、それを凍結した上で、encoder embeddingの低次元線形射影の上にCNN decoderを学習することで、二つの目的関数を切り離します。

Phase 1:完全にボリュメトリックなMAE encoderが、18コホート(17,399被験者、200以上のサイト、4モダリティ――T1、T2、FLAIR、T1c――10の臨床カテゴリ、年齢5〜98歳)から得られた35,309ボリュームで事前学習されます。すべてのボリュームはANTsを用いてSRI24にaffine registrationされ、HD-BETでskull-strippingされ、N4補正が施され、1 mm等方的分解能での160{\times}192{\times}160ボリュームが得られます。encoderはチャンネル次元1152のtoken gridを出力します。

Phase 2:線形射影z' = W zが1152次元のper-token embeddingをd'チャンネルにマッピングし、専用のCNN decoder D_\phi(z')がボクセルを再構成するよう学習されます。encoderの重みは更新されません。diffusionモデルが操作するlatentはzではなくz'であるため、diffusionの入力次元はd'によって決まります。

重要な経験的なパラメータはd'です。1100ボリュームの腫瘍コホート(UCSF-PDGM + UPENN-GBM)において、著者らはd' \in \{32, 128, 512\}をsweepします。再構成のPSNR/SSIMはd'に対して単調に増加し、128を超えると収穫逓減となります。さらに重要なことに、bottleneckが臨床的な内容を破壊するかどうかを検証するため、射影後のz'をlinear-probeします。d'=32において、IDH1変異probingのAUCは0.861であり、生の1152次元embeddingの0.883と比較して0.022の低下にとどまっています――元の次元数のわずか3%未満(38K対1.4Mのlatent変数)でのことです。WHOグレードのギャップは0.055です。著者らはすべての下流実験にd'=32を採用し、diffusion入力の大幅な小型化のために、わずかなprobing精度を犠牲にしています。

凍結MAE + CNN decoder tokenizerによるd'=32でのボクセル再構成

d'=32での再構成は、年齢や疾患状態を超えて、脳回の折り畳み、脳室形状、および全体的な形態を保持しており、拡大した脳室を持つアルツハイマー症例も含まれます。これは、凍結MAE encoderの32チャンネル射影が解剖学的に忠実なデコーディングに十分であることを示す視覚的証拠です。

その後、z'空間でconditional DiTがclassifier-free guidanceを用いて学習されます。conditioning属性には年齢、疾患ラベル、モダリティ、腫瘍の有無が含まれます。

conditional DiT(CFG s=1.5)による同一ノイズ反事実生成

反事実パネルでは初期ノイズを固定し、一度に一つの属性をsweepします。年齢sweep(HCにおける30 → 75)は期待される脳室拡大と皮質菲薄化をもたらし、75歳でのHC → ADのsweepは追加的な内側側頭部萎縮をもたらします。モダリティsweep(T1/T2/FLAIR)は解剖構造を変えずにコントラストを変化させます。固定ノイズ下でdisentanglementが維持されるという事実は、conditioning signalがノイズに吸収されることなく意図した変動軸に作用していることの最も強力な証拠です。

縦断的予測

凍結tokenizer は、ベースラインボリュームと\Delta tが与えられたときに追跡スキャンを予測するという、保留されたADNI被験者に対する予測基盤としても評価されます。

保留されたADNI被験者に対するリアルとモデル予測の縦断的変化の比較

差分マップは、脳室周囲および内側側頭部領域に集中した実際の萎縮と空間的に一致しており、行ごとにzスコアの大きさが記載されています。これらの予測は写実的な新規スキャンではなく――同一被験者の予測です――これが臨床的に有益なtokenizerの適切な使用法です。

結果の概要

  • 23タスクのlinear probing:SOTA に匹敵または凌駕する(詳細な表は付録に記載;抄録での主張)。
  • Bottleneck:d'=32は次元数の1/36でIDH1 AUCを1152次元encoderの0.022以内、WHOグレードを0.055以内に保持する。
  • 再構成はモダリティおよび疾患を超えてd'=32で解剖学的な忠実性を維持する。
  • Conditional DiTは同一ノイズsweepにおいて属性がdisentangleされた反事実を示す。

制限と未解決の問題

本論文は単一の腫瘍コホートにおける1種類のbottleneckアブレーション(d'\in\{32,128,512\})のみを報告しており、d'=32が皮質厚回帰や小病変セグメンテーションのようなfine-grainedタスクに対しても十分かどうかは未検証です。MAE encoderは凍結されているため、Phase 1の事前学習中に学習できなかった臨床的シグナルはz'から永続的に失われます。これにより、事前学習のカバレッジに強い依存性が生じます。decoderはz'に対して決定論的であるため、生成の多様性は完全にdiffusion priorに由来します――サブtoken分解能の病理は平均化される可能性があります。定量的な予測指標(実際の追跡との領域ごとの萎縮相関)は図中に定性的に示されているものの、確立された縦断的モデルとのベンチマーク比較はなされていません。最後に、SRI24への統一的な前処理は、実際のデプロイメントで遭遇するネイティブ空間の変動性へのモデルの露出を制限します。

重要な理由

clinically事前学習された凍結encoderと、CNN decoderに入力する薄い線形射影を組み合わせることで、encoderとdecoderの目的関数を切り離すアプローチは、医療向けlatent diffusionにおけるtokenizerのトレードオフに対して、さらなる共同VAE目的関数よりも明快な解決策です。結果として得られる単一の32チャンネルlatentは、一つのtokenizerからprobing、条件付き生成、および縦断的予測をサポートします――これは、視覚的にだけでなく臨床的にも有用な生成モデルに向けた意義深い一歩です。

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

Multi-Turn Reflective Masking Elicits Reasoning in Mask Diffusion Models

Mask diffusion models(MDMs)は、吸収マルコフ過程のもとでトークンを逐次的にアンマスクすることで生成を行います。一度ある位置が明らかになると、それは固定されます。これは、人間が草稿を反復修正する際の自然な対称性——シーケンス全体を書き直すことなく、誤った領域を局所的に再編集する——を損ないます。Autoregressive chain-of-thought reasoning は反射的な継続を追加することで補完しますが、すべての改訂は編集点以降の再生成を必要とします。本論文は、denoiserが自身の以前の出力を再マスクすることを許可すれば、MDMsが局所的なインプレース反射に近いものを回復できると主張し、Reflective Masking(RM)とパラメータフリーの履歴機構(History Reference、HR)を提案して、軽量なpost-trainingによりこの挙動を引き出します。

Method

x^\ast \in \mathcal{V}^N をターゲット、E \subseteq \{1,\dots,N\} を編集可能な位置、\bar{\mathcal{V}} = \mathcal{V} \cup \{\texttt{MASK}\} とします。各編集可能な位置はステップ t において \{w_i, \texttt{MASK}, x_i^\ast\} の値を取り、ここで w_i はタスク固有の誤ったトークンです。モデルは \bar{\mathcal{V}} 上のカテゴリカル分布 p_\theta(\cdot \mid \tilde{x}^{(t)})_i を出力し、次ステップの遷移は位置ごとに決定論的です:

\tilde{x}^{(t+1)}_i = \begin{cases} \texttt{M} & \text{if } \tilde{x}^{(t)}_i \neq \texttt{M} \text{ and } p_\theta(\texttt{M}\mid \tilde{x}^{(t)})_i > p_\theta(\tilde{x}^{(t)}_i\mid \tilde{x}^{(t)})_i \\ \tilde{x}^{(t)}_i & \text{if } \tilde{x}^{(t)}_i \neq \texttt{M} \text{ and } p_\theta(\texttt{M}\mid \tilde{x}^{(t)})_i \leq p_\theta(\tilde{x}^{(t)}_i\mid \tilde{x}^{(t)})_i \\ \arg\max_{v\in\mathcal{V}} p_\theta(v\mid \tilde{x}^{(t)})_i & \text{if } \tilde{x}^{(t)}_i = \texttt{M} \end{cases}

この決定規則は対称的かつ直感的です。モデルが現在表示されているトークンよりも MASK により多くの確率質量を与えるならば、そのトークンは誤りと判断され再マスクされます。そうでなければ保持され、マスクされた位置は \mathcal{V} 上のargmaxで埋められます。これにより、保持・再マスク・明示の3つのアクションが、モデル分布のみによって駆動される1つの位置ごとの決定のもとに統一されます。

\tilde{x}^{(t)} のみを条件とすると、同一の状態が再び現れてループが発生するサイクルが生じます。History Referenceはこのルールを変えることなくこれを解決します。過去の状態はembeddingされ、位置ごとの履歴考慮embeddingに集約され、denoiserに入力される前に現在状態のembeddingに加算されます。

History Referenceを用いた推論手順。過去の状態はHERによって処理され、モデルが次のステップを予測する前に現在のembeddingに加算されます。

HRはパラメータフリーであるため、既存のMDMバックボーンは変更されません。再マスク挙動を学習するために、著者らは MASK 破損と誤りトークン破損 w_i の両方を含む軌跡を合成し、式(1)と整合する許容遷移パスに沿って合成履歴をサンプリングします。学習ターゲットは、現在誤ったトークンを持つ位置では MASK を出力し、それ以外では正しい x_i^\ast を出力するようモデルに指示し、保持・再マスク・明示の三分法を直接教示します。

合成履歴データの構築:クリーンなシーケンスをマスクと誤りトークンのノイズで破損させ、位置ごとの遷移ルールが履歴をサンプリングして学習ターゲットを定義します。

このレシピは低コストです。3つのベンチマーク全体にわたる完全な学習は2×H100 80GB上でおよそ5時間で完了し、アーキテクチャを修正する代替手法に典型的な数日間の実行と対照的です。

Results

評価は外部監督が減少する3つのレジームにわたります:命令画像編集(強い誘導)、数独(構造化推論)、数学・コード(回答に関する誘導なし)。

Lumina-DiMOOをベースモデルとした命令ベースのインプレース画像編集において、85kのImgEdit事例で学習し1.7kのホールドアウト事例でテストした結果、RMはマッチした設定のもとでバニラベースラインとSFTの両方を大幅に上回りました。Edit Precisionは65.81(Lumina)・71.84(SFT)から99.73へ、Edit Coverageは41.68 / 48.42から73.02へ向上しました。背景保持も大幅に改善し、MAE-RGBは12.497 / 11.035から3.613へ低下、PSNRは23.09 / 23.90 dBから34.76 dBへ上昇、SSIMは0.626 / 0.657から0.9744へ向上しました。総合品質も同様で、VQAScoreは71.95 / 81.61 → 85.17、ユーザースタディの選好は41.8 / 53.3 → 68.2となりました。

RMは編集領域(赤マスク)を正確に局所化し、変更をその領域に限定します。ベースラインは編集ノイズをグローバルに分散させ、影響を受けるべきでない領域を歪めます。

このメカニズムは定性的にも可視化されます。RMのピクセル差分ヒートマップは意図した領域に集中しているのに対し、ベースラインは変更を画像全体に広げます。これはまさに再マスクを動機づける失敗モードです——局所的に誤ったトークンを選択的に再生成し、残りのキャンバスは保持アクションによって固定されます。

本論文はこれを数独(限られた誘導のもとでの構造化局所補正)と数学・コード推論にも拡張しており、後者ではモデルが自律的にどの過去のトークンが誤りであるかを発見しなければなりません。監督が弱まるにつれてHRの役割は大きくなります。画像編集では命令が編集を局所化しますが、数学・コードではモデルは何を再訪すべきかを知るために中間のdenoising軌跡情報に頼らなければなりません。

Limitations and open questions

決定規則は p_\theta(\texttt{MASK}) と現在表示されているトークンの確率のみを比較します。モデルが MASK に対して校正が不十分な場合、または確率質量が分割された複数の正しい代替案が存在する場合に、これがどの程度ロバストであるかは不明確です。学習中の合成誤りトークン w_i への依存は、それがもっともらしいエラーモードをカバーするかどうかが破損分布に大きく依存することを意味します。反復プロセスの収束特性は、HRがサイクルを破るという発見的な議論を超えては特徴付けられておらず、病理的なケースにおいて力学系が不動点を持つのか周期軌道のみを持つのかは未解決のままです。最後に、推論コストは反射的なターンの数に応じてスケールしますが、単純により多くの標準denoisingステップを実行することとの制御された計算一致比較は報告されていません。

Why this matters

Reflective MaskingはMDMsにネイティブなテスト時スケーリング軸——反復することで選択的に改訂する——を与えます。AR modelはサフィックスを再生成することでしかこれを近似できません。位置ごとの確率比較1つとパラメータフリーの履歴embeddingで十分であり、5時間のpost-trainingで実現できるという事実は、この能力が現在のMDMチェックポイントに潜在しており、単にアンロックされる必要があるに過ぎないことを示唆しています。

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

PerceptionDLM: Parallel Region Perception with Multimodal Diffusion Language Models

問題設定

領域レベルの知覚 — 画像中のユーザが指定した N 個の領域に対して詳細なキャプションを生成すること — は、自己回帰(AR)decoding によってボトルネックとなっています。DAM や GAR などの既存システムは領域ごとに1回の forward pass、すなわち y_i = f(I, R_i) を実行するため、実時間のレイテンシは N に対して線形に増大します。密なシーン(数十のマスク)では、これが支配的なコストとなります。PerceptionDLM はこのタスクを単一の結合予測 \{y_i\}_{i=1}^N = f(I, \{R_i\}_{i=1}^N) として再定式化し、1回の denoising diffusion プロセス内で実行します。これにより、離散拡散 LM(DLM)が本質的に持つ token 並列 decoding を活用します。

PerceptionDLMの概要と効率性分析。

Base model

PerceptionDLM-Base は、SigLIP-2(so400m-patch16-512)+ 2層 GELU MLP connector + LLaDA-Instruct-8B のスタック構成であり、応答スパン X_a に限定したマスクトークン DLM objective で学習されます:

\mathcal{L}_{\mathrm{PerceptionDLM_{Base}}} = -\mathbb{E}_{(X_v,X_q,X_a),t,x_t}\left[\frac{1}{t}\sum_{i\in\mathcal{M}_a}\log p_\theta(x_0^i \mid x_t, H_v, X_q)\right].

視覚 embedding H_v と instruction トークン X_q はクリーンな状態を保ち、X_a のみが吸収状態の corruption を受けます。学習は Bee-Training、LLaVA-OneVision-1.5-Instruct、Honey-Data-15M を用いた4段階(各 1M/14M/22M/15M サンプル)で構成され、32×H100 上で動的な 512×512 タイリングを適用しながら約3週間かけて実施されます。

標準的な MLLM 評価において、本 base モデルは先行するオープンソースの diffusion VLM(LLaDA-V、MMaDA、LaViDa、SDAR-VL、Dream-VL)を上回り、Qwen2.5-VL-7B および InternVL3-8B と競合する性能を示します:MMBench 85.0、ChartQA 91.6、DocVQA 89.9、MMVP 82.0、BLINK 60.3、HallusionBench 58.4。LLaDA-V からの顕著な向上として、ChartQA(78.3→91.6)および MathVista(52.4→65.5)が挙げられます。

Parallel region perception

領域プロンプティング、RoI feature replay、および構造化 attention masking を用いた並列領域知覚アーキテクチャ。

base モデルを並列領域キャプション生成器に変換する3つの要素を以下に示します:

  1. Region prompting。 N 個の各マスクに対して、プロンプトは領域タグと長さ32トークンの専用応答スロットを含むようにテンプレート化されます。モデルは1回の diffusion trajectory 内で全 N スロットに対して joint attention を実行します。
  2. RoI-aligned feature replay。 各マスク R_i に対して、領域特徴が H_v から 4×4 RoI グリッドで pooling され、対応する応答スロットに再注入されます。これにより各スロットがターゲット領域の視覚的内容に固定され、AR 領域モデルおよびナイーブな DLM 双方で問題となる領域間の feature leakage が軽減されます。
  3. Structured attention masking。 各領域の応答トークンは、(a)完全な視覚的コンテキスト H_v、(b)共有 instruction トークン、(c)自身の応答スロットおよび RoI トークンのみに対して attention を実行でき、他の領域のそれらには attention できません。これにより denoising 中の並列生成が切り離される一方で、グローバルな画像コンテキストは保持されます。

学習は PerceptionDLM-Base から初期化し、全パラメータを学習可能に設定、1画像あたり最大6つの region prompt を使用、batch size 256、学習率 4\times10^{-5}、ParaCaption-5.7M 上で1エポック(32×H100 で約2日間)実施されます。推論では32回の denoising step とマスクあたり32トークンのスロットを使用します。

結果

著者らは DLC-Bench を Objects365 V2(54枚 / 178マスク)および DaTaSeg(46枚 / 121マスク)から抽出したマルチ領域プロンプトでスケールアップすることにより ParaDLC-Bench を構築しており、空間的に隣接するまたは意味的に混同しやすいインスタンスの組み合わせを明示的に選択しています。

ParaDLC-Bench 評価パイプライン:並列キャプション生成に続く領域ごとの LLM 判定。

ParaDLC-Bench における結果(Pos / Neg / Avg / TPF / Time):

  • PerceptionDLM-8B: 42.3 / 82.4 / 62.4、TPF = 2.9276 s
  • DAM-3B(AR): 48.1 / 87.2 / 69.2、TPF = 1、326 s。
  • GAR-8B(AR): 49.0 / 87.6 / 69.5、479 s。
  • PixelRefer-7B: 40.8 / 78.7 / 60.5、718 s。
  • LLaDA-V-8B(diffusion、最高品質設定): 24.1 / 46.3 / 35.2、3241 s。
  • Gemini-3.1-Pro: 43.6 / 81.1 / 63.7。

単一領域の DLC-Bench では、PerceptionDLM は 33.4 / 72.8 / 53.1 を記録し、LLaDA-V の 10.0 / 39.2 / 24.6 および DAM の 52.3 / 82.2 / 67.3 と比較されます。すなわち PerceptionDLM は、DAM/GAR に対して約1.7〜2.6倍、LLaDA-V に対して約12倍、PixelRefer に対して約2.6倍高速に動作しつつ、特化型 AR 領域モデルとの差を大幅に縮め、1回の forward sweep で実効的に TPF ≈ 2.9 領域を処理します。汎用フロンティアモデル(GPT-5.2、Gemini-2.5/3.1-Pro)との比較では、PerceptionDLM は Avg において競合する性能(62.4 対 55.2〜63.7)を示しながら、領域あたりのコストははるかに低くなっています。

限界と未解決の課題

  • 品質は依然として専用の AR 領域モデル(DAM/GAR の平均 ~69 対 62.4)に及ばず、並列 attention masking は一部の領域間意味的結合を切り離しのために犠牲にしており、記述が領域間の関係を参照すべき場合に性能が低下する可能性があります。
  • スループットは batch size 1 で報告されており、AR baseline のレイテンシはバッチ化された領域推論によって縮まる可能性がありますが、単一シーケンス内での真のトークンレベル並列性には追いつけません。
  • モデルは最大6つの region prompt で学習されており、1画像あたり数十のマスクへのスケールアップおよびそれに伴う attention/シーケンス長のコストは分析されていません。
  • 推論では固定の32ステップ × マスクあたり32トークンを使用しており、適応的な長さおよびステップスケジュールは未探索です。
  • ParaDLC-Bench は100枚の画像 / 299インスタンスに過ぎず、異なる judge 間での LLM-judge スコアの信頼性は報告されているものの、絶対的なスケールは小規模です。

なぜ重要か

これは、離散拡散 LM が本質的に集合値的であり逐次的でないタスク — マルチ領域キャプション生成、マルチエンティティ grounding、そして議論の余地はあるものの multi-question VQA — において AR MLLM に対して構造的な優位性を持つことの明確な実証です。N 回の逐次 decode を、切り離されたスロットごとの attention を持つ1回の denoising trajectory に集約することで実現しています。このレシピ(region prompting + RoI replay + structured masks)は、他のマルチターゲット知覚タスクを DLM backbone に移植するための再利用可能なテンプレートとなります。

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

WorldLines: 長期水平でステートフルな身体化エージェントのベンチマークとモデリング

問題設定

LLM向けの長期記憶ベンチマークは主に対話履歴からの検索やQAをテストするものであり、身体化ベンチマーク(ALFRED、Habitatタスク)は世界の状態が完全に可視化されているか素早くリセットされる短い水平での実行をテストするものです。どちらの設定も、家庭用ロボットが実際に必要とするものをプローブしていません。すなわち、数日間にわたって持続的で部分観測可能な世界状態を維持すること、直接観測したことと単に報告されたことを区別すること、状態の上書き(物体が二度移動された、タイマーがリセットされた)を処理すること、そしてその記憶を状態整合性のあるプランに変換することです。WorldLinesはこのギャップを対象としています。

WorldLinesの概要

ベンチマークの構築

WorldLinesのインスタンスは次のように定義されます:

x_i = (\mathcal{H}_{<c_i}, q_i, S_{c_i}, \mathcal{E}_i, y_i^\star, \tau_i),

ここで\mathcal{H}_{<c_i}はカットオフc_i以前の可視履歴、q_iは質問またはタスク、S_{c_i}は正解の世界状態、\mathcal{E}_iは支持イベントのエビデンスチェーン、y_i^\starは参照解答/プラン、\tau_iはタスクタイプです。重要なのは、S_{c_i}\mathcal{E}_iはエージェントからは隠されており、評価時にのみ使用される点です。トレースはHabitat/HSSのシーンに基づいており、手動でキュレートされたオブジェクト、receptacle、および制御可能なデバイスを用いています。クローズドループのジェネレータが、複数日にわたる対話、navigate/pick/place/open/close/set_device_state/handoffアクション、実行フィードバック、オブジェクト/デバイスの状態遷移を生成します。

構築フレームワーク

サンプルは8つのメモリターゲット(object_location、temporal_state、device_state、preference、routine、planning_dependency、hidden_state、social_context)と2つのタスクファミリー(Memory QAおよびEmbodied Task Planning)に沿って整理されています。代表的なQAサンプルでは、5月3日のコーヒータイマーの誤設定(04:00に設定)が5月4日のロボットによる修正(07:00)で上書きされています。カットオフは修正後に置かれており、エージェントは両方のイベントを再構築しなければなりません。

ObsMemメソッド

ObsMemはメモリをオンラインの型付きエビデンスプロセスとして扱います。インジェスト時に、オブザーバーゲートが可視性を判断します。イベントo_tとオブザーバー集合V_tおよびロボットrに対して、

\Phi(o_t)=\begin{cases}\{e_t^{\mathrm{obs}}\}\cup \mathbf{1}[\mathrm{utt}(o_t)\wedge \mathrm{actor}(o_t)\neq r]\{e_t^{\mathrm{rep}}\}, & r\in V_t,\\ \varnothing, & r\notin V_t.\end{cases}

つまり、直接観測されたアクションはobservedアトムを生成し、同じ事実に関する第三者の発話はreportedアトムを生成します。これらは単一のテキストレコードに統合されることはありません。承認された各イベントは次の3つのビューにルーティングされます:

  • Event Track:タイムスタンプ付きの履歴エビデンス。
  • State Track:実行可能なアクション(例:laptop.location=sofa)によって生成された構造化ファクトで、上書きセマンティクスをサポートします。
  • Commitment Track:発話からのリクエスト、リマインダー、スケジュール。

belief viewはロボットの認識論的確信度(observed対reported、矛盾の可能性を含む)を追跡します。クエリ時には、テキストに対する単一の密な検索を行う代わりに、エビデンスセレクターが質問タイプに基づいてビューを組み合わせ、最大5件の型付きレコードを解答生成器に返します。

結果

すべてのシステムはカットオフ制御された履歴、top-5検索上限、Gemini-3.5-flashによる解答生成、およびGPT-4oをジャッジとして共有しています(人手による再アノテーションでFleiss’ \kappa=0.71、ジャッジ・人間間の一致率87.5%、Spearman 0.82)。

310件のMemory QAサンプルにおいて、ObsMemはJudge 0.713 / Perfect 69%を達成しており、次点のA-mem(0.575 / 53%)およびMem0(0.554 / 53%)を上回っています。GraphMem(0.457)とMemoryOS(0.312)はさらに低い結果となっています。差が最も大きいのはエビデンスを要求するメトリクスです:Event R@5はObsMemが0.537であるのに対し、Mem0は0.378、A-memは0.355です。StateMH-E(マルチホップ状態QAにおけるイベントレベルのrecall)は0.452対0.264(Mem0)です。Session Any@5の差はより小さく(0.879対A-memの0.839)、粗いセッションレベルの検索はほぼ解決済みであり、未解決の問題は状態上書き下での精密なイベントレベルのエビデンス回復であることが確認されました。

62件の診断サブセットに対するablationにより、各ObsMemコンポーネントの貢献が特定されました。エビデンスセレクターの除去が最も損害が大きく(-0.264 Judge、0.435へ低下)、次いでエピソード統合(-0.145)、世界状態検索(-0.102)、belief view検索(-0.048)の順となっています。Hidden Judgeカラム(6件の「観測されるまで隠れた」質問に限定)は、belief view検索またはセレクターなしでは0に崩落し、observedとreportedの出所を区別することがhidden状態推論に必要であることが確認されました。セレクターのablationはレイテンシも半減させ(5.54s対8.82s)、品質とコストのトレードオフを露わにしています。

限界

(1)トレースはステージングされたプロンプトパイプラインを介してLLMが生成したものです。Habitatのシーンに基づきアノテーション済みエビデンスと照合して検証されていますが、GPT-4o-mini生成の分布的アーティファクトは特性評価されていません。(2)評価はLLM-as-judgeに依存しており、合理的な一致にもかかわらず\kappa=0.71には改善の余地があり、特定の表現を優遇する可能性があります。(3)5レコードのコンテキスト上限は予算を均等化するものの、より大きなコンテキストから恩恵を受けるベースラインを過小評価する可能性があります。逆に、スケール時のObsMemの型付きエビデンスの優位性も過小評価する可能性があります。(4)Embodied Task Planningの数値は本抄録では報告されておらず、ObsMemの向上がQAとは対照的にプラン生成に完全に移転するかどうかは実証されていません。(5)ObsMemは実行可能なセマンティクスを持つアクションネイティブなアクションログを必要とします。純粋に視覚的な知覚ストリームに適用するには、ここでは評価されていないアクション/状態抽出器が必要になります。

なぜ重要か

WorldLinesは身体化メモリを対話検索としてではなく、部分観測可能性と上書きの下での状態維持として再定義し、支配的なテキストメモリアーキテクチャ(Mem0、A-mem、MemoryOS、GraphMem)がセッションレベルの検索がほぼ飽和しているにもかかわらず、精密なエビデンス回復(Event R@5が0.4以下)で頭打ちになることを示しています。ObsMemの向上はほぼすべて型付きビューとオブザーバーゲートという安価な構造的事前知識から来ており、長期水平の家庭用エージェントにとっては、メモリのスキーマ設計が検索スケールよりも重要であることを示唆しています。

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

GeneralVLA-2: ロボット計画のための幾何認識再構成と管理型メモリ

GeneralVLA-2は、言語とRGB-Dをエンドエフェクタの軌跡に変換する階層型VLAスタックにおける2つの失敗モードを標的としています。第一に、元のGeneralVLAで使用されているSAM3D方式のモノキュラーオブジェクト再構成は、姿勢および未観測の幾何形状を幻覚してしまいます。これは単一視点のみ利用可能な場合の既知の問題ですが、較正済みのマルチビューRGB-Dが利用可能であれば不要な問題です。第二に、元のKnowledgeBankはフラットな検索ストアです。意味的に類似したスニペットが返され、新しいエントリが追記されるだけで、信頼度、矛盾、幾何的関連性、ライフサイクルといった概念が存在しません。どちらのボトルネックも計画エージェントに提示される証拠の質を低下させ、ひいては出力される軌跡の信頼性を損ないます。

ロボット操作のためのGeneralVLA-2の概要

システムレベルの概要は単純です(Figure 1)。対象物体の較正済みマルチビュー観測が利用可能な場合、GeoFuse-MV3Dが精緻化されたオブジェクト中心の幾何形状を生成します。この幾何形状は、管理型KnowledgeBankからの検索結果と合わせて、マルチステージのエンドエフェクタパスを出力する3D対応計画エージェントに条件として与えられ、そのパスがグラスピング・モーションモジュールによって実行されます。

GeoFuse-MV3D: 保守的な幾何形状のみの精緻化

GeoFuse-MV3DはMV-SAM3Dを置き換えるのではなく、その上に構築されています。入力は固定された5視点セット \mathcal{D}=\{(I_i, M_i, K_i, T_i)\}_{i\in\mathcal{V}_{\mathrm{in}}},\quad \mathcal{V}_{\mathrm{in}}=\{0,1,2,3,4\}, であり、RGB I_i、オブジェクトマスク M_i、内部パラメータ K_i、姿勢 T_i から構成されます。MV-SAM3Dは初期ガウシアンオブジェクト G_0=\{(x_0^j,\theta_0^j)\}_{j=1}^N, を生成します。ここで x_0^j\in\mathbb{R}^3 はガウシアン中心、\theta_0^j は不透明度、スケール、回転、SH外観をまとめたものです。GeoFuse-MV3Dは \theta を全工程において変更しません。すなわち、fusion は幾何形状のみを対象とするため、ベースラインの色・不透明度・SHはそのまま保持されます。

GeneralVLA-2におけるGeoFuse-MV3D再構成ブランチ

このブランチ(Figure 2)は、同一のマスク整合性基準でゲートされた2つの独立した幾何形状ソースを組み合わせます。ソースAはMV-SAM3Dの出力を起点とし、外部の幾何事前分布プロバイダ(実装ではVGGT)を参照したうえで、VGGTの出力がベースラインの座標・測光フレームに配置されるよう軽量な外観アフィン較正を適用します。ソースBは入力ビューによる軸補正ブランチで、外部モデルを呼び出さず、入力ビュー自体から軸ごとの小さな補正値を導出します。2つのソースを使用することで、実際のマスクとVGGT事前分布が一致しない場合にVGGT事前分布への過度な依存を回避できます。

どちらのソースも入力ビューのマスクに対してフィルタリングされます。候補点 p に対して、\mathcal{V}(p)p が投影される入力ビューの集合、\pi_i をビュー i への投影、M_i(\pi_i(p)) を双線形サンプリングされたマスク値とします。サポートスコアは s(p)=\frac{1}{\max(|\mathcal{V}(p)|,1)}\sum_{i\in\mathcal{V}(p)} M_i(\pi_i(p)) と定義されます。設計上の重要な選択は、サポートの低い点をどう扱うかです。ハード削除または不透明度の減衰はビジュアルハルパイプラインでの典型的な手法ですが、マスクにノイズがある場合には脆弱であり、穴を生じさせます。GeoFuse-MV3Dはその代わりに、サポートの低さをオブジェクト中心 c に向かった小さな内向き幾何補正に変換します。 p' = c + (p-c)(1-\lambda(p)), ここで \lambda(p) は小さな最大収縮比で上限が設けられています。これはソフトなビジュアルハル正則化器であり、弱くサポートされた幾何形状を削り取り境界に向けてわずかに押しやることで、質量を破壊せずに済みます。

点ごとのソフト補正の後、低次元の軸方向アフィン a\in\mathbb{R}^{\cdot} がガウシアン中心に適用され、同一の変換がメッシュ頂点にも同期されるため、(ガウシアンではなくメッシュを消費する可能性がある)下流のツールとの整合性が保たれます。外観パラメータは一切上書きされないため、精緻化によって fusion アーティファクトを通じた測光品質の低下は生じません。

GSO-30における定量的結果

再構成ブランチはGSO-30(Google Scanned Objects)上でMV-SAM3Dの公式プロトコルに基づいて評価されています。オブジェクトリスト、入力ビュー \{0,1,2,3,4\}、マスク、カメラ姿勢はすべて同一です。ビュー \{10,\ldots,24\} へのホールドアウトレンダリングがCD、PSNR、SSIM、LPIPSで評価されます。ベースラインと異なる点は精緻化ステージのみです。MV-SAM3Dと比較して、GeoFuse-MV3Dは以下の結果を報告しています。

  • CD: -2.20\%
  • LPIPS: -2.02\%
  • PSNR: +2.36\%
  • SSIM: +1.03\%

4つの指標すべてが同時に改善しており、これは外観を犠牲にして形状を得るトレードオフを行わない幾何形状のみの fusionの典型的な特徴です。オブジェクトごとの詳細な表は付録Aに掲載されています。

管理型KnowledgeBank

第二の貢献は、検索メモリを類似度インデックスによる追記ストアから管理型長期メモリへとアップグレードするものです。すべてのレコードは明示的なメタデータを持ちます。検証器が生成する品質ラベル、信頼度スコア、ライフサイクル状態、そして矛盾するレコードを指す競合タグです。検索は精度重視で設計されており、意味的に最近傍の上位 k 件のスニペットを返すのではなく、計画器は検証済みで矛盾がなく幾何的に関連するエントリのみを使用し、競合解決はメタデータによって行われます。3DAgentはその後、精緻化されたGeoFuse-MV3D幾何形状と管理型検索結果の共同証拠を条件として、軌跡を出力します。

限界とオープンクエスチョン

再構成の改善は絶対値では控えめ(各指標で数パーセント)であり、合理的なマスクを持つ5つの較正済みビューが利用可能であることを前提としています。マスクが大きく破損している場合や、あるクラスのオブジェクトに対してVGGT事前分布が系統的に誤っている場合の挙動については論文中で特徴付けられていません。内向きソフト補正は上限が設けられていますが、その上限値 \lambda_{\max} は感度分析が示されていないハイパーパラメータです。メモリ面では、アブストラクトでガバナンスの仕組みが説明されているものの、抜粋には管理型検索がフラット検索よりも計画器の成功率を向上させることを示すマニピュレーションタスクの数値が含まれておらず、核心となる主張にはそのアブレーション実験がまだ必要です。

なぜこれが重要か

本論文は、計画器を再学習させることなくVLAスタックをアップグレードするための有用なテンプレートを提供しています。知覚インターフェースに幾何形状のみのマスク検証済み精緻化を挿入し、メモリインターフェースに検証器・ライフサイクルのメタデータを追加しながら、ポリシーを変更しません。このパターン、すなわち安価な整合性チェックでゲートされた保守的な補正と、長期メモリに格納される内容のガバナンスは、学習済み事前分布と検索された経験を組み合わせる任意の階層型エージェントに幅広く適用可能です。

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

SpatialAvatar-0: マルチステージ再構成による高品質4Dヘッドアバター

問題

1枚または数枚のポートレートからの4Dヘッドアバター再構成は、現在表現を共有しない2つの方式に分かれています。Feed-forwardな汎化予測器(GPAvatar、GAGAvatar、Portrait4D-v2)は単一のデータセットファミリーで訓練され、ソース数 K がハードコードされており、分布バイアスが組み込まれています。一方、被験者ごとの精緻化手法(GaussianAvatars、SplattingAvatar、INSTA)は30万〜60万イテレーションを実行し、適応的な3DGS densificationに依存していますが、これは予測器が生成したGaussianレイアウトを破壊してしまうため、共有表現でのエンドツーエンド接続ができません。本論文はこのギャップを直接の標的とし、feed-forward予測器と被験者ごとの精緻化の両方を生き残る単一のFLAME拘束Gaussianレイアウトを設計することで、同じGaussianを予測してからオプションで磨き上げられるようにします。

手法

表現は貢献ではなく固定インフラです:256\times256 FLAME UVアンラップの有効ピクセルごとに1つの3D Gaussianを配置し、アイデンティティごとに \sim 58\text{K} 個のGaussianを生成し、各Gaussianは親三角形に剛体拘束されます(Xiang et al. 2023と同様)。パイプラインはこのレイアウト上の2段階で構成されます。

2段階パイプラインの概要:FLAME-UV GaussianレイアウトにわたるKソースfeed-forwardジェネレータと、その後に続くオプションの10Kイテレーションレイアウト保存精緻化器。

Stage 1 — Feed-forwardジェネレータ f_\theta f_\thetaK\in\{1,2,3,4\} 枚のソースポートレートを入力として受け取り、1回のforward passですべてのGaussianを出力します。可変ソース数はパラメータフリーなmean-poolによりソースごとのfeatureテンソルにわたって処理されます:訓練中は K\sim\text{Uniform}\{1,2,3,4\} であるため、同一の重みがmonocularとmulti-viewの両コンテキストを経験します。これが単一ネットワークで K=1K=4 を個別のheadや学習済みaggregatorなしに処理可能にする中心的なアーキテクチャ上の工夫です。

訓練は同一アーキテクチャ上の2フェーズで進行します:

  1. Phase 1 — monocular-temporal事前訓練:CelebV-HQ上で実施し、同一クリップからの時間的ペアが大規模なアイデンティティ一貫性のある監督を提供します。
  2. Phase 2 — multi-view-spatial後訓練:NeRSemble v2上で実施し、規模はずっと小さいですが真のmulti-viewジオメトリを提供します。

Phase 2のデータセットはPhase 1と比較して小さいため、単純なfine-tuningはアイデンティティpriorをNeRSembleのアイデンティティに崩壊させます。その対策として、Phase 1チェックポイント \theta_1 に対するL2-SPアンカーを用います:

\mathcal{L} = \mathcal{L}_{\text{photo}}(\theta) + \lambda \,\|\theta - \theta_1\|_2^2.

これにより、Phase 1の広いアイデンティティ分布を保持しながら、Phase 2がmulti-viewのジオメトリ手がかりを注入できるようにします。

Stage 2 — レイアウト保存被験者ごと精緻化。 標準的な3DGS精緻化では適応的densification/pruningを使用しますが、これはStage 1のUVからGaussianへの全単射を破壊します。その代わり、精緻化器は 10\text{K} イテレーション(被験者ごとの先行研究の30万〜60万と比較して)のみ実行し、FLAME拘束とGaussian数を凍結し、densificationをscale・opacity・color gradientに対する3成分のanti-spikeレギュラライゼーション(densificationが通常隠す標準的な失敗モード)に置き換えます。GaussianのインデックスとそれらのUVマップは完全に保持されるため、Stage 1で予測されたGaussianとStage 2で精緻化されたGaussianは同一のテンソルであり同一のセマンティクスを持ちます。

結果

評価プロトコルはドメイン内リークを回避するように構成されています:VFHQとHDTFはいかなる教師あり訓練ステージにも登場しないため、厳密なクロスドメインゼロショットプローブを形成します。CelebV-HQの保留スライスはアブレーション用に確保され、SplattingAvatarデータセット(クリップごとに最後の350フレームを保留)は被験者ごとの評価に使用されます。HDTFはChu et al. 2024の19クリップ分割に従います。

VFHQとHDTF上でのGAGAvatar、CVTHead、GPAvatar、Portrait4D-v2に対するゼロショット自己リエナクトメント。

定性的には、feed-forwardの比較(図2)において、本手法は同じソースバジェットでGAGAvatarやGPAvatarよりも、アイデンティティ拘束の高周波詳細(髪の毛、目の周りのspecularity、歯)をよく追跡することが示されています;CVTHeadとPortrait4D-v2が最も近い競合手法ですが、極端な表情下での詳細が失われます。定量的なテーブル(論文のTab. 1–2)はVFHQ/HDTFの数値として参照されますが、提供された抜粋においてアブストラクトは途中で途切れてヘッドライン数値の前で終わっているため、具体的なPSNR/LPIPSの差分をここで逐語的に引用することはできません。

GeoAvatar、GaussianAvatars、SplattingAvatar、INSTA、FlashAvatarに対する被験者ごとのmonocular比較。

被験者ごとの方式(図3)では、「Ours+S3」——feed-forward初期化プラス10Kイテレーション精緻化——が、GeoAvatar、GaussianAvatars、SplattingAvatar、INSTA、FlashAvatarと比較されており、これらはすべて \geq 30\times 多い精緻化イテレーションを使用します。10Kバジェットが30万〜60万イテレーションのベースラインと競争力を持つことが、Stage 2の中心的な効率性の主張です。

制限と未解決の問題

  • feed-forwardアグリゲータはパラメータフリーなmean-poolです。これは堅牢ですが、ソース条件付き重み付けを捨ててしまいます;本論文が避けている K 固有の過学習を再導入せずに、view依存attentionが K=4 で有効かどうかは不明です。
  • L2-SPは粗いアンカーです。崩壊を防ぎますが、Phase 2がmonocularデータから受け継いだPhase 1のジオメトリバイアス(例:髪と耳の深度曖昧性)をどれだけ修正できるかを制限します。
  • Gaussian数を \sim 58\text{K} に凍結することは達成可能な詳細の上限を制限します;3DGSが通常densifyする領域(睫毛、歯の端)は既存のGaussianを変形することで表現しなければなりません。
  • 提供された抜粋には数値テーブルが含まれていないため、HDTFにおけるPortrait4D-v2とのギャップや、SplattingAvatarにおけるGaussianAvatarsとのギャップの大きさをアブストラクトのみから評価することはできません。
  • 両フェーズはFLAMEトラッキングが信頼できることを前提としており、表情フィッティングの失敗はUV拘束Gaussianに直接伝播します。

重要性

本貢献は新しいレンダラーに関するものというよりも、feed-forwardと被験者ごとの3DGSアバター方式が単一の表現を共有できるようにすることで、予測されたアバターを予測器のジオメトリを捨てることなく10Kイテレーションで磨き上げられるようにする点にあります。完全なテーブルの数値が確かなものであれば、これはヘッドアバターパイプラインにおける長年の二分化を解消し、下流の4D編集やアニメーションのためのクリーンな基盤を提供します。

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

Hacker News Signals

(How to Write a (Lisp) Interpreter (In Python)) (2010)

Peter Norvigによる古典的なチュートリアルで、Schemeのサブセット(“Lispy”)をPython約90行で実装するものです。この実装は、eval/applyループ全体をカバーしており、トークン化とネストされたPythonリストをASTとして構築するparse関数、字句スコープと外部環境チェーンのためにdictをサブクラス化したEnvクラス、そしてシンボル(変数参照)、リテラル、ifdefinelambdabegin、および手続き適用に対応したケースを持つeval関数が含まれます。lambdaは定義時の環境をクロージャとして持つProcedureオブジェクトを構築し、適切な字句スコープを実現します。このインタープリタは末尾呼び出しをトランポリンではなくPythonのコールスタックで暗黙的に処理するため、深い再帰はCPythonのスタック制限に達します。算術演算およびリストのプリミティブは、PythonのbuiltinをグローバルEnvironmentに直接マッピングすることで初期化されます。このチュートリアルはSICPのeval/applyサイクルを、メタ循環抽象化レイヤーを排除した直接的な実装として示しており、具体的かつ即座に実行可能なものとなっています。続編の”Lispy2”では、適切な末尾呼び出し、マクロ、およびcall/ccが追加されています。このチュートリアルが今なお価値を持つ理由は、実際の言語に対する動作するインタープリタとは大規模なエンジニアリングプロジェクトではなく、操作的意味論を直接エンコードしたものに過ぎないことを最も明快に示す例の一つであるからです。現在も大学の講義やコンパイラエンジニアのオンボーディング演習として活用されています。

Source: https://norvig.com/lispy.html


Sakana Fugu

Sakana AIのFuguは、合成的ニューラルネットワーク推論のためのフレームワークです。具体的には、fine-tuningを行わずに推論時に複数の事前学習済みモデルを組み合わせるものです。核心的なアイデアは「重み空間におけるモデルマージ」を実行時に拡張したものであり、モデルスープやTIES-mergingのようにチェックポイントをオフラインで平均化するのではなく、Fuguは活性化や重みの寄与を動的にルーティングします。技術的なメカニズムは、入力に条件付けられたベースモデルのライブラリに対して、タスク固有の組み合わせ係数を計算することを含んでおり、これは単一モデルの各層の内部で行われるよりも、異なるモデルチェックポイントをまたいで適用されるmixture-of-expertsルーティングに近い手法です。このフレームワークは特化のコストを削減するものとして位置づけられています。つまり、タスクごとに新しいモデルをfine-tuningする代わりに、既存のモデルを組み合わせるというアプローチです。公開されたベンチマークによると、タスク固有のfine-tuneと比較してホールドアウトタスクにおいて競争力のある性能を示しており、合成のオーバーヘッドは小さな線形結合のパスにとどまります。未解決の問題としては、ルーティング係数の学習方法(別個のメタネットワークなのかgradient-freeサーチなのか)、ベースモデルライブラリが大規模化した際のスケーラビリティ、そして候補モデル間のアーキテクチャの不一致に対するアプローチの感度が挙げられます。「Fugu」という名称は日本語のフグ(河豚)に由来しており、Sakanaが採用している魚をテーマにした命名規則を踏襲しています。今回のリリースにはモデルカードと推論コードが含まれているようであり、その基盤となる研究は、同じベースから各組織がそれぞれfine-tuningを行うことによる冗長な計算コストの削減を目指すものとして位置づけられています。

Source: https://sakana.ai/fugu/


Apertus – ソブリンAIのためのオープンファウンデーションモデル

Apertusは、「ソブリンAI」デプロイメントを目的としたオープンウェイトのファウンデーションモデルとして自らを位置づけています。これは、米国ハイパースケーラーのAPIに依存することなく、モデルの重み・学習データの来歴・推論インフラに対する完全な管理を必要とする組織を対象としています。技術的な核心は、いくつかの具体的な主張に集約されます。すなわち、完全なオープンウェイト(研究目的に限定されないもの)、学習データ構成の開示、そしてオンプレミスデプロイメントのサポートです。このモデルは、GDPRや施行が進むEU AI Actの義務のもとで、データレジデンシーや監査可能性の要件により、クローズドなAPIモデルの利用が法的・運用上困難となっているヨーロッパの公共部門および企業ユースケースをターゲットとしているように見えます。アーキテクチャ上、このモデルはtransformerベースのLLMとして説明されていますが、パラメータ数や学習計算量といった具体的な情報はランディングページに prominently開示されておらず、再現性の観点からは懸念材料です。「ソブリン」というフレーミングは、狭義においては技術的に意味のあるものです。オープンウェイトはエアギャップ環境でのデプロイメント、重みの検査、ベンダーロックインなしのfine-tuningを可能にするものであり、これはガバナンスや地政学的な主張とは異なります。既存のオープンウェイトモデル(Llama、Mistral、Qwen)に対して宣伝されている主な技術的差別化要素は、ヨーロッパの学習データ構成とコンプライアンス文書です。これらの代替モデルと比較して競争力のあるbenchmarkパフォーマンスを達成しているかどうかは、公開資料からは明確に確認できません。この分野はすでに競合が多く、興味深いエンジニアリング上の問いは、オープンウェイトLLMを対象とした専用のコンプライアンスツール(監査証跡、データプロvenance、差分プライバシーの証明)が真の競争優位性を構成し得るかどうかです。

Source: https://apertvs.ai/


Qwen 3:0.6BのようなローカルLLMを質問分類にfine-tuningして良好な結果を得る

多クラステキスト分類タスクに向けてQwen3-0.6Bにsupervised fine-tuning(SFT)を適用する実践的なウォークスルーです。アプローチの概要:カテゴリにマッピングされた質問のラベル付きデータセットを構築し、instruction-tuningの形式(system prompt+ユーザーの質問+assistantのラベル)にフォーマットし、UnslothなどによるLoRAの標準的なセットアップでSFTを実行します。0.6Bパラメータであれば、モデルはCPUのRAMや最小限のVRAMに余裕を持って収まるため、GPUクラスターなしでもワークフローを実行できます。本記事では、数百から数千程度のラベル付き事例に対するgradient stepsが適度な回数に達した時点で、ホールドアウト事例における分類精度が実用的な閾値に到達したと報告しています。これは、ベースモデルがすでに関連する事前知識を持ち、出力空間が制約されている場合(オープンエンドな生成ではなく、固定された小さなラベルセット)、小規模なドメイン固有データセットへのSFTがうまく転移するという確立された知見と一致しています。主要な技術的観察点:(1)このスケールでは、ハイパーパラメータチューニングよりもinstruction formatの方が重要である;(2)0.6Bモデルは曖昧なカテゴリでは大規模モデルに劣るが、明確な識別が可能なケースでは十分な性能を発揮する;(3)CPUでの推論レイテンシは非同期分類パイプラインには許容範囲内である。より広い視点で言えば、分類のためにサブ10億パラメータモデルをfine-tuningすることは、今やルーチンなエンジニアリング作業であり、研究プロジェクトではありません。ツール群(Unsloth、llama.cpp、Ollama)により障壁が大幅に低下し、古典的なテキスト分類のためのsklearnとほぼ同程度になっており、特徴量エンジニアリングが不要という利点もあります。

Source: https://www.teachmecoolstuff.com/viewarticle/fine-tuning-a-local-llm-to-categorize-questions


Goにおける過剰なNilポインタチェック

Goコードにおけるよくあるコードスメルの診断:正確性のために実際に必要な範囲を超えて、防衛的な if x == nil { return } ガードがコードベース全体に増殖してしまう問題です。著者は3つのカテゴリを区別しています:(1) nilレシーバーやポインタがパニックを引き起こすため、真に必要なチェック;(2) 正常に動作しているプログラムではそのコールサイトにnilが来るべきでないという設計上の欠陥を糊塗するチェック;(3) 不確実性から追加され、ノイズとして蓄積されていくチェック。技術的な主張として、カテゴリ2および3のチェックは有害であるとされています。なぜなら、これらはバグを早期に露出させるはずのパニックを抑制し、APIの契約として公開することを意図していないnilケースについて呼び出し元が考慮することを強制するからです。これは他の言語コミュニティにおけるnull安全性の議論と構造的に類似しています。GoにはOption型や非null許容参照型(RustにおけるTとOption<T>、KotlinにおけるTとT?のような)が存在しないため、型システムでその区別を強制することができず、慣例とコードレビューに委ねられることになります。この投稿では、nilがその値に対して文書化された意図的な状態であるかどうかを基準にnilチェックを監査することを推奨しています。そうでない場合は、チェックを削除してテスト中にパニックを発生させるか、nilを表現不可能にするようAPIを再設計する(例えば、ポインタではなく構造体を返す、センチネルオブジェクトパターンを使用する)べきとしています。HNのコメントは実質的な内容を含んでおり、これがlinterによる対処を必要とする言語設計上の制限なのか、それともGoの型システムの正しい使い方を反映しているのかについての議論が展開されています。

Source: https://konradreiche.com/blog/excessive-nil-pointer-checks-in-go/


Lisp in the Rust Type System

RustのトレイトシステムにLispインタープリタを完全にエンコードしたRustライブラリです。計算は実行時ではなく、トレイト解決によってコンパイル時に行われます。この実装ではLispの値をRustの型として表現します。コンスセルはジェネリック構造体 Cons<H, T> となり、nilはユニット型、シンボルはゼロサイズのマーカー型として表現されます。評価は関連型出力を持つ Eval トレイトを実装することで駆動され、コンパイラはトレイト境界を再帰的に解決することで、型検査の過程でLispの評価を実行します。これは、Rustのトレイトソルバーがチューリング完全(再帰の上限を除く)であるという事実を利用した、よく知られた「型レベルプログラミング」手法の一変形です。実用上の上限はコンパイラの再帰制限(#![recursion_limit = "..."])であり、これを引き上げることはできますが、コンパイル時間の爆発的増大を招きます。このエンコーディングはメタ循環評価器の構造を忠実に反映しています。Eval<Env> は、その型がシンボル(トレイトを介した環境ルックアップ)、リテラル(恒等)、先頭が Quote であるコンスセル(末尾を未評価のまま返す)、あるいは一般的な適用(先頭を関数型に評価してから適用)のいずれであるかによってディスパッチします。ラムダ抽象は、引数型に Apply されると本体型への代入を行い再評価する型としてエンコードされます。エラーケースはトレイト未実装のコンパイラエラーとして現れます。このプロジェクトは主として型システムの表現力のデモンストレーションですが、同様の手法は組み込みRustにおける正当なコンパイル時計算(例えば、const genericsや物理単位のための typenum)の基盤にもなっています。

Source: https://github.com/playX18/lisp-in-types/


Deno Desktop

Denoの新しいDesktopモードは、既存のDenoランタイム上にネイティブなウィンドウ操作とUIのAPIを公開し、JavaScript/TypeScriptプログラムがフルのChromiumインスタンスをバンドルすること(Electronモデル)なしに、OSネイティブのウィンドウ、メニュー、ダイアログを作成できるようにします。技術的なアーキテクチャとしては、プラットフォームのウィンドウ操作APIをラップする薄いRustレイヤーを使用しており、イベントループとウィンドウ管理にはwinit、ウィンドウ内でのオプションのHTMLレンダリングにはwryまたは類似のWebViewクレートが用いられていると考えられます。これらはJavaScriptから呼び出し可能なDeno opsとして公開されています。このスタックはTauriが採用しているものと同一であり、比較対象として最も自然な選択肢です。Electronとの主な違いはメモリフットプリントにあります。V8とChromiumを一緒に同梱しないことで、ランタイムのオーバーヘッドが大幅に低減されます。Tauriとの主な違いは、Deno DesktopがRustファーストのバックエンドモデルではなく、Denoの既存のエコシステムをターゲットにしている点です。JSランタイムが主要なアプリケーション層であり、Rustコアの薄いフロントエンドではありません。APIサーフェスにはDeno.desktop.createWindow()、ウィンドウのライフサイクルに関するevent listener、そしてDenoのパーミッションモデルとの統合が含まれており、デスクトップアプリは同じケイパビリティベースのセキュリティサンドボックスを継承します。注目すべき未解決の問題はレンダリングです。ネイティブウィジェットのレンダリングはプラットフォーム間で一貫性がないことで知られており、WebViewへのフォールバックパスはエンジンの差異(macOSではWebKit、WindowsではWebView2)を再導入します。HNのディスカッションでは、Tauriとの比較や、JSファーストモデルが既存の選択肢と比較して開発体験を簡素化するのか複雑化するのかについて、実質的な議論が行われています。

Source: https://docs.deno.com/runtime/desktop/


PDFをスキャン済みのように見せる(CLIまたはブラウザ上でWASM経由で動作)

各PDFページにスキャンの外観をシミュレートする画像劣化変換のパイプラインを適用する、CLIツールおよびブラウザベースのユーティリティです。処理パイプラインはラスター画像としてレンダリングされた各ページに対して実行され、以下の処理が含まれます:ページごとのわずかなランダム回転(用紙のずれをシミュレート)、Gaussian blur(レンズ・フォーカスの不完全さ)、輝度・コントラストの変動、Gaussian noiseの付加(センサーグレイン)、コーヒーのシミや折り目のオーバーレイ(オプション)、および低品質でのJPEG圧縮(スキャナーの圧縮アーティファクト)。ブラウザ版は、EmscriptenまたはWASM-packを通じて同じパイプラインをWebAssemblyにコンパイルし、サーバーへのラウンドトリップなしにクライアントサイドで処理を行えます。これは、ユーザーがサードパーティのサービスにドキュメントをアップロードしたくないという明白なユースケースにおいて重要です。実装にはOpenCV(ジオメトリ変換とblur用)またはPillow/PIL相当のライブラリを組み合わせて使用しており、PDFレンダリングはPyMuPDFやpdf2imageのようなライブラリで処理されます。各変換はパラメーター化されており、劣化の強度を制御できます。WASMビルドは技術的に興味深い点があります。それはネイティブ依存関係を持つPDFレンダリングライブラリをWASMターゲットにバンドルする必要があるためで、これは容易ではありません。おそらくこのリポジトリはこれを回避するために、事前にレンダリングされたラスター中間形式を使用していると思われます。正当なユースケースとしては、劣化した入力に対するOCRパイプラインのテスト、ドキュメント管理システムのためのアーカイブシミュレーション、文書復元モデルの学習データ生成などが挙げられます。HNのコメントには予想通り文書偽造に関する議論が含まれていますが、技術的な内容は応用的な画像処理パイプラインです。

Source: https://github.com/overflowy/make-look-scanned

注目の新しいリポジトリ

Soul-AILab/SoulX-Transcriber

話者分離(誰が)、時間的セグメンテーション(いつ)、ASR(何を)という3つの相互依存するサブ問題を同時に解く、マルチスピーカー転写のためのエンドツーエンドパイプラインです。多くの本番パイプラインではこれらを別々に連鎖させるため、各受け渡し時点でエラーが蓄積されますが、SoulX-Transcriberはこれらを統合的にモデル化することで、話者とワードの割り当てミスマッチを低減します。アーキテクチャは、話者 embedding モジュールとsequence-to-sequence ASRバックボーンを組み合わせており、話者の同一性が後付けのラベルとして適用されるのではなく、transcript生成を条件付ける形で協調動作します。本フレームワークは、重複発話や可変話者数を扱うことができ、これらは直列パイプラインにおいて最も連鎖的な障害を引き起こす2つの失敗モードです。会議の転写、ポッドキャストのインデックス作成、そして単語の正確性と同様に話者の帰属が重要な法律・医療ディクテーションにおいて実用的な有用性を持ちます。リポジトリには、一般的な音声フォーマットの前処理ユーティリティ、標準的な話者分離メトリクス(DER、話者ごとのWER)に対する評価スクリプト、およびドメイン固有コーパスへの fine-tuning 用のサンプルconfigが含まれています。合理的な速度での推論にはCUDA対応GPUが必要です。

Source: https://github.com/Soul-AILab/SoulX-Transcriber


Totoro-jam/battle-tested-patterns

実際のプロダクションコードベース(React、Linuxカーネル、GoのStandard Library、Chromiumなど)から抽出した設計・実装パターンを、ソースへのリンク付きでまとめたキュレーションカタログです。一般的なパターン書籍との大きな違いは、各エントリが実際のリポジトリ上のコミットまたはファイルを直接指していることで、読者はおもちゃのような例示ではなく、本物の産業的なコンテキストの中でパターンを確認できます。カバー範囲は、フロントエンドの状態管理イディオム(React)、カーネル同期プリミティブとメモリ管理の工夫(Linux)、Goの並行処理パターン(goroutineのライフサイクル管理、context伝播)、ブラウザエンジンのアーキテクチャに関する設計判断(Chromium)など多岐にわたります。各パターンエントリには、概念が異なるランタイム間で通用する場合の多言語サンプルと、概念をハンズオンで検証できる実行可能な演習が含まれています。このリポジトリは、プロダクションコードを読んで学ぶエンジニアのうち、大規模コードベースをナビゲートして関連する断片を見つけるコストが高いと感じている人にとって特に価値があります。このリポジトリは、そのような検索をあらかじめインデックス化したものといえます。

Source: https://github.com/Totoro-jam/battle-tested-patterns


yaroslav/kino

Ruby 4.0のRactor並行プリミティブをターゲットとしたRuby Webサーバーで、分割ランタイムアーキテクチャを中心に設計されています。ネットワーク層はTokio(非同期I/Oランタイム)とHyper(HTTP/1.1およびHTTP/2)を用いてRustで実装されており、コネクションのacceptやTLS処理、リクエストのパースをほぼゼロのGIL競合で処理します。パース済みのリクエストはRuby Ractorワーカーに引き渡され、各ワーカーは真の並列実行を行います(RactorはGVLを迂回するRubyのアクターモデル分離ユニットです)。グローバルなミュータブル状態に依存するほとんどのgemをRactorの厳格なオブジェクト共有制限が破壊するため、まだRactor安全でないRack middlewareとの互換性のためにスレッドベースのフォールバックモードも提供されています。サーバーはRack 3の標準インターフェースを公開しているため、依存ライブラリがRactor対応である範囲において、既存のアプリケーションをそのまま利用できます。このアーキテクチャはRubyが歴史的にマルチコアハードウェアを活用できなかった問題への直接的な応答であり、KinoはRactorモデルがI/Oバウンドなプロダクションワークロードに対して実用的かどうかを検証する初期の具体的な実験です。Rubyパフォーマンスエンジニアや、Ruby 4.0の並行処理動向を追っている方にとって注目すべきプロジェクトです。

Source: https://github.com/yaroslav/kino


opengeos/geolibre-rust

Whitebox Geospatialの次世代ツールセット向けのWebAssemblyコンパイルターゲットに加え、GeoLibre固有の新しいツールを提供するプロジェクトで、GeoLibreブラウザ環境においてクライアントサイドで動作するよう構築されています。このツールチェーンはRust製の地理空間アルゴリズムをWASI(WebAssembly System Interface)にコンパイルし、地形解析・水文モデリング・LiDAR派生処理といったラスタおよびベクタ処理を、サーバーへのラウンドトリップなしにブラウザ内で実行可能にします。単純なEmscripten WASMではなくWASIを採用することで、ファイルシステムの抽象化とWASMランタイム間の優れた可搬性を実現しています。基盤となるWhiteboxツールがRust製であるため、WASMバイナリはコンパクトであり、計算上のホットパスはRustのゼロコスト抽象化の恩恵を受けます。地理空間処理のワークロードはバイナリサイズと計算コストの問題から従来はサーバーサイドで処理されてきましたが、エッジやブラウザ上で実行できることは、オフライン対応のGISアプリケーション、データプライバシーが求められるシナリオ、およびバックエンドインフラの削減において重要な意味を持ちます。このリポジトリにはビルドスクリプト、WASI互換のshim、およびGeoLibre JSフロントエンドとの統合のためのグルーコードが含まれています。

Source: https://github.com/opengeos/geolibre-rust


vedika-io/xalen-ephemeris

9つの占星術の伝統(ヴェーダ(ジョーティシュ)、西洋熱帯占星術、中国式、およびその他6つのシステム)にわたって惑星位置を計算するための純粋なRustライブラリです。計算コアはSwiss Ephemerisアルゴリズム——JPL DEシリーズの惑星テーブルに対する数値積分——を、C FFI依存なしのsafe Rustで実装しており、これがlibsweのラッパーとの主な差別化点となっています。9つの伝統をサポートするには、それぞれ異なる参照フレームを扱う必要があります。ヴェーダ系ではさまざまなアヤナムシャ補正(ラヒリ、クリシュナムルティ、ラーマン)を伴う恒星黄道帯、西洋系では熱帯黄道座標、中国系では太陰太陽暦の算術演算です。本ライブラリはユニファイドなクエリAPIを公開しており、ユリウス日と伝統識別子を受け取り、その伝統の座標系における惑星経度、ハウスカスプ、アスペクトテーブルを返します。純粋なRustにより、ブラウザ展開向けのWASMおよび組み込みターゲットへのコンパイルが可能です。これだけ多くの伝統をサポートしているのは珍しく、ほとんどのオープンソースのephemerisライブラリは1〜2つのシステムしか対応していません。C言語ライブラリの依存関係を管理せずに、正確性の保証とクロスシステム間での均一性を必要とする占星術アプリケーションを構築する開発者にとって有用です。

Source: https://github.com/vedika-io/xalen-ephemeris


Albert-Weasker/niubi_guard

GitHubリポジトリの不正利用パターン——スパムリポジトリ、偽スターキャンペーン、依存関係混乱攻撃(dependency confusion attacks)、悪意のあるパッケージ公開、および組織的な不正行為——を対象とした自動検出・対応システムです。検出パイプラインは、GitHub APIのメタデータに対してヒューリスティックとML classifierを適用します。具体的には、アカウントごとのリポジトリ作成速度、スター獲得率の曲線(有機的な成長と一括購入によるバースト的増加の識別)、forkグラフのトポロジー、そしてコミット著者の異常などが対象となります。対応レイヤーでは、自動的な不正利用報告の送信やアラートパイプラインのトリガーが可能です。これは実践的に重要な問題です。npm/PyPI/GitHubのエコシステムでは、スター数やfork数が付与する「正当性の外見」を悪用したサプライチェーン攻撃が繰り返し発生しています。本リポジトリはオープンソースであるため、検出ロジックの監査や適応が可能です——防御側は不正利用の手口が進化するにつれてヒューリスティックを更新する必要があるため、これは重要な点です。CIパイプラインへのintegration hooksにより、組織が利用している依存関係を継続的に監視することができます。オープンソースパッケージレジストリや大規模な依存関係グラフを管理するセキュリティチームに最も直接的に適用可能です。

Source: https://github.com/Albert-Weasker/niubi_guard


eli-labz/Third-Eye

ソーシャルメディアモニタリング、インフラ列挙、地理空間シグナル相関、文書・画像解析、ダークウェブインデックス化など、複数のインテリジェンスドメインにわたる統合的な状況認識を提供する、プロダクショングレードのOSINTアグリゲーションプラットフォームです。アーキテクチャは、コレクションモジュール(ソースごとのスクレイパーおよびAPIクライアント)を、異種データを共通のエンティティグラフに正規化する分析レイヤーから分離しており、クロスドメイン相関を実現しています。例えば、ユーザー名をIPレンジに、さらに画像のEXIFデータから抽出した物理的な位置情報に結びつけることが可能です。グラフベースのエンティティ解決により、単一のデータソースを個別に調査するだけでは見えないような関係性をアナリストが浮き彫りにできます。本プラットフォームは、セキュリティオペレーション、脅威インテリジェンス、調査報道、レッドチームによる偵察といったユースケースを対象としています。ここでいう「プロダクショングレード」とは、アドホックなスクリプトの集合ではなく、永続的なストレージバックエンド、レート制限を考慮したコレクションスケジューリング、そしてアナリストが操作するためのAPIまたはUIレイヤーを備えることを意味します。このレベルの統合を持つOSINTツールは、一般的に商用製品か断片的な実装のいずれかであり、統合されたオープンソースプラットフォームによって、規模の小さいセキュリティチームの参入障壁が低下します。

Source: https://github.com/eli-labz/Third-Eye


dongshuyan/compass-skills

COMPASS(司南)はAIエージェント向けのスキル・オペレーティングシステムであり、タスク仕様とエージェント実行の間に位置する構造化レイヤーとして、特定のユーザーやコンテキストに対してどのように能力を選択・組み合わせ・パーソナライズするかを管理します。中核となる抽象化概念は「Skill」であり、プロンプト戦略・ツール呼び出しパターン・コンテキストスキーマをカプセル化したモジュール単位で、事前条件と事後条件のメタデータを持つ関数に類似しています。中央のタスクコントローラーは、セマンティックルーティングを通じて受信リクエストをスキルにマッチングさせることで処理を振り分け、複合タスクが必要な場合にはマルチスキルチェーンをオーケストレーションします。パーソナライゼーションはファーストクラスの機能として扱われており、スキル選択にバイアスをかけてスキル実行をパラメータ化するユーザーごとの嗜好プロファイルを維持することで、汎用的なエージェント動作とユーザーに沿った動作のギャップを解消します。これは、LLMエージェントフレームワークにおいて能力自体は存在するものの、ルーティングや個々のユーザーの意図へのアラインメントが脆弱であるという一般的な失敗パターンを対象としています。バイリンガル(中国語・英語)のドキュメントと「Personal Alignment」という切り口は、コンシューマー向けエージェント製品への注力を示唆しています。生のtool-calling APIが提供するよりも構造化されたスキル管理を必要とする、エージェントオーケストレーションレイヤーを構築する方々に関連性の高い取り組みです。

Source: https://github.com/dongshuyan/compass-skills