正在加载，请稍候
面向 2026 年的 RAG 知识库搭建实战：文档解析、分块、Embedding、混合检索、评测闭环、成本预算 6 个决策，附制造企业 2 万份质检文档案例与反面教训。
一家制造业客户把 2 万份质检文档交给我们的那天，问题不是「AI 能不能答」，而是「先入库哪一步」。最终 3 周的人工整理被压到 2 天，靠的不是某个更强的模型，而是把 RAG 知识库搭建拆成 6 个可评测的工程决策。这篇把每个决策的取舍和踩过的坑写出来，给正在做企业知识库的团队参考；常见坑位的速查版，可以对照我们之前写的《企业知识库 AI 检索不到内容？RAG 落地最常见的 6 个坑与修复路径》。
每年都有人问「还要不要 RAG」，答案在 2026 年依然明确：RAG 是知识更新、成本、可解释性三者平衡点最低的方案。
微调的问题在于知识更新。一次领域微调要整理标注数据、跑 GPU 训练、做版本回归，业务手册改一版就得重来。RAG 的更新路径是「换文档、重新向量化」，半天内生效，这个差距在企业知识高频变化的场景里是决定性的。
长上下文也不是银弹。Anthropic 在 2025 年 9 月的 context engineering 研究里给过一个明确结论：token 越多，模型从上下文里精确回忆信息的能力越差，他们把这种现象称为 context rot。与其把整本手册塞进 1M 上下文，不如检索出 2K 高信号片段交给模型。
对 B 端更重要的是可解释性。RAG 的每个回答都能回溯到原文 chunk，审计、合规、争议处理都要这条引用链。微调和长上下文都给不了这个能力。更进阶的检索架构演进，可以看这篇企业知识库 AI 检索架构进化：从玩具 RAG 到 Retrieval Harness。
| 方案 | 知识更新 | 可解释性 | 成本 |
|---|---|---|---|
| RAG | 换文档即更新，半天 | 回答可回溯原文 | 低，向量化+推理 |
| 微调 | 重新训练，按周算 | 黑盒 | 高，GPU 训练+标注 |
| 长上下文直塞 | 实时 | 弱，易 context rot | 中，token 随长度暴涨 |
我们接手的 2 万份质检文档里，一半是扫描件，三分之一是带复杂表格的 PDF。第一步就决定了后面所有环节的上限。
PDF 要先确认有没有文本层。扫描件必须走 OCR，中文场景用 PP-OCR 或云 OCR 都能拿到不错的结果；表格直接按纯文本抽取会把行列关系打散，正确的做法是先转 Markdown 或 HTML，保留表头与单元格结构，否则数字对不上号。
分块粒度直接决定召回质量。我们一开始把整份合同做一个 chunk，结果一个 query 命中整篇合同，重排后碎片化严重，命中率从 78% 掉到 61%。后来改成按语义边界切 256-512 token，同一测试集的命中率回到 84%。
分块没有银弹，按内容类型选策略：
Embedding 模型决定向量空间长什么样。选型先看中文效果，再看部署成本，最后看维度。
国产和开源模型在中文场景已经不比 OpenAI 差。BGE 系列、智源、通义百炼、智谱都有一线水平的中文 Embedding；API 方案省运维，但 QPS 上来后按量付费可能比自部署贵。我们一般建议：先用 API 验证效果，命中率达标后再评估自部署。
| 方案 | 维度 | 部署 | 适用场景 |
|---|---|---|---|
| BGE / 开源中文 | 768-1024 | 可自部署，GPU 推理 | 数据敏感、QPS 高 |
| OpenAI text-embedding-3 | 1536（可降维） | API | 快速验证、英文为主 |
| 通义/智谱/百炼 API | 1024-1536 | API，国内合规 | 中文为主、不想运维 |
维度不是越高越好。1536 维比 768 维存储和检索成本高一倍，效果提升可能只有几个点。先按 768-1024 起步，用评测集验证，别为了参数好看买单。
向量检索擅长语义相近的表达，但精确术语是它的盲区。质检场景里，用户问「条款 4.2.3 的偏差标准」，query 里的编号在向量空间里没有语义，只有 BM25 这种关键词检索能精确命中。
我们的标准配置是「向量 + BM25 双路召回，RRF 融合，交叉编码器重排」。重排模型（如 bge-reranker）把召回的前 50 条逐对打分，取 top 5 进上下文。只做向量检索不加重排，top 5 里经常混进两三条无关片段，忠实度指标会难看。
这套组合在制造企业的质检条款检索里，精确编号类 query 的命中率比纯向量高 30% 以上。HubSpot 把语义搜索做到 200 亿向量规模时的架构取舍，是向量库上量后值得对照的样本。
分块改一改、Embedding 换一个，效果到底变好还是变坏？不跑评测集，你只能靠感觉，而感觉在 RAG 项目里几乎总是错的。
评测集三件套：50-100 条来自真实用户的 query，每条标注 golden chunk（应该召回哪几段），再标注期望答案要点。指标盯三个：命中率（recall@k，正确答案是否在召回的 k 条里）、忠实度（faithfulness，回答是否被上下文支撑）、引用准确（citation accuracy，引用的 chunk 是否真的支撑该句）。
每次改动跑同一套评测集，分数不进反退就回滚。这个回归机制比任何架构先进性都重要。同理，PoC 里能跑通和生产线可用是两回事，从演示到上线的门禁清单可以参考这篇企业 AI 应用的 5 道工程门禁。
向量库选型跟着数据量走。已有 PostgreSQL 且向量在百万级以内，pgvector 够用；千万级或高并发，再考虑 Milvus、Qdrant 这类专用库；已经有 Elasticsearch 的团队可以直接用 ES 的向量能力，少维护一套系统。
延迟和成本用三道闸控制：高频 query 的检索结果做缓存，命中直接返回；向量服务不可用时降级到 BM25 关键词检索，保住可用性；最后才是限流和告警。企业知识库的可用性优先级高于单次回答质量。
反面教训汇总：整篇合同一个 chunk、扫描件不 OCR 直接向量化、纯向量检索不加重排、优化不跑评测集——这四件事我们全都犯过，也都是真实项目里命中率腰斩的元凶。
小规模（几万份文档）用开源 Embedding + pgvector + API 推理，月成本可以压到千元级；关键是评测和调优的人力，这也是企业最容易低估的部分。
从 256-512 token 起步，按语义边界切，表格单独成块。用评测集跑 recall@k，哪套分块分数高就留哪套，不要凭感觉。
中文场景足够，BGE、通义、智谱都是一线水平。先用 API 验证效果再决定是否自部署，别一上来就上 GPU。
增量向量化新文档，对已失效的 chunk 做标记或删除。更新后必须重跑评测集，防止旧知识污染新回答。
看三个数字：命中率、忠实度、引用准确。三个都过 85% 才能谈得上生产可用，只看 demo 效果不算数。
如果你也在搭企业知识库，卡在评测或分块上，可以私信我们拿 RAG 评测数据集模板，或直接看我们做过的企业知识库案例。