地熱発電所の運転員が、運転の記録・過去のトラブルの対処記録・メーカーの技術資料を Vertex AI Search で検索し、異常の兆候から対処の前例とその後の経過を根拠付きで引く

処理の起点を決める

運転員が調査の画面で、設備の番号を選び、兆候の文を書いて送信したことを起点にします。 監視の数字から自動で起動する形にはしません。数字の変化の多くは、季節や出力の調整による、説明のつくものです。 調べるかどうかは、画面を見た運転員が決めます。

送信すると、answer メソッドと search メソッドを同時に呼びます。 公式ページでは、10件を超える検索結果がほしいときや、答えの生成を待たずに結果を先に見せたいときは、search メソッドと answer メソッドを一緒に使うとされています。一覧が先に出て、答えはそのあとに出ます。

同じ兆候を次の班が調べ直すときは、同じ会話として続けます。 公式ページでは、前の問い合わせのセッションを渡すと、続きとして問えるとされています。調査の画面は、事象ごとにセッションの ID を持たせ、引き継ぎの欄と一緒に次の班へ渡します。

入力データを集める

質を決めるのは、事象の記録の「その後の経過」と「効いたかどうか」の項目です。 15年分の日誌から束ねるときに、処置の後の日付の記事を読み、効いた・一部効いた・効かなかった・不明の4つのどれかを付けます。 不明のまま残すものもありますが、空欄にはしません。

記録からは、人の名前と外部との連絡の中身を外して入れます。 日誌には、連絡した相手や当番の名前が書かれています。検索に要るのは設備の状態と処置で、人の名前は要りません。 書き出しの段で、決まった欄と名前の一覧に当たる文字列を消します。

データの取得方法を決める

事象は、1件を1つの文書にしてメタデータを付けます。 公式ページでは、非構造のデータのメタデータは JSON Lines（NDJSON）のファイルで、各行に id、structData（または jsonData）、Cloud Storage の文書を指す content の mimeType と uri を持たせるとされています。1件は、たとえば次の1行にします。

{"id": "evt-2024-0137",
 "structData": {"doc_kind": "event", "equipment_ids": ["PW-07", "SEP-2"],
                "equipment_type": "production_well", "event_kind": "流量の低下",
                "noticed_at": "2024-02-11", "closed_at": "2024-03-04",
                "outcome": "一部効いた", "operation_change": true},
 "content": {"mimeType": "text/plain", "uri": "gs://<bucket>/event/evt-2024-0137.txt"}}

本文の文書には、日付順に日誌の記事の抜き書きを並べます。 「2月11日 坑口の圧力が下がり始めた」「2月15日 坑内の点検を依頼」「3月4日 流量が戻った」のように、元の日誌のファイル名と日付を各行に付けます。 引用から元のファイルに戻れるようにするためです。

過去の15年分の束ね直しは、一度だけの大きな作業です。 そのあとは、事象が終わるたびに運転員が下書きを確かめて登録し、毎晩の書き出しで足します。公式ページでは、取り込めるファイルの上限は200MBで、一度に100,000ファイルまで取り込めるとされています。

メーカーの資料は、データストアを作るときに文書の分割（チャンキング）とレイアウトの解析を有効にします。 公式ページでは、RAG に使うならデータストアを作るときに文書の分割を有効にするよう勧められています。分割はデータストアを作ったあとに有効・無効を切り替えられず、見出しを各チャンクに付ける includeAncestorHeadings は既定で無効です。取扱説明書は章と節で意味が決まるので、作るときに有効にします。

AIへ渡す前に整形する

1. 設備の特定 … 設備の番号から、設備の種類と、つながる坑井・気水分離器・配管を引きます
2. 番号の正規化 … 全角・半角、ハイフンの有無をそろえ、記録と同じ表記にします
3. 絞り込みの条件の組み立て … 選んだ設備と、つながる設備の番号のどれかに一致する事象に絞ります
4. 資料の絞り込み … メーカーの資料は、設備の種類が合うものに絞ります
5. 問い合わせ文の作成 … 兆候の文に、設備の種類と季節を足して問い合わせ文にします

3番目で、つながる設備まで広げるのが地熱らしいところです。 気水分離器の兆候の前例は、その分離器の番号ではなく、つながる生産井の番号で書かれていることがあります。 設備台帳のつながりを使い、絞り込みの条件を「この設備か、つながる設備のどれか」にします。

絞り込みの条件は、たとえば次のようになります（公式ページの書き方による）。

filter（事象の記録）:
  doc_kind: ANY("event")
  AND equipment_ids: ANY("PW-07", "SEP-2", "PIPE-07A")
  AND noticed_at >= "2011-01-01"
filter（メーカーの資料）:
  doc_kind: ANY("manual") AND equipment_type: ANY("separator")

公式ページでは、ANY は指定した値のどれかに完全に一致するときに真になり、日付の項目は ISO 8601 の文字列で比べられるとされています。絞り込みに使う項目は、スキーマの画面でインデックス可能にしておく必要があります。answer メソッドの検索の段でも、絞り込みを指定できるとされています。

AIに処理させる

answer メソッドにさせるのは、絞り込んだ事象の記録と資料から、今回の兆候に近い前例を探し、処置とその後の経過、関係する資料の箇所を引用付きで短くまとめることです。 判断はさせません。

2行目がいちばん大事です。 前例の処置には、還元の量や蒸気の配分を変えたものが含まれます。前例として読むことと、今回の処置として勧めることは別です。 中継プログラムは、operation_change が真の事象を引用した文に印を付けます。

指示内容を固定する

answer メソッドでは、回答の口調や詳しさをプロンプトの前置き（preamble）で指定できます。前置きを次のようにします。

あなたは地熱発電所の運転の記録の係です。運転員が気づいた異常の兆候について、
検索で見つかった事象の記録、メーカーの資料、運転の要領だけを根拠に、
次の順で短く答えてください。

1. 似た兆候の前例（事象のID、気づいた日、兆候の書き方）
2. そのときの処置と処置の日
3. その後の経過（効いたかどうか、戻るまでの日数、再発の有無）
4. 関係する資料の箇所（資料の名前、章・節、版）
5. 運転の要領の連絡と判断の手続きの該当箇所

守ること：
- 原因を断定しないでください。前例として、根拠の箇所を示してください。
- 運転の条件を変える、出力を下げる、止めるといった判断を勧めないでください。
  前例にそうした処置があっても、「当時の処置」として書いてください。
- その後の経過が記録に無い前例は、「経過の記録なし」と書いてください。
  効いたものとして扱わないでください。
- 設備の番号、数値、単位は原文の表記のまま写してください。
- 別の設備の前例を、この設備のものとして書かないでください。
- 検索結果に無いことを書かないでください。見つからなければ「前例なし」としてください。

「経過の記録なし」を効いたものとして扱わない、を書くのは、文章が自然に「処置をして解決した」と結ぼうとするからです。 前例の半分近くは、効いたかどうかが日誌から読み取れないかもしれません。それを効いたように書くと、効かなかった処置が繰り返されます。

あわせて、answer メソッドの設定を次のようにします。

公式ページでは、filteringLevel を入れなければ支持の度合いによる絞り込みは掛からず、支持が基準に届かない答えは返されず、LOW_GROUNDED_CONTENT として理由が返るとされています。返されなかったときの画面の出し方は、例外処理で決めます。

出力形式を固定する

中継プログラムが、2つの呼び出しの応答を次の形にそろえて調査の画面に渡します。

{
  "request_id": "",
  "equipment_id": "",
  "related_equipment": [],
  "symptom_text": "",
  "answer_text": "",
  "support_score": 0.0,
  "skipped_reason": "",
  "citations": [
    { "sentence": "", "doc_kind": "", "doc_id": "", "section": "", "quote": "", "operation_change_flag": false }
  ],
  "events_all": [
    { "event_id": "", "noticed_at": "", "closed_at": "", "event_kind": "", "outcome": "" }
  ],
  "outcome_stats": { "effective": 0, "partial": 0, "not_effective": 0, "unknown": 0 },
  "handover": { "checked_events": [], "reported_to": "", "next_check": "", "session_id": "" }
}

1つ目の理由は、events_all と outcome_stats を答えと別に持てることです。 同じ設備の前例が、効いた・効かなかった・不明でそれぞれ何件あるかが、答えの文を読む前に分かります。不明が多ければ、答えの前例を読むときに慎重になれます。

2つ目は、operation_change_flag で印を持てることです。 真の引用は、画面で色を変え、横に運転の要領の判断の手続きの箇所を並べます。

3つ目は、handover に session_id を持てることです。 次の班は、同じ会話の続きとして問い直せます。ゆっくり進む兆候では、調べものが何日も続くからです。

システムへ連携する

事象の記録の登録は、事象が終わってから運転員が確かめて行います。 中継プログラムは、引き継ぎの欄と日誌から下書きを作るまでです。事象の記録は次の検索の材料なので、確かめていない文が混ざると、誤りが次の答えに入ります。

アプリとデータストアのつなぎ方は、最初に決めます。 公式ページでは、データストアをアプリにつないだあとは外せないとされています（複数のデータストアをつなぐ検索では、2つ以上を残す範囲で足し外しできる）。メーカーとの取り決めで見られる人を限る資料は、その資料だけのデータストアにし、見られる人が使うアプリにつなぎます。

人が確認する

1. 一覧の件数を先に見る … 同じ設備の前例の数と、効いた・効かなかった・不明の内訳を確かめます
2. 引用の原文を開いて読む … 前例の兆候が今回と似ているかを、日誌の抜き書きで読みます
3. 前例の時期と今を比べる … 前例の後に、坑井の清掃や設備の改修がないかを設備台帳で確かめます
4. 色の変わった引用を確かめる … 運転の条件の変更を含む前例は、運転の要領の手続きに従います
5. 当直の責任者に報告する … 引用した前例と経過を添えて報告します
6. 当直の責任者が決める … 処置と運転の条件を、保安規程と運転の要領に従って決めます

3番目を省かないでください。 前例の後に坑井の清掃をしていれば、同じ下がり方でも、意味が違うことがあります。 答えは前例の当時の状態を知りません。

目標は、240件をならして1件10分です。 一覧を見て、原文を読み、設備台帳と比べ、報告と引き継ぎを書く時間です。ファイルを開いて探す時間がほぼ無くなり、確かめる時間が残ります。

例外に対処する

下の2行の「検索を待たない」「いまどおり」は、常に残しておきます。 この構成は、ゆっくり進む兆候を調べる時間を短くするもので、急に進む異常の初動には使いません。

記録を残す

• 調査の依頼（設備の番号、兆候の文、気づいた日時、依頼した人）
• 絞り込みの条件、answer メソッドと search メソッドの応答の全文、セッションの ID
• 画面に出した答えと、外した文、色を変えた引用
• 運転員が開いた原文、報告した相手と時刻
• 引き継ぎの欄の内容と、登録した事象の記録
• 資料の版、データストアに入れた日、事象の記録の書き出しの日

5つ目が、いまは残っていない記録です。 どの前例を見て、誰に報告したかが残れば、次の班は前の班の続きから調べられます。 事象が終わったときに、その経過がそのまま次の前例になります。