企业级AI落地

• Sandipan Bhaumik（自称 Sandy）是 Databricks 数据与 AI 方向的技术负责人；加入前在 Amazon Web Services（AWS，亚马逊的云计算部门）做了 5 年数据与 AI 的首席架构师，长期用分布式系统构建、扩展数据和 AI 平台。→ 详细
• 最近两年他主要陪客户摸索「这套全新 AI 技术到底怎么用」，客户横跨 B2B 软件行业和金融服务这类强监管行业；这套 playbook（行动手册）就是他「在一线战壕里」总结出来、并已在多家客户组织落地的框架。→ 详细
• 他给听众一个用法建议：把今天大会各个分场学到的零散知识，往这个框架里「对号入座」，看每块知识分别落在哪个环节——框架是收纳盒，散装知识是物件。→ 详细

• 两年前他注意到一个普遍套路：所有人都想拿 AI 干点什么，高层施压「必须做个 demo 出来」，而每次对话的开场白都是「咱们先选个模型吧」——是用 GPT 还是用 Claude，组织内部为此吵得不可开交。→ 详细
• 他强调这「不能怪谁」，因为当时整个市场就是这氛围：模型是新技术，大家满嘴都是模型。选定模型后，团队又为「这应用到底该做哪些功能」反复扯皮。→ 详细
• 关键错误在顺序：把「选模型」当起点，等于在还不知道「成功长什么样」的时候就先动手——这是后面一切翻车的源头。→ 详细

• 团队在受控环境里搭 demo：数据集可预测、场景有限，于是 demo 看起来棒极了，领导一高兴就拍板放行，直接扔进生产环境。→ 详细
• 结果几周后大家开始发问「这 AI 到底在干嘛？为什么回答方式跟 demo 时期待的完全不一样？」——投资回报无从谈起，搭这些永远上不了生产的 demo 的钱和精力全打了水漂。→ 详细
• 这条路径之所以致命，是因为受控 demo 和真实生产是两个世界：可预测数据 vs. 每天成千上万条真实查询、有限场景 vs. 各种刁钻边缘情况。→ 详细

• 可观测性鸿沟（observability gap）：AI 一旦投入生产，如果你看不到它实际在做什么、无法追踪它做的每一个决策，那它在生产里就毫无用处。→ 详细
• 评估鸿沟（evaluation gap）：当年那么多对话，从没认真想过「到底要衡量哪个核心指标」。嘴上会聊准确率、延迟、groundedness（答案有没有事实依据），但从没把「真正对业务重要的东西」定义清楚，也没想过怎么搭系统去持续衡量它到底在变好还是没变好。→ 详细
• 治理鸿沟（governance gap）：根本没想过「AI 在生产里出事了怎么办」——谁来担责？凌晨三点出岔子找谁？喂给 AI 答案的数据资产谁负责？AI 对客户胡说八道了会怎样？没有问责，也没有任何治理。→ 详细
• 这三个鸿沟直接催生了下面的五大支柱框架。→ 详细

• 讲者强调：这五根支柱是你在项目还没启动之前就必须想清楚的，想清楚后再逐步去建——最好按顺序，但他坦承「现实里这个顺序根本走不通」，不过不管怎样开工时必须知道、必须想到这五根。→ 详细
• 五根支柱依次是：① 评估（evaluation）② 可观测性 / 追踪（observability / tracing）③ 数据底座（data foundation）④ 编排（orchestration）⑤ 治理（governance）。→ 详细
• 核心反直觉点：把「选模型」从第一步挪到接近最后一步；前面四根支柱搭好了，选模型反而变成一件很快就能搞定的事（见案例「第 7 周才选模型」）。→ 详细

• 评估本质上是你 AI 系统的 specification（规格说明书）：在动任何一行代码、讨论任何模型和功能之前，先定义成功长什么样。→ 详细
• 不能嘴上聊聊准确率就完了，要拿数字把它定死——比如对你的业务用例准确率到多少才算好、能容忍什么样的误报（false positive）、分流率（deflection，把简单咨询从人工转给 AI 的比例）应该是多少。→ 详细
• 举例：银行聊天机器人的一个核心目标，就是把简单咨询**分流（deflect）**给 AI agent，让人工坐席不必处理这些；所以你得追踪这些咨询、追踪这些数字，把这套系统建起来。→ 详细

• 第二件事是构建测试用例，也就是评估数据集 / 黄金数据集（golden dataset，被人工确认为「标准答案」的成套测试样本）：去跟领域专家聊，搞清楚现实中人工客服面对某个具体问题会怎么回答客户，把这些信息收集起来。→ 详细
• 尤其要收集灰色地带、边缘情况——人工坐席碰到客户问了个含糊不清的问题时会怎么处理，这些都进数据集。→ 详细
• 然后把 AI 测试自动化：给 AI 抛问题→它作答→拿答案跟测试集比对→把整条流水线自动化，这样上生产后流水线能接住线上实时响应、拿它跟测试集比对，告诉你 AI 相对你定的目标表现如何。→ 详细

• 讲者说评估在各组织里反复出现三个层次，这是搭评估系统时必须做的一个架构决策。→ 详细
• 第一层·确定性（deterministic）：简单又便宜的活儿——校验邮箱/电话格式（就是写代码早就在用的正则表达式那一套），用经典 ML 模型做命名实体识别（NER，从文本里认出人名地名等）、意图分类、PII（个人隐私信息）检测。这些做了好多年了，先把它们清理掉。→ 详细
• 第二层·非确定性 / 语义（semantic）：groundedness 出现在这一层，靠 LLM as a judge（用一个跟主模型分开的、独立的 LLM 去给主模型的回答打分） 来做——你告诉这个裁判模型该按什么标准评判（安全性、groundedness、答案相关性），它还能从评估数据集里取「期望答案」来比对。Databricks 的 MLflow 里就有自动的 LLM as a judge，能让自定义裁判在 trace 上自动跑。→ 详细
• 第三层·行为（behavioral）：关注工具调用（tool call）——agent 调对工具了吗？会不会陷进死循环？这一层最容易被忽略却非常重要（详见下一主题的「三次数据库调用」案例）。→ 详细

• 用户问「我的账户余额是多少？」，确定性层没问题、语义层 agent 也答对了「您的余额是多少多少美元」——表面全对。→ 详细
• 可一进行为层检查就发现：agent 为拿到这个答案往数据库发了三次调用——它不知为何在重复发请求（可能某次失败了就跑去重试）。→ 详细
• 在 demo 环境里三次调用没什么，但生产环境每天成千上万条查询、再叠加这种重复，就是一笔昂贵开销——这正是必须做行为层评估的理由，也是很多团队漏掉的地方。→ 详细

• 这根支柱谈的是 tracing（追踪，把 agent 做出的每一个决策、每一步调用都记录下来，串成一条可回放的链路）。讲者用一个真实零售银行项目的场景来讲。→ 详细
• 场景：用户说「我被收了一笔透支费（overdraft fee），觉得不合理，能帮我免掉吗？」agent 的链路被完整追踪下来——① 意图分类（耗时多少秒、置信度多高）② 调 API 连客户数据库、拿账户明细。→ 详细
• ③ 从 RAG 向量数据库（RAG = 检索增强生成，先去知识库捞相关资料再让模型作答；向量数据库按语义存取这些资料） 检索透支政策文档、判断客户诉求是否合理 → ④ 做推理想清楚怎么回复 → ⑤ 跑最终护栏（guardrail，拦截违规/危险输出的安全检查）→ ⑥ 回复客户。→ 详细
• 讲者坦白这张幻灯片是「简化美化过的」，真实 tracing 数据远没这么漂亮。→ 详细

• 如果没搭可视化 trace 的系统，当客户找上门发起争议时，你根本无从去查 AI 当时做了什么，最后只能说「我也不知道，要不给客户打个折哄高兴算了」。→ 详细
• 这正是监管方基本把它列为强制要求的原因——做不到这种事就根本谈不上生产系统。→ 详细
• trace 还能驱动在线监控（online monitoring）+ 兜底策略：生产中一旦发现重复调用就套 fallback（兜底）策略；某个调用一直失败，就让它「最多重试三次，超过就上报或交人工处理」。→ 详细

• 讲者明确说数据底座在他看来是最重要的一根支柱，典型项目里他 60% 的时间都花在这上面，很多组织也在这儿大量投入——因为「谁也没料到 agent 会突然冒出来、开始直接查数据」。→ 详细
• 金句：「数据一直是为人构建的，而人总是宽容的——你在报告里发现一处数据错了，顶多找个人改一下。可 agent 不会这么宽容你，它会拿着那条错数据、理直气壮地给你一个错误答案，而你根本不知道出了什么岔子。」这就是数据质量、数据战略变得如此重要的原因。→ 详细
• 数据底座分两块：① 问题数据（question data）——真正用来支撑 AI 产出结果的数据（预训练、后训练、通过 API 挂上去取答案的数据）；② 追踪数据（tracking data）——就是可观测性里那些 tracing 数据，但从数据战略角度要在这根支柱里专门处理。→ 详细
• 追踪数据需要一整套独立的数据战略：规划怎么收集、怎么交付给审计/监管方、怎么做在线监控、怎么在 trace 上跑 LLM 裁判，以及怎么设计它的 schema——尤其当组织里跑着成百上千个 agent 时。→ 详细

• Databricks 构建在开源技术之上（Apache Spark、MLflow、Delta Lake），跑在三大云上（Google、AWS、Azure）。最底层是你的云存储（存原始数据）。→ 详细
• Delta Lake 层：在原始数据之上叠加「类似数据库的特性」——哪怕你存的是图片、文本、视频，也能用 manifest 文件构建出类似表（table）的结构，支持增量加载、结构化的数据管理。→ 详细
• Unity Catalog（数据目录）：在 catalog 这一层集中施加权限、开启发现/归属/元数据打标。关键点——当你给表/字段加描述、给 PII 字段打元数据标签后，AI 查询这些表时就能轻松拿到上下文，一切在这一层统一治理。→ 详细
• 上层应用：Mosaic AI（构建/调优 LLM、搭 AI 应用）、数据仓库与 BI 能力、text-to-SQL；Genie（用自然语言写 SQL 查询）；Agent Bricks + MLflow（开箱即用的 LLM as judge + 主动监控）。→ 详细

• 现实约束：企业绝不会只在一个框架里跑 AI——会同时用 CrewAI、LangChain 等各种 agent 框架、用不同的云平台。→ 详细
• 所以你需要一个集中的层来收集这些异构来源的追踪数据，再从这个共享位置服务右侧多类用途：给运维做仪表盘、给一线支持（first line of defense，第一道防线团队）做健康监控仪表盘。→ 详细
• 这些团队既能用 Genie 写 text-to-SQL，也能用编程 agent 搭 Databricks 应用、为不同场景做定制 UI。核心思路一句话：不管 AI 跑在哪里，把数据汇聚到一处、从一个共享位置服务不同团队。→ 详细

• 前提：一个 agent 运转得挺好、不用想编排；可一旦上了五个 agent，复杂度就指数级飙升——多种协同模式、各种通信方式、彼此等待响应，一大堆复杂性涌进来。→ 详细
• ① orchestrator-worker（编排者-工作者）模式：一个 orchestrator 在集中平面上统一编排、掌控所有工作，按各 agent 的专长分发任务；每个请求都经过它，所以你有中心化控制，出问题翻 orchestrator 日志就能查清。→ 详细
• ② choreography（编舞）模式：每个 agent 独立自治、不依赖 orchestrator，全都连到一条消息总线（message bus）、只监听自己关心的事件，可以并行跑。例：一笔房贷申请触发后，一个 agent 看客户信息、另一个看审批信息，并行工作——好处是延迟降低（不用经 orchestrator 来回传消息）。→ 详细
• ③ human in the loop（人在回路）模式：当某个 agent 超过某阈值、或置信度低于某阈值时，工作流就拉一个人进来看 agent 都做了什么、再据此采取行动。→ 详细
• 讲者预告：他为大会线上专场做过一期多 agent 编排深度视频（已在 YouTube），里面讲了状态管理、容错（出故障怎么办）、以及在大型企业里怎么大规模扩展。→ 详细

• 讲者特别澄清：这里完全不是在说数据治理（那是默认就该有的），而是从 AI 角度的合规治理。→ 详细
• 审计轨迹（audit trails）：有没有记录下每一个动作、每一次用户连接、每一个请求、系统里发生的每一件事？有没有对个人信息做前置校验、用命名实体识别拦截？→ 详细
• 硬数据：在那个客户项目里，光是加上这一层（PII 前置校验），他们在测试阶段就检测出 47 起 PII 泄露——这就是为什么它真的很重要。→ 详细

• prompt 版本管理 = 变更管理：在企业级方案里，prompt 改动不能只是「改一下然后 commit 到 Git」，必须像对待代码那样走完整的变更管理流程——本质上「把 prompt 当代码来管」。→ 详细
• 模型变更管理：模型厂商会升级模型，你得有机制判断「升级后的模型对你的场景、你的数据是不是更好」。厂商在三大榜单上放的评测基准，放到你自己的企业语境里没多大用——这时候你自己的评测数据集就派上用场，拿不同模型在上面跑一跑看谁更好。→ 详细
• 风险视角的底层逻辑：不能只押在单一一个模型上，你得有灵活切换到不同模型的余地，还得能在自己的数据上测试它们。→ 详细
• Databricks 把以上所有支柱都做进了 Agent Bricks，目标是把这些操作做成开箱即用，让企业实现生产级 AI 应用变简单。→ 详细

• 客户背景：约一年半（18 个月）前，一家零售银行在做聊天机器人，每月约 2 万次客户咨询，其中约 60% 是简单问题（账户余额、透支怎么处理等），想分流掉、减少对人工坐席的依赖。→ 详细
• 失败的第一版：他们花了约 8.5 万美元（85K）、做了 6 个月的 PoC，结果没成功——讲者团队介入后发现的，正是开头那三个鸿沟：上生产后没人知道东西为什么出错、没人能衡量它为什么不成功、出问题也没人能搞清楚谁该负责。→ 详细
• 重定目标：让 AI agent 处理掉 60% 的（简单）用户问询，并且要有办法把它们识别和追踪出来。→ 详细

• 关键不同点：整个 PoC 是 8 周，模型是第 7 周才选的——把行业惯常的「第一步」推到了倒数第二步。→ 详细
• 第 1-2 周·评估层：采集了 200 个真实案例（看人工坐席怎么回答简单问询），建好数据库；定义成功指标——100 个问询里要有 60 个（60%）由 agent 处理、准确率目标约 85%、外加延迟等所有运维指标；再搭起自动化评测流水线（捕获问答→比对评测集→打分→低于阈值交人工核查→修复后把新用例加回数据集）。→ 详细
• 「评测数据集是活的系统」：从 200 条起步（讲者说这里没什么标准数字），一旦在生产中迭代它就会不断长大，长得越大、系统越好。→ 详细
• 第 2 周·基础层（数据底座）：核对问题数据的 API 连接对不对、有没有机制追踪 API 连接、安不安全（他特意点出「那会儿还没在谈 MCP，就只是直接调数据库 API」）、有没有分布式存储、有没有采集追踪数据——正是搭完这些开始测试时，他们逮住了那些重复 API 调用、搞清了客户满意度为什么下滑。→ 详细

• 第 7-8 周·选模型：因为已经有了评测数据集，就拿不同模型在上面跑、跟期望回答比对、算出准确率数字——这个决策没花多少时间（对照开头「曾花好几周争论用哪个模型」）。然后把可观测性、评估各层全拼起来，等系统能让 AI「可见、可衡量、可问责」，才推上生产。→ 详细
• 上线六周后测的运维指标：准确率、分流率（deflection rate）、响应时间、客户 CSAT（客户满意度评分）。→ 详细
• stale-embedding 事故（招牌细节）：上线几周后，银行改了利率相关政策，并给客户发了邮件 / 手机银行 App 通知；但客户去聊天机器人追问后续问题时得不到正确答案、纷纷点踩，CSAT 下滑。→ 详细
• 追踪系统如何破案：因为衡量系统在位、负面反馈被捕获，他们去看追踪到的决策，发现 agent 引用的是一份已过期的政策文档——新政策文档没更新进向量数据库、embedding（把文本变成一串数字向量、让机器能按语义检索）没有生成进去，所以一直在给过时答案。定位后才修好。「这一切之所以能做到，全靠搭好了那些让我们能检测到问题的系统。」→ 详细

• 讲者会议惯例是分享可带走的资料（结尾有二维码下载），其中他特别想讲的一样是 production incident playbook（生产事故应对手册）——很多人做 AI 项目时容易漏掉。→ 详细
• 手册定义「生产出故障时该按什么流程走」：① 检测（detect）——用评测仪表盘；② 诊断（diagnose）——用 tracing；③ 控制（contain）——靠 prompt 版本管理，某个 prompt 有问题就把它撤下来、做改动、转给人处理。→ 详细
• 容错 / 故障恢复模式（详见他的多 agent 视频）：saga 模式、补偿（compensation）模式、断路器（circuit breaker，下游频繁失败时主动「跳闸」止损）模式。→ 详细
• ④ 修复（fix）——看 LLM as judge 报告、看评测数据集报告，修完把新测试用例放进数据集，组成不断生长的评测套件。手册跑在生产里时要跟 ITSM 系统（IT 服务管理系统，企业现成的告警/工单系统） 打通，好在对的时间提醒对的人、确保下游系统不受影响。→ 详细

• 第一步：从「定义成功」开始，而且是业务意义上的成功、不是技术意义上的——它对业务到底意味着什么。→ 详细
• 第二步：给出几个「好答案长什么样」的例子、做成一个数据集。→ 详细
• 第三步：用简单的 Python 代码搭一条流水线，把它自动化——跑完 AI、拿到回答后，它能自动拿这个答案跟数据集比对，再把答案交付给客户。→ 详细

• 经验一·测试用例库要做治理：它是个会不断变大的系统，所以需要一个负责人，还要给数据集里每一行分类（比如「安全」类目——客户问问题时 agent 没要求登录凭证就归到这里），这样每次回头看才能拎出「改了什么」去对比。→ 详细
• 经验二·prompt 的 commit message 要做治理：大家写 Git commit message 往往随手写得很简单，但改 prompt 时必须记录清楚——这个 prompt 何时被改、为什么改、是什么失败导致它被改、要解决哪类失败、下一版要纠正什么，否则以后回看版本时追不出改动原因，就很难追踪发生了什么。→ 详细
• 经验三·第三层（行为）评测很烧钱，要做成本治理：改一次错误工具调用后要拿它跑整个评测数据集（假设有 300/400/500 行就得一行行全跑），反复测试会花掉一大笔钱。省钱办法：在持续集成（CI）流水线里，做 prompt 改动时只挑评测集的一小部分子集来测，只有合并到主分支时才跑全量测试。→ 详细

• 扫结尾二维码会到一个 Google Drive 链接，里面有这些模板的示例、评测清单该长什么样、以及用开源技术快速搭建 tracing 的指引（让你先在测试环境开测，再决定用什么工具）。→ 详细
• 另一个二维码到他的 LinkedIn 主页；他有一份免费 newsletter，每周分享这类话题，内容就是他在一线跟客户打交道时学到的东西。→ 详细

（本片为单人主题演讲，无独立闪电问答。）

收尾金句 / 一句话带走

• 「数据一直是为人构建的，而人总是宽容的；可 agent 不会宽容你——它会拿着错数据、理直气壮地给你一个错误答案。」（数据底座为何成了企业头号难题的最佳概括）→ 详细
• 「等我们有了这套能让 AI 可见、可衡量、可问责（visible, measurable, and accountable） 的系统，我们才开始把它推上生产。」（整套 playbook 的目的就这一句）→ 详细
• 把行业默认顺序翻过来：先把评估、数据、追踪搭好，最后一步才选模型——「以前花好几周争论用哪个模型，换这套打法后非常快就搞定了。」→ 详细

被点名的产品 / 概念清单（便于检索）

• 框架与方法论：五大支柱（评估 / 可观测性 / 数据底座 / 编排 / 治理）、三层评估（确定性 / 语义 / 行为）、三种编排模式（orchestrator-worker / choreography / human-in-the-loop）、生产事故应对手册（detect→diagnose→contain→fix）、saga / 补偿 / 断路器三种容错模式。→ 详细

• Databricks 技术栈：Apache Spark、MLflow、Delta Lake、Unity Catalog、Mosaic AI、Genie（text-to-SQL）、Agent Bricks。第三方框架点名：CrewAI、LangChain。→ 详细

• 讲者：Sandipan Bhaumik（Sandy），Databricks 数据与 AI 技术负责人；前 AWS 数据与 AI 首席架构师。→ 详细

• LinkedIn 主页：演讲结尾二维码指向其 LinkedIn（具体 URL 未在转写中读出）。→ 详细

• Newsletter：免费，每周分享一线落地企业 AI 的经验（订阅入口同 LinkedIn）。→ 详细

• 资料包：另一个二维码指向 Google Drive，内含模板示例、评测清单、用开源技术搭 tracing 的入门指引（具体 URL 未在转写中读出）。→ 详细

• 视频：https://www.youtube.com/watch?v=ObTPqBGsEbA ；另有一期「多 agent 编排模式」深度视频已在 YouTube（大会线上专场）。→ 详细