【LLMセキュリティ】ゼロリソースブラックボックスでの幻覚(ハルシネーション)検出

【LLMセキュリティ】ゼロリソースブラックボックスでの幻覚(ハルシネーション)検出
Photo by Will / Unsplash

こんにちは、Qualiteg研究部です。

今回は、データベースなど外部の情報を使用しない「ゼロリソース」状態での幻覚(ハルシネーション)検出の手法である以下論文について解説いたします。

SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models
https://arxiv.org/abs/2303.08896

背景 LLMが出力する「幻覚」の問題

近年、生成型大規模言語モデル(LLMs)は、多様なユーザープロンプトに対して非常に流暢な応答を生成する能力を持っています。
しかし、これらのモデルは事実を幻覚させたり、非事実的な発言をすることが知られており、出力への信頼性を損なう可能性があります。
この問題に対処するための既存のファクトチェック手法は、出力確率分布へのアクセスが必要だったり、外部データベースを使用した複雑なモジュールを必要としたりします。

本論文では、SelfCheckGPTと呼ばれる新しいアプローチを提案しています。このアプローチは、ゼロリソースでブラックボックスモデルの応答をファクトチェックするためのシンプルなサンプリングベースの手法です。
SelfCheckGPTは、LLMがある概念についての知識を持っている場合、サンプルされた応答が類似しており、一貫した事実を含んでいる可能性が高いというシンプルな考えに基づいています。しかし、幻覚された事実の場合、確率的にサンプルされた応答は異なることが多く、お互いに矛盾する可能性があります。

幻覚検出の仕組みをざっくりいうと、

まず原理を簡単に説明します。

  1. ある入力プロンプトでLLMに応答を出力させます。
  2. さらに、同じ入力プロンプトをつかってLLMに複数の応答を出力させます。
  3. 複数応答させた出力テキストと、もとの出力を比較し、どれも同じことを言っているなら、「幻覚なし」、出力どうしを比較すると内容がマチマチなら「幻覚あり」
  4. 出力がマチマチになっていないかどうか、の評価のことを「一貫性の評価」といいます。この一貫性の評価手法にはいくつかあり、それぞれの長所短所があるよ、ということが書いてあります。

それでは、もう少しこれを詳細にみていきましょう。

本手法を用いた幻覚検出の利点

以下のように、大それた仕組みが不要で幻覚検出ができる点がメリットとなります

  • 外部データベースが不要
    サンプリングのみでモデルの知識を評価できるため、外部リソースを使用しなくてもブラックボックスモデルに適用可能な点
  • ゼロリソースアプローチ:
    モデル内部の確率分布や外部データに依存せず、純粋に生成されたテキストの一致性・一貫性で評価できる点

サンプリングによる多様な応答生成

まず、与えられたユーザープロンプトに対してLLM(大規模言語モデル)から複数の応答を生成します。このとき、応答を確率的にサンプリングすることで多様性を持たせます。

(「サンプリング」とはここでは、同じプロンプトを使って複数の応答を生成することを指します。)

サンプリングの手順

  • 特定のプロンプトを言語モデルに与え、モデルが生成する応答を複数回取得します。これにより、応答にバリエーションが生まれます。
  • たとえば、「ジョン・スミスはどんな職業ですか?」というプロンプトを与えると、モデルは複数の異なる職業を生成するかもしれません。

温度パラメータ(temperature)の使用

  • サンプリングの際に、温度パラメータを調整することで、応答の多様性を制御します。温度を高く設定するとランダム性が増し、より多様な応答が得られます。
  • 論文では、主応答の生成には温度0.0で標準ビームサーチを用い、サンプル応答の生成には温度1.0を用いて多様な応答を生成しています。

一貫性の評価

生成された複数のサンプル応答を比較し、それらがどれだけ一貫しているかを測定します。一貫している情報は事実である可能性が高く、ばらつきがある情報は幻覚である可能性があります。

一貫性の評価には、BERTScore、質問応答、n-gramモデル、自然言語推論(NLI)、プロンプトによる評価などの手法が用いられます。例えば、BERTScoreでは応答内の文とサンプル応答内の文をBERTを用いて類似度を測定し、一貫性を評価します。質問応答では、主応答から自動生成された質問に対する回答がサンプル応答でも一致しているかを確認します。n-gramモデルでは、サンプルから作成されたモデルを使い、元の応答内の文の出現確率を評価し、出現確率が低い場合は幻覚である可能性が高いと判断します。また、NLIでは、応答がサンプルと矛盾しているかを評価し、矛盾が多い場合は幻覚とみなします。さらに、プロンプトによる評価では、LLMに対して文がサンプルによって支持されているかをYes/Noで評価させ、一貫性を測ります。

一貫性の評価手法のまとめ

以下は一貫性=内容のばらつきの有無を確認する 評価の手法を以下にまとめました

手法 概要 利点 評価
BERTScoreを用いた手法 応答内の文をサンプル応答内の文と比較し、BERTを用いて類似度を測定 BERTを使用し、文の意味的な類似性を高精度で評価可能 他の手法に比べて劣ることがあるが、一部のケースで有用
質問応答を用いた手法(QA) 自動生成された選択肢付き質問を使用し、応答の一貫性を評価 質問応答の形式で情報を具体的に検証し、一貫性の高い情報を特定可能 中程度の性能で、特に詳細な情報検証が必要な場合に効果的
n-gramモデルを用いた手法 サンプルからn-gramモデルを作成し、応答内の文の出現確率を評価 簡単で計算コストが低く、トークン出現の確率を利用して幻覚を検出 大規模データで効果的だが、単独では限界がある
自然言語推論(NLI)を用いた手法 文がサンプルと矛盾しているかをNLIモデルで評価 文間の論理的一貫性を評価することで、幻覚検出に高い精度を示す 非常に高い性能を示し、実用的な選択肢
プロンプトを用いた手法 LLMに対して、文がサンプルによって支持されているかをプロンプトを使ってYes/Noで評価 直感的でシンプルな方法で、特に最新の言語モデルを利用する場合に有効 最も高い性能を示し、全体的に優れた方法

幻覚スコアの計算

こうして得られた一貫性の情報を基に、各文に幻覚スコアを計算します。このスコアは0.0から1.0の範囲で、0.0に近いほど事実に基づいており、1.0に近いほど幻覚であることを示します。検出の基本原理として、LLMが特定の情報について正確な知識を持っている場合、サンプリングされた応答は類似しており、一貫した事実を含む傾向があります。逆に、幻覚された事実はサンプル応答の間でばらつきがあり、矛盾が生じやすくなります。このように、SelfCheckGPTは応答の一貫性を基に幻覚を検出するアプローチを採用しています。

結論とおすすめの手法

  • 最も効果的な手法
    論文の結果から、プロンプトを用いた手法(SelfCheckGPT with Prompt)は最も高い精度を示しており、特に新しい言語モデル(例えばGPT-3.5やそれ以上)を用いる場合において最適です。この手法は、一貫性の高い評価を行うため、幻覚検出において最も信頼性が高いと報告されています。
  • 複数手法の組み合わせ
    それぞれの手法が異なるアプローチを提供するため、複数の手法を組み合わせることで、検出の精度をさらに向上させることができます。特に、プロンプト手法とNLI手法の組み合わせは、性能と計算コストのバランスが良く、幅広いシナリオに対応可能であることがわかりました。

まとめ

実際の利用シナリオによって、計算コストや利用可能なリソースが異なるため、どの手法を選択するかは状況によりますが以下のポイントを考慮して選択することが最終的に必要になるのではないでしょうか。

  1. 高精度を求める場合:
    プロンプト手法をメインに、必要に応じてNLI手法を補完的に使用。
  2. 計算コストを抑えたい場合
    n-gram手法やBERTScore手法を組み合わせて利用。
  3. 細かい検証が必要な場合:
    質問応答手法を利用して、詳細な一貫性評価を行う。

LLM-Audit ™のご紹介

Qualiteg では、LLMのセキュリティソリューション「LLM-Audit™」を開発・提供しております。
LLMがビジネス活用されるにつれ、LLMへの各種攻撃が活発化しています。
一方で、これまでのWebセキュリティとはまた異なったLLMへの攻撃についてはまだ知見も乏しく防衛手段も確立していません。

(株)Qualiteg では、LLMサービス開発・運営を通して得た経験・知見を集めた LLM防衛ソリューション 「LLM-Audit™」※をご提供しています。

※本論文にある SelfcheckGPTによるハルシネーションの検出にも対応しています。

また、悪意ある入力プロンプトのブロック、LLMによる不適切な出力の監査を強力に実行しLLMの安全、安心を実現することができます。

OpenAI API 互換サーバーとして貴社LLMをラッピングするだけで利用できますので非常に小さな導入コストで高度化したLLMセキュリティを実現することが可能です。

LLMセキュリティやLLM-Audit™ にご関心がおありの場合は以下までご連絡くださいませ。またLLMセキュリティコンサルティングや製品デモについてもどうぞお気軽にこちらのお問い合わせフォームまでご連絡くださいませ。

Read more

シェルスクリプトからcondaコマンドを活用したいとき

シェルスクリプトからcondaコマンドを活用したいとき

こんにちは! 今日はみんな大好きcondaコマンドについてです。 condaコマンドで仮想環境に入って、何らかの処理をして、戻ってくる ようなシェルスクリプト、バッチタスクをやるときのTipsです。 AI開発において、Anacondaとその中核であるcondaパッケージマネージャーはとっても重宝します。 しかし、シェルスクリプトから自動的にcondaを利用しようとすると、意外なハードルがあります。 本記事では、シェルスクリプトからcondaコマンドを正しく呼び出す方法について解説します。 condaと非対話モードの課題 AnacondaがインストールされているLinux環境において、condaコマンドは通常、.bashrcや.bash_profileなどの設定ファイルによって初期化されます。 なんとなくシェルをつかっていると、このcondaコマンドの初期化を忘れてしまいますが、これらの設定は多くの場合シェルの「対話モード」でのみ有効になるように設計されています。 ゆえにシェルスクリプトのような非対話モードでは、condaコマンドが正しく機能してくれません 例えば、.b

By Qualiteg プロダクト開発部
Node.jsで大容量ファイルを扱う:AIモデルのような大きなデータ保存はストリーム処理使いましょう

Node.jsで大容量ファイルを扱う:AIモデルのような大きなデータ保存はストリーム処理使いましょう

こんにちは!今日はAIシステムのフロントサーバーとしてもよく使用するNode.jsについてのお話です。 AIモデルの普及に伴い、大容量のデータファイルを扱う機会が急増しています。LLMなどのモデルファイルやトレーニングデータセットは数GB、場合によっては数十、数百GBにも達することがあります。 一方、Node.jsはWebアプリケーションのフロントサーバーとして広く採用されており、データマネジメントやPythonで書かれたAIバックエンドとの橋渡し役としてもかなりお役立ちな存在です。 本記事では、Node.js v20LTSで5GB程度のファイルを処理しようとして遭遇した問題と、その解決方法について解説します。 Node.jsのバッファサイズ制限の変遷 Node.jsのバッファサイズ制限は、バージョンによって大きく変化してきました Node.jsバージョン サポート終了日 バッファサイズ上限 備考 Node.js 0.12.x 2016年12月31日 ~1GB 初期のバッファサイズ制限(smalloc.kMaxLength使用) Node.js 4.

By Qualiteg プロダクト開発部
AGI時代に向けたプログラマーの未来:役割変化とキャリア戦略

AGI時代に向けたプログラマーの未来:役割変化とキャリア戦略

はじめに 私がはじめてコードを書いたのは1989年です。 当時NECのPC88というパソコンを中古でかってもらい N-88 Basic というBASIC言語のコードをみようみまねで書いて動かしたあの日から何年経つのでしょうか。 当時、電波新聞社のマイコンBASICマガジンという雑誌があり、ベーマガにはいろんなパソコン向けのプログラムコードが掲載されていました。 そんなわけでもう35年以上趣味や仕事でプログラミングに従事していますが、開発環境、情報流通の仕組みには革命といっていいほどの変化、進化がおこりました。 しかしながら、そんな中でも、あくまでコードを書くのは「私」という生身の人間でした。 そうしたある種の古き良き時代は、いよいよ本格的に終わりを告げようとしています。 2023年ごろからのLLM技術の飛躍的進歩により、プログラミング業界は大きな転換期を迎えています。 特に、OpenAI o3,o1やClaude 3.5、Gemini2.0などの大規模言語モデル(LLM)の進化や、その先にある将来的な汎用人工知能(AGI)の出現は、プログラマーやAIエンジニアの役割に根

By Tomonori Misawa / CEO
PythonとWSL開発のトラブルシューティング: PyCharmとCondaの環境不一致問題

PythonとWSL開発のトラブルシューティング: PyCharmとCondaの環境不一致問題

こんにちは! 今回は、WSL上のConda環境をPyCharmから利用する際に発生した「同じ環境なのにパッケージリストが一致しない」という問題に遭遇したため、その原因と対策について書いてみたいとおもいます 問題の状況 開発の流れは以下のようなものでした 1. WSL環境でConda仮想環境を作成 2. その環境をPyCharmのプロジェクトインタプリタとして設定 3. 開発を進める中で奇妙な現象に気づく 具体的には、次のような不一致が発生していました * PyCharmのプロジェクト設定で表示されるpipパッケージのリスト * WSLでConda環境をアクティベートした後にpip listコマンドで表示されるパッケージのリスト これらが一致せず、「WSL側のシェルから直接インストールしたパッケージがPyCharmで認識されない」という問題が生じていました。 この手の問題でよくある原因は、PyCharm側がWSL側の更新を得るのに少し時間がかかったり、 Indexing が遅れているなどなのですが、今回はそれが原因ではありませんでした。 危険な「静かな

By Qualiteg プロダクト開発部