<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LLM-as-Judge on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/llm-as-judge/</link><description>Recent content in LLM-as-Judge on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 04 Jul 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/llm-as-judge/feed.xml" rel="self" type="application/rss+xml"/><item><title>Auto Agent System - Part 2 - Harness 引擎:多模型容錯、自我修正與 LLM 評審</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/</link><pubDate>Sat, 04 Jul 2026 10:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/</guid><description>Demo 版的 AI:json.loads(resp.content)——今天能跑。 上線版的 AI:模型回了 ```json {...} ```、或回 429、或一本正經編造欄位——明天就炸。 差別不在模型多強,而在你有沒有一層「挽具」接住這些意外。 這一篇就是拆解 agent_auto_system 的 Harness 引擎——它如何把不可靠的 LLM,變成可預測的服務。
Part 1 我們鳥瞰了整個系統,並指出 executor.py 和 harness/ 是心臟。這一篇我們把它剖開,順著這個專案的 merged PR 歷史,看它是如何一步步長出「可靠性」的。
Harness 層有五個元件:
src/automation/harness/ ├── provider.py 選模型、算 fallback 順序 ├── validator.py 每個任務的結果驗證規則 ├── evaluator.py 獨立的 LLM 評審,0–100 打分 ├── costs.py token 用量與美元成本估算 └── langfuse_tracer.py 可觀測性(Part 4 深入) 我們一個一個看,並穿插它們背後的 PR。
一、最不起眼卻最致命的第一個坑:被 markdown 包住的 JSON 對應 PR #1:fix: parse markdown-fenced JSON from LLM flow output
任何做過 LLM 結構化輸出的人都遇過這件事。你在 prompt 裡明明白白寫「只回 JSON」,結果模型很貼心地回你:</description></item><item><title>ChatPDF RAG 優化（三）：可觀測性與評估 —— Langfuse 追蹤、評估歷史、即時評分</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/</link><pubDate>Tue, 30 Jun 2026 11:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/</guid><description>多數 RAG 專案上線後,優化全憑「感覺答案變好了」。 但你說不出 faithfulness 是 0.6 還是 0.9,也不知道上次調 alpha 是讓 nDCG 上升還是下降。 這篇講的就是把「感覺」換成「數字」:追蹤每一次 LLM 呼叫、持久化每一次評估、即時評每一個答案——讓優化變成可被驗證的循環。
一、為什麼可觀測性是 RAG 的最後一哩 第一篇解決切塊與檢索品質,第二篇補上 production 防線。但還缺一塊:你怎麼知道這些優化真的有效?
RAG 的恐怖之處在於它「永遠會給出一個看起來合理的答案」。沒有量測,你根本分不清:
調了 hybrid_alpha,到底是變好還是變壞? 某個答案是基於檢索內容,還是 LLM 自己編的(hallucination)? 這次改動,整體 nDCG@k 的趨勢是上升還是下降? PR #4 補上三層可觀測性:
┌──────────────────────────────────────────────────────┐ │ 三層可觀測性 │ ├──────────────────────────────────────────────────────┤ │ 1. 即時聊天 每個回答附信心分數(faithfulness 等) │ │ 2. 評估工具 每次評估的彙總指標持久化,追蹤趨勢 │ │ 3. Langfuse 所有 LLM 呼叫被追蹤(延遲/token/成本) │ │ ── 設定才開,不設定零開銷 │ └──────────────────────────────────────────────────────┘ 二、Langfuse 追蹤:opt-in 且零開銷 設計原則:不設定 = 完全無感 可觀測性工具最怕的就是「為了觀測而拖慢主流程」。chatPDF 的 Langfuse 整合是完全 opt-in:沒設定環境變數時,它是一個 no-op,零開銷、零風險。</description></item></channel></rss>