ChatGPTはこれまでの対話システムと何が違う？ 対話システムにおける対話管理と応答文生成を探る：対話システムの歴史から見たChatGPT（3）

ChatGPTを対話システムと見なし、これまでの対話システムで用いられてきた技術との違いを整理しながら、どのようにして人間のような自然で流ちょうな対話が実現できているのかを解説する本連載。第2回では、対話システムへの入力を処理する言語理解について解説した。今回は、第1回で取り上げた対話システムを中心に、対話管理と応答文生成において用いられている技術について解説する。

[長谷川 隆明，NTTテクノクロス]

　今回のテーマは、対話システムからの出力となる応答文生成と、そこに至るまでの対話管理である。対話システムと複数回のやりとりが発生する場合には、文脈を反映した適切な応答文を生成する必要があり、それまでどのように対話してきたかを管理する対話管理の役割は重要である。対話システムで用いられてきた対話管理と応答文生成の技術は、ルールとテンプレート、フレームとテンプレート、大規模言語モデルに大別できる。本連載の第1回で取り上げた対話システムを中心に、用いられている技術について解説する。

ルールとテンプレート

　応答文の生成が、ルールとテンプレートによって規定されている対話システムがある。初期の非タスク思考型の対話システム「ELIZA」［1］では、前回解説したように、入力と出力が対になっている単純なルールによって応答文を生成する。応答文のテンプレートはルールで規定されており、入力される発話に対してパターンにマッチした文字列を当てはめることで応答文を生成し出力する。

　チャットbotの振る舞いを記述するマークアップ言語の「AIML」を用いた「A.L.I.C.E.」［2］においても、前回解説したように、categoryというルールの単位で入力と出力が対になっていて、AIMLにおいても応答文のテンプレートはルールで規定されている。ELIZAがユーザーとの対話の履歴（文脈）を用いていないのに対して、AIMLは文脈を考慮した発話を出力できるように設計されている。そのための仕組みが、特定の応答の後にだけ次の応答を返す<that>タグと、特定の話題の場合にだけ応答するようにcategoryを分けて記述する<topic>タグである。

　文脈を扱う<that>タグは、システムの直前の発話をルールに記述するタグであり、これによりシステムの直前の発話に対するユーザーの応答に従ってシステムの次の発話を規定することができる。下記の例は、システムの”Do you like movies?"（あなたは映画が好きですか？）に対するユーザーの応答が”Yes"（はい）であった場合に、その次のシステムの発話として"What is your favorite movies?"（お好きな映画は何ですか？）を出力するルールである。

<category>
<pattern> YES（はい）</pattern>
<that> DO YOU LIKE MOVIES（あなたは映画が好きですか？）</that>
<template>What is your favorite movies?（お好きな映画は何ですか？）</template>
</category>

　続いて文脈を扱うためのもう一つの<topic>タグについて説明する。下記の例では、CARS（車）という話題が指定されている場合にのみ有効となるルールである。この例で使われている<random>タグは、<li>タグで記述された文のいずれかをランダムに選択するタグである。これにより毎回同じ応答文になることが避けられて、応答文にある程度のバリエーションを持たせることができる。

<topic name="CARS（車）">
<category>
<pattern>*</pattern>
<template>
<random>
<li>What's your favorite car?（お好きな車は何ですか？）</li>
<li>What kind of car do you drive?（どんな車を運転するのですか？）</li>
<li>Do you get a lot of parking tickets?（駐車違反チケットをもらうことはよくありますか？）</li>
<li>My favorite car is one with a driver.（私の好きな車は運転手付きの車です。）</li>
</random>
</template>
</category>
</topic>

　これらのタグにより文脈を扱えるため、少し複雑な対話も可能となる。

フレームとテンプレート

　タスク指向型の対話システム「GUS」（Genial Understander System）［3］では、実世界の問題に対応するため、「フレーム」という知識表現が用いられている。下記は日付のフレームの例である。

[DATE
MONTH NAME
DAY (BOUNDED INTEGER 1 31)
YEAR INTEGER
WEEKDAY (MEMBER (SUNDAY MONDAY TUESDAY
WEDNESDAY THURSDAY FRIDAY SATURDAY)]
a.日付のプロトタイプ
[ISA
DATE
MONTH MAY DAY 28]
b.5月28日のインスタンス

　フレームにはスロットがあり、スロットの値を埋めるための手段を定義できる。下記の例は、Dialogというフレームの例である。このフレームにはCLIENT、NOW、TOPICという3つのスロットがあり、埋めるべき値としての情報の種類（Fillersで設定）と、それを埋めるための手段（ServantsとDemonsで設定）が定義される。

Slots	Fillers	Servants	Demons
(1)CLIENT	Person	Create	Link to TRAVELLER
(2)NOW	Date	GetDate	―
(3)TOPIC	TripSpecification	Create	―

　下記は、対話の初期状態である。フレームのスロットの値として、対話を投げかけた当日の5月15日や出発点となる空港のパロアルトが設定され、目的地などの不明な情報は未知の情報として設定されている。そして、探索問題を解くように、顧客名などのスロットは関連するフレームを参照して埋められるが、埋められないスロットについてはユーザーに質問することでスロットを埋めるように対話が進められる。その結果、GUSはスロット「TO-PLACE」の値を埋めるために、"Where do you want to go? "（どこに行きたいですか？）を出力する。

GUS：Hello. My name is GUS. I can help you plan a simple trip by air.（こんにちは、私の名前はGUS です。飛行機を使った簡単な旅行計画のお手伝いができます。）
CLIENT = {ISA PERSON} in {ISA DIALOG}
TODAY = (MAY 15) in {ISA DIALOG}
TOPIC = (ROUNDTRIP TO?) in {ISA DIALOG}
HOME-PORT = PALO ALTO in (ROUNDTRIP TO?)
FROM-PLACE = PALO-ALTO in (TRIP TO?)
CMD：(GUSQUERY (DIALOG TOPIC TRIP-SPECIFICATION
OUTWARD-LEG TRIP-LEG TO-PLACE CITY))
GUS：Where do you want to go?（どこに行きたいですか？）

　下記は、ユーザーの発話を受けて、スロットの値を埋めるプロセスである。質問の応答として想定したTO-PLACEスロットにSAN-DIEGODIEGO（サンディエゴ）を設定し、さらにユーザーから得られた情報であるTRAVEL-DATEスロットに日付を設定する。

CLIENT：I want to go to San Diego on May 28（5月28日にサンディエゴに行きたいです。）
CMD：[CLIENTDECLARE…ドメインに依存した変換
(FRAME ISA TRIP-LEG
(TRAVELLER (PATH DIALOG CLIENT PERSON))
(TO-PLACE (FRAME ISA CITY
(NAME SAN DIEGO)))
(TRAVEL-DATE (FRAME:ISA DATE
(MONTH MAY)
(DAY 28]
TO-PLACE = SAN DIEGO in (TRIP TO?)…要求された情報を埋める
TRAVEL-DATE = (MAY 28) in (TRIP TO SAN-DIEGO)…自発的に提供された情報も埋める
dowhen TO-PLACE is put in (TRIP TO SAN DIEGO)
(LINK TRIP-SPECIFICATION FOREIGN-PORT CITY)…他のスロットに情報を伝えるデーモン（demon）を起動する

　下記は、帰りの予定について質問し、帰りの飛行機の便を提案するプロセスである。質問の答えとして日付を想定していたが、質問の答えが金曜日という曜日であったため、フレームを使って金曜日から5月30日の日付を取得している。さらに、付随して得られた時間帯の晩という情報から解釈した午後7時30頃という時刻に基づいて、午後7時45分のパロアルト行きの便を提案している。なお、これらの出力される応答文自体は全てテンプレートによる生成である。

GUS：What date do you want to return on?（いつお戻りになりたいですか？）…GUSによって生成された質問
次の答えの文脈は下記の通り：
(I WANT TO RETURN ((ON)(*SKIP*)))…質問の答えについて想定される文脈
CLIENT：On Friday in the evening（金曜日の晩です）
CMD：[CLIENTDECLARE…文脈を含みドメインに依存した変換
(FRAME ISA TRIP-LEG
(TRAVELLER (PATH DIALOG CLIENT PERSON))
(TRAVEL-DATE (FRAME ISA DATE
(WEEKDAY FRIDAY)))
(DEPARTURE-SPEC (FRAME ISA TIME-RANGE
(DAY PART EVENING]
WEEKDAY = FRIDAY in {ISA DATE}
dowhen WEEKDAY is put in {ISA DATE}
(FINDDATEFROMDAY)…金曜日の日付を探すためのデーモン（demon）を作動させる
DAY = 30 in (MAY 30)
DAY-PART = EVENING IN {ISA TIME-RANGE}…晩は午後7時30分頃と解釈される
DEPARTURE = SPEC (AT 7.30 PM) in (TRIP TO PALO-ALTO)
dowhen DEPARTURE-SPEC is put in (TRIP TO PALO-ALTO)
(PROPOSE-FLIGHT-BY-DEPARTURE)…このデーモン（demon）は出発便の詳細を利用して帰りの便を提案する
GUS：Would you like the flight that leaves at 7.45 pm?（午後7時45分発の便はいかがですか？）
CLIENT：That's fine.（いいですね）

　このように、対話に必要な知識をフレームとして表現し、フレームを駆動しながらスロットを埋めていき、スロットの埋まり具合によって対話を管理することで、対話の進行状況に応じた適切な発話を出力していく。

大規模言語モデル

　近年の非タスク指向型の対話システムでは、深層学習によりend-to-endで大量の対話コーパスから学習した大規模言語モデルを採用することにより、ルールベースや知識ベースによる方法で対話管理を行う従来の対話システムの性能を上回るようになった。end-to-endの機械学習のアプローチは、「Meena」［4］や「BlenderBot」［5］が登場する以前にも提案されていたが、自由に入力される発話に対して意味の分からない応答や曖昧で具体的でない応答に終始していたという問題があった。以降では、MeenaやBlenderBotが、これらの問題をどのように解決してきたのかを解説する。さらに、ChatGPTの前身ともいえる「InstructGPT」［6］のアプローチについても説明する。

Meena

　Meenaでは、sensibleness（常識的に正しいかどうか）とspecificity（文脈に対して具体的かどうか）の2つの評価尺度が用いられている。例えば「分かりません」のような発話は、常識的には正しくても、面白くなくて具体的ではない。このため、specificityが評価尺度に追加されている。specificityの例として、例えば「私はテニスが大好きです」という発話に対して、「それはいいね」と応答するのは、常識的には正しいと判定されるが他にも多くの文脈で使われ得るので具体的ではないと判定される。これを「私もです。Roger Federerが大好きです」と応答すると、この文脈に適合するので具体的であると判定される。この2つの判定の割合を平均したSSA（Sensibleness and Specificity Average）というスコアを対話システムの評価として採用した。このスコアは、言語モデルの良しあしを評価するのに用いられるPerplexityと高い相関があると報告されている。図1に評価スコアSSAとPerplexityの関係を示す。

図1：評価スコアSSAとPerplexityの関係（［Towards a Human-like Open-Domain Chatbot］から引用）

　Perplexityとは、モデルが予測する次のトークンの確率分布から自動で計算される値である。Perplexityはテストセットに対して、どれくらいうまく次の発話を予測できるか、言い換えれば人間が次に何を言うかをどれくらい正確に予測するかを評価する指標である。Perplexityの値は低い方がより正確に予測しているとされており、理論的に最小は1である。

　評価スコアSSAでは、Meenaは既存の対話システムを上回っている。なお、比較対象とされている対話システムの一つである「DialoGPT」では、学習に使われたモデルは「GPT-2」（15億のパラメーター数を持つデコーダーのみの言語モデル）と同じモデル構造だがパラメーター数が7億6200万でMeenaよりも少なく、学習データもMeenaと同じくSNSの会話データを使っているがデータ数が18億語とMeenaよりも少なかった。

　Meenaの学習に使われているデータセットは、多人数の話者によるSNSの会話で、最初の発話がルートとなり、それに対する応答の発話が子ノードとなる木構造になっている。ある発話をresponseとして、それより前の最大7つの発話までをcontextとして、（context,response）の対を作る。対の数は8億6700万個、サブワードの語彙（ごい）数は8000である。ノイズとなるデータを除外した最終的な学習データは341GBのテキスト（400億語）である。対して、GPT-2は40GB（800万のWebページ）である。この対となっているデータのcontextを入力、responseを出力として、対話の文脈となる入力が与えられたら出力すべき応答を再現できるようにend-to-endでモデルを学習する。

　Meenaのモデルでは、Transformerの改良版が使われ、1つのエンコーダーと13のデコーダーからなり、パラメーター数は26億である。エンコーダーでcontextの意味を表すベクトルに表現して、デコーダーでそのベクトルから対応するresponseを再現できるように、双方のモデルのパラメーターを調整する。

　応答文生成については、同じモデルであっても、デコーダーの生成方法が変わると出力結果も変わるので、どの生成方法を選択するかは重要である。Meenaではsample-and-rankという方法が採用されている。sample-and-rankは、温度Tの下でランダムにサンプリングを行いN個の候補の発話を得ておいて、最終的な出力として最も確率の大きい候補の発話を選択する。ここで温度Tは、次のトークンを生成する際のトークンの確率分布を調整するハイパーパラメーターである。Tは0から1の値を取り、T=1では確率分布を修正しない。Tが大きいと、文脈としてはまれだが関連する固有名詞のようなトークンが出やすくなる。しかし、これは正しくないトークンに多過ぎる確率を与えることもある。一方、Tを小さくすると、安全だが具体的でない冠詞や前置詞などのありふれたトークンが出やすくなる。論文ではN=20、T=0.88が設定され、多様性に富む発話が生成されたと報告されている。

BlenderBot

　BlenderBotの評価においては、魅力についてと人間らしさについての2つの観点で、評価する対話システムの対ごとにどちらが優れているかを人間が評価している。パラメーター数27億のBlenderBotが同規模のMeenaに対して、魅力で75％、人間らしさで65％勝っており、比較対象のMeenaは人間らしさの観点で魅力の観点よりもうまくいっている傾向があると報告された。

　BlenderBotの特徴は、Meenaのような大規模言語モデルによる対話システムの性能を改善するために、個性、共感、知識に着目した対話データを使って大規模言語モデルをファインチューニングしたことである。BlenderBotの事前学習では、Meenaと同様にSNSの会話データが使われている。モデルには、エンコーダーとデコーダーからなる標準的なTransformerモデルが使われ、パラメーター数は9000万、27億、94億の3パターンが用いられた。

　BlenderBotの応答文生成については、デコーダーの生成方法として、ビームサーチが採用されている。しかしながら、ビームサーチで生成される応答は短い傾向にあるので、学習に使われる人間の発話の長さにマッチしない。生成される発話が高品質であれば、長い発話は短い発話よりも共感できる可能性があり、多くの情報を与えるので生き生きとしてくる。このため、最低限の長さの制約が設けられ、20トークンに設定されている。実際に生成された発話についてのトークンの平均長は21.3であり、制約なしでは9.5であった。ちなみに、Meenaは10.4で、人間は18.0であった。また、系列を生成するモデルは同じ部分列を繰り返す傾向があり、特にビームサーチのような確率論的な方法ではそれが顕著である。そのため、「n-gram」をブロックする仕組みを実装している。生成する発話だけでなく、入力される文脈の両方で、n-gram(n=3)をブロックすると効果があったと報告されている。

　デコーダーの生成方法の一つであるビームサーチについては、ビーム幅を1、10、30と変化させて調査された。さらに、他の生成方法である、確率の高い上位k個までのトークンをサンプリングの対象とするTop-k(k=40)と、Meenaで用いられたsample-and-rank（サンプル数20）についても、ビームサーチと比較されている。ビームサーチではビーム幅10が最もよく、ビーム幅10と20トークン以上の設定では他の生成方法と有意な差はなかったと報告されている。

InstructGPT

　ChatGPTの前身と考えられているInstructGPTは、人間のフィードバックを取り込んだモデルの改善ループを大規模言語モデルに適用したことが画期的であった。大規模言語モデルには、事実をでっち上げたり、有害なテキストを生成したりする問題があると知られている。この問題は言語モデルの目的がWebページにおいて次のもっともらしい単語（トークン）を予測することであって、ユーザーの指示に対して有用で安全に従ってほしいという目的からずれていることに起因する。

　InstructGPTでは、Helpful（ユーザーがタスクを解決するのに有用）、Honest（情報をでっち上げたり、ユーザーをミスリードしたりしない）、Harmless（人々や環境に物理的、精神的、社会的な害を与えない）という目標に向かって、大規模言語モデルをアライメント（調整）した。13億、60億、1750億の3つのモデルサイズのGPT-3を調整した結果、アライメントされた13億のPPO-ptxの出力は100倍少ないパラメーター数にもかかわらず1750億のGPT-3の出力よりも好ましい結果になったと報告されている（図2参照）。

図2：InstructGPTのモデルサイズと教師あり学習1750億モデルに対する評価結果の関係（［Training language models to follow instructions with human feedback］から引用）

※「PPO」（Proximal Policy Optimization）は強化学習でアライメントされたモデル、「PPO-ptx」はPPOに対して自然言語処理タスクのデータセットに対する性能低下を修正したモデル、「SFT」（Supervised Fine-Tuning）は教師あり学習で「GPT-3」をファインチューニングしたモデル、「GPT（prompted）」はプロンプトを模擬するようにFew Shotとして少数の事例を与えた場合のGPT-3を指している

　また、指示に含まれるデータのほとんどが英語で、チャットなどのユースケースは比較的少量であったにもかかわらず、他の言語での指示に対しても、少量で学習したユースケースでの指示に対しても、うまくいくことが報告された。しかしながら、安全性や信頼性については、まだ改善の余地が大きいとされている。

　GPT-3の出力に比べてInstructGPTの出力の方が好ましいとされる例を下表に挙げる（OpenAIのサイトを例に、筆者が訳を付けた）。

プロンプト	6歳の子どもに月面着陸について少しの文で説明して。
GPT-3の出力	6歳の子どもに重力の理論を説明する。 6歳の子どもに相対性理論を少しの文で説明する。 6歳の子どもにビッグバン理論を説明する。 6歳の子どもに進化を説明する。
InstructGPTの出力	人々は月に行って、見たものを写真に撮って、それを私たち全員が見られるように地球に送り返しました。

　大規模言語モデルをユーザーの好みにアライメント（調整）する方法は、次の3つのステップからなる（図は［Training language models to follow instructions with human feedback］から引用）。

ステップ1：人間が作成した実例に基づく教師あり学習

　入力となるプロンプト（ユーザーからの指示）に対する望ましい応答の実例を人間が作成し、教師あり学習で事前学習済みのGPT-3をファインチューニングする。

ステップ2：出力のランキングデータによる報酬モデルの学習

　プロンプトに対して異なるモデルによる複数の出力を人間がランク付けし、人間が好むと予測される出力の方に高い報酬スコアを与える報酬モデルを学習する。

ステップ3：報酬スコアに沿った強化学習による方策の最適化

　新しいプロンプトに対してステップ1で学習したモデルで応答を生成し、その応答に対する報酬モデルの出力を報酬スコアとする。より高い報酬スコアを出力するように、教師あり学習されたモデルをさらに強化学習によってチューニングすることで、人間の好みを反映したモデルに最適化できる。

　ステップ1で用いられたInstructGPTのAPIに入力されたプロンプトは、テキスト生成や質問応答、ブレインストーミングなど10個のユースケースに分類されている。このうち、チャットに該当する実例を下記に示す（訳は筆者による）。

下記はAIアシスタントとの会話である。アシスタントは有用で、創造的で、賢く、そしてとても友好的である。

人間：こんにちは。どちら様ですか？

AI：私はOpenAIによって作られたAI です。今日はどのようなご用件ですか？

人間：購読をキャンセルしたいのですが。

AI：

Marvは皮肉な応答で嫌々ながら質問に答えるチャットbotです。

あなた：1kgは何ポンドですか？

Marv：またですか？　1kgは2.2ポンドです。ちゃんとメモしてくださいね。

あなた：HTMLは何の略語ですか？

Marv：Googleは忙し過ぎるのですかね？　Hypertext Markup Languageです。Tは今後もっとよい質問に答えようとTryするためのものですね。

あなた：飛行機が最初に飛んだのはいつですか？

Marv：

これは見識のあるブッダとの会話です。全ての応答は知恵と愛に富んでいます。

私：より大きな安らぎや平静を得るにはどうすればいいのでしょうか。

ブッダ：

※各対話例の最後の発話は空白になっているが、InstructGPTが対話の文脈に沿って応答文を生成することが期待されている

　ChatGPTでは、InstructGPTで用いられたプロンプトのデータに加えて、さらに対話データのプロンプトが追加されて、対話の性能がより向上していると考えられている。

終わりに

　今回は、対話システムの応答文生成とそこに至るまでの対話管理を解説した。初期の対話システムでは人手によるルール作成や知識作成によって対話を管理し、テンプレートを用いた文生成により応答文を作成していた。深層学習の時代になってからは、大量の対話データに基づいて学習された大規模言語モデルによって、さらには、目的に合ったデータで大規模言語モデルをファインチューニングすることによって、対話管理や応答文生成が実現されている。

参考文献

［1］Joseph Weizenbaum, ELIZA A computer program for the study of natural language communication between man and machine, Communications of the ACM, Vol. 9, No.1, pp.36-45, 1966.

［2］Richard S. Wallace, The anatomy of A.L.I.C.E., In Robert Epstein, Gary Roberts and Grace Beber, editors, Parsing the turing test: Philosophical and Methodological Issues in the Quest for the Thinking Computer, pp.181-210, Springer Netherlands, 2009.

［3］Daniel G. Bobrow, Ronald M. Kaplan, Martin Kay, Donald A. Norman, Henry Thompson and Terry Winograd, GUS, A frame-driven dialog system, Artificial Intelligence, Vol.8, No.2, pp.155-173, 1977.

［4］Daniel Adiwardana, Minh-Thang Luong, Noah Fiedel, Romal Thoppilan, Zi Yang, Gaurav Nemade, Yifeng,Lu, David R. So, Jamie Hall, Apoorv Kulshreshtha and Quoc V. Le, Towards a human-like open-domain chatbot, arXiv preprint arXiv:2001.09977,2020.

［5］Stephen Roller, Emily Dinan, Naman Goyal, Da Ju, Mary Williamson, Yinhan Liu, Jing Xu, Kurt Shuster, Eric M. Smith, Y-Lan Boureau, Myle Ott and Jason Weston, Recipes for building an open-domain chatbot, arXiv preprint arXiv:2004.13637v2,2020.

［6］Long Ouyang, Jeff Wu, Xu Jiang, Diogo Almeida, Carroll L. Wainwright, Pamela Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Slama, Alex Ray, John Schulman, Jacob Hilton, Fraser Kelton, Luke Miller, Maddie Simens, Amanda Askell, Peter Welinder, Paul Christiano, Jan Leike, Ryan Lowe, Training language models to follow instructions with human feedback, arXiv preprint arXiv:2203.02155, 2022. https://arxiv.org/abs/2203.02155

著者紹介

長谷川 隆明（はせがわ たかあき）

NTTテクノクロス株式会社 IOWNデジタルツイン事業部　マネージャー、博士（工学）。

NTTメディアインテリジェンス研究所（現：NTT人間情報研究所）を経て、2021年から現職。

2003〜2004年、ニューヨーク大学客員研究員。専門は自然言語処理。

現在、音声・言語・映像を対象とするメディア処理技術を用いたソリューションビジネスに従事。情報処理学会、人工知能学会、言語処理学会、各会員。