\documentclass[japanese,other]{jnlp_3.8}
\usepackage{jnlpbbl_2.2}
\usepackage[dvipdfmx]{graphicx}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{url}
\usepackage{array}
\usepackage{hangcaption_jnlp}
\allowdisplaybreaks


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% author's definition
%%%%\usepackage{subfigure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\Volume{31}
\Number{3}
\Month{September}
\Year{2024}
%%%%\Issuetitle{「　　　　」特集号}

\setcounter{page}{1382}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\jsubject{学会記事}
\jtitle{Source Identification in Abstractive Summarization \& Characterizing the Confidence of Large Language Model-Based Automatic Evaluation Metrics}
\jauthor{数原　良彦\affiref{NVIDIA}}

\etitle{Source Identification in Abstractive Summarization \& Characterizing the Confidence of Large Language Model-Based Automatic Evaluation Metrics}
\eauthor{Yoshi Suhara\affiref{NVIDIA}}

\headauthor{数原}
\headtitle{Our Two Short Papers at EACL 2024}

\affilabel{NVIDIA}{NVIDIA，ただし本稿で紹介する論文は著者がGrammarly所属のときの成果である．}{NVIDIA}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{はじめに}

本稿ではEACL 2024に採択された2本のshort paperの紹介を通じて，論文に至った経緯と研究活動の一部を解説したい．
私は就職して以来15年以上一貫して企業の研究開発に携わってきた．また2014年からは米国に拠点を移したため，Grammarlyという急成長した米国スタートアップにおいて，研究開発と研究インターンシップがどのように進められたのかという点に重点を置いて解説できればと思う．

本稿ではまずそれぞれの論文について背景と着想，論文のポイントについて説明したのち，論文採択までの道のりについて述べ，最後にまとめる．論文を読まなくてもポイントを掴めるように簡単な概要は述べるが，興味ある方は論文を読んでいただくとして，技術的な内容は可能な限り要点に絞って裏話的な内容を多めに述べたいと思う．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Source Identification in Abstractive Summarization}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{背景と着想}
まず一本目の論文 \cite{suhara-alikaniotis-2024-source} は，私が2022年4月にGrammarlyに入社し，同僚で共著者のDimitris Alikaniotis （以下Dimi）と一番最初に取り組んだプロジェクトである．
$\beta$ 版として提供されていた（現在は終了）Grammarlyのメール要約機能の欠点として，要約の粒度が必ずしもユーザの期待にそぐわないというものがあった．たとえば箇条書きでメールの要点をまとめたところで，そもそものコンテキストをよく理解していないユーザにとっては不十分で，結局本文を読み直さなければいけない．{\bf このギャップは埋めねばならない．}

文をそのまま抜き出す抽出型要約とは異なり，現在の主流になっているニューラルモデルを用いた抽象型要約では，生成された要約が元文書のどの部分を利用して作られているかが明らかではなく，生成要約の元となる情報を元文書の中から見つけることは自明ではない．そのような要約と元文書のギャップをどのように埋めるかということについて考えた．

そんなことを考えながら，せっかく面白い問題なのでNLP的な問題に定式化してデータセットを作ってきちんと解いてみてはどうかと考えた．具体的には，要約モデル，元文書，生成要約が与えられた際に，元文書の中から要約作成に用いられたソース文を見つける {\bf Source Sentence Detection} というタスクとして定式化した．
要約文からソース文を見つけるという問題が全く研究されていなかったわけではない．文類似度やアテンション重みを使う方法など，いくつかの手法は開発されていた．それらを同じ土俵に乗せて定量評価可能にしたかったので，このような定式化を行い，SourceSum\footnote{\url{https://github.com/suhara/sourcesum}}というベンチマークを作成した．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{論文のポイント}
作成したSourceSumは，要約研究でよく用いられているCNN/DMとXSumのふたつのデータセットをもとに，元文書の各文に対して生成要約に寄与したかどうかをアノテーションとして付与したデータセットである．生成要約と参照要約の比較を行うため，参照要約についても同様のアノテーションを行った．
また，データセット品質担保のため，そもそも生成要約（または参照要約）が，元文書から構築可能なのかというの要約の構築可能性判定も行った．
%%%%図\ref{fig:sourcesum}にアノテーションの流れを示す．
    図\ref{fig:figure}(a)にアノテーションの流れを示す．

要約の構築可能性判定では面白い知見が得られた．CNN/DMとXSumははそれぞれCNN，BBCのニュース記事のまとめ文やニュースヘッドラインが参照要約として用いられているため，そもそもニュース記事本文に存在しない情報が要約として使われている可能性があった．この問題については要約研究コミュニティではすでに知られていたものの，私の知る限りどれほどの参照要約が元文書から構築可能なのかという定量評価はされていなかった．SourceSumアノテーションの結果，なんとXSumデータセットの参照要約の実に51.7\% （CCN/DMでは8.2\%）が元文書から構築できないという判定結果が得られた．これはすなわち，XSumデータセットにおいては{\bf 厳密な意味での要約の範疇を超え，入力文書以外の知識に基づくニュースヘッドライン作成というタスクを解いていた}ことが示唆されて興味深い．

SourceSumに関してはアノテーション品質の高さをアピールしておきたい．これについてはアノテーションタスクを取りまとめてくれた元同僚のJennifer Bellik （以下Jenny）の仕事の質の高さのおかげである．Grammarlyでは言語学者 (PhD in Linguistics) が多数所属しており，アノテーションタスク設計と検証を通じたアノテーション品質管理が徹底されていた．私はMechanical TurkやAppen\footnote{CrowdFlowerやFigureEightと呼ばれていた頃から使っていた．}などを使って人手評価やコーパスづくりをしたことはあるが，パイロットタスクを行って，ある程度のinter-annotator agreementが確認できたらよしとしていた．
Grammarlyでは，Jennyのような言語学者たちによって何段階も高いレベルでのアノテーションタスク設計と品質管理が行われており，言語学者の強いこだわりとプロフェッショナリズムを垣間見て，大変勉強になった．ちなみに言語学者たちはしばしば言語学用語を使ったり難しい言い回しをするので，英語が母語でない言語学者でもない私は会話をするのにかなり苦労した．

Source Sentence Detectionタスクのために，本論文ではPerplexity Gainと呼ばれるモデルベースの手法を開発した．アイディアはシンプルで，元文書の対象文を取り除いたときに，同じ要約モデルを用いて生成要約の対数尤度がどれほど低くなるか（すなわち perplexity が大きくなるか）という方法で文の要約に対する貢献を評価するというものである．SourceSumを用いた評価結果では，要約がほとんどそのまま入力文書にそのまま現れる抽出型に近いCNN/DMにおいては単純な文類似度比較手法の方がソース文検出精度が高かったが，抽象度が高いXSumではPerplexity Gainが高精度を示し，有効性を確認した．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% fig. 1
\begin{figure}[t]
\begin{center}
\includegraphics{31-3ia22f1.pdf}
\end{center}
%%%%\label{fig:sourcesum}
%%%%\label{fig:tradeoff}
\hangcaption{(a) SourceSumアノテーションの流れ．要約モデルによって生成された要約について，元文書の各文について要約構築に寄与したかどうかを人手で判定を行い，最後に要約が元文書から構築可能かという判定を行った． (b) 2つのモデルの性能差 (ACU) が異なる場合について，LLM-as-a-Judgeの性能（人手評価との相関係数）と95\%信頼区間で正しく判定するために必要なサンプル数のグラフ．}
\label{fig:figure}      
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Characterizing the Confidence of Large Language Model-Based Automatic Evaluation Metrics}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{背景と着想}
2本目の論文\cite{stureborg-etal-2024-characterizing}は2023年夏期インターン生である Rickard Stureborg （以下Rich）とDimiとの仕事で，Richのインターンプロジェクトのサブ論文である．
最近ではMT-Benchに代表されるように，モデルの評価にLLMを用いることが一般的になりつつある．従来ではリファレンス出力までを人手で作成し，リファレンスベースの評価指標（古くはROUGE，BLEU，最近ではBERTScoreのようなモデルベースの手法）が用いられてきたが，リファレンス出力を用意せず，タスクに合ったプロンプト集合をベンチマークとして，モデル出力の良し悪しをLLMに判定させるというものだ．
このようなLLMを用いた評価手法はLLM-as-a-Judgeとも呼ばれ，評価対象のプロンプト集合があればGPT-4などのAPIを呼び出すだけで実行できる手軽さから徐々に広まっている．以下，LLMを用いた自動評価のことをLLM-as-a-Judgeと呼ぶ．


ただ，このようなLLM-as-a-Judgeはあくまで一次評価目的であって，MT-Benchなどの自動評価結果に比べて，たとえばChatbot Arenaのような人手判定結果が重視されているように\footnote{この点についてはAndrej Karpathy氏の ``I pretty much only trust two LLM evals right now: Chatbot Arena and r/LocalLlama comments section''(\url{https://x.com/karpathy/status/1737544497016578453})というコメントに同意である．}，人手評価を完全に置き換えることは（すぐには）ないと思われる．ちなみにLLM-as-a-Judgeはモデル由来のバイアスや出力が安定しないことが知られており，注意深く使用しなければならない．これについてはRichのインターンプロジェクトのメイン論文にまとめてあるので，興味がある方はご覧いただきたい \cite{stureborg2024large}．


LLM-as-a-Judgeの研究は2022年末のChatGPT公開後に一気に広がりはじめ，2023年初めからarXiv論文も徐々に増えてきたものの，2023年春の時点ではまだ自分自身で現場に応用できるほどの知見が集まっていなかった．
また，Grammarlyの視点からも重要なトピックであった．高品質なアノテーションはプロダクト品質には重要である一方で時間・費用のコストもかかるため「人手アノテーションをどこまでLLMアノテーションに置き換えることができるのか？」ということは重要なリサーチクエスチョンであった．
そのような背景もあり，LLM-as-a-Judgeに関するテーマを立ち上げ，2023年夏期インターンのテーマとして，LLM-as-a-Judgeの挙動を分析し，よりよい手法の開発を検討することにした．


既存研究では基本的に，LLM-as-a-Judgeのスコアと人手スコアの相関係数の高さで手法の優劣を競っていた．手法比較という意味では数値評価がある方がわかりやすいのだが，インターンを進めていくうちに「そもそもLLM-as-a-Judgeと人手評価との相関係数が0.42と言われて，それがどの程度有用なのか．相関係数が0.29の手法よりもどの程度信頼できるのか？」という至極単純な質問に既存研究が答えていないこと，自分たちでも答えられないことに気がついた．
言い方を変えれば，LLM-as-a-Judge研究で用いられている性能評価が実応用における評価に直結していないわけである．{\bf このギャップは埋めねばならない．}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{論文のポイント}
そんなわけで2つのモデル（例えば要約モデル）の評価をLLM-as-a-Judgeを用いて行った場合に，どの程度正しく判定できるか，という問いをシミュレーションによって経験的に検証したのが本論文である．
具体的には，2つのモデルの真の性能差 $X$ ，相関係数 $Y$，評価サンプル数 $N$ が与えられた際に，モンテカルロ法を用いて実際に2つのモデルの差を正しく判定できるかというシミュレーションを行った．実験にはSAMSumデータセットを用いて，モデルの真の性能差の推定には Atomic Content Unit (ACU) を使った．これらに基づいて2つの要約モデルの比較評価を，LLM-as-a-Judgeを用いてどの程度正しく行えるのか，というものである．


%%%%実験結果のひとつを図\ref{fig:tradeoff}に示す．
    実験結果のひとつを図\ref{fig:figure}(b)に示す．
このグラフから，たとえLLM-as-a-Judgeの性能（すなわち人手評価との相関係数）が低くとも，評価サンプル数を増やすことで，2つのモデルの差を正しく判定できることをシミュレーションによって示した．別の言い方をすれば，ACUの差で計測される2つのモデルの性能差がある程度以上大きい場合には，{\bf 性能は高いがコストも高いLLMを，性能は低いがコストも安いLLMで代替できるということを示唆している．}

言われてみれば至極当たり前のことではあるが，シミュレーションとはいえ経験的に示し，知見として共有できたのはよかったのではないかと思う．
余談だが最近では小規模ながら高い性能を持っているphi-3を用いたLLM-as-a-Judgeの研究\cite{deshwal2024phudge}も出てきたりもしているので，今後は小規模言語モデル (SLM) を用いたLLM-as-a-Judgeの研究が発展していくかもしれない．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{ふりかえり}

2つの論文は論文採択に至った経緯からすると正反対の2本である．1本目はGrammarly入社直後に始め，着想から採択まで約2年かかった一方で，もう一本は着想から投稿まで1か月もなく一気に書き上げてそのまま採択に至った．


1本目の論文については最初の投稿でリジェクトされた後に，他の仕事で論文執筆および追加実験論文が遅れに遅れているうちにChatGPTが発表され，あっという間にLLM全盛の時代が到来してしまった．
本論文はもう採択されることはないだろうと思っていたところ，なんとかEACL採択にこぎつけた．最近は論文が旬である時期の短期化が加速度的に進んでいて，現在2年以上はおろか，1年という単位でも中長期的な研究テーマを立ち上げることが難しいと感じている．
当時GPT-3は研究コミュニティにはそれなりに使われていたものの，まだBARTやT5のようなencoder-decoderモデルが文書要約の主流であったため，当時の抽象型要約モデルの強いベースラインとされていたPEGASUSを使ったが，論文が出版される頃には，右も左もLLMになっていた．なお本論文で開発したPerplexity GainはLLMで用いられるdecoder-onlyモデルにそのまま適用可能であるが，この論文のようなスタイルの研究は主流モデルアーキテクチャの変遷の影響をそのまま受けるリスクがある．
自分なりには地に足をつけた研究であり，正攻法的なアプローチで進めてみたが，LLM全盛期で現在の技術進歩のスピードを考えると，アイディア $\to$ データセット作成 $\to$ 実験 $\to$ プロダクト化という従来の研究開発のパターンが，プロダクト開発のスピード，論文化のスピード双方の面から，かなり難しくなっていると感じている．


2つ目の論文は着想から世にでるまでのスピードという意味では1本目とは対照的であった．ただインターンプロジェクトのメイン論文が採択に至っていないので，そういう意味では紆余曲折があったと言えるだろう．
Richが東海岸を拠点としていたため，時差のあるリモートインターンであった．Richと面と向かって直接議論をできたのは，インターン期間のうち最初と最後の1週間だけであった．そのため試行錯誤が少なくても成果につながるような手離れの良いトピックを選ぶようにしたが，メインプロジェクトがなかなかうまく進まない中，上述の埋めねばならないギャップに気づき，Richが1週間もかけずに基本実験を終えたため，こちらも論文にしようということになった．
この論文についてもすぐに採択されたからよかったものの，査読者ウケが分かれる内容だと思っていたのでお蔵入りの可能性も十分にあった．

なお，いずれの論文も私がGrammarly退職後に採択されており，自分で勝手にGrammarly卒業論文と呼んでおり，思い入れの深い論文である．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{おわりに}

「どんな研究をしているんですか？」と聞かれるたびにいつも答えに困っている．自分の発表論文リストを眺めると，国際会議，ジャーナル分布のエントロピーが非常に高い（いちおうNLPが多め）．研究者としては軸足に欠けてよくないのかもしれないが，技術者としては目の前の問題に対して，重要な問いに答えられるか，役に立つものを作れるか，というようなことを考える，{\bf ギャップを埋めねばおじさん}として一貫して仕事を続けてこれたのではないかと思う．LLM全盛の時代になって産業応用と研究の境目がどんどん曖昧になり，これまで研究フェーズの対象になっていた領域が産業応用のフェーズでも盛んに行われるようになってきた．最近は技術進歩のスピードが目覚ましく，ただ最新の技術動向についていくだけで精一杯であるが，これからも体力と気力の続く限りは目の前のギャップを埋め続け，何かしら世の中に役立つものに貢献したいと思う．

なお，仕事の都合上EACLに現地参加できず，マルタ島に行けなかったのは痛恨の極みだった．その期間，マルタ島に関する楽しそうな情報に触れないようにソーシャルメディアを避けていた．マルタ島でラーメンを食べることを引退後の楽しみにしている．なかなか日本に帰国したり学会に参加する機会がないので，もしサンタクララ近くにお越しの際にはぜひ遊びに来ていただきたい．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibliographystyle{jnlpbbl_1.7}
\bibliography{22refs}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{biography}

\bioauthor{数原　良彦}{%
2006年慶應義塾大学理工学部管理工学科卒業，2008年慶應義塾大学\linebreak
大学院理工学研究科博士前期課程修了，日本電信電話株式会社研究員，株式会社リクルートホールディングス研究員，MIT Media Lab, Visiting Scientist，Megagon Labs, Senior Research Scientist，Gramamrly, Applied Research Scientistを経て現在NVIDIA, Applied Research Manager．博士（工学）．小さなものから大きなものまで幅広く大規模言語モデルの研究開発に従事．ギャップを埋めねばおじさん．
}

\end{biography}


\end{document}



