自由奔放なLLMをどう制御するか　“自由度”と“制御性”のバランスを取る、前処理・後処理の技術

山崎氏の自己紹介

山崎天氏：LINEのNLPチームに所属している山崎と申します。「どこまでLLMに任せる？　LLMの自由度と制御性のバランスを取るための技術紹介」というタイトルで発表します。よろしくお願いします。

最初に自己紹介をすると、私はLINEのNLP Foundation Devチームというところでシニアエンジニアをしています。

経歴ですが、東京大学の相澤研究室という自然言語処理の研究室で修士号を取得しました。この発表にもけっこう関連があるのですが、ニューラル言語モデルの制御性に関する修士論文を執筆して卒業しています。

そして、2021年からNLPチームに所属していて、対話システムユニットというチームのディレクターを担当しています。ほかにも、LLMの応用開発やLLMの基礎開発を担当しています。

LINEでの言語モデルに関する取り組み

本題に入る前に、LINEでの言語モデルに関する取り組みを少し紹介します。2021年に「HyperCLOVA 39B」というものを構築しました。

当時最大級の日本語言語モデルの訓練に成功していて、私が入社した時にはすでに構築が完了していたのですが、「修士で実装したようなモデルとぜんぜん比にならないぐらい性能がいいな」と、とても驚いた記憶があります。

その後、HyperCLOVA 39Bを用いて対話システムライブコンペティション4という大会に実際に出場して、優勝できました。LLMが対話性能がとても高いことを示せた結果なのかなと思っています。

2022年には「HyperCLOVA 82B」と、より大きいモデルを構築できました。こちらは39Bよりもより高いコンテキスト理解能力や生成品質を獲得していることを確認しました。

その82Bを用い、対話ロボットコンペというコンペティションや、対話システムライブコンペティションの次のバージョンにも出場して最優秀賞を獲得しました。音声対話やロボット対話のコンペティションだったのですが、そちらでもLLMは活用できるということを実証した大会になったのかなと思っています。

2023年には、実務でLLMを活用する方法の提案として、「HyperCLOVA Writer」を発表しました。社内にて公開して、社内で活用している状況です。

つい先日、HyperCLOVAとは別のチームが開発した3.6ビリオン（36億）パラメーターのLLMを一般公開しました。こちらは「Hugging Face」で商業利用可能な状態で公開しているので、ぜひみなさんに利用してもらえたらなと思っています。

“制御性が高いシステム”と“自由度が高いシステム”

というわけで今日の本題に入っていこうと思いますが、生成AI自体には、制御性と自由度が高いシステムという2つの性質があると思っています。

（スライドを示して）制御性が高いシステムがどういうものを指しているかというと、左側の例のようにルールやテンプレートに従って決まったことを返すようなシステムです。ここでは“制御性が高いシステム”と呼びます。

一方で、自由度が高いシステムは、ユーザーの自由な入力に対してニュアンスを汲み取ってくれたり、自由な応答を返してくれたりするシステムです。ここでは“自由度が高いシステム”と呼びます。こういったシステムは、昨今のChatGPTを使ったり、プロンプティングをしたりして実装できます。

（スライドを示して）それぞれのシステムには、やはりメリット・デメリットがあります。例えば制御性の高いシステムは、ユーザーエクスペリエンスが悪いものが多いと思っています。

というのも、スマートスピーカーはけっこう決まったことにしか反応できなくて、変なことを言うと「知りません」みたいなことを言ってしまいます。そういった点でUXが悪いです。一方で、自由度が高いシステムは、うまく返答ができたらUXがとても高いものになると考えています。

やはり生成AIの特徴として、創造性のあるタスクが解けるのも大きなメリットの1つだし、一方で制御性の高いシステムは、創造性のあるタスクはとても難しいです。

ただ、制御性の高いシステムにもけっこうメリットはあって、開発やデバッグが容易だったり、説明性が高かったり、タスク達成が保証できるというメリットがあります。自由度が高いシステムは、タスクが本当に達成されるのかを保証することが難しいシステムになっています。

このメリット・デメリットは明らかに反しているもので、トレードオフの関係にあると考えています。なので、実際に業務で使うには、要件に応じてこれらのバランスを調整して、必要なメリットを享受して必要じゃないメリットを捨てつつ、デメリットをできるだけ減らすことが実務では大事なのかなと考えています。

本当にLLMに制御は必要なのか？

（スライドを示して）LLMを活用したアプリケーションを開発している方ならこの課題感はもう共有できていると思うのですが、これから開発する方からの『LLMの制御って本当に必要？』という質問に答えます。

（スライドを示して）例えば、左側のようにカスタマーサポートを実装するようなプロンプトをChatGPTに入力して、カスタマーサポートをやらせてみます。

最初のほうはけっこううまくいっているのですが、「君はAIなの？」みたいなことを聞いちゃうと、「はい、私はOpenAIが開発したAI言語モデルです」みたいなことを言ってしまい、話が逸れてタスクを実際に達成できないケースもあります。

一方で右側のように、最近のインストラクションモデルはそんなに出てこないですが、暴言や非倫理的なこともけっこう発言してしまうケースも可能性としてはある状態になっています。なので、LLMの制御はとても大事なことだと考えています。

制御の鍵となる「タスクの細分化」

今日の発表で伝えたいこととして、自由奔放なLLMをどう制御するかというものの考え方と、具体的な技術をいくつか紹介できればと思っています。

制御の鍵となるのは、タスクの細分化だと思っています。タスクの細分化が鍵だと思っているのは実はLINEの僕だけではなくて、OpenAIもそのようなことを考えていると最近講演で聞きました。

というのも、先々週（2023年9月26日現在）ぐらいの「SIGDIAL」という対話系の学会でOpenAIのRyan Lowe氏が講演していたのですが、この方によると、今までは1つのAPIコールでタスクを解いてしまうようなChatGPTを、エンドツーエンドで活用してタスクを解くような一気通貫な方法があって、ChatGPTのWeb UIは、実際にこの仕組みでチャットが提供されています。

一方で、最近トレンディングな方法としては、ChatGPTを一つひとつのモジュールとして活用して、実際に中身で分業を行います。そうすることによってタスクが1個1個がシンプルになって、精度やシステム全体の制御性が向上します。「そういったことがトレンディングになっているよ」と発言していました。実際に、「LangChain」という最近のライブラリでは、こういった機能を提供しています。

（スライドを示して）これもRyan氏のスライドです。和訳した文章を読むと、「複雑なタスクにおいてLLMで一度推論するだけでは信頼できる結果を得ることは難しい」と言っていました。しかし、「シンプルなタスクならLLMは十分信頼できるような精度を達成することができる」とも言っていました。

なので今後の彼の予測としては、「対話を含むあらゆる言語アプリケーションにおいては、LLMはパーツとして使用されていくだろう」と発言されていました。ということで、モジュールとして使用するものが今後の主流になってくるのかなと思っています。

LLMを挟んだ「前処理」と「後処理」

では「LINEのNLPチームではどう細分化したのか？」という質問ですが、実際に私のチームでは、前処理と後処理に分けて細分化して、LLMを制御してきました。

LINEは言語モデルを2021年ぐらいから持っていて、長い間いろいろ試行錯誤した結果、「前処理と後処理に分けて考えることはすごく容易だよね」と考えています。

（スライドを示して）図にするとこんな感じで、LLMを挟んで前処理と後処理があります。まず、前処理はどういう処理をするかというと、プロンプトを作成する部分ですね。期待する出力を得るための積極的な制御と考えていて。特徴としては、文脈となる情報をどんどんプロンプトに入れ込むことができます。

一方で、こういうものはLLMによって期待どおり処理されない可能性がすごくあるので、「できればこんな出力をしてほしい」ぐらいの実装を入れ込むことが重要かなと考えています。

具体的にできることとしては、プロンプトプログラミングをしたり、あとはパラメーターを調整したりですね。あとはデータベースを利用する、RAG（Retrieval-Augmented Generation）という手法で、データベースを利用してプロンプトに入れ込むことで、LLMにそういったデータベース、ドキュメントを活用して生成させる技術があります。

あとは、ほかのNLP技術やLLMによる部分タスクを解決してプロンプトとして渡すといったことが前処理ではできます。

そして、メインとなる出力を中心のLLMで生成して、次の後処理に回します。後処理とはなにかというと、出力されてしまったものをなんとかするような消極的な制御だと考えています。特徴としては、出力に直結するような処理の部分なので、確実に適用されてほしいようなルールを実装したり。あと課題としては、生成失敗時にどう処理をするのかがすごく難しい部分かなと考えています。

というのも、例えばフィルタリングとかを実装していくと、NGワードとか引っかかっちゃった時に「どういうふうに処理するんだろう？」ということをけっこう考えなきゃいけないのが、この後の処理の部分だったりします。あとは、NLP技術やLLMを使って文章を追記したり編集したりもできます。

失敗したら再生成にまわしてもう1回生成するような方法も方法論としてはありますが、そうするとコストがどんどんかさんでいくので、それが正解かどうかは各要件によっていくのかなと思います。

前処理と後処理を施した対話システムのデモ

（画面を示して）実際に前処理と後処理を施した対話システムのデモを見てもらえたらと思います。

（デモ開始）

システム（※画面上の音声）：もしもしー、こんにちは。四葉です！　お元気ですか？

山崎：はい、元気ですよ。

システム：今日は天気が良くて気持ち良いですね。どこかに出かけたくなります。

山崎：そうですね。私は仕事なので出かけられないですけど。

システム：あらら、残念ですね。でも、週末は休みじゃないんですか？

山崎：年末は休みです。四つ葉さん、週末何するんですか？

システム：特に予定はないですね。家でゆっくり過ごすつもりです。

（デモ終了）

山崎：こんな感じで、わりと自然な対話ができているかなと思います。暴言とかはできるだけ吐かせないようにしています。

具体的にどういったシステムなのかというと、例えば、知識応答生成という前処理の部分。これはユーザーがけっこうニッチなトピックについて話したい時はRAGですね。先ほど説明した、データベースからドキュメントを拾ってくるような仕組みを利用して、知識としてプロンプトに挿入してあげることで、よりLLMがリッチなトピックで話すことができます。

あとはペルソナ応答生成ですね。ユーザーやシステムのプロフィールについて話したい時は、LLMを使ってプロフィールを抽出して利用する仕組みを用意していたりします。後処理の部分はいろいろなフィルターをかませていて、例えば非倫理的な応答を検知するフィルターなど、いろいろフィルターを実装しています。

前処理と後処理それぞれで達成できること

「前処理では、具体的にどのようなことが達成できるの？」というのを軽く紹介すると、先ほど説明したようなドキュメントデータベースなどを参考にした文章生成ができます。

あとは、パラメーターを調整して出力のランダム性を変えていくのも、手としてすごく有効かなと思っていて。Temperatureだったり、presence_penalty、frequency_penaltyといった値を調整することも効果としてあるかなと思っています。

後処理ではなにができるかというと、文章を読みやすくするということですね。LLMを使用して文章を平易化したり、翻訳したり、説明文を追記したりと、読みやすくする処理だったり、あとは差別的表現やわいせつ表現などの有害な発言を防ぐことも可能かなと考えています。実際、弊社で論文を書いていて、弊社でも自前でフィルターを開発中です。