跳到主要內容

AG Day 34 LLM-as-judge：用模型評模型

AG Day 34 LLM-as-judge：用模型評模型

執行需求：CPU+API key。AG Day 33（原文連結）建立了黃金問題評估集，也把每題的評分標準拆成「規則式可自動判定」與「需要語意判斷」兩類，但後面那一類至今完全沒有被真正執行過。今天要把它真正接上：用 RESEARCH_AGENT_MODEL 指定的模型，讀取報告全文與對應的評分標準，回傳結構化的判斷結果，這種做法業界通稱 LLM-as-judge（用大型語言模型當評審）。這篇需要真正呼叫模型 API 才能看到完整效果，如果手邊沒有 OPENAI_API_KEY 或 ANTHROPIC_API_KEY，程式一樣可以透過 --dry-run 用固定的模擬評分跑完整條流程，只是評分結果是示範用的假資料，完全不代表任何真實的語意判斷結果。

引言

「用模型評模型」聽起來有點像自己出題、自己改考卷，直覺上會讓人擔心公正性。這個擔心是對的，也正是今天要花不少篇幅討論偏誤的原因。但反過來想，語意層面的品質判斷（這份報告有沒有正確理解問題、論述是否合理、有沒有掉入常見的誤解）本來就沒有更便宜、更快速的替代方案——找真人專家一題一題審閱固然理想，但成本高、速度慢，不可能每次程式碼一改動就跑一輪人工評審。LLM-as-judge 的定位是：在「完全沒有語意判斷」與「昂貴的人工全面審查」之間，提供一個雖不完美但可重複、可規模化、成本相對低的中間選項。

今天的實作分成三個部分：先設計評分提示詞（judge prompt），把 AG Day 33 的評分標準轉換成模型能理解、能給出結構化判斷的指令；接著實作評分函式本身，包含離線模擬模式的降級路徑；最後把評分結果整合進 AG Day 32 的 EvalResult，讓規則式檢查與模型判斷的結果可以並排比較、互相參照。過程中我們會不斷提醒自己 LLM-as-judge 不是萬能的真理，而是一個需要持續校準、需要人工定期抽查驗證的評分工具，用錯了反而會給人一種虛假的安心感。

原理／觀念

LLM-as-judge 常見的三種偏誤

第一種是位置偏誤（position bias）：如果讓模型比較兩份報告的優劣，模型常常偏好排在前面（或後面）的那一份，跟內容本身的品質無關，只跟呈現順序有關。今天我們評分的方式是「單一報告打分數」而不是「兩兩比較」，暫時避開這個問題，但如果未來要做版本比較（例如比較改動前後的兩份報告），就必須刻意把順序隨機化、或兩個方向都跑一次取平均，才能抵銷這個偏誤。

第二種是verbosity偏誤（也稱長度偏誤）：模型常常誤把「寫得更長、更詳細」等同於「品質更好」，即使內容本質上沒有更正確或更有幫助。設計評分提示詞時，必須明確要求模型忽略長度、只針對評分標準裡列出的具體條件打分，並在提示詞裡舉例說明「簡短但正確」應該打高分、「冗長但答非所問」應該打低分。

第三種是自我偏好（self-preference bias）：如果評分模型跟產生報告的模型是同一家廠商甚至同一個模型，有研究顯示模型會傾向給自己風格相近的輸出更高的分數。今天的做法是讓 RESEARCH_AGENT_MODEL 同時扮演產生報告與評分兩種角色，這在教學情境下可以接受，但正式專案裡建議用不同廠商或不同版本的模型來擔任評審，降低自我偏好造成的評分虛高。

評分要基於明確標準，不要問模糊的「好不好」

今天的評分提示詞不會問模型「這份報告寫得好嗎，給幾分」，而是把 AG Day 33 RUBRICS 裡標記為 auto_checkable=False 的每一條標準，逐條列給模型，要求它針對每一條分別回答「符合」或「不符合」，並附上簡短理由。這種逐條判斷的方式比要求一個綜合分數更可靠，因為每一條的判斷範圍更窄、更具體，模型出錯的機會也相對較小，而且逐條記錄下來的理由本身也是有用的除錯資訊，能讓人快速看出模型判斷的依據是否合理。

完整實作

第一步：在 evals.py 定義 judge 用的結構化輸出模型 RubricJudgement 與 JudgeResult，沿用 AG Day 8 學過的 Pydantic 結構化輸出習慣：

# research-agent/src/research_agent/evals.py（新增：judge 結構化輸出）
from pydantic import BaseModel, Field


class RubricJudgement(BaseModel):
    """模型對單一評分標準的判斷。"""
    description: str
    satisfied: bool = Field(description="這份報告是否符合這條評分標準")
    reasoning: str = Field(description="簡短說明為什麼符合或不符合，一到兩句話")


class JudgeResult(BaseModel):
    """一次 LLM-as-judge 評分的完整結果，包含逐條判斷。"""
    case_id: str
    judgements: list[RubricJudgement]
    satisfied_count: int
    total_count: int

第二步：設計評分提示詞。這裡把系統提示詞跟評分標準清單組合起來，明確要求模型逐條判斷、忽略長度、只根據標準本身給結論：

# research-agent/src/research_agent/evals.py（新增：評分提示詞）
JUDGE_SYSTEM_PROMPT = """你是一個嚴格但公正的研究報告評審。
你會收到一份研究報告與一組評分標準，請針對每一條標準逐一判斷「符合」或「不符合」。
評分原則：
1. 只根據列出的標準判斷，不要因為報告寫得長或用詞華麗就給比較寬鬆的判斷。
2. 每一條都要附上一到兩句話的簡短理由，理由要能對應報告裡的具體內容。
3. 若報告完全沒有處理某條標準對應的內容，一律判定為不符合。
"""


def build_judge_prompt(report: str, rubric_items: list[RubricItem]) -> str:
    """把報告與評分標準組成要交給模型的使用者提示詞。"""
    standards = "\n".join(f"{i+1}. {item.description}" for i, item in enumerate(rubric_items))
    return f"評分標準：\n{standards}\n\n報告內容：\n{report}"

第三步：實作 judge_report，離線模擬模式下回傳固定的示範判斷（一律標示為模擬結果、不代表真實判斷），正式模式則呼叫既有的 llm.chat 搭配結構化輸出：

# research-agent/src/research_agent/evals.py（新增：judge_report 主函式）
from research_agent.config import load_settings


def judge_report(case_id: str, report: str, rubric_items: list[RubricItem]) -> JudgeResult:
    """對一份報告逐條套用評分標準，回傳結構化的判斷結果。"""
    if not rubric_items:
        return JudgeResult(case_id=case_id, judgements=[], satisfied_count=0, total_count=0)

    settings = load_settings()
    if settings.is_dry_run:
        judgements = [
            RubricJudgement(description=item.description, satisfied=True,
                             reasoning="離線模擬模式：固定回傳符合，非真實模型判斷。")
            for item in rubric_items
        ]
    else:
        from research_agent.llm import chat  # AG Day 3-8 建立的對話與結構化輸出介面
        prompt = build_judge_prompt(report, rubric_items)

        class JudgementList(BaseModel):
            items: list[RubricJudgement]

        response = chat(
            messages=[
                {"role": "system", "content": JUDGE_SYSTEM_PROMPT},
                {"role": "user", "content": prompt},
            ],
            response_model=JudgementList,
        )
        judgements = response.items

    satisfied = sum(1 for j in judgements if j.satisfied)
    return JudgeResult(case_id=case_id, judgements=judgements, satisfied_count=satisfied, total_count=len(judgements))

第四步：呼應「常見錯誤與踩雷」會提到的呼叫失敗問題，先把 judge_report 包一層跟 AG Day 7 一致的重試邏輯，避免單次模型呼叫逾時或格式不符就讓整個評估中斷：

# research-agent/src/research_agent/evals.py（新增：帶重試的 judge 呼叫）
from tenacity import retry, stop_after_attempt, wait_exponential


@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, max=10))
def judge_report_with_retry(case_id: str, report: str, rubric_items: list[RubricItem]) -> JudgeResult:
    """對 judge_report 包一層指數退避重試，逾時或暫時性錯誤時自動重試三次。"""
    return judge_report(case_id, report, rubric_items)

第五步：寫一個批次評分函式 run_full_evaluation，把整組黃金問題的規則式基準評估與 LLM-as-judge 評分一次跑完，彙整成一份可以直接列印或存檔的總表：

# research-agent/src/research_agent/evals.py（新增：整合規則與模型評分）
def run_full_evaluation(cases: list[EvalCase], reports: dict[str, str], known_sources: list[str]) -> list[dict]:
    """對每一筆評估案例同時跑規則式基準評估與 LLM-as-judge，回傳整合後的總表。"""
    rows = []
    for case in cases:
        report = reports.get(case.case_id, "")
        baseline = run_baseline_eval(case, report, known_sources, step_count=3)
        _, manual_items = split_rubric(case.case_id)
        judge_result = judge_report_with_retry(case.case_id, report, manual_items)

        rows.append({
            "case_id": case.case_id,
            "baseline_passed": baseline.passed_baseline,
            "judge_satisfied": judge_result.satisfied_count,
            "judge_total": judge_result.total_count,
        })
    return rows

第六步：把 LLM-as-judge 的結果跟 AG Day 32 的規則式基準評估並排呈現，寫一個整合示範腳本：

# research-agent/scripts/run_judge_demo.py
from research_agent.evals import EvalCase, run_baseline_eval, judge_report, split_rubric

def main():
    case = EvalCase(case_id="gq-001", question="什麼是檢索增強生成（RAG）？",
                     required_keywords=["檢索", "向量", "生成"], min_citations=1)
    demo_report = (
        "# 什麼是檢索增強生成（RAG）？（示範報告）\n"
        "RAG 先把文件向量化存進向量資料庫，再用檢索找出相關片段，"
        "最後把片段交給模型生成答案。［來源：示範資料］"
    )

    baseline = run_baseline_eval(case, demo_report, ["示範資料"], step_count=3)
    print(f"規則式基準評估：{'通過' if baseline.passed_baseline else '未通過'}")

    _, manual_items = split_rubric(case.case_id)
    judge_result = judge_report(case.case_id, demo_report, manual_items)
    print(f"LLM-as-judge：{judge_result.satisfied_count}/{judge_result.total_count} 條標準符合")
    for j in judge_result.judgements:
        print(f"  [{'符合' if j.satisfied else '不符合'}] {j.description}：{j.reasoning}")

if __name__ == "__main__":
    main()

執行示範（離線模擬模式）：

cd research-agent
uv run python scripts/run_judge_demo.py

示範輸出：

規則式基準評估：通過
LLM-as-judge：1/1 條標準符合
  [符合] 有解釋向量化與相似度檢索的基本概念：離線模擬模式：固定回傳符合，非真實模型判斷。

若設定了 OPENAI_API_KEY 或 ANTHROPIC_API_KEY，同一支腳本會改成真正呼叫模型評分，理由欄位會變成模型針對報告內容給出的具體說明，而不是這句固定的模擬提示。

常見錯誤與踩雷

第一個常見錯誤是把 LLM-as-judge 的結果當成絕對真理，不再做任何人工抽查。模型評審跟模型本身一樣會犯錯，尤其在評分標準寫得不夠具體、或報告內容處於模糊地帶時，判斷結果的可靠度會下降。實務上建議定期抽出一部分評分結果（例如每次評估集執行後抽 10%）讓人工複核，追蹤模型評審跟人工判斷的一致率，一致率明顯下降時就要重新檢視評分提示詞或評分標準本身。

第二個常見錯誤是評分提示詞裡混雜了太多條標準，導致模型在一次回應裡要同時判斷五六條甚至更多標準，判斷品質會隨著標準數量增加而下降。如果一題的評分標準特別多，建議拆成多次呼叫，每次只處理兩三條標準，雖然會增加 API 呼叫次數與成本，但能提升每一條判斷的可靠度，這是成本與品質之間需要視情況拿捏的取捨。今天的示範裡每題只有一到兩條需要模型判斷的標準，還沒有真正碰到這個問題，但評估集規模一大，這個取捨就會變得很現實。

第三個常見錯誤是忽略了模型呼叫本身可能失敗（逾時、格式不符預期），沒有像 AG Day 7 那樣做重試與例外處理，一旦評分過程中某次呼叫失敗，整個評估集的執行就會中斷。正式串接時 judge_report 應該包一層跟 AG Day 7 一致的重試邏輯，並在多次重試失敗後明確標記這一題「評分失敗」，而不是讓整個批次評估因為一題出錯而全部停擺。

效能與實務提醒

LLM-as-judge 每評一題都要付出一次真實的 API 呼叫成本，如果評估集有上百題、每題又有好幾條需要模型判斷的標準，一次完整評估的花費可能不小。實務上建議先用今天的離線模擬模式驗證整條流程的邏輯是否正確（提示詞組裝、結構化輸出解析、結果彙整），確認沒有程式錯誤之後，再花真正的 API 費用跑一次完整評估，避免因為程式邏輯的小錯誤而重複燒錢。

另外，評分模型的選擇也值得思考：不一定要用跟產生報告一樣強大（也一樣昂貴）的模型來當評審。很多情境下，一個較小、較便宜的模型只要評分提示詞設計得夠明確、標準夠具體，也能做出合理的判斷，這跟 AG Day 36 要討論的模型分級策略是同一個思路——不是所有工作都需要動用最貴的模型。

最後，LLM-as-judge 的評分結果本身也應該被記錄下來、可追蹤版本歷史，這樣才能回答「這次改了評分提示詞之後，同一批舊報告的評分有沒有系統性地變高或變低」這種校準問題，而不是每次評分都是一次性的、無法比較的孤立事件。這也是為什麼今天 run_full_evaluation 回傳的是一份結構化的清單而不是直接印出來就丟掉，方便之後接上 AG Day 35 的追蹤平台時，能直接把這份總表寫進去，不需要重新設計資料格式。

小結

今天我們把 AG Day 33 標記為「需要語意判斷」的評分標準真正接上模型：設計了逐條判斷、忽略長度、附理由的評分提示詞，實作了 judge_report 搭配離線模擬的降級路徑，也把結果整合進既有的評估流程，跟規則式基準評估並排呈現。同時我們也誠實面對了 LLM-as-judge 本身的三種常見偏誤：位置偏誤、長度偏誤、自我偏好偏誤，這些偏誤不會因為换了模型就自動消失，需要在提示詞設計與抽查流程裡持續留意。

新增的術語：LLM-as-judge（用大型語言模型評估其他輸出品質的評分方法）、位置偏誤與長度偏誤（模型評分時容易受呈現順序或篇幅長短影響、而非只看內容本質的系統性誤差）、自我偏好偏誤（模型傾向給風格相近的輸出更高評分的現象）。這三種偏誤都不是理論上的假設，而是實際應用 LLM-as-judge 時經常遇到的真實問題，設計評分流程時務必提前考慮。

結語

有了規則式基準評估與 LLM-as-judge 兩層評分機制，research-agent 現在已經有一套相對完整的品質評估流程。但這些評分結果目前都只是印在終端機上，跑完就消失，沒有任何地方能長期留存、視覺化呈現，也沒辦法輕易看出「這個月的平均通過率跟上個月比起來如何」這種趨勢問題。

明天，我們會進入「AG Day 35 追蹤平台：Langfuse 觀測實戰」，把 research-agent 的執行過程與今天的評估結果接上正式的可觀測性平台，讓每一次代理執行、每一次評分都留下可以回溯、可以視覺化查詢的完整紀錄，這需要一個外部服務帳號才能完整體驗全部功能。

延伸資源

  • Anthropic 官方文件關於評估與 LLM 評審的討論：https://docs.anthropic.com/。說明結構化評分提示詞設計與常見偏誤的緩解方式。
  • OpenAI 官方文件的結構化輸出（Structured Outputs）指南：https://platform.openai.com/docs/。response_model 對應的底層機制請以官方文件為準。
  • Pydantic 官方文件：https://docs.pydantic.dev/。巢狀模型（如 JudgementList 內含 RubricJudgement 清單）的驗證行為可在此查閱完整規格。
標籤：

留言

張貼留言

這個網誌中的熱門文章

Day 2 變數與資料型別

Day 2 變數與資料型別 引言 寫程式的過程中，變數與資料型別是處理資料的基礎。變數是存放資料的容器，資料型別則決定這筆資料有哪些特性、可以進行哪些操作。學會定義變數、認識各種資料型別，是學好 Python 的關鍵一步。 這篇文章會帶你了解 Python 中變數的觀念、如何定義變數，以及常見的資料型別，包括整數、浮點數、字串、布林值，還有串列、元組、字典與集合等容器型別。我們也會介紹變數的命名規則與撰寫風格建議，以及如何用 type() 檢查資料型別。 什麼是變數？如何在 Python 中定義變數 變數是在程式執行時用來存放資料的名稱。透過定義變數，我們可以給一筆資料一個名字，並在程式的其他地方用這個名字取用該筆資料。在 Python 中，變數不需要事先宣告型別，因為 Python 是動態型別語言，變數的型別由指定給它的值決定。 定義變數的基本語法 在 Python 中定義變數非常簡單，只要用賦值符號 = 把值指定給變數即可。例如： x = 5 # 定義變數 x，並把整數 5 賦值給它 name = "Alice" # 定義變數 name，並把字串 "Alice" 賦值給它 在這裡，x 是一個變數，被賦予整數 5；name 是另一個變數，被賦予字串 "Alice"。 變數的更新與覆寫 變數的值可以修改，也就是說，我們可以在程式的不同地方給同一個變數新的值。例如： x = 10 # x 最初被賦予 10 x = 15 # x 的值現在被更新為 15 這樣就能依照需求，在程式執行過程中靈活調整變數的值。 Python 的動態型別系統 Python 和某些靜態型別語言不同，定義變數時不需要宣告型別。賦值時，Python 會根據值自動判斷變數的型別。例如： x = 5 # x 是整數 x = 3.14 # x 變成浮點數 x = "Hi" # x 變成字串 同一個變數在程式執行過程中可以存放不同型別的值，這是 Python 的彈性之一。 常見資料型別 在 Python 中，資料型別決定我們可以對變數進行哪些操作...
張貼留言
閱讀完整內容

Day 1 Python 簡介與環境設定

Day 1 Python 簡介與環境設定 引言 在現在的科技環境裡，程式設計已經是一項重要技能。無論你是對資料科學有興趣、想成為開發者，或是想踏入人工智慧（AI）領域，學會寫程式都能明顯提升你的競爭力。在眾多程式語言中，Python 因為語法簡單、功能強大、應用範圍廣泛，成為許多人進入程式世界的第一選擇。這篇文章會帶你認識 Python 的背景與優勢，並一步步教你在不同系統上安裝與設定 Python 開發環境，最後寫出第一支 Python 程式。 為什麼選擇 Python？ Python 是一種高階程式語言，由 Guido van Rossum 在 1991 年發布。Python 的設計哲學強調程式碼的可讀性，並用縮排來定義程式區塊，這點和許多使用大括號的語言不同。簡潔的語法讓它成為初學者的理想選擇；就算是經驗豐富的開發者，也能用它完成複雜的專案。 Python 的優勢如下： 簡單易學 ：Python 的語法清楚、結構簡潔，初學者很快就能上手。和其他語言相比，學習曲線相對平緩，不需要先弄懂一堆複雜觀念，就能開始寫程式。 應用範圍廣泛 ：從資料科學、網頁開發、人工智慧、機器學習、自動化測試到網路爬蟲，Python 都有大量開源函式庫與工具支援，而且在這些領域都扮演關鍵角色。 豐富的函式庫與框架 ：Python 的函式庫生態系非常龐大。做資料分析有 NumPy、Pandas；開發網站有 Django、Flask；做深度學習有 TensorFlow、PyTorch。各種需求幾乎都能找到對應的套件，讓開發更有效率。 跨平台支援 ：Python 支援 Windows、macOS、Linux 等作業系統，程式通常不需要太多修改就能跨平台執行，讓開發與部署更有彈性。 活躍的社群 ：Python 擁有龐大的開發者社群。學習或開發上遇到問題，幾乎都能在社群與論壇（例如 Stack Overflow）找到答案，對初學者來說是很強的後盾，也能減少卡關時的挫折感。 Python 的應用領域 Python 的流行與強大功能，讓許多領域都開始大量使用它。以下是幾個常見的應用方向： 資料科學 ：隨著大數據與人工智慧興起，資料科學大量使用 Python。NumPy、Pandas 與 Matplotlib 等工具能處理和分析龐...
張貼留言
閱讀完整內容

Python 從入門到 PyTorch 深度學習：開啟 AI 世界的大門

Python 從入門到 PyTorch 深度學習：開啟 AI 世界的大門 隨著人工智慧（AI）與深度學習（Deep Learning）快速發展，越來越多人對這些技術產生興趣。不論你是想踏入 AI 領域的初學者，還是已經有程式基礎的開發者，學好 Python 與深度學習框架（例如 PyTorch），都能為你打開更多可能。 為什麼選擇 Python？ Python 已經是資料科學與人工智慧領域的首選語言。它的語法簡潔、容易上手，而且擁有龐大的生態系與大量開源函式庫。無論是資料處理、資料視覺化，還是建立機器學習與深度學習模型，Python 都能勝任。對想進入 AI 或資料科學領域的人來說，它幾乎是必備工具。 PyTorch 是什麼？ PyTorch 是由 Meta（原 Facebook）AI 研究團隊開發的開源深度學習框架，以易用、靈活和動態計算圖著稱，是許多 AI 研究人員與開發者的首選。相較於其他框架，PyTorch 的寫法更貼近原生 Python，對初學者相對友善。無論是簡單的實驗，還是複雜的深度學習模型，PyTorch 都能提供強大的支援。 這個系列能帶給你什麼？ 這個系列會從 Python 的基礎開始，帶你一步一步學習，最後能自己用 PyTorch 建立深度學習模型。即使你完全沒有寫過程式，也能跟著文章的節奏累積技能，理解 AI 與深度學習的核心觀念。 本系列涵蓋的主題 Python 基礎：從變數、條件判斷到函式與模組。 資料處理工具：用 NumPy 與 Pandas 有效率地操作資料。 資料視覺化：用 Matplotlib 與 Seaborn 把資料畫成圖表。 深度學習的數學基礎：線性代數、微積分與機率。 PyTorch 入門：理解張量、模型建構與 GPU 加速。 基礎深度學習模型：CNN 與 RNN 的實作應用。 深度學習專案實戰：從資料前處理到模型部署的端到端流程。 誰適合這個系列？ 程式初學者 ：如果你對 AI 充滿好奇，卻還沒寫過程式，系列的第一部分會帶你快速上手 Python，並幫助你理解深度學習的基本觀念。 資料科學愛好者 ：如果你已經熟悉一些資料處理方法，進階部分會教你如何用 PyTorch 建構深度學習模型。 開發者與研究人員 ：想更深入了...
張貼留言
閱讀完整內容