SaaS 企業のサポートが、新しい問い合わせに近い回答の定型文（マクロ）と解決済みのチケットを OpenSearch のハイブリッド検索で探し、書き換える点を添えて担当に示す

処理の起点を決める

起点は3つあります。毎晩の定型文と解決済みのチケットの取り込み、5分ごとの新しいチケットの取り込み、担当の「合わなかった」の印です。

新しいチケットは、Zendesk の増分の書き出し（Incremental Ticket Export）で5分ごとに取ります。公式のドキュメントでは、増分の書き出しは1分あたり10回まで呼べ、直近の1分のデータは返さないとされています。問い合わせが届いてから内部メモが付くまで、数分の遅れがあることを担当に伝えます。

取ったチケットの問い合わせの文は、チケットのコメントの一覧で取ります。公式のドキュメントでは、コメントの一覧は1ページ最大100件で、コメントごとに plain_body（文字だけの本文）と、公開か内部メモかを表す public を持つとされています。問い合わせの文は最初の公開のコメントの plain_body から取ります。

定型文は、毎晩、定型文の一覧（List Macros）で取ります。公式のドキュメントでは1ページ最大100件で、only_viewable を true にするとチケットに当てられる定型文だけに絞れるとされています。active が false の定型文は、索引に残したまま検索から外します。

入力データを集める

質を決めるのは、定型文の中身です。 古い手順の定型文が有効のまま残っていると、検索はそれも正しく見つけます。 取り込みのときに、最終の更新から1年を超えた定型文を一覧にして、定型文の担当に見直しを頼みます。

定型文の使われた回数は、候補の並びの参考に出します。 公式のドキュメントでは、定型文の一覧に直近1時間・24時間・7日・30日の使われた回数を合わせて取る指定（sideload）があり、Support Professional か Suite Growth 以上のプランで使えるとされています。

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

ハイブリッド検索は、検索のパイプラインで点数をそろえてから合わせます。 公式のドキュメントでは、hybrid は複数の問い合わせの点数を1つにまとめるもので、問い合わせは最大5つ、点数は検索のパイプラインで合わせるとされています。normalization-processor は、語の検索とベクトルの検索の点数の尺度が違うため、合わせる前にそろえるものとされ、そろえ方の既定は min_max、合わせ方の既定は arithmetic_mean、weights で問い合わせごとの重みを合計1で決められます。

PUT /_search/pipeline/macro-hybrid
{
  "phase_results_processors": [ { "normalization-processor": {
    "normalization": { "technique": "min_max" },
    "combination": { "technique": "arithmetic_mean",
      "parameters": { "weights": [0.4, 0.6] } } } } ]
}

GET /macros/_search?search_pipeline=macro-hybrid
{
  "size": 5,
  "_source": ["macro_id", "title", "category", "updated_at", "usage_30d"],
  "query": { "hybrid": {
    "filter": { "bool": { "filter": [
      { "term": { "active": true } },
      { "terms": { "plans": ["standard"] } } ] } },
    "queries": [
      { "match": { "body": "二段階認証のコードが届かずログインできない" } },
      { "knn": { "body_vector": { "vector": [0.012, -0.031], "k": 20 } } } ] } }
}

hybrid を function_score の中に入れません。 公式のドキュメントでは、hybrid は検索の最上位に置くもので、function_score などの包む問い合わせの中に入れると実行時のエラーになるか、そろえる処理が黙って飛ばされることがあるとされています。使われた回数で点数を上げたくなりますが、点数には混ぜず、画面に回数を並べるだけにします。

min_max の性質を知っておきます。 公式のドキュメントでは、問い合わせごとに、返った結果の中の最小と最大で0〜1にそろえ、最も点の高い文書が必ず1.0になるとされています。どの候補も遠い問い合わせでも、一番上は1.0になります。 点数の高さで「合っている」と判断しないで、語の一致とベクトルの両方に当たったか、片方だけかを候補に出します。

埋め込みの値は、取り込みのときと検索のときで input_type を分けます。 AWS の公式ページでは、Cohere Embed の input_type は、ベクトルの索引に入れる文書には search_document、検索の問い合わせには search_query を使うとされています。

AIへ渡す前に整形する

1. 個人の情報を伏せる … 問い合わせと返信の文から、メールアドレス・電話番号・人の名前・契約の番号を、Lambda の規則で ［メール］ などに置き換えます
2. 署名と引用を外す … メールの署名と、前の返信の引用を外します
3. 長さをそろえる … 埋め込みは1件512トークンまでなので、問い合わせは件名と最初の段落を、返信は最初の段落と手順の部分を埋め込みます
4. 機能名をそろえる … 機能とプランの表で、「2FA」「二段階認証」を同じ語にして語の検索の項目に足します
5. 定型文の本文を取り出す … 定型文の actions のうち、コメントに入る文を本文にします
6. もとになった定型文の候補を付ける … 解決済みのチケットの最後の返信で定型文の索引を引き、上位の定型文の番号を source_macros に持たせます

3番目で truncate を NONE にします。 AWS の公式ページでは、Cohere Embed の truncate は既定が END で、長すぎる入力は末尾を捨てて埋め込み、NONE にすると長すぎる入力でエラーを返すとされています。黙って切られると、問い合わせの肝心の部分が埋め込みに入らないまま検索されます。 エラーになった文は、短くしてから入れ直します。

6番目の候補は「推した」ものです。 返信は担当が書き換えているので、もとの定型文と一致するとは限りません。画面には「過去のチケットの返信に近い定型文」と出し、「このチケットで使われた定型文」とは書きません。

AIに処理させる

AIの仕事は1つです。 検索が返した定型文の候補ごとに、問い合わせに合わせて書き換える点と、定型文が答えていない点を書くことです。

返信の文を書き上げさせないのが、この構成でいちばん大事な線です。 定型文は、会社として確かめた言い方と手順が入った文です。AIが書き直した文は、その確かめを通っていません。 担当が定型文を当て、書き換える点に沿って直せば、確かめた文から外れずに済みます。

会社としての判断を答えさせないのも同じ理由です。 返金や料金の例外、障害の原因は、定型文に書かれていても、問い合わせごとに担当や上の担当が決めます。答えていない点にこれらが入っていたら、「担当の判断が必要」と書かせます。

指示内容を固定する

あなたはクラウドサービスのサポートで、担当が回答の定型文を選ぶのを助ける立場です。
【候補】は検索が返した定型文です。【問い合わせ】は客の文で、個人の情報は伏せてあります。

【書くこと（候補ごと）】
- macro_id: 候補の番号。【候補】の番号をそのまま写す
- edits: 問い合わせに合わせて変える部分。定型文の中の文を「」で写し、何に変えるかを
  問い合わせの文から書く。問い合わせに書かれていなければ「確かめる」と書く
- unanswered: 問い合わせにあって、この定型文が答えていない質問。問い合わせの文のまま写す
- needs_decision: unanswered のうち、返金・料金の例外・障害の原因・今後の予定に関わるもの

【厳守事項】
- 【候補】に無い定型文を挙げないでください。
- 返信の文を書かないでください。edits は変える部分の指摘だけにしてください。
- 返金・料金の例外・障害の原因・今後の予定について、答えを書かないでください。
- 候補の順位を変えないでください。どれが正しいかも書かないでください。
- 客のプランや権限が問い合わせに書かれていなければ、推し量らずに「確かめる」と書いてください。

【問い合わせ】{question}
【候補】{macros}
【似た解決済みのチケット】{tickets}

「定型文の中の文を「」で写す」を書くのは、照合のためです。 写した文が定型文の本文に無ければ、AIが定型文を言い換えたか、別の定型文と混ぜたかのどちらかです。Lambda が本文と照らし、無い文の指摘は内部メモから外します。

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、次の形で受け取ります。

{
  "ticket_id": 0,
  "candidates": [
    { "macro_id": 0, "matched_by": "both | keyword | vector",
      "edits": [ { "quote": "", "change_to": "" } ],
      "unanswered": [""], "needs_decision": [""] } ],
  "similar_tickets": [ { "ticket_id": 0, "source_macros": [0] } ],
  "to_confirm": [""]
}

AWS の公式ページでは、Converse API の outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えるとされています。すべての object に additionalProperties: false が要り、任意の項目は全体で12個までです。 matched_by は enum で縛り、Lambda が検索の結果から入れた値と照らします。

1つ目の理由は、macro_id と quote を照合できることです。 macro_id が検索の結果に無いとき、quote が定型文の本文に無いときは、その候補か指摘を外します。

2つ目は、内部メモを決まった形で書けることです。 内部メモは次の形にします。

【定型文の候補】（自動。返信の前に担当が確かめてください）
1. ログイン_二段階認証_コード未着（#1234）／語と意味の両方で一致／直近30日 86回
   書き換え：「管理画面の［セキュリティ］」→ 問い合わせはスマホのアプリから
   答えていない点：「機種を変えた場合はどうなるか」
2. ……
【似た解決済みのチケット】#98765（返信に近い定型文：#1234）
【担当の判断が必要】なし

内部メモは public を false にしたコメントとして書きます。 公式のドキュメントでは、コメントの public が false のものは内部メモです。客に見えるコメントとして書かないことを、Lambda の書き込みの処理で固定します。

システムへ連携する

定型文を当てた後の見え方は、チケットを変えずに取れます。 公式のドキュメントでは、Show Ticket After Changes は定型文を当てた後のチケットの全体を返し、実際にはチケットを変えないとされています。定型文が状態や担当のグループも変える場合は、その変更を内部メモに書き添えます。 担当が当てたときに、思わぬ変更に気づけます。

人が確認する

1. 候補を見る … 内部メモの候補から定型文を選びます。合うものが無ければ、いつもどおり探します
2. 書き換える点を見る … 指摘に沿って、定型文を当てた後の文を直します
3. 答えていない点を見る … 手順書で答えを足すか、上の担当に回します
4. 担当の判断が必要な点を回す … 返金・料金の例外・障害の原因は、決まった担当に回します
5. 印を付ける … 候補が合わなかったら「合わなかった」の印を付けます

3番目を省かないでください。 定型文は1つの質問に答える文で、問い合わせの2つ目の質問は、定型文を当てただけでは答えられていません。

例外に対処する

1行目の「片方のみ一致」は、見落としの多い候補です。 ベクトルだけで当たった候補は、言い方は近いが別の機能の定型文であることがあります。

記録を残す

• チケットごとの、伏せ字にした問い合わせの文、検索の条件、候補と点数と当たった道
• AIの出力と、照合で外した指摘
• 内部メモに書いた内容と書いた時刻
• 担当が選んだ定型文と「合わなかった」の印
• 検索のパイプラインの重みと、機能とプランの表を見直した日と担当

4つ目が、重みと定型文の見直しの材料です。 「合わなかった」が多い問い合わせの種類は、定型文が足りないか、古いかのどちらかです。