标签 上下文工程 下的文章

本文作者:OceanBase 资深技术专家 张易

摘要:
在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

在 AI 与数字化转型驱动的时代,企业正面临数据形态、处理速度与复杂性的剧增。近日,全球知名咨询机构 Forrester 在其最新报告《Multi-Model Data Platforms Landscape, Q4 2025》中指出,多模数据平台(MMDP)已成为应对现代应用复杂数据需求的关键趋势。报告将 MMDP 定义为“在一个数据库管理系统中支持多种数据模型”的统一平台,其核心价值在于简化技术栈、降低数据冗余并加速开发周期。

OceanBase作为“Notable Vendor”出现在该报告中,这不仅是对 OceanBase 多模一体化产品的认可,更预示着化繁为简、现代架构的数据时代即将来临。

在报告中,OceanBase 被认为是聚焦以下扩展用例的代表性厂商:

Agentic AI
Forrester 认为 MMDP 是 Agentic AI 的大脑与记忆。AI Agent 需要推理,它需要知道事实、拥有记忆并理解逻辑关系。MMDP 提供了向量检索(找相似)、图谱(找逻辑)、结构化数据(找事实)的统一平台,防止 AI 幻觉。

多模数据统一检索
Forrester 认为 MMDP 能为开发者提供一键“原子操作”。比如,用户修改资料,既要改结构化数据里的名字,又要改全文搜索里的索引,还要改图数据里的节点,过去这需要写很复杂的分布式事务代码,而 MMDP 允许用统一查询语言在一个步骤内完成跨模态的增删改查,保证数据一致性,极大简化开发。

推荐引擎
Forrester 认为 MMDP 能够提供比“猜你喜欢”更懂你的推荐。传统的推荐只看买了什么,现在的推荐要看用户的实时点击流(行为)、朋友买了什么(关系)、用户搜索的关键词(文本语义),结合了图计算(社交推荐)和多模态搜索(语义推荐),提供更精准的上下文感知推荐。

本文将深度解读 OceanBase 多模一体化能力,探讨其如何以原生一体化的架构,帮助企业架构师与 IT 决策者厘清正在面临的“架构之问”:是继续采用“烟囱式”的数据库组合,还是转向真正的一体化平台?

从“多”到“一”:终结架构碎片化,多模是 AI 时代的必然选择

长期以来,业界普遍采用“为专业场景选择专业工具”的理念,构建了所谓的“多语言持久化”(Polyglot Persistence)架构,即为不同数据模型部署独立的数据库系统。然而,这种模式在业务复杂性指数级增长的今天,其弊端日益凸显,逐渐演变为创新的沉重枷锁。

这种“数据库联邦”模式的困境,在许多积极拥抱 AI 的企业中表现得尤为突出。它们为了实现语义搜索、精确匹配与关系查询,被迫引入由关系数据库、搜索引擎与多种向量数据库构成的复杂技术栈。这不仅导致架构臃肿、运维成本高昂,更在稳定性、数据一致性与开发效率上带来了巨大挑战,形成了沉重的技术债务。

货拉拉在转型过程中的早期探索,便是一个深刻的例证,其面临的动态 Schema 变更、混合检索与多系统运维难题,正是这种碎片化架构的典型缩影。

这些痛点深刻揭示了“烟囱式”架构的本质缺陷——它将数据管理的复杂性转嫁给了应用和运维团队。正如 Forrester 报告所指出的,MMDP 的核心价值正是通过在一个数据库内部实现统一的数据存储、事务处理和治理,从根本上解决数据孤岛问题,降低总拥有成本(TCO)并提升业务敏捷性。


Forrester: MMDPs Enable Simpler Cross-Model Querying

解构 OceanBase:为 AI Agent 打造的混合搜索“大脑”

在 AI Agent 与大语言模型(LLM)引领技术浪潮的今天,数据库的角色正在被重新定义。它不再仅仅是数据的存储仓库,更是决定 AI 应用智能水平与运行成本的“上下文引擎”(Context Engine)。

正如 OceanBase CTO 杨传辉所言,“向量搜索只是 AI 数据库的初级阶段,最终所有向量搜索都会演进为混合搜索——能否支持混合搜索,正是衡量 AI 数据库核心实力的关键分水岭”。


OceanBase 的多模一体化实现混合搜索

OceanBase 的多模能力并非简单的“功能叠加”,而是根植于其原生一体化的分布式架构。这种架构将关系、向量、全文、JSON 等多种数据模型统一在单一引擎下,共享同一套存储、事务和查询优化器。其核心价值主张,正是从 AI Agent 的视角出发,通过强大的混合搜索能力,为大模型提供更高质量、更精准的上下文信息,从而在提升 AI 应用效果的同时,显著降低因 Token 消耗而产生的计算成本。

混合搜索:AI 时代的“上下文工程”基石

AI 应用,尤其是 RAG(检索增强生成)应用,其效果的优劣极大程度上依赖于提供给大模型的上下文质量。大模型虽然具备强大的计算能力,但缺乏长期记忆,这就需要数据库为其存储并管理上下文信息,同时精准输出大模型所需的上下文——这一过程被称为“上下文工程”(Context Engineering)。

一个典型的复杂查询,如“推荐附近 500 米内,人均消费低于 25 元,评价超过 4.5 分,且环境安静的咖啡厅”,单纯的向量或文本搜索都难以胜任。这需要一个能同时理解并处理多种数据维度的“大脑”。

OceanBase 的混合搜索能力,正是为解决这类多维度信息综合检索的难题而生。它将四种关键的搜索能力无缝融合在一个查询引擎中:

这种“多路召回,统一排序”的模式,让 OceanBase 能够先通过关系、标量数据进行高效过滤,大幅缩小检索范围,再在小范围内进行精准的向量或全文搜索。每一路检索都会产出部分结果,最终将各路结果融合,并经过全局重排序(Rerank),才能为大模型输出其真正需要的精准结果。


OceanBase 混合搜索机制

这种机制不仅极大地提升了查询的准确性(Recall)和精确率(Precision),更重要的是,它将最相关、最精炼的信息作为上下文喂给大模型,有效避免了无关信息对模型推理的干扰,并从根本上减少了昂贵的Token消耗,直接降低了AI应用的运行成本。

技术利器一:高性能向量搜索是混合搜索的基础

高性能且功能完备的向量搜索,是混合搜索的核心基础。目前,OceanBase 向量搜索性能已达到业界开源向量数据库的先进水平——无论是稠密向量还是稀疏向量,在向量数据库领域主流 Benchmark 测试中均表现突出。

在 VectorDBBench 的测试中,OceanBase 在不同过滤率下的性能全面占优。同时,OceanBase 的磁盘向量索引,在构建时间与存储占用两方面,也实现了业界领先。


OceanBase 向量性能测评

更重要的是,OceanBase 实现了向量搜索与全文搜索的深度融合,通过多路搜索显著提升召回效果。测试数据清晰呈现了不同搜索方式的召回表现:仅采用单一搜索路径(无论全文搜索、稠密向量还是稀疏向量),都难以达到最优召回效果;唯有将稀疏向量、稠密向量与全文搜索相结合,才能实现更优的召回表现,达成 1+1 > 2的协同效应。


OceanBase 多路召回评测

值得一提的是,这两大能力均构建于 OceanBase 数据库原生架构之上,天然继承了分布式架构的弹性扩展特性与对象存储的高效适配能力。

技术利器二:半结构化数据的高效处理(JSON)

在 AI 场景中,企业在处理海量 JSON 数据(如用户行为日志、订单轨迹、动态特征字段)时,普遍面临 Schema 重复存储导致空间浪费、按行存储导致压缩率低、查询性能低下等痛点。

OceanBase 针对性地设计了创新的存储方案。它采用 JSON 二进制存储,并创造性地实现了“列化拆分”。通过智能识别“高频列(Frequent Col)”与“稀疏列(Spare Col)”,将频繁访问的字段独立成列存储,稀疏字段则聚合存储。


OceanBase JSON 列化拆分机制

这种设计带来了显著的技术收益。首先是极致的压缩效率,拆分后的独立列可利用 OceanBase 成熟的列存编码能力进行高效压缩。在 TPCH-10G 数据集上的测试显示,其压缩比是传统文档数据库的 3 倍,直接降低了存储成本。

其次是查询性能的加速,查询特定字段时,只需读取对应列,极大减少了 I/O 开销。此外,用 JSON 格式动态扩展特征字段,还可帮助企业减少 30%-50% 的数据清洗成本。这一能力对于 AI 应用中频繁变化的特征工程尤为重要,使得企业无需频繁修改 Schema 即可灵活应对业务需求。

技术利器三:HTAP 能力支撑 AI 场景的元数据管理

在 AI 场景中,除了要开展多路搜索,还需妥善管理 AI 场景下的元数据。要做好 AI 数据库的元数据管理,不仅需要支持元数据的实时写入与事务一致性,还需实现元数据检索结果与多路搜索结果的 SQL 级联动。

在这方面,支持 HTAP 的关系型数据库是更优选择。通过将关系模型与向量、全文、JSON 能力深度融合,OceanBase 最终形成了全面的混合搜索能力。


OceanBase 如何解决 AI 场景元数据管理问题

例如,在知识库场景中,需要管理用户权限、文档分类、访问日志等大量元数据,同时还要进行文档的语义检索。传统方案需要在应用层协调关系数据库与向量数据库的查询结果,而 OceanBase 则可以通过一条 SQL 完成“先通过关系过滤确定用户可访问的文档范围,再在该范围内进行向量语义搜索”的复杂操作,极大地简化了开发逻辑并提升了查询效率。

一体化架构:从“数据库联邦”到“统一数据底座”

过去,企业为了实现类似的多模态处理能力,不得不拼凑一个由关系数据库、向量数据库、全文搜索引擎等多种产品组成的“数据库联邦”。这种“烟囱式”架构不仅运维复杂、成本高昂,更在数据一致性、开发效率和系统稳定性上带来了巨大挑战。

OceanBase 的一体化架构则试图改变这一局面,为企业 AI 应用提供坚实的统一数据底座。多个客户的成功实践,生动地诠释了这一价值。

蚂蚁集团“百宝箱”的智能体在线搜索就是一个典型案例。其复杂的地理位置、用户评分、消费水平和语义偏好混合查询需求,在 OceanBase 中通过一条 SQL 即可实现,完美替代了原先 Milvus + Zsearch + OceanBase 的复杂组合。这种将多路检索逻辑从业务层下沉到数据库内核的做法,极大地简化了业务实现,实现了在线高性能混合搜索。


蚂蚁集团百宝箱 Agent 在线搜索示例

货拉拉则基于 OceanBase 的混合搜索能力,构建了一站式的企业 AI 数据底座,支撑起包括知识库平台、AI Coding、Agent 平台、ChatBI、智能客服等多种 AI 应用。这不仅用单一技术栈取代了原有的 vsearch + Weaviate + Milvus 等多个开源组件,解决了系统的稳定性难题,还复用了 OceanBase 成熟的高可用能力,实现了 RPO=0、RTO<8 秒的金融级标准。

在具体应用中,货拉拉通过“资损代码识别”场景,利用历史案例向量化与实时代码相似度检索,有效规避了潜在的财务风险;在“数仓AI答疑助手”项目中,更是融合了向量、标量、全文关键字等多种检索方案,并结合重排序模型,显著降低了内部数据查询门槛和人力成本,提升了数据开发人员的效率。


货拉拉 AI 应用架构

中国联通利用 OceanBase 构建了拥有 10 亿级向量规模的公司级统一知识库平台。原先采用“关系数据库+Elasticsearch”的架构,在切换到 OceanBase 后,查询执行效率提升到原 Elasticsearch 方案的 2 倍,同时解决了复杂的用户-文档权限管理问题。通过融合关系查找与多路搜索,联通成功实现了知识库的精细化权限管控及灵活的用户间权限共享需求,支持公共文档与私有文档的统一管理。


中国联通 AI 应用架构图

飞猪也通过 OceanBase 统一了其智能体数据平台的后端,用一套系统替代了原先的分布式 KV + 分布式 Table + 搜索 + 向量的复杂架构。这不仅统一了技术栈,还实现了对知识库、Memory 等多种数据的统一支持,SQL 的简单易用性与稳定低延迟的特性,让开发团队能够更专注于业务创新。


飞猪 AI Agent 架构

这些案例共同证明,OceanBase 的一体化架构并非简单的功能聚合,而是通过在内核层面实现多模数据的统一管理与查询,从根本上解决了数据孤岛问题,降低了技术栈的复杂性,最终加速了AI应用的创新与落地。

从技术到业务:OceanBase 多模一体化的实践价值

技术的先进性最终需要通过业务价值来体现。从上述案例中,我们可以清晰地看到 OceanBase 多模一体化架构在 AI 时代所带来的三大核心价值:

第一,显著降低 AI 应用的运行成本。 通过混合搜索提供的精准过滤与排序机制,OceanBase 能够为大模型提供更高质量、更相关的上下文信息,从而大幅减少无效 Token 的消耗。在当前大模型推理成本居高不下的背景下,这种成本优化对企业而言具有直接的经济价值。

第二,简化技术栈,提升开发与运维效率。 一体化架构让企业无需在应用层协调多个异构数据库系统,开发者可以用熟悉的 SQL 语言完成复杂的多模查询,极大地降低了学习成本与开发复杂度。同时,统一的运维管理也减轻了 DBA 团队的负担,提升了系统的整体稳定性。

第三,加速 AI 应用的创新周期。 当数据基础设施变得简单、高效且可靠时,业务团队可以将更多精力投入到 AI 应用本身的创新上,而非陷入复杂的数据管道搭建与维护中。这种“基础设施即服务”的理念,正是 OceanBase 一体化架构的核心价值所在。

选择下一代数据基石,拥抱智能未来

Forrester 的报告揭示了多模一体化不仅是技术趋势,更是企业在 AI 时代保持竞争力的战略选择。面对日益复杂的数据环境,传统“烟囱式”的架构已难以为继。

OceanBase 提供的不仅是一个功能丰富的数据库,更是一个稳定、高效、面向未来的一体化数据基石。它通过在存储、查询、事务等层面的原生一体化设计,让企业能够更从容地应对数据融合的挑战,将宝贵的精力聚焦于业务创新本身。

特别是在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

对于正在寻求下一代数据架构的架构师和 IT 掌舵者而言,可以重新审视自身的技术栈,考虑 Forrester 倡导的多模数据处理平台,为企业的下一个十年发展奠定坚实基础。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

Andrej Karpathy:过去一年大模型的六个关键转折

本文共 2836 字,阅读预计需要 4 分钟。

一边是模型光靠"多想一会儿"就能解出奥数题,另一边是刷爆排行榜的选手被用户吐槽"中看不中用"。

2025年的AI圈,弥漫着一股诡异的气息:

参数规模不再是唯一的军备竞赛指标,但模型能力却在某些维度上狂飙突进。

这到底发生了什么?

Andrej Karpathy——前OpenAI研究总监、曾掌舵特斯拉AI团队的技术大牛——在年终复盘中抛出了一个判断:

2025年LLM的真正突破,不在于模型变大,而在于我们"驯养"它的方式、理解它的视角、以及使用它的姿势,都发生了根本性的变化。

这篇文章,我会带你拆解Karpathy眼中的六个范式转变,聊聊它们对普通人意味着什么,以及有哪些坑是你现在就该绕开的。

一、RLVR:训练范式的静默换代

2024年之前,大模型训练三板斧:预训练、监督微调、RLHF。但RLHF的瓶颈很明显——依赖人工标注,成本高、速度慢

2025年,RLVR(基于可验证奖励的强化学习)开始上位。核心逻辑很简单:用有标准答案的任务来训练。数学题对不对?代码能不能跑?机器自己就能验证。

打个比方:RLHF像请老师批改作文,标准不一;RLVR像做数学卷子,对就是对、错就是错。

RLVR还解锁了一个调节旋钮:让模型"多想一会儿"

生成更长的推理链,就能换来更强能力。OpenAI的o1到o3,DeepSeek的R1,都是这条路线的产物。

以前比谁模型参数多,现在比谁的强化学习跑得久。

二、召唤幽灵,而非驯养动物

Karpathy用了一个隐喻:我们不是在"培育动物",而是在"召唤幽灵"

动物智能是进化塑造的,能力配合天衣无缝。

但LLM的"大脑"是为了预测下一个词、在数学题里拿分——这些目标和生存没关系

结果就是"锯齿状智能":某些任务碾压专家,另一些任务犯低级错误。

它能写出逻辑严密的报告,但是转头就被越狱提示词骗了。

实际后果是:别迷信基准测试。 LLM团队为了刷榜,围绕测试题大量生成训练数据,榜单漂亮,实际用起来翻车。

幽灵的能力是尖刺的、不可预测的。用的时候,得时刻警惕。

三、Cursor与新应用层:上下文工程的价值爆发

2025年,Cursor没有自己训练模型,但估值从4亿飙到99亿美元。它做对了什么?

答案是上下文工程——在调用大模型时,精心设计给它的信息环境:提示词怎么写、代码库怎么索引、多次调用怎么编排。

Karpathy的观点是:LLM实验室培养"通才大学生",应用层把他们培养成"垂直专家"。桥梁就是上下文工程。

直接问ChatGPT和用Cursor写代码,体验天差地别。Cursor自动索引代码仓库,理解文件依赖,提问时自动塞入相关上下文。这不是模型能力差距,是信息组织方式的差距

启示很清晰:模型会迭代,但上下文工程能力可以沉淀,能无缝迁移到下一代模型。

这也是我一直以来坚持上下文工程优先的原因。

四、Claude Code:AI从"网站"变成"室友"

Claude Code是Anthropic推出的命令行工具,特别之处在于:直接运行在本地电脑上,访问你的文件、配置、密钥。后续Copilot等工具也相继推出了这样的开发模式。

Karpathy说:它不再是需要打开浏览器的网站,而是"寄居"在电脑里的小精灵

本地运行的好处:AI直接读取电脑上的上下文——装了哪些软件、项目代码长什么样,不需要手动复制粘贴。

更重要的是延迟和隐私——云端来回几百毫秒,敏感数据发到第三方合规部门不同意。

当然也有隐患:一个能操作本地文件的AI,权限边界怎么划定?

五、Vibe Coding:代码正在变得廉价

Karpathy造了个词叫"Vibe Coding"——氛围编程。

用自然语言描述需求,AI帮你写代码,你甚至不需要"懂"代码

2025年这事跨过了临界点。之前AI写代码问题多,需要人debug。现在很多简单项目,从想法到可运行程序,一气呵成。

Karpathy自己用它写了Rust版tokenizer(不需要学Rust)、做了好几个小应用原型、甚至写过临时应用定位bug——用完就扔。

他的原话是:代码变得廉价、短暂、可塑、用完即弃。

对普通人意味着什么?"我有想法但不会代码"这个门槛,正在消失。

六、Nano Banana:LLM的GUI时代前奏

Google的Gemini Nano Banana让Karpathy特别兴奋。

核心不是图像生成能力,而是文本、图像与世界知识在模型权重中的深度融合

现在"跟LLM对话"像1980年代敲命令。文本是机器原生语言,但人更喜欢视觉化呈现——这正是GUI被发明的原因。

LLM也需要自己的GUI——用图片、信息图、动画跟我们沟通。Nano Banana就是这个方向的早期预演。

写在最后:可立即落地的三个建议

拉回来说说,这六个范式转变对你意味着什么。

如果你是创业者,最重要的启示是:模型能力会继续涨,但涨的方式变了。与其追着模型跑,不如在上下文工程上建立壁垒。Cursor的成功已经证明了这条路。

如果你是开发者,Vibe Coding值得你认真对待。不是说它会取代你,而是说它能让你的生产力翻倍。把重复性的代码工作交给AI,把精力放在架构设计和业务逻辑上。

如果你是普通用户,最重要的是调整预期。AI既不是全能的神,也不是彻底的废物——它是一个能力极度不均匀的"幽灵"。用好它的尖刺能力,同时对它的盲区保持警惕。

三个行动建议,作为结束:

投资上下文工程能力。学会设计提示词、组织RAG检索、编排多步调用,这是当下性价比最高的AI技能。

用Vibe Coding降低创意落地门槛。你脑子里的想法,别再等"等我学会编程再说",现在就可以试着让AI帮你实现。

理解锯齿状智能,设置人工校验。在享受AI效率提升的同时,别忘了在关键环节保留人工把关。

2025年是LLM的分水岭。规则变了,玩法也得跟着变。

2026年,又会有什么新的成果出现呢?评论区聊聊你的看法

既然看到这了,如果觉得不错,随手点个赞、收藏、转发三连吧~

我是Carl,大厂研发裸辞的AI创业者,只讲能落地的AI干货。

关注我,更多AI趋势与实战,我们下期再见!

数据来源

Karpathy 2025年终复盘原文 [数据|2025|https://karpathy.bearblog.dev/year-in-review-2025/]

RLVR训练范式说明:基于可验证奖励的强化学习 [数据|2025|Karpathy原文]

DeepSeek R1推理能力展示 [数据|2025|DeepSeek R1论文]

Cursor估值变化:$400M(2024.8) → $9.9B(2025.6) [数据|2024-2025|https://techcrunch.com/tag/cursor/]

OpenAI o1/o3推理模型发布 [数据|2024-2025|OpenAI官方]

Claude Code产品发布与功能说明 [数据|2025|Anthropic官方]

Vibe Coding概念由Karpathy在Twitter提出 [数据|2025|https://x.com/karpathy/status/1886192184808149383]

Google Gemini Nano Banana多模态融合能力 [数据|2025|Google官方]

以下内容来源于DataforAI社区,作者Data for AI

当 AI 遇见数据:一场面向工程实践的技术交流

大模型并没有直接带来 AI 应用的成熟。真正决定 AI 能否规模化落地的,正在从模型本身,转移到数据、上下文与基础设施

与此同时,数据基础设施也正经历一轮深刻演进:从传统的数据湖仓,到多模态数据管理;从 SQL 查询引擎,到面向 AI 的数据解析与治理能力。这些变化,正在重新定义我们构建 AI 应用的方式。

1 月 24 日(周六)下午Data for AI 社区 将携手 ALC Beijing (Apache Local Community Beijing) 举办 Data for AI Meetup Beijing,邀请来自产业、开源社区与学术界的一线实践者,围绕 AI 时代的数据基础设施演进 展开深入交流。

本次 Meetup 汇聚了来自 字节跳动火山引擎 / Daft 社区、OceanBase社区、北京大学、Datastrato / Apache Gravitino 社区、Zilliz / Milvus 社区的技术专家,深度剖析 AI 时代数据基础设施的技术演进路径。

📍 本次 Meetup 核心看点

  • 多模态数据处理引擎实践:

    Daft 在 AI 数据预处理与训练加载中的工程经验

  • AI 原生元数据平台:

    Apache Gravitino 1.1.0 的关键能力与治理实践

  • Agent 数据基座设计:

    记忆、检索与数据统一的工程解法

  • Data-centric AI 方法论:

    面向大模型的数据准备与质量体系

  • 混合检索实践:

    向量 + 全文检索在真实业务中的优化路径

  • 开源探索:

    Skill 驱动的上下文工程平台化可能性

  • 圆桌讨论:

    下一代面向 AI 应用的数据基础设施如何设计与落地


多模态数据处理的新范式

AI 训练对数据处理提出了全新挑战。火山引擎 AI 数据湖服务架构师 琚克俭 将分享 Daft 在多模态数据处理上的工程实践,聚焦图像、视频、文本等异构数据在统一处理、预处理与训练加载阶段的性能与架构挑战。

这一分享直面当前 AI 工程的核心痛点:传统数据引擎已难以支撑多模态 AI 工作负载,而 Daft 通过全新的架构设计,在数据预处理和训练加载环节实现了显著的性能提升。

元数据治理进入 AI 原生时代

Datastrato VP of Engineering 史少锋 将深度解析 Apache Gravitino 1.1.0 的核心升级,包括 Lance REST 支持、Generic Lakehouse Catalog、Iceberg 安全增强等关键特性。

当 AI 团队需要在多个集群间管理训练数据、推理数据和模型元数据时,传统的元数据工具往往各自为政。Apache Gravitino 1.1.0 通过统一的元数据治理架构,让跨引擎、跨存储的数据协同变得标准化、可管理,大幅降低 AI 工程中的数据协同成本。

上下文工程:Agent 落地的数据基座

OceanBase 技术专家 汤庆 将深度解析当下最热的「上下文工程」话题。他指出,企业级 Agent 面临三大核心挑战:如何让 Agent 拥有可靠的「记忆」(记忆管理)、如何让 Agent「理解」复杂文档(知识检索),以及如何统一处理向量、文本、结构化数据(数据统一)。

这三款 AI 产品的协同设计给出了答案:PowerMem 基于艾宾浩斯遗忘曲线构建智能记忆系统并支持多智能体隔离,PowerRAG 提供多引擎 OCR 与向量 + 全文的混合检索能力,seekdb 则作为 AI 原生数据库统一管理多模态数据并兼容 MySQL 生态。这套方案的核心价值在于:用数据架构的确定性,对抗 Agent 行为的不确定性。

面向大模型时代的 Data-centric AI 基础设施

北京大学助理教授 张文涛 将从学术与工程结合的视角,系统阐述 AI 从「模型为中心」到「数据为中心」的范式转变。当大模型能力趋同,数据质量正在成为决定模型性能的关键变量。

张文涛团队主导开发的 DataFlow 数据准备系统已在大模型预训练、企业知识库构建等场景得到验证。本次分享将深入解析 LLM 数据工程的完整流程:如何获取数据(爬取、解析、合成、标注),如何处理数据(过滤、改写、配比),以及如何评估数据质量。这套开源工具链与方法论,正在为 AI 开发者降低数据工程的门槛。

从向量检索到混合查询:Context Engineering 实践

Zilliz 资深解决方案架构师 刘汉卿 将系统回顾从 Prompt Engineering 到 Context Engineering 的演进路径。随着 RAG 技术从单一向量检索发展到 GraphRAG 与全文检索的混合查询阶段,检索系统已经从「找到相似内容」进化到「理解查询意图并精准召回」。

在这个演进过程中,一个关键趋势是:用向量计算代替多轮LLM推理,通过检索层的优化来提升 AI 应用的性能与稳定性。刘汉卿将结合企业知识库、推荐系统、智能助理等场景,分享混合查询的工作流搭建经验,以及在金融、医疗、法律、教育等行业的实际落地案例。

上下文工程的平台化探索

独立开源开发者 袁怿(Sam Yuan)将从前瞻视角探讨 2026 年上下文工程的技术趋势。如果说 2025 是 Agent 元年,那么随着上下文工程的快速演进,一个关键问题正在浮现:上下文能力是否应该从「各自实现」走向「横向平台化」?

袁怿将上下文工程拆解为三个维度:工具调用(空间维度)、RAG(信息密度维度)与 Memory(时间维度)。他将以最近进入 AAIF 的 Skill 机制为切入点,对比 Skill 与传统 Function Call 的本质差异,并结合他在开源社区贡献的 StructuredContextLanguage 项目,展示以渐进式加载为代表的平台化思路——让 AgentOS 像操作系统管理进程一样,统一管理上下文资源。


圆桌论坛:下一代面向 AI 应用的 Data Infra 的设计和落地

从多模态数据处理到 AI 原生元数据平台,从上下文工程到混合检索系统——本次 Meetup 的所有分享指向同一个命题:在 Agent 时代,数据不再只是「被调用的资源」,而正在成为被理解、被约束、被治理的核心能力。

越来越多团队在实践中遇到相似挑战:Agent 需要访问的数据分散在不同系统中,权限、语义与上下文边界不清;模型可以生成「看似合理」的请求,却难以保证结果的安全性与一致性。这些问题往往无法通过 Prompt 或单点优化解决。

我们特邀到前 Apple 数据与机器学习平台负责人 谭涛(Kwaai AI Lab 顾问)、Datastrato 创始人 CEO 堵俊平、北京大学助理教授 张文涛 三位圆桌嘉宾,围绕三个核心问题展开讨论:

  • 意图与执行解耦:如何让 Agent 的数据请求既灵活又可控?
  • 访问规则原生化:能否在系统层面保证数据访问的安全性与一致性?
  • 上下文边界管理:如何让 Agent Builder 在不理解底层架构的前提下获取「该拿的数据」?

这些讨论并不立马给出最终答案,而是帮助我们勾勒下一代面向 AI 应用的数据基础设施轮廓——一个更开放、更可治理、也更适合 Agent 时代的技术底座。

活动信息

时间

2026 年 1 月 24 日(周六)13:10 – 18:00

地点

北京 · 原点学堂(东升大厦 A 座 10 层)(不提供线上直播)

立即报名:

👉 访问链接:https://www.huodongxing.com/event/3843480320400

⚠ 名额有限,需审核通过(请详实填写报名信息,并通过主理人的微信添加请求,确认审核状态)

这是一场面向 AI & Data 工程实践者的技术深度交流。

无论你是正在构建企业级 Agent 系统的架构师,

还是关注 Data-centric AI 的研发工程师,

都能在这里找到有价值的技术洞察和落地经验。

Community Over Code,期待与你在北京相聚。

阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么