Jay Revels（ジェイ・レヴェルス）とFrancisco Soares（フランシスコ・ソアレス）共著
LLMアプリケーションのプロダクトマネージャーや、LLMアプリケーションに資金を提供するビジネスリーダーは、社内ユーザーや顧客にアプリケーションを使用させることに躊躇することがあります。。なぜなら、LLMアプリケーションのハルシネーションがあまりにも頻繁に、予測不可能に発生するからです。。開発者がアプリケーションのハルシネーションを許容できるレベルまで減らしたと思った矢先、データセット、プロンプト、検索エージェントに小さな変更を加えただけで、LLMは再び望ましくないレベルのハルシネーションを見せ始めることがあります。私たちは以前、ハルシネーションを抑えるテクニックについて、以下の記事「Re-Rankingの力：RAGシステムを強化する」や「RAGの精度向上：チャンクサイズ、クエリ変換、チャンク方法のカスタマイズ」などを書きました。
さらに、LLMアプリケーション開発者は、アプリケーションに適切な目標ハルシネーション率の設定方法について、慎重に検討を重ねているところです。目標とするハルシネーション発生率が達成された場合、どのようなメリットがあるのか、達成されなかった場合、どのようなリスクがあるのかを知りたがっています。LLMアプリケーションプロジェクトの予算を確保し、その成功を確実に測定するための指標は何か、という重要な問いも出ています。
このブログ記事では、以下のことを解説します。
- AHR（許容ハルシネーション率）の定義
- 適切な目標AHRの決定プロセス
- AHRを活用したプロジェクト予算獲得の戦略
- AHRの継続的なモニタリングと報告手法の習得
ハルシネーションの許容率とは
ハルシネーションとは、LLMが、事実に基づかない情報を生成する現象のことです。これには捏造された事実、誤った解釈、完全にでっち上げられた情報などが含まれます。大規模言語モデル（LLM）アプリケーションLLMアプリケーションにおける許容ハルシネーション率（AHR）とは、ユーザーが許容できる、ハルシネーションを含む生成された回答の割合を指します。ユーザーがハルシネーションを修正する時間が、LLMアプリケーションの生産性向上メリットを超えない場合、ユーザーはその割合のハルシネーションを許容します。
ハルシネーション発生率がAHRを超えるとどうなるか。生じるリスクとは？
ハルシネーション発生率がAHRを超えると、アプリケーションの採用率はすぐに低下します。 アプリケーション開発者やプロダクトマネージャーは、幻覚率が少し上昇したからといって、採用率が同じように少し下がると考えるべきではありません。 実際、ハルシネーション発生率が2～5％上昇すると、すぐに採用率がゼロになる可能性は十分に有り得ます。今日のほとんどのLLMアプリケーションは、これまで人間が行っていたワークフローやタスクを置き換えるものであることを忘れてはなりません。
したがって、LLMアプリケーションのユーザーは、LLMアウトプットの品質に大きな期待を寄せているのです。彼らは、アプリケーションの出力と、これまで手作業で行っていた作業の結果を比較します。もしアプリケーションがAHRを維持できなければ、彼らはすぐに手作業に戻すでしょう。もし導入がゼロになれば、導入が再開されるまで、アプリケーションの予測された生産性、時間の節約、または収益の利益は失われます。AHRを維持できないことによるその他のリスクには、次のようなものがあります。
- ユーザーの信頼性と体験： ユーザーは、正確かつ信頼できる情報を求めてAI主導のアプリケーションに頼る。ハルシネーション発生率が高いと、信頼が損なわれ、将来的にユーザーが新しいアプリケーションの採用をためらう可能性がある。
- 運用の非効率性： AIシステムからの出力に一貫性がなかったり不正確であったりすると、情報を検証・修正するための追加リソースの必要性など、運用上のオーバーヘッドが増大する可能性がある。AHRの設定：許容可能なハルシネーション率を決めるには、以下のことが必要です。
- 法的・倫理的リスク： アプリケーションによっては、特に医療、金融、法律などの分野において、ハルシネーションが深刻な法的・倫理的影響を及ぼす可能性がある。
- 継続的改善の阻害： 展開プロセスの一環としてハルシネーション発生率を管理しないと、アプリケーションのROIの継続的な改善が阻害される可能性がある。
ハルシネーション発生率がAHRを下回るとどうなるか。
ハルシネーション発生率を許容範囲以下に抑えることができれば、アプリケーションのROIは向上する可能性があります。
例えば、LLMアプリケーションが外部顧客向けの電子メールのドラフトを書くものとしましょう。
ハルシネーションが少なければ、人間がハルシネーションの確認と修正に費やす時間は減少します。 つまり、ハルシネーション率が改善されるにつれて生産性が向上し、組織のROIが大きくなる可能性があるということです。
他のユースケースでは、ROI向上の機会がより限定されるかもしれません。
例えば、LLMアプリケーションが作成した電子メールの下書きが、人間によるレビューなしで直接外部顧客に送信されることを想定しているとします。このユースケースでは、アプリケーションをリリースするためには、非常に低いAHRが必要になります。
従って、AHRを多少改善したところで、ROIの大幅な改善は見込めないでしょう。どのようなユースケースであれ、AHRは、アプリケーションライフサイクルの中での要件の変化により、変動する可能性があります。開発者とプロダクトマネージャは、AHRの継続的なモニタリング、維持、最適化が成功とROI確保の鍵だと認識すべきです。
AHRの設定方法
許容ハルシネーション率の設定
ハルシネーションをゼロにすることは不可能です。ほとんどのユースケースでは、ユーザーが有用な情報を得ることの妨げにならない限り、ある程度のハルシネーションは許容されます。ハルシネーションの影響は、それぞれのユースケースで考慮しなればなりません。例えば、クリエイティブやエンターテイメント分野においては、ハルシネーションが体験を向上させるかもしれません。ただし、医療、金融、法律相談などの分野では、ハルシネーションによる誤りが重大なリスクをもたらす可能性があります。
許容できるハルシネーション率は、アプリケーションのユースケースやーザーに大きく依存します。それは以下のような要因に影響されます。
- アプリケーションの目的： クリエイティブ もしくはファクトのコンテンツ生成
- 正確性の重要性： 法律文書 / カジュアルな会話ボット
- ユーザーの期待値： プロフェッショナルな使用 / 個人的な使用
- 規制： コンプライアンスと法的影響
AHRの設定：許容可能なハルシネーション率を決めるには、以下のことが必要です。
- ユースケースの深い理解： 開発者とプロダクトマネージャーは、ユースケースとLLMアプリケーションが自動化するワークフローを深く理解しなければならない。 ワークフローのどの部分が幻覚の影響を最も受けやすいか、また他の部分はより許容しやすいかを特定する。
- ユーザーからのフィードバックとテスト： 幻覚の影響についてユーザーから洞察を集め、どの幻覚が許容され、どの幻覚が許容されないかについて意見を得る。
- 領域固有の基準： 業界特有の基準や慣行を考慮する。
- 反復的改善： 使いやすさを維持しながら、ハルシネーションを最小限に抑えるために、モデルと検索技術を継続的に改良する。
AHRはユースケースと、ユーザーがハルシネーションを許容できるレベルに依存します。組織は、何百ものLLMアプリケーションが同時に実行される未来を想像するべきです。開発者、プロダクトマネージャー、およびビジネスリーダーは、各アプリケーションが各ユースケースのAHRに対してどの程度機能しているかを報告します。AHRを一貫して達成することで、組織は、法的・倫理的リスクを低く抑えながら、投資に対するROIを確実に確保していると確信することができます。
予算を確保するために、AHRを利用するにはどうすればよいか。
企業幹部は、LLMアプリケーションの開発と展開に資金を提供する任務を負っています。
その多くは、どの程度の投資を行うべきか確信が持てず、さらに重要なこととして、ROIがどの程度になるのかが不明確な場合が多いのです。プロダクトマネージャーやアプリケーション開発者は、プロジェクトの資金を確保するために、説得力のあるビジネスケースを明確にし、作成するのに苦労することが多いです。マーケティングや財務のような他の分野では、プロジェクトとその資金調達の可能性を評価するために、社内で合意された指標が使用されます。例えば、新しいマーケティング投資は、CAC（顧客獲得コスト）をいかに下げるかで評価されるのです。 財務の分野では、経費を削減するための新しいアプリケーションが、純利益率をどのように増加させるかについて評価されるかもしれません。AHRは、同様の方法で、新しいLLMアプリケーションの予算確保を正当化するために使用できると考えています。
ROIの見積もりを計算する
上述したように、AHRを設定するとき、開発者とプロダクトマネージャーは、LLMアプリケーションが自動化しようとしているユースケースとワークフローを深く理解しなければなりません。
上述したように、AHRを設定するとき、開発者とプロダクトマネージャーは、LLMアプリケーションが自動化しようとしているユースケースとワークフローを深く理解しなければなりません。
その発見段階やユーザーとの会話の中で、プロダクトマネージャーは、人間がタスクを完了するのに現在かかっている時間を計算するのが一般的です。例えば、法務のユースケースを例にとると、プロダクトマネージャーは、社内の法務アシスタントが法務レビューの初稿を書くのにかかる時間を特定します。そして、LLMを使うことでどれだけの時間を節約できるかを、ユーザーの協力を得て見積もります。プロダクトマネージャーは、ユースケースのプロトタイプや、同じようなアウトプットを持つ他のアプリケーションからのROIを使用して、LLMアプリケーションを採用するユーザーにとっての時間節約を見積もることができます。同時に、プロダクトマネージャーと開発者は、レビューのどの側面がハルシネーションに耐えやすく、どの側面が耐えられないかについてのフィードバックを集め始めることができます。AHRが設定され、ビジネスケースが構築できます。
以下は、ビジネスケースを構築するための基本的なモデルです。
AHRがLLM出願の成功を測る指標となる
上の例はLLMのユースケースであり、ユーザーの時間節約を予測しています。
この計算では、毎月AHRを1年間達成した場合、ユーザーは2,400,000労働時間を節約し12,000,000,000円のコスト削減を実現することになります。この計算には含まれていませんが、ビジネスケースに追加するのはまったく正当なことです。例えば、営業担当者は顧客とのミーティング設定により多くの時間を費やすことができるため、月間のミーティング総数を増やすことができるかもしれません。顧客とのミーティングを増やすことは、ほとんどの営業組織において収益の増加と強い相関関係があります。
プロダクトマネージャーや開発者は、予算保有者から次のような質問を受けるでしょう。
- 予想されるROIはどのくらい？
- それをどのように測定するのか？
- 長期的な成功をどのように確認するのか？
私たちは、AHRこそが、予算保有者が予算配分を決定するために必要な明確さをもたらす指標であると考えています。もし開発者とプロダクトマネージャーがアプリケーションのAHRを設定したならば、予算保有者は、そのユースケースがエンドユーザーの協力を得て徹底的に吟味されたものであると確信することができます。さらに、マーケティング担当者がCAC（顧客獲得コスト）を使うように、あるいは財務部門が純利益率を使うように、日次、週次、月次のダッシュボードで、LLMアプリケーションのどれが目標のAHRを達成しているかを見ることができます。このように、LLMアプリケーションの成功はファジーロジックに基づくものではありません。
その代わり成功は、日次、週次、月次ベースで測定可能な、合意され吟味された指標に基づいています。
一貫して達成されれば、開発者とプロダクトマネージャーは、幻覚の最適化が機能していることを示す方法を手に入れることができます。 コンプライアンス担当者や法務担当者は、アプリケーションが組織のリスクを増大させていないと確信できます。また、プロジェクトに資金を提供した経営陣は、そのアプリケーションがAIによって約束された生産性の利益をもたらしていることに自信を持つことができます。
LLMのAHRを監視するために、どのようなレポートやダッシュボードが利用できますか？
AHRは、開発者、プロダクトマネージャー、コンプライアンス担当者、ビジネスリーダーに、企業全体のAI導入がどのように進んでいるか、また個々のLLMアプリケーションが生産性、コスト削減、収益の成果をどのように出しているかを知らせる指標です。しかし、この重要な指標を監視するために必要なレポートやダッシュボードを作成するのは、どれほど難しいことでしょうか。このレポートと分析機能を提供できるツールは数多くありますが、私たちはArizeを気に入っています。LLMメトリクスのレポートと分析は、LLM OPSという最近話題になっているカテゴリーに当てはまります。ArizeとそのオープンソースオプションであるArize Phoenixには、LLMのハルシネーションをデバッグし、可視化された自動化されたアプローチでパフォーマンスをより迅速に評価するための多くの機能とツールがあります。
Arizeでは、カスタムメトリックを作成し、この場合は「Acceptable Hallucination Rate（許容ハルシネーション発生率）」とします。 望ましいハルシネーション発生率を設定し、その変化を1時間、1日、1週間、1ヶ月にわたってモニターすることができます。ビジネスサイドの利害関係者もダッシュボードにログインし、アプリケーションごとに設定されたAHRに対して、各アプリケーションのハルシネーション発生率がどのように推移しているかを確認することができます。
同様に重要なのは、開発者がAHRの変更についてアラートを受け取り、これらのアラートをトリガーする閾値を設定できることです。アラートはslackやメールに送信することができるので、開発者はすぐに行動を起こし、ハルシネーションをデバッグし、修正を実装し、ユーザーの採用率が低下するのを防ぐことができます。
結論
AHRは、LLMアプリケーション全体で設定、監視、最適化するための重要な指標です。
AHRは、組織におけるAI導入の進捗と成功のレベルを示す指標として、利害関係者を一体化させます。AHRを設定、監視、報告することに課題がないわけではありません。多くの企業では、これを成功させるための専門知識やツールが不足しているのが現実です。私たちLLM Recovery Labは、予測不可能なハルシネーションに悩むAI導入希望のお客様のためのソリューションを開発し続けていきます。このような問題をお持ちの方は、ぜひお問い合わせください。皆様からのご連絡をお待ちしております。
注意事項 – 上記ブログの一部ではありません。
RAGアプリケーションにおけるハルシネーションの管理
RAGの概要 検索補強型生成は、LLMと外部の知識ソースを組み合わせ、より正確で文脈に関連した応答を生成します。生成されたコンテンツを実世界のデータに基づかせることで、ハルシネーションを軽減するのに役立ちます。
ハルシネーション発生率をコントロールする戦略
入力を最適化する： クエリー強化やキーワード増強などのテクニックを活用し、意味検索プロセスを改善する。
検索メカニズムの強化： 再順位付け、ハイブリッド検索、カスタム類似性アルゴリズムなどのテクニックを使用し、高品質で関連性の高いデータが生成プロセスに取り込まれるようにする。
モデルの微調整： LLMを特定のユースケースやデータに合わせて調整することで、ハルシネーションの傾向を低減する。
継続的なモニタリングと評価： メトリックスとガードレールを実装し、ハルシネーション発生率とユーザー満足度を継続的に監視する。
急速に進化する人工知能の世界では、大規模言語モデル（Large Language Models：LLM）や検索拡張生成（Retrieval-Augmented Generation：RAG）システムが、情報との関わり方やコンテンツの生成方法に革命をもたらしています。
これらのモデルは驚くべき能力を提供する一方で、課題がないわけではありません。最も重要な課題の1つは、モデルがもっともらしいが不正確な、あるいは捏造された情報を生成するハルシネーションです。
許容可能なハルシネーション発生率を理解し定義することは、イノベーションと信頼性のバランスをとる上で極めて重要です。特に、これらのテクノロジーが、創作活動から医療や金融における重要な意思決定まで、多様な領域でますます適用されるようになっています。
このブログでは、ハルシネーション許容率とは何か、どのように決定されるのか、そしてなぜそれがLLMとRAGアプリケーションの有効性と信頼性を確保するために極めて重要なのかについて掘り下げていきます。
