麻省理工的一份最新报告显示，约 95% 的企业在实施 AI 后并未获得实际商业回报。事实上，我们也常见到一些 AI 项目“Demo 很惊艳，上线后无人问津”。问题究竟在哪？我们将从企业级 AI 应用的真实场景切入，并通过一个Demo构建，探讨 AI 在数据层的真正需求，以及企业应如何构建合适的数据底座来支撑真实的 AI 应用。
问题：超预期的真实业务需求
思考：当向量遇到企业应用的天花板
实战：构建一个多模态混合检索Agent
扩展：传统方案并未消失
结语：构建一体化的AI数据底座
本文完整源码见文末。
01
以看似简单的AI咨询为例，用户的需求远非“产品有什么特点”或“如何退换货”这样的单维问题，靠着“知识库+向量+LLM”可以轻松解决。而实际情况可能是：
再比如：
这类请求融合了向量相似（理解图片、“适合女生”）、关键词（“配送问题”）、数值精确过滤（价格）、位置约束（附近有销售点）、甚至个性化信息（购买过xx产品）等。现在请回想：你正在建设的RAG或者Agent应用能否支持这样的对话？
问题的瓶颈并不在LLM，更不是向量数据库。而是：
企业AI应用的大量场景从来都不是孤立（查询一个财务政策、保修条款、创作一封邮件）的，更多的是与企业的业务紧密联系，这体现在应用、流程与数据多个层面。
数据的多样性是常态
产品有图片、文字、参数、评价、宣传视频 交易有金额、时间、地点、关联商品、满意度 用户有基本信息、行为、社交关系、客户画像
查询的复杂性是必然
语义相似+价格区间+地理位置 图像匹配+库存状态+用户偏好 关键词搜索+时间范围+关联推荐
应用的融合性是趋势
用户的行为会实时影响到AI推荐结果 价格、宣传物料的更新实时反映到AI搜索结果 AI应用的交互信息会实时的影响用户的画像
02
思考：当向量遇到企业级应用的天花板
以上的问题和案例都暴露了当前很多以数据为中心的AI应用的一些核心痛点：
新的AI数据“孤岛”
企业生产中不仅有大量非结构化文本，还有丰富的结构化信息（往往是核心生产数据），它们往往需要关联使用。比如一个企业的“产品”相关的信息：
AI时代，我们擅长将非结构化文本存入向量库，比如用户手册、常见问答等；而产品的价格、类别、库存、参数等留在传统RDBMS/文档数据库。一个显然的问题是：数据同步与维护复杂、低效、代价大，更可能涉及复杂的分布式事务等问题。
多种模态数据的割裂
现有以向量为核心的RAG应用仍然是面向文本为主，在客户提供参考图片或其他非文本时往往捉襟见肘，常见方案是借助图片嵌入模型，并需要开发框架的支持。如果能够将图像、音频、视频等多模向量，与非结构化文本向量统一存储与检索，就可以更方便的实现跨模态关联，减少在应用层的”粘合开发“工作。
单一的检索维度
各种类型数据的割裂带来了检索能力的单一，但真实场景中的检索往往是“混合”型的。在割裂的数据层中实现混合检索，不仅是处理流程上的复杂，更在于不统一的检索接口或查询语言。比如：结构化过滤使用SQL；而到了语义检索则使用向量库的API - 这取决于不同的产品实现。
当前应对混合检索的常见方法：
多种检索方法组合使用。比如先用结构化条件筛选，再用向量做语义匹配与排序（也可以反过来）。这种方法既麻烦且性能低下。
一些优秀的向量库也支持元数据过滤等筛选。比如：查找“xx类别”下语义近似“xxxx”的块。不过更适合轻量级场景，且元数据大小有限制。
完全在应用层实现拼接：分别检索后由应用做合并、去重和排序。
多模态统一数据支持：多种模态的数据可以更一致的存储并创建混合索引。 融合的数据应用能力：多类型索引、混合检索、简化数据同步、提高性能。 简化系统架构与运维：更易于统一的架构设计、性能优化、分布式扩展等。
03
实战：构建一个多模态混合检索Agent
为了更直观地理解“多模态融合AI数据层”的方案与价值，我们来动手构建一个基于真实场景的完整Demo。
【场景设计】
假设一个家居产品（如沙发）的销售企业，在多个渠道部署了AI产品推荐与咨询的机器人。用户可以与AI展开可能的连续对话，比如：
【工具选择】
技术选型如下：
开发框架：LangGraph，用来更灵活的实现AI应用工作流
融合AI数据层：OceanBase（OB Cloud实例）
LLM模型：通义千问
嵌入模型：阿里text-embedding-v3/multimodal-embedding-v1
这里核心的融合数据层选择了国产的分布式数据库OceanBase最新社区版来构建：可以很好的支持结构化、JSON、向量、空间等统一数据的存储，并提供了简洁一致的访问接口（SQL&内部算法函数&API库）。你可以选择使用社区版或OceanBase Cloud上的免费实例来完成Demo（对于生产级应用，企业版应是最佳选择）。
一个融合的AI数据层：不再需要其他独立的RDBMS或向量库。 一个灵活的AI应用层：采用LangGraph框架构建应用工作流，整合检索工具。
混合检索
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
limit3
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设计
客户意图识别：主要目的是分理出复杂的产品推荐/咨询意图以做精准处理。 过滤条件抽取：抽取自然语言中的各种标量和向量过滤条件并结构化输出。
04
扩展：传统方案并未消失
SELECT ......检索的字段...... cosine_distance(pd.chunk_vector, ?) as similarity_scoreFROM products pLEFT 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 NULLHAVING similarity_score <= 0.8 -- 只返回相似度高于某个阈值的结果ORDER BY similarity_score ASCLIMIT 3;
LlamaIndex/LangChain/dify等框架+OceanBase 诸如LlamaIndex/LangChain/Dify这些常见的主流开发框架或平台都支持让OceanBase作为AI数据层的选择，以保留面向未来的高度扩展性。 借助OB Cloud 的PowerRAG数据应用开发平台 如果你使用云端的OceanBase实例，可以借助OceanBase的PowerRAG - 官方一站式的RAG应用低代码开发平台。可以通过简单的知识库上传快速构建属于自己的RAG应用（目前还是预览版，更多的功能在完善中）：
05
结语：一体化的AI数据底座引领未来方向
架构极简与技术栈统一
关系库、全文检索、向量库合一，减少组件数量与跨系统粘合代码；应用仅对接一种协议与驱动、一套工具链，开发、维护与升级的复杂性都得以下降。
单条“语句”实现混合检索
相关性与精确性提升
结合传统数据库索引 + 关键词过滤 + 语义检索的联合计划，兼顾标量匹配与向量相似，减少传统方案里“结果不够 K 条”或“语义相关但条件不满足”的两难。
一致性与数据实时性更好
结构化字段与多模态向量共处同一事务域，可以实现数据更新天然的一致，避免异步同步导致的“新旧不一”和读写延迟等问题（很多场景中会影响用户体验）。
更好的企业级可用性、性能与扩展性
融合AI数据层以传统RDBMS的扩展为主，这恰恰可以让AI应用充分利用传统数据库更成熟的企业级特性：高可用性、高性能、海量数据及扩展性。
最后的思考：融合AI数据底座，传统RDBMS的新机会？
融合AI数据层解决方案由于需要兼顾多种数据形态、负载类型、融合业务，并不是把“向量库 + 关系库 + 搜索引擎”简单拼装，而是要在同一内核内把多种数据与索引类型（标量、全文、JSON、空间、向量）纳入统一的设计与优化器，并在事务、分布式处理、资源调度、性能优化、容灾、治理等多方面实现一体化。
显然，这是一项复杂的系统工程。有更强的企业级IT基建能力的传统RDBMS供应商的长期积累使其更有条件把向量等能力“吃进内核”，实现真正一体化的面向AI的数据“底座”。
或许这也是传统数据库厂商在AI时代转型的必然方向之一，甚至是像OB这样的国产数据库在AI时代弯道超车的重要机会。
