為任何智慧體、任何地點提供可觀測性：基於 Databricks 的 OpenTelemetry 與 Unity Catalog 實現生產級追蹤

隨著 AI 應用進入生產環境，追蹤（Tracing）成為理解智慧體行為的關鍵手段，它能夠捕獲提示詞、工具呼叫、響應、延遲和執行路徑。然而，傳統的可觀測性工具在處理 AI 智慧體產生的海量追蹤資料時面臨成本高昂、難以治理和分析靈活性不足的問題。

Databricks 現在透過支援將 OpenTelemetry（OTel）追蹤直接寫入 Unity Catalog 表來解決這一難題。該方案基於完全託管、無伺服器的 Zerobus Ingest 引擎，能夠以原生格式攝取 OTel 資料，並將其儲存為 Delta 表。這意味著追蹤資料可以像其他任何資料集一樣，享受 Lakehouse 的可擴充套件性、治理能力和工具生態。

為什麼 AI 追蹤打破傳統可觀測性

AI 追蹤資料不僅用於除錯，還廣泛用於評估、分析和監控。團隊希望長期保留這些資料，用 SQL 進行分析，與業務和模型資料關聯，並用於評估和監控。然而，當追蹤資料僅存在於可觀測性系統中時，靈活性受限，治理碎片化，將資料遷移到分析工作流需要額外的管道和複製，尤其是在涉及敏感提示詞資料時。

架構：無伺服器 OpenTelemetry 攝取

Databricks 的解決方案摒棄了傳統的多跳遙測管道，透過 Zerobus Ingest 提供單跳攝入。任何支援 OTel 的客戶端（包括流行的 AI 智慧體框架）都可以透過 gRPC 或 REST API 將追蹤、日誌和指標直接傳送到 Unity Catalog 表。這種“單接收端”架構消除了對 Kafka 等中間訊息匯流排的需求，降低了運維複雜度。

教程：將追蹤接入 Lakehouse

為了演示端到端的追蹤，本文使用了一個基於 LangGraph 構建的“支援經理助理”智慧體。該智慧體呼叫 Databricks 託管的 Claude Sonnet 模型進行推理，並透過 MCP 工具 API 呼叫 Genie 空間來查詢支援資料集。透過 MLflow 配置 OpenTelemetry 表後，智慧體的每次呼叫都被自動追蹤，包括模型呼叫和工具呼叫。

在 MLflow 實驗中，使用者可以觀察到智慧體的完整執行路徑，例如它為回答“我應該推薦哪位支援工程師晉升”而三次呼叫 Genie 空間來收集資料。追蹤資料以 Delta 表的形式儲存，支援 SQL 查詢，例如透過 mlflow_experiment_trace_unified 檢視檢視請求、響應和跨度詳情。

超越除錯：追蹤資料的分析

追蹤資料儲存在 Unity Catalog 後，立即可用於批處理和流分析。Unity Catalog 的細粒度訪問控制確保了敏感提示詞資料的安全性，同時允許團隊使用 SQL 構建儀表盤、ETL 流水線和自定義分析。

MLflow 實驗 UI 提供了原生可觀測性儀表盤，包括追蹤量、錯誤、延遲、令牌使用量和成本。此外，由於追蹤表只是 Delta 表，使用者可以使用 AI/BI 儀表盤構建自定義檢視，例如嵌入合同定價的實際成本分析，以及元件級效能監控（如單個工具的 P50/P99 延遲和錯誤率）。

透過將生產追蹤資料與分析工作流統一，團隊可以建立持續改進的飛輪：生產行為驅動評估和分析，進而加速迭代並提升智慧體效能。