# 時系列質問応答
## 定義
時系列質問応答(time series question-answering, TSQA)は、自然言語の質問を投げかけて時系列の性質を推論・判断するタスク。基盤モデルの有望ながら未開拓の能力とされ、複数の時系列や時間的パターンにまたがる推論を要する。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]]) ソフトウェアインシデント対応では、エンジニアがオブザーバビリティメトリクスに対して「このパターンは異常か」「2 つの系列は相関しているか」と問いを繰り返す行為が TSQA として自然に定式化され、下流の意思決定(トリアージ・緩和・RCA)を支える。
[[ARFBench]] は TSQA を**多肢選択の単一クラス分類問題**に落とし込む設計を取る。異常理解を「異常の時間範囲の予測」(従来の異常検知ベンチマークの形式)としてではなく、相対的に正解 1 つを選ぶ多肢選択にすることで、正解境界の曖昧さ・ラベルの主観性・専用評価指標の難しさを回避する。質問は段階的に難化する 3 ティア(Presence → 単一系列の異常性質 → 系列間の関連推論)で構成され、高位ティアは下位の正しい推論に依存する。
## 横断的知見
- (1 ソース目のため横断はまだ限定的。隣接概念との関係を以下に置く。)
- **TSQA は異常検知を「予測タスク」から「推論タスク」へ組み替える試みである**: 従来の[[異常検知]]ベンチマークが異常の時間範囲を出力させ、正解境界の曖昧さと専用指標(VUS 等)の難しさを抱えるのに対し、[[ARFBench]] は多肢選択化でこの境界問題を回避し、インシデント対応の下流意思決定に関連する高レベルの異常推論を測る。これは [[MonitorAssistant]]([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]])が「実用的異常」を統計的逸脱 + インシデント裏付けに再定義したのと同じ問題意識——「何を異常と見なし、どう評価するか」を業務文脈に寄せる——を、ベンチマーク形式の側から実装している。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]])
- **観測 TSFM の評価軸が「予測精度」から「推論能力(TSQA)」へ拡張している**: [[Toto]]/[[BOOM]]([[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]])が観測メトリクスの予測精度を競うのに対し、同じ Datadog AI Research チームの [[ARFBench]] は Toto を VLM と結合した [[Toto-1.0-QA-Experimental]] で TSQA の推論能力を評価する。予測専用 TSFM が TSQA の時系列エンコーダとして再利用され、評価の関心が「どれだけ正確に予測できるか」から「時系列を見て何を推論できるか」へ移っている。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]])
- **マルチモーダル観測データの「正常な急変動」が TSQA でも検知・分類を欺く**: [[ARFBench]] では VLM が異常の有無(Presence/Tier I)は得意だが性質判定(Tier II)で人間に劣り、Tier III(系列間推論)が最難。これは [[TelecomTS]]([[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]])が報告した「正常なストリーミング起因スパイクの偽陽性」問題と同じく、観測データの文脈依存性がモデルの異常理解を難しくする構図。両ソースとも観測ドメインの TSQA/検知で LLM/VLM の限界を共有する。(Source: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]], [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]])
- **TSQA は「ベンチマーク + 専用モデル」の方向と「LLM の推論時スケーリング」の方向に分岐している**: ARFBench / TelecomTS が観測ドメインの TSQA ベンチマークと VLM ベース解法を提示するのに対し、[[@2026__ICLR2026__TimeOmni-1 - Incentivizing Complex Reasoning with Time Series in Large Language Models]] は TSR-Suite(23K サンプル、4 アトミックタスク)という汎用 TSQA ベンチマークを提案し、SFT + GRPO で TimeOmni-1 が GPT-4.1 を因果発見精度 40.6%(ID)・28.1%(OOD)上回ることを示す。TSQA の評価軸が「特定ドメインでの推論精度」(ARFBench: インシデント対応)から「タスク横断の能力スイート」(TSR-Suite: シナリオ理解 / 因果発見 / イベント認識予測 / 意思決定)へ拡張しつつある (Source: [[@2026__ICLR2026__TimeOmni-1 - Incentivizing Complex Reasoning with Time Series in Large Language Models]], [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])。
- **「真に推論を要する TSQA タスク」の判定基準が初めて形式化された**: TimeOmni-1 は推論報酬原則(推論モデルが非推論モデルを有意に上回るタスクのみ採用)と文脈充足原則(入力が不十分なら理想推論者でもランダム推測になる)を導入し、TSQA タスクの設計品質を測る指標を提供する。既存の TSQA ベンチマーク(ARFBench/TelecomTS 含む)がこの 2 原則を満たすかは別途検証が必要だが、TSQA タスク設計の方法論として独立した価値を持つ (Source: [[@2026__ICLR2026__TimeOmni-1 - Incentivizing Complex Reasoning with Time Series in Large Language Models]])。
- **時系列を LLM に入力する形式(テキスト / 画像 / 専用エンコーダ)で TSQA 性能が大きく変わる**: [[@2024__arXiv__Towards Time-Series Reasoning with LLMs]] は時系列をテキスト・プロット画像・キャプション・専用トークンに変換した 4 形式を体系的に比較し、軽量パッチエンコーダ(MLP)+ LoRA が病因論的推論で最良。プロット画像変換も VLM で機能するが、テキスト変換は知覚ボトルネックを生む。これは ARFBench で「LLM 同一モデルの VLM 版に劣る」観察と同方向で、TSQA の表現形式の選択がモデル能力以上に性能を決定する (Source: [[@2024__arXiv__Towards Time-Series Reasoning with LLMs]], [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]])。
## 未解決の問い
- [[ARFBench]] はシングルターン QA に限られ、緩和戦略の推奨(「この異常からリソースを増強すべきか」)やインシデントパターンへの紐づけ(「この異常はデプロイに直結するか」)といった自由形式・マルチターン・エージェント的な問いを含まない。TSQA をエージェント型のインシデント調査ループ(検知→トリアージ→診断)へ拡張する設計は未着手。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] §5)
- TSFM-VLM ハイブリッド([[Toto-1.0-QA-Experimental]])が特定タスクで好成績を出す理由と、時系列エンコーダ・VLM の結合学習の何が効いているのかが未解明。SFT 段が RL の収束を速める効果の機序も含めて訓練ダイナミクスが未理解。([[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] §4.5)
- モデルと人間専門家の誤り分布が相補的(Model-Expert Oracle で精度 87.2%)という観察を、実運用のインシデント対応にどう取り込むか。モデルが専門家を補強する human-in-the-loop の設計は、[[MonitorAssistant]] の LLM-Engineer-In-The-Loop と接続するか。
- ARFBench は Datadog 単一ベンダの内部テレメトリ由来。他の観測プラットフォーム・他組織のインシデントへの TSQA 能力の汎化は未検証。「オラクル」VLM がラベルを生成する半自動構築の偏りが残る可能性も未評価。
- LLM は同一モデルの VLM 版に劣る(時系列をプロット画像として与える方が表形式より有効)が、高変量・長系列(中央値 10.5 変量・最大 2283)ではプロットも context-length も破綻する。専用の時系列トークン化(variate embedding)とプロット入力のどちらが本質的に優位かは未決着。
- TimeOmni-1 の TSR-Suite(汎用 4 タスク)と ARFBench(インシデント特化)・TelecomTS(通信特化)はベンチマーク設計の粒度が異なる。「ドメイン汎用」と「ドメイン特化」の TSQA 能力は同じ基盤モデルで両立しうるか、トレードオフがあるか未検証。
- TimeOmni-1 が示した「ジョイント訓練で 4 タスクが相互補完する」効果は ARFBench/TelecomTS の特化タスクでも成り立つか。汎用 TSR-Suite の能力を観測 TSQA に転移する効率はどの程度か。
- 時系列の入力形式(テキスト/画像/エンコーダ)とタスク種別(分類/予測/QA)の最適な組合せをマッピングする系統的研究は未着手。Chow+ の発見は分類タスクでの観察に限られる。
## 関連
- ソース: [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]] / [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]] / [[@2026__ICML__TelecomTS - A Multi-Modal Observability Dataset for Time Series and Language Analysis]] / [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]
- 概念: [[時系列基盤モデル]] / [[異常検知]] / [[インシデント管理]] / [[エージェント型時系列予測]]
- エンティティ: [[ARFBench]] / [[Toto-1.0-QA-Experimental]] / [[Toto]] / [[Qwen3-VL]] / [[Datadog]] / [[TelecomTS]]
- 関連 MOC: [[時系列基盤モデル - MOC]] / [[Telemetry - MOC]]
## 出典
- [[@2026__arXiv__ARFBench - Benchmarking Time Series Question Answering Ability for Software Incident Response]](§1 TSQA の定義、§3.1–3.2 問題定義とティア設計、§4 実験結果)