発話を「喜び」「怒り」「悲しみ」と分類できても、なぜその感情になったかまで分かるとは限りません。原因は本人の発話内にあることも、相手が何ターンも前に話した出来事にあることもあります。感情語そのものを、原因と取り違える場合もあります。

RECCON（Recognizing Emotion Cause in CONversations）は、感情ラベルが付いた英語の二者会話に対し、原因を表す発話と、その中の具体的な文字列を対応付けたデータセットです。「どの発話が原因か」を選ぶ課題と、「原因を十分に表す部分はどこか」を抜き出す課題の両方を扱えます。

RECCONの原因は、発話者本人へ「なぜそう感じたか」と尋ねた回答ではありません。既存会話と既存の感情ラベルを読み、評価者が出来事・状況・意見・経験のうち何が感情を引き起こしたかを推定したものです。文章上の因果関係を学ぶ資源であり、人の内面を客観的に確定した記録ではありません。

新しく会話を収録せず、二つの既存データを選び直した

RECCONは、DailyDialog由来のRECCON-DDと、IEMOCAP由来のRECCON-IEから成ります。ただし、両者は同じ条件で集めた会話ではありません。

DailyDialogは、英語学習者が日常会話を練習する複数のウェブサイトから集めた、人間が書いた会話文です。重複を削除し、3人以上の会話を除き、綴りを自動修正して作られています。実際の会話を録音・書き起こしたものではありません。元データは83％が中立だったため、RECCONでは非中立の発話を4件以上含む対話を無作為に選びました。

IEMOCAPは、俳優10人を2人ずつ5組にし、台本付き場面と即興場面を収録した音声・映像データです。怒り、興奮、苛立ち、喜び、中立、悲しみの感情ラベルがあります。RECCONでは、重複を避けるため16種類の会話状況から各1対話だけを人手で選びました。

最終規模はDailyDialog側1,106対話・11,104発話、IEMOCAP側16対話・665発話、合計1,122対話・11,769発話です。そのうち6,355発話へ感情原因を付け、原因を持つ対象発話と原因文字列の組は11,069件になりました。

評価者には「感情表現」ではなく「原因」を探させた

対象は、すでに感情ラベルが与えられた発話です。評価者は会話全体を読み、その感情を十分に説明する原因文字列をすべて抜き出しました。原因は出来事、状況、行為、意見、経験などです。一つの感情に複数の原因があれば、複数の発話・文字列を選べます。

たとえば「わあ、信じられない！」は感情が表れている証拠ですが、その表現自体が原因とは限りません。直前の「賞を取った」という出来事が原因です。研究チームは、感情が表現されている箇所と、その感情を生み出した原因を区別するよう評価者へ指示しました。

当初は対象発話より後のターンも探索対象にしましたが、未来の発話に明示的原因が見つかったのは全体で7件だけでした。オンラインの会話AIは未来を参照できないため、これらの原因スパンを除外し、最終課題では会話冒頭から対象発話自身までを探索範囲にしています。

学生を研修し、試行データで合格してから本番を任せた

アノテーターはコンピュータ科学を学ぶ学部生・大学院生です。英語母語話者ではありませんが、日常的に英語で意思疎通し、授業も英語で受けていました。研究チームは感情原因認識の特別ワークショップを開き、試行データへの注釈を確認して個別にフィードバックしました。十分な成績に達した人だけが本番作業を担当しています。

各対象発話は、課題知識を持つ大学院生2人が独立に評価しました。論文には、参加人数の総数、年齢、報酬、1件あたりの作業時間、試行データの合格基準は記載されていません。したがって、誰でも参加できる一般的なクラウドソーシングではなく、訓練済み評価者による専門寄りの作業と捉えるのが適切です。

原因発話と原因文字列を二段階で統合した

品質管理は二段階です。まず発話単位で、2人のうちどちらが選んだ発話を原因として採用するか決め、不一致時は3人目の専門評価者が判定しました。次に同じ原因発話内で文字列の範囲を統合しました。

2人が選んだ文字列の重なりが、短い方の文字列の50％以上なら両者の和集合を最終スパンとしました。50％未満なら3人目が既存候補から選び、同じ内容を表せる場合は短い範囲を優先しました。この50％という閾値は、少数の対話を調べて経験的に決めたものです。3人目でも決着しなかった34件は除外されました。

一致度は、原因発話の有無についてκ＝0.7928、評価者ペアの平均macro F1＝0.8839でした。原因のない候補を除くとmacro F1は0.8201、文字列範囲の一致はF1＝0.8035です。発話単位よりスパン単位の一致が低く、「原因は同じでも、どこまで囲むか」が難しいことが分かります。

原因を五つの型に整理した

• No Context：原因が対象発話自身に書かれている。
• Inter-Personal：相手が述べた出来事や相手の感情が、対象話者へ影響する。
• Self-Contagion：以前の自分の発話で生じた気分や原因が持続する。
• Hybrid：相手からの影響と自分の感情の持続が組み合わさる。
• Latent：会話中に明示的な原因文字列がなく、文脈から原因を推測する。

全体ではNo Contextが43％、Inter-Personalが31％、Self-Contagionが10％、Hybridが11％、Latentが5％です。対象発話の中だけで完結する原因も多い一方、同じ発話と過去発話の両方に原因がある例は3,613件あります。原因数は平均1.73件で、対象発話の46％には複数原因が付いています。

長い会話ほど遠い原因を探す必要がある

DailyDialog側は1対話平均約8発話ですが、IEMOCAPは50発話を超えます。原因が対象発話から3ターン以上離れている割合はDailyDialog側で約13％、IEMOCAP側では約40.5％でした。直前の発話だけを見ればよいデータではなく、会話長によって課題の難しさが大きく変わります。

一方、DailyDialogは非中立発話が4件以上ある対話だけを選んでいるため、元データの通常分布を保っていません。IEMOCAPも16状況から1対話ずつに限られ、RECCON-IEは16対話しかありません。二つの部分データは、会話の由来、長さ、感情体系が異なり、単純に一つの均質なコーパスとして扱えません。

「原因ではない例」は人工的な作り方で変わる

モデル学習用には、正しい原因だけでなく負例も作られました。同じ会話履歴にある原因ではない発話をすべて組み合わせる方法、別の対話から無作為に発話を取る方法、別対話から対象感情と同じ感情を持つ発話を取る方法の3種類です。どの負例を使うかによって、課題が「無関係な文章を除く」ものになるか、「もっともらしいが原因ではない文章を見分ける」ものになるかが変わります。

公式リポジトリでは、元注釈JSONと二つの下流課題用データを分けて公開しています。JSONには発話順、話者、本文、感情、原因発話番号、原因スパン、任意の説明、原因タイプが入ります。利用時はRECCONだけでなく、派生元であるDailyDialogとIEMOCAPの利用条件も確認する必要があります。

因果関係ではなく、会話から説明可能な原因候補である

RECCONは因果推論の実験で原因を操作したデータではありません。評価者が会話文から説明可能と判断した原因候補です。会話に書かれていない生活歴、性格、身体状態、表情や声の情報は原則として扱えず、潜在原因には評価者の常識や文化的解釈が入ります。既存の感情ラベルが誤っていれば、原因注釈もその前提に引きずられます。

日本語で作る場合は、本人申告の理由、会話中に明示された原因、第三者が推測した潜在原因を別フィールドにし、判断根拠と確信度も残す設計が有効です。株式会社イングクラウドでは、会話収集、感情評価、原因発話・原因スパンの複数人アノテーション、不一致の第三者判定まで、工程を分けて設計できます。