許多工程師在開發 AI Agent（AI 代理）時，常面臨一個兩難：想要頂級模型（Frontier Models，如 GPT-4 或 Gemini 1.5 Pro）的強大推理能力，但卻受限於高昂的 Token 成本、回應延遲以及企業對數據外流的資安疑慮。
通常我們的解決方案是嘗試 Prompt Engineering（提示工程）或 RAG（檢索增強生成），但當這些方法達到瓶頸時，如何讓一個小型模型（SLM, Small Language Model）也能擁有接近頂級模型的特定任務表現？答案在於將「生產環境的遙測數據」轉化為「訓練數據」。
這篇文章將分享如何利用 OpenTelemetry (OTel) 捕捉用戶真實行為，建立一個數據飛輪，將頂級模型的行為蒸餾到本地小型模型中。
從 LSP 聊起：為什麼需要 AI 驅動的語意分析
在進入技術核心前，我們先看一個實務案例：AI 驅動的 Language Server Protocol (LSP)。
LSP 是現代編輯器（如 VS Code, Neovim）實現程式碼智能的核心協議。傳統的 LSP（如 Pyright 或 Rust-analyzer）是基於規則（Rule-based）的，它們將程式碼解析成 AST（抽象語法樹），檢查類型是否正確或語法是否出錯。這類工具速度快且精準，但無法理解「語意」。
例如，傳統 LSP 沒辦法告訴你：「這個函數的名字與它實際做的事情不符」，或者「你的錯誤處理邏輯太脆弱」。這就是 AI LSP 的切入點：它不依賴 AST 解析，而是利用 LLM 的語意理解能力，主動提供程式碼診斷與修復建議。
然而，AI LSP 面臨兩個痛點：一是成本，每次存檔就發送請求，Token 消耗極快；二是通用模型並不完全符合個人或特定專案的編碼風格。
利用 OpenTelemetry 捕捉隱式標記
要優化模型，最困難的不是演算法，而是「高品質的標記數據」。傳統上，我們需要花錢請人標記數據，或者讓用戶點擊「讚」或「倒讚」，但這種顯式反饋（Explicit Feedback）的回收率極低。
這裡引入了 OpenTelemetry (OTel)，這是一個工業標準的觀測性（Observability）框架，用於追蹤請求在分散式系統中的路徑。在 AI Agent 中，我們可以將每一次互動定義為一個 Span（工作單元），並將用戶的後續操作記錄為事件。
關鍵在於將「用戶行為」視為「隱式標記（Implicit Labels）」：
強正向信號：用戶直接採納（Accept）了 AI 建議的修復方案。這代表 AI 既找對了問題，也給對了答案。 弱正向信號：用戶點擊重新生成（Regenerate）。這代表用戶認同問題診斷，但對目前的解決方案不滿意。 強負向信號：用戶直接忽略或刪除（Dismiss）建議。這代表該建議對用戶而言是噪音。
當我們將這些行為紀錄在 OTel 的 Trace 中，我們實際上是在讓用戶在正常使用產品的過程中，免費且自然地為我們標記數據。
建立數據蒸餾飛輪
有了 OTel 捕捉的數據，我們就可以建立一個持續改善的飛輪（Data Flywheel）：
第一步：數據提取。將 OTel 導出的 JSON 格式追蹤數據進行過濾，只保留有用戶行為反饋的片段，將其轉換為訓練格式（如 JSONL）。
第二步：模型蒸餾（Distillation）。利用頂級模型（如 Gemini）生成高品質的初始答案，並結合用戶的正負面反饋，對一個小型開源模型（如 7B 或 13B 參數的模型）進行微調（Fine-tuning）。
第三步：本地部署。使用如 MLX 等工具在本地快速微調，將模型部署在本地環境。
這樣做的好處是，小型模型雖然在通用能力上不如頂級模型，但在特定任務（如特定專案的編碼風格）上的表現可以達到 80% 到 85%，且速度極快、成本幾乎為零，且數據完全不出域。
將此能力平台化
如果公司內部有數十個 AI Agent（例如客服機器人、代碼審查助手、數據分析工具），不應該為每個 Agent 單獨設計這套流程，而應該將其打造為平台能力：
1 統一的觀測層：所有 Agent 統一使用 OTel SDK，定義標準的行為標記（如 feedback_span）。 2 共享的提取管線：一套自動化的 Pipeline 將 Trace 轉化為訓練樣本。 3 標準化的微調基礎設施：提供統一的微調與評估（Eval）工具。
透過這種方式，不同 Agent 之間甚至可以共享知識。例如，客服機器人從用戶互動中學習到的產品痛點，可以被蒸餾並餵給文件生成 Agent，讓生成的技術文件更貼近用戶需求。
給工程師的實務建議
如果你想在自己的 AI 產品中實作這套機制，建議遵循以下路徑：
首先，從第一天起就部署 OpenTelemetry。不要等到要微調模型才開始收集數據。即便最後不做蒸餾，OTel 的分佈式追蹤對於 debug AI Agent 的複雜鏈路也至關重要。
其次，設計「可觀測」的用戶體驗。不要只依賴點讚/點倒讚，要將反饋機制融入工作流（例如：採納、重新生成、忽略）。
最後，從小規模開始。選擇一個特定的工作流，收集一個月的數據，嘗試在本地微調一個小型模型。你會發現，針對特定任務的個人化模型，往往比昂貴的通用模型更能提升實際生產力。
來源：infoq.com (Presentation: From OTEL to SLMs: Distilling Frontier Model Behaviour from Production Telemetry)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。