【ITニュース解説】Customer-Support Retrieval Architecture: 4 Pagination Rules for a Knowledge Base

カスタマーサポートのナレッジベース（知識データベース）を構築する際、検索システム（Retrieval Architecture）は非常に重要である。特に、検索結果を複数ページに分けて表示する「ページネーション」の設計は、単なる見た目の問題ではなく、情報の正確性、検索コスト、そしてシステム全体の信頼性に大きく影響する。

まず、システム開発を始める前に「回答契約（Answer Contract）」を明確に定義することが最も重要である。これは、システムがどのような情報を、どのような品質で提供すべきかを定めるもので、システムエンジニアにとっては設計の土台となる。この契約には、主に以下の4つの要素が含まれる。情報の「鮮度目標」（Freshness Target）として、どのくらい新しい情報が必要か。「根拠の提示」（Evidence Required）として、回答の裏付けとなる情報源の明示が必要か否か。「対象顧客範囲」（Tenant Scope）として、どの顧客や部門向けの情報か。「ページネーション予算」（Pagination Budget）として、1ページに表示する情報量や、何ページ目まで提供可能か、といった項目である。例えば、「2秒以内に回答する」という要件だけでは不十分で、「先週改訂された最新のポリシーを引用して回答する」といった具体的な制約まで盛り込む必要がある。

この契約に基づいて、情報処理を「取り込み（Ingestion）」「検索（Querying）」「回答組み立て（Answer Assembly）」という三つの明確な段階に分離すると良い。取り込みでは、元データの改訂履歴、対象顧客、アクセス権限、そして情報を検索可能な「チャンク」（小さなかたまり）に分割する境界が記録される。検索では、質問に関連する情報がランク付けされ、次のページを示すカーソルやページマーカーが返される。回答組み立てでは、実際に利用された情報の識別子が記録される。この段階分離により、もし問題が発生した場合（例えば、2ページ目に重複した情報がある場合など）に、問題がデータ取り込み段階にあったのか、検索段階でカーソルが誤って処理されたのか、あるいは回答組み立て段階で情報が適切に扱われなかったのか、といった原因特定が容易になる。

ページネーションの方式も重要な検討事項である。「オフセットページネーション」は、単純に「10件スキップして次の10件を表示する」という形で、理解しやすいが、データベース内の情報が頻繁に更新されると、ユーザーが次のページを見た時に情報が移動したり重複したりする可能性がある。これに対し、「カーソルベースのページネーション」は、特定の時点のデータ（スナップショット）に基づき、次の検索開始位置を示すカーソルを使用するため、結果の再現性が高く、ユーザー体験が安定する。システムがスナップショットの保証を提供できない場合は、表示された情報の識別子を保持し、後続のページは「ベストエフォート」（可能な限り最善を尽くす）として扱うべきである。

ナレッジベースの検索には、主に二つのパス（経路）が考えられる。一つは「ベクトル検索」である。これは自社で管理している、内容が比較的安定した情報（例えば、返品ポリシー、社内規定など）に適している。記事などの情報を意味的な特徴を表す数値のベクトルに変換してインデックス化し、質問の意味に近い情報を検索する。この方法の利点は、質問文と記事の言葉が直接一致しなくても、意味的に関連性の高い情報を見つけられる点にある。「モノグラム入りの商品は返品できますか？」といった質問に対し、具体的な返品ポリシーを検索するような場合に有効である。

もう一つは「ウェブ検索」である。これは、自社のナレッジベースにまだ取り込まれていない外部の情報源、あるいは運送状況、税制改正、ベンダーのサービス状況など、頻繁に変化する最新の公開情報に適している。ウェブ検索は情報の鮮度が非常に高い反面、検索結果の制御が難しく、外部サイトの内容がいつの間にか変わったり、消えたり、公開すべきでない情報が含まれたりするリスクがある。そのため、検索結果のURLと取得日時を記録し、情報として採用する際には必ず引用元を明示するような厳格なルールが必要となる。

どちらの検索方法を選ぶにしても、情報を「チャンク」（意味を持つ小さな情報の単位）に分割する工程は極めて重要である。チャンクが大きすぎると、重要な情報が埋もれてしまい、小さすぎると、文脈が失われ、その情報の意味が正確に伝わらなくなる可能性がある。この適切なチャンク分割を見つけるためには、実際の質問と失敗ケース（例えば、古いポリシーと新しいポリシーの違い、類似した製品名を持つ異なる顧客の情報、検索結果がページの境界にまたがるケースなど）を用いてテストを繰り返すことが不可欠である。

実用的なアプローチとしては、これら二つの検索パスを組み合わせる「二段階予算（Two-pass budget）」パターンが有効である。まず、社内の安定した情報を扱うベクトルストアで検索を行い、もし回答契約で「厳格な鮮度」が求められている場合や、ベクトルストアの情報が古い場合にのみ、ウェブ検索を利用するという流れである。異なる情報源からの結果を統合する際には、それぞれの引用元を明確に分離し、情報が矛盾する場合には自動で回答せず、オペレーターによるレビューを求めるべきである。古い情報に基づいて顧客に誤った回答をしてしまうよりも、この追加の確認プロセスの方がコストは低い。また、どの情報が内部のナレッジベースから来たのか、どの情報が外部のウェブ検索から来たのか、そしてなぜ両者が組み合わされたのかという監査証跡も残せるため、サポート業務の透明性を高めることができる。

検索システムの評価も非常に重要である。システムをリリースする前に、実際のドキュメント（成功事例だけでなく、過去のポリシー、似たような製品の記述、多言語の用語、アクセス権限のないドキュメント、重要な文章がチャンクをまたがっているページなど）から代表的な評価セットを作成する。それぞれの質問に対して、期待される情報源と許容される鮮度を記録しておく。そして、1ページあたりの表示件数内で関連情報をどれだけ取得できたか（リコール）、取得された情報がどれだけ正確であったか（プレシジョン）、引用が適切に行われたか、顧客フィルターが正しく適用されたか、といった指標を測定する。特に、1ページ目だけでなく、2ページ目以降でも引用情報が失われたりしないかを確認することが重要である。また、後で問題分析ができるように、データ取り込み時のリビジョン、クエリの契約内容、カーソル情報、選択された検索パス、最終的な引用IDなどをログとして記録するべきである。

最終的に、システム設計の決定はシンプルである。管理された安定した情報にはベクトル検索を、リアルタイムに変化する外部情報にはウェブ検索を、そして両方の要素が必要な回答にはこれらを組み合わせたパスを選択する。情報の鮮度とページネーションは回答契約に明確に含め、対象顧客のメタデータはシステム全体で保持し、顧客に不利益を与える失敗ケースに焦点を当ててテストを行うことが、信頼性の高いカスタマーサポート検索システムを構築する鍵となる。