HaishanDB 通过构建多模态融合检索能力，实现向量、全文、结构化数据的统一查询。其核心设计理念是将不同类型的数据及其检索能力整合在同一数据引擎内，而非依赖外部组件拼接，从而为智能体（Agent）提供高效、一致的数据访问入口。这种能力主要从架构设计、数据共置、查询优化三个维度实现。
1. 架构设计：一体化融合引擎
HaishanDB 采用一体化架构，将向量检索、全文搜索、关系型查询、时序处理等能力作为数据库内核的一等公民进行原生支持。这与传统方案中采用独立向量数据库（如 Pinecone）、搜索引擎（如 Elasticsearch）与关系数据库（如 PostgreSQL）进行外部集成的"缝合怪"模式有本质区别。一体化架构的优势在于：
- 统一的查询语言与接口：开发者无需学习多套查询语法（如 SQL、向量相似度搜索 DSL、全文检索 DSL），仅通过标准的 SQL 扩展即可完成所有类型的检索操作。
- 统一的优化器与执行引擎：查询优化器能够全局考虑不同检索方式的代价，生成最优的混合查询执行计划，避免跨系统数据搬运带来的性能损耗与一致性风险。
- 统一的事务与一致性保证：所有类型的数据操作（增删改查）均在同一个事务框架下进行，确保了跨模态数据操作的 ACID 特性，这在智能体需要同时更新结构化业务数据和关联的向量嵌入时至关重要。
2. 数据共置：统一存储与关联
HaishanDB 实现了不同类型数据的物理共置存储。具体而言：
- 结构化数据：以传统的行/列格式存储于表中。
- 非结构化数据（文档、图片等）的元数据与向量嵌入 ：同样存储于数据库表内。例如，可以将文档的文本内容经过 embedding 模型处理后得到的向量，以特定向量数据类型（如
VECTOR(768)）存储在表的某一列中。该文档的原始文件路径、标题、作者等元信息则存储在相邻的列中。 - 全文索引：在文本内容列上创建倒排索引，支持高效的全文关键词检索。
这种数据共置的设计，使得一条记录可以同时包含结构化字段、文本字段和向量字段。当执行查询时，数据库可以直接在单表内完成跨数据类型的关联与过滤，这是外部独立组件方案难以实现的。例如，查询"上个月与客户张三相关的所有合同文档及其关键条款摘要"时，数据库可以：
- 在时间戳字段上进行范围过滤（结构化查询）。
- 在客户姓名字段上进行等值匹配（结构化查询）。
- 在合同文档的全文索引中进行关键词检索（全文检索）。
- 根据摘要的语义向量进行相似度搜索（向量检索）。
这四个步骤可以在一次查询中高效完成，并将结果集进行合并与排序。
3. 查询优化：混合检索与结果融合
HaishanDB 的查询引擎核心能力在于对混合检索查询的优化与执行。其流程通常包含以下步骤，并通过扩展的 SQL 语法进行表达：
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 会利用 HNSW（Hierarchical Navigable Small World）或 IVF（Inverted File）等索引结构来加速高维向量的相似度搜索，避免全表扫描带来的性能灾难。
- 结果融合与重排序：查询可能返回来自不同检索路径的结果（如向量检索的 Top-K 结果和全文检索的 Top-K 结果）。HaishanDB 需要根据业务规则（如上述 SQL 中的加权公式）对它们进行去重、合并与最终排序，以返回最符合用户综合意图的结果列表。
应用场景与价值
这种多模态混合检索能力在 FDE（前沿部署工程师）交付智能体时价值显著：
- 场景一：智能客服工单分析：客服人员提问"张三上周的投诉邮件怎么处理的？"。智能体需要：1）在用户表中查找"张三"（结构化查询）；2）在邮件日志的时间戳中过滤"上周"（结构化查询+时序）；3）在邮件正文中检索"投诉"（全文检索）；4）结合历史处理方案库，寻找语义相似的解决方案（向量检索）。HaishanDB 可在一个查询中完成这些步骤。
- 场景二：合同知识库问答：法务人员询问"找出所有含有'不可抗力'条款且甲方为'某科技公司'的合同"。这需要结合：1）合同元数据中的"甲方"字段（结构化查询）；2）合同全文中的"不可抗力"关键词（全文检索）；3）可能还需要对条款段落进行语义理解以判断其是否属于"不可抗力"范畴（向量检索）。
- 场景三：产品图片与描述关联检索：市场人员需要"搜索所有包含'红色'、'金属'材质且价格低于1000元的产品图片"。这需要：1）在产品属性表中过滤"价格<1000"（结构化查询）；2）在描述文本中检索"红色"、"金属"（全文检索）；3）在图片特征向量库中搜索视觉上"红色金属质感"的图片（向量检索）。
通过提供这种"一个入口，看到所有数据"的能力，HaishanDB 使得 FDE 能够将精力集中于智能体本身的业务逻辑编排，而非耗费在复杂、脆弱的多系统数据集成工作上，显著加速了智能体从概念验证到生产部署的进程 。