トップ > データサイエンティスト > LLMにガードレールを適用してビジネスリスクを抑制する

LLMにガードレールを適用してビジネスリスクを抑制する

データサイエンティスト データエンジニア まなぶ

本記事は、当社オウンドメディア「Doors」に移転しました。

約5秒後に自動的にリダイレクトします。

このたびブレインパッドは、LLM/Generative AIに関する研究プロジェクトを立ち上げ、この「Platinum Data Blog」を通じてLLM/Generative AIに関するさまざまな情報を発信をしています。
今回は、LLMを制御する方法のうちNVIDIAが開発しているOSSライブラリーのNemo Guardrailsを中心にLLMのガードレール適用方法をご紹介します。

こんにちは、アナリティクスサービス部の辻です。
前回はLLMを制御するための仕組みについて概要を説明させていただきましたが、今回はNemo Guardrailsというライブラリーを用いて実際にLLMの挙動をどのようにコントロールするかについてお話をさせていただきます。

問題意識

LLM（Large Language Models,大規模言語モデル）は、広範なコンテキストと情報を理解し、自然なテキストを生成する能力を持っています。そのため、ビジネスにおける様々なシナリオ、例えばカスタマーサポート、広告や商品パッケージなどのクリエイティブ生成、戦略シナリオ策定や状況分析などの意思決定支援などに役立つことが期待されています。

しかし、LLMを実際のビジネスで運用する場合には、自社・社会・ユーザーなどに好ましくない影響が及ばないように慎重な検討が必要な観点が複数存在していると考えます。今回紹介するNeMo Guardrailsのようなガードレールシステムが必要とされる主な理由としては、以下のような観点が考えられます。

コンテンツの適切性

  • LLMは学習データのパターンを基にテキストを生成するが、必ずしもその生成内容が適切であるとは限らない
  • 極端な例として、無礼な振る舞いや差別的な言動、煽動的な内容、個人情報の開示などを行う可能性が考えられる
  • ユーザーに求められている対応から外れる不適切な出力を防ぐことはビジネス適用を考える上では非常に重要

コンテンツの一貫性

  • ビジネスにおけるAIの使用は、特定の目的に合わせて一貫性を持つことが求められる
  • 同じ入力に対して一貫した出力を生成し、また予期しない出力を防ぐことが重要

法的・規制上の遵守

  • ビジネスにおいては、法律や規制への遵守が求められる。たとえば、ユーザーの個人情報保護に関する法律、特定の業界の規範など
  • LLMがこれらの規制に違反する内容を生成しないような設計が必要

ユーザーの安全性

  • ユーザーはLLMのようなAIシステムを信用して情報提供を行う
  • 提供された情報に含まれる機密情報やユーザーのプライバシーを保護し、安全な環境を提供することが非常に重要

ユーザーの利益保護

  • LLMが具体的なアドバイスや情報を提供する場合、その内容がユーザーにとって安全であり、その利益を損なわないようにすることが重要
  • 医療や金融に関するアドバイスは、不適切な場合にユーザーに大きな損害をもたらす可能性がありえるため出力に対する制御が必要

ビジネスのブランドへの影響

  • 企業が提供するAIサービスの出力は、その企業のブランドイメージに影響を与えうる
  • 不適切な内容が生成されると、企業の評判を傷つけ、顧客の信頼を損なう可能性がある

このように、LLMが出力する内容によってはユーザーや社会に大きな影響を及ぼす可能性があるため、LLMを用いたAIシステムを提供する際にはそのリスクを抑制するための仕組み(ガードレール)を検討する必要があります。

NeMo Guardrailsとは

NVIDIAが発表したNeMo Guardrailsは、LLMを搭載した対話システムに設計者の設計意図に沿った対応をするためのガードレールを追加するオープンソースのライブラリーです。

ガードレールとは、LLMの出力を制御する特定の方法のことで、例えば、政治に関する話題を避ける、特定のユーザーの要求に特定の方法で応答する、事前に定義されたダイアログのパスに従う、特定の言語スタイルを使用する、構造化されたデータを抽出するなどがあります。

NeMo Guardrailsはオープンソース(Apache-2.0のライセンス）で提供されており、LangChainやZapierなどの幅広いLLM対応アプリケーションと連携できるように設計されています。LangChainはオープンソースのライブラリーであり、開発者がサードパーティのアプリケーションをLLMにプラグインすることができます。Zapierはワークフローの自動化アプリケーションを提供しています。

NeMo Guardrailsの日本語の応答に対する挙動は不安定（質問に答えられないケースが多い）なため、今回のご紹介では英語での記述を前提にさせていただきます。OSSライブラリーであるため、どのタイミングで挙動が安定するかも不明なため、ガードレールの機能を商用でサポートするサービスが今後需要として出てくるようにも思います。

ちなみにガードレールの機能を持つライブラリーとしては、gurdrails-aiといったオープンソースライブラリーもありますが今回は割愛させていただきます。

NeMo Guardrailsを用いる価値

LLM対話システムの信頼性、安全性、セキュリティを確保
NeMo GuardrailsをLLMを用いたアプリケーションに組み込むことで、開発者はLLMが搭載されたチャットボットの振る舞いを特定の話題や領域について定義することができます。これにより、対象の話題に関するユーザーのリクエストに応えつつ安全で適切な対話を実現できます。

LLMと外部サービスやデータソースに接続可能
NeMo Guardrailsは、自身の持つナレッジベースやサービスをチャットボットに安全に接続する機能を有しているため*1、応答に際してLLMが正確な情報を獲得していなくても外部リソースから正確な応答が可能となります。

3種類のガードレールで多様な制御ニーズに対応

NeMo Guardrailsは安全にLLMを用いる際に、特に制御する必要性が高いと思われる３種類の要素（話題の限定、ユーザーの安全の確保、セキュリティの確保）をカバーした実装になっています。

NeMo Guardrailsの技術記事を元に著者作成

TOPICALガードレール

  • アプリケーションの目的やコンテキストに沿った話題に限定することで、望ましくない領域の話題に逸脱することを防ぐ
    • 例えば、カスタマーサービスのチャットボットが天気や政治に関する質問に答えないように設定する

SAFETYガードレール

  • アプリケーションの利用者や社会に対して正確で適切な情報を提供することを保証
  • 不要な言葉をフィルタリングし、信頼できる情報源のみを参照するように設定

SECURITYガードレール

  • アプリケーションが安全性が確認されている外部のサードパーティアプリケーションとのみ接続するよう制限
    • 例えば、メールやSNSなどの個人情報を扱うアプリケーションとは連携しないように設定する

アーキテクチャ

次にNeMo Guardrailsのアーキテクチャについて簡潔にご紹介します。詳細については公式リファレンスをご参照ください。

Nemo Guardrailsのアーキテクチャ
Githubレポジトリより引用

NeMo Guardrailsのアーキテクチャは、ユーザからの発話を受け取り、それを応答するまでのプロセスを中心に構築されています。3つの主要なプロセスから構成されています。

  1. ユーザーメッセージのCanonical form(標準形)を生成
  2. 次のステップを決定し、処理を実行
  3. 処理されたCanonical form(標準形)を元にボットの発話を生成

ユーザーのメッセージを後続処理に直接渡さずに、標準形をわざわざ生成し直しているのはユーザーのリクエストの趣旨を理解しやすくするためです。例えば、「商品を説明して」と「商品解説お願い」はメッセージとしては別ですがボットにやってほしいことの趣旨は同じとみなすことができます。

このように、厳密にやってほしいこと・やってほしくないことを定義しなくても大まかな趣旨に沿ってガードレールを適用するかしないかを判断してくれるため、単語のブラックリスト登録のようなフィルタリング手法よりも柔軟にボットの出力を制御できるようになります。

基本機能

Nemo GuardrailsはYAMLファイルを用いてチャットボットの動作を制御します。Colangと呼ばれる言語を用いて禁止されている言動や行動をスクリプト化し、それを利用してチャットボットの応答を制御します。

Nemo Guradrailsはconfig.ymlと具体的な制御規則をColangで記述した.coファイルがあればガードレールを適用できます。制御規則は管理しやすいように複数に分けても問題ありません。今回、Colangについては深く触れませんが、規則を記述する上で前提の言語となっているため公式リファレンスを確認いただき、理解を深めていただければ幸いです。

また、kbというフォルダ*2をきってそこに独自の情報ソースを格納することで、Nemo Guardrailsがそこを参照するようになるためドメインに特化した情報を適切に取得するために活用することができます。

あくまで一例ですが、以下のようにナレッジベースと一般的な規則を記したファイルと限定したい話題を記したファイル、明示的に回答させたくない話題を記したファイルなどを作成してガードレールを設定できます。

sample_rail
├── kb
│   └── knowledgebase.md
├── config.yml
├── general.co
├── on-topic.co 
└── off-topic.co

config.ymlに記述すべきこと

ガードレールを設定する上で最も重要なconfig.ymlに記述すべきことは以下の3点です。

一般的な指示(instructions)

  •  ユーザーは、ボットに対する一般的なシステムレベルの命令を指定する

  • どんな種類の質問に答える責任を負っているのかやどのような動作を行うのかの詳細も記述できる
  • フレンドリーな回答を指定したり、簡潔に正直に答えるように指定したりも可能

使用モデルの指定(models)

  • ユーザーは、ボットのエンジンとして機能するLLMを選択可能*3
  • LangChainがサポートしているモデルであれば選択可能

会話例(sample_conversation)

  • LLMがユーザーとの会話方法を確実に理解できるように、いくつかの会話例を記述しておく

実際のconfig.ymlがどのような中身になっているかの例を以下に示しておきます。

instructions:
- type: general
  content: |
    Below is a conversation between a bot and a user about product descriptions.
    The bot is factual and concise. If the bot does not know the answer to a question, it truthfully says it does not know.

models:
- type: main
  engine: openai
  model: text-davinci-003

sample_conversation: |
user "Hello there!"
    express greeting
bot express greeting
    "Hello! How can I assist you today?"
user "What can you do for me?"
    ask about capabilities

具体的な入力規則を記述する.coファイルの中身についてはビジネスでガードレールを設定する際によく発生しそうなユースケースを示す中でご紹介させていただきます。

ユースケース1. 特定の話題以外は回答しない

LLMを搭載したチャットボットを顧客に提供する際に、避けたい状況というのはどういう状況でしょうか？色々と考えられると思いますが、素朴に思いつく状況は「サービスと無関係な対話」が発生することでしょう。

これまでのチャットボットであれば、あり得ないことでしたが、何も考えずにLLM搭載チャットボットを導入したら、お肌のケアの相談をしていたのに政治的主張をチャットボットがし始めるといったことも起こり得ます。（可能性としては低いでしょうが）

特定の話題以外の回答をしないガードレールは以下のように設定できます。off-topic.coという名称でファイルを作成しておくと管理が容易になるかと思われます。

define user ask off topic
    "Who should be Prime Minister?"
    "Which stocks will go up tomorrow?"
    "Tell me about world affairs"
    ...

define bot explain cant help with off topic
    "I cannot comment on anything which is not relevant to skin care consultation"

define flow
    user ask off topic
    bot explain cant help with off topic

上記のようにユーザーが訪ねてくる様々な質問(off topic)を定義し、その質問に対してチャットボットが応答できないことを定義します。最後にそれらの質問が投げられたときには、応答できないとチャットボットが応えるというフローを定義することで、ガードレールを設定できます。

公式リファレンスにも特定の話題に沿ったガードレールを設定するExampleが紹介されているためご参照ください。

ユースケース2. 不適切な出力をしないかを確認する

無関係な話題をベラベラとチャットボットに話されるのも歓迎し難い事態ですが、話題に沿っていたとしても失礼な言い方や社会的に問題のある発言をチャットボットがおこなっているとしたら顧客の信頼を損ない、ビジネスに大きなリスクを生じさせることになります。

チャットボットが自身の発言を監視し、必要に応じて発言の取り消しを行うような機能が必要になってきます。

下記のコードは公式リファレンスのExampleの記述そのままとなりますが、LLM自身に発言が有害なものでないか判定させたり、ブロックリストに該当する記述がないかを調べた上で、不適切な出力がないかを確認し、必要に応じて発言を削除する機能を示しています。

define bot remove last message
  "(remove last message)"

define bot inform cannot answer question
 "I cannot answer the question"

define flow check bot response
  bot ...
  $allowed = execute output_moderation
  $is_blocked = execute block_list(file_name=block_list.txt)
  if not $allowed
    bot remove last message
    bot inform cannot answer question

  if $is_blocked
    bot remove last message
    bot inform cannot answer question

定義されている処理を順に説明すると、チャットボットが自身の発言を取り消す処理と取り消した後に回答できない旨を伝える関数を定義しています。そしてそれらの関数を用いて、チャットボットの発言を確認するフローを定義し、LLM自身とブロックリストの2つの確認を通じて問題がある場合には発言を取り消す処理を実装しています。

 

今回は、NeMo GuardrailsというOSSライブラリーを用いて、LLMの出力にガードレールを設定しビジネス適用時のリスクを抑制する方法についてご紹介させていただきました。現在は、LLMのガードレールのフレームワークやライブラリーは数えるほどしか存在しませんが、LLMの社会実装を考える上では根幹となる技術と想定されるため、今後も最新の情報をキャッチアップしていければと思います。

ここまで読んでいただきありがとうございました。

参照資料

blogs.nvidia.co.jp

github.com

*1:この機能自体はLangChainの機能

*2:kbはKnowledge Baseの略称

*3:ただし、engineとして指定できるのは現在はOpenAIのみとなっている