企业官网建设流程全解析

前阵子有个朋友跟我说，他拿大模型做企业知识库问答，结果模型一本正经地编了个根本不存在的政策条款，还配上了一个相似的文件名。这事特别典型，大模型“一本正经胡说八道”早就不是新闻了，但真落到自己的业务场景里，还是挺头疼的。后来我给他搭了一套RAG，让模型先“查书”再回答，效果一下子实在了很多。今天就把这套思路完整拆开讲讲：RAG到底怎么运作，为什么能把幻觉压下来，以及真正落地时那些文档、分块、检索、提示词上的坑。

1. 大模型为什么会“不懂装懂”：幻觉的来源得先说清楚

想理解RAG为什么能降幻觉，得先搞清楚幻觉是怎么来的。这事本质上不是模型“坏”，而是大模型的生成机制决定的。

1.1 语言的游戏

大模型本质上是“下一个词预测器”。你给它一段文字，它根据训练中学到的统计规律，去猜下一个最可能的词是什么，然后一个词一个词地蹦出来。问题在于，它的参数里存的是海量的文本模式，但没有任何一个机制保证这些模式是对的、是事实。你可以把大模型的参数空间理解成一个压缩过的“知识的影子”，它有大量内容，但每一条都是压缩过的概率分布，不是精确索引的数据库条目。

有个很扎心的真相：模型回答问题时并不区分“它知道”和“它不知道”，它只会顺着语言的惯性往下走。你问一个冷门领域的问题，如果训练数据里相关文本很少，那模型只能靠泛化去“编造一个最像样的回答”。这就是幻觉的底层来源——语言惯性压过了事实约束。

1.2 无中生有的三种典型形态

实际用下来，幻觉大致可以分成三类：

• 事实性幻觉：模型把人物、时间、数字、条款彻底说错，例如把某个产品的发布日期从2019年说成2022年，还讲得头头是道。
• 无中生有：直接捏造不存在的来源、论文、公司政策。我见过最离谱的，是模型给一个企业客户生成了一个“内部管理制度编号”，还附上了完整章节结构，整个制度根本不存在。
• 逻辑断裂：在长回答中，前半段还正常，后半段开始自相矛盾，甚至编出“因为A所以B”这种不合理因果链。

这三种幻觉在纯参数化生成里基本无法根治，因为你没法靠“更长的训练”来解决。静态知识训练完之后是固定的，而真实世界的事实一直在变，企业内部文档、产品参数、政策条款这些私有知识，大模型在预训练阶段根本没机会见过。

1.3 为什么微调也没解决根本问题

很多人会想到微调，但也得泼盆冷水。微调的本质是用更多针对性的数据去调整概率分布，它确实能改模型的语言风格和固定格式，但要让模型稳定记住某一条具体事实，需要大量的重复样本，而且要保证训练数据里“事实知识”和“语言风格”没冲突。更关键的是，只要企业内部知识在持续更新，微调模型就是个无底洞——文档改了，模型就得重新训一遍，成本根本扛不住。

所以行业里才转向了RAG这种路子。思路很直接：模型自己不需要记住每条具体事实，它只要学会“带着检索到的资料去作答”就够了。事实从哪来？从你指定的知识库里实时拿，而不是从参数里赌。这等于把模型从“知识存储者”降级成“阅读理解者”，幻觉从根上就被削弱了。

提示：这里有个很重要的认知转变，RAG不是让模型变聪明，而是给模型加上了一个“强制查阅资料”的前置动作。模型依然可能答错，但它答错的概率会大幅降低，因为答案来源从“概率猜测”变成了“给定素材的推理”。

2. 先查书再回答：RAG的完整工作链路拆解

RAG的全称是Retrieval-Augmented Generation，检索增强生成。一句话概括就是：在模型生成回答之前，先从外部知识库中检索出一批相关内容，把内容拼接进提示词里，让模型基于这些内容作答。

2.1 链路总览

一个典型的RAG系统包含五个环节：

1. 文档加载：把PDF、Word、Markdown、网页等格式的原始资料读进来
2. 文本切分：把长文档切成一段一段的小文本块
3. 向量化：用嵌入模型把每个文本块转成一个高维向量
4. 检索召回：用户提问时，把问题也转成语义向量，找出知识库里最相似的若干文本块
5. 生成作答：把检索到的文本块和用户问题拼在提示词里，交给大模型生成最终答案

整个链路看着简单，但每个环节都有讲究，尤其切分和检索这两步，直接把控着回答质量的上限。

2.2 文档加载：别急着处理，先“清洗”

很多人上来就想直接切分，结果垃圾进垃圾出。我自己踩过的坑至少有三个：

• 扫描版PDF直接进来全是乱码，必须加OCR环节
• PDF里的页眉页脚、水印被当成正文切进来了，检索到之后噪声极大
• 表格数据在文本化之后丢失了结构，变成一长串空格分隔的数字，模型根本读不懂

所以文档加载阶段一定要做清理和格式归一化。我现在的标准动作是：先转纯文本，再统一去除页眉页脚、URL、特殊字符，表格尽量转成Markdown表格保留结构语义，图片里的文字走OCR。这个阶段多花半小时，后面检索少踩十倍的坑。

2.3 文本切分：这可能是被低估得最严重的一步

文档切分直接决定检索的粒度。切得太粗，一段塞完整章，语义混杂，向量检索时难以精确命中关键句；切得太细，变成了几句话一块，虽然能精确定位，但常常缺少上下文支撑，模型回答起来也摸不着头脑。

我举一个真实对比案例。同一份项目章程文档，我用两种方式测试：

这里的关键发现是：切分要尽量保持语义单元的完整性，段落天然是语义单元。不要机械按字数硬切，要结合标题层级和段落边界切。企业文档切分还有一个很实用的技巧——多级切分：先按一级标题切出大章，再按二级标题切出小节，小节内部再按段落细切。这样的好处是，检索时可以控制“召回范围”，既保证了精确性，又保留了回溯上下文的可能。

2.4 向量化和索引：嵌入模型选型与向量库

文本块准备好之后，下一步就是向量化。嵌入模型的作用是“把文字翻译成位置坐标”，语义相近的文本在向量空间里距离近，语义无关的距离远。嵌入模型的核心选择标准有三个：

• 中文效果好不好（这是很多通用英文模型的短板）
• 输入长度上限够不够（有的模型只支持512 token，长段落会被直接截断）
• 向量维度是否适合自己后端库的规模（维度越高精度越高，但存储和计算成本也越大）

向量库的选择就更常见了，开源的有Milvus、Qdrant、Chroma，商业的有各云厂商的方案。小规模的个人项目比如几百个文本块，Chroma完全够用；生产级环境要上Milvus或者Qdrant，不但支持分布式，还能做混合检索。这个“混合检索”后面细说，它和纯向量检索差异极大。

2.5 生成作答：提示词的设计直接决定“是否忠于材料”

最后的生成环节，大模型的提示词设计是决定幻觉压制效果的关键。一个合格的RAG提示词至少要包含四层信息：

1. 系统指令：你是知识库问答助手
2. 回答规则：只能依据提供的资料回答，资料没有的内容，明确说不知道，不要猜测
3. 检索资料：有明确分隔符包裹的若干文本块
4. 用户问题：用户原始问题

其中第二层“回答规则”必须写得非常具体，比如：

你是一个严谨的知识库问答助手。 请严格依据<document></document>标签内提供的资料回答用户问题。 要求： 1. 只能使用资料中明确出现的信息，不得推测或想象。 2. 如果资料完全没有相关内容，直接回答“未检索到相关信息”。 3. 如果资料中存在相关但不完整的信息，先回答已有部分，然后补充说明缺少哪些信息。 4. 回答末尾列出引用的文本块编号。

这套规则看着只是文字，但它实际上是在告诉模型：你的角色不是“知识权威”，而是“资料转述者”。角色一转换，模型生成时的“自由发挥”空间就被压制了。

3. 为什么RAG能把幻觉降下来：从根上换回答策略

聊完链路，回到标题里最核心的问题：RAG到底是怎么把幻觉降下来的？我觉得可以从四个角度回答。

3.1 事实来源:从闭卷考试换成开卷考试

这是最基础、也最核心的转变。纯大模型回答问题时，全靠参数里压缩的“记忆”，这相当于闭卷考试。你有印象的题就能答，没印象的题只能连蒙带猜。RAG系统给模型配了一摞参考资料，相当于开卷考试，答案细节从资料里直接找，不需要凭记忆复述。闭卷考试的“记忆偏差”和“杜撰可能性”天然存在，开卷考试则大大降低了编造需求。

3.2 答案有了可验证的出处

RAG的引用溯源能力是个隐性但巨大的价值。检索模块能告诉你命中了哪些文本块，生成模块写提示词时要求引用编号，最后用户在答案里能看到“这段内容来自第3段资料”。这个能力直接改变了幻觉问题的性质：幻觉从“无法检测的一本正经胡说八道”，变成了“可以被人工核验的回答”。一旦用户能快速核对原文，错误就会被发现、被纠正,这是纯模型输出做不到的。

3.3 知识库可控更新，回答跟着资料走

企业内部知识的更新速度往往比模型重训快得多。RAG把知识的更新成本从“重训练模型”降到了“替换文档、重新向量化”。资料一变，系统回答的内容就跟着变，语义和事实的一致性由外部资料把关，模型参数完全不用动。这个优势对垂直场景来说简直刚需。

3.4 大模型的“角色切换”：从创作者变成转述者

还有一层容易被忽视的原因：RAG改变了模型在提示词里的“角色设定”。纯生成模式下，模型默认是“全知全能的答题者”，它会主动调动所有知识去组织答案，这是一种创作状态。RAG模式下，提示词强制它进入“基于给定材料回答”的转述状态，模型会倾向于摘取、概括、拼接资料中的原句，而不是自由创作。这种角色切换对生成方式的影响非常明显。

不过把话也说回来，RAG不是万能药。它解决的是“知识来源”问题，解决不了“模型本身能力不足”问题。如果用户的问题高度依赖复杂的多步推理，或者检索到的资料本身不准确，RAG依然可能给出错误回答。所以严格来说，RAG不是消除了幻觉，而是把幻觉的“触发范围”大幅缩小了。

提示：RAG对抗幻觉的本质，是把概率生成的信息源换成事实依据，而不是让模型永远不会错。评估一个RAG系统是否有效，要看“错误回答率”下没下降，而不是看“错误是否归零”。

4. 落地实操：一个最小可复现的RAG项目起步方案

上面部分偏原理，接下来说点能直接上手的。常见的技术栈组合，我这里给出一套相对成熟的方案，适合中小型知识库问答场景。

4.1 技术选型参考

这套组合的优点是：每一层都可以替换，方便后续调优。比如嵌入式模型换成其他开源模型，向量库从Chroma迁到Qdrant，改动成本都不高。

4.2 核心流程的起步代码

拿LangChain做示范，最小可运行的链路大概是这个样子的：

from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA # 1. 加载与切分 loader = PyPDFLoader("企业制度手册.pdf") documents = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=80, separators=["\n\n", "\n", "。", "；", "，", " ", ""] ) chunks = splitter.split_documents(documents) # 2. 向量化与入库 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = Chroma.from_documents(chunks, embeddings) # 3. 检索问答 qa = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), return_source_documents=True ) result = qa({"query": "请说明年假政策"}) answer = result["result"] source_docs = result["source_documents"]

这段代码最需要注意切分器的参数。chunk_size是块的最大字符数，chunk_overlap是相邻块之间的重叠字符数。重叠的目的在于，当关键信息恰好处于两个块的边界时，两个块都包含这段文本，检索时不容易被遗漏。为什么是600字符而不是100？因为中文600字符大约是300到400个token，既不会因为太短丢失语义，又不会因为太长导致向量表示模糊。

4.3 第一次跑通后先别急着上线

跑通这套代码只需要几个小时，但真正要打磨到好用，需要做以下三件事：

第一，构建评估集。准备20到50个真实业务问题，标注出“标准答案”或“答案应在哪些文档中出现”。没有评估集，后续的所有优化都只能是“感觉好多了”。

第二，跑一遍基线。用默认参数跑评估集，记录回答的命中率和正确率。哪怕效果一般也先记着，这就是之后对比的基准线。

第三，分析错误类型。把错误回答归类：是“检索没找到对的块”还是“检索到了但模型没用对”？这两种错误的优化方向完全不同，前者调切分和检索策略，后者调提示词和重排策略。

5. 自己实践时的关键调优点：从检索到提示词逐个击穿

上面讲的是从零到能跑通，下面这部分是真正影响回答质量的调优实践。我从自己的实测中挑出四个影响最大的环节。

5.1 TopK设置：召回多少块最合适？

search_kwargs={"k": 5}中的k就是召回数量。这个参数单独拎出来说，是因为它直接控制模型接收资料的多少。

• k太小（比如1到2）：语义匹配稍有偏差就会导致答错
• k太大（比如10以上）：噪声信息混入，模型反而被无关内容带偏，可能从某段资料里抓出一句无关的话强行展开

我的经验是，知识库类场景通常落在3到8之间。先定5，再看错误类型调：如果错误集中在“相关片段没被召回到”，增加k；如果错误集中在“回答被无关片段带跑偏”，减少k，或者引入重排模型（下面讲）。

5.2 重排：召回之后最有性价比的优化

向量召回擅长“语义初筛”，但它有个天然弱点：嵌入模型计算相似度关注的是语义相近，而不一定是信息相关性。比如用户问“年假天数”，一篇介绍“新员工入职培训含年假制度讲解”的文本块，语义上相关，但实际信息量极少。重排模型就是在向量召回后，再做一轮精确排序，把真正能回答问题的块排在前面。

from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CrossEncoderReranker reranker = CrossEncoderReranker( model_name="BAAI/bge-reranker-base", top_n=3 ) retriever = ContextualCompressionRetriever( base_compressor=reranker, base_retriever=vectorstore.as_retriever(search_kwargs={"k": 10}) )

这段代码典型的变化是：先粗召回10个块，再用重排模型选Top3。实测下来，回答准确率通常能提升10到20个百分点，是“性价比最高”的一次调优。

5.3 混合检索：向量不是万能的

向量检索对语义理解的强项非常突出，比如“我休年假去国外，一共可以离开岗位几天”这种口语化表述，关键词检索基本没辙，向量检索能理解。但向量检索也有弱项，比如精确匹配的型号编码、合同编号、人名产品名这类强标量信息，向量化之后语义容易被“稀释”，而关键词检索反而能精确命中。所以生产级RAG系统一般都做混合检索：BM25关键词检索和向量检索并行召回，再合并去重。

from langchain.retrievers import BM25Retriever, EnsembleRetriever bm25_retriever = BM25Retriever.from_documents(chunks, k=5) vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) ensemble_retriever = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.3, 0.7] )

这个权重配比也是经验值加上测试调整的结果。我是先在向量检索权重0.7、BM25权重0.3的基准上跑评估，再根据错误类型微调：如果错误主要是“精确编号没匹配到”，把BM25权重往上调；如果错误主要是“语义理解不足”，则反过来。

5.4 提示词迭代：让模型“克制”一点

最后一个调优点回到提示词。RAG提示词不是写一次就完事的，要配合评估集持续迭代。实操里我常用的迭代方法是“故意给错材料”：构造一个问题，故意把知识库里相关的文本块全部排除在外，看模型会怎么回答。如果模型还是强行编个答案出来，说明提示词约束力度不够；如果模型老老实实说“资料中未找到相关答案”，约束才到位。

我目前使用的一个通用提示词模板，供参考：

系统角色：你是企业知识库智能问答助手。 回答规则： 1. 只允许使用<document></document>中提供的资料进行回答。 2. 资料中完全没有的内容，直接回答“未检索到相关信息”，不要自行发挥。 3. 回答时尽可能还原资料中出现的原话表述，不要改写扩写，不要添油加醋。 4. 引用资料时标注资料编号，如有多个相关编号，请一并列出。 5. 如果用户问题和资料无关，拒绝回答并解释原因。

“不要改写扩写，不要添油加醋”是我用过的最有效的一句，它直接把模型的自由发挥空间压到了最小。虽然牺牲了一点点流畅度，但在事实准确性优先的场景里，这个取舍是值得的。

6. 踩过的坑与验证方法：防不胜防的边界情况

RAG落地过程中有一些边界情况很少被人提前提醒，但实际遇到时很折磨人。我把踩过的几个典型坑集中梳理一下。

6.1 检索到了但回答错误：问题出在“跨块推理”

有一回知识库里明明有完整的项目管理制度，用户问“项目立项的审批流程和预算限额分别是多少”，模型答得支离破碎。查了半天，原因是一次回答需要两个不同文本块里的信息，检索只召回了一个块，模型手里缺料，只能硬补。这类问题通常不是提示词的锅，怎么办？要么把k调大，要么优化切分策略，把同一章节内、逻辑关联紧密的段落尽量放进同一个块。注意观察回答时“哪些字段模棱两可、含糊不清”，就知道缺哪块料了。

6.2 嵌入模型吃下水道错误：中英混排的陷阱

有些企业文档中英混排，嵌入模型却对中文不够友好，导致“中文问题”和“英文资料”的向量距离远得离谱，检索基本失效。规避方案是：在文档清洗阶段统一语言，或者选择对中英文都支持较好的嵌入模型，再或是对问题和文档同时做语言归一化预处理。数据库字段也别放过，一些实体名词大小写不一致也会导致精确匹配失效。

6.3 评估RAG效果的硬指标

接前面说的，RAG系统上线前务必跑评估。我一般会记录四类硬指标：

这里必须强调引用忠实度，这是RAG系统里最隐蔽的坑。模型可能给出的文字内容”看似合理，但引用的来源其实无关甚至反对自己。深层原因是：提示词里没有把“引用”和“依据”严格绑定。解决方式就是前面提到的“只能使用资料中的信息，并在末尾列出引用块编号”这层指令，配合评估集逐条审计。

7. 效果实测与经验总结

最后分享一下我自己评估集上的实测数据。一个关于企业产品知识的问答场景，知识库包含产品参数文档、销售话术、售后政策三个来源，评估集60个真实问题。在未加任何RAG之前，纯大模型回答的事实正确率大概在65%左右——也就是大约三分之一的回答有明显事实错误。接入基础RAG（向量检索，k=5，无重排）之后，正确率提升到83%。再加上重排、混合检索和严格的提示词约束后，正确率稳定在91%到93%之间。

这个数据并不惊艳，但已经说明问题了：三分之一的错误被压缩到十分之一，而且剩下的错误主要来自知识库本身不完整或文档过时，属于内容治理范畴，不再是模型“瞎编”的问题。

从投入产出比来看，RAG的核心价值是可控。可控的意思不是说每次回答都对，而是说每次回答都有据可查、可追溯、可迭代。只要资料是对的，模型回答就不会跑太偏；资料错了，改资料就行，系统不需要重训。这个特性在企业级知识问答场景里，价值比任何花哨的技术指标都大。

如果现在要做一个知识库问答系统，我建议的最小起步组合是：文档清洗加段落切分，加一个中文友好的嵌入模型，加向量检索，加一个约束力清晰的提示词，第一次跑通就围绕这几个环节做小步迭代。别一开始就上复杂的编排框架和超多模块，先把主链路跑通，用评估集量化出基线，再逐步加重排和混合检索。这个路线最稳，也最容易复现。