4 月 9 日晚，DataFunSummit 视频号组织了一场主题为“从 ChatBI 到 DataAgent——AI 驱动的数据架构与决策落地实践”的直播对话。
主持人杜淑均与两位嘉宾——小红书数据分析平台技术负责人杨周智、观远数据合伙人兼产品负责人严林刚，三位嘉宾分别站在甲方平台、乙方产品和内部技术落地的不同视角，坦率呈现了 Data Agent 从 Demo 到生产级可用之间最真实的鸿沟：不是模型够不够强，而是语义是否收敛、知识是否被结构化、系统能否被解释、结果能否被业务信任。换句话说，企业真正需要的不是“会写 SQL 的大模型”，而是“能在复杂数据世界里稳定工作、持续进化、并且敢被业务使用的智能系统”
这不是一场谈“概念”的直播，而是一场谈“工程现实”的直播
直播一开始，杜淑均就把氛围定得很务实。他先介绍了本次对话的背景：这不仅是一场技术社区交流，也是在为即将到来的 DACon 大会预热。随后，杨周智和严林刚分别介绍了自己的工作背景：前者长期深耕企业大数据与分析平台，当前主要负责小红书分析平台与 BI 体系；后者则长期在 BI、商业智能与数据科学平台产品领域工作，更关注企业级智能决策 Agent 的可靠落地。这样的嘉宾组合，也决定了整场讨论不是泛泛而谈，而是始终围绕“怎么真正做出来、跑起来、交付出去”展开。
统一语义层：问题从来不只是“建不建”，而是“怎么承载变化”
主持人抛出的第一个问题就很尖锐：统一语义层到底该采用 Cube、View，还是 API 抽象？而且当业务口径变化时，系统多久能够更新？这一下把讨论拉回到企业数据智能最底层的现实：语义层从不是一个漂亮的概念，而是取数准确性的基础设施。
杨周智的回答非常贴近工程实践。他没有先讲宏大的“统一语义层平台”，而是直接聚焦到最容易把系统做崩的地方——维度值映射。用户口中的“某某行业”“某类商家”“那个广告主”，往往和底层数据存储中的真实值根本不一致。于是，小红书在做 ChatBI 时，把大量精力花在维度、维值、别名、口语表达和实际存储值之间的映射上：高频维值被提前抽取出来，放入加速引擎；消费时再通过语义理解和召回，把用户自然语言映射回正确的数据对象。用他的话说，这本质上是一套“逻辑视图”，但必须有平台化维护能力。
严林刚则从另一侧补充了这个问题。他认为，语义层当然重要，但它未必只能以一种固定的形式存在。对一些场景来说，是 To SQL；对另一些场景来说，是 To DSL；还有些场景，更重要的是前端的意图识别和维值识别。也就是说，真正决定准确率的，往往不是“最后生成什么”，而是“前面理解得对不对”。他说得很直接：很多不准确，并不出在 SQL 生成阶段，而出在用户说了一个业务黑话，系统却没认出来。
杜淑均则分享了更偏“规范化定义”的做法：对于高频、核心、稳定的 KPI 报表，采用接近 YAML 配置式的语义模型来定义维度、度量与口径；对于更灵活的长尾问题，则用增强元信息与枚举值封装等方式，把知识在执行时动态提供给模型。三位嘉宾在这里形成了一个很有意思的互补：语义层不是单一产品形态，而是一种让“企业隐性知识显性化”的系统能力。
Prompt还是SFT：没有谁能永远靠“调提示词”赢下去
当话题转到 Prompt 工程与模型微调时，现场的分歧明显起来了。
杨周智的判断很鲜明：Prompt 在前期非常有用，但一定有上限。他们在早期主要依靠 Prompt 调整 DSL 生成格式、补充业务知识、增强维度召回等方法，确实能把测试集效果提升到六七成；但再往上走，就越来越难。因为上下文有限，注意力机制会漏指令，链路也越来越复杂。到这个阶段，如果还在不停“往提示词里加东西”，收益会迅速递减。于是，小红书选择在链路的不同阶段做 SFT，把准确率进一步提升到 85% 左右。这个回答里最打动人的一句是：当你发现“疯狂调 Prompt 但效果不涨”的时候，其实系统已经在告诉你，该换路了。
但严林刚的立场几乎正相反。作为服务多客户的产品方，他明确表示，观远数据当前并不主张微调基座模型。原因并不神秘：客户会偏好不同模型，底层技术也在快速迭代，如果对某个模型做深度绑定，产品可复制性就会下降。所以他们的做法，是把系统提示词做成稳定底座，用 Benchmark 和回归测试持续维护；同时把错题集、业务知识、SQL 语法约束、分析方法等内容做成可注入的知识模块，动态参与推理过程。对于他们来说，微调不是不能做，而是“商业上不划算”。
这场分歧并没有走向对立，反而很能说明企业 AI 的真实面貌：甲方更愿意为某个关键场景深度优化，乙方则更在意跨场景复用与产品化边界。一个追求极致准确率，一个追求稳定可交付，它们分别代表了两类完全合理的路线。
“找数难”没有因为AI出现而消失，只是换了一种形式继续存在
在 AI 出现之前，“找数难”就是数据团队最熟悉的老问题。表太多、口径太杂、资产边界不清，最后往往还得去问人。到了 Data Agent 时代，这个问题并没有消失，只不过从“人怎么找表”，变成了“Agent 怎么找对表”。
杨周智给出的答案是“先缩圈，再识别”。小红书并没有让 Agent 在成千上万张表里自由探索，而是先按业务线圈定一批更官方、更可信、更常用的数据集，再在这个范围内做问题理解、候选集匹配与语义打标。尤其关键的是，他们还会区分哪些表更适合看明细，哪些表更适合看聚合结果。换言之，找表从来不只是检索问题，更是选择策略问题。
严林刚则强调，“找表”的前提其实是数据治理。表有没有被梳理过，字段有没有注释，资产有没有热度，使用人群是否明确，决定了 Agent 能不能把这些资产当作可信资产来使用。他建议按主题建设数据问题空间，把每个主题控制在相对可控的表规模内。再往后，才是通过问题重写、实体抽取、维值向量召回和表路由，把问题送到真正应该回答它的数据对象上。这个思路特别有代表性：不是让 AI 代替治理，而是让 AI 站在治理结果之上工作。
口径不一致：Agent不该“自己判断”，而该“学会听谁的”
“活跃企业用户”在三个系统里有三种定义，Agent 到底该听谁的？这是直播里最接近“企业现实政治学”的问题。因为很多时候，所谓数据智能的难点，并不是算法，而是组织。
杨周智的回答很清晰：这种问题最终还是要回到统一指标平台。官方指标、标准口径、关联数据集，都应该在平台上有明确登记。Agent 不是裁判，它不应该自己发明定义，而应该优先服从被组织确认过的定义体系。严林刚则补充说，除了指标定义，还需要上层路由机制：同一个指标可能能在不同层级、不同主题、不同聚合路径里查到，但系统必须知道“问这种问题时该去哪儿查”。
这段讨论背后的共识很重要：Data Agent 的“智能”，不是拥有无限解释权，而是在企业边界内形成受约束的解释力。真正可用的 Agent，从来不是“什么都敢答”的系统，而是“知道哪些该自己推理，哪些必须尊重制度”的系统。
多轮对话：真正难的不是记住，而是记住“该记的东西”
“再算一下那个的同比。”这句在用户看来再自然不过的话，对系统却可能是噩梦。因为“那个”到底是哪个？是上一轮的指标、维度、筛选条件，还是更久之前提到的口径？
杨周智把记忆机制分成短期和长期两类。短期记忆主要依赖当前上下文窗口，但为了不让 Token 膨胀失控，他们会做压缩；长期记忆则通过离线总结，把用户过去的分析习惯、关注对象沉淀下来，在下一次问答前进行召回。严林刚的做法更“克制”一些：他们认为绝大多数业务问题不需要无限长的会话记忆，因此更多采用轮次裁剪和问题重写，把上一轮真正有效的信息沉淀进当前问题里，而不是把全部上下文原样喂回模型。
这其实揭示了一个很好的产品原则：多轮对话的关键不在于“记得越多越好”，而在于“压缩后仍然保留关键约束”。一个成熟的 Data Agent，最终应该像一个懂业务的分析师：它不会逐字记住所有对话，但会抓住真正有用的上下文。
从Demo到生产：最大的难点，不是生成，而是被信任
直播进行到中段，话题终于落到了最核心的一问：为什么很多 Demo 看起来很好，但一到生产就不行了？
杨周智的回答很直接：最大的障碍还是准确性。用户对取数的容错率极低，一次答错，信任就会迅速下滑。更进一步，用户还希望 Agent 不只是取对数，而是提供有价值的洞察，这对系统提出了更高要求。严林刚则从交付视角指出，真正棘手的是“可验收标准”。什么叫准确？准确到多少才能上线？多长响应时间用户能接受？当你为了准确率叠加越来越多链路，多轮推理、多次校验、多模型交叉验证固然能提升质量，但延迟也会急剧增加，用户体感很可能反而变差。
这段讨论非常残酷，也非常真实：生产级 Data Agent 不是模型问题，而是系统工程、产品边界和用户预期的联合问题。它考验的从来不是“能不能做出一个惊艳 Demo”，而是“能不能定义一个业务真的愿意验收的系统”。
可解释性：用户不是只想要答案，他还想知道“为什么信你”
关于可解释性，三位嘉宾的态度几乎一致：这绝不是锦上添花，而是业务信任的入口。
杨周智提到，一个有效做法是把思维链显性化，让用户看到系统的分析框架；同时，报告里不能只有文本结论，还必须有数据支撑，并且能进一步查看引用的数据配置、指标、维度和筛选条件。严林刚则把这个问题做得更工程化：他们会并行生成多个结果，做交叉比对，以提高可信度；更关键的是，在长报告场景里，数据本身不直接由模型“写出来”，而是由模型驱动脚本去原始数据源取数，再回填到报告中，从而最大限度避免读数幻觉。
这意味着，企业级可解释性并不只是“把推理过程说出来”，还包括“证明数据是真的”“让用户知道系统遵循了哪些规则”。解释，不只是语言能力，更是系统设计能力。
如果大模型API成本涨十倍，先砍谁？
这个假设题很妙，因为它逼着所有人从“技术理想”退回“商业现实”。
杨周智的选择很明确：最先优化掉的是重 Token 消耗的多 Agent 协同场景；与此同时，会重新审视 SFT 的实施方式，比如从训练大模型转向蒸馏小模型或本地化部署；但语义缓存不会轻易砍掉，因为它本身就是降低成本、提升响应速度的重要手段。严林刚则把问题拉回 ROI：一场高价值管理决策会议，值得投入更高推理成本；但如果是成千上万门店每天的例行问报表，就未必适合用昂贵的大模型链路。他还提到，很多环节完全可以规则化、模板化，从而降低对生成模型的依赖。
这里能看到两位嘉宾都很清醒：企业不可能无限为“更聪明”买单，真正能活下来的系统，一定是既有智能增益，也有成本纪律。
SFT、RAG与飞轮：最终比拼的不是单点能力，而是闭环能力
当讨论来到“系统如何持续变好”，直播的层次就从技术组件，升到了组织能力。
杨周智分享了很典型的 SFT 飞轮：把线上问题聚类，找代表性样本，进入训练池，由 AI 初筛、人工抽检，再做新一轮微调与测试，通过后上线，继续收集新问题。严林刚则提出了“三层飞轮”的说法：用户反馈形成第一层；平台积累 Bad Case、优化提示词形成第二层；而在更高层面，服务多个行业客户后沉淀下来的行业 Know-how、分析案例和思维框架，会成为新的知识资产，反过来赋能后续客户。
如果说前面的话题都在讨论“一个 Agent 怎么做”，那这里讨论的其实是“一个组织怎么持续造出更好的 Agent”。单次回答做得漂亮不难，难的是把错误、反馈、经验和行业知识不断沉淀为系统能力。
Text-to-SQL还是Text-to-Semantic-Query：争论的重点，也许根本不在“SQL”
最后一个路线问题也很有意思。杨周智更倾向于 DSL 或语义代理层的路径。他认为 SQL 太灵活、训练数据又太多，反而容易把模型带偏；相比之下，受限的 DSL 在语义层之上更可控，也更适合企业级 BI 场景。严林刚则相对中立：To SQL、To DSL，甚至直接到仪表板，本质上都是可选项，核心问题不在于最后翻译成什么，而在于前面的意图识别、实体理解与业务上下文是否成立。
这一问的真正价值，也许不在于得出结论，而在于提醒我们：企业数据智能的终局，不会是“人人都和数据库直接对话”，而更可能是“人人都在和一个语义代理层对话”，至于底层最终调用的是 SQL、DSL、API，还是某个仪表板，并不一定需要用户知道。
Data Agent的终局，不是更像聊天，而是更像“可信的分析同事”
在直播尾声，三位嘉宾没有沉迷于“AI 会不会替代分析师”的宏大叙事，而是反复回到一个务实判断：企业真正需要的，不是一个什么都能说的大模型，而是一个知道该查什么、该信什么、该解释什么、该沉淀什么的智能系统。它必须建立在语义层、数据治理、知识闭环、权限控制和产品可解释性之上。只有这样，Data Agent 才可能从一个令人惊艳的演示，变成一个能走进业务、进入流程、真正辅助决策的生产工具。
如果一定要用一句话概括这场对话，我会写成这样：从 ChatBI 走向 Data Agent，真正的分水岭从来不是“模型变得更强”，而是“系统终于值得被信任”。
想进一步体验 AI+BI 在业务分析中的落地效果，可以从这里开始。
