企业知识库问答落地：RAG 从架构选型到检索质量的完整指南
适合读者：正在做或准备做企业知识库问答（制度问答、合同审查、产品文档、售后知识库）的技术负责人、后端工程师、AI 应用开发者
企业 AI 落地，场景千千万，但过去两年我们接触的项目里，出现频率最高、投入产出比最稳的就是私有知识库问答：制度问答、合同审查、产品文档、售后知识库、行业规范检索。
原因很简单——企业内部 80% 的知识沉淀在文档里，而文档问答恰好是 RAG 最擅长的任务。
但 RAG 的落地差距极大：有人用 Docker 跑一个 Qdrant + 开源模型就上线了，效果不错；有人调了三个月还在"检索不准"。差距不在模型，而在知识工程——切分、元数据、检索策略、评估闭环。
一、先做决策：RAG 还是微调，还是长上下文？
很多团队第一步就选错了。
| 方案 | 适合 | 不适合 | 成本 |
|---|---|---|---|
| RAG | 答案来自已有文档、需要引用溯源 | 风格/格式需要模型内化 | 低，易更新 |
| 微调 | 固定输出格式、领域表达风格 | 注入新知识（训完仍需 RAG） | 高，每次更新重训 |
| 长上下文 | 单篇长文档问答 | 多文档聚合、窗口超限 | 随长度暴涨 |
判断口诀：知识在文档里、答案要能溯源 → RAG；只有风格和格式要固定 → 微调；单篇几万字以内 → 长上下文。
绝大多数企业知识库场景，RAG 是第一选择。微调解决不了知识缺失——你没法把知识库"训进"模型，即使训了，更新知识也要重训，成本不可持续。
二、一条完整的 RAG 链路
一个生产级 RAG 系统有五段，缺一段都会在线上暴露问题：
文档入库 → 解析清洗 → 切分 → 向量化 → 向量库存储 ↓ 用户提问 → 查询改写 → 混合检索(向量+关键词) → 重排 → 组装上下文 → 生成 → 带引用输出大部分团队把精力放在「向量化 → 生成」，忽略了入库侧（解析清洗、切分、元数据）和检索侧（查询改写、混合检索、重排）——而这两侧恰恰决定了检索质量的上限。模型只是最后一段。
三、向量库选型：别一上来就上分布式
| 方案 | 优势 | 适合 | 注意 |
|---|---|---|---|
| pgvector | 零新组件，复用现有 PG | 已有 PostgreSQL，千万级以下 | 过滤查询性能一般 |
| Qdrant | 上手最快、运维最简、HNSW+过滤强 | 独立向量库首选 | 单机即可起步 |
| Milvus | 分布式、亿级扩展 | 数据量巨大、需多副本 | 组件多，运维重 |
| Elasticsearch | 全文+向量一体，混合检索原生 | 已有 ES 基建 | 向量性能不如专用库 |
务实建议：大多数企业知识库是几百万条 chunk 以内，单机 Qdrant 足够。选择标准不是"哪个最强"，而是"哪个和现有团队、现有基建的摩擦最小"。
四、切分与元数据：决定检索质量的第一因素
切分（Chunking）
最常见的错误是按固定字数硬切（比如 500 字一刀），把语义完整的段落切断。生产级做法：
- 按文档结构切：先按标题层级切出语义块，块过大再按段落细化——标题信息要保留，它是检索的重要信号。
- 块重叠：相邻块之间重叠 50-100 字，避免关键句恰好落在切点上。
- 块上限与下限：单块 200-1000 字为宜。
- 父子分块（可选进阶）：用小块做检索、用其所在的大块做上下文，兼顾精度与语义完整性。
元数据（Metadata）
这是被低估最多的一环。每个 chunk 至少要带：
- 来源：文档 ID、标题、URL（回答时引用溯源要用）
- 层级路径：章节路径，回答时可定位
- 日期：制度有版本，检索要能按时间过滤
- 权限/部门：不同部门的知识不能互相串
有了元数据，检索才能加过滤条件——「2024 版考勤制度」绝不能召回 2022 版。
五、检索策略：向量之外必须有关键词
纯向量检索在知识库场景有个致命弱点：专有名词、编号、缩写召回极不稳定。合同条款「第 4.2 条」、产品型号「Qwen3-30B-A3B」、内部代号，embedding 对这类 token 区分度很差。
生产级方案是混合检索：
- 向量检索：语义相关召回，解决"换个说法"的问题
- 关键词检索（BM25）：精确匹配召回，解决"编号/专名"的问题
- 重排（Reranker）：混合结果合并后，用 cross-encoder 重排器精排，把真正相关的提到前面
推荐配置：BM25 + 向量各召回 Top 50，融合后 Reranker 精排取 Top 5-8。重排模型显存开销小（几 GB），但检索质量提升非常明显，这是性价比最高的一笔投入。
另外别忘了查询改写：用户问「上次说的那个政策现在还能用吗」这种口语化指代，直接检索必失败。用一个小模型改写为「政策 有效期 2026」再检索，命中率明显提升。
六、私有化部署与成本：别被模型大小吓住
私有知识库几乎都要求数据不出内网，部署分两层：
生成层（LLM）：
- 7B-8B 单机：RTX 4090（24G）跑 AWQ 4bit 量化，可服务几十并发
- 32B MoE（Qwen3-30B-A3B 等）：建议 48G 显存以上
- 70B 稠密：A100/H20 或双卡，仅在答案质量是硬指标时考虑
检索层（向量库 + 重排）：好消息是向量检索不吃 GPU，吃内存——几百万条 chunk 的向量放内存也就几 GB，CPU 即可。真正决定显存的是模型大小和并发数，与知识库规模无关。
硬件预算可以按模型、量化方式、上下文长度、并发数四个参数精确测算，官网的模型部署测算器几分钟出结论（VRAM、显卡选型、预算、vLLM 启动参数）。
七、上线后的质量评估：把评测做成机制
RAG 项目最大的坑是没有评测集就上线，全靠"感觉好像还行"。
第一层：检索层评估：准备 100+ 条带标准答案的真实高频问题，算召回率和MRR。召回率低于 80% 先别调生成层——检索不准，模型再强也答不对。
第二层：生成层评估：抽样 50-100 条，人工/LLM-as-judge 打分：引用正确率、答案完整率、幻觉率。答案必须带引用且引用必须真实。
第三层：业务层评估：上线后跟踪追问率（首答后用户继续追问的比例，高说明首答没命中）和采纳率。每周看一次，把高频答错的问题回流进评测集，形成闭环迭代。
八、四个最常见误区
- 把模型当全部。换更大的模型解决不了检索不准。先解决切分、元数据、混合检索，模型 7B 就够。
- 用固定字数切分。语义块被切断，检索碎片化。按标题层级和语义边界切，是投入产出比最高的一步。
- 只做向量检索。专有名词和编号召回必崩。混合检索 + 重排是标配，不是加分项。
- 没有评测就上线。"感觉还行"会被用户的追问打脸。100 条评测集、三层评估、每周回流，才是可持续的质量保障。
最后：RAG 的护城河是知识工程，不是模型
把上面所有环节串起来看，RAG 落地的瓶颈从来不在"有没有大模型"，而在知识工程的细腻程度：文档怎么解析、怎么切分、元数据怎么设计、检索怎么组合、效果怎么评估。
完整版博客（含 FAQ 详解与更多配置细节）：企业私有知识库 RAG 落地实战：从架构选型到检索质量（2026 完整指南）
相关阅读：
- AI 赋能中小企业：三个真实落地案例 —— RAG 在合同审查等场景的真实落地效果
- AI 应用的可观测性设计 —— RAG 系统上线后如何观测检索与生成质量
- 系统容量规划与压测实战 —— 知识库上线的并发与容量设计
- 模型部署测算器 —— 按模型/量化/上下文/并发精确算私有化部署硬件预算
（本文首发于 AIGC Harness 博客，转载请注明出处）