<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>GenAI on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/genai/</link><description>Recent content in GenAI on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/genai/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE 面試指南 Part 50：生產環境 GenAI 自動化評估管線與 LLM-as-a-Judge 漂移監控</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/</link><pubDate>Mon, 08 Jun 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/</guid><description>多數工程師的做法：每次模型更新後，手動抽幾十筆對話，憑感覺評估品質有沒有退步。 問題是，樣本量不足無法代表真實用戶分佈，而且人工評估無法在 CI/CD 流程中自動執行。 正確的做法：建立三層自動化評估管線，用統計學方法精準抽樣 5% 送 LLM 裁判， 其餘 95% 走免費傳統指標，並在 Sigma 2 漂移時自動觸發 PagerDuty 警報。
面試情境 你的團隊正在維護一個 B2B SaaS 平台上的 RAG Agent，每天處理約 50 萬筆客戶支援對話。 上週你們將底層模型從 Gemini 1.5 Pro 升級至 Gemini 2.0 Flash，同時調整了 System Prompt。 產品團隊要求你在 48 小時內確認新系統的回答品質沒有惡化，並建立一套長期可用的 自動化觀測機制。你有 Vertex AI 的使用權限，預算受限，你會怎麼設計這套系統？
一、核心問題：為什麼 GenAI 的品質監控比傳統服務更難？ 傳統後端服務的品質監控相對直觀：HTTP 4xx/5xx 錯誤率、P99 延遲、資料庫查詢失敗數。 這些指標全都是客觀的、可計算的、接近零成本的。
GenAI 系統的品質卻天生是主觀的：一個回答是否「夠好」，取決於事實準確度、 語氣適切性、上下文相關性、甚至法律合規性。這帶來三個根本性挑戰：
挑戰一：評估本身就需要智慧 你無法用 if response == expected_answer 來評分自由文本。傳統 BLEU / ROUGE 指標 只能衡量字面重疊，無法判斷語意正確性。唯一可靠的裁判是另一個 LLM——但這就是 評估成本 ≥ 生產成本的陷阱：</description></item></channel></rss>