企业官网建设流程全解析

1. 先说结论：检索命中只是必要条件，不是充分条件

前阵子在调试一个法律条文问答的RAG项目，遇到了一个特别有意思的case：用户问“同一份合同里，违约责任条款和争议解决条款冲突时，以哪个为准”，RAG检索阶段稳稳当当召回了合同原文里对应片段，相似度打分还不低。结果模型给出的答案是“以违约责任条款为准”，而合同原文白纸黑字写着“如本协议条款存在冲突，以争议解决条款为准”。检索没问题、模型也没瞎编，答案就是错的。

这种“检索全对、答案全错”的情况，在实际项目里出现的频率远比想象中高。很多团队在做RAG落地的时候，习惯把注意力全放在召回率上，拼命调embedding模型、调chunk大小、调Top-K，以为“检索到的内容对”就等于“答案对”。但检索只是把材料摆到桌面上，真正决定答案对错的，是整个从“材料”到“结论”的推理链路。

我拆过不少类似的问题，总结下来，答案出错的原因基本可以归为四类：检索到的内容本身就不支持答案、检索结果把模型带偏了、模型压根没好好用检索到的内容、以及检索的内容被其他信息干扰了。下面逐个展开说，每一类都会配上实际调试中遇到的案例。

需要先明确一个前提：RAG系统的“正确答案”取决于两件事——有没有把必要的信息找回来，以及能不能让生成模型从这些信息里推出正确的结论。前者是检索问题，后者是生成问题，但两者不是割裂的。很多时候生成出错，根子却在检索阶段就埋下了，只是表面上看检索“命中”了而已。

2. 检索阶段的三类“假命中”，比召回不到更坑

2.1 语义相似不等于事实支持，命中的片段里根本没有答案

最典型的坑是：检索系统返回了一个和问题语义高度相关的片段，文本里充满了和问题重合的关键词，但仔细看内容，它并没有回答问题。

举个实际的例子。我在做一个医疗科普问答RAG，用的是公开的医学指南和药品说明书。用户问“布洛芬和对乙酰氨基酚哪个更适合儿童退烧”，embedding检索召回的Top-5里前两条都是关于两种药物各自退烧机制的科普段落，文本里确实同时出现了“布洛芬”“对乙酰氨基酚”“儿童”“退烧”，语义相关度打分非常高。但这两段内容完全是平行介绍，根本没有做对比，更没有给出“更适合”的结论。模型硬着头皮去答，就只能凭训练时的知识去补，这时候如果它补错了方向，就是典型的“检索命中但答案错误”。

这种问题有一个非常误导人的特点：如果你是人工随机抽查Top-5的检索结果，你会觉得“检索结果挺好的，每一条看着都相关”，从而把问题归到生成模型不够聪明上。但事实上，检索返回这些内容本身就不合格——任务需要的是能支撑某个结论的“判断依据”，而不是仅仅是“相关背景信息”。

判断方法其实很简单：把检索到的片段当成唯一的知识来源，问自己“只凭这段文字，能不能直接推出问题的答案”。如果不能，这个片段就不应该被当作有效命中。我后来在调试项目里做了一个小工具，把每个查询的召回片段分成了三类：直接支撑答案的、提供背景但无结论的、纯噪音。结果发现，很多“看起来还行”的检索结果里，真正直接支撑答案的片段占比不到一半。

怎么解决这类问题？靠调Top-K没用，多召回来的更多是背景信息；靠换embedding模型也只能缓解语义匹配的精度，解决不了“语义相关但事实不支撑”的结构性问题。更有效的做法是给检索阶段加上意图理解——先判断用户的问题类型是“事实查询”“对比判断”还是“操作步骤”，不同类型的查询对文档的要求不一样。例如对比判断类问题，最好能把支持对比结论的信息尽量集中到同一个chunk里，或者用后续的重排模型专门去挑“包含双方信息且有明确结论倾向”的片段。

2.2 检索单元颗粒度不对，正确答案被切成碎片了

这是RAG项目里最隐蔽的问题。chunk切得太粗或者太细都会导致问题，但“太细”带来的问题尤其容易被误判成模型问题。

我之前做一个企业内部制度问答系统，文档是员工手册，每一条制度用表格编号区分。初期我把chunk size定得很小——大概150个Token左右，想着这样检索精度高、上下文占用少。结果用户问“出差报销需要提前多久提交申请”，检索出来的是“出差报销流程——申请阶段：需提前三个工作日提交申请”这个片段，看起来非常完美，但模型还是答错了，因为它把“三个工作日”理解成了“三个自然日”。为什么？因为这个chunk里没有写“工作日定义：以公司考勤系统为准，不含周末及法定节假日”，而那条规定在另一个chunk里。

问题就出在：答案需要的信息横跨了多个chunk，但检索系统把每个chunk当作独立单元打分，没有哪个单独的chunk能提供完整答案。模型真正需要的其实是两个chunk的“合体”，但RAG架构里，如果两个相关的片段被分到了不同的chunk且Top-K不够大，模型就只能看到其中一个。

这就是chunk粒度带来的两难：切得细，检索命中率高，但信息碎片化严重；切得粗，信息完整性好，但混合了太多噪音拉低检索精度。我最后的做法是放弃“全网统一chunk size”，改成结构化切分——按文档的语义边界（编号条目、表格行、段落层级）来切，并且在需要跨条目才能回答的问题上，专门做了一步“子块聚合成片段”的后处理。这里面有个很关键的细节：如果你直接调大Top-K来应对信息碎片化，往往会引入大量无关内容，反而给模型更大的发挥空间，让它更容易走偏。

2.3 召回排名没错，但顺序反而把最强的证据放到了后排

还有一个很容易被忽视的问题——检索结果的相关性排序本身可能是“对的”，但对生成任务不友好。

Transformer模型处理上下文时有明显的近因效应和注意力衰减。你把最有支撑力的那个证据片段放在第7条，把两条勉强沾边的背景信息放在第1、2条，模型在有限的注意力窗口里，对前排内容的重视程度远高于后排。这种时候，检索的Top-K完全没有过错，排名算法按相似度打分也没错，但答案就是容易被前排的“次相关但先出现”的内容带偏。

这事我在一个论文问答项目里感受特别深。用户问“这篇论文的实验用了什么数据集”，论文正文里有明确数据集的段落，那个段落里同时提到了数据集的来源、规模和预处理方式。但另一段讨论相关工作的地方也提到了同一个数据集的名字。embedding模型给相关工作的打分比正文段落还高，结果模型回答的时候，把相关工作部分提到的数据集规模当成了正文实验的答案，数字差了好几个量级。

解决这个问题的思路是：不要把“召回相关性”直接当“生成顺序”。有条件的项目，应该上一套reranker（重排模型）专门调整上下文顺序，而且重排的目标不是“继续提高相关性”，而是“确定支持度优先级”。这类问题的排查思路比普通的相关性调优更值得投入——因为它是检索和生成这两个环节之间的“接口问题”，是很多RAG项目从能用走向好用的分水岭。

3. 生成阶段的两个“背叛”，模型拿到了证据却不照着说

3.1 上下文太长，关键信息被淹没在噪音里

很多人以为RAG的上下文越长越好，把Top-K拉到10、15，把一堆弱相关的片段全塞进去，觉得“反正模型自己会挑重点”。但实际上，上下文窗口的注意力是有限的，段落越多，模型越难准确聚焦到真正有决定性的那个片段上。长尾噪音上下文不仅不能帮助回答，反而会稀释证据权重。

我做过一个A/B对比测试，同一个问题、同样的知识库，只改Top-K：Top-3的时候准确率82%，Top-7的时候准确率掉到了58%。不是检索变差了，Top-7里完全包含了Top-3里的正确答案，但多余的4个弱相关片段把模型“带跑”了——它开始引用更靠后的、其实不太相关的片段来凑答案，引着引着就错了。

具体到场景里：出错最多的是故障排查类问答。用户问“邮件服务器返回530错误怎么处理”，知识库里有几篇操作手册，其中一篇明确写了530对应的认证失败根因和解决步骤，但另外几篇手册里提到了SMTP端口配置、SSL证书过期、IP黑名单等其他问题，这些内容也包含关键词“邮件服务器”“530”，被embedding判断为相关并送进了上下文。模型为了显得全面，把端口配置、证书问题全扯进来了，最后的回答用了一堆正确但不对应的操作，用户照着做了半天没效果。

这类问题有一种很误导人的表现——单看模型的答案，每一句单独拎出来都是“对的”，连在一起却不是用户要的答案。这就是典型的上下文调度问题：模型不是没有找到正确答案，而是被旁边的错误选项吸引了注意力。解决方向有两个，一是严格控制Top-K，二是做“相关度闸门”，低于某个阈值的片段干脆不送进上下文，宁缺毋滥。

3.2 模型在补全而非推理，幻觉本质上是对“结构缺口”的填空

另一种生成阶段的背叛更隐蔽，也更难治：模型拿到了一条相关但不够完整的证据，它不是一个字一个字照抄证据，而是把证据当作“灵感”，然后用自己的训练知识去把“没说完整的话”补完。补的时候如果训练知识恰好是对的，就是成功案例；如果恰好是错的，就变成RAG幻觉。

典型的例子来自法规问答。系统检索到了《劳动合同法》的某一条：“用人单位自用工之日起即与劳动者建立劳动关系”，用户的问题是“没签合同但工作了三个月，算不算事实劳动关系”。检索片段其实已经能支持“存在劳动关系”这个结论，但模型为了回答得更完整，脑补了一句“劳动者可以主张双倍工资”，而这个结论在法条原文中并未出现，是需要额外法律依据才能推出的——如果没有检索到那条依据，模型凭训练知识的记忆去补，经常会把适用的前提条件搞错。

这种问题的Debug很有迷惑性，因为肉眼看去上下文和答案是“相关”的，错觉就是“RAG系统工作正常”。要区分模型是“推理”还是“补全”，有一个简单的测试方法：把上下文里的关键证据删掉，再看模型回答，如果它给出的答案依然高度相似，说明它根本没依赖检索内容，是在靠自己的训练记忆作答——这就意味着，即便检索对了，模型的输出质量也不可控。

要缓解这个问题，光靠换更强的模型不够，因为补全习惯是LLM的天性。真正有效的做法是在提示词里明确“每个结论都必须引用证据片段编号”，同时在应用层做一个规则校验：答案里出现的核心事实，必须在证据片段里有对应文本支撑。这个策略不能100%拦住所有幻觉，但能把相当一批“凭记忆补全”的错误拦在发布前。

4. 指令与解析层的错位：上下文对了，模型却理解错了要干嘛

除了检索和生成内部的机制问题，还有一类错误是从系统设计层面引入的——你把正确答案送到了模型面前，但指令没有说清楚该怎么用这个答案。

举个例子。一个旅游攻略RAG，用户问“京都玩三天，怎么安排行程比较合理”。知识库里有几篇质量不错的攻略，检索也正确命中了。但系统提示词写的是“基于以下资料回答问题，如资料中无相关内容请如实告知”。模型看到这个指令，默认的执行逻辑是“摘录式回答”，它就照着攻略原文把三天的行程摘抄了一遍。但如果用户问的是“对比两篇攻略哪篇更适合带老人出行”，摘录式回答就会漏掉“台阶多不多”“要不要走山路”这些判断维度，模型没有主动从原文推导这些结论，答案虽然每句话都对，但整体上答非所问。

这种问题在RAG项目中极其常见，而且特别容易被当成“上下文不够好”来排查，浪费很多时间去调embedding，最后发现根本不是检索的事。

还有一种错位来自对“否定表达”的处理。知识库里明确写着“该功能不支持在移动端使用”，用户问的是“这个功能在手机浏览器上能用吗”，检索命中了同一段话，但生成时模型可能因为否定句在长上下文里被弱化，把意思理解反了。

指令层的错位，本质上是对“模型角色”的定义过于宽泛。一个通用的RAG系统，如果提示词只写“根据上下文回答问题”，那模型在大量任务上都会采用默认的“文本摘要”模式，而不是“推理判断”模式。更好的做法是针对高频问题类型分别提示：对于对比类问题，告诉模型“必须指出差异点，禁止含糊地说各有优势”；对于操作步骤类问题，告诉模型“必须按顺序输出，禁止跳步”。不区分任务类型、一套提示词走天下，遇到复杂问题基本都会吃瘪。

5. 检索结果之间的相互矛盾，模型没有能力自行仲裁

这一块很容易被忽略，因为多数RAG项目用的是静态知识库，大家默认知识库里的内容是一致的。但实际业务里，知识库本身往往充满了表述差异、版本差异甚至直接冲突的内容——而RAG把多段互相矛盾的文本一起送进上下文之后，模型就处在了一个非常尴尬的位置：它不知道该听谁的。

我遇到的一个非常具体的例子是客服知识库里同一个产品的退货政策，FAQ页面写“支持7天无理由退货”，商品详情页写“定制类商品不支持无理由退货”。用户问的是“这个定制刻字的杯子能退吗”，检索系统把两个页面都召回了，相似度都很高，Top-1还是FAQ那个“7天无理由”。模型读完之后，倾向于取出现次数多、表述更绝对的那句——“7天无理由”，给了错误答案。

从检索的角度看，召回这两个页面都没有错，它们是知识库里的真实内容。错误发生在“用一段相对模糊的指令，让模型在互相冲突的文本中自行判断”。LLM虽然没有真正的“判断力”，但它会基于统计偏好做选择——哪个说法在上下文中更多、更显眼、更接近通用常识，它就容易倾向于哪个。

面对这种情况，工程上的处理逻辑很简单：RAG系统不应该把“文档仲裁”的责任留给生成模型。系统在把上下文交给模型之前，应该先做一层冲突检测。如果检测到多个高相关片段之间的结论相互矛盾，应该要么触发版本优先规则（例如发布日期较晚的覆盖较早的），要么把冲突片段同时交给模型，让它把两种说法都呈现给用户，而不是替用户做选择。

这个观点在群里跟几个做RAG的朋友交流过，有人说这种做法太“重”了，成本和复杂度都高。从实际效果看，我的体会是：对于面向C端客服的知识库，不做冲突处理，错误率是很稳定地偏高；做了冲突检测之后，至少能把“答错方向”的比例降下来一大截。因为大量用户问题本质上都是“这几个说法之间到底以哪个为准”，这恰恰是最需要规则介入、也最不该交给模型自由发挥的场景。

6. 从“找到相似”到“答对问题”：一套可落地的分层排查清单

讲了这么多问题类型，最后整理一个我实际用下来的排查思路。碰到“检索正确但回答错误”的情况，不要一上来就换embedding模型，按下面这个顺序逐层排查，大多数情况下能找到根源。

第一层：回看检索结果，做“证据支撑度”判断。把Top-5的检索片段拉出来，逐个做以下标注：这个片段能不能直接推出问题的答案？如果只能推出背景信息，标记为弱支撑；如果完全不能推出，标记为无关。如果弱支撑片段占多数，那就不是生成的问题，而是检索策略的问题，重点去调整chunk切分方式和查询改写。

第二层：检查上下文排序，确认最强证据是否在靠前位置。把强支撑片段放在Top-1、Top-2，弱支撑和背景片段放在后面或直接剔除。这一层不用改检索逻辑，只需要在拼接上下文阶段做一个排序干预——如果你有reranker，优先看它能不能把强证据顶到最前面；如果没有，手动写一个“证据优先”的规则也比直接让模型在长上下文里自己找要稳得多。

第三层：单测模型在“只有标准答案片段”时的表现。构造一组“黄金上下文”：只放一条确定正确、直接可用的知识片段，让模型基于它回答问题。如果这种情况下模型还答错，说明生成阶段的故障是独立的，可能是提示词写得不够明确，也可能是模型本身的推理能力不够，需要换更大的模型或细化指令。如果黄金上下文下回答正确，说明生成能力没问题，问题一定出在检索阶段喂进去的上下文上。

第四层：检查指令类型与问题类型的匹配度。整理一段时间内的错误case，把问题分成事实型、对比型、操作型、判断型几类，分别看提示词是否对每类问题给出有针对性的执行指令。如果某类问题的错误率系统性偏高，九成是指令设计问题，而不是检索问题。

第五层：做一次小规模的“人肉Ablation”，删掉冲突片段看变化。把知识库里相互矛盾的内容临时屏蔽掉，重新跑一遍之前出错的问题集。如果错误率明显下降，说明问题出在知识库内部的冲突数量上，你需要的是冲突检测或版本覆盖机制，而不是去优化检索模型。

这个排查链路我每次在项目Debug的时候都会走一遍，通常走到第二层或者第三层就能定位到80%以上的问题。真正到了第五层才发现原因的，往往是知识库本身质量堪忧——那种情况，你换任何模型、调任何参数都救不回来。

7. 项目落到最后，真正让我觉得值回票价的三个改动

前面讲了很多原理和排查方法，这篇博客最后说三个实操过程里改动收益最大的地方。

第一个改动是给检索结果加了“证据支撑度”标注。每个片段在进上下文之前，用一个轻量级分类器判断它跟当前问题之间的关系类型——是直接证据、背景信息还是无关内容，然后按这个标注调整上下文拼接时的权重顺序。这个改动不大，但对错误率的下降非常明显，因为它等于强制干预了模型对上下文的“注意力分配”。

第二个改动是把Top-K从固定值改成了动态值。根据第一个证据的相似度得分决定继续追加几个片段——如果最强的证据已经很明确（得分远高于阈值），就少放几个；如果最强的证据也不够强，就多放几个候选进来。这个策略比任何固定数值都稳，尤其对付那种“不同问题类型对上下文数量需求不同”的复杂场景。

第三个改动是最朴素的——我把每个错误案例的错误原因都标成“检索问题、证据排序问题、指令理解问题、知识库冲突问题、模型推理问题”五类中的一种，每周复盘一次。这让我很快就摸清了自己项目的短板分布：原来不少人天天调的embedding模型，根本就不是错误的主要来源。这种基于真实数据分布的判断，比我之前凭感觉去优化要靠谱太多。

RAG项目调到这里，我越来越觉得“检索到了相似内容”只是一个开始，它离“答对问题”之间还隔着一整条需要精细处理的链路。这条链路里没有一招鲜的技术，只有一层一层地Debug、一遍一遍地追问“模型到底为什么选中了那句表述”，答案自然就浮出水面了。