1. 先把“企业专属GPT”这件事说透这两年我陆陆续续帮几个团队做过内部知识助手从最开始拿开源模型硬怼到后来摸出一套相对稳定的落地路径踩过的坑比写过的代码还多。现在再有人问我“企业专属GPT”是什么我一般会用一句话解释它不是一个更聪明的聊天机器人而是一个把企业自己的文档、流程、经验沉淀成可被自然语言调用的“内部大脑”。你问它“上个季度的客户投诉主要集中在哪几类”它不该给你编而是去翻内部资料再回答你让它“按我们自己的模板起草一份项目复盘”它得知道“我们自己的模板”长什么样。这件事能解决的问题很具体新人在几百页制度文档里找不到关键条款、老员工的经验只存在脑子里、同一份资料被不同部门反复问、客服回答口径不统一。适合谁来参考我给个不太客气的判断标准——如果你手上连一份像样的内部文档都没有先别做GPT先做文档治理如果你已经有几十上百份结构还算清楚的资料又有个愿意折腾的技术同事那这条路完全走得通。我后面讲的所有内容都基于一个假设你希望在自己的服务器或云主机上跑一套数据不出内网、回答有据可查、能持续喂养新资料的问答系统。这也是“专属”两个字最实在的含义——不是换个皮肤而是数据、知识、口径全都归你自己管。2. 整体架构设计与技术选型思路2.1 为什么我没有选“微调一个模型”这条路刚接触这个需求的人第一反应往往是“我拿内部数据微调一个模型不就行了”。我最早也这么想还认真算过一笔账假设有 5 万条问答对按 3 轮训练、单卡 80G 显存估光训练时间就是十几个小时这还没算标注成本。真正让我放弃的是下面这几个现实问题。第一微调记不住细节。模型参数不是数据库你把一份制度文档喂进去它学到的是“语气和风格”而不是“第 12 条第 3 款到底写了什么”。你问它具体条款它照样会一本正经地编。第二更新成本太高。今天新出一份通知明天改一条流程你都要重新跑训练这在业务侧根本跟不上。第三溯源做不了。微调后的模型回答“为什么要这样审批”你没法告诉用户这句话出自哪份文件的哪一段出了问题没法追责。所以我最终采用的是检索增强生成这条路线也就是常说的 RAG文档切片存进向量库用户提问时先检索出最相关的几段原文再把原文和问题一起交给模型组织语言。它最大的好处是知识在模型外面——换文档不用重训回答能附出处查错也方便你看到它答歪了直接去看检索出来的是哪几段垃圾就行。2.2 一套能跑起来的四层结构我把整套东西拆成四层这个拆法不是学术分类而是按“出问题的时候我去哪一层找”来划的实践下来排查效率最高。层级承担的角色常见选型出问题时的典型症状文档处理层把各种格式的资料变成干净文本解析库 自写清洗规则答案里出现乱码、页眉页脚、表格错位检索层把问题变成向量并召回相关片段向量库 嵌入模型明明有资料却答“未找到”或召回一堆无关内容生成层基于召回内容组织自然语言回答开源对话模型答得挺流畅但偏离原文或在编应用层权限、对话历史、引用展示、反馈收集自建服务 前端越权看到不该看的文档或历史记录串台为什么把文档处理单独拎成一层因为在我做过的项目里八成的效果问题根源都在这一层。很多人上来就调模型参数、换更大的向量库结果真正的原因是 PDF 里的双栏排版被解析成了交错的两列文字喂进去的全是乱序句子模型再强也救不回来。我现在的习惯是任何新接入的文档类型先人工抽 20 份看解析结果确认没问题再入库。2.3 选型时我实际权衡的几个点模型这块我的建议是先别追最大参数的。企业内部问答的语料通常不算特别复杂一个 7B 到 14B 级别的中文对话模型配合好的检索效果往往比硬上大模型但检索做烂要好。判断标准很朴素拿 30 条真实问题做测试集看回答里“有据可查”的比例。我自己测过一个 7B 模型检索做好之后准确引用率能到八成以上但检索做烂的时候换个 70B 也只到五成出头。向量库的选择上数据量在十万切片以内本地文件型向量库完全够用部署简单、不用运维。真到了百万级再考虑分布式方案。我见过有团队一开始就上集群结果每天切片量还不到一千纯属给自己找运维负担。嵌入模型这块要特别注意中文适配。有些通用多语言模型在中文语义相近的短句上区分度很差导致“报销标准”和“报销流程”这种问题召回混淆。我的做法是准备一组“近似但不同”的问题对专门测嵌入模型的区分能力谁的表现好用谁不完全看榜单。3. 文档处理这一步决定了效果上限3.1 切片策略切多大、怎么切切片这件事听起来简单其实是最容易埋雷的地方。我最初按固定 500 字硬切结果一条完整的审批流程被从中间劈开前半段在切片 A后半段在切片 B用户一问模型只看到“需提交材料如下”材料清单在下一条里回答自然残缺。后来我固定了一套混合策略实测比较稳优先按语义边界切识别标题、编号、段落按“一章一节一条”为单位切宁可大小不均也不要切断语义。设置长度兜底单条超过 800 字再强制拆拆分时保留上一段的最后一句作为上下文前缀。重叠区固定给 15% 左右相邻切片保留一点重叠防止边界信息丢失。给每个切片打元数据来源文件名、章节标题、更新时间、可见范围这些后面检索过滤和引用展示都要用。这里有个细节值得说表格一定要单独处理。制度文件里大量关键信息在表格里比如“职级对应的报销额度”。如果按纯文本切表格会被切成一行行没有表头的数字彻底失去意义。我的做法是把表格转成“表头: 值”这种键值对文本或者干脆整张表作为一个切片并在切片头部补一句“以下为报销额度对照表”。3.2 清洗规则要写得“脏”一点真实的企业文档脏得超乎想象。我接手过一批资料同一份文件里混着三种全半角括号、页眉在每页重复出现、还有扫描件 OCR 出来的错字。清洗规则我一般会做这几件事去掉重复页眉页脚——按行统计出现频次同一行在超过 70% 的页面出现就判为页眉页脚。合并被硬换行打断的句子——中文行尾没有标点且下一行不以数字编号开头就合并。统一标点与空白——全角转半角只针对数字和英文中文标点保留否则会把“。”变成“.”很别扭。剔除目录页和修订记录页——这两类内容对问答几乎无价值还会污染检索。注意清洗不要追求“一步到位全自动”。我的经验是留一个“可疑片段池”把清洗规则命中的内容单独存一份方便回查。有次一条正则把“第 3.2 条”误判成了版本号删掉导致某章节整段缺失就是靠这个池子发现的。3.3 实操一条完整的入库流水线下面这段是我现在常用的处理脚本骨架Python 写的逻辑不复杂但覆盖了大部分场景。这是基于常见实践整理的可复现方案实际参数要按你的文档类型调整。import re, hashlib, json def clean_text(raw: str) - str: # 1) 去掉连续空行 text re.sub(r\n{3,}, \n\n, raw) # 2) 合并中文硬换行行尾无标点 且 下行非编号开头 text re.sub(r([^\n。\d])\n(?![0-9一二三四五六七八九十(]), r\1, text) # 3) 数字与英文的全角转半角 trans {ord(c): ord(c) - 0xFEE0 for c in } return text.translate(trans).strip() def split_by_heading(text: str, max_len: int 800, overlap: int 120): # 按“第X章/第X条/一、/1.”这类标题切分 pattern r(?m)^(第[一二三四五六七八九十百][章节条]|[一二三四五六七八九十]、|\d\.\s) parts, last [], 0 for m in re.finditer(pattern, text): if m.start() last: parts.append(text[last:m.start()]) last m.start() parts.append(text[last:]) chunks [] for p in parts: p p.strip() if not p: continue if len(p) max_len: chunks.append(p) else: # 超长段二次切分保留 overlap 字重叠 for i in range(0, len(p), max_len - overlap): chunks.append(p[i:i max_len]) return chunks def build_record(chunk: str, meta: dict) - dict: return { id: hashlib.md5(chunk.encode()).hexdigest()[:16], text: chunk, meta: meta, # 来源、章节、更新时间、可见范围 tokens: len(chunk), }跑完这条流水线我会做一次抽样自检随机抽 20 个切片打印出来看三件事——开头是不是完整的句子、有没有混进页眉、表格内容是否还能读懂。这个动作花不了十分钟但能省掉后面几天的排查。3.4 一个容易忽略的坑元数据就是权限很多人把元数据当成“备注”其实它是权限控制的基础。我在切片阶段就给每份文档打上“可见部门”和“密级”两个字段检索时先按用户身份过滤再做语义匹配。如果等到生成之后再去过滤那就晚了——模型已经把内容吐出来了。4. 检索层让“找得准”先于“说得好”4.1 为什么纯向量检索经常不够用向量检索擅长“语义相似”但企业内部问题里大量是精确匹配需求某个项目编号、某个产品型号、某个专有名词。这类查询向量化之后反而模糊了容易出现“明明文档里有这个编号却召回了一堆语义相近但不含编号的内容”。我的方案是向量检索 关键词检索双路召回再融合排序。关键词一路用轻量的全文索引就能做专门兜住编号、人名、缩写这类查询。融合的时候不用太复杂我对两路结果做归一化后加权求和通常向量权重给高一点关键词权重保证精确命中能排进前列。还有一个提升很明显的小技巧查询改写。用户问“那个报销的东西怎么弄”这种话直接去检索效果很差。我会先用小模型或规则把它改写成两三个具体查询比如“费用报销流程”“报销所需材料”分别召回后合并去重。这一步做不做召回命中率能差出一截。4.2 切片重排把最该看的放最前面召回结果拿到后别急着塞给模型。上下文窗口有限塞进去十段真正有用的可能就两段剩下八段全是干扰模型反而容易被带偏。我一般会做一个重排步骤用交叉编码类的模型给“问题—切片”逐对打分取前 3 到 5 段。这一步的收益我实测过同一批问题不重排时回答准确率大概六成多加了重排能到八成。代价是延迟增加几百毫秒对内部工具来说完全可以接受。4.3 检索参数怎么定我给个参考区间参数建议区间调整依据单次召回切片数8 到 15少于 8 容易漏多于 15 噪声上升重排后保留3 到 5取决于单切片长度和模型上下文相似度阈值0.3 到 0.45低于阈值直接判“资料未覆盖”宁可说不知道关键词路权重0.2 到 0.4编号类查询多的场景调高相似度阈值这个参数我特别想说一句它的意义不是“提高准确率”而是给系统一个说“不知道”的权利。企业场景里编造答案的代价远大于答不上来。我一般会把阈值调得偏保守宁可多拒答几次让用户知道这块资料还没入库。4.4 实操记录一次召回效果排查上个月有个团队反馈“问报销额度时答案里总是混进差旅标准”。我按四层结构往下查先看切片发现两份文档都被正确入库没问题再看召回问题来了——两份文档里都有“住宿费”“标准”这些词向量相似度几乎一样而差旅那份切片更短打分反而更高。处理方式有三个一是给切片加上“文档标题 章节标题”作为前缀再向量化让语义更明确二是把报销额度表整表作为一个切片提高它的信息密度三是在重排阶段把“额度”“上限”这类关键实体做个加权。三招一起上问题基本解决。这件事让我更确信一点召回不准先看数据形态再谈模型。5. 生成层与应用层把“能答”变成“敢用”5.1 提示词要写成“规章制度”而不是“请求”生成层的提示词我见过太多写成“你是一个乐于助人的助手请回答问题”。这种写法在企业场景里很危险模型会自由发挥。我的写法更接近给新人交代工作核心是四条硬约束你是内部知识助手。只能依据【参考资料】回答禁止使用外部知识。 1. 参考资料未覆盖的问题直接回复“现有资料未包含该内容建议咨询XX”不要推测。 2. 回答涉及具体数字、条款、时限时必须原样引用不得改写。 3. 每个结论后用 [编号] 标注来源编号对应参考资料序号。 4. 如果多份资料存在冲突列出冲突点并提示以最新版本为准。第 2 条是关键。我踩过的坑是模型把“7 个工作日”改写成“一周左右”用户按“一周左右”理解结果误了时限。数字和时限必须禁止改写这条写进提示词后这类问题基本消失。还有一个实用技巧把参考资料用清晰的分隔符包起来并标注序号和来源。格式乱了模型引用的准确率会明显下降。5.2 引用展示让用户自己能验证回答下面附上引用点开能定位到原文段落——这个功能看似小但它决定了用户敢不敢用。我的做法是每个引用卡片显示文档名、章节、片段原文、更新时间。用户一看更新时间是三年前的自己就会判断该不该采信。这里有个细节引用要显示原文不要显示切片。切片可能被截断显示出来是半句话用户会觉得系统不靠谱。我在存储时保留了切片在原文中的偏移量展示时按偏移回取完整段落。5.3 反馈闭环把“答错”变成“资料缺口”我在界面上放了两个按钮有用、没用。点“没用”时要求选原因选项是资料没找到、资料过时、回答不准确、答非所问。这四个选项直接对应我的排查方向——第一个补资料第二个更新版本第三个调提示词第四个查检索。这套机制运行两个月后我发现“资料没找到”占了六成以上。这个数字很有意思它说明大部分时候不是模型不行是知识库还不够全。所以后面我的精力主要放在扩资料上而不是调模型。5.4 权限与审计企业内部绕不开的两件事权限设计我建议在检索前做按用户所属部门和文档可见范围过滤这样模型根本看不到没权限的内容也就不存在“说漏嘴”。审计日志记录四样东西谁问的、问了什么、召回了哪些切片、答了什么。留存周期按你们内部要求来但至少要能回溯最近一个月的问答。注意日志里如果包含用户提问原文要注意脱敏。我见过有人把含身份信息的提问原样落盘后面清理起来很麻烦。6. 常见问题与排查速查6.1 问题速查表现象最可能的原因排查动作明明有资料却答“未找到”切片质量差 / 阈值过高 / 查询表述差异大打印召回结果看是否命中临时降阈值验证答案流畅但内容编造提示词约束太弱 / 召回内容不含答案检查提示词是否有“禁止推测”看召回切片引用编号对不上参考资料格式混乱 / 序号未对齐统一分隔符格式逐条编号回答总是很长很空上下文塞太多无关切片减少重排保留数加“回答不超过 200 字”表格类问题答错表格被切成无表头的行整表入切片或转键值对文本数字被改写提示词未禁止改写数值加入“数字条款原样引用”约束不同部门答案互相污染权限过滤放在生成之后把过滤前移到检索阶段6.2 三个我踩过的坑第一个坑过度追求切片小。早期听说“切片越小检索越准”我把切片压到 200 字结果检索是准了但每段信息都不完整模型被迫在碎片之间猜。后来改成按语义切、允许长短不均效果反而更好。切片的目标不是小是自洽。第二个坑用问答对当训练数据。有段时间我收集了几千条历史问答想直接喂给模型。实际效果是模型学会了“回答的语气”但一遇到新问题就套用旧答案的句式答得似是而非。问答对更适合用来做测试集和评估不适合当知识来源。第三个坑忽略“不知道”的价值。早期为了追求“有问必答”我把拒答阈值调得很低结果用户问了个没入库的问题系统硬凑了个答案用户信了后面出了偏差。这件事之后我把拒答做成了明确的产品行为答不上来就明说并告诉用户该去找谁。6.3 评估怎么做才不流于形式别用“感觉回答得不错”来评估。我的做法是建一个 50 条左右的问题集覆盖三类事实查询某条款是多少、流程查询怎么办、边界问题资料里没有的。每条标注标准答案出处。每次改动后跑一遍统计三个指标召回命中率、引用准确率、拒答正确率。这三个指标里我最看重第三个。因为前两个可以靠调参刷高但拒答正确率反映的是系统“知不知道自己不知道”这直接关系到用户信任。7. 上线之后持续喂养比一次性搭建更重要系统上线只是开始。我维护的几个实例上线第一个月的问题量往往最大因为大家在试探它到底能干什么。这时候最该做的不是改代码而是看日志、补资料。我一般每周花半小时翻一遍“没用”的反馈把高频缺口列出来安排补录。资料更新也要有机制。我的做法是给每份文档打“最后校验时间”超过一定周期没校验的在引用卡片上标一个提示。这样用户看到旧资料时心里有数不会当成最新口径。还有一个容易被忽略的点定期回归测试。向量库扩容、模型换版本、清洗规则调整都可能悄悄影响效果。我习惯每次动完这些把那个 50 条问题集跑一遍指标掉超过五个百分点就回滚。这套流程听起来笨但救过我两次——有一次换了嵌入模型离线榜单分数更高实际召回反而变差全靠回归测试发现。最后分享一个我个人觉得最值钱的经验先把一个部门、一类文档做透再横向铺开。我见过太多项目一上来就想覆盖全公司所有资料结果每个领域都做得半生不熟用户问三次错两次信任直接崩掉。反而是先把“人事制度问答”这一件事做到九成准确让用户真的觉得好用后面再扩到财务、法务推进阻力会小得多。企业内部工具的传播靠的是口碑而口碑只来自“它真的答对过我好几次”。 
长河君 · 2026/10/27 11:17:16 · 阅读 1.2k 企业专属GPT落地：基于RAG的内部知识助手工程实践
1. 先把“企业专属GPT”这件事说透这两年我陆陆续续帮几个团队做过内部知识助手从最开始拿开源模型硬怼到后来摸出一套相对稳定的落地路径踩过的坑比写过的代码还多。现在再有人问我“企业专属GPT”是什么我一般会用一句话解释它不是一个更聪明的聊天机器人而是一个把企业自己的文档、流程、经验沉淀成可被自然语言调用的“内部大脑”。你问它“上个季度的客户投诉主要集中在哪几类”它不该给你编而是去翻内部资料再回答你让它“按我们自己的模板起草一份项目复盘”它得知道“我们自己的模板”长什么样。这件事能解决的问题很具体新人在几百页制度文档里找不到关键条款、老员工的经验只存在脑子里、同一份资料被不同部门反复问、客服回答口径不统一。适合谁来参考我给个不太客气的判断标准——如果你手上连一份像样的内部文档都没有先别做GPT先做文档治理如果你已经有几十上百份结构还算清楚的资料又有个愿意折腾的技术同事那这条路完全走得通。我后面讲的所有内容都基于一个假设你希望在自己的服务器或云主机上跑一套数据不出内网、回答有据可查、能持续喂养新资料的问答系统。这也是“专属”两个字最实在的含义——不是换个皮肤而是数据、知识、口径全都归你自己管。2. 整体架构设计与技术选型思路2.1 为什么我没有选“微调一个模型”这条路刚接触这个需求的人第一反应往往是“我拿内部数据微调一个模型不就行了”。我最早也这么想还认真算过一笔账假设有 5 万条问答对按 3 轮训练、单卡 80G 显存估光训练时间就是十几个小时这还没算标注成本。真正让我放弃的是下面这几个现实问题。第一微调记不住细节。模型参数不是数据库你把一份制度文档喂进去它学到的是“语气和风格”而不是“第 12 条第 3 款到底写了什么”。你问它具体条款它照样会一本正经地编。第二更新成本太高。今天新出一份通知明天改一条流程你都要重新跑训练这在业务侧根本跟不上。第三溯源做不了。微调后的模型回答“为什么要这样审批”你没法告诉用户这句话出自哪份文件的哪一段出了问题没法追责。所以我最终采用的是检索增强生成这条路线也就是常说的 RAG文档切片存进向量库用户提问时先检索出最相关的几段原文再把原文和问题一起交给模型组织语言。它最大的好处是知识在模型外面——换文档不用重训回答能附出处查错也方便你看到它答歪了直接去看检索出来的是哪几段垃圾就行。2.2 一套能跑起来的四层结构我把整套东西拆成四层这个拆法不是学术分类而是按“出问题的时候我去哪一层找”来划的实践下来排查效率最高。层级承担的角色常见选型出问题时的典型症状文档处理层把各种格式的资料变成干净文本解析库 自写清洗规则答案里出现乱码、页眉页脚、表格错位检索层把问题变成向量并召回相关片段向量库 嵌入模型明明有资料却答“未找到”或召回一堆无关内容生成层基于召回内容组织自然语言回答开源对话模型答得挺流畅但偏离原文或在编应用层权限、对话历史、引用展示、反馈收集自建服务 前端越权看到不该看的文档或历史记录串台为什么把文档处理单独拎成一层因为在我做过的项目里八成的效果问题根源都在这一层。很多人上来就调模型参数、换更大的向量库结果真正的原因是 PDF 里的双栏排版被解析成了交错的两列文字喂进去的全是乱序句子模型再强也救不回来。我现在的习惯是任何新接入的文档类型先人工抽 20 份看解析结果确认没问题再入库。2.3 选型时我实际权衡的几个点模型这块我的建议是先别追最大参数的。企业内部问答的语料通常不算特别复杂一个 7B 到 14B 级别的中文对话模型配合好的检索效果往往比硬上大模型但检索做烂要好。判断标准很朴素拿 30 条真实问题做测试集看回答里“有据可查”的比例。我自己测过一个 7B 模型检索做好之后准确引用率能到八成以上但检索做烂的时候换个 70B 也只到五成出头。向量库的选择上数据量在十万切片以内本地文件型向量库完全够用部署简单、不用运维。真到了百万级再考虑分布式方案。我见过有团队一开始就上集群结果每天切片量还不到一千纯属给自己找运维负担。嵌入模型这块要特别注意中文适配。有些通用多语言模型在中文语义相近的短句上区分度很差导致“报销标准”和“报销流程”这种问题召回混淆。我的做法是准备一组“近似但不同”的问题对专门测嵌入模型的区分能力谁的表现好用谁不完全看榜单。3. 文档处理这一步决定了效果上限3.1 切片策略切多大、怎么切切片这件事听起来简单其实是最容易埋雷的地方。我最初按固定 500 字硬切结果一条完整的审批流程被从中间劈开前半段在切片 A后半段在切片 B用户一问模型只看到“需提交材料如下”材料清单在下一条里回答自然残缺。后来我固定了一套混合策略实测比较稳优先按语义边界切识别标题、编号、段落按“一章一节一条”为单位切宁可大小不均也不要切断语义。设置长度兜底单条超过 800 字再强制拆拆分时保留上一段的最后一句作为上下文前缀。重叠区固定给 15% 左右相邻切片保留一点重叠防止边界信息丢失。给每个切片打元数据来源文件名、章节标题、更新时间、可见范围这些后面检索过滤和引用展示都要用。这里有个细节值得说表格一定要单独处理。制度文件里大量关键信息在表格里比如“职级对应的报销额度”。如果按纯文本切表格会被切成一行行没有表头的数字彻底失去意义。我的做法是把表格转成“表头: 值”这种键值对文本或者干脆整张表作为一个切片并在切片头部补一句“以下为报销额度对照表”。3.2 清洗规则要写得“脏”一点真实的企业文档脏得超乎想象。我接手过一批资料同一份文件里混着三种全半角括号、页眉在每页重复出现、还有扫描件 OCR 出来的错字。清洗规则我一般会做这几件事去掉重复页眉页脚——按行统计出现频次同一行在超过 70% 的页面出现就判为页眉页脚。合并被硬换行打断的句子——中文行尾没有标点且下一行不以数字编号开头就合并。统一标点与空白——全角转半角只针对数字和英文中文标点保留否则会把“。”变成“.”很别扭。剔除目录页和修订记录页——这两类内容对问答几乎无价值还会污染检索。注意清洗不要追求“一步到位全自动”。我的经验是留一个“可疑片段池”把清洗规则命中的内容单独存一份方便回查。有次一条正则把“第 3.2 条”误判成了版本号删掉导致某章节整段缺失就是靠这个池子发现的。3.3 实操一条完整的入库流水线下面这段是我现在常用的处理脚本骨架Python 写的逻辑不复杂但覆盖了大部分场景。这是基于常见实践整理的可复现方案实际参数要按你的文档类型调整。import re, hashlib, json def clean_text(raw: str) - str: # 1) 去掉连续空行 text re.sub(r\n{3,}, \n\n, raw) # 2) 合并中文硬换行行尾无标点 且 下行非编号开头 text re.sub(r([^\n。\d])\n(?![0-9一二三四五六七八九十(]), r\1, text) # 3) 数字与英文的全角转半角 trans {ord(c): ord(c) - 0xFEE0 for c in } return text.translate(trans).strip() def split_by_heading(text: str, max_len: int 800, overlap: int 120): # 按“第X章/第X条/一、/1.”这类标题切分 pattern r(?m)^(第[一二三四五六七八九十百][章节条]|[一二三四五六七八九十]、|\d\.\s) parts, last [], 0 for m in re.finditer(pattern, text): if m.start() last: parts.append(text[last:m.start()]) last m.start() parts.append(text[last:]) chunks [] for p in parts: p p.strip() if not p: continue if len(p) max_len: chunks.append(p) else: # 超长段二次切分保留 overlap 字重叠 for i in range(0, len(p), max_len - overlap): chunks.append(p[i:i max_len]) return chunks def build_record(chunk: str, meta: dict) - dict: return { id: hashlib.md5(chunk.encode()).hexdigest()[:16], text: chunk, meta: meta, # 来源、章节、更新时间、可见范围 tokens: len(chunk), }跑完这条流水线我会做一次抽样自检随机抽 20 个切片打印出来看三件事——开头是不是完整的句子、有没有混进页眉、表格内容是否还能读懂。这个动作花不了十分钟但能省掉后面几天的排查。3.4 一个容易忽略的坑元数据就是权限很多人把元数据当成“备注”其实它是权限控制的基础。我在切片阶段就给每份文档打上“可见部门”和“密级”两个字段检索时先按用户身份过滤再做语义匹配。如果等到生成之后再去过滤那就晚了——模型已经把内容吐出来了。4. 检索层让“找得准”先于“说得好”4.1 为什么纯向量检索经常不够用向量检索擅长“语义相似”但企业内部问题里大量是精确匹配需求某个项目编号、某个产品型号、某个专有名词。这类查询向量化之后反而模糊了容易出现“明明文档里有这个编号却召回了一堆语义相近但不含编号的内容”。我的方案是向量检索 关键词检索双路召回再融合排序。关键词一路用轻量的全文索引就能做专门兜住编号、人名、缩写这类查询。融合的时候不用太复杂我对两路结果做归一化后加权求和通常向量权重给高一点关键词权重保证精确命中能排进前列。还有一个提升很明显的小技巧查询改写。用户问“那个报销的东西怎么弄”这种话直接去检索效果很差。我会先用小模型或规则把它改写成两三个具体查询比如“费用报销流程”“报销所需材料”分别召回后合并去重。这一步做不做召回命中率能差出一截。4.2 切片重排把最该看的放最前面召回结果拿到后别急着塞给模型。上下文窗口有限塞进去十段真正有用的可能就两段剩下八段全是干扰模型反而容易被带偏。我一般会做一个重排步骤用交叉编码类的模型给“问题—切片”逐对打分取前 3 到 5 段。这一步的收益我实测过同一批问题不重排时回答准确率大概六成多加了重排能到八成。代价是延迟增加几百毫秒对内部工具来说完全可以接受。4.3 检索参数怎么定我给个参考区间参数建议区间调整依据单次召回切片数8 到 15少于 8 容易漏多于 15 噪声上升重排后保留3 到 5取决于单切片长度和模型上下文相似度阈值0.3 到 0.45低于阈值直接判“资料未覆盖”宁可说不知道关键词路权重0.2 到 0.4编号类查询多的场景调高相似度阈值这个参数我特别想说一句它的意义不是“提高准确率”而是给系统一个说“不知道”的权利。企业场景里编造答案的代价远大于答不上来。我一般会把阈值调得偏保守宁可多拒答几次让用户知道这块资料还没入库。4.4 实操记录一次召回效果排查上个月有个团队反馈“问报销额度时答案里总是混进差旅标准”。我按四层结构往下查先看切片发现两份文档都被正确入库没问题再看召回问题来了——两份文档里都有“住宿费”“标准”这些词向量相似度几乎一样而差旅那份切片更短打分反而更高。处理方式有三个一是给切片加上“文档标题 章节标题”作为前缀再向量化让语义更明确二是把报销额度表整表作为一个切片提高它的信息密度三是在重排阶段把“额度”“上限”这类关键实体做个加权。三招一起上问题基本解决。这件事让我更确信一点召回不准先看数据形态再谈模型。5. 生成层与应用层把“能答”变成“敢用”5.1 提示词要写成“规章制度”而不是“请求”生成层的提示词我见过太多写成“你是一个乐于助人的助手请回答问题”。这种写法在企业场景里很危险模型会自由发挥。我的写法更接近给新人交代工作核心是四条硬约束你是内部知识助手。只能依据【参考资料】回答禁止使用外部知识。 1. 参考资料未覆盖的问题直接回复“现有资料未包含该内容建议咨询XX”不要推测。 2. 回答涉及具体数字、条款、时限时必须原样引用不得改写。 3. 每个结论后用 [编号] 标注来源编号对应参考资料序号。 4. 如果多份资料存在冲突列出冲突点并提示以最新版本为准。第 2 条是关键。我踩过的坑是模型把“7 个工作日”改写成“一周左右”用户按“一周左右”理解结果误了时限。数字和时限必须禁止改写这条写进提示词后这类问题基本消失。还有一个实用技巧把参考资料用清晰的分隔符包起来并标注序号和来源。格式乱了模型引用的准确率会明显下降。5.2 引用展示让用户自己能验证回答下面附上引用点开能定位到原文段落——这个功能看似小但它决定了用户敢不敢用。我的做法是每个引用卡片显示文档名、章节、片段原文、更新时间。用户一看更新时间是三年前的自己就会判断该不该采信。这里有个细节引用要显示原文不要显示切片。切片可能被截断显示出来是半句话用户会觉得系统不靠谱。我在存储时保留了切片在原文中的偏移量展示时按偏移回取完整段落。5.3 反馈闭环把“答错”变成“资料缺口”我在界面上放了两个按钮有用、没用。点“没用”时要求选原因选项是资料没找到、资料过时、回答不准确、答非所问。这四个选项直接对应我的排查方向——第一个补资料第二个更新版本第三个调提示词第四个查检索。这套机制运行两个月后我发现“资料没找到”占了六成以上。这个数字很有意思它说明大部分时候不是模型不行是知识库还不够全。所以后面我的精力主要放在扩资料上而不是调模型。5.4 权限与审计企业内部绕不开的两件事权限设计我建议在检索前做按用户所属部门和文档可见范围过滤这样模型根本看不到没权限的内容也就不存在“说漏嘴”。审计日志记录四样东西谁问的、问了什么、召回了哪些切片、答了什么。留存周期按你们内部要求来但至少要能回溯最近一个月的问答。注意日志里如果包含用户提问原文要注意脱敏。我见过有人把含身份信息的提问原样落盘后面清理起来很麻烦。6. 常见问题与排查速查6.1 问题速查表现象最可能的原因排查动作明明有资料却答“未找到”切片质量差 / 阈值过高 / 查询表述差异大打印召回结果看是否命中临时降阈值验证答案流畅但内容编造提示词约束太弱 / 召回内容不含答案检查提示词是否有“禁止推测”看召回切片引用编号对不上参考资料格式混乱 / 序号未对齐统一分隔符格式逐条编号回答总是很长很空上下文塞太多无关切片减少重排保留数加“回答不超过 200 字”表格类问题答错表格被切成无表头的行整表入切片或转键值对文本数字被改写提示词未禁止改写数值加入“数字条款原样引用”约束不同部门答案互相污染权限过滤放在生成之后把过滤前移到检索阶段6.2 三个我踩过的坑第一个坑过度追求切片小。早期听说“切片越小检索越准”我把切片压到 200 字结果检索是准了但每段信息都不完整模型被迫在碎片之间猜。后来改成按语义切、允许长短不均效果反而更好。切片的目标不是小是自洽。第二个坑用问答对当训练数据。有段时间我收集了几千条历史问答想直接喂给模型。实际效果是模型学会了“回答的语气”但一遇到新问题就套用旧答案的句式答得似是而非。问答对更适合用来做测试集和评估不适合当知识来源。第三个坑忽略“不知道”的价值。早期为了追求“有问必答”我把拒答阈值调得很低结果用户问了个没入库的问题系统硬凑了个答案用户信了后面出了偏差。这件事之后我把拒答做成了明确的产品行为答不上来就明说并告诉用户该去找谁。6.3 评估怎么做才不流于形式别用“感觉回答得不错”来评估。我的做法是建一个 50 条左右的问题集覆盖三类事实查询某条款是多少、流程查询怎么办、边界问题资料里没有的。每条标注标准答案出处。每次改动后跑一遍统计三个指标召回命中率、引用准确率、拒答正确率。这三个指标里我最看重第三个。因为前两个可以靠调参刷高但拒答正确率反映的是系统“知不知道自己不知道”这直接关系到用户信任。7. 上线之后持续喂养比一次性搭建更重要系统上线只是开始。我维护的几个实例上线第一个月的问题量往往最大因为大家在试探它到底能干什么。这时候最该做的不是改代码而是看日志、补资料。我一般每周花半小时翻一遍“没用”的反馈把高频缺口列出来安排补录。资料更新也要有机制。我的做法是给每份文档打“最后校验时间”超过一定周期没校验的在引用卡片上标一个提示。这样用户看到旧资料时心里有数不会当成最新口径。还有一个容易被忽略的点定期回归测试。向量库扩容、模型换版本、清洗规则调整都可能悄悄影响效果。我习惯每次动完这些把那个 50 条问题集跑一遍指标掉超过五个百分点就回滚。这套流程听起来笨但救过我两次——有一次换了嵌入模型离线榜单分数更高实际召回反而变差全靠回归测试发现。最后分享一个我个人觉得最值钱的经验先把一个部门、一类文档做透再横向铺开。我见过太多项目一上来就想覆盖全公司所有资料结果每个领域都做得半生不熟用户问三次错两次信任直接崩掉。反而是先把“人事制度问答”这一件事做到九成准确让用户真的觉得好用后面再扩到财务、法务推进阻力会小得多。企业内部工具的传播靠的是口碑而口碑只来自“它真的答对过我好几次”。