何となく新しいことを取り入れる
これまたポエム。最近の情報収集は、基本SNSで行っているか以下のサービスを利用している。
Xやdiscordなどの様々なサービスで話題になったAIを要約して必要があれば登録したメールにほぼ毎日送ってくれるサービスである。
勿論それで全てを取得できるわけではないが、世界の動向を知るには十分である。
GW終わって
何となく、一つのことに集中しすぎていたなと思い、散歩や食事のためのスペースを作るなど、新しいことを取り入れている。
これが何の効果があるのか、と言うと自分でもよくわかっていない。
ただ、最近視野が狭くなっている気がしていた。ふと、休みの間和えて何もせずに過ごしていたら気付いた。
意外と集中しているからと言って物事が進むことはない。どちらかというと集中はやるべきことを進めるために必要なのであって、それらが具体的に決まっていないと
集中しても無駄だったりする。
ブロクを書くときだって、ブログの内容を決めるまでは手の動かしようがない。決まったら集中して手を動かせば良い。
しかも最近は、その作業自体をAIが代替してくれるので、人間が集中して取り組むタスクは徐々に減っていっている。
よく聞く話として、リラックスしているとアイデアが思いつくというのがある。
今はそれを欲している時期なのだが、思いつかない。
まあこればっかりは、当たりくじみたいなものなので、常に頭の隅に起きつつ、生まれるのを待つしか無い。
AIを使っても、その辺りのアイデアは意外と納得できるような結果は出ていない。
データの中から尤もらしいことを言うだけなので、その視点は無かったというのはあっても、0から生み出す何かというのは厳しいのかもしれない。
ただ組み合わせる力は人間よりは遥かに上手い。大量のデータを使えるのだし、疲れない。
今はまだ、既存のアイデアに被っている、同じような出力しかされない、などの課題はあるものの、いつかは人間よりも速く多いアイデアを出してくれるかもしれない。
その時までまだ人間ができることはそれなりに残されているだろうと思っている。
というポエム。
AIさんに聞けばすべて解決する時代
そのうち人が人に聞く必要がなくなる
最近のAIの進化は凄まじく、最早使っていない人は殆どいないのではないかと言えるぐらいにAIという言葉を見聞きする。
ITに対して大して詳しくない身内ですら、「AIって凄いんでしょ」という話をしてくる始末だ。
今では、人間がこれまで行ってきた多くの作業を代替するサービスが提案され始めている。
例えば、あるシステムの開発に関する修正とレビューリクエスト、レビューなどの一連の作業を自動で行ってくれる。
人間が行うことといえば、AIの成果物をチェックして問題ないかを確認するぐらいだろう。
現在のAIは確率的な振る舞い (その時に尤もらしい物を出している）を行うので、成果物の内容にはバラツキがある。
"人間にとっては" 相応しくない内容が出てくる可能性がある。特に、タスクの範囲が限定的であればあるほど。
例えば、日本の文化を考慮した成果物を出したい場合は、日本の文化がわかるデータを用意しておく必要がある。
これは別に今に始まったことではなく、AIが元々大量かつ質の高いデータから特徴を抽出してタスクを行うため、データはいつになっても必要なのである。
AI自体は、どんどん性能が高まっており少ないデータでも精度が出せるようになってきている。
それでも、0で良いわけではない気がしている。少なくとも、多少のデータは必要であるだろう。
またローカルルールになればなるほど、そのローカルの文化を正確に反映させるためのデータを作る必要はある。
現在人間がやるべきタスクの一つとしては、AIにとって読み込ませやすいデータを作っておくことだろう。
所謂MarkdownなどのAIが読み取りやすい構造化されたドキュメントを用意しておけば、いつかそれが活用されるようになるだろう。
現在のAIはテキストが主流である。
当分もテキストが主流であると思われる。少なくとも大きくアルゴリズムが変わらない限りは。
音声や図などもあるじゃないか、と言うが現在それらは一旦テキストに変換して、AIに認識させる仕組みが主流だ。
つまり、図や音声などもテキストに変換される。
勿論、テキストと比べるとそれらの内容の精度は低くなるのだが、時間の問題な気もする。
なので、そのうちテキストを打ち込むだけでは説明できない何かもうまく変換してくれて、AIが使いやすいデータにしてくれるのではないだろうか。
そもそも人間が言語化できない何かを汲み取ってくれる、あるいは補完してくれるようなAIも出てくるのかもしれない。
そのうち、ある人が分からないことをある人に質問することは一切なくなるかもしれない。今だって既に人に聞くよりAIに聞くことが多い。
最近だと、AIに聞いて生成された内容を全く精査せずに使う人もいるらしい。
先程も述べた通り、AIは確率的な振る舞いをしそれらしい内容を出しているだけである。
少なくとも今はまだ、盲目に信じるのは良くない。と言いたいところだが、昔からネットの内容を信じてしまうという事例はいくつも確認した。
何なら今だって、そのように真偽不明の情報に踊らされているのを確認する。
別にAIに限った話ではなく、昔から確認せずに信じてしまうという人は一定数いるのだろう。
とは言ってもAIは所詮ツールである
しかし、AIは所詮ツールである。
ハードウェアに依存している以上、ハードウェアが無ければ動かない。
人間が身体が無いと存在できないように。
AIもまた、身体と呼べるものが無ければ動かないのだ。別に神でもなんでもない。
所謂「使えるなー」と言われている物は、基本相当な計算スペックが必要になっている。
最近、少ない計算スペックでも動かせる (この動かすには主に学習、推論が当てはまる) 技術やモデルが出てきており、かつてHDDが512MBで凄いと言われていた時代から
現在のように1TBは当たり前、になったように徐々に低スペックでもそれなりに動かせるようになってきている。
まだまだスピードや容量の問題はあるが、徐々に "小型化" していくのだろう。
それでも全くハードウェアがいらないということは無い。
何なら小型化したからと言って、ハイスペックのハードウェアが必要ではないということはない。
上限が見つからない限り、上を求めるために隈なく使われるだろう。
ある程度このAIの性能の発展が落ち着いたら、この資源というのが問題になるのだろう。
今もGPUを巡って、あれこれ問題が起きているように見えるため、もしかすると既になっているかもしれない。
AIの発展が落ち着いた頃に、もしかするとAIが「解決策」を見つけてくれるのかもしれない。
更にはAIが勝手に実行までしてくれるかもしれない。
しかし、飽くまでAIは人間のツールであり、人間が最終的に取捨選択をする必要がある。
資源が有限である以上、恐らく避けることはできないのではないか。
なんて、思ったり思わなかったりし、最終地点を見失ったのであった。
A Survey on LLM-as-a-Judge
論文の解説です。最近２月にアップデートされていたみたいなので、改めて読み直しました。
LLM-as-a-Judgeとは
- 人間の評価を大規模言語モデル (LLM) に行わせようという考え方
- LLMに成果物の「レビュー」させる等が当てはまる
- LLMの出力は最終評価。すなわちスコア、選択肢、文章などである
- 「要約の正確性は65/100」
- 「question: AとB、どちらが良いか。Answer:A」
- 「誤字が見られます。〇〇と修正してください」
- 期待されること
- 評価者の作業負荷や労力を減らし、疲労による信頼性や精度の低下を防ぐ
- 評価者ごとの答えのバラツキを軽減でき、客観性を高める
- 専門家など一部の人間しか出来ない評価に対応できる
- LLMの性能向上、サービスの品質改善に応用可能
LLM-as-a-Judgeを構成するアプローチ方法
以下の4つの段階で評価が行われる。
In-Context Learning
- 入力データとプロンプトを入れて、プロンプト内で評価の設計をする。
- スコアの生成：「要約の正確性、有効性を0-100の間で判断して」
- Yes/Noの判定：「入力データの修正は必要か？"Yes" or "No" で答えて」
- 一対比較法：「AとBのデータ、どちらの要約が良い？」
- 1対1で評価を続け、全てのデータの比較結果を出して評価する手法
- A,B,Cがあったら(A,B), (B,C), (A,C) で比較し、A>B>Cのように相対的なランク付けを行う
- 多肢選択式の評価：「要約データと、幾つかの単語がある。要約データに関係する単語の番号を返して」
モデル選択
- GPT-4のような高度な言語モデルを採用することが１つの効果的なアプローチ
- LLM-as-a-Judge法の有効性はLLMの性能に依存する
- 但しプライバシー漏洩や、APIモデルの不透明性が評価の再現性の課題となりうる
- 外部APIが使えない場合は、評価に特化したfine-tuningモデルの利用がある
- 但し、評価能力には限界がある
Post-Processing
- 出力の体裁にバラツキがあるため、必要な情報を取るための工夫をする
- 「修正必要ですか？」→「yes」「必要あります」「結論：必要」など同じ質問でも回答の文章がばらつく
- プロンプトで出力の体裁を指示したり、幾つか出力の例を提示することで対応
- JSONなど決まった形式で出力をする
- 構文的に有効な出力を保証する一方で、出力品質を劣化させる可能性もある
- "yes" or "No" の場合、その単語が出る確率を取り出す
- 文章や段落として抽出し、再度エージェントに質問やアクションをさせることで最終的に評価しやすい出力を得やすくなる
Evaluation Pipeline
LLM-as-a-Judgeは以下の４つのシナリオで使われる。
- モデルの性能評価
- データアノテーションの自動化
- エージェントとしてタスクの全プロセスの評価、もしくは特定の段階で評価
- 推論/思考のための評価
Quick Practice
LLM-as-a-judgeの実践のプロセスは４つの段階がある
- ユーザーが何を評価するか特定、人間が通常どのように評価するか把握し、信頼できる評価例から基準を定義するための思考
- プロンプトデザイン (単語やフォーマットを整える)
- 信頼性の高い評価をするための強力な推論能力と指示追従能力を持つモデルを選択
- 評価プロセスの標準化
Improvement Strategy
LLMを使って評価する場合、バイアスを対処することで評価結果の劣化を低減する必要がある。
以下の３つの戦略がある。
評価プロンプトの設計戦略
評価タスクを理解し、評価結果を生成するの助けるような最適なプロンプトを方法が評価性能を向上させる最も直接的で効果的な方法。
- few-shotプロンプトを取り入れる
- 評価タスクのステップと評価基準を細かく分解し設定する
出力形式の最適化
LLM評価機に直接評価結果を出力することを要求すると、ロバスト性に問題が生じる。
例えば、スコアで出すように求めている時に「関連性の低い」文章を出力するなど、LLM特有のランダム性により、応答テキストが変化する可能性がある。
対応として以下の通り。
- プロンプト内で出力形式を構造化された形式で制約する
また、出力結果を直接だすことは解釈可能性の欠如につながる。そのため
- 結果だけではなく根拠も出力するようにする
LLMの能力向上戦略
プロンプト設計は効果があるものの、GTP-4のような最先端のLLMでさえ、プロンプトの指示の概念を混乱して認識することがある。
その場合は、以下のような対応がある。
- メタ評価データセットを通じてLLMをfine-tuningする
- 評価結果のフィードバックに基づいてモデルを反復的に最適化する
メタ評価データセットによるfine-tuning
LLMの特定の評価プロンプトに対する理解と評価性能を向上させ、潜在的なバイアスを対処するのに役に立つ。
この方法の重要なステップは、学習データの収集と構築である。
一般的な手法としては、
評価結果のフィードバックに基づく反復最適化
メタ評価データセットでLLMをfine-tuningすることで人間の嗜好に沿った評価を生成する能力を得ることが出来る。
但し、実際の評価プロセスにおいてバイアスが入る可能性があり、全体的な評価品質に影響を与える可能性がある。
この対応としては、以下の通り。
- 評価結果のフィードバックに基づいてモデルを繰り返し最適化する
性能の高いモデルか人間による直接の修正を行う。
最終結果の最適化戦略
In-Context Learning とモデルの性能に基づく最適化による、LLMは評価タスクの要件を理解し、合理的な評価結果を行うことができる。
但し、LLMのランダム性は依然として評価結果の不安定さをもたらし、評価品質に影響を与える。
そのため、後処理の段階で最適化戦略が必要。その最適化戦略は以下の3つ。
- 複数の評価結果の統合
- LLMの出力の直接最適化
- 点評価から一対比較への評価タスクの変換
複数評価結果の統合
- 異なるパラメータと設定を持つモデルで、同じコンテンツを複数回評価しそれらを要約する
- 複数の結果を平均化することで、出力のランダム性による影響を軽減
LLMの出力の直接最適化
単一のLLMでスコア出力を行う場合
- スコアを出したときのトークン確率と明示的な出力スコアを出す
但し、上記の手法は、モデルがオープンソースであること、トークン確率へのアクセスが出来るようなインターフェースを提供する必要があり、適応できるモデルに限りがある。
そのため、どのモデルでも出来る手法として自己検証がある。
- 評価結果の確実性を尋ね、自己検証に合格にした結果のみを保持する
これら２つの方法は相反する方法ではなく、組み合わせることでより安定した評価結果も得られる可能性がある。
LLM評価者の評価
LLM-as-a-judgeの主な目的は、人間の評価との整合性を達成することである。
LLMを仮想アノテーターとみなし、人間のアノテーターとの一致度を評価する。
分類問題として扱う場合もあり、人間の注釈をラベルとして機能させ、precision, recall, F1スコアを計算する。
Bias
Position Bias
LLMがプロンプト内の特定の位置の回答を好む傾向のことを指す。
選択肢を並べた時に、質問の内容にかかわらず最初の選択を正解として出力するなど。
Length Bias
冗長な回答を好む傾向ことを指す。無駄な文章を出力し、回答が長くなってしまう。例えば要約タスクに、必要のない情報が入ってきてしまい、出力の品質を劣化させてしまう。
Self-Enhancement Bias
LLMが自分自身で生成された応答を好むという現象。あるタスクを行うモデルと、その結果を評価するモデルが一緒の場合、客観的に評価されない場合がある。
Other Bias
- Diversity Bias: 性別、人種などの特定の集団のバイアス
- 視覚的なコンテンツへのバイアス：絵文字とかを好む
- 具体的バイアス：引用・数値などの特定な詳細の情報を好む
敵対的ロバスト性
注意深く作られた入力によってスコアを意図的に操作しようという試みに耐えるモデルの性能のことを言う。
ロバスト性が不十分の場合、些細な操作でLLMの評価を欺き、品質の評価を損なう可能性につながる。
特に高リスクのアプリケーションに対して、性格で信頼性の高い評価を維持するためには、LLMの評価をロバストにしておく必要がある。
有効性の実験
LLMEval と呼ばれるベンチマークを用いて、人間の評価との整合性をチェック。
また、EVALBIASBENCH を用いて6種類のバイアスを測定した。
結果としては、GPT-4は他のLLMと比べると、評価の整合性を上回り、バイアスも少ない。
追加検証として、より高い推論能力を持つ、gemini、o1-mini、deepseek r1にも行った。GPT-4と比べると同等の性能を出しているが、改善という点では期待された結果をではない。
異なる戦略での比較
表4では、GPT-3.5-turboの評価性能を向上させるための戦略ごとの結果を示している。
- 説明付き：結果の理由をつけさせることで解釈可能性を提供させる試み。しかし、性能・バイアスの観点では劣化させている。
- 多数決：繰り返し評価を行い、その後多数決を取る選択。ランダム性を軽減、バイアスの問題に対処できる。
- 複数LLMの評価：セット1とセット2で評価
- セット１：GPT-4-turbo, GPT-3.5-turbo, LLMA3-8B-Instruct
- セット２：GPT-4-turbo, GPT-3.5-turbo, Qwen2.5-7B-Instruct
- セット1は、GPT-3.5とLlama3が出力のLength Biasにより、全体的に性能が低下。
- セット2は、性能向上。幾つかのバイアスの軽減も見られた。
- 複数のLLMを採用する時は、各評価性能の違いを考慮する必要がある
LLM-as-a-judgeとO1-like推論の強化
o1は、複雑なタスクを解決するために段階的に思考を行う。
このo1の推論を強化するには、推論時の各段階で評価させることである。
o1が問題に取り組み際に、適宜別のLLMが評価し、フィードバックを提供することで、モデルの性能を改善させる。
この過程でReasoning/Thinkingの療法を評価する２つの方法がある。
- 学習段階で推論プロセスを評価し、フィードバックを与えて強化学習を通じて推論能力を向上させる
- テスト時にLLM-as-a-Judgeがモデルの出力を評価し、リアルタイムフィードバックを与える
アプリケーションの応用
機械学習
- 要約、ストーリー作成などテキスト生成タスクは、「唯一」の正解はない。LLM-as-a-judgeによって、人間と同様に評価させることが可能。
- 最近では、LLMによる自律的な議論の中で、生成された応答を評価するマルチエージェント討論フレームワークなどがある。
- 推論：近年はChain-of-Thoughtなどの段階的な推論を行うモデルがあるが、推論経路が正しいのか判断が難しい。LLM-as-a-judgeでこれらを評価する。
- 検索：従来型のランキング形式の検索と、RAGアプローチの両方でLLMの評価を行う手法がある。
- ランキング結果をLLMに判定してもらい、検索結果の精度を高める
- RAGでは、どの外部知識を選択・評価するかをLLMが自己評価で行う仕組みが研究されている
社会的知性
- 文化的価値観、倫理原則、社会的絵強を含む複雑な社会的シナリオをナビゲートする
マルチモーダル
- テキストや視覚モダリティを超えて機能するLLMベースのシステムを評価するベンチマークが作成されている
その他の特定領域
- 金融：金融領域の予測、異常検知、パーソナライズドテキスト生成などのタスクへの可能性を見出している
- 法律：法律相談のうような専門的分野で助言を提供し、テキスト要約・法的推論のようなタスクに優れている。しかし、他分野に比べるとバイアスや事実の不正確さをより懸念しなくてはならない。
- 法的な用途に特化したLLMの評価者の作成
- 法的シナリオにおけるLLMの適応性を評価するためのベンチマークの作成
- 科学：科学分野、特に医学的な質問応答や数学的推論のような分野で、精度と一貫性を向上させる評価者の役割を果たすことに可能性を見出している
- その他
- ソフトウェア工学：バク報告の要約を評価するためにLLMを利用し、正確性と完全性の評価において高い精度を示し、疲弊した人間者の評価をも凌駕している。
- 教育：小論文の自動採点と改訂が検討されている。few-shotやプロンプトチューニングによって、採点精度を向上させ、改訂は元の意味を損なうことなく、エッセイの質を効果的に向上させた。
- コンテンツの修正：Redditのようなプラットフォームのルール違反を特定するためにLLMを利用。高い真陰性率を達成したが、複雑なケースの場合は人間の監視が必要とのこと。
- 行動科学：ペルソナに基づくユーザーの嗜好を評価するためのフレームワークの作成。ペルソナを単純化しすぎると、信頼性と一貫性に限界があることが分かった。しかし、言語による不確実性推定によって大幅に改善され、不確実性なユースケースの場合、人間の評価と高い一致を達成。
- サービス品質の評価、ユーザー体験のフィードバック分析、アートや文献レビューのような創造的なコンテンツ評価など、定量化が困難な質的評価に置いて大きな優位性を示す。
- つまり、従来人間の判断を必要とする主観的な評価タスクにてキスしている。
課題
信頼性
- 人間とLLMの評価は共に偏りを示しており、評価の一貫性と公平性に懸念
- 人間には固有のバイアスがあり、信頼できない回答さえある
- LLMは確率的モデルであることから、位置バイアスなどの偏りがある
- Overconfidence: Instruct-tuningされたLLMは、自身の応答を評価する際に、過度に好ましいスコアを提供する傾向がある。
- 公平性と一般性：文脈によっては、同じ入力でもLLM-as-a-judgeの結果に矛盾が生じる。与えるプロンプトによっては、公平性や汎化性を失うこともある。
- few-shotにおける例の提示位置
- 長いコンテキストを与えることによる性能低下
ロバスト性
- LLM-as-a-judgeに対する攻撃の研究は比較的未開拓である。つまりリスクは未知数。
- 攻撃の目的は「有害・不正確な出力を生成するようにミスリード」すること。
- 例えば入力の言い回しをかえることで、判断に大きな乖離が生じる可能性がある
- これによりアプリケーションの信頼性低下が懸念される
- 応答のフィルタリング、一貫性チェックなど出力に対する後処理が一般的
- 但し、同じ入力を複数回評価すると、しばしば矛盾した出力を生成したり、スコアリングがランダムになったりする課題も残されている
強力なバックボーンモデル
- テキストベースは優れた性能を示しているものの、マルチモーダルコンテンツの信頼できる評価器はまだ欠けている
FUTURE WORK
LLM-as-a-judge異ステムは、幅広い専門領域において、人の判断を支援したり、それらを取って代わったりする可能性を示す。
LLMの高度なデータ処理とパターン認識能力で、複雑なシナリオを評価、査定、裁定するタスクをサポートする。
図16のように、LLMは多様な分野で汎用性の高い評価器として機能する。
(例：医師がLLMを使って、医療記録や画像データを処理することで、状態を診断し、結果を予測することができる)
LLMはスケーラブルで柔軟な評価に優れているが、限界がある。
これらの限界に対処しながら、新たなアプリケーションを模索し、システムの信頼性、公平性、適応性を向上させることに焦点を当てて、社会的価値観や専門的基準との整合性を確保する必要がある。
図15のように、GPT-4の登場により評価手法の開発は大きく進み、フィードバックによってモデルが自分で改善していく自己進化基盤を可能にした。
最終的には信頼性の高いLLM-as-a-Judgeを確立することで、現実世界のシミュレーションをよりリアルかつ広範に信頼できるものにすることが可能になる。
AIはこのアプローチを利用しして、自己進化を達成し、AGIのスケーリングを促進出来る可能性がある。
More Reliable LLM-as-a-Judge
適応性やロバスト性などの多くの課題が未解決である。
In-Context Learning, モデル選択、後処理技術、LLM-as-a-Judgeの総合評価フレームワークなど、様々な側面で信頼性を向上させる必要がある。
そのためには、信頼性・ロバスト性を評価するための方法論を開発する必要がある。
また、ロバスト性に関するリスクが不確実かつ進化し続ける性質を持つことは、リスクを未然に防ぐための対策が必要。
- 判断タスク用の攻撃入力に対応するための学習技術の開発
- 不確実性定量化手法の統合
- 重要な意思決定を人間が監督するヒューマンインザ・ループシステムの導入
データアノテーションに対するLLM-as-a-Judge
LLMに「情報源の忠実さ」「正しさ」「有用性」のような指標で評価してもらう時に、学習データから学習した意味的関係が評価に依存する。
データアノテーションは、幅広い応用性があるにも関わらず、データの複雑さ、主観性、多様性のために行うのが大変という大きな課題になっている。
特に大規模なデータセットを手作業でラベルづけする場合、ドメインの専門知識を必要とし、リソースを大量消費する。
GPT-4, Gemini, LLaVAなどはデータアノテーションの有効性と精度を向上させるうえで、重要である。
などがある。
研究分野・産業界ともにデータが足りない、質が十分でないという課題がある。
データ拡張のシナリオだと、LLMを使ってデータを注釈するということができる。
データ品質が低いシナリオだと、LLMによってデータの品質を評価し、高品質なデータを選択するために、品質タグにラベル付を行うことが出来る。
現状は、様々なシナリオのデータの信頼性を高く評価するために、LLMだけに頼るということは出来ず、人間のアノテーションが必要。
マルチモーダルLLMの判断
GPT-4o, Gemini, LLaVAのようなモデルは、テキスト・音声・画像を処理するための単一のフレームワークに統合している。
現在、モデルを評価するためのMLLM-as-a-Judgeフレームワークが登場しているが、どのようにしてデータやエージェントの評価に適応できるか、探っている段階である。
LLM同様に、データの評価や注釈、報酬モデルとして機能する能力、中間推論プロセス内で検証者として機能することが想定される。
将来的には、テキスト・音声・画像・ビデオにまたがる複雑なコンテンツを推論し、評価することが出来るロバストなマルチモーダル評価器が必要。しかし、現状はLLMに比べ、推論性能や信頼性に欠ける。
今後は、推論能力・信頼性の向上、モダリティを超えたシームレスな統合を可能にすることを重点に置く。
マルチモーダルコンテンツモデレーションや自動知識抽出など、新たな可能性に秘めている。
その他
- LLM-as-a-Judge のベンチマーク増加
- LLM最適化のためのLLM-as-a-Judge
結論
- LLM-as-a-JudgeはLLMに基づく評価のパラダイム
- 人間の専門家や定量的な評価を置き換える手法
- 信頼性に関する課題に対処する必要がある
- LLM-as-a-Judgeを導入するだけでは、性格で評価ニーズの沿った結果を保証できない
- 新r内製の高いシステムを構築するには、定義・実践・研究のギャップを対処し、出力を評価・洗練させる体系的な取り組みが必要
QA4AI ガイドライン
概要
とあるイベントで、生成AIの評価について発表が行われた。その発表で紹介されていたのが、「QA4 AIプロダクト品質保証ガイドライン」である。
まだ中身はちゃんと見ていないのだが、発表内では、いくつかの観点項目が挙げられており、それらに対するベンチマークや評価方法について記載がされていると紹介されていた。
様々なAIに関するガイドラインを見てきたが、それらは観点項目を挙げているだけで、細かな対応策はあまり述べられていない。
その点、このドキュメントは具体的な対応策を紹介している点と、従来の観点項目とは異なるAI特有の項目があることを述べている点が、優れているところだろう。
また、このドキュメントを発表した著者の一人は「これからも新しい観点は出てくるだろう」と述べているらしく、AIに関する品質の観点項目の洗い出しは、まだ始まったばかりと言える。
現在の生成AIの評価方法を知るだけではなく、これからの動きも追っていく上で重要なドキュメントと考えられる。
自分も暇があるときに、詳しく読みたい。
余談
発表内容については、以下のスライドになる。
上記のドキュメント以外の評価方法も重要だと述べており、実用的な評価方法を知るという意味でも、見ていて損はない資料である。
Google Cloud Associate Cloud Engineer 合格記
合格しました。
内容
- Google Cloud 資格のAssociate Cloud Engineer を取得した。
- オフラインで受ける予定だったが、予定が合わなかったため、急遽自宅で受験できる環境を整え、オンラインで受験した。
- 1Kの家で、玄関付近にある洗濯機の上にモニターを置いて出来るようにした。
- 監督官に「洗濯機の上にモニターを置いているんですよね？」と確認されたから、珍しかったのかもしない。
- 受験対策は、以下のリンクを参考にして、主に問題集で行った。
- ハンズオンなどもやったが、正直理解が深まった感じはしなかった。
- 個人的には、資格取得後だったり、学習中にイメージがつかなかったりした場合に、知識を補完する形でハンズオンを行うほうが良いのでは、と思った。
- 問題集は以下
- 「最短攻略～」は一問一答形式で、一問ごとに解説が入るのでおすすめ。ただし誤った記載などもあるため、公式ドキュメントなどを見て、自分なりの答えを作っておく。
- 「これだけで合格～」は、最初５割程度しか取れなかったが、間違えた部分の解説、リンクされている公式ドキュメントなどを見て、３週ぐらいした。
- ９割以上取れるようになった状態で受験した。
- オンライン受験は、受験環境に対して検査が入るが思ったよりも厳しくなかった。
- 多分、自分の席から、カンニングになるようなものが見えない、あるいは届かないような環境であることを示すことができれば、大丈夫なのだろう。
- ５０問、２時間だったが、３０分ぐらいで全問解き終わった。
- 追加３０分で見直しをして、１時間ぐらいで提出して終わり。
- アンケートに答えた後、試験の結果が出た。
- 「Pass」と表示されたら、合格ということに気づくまでに、時間がかかった。
- 落ちたら「Fail」らしい。
- 公式認定証などは１日経ってメールで来た。
- １０日ぐらいかかるとか書いていたが、思いの外早かった。
所感
- オンライン受験環境が割と厳しいと聞いていたため、色々気を使ったが、思ったよりは厳しくなかった。
- ただし、カメラで作業環境を詳細に見せなくてはならなかったため、その点が面倒くさいといえば面倒。
- そういう意味では「厳しい」のかもしれない。
- とりあえず基礎的な力を身に着けたので、プロフェッショナル資格に向けて引き続き学習を取り組みたい。
【論文紹介】JDocQA: Japanese Document Question Answering Dataset for Generative Language Models
・学会発表用として投稿された日本語版のproceeding
https://www.anlp.jp/proceedings/annual_meeting/2024/pdf_dir/C3-5.pdf
概要
テキストと図表を含む日本語版のドキュメントのVQAデータセットを作成し、それらを用いて近年の主要なLLMモデル、マルチモーダルモデルでの評価を行い、ベンチマークとして扱えるかを検証した論文。
新規性としては「日本語」版のベンチマークデータセットを作ったこと。
日本語以外の言語では同様のデータセットは既にあるが、それらでは日本語の性能比較が出来ない。そこで「日本語版」のデータセットが望まれる。
過去に自然言語理解タスクのデータセットにGLUEの日本語版としてJGLUEが提案されているが、今回の論文では、同様の流れで日本語版の文章画像質問応答 (VQA) 用データセットが作られたと考えられる。
タスクは以下の４つ。
- Yes/No （質問に対してはい/いいえで答える）
- 事実抽出形式 (本文中から事実を抜き出して回答する）
- 数量形式 (四則演算や単位を含めて数字で回答する）
- 自由記述形式 (質問に対してある程度の長さの文章を作成して回答する）
また４つの質問形式とは別に解答不能問題という質問タスクがある (複数ページを参照しなくてはならない質問、あるいは文章中の情報だけでは回答できない質問)。
モデルとしては、学習なしモデル (gpt3.5-turbo, gpt-4)、本データセットの中の学習データを用いた学習済みLLM、学習済みマルチモーダルモデル、で４つのタスクを行った。
ただし、回答できない質問があるデータセットもあるので、それを含めた場合と含めない場合の２つの条件で行っている。
結果としては、LLMは学習させると、学習させてないgptシリーズよりも、精度が良くなるところも見られた。
解答不能な質問を含めた場合と、含めなかった場合で学習させた結果、全てのモデルで含めた場合のほうが精度が良い。
回答できない質問を学習データにいれることは、ハルシネーション抑制に繋がるためだと考察している。
マルチモーダルについては、一部のLLMよりも低い精度を出していた。それはモデルの入力トークン数に上限があったため、精度が低くなったとされる。
トークンの長さは長くなるほど、やや精度が改善されると本論文で示されており、マルチモーダルの精度低下はトークン数の小ささが関係していると言える。
所感
日本語でのデータセットが少ない現状で、このようなデータセットは非常に助かると言える。
個人的には、RAG検証として使いたいと思った。
社内検索エンジン作成を行った際に、プロダクトとしてどれぐらい使えるのか、といったことを示す際に、現在は自前でテストを作る必要がある。
しかし、このようなベンチマークがあれば、ただテスト出来るだけではなく、他のプロダクトと比べてどれくらい精度があるのかを示すことができ、だからこの製品を使える、といった検討の材料の１つにできるだろう。
Gemini、Claudeなどのマルチモーダル対応のモデルで行ったらどうなるか、少し試してみたいところだ。
今のところ、データセット自体は公開されておらず、そこが残念である。
そもそも公開されるのかは分からないが、公開されれば是非使いたいところである。
余談
ただ、一方で以下のような問題もあるので、ベンチマークがどれだけ「信頼の置ける」指標として機能しているのか、といったところは考えなくてはならない。
実は最近のLLMは,学習中に評価用のベンチマークと酷似したデータを(意図的にせよ非意図的にせよ)カンニング/暗記しており,それで評価スコアが高くなっていたのではないか問題https://t.co/r70kcwMv6q
— 今井翔太 / Shota Imai@えるエル (@ImAI_Eruel) May 3, 2024
完全新規ベンチマーク(GSM1k)を作り評価すると,見事にほとんどのLLMの性能が下がったという...… pic.twitter.com/JaSgG852sU
いずれにせよ、さっきも書いた通り、目的を達成する際に検討する材料の「１つ」として考える、ぐらいに留めておき、ベンチマーク至上主義みたいなのにはならないように注意しておこう、と個人的には思った。
