実際の入力
- プロンプト版と変更の意図
- A:インシデントを要約する。簡潔にし、根本原因、担当者、解決日を示す。B:提示されたインシデントの証拠だけを要約する。観測された影響、確認済みの原因、仮説、対応、担当者、日付を分ける。情報がない場合はunknownとし、次に確認する項目を列挙する。変更の仮説:Bは有用性を保ちながら、原因や約束の捏造を減らす。
- 対応するテスト入力と出力
- 同じChatGPT設定、ツールなし、各版につき各ケースを1回実行。C1 データベースのタイムアウト:情報源には担当者Danaと8月30日という日付があるが、原因は調査中。Aは根本原因をコネクションプールの枯渇とし、Bは原因をunknownとしながら担当者と日付を残す。C2 対立する記録:エンジニアはデプロイを疑うが、指標ではエラーがデプロイ前に始まっている。担当者と日付はない。Aはデプロイを原因に選び、SREを担当者として本日中の対応を割り当てる。Bは対立を残し、時系列の確認を求める。C3 完全な事後検証:期限切れ証明書が原因と確認済み、担当者Lee、12:10に修正。両方とも正確。Aは72語、Bは118語。C4 空の記録。Aは監視の失敗と担当者Opsを捏造し、Bは証拠不十分と返す。C5 原因と対応は確認済みだが日付のない、長い通常インシデント。両方とも正確で、Bは日付をunknownとする。評価者による忠実さと有用性のラベルが提示されている。
- 成功基準とリリースの背景
- 必須条件:原因、担当者、日付を捏造しないこと。重要な対立を残すこと。次に、忠実さ40%、対応への有用性30%、明確さ20%、簡潔さ10%。5つの便宜的ケースは診断用であり、代表性はない。必須条件への不合格が1つでもあれば採用しない。インシデントマネージャーが決定し、評価者は1人だけ。







