企业官网建设流程全解析

做RAG项目越久越觉得，能跑通demo只是起点，能在真实问答场景里站住脚才是分水岭。第一次搭RAG都会觉得特别省事——装个LangChain，扔几个PDF进去，聊天窗口敲一句"帮我总结这份合同"，机器人答得头头是道。可一旦换成几十份合同、几百页技术手册、带大量编号和专业术语的内部资料，答案就开始胡编。我过去大半年接手的几个RAG知识库项目，几乎都卡在同一处：检索抓不到真正有用的段落，后面生成再强也是白搭。

这篇文章是系列第六篇，前面聊过RAG基础概念、大模型本地化部署、向量数据库选型这些底层话题。今天这篇想把RAG知识库从构建到检索的整条链路完整串一遍：文档怎么清洗、切块怎么定、向量怎么建、检索怎么召回、重排怎么用、生成侧怎么兜底，以及上线之后命中率怎么评测、都会踩哪些坑。内容偏实战，适合已经跑过一两个demo、想把手里的东西做成一个真正能用的系统的朋友。

1. 先把全链路拆开：一条RAG流水线到底由几段构成

RAG标准定义是检索增强生成，一句话就能说完。但"从文档进来，到答案出去"，实际要经过的环节比这个概念复杂得多。我习惯把整条链路拆成八段：

原始文档 → 解析清洗 → 切块 → 向量化 → 写入索引 → 用户提问 → 检索召回 → 重排 → 组装上下文 → 大模型生成。

数一下其实是十段。网上的教程通常给你画一张非常漂亮的架构图，然后把大部分篇幅放在最后两段，因为最后两段最容易出效果——点几下界面就能看到机器人回答得头头是道。但做过工程化的人都知道，前面那些环节决定了这套系统的上限。检索要是不行，后面生成能力再强，也只会把错的内容包装得更流畅。

为什么检索环节这么关键？因为它是乘法效应，不是加法效应。你召回的结果相关度如果是60%，后面重排、生成做得再完美，天花板也就是60分的答案。反过来，检索能稳定拿到90分以上的相关内容，哪怕生成侧用参数小一点的模型，出来的答案质量也不会差到哪去。这也是为什么很多项目里换了检索方案之后，整体效果提升比换一个大模型还明显。

上表里每一行展开都是足够的选题，而且每一行都能单独写一篇踩坑实录。这篇文章后面四节基本按照这个表的顺序往下走，重点放在中间六段——从切块开始，到重排结束，这是我最想强调的部分。

2. 知识库构建的前半程：切分粒度与向量质量决定检索上限

很多项目启动时最兴奋的是模型选型，最不重视的是文档预处理。我见过一个团队花两周时间对比各种大模型，然后用一段20行的脚本把PDF塞进向量库，跑完一看，检索结果惨不忍睹。解析和切块看着不起眼，但它们的问题会被整条链路放大。

2.1 文件解析：PDF、Word、扫描件各有各的坑

先聊文件解析。PDF是RAG项目里最主流的输入格式，也是最坑的格式。原因在于PDF分两种：自带文本层的PDF，和本质是图片的扫描版PDF。前者用PyMuPDF可以很快抽取文本，速度比pdfplumber快一个量级；后者必须走OCR流程，PyMuPDF抽出来是空白。

解析阶段最容易被忽略的是版面结构。常见问题有三个：第一，多栏排版，论文那种两栏布局按阅读顺序抽取时经常左右栏交错，一段话被拦腰截断；第二，页眉页脚混入正文，每页重复的页码、公司名、机密标识会污染切块内容，降低检索质量；第三，表格被抽成一行行文本，原本清晰的维度关系全丢了。

扫描件和图文混排文档则要上OCR。中文场景我试过Tesseract和PaddleOCR，后者中文识别效果明显更好，但对硬件有要求。OCR之后还要做坐标还原，否则图片里的文字跟上下文位置对不上。这里有个经验：图片中的文字，比如流程图里的说明、PPT截图里的要点，经常是整个知识库里信息密度最高的部分。只解析纯文本会丢掉一大部分有效信息，所以处理图文混排文档时，最好把图片单独抽取出来走一遍OCR，识别结果作为该页的补充文本块。

2.2 切块策略：窗口、递归、语义三种方案怎么选

解析完之后就是切块。切块的核心原则其实一句话：切块粒度必须跟你实际问答的粒度匹配。如果你的知识库是FAQ条目，每条本身就是一个完整问答对，那压根不需要切，整条塞进去就是最佳切块；如果你的知识库是几百页的操作手册，用户的问题是"停机之后怎么复位"，那答案通常落在某一两个小节里，切块就应该围绕章节边界来做。

三种主流切法我简单对照一下：

• 固定窗口切分：按固定字符数或Token数硬切，最简单，但对语义破坏最严重，经常把一个完整句子从中间切开。
• 递归字符切分：先按段落切，再按句子切，尽量保持语义完整。LangChain的RecursiveCharacterTextSplitter就是这种思路，实用中比固定窗口好很多。
• 语义切分：用Embedding模型计算相邻句子之间的语义差异，差异太大就在那里断开。效果最好，但多一层计算开销。

如果没有什么特殊理由，中文场景我建议从递归切分起步，初始参数可以设块大小300到500字，重叠50到80字。这个数值不是玄学：300字大概对应一个完整知识点在中文表达中的平均长度，太小的话上下文不完整，答案会缺前因后果；太大的话一块里面塞了多个主题，检索时相似度被稀释，命中率反而下降。

还有一个进阶做法是父子切块，也叫small-to-big。思路是同时保留两种粒度的块：小到用来匹配（比如150字），大到用来作为上下文（比如整节内容）。检索时用小块去跟问题算相似度，命中之后把对应的大块塞给大模型。这样既保证了匹配精度，又保住了上下文完整性。这个方案在真实项目里对答案完整度的提升非常明显，值得专门花点时间实现。

2.3 向量化与索引设计：Embedding选型和元数据

切完之后要向量化。这一步最关键的决策是Embedding模型选型。中文场景里，通用英文模型如OpenAI的text-embedding-3系列对中文的支持虽然不错，但很多本土模型在中文、尤其在专业术语上表现更好。目前国内项目用得比较多的有bge系列、bge-m3、以及一些针对特定行业微调的模型。选型时不要只看公开榜单分数，把你自己的知识库文档抽一批出来，拿真实问题去测，比什么都准。

向量维度也需要考虑。维度越高通常表示能力越强，但存储和查询开销越大。768维和1024维在千万级以下规模的项目里，性能差异可以接受；但如果体量更大，可能需要考虑降维或者换用维度更低的模型。距离度量方面，大多数向量库默认余弦相似度，如果你的Embedding模型明确建议用内积，那就改成内积，别偷懒。

接下来是元数据设计。很多人把向量库当成一个单纯的存储，只往里塞文本和向量，这是后续所有麻烦的根源。正确的做法是给每个块打上来源文档编号、章节路径、页码、更新时间、文档类型、权限级别等元数据。这些字段至少有三个用途：检索时按条件过滤、生成时提供引用来源、后续做权限控制。没有元数据的话，知识库一旦超过几百份文档，同名不同年的文件、不同部门的人名术语，都会互相干扰，到时候想救都难。

3. 检索回路里的三个关键环节：召回、过滤与重排

知识库构建完毕，接下来的检索回路才是RAG的灵魂。这一节是全文的重心，我会把召回、过滤、重排拆开讲。很多人以为检索就是"问句转向量，然后在向量库里找相似"，实际操作下来，这套逻辑在真实业务场景里漏洞百出。

3.1 向量检索的边界：纯语义匹配扛不住精确词

向量检索的本质是把文本映射到高维语义空间，然后找相似度最高的邻居。它擅长的是"意思相近"——你搜"怎么处理合同违约"，它能找到讲"违约条款应对"的段落。但业务知识库里大量问题恰恰是"字面精确"的：设备型号WLAN-2024-001、合同编号HT-2023-088、人名、时间、地点。

这种精确词在向量空间里经常不占优势。你把完整编号跟其他文本一起Embedding之后，编号字符对整个向量的贡献被其他语义稀释了，相似度分数会被"貌似相关"的段落压过。我见过一个真实案例：用户搜"HT-2023-088号合同的付款条款"，纯向量检索排第一的是另一份合同里讲"付款条款"的段落，而真正目标合同的段落排到十几名开外。这就是纯向量检索的经典翻车现场。

解决方案首先是元数据过滤：如果合同编号已经存在元数据字段里，可以启动检索前先把范围过滤到目标合同，向量检索只在过滤后的集合里跑。其次是混合检索，下面细说。

3.2 混合检索：BM25和向量一起上，再用RRF合并

混合检索是目前提高召回质量最稳的一招。它把两个互补的检索通路的结果合并：BM25这种词法检索负责精确匹配，向量检索负责语义匹配。

BM25是传统搜索引擎的老将，核心逻辑是看查询词在文档里的出现频率和稀有程度。它处理"WLAN-2024-001"这种编号极其稳，因为编号的字符在候选文档里要么完全一致要么完全缺失，分数差异一目了然。但它处理"怎么处理合同违约"这种语义化问题就很弱，因为字面没有重叠词。这正是向量的主场。

合并方式里比较简单的是加权求和，但权重难调，两个通道的分数尺度也不一致。更稳的是RRF，即倒数排名融合。公式很简单：对每个文档，在所有通道上计算 1/(k + rank)，k通常取60，然后把各通道得分相加。RRF只关心排名位置，不关心分数绝对值，天然规避了不同通道之间量纲不一致的问题。实测下来，BM25加向量再走RRF，比单独任一个通道的命中率能提升十几个百分点，尤其在有大量精确编号和术语混合的场景里，提升更显著。

3.3 重排：从top50到top5，这一脚踩下去效果立竿见影

召回阶段用双编码器（bi-encoder）模型，因为要在大规模向量库里快速筛出候选，必须牺牲精度换速度。但双编码器的问题在于，问题和文档是各自独立编码的，它们之间没有做深入的交互计算。所以召回结果里经常出现"语义上沾边但实际不相关"的段落。

重排阶段换用交叉编码器（cross-encoder）模型，把问题和文档拼成一个输入，一起喂给模型做精细相关度打分。这等于让模型"仔细读一下再判断"，精度高很多，但没法在大库里全量跑，只能对召回的top几十条做精排。所以标准的组合拳是：召回阶段用双编码器粗筛top50到top100，重排阶段用交叉编码器精排，取top5到top8进最终Prompt。

中文项目里bge-reranker-v2-m3是现在用得比较多的重排模型，效果不错，但注意它是Rust服务，部署不是简单的pip install，需要按官方文档起服务。如果你用的是Dify这类平台，重排模型已经内置了配置入口，会省很多事。

重排这步的收益，我用实际数据说：一个混合检索跑下来top5命中率76%的项目，加入重排后稳定到了89%。代价是多了一次模型推理，单个请求的检索耗时会增加几百毫秒到一两秒。对知识库问答来说，这点延迟通常可以接受。

4. 从普通RAG到Agentic RAG：生成侧怎么"主动查资料"

前三节讲的都是"用户给问题，系统查资料"的经典流程。但真实业务里还有一类更难的场景：用户的问题本身不完整，或者需要多次查询才能拼出答案。这就需要生成侧具备一定的"主动性"，也就是从普通RAG向Agentic RAG演进。

4.1 查询改写：把用户的话翻译成检索系统听得懂的话

最容易被低估的环节是查询改写。用户的实际提问往往非常口语化，甚至充满歧义。比如多轮对话里用户上一句问"这份合同哪年签的"，下一句问"违约金是多少"，这里的"违约金"如果没有带上"这份合同"的上下文，检索系统根本不知道在问哪份合同。逻辑就是先判断指代，把问题改写成"HT-2023-088号合同的违约金条款是什么"，再做检索。

另一个常用手段是多查询（multi-query）：用一个问题生成多个语义变体，分别检索，再合并结果。比如"如何降低服务器成本"可以扩展成"服务器成本优化方案""云资源费用控制""降本增效措施"。每个变体都能召回到不同的段落，合并去重之后用重排选出最优，覆盖面明显变大。代价是成本翻倍——一次提问做三轮检索和重排，延迟和费用都上去了，但效果通常是值得的。

4.2 路由和多跳检索：一个知识库不够用怎么办

当企业里不止一个知识库时，就需要检索路由。典型场景是用户问题来了，先做意图识别，判断该走合同库、技术手册库还是规章制度库。这里跟4.1一样，可以直接让大模型做分类路由，也可以自己在前面加一层分类模型。路由做不好，检索范围错了，后面一切白搭。

多跳检索是另一个进阶需求。"A项目的服务器用了什么型号，它的故障恢复时间是多久"这种问题，可能需要在项目档案里先找到服务器的型号，再在技术手册里查该型号的故障恢复时间。一步检索解决不了跨文档的信息串联。GraphRAG和本体RAG（ontology RAG）就是冲着这个去的，思路是把文档里的实体和关系抽出来存成图谱，检索时沿着关系边走边找。

4.3 Agentic RAG的本质：把"检几次、查什么、何时停"交给模型

Agentic RAG是最近这个方向最热的词。它的核心变化是，检索的次数、检索的目标、甚至要不要再检一次，都由大模型自己判断，而不是预设的一条固定流水线。普通RAG是线性流程：问句进来，检一次，生成答案。Agentic RAG是循环流程：模型先判断这个问题是否需要额外知识，需要的话先检一次，看完结果觉得不够就改写查询再检一次，直到它认为信息够了才生成答案。

这个能力带来的收益和风险都明显。收益是能处理多跳、模糊、对比类复杂问题；风险是延迟和成本不可控，模型可能陷入反复检索的死循环，而且查得越多，越可能把不相关的内容带进来。所以我的建议是分场景：FAQ、单文档问答、强规则的知识库，普通RAG加好的检索链路完全够用；真正涉及多文档对比、复杂逻辑推理的场景，才值得上Agentic RAG。一上来就整Agentic，大概率是给自己挖坑。

5. 实测表现与踩坑记录：命中率是怎么一步步练起来的

链路搭好只是开始，上线前的评测才是决定能不能交付的关键。很多项目"感觉回答得还行"就上线了，结果用户一用就翻车。原因很简单——感觉不可靠，评测必须量化。

5.1 一套能复现的评测方法

我的做法是，每个项目都建一个黄金测试集，从真实用户历史问题里抽50到100条，每条配上标准答案和答案来源文档。这步看着费时间，但一旦建好，后续每一轮改动都能快速验证效果，省的时间远超投入。

核心指标首推命中率，也就是检索出的top5结果里，是否包含生成答案真正依赖的那个来源块。这个指标直接反映检索链路的质量，不掺生成模型的干扰。计算方式可以这样：对每条测试问题，人工标注出标准答案所在的块ID；跑完检索后检查这ID是否在返回结果里，在就算命中。50条问题就能给出一个足够可信的百分比趋势。

另外两个常用指标是答案忠实度和答案完整度。忠实度看生成的答案有没有包含上下文之外的信息，也就是有没有幻觉；完整度看标准答案里的要点有没有被覆盖全。评测方式可以人工打分，也可以让一个更强的模型当裁判。后者有争议但效率高，适合快速迭代；最终验收建议还是要人工过一轮，尤其在涉及合同、医疗、法律这类场景。

5.2 我踩过的几个坑

挑五个最有代表性的说出来，给各位当参考。

第一个坑是固定长度切块不看语义边界。早期我图省事，按500字硬切，结果把一个完整的安全操作流程从中间劈成两块，每块都缺一半，检索永远命中不了完整步骤。后来换成递归切分加适当重叠，问题立刻缓解。

第二个坑是Embedding模型前后不一致。测试环境用了A模型，线上换成了B模型，两者的向量空间完全不一样，索引里已经写入的向量和新查询向量风格不符，检索效果直线下降。所以要么固定模型版本，要么换模型时重建全量索引，没有中间地带。

第三个坑是没做元数据过滤。多份同类文档在库里共存时，相似内容互相干扰，造成跨文档串答案。加上文档编号、时间、部门等过滤条件之后，歧义问题大幅减少。

第四个坑是上了重排但没有单独评测。之前以为重排一定有增益，结果加了之后延迟上升，命中率反而掉了几个点。原因是我用的重排模型跟我的领域数据不匹配。后来换了模型并针对测试集单独验证，收益才出来。重排不是必增项，必须用自己业务的数据实测确认。

第五个坑是知识割裂。企业里不同部门对同一事物的叫法不同——财务叫"客户"，交付部门叫"项目方"。单独每个知识库都建得很好，但合并检索时，用户用A部门的词根本召不回B部门的内容。这个问题需要在元数据层做同义词映射，或者在切块阶段就把别名写进去，等到上线之后再救就难了。

6. 工程选型建议：哪些组件自己搭，哪些直接用现成的

最后聊选型。RAG生态已经卷出了大量现成组件，但选什么取决于团队的技术栈和项目的真实约束，不是越新越好。

6.1 框架和平台怎么选

如果是Java技术栈，LangChain4j或者Spring AI值得单独研究，它们对Java系工程接入RAG方案友好很多，不必强制跨语言上Python。

我的倾向是：初创产品和快速验证阶段，直接用Dify这类平台，两三天能把知识库搭起来；一旦验证了业务价值，再考虑把关键链路抽出来用langchain或LlamaIndex重写。追求极致搜索效果的搜索型产品，从一开始就走自研路线，尤其是切块、检索、重排这几层，别指望平台能帮你调到最优。

6.2 低成本本地知识库的完整组合

最后给一个零基础可复制的本地RAG知识库组合，这条路径我实际跑通过，全部开源组件，成本几乎为零。大模型用Ollama跑一个7B或者13B量级的模型，Embedding可以用bge系列，向量库用Chroma，前端编排用Dify或者自写一个FastAPI服务。整条链路的顺序是：文档灌进Dify或者脚本切块入库，查询时先做混合检索（Chroma现在已经支持部分混合检索能力），再用一个轻量重排模型精排，最后把上下文拼给Ollama大模型生成答案。

这套组合跑小规模知识库（几百份文档、十万级向量）完全没问题，适合个人知识库、小型团队内部问答。但要上生产，有几个绕不开的硬条件：并发访问量上来之后，Ollama单机推理会卡脖子，需要换成支持并发调用的服务端推理框架；向量检索的持久化和备份要做好，Chroma项目级的稳定性还需要你自己兜底；权限控制如果有多部门隔离需求，就得在应用层做元数据过滤，不能全靠向量库本身。

我在实际项目里最深的体会是，RAG知识库构建与检索这件事，真正的竞争力不在用了多强的模型，而在每一层细节的打磨——文档解析得干不干净、切块跟不跟得上真实提问粒度、元数据有没有设计到位、混合检索的比例调没调对、重排有没有针对性验证过。把这些环节当成一个整体去优化，比单独追求某一个环节的"最强组件"有用得多。尤其是当你的测试集命中率从70%磨到90%以后，再回头看每个环节的取舍，会发现每一层都缺一不可。