企业官网建设流程全解析

上周日凌晨两点，我盯着屏幕上一条 RAG 问答日志看了半天。用户问的是“员工年假天数怎么算”，系统返回的答案却在讲考勤异常扣款规则。第一反应很自然：这模型也太笨了。正准备换一个更大参数的模型，鼠标滑到引用的来源片段，才意识到检索阶段早就跑偏了，top 5 召回的结果里压根没有一条跟“年假”沾边。那一刻我确认了一件事：RAG 答非所问时，先查向量，再怪模型。这个排错顺序，能在大多数情况下帮你省掉一晚上的无效折腾。

这篇文章适合正在做 RAG 应用、知识库问答、企业内部文档检索这类项目的开发者和运维同学。如果你也被“模型乱答”“答案张冠李戴”折磨过，希望这里面的排查思路和实操手段能给你一条可复用的路径。

1. 一次“答非所问”的完整现场：先别急着骂模型

我那天遇到的项目是一个内部制度问答系统，文档库里存了上百份公司制度、公告和操作手册，整体技术链路是“文档切片 -> 向量化 -> 向量数据库召回 -> 拼接上下文 -> 大模型生成”。听起来很标准，但线上就是不断有“答非所问”的反馈。

我把出问题的 query 和检索日志拉出来看，过程大致是这样：

• 用户 query：“员工年假天数怎么算”
• 系统从向量库里取出的 top 5 片段：考勤异常处理办法、加班审批流程、薪资发放说明、请假系统操作手册、团建活动通知
• 最终生成结果：围绕考勤异常扣款规则展开，与“年假”毫无关系

这个 case 最有迷惑性的地方在于：回答本身通顺、格式完整、语气像模像样。如果不看引用来源，你会觉得是模型“理解跑偏”了。但把召回片段摆出来，问题一目了然——不是模型不会答，而是它压根没拿到正确的资料。模型只是把一个语义相近但主题无关的片段当成了救命稻草，硬生生生成了一段“看起来对”的答案。

我后来养成了一个习惯：遇到 RAG 答非所问，第一步永远是看检索日志里的召回片段，第二步看相似度分数，第三步才是 review prompt 和模型。为什么这样排？因为链路里每一环的“可观测性”不一样：检索结果能直接拉到人眼前审核，prompt 也能逐字检查，唯独大模型的生成过程是个黑盒。你把黑盒排查放在第一位，等于在没有任何证据的情况下瞎猜。

在我自己经手的几个项目里，线上“答非所问”的 case 大约七成最终定位在检索侧，包括切分问题、embedding 不匹配、缺少过滤、没有重排序；剩下三成里有相当一部分是 prompt 里没给清楚“不知道就说不知道”的约束，真正需要换模型才能解决的占比很低。所以我一直建议团队里刚接触 RAG 的同学：出问题的时候，把“骂模型”放在最后一步。

2. 为什么检索层一出错，生成层必然跟着翻车

要理解这个排查顺序，得先想清楚 RAG 的本质。所谓检索增强生成，核心思路不是让模型“记住”知识，而是让模型“临时查资料再回答”。整个链路可以简化成：

用户问题 -> 编码成向量 -> 在向量库召回相关片段 -> 把片段拼进上下文 -> 大模型基于上下文生成答案

关键点在最后一步。模型在这个环节里扮演的角色，本质上是一个“基于给定资料作答”的总结者，不是一个“什么都知道”的知识库。它不会去验证你给它看的资料是否正确，只会默认这些资料就是事实，然后从中提取信息、组织语言。这意味着，生成答案的质量上限，在你把片段喂进去的那一刻就已经决定了。

用一个不严谨但很贴切的类比：你让一个文笔很好的人去写一份行业报告，但递到他手上的参考资料全是另一个行业的数据。他写得越流畅，错得越离谱，因为他没有能力、也没有义务去核实资料本身的真伪——他的职责就是把这些资料“讲圆”。大模型在 RAG 链路里的处境就是这个人。

所以 RAG 项目里有一个我非常认同的原则：垃圾进，垃圾出。检索召回的片段里如果混着主题无关的内容，模型大概率会把其中一些细节当成事实写进答案，而且因为生成过程非常流畅，这种错误比模型“凭记忆瞎编”更有隐蔽性。用户看到的是自信满满的答案，实际上里面的关键信息可能来自一段完全不相干的文档。

那为什么很多人觉得“换个更强的模型”能改善？我也试过。结论是：更强的大模型确实能更好地从嘈杂的上下文中抓到蛛丝马迹，表现为回答看起来更“聪明”——比如不再那么机械地复述错误片段。但这是碰运气式的提升，它只是提高了模型“猜测”的准确率，并没有从根源上解决资料错误的问题。而且参数更大的模型往往生成能力更强，一旦它把错误上下文的某些细节当成事实展开，编出来的内容反而更有说服力、更难被用户察觉。

这也是我在团队里反复强调的：RAG 排错顺序应当是“检索链路 -> 上下文拼接 -> prompt -> 模型”。前两环是你能直接看到、直接验证的，性价比最高。别一上来就把宝贵的时间花在更换模型、调整 temperature 这类“玄学调参”上。

3. 向量检索环节的五个“惯犯”：从症状到根因的逐个排查

既然要先查检索，那就要有一套具体的排查清单。我把这些年踩过的坑整理成五个高频问题，每个都从症状讲起，然后给排查方法和改善手段，你可以照着顺序走一遍，基本能覆盖大多数“答非所问”的场景。

3.1 文本切分：语义被拦腰截断

症状很典型：某个文档明明就在知识库里，相关问题的答案里却总是“差点意思”，或者检索结果中反复出现同一个文档里无关的段落。

我遇到过最经典的例子：一份采购合同里写着“付款方式：合同签订后 30 日内支付 30%，货到验收合格后支付 70%”。当时用固定 500 字符切分，这句关键的付款条款正好被从中间截断，前半段和后半段分别进了相邻的两个 chunk。用户问“付款比例是多少”，向量检索命中的经常是后半段，上下文里根本没有“30日内支付30%”这个信息，模型自然答不完整。

为什么固定字符切分不可靠？因为语义边界和字符数没有必然关系。段落、标题、列表项才是天然的语义单元。你可以这样排查：从向量库里随机抽几个文档，把实际存储的 chunk 打印出来看一眼。如果发现大量 chunk 是从句子中间开始的，或者标题成了孤立的碎片，那基本就是切分策略的锅。

改善方向有三个：

• 改用标题感知切分或段落切分，以 Markdown 标题、空行、列表层级作为边界；
• 给每个 chunk 拼接父文档信息（比如“所属章节标题 + 正文”），让向量更清楚这段内容在讲什么主题；
• 如果必须用固定字符切分，设置适当的重叠（overlap），比如切 500 字符时重叠 50~100 字符，至少把拦腰截断的损失降低一些。

3.2 Embedding 模型与领域语料的错配

这个问题的症状最隐蔽：换个 query 说法，检索结果排名波动剧烈；同一个意思，用正式术语能查到，用内部叫法就查不到。

原因在于，目前常用的通用 embedding 模型是在大规模网页、论文、社区语料上训练的，对特定行业里的专有名词、缩写、企业内部的习惯叫法，语义距离把握得并不好。比如员工嘴里说的“调休”，文档里可能写的是“补休”，两个词在通用模型看来意思非常接近，但在你的业务规则里可能完全是两套政策。模型只负责把语义相近的内容聚在一起，它并不理解这两个词在你们公司制度里的差别。

排查方法很直接：拿高频问题里的核心词去查相似度排序，对比两种写法——一种保持用户的原始说法，另一种替换成文档里的标准术语——看看召回结果是否天差地别。如果替换后效果明显变好，那就是 embedding 模型没有对齐你的领域语料。

实际处理手段可以分几个量级：

• 数据量小、不想折腾：维护一份术语映射表（同义词表），在查询阶段对 user query 做改写，把“调休”映射为“补休”等规范术语，再去做向量检索。这个技巧我在多个项目里都用了，成本极低，见效快；
• 领域数据有一定规模：选择一个在中文/垂直领域表现更好的底座模型，比如 BGE 系列，在保留通用能力的同时，对领域语料的适应性通常会好一些；
• 有标注数据且有训练条件：对开源 embedding 模型做领域微调。这是效果上限最高的方案，但要处理好训练数据构建和评测集，属于“投入大、回报高”的路线。

3.3 相似度算法与阈值：分数高不代表相关

很多人看到向量库里返回的相似度分数很高，就默认“这条肯定相关”。这个习惯会埋雷，我之前就被坑过。

要明白分数高不代表语义相关，得先区分点积相似度和余弦相似度。余弦相似度计算的是两个向量方向的夹角大小，方向越一致越相关；而点积相似度等于两个向量的模长相乘再乘余弦值，也就是说，向量越长，得分天然越高。如果 embedding 模型没有做向量归一化，高频词、长文本、包含更多实体词的片段就会“占便宜”，检索结果会被这些“长而全”的片段带偏。

排查时直接把检索日志里的分数列出来看一眼：

• 相关片段和不相关片段的分数差距是否明显？如果一片混沌，说明向量本身区分度不够；
• 分数分布有没有“普遍偏高”的现象？如果所有片段都在 0.7 以上，可能点积相似度被模长污染了；
• 有没有低于阈值的片段混进了 top k？说明代码里可能根本没设相关性过滤。

改善手段很简单：

• 统一对向量做 L2 归一化，然后用余弦相似度作为打分标准；
• 设置一个最小相关性阈值，低于阈值的片段直接丢弃，宁可让模型说“资料不足”，也不要硬答；
• 不要盲目调大 top k。很多人觉得“我多给模型几个片段，它总能找对”，但 top k 从 5 调到 10，多出来的那几条大概率是低相关噪声，模型反而更容易被带偏。先保证前几条的高纯度，再谈数量。

3.4 元数据过滤缺失：新政策被旧文件淹没

这种 case 最迷惑人：答案的内容形式完全正确、语气正常，但版本或适用范围错了。比如用户问“现行年假制度是什么样的”，系统引用的却是三年前已经废止的旧制度全文——因为向量库里旧文件和现行文件都在，embedding 模型只看了语义相似度，不知道哪个版本“更该被引用”。

很多人建索引时只存了文本和向量，元数据字段（部门、版本号、生效日期、文档类型）压根没写进去；或者索引里写了元数据，查询时请求却忘了带过滤条件。于是新版旧版、不同部门的资料在检索时完全一视同仁地参与排序。

排查方法：看一下索引文档的字段结构，确认是否包含版本号、日期、部门等属性；再看查询请求有没有把这些属性作为 filter 传入向量库。如果索引里根本没存元数据，那问题在入库环节；如果存了但没用，问题在检索调用环节。

改善建议：

• 入库阶段务必保留元数据字段，尤其是“版本号”“生效日期”“文档归属部门”这类业务过滤属性；
• 查询阶段把已知的业务约束转成 filter，例如“只检索生效日期早于今天的制度”“默认排除已废弃版本”；
• 对于“取现行版本”的场景，可以在向量召回后按生效日期做一次二次排序，保证命中同主题时优先采用最新版本。

这个环节修好了，很多“张冠李戴”式的答非所问会直接消失。

3.5 缺少重排序：top k 里的“混子”污染答案

最后这个惯犯，是我见过的“回报率最高”的优化点：RAG 链路里缺少重排序（rerank）环节。

逻辑其实很简单：双塔结构的稠密向量模型，也就是平常拿来算 query 与文档相似度的 embedding 模型，追求的是“在大规模候选集里快速筛出潜在相关项”，它的速度优势明显，但精度有限。而交叉编码器这类重排序模型，把 query 和候选片段拼接在一起做深度交互，精度更高，但速度慢。所以正确姿势是把两者结合：先用向量召回 top 20~50 个候选，再用重排序模型精挑细选出前 3~5 个真正相关的片段给大模型。

没有重排序的情况下，向量召回的 top k 里经常混着一些“语义沾边但实际不相关”的片段，这些片段的分数可能排在第八、第九位，但因为 top k 直接取了前五条，它就混进来了。模型看到五条片段里有一条讲的是另一个主题，有时就会被这条带偏。

排查方法：对 bad case 做标记。如果你的知识库很小，可以直接人工看召回片段里哪一条导致模型跑偏；如果量大，可以统计“错误答案出现时上下文里是否都包含某一条低相关片段”，精准定位惯犯。

改善手段也不复杂：

• 在向量召回之后接一个轻量级 rerank 模型，对 top 20~50 候选重新打分，取分数最高的前 3~5 条作为最终上下文；
• 本地部署一个中小规模的重排序模型，在很多场景下就够用，不必一上来就追求大模型级的效果；
• 如果短期内上不了 rerank，可以退而求其次：降低 top k，并且在拼接上下文时给不同片段按相似度分数加权，让高相关片段在提示词中更有存在感。

我在一个内部项目里加了一个轻量 rerank 模型之后，首轮回答准确率从 62% 直接升到 81%，而且这个改动没有换任何大模型，只是把“喂给模型什么”这件事做严谨了。

4. 向量数据库选型与集成优化：别把时间浪费在换库上

排查完上面五个惯犯，你可能会被某些文章带到另一个方向：换向量数据库。依我看，大多数团队完全没必要走到这一步——因为回答质量的问题，十有八九不在数据库本身，而在你喂给数据库的数据和检索策略。

先给一个选型结论。我自己对向量数据库的要求其实就三条：数据能存、查询能回、运维省心。按这个标准，当前社区里常见的方案可以快速分成几类：

表格之外，我更想强调一个容易踩的坑：向量维度一致性。embedding 模型输出多少维，向量库的索引就必须匹配多少维。很多人改了 embedding 模型（比如从 768 维的通用模型换成 1024 维的新模型），没有重建索引，结果检索要么报错，要么一直返回空结果。这不是向量库的问题，是索引和模型没对齐。

再往深了说，还有几个集成细节需要处理：

• 增量更新要“先删后写”。文档改版后只写入新的向量，旧的向量还留在索引里，库会越攒越脏，检索质量慢慢劣化。我的做法是给每个文档一个稳定的 doc_id，更新时先按 doc_id 删除旧向量，再写入新向量；
• 本地向量模型值得考虑。现在个人和小团队项目完全可以在本地跑一个开源 embedding 模型（比如 BGE 系列，或者通过 Ollama 这类工具管理），效果不一定输给云端 API，关键是省去网络延迟，也不用把内部文档发到外部服务去计算向量。数据不出域这个点，对很多企业场景甚至是硬性要求；
• 监控不是可选项。至少要看三个指标：向量查询平均耗时、单次查询召回数量、空结果比例。空结果暴涨，通常意味着索引出问题了，而不是用户问题太偏。

但这里要泼一盆冷水：如果你的 RAG 答非所问，把向量数据库从 A 换成 B，大概率不会有任何改善。因为检索质量瓶颈在数据切分、embedding 模型、过滤策略和重排序这些环节，数据库只是“存储和查找”的执行者。换库解决的是性能瓶颈、运维复杂度和功能缺口，不是语义匹配精度。先把第五个惯犯那几个问题处理干净，再冷静评估自己是不是真的遇到了数据库的性能瓶颈。

5. 三十分钟建立一份“检索质量体检”流程：把排错变成日常习惯

排查方法讲完了，但真正能让你长期省心的，是把这套思路固化成一份可重复执行的“体检”流程。我自己的做法很简单，花半小时就能搭好框架，之后每次修改切分策略、换 embedding、调过滤参数，都用它回归一遍。

第一步，准备一份“黄金问答对”。挑 15 到 20 条线上最典型、最容易被用户问到的业务问题，人为标注出“预期应该命中的文档和片段”。不用多，但覆盖面要广，最好覆盖不同主题、不同文档类型。这相当于检索侧的测试集。

第二步，开启检索日志记录。在应用里把每次查询的 query、召回片段、相似度分数、最终答案保存下来。不需要额外系统，直接输出到日志文件，或者用 LangSmith、Langfuse 这类工具可视化看链路，能直接点开某次会话看到检索阶段发生了什么。

第三步，对 bad case 做分类。每次遇到答非所问，先归类到三个桶里：

• 召回不到：相关文档没进 top k，大概率是切分或 embedding 的问题；
• 召回不精：相关文档进了 top k，但排序靠后，混入了太多低相关片段，大概率需要重排序或调阈值；
• 生成偏移：召回片段已经够相关，但模型还是答偏了，这时候才动 prompt，或者考虑换更强的模型。

第四步，做一个极简的离线评估脚本。逻辑不需要很复杂，伪代码如下：

golden_set = load_golden_questions() # 每条含 query 和 expected_doc_id for query, expected in golden_set: hits = vector_db.search(query, top_k=10) hit_ids = [normalize(h.metadata["doc_id"]) for h in hits] if expected in hit_ids[:1]: recall_at_1 += 1 if expected in hit_ids[:5]: recall_at_5 += 1

算两个指标就够了：Recall@1 和 Recall@5，也就是正确答案出现在前 1 名和前 5 名的比例。改动任何检索环节后跑一遍，分数不降再上线。

第五步，维护一份术语映射表。日常积累用户问法里和文档表述不一致的词，写进一个简单的同义词配置文件，查询时先做改写再检索。人力和收益的性价比极高。

这套流程做完，你手头就有了一份“睡眠质量保障清单”。以后线上出问题，先跑一遍黄金集回归，再对照 bad case 分类定位，基本不会陷入无头绪瞎试的状态。

最后再分享一个小技巧：给 RAG 应用加一个“查看引用来源”的功能。用户能直接点开答案引用的原始片段，不需要你亲自动手，他们就能帮你发现“检索错了”。我见过太多团队把引用来源藏得很深，导致用户和开发者都以为答案是大模型编的，实际上元凶一直是检索侧。把来源亮出来，答非所问的定位成本会降到最低。按我个人的习惯，现在每周跑一遍黄金集，每月翻一遍日志里的 bad case，已经很少再被“模型太笨”这种表象带偏了。