企业官网建设流程全解析

授权与合规声明
本文为技术实践笔记，示例均基于公开文档与自建环境中的实验，不涉及任何未获授权的系统。文中结论仅代表个人实践小结，与所涉厂商无利益关系。转载请注明出处。

1. 为什么先修检索层，而不是换更强的模型

很多人做 RAG 的第一反应是"把底座模型换成更强的"或者"把向量库换成更贵的"。但真正卡住效果的，往往是检索这一层：模型再强，喂给它的上下文不对，答案也不会对。

一个典型的失败链路是这样的：用户问"这个接口的超时时间怎么配"，系统检索回来三段关于"接口定义"的文档，模型只能基于这三段编一个看起来合理的答案。这时候换模型没用 —— 输入就错了。

判断问题在不在检索层，有个很便宜的检验办法：把检索到的原文人工贴给模型，看它能不能答对。

• 贴原文能答对 → 问题在检索层
• 贴原文也答不对 → 问题在提示词或模型层

先用这一步把问题定位清楚，再决定改哪里。本文只讨论第一类问题。

2. 分块策略：从固定长度到语义边界

分块（chunking）是检索质量的第一道闸门。

固定长度分块最省事：按 500 字或 800 字切，带一点重叠。它的优点是实现简单、长度可控；缺点是会把一个完整的论述从中间劈开，于是"半句话"被检索命中，上下文不完整。

按结构分块更适合有明确层级的技术文档：Markdown 按标题层级切、代码按函数切、FAQ 按问答对切。它让每个块尽可能自洽。

实践中比较稳的做法是结构优先、长度兜底：先按标题或段落边界切，超过上限再按句号二次切分，块与块之间保留一小段重叠，避免边界信息丢失。

需要说清楚的一点：分块大小没有普适最优值，它取决于语料密度和查询粒度。这个问题在本文里只能给方法，不能给数字 —— 具体数值必须在自己语料上实测。

判断分块好坏的指标很直观：随机抽一批块，看单块单独给模型时，信息是否自足。如果一块读完仍然不知道它在说什么，这块就切坏了。

3. 向量检索的天花板：为什么还需要关键词检索

向量检索（embedding 相似度）擅长语义匹配：用户说"超时配置"，文档写"timeout 参数"，两者字面不同但语义接近，向量能找出来。这是它的价值。

但它在两类查询上会明显吃亏：

第一类是精确串匹配。用户找的是具体的报错码、函数名、参数名、版本号。这类查询里，字面完全一致才是最相关的，而向量会把语义相近但字面无关的内容排在前面。

第二类是低频专有名词。训练语料里没怎么出现过的内部术语、产品名、缩写，embedding 往往表示得很差，导致召回不到。

关键词检索（最常用的就是 BM25 这类概率检索模型）恰好在这两类查询上很强，因为它直接算词项权重。

所以结论不是"哪个更好"，而是两者互补：语义查询靠向量，精确查询靠关键词。这就是下面要讲的混合检索。

工程上还有一个绕不开的点：向量检索为了保证速度，通常用近似最近邻索引（例如基于多层可导航小世界图的 HNSW 结构），近似就意味着会漏。这也是混合检索能兜住一部分召回损失的原因（HNSW 由 Malkov 与 Yashunin 于 2018 年提出，见附表 A）。

4. 混合检索与重排：怎么把两路结果合成一路

两路检索各自返回一个有序列表，问题变成：怎么合成一个最终列表？

做法一：分数归一化后加权求和。把向量相似度和 BM25 分数各自归一化到同一区间，再按权重相加。问题是两路分数的分布差异很大，权重很难调稳，换一批数据就要重调。

做法二：RRF（Reciprocal Rank Fusion，倒数排名融合）。它不看分数，只看排名：每个文档的得分等于各列表中1 / (k + rank)之和。这样就不用担心两路分数不可比的问题，实现简单、鲁棒性好，是目前比较常用的融合方式（RRF 由 Cormack、Clarke、Buettcher 于 2009 年提出，见附表 A）。

融合完之后，如果对精度要求更高，还可以再加一层重排（rerank）：用一个 cross-encoder 类模型，把「查询 + 候选文档」成对输入，直接打相关性分。它比双塔向量模型精度高，但计算量也大，所以通常只对融合后的前若干条做重排，而不是对全库做。

一条比较务实的链路是：

# 示意流程，非可直接运行的脚本1. 查询改写 / 关键词抽取2. 向量检索 top-N + BM25 检索 top-N3. RRF 融合 → 取前 M 条4. cross-encoder 重排 → 取前 K 条5. 拼上下文送模型

⚠️ 上面这段是流程示意，不是可执行脚本，未在本机实测。

这套链路的参数怎么定？我把踩过的坑和一套可复用的调参顺序整理成了笔记。放在资料包里，扫码即可获取：

5. 召回评估：不评估就只能靠感觉调参

调 RAG 最常见的坏习惯是：改一个参数，拿十几个问题试一试，感觉"好像好了一点"。这样调出来的系统换个场景就崩。

评估要做三件事：

第一，造一个小而真的评估集。三十到一百条就够用，每条包含：问题、标准答案要点、应当被召回的文档块标识。最后一项是关键 —— 没有它你无法判断"是检索没找到，还是找到了但模型没用"。

第二，分开量两段指标。检索段看 Recall@K（前 K 条里是否包含应有的块）和 MRR（正确块的排名倒数的均值）；生成段再单独看答案正确性。两段混在一起看，永远定位不到瓶颈。

第三，固定评估集，只改一个变量。换分块、换 embedding、加不加 BM25、加不加 rerank —— 每次只动一个，记录指标。这样每一步改动到底值不值，一目了然。

一个容易忽略的细节：评估集要包含"精确查询"和"语义查询"两类。只用一类，你会得出"向量检索更好"或"关键词更好"这种片面结论。

6. 常见坑与排查顺序

按投入产出比排序，值得先查的是这几条：

1. 分块切断了语义单元—— 表现是"检索命中了，但上下文答不出问题"。回到第 2 章重切。
2. 只用了一种检索—— 精确查询（报错码、函数名）答不出来。加 BM25 混合。
3. 把整篇文档塞进上下文—— 无关内容稀释了有效信息，还挤占了窗口。改成"检索块 + 少量邻居块"。
4. 没有去重—— 同一份文档被多次召回，占满上下文。按文档标识或文本相似度去重。
5. 查询没做改写—— 用户的口语化问题和文档书面语差异太大。先做关键词抽取或假设性答案改写再检索。
6. 没有评估集—— 所有改动都靠感觉。这是最根本的一条。

排查顺序建议从后往前：先补评估集，再动检索链路，最后才调分块参数。没有度量就开始调参，等于在噪声里做优化。

7. 一个可以今天就开始的最小改造清单

如果现在就要动手，按这个顺序做，每一步都能单独验证：

1. 抽 30 条真实问题，标出每条"应当召回的块"，先把评估集建起来
2. 跑一次基线：只用向量检索，记录 Recall@K
3. 加一路 BM25，用 RRF 融合，再测一次
4. 对融合结果加一层重排，再测一次
5. 最后才回头调分块大小和重叠长度

这样安排的好处是：每一步的收益都被量化了，哪一步不值，可以直接砍掉。这套流程比"换个更强的模型试试"可靠得多。

调参时最容易反复的地方，是"改完不知道有没有变好"。我把评估集的标注格式和指标计算脚本整理在了一起，放在资料包里，扫码即可获取：

附表 A：本文引用事实与出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇的时候我把手上的 RAG 项目重新过了一遍，把检索层那部分单独拎出来做了对照实验，顺手也整理了几份配套的东西：

• RAG 检索层调参顺序笔记：从评估集到重排的分步顺序，以及每步该量什么
• 评估集标注模板：问题 / 应有块 / 答案要点 三列，直接照着填
• 召回指标计算脚本：Recall@K、MRR 的参考实现

资料是我自己整理的，放在下面这个码上，扫码即可获取：

资料较多，建议先看「全套 AGI 大模型学习路线」，再挑一个实战项目跟练。