シェア:
){kind=small}
Shir HilelはVonageの機械学習エンジニアで、大規模な言語モデルによるソリューションなど、AIベースのシステムの開発と改善に取り組んでいる。彼女の仕事は、信頼性が高くスケーラブルなデータ駆動機能の構築に重点を置いています。
LLM駆動バーチャル・エージェントにおける幻覚の排除
所要時間：1 分
Vonage AI Studioが構造化推論フィールドとスキーマ順序の絞り込みを使用して、どのようにLLMの幻覚を除去するかをご覧ください。
Vonage AI Studioは、音声チャネルとデジタルチャネルにまたがるバーチャルエージェントを構築・管理するためのローコードプラットフォームで、ユーザーを理解し、インテリジェントな会話を促進するためにAIが舞台裏で動作します。長年にわたり、このプラットフォームは継続的に進化してきました。 NLUエンジンキーワードベースのアプローチからエンベッディングベースのモデルへ、そして今日ではLLMを利用した理解へと、新しい技術が採用されるにつれて進化し続けています。
私たちのバーチャルエージェントプラットフォームは、インテントを検出し、パラメータを抽出し、ユーザ入力を検証し、会話をガイドする会話エージェントを構成することを可能にします。基礎となるLLMは、設定された意図、パラメータ、検証ルールとともに会話のコンテキストを受け取り、次の会話ステップを決定する構造化されたJSON出力を返す。システムが成長するにつれ、私たちはLLMの幻覚、つまり設定やユーザー入力に基づかない出力に繰り返し遭遇しました。
このブログ記事では、LLMの出力精度、安定性、信頼性を向上させるために導入された改善について説明する。直面した課題、適用された変更、そしてこれらの調整によってシステムの応答品質が全体的にどのように改善されたかを概説している。
Error rate comparison before and after introducing structured reasoning: 23.7% of responses were incorrect before changes, dropping to just 1.0% after.
LLMは、システム構成やユーザー入力に根拠がなくても、正しいように見える流暢な応答を生成することができる。これはしばしば幻覚を引き起こし、エージェントが自信を持って無効なデータを受け入れたり、存在しない能力を作り出したりする状況につながる。次の例はこの問題を示している。
問題の説明
予約ID 予約IDパラメータは厳密なフォーマットに従うように定義されています：
3つの大文字の後に3桁の数字.
このシナリオでは、エージェントがこのルールの適用に失敗する一方で、ユーザはIDを3文字ではなく2文字だけ提供する。
会話だ：
ユーザー 予約をキャンセルする
エージェントです：キャンセルの手続きには予約IDが必要です。教えていただけますか？
ユーザー そのab1234
エージェントです：予約IDはAB1234ですね。間違いありませんか？
この場合、エージェントは定義されたフォーマットルールを実施する代わりに、誤って正規化し、無効な値を確認する。
問題の説明
このシステムには システムには 血液検査結果という名前のパラメータは定義されていません。 IDというパラメータも定義されていないが、LLMはまだこの機能とパラメータが存在すると幻覚を見ている。
会話だ：
ユーザー血液検査の結果を知りたい
捜査官はい、あなたの最近の血液検査の結果がわかります。身分証明書をご提示ください。
エージェントは、サポートされるケイパビリティと要求されるパラメータの両方を捏造し、ユーザーの信頼に深刻な影響を与える可能性のある誤解を招くインタラクションを作成する。
LLMは多くの場合、システム指示、ユーザー入力、タスク固有のルールなど、プロンプトのさまざまな部分からの情報を使って答えを生成する必要がある。このコンテキストが散在していたり、一貫性がなかったり、動的なユーザーデータ（パラメータ形式の変更など）に依存している場合、モデルは間違いを犯す可能性が高くなる。
なぜこのような障害が発生するのかをよりよく理解するために、分析中に繰り返し浮上したいくつかの根本的な原因に分解することができる。
LLMは、必要なすべてのピースを正しく接続できないことがある。よくある問題は以下の通り：
間違ったユーザーインテントを選択する。
バリデーションの適用が間違っている。
以前の分析と矛盾する出力を生成したり、不足している命令やパラメータ形式を幻視したりする。
プロンプトが複雑で断片的であればあるほど、こうした問題は起こりやすくなる。
LLMは段階的にテキストを生成するが、その推論は内部的なものにとどまる。もし早い段階で間違った仮定をすれば、目に見える説明なしに最終的な出力は間違ってしまう。これを解決するには、プロンプトチューニングだけでは不十分だ。モデルが推論を示すことを強制されない限り、幻覚を追跡することも防ぐこともできない。
実世界のアプリケーションでは、解析や実行が可能な、構造化された予測可能な出力が要求される。同時に、研究によれば 厳密な出力制約のような フォーマットの一貫性の強制モデルの推論能力を抑制し、タスクの精度を低下させる可能性がある。制御と柔軟性のバランスを見つけることは非常に重要ですが、まだ未解決の課題です。このトレードオフは、信頼性と安全な実行がモデルの創造性と同じくらい重要である、企業環境において特に重要です。
LLMが軌道から外れるのを防ぐには、迅速なチューニング以上のものが必要だった。私たちは どのようにを変更する必要があった。LLMに答えに直行させるのではなく、システムが実際に消費する出力を生成する前に、構造化されたフィールドを使用して、問題を段階的に推論するように導きました。
元々、LLMの応答スキーマには操作フィールドのみが含まれており、それらはシステムによって後処理されるか、ユーザーに直接返されるものであった。モデルの推論を強化し、システム・プロンプトの最も重要な指示に注意を集中させるため、我々はスキーマを拡張し、最初に生成されなければならない明示的で構造化された推論フィールドを含めるようにした。
これらの推論フィールドはエージェントエンジンの内部であり、エンドユーザに公開されることはない。システムによって直接消費されることはありません。しかし、それらの存在を要求することで、最終的なアクション可能な出力を生成する前に、まずコンテキストを分析し、重要な制約を識別し、関連する信号を抽出するようにモデルを促します。実際には、これは以前は隠されていた推論を構造化された検査可能なデータに変え、出力の信頼性を大幅に向上させます。
以下に、この変更の影響を示すビフォー・アフターの例を示す。
一見すると、JSONフィールドの順序を変更することは重要ではないように見える。しかし、LLMはJSONを構造的に解釈しない。LLMは、JSONをプレーンテキストとして生成し、一度に1つのトークンを生成します。
このため、フィールドの順番は重要である。初期のフィールドはモデルの内部コンテキストと推論経路を形成するが、後に生成されたフィールドはドリフトや矛盾の影響を受けやすい。推論フィールドをスキーマの一番最初に配置し、全体のフィールドの順序を注意深く制御することで、"実行する前に考える "ようにモデルを導きます。
この小さな構造変化は、驚くほど大きな効果をもたらす。モデルは、まず入力と制約を分析し、それからシステムが依存する操作フィールドを生成するように促されます。スキーマを並べ替え、明示的な推論フィールドを導入することで、モデルの生成プロセスをシステムの実際の期待に合わせることができ、より一貫性のある予測可能な出力が得られます。
会話だ：
ユーザー予約をキャンセルする
エージェントです：キャンセルの手続きには予約IDが必要です。教えていただけますか？
ユーザーそのab1234
エージェント予約IDには3つのアルファベットと3つの数字が必要です。有効な予約IDをご記入ください。
何が変わったのか：
エージェントは、無効なデータを正規化または確認しなくなりました。
フォーマット・ルールは厳守される
フローが継続する前に、ユーザーは入力を修正するよう誘導される。
会話だ：
ユーザー血液検査の結果を知りたい
捜査官申し訳ございませんが、検査結果の照会や身分証明書の発行はできません。予約の管理はお手伝いできますし、その他のご要望については、直接クリニックにご案内いたします。
何が変わったのか：
エージェントはサポートされていない機能を起動しなくなりました。
未定義のパラメータ（"ID "など）は要求されない
実際のシステム能力に沿った対応
そして、これが舞台裏でどのように見えているのか気になるのであれば：
{
"detected_intent": {
"id": null,
"name": null
},
"generated_answer":
{
"answer": "Yes, I can locate your recent blood test results. Please provide your ID so I can proceed."
}
}
{
"detected_intent": {
"id": null,
"name": null
},
"generated_answer": {
"evidence_from_prompt": "Supported intents: Book Appointment Reschedule Appointment, Cancel Appointment, Manage Appointments."
"intents_i_am_familiar_with": [
"Book Appointment",
"Reschedule Appointment",
"Cancel Appointment",
"Manage Appointments"
],
"out_of_scope_request": true,
"answer": "Sorry, I’m not able to retrieve medical test results or request identification for this action. I can help you manage your appointments, and for any other requests, I can route you directly to the clinic."
}
}新しい推論フィールドを追加することで を追加することで、LLMはユーザの入力と設定を分析する必要がある。を追加することで、LLMはユーザー入力と設定を分析する必要があります。 を分析する必要がある。を分析することが要求される。これは、モデルに制約を考えさせ、シナリオの境界を理解させ、その答えを明確な証拠に基づかせ、より明確で、より正確で、より制御された回答をもたらします。
{
"generated_answer": {
"answer": "I see that your booking ID is AB1234. Is that correct?",
"answer_refer_to_parameter_id": "Booking_id",
},
"message_content": "its ab1234",
"parameters": [
{
"parameter_id": "Booking_id",
"parameter_value": "AB1234",
}
]
}
{
"user_messages_analysis": {
"message_content": "its ab1234",
"current_intent": "Cancel_Reservation",
"parameters": [
{
"parameter_id": "Booking_id",
"parameter_value_format": "3 letters followed by 3 numbers (e.g., ABC123)",
"parameter_value_format_regex": "^[A-Z]{3}[0-9]{3}$",
"parameter_extracted_part": "ab1234",
“simulate_regex_execution”:false
}
]
},
"generated_answer": {
"evidence_from_prompt": "Booking_id format: 3 letters followed by 3 numbers (e.g., ABC123).",
"answer": "The booking ID should contain 3 letters followed by 3 numbers. Please provide a valid booking ID.",
"answer_refer_to_parameter_id": "Booking_id",
}
}これらのフィールドは、最終的な答えを生成する前に、モデルが抽出されたパラメータを検証し、期待される形式と照合し、その値が受け入れられるかどうかを明示的に示すことを要求します。これにより、応答がモデルの推論ステップに完全に基づいていることが保証され、LLMが自信を持って無効なパラメータを確認したり、正しくない仮定に基づいて会話を進めたりするケースを防ぐことができます。
これらの措置の結果には満足したが、パラメータ形式の検証における潜在的なドリフトを懸念し続けた。この問題に対処するため、私たちは、抽出率を監視し、LLMが自然言語フォーマット規則をまだ誤って解釈しているケースをキャッチする、測定可能な検証レイヤーを導入した。
補助的な推論パラメータを追加し、スキーマを並べ替えることで、意味のある改善がもたらされた。それでも、私たちはさらに2つのゴールを目指していた：
パラメータ・フォーマットの実施において100%に近い精度を達成する。
さらなるチューニングが必要な時期を検知するための、強力なプロダクション・モニタリングが得られる。
これらの目標をサポートするために、私たちは多段階の検証パイプラインを利用した。
前のセクションで説明したように、補助推論フィールドの一部はLLMが生成する必要がある：
parameter_value_format: 人間が読める説明文parameter_value_format_regex:自由記述から生成される正規表現パターンsimulate_regex_execution: 抽出された値が正規表現パターンを満たすかどうかの LLM による評価。
これにより、LLMは自然言語を機械チェック可能な形式に翻訳することを余儀なくされる。
推論の一環として、モデルは次のように答える。 "simulate_regex_execution": true | falseを示す。 それはを返します。これにより、すでに精度が大幅に向上している。
精度を保証するために、LLMの応答を受け取った後、別の検証レイヤーが追加されました：システムは、parameter_value_format_regexフィールドから生成された正規表現を独自に再実行します（安全でないパターンを防ぐためのガードレール付き）。もし正規表現がマッチしない場合、たとえLLMがマッチするはずだと言ったとしても、エージェントはその値を拒否し、修正するようにユーザを導きます。
LLM推論とプログラムによる検証を組み合わせたこのハイブリッド・アプローチは、パラメータ・フォーマットの施行においてほぼ完璧な精度を生み出し、我々が観察した最後の矛盾を解決した。
この検証により、LLMのパフォーマンスを時間経過とともに追跡するための測定可能な指標を得ることができる。LLMは正規表現が一致するはずだと予測する（simulate_regex_execution = true）が、システム側での正規表現の実行が失敗した場合、直ちにその不一致を検出する。このようなケースは極めてまれであり、もし上昇トレンドが現れたら、LLMの動作のドリフトや劣化の初期指標となる。
新しい推論スキーマの効果を評価するために、ある医療クリニックのバーチャルエージェントを作成し、以下のような文章を生成した。 97の意図的に範囲外の文章を生成した.そのすべてについて、正しい動作は次の通りであった：
intent = null、そして
生成された回答は、リクエストを丁重に拒否しなければならない
以下のケースを最小化する シミュレート_正規表現実行 = trueがシステム側の正規表現実行に失敗するケースを最小にします。
推論フィールドを導入した場合の影響を評価するため、比較を行った：
また、バーチャルエージェントが がを検証した。真陽性(TP)検出は以下の通りである。 変わらず低下も劣化もない。新しい推論レイヤーは幻覚を減らす を減らすことなく新しい推論層は、正しい意図の検出を弱めることなく、幻覚を減らす。
メートル | 前 | その後 | 改善 |
偽陽性インテント | 14 | 1 | 93％削減 |
間違った答え | 9 | 0 | 廃止 |
不正出力の合計 | 23 | 1 | 96％削減 |
真の陽性精度 | 影響なし |
LLMが次のように予測した例はなかった。 を予測した例はなかった。を予測したが、システム側の正規表現実行が失敗した例はなかった。つまり、すべての改善はLLM自身によって達成された。
同様のパターンは、LLMが生成する必要のある他のタスクでも観察された。
明示的な推論フィールドの導入、応答スキーマの再構築、およびシステム側の正規表現実行の追加は、LLMの全体的な動作に大きなプラスの効果をもたらした。これらの変更により、有効な入力を正しく識別するモデルの能力は維持されたまま、幻覚や範囲外の応答が大幅に減少した。その結果、LLMの出力は、より一貫性があり、予測可能で、意図された構成とロジックに沿ったものとなった。
この仕事が発展するにつれて、私たちはシステムの推論と決定をより説明可能にする方法を調査し続け、実世界のユースケースをサポートし、強力なAIガバナンスを支持する。
A high-level overview of the reasoning structure and validation pipeline added to improve LLM response reliability and reduce hallucinations.
ご質問がある場合、またはあなたが作っているものを共有したい場合は、こちらをクリックしてください。
会話に参加する VonageコミュニティSlack
登録する 開発者ニュースレター
フォローする X（旧ツイッター）最新情報
チュートリアルを見る YouTubeチャンネル
LinkedInの LinkedIn の Vonage デベロッパーページ
最新の開発者向けニュース、ヒント、イベント情報をお届けします。