ECサイトの検索で0件・少数だった検索語を毎月集めて原因で分類し、同義語辞書と表記ゆれの登録候補を作って商品が見つかるようにする

処理の起点を決める

月初の定時実行で動かします。 前月の1日から末日までの検索ログを対象にします。毎日動かさないのは、同義語の行は1語ずつではなく、まとまりで判断したほうが矛盾に気づけるからです。 「スマホケース」と「スマホカバー」の行が別の日に別々に足されると、重なりに気づけません。

例外として、セールや新商品の発売の前には、臨時で動かします。 特集ページを出す商品群について、前月の0件の語のうちその売場に関係するものだけを先に処理します。

取り出す条件は2つです。 ヒット件数が0件の語と、1〜3件の語です。少数ヒットの語を入れるのは、0件と同じくらいお客様が困っているからです。 「電気毛布」で探して1件だけ出た場合、残りの電気毛布は商品名が「電気ブランケット」になっていて出ていないことがあります。

入力データを集める

質を決めるのは、商品の候補の集め方です。 生成AIは、渡された候補の中から根拠を探します。候補に正しい商品が入っていなければ、原因を「取り扱いなし」と分類するしかありません。 次の「データの取得方法」で、候補を集める検索を3通りに分けているのはそのためです。

検索ログには、個人を特定できる情報を入れません。 検索語に電話番号や氏名を入れるお客様がまれにいるため、取り出す段階で数字の並びやメールアドレスの形のものを外します。

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

検索ログは、検索のたびにサイトのアプリケーションが書き出しているものを使います。 検索語、ヒット件数、日時、その後に商品ページを開いたかを1行にします。ヒット件数は、検索エンジンが返した件数をそのまま書きます。

商品の候補は、本番の検索とは別の条件で集めます。 本番の検索で0件だったのですから、同じ条件で探しても出ません。

3つの集め方で出た商品を合わせ、1語あたり最大10件を候補にします。 どの集め方で出たかも候補に付けて渡します。表記ゆれは断片の一致で、言い換えは説明文の一致で出ることが多く、どの集め方で出たかが分類の手がかりになります。

文字の断片の項目は、候補を集めるための検証用の索引にだけ持たせます。 本番の索引に足すと、本番の検索の結果まで変わります。

AIへ渡す前に整形する

1. ログの整理 … 前後の空白を取り、全角と半角、大文字と小文字をそろえてから同じ語をまとめます
2. 個人情報らしい語の除外 … 数字が8けた以上続くもの、メールアドレスの形のものを外します
3. ボットの除外 … 同じ時刻に同じ語が大量に出ているもの、意味の無い文字列を外します
4. 件数での絞り込み … 0件の語と1〜3件の語を、それぞれ検索回数の順に並べ、上位を対象にします
5. 既存の辞書との照合 … すでに辞書にある語は、辞書の行が効いていない理由を別に調べるため、印を付けます
6. 候補の収集 … 3つの集め方で商品の候補を集めます
7. 候補が0件の語の扱い … 3つの集め方でも1件も出ない語は、生成AIに渡さず「候補なし」として一覧に残します

5番目を省かないでください。 辞書にあるのに0件の語は、辞書の行の書き方が誤っているか、解析器の設定でその行が効いていないことを示しています。新しい行を足しても直りません。

7番目で生成AIに渡さないのは、根拠の無い分類を作らせないためです。 候補が無いと、生成AIは一般的な知識から「言い換え」と分類し、自社が扱っていない商品名を辞書の候補に書くことがあります。

AIに処理させる

させるのは、検索語ごとに、渡された商品の候補を根拠にして原因を1つ選び、辞書で直せるものについて辞書に足す行の候補を作ることです。

辞書の行は、同じ意味として扱う形（a, b, c）と、片方向に置き換える形（a => b）を使い分けさせます。 誤字は片方向です。「ふとn => 布団」は要っても、逆向きの行は要りません。 言い換えでも、意味の範囲が違うものは片方向にします。「ブランケット」で「ひざかけ」を出すのはよくても、「ひざかけ」で大判のブランケットまで出す必要はありません。

3行目が、いちばん起きやすい失敗です。 「電動自転車」で0件のサイトに、候補として「自転車用ライト」が出ていると、関係がありそうだという理由で言い換えにします。 候補の商品が、検索語と同じ物かを判断の基準にし、関係がある物では結ばないことを指示に書きます。

指示内容を固定する

あなたはECサイトの検索の担当者を手伝います。
お客様が検索して0件または数件しか出なかった検索語について、
原因を分類し、同義語辞書に足す行の候補を作ってください。

【分類】次の中から1つ選んでください。
- variant ........ 表記ゆれ。候補の商品名と、文字の書き方だけが違う
- synonym ........ 言い換え。候補の商品と同じ物を、別の言葉で呼んでいる
- typo ........... 誤字・打ち間違い。候補の商品名の書き損じ
- model_number ... 型番の書き方の違い（ハイフン・空白・大文字小文字）
- attribute_missing 候補に同じ種類の商品はあるが、検索語の性質
                    （例：撥水、静音）が商品名・説明文に書かれていない
- not_carried .... 候補の中に、検索語と同じ物が無い
- too_broad ...... 検索語が広すぎ、言い換えで結ぶと多くの検索が変わる
- unclear ........ 判断できない

【厳守事項】
- 判断の根拠は、渡した商品の候補だけにしてください。
  一般的な知識で、自社が扱っている商品を想像しないでください。
- 辞書の行に書く言葉は、検索語と、候補の商品名・カテゴリ名に
  実際に出てくる言葉だけにしてください。
- 候補の商品が、検索語と「同じ物」のときだけ、variant / synonym /
  typo / model_number を選んでください。
  関係がある物、一緒に使う物、似た用途の物は not_carried です。
- 誤字は片方向（誤 => 正）にしてください。
- 意味の範囲が違う言い換えは、片方向にしてください。
- 1語だけで意味の広い言葉（例：ケース、カバー、マット、収納）を
  同じ意味の行に入れないでください。too_broad にしてください。
- evidence_ids には、判断の根拠にした商品IDを書いてください。
- 迷ったときは unclear にしてください。

【検索語】{query}（前月の検索回数 {count} 回、ヒット件数 {hits} 件）
【商品の候補】{candidates}（商品ID、商品名、カテゴリ、出た集め方）
【この語を含む既存の辞書の行】{existing_rules}

「同じ物のときだけ」を、関係がある物の例まで挙げて書いています。 書かないと、一緒に使う物（「プリンター」と「インク」）や、似た用途の物（「加湿器」と「除湿機」）を言い換えにします。辞書に入れば、検索のたびに別の商品が出ます。

広い語を名指しで禁じているのは、1行の影響が大きいからです。 例として挙げた4語は、どれも商品名の後半に付く語です。これらを含む行は、その語を含む全部の検索に効きます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "query": "",
  "category": "variant | synonym | typo | model_number | attribute_missing | not_carried | too_broad | unclear",
  "rule": {
    "type": "equivalent | one_way | none",
    "line": "",
    "terms": []
  },
  "evidence_ids": [],
  "route_to": "dictionary | product_page | merchandising | reviewer",
  "note": ""
}

1つ目の理由は、category と route_to で、送り先を機械で分けられることです。 辞書の候補は担当者の一覧へ、attribute_missing は商品ページの担当へ、not_carried は商品部門へ、自動で振り分けます。category は enum で決まった値しか返らないため、分類の名前の書き方のゆれで振り分けが漏れることがありません。

2つ目は、rule.line をそのまま辞書の形式で受け取れることです。 line には スマホケース, スマホカバー, スマートフォンケース や ふとn => 布団 の形で入ります。terms に行の中の語を分けて持たせ、ワークフローがその語が検索語か候補の商品名・カテゴリ名に実際に出てくるかを照らします。 出てこない語が入っていれば、行を却下します。

3つ目は、evidence_ids で担当者の確認が速くなることです。 一覧で根拠の商品を開けば、同じ物かどうかを画像で確かめられます。

構造化出力は、JSON スキーマに沿った応答を制約付きのデコードで保証します。 enum と required が使え、スキーマに合わない応答をやり直す必要がありません。ただし、数値の minimum や文字列の maxLength のような制約は使えないため、terms の数や行の長さはワークフローの側で確かめます。

システムへ連携する

検証用の索引で、反映の前に結果を比べます。 本番と同じ商品データと解析器を持つ索引に、候補を足した辞書を入れ、前月の検索回数の上位1,000語の上位10件の商品が、どれだけ入れ替わるかを数えます。大きく入れ替わる語があれば、その原因になった行に印を付けて担当者の一覧に出します。

本番への反映は、パッケージの更新で行います。 辞書のファイルを S3 に置き直し、パッケージを更新し、ドメインに更新を適用します。関連付けの状態が有効（Active）になるのを待ってから、反映した語で検索して確かめます。

辞書のファイルの大きさにも気をつけます。 ドキュメントでは、辞書ファイルは大きさに比例して Java のヒープを使うとされています。毎月足すだけで消さないと、辞書は大きくなり続けます。

人が確認する

担当者が見るのは、辞書の候補の行です。 900語のうち、辞書の候補になるのは一部で、残りは各部門への一覧と却下の記録です。

1. 印の付いた行を先に見る … 検証用の索引で上位の語の結果を大きく変えた行、既存の辞書と重なる・矛盾する行です
2. 根拠の商品を開く … evidence_ids の商品を開き、検索語と同じ物かを確かめます
3. 同じ意味か片方向かを決める … 意味の範囲が違えば片方向に直します
4. 採用・修正・却下を記録する … 却下には理由を付けます
5. unclear を見る … 担当者が判断し、判断がつかなければ売場の担当に聞きます

1番目を必ず先に見てください。 上位の語の結果を変える行は、採用すれば翌日から何万回もの検索に効きます。 0件の語を1つ直すために、よく使われる検索を崩していないかを確かめます。

目標は、900語をならして1語2分です。 辞書の候補は根拠の商品を開いて見るので数分かかり、各部門への一覧と却下は流し見で数秒です。

例外に対処する

3行目で既存の行を自動で消さないのは、行の理由が残っていないからです。 古い行にも、当時の売場の事情があったかもしれません。消すのは担当者が理由を確かめてからにします。 今後足す行には、足した月と理由を必ず記録します。

記録を残す

• 月ごとに取り出した検索語と、検索回数・ヒット件数
• 検索語ごとの商品の候補と、どの集め方で出たか
• 生成AIの分類と辞書の行の候補（応答の全文）
• 検証用の索引での比較の結果（上位1,000語のうち、上位10件が入れ替わった語と入れ替わりの数）
• 担当者の判定（採用・修正・却下と、却下の理由）
• 辞書のファイルの版と、行ごとに足した月・理由・根拠の商品ID
• 反映した語の、翌月のヒット件数

6つ目で行ごとに理由を残すのが、3年後に効きます。 今の辞書の約3,000行は、理由が無いために消せない行です。理由と根拠の商品IDがあれば、その商品の取り扱いが終わったときに、関係する行を洗い出せます。

最後の行で、反映した語が0件から抜けたかを見ます。 抜けていなければ、行の書き方か解析器の設定に原因があります。