企业官网建设流程全解析

最近组里有个新来的同事，对着大模型问了一下午“咱们那个内部系统的上线时间是什么时候”，模型一会儿说三号，一会儿说十五号，最后他还真信了十五号，差点把排期搞崩。这种场景我太熟了——大模型知识停留在训练时，你的私有资料、实时信息、内部文档，它根本不知道。而“RAG大模型实战”里讲的这项知识增强技术，就是专门治这个病的：把外部知识库接到大模型上，让它学会“先查资料，再回答”。这篇内容主打小白可学，我把自己从零接触RAG、亲手搭完一个问答系统的完整思路、关键代码和踩坑记录都放进来，你看完至少能明白这套东西的原理，并且知道下一步该往哪儿使劲。

1. RAG到底解决什么问题：先把“为什么”想清楚

1.1 大模型不是百科全书，它只是一个“接话专家”

很多新手对大模型有一个误解，觉得它既然读过那么多资料，讲什么都会有依据。但实际上，大模型在训练时做的事，就是根据上文预测下文，海量文本喂进去之后，它学到的是词语之间、概念之间的大致统计规律。说得直白点：它不是在“回忆”，而是在“接话”。训练数据里的知识会变成参数权重，但这些参数学完就固定了，训练时没见过的东西，它不可能凭空知道。

这就带来两个最典型的毛病。一是“时效性差”，行业动态、公司规则、最新政策这些高频更新的信息，模型根本没法感知；二是“私有知识缺失”，你自己的产品文档、项目日志、团队沉淀，这些根本没有出现在它的训练语料里，它当然答不上来。更麻烦的是，一旦被问到不知道的东西，它不会老老实实说“我不知道”，而是会顺着你的问题编一段看起来合理的回答，这就是所谓的“幻觉”。模型自己是不会辨别“啥时候是在胡编”的，因为对它来说，生成一段通顺的文字就是全部任务。

所以我常说，大模型更像一个知识面极宽但从不翻书的“接话专家”，你不能指望它脑子里装着所有最新的、私有的、甚至是你昨天刚写的资料。想要让它变成会查证的助理，就得给它一套“外面查资料”的机制。这就是RAG存在的价值。

1.2 RAG的核心思路：现场翻书，而不是死记硬背

RAG这名字，中文一般叫检索增强生成。拆开看就是两件事：先检索，再生成。整条链路其实很像人类查资料写报告的过程：你先有一个问题，然后去资料库、搜索引擎里找几篇相关的文档，看了之后，再结合这些文档的内容组织回答。

在技术上，这个过程大致分几步。第一步，把你要让模型学习的资料准备成一个知识库，这些资料可能是一批PDF、Word、Markdown、网页或者数据库里的记录。第二步，把这些长文档切成一个个片段，再用模型转成向量，相当于给每个片段算出一个能表示它语义的“指纹”，然后建立索引。第三步，当用户提问时，系统把问题也转成向量，在索引里找出最相似的那几个片段。第四步，把“用户的原始问题 + 检索到的几个片段”拼在一起，作为提示词，喂给大模型，让它基于这些资料作答。

这个“现场翻书”的动作，就是RAG相比直接问大模型的核心区别。知识更新时，你只需要重新处理一遍资料库，不需要重新训练模型；回答私有问题时，模型的所有依据都来自你给的资料，而不是它自己脑补。对我这种实用主义者来说，用一套现成的知识库把大模型的回答“锚”住，成本低、见效快，这也是为什么RAG现在成了大模型落地场景里最常见的方案之一。

1.3 为什么不直接微调：两套方案的取舍

很多人第一次接触RAG时会问：既然想让模型懂我的私有知识，为什么不直接用这些数据去微调模型？这个问题很关键，我也折腾过。简单说，微调是“把知识记进参数里”，RAG是“把知识放在外面随查随用”，两者各有擅长，但它们的适用场景完全不同。

我自己的经验是：如果你的核心诉求是“让模型知道某些事实”，优先用RAG。只有当你的目标不是“知道什么”，而是“用什么样的语气和格式说话”，比如模仿某种写作风格、适配固定的交互范式，微调才是更对症的方案。很多项目其实可以先用RAG跑通业务，再把高频问题沉淀成微调数据做优化，两条腿走路，而不是一开始就二选一。

说到底，RAG是个“外挂知识”的方案，它不动模型本身的参数，却能补上模型最缺的动态信息和私有信息。接下来，我们就拆开这套系统的内部结构，看看每个零件都该怎么做、怎么选。

2. 一个RAG系统的完整骨架：四大模块一次看明白

2.1 文档加载与清洗：垃圾进，垃圾出

所有RAG流程的第一步，都是把乱七八糟的原始文件变成干净、规整的纯文本。这一步看着不起眼，实际上决定了整个系统的上限。你想想，如果资料本身一堆乱码、错字、重复内容，后面切出来的片段、算出来的向量，自然也好不到哪去。检索这种环节，最怕的就是“数据源头不干净”。

先说格式。用PDF做知识库最普遍，但PDF是个“包装纸”，里面可能是文字层，也可能是扫描图片。文字层直接提取就行，扫描件就得先过OCR文字识别。我的习惯是：先抽几页看看提取出来的文字质量，如果出现大段乱码，赶紧换解析策略，不然整条链路都会被污染。网页资料要处理掉导航栏、页脚、广告这些噪声，只用正文。表格类数据尤其要小心，直接转成纯文本会丢失行列关系，常见做法是把表格转成Markdown表格或者一行一组的描述性文字，让语义保留下来。

清洗环节也别省略。全角半角符号不统一、多余的空行空格、从排版文件里带出来的页码和水印，这些最好在切分之前处理干净。我自己做项目时，清洗这块的耗时通常能占到前期处理的三成。别急着抱怨麻烦，这里的每一分钟，都会在后面的检索准确率上回报你。

2.2 文本切分的艺术：切多大多重叠都有讲究

文档清洗成纯文本之后，不能整篇丢进去建索引。一篇长文档动辄几千上万字，用户问的问题常常只涉及其中一小段，如果拿整篇去算相似度，答案的命中率会低得可怜。所以必须把长文档切成一个个语义相对完整的小块，这一步叫文本切分。

切多小合适？这是新手最爱纠结的问题。切得太小，比如一句话一个块，语义碎片化，“登录功能”和“密码找回”明明是一件事，却被拆成两段；切得太大，比如一整个章节一个块，里面内容太多，相似度计算时很多噪音会把关键信息稀释掉。没有绝对标准，但一般经验是：常规说明文档切成200到500字左右比较稳，代码文件按函数切，表格按行列语义切。关键要看你的文档结构和提问习惯来微调。

比块大小更隐蔽的参数是重叠。相邻两个块之间保留一小段重复内容，比如两句到三句，可以避免“恰好把关键信息截断在两段中间”的尴尬。我见过很多初版系统检索不到内容，最后定位到就是因为切分点把关键句子劈成两半，加上一点重叠后效果立刻不一样。切分看起来是很朴素的活，但它是后边所有步骤的地基，值得多花时间试几组参数。

2.3 向量化与索引构建：Embedding模型决定搜索质量

文本切完之后，下一步是把每一段文字变成机器能“算距离”的向量。你可以把向量想象成坐标，文字含义越接近，坐标距离越近。比如“如何重置密码”和“登录密码忘了怎么办”，这两句话在向量空间里的位置就非常接近，系统就能根据这个问题对应的坐标，找到周围最相近的知识片段。

负责这个向量化动作的，是一个叫Embedding模型的组件。选什么模型，对你的检索效果影响极大。中文场景下，我强烈建议优先选经过中文语料训练的模型，直接用英文为主的通用模型处理中文，相似度计算经常出现“看着相关，其实偏了”的问题。如果你的数据是领域味儿很浓的垂直内容，比如医疗、法律、工控，最好进一步找领域调整过Embedding都试试，同一套流程，换了模型召回质量可能是天壤之别。

向量建好之后，还得建索引。原理上没那么玄：第一次把成千上万个向量和原文一起存进向量数据库，后续查询不再傻傻地全量扫描，而是通过高效索引快速找相似项。这一层现在有现成的开源方案和托管的云服务，选型时重点看几件事：是否能本地化部署、检索速度、相似度计算方式、是否方便做过滤条件。我之前图省事直接用了默认配置，结果追着一个慢查询查了好久，后来发现是索引参数没调，调整之后速度上来了几个级别。

2.4 检索、重排与提示词拼接：最后一公里决定效果

知识进库之后，核心动作就剩检索和拼接。用户输入问题，系统先把问题向量化，然后到向量库里捞最相关的K个片段，这个K就是召回数量。K值不是越大越好，取太少可能漏掉关键内容，取太多又会把不相干的东西一起塞进来，给模型添乱。初期可以设成5到8，结合后面的效果再调。

光靠向量相似度直接返回topK，偶尔会出现“高相似但不对题”的情况。最近我还会在中间加一层重排：先拿向量检索召回几十个候选，再用一个专门的排序环节，把候选片段重新按“和问题的真实相关性”排序，只留下最精准的几个。这个动作不算复杂，但对回答质量的提升非常明显，属于低成本高收益的优化点。

最后是提示词拼接。这一步很多人忽略，以为把片段往提示词里一塞就行，其实提示词的写法直接决定模型是“照着资料回答”还是“自由发挥”。我常用的思路是：明确告诉模型“请根据以下参考资料回答用户的问题；如果资料中没有答案，请直接说不知道，不要编造”，然后把检索片段按顺序放在上下文里，最后附上用户问题。就这么三两句话的差别，有约束和没约束，回答的靠谱程度完全不同。

到这儿，RAG系统的骨架已经讲完了。接下面这部分，我带你把整个流程真正跑起来，从零开始搭一个本地问答工具。

3. 从小白到跑通：本地RAG问答系统的可复制流程

3.1 前置准备：想清楚这轮要做什么

动手之前，先给一个最小目标：不要一上来就想着做一个万能AI助理。我见过太多朋友兴致勃勃想一次搞定全公司的知识库，结果做了一半发现文档格式五花八门、权限逻辑复杂，项目烂尾了。小白的正确姿势，是找一个范围很小的场景先跑通闭环。

比如我建议的做法：拿一个你最熟悉的东西下手——自己最近在学习的课程讲义、一份产品说明书、某项目沉淀下来的QA文档。把范围限定在“围绕这些资料提问”这个单一诉求上。资料整理好之后，提前想清楚用户会问哪类问题，这能帮你后面验证检索效果的时候更有方向。环境方面，需要能跑Python脚本的环境，装好依赖的库、向量数据库服务，再准备好大模型接口或者本地跑一个小模型。第一次跑，不求规模，但求链路通。

3.2 最简核心流程：一段代码打通整个链路

先说清楚，我这里用的是伪代码思路，你现在手边的开源框架基本都提供了对应的现成方法，套用以下流程即可。真正动手的时候，你会发现核心逻辑非常简单，难的都是细节。

第一步，加载文档。

# 加载本地文档（支持的格式按实际框架能力来，PDF、Markdown、TXT最常用） documents = load_documents("./knowledge_base/") # 此处输出的是原始文档对象列表

第二步，文本清洗和切分。把清洗好的内容按前面讲的策略切成适度大小的块，并设置少量重叠。

# 清洗：去空行、去特殊字符、统一转码 cleaned_chunks = clean_and_split(documents, chunk_size=400, overlap=50) print(f"切分完成，共得到 {len(cleaned_chunks)} 个片段")

第三步，向量化并写入向量数据库。每个片段调用Embedding模型算出向量，连同样文一起写入索引。

# 向量化：调用 embedding 模型生成向量 embeddings = embed_texts([chunk.text for chunk in cleaned_chunks]) # 写入向量库索引，保留原文内容和元数据 vector_store.add(embeddings=embeddings, texts=[chunk.text for chunk in cleaned_chunks], metadatas=[chunk.meta])

第四步，检索并拼接。用户输入一个问题，转成向量，召回最相似的K个片段。

# 查询：问题向量化，召回最相似的片段 question = "这个系统的密码重置流程是什么样的？" question_vector = embed_texts([question])[0] results = vector_store.search(question_vector, top_k=6)

第五步，把问题和检索片段拼成提示词，交给大模型生成回答。

# 拼装提示词 context = "\n\n".join([r.text for r in results]) prompt = f"""请仅根据以下参考资料回答问题。 参考资料： {context} 问题：{question} 要求：如果资料中没有明确信息，请回答“无法从现有资料中找到答案”，不要编造。""" answer = llm_generate(prompt) print(answer)

就这么五步，一个能用的RAG问答工具已经成型。我第一次跑通的时候，心里挺惊讶的，怎么这么简单？但“跑通”和“好用”之间，还隔着一段调优的路。第一次跑通之后别高兴太早，照着下面的方法把效果拉上去才是真正的工作量。

3.3 三个立竿见影的调优动作

第一个动作，把“检索-生成”改成“检索-重排-生成”。前面已经讲过重排的思路，实操上就是在向量召回之后，多调一个重排序的接口，先召回比如20个候选，再重排挑出最精准的5个。这一步对回答质量的提升，比你在提示词上抠三天还有用。我自己的项目加上重排之后，人工评测的满意度从勉强及格提高到了有点好用的程度。

第二个动作，给提示词加“强制约束”。我最初版本没写“不知道就直说”这句话，结果模型面对检索不到答案的情况时，会硬着头皮编一段看起来很像那么回事的话。加一句“如果资料中没有明确信息，请直接说明无法回答”之后，输出立刻变得诚实可靠。这叫“兜底约束”，成本几乎为零，收益却极大。

第三个动作，反复调K值和相似度阈值。K值前面说了，一般从5到8开始调。相似度阈值则是一个过滤规则，低于某个相似度的片段不进入上下文。这两个参数互为牵制，得一起看。我的实操心得是：先固定K，然后用几个真实问题来回测阈值，找到“能答上来”和“不胡说”的平衡点。想把这套东西调到能用，这三个动作做完，基本能覆盖80%的场景需求。

4. 实测踩坑记录：常见问题与排查技巧

4.1 检索不到想要的内容：先排查五个环节

检索是RAG的命门，检索不到东西，后面啥都白搭。如果你发现“查出来的是错内容”或者“根本没查出来”，别急着怀疑模型，先按优先级排查。

一是原始文档是不是真的解析出来了。去清洗阶段看一眼抽取后的文本有没有乱码、截断，这一步问题最多。二是切分是否合理。试试把块大小改小或者增加重叠，很多“漏检”其实是切分把关键内容切碎了。三是Embedding模型适不适合你的语言和领域。通用模型处理专业术语，效果往往很差，换一个领域加强过的模型跑一遍，结果会完全不同。四是向量库索引有没有建对，集合名、命名空间这些看着不起眼，一旦搞错，查的就是个空库。第五个是查询本身。用户问得太模糊或者带了口语化的说法，检索自然不准，必要时可以对用户问题做个简单的改写，把“这个东西”改成具体的名词再去做检索。

4.2 答案还是不对：生成侧的三个隐形陷阱

检索没问题，答案还是不对，问题多半出在生成侧。第一个陷阱是提示词约束太弱。模型本质上是个“生成狂魔”，你不严格限制，它就忍不住自己发挥。我把案例给过很多朋友看，加一句“只准基于资料回答”，答案的准确度上一个台阶，就是这么明显。第二个陷阱是上下文塞得太多太杂，把不相关的片段也放进了提示词，模型会聪明地认为这些片段都有用，然后就拿不相干的信息来回答。这时候减小K值、提高相似度阈值，把上下文收窄。第三个陷阱容易忽略，就是你接的大模型本身能力太弱。有些小模型能力有限，就算材料给了，它也归纳不出正确信息。换个更强或者更大的模型试试，有时候问题是模型而不是流程。

4.3 系统很慢很贵：工程侧的务实优化

如果你的系统已经有人用了，性能就是下一个要面对的问题。最直接的优化是降级召回数量，别让多个不相关的片段挤进上下文，既能省模型输入的成本，也能降低回复的延迟。第二个建议是加一层缓存，相同或者近似的问题，短期内直接返回上次结果，这是性价比极高的做法。第三，离线预处理能做的都做掉，文档解析、切分、Embedding这些步骤，不用每次查询重复算，只做一次，之后复用。第四，生成模型的规模要匹配需求。如果你只是做一个内部的简单问答，用轻量模型配一个写得很好的提示词，效果不逊于大模型，成本却少一个数量级。

这里我踩过最狠的一个坑，是把两条完全不同的数据源塞进了同一个索引，结果检索时不光查自己的资料，还捞出来一堆隔壁项目的旧文档。后来给每条索引增加了业务线标签，查询时按标签过滤，世界立刻就清静了。

4.4 常见问题速查表

我整理了一张速查表，当你调RAG调到头大的时候，直接按表格自查。

这张表我建议直接截图存着。调RAG的过程，说白了就是一个不断定位“到底是哪一环最拖后腿”的过程。只要排查顺序合理，大部分问题都能在半小时内定位，而不是瞎调参数。

4.5 一些长期有效的维护习惯

最后说几个长期的事情。RAG系统不是搭好就一劳永逸的，知识库里的资料会过时，用户问的问题会越来越刁钻。我现在的习惯是，每周抽几条用户真实提问，回头看看哪些检索结果和最终回答不满意，积累成一个测试集。下次改动参数、换Embedding模型时，先拿这个测试集跑一遍，用数字看效果，而不是凭感觉。

另外，资料的上架和下架要留日志。没有日志，你根本说不清一个问题回答不对，是因为数据压根没进库，还是数据已经过期了。我吃过这个亏：找半天原因，最后发现知识库里存的是一年前的老版本制度，改了文档但没重新处理向量库。所谓“收藏版”的方法论，不只是笔记收着，而是真的能让你少走弯路。

我自己的体会是，折腾RAG这么久，最容易让人误解的地方在于期待过高。它不能让你用一个普通模型就变成专家级助手，但它能非常有效地扩展一个模型的“已知边界”，让它回答你私有领域的内容。它给你的不是无限智慧，而是一个可靠的“查证能力”。这种能力，在真实工作中已经很值钱了。