企业官网建设流程全解析

这两年大模型火得一塌糊涂，但真正用到业务里，大家聊得最多的既不是写诗也不是画画，而是怎么让模型回答得“靠谱”。“RAG入门”这个标签几乎成了大模型落地绕不开的第一站。所谓RAG（Retrieval-Augmented Generation，检索增强生成），说白了就是先让你的模型去知识库里翻资料，再根据资料来回答。这篇文章我打算用大白话把RAG从头到尾拆一遍，不用你懂复杂的数学公式，只要会点Python基础，跟着思路走就能搭出属于自己的知识问答系统。不管你是产品经理想给项目加个私有知识助手，还是开发者准备做企业内部文档问答，这篇都能帮你省去大量踩坑时间。

1. 先搞懂RAG到底解决了什么问题

1.1 大模型的两个“天生缺陷”

大模型再聪明，也藏着两个让人头疼的问题。

第一个是知识截止日期。模型训练完的那一刻，它的知识就“冻结”了。你问它今年最新发布的产品参数、你们公司内部刚更新的制度流程，它大概率只能胡编。原因很简单，这些信息它根本没学过，或者学过但已经是过时的版本。

第二个问题是幻觉。当模型遇到不会答的问题时，它不会老老实实说不知道，而是会“自信地编造答案”。这种一本正经的胡说八道，在日常闲聊里问题不大，放在医疗、金融、法律这种对准确性要求极高的场景里，就是灾难。我见过不少团队前期信心满满，一测真实业务问题就傻眼了，答案编得比真还真，但全是错的。

1.2 RAG的核心思路：让模型学会“查资料”

RAG的解决思路非常朴素，不改变模型本身，而是给它加了一个“查资料”的环节。你想让模型回答一个问题时，先从你的知识库里把相关资料检索出来，然后把这些资料塞进提示词里，告诉模型“以下资料供你参考，请基于资料内容作答”。

你可以把这个过程类比成开卷考试：微调是让一个人把知识背进脑子里，而RAG是让他带着参考书去考试。开卷考试的优点很明显，不心疼脑容量，想查什么翻书就是，信息更新只需要更新书的内容，不需要让这个人重新学一遍。这正是RAG最大的价值主张：知识实时可更新、内容来源可追溯、实现门槛比微调低得多。

1.3 为什么RAG比微调更适合大多数场景

很多人第一次接触RAG时会问：“为什么不直接微调模型呢？”这是个好问题。

微调的本质是修改模型内部的参数，让模型本身的“知识结构”发生变化。听起来很厉害，但代价也不小：每次知识更新都要重新训练一套模型，成本高、周期长，而且微调对硬件的要求也不低。更麻烦的是，微调并不能很好解决幻觉问题，模型该编还是会编，只是编得“更像那么回事”。

相比之下，RAG对知识更新的响应是秒级的。文档改了，重新灌进向量库，下次检索就是新内容。你可以把知识库看成独立的资产，换哪个模型都不影响这部分积累。所以我的观点很明确：如果你的目标只是让模型了解某个具体领域、回答某个封闭范围内的问题，RAG永远是优先尝试的方案。微调更适合做风格迁移、工具调用、输出格式约束这种事情，而不是单纯的“知识注入”。

2. 核心组件拆解与实操要点

2.1 RAG系统流转的四个关键环节

一套标准的RAG流程，由四个核心环节组成：文档加载、文本切分、向量化和检索生成。这四个环节环环相扣，前面任何一个环节偷了懒，后面就别想有好结果。

这里面最容易忽视的是第二个环节：文本切分。很多新手上来就直接把整篇文档塞进向量库，结果检索出来的是一大坨内容，上下文被塞得乱七八糟，模型根本没法定位到关键信息。我一会儿专门讲这个。

2.2 文档切分：粒度决定检索质量

文本切分是把文档拆成很多个小片段，然后每个片段单独做向量化。切分粒度的选择，直接决定了检索的召回效果。

我自己的经验是：切片不能太大，也不能太小。太大了，检索出来的片段主题漂移，模型找不到精确答案；太小了，片段之间语义割裂，该有的上下文信息丢失了。最常见的做法是用LangChain里的RecursiveCharacterTextSplitter，按照“段落优先、长度兜底”的原则切割。先尝试按段落分隔符分割，如果分出来的块还是太大，再递归到更小的分隔符继续切。

举一个实际的例子，我在一个模拟项目X里处理一份200多页的产品说明书，初始设置chunk_size（块大小）为500个token，overlap（重叠长度）为50个token。测试下来发现，500个token的切分对长段落场景效果不错，但有些段落本身很短、上下文信息被割裂，于是我把chunk_size从500降到384，反而精准了不少。原因很简单：知识文档中答案往往集中在1-2个核心段落里，切分过大会混入噪音，切分过小又会丢失关键背景。

这里必须提到一个关键参数：chunk_overlap。切分时让相邻片段有少量内容重叠（一般20~50个词），相当于给每个片段加了“记忆衔接”。没有overlap时，一个原本连贯的句子正好被从中间截断，前半句在上一块、后半句在下一块，检索的时候两块都不完整，答案自然对不上。加上overlap之后，这种断裂问题明显减少了。

2.3 向量化与向量数据库的选择

切分后的文本要被嵌入模型（Embedding Model）转换成向量，也就是一个几百上千维的浮点数数组。这个向量可以理解为文本的“语义指纹”，越相关的文本，向量之间的距离越近。

选择嵌入模型时，中文场景下我建议优先考虑开源的国产嵌入模型，比如BGE系列、M3E系列。它们的优点是针对中文语料做了优化，词汇量大，对中文语义的把握比通用模型明显更细腻。M3E在语义相似度任务上的表现，在同等体量的通用模型里通常领先，实测下来对长尾的专业术语也有一定的区分度。

向量数据库的选型，如果只是学习或者做个原型，强烈建议用FAISS或者Chroma。Chroma的优势是轻量，直接在本地跑，API设计简单，很适合初学者快速起步。如果团队里的文档量到了百万级、千万级，再考虑Milvus或者专用的托管向量库。两个维度的决策要点：一是看部署成本能不能被团队承受；二是看检索延迟和并发量是否满足业务需求。FAISS的好处是完全离线、不依赖外部服务，隐私敏感的项目用起来很踏实。

2.4 生成环节：提示词决定了答案的规范性

向量检索只负责“找资料”，最终回答还是要靠大模型生成。生成这一步，提示词的设计非常重要。你需要明确告诉模型三件事：你是某个领域的知识助手、必须基于给定的参考信息作答、信息不足时直接坦白说不知道。

我在实战里常写这么一套模板：

system_prompt = """ 你是企业内部知识助手。你的任务是根据提供的参考信息回答用户问题。 规则： 1. 只使用参考信息中的内容作答，不得使用你自己记忆中的知识。 2. 如果参考信息中没有相关答案，请明确回答"知识库中未找到相关内容"。严禁编造。 3. 回答时注明信息来源编号[1]、[2]等，方便用户核对。 参考信息： {context} 用户问题： {question} """

这个模板看着简单，作用却大。第一个规则把答案严格限定在知识库范围内，极大压缩幻觉空间；第二个规则给模型留了退路，避免它硬着头皮编答案；第三个规则方便做溯源验证，回答错了用户一眼就能看出来是哪份文档写得有问题。

3. 一个最小可跑的RAG系统：手把手实测

3.1 环境准备与数据准备

下面我带你亲手搭一个最小可跑的RAG问答系统。这个项目我命名为“模拟项目X”，目标是根据一份虚构的公司新人手册回答新员工问题。整套流程用Python实现，纯本地开发环境，不需要GPU也能跑。

先安装核心依赖：

pip install langchain langchain-community chromadb sentence-transformers faiss-cpu

代码里我用Chroma做向量库、用开源的SentenceTransformer加载嵌入模型（框架名就不写了，反正驱动方式一致）。运行环境是Python 3.10，实测在普通笔记本上完全流畅。

数据准备方面，我准备了一份3000字左右的纯文本文件employee_handbook.txt，里面包含公司请假制度、报销流程、团建规则、值班安排等常见问题。这类数据非常直观，你换成自己的总结合同、项目文档、故障排查手册，流程是一模一样的。

3.2 从文件读取到向量化入库

整套流程分五步：读取文档、文本切分、生成向量、写入向量库、封装检索问答函数。

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader = TextLoader("employee_handbook.txt") documents = loader.load() # 2. 文本切分 text_splitter = RecursiveCharacterTextSplitter( chunk_size=384, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = text_splitter.split_documents(documents) print(f"切分成 {len(chunks)} 个文本块")

这里选择separators的顺序很有意思。系统会优先用第一个分隔符“换行+换行”来切分，如果分完还是超过chunk_size，就换用“单个换行”，再不行就用“句号”等中文标点。这种层层降级的方式，让切分尽量尊重原文的语义边界，而不是硬按字数劈开。我实测过，如果直接按空白字符切，非常容易把一句完整的话拦腰截断。

然后是向量化和入库：

from sentence_transformers import SentenceTransformer import chromadb from chromadb.utils import embedding_functions # 3. 加载嵌入模型（开源中文嵌入模型，输出512维向量） embedder = SentenceTransformer("path/to/your/chinese-embedding-model") # 4. 创建向量库并写入数据 client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection( name="handbook", metadata={"hnsw:space": "cosine"} ) for i, chunk in enumerate(chunks): collection.add( ids=[str(i)], embeddings=[embedder.encode(chunk.page_content).tolist()], documents=[chunk.page_content], metadatas=[{"source": "employee_handbook.txt"}] )

实际项目中，我一般不手工一条条add，而是用LangChain的Chroma.from_documents一行搞定，但手工写的好处是你能直观理解每一步在干什么，出了Bug也知道去哪里排查。存入Chroma时我特意指定了"hnsw:space": "cosine"，也就是检索时用余弦相似度。对文本向量来说，余弦相似度比欧式距离更合适，因为它只关注方向差异，对向量长度不敏感。

3.3 检索与生成：完整问答函数

向量库建好之后，写问答函数就很简单了。先根据用户问题检索出最相似的前K个文本块，再把它们拼进提示词，最后调用大模型接口生成答案。

def ask_question(question, top_k=4): # 将问题转为向量 query_embedding = embedder.encode(question).tolist() # 检索相似文本块 results = collection.query( query_embeddings=[query_embedding], n_results=top_k ) # 拼接参考信息 context = "\n\n".join(results["documents"][0]) prompt = system_prompt.format(context=context, question=question) # 调用大模型接口生成答案 answer = call_llm(prompt) # 这里对接你自己的大模型服务 return answer

参数top_k默认设为4，这个取值是我反复测试权衡出来的。K值太小，可能漏掉关键信息；K值太大，噪音文本混进来反而干扰判断。实测在这个新人手册场景里，K=3到K=5效果都不错，你可以根据自己知识库的切分粒度和内容质量去微调。

我拿几个真实问题跑了测试，效果超出预期。“请病假需要提前多久报备？”准确回复了手册里“病假需提前30分钟向直属主管报备”的原意，并附上了来源段落；“报销发票需要提供哪些信息？”也准确列出了手册中的要求。更有意思的是，当我把问题换成手册里根本没写的“公司期权政策”时，系统正确回答了“知识库中未找到相关内容”，而不是张口编造。这一步验证了提示词第三条例的效力：严禁编造。

3.4 关键参数效果实测对比

参数这个东西，不同项目最优解差异很大，光靠背书没用。我在每次调参后都会跑一遍同样的测试集，用表格记录结果。下面是一张我在模拟项目X中实测的对比表，供你参考：

这张表是我自己实测的结果，换你的文档结构数据，最优点可能偏移，但调参的思路可以参考：先固定一个较宽的chunk_size区间，多试几组，观察检索出的文本块质量，再微调overlap和top_k。

4. 实战中一定会踩的坑：问题排查与优化

4.1 检索不到相关内容，别急着换模型

“检索不到相关内容”是RAG新手遇到最多的第一大坑。很多团队第一反应是换更强的嵌入模型，或者换更大参数的大模型，其实很多问题出在更前置的环节。

先检查一下你的文本切分。如果chunk_size过大，一段几百字的文本里只有一句话和问题相关，剩下的全是噪音，相似度得分被平均掉，结果排名靠后，就喂不进上下文了。如果你发现检索出来的内容“模棱两可”，试着把chunk_size调小一点，让每个文本块聚焦于单一主题。

再检查你的查询方式。很多刚起步的人直接把原始问题送去和所有向量做相似度比较，遇到复杂问题效果很差。比如用户问“请假流程里遇到主管出差怎么办？”，这个问题的表述和手册中的原文差别很大，纯向量检索可能匹配不到。可以尝试对问题做改写，让模型先把问题转换成更适合检索的句式，或者直接用关键词提取的方式做一次浅层匹配，再配合向量检索做混合召回。关键词和向量混合的Hybrid检索，优化效果特别明显，简单粗暴但十分有效。

最后还要检查嵌入模型的词表覆盖。如果你的知识库是某个垂直行业（比如特种设备检修、医疗术语），通用开源嵌入模型可能压根没学过这些词汇。换用BGE-large这类参数量更大、中文语料覆盖更广的模型，召回率通常会有质的提升。

4.2 上下文塞爆了怎么办

RAG系统的核心瓶颈之一是大模型上下文窗口有限。即便现在主流模型都有了很大的上下文窗口，也经不住你把大段检索结果一股脑塞进去。

解决方法有两个思考方向。第一是“少而精”：提高检索精准度，让每个检索结果都是必要的。我上面提到的混合检索、问题改写都是干这个用的，尽可能把top_k从6降到4，用质量换数量。第二是“压缩摘要”：检索到的多个文本块在拼进提示词之前，先用一轮小的LLM调用对它们做摘要去重，把重复信息和离题内容挤掉，再进主模型。这个做法增加了延迟，不能滥用，但在处理大量文档时非常管用。

另外提一下，有些场景里知识库文档本身就特别长，比如原文一段就是几千字。这时候需要先做“父文档切分”：把一个长文档切成若干个短块，每个短块做向量化用于检索，但检索命中后返回的不只是这个短块，而是包含它的完整长文档。这样既保证了检索的精准度，又不会丢失上下文完整性，是处理超长文档的关键折中方案。

4.3 答案有幻觉或者答非所问

有人说加了RAG模型就不再幻觉了，这是完全错误的期待。RAG大大降低了幻觉概率，但只要步骤哪里没配合好，模型照样会顺着语义强行编。

排查思路从三处入手。第一，检查检索内容是否真的和问题相关。RAG的链路很长，模型把错误的检索内容当成“参考信息”之后，就会被误导到更离谱的方向。第二，检查提示词是否明确约束了模型禁止使用自身知识。很多情况下模型觉得自己“知道”答案，就懒得看参考信息了。第三，检查prompt里参考信息的格式。如果你的检索结果是一坨完全没有标号、没有层次结构的长文本，模型很容易迷失重点。

还有一个实践技巧：在回答中强制要求模型输出引用来源编号。模型每次生成时都要说“根据[2]号文档显示……”，这样即便偶尔答错了，你和用户也能一眼定位到是哪份文档的信息误导了模型，方便及时修正源头。

4.4 快速评估RAG效果的三板斧

用RAG不能只靠感觉判断“好像还行”，需要有一组快速、低成本的评估方法。

第一板斧：单测验收。准备20到30个典型问答对，覆盖知识库内的关键知识点，再加入少量故意超纲的“陷阱问题”，每次改动后跑一遍，记录正确率、拒答率和错误率。比跑几百条数据快得多，改参数反馈速度极快。

第二板斧：检索命中检查。每跑一个测试问题，把检索返回的前K个片段打印出来，人工看一眼“这次检索找对内容了吗”。这个检查虽然原始，但在快速迭代阶段不可或缺。你很快会发现哪些问题是切分粒度不合理造成的，哪些是嵌入模型理解偏差造成的。

第三板斧：引入开源评估指标。等系统迭代到后期，可以引入召回率、命中率、MRR这些离线指标做量化评估。RAGAS这类专门评估RAG效果的框架也能帮忙，只是它本身要调用模型，需要额外token成本。先跑人工小批量，再上自动化评估，是我比较推荐的节奏。

4.5 将RAG从头实现一遍之后的一点点感想

做RAG做到后面，你会发现它本质上不是一个算法问题，而是一个工程问题。文档干净程度、切分质量、检索策略、提示词设计、参数调优，每一个环节都在贡献质量，也每一个环节都在拖后腿。你唯一能做的，就是建立自己的测试集，然后反复迭代。拿我自己的体会来说，最难的不是把系统搭出来，而是让系统在真实数据下保持稳定的高质量表现。每当我把一个看起来很小的问题优化好，系统整体体验都会往上跳一小截，这种正反馈其实就是不断探索技术边界的乐趣所在。