1. 为什么说检索前优化比换模型更值得投入

1.1 检索不出内容的瓶颈通常藏在索引里

做RAG的人应该都有过这种经历：模型已经是业界顶配了，prompt也调了好几轮，用户问一个问题，系统要么回复“找不到相关信息”，要么把八竿子打不着的内容当成上下文丢给大模型。这时候多数人第一反应是换更好的模型，或者加大向量检索的TopK。

实际上问题大概率不在生成端，而在检索前这一段。

你回想一下RAG的完整链路：原始文档进来，先要做数据清洗、解析、切块，然后embedding向量化，接着把向量和元数据送进向量库构建索引，在线检索时再拿query去召回、融合、重排，最后把命中的上下文交给LLM生成回答。前面这一半，也就是从“原始文档”到“可检索索引”的整条流水线，就是检索前优化的工作范围。

我在实际项目里见过太多“检索效果差”的case，最后定位下来都是检索前的索引结构出了问题。比如给管理层做知识库问答，用户问“去年Q3华东区的销售额是多少”，文档里其实有这个数，但它在Excel里，而且被硬切成十几个固定长度的chunk，数字、表头、单位被分散到了不同片段里。向量检索召回了一段完全不相关的内容，最后模型告诉你“未找到该数据”。你说这是模型的问题吗？不是，是索引结构压根没把表格数据当成一个有边界的信息单元来组织。

所以做RAG优化，我的经验是：先别折腾生成侧，先把检索前这一段理清楚，尤其是索引结构。硬件决定的是速度上限，索引结构决定的才是效果上限。

1.2 先搞清楚你的RAG到底慢在哪、差在哪

优化之前要有一个客观的度量方式，不然就是瞎调。

RAG检索质量最常用的三个指标：命中率（Hit Rate）、MRR（Mean Reciprocal Rank）和NDCG。命中率衡量的是正确答案有没有出现在召回集合里，MRR看正确答案排在第几位，NDCG更严格一些，会考虑多级相关性排序。日常迭代里，我一般盯命中率和MRR就够了，优化索引结构主要影响这两个值。

先说命中率。它反映的是召回能力，也就是“该捞的有没有捞上来”。索引结构直接影响召回的边界：切块太小，一个完整语义被拆碎，向量表示不完整，召回失败；切块太大，噪声太多，向量被干扰，召回还是失败。元数据过滤条件写错了，该命中的文档直接被杀掉。这些都属于检索前的问题。

MRR反映的是排序能力，也就是“正确答案排多靠前”。这一步和索引结构的关系也很大。向量检索本身对语义相似度敏感，但对关键词精确匹配、ID号、型号、数值区间这些“硬信号”不敏感。比如用户问“A100-80G和A800哪个带宽高”，索引里明明有对比表格，但因为切块和索引方式的问题，精确匹配的段落根本没被优先召回。这时候就需要混合索引结构、重排序策略介入。

在昇腾平台上做RAG还有个特点：embedding模型的推理可以跑在NPU上，向量化和在线推理的速度比CPU快很多。但你要是索引结构一团糟，硬件再快也只是更快地召回错误结果。所以检索前优化这件事，是性能和效果的双赢杠杆，值得先投入。

2. 检索前优化的设计思路：从“能存”到“好找”

2.1 把知识库当作一个系统来设计，而不是流水线

很多团队做RAG知识库，上来就是“PDF进来，向量出去”，装个LangChain、LlamaIndex就跑。数据不管是什么格式、什么结构，一律用默认的递归字符切割器，固定大小500字符切完拉倒。这样搞出来的索引，本质上就是一堆无结构的碎片堆在一起。

我习惯用一个类比来解释索引结构：图书馆里不会有人把所有书按页码顺序堆成一座山，检索的时候一张一页去找。图书馆一定有分类体系、目录卡片、书架编号，甚至还有索引柜。同一本书会在“作者索引”“主题索引”“书名索引”里同时出现。你设计RAG的索引结构，做的就是这个图书管理员的活。

具体来说，设计索引结构要考虑几件事：原始数据的结构特征是什么（是长文档、表格、对话记录、工单还是代码）；用户查询的典型范式是什么（是全句自然语言，还是带编号带参数的精确查询）；以及返回给LLM的上下文应该以什么粒度组织最合适。

举个例子。法律合同类文档，条款之间有强引用关系，你如果按固定字符切块，第3条的内容和第3.1条的内容被分到两个不连续的chunk里，用户问“第3.1条的违约责任是什么”，召回结果里可能只有半个条款。正确做法是先用文档解析器把法条结构切成“章、节、条、款”这种层级单元，再以条款为最小检索单元建索引，同时保留“所属合同编号”“条款编号”“生效日期”这些元数据字段用于过滤。

再比如客服FAQ场景。用户问的是“退款多久到账”，这个query背后的意图其实是“退款时效类FAQ”，直接按FAQ标题去做语义匹配比全文向量检索更准。这种场景就需要给索引打上“意图ID”这种标签，检索时先做意图路由，再进向量库。

这一层设计我没法给你一个万能模板，因为不同业务的知识结构差异太大。但你可以把握一条原则：索引结构是给检索场景服务的，先想清楚用户会怎么问，再设计你怎么切、怎么存。检索前优化做得好不好，就看这个对齐程度高不高。

2.2 让元数据过滤成为索引结构的一部分

向量检索不是万能的，纯靠embedding的余弦相似度很难处理时间范围、来源权限、业务线这些结构化条件。比如你给集团做知识库，上海分公司的人只能看到上海分公司的文件，如果向量检索不做权限过滤，召回结果里混着别的分公司的资料，那不只是效果问题，是安全问题了。

元数据过滤就是在索引结构里给每个文档块挂上一组结构化字段，查询的时候先按条件过滤，再在过滤后的集合里做向量检索。常见字段包括所属部门、文档类型、业务线、时间戳、访问级别、项目代号、来源系统。

实际操作中，过滤和向量检索的顺序也有讲究。我推荐的做法是：先做权限和业务域的硬过滤，把检索空间缩到几百到几千条，再做向量召回。因为如果你先向量召回再过滤，TopK里的结果可能一大半都被过滤掉了，有效召回数量根本不够。你要是把TopK拉得很大，又会影响精排效果并拖慢速度。

元数据字段是要进索引结构的，在建集合（Collection）的时候就要定义好字段类型，而不是等到查询时才临时拼条件。后面具体讲昇腾平台落地实操时，我会给出一份可供参考的索引字段设计。

2.3 关于多模态内容的一点边界说明

热词里有朋友关心“RAG知识库能不能存图片”。我的看法是：图片能不能进索引，取决于你的embedding模型是不是多模态的。文本向量模型没法直接把图片变成有语义的向量。如果业务需要检索图片，要么用支持图文对齐的多模态embedding模型，要么退而求其次，只把图片的OCR文字和人工标注作为文本索引内容入库，图片本身作为原始附件存储。索引结构层面，图片索引一般是独立的集合，和文本索引分开管理，别混在一起。

3. 索引结构优化的核心技术手段

3.1 切块策略：影响检索效果的第一道关卡

切块是检索前优化里性价比最高、也最容易被忽视的一步。

先说参数经验。基于常见的文本Embedding模型，我一般推荐：块大小（chunk size）控制在200到400个token之间，重叠区（overlap）控制在块大小的10%到20%，也就是50到150个token。这个经验值怎么来的？

块太小的问题在于语义完整性被破坏。一个完整的观点被拦腰切断，两个半截文本都无法代表原意。块太大则有两个隐患：一是向量表示的“语义重心”被稀释，一个5000字的大块里混杂多个主题，query跟其中某个细节相关时，整体向量相似度反而很低；二是超出embedding模型的输入上限，模型只能截断，等于硬生生丢了尾部信息。

重叠区的作用更直接。文档切块本质上是把一个连续语义流切成片段，切点往往落在语义最连贯的位置，而不是语义断裂的位置。不加重叠区，落在切点附近的query就可能两边都覆盖不到。加了重叠后，切点附近的信息在两边的块里都出现，命中概率就上来了。

但重叠区不是越多越好。重叠太多意味着大量重复内容写入索引，存储膨胀、检索时相似片段互相干扰，MRR反而下降。我自己踩过坑，有一版为了追求召回率把重叠区设成50%，索引体积直接大了快一倍，检索时长也肉眼可见变慢，最后MRR没涨多少。

切块策略优先级从高到低是这样的：

第一，优先用结构感知切分。文档是Markdown就按标题层级切，PDF就先解析出章节结构再切，代码就按函数和类切，表格就整块保留，不要拦腰拆。这是最核心的一条，比调任何参数都管用。

第二，没有明确结构时用句粒度聚合。先把文档切成句子，再用贪心策略把句子聚合到接近目标块大小；遇到超过上限的句子单独成块，别硬拆。

第三，实在没有结构再考虑固定字符切分。那是兜底策略，效果最差，只能保证不报错。

切块参数不是拍脑袋定的。每换一个embedding模型，都要边测边调。我的方式是：挑20到50条真实用户问题，手动标注每条问题的标准答案所在的原文区域，做成测试集；然后在不同切块参数下跑hit_rate和MRR，选效果稳定的那组参数。别用随机生成的测试问题做评估，那对你的业务场景没有代表性。

3.2 向量索引选型：Flat、IVF、HNSW、PQ怎么选

向量数据量涨上去之后，索引结构就是检索性能的分水岭。每次看到有人把几百万条向量丢进默认配置就上线，我都替他捏把汗。

目前主流的向量索引算法主要有这么几类：

Flat向量索引就是全量暴力扫描，逐个向量算距离。召回精度100%，因为没有任何近似，但数据量大时遍历开销极高，不适合在线场景。

IVF（倒排文件索引）的思路是先把数据集用K-Means聚成nlist个桶，检索时只扫描距离query最近的nprobe个桶，把候选集缩小到原来的nprobe/nlist。召回精度取决于nprobe，nprobe越大扫描桶越多、越准但越慢。

HNSW用的是分层图的思路。图分多层，上层稀疏，下层稠密，检索从最顶层开始，沿着图结构逐层下探，直到找到最接近的目标。这种方法的检索速度和召回精度都很好，是高维向量检索里最常用的方案，代价是构建索引时要调参数，内存占用也偏高。

PQ（乘积量化）则是把高维向量切分成多个子向量，每个子向量用一组码本量化。比如512维向量切分成32段，每段16维，每段量化为256个码中的一个，那一个向量就从512*4字节（约2KB）压缩到32字节。内存直接降了两个数量级，但这是有损量化，精度会有牺牲，适合超大基数场景下做候选粗筛。

还有一个SQ（标量量化），把浮点数值压缩到int8类型，内存降4倍，精度损失可控。对昇腾服务器上部署的场景来说，SQ+HNSW的组合成本控制效果很好，值得优先考虑。

选型没有银弹，我的经验判断表放在这里：

不需要在架构初期就把技术选型钉死。我一致的做法是：小数据量（几万条）先用Flat跑通业务，后续数据涨上来再平滑迁移到HNSW，通过建索引接口做异步重建，不影响线上服务。索引结构优化的过程本身就是渐进式的，一步到位的完美方案不存在。

3.3 多路召回与层级索引：让检索从“一把抓”变成“多点出击”

很多人理解的RAG检索就是“一条query进向量库，TopK出来一堆chunk”。但生产环境真正好用的方案，很少是单路向量检索。我推荐至少做向量检索、关键词检索、元数据过滤三路并行，然后用RRF融合排序，再把结果交给重排模型精排。

为什么一定需要关键词检索？因为向量检索的语义匹配对“精确标识”的敏感度很低。用户问“合同HT2024-0018的甲方是谁”，向量检索很可能召回一堆“合同、甲方”语义相似但不含这个编号的段落，而BM25这类词频检索能靠精确token匹配把HT2024-0018这段顶到前面。这两路的能力正好互补。

RRF融合排序的公式很简单：score(d) = sum(1 / (k + rank_i(d)))，其中rank_i(d)是文档d在第i路检索结果中的排名，k常数一般取60。这个公式的精髓在于：它不看具体得分，只看排名，所以两路检索的分数尺度是否一致都没关系。实现起来也就十几行代码的事情。

层级索引的另一个思路，我称之为“父子块结构”。子块小，几百个token，用于精确召回定位；父块大，几百到上千token，用于给LLM提供完整上下文。检索时先用embedding在小块上做向量匹配，命中子块后找到它的父块，把父块拼进prompt。这样既保住了召回精度，又解决了“上下文不够完整”的问题。这个方案在长文档场景里效果极其明显，因为问题相关的细节定位到小粒度，模型拿到的上下文又能覆盖前后文逻辑。

还有一种更轻量的层级方案，是我叫它“摘要索引”：对每个大块先生成一段摘要，把摘要向量挂在索引上；检索时先在摘要层粗筛，定位到候选块后再去细粒度块里做精读。这种方案适合文档很长、检索多轮的场景，能把一次检索的开销分摊到多个层级上。

4. 在昇腾平台落地索引优化的实操要点

4.1 用昇腾的推理能力加速Embedding生成

前面聊了这么多理论，这一节落到昇腾平台的实证细节上。

先说明一点，我这里说的昇腾平台，指的是Atlas系列硬件平台以及配套的软件栈和推理框架。在昇腾上做RAG，embedding模型的加载和推理可以放在NPU上执行，向量化吞吐量比CPU要高得多。这也是检索前优化里“提速”最直观的一环。

结构上，建议把文本切块、数据清洗这类轻量任务放在CPU侧完成，Embedding推理下发到NPU执行，向量库服务单独部署在服务器上。数据处理、Embedding生成、向量入库这三个环节用队列解耦，切块完成的文本块立刻进入Embedding队列，不要让CPU等待NPU推理，也别让NPU空转。

昇腾环境下加载模型有几个地方要提前踩平。一是模型格式转换，PyTorch模型文件要转换成推理框架要求的格式，这个过程在开发环境里能直接跑通，一旦卡住后面全部停摆；二是动态Shape问题，embedding模型输入端长度不固定，建议把batch_size固定下来，比如每次推理一个batch 32条，减少动态shape带来的调度开销；三是显存规划，embedding模型不大，一般几百MB到一两GB，但你的主模型如果也在同一张卡上运行，就得注意显存预留，别让embedding推理吃光资源导致LLM推理排队。

文本块的长度要跟embedding模型的max_seq_length严格对齐。我碰到过团队换了一个更长的模型，忘了检查切块参数，结果500个token的块被截断到256，后半段语义凭空消失，命中率跌了十几个百分点。这个检查点务必纳入切块参数评估流程。

4.2 向量库的索引参数与昇腾服务器资源配置建议

昇腾服务器上向量库的部署方式和通用服务器没有本质差异，关键是资源分配要合理。我在昇腾环境里推荐的组合是：Milvus或Faiss跑在CPU侧，向量检索本身不依赖NPU；NPU集中资源跑embedding和LLM推理。

以Milvus为例，我第一次构建索引时会显式指定索引类型和参数。比如HNSW索引的参数配置：

from pymilvus import CollectionSchema, FieldSchema, DataType, Collection schema = CollectionSchema([ FieldSchema(name="chunk_id", dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name="doc_id", dtype=DataType.VARCHAR, max_length=128), FieldSchema(name="business_line", dtype=DataType.VARCHAR, max_length=64), FieldSchema(name="content", dtype=DataType.VARCHAR, max_length=4096), FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=1024) ], description="rag_index") index_params = { "index_type": "HNSW", "metric_type": "COSINE", "params": {"M": 16, "efConstruction": 200} }

这个配置里的参数不是随便写的。M是每个节点的最大连接数，影响图的密集程度，M越大图越稠密、检索越准，但建图耗时和内存也越大。16是一个兼顾效果和开销的常用起始值。efConstruction是建图时的动态列表大小，影响建图质量，200够用。检索时还有一个efSearch参数，控制搜索时的探索范围，我建议从80开始调，效果不行再往上加。

索引构建策略上，全量重建和增量更新要分开设计。首次上线做一次性全量build没问题。后续每天新增文档，逐条插入会导致索引段膨胀，检索性能会逐步下降。更好的做法是定时做索引合并，或者干脆按天/周做一次全量rebuild。我们线上业务数据量不大的时候，每天凌晨跑一次全量重建，五百多万条向量不到半小时就能完成，比处理增量更新的各种边角问题省心得多。

5. 常见问题排查与避坑实录

5.1 检索效果差的第一轮排查清单

做RAG排查也有一个基本套路。发现效果不好，先对照着查一遍，大多数问题在第一轮就能定位。我整理成了一张速查表，每次索引结构调整后出现异常，都按这个顺序过一遍。

这里面的每一行都来自实际踩坑。特别是最后一条，重复内容在召回结果里占据多个坑位，把真正有用的信息挤掉了，这个问题非常隐蔽。源文档里同一个条款可能出现在多个汇总文档里，没有去重，hit_rate再高也没用。

5.2 几个容易被忽视的细节

第一，向量归一化问题。以COSINE作为度量类型时，大部分向量库会自动做归一化；但如果你用的是自己的算法或者跨库迁移，一定要确保embedding向量做过L2归一化，否则内积相似度和余弦相似度会混为一谈，排序结果直接乱套。

第二，测试集一定要留好。索引结构优化的每一步都需要评估，没有固定的测试集就等于盲调。我给测试集设了一个底线要求：必须包含真实用户问题，不是让模型生成的模拟问题，而且每条都要标注标准答案所在文档的ID或原文位置。这个测试集可以不用很大，50条就足够发现绝大多数回归问题。每次改索引结构，先跑一遍baseline，再跑改后结果，所有技术决策都靠数据说话。

第三，权限过滤器要先于向量检索执行。生产环境的知识库一定涉及权限隔离，如果没有先做权限过滤，向量检索召回的结果里可能就有用户无权访问的内容，系统把召回结果至于生成模型，这会直接越过安全边界。这个不是性能问题，是一个绝对不能省的设计。

6. 结尾：一点个人体会

做索引结构优化这一年多，我最大的体会就是“先理结构、再上模型”。很多团队把RAG当成“模型问题”，动不动就上更大的模型、微调prompt，但根本问题往往是切块切得粗糙、索引选型不对、元数据没挂、没做多路召回。这些检索前的问题，反复在线上以“找不到、答非所问、速度慢”的形式暴露出来，换什么模型都治标不治本。

最后分享一个我在实际运行中保留的习惯：每次调整索引结构（改切块参数、换索引类型、加检索路由），都先用固定测试集跑一遍基准指标再做上线决策。这不是流程负担，而是唯一能让你在排障时不至于一头雾水的手段。索引结构优化这件事，越早做，后面的成本越低。等生产环境出了问题再去回头补课，那代价就是好几倍的返工。