引用付き回答とハルシネーション対策
検索で本文に近づいたら、次は、その本文を根拠に答える段階である。
ここで出てくるのがRAGである。
RAGは、Retrieval-Augmented Generationの略で、日本語にすると「検索拡張生成」あたりになる。名前は少し硬いが、この本で扱う範囲では、考え方はそれほど難しくない。
まず、本文から関連しそうな段落を探す。
次に、その段落をLLMに渡す。
そして、LLMに「この本文だけを根拠に答えて」と頼む。
つまり、AIに何でも知っているふりをさせるのではなく、先に資料を渡して、その資料の範囲で答えさせる。
このbotの /ask は、この仕組みで動く。
/ask q:ルークスの受けた依頼は？この質問に対して、botはまず本文を探す。
関連しそうな段落を集める。
必要なら前後の段落も足す。
それをLLMに渡す。
そして、本文引用だけを根拠に回答させる。
返ってくるのは、自然文の答えである。
けれど、この自然文がそのまま信頼できるわけではない。
AIはもっともらしく補う
LLMは、文章を作るのがうまい。
聞かれたことに対して、自然な形で答える。
足りないところを補い、文脈を整え、読みやすい文章にする。
それは長所である。
けれど、創作確認では、その長所が危うさにもなる。
本文にないことを、もっともらしく補ってしまうかもしれない。
似た設定から推測してしまうかもしれない。
一般的な物語のパターンを混ぜてしまうかもしれない。
本文には書かれていないことを、本文にあるかのようにまとめてしまうかもしれない。
AIの答えは、自然であればあるほど危ないことがある。
不自然な間違いなら、すぐ疑える。
しかし、自然な間違いは、うっかり信じてしまう。
特に創作設定では、それが危ない。
「そういえば、そうだった気がする」
「たしかに、そんな設定だったかもしれない」
「本文にも書いてあったような気がする」
作者本人でも、そう思ってしまうことがある。
長編創作では、頭の中の設定と本文に書いた設定がズレる。第2章で見た通りである。そこにAIのもっともらしい補完が混ざると、ズレがさらに見えにくくなる。
だから、このbotでは、LLMに自由に答えさせない。
本文以外は答えない。
本文にないことは断定しない。
推測しない。
一般論を混ぜない。
作者メタ情報も混ぜない。
そういう制限をかける。
本文引用だけを根拠にする
/ask では、LLMに本文引用を渡す。
そのとき、プロンプトでは「提供された本文引用のみを根拠にして答える」ように指示する。本文にない推測や一般論は禁止する。本文から分からないことは、分からないと答えさせる。
これは、AIを賢く見せるためではない。
むしろ、AIに賢そうなふりをさせないためである。
創作確認において大切なのは、滑らかな答えではない。
正確に本文へ戻れる答えである。
たとえば、ルークスが受けた依頼について聞いたとする。
LLMが「ルークスは人攫い蜂の退治を依頼された」と答える。
これだけなら、まだ足りない。
それが本文から出た答えなのか、AIが文脈から補った答えなのか、人間には分からないからだ。
必要なのは、答えと一緒に根拠が出ることである。
どの作品の、どの章の、どの段落にその情報があるのか。
その場所へ戻れば、本当にそう書いてあるのか確認できるのか。
だから、回答には出典IDを付ける。
[kimihana/作品ID ch17:p005]このようなIDがあれば、AIの答えをそのまま信じる必要はない。
本文へ戻ればいい。
「断定できません」と言えること
RAGで大事なのは、答えることだけではない。
答えないことも大事である。
本文に書いていないことを聞かれたとき、AIはつい答えようとする。
質問に対して、何かしら返そうとする。
それが会話AIとしては自然だからだ。
しかし、創作確認では、分からないことを分からないと言える方が重要である。
本文からは断定できません。
提供された引用からは確認できません。
少なくとも、この検索結果の範囲では見つかりません。
そう返せることが、信頼につながる。
もちろん、これは気持ちのいい答えではない。
聞いた側としては、答えがほしい。
「分からない」と返されると、少し物足りない。
検索範囲が足りなかったのか、質問が悪かったのか、本当に本文にないのか、さらに調べる必要が出てくる。
けれど、それでいい。
創作確認の目的は、AIに気持ちよく答えてもらうことではない。
本文上で何が言えるかを確かめることだからだ。
本文から断定できないなら、断定しない。
この姿勢は、かなり大事である。
出典IDは検証のためにある
出典IDは、AIの答えに権威を与えるためのものではない。
むしろ逆である。
AIの答えを疑えるようにするためにある。
出典IDがあれば、人間は本文へ戻れる。
前後の段落を読める。
AIの要約が妥当かどうか確認できる。
必要なら、「これは言い過ぎではないか」「この段落だけでは足りないのではないか」と判断できる。
つまり、出典IDは信頼の記号ではなく、検証のための取っ手である。
「出典があるから正しい」のではない。
出典へ戻れるから、確かめられる。
確かめられるから、創作確認に使える。
この違いは大きい。
引用付き回答というと、見た目には少し堅くなる。
会話としては、出典IDがない方が読みやすいかもしれない。
短く答えてくれる方が楽かもしれない。
けれど、このbotは雑談相手ではない。
小説本文を確認するための道具である。
だから、読みやすさよりも、戻れることを優先する。
/ask は要約する
/ask は、本文を根拠に自然文で答える機能である。
キーワード検索だけではたどり着きにくい質問に向いている。
「ルークスの受けた依頼は？」
「この二人はどこで知り合った？」
「この魔物について何が分かる？」
「この人物はなぜ怒っていた？」
こういう質問では、単純に単語を検索するだけでは足りないことがある。
関連する段落を探し、その内容を短くまとめて返す。
それが /ask の役割である。
ただし、まとめるときに情報を足してはいけない。
本文にあることだけを使う。
本文にないことは書かない。
複数の段落を使う場合も、どの情報がどの出典に基づくのかを示す。
要約は便利だが、便利な分だけ危うい。
長い本文を短くする過程で、ニュアンスが落ちる。
断定の強さが変わる。
「そう読める」と「そう書いてある」が混ざる。
だから、出典IDが必要になる。
要約を読む。
必要なら本文へ戻る。
本文を読んで、要約が妥当か確認する。
この往復ができることが、/ask の価値である。
/count は数える
一方で、/count は少し性質が違う。
/count q:人攫い蜂このように聞くと、画面には数字だけが返ってくる。
第1章の例では、人攫い蜂 の回数として 10 が返ってきた。
見た目はとても単純である。
しかし、内部ではやはり本文を根拠にしている。
関連する段落を探す。
前後の文脈を足す。
その本文引用の中で、指定された事象が何回明示されているかを数えさせる。
ここでも大事なのは、推測で数えないことである。
明示されたものだけを数える。
暗示や雰囲気は数に含めない。
理由や説明を返さず、数字だけを返す。
ただし、数えるという行為は難しい。
単語の出現回数なら、比較的分かりやすい。
しかし、「主人公が怒った回数」「誰かが助けられた回数」「依頼が発生した回数」のような自然文になると、何を一回とみなすかが問題になる。
言及と出来事は違う。
回想と現在の出来事も違う。
同じ出来事が複数回語られている場合もある。
だから、/count は便利だが、慎重に使う必要がある。
数字が返ってきたからといって、それが絶対ではない。
必要なら、数えた根拠となる本文へ戻る。
検索結果を確認する。
条件を変えて聞き直す。
ここでもやはり、本文へ戻ることが大切になる。
AIを信用しすぎないためにAIを使う
このbotの面白いところは、AIを使っているのに、AIを信用しすぎない設計になっているところだと思う。
AIに自由に答えさせるのではない。
本文を渡す。
本文だけを根拠にさせる。
出典IDを付けさせる。
必要なら本文へ戻って確認する。
これは、AIを疑っているからこその使い方である。
けれど、疑っているから使わない、という話ではない。
疑いながら使える形にする。
LLMは、曖昧な質問を受け取り、関連する本文をまとめるのが得意である。
人間が忘れていた場面に近づく助けになる。
長い本文から、必要そうな情報を短く返してくれる。
その力は使いたい。
ただし、答えを丸呑みしたくはない。
だから、引用付きにする。
本文以外は答えないようにする。
分からないときは分からないと言わせる。
これは、AIを信じるための仕組みではない。
AIを疑いながら、それでも便利に使うための仕組みである。
本文へ戻れる回答だけを採用する
この本で何度も繰り返している通り、合言葉は「本文へ戻る」である。
RAG回答でも、それは変わらない。
本文へ戻れない答えは、創作確認には使いにくい。
どれだけ自然でも、どれだけもっともらしくても、根拠が追えないなら不安が残る。
逆に、多少ぎこちない答えでも、本文へ戻れるなら確認できる。
出典IDをたどる。
本文を読む。
前後の流れを見る。
必要なら別の検索をする。
そのための入口を、回答の中に残しておく。
AIの仕事は、最終判定者になることではない。
本文へ戻る道を示すこと。
本文を読む人間の手間を減らすこと。
曖昧な記憶と本文の間に橋を架けること。
創作検索botにおけるRAGは、そのための仕組みである。
AIは答える。
けれど、答えは本文に縛られる。
人間はその答えを読み、必要なら本文へ戻る。
この距離感が、創作支援AIにはちょうどよい。
第6章では、こうした機能が実際にDiscord上でどう見えるのかを見ていく。
/search、/ask、/count、/first、/last。
それぞれのコマンドは、創作中のどんな場面で使うためのものなのか。
本文を根拠に答える仕組みを、日常の創作会話の中へ置く。
次は、そのUIと使い方の話である。