企业官网建设流程全解析

最近我连续在好几个项目群里看到同一种吐槽：检索结果里明明已经有相关内容了，可大模型给出的答案还是错的。RAG 做到这个阶段，基本等于临门一脚踢飞，特别泄气。这篇文章就专门聊这个问题，把“检索对了但答案错了”的链路拆开，从检索、分块、上下文组织、模型推理到知识结构设计一层层过，顺便聊聊我实际搭建和排障时踩过的坑，希望能帮正在调 RAG 的人少走弯路。

这个标题背后其实藏着好几类完全不同的故障，我梳理之后分成五个层面：检索质量、上下文组织、模型能力、知识库结构、以及评测方法。每一层都可能导致答案错误，但修法完全不同。这次全写出来，不说空话，直接给排查思路和可复现的调整方案。

1. 先别急着怪模型：RAG 答案错误的五个故障层

1.1 把 RAG 拆成“找人”和“读题”两个动作

很多人把 RAG 当成一个整体，答案错了就一句“模型垃圾”甩锅。但 RAG 的本质是两件事：先检索，再生成。用生活化一点的类比，就是你问一个助理：“帮我查一下这台设备的保修期。”助理先去档案室翻资料，翻到几页相关文档，然后回到你面前总结答案。这时候答案错了，可能是助理压根没翻到对的档案，也可能是翻到了但文件里那句话被别的内容盖住了，也可能是助理自己理解跑偏，甚至是他根本没看档案，凭印象编了个答案。

这四个环节任何一个出问题，最终都是“答案错了”。所以排障的第一原则是：不要先调模型，先确认检索回来的内容里到底有没有正确答案。我见过太多人花两个星期调提示词，最后发现 TopK 返回的十个片段里根本就没有能回答问题的内容。

1.2 答案错误不等于单一故障

把故障分层之后，RAG 的“错”大致能分成五类，每一类的特征和处理思路完全不同，可以对照着快速定位：

我实际操作中见最多的不是第一种，而是第二和第三种。也就是说，检索结果看起来相关，但要么关键信息被切碎、被稀释，要么模型没有从长上下文中把关键句抽出来。后面几节我会分别展开说，这里先记住一个结论：答案错了，先给故障分层，再对号入座。

2. 检索侧深挖：相似不等于能用，TopK 和分块是重灾区

2.1 向量相似度只负责“语义像”，不负责“能回答问题”

这是 RAG 入门最容易踩的坑。向量检索计算的是“语义相似度”，它保证的是两句话在语义空间里距离近，而不是“这句话能回答这个问题”。举个我调试时的真实例子：知识库里有一篇文档讲“退货流程”，里面详细写了七天无理由退货的时间线；另有一篇文档讲“退款到账时间”。你问“退货之后多久能收到退款”，向量检索可能把两篇都召回了，但排序靠前的可能是“退货流程”那篇，因为它和问题里有大量重合词。真正的答案其实在“退款到账时间”那篇里。结果模型看到了第一篇文章，就根据里面的“七天”顺口答了个时间，完全没用第二篇。

这就是“检索到了相似内容，答案还是错的”最典型的形态。核心原因在于相似度并不等价于“信息增益”。解决思路有几个：一是引入混合检索，把 BM25 这类稀疏检索和向量检索结果做融合，关键词精确匹配不会被语义相似挤掉；二是做查询改写，把“退货之后多久收到退款”改写成更明确的“退款到账时限”，让检索目标更聚焦；三是加一个重排模型（Cross-Encoder），对召回结果按“是否包含答案线索”重新排序，而不是按语义相似度排序。

2.2 分块策略决定了答案是否完整

分块是另一个大坑。块太小，一句话被拦腰截断，答案信息不完整；块太大，噪声增多，正确答案被淹没。我之前处理一份产品手册时，用固定 500 字符分块，结果“保修期 12 个月，但人为损坏不在保修范围内”这句话恰好被切成了两半，模型只看到前半句就回答“12 个月”，完全丢失了例外条款。这不是模型的问题，是分块把答案拆碎了。

更隐蔽的问题是跨块上下文缺失。比如文档先用一段介绍“本产品支持蓝牙 5.3”，后面另一段说“该功能需配合手机 App 使用”，这两段被分到不同块之后，模型面对提问“蓝牙连接需要怎么设置”时，每个块都给不出完整上下文，于是开始脑补。对策是使用带重叠的分块，或者在切分时按 Markdown 标题、PDF 章节结构做语义切分，而不是无脑按字符数切。再激进一点，可以在分块时做“父子块”结构：小块用于精确召回，找到后把父块整块塞进上下文，避免信息被切散。

2.3 TopK 是个需要反复试的参数

TopK 太少，真答案可能没进候选；TopK 太多，无关片段一起进上下文，把模型注意力带偏。我见过有人把 TopK 设成 20，结果 20 个片段里有 15 个都是相似但不相关的段落，模型被大量冗余信息包围，反而把真正答案挤到上下文中间位置，出现“lost in the middle”现象。这里涉及一个在大模型里很普遍的特性：模型对长上下文中间位置的内容关注度低于开头和结尾。你把关键证据放在第 8 个片段里，模型很可能就是没读到。

所以我在实际项目里一般先把 TopK 压到 5 左右，配合重排器从召回候选中再挑出最精准的 3 到 5 个片段。宁可少给，不要多塞。少给顶多漏答（漏答容易发现，也能引导用户换种方式问），多塞会导致模型自信地瞎说，更难排查。

3. 生成侧深挖：上下文组织、提示词和模型边界

3.1 上下文塞得越多，模型越容易“看漏”

检索侧搞定之后，问题会转移到“读题”环节。我做过一个对比实验：同样的检索结果，用不同的方式组织提示词，准确率能差出 20 个百分点。最影响效果的是“证据排布”。把最可能包含答案的片段放在上下文的最开头和最末尾，比放在中间更容易被模型采信。这不是玄学，是模型注意力分布的实际特性。

做法很简单：在把检索片段拼进提示词之前，先用一个打分逻辑对片段排序，把高置信度证据放开头或结尾。比如用重排器的分数、关键词命中数、文档新鲜度综合排序。我甚至会在 prompt 里给每个片段编号，并明确要求模型“回答时必须从编号片段中摘取证据，引用格式如 [1]”。这能显著降低凭空编造的概率。

3.2 “无法从上下文回答”是必须写进提示词的兜底话

一个让我印象很深的 case：知识库里有一份旧版产品的说明书，新版产品已经停产换代了。用户问“旧版还能用吗”，检索回来的说明书通篇讲的是使用方法，没有任何地方说“能用或不能用”。模型面对这种情况，硬生生编出一句“该产品仍可正常使用，但建议联系供应商确认”。这句很像“正确的废话”，但其实是幻觉。为什么模型会编？因为默认情况下它倾向于给出一个看起来完整的答案，而不愿意承认自己不知道。

修复成本极低，但很多人不做：在系统提示词里明确写“如果你无法从提供的上下文中得到明确答案，请直接回答‘无法确定’，不要猜测”。就是这么一句话，能把幻觉率压下去一大截。更严格的做法是让模型先输出判断结果，比如先输出“SUPPORTED”或“UNSUPPORTED”，再决定要不要生成答案，类似分类器前置的思路。

3.3 小模型在这里真的吃亏，换模型比调提示词更有效

开源小模型（7B 到 14B 这个范围）在处理“上下文里有答案但需要推理”的场景时，能力天花板明显低于大模型。比如你问“哪些产品保修期超过一年”，即使上下文里把三个产品的保修时间都列全了，小模型的表格理解或多实体对比能力就是跟不上，会漏掉一个。

我做过同批检索结果在不同模型上的对比：同一份法律咨询文档，qwen2.5-7b 在归纳多条款时答漏了例外条款，而用 qwen2.5-32b 或 GPT-4o 就能基本答全。这说明有些“答案错误”本质上不是 RAG 架构问题，而是生成模型能力问题。在工程上，如果你的场景是多跳、对比、条款例外这些高难度任务，要么换更大的模型，要么把任务拆小：先检索出候选实体，再针对每个实体单独询问，最后汇总。不要让模型一次性做“检索+推理+判断”三件事。

4. 结构知识库与 Ontology RAG：向量检索解决不了的那类“错”

4.1 向量知识库和结构知识库到底怎么选

说到 RAG 的瓶颈，纯靠向量库确实有绕不过去的坎：它擅长模糊语义匹配，但处理不了强约束、多跳推理和一致性问题。这时候就该考虑“结构知识库”了。要区分这两个概念：向量知识库存的是非结构化文本的向量表示，适合开放问答、语义搜索；结构知识库存的是实体、属性、关系的结构化数据，可能是关系型数据库、知识图谱、本体加三元组，适合精确查询、规则约束和多跳关系推理。

我用一个例子说明：一个客服机器人被问“这个产品在保修期内，但我是在第三方平台买的，还能找官方售后吗”，纯向量检索会召回一堆关于保修期的描述和第三方平台合作条款，模型看完之后仍然需要自己判断“第三方平台购买是否影响官方售后”。但如果知识图谱里已经有一条规则：经销商购买的设备具有同等售后权利，那直接查图谱就能拿到权威答案，根本不需要让模型去猜。这类问题的特点就是：答案不是一个“相似段落”，而是一条明确的关系或规则。

4.2 Ontology RAG 的价值是“约束”而不是“召回”

最近很多人聊 ontology RAG，说简单点：本体（Ontology）就是给知识库先定义一套概念的边界和关系。比如“产品”有“制造商”属性，“保修单”关联到“产品”，“责任方”则是“售后主体”。这相当于给 RAG 装了一副眼镜，让它知道“保修”这件事由哪些概念和关系构成，而不是把所有文本一锅端。

实际落地上，我在一个设备售后问答项目里用过“混合路线”：先用向量召回候选文档，同时用一个轻量级本体图把问题里的实体和关系解析出来，通过图查询直接拿到一条结构化证据，再跟向量召回的文本一起塞进生成模型的上下文。效果很明显：“谁负责维修”这种问题，纯文本召回时模型经常答成“品牌方”，而图查询直接返回了“授权服务商”，答案从模糊变精确。这类增强不是用来替代向量检索，而是用来给生成模型提供“不容置疑的结构化事实”。

5. 实操笔记：在 Mac 上搭一套 RAG，踩过的坑与排查清单

5.1 Mac 本地搭建的最小可行方案

热搜里有人问“怎么在 mac 上搭建 rag 知识库”，我也在 Mac 上跑过完整的本地 RAG 流程，分享一个适合 Apple Silicon 的搭配。核心诉求是省钱和私密性好，不需要 GPU 集群，用内存换速度。我的选择是：Ollama 跑生成模型，Embedding 用 BGE-M3（它有 ONNX 版本，在 Mac 上跑没问题），向量库用 Chroma，编排直接手写 Python 脚本，没有用 LangChain，目的是把每一环节的输入输出都看得到。

装完之后，内存占用大概是：7B Q4 量化模型约 4.5GB，BGE-M3 约 600MB，加 Chroma 的索引服务几百 MB。如果你的是 16GB 内存的 M1/M2，跑起来不富裕但够用。如果不是很在意本地运行，更推荐把 embedding 和 rerank 放在云端 API 上，本地只负责流程编排，这样响应速度会快很多，也不影响学习和调试。关键经验：在 Mac 上不要尝试加载 13B 以上量的模型跑长上下文，第一次你就会感受到什么叫风扇起飞。

5.2 一套实测可用的排查流程

迭代了很多次之后，我总结出一套几乎不会走弯路的排查顺序，每次答案错了，就按这个顺序过一遍：

1. 打印检索到的 TopK 片段，人工判断“这些片段里有没有正确答案”。
2. 如果没有，问题在检索侧，按混合检索、查询改写、TopK 调整的顺序处理。
3. 如果有，但模型答错了，把所有片段按证据可能性重排，把强证据放最前最后，并加上强制引用。
4. 还不行，就把上下文里的关键段落单独截出来，用一条简单的提示词问同一个模型。
5. 简单任务答对、完整 RAG 答错，问题多半在上下文组织或干扰信息；简单任务也答错，直接换模型或升级量化精度。

这份流程能覆盖八成以上的“检索正确但答案错误”问题。你不需要上来就调 embedding 模型，也不用重训任何东西，大多数问题通过分块、排序和提示词结构就能解决。

5.3 用真实案例做回归，别靠“感觉变好了”

最后强烈建议建一个“黄金测试集”。找 30 到 50 条真实用户问题，把正确答案和对应文档记录下来，每次调整分块参数、TopK、重排器、提示词之后都跑一遍。不这样做，你很可能陷入“昨天改完觉得不错，今天换个问题又崩”的循环。

我在一个知识问答项目里就是这么做的，后来才发现某个提示词调整让准确率提升了 8%，代价是“无法回答”率暴增。如果你不做回归测试，根本发现不了这个代价。RAG 调优不是单点优化，它是一个系统性工程，每一步都要有验证闭环。

6. 经验收尾：别追求完美检索，先让错误可解释

写了这么多，我自己最深的体会是：RAG 这个架构最大的优势其实不是“答案一定对”，而是“错的时候能找出原因”。传统问答系统答错了，你只能分析日志硬猜；RAG 答错了，你可以把检索结果、重排分数、提示词内容全部摊开来看，找到问题出在哪一环。所以与其追求一个完美的检索器，不如把链路做成透明的，让每一次错误都能被定位。

实际操作中我越来越倾向于在检索之后加一层“答案片段验证”逻辑：用一个轻量级分类器或小模型判断候选片段是否真的包含答案线索，过滤掉那些“相似但无用”的内容。这比单纯堆检索参数更可靠，也能大幅降低生成模型的幻觉率。如果你也被“检索对了答案却错”折磨，照这个思路做一次链路拆解，大概率能找到你那一环真正的病灶。