企业官网建设流程全解析

最近好几个朋友问我，说大模型聊天倒是会用，但一涉及自己的文档、内部资料就抓瞎，问什么都是"我不知道"，要不就是一本正经地胡说八道。还有人跟风做了知识库，结果效果稀碎，检索半天答非所问。说到底，大部分人缺的不是算力也不是模型，而是没搞懂 RAG（检索增强生成）知识库到底是怎么一层一层搭起来的。

这篇我就把 RAG 知识库的三层架构掰开揉碎讲一遍：数据层喂什么、索引层怎么存、检索生成层怎么答。不堆概念，直接讲每一层干什么、为什么这么设计、落地时踩过哪些坑。不管你是刚入门的小白，还是准备在生产环境里搞知识库的程序员，这套思路都适用。

1. 先搞明白 RAG 到底在解决什么问题

1.1 大模型的两个致命短板

大模型再聪明，本质上是个"记忆力有限的话痨"。它训练时见过的东西能答个大概，但有两类问题天生处理不了：第一，你私有的文档、最新的内部制度、还没上网的测试报告，它根本没见过，自然答不上来；第二，模型的参数是训练时定死的，知识有截止日期，时事热点、新版本功能这些动态信息，它张口就来也大概率是编的。

这就是圈里常说的"幻觉"问题。你问模型一个它不知道答案的问题，它不会老实说"不知道"，而是会用非常自信的语气编一段看似合理的回答。放到知识库场景里，这几乎等于事故——客服答错业务规则、HR 答错休假制度、研发答错接口规范，每一条都是在给公司挖坑。

1.2 RAG 的思路：给大模型开卷考试

RAG 的核心思路其实特别朴素：与其让模型闭卷硬答，不如改成开卷。你先从自己的知识库文档里把和问题最相关的内容检索出来，拼到提示词里，再让模型基于这段材料作答。模型本来就擅长"给定材料写作文"，现在材料喂到嘴边，它答对的概率自然大幅提升。

这个设计有两个明显好处：一是知识来源可追溯，模型答的每句话都能对应到具体的文档片段，方便复核；二是更新成本极低，公司制度改了，只需要替换知识库里的文档，完全不用重新训练模型。RAG 能把最新的、私有的知识以极低的成本"注入"大模型，这也是它能在企业应用里遍地开花的原因。

1.3 为什么非要强调"三层架构"

很多教程一上来就教你调代码，跑通一个 Demo 很容易，但一旦换数据集、换场景就全线崩盘。根本原因在于：RAG 的链路太长了，从原始文档到最终回答，中间任何一个环节偷懒都会让效果打折扣。

把这条链路拆成"数据层—索引层—检索生成层"三层，本质上是在做工程上的解耦。每一层只关心自己的事情：数据层管"把乱七八糟的文档变成干净文本"，索引层管"把文本变成机器能快速查找的结构"，检索生成层管"召回相关内容并组织成答案"。这样哪个环节出问题，你就知道去哪一层排查，而不是对着一个黑盒瞎调参数。下面我就一层层拆给你看。

2. 三层架构整体拆解：从文档到答案的完整链路

2.1 数据层：所有问题的根源

数据层是整个知识库的地基，干的活也最脏最累：把 PDF、Word、Markdown、扫描件、网页这些五花八门的原始资料，统一解析成干净的纯文本，再按合适的大小切成片段（业内叫 chunk）。

很多人不重视这层，觉得不就是读文件吗？真做起来全是坑。PDF 里看起来是文字，实际可能是扫描图片，不 OCR 识别全是乱码；Word 里的表格、页眉页脚混在正文里，切分时会制造大量噪音；一个 200 页的技术手册，直接整个塞给模型，上下文窗口再大也装不下，就算装下了，模型也抓不住重点，回答必然顾此失彼。

所以数据层的目标非常明确：把"人能看的文档"转化成"机器好处理、模型好理解的标准文本单元"。这里有两个关键点，一个是格式解析的准确性，一个是切分粒度的合理性。前者决定你喂进去的是金矿还是垃圾，后者直接决定后续检索的命中精度。

2.2 索引层：给知识建一套目录和索引

有了干净文本之后，就要考虑怎么存、怎么查。这层叫索引层，干的活和图书馆管理员高度相似：把每段文本打上语义标签，建立一个"从语义到位置"的索引，让后续检索能快速找到相关段落。

这里最核心的动作是"向量化"。简单解释就是：把一个文本片段转换成一串几百维的数字（向量），这段文本的语义越相近，数字在空间里的距离就越近。比如"怎么申请年假"和"休假制度"的距离，一定比"怎么申请年假"和"服务器部署指南"近得多。这样检索就变成了一道数学题：计算问题向量和所有文档向量的距离，挑最近的。

实际系统中，索引层通常还会做双重索引：除了向量索引做语义检索，还会保留一份倒排索引做关键词匹配。原因后面细讲，你可以先记住一个结论：只靠向量索引，遇到专有名词、编号、精确版本号，效果通常不理想，结合关键词检索会更稳。

2.3 检索生成层：召回、排序、写答案

最后一层是直接面对用户的一层，也是决定"用户觉得好不好用"的一层。它的工作分三步：先从索引里召回一批候选片段，再从候选里精确挑选最相关的少数片段，最后把这些片段组装成提示词交给大模型生成答案。

这里有个常见的认知误区：召回的片段不是越多越好。有朋友一开始把 top-k 设成 20，觉得多喂点材料模型答得更全，结果模型被一堆弱相关片段干扰，反而抓不住重点，回答变得又臭又长。正确的做法是：先宽召回（比如 50 条），再精排（压缩到 3~5 条高质量片段），让模型只基于精华内容作答。

三层合在一起，就是一个完整的 RAG 流水线。你从用户视角看到的是一次提问和回答，背后其实经过了"文档解析—文本切分—向量化—双路召回—重排—提示词组装—生成"这一长串工序。把这个链路在脑子里立起来，后面每一个优化点你就知道它属于哪一层了。

3. 逐层拆解核心细节：参数怎么定、方案怎么选

3.1 数据层的切分策略：chunk 大小和重叠窗口

chunk 切分是数据层最值得花时间调的地方。切太大，一个片段里揉进多个主题，检索时会召回一堆"半相关"内容，模型分不清重点；切太小，语义被切断，比如把"王小明申请了三天年假"拦腰截成两段，检索时就再也拼不回来。我常用的经验值是：通用文档 500~800 字/块，技术文档按章节切，每块控制在 1000 字以内，同时让相邻块有 10%~15% 的重叠。

为什么需要重叠？想象一下你把一本纸质书撕成几页，如果恰好从某句话中间撕开，那这两页都不完整，谁捡到都读不通。重叠窗口就是在切分时故意让上一块结尾和下一块开头重复一些内容，保证语义的连贯性。按 Markdown 标题、章节号来切分效果更好，因为文档自身的结构本身就是天然的语义边界。

还有个细节很多人忽略：表格和列表要特殊处理。表格直接转成纯文本会变成一堆竖线和空格，模型根本读不懂。建议按行转成"字段: 值"的键值对文本，比如"员工姓名: 王小明；休假类型: 年假；天数: 3"。列表则保留缩进层级，让模型能看清从属关系。

3.2 索引层的关键决策：嵌入模型和向量数据库

嵌入模型的选择直接决定语义检索的上限。选型时主要看三点：一是语言匹配度，处理中文文档优先选中文语料训练过的模型，英文模型处理中文效果会打折扣；二是向量维度，维度越高表达能力越强，但存储和计算开销也越大，一般 768 或 1024 维是主流平衡点；三是更新频率，嵌入模型一旦换了，所有历史向量都得重新生成，所以上线前务必先定死模型版本。

向量数据库这边，市面上的选择很多，有专门的向量库（如常见的几个开源产品），也有在传统数据库上加向量插件的方案。在我看来，中小项目优先选专门做向量检索的轻量方案，部署简单、索引构建快；数据量大到千万级、需要分布式扩展时，再考虑重型的分布式向量库。如果项目里已经有关系型数据库，且场景是"少量文档 + 中等查询量"，也可以直接复用现有数据库的向量能力，少维护一套系统。

一个容易踩的坑：向量相似度度量方式要和检索需求匹配。绝大多数场景用余弦相似度就够，它只关心方向不关心长度，对文本长度差异不敏感。但如果你切换了度量方式（比如改成内积），必须同步重新生成索引，否则查出来的结果全乱套。

3.3 检索生成层的核心动作：混合检索与重排

很多入门教程只教你做"向量检索",实际生产环境里远远不够。我强烈建议上"混合检索"，也就是把向量检索和关键词检索的结果合并起来。理由很简单：语义检索擅长"意思相近但表达不同"的查询，比如"请假流程"能匹配到"休假申请步骤"；但语义检索对精确的词、编号、型号无能为力，"API-2567 这个接口报错"这种问题，关键词检索能精准命中，向量检索反而可能跑偏。

召回之后的排序环节同样重要。向量相似度分数只能说明"语义上接近"，不能直接等同于"最相关"。实践中可以加一个重排模型（reranker），把召回的 20~50 条候选逐对打分，输出一个更精准的相关性排序，然后只取前 3~5 条给大模型。加了这个环节之后，知识库的回答准确率通常会有明显提升，属于性价比很高的优化项。

3.4 提示词组装：别把材料一股脑全塞进去

最后一步是把检索到的片段组装成提示词。这里有几个经验：一是给每个片段标注来源，比如"【来源：《员工手册》第三章】"，模型引用时会自然地带上出处，方便用户核对；二是在提示词里写清楚约束，比如"只能根据给定材料回答，材料中没有的信息直接说不知道"，能显著减少模型自由发挥的概率；三是控制总长度，给生成留足空间，不要为了堆材料把上下文塞到 90% 满。

4. 实操：从零搭一个最小可用的 RAG 知识库

4.1 准备阶段：选型与材料整理

下面我带你把整个流程走一遍。假设场景是做一个公司内部制度问答助手，知识库材料是三份 PDF（员工手册、报销制度、假期管理办法）。选型我基于常见实践给一套组合：嵌入模型用开源的通用中文模型，向量存储用轻量级向量数据库，大模型用现成的 API 或本地部署的开源模型均可。这套组合的特点是：免费、上手快、效果中规中矩，适合学习和试用。

材料整理这一步，先把 PDF 转成文本。我建议先人工快速浏览一遍转换结果，重点关注三类问题：扫描件有没有 OCR、页眉页脚是不是混进来了、表格有没有乱掉。不要嫌这一步烦，这一步清干净了，后面能少踩一半的坑。

4.2 切分与向量化入库

材料清理完之后，写切分逻辑。我习惯按 Markdown 标题层级来切，先确认 PDF 转出来的文本有没有保留标题结构，没有的话可以按空行分段，再按固定窗口兜底。示例伪代码如下：

def split_document(text, max_chunk_size=600, overlap_size=80): # 先按标题/章节拆分 sections = re.split(r'(?m)^第[一二三四五六七八九十]+[章节]', text) chunks = [] for section in sections: # 对每个大块再按长度切片，带上重叠窗口 for i in range(0, len(section), max_chunk_size - overlap_size): chunks.append(section[i:i + max_chunk_size]) return chunks

每个切分出的文本片段，调用嵌入模型转成向量，连同原文、来源、章节号一起存进向量数据库。入库时我建议顺带存一份原始文本字段，不要只存向量，否则后面想展示引用来源、做结果排查时还要回源查文档，很麻烦。

4.3 双路检索实现

写检索逻辑时，同时发起两路查询：一路把用户问题向量化，在向量库里做相似度检索，取 Top 30；另一路直接用关键词（分词后）在倒排索引里匹配，取 Top 30。把两路结果合并，按"同时出现在两路里的优先"的规则加权排序，去掉重复片段，最后交给重排模型精排，取前 5 条。

这一步是最容易出现"看起来没效果"的环节。很多人合并时直接取并集按分数排序，实际跑下来发现关键词路总是被向量路的高分淹没，导致混合检索形同虚设。我常用的调法：给两路分数做归一化（min-max 缩放到 0~1），再给关键词路一个加权系数（1.2 左右），这样才能让精确匹配的结果真正冒头。

4.4 调用大模型生成回答

检索完成之后，把片段按格式拼进提示词，调用大模型生成答案。同时把命中的片段来源列表取出来，一并回传给前端展示。这样一个最小可用的知识库就通了：用户提问，系统检索，模型作答，附上引用来源。

第一版跑通之后，我建议你做一次"人工评测"，拿出 20 个典型问题，逐个看回答质量。不要只看答没答对，还要看：有没有答非所问、有没有遗漏关键信息、引用来源是否对得上。这一轮评测记录的样本，就是后续优化效果对比的基准线。

5. 常见问题与排查实录

5.1 检索召回效果差，怎么调都没用

如果你发现无论怎么优化提示词，模型回答都很烂，大概率问题不在生成层，而在检索层。第一步去查索引库里存的内容：随便拿几个 chunk 出来读，看看解析干不干净。我见过太多案例，索引里全是"第 1 页 共 20 页""欢迎下载"这类垃圾文本，那模型再怎么聪明也是巧妇难为无米之炊。

第二步看召回结果：把用户问题对应的 Top 10 召回片段打印出来，人工判断相关性。如果 Top 10 里超过一半是弱相关，说明嵌入模型和你的领域不太匹配，或者 chunk 切得太大/太小。如果召回里有明显的精确关键词但没排到前面，就去调混合检索的加权系数。

5.2 向量检索常见误区：相似度分数高不等于相关

很多初学者看到"相似度 0.92"就觉得稳了。实际上，向量相似度的绝对数值没有太大参考意义，分数分布取决于嵌入模型和数据集的整体形态。有些数据集的 Top 5 都是 0.9 以上，有些则只有 0.7。你在检索阈值过滤时，不要拍脑袋定 0.8 之类的数字，而是先跑一批真实问题，统计一下"相关结果的最低分"和"不相关结果的最高分"，再在中间取阈值。

5.3 模型还在胡说八道，幻觉没消掉

代码能跑通，检索也正常，但模型还是会编造不存在的细节。这种情况通常是提示词约束不到位。检查一下你的提示词里有没有明确写"只能根据材料回答，材料未提及的内容一律说不知道"。不要觉得这是废话，模型真的会因为少了这句话而在答案末尾自由发挥。把引用格式也在提示词里规定好，要求每句话尽量对应到给定片段，能极大减少幻觉。

另一种情况是召回片段里本身有噪音。比如切分时把两个无关段落拼在了一个 chunk 里，模型就会把 A 段的信息安到 B 段头上。这种问题去数据层查 chunk 切分逻辑，别在提示词里死磕。

5.4 响应慢、卡顿，体验差

知识库查询慢，最常见的瓶颈是检索阶段而不是生成阶段。向量检索在百万级数据量下，如果没有走索引而是暴力全表扫描，一次查询要几秒，体验自然崩。解决方法是确认向量数据库建了合适的索引（比如 HNSW 一类），并在召回时用近似最近邻搜索，牺牲一点点精度换取几十倍的召回速度。

还有一个常被忽略的点：重排模型很耗时。如果你每轮对话都要重排 50 条候选，响应时间会明显拉长。实际项目中可以把候选数压到 20 条以内，或者只在用户点击"进一步精确匹配"时触发重排，常规查询跳过重排直接取向量 Top 5，体验会顺滑很多。

一张速查表送给你，遇到问题按表排查：

6. 进阶方向与个人体会

三层架构跑通只是起步，真正提升知识库质量，我体感最明显的三个方向：第一是数据层的"清洗增强"，比如针对表格做结构化解析，针对问答对做索引优化；第二是引入重排模型，这是性价比极高的一步，通常能让准确率上一个台阶；第三是加一层"意图路由"，先判断用户问题是不是真的需要检索知识库，闲聊和小常识直接走大模型原生能力，避免检索噪音干扰。

另外想提醒一句：RAG 不是银弹。如果知识库文档本身质量极差，或者用户问题高度依赖多轮上下文，单纯靠三层架构也救不回来。这种场景需要考虑更重的方案，比如对文档做结构化知识抽取，或者引入 Agent 机制做多步推理。但无论如何，把三层架构吃透，都是你进阶这些复杂方案的前提。

我个人在实际操作中还有一个习惯：每改一个参数，就重新跑一遍那 20 个基准评测问题，答案逐条对比。这个习惯帮我避开了无数次"感觉优化了、实际变差了"的陷阱。知识库的优化没有一次性的灵丹妙药，本质上是个不断评测、定位、调整的循环。把这套方法论掌握住，不管以后换什么模型、换什么框架，你都能快速摸清一套系统的脾气。