企业官网建设流程全解析

前阵子我在内部评审一个企业知识库问答项目的方案，业务方提的需求特别朴素：“把公司制度文档、产品手册都交给大模型，让它像内部顾问一样回答问题。”需求听起来不难，但真到方案评审阶段就暴露了各种坑：有人打算把所有文档塞进一个超大上下文再让模型硬答，先不说成本，文档一多模型就抓不住重点；有人做了检索，但文档切出来的碎片东一句西一句，模型答得前后矛盾；还有人压根没考虑权限，员工问一个问题，系统能把隔壁部门的保密材料一起捞出来。

这类场景，就是典型的RAG应用场景。RAG（Retrieval-Augmented Generation，检索增强生成）这几年已经成了大模型产品落地里最常见的方案：先从一个外部知识库中检索出与用户问题最相关的几段资料，再把资料和问题一起交给生成模型，让模型基于资料作答。一句话说清楚就是：让大模型不再靠记忆“裸答”，而是学会“查着资料答”。

对AI产品经理来说，千万别被“检索增强生成”这个名字劝退。它本质上就是一条产品流水线，你可以不写代码，但最好把七个核心概念逐一搞明白：Embedding（向量化）、向量数据库、分块（Chunking）、检索（Retrieval）、增强（Augmentation）、上下文窗口（Context Window）、评估与质量指标。这篇文章按一条真实落地链路来拆这七个概念，每个概念都配上生活化类比和产品视角的要点，尽量让刚入门的产品同学也能跟得上。

1. RAG 到底在解决什么问题？为什么AI产品经理一定要弄懂

1.1 没有RAG时，大模型在“裸答”

你直接问一个大模型：“我们公司的年假制度是什么？”如果模型没在你的私有数据上训练过，它只能把训练时见过的、可能是别的公司的制度“脑补”出来。这跟你想要的完全不是一回事。

大模型的底层能力来自海量公开数据的训练，训练数据有截止时间，也不知道你业务里的私有文档。答案一旦超出它的认知边界，它就倾向于“一本正经地编造”，这就是大家常说的幻觉。注意，这里说的“裸答”不是说模型完全不能答，而是说它没有依据地答。业务文档里明明写了“年假按工龄分三档”，但模型没见过这份文档，它就会按照自己的记忆给你编一个通用答案。这个通用答案放哪儿都是对的，但在你们公司就是错的。

RAG的思路其实特别朴素：考试的时候遇到不会的题目，学霸不是闭卷硬编，而是把参考书翻开放在旁边，找到解法再动笔。RAG让模型在真正生成回答之前，先做一次“翻书”——从你们公司的文档库里检索出相关段落，放进上下文，再基于这些段落产出答案。这样一来，模型不再依靠记忆，而变成一个“会查资料的分析师”：知道答案来自哪份文档、哪个章节，不知道也可以直说不知道。这种表现对产品来说才是可控的。

1.2 从产品视角看懂RAG的基本链路

RAG系统可以拆成两段：一段是离线准备，一段是在线问答。

离线准备阶段，你要把所有业务资料收集好，做格式清洗。比如PDF里的扫描页、乱码、页眉页脚、公司盖章水印，都可能干扰后续处理。清洗完之后，长文档会被切成分块，每个分块转换成Embedding向量，连同原文片段和元数据一起存进向量数据库。这是“建知识库”的环节。

到在线问答阶段：用户输入一个问题，系统先把问题转成同一个向量空间里的向量，然后到向量数据库里做相似度搜索，捞出最相关的TopK个片段，再组装成提示词，调用大模型生成答案，最后把答案和引用来源一起展示给用户。产品经理必须理解这条完整链路，因为排查问题的时候不能只盯“模型对不对”——大多数情况是数据、分块、检索、提示词拼接出了问题。学会了按环节拆解，定位问题才有抓手。

这里还要多说一句：RAG和模型微调（Fine-tuning）并不是二选一。大多数知识型问答场景，RAG是更优先的选择，因为它不重新训练模型，文档更新只需改知识库，成本低、可溯源、容易回滚。微调适合要让模型改变语气、学会某种输出格式的场景，但它不擅长“记住”随时变化的具体知识。理解这个区别，产品评审时就不容易被人带偏。

2. 七个核心概念详解：从Embedding到评估，一条链路讲透

这一章是核心，我按业务里出现的先后顺序来逐个拆：Embedding → 向量数据库 → 分块 → 检索 → 增强 → 上下文窗口 → 评估。每个概念都讲清楚两件事：它到底是什么，以及你做产品时需要关注什么。

2.1 第一个概念：Embedding（嵌入/向量化）——把文字变成坐标

Embedding翻译成“嵌入”总让人一头雾水，其实它就是一个“文字转坐标”的过程。模型会把一段文本，比如一句话或一个段落，转换成一串数字，这串数字通常有几百到几千维，用来表示这段文字的语义。两个表达不同但意思接近的句子，转换出来的向量在高维空间里距离会很近；两个风马牛不相及的句子，向量距离就会很远。

举个生活类比：假设你给每个人打标签，包括专业、性格、所在城市、从事行业，这些标签全部拼在一起，就等于把每个人映射到了多维空间里的一个点。如果两个人的标签很接近，他们在空间里就是“邻居”。向量检索的核心，就是靠这种“邻居关系”来发现相关内容。

产品经理要关注的至少有四点。第一，Embedding模型不要自己造，直接用成熟模型，但不同模型对语义的理解能力差异很大，换一个模型，检索效果可能彻底变样，所以要在项目初期确定好基线再迭代。第二，在线场景里，用户每次提问都要把问题实时转成向量，这部分有成本和延迟，要提前做好预算。第三，很多业务文档有行业黑话、英文缩写、中英文混排，向量模型可能理解不好，需要在数据准备阶段做术语归一化的预处理。第四，同一份文档在不同Embedding模型下的质量，不能凭感觉判断，要用检索命中率来量化。

2.2 第二个概念：向量数据库——存坐标、找邻居、带过滤器的仓库

向量数据库是专门存向量、并且支持“找相似向量”的存储系统。你生成了那么多Embedding向量，总不能每次把全量文档都扫描一遍，所以向量数据库会通过建立索引结构，在几十万甚至上千万级别的向量里快速找到目标向量附近的一小撮邻居。这个操作通常叫ANN近似最近邻搜索，你不需要写算法，但要理解它的核心价值：快、近似、可扩展。

向量数据库里保存的不只是向量本身，通常还有原文片段、来源文档ID、页码、标题、权限标签等元数据。这里有一个对产品经理特别重要的点：元数据过滤。比如企业知识库里有研发文档、销售资料、人力资源制度，同一个库里混着好几类内容，你必须根据提问人的部门和权限设置过滤条件，只让他检索到允许用户访问的范围。如果不加过滤，检索层可能捞出不该出现的内容，那就不是模型幻觉的问题，而是信息泄露的产品事故。

选型时产品经理也不需要纠结某个索引算法叫什么，你需要关注的是：数据库能否支持高并发、检索延迟是多少、是否方便做权限过滤、运维成本高不高。把这些变成可量化的指标，比如“延迟小于300毫秒”“支持按部门字段过滤”，评审时才有依据。

2.3 第三个概念：分块（Chunking）——切文档的方式决定了答案上限

分块就是把长文档切成一段一段的小片段。为什么一定要切？因为大模型上下文窗口有限，也因为你要做的是精准检索而不是全文搬运。只有先把文档切好，检索时候才能只捞相关片段，把上下文里的噪声控制住。

分块策略有好几种，没有绝对正确的，只有适不适合你的文档类型。固定长度切块最简单，按字符数或token数切成固定大小，相邻块之间留一点重叠，防止一句话被拦腰切断导致语义残缺。自然段落切块适合结构规整的文档，比如制度文件、产品说明书，按段落或标题切，语义完整性最好。更高级的做法是语义切块，计算句子之间的相似度，语义发生明显变化的地方就是切分点，适合内容比较松散的网页或聊天记录。

产品经理一定要理解：分块跟检索效果是强相关的。块太小，单个片段里信息太少，模型看不到前因后果；块太大，每个片段里塞满无关信息，检索命中后会带进一堆噪声。我见过很多问题就出在“一刀切”上，把一份整章文档直接切成固定长度的碎片，最后模型总说资料里没有答案，实际上答案活生生就在文档里，只是被切散了。

有个实用技巧：在切块时给每个块附加文档标题、章节号、页码作为元数据。这样检索结果可以自动生成引用信息，前端直接展示“回答来自哪个文档的哪个章节”，用户信任感会强很多。你可以在项目里让技术同学对同一批文档跑几组不同切块参数的对比测试，看答案质量变化，这是最直观的调参方法。

2.4 第四个概念：检索（Retrieval）——从候选池里精确捞出最相关的内容

检索是RAG里“翻书”的那个动作，它决定了模型最后能看到的资料是什么。最常见的做法是向量检索：把用户问题转成向量，在向量数据库里用相似度距离计算，找出距离最近的TopK个片段。但单一向量检索不是万能的，比如用户输入精确的编号、型号，向量模型可能把它们当成无意义的符号，导致精确匹配失败；这时候如果配合关键词搜索，就能很快定位到含特定编号的那段内容。

所以很多生产系统会采用混合检索：同时跑向量检索和关键词检索，再把两路结果合并。合并的方式五花八门，有的取交集，有的加权求和，有的用规则过滤。召回之后还有一个关键动作叫重排（Rerank）：先用便宜的算法快速捞几十个候选，再用更精准的排序模型把相关度最高的3到5个片段排到最前面，最终送进提示词。重排虽然增加一次调用，但答案质量往往提升非常明显，值得付出这个延迟。

产品端要理解两个指标：召回率（Recall）和精度（Precision）。召回率高，代表该捞的内容被捞出来了，但可能同时带进来一大堆无关片段；精度高，代表捞出来的都是对的，但又可能漏掉部分相关内容。光调一个TopK很难同时满足两者。所以产品同学评审方案时，要问清楚：默认TopK是多少、有没有重排、混合检索怎么合并结果。这些参数直接决定了用户看到的最终回答质量。

多轮对话场景里还要注意一个问题：如果用户先问“年假有几天”，再追问“那婚假呢”，系统如果只拿“婚假呢”去检索，会什么都查不到。生产系统一般会做查询改写（Query Rewrite），把多轮对话的上下文合并成完整问题再去检索。这个产品细节很容易被忽略，但体验影响巨大。

2.5 第五个概念：增强（Augmentation）——把资料“组装”进提示词

“增强”两个字有点抽象，其实它就是提示词装配。RAG和普通文件上传功能的区别就在于：它不是简单把整份文档塞给模型，而是先检索、再组装。系统会把检索到的片段处理成约定格式，然后和用户问题一起放进大模型调用。

实际工程里，增强环节至少包含三段：第一段是系统提示词，定义角色和边界，比如“你是一个知识库助手，只依据参考资料回答，不要编造”。第二段是参考文档，把检索到的片段按顺序放进去，标注编号或来源。第三段是用户问题。最关键的指令是“资料里没有就直说不知道”，这一句能明显降低幻觉。还可以要求模型在引用处标注来源编号，这样前端界面就能展示“回答来自哪份文档”，让结果可溯源、可信。

产品经理在这个环节有非常大的发挥空间。你比技术更懂用户怎么问问题，所以提示词里的边界条件、回答风格、是否允许多轮追问，都值得你提出明确的产品要求。同样是知识库问答，给内部员工用，回答要简洁、直接给操作步骤；给C端用户用，语气反而要温和、有耐心。增强环节就是决定“模型的嘴怎么张”的地方，这个环节打磨到位，回答的可控性会显著提高。

2.6 第六个概念：上下文窗口——装得下只是起点，装得好才是关键

上下文窗口指大模型一次能处理文本的最大长度，通常用token来计算。一个中文汉字对应多少token跟模型有关，大约在0.6到2之间浮动。产品经理不用背这些细节，但要建立两个基本认知：一是窗口会限制你能放多少资料，二是窗口越大不代表模型越聪明。

为什么说“能装不等于能用好”？模型在非常长的上下文里容易出现注意力稀释，它可能漏看中间被折叠的内容，也可能被占大篇幅但相关度不高的内容带偏。所以RAG不是把所有命中的片段一股脑全堆进去，而是精选少量高相关片段放进窗口。宁可少而精，不要多而杂。

产品侧还要考虑成本和延迟。上下文里内容越长，模型处理的token就越多，费用和响应时间都会上涨。如果用户问题本身很长、参考文档也长，加起来超过窗口上限，就得设计摘要、筛选或截断策略。交互上，也要限制用户一次提交的内容长度，避免把窗口撑爆。我记得有个项目，用户习惯把一整段需求说明直接粘贴进去，结果每次调用都超时，后来在输入框限制长度、增加“自动提炼要点”功能才解决。

2.7 第七个概念：评估与质量指标——没有体检表，就无法谈优化

最后一个概念我认为是七项里最重要的。RAG是一个多环节流水线，每个环节都会有质量波动，不建立评估体系，就谈不上优化。业务方反问一句“这个回答怎么保证是对的”，你不能只拍胸脯说“大模型能力很强”。你需要一套评估集和指标，用数据说话。

评估分两个层面。结果层看最终回答：答案是否准确、是否忠实参考了资料、是否完整、引用是否真实存在。过程层看中间环节：检索召回率、重排命中率、端到端延迟。产品经理要做的第一件事，是和业务方一起整理一套真实问题集，我建议至少100到300条，覆盖高频问题、疑难问题、边界问题，并写好参考答案或评分标准。然后让评测人员按统一打分规则去评，把平均分、每类问题的得分都记录下来。

有了评估集，后面所有优化都变得可比较。技术说“把分块大小调大了一倍”，你就跑同一批测试看分数是升是降；技术说“换了一个Embedding模型”，也跑同批测试对比。更规范的做法是再加一个线上AB测试分组，用真实流量观察用户点击“有用/无用”的比率。评估不是上线的收尾动作，而是RAG产品能持续变好的发动机。

3. 产品经理推进RAG项目时，最该盯住的四个落地观察点

从七个概念抽离出来，回到真实项目里，产品经理应该怎么推动RAG落地？我总结成四个观察点。

3.1 先判断：这个场景真的需要RAG吗

不要遇到什么都想起RAG。我一般在需求沟通时会先问三个问题：用户的问题是否高度依赖某些私有或更新的信息？期望的回答是不是需要带来源依据？资料量是否大且经常更新？如果三个答案都是肯定的，RAG很合适。如果用户就是闲聊、创意写作、头脑风暴，或者回答完全不需要引用外部资料，那直接用普通大模型反而更轻快。

还有一种常见误区：把RAG当万能搜索。RAG不是搜索引擎的替代品。如果用户想精确找一个文件名或编号，传统数据库和检索系统更快、更便宜；RAG适合的是“我要一个综合性的答案，而不是一个链接列表”。这两种产品体验差距很大，要在需求阶段就想清楚，不然做出来用户会说“怎么检索结果变差了”。

RAG和微调的选择也要提前聊清。如果主要诉求是知识更新，答案必须常换常新、来源可追溯，选RAG。如果主要诉求是把回答风格固定下来、让模型学会特定的输出结构，微调更合适。没有哪套方案是万能的，但RAG因为低成本和快速迭代，通常是知识型产品的第一选择。

3.2 需求评审时，先问清这十个技术参数

产品经理不一定懂每个算法，但一定要会问对问题。下面这张速查表是我在评审RAG方案时常用的，可以直接照着问，非常实用：

针对这个表格，第一列的每一项，我都建议你在方案评审时拿到具体答案。如果对方回答“这个我们还没定，后面再说”，那你就要警觉了，因为这十个问题背后，每一步都可能成为影响上线效果的隐藏风险。

3.3 数据准备与权限控制，是产品的地基

我对RAG项目最大的感受是：模型能发挥多少，取决于数据准备做得多到位。数据治理是RAG产品最不性感但最要命的部分。

第一做数据清洗。把PDF里的扫描版、乱码、水印、页眉页脚清掉，不然分块和向量化都会受干扰。表格处理更麻烦，很多制度文档的核心信息都在表格里，直接把表格转成纯文本，语义就丢了，需要专门设计表格抽取规则。

第二做结构规范化。统一标题层级，把文档里的有效信息抽取出来，哪些章节该保留、哪些该丢弃，都要有规则。这一步做得好，后面分块的质量就会明显提升。

第三做敏感信息处理。文档里如果有手机号、身份证号、内部薪资信息，入知识库前必须做脱敏或设置访问权限。隐私合规从来不是技术问题，而是产品问题，你必须在产品设计阶段就把“谁能看到什么”定义清楚。

权限控制要特别强调，因为RAG一旦上线，所有能被检索到的文档都可能被生成进回答里，等于被间接传播出去了。所以知识库的权限体系和检索过滤必须严格一致。某个角色能问什么、不能问什么，这些要在向量数据库的元数据上做约束，不能只指望模型自己判断该不该回答。我见过一个反面案例：某公司知识库把所有离职员工的反馈文档都算开放权限，结果被员工问出了其他部门的内部意见，场面非常尴尬。

3.4 迭代节奏，要安排上“知识保鲜”

RAG项目上线不是终点，而是一套需要持续运维的系统。文档更新后，索引要不要重新生成？是从增量开始还是全量重建？平均需要多久？

如果知识库长期不更新，用户会发现模型回答的内容跟公司现行制度对不上，信任感会快速崩塌。我建议产品经理在规划阶段就把“知识保鲜”当作一项必做的功能，而不是可有可无的维护任务。至少要做到：有新文档发布时自动触发订阅更新，旧版本能被标记废弃，删除时能同步清理向量索引。

这类机制虽然不起眼，但用户感知非常直接。你见过一个智能客服推荐了已经作废的报销流程，用户还是会觉得系统“蠢”；而一旦出现一次，前面一百次正确回答都会被覆盖。知识库的新鲜度优先级，往往比模型调优更高。

4. RAG落地最常见的5个坑与排查速查表

4.1 典型症状、可能原因与应对

这些症状来自真实项目，几乎每个做RAG的团队都会至少踩中一个。排查时要有耐心，因为RAG的因果链很长，表面现象和真实原因之间往往隔着两三层。比如模型总说不知道，也许问题不在模型，而是在检索过滤条件把正确文档挡在了门外。

4.2 排查RAG问题的“三板斧”实操法

第一板斧：单测检索。直接在测试环境里把用户问题输入检索接口，把召回的TopK片段拉出来，自己肉眼看一遍。如果召回的片段就是不对，问题在分块、向量化或过滤条件，而不是模型。这一步能快速切分责任，别跟技术人员在“模型不行”上没完没了争论。

第二板斧：对比实验。把同样的100道评测题，在不同参数组合下各跑一遍，比如不同的分块大小、TopK数量、有无重排，对比评测分数。有了对比数据，之前谁也说服不了谁的问题就能用事实解决。参数调优不是拍脑袋，而是控制变量做实验。

第三板斧：反馈闭环。在真实产品里设置“回答有用/回答无用”的反馈入口，把低分案例定期拉出来，重新加入评估集、记录原因，再指导下一轮迭代。很多RAG产品上线即巅峰，就是因为没有反馈入口，模型永远停在第一版水平，后面只能靠碰运气。这是一个低频但长期见效的优化动作。

4.3 特别提醒：别把“幻觉”全部甩给模型

我最常听到的一句话是：“这模型又在幻觉了。”可真到生产环境里，超过一半的“幻觉”根本不是模型的问题，而是检索环节的问题：知识库里压根没有这条资料，模型只能靠常识硬答；或者文档切错块，把上一段的内容带进下一段，模型误把别的主题当成原文；又或者检索回来的片段本身就不相关，模型受害于输入噪声，把错误答案“合理化”。

所以排查顺序永远是：先看数据，再看检索，最后再看模型和提示词。数据缺失就补数据，检索不对就调检索，别一上来就换大模型。遵循这个顺序，能省下大量时间，也避免团队在错误方向上反复内耗。

5. 我的实操体会：先建评估集，再谈一切优化

最后聊点我自己的经验，也算给产品经理同行一点建议。

我最初接RAG项目时也走过弯路，一上来就让技术同学去调模型、调参数，结果效果忽好忽坏，业务方完全失去信心。后来花了两周时间，跟业务团队一起整理了一套评估问题集，覆盖了日常客服收到的高频问题、用户故意挖坑的问题、多文档答案冲突的问题，又制定了比较简单的一到五分评分标准。从那以后，每次版本改动都跑同一套测试，团队内部的说服和决策效率都上来了。

我个人建议从今天开始，就把评估思维带到RAG项目里。不要迷信“换个更强的模型就能解决一切”，大概率你缺的不是模型，是一套更好的检索策略、更扎实的知识库，以及更完整的数据治理。RAG做得好不好，拼的其实不是模型强弱，而是工程化的细节：文档切得对不对、检索捞得准不准、权限控得严不严、评估做得稳不稳。

希望这七个概念能帮你从“看到RAG就头疼”变成“我能一个环节一个环节拆解问题”。下次再跟算法同学开会说需求，你问的问题都能问到点子上的时候，你会发现自己已经站在同一个讨论平面上了。