作者：顾汉杰（执少）
"纸上得来终觉浅，绝知此事要躬行。" ------ 陆游
在 LLM 应用快速发展的今天，我们往往专注于模型调优和功能实现，却忽略了一个关键问题：
如何有效地监控、诊断和优化线上运行的 LLM 应用？
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践，展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
背景：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 平台现有的监控和观测能力下，难以满足我们的生产实践需求。
痛点分析：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.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 在企业级数据开放需求面前存在明显不足：连接数和并发能力受限，缺乏灵活的访问控制和安全管理机制（如数据过滤、脱敏等），数据消费方式单一，缺乏多样化的数据处理和消费能力（非不可实现，但需投入额外建设成本）。
能力重构：基于 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 强大的数据存储、查询和处理能力。
于是我们便有了这样一个轻量但功能完整的诊断系统：
它有着不错的颜值和风格，具备简洁清晰的页面布局，甚至还集成了公司的用户身份认证。
只需要用户提问的请求 ID，它就会追踪串联整个链路和拓扑，你可以看到任一请求、任一阶段、任一节点的执行明细情况，包括输入、处理和输出。
它支持多元数据类型的智能识别，无论是 Markdown、Json、SQL，还是纯文本，都支持智能高亮并完美格式化展示。
它还支持系统提示词和用户提问等动态内容的完整展示，并支持提示词的格式排版、分段展示、内容导航和文字缩放，这对于具体问题的诊断，尤其是细节处的定位，非常有用。（在 Dify 中，系统提示词本质上是一个内容模板，系统会从多处获取或召回片段内容并嵌入其中，每个请求的提示词内容都不一样，阅读完整的提示词内容，快速定位细节问题，非常关键。）
而这一切，我们仅花费了一天时间，从代码实现→数据→服务，实现了全托管，OneDay 果然名不虚传！
而这背后，基于 SLS 的底层数据基础设施所提供的强大能力，才是实现极简风架构的基石：
- 数据层：SLS 提供一站式的数据存储、查询、分析能力
- 应用层：轻量代理仅处理权限安全和必要的业务逻辑
- 展示层：OneDay 根据需求描述快速生成可视化界面
在此不得不提一嘴：AICoding 真的在重塑整个软件行业！
现在，一个想法 + 一个可靠且灵活的数据基础设施 就足够了，剩下的事情交给 AI，就这么简单！
OneDay+SLS 的配合简直是天作之合，它们共同构成了极简风的架构设计，几句话 OneDay 便帮你实现了精美页面，而 SLS 强大的数据基础设施能力助你轻松搞定数据查询、处理和分析工作，无需配置笨重的数据库，无需开发冗长繁琐的服务端处理逻辑（若对安全性有要求，最多仅需一层代理），也无需担心容量、性能、实例规格等琐碎之事。
基于 SLS 强大的数据基础设施，我们快速构建了一套完整的链路追踪和问题诊断系统，验证了 SLS 在实际业务场景中的应用价值。
生产实践：数据驱动的质量优化闭环
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.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 团队出品
本文基于阿里云 SLS SQL Copilot 项目的真实实践经验整理而成。
广告时间：除了可以基于 SLS 数据基础设施灵活建设可观测方案外，阿里云还与 Dify 平台合作，提供了开箱即用的 Dify 链路追踪云监控 2.0 方案，欢迎选用适合您的方案~
点击此处查看接入指南。