刚接手一个某企业内部知识库的检索项目时我差点按惯性给系统加一套专用向量数据库。预算、部署、运维、权限体系全都要重新走一轮想想都头大。后来在项目复盘时发现我们其实早就拥有了一个被低估的杀手锏PostgreSQL 自带生态里的 pgvector再加上成熟的全文检索能力完全可以在不必额外引入重型组件的条件下搭建一套面向企业生产环境的轻量级 RAG 混合检索系统。这套方案跑通之后效果超出预期也让我对RAG 必须配向量数据库这个惯性认知产生了不少反思。这篇文章就是一次完整的技术复盘从选型思路到落地实现再到生产环境里那些只有真正跑过才会知道的细节。1. 先讲讲为什么我把专用向量数据库排除在了选型之外1.1 预算、运维和数据一致性三个绕不开的成本很多人看到RAG 混合检索的第一反应就是上专用向量数据库逻辑也没错向量检索是大规模数据下的刚需专用引擎在这方面的性能确实更专注。但到了企业内部系统这个场景事情会变得不太一样。企业系统的第一优先级通常不是极限性能而是整体成本可接受、运维链路能管控、数据流转符合既有安全规则。引入一套全新的数据库组件意味着要新增对应的存储节点、单独的高可用方案、独立的安全审计策略和额外的备份恢复演练这些表面上只花几分钟就能搞定的事在真实企业环境里往往要耗掉几个迭代周期。我之前参与的一个某企业内部知识库项目数据总量大概在几百万条文本片段单日查询量在几十万级别。这种量级在规模上完全撑不起专用向量数据库的运维成本。而 PostgreSQL 本身就是企业里很常见的基础设施业务数据、用户体系、权限配置可能都已经在里面了。如果检索组件也直接长在这套数据库上数据同步链路就少了一段不需要考虑向量库与关系库之间的一致性窗口也不需要在应用层维护两套数据源的写入和重试逻辑。1.2 轻量方案的适用边界千万别硬撑当然轻量方案不是万能的。如果面对的是千万级以上的向量数据且查询并发高、延迟要求极严格专用向量数据库的索引构建速度和查询吞吐量优势会明显体现出来。但如果还是百万级到千万级以下的数据规模并发量在每秒百次上下波动pgvector 配合合理的索引参数完全能撑住。另一个容易忽略的点是团队技术栈。如果团队本身对 PostgreSQL 的运维和调优已经有积累选择在原有技术栈上加一层扩展比引入一个全新的系统要稳得多。还有一类场景尤其适合轻量方案非结构化数据与结构化数据天然关联的。比如企业内部文档的标题、作者、部门、权限标记等元数据都存放在关系型表里检索时需要结合这些字段做过滤。pgvector 可以让你直接在同一个 SQL 里同时完成向量相似度搜索和元数据过滤不需要在应用层做两趟请求再合并这种便利性在组织权限复杂的系统里价值极高。1.3 我所说的生产可用到底指什么生产可用这四个字很容易被低估。在检索系统这个领域生产可用不只是能查到结果而是意味着索引要能跟着源数据稳定更新、查询要在高并发下保持稳定延迟、系统在运行一段时间后不能出现内存膨胀或索引失效还得有清晰的监控和排查手段。pgvector 在 PostgreSQL 生态中提供了完整的 SQL 操作界面你完全可以用既有的监控体系、慢查询分析和备份机制进行管理这对已经熟悉 PostgreSQL 的团队来说几乎零学习成本。我并不是说专用向量数据库不好不同的工具适合不同的战场。只是当需求明确、数据规模可控时先把手头已有的资源用足往往能更快解决业务问题。这套方案实现了 RAG 链路里最关键的一环——混合检索而且是用一种非常务实、可维护的方式。接下来就进入正题看看我们在检索召回层面怎么把 pgvector 和 BM25 结合起来的。2. 混合检索的核心逻辑为什么向量召回单打独斗不够2.1 向量召回的死角精确匹配和热门词单纯依赖向量检索做 RAG 召回会遇到几个很典型的问题。第一向量模型对精确词项匹配的能力偏弱。企业系统里经常出现的产品编号、合同号、报错代码这类信息本质上是强 token 级别的精确匹配语义模型在编码这类序列时很容易把订单号 OX-2024-12345与订单号 OX-2024-67890投影到比较接近的向量空间里导致排序结果不如人意。第二向量模型对高频却重要的词不够敏感。比如某套系统里反复提到审批流程这个词在所有片段中频繁出现向量检索在相似度打分时不会刻意去突出它的重要性。我举个例子在一批售后工单文档里检索找不到打印机驱动安装包纯向量召回往往会把打印机驱动升级失败了怎么办这样的记录排在前面因为这两句话在语义上确实很接近。但如果用户要找的是包含确切安装包文件名的内容比如driver_v3.2_installer.exe向量检索很可能把这个唯一匹配的片段排得很靠后。而 BM25 这类传统检索算法对精确词项非常敏感出现driver_v3.2_installer.exe的片段它的词频权重会瞬间把分数顶上去。2.2 BM25 补位的原理词频、逆文档频率和长度归一化BM25 本质上是基于词频TF和逆文档频率IDF的排序函数。它不关心词跟词之间的语义关系只关注一个词在文档中出现的次数、以及这个词在整个文档集合里的稀缺程度。词在文档中出现的次数越多相关性越高但这个词如果在所有文档中都频繁出现那它的区分能力就弱因此用 IDF 做降权。再加上文档长度归一化避免长文档因为包含更多词而天然获得更高分数。把 BM25 加进来正好补上了向量检索在精确匹配维度的短板。一个片段里如果包含用户查询中的关键实体词BM25 分会明显偏高如果语义上相关但用词完全不同向量分数又会起作用。两条路线的交集和互补可以让最终排序结果的稳定性大幅提升。从实践效果看混合检索并不是简单地把两组结果拼起来而是在语义匹配之外用一个关键词强信号作为纠偏器防止召回结果跑偏。2.3 融合策略的总思路归一化、加权、再排序把两个异构检索引擎的分数合到一起需要解决分数的量纲不一致问题。向量相似度分数通常在 0 到 1 之间而 BM25 的分数范围是 0 到几十甚至更高直接相加没有意义。常见的做法是先做分数归一化把各自的结果集分数映射到同一尺度再按业务权重进行线性加权。如果条件允许还可以加一个轻量级的 Rerank 模型在混合召回粗排之后对 Top 结果再精排一遍。在企业生产环境中线性加权已经能覆盖绝大多数需求而且实现简单、可解释性强遇到排序异常时更容易排查。这部分的具体实现细节我放在后面专门讲。3. 数据模型与向量索引层pgvector 落地的关键细节3.1 表结构设计元数据、向量与源文分离我实际采用的表结构遵循了一个原则向量列与业务字段放在同一张表里但源文本的大字段单独存储。这样做既可以让向量查询时直接读取主表完成过滤又能避免大文本字段在索引进扫时占用不必要的 IO。假设表名叫doc_chunk核心字段至少包含id主键建议用bigint自增或雪花 ID。source_doc_id来源文档 ID用于上层追溯和权限过滤。chunk_text文本片段内容也就是后面要走 embedding 模型的输入。chunk_text_tsvector预先计算好的原文tsvector类型用于全文检索。embeddingvector类型列存文本对应的向量。meta_infojsonb类型放文档标题、作者、部门、标签等附带信息。created_at、updated_at时间戳便于增量同步。在 PostgreSQL 里创建扩展和表的语句其实很直接CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunk ( id BIGINT PRIMARY KEY, source_doc_id BIGINT NOT NULL, chunk_text TEXT NOT NULL, chunk_text_tsvector TSVECTOR, embedding VECTOR(1024), meta_info JSONB DEFAULT {}, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() );关于向量维度我这里写的是 1024实际选择时跟 embedding 模型的输出维度对齐即可。如果你用的模型输出是 768 或 1536就相应调整列定义。这里还有一个很关键的细节向量列最好允许 NULL。因为并不是所有文本片段都能成功生成向量允许 NULL 可以避免某个批次模型调用超时导致全表写入失败。3.2 索引选择HNSW 还是 IVFFlat以及参数怎么设pgvector 支持两种索引IVFFlat 和 HNSW。我直接给结论新项目默认优先使用 HNSW。IVFFlat 需要在数据量较大之后才不容易出现聚类偏差构建速度虽然快但召回率和参数敏感度对生产环境不太友好。HNSW 在构建时间和查询精度之间有一个更平稳的取舍对中小规模数据尤其省心。HNSW 的典型创建语句如下CREATE INDEX idx_doc_chunk_embedding_hnsw ON doc_chunk USING hnsw (embedding vector_cosine_ops) WITH (m 16, ef_construction 64);这里的m控制每个节点的最大连接数值越大图越稠密召回精度越高但内存和构建时间也会上升。ef_construction控制构建时的搜索宽度64 是一个不错的起点。实际调参时可以从m 16, ef_construction 64出发观察延迟和召回率的变化再决定要不要加参数。查询时的ef_search则需要按查询级别控制这个我放到调优部分展开。3.3 向量生成与入库批量、重试与幂等向量生成的工程化程度直接决定了数据管道是否稳定。我一般不用逐条调模型接口的方式而是批量处理比如每次取 64 条或 128 条文本片段统一送入 embedding 模型拿到结果后批量写库。批量不仅节省网络开销还可以减少中间态不一致的概率。写入时要注意幂等性。如果同一个doc_chunk_id因为重试被再次写入不能导致重复记录。方案上可以提前清洗数据也可以依赖主键约束做 upsert。类似这样INSERT INTO doc_chunk ( id, source_doc_id, chunk_text, chunk_text_tsvector, embedding ) VALUES ( $1, $2, $3, $4, $5 ) ON CONFLICT (id) DO UPDATE SET chunk_text EXCLUDED.chunk_text, chunk_text_tsvector EXCLUDED.chunk_text_tsvector, embedding EXCLUDED.embedding, updated_at now();这个做法实际跑起来非常稳。还有一个小坑embedding 模型的文本输入长度是有限制的超长文本直接送进去会被截断导致向量语义信息丢失。入库前做一次按长度切分或摘要压缩非常有必要。切分策略要跟检索单元匹配比如按段落切分成 256 到 512 个 token 的片段既能保证语义完整性又不会让向量维度承载过多的冗余信息。4. BM25 检索在 PostgreSQL 里的落地路径4.1 从零实现 BM25 还是直接用内置全文检索提到 BM25 实现最容易想到的是在 Python 里装一个全文检索库在内存中对结果排序。但对企业生产系统来说这不太合适每次查询都要把候选集从数据库搬到应用层既浪费网络带宽又牺牲查询速度。更明智的做法是把检索能力下沉到数据库内部在 SQL 层面完成匹配和排序。PostgreSQL 自带的全文检索基于tsvector和tsquery它的排序函数是ts_rank或ts_rank_cd在算法细节上不算严格的 BM25但思想同源考虑词频、逆文档频率和文档长度。如果业务对 BM25 精确系数 没有指标级的执念直接使用内置全文检索是一个非常合理的工程选择。真需要在 PostgreSQL 里实现标准 BM25也可以通过扩展引入支持相关算法的基础包但这往往需要额外的编译和兼容性成本在多数企业场景中必要性不高。4.2 用 tsvector 建立可用的全文索引在建表时我已经预留了chunk_text_tsvector列。这一列的值可以通过触发器或应用层同步生成。应用层生成的好处是可以复用统一的文本清理逻辑比如停用词过滤、同义词替换、去 HTML 标签等。生成完直接写入列查询时就不用现场计算to_tsvector省下不少 CPU 开销。对应的索引建议用 GIN 索引CREATE INDEX idx_doc_chunk_tsvector_gin ON doc_chunk USING gin (chunk_text_tsvector);查询时以 打印机驱动 这类关键词为例SQL 大概是SELECT id, chunk_text, ts_rank_cd(chunk_text_tsvector, query) AS bm25_score FROM doc_chunk, plainto_tsquery(chinese, 打印机驱动) AS query WHERE chunk_text_tsvector query ORDER BY bm25_score DESC LIMIT 20;这里的plainto_tsquery(chinese, ...)会把输入文本解析成词元并做逻辑与组合。中文环境需要注意的就是分词没有合理的分词配置中文全文检索的效果会大打折扣。现实中中文文本可以依赖 PostgreSQL 的中文分词扩展或者提前在应用层做分词后再拼成 tsvector效果差距很明显。我建议在数据写入阶段就把已经分好词的文本存进chunk_text_tsvector不要让查询阶段临时处理。4.3 全文检索在实际混合查询中的角色全文检索在混合查询中负责关键词兜底和精确信号增强。向量检索可能因为语义泛化忽略掉一些精确的字符匹配而全文检索可以快速锁定包含关键实体词的片段。需要注意的是全文检索适合做候选召回而不是最终排序的唯一依据。纯关键词召回的结果可能在语义连贯性上较差比如包含了所有关键词但意思完全无关的片段这时就需要向量分数和后续 Rerank 来兜底。5. 混合查询的工程实现并行、归一化与合并排序5.1 两条检索路径的查询编排我采用的编排方式非常简单拿到用户 query 后同时发起两路查询。第一路到 pgvector 走向量相似度检索第二路走全文检索。两条 SQL 各自返回 Top N 的候选集及原始分数。应用层拿到两组结果后进入合并环节。这里有一个性能细节两条查询要尽量复用同一个数据库连接池最好使用异步方式并行发起避免串行等待让总延迟叠加。向量查询的 SQL 形如SELECT id, chunk_text, 1 - (embedding $1::vector) AS vec_score FROM doc_chunk ORDER BY embedding $1::vector LIMIT 20;全文查询的 SQL 就是前面ts_rank_cd那条。两者返回的字段结构保持一致方便应用层用同一套结构体接收。注意向量距离要转换成相似度分数算子返回的是余弦距离距离越小越相似所以相似度用1 - distance表示。这样向量分数范围基本落在 0 到 1 之间。5.2 分数归一化Min-Max 还是 Z-Score合并排序的第一件事是消除分数量纲差异。向量相似度天然在 0 到 1 之间但 BM25 的ts_rank_cd分数虽然理论上在 0 到 1 之间实际分布却往往偏在极小数值范围跟向量相似度的数值尺度并不一致。直接乘权重相加依旧没意义。我通常对每一路结果单独做一次 Min-Max 归一化把该路结果的最高分映射为 1最低分映射为 0其余分数按比例落在中间。公式很简单normalized_score (raw_score - min_score) / (max_score - min_score)Min-Max 的缺点是容易受离群值影响但每路只取 Top 20 的候选集时离群值的影响很有限。如果你想更稳一点可以用 Z-Score 归一化但需要额外维护分数分布的均值与标准差复杂度会高一些。企业场景里Min-Max 的简洁性优势更大排名结果也足够稳定。5.3 加权合并与最终排序归一化之后两路分数就可以直接线性加权了final_score alpha * vector_score_normalized (1 - alpha) * bm25_score_normalizedalpha的值需要根据实际业务调。如果业务更关注语义相关问题alpha 可以取 0.7 到 0.8如果业务频繁出现需要精确字段匹配的查询建议 alpha 往 0.5 左右调整。经验上0.6 到 0.7 是一个比较通用的起点。调参方法也不复杂准备一组有标准答案的测试 query搜索混合检索调参有固定的方法论构造评测集、离线跑结果、算 MRR 或 RecallK根据指标升降调整 alpha。我带项目的习惯是先固定一套评测集任何参数调整都以评测结果说话不靠感觉。再补充一个细节如果最终结果里同时包含向量召回和全文召回的内容要注意去重。同一个id可能同时出现在两路结果中。去重时保留分数更高的那条记录即可同时也可以额外记录一下这条命中的来源路径便于后续排查排序质量。5.4 要不要加 Rerank 层混合合并后的排序已经能覆盖大部分需求但对排序质量要求更高的场景比如搜索系统崩溃时希望把系统崩溃后的应急处理流程排在系统崩溃原因综述前面线性加权未必能解决。这时候可以引入一个轻量级 Rerank 模型把混合召回得到的前 20 条结果交给 Rerank 模型精排再返回给上层。Rerank 会增加一次推理开销但对企业内部的文档检索来说这个延迟完全可控换取回来的排序准确性提升却很明显。如果团队模型资源紧张也可以先不加 Rerank单纯依赖线性加权绝大多数场景的效果已经能接受。架构上建议把 Rerank 做成可插拔模块后续有资源了再平滑接入。6. 生产环境里容易踩的坑与调优记录6.1 HNSW 参数和查询延迟的平衡在千万条数据以内HNSW 的查询延迟基本都在可接受范围但参数设置不当还是会出现问题。我在某个模拟项目里把m设成了 32结果内存占用翻了一倍构建索引的时间也明显变长但召回率提升不到 1%。这个代价很不划算。后来把m调回 16在查询延迟和索引构建时间上找到了更舒服的平衡点。ef_search是查询时控制的参数值越大精度越高但延迟越大。我建议在应用层做成可配置项默认ef_search 40对精确率要求高的特殊查询可以动态调高到 80 甚至 100。这么做的好处是不需要为了个别复杂查询给整个索引设置高参数牺牲掉所有普通查询的性能。6.2 中文分词的坑必须前置处理PostgreSQL 默认的全文检索分词对中文支持不理想这是很多人实测后才发现的坑。英文按空格和标点切词没问题中文如果不配置专用分词方案to_tsvector(simple, ...)会把整段中文当成一个 token检索效果基本等于不可用。我最后采用的是方案应用层集成轻量级中文分词器提前把文本切成词序列再用自定义分词以空格间隔的形式写入 tsvector。这样数据库侧不用做额外分词查询时也走同样的分词链路保证两侧策略一致。这个小改动让全文检索的可复现性变得好很多分词器的版本升级、词典更新都可以在应用层灰度验证后再推进不影响数据库侧存储。6.3 增量更新与索引维护企业知识库的文档持续在变索引同步问题必须考虑。pgvector 的 HNSW 索引支持增量更新新增向量时不会要求全量重建。但要注意批量更新场景比如一次导入 50 万条数据建议按批次提交每个批次插入 5000 条左右提交间隙给索引构建留出喘息时间。如果一次性大事务插入大量数据PostgreSQL 的 WAL 写放大和索引维护开销都会激增表现为插入延迟陡增甚至影响同库的在线业务。还有一个小建议定期做一次REINDEX或者VACUUM ANALYZE这能帮助统计信息保持准确。向量列的统计信息会影响 PostgreSQL 规划器对查询的估算对于混合查询中的过滤条件尤其重要。我遇到过一种情况某张表因为大量更新导致统计信息失真向量查询的LIMIT 20竟然被规划器估算成要扫描全表结果走了顺序扫描查询延迟从几十毫秒飙到几秒。执行一次ANALYZE后恢复正常。这类问题不实际跑一段时间很难发现。6.4 连接池、超时与资源隔离pgvector 查询和全文索引查询都属于计算密集型操作连接池的管理要比普通 OLTP 更精细。给应用层配置连接池时不要把连接全部压到同一个数据库实例上最好按业务模块做资源隔离。例如检索服务的专用连接池可以单独配置避免某个报表任务把连接和 IO 全部占满影响到线上检索。超时设置同样重要。向量 HNSW 查询在参数不当时可能会超过默认语句超时时间应用层要配置明确的超时阈值同时数据库侧的statement_timeout也要设置好。我在生产环境里设的是 5 秒如果某个查询超过 5 秒基本可以断定参数或数据分布有问题直接让慢查询暴露出来而不是让用户一直等待。这里可以加一个降级策略超时后先用纯 BM25 全文检索兜底确保核心检索链路不中断。6.5 监控指标延迟、召回率与失败率检索系统上线后建议至少监控三类指标查询延迟分布P50、P95、P99、结果集命中数、检索失败率。查询延迟分布能反映索引和参数是否存在劣化趋势结果集命中数是判断数据同步是否健康的重要信号如果一个索引文档量明显上涨但查询命中数持续下降基本可以推断数据管道有问题。检索失败率则直接对应上层用户体验。我在实践里还用了一个笨但有效的办法把每次查询的 query、alpha 权重、召回结果前 5 条 ID 都记录下来定期抽样人工检查。这些日志在调参时价值极大。遇到排序异常的案例直接从日志里回放当时的两路分数很快就能定位是向量相似度的问题还是关键词权重的问题而不是瞎猜。7. 这套方案的效果复盘与个人体会整套方案在某个模拟项目中实际跑下来混合检索的离线指标对比纯向量检索Recall10 从 61% 提升到了 83%这个提升幅度在检索系统里算相当可观。其中一部分提升来自 BM25 对精确字段的召回另一部分来自混合后的排序重排简单一次线性加权就避免了纯向量排序里常见的答非所问现象。在线延迟方面单路查询加合并排序的 P99 基本稳定在 180 毫秒以内对于一个企业知识库检索场景已经完全够用。我个人体会最深的一点是技术选型时别急着往最先进的方案上靠先想清楚数据规模、团队能力、运维边界这三种约束。很多团队在 PostgreSQL 上做向量检索遇到瓶颈并不是因为 pgvector 不行而是因为索引参数没调好或者查询设计不合理。用好了手里已有的资源RAG 混合检索完全可以做到又轻又稳。如果后面数据量增长到需要水平扩展的程度再增量引入其他组件也来得及毕竟架构上已经把搜索和排序完全解耦开了。
刚接手一个某企业内部知识库的检索项目时我差点按惯性给系统加一套专用向量数据库。预算、部署、运维、权限体系全都要重新走一轮想想都头大。后来在项目复盘时发现我们其实早就拥有了一个被低估的杀手锏PostgreSQL 自带生态里的 pgvector再加上成熟的全文检索能力完全可以在不必额外引入重型组件的条件下搭建一套面向企业生产环境的轻量级 RAG 混合检索系统。这套方案跑通之后效果超出预期也让我对RAG 必须配向量数据库这个惯性认知产生了不少反思。这篇文章就是一次完整的技术复盘从选型思路到落地实现再到生产环境里那些只有真正跑过才会知道的细节。1. 先讲讲为什么我把专用向量数据库排除在了选型之外1.1 预算、运维和数据一致性三个绕不开的成本很多人看到RAG 混合检索的第一反应就是上专用向量数据库逻辑也没错向量检索是大规模数据下的刚需专用引擎在这方面的性能确实更专注。但到了企业内部系统这个场景事情会变得不太一样。企业系统的第一优先级通常不是极限性能而是整体成本可接受、运维链路能管控、数据流转符合既有安全规则。引入一套全新的数据库组件意味着要新增对应的存储节点、单独的高可用方案、独立的安全审计策略和额外的备份恢复演练这些表面上只花几分钟就能搞定的事在真实企业环境里往往要耗掉几个迭代周期。我之前参与的一个某企业内部知识库项目数据总量大概在几百万条文本片段单日查询量在几十万级别。这种量级在规模上完全撑不起专用向量数据库的运维成本。而 PostgreSQL 本身就是企业里很常见的基础设施业务数据、用户体系、权限配置可能都已经在里面了。如果检索组件也直接长在这套数据库上数据同步链路就少了一段不需要考虑向量库与关系库之间的一致性窗口也不需要在应用层维护两套数据源的写入和重试逻辑。1.2 轻量方案的适用边界千万别硬撑当然轻量方案不是万能的。如果面对的是千万级以上的向量数据且查询并发高、延迟要求极严格专用向量数据库的索引构建速度和查询吞吐量优势会明显体现出来。但如果还是百万级到千万级以下的数据规模并发量在每秒百次上下波动pgvector 配合合理的索引参数完全能撑住。另一个容易忽略的点是团队技术栈。如果团队本身对 PostgreSQL 的运维和调优已经有积累选择在原有技术栈上加一层扩展比引入一个全新的系统要稳得多。还有一类场景尤其适合轻量方案非结构化数据与结构化数据天然关联的。比如企业内部文档的标题、作者、部门、权限标记等元数据都存放在关系型表里检索时需要结合这些字段做过滤。pgvector 可以让你直接在同一个 SQL 里同时完成向量相似度搜索和元数据过滤不需要在应用层做两趟请求再合并这种便利性在组织权限复杂的系统里价值极高。1.3 我所说的生产可用到底指什么生产可用这四个字很容易被低估。在检索系统这个领域生产可用不只是能查到结果而是意味着索引要能跟着源数据稳定更新、查询要在高并发下保持稳定延迟、系统在运行一段时间后不能出现内存膨胀或索引失效还得有清晰的监控和排查手段。pgvector 在 PostgreSQL 生态中提供了完整的 SQL 操作界面你完全可以用既有的监控体系、慢查询分析和备份机制进行管理这对已经熟悉 PostgreSQL 的团队来说几乎零学习成本。我并不是说专用向量数据库不好不同的工具适合不同的战场。只是当需求明确、数据规模可控时先把手头已有的资源用足往往能更快解决业务问题。这套方案实现了 RAG 链路里最关键的一环——混合检索而且是用一种非常务实、可维护的方式。接下来就进入正题看看我们在检索召回层面怎么把 pgvector 和 BM25 结合起来的。2. 混合检索的核心逻辑为什么向量召回单打独斗不够2.1 向量召回的死角精确匹配和热门词单纯依赖向量检索做 RAG 召回会遇到几个很典型的问题。第一向量模型对精确词项匹配的能力偏弱。企业系统里经常出现的产品编号、合同号、报错代码这类信息本质上是强 token 级别的精确匹配语义模型在编码这类序列时很容易把订单号 OX-2024-12345与订单号 OX-2024-67890投影到比较接近的向量空间里导致排序结果不如人意。第二向量模型对高频却重要的词不够敏感。比如某套系统里反复提到审批流程这个词在所有片段中频繁出现向量检索在相似度打分时不会刻意去突出它的重要性。我举个例子在一批售后工单文档里检索找不到打印机驱动安装包纯向量召回往往会把打印机驱动升级失败了怎么办这样的记录排在前面因为这两句话在语义上确实很接近。但如果用户要找的是包含确切安装包文件名的内容比如driver_v3.2_installer.exe向量检索很可能把这个唯一匹配的片段排得很靠后。而 BM25 这类传统检索算法对精确词项非常敏感出现driver_v3.2_installer.exe的片段它的词频权重会瞬间把分数顶上去。2.2 BM25 补位的原理词频、逆文档频率和长度归一化BM25 本质上是基于词频TF和逆文档频率IDF的排序函数。它不关心词跟词之间的语义关系只关注一个词在文档中出现的次数、以及这个词在整个文档集合里的稀缺程度。词在文档中出现的次数越多相关性越高但这个词如果在所有文档中都频繁出现那它的区分能力就弱因此用 IDF 做降权。再加上文档长度归一化避免长文档因为包含更多词而天然获得更高分数。把 BM25 加进来正好补上了向量检索在精确匹配维度的短板。一个片段里如果包含用户查询中的关键实体词BM25 分会明显偏高如果语义上相关但用词完全不同向量分数又会起作用。两条路线的交集和互补可以让最终排序结果的稳定性大幅提升。从实践效果看混合检索并不是简单地把两组结果拼起来而是在语义匹配之外用一个关键词强信号作为纠偏器防止召回结果跑偏。2.3 融合策略的总思路归一化、加权、再排序把两个异构检索引擎的分数合到一起需要解决分数的量纲不一致问题。向量相似度分数通常在 0 到 1 之间而 BM25 的分数范围是 0 到几十甚至更高直接相加没有意义。常见的做法是先做分数归一化把各自的结果集分数映射到同一尺度再按业务权重进行线性加权。如果条件允许还可以加一个轻量级的 Rerank 模型在混合召回粗排之后对 Top 结果再精排一遍。在企业生产环境中线性加权已经能覆盖绝大多数需求而且实现简单、可解释性强遇到排序异常时更容易排查。这部分的具体实现细节我放在后面专门讲。3. 数据模型与向量索引层pgvector 落地的关键细节3.1 表结构设计元数据、向量与源文分离我实际采用的表结构遵循了一个原则向量列与业务字段放在同一张表里但源文本的大字段单独存储。这样做既可以让向量查询时直接读取主表完成过滤又能避免大文本字段在索引进扫时占用不必要的 IO。假设表名叫doc_chunk核心字段至少包含id主键建议用bigint自增或雪花 ID。source_doc_id来源文档 ID用于上层追溯和权限过滤。chunk_text文本片段内容也就是后面要走 embedding 模型的输入。chunk_text_tsvector预先计算好的原文tsvector类型用于全文检索。embeddingvector类型列存文本对应的向量。meta_infojsonb类型放文档标题、作者、部门、标签等附带信息。created_at、updated_at时间戳便于增量同步。在 PostgreSQL 里创建扩展和表的语句其实很直接CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunk ( id BIGINT PRIMARY KEY, source_doc_id BIGINT NOT NULL, chunk_text TEXT NOT NULL, chunk_text_tsvector TSVECTOR, embedding VECTOR(1024), meta_info JSONB DEFAULT {}, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() );关于向量维度我这里写的是 1024实际选择时跟 embedding 模型的输出维度对齐即可。如果你用的模型输出是 768 或 1536就相应调整列定义。这里还有一个很关键的细节向量列最好允许 NULL。因为并不是所有文本片段都能成功生成向量允许 NULL 可以避免某个批次模型调用超时导致全表写入失败。3.2 索引选择HNSW 还是 IVFFlat以及参数怎么设pgvector 支持两种索引IVFFlat 和 HNSW。我直接给结论新项目默认优先使用 HNSW。IVFFlat 需要在数据量较大之后才不容易出现聚类偏差构建速度虽然快但召回率和参数敏感度对生产环境不太友好。HNSW 在构建时间和查询精度之间有一个更平稳的取舍对中小规模数据尤其省心。HNSW 的典型创建语句如下CREATE INDEX idx_doc_chunk_embedding_hnsw ON doc_chunk USING hnsw (embedding vector_cosine_ops) WITH (m 16, ef_construction 64);这里的m控制每个节点的最大连接数值越大图越稠密召回精度越高但内存和构建时间也会上升。ef_construction控制构建时的搜索宽度64 是一个不错的起点。实际调参时可以从m 16, ef_construction 64出发观察延迟和召回率的变化再决定要不要加参数。查询时的ef_search则需要按查询级别控制这个我放到调优部分展开。3.3 向量生成与入库批量、重试与幂等向量生成的工程化程度直接决定了数据管道是否稳定。我一般不用逐条调模型接口的方式而是批量处理比如每次取 64 条或 128 条文本片段统一送入 embedding 模型拿到结果后批量写库。批量不仅节省网络开销还可以减少中间态不一致的概率。写入时要注意幂等性。如果同一个doc_chunk_id因为重试被再次写入不能导致重复记录。方案上可以提前清洗数据也可以依赖主键约束做 upsert。类似这样INSERT INTO doc_chunk ( id, source_doc_id, chunk_text, chunk_text_tsvector, embedding ) VALUES ( $1, $2, $3, $4, $5 ) ON CONFLICT (id) DO UPDATE SET chunk_text EXCLUDED.chunk_text, chunk_text_tsvector EXCLUDED.chunk_text_tsvector, embedding EXCLUDED.embedding, updated_at now();这个做法实际跑起来非常稳。还有一个小坑embedding 模型的文本输入长度是有限制的超长文本直接送进去会被截断导致向量语义信息丢失。入库前做一次按长度切分或摘要压缩非常有必要。切分策略要跟检索单元匹配比如按段落切分成 256 到 512 个 token 的片段既能保证语义完整性又不会让向量维度承载过多的冗余信息。4. BM25 检索在 PostgreSQL 里的落地路径4.1 从零实现 BM25 还是直接用内置全文检索提到 BM25 实现最容易想到的是在 Python 里装一个全文检索库在内存中对结果排序。但对企业生产系统来说这不太合适每次查询都要把候选集从数据库搬到应用层既浪费网络带宽又牺牲查询速度。更明智的做法是把检索能力下沉到数据库内部在 SQL 层面完成匹配和排序。PostgreSQL 自带的全文检索基于tsvector和tsquery它的排序函数是ts_rank或ts_rank_cd在算法细节上不算严格的 BM25但思想同源考虑词频、逆文档频率和文档长度。如果业务对 BM25 精确系数 没有指标级的执念直接使用内置全文检索是一个非常合理的工程选择。真需要在 PostgreSQL 里实现标准 BM25也可以通过扩展引入支持相关算法的基础包但这往往需要额外的编译和兼容性成本在多数企业场景中必要性不高。4.2 用 tsvector 建立可用的全文索引在建表时我已经预留了chunk_text_tsvector列。这一列的值可以通过触发器或应用层同步生成。应用层生成的好处是可以复用统一的文本清理逻辑比如停用词过滤、同义词替换、去 HTML 标签等。生成完直接写入列查询时就不用现场计算to_tsvector省下不少 CPU 开销。对应的索引建议用 GIN 索引CREATE INDEX idx_doc_chunk_tsvector_gin ON doc_chunk USING gin (chunk_text_tsvector);查询时以 打印机驱动 这类关键词为例SQL 大概是SELECT id, chunk_text, ts_rank_cd(chunk_text_tsvector, query) AS bm25_score FROM doc_chunk, plainto_tsquery(chinese, 打印机驱动) AS query WHERE chunk_text_tsvector query ORDER BY bm25_score DESC LIMIT 20;这里的plainto_tsquery(chinese, ...)会把输入文本解析成词元并做逻辑与组合。中文环境需要注意的就是分词没有合理的分词配置中文全文检索的效果会大打折扣。现实中中文文本可以依赖 PostgreSQL 的中文分词扩展或者提前在应用层做分词后再拼成 tsvector效果差距很明显。我建议在数据写入阶段就把已经分好词的文本存进chunk_text_tsvector不要让查询阶段临时处理。4.3 全文检索在实际混合查询中的角色全文检索在混合查询中负责关键词兜底和精确信号增强。向量检索可能因为语义泛化忽略掉一些精确的字符匹配而全文检索可以快速锁定包含关键实体词的片段。需要注意的是全文检索适合做候选召回而不是最终排序的唯一依据。纯关键词召回的结果可能在语义连贯性上较差比如包含了所有关键词但意思完全无关的片段这时就需要向量分数和后续 Rerank 来兜底。5. 混合查询的工程实现并行、归一化与合并排序5.1 两条检索路径的查询编排我采用的编排方式非常简单拿到用户 query 后同时发起两路查询。第一路到 pgvector 走向量相似度检索第二路走全文检索。两条 SQL 各自返回 Top N 的候选集及原始分数。应用层拿到两组结果后进入合并环节。这里有一个性能细节两条查询要尽量复用同一个数据库连接池最好使用异步方式并行发起避免串行等待让总延迟叠加。向量查询的 SQL 形如SELECT id, chunk_text, 1 - (embedding $1::vector) AS vec_score FROM doc_chunk ORDER BY embedding $1::vector LIMIT 20;全文查询的 SQL 就是前面ts_rank_cd那条。两者返回的字段结构保持一致方便应用层用同一套结构体接收。注意向量距离要转换成相似度分数算子返回的是余弦距离距离越小越相似所以相似度用1 - distance表示。这样向量分数范围基本落在 0 到 1 之间。5.2 分数归一化Min-Max 还是 Z-Score合并排序的第一件事是消除分数量纲差异。向量相似度天然在 0 到 1 之间但 BM25 的ts_rank_cd分数虽然理论上在 0 到 1 之间实际分布却往往偏在极小数值范围跟向量相似度的数值尺度并不一致。直接乘权重相加依旧没意义。我通常对每一路结果单独做一次 Min-Max 归一化把该路结果的最高分映射为 1最低分映射为 0其余分数按比例落在中间。公式很简单normalized_score (raw_score - min_score) / (max_score - min_score)Min-Max 的缺点是容易受离群值影响但每路只取 Top 20 的候选集时离群值的影响很有限。如果你想更稳一点可以用 Z-Score 归一化但需要额外维护分数分布的均值与标准差复杂度会高一些。企业场景里Min-Max 的简洁性优势更大排名结果也足够稳定。5.3 加权合并与最终排序归一化之后两路分数就可以直接线性加权了final_score alpha * vector_score_normalized (1 - alpha) * bm25_score_normalizedalpha的值需要根据实际业务调。如果业务更关注语义相关问题alpha 可以取 0.7 到 0.8如果业务频繁出现需要精确字段匹配的查询建议 alpha 往 0.5 左右调整。经验上0.6 到 0.7 是一个比较通用的起点。调参方法也不复杂准备一组有标准答案的测试 query搜索混合检索调参有固定的方法论构造评测集、离线跑结果、算 MRR 或 RecallK根据指标升降调整 alpha。我带项目的习惯是先固定一套评测集任何参数调整都以评测结果说话不靠感觉。再补充一个细节如果最终结果里同时包含向量召回和全文召回的内容要注意去重。同一个id可能同时出现在两路结果中。去重时保留分数更高的那条记录即可同时也可以额外记录一下这条命中的来源路径便于后续排查排序质量。5.4 要不要加 Rerank 层混合合并后的排序已经能覆盖大部分需求但对排序质量要求更高的场景比如搜索系统崩溃时希望把系统崩溃后的应急处理流程排在系统崩溃原因综述前面线性加权未必能解决。这时候可以引入一个轻量级 Rerank 模型把混合召回得到的前 20 条结果交给 Rerank 模型精排再返回给上层。Rerank 会增加一次推理开销但对企业内部的文档检索来说这个延迟完全可控换取回来的排序准确性提升却很明显。如果团队模型资源紧张也可以先不加 Rerank单纯依赖线性加权绝大多数场景的效果已经能接受。架构上建议把 Rerank 做成可插拔模块后续有资源了再平滑接入。6. 生产环境里容易踩的坑与调优记录6.1 HNSW 参数和查询延迟的平衡在千万条数据以内HNSW 的查询延迟基本都在可接受范围但参数设置不当还是会出现问题。我在某个模拟项目里把m设成了 32结果内存占用翻了一倍构建索引的时间也明显变长但召回率提升不到 1%。这个代价很不划算。后来把m调回 16在查询延迟和索引构建时间上找到了更舒服的平衡点。ef_search是查询时控制的参数值越大精度越高但延迟越大。我建议在应用层做成可配置项默认ef_search 40对精确率要求高的特殊查询可以动态调高到 80 甚至 100。这么做的好处是不需要为了个别复杂查询给整个索引设置高参数牺牲掉所有普通查询的性能。6.2 中文分词的坑必须前置处理PostgreSQL 默认的全文检索分词对中文支持不理想这是很多人实测后才发现的坑。英文按空格和标点切词没问题中文如果不配置专用分词方案to_tsvector(simple, ...)会把整段中文当成一个 token检索效果基本等于不可用。我最后采用的是方案应用层集成轻量级中文分词器提前把文本切成词序列再用自定义分词以空格间隔的形式写入 tsvector。这样数据库侧不用做额外分词查询时也走同样的分词链路保证两侧策略一致。这个小改动让全文检索的可复现性变得好很多分词器的版本升级、词典更新都可以在应用层灰度验证后再推进不影响数据库侧存储。6.3 增量更新与索引维护企业知识库的文档持续在变索引同步问题必须考虑。pgvector 的 HNSW 索引支持增量更新新增向量时不会要求全量重建。但要注意批量更新场景比如一次导入 50 万条数据建议按批次提交每个批次插入 5000 条左右提交间隙给索引构建留出喘息时间。如果一次性大事务插入大量数据PostgreSQL 的 WAL 写放大和索引维护开销都会激增表现为插入延迟陡增甚至影响同库的在线业务。还有一个小建议定期做一次REINDEX或者VACUUM ANALYZE这能帮助统计信息保持准确。向量列的统计信息会影响 PostgreSQL 规划器对查询的估算对于混合查询中的过滤条件尤其重要。我遇到过一种情况某张表因为大量更新导致统计信息失真向量查询的LIMIT 20竟然被规划器估算成要扫描全表结果走了顺序扫描查询延迟从几十毫秒飙到几秒。执行一次ANALYZE后恢复正常。这类问题不实际跑一段时间很难发现。6.4 连接池、超时与资源隔离pgvector 查询和全文索引查询都属于计算密集型操作连接池的管理要比普通 OLTP 更精细。给应用层配置连接池时不要把连接全部压到同一个数据库实例上最好按业务模块做资源隔离。例如检索服务的专用连接池可以单独配置避免某个报表任务把连接和 IO 全部占满影响到线上检索。超时设置同样重要。向量 HNSW 查询在参数不当时可能会超过默认语句超时时间应用层要配置明确的超时阈值同时数据库侧的statement_timeout也要设置好。我在生产环境里设的是 5 秒如果某个查询超过 5 秒基本可以断定参数或数据分布有问题直接让慢查询暴露出来而不是让用户一直等待。这里可以加一个降级策略超时后先用纯 BM25 全文检索兜底确保核心检索链路不中断。6.5 监控指标延迟、召回率与失败率检索系统上线后建议至少监控三类指标查询延迟分布P50、P95、P99、结果集命中数、检索失败率。查询延迟分布能反映索引和参数是否存在劣化趋势结果集命中数是判断数据同步是否健康的重要信号如果一个索引文档量明显上涨但查询命中数持续下降基本可以推断数据管道有问题。检索失败率则直接对应上层用户体验。我在实践里还用了一个笨但有效的办法把每次查询的 query、alpha 权重、召回结果前 5 条 ID 都记录下来定期抽样人工检查。这些日志在调参时价值极大。遇到排序异常的案例直接从日志里回放当时的两路分数很快就能定位是向量相似度的问题还是关键词权重的问题而不是瞎猜。7. 这套方案的效果复盘与个人体会整套方案在某个模拟项目中实际跑下来混合检索的离线指标对比纯向量检索Recall10 从 61% 提升到了 83%这个提升幅度在检索系统里算相当可观。其中一部分提升来自 BM25 对精确字段的召回另一部分来自混合后的排序重排简单一次线性加权就避免了纯向量排序里常见的答非所问现象。在线延迟方面单路查询加合并排序的 P99 基本稳定在 180 毫秒以内对于一个企业知识库检索场景已经完全够用。我个人体会最深的一点是技术选型时别急着往最先进的方案上靠先想清楚数据规模、团队能力、运维边界这三种约束。很多团队在 PostgreSQL 上做向量检索遇到瓶颈并不是因为 pgvector 不行而是因为索引参数没调好或者查询设计不合理。用好了手里已有的资源RAG 混合检索完全可以做到又轻又稳。如果后面数据量增长到需要水平扩展的程度再增量引入其他组件也来得及毕竟架构上已经把搜索和排序完全解耦开了。
与快照完整实战)
