企业官网建设流程全解析

1. 为什么现在所有人都在谈RAG工程化

先说结论：RAG（检索增强生成）不是某个新模型，也不是一套固定的开源框架，而是一种把“外部知识”和“大模型生成能力”组合起来的技术架构。这两年只要有做AI应用的团队，基本都绕不开这个方向。

我在各种项目里最常看到的现象是：大模型效果Demo做得很好，可一旦要接真实的业务数据、要处理几千份文档、要保证回答不胡说八道，就直接从“演示”跌到“难产”。很多团队花了两三周做出来的检索链路，召回率低、答案质量不稳定、响应速度慢，甚至在线上一跑就直接内存溢出。问题不出在模型能力上，而是整个系统没有被当成工程系统来对待。

RAG工程化，本质上是把“能跑通的代码”变成“能上线、能维护、能迭代的系统”。它要求你做对四件事：数据准备、检索策略、生成策略、评测闭环。这四件事没有一件是“装个库调个API”就完事的，每件都需要结合你的业务场景去做取舍和设计。

这也是我写这篇文章的初衷。我不会去复述某篇论文或者某个框架的官方文档，而是把我在多个项目里反复踩坑、反复调优之后沉淀下来的实操思路整理出来。内容偏方法论，但每个结论背后都有具体的工程场景和踩坑记录，希望能帮你少走几个月的弯路。

适合谁来参考？如果你正在做知识库问答、智能客服、企业搜索、文档助手这类项目，或者你已经在做RAG但效果不稳定、说不清楚瓶颈在哪，这篇文章值得你花半小时读完。

2. RAG系统的整体链路与核心设计思路

2.1 别急着选型，先把链路图画在纸上

我在接手一个新项目时，第一件事不是去挑向量数据库、不是去选Embedding模型，而是把整条链路按数据流画一遍。一个标准的RAG系统通常包括六个环节：原始文档接入、文档解析与清洗、文本切分、向量化与索引、检索与重排、生成与引用。

这六个环节看着简单，但每两个环节之间都有大量细节。文档接入要考虑不同格式、不同权限；解析清洗阶段要处理PDF里扫描图片、表格、页眉页脚；切分要平衡语义完整性和检索粒度；向量化要选模型、定参数；检索要设计召回策略、融合排序；最后生成阶段还要管理上下文长度和输出格式。

把链路画出来，最大的价值在于你能一眼看到瓶颈在哪儿。经常有团队跑来跟我说“检索效果不好”，我让他把各环节的耗时和召回结果一列，马上就会发现卡在文档解析：PDF解析出来全是一段段的乱码，向量化再牛也没用。链路图画清楚之后，排错和优化都有了方向。

2.2 为什么检索增强比单纯微调更符合现实需求

不少团队会纠结：我到底该微调大模型，还是做RAG？

我的经验是：如果你需要的是让模型掌握某种“说话风格”或“推理能力”，微调有价值。但如果你要让模型回答基于私有知识的问题——比如企业内部规章制度、某个产品的操作手册、某一批技术文档——RAG几乎总是更优的选择。

理由也很实在。第一，私有知识是动态变化的，文档今天改了，RAG系统只需要增量更新索引，而微调需要重新训练；第二，RAG可以把答案来源追溯到具体文档，这对合规场景几乎是硬性要求；第三，工程成本上RAG不需要GPU做训练，主要算力消耗在向量化和检索上，整体可控很多。

所以我一般建议团队把RAG作为默认方案，只有在模型本身能力不足（比如总是不按指定格式输出、逻辑能力太弱）时才考虑微调。RAG负责提供事实，模型负责表达和组织，两者互补，效果会比较稳。

2.3 工程化和“跑通Demo”最大的差别在哪儿

跑通Demo的时候，你往往只有几十个文档、几百个片段，检索效果差一点看不出来。但到了真实生产环境，数据量可能会到几万甚至几十万片段，用户提问的方式也千奇百怪，这时系统要同时面对三个挑战：性能、一致性、可维护性。

性能不用多说，单次检索不能超过两到三秒，否则用户感知就很明显。一致性指的是同类型问题，回答质量不能忽好忽坏，这需要检索和提示词都足够稳定。可维护性则要求你的代码、配置、评测流程都有清晰的结构，不然两周后你自己都忘了当初为什么这么调。

记住一个原则：RAG工程化的过程，就是把“玄学”变成“科学”的过程。每个环节都得有指标、有记录、有回滚方案。后面我会把每个环节的实操细节展开讲。

3. 文档接入与解析：整个系统最容易翻车的第一步

3.1 格式杂乱的文档怎么统一处理

很多团队在RAG刚起步时，总把大量精力花在向量模型和提示词上，但真实项目里最先让你头疼的一定是文档本身。我在一个模拟项目X里处理过一批混合格式的资料，有Word、PDF、扫描件、网页导出的HTML，甚至还有表格里嵌套表格的Excel。这些文档如果不做统一处理，后面的切分和向量化就是空中楼阁。

文档解析的核心目标只有一个：把各种格式的内容变成干净的纯文本，并且尽量保留结构信息。对于PDF，要区分是文本型还是扫描型，文本型用解析库直接抽取，扫描型需要先走OCR。对于Word文档，要注意列表、表格、标题样式的保留，因为后面切分时会用这些结构信息。对于网页导出的内容，需要去掉HTML标签、提取正文主体。

我在实际操作中会为每个文档类型写一个专门的解析适配器，输入是原始文件，输出是一个统一的结构化对象，里面包含标题层级、段落、表格、图片说明等信息。这样做的好处是下游切分和检索模块完全不用关心原始格式，极大降低了系统耦合度。

3.2 OCR的坑和表格处理的三个选择

遇到扫描版PDF，OCR几乎是必经之路。这里我踩过最大的坑是：OCR精度不够直接导致检索效果断崖式下跌。尤其是一些印刷质量差、带手写批注的文档，识别出来几乎没法用。

做OCR我建议用成熟的服务或开源模型，不要自己从零训练。选型时要关注两个指标：识别准确率和版面还原能力。只把文字识别出来还不够，还要能还原段落顺序、表格结构，不然切出来的文本片段语义是乱的。我一般会在OCR之后加一道人工抽检的流程，随机抽5%-10%的结果看一眼，毕竟在关键业务上出乱子比多花几分钟审校麻烦得多。

表格处理是另一个容易翻车的地方。我的经验是三个选择：如果表格行数少且每个单元格内容短，直接把表格转成Markdown或HTML格式塞进文档流；如果表格信息密度高且问答场景经常需要查某个具体单元格，建议把表格拆成多条“表格标题+行描述+单元格内容”的记录；如果表格本身就是扫描图片，只能靠带有版面分析能力的OCR工具，直接把表格结构还原出来。

3.3 清洗环节的三个必备动作

解析出来的文本不是直接用，还要做清洗。最基础的三个动作是：去页眉页脚、去重复内容、修正常见错别字或识别错误。

页眉页脚非常影响切分质量，想象一下每个文本片段里都混着“某某公司内部资料 第3页”这种文字，检索时这些噪音会严重干扰相关度计算。清洗时我会用规则加统计的方法：同一段文字在文档中反复出现且位置固定，大概率就是页眉页脚，直接删掉。

去重复也很重要，尤其是有些文档在章节末尾会附上“参考链接”“附录目录”这类内容和正文高度重复。这一环节可以用简单的文本相似度比较来做，重复度超过阈值的段落直接丢弃。

修正常见错别字这事要克制，不要在大规模清洗阶段做复杂校正，只处理因为OCR导致的稳定字符错乱。比如某个识别模型总把“0”识别成“O”，就写一条全局替换规则。大而全的NLP纠错在文档清洗阶段既消耗算力又收益有限。

4. 文本切分：粒度、重叠与语义完整性的权衡

4.1 固定长度切分为什么不够用

文本切分是RAG系统里最容易被低估的一环。很多人默认按固定字符数切，比如每段512个字符，然后相邻段重叠100个字符。这种做法实现简单，但效果经常不稳定。

问题出在语义边界上。固定长度切分会把一句话从中间拦腰截断，或者把一个完整概念拆到两个片段里。我亲眼见过一个案例：某产品的技术参数表被从中间切了，用户问“最大支持电压是多少”，明明文档里有答案，检索结果却只召回了半个表格，导致对话系统回答“未找到相关信息”。

更合理的做法是结构化切分。如果你的文档带有标题层级，就按标题划分子章节，再在每个子章节内按段落切分。如果文档没有明显结构，可以先用“语义段落”做切分——根据换行符、缩进、语意完整性把文本分成自然段落，然后对过长的段落做二次切分。

4.2 切分窗口和重叠参数怎么定

我常用的经验参数是：目标片段长度控制在300到600个中文字符之间，重叠量约为目标长度的10%到20%。这个范围基本能兼顾检索精度和上下文连贯性。片段太短，检索召回容易碎片化，模型拼不出完整答案；片段太长，单个向量表达的内容过于混杂，检索相关度被拉低。

重点说下重叠的意义。重叠窗口是为了保证被切分边界切断的语义重新出现在相邻片段中。比如一个技术方案里先描述了“传统方案不足”，紧接着下一段是“本方案优势”，如果两个段落被切得很干净，检索时可能只召回“不足”而漏掉“优势”。设置10%-20%的重叠窗口，相当于给语义边界加了一个缓冲带。

实际项目中我不会只依赖一个切分策略。我会做一个可配置的切分器，支持按字符、按段落、按标题层级三种模式，并在每个模式里暴露窗口大小、重叠大小、切分粒度参数。不同业务场景选择不同配置，这样当某个场景效果不佳时不至于推倒重来。

4.3 给每个片段打标签：元数据设计

很多团队做切分时只输出文本片段，丢掉了元数据。这是个很可惜的事情。元数据是后面做“按条件过滤检索”的基础。比如你的知识库里有产品文档、售后记录、规章制度三种类型的文档，在检索时如果能把搜索范围先限定在某个类型里，准确率会显著提升。

我一般会给每个片段至少打上：文档ID、文档标题、片段序号、一级/二级标题路径、文档类型、更新时间。这些元数据不需要多复杂，但在检索后处理阶段很有用。比如回答“这个产品的保修政策是什么”这种问题，如果候选片段里混着售后吐槽和官方政策文档，有文档类型这个字段就可以做倾向性排序。

元数据还会影响答案的引用展示。当系统需要标明“信息来源”时，直接用片段上挂的文档标题和标题路径去生成引用说明，比在片段文本里正则匹配靠谱得多。

5. 向量化与索引：为什么检索结果总是不尽如人意

5.1 嵌入模型选型的三个关键因素

嵌入模型（Embedding Model）的作用是把文本变成向量，这块选型直接影响检索效果的上限。我在选嵌入模型时主要看三个维度：领域适配度、向量维度、性价比。

领域适配度最关键。通用领域的嵌入模型对财经术语、医疗术语、编程语言类文本的理解往往不够用。我在一个法律文档项目里就遇到过，某知名开源嵌入模型把“不可抗力”和“不可抗拒力”两个向量算得非常接近，导致检索区分不了这两种完全不同场景。后来换成在法律语料上继续训练过的模型，效果立竿见影。

向量维度影响的是存储成本和检索速度。当前主流模型的向量维度从768到几千不等，维度越高表达信息越丰富，但存储和计算开销也越大。如果你的业务场景有十万级以上的片段量，维度每差一档，硬件成本和响应延迟都会有明显差异。选型时要结合自己的数据量，别只看模型效果排行。

性价比要综合看推理速度、批量处理能力和成本。在实际项目里，嵌入模型往往是调用量最大的环节，每天几百万次向量化请求很常见。这个时候一个速度快很多、效果略有差距的模型，可能比一个精度略高但速度慢的模型更适合你的线上系统。

5.2 向量数据库选型对比与避坑

向量数据库是RAG系统的核心组件之一。我用过多个主流方案，这里给一个对比结论。开源部署类的方案适合私有化部署、数据不出内网的场景，但要自己运维、处理扩容问题。全托管式的方案胜在运维省心、自带高可用，但涉及数据合规时可能需要谨慎评估。

选型时我最看重三个功能：混合检索支持、过滤能力、可扩展性。混合检索是指同时支持向量召回和关键词召回；过滤能力是指能否基于元数据做条件查询；可扩展性是指数据量增长时能否平滑扩容。

这里额外提个容易忽略的坑：向量数据库里的索引类型和参数。多数向量数据库支持HNSW或IVF索引，HNSW的候选连接数、搜索层级数直接影响召回速度和准确率。我在一个项目里用默认参数跑，响应时间当时没在意，后来数据量翻倍后检索延迟直接飙到三秒以上，调了索引参数后才恢复正常。这类参数看起来不起眼，但迟早要面对。

5.3 索引更新的几种策略

知识库的文档不是静态的，一定会持续更新。索引更新策略要提前设计好，不然后期维护会很痛苦。

第一种是全量重建，适用于数据量小、更新不频繁的场景，优点是实现简单，缺点是随着数据量增长会越来越慢。第二种是增量更新，只对新文档或修改过的文档重新解析、切分、向量化。第三种是滚动更新，定期批量处理新文档，合并到现有索引中。

我在实际项目里一般默认用增量更新，并配合一个版本号机制：每条知识片段记录文档版本，检索时如果发现同一文档有多个版本，优先用最新版。这样做的好处是既保证了数据新鲜度，又不需要每改一个文档就动一次全量索引。

6. 检索策略优化：召回、排序与结果融合

6.1 混合检索为什么比纯向量检索稳

只依赖向量检索的RAG系统，在部分场景下会表现得很脆弱。向量检索擅长捕捉语义相似，但涉及精确关键词、编号、型号、人名时经常失手。比如用户搜“型号ABC-100的说明书”，向量检索可能召回一堆泛泛而谈的资料，却不包含那个明确的型号字符串。

混合检索的思路是：向量检索查语义，关键词检索查精确匹配，然后把两路结果融合起来。具体做法不复杂：先用向量检索召回一批候选，再用BM25或全文检索召回一批候选，取并集。这样即使语义理解失手，关键词路也能兜住。

我在一个技术文档问答项目里做过对比实验，单用向量检索时，含有精确型号问题的top5准确率只有六成左右；加上关键词检索做融合后，直接提升到八到九成。如果你已经在用纯向量方案，强烈建议插一路关键词检索进来。

6.2 重排序：让最相关的内容排在前面

检索完成后，候选片段往往有几十条，但最终给大模型的上下文窗口有限，只能塞几条进去。这时候需要重排序（Rerank）来选出最合适的那几条。

重排序最朴素的实现是用“向量相似度分数”直接排序，但效果往往一般。推荐的方案是引入一个专门的重排序模型，它会把“用户问题”和“候选片段”配对打分，比单纯的向量相似度更准确，因为它完整地建模了问题和片段之间的交互关系。

我用重排序模型后，检索结果的相关性提升非常明显。代价是每次查询要额外做几十次模型推理，会增加一些响应时间。工程上有很多缓解方案：先用低成本的向量或关键词检索粗筛出前二十到五十条，再让重排序模型精排，选出前三条到五条。这样效果和性能都能兼顾。

6.3 结果融合和阈值设置

两路甚至多路检索结果融合时，分数归一化是必须做的。向量相似度的范围通常是0到1，BM25的分数却是几到几十的绝对值，不能直接相加。我在项目里常用的是加权求和或者基于排名位置做融合。排名法实现简单且稳健：给每路结果按排名赋分，第一名给满分，后续递减，然后加权重融合。

阈值设计要谨慎。很多团队喜欢给检索相似度设一个硬性阈值，低于阈值就当“没找到”。这个思路在数据量小的时候还行，数据量大时相关性分布会很分散，硬性阈值容易造成大量漏召回。我的经验是：阈值应该配合重排结果来设，而且要基于你的评测数据去调，不能拍脑袋。

7. 生成环节的上下文组织与提示词设计

7.1 不是所有检索结果都该塞给模型

检索回来的片段质量参差不齐，如果全部塞进提示词，不仅浪费上下文窗口，还会干扰模型生成。生成环节的第一步其实是“筛选”和“组织”。

筛选逻辑通常基于重排分数做取舍，但还可以加一道去重逻辑。有些文档内容重复度很高，比如同一份操作说明在多个章节里出现了不同描述，检索后可能召回好几条高度重叠的内容。去重能提升上下文的信息密度，避免模型被重复信息带了节奏。

组织顺序同样有讲究。我习惯把与用户问题相关性最高的片段放在最前面，然后按相关性递减排布。大模型的注意力机制对这个顺序比较敏感，实际测试中相关性最高的片段放在前面，回答准确率确实会更好。

7.2 提示词的三个层次

提示词设计可以拆成三个层次：系统层、组织层、输出约束层。

系统层是告诉模型“你是一个知识库问答助手，只能依据提供的参考资料回答”，这一层关键是给出清晰的边界约束。我见过太多回答翻车的例子，都是因为系统提示词没写清楚边界，模型就开始自由发挥。

组织层是定义模板，“请根据以下参考资料回答问题，如果参考资料中没有相关信息，请明确说明无法回答。”这里要用尽量明确的指令取代模糊的期望。我曾经看到不少团队写“请基于资料内容回答”，模型根本不清楚“基于”到什么程度，翻车是必然的。

输出约束层直接控制答案格式。比如要求“回答时先给结论再给依据”，或者“可以按照1、2、3列出步骤”。这一层要贴合业务需求，在很多偏客服和售前的场景中，答案格式甚至比答案内容更影响使用体验。

7.3 控制上下文长度与关键信息保护

上下文窗口虽然越来越大，但任何时候把全部文档塞进去都是不现实的。一般检索后我会控制最终送入模型的片段数量在三到五条。如果参考答案需要跨多个文档，可以使用“多轮检索”策略，第一次检索发现问题里的关键实体，再用这些实体做补充检索，把补充结果一并组织进上下文。

还有一个经验：不要把原始文档的所有元数据全部暴露给模型。模型只需要知道“这段内容来自哪个文档标题”，就足够生成带引用的回答了。把内部标签、处理时间这类信息都塞进上下文，模型可能把噪音当成依据，导致回答里出现莫名其妙的内容。

8. 评估体系：怎么证明你的RAG真的变好了

8.1 数据集怎么构建

没有评测体系，就没有优化方向。RAG项目里最让我头疼的事情就是“效果好坏全靠感觉”。解决的办法是尽早构建评测集。

评测集不需要一开始就很大，三五十条高质量问答对就可以启动，但必须覆盖三类场景：一类是标准问题，答案在单个文档片段里能直接找到；一类是跨文档推理问题，答案需要综合多个片段的信息；一类是刁钻问题，可能触发幻觉、语义混淆或检索死角。

构建评测集的方法，我推荐半自动加人工审核。先让系统基于文档自动生成候选问答对，再让业务人员逐条确认和改写。这样做比完全手工编写效率高很多，也比完全自动生成更可靠。评测集要持续扩充，每次线上出现回答质量问题时，就把该问题追加到评测集里。

8.2 核心指标：召回、准确率和答案质量

RAG系统的评测要分两层：检索层和生成层。

检索层最常用的是召回率（Recall@K）。这个指标的直观含义是“正确答案是否被召回”，我一般会看Recall@5，如果正确答案经常不在前五条候选里，说明检索链路有问题。检索准确率也很关键，如果召回的十条里有七条是无意义的，进入大模型后很容易干扰生成结果。

生成层的指标比较难自动度量，业界常用结合人工打分和自动化辅助的方式。人工评估主要看三个维度：准确率，答案是否忠实于资料；完整性，是否覆盖了用户问题的所有要点；表达质量，是否通顺自然。这些维度可以用1到5分的量表来控制。也有用另一个大模型当裁判来做初筛的做法，但要防止裁判模型自己被带偏，人工抽检还是不能省。

8.3 线上监控和回归机制

评测集最好嵌入到开发流程里，就像软件工程里的自动化测试一样。每次调整参数、换模型、改提示词，都要把评测集跑一遍，防止“修好一个bug引出三个新bug”。

线上监控是另一道防线。我一般会在线上系统里记录两类数据：一类是检索结果的统计信息，比如本次召回了多少片段、最高相关分数是多少；另一类是用户的隐式反馈，比如用户是否点了“有帮助”按钮、是否很快结束了对话。这些数据可以定期汇总成报告，用来评估“离线评测效果不错，线上体验是否对齐”。

有条件的话，可以把线上真实用户的低频问题转成新的评测用例，每两周做一次增量回归。这样评测集始终能反映真实场景的变化，你的RAG系统也会随着时间推移越调越顺。

9. 常见问题与排查技巧实录

9.1 检索结果看起来相关但答案一塌糊涂

这个问题我遇见过太多次，答案“看起来相关”说明检索基本没跑偏，问题出在“怎么用检索结果”上。先看提示词约束是否足够硬，再看片段组织是否把最相关的内容放在靠前位置，最后排查上下文里是否混入了大量低质量片段。

如果上面都没问题，大概率是片段本身就包含错误信息。这时候回到文档解析和清洗环节，看看是不是解析阶段把表格弄乱了，或者片段里混入了OCR识别错误的内容。我自己就碰到过多次，看起来每一步都对，最后发现出错点在最初的数据准备环节。

9.2 回答过于发散，喜欢“脑补”额外信息

模型在答案里加入资料之外的内容，核心原因通常是：上下文里没有包含足够直接回答用户问题的信息，模型只能自行补充。解决思路有两个方向，一是提高检索精度，通过重排把真正包含答案的片段顶到前面；二是强化提示词，明确要求“如果资料不完整，请直接说没有相关信息，不要猜测”。

有时候发散也是因为用户的问题本身就是开放性的，比如“这个产品有哪些优缺点”，资料如果只泛泛介绍了功能，模型很可能自行脑补出几条“标准优缺点”。这种场景建议设计意图识别逻辑，把用户意图映射到最可能的检索关键词，然后再进入RAG链路。

9.3 响应时间越来越慢，怎么办

系统上线初期数据量小，检索可能很快；几个月后数据量翻了十倍，什么问题都暴露出来了。这里我建议从四个方向排查。先看向量检索索引参数，是否因为数据量增长导致搜索深度不够，需要重新调参。然后看重排序环节的调用量，是否可以把粗选集限制得更小。再看Embedding服务是否成为瓶颈，是否需要升级批量处理能力。最后看缓存逻辑，常见问题是否命中缓存，如果缓存命中率很低，说明查询分布太分散，可以考虑优化问题改写来收敛查询模式。

9.4 常见问题速查表

10. 从能跑到好用：工程化落地的几条经验

写了这么多，最后分享几条大的经验心得。

第一条，不要追求一步到位的完美架构。先基于最小可行链路跑通一个端到端Demo，哪怕只放几十个文档。有了Demo之后，再逐步把解析、切分、检索、生成各个环节替换成工业化方案。这样每一步的改进都有可比较的基线，不至于越改越乱。

第二条，性能指标要从第一天就埋点。RAG链路里最容易被忽视但又最关键的是各类耗时数据：解析耗时、检索耗时、重排耗时、生成耗时。没有这些数据，线上出问题时你只能靠猜。埋点本身不复杂，但对定位问题帮助巨大。

第三条，每个人的场景都不一样，方法论是骨架，具体参数要靠自己的评测集来定。我在文中给了一些经验值，比如片段长度300到600字、重叠10%到20%、候选集20到50条，这些是通用起点，不是标准答案。拿着自己的数据和评测集去调一遍，才能得到适合你的配置。

第四条，重视提示词的版本化管理。RAG系统迭代最多的往往不是模型，而是提示词和检索参数。我见过太多团队改完提示词之后效果变差，但回滚时发现根本没存旧版本。把提示词、检索配置、切分配置都纳入版本管理，每次改动都记录原因和评测结果，半年后回头看，你会感谢这个习惯。

我自己的体会是，RAG工程化没有什么灵丹妙药，就是把每个环节做扎实、把评测闭环建立起来、把线上数据反馈机制跑通。这个方向还在快速迭代，今天的最佳实践半年后可能就过时了，但底层的工程思维永远不会过时。希望这篇文章能帮你建立属于自己的RAG方法论，在真实项目和业务中少踩一些坑。