https://yennj12.js.org/yennj12_blog_V4/tags/langfuse/Recent content in Langfuse on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/Sat, 04 Jul 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/「在我電腦上跑得起來」和「能給一群人用」之間,隔著四道牆: 你看得到它在做什麼嗎(可觀測性)?它打包起來多大、部署多快(image)? 它能自動擴縮、掛了會自己重啟嗎(部署)?誰能用、能用什麼由誰決定(權限)? 這一篇,就是 agent_auto_system 翻過這四道牆的過程。 前三篇我們把系統的「能力」講完了:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)。這一篇談的是另一個維度——生產化(productionization):讓這套系統能被真實地、多人地、可維運地跑起來。四個主題,對應四個 merged PR。 一、Langfuse 可觀測性:在唯一的漏斗上掛 trace 對應 PR #19:feat(harness): add Langfuse LLM-observability integration Part 2 我們反覆強調:LLM 的「錯」不是當機,而是品質退化——HTTP 200,但答案是編的。你需要一種能看見「品質」的監控,這就是 LLM 可觀測性,而 Langfuse 是這個領域的代表工具。 這個 PR 最漂亮的地方,是它的 PR 描述本身就是一堂架構課: 「CrewAI 1.x 直接呼叫各家原生 provider SDK(不走 litellm),所以要把 Langfuse 掛在 executor——這個已經知道 model、tokens、cost、eval score、status 的唯一漏斗。」 拆解這句話為什麼重要: 很多人以為的 Langfuse 接法: 在「LLM 呼叫的那一行」自動攔截(靠 litellm 之類的中介層) 但 CrewAI 1.x 直接打原生 SDK,沒有那個中介層可攔 │ ▼ 聰明的做法:不在「呼叫點」攔,而在「執行點」記 │ ▼ executor 是所有任務的必經之路,而且它手上早就有: model + tokens + cost + eval score + status → 在這裡發一條 trace,一次到位、還帶品質分數 ┌─────────────────────────────────────────────────┐ │ executor.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part4-monitoring-prompt-management-zh/Tue, 30 Jun 2026 14:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part4-monitoring-prompt-management-zh/很多團隊把 prompt 當成「寫死在程式裡的字串」,改一個字就要改程式、跑 CI、重新部署。 也有很多團隊上線後從不看成本,直到月底收到一張嚇人的 API 帳單。 這篇講的就是讓 LLM 應用「可營運」的最後兩塊拼圖:看得見的監控,與管得動的 prompt。 一、從「會用」到「營運得起來」 Part 2 讓資料進來、Part 3 讓品質可評,這最後一篇處理的是長期營運:當你的 LLM 應用每天服務真實使用者,你需要兩件事—— ┌─────────────────────────────────────────────┐ │ 監控(Monitoring) │ │ 「現在花多少錢?多慢?品質有沒有退化?」 │ ├─────────────────────────────────────────────┤ │ Prompt 管理(Prompt Management) │ │ 「改 prompt 不必改程式、不必重新部署」 │ └─────────────────────────────────────────────┘ 二、監控:LLM 應用要盯的三個維度 傳統服務盯 error rate、latency、throughput。LLM 應用在這之上,多了一個你絕不能忽略的維度:成本。Langfuse 的儀表板原生圍繞三個維度: ┌──────────┬──────────────────────────────────────┐ │ 維度 │ 為什麼要盯 │ ├──────────┼──────────────────────────────────────┤ │ 成本 Cost │ token 用量直接換算成 $$;一個爛 prompt│ │ │ 可能讓成本翻數倍而你毫無感覺 │ │ 延遲 Lat. │ LLM 呼叫是秒級的;哪一步拖慢、p95 多少│ │ 品質 Qual.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/Tue, 30 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/寫傳統程式,你有單元測試:斷言 add(2,3) == 5,綠燈就是對。 寫 LLM 應用,「正確答案」往往沒有唯一解——同一個問題有一百種好的回答方式。 那你怎麼測?怎麼知道改了 prompt 之後是變好還是變壞?這就是 LLM 評估要解的問題,也是 Langfuse 最核心的價值。 一、為什麼 LLM 評估這麼難 Part 1 說過,LLM 的「錯」是品質退化而非當機。這帶來一個根本困難:品質很難測。 傳統測試 LLM 評估 ─────────────── ─────────────── assert f(x) == 預期值 「這個回答好不好?」 ✅ 確定、二元、自動 ❓ 主觀、連續、難自動 困難來自三點: 沒有唯一正解:「解釋一下這份財報」可以有無數種好答案。 品質是多維的:正確性、忠實度(有沒有編造)、完整性、語氣、格式……每個維度都要分開看。 改一處動全身:調了 prompt 修好了 A 問題,可能默默弄壞了 B 問題——你需要回歸測試。 Langfuse 的評估體系,就是把這三個困難逐一拆解。核心是一個概念:Score(評分)。 二、Score:把「好不好」變成一個數字 Part 1 提過,Score 是 Langfuse 評估的基石。它把主觀品質,變成可記錄、可追蹤、可比較的值,附加在 trace 或 observation 上。 最直接的用法是用 SDK 寫入。比如收到使用者按了「👍 / 👎」: 1from langfuse import get_client 2langfuse = get_client() 3 4# 把使用者回饋寫成一個 score 5langfuse.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part2-tracing-sdk-zh/Tue, 30 Jun 2026 13:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part2-tracing-sdk-zh/可觀測性最大的阻力,從來不是「值不值得」,而是「要改多少程式碼」。 Langfuse 的設計哲學是:讓你從「完全沒追蹤」到「完整 trace」,只需要加幾行——甚至一行。 這篇就帶你把第一個 trace 送上儀表板。 一、起手式:安裝與設定 Part 1 講完概念,這篇全是實作。先裝套件、設好金鑰。 1pip install langfuse 到 Langfuse Cloud(免費)或你自架的實例,建一個專案,拿到一組金鑰,放進環境變數: 1LANGFUSE_PUBLIC_KEY="pk-lf-..." 2LANGFUSE_SECRET_KEY="sk-lf-..." 3LANGFUSE_BASE_URL="https://cloud.langfuse.com" # 自架的話填你的網址 SDK 會自動讀這些環境變數,所以程式裡通常不必硬寫金鑰。接下來有三種接法,由淺入深。 二、接法一:@observe 裝飾器(最省力) 最快的方式:在你想追蹤的函式上加一個 @observe() 裝飾器。它會自動把這個函式變成一個 observation,捕捉輸入、輸出、執行時間。 1from langfuse import observe, get_client 2 3@observe() 4def retrieve_docs(query: str) -> list[str]: 5 # 你的檢索邏輯 6 return ["doc1", "doc2"] 7 8@observe() 9def generate_answer(query: str, docs: list[str]) -> str: 10 # 你的生成邏輯 11 return "答案..." 12 13@observe() # 最外層 → 這會是一個 Trace 14def handle_request(query: str) -> str: 15 docs = retrieve_docs(query) # 巢狀的 Observation 16 answer = generate_answer(query, docs) 17 return answer 18 19handle_request("分析這份財報的風險") 關鍵在於:巢狀的函式呼叫會自動形成巢狀的 observation 樹。 你不需要手動串接 parent/child——handle_request 成為 trace,裡面的 retrieve_docs 和 generate_answer 自動成為它的子 observation。這正是 Part 1 講的那棵樹,而你只加了三個裝飾器。https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/Tue, 30 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/傳統後端壞掉:噴 500、log 一條 stack trace、監控告警響——你馬上知道。 LLM 應用壞掉:回了一段「看起來很合理但其實是編的」答案,HTTP 200,沒有任何錯誤。 你的使用者知道它錯了,但你的系統不知道。這就是為什麼 LLM 需要一種全新的可觀測性。 一、傳統監控為什麼救不了 LLM 應用 先想一個問題:一個傳統 API 壞掉,你怎麼發現? 傳統後端 ───────────────────────────── 輸入 → 確定性邏輯 → 輸出 │ ├─ 壞了 → throw Exception → 500 → 告警響 └─ 對了 → 200 錯誤是二元的、確定的:不是對就是錯,壞了會噴例外。你的 APM(Datadog、Sentry)抓得到。 但 LLM 應用不是這樣: LLM 應用 ───────────────────────────── 輸入 → Prompt → LLM(機率性) → 輸出 │ ├─ 幻覺(編造事實) → HTTP 200 ✅ ├─ 答非所問 → HTTP 200 ✅ ├─ 語氣不對/拒答 → HTTP 200 ✅ └─ 完美回答 → HTTP 200 ✅ 所有情況都是 HTTP 200。 沒有例外、沒有 stack trace、沒有錯誤碼。LLM 的「錯」不是當機,而是輸出品質的退化——而品質是連續的、主觀的、機率性的。傳統監控的整套工具(看 error rate、看 5xx)在這裡完全失效。https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/Tue, 30 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/多數 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,零開銷、零風險。