RAG实战：用pgvector解决知识库问答的“对齐”难题

我做过好几个RAG项目，最开始和大多数人一样，以为核心难点在怎么把检索做快、把向量算准。结果真正跑到生产环境才发现，pgvector再快、Embedding模型再强，只要文本切片和查询意图对不齐，召回的东西就是答非所问。这个“对齐”问题，比任何索引调参都坑人。

这篇文章不打算从头科普RAG是什么，而是把我用pgvector做知识库问答的完整过程、踩坑经历和调整方案梳理一遍。重点落在三个地方：一是为什么说RAG最大的坑在“对齐”而不是检索，二是pgvector从安装到索引选型的实战细节，三是文档切片、元数据设计、查询改写这一整套让系统真正能用的“对齐”操作。适合正在用PostgreSQL搭RAG、或者已经在用pgvector但召回质量不理想的团队参考。

1. 先理解RAG的真正瓶颈：为什么坑在“对齐”

很多人一上来就调Embedding模型、调向量索引参数，但系统检索结果还是很差。我做了几个项目之后才慢慢想明白：RAG链路里，检索只是表面功夫，真正决定上限的是整个链路有没有“对齐”。这个“对齐”至少分成四层，每一层对不上，结果都会崩。

1.1 什么是“对齐”：四层维度的拆解

第一层是文本切片与查询意图的对齐。文档被切成一段段之后，每一段能否独立回答一个完整问题。如果切片把三段不相关的上下文拼在一起，或者把一个完整方案拆散到两个片段里，向量检索再好也没用。

第二层是Embedding模型与语料领域的对齐。通用Embedding模型在通用语料上表现不错，但在垂直领域（比如法律、医疗、内部运维工单）很容易失效。模型词汇表里缺少行业术语，语义表达方式和行业惯例不一致，向量空间里的“相似”和业务上的“相关”就会偏掉。

第三层是元数据业务语义与检索逻辑的对齐。RAG系统通常要按来源、时间、文档类型做过滤，如果元数据设计不合理，检索时没法用业务条件缩小范围，或者过滤条件把正确的文档误杀了，对齐就失败了。

第四层是评估方式与真实业务目标的对齐。用一个简单的top_k命中率来看系统表现，和真正看用户问题是否得到完整、准确答案，是两回事。很多项目“看起来准”是因为评估集太简单，一上真实用户就崩溃。

1.2 pgvector在中间扮演什么角色

pgvector只是把文本向量化之后存进去并提供相似度检索的组件。它解决的是“快速找到向量空间里距离近的片段”，但距离近不等于业务答案对。所以pgvector是必要条件，不是充分条件。

从工程角度看，pgvector最大的价值在于：如果你已经在用PostgreSQL管理业务数据，就能省掉引进Milvus、Weaviate、Pinecone等独立向量数据库的运维成本。所有向量数据、元数据、业务数据都在同一个事务里，备份、权限、一致性都沿用原有体系。但这个便利也容易让人产生错觉——以为装了pgvector就完成了RAG系统，其实后面还有大量“对齐”工作。

注意：如果只是存几个文本块做Demo，随便一个向量数据库都能跑通。一旦进入生产环境，文档数量上万、用户问题复杂、还需要多租户隔离时，pgvector在元数据过滤、SQL联合查询、事务一致性上的优势才真正体现出来。

2. pgvector安装与环境选型：先把地基打稳

很多踩坑从安装就开始了。pgvector作为一个PostgreSQL扩展，版本兼容性必须提前查清楚。我用的是PostgreSQL 14，pgvector选0.6.x版本，整体比较稳定。如果你用PostgreSQL 12或13，注意部分旧版本不支持HNSW索引，只能走IVFFlat，这会影响后面召回策略。

2.1 Windows和Linux的安装差异

Windows上安装pgvector需要找到和数据库大版本、位数完全匹配的安装包。下载不到合适的预编译包时，最常见的选择是用Docker跑PostgreSQL容器，省掉本地编译的麻烦。我自己的推荐是：

• Windows快速体验：Docker运行pgvector/pgvector:pg14镜像，简单高效。
• Windows生产环境：优先考虑迁移到Linux服务器，或者使用云数据库PostgreSQL版（部分云厂商已内置pgvector插件）。
• Linux环境：最省心的方式是使用PostgreSQL官方源安装数据库后，再用make install编译安装pgvector，需要提前准备好postgresql-server-dev-14依赖包。

安装完成后，在目标数据库里执行：

CREATE EXTENSION IF NOT EXISTS vector;

能正常执行就说明扩展装上去了。验证无误后，可以顺手确认一下版本：

SELECT extversion FROM pg_extension WHERE extname = 'vector';

2.2 数据表设计：向量字段不能随便建

建表时最容易犯的错：把所有向量都放进一张大表，不区分业务域。建议按业务语义拆表，每张表对应一个知识域，而不是一个大而全的“embeddings”表。这样后续做元数据过滤、权限隔离和索引重建都轻松很多。

我用过的表结构大致长这样：

CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, document_id TEXT NOT NULL, chunk_index INT NOT NULL, content TEXT NOT NULL, source_file TEXT, page_number INT, chunk_metadata JSONB DEFAULT '{}', embedding vector(1536) ); CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

这里的vector(1536)维度要根据你选的Embedding模型来定。OpenAI的text-embedding-ada-002是1536维，开源模型如bge-large-zh是1024维，m3e-base是768维。维度不匹配会直接报错，写入时要注意统一。

2.3 距离函数的选择逻辑

pgvector支持三种距离：L2欧氏距离、内积、余弦距离。

• 余弦距离（vector_cosine_ops）：对向量模长不敏感，适合文本语义相似度，知识库问答基本都用它。
• L2距离（vector_l2_ops）：适合图像特征、推荐场景，对向量归一化要求高。
• 内积（vector_ip_ops）：适合已归一化向量的场景。

文本检索场景我直接用余弦距离，这样即使Embedding后的向量模长不稳定，也不会影响相似度排序。建索引时用了vector_cosine_ops，查询时也要保持同一套距离计算方式，否则索引命中不了，性能会退化。

提示：如果对距离类型不敏感，千万别混用。我之前有个表用L2建索引，查询却用了余弦距离，出来的排序结果整体偏移还不自知，排查了很久才发现索引没走对。

3. 切片与元数据：检索质量的核心“对齐”操作

真正让我觉得RAG难做的，不是向量检索本身，而是文档处理。同一个文档，切片粒度不同、策略不同，检索效果天差地别。同时，元数据设计直接决定了后续能不能用业务条件过滤，进而决定系统能不能规模化。

3.1 切片长度不是拍脑袋定的

我在项目里试过200字符、500字符、800字符、1500字符四种切片方式。结果很有意思：对于产品手册类文档，500~800个字符的中等切片效果最好；对于技术方案和合同类长段落文档，需要先按章节结构切开，再在过长段落内部分片。

为什么？切片太长，向量中包含太多无关信息，查询向量落在其中时，相似度被平均掉，就找不准真正相关的片段；切片太短，上下文断裂，后半段内容往往缺乏回答问题的必要背景。所以切片策略不能只看字符数，还要结合文档结构。

一个比较实用的做法：

1. 先用文档原生的标题结构（Markdown标题、Word标题样式、PDF目录）做第一层切分，保证每个候选片段在业务语义上是完整的。
2. 对超过阈值的段落，再按句子边界二次切分，加入前后文的“重叠窗口”。
3. 把同一章节下的相邻小段聚合起来作为检索元信息前缀，让向量同时感知局部内容和全局上下文。

3.2 重叠窗口和父子块设计

重叠窗口是缓解切片上下文断裂的常用手段。简单说，就是相邻两个切片之间重叠一部分文本，让关键信息不会恰好被切片边界切断。比如按500字符切片时，每相邻两个切片重叠100字符。这样一条信息最多被截断的概率会显著降低。

更进阶的做法是“父子块”结构：给每个小切片（子块）做Embedding用于精确召回，同时把一个章节的整体文本（父块）留给大模型做回答时的上下文。查询命中子块后，把父块内容整体返回给LLM，这样既能通过小切片保证召回精度，又不会因为上下文缺失影响回答质量。代价是多一层存储，但效果提升非常明显。

我用jsonb字段记录父子关系和章节信息：

{ "parent_id": "doc_001_chunk_003", "chapter": "3. 系统架构设计", "title": "3.2 数据流向说明", "doc_type": "设计文档" }

这样在查询时不仅可以按doc_type过滤，还能按章节聚合去重，避免多个子片段同时命中但内容高度重复，反而占用上下文窗口。

3.3 元数据：RAG系统里最容易偷懒但最不能偷懒的部分

元数据看似只是几个字段，实际决定了一个RAG系统能否从Demo走向生产。缺少元数据，用户问“上个月运维工单的处理流程”，检索时无法限定时间范围，就会把去年同名的文档也捞出来；缺少来源标识，大模型回答完用户没法追溯，也没法建立信任。

我比较推荐的元数据至少包含：

• 文档唯一ID和名称
• 文档类型（手册、流程、公告、工单方案）
• 所属业务域或部门
• 生效时间、过期时间
• 安全级别（公开、内部、机密）
• 章节路径和页面号
• 版本号

这些字段在检索时都能作为过滤项。pgvector的SQL查询天然支持把向量相似度条件和元数据过滤条件组合在一起，这也是我不用独立向量数据库的一个重要原因——过滤逻辑可以写进同一条SQL里，不会出现“先向量召回100条再内存里做过滤”的低效做法。

3.4 查询语句中如何把对齐逻辑落实

我把一个查询拆成几个阶段：

WITH relevant_chunks AS ( SELECT id, content, chunk_metadata, embedding <=> $query_embedding AS cosine_distance FROM doc_chunks WHERE chunk_metadata->>'doc_type' = '运维手册' AND (chunk_metadata->>'effective_date') >= '2024-01-01' ORDER BY embedding <=> $query_embedding LIMIT 20 ) SELECT id, content, chunk_metadata, cosine_distance FROM relevant_chunks WHERE cosine_distance <= 0.35 ORDER BY cosine_distance;

这里我用了<=>运算符表示余弦距离，距离越小越相似。LIMIT设为20是因为后面还要做重排，先放宽召回，防止真正相关的片段被卡在20名之外。最后再用距离阈值0.35过滤掉明显不相关的噪声。

阈值的选择需要结合具体Embedding模型来标定，没有通用值。我一般会随机抽一批用户问题，把每道题的真实相关片段距离画成分布，再选择合适的阈值，保证召回率和精确率的平衡。

4. 索引选型与调参：让pgvector在数据量增长后不拖后腿

数据量小的时候，全表扫描也能秒回。但当文档块数量涨到几十万甚至上百万，没有合理的索引，查询会越来越慢。pgvector目前提供了两种主要的向量索引：IVFFlat和HNSW，两者各有适用场景。

4.1 IVFFlat和HNSW怎么选

IVFFlat的思路是先把向量空间划分成多个桶，查询时只在最近的几个桶里搜索。它构建快、内存占用低，但召回精度受桶数量影响。桶数太少，每个桶里向量太多，检索精度下降；桶数太多，候选集太小，可能漏掉真实相关片段。

HNSW的思路是用多层图结构组织向量，像高速公路一样从粗略层快速定位到精细层。它的查询精度和速度通常更好，但构建时需要更多内存，参数调整也更敏感。

就我最近的实践经验来说，优先推荐HNSW。原因很简单：RAG场景中数据量通常不算特别大（几百万以内），内存占用完全可以接受，但查询精度和速度都更稳定。IVFFlat比较适合构建时内存受限、且能接受重建索引来适配动态数据的场景。

建HNSW索引的核心参数：

• m：每个节点的最大连接数，默认16。增大m会提升召回精度，但索引体积和构建时间也上升。
• ef_construction：构建索引时的动态候选列表大小，默认64。越大构建越慢、索引质量越高。
• ef_search：查询时的候选列表大小，不是建索引时设置，而是在每次查询前设置。

查询时可以动态调整：

SET hnsw.ef_search = 100;

我的经验是默认m=16, ef_construction=64在大多数场景下已经够用。如果召回精度不足，优先提高ef_search到100~200，而不是一开始就动m和ef_construction，因为后两者的调整需要重建索引，成本高很多。

4.2 常见的索引踩坑记录

1. 建索引用了vector_l2_ops，查询却用余弦距离，导致索引失效，性能回落成全表扫描。
2. HNSW索引在数据量很小（几千行）时优势不明显，有人因此误判“索引没用”，但数据量上来就后悔没建。
3. 初始化ef_search设得太小（比如默认40），长尾问题召回效果差。我先调整到100，观察分布后定成80左右。
4. 大表上直接建HNSW索引，内存不够导致OOM。建议先调大maintenance_work_mem，或者分批插入数据后再建索引。

4.3 用分区表或定期清理保证性能

文档数据是持续增长的，但知识库里并非所有内容一直有效。比如企业规章制度更新后，旧版本就不应该再被检索到。我通常用标记删除或分区表来实现“逻辑有效”的数据可见性：

CREATE TABLE doc_chunks_2025 PARTITION OF doc_chunks FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

加上时间分区后，可以按“当前有效版本”过滤，减少无效数据对检索的干扰。每次知识库版本更新时，只重做对应分区的Embedding和索引，而不是全量重建。

5. 从“能搜到”到“答得对”：检索后处理的几个关键技巧

检索返回一批候选片段后，很多人直接把内容拼进Prompt就交给大模型。但这里还差了好几道“对齐”工序。多轮对话、长文档、相似片段多的情况下，不加处理效果非常不稳。

5.1 查询改写：让用户问题更贴近索引空间

用户提问往往口语化、指代不清、省略背景。比如用户问“这个功能怎么开”，如果没有上下文，系统根本不知道“这个功能”指什么。我的做法是在检索前加入一个查询改写环节：

1. 结合多轮对话历史，把“这个功能”补全为“用户上一轮提到的XX功能”。
2. 抽取用户问题中的关键实体，扩展同义词。
3. 如果问题冗长，提炼出核心搜索词，而不是直接拿原文去检索。

改写可以交给LLM来做，但要注意控制额外耗时和成本。我们用一个轻量Prompt，只要求输出改写后的查询词，不需要解释。整个过程增加几百毫秒，但检索准确率提升明显。

5.2 混合检索与重排：别只依赖单一向量召回

向量检索擅长语义相近的场景，但无法保证每个关键词都精确命中。比如用户搜索“SLA 99.95% 补偿方案”，如果文档里写的是“服务可用性标准”而Embedding模型对该概念理解不到位，向量召回就可能漏掉。

混合检索的价值就在这里：向量召回一批+关键词全文检索召回一批，取并集后再做重排。pgvector本身不支持全文检索的联合索引优化，但PostgreSQL的tsvector全文搜索可以和向量检索写进同一条SQL，找出交集和并集。

我通常的组合方式是：

• 向量召回top30
• PostgreSQL全文检索召回top20（按ts_rank排序）
• 合并去重后，用轻量重排模型或LLM打分，选出最终的top5

重排这一步很多团队会省略，但对回答质量影响很大。因为向量召回结果可能多个片段内容高度相似，重排可以把最相关的那一个推上来，同时让多个互补的片段同时进入上下文。

5.3 多轮对话怎么设计：上下文压缩很关键

多轮对话场景下，直接把全部历史记录拿去检索，既浪费Token又容易把查询搞偏。我们后来用了“逐轮摘要”的思路：

每一轮对话结束后，把当前问答的核心信息压缩成一句话，累积成对话记忆摘要。下一轮用户提问时，用“对话摘要+当前问题”一起去做查询改写和向量检索。这样既能维持上下文，又不会引入过多噪声。

一开始我没做摘要，而是把所有历史记录都拼接进Prompt，结果模型经常把用户的代指词“它”“这个”解析错，检索出来的片段也明显偏差。后来改成摘要方案，问题就稳定多了。

对话摘要：用户咨询XX服务的告警处理流程，运维人员已给出初步排查步骤。 当前问题：这个流程在夜间值班时适用吗？ 改写查询：XX服务告警处理流程在夜间值班时是否适用，夜间值班告警处理步骤

这种改写结果可以直接用来做向量检索，同时保留原问题供LLM生成答案。

6. 常见问题与排查技巧实录

这部分是实战记录，不是在文档里能直接查到的内容。多数问题不是因为代码有Bug，而是“对齐”没做好导致的软故障。

6.1 检索结果看着相似，但答案完全不对

最典型的现象是：Embedding距离很近，但内容只是“用词相近”，不是问题需要的答案。我排查过几次，根因通常出在切片上。

比如用户问“系统超时怎么排查”，文档里有一大段讲“超时时间的配置方法”，这小段和问题在字面上相似，但用户要的是排查步骤，不是配置方法。解决办法是调整切片信息密度，把“问题现象-排查步骤-解决方案”这类结构化内容尽量放在同一个片段里，或者把文档的章节标题、段落摘要作为额外的元数据加入向量索引，让Embedding能感知文档的“功能定位”。

6.2 相似度阈值设多少都难受

阈值是RAG拉胯的重灾区。阈值设太高，召回太少，大模型无话可说；阈值设太低，召回一堆无关片段，大模型答非所问。我之前一直靠感觉调，后来改成数据驱动的办法：

1. 准备50~100条真实用户问题，人工标记出每条问题对应的正确文档片段。
2. 跑一遍检索，统计正确片段在候选列表里的排名和相似度分数。
3. 画出排名分布和分数分布，用P90和P10来辅助定阈值。

这样定出来的阈值虽然不能保证100%准确，但至少有理有据，出了问题也能复盘。

6.3 召回片段互相矛盾怎么办

当一个提问命中了多个片段，而这些片段来自不同版本或不同部门文档时，LLM可能把冲突内容揉在一起，给出自相矛盾的答案。

我的做法是在元数据中加入“文档版本”和“生效状态”，检索时只召回当前有效的版本。如果业务上确实需要比较新旧版本文档，那就把“版本对比”作为独立的用户意图，交给专门的检索流程处理。

6.4 大模型输出质量不稳定，不知道是不是检索的问题

模型输出不好，很多人第一反应是换大模型，但这个坑往往藏在上下文中。我用一个小技巧来分开排查：

• 把检索到的片段直接用简单模板拼接，让大模型“只根据片段内容回答，不要推理”。
• 如果输出仍然差，那就是召回内容本身不对或信息缺失。
• 如果输出结果相对稳定但不够好，那就是大模型能力或Prompt设计问题。

这样分层排查，能少走很多弯路。

6.5 常见问题速查表

现象	可能原因	排查方向
召回结果语义相关但答非所问	切片粒度不对，片段内信息混杂	检查切片是否能独立回答完整问题
相似度分数整体偏低	Embedding模型与语料领域不匹配	换领域微调或换垂直领域Embedding模型
候选片段很多但内容重复	切片重叠度过高或父子块设计不合理	重排时增加多样性限制
带条件过滤后召回为空	元数据条件过严	先放开过滤条件，查看真实文档的元数据值
查询延迟越来越高	索引没走对，或ef_search过大	用EXPLAIN检查是否命中向量索引
多轮对话指代不清	历史上下文没有压缩	增加对话摘要和查询改写

7. 聊聊我对RAG现状的观察和一点建议

做了几个RAG项目后，我越来越觉得，这类系统的难度不在于某一个独立技术点的“深”，而在于把文档处理、向量化、检索、重排、Prompt工程、模型调度串成一个整体。任何一个环节和业务目标不对齐，最终效果都会打折扣。而pgvector的好处是它让我从向量数据库运维中解放出来，让我有更多精力去解决这些真正影响业务体验的“对齐”问题。

我常和团队说一句话：先别急着上重模型、大索引，先拿一批真实用户问题跑通链路，把回答里明显不对的案例收集起来，再逐条回到“切片-检索-重排”链路里去定位是哪一环出了问题。RAG系统是典型的木桶效应，短板在哪，你从最终答案的质量上都能看出来。

另外，我也建议在项目初期就建立一个小规模的评测集，哪怕是50条问题也好。每次改动切片策略或换Embedding模型，都跑一遍评测集，用数字说话，而不是靠“感觉好了”来判断。我踩过最大的坑就是靠感觉调参，结果上线后被真实用户的问题打回原形。

最后分享一个小技巧：给每个文档块留一个全局唯一ID，并且在回答中引用它。这样用户看到答案时能追溯来源，遇到错误能反馈到具体文档，你的问题排查链路也会顺畅很多。RAG系统最终拼的不是模型有多强，而是你对知识库的理解有多深、对用户问题的把握有多准。这个认知，希望你在看完这篇文章后能少走一些弯路。