Langfuse：把 Prompt Eval、Dataset、Trace 與成本監控放進同一個 LLM 工程閉環

Langfuse 官方文件把 prompt management 定義為集中儲存、版本化與擷取 prompt 的方式，而不是把 prompt 硬編在程式碼裡。它支援 versions 與 labels，可把 prompt 標到 production、staging、tenant 或 experiment。

實務意義：產品 / domain expert 可以改 prompt；工程端透過 SDK 取用指定版本，降低「小改 prompt 也要完整部署」的摩擦。

官方 evaluation docs 強調：eval 是可重複檢查 LLM 行為的方式，可以把 live traces 轉成 datasets，用 experiments 比較 prompt、model 或 code change，並結合人工評分、程式評分與 LLM-as-a-judge。

實務意義：模型升級、切模型、改 prompt 前，先跑固定資料集與評分規則，避免只看少數 demo case。

Langfuse tracing 會記錄 prompt、model response、token usage、latency、retrieval、embedding、API calls、tool actions 等結構化資料，並可把多輪對話歸為 sessions、追蹤 user。

實務意義：當 AI 產品出問題，不只知道「答案錯」，而是能追到是哪個 retrieval、tool call、prompt version、model call 或成本 / latency 異常。

AI 產品裡的 prompt 其實接近設定檔、商業規則與產品邏輯的混合物。沒有版本、label、rollback 與環境分層時，團隊很快會不知道線上到底跑的是哪個版本。

換模型、調 temperature、改 retrieval chunk、加 tool call 都可能讓回答分布改變。固定 dataset + evaluator 可以把「感覺變好」變成可比較的分數與失敗案例。

傳統 log 通常只記 API request；LLM app 需要記更細：prompt、context、tool、retrieval、token、cost、latency、session、user feedback。否則客服、工程、產品都只能猜。