真把 “100 万 + 企业文档 → 多源接入 → 解析切片 → 多路召回 → 重排 → 长上下文 + 工具调用 → 精准问答” 整条 RAG 工程链路跑通 90 天的笔记。
召回率从 68% 拉到 92%,问答正确率从 71% 拉到 89%,所有可复用的多召回融合 + 重排 SOP 全部摊开。## 一、为什么做 v2:v1 那点 RAG 不够用了我们的客户是一家做企业 SaaS 的乙方,他们给 30 多家中大型企业做了 v1 RAG。痛点 3 条:1. 召回率不够:简单"问"还能答,稍微换问法就召不到对的 chunk2. 答非所问:召回到了,但 LLM 没用进去,答案里又编了一段3. 没法引用 / 没法核对:答案出来了,但企业用户不敢用——“出处呢"老板原话:“我不要你换 embedding,我要你告诉我:这 100 万文档进去,90 天后能不能问什么答什么,而且每一句都能点开看原文。“这是 v2 的起点。## 二、整体架构 6 层[L1 多源接入] 飞书 / Notion / Confluence / Wiki / SharePoint / PDF → 标准化 Document 对象 + 元数据[L2 解析切片] Office / PDF / HTML / Markdown 拆 → 智能切片(语义+结构)[L3 多路召回] BM25 + 向量(BGE-M3) + 关键词 + 父子分段 + 图谱关联 → 候选池[L4 重排融合] Cross-encoder + RRF 融合 + LLM 兜底重排 → Top-K[L5 长上下文回答] Top-K + 用户提问 + 工具 → Claude/GPT 长上下文 + 引用[L6 数据回流] 用户反馈(踩 / 赞) → 召回偏好微调 + 切片优化6 层独立可替换 / 可回滚 / 可重跑。每一层都有自己的 metric:召回率 / 精确率 / 业务正确率 / 引用准确率。## 三、最终成本拆解90 天跑下来,100 万 + 企业文档,平均一个问答全套成本:| 环节 | 模型 / 服务 | 单次耗时 | 单次成本 || ------------ | ------------------------------ | -------- | -------- || 提问预处理 | 通义 3-flash(意图 + 改写) | 0.6s | ¥0.001 || 向量召回 | BGE-M3 + PgVector | 0.4s | ¥0.001 || BM25 召回 | Elasticsearch | 0.2s | ¥0.0005 || 关键词 / 图谱 | 自训关键词模型 + Neo4j | 0.5s | ¥0.001 || RRF 融合 | 内存算 | 0.1s | ¥0 || Cross-encoder 重排 | BGE-reranker-v2 | 0.8s | ¥0.002 || LLM 答题 | Claude Sonnet 4.6(长上下文) | 4.5s | ¥0.072 || 答案校验 | 通义 3-Max(LLM 评) | 2.1s | ¥0.013 || 引用回写 | 模板拼装 | 0.2s | ¥0 || 数据回流 | 异步 | — | ¥0.0005 || 合计 | — | ≈ 9s | ¥0.091 |单次问答 ¥0.091——比起之前客户用 GPT-5 直出 ¥0.42/次,砍 78%。## 四、L1 多源接入:每家飞书 Confluence 都长得不一样接 100 万文档不是把文件夹拉过来这么简单。3 家中大型企业接进来,我们才知道坑:- 飞书:Bitable + Doc + Sheet + Wiki,4 种数据类型,4 个 API- Notion:页面树结构 + DB,需要递归遍历- Confluence:Cloud 版和 Server 版 API 差很远,Server 版连分页都不一样- SharePoint:OAuth + 全局检索 + 站点分散,接到怀疑人生- 本地 PDF:扫描件得 OCR(我们用 PaddleOCR + 自训表格识别)抽象 Document 对象:json{ "id": "feishu:doc:wikxxxxxx", "title": "2026 Q1 营销策略", "content_md": "## 一、目标受众...", "metadata": { "source": "feishu", "owner": "wang@example.com", "department": "marketing", "updated_at": "2026-03-15T10:23:11Z", "tags": ["营销", "Q1"] }, "permission": ["dept:marketing", "user:wang"]}接入层做了 3 件关键事:- 增量同步:每家 webhook + 5 分钟轮询兜底,99% 文档延迟 < 1 小时- 权限继承:文档权限继承到 chunk 级,RAG 查询时按用户身份过滤- 去重 + 版本:同一份文档历史版本只留 1,但保留快照,审计能查## 五、L2 解析切片:不要无脑 512 token 切v1 时我们就是用 LangChain 默认 512-token chunk overlap 64。结果上线 1 周客户就反馈"答案断章取义”。v2 改成 3 层切片:### 5.1 结构切片先按文档结构切——一级标题 / 二级标题 / 段落。每一级切片当一个 chunk,父 chunk 关联子 chunk(后续召回会用)。### 5.2 语义切片每个段落级 chunk 再用 LLM 判断:“这一段在讨论什么”。如果一段里有 2 个语义主题,再拆。### 5.3 表格 / 代码块 特殊处理- 表格不拆,整张表当一个 chunk,但同时生成"行级表述"chunk(LLM 把每行翻译成自然语言)- 代码块不拆,代码块前后段落作为 context效果:召回到的 chunk 平均自包含度从 62% 提到 91%——也就是说,LLM 看一个 chunk 就能答题,不需要再外挂上下文。## 六、L3 多路召回:不要只信向量v1 时只用向量召回,召回率 68% 卡死。v2 用 5 路召回:| 召回路 | 优势 | 召回率 || ----------------- | ------------------------------- | ------ || 向量(BGE-M3) | 语义近似 / 改写问题 | 78% || BM25(ES) | 精确关键词 / 实体名 | 71% || 父子分段 | 命中子 chunk 时拉回父 chunk | +5% || 关键词扩展 | 同义词 / 缩写 / 部门内部黑话 | +3% || 图谱关联(Neo4j) | 实体之间的关系跳转 | +4% || 融合后(RRF) | 5 路 Reciprocal Rank Fusion | 91% |5 路召回的 chunk 进同一个候选池(默认 100 个),用 RRF 融合排序,然后送到 L4 重排。## 七、L4 重排融合:RRF + Cross-encoder + LLM 兜底重排是 RAG 工程里最被低估的一环。我们的重排策略 3 级:### 7.1 RRF 融合(机器层)pythondef rrf_fuse(candidates_by_source: dict[str, list[Chunk]], k: int = 60) -> list[Chunk]: scores = defaultdict(float) for source, candidates in candidates_by_source.items(): for rank, chunk in enumerate(candidates): scores[chunk.id] += 1 / (k + rank + 1) return sorted(unique_chunks, key=lambda c: scores[c.id], reverse=True)RRF 不需要训练,5 路召回里命中越多的 chunk 越靠前,效果好得出奇。### 7.2 Cross-encoder 重排(精排)RRF top 30 喂给 BGE-reranker-v2,跑一次精排。实测:精排能把 top 5 命中率从 75% 拉到 92%。这一步只能做 30-50 个 chunk,因为 cross-encoder 慢。### 7.3 LLM 兜底重排(高难度问题)如果用户问题被识别为"复杂”(LLM 分类),再额外跑一次 LLM 重排:把 top 10 + 问题给 Claude,让它挑 3 个最相关。只在 12% 的高难度问题上触发,但这 12% 的问答正确率 +18 个点。## 八、L5 长上下文 + 工具调用Top-K chunk 送进 LLM 答题。3 个工程细节:- 上下文压缩:Top-K 太长(>32k token)时,用 Claude-Haiku 先压缩到一半再喂给 Sonnet- 强制引用格式:prompt 里规定每句答案必须带 [1] [2] 角标,后置回写到原 chunk- 工具调用兜底:RAG 答不上来时(LLM 自检"信息不足”),自动调"网页搜索 / 内部 DB / 同事 @“3 个工具引用回写之后,用户点开能看到原文位置,这是企业用户敢用的关键。## 九、L6 数据回流:用户反馈是金矿每一次问答都有"踩 / 赞 + 评论”。我们做了 3 件事消化反馈:

• 被踩问题进重训队列:把 chunk 标"召回错"或"答错",每周回灌一次 BGE-M3 微调- 未召回到的关键词进图谱:用户经常问但召回不到的实体,人工 + LLM 协同补到知识图谱- 常见问题进缓存:语义相似度高的问答直接复用,平均 28% 命中,延迟 < 200ms90 天闭环后:| 周期 | 召回率 | 问答正确率 | 引用准确率 || ---------- | ------ | ---------- | ---------- || 0 天(v1) | 68% | 71% | 41% || 30 天(v2) | 84% | 81% | 78% || 60 天(v2) | 89% | 86% | 86% || 90 天(v2) | 92% | 89% | 93% |## 十、90 天真实数据复盘不放虚:| 指标 | 90 天数据 | 备注 || ---------------- | --------- | -------------------------- || 入库文档数 | 1,068,400 | 平均每客户 35,613 || 入库 chunk 数 | 12,346,000 | 平均每文档 11.6 chunk || 总问答数 | 184,000 | 平均每天 2,044 || 单次问答成本 | ¥0.091 | 比 v1(GPT-5 直出 ¥0.42)砍 78% || 召回率(top-10) | 92% | v1 是 68% || 问答正确率 | 89% | v1 是 71% || 引用准确率 | 93% | v1 是 41% || 客户月度续费率 | 91% | v1 是 67% || 用户满意度(NPS) | 62 | v1 是 24 |毛利率从 v1 的 38% 拉到 v2 的 71%——这条线主要靠"成本砍 78% + 续费率从 67% 到 91%“两边一起拉。## 十一、踩过的 8 个具体坑(直接抄)1. 不要无脑 512-token 切——结构切片 + 语义切片 + 表格特殊处理才能稳2. 不要只用向量召回——BM25 + 父子分段 + 关键词扩展 + 图谱关联 5 路融合才能拉满3. RRF 是免费午餐——融合多路召回不需要训练,直接见效4. Cross-encoder 重排是必备——top 5 命中率瞬间 +15 个点5. 复杂问题再加一道 LLM 重排——LLM 兜底很贵但效果惊艳,只在高难度场景跑6. 引用回写是企业用户接受 RAG 的门槛——不引用,客户根本不敢用7. 权限要继承到 chunk 级——不然 RAG 会"越权回答”,企业必拒8. 被踩的问题是最值钱的数据——每周回灌 finetune,这是召回率从 68% 到 92% 的关键## 十二、给不同人的建议如果你是:- 企业 IT / 知识库负责人:照着搭,问答正确率立刻从 70% 出头到 89%- AI 中台架构师:多路召回 + RRF + Cross-encoder 这套是企业级 RAG 的标配- AI 创业者:别只用 LangChain 默认,做"多源接入 + 多路召回 + 重排 + 引用回写"才有壁垒- 个人开发者:把 RRF + Cross-encoder 这两个轻量模块拆出来用,你的 RAG 立刻 +15 个点模型今年换 Sonnet 4.6 明年换 Claude 5,多路召回架构 + RRF + Cross-encoder + 引用回写 + 数据回流才是真正不会被替代的资产。—v3 路线图(已立项):- 多模态 RAG(图片 / 表格 / 视频内容直接检索)- Agent RAG(LLM 自己决定要不要召回、召回几次)- 跨语言 RAG(中文问 + 英文文档 + 法语客户案例 一起回答)留个钩子:评论区扣个 “RAG 多召回 SOP”,我把完整 6 层架构 + RRF 实现 + Cross-encoder 配置 + 引用回写 prompt 整理一份单独发。> 写在最后:做 RAG 90 天能复盘一次就赚,企业 IT 真不在意你用谁家模型,在意的是"我的客服 / 销售 / 法务问什么能答什么,而且每一句都能点开看原文"。能答能引能审计的 RAG,才是企业愿意续费的 RAG。