本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
LLM出力評価におけるBLEU/ROUGEスコア
大規模言語モデル（LLM）の性能を評価する上で、出力の品質測定は不可欠です。本記事では、特にテキスト生成タスクで広く用いられる自動評価指標であるBLEU (Bilingual Evaluation Understudy) スコアとROUGE (Recall-Oriented Understudy for Gisting Evaluation) スコアに焦点を当て、その活用方法、限界、およびプロンプトエンジニアリングにおける評価・改善ループについて解説します。
1. ユースケース定義
LLM出力の品質を定量的に評価する主要なユースケースは以下の通りです。
開発段階でのモデル性能比較: 新しいLLMモデルやファインチューニングモデルが、既存モデルと比較してどの程度改善されたかを評価します。
プロンプトエンジニアリング: プロンプトの変更（例: ゼロショット、少数例、Chain-of-Thought）がモデル出力に与える影響を測定し、最適なプロンプト設計を探索します。
回帰テスト: モデルのアップデートや環境変更後に、以前の性能が維持されているか、意図しない劣化がないかを確認します。
特定タスクにおけるベンチマーク: 要約、翻訳、質問応答など、参照テキストが存在する特定のタスクにおいて、LLMの出力がどの程度「正解」に近いかを客観的に評価します。
これらのユースケースでは、人間による手動評価はコストと時間がかかるため、BLEUやROUGEのような自動評価指標が迅速なフィードバックと大規模なデータセットでの評価を可能にします。
2. 入出力契約（制約付き仕様化）
LLMプロンプトの設計と評価プロセスにおける入出力契約を明確に定義します。
2.1. 入力契約
| 項目 | 定義 | フォーマット | 失敗時の挙動 |
|---|---|---|---|
| LLMプロンプト | 評価対象となるLLMへの命令。タスク説明、制約、コンテキストを含む。 | text |
形式不備時はプロンプトエラーとして処理 |
| 評価タスク定義 | 評価対象のタスク（要約、翻訳、Q&Aなど）と目的。 | text |
― |
| 参照テキスト | 期待される正解出力のテキスト。複数設定可能。 | list[text] |
提供されない場合は評価不可 |
| 評価基準 | スコア計算に用いる指標（BLEU-1, ROUGE-Lなど） | text |
未定義時はデフォルト値を使用 |
2.2. 出力契約
| 項目 | 定義 | フォーマット | 失敗時の挙動 |
|---|---|---|---|
| LLM生成テキスト | LLMによって生成されたテキスト出力。 | text |
空文字列または部分出力の場合はエラーフラグ |
| BLEUスコア | BLEU-1, BLEU-2, BLEU-3, BLEU-4 の各スコア。 | float |
参照テキスト不足時は 0.0 |
| ROUGEスコア | ROUGE-1 F値, ROUGE-2 F値, ROUGE-L F値。 | float |
参照テキスト不足時は 0.0 |
| 評価コメント | 自動評価結果に基づく簡易コメント（例: “参照とよく一致”, “簡潔性に課題”） | text |
― |
| 失敗モード識別子 | 検出された失敗モードを示すフラグ（例: HALLUCINATION, FORMAT_ERROR） |
list[str] |
検出されない場合は空リスト |
2.3. 失敗時の挙動
タイムアウト: LLMからの応答が指定時間（例: 60秒）を超えた場合、評価を中断しエラーを返します。
形式違反: LLM生成テキストが指定された出力フォーマット（JSON、箇条書きなど）に従わない場合、部分的な処理を試みるか、
FORMAT_ERRORフラグを立ててエラーとして扱います。関連性欠如: LLM生成テキストがプロンプトの指示と著しく関連しない場合、BLEU/ROUGEスコアが低くなるほか、別途
OFF_TOPICフラグを立てます。
2.4. 禁止事項
個人情報（PII）の入力: プロンプトや参照テキストに個人を特定できる情報を含めることを禁止します。
著作権侵害コンテンツの生成指示: 著作権で保護されたコンテンツの複製を意図的に指示することを禁止します。
有害コンテンツの生成指示: ヘイトスピーチ、暴力奨励、違法行為、または差別的な内容を生成するよう指示することを禁止します。
3. プロンプト設計
LLMの出力品質を最大化し、BLEU/ROUGEスコアによる評価に適した出力を得るためのプロンプト設計手法を3種類紹介します。
3.1. ゼロショットプロンプト
最も基本的な形式で、具体的な例示なしにタスクを直接指示します。簡単な要約や翻訳タスクに適しています。
あなたは日本語の文章を20文字以内で要約する専門家です。 以下の文章を20文字以内で要約してください。 文章: 「地球温暖化は、人間の活動によって大気中の二酸化炭素濃度が増加し、地球全体の平均気温が上昇する現象です。これに伴い、異常気象の頻発や海面上昇など、さまざまな環境問題が引き起こされています。」 要約:
3.2. 少数例プロンプト（Few-shot Prompting）
タスクの説明に加え、数例の入出力ペアを提供し、モデルに期待されるパターンを学習させます。特に、特定のスタイルや制約のある出力を求める場合に有効です。
あなたは日本語の文章を20文字以内で要約する専門家です。
以下に示す例を参考に、指定された文章を20文字以内で要約してください。
入力: 「太陽は東から昇り、西に沈むという現象は、地球の自転によって引き起こされます。」
出力: 「地球の自転により、太陽は東から昇り西へ沈む。」
入力: 「大谷翔平選手は、ロサンゼルス・ドジャースに所属するプロ野球選手であり、二刀流として世界中で活躍しています。」
出力: 「大谷翔平はドジャース所属の二刀流プロ野球選手。」
入力: 「{{評価対象の文章}}」
出力:
3.3. Chain-of-Thought（CoT）制約型プロンプト
モデルに思考プロセスを段階的に出力させ、特定の制約（文字数、キーワード使用など）を強制します。複雑な推論や厳密な条件が求められるタスクにおいて、幻覚や脱線を抑制しやすくなります。
あなたは日本語の文章を20文字以内で要約する専門家です。 以下の手順に従い、指定された文章を20文字以内で要約してください。 文章: 「量子コンピュータは、従来のコンピュータとは異なり、量子の重ね合わせやもつれといった現象を利用することで、特定の問題において超高速な計算を可能にする次世代の技術です。その開発は世界中で加速しています。」 思考ステップ: 1. 入力文章の主要な主題とキーワードを特定する。 2. 主要な主題とキーワードを用いて、簡潔な要約の草案を作成する。 3. 要約が指定された文字数制限（20字以内）を満たしているか確認する。 4. 草案を洗練し、自然な日本語になるように調整する。 要約:
4. 評価
BLEU/ROUGEスコアはテキスト生成タスクにおける自動評価の有力な手段ですが、その定義と限界を理解した上で活用することが重要です。
4.1. 評価シナリオ
正例: プロンプトの指示に忠実で、参照応答と語彙・意味がほぼ完全に一致する出力。
- 例: 「京都タワーは京都駅の近くにある。」（参照: 「京都タワーは京都駅の北側に位置する。」）
難例: 意味的には正しいが、参照とは異なる語彙や構文を使用した出力。または、参照情報の一部が欠落している出力。
- 例: 「京都タワーは京都のシンボルで、駅の近くにある。」（参照: 「京都タワーは京都駅の北側に位置する。」）
コーナーケース:
幻覚: 参照にない架空の情報を生成するケース。
- 例: 「京都タワーは東京タワーの姉妹タワーだ。」（参照: 「京都タワーは京都駅の北側に位置する。」）
様式崩れ: 指定された出力形式（例: 「箇条書きで3点」）を無視するケース。
脱線: プロンプトの主題から逸脱し、無関係な情報を生成するケース。
簡潔性不足: 要約タスクで、指定された文字数より著しく短いか、重要な情報が欠落しているケース。
4.2. BLEU/ROUGEスコアの定義と限界
BLEU (Bilingual Evaluation Understudy) スコア: 2002年7月6日にPapineni et al.によって発表された機械翻訳の評価指標です [1]。機械翻訳出力と1つ以上の参照訳との間のn-gram適合率（precision）に基づき、短い出力に対してペナルティを課します。スコアは0から1（または0から100）の範囲で、高いほど良い翻訳とされます。
- 限界: 語彙レベルの一致を重視するため、意味的な同等性や多様な表現を捉えにくいです [1]。特にLLMのように多様な表現が可能なモデルでは、人間による評価との相関が低くなることがあります。
ROUGE (Recall-Oriented Understudy for Gisting Evaluation) スコア: 2004年7月26日にLin and Hovyによって発表された、主に自動要約の品質を評価するための指標です [2]。生成された要約と参照要約との間のn-gram再現率（recall）に基づいています。ROUGE-N（n-gram）、ROUGE-L（最長共通部分列）、ROUGE-S（スキップグラム）などがあります。
- 限界: BLEUと同様に語彙レベルの一致に依存するため、言い換えや同義語を評価しにくいです [2]。事実の正確性や論理的一貫性といったより深い評価軸は捉えられません。
LLM評価における共通の課題: これらのスコアは参照テキストに強く依存するため、LLMのオープンエンドな生成タスクでは、複数の「正解」があり得るため、単一の参照では不十分になることが多いです [3]。また、表面的な一致を測るため、LLMが生成する内容の事実性、論理性、創造性、安全性といった重要な側面を見落とす可能性があります。これらの限界を補完するため、BERTScore [4] やG-Eval [6] といったセマンティックな類似性やLLM自身を評価器とする手法が注目されています。
4.3. 自動評価の擬似コード
Pythonと一般的なライブラリ nltk (BLEU) および rouge-score (ROUGE) を用いた自動評価の擬似コードを以下に示します。
import nltk
# NLTKデータのダウンロードが必要な場合があります: nltk.download('punkt')
from nltk.translate.bleu_score import sentence_bleu, SmoothingFunction
from rouge_score import rouge_scorer
import datetime
def evaluate_llm_output(generated_text: str, reference_texts: list[str]) -> dict:
"""
LLMの生成テキストをBLEUおよびROUGEスコアで評価する。
Args:
generated_text (str): LLMによって生成されたテキスト。
reference_texts (list[str]): 1つ以上の参照正解テキストのリスト。
Returns:
dict: BLEU/ROUGEスコア、失敗モード、評価日を含む辞書。
"""
# テキストを単語単位でトークン化
tokenized_generated = generated_text.split()
# 参照テキストも同様にトークン化（BLEU用）
tokenized_references = [ref.split() for ref in reference_texts]
# BLEUスコア計算: 短い文や少数の参照に対するスムージング関数を適用
# method1は通常、高いBLEUスコアを返す傾向があるが、適切なスムージングを選択することが重要
chencherry = SmoothingFunction()
# BLEUスコアは複数参照に対応。ここでは参照リストを渡す
bleu_score = sentence_bleu(tokenized_references, tokenized_generated,
smoothing_function=chencherry.method1)
# ROUGEスコア計算: rouge_scorerは内部でトークン化を行う
# ROUGEは通常、単一の参照テキストに対して評価されるため、最初の参照を使用
# 'rouge1': 単一単語の適合度, 'rouge2': 2単語の適合度, 'rougeL': 最長共通部分列
scorer = rouge_scorer.RougeScorer(['rouge1', 'rouge2', 'rougeL'], use_stemmer=True)
rouge_scores = scorer.score(reference_texts[0], generated_text)
# 失敗モードの簡易検出（ルールベースの例）
failure_modes = []
# 参照テキストの平均長と比較して生成テキストが著しく短い場合
avg_ref_len = sum(len(ref.split()) for ref in reference_texts) / len(reference_texts)
if len(tokenized_generated) < avg_ref_len * 0.5: # 参照の半分未満の長さの場合
failure_modes.append("brevity_issue")
# 特定のキーワードや正規表現で幻覚や不適切なコンテンツを検出
if "幻覚" in generated_text or "事実ではない" in generated_text:
failure_modes.append("potential_hallucination")
# JSON形式を期待しているが、そうではない場合（擬似的なチェック）
if generated_text.strip().startswith("{") and not generated_text.strip().endswith("}"):
failure_modes.append("format_deviation")
# JSTの日付を取得
jst_now = datetime.datetime.now(datetime.timezone(datetime.timedelta(hours=9)))
evaluation_date_jst = jst_now.strftime("%Y年%m月%d日")
return {
"bleu_score": round(bleu_score, 4),
"rouge_1_fmeasure": round(rouge_scores['rouge1'].fmeasure, 4),
"rouge_2_fmeasure": round(rouge_scores['rouge2'].fmeasure, 4),
"rouge_l_fmeasure": round(rouge_scores['rougeL'].fmeasure, 4),
"failure_modes": failure_modes,
"evaluation_date_jst": evaluation_date_jst
}
# 使用例:
# generated = "京都タワーは京都駅の近くにある。"
# references = ["京都タワーは京都駅の北側に位置する。", "京都タワーは京都駅のすぐそばにあります。"]
# result = evaluate_llm_output(generated, references)
# print(result)
この擬似コードは、2024年7月26日現在のPythonライブラリの一般的な利用方法に基づいています。
5. 誤り分析と抑制手法
自動評価スコアが低い場合や、評価シナリオで問題が検出された場合、以下の失敗モードと抑制手法を検討します。
5.1. 失敗モード
幻覚 (Hallucination): LLMが事実に基づかない、または参照情報に存在しない内容を生成する。これはBLEU/ROUGEでは検出が難しい場合があります。
様式崩れ (Format Deviation): JSON、Markdown、箇条書きなど、プロンプトで指定した出力形式が守られない。
脱線 (Off-topic): プロンプトの指示から逸脱し、無関係な情報や余分なコンテキストを生成する。
簡潔性不足/過剰 (Brevity/Verbosity): 要求された情報量（文字数、センテンス数）を著しく下回る、または上回る。
安全性違反 (Safety Violation): 差別的、暴力的、またはその他の有害なコンテンツを生成する。
一貫性欠如 (Inconsistency): 生成されたテキスト内で論理的な矛盾や情報の一貫性の欠如が見られる。
5.2. 抑制手法
System指示の強化: プロンプトの
systemメッセージで、モデルの役割、厳守すべき出力形式、禁止事項を明確かつ簡潔に指示します。「いかなる場合でも、箇条書きで3点のみを生成し、それ以外の情報は一切含めないでください。」のように具体的に記述します。Few-shot例の追加: 高品質な入出力例を複数提供することで、モデルに望ましい挙動のパターンを学習させます。特に、特定のニュアンスや形式を期待する場合に有効です。
Chain-of-Thought (CoT) プロンプティング: モデルに推論ステップを明示的に要求し、最終的な出力に至るまでの思考プロセスを可視化させます。これにより、論理的な飛躍や幻覚の発生を早期に検出し、自己修正を促すことができます。
出力検証ステップ:
正規表現: 出力テキストが特定のパターン（例: 日付形式、数値範囲）に従っているか検証します。
スキーマバリデーション: JSONなどの構造化データを期待する場合、そのスキーマに適合しているかをプログラムでチェックします。
キーワード検出: 特定の禁止キーワードや不適切な表現が含まれていないかを検出します。
リトライ戦略: 上記の検証ステップで失敗モードが検出された場合、フィードバックとともにプロンプトを再送し、モデルに修正を促す戦略です。例：「JSON形式が正しくありません。再度JSON形式で出力してください。」
外部ツール利用: ファクトチェックのために検索ツールと連携したり、複雑な計算のためにコードインタープリターを使用したりすることで、情報の正確性を担保します。
6. 改良と再評価のループ
LLMのプロンプト設計は一度で完結するものではなく、継続的な評価と改良のループを通じて最適な性能を引き出します。
graph TD
A["プロンプト設計"] --> B{"LLMによる出力生成"};
B --> C["LLM出力"];
C --> D["参照テキスト準備"];
D --> E["BLEU/ROUGEスコア計算"];
C --> E;
E --> F["評価結果分析"];
F --> G{"人間による誤り分析"};
G --> H{"失敗モード特定"};
H --> I{"抑制手法検討"};
I --> J["プロンプト改良"];
J --> A;
6.1. 改良ステップ
評価結果の確認: BLEU/ROUGEスコアや、上記で検出された失敗モード識別子を確認します。
人間による誤り分析: スコアが低い出力や、失敗モードが検出された出力について、人間の目で詳細に分析し、なぜ問題が発生したのか（例: 指示の曖昧さ、モデルの知識不足、コンテキスト不足、制約違反）を特定します。
プロンプトの調整:
明確化: 指示が曖昧な部分を具体的に修正します。
制約追加: 望ましくない出力を防ぐための明確な制約（例: 「必ず〇〇の形式で」）を追加します。
コンテキスト付与: モデルが正確な情報を生成するために必要な背景情報や例を追加します。
思考ステップの導入: CoTプロンプトを導入し、モデルの推論プロセスを制御します。
ペルソナ設定: モデルに特定の役割（例: 「あなたは熟練した要約専門家です」）を与え、出力のトーンやスタイルを調整します。
6.2. 再評価
改良されたプロンプトを用いて再度LLMの出力を生成し、同じ評価指標とシナリオで再評価を行います。このループを繰り返すことで、徐々にプロンプトの品質を高め、LLMの出力性能を向上させます。
7. まとめ
BLEUスコアとROUGEスコアは、LLMのテキスト生成タスクにおける自動評価の強力なツールであり、特に大規模なデータセットや迅速なフィードバックが必要な開発サイクルにおいてその価値を発揮します。しかし、これらの指標は語彙や構文の表面的な一致に重点を置くため、LLMの真の能力（事実性、論理的一貫性、創造性など）を完全に捉えることはできません。
効果的なLLM評価のためには、BLEU/ROUGEスコアの限界を理解し、人間による誤り分析、そしてBERTScoreやG-Evalといったセマンティックな評価手法との組み合わせが不可欠です。プロンプトエンジニアリングにおいては、ゼロショット、少数例、Chain-of-Thoughtなどの手法を組み合わせ、評価ループを通じて継続的にプロンプトを洗練していくことが、高品質なLLM出力を実現する鍵となります。
参考文献
[1] Papineni, K., Roukos, S., Ward, T., & Zhu, W. J. (2002, July). Bleu: a method for automatic evaluation of machine translation. In Proceedings of the 40th annual meeting on association for computational linguistics (pp. 311-318). https://aclanthology.org/P02-1040/ (2002-07-06, IBM)
[2] Lin, C. Y. (2004, July). ROUGE: A package for automatic evaluation of summaries. In Text summarization branches out: Proceedings of the ACL-04 workshop (pp. 74-81). https://aclanthology.org/W04-1013/ (2004-07-26, University of Southern California)
[3] Fabbri, A. R., Li, W., Durrett, D., & Radev, D. R. (2021). What makes a good summary? faithful or coherent? scoring summaries with a multi-task model. arXiv preprint arXiv:2104.09279. https://arxiv.org/abs/2104.09279 (2021-04-19, University of Michigan et al.)
[4] Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2019). BERTScore: Evaluating text generation with BERT. arXiv preprint arXiv:1904.09675. https://arxiv.org/abs/1904.09675 (2019-04-20, Cornell University et al.)
[5] Pillutla, K., Gopi, S., Harchaoui, Z., & Liu, X. (2022). MAUVE: Measuring the gap between neural text and human text. Advances in Neural Information Processing Systems, 35, 19472-19488. https://arxiv.org/abs/2102.01637 (2021-02-03, University of Washington et al.)
[6] Liu, Y., et al. (2023). G-Eval: A new benchmark for LLM evaluation. arXiv preprint arXiv:2303.04874. https://arxiv.org/abs/2303.04874 (2023-03-08, Google)
