作者：傅榕锋，OceanBase 高级技术专家
在过去一年， OceanBase 在AI 能力方面快速发展， 从2024年6月社区用户基于OceanBase基础向量能力实现RAG小助手，到10月发布第一个正式向量版本 OceanBase 4.3.3，可用于生产环境。随后快速和 Llamalndex、DB-GPT、Dify 等主流的生态产品进行适配，同时也开放了 RAG Demo 并在线下活动开展丰富的 AI Workshop。再到11月份，我们开放了基于多模融合查询 Demo，并为社区用户开放线上 AI Demo 体验，包括：基于向量检索的图搜图应用、基于向量检索的 AI 知识库、基于多模融合查询的 AI 助手。
直到2025年，我们陆续发布了OceanBase MCP 、Power RAG、OceanBase AI 一体机，以及 OCP、ODC、OMS 等工具的 AI 能力的增强，并宣布全面拥抱AI。
AI 应用开发平台选型
通过快速迭代去实现功能的构思并验证其可行性，除了团队成员的深度投入外，选择一款适合的工具可以事半功倍。在选择AI应用开发平台时，我们明确了三个要点：
- 可视化编排。通过白屏操作，快速验证一些想法的可行性。
- 可编程节点，由于许多平台提供的节点不能完全满足我们的需求，因此我们希望平台对节点开放，支持自主编程。
- 可复用流程。例如在ChatBI场景中，大模型时常因为缺少业务相关知识导致无法正确理解问题，此时我们就可以复用已经开发好的 RAG 流程，通过用户问题检索对应的业务知识，从而让大模型能够正确理解用户的问题、生成正确的SQL。
基于上述三个选型要点，我们认为Dify较为符合预期。Dify（Define + Modify）是一个面向未来的开源LLM应用开发平台，旨在通过融合后端即服务（Backend as Service）与LLMOps理念，为开发者和企业提供生产级的生成式AI应用构建能力。
首先，Dify的工作流编排能力非常强大，相比其他平台，它拥有完整的逻辑控制能力，包含条件分支、迭代和循环等，且易用性较高。
其次，Dify的可编程节点完全开放了我们的输入和输出，以及中间的过程定义，拥有完整的 Python 函数能力。在前期调研过程中，我们发现其他平台使用完编程节点的能力后需要重启服务，这是我们完全不可接受的。
最后是可复用流程方面，Dify支持在编排时通过左下角工具一栏可以直接添加历史流程，非常方便。
此外，Dify 还提供了插件功能，允许我们在社区直接下载第三方流程以及第三方提供的插件，并直接使用。
Dify 使用挑战及解决方案
在确认 Dify 满足需求后，我们开始了落地和使用，过程中也不可避免地发现了一些挑战。
挑战1：多存储组件维护成本高
业务挑战
下图是 Dify 官网提供的架构图，可以看到有三套 DB，默认架构选择 PostgreSQL 作为元数据库，Redis 作为 cache，Weaviate 作为向量数据库。这样的多组件架构会增加维护的复杂度和学习成本。
解决方案
OceanBase 具备完善的工具体系并且同时支持标量、KV、向量的存储和查询，针对上述问题，我们的想法是可以全部换成 OceanBase 工具吗？使用 OBKV-Redis 替换 Redis，OceanBase 的向量化能力也可以直接替换 Weaviate。而最大的挑战是 OceanBase 不兼容 PostgreSQL，也没有兼容计划。于是我们改造了Dify 分支基于 MySQL 的兼容性，因为OceanBase兼容MySQL，所以就可以使用 OceanBase 作为元数据库、向量数据库（项目地址：oceanbase/dify-on-mysql 分支，扫描下方二维码直达）。
将原本的三套 DB 切换成 OceanBase后，不仅统一了技术栈，实现高效运维，还实现了混合检索能力。
挑战2：高可用、快速扩展较弱
业务挑战
在部署过程中，由于 Dify 默认使用的Redis 和 PostgreSQL 都不支持原生分布式，而 Weaviate 官方则提供 K8s 一种私有化分布式部署方案。在本地私有化部署的情况下，这套架构在面对高并发的场景时存在单点故障的风险，单机的性能限制将成为业务增长的瓶颈。
解决方案
OceanBase 为原生分布式集群，支持两地三中心，三地五中心高可用部署，也支持快速水平扩展，透明扩展，且业务无感知。因此将三个数据库组件都换为OceanBase后，避免了高并发场景下经常宕机的问题，实现了业务稳定运行，也避免了发生故障后不能平滑自动迁移的问题，实现了水平扩展、透明扩展，另外，还提升了备份恢复能力。
挑战3：业务不隔离，多套特务维护成本高
业务挑战
Dify 许可证显示，开源版本不允许使用多租户功能，导致业务不隔离，可能出现相互干扰，但可以通过部署多套集群实现隔离，但部署多套集群的维护成本较高。
解决方案
利用 OceanBase 多租户资源隔离的能力部署多套业务集群，实现业务资源隔离。一个租户对应一套业务，一套集群可以同时支持多套业务。
综上所述，将 Dify 原本的三个数据库替换成 OceanBase 后，实现了：存储系统 OceanBase = PostgreSQL + 向量库 + Redis，并取得如下收益：
- 稳定性提升。提供7x24 小时企业级高可用能力，支持跨机房容灾。
- 扩展性提升。支撑数据无限扩展，单机到分布式，有效避免内存 OOM。
- 强化多租户。基于社区版即可实现多租户。
- 节省成本。一套系统替换多套存储系统，通过资源池化，实现30%的节省资源。
- 统一技术栈，降低运维成本和学习成本。
Dify+OceanBase的落地与应用场景
目前 Dify 和 OceanBase 结合的方案已应用于多个场景，以下简单举例，供大家参考。
AI Agent：戒毒人员对话式量表心理评估工具
2025 OceanBase AI 黑客松中，一位来自戒毒所且没有技术背景的警官提交了他的作品------戒毒人员对话式量表心理评估工具。起因是其在司法行政机关需要履行帮助戒毒人员强制隔离戒毒、康复等职能，其中强制隔离戒毒是一项具有中国法治特色的戒毒措施，围绕教育戒毒人员的戒治工作，运用心理学原理和方法，对戒毒人员开展心理脱瘾和心理康复的重要职责。该过程涉及心理评估，即根据法则和程序对戒毒人员的认知、行为、情感等予以量化，是戒毒场所开展心理咨询经常使用的方法之一。通常会通过单独谈话与量表测试这两种方式进行评估：单独谈话能够获取更大的信息量，评估效果较好，却费时费力（1小时左右）；量表测试可以在短时间内完成，便捷高效，但获取信息单一，评估效果较差。
该警官试图通过大模型能力实现自动化，根据戒毒人员的回答判断、解读其情况，因此选择通义千问大模型和底层数据库 OceanBase Cloud，以及Dify，部署在 Docker 中。
通过流程图，我们可以看到运行过程并不复杂，首先把编制好的量表上传到数据库中，对话开始。然后大模型会根据问题回答给出评分，并判断下一阶段要获取的信息，自动选择更合适的问题，引导戒毒人员逐步回答量表问题。如此循环，最终可以收集到戒毒人员的相关信息。
某东南亚快递公司：智能客服
在某东南亚快递公司海量订单的背景下，其客服每天面临庞大的答疑量，为提升答疑效率、降低客服压力，该公司利用大语言模型能力实现智能客服。起初，使用 Dify 的 RAG 能力，开启了多路召回，中文效果不错，但由于泰语属于小语种，默认的分支器不支持泰语，所以泰语效果比较差。引入OceanBase后，可通过插件快速实现对应语言的分词器解决了该问题。此外，避免了之前在高并发场景下经常宕机的问题，提升了备份与恢复能力。在向量方面，引入 HNSW_SQ，实现了单分区支撑业务，无须分库分表。
最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库 、#AI 、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。