上個月，我發布咗一個令我真心自豪嘅管線變更。一次 prompt 重寫。一個全上下文審查步驟。一個詳細嘅評分標準，用嚟捕捉重複同確保各片段之間嘅結構多樣性。
我部署咗佢。觀察咗六個禮拜。同自己講緊佢喺度正常運作。
然後我構建咗一個評估框架。喺 7 種語言嘅 40 個真實生產集數上面運行。結果發現，審查步驟——我精心設計嗰一步——正喺度可測量咁令腳本變差。
唔係中性。係變差。
每個片段嘅對話得分 3.34（滿分 5 分）。大綱得分 3.01。而最終腳本，喺審查通過之後呢？2.91。
嗰個旨在改進腳本嘅步驟，正喺度降低超過 12% 嘅質量。
呢個轉變——由「我以為佢喺度運作」到「我知道佢冇」——始於幾個禮拜前。我當時喺度睇緊 Andrew Ng 喺 DeepLearning.AI 上面嘅 Agentic AI 課程，佢強調咗一個聽落顯而易見但其實唔係嘅觀點：評估同追蹤係任何 agentic 系統嘅基礎。 冇佢哋，你就係喺黑暗度 debug。有佢哋，你就確切知道鏈嘅邊個環節斷咗。
我已經進行咗幾個月嘅臨時腳本品質檢查——好似話輪長度比例同講者平衡呢類結構性指標，再加一個比較 A/B prompt 變體嘅 LLM 裁判。佢哋捕捉到明顯嘅 regression。但佢哋唔夠全面。佢哋淨係覆蓋一個階段（對話），一次一種語言，並且係為 prompt A/B 測試設計嘅，唔係為全管線品質審計設計嘅。
Andrew 關於追蹤嘅觀點深深觸動咗我。我嘅管線每個集數有五次主要嘅 LLM 調用——研究、大綱、每段對話、開場/收尾同審查——再加一次 ElevenLabs TTS 處理。我對其中一次有品質指標。其餘四次完全依賴直覺信任。
所以我構建咗一個真正嘅評估系統。完整。多維。可重複運行。呢度係佢發現嘅結果，我喺一日內發布嘅六項修復，同埋實際改善咗啲乜。
基線：三個改變一切嘅數字
我由我嘅生產資料庫度評估咗 40 個已完成嘅集數——覆蓋全部 7 種語言（en, vi, ja, ko, es, zh, fr）同 10 種播客風格——使用三套評分標準，每套五個維度。一個 LLM 裁判（GPT-5.6-terra）為每個階段打分。
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3.34 | Factual Grounding: 2.17 |
| Outline (research + structure) | 3.01 | Citation Credibility: 1.28 |
| Final Script (post-review) | 2.91 | Publishability: 1.95 |
三件事即刻跳咗出嚟：
1. 審查通過正喺度令腳本退化 0.43 分。 對話得分 3.34。審查之後呢？2.91。旨在改進品質嘅步驟正喺度移除品質。
2. 所有引用 URL 都係唔透明嘅重定向。 每個大綱入面嘅每個「源 URL」都指向 vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ...。呢啲對點擊嘅人類有效，但喺自動審查者睇落完全係捏造嘅。344 個事實有源 URL。零個有 resolved_url——一個仲未存在嘅欄位。
3. 可發布性（Publishability）係成個管線最低嘅維度（1.95）。 根據評估裁判嘅判斷，真正嘅播客主唔會用自己嘅名義發布呢啲腳本。可檢測嘅 AI 模式：相同嘅片段開頭語、通用嘅過渡語、缺少主持個性。
評估畀咗我一個精確排名嘅待修復列表。我將嗰日剩低嘅時間全部花咗喺修復上面。
六項修復（及其測量嘅影響）
修復 1：引用 URL——0% 到 100% 解析
之前： 344 個研究事實當中有 0 個有 resolved_url。每個 URL 都睇落係捏造嘅。
修復： 一個 60 行嘅 URL 解析器，喺大綱生成期間運行，追蹤 Vertex AI 重定向到實際來源，並存儲兩個 URL（原始 URL 用於 Google 服務條款合規，已解析 URL 用於其他一切用途）。
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
之後： 今日新集數度 23 個研究事實當中嘅 23 個都有 resolved_url 已填充——真實嘅 URL，例如 simonwillison.net、axios.com、thinkingmachines.ai。100% 解析。
修復 2：更換審查模型（Gemini → DeepSeek）
之前： Gemini 3.5 Flash 運行審查通過。佢做出輕量、保守嘅編輯：將「Exactly!」改成「No question about it!」，但大多保留原始文字。佢添加嘅填充語令對話變得平淡。音頻標籤密度下降。類型-詞符比下降。話輪數膨脹。
修復： 將審查通過更換為 DeepSeek v4-pro（384K 最大輸出，設定 96K 上限）。令提供商可配置：
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
驗證： 已部署到生產環境。一個越南語科技新聞集數喺 DeepSeek 審查下通過完整管線——10.3K → 11.6K tokens，喺 121 秒內完成，需要 0 次收緊處理。第二個集數（英語）處理 7.9K → 17K tokens，耗時 203 秒。DeepSeek API 密鑰保存喺 Google Cloud Secret Manager 度，部署時通過 service.yaml 自動注入。
修復 3：大綱自我批評（+0.50 改善）
之前： 大綱由 Gemini 直接到用戶，冇任何內部品質檢查。平均得分：3.01。
修復： 添加咗一個自動化批評步驟。DeepSeek v4-pro 用 6 維度評分標準（5 個大綱維度加片段數量）評估大綱，返回分數 + 具體回饋，並將批評存儲喺播客元數據度。
然後我進行咗一個對照實驗：攞 6 個大綱得分低過 3.0 嘅集數，運行 DeepSeek 批評，將回饋作為重新生成指令回傳畀 Gemini，然後重新打分。
之後： 喺 6 個集數上總體改善 +0.50。
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3.33 | 4.17 | +0.83 |
| Research Depth | 2.67 | 3.17 | +0.50 |
| Citation Credibility | 1.00 | 1.50 | +0.50 |
| Structural Logic | 3.67 | 4.17 | +0.50 |
| Audience Fit | 2.17 | 2.33 | +0.17 |
最差嘅集數由 1.80 升至 3.20（+1.40）。6 個當中得 1 個變差咗。批評而家喺生產環境度預設啟用——每個新大綱喺用戶睇到之前都經過呢個品質檢查。
修復 4：單片段大綱而家強制失敗
之前： 評估顯示，只有一個片段同零研究事實嘅集數得分低至 2.07。呢啲係管線未當作失敗處理嘅失敗案例。
修復： 如果大綱生成器喺恢復嘗試之後產生少過 3 個有效片段，則播客被標記為 FAILED。唔會再有單片段大綱到達用戶手中。喺下一次創建嘗試時，用戶嘅額度被釋放以重試。
修復 5：中文本地化規則
之前： 中文集數得分 2.88——7 種語言當中最低。翻譯痕跡（英文習語直譯）、相同嘅片段開頭語、預設嘅英文主持名（Alex/Maya）而非中文名（明輝/曉雯）。
修復： 編寫咗中文特定對話規則：原生會話模式（不是...而是...結構）、適當嘅句末助詞（吧/啊/呢）、反翻譯指南（千祈唔好直譯「medical miracle」）、世界盃集數嘅中國足球隱喻，同埋有鮮明個性嘅地區特定主持檔案。
中文對話模板由重用英文預設值，發展到擁有自己 80 行嘅指南，涵蓋會話模式、表達唔同意見嘅措辭，同每種播客風格嘅受眾特定框架。
修復 6：非英語語言嘅預設主持名
之前： 多個非英語集數嘅主持叫 Alex 同 Maya。地區特定嘅主持檔案存在，但大綱生成器入面嘅回退路徑被硬編碼為英文預設值。
修復： 通過語言感知嘅檔案解析管線追蹤修復。近期生產集數而家使用 翔太/健一（ja）、Mạnh/Nga（vi）、Hugo/Camille（fr）、明輝/曉雯（zh）。七月提交嘅代碼已經修復咗邊緣函數同創建流程——剩餘嘅回退喺大綱生成器本身度。
評估框架（可復用）
發現呢一切嘅框架大約 500 行 Python、三個評分標準檔案（每個 5 個維度）、一個共享嘅 GPT-5.6-terra 裁判同一個編排器：
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
我仲構建咗一個實驗層用於 A/B 比較：
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
喺任何管線變更之後運行 python docs/pipeline/evals/run.py --full，約 8 分鐘內獲得報告。運行 experiments/review_ab.py --episodes 10 比較模型。結果按日期歸檔以追蹤趨勢——想知道今個月相比上個月品質有冇改善？對比分數就得。
完整嘅 40 個集數評估 API 調用成本約 $1-2。實驗成本更低。作為回報，你獲得嘅訊號——一個精確列出管線中邊啲階段同維度需要關注嘅排名列表——呢個係我構建過嘅最平 debug 工具。
仲未解決嘅問題
DeepSeek 審查 A/B 實驗需要完整嘅生產 prompt。 實驗腳本使用咗一個簡化嘅 15 行 prompt。生產審查使用 80 行 prompt，包含反重複規則、口頭禪配額、編輯護欄同長度政策。使用簡化 prompt 時，DeepSeek 表現出基本中性嘅結果（-0.04）。使用完整 prompt 喺生產環境度，管線喺英語同越南語入面成功完成。我需要更新實驗以反映生產環境並重新運行。
中文本地化需要驗證。 規則喺紙面上睇落正確，主持檔案已編寫，對話指南已到位。但我仲未喺新嘅中文集數度運行評估以確認得分由 2.88 上升咗。呢個係今個禮拜嘅優先事項。
我需要喺新集數度重新運行完整嘅 40 個集數評估。 所有六項修復都已部署。下一步係提取喺呢啲變更之後生成嘅 40 個集數，通過相同嘅評估運行佢哋，同歷史基線進行比較。如果最終腳本得分由 2.91 上升到 3.0 以上，並且引用可信度由 1.28 提升到合理水平，我就知道呢啲變更端到端咁奏效咗。
三問管線審計
經過呢次經歷，我而家用三個問題審計每個管線變更：
1. 每個步驟之間係咪有品質關卡？ 我嘅大綱由 Gemini 直接到用戶。添加批評步驟喺任何人睇到之前就捉住咗最差嘅大綱。每個管線步驟都需要品質檢查——根據明確標準進行自動化 LLM 評估。
2. 每個步驟喺被測量時係咪真係改善咗品質？ 運行佢並假設佢有幫助係唔夠嘅。你需要同一內容上面嘅字面前後分數。我嘅審查步驟喺俾我測量之前，降低咗腳本品質六個禮拜。先測量，唔做任何假設。
3. 我能夠判斷係邊個維度出咗問題？「品質唔好」係不可操作嘅。「引用可信度係 1.28，因為 100% 嘅 URL 係唔透明嘅重定向」係可操作嘅。每個階段嘅多維評分標準話你知應該望邊度。喺評估之前，我花咗幾個鐘調查我嘅審查步驟。有咗評估，我淨係花咗幾秒——數字直接指向咗可發布性同審查模型。
常見問題
運行 LLM 評估唔會變貴咩？
完整嘅 40 個集數評估 API 調用成本約 $1-2（GPT-5.6-terra，總計約 420K tokens）。A/B 實驗成本更低。作為回報，你獲得嘅訊號——一個精確列出管線中邊啲階段需要關注嘅排名列表——呢個係我構建過嘅最平 debug 工具，比用戶喺壞咗嘅集數上浪費嘅額度更平。
點解每個階段 5 個維度？點解唔淨係用「整體品質」？
「整體品質」話你知有啲嘢唔啱。佢唔話你知係乜。當我睇到引用可信度為 1.28 時，我即刻知道 URL 壞咗。當我睇到可發布性為 1.95 時，我知道 AI 痕跡係可檢測嘅。五個維度畀你一個鑑別診斷。一個維度只係畀你一個發燒探熱針。
點樣保持 LLM 裁判嘅一致性？
相同嘅模型（GPT-5.6-terra），相同嘅溫度（0.0），相同嘅推理力度（medium），每次都使用相同嘅評分標準 prompt。分數帶時間戳歸檔，等你跨日期比較。更換裁判會改變基線——揀定一個並堅持落去。
當裁判本身出錯時點算？
評分標準包含每個分數嘅必需理據——裁判必須引用內容中嘅具體證據。我仲對所有 7 種語言嘅 10 個集數進行咗手動定性審查嚟校準裁判。LLM 分數同我嘅主觀判斷緊密匹配。對於 LLM 可能唔可靠嘅關鍵維度（例如需要文化判斷嘅「可發布性」），人工抽檢至關重要。
我喺夜晚同週末獨自開發 DIALOGUE，一個 AI 播客平台。我寫低沿途學到嘅嘢。
如果你為自己嘅 LLM 管線構建咗評估系統，我好好奇：你點樣衡量品質，你發現咗乜嘢令你驚訝嘅事情？
就係咁多啦。
祝好，Chandler