GitHub：darkstar1227/learning-sre-for-ai-era

結論先說：Langfuse 與 LangSmith 都能協助追蹤、評估與改善 LLM application；該選哪一個，取決於資料治理、部署模式、OpenTelemetry 策略、evaluation workflow 與團隊願意承擔的維運責任——這篇（上）先把責任邊界、共同能力、選型的六個關鍵問題與 LangSmith／Langfuse 各自適合的情境講清楚，DIY 動手驗證留給下一篇。

Day 31 已把 LangSmith 的 trace、dataset、evaluation、feedback 與 release decision 接成 learning loop。這篇不推翻它，只問下一個工程問題：如果團隊偏向自架、資料主權或 OTel-first，Langfuse 是否更適合？答案要看誰比較符合你的系統與組織條件，不是誰的功能表比較長。

① 先守住觀測責任邊界

Infrastructure / Service Reliability
├─ Prometheus：SLI、SLO、Error Budget、資源訊號
├─ Grafana：dashboard 與 drill-down
├─ Loki：structured log 與 audit event
└─ OpenTelemetry：跨 service、dependency 的 request path

AI Workflow Reliability
├─ LangSmith 或 Langfuse：prompt、retriever、model、tool 的 workflow trace
├─ Dataset 與 evaluation
├─ Human feedback 與 regression analysis
└─ Release decision 的證據

Langfuse 與 LangSmith 都不是 Prometheus、Grafana、Loki 的替代品。前者要回答「使用者是否受影響、error budget 是否在燃燒」；後者協助回答「這一筆 AI workflow 為何答錯、用了哪版 prompt、能否變成 regression case」。把它們混成一套工具，事故時通常兩邊都不夠用。

舉一個具體情境：使用者回報「機器人核准了一個不存在的流程」。如果 on-call 第一步開 Grafana 查 CPU、記憶體、5xx 比例，多半只會看到一片正常——這筆 request 的 HTTP status 是 200，資源用量也沒有異常，Infrastructure 這一層的訊號完全不會告訴你答案錯在哪裡。問題若出在 retrieval 抓到過期文件、或是 prompt 被誤改到舊版本，Prometheus 和 Loki 本來就沒被設計來回答「這句話為什麼是錯的」；反過來，如果整起事故的起點其實是資料庫連線池耗盡（Day 10 討論過的情境），硬去 AI trace 平台裡翻 prompt 版本，也只是在錯的地方找答案，浪費事故應對的黃金時間。分清楚這兩層責任邊界，不是學術上的潔癖，而是決定 on-call 接手事故的第一分鐘該打開哪一個分頁。

為什麼傳統訊號會「盲」，而不是「壞」

要分清楚「看不到」和「壞掉」：Prometheus、Grafana 這套 stack 並沒有失效，量測延遲、錯誤率和資源使用率仍然正確。它的限制是只看得到較底層的訊號，無法直接判斷 AI 輸出的語意品質。

傳統 Web Service 的失敗訊號
輸入錯誤 → Server 拋例外 → HTTP 5xx → Prometheus 計數 → Alert

AI Workflow 的語意失敗訊號
輸入正常 → Server 正常回應 → HTTP 200 → Prometheus 計數為「成功」→ 沒有 Alert
                                          │
                                          └─ 但答案是錯的、政策沒核准、事實漏掉了

這條線畫出來之後，SLI 的定義就必須跟著改變。Day 12 和 Day 19 討論過的「technical success ≠ task success」在這裡是同一件事的另一個講法：technical SLI（HTTP status、latency、error rate）量測的是「系統有沒有正常運作」，task/quality SLI（citation 是否齊全、任務是否真的完成、是否有政策違規）量測的是「系統的輸出有沒有用」。兩者互相獨立，其中一個綠燈不代表另一個也綠燈——這正是為什麼 AI workflow trace 平台不是「多一個 nice-to-have 的 dashboard」，而是把原本看不到的那一半訊號找回來的必要拼圖。

這個轉變不是紙上談兵，而且很容易在 Prometheus 的設定上直接看到破綻。假設團隊照 Day 02 的做法，替 /ask 這個 endpoint 定義了一個標準的請求計數器：

from prometheus_client import Counter

REQUEST_COUNT = Counter(
    "http_requests_total",
    "Total HTTP requests",
    ["method", "route", "status_code"],
)

# 每次 request 結束時
REQUEST_COUNT.labels(method="POST", route="/ask", status_code=200).inc()

這段程式碼完全正確，也完全符合 Day 02 強調的「label 只放低基數欄位」原則——問題是它天生就沒有能力回答「這次回答對不對」。policy-missing-approval 那筆案例（Step 16 會再詳細展開）跟一筆完全正確的回答，在這個 Counter 眼裡是同一筆「status_code=200 的成功請求」。想讓 Prometheus 這一層也能感知語意層的結果，metric 定義本身就要多一個維度：

REQUEST_OUTCOME = Counter(
    "ai_workflow_outcome_total",
    "AI workflow outcome by technical and quality status",
    ["route", "technical_status", "quality_status"],
)

REQUEST_OUTCOME.labels(
    route="/ask", technical_status="success", quality_status="failed"
).inc()

差別只在多加了 quality_status 這個 label，卻讓 Grafana 上能直接畫出「HTTP 都是 200，但 quality_status=failed 比例正在飆升」這條線——這正是①段落一開始那個事故情境裡，值班工程師理論上應該第一眼就能看到的訊號。這也再次印證前面畫的那張責任邊界圖：不是 Prometheus「做不到」，而是沒有人事先把語意層的結果，也定義成一個可以被 Prometheus 記錄的維度。

這個轉變不是紙上談兵，業界近年也把它講得越來越直白：進入 2026 年，多份 LLM observability 產業回顧文章不約而同把「AI 觀測」從維運工具升級成產品發佈的第一級關卡（launch blocker）。理由正是上面畫出的那張圖——傳統 APM 工具（如 Datadog、New Relic）擅長的是基礎設施層訊號，而 LLM 系統最危險的失敗模式（幻覺、檢索錯誤、邏輯錯誤）恰好完全不會反映在那一層。當一個團隊決定要用 Langfuse 或 LangSmith，他們選的不只是一個除錯工具，而是選擇了「誰能最快發現並隔離語意層失敗」——這件事直接決定一個版本能不能上線，而不是上線後才慢慢優化的加分項。

常見誤解：「有 trace 就等於有 observability」

另一個值得先戳破的誤解，是把「有記錄 trace」和「有 observability」畫上等號。單純把每一筆 LLM API 呼叫的 input／output 記下來，充其量只是一份日誌（log），距離 observability 還差了兩層：

Log            只回答「發生了什麼」
Trace          回答「這件事跟其他哪些事有因果關係」
Observability  回答「我能不能從現有訊號推導出我原本沒預期會問的問題」

如果只是把每次呼叫的 prompt 和 response 塞進一張資料表，遇到事故時能做的只有肉眼翻找，跟 grep log 檔沒有本質差異。真正的差異在於：trace 能不能把 retrieval 版本、prompt 版本、model route、驗證結果串成一條可以被查詢、被關聯、被拿來跟另一次 request 比較的因果鏈。這也是為什麼本文後面會反覆強調「span tree 的切法」與「metadata 的版本化」——沒有這兩者，平台功能表再長，事故時也只是多一個要翻的分頁，而不是少一個要猜的環節。

② 共同能力很多，差異在工程條件

Langfuse 官方將 tracing、prompt management、evaluation 視為核心能力：trace 可涵蓋 LLM 與非 LLM 呼叫，例如 retrieval、embedding、API call；evaluation 可使用 dataset、experiment、code evaluator、LLM-as-a-judge、feedback 與人工標註。官方文件也說明其 OpenTelemetry 相容方向。

LangSmith 則很適合將 production trace 接到 dataset、evaluation 與 feedback，形成 Day 31 的 workflow。兩者都能支援 prompt／model iteration；文章不把任何一方寫成「自動保證品質」的工具。

表格只描述選型方向，不替任何方案宣告特定 SLA、成本或合規能力。這些必須按你實際版本、plan、region、合約與部署設計重新確認。

「OTel 相容」這行看似只是一個 checkbox，實際上在賭的是三、五年後的搬遷成本。SDK-native 的 tracing（直接呼叫某平台自己的 client library）換平台時，通常代表把所有 instrumentation 呼叫重寫一遍；OTLP-native 的 tracing 換平台時，理論上只需要換 exporter 的目的地設定，應用程式碼完全不動。這不是說 LangSmith 的 SDK 選擇有問題——它換來的是與 LangChain／LangGraph 生態更緊密的整合，兩者是不同的取捨，不是誰對誰錯。但選型當下就該誠實回答：如果三年後平台供應商漲價、被併購、或停止你需要的功能，你的 instrumentation 程式碼要改多少行？答不出來，代表這個成本目前是隱藏的，不是不存在。

用程式碼把「隱藏成本」具體化

抽象地講「搬遷成本」很容易被會議室的樂觀氣氛蓋過去，不如直接寫出兩種寫法的差異。假設今天要記一筆 retrieval 的結果數量，SDK-native 的寫法通常長這樣：

# SDK-native：直接呼叫平台自己的 client
from some_platform_sdk import trace

@trace.observation(name="retrieval")
def retrieve(question: str) -> list[dict]:
    documents = vector_search(question)
    trace.current_observation().set_metadata({"result_count": len(documents)})
    return documents

而 OTLP-native 的寫法是對著中立的 OpenTelemetry API 寫：

# OTLP-native：呼叫 OpenTelemetry 標準 API，平台只是 exporter 的目的地
from opentelemetry import trace

tracer = trace.get_tracer("answer-api")

def retrieve(question: str) -> list[dict]:
    with tracer.start_as_current_span("retrieval") as span:
        documents = vector_search(question)
        span.set_attribute("retrieval.result_count", len(documents))
        return documents

兩段程式碼做的事情一模一樣，差別只在 trace.observation 是某個平台專屬的裝飾器，而 tracer.start_as_current_span 是 OpenTelemetry 規格定義的標準呼叫。當團隊決定換平台，第一段程式碼裡的每一個 @trace.observation、每一個 trace.current_observation() 都要找出來重寫；第二段程式碼完全不動，只需要換 TracerProvider 指向的 exporter 設定。把這個差異放大到一個成長中的 codebase——幾十個 endpoint、上百個 span——搬遷成本從「改一個環境變數」變成「一個要排進 sprint 的專案」，這中間的落差正是「OTel 相容」這行 checkbox 真正在保護的東西。

這不代表 SDK-native 註定是錯誤選擇。如果團隊已經深度綁定某個框架的生態（例如 LangChain 的 traceable 裝飾器能自動抓到 chain、agent、tool 呼叫的巢狀結構，OTel 手動插 span 反而更費工），用 SDK 換來的開發速度可能划算得多。只是要清楚知道自己付出的是哪一種代價：今天省下的 instrumentation 工時，未來可能變成搬遷時的重寫工時；今天多寫幾行 OTel span，換的是三年後只改一行 exporter endpoint 的自由。

把這個取捨換算成一張表，會更容易在選型會議上被具體討論，而不是停留在「應該還好吧」的直覺：

最後一行值得特別點出來，因為它是這張表裡唯一一個「OTLP-native 反而不一定比較穩定」的項目——這正是本文稍後會展開的重點：「換平台免費」和「欄位名稱本身穩定」是兩件事，OTel 相容解決的是前者，不是後者。

這張表沒有標準答案——它的用途是讓「我們要不要現在多花一點工時寫 OTel span」這個問題，從一句模糊的工程偏好，變成一次有明確代價與回報的取捨討論。

名詞不一樣，資料模型也不一樣

除了 SDK 呼叫方式的差異，兩個平台在描述「同一件事」時用的詞彙也不一樣，這件事在選型會議上很少被認真討論，卻會實際影響你怎麼設計程式碼裡的抽象層。

概念層級          Langfuse 的詞彙        LangSmith 的詞彙       OpenTelemetry 的詞彙
────────────────────────────────────────────────────────────────────
整條請求的軌跡     Trace                  Trace / Run Tree        Trace
單一步驟／呼叫     Observation             Run                     Span
LLM 專屬的步驟     Generation（Observation 子類型）  Run（type=llm）   Span + gen_ai.* 語意慣例
巢狀父子關係       Observation 樹狀結構     Run Tree                Span 的 parent-child 關係

這張對照表最有意思的地方，是 OpenTelemetry 那一欄的詞彙——Span、parent-child——完全沒有任何 AI 專屬的概念。這不是 OTel 的缺陷，而是它刻意保持中立的結果：一個 retrieval 動作、一個資料庫查詢、一個 LLM 呼叫，在 OTel 的世界裡都只是「一個有開始時間、結束時間、可能有子節點的 span」，差別只在你替它加上哪些 attribute（例如 gen_ai.request.model）。這正是為什麼本文一路強調「先定義中立的資料模型，再各自映射到平台專屬詞彙」——因為 OTel 本身就是這樣設計的：它不知道，也不需要知道你的 span 是不是一次 LLM 呼叫，它只負責忠實記錄「發生了什麼、跟誰有因果關係」。

理解這張表也能解釋一個常見的困惑：為什麼同一段程式碼接到 Langfuse 顯示的樹狀結構，跟接到 LangSmith 顯示的樹狀結構，看起來排版不太一樣？答案通常不是資料遺失，而是兩個平台把 OTel 的 Span attribute，各自重新詮釋成自己 UI 慣用的 Observation 或 Run 概念時，選擇強調的欄位不完全相同。這也是 Step 6 為什麼要求「驗證同一條 trace，而不是只看 UI」——UI 呈現方式的差異，不代表底層資料模型有優劣之分，先確認資料本身完整，再去評判 UI 好不好用，順序不能顛倒。

gen_ai.* 這個名詞本身也還沒定型

前面把 OTel 的 Span 講得像一塊中立、穩固的地基，這句話要再補一個但書：地基本身也還在施工。OpenTelemetry 於 2024 年 4 月成立 GenAI SIG（Special Interest Group），一開始只打算涵蓋「LLM client call 該怎麼記」這麼窄的範圍，後來一路擴展到 agent orchestration、MCP tool calling、內容擷取（content capture）、品質評估等六個子領域。但截至 2026 年 5 月，這組 semantic conventions 仍然標示為「Development」狀態，沒有穩定版本的時間表——業界工程分析指出，光是 v1.37 到 v1.41 這幾個版本之間，幾乎每一版都動到 GenAI 相關屬性的命名或結構（OpenTelemetry for Generative AI、How OpenTelemetry Traces LLM Calls, Agent Reasoning, and MCP Tools）。

具體長什麼樣子？以下是目前規格草案裡，記錄一次 LLM 呼叫時常見的屬性寫法：

with tracer.start_as_current_span("model.generate") as span:
    span.set_attribute("gen_ai.system", "gemini")
    span.set_attribute("gen_ai.request.model", "gemini-2.5-flash")
    span.set_attribute("gen_ai.request.temperature", 0.2)
    answer = call_model(question, documents)
    span.set_attribute("gen_ai.response.finish_reasons", ["stop"])
    span.set_attribute("gen_ai.usage.input_tokens", answer.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", answer.usage.output_tokens)

這段程式碼今天寫下去會動，但「今天會動」跟「三年後這幾個屬性名稱還長這樣」是兩件事。規格作者自己也承認一個結構性的兩難：把敏感的 prompt／completion 內容直接記在 gen_ai.prompt、gen_ai.completion 這類屬性上，除錯最方便，但風險最高；完全不記錄，安全但用起來綁手綁腳；折衷做法是把內容存到另一個外部系統、span 上只留指標——但這需要額外的工程投入，而且目前不同 instrumentation library 對這件事的成熟度差異很大：OpenAI 的 Python SDK instrumentation 做得相對完整，社群的 OpenLLMetry 涵蓋不完整，agent 層級的 framework instrumentation 則多半還在進行式。

這件事直接呼應本文一開始討論的「隱藏成本」——「OTel 相容」降低的是換平台時重寫 instrumentation 呼叫的成本，但如果連 OTel 自己對 AI workload 的屬性命名都還在變動，那份確定性本來就沒有想像中高。務實的因應方式，是把 gen_ai.* 這些屬性名稱也當成需要被抽象一層的東西，而不是直接在幾十個 handler 裡到處硬寫字串：

# ai_semconv.py —— 集中管理目前採用的 GenAI 屬性名稱
# 版本升級時只改這一個檔案，不用到處找散落的字串
GEN_AI_SYSTEM = "gen_ai.system"
GEN_AI_REQUEST_MODEL = "gen_ai.request.model"
GEN_AI_USAGE_INPUT_TOKENS = "gen_ai.usage.input_tokens"
GEN_AI_USAGE_OUTPUT_TOKENS = "gen_ai.usage.output_tokens"

這跟 Step 1 建立 AITraceContext dataclass 是同一個道理的延伸：先前是把「業務要記錄什麼」跟「平台的資料模型」分開，這裡則是把「業務要記錄什麼」跟「標準規格目前用哪個字串」也分開一層。規格會演進本身不是壞事——它代表這個領域還在被認真定義——但工程上不該把一個尚在 Development 狀態的命名，直接當成永久不會變動的公開 API 來大量散落引用。

③ 不要只看功能表

錯誤問題是「誰的功能比較多？」更有用的問題是：

• trace 是否含敏感 prompt、內部文件或個資？
• 是否需要 VPC、on-prem 或 self-hosting？
• 誰維運 database、queue、object storage、backup、patch 與 upgrade？
• 現有 OpenTelemetry Collector／OTLP pipeline 要如何關聯 AI trace？
• dataset、feedback、evaluator 是否真的是 release gate 的證據？
• trace、dataset、prompt、feedback 的 retention 與刪除策略是什麼？

這六個問題不是隨意排序的檢查表，而是刻意按照「越晚發現代價越高」排列。前兩題（敏感資料、部署模式）決定的是資料到底能不能離開你的系統邊界，一旦答錯，補救方式往往是資安事故應變，而不是技術重構；中間兩題（維運責任、OTel pipeline 整合）決定的是平台長期能不能被你的團隊撐住，答錯的代價通常在幾個月後的某次 incident 現場才會兌現；最後兩題（release gate、retention）決定的是這套 observability 投資，最終能不能真的變成「這個版本可以上線」的依據，答錯的代價是團隊花了時間建置一套平台，事故時卻發現它幫不上忙。把六題按這個順序想過一遍，比毫無章法地隨機挑幾題討論，更容易在會議室裡就先擋掉之後會變成事故的假設。
清單裡的第一題——「trace 是否含敏感 prompt、內部文件或個資？」——最容易被略過，因為它聽起來像合規部門的例行公事，而不是工程決策。但這題答不好，平台功能再強也沒有意義，因為你根本不該把某些內容送出系統邊界。

這裡不需要憑空想像最壞情況，三星電子在 2023 年就親身示範過一次。當年 4 月，三星開放半導體部門員工使用 ChatGPT 協助處理程式碼與日常工作，結果短時間內就出現員工把公司內部敏感資料直接貼進對話視窗的情況——問題不是員工惡意外洩，而是工具好用到讓人忘記自己正在做的事：貼上一段報錯訊息、貼上一段程式碼片段去問「這裡為什麼會壞」，是再自然不過的除錯動作，沒有人會在按下 Enter 前停下來做資料分類。這些內容一旦送出，就離開了公司的控管範圍，理論上可能被服務方用於模型訓練，或以其他方式被間接看到。三星在事故曝光後（2023 年 5 月 2 日公告）立刻對所有公司裝置與連上內部網路的裝置實施暫時性生成式 AI 禁用，範圍涵蓋 ChatGPT、Microsoft Bing Chat 與 Google Bard，並要求員工「不要將任何公司相關資訊或個資提交給這類工具」（TechCrunch 報導）。

把這起事故搬到 AI observability 平台的情境，道理完全相通：Langfuse 或 LangSmith 的 trace 本質上就是「把系統內部發生的事情記下來、送到另一個地方查看」。如果 retrieval 抓到的完整文件、使用者輸入的完整問題、甚至夾帶在 prompt 裡的 API key 或個資，未經任何遮罩就整包送進 trace attribute，這條 trace pipeline 本身就變成了一個新的外洩管道——差別只在於三星的案例是員工手動貼上，而 trace pipeline 的外洩是自動化、持續發生、規模可能更大的版本。這也是為什麼後面 Step 5、Step 11 花了整整兩個小節在講 allowlist 與 mask：靠員工自律（「請不要提交敏感資訊」）在真正發生事故之前，幾乎不會被認真執行；技術層的強制攔截才是真正的防線。先減少送出去的資料，再談要把資料送到哪個平台，通常比事後補救省事得多。

再往下一題——「誰維運 database、queue、object storage、backup、patch 與 upgrade？」——同樣容易被輕描淡寫地帶過，彷彿只要選型會議上有人說「我們可以自己維運」，這件事就算解決了。

Langfuse 官方將 Docker Compose 定位為 local use／testing，並明說它不是具備 HA、scaling、backup 的 production 架構；production self-hosting 由你的 infrastructure 負責。官方 self-hosting 說明把這件事寫得很直接。可以自架，從來不等於不用維運。

這句話不是危言聳聽。GitLab 在 2017 年的資料庫事故，是「以為有備份」這種假設如何全面破功的經典案例：一名工程師在嘗試修復失敗的資料庫複寫時，誤在正式環境的伺服器上執行刪除指令，數秒內中止，但已經刪掉約 300 GB 資料。GitLab 當時理論上有四層備援——pg_dump 每日備份、LVM snapshot、Azure 磁碟快照、資料庫複寫本身——事後盤點卻發現每一層都已悄悄失效：pg_dump 用的 PostgreSQL 版本（9.2）跟正式環境（9.6）對不上，已經默默失敗數週，失敗通知信又被信箱的 DMARC 設定擋下、從沒人看到；Azure 快照從未對資料庫伺服器啟用；LVM snapshot 全站只留兩份，最新的一份也已經是 6 小時前；複寫則早在事故前就已中斷。最後只能拿 6 小時前的 LVM snapshot 還原，整起事故造成約 18 小時不可用，永久遺失約 5,000 個專案、5,000 則留言與 700 個使用者帳號（GitLab 官方 postmortem）。官方報告寫得很直白：「沒有人真正擁有這個備份流程，所以也沒有人測試過它。」把這句話搬到 Langfuse self-host 的情境：Postgres、ClickHouse、Redis、object storage 一樣要問同一個問題——不是「有沒有備份」，而是「最近一次真的把它還原回來，是什麼時候、花了多久、丟了多少資料」。答不出來，就代表這一層備援目前只是心理安慰。

④ 什麼情況選 LangSmith？

LangSmith 較適合下列起點：

• 想快速建立 trace → dataset → evaluation → release decision 的迴圈。
• 團隊先想降低 observability platform 的自行維運工作。
• 開發流程已高度使用 LangChain、LangGraph 或相近的整合方式。
• 希望先把 production failure 轉成可比較的 regression case。

若團隊已經以 LangChain 或 LangGraph 開發，LangSmith 的整合路徑通常較短。這不表示它天生比較好；只是當眼前的瓶頸是 debug 與評估迭代速度，少維運一套有狀態的平台，往往比多一個可自訂元件更有價值。

這不是說 LangSmith 比較「強」。它只是表示你的當前約束更重視迭代速度與整合流程。Day 31 的架構也仍需要 metrics、logs、OTel 與 SLO；不要因為 trace UI 好用，就放棄底層的可移植 telemetry。

託管模式不是偷懶，是把維運責任外包給願意承擔它的人

「選 managed 平台」在一些團隊的直覺裡帶著一點「不夠硬核」的意味，好像只有自己維運資料庫才算真正掌握系統。這種直覺值得被戳破：維運一套有狀態的 observability 平台（trace ingestion、dataset 儲存、evaluation 排程、UI 服務）本身就是一個需要專職團隊長期投入的產品工程問題，跟你的核心產品（例如政策問答系統）完全是兩件事。把這件事外包給專門做這件事的供應商，換來的時間拿去改善自己的 AI workflow，往往是更划算的資源配置——前提是你已經誠實回答過 ③ 清單裡的資料治理問題，確認這批資料真的可以離開你的邊界。

市場對這個判斷也給出了具體的資本回應。2025 年 10 月，LangChain（LangSmith 的母公司）以 12.5 億美元估值完成由 IVP 領投的 1.25 億美元 Series B 融資，聯合投資方包含 Sequoia、Benchmark、CapitalG 等機構；公告特別點名資金將用於「持續擴展 LangSmith，作為 LLM 應用的觀測、評估與部署平台」。這輪融資本身不是任何團隊選型的理由——投資人看好一家公司，不代表它適合你的資料治理要求——但它至少印證了一件事：讓專業供應商承擔 observability 平台的維運責任，同時把框架整合做得夠深，是一個能被市場驗證、有機構級資本背書的商業模式，不是「圖方便」的偷懶選項。換句話說，選擇 managed 平台和選擇自架，最終比的不是誰比較認真，而是你的團隊願意把有限的工程時間，投入在維運 observability 平台，還是投入在讓 AI workflow 本身更可靠。

Managed 平台省下的時間，具體花在哪裡

「把維運責任外包出去」講起來抽象，具體省下的到底是哪些工作？把前面 ⑤ 段落那張依賴圖拿來對照最快：Langfuse 自架團隊要處理的 Postgres backup 演練、ClickHouse disk 容量規劃、Redis 故障重試、object storage 存取權限——這四項在選擇 LangSmith 這類 managed 平台時，全部變成供應商的責任範圍，團隊完全不需要為它們安排 on-call rotation，也不需要在季度規劃裡編列維運這些元件的工程時數。

這不代表 managed 平台完全沒有維運工作——資料分類、negative fixture 驗證、evaluator 邏輯維護、prompt 版本管理，這些②③段落強調的責任，不會因為換成 managed 平台就消失，因為它們本來就不是「平台維運」的範疇，而是「你的 AI workflow 本身」的責任，任何平台都不會替你承擔。真正的差異在於：managed 平台讓團隊不用同時扮演「AI 應用開發者」和「有狀態分散式系統的維運者」兩個角色，省下的工程時間，理論上可以全部投入在讓 retrieval、prompt、validator 這些真正影響答案品質的環節更可靠——而不是花在確認 ClickHouse 的磁碟還有多少剩餘空間。

②段落提過的 gen_ai.* schema 演進，也是這份省下的時間清單裡容易被忽略的一項。自架團隊如果直接用 OTel-native 方式送 span，等於自己扛起了「規格更新時要不要跟進、跟進後舊資料怎麼對應」這個責任；而使用 LangSmith 這類 managed SDK 的團隊，這件事實質上是由平台方去追蹤官方規格變動、決定何時在自己的 SDK 裡吸收這些變化，應用端通常只需要升級 SDK 版本，而不必自己盯著 GenAI SIG 的 changelog。這不代表 SDK-native 完全沒有代價——本文②段落已經談過「換平台要重寫 instrumentation」這個取捨——只是在「schema 本身還在演進」這個特定維度上，把追蹤規格變動的責任交給平台方，跟前面「把資料庫維運責任交給平台方」是同一種邏輯的延伸。

⑤ 什麼情況選 Langfuse？

Langfuse 較值得優先評估的情境包括：

• 偏好開源、可自行檢視與部署的平台。
• 有較強的資料駐留、資料主權、VPC 或 on-prem 要求。
• 已有 Docker、Kubernetes、Postgres、ClickHouse、Redis／Valkey、object storage 的維運能力。
• 想以 OpenTelemetry／OTLP 作為 AI telemetry 的長期中立介面。
• 願意將 retention、backup、access control、upgrade 與 incident ownership 視為產品責任。

ClickHouse 在 2026 年 1 月宣布收購 Langfuse，並表示既有部署可繼續使用。這是工具演進的背景，不是選型證據；採用前仍要以當前授權、版本、支援條款與你的資料政策為準。自架能提高部署與資料處理的控制程度，但不會自動消除供應商、版本或營運風險。

收購案背後：開源自架路線的市場定價

這筆收購值得多花一段篇幅講清楚，因為它剛好可以驗證上面清單裡「願意將 retention、backup、access control、upgrade 與 incident ownership 視為產品責任」這句話，到底值不值得。2026 年 1 月，ClickHouse 一次公告了兩件事：完成一輪 4 億美元的 Series D 融資，並同步收購開源 LLM observability 平台 Langfuse（ClickHouse 官方公告、SiliconANGLE 報導、InfoWorld 報導）。ClickHouse 本身早已是分析型資料庫的市場領導者之一，它看中 Langfuse 的理由並不是要「多做一個功能」，而是兩件事在架構上天生互補：Langfuse 開源、MIT 授權，讓採用它的企業能完整掌控程式碼與資料；而 Langfuse 的 LLM trace schema——高基數、append-heavy、以時間序列為主的寫入模式——恰好與 ClickHouse 這類欄式資料庫最擅長處理的工作負載高度吻合。整合之後，ClickHouse 對外的說法是可以「把每一筆 LLM 呼叫轉換成可查詢的結構化紀錄」。收購後 Langfuse 保留開源地位，但同時取得一家成熟資料庫公司的工程與資金支援，成為 LangSmith 這類專有 SaaS 之外一個更站得住腳的替代選項。

這件事對本文的立場有兩層意義。第一層是市場驗證：一家已經在分析型資料庫市場站穩腳步的公司，願意用九位數美元的規模去併購一個開源 observability 專案，說明「資料主權」與「自架能力」在企業採購市場上是有明確價格的——不是工程師自己說爽的浪漫堅持。第二層更貼近本文反覆強調的原則：這筆收購沒有改變 Langfuse 自架時仍然需要維運 Postgres、ClickHouse、Redis、object storage 的事實。被更大的公司收購，換來的是程式碼與生態系更有機會被長期維護，但不會替你把 backup 演練、patch 排程、access control 這些維運責任變不見。把「這家公司被大廠收購了，應該比較安全」當成免除維運責任的理由，跟把「有備份」誤當成「備份可以還原」是同一種思考陷阱——GitLab 2017 年的事故就是後者最好的教材。

為什麼是 ClickHouse，不是隨便一個關聯式資料庫

前面提到「Langfuse 的 LLM trace schema 恰好與 ClickHouse 這類欄式資料庫最擅長處理的工作負載高度吻合」，這句話值得展開講清楚，因為它不是行銷詞彙，而是一個有具體技術理由的架構選擇。

一般應用程式最熟悉的關聯式資料庫（如 Postgres）是列式儲存（row store）：同一筆紀錄的所有欄位存在磁碟上相鄰的位置，適合「查一筆完整紀錄」這種操作——例如「把某個 request 的所有欄位一次讀出來」。但 AI trace 資料的查詢型態常常是反過來的：分析師想問的問題往往是「過去一小時內，retrieval.index_version=policy-v5 的所有 span，quality_status 分布是什麼」——這種查詢只需要讀兩三個欄位，卻要掃過非常大量的列。

Row store（Postgres 這類）的資料排列方式
[request_id=1, timestamp=t1, model=gemini, quality=pass, ...]
[request_id=2, timestamp=t2, model=gemini, quality=fail, ...]
[request_id=3, timestamp=t3, model=gpt,    quality=pass, ...]
        ↑
        查「一整筆」很快，查「只要 quality 這個欄位、掃十萬筆」要跳著讀，很慢

Column store（ClickHouse 這類）的資料排列方式
timestamp: [t1, t2, t3, ...]
model:     [gemini, gemini, gpt, ...]
quality:   [pass, fail, pass, ...]
        ↑
        只要讀 quality 這一欄，磁碟上是連續的，掃描效率高出一個量級

AI trace 資料還有另一個特性放大了這個差異：它是 append-heavy（幾乎只有新增、很少更新既有紀錄）而且高基數（request_id、trace_id 這類欄位幾乎每筆都不同）。欄式資料庫對這種「一直寫入、很少更新、常常按少數幾個欄位聚合查詢」的工作負載，天生比列式資料庫更有效率——這也是為什麼 Prometheus、ClickHouse 這類為時間序列或分析查詢設計的系統，架構上都偏向欄式或類欄式儲存，而不是傳統 OLTP 資料庫的設計。

這件事對選型會議有一個實際的提醒：如果團隊評估的不是 Langfuse，而是考慮「乾脆自己拿 Postgres 存所有 trace 資料，省得多維運一套 ClickHouse」，這個決定短期內看起來省事，但長期會在「trace 資料量成長到一定規模後，聚合查詢明顯變慢」這件事上付出代價——這也呼應了 Step 18 提醒的「ClickHouse 的 disk 用量誰在追蹤（它是這四者裡最容易隨 trace 量成長而爆掉的一個）」：它會爆掉的原因不只是空間不夠，更常見的是為了應付這類分析查詢，資料模型和索引策略也需要隨著資料量成長而重新調校，而不是一套設定用到底。

自架的資料控制權和維運負擔是同一個選擇的兩面。官方 Docker Compose 範例涉及 web、worker、Postgres、ClickHouse、Redis 與 object storage 等元件；在你的 SRE 語言裡，這些都是 dependency，不是 compose 檔案裡的背景角色。

把「compose 檔案裡的背景角色」畫成一張真正的依賴圖

「這些都是 dependency」這句話講起來容易，真正落地時最好的方式是把它畫出來，而不是留在腦中當一句口號。以下是 Langfuse self-host 時實際上會出現的依賴關係，刻意按照「這一層掛掉，會拖累哪一層」的方向畫：

使用者的 Trace 查詢請求
        │
        ▼
Langfuse Web（查詢介面、API）
        │
        ├─── 讀寫 Trace/Observation 中繼資料 ──► Postgres
        │                                          │
        │                                          └─ 掛掉 → Web 完全無法查詢，等同平台停擺
        │
        ├─── 讀寫高基數 trace 事件資料 ──────────► ClickHouse
        │                                          │
        │                                          └─ 掛掉 → 新 trace 查不到，歷史資料可能部分可讀
        │
        ├─── 快取、佇列狀態 ─────────────────────► Redis / Valkey
        │                                          │
        │                                          └─ 掛掉 → ingestion 排隊機制失效，worker 可能積壓
        │
        └─── 大型 payload（如完整 prompt）───────► Object Storage（S3-compatible）
                                                     │
                                                     └─ 掛掉 → trace 看得到骨架，內容讀不出來

Langfuse Worker（背景處理 ingestion、evaluation job）
        │
        └─── 同樣依賴上述四個元件，其中任何一個異常都可能讓 ingestion 佇列持續堆積

這張圖想強調的重點，是「Langfuse 掛了」在自架情境下幾乎從來不是單一事件，而是背後四個 stateful dependency 裡的某一個先出問題，Langfuse 本身的 web／worker 服務其實通常沒有壞掉，只是連不上它依賴的資料層。這正是 Day 10 討論過的 dependency failure 模式在 observability 平台自身架構上的重演——你選 Langfuse 是為了更好地觀測你的 AI workflow，但 Langfuse 自己也是一個有 dependency 的分散式系統，一樣會被同樣的故障模式打中。維運自架 Langfuse 的團隊，等於同時接下了四個新的「這個東西掛了會怎樣」的問題，而不是只多裝了一個應用程式。

也因為這樣，選 Langfuse 自架之前，值得誠實地把 ③ 清單裡那句「誰維運 database、queue、object storage、backup、patch 與 upgrade」拆解成四個獨立的問題來回答，而不是含糊地說一句「我們有 DBA」：Postgres 誰負責備份演練？ClickHouse 的 disk 用量誰在追蹤（它是這四者裡最容易隨 trace 量成長而爆掉的一個）？Redis 掛掉時 worker 的重試機制夠不夠健壯？Object storage 的存取權限有沒有跟其他系統共用、會不會因此被牽連？四題都答得出來，才算是真正把「自架」這件事的維運負擔想清楚，而不是被「開源、免授權費」這幾個字帶過去。

⑥ 可否同時用？可以，但先決定理由

這是本文的 SRE 設計建議：不要一開始就在 production 對所有 trace 雙寫入 LangSmith 與 Langfuse。SDK integration、trace context、遮罩、sampling、retention、成本和 source of truth 都會變成兩套；當 incident 發生，團隊可能連該看哪個 project 都不知道。

較穩妥的分階段策略：

Development / Lab：可用固定 workflow side-by-side 比較資料模型。
Staging：選一套作為 primary evaluation platform，驗證 trace、dataset、prompt、feedback 與 CI 連結。
Production：原則上選一套 primary AI observability platform；保留 OTel、metrics、logs 作為底層可移植能力。

雙寫入不是禁令。它需要明確假設，例如遷移驗證、合規比較或工具評估，並有截止日、資料範圍、成本上限和單一 incident investigation source。

為什麼「先都留著」比「選錯」更危險

工程團隊很容易把「雙寫入」當成一種延後決策的保險——反正兩邊都留著，之後想清楚再選一個就好。這個想法忽略了一件事：雙寫入本身也在持續累積成本，而且是那種不會馬上被注意到、卻會隨時間複利的成本。

雙寫入的隱藏帳單（每多留一天都在累積）
├─ SDK／instrumentation：兩套呼叫要同時維護、同時升級
├─ Masking 規則：兩邊的遮罩邏輯可能悄悄分岔，其中一邊漏了新加的 PII 欄位
├─ Sampling／retention：兩邊政策不同步，同一個 request 在兩邊看到的資料量不同
├─ 成本：兩份 ingestion、兩份儲存、兩份平台費用同時燒
└─ Incident investigation：on-call 得先猜「這次事故該看哪邊」，才能開始查

最後一項是最致命的。Incident 發生時，時間是最稀缺的資源；如果 on-call 連「該打開哪個分頁」都要先想一下，代表雙寫入已經從「降低風險的緩衝」變成「多一層要克服的摩擦」。這也是為什麼本文建議雙寫入必須有明確的結束條件，而不是「先留著比較安心」——安心感和實際的可靠性，往往不是同一件事。

「兩邊都保留」到底保留了多少？用取樣數字戳破一個常見錯覺

上面「隱藏帳單」清單裡有一項常被輕描淡寫——「Sampling／retention 兩邊政策不同步，同一個 request 在兩邊看到的資料量不同」。這句話聽起來只是設定沒對齊的小問題，但背後藏著一個更根本、而且經常被誤解的數學事實：sampling 這件事，天生就沒辦法「事後」補救。

工程社群近年對這件事有一個很直白的量化說法：在 10% 的錯誤取樣率下，一次性的失敗有高達九成的機率完全沒被保留下來（Tune Sentry Error and Trace Sampling While Preserving Rare Failures）。原因不是取樣器「運氣不好」，而是取樣的決定通常要在請求「剛開始」的時候就做——那個當下系統根本還不知道這個請求最後會不會失敗。等到請求真的壞掉了，才想「回頭」把它的完整 trace 找回來，已經來不及了：呼叫 captureException 之類的方法，只能獨立記下「這裡發生了一個錯誤」這個事件本身，沒辦法讓那些「當初就沒被抽中要保留」的 span 憑空補回來。

Head sampling 的時間順序（大多數平台的預設行為）
t0：request 進來 ──► 立刻擲骰子決定「這條 trace 要不要留」
                          │
                          ├─ 沒被抽中 → 這條 trace 的所有 span 都不會被儲存
                          │
t1：request 執行中 ──► 這時候還不知道它會不會失敗
                          │
t2：request 失敗了 ──► 太晚了，t0 的骰子已經擲過，補不回來

把這件事套進雙寫入的情境會更清楚為什麼它是隱藏帳單，而不只是設定檔裡兩行不一樣的數字。如果 Langfuse 那邊設定 trace 取樣率 20%、LangSmith 那邊設定 50%（或兩邊各自的預設值本來就不一樣，沒有人特別去對齊），同一批 production 流量會在兩個平台留下完全不同的「倖存子集」。這時候拿「Langfuse 上看不到這筆事故的 trace，但 LangSmith 上看得到」去下結論「LangSmith 比較準」，其實只是在比較兩份根本不同的樣本——跟丟兩枚不同機率的硬幣，卻拿正反面出現的次數去說「這枚硬幣比較準」是同一種邏輯錯誤。

務實的作法是把「保留所有失敗事件」與「用較低比例取樣一般流量」分開設定——例如失敗事件（quality_status=failed、safety_status=failed）一律 100% 保留，一般成功案例才套用較低的取樣比例——並確保這條規則在雙寫入的兩個平台上是同步設定的，而不是各自套用平台預設值。這也解釋了為什麼 Step 19 的雙寫入退場條件清單，要求「期間：只收固定 workflow、固定 sampling 或去識別 fixture」——不是隨口加的限制，而是不這樣做，連「兩邊看到的是不是同一份事故」這個最基本的問題都答不出來。

真的要選的時候，怎麼把「感覺」變成「決定」

前面講了很多不該做的事（不要一開始就雙寫、不要只看 UI、不要把開源等同於安全），但團隊最後還是得真的選出一套 primary platform。以下是一個具體、可依序執行的收斂流程，把「選型會議」從一場各自表述的討論，變成一連串有先後順序的檢查動作。

1. 先跑③的六題清單 ── 有沒有任何一題的答案是「不知道」？
        │
        ├─ 有 ──► 先把「不知道」變成「知道」，這不是選型階段該猜的事
        │
        ▼ 沒有（六題都答得出來）
2. 對照④⑤的情境清單 ── 你的團隊條件更接近哪一邊？
        │        （不是「哪個功能表比較長」，是「哪些前提你已經成立」）
        ▼
3. 用 Step 1–9 實際跑一次 side-by-side Lab ── 兩邊看到的世界一致嗎？
        │
        ├─ 不一致 ──► 回到 Step 6，先解決資料模型或遮罩規則的分歧
        │
        ▼ 一致
4. 填 Step 9 的決策表、跑 Step 17 的 Lab Report ── 每一格都有 owner 和證據嗎？
        │
        ├─ 沒有 ──► 這一格代表的風險還沒被任何人擁有，先指派，不要跳過
        │
        ▼ 有
5. 寫 Step 22 的 ADR，標出 Revisit 條件 ── 完成，但不是「結案」

這個流程刻意設計成「每一步都可能把你打回上一步」，而不是一條只能往前走的單行道。這正是在對抗選型會議最常見的失敗模式：時間壓力一大，團隊很容易跳過某個環節、直接進到「投票選一個」的階段。把每一步的失敗出口明確標出來（不知道就先查清楚、不一致就先解決分歧、沒 owner 就先指派），是刻意讓「跳步驟」這件事變得顯眼，逼團隊誠實面對自己到底卡在哪一步。

動手之前，先戳破幾個常見誤解

在真的打開終端機之前，值得先把幾個在選型會議上反覆出現、卻經不起追問的誤解攤開來看。這些誤解不是誰特別無知，而是每一個都有它聽起來合理的表面理由——正因為合理，才更容易在沒有人細想的情況下，變成整個團隊的預設假設。

誤解一：「開源就代表安全、自架就代表資料主權。」

開源讓你有能力檢視程式碼、有能力自架，這是事實；但「有能力」不等於「已經做到」。Langfuse 自架後，資料主權的實際邊界取決於你怎麼設定 access control、有沒有落實 encryption at rest、backup 存放在哪裡、由誰擁有存取金鑰——這些都是部署決策，不是授權條款自動附贈的屬性。反過來，一個 managed SaaS 平台如果簽了明確的資料處理合約、有清楚的 region 選擇和刪除保證，資料治理的確定性可能比一個設定隨便的自架環境更高。開源與自架給的是「選擇權」，不是「保證」；選擇權要真的被用來做出正確的設定，才會變成保證。

誤解二：「OpenTelemetry 相容，就代表換平台是免費的。」

② 段落已經用程式碼示範過，OTLP-native 的 instrumentation 確實能讓應用程式碼不動、只換 exporter 設定。但這只解決了「trace 怎麼送出去」這一層；換平台真正的成本往往藏在別的地方——dataset 和 evaluator 的定義通常是平台專屬的資料結構，換平台代表這些定義要重新遷移；歷史 trace 資料是否能匯出、能匯出到什麼程度，也完全取決於原平台的匯出能力，而不是 OTel 標準能保證的事。OTel 相容降低的是「重寫 instrumentation」這一項成本，不是全部的搬遷成本。

誤解三：「Trace UI 好看、用起來順手，就代表 observability 做得好。」

一個排版精美、互動流暢的 trace UI，確實會讓開發體驗變好，這點不該被貶低。但 UI 的美觀程度，跟這套系統在事故當下能不能回答關鍵問題，是兩回事。① 段落強調的「Trace 能不能把 retrieval 版本、prompt 版本、驗證結果串成一條有因果關係的鏈」，才是決定它有沒有用的關鍵，而這件事取決於你自己的 span 設計與 metadata 規劃（Step 1、Step 15），不是平台 UI 的排版能力。一個 UI 難看但 span tree 設計嚴謹的系統，遠比一個 UI 漂亮但什麼 metadata 都沒記的系統更能扛事故。

誤解四：「用了 AI observability 平台，就不用再管 Prometheus／Grafana／Loki 那一套了。」

這是①段落一開始就要拆穿的誤解，值得在這裡再強調一次：AI workflow trace 平台回答的是「這一筆 request 的 AI 決策為什麼錯」，它從來沒有打算取代「使用者是否受影響、系統整體是否健康」這一層的職責。一個團隊如果因為導入了 Langfuse 或 LangSmith，就放鬆了對 Infrastructure Reliability 這一層的監控，會在下一次資料庫連線池耗盡（Day 10 的情境）或容器被 OOM Killer 幹掉（Day 03 的情境）時，付出雙倍的代價——因為原本熟悉的那套工具鏈被荒廢了，而新導入的 AI 平台又完全看不到這一層。

誤解五：「雙寫入只是多花一點錢，風險可控。」

這個誤解低估的不是金錢成本，而是⑥段落最後那張「隱藏帳單」清單裡除了成本以外的四項：masking 規則分岔、sampling／retention 不同步、SDK／instrumentation 要維護兩套，以及最致命的「incident investigation 時 on-call 猜不到該看哪邊」。金錢成本頂多影響預算審核，這四項風險卻會在事故發生的當下，直接拖慢團隊的反應速度——而反應速度正是可靠性工程真正在乎的東西。

誤解六：「gen_ai.* 已經是 OpenTelemetry 官方標準，schema 不會再變，可以放心當成長期資料模型。」

②段落已經說明過，gen_ai.* 這組 semantic conventions 截至 2026 年 5 月仍處於「Development」狀態，沒有穩定版本時間表，v1.37 到 v1.41 之間幾乎每一版都動到相關屬性的命名或結構。「OpenTelemetry」這個名字帶來的權威感，很容易讓人誤以為它底下的每一組規格都同樣成熟穩定——但 OTel 的核心 trace／span API 已經穩定多年，跟 GenAI SIG 這種 2024 年才成立、仍在快速演進中的子規格，是完全不同的成熟度階段。把一個還在 Development 狀態的命名，當成可以直接散落引用在幾十個 handler 裡的永久 API，跟本文一開始批評的「把某個平台的 SDK 欄位當成長期契約」，其實是同一種錯誤，只是這次犯錯的對象換成了「標準組織」而不是「商業平台」——而「這是標準」這個標籤本身，並不會讓底層的欄位真的變得更穩定。

這六個誤解共通的模式是：每一句話單獨聽都有幾分道理，卻都省略了一個關鍵的但書。接下來的 DIY 步驟，某種程度上就是把這些但書一個個具體驗證出來，而不是繼續停留在會議室裡各自表述的階段。

下集預告：下一篇（中）開始動手，用同一組 workflow 建立中立的 AI telemetry schema，接上 OpenTelemetry、Collector 與 attribute allowlist，讓 Langfuse 與 LangSmith 看到同一份被妥善遮罩過的 trace。

這篇是 Learning SRE for the AI Era 系列的一部分。從 Day 31 把 LangSmith 接成 trace → dataset → evaluation → release decision 的迴圈，到這篇比較 Langfuse 與 LangSmith 的治理與維運條件，核心問題始終沒變：你要用什麼證據，決定下一個版本能不能上線。

工具會換、平台會換，但這條從使用者旅程一路連回 prompt、model、retriever、evaluation 與 release decision 的證據鏈，必須自己保持完整。

Build → Trace → Break → Measure → Evaluate → Recover → Improve.