如果你过去两三年一直在跟“检索+分析”这两类需求打交道，应该能明显感觉到，AI应用大规模落地之后，数据平台的玩法彻底变了。以前做实时数仓，无非是把日志、交易、用户行为倒进来，跑跑指标，出出报表；现在客户开口就是：帮我把商品库做成多模态搜索，支持图片、文本、标签联合查询；帮我做知识库的智能问答，答案里还要带数据依据；最好再让AI能自己看报表、写分析结论。
这些需求堆到一起，传统架构就顶不住了：一个系统负责结构化分析，一个系统负责全文检索，一个系统再负责向量召回，中间靠数据同步任务串起来，链路长、口径乱、延迟高。Hologres这套“一站式 Agentic 多模态检索分析平台”的思路，本质上是把这些问题收敛到一个统一入口：用一份数据、一套引擎，同时支撑结构化分析、全文检索、向量检索，再交给 AI Agent 去编排调用。
这篇文章我就以自己的实际搭建经历为主线，聊聊为什么选这条路、多模态数据怎么建模、混合查询怎么做、Agentic 工作流怎么接进去，以及过程中踩过的坑。内容偏实操，适合正在做知识库、多模态搜索、企业级 AI 应用的数据工程师和算法工程师，也适合准备从“多套系统拼装”转向“统一平台”的团队参考。
1. 整体设计与思路拆解：为什么要把检索和分析焊在一起
1.1 旧方案的两条路，走起来都不够顺手
先还原一个典型场景：某个电商团队要做商品多模态搜索。用户上传一张衣服的图片，希望系统返回类似款式，同时能按价格区间、品牌、上架时间过滤，再统计一下某个类目下有多少商品、平均折扣率是多少。这个需求拆开来看，既有点查、又有聚合分析，既有图像向量的相似度检索，又有结构化属性的精确过滤。
用传统架构解决，一般两条路。第一条路是“ES + 数仓”组合：ES 负责关键词和部分向量检索，数仓负责指标分析，两边通过定时任务同步数据。问题在于：ES 的聚合分析能力远不如专业数仓，复杂 join 和漏斗计算写起来很难受；数据同步又有延迟，经常出现 ES 里的商品和数仓里的价格不一致。第二条路是“向量数据库 + 传统数据库”组合：向量库做召回，传统库做过滤和聚合，业务层自己写代码把两边的结果拼起来。这条路更麻烦，你得处理两个数据源的一致性、双写的原子性、还有查询时的连接延迟。
所以我的判断很直接：如果数据平台能在一张表里同时搞定行存点查、列存分析、全文检索和向量检索，那么上面这些复杂场景就变成了几个 SQL 的事。这也是 Hologres 这类 HSAP（Hybrid Serving/Analytical Processing）引擎的价值所在——它不是单纯把 OLTP 和 OLAP 揉在一起，而是在存储和查询引擎层面，让同一条 SQL 可以自由组合多种访问模式。
1.2 Hologres 为什么适合做这个“统一底座”
Hologres 本身是阿里云上的实时数仓，兼容 PostgreSQL 生态，这一点在我实际用下来非常关键。团队里的同学基本都会写 SQL，接 PostgreSQL 的工具链也现成，不用从头学一套新语法。而在检索分析这个场景里，它有几个特性是我认为最核心的：
- 行存列存共存于一张表：点查走行存，分析扫描走列存，引擎会自动选择最佳访问路径。
- 内置全文检索能力：基于 ZSearch 的全文索引，可以直接对文本字段做分词、匹配、相关性打分。
- 原生向量检索：通过 Proxima 向量引擎，支持 HNSW、IVF 等算法，SQL 里可以直接做相似度排序。
- 在线服务与分析一体：数据写入后即可查询，延迟可以压到毫秒级，又支持复杂分析，不需要额外引入 OLAP 引擎。
- 与数据生态无缝衔接：Flink、DataWorks、PAI、大模型服务平台都能直接读写，适合做实时链路。
这些能力单独拿出来，其他产品也有；但能在一套系统里以 SQL 为统一接口组合使用，这是我选择它的核心理由。尤其在 Agentic 场景下，AI Agent 需要调用的“工具”越少越好，如果检索、分析、查明细都通过一个 Hologres 工具完成，工作流的稳定性和可控性都会大幅提升。
2. 核心细节解析：多模态数据如何统一建模与检索
2.1 让不同模态的数据落进同一张“宽表”
多模态数据听起来复杂，图片、视频、音频、文本、结构化标签，各有各的格式。但落到工程实现上，核心就一句话：把非结构化数据特征化，把结构化数据字段化，最后统一放进一张可检索的宽表。
我这里常用的表结构长这样：
CREATE TABLE multimodal_assets ( asset_id BIGINT PRIMARY KEY, asset_type TEXT NOT NULL, -- image / video / text / audio title TEXT, content TEXT, -- 原始文本或OCR/ASR结果 tags TEXT[], -- 标签数组 category_path TEXT, -- 类目路径 status TEXT, owner_id BIGINT, embedding float4[], -- 多模态统一向量 meta JSONB, -- 扩展属性 update_time TIMESTAMPTZ DEFAULT now() );这张表的关键在于embedding字段。无论原始数据是图片、文本还是音视频，我们先通过对应的特征提取模型生成一个固定维度的向量，再把这个向量和结构化字段一起落到同一行。这样做的最大好处是：后续所有查询逻辑都变得非常统一——你要找“相似内容”就是做向量距离排序，你要做“精确圈选”就是加 WHERE 条件，两者可以组合在同一条 SQL 里。
需要提醒的是，float4[]只是我习惯的写法，Hologres 向量字段也支持vector等类型，具体看实例版本。建表时最关键是确定向量维度，这里建议提前和算法团队对齐：如果后面换了 embedding 模型导致维度变化，重建索引的成本很高。
2.2 三类索引的协同：B-tree、全文索引、向量索引
有了宽表，下一步就是建索引。我把这个环节叫“三条腿走路”，缺一条都会瘸。
第一条腿是 B-tree 索引，负责结构化字段的精确过滤。最常见的场景是：查询某个用户的资产列表、按状态过滤、按时间范围圈选。这类查询对吞吐要求高，Hologres 的主键和普通索引能直接走到行存点查，毫秒级返回。
第二条腿是全文索引，负责文本语义搜索和关键词匹配。比如用户搜“蓝色连衣裙”，我们希望系统能匹配到“蓝色的裙子”而不是精确依赖完整字符串。全文索引会对指定的文本列做分词，并维护倒排结构，查询时用ts_rank之类的相关性函数打分。Hologres 里配置全文索引大概是这样的形式：
CALL set_table_property('multimodal_assets', 'zsearch_columns', 'title,content,tags');具体参数名因版本而异，但思路一致：把需要被全文搜索的列交给索引引擎。
第三条腿是向量索引，负责相似度召回。基于 Proxima 引擎，支持 HNSW 和 IVF 两类算法。HNSW 召回质量高、查询快，但构建耗时和内存占用更大；IVF 构建快，但查询精度略低，需要通过增大 nprobe 来弥补。配置向量索引时，我一般会显式指定距离算法：
CALL set_table_property('multimodal_assets', 'proxima_vectors', '{"embedding":{"dimension":1024,"algorithm":"HNSW","distance_method":"SquaredEuclidean"}}');这里的关键决策是索引粒度：不要对整张表的所有数据建立一个全局向量索引，那样会让索引体积巨大、写入变慢。更好的做法是，在查询时先用结构化字段把候选集缩小，再在候选集上做向量相似度计算。Hologres 的优化器会结合 WHERE 条件和向量索引路径，你要做的就是保证过滤字段上有索引。
2.3 多模态融合的核心：统一向量 + 属性过滤 + 融合排序
多模态检索最容易翻车的地方，不是向量召回本身，而是“融合”环节。以商品检索为例，用户上传一张图片，我们希望返回的图片既“长得像”，又在价格、品牌、库存等业务属性上满足条件。单纯的向量检索会把相似的商品都拉出来，但可能包含高不可攀的奢侈品或者已经下架的款式；单纯的属性过滤又失去“以图搜图”的意义。
我实践的方案是“三级漏斗”：第一级用结构化属性做硬过滤，比如价格区间、类目、状态，把数据量直接缩到可控范围；第二级在过滤后的数据上做向量近似召回，取 TopK；第三级做重排，把业务规则和向量相似度加权融合，得到最终排序。
融合排序的公式不需要复杂，常用的做法是加权调和：
SELECT asset_id, title, 0.7 * (1 - (embedding <=> :query_vec)) + 0.3 * ts_rank(...) AS final_score FROM multimodal_assets WHERE category_path = :cat AND price BETWEEN :min AND :max AND status = 'on_sale' ORDER BY embedding <=> :query_vec LIMIT 50;实际项目中，权重系数我很少一开始就定死。一般先让算法同事用离线评测集调一轮，再上 A/B 看线上点击数据。指数级的调权不如直接做一个粗排+精排的两阶段：粗排用向量距离过滤出几百个候选，精排环节再结合更多业务特征用模型打分。Hologres 在这个链路里承担的是“粗排+属性硬过滤”的角色，这也是它最擅长的部分。
3. 实操过程：从零搭一套 Agentic 多模态检索分析平台
3.1 数据准备与实时写入链路
我拿一个实际做过的“企业知识库+业务数据分析”平台来举例。这个平台要支持三类查询：一是根据自然语言提问检索内部文档；二是用户可以上传截图，系统识别图里的表格再分析；三是直接问“上个月华东区销售额环比变化”这类指标问题。三条链路背后，都需要一个统一的数据底座。
数据准备环节，最重要的是打通实时链路。Hologres 支持通过 Flink CDC 同步业务库数据，也支持直接写入。我给文档类数据设计了这样一条链路：文档解析服务（负责文本去重、版面解析）→ 生成标题、正文、标签 → embedding 模型生成向量 → 写入 Hologres。对于业务指标数据，则从 Kafka 通过 Flink 实时计算后写入对应宽表。
写入时需要注意两个坑：第一，批量写入时控制 batch size，不要一次性塞几百万行，容易出现内存压力；第二，embedding 生成过程非常耗时，建议作为异步任务做，不要阻塞主链路。我踩过最狠的坑是，同步脚本在写入向量字段时格式不统一，导致部分数据向量维度不对，查询时直接报错。后来在写入前加了一层 schema 校验，问题才彻底解决。
3.2 混合查询：把 SQL 当成“检索总编排器”
平台的核心能力，就是把多模态检索和结构化分析放到同一条 SQL 里。这里我分享几个实际用到的查询模式。
第一种是“以图搜图+属性过滤”。用户上传了一张商品图，我们先用视觉模型生成 embedding，再执行下面的查询：
SELECT asset_id, title, tags, price, shop_name, 1 - (embedding <=> :query_vec) AS similarity FROM products WHERE category_id = :category_id AND price BETWEEN :min_price AND :max_price AND status = 1 ORDER BY embedding <=> :query_vec LIMIT 20;这个 SQL 看起来简单，但内部执行路径是：先走 B-tree 索引把category_id、price、status过滤掉，再在剩余数据上做向量排序。没有第一层过滤的话，全表几百万条向量做距离计算，延迟很难看。
第二种是“关键词+向量混合召回”。用户问“哪里有介绍网络超时排查的文档”，我们既希望匹配到包含“网络超时”“排查”这些词的文档，又希望找到语义相似但用词不同的文档。于是我把全文检索和向量检索的结果做融合排序：
SELECT doc_id, title, (0.5 * ts_rank(c.cf, to_tsquery('网络 & 超时')) + 0.5 * (1 - (embedding <=> :query_vec))) AS score FROM docs c WHERE c.cf @@ to_tsquery('网络 & 超时') OR embedding <=> :query_vec < 0.6 ORDER BY score DESC LIMIT 10;这里只展示思路，具体相关函数名以实际版本为准。核心是：碎片化的多个条件，通过 SQL 拼接成一个整体请求，数据库自己决定哪些条件走索引、哪些做过滤、哪些做排序。
第三种是“检索后分析”。不仅要找到相似案例，还要统计这些案例的分布。这个用一条 SQL 也能完成：
SELECT category_path, count(*) AS cnt, avg(resolve_time) AS avg_resolve_time FROM service_tickets WHERE status = 'closed' AND embedding <=> :query_vec < 0.5 GROUP BY category_path ORDER BY cnt DESC;这就是 Hologres 和其他专用向量数据库最大的区别：它不会让你把“召回”和“分析”拆成两次调用，而是直接在检索结果之上做聚合。
3.3 接入 Agentic 工作流：让 Agent 学会“先查后答”
Agentic 检索分析的核心，不是简单给大模型加一个 RAG 接口，而是让 Agent 能够自主理解用户的真实意图，再决定调用哪些数据工具、如何组合这些工具、最终给出带依据的回答。
我实现的方式是 Function Calling 模式。把 Hologres 封装成若干个工具的集合：
search_multimodal(query_text, filters)：多模态检索，返回相似内容列表query_metrics(sql)：执行指标分析 SQL，返回表格结果get_document_detail(doc_id)：获取文档详情，用于生成回答时的引用
然后让大模型根据用户问题选择调用哪个工具。比如用户问“帮我找一些含棉量高的夏季连衣裙，顺便统计一下这类商品的平均价格”，大模型会先拆解为两个子任务：检索商品列表 + 统计平均价格。然后分别调用两个工具，最后把结果汇总成自然语言回答。
Python 侧的核心逻辑类似下面这样，我用伪代码展示关键结构：
def agent_handle(user_query): intent = llm.parse_intent(user_query) if intent == "search": vec = embedding_model.encode(user_query) rows = holowrapper.search_multimodal(query_vec=vec, filters=...) return llm.answer_with_context(user_query, rows) elif intent == "analysis": sql = llm.text2sql(user_query, schema_prompt) df = holowrapper.query(sql) return llm.interpret_result(user_query, df)这里有一个非常容易被忽略的细节：给 LLM 的结构化查询指令，必须限制表名、字段名和 WHERE 条件边界。大模型生成的 SQL 很容易出现“幻觉字段”，或者条件写得过于宽松导致扫描全表。我的做法是：为 Agent 提供一个“受控查询视图”，只暴露必要的表和字段，同时在 SQL 执行前做一层简单校验（是否包含非法表名、是否缺少必填过滤条件），不合格就直接拒绝执行并要求模型重新生成。
3.4 从“检索增强”到“决策增强”：让平台真正 Agentic
RAG（检索增强生成）大家已经很熟了：把查询变成向量，召回相关片段，拼进 Prompt，让模型回答。但 Agentic 场景下，检索本身的策略是动态的。同一个问题，可能第一次需要宽松召回，第二次就需要精确过滤。这时候，检索参数的决策权不能全部交给预设规则，而是交给 Agent 自己。
我在实践里让 Hologres 承担了“可编程数据上下文”的角色。Agent 会根据对话历史判断：用户是想要几个具体例子，还是想要一份宏观统计；是只需要文本信息，还是需要图片和表格。随后动态生成不同的检索参数：TopK 调大调小、是否启用时间过滤、是否做分组聚合、排序权重如何设置。Hologres 的 SQL 天然适合这种动态拼接，Agent 每产生一组参数，就能转换成一次查询请求。
另外，Agentic 应用的安全边界问题也值得拿出来说。业界近几年针对 Agent 应用的 OWASP Top 10 讨论很多，核心风险包括提示注入、敏感数据泄露、工具权限失控等。落到数据平台这层，我的建议是：Agent 所使用的数据库账号必须有独立的 Row-Level Security 策略，且只能访问经过脱敏的视图，不能让 Agent 直接拥有原始表的全部权限。宁可每次查询多包一层视图，也不要把底层表直接暴露给大模型。
4. 性能优化与调优实录
4.1 索引选型：HNSW 还是 IVF？先看数据量和写入频率
向量索引的选型，直接影响查询延迟和写入吞吐。HNSW 在查询质量和速度上表现最好，适合数据量几百万到千万级、查询频繁的场景；但它的索引构建成本高，数据持续高频写入时，索引更新可能会成为瓶颈。IVF 的构建速度快得多，写入友好，但查询精度下降，而且如果数据分布不均匀，某些桶的数据量过大会拖慢召回速度。
我在实际项目中的经验是：以查询延迟为首要指标、数据量在千万以下、写入可以批量异步处理，优先选 HNSW；如果写入是实时高频的，且对召回精度要求不是极致，可以用 IVF 配合调大 nprobe。另外，Hologres 的分区策略对索引也有影响，尽量把向量索引建立在分区子表上，避免跨分区的大范围扫描。
4.2 查询链路优化：过滤先行，召回后置
很多人写多模态检索 SQL 时，习惯一上来就ORDER BY embedding <=> :query_vec LIMIT 10，把向量排序当成核心，其他字段的过滤条件反而写得比较宽松。这个习惯在数据量小的时候没问题，数据量一旦过了百万，查询延迟会急剧上升。
我的调优顺序是：
- 先通过结构化字段缩小候选集。查看执行计划，确认过滤条件走到了索引。如果没有索引，就为高频过滤字段补充 B-tree 索引。
- 再检查向量距离计算的范围。Hologres 支持通过 WHERE 条件给向量距离加阈值，比如
embedding <=> :query_vec < 0.8，这样能提前裁剪掉大量不相关向量。 - 最后才做排序和 TopK。把
LIMIT设置到合理范围，不用一次性拉几千条。
还有一种高频场景是“分组 TopK”，比如对每个类目返回最相似的 5 个商品。这种情况应该用窗口函数：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY embedding <=> :query_vec) AS rn FROM products WHERE status = 1 ) t WHERE rn <= 5;这个查询在数据量较大时对资源消耗很敏感，建议配合分区裁剪使用，别让每个分组都扫描全表。
4.3 实时链路与写入性能的平衡
多模态平台最常见的写入形态是：图片/文本先经过模型推理生成 embedding，然后批量写入 Hologres。这个链路里最慢的往往是模型推理，而不是数据库写入。所以工程上要做的是“异步化 + 缓冲批写”。
我常用的方案是：模型推理服务产出的结果先发到 Kafka，由 Flink 做攒批，攒够一定条数或到时间窗口再批量写入 Hologres。这样 DB 的写入压力非常平稳。如果直接用 API 逐条写入，每秒写入量上不去不说，还容易因为连接数过多引发限流。
另外，Hologres 写入时要注意表属性设置，比如是否开启分布式写入、是否设置合适的 Shard 数。Shard 数太少会导致写入和查询争抢资源；Shard 数太多又会增加元数据开销。这个值我一般参考实例的规格，按照单 Shard 处理 100-300 万行数据的经验来预估，先给个中间值，再根据实际监控调整。
5. 常见问题与排查技巧实录
5.1 召回结果不准：先别急着换模型，检查索引和过滤条件
多模态检索结果不理想，我的排查顺序是这样的：
- 先确认粗排阶段没有被硬过滤条件误伤。比如
status = 1过滤掉了原本相似度很高的数据，导致召回结果整体偏移。 - 再检查向量索引的召回参数，比如 HNSW 的
ef_search是否过小。ef_search太小时，图搜索会过早收敛，漏掉真正的近邻。 - 接下来确认 embedding 模型本身有没有对齐训练目标。如果业务是时尚商品检索，用通用图文模型做 embedding，效果大概率不如用商品图片微调过的模型。
排除完这三层，才需要考虑调整排序权重或换模型。
5.2 SQL 慢查询：定位是卡在索引、join 还是向量计算
遇到慢查询，我在 Hologres 里会先看执行计划，确认每个算子的耗时占比。最常见的慢查询原因有三个：全表扫描、大表 join、向量距离计算没有裁剪数据。
全表扫描的解法是补索引；大表 join 的解法是调整表为哈希分布，让 join 在本地完成，避免数据重分布；向量距离计算没裁剪的解法是增加 WHERE 过滤条件和距离阈值。我在写 SQL 时养成了一个习惯：每次写检索 SQL 都尽量带上至少一个“硬过滤条件”，哪怕这个条件只是update_time > now() - interval '30 days'，也能把扫描范围缩小很多。
5.3 Agent 生成错误 SQL：用受控视图和预校验拦截
Agent 直接生成 SQL 是风险很高的事情。我见过最离谱的一次，是模型生成了一条没有 WHERE 条件的全表聚合，把实例的资源直接打满。后来我在中间加了一层“SQL 安全网关”，规则包括：
- 只允许查询白名单预注册的视图，不允许直接查询底层物理表。
- 必须包含至少一个过滤条件，且过滤字段必须在索引列表里。
- 限制单次查询返回行数，比如强制
LIMIT 200。 - 对分析型 SQL 设置超时时间，超时自动终止。
这套防线加上之后，Agent 的查询稳定性明显提升。即便模型生成了次优 SQL，也不会对整个实例造成严重影响。
5.4 数据一致性与多模态之间的“时间差”问题
多模态数据里，文本、图片、标签往往来自不同的处理链路，写入时间有先后。比如图片先落库，但标签和向量还在异步生成中，这时候检索就可能查到“没有向量”的残缺数据。
我的处理方式是在表里加一个feature_status字段，标记该行数据是否已完成全部特征生成。检索时默认只查feature_status = 'complete'的行，后台异步任务处理完成后更新状态。这个字段搭配 TTL 还能做数据生命周期管理，避免无效数据长期占用存储。
6. 写在最后的一些心得体会
做这套平台花了我不少时间，但最有价值的收获不是“某条 SQL 写得快”，而是想清楚了一个问题：AI 时代的数据平台，不应该再把检索和分析分成两套系统，而是应该把数据本身做厚，把查询接口做薄。
Hologres 这套方案让我最满意的地方，不是某个单独的功能点多么强大，而是它能让“结构化过滤、全文检索、向量召回、实时分析”发生在同一个数据上下文里。Agent 不需要在多个系统之间来回搬运数据，一条 SQL 就能把用户模糊的提问落地成精确的检索或分析动作。
最后再分享一个小技巧：如果你正在做多模态检索平台，不要把精力全部押在“用哪个 embedding 模型”上。模型迭代确实很重要，但更大红利往往来自数据质量和查询编排。把元数据补全、把过滤字段建好索引、把融合排序的权重调对，哪怕用一个通用 embedding 模型，也能达到让人满意的效果。数据平台的价值，永远有一半藏在那些不起眼的 WHERE 条件和索引设计里。
