まとめ

• ローカルLLMを使って日本語要約してみた
• 作成した要約をGPTと人手（自分）評価で評価してみた
• Generation Configの重要性（せめてHuggingface-hubに記載の値を使うべき）

概要と背景

振り返ってみると2023年はLLM関連が非常にホットなトピックだったような印象があります。
LLMにプロンプトを投げるといい感じの出力を出してくれるので、私自身困ったらGPT、みたいなそこそこ頼れるアシスタントとしてよく使っています。

LLMができることの一つとして文書要約があると思います。
GPT-3.5やGPT-4は「次の文書を要約してください。{文書}」みたいな入力をいれるだけでいい感じに要約してくれてすごいなと小学生並みの感想にはなりますが思っています。

2023年は日本国内企業もLLMの開発を盛んに行い、様々なモデルが発表されました。
気になってくるのはその性能ですよね。
Stability AI版のlm-evaluation-harness、Rakuda benchmark、llm-jp-evalなど、様々な評価ツール、データセットなどが公開され、数値として様々な評価結果が報告されています。
すごく参考になる一方で、やっぱり自分のほうでもどんな出力が得られるのか確認したいなと思いまして、今回日本語要約で精度検証をしてみました。

ローカルLLMを使って日本語要約を実施

検証モデルとその設定

今回は以下のモデルに関して検証を行っています（並び順は適当です）。

• Xwin-LM/Xwin-LM-7B-V0.2
• Xwin-LM/Xwin-LM-13B-V0.2
• meta-llama/Llama-2-7b-chat-hf
• meta-llama/Llama-2-13b-chat-hf
• mistralai/Mistral-7B-Instruct-v0.1
• elyza/ELYZA-japanese-Llama-2-7b-fast-instruct
• stabilityai/japanese-stablelm-instruct-gamma-7b
• stabilityai/japanese-stablelm-instruct-beta-7b
• stabilityai/japanese-stablelm-instruct-ja_vocab-beta-7b
• llm-jp/llm-jp-13b-instruct-full-jaster-dolly-oasst-v1.0
• matsuo-lab/weblab-10b-instruction-sft
• rinna/youri-7b-instruction
• cyberagent/calm2-7b-chat

検証対象のモデルは、

• Instruction Tuning済みのモデル
• A100一枚の環境で検証するため、fp16、bf16で動作するモデル

という観点で適当に集めました。
ちなみに検証環境はGoogle Colabです。
使用したnotebookは[こちら]()。

また、検証時のプロンプト（チャットテンプレート）は各モデルについてHuggingface-hubに記載されているものを使用しています。
（モデルごとに全然違うのちょっと大変でした......Huggingfaceの tokenizer.apply_chat_templateがもっと出回ってほしい......）

また、Generation Configですが、なんと今回はすべてデフォルト値を使用しています！
理由としては単純に個々のモデルについて調べて設定するのを嫌がった、という完全にこちらがさぼっただけになります......
（一応の思想としては、優れたモデルはパラメータ適当でもなんとかなるだろうし、すべてのモデルでパラメータチューニングさぼれば公平な比較だろう、ぐらいの感覚ではありました。）

結論を述べると、一部のモデルでそもそも要約がうまくできない結果となり、原因の一端としてこのGeneration Configが考えられるかもしれません。

検証データと評価方法

今回は検証データとして既存の日本語要約データを使っていません。
理由として、データリークの恐れがあったことが大きいです。

じゃあどうやって要約の精度評価をするかですが、今回は簡単に11件の文書をLLMに要約してもらい、その要約結果をGPTで自動評価します。
具体的にはGPT-4に要約対象の文書と要約結果を与えて、「consistency」「relevance」「fluency」「coherence」の４項目を1-5の5段階評価してもらう、というものになっています。
Human-like Summarization Evaluation with ChatGPT. [link]によると、データセットにもよりますが、GPT-3.5での評価は人手評価とそこそこ相関するとのことです。
今回使用した評価用プロンプトはこちらです。

evaluation_prompt = "ニュース記事に対する日本語要約文書の品質を評価してください。"\
                    "次の4つの評価項目に関して評価してください: relevance faithfulness fluency coherence"\
                    "relevance は要約がどれだけ記事の要点を捉えているかを表しています。記事の重要な内容のみが要約に含まれているかどうか確認してください。"\
                    "faithfulness は要約中の事実が記事中の事実と一致しているかを表しています。要約がすべての事実を正確に再現しているか、事実と異なる情報を述べていないか確認してください。"\
                    "fluency は個々の文がよく書けているか、文法的に正しいかどうかを表しています。"\
                    "coherence は全ての文がまとまっていて、自然に思えるかどうかを表しています。全体としての要約の品質を確認してください。"\
                    "各項目の評価は1（最悪）から5（最高）までの5段階評価をしてください。\n"\
                    "ニュース記事: {}\n"\
                    "要約文書: {}

一応こちらの論文は英語要約に関する話なので、今回は日本語要約についても同様の傾向がみられるか検証するため、人手評価も簡単に実施し、相関を計ってみたいと思います。
（作業者は自分だけなので、あくまで参考値的にはなります。）

また、前述の通りデータリークを考慮して、今回使用する11件の文書は2023年に投稿されたニュース記事を使用しています。
（11件の選択方法は完全に自分の好みで選んでます。）

作成した要約を評価

あくまで今回は各LLMを要約に使った際にどのぐらいの精度になったのかを述べるだけなので、LLMの動かし方などは割愛し、さっそく評価結果を載せたいと思います。

GPTで自動評価してみた

GPT-4での評価結果は次の通りです。

それぞれの項目を見てみると、relevanceでは、Xwinから順に大半のモデルが4以上となっています。
つまり、大半のLLMはそれなりに入力文書と関連した内容を要約にできている、ということのようです。

consistency（faithfulness）についてですが、こちらもrelevanceと同様に大半のモデルが4になっています。いわゆる忠実性についても大半のLLMは満たしていそうです。

生成した要約のfluencyについてですが、こちらはなんと複数のLLMで11件すべて5を獲得しています。
ほかのモデルに関しても大半が4.5以上となっており、出力された日本語の流暢性も問題なさそうです。

最後に出力された要約のcoherenceですが、こちらも大半のモデルが4以上となっています。

以上の結果をまとめてみると、GPT-4によると、2023年のニュース記事要約11件においては、大半のモデルは「relevance」「consistency」「fluency」「coherence」のどれも非常に高いレベルで達成できる、ということがわかります。

一方で、いくつかのモデル、特に「llm-jp-13b-instruct-full-jaster-dolly-oasst-v1.0」は軒並み低い結果となっていますが、これは何が起きているのでしょうか。
それを確かめるためにも、前述の通りGPT-4ではなく人手でも同様に4項目について5段階評価を実施しました。

人手で評価してみた

人手評価の結果が次の通りです。

いったんそれぞれの項目を見ていきます。

relevanceについてですが、Elyzaモデルが唯一4を超えていて、大半のモデルは3点台となりました。
5段階評価の3点台なので、すごくいいわけではないが、そこそこ良い、が大半のようです。

consistency（faithfulness）については大半のモデルが4を超える結果となりました。
要約結果の忠実性は人手評価でも十分良さそうです。

fluencyについてなのですが、半分程度が4以上となり、GPT-4の結果と比べて少し低めとなりました。
面白い点としては、日本語の語彙を明確に含むようにしていないモデルのほうが低めの傾向になっていそうです。（ただしXwin-LM-13B-V0.2は不明）

coherenceについても同様に半数程度が4以上となりました。

以上から、GPT-4の評価と比べると人手評価の結果は全体的に低めとなりました。
特にrelevanceは顕著に低い結果です。
現状、人手評価といっても自分ひとりで評価したため、あくまで自分が低めに評価しすぎ、という可能性もあります。
このあたりの乖離について、より精巧な人手評価を行い明らかにしてみたいところです。

ちなみにllm-jpモデルについてなのですが、人手評価でも一貫して低い結果となっています。
これは何が起きているかというと、llm-jpモデルは要約を生成できていませんでした。
下記に実際のLLMの出力例を載せておきます。
11件すべてについて以下のような出力を行っていたため、自分はすべての項目で1を付けた次第です。

/*
* Copyright (c) 2018 THL A29 Limited, a Tencent company. All Rights Reserved.
*
* Licensed under the Apache License, Version 2.0 (the \"License\");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied.  See the License for the
* specific language governing permissions and limitations
* under the License.
*/

namespace TencentCloud.Vod.V20180717.Models
{
    using Newtonsoft.Json;
    using System.Collections.Generic;
    using TencentCloud.Common;

    public class DescribeVideoDetailResponse : AbstractModel
    {        
        /// 

        /// 视频详情列表
        /// 
        [JsonProperty(\"VideoDetailList\")]
        public VideoDetail[] VideoDetailList{ get; set; }

        /// 

        /// 唯一请求 ID，每次请求都会返回。定位问题时需要提供该次请求的 RequestId。
        /// 
        [JsonProperty(\"RequestId\")]
        public string RequestId{ get; set; }

        /// 

        /// For internal usage only. DO NOT USE IT.
        /// 
        internal override void ToMap(Dictionary map, string prefix)
        {
            this.SetParamArrayObj(map, prefix + \"VideoDetailList.\", this.VideoDetailList);
            this.SetParamSimple(map, prefix + \"RequestId\", this.RequestId);
        }
    }
}

ぱっと思いつく原因としては、「Generation Configが不適切」や「そもそも長文対応していない」などが挙げられます。
せめてGeneration ConfigをHuggingface-hubの値にしておけば前者は多少軽減できたのですが.......
次に似たことをやるかどうかはわかりませんが、この辺りは注意しておいたほうが良さそうです。

GPT評価と人手評価の相関を算出

GPT-4と人手評価の結果が出たので、それらの相関を見てみます。

スピアマンの相関係数は次の通りです。

相関係数の解釈は人によりけり、タスクによりけりだと思いますが、個人的には今回の要約評価タスクだともう少し欲しいなという印象です。
特にrelevanceとcoherenceはちょっと物足りない感が......

今回GPT-4に投げるプロンプトは、先行研究のHuman-like Summarization Evaluation with ChatGPT.で使用されたものを日本語化したものなので、もう少し工夫の余地はありそうです。
確かにGPT-4を使えばreference summary無しで要約評価ができそうなのは魅力ですが、現状だとざっくりスコアを出したいときに使うようなもの、という印象です。

各LLMの要約圧縮率

今回は適当に要約を生成するようにLLMにプロンプトを入れているのですが、割とモデルごとに出力される要約長が異なることを確認したので共有します。

上記の表は圧縮率に関するものです。
averageが入力記事と出力要約の単語数比をsampeleで算術平均したもの、medianが中央値、stdが標準偏差です。
averageの太字は0.5以下のものを指しています（0.5は適当ですが、要約には文書を半分くらいにはして欲しいかなと思いその値に設定しました）。

ちなみにjapanese-stablelm-instruct-gamma-7bは平均して圧縮率が2.62倍となっていて、入力記事と比べて要約が長くなっていることがわかります。
何が起きていたかというと、n-gramのrepetationがいくつかのsampleで発生していて、それを残していた、ということになっています（stdの通り、repetationが発生しない場合もあります）。

まとめ

いくつかのLLMを使って日本語要約を実施して、その出力をGPT-4および人手で評価してみました。
やってみると現状公開されているモデル（一部）でもニュース記事要約タスクなら普通に動きそうな印象でした。

GPT-4と人手評価の相関も計測してみましたが、評価の観点においてはちょっと弱い相関となりました。
今のところGPT-4での評価はざっくりスコアを求める用かもしれません（人手評価のほうも一人なのでちょっと怪しいです）。

また、LLMごとに入力記事に対して出力される要約長が異なることも確認できました。
用途に合わせてモデルを選択するなどが重要かもしれません。

今回はGeneration Configでさぼってしまった点、人手評価がガバガバな点で検証としていまいちなものになってしまいました。
個人でもっといい感じにできる検証設定を思いついたらまた何かLLMで遊んでみようと思います。

まとめ

• 気胸で入院することで828件のタイトルを眺め、最終的に28件の論文を読んだ
• 個人的にめちゃくちゃ面白かった論文は多分こちら
  • Invariant Language Modeling.
  • PromptBERT: Improving BERT Sentence Embeddings with Prompts.
  • Automatic Document Selection for Efficient Encoder Pretraining.
• トホホ、気胸はもうこりごりだよぉ～

概要

以前の投稿でも触れましたが、1月末から二週間ほど気胸で入院していました。。。
自分の場合、病院受診、緊急搬送、即入院の流れだったので、手元にスマホしかない状況でした。
あまりにも暇かつ、何もしていないと思考が悪い方向に進んでいくので、現実逃避も兼ねてEMNLP2022の採択論文を眺めた次第です。

採択論文の眺め方

今回の場合、時間に余裕があるので本会議採択論文828件のタイトルを眺めて、その中から気になったものをちゃんと読む形をとりました。
具体的には次の工程です。

1. EMNLP2022採択論文828件のタイトルを全て眺めて、気になったものを残す
2. 1の各論文のアブストラクトを眺めて、気になったものを残す
3. 2で残った論文を（程度は様々に）読む

タイトル、アブストラクトの順で篩にかける形ですね。
大体1の工程で1/10程度になって、2で1/5程度になる印象です。

ちなみに3番まで進んだ論文は必ずintroductionは読んで、面白かったら精読するし、ちょっと気になるぐらいなら斜め読み、なんか違うかなとなったらそこで読むのを止めてます。

今回は実際に3番まで進んだ論文一覧をメモとして列挙します。
（解説とかではないです。）

EMNLP2022で気になった論文一覧

気になった論文は次の28件です。

The Geometry of Multilingual Language Model Representations.
Toward Unifying Text Segmentation and Long Document Summarization.
SNAC: Coherence Error Detection for Narrative Summarization.
RetroMAE: Pre-Training Retrieval-oriented Language Models Via Masked Auto-Encoder.
Zero-Shot Text Classification with Self-Training.
Efficient Nearest Neighbor Search for Cross-Encoder Models using Matrix Factorization.
How Far are We from Robust Long Abstractive Summarization?
Summarizing Community-based Question-Answer Pairs.
Sparse Teachers Can Be Dense with Knowledge.
DuReaderretrieval: A Large-scale Chinese Benchmark for Passage Retrieval from Web Search Engine.
Invariant Language Modeling.
CTRLSUM: Towards Generic Controllable Text Summarization.
A Survey of Active Learning for Natural Language Processing.
Bernice: A Multilingual Pre-trained Encoder for Twitter.
Revisiting Grammatical Error Correction Evaluation and Beyond.
X-FACTOR: A Cross-metric Evaluation of Factual Correctness in Abstractive Summarization.
HashFormers: Towards Vocabulary-independent Pre-trained Transformers.
Decoding a Neural Retriever’s Latent Space for Query Suggestion.
PromptBERT: Improving BERT Sentence Embeddings with Prompts.
Incorporating Relevance Feedback for Information-Seeking Retrieval using Few-Shot Document Re-Ranking.
Few-shot Learning with Multilingual Generative Language Models.
Automatic Document Selection for Efficient Encoder Pretraining.
Large Dual Encoders Are Generalizable Retrievers.
Improving Iterative Text Revision by Learning Where to Edit from Other Revision Tasks.
Mask the Correct Tokens: An Embarrassingly Simple Approach for Error Correction.
CODER: An efficient framework for improving retrieval through COntextual Document Embedding Reranking.
CiteSum: Citation Text-guided Scientific Extreme Summarization and Domain Adaptation with Limited Supervision.
Pseudo-Relevance for Enhancing Document Representation.

ワードクラウドで遊ぶ

せっかくなので、読んだ論文28件のアブストラクトをワードクラウドに入れてみました。
（ストップワードは適当に設定しています。）

特徴的な単語としては「query」、「retrieval」、「embedding」、「summarization」とかでしょうか。
そうでしょうね的な感想しかでないです。。。

論文メモ

28件の論文のうち、特に気になる論文のメモを残しておきます。
（解説とかではないので、内容が気になった場合は元論文に当たってください。）

RetroMAE: Pre-Training Retrieval-oriented Language Models Via Masked Auto-Encoder.

https://aclanthology.org/2022.emnlp-main.35/

Retrieval系のお話です。
検索用の分散表現作成を目的として、MAE (Masked Auto-Encoder) を利用した事前学習を行った論文です。
MAEはreconstructionをやってて、それがめちゃくちゃ効いた的な話みたいです。
Fig.1が概要図になってます。

Zero-Shot Text Classification with Self-Training.

https://aclanthology.org/2022.emnlp-main.73/

Zero-Shot分類でNLIベースのものが既存研究であって、それにself-trainingを足した話です。
手法としては素直なんですが、結果がけっこう上がっていてちょっと驚きました。

How Far are We from Robust Long Abstractive Summarization?

https://aclanthology.org/2022.emnlp-main.172/

最近流行り？のLong Text SummarizationについてBART、PEGASUSベースのモデルのベースライン調査を行ってます。
また、relevanceとfactual consistencyについて、人手と自動評価の相関を測定してます。
特にこのメタ評価の話（Table 3）は勉強になりました。

Invariant Language Modeling.

https://aclanthology.org/2022.emnlp-main.387/

Invariant Risk Minimization (IRM)をBERTの事前学習で実施することで、invariant性を満たすような実験結果が確認できた的な話です。
やりたいことはFig. 1の通りで、それを実現する学習の流れがAppendix A.のFig. 3に記載されています。

もう少し語ると、学習データのenvironments（だいたいドメイン）間でのinvariant relationshipを学習しよう、みたいな話がcausal inferenceではよくあるので、それをBERTでやった話、のはずです。
各enviromentのfeatureをinvariantなものと、spurious、つまりenvironments間で一般化できないものに分けて考えて、前者を素性抽出できるモデル（BERTなど）を作成することを頑張った話だと思います。
このモデル作成は、IRMおよびIRM-gamesを参考にして行うのですが、この部分がすごくシンプルな構造になっています（Alg. 1）。

検証としては

1. robustness to noise
2. bias removal
3. out-of-domain generalization

を行っていて、それぞれで有効であることを報告しています。

また、Sec. 5.2では提案手法が表層的な話ではなく、潜在空間の話であることを強調するために、environmentとしてmultilingual（EnglishとFarsi）で実験した話も掲載されています。

EMNLP2022の中で個人的にこの論文が一番面白く、勉強になったのですが、うまく言語化できていない感があります。。。

CTRLSUM: Towards Generic Controllable Text Summarization.

https://aclanthology.org/2022.emnlp-main.396/

要約の出力制御は大抵モデル構造、出力構造で頑張ることが多い（と思っている）のですが、
この研究ではキーワード（Prompt）で出力制御を行うことを目指しています。

入出力の例はTab. 1にあります。
夢があるなーとか思いながら読んでいました。

A Survey of Active Learning for Natural Language Processing.

https://aclanthology.org/2022.emnlp-main.414/

タイトルの通りです。
現在のActive Learningの主要な研究トピックがまとまっています。

Active LearningをAlg. 1にまとめていて、その構成要素を各章で解説する形を取っています。
基本的にアノテーションするサンプルを選択する研究について書いてあります。

Revisiting Grammatical Error Correction Evaluation and Beyond.

https://aclanthology.org/2022.emnlp-main.463/

GECの自動評価尺度はm2、ERRANTと呼ばれる編集部分の一致を確認する方法、またはGLEUと呼ばれるBLEUのような方法が（少なくとも自分が研究していたときは）よく使われています。
この論文では、編集部分の一致を取りつつ、BERTScoreの手法を混ぜた自動評価尺度を提案しています。

X-FACTOR: A Cross-metric Evaluation of Factual Correctness in Abstractive Summarization.

https://aclanthology.org/2022.emnlp-main.478/

factuality改善に関する要約に関する論文です。
factuality-awareな要約モデルを調査した後、3.7章で自動評価尺度間の相関を、3.8章で人手相関を報告しています。

特に3.7章は面白く、Tab. 5に記載されているROUGEと各種factuality評価尺度の相関は勉強になりました。
「How Far are We from Robust Long Abstractive Summarization?」もそうですが、factualityは要約において重要な要素だと思うので、もうしばらく追っていきたいですね。

PromptBERT: Improving BERT Sentence Embeddings with Prompts.

https://aclanthology.org/2022.emnlp-main.603/

特になんの工夫もなくBERTの出力ベクトルをそのまま類似度算出などに使用するとうまくいかないことが往々にしてあります。
この現象の理由として、BERTのベクトル空間がanisotropicで、narrow coneな埋め込みになっているから（SimCSEなど）だと言われています。
（ちなみにnarrow coneの話はこの論文が詳しいです。昔研究室で論文紹介したスライドがこちら。）

この論文では、BERTが出力する分散表現がうまく働かない原因として、anistropicというより、BERTのlayerが効果的に機能していないのと、0-layer（つまりstatic embedding）のbiasが影響していると主張しています。
詳しくはSec. 3に記載されています。
実際、2つめのbiasに関する調査として、Fig. 1に図示した例が載っていますが、たしかに頻度、case/uncase、subwordで分かれているのがわかります。

この対応として、Promptingをベースとした文分散表現作成を提案しています。
[MASK]トークンを利用して分散表現を作成することで、問題となったbiasも軽減され、MLMの事前学習で[MASK]トークンのhiddenならばBERTのlayerも機能する、と言った具合のようです。
詳しくはSec. 4に記載されています。

確かにこの方法（といくつかの工夫）でSimCSEといった手法と比べて高い精度となっていて、ちょっとおもしろいと思いました。

Automatic Document Selection for Efficient Encoder Pretraining.

https://aclanthology.org/2022.emnlp-main.647/

データ選択手法と聞いて何を思い浮かべますか？
自分はMoore and Lewis. [link]がシンプルかつ動かしやすくて好きです。
この論文では、Cynical Data Selection [link]を利用してデータ選択を行います。

具体的には、BERTの事前学習に使用するデータのためにこの手法を用いています。
in-domainなBERTを作成する際に、そのドメインのデータだけでなく、一般ドメインのデータからそのドメインに関連するデータを選択し、事前学習に使用します。
このように関連するデータを使用することで、効率的にin-domainのモデルを作成することが期待されます。

恥ずかしながら、Cynical Data Selectionを知らなかったので勉強になりました。

Large Dual Encoders Are Generalizable Retrievers.

https://aclanthology.org/2022.emnlp-main.669/

パラメータ数がすごく大きいDual EncoderはBM25やColBERTより高い精度になることを実験的に示した論文です。
評価はMS MarcoやBM25で行っていて、Fig 1.やTab. 3に実験結果が載っています。
他にも、分析などが報告されていて勉強になりました。

Improving Iterative Text Revision by Learning Where to Edit from Other Revision Tasks.

https://aclanthology.org/2022.emnlp-main.678/

Grammarly Paperです。
Revisionして欲しい文章が与えられたら、自動でintent edit span（単語ごとにfluencyのeditが必要、coherenceのeditが必要といったもの）を推定し、その結果を別途Revisionモデルに投げて修正を行います（Fig. 1が概要図です。）。
これをIterativeに行うことで、Revisionを実施しています。

文章の修正は以前から興味があり、すごく勉強になりました。

論文を読んだ感想

論文は適度に頭を使いながら読めるので、夢中になって読むことができました。

ただ、正直なところ、手術前日とかはあまり集中して論文読めなかったです。
逆に手術数時間前は結構ちゃんと読めました。現実逃避したかったんだとおもいます。

まとめ

• ChatGPT は雑に良い
• トホホ、気胸はもうこりごりだよぉ～

概要

気胸で二週間ほど入院していました。

入院生活めちゃくちゃ暇なので、色々やっていて、その中の一つで日記を書いたりしてました。
せっかく珍しく日記とか書いたので公開、と思ったのですが、そのまま出すと後悔しそうなので（激ウマギャグ）、今流行りのChatGPTを一段挟むことにしました。

ChatGPT

ChatGPTについては散々ネットに解説記事が出回っていると思うのでここでは解説はしません。
今回はOpenAIが提供しているChatGPTのようなモデルを使ってみました。

ChatGPTのようなモデル？

GPTには色々モデルがあるのですが、その中でも今回はいわゆる「text-davinci-003」を触っています。
こちらのOpenAi公式ページを読んでいただくと分かる通り、「code-davinci-002」に対してInstructGPTを行い、さらにPROで精度向上させたモデルとなっています。

ちなみに、OpenAIのChatGPTに関するページを眺めてみると同じようなことが書いてあります。
おそらく、ChatGPTの内部のモデルは「text-davinci-003」で、推論に使用する各種パラメータまで含めてChatGPTと呼称されているのかと思います（ドキュメント斜め読みマンなので違っていたらすいません。。。）。

そんなわけで、今回はChatGPTと同じパラメータを持つと思われるモデルを用いて要約を行いたいと思います。

要約

入力（プロンプト）とか設定とか

今回は次のようにプロンプトを入れてます。

次の日記を要約

<日記>

また、各種推論パラメータは次のパラメータを使用しました。

約二週間分の日記をまとめて要約

まるまる全てを要約してみると次のような出力になりました。

要約：最初の日から十三日目までの体調の悪化、検査の結果により手術が必要となるまでの病院生活を記した日記である。
最終的には手術が成功し、退院することができたが、思いもよらぬ料金請求書が届いてしまう

ほぼほぼその通りです。
特に言うことないですね。

一日ごとに要約してみる

せっかくなので、一日ごとに要約してみました。

一日目

今日は最寄りのお医者様へ行き、気胸で緊急搬送が決まった。
搬送先を探しても満床で見つからなかったが、個室なら可能ということで搬送される。
酸素飽和度が低下しそうになり神だと感じた回復体位をとった。
緊急搬送車で搬送され、PCRやCTを受けてから一週間ほど入院することになった。
管を入れる際には部分麻酔でも痛くて耐えられなかったが、個室に入ったあとは熱も出てフラフラしたので眠りたいが痛くて眠れないという思いを体験した。

管を入れる際には部分麻酔でも痛くて耐えられなかったが、

耐えてます。日記ではギリギリ耐えたって書いてます。あまり舐めないでいただきたい。

二日目

今日は病院の寝たくない朝を迎え、朝ごはんの準備で利き腕を使えなかったことやレンタルサービスなどの説明を受け、レントゲン検査をして膨らんでいるかを診てもらうが、痛みがあり眠れない夜を過ごした。

レントゲン検査をして膨らんでいるかを診てもらう

これは肺のことですね。気胸は自然に治る、つまり自然に穴が塞がって膨らむ場合が多いので、それをレントゲンで検査しています。
ちょっと流暢性が残念な感じですね。。。

三日目

三日目の病院では管がまだ痛いので横になることを考えた。
レントゲンで肺はまだ膨らんでいないと判明し、健康保険だと個室代はかからないことが分かり、さっさと退院することを夢見た。
暇なのでemnlp2022の採択論文を眺め、夜は少し眠れた。

大体あってます。
ちなみにemnlp2022の採択論文を眺めた話はあとでブログで公開予定です。

四日目

要約：四日目の入院生活に慣れてきたが、肺は戻らず、吸引をかけるか手術を取る必要があり、退院の夢は幻想だった。
今日もemnlpのタイトルを眺めていたが、病院のベットの硬さで背中の痛みが残っている。

肺は戻らず、吸引をかけるか手術を取る必要があり

ここちょっと変ですね。
吸引というのは外から圧力で肺を膨らませて、自然に穴が塞がるのを手助けする医療行為なのですが、手術との二択ではないです。
吸引してもうまく塞がらなかったら手術のはず。

生成される要約、coherenceがイケてない？

五日目

今日は起きる癖がついたとのことで、吸引で肺が膨らんだという祝福を得た。
しかし、密林から注文した下着が届かなくなりコノザマ現象が発生している。
そして、emnlpのタイトル一覧を読み終わり、明日から気になった論文を読む予定。
最後に夜は背中が痛いという日記だった。

大体あってます。
というか割とそのままかもです。

六日目

本日は起床時間が7時で、レントゲンがない為、読書やソシャゲをするなどして暇を持て余した。
また、今回から腕も動き出したのでシャンプーを自分で行うことに挑戦したが、洗面台に頭や腕が収まらず、シャワーヘッドの操作も難しかった。
下着が無事届いたことで幸せを噛み締め、肺の状態も気になるところだった。

内容はあってるんですが、もうちょっと圧縮率いじりたいですね。
シャワーのくだりとか「シャワーは難しかった」で十分な気が。。。

七日目

今日はレントゲン検査の結果が出たが、問題があり手術を回避できず、再度吸引が必要となった。
論文を読んだりソシャゲしたりしながら一日を過ごした。

あってます。
問題っていうのは肺が自然に膨らまなかったことですね。

八日目

今日から内科から外科に移ったことで、手術が現実的になりつつある。
月末だから仕事の方で必要な処理を済ませて、退院後の金銭面なども都合をつけようとしているが、肩が痛いためか現実放棄気味だ。

肩が痛いためか現実放棄気味だ。

ちょっと違いますね。
肩が痛いからじゃなくて、手術をするという事実から現実放棄って日記には書いています。

九日目

九日目に入院し、全身麻酔での手術を覚悟していることを書いた日記である。
ベッドから正面にカレンダーがある病院の空気がナーバスにさせる。
しかし、抱きたくもない希望を抱いてしまうこともあり、今日も肩が痛いというような不安がある。

ちょっと話それますが、なんで病院の個室ってベットの真正面にカレンダー置くんですかね？
日数感覚とかだとは思うんですが、個人的にはその辺意識するとメンタルダメージ負うかもです。
肩が痛いのは不安ではなく事実。

十日目

明日の手術の前に、今日は忙しくなかった。
午前中は手術前同意で少し忙しいが、午後はいつも通りの日常活動を行った。
洗濯や乾燥も行い最後の晩餐はパン粉であげた鮭だった。

大体あってますが、 日常活動って単語はちょっと違うかな。。。
いつも通りの入院生活とかが個人的には好ましいんですが、その辺の機微をモデルに求めるのはちょっと酷か。

十一日目

11日目に手術を受け、意識が飛んでいたところから目覚めた。
痛みが強くて、動くこともつらい状態だったが、必死にトイレまで行くことになった。

急に圧縮してきました。

意識が飛んで

これは全身麻酔で意識が飛んで、ということですね。
出術後は痛み以外にも吐き気とかもありました。

十二日目

今日は腰の痛みがあり、レントゲン検査を受けたところ問題なさそうだった。
時間を置いて再度検査を受け、今度こそ大丈夫だったとのことでドレーンを抜いてもらったところ、全ての痛みがなくなった。
保険の力で請求書の額が抑えられたが、今夜も体は痛いとのことだった。

腰の痛み

背中ですね。
腰は痛くなったことそんなになかったと思います。

全ての痛みがなくなった

仙豆かなにか？
全ての痛みがなくなるのではなく、痛みが薄れた、が正しいです。

十三日目

十三日間の入院が終わり、体温は37度になり料金は高いものとなった。

正しいですが、ちょっと無理矢理くっつけすぎですね。。。

要約してもらった感想

正しいといえば正しいですが。。。
まあZeroでやってこれなので、その辺を踏まえると十分かもですね。
圧縮率周りもある程度はプロンプトでいじれば対応できると思いますし。

気胸に関するちゃんとした体験記はそのうち暇なときにメモとして残すと思います。

まとめ

• 勤務技術ブログの執筆しかやってない
• 何もしなくても何かをしていても時間は等しく無くなることを実感
• 2023年やりたいこと:
  1. DeepSpeedに詳しくなる
  2. 成果物までたどり着く

2022年にやったこと

昨年もやっていた、2022年に世間一般に公開した技術的な話を時系列列挙してみたいと思います。

1. 2022年1月: 勤務先ブログにて「深層学習の量子化に入門してみた 〜理論編〜」を公開
2. 2022年3月: 勤務先ブログにて「深層学習の量子化に入門してみた 〜BERTをDynamic Quantization〜」を公開
3. 2022年5月: 勤務先ブログにて「深層学習の量子化に入門してみた 〜BERTをStatic Quantization〜」を公開
4. 2022年7月: 勤務先ブログにて「深層学習の量子化に入門してみた 〜BERTをIntel Neural CompressorでStatic Quantization〜」を公開
5. 2022年12月: 勤務先ブログにて「DeepSpeed Compressionを使ってtask-specific BERTを蒸留してみた」を公開

勤務先で技術ブログを書く文化がなかったらどうなっていたんだろう。。。

振り返り

2022年は量子化とか蒸留を用いたモデルサイズ軽減にハマっていたみたいですね。
昨今機械学習モデルがどんどん大きくなるので、この辺調べると面白いかなと思ってやってみたら実際面白かったので1年通して調べてたみたいな感じです。
モデルサイズ軽減以外にも学習などなど様々な状況で取り回しが良さそうなDeepSpeedも面白く、まだまだ発展していくライブラリのような気がしました。
来年もこの辺は調べると思います。

今年他にやったこととしては技術的な知識を仕入れた点とかでしょうか。
Clean Code、レガシーコード改善ガイド、テスト駆動開発とかは結構参考になったような気がしますが、身についたかどうかはよくわからないです。。。

成果物？知らないですね。。。

2022年の総括

2022年は良く言えば来年のために充電していた年、悪く言えば何もしていない年だったと思います。
仕事終わってご飯食べてゲームして寝るだけでも一日は充実するんですね。。。

世間一般だとStableDiffusionとかChatGPTが話題になって、深層学習モデルが広く注目された年だったこともあり、自分もその辺でなにかしようかなとか思ったような気もしますが、逆張り気質なので結局投げるなどしてしまった記憶がちょっとありますね。。。

2023年の目標

2023年はとりあえず継続してDeepSpeedには詳しくなっておきたいですね。
これからも継続して使うライブラリのような気がします。
他にも量子化だとQATとかさわってないのでその辺はやりたいかな？

あとはやっぱり何か外に共有したい、とかが目標になるのかなと思います。
個人的に技術記事とか成果物とかって興味持った事柄を触っていると勝手に生えてくるものかと思っていたのですが、（少なくとも自分は）そうではなさそうなので、強い意志をもって成果物を生み出せるように活動していきたいと思います。

まとめ

• GLIDEとかいうテキストを入れたらそれを反映した画像を出力するモデルがOpenAIによって公開された
• OpenAIによってsmallサイズのGLIDEが公開されているのでちょっと遊んでみた
  • 論文内容の解説記事ではないです
• CVの流行りも色々変わっていくんですね
• バイアス大変そう

GLIDEって？

2021年12月、arXivに次の論文が投稿されました。

GLIDE: Towards Photorealistic Image Generation and Editing with Text-Guided Diffusion Models. Alex Nichol, Prafulla Dhariwal, Aditya Ramesh, Pranav Shyam, Pamela Mishkin, Bob McGrew, Ilya Sutskever, Mark Chen. [link]

GLIDEはこの論文で提案された、テキストを入れたら画像が出力されるモデルのことです。
以下の画像が論文に記載されている具体例となっています。

一番上の行がReal Image、つまり実際の画像で、画像に対応する各キャプションが一番下似それぞれ記載されています。
2行目以降は機械学習モデルの出力ですね。
XMC-GANというのがGANの仕組みを利用して、画像とキャプションの組を使って学習したモデルとなっています。
その下のDALL-EとGLIDEはZero-shotで運用しているモデル、つまり明示的に画像とキャプションの組を使って学習はしていない（と思われる）モデルとなっています。

この具体例の通り、GLIDEはZero-shotにもかかわらず、かなり鮮明な画像を出力できていることがわかります。
ちなみに、この具体例にはGLIDEが2種類（CLIP Guid.とCF Guid.）あるのですが、論文中ではCF Guid.の方を推しているみたいです。
この辺の違いについてはまた別の記事で解説するかも？しれません。

GLIDEモデルが公開されてる！

なんとこのGLIDE、smallモデルでなおかつfiltered dataで学習されたモデルではありますが、一般公開されています（smallモデルとか言ってますが、あくまで論文で使用しているモデルと比べて、という意味合いです。）。

filtered dataって何のこと？って話なのですが、その辺りの事情は論文の7. Safety Considerationsで主に記述されています。
具体的には以下の部分ですね。

Our model is capable of producing fake but realistic images and enables unskilled users to quickly make convincing edits to existing images. As a result, releasing our model without safeguards would significantly reduce the skills required to create convincing disinformation or Deepfakes. Additionally, since the model’s samples reflect various biases, including those from the dataset, applying it could unintentionally perpetuate harmful societal biases.

ざっくりまとめると

1. 論文モデルそのままは精度が高すぎてdeepfakeとか誰でも作れちゃう
2. 論文モデルを学習したデータにはそこそこバイアス入っていて、生成した画像に意図せず有害バイアスが入ってしまう

の2点を懸念して、filtered dataを用意して、それで学習したsmallモデルを公開した、とのことです。
（つまりバイアスのあるデータをfilterしたみたいです。）

GLIDEモデルの動かし方について

せっかく公開してくれているならfilter dataで学習したモデルとか気にせずとりあえず動かしてみたい！
というわけで適当にうごかしてみました。

GLIDEのGitHubレポジトリはこちらで、ご丁寧にGoogle Colabを貼ってくれているので誰でも簡単に試すことができます。
3つのColabリンクが貼ってあるのですが、とりあえずGLIDEを動かしたいならtext2imというのを触ればよいのかなと思います。

ちなみにinpaintというのは既存の画像に対して、与えられたテキストをもとに書き足すexampleとなっています。
clip_guidedはさきほどのGLIDEの出力例のGLIDE (CLIP Guid.)ってやつですね。

ノートブックの細かい話

簡単ではありますが、text2imのノートブックを使う際の気をつけることを記載します。

まず、入力するテキストですが、ノートブック中のprompt変数に格納しています。
また、モデルはテキストから画像を生成するモデルと、それをupsampleするモデルの2種類を使います。
そのため、推論も2回走るような構成になっています。

細かいことはレポジトリのmodel-card.mdに記載されているので、気になった方はそちらをご確認ください。

実際にいくつか生成してみた

適当に色々生成してみました。
以下、添付する図はすべてGLIDE（text2im）で生成した画像です。

ちなみに、同じキャプションを使用した場合でも、画像を生成する度に異なる画像が生成されるので、再現はできなさそうでした。

論文のキャプションを使ってみる

まずは論文や上記ノートブック（text2im）で使われている例を試してみようと思います。

ノートブックをそのまま動かす

うまく生成されました。

論文モデルの出力を再現してみる

上記の出力例（一番左端の列）の画像を公開モデルでも生成してみました。
論文モデルと比べて、学習データもモデルサイズも小さめになっているので、なかなか綺麗な
画像は生成できていません。

バイアスチェック

論文では生成した画像のバイアスに関しても言及しています。
公開モデルを使って、生成した画像のバイアスを見てみようと思います。

上から順に

• 宗教的なバイアス
• ジェンダー（男性）のバイアス
• ジェンダー（女性）のバイアス

に関する画像となっています。

論文にも記載されているのですが、宗教的なバイアスに関しては確かに、西洋風の建物の画像が生成されています。

おもちゃの画像に関しては、生成された画像がなかなか個性的なので、バイアス云々言ってる場合ではないような気もしますが。。。
男性向けおもちゃは青っぽくて、女性向けおもちゃはピンクっぽいみたいなバイアスがついている、とは思います。

遊ぶ

遊びます。

ガンダム

色合いだけ頑張っている感じでしょうか
（ハサウェイ面白かったです）

ゴジラ

こんなおもちゃ昔ありませんでした？

可愛さ爆発

戦わせてみた

戦っている、というよりはただただ並んでいますね。。。
他にも複数オブジェクトで色々やらせようとしたんですが、なかなかうまく画像が生成されませんでした。
公開モデルではかなり単純な生成しかできないかもしれません。

飯テロ

味噌？

もっと青いものを想定していたんですが。。。想像していたものとはちょっと違いました。。。
論文にも記載されているのですが、明らかに存在しない画像を生成させようとするとうまく行かないみたいです。

背景

背景画像はかなりうまく生成されました。

趣味1

わかってるっぽいです

わかってないっぽいです

趣味2

最近自分がハマってるやつ適当に投げてみましたが。。。

感想

今回はGLIDEの簡単な紹介と公開モデルで遊んでみた話でした。
個人的な感想になりますが、なんとなくCVはGANベースの手法が流行っている印象があったので、こういったGANではないモデルが出てきて、流行を掴む難しさみたいなものを感じました。。。反省。
自然言語処理（別に自然言語処理の流行も掴めてないですが）ばっかりやってると画像周りはめちゃくちゃ周回遅れで知識を得ているような感じになっちゃいますね。

モデルを公開していただいたので、色々遊んでみましたが、小規模モデルでこの精度なら論文モデルは確かに強いだろうなあという印象でした。
富士山とかめちゃくちゃ普通に生成されましたし、有名な固有名詞はこのモデルでも抑えられていそうです。

個人的に気になった話としてはバイアス周りでしょうか。
論文でもかなり気にしていて、この辺りは大規模事前学習モデルの常というか、どうしても学習データを大規模にするとそういったバイアスは入るので、その辺りの懸念を強く感じました。
前処理的なアプローチはデータフィルタリングとかだとおもうのですが、後処理的にデバイアスするのはどうするんだろう、なんて疑問もちょっと持ったので、その辺り時間があれば調べてみようと思います。

まとめ

• やったことの大半は勤務先技術ブログの執筆
• 今年は研究発表ができた、来年は。。。
• 2022年やりたいこと:
  1. 来年ももう少し日本語要約を擦りたい
  2. 個人開発勉強する
  3. GECとかもちょっとやりたい

2021年にやったこと

2021年、世間一般に公開した内容を時系列順に挙げてみようと思います。

1. 2021年1月: 勤務先技術ブログにて「AACL-IJCNLP2020で発表してきました」を公開
2. 2021年3月: 言語処理学会第27回年次大会にて「CSJを用いた日本語話し言葉BERTの作成」を発表
3. 2021年3月: 言語処理学会第27回年次大会にて「事前学習モデルを用いた少量データに対する日本語抽象型要約
   」を発表
4. 2021年3月: ジャーナル自然言語処理にて学会記事「Stronger Baselines for Grammatical Error Correction Using a Pretrained Encoder-Decoder Model. の採択までの流れ記事」が公開
5. 2021年4月: 勤務先技術ブログにて「日本語話し言葉BERTを作成、公開します！」を公開
6. 2021年5月: 勤務先技術ブログにて「事前学習モデルBARTを使って日本語文書要約をやってみた」を公開
7. 2021年8月: 勤務先技術ブログにて「ACL2021のBest PaperのVOLTを日本語文書分類で試してみた結果...！」を公開
8. 2021年9月: 勤務先技術ブログにて「ラベルなしデータだけでも高い精度で文法誤り訂正ができるLM-Criticの紹介」を公開
9. 2021年9月: 日本語GPT-2を使ったデモアプリ「"小説家になろう"っぽい小説タイトルメーカー」を公開、紹介記事（Qiita）はこちら
10. 2021年11月: 勤務先技術ブログにて「事前学習モデルT5とTransformersを使ってお手軽日本語文書要約をやってみた」を公開
11. 2021年12月: 個人ブログ「塵も積もれば忘備録」を公開

勤務先の技術ブログ多いですね......

2021年前半を振り返って

1月から6月までを振り返ってみると、トピックとしては次の3つに分かれるみたいです。

1. AACL-IJCNLP2020のネタ
2. 言語処理学会第27回年次大会まわり
3. 日本語BARTで要約

1と2は2020年にやってたネタです。（何なら1は2019年終わり辺りからちょっとやってたまである）
1については、学会記事なども書かせて頂いて、研究の始まりはかなりわちゃわちゃしていたような気がしますが、終わりはちゃんと振り返りまでできたような覚えがあります。
学会記事を書かせて頂いて、改めて解説記事、というか論文採択までの流れを説明するのって難しいなぁと感じました。。。
この学会記事シリーズは個人的に読み物としてもかなり面白く（とくに採択までの流れは普段聞けないのでおもしろい）、隙間時間にちょこちょこ読んで、勉強させていただいています。

2は社内でやっていた話を外に出せて良かったーという点が自分にとって大きかったと思います。
日本語要約はデータ用意したから発表しちゃえ、ぐらいの気持ちだったような気が。。。
思ったよりも出力する要約の抽象度が高いデータだったので、そもそもEnc-Decでできるのか不安とかもありましたが、やってみたら意外とできたこともあり、その後も割とこのデータを擦っている感じですね。

3からが2021年に入って始めたことになると思います。
年次大会で日本語BARTを作っていただいたことを知り、動かしたいーって思って数ヶ月。
動かした話を世間に公開できてよかったです。

2021年後半を振り返って

7月から12月までを振り返ってみると、トピックは次のようになります。

1. 最新論文で遊ぶ
2. 日本語T5で要約
3. 個人開発をやってみた

1はただただ好奇心の産物です。
日本語でやってみるとどうなるかなー？的な疑問と、実際に自分で動かしてみたい気持ちでVOLTを触ってみたとかだったと思います。
LM-Criticも動かしてみたさはあったんですが、個人でやると絶対に重たいので断念、論文紹介に留めました。。。
来年もこういう記事はちょこちょこ出すだろうと思います。

2はせっかくあるなら動かそうのやつですね。
はじめてTransformersでEnc-Decやったんですが、めっちゃ簡単ですね。
OpenNMT-pyとかも当時は簡単だと思ったんですが、時代が進むとどんどん楽なものが出てくるんだなと実感させられました。

3は昨年からやりたいなと思いつつなかなかできなかった話ですね。
GPT-2デモの構成もそのうちどこかに書こうとは思うのですが、かなり簡単にできてます。
実際に作業しているときもググれば無限に解決策出てくるので、本当にいい時代になったものだと思いました。

2021年の総括

2021年、全体的には思ったより色々できなかったなーという印象です。。。
とくに個人開発周りとかはもっと色々できたかと。。。
平日もうちょっと時間作れればって後悔が大きいですね。

日本語要約で事前学習モデルを色々検証できたのは良かったかなと思います。
ひととおりはできたので、次は評価かデータセットか。
もう少し触りたいですね。

研究的な話は2020年にやったことが外に出た印象です。
来年は、、、どうなんでしょうね。。。

2022年の目標

2021年の振り返りから2022年の目標は次のようになるのかなと思います。

1. 日本語要約の評価ないしはデータセット
2. 開発周りをもう少し勉強する
3. GECないしは校正支援まわりのなにかをやる

1は色々やって技術ブログで公開とかできるとよいのかなと思います。
とりあえずBERTScore触りたい触りたいめちゃくちゃ触りたい。

2は切実ですね。。。
作りながら覚えていくのが自分の性に合っているので、そんな感じで進められるといいのかなと思います。

3が急に来た感じではありますが、これは以前の記事でGECとかを考えて、自分でもなにかできたらな、みたいな気持ちが由来ですね。
次の年次大会での発表を聞いて、そこから自分でもぱっとできそうな話を考えようと思ってます。

まとめ

• GECで修士卒業した人間が、就職後にこういう研究が世の中にあったらいいなって思ったものを挙げてます
  • ERRANT-Japaneseが欲しい
  • 訂正結果の説明して欲しい
  • 結果の一貫性をいい感じにして欲しい
  • マルチモーダルできるとおもしろいと思いました
• 欲しいばっかりですいません　m(_ _)m
• アドベントカレンダーの企画ありがとうございました

GECで修士卒業した話

今回の記事は「GECで修士卒業した人間が、GEC研究から足を洗えると思ったら、微妙にそうでもなかったので、自分の視点から、こういう研究が世の中にあったらいいなあ」的な内容（お気持ち的なやつですね）となっております。
ということで、まずは前フリとして、自分の視点について簡単に紹介します。

GECで修士を卒業するまで

始めまして。
記事のタイトル通り、修士の2年間でGECの研究に取り組み、そのまま修士を卒業して就職した者です。
修士では主に、学習データが少量のときのGECについて取り組みました。

自分が修士で取り組んだ内容をざっくり説明すると、学習データを使わない設定のGECに対して、当時流行っていた（と思われる）教師なし機械翻訳を使って取り組んだ的なやつです。
教師なしと言っても、やっていることは、GECでよく使われる誤り文と訂正文のデータを使わず、代わりに単言語データで頑張って学習してGECモデルを作ろう、的な内容になっています。
ちなみに結論としては、単言語データになんらかの誤りを入れて、疑似対訳データを作る方法（今流行っているやつですね）が一番シンプルで性能が高い、となっております。。。
細かい内容については、こちらの修論を確認していただければと思います。

就職の話

自分は自然言語処理を扱う会社に就職しました。
自然言語処理、と言っても色々あるとは思うのですが、残念ながら？就職先は学習者支援に関して腰を入れている、というわけではありませんでした。
「これでGEC研究から離れるかな」とも思ったのですが、弊社のサービスとして校正支援があり、それに関わることとなりました。
先に言っておくのですが、校正支援とGECは、研究的にもそうですが、実世界の問題設定としても全然違うものです。
しかし、全然違う、と言っても、間違った文を訂正する、といった点では（めちゃくちゃ大雑把ですが）同じですし、自分自身、さまざまな問題設定に触ってみたかったこともあり、かなりモチベーションは高めに取り組めていると思います。

今回の記事は、このような、「修士でGECやって、成果を挙げられなかった人間が就職後もちょっとだけ関係するタスクを触った視点」から、GEC研究で使えそうな問題、課題設定を共有させていただくものとなっております。

こういう研究あったらいいなあ一覧

日本語GEC、もっと充実して欲しい

個人の感想になりますが、日本語GECのデータは結構あると思ってるんですよね。
詳細は今回のGECアドベントカレンダーを眺めていただければと思います。
問題は評価の方かなと思っています。
具体的にはERRANT-Japaneseが欲しいって話ですね。

ERRANTの何が良いって、誤りタグの推定もそうなんですが、訂正前後を比較したときのDiffの作成がかなり人間にわかりやすいんですよね。
訂正前後のDiffのAlignment云々については、こちらの論文で紹介されています。
ざっくりかいつまむと、編集距離で文間のDiffとって、人手で決めたマージルールでくっつける的なやつだったと思います。
論文中では、この自動Diff作成結果をCoNLL-2013やCoNLL-2014などの人手で作成したDiffと比較して、一致度合いの検証をしています。

自分の知っている限りではありますが、日本語GEC評価、となったら最近はTEC-JLデータに対してGLEUで評価、とかになるのでしょうか。
あとはNAIST誤用コーパスとか？

一方で、校正支援、となったときに、NAIST誤用コーパスみたいな誤りタグがついたデータはないので、訂正システムの良さを誰かに説明する、となったときに結構困るんですよね。
適当に編集距離のDiffを出しても正直ピンとこないことが多くて。。。（これも校正支援の定義次第だとは思っていて、たとえば入力誤りに限定するなら編集距離でもいいと思います。）
せめてある程度意味を持った単位でのDiffさえ自動で取れれば、誤りタグは説明者が決める、とかもできるのですが、といった悩みがここ数年あったりします。

土日とか暇な時間作って日本語用マージルール作ってみようと思ったこともあったんですけど、全然やらずに2年立ちそうなので。。。

訂正結果の説明タスク、いい感じなものが欲しい

GECって基本的に入力が誤り文で、出力が訂正文ですよね。
そして評価はシステムの訂正文と、リファレンスを評価する、といった形ですよね。
GECの学習者支援のお題目を考えると、「なぜその訂正になったのか」ってめちゃくちゃ知りたいとおもうんですよね、って話です。

形として1つありそうなのは、入力が誤り分と訂正文（リファレンスでもシステムでもどちらでもいいと思います）で、それとは別に文法が網羅されている辞書のようなものがあって、誤り文と訂正文をクエリとして、辞書から該当する文法事項をInfomation Retrievalする的なものとか。
GECやっていると思い付きがちな問題設定の1つだとは思うのですが、自分の知る限り聞いたことないんですよね。（自分のサーベイ力なんてたかが知れているので、すでにあるかもです）

GECの枠組みでこういった出力の説明、どのくらいできるのか知りたいなーと思って2年立ちました。。。

訂正結果の一貫性、保証する研究とかないでしょうか。。。

これはGECというよりは、校正支援的な要求が強いところですね。
サービスとして考えるとある程度、出力が一貫していると助かる的なやつです。
（ルールでやればいいとは思うんですが）

GECで使えそうな問題設定を考えてみると、学習支援の際に一貫性が薄いと嬉しくない、とかですよね。
たとえば、He has apple.に対して、He has an apple.にするのに、He has pen.はHe has pens.のような、単複の一貫性とかでしょうか。
なにも考えずにやるとおそらく学習データの分布から決定されるので、一貫しない形になると思います。
他にパッと思いつくもので、能動態、受動態だったり、類義語の使い方だったりなど（日本語だったら漢字をひらくかどうかとか）。
学習者の気持ちとしては、ある状況では能動態だけど、別の状況では受動態、とか言われても、混乱の元なのかなあとは思ってます。
ある程度はタグでコントロールできると思うんですけど、包括的な話になると難しい、、、はず。

マルチモーダル、はやると思うんですよね

こちらに関しては正直GEC云々ではないですし、校正支援でもないですね。
単純に自分の興味です。

昨日のGECアドベントカレンダーの記事とかかなりおもしろいと思いましたし、学習者支援と画像や音声はかなり色々できるような気がするんですよね。
たとえば、GECからは離れますが、Web言語学習者フォーラムで日本語学習をしたい人がいて、手元の教科書を使っていたら、読みがわからない単語について質問したいとします。
一番簡単なのはフォーラムにその教科書の該当部分の画像を乗っけて読みを聞くことだと思うのですが、需要として、既存のフォーラムの投稿から回答を得たい場合もあると思います。（俗に言うggrks精神）

つまり、入力として画像と質問文があって、それをもとに既存のフォーラム投稿をInformation Retrievalする的な形、色々できるのでは？とちょっと思ったりはしました（言語学習者向けのVQA？）。

おわりに

長々とGEC要望を垂れ流す記事となってしまい申し訳ないです。。。
自分が学生だったらちょっとやってみたかった感もあるのですが、社会人はちょっと厳しいのでここでお焚き上げさせていただきました（社会人D本当にすごいと思います）。

こういったGECアドベントカレンダーでの環境整備も進み（企画していただきありがとうございます）、次の年次大会でも自分の想像もつかないおもしろい話が聞けるのではないかと楽しみにしております。

最後までご覧下さりありがとうございました。

• 雑な記事を書ける場所を求めてブログを作成、公開してみた
• 構成はWordPress + Firebase Hosting
• ブログ作成に手間がかかるようだったらはてなブログとか検討しようと思ったが、めちゃくちゃ簡単だった話

なんでブログを作成したのか

ブログ、作ってみました。
これまで個人で何らかの記事を書くときはQiitaを利用させてもらっていたのですが、技術的な内容でないものを書きたくなったときに「Qiitaに自分の所感だけの記事を書くのもどうなんだ......？」みたいな葛藤が生じてしまい、書くのを止める、みたいなことを繰り返してきたんですよね。。。
なので、適当なことを書ける場所としてブログを作成してみた、という状況です。

このブログの構成

このブログは冒頭のまとめにある通り、「WordPress + Firebase Hosting」でやっています。
最初は、はてなブログ等の簡単にブログを作成できるサービスを使おうと思ったのですが、以下の理由で今回はちょっと頑張った構成でブログ公開を行っています。

1. はてなブログ自体は勤務先の技術ブログで触っているため、他の形態でのブログ運営を行ってみたかった
2. WordPressとFirebaseは一度は触ってみたかった

1番についてですが、はてなブログってめちゃくちゃ便利（個人の感想）なんですよね。
はてなブログで記事書いていて不便だなーと感じたことまったくないぐらい楽をさせてもらっている印象です。
あまりにも便利すぎたので、自分の逆張り精神が掻き立てられ、はてなブログ以外でブログ運営したくなっちゃいました。。。

2番の通り、今までWordPressとFirebase触ったことないんです。
WordPressが便利だー、みたいな話は聞いたことがあったので、ブログを開設するなら使ってみたいと昔から思っていて。
Firebaseの方は、ちょっと個人開発で使ってみたいなーとは思いつつ、なんとなく触ってこなかったんです。
一度どんな形でもいいから触っておけば、次も触るでしょう、というところで今回FirebaseのHostingサービスを使ってみました。

このブログの仕組み

このブログはこちらの記事を参考、というかほぼそのまま使用しています。

流れとしては次の通りです。

1. ローカル環境のWordPressでブログ作成
2. ブログをStaticにする
3. Firebase HostingでStaticファイルを公開

それぞれの詳細についてはリンク記事を参照していただければと思います。（2021/12/15段階では問題なく動きました）

細かい変更点

細かい点としては、Simply Staticと呼ばれるWordPressプラグインを使用して2番の処理を行うのですが、その際に「Staticファイルの出力先にアクセスできない」的なエラーが出るのでその辺りの対応を行ったぐらいですね。
とは言っても大したことはしていなくて、アクセス権限の問題だったので、chmodして対応しました。

ブログを作成した感想

はじめてのブログ開設、はじめてのWordPress、はじめてのFirebaseだったのですが、めちゃくちゃ簡単でした！
今回の場合は参考になる記事があったので、それをそのまま使えばよかった、というところがすごく大きかったですね。

Firebaseもだいぶ使いやすい印象ですね。
npmでFirebase CLIが入るので、それを使えば簡単にデプロイまで行くのでとても楽でした。
Herokuはちょっと触ったことがあるんですが、あれもCLIで色々できるんですよね。
Firebase CLIで何ができるのかちゃんと調べたわけではないのですが、リファレンスを眺めた感じだと色々できるような印象でした。

Firebaseの良いところとして料金体系もあるのかなと思います。
こちらのページにある通り、Firebaseは無料プランを用意してくれています。
Hostingの無料プランを見てみると「カスタムドメインとSSL」も入ってる！
Herokuとかってカスタムドメインを使うためには有料プランに入らないといけない（2021/12/15現在）ので、無料で独自ドメイン使うことができるのはとても良いと思いました。

ということで、無料で簡単に適当なことを書ける場所が作れて大変満足でした。
あとは定期的に記事を上げることができるかどうかですね。。。