企业官网建设流程全解析

最近和几个团队聊 RAG 项目的落地情况，发现一个很有意思的现象：大家早期的困惑集中在“检索到的内容不对”，中期的困惑则变成了“怎么在无数个优化手段里选出优先级最高的那一个”。这其实意味着 RAG 的技术演进已经走到了一个分水岭——不再纠结能不能跑通，而是开始追求跑得稳、跑得聪明。

这篇中篇，我打算把 RAG 演进过程中最有代表性的几个拐点拆开讲一讲，重点放在索引端、查询端、生成端这三条主线的变化上，顺带聊聊评估体系的搭建和那些反复踩到的坑。如果你正处在“基础 RAG 已经能用，但效果总差一口气”的阶段，这篇文章应该能帮你理清思路。

1. RAG 演进路径回顾：从朴素到模块化的分水岭

1.1 朴素 RAG 的典型流程与瓶颈

先简单回顾一下朴素 RAG 的标准流程：文档切块、向量化、建索引，用户提问时把问题向量化，在向量库里做相似度检索，取回 top-k 片段，和问题一起塞给大模型生成答案。

这套流程在 demo 阶段非常友好，因为每个环节都有成熟的轮子可以装。但到了真实业务场景，问题就开始暴露了。最典型的是三个：

第一，检索精度不稳定。向量检索对语义相似度敏感，但“语义相似”和“答案所需”是两回事。用户问“这个产品的保修政策是什么”，文档里恰好有“保修期为一年”和“一年内免费维修”两段话，向量距离都不远，模型拿到的上下文可能同时包含两段，反而不知道到底该引用哪个版本。

第二，上下文窗口浪费严重。top-k 取回的片段里经常有大量冗余信息，真正相关的可能只有一两句话，其余都是噪音。大模型面对这种输入，容易被不相关信息带偏，产生幻觉或答非所问。

第三，对复杂问题的支持能力弱。一个复合问题涉及多个知识点时，朴素 RAG 只能做一次检索，取回的片段很难完整覆盖所有维度。比如“去年的营收增长率和今年的毛利率对比如何”，需要至少从两份不同报告中取数，单轮检索根本抓不全。

1.2 中期演进的底层驱动力

朴素 RAG 的瓶颈，本质上是“检索”和“生成”两个环节缺乏协同。演进的方向也因此变得清晰：把原本单一的处理流程拆成可独立优化、可灵活组合的模块，让检索不再是“一次性动作”，而是“可编排的策略”。

这个阶段有个明显的特征，就是工程化思维开始介入。早期的 RAG 项目很多是算法工程师在推着走，重心放在模型选择和向量库选型上。到了中期，系统性问题占据了主导——数据质量参差、索引结构不合理、查询意图复杂多变——这些问题的解法往往不在模型本身，而是在数据处理流程和系统架构设计上。

我见过不少团队在这个阶段把 RAG 项目从“实验脚本”重构成了“完整的数据流水线”。这个转变并不轰轰烈烈，但对效果的影响是决定性的。后面要讲的索引端、查询端和生成端优化，其实都是这个转变的具体体现。

2. 索引端的关键升级：分块、向量化与混合检索

2.1 分块策略从“固定窗口”走向“结构感知”

分块是 RAG 里最容易被低估的环节。很多人一开始直接用固定字符数切块，比如 512 个字符一刀切。这种方式简单，但隐患很多：一个完整的技术方案可能被拦腰截断，关键参数和解释性文字被分到不同块里；代码块和自然语言混杂时，固定窗口常常把代码逻辑切得七零八落。

结构化感知的分块是第一个值得升级的点。操作思路是：先识别文档的固有结构，再按照结构边界切分。比如 Markdown 文档按标题层级切，PDF 按段落和表格边界切，HTML 按 DOM 节点切，代码文件按函数和类切。

这里有一个基于常见实践的做法：先做结构解析，生成带层级标签的内容树，再决定切分粒度。对技术文档，我通常会让一个块尽量覆盖一个完整的标题层级下的内容，如果内容过长，再按句边界二次切分。这个方案比固定窗口复杂一些，但对检索精度的提升非常明显。

还有个值得关注的细节是块与块之间的“上下文关联”。有些内容孤立看不知所云，但在原文档里有上下文。一种解决思路是在切分时保留父级标题作为块前缀，让向量化模型能感知到当前内容在文档中的位置。这个做法我实测下来对主题分散的文档很有效。

2.2 向量化模型选型的考量

向量化模型直接决定了检索的语义天花板。早期项目喜欢用通用领域的 embedding 模型，后来发现领域差异对效果影响巨大。只面向技术文档内容的项目，通用模型往往对术语的语义表示不够精准，导致检索结果飘。

中期演进里，向量化模型有几个值得关注的趋势：

一是领域微调。用领域内的问答对或相关文档对做 embedding 模型的二次训练，让模型对特定术语的相似度计算更敏感。这个操作的成本不低，但收益常常大于在提示词上反复调优的投入。

二是多向量表达。有的方案不再用单向量表示一个 chunk，而是为 chunk 生成多个向量，分别捕捉不同维度的语义，检索时做聚合匹配。这在多义词和概念重叠较多的领域效果更好，但存储和检索开销也会增加。

三是向量维度的取舍。大部分情况下，256 到 768 维的向量已经够用，盲目追求高维度不会带来显著提升，反而增大检索延迟和存储压力。我见过一个项目把 embedding 维度从 1024 降到 384，检索速度提升近一倍，准确率几乎没变化。

2.3 混合检索解决“语义盲区”

向量检索擅长语义匹配，但对精确字符串匹配、编号匹配、产品型号这类场景并不敏感。用户问“KF-2000 型号的固件版本是多少”，向量检索可能把“KF-2000”和“KF-200”混淆，而 keyword 匹配就能精确定位到含“KF-2000”的片段。

混合检索的思路是同时跑向量检索和关键词检索，再用融合算法合并结果。这个方案在中期演进中几乎是标配级操作。融合过程有一个常见的可行做法：把两路结果的分数做归一化后加权求和，或者直接使用一种简单的排序融合方法，避免复杂的调参。

我实际用得最多的一种融合方式是 rank-based 融合：不考虑具体分数，只考虑结果在不同检索方式中的排名，然后按排名倒数加权。它的好处是对分数分布不敏感，稳定性好。关键词检索可以用开源检索引擎实现，也可以用工程上的简单方案——先做词法过滤，把包含查询词中必须出现的片段的文档选出来，再做语义排序。

混合检索的效果提升通常非常直观，尤其是处理带有明确标识符的查询。

3. 查询端的重构：从“一次检索”到“多轮交互”

3.1 查询改写

用户原始提问往往不适合直接做向量检索。口语化表达、指代不明确、意图分散，这些问题都会拉低检索命中率。查询改写是在检索之前增加一道工序，把用户的原始问题转换成更适合检索的形式。

常见的改写类型有几种。一是补全指代，用户说“它支持并发吗”，需要把“它”还原成上文提到的具体产品名。二是分解复合问题，把“对比 A 和 B 在性能上的差异”拆成两个或多个独立查询。三是补充同义词和领域术语，用户在问“内存占用”时，文档里用的可能是“吞吐量”或“显存占用”，改写时做一次术语映射。

实践中常用的方案是让大模型做查询改写，但要注意控制延迟和成本。一个折中的方案是：先做规则判断，命中简单模式时用规则处理，复杂场景才调用模型改写。这样大部分流量不需要经过模型，成本可控。

有一个容易忽略的点：改写后的查询不一定只用于一次检索。可以把改写后的多路查询分别跑一次检索，然后把多路结果合并去重。这个过程，本质上就是把“一次检索”变成了“一个查询策略组”。

3.2 意图识别与路由

查询端另一个重要变化是检索路由。不再对所有查询走同一条检索链路，而是根据查询意图分发到不同的检索策略。

比如用户问“这个产品有没有保修”，属于事实型问题，适合走文档库检索。用户问“帮我写一段根据这份报告生成摘要的代码”，属于代码生成类问题，应该优先检索代码示例库。用户问“打开设置面板找到显示选项”，属于操作步骤问题，应该检索支持文档中的步骤类内容。

路由可以用分类模型实现，也可以用基于规则的关键词匹配。早期阶段规则就够用，规则覆盖不到的再用一个轻量模型兜底。

路由的价值在于，它让 RAG 系统从“一个模糊的通用流程”变成了“一组清晰的专门通道”。每个通道的索引结构、chunk 粒度、检索参数都可以单独调优，互不干扰。这样优化起来，思路会清晰很多。

4. 生成端的质量控制：重排序与上下文压缩

4.1 重排序器的选型与融合

检索阶段拿到的候选片段，按向量相似度或关键词分数排序，未必是答案相关度的最优排序。这里需要重排序器，对候选片段做一次更精细的相关性评估。

重排序器的做法一般是用一个更强力的模型对查询和候选片段做交叉编码，计算每个片段和问题的真实相关分数。交叉编码比双编码（把查询和片段分别编码然后算相似度）更精确，因为它能让查询和片段在模型中深度融合。但代价是速度慢，所以通常只对少数候选做重排，比如先把 top-20 重排到 top-5。

重排序器的使用有一个经验：不要过分依赖“更深的模型”。对大模型来说，关键是数据质量和蒸馏策略。有些重排序模型在通用语料上效果不错，但在特定领域效果一般，需要领域数据微调。

还有一个实操细节：重排序分数和检索分数的融合方式。常见做法是重排时直接用重排分数作为最终排序依据，不再考虑检索分数，或者把检索分数作为遮蔽特征。我遇到的情况是，前者在大部分场景下足够，偶尔出现漏召回时，就需要回到检索阶段调参，而不是纠结重排阶段。

4.2 上下文压缩

即便重排之后，候选片段里依然可能包含很多无关内容。上下文压缩的目标是：只保留和问题最相关的部分，降低生成时的噪音干扰。

一个可行的做法是：在拼接送给大模型之前，对每个候选片段做一次信息提取。可以简单用正则或启发式规则裁剪篇幅，也可以用一个小模型提取与查询相关的段落。对长文档场景，这个步骤很有意义，直接决定了生成答案能不能聚焦。

压缩还有一层含义是去重。多路检索结果合并后往往有重复片段，如果不做去重，模型会对重复信息产生过拟合式的强调。我自己一般会在压缩阶段做一遍去重，策略是：把片段做一次向量化，和已经选中的片段算相似度，超过阈值就丢弃。

5. 评估体系的建立：没有评测就没有迭代

5.1 评估指标的演进

中期阶段，很多团队会意识到“凭感觉调参”走不远。RAG 系统的优化环节太多，改一个参数就可能影响多个链路，如果没有统一的评估指标，根本没法判断改动是变好还是变坏。

RAG 评估指标大致分两块：检索质量和生成质量。检索质量常用召回率、命中率、重排序增益等指标；生成质量则看答案的相关性、忠实性，以及答案是否完整覆盖问题。忠实性指标很适合做自动化评估：把生成的答案拆成多个断言，逐一在上下文中找依据，找不到依据的断言越多说明幻觉越严重。

这个思路可以用一个独立评估链路来实现：每次跑完一条查询，把候选片段、最终答案和参考答案都记录下来，然后自动计算指标。长期积累下来，就能建立起一套回归测试集，每次改动后跑一遍回归，就知道哪里变好哪里变差。

5.2 如何构建一套实用评估集

构建评估集时，一个常见的误区是直接拿线上真实问题做评估。真实问题分布和答案标准不清晰，标注成本高，噪音大。更好的做法是：从真实日志中采样高频问题类型，人工整理成包含标准答案的评测集。

评估集规模不需要很大。一个领域如果问题类型变化不大，两三百条评测问题足够发现问题。关键是要覆盖不同类型：事实型、对比型、操作步骤型、因果型等。每条评测问题最好有明确的答案要点列表，这样生成答案时才容易做自动判定。

有一个实操心得：评估集一定要定期复核。业务变化会导致知识库内容更新，旧的标准答案可能已经失效，如果用失效的评估集做回归，结果会产生误导。我见过一个团队因为评估集没有更新，“回归通过但线上效果下降”的现象持续了很久。

5.3 线上效果监控的取舍

离线评估只能覆盖有限场景，线上真实流量才是最终检验标准。但要做一个真正可用的线上指标监控，并不容易。

一个务实的选择是：用“伪点击”和“会话成功率”作为间接指标。比如用户提问后是否很快结束会话，或者用户是否对回答中的链接有进一步点击。这个指标虽然粗糙，但能粗略反馈系统整体表现。

更精细的监控可以在关键路径上埋点：检索命中率如何，路由分发是否正确，重排之后的答案引用覆盖率如何。把这些数据接入日志系统并生成报表，比拍脑袋调参要可靠得多。

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

6.1 检索质量问题的排查顺序

遇到检索结果不对，我建议按照下面的顺序排查：

第一，先确认查询改写是否正确。很多时候问题根本不在检索，而是查询本身被改写错了，导致检索方向偏差。先看日志里的改写后查询。

第二，再看召回召回是否不够。把 top-k 从 5 放大到 20，观察相关片段是否出现在候选里。如果相关片段出现但最终没被选中，问题可能出在重排或融合；如果没有出现，问题大概率在索引阶段——要么分块不合理，要么向量化表达不准。

第三，做一次“直接链路”测试：跳过所有前处理模块，用原始问题直接检索，看返回结果和经过查询改写后的结果是否差距很大。这个对比能快速定位模块之间的责任。

排查时有一点非常重要：不要同时改多个变量。每调整一个模块，保存好基线结果，再跑一次对比。很多人因为同时改了分块策略和检索模型，出了问题都不知道该往哪个方向回退。

6.2 工程性能优化的几个方向

性能问题在中期也常出现。候选片段多、模型调用频繁，延迟很容易超标。

一个优化方向是缓存。对高频相似查询，可以在改写后计算哈希，命中缓存直接把上次的检索结果返回。业务中很多用户提问其实是高频重复的，缓存命中率往往超出预期。

另一个方向是分层检索。先做一次粗粒度检索，用便宜的向量模型，快速定位到可能在的章节或文档，再做细粒度检索。这种方式在文档数量大时能明显减少计算量。

还有一个细节是异步化。查询改写、路由判断、多路检索之间没有严格的前后依赖时，可以用并行方式同时执行，再在汇聚层做合并。这个对查询延迟的改善非常明显。

7. 实操总结与心得

写了这么多，其实想表达的核心观点就一个：RAG 的进化不是某一个模型或某一个组件的功劳，而是整个系统在检索、查询、生成三个环节持续协同优化的结果。

我始终记得一个印象很深的优化案例。某个技术文档问答场景，团队连续几周都在调提示词，效果一直不温不火。后来把注意力转向分块策略和混合检索，仅仅把固定分块改成结构感知分块，并把检索从纯向量改为向量加关键词融合，最终相关片段命中率就提升了明显的一截。提示词一个字没改，效果变化却很显著。

这说明什么呢？在 RAG 这条链路里，很多时候瓶颈不在“生成”，而在“喂给生成的东西不对”。先让检索更准、更全，再谈生成优化，顺序不能乱。

另外也想提醒大家，RAG 优化是一项持续性工作，不是一个一次性交付的项目。知识库在变、用户问题在变、模型能力也在变。建立好评估体系，把每一次改动的影响都量化出来，这套系统才能持续进化，而不是靠手感反复横跳。

有一个建议给正在做中期演进团队：每做一个改造，都把这个改造的动机、预期效果、实际效果记录成一份简短实验报告。三个月后回看，你会发现这套实验记录比很多技术文档都有价值，因为它真实记录了哪些路有效、哪些路是弯路。

最后从我个人体会出发：在 RAG 演进这条路上，最重要的不是追赶最新的模型，而是把基础的数据质量、分块策略、评估体系做扎实。地基打稳了，后面无论模型怎么换，系统的整体表现都不会差。