HaishanDB 通过构建多模态融合检索能力实现向量、全文、结构化数据的统一查询。其核心设计理念是将不同类型的数据及其检索能力整合在同一数据引擎内而非依赖外部组件拼接从而为智能体Agent提供高效、一致的数据访问入口。这种能力主要从架构设计、数据共置、查询优化三个维度实现。1. 架构设计一体化融合引擎HaishanDB 采用一体化架构将向量检索、全文搜索、关系型查询、时序处理等能力作为数据库内核的一等公民进行原生支持。这与传统方案中采用独立向量数据库如 Pinecone、搜索引擎如 Elasticsearch与关系数据库如 PostgreSQL进行外部集成的“缝合怪”模式有本质区别。一体化架构的优势在于统一的查询语言与接口开发者无需学习多套查询语法如 SQL、向量相似度搜索 DSL、全文检索 DSL仅通过标准的 SQL 扩展即可完成所有类型的检索操作。统一的优化器与执行引擎查询优化器能够全局考虑不同检索方式的代价生成最优的混合查询执行计划避免跨系统数据搬运带来的性能损耗与一致性风险。统一的事务与一致性保证所有类型的数据操作增删改查均在同一个事务框架下进行确保了跨模态数据操作的 ACID 特性这在智能体需要同时更新结构化业务数据和关联的向量嵌入时至关重要。2. 数据共置统一存储与关联HaishanDB 实现了不同类型数据的物理共置存储。具体而言结构化数据以传统的行/列格式存储于表中。非结构化数据文档、图片等的元数据与向量嵌入同样存储于数据库表内。例如可以将文档的文本内容经过 embedding 模型处理后得到的向量以特定向量数据类型如VECTOR(768)存储在表的某一列中。该文档的原始文件路径、标题、作者等元信息则存储在相邻的列中。全文索引在文本内容列上创建倒排索引支持高效的全文关键词检索。这种数据共置的设计使得一条记录可以同时包含结构化字段、文本字段和向量字段。当执行查询时数据库可以直接在单表内完成跨数据类型的关联与过滤这是外部独立组件方案难以实现的。例如查询“上个月与客户张三相关的所有合同文档及其关键条款摘要”时数据库可以在时间戳字段上进行范围过滤结构化查询。在客户姓名字段上进行等值匹配结构化查询。在合同文档的全文索引中进行关键词检索全文检索。根据摘要的语义向量进行相似度搜索向量检索。这四个步骤可以在一次查询中高效完成并将结果集进行合并与排序。3. 查询优化混合检索与结果融合HaishanDB 的查询引擎核心能力在于对混合检索查询的优化与执行。其流程通常包含以下步骤并通过扩展的 SQL 语法进行表达-- 示例混合检索查询 SELECT c.contract_id, c.customer_name, c.sign_date, v.vector_distance AS semantic_similarity, -- 向量相似度得分 t.fts_rank AS keyword_relevance -- 全文检索相关度得分 FROM contracts c LEFT JOIN LATERAL ( -- 向量相似度搜索查找与“违约风险条款”语义相似的合同摘要 SELECT embedding [0.1, 0.2, ...]::vector AS vector_distance, -- 为余弦相似度操作符 contract_id FROM contract_embeddings e WHERE e.contract_id c.contract_id ORDER BY embedding [0.1, 0.2, ...]::vector LIMIT 1 ) v ON TRUE LEFT JOIN LATERAL ( -- 全文检索在合同正文中搜索“赔偿”、“责任”等关键词 SELECT ts_rank_cd(to_tsvector(zhcfg, full_text), query) AS fts_rank, contract_id FROM contract_texts t WHERE t.contract_id c.contract_id AND to_tsvector(zhcfg, full_text) plainto_tsquery(zhcfg, 赔偿 责任) ) t ON TRUE WHERE c.sign_date 2024-04-01 -- 结构化过滤上个月 AND c.customer_name 张三 -- 结构化过滤客户姓名 AND (v.vector_distance 0.2 OR t.fts_rank 0.05) -- 混合条件语义相似或关键词匹配 ORDER BY -- 综合排序结合业务逻辑对结构化、向量、全文结果进行加权排序 (c.priority * 0.3 (1 - v.vector_distance) * 0.5 t.fts_rank * 0.2) DESC;执行优化策略谓词下推与索引选择优化器会分析WHERE子句中的各类条件将高选择性的结构化过滤条件如customer_name 张三优先下推到存储层利用 B-tree 索引快速缩小数据扫描范围。随后在候选集上应用计算代价较高的向量相似度搜索或全文检索。近似最近邻搜索ANN优化对于向量检索HaishanDB 会利用 HNSWHierarchical Navigable Small World或 IVFInverted File等索引结构来加速高维向量的相似度搜索避免全表扫描带来的性能灾难。结果融合与重排序查询可能返回来自不同检索路径的结果如向量检索的 Top-K 结果和全文检索的 Top-K 结果。HaishanDB 需要根据业务规则如上述 SQL 中的加权公式对它们进行去重、合并与最终排序以返回最符合用户综合意图的结果列表。应用场景与价值这种多模态混合检索能力在 FDE前沿部署工程师交付智能体时价值显著场景一智能客服工单分析客服人员提问“张三上周的投诉邮件怎么处理的”。智能体需要1在用户表中查找“张三”结构化查询2在邮件日志的时间戳中过滤“上周”结构化查询时序3在邮件正文中检索“投诉”全文检索4结合历史处理方案库寻找语义相似的解决方案向量检索。HaishanDB 可在一个查询中完成这些步骤。场景二合同知识库问答法务人员询问“找出所有含有‘不可抗力’条款且甲方为‘某科技公司’的合同”。这需要结合1合同元数据中的“甲方”字段结构化查询2合同全文中的“不可抗力”关键词全文检索3可能还需要对条款段落进行语义理解以判断其是否属于“不可抗力”范畴向量检索。场景三产品图片与描述关联检索市场人员需要“搜索所有包含‘红色’、‘金属’材质且价格低于1000元的产品图片”。这需要1在产品属性表中过滤“价格1000”结构化查询2在描述文本中检索“红色”、“金属”全文检索3在图片特征向量库中搜索视觉上“红色金属质感”的图片向量检索。通过提供这种“一个入口看到所有数据”的能力HaishanDB 使得 FDE 能够将精力集中于智能体本身的业务逻辑编排而非耗费在复杂、脆弱的多系统数据集成工作上显著加速了智能体从概念验证到生产部署的进程 。参考来源云卷云舒当 FDE 带着 Agent 走进客户现场数据底座准备好了吗——HaishanDB技术深度解读