数据不再只是后台：OceanBase 与年轻开发者讨论企业 AI
AI 产品 编程 Agent 工程师 访谈 技术 战略
一场围绕数据库竞赛的对谈，最后落在企业 AI 最难处理的部分：模型能力已经可以调用，企业自己的数据该怎样交给它使用？OceanBase CTO 日昭把这件事放在公共数据与私有数据的差别中解释。通用模型的预训练和许多通用应用，主要建立在公共数据上；企业真正关心的订单、客户、流程和内部资料，却不会自动出现在这套模型知识里。
因此，企业把模型带进核心业务，并不是把一个聊天界面接到系统上就结束。日昭认为，企业要先管好自己的数据，再让模型在需要时取得相关上下文，最后才能把能力接入业务流程。聊天、编程、图像和视频生成等通用场景已经较容易落地；企业核心流程仍在早期阶段。评估模型表现的标准、构建应用的方式和可复用的行业方案，都还没有定型。
从结构化数据到更宽的数据范围
日昭并不把数据在 AI 时代的重要性理解为突然出现的新现象。他认为，优秀互联网和科技公司一直把数据放在核心位置。变化在于，大语言模型让过去较难直接利用的内容进入统一的处理范围：除结构化数据之外，文本、图像、音频、视频等半结构化或非结构化数据，也能被放进同一个工作流。
这给数据库提出了两层要求。一层是数据库本身要能处理更多数据形态，给用户保留控制和管理能力；另一层是数据库要与模型结合，用模型擅长的能力简化处理。主持人把语言、多模态和编程看作几张不同的技术桌，日昭从用户视角回应：用户只关心能不能完成任务，底层可以有不同技术路线，但终究需要一种更通用的使用方式。
企业侧的困难也由此变得具体。日昭说，过去 IT 系统能大规模使用数据库，是因为数据库已经有标准化的语言、构建方式和解决方案。企业现在想用大模型，却常常不知道怎样才算做对：场景不同，评价方法不同，实施没有现成模板。他期待数据和模型的组合经过更多部署后，逐渐沉淀为行业方案和标准。这是他对发展路径的判断，不是已经形成的行业事实。
混合检索把答案拉回资料本身
OceanBase 的数据库比赛提供了一个缩小版的工程现场。日昭介绍，去年的题目偏向向量数据库，主要借助 embedding 和 RAG 补充模型上下文；今年则改为混合检索。他将这种转向归入上下文工程：向量相似度只是一个入口，全文、图和标量、半结构化数据的索引与搜索方式也可能一起参与，关键在于怎样把数据能力和模型能力组合起来。
参赛学生的做法让这个抽象概念更容易理解。一支队伍会先改写用户问题，让语义和意图更清楚，再对混合检索的结果重排序，希望模型拿到更相关的上下文。另一支队伍碰到的难题更接近企业风险：模型给出的回答看起来正确，引用的文档和页码却持续变化。答案说对了，却无法说明依据在哪里，仍可能只是猜中。
这支队伍于是先给候选文档排序，再在文档内部定位更可能包含答案的页码。这个过程不能无限叠加步骤，因为检索性能同样是比赛指标。两队分享的并不是同一套完整方案，却共同说明了一件事：RAG 的问题不只在于找到相关文本，也在于让使用者能检查模型究竟根据哪份资料作答。
检索与生成的边界：嘉宾把 AI 场景中的数据库任务描述为搜索问题。搜索结果带有非精确性，方法也尚未定型；文档、页码等来源定位为模型输出增加了一层可检查的依据。
日昭因此看到数据库角色的变化。它依然服务交易和分析，也要开始处理模型所需的上下文。在传统数据库领域，许多理论与实现已经成熟；在数据和模型结合的早期，参赛选手可能提出评委没有想到的方案。比赛依然考察数据库内核能力，只是题目把 AI 业务场景带进了优化对象。
AI 编程加速实现，审查仍是开发的一部分
对两位学生而言，AI 已经不是只在聊天框里提问的工具。一位曾更相信手写代码，因为这样更容易把握实现；在团队协作和决赛中，他看到队友先用模型分析代码，再快速生成部分功能，自己还在梳理前因后果时，对方已经提交了一半实现。这次经验促使他开始学习怎样把需求讲清楚、怎样配合工具工作。
另一位学生更早使用 AI，感受到近一年变化最大的地方是编程工具可以读取更完整的代码库上下文。开发者不必再把一个个代码片段摘出来贴进对话框，读源码和实现功能都更顺手。已经在银行工作的学生也提到，内部开始使用 AI 编程后，原先偏后端的工作会接触 Java、C++ 和 React 等更多技术，描述好需求、让程序跑起来，就能更快完成跨领域的功能。
日昭的看法更接近团队管理的角度。OceanBase 已大量采用 AI 编程，前端、实验性代码和部分中间件的效率提升很明显；要求特别严谨的代码仍可能埋有问题，不能跳过人工 review。接下来的变化不只是开发者会不会用工具，还包括开发、测试和产品怎样重新协作。
工具带来的速度
读取代码库上下文、生成实现和快速试验，可以缩短许多重复性的工作。
人保留的判断
需求是否清楚、逻辑能否解释、错误怎样修复、代码是否应合并，仍需要开发者负责。
这也解释了节目对基础能力的反复强调。学生说，AI 修改代码后仍要逐段看清执行流程，简单错误可以由人先修好再继续让模型改。日昭认为，数据库理论、基础编程和把需求描述清楚的能力没有过时；研发人员还要对新工具、新数据形式保持开放。AI 可以改变完成任务的方式，但不能替代对结果的校验。
安全问题也随着接口扩大
学习网络安全的学生把自己的观察放在另一个方向：学校接触到的新研究包括大模型安全、语音模态和其他多模态安全，范围很宽，也还在快速发展。她没有把它归结为一两个已经固定的问题。
主持人则把这种扩展放回企业系统。数据库、网络和交易系统原本有较清楚的边界；当通用模型能力开始与它们交互，模型本身的输出风险会与业务系统的安全要求相遇。节目没有为此给出一套解决方案。主持人提出的工程担忧是，模型接入得越深，安全审查的对象也会延伸到模型与业务系统之间。
持续学习：模型更新与外部上下文是两回事
节目随后谈到 Continual learning。这个词在讨论中很热，但日昭先把它拆成两种机制：一种是让模型本身持续吸收新信息，另一种是让模型与数据库结合，通过上下文工程使用不断更新的数据。两者都可能让模型面对变化后的信息，但并不是同一件事。
他对第一种机制保持谨慎。以多次微调为例，模型反复更新后会得到什么结果，往往难以预测，还需要人检查。节目没有断言这条路线一定走不通，只说目前尚未看到足够明确的突破。日昭更愿意先研究第二种方式：数据库可以实时读写，把新数据保留下来，在任务发生时提供给模型。混合检索也是这条实用路线的一部分。
这个选择的含义很朴素。企业不必等到模型自动、稳定地把所有新知识写进参数，才能处理变化的数据；但外部上下文的管理、检索、权限和更新机制本身也要做对。日昭称这套数据库加模型的组合仍是前沿探索，并没有表示业界已经把它完全解决。
从内部项目到开源生态，再到企业 Agent
OceanBase 的经历给这条路线补上了产品和生态的一面。日昭说，OceanBase 从 2010 年开始是蚂蚁内部项目，后来公司化，再在第二年对外开源。代码公开前，团队要剥离内部依赖、处理代码质量、补齐文档；内部可以运行的系统，要成为外部开发者能够使用和协作的项目，还要跨过这些工程环节。
他把开源的价值放在持续创新和生态协作上，而不只是发布一份代码。团队最初就按通用数据库的方向设计产品，开源后也希望更多人用这些工具探索数据和模型结合的方式。节目没有把开源自动等同于商业成功；它讨论的是，当 AI 要和既有技术栈、企业系统结合时，开源社区与产业实践开始更紧密地互相影响。
同一层区别也出现在 Agent 上。日昭认为，通用 Agent 受益于通用能力，产品变化可能很快；把 Agent 放进企业的业务流程，节奏则不同。它要接入私有数据、权限、模型和基础设施，还要把一次次实施沉淀为解决方案。他预计搜索、风控和客服等场景正接近更大规模采用的前期，金融、医疗等拥有高价值私有数据的行业可能更早出现需求。这是嘉宾对 2026 年的预测，节目没有给出采用率或时间表。
讨论到最后，问题又回到数据库竞赛中那条小小的检索链路：模型能否在正确时间取得正确资料，使用者能否知道答案来自哪里，系统是否能随着资料和流程变化继续工作。对这期节目的几位嘉宾而言，数据不再只负责留存在后台；它要成为模型进入企业时可管理、可检索、可核验的一部分。