"紙上得來終覺淺，絕知此事要躬行。" —— 陸游

在 LLM 應用快速發展的今天，我們往往專注于模型調優和功能實現，卻忽略了一個關鍵問題：

如何有效地監控、診斷和優化線上運行的 LLM 應用？

本文將分享我們在構建 SLS SQL Copilot 過程中的工程實踐，展示如何基于阿里云 SLS 打造一套完整的 LLM 應用數據基礎設施。

1.背景：LLM 應用開發的可觀測性挑戰

1.1 Dify 平臺的崛起與局限

Dify 作為目前最受歡迎的 LLM 應用開發平臺之一，以其可視化的工作流設計和豐富的組件生態，大大降低了 LLM 應用的開發門檻。我們團隊也選擇在 Dify 平臺上構建 SQL Copilot 應用，旨在為用戶提供智能化的 SQL 查詢生成和分析服務。

然而，在實際生產環境中，我們逐步發現一個嚴重的問題：Dify 平臺的可觀測能力嚴重不足。作為一個提供可觀測性解決方案的團隊，我們深知良好的監控和診斷能力對于保障服務質量的重要性。這種"自己的狗糧都吃不香"的尷尬處境，促使我們開始思考如何構建一套適合 LLM 應用的數據基礎設施。

1.2 SQL Copilot 的業務復雜性

我們的 SQL Copilot 應用具有以下特點：

• 多子系統協作：包含需求理解、SQL 生成、質量校驗、SQL 診斷等多個子系統
• 復雜工作流：涉及多層嵌套的 Dify workflow，單個用戶請求可能觸發多個子流程
• 動態內容嵌入：大量使用上下文嵌入和 RAG 技術，系統提示詞包含大量嵌入的動態上下文信息和知識庫召回內容
• 高并發場景：需要支持大量用戶的實時查詢生成請求

這些特點在 Dify 平臺現有的監控和觀測能力下，難以滿足我們的生產實踐需求。

2..痛點分析：Dify 平臺可觀測性的三大短板

2.1 查詢能力嚴重不足

現狀描述：Dify 平臺僅提供基礎的賬號查詢功能，用戶只能通過用戶 ID 或會話 ID 進行簡單的歷史記錄查找。

圖片

實際需求：

• 關鍵詞檢索：當用戶反饋"我問了關于訂單分析的問題，但結果不對"時，我們需要能夠通過"訂單"等關鍵詞快速定位相關會話
• 多維度查詢：按時間范圍、錯誤類型、用戶 ID、會話 ID、功能模塊等多個維度進行組合查詢
• 模糊匹配：支持 SQL 語句片段、錯誤信息片段的模糊搜索

痛點：線上問題排查效率低下，用戶反饋的問題往往需要數分鐘才能定位到具體的執行記錄。

2.2 鏈路追蹤能力缺失

現狀描述：Dify 的執行日志以平鋪的方式展示，缺乏層次化的鏈路追蹤能力。

圖片

實際痛點：

• 嵌套工作流追蹤困難：當主工作流嵌套子工作流時，很難下探追蹤子工作流的具體執行明細
• 上下游數據追溯麻煩：當需要查看和比對上下游數據時，往往需要重新查詢，整個追溯過程非常繁瑣，嚴重影響排查效率

案例：當用戶提交 SQL 生成請求時，系統會依次執行會話記憶→智能路由→需求理解→SQL 生成→語法校驗等多個步驟。若最終結果不符合預期，我們需要逐個檢查每個步驟的詳細執行過程以定位具體原因，尤其是當問題復雜時，需要多次切換上下文，整個排查過程往往需要 30 分鐘以上。

2.3 內容展示能力不足

現狀描述：Dify 的日志展示界面對于大段文本內容的可讀性很差，特別是包含大量動態內容嵌入的系統提示詞。

圖片

實際問題：

• 提示詞可讀性差：包含上下文嵌入和 RAG 召回內容的提示詞往往長達幾千字，在 Dify 界面中顯示為一大段沒有格式的文本
• 數據格式解析能力不足：輸入和輸出的數據往往包含多種格式，如 Markdown、JSON、SQL、Text 等，Dify 在界面中只能看到原始字符串，不支持智能格式解析和友好閱讀展示

痛點：當需要排查 SQL 生成問題時，很難快速閱讀和理解完整的上下文，也無法快速跳轉至關鍵章節，降低了問題診斷的效率。

3.深層思考：從可觀測痛點到基礎設施的三重挑戰

在深入分析上述可觀測性痛點的過程中，我們逐漸意識到，這些表面的可觀測性問題背后，實際上反映了更深層次的架構挑戰。

3.1 第一重挑戰：架構擴展性

當我們試圖解決查詢能力問題時，深入調研發現問題的根源在于 Dify 底層架構的擴展性限制：Dify 采用 PostgreSQL 作為底層數據存儲，雖然 PG 在 OLTP 場景表現優秀，但面對大規模日志數據的存儲和復雜查詢分析時，在存儲容量、計算資源、寫入和查詢性能等方面，系統的擴展性正面臨著嚴峻挑戰。

數據規模持續增長的挑戰：隨著用戶量和使用頻次增長，海量的執行日志、交互數據、模型調用記錄快速積累。即便使用云上 PostgreSQL，仍受實例規格束縛，面臨規劃和擴容難題。真正需要的是無限彈性、按需擴展、按量計費的底層數據基礎設施。

突發流量的資源彈性不足：高并發時 PG 受限于連接數和處理能力，若資源不夠常會導致服務延遲甚至超時。而 LLM 應用的人機交互特性決定了流量波峰波谷明顯，持續高配實例將導致資源利用率低，甚至可能造成 2-3 倍的成本浪費。

升級和擴容的復雜性與風險：云上 PG 雖支持在線擴容，但仍需人工規劃和評估，且可能涉及服務重啟或性能波動風險。我們的 Copilot 服務親身經歷過多次線上擴容的"驚險"時刻。

3.2 第二重挑戰：數據處理能力

當我們試圖分析和診斷線上問題時，發現底層基礎設施在 LLM 應用數據的查詢能力上（特別是可觀測方面）存在局限：

多維查詢性能瓶頸：LLM 應用產生大量的自然語言文本（用戶問題、系統提示詞、模型回復等），雖然 PG 支持全文檢索，但在處理海量長文本數據的關鍵詞檢索、模糊匹配等方面性能有限，也難以支撐前面提到的"多維度查詢"等需求。

實時分析能力不足：當我們需要即席查詢"相同問題影響了多少用戶"、"不同錯誤類型的分布情況"等多維度分析時，Dify 并未提供相應的分析能力，無法滿足復雜多變的即席查詢和分析需求。

數據結構復雜多變：LLM 應用數據包含復雜嵌套的多種格式（如：JSON、Markdown 等，涉及提示詞、參數配置、生成結果等），并且數據結構常隨開發迭代動態變化，PG 在復雜日志數據的查詢、提取、分析方面遠不如專業的日志分析引擎靈活高效。

3.3 第三重挑戰：數據多樣化需求

當我們試圖優化問題診斷流程和內容展示時，意識到了一個更深層次的問題：

需求場景日趨多樣化：LLM 應用百花齊放，不同領域需求呈現多樣化趨勢。質量團隊需要質量評估和回歸測試，產品團隊需要用戶分析和需求挖掘，算法團隊需要模型訓練和效果評估，運維團隊需要鏈路診斷和性能分析。這些需求遠超 Dify 平臺功能邊界。

數據開放性需求凸顯：作為 LLM 應用開發平臺，Dify 接觸到最完整的第一手數據，但難以滿足各行業、各角色的多樣化需求。用戶希望獲取這些數據資源，結合業務特點進行深度分析或定制開發，對數據開放性提出更高要求。

數據基礎設施能力不足：PG 在企業級數據開放需求面前存在明顯不足：連接數和并發能力受限，缺乏靈活的訪問控制和安全管理機制（如數據過濾、脫敏等），數據消費方式單一，缺乏多樣化的數據處理和消費能力（非不可實現，但需投入額外建設成本）。

4.能力重構：基于 SLS 的數據基礎設施實現能力躍升

正是基于上述三重挑戰的深入思考，我們意識到：單純的功能修補無法解決根本問題，我們需要徹底重構底層數據基礎設施，以在能力上滿足多重挑戰的需求。 而作為一個提供可觀測性解決方案的團隊，我們深知 SLS 的能力所在與無限潛力，面對這些挑戰，內心不禁自信地喊出：“正是在下！”

SLS 在應對這些難題時具備天然優勢：

架構擴展性方面：SLS 作為完全托管的云原生服務，在規模、性能、彈性、成本等方面，實現了真正的在線無縫、彈性擴展、按需付費，能夠動態調整資源而不影響業務連續性，無需人工規劃或擔心擴容風險，從根本上解決了 PG 面臨的擴展性瓶頸。

數據處理能力方面：LLM 應用數據天然具有日志屬性，而 SLS 專門服務于日志場景，原生支持全文檢索、多維查詢、靈活聚合分析，并且數據處理能力隨數據規模線性擴展，在處理 LLM 應用產生的海量文本和 JSON 數據方面表現卓越。

多樣化需求方面：SLS 提供豐富的數據查詢、處理和消費方式（查詢、SQL、API 接口、流式加工、投遞等），支持細粒度的訪問控制和數據分發管理（通過 storeview 控制行粒度甚至字段粒度的數據可見性和安全性），支持松散 Schema 甚至完全無結構化數據，能夠靈活滿足不同團隊的數據需求。

4.1 架構重構：從雙寫到能力重構

基于這樣的技術優勢，我們選擇了 SLS 作為新的數據基礎設施，考慮到線上業務的穩定性和風險控制，我們制定了漸進式的架構重構策略：保持原有 PG 寫入鏈路不變，同時新增 SLS 異步寫入鏈路。

圖片

這樣做的好處是：

業務安全優先：保持 PG 作為主要的在線業務數據存儲，確保 Dify 核心功能不受影響，所有原有的查詢、統計、業務邏輯繼續基于 PG 運行。

數據面解耦：通過異步寫入 SLS，實現數據層面的解耦，將可觀測、分析、監控等需求從主業務庫中分離出來，既避免了對在線服務造成性能影響，又增強了數據查詢和處理能力。

功能負載分離：PG 專注提供在線執行負載（用戶管理、會話管理、實時查詢等），SLS 承載所有離線分析負載（日志查詢、統計分析、監控告警等）。

架構漸進式演進：為未來底層數據基礎設施的進一步演進預留空間，可以根據業務發展需要，逐步將更多功能遷移到基于 SLS 的新數據基礎設施上。

4.2 能力升級：SLS 核心能力展示

現在，有了全新的數據基礎設施，基于 SLS 強大的數據處理引擎，我們在全文檢索、多維查詢、即席分析等方面實現了質的飛躍。面向多樣化場景的數據擴展能力得到極大增強，可以輕松支撐質量團隊的回歸測試、產品團隊的用戶分析、算法團隊的模型優化、運維團隊的問題診斷等多樣化場景需求。

多元數據支持

無論你的數據是 Json、Markdown、Text、SQL 還是數值參數，SLS 都兼容并蓄，并且還貼心地為用戶提供了如 Markdown、JSON 等常用數據格式的可讀性格式渲染，助力輕松閱讀并理解數據。

日志原文

Markdown 數據格式化展示

Json 數據格式化展示

快速全文檢索

比如，我們在面對第二章中提到的用戶反饋問題時，現在可以輕松根據“訂單”字樣快速檢索出相關問題的請求。

多維組合查詢

我們還可以通過組合多個維度的查詢條件（如 uid、會話 ID、動作、錯誤類型等） 實現對某種特征請求的精準檢索。

圖片

實時洞察分析

更進一步，我們還可以通過 SQL 針對某種特征數據進行靈活的聚合統計和分析，如下例：我們按天統計用戶提問中有“包含”字眼的請求趨勢變化。

圖片

基于 SLS 的 SQL 分析和可視化能力，我們還可以為業務輕松構建黃金指標，定制運營大盤，深入洞察并分析交互留存轉化、每日請求趨勢變化、錯誤分布情況、SQL 質量監控（可執行率和有效數據率）、用戶滿意度監控等。

圖片

圖片

圖片

得益于 SLS 強大且靈活的查詢和分析能力，我們還可以進一步根據具體業務場景對用戶行為進行更深度的分析和洞察，比如：

• 相同問題影響了多少用戶？
• 不同用戶群體的問題特征分布如何？
• 哪些 SQL 模式最容易出錯？
• 用戶的操作行為模式是什么？

4.3 場景落地：基于 SLS + OneDay 構建輕量級鏈路追蹤與問題診斷系統

在第二章中，我們提到 Dify 本身的鏈路追蹤和內容展示的不足，在實際排查問題時非常費力。當下正值 AICoding 盛行，在有了 SLS 強大的數據基礎設施加持之下，于是我決定親自動手，打造一個輕量級的鏈路追蹤和問題診斷系統，順便也體驗一下 AI 驅動的新研發模式。

在實踐中，我使用到了集團的 AICoding 平臺 OneDay（阿里巴巴內部的一個基于AI的創意應用生成平臺）構建前端系統，后端則直接基于 SLS 強大的數據存儲、查詢和處理能力。

圖片

圖片

于是我們便有了這樣一個輕量但功能完整的診斷系統：

而這一切，我們僅花費了一天時間，從代碼實現→數據→服務，實現了全托管，OneDay 果然名不虛傳！

而這背后，基于 SLS 的底層數據基礎設施所提供的強大能力，才是實現極簡風架構的基石：

• 數據層：SLS 提供一站式的數據存儲、查詢、分析能力
• 應用層：輕量代理僅處理權限安全和必要的業務邏輯
• 展示層：OneDay 根據需求描述快速生成可視化界面

在此不得不提一嘴：AICoding 真的在重塑整個軟件行業！

現在，一個想法 + 一個可靠且靈活的數據基礎設施 就足夠了，剩下的事情交給 AI，就這么簡單！

OneDay+SLS 的配合簡直是天作之合，它們共同構成了極簡風的架構設計，幾句話 OneDay 便幫你實現了精美頁面，而 SLS 強大的數據基礎設施能力助你輕松搞定數據查詢、處理和分析工作，無需配置笨重的數據庫，無需開發冗長繁瑣的服務端處理邏輯（若對安全性有要求，最多僅需一層代理），也無需擔心容量、性能、實例規格等瑣碎之事。

圖片

基于 SLS 強大的數據基礎設施，我們快速構建了一套完整的鏈路追蹤和問題診斷系統，驗證了 SLS 在實際業務場景中的應用價值。

5.生產實踐：數據驅動的質量優化閉環

5.1 問題診斷與質量優化流程

我們最終還是要回到生產實踐中來，為 SQL Copilot 產品建設而服務，我們建立了一套完整的質量優化閉環：

圖片

這里值得一提的是，在 AI 應用的構建和迭代過程中，我們應該充分利用手頭一切可用的資源，并且全面面向 AI。

比如這里，我們將 SLS 和釘釘 AI 表格結合：利用 SLS SQL 分析能力處理海量的請求數據，整理出錯誤問題并有效識別錯誤特征（通過正則模式匹配識別，比如 case when msg like '%cannot be resolved%' then '列引用錯誤' ...），然后通過下載將結果數據導出，并導入釘釘 AI 表格（前身是釘釘多維表格），于是我們便可以利用 AI 表格中的諸多特性（如分組、篩選等），還可以通過表單形式進行人工審閱和標注，診斷具體問題時則直接跳轉到上章所述的診斷系統中，實現請求→問題→數據的串聯。

而“全面面向 AI”并不是空喊口號，釘釘已在很多 AI 平臺中做了集成，包括 AI 表格本身后續也會開放 AI 助理的能力（PS：已申請內測，期待能力開放。），我們不斷沉淀的數據（包括人工標注）后續能否被高效地作為 AI 的生產資料和知識使用，這是我們選擇工具的邏輯和策略標準。

圖片

圖片

圖片

5.2 關鍵指標與評估體系

Copilot 的質量評估，是衡量和反饋版本迭代好壞，指引優化方向的關鍵工具，我們經歷了反復摸索和多輪迭代，最終確定了如下。

核心質量指標：

• SQL 可執行率：生成的查詢 SQL 語句語法正確且能夠執行的比例
• 數據有效率：SQL 執行后返回有意義結果數據的比例
• 響應時間：從用戶提問到返回結果的完整耗時
• 用戶滿意度：基于用戶反饋和利用 LLM 反向評估生成質量的綜合評分

這套質量評估體系簡單、明確、具體、可執行，也將指導我們后續的迭代和優化工作。

5.3 實際效果提升

我們在最近 3 個月內，將這套基礎設施逐步建設起來并投入使用，目前正在持續優化 Copilot 質量，也取得了階段性的效果提升：

問題診斷效率提升：

• 問題定位時間：從平均 30 分鐘降低到 5 分鐘內，提升 83%
• 根因分析準確率：從 60% 提升到 90%，提升 50%
• 問題修復周期：從平均 3 天縮短到 1 天，提升 67%

服務質量改善：

• SQL 可執行率：從 75% 提升到 85%，提升 10 個百分點
• 用戶滿意度：從 3.2 分提升到 4.3 分（5 分制），提升 34%
• 問題追蹤覆蓋率：從人工抽查的 10% 提升到全量監控的 100%

6.經驗總結與未來展望

6.1 AI 時代新趨勢

架構輕量簡潔化：

• 全托管的數據基礎設施，使系統架構輕量簡潔，讓團隊專注于核心業務創新
• "想法+數據+AI"的研發模式，簡潔、高效，釋放無限創造力

工具鏈融合趨勢：

• SLS + OneDay + 釘釘 AI 表格，展現了 AI 時代多工具鏈協同的巨大潛力
• 從想法→實現→流程的路徑，在 AI 加持下被極大簡化，開發效率實現躍升

數據驅動的質量閉環：

• 回歸業務本身，建立清晰可靠的評估指標是 LLM 應用開發的首要任務
• 從數據收集、分析、洞察、到優化的完整反饋閉環保障持續改進

6.2 未來展望

智能升級：

• 基于歷史數據沉淀用戶語義和偏好，智能推測用戶真實意圖
• 基于數據基礎設施，利用 LLM 技術自動生成問題診斷報告和優化建議
• 構建智能化的根因分析系統，減少人工判斷的工作量

生態合作：

• Dify 雙寫實現已計劃貢獻給開源社區（由言合實現），阿里云可觀測能力也已集成到 Dify 官方平臺
• 不僅限于 Dify 平臺，我們期待與更多優秀的 LLM 應用平臺深度合作，推動云原生可觀測能力建設

結語

LLM 應用的快速發展正在改變著我們的工作和生活方式，但與此同時，如何保障這些應用的穩定性和質量成為了一個重要挑戰。正如我們在 SQL Copilot 項目中的實踐所示，完備且能力強大的底層數據基礎設施和可觀測能力是 LLM 應用成功的重要保障。

通過本文分享的基于 SLS 構建 LLM 應用的數據基礎設施的實踐經驗，我們希望能夠為更多的開發者和團隊提供參考和啟發。在 AI 技術日新月異的今天，讓我們不僅要追求功能的創新，更要注重基礎設施的建設，只有把基礎打牢，才能在智能化的道路上走得更遠、更穩。

"工欲善其事，必先利其器。" 愿每一個 LLM 應用都能擁有完善的可觀測能力，在智能化的征程中行穩致遠。

作者：執少 | 阿里云 SLS 團隊出品