10月15日 13:15~ ## スライド ![[okabelab_meeting_202210.pdf]] ## やったこと - Train Ticketの性能の安定化 3週間 - Train Ticket向けの評価スクリプト 2週間 - TSifter評価 3週間 - ジャーナル査読ｘ4 1週間 + @ - 会社仕事 1週間 + @ ## アウトライン - 直近でCORE Rank B相当の国際会議への投稿機会がないため、IEEE ACCESSに向けて投稿準備中。 - 不採録かつ再投稿のために根本的な修正が必要となる場合は、IPSJの論文誌ジャーナルへ投稿予定。 - 進捗サマリー 1. 単一システムの実験では、提案手法の一般性が不明 → 別システムのデータセットを作成可能とした。 2. 時系列データの正常と異常の定義が主観的である → 既存研究（[[2021__ISSRE__Identifying Root-Cause Metrics for Incident Diagnosis in Online Service Systems|Wu+, ISSRE2021]]）が商用環境にて調査した異常パターンを採用した。 3. 2.をもとに提案手法の評価の詳細を設計した。 - 現在、実験作業中のため、議論できるような評価結果はまだない。 - 用語の整理 - [[FaultとFailureの差異]] - 評価の詳細の設計 - 評価では、以下の問いに応える - RQ1: **次元削減性能評価** 提案手法は時系列データの次元削減にどのように機能するか？ - RQ2: **部位評価** 提案手法の主要コンポーネントは全体のパフォーマンスに貢献しているか？ - RQ3: **時間コスト評価** 提案手法はどの程度効率的に動作するか？ - RQ4: 既存の故障局在化プロセスの前にTSifterを実行したときにTSifterは貢献しているか？ - RQ5: 提案手法はデータセットのパラメータやハイパーパラメータにどの程度敏感か？