生成 AI の回答の由来をたどる

本シリーズの第 1 回では、DevRev の RAG パイプライン「チューリング（Turing）」とその開発経緯について説明しました。現在、 チューリングを顧客のビジネス課題解決に適用するにあたり、顧客に提供する回答の正確性と関連性を継続的に保証する必要があります。そのためには、分析を通じて各段階で何が起きているかを調査できる体制が求められます。

チューリング分析が重要な理由の一例として、最近サポートチームのメンバーと一緒に実際の問い合わせと回答を確認していました。未解決の問い合わせの多くが API に関するものであることに気づきました。数週間前に開発者向けドキュメントのプラットフォームを移行して以来、検索機能を完全には実装できていませんでした。それでも、API ドキュメントを DevRev ナレッジベース（KB）に記事として読み込み、 AI エージェントが API に関する問い合わせに回答できるよう準備を進めました。

ナレッジベースに記事が存在することを確認した後、自社ウェブサイトの PLuG にアクセスし「 API で記事を削除するにはどうすればよいですか？」とクエリを入力しました。嬉しいことに、まさに求めていた「 articles.delete 」という回答とリファレンスドキュメントへのリンクが返ってきました。Slack で説明を共有する前に、スクリーンショットを共有するより一般的なトピックを探そうと、「API でチケットを作成するにはどうすればよいですか？」と試しました。関連する回答は見つかりませんでした。次に「DevRev API でワークスペースにアカウントを作成するにはどうすればよいですか？」と試しました。関連する回答は見つかりませんでした。そこで、1 時間前には機能していた元のクエリに戻りました。関連する回答は見つかりませんでした。

そこで開発チームに確認しました。チューリング分析を通じて、回答が生成された理由と、その生成にナレッジベースのどの情報が使用されたかを特定しました。

ナレッジベースの質問と回答

前回のブログでは、ナレッジベース（KB）を複数のソースからの記事の集合と同義であるかのように説明しました。実際にはもう少し複雑です。KB 内の単語の約 90% は記事に由来するものの、DevRev には質問と回答（QnA）オブジェクトも存在します。 チュアリングは QnA を KB に含めます。QnA は記事とはいくつかの重要な点で異なります。

まず構造が異なります。記事は通常、あるトピックを詳細に扱います。例えば、サポートポータルに関する DevRev の記事は約 1,000 語で、概要、機能と利点のリスト、権限の説明、サポート記事の追加手順、カスタマイズオプションが含まれています。このような長さや複雑さのため、記事はセマンティック検索用にインデックス化される前にチャンクに分割処理されます。
QnA は記事よりも簡素です。名称が示す通り、主に質問とその簡潔な回答で構成され、パーツの関連付けや可視性といった基本メタデータが付随します。

記事とは異なり、記事は人間によって作成されますが、チューリング自体はナレッジベースで回答できなかった顧客の質問に基づいて Q&A を生成します。チューリングが Q&A を生成した後、担当者が回答を検証し、レビュー済みであることを確認する必要があります。この確認が完了して初めて、チューリングは回答として使用します。また「提案のみ」モードも用意されており、このモードではチューリングが回答を生成しますが、顧客への送信は行いません。このモードは、回答を顧客に公開する前にサポートチームが回答の品質を監視できるようにするためのものです。

最後に、QnA は記事のように単独で閲覧されるものではありません。顧客が閲覧できる QnA のカタログは存在しません。顧客が QnA のコンテンツにアクセスできる唯一の手段はチューリングです。ほとんどの場合、質問は記事で回答されることを想定しているため、QnA の有効期間は短い傾向にあります。ただし、特定の情報が QnA として永続的に残るケースも存在します。

問い合わせと回答の追跡

それでは、この投稿の冒頭にある例を詳しく見ていきましょう。DevRev アプリには、すべてのクエリと応答を表示するチューリング分析のダッシュボード（まだお客様には公開されていません）があります。私はこの 2 つの問い合わせを正確に見つけることができます。

同じ問い合わせ、同じナレッジベースから取得された項目であるにもかかわらず、一方は回答され、もう一方は回答さ れませんでした。これらの記録から、一方の問い合わせではコンテキストが無効と見なされたことがわかります。しかし、その理由を解明しようとしても、具体的に何が起きたのかは確認できません。

では、さらに一歩深く掘り下げてみましょう。チューリング分析では、問い合わせごとに以下のパラメータを含みます（時間やユーザーなどのイベントコンテキストに加えて）：

1. ユーザーが入力した問い合わせ（製品内分析の「問い合わせ」と同じ）
2. LLM によって言い換えられた問い合わせ
3. 検索によって取得されたナレッジベースの項目（「取得された記事」および「取得されたQ&A」と同じ）
4. 言い換えられた問い合わせに該当すると見られるナレッジベース項目（「有効なソース」と同じ）
5. 生成された回答（存在する場合）（「生成された回答」と同じ）

製品内分析から、クエリ1とクエリ3の項目1と項目3が同一であることは既に把握していた。また、成功ケースにおける有効なソース（項目4）と生成された回答（項目5）、および失敗ケースにおけるそれらが欠如していることも把握していました。問題は、コンテキストがなぜ時として無効になり、また別の時には有効になるのかという点でした。

つまり、失敗の原因は言い換える段階で生じていたことが判明しました：クエリは二つの異なる方法で言い換えられていたのです：

1. 「APIを使用して記事を削除するメソッド（方法）は？」
2. 「APIを使用して記事を削除するプロセスは？」

最初の方法は正しい回答を返し、2番目の方法は回答が得られませんでした。検索では同じ記事と QnA がヒットしたものの、言い換えられたクエリの違いにより、2番目のケースでは検証が失敗しました。興味深いのは、LLM が元のクエリには存在しなかった文脈 —— プロセス 対 メソッド —— を導入した点です。重要な用語は「API」「記事」「削除」です。一般的な用法では「メソッド」と「プロセス」は類似した意味を持ちますが、偶然にも「メソッド」は API の文脈において特定の意味を持ちます。

修正（Remediation）

この問題を開発チームに報告した後、すぐに RAG パイプラインへの更新が実施されました。API ドキュメントのクエリは現在、確実に動作します。変更点の一つは言い換えプロンプトへの修正であり、この変更によってこの特定の問題が解決されました。

これは非常に重要ですが、明日や来週、来月に発見される可能性のある問題についてはどうでしょうか？ 他の機能を壊すことなく、特定の問題に対処し続けるにはどうすればよいのでしょうか？ それがこのシリーズの次回、そして最終回のテーマとなります。