1. 为什么说检索前优化比换模型更值得投入1.1 检索不出内容的瓶颈通常藏在索引里做RAG的人应该都有过这种经历模型已经是业界顶配了prompt也调了好几轮用户问一个问题系统要么回复“找不到相关信息”要么把八竿子打不着的内容当成上下文丢给大模型。这时候多数人第一反应是换更好的模型或者加大向量检索的TopK。实际上问题大概率不在生成端而在检索前这一段。你回想一下RAG的完整链路原始文档进来先要做数据清洗、解析、切块然后embedding向量化接着把向量和元数据送进向量库构建索引在线检索时再拿query去召回、融合、重排最后把命中的上下文交给LLM生成回答。前面这一半也就是从“原始文档”到“可检索索引”的整条流水线就是检索前优化的工作范围。我在实际项目里见过太多“检索效果差”的case最后定位下来都是检索前的索引结构出了问题。比如给管理层做知识库问答用户问“去年Q3华东区的销售额是多少”文档里其实有这个数但它在Excel里而且被硬切成十几个固定长度的chunk数字、表头、单位被分散到了不同片段里。向量检索召回了一段完全不相关的内容最后模型告诉你“未找到该数据”。你说这是模型的问题吗不是是索引结构压根没把表格数据当成一个有边界的信息单元来组织。所以做RAG优化我的经验是先别折腾生成侧先把检索前这一段理清楚尤其是索引结构。硬件决定的是速度上限索引结构决定的才是效果上限。1.2 先搞清楚你的RAG到底慢在哪、差在哪优化之前要有一个客观的度量方式不然就是瞎调。RAG检索质量最常用的三个指标命中率Hit Rate、MRRMean 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。召回精度取决于nprobenprobe越大扫描桶越多、越准但越慢。HNSW用的是分层图的思路。图分多层上层稀疏下层稠密检索从最顶层开始沿着图结构逐层下探直到找到最接近的目标。这种方法的检索速度和召回精度都很好是高维向量检索里最常用的方案代价是构建索引时要调参数内存占用也偏高。PQ乘积量化则是把高维向量切分成多个子向量每个子向量用一组码本量化。比如512维向量切分成32段每段16维每段量化为256个码中的一个那一个向量就从512*4字节约2KB压缩到32字节。内存直接降了两个数量级但这是有损量化精度会有牺牲适合超大基数场景下做候选粗筛。还有一个SQ标量量化把浮点数值压缩到int8类型内存降4倍精度损失可控。对昇腾服务器上部署的场景来说SQHNSW的组合成本控制效果很好值得优先考虑。选型没有银弹我的经验判断表放在这里索引方式检索速度内存占用召回精度适合规模落地建议Flat最慢最高100%十万级以下适合离线验证或数据量小、精度要求高的场景IVF中中中高十万到百万级结合nprobe调节速度与精度可权衡HNSW快较高高百万级常规在线检索首选参数量要调好PQ较快极低中低千万级以上做粗筛配合精排使用HNSWSQ快中低中高百万级内存紧张时的最佳折中方案不需要在架构初期就把技术选型钉死。我一致的做法是小数据量几万条先用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系列硬件平台以及配套的软件栈和推理框架。在昇腾上做RAGembedding模型的加载和推理可以放在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侧向量检索本身不依赖NPUNPU集中资源跑embedding和LLM推理。以Milvus为例我第一次构建索引时会显式指定索引类型和参数。比如HNSW索引的参数配置from pymilvus import CollectionSchema, FieldSchema, DataType, Collection schema CollectionSchema([ FieldSchema(namechunk_id, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(namedoc_id, dtypeDataType.VARCHAR, max_length128), FieldSchema(namebusiness_line, dtypeDataType.VARCHAR, max_length64), FieldSchema(namecontent, dtypeDataType.VARCHAR, max_length4096), FieldSchema(namevector, dtypeDataType.FLOAT_VECTOR, dim1024) ], descriptionrag_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排查也有一个基本套路。发现效果不好先对照着查一遍大多数问题在第一轮就能定位。我整理成了一张速查表每次索引结构调整后出现异常都按这个顺序过一遍。问题现象可能原因排查手段解决动作问什么什么找不到切块过小或切断了关键语义抽查结果中召回的chunk内容看是否语义完整改用结构感知切分调整块大小召回内容语义相似但答非所问用户query里有精确编号/型号向量检索不敏感检查BM25关键词召回结果是否命中精确token加向量BM25多路召回用RRF融合检索结果大量越权或无关业务没有做元数据过滤或过滤字段没进索引查召回结果里是否混入其他业务线内容建Collection时加business_line等过滤字段数据量不大但检索很慢索引类型还是Flat或nprobe设置过大查看向量库查询耗时和段数量迁移到HNSW索引控制nprobe增量插入后命中率下降索引段碎片化旧段数据和新段数据冲突查索引段的数量执行compaction定时合并段或定期全量rebuild换embedding模型后效果变差向量维度不一致导致索引重建失败或token上限截断检查向量维度、模型max_seq_length和切块长度统一维度重新切块再建索引同一个内容反复出现源文档有重复或切块重叠过大看召回结果里的doc_id是否重复入库前去重simhash调低重叠率这里面的每一行都来自实际踩坑。特别是最后一条重复内容在召回结果里占据多个坑位把真正有用的信息挤掉了这个问题非常隐蔽。源文档里同一个条款可能出现在多个汇总文档里没有去重hit_rate再高也没用。5.2 几个容易被忽视的细节第一向量归一化问题。以COSINE作为度量类型时大部分向量库会自动做归一化但如果你用的是自己的算法或者跨库迁移一定要确保embedding向量做过L2归一化否则内积相似度和余弦相似度会混为一谈排序结果直接乱套。第二测试集一定要留好。索引结构优化的每一步都需要评估没有固定的测试集就等于盲调。我给测试集设了一个底线要求必须包含真实用户问题不是让模型生成的模拟问题而且每条都要标注标准答案所在文档的ID或原文位置。这个测试集可以不用很大50条就足够发现绝大多数回归问题。每次改索引结构先跑一遍baseline再跑改后结果所有技术决策都靠数据说话。第三权限过滤器要先于向量检索执行。生产环境的知识库一定涉及权限隔离如果没有先做权限过滤向量检索召回的结果里可能就有用户无权访问的内容系统把召回结果至于生成模型这会直接越过安全边界。这个不是性能问题是一个绝对不能省的设计。6. 结尾一点个人体会做索引结构优化这一年多我最大的体会就是“先理结构、再上模型”。很多团队把RAG当成“模型问题”动不动就上更大的模型、微调prompt但根本问题往往是切块切得粗糙、索引选型不对、元数据没挂、没做多路召回。这些检索前的问题反复在线上以“找不到、答非所问、速度慢”的形式暴露出来换什么模型都治标不治本。最后分享一个我在实际运行中保留的习惯每次调整索引结构改切块参数、换索引类型、加检索路由都先用固定测试集跑一遍基准指标再做上线决策。这不是流程负担而是唯一能让你在排障时不至于一头雾水的手段。索引结构优化这件事越早做后面的成本越低。等生产环境出了问题再去回头补课那代价就是好几倍的返工。