【LLM-as-judge 怎麼用：自動分數好看≠可直接上線】
LLM-as-judge 怎麼用？自動分數好看≠可直接上線。先鎖相關性、準確度、完整度與評審提示詞，再定人工抽檢比例；對得上再上線。
RAG 助手儀表板跳出平均分 4.6／5，有人立刻問：「分數夠高，可以上線了吧？」先停一下。LLM-as-judge 怎麼用，先別急著信那排自動分數有多漂亮。先問：評估維度有沒有寫死？評審提示詞有沒有鎖輸出格式？人工抽檢比例有沒有定？分數好看 ≠ 可直接上線；先鎖維度與抽檢，再決定何時信。
本篇鎖定 wrong-signal：用另一個大語言模型（LLM）自動評分 RAG 助手時，亮燈分數 ≠ 可上線／可信。機制框是三件決策：評估維度（相關性／準確度／完整度）、評審提示詞骨架、人工抽檢比例。本篇不寫 RAG 檢索／parent-child／chunking 架構（見 Related），不寫報表輸出抽樣對帳，也不寫代理「上線前」資料來源三核對。資料核對於 2026 年 10 月公開說明（見文末）。未經實測；示範數字皆標示為示範情境。
若你要先管檢索層為什麼答錯，見RAG 混合檢索失敗模式。本篇假設檢索與生成已經跑起來，聚焦「自動評分能不能替你決定上線」。
定義框：LLM-as-judge、三維度、評審提示詞與人工抽檢
> LLM-as-judge（LLM as a judge／以 LLM 當評審） > 用一個大語言模型，依預先寫好的準則，去評另一個模型（或 RAG 助手）產出的文字品質，常見輸出是分數、類別標籤或兩者比較的偏好。Wikipedia 說明：它是以 LLM 評估文本品質、相關性或正確性的做法，作為人工標註與 BLEU／ROUGE 一類字面重疊指標的可擴充替代。見 LLM-as-a-Judge。調查論文亦把可靠性（與人一致、少偏誤、可重現）列為建系統時的核心難題。見 A Survey on LLM-as-a-Judge（arXiv:2411.15594）。本篇只談行銷場景裡 RAG 助手回答的評審，不做評審模型微調百科。 > > 相關性／準確度／完整度（決策用三維度） > 相關性：回答有沒有對上問題，以及有沒有用到檢索內容該用的部分（括號橋：answer relevancy／relevance）。準確度：事實、數字、政策句有沒有站得住，有沒有超出檢索上下文捏造（括號橋：faithfulness／groundedness）。完整度：有沒有漏掉關鍵約束，例如退貨條件、適用市場、時效。Azure AI Foundry 的 RAG 評估器亦分開談 Groundedness（回應有沒有超出 grounding context）與 Response Completeness（相對期望答案有沒有漏關鍵資訊）。見 RAG Evaluators。本篇用三個繁中詞當會議語言，不重寫英文指標百科。 > > 評審提示詞／人工抽檢比例 > 評審提示詞：給評審模型看的說明，至少要寫清維度定義、評分尺度、輸出格式（分數＋簡短理由），必要時附參考答案或少數正反例。Langfuse 文件把典型 prompt 拆成：評估準則、輸入、待評輸出、可選參考答案。見 LLM-as-a-Judge。人工抽檢比例：每批次自動評完後，由人抽多少比例覆核；未達門檻就擋上線。比例依風險定，沒有萬用數字；下文只給示範決策規則。
神話：平均分漂亮，等於助手可以上線
常見捷徑是：接上 RAGAS、DeepEval 或自架 LLM-as-judge，跑一批測試問句，儀表板顯示「相關性 0.92、faithfulness 0.88」，週會結論變成「可以放客服／可以放內容審核」。壓力大、人力又不夠時，這捷徑很誘人。
問題在機制。評審模型本身也是生成模型：它優化的是「依提示詞延續出看起來合理的評語」，不保證跟你公司的人判一致。Wikipedia 與多份調查整理出常見偏誤：位置偏差（先出現的答案較容易贏）、偏長偏差（較長答案較容易贏，即使沒有新資訊）、自我偏好（同家族模型互捧）。見 LLM-as-a-Judge 與 A Survey on LLM-as-a-Judge。SIGIR 指引亦建議：把自動評估當驗證工具，保留人工判斷來校正與稽核。見 Principles and Guidelines for the Use of LLM Judges。
「平均分漂亮」只證明評審管線跑完了；還證明不了：
- 三個維度的定義跟你決策用的門檻一致；
- 評審提示詞沒有在獎長文、獎口吻、獎同家族口吻；
- 抽過的人工樣本跟自動分數對得上。
把未校準的自動分數直接當上線投票依據，就是用未對過人判的訊號驅動放行。會議上較穩的說法：先別上線，直到你能講清楚「維度、提示詞、抽檢比例」三枝至少過了哪幾枝。
為什麼行銷端也需要自動評估 RAG？
機制
行銷常見的 RAG 助手，多半接在知識庫、FAQ、商品說明或政策文件上，對外服務內容審核草稿或客服回覆建議。人工逐條看成本高；只看抽樣又怕漏高風險句。自動評估的價值在於：先 narrowing 風險批次，讓人把時間花在邊界案例，少在每則都從頭讀。
RAGAS 一類框架提供參考答案可選的 RAG 指標（例如 faithfulness、response relevancy）。見 Ragas available metrics。DeepEval、Langfuse 亦把 LLM-as-judge 接到實驗或線上抽樣。這些工具回答「怎麼量」。本篇要回答的是：量完之後，能不能上線。
示範情境（標示：示範，非實測）
| 步驟（示範） | 你看到的 | 常見失敗 |
|---|---|---|
| 接上自動評審 | 平均分 4.5+ | 維度只有「整體品質」，沒拆相關／準確／完整 |
| 週會投影 | 「可上線」綠燈 | 未對過任何人工金標 |
| 客服試跑 | 語氣很完整 | 偏長偏差：長答案分數較高，卻漏退貨期限 |
| 內容審核 | 「合規分」高 | 評審提示詞沒要求點名政策條號 |
示範重點不在工具名，而在「分數管線完成 ≠ 決策門檻完成」。
相關性、準確度、完整度各看什麼？
機制
三維度要分開打分，才看得出「分數好看」到底好看在哪一枝。混成單一「整體分」，最容易掩蓋漏約束或捏造細節。
- 相關性：問題問退貨，回答卻大談運費；或檢索到正確段落，回答卻繞開。對的是「答有沒有對題」。
- 準確度：回答裡的數字、適用地區、生效日，能不能在檢索上下文找到依據；找不到卻寫得很篤定，就是準確度失敗。對的是「有沒有站得住」。
- 完整度：關鍵約束有沒有漏。示範常見漏項：適用市場（港／台／馬）、時效、例外 SKU、必須人工轉接的條件。對的是「決策者要的條件齊不齊」。
Azure 文件把 groundedness 偏 precision、completeness 偏 recall；兩者可以一邊高、一邊低。見 RAG Evaluators。行銷會議用繁中三詞即可，不必先背完英文指標表。
示範情境（標示：示範）
| 維度（示範） | 問題 | 助手回答摘要 | 評審讀法 |
|---|---|---|---|
| 相關性 | 港澳退貨幾天？ | 詳述台灣退貨流程 | 相關性低；勿因文長給高分 |
| 準確度 | 運費門檻？ | 寫「滿 500 免運」但上下文是滿 800 | 準確度失敗 |
| 完整度 | 可否自行取消？ | 只說「可於 App 取消」，漏「已出貨不可」 | 完整度失敗 |
示範讀法：任一決策維度未過，整則回答先標「未驗證」，不進上線池。
限制
- 三維度通過 ≠ 商業話術得體；語氣與品牌調性另開欄，或另做人工審。
- 檢索錯了，準確度與完整度會一起漂；那時要先修檢索，見RAG 混合檢索失敗模式。
- 未經實測各家 Admin UI；步驟以你能匯出的問答對與評分 log 為準。
評審提示詞怎麼寫，才不會只獎長文？
機制
評審提示詞至少要鎖四塊：角色與任務、維度定義、評分尺度、輸出格式。Langfuse 建議在上線前用少量人工標註樣本校準，並用分析工具看評審與人判是否一致。見 LLM-as-a-Judge。
對抗偏長偏差的寫法（示範骨架，非產品模板）：
- 明確寫「長度本身不計分；多餘段落不得加分」。
- 要求評審先列出「依據的上下文句」再給分；列不出依據 → 準確度上限鎖定低分。
- 完整度用 checklist 勾選關鍵約束，勾完才允許高分。
- 輸出固定為 JSON 或「分數｜理由｜引用句」三欄，方便抽檢與對帳。
- 若做兩兩比較，對調順序各跑一次，兩邊結論不一致就標平手或重評（對抗位置偏差）。
步驟
- 先寫一頁「決策用維度」（三維度＋各維度失敗例子，五則以內）。
- 把失敗例子放進評審提示詞的 few-shot，優先放「長文但漏約束」「短文但引用正確」對照。
- 用 20–50 則人工金標（示範量級）跑評審，看不一致集中在哪一維。
- 不一致偏高時，先改提示詞與尺度，再考慮換評審模型；不要先換儀表板顏色。
限制
- 提示詞再完整，也無法替你決定公司風險胃納；上線門檻仍是人定。
- 專有 API 評審模型會隨版本變，重現性較差；調查文獻亦指出 black-box API 不利重現。見 A Survey on LLM-as-a-Judge。重要批次請記錄模型名與日期。
失敗模式：偏長文、位置偏差、同家族自誇
公開文獻反覆出現的三類，剛好也會出現在行銷評審管線：
- 偏長偏差：同一答案加長、不加新資訊，分數仍上升。客服場景會變成「回覆很完整」但其實在繞。
- 位置偏差：兩兩比較時，先出現的答案較容易勝出；對調後結論翻盤。
- 自我偏好／同家族偏好：用同一廠牌模型當評審，可能偏袒同風格輸出。
沒有單一招式能一次解完。文獻常見做法有：對調順序取一致勝、多輪或多元評審投票、附參考答案與明確量表、保留人工金標校正。見 Wikipedia 條目與 Principles and Guidelines for the Use of LLM Judges。實務上，行銷端最低可行是：對調比較＋人工抽檢＋維度拆分；三樣都缺，就不要把平均分寫進上線議程。
人工抽檢比例何時加、何時擋上線？
沒有萬用百分比。較穩的是依風險分層（示範規則，非實測保證）：
| 風險層（示範） | 場景 | 抽檢起點（示範） | 擋上線條件（示範） |
|---|---|---|---|
| 高 | 退貨／法規／價格承諾 | 每批至少 20% 或每則高風險必抽 | 任一準確度金標不一致 → 整批擋 |
| 中 | 一般客服 FAQ | 10% 隨機＋分數邊界帶加抽 | 人判與自動分 Cohen 類一致度低於內部門檻 → 擋 |
| 低 | 內部草稿潤飾 | 5% 抽樣即可啟動 | 連續兩週無高風險失敗可維持；一有投訴加嚴 |
比例只是起點；金標不一致率才決定加嚴或放行。Langfuse 亦強調先用人工標註校準評審，再放大到線上抽樣。見 LLM-as-a-Judge。你的門檻用歷史客訴與法遵要求定，不要抄示範列。
當下面任一成立，先別上線：
- 三維度未分開，只有「整體分」；
- 評審提示詞沒有要求引用依據句；
- 高風險場景抽檢為 0；
- 人判與自動分在金標集上明顯漂，且重跑提示詞後仍漂；
- 你打算用「換一個更強的評審模型」代替抽檢。
行銷場景怎麼套：內容審核與客服回覆（示範）
內容審核草稿
機制：品牌或代理用 RAG 依產品說明產文案草稿，再經 LLM-as-judge 打「合規／相關」分。失敗常見在完整度：漏了必須揭露的限制條件，但語氣流暢、分數仍高。
示範流程：維度鎖「宣稱是否有依據」「限制條件是否齊」→ 提示詞要求列出依據段落 → 高風險宣稱 100% 人工；其餘依邊界分加抽。分數只決定要不要進人工佇列，決定不了能不能直接刊登。
客服回覆建議
機制：助手依知識庫草擬回覆，評審打相關／準確／完整。失敗常見在準確度：把 A 市場政策套到 B 市場；或完整度：漏「需人工轉接」觸發條件。
示範流程：上線前用金標集校準 → 線上只對抽樣 traces 跑評審（控制成本）→ 低分與邊界分進人工 → 週會該看「不一致率」跟「擋下件數」，別只看平均分曲線好不好看。
兩個場景共用同一句會議話：自動分數是篩選器，人工抽檢才是放行閘。
這題跟檢索失敗、報表對帳、上線前三核對差在哪？
| RAG 檢索失敗（LIVE） | 報表輸出驗證（LIVE） | 上線前三核對（LIVE） | 本篇：LLM-as-judge | |
|---|---|---|---|---|
| 時機 | 知識怎麼切、怎麼找回來 | 報表數字產出之後 | 代理要不要上線 | 助手回答自動評完之後 |
| 焦點 | parent-child／混合檢索 | 抽樣對帳／口徑／極端值 | 來源／證據／人手入口 | 維度／提示詞／抽檢比例 |
| 失敗樣子 | 找錯段、切錯塊 | 數字漂亮但對不上 | 接錯庫、無引用 | 分數高但偏長文或漏約束 |
| 決策句 | 先修檢索 | 先別加碼 | 先別上線（入口） | 先別上線（評審未校準） |
四題可 Related，不要混成同一張 checklist。本篇不重開治理「五關」口號。若你要治理層清單，見行銷 AI 治理五道關，本文不重寫那篇結構。
HK／TW／MY 評審時多問的兩句
港台馬團隊常並行多語知識庫（繁中／英文欄位）、多市場政策，以及區域客服工具。若評審提示詞只寫英文 metric 名、沒有寫「適用市場」完整度欄，分數會把「講得很完整的錯誤市場政策」平均成假綠燈。
建議最少拆：
- 市場：這則回答鎖定港、台、還是馬？檢索上下文是否同市場；
- 校準：金標集有沒有含各市場邊界案例（不只總部語言的漂亮回答）。
給港台馬讀者看，不必另造一套英文術語。重點是同一套會議語言：先鎖維度與抽檢，再談上線。
可見 FAQ
Q：LLM-as-judge 怎麼用在行銷 RAG？ A：先鎖三維度（相關性／準確度／完整度），寫清評審提示詞與輸出格式，再用人工抽檢比例校準；分數只做篩選，放行仍看人判一致度。
Q：分數高為什麼還不能上線？ A：評審模型有偏長、位置、自我偏好等偏誤；未對金標前，高分只代表管線跑完。見 Wikipedia LLM-as-a-Judge、Survey。
Q：一定要上 RAGAS 嗎？ A：不必。RAGAS／DeepEval／Langfuse 等是量測選項；本篇決策語言是維度、提示詞、抽檢。工具可換，三枝門檻不能省。
Q：人工抽檢要抽多少？ A：沒有萬用數字。示範起點依風險分層（高風險每批更高比例或全抽）；以人判不一致率加嚴或放寬。
Q：跟報表輸出驗證是同一件事嗎？ A：不是。報表篇管數字對帳；本篇管助手回答的自動評審。見GenAI／AI 報表輸出怎麼驗證。
Q：檢索修好转了，還要 LLM-as-judge 嗎？ A：要。檢索對了仍可能生成漏約束或過度推論；評審管生成層。檢索篇見RAG 失敗模式。
相關閱讀
- RAG 混合檢索失敗模式：parent-child chunking 實戰筆記
- GenAI／AI 報表輸出怎麼驗證：數字好看≠可直接決策
- AI 報表代理上線前三核對
- 行銷 AI 治理五道關：借 HKMA BDAI 的檢查清單
- 若你已懷疑量度基線撐不住決策，可先做一次量度自查。
你下次要放行一個 RAG 助手之前，會先講清楚評估維度與抽檢比例，還是直接讓平均分投票？
By MarTech Guy 資料核對於 2026-10（Wikipedia LLM-as-a-Judge；arXiv A Survey on LLM-as-a-Judge 2411.15594；Langfuse LLM-as-a-Judge；Ragas metrics；Azure AI Foundry RAG Evaluators；arXiv Principles and Guidelines for the Use of LLM Judges 2504.19076）。 soft anon；無客戶名稱；示範情境標示非實測。