RAG数据管道全流程详解：从解析、分块到检索重排的工程实践

1. 先把数据管道全貌说清楚有人把 RAG 做成了“分块 向量化 相似度搜索”三步上线后效果一言难尽。我见过不少项目Embedding 选得没问题分块也没有按字数一刀切但最后召回还是一堆噪声。原因几乎都一样只盯着中游两个环节把整条数据管道当成了两段焊死的管子。其实 RAG 能不能做好核心是数据管道全流程——上游的采集、解析、清洗决定你能捞到什么中游的分块和向量化决定捞出来的粒度下游的索引、检索、重排、评估决定捞出来能不能用。1.1 为什么总盯着分块与向量化会翻车很多教程把 RAG 的链路简化成“读文档 - 切成 chunk - 塞进向量库 - 查询”。这套流程跑 demo 没问题一旦面对真实业务数据问题立刻现形。最常见的现场是用户的原始材料是扫描版 PDF、合并单元格的 Excel、带目录和页脚的 Word或者是从内部系统导出的 HTML。这些内容如果不经过解析和清洗直接进分块环节后果就是每个 chunk 里都残留页眉页脚、表格被拍平、标题层级完全丢失。这时候你换个更好的 Embedding 模型或者把 chunk 大小从 512 调到 256召回率也只能涨两三个点因为问题出在源头。打个比方图书馆的分类做得再漂亮进货的书全是缺页、错版读者能找到正确资料的几率并不会因此提高。很多团队把大量时间花在调模型上却不愿意在数据管道的“进货质检”环节下功夫这是本末倒置。还有一个比较容易忽略的点分块和向量化的结果最终要服务于检索。如果下游策略是纯向量 top-K 召回中游做得再好也会遇到“相似但错误”的噪声。我后面会详细讲混合检索和重排这里先记住一个结论数据管道的每一环都在给下一环提要求只优化中间两环效果天花板很低。1.2 一个完整数据管道的八段骨架我在实际项目中通常把 RAG 数据管道拆成八个环节哪怕是一个星期就要上线的最小可用版本也会把八个环节的接口先留出来数据采集确定数据源文件目录、数据库、网页抓取、SaaS 导出都要有稳定的接入方式。格式解析把 PDF、Word、Excel、HTML、图片等转成可处理的文本或结构化内容。清洗与规范化去重、去噪、编码修复、敏感信息过滤把内容变成相对干净的语料。分块按语义边界或文档结构拆成适合检索的单元同时保留上下文关联。向量化用 Embedding 模型把分块文本转成向量必要时同时生成稀疏向量。索引存储写入向量库或搜索引擎建立索引和元数据映射。检索与重排查询时做召回、过滤、重排取最相关内容交给大模型。评估与回流更新用评测集和线上反馈评估效果驱动数据、参数、索引的持续更新。这八个环节不是一次性的静态流程而是一个循环。尤其最后一步很多人做完前七步就以为收工了实际上数据源会变、文档会更新、用户问题会越问越偏没有回流机制知识库会逐渐腐烂。所谓 RAG 不只是分块和向量化本质上就是说要把这八段当成一条自动化的、可观测的数据管道来运营。现在热起来的一些概念比如 Agentic RAG、Ontology RAG甚至很多人拿 RAG 和 MCP 做对比其实都改变不了这条主干。Agentic RAG 只是让模型在检索前先拆解任务、多次查询Ontology RAG 是在清洗和索引环节引入了领域知识结构MCP 解决的是模型怎么调用工具的问题它可以让 RAG 变成“服务化”的能力但服务背后仍然需要这样一条数据管道。认清主干后面加什么花活都不慌。1.3 一次失败项目复盘这里拿我参与过的一个企业制度问答项目举例复盘一下“只盯中游”的典型案例。当时客户给了几百份 PDF 规章制度里面有大量表格比如请假审批权限表、报销金额分级表。我们第一版直接把 PDF 用通用文本提取库抽出来表格内容被拍平成一行行碎片然后又按固定字符数 512 切成 chunk灌进向量库。用户问“年假和病假连着请审批权限按哪个标准走”系统召回的 chunk 是政策文件首页和末尾的附则因为那些地方的文本和“年假”“病假”有字面重叠真正的权限表却被切成了不完整、无语义的碎片。最终大模型只能靠通用知识硬编答案看起来通顺但完全不可用。后来整改时我们把 PDF 解析换成表格结构识别将表格转成 Markdown 或 HTML 保留行列关系分块改成按标题层级做父子块查询时先按章节过滤再向量召回。同样的问题召回结果从“目录页 附则”变成了真正包含权限表的那一章。这个项目给我的教训很深解析和清洗才是 RAG 的地基分块和向量化只是在地基上砌墙。2. 上游环节采集、解析和清洗往往吃掉你 60% 的工时如果你做的是工具类产品比如“上传文件然后问答”用户上传的文件格式极其混乱解析环节的复杂度会远超预期。即便做企业知识库数据源相对可控解析也绝不是调用一个库那么简单。2.1 文件解析的坑PDF 表格、扫描件、Word 样式、Excel 合并单元格先说 PDF。PDF 本身是一种排版格式不是天然的内容流。同样是打开一个 PDF文本型 PDF 可以直接抽字符但排版顺序常常是乱的扫描型 PDF 实际上是图片你直接抽文本只会得到空白带表格的 PDF 更麻烦表格线和单元格里的文字在底层对象里可能是零散的线条和文本框。应对这类问题我习惯分层处理文本型 PDF 用 PyMuPDF 或 pdfplumber 提取优先保留坐标信息方便判断同一行、同一表格区域。扫描型 PDF 走 OCR常用 PaddleOCR 或开源的多模态解析模型。表格密集型 PDF 要用“表格识别”而不是全局文本流把表格识别成 HTML/JSON 结构保留行、列、合并单元格。再强调一次表格识别的重要性怎么高估都不过分。业务文档里的高频信息比如审批权限、费用标准、产品参数几乎都放在表格里。如果表格被拍平成“字段 值”的流水文本语义关系直接丢失。Word 文档的问题在于“看着有标题实际没标题”——很多人用手动加大字号代替样式。解析时如果只按样式提取会把正文和标题混在一起分块的层次感就没了。我的做法是解析时同时对常见样式名做映射并且做一层启发式判断比如“字号更大、加粗、独占一行”就当成标题候选。Excel 的坑集中在合并单元格。合并单元格在解析结果里往往只有第一行有值其余行是空值或 NaN。正确做法是显式展开把左上角的值填充到整个合并区域再用“行转记录”的方式转成结构化内容。很多客服知识库的源数据是 Excel 表格不做这一步问答系统连“这个产品支持哪些地区”这种基础问题都答不对。2.2 清洗策略去重、去噪、敏感信息与编码问题清洗的目的不是“把中文变成漂亮的话”而是让后续分块和向量化拿到最小噪声单元。先说去重。同一份文件可能在不同目录分别存储网页版和 PDF 版内容高度相似这些相似 chunk 进入索引后检索时会出现“同一条知识被召回三份”的情况。精确去重容易算哈希即可真正的难点是近似去重比如同一篇公告的 PDF 版和 OCR 版字符有细微差异。工程上可以用 MinHash 或 SimHash 做近似指纹阈值控制在 0.85 左右比较合适。再说噪声。页眉页脚、页码、目录、导航栏、免责声明这类内容如果不去掉分块时经常会产生一种“通用 chunk”——比如每个页面都被切出一块必含页眉页脚的内容检索时它们会频繁命中挤掉真正有价值的知识。我见过一个极端案例向量库里有 30% 的 chunk 都包含同一段版权声明任何查询都可能把这些噪声召回到 top 5。解决方式是在解析阶段做区域检测PDF 可以按页面上、中、下三个区域做规则过滤HTML 可以按标签类型过滤 header/footer/nav。敏感信息和编码问题也必须在这个环节处理。涉及个人电话、地址、身份证号的文档不能直接把原文灌进向量库否则后续查询可能无意中带出这些信息。编码方面中文场景最常见的坑是 GB18030 和 UTF-8 混用读取时一定要指定编码并做异常兜底否则你会得到一堆“锟斤拷”。还有一点容易被忽略文本里的全角/半角、不可见字符、零宽字符会干扰相似度计算清洗时建议统一 normalize。2.3 元数据检索里最大的杠杆清洗完之后我强烈建议保留一套完整的元数据而不是只留“文件路径 页码”。至少包括来源文件名、文档类型、标题层级路径、章节路径、页码或行号范围、更新时间、业务归属比如部门、品类、权限标签。元数据在检索端的价值远比你想的大。第一它可以做过滤条件比如“只看市场部的公告”“只看最近一年的制度”在向量相似度之外加硬性约束直接砍掉大量无关候选。第二它可以做引用溯源大模型回答后能给出“来源XX制度第 3 章第 2 节”可信度明显提升。第三它是权限控制的基础向量库里的内容按部门或密级打标查询时就能做行级过滤。换句话说没有元数据向量化只是给每个文件盖了盲章的图章有了元数据检索是在一个带目录、带分类、带权限的档案室里翻材料。很多人说自己的 RAG 结果不够准我第一反应就是去看有没有用上元数据过滤。3. 中游核心分块与向量化的正确打开方式这个部分读者期待最高但我想先泼一点冷水不要迷信任何一种“最优分块算法”。分块策略必须跟着文档结构和问答场景走脱离数据谈参数都是空谈。3.1 分块不是“按字数切一刀”固定字符数分块最简单也最常见但它最大的问题是会把一个完整的语义单元拦腰截断。比如一段 800 字的操作流程按 512 切第一块的结尾正好停在“步骤五”之前第二块成了没头的半截操作检索时无论命中哪一半LLM 都拿不到完整流程。比较实用的几类策略结构化感知分块先识别 Markdown 标题、列表、代码块、表格等结构节点以标题和段落为边界切块。如果文档有明确的章、节、条那么这些天然边界就是最好的 chunk 边界。父子分块父块保存完整上下文通常是一个章节子块从父块内部再切细一点比如段落级别。检索时命中子块返回给模型时带父块上下文。这种方案特别适合制度、手册类文档查询“审批权限”时能同时拿到具体条目和所属章节。滑动窗口重叠相邻 chunk 之间保留部分重叠避免边界切断语义。重叠比例一般取 10% 到 20%太大浪费存储太小等于没重叠。语义分段用 embedding 对句子做聚类在语义断点处切分。效果不差但计算成本高适合文档结构本身不清晰的情况。分块大小也要结合模型上下文一起看。如果最终要给 LLM 的上下文窗口只有 8K token那你传给它的 top-K 个 chunk 总长必须留出回答输出的余量。我一般控制单块在 300 到 800 token 之间具体数值根据内容形态来操作手册类偏小制度规范类偏大代码类单独按函数或代码块切。3.2 Embedding 模型选型实践Embedding 模型选型核心看三点效果、服务化成本、与业务的匹配度。中文场景里BGE、BCE 这批开源模型效果已经足够好没必要一上来就调用付费闭源 API尤其是知识库可能有敏感数据时自部署更稳妥。自部署的一个现实问题叫“向量化服务器”GPU 和 CPU 的吞吐量差别很大BGE 系列在 GPU 上可以跑出几百 QPS但 CPU 可能只有几十 QPS。如果你的管道需要一次性灌入几百万份文档建议用批量任务把向量化做成异步服务而不是在写入链路里同步调用。模型维度也需要留意。768 维是常见选择但很多新模型支持 Matryoshka Representation Learning可以输出更小维度比如 256 维。维度越小向量库的存储和计算成本越低但效果会有轻微损失。我的习惯是新项目先用 768 维跑评测如果存储成本吃紧再降维测试用评测数据说话而不是拍脑袋。还有一个小细节使用 cosine 相似度时务必在向量化之后做 L2 归一化。很多向量数据库默认计算余弦相似度但如果你的模型输出没有归一化或者你和 BM25 分数直接相加时量纲不一致结果会变得很怪。归一化统一了尺度后面做加权融合才不容易翻车。3.3 向量索引与混合检索向量化只是把文本变成数字真正支撑检索的是索引结构。目标是万级以下的小知识库用暴力检索都行到了百万级HNSW 是默认选择它把检索时间复杂度从 O(n) 降到近似 O(log n)。配置 HNSW 时M 值越大内存越高、召回越准efConstruction 影响建库速度efSearch 影响查询精度。我通常会先开一波默认参数再用评测集扫一遍召回率不要盲目追求高精度导致内存失控。IVF 系列索引在某些场景内存占用更低但训练聚类和查询调参比 HNSW 繁琐没有特殊原因不建议新项目直接上。但只靠向量索引远远不够。向量检索擅长语义相似不擅长精确关键词匹配。比如你搜索“报销”但文档里写的是“费用核销”向量模型可能知道二者相关反过来你搜索型号“A10-3000”文档里全是“A10-3000”的精确描述向量检索却可能因为上下文差异把更相似的噪声排前面。这时候 BM25 这种稀疏检索更好使。所以现在的工程实践基本都走向混合检索一路用向量模型做稠密检索一路用 BM25 或稀疏向量做关键词检索最后把两路结果融合。融合方式最常用的是 RRFReciprocal Rank Fusion把两路排名的倒数分数相加简单稳定不需要校准分数也可以用权重加权但权重需要针对业务场景反复调。我在落地时偏爱 RRF省心而且不容易被某一路的极端分数带偏。4. 下游与迭代检索、重排、评估与知识库更新如果中游解决的是“切得好不好、向量准不准”下游解决的则是“怎么从一堆候选里捞出真正有用的内容”以及“如何让系统越用越准”。4.1 检索策略top-K、阈值、HyDE 与查询改写检索端最常见的错误是直接 top-K5 然后传给大模型。这有几个问题第一向量召回的第一名经常是字面相似但语义不对的噪声第二真正有用的内容可能在 20 名开外。因此实战中我通常先把召回数量放大到 30 到 50 条经过过滤、重排后再取前 5 条喂给 LLM。相似度阈值这里多说一句。很多教程让你设一个阈值低于阈值的都丢弃但这个阈值在不同数据集上的分布完全不同同一模型对同义改写和无关文本的分数差距也很微妙。我建议不要一开始就给全库设统一阈值而是基于一批真实查询先统计分数分布再决定一个安全的底线。否则要么误杀可用内容要么阈值形同虚设。查询改写也值得做。用户问题往往是口语化的 “那个年假剩几天怎么查来着”。直接拿这句话去检索效果远不如改写后的“查询剩余年假天数”。HyDE 的思路则是让 LLM 先生成一个假设性回答再用这个回答去检索——在某些场景下能显著提高召回但增加了延迟和成本适合离线分析或对实时性不敏感的后台。多查询Multi-Query也是类似思路把一个问题拆成多个子查询分别检索再合并结果适合复杂任务型问答。4.2 Rerank 值得加吗我直接给结论如果你的问答场景对准确率敏感Rerank 是性价比最高的一个组件。所谓 Rerank是在向量和 BM25 召回几十条候选之后用一个更重但更准的模型通常是交叉编码器对候选重新排序。交叉编码器把“查询 候选文档”拼接后一起编码能建模细粒度的交互关系效果远胜于双塔式的向量检索模型。代价是慢。交叉编码器需要对每个查询和候选对都计算一次假设候选 50 条就是 50 次编码延迟明显上升。所以实践中要把握好两步召回阶段扩大候选池重排阶段缩小到最终 5 到 10 条重排模型部署在独立服务上必要时走 GPU。开源方案里 bge-reranker 这类中文模型就跑得不错。有一种情况我对 Rerank 特别推崇知识库里的内容差异很小比如几十条政策看起来都在讲“报销”。纯向量召回时top 10 几乎都是同一主题真正回答用户具体问题的那一条可能排在第 11。加上 Rerank 之后交叉编码器能区分“报销申请流程”和“报销标准”的细微差异顺位一下子就能拉对。4.3 评估指标体系离线指标与线上反馈RAG 的评估是个不算新但始终做不彻底的话题。我的建议是分两层离线评测集和线上反馈。离线评测集不用贪大20 到 50 条真实问题就能暴露出大部分问题。每条问题需要标注标准答案对应的文档片段、是否允许拒答、预期答案要点。离线指标里最基础的三个是命中率正确片段是否在召回结果里、MRR正确片段的排序位置、忠实度生成答案是否完全基于召回内容且没有幻觉。忠实度评估一开始只能人工看后来可以借助 LLM 做 NLI 判断但要注意别让评判模型本身成为不确定因素。我的做法是三重校验人工标注 20 条、LLM 评判全部、再抽查边缘 case 人工复核三者对不上的就单独分析。线上反馈层面必须在产品里埋点用户对回答点赞/点踩、是否复制了引用来源、是否发起追问。点踩的 query 自动进入“待分析池”每周从里面挑新增的失败案例补进评测集。有了这个循环知识库会越跑越贴合真实用户。4.4 知识库更新与管道自动化数据是活的知识库必须能更新。最原始的做法是全量重灌每天晚上把所有文档重新解析、分块、向量化然后重建索引。优点是简单缺点是资源消耗大而且一旦灌库期间有查询可能出现结果不一致。更好的做法是增量更新。文档接入时计算哈希只有内容变化的文件才重新解析删除的文件从索引和向量库中同步标记删除新增的文件通过消息队列进入管道。这里要注意一个容易踩的坑向量库的 upsert 需要稳定的主键。很多人用“文件名 页码 分块索引”当主键看起来没毛病可一旦文件里某页新增了一行所有后续分块都变了主键就失去了稳定性。比较稳妥的做法是给每个 block 生成一个内容哈希或者使用带版本号的主键并保留旧版本用于回滚。自动化层面我习惯把管道拆成几个幂等任务采集任务、解析任务、清洗分块任务、向量化任务、索引写入任务。每个任务都可以单独重跑任务之间用消息队列连接。这样任何一个环节失败只需要重跑该环节而不用全量重来。5. 端到端工程实践一套可落地的数据管道前面的章节偏原理这一节给出一套我在中小型项目里反复使用的落地方案。技术选型不一定是最炫的但一定是改动成本低、可观测性强的。5.1 组件选型参考我习惯把“解析”“向量化”“索引”“重排”拆成独立服务组件选型大致如下环节常用方案说明文档解析PyMuPDF / pdfplumber / PaddleOCR / MinerU文本型 PDF 和扫描型 PDF 要分开走清洗与分块自研脚本 LangChain/LlamaIndex 的分块工具清洗一定自研分块可以借框架向量化BGE-M3 / BCE 等开源模型自部署服务按吞吐量决定 GPU/CPU 资源向量库Milvus / Qdrant / Elasticsearch数据量小用 Qdrant复杂业务用 Milvus混合检索Elasticsearch BM25 向量库 RRF也可用支持混合检索的 Qdrant/Milvus 新版本重排bge-reranker 等交叉编码器独立服务避免拖慢检索主链路编排Python 脚本 消息队列 定时任务优先保证幂等和可重跑这套选型的核心原则是不过度集成。LangChain 之类的框架适合快速验证流程但在生产环境里框架的抽象层反而会拖累调试。我的做法是借框架的函数比如分块器、文档加载器但整体管道流程用原生 Python 控制日志和错误传播都能清清楚楚看到。5.2 Pipeline 代码骨架下面是一个简化的数据管道骨架重点在于展示各环节的接口边界而不是完整实现def process_file(path: str, store: VectorStore): # 1. 解析 raw_blocks parse_document(path) # 返回带结构信息的块列表 # 2. 清洗 clean_blocks [clean_block(b) for b in raw_blocks] # 3. 分块与元数据 chunks semantic_chunk(clean_blocks) # 按标题/父块结构切分 # 4. 向量化 for chunk in chunks: chunk.vector embed(chunk.text) chunk.id stable_hash(chunk) # 5. 写入索引 store.upsert( idchunk.id, vectorchunk.vector, textchunk.text, meta{ source: path, section: chunk.section, updated_at: chunk.updated_at, } ) def query_pipeline(query: str) - list[str]: rewritten rewrite_query(query) # 可选查询改写 dense_hits vector_search(rewritten, top_k50) sparse_hits bm25_search(rewritten, top_k50) fused reciprocal_rank_fusion(dense_hits, sparse_hits) reranked rerank(query, fused, top_n5) # 交叉编码器重排 return [hit.text for hit in reranked]这套骨架跑通之后你会发现后续调优都是局部替换解析环节换更强的表格识别、向量化服务升级成多卡版、检索融合从 RRF 换成加权……每个环节都有明确边界不会互相干扰。5.3 参数调优经验参数调优没有银弹但有一套高投入产出比的顺序。第一步先调解析和清洗因为这个环节的错误会传导到后面而且调起来最便宜无非是改规则、重跑、对比块内容。第二步调分块策略重点看召回的正确片段是否完整落在一个块内如果经常跨块就要调整分块边界或加上父块回传。第三步才是向量化和向量库参数因为前两步不改embedding 调得再精细也是白调。分块参数的对照我列一个小表方便你快速定位业务文档特征推荐策略分块大小操作系统/流程手册按步骤或段落切可配滑动窗口300-500 token制度规范、条例父子分块检索用子块、回传用父块500-800 token商品手册、产品参数结构化感知表格保留 JSON/Markdown按表格或字段组切代码库文档按函数/类边界切按代码块边界检索参数上我的默认起点是召回 50 条 - RRF 融合 - Rerank 取 top 5。如果你没有独立的 Rerank 服务也可以先用召回 20 到 30 条 加权融合的代替方案效果略逊但成本能控。延迟目标方面单次查询总耗时尽量控制在 1 到 2 秒内其中 Rerank 占大头如果超过 3 秒用户已经明显感觉到卡建议把候选池缩小或重排模型换小一号。6. 常见问题与排查技巧实录最后这部分是我在多个项目里反复遇到、几乎每个团队都会踩一遍的问题直接按“症状 - 原因 - 解法”的格式写方便你排查时对照。6.1 为什么表格检索总是一团糟症状问“不同等级的报销限额是多少”答案不是缺列就是错行甚至张冠李戴。原因解析阶段表格被拍平成纯文本行列关系丢失或者分块时表头被切到上一个 chunk导致后面的数值不知道属于哪一列。解法优先从解析端修复把表格识别成 Markdown 或 HTML保留表头和行列结构。如果已经在库里了需要确认这批数据是否得重建索引。无脑加长 chunk 解决不了问题因为表格的语义是二维的不是靠长度能保住的。另一个实践技巧是对表格类知识额外加一层“表头上下文”比如把列名拼到每个单元格描述前让向量模型更容易对齐关系。6.2 召回不准而且重复多症状同一个查询返回的 top 5 里有两三条内容几乎一样或者全是泛泛的背景介绍真正细节的那条反而排不上来。原因大概率是语料没有做好近似去重相似文档被多次写入索引其次可能是分块边界不佳产生了大量“通用块”。解法先跑一遍全库相似度统计把近似重复的块合并或移除。这个操作对召回率的影响肉眼可见尤其当一个来源同时存在 PDF 版、Word 版和 OCR 版时。分块侧记得过滤掉页眉页脚等高频噪声块并考虑给高质量的实体型内容比如表格、列表更高检索权重。你还可以在融合策略里用 MMR 增加多样性避免 top 5 全是同一出处的内容。6.3 更新删除之后旧数据还在症状文档更新后老问题和老答案还在。明明删掉的文件检索里依然会出现。原因多数是主键策略出了问题。如果主键用的是“文件名 编号”文件内容变化后编号没变旧向量没有被覆盖或者文件删除时没有触发索引清理。解法保证每个 chunk 的主键是内容稳定的哈希比如对“清洗后的块内容 章节路径”取哈希。变更时用 upsert 覆盖删除时通过元数据过滤 删除接口同步清理。另外我强烈建议做“知识库快照”每次全量重建前把当前索引导出一份备份出问题可以直接回滚。千万不要让用户问出“你今天是不是又偷偷把老资料删了”这种尴尬问题。6.4 管道的成本与延迟优化症状整条链路跑完要 5 秒或者每次更新重灌占用大量 GPU 资源老板开始过问成本。原因向量化服务和查询链路没有分离或者批次太小也可能是每次更新都做全量重灌没有走增量还有可能是 query 阶段候选池太大且没有缓存。解法向量化做成异步批量服务不要在写入主流程里同步等嵌入结果。查询阶段加一层语义缓存同义或高度相似的问题直接命中缓存不用再走检索和重排。如果线上流量大把 Rerank 模型缩到最小可用版本或者允许低频时段离线预先计算部分热门查询。成本这种事一定要先量化再优化我一般把“单次查询成本”和“单次更新成本”两个数字盯死优化目标才有抓手。6.5 问题速查表现场可能原因优先处理动作表格内容答错解析阶段表格被拍平换表格识别方案重建相关索引结果全是噪声索引里有大量页眉/页脚/模板文本清洗阶段增加区域和模板过滤相似文档重复召回没有做近似去重引入 MinHash/SimHash 去重旧内容删不掉主键不稳定改用内容哈希作为主键查询太慢召回池过大、重排无缓存缩小候选池加语义缓存答案有幻觉喂给 LLM 的上下文不足或冲突扩大召回重排增加引用来源这张表不是标准答案但大概率能覆盖你上线头一个月遇到的八成问题。剩下两成就需要你回到数据管道本身一个环节一个环节地加日志、看样例、量指标。最后分享一个小习惯做 RAG 这几年我养成了一个算不上聪明但极其有用的习惯每次改完解析规则、分块参数或向量模型都会用同一套 50 个真实问题从头跑一遍评测并记录命中率、MRR 和忠实度三个数字。哪怕只是把重叠比例调了 2%也要跑。这套固定评测集帮我挡住了好几次“看起来合理但落地无效”的改动也让我在团队争论哪种方案更好时不用吵直接看数据。数据管道全流程这件事听起来不如“换一个更好的 embedding 模型”那么性感但真正的效果提升往往就藏在这条流水线上每一个被人忽视的细节里。