企业官网建设流程全解析

你有没有遇到过这种情况：问大模型一个问题，它回给你一段逻辑严谨、语气笃定、专业名词满天飞的答案，但只要拿关键细节去核实，就发现人名是编的、数字是瞎凑的、引用来源也是对不上的。这就是大模型幻觉（Hallucination），圈内人管它叫“一本正经地胡说八道”。想根治这个问题，过去两年被验证最有效、落地最快的方案，就是RAG（Retrieval-Augmented Generation，检索增强生成）。这篇文章不打算讲概念车轱辘话，而是从原理、流程、参数到日常踩坑，给想摆脱幻觉的开发者一份能直接照着调的实操手册。

1. 先搞清楚前提：大模型为什么会一本正经地胡说八道

1.1 本质原因：模型骨子里是个“概率猜词机器”

很多人第一次接触大模型，容易把它当成“会说话的知识库”。实际上，主流大模型的底层逻辑更像一个高级版“猜词游戏”：给定前文，逐字预测下一个最可能出现的token（词元）。它并不知道自己“知道什么”或“不知道什么”，只是在概率分布里采样出一串听起来合理的内容。

训练过程决定了它有两个先天缺陷：第一，训练数据有截止时间，拿不到当时之后的新信息；第二，模型用参数压缩训练语料，本质上是“记了一个大概”，细节会被模糊化、合并甚至扭曲。调用模型时，如果你问了一个它没“记牢”的问题，它不会老实说“我不会”，而是会沿着语言惯性，硬生生补出一段结构完整、语气自信的答案。

这种补全在语义上往往非常流畅，所以特别有欺骗性。说句不好听的，模型最擅长的事情就是“用你没听过的内容、一本正经地骗你”。不信的话，你随便问某一个封闭式模型：“帮我回忆我上个月在某平台下单的订单号是多少”，它大概率会编一个格式工整、但完全不存在的单号。这就是“猜词”机制在起作用，跟“它太笨”是两回事。

1.2 幻觉的类型远比想象中隐蔽

光说“胡说八道”太笼统，实际落地时，幻觉大概分成四类：

• 事实捏造：模型生成的人名、机构、日期、数值纯属虚构，比如“某某论文在2023年证明了什么”，但根本没有这篇论文。
• 信息过时：答案本身曾经正确，但训练数据过期，比如“目前某平台支持单笔转账限额50万”，实际上规则早就改成了20万。
• 推理错误：模型把几个知识点捏在一起，逻辑链条断裂。比如“A包含B，B包含C，所以A包含C”，但在具体场景里并不成立。
• 来源错配：模型确实引用了一段上下文，但它把张三的观点安到李四头上，或者把某个时间点的政策说成了当前政策。

这四类幻觉的危害差异很大。个人用大模型写代码、写文案，幻觉顶多是多改几遍；但在企业场景里，幻觉可能直接导致客户投诉、错误决策甚至合规风险。例如客服机器人告诉用户“可以人工全额退款”，实际上没有这个政策；投研助手引用了一个不存在的监管文件，可能导致用户做错误判断。这也是为什么越来越多团队宁可牺牲一点“话多”，也要强制模型“先查再答”——这正是RAG要解决的核心问题。

2. RAG的思路：让模型学会“先翻书，再回答”

2.1 RAG和微调的区别：闭卷考试与开卷考试

要理解RAG，最好用一场考试来类比。微调（Fine-tuning）相当于给模型继续“补课”，把新知识强行灌进它的参数里，本质上还是闭卷考试。你问它，它从“大脑”里找答案，找不到就只能编。RAG则相当于给模型一张允许带进考场的资料夹，考试时先翻资料，再根据资料写答案。

具体来说，RAG的完整链路是：用户提问后，先把问题拿去检索一个外部知识库（可能是文档、数据库、网页），找出与问题最相关的若干片段，再把“问题 + 检索到的片段”一起交给大模型，让模型基于这些片段生成回答。这样一来，模型不用靠记忆硬扛事实细节，只需要做好一件事：理解检索到的上下文，然后把答案组织出来。

很多团队一上来就想用微调解决幻觉，这是个经典误区。微调更适合改变模型的表达风格、输出格式或固定能力，比如让模型学会用SQL回答表格问题；但如果纯粹是“业务知识不够新、不够全”，微调的成本很高，而且效果不一定稳。你可以想象，让一个学生背一本1000页的手册，他背完也可能把第300页和第600页的知识点搞混；但你让他考试时翻手册，只要手册够清楚，他就能给准确答案。

2.2 RAG不是“检索一次就完事”，现在已经有三种常见形态

这几年RAG被玩出了很多花样，但核心逃不开三种姿势：

第一种是朴素RAG（Naive RAG）。用户query进来，直接经过向量检索，从知识库召回top_k片段，拼进Prompt里交给模型。优点是简单易懂，适合刚起步或问题比较单一的场景；缺点也很明显：用户问法稍微口语化一点，或者知识分散在多段文档里，召回效果就崩。

第二种是查询改写/多路召回RAG。它会在检索之前加一个“问题加工”环节：用大模型把“今天天气怎么样？我想知道要不要带伞”改写成“今日某地天气、降水概率、风力大小”，或者同时做向量检索和关键词检索，最后用排序算法融合。这个阶段可以用HyDE（让模型先生成一个假设答案，再用假设答案去检索），也可以用子问题分解，把“A公司去年的营收和员工人数是多少”拆成“A公司去年营收”和“A公司去年员工人数”两个检索任务。

第三种是模块化/Agent式RAG。这种RAG把检索、重排、生成都变成可被大模型动态调用的模块。大模型先判断“这个问题需要检索吗？检索哪几个来源？”，再执行检索、读答案，如果发现不够就再检索一次。它对复杂问题的控场能力强，但对链路稳定性要求也高，因为不能每次都让模型乱试。

我在实际调试中最大的感受是：不要指望一个朴素RAG解决所有问题。绝大多数情况下，你要先跑通朴素RAG，再根据失败样本决定要不要加“查询改写”“混合检索”或“多轮检索”这些增强模块。

3. 从零搭一个可落地的RAG：流程、参数和操作细节

3.1 知识库准备与切块策略：切不好，后面全白搭

RAG的检索对象不是整本书，而是“块”。在向量检索阶段，系统会把文档切成若干小片段，分别转成向量存进数据库。切块策略直接决定召回质量。切太大，一个片段里塞了多个主题，向量被平均化，检索出来不痛不痒；切太小，片段缺少上下文，模型拿到手也不一定能看懂。

我建议从这几个维度去控制切块：

• 切块大小（chunk_size）：中文场景，经验值在256~512个token之间。如果文档结构非常清晰（比如每段讲一个点），可以放宽到600~800；如果文档是连续的描述型文本，256更安全。
• 重叠窗口（overlap）：相邻两个块之间建议保留20~50个token的重叠，防止切块时把一句完整的话从中间截断。比如原文本是一个句子的后半段被切进了下一块，模型读起来就会很割裂。
• 切块方式：不要只用固定字符数切，优先按段落、标题、列表结构切。有一种做法是“递归切分”：先按段落切，段落太长再按句子切，句子还太长再按固定长度切。

举个例子。假设你有这样一段文档：“2023年公司推出A计划。该计划覆盖三个城市，分别是S市、T市、G市。S市已于5月启动试点，T市预计6月……”如果用512个token固定切，很可能把“该计划覆盖三个城市”和后面的具体列表切到两个块里，导致用户问“三个城市是哪些”时，只召回了一半。改用按语义段落切分，先把“计划是什么”保留在一个完整块里，问题就解决了。

数据清洗同样不容忽视。知识库如果是从PDF抽来的，会有大量页眉页脚、目录、水印和乱序文本。这些噪声一旦进入向量库，检索时经常会“灵魂出窍”——明明用户问退货政策，召回结果里全是“版权所有”“目录”这些垃圾片段。所以建库前，必须做一遍简单的去噪声：去掉页眉页脚、统一编码、识别表格结构。顺便提醒一句，PDF抽取表格如果抽成一个矩形块，向量化效果非常差，建议对表格转成Markdown或HTML结构再入库。

3.2 Embedding选型：别只看公开榜单，领域语料才是试金石

切好块之后，每个块需要被转成向量。Embedding模型的作用，就是把“文本语义”映射到一个高维空间里，让语义相近的句子距离更近。选Embedding模型时，我建议关注四个点：

• 是否支持中文：很多英文模型在中上表现尚可，但处理中文口语、专有名词、长难句时会有一言难尽的表现。优先选中文语料充分训练的模型。
• 输入序列上限：有的模型最多只能编码512个token，你的默认chunk_size设到600，就会被迫截断。务必先确认上限，再定切块大小。
• 向量维度：常见的有768、1024、1536等。高维度上限更强，但存储和计算开销更大。如果知识库在百万级以下，768~1024通常够用；别为了“感觉更细腻”盲目上大维度。
• 领域适配性：通用领域的Embedding模型对法律、医疗、代码这类强专业词汇理解有限。建议用你的领域样本，跑一个小规模“召回命中率对比”，用数据说话，而不是只看公开榜单。

向量检索的距离度量，一般用余弦相似度（Cosine Similarity）。它专注于夹角的差异，对向量长度不敏感，适合文本语义匹配。代码实现上，就是把query向量和库里所有向量算一遍余弦相似度，取最高的top_k个。这步听起来简单，但知识库一上百万条，暴力计算就扛不住了，所以实际会用向量数据库或支持ANN索引的组件来做近似最近邻检索，速度能快几个数量级。

3.3 检索与重排：召回百条，不如精准三条

很多初学者直接把召回的top_5拼接进Prompt，效果却很差。核心问题是：向量检索的“相关”，不等于生成答案的“有用”。用户问“有哪些退货条件”，召回结果里可能有5段都提到“退货”两个字，但真正写清楚条件集合的只有其中1段。把5段全塞给模型，模型反而容易被带偏。

正确的做法是：召回和精排分离。召回阶段，预留足够候选，比如每轮检索召回top_20~top_50；然后交给一个重排（Rerank）模型，对所有候选再做一次精细打分，最终只取3~5个最相关的片段进入上下文。重排模型比向量模型更“聪明”，它通常是一个交叉编码器，会把query和每一个候选文档拼起来，逐字判断相关性，所以精度高，但速度慢，不适合对所有库直接跑，只适合对第一轮召回的少量候选跑。

如果暂时不想引入重排模型，有一个低成本补救方案：混合检索。向量检索擅长“语义相关”，BM25这类关键词检索擅长“词面完全命中”。两者结果用RRF（Reciprocal Rank Fusion）之类的简单算法融合，能明显改善专有名词和代码类查询的召回。我对纯代码场景做过对比：单独用向量检索，很多包含特定变量名的上下文召回不到；加入关键词召回后，命中率一下子提高了不少。

3.4 生成侧调教：让“不确定就不答”变成系统级约束

检索做得再好，生成侧不约束，模型照样会发挥想象力。系统Prompt里至少要写清楚三条规则：

1. 只允许使用给定上下文中的信息作答，不使用模型自身记忆补全。
2. 如果上下文中没有答案，必须明确回复“根据现有文档无法回答”，不要编造。
3. 回答中需要标注信息来源，例如“根据《XX操作手册》第二章”。

接着，把上下文在Prompt里组织成清晰的字段，建议给每一段加一个编号和来源标签。比如：

以下是检索到的资料片段： [1] 来源：退货政策.md，第3章第2节 [2] 来源：售后常见问题.docx 你的任务：只根据以上片段回答问题。

这样模型在生成时，更有可能在答案里写“根据退货政策，消费者可以在签收后7天内申请退款”，而不是从自己脑子里捞一个别的数字。我试过在几百个真实问答样本上做对比，加了来源标签之后，答案可溯源率明显上升，用户也更愿意信任模型输出。

另外，把temperature调低一点，通常建议0.1~0.3。温度太高，模型倾向于自由发挥，即使上下文里有正确答案也可能换一种“说得漂亮”的方式组织；温度低，模型更愿意紧密跟随上下文，虽然会显得呆板，但幻觉率会下降。你要的如果是一个可靠的知识库问答助手，宁可呆，不要飘。

4. 实操中最容易踩的坑：从上一节到下一节都是排雷现场

4.1 检索命中率低：问题往往出在“用户问法”上

做客服问答时，我见过最典型的一类翻车：用户问“这个怎么退啊？我昨天才买的”，向量模型直接把它编码成“如何退货”的语义向量，结果在文档库里匹配到的全是“退换货流程”之类的大标题段落，没有匹配到“7天无理由退货条件”这一核心条款。检索命中率一低，模型当然只能瞎编。

解决思路是“先改问题，再检索”。用一个轻量大模型或规则模块，把口语化query改写成标准检索query。例如“这个怎么退啊？我昨天才买的”可以改写为“如何进行退货操作 昨日购买 退货条件”。这种改写不需要模型很强大，但效果提升非常明显。另一个思路是HyDE：让大模型先基于当前问题生成一个“假设答案”，拿这个答案去检索，因为假设答案中的表述往往比用户原话更接近文档语言，相似度匹配会准确很多。

还有一类更隐蔽的问题：query太复杂。比如“帮我对比A和B两个城市的补贴政策，并告诉我在S市补贴是否包含租房补贴”，这个query揉合了“对比”“筛选”“判断”多个意图，直接整体检索大概率一个都抓不准。这种问题建议拆解成多个子查询，分别检索后再合并上下文，这也属于“查询改写”的进阶用法。

4.2 召回了一堆“相关但没用”的片段：噪音上下文比没有上下文更危险

很多人以为召回数量越多越好，于是把top_k设成10甚至20，结果上下文里混杂了大量“看似相关、实则是泛泛而谈”的内容。比如用户问“逾期还款的违约金比例是多少”，召回结果里可能包含“逾期还款会影响征信”这种句子。虽然相关，但没有回答用户要的数字。模型面对这种前后矛盾的信息，可能做出混乱的回答。

处理这类问题，有两道闸门。第一道是相关度阈值：在向量检索或重排打分之后，设置最低相关分，低于阈值的片段直接丢掉，哪怕候选数不到预期的top_k。第二道是重排排序：按相关性从高到低排好后，只截断前3~5个片段；宁可上下文短，也不要硬塞一堆噪声。实际测试中，某些场景把top_k从10降到3，答案准确率反而上升——因为上下文噪音少了，模型更容易聚焦。

如果阈值和重排都做了，仍然经常召回无用片段，就要回查Embedding模型的领域适应性问题。这时可以用一批领域样本做一次“query-正样本-负样本”微调，让模型学会区分“触发退货话题的相关片段”和“真正说明退货规则的片段”。这也是我之前提到的，通用Embedding模型在专业场景里经常不够用。

4.3 上下文太长导致“中间迷失”，离真相越近反而越容易答错

即使检索质量很高，长上下文本身也会带来新幻觉。Transformer的注意力机制有“Lost in the Middle”现象：模型对上下文开头和结尾的内容感知较强，对中间部分容易忽略。如果你把5段、每段800字的上下文一次性塞进Prompt，模型很可能只盯着第一段和最后一段，漏掉最核心的中间段落。

控制策略有三个。第一，压缩上下文块大小，不要让单块超过500个token，必要时对长块做抽取摘要后再入库。第二，调整块顺序，优先把重排分最高的段落放在Prompt靠前或靠后的位置。具体放哪儿要实测，根据你用的模型，不同位置的效果可能不一样。第三，限制最终进入Prompt的片段数量，不要贪多。我的经验是，对于文档问答场景，最终上下文总长控制在1500~2500个token之间是比较平衡的区间；超过3000后，答案准确率的下降经常能肉眼可见。

4.4 上线前不做好评估，调参全靠玄学

RAG链路里能动的配置实在太多：切块大小、重叠窗口、Embedding模型、检索方式、重排模型、top_k、阈值、Prompt、temperature。如果不建立一套评估体系，你根本不知道改动一个参数是变好还是变差。

最推荐的做法是建立“回归评测集”：准备50~100个具有代表性的问题，每个问题标注正确答案、最少需要的上下文片段ID、预期来源。每次改配置，就在这套评测集上跑一遍，记录三个核心指标：

• 召回命中率：正确答案对应的片段是否出现在最终上下文里。
• 生成准确率：模型生成答案是否与参考答案一致或逻辑等价。
• 幻觉率：模型答案中是否出现与上下文矛盾、或上下文未提及的内容。

人工逐条评估太慢，可以先用大模型自动打分。具体做法是：把“用户问题、模型答案、上下文片段”一起交给另一个大模型，让它判断“答案是否严格基于上下文、是否存在推理跳跃”。但要注意，“大模型法官”自身也有偏好，所以自动评估只能筛出明显问题，上线前仍然需要人工抽检一批。没有评估体系的RAG优化，基本等于蒙眼开车。

5. 什么时候RAG不够用：边界、进阶与更稳的出路

5.1 别迷信RAG，有些场景它天生别扭

RAG适合“知识库里的内容回答知识库里的问题”，但如果你遇到三类场景，就要谨慎评估。

第一，模型需要在固定模板下生成内容，比如每周自动生成一份固定格式的销售周报。RAG负责检索本周数据，但“周报格式”这件事用微调或Few-shot更有效。你说什么格式、用什么措辞，RAG可能会钻到上下文里找不存在的格式要求。

第二，答案需要精确计算、跨多行表格聚合。比如“上个季度华南区所有门店的员工总数是多少”，如果这些数据分散在很多张表格里，RAG把整张表塞进上下文也容易出错。这种场景更适合用SQL查询、API调用等结构化工具。

第三，知识高度重叠、关系复杂。普通RAG把每段文档独立向量化，检索时容易“只见树木不见森林”。比如问“哪些政策文件影响S市的补贴申请条件”，答案可能横跨三个政策文件，单靠向量检索很难同时召回所有关联信息。在这种情况下，你需要考虑进阶方案。

5.2 进阶方向：Agent式RAG和GraphRAG帮你补短板

进阶方向不外乎两条路。一条是Agent式RAG：让大模型当调度员，拆解问题、多次检索、自我反思。比如处理“对比A和B两个城市的补贴政策”这种问题，Agent可以先把问题拆成“A城市政策”“B城市政策”“两者差异”，分三次检索再汇总，而不是一次性用整个query去撞运气。这种方案灵活，但链路更长，需要做好超时、失败重试和风险控制。

另一条是GraphRAG。它在建库阶段不只有向量索引，还会从文档中抽取实体（如“S市”“补贴方案”“申请条件”）和关系（“属于”“要求”“调整”），构建一张知识图谱。检索时不仅能找到语义相关的片段，还能沿着关系路径找到隐藏关联。对于“哪些政策影响X”这类多跳问题，GraphRAG的召回效果明显比纯向量RAG好。

不过，这两条路的开发成本都不低。如果你的知识库规模不大、问题以单点事实问答为主，老老实实把朴素RAG的切块、检索、重排、评估打磨好，效果收益反而是最高的。很多团队连朴素RAG都还没跑稳，就上全套Agent编排，最后只收获了排错地狱。工具不是越复杂越好，能稳定解决业务问题的链路，才是好链路。

最后再分享一个我反复跟人强调的体会：RAG要做到“不胡说”，关键并不在某一个环节多厉害，而在整条链路是否闭环。检索不准，模型没东西可用；上下文太杂，模型又会学坏；不设来源，模型会自由发挥；不评估，你不知道下次改动是变好还是变坏。哪怕只用最简单的向量检索加一个高质量Prompt，只要每次改动都有评测数据兜底，效果也会比盲目堆一堆高级模块强得多。如果你正被大模型幻觉折磨，我建议从今天开始，用最小的知识库跑通一遍“切块-向量化-检索-生成-评估”，再把top_k和上下文长度当成第一批调参对象。这条路不性感，但真的能落地。