https://yennj12.js.org/yennj12_blog_V4/tags/tracing/Recent content in Tracing on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 13:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part11-agent-debugging-zh/Wed, 03 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part11-agent-debugging-zh/Agent debugging 和傳統程式 debug 的本質差異： 傳統程式出錯，你找 stack trace。 Agent 出錯，LLM 的「決策過程」是不透明的——你找不到 stack trace。 所以你必須在設計時就把觀測能力建進去，而不是出問題後再想怎麼查。 一、核心問題：為什麼 Agent 難 debug 傳統程式： Input → [確定性邏輯] → Output ↑ 出錯有 stack trace Agent： Input → [LLM 決策] → [Tool Call] → [LLM 決策] → ... → Output ↑ ↑ 決策過程不透明 中間狀態沒有自動記錄 三個讓 Agent debugging 特別難的原因： 非確定性：同樣的 input 可能產生不同的執行路徑 多步驟：一個錯誤可能在步驟 1 發生，但直到步驟 8 才顯現 工具依賴：問題可能在 LLM 層、工具層、還是 data 層——不好定位 二、系統全貌：觀測性架構 解決思路：在 Agent 的每個關鍵節點插入觀測點。 用戶請求 │ ▼ ┌──────────────────────────────────────────┐ │ Agent Execution │ │ │ │ ┌─────────┐ ┌──────────────────┐ │ │ │ LLM │ │ Tool Gateway │ │ │ │ │ ←→ │ (instrumented) │ │ │ └─────────┘ └──────────────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────────────────────────┐ │ │ │ Trace Collector │ │ │ │ 每一步的 thought/action/result │ │ │ └──────────────────────────────────┘ │ └──────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Observability Stack │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Metrics │ │ Traces │ │ Logs │ │ │ │ (Grafana)│ │(Langfuse)│ │(Cloud │ │ │ │ │ │ │ │ Logging) │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ 系統健康狀態 單次請求路徑 詳細事件記錄 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Alerting Layer │ │ threshold breach → PagerDuty / Slack alert │ └─────────────────────────────────────────────┘ 三、觀測性三層：各層收集什麼 Layer 1：Metrics（系統健康） 關鍵指標 Dashboard： 延遲 成本 品質 ───────────── ────────────── ────────────── TTFT p50: 450ms input tokens/req: 2500 loop_rate: 0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/Thu, 04 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/評估 RAG 系統：一個問題進去，一個答案出來，量化兩者的關係。 評估 Multi-Agent 系統：一個問題進去，4 個 Agent 跑了 10 次工具，最後出來一個答案。 中間任何一個環節出了問題，你都看不到——除非你事先設計好追蹤架構。 面試情境 面試官： 「這是一個由 4 個 Agent 組成、包含 10 次 Tool-calling 的複雜工作流。客戶說最終答案正確率很低。你如何建立統計評估管線？如何進行 Granular Tracing 抓出是哪個 Agent 或哪次 Tool-calling 出問題？」 一、核心問題：Multi-Agent 的評估為什麼比 RAG 難一個量級 RAG 評估的輸入/輸出模型： Input: Query ↓ [Single Pipeline] ↓ Output: Answer 評估點：3 個指標（Context Relevance, Faithfulness, Answer Relevance） 定位問題：要麼是 Retrieval，要麼是 Generation Multi-Agent 評估的現實： Input: User Request ↓ Router Agent → 分派 ├── Agent A → Tool 1 → Tool 2 → Output A ├── Agent B → Tool 3 → Tool 4 → Tool 5 → Output B └── Agent C → Tool 6 → Output C ↓ Synthesis Agent → 整合 A + B + C → Final Answer 評估點： ├── Router 的分派決策對不對？（Routing Accuracy） ├── Agent A 的工具呼叫成功率？（Tool Success Rate） ├── Agent B 是不是最慢的瓶頸？（Latency by Agent） ├── Agent C 的輸出品質？（Output Quality by Agent） └── Synthesis Agent 整合時有沒有幻覺？（Faithfulness） 問題可能在 10 個地方的任何一個 二、可觀測性架構：三層追蹤設計 ┌──────────────────────────────────────────────────────────────┐ │ User Request 進入 │ │ 分配唯一的 trace_id（e.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part35-granular-tracing-zh/Fri, 05 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part35-granular-tracing-zh/面試官問「P95 延遲突然升高，你怎麼辦？」 多數人說「我去看 Logs」。 強力雇用的答案是：「我打開 Trace，找哪個 hop 吃掉了時間。」 Log 告訴你發生了什麼；Trace 告訴你在哪裡、花了多少。 面試情境 面試官：「你幫客戶部署了一個 ADK Multi-Agent 系統：並行查三個後端、彙整後做決策。上線後客戶回報：有時候 2 秒，有時候 15 秒。你不在客戶現場。你如何在 5 分鐘內定位問題？你的可觀測性設計是什麼？」 一、為什麼 Log 不夠，需要 Trace Log 的問題：只記錄「發生了什麼」，不記錄「在哪裡、花了多久」 一個 Multi-Agent 請求的真實路徑： User Query │ ▼ Orchestrator Agent ├── LLM Call #1（決策） ?ms ├── ParallelAgent │ ├── Sub-Agent A ?ms │ │ ├── Embedding Call │ │ ├── Vector Search ← 瓶頸在這裡？ │ │ └── LLM Call #2 │ ├── Sub-Agent B ?https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/Mon, 22 Jun 2026 03:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/大多數工程師把 LLM 呼叫當成黑箱：記錄 HTTP 狀態碼、回應時間，然後就沒了。 正確的做法是：追蹤每一個 Prompt 版本、每一次工具呼叫、每一個 Token 成本，並量化模型行為漂移。 傳統 APM 只告訴你系統「掛了沒」；AI 可觀測性要告訴你模型「答得好不好」。 沒有這層監控，你永遠不知道提示更新讓答案品質下降了 12%，還是模型供應商悄悄換了版本。 面試情境 面試官問：「你們的 RAG 問答系統上線後，客服主管反應『最近答案怪怪的』，但 p99 延遲和錯誤率都正常。你身為 SRE/AI 工程師，會怎麼設計可觀測性系統來定位這類問題？請說明你的 Traces 設計、漂移偵測機制，以及如何在成本和覆蓋率之間取得平衡。」 一、核心問題：AI 系統的可觀測性為什麼與傳統系統不同 傳統服務的可觀測性三支柱——Metrics、Logs、Traces——在 AI 系統上全都「不夠用」，但原因各不相同。 傳統系統的失敗模式是二元的：請求成功或失敗，HTTP 200 或 500，延遲高或低。失敗有明確的邊界。當資料庫 query 耗時 800ms，你知道哪裡壞了。 AI 系統的失敗模式是漸進的、語意的： 模型回傳 HTTP 200，但答案從準確滑向「有點對但不夠精確」 Prompt 被改了一個詞，召回率悄悄下降 8% 供應商在 2AM 更新基礎模型，語氣風格改變，用戶滿意度在 48 小時後才反映在 CSAT Token 用量因為對話上下文累積，每週成本靜靜地增長 15% 這就是為什麼 AI 可觀測性需要新的維度： 維度 傳統系統 AI 系統 品質訊號 Error rate, p99 latency 語意相似度、答案忠實度、幻覺率 版本追蹤 Code git SHA Prompt version + Model version + RAG index version 成本單元 CPU/Memory/Network Input tokens + Output tokens + Embedding calls 漂移型態 無（確定性系統） 概念漂移、分佈漂移、模型版本漂移 告警閾值 靜態（> 500ms alert） 動態（品質分數 7 日移動平均下降 > 5%） 面試官問的「答案怪怪的」就是典型的語意品質退化。系統層面一切正常，但輸出品質已悄悄崩潰。沒有 AI-native 可觀測性，這種問題的 MTTR 往往超過 3 天。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,零開銷、零風險。