在万众期待之下，OceanBase 城市交流会北京站携手社区嘉年华盛大启幕。此次盛会汇聚了超过170余位技术爱好者、开发者及业界顶尖专家，共同编织了一场技术与创新交相辉映的庆典，标志着OceanBase 社区年度中最盛大、气氛最热烈的聚会。
本次活动波及范围广泛，影响力深远。与会者中，不乏来自科技前沿企业的精英、初创团队中富有创新激情的成员，以及深耕于高校与科研机构、致力于学术研究的学者们。尽管他们来自五湖四海，拥有不同的背景，但都怀揣着对技术的无限热爱，跨越重重阻碍，从四面八方汇聚于此。
活动现场气氛热烈非凡，还未开场，签到区便排起了长队。参与者们不仅可以现场签到参与幸运抽奖，赢取丰富奖品，还有机会亲手 DIY 专属红包，拍照留念成为 “2025 年最靓的仔”，提前感受了浓厚的春节氛围。
本次嘉年华内容丰富、创新与亮点十足。特邀主持人奇富科技数据库负责人贾建龙，以其专业视角与丰富经验，为活动的顺利开展起到了重要推动作用。“Ask me anything” 环节首次采用小组讨论模式，为参会者搭建了与数据库领域的专家大咖面对面深入交流的平台。来自 360、作业帮、BOSS 直聘、好未来等企业的技术大咖与现场观众围绕业务需求和技术挑战展开热烈探讨，大家在思维的碰撞中，技术难题迎刃而解，在技术上更加自信，在业务上也更加游刃有余。
此外，活动还邀请了 OceanBase、TuGraph、智源、Dify.AI 等多领域的技术专家，共同探讨了 OceanBase、RAG、TuGraph、LLM 等前沿技术的落地应用。从助力企业商业化发展，到拓展应用场景；从多云环境下的高可用，到与大模型结合、应用于文档智能和知识图谱，全方位的技术分享让参会者们收获满满。
没能参与现场的精彩活动？没关系，我们还有线上活动～
💃 参与方式：
只需社区专属活动帖子下方分享本次活动中你印象最深刻的金句（金句可以来自嘉宾分享内容，也可以是你的个人提炼），只要足够精彩就有机会获得精美礼品+丰富积分哦～
社区线上活动帖子链接：
https://ask.oceanbase.com/t/topic/35617704
活动截止时间：2025 年 1 月 22 日
我们将在帖子中随机抽取 3 位参与活动的幸运儿送出实物奖品，其余所有参与者都将获得 50 积分&成长值作为奖励。快来参加吧~🙋♀️🙋♂️
具体各位嘉宾讲解了哪些内容？一起来看精华汇总～～～
一、OceanBase 开源社区嘉年华共赴技术新征程，开启开源新未来
OceanBase 开源生态技术部总经理封仲淹，开场便向周末参会的社区成员致谢。此次嘉年华意义非凡，汇聚了志同道合的成员，为大家提供深度交流、增进合作的平台。
封仲淹特别强调，360 及众多热心人士为活动成功举办全力付出。从场地筛选、PPT 筹备到活动策划，各个环节都饱含大家的心血。此外，一些社区成员和外部合作方在答疑机器人开发测试等方面都有贡献卓越，有力推动了社区技术支持的完善。
在活动中，关于开源社区和数据库市场趋势的分享引发了热烈的讨论。OceanBase 开源社区自成立之初，便提出了 “开源开放，生态共赢” 的理念，这不仅是一句口号，更是贯穿社区发展始终的核心方针。秉持着这一理念，OceanBase 开源社区始终致力于与广大用户紧密合作，携手共进。在这个过程中，社区为用户提供了强大的技术支持和丰富的资源，而用户的反馈与建议也不断推动着 OceanBase 产品的优化与创新，真正实现了双赢的局面。
近年来，国内数据库市场竞争激烈，资源向头部集中。但 OceanBase 开源社区逆势上扬，去年年初社区版安装集群数仅 5000 套，年底激增至 3.3 万套。在国家政策推动，市场分化的背景下，OceanBase 凭借实力站稳脚跟，未来有望借助技术创新和生态完善，拓展更大发展空间。
随着科技进步，Data+AI 成为行业的新风口。Open AI 收购 Rocketset、Oracle 推出 23ai 版本，都凸显了 AI 与数据库融合的趋势。Databricks 提出口号 “AI Infra”并获百亿美金融资，彰显该领域潜力巨大；OceanBase 开源社区紧跟趋势，未来将加大向量化投入，探索上层 AI 发展路径。
OceanBase 开源社区嘉年华是回顾过去、展望未来的盛会，更是凝聚社区力量的契机。相信在社区成员共同努力下，OceanBase 开源社区将铸就更辉煌的成就。
二、360 商业化业务中的OceanBase 与 Al实践探索
1、RAG 流程与 OceanBase 的基础支持
在探究 OceanBase 与 AI 融合应用前，需先了解 RAG。RAG 流程中，embedding 环节至关重要，它将高维稀疏语义转为低维稠密二进制，即把文档转为浮点数存储，这些浮点数存储在 OceanBase 数据库，为后续 AI 应用提供数据支持。OceanBase 能在多方面为业务提供支持。底层存储支持向量存储，上层支持常用索引如 HNSW 索引 ，还有向量搜索层，为向量存储及操作奠定基础。
2、使用 OceanBase 进行向量存储的优势
👉 易用性强：OceanBase 支持用标准 SQL 方式进行向量查询，对运维和开发人员友好，降低开发门槛，让开发人员专注业务逻辑开发。
👉 完善的监控能力：通过 OCP 平台，OceanBase 可对集群从主机集群和租户等级别进行全方位监控。
👉 出色的水平扩展能力：水平扩展是 OceanBase 主打特性。限量租户遇资源瓶颈时，可增加 Unit 数量或提升 Unit 规格。其内置的 Paxos 高可用机制，能保证向量查询有结果，让大模型回答更准确。
3、AI 实战中的 OceanBase 业务场景
👉 广告主查询场景：将实时和离线报表向量化存储在 OceanBase，广告主可用自然语言查询，如询问情人节鲜花收益情况，便捷获取信息。
👉 SRE 运维知识库场景：类似 chatDBA，结合 AI 快速检索故障解决方案，帮助新手 DBA 定位问题，提升运维效率。
👉 开发流程标准化场景：与 IDE 结合，把 DBA 最佳实践、开发手册等向量化存于 OceanBase，开发人员写出低效 SQL 语句时，IDE 自动提示，提高代码质量。
👉 OceanBase 与 Dify 结合的场景：Dify 是大语言应用开发平台，OceanBase 4.3.3 版本后支持向量数据库，Dify 0.1 版本后支持 OceanBase 作为底层向量存储，为大语言应用开发提供强大支持。
4、商业化报表类业务痛点与 OceanBase 的解决方案
1️⃣ 商业化报表类业务痛点
👉 内存不足问题：报表业务查询范围大时易出现内存不足（OOM），行存模式下计算节点在长时间范围查询时易触发，导致业务侧需在数据库稳定性和服务可用性间取舍。
👉 高并发下系统压力大：大规模并发报表查询会产生热点读问题，业务方设置 SQL 超时时间后，超时未返回会再次执行 SQL，加重系统负载。
👉 资源利用率不均衡：广告类报表业务高峰期在特定时段，系统资源消耗迅速，低峰期流量少，要求数据库具备错峰计算和横向扩缩容能力。
2️⃣ OceanBase 的解决方案
👉 高并发加速运算能力：优化底层存储和并发调度机制，打开 Auto DOP 功能，优化器根据 SQL 复杂度自动选择并发方式加速。
👉 分区自动分裂功能：4.3.4 版本作为实验特性发布，4.3.5 版本正式 GA。OceanBase 按用户指定大小自动分区单表，避免资源热点，提高利用率。
👉 物化视图功能：适合报表类业务，在业务低峰期统一计算，避免高峰期重复计算，以空间换时间。
👉 列存模式：4.3 版本提出，创建表时可选行存、列存或行列混存，列存副本可单独存储，减少无关数据加载，降低 IO 开销，适合大规模分析业务。
5、360 商业化 HTAP 业务的收获
基于 OceanBase 的解决方案，360 商业化 HTAP 业务成果显著。HTAP 分析业务效率提升 80%，查询时间从约五分钟缩短至 40 秒，查询范围从六个月扩大到一年以上。商业化报表服务已稳定运行超一百天，有力支撑业务发展。
三、多云环境高可用架构保障OceanBase 落地作业帮实践分享
作业帮分布式数据库负责人刘强，分享了 OceanBase 在作业帮的落地实践，介绍了作业帮多云环境下的架构情况，以及 OceanBase 如何助力实现高可用架构和其在公司内的主要应用场景。
1、作业帮的多云环境基础架构
作业帮在三个公有云上购置物理机，部署业务与数据库。以 MySQL 为例，云一业务量较大，承载了大部分业务流量，因此 MySQL 的主节点设置在云一；而其他两个云流量相对较小，主要部署从节点，以此满足机房容灾的需求。在这种架构下，每个云内的业务都对应本地云内的一个 Proxy。写入流量需要跨云到云一，而只读流量则优先在本地路由。
2、基于 OceanBase 的架构调整
作业帮在部署 OceanBase 时，基于其两个特性实现了多云的高可用架构，主备租户同步的架构以及服务名的访问方式。
1️⃣ OCP 服务的高可用部署：
在使用 OceanBase 时，作业帮高度依赖 OCP。为确保 OCP 服务本身的多云高可用性，在每个云上都部署了一个 OCP 的 Server 节点，并且 OCP 使用的后端元数据数据库同样也是 OceanBase，在每一个云上也各部署一个节点。如此一来，在任何一个云发生故障时，都能保证 OCP 服务的正常访问。
2️⃣ OceanBase 集群部署策略：
考虑到网络稳定性，如果将 OceanBase 一个集群的多个节点跨云部署，一旦网络出现抖动，业务在数据库层面可能会出现读写问题。因此，作业帮选择在主要的云上部署一套 OceanBase 集群作为主集群，所有业务的读写流量优先访问主集群；在另外一个云上部署一套 OceanBase 集群。对于每一个业务租户而言，其主租户位于云 1，备租户在云 2。云 1 和云 2 的业务流量都会自动路由到云 1 的 OceanBase 集群中。
当机房出现故障时，会进行容灾切换，将云 2 的集群提升为主租户。由于业务的 addr 和 user 无需变动，仅需上层将云 1 的业务流量切到云 2，OBProxy 能够自动识别新的主租户在云 2 上，从而完成多云的高可用架构切换，且对业务几乎没有影响。
3、OceanBase 在作业帮的主要使用场景
1️⃣ 高并发写入：
作业帮的部分业务每天的写入量极大，高峰时 Insert 操作将近 5 万次，并且业务表的字段较大，这对数据库的压力挑战很高。OceanBase 相较于其他数据库在性能上具有显著优势，目前在公司内这种高并发写入场景下运行良好，是一个较为理想的解决方案。
2️⃣ MySQL 的迁移：
作业帮面临单机磁盘空间紧张的问题，单机磁盘 7T，很多业务使用量达到 5 - 6T，这不仅使得数据处理较为麻烦，成本也较高。将此类业务迁移到 OceanBase 是后续重点推广的项目。从成本对比来看，迁移到 OceanBase 后能节省大量成本。
3️⃣ 基于主备租户架构的单元化改造探索：
近年来，作业帮一直在调研单元化的改造方案。例如，部分业务在华北，部分业务流量入口在华南，对于一些复杂业务场景，事务来回的链路耗时较长，影响业务体验。常见的单元化方案是通过两个集群之间的 DTS 方案实现，而 OceanBase 的主备租户架构更为轻量化且稳定。
作业帮设想将集群 1 里的租户 1 作为华北的业务数据模块，集群 2 里的租户 2 作为华南的业务数据模块，每一部分数据都是自包含的，两个集群之间进行双向主备租户同步，既实现容灾，又能实现业务的单元化改造。不过这还只是初步设想，后续还需与研发业务部门进行更细致的设计。
四、降本增效，OceanBase 助力BOSS 直聘数据库分布式转型
BOSS 直聘资深 DBA 王占全分享了 OceanBase 在其数据库分布式转型中的关键作用。
1、OceanBase 应用场景落地
👉 数据归档：BOSS 直聘率先在数据归档场景试点 OceanBase，自去年 3 月正式接入。该场景通过定期将 MySQL 冷数据归档，释放 MySQL 存储空间，优化其运行效率。
👉 聊天消息存储：招聘场景中聊天数据量大，BOSS 直聘采用双写机制。MySQL 存近 1 个月数据满足高频访问，OceanBase 存储全部数据，实现历史数据长期留存。
👉 数据工程分析：此场景存储聊天行为数据并分析。OceanBase 为这些对了解用户行为、优化产品和制定营销策略意义重大的数据，提供了可靠的存储与分析支持。
👉 管控平台元数据存储：BOSS 直聘将 CMDB 和配置中心等管控平台元数据存于 OceanBase，看中其高可用性。机房故障时，能消除切换循环依赖，快速恢复管理平台，保障业务连续性。
目前，BOSS 直聘 OceanBase 使用规模不断扩大，拥有 24 个集群，超百个线上节点，总存储量达 700T+。
2、OceanBase 带来显著收益
1️⃣ 硬件成本降低：
使用 OceanBase 后，BOSS 直聘存储优化显著，整体存储至少降低 60%。如 4T 归档集群单副本在 OceanBase 可达 500G 左右；原 MySQL 中约 70T 的一个月聊天消息数据，在 OceanBase 仅需 20T 左右。经核算，节省超 50 台物理机，降低了硬件采购和维护成本。
2️⃣ 运维效率提升：
👉 自动化程度高：OceanBase 线上运维简便，扩容迅速，缩短业务等待时间。
👉 问题排查便捷：丰富的内部指标助力运维人员快速定位问题，提升故障处理效率。
👉 稳定性有保障：系统运行稳定，极少出现问题，保障业务持续运行。
3️⃣ 技术收益：
👉 性能提升：复杂 SQL 响应时间大幅缩短，业务处理效率显著提高。迁移到 OceanBase 后机器使用率降低，单机可承载更高流量，满足业务增长需求。
👉 稳定性改进：OceanBase 故障率极低，RTO 小于 8 秒，实现金融级高可用，且运维对业务影响小。
👉 扩展能力更强：扩展能力出色，添加机器可自动扩容，并发处理能力强于传统单机数据库，高峰期弹性扩缩容便捷。
通过将财务相关查询迁移到 OceanBase 后，SQL 执行效率普遍显著提升，从迁移前和迁移后的平均耗时对比中，能明显看出 OceanBase 带来的性能飞跃。OceanBase 助力 BOSS 直聘在数据库管理方面实现了降本增效，提升了技术水平，为企业的持续发展和业务创新提供了坚实的基础。
五、KV 场景性能升级：好未来试点 OBKV 探索经验分享
好未来数据库专家王新然分享了好未来在 KV 场景下，通过试点 OBKV 实现性能提升的探索经验，并介绍了目前线上业务使用 OceanBase 的情况。
1、OBKV 在业务中的试点背景
在基础设施方面，好未来的线上集群规模持续稳步发展，已成功部署了五套 OceanBase 集群且有 31 个租户在这些集群上稳定运行，为各类业务的开展提供了坚实支撑。
好未来作为一家头部教育科技集团，教学活动是其核心业务场景。在课堂教学过程中，师生间丰富的互动信息，例如老师在授课时绘制的涂鸦、发送的指令以及学生的即时反馈等，都依赖消息系统进行存储。目前，这一关键的存储任务由 Pika 承担。
然而，随着教育业务的蓬勃发展，历史消息呈海量积累，同时课堂出勤人数也快速增长，基于 Pika 3.3.6 版本构建的存储方案开始逐渐暴露出一系列性能与稳定性方面的隐患同时影响了教学互动数据存储的效率和可靠性，从而对整体教学体验的流畅性构成了潜在威胁，亟待通过优化或替换存储方案来解决 。
Pika 存在的问题表现在以下几个方面：
👉 并发写入较大引发响应超时：上课期间，业务并发写入量较大，Pika 会偶尔出现卡顿现象，影响消息存储的及时性和系统响应速度。
👉 主从切换时老库重新同步问题：主从切换时，老主库有时需要重新同步新主库的数据。由于 Pika 上的数据量达到 TB 量级，像 Redis 一样进行全量同步操作风险极高，可能导致长时间的业务不可用和系统性能下降。
👉 数据删除无法有效释放空间：业务在达到瓶颈后删除一些数据，但数据删除后空间释放效果不理想，执行 compact 操作后，空间释放也不明显，造成存储资源的浪费。
👉 老版本 Pika 运维难度大：老版本 Pika 资料匮乏，这使得运维团队在维护和优化 Pika 时面临诸多困难，对运维 Pika 的信心不足。
2、选择 OBKV 替代 Pika 的原因
鉴于 Pika 存在的上述问题，好未来考虑使用 OBKV 进行替代，主要基于以下三点原因：
1️⃣ 完全兼容 Redis 协议：
OBKV 完全兼容 Redis 协议，并支持常用命令。在消息服务场景下，OBKV 已经通过了 POC 测试。好未来的消息业务使用的功能并不复杂，OBKV 目前提供的命令支持能够很好地符合业务需求，无需对业务代码进行大规模修改即可实现平滑过渡。
2️⃣ 同源产品的高性能与高可靠性：
OBKV 和 OceanBase 属于同源产品，原生继承了高性能、高可靠、高压缩以及分布式等能力。从 OBProxy 到底层的 OBServer，除了协议层不同，其他部分基本一致，这使得 OBKV 在服务可用性和稳定性方面表现出色，让好未来对其运行可靠性充满信心。
3️⃣ 丰富的工具体系与活跃的社区生态：
OceanBase 本身拥有丰富的工具体系，并且这些工具完全适配 OBKV，这使得好未来内部能够形成一个统一的技术栈，便于管理和维护。同时，OceanBase 良好的社区活跃度以及强大的技术支持，也为迁移到 OBKV 后的技术难题解决和系统优化提供了有力保障。
3、性能对比结果
经过性能测试对比发现，OBKV 相对于 Pika 在性能上有一定提升，这为好未来在 KV 场景下的业务发展提供了更有力的支持，也坚定了好未来在相关业务中进一步推广使用 OBKV 的决心 。
六、从开放到连接：蚂蚁图计算 (rucraph)开源年度总结
TuGraph 社区开源负责人、布道师范志东进行了蚂蚁图计算开源年度总结，分享了 TuGraph 的开源经验与社区思考。
1、关于图技术的思考
范志东首先介绍到，图是一个复杂的数据结构，可以看作更高维的数据连接方式抽象，并基于多年业务、商业化及开源场景实践分享了关于图的思考。
👉 关系本体论：对图来说“我连接故我在”，连接是关键词，通过连接的方式来思考数据的建模和分析流程。
👉 图的三个内涵：科学内涵 - 从数据结构角度来讲，图是最复杂的数据结构；客观内涵 -万物互联的必然性；哲学内涵 - 存在不是实体的集合，而是关系的场域。
👉 图的优势：关系的确定性、图算法的可解释性、图特征的稳定性。
2、TuGraph 社区演进路线
👉 2024 年之前——开放源码（探索期）：开放单机图数据库 TuGraphDB，分布式流图引擎 TuGraph Analytics。
👉 2024 年——开放生态（破局期）：“用开源服务开源”的开源图谱洞察工具 OSGraph、开源 DB-GPT GraphRAG、开源 Text2GQL，并启动 TuGraph Analytics 的 Apache 孵化流程。
👉 2025 年——开放心智（增长期）：开源图智能体 Chat2Graph、mini-GU，以及统一图数据管理 GraphUniverse 等。
3、TuGraph 社区未来探索路径
1️⃣ 从 Infra 到应用的纵向场景探索
👉 基础融合索引的思路，增强 Graph 基础能力，改进图分析效果。
👉 基于开源数据，结合图可视化与图智能化，加速图数据洞察。
2️⃣ AI 时代浪潮下的横向生态破局
AI 时代大模型最大的痛点为模型幻觉，需要不断改进补充大数据的能力。连接主义和符号主义的结合可以减轻大模型幻觉问题。
👉 DB-GPT GraphRAG：基于 TuGraph 构建知识图谱和多路检索，改进 RAG 问答质量。
👉 Text2GQL：构建图语言的语料生成与大模型微调，提升图数据上的自然语言理解能力。
👉 Chat2Graph：建设面向图的多智能体系统，降低用图门槛，加速图数据洞察。
4、以人为本的合作共赢
布道师需要在技术、内容和社区上持续跟进。基于技术创作出更多的优质内容，然后将内容传播到社区，通过社区来获取大家的贡献反馈。反过来，社区通过了解公开的优质内容，理解我们的技术，并将技术应用到社区的产业生态里去。通过双向的增长飞轮，促进开源社区与 TuGraph 技术生态的共同发展。
七、文档智能+知识图谱+大模型结合范式
360 人工智能研究院知识图谱及文档理解算法方向负责人刘焕勇分享团队在文档智能、知识图谱和大模型三个技术在实际落地研发过程中的一些心得体会。
1、文档智能：文档解析解决的是原始数据单元的抽取和以及标准化的问题
👉 文档解析整体流程三种方式：PDF2TXT、OCR-PIPELINE、OCR-FREE
👉 文档解析落地包含：布局分析、表格解析、公式解析、图表解析、文档阅读顺序、文档层级关系表示、图表 meta 信息抽取、Figure2meta 出口、文档层级图、文图链接。
2、知识图谱：知识图谱解决chunk之间关联以及细粒度问题
知识图谱在 LLM 大背景下，应该有更为广泛的含义，可以突破之前的知识三元组形式。
👉 文档元数据级关系图谱：节点为各个文档名称/主题等元数据，关系为文档之间的相似关系/父子关系等。
👉 文档块级关系图谱：节点为各个 Chunk（Title，Paragraph，Doc，Tabled，Figure 等），关系为 Chunck 之间的父子、共现、相似等关系。
👉 文档实体级关系图谱：节点为文档中的特定实体类型及其关系（Schema Based）或者关键词网络（Free Schema）。
👉 应用范式：知识图谱增强大模型问答。
3、大模型：微调大模型解决情报问答问题
👉 RAG 多环节优化策略：RAG 优化涉及到检索 Ranking、Query 改写、Chunk 切分、Prompt 组装等多个优化环节。
👉 多模态 RAG 实现：解析式文档多模态 RAG、DocVQA 式文档多模态 RAG。
4、实践体会分享
语料加工是情报处理中十分重要环节，加工的程度和质量，影响情报的含金量。多模态大模型给文档处理带来新的机会，值得期待。在挖掘文档信息过程中，虽然现有很多工具，要保证质量可信的话，人工审核仍然不可或缺。文档智能一些长尾问题还未得到根本解决。知识图谱要积极拥抱变化，要从结构、粒度、形式等多方面发展。在资源受限且文字密集型的场景中，小模型方案（传统 NLP/CV/BERT 等）不能丢。
八、RAG 2.0：记忆驱动的下一代检索增强系统的探索与进展
智源研究院研究员钱泓锦从 2018 年开始自然语言处理、信息检索相关研究，2022 年开始专注于 RAG。本次分享聚焦于信息检索和 RAG 大模型方向，深入分享了智源研究院研究团队在此方面的工作进展，以及如何借助记忆驱动的RAG 2.0（下一代检索增强系统）提升模型对复杂问题的处理能力。
1、RAG 概念与系统原理
RAG 的诞生是因为传统搜索引擎靠单一指标工作，大模型虽然知识多，但面对复杂问题时，由于训练存在知识截断，长尾知识覆盖不全等问题，往往给不出可靠答案。所以提出 RAG 机制，就是用外部知识（Z）来生成最终答案（Y）。
在 RAG 系统里，X 是原始输入，比如公司内部的大量知识文本；Z 是从外部知识库找到的相关知识；Y 是生成的答案。信息传递时，Z 包含 X 的信息，但从 Z 到 Y 会减少。打个比方，妈妈给 100 块钱（X）买猪肉，我愿意花的钱（Z）和买到猪肉的价值（Y）有差距，RAG 系统中 X 到 Z 的信息差距更大，要从 Z 里找准确答案生成 Y。
2、当前 RAG 模型的问题
👉 信息不足与冗余并存：找准确信息时，很难同时满足信息量足和精准度高。Top K 值大，信息全但冗余多；减小超参数值可以减少冗余，但又会导致信息缺失。
👉 线性 Pipeline 流程有缺陷：RAG 1.0 的线性流程，不能提前了解知识库内容。对于像 Singel-hop Factoid Query 这类问题，RAG 1.0 模型表现好；但对于 Multiple-hop Factoid Query 这类问题，RAG 1.0 就确定不了回答该问题所需的证据数量，设置 Top K 值很容易出错。Explicit Ration Query 这类隐式相关性强的 问题，传统检索方法也无法应对。
👉 部分问题处理能力弱：对泛化问题，比如 Implicit Rational Query 问题，RAG 1.0 仅靠搜索结果效果不好。全新主题，模型无法直接作答，得结合个人文本检索。
3、探索方向与成果
1️⃣ 模拟人类记忆机制：
让模型模拟人的记忆，先形成初步记忆，再生成线索找证据出答案。这里面临形成记忆、优化线索质量、提高效率等挑战。处理长文本时插入 Memory Token，用 SFT 训练模型。这提升了传统 QA 任务表现，也能更好解答 Implicit Rational Query 问题。
2️⃣ 二级缓存记忆机制：
借鉴人脑记忆结构，提出二级缓存记忆机制。一级缓存类似压缩的 KV Activation，二级缓存信息丰富。训练时插入二级缓存 Token，训练后拆分，一级缓存全局理解，二级缓存按需回填。实验表明，处理长文本时，二级缓存记忆模型效率和效果都更好，相比传统 Memory Model 优势明显。
分享的最后，钱泓锦研究员还给大家展示了下团队做的一些大模型的相关开源工具。未来，团队会聚焦隐含推理问题处理、优化信息冗余和缺失权衡，以及发展更高效的检索和生成算法。
九、探索 Dify.AI：开源生成式 AI创新引擎的无限潜力
Dify.AI 是一个简单易用且开源的 LLM 应用开发平台。在本次活动中，Dify.AI 后端工程师秦骏言分享了如何帮助开发者和业务专家以低代码的方式快速搭建 AI 应用，介绍了全新的 Parent-Child Retrieval（父子检索）功能如何进一步提升 AI 应用的信息获取与上下文理解能力，并为现场开发者讲解了 Dify v1.0.0-Beta 最新版本中推出的插件机制。
1、Dify.AI 平台：快速构建生产级 AI 应用的利器
随着 LLM（大型语言模型）日益火爆，基于 LLM 技术栈进行应用构建的困难也逐渐凸显。Dify.AI 正是为解决这些问题而诞生，赋能生产级 AI 应用开发，具有简洁友好的用户界面，极大地简化了开发流程。无论是验证新想法还是构建企业级 AI 解决方案，都能通过 Dify.AI 高效实现。
Dify.AI 坚持模型中立，支持全球 1000+ 最新最强大的 LLM。用户可通过 Dify.AI 创建 Agent、Workflow、Chatflow 等类型的 AI 应用，将应用发布为 WebApp 供外部访问，也可以直接获取 AI 应用的 API 进行进一步开发。同时，借助 Dify.AI 平台及其 RAG Engine 的能力，用户可轻松导入私有数据并连接各类工具。不仅如此，用户还能够查看 AI 应用的详细日志，便于应用的调试和发布，以进行持续的运营和迭代。
2、Dify RAG Engine：提升检索精度的创新方案
在 RAG（检索增强生成）场景中，传统检索方法往往面临精度不足的挑战。为此，Dify 创新性地引入了 Parent-Child Retrieval（父子检索）技术。该技术通过智能分段，将长文本内容切分为语义完整的子段落，并独立计算每个子段落的 embedding 向量。在检索时，系统不仅匹配用户问题与最相关的子段落，还会智能关联相关联的上下文内容，确保检索结果的完整性和准确性。这种方法显著提升了检索质量，使 AI 应用能够提供更精准的回复。
针对向量数据库在资源受限环境下的部署痛点，Dify 支持基于 OceanBase 的云端向量检索方案。用户只需配置 OB Cloud 连接信息，即可获得高性能的向量检索能力，既降低了本地资源占用，又保证了检索性能。
3、Dify v1.0.0-beta：开放性与灵活性的全新突破
Dify.AI 在 v1.0.0-Beta 全新版本中推出了插件机制。插件机制提供了模块化的即插即用组件，包括模型、工具、Agent 策略、扩展和插件集等多种类型，极大地增强了平台的扩展能力。
用户可以通过 Dify 市场获取来自官方、合作伙伴和社区的各类插件。插件能够从图像识别、音频分析到数据处理等多个领域，显著扩展 AI 应用的能力边界。同时，插件机制支持本地开发和部署，并通过严格的代码审核和权限控制确保安全性。
在架构设计上，Dify 通过插件 Endpoints 实现了外部服务与平台的无缝连接。开发者可以通过自定义端点和 API，实现与 Dify 内部模型、应用、工具、知识库以及工作流节点的灵活交互，支持更复杂的应用场景。例如，开发者可以轻松构建一个能实时调用 Dify 模型和查询知识库的聊天机器人，为用户提供智能的上下文响应。
Dify.AI 通过开放的插件机制、强大的 RAG 引擎以及灵活的应用开发能力，正在构建一个充满活力和创新的 AI 应用开发生态，让开发者和企业能够更便捷地实现 AI 应用的创新与落地。
十、Al动手实战营
“AI 动手实战营” 是本次嘉年华的一大亮点。在技术专家的悉心指导下，参与者们亲自动手实践，一步步构建基于 OceanBase 向量检索能力的 AI 智能应用。从理论知识的讲解到实际操作的每一个细节，专家们都手把手耐心指导，让参与者们在实践中深刻理解技术原理，掌握应用开发技巧。
OceanBase 开源社区嘉年华的成功举办，不仅为技术爱好者和开发者们提供了一个学习、交流和实践的平台，也充分展示了 OceanBase 在开源技术领域的强大实力和创新精神。相信在未来，OceanBase 将继续引领开源技术潮流，为行业发展注入新的活力，推动更多技术创新和应用落地。
