LangGraph与OceanBase融合数据层：企业AI落地深度解析_AI热点日报

约95%企业AI落地未获回报，根源在数据层。企业应用需融合结构化、非结构化、向量、空间等多模态数据，并支持语义、关键词、数值、位置等混合检索。通过LangGraph与OceanBase构建融合数据层，统一存储与检索，可简化架构，支撑复杂业务场景。

麻省理工学院最新报告指出，约 95% 的企业在实施 AI 后并未获得实际商业回报。这一数字是否似曾相识？我们身边不乏这样的案例：Demo 演示时惊艳全场，一旦上线却无人问津。问题究竟出在哪里？

实际上，问题的根源往往不在于 AI 模型本身，而在于我们忽略了关键的底层环节——数据层。现实中的企业 AI 应用，远比我们想象的更加复杂。本文将从真实场景切入，通过动手构建一个 Demo，深入探讨企业级 AI 应用在数据层面的真实需求，以及如何构建合适的底座来支撑真正的落地。

先梳理本文的核心脉络：

真实的业务需求，可能比你想象的更复杂
当向量库遇到企业级应用，天花板在哪里
实战：构建一个多模态混合检索 Agent
传统 RAG 方案也并未消失
结语：一体化 AI 数据底座引领未来

完整源码见文末。

01 问题：超预期的真实业务需求

AI 在企业应用中的表现不尽如人意，工程上的高要求固然是一方面，但更常见的是：开发者常常沉浸于技术细节，反而忽视了真实场景的复杂性。

就拿看似简单的“AI 咨询”来说，用户的需求远不止“产品有什么特点”或“如何退换货”这类单维问题。这些依靠“知识库+向量库+LLM”确实可以轻松解决。但现实中的请求往往是这样：

“有没有类似图片这种的布艺沙发，价格低于8000，适合女生。我在朝阳区，附近最好有销售点，想去体验下。”

再比如：

“找到北京地区近三个月购买过家居类产品，最近的投诉内容里涉及配送问题；优先推荐在我们现有库存量大的 SKU 上投放优惠券。”

这类请求融合了向量相似（理解图片、“适合女生”）、关键词（“配送问题”）、数值精确过滤（价格）、位置约束（附近有销售点），甚至还包括个性化信息（购买过xx产品）。现在请回想一下：你正在建设的 RAG 或者 Agent 应用，能否支持这样的对话？

问题的瓶颈其实并不在 LLM，也不在向量数据库本身。根源在于：

企业 AI 应用的大量场景从来都不是孤立的（比如查询财务政策、保修条款，或者创作一封邮件），它们与企业的业务紧密联系，体现在应用、流程和数据多个层面。

因此，企业真实应用场景的复杂性远超想象。我们必须意识到：

数据的多样性是常态
- 产品有图片、文字、参数、评价、宣传视频
- 交易有金额、时间、地点、关联商品、满意度
- 用户有基本信息、行为、社交关系、客户画像
查询的复杂性是必然
- 语义相似 + 价格区间 + 地理位置
- 图像匹配 + 库存状态 + 用户偏好
- 关键词搜索 + 时间范围 + 关联推荐
应用的融合性是趋势
- 用户的行为会实时影响到 AI 推荐结果
- 价格、宣传物料的更新会实时反映到 AI 搜索结果
- AI 应用的交互信息会实时影响用户画像

02 思考：当向量遇到企业级应用的天花板

上述问题和案例，暴露了当前许多以数据为中心的 AI 应用的核心痛点。

第一个痛点：新的 AI 数据“孤岛”

企业中不仅有大量非结构化文本，还有丰富的结构化信息，而这些结构化信息往往是核心生产数据。它们通常需要关联使用。例如，一个企业的“产品”相关信息：

在 AI 时代，我们擅长把非结构化文本存入向量库，比如用户手册、常见问答等；而产品的价格、类别、库存、参数等则留在传统的 RDBMS 或文档数据库中。这样一来，数据同步与维护变得复杂、低效、代价高昂，甚至还可能涉及复杂的分布式事务问题。

第二个痛点：多种模态数据的割裂

现有以向量为核心的 RAG 应用主要还是面向文本的。当客户提供参考图片或其他非文本信息时，往往捉襟见肘。常见方案是借助图片嵌入模型，但这需要额外的开发框架支持。如果能够将图像、音频、视频等多模向量，与非结构化文本向量统一存储与检索，就能更方便地实现跨模态关联，大大减少应用层的“粘合”开发工作。

第三个痛点：单一的检索维度

各种类型数据的割裂，直接导致了检索能力的单一。但真实场景中的检索往往是“混合”型的。在割裂的数据层中实现混合检索，不仅处理流程复杂，更关键的是不统一的检索接口或查询语言。比如，结构化过滤使用 SQL，语义检索却要用向量库的 API——这取决于不同的产品实现。

当前应对混合检索的常见方法有几种：

多种检索方法组合使用。比如先用结构化条件筛选，再用向量做语义匹配与排序（也可以反过来）。这种方法既麻烦，性能也堪忧。
一些优秀的向量库也支持元数据过滤等筛选。比如查找“xx类别”下语义近似“xxxx”的块。不过这种方式更适合轻量级场景，而且元数据大小有限制。
完全在应用层实现拼接：分别检索后由应用做合并、去重和排序。

那么，有没有更好的解决方案？答案是：多模态的融合 AI 数据层。

数据具有不可复制性、价值积累性以及业务依赖性。要破解这些核心痛点，释放 AI 潜力的技术关键或许仍然在数据层：一体化的 AI 融合数据层，可以面向多模态、多负载提供统一的数据存储、检索与更新能力，从而极大地简化上层应用架构。开发者可以更专注于业务需求的满足，而不是在技术层面的“粘合”工作里打转。这能显著改善以下几个方面：

多模态统一数据支持：多种模态的数据可以更一致地存储，并创建混合索引。
融合的数据应用能力：多类型索引、混合检索、简化数据同步、提高性能。
简化系统架构与运维：更容易实现统一的架构设计、性能优化、分布式扩展等。

03 实战：构建一个多模态混合检索 Agent

为了更直观地理解“多模态融合 AI 数据层”的方案与价值，我们来动手构建一个基于真实场景的完整 Demo。

场景设计

假设一个家居产品（比如沙发）的销售企业，在多个渠道部署了 AI 产品推荐与咨询机器人。用户可以与 AI 展开连续的对话，比如：

“我想买类似这张图片风格的沙发，适合女生，布艺，价格低于10000，最好有优惠政策。【上传了参考图片】”

“推荐的这款产品，维护保养能不能详细介绍下？”

“我之前买过你们一款沙发，很不错，想再买一个大点，但是样子差不多的。”

工具选择

技术选型如下：

开发框架：LangGraph，用来更灵活地实现 AI 应用工作流
融合 AI 数据层：OceanBase（OB Cloud 实例）
LLM 模型：通义千问
嵌入模型：阿里 text-embedding-v3 / multimodal-embedding-v1

这里核心的融合数据层选择的是国产分布式数据库 OceanBase 最新社区版。它能够很好地支持结构化、JSON、向量、空间等统一数据的存储，并提供了简洁一致的访问接口（SQL 及内部算法函数、API 库）。你可以选择使用社区版或 OceanBase Cloud 上的免费实例来完成 Demo（生产级应用推荐企业版）。

方案设计

如之前分析，这些常见的真实场景咨询，用简单的知识库和 RAG 很难应对。要么无法实现，要么效果不佳。你可能会想到借助 Agentic RAG：针对多数据源建立多个检索 Pipeline，再借助应用层 Workflow 来处理，但这样复杂性较高，还可能会产生大量的胶水代码。

本 Demo 的方案有两个核心：

一个融合的 AI 数据层：不再需要其他独立的 RDBMS 或向量库。
一个灵活的 AI 应用层：采用 LangGraph 框架构建应用工作流，整合检索工具。

关键实现

混合检索

借助 OceanBase（打开向量支持）的统一接口与语言（SQL）来方便地实现混合检索。下面是一个例子：

SELECT cosine_distance(p.image_vector, [参考图片的vector]) as similar_score_image,
cosine_distance(p.description_vector, [查询自然语言的vector]) as similar_score_text,
...
FROM products p
WHERE style='布艺' AND price<=10000 AND
cast(JSON_UNQUOTE(JSON_EXTRACT(promotion_policy, '$.discount')) AS DECIMAL(3,1)) < 9.0 AND
st_dwithin(address, ST_GeomFromText(...),20)
ORDER BY similar_score_image ASC
LIMIT 3

在这个模拟检索中，融合了结构化属性检索（价格）、文本/图片相似度（cosine_distance 计算与排序）、JSON 属性过滤（JSON_EXTRACT）、空间数据过滤（st_dwithin）。相对于单一的向量库，这种方式依托于强大的 SQL，可以满足极其灵活与复杂的检索需求。

这里的难点是：如何动态地根据客户自然语言生成检索语句？毕竟单纯的向量检索可以输入任意文本，而 SQL 是一种有着严格语法的查询语言。可以考虑两种方法：

借助 LLM 生成，即广为所知的 Text2SQL。混合检索本身复杂度较高，所以实际应用中需要精心设计 Prompt（提供样例和数据结构）来提高生成准确性，否则容易出错。
LLM 的条件推理 + 代码组装，这也是我们 Demo 中使用的方式：
1. 抽取检索条件：从用户的自然语言输入和上下文中推理出检索条件。借助于现在的 LLM 和 few-shot Prompt，这种抽取可以达到极高的准确性。
2. 检索条件校验：对推理出来的条件进行校验。这里可以做设定：比如有的条件必须提供，有的条件可以选择；根据抽取结果决定是继续检索，还是反馈客户（要求提供更多信息）。
3. 生成混合检索语句：有了检索条件后，生成混合检索语句就只是简单的拼装工作（实际应用中要充分考虑索引利用、SQL 缓存等性能问题）。

代码参考（部分）：

def _vector_search(self, embedding: List[float], filters: Dict[str, Any] = None, search_type: str = 'text') -> List[Dict]:
    try:
        # 根据搜索类型选择向量字段
        vector_column = 'description_vector' if search_type == 'text' else 'image_vector'
        
        # 构建基础查询语句
        base_query = f"""
            SELECT id, name, description, material, style, price, size, color,
                    brand, service_locations, features, dimensions, promotion_policy, image_url,
                    cosine_distance({vector_column}, '{embedding}') as similarity
            FROM {self.table_name}
        """
        
        # 添加过滤条件
        conditions = []
        
        if filters:
            # 材质过滤
            if filters.get(self.material_name):
                conditions.append(f"material LIKE '%{filters[self.material_name]}%'")
            # 省略：添加其他过滤条件
                    
        # 组合查询语句
        if conditions:
            base_query += " WHERE " + " AND ".join(conditions)
        
        base_query += f" ORDER BY similarity ASC LIMIT {self.topk}"
        
        # 执行查询
        results = self.client.perform_raw_text_sql(base_query)
        ......

工作流与 Prompts 设计

为了更灵活地控制流程，我们没有直接使用预置的 ReAct Agent，而是自定义了 LangGraph 工作流。大致逻辑是：重点实现产品推荐和详情咨询，以演示真实场景中的混合检索需求。

Demo 中涉及的重点 Prompt 有：

客户意图识别：主要目的是分离出复杂的产品推荐/咨询意图，以便精准处理。
过滤条件抽取：抽取自然语言中的各种标量和向量过滤条件，并结构化输出。

其他如闲聊引导、最终推荐结果生成等，可根据需要自行设计 Prompt。

测试效果

最后，让 AI 帮忙写一个简单的 Streamlit UI 来测试我们的 Agent。查看 Agent 的处理过程可以看到：Agent 借助 LLM 提取了结构化的查询条件，同时也借助图片和文本的向量相似度进行了筛选排序，最终返回多个产品信息。LLM 整理后输出图文结果。

对这个 Demo 做简单改造，就可以进一步增加对空间数据（POINT、POLYGON 等类型）、半结构化数据（JSON 类型）的融合检索能力，以覆盖更多复杂业务场景（比如基于位置的附近网点咨询、旅游规划等）。

04 扩展：传统方案并未消失

上面的案例展示了在融合的 AI 数据层上的多模态混合检索能力：一种技术、一套 API、一条语句，就能同时展开多模态、多条件、多索引的数据检索。

但请注意，这个数据层是完全可以兼容传统知识库型 RAG 应用的需求的。你应该注意到了，在 Demo 的工作流中，有一条分支专门用于处理客户进一步的产品详情咨询：比如了解某个推荐产品的手册或白皮书中的部分内容。我们可以把这些文档用经典 RAG 的方法进行拆分（Split）、嵌入（Embedding）、存储成向量，并与产品、原始文档、文本内容关联存放到 OceanBase 中。剩下就很简单了，用推荐产品和用户输入做条件直接检索即可：

SELECT ......检索的字段......
cosine_distance(pd.chunk_vector, ?) as similarity_score
FROM products p
LEFT JOIN products_docs pd ON p.id = pd.product_id
WHERE p.id = ?
AND pd.chunk_vector IS NOT NULL
AND pd.chunk_content IS NOT NULL
HA VING similarity_score <= 0.8
ORDER BY similarity_score ASC
LIMIT 3;

可以看到，数据关联、相似度判断、甚至调试检查都变得更简洁和“优雅”。从测试效果来看，Agent 后台的跟踪信息也充分证明了这一点。

如果你暂时只需要构建简单的知识库 RAG，但又希望预留未来的扩展能力，还有两种更简洁的方式：

LlamaIndex/LangChain/Dify 等框架 + OceanBase：这些主流开发框架或平台都支持 OceanBase 作为 AI 数据层，保留面向未来的高度扩展性。
借助 OB Cloud 的 PowerRAG 数据应用开发平台：如果使用云端的 OceanBase 实例，可以借助 OceanBase 官方的一站式 RAG 应用低代码开发平台。通过简单的知识库上传，即可快速构建属于自己的 RAG 应用（目前还是预览版，更多功能正在完善中）。

05 结语：一体化的 AI 数据底座引领未来方向

上面的 Demo 很好地展示了一体化融合 AI 数据层的价值与收益：

架构极简与技术栈统一：关系库、全文检索、向量库合一，大幅减少组件数量与跨系统的粘合代码；应用只需对接一种协议、一种驱动、一套工具链，开发、维护与升级的复杂性都随之下降。
单条“语句”实现混合检索：在一条 SQL 或 API 中同时执行属性过滤、向量相似度排序，还可以结合空间数据、全文检索、JSON 抽取。避免多段式开销，减少跨系统查询与数据搬运。
相关性与精确性提升：结合传统数据库索引 + 关键词过滤 + 语义检索的联合计划，兼顾标量匹配与向量相似，减少传统方案里“结果不够 K 条”或“语义相关但条件不满足”的两难问题。
一致性与数据实时性更好：结构化字段与多模态向量共处同一事务域，实现数据更新天然一致，避免异步同步导致的“新旧不一”和读写延迟等问题（很多场景中这会影响用户体验）。
更好的企业级可用性、性能与扩展性：融合 AI 数据层以传统 RDBMS 的扩展为主，这让 AI 应用可以充分利用传统数据库更成熟的企业级特性：高可用性、高性能、海量数据及扩展性。

最后的思考：融合 AI 数据底座，传统 RDBMS 的新机会？

融合 AI 数据层解决方案并不是简单地把“向量库 + 关系库 + 搜索引擎”拼装在一起，而是要在同一内核中把多种数据与索引类型（标量、全文、JSON、空间、向量）纳入统一的设计与优化器，并在事务、分布式处理、资源调度、性能优化、容灾、治理等多方面实现一体化。

显然，这是一项复杂的系统工程。那些拥有更强企业级 IT 基建能力的传统 RDBMS 供应商，其长期积累使其更有条件把向量等能力“吃进内核”，实现真正一体化的、面向 AI 的数据“底座”。

或许，这正是传统数据库厂商在 AI 时代转型的必然方向之一，甚至是像 OceanBase 这样的国产数据库在 AI 时代实现弯道超车的重要机会。