企业官网建设流程全解析

我见过太多公司，买完大模型API或者自己部署完开源模型之后，兴冲冲地把客服知识库、产品手册、售后政策全部丢进去，结果发现模型根本不知道自家产品有几种型号、合同审批流程是几级。原因很简单：通用大模型的知识边界停在公开语料上，企业内部业务知识它一点都没有。这个阶段最务实的解法就是RAG。企业小白程序员想入门RAG这条链路，我个人认为第一步不是读论文，而是先把架构和组件在脑子里拼起来，再亲手把一份文档从入库到回答完整跑通。这篇指南就是围绕这件事写的，适合刚接手RAG项目、或者准备给内部知识库做智能问答改造的后端与全栈开发者，希望能帮你少走几个月的弯路。

1. 为什么"把文档喂给模型"这个想法行不通，RAG才是企业的现实解

1.1 大模型本质上是个"知识停在训练期"的通才

很多刚接触大模型开发的同学，第一反应是"能否把公司文档直接当上下文丢给模型，让它回答"。这个思路在十几页的小文档上勉强能用，一旦换成企业知识库就立刻崩盘。原因有三层：

第一，大模型的参数里存储的是预训练阶段学到的统计规律，训练数据有截止日期，之后的内部资料、新增政策、最新产品参数一概不知道。第二，模型上下文窗口再大也有上限，几百页的说明书不可能完整塞进去，强行塞入既浪费token，又会让模型"淹没"在无关信息里。第三，企业内部文档往往存在权限隔离、版本变更、敏感信息等约束，直接喂给模型等于放弃了所有控制手段。

我习惯用一个比喻：通用大模型像一个能力很强的实习生，表达流畅、逻辑在线，但你对公司业务一无所知。你要让他干活，就得在每句话旁边放上对应的参考资料，让他"翻着资料回答"，而不是凭印象胡编。RAG干的就是这件事：在模型回答问题之前，先从一个外部知识库里把相关材料检索出来，拼到提示词里，让模型基于这些材料作答。

1.2 先分清RAG和微调的边界，别把两个问题混在一起

企业里聊AI落地，必吵的一个话题是"到底做RAG还是微调"。这两件事解决的是完全不同的两类问题，很多项目拖沓是因为一开始就没分清。

我的经验是：RAG负责让模型"知道"企业里的具体事实，微调负责让模型"学会"某种固定的表达方式或行为习惯。比如你是要让模型用特定格式输出周报、模仿某个客服的话术风格、学会调用内部工具，那这是微调的活。如果你只是想让模型能准确回答"XX产品的保修期是几年"，RAG是绝对的主流选择，因为保修政策三个月就可能改一次，用微调去跟进这种变更，成本完全失控。

1.3 也要泼一盆冷水：RAG不是所有知识需求的标准答案

不夸张地说，我见过好几个团队把简单问题复杂化，最后做成一个又慢又贵的RAG系统，但其实用普通数据库查询就能解决。判断要不要上RAG，可以先问三个问题：

• 你的知识是否以非结构化文档为主（PDF、Word、网页、聊天记录）？
• 用户的提问是否没有固定句式，需要去理解语义再找答案？
• 答案是否需要引用具体出处，或者需要频繁更新？

如果三个回答都是"是"，RAG是合理选择。如果只是"查一下库存表里某个字段"，或者"按条件过滤订单列表"，直接写SQL、做传统搜索都比RAG更简单可靠。RAG解决的是"语义模糊、来源分散、需要自然语言作答"的场景，不是所有信息获取问题的万能药。

2. 最小可用RAG的完整链路：一条"知识流水线"从头走到尾

2.1 离线索引阶段：入库不再是"传个文件"这么简单

RAG工程里，最容易被低估的是离线索引阶段。很多人以为把文档传上去、按个按钮就算入库，实际上从原始文件到可检索的知识块，中间至少要经过六步：

文档采集：把散落在共享盘、企业内部系统、旧邮件里的文档汇总到一个标准目录或对象存储里。这一步要考虑文件格式多样性、命名规则、去重逻辑。

格式解析：PDF要区分文本层和扫描件，Word要提取正文并去掉页眉页脚，Excel要按表格结构转成可检索的文本，PPT要把每页的标题和正文分离。解析层做不好，后面所有环节都是在垃圾上盖楼。

内容清洗：删掉水印、批注、超链接、重复段落，识别并转换乱码字符。比如某制造企业的设备手册里，大量表格在解析后变成一串数字堆在一起，如果不做表格结构重建，检索阶段根本没法用。

分块（Chunking）：把长文档切成逻辑完整、长度可控的片段。这是索引质量的核心变量，后面会专门展开。

向量化：用Embedding模型把每个文本块变成向量。需要注意模型的上下文限制、向量维度、是否归一化。

写入向量库：把向量和对应的原始文本、元数据（来源、章节、更新时间、权限标签）一起存进向量数据库。检索时系统不仅要找向量相似，还要能按元数据过滤。

这六步合起来就是"知识索引流水线"。很多企业一开始图省事，用现成框架里的默认解析器一把梭，结果检索召回率惨不忍睹，最后还得回头重做，代价远大于一开始就认真设计。

2.2 在线问答阶段：从用户提问到生成答案的四步接力

索引建好之后，每次用户提问，系统要完成一条"在线链路"：

1. 接收用户问题，做必要的改写或意图识别。比如用户问"保修期多久"，系统可能把它改写为"XX产品型号的保修政策与期限"，以提高检索命中率。
2. 把问题用同一个Embedding模型转成查询向量。
3. 在向量库里做相似度检索，通常用HNSW索引加速，同时叠加关键词检索（BM25）补充精确匹配，因为向量检索对专有名词、型号编号的匹配经常不如关键词。
4. 把召回结果送入重排模型，把最相关的若干条精排到前面，然后组装成提示词交给大模型生成答案，最后把引用来源标注在回答后面。

在线链路看起来不长，但每一步都有参数可调，也都藏着坑。最典型的问题是"检索结果很相关，但生成答案还是胡编"，这种情况几乎可以断定是提示词组装环节出了问题，模型没有被告知"必须忠于上下文"。

2.3 一个典型的企业内部部署形态

为了让小白有个整体印象，我画一个最常见的内部部署形态（不需要上K8s，单机起步也够）：

对外入口一般是域名加Nginx或内部API网关，请求先到业务服务层，业务服务负责调用链路的编排，之后分别请求Embedding服务、向量数据库和大模型服务。大模型服务可以接外部API，也可以内部化部署开源模型。整体就是"业务服务串联、各个组件解耦"的形态。

3. 组件逐个说清楚：选型逻辑、参数配置和我踩过的坑

3.1 文档解析是整个RAG里最容易被低估的一环

如果让我只强调一个容易翻车的地方，我首选文档解析。很多RAG项目Demo跑得通、一上真实业务就露馅，八成问题出在索引阶段的文档处理上。

先说PDF。PDF有两类：带文本层的数字版PDF，可以直接提取文字；扫描件或图片型PDF，必须走OCR。OCR引擎的中文识别准确率、表格结构还原能力差别很大，我建议对扫描件单独建一个处理流程，不要和文本型PDF混在一起。再有就是双栏排版的技术文档，解析器如果按从左到右的顺序读，会把左右两栏的内容交错在一起。针对这种文档，要么在解析阶段做版面分析，要么按栏切分后再拼接，否则后面分块检索会天天出错。

Word和Excel同样不能掉以轻心。Word文档里的批注、修订记录、页眉页脚、文本框，解析时如果不过滤掉，会被当作正文写入知识库，用户问一句正经问题，召回出来的却是批注里的闲聊。Excel表格转成纯文本之后，列名和数值很容易错位，我常用的做法是把表格转成Markdown格式，保留表头结构，这样语义关系清晰很多。

注意：解析层的质量没法靠调大模型参数弥补。源头错了，全链路都是错的。建议在正式建索引前，用一个包含PDF、Word、扫描件、表格的"样本文档集"跑一遍解析输出，人工过目检查三五个案例。

3.2 分块策略：等宽分块、重叠窗口与语义分块的取舍

分块是RAG里另一个决定成败的"小参数"。块太小，单个片段缺乏上下文语义，检索找不到关键信息；块太大，片段里塞太多无关内容，向量相似度被稀释，还可能超出Embedding模型的长度限制。

等宽分块是按固定token数量切分，实现最简单。一般取256或512个token，块之间设置10%到20%的重叠，避免关键句子恰好被切在边界上。这个策略适合结构不明显的非结构化文本，比如聊天记录、会议纪要。

语义分块则尽量按章节、段落、话题的完整性来切。比如一份设备操作手册，按"标题层级+自然段"切，每个段落单独成块，长段落超过阈值时再切开。语义分块召回的准确率通常明显好于等宽分块，因为它保持了"一个块讲一件事"的原则。代价是依赖解析器的标题识别质量，遇到排版混乱的文档会失效。

我踩过的坑是：一份技术合同，被解析器按1000个字符等宽切块，结果一个完整的"违约责任条款"被切成三块，用户问"违约金比例是多少"，检索回来的三块各带了半句话，重排模型怎么排都对不齐信息。后来改成按条款章节切块，这个问题直接消失。分块策略没有银弹，建议先用语义分块做基线，对效果不佳的文档再叠加等宽分块和重叠窗口对比测试。

3.3 Embedding模型选择：中文场景不能照搬开源排行榜

Embedding模型负责任务是把文本变成稠密向量，向量之间的余弦相似度代表语义相关性。选型最核心的是语言适配性：英文为主的场景可以选text-embedding-3这类闭源接口模型；中文业务场景更推荐本地化的开源模型。

国内开发者上手比较顺的是bge系列模型。它的优势在于原生中文训练充分，对中文专有名词、行业术语的语义把握比直接用英文模型好很多。我做过一次对比，同一批中文售后问题，用某个以英文为主的Embedding模型检索，召回命中率大概在六成，换成本地化中文模型后能到八成以上，差距非常明显。

除了模型选型，还有几个细节容易被忽略：

• 维度与成本：向量维度越高，存储和查询成本越高，但维度太低又表达不了复杂语义。bge-m3这类模型的默认维度在千维级别，量级大时要算好磁盘和内存。
• 检索和入库必须用同一个模型：如果索引用的是模型A，线上查询却换成了模型B，向量空间不一致，检索结果基本报废。
• 归一化：很多向量库计算余弦相似度，而某些模型输出向量不是归一化的，如果检索时没有做归一化处理，相似度数值会诡异。建议在Embedding服务层统一做向量归一化，省得各个下游环节各搞一套。

3.4 向量索引与向量数据库：HNSW参数和选型矩阵

向量数据库是RAG的"记忆中枢"，选型上要结合文档量级和团队运维能力，避免一上来就上一套重组件。

先看索引算法。HNSW是当前最流行的近似最近邻算法，核心有三个参数：

• M：每个节点的最大连接数。M越大，召回越准、内存越高，建议从16起步，数据量大再往上调。
• efConstruction：建索引时的动态列表长度，越大索引质量越好但建索引越慢，一般取100到200。
• efSearch：查询时的动态列表长度，越大召回越准但查询越慢，一般取64到128，作为在线检索的调参重点。

再看向量库选型。我的建议比较务实：

我见过不少团队用Chroma跑通Demo后就直接上生产，并发一高就出各种稳定性问题。如果一开始就知道要上线，建议最迟在MVP阶段就评估pgvector或Milvus。反过来也有一个反面案例：某团队几千条文档就上了完整Milvus集群，运维成本比业务价值还高，属于明显的过度设计。RAG项目里，"够用就好"比"一步到位"更实际。

3.5 重排模块：召回几十条不如精排五条

向量检索召回的是"候选"而不是"答案"。如果只做向量检索就组装Prompt，经常会出现前几条结果里有两条不相关的文档，把模型的注意力带偏。所以我强烈建议在RAG链路上加一层重排（Rerank）。

向量检索和重排的分工是：向量模型是"粗筛"，计算快但语义理解浅；重排模型是"精排"，通常用交叉编码器结构，把查询和候选文档一起输入模型，计算细粒度的相关性分数。交叉编码器精度高但速度慢，所以先靠向量检索召回20到50条候选，再用重排模型挑出最相关的5条，这是工程上特别经典的做法。

实际项目里，重排是性价比很高的"提分项"。我记得有一次调完重排，端到端答案准确率直接涨了十来个点，改动量却只是加了两次模型调用。需要注意的是重排模型的输入长度有限制，候选文档不能过长，超长就要截断。重排一般放在权限过滤之后，别让重排模型看到权限之外的文档，容易浪费算力还有数据安全风险。

3.6 提示词组装：RAG效果一半由Prompt决定

检索做得再好，提示词组装不对也白搭。RAG提示词要交代清楚四件事：身份与任务、上下文材料、回答约束、引用要求。下面是我常用的一个模板，可以直接抄：

你是一名企业内部知识问答助手。请严格基于以下参考资料回答问题。 参考资料： [1] 来源：XX产品操作手册，第3章第2节 内容：设备的日常保养周期为每500小时或每季度一次，以先到者为准。 [2] 来源：XX售后政策V2.3，第1章 内容：整机保修期为24个月，核心部件保修期为36个月。 要求： 1. 只使用所提供的参考资料回答，不得编造参考资料之外的信息。 2. 如果参考资料不足以回答用户问题，请明确回答"根据现有资料无法确认"。 3. 回答内容标注引用编号，例如"保修期以购机发票日期起算[1]"。 4. 问题：XXX

这里有两个最重要的约束：一是**"不得编造"，必须写进提示词里，不是可选项；二是"无法回答时必须承认不知道"**，这是控制幻觉最有效的手段。temperature参数建议设置在0.2以下，RAG场景不需要发挥创造力，需要的是确定性。

4. 企业落地绕不开的三堵墙：权限隔离、知识时效和"承认不知道"

4.1 权限隔离：检索阶段就要过滤，不能只指望模型懂规矩

个人开发者的RAG可以只关心效果，企业落地则必须考虑权限。知识库里既有公开的产品手册，也有仅限特定部门查看的合同模板、薪酬政策、内部审计报告。如果权限控制只靠提示词里写一句"请忽略无权访问的内容"，模型根本分不清哪些是它有权限的，等于没控制。

正确的做法是在索引阶段给每个文档打上元数据标签，检索阶段用元数据过滤直接不召回来。常见的标签有部门、文档密级、文档类型、可见角色等。

{ "doc_id": "CONTRACT-2024-001", "department": "法务部", "security_level": "internal", "visible_roles": ["legal_admin", "hr_admin"] }

检索时在向量库里加上过滤条件，只返回当前用户角色可见的文档。这个方案也依赖向量数据库的性能：如果Filter条件不能走索引，高并发下查询会明显变慢，选型阶段就要确认向量库的过滤能力。

提示：权限过滤务必放在向量检索阶段，不要放在生成阶段，更不要放在前端展示阶段。前端只能控制"显示不显示"，控制不了模型是否已经看到了不该看的内容。

4.2 知识时效与文档撤销：知识库不是建完就一劳永逸

企业知识是动态的。产品V2.0上市之后，V1.0的说明书如果还留在知识库里，用户问"XX功能怎么用"，检索系统可能把新旧版本混在一起召回，答案自然错乱。

处理知识时效，我建议在元数据里加版本号和生效时间，检索时加过滤条件，只取当前生效版本。每次文档更新时，不要让新旧文档共存，而是把旧版本标记为失效，再写入新版本。失效文档可以从索引里删除，也可以保留但在过滤条件里排除。除了单篇更新，还要有定期的全量重建任务。索引跑久了，文档删除、权限列表变化都会让数据变得不一致，每周或每月做一次全量重建能兜底。

4.3 多轮对话与拒答机制：企业场景里"不知道"比"胡编"重要

多轮对话是RAG落地的常见难点。用户先问"XX型号的参数是什么"，紧接着问"那它的保修呢"，如果系统没有办法把"它"指代回前文的型号，检索就会失去上下文。工程上最简单的方案是把最近两到三轮历史问答拼进查询，做一次查询改写，让"保修"变成"XX型号的保修政策"，再去做检索。开源框架一般都有现成实现，小项目没必要自己写。

同时一定要设计拒答机制。把"根据现有资料无法确认"这种话术写进提示词还不够，还要在代码层面做兜底：如果检索结果的最高相关度分数都低于阈值，就不要让模型硬答，直接返回"抱歉，我在知识库里没有找到相关答案，请尝试换个说法，或咨询相关业务部门"。这个"低分拒答"逻辑能拦掉一大半幻觉，是企业对外客服场景的保命符。我参与过的项目里，最尴尬的失败案例就是模型面对一个测试者的刁钻提问，编造了一条不存在的售后条款，后来测试组的信任度跌到了冰点。

5. 上线之前，先把评测体系搭起来：没有评测集就调参等于盲调

5.1 先从真实业务里整理一批"标准问题集"

很多RAG项目死在同一个怪圈：调参全靠"感觉"，改完分块或换个模型，用三个问题点一下，觉得变好了就继续，结果上线后用真实流量一测，效果稀碎。要打破这个怪圈，一定要先建评测集。

评测集一般从真实用户提问里抽样整理，规模不需要很大，50到200条就够起步。每条评测包含三个字段：标准问题、期望答案要点、支撑文档ID。这三个字段缺一不可：标准答案用来评估生成内容是否准确，支撑文档用来评估检索的召回命中率。重点覆盖业务里最关心的几类问题：直接事实问、跨文档综合问、否定问（知识库里没有的东西）、多轮对话问。

5.2 分环节评测：索引好不好、检索准不准、生成是否忠实

RAG链路是多段接力，只看最终答案无法定位瓶颈。我的做法是分环节记录指标：

• 召回命中率：对评测集里每道题，看支撑文档有没有被召回Top20，这是最早应该看的指标。召回都命中不了，后面重排和生成根本没得救。
• 重排命中率：看支撑文档在重排后是否进入Top5。如果向量召回命中但重排后丢掉了，优先排查重排模型和候选截断逻辑。
• 答案准确率：最终答案是否覆盖了期望答案要点，有没有把关键信息说错。
• 幻觉率：答案里是否出现了支撑文档之外的信息，这是最严重的问题，出现一条都要追查。

评测的方式可以人工打分，也可以用更强的模型做自动评判。实际项目里我建议"自动评测+人工抽审"结合：自动评测跑全量，人工抽审只查分低的和有争议的，节约时间又比较可信。

5.3 端到端指标：时延和成本同样致命，别只盯着准确率

如果你以为RAG上线只考核答案准不准，那就太年轻了。企业内部动辄几百上千人同时使用，端到端时延和单次问答成本，往往是决定项目能不能持续跑下去的隐藏变量。

时延优化有几个常用手段：把Embedding模型和大模型都做预热、向量库连接池调大、对热门问题做缓存、重排TopN控制在5以内。成本优化则是控制召回数量、适当裁剪送入大模型的上下文长度、对长文档提前做摘要。记住一个原则：在准确率达标的前提下，时延和成本是RAG上生产之前必须压测的指标。

6. 给小白的一版可执行路线图：四周搭出能演示的MVP

6.1 第一周：用二十篇文档跑通闭环，先别碰复杂架构

第一周的目标只有一个：把端到端链路跑通。选20篇典型的业务文档（务必包含PDF、Word、表格），部署Embedding模型和向量库，用开源RAG框架或者自己写几个API串起来，能回答几个预设问题就算成功。这个阶段不要纠结分块重叠多少、HNSW的M参数怎么调，先感受链路本身。

建议的起步配置是：Embedding用bge-m3这样的中文模型，向量库用Chroma方便调试，模型用内部已有API就行。还需要准备一台8核16G内存的开发机，单机部署完全够用，等到并发上来了再考虑拆分服务。

6.2 第二周：把解析、分块、重排和提示词各调一轮

第二周开始做质量优化。先检查解析层：打开你索引里的几个典型文本块，看有没有大量乱码、表格错位、页眉混入。再调分块：写一个简单的对比脚本，对同一批文档分别按固定512字分块和按章节语义分块，跑一遍评测集看召回命中率差异。然后加重排：接入一个重排模型，观察准确率变化。最后调提示词：把"不得编造""标注引用""无法回答就承认"这些约束写进去，再试几个真实提问。

每次调参都要记录实验结果，不要凭印象决定去留。我的经验是，这一周的优化顺序不要颠倒：解析和分块的影响最大，重排次之，提示词微调排最后。

6.3 第三周：权限过滤、知识更新和部署形态

如果MVP要给别人演示，第三周必须做权限和运维能力。给知识库加上部门、密级等元数据标签，检索阶段加上权限过滤。实现一个简单的文档增量更新接口——上传新文档自动走解析、分块、写库流程，旧版本自动标记失效。然后把服务做成标准部署形态：Nginx反向代理、服务以Docker方式运行、日志集中输出。这些工作不性感，但缺了它们，MVP永远只能是"自己电脑上的一个脚本"。

6.4 第四周：评测验证、成本估算和上线前收紧

第四周拿真实业务数据建评测集，完成第一轮正式评测。跑完看三个数：召回命中率、答案准确率、端到端时延。如果召回命中率不到八成，回头优化分块和解析；如果答案准确率不够，优先改提示词和重排；如果时延超了，加缓存、调向量库连接数。

成本估算也放在这个阶段，按单次问答消耗tokens和服务器资源反推。我见过一个粗略算法：假设每天500次问答，每次平均消耗3000个tokens，一个月下来token费用很有限，真正的大头是GPU服务器和维护的人力成本。把这笔账算给业务方看，项目推进会顺利很多。

最后再分享一点个人体会。我带过几个RAG项目，最大的感受是：决定项目成败的往往不是大模型本身，而是文档解析质量、分块策略和评测体系这三件"不性感"的工作。大家最喜欢调来调去的temperature，反而对整个系统的影响小得可怜。如果你读到这里准备动手，我的建议是别囤资料，先拿十篇公司里最典型的文档，把这套链路跑通再说。跑通之后你自然会知道下一步该优化哪里。