如果你过去两三年一直在跟“检索分析”这两类需求打交道应该能明显感觉到AI应用大规模落地之后数据平台的玩法彻底变了。以前做实时数仓无非是把日志、交易、用户行为倒进来跑跑指标出出报表现在客户开口就是帮我把商品库做成多模态搜索支持图片、文本、标签联合查询帮我做知识库的智能问答答案里还要带数据依据最好再让AI能自己看报表、写分析结论。这些需求堆到一起传统架构就顶不住了一个系统负责结构化分析一个系统负责全文检索一个系统再负责向量召回中间靠数据同步任务串起来链路长、口径乱、延迟高。Hologres这套“一站式 Agentic 多模态检索分析平台”的思路本质上是把这些问题收敛到一个统一入口用一份数据、一套引擎同时支撑结构化分析、全文检索、向量检索再交给 AI Agent 去编排调用。这篇文章我就以自己的实际搭建经历为主线聊聊为什么选这条路、多模态数据怎么建模、混合查询怎么做、Agentic 工作流怎么接进去以及过程中踩过的坑。内容偏实操适合正在做知识库、多模态搜索、企业级 AI 应用的数据工程师和算法工程师也适合准备从“多套系统拼装”转向“统一平台”的团队参考。1. 整体设计与思路拆解为什么要把检索和分析焊在一起1.1 旧方案的两条路走起来都不够顺手先还原一个典型场景某个电商团队要做商品多模态搜索。用户上传一张衣服的图片希望系统返回类似款式同时能按价格区间、品牌、上架时间过滤再统计一下某个类目下有多少商品、平均折扣率是多少。这个需求拆开来看既有点查、又有聚合分析既有图像向量的相似度检索又有结构化属性的精确过滤。用传统架构解决一般两条路。第一条路是“ES 数仓”组合ES 负责关键词和部分向量检索数仓负责指标分析两边通过定时任务同步数据。问题在于ES 的聚合分析能力远不如专业数仓复杂 join 和漏斗计算写起来很难受数据同步又有延迟经常出现 ES 里的商品和数仓里的价格不一致。第二条路是“向量数据库 传统数据库”组合向量库做召回传统库做过滤和聚合业务层自己写代码把两边的结果拼起来。这条路更麻烦你得处理两个数据源的一致性、双写的原子性、还有查询时的连接延迟。所以我的判断很直接如果数据平台能在一张表里同时搞定行存点查、列存分析、全文检索和向量检索那么上面这些复杂场景就变成了几个 SQL 的事。这也是 Hologres 这类 HSAPHybrid 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_vecvec, 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 从“检索增强”到“决策增强”让平台真正 AgenticRAG检索增强生成大家已经很熟了把查询变成向量召回相关片段拼进 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 条件和索引设计里。