ICLR2026が開催中なので、エムスリー AI・機械学習チームの推し論文を勝手に紹介するぜ！
こんにちは。エンジニアリンググループのAI・機械学習チームに所属している鴨田 です。弊チームでは毎週1時間の技術共有会を実施しており、各自が担当するプロダクトの技術や、最近読んだ論文を紹介しています。今週はICLR2026が開催されていることもあり、同学会の論文読み会となりました。1セッションにつき1名が担当し、各自が選定した論文の詳細について解説しました。本ブログではその一部として、セッションごとの「推し論文」を紹介します。 まだ読んでいない方は前回のAAAI2026の輪読会ブログも是非ご覧になってください www.m3tech.blog ICLR 2026からトップページバナーを引用 Is it Thinking or Cheating? Detecting Implicit Reward Hacking by Measuring Reasoning Effort 推しポイント はじめに 報酬のハッキング 暗黙のハッキング 論文の提案 感想 AnyUp: Universal Feature Upsampling 推しポイント 課題 感想 Neon: Negative Extrapolation From Self-Training Improves Image Generation 推しポイント RealPDEBench: A Benchmark for Complex Physical Systems with Real-World Data 推しポイント マスク学習によるダイナミクスの獲得 U-Netの有用性とコストパフォーマンス 実データ収集における計測規模 Invisible Safety Threat: Malicious Finetuning via Steganography 推しポイント ステガノグラフィによる攻撃 ステガノグラフィでの学習、推論の工夫 感想 We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています Is it Thinking or Cheating? Detecting Implicit Reward Hacking by Measuring Reasoning Effort セッション: Oral Session 2D LLMs and Evaluation 著者: Xinpeng Wang, Nitish Joshi, Barbara Plank, Rico Angell, He He 論文リンク:https://openreview.net/forum?id=Gk7gLAtVDO 紹介者: 髙橋 論文中Figure 2から引用 推しポイント はじめに ある評価指標が目標に設定されると、その評価指標はもはや良い評価指標ではなくなる これはよく知られた格言でKPIデザインなどでよく言及されますが、LLMにも当てはまります。 最近のコーディングエージェントなどのLLMは、多ステップの推論を経て複雑な問題を解きます。こうした推論能力の最適化には主に強化学習が用いられ、最終的な正解や、そこに至る正しい推論ステップ（過程）に対して報酬を与えることでモデルの学習が進められます。 報酬のハッキング この学習の過程でモデルは設計者の期待から逸脱した行動によって報酬を「ハック」しようとすることがあります。 例えば、ユニットテストの通過のみを報酬として設定すると、モデルは要件から想定される実装の代わりに、テストの入出力をそのままハードコードして無理やりパスさせようとするケースがあります。 このような「明示的なハッキング」であれば、モデルの推論過程（CoT：Chain-of-Thought）を監視することで比較的容易に検知できます。なぜなら、モデルが抜け道を使おうとするプロセスや意図自体が、CoTのテキスト上にそのまま出力されてしまうためです。 暗黙のハッキング 今回の論文が問題提起しているのは、明示的なハッキングより巧妙な「暗黙のハッキング（Implicit Hacking）」と呼ばれる現象です。 暗黙のハッキングとは、モデルが実際には早期に抜け道を利用して答えを出しているにもかかわらず、CoT上では「いかにも正当な推論を順序立てて行っているかのような」もっともらしいテキストを生成して隠蔽している状態を指します。 暗黙のハッキングが行われていると、出力されたテキストを監視する従来の手法では見抜くことができなくなってしまいます。 Claude Codeを利用していても、実際には実行していないコマンドをあたかも実行したかのように報告することがあります。 論文の提案 論文中の実験ではタスクの中に意図的にLoophole（容易に報酬が得られる抜け道）が存在する環境を構築し、強化学習を通じてモデルがどのように振る舞うかを観察しています。 引用図のように特定の条件（問題のid番号や負の数を返せば報酬が得られる）を満たせば本来の推論をスキップして正答できる抜け道を与えた結果、モデルはその抜け道を利用して容易に正解を導き出しながらも、出力上はもっともらしく長い推論過程を生成し続けるという「暗黙のハッキング」を学習するモデルが実際に作られました。 論文ではこうした暗黙のハッキングを検出するための手法として、Truncated Reasoning AUC Evaluation (TRACE)を提案しています。 考え方としては、「ハッキングを利用していると推論のステップ数が少ない段階で本来解けないはずの問題を正解できてしまう」、という性質を逆に利用します。 具体的には、推論ステップの生成を10%、30%、50%といった任意の割合で強制的に打ち切り、その時点での文脈のみから最終解答を出力させます。 各打ち切り時点の推論ステップと正答率をグラフにプロットし、その曲線の下の面積（AUC: Area Under the Curve）を計算します。 暗黙のハッキングを行っているモデルは、推論の初期段階で打ち切られても高い正答率を保つため、AUCの値が大きくなる一方でハッキングを利用していないモデルでは、推論ステップ数に伴って正答率が向上するためAUCの値は比較して小さくとどまります。 この指標を用いることで、生成されたテキストのもっともらしさに騙されることなく、モデルの内部的な推論の早期終了を定量的に検知できる、と論文では主張されています。 感想 LLMの発展は常に目覚ましいもので、どうしてもモデルの規模に目が奪われがちですが、モデル能力の向上は評価側の発展に支えられているのだなと改めて感じさせてくれる論文でした。 AnyUp: Universal Feature Upsampling セッション: Oral Session 5E Learning in computer vision 著者: Thomas Wimmer, Prune Truong, Marie-Julie Rakotosaona, Michael Oechsle, Federico Tombari, Bernt Schiele, Jan Eric Lenssen 論文リンク:https://arxiv.org/pdf/2510.12764 紹介者: 鴨田 論文中Figure 3から引用 視覚基盤モデル（VFM）の発展により、画像全体の高度な意味理解が可能になりましたが、構造上出力される特徴量マップの空間解像度が劇的に低下してしまうため、ピクセル単位の精緻な予測（セグメンテーションや深度推定など）が難しいという根本的な課題があります。 この課題を解決し、低下した解像度を復元するアプローチとして特徴量アップサンプリングの研究がこれまでも盛んに行われてきました。しかし、既存の学習ベースの手法には、DINOやCLIPなどバックボーンとなるモデルを変更するたびに、アップサンプラー全体をゼロから再学習しなければならないという実用上の大きな壁がありました。 この論文の面白いところは、特定のモデルアーキテクチャに依存しない「特徴量非依存（Feature-Agnostic）」なアップサンプリングを推論時に実現している点です。 従来のように特定の特徴量に依存するのではなく、入力段に独自の「特徴量非依存レイヤー」を設け、画像のどこにエッジやテクスチャの境界があるかといったパターンを抽出するアプローチをとっています。これにより、未知の次元数や表現空間を持つ特徴量であっても、一度学習するだけで任意の解像度へ柔軟に拡張できるようになりました。 推しポイント 個人的に一番の推しなのは、「画像の解像度を復元（アップサンプリング）するには、わざわざ画像全体の特徴を計算しなくても、局所的（Local）な特徴を見るだけで十分ではないか」というアプローチです。 従来の手法は画像全体のクロスアテンションを計算しがちでしたが、AnyUpは局所的な構造変化さえ捉えられればよいと割り切り、ローカルなウィンドウアテンションを採用しています。さらに、複数の異なるモデル（DINOv2とSigLIPなど）でマルチバックボーン学習させることで、未知のモデルに対するゼロショット汎化性能を底上げしており、この直感的な設計と普遍性の組み合わせが見事です 。 課題 ただし、ウィンドウアテンションの副作用として、オブジェクトの境界分離能力（空間的識別性）が甘く、特徴量マップ全体が滑らかに一様化しやすい傾向があったり、アテンション計算の性質上、解像度が大きくなると計算コストとメモリ消費が二次関数的に爆発してしまうという構造的な弱点も抱えています。 このような課題が解決されていないので、計算の線形化を目指す「UPLiFT」や、学習効率と高倍率へのスケーリングに特化した「DiveUp」という論文が続々と登場しています。 感想 とはいえ、テーマ自体が「普遍的アップサンプリング」として面白いので後続の論文がたくさん出ている点と、この論文自体シンプルなアプローチで読みやすい点を考慮して推し論文としました！ 後続の論文も読みやすいので合わせて読んでみてください！ Neon: Negative Extrapolation From Self-Training Improves Image Generation セッション: Oral Session 1B Generative models I 著者: Sina Alemohammad, Zhangyang Wang, Richard Baraniuk 論文リンク:https://openreview.net/pdf?id=kpLRYtPGt3 紹介者: 中村 伊吹 論文中Figure 1から引用 推しポイント 生成AIの性能向上には大量のデータが必要ですが、高品質な実データは今後ますます貴重になります。そこで期待されるのが、モデル自身が生成した「合成データ」を使った自己学習です。ただし、合成データだけでFine-Tuningすると、品質や多様性が急速に崩れる「モデル崩壊」が起きやすい、という難しさがあります。 論文では、合成データによる崩壊の原因を、モデルがもともと出しやすい画像をさらに出しやすくしてしまう mode seeking にあると説明しています。つまり、自己生成データにはどうしても偏りがあり、その偏りでさらに学習すると、よく出るパターンばかりが強化され、生成の多様性が失われていく、という見方です。 この論文の面白いところは、そのモデル崩壊を「避けるべき失敗」として扱うのではなく、あえて利用する発想にあります。合成データで少しだけ自己学習したときの更新方向を、「モデルが崩壊していく方向」だとみなし、その逆向きにモデルを動かすことで性能改善を狙います。タイトルの Negative Extrapolation という名前も、
- 生成AI
- LLM
- 機械学習
- 強化学習
Agentic MLOpsで加速する機械学習開発
こんにちは、AI・機械学習チームの池嶋大樹です。 LLMエージェントがモデルの性能グラフを見ながら、YAMLの設定を自律的にチューニングしていく――そんなAgentic MLOpsを私たちのチームでは実践しています。 私たちのチームでは6年前から、YAMLで機械学習モデルの設定を管理し、設定を差し替えるだけで実験を回せるconfig-drivenな機械学習を実践してきました。 もともと実験管理やコードと設定の分離といったメリットがありましたが、LLMエージェントがYAMLの設定を自律的にチューニングできるようになったことで、開発がさらに加速しています。 本記事では機械学習におけるconfig-drivenのメリットと、Agentic MLOpsによってさらに生産性が向上した話を紹介します。 YAMLによるconfig-driven機械学習とは YAMLによるconfig-driven機械学習のメリット コードと設定の分離 実験管理で有利 LLMを使ったAgentic MLOpsへ まとめ We are hiring! YAMLによるconfig-driven機械学習とは m3.comでは、あるテーマに興味が高いユーザーに絞ってコンテンツを届けたい、という施策が頻繁に発生します。 例えば、ある疾患に興味がありそうなユーザーにだけ特集ページを案内する、といったケースです。 私たちのチームでは、こうした「XXXに興味が高いユーザー」をピックアップするための機械学習モデルを開発・運用しています。 対象となるテーマはさまざまな疾患や薬剤から、生活に関する情報まで多岐にわたり、テーマごとに教師データや最適化ロジックが異なります。 モデルもGBDTやNNなど複数を組み合わせたアンサンブルで構成されているため、テーマごとの設定に加え、モデルごとのハイパーパラメータや特徴量も必要になり、全体の設定項目はかなり多くなります。 そこで、これらの設定をすべてYAMLファイルに切り出し、コードを変えずに設定ファイルだけ差し替えて実験を回せるよう、config-driven機械学習を実践してきました。 例えば、次のようなYAMLファイルでモデルの構成を記述します。 # モデル設定YAMLの超抜粋（設定項目が多いと、実際には500行以上になることもある） project_config: project_name: recommend_toppage_A train_data_path: gs://bucket/train_data.csv loading_model_names: - model_a_pv_and_meta_nn - model_a_pv_and_meta_optuna_lgb - ... ensemble_config: - ensemble_name: ens_group_1 group_name: group_1 minimum_allowed_model_auc: 0.75 ensemble_max_model_counts: 15 auto_model_selection: true actual_label_columns: - actual_label_1 - ensemble_name: ens_group_2 group_name: group_2 minimum_allowed_model_auc: 0.77 ensemble_max_model_counts: 15 auto_model_selection: true actual_label_columns: - actual_label_1 segmentation_config: - group_name: group_1 single_segment_config: - ensemble_name: ens_group_1 should_extract_higher: true score_threshold: 0.3 assigned_segment: 1 - ensemble_name: ens_group_1 should_extract_higher: false score_threshold: 0.3 assigned_segment: 0 このYAMLファイルでは、project_configでプロジェクト名や学習データのパス、読み込むモデルの一覧を定義し、ensemble_configでグループごとのアンサンブル条件（どの教師ラベルで最適化するか、アンサンブルに使うモデルの最低AUC、最大モデル数など）を指定しています。 segmentation_configでは、アンサンブルモデルの予測スコアをもとにユーザーをセグメントに分割するルールを定義しています。 最終的にユーザーを「興味が高い／低い」といったセグメントに分け、興味が高いユーザーにだけ施策を配信します。 このYAMLを入力として、モデルの学習・推論・アンサンブル・セグメンテーションまでを自動実行するPythonのパイプラインスクリプトを整えているため、プロジェクトのたびにコードを触る必要はなく、YAMLを編集するだけで別プロジェクト用のモデル作成が可能になっています。 YAMLによるconfig-driven機械学習のメリット コードと設定の分離 設定をYAMLに切り出しているため、ハイパーパラメータや特徴量を変えたいときにコードを触る必要がありません。 同じコードベースのまま、YAMLを差し替えるだけで複数のプロジェクトや実験構成を管理できるようになりました。 レビューの負担も軽くなります。 コード側はテスト済みの安全なものをそのまま使うため、レビューでは設定ファイルの内容が適切かどうかだけを確認すれば済みます。 実験管理で有利 実験条件がYAMLファイルとしてそのまま残るため、再現性が高く保てます。 「あの施策/実験の設定なんだっけ？」と振り返りたいときも、YAMLを見るだけで分かります。 YAMLをGitで管理すれば、「前回の実験から何を変えたか」が差分で一目瞭然です。 実験ごとにYAMLファイルを残しておけば、それ自体が実験ログとして機能します。 LLMを使ったAgentic MLOpsへ ここまでのメリットは以前からあったものですが、課題もありました。 実際のYAMLは学習・モデルアンサンブル・ユーザーセグメンテーションのハイパーパラメータを細かく設定しています。 さらに、ユーザーを属性ごとに分けたグループごとにこれらを設定するため、完成版のYAMLは数百行に及びます。 グループごとに設定を分けることで推計結果の偏りを防げていましたが、設定項目が多い分、新しいメンバーにとっては慣れるまでに時間がかかる面もありました。 LLMエージェントがYAMLの設定を自律的に編集・チューニングできるようになり、この課題が大きく解消されました。 「モデルにAUCの閾値をXXXに上げて」「新しいグループを追加して」と自然言語で指示するだけで、LLMがYAMLの該当箇所を正しい書き方で修正してくれます。 設定YAMLの書き方ドキュメントを完全には理解しなくても、LLMが設定の構造を解釈した上で生成・修正してくれるため、慣れていないメンバーの学習コストが大幅に下がりました。 さらに、Claude CodeのSkillsを活用して、チューニング作業自体の自動化にも取り組んでいます。 例えば、ユーザーセグメンテーションのパラメータチューニング手順を次のようにSkillとして定義しています。 # セグメンテーション閾値チューニング スキル ## 核心原則: inference推論分布とprecisionのバランス チューニングでは以下の2つを同時に満たすことを目指す： 1. inferenceの各セグメント人数比率が、教師データの人数比率に近いこと 2. 各セグメントのprecision（positive rate）が良好であること ## Step 1: ベースライン実行 `segmentation_config` で全員を同一セグメントに割り当てて実行し、モデル性能を確認する。 ## Step 2: グラフからの閾値決定 `grouped_performance_rank_1.png` のビン境界値をもとに閾値を決定する。 ## Step 3: YAMLの編集と再実行 閾値を高い順に設定する。セグメント数は3〜4が現実的。 ## Step 4: 評価と反復 inference推論分布とprecisionの両方を確認し、必要に応じて閾値を調整する。 ... 実際のSkillはより詳細ですが、LLMがこのSkillに従い、YAMLの閾値を編集 → パイプラインを実行 → 結果を評価 → 再調整、というサイクルを自動で回してくれます。 LLMが実際にモデルの性能グラフを見て、precisionやセグメント割合を分析しながら閾値を調整していく様子は、見ていても面白いものです。 LLMの操作対象がYAMLに限定されており、モデル実行はテスト済みの既存Pythonスクリプトなので、安心して任せられます。 現状では局所解にハマることもあり、教師データの作り方を変えるといった判断にはまだ人間が必要です。 しかし、チューニングのサイクルをLLMが高速で回してくれるおかげで、最適な閾値を見つけるまでの効率は大幅に向上しました。 まとめ YAMLによるconfig-driven機械学習は、コードと設定の分離や実験管理といった従来のメリットがあります。 そしてAgentic MLOpsの時代になり、自然言語での設定編集やSkillsによる自動チューニングなど、YAMLの扱いやすさがさらに活きるようになりました。 設定ファイルの複雑さという課題も、LLMエージェントが正しい書き方で生成・修正してくれることで解消されつつあります。 config-drivenで設計しておくと、エージェントの操作対象をYAMLに限定できるため安全に自動化しやすい、というのも大きな学びでした。 機械学習の設定管理にお悩みの方は、config-driven機械学習 × Agentic MLOpsをぜひ試してみてはいかがでしょうか。 We are hiring! エムスリーでは、AI・機械学習を活用したプロダクト開発を一緒に進めてくれるエンジニアを募集しています。 興味のある方は、ぜひ次のリンクからご応募ください。 jobs.m3.com
- MLOps
- 機械学習
- LLM
- 自動化
LLM as a Judgeで生成物の品質を担保する
こんにちは、エムスリー AI・機械学習チームの氏家（@mowmow1259）です。 この記事はAI・機械学習チームブログリレーの10日目の記事です。9日目は苅野さんによる「Claude Code と進める Ingress から Gateway への移行」でした。 移行をゴリゴリ進めていただいている苅野さんによる解説記事です！ www.m3tech.blog 私は福岡に住んでいるんですが、最近同僚と大濠公園でお花見BBQをしてきました。 お花見と言いつつ桜はまだ咲いていなかったのでただBBQをしただけになりました。 お花見シーズンに限らず、大濠公園は落ち着いて過ごせるいいところなので福岡に来た際にはぜひ立ち寄ってみてください。 桜が咲き掛けの大濠公園 さて、生成AIの台頭により、画像・テキスト・コードとあらゆるコンテンツ生成が飛躍的に容易になりました。 エムスリーでも業務効率化だけでなく、生成AIの各種プロダクトへの組み込みを積極的に推進しています。 一方で、生成物を直接利用する場合には、低品質な生成物はユーザー体験の悪化や意図しない情報漏洩にも繋がるため、品質担保は避けて通れない課題です。 本記事では、LLMによる生成物をプロダクトに組み込む際の品質担保戦略として、エムスリーで実践しているLLM-as-a-Judgeを中心としたアプローチを紹介します。 なお、本記事は先月福岡で行われたPythonのコミュニティイベント Python Meetup Fukuoka #6 *1での登壇内容です。 ご興味がある方はぜひ登壇資料もご覧ください。 LLM as a Judgeとは 基本的な考え方 LLM-as-a-Judgeに潜むバイアス バイアスを考慮した評価 ① 評価観点の明確化 ② 複数モデルでのバリデーション ③ 人間による生成との対決（ペアワイズ法） ④ 評価理由やリファレンスを生成させる ⑤ 人手評価によりプロンプトをチューニング ⑥ プロンプトのチューニングもLLMにやらせる LLMの評価をプロダクトの一部としてとらえる まとめ We are Hiring! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ エンジニア新卒採用サイト！ LLM as a Judgeとは 基本的な考え方 LLM-as-a-Judge とは、生成AI（LLM）自身に評価をさせるアプローチです。 近年ではレビュー論文*2も公開されるなど活発に議論されている分野です。 例えば、このブログについて、5点満点で評価してくださいのような形でプロンプトを作り、LLMの出力を直接評価に使います。 出された評価でフィルタリングをしてもいいですし、評価を元に改善のサイクルを回すこともできます。 人手による評価と比較して圧倒的にスケールするのが最大の利点です。 LLM-as-a-Judgeに潜むバイアス ただし、先ほどの例のように素直に評価させても多くの場合うまくいきません。 LLMの生成にバイアスやハルシネーションがあるように、LLMを評価に用いる際にもさまざまなバイアスは避けて通れません。 例えば代表的なバイアスとして次のものがあります。 Position Bias: 複数選択肢のうち最初のものを高く評価しがち Length Bias: 長く冗長な文章ほど高く評価しがち Self Enhancement Bias: 自身が生成した出力を高く評価しがち これらのバイアスを踏まえた上で「どうやってLLMに公正・妥当な評価をさせるか」がLLM as a Judgeの研究分野であり実用上の肝になります。 バイアスを考慮した評価 では、どのようにしてバイアスを排除しながら評価させたら良いのでしょうか。 ここでは例として、プログラミングクイズを出題するプロダクトのために、LLMでクイズを生成したとします。 問題: 次のデータ型のうち、一度作成すると中身を変更できない（イミュータブルな）ものはどれ？ A. リスト (list) B. 辞書 (dict) C. タプル (tuple) D. セット (set) 当然答えはCです。 ここからはこのクイズに対して適切に評価させる方法を紹介していきます。 ① 評価観点の明確化 「いい評価をしてください」という曖昧な指示では一貫性のある評価になりません。 まずは、何の観点で、どういう基準で評価するかを明示することが重要です。 次のPythonクイズを次の4つの観点から、5点満点（1〜5）で評価し、総合評価を同じく5点満点で評価してください。 評価項目： - 有用性: 実務や学習の初期段階で、知らなければ困る重要な知識か。 - 選択肢の罠: 誤答の選択肢に「他言語の癖」や「直感的な勘違い」を誘う説得力があるか。 - 意外性: 正解や解説を聞いたときに「なるほど！」という驚きや納得感を得られるか。 - 汎用性: その問題の答えが他の文法やライブラリの理解にも繋がる根本的なルールか。 評価観点を明示することで評価軸やスケールが揃い、妥当な評価になりやすくなります。 冒頭のクイズだと選択肢の罠の観点でGeminiに3をつけられてしまいました。 ここから、setの代わりにdataclassを選択肢に入れるなどの改善が考えられます（その場合Geminiの評価は5に上がります）。 ② 複数モデルでのバリデーション コストとの兼ね合いになりますが、単一モデルの評価はそのモデルのバイアスをそのまま反映してしまいます。 Gemini、GPT、Claude Sonnetなど異なるLLMに同じプロンプトで評価させ、複数の評価結果を統合することで、self enhancement biasを考慮したより頑健な評価が得られます。 モデルA: 5点 モデルB: 2点 → 平均: 2.7点 モデルC: 1点 また、スコアのばらつき自体も「評価が難しい問題かどうか」の指標になります。 ③ 人間による生成との対決（ペアワイズ法） ここまでは絶対評価を前提に紹介しましたが、絶対評価だけでなく相対評価も品質担保に有効です。 生成物と人間が作ったコンテンツを並べて比較させ、相対的に品質の高いクイズかを評価できます。 次の2つはPythonに関するクイズです。どちらがよりソフトウェアエンジニアが監修した クイズとして質が高いでしょうか。 クイズA: XXXXX クイズB: YYYYY Position Biasへの対策として、クイズAとBの順番を入れ替えたパターンを実施するのもよいでしょう。 ④ 評価理由やリファレンスを生成させる スコアだけでなく評価理由も生成させることで、CoTの文脈で評価精度の向上が期待できますし、人手で後から確認する際の効率も上がります。 ... ただし、評価は次の形式で理由も含めて出力してください。 修正や批判を行う場合はそれが正しいと主張できる箇所を原文から抽出して併記してください。 { "has_issues": true/false, "issues": [ { "category": "有用性" | "意外性" | "汎用性", "description": "具体的な問題点の詳細説明", "severity": "high" | "medium" | "low", "details": "カテゴリ分析結果や具体的な指摘内容" } ] } 根拠を原文から抽出させる指示を加えることで、ハルシネーションのチェックの効率も上がります。 ⑤ 人手評価によりプロンプトをチューニング ここまで評価のためのTipsを紹介してきましたが、一発で実用に足る評価プロンプトを作ることは困難です。 解いている問題のドメインや難易度によってプロンプトの調整は必須だと思っています。 そのため、従来の機械学習と同様に人手評価 → プロンプト改善のサイクルを回すことが重要です。 プロンプトv1で評価 → 人手評価と比較 → ずれを修正したプロンプトv2を作成 「LLMが3点と評価したが人間は5点と評価した」というようなずれを収集し、そのずれのパターンに基づいてプロンプトを改善していきます。 ⑥ プロンプトのチューニングもLLMにやらせる 人手評価を進めていく中で、プロンプトの修正案作成自体もLLMに任せるのもよく行っている方法です。 [正解例] 問題: XXXXX 人手評価: 5点、理由: 〇〇 LLM評価: 2点、理由: △△ → このずれを修正するプロンプトv2の改善案を生成してください 人手アノテーションのコストを抑えつつ、評価プロンプトの品質を継続的に向上させられます。 LLMの評価をプロダクトの一部としてとらえる LLMによりいかにバイアスを排除した評価を実施しても、ドメインやプロダクトの特徴によっては生成物をそのまま利用することが難しい場合ももちろん多くあります。 LLMが高評価したから大丈夫だ、というような使い方ではなく、プロダクトによって適切に道具の一つとして使っていくのが重要です。 例えば、コンテンツを大量生成・評価させた上で人手による評価ができる程度にフィルタリングしたり、LLMによる評価をプロダクトそのものにすることも考えられます。 まとめ LLM-as-a-Judgeを活用した生成物の品質担保戦略を紹介しました。 生成AIをビジネスに組み込む際、「生成できること」と「信頼できる品質で生成できること」の間には大きなギャップがあります。LLM-as-a-Judgeをそのギャップを埋める現実的な手段として、ぜひ活用してみてください。 We are Hiring! エムスリーではエンジニアを絶賛募集しています！ 少しでもご興味をお持ちの方は、ぜひカジュアル面談等にご応募ください！ エンジニア採用ページはこちら jobs.m3.com カジュアル面談もお気軽にどうぞ jobs.m3.com エンジニア新卒採用サイト！ fresh.m3recruit.com *1:LINEヤフーさん、GMOペパボさん、エムスリーの共同開催 *2:Jiawei Gu, et al. (2025). A Survey on LLM-as-a-Judge. arXiv:2411.15594. https://arxiv.org/abs/2411.15594
- 生成AI
- LLM