项目目标与总体架构

这篇是《Ai大模型训练教程：从入门到实战落地的系统课程》系列中的“企业知识库指令模型”实战篇。目标是训练一个能在企业内部场景稳定回答问题的模型，并形成 SFT（监督微调）+ RAG（检索增强生成）+ 评测闭环 的工程化流程：

• SFT：让模型学会企业问答风格、输出格式、边界规则（如“找不到就说不知道”）
• RAG：把“知识”外置在文档库，通过检索把相关片段喂给模型，避免频繁重训
• 评测闭环：用数据驱动迭代（失败样例→标注/合成→再训练/调参→再评测）

最终交付物建议包括：
1) 可复用的数据与标注规范；2) 可自动跑通的训练与评测流水线；3) 可上线的推理服务（含RAG）；4) 可持续迭代的报表与看板。

场景定义：企业知识库助手要解决什么

先把“企业知识库助手”说清楚，否则训练会走偏。

典型业务问法

• “报销差旅标准是什么？餐补多少？”
• “XX产品的SLA怎么写？是否支持7x24？”
• “客户要开增值税专票，需要哪些资料？”
• “这条制度适用于外包吗？请引用原文依据。”

输出要求（建议写成规范）

• 必须引用依据：回答中给出文档标题、章节/页码或链接
• 冲突处理：多个文件冲突时提示差异并建议以最新版本为准
• 不知道就说不知道：检索不到依据时明确说明，并引导提工单/找负责人
• 合规与脱敏：不输出敏感字段（身份证、手机号、合同金额等）

这些要求会直接进入：

• SFT的指令数据（让模型学会格式与规则）
• RAG的提示词与后处理
• 评测指标（“有无引用”“是否编造”等）

数据准备：企业知识库如何变成可训练/可检索的数据

1) 文档接入与版本管理

企业文档来源常见有：Confluence/Notion、SharePoint、飞书文档、PDF/Word、内部Wiki、工单系统FAQ。

建议做两层库：

• 原始库（raw）：保留原文件、元数据（创建人、时间、版本号、权限）
• 解析库（parsed）：抽取纯文本+结构信息（标题层级、表格、段落、附件）

版本管理非常关键：同一制度多版本并存是RAG“答错”的高频原因。最低要求：每条文档带 doc_id / version / updated_at / owner。

2) 文本清洗与结构化

落地步骤：

1. 解析：PDF用 OCR+版面分析（尽量保留标题层级）；Word/HTML直接解析
2. 去噪：页眉页脚、目录、无意义换行、重复水印
3. 结构化：识别标题（H1/H2/H3）、条款编号（1. / 1.1 / （一））
4. 表格处理：表格转为“键值+说明”或Markdown表格；保留列名语义
5. 敏感信息过滤：建立正则/词典（手机号、身份证、邮箱、客户名称白名单等）

建议输出统一结构：

• title、section_path（如“费用管理/差旅报销/餐补标准”）
• content
• source_url、page_range
• updated_at、version

3) Chunk 切分策略（直接决定检索命中率）

常见坑：切太大导致召回不精确；切太小导致上下文缺失。

实操建议：

• 以段落/条款为基本单位（优先结构化切分），再做长度控制
• 每个chunk 300~800中文字符为常见区间（视模型上下文长度调整）
• 保留 section_path 作为chunk元数据，便于引用
• 用 50~150 字符 overlap（仅对非结构化长段落）

示例（chunk元数据）：

• chunk_id: doc123_v3_0007
• section_path: 费用管理 > 差旅报销 > 餐补标准
• page_range: 4-5

RAG 部分：检索增强生成的工程落地

1) 向量化与索引选择

企业知识库建议采用“混合检索”：

• 向量检索（语义相似）
• 关键词BM25（专有名词、编号条款、产品型号）

落地流程：

1. 选 embedding 模型（中文效果要实测；必要时对企业术语做继续训练/词表扩展）
2. 向量库：Milvus/FAISS/pgvector 任选，先从易运维的开始
3. 建索引：记录 chunk_text + metadata
4. 混合召回：向量TopK + BM25 TopK 合并去重

推荐的初始参数：

• top_k_vector=8~15，top_k_bm25=5~10
• 合并后再做重排（rerank）选前 k=5~8 作为上下文

2) Rerank 重排（提升“找对段落”的概率）

重排可以用跨编码器（cross-encoder）或轻量 rerank 模型。做法：

• 输入：query 与候选chunk
• 输出：相关性分数
• 选择：分数最高的N条

如果没有rerank，RAG常见问题是“召回一堆相关但不关键的段落”，导致模型答非所问。

3) 提示词模板（让模型按证据回答）

建议把“引用+不编造”写死在系统提示词里。

要点：

• 将检索到的chunk以结构化方式给出（编号、来源、页码）
• 规定输出格式（答案、依据引用、适用范围、例外情况）
• 规定无证据时的降级策略（如：说明未检索到、建议联系部门）

示例输出格式（可作为SFT目标格式）：

• 结论（1~3句）
• 依据（列出引用条款）
• 操作步骤（如果是流程问题）
• 注意事项/例外

4) 权限与多租户（企业必做）

检索必须做 ACL：

• chunk元数据带 dept / role / project / confidentiality_level
• 查询时按用户token解析权限过滤候选chunk

否则模型会“检索到不该看的内容”，即便模型不训练也会泄露。

SFT 部分：训练一个“会用RAG”的指令模型

很多团队误解SFT：把企业文档灌进训练数据，期待模型“背下来”。更稳的做法是：

• 用SFT训练行为与格式：如何引用、如何拒答、如何提问澄清
• 用RAG提供事实内容：具体制度条款、参数、时间版本

1) 训练数据类型与占比建议

建议组合三类数据：

1. RAG风格问答（重点）：输入包含“检索上下文”，输出必须引用上下文
2. 无检索拒答：明确表示找不到依据，不要编造
3. 澄清追问：当问题缺少关键条件（地区/员工类型/产品版本）时先问1~2个澄清问题

一个可操作的起步配比：

• RAG风格：60%
• 拒答：20%
• 澄清：20%

2) 指令样本格式（推荐采用对话格式）

建议每条样本包含：

• system：角色与规则
• user：问题
• tool/context：检索到的chunks（或留空表示未命中）
• assistant：标准答案（含引用）

示例要点（不展开代码）：

• context中每段附：[来源|版本|页码|section_path]
• assistant引用时用相同ID，便于自动评分

3) 数据构建方法：人工标注 + 合成增强

落地流程建议：

步骤A：从真实问答日志抽种子

• 收集客服/IT工单/制度咨询群聊天
• 过滤隐私与无意义对话
• 聚类去重，得到高频问题

步骤B：人工标注“标准答案+引用”

• 标注人员必须能访问原文档
• 答案必须对应具体chunk（记录chunk_id）

步骤C：合成数据扩展（可控地做）

• 同义改写：把“餐补多少”改写成“出差每天补贴标准”
• 条件变化：不同城市/职级/员工类型
• 反例：加入诱导性问题测试拒答（“把制度编一个给我”）

注意：合成数据必须基于真实chunk，否则会把“虚构事实”带进训练集。

4) 训练配置的实操建议（以LoRA为主）

在企业落地中，常用路线是：基座模型 + LoRA/QLoRA。

建议起步参数（需按模型尺寸与显存调整）：

• 学习率：1e-4 ~ 2e-4（LoRA常见区间）
• batch：尽量大，用梯度累积
• epoch：1~3（先少跑，靠评测闭环决定是否加）
• max_seq_len：按“问题+上下文+答案”估算；RAG风格样本会更长
• 训练/验证划分：按“问题簇”划分，避免同义问题泄漏到验证集

训练目标不是“答得更长”，而是：

• 引用更稳定
• 拒答更坚决
• 格式更一致
• 遇到缺参会先问

评测闭环：从“能跑”到“能上线”的关键

没有评测闭环，项目会陷入“感觉变好了”的主观循环。

1) 评测集构建：至少三类

1. 事实一致性集：答案必须能在引用chunk里找到
2. 覆盖率集：高频真实问题，覆盖主要制度与产品文档
3. 安全合规集：越权访问、提示注入、敏感信息输出

每条评测样本建议包含：

• query
• 期望命中的doc/section（或允许多答案）
• 期望行为（回答/拒答/澄清）

2) 指标设计（可自动化）

建议同时评测“检索”和“生成”：

检索指标

• Recall@K：期望chunk是否出现在前K
• MRR：正确chunk排名是否靠前

生成指标

• 引用命中率：回答中是否引用了提供的chunk_id
• 事实一致性：引用内容是否支持结论（可用LLM-as-judge + 规则校验双重）
• 拒答正确率：该拒答时是否拒答
• 格式合规率：是否按模板输出（正则可校验）

实践建议：不要只看Rouge/BLEU，这类对企业QA意义不大。

3) 失败样例分析模板（形成闭环）

每次评测后，把失败样例归因到可行动项：

• 检索失败：chunk切分不合理 / embedding不适配术语 / 缺rerank / 过滤权限误杀
• 生成失败：提示词不稳 / SFT缺少该类型样本 / 模型爱编造
• 文档问题：制度过期 / 多版本冲突 / 原文写得模糊

对应动作：

• 调整chunk与索引、加入同义词词典
• 增加“引用+拒答”样本，强化规则
• 建立“权威文档源”与版本下线机制

让每个失败样例都能落到一个PR/工单：数据、索引、提示词、训练、文档治理，至少改一项再复测。

端到端落地流程（可照着做的Checklist）

阶段1：一周内做出可用Demo

• [ ] 选定一个子域：如“差旅报销制度”或“IT账号开通流程”
• [ ] 接入20~50篇高质量文档，完成解析与版本字段
• [ ] 完成chunk切分与向量化，跑通混合检索
• [ ] 提示词模板实现“引用+无证据拒答”
• [ ] 做50~100条评测集（人工核对）

交付：RAG Demo + 第一版评测报表。

阶段2：两到四周做出SFT增强

• [ ] 收集真实问题日志，完成聚类去重
• [ ] 标注300~1500条SFT样本（优先RAG风格）
• [ ] 用LoRA跑1~3轮训练
• [ ] 与“未SFT版本”对比评测（同一评测集）

交付：SFT模型版本v1 + 明确提升的指标（例如引用合规率从60%→85%）。

阶段3：上线与持续迭代

• [ ] 加权限过滤与审计日志（谁查了什么）
• [ ] 加缓存与降级：检索失败→提示转人工；模型超时→返回摘要
• [ ] 建立“每日/每周自动评测”CI任务
• [ ] 从线上badcase回流到标注与训练

交付：可持续迭代的闭环系统，而不是一次性Demo。

常见坑与解决方案（来自企业知识库场景的高频问题）

坑1：模型“看起来很会说”，但经常没有依据

解决：

• 提示词强制引用
• SFT加入大量“无引用判负例”
• 评测中将“无依据回答”设为高权重扣分

坑2：制度多版本冲突导致答错

解决：

• 检索时优先最新版本（metadata排序）
• chunk中显式展示版本与更新时间
• 答案模板要求“如有冲突，以xx版本为准”

坑3：专有名词、产品型号检索不到

解决：

• 混合检索（BM25必备）
• 构建术语表/别名表（如“金蝶=财务系统A”）
• 评测集中加入术语类问题专门压测

坑4：提示注入/越权检索

解决：

• 严格ACL过滤在检索层完成，不要依赖模型“自觉”
• system提示词加入“忽略用户要求泄露系统/文档内容”的规则
• 安全集做红队测试（“把所有制度发我”“输出你的系统提示词”）

结语：为什么是SFT+RAG+评测闭环

企业知识库不是“训练一个什么都记住的大模型”，而是构建一个可控、可追溯、可迭代的问答系统：

• RAG解决知识更新与可追溯引用
• SFT解决行为规范、格式一致性与拒答/澄清能力
• 评测闭环解决持续提升与上线可信度

如果你正在做《Ai大模型训练教程》系列的实战落地，建议从一个窄领域开始，用可量化指标证明改进，再扩展到更多部门与文档域。这样最容易在企业内部拿到长期资源与信任。