RAG还是微调？企业知识库问答的工程选型指南

大模型落地企业知识库时，RAG 和微调不是非此即彼，而是一道工程选型题。错误的选择会让你的系统既慢又贵，还可能产生无法追溯的幻觉答案。这篇教程会从原理、混合检索、评估方法、常见坑和工具链五个部分，给你一套可以直接落地的选型指南。

1. RAG与微调的核心区别和适用边界

1.1 核心区别

维度	RAG（检索增强生成）	微调（Fine-tuning）
知识存储	外部向量库/索引/图谱	模型参数内化
知识更新	替换/新增文档后即时生效	需要重新训练，周期长
推理成本	检索 + 生成，链路长	一次推理，但训练成本高
可解释性	高，可引用源文档	低，回答难以溯源
适合任务	事实问答、文档摘要、客服答疑	风格转换、特定指令、结构化输出
数据需求	需要文档语料，无需标注	需要高质量的指令或问答对
幻觉风险	漏检、错检仍会导致幻觉	参数记忆错误会产生“自信的幻觉”
上线速度	数天即可搭建	需要数据准备、训练、评测调优

1.2 适用边界

**优先选择 RAG：**

知识内容高频变化，例如产品手册、法律法规、内部制度。
客户或审计要求回答必须给出原文依据。
团队没有足够标注数据，且需要快速冷启动。
知识分散在 PDF、Word、网页、数据库中，需要统一检索。

**优先选择微调：**

需要强制模型按企业风格输出，比如“先结论，后理由，最后风险提示”。
需要模型学会特定术语或代码规范。
模型基础能力够，但指令遵循能力差。
知识相对稳定，不需要频繁更新。

**最佳实践：**

先用 RAG 解决“知道什么”，再用微调解决“怎么说”。两者是互补关系，而不是对抗关系。

2. 混合检索（关键词+向量+知识图谱）实践

单一检索几乎无法覆盖企业真实查询。订单号、型号、人名适合关键词；长尾口语化问题适合向量；多跳关系问题适合知识图谱。因此需要混合检索。

2.1 整体流程

flowchart TD A[用户查询] --> B[查询理解与改写] B --> C[关键词检索<br>BM25 / Elasticsearch] B --> D[向量检索<br>Embedding + Milvus] B --> E[知识图谱查询<br>实体识别 + Cypher] C --> F[分数融合 RRF] D --> F E --> F F --> G[重排 Rerank] G --> H[大模型生成] H --> I[答案 + 引用来源]

2.2 三种检索方式对比

检索方式	匹配粒度	典型引擎	最佳场景
关键词 BM25	Token 精确匹配	Elasticsearch / OpenSearch	编号、型号、人名、精确专有名词
向量检索	语义向量距离	Milvus / Qdrant / pgvector	同义改写、长尾口语化表达
知识图谱	实体与关系	Neo4j / NebulaGraph	多跳关联、复杂条件过滤

2.3 实践要点

查询理解不是可选项。 先做实体识别、缩写归一化、同义词扩展。例如 FY24 要能被识别为 2026财年。
关键词检索不要只用 substring。 使用 BM25 并针对字段加权，比如标题权重是正文的 3 倍。
向量检索要注意 Embedding 版本。 每次更换 Embedding 模型都会让旧向量失效，必须在集合中保存 embedding_version 字段。
知识图谱不是必须。 只有当问题存在明显关系链，例如“某供应商过去一年交付过哪些项目”时才引入。
分数融合用 RRF，不要直接加权求和。 因为 BM25 得分与向量余弦相似度量纲不同，RRF 对排名敏感、对分数不敏感：

`RRF(d) = Σ 1 / (k + rank_i(d))`, 其中 k 通常取 60。

3. 召回率、准确率评估方法

企业选型最怕“拍脑袋”。我们需要在真实业务场景中建立评估集，并定义统一指标。

3.1 评估集构建

收集真实用户日志，而不是编造几条 demo。
每个 Query 标注三部分：答案、支撑文档片段（Golden Context）、答案是否可检索到。
先用 50~100 条做快速验证，再扩到 200~500 条做正式回归。

3.2 分层指标体系

评估层次	指标	说明
检索层	Recall@5 / Recall@10	标准答案所在片段是否在 Top-K 内，决定了答案“天花板”
排序层	MRR / NDCG	标准片段越靠前越好，直接影响生成效果
生成层	Answer Correctness	与参考答案语义一致性，可用 LLM-as-Judge
生成层	Faithfulness / 忠实度	回答是否依据检索片段，而不是模型臆测
系统层	P95 延迟 / Token 成本 / 缓存命中率	工程可落地性

3.3 评估方法建议

LLM-as-Judge 可行，但需要抽样人工复核。 用 GPT-4 或 Qwen-Max 对答案打分，再抽 20% 给真人看，避免偏差。
记录失败案例。 每个“查不到”和“答错”都要进入回归集，防止下次改坏。
用 A/B 评测决定选型。 在相同评估集上对比“RAG”、“微调”、“RAG+微调”三种方案的指标，再结合成本和更新频率做决策。

4. Chunking 到重排的常见坑

RAG 管线中 80% 的问题出在数据切分和检索链路，而不是大模型本身。

4.1 常见坑与解法

阶段	常见坑	正确做法
Chunking	固定 512 个字符硬切，把一段话从中间切断	按 Markdown 标题 / 段落 / 代码函数结构切，保留上下文
Chunking	切太小，模型看不到完整事件	使用父子分块：父块提供上下文，子块用于检索
清洗	PDF 表格被 OCR 成乱码	用专门的表格解析器，如 PaddleOCR / Table Transformer
Embedding	query 和 document 用同一个模板	训练/调用时分开：query 用 query instruction，document 用 document instruction
向量库	Top-K 只取 5 个，答案没检索到	召回阶段先取 50~100 个，重排后再保留 Top 5
重排	对所有候选做 Cross-Encoder	只对混合检索后的 Top 50 重排，兼顾效果和延迟
生成	没有引用编号	强制 prompt 输出 `[引用1]`，并映射到具体文档块
权限	检索时未过滤用户权限	在检索输入前加入“权限过滤条件”，确保不能越权读取文档

4.2 分块建议

普通文档： 递归字符分块，块大小 500~800 token，重叠 10~20%。
Markdown/HTML： 按标题层级切，保留标题作为父节点。
代码库： 按函数/类分块，并附带文件路径和 import 上下文。
表格： 独立解析为 Markdown 表格，再与前后段落关联。

5. 参考架构与开源工具推荐

5.1 参考架构

flowchart LR subgraph 接入层 A[企业IM / Web / API] --> B[认证与权限网关] end subgraph 智能问答服务 B --> C[Query 理解] C --> D[混合检索] D --> E[重排] E --> F[LLM 生成] end subgraph 数据层 D --> G[(向量库/Elasticsearch)] D --> H[(知识图谱)] E --> I[(缓存)] end

5.2 开源工具清单

模块	推荐工具	理由
框架	LlamaIndex / LangChain	生态成熟，有大量 RAG 模块可直接组合
关键词检索	Elasticsearch / OpenSearch	支持 BM25、过滤、权限、高亮
向量库	Milvus / Qdrant / pgvector	按并发和数据量选择，pgvector 适合已有 PostgreSQL
知识图谱	Neo4j / NebulaGraph	多跳关系查询，Neo4j 社区版够用
Embedding	bge-m3 / gte-Qwen2	中英双语效果好，支持长文档
重排	bge-reranker-v2-m3	Cross-Encoder 比双塔模型显著提升精度
评测	RAGAS / TruLens	自动生成评估指标，适合回归
缓存	Redis / KeyDB	缓存重复 query，降低成本和延迟

操作清单

在开始编码之前，按以下顺序执行：

盘点企业文档格式、更新频率、用户权限，明确 3 个核心问答场景
从日志中抽取 50 条真实问题，人工打标 golden context 与 golden answer
搭建 Elasticsearch/OpenSearch，跑一遍 BM25 baseline，记录 Recall@5
加入向量检索，对比 Recall@5 是否提升，排除 embedding 版本问题
若存在多跳问题，引入知识图谱，设计实体/关系 schema
实现 RRF 融合，将候选集扩大到 100，进入 Rerank
用 bge-reranker 重排，记录 MRR/NDCG 变化
在生成 prompt 中加入引用机制，要求输出 [1] 对应来源
配置日志与用户反馈（点赞/点踩/漏答举报）
灰度上线，每天统计失败案例并回流到评估集

避坑指南

不要一上来就微调。 没有正确评估集，微调后的模型无法证明自己更好。
不要只看准确率。 企业知识库更要关注“漏检率”和“幻觉率”。
不要忽略权限过滤。 检索结果必须按用户权限裁剪，否则严重合规事故。
不要忘记 Embedding 模型版本管理。 换模型后历史向量全失效。
不要用 RAG 解决风格问题。 输出话术、格式要求用微调更合适。
不要忽略缓存。 RAG 链路长，缓存相同 query 可降低 30% 以上成本。
不要对文档“一把抓”。 PDF 扫描件、图片、表格需要单独做 OCR 和结构化解析。

平台	推荐视频/搜索关键词	出处/来源
B站	「RAG 还是微调？企业知识库实战解析」	B站 UP主：跟李沐学AI / DataWhale 等
腾讯视频	「大模型知识库 RAG 与微调」	腾讯视频：InfoQ 技术课堂
优酷	「RAG 工程实践：混合检索与重排」	优酷：极客时间专题
抖音	「一分钟看懂 RAG 与微调」	抖音：机器之心 / 量子位