アーカイブ / AI Agent / LLM
操作履歴から支援の時点と根拠を選ぶ時系列グラフ手法
Temporal Graph Learning (TGL)
概要
- 操作イベントとファイルなどの対象を時系列グラフにし、支援する時点と提案の根拠を一回のモデル処理で判定する。
- 著者らのProactiveAgentテスト集合での比較では、14種類の下流言語モデルすべてでF1が上がり、平均上昇幅は16.7ポイントだった。
- 発火判定のAUCは、支援が必須のイベントを上位に並べる条件で0.738。著者らの測定ではGPUサーバーでイベント当たり11.13ミリ秒だった。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Temporal Graph Learning (TGL)の仕組み
- 01時刻付き操作
- 02操作と対象のグラフ
- 03発火と対象を判定
- 04対象付き提案文
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
先回りして支援するエージェントには、利用者の操作ごとに、今支援するか、何を根拠に提案するかという二つの判断が要る。毎回LLMに操作内容を文章で渡す構成では、支援しない場面でも判定のための呼び出しが発生する。
操作履歴には、誰が、何を、どの対象に、いつ行ったかという構造がある。同じファイルなどが複数の操作に現れる関係を保つことで、支援の時点と提案に添える対象を一緒に扱える。
手法
ファイル編集や検索などの時刻付き操作から、操作と、ファイル・アプリ・URLなどの対象を規則で取り出す。操作と対象を点、両者の関係や操作の時間順を線にしたものが「時系列グラフ」だ。例えば同じファイルを開いて後で編集した場合、そのファイルを両方の操作に関わる対象として表せる。
TGLはグラフを一回処理し、各操作で支援を始める確率と、各対象が根拠として関連する度合いを出す。確率が設定した境界を超えたときだけ、得点の高い対象を構造化した情報として下流のLLMへ渡す。LLMが利用者向けの提案文を作り、境界を超えなければ呼び出さない。
新規性
著者らの提案は、支援を始めるかというイベント単位の判定と、提案の根拠にする対象の選択を、同じ時系列グラフの表現から得る点にある。二つの出力は別々の判定器が担うが、グラフを読む本体を共有し、同時に学習する。
一回のモデル処理で発火確率と対象ごとの関連度を出し、文章生成用の大規模言語モデル（LLM）は発火時だけ呼ぶ。常時行う判定と利用者向けの文章作成を分ける構成である。
従来手法との違い
提案文の評価では、ProactiveAgentの従来のプロンプト方式と、TGLが選んだ対象を構造化して同じ下流言語モデルへ渡す方式を比べた。この比較では、発火判定に加え、渡す対象とプロンプトも変わる。
発火判定の比較では、規則、表形式の特徴量を使う分類器、操作を文章として扱う分類器、LLMを用いた方式を検証した。学習を伴う比較対象には同じ教師情報を使い、対象の選択と下流モデルは固定して、発火判定器の違いを調べている。
実験結果
著者らはデスクトップ操作のProactiveAgentテスト集合で、14種類の下流言語モデルを評価した。従来方式と比べ、提案文の評価に用いるF1は全14モデルで3.1～46.0ポイント上昇し、平均上昇幅は16.7ポイントだった。各表の値は3回の実行を集計した結果である。
発火判定では、支援が必須のイベントを上位に並べる性能を示すAUCがTGLで0.738だった。著者らの測定では、処理時間はGPUサーバーでイベント当たり11.13ミリ秒、一般向けノートPCで13.99ミリ秒だった。別の操作履歴で同じ値になるかは、この結果から判断できない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：開発作業中、支援候補を示す時点と参照ファイルを選ぶ試行が考えられる。入力源は利用を許可された操作ログとし、ファイルを開く・編集する操作、検索語、時刻を記録する。発火時だけ選ばれた対象名を下流の言語モデルへ渡し、対象を明示した短い提案を得る。
導入先では、支援の要否を示すイベント単位のラベルと、根拠となる対象のラベルを用意する必要がある。操作ログを取得する仕組みが観測源となり、別のセンサーを要するかは記録環境に応じて確認する。対象名の抽出規則を導入先のログ形式に合わせる。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：利用を許可された操作ログを集め、イベントごとの支援の要否と、根拠にするファイルなどの対象にラベルを付ける。ログを観測源とし、追加センサーが必要かを確認する。対象と時刻の抽出規則を決め、導入先の記録形式と教師ラベルに合わせてモデルを学習させる。
比較基準には、同じ履歴を文章にして発火を判断する方式を置く。別に確保した記録で、発火のF1、不要な提案の割合、対象選択の正しさ、イベント当たりの処理時間を測る。提案文が実際の作業対象を正しく指すかも人が確認する。
限界と課題
確認できた本文の範囲では、著者らは操作履歴にファイル名、URL、検索語などの機微な情報が含まれると述べ、モデルの常駐容量を約220 MiBと報告している。本文が途中で切れているため、論文の限界節に書かれた事項を著者の報告として確認することはできない。
編集上の検証事項は、導入先の操作ログから必要なイベントと対象を安定して抽出できるか、教師ラベルを一貫して付けられるかである。誤った割り込みへの利用者の反応、下流モデルへ渡す情報の範囲、長期運用時の処理時間も別途確かめたい。
出典
元のタイトル・要旨を確認する（英語）
Do Proactive Agents Really Need an LLM to Decide When to Wake and What to Anchor?
Proactive agents read user activity as text and call an LLM on every event to decide whether to act. But user activity is not natively text: it is a structured event stream of (actor, verb, object, timestamp) tuples that the operating system already maintains in graph form. Rendering the structure as text and asking an LLM to recover it is a round-trip the system never had to take. We treat the always-on signal as graph updates rather than text and use a small temporal-graph-learning (TGL) model as the encoder: one forward pass yields a per-event trigger probability and a per-entity routing score, and only the downstream agent (turning a small structured handoff into a fluent user-facing sentence) is an LLM call, invoked only when the trigger fires. TGL improves F1 on each of 14 backbones (mean +16.7, up to +46.0); in trigger-architecture comparisons, one TGL checkpoint gives the strongest trigger AUCs and the most stable deployed threshold. It runs at 11.13 ms per event on a GPU server and 13.99 ms on a consumer laptop, approximately 4--7x and 12--83x faster than every single-forward LLM-as-trigger configuration tested in each regime, with an approximately 220 MiB BF16 resident footprint deployable on-device alongside the privacy-sensitive activity stream it consumes.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01