ハルシネーションを減らす：実践的チェックリスト

ハルシネーションとは、真実でないのに自信を持って述べられた言明のことです。言語モデルがこれを生み出すのは、もっともらしい続きを生成するように作られているからであり、もっともらしく聞こえる虚偽は、モデルの観点からすれば申し分なく良い続きなのです。この傾向をプロンプトで完全に消し去ることはできません。しかし、モデルがでっち上げる理由を減らし、不確かさを認める理由を増やすように、タスクを作り直すことはできます。これは実際に効果のある手立てのチェックリストです。

モデルに事実を思い出させるのではなく、与える

ハルシネーションの最大の削減は、モデルの記憶にまったく頼らないことから生まれます。訓練中にたまたま吸収したものから答えるようモデルに求めるとき、あなたは思い出すことを求めています。そして思い出すことこそが、でっち上げの棲み処なのです。代わりに関連する元資料をプロンプトに提供し、それに基づいて答えるよう求めるとき、タスクは「これを覚えていなさい」から「これを読んで報告しなさい」へと変わります。読むことは思い出すことよりはるかに信頼できます。

これが検索拡張型のセットアップの背後にある核心的なアイデアですが、恩恵を受けるのにインフラは必要ありません。一度きりの質問のために関連文書をプロンプトに貼り付けるだけでも、でっち上げは劇的に減ります。答えがあいまいな記憶から再構成されるのではなく、いまやモデルの目の前にあるからです。取ってこられるどこかに事実が存在するなら、それを取ってきてコンテキストに入れましょう。

「わかりません」と言ってよいとモデルに伝える

モデルがでっち上げるのは、一つには言ってはいけないと誰も伝えなかったからです。利用可能な情報から答えられない質問に直面したとき、デフォルトの挙動は自信に満ちた推測を生成することです。推測は沈黙よりも確率の高い続きだからです。解決策は、答えないという選択を明示的に許可することです。「提供されたコンテキストに答えが含まれていなければ、推測せずに記載がない旨を述べなさい」。

このたった一つの指示は、そのシンプルさから想像される以上に挙動を変えます。モデルに公認の逃げ道を与えるので、安全な動きはもはやでっち上げではなくなります。指示はあなたの状況に即して具体的にしましょう。「文書にない」「情報が不十分」「範囲外」など、どの種類の非回答を返すべきかモデルにわかるようにします。これがなければ、本当の答えが得られないたびに、暗黙のうちに推測を求めていることになります。

答えを元資料に制限する

元資料を提供することは役立ちます。答えをそれに制限することはさらに役立ちます。「ここに文書があるので質問に答えなさい」と「この文書の情報のみを使って質問に答え、外部知識を加えてはいけない」の間には違いがあります。後者の枠組みは、文書が単なるヒントではなく境界であるとモデルに伝えます。元資料に裏付けられていないことをモデルが言いたがっても、指示によって禁じられているのです。

これを、主張を元資料に根拠づける、つまり各言明がどこから来たのか文書の該当箇所を指し示すよう求めることと組み合わせましょう。主張を出典に帰する行為は、その主張が実際に存在するかをモデルに確認させます。そして出典に帰せられない言明こそ、でっち上げられている可能性が最も高いものです。根拠づけは品質の向上であると同時に検出の仕組みでもあります。

難しい質問では答えの前に推論を求める

複数の事実やステップを結びつける必要のある質問では、即座の答えを要求すると、何も整理していないうちにモデルが確定してしまいます。そして早すぎる確定はでっち上げの肥沃な土壌です。まず質問を推論し、それから結論を述べるようモデルに求めると、各要素が実際には答えを支えていないと気づく余地が生まれます。

恩恵は二重です。推論はしばしばより良い答えを生みます。モデルが途中で自らの抜けに気づけるからです。そして推論は検証可能です。ステップを読めば、裏付けのない飛躍が、むき出しの結論では見えない形で見えてきます。単純な参照ではこれは省きましょう。手間に見合いません。統合を要するものなら、でっち上げを減らすと同時に露わにしてくれます。

各リクエストの負担を下げる

長く広範なタスクは、短く範囲の定まったタスクより多くのハルシネーションを招きます。一度に多くの小質問をやりくりするモデルには、裏付けられた道筋から逸れる機会が多くあるからです。複雑なリクエストを、それぞれ明確な入力と正しい答えがどう見えるかの明確な認識を持つ、より小さくよく定義された断片に分解すると、各ステップでモデルを短い綱で繋いでおけます。

小さなタスクは検証も容易です。リクエストが一つの焦点の定まった主張を生むなら、その主張を出典と照らし合わせて確認できます。数十の主張を織り交ぜた十段落のエッセイを生むなら、検証は非現実的になり、誤りがすり抜けます。範囲を絞ることは、一つにはでっち上げを減らすこと、もう一つには残ったでっち上げを捕まえられるようにすることです。

信頼せず、出力を検証する

どれだけプロンプトを工夫しても、モデルの出力がデフォルトで信頼できるようにはなりません。ですからチェックリストの最後の項目は検証です。重要なものについては、答えは公開すべき事実ではなく、チェックすべき下書きです。チェックは人間によるレビューでもよいですが、自動化もできます。引用された出典に実際に主張された情報が含まれているか、数字が合っているか、参照された項目が存在するかを確認するのです。

検証が可能になるようシステムを設計しましょう。出典を指し示す出力は、その出典と照らし合わせて確認できます。事実がどこから来たかを述べる出力は追跡できます。自信に満ちた、出典のない散文は、構造上検証不可能であり、検証不可能なところに見つからないハルシネーションが棲みます。目標は決して誤らないモデルではなく、発生する誤りが、誰かに届く前に捕まえられる種類のものであるパイプラインです。

まとめ

ハルシネーションを減らすのは、モデルを叱ることによってではなく、タスクを変えることによってです。事実を与えて、思い出すのではなく読ませる。わからないと言うことを許可する。答えを元資料に制限し、主張を根拠づけるよう求める。難しい質問では結論の前に推論させ、検証できるほど小さくリクエストの範囲を絞り、重要な出力はすべて信頼すべき事実ではなくチェックすべき下書きとして扱う。これらのどれもハルシネーションを根絶しません。何もそれはできません。しかし合わせれば、自信を持ってでっち上げるシステムを、その限界をおおむね認め、残りをチェック用に露わにするシステムへと変えられます。