企业官网建设流程全解析

最近被问得最多的一句话是：“我的AI怎么总是一本正经地胡说八道？明明不懂的东西，它也能编出一套完整答案。”确实，大模型的通病就是会一本正经地给你编瞎话，什么“某某产品限时优惠”“某某API支持某个参数”，说得有理有据，结果一查全是假的。这篇文章想把“RAG”这件事彻底讲透——它是什么、为什么能治这个病、怎么挂上去，以及挂完之后怎么排查问题。适合那些已经用过大模型API、但被幻觉折磨过的开发者和产品负责人，刚入门的新人也能跟着走完一遍流程。

我自己最开始做智能客服的时候，被大模型幻觉坑得够呛。用户问一个冷门问题，它居然能编出一个不存在的解决方案，还详细到了具体步骤。后来接触了RAG，才算从根上解决了大部分问题。所以这篇不仅讲原理，还有实操，踩过的坑也会都交代清楚。

1. 先搞清楚大模型为什么会“睁眼说瞎话”

1.1 语言模型的本质是“猜下一个词”，不是“查资料”

很多人用大模型的时候，下意识把它当成一个内置了海量知识的搜索引擎。这是最大的误解。大模型的核心能力，是根据上下文预测下一个最可能出现的词。

怎么理解这件事？举个生活化的例子。你写句子“今天天气真____”，正常人都会填“好”或者“不错”，因为语言习惯里这些词出现的概率最高。大模型干的事情本质上就是这个，只不过它是在一个巨大的语料库上统计出来的概率分布。

训练阶段，模型读了几千亿个句子，学到了词和词之间的统计关联。它并不知道“北京是中国的首都”这个事实意味着什么，只是在这句话出现的语料上下文里，“中国的首都”这个片段和“北京”这个词存在极强的统计关联。

正是这种“统计关联”机制，决定了模型天生就会“编”东西。只要一个问题的答案在它训练数据里出现过很多次，它就能大概率“猜对”；但如果问题很冷门，或者数据里根本没答案，它就只能根据常见词组合规律，合成一个看着很像话、实则完全虚构的答案。

1.2 幻觉产生的几个常见来源

把幻觉当成一个孤立问题，其实很难根治。因为它在不同场景下的成因完全不同。

第一种是知识缺口导致的幻觉。模型在训练时根本没见过某类内容，或相关内容太少。你问它“某新款产品支持哪些功能”，它压根没学过，但为了给你一个完整的回答结构，就开始用“常见产品功能介绍”来凑，于是编出几个功能点。这种情况在垂直领域极其常见。

第二种是时效性导致的幻觉。比如你问它“昨天主城区发生了哪件大事”，它的知识库存的是几个月前甚至几年前的语料，昨天的事它不可能知道。但它不会说“我不知道”，它只会用“最近、有消息称”这类模糊措辞，配合一个伪装的细节，制造出一种“我确实知道”的错觉。

第三种是上下文污染导致的幻觉。这是最隐蔽的一种。如果你的问题里包含了某个虚构名词或错误信息，模型往往会顺着你的话去发挥。比如你随口说一句“听说某平台上线了新功能”，模型可能就顺着“新功能”往下编出详细介绍。它不是主动骗你，是它真的很擅长顺着聊。

第四种是解码策略带来的不确定性。模型生成时有个温度参数，温度越高，模型越愿意选那些概率不太高的词来增加回答多样性。当温度过高时，回答会从“合理发挥”滑向“自由发挥”，这时候幻觉的概率就会明显上升。

1.3 基础模型+微调为什么救不了幻觉

有人说，那我花钱做微调，专门把领域数据喂给模型，是不是就能解决幻觉了？这个想法很自然，但实际上微调对幻觉的帮助非常有限。

微调做的事情，是调整模型在特定任务上的行为模式，比如让它学会客服的语气、回复格式、处理工单的固定流程。它很难让模型记住大量新增的事实性知识，因为这些知识需要在大规模预训练阶段才能融入模型参数。你想通过一两万条数据微调让模型“记住”几千条产品知识，基本是痴心妄想。

更麻烦的是微调还有一个副作用：模型在微调后虽然格式对了，但幻觉率可能反而升高。因为微调后的模型更倾向于“展示自己有能力”，碰到超出微调数据范围的问题时，它依然会强行编造，且因为语气更像标准答案，反而更容易被人信以为真。

所以结论很直接：要解决幻觉，核心思路是别让模型凭记忆瞎猜，而是给它一份可检索的实时资料库，让它在回答时“看着资料说话”。

2. 为什么说RAG是当前治“胡说八道”的良方

2.1 RAG的本质：给大模型配一个可随时查阅的资料库

RAG的全称是检索增强生成。思路特别朴素：先建一个知识库，用户提问时先去知识库里检索相关片段，再把这些片段塞进提示词里，让大模型基于这些参考材料来生成答案。

用大白话说，RAG就像给一个记性不太好的专家配了一个实时查阅的资料库。专家不用把每件事都记在脑子里，遇到问题翻资料即可。资料库里有的，他能给出准确回答；资料库里没有的，他只能承认自己不知道，而不是瞎掰。

这个过程里，模型自身的角色也发生了变化。它从“唯一的答案来源”，变成了“基于材料的组织输出者”。它的强项被集中在语言组织、逻辑串联、回答格式化上，而知识来源则完全是知识库里的检索结果。

2.2 RAG相比其他方案的核心优势

很多人会在RAG、微调、长上下文窗口这三个方案之间犹豫，我的建议是搞清楚各自适用边界。

微调适合的是风格改造和任务流程塑造，比如让模型固定输出Json格式、学会一套客服话术流程。它不是用来注入大量新知识的。

长上下文窗口是最近比较热门的方向。比如某些模型支持一次性输入几十万字，把整个知识库一股脑塞进上下文里，再让模型阅读后回答。这个方法在知识库比较小、单次查询数据量可控时是可行的，但随着资料量增大，成本会成倍上涨，而且模型对超长上下文的注意力分布会变得极其稀疏，资料放在中间位置时模型经常“读不进去”。

RAG的优势在于：知识库可以无限扩展，检索出来的核心片段成本极低，模型永远只用关注与问题最相关的那几千字材料。另外一个隐性优势是更新即时，知识库里改一条数据，下一次问答立刻生效，不需要重新训练模型、不需要等待部署。

2.3 RAG适合哪些场景、不适合哪些场景

RAG适合的场景非常明显：知识密集型问答、客服系统、企业内部文档检索、产品说明书问答、学习辅导等。这些场景的共同特征是知识内容量大、频繁更新、并且对答案的准确性要求高于文采要求。

它不适合的场景也要说清楚。比如开放式创意写作，你让AI写个科幻小说，硬要给它挂个RAG去检索“宇宙飞船的技术参数”，反而会限制发挥。再比如通用闲聊场景，日常聊天中用户并不需要一个严谨的核对过程，RAG的价值体现不出来，还会拖慢响应速度。

另外还有一种情况，就是你手头知识库质量太低。哪怕你强行挂了RAG，检索出来的是一堆漏洞百出的旧文档，那生成答案一样是错的。RAG并不能提升数据质量，它只能保证“模型说的是你给的资料里有的东西”。

3. 手把手搭一个最小可用的RAG系统

3.1 技术选型：各个组件怎么选

一个RAG系统核心包含三个环节：文档解析与切片、向量化存储、检索与生成。下面逐个说组件选型。

文档解析环节。如果知识库是纯文本或者Markdown格式，那直接读文件即可。如果是PDF、Word、HTML这类格式，就需要一个解析工具。比较常见的选择有开源的工具库，专门把PDF表格、段落结构提取成文本；也有直接用大模型做解析的方案，但成本高、速度慢，而且对长文档容易丢失细节。第一版RAG建议从纯文本或Markdown开始，走通流程后再考虑复杂格式解析。

切片策略的选型。常见做法是按固定字符数切片，比如每500个字符切成一段，段间重叠50个字符。固定切片实现简单，但有一个明显问题：它会从中间切断语义。比如一个话题完整讲完需要1000字，你500字一切，第二片就只能接半句话。多实践之后你会发现，更稳妥的是按段落、按标题、按语义边界来切，这样每个切片的语义完整度明显更高。

得到候选段落列表后再计算向量相似度。这个策略的缺点是每次检索都要算一遍句子和所有文档片段的相似度，知识库变大之后耗时线性增长。对于超大规模知识库，可以加一层粗筛，先用BM25这种关键词检索找出候选段落，再对候选段落做向量精排，速度和准确率都能兼顾。

最后一个环节是生成模型的选择。主流的大模型API都支持RAG场景，你需要用的是那种“支持自定义系统提示词”的模型，方便把检索结果和指令写进提示词。如果是在低算力设备上部署开源模型，建议选7B到14B参数量的量化版本，兼顾效果和速度。

4. 完整搭建过程实录（从零写到能跑）

4.1 准备一份高质量知识文档

我用了一个模拟场景来演示：做一个“内部设备维修问答助手”，知识库是技术手册和常见故障处理指南。

这一步最关键的是把文档整理干净。什么叫干净？首先没有明显错误和过时信息，其次同一类内容不要在多个文档里自相矛盾，最后尽量拆掉大文档、梳成一个个独立小主题。做过这个项目的都知道，知识库整理的时间占比能达到整个项目的60%以上，比写代码费劲多了。

我准备的文档经过两个步骤：

• 把零散的PDF转换成了Markdown，去掉了页眉页脚、图片水印文字。
• 把整个手册按设备型号和故障场景拆分成了十几个Markdown文件，每个文件聚焦一个主题。

4.2 文档切片的经验与方法

以其中一个文件为例，它讲的是“某型号主机开机无显示的排查流程”，内容比较长，如果按500字固定切，很容易把第一个故障原因的分析切成两半，检索时一个完整知识点被强行拆分，效果就差。

最后我选的方案是：先将Markdown按二级标题分成多个大块，再对超过800字的大块按段落边界继续切，小于300字的小块和相邻章节合并。这样出来的每个切片基本都对应一个完整的知识点。

切完片后，我给每个片段加了一个“标题前缀”。比如切片内容是“检查电源指示灯是否亮起”，我会在前面加上“某型号主机开机无显示排查流程”。这个细节在后续匹配时作用很大，经常能让语义的命中率上一个台阶。因为用户问问题时通常说的是“主机开不了机怎么办”，而不是“检查电源指示灯是否亮起”，有了上下文前缀，向量匹配才能更好捕捉语义关联。

4.3 向量化存储与索引构建

切片完成后进入向量化环节。我用的是开源向量模型的API，选择不难：小规模知识库选高维模型没大问题，但如果知识库超过几十万条，就要关注一下向量维度和检索性能的平衡。

每条文本向量化后，存进向量数据库。表结构大致就是三列：文本片段、对应的来源文档、向量数据。检索时，系统先把你输入的问题转成一个向量，然后在库里做相似度搜索，返回最接近的前K个片段。

K值怎么选？这个参数很关键。K太小，相关材料覆盖不全；K太大，塞进提示词的无关内容变多，反而干扰模型判断。我用了一个渐进测试法：从K=3开始，逐步增加到10，每档都跑一批测试问题，对比回答质量。最终在这个场景里K=5效果最好，既覆盖了多步排查流程的细节，又没有垃圾信息挤占上下文。

4.4 检索与生成的提示词组装

检索完成之后，要把结果和指令组装成完整的提示词发给大模型。这一步直接决定生成的质量。我的提示词模板大致是这样的：

你是一名设备维修助手。请阅读下面提供的技术资料片段，回答用户问题。 资料内容: {retrieved_chunks} 用户问题: {question} 回答要求： 1. 优先依据资料内容回答，不要编造资料中没有的细节。 2. 如果资料内容不足以回答用户问题，明确回复“资料中未找到相关信息”。 3. 回答时要有条理，按故障排查流程一步步说明。 4. 引用具体步骤时标注来源。

这个提示词有三个细节值得注意。第一，我明确说了“不要编造资料中没有的细节”，这句是对抗幻觉的关键指令。第二，我给了模型一个“退路”：资料不够时可以回答“找不到”，相当于是给模型授权说“不知道”，它就不会硬编了。第三，我让它按步骤输出、标注来源，生成答案的可读性和可验证性都大幅提升。

实测下来，挂上RAG之后，这个维修助手的准确率提升明显，绝大多数测试问题都能给出与手册一致的答案；少部分手册确实没覆盖的问题，也能老老实实回答“未找到相关信息”，没有硬编。

4.5 一个完整的问答流程示例

下面是用这套流程跑出来的一个真实对话示例：

用户提问：“某型号主机开机后风扇转，但显示器无信号，怎么办？”

流程内部做的事大概是：

1. 将问题向量化。
2. 在向量库中检索出最相关的5个文本片段，分别是“电源供电异常排查”、“显卡接触不良处理”、“内存条重插步骤”、“显示信号线检查指南”、“主板报警音含义”。
3. 组装提示词，连同用户问题发给大模型。
4. 模型基于这些片段生成答案，步骤清晰，且标注了信息来源是哪个片段。

最终回答如下： “根据维修手册，建议按以下顺序排查：1. 检查显示信号线是否松动，优先更换一根已知完好的信号线测试；2. 打开机箱，将内存条拔出后用橡皮擦拭金手指，再插回；3. 检查显卡是否完全插入PCI-E插槽，辅助供电接口是否接牢；4. 若以上无效，留意开机时是否有报警音，不同报警音对应不同硬件故障，详细对照表请参考手册第3章。”

整个过程说明了一个核心观点：模型没有“记忆”这些维修知识，它只是在回答的那一刻，从资料库里找到了合适的材料并组织成了像样的答案。

5. 这些坑我帮你踩过了：常见问题与排查思路

5.1 检索不到相关内容：问题十有八九出在切片或查询改写上

症状很典型：用户明明问了知识库里有的问题，但系统结果为空或者乱七八糟答非所问。碰上这种情况，先别怀疑向量模型，九成原因是查询语句和切片内容对不上。

一种情况是用户说话口语化，比如问“电脑点不亮了”，而知识库里写的是“主机无法开机”。字面差很多，语义向量应该抓到相似点。如果抓不到，那就检查向量模型的选择是否合适。不同模型对口语和书面语的语义对齐能力差别很大，这方面动手实测是最好的验证方式。

另一种情况是切片策略不合理。之前说过固定切片会切断语义，如果全库都是这种被切断的文本块，检索效果自然好不了。排查时先挑一个已知能匹配的问题，把检索返回的前十段结果打出来逐个看，你就知道到底是切片问题还是向量模型问题了。

5.2 检索到了但答案还是错：检查提示词有没有“锁死”生成边界

有一种情况最让人血压升高：检索结果明明是对的，模型还是给出了一个不同版本的说法。说明模型的默认知识太强了，把检索到的资料当成了辅助参考，而不是唯一答案来源。

解决办法就在提示词上。需要把指令从“请参考以下资料”改成“请严格依据以下资料回答，任何资料中未出现的信息都视为未知”。同时，把资料区域和问题区域用明显的标识分隔开。

还有一种用法是给每个文本片段加上来源标记，比如“[1]第2章第3节”，然后要求回答中的每个关键信息后面必须标注来源编号。这招非常管用，模型为了能标注来源，就会更老实地对照资料内容来组织语言，而不是凭自己的记忆发挥。

5.3 回答倒是准，但太碎了：做个重排环节，把杂讯滤掉

初版系统上线后，测试反馈最多的不是“错误”，而是“答案不完整”。比如问“这个设备准备做季度保养需要哪些工具”，正确流程是列出一整套工具清单。但系统只检索到其中一个片段，就只回答了那部分，漏掉了其他工具。

原因在于Top-K检索只按向量相似度取前面几个片段，可能多个片段都在讲同一个子话题，导致覆盖范围很窄。解决办法是引入一个重排序环节。第一次先取较大的候选集，比如Top-20，然后拿一个重排模型或大模型对候选集重新打分，筛出和问题真正相关的5个片段。

加了重排之后，覆盖率显著改善，检索结果也更集中了。重排的成本可控，因为只需要处理二三十条文本内容，耗时很短。

5.4 知识库更新了，答案却没变：搜索别只盯着向量

还有一次遇到的情况特别诡异：我在知识库里新增了一条新政策内容，但反复问系统，它始终回答的是旧政策。排查半天才发现，问题出在检索环节——新增的那条内容因为和其他旧文档内容高度相似，在向量检索排序时排到了后面，没进Top-K。

这件事给我的教训是：在知识问答场景中，不要只用向量检索。经典的关键词检索（比如BM25）对精确匹配非常强，新政策里几个特有名词，它能直接命中。后来我改用了混合检索，向量检索和关键词检索各返回一组结果，合并后再重排，新内容命中率立刻上来了。

5.5 常见问题速查表

6. 进阶玩法：怎么让RAG再上一个台阶

6.1 查询改写：别让用户的问题“裸奔”进检索器

第一个显著提升检索质量的技巧是查询改写。直接把用户原始问题丢进向量检索，会有几个痛点：口语化、指代不明、问题太短。你问“这个怎么弄”，模型根本不知道该搜什么。

做法是先让大模型对用户问题做一轮改写，补全指代词、扩展同义词、转化为更完整的查询表述。比如用户问“那个新的检测流程怎么操作？”，改写后可能变成“新发布的产品质量检测标准流程有哪些步骤？”。

别小看这一步，它对检索命中率的提升非常可观。代价仅仅是多一次大模型调用，但换来的是整体效果的大幅提升。

6.2 引用溯源：每个答案都能查原始出处

我给系统加了一个引用溯源的功能。具体做法是：提示词要求模型在回答中标注引用编号，比如“[1]、[2]”。而在返回结果的同时，把对应的原始文档片段拼接成一个引用列表一起返回给前端。

用户在界面上看到的不只是“答案”，还有“答案来自哪份文档的哪一段”。这样做有一个额外的好处：用户肉眼就能验证回答的可靠性，一旦发现引用内容不对，可以立刻反馈，形成修正闭环。

6.3 多轮对话的记忆与重写

如果你做的是聊天机器人，RAG同时需要处理多轮对话。用户问“那这个呢？”时，单看这五个字根本没法检索，因为它缺少上下文。

我的处理方式是：每次用户发问时，把最近几轮对话记录一起交给大模型，让模型把“当前问题+历史对话”重写成一个独立的、包含充足上下文的查询语句，然后再用这个查询去做检索。这样“那这个呢”就被改写成“前面提到的某某型号的主机，开机无法显示的故障原因有哪些”，检索时才能命中正确内容。

6.4 对检索结果重新排序，减少“强行检索”带来的干扰

前边提过一次重排，这里补充一个经验。重排尽量别用大模型逐条打分了，太慢也太贵。更实用的方案是先用一个轻量级的交叉编码器模型做粗排，再对Top结果做精排。这个方案实测性能和成本都能接受。

重排之后还有一个可选操作叫“去重”：如果几个片段来源是同一份文档的相邻章节且内容高度重叠，只保留信息量最完整的一段，避免把重复内容全部塞进上下文白占窗口。

6.5 从单次问答走向“主动追问”

最后说说一个很实用的进阶方向。很多RAG系统止步于“给材料、生成答案”，但如果知识库里的材料相互矛盾，或者检索结果指向多个不同结论时，系统可以主动向用户澄清。比如“根据您的问题，我找到了A和B两种方案，您的设备型号是哪个？我可以进一步排除”。

这等于把RAG从被动检索升级为主动引导。做起来的额外成本不高，但对用户体验的提升是质变级别的。

7. 一个关键提醒：RAG的效果上限，取决于知识库质量

不管你用什么技术方案、做什么优化，最终都会撞上同一个天花板：知识库本身的质量。RAG不会无中生有，它只会忠实地把资料库里的内容转化为答案。如果你的文档里满是错误、过时、自相矛盾的内容，RAG系统一样会把这些垃圾信息原封不动地吐给用户。

所以挂上RAG之后，工作并没有结束。知识库是活物，需要持续维护。定期清理过期内容、更新政策变化、补录新文档，这些都是RAG系统上线后的日常运维任务。建议至少建立一套“内容归属与责任”的制度，每份文档都要有明确的维护人，改了什么内容、什么时候改的、为什么改，都做记录。看起来繁琐，但只有这样才能保证系统长期可靠运行。

8. 从这套流程中我真正学到的

走完这套流程，最大的感触是：RAG不是一个“插上去就完事”的组件，它是一个需要反复调优、不断观察的系统工程。初版系统能跑通，只解决了“0到1”的问题；真正好用，还需要在切片策略、检索混合、重排、提示词这几个环节上持续打磨很久。

至于最终生成的答案是不是真的让用户满意，最直接的检验方式就是回归测试。我自己会维护一个两百条问答的评测集，覆盖常见问题、冷门问题、模糊问题、超纲问题。每次改动之后，都把这套题跑一遍，量化对比正确答案占比。这样改起来心里才有底，不会越改越乱。

如果你正准备给AI挂RAG，我的建议是：先别追求完善方案，用一个最小系统把流程跑通，然后用评测集持续迭代。技术只是手段，让用户拿到准确、可靠的答案，才是目的。希望在AI这条路上，我们都少一点“一本正经的胡说八道”，多一点实实在在的靠谱。