NLP2024 2日目
聴講した発表をいくつかピックアップ
適宜加筆修正します
市況コメント生成
トレンドを文章で説明するとどうなる？
Data-toTextタスク
グラフを読みとってテキストで説明する
一行の日本語を生成する
やりたいかも 
既存手法
fine tuning
few-shot learning
少数事例選択 few-shot selection
これを検証する
入力: 数値時系列データ
少数ショット学習で使うプロンプト
<commment> タグで挟んで出力させる 評価時にテキストを判別しやすくなって嬉しい
わかる僕も最近これやってる
出力文の比較
傾向把握に成功
値動きを正しく表現できている
宿泊施設からのレビューへの自動返信
低評価レビューへの自動返信
レビューと返信
複数の不満のすべてにしっかり答える
定型的なものではなく
入力: レビュー以外の情報を使わない。汎用性を高める。
問題の定義の仕方がうまい
レビューを文に分割し、苦情か否かの判定
属性語の抽出
重複文の削除
一文ずつ出力するので編集距離が近い文がつくられることがある
最初に出てきた文を除去する（属性語が含まれない場合）
NLPと教育工学
記述式問題
傍線部の内容について数十字程度を答案にする問題
文章構造理解の支援
答案に応じたフィードバック生成
誤りに応じたコメント
生徒: 模範解答との差異が感じられずになぜ減点されたかわからない
良いフィードバックは一意に定まらない
ユーザーによりけり
現状: 自動採点はできるようになってきているが、フィードバックはまだだめ
定型テンプレートだけでは対応しきれない
採点項目特有の
Sentence BERT
課題
参照箇所の精度向上
参照箇所の自動評価
フィードバックの形態（教育観点）
クイズを解く
思考力、想像職の向上
記憶力、判断力の維持
認知機能の維持からエンタメまで
少量では問題ないが、大量は高コスト
質問応答タスクでも難点がある
学習時に利用可能な日本語データの少なさ
JSQuAD 64,000件
JQKET 24,000件
意外だった。もう少しでかいデータセットがあると思っていた
多様なクイズ
入力形式の変更
学習時の損失関数を工夫
類似しすぎるとつまらない、著作権侵害に抵触
質問生成モデル
MixQG
文書から、異なる解答を持つ複数の質問を生成
Fusion-in-Decoder
T5ベースの質問応答モデル
複数の文章を考慮しながら解答を生成できる
提案: 昨年の成果をベース
入力における問題と解答の役割を逆転させる
解答を生成しないことで問題生成のしばりがなくなる、結果、多様性が生まれる
教師データを完全に模倣しようとしてしまう
多様性がなくなる
類似しすぎている場合は学習を弱める
実験
入力形式を３パターン
文書＋解答→問題
適切性の向上を確認
文書→問題
多様性が向上を確認
文書→問題＋解答
実験
BERTScoreによる損失制御の効果を検証
実験
新規Wikipedia記事で問題生成
面白さを考えるには文章の選択も重要
Q: 多様性向上を追求したときの文章の乱れへの影響は？
そもそもクイズ文は短いのでそこまで影響は見られなかった
日本語を英語に翻訳してから英語モデルで解く
類語を取り扱うための多言語共通のsynsetID
一つの単語に複数のIDが意味の数だけ割り当てられている
同じIDを持っていればそれらの語は適切に翻訳可能
データを眺めてみたい
数式のグラウンディング
文書ローカルで変数に関する辞書を作る
変数はx, yのように短い文字
同一文書内で違う意味で使われていることもある
既存研究でカバーできなかった
文書内の変数の曖昧性はずっと課題として残っていた
意外だった
データを作ればできる問題
数式識別子に限定
x, y, sin, 関数名
問題の定義の仕方がうまい
NLPとして
入力: 構造化文書データ XHTML
多層パーセプトロンモデル
ベースライン以上人間未満
Q: 形式言語においても同じようなことが起きる？ ソースコードにおける変数でも同じ問題を抱える？
コードは記号の生存範囲のスコープが明確である
数学や論文（自然言語）で使われる場合はこれが曖昧なので難しいということ
文章内位置データと接辞タイプが重要要素
文脈はあまり関係ない
→ 分野に依存しないという結論
料理レシピの類似度比較
レシピのためのSTSデータセットをつくりたい
Semantic text similarity
メニューのタイトルのEmbeddingを比較する
fastTextベクトル
fine tuningしたモデル
OpenAIのtext-embedding-3-smallと同等の精度
課題: レシピの構造を考慮した表現手法
材料と手順とか
レシピ、ソースコードとして考えたらなにか面白いことできないかな？
手順を擬似的に関数として実行してみたり
見出しの意味を予め確定させることで英語への翻訳の精度を高めたい
一文字の国名: 仏-フランス、米 コメ
見出しの意味具体化
2015年の先行研究で言及されているタスク
LLM-jp few-shot learning
触ってみよう
Japanese Explainable Multi Hop Question-Answering
1,179組の質問と答え、答えを導出するためのトリプルの形の知識が含まれる
マルチホップQA
質問と答え
答えを導出するためのtriplesの出力
主語エンティティ（記事タイトル）と目的語エンティティ（InfoboxやAbstractにあるハイパーリンク部分）の関係をアノテーションするタスク
導出を介して質問に答える
Chain-of-Thought (CoT) の一種
関連発表が P9-12 でも行われるとのこと
人間が分かりやすい表現でロボットを道案内したい
経緯度、方位、通り名、などを用いずに、建物や景色を目印にして表現できるか
人間に地図片を見せて実際に書いてもらって評価する
わかりやすさの評価
評価者の主観が含まれてしまうので結構難しそうだ
分かりやすい例に見られる特徴
スタート地点は必ずしも含まれていなくてもいい
ゴール地点は明確にすべき
文字数が長くないほうがいい
Helpfeelの質問文の作り方でも参考にできるところがある？
実験データはGitHubで公開されている
ぜひ試してみてほしいとのこと
https://github.com/masayu-a/HRI-JP-RIRE-DB (CC BY-NC-SA)
FAQタスクを例に、RAGとLoRA tuning、およびその組み合わせの性能差を検証
→ RAG + LoRAの組み合わせがMRRが最も良かった
RAGで与えられた情報を事前学習で知識として獲得していたことの強みではないか
推論時の外部知識注入
LoRA
関連ドキュメントの学習
full fine-tuningしなくて済むやつ
Ameba FAQ データセット
AmebaブログヘルプページのFAQ
train 1300件ほど、valid 630件ほど、test 680件ほど
これくらいお手頃なサイズでもいい感じに実験できるのだな
Ragas
RAGの性能を評価するためのフレームワーク
生成された解答がどれほど適切であるかをGPT-3.5-turboで評価
実行するたびに結果に揺らぎがあって評価が難しいらしい
BERTScore
MRRスコア（相対評価）
Mean Reciprocal Rank
スポンサーブースの様子
株式会社Helpfeelはプラチナスポンサーとして協賛しています
3つのプロダクトと自然言語処理の関わりをまとめたポスターとパネルを展示しています
居場所がわかるホワイトボード
デザイナーの
さんがアイコンマグネットを作ってくれました
Scrapboxのアイコン記法みたいでかわいい
旅日記
駅からホテルまでの道を覚えた
お菓子
昼食
学会キッチンカー飯
てりやきハンバーグ丼