本当に機能するドキュメントQ&A：パターンと落とし穴

「自分の文書に質問してみよう」――これはビジネスAIという発想そのものを売り込むユースケースです。契約書、ポリシー、マニュアルにモデルを向けると、平易な言葉で答えてくれる。デモは人を惹きつけ、最初のバージョンは本当に簡単に作れます。厄介なのは、その簡単なバージョンが、あなたが試した質問では機能し、ユーザーが実際に尋ねる質問では失敗することです。本記事はその違いについて――ドキュメントQ&Aを信頼に足るものにするパターンと、機能しているように見えながら静かに間違っている落とし穴についてです。

ほとんどの失敗は検索の失敗

肝心なメンタルモデルはこれです。ドキュメントQ&Aは一つではなく二つのシステムです。第一に、検索が答えを含みそうな箇所を見つけます。第二に、モデルがその箇所を読んで応答を書きます。ほぼ全員が二つ目に執着しますが、実際に物事が壊れるのは一つ目です。関連する箇所がモデルの前に置かれなければ、どれほど流暢に生成しても正しい答えは取り戻せません――モデルは滑らかに、そして間違って即興します。悪い答えをモデルのせいにする前に、正しいテキストがそもそも検索されたかを確認しましょう。たいていは、されていなかったのです。

チャンク分割が、何を見つけられるかを決める

すべての質問のたびに文書ライブラリ全体をモデルに与えることはできないので、文書はチャンクに分割され、検索が探すのはそのチャンクです。したがって、どう分割するかは静かでありながら決定的な設計上の選択です。小さく分割しすぎると、一つの答えが断片にまたがって切断され、どのチャンク一つでも十分でなくなります。大きく分割しすぎると、各断片が自身の関連性を薄め、肝心の一文を、検索のスコアが低くなるノイズの中に埋もれさせます。さらに悪いことに、素朴な分割は表を真っ二つにし、見出しをそのセクションから切り離し、条項をそれを規定する条件から剥ぎ取ります。良いチャンク分割は、N文字ごとに切って祈るのではなく、文書の構造――セクション、見出し、リスト項目――を尊重します。

キーワードと意味、どちらも重要

初期のシステムは意味だけで照合し、埋め込みを使って質問と意味的に近い箇所を見つけていました。これは強力ですが、盲点があります。正確な語句です。特定の部品番号、エラーコード、条項参照、固有名詞を探すユーザーは正確な一致を必要としており、純粋な意味検索は「同じ話題について」の箇所へ漂って、文字どおりの文字列を取り逃すことがあります。長く使えるパターンは、アプローチを組み合わせることです――意味のための意味検索、精度のためのキーワード検索――そうすれば「リモートワークに関する当社の方針は」も「第4.2条(b)」も、正しい箇所に着地します。埋め込みと検索のためのツールはHugging Faceのドキュメントのような資料で十分に文書化されています。設計上の判断はあなたのものです。

「文書からのみ答えよ」という指示

正しい箇所が検索されたら、生成の工程には何より重要な一つの仕事があります。検索されたテキストから、そしてそのテキストからのみ答えること。モデルは膨大な世界知識を抱えており、制約しないでおくと、文書が言っていることと、自分が一般に信じていることを混ぜ合わせます――これが、自社が一度も書いていないポリシーをQ&Aシステムが自信満々に述べる仕組みです。モデルには、提供された箇所に根拠を置くこと、出典を引用または明示すること、そして箇所に答えが含まれていなければ率直にそう言うこと、を明示的に指示しましょう。その最後の振る舞い――「文書はこれについて触れていません」――は機能です。常に答えるシステムは、ときに嘘をつくシステムなのです。

引用は任意ではない

出典の指し示しのないドキュメントQ&Aの答えは、当てずっぽうとほとんど変わりません。ユーザーに検証する手立てがないからです。信頼を築くパターンは、答えを、それが出てきた具体的な箇所とともに返し、人間がクリックして確認できるようにすることです。これは3つのことを成し遂げます。ユーザー自身が検索の誤りを見つけられるようにし、システムを監査可能にし、モデルの振る舞いを根拠ある答えへと寄せます――今や証拠を指し示さねばならないからです。何か重大なこと――法務、医療、財務、コンプライアンス――については、引用は気の利いた付け足しではありません。それは、人間がその判断について説明責任を負い続けるための仕組みであり、まさにNIST AI Risk Management Frameworkのような枠組みが、結果が現実のものであるときに期待する種類の制御なのです。

それを壊す質問

よく作られたシステムでも、設計で備えるに値する予測可能な失敗モードがあります。多くの文書を統合する必要のある質問（「このポリシーは年々どう変わってきたか」）は、いくつかの関連箇所を見つけるよう調整され、すべてを横断して集約するようには調整されていない単純な検索に負担をかけます。文書が言っていないことに依存する質問は、ほぼ不可能です。検索は不在を浮かび上がらせられないからです。比較や計数の質問（「どの契約書がXに言及しているか」）は、箇所の検索とは別のアプローチを要します。そして表、図、スキャン画像は、しばしば本当の答えを担いながら、テキストベースの検索には見えません。これらの限界を知れば、構造上与えられない答えを約束する代わりに、システムの範囲を正直に定められます。

検索と答えを別々に測る

最後のパターンは、チームが省いて、後で悔やむものです。正しい答えと出典箇所が分かっている実際の質問のセットを作り、二つのことを独立に測りましょう。検索は正しい箇所を浮かび上がらせたか、そしてそれが与えられたうえでモデルは正しく答えたか。これらを一つの「答えは良いか」というスコアに潰してしまうと、システムがどこで失敗しているかが隠れ、手探りで調整することになります。分離すれば、診断は即座です――検索のミスと生成のミスは、まったく異なる修正を要します。チャンク分割、検索、プロンプトを変えるたびにこの評価を再実行しましょう。それらの変更はいずれも、以前は機能していた質問を静かに壊しうるからです。

知識を新鮮に保ち、ユーザーが何を尋ねるか見守る

二つの運用上の現実が、ローンチ後にドキュメントQ&Aシステムが良いままでいられるかを決め、どちらも構築の一部ではないため疎かにされがちです。一つ目は新鮮さです。基盤となる文書が変わった瞬間――ポリシーが改訂され、マニュアルが更新され、契約が差し替えられた瞬間――あなたのインデックスは古くなり、古いインデックスは自信満々に時代遅れの答えを生みます。変更された文書を再取り込みし、廃止されたものを取り除くプロセスが必要です。検索した箇所が前四半期に置き換えられた規則を記述していると、システムには知るすべがないからです。ローンチ時には正しく、今日では間違っている答えは、最も有害な失敗の一つです。まさに、かつて機能したがゆえに、誰もが確認をやめてしまっているからです。

二つ目の現実は、ユーザーが予期しなかったことを尋ねるということ、そして実際の質問のログが、システムが生み出す最も価値ある成果物だということです。それを読みましょう。悪い答えが返る質問は、検索がどこで失敗しているか、文書のどこに穴があるか、ユーザーがシステムには構造上提供できない能力をどこで期待しているかを、正確に教えてくれます。「AIが間違っている」という苦情の多くは、ふたを開ければ「文書がそもそもこれを扱っていなかった」――これは内容の問題であってモデルの問題ではなく、質問ログだけが明らかにするものです。稼働中のシステムを、文書に何が欠けているかを発見する計器として扱えば、Q&Aの層は穴を上塗りするのではなく、基盤となる知識ベースそのものを改善していきます。

まとめ

ドキュメントQ&Aは、それを魔法の答え箱としてではなく、生成の工程を上に載せた検索の問題として扱うとき機能します。チャンク分割では文書構造を尊重し、意味検索とキーワード検索を組み合わせ、答えを検索されたテキストに根拠づけることを強制し、引用を返し、検索と生成を別物として測る。何より、壊れない質問だけをデモするのではなく、それを壊す質問に備えて設計しましょう。そうすれば、文書への質問は手品であることをやめ、信頼できる道具になります。