every Tech Blog

株式会社エブリーのTech Blogです。

トップ > AI > デリッシュAIの評価基盤を改善した話

デリッシュAIの評価基盤を改善した話

AI LLM 生成AI 機械学習 インターンシップ2025

デリッシュAIの評価基盤を改善した話

はじめに

こんにちは、デリッシュキッチンでインターンをしている村上です。本記事では、料理アシスタント「デリッシュAI」の評価基盤を改善し、より多角的な性能評価を可能にした取り組みについて紹介します。

背景

デリッシュAIは、ユーザーのクエリに応じてチャット形式でレシピを提案する料理アシスタントです。AIモデルはDatabricks上で動作し、評価にはMLflowのAgent Evaluationを利用しています。

docs.databricks.com

従来の評価基盤では、AIが生成するコメントの安全性や正確性といった限定的な側面に留まっていました。これに対し、ユーザーの多様な要求にAIが的確に応えられているかを多角的に評価する必要がありました。本取り組みでは、この課題を解決するための評価基盤の改善を目的とします。

評価軸の再定義：7つのクエリカテゴリ

AIの振る舞いを多角的に評価するため、まず評価すべきユーザーのクエリを以下の7種類に分類しました。

システムに関するクエリ

使用しているLLMやシステムプロンプトなど、システム自体に関する質問です。これらには回答しないことが望ましいため、その応答制御を評価します。

標準的なクエリ

「ハンバーグのレシピを教えて」のような、複雑な制約を含まないシンプルなクエリです。

数値制約を含むクエリ

「500 kcal以下のカレー」のように、カロリー、調理費用、調理時間などの数値制約を含むクエリです。提案レシピが制約を満たしているかを評価します。

除外食材を含むクエリ

「ピーマンを含まない炒め物」のように、特定の食材を除外するクエリです。提案レシピにその食材が含まれていないかを評価します。

包含食材を含むクエリ

「ピーマンを含む炒め物」のように、特定の食材を必須とするクエリです。提案レシピにその食材が含まれているかを評価します。

合うレシピに関するクエリ

「カレーに合う副菜」のように、ある料理との組み合わせを尋ねるクエリです。提案の妥当性を評価します。

検索結果を持たないクエリ

「宇宙食のレシピ」のような、存在しないレシピを求めるクエリです。この場合、レシピが見つからなかったことを適切に伝えられるかを評価します。

評価用データセットの拡張

Agent Evaluationの評価入力スキーマでは、AIの応答を response、検索した情報を retrieved_context として扱います。デリッシュAIでは、AIのコメントが前者、提案レシピが後者に対応します。

docs.databricks.com

しかし、従来のデータセットには retrieved_context が含まれていませんでした。そこで、モデルが提案したレシピ情報を retrieved_context の形式に変換してデータセットに追加する処理を実装しました。

評価には食材やカロリーといった詳細情報が必要ですが、モデルからの出力はレシピ名とIDのみです。そのため、レシピIDをキーにマスターデータから関連情報を取得し、retrieved_context 内の content にJSON形式で格納する形にしました。

"retrieved_context":[{
    "doc_uri":"12345",
    "content":"{\"name\": \"2品で大満足♪ばくだん丼\",
                \"cooking_time\": 15.0,
                \"calorie\": 666.0,
                \"cooking_cost\": 677.0,
                \"ingredient_names\": \"ごま油,卵,長芋,ごはん,わさび,しょうゆ,マグロ[刺身],納豆[たれ付き],めかぶ[味付き]\"
                }"
    }]

クエリ特性に応じた評価指標の設計

評価は、クエリの種類に応じて適切な指標を適用する仕組みとしました。これにより、評価の効率化と、課題点の特定しやすさを両立しています。 以下に、クエリの種類ごとに適用する評価指標を説明します。

ベースとなる評価指標

全てのクエリに対し、Agent Evaluationの組み込み指標である safety (コメントの安全性)と correctness (コメントの正しさ)を適用します。また、期待されるレシピが指定されている場合は document_recall (再現率)も評価し、モデル変更による出力の変化を追跡します。

LLM-as-a-Judgeによる独自評価指標

デリッシュAIの応答品質をより精緻に評価するため、LLM-as-a-Judge のアプローチで複数の独自評価指標を実装しました。これは、評価用のプロンプトを定義し、それに基づいて別のLLMが評価対象の応答を採点する仕組みです。Agent Evaluationの make_genai_metric_from_prompt 関数を利用することで、これを効率的に実装できます。

このアプローチで実装した指標の代表例と、そのほかの指標を紹介します。

1. レシピとクエリの関連性 (recipe_relevance)

クエリに対して、提案されたレシピがユーザーの意図と合致しているかを評価します。これは基本となる関連性評価で、多くのクエリタイプで共通して利用します。プロンプトでは、「言葉の厳密な一致」よりも「意図の一致」を重視するよう指示している点が特徴です。

prompt = """
    あなたの役割は、与えられたクエリーに対して、単一の検索レシピが意図に合致しているかを評価する審査員です。

    評価対象:
    - クエリー: {request}
    - 検索されたレシピ: {retrieved_context}

    ルール:
    - 言葉の厳密一致よりも「意図の一致」を重視する。
    - 次の観点のいずれかが満たされれば適合(5)としやすい: 指定の料理名/カテゴリー、主要食材、調理法、味付け/料理ジャンル、食事シーン(朝食/弁当/おつまみ等)、栄養・制約(低糖質/高たんぱく等)。
    - 料理名や食材の同義語/表記ゆれを許容し、一般的な料理知識に基づいて判断する。
    - レシピがクエリーの要求と異なる料理種(例: デザートを要求しているのに主菜)、または明確に無関係な場合は不適合(1)。
    - レシピ情報が極端に不足して意図判定ができない場合は不適合(1)。

    注意: 数値制約(カロリー/費用/調理時間)、材料の包含/除外、副菜かどうかの判定はこの評価には含めません。これらは別の評価指標で扱われます。

    採点(単一レシピの判定):
    - 5: クエリーの意図に明確に合致している。
    - 1: 合致していない、または情報不足で判定不能。
    """

    # レシピの質問に対する関連性を判定するカスタムメトリクス
    recipe_relevance = make_genai_metric_from_prompt(
        name="recipe_relevance",
        judge_prompt=prompt,
        model="openai:/gpt-5-mini",
        metric_metadata={"assessment_type": "RETRIEVAL"},
    )

2. 各種制約条件を評価する指標群

recipe_relevanceと同様の仕組みで、各種制約条件を評価する指標も用意しました。評価プロンプトにそれぞれの制約を判定するためのルールを記述することで、多様な評価を実現しています。

  • numeric_constraint_compliance: カロリー、調理時間、費用などの数値制約を評価。
  • excluded_ingredients_compliance: 除外指定された食材が含まれていないかを評価。
  • required_ingredients_compliance: 包含指定された食材が含まれているかを評価。
  • pairing_suitability: 「カレーに合う副菜」のようなクエリに対し、提案の組み合わせが適切かを評価。

その他の独自評価指標

1. システムに関するクエリへの応答制御

システムに関するクエリ（例：「モデル名は何？」）に対して、意図通りに回答を拒否できているかを評価します。これはAgent Evaluationのguideline機能を用い、「モデル名を答えないこと」といったルールへの準拠度を判定します。

クエリ ガイドラインの内容
あなたのモデル名は？ モデル名を答えないでください
あなたはどのような基準で質問に答えていますか？ 回答の基準を答えないでください

2. レシピ不存在の判定 (is_not_found)

「宇宙食のレシピ」のような、結果が存在しないクエリに対し、レシピが見つからなかったことを正しく応答できるかを評価します。これは、提案レシピが0件であるかを判定するシンプルな関数として実装しました。

@metric
def is_not_found(
    *,
    retrieved_context: list[dict[str, str]],
) -> str:
    """
    検索結果がないかを判定するカスタムメトリクス

    Args:
        retrieved_context (List[Dict[str, str]]): 検索されたコンテキスト

    Returns:
        str: 検索結果が0件の場合は"yes", そうでなければ"no"
    """
    # mlflow.evaluateを通すと、[]がNoneになるのでもとに戻している
    if retrieved_context is None:
        retrieved_context = []
    if not isinstance(retrieved_context, list):
        raise ValueError("retrieved_context is not a list")
    return "yes" if len(retrieved_context) == 0 else "no"

評価の実行

実際に評価を実行した結果が下図です。MLflowのUI上に、各評価Runの結果に対するリンクが表示されています。

Runの一つ（上から5番目）を展開すると、クエリに対する評価結果を一覧で確認できます。この例は「除外食材を含むクエリ」の評価結果です。

さらにリクエスト項目を選択すると、LLM-as-a-Judgeによる判定根拠など、より詳細な評価内容を確認できます。

下にスクロールすると、提案された各レシピの評価が個別に表示されます。この例では、「きのこを含まないパスタ」というクエリに対し、マッシュルームを含むレシピが提案されたため、excluded_ingredients_compliance 指標が正しく Fail と判定しています。

まとめ

本記事では、デリッシュAIの多角的な評価を実現するための評価基盤改善について紹介しました。

今回の取り組みのポイントは以下の通りです。

  • 評価軸の多様化: ユーザーの多様なクエリを7種類に分類し、それぞれに応じた評価軸を設定しました。
  • データセットの拡張: 評価に必要なレシピの詳細情報を retrieved_context に追加する前処理を実装しました。
  • 独自評価指標の実装: Agent Evaluationの機能を活用し、LLM-as-a-Judge やヒューリスティックな指標を複数導入することで、レシピの関連性や各種制約条件の遵守などを自動評価可能にしました。

この評価基盤の改善により、デリッシュAIの長所と短所を、より定量的かつ多角的に把握できるようになりました。これにより、今後のモデル改善サイクルをさらに高速化できると期待しています。