用魔法打败魔法！AI和SLS的相互赋能。我们正在基于AI不断拓宽SLS的能力边界，用SQLCopilot让SLS更好用；同时也在发挥SLS的无限潜能，去趟平AI实践路上的痛点与深坑。当Dify遭遇可观测的三大痛点，当问题排查耗时30分钟以上，我们选择用SLS让AI变得更好...
"纸上得来终觉浅，绝知此事要躬行。" —— 陆游
在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构建前端系统，后端则直接基于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应用都能拥有完善的可观测能力，在智能化的征程中行稳致远。