RAG、微调、长上下文，企业知识库问答该选哪个？

三者不是替代关系：RAG 适合「答案来自已有文档、需要可追溯引用」的场景（合同审查、制度问答、产品文档），成本低、易更新、幻觉可控；微调适合「风格与格式需要固定」的场景，但无法注入新知识且每轮更新都要重训；长上下文适合单篇长文档问答，多文档聚合时会超出窗口且成本随长度暴涨。绝大多数企业知识库场景，RAG 是第一选择，微调只解决表达风格，解决不了知识缺失。

Qdrant、Milvus、pgvector、Elasticsearch 怎么选？

按团队基础和场景决定：已有 PostgreSQL 且数据量千万级以下，pgvector 零新组件即可起步；要做大规模向量检索、HNSW 索引和过滤组合查询，Qdrant 上手最快、运维最简；数据量亿级以上且要分布式，选 Milvus；需要同时做全文检索和向量检索的混合检索且已有 ES 基建，选 Elasticsearch。别一上来就上分布式向量库，大多数企业知识库几百万条 chunk 用单机 Qdrant 就够了。

RAG 检索质量差，最常见的三个原因是什么？

第一是切分太粗暴——按固定字数切分切断了语义完整段，导致检索碎片化，正确做法是按标题层级和语义边界切分；第二是没有元数据过滤——知识库混入多个文档时不做来源、日期、权限过滤，检索结果互相污染；第三是只用向量检索——专有名词、编号、缩写（合同条款号、产品型号）用向量召回极不稳定，必须配合关键词检索的混合检索。

私有化部署 RAG 知识库需要什么硬件？

取决于模型和并发：7B-8B 模型做单机部署，RTX 4090（24G）可跑 AWQ 4bit 量化，服务几十个并发没问题；32B 级 MoE 模型（如 Qwen3-30B-A3B）建议 48G 显存以上；70B 级需要 A100/H20 或双卡。知识库规模不影响 GPU 需求（向量检索是 CPU 内存活），决定显存的是模型大小和并发数，可用模型部署测算器按模型、量化、上下文、并发四个参数精确估算。

RAG 上线后怎么评估效果？

拆成三层：检索层评估——用带标准答案的测试集算召回率和 MRR，低于 80% 先别调生成；生成层评估——抽样看引用正确率和答案完整率，用 LLM-as-judge 批量打分 + 人工抽验；业务层评估——上线后跟踪用户「追问率」和「采纳率」，追问多说明首答没命中。评测集要覆盖真实高频问题，至少 100 条起步，否则指标没有统计意义。

企业私有知识库 RAG 落地实战：从架构选型到检索质量（2026 完整指南）

RAG 是企业 AI 落地最高频的场景。本文完整拆解私有知识库问答的落地链路：RAG vs 微调 vs 长上下文的决策边界、向量库选型（Qdrant/Milvus/pgvector）、切分与元数据设计、混合检索与重排、私有化部署成本、上线后质量评估。附可复制的评估清单和常见坑。【查看RAG落地6步清单】

先说结论：RAG 是 2026 年企业 AI 落地最高频的场景

过去两年我们接触的企业 AI 项目里，出现频率最高、投入产出比最稳的场景就是私有知识库问答：制度问答、合同审查、产品文档、售后知识库、行业规范检索。原因很简单——企业内部 80% 的知识沉淀在文档里，而文档问答恰好是 RAG 最擅长的任务。

但 RAG 的落地差距极大：有人用 Docker 跑一个 Qdrant + 开源模型就上线了，效果不错；有人调了三个月还在”检索不准”。差距不在模型，而在知识工程——切分、元数据、检索策略、评估闭环。本文把从 0 到 1 的完整链路拆开讲，含决策边界、选型、可复制的配置与评估清单。

1. 先做决策：RAG 还是微调，还是长上下文？

很多团队第一步就选错了。三者的适用边界：

方案	适合	不适合	成本
RAG	答案来自已有文档、需要引用溯源	风格/格式需要模型内化	低，易更新
微调	固定输出格式、领域表达风格	注入新知识（训完仍需 RAG）	高，每次更新重训
长上下文	单篇长文档问答	多文档聚合、窗口超限	随长度暴涨

判断口诀：知识在文档里、答案要能溯源 → RAG；只有风格和格式要固定 → 微调；单篇几万字以内 → 长上下文。绝大多数企业知识库场景，RAG 是第一选择。微调解决不了知识缺失——你没法把知识库”训进”模型，即使训了，更新知识也要重训，成本不可持续。

2. 架构总览：一条完整的 RAG 链路

一个生产级 RAG 系统有五段，缺一段都会在线上暴露问题：

文档入库 → 解析清洗 → 切分 → 向量化 → 向量库存储
                              ↓
用户提问 → 查询改写 → 混合检索(向量+关键词) → 重排 → 组装上下文 → 生成 → 带引用输出

大部分团队把精力放在「向量化 → 生成」，忽略了入库侧（解析清洗、切分、元数据）和检索侧（查询改写、混合检索、重排）——而这两侧恰恰决定了检索质量的上限。模型只是最后一段。

3. 向量库选型：别一上来就上分布式

方案	优势	适合	注意
pgvector	零新组件，复用现有 PG	已有 PostgreSQL，千万级以下	过滤查询性能一般
Qdrant	上手最快、运维最简、HNSW+过滤强	独立向量库首选	单机即可起步
Milvus	分布式、亿级扩展	数据量巨大、需多副本	组件多，运维重
Elasticsearch	全文+向量一体，混合检索原生	已有 ES 基建	向量性能不如专用库

务实建议：大多数企业知识库是几百万条 chunk 以内，单机 Qdrant 足够，别为不存在的规模买单。选择标准不是”哪个最强”，而是”哪个和现有团队、现有基建的摩擦最小”。

4. 切分与元数据：决定检索质量的第一因素

切分（Chunking）

最常见的错误是按固定字数硬切（比如 500 字一刀），把语义完整的段落切断，检索时拿到的是半截内容。生产级做法：

按文档结构切：先按标题层级（Markdown 标题 / 章节）切出语义块，块过大再按段落细化——标题信息要保留，它是检索的重要信号。
块重叠：相邻块之间重叠 50-100 字，避免关键句恰好落在切点上。
块上限与下限：单块 200-1000 字为宜。太短上下文信息不足，太长稀释检索精度。
父子分块（可选进阶）：用小块做检索、用其所在的大块做上下文，兼顾精度与语义完整性。

元数据（Metadata）

这是被低估最多的一环。每个 chunk 至少要带：

来源：文档 ID、标题、URL（回答时引用溯源要用）
层级路径：章节路径，回答时可定位
日期：制度有版本，检索要能按时间过滤
权限/部门：不同部门的知识不能互相串

有了元数据，检索才能加过滤条件——「2024 版考勤制度」绝不能召回 2022 版。没有元数据过滤的知识库，多文档混在一起，检索结果必然互相污染。

5. 检索策略：向量之外必须有关键词

纯向量检索在知识库场景有个致命弱点：专有名词、编号、缩写召回极不稳定。合同条款「第 4.2 条」、产品型号「Qwen3-30B-A3B」、内部代号，embedding 对这类 token 区分度很差。生产级方案是混合检索：

向量检索：语义相关召回，解决”换个说法”的问题
关键词检索（BM25）：精确匹配召回，解决”编号/专名”的问题
重排（Reranker）：混合结果合并后，用 cross-encoder 重排器精排，把真正相关的提到前面

推荐配置：BM25 + 向量各召回 Top 50，融合后 Reranker 精排取 Top 5-8。重排模型显存开销小（几 GB），但检索质量提升非常明显，这是性价比最高的一笔投入。

另外别忘了查询改写：用户问「上次说的那个政策现在还能用吗」这种口语化指代，直接检索必失败。用一个小模型把查询改写为「政策有效期 2026」再检索，命中率明显提升。

6. 私有化部署与成本：别被模型大小吓住

私有知识库几乎都要求数据不出内网，部署分两层：

生成层（LLM）

7B-8B 单机：RTX 4090（24G）跑 AWQ 4bit 量化，可服务几十并发，知识库问答质量够用
32B MoE（Qwen3-30B-A3B 等）：建议 48G 显存以上，质量接近 70B 稠密模型
70B 稠密：A100/H20 或双卡，仅在答案质量是硬指标时考虑

检索层（向量库 + 重排）

好消息：向量检索不吃 GPU，吃内存。几百万条 chunk 的向量放内存也就几 GB，CPU 即可。真正决定显存的是模型大小和并发数，与知识库规模无关——这点很多人想反了。

硬件预算可以按模型、量化方式、上下文长度、并发数四个参数精确测算，用我们的模型部署测算器几分钟出结论（VRAM、显卡选型、预算、vLLM 启动参数），不用拍脑袋。

7. 上线后的质量评估：把评测做成机制

RAG 项目最大的坑是没有评测集就上线，全靠”感觉好像还行”。生产级做法：

第一层：检索层评估

准备 100+ 条带标准答案的真实高频问题
算 召回率（标准答案是否在召回结果里）和 MRR（标准答案排第几）
召回率低于 80% 先别调生成层——检索不准，模型再强也答不对

第二层：生成层评估

抽样 50-100 条，人工/LLM-as-judge 打分：引用正确率、答案完整率、幻觉率
引用是 RAG 的核心价值，答案必须带引用且引用必须真实

第三层：业务层评估

上线后跟踪追问率（首答后用户继续追问的比例，高说明首答没命中）和采纳率
每周看一次，把高频答错的问题回流进评测集，形成闭环迭代

8. 四个最常见误区

1. 把模型当全部。 换更大的模型解决不了检索不准。先解决切分、元数据、混合检索，模型 7B 就够。

2. 用固定字数切分。 语义块被切断，检索碎片化。按标题层级和语义边界切，是投入产出比最高的一步。

3. 只做向量检索。 专有名词和编号召回必崩。混合检索 + 重排是标配，不是加分项。

4. 没有评测就上线。 “感觉还行”会被用户的追问打脸。100 条评测集、三层评估、每周回流，才是可持续的质量保障。

最后：RAG 的护城河是知识工程，不是模型

把上面所有环节串起来看，RAG 落地的瓶颈从来不在”有没有大模型”，而在知识工程的细腻程度：文档怎么解析、怎么切分、元数据怎么设计、检索怎么组合、效果怎么评估。这些正是我们团队做 AI 工程外包和补位服务时最常被委托的部分——AI 工程补位服务覆盖 RAG 与知识库从架构设计到上线迭代的全过程，适合「团队里缺一个能把 RAG 做到生产级的人」的企业。

延伸阅读：

AI Agent 工作流编排实战：从单 Agent 到多 Agent 的架构选型 — RAG 之上的 Agent 层：工具调用、编排架构与幻觉控制

AI 赋能中小企业：三个真实落地案例 — RAG 在合同审查等场景的真实落地效果

AI 应用的可观测性设计 — RAG 系统上线后如何观测检索与生成质量

系统容量规划与压测实战 — 知识库上线的并发与容量设计

找个靠谱的技术外包团队，看这 6 点就够了 — 选供应商的评估 checklist

模型部署测算器 — 按模型/量化/上下文/并发精确算私有化部署硬件预算

需要私有知识库 RAG 落地的架构设计、技术选型或补位开发？联系我们获取免费评估。