埋め込みは「十分」で満足しないでください

検索システムは、関連性があるように見える結果を返しても、ユーザーの期待を裏切ることがあります。これが「十分な」埋め込みの問題です。モデルは、関連する文を互いに近くに配置しても、重要な意味を見逃してしまう可能性があります。 「サブスクリプションのキャンセル」と「サブスクリプションの一時停止」はほぼ同じリクエストとして扱われる場合があります。ユーザーの実際の目的を無視して、製品名と一致する可能性があります。私はこれがサポート検索、製品カタログ、ドキュメントアシスタントで起こっているのを見てきました。システムはクエリに関連するものを返しますが、有用なものは返しません。その後、ユーザーは質問を繰り返したり、言葉遣いを変えたり、検索エクスペリエンスを信頼しなくなったりします。より良い埋め込みは、より良いプロセスから始まります。 ## 埋め込みで保持する必要があるものを理解する 埋め込みはテキストを数値表現に変換します。同様の意味はベクトル空間内で近くに位置するはずです。これは、テキストに次のような詳細が含まれるまでは簡単に聞こえます。 - 製品モデル - バージョン番号 - ユーザーの役割 - 日付 - 法的条件 - 否定 - 段階的な指示 - 結果が異なる類似の用語 次の 2 つの文を考えてみましょう。 - 「最大 3 か月間、プランを一時停止できます。」 - 「3 か月以内であればプランをキャンセルできます。」言葉は重なっていますが、行動は異なります。埋め込みが弱いと、それらが近づきすぎる可能性があります。有用なシステムでは、一時停止とキャンセルの違いを保持する必要があります。私は、ベクトルがどれだけ自然に見えるかによって埋め込みを判断しません。完全な検索タスクに役立つかどうかで判断します。 ## 実際のユーザーの質問から始めます 一般的なベンチマーク データはモデルの比較に役立ちますが、ユーザーがどのように検索するのかは示されません。私は以下から実際のクエリを収集することを好みます。 - 検索ログ - サポート チケット - チャットでの会話 - 営業に関する質問 - 社内の知識リクエスト - 失敗した検索 - 繰り返しのページ訪問につながったクエリ 個人情報を削除し、質問を意図ごとにグループ化します。グループには、返金、アカウントへのアクセス、配送の変更、技術的なセットアップに関する質問が含まれる場合があります。次に、小さなリファレンス セットを作成します。クエリごとに、先頭近くに表示されるドキュメントを記録します。初期の問題を見つけるために膨大なコレクションは必要ありません。 100 ～ 300 個のクエリを集中的に実行すると、文言、チャンク サイズ、メタデータ、ランキングに関する問題が明らかになります。有用なテスト記録は次のようになります: text クエリ: 最初の支払い後に年間プランを一時停止できますか?関連箇所: 年間プランは、最初の請求サイクル後に一時停止できます。休止期間は最長３カ月間続く。関連するが間違った一節: 年間プランは購入後 3 か月以内にキャンセルできます。 この例では、トピックの類似性以上のものをテストします。アクション、タイミング、ポリシーの詳細をテストします。 ## モデルを変更する前にテキストを改善する 埋め込みの問題の多くは、入力テキストが貧弱であることから始まります。文書には、見出し、段落、表、および脚注が含まれる場合があります。抽出プロセスでこれらのセクションが混在している場合、埋め込みには紛らわしいコンテンツのブロックが含まれます。私は通常、次の 4 つの領域をチェックします。 ### 1. 見出しを保持する 払い戻しに関する段落には、見出しが含まれているとより意味が伝わります。埋め込む代わりに: テキスト リクエストは納品後 14 日以内に行う必要があります。 use: text 返品 — 期限 返品リクエストは配達後 14 日以内に行う必要があります。 追加されたコンテキストにより、ベクトルにより明確な信号が与えられます。 ### 2. 関連するコンテンツをまとめて保存する 条件の途中で終了したチャンクは、次の文の意味を失う可能性があります。不正な分割: text デバイスに製造上の欠陥がある場合、顧客は返金を要求できます。 より良い分割: text の場合、返金は利用できません。デバイスに製造上の欠陥がある場合、顧客は返金をリクエストできます。誤用による損傷の場合は返金できません。 チャンクの境界は、固定の文字数だけではなく、意味に従う必要があります。 ### 3. サイズが大きすぎるチャンクを避ける 大きなチャンクには複数のトピックが含まれる場合があります。その場合、ベクトルは明確な答えではなく、幅広い混合を表します。製品ガイドでは、設置、メンテナンス、保証範囲、トラブルシューティングについて 1 つのセクションで説明します。保証範囲に関するクエリではセクション全体を取得できますが、有用な部分を特定するのは難しくなります。多くの場合、チャンクが小さいと検索に役立ちますが、チャンクが非常に小さいとコンテキストが削除される可能性があります。習慣で番号を選択するのではなく、いくつかのサイズをテストし、その結果を検査します。 ### 4. 主要な識別子をそのまま保持する モデル名、エラー コード、プラン名、および技術用語を複数のチャンクに分割しないでください。たとえば、「アカウント検証中のエラー PX-204」を個別のフラグメントに分割すると、キーワード検索とセマンティック検索の両方が弱くなる可能性があります。チャンクには、意味を与える説明とともに識別子を保持する必要があります。 ## 最終的なランキングから取得を分離する 埋め込みは候補を見つけるのに適しています。すべてのランキング決定を単独で行う必要はありません。実際の検索フローでは、以下を使用できます。 1. 意味の高密度検索 2. 名前、コード、正確なフレーズのキーワード検索 3. 製品、言語、日付、またはアクセス レベルのメタデータ フィルター 4. 最終的な順序の再ランカー ユーザーが「PX-204 ログイン エラー」を検索するとします。セマンティック モデルは、異なるコードを使用するアカウント検証エラーに関するドキュメントを取得する場合があります。キーワード照合により、正確なコードを保護できます。 2 つの検索方法は併用できます。すべてのクエリを 1 つのメソッドで処理するように要求するよりも、システムが意味論的な信号と語彙的な信号を組み合わせた方が良い結果が得られることがよくあります。メタデータにも同じことが当てはまります。モバイル アプリに関するクエリでは、表現が似ているという理由だけで古いデスクトップ ガイドが返されるべきではありません。フィルターを使用すると、最終的なランキング段階の前にこの種のノイズを軽減できます。 ## 簡単な一致だけでなく、難しい例をテストする 簡単なクエリにより、ほぼすべての埋め込みシステムが健全に見えるようになります。ハードクエリを実行すると、どこが壊れているかがわかります。以下を含むテスト ケースを作成します。 - 同義語 - タイプミス - 短いクエリ - 長い質問 - 否定的な表現 - 類似の製品 - 類似のポリシー - 複数の言語 - 頭字語 - バージョン番号 - コンテキストが欠落しているクエリ 各クエリについて、正しい文章が上位の結果に表示されるかどうかを確認します。 Recall@K や MRR などの測定値を追跡することはできますが、それでも人間によるレビューが重要です。結果は、ユーザーのニーズに応えていないにもかかわらず、関連しているものとしてカウントされる場合があります。誤検知についてもレビューします。非常に似ているように見える間違った結果は、モデルが何を混乱させているかを示すため、ランダムなミスよりも役立つことがよくあります。例: text クエリ: 請求履歴を失わずに所有権を譲渡するにはどうすればよいですか?間違った一致: ファイルを別のアカウントに転送するにはどうすればよいですか?有用な一致: アカウント所有権の譲渡は、管理者が完了すると請求履歴を保存します。 どちらの文章も送金と口座について言及しています。ユーザーの完全な意図に対処できるのは 1 つだけです。 ## 導入後の変更に注意する コンテンツの変更に応じて、埋め込みの品質が変化する可能性があります。新しい製品名は古い製品名に似ている場合があります。ポリシーの更新はアーカイブされたページと競合する可能性があります。機能のリリース後に顧客の言語が変更される場合があります。前四半期にはうまく機能していた検索システムでも、大量のドキュメントをインポートすると結果が悪くなる可能性があります。各コンテンツまたはモデルの更新の一部として、小規模な評価セットを保持しておくことをお勧めします。新しい結果を以前のバージョンと比較します。以下に注意してください。 - 正しい結果を失ったクエリ - 新しい誤った一致 - 上位結果の順序の変更 - 空の結果の割合 - 繰り返しの検索 - クリック後のクイックリターン - 検索で解決できなかったサポートの質問 ユーザーのフィードバックにより、オフライン テストで見逃された問題が明らかになることがあります。ユーザーが結果を開いて再度検索することを繰り返した場合、結果は関連している可能性がありますが、十分ではありません。 ## 埋め込みモデルを無視しないでください。 テキストの準備とランキングの設計は重要ですが、モデルは依然としてパフォーマンスに影響します。モデルを比較するときは、同じものを使用します。 - ドキュメント - チャンキング ルール - クエリ セット - フィルター - インデックス設定 - ランキング プロセス モデルは、公開テストでは強力に見えても、ドメイン言語ではパフォーマンスが低い場合があります。小規模なモデルは明確なサポート記事に適している場合がありますが、専門的なモデルは技術用語や多言語コンテンツに役立つ場合があります。コストとスピードも決定事項に含まれます。リトリーブがわずかに優れているものの、許容できない遅延が発生するモデルは、製品に適合しない可能性があります。正しい選択は、1 つのスコアではなく、完全なユーザー エクスペリエンスによって決まります。 ## デバッグに十分な情報を保存する ベクトル データベースはブラック ボックスであってはなりません。各チャンクについて、次のような有用なフィールドを保持します。 - ソース文書 - 見出しパス - 製品またはコンテンツ タイプ - 言語 - 発行日 - アクセス ルール - チャンク位置 - ソース バージョン 結果が間違っているように見える場合、これらのフィールドは原因を説明するのに役立ちます。ベクトルには問題はなかったものの、ドキュメントが古かったことがわかるかもしれません。フィルターが最適な通路を削除したことがわかるかもしれません。 2 つのチャンクが同じガイドの異なるバージョンからのものであることがわかります。結果がどのように作成されたかをシステムが表示できると、デバッグがはるかに簡単になります。 ## 「十分に良好」を目標ではなくテスト結果として扱う 有用な製品をサポートするために埋め込みが完璧である必要はありません。タスク、内容、ユーザーの言語と一致する必要があります。私は 3 つの質問に焦点を当てます: - クエリの近くに正しい意味が表示されますか? - ランキング システムでは、最高のパッセージを十分上位に配置できますか? - ユーザーは検索を繰り返さずにタスクを完了できますか?これらのいずれかの答えが「いいえ」の場合、埋め込みモデルを変更しても問題は解決しない可能性があります。原因としては、弱いチャンク化、コンテキストの欠落、不適切なフィルター、古いコンテンツ、完全一致サポートの欠如などが考えられます。優れた検索はシステム全体から生まれます。埋め込みはそのシステムの一部であり、その価値は、ベクトル検索が単独でどれだけ受け入れられるかによってではなく、ユーザーが見つけられる答えによって測られます。

多くのチームは、モデルをベクトル データベースに接続するとすぐにエンベディングがコンテンツを理解できることを期待しています。多くの場合、最初の検索は有望に見えます。その後、小さな問題が発生します。顧客が返金について問い合わせましたが、システムは配送商品を取得しました。開発者が「ログイン タイムアウト」を検索すると、システムはパスワードのリセットに関するドキュメントを返します。製品名には複数のバージョンがあるため、類似したテキストは間違った項目を示しています。埋め込みの品質はモデル以上のものに依存することがわかりました。良好な結果は、クリア テキスト、適切なチャンク、有用なメタデータ、および定期的なテストから得られます。 ## 検索問題から始める まず、ユーザーが見つけたいものを書き留めます。サポート チームは、次のような質問に答える必要がある場合があります。 - 「破損した商品を返品できますか?」 - 「通常の配送にはどのくらい時間がかかりますか?」 - 「なぜ支払いが拒否されたのですか?」 - 「配送先住所を変更できますか?」これらの質問はすべて注文や支払いについて言及しているため、関連しているように見えます。彼らの答えは別の文書に記載されている可能性があります。検索システムは、共有された単語を単に一致させるだけでなく、ユーザーの意図を理解する必要があります。私はサポート チケット、Web サイトのログ、内部チームから実際の検索クエリを収集します。少数の実際の質問からは、多数の架空の例よりも多くのことが明らかになります。 ## 埋め込みを作成する前にコンテンツをクリーンアップする ソーステキストが貧弱であると、埋め込みモデルの品質が制限される可能性があります。繰り返されるナビゲーション メニュー、壊れた HTML、追跡テキスト、重複したページを削除します。ユーザーがトピックを理解するのに役立つ情報を保持します。 - 製品名 - サービス条件 - 日付 - 場所 - ユーザー要件 - 例外 - 段階的な説明 また、重要な用語も明確にします。 「標準プラン」と記載されているページは、プランを識別する見出しなしで保存すると混乱を招く可能性があります。私は、「スタンダード プラン: 購入後 30 日以内であればキャンセルできます。」のような完全な文章を好みます。この文には、「顧客は 30 日以内にキャンセルできます」という以上の意味があります。 ## コンテンツに適したチャンク サイズを選択してください。チャンクが短すぎると、コンテキストが失われる可能性があります。長すぎるチャンクには、無関係な主題がいくつか含まれている可能性があります。製品マニュアルの場合、見出しとサポート手順を含む 1 つのセクションを使用することがあります。法的ポリシーや価格設定ページについては、その条件と例外を含む完全なルールを保持することがあります。有用なチャンクには、次のものが含まれることがよくあります。 - 明確な見出し - 1 つの主要なアイデア - そのアイデアを理解するために必要な詳細 - 近隣の少量のコンテキスト 私はチャンク間で文を分割することを避けています。関連アイテムもまとめてます。時間制限のない返品ルールでは、正しいように見えても重要な条件が省略された回答が作成される可能性があります。すべてのプロジェクトに適合する単一のチャンク サイズはありません。同じ検索質問でいくつかのオプションをテストし、結果を比較します。 ## テキストの横にメタデータを保持します。埋め込みはテキストの意味を表します。メタデータはフィルターとビジネス コンテキストを追加します。各チャンクについて、以下を保存できます。 - 文書タイトル - 製品名またはサービス名 - 言語 - 地域 - 顧客タイプ - 発行日 - アクセス レベル - ソース URL - バージョン番号 「モバイル プランのキャンセル」を検索するには、国フィルターが必要な場合があります。 「最新の API 制限」を検索するには、バージョン フィルターが必要になる場合があります。メタデータがないと、間違った地域またはバージョンの意味的に類似したコンテンツが結果に含まれる可能性があります。私はメタデータを後付けとしてではなく、検索設計の一部として扱います。 ## モデルをコンテンツに一致させる 一般的なテキスト用にトレーニングされた埋め込みモデルは、一般的な質問にはうまく機能する可能性があります。技術検索システムでは、製品コード、ソフトウェア用語、または短いクエリのより強力な処理が必要な場合があります。顧客が使用する言語、ドキュメント スタイル、クエリの長​​さを使用してモデルをテストします。モデルは英語のサポート コンテンツでは適切に動作しますが、言語が混在するドキュメント、略語、または業界用語では動作が異なる場合があります。単一の例からモデルを選択することはありません。以下のテスト セットを作成します。 - 一般的な検索 - 短い検索 - 詳細な質問 - スペルミス - 製品名 - 必要に応じて異なる言語 - 日付またはバージョン番号を含むクエリ テスト セットを使用すると、モデルと設定を比較するための安定した方法が得られます。 ## 正確な用語が重要な場合はハイブリッド検索を使用する 埋め込みは意味ベースの検索に役立ちます。すべての用語を正確に扱えるわけではないかもしれません。ユーザーは以下を検索できます。 - 「ERR_CONN_RESET」 - 「SKU-48391」 - 「v2.4.7」 - 「AC-19 返金コード」 キーワード システムを使用すると、これらの正確な文字列をより確実に見つけることができます。私はベクトル検索とキーワード検索を組み合わせて、両方のシグナルを使用して結果をランク付けすることがよくあります。このアプローチは、クエリに自然言語と正確な識別子が混在している場合に役立ちます。セマンティック層は、「なぜ支払いが失敗したのか?」を結びつけることができます。支払いトラブルシューティングガイド付き。キーワード レイヤーは、そのガイド内の特定のエラー コードを見つけることができます。 ## 再ランキング ステップを追加する ベクトル検索では、一般的に関連するいくつかのパッセージが返される場合があります。再ランカーは、クエリと候補パッセージを一緒にレビューし、最も関連性の高いアイテムを上位に配置できます。この手順は、データベースに次のような類似のドキュメントが多数含まれている場合に使用します。 - 複数のバージョンの製品説明書 - 大規模なナレッジ ベース - 類似した名前の複数のプラン - 共通の文言を共有するサポート記事 再ランキングでは不十分なソース コンテンツは修正されません。最初の検索で有用な候補グループが返された場合に最適に機能します。 ## 実際の質問で検索を測定する 検索システムは、結果が「見た目が良い」かどうかだけで判断されるべきではありません。小さな評価表を使用します。各クエリについて、次のことを記録します。 - 予想されるドキュメントまたはパッセージ - それが上位の結果に表示されるかどうか - その位置 - パッセージに十分なコンテキストが含まれているかどうか - 結果が正しい製品または地域に属しているかどうか 100 個のサポート質問をテストするとします。 82 の質問の最初の 5 つの結果に正しい文章が表示されれば、有用なベースラインが得られます。数字だけではすべての問題を説明できないため、失敗した検索をタイプ別に確認します。ある小売チームは、ほとんどの失敗が古い製品ページに起因していることに気づくかもしれません。別のチームは、チャンクが配送ルールと例外を分け​​ていることに気づくかもしれません。修正方法は失敗のパターンによって異なります。 ## 意味を変える文言に注意してください。 文言の小さな違いが検索に影響を与える可能性があります。 - 「キャンセル後の返金」 - 「返金後のキャンセル」 - 「出荷後は返金不可」 - 「出荷前のみ返金可能」 これらの語句は多くの共通語ですが、異なるルールを説明しています。私は、条件を変更するステートメントの近くに条件を配置します。また、見出し、ラベル、表のコンテキストに意味がある場合はそれらも保存します。テーブルには注意が必要です。 「Basic Plan | 5 users | $20」の行は、個別のフラグメントとして抽出されると意味が失われる可能性があります。埋め込みを作成する前に、読み取り可能なテキストに変換します。 ## エンベディングを慎重に回答生成に接続します。 検索と回答生成は別のタスクです。強力な検索結果が正しい答えを保証するものではありません。言語モデルは依然として、異なるバージョンの文章を組み合わせたり、サポートされていない詳細でギャップを埋めたりする可能性があります。ソース情報を回答レイヤーに渡し、それが取得されたコンテンツ内に留まるように依頼します。ユースケースのレビューが必要な場合は、引用またはソースのリンクも表示します。サポート エージェント、コンプライアンス チーム、および技術ユーザーは、応答する前に元の文章を確認する必要がある場合があります。システムに十分な情報が不足している場合は、確信を持って推測するよりも詳細を明確に要求する方が安全です。 ## コンテンツ変更後にシステムを確認する ナレッジ ベースは時間の経過とともに変化します。新しい価格、製品バージョン、ポリシー、ヘルプ記事は、検索に影響を与える可能性があります。各レコードのソース バージョンと埋め込み日を追跡します。ドキュメントが変更されると、古いバージョンと新しいバージョンをラベルなしで混在させたままにするのではなく、関連するチャンクを更新します。次の後に検索パフォーマンスをレビューします。 - 主要な製品リリース - ポリシーの更新 - 新しい言語の追加 - 顧客からの質問の変更 - 検索インターフェイスの再設計 ユーザーからのフィードバックがここで役に立ちます。 「役に立たない」アクション、再定式化されたクエリ、またはサポート エージェントの修正により、同義語の欠落や不明瞭な文章が明らかになる可能性があります。 ## 実用的なワークフロー 私は多くの埋め込みプロジェクトでこのシーケンスを使用します。 1. 実際のユーザーの検索を収集します。 2. 何が有用な結果としてカウントされるかを定義します。 3. ソースコンテンツを整理して整理します。 4. ヘッダーとコンテキストを使用してチャンク サイズをテストします。 5. フィルタとバージョンのメタデータを追加します。 6. 適切な埋め込みモデルを比較します。 7. 正確な用語が重要な場合は、セマンティック検索とキーワード検索を組み合わせます。 8. 多くの結果が類似している場合は、再ランキングを追加します。 9. ラベル付きクエリセットを使用してテストします。 10. 失敗を確認し、ソース コンテンツを更新します。最も有益な教訓は単純です。埋め込みは明確な情報アーキテクチャに取って代わることはできないということです。ソース コンテンツが重複しているか、不完全であるか、コンテキストが欠落している場合、検索エクスペリエンスにはそれらの問題が反映されます。私は埋め込みをより大きな検索システムの一部として扱います。実際の質問でテストし、各チャンク内に重要なコンテキストを保持し、すべての結果を適切な製品、バージョン、対象ユーザーに結び付けます。このプロセスにより、システムは、リクエストを理解せずに単語を照合するのではなく、ユーザーの意味を理解する機会が高まります。

検索結果が無関係であると感じられる場合、問題は検索ボックスではない可能性があります。それはシステムが言語を理解する方法である可能性があります。キーワード検索では、一致する単語が検索されます。埋め込みベースの検索では、意味が調べられます。この違いは、ユーザーがさまざまな方法で質問を書いたり、業界用語を使用したり、必要なページを正確に指定せずに問題を説明したりする場合に重要になります。実際の問題はデータ準備プロセス内にあるにもかかわらず、チームが検索フィルターの調整に時間を費やしているのを私は見てきました。弱いテキスト チャンク、欠落したコンテキスト、不十分なテストにより、強力な検索モデルであっても混乱を招く結果が返される可能性があります。 ## 埋め込みによって検索が改善される仕組み 埋め込みは、テキストをその意味を表す数値のグループに変換します。同様の意味を持つテキストは、埋め込みスペース内で互いに近くに表示される傾向があります。例: - 「アカウントのパスワードをリセットするにはどうすればよいですか?」・「パスワードを忘れたのでログインできません。」これらの文では異なる単語が使用されていますが、同様のニーズが説明されています。セマンティック検索システムは、基本的なキーワード検索よりも効果的にそれらを結び付けることができます。同じアプローチは次の場合にも役立ちます。 - 製品ドキュメント - カスタマー サポート ポータル - 社内ナレッジ ベース - 電子商取引製品の発見 - 法的文書または技術文書の検索 - 質問応答システム 埋め込みは、人間と同じようにコンテンツを理解するわけではありません。システムがテキストを比較するのに役立つ数学的表現を作成します。結果の品質は、モデル、ソース コンテンツ、検索設定によって異なります。 ## クリーンなソース コンテンツから開始する より適切な検索は、埋め込みモデルを使用する前に開始します。ソースドキュメントで次の点をチェックします。 - 繰り返されるナビゲーション メニュー - 古い説明書 - 壊れた書式設定 - 製品名の欠落 - 重複ページ - 不明確な見出し - いくつかの無関係なトピックを組み合わせたコンテンツ 5 つの異なる問題を含むサポート記事は、埋め込みが弱い可能性があります。システムは、どの部分がユーザーの質問に一致するかを判断するのに苦労する可能性があります。より明確な構造は以下に役立ちます: タイトル: 請求先メールアドレスを変更する 目的: 請求書とアカウント通知に使用するメールアドレスを更新する 手順: アカウント設定を開き、請求先を選択し、メールを編集して保存します 制限事項: この変更を行うことができるのはアカウント管理者のみです この形式は、短く切れ目のない文章で埋め尽くされたページよりも、検索システムに有用なコンテキストを提供します。 ## 実用的なチャンク サイズを使用する 大きなドキュメントは、多くの場合、埋め込む前に小さなセクションに分割する必要があります。このプロセスはチャンキングとして知られています。大きすぎるチャンクには複数のトピックが含まれる可能性があります。チャンクが小さすぎると、答えを理解するために必要なコンテキストが失われる可能性があります。通常、関連情報をまとめて保管します。 - 見出しとその下の段落 - 質問とその回答 - 手順とその条件 - 製品機能とその制限 - トラブルシューティングの問題とその解決策 たとえば、このチャンクはうまく機能する可能性があります。 > 月次レポートをエクスポートするには、[レポート] を開き、月を選択し、[CSV] を選択して、[エクスポート] をクリックします。閲覧者アクセス権を持つユーザーはレポートを表示できますが、エクスポートすることはできません。許可の詳細はエクスポート手順に記載されている必要があります。これらの行を分離すると、手順は説明されているものの、アクセス ルールが欠落している回答が得られる可能性があります。すべてのプロジェクトに適合する単一のチャンク サイズはありません。実際のクエリでいくつかのオプションをテストし、結果を比較します。 ## 有用なメタデータを保持する テキストだけでは十分な情報が得られない可能性があります。メタデータは、検索システムがコンテンツをフィルタリングしてランク付けするのに役立ちます。有用なフィールドには次のものがあります。 - 製品分野 - 言語 - ドキュメント タイプ - 顧客プラン - 発行日 - 地域 - ユーザー ロール - アクセス レベル - コンテンツ ステータス 企業がベーシック プランとエンタープライズ プラン用に個別のセットアップ ガイドを持っていると想像してください。検索システムがテキストのみを比較する場合、ユーザーは誤った指示を受け取る可能性があります。メタデータ フィルターを使用すると、ユーザーのアカウント タイプと正しいドキュメント セットを照合することで、そのリスクを軽減できます。アクセス制御は慎重に扱う必要があります。文書の文言がクエリに一致するという理由だけで、文書が検索結果に表示されるべきではありません。検索権限は、メイン アプリケーションと同じルールに従う必要があります。 ## セマンティック検索とキーワード検索を組み合わせる 埋め込みは便利ですが、あらゆる状況でキーワード検索に代わるわけではありません。キーワード マッチングは、ユーザーが以下を検索する場合に役立ちます。 - エラー コード - モデル番号 - 製品名 - チケット ID - ファイル名 - 正確な専門用語 セマンティック検索は、自然な質問や関連する文言に対して適切に機能します。ハイブリッド検索は両方の方法を組み合わせたものです。たとえば、ユーザーは次のように検索する場合があります。 > AX-220 ドライバのインストール後のエラー E104 エラー コードとモデル番号は厳密に一致する必要があります。 「インストール後」というフレーズにより、セマンティック検索が解釈に役立つという意味が追加されます。実際のランキング システムでは、次の項目が重視される場合があります。 - キーワードの完全な一致 - 意味論的な類似性 - ドキュメントの新しさ - 製品または計画のメタデータ - ユーザーのアクセス許可 - 過去のインタラクション シグナル 適切なバランスは、検索の目的によって異なります。サポート ポータルは技術識別子を重視する場合があります。製品発見ページでは、意味やユーザーの好みがより重視される場合があります。 ## 実際の質問で検索品質を測定する 検索システムは、小規模なデモでは印象的に見えても、日常のユーザーにとってはパフォーマンスが低い場合があります。実際の検索動作からテスト セットを構築します。 - よくある質問 - 綴りが間違っている用語 - 短いクエリ - 長い説明 - 製品コード - コンテキストが欠落している質問 - 結果を返さないクエリ 各クエリは、次のような判断を受けます。 - 関連する - 部分的に関連する - 関連しない - 有用な結果なし 小規模のサポート チームが、各クエリの上位 3 つまたは 5 つの結果を確認できます。これにより、大規模な研究チームを必要とせずに実用的なベンチマークが作成されます。カスタマーサポートの例を考えてみましょう。あるソフトウェア会社は、ユーザーが「請求書ダウンロード」を検索すると、その結果は一般的な請求ページに誘導されることに気づきました。データを確認した結果、チームは有益な記事で「請求明細のエクスポート」というフレーズが使用されていることを発見しました。チームはページ見出しを改善し、ステップの近くにアカウント権限の詳細を保持し、請求用のメタデータを追加し、キーワード検索とセマンティック検索の両方をテストします。コンテンツと取得方法が同じユーザーのニーズをサポートするようになったため、検索結果はさらに便利になります。改善は次のようなデータで測定する必要があります。 - 関連する結果のクリック数 - 検索再構成率 - 結果なし率 - 有用なページを開くまでの時間 - 検索後のサポート リクエスト - ユーザーからのフィードバック 結果なし率が低いほど役に立ちますが、すべての回答が正しいことを証明するわけではありません。関連性についてはまだ検討が必要です。 ## 一般的な埋め込みの問題に注意してください いくつかの問題は、実装中に頻繁に発生します。 古いコンテンツ 古い記事は、適切な言葉が含まれているため、上位にランクされる可能性があります。公開ステータスと更新日を追加し、トラフィックの多いページを確認します。 コンテンツの重複 同じガイドを複数コピーすると、ユーザーのクリックが分割され、一貫性のない回答が作成される可能性があります。可能な場合は、メイン バージョンを 1 つだけ保持してください。 コンテキストが欠落しています 「保存をクリック」というチャンクは、ページ名やタスクがなければ意味がない可能性があります。周囲の情報を十分に追加します。 混合言語 多言語検索システムには、言語対応の埋め込み、個別のインデックス、または言語メタデータが必要な場合があります。サポートされている各言語からのクエリをテストします。 機密情報 アクセス ルールが弱い場合、埋め込みシステムによってプライベート コンテンツが公開される可能性があります。ユーザーがドキュメントを開いた後ではなく、結果を返す前にアクセス許可を適用します。 不明瞭な失敗動作 一部のクエリにはナレッジ ベースに適切な答えがありません。システムは、大まかに関連するページを答えとして提示するのではなく、信頼できる一致が見つからなかったと言える必要があります。 ## 検索フィードバックをメンテナンスの一部にする 製品、ポリシー、ユーザー言語の変更に応じて、検索の品質も変化します。 - クリックのないクエリ - 再構築が繰り返されるクエリ - 閲覧数は多いが満足度が低いページ - 新しい製品条件 - 頻繁にチケットを生成するサポート トピック - エンゲージメントが低下しているドキュメント ユーザーのフィードバックにより、指標では示されないギャップが明らかになることがあります。ユーザーはページを見つけて読んでも、重要な条件が欠落しているためにサポートに問い合わせる場合があります。簡単なフィードバック オプションでは、次のことを尋ねることができます。 > この結果は役に立ちましたか?答えはすべての問題を説明するものではありませんが、クエリ ログやコンテンツ レビューと組み合わせることで、チームに有用なシグナルを与えます。 ## 実践的なワークフロー 私は明確な作業プロセスを使用します。 1. 実際の検索クエリを収集します。 2. ソース文書を整理して整理します。 3. 見出し、コンテキスト、メタデータを追加します。 4. いくつかのチャンク化アプローチをテストします。 5. 承認されたコンテンツの埋め込みを作成します。 6. セマンティックおよびキーワードの取得を設定します。 7. 権限とメタデータフィルターを適用します。 8. 実際のユーザーの質問を使用して結果を確認します。 9. 関連性、結果のないクエリ、および再定式化を追跡します。 10. コンテンツを更新し、テストを繰り返します。この作業は、埋め込みモデルを選択するだけではありません。適切に構造化されていないデータに接続された大規模なモデルよりも、クリーンなコンテンツと慎重な評価を組み合わせた小規模なモデルの方が、ユーザーに優れたサービスを提供できる可能性があります。より良い埋め込みはよりスマートな結果をサポートしますが、システム全体が重要です。明確なソース コンテンツ、適切なチャンク、有用なメタデータ、ハイブリッド検索、および定期的なテストにより、ユーザーは質問から回答までのより適切な道筋を得ることができます。

多くのチームは、プロンプトを変更することでチャットボット、検索ツール、または推奨システムを改善しています。多くの場合、本当の問題はプロセスの初期にあり、テキストが弱い埋め込みに変わってしまっています。埋め込みが意味を捉えることができない場合、関連するコンテンツはベクトル空間内で遠く離れたままになります。ユーザーが「開封したデバイスを返品できますか?」と尋ねます。どちらのページにも「返品」と「デバイス」について言及されているため、システムは未開封の商品に関するページを取得します。答えは流暢に聞こえるかもしれませんが、間違った情報源に基づいて構築されています。このパターンはよく見かけます。埋め込み品質の向上は、よりクリーンなデータ、適切なモデル、実際のユーザーの質問を反映したテスト プロセスから始まります。 ### モデルではなくコンテンツから始める 強力な埋め込みモデルでは、不明瞭なテキストやノイズの多いテキストを修復できません。技術的な設定を変更する前に、ソース資料を確認します。繰り返されるナビゲーション メニュー、壊れた HTML、重複ページ、古いポリシー バージョン、コンテキストが欠落しているテキストを削除します。 「この料金は 30 日後に適用されます」などの文は、文書に「この料金」の意味がまったく記載されていない場合には使用しにくいです。また、有用な構造も保持します。 - 製品名 - 機能ラベル - セクション見出し - 保険契約日 - 顧客プラン名 - 地域または言語情報 - ドキュメントのバージョン クリーンなドキュメントは、各パッセージの意味を表すのに十分なコンテキストを埋め込みモデルに提供します。 ### ベクトル サイズを増やす前にチャンク化を改善する チャンク化は、各ベクトルがどの程度の意味を持つかを制御します。チャンクが短すぎると、文の主語が失われる可能性があります。長すぎるチャンクには、無関係なトピックがいくつか含まれている可能性があります。どちらの場合も、検索の品質が低下する可能性があります。私は通常、習慣で 1 つを選択するのではなく、いくつかのチャンク サイズをテストします。サポート知識ベースの場合、開始点としては 150 ～ 400 ワードの一節が適しています。手順が以前の定義に依存しているため、技術マニュアルにはより大きなセクションが必要になる場合があります。便利なチャンク化の実践方法は次のとおりです。 - 見出しを本文と一緒に保持する - ステップバイステップのプロセスを途中でカットしないようにする - 関連する各チャンク内に製品名を保持する - コンテキストがセクション間で続く場合は、小さな重複を使用する - すべてのチャンクにドキュメントのタイトルとセクションのパスを保存する チャンクは、1 つの明確な質問に答えるか、1 つの明確なタスクをサポートする必要があります。これにより、検索とレビューの両方が容易になります。 ### モデルを言語およびタスクに一致させる 埋め込みモデルは、対象言語、入力制限、検索動作、およびトレーニング データが異なります。英語の製品ページではうまく動作するモデルでも、複数言語が混在するサポート コンテンツでは動作の信頼性が低くなる可能性があります。私はモデルとユーザーが実際に尋ねる質問を比較します。一般的なベンチマークスコアだけに頼っているわけではありません。基本的なテスト セットとして、以下を収集します。 - 顧客メッセージからの自然な質問 - 短いキーワード検索 - 長くて詳細な質問 - スペル ミスのある質問 - 製品のニックネームを使用した質問 - 日付または地域によるフィルタリングが必要な質問 - 回答が異なる類似の質問 各質問には、信頼できる関連する文章が必要です。これにより、出力を感覚で判断するのではなく、検索結果を比較できるようになります。有用な測定値には、recall@k、precision@k、および平均逆数ランクが含まれます。正しいパッセージが上位 5 つの結果に表示される場合、recall@5 は成功したことを記録します。無関係なパッセージが結果リストを埋める場合、精度に問題があることがわかります。 ### メタデータに意味を追加する ベクトルは意味論的なコンテンツを表します。ビジネス ルールを完全に表していない可能性があります。 2 つのドキュメントで同じ機能が説明されているとします。 1 つはカナダの顧客に適用され、もう 1 つは英国の顧客に適用されます。彼らの文章は非常に似ているかもしれません。メタデータによってそれらを分離できます。次のようなフィールドを添付します。 - 国 - 言語 - 製品 - 顧客プラン - 発行日 - 文書ステータス - アクセス レベル - コンテンツ タイプ 検索システムは、ベクトル検索の前後にこれらのフィールドをフィルターとして使用できます。これにより、ユーザーが間違った製品または保険期間からの回答を受け取る可能性が低くなります。 ### セマンティック検索とキーワード検索を組み合わせる 埋め込みは意味を適切に処理します。正確な言葉は依然として重要です。ユーザーは、モデル番号、エラー コード、請求書 ID、または法律用語を検索できます。キーワード システムは、ベクトル検索システムよりも正確な文字列をより確実に照合できます。多くのビジネス システムに対して、私はハイブリッド アプローチを使用します。 1. 意味上の類似性についてベクトル検索を実行します。 2. 完全に一致するキーワード検索を実行します。 3. 結果をランキング方法と結合します。 4. 製品、言語、日付、またはアクセスのフィルターを適用します。 5. 結果セットを詳細に比較する必要がある場合は、リランカーを使用します。この設定により、検索システムに 2 つの信号 (ユーザーが何を意味するか、およびユーザーが使用した単語) が与えられます。 ### 意図的に難しいクエリをテストする 簡単な質問によって、脆弱なシステムが健全に見えることがあります。失敗の原因となる可能性が最も高いケースを含むテスト セットを作成します。 - 文言が似ている 2 つの文書 - 同じポリシーの古いバージョンと新しいバージョン - スペルが似ている製品名 - 詳細が欠落している質問 - くだけた言葉を使用している質問 - 2 つのトピックを組み合わせた質問 - 関連する回答が存在しない質問 ソースに信頼できる回答が含まれていない場合、システムは一致を強制すべきではありません。私は、無関係な文章に基づく自信に満ちた回答よりも、「そのリクエストに対するサポートが見つかりませんでした」という明確な回答を好みます。 ### 実際の検索ログを確認する オフライン テストにより構造が得られます。ユーザーの行動は、テスト セットが何を見逃していたかを示します。 - クリックなし - 再定式化の繰り返し - 長い読み取り時間 - 低評価の回答 - 人間のサポートへのエスカレーション - 間違った製品分野からの結果 私が協力したあるサポート チームは、顧客が「サブスクリプションのキャンセル」を検索しているのに対し、ヘルプ センターは「サービス プランの終了」を使用していることを発見しました。埋め込みモデルだけが問題ではありませんでした。コンテンツには、顧客がほとんど使用しない社内用語が使用されていました。顧客用語をコンテンツとメタデータに追加することで、質問とソース ページの間の接続が改善されました。 ### 測定された小さなステップでアップグレードする モデル、チャンク サイズ、フィルター、ランク付け方法を同時に変更すると、結果を説明するのが難しくなります。テストごとに 1 つの主要な要素を変更します。 - ソース コンテンツのクリーンアップ - チャンク境界の調整 - 2 つの埋め込みモデルの比較 - メタデータ フィルターの追加 - ハイブリッド検索の追加 - リランカーのテスト - 失敗ケースのレビュー クエリ、予想されるソース、取得結果、システム バージョンを記録します。単純なスプレッドシートで初期段階をサポートできます。大規模なシステムでは、評価パイプラインが必要になる場合があります。目的は、文脈なしにスコアを追うことではありません。目標は、ユーザーが再試行を減らし、手動での確認を減らして適切な情報を見つけられるようにすることです。より良い埋め込み品質は、着実なチェックによって構築されます。ソーステキストがきれいであれば、モデルの意味がより明確になります。適切なチャンクはコンテキストを保持します。メタデータはビジネス ルールを保護します。ハイブリッド検索は、自然な質問と正確な用語の両方をサポートします。焦点を絞ったテスト セットは、システムがまだ見逃している箇所を示します。検索結果が信頼できないと感じた場合、私はプロンプトを書き直すことから始めません。ソース文書から取得されたパッセージまでのデータ パスを検査します。そこから多くの品質向上が始まります。私たちは産業分野で豊富な経験を持っています。専門的なアドバイスが必要な場合は、胡海峰までお問い合わせください: 928464224@qq.com/WhatsApp +8613855932323。

1. Reimers Nils と Gurevych Iryna 2019 Sentence-BERT Sentence Embeddings using Siamese BERT-Networks 2. Karpukhin Vladimir Oguz Barlas et al 2020 Dense Passage Retrieval for Open-Domain Question Answering 3. Gao Luyu Ma Xueguang Lin Jimmy Callan Jamie 2021 COIL Revisitコンテキスト化された反転リストを使用した情報検索における語彙の完全一致 4. Khattab Omar および Zaharia Matei 2020 ColBERT BERT 上のコンテキスト化された遅延インタラクションによる効率的かつ効果的なパッセージ検索 5. Thakur Nandan Reimers Nils Daxenberger Johannes Gurevych Iryna 2021 バイエンコーダを改善するための拡張 SBERT データ拡張手法文埋め込みモデル 6. 正式な Thibault Piwowarski Benjamin Clinchant Stéphane 2021 SPLADE 第 1 段階ランキングのスパース語彙および拡張モデル