ハルシネーションを防ぐため、ローカルRAGに検証レイヤーを追加した
Ollamaを使用して、ローカルのリサーチアシスタントを構築しました。これは自分の論文に基づいて動作します。データがマシンから外部に出ることはありません。
ハルシネーション（もっともらしい嘘）を止めたいと考えました。自信満々な口調で誤った数値を引用するツールは危険です。
検証レイヤーを追加しました。これは3つのステップで動作します：
- 回答を小さな主張（claims）に分解する。
- LLMを使用して、各主張がソースと一致しているか確認する。
- ソースが裏付けていない主張にフラグを立てる。
その結果、手痛い教訓を得ました。自分自身のデータについて、2回も間違えてしまったのです。
第一に、モデルは実在する数値を提示しましたが、文脈（コンテキスト）が間違っていました。存在しないテストセットに対して、AUROCが0.804であると引用したのです。数値自体は実在していましたが、文脈は嘘でした。検証器は、数字が一致していたため、これをパスさせてしまいました。
第二に、モデルが論文の別の部分から数値を拾ってきました。ある値を、誤った実験の結果として紐付けてしまったのです。
このテストから学んだことは以下の通りです：
検証は「値の欠如」しか検知できない。 数値がテキスト内に全く存在しない場合は、検証器がそれを検知できます。しかし、数値自体は実在するものの、誤った事実に関連付けられている場合、検証は失敗することがよくあります。
同じモデルを判定役（ジャッジ）にすると盲点が生じる。 回答を作成したモデルと同じモデルで回答を判定させると、自身のミスをそのまま承認（rubber-stamp）してしまいます。異なるモデルを判定に使用することで、誤った紐付けを検知しやすくなります。
フラグが常に「嘘」を意味するわけではない。 フラグには3つの可能性があります：
- 実際のハルシネーション。
- ソースが見つからなかった検索（retrieval）エラー。
- 検索されたテキストには含まれていなかった真実。 フラグが表示されたときは、単にその主張を削除するのではなく、データの再検索を試みてください。
- グラウンドトゥルース（正解データ）が必要である。 正解を知らなければ、ハルシネーションを測定することはできません。私は自分の研究について、2つの誤った知見を公表しそうになりました。ファイルを単純に検索し直すだけで、両方のエラーを修正できました。
RAGに関する実践的なアドバイス：
- 回答を行うモデルとは別のモデルを判定に使用する。
- 検索（retrieval）の精度向上に注力する。ほとんどの「ハルシネーション」は、単なる検索の失敗です。
- フラグを単なるエラーの兆候としてではなく、より深く調査するためのプロンプトとして扱う。
Optional learning community: https://t.me/GyaanSetuAi