不少团队在内部搞“企业专属GPT”这件事上第一版通常死得很安静。我见过一个很典型的场景某公司花了两个月把内部知识做成问答助手推给全员上线第一周大家图新鲜问了上百个问题第三周访问量掉了一大半一个月后基本没人打开。事后复盘答案不是“模型不够强”而是三个很朴素的原因——问“年假怎么算”它引用了一份已经作废的旧制度问“某个项目现在的对接人是谁”它一本正经地编了一个名字问“这份合同有没有风险条款”它给了三段听起来很专业但没有出处的分析。这就是我想聊“如何构建企业专属GPT”的起点。这里的“专属”不是给模型换个名字、塞一段提示词那么简单它意味着这个助手知道你们公司的事、用你们公司的说法、在你们公司的规则边界内说话并且在不知道的时候敢于承认不知道。它要解决的问题是把散落在共享盘、邮件、工单系统、会议纪要里的组织记忆变成一个人人可问、答案可追溯的服务。适合看这篇的人大概是这几类被老板点名要“搞个AI助手”的技术负责人、正在做RAG原型但效果不稳定的工程师、以及想评估这条路到底值不值得投入的产品同学。下面这份内容是我自己从零到一带过几个内部助手项目之后觉得真正会踩坑、真正需要提前想清楚的环节。1. 拆开“专属”这两个字企业掏钱到底在买什么先把需求收敛不然技术选型一定会飘。企业内部想让“专属GPT”干的活粗分下来就三类每一类背后的技术重点完全不同混在一起做就会变成四不像。1.1 信息不对称型把“找不到”变成“问得到”这是绝大多数项目的起点。规章制度、产品手册、历史项目文档、常见故障处理手册、售后FAQ这些内容的共同点是存在但没人愿意翻。新人入职三个月还在群里问“报销流程在哪”老员工也记不住两年前那份接口规范放在哪个目录。这类需求的本质是检索问题不是生成问题。模型在这里的角色是“把检索到的原文用人话复述一遍”它自己不需要掌握任何业务知识。想清楚这一点很关键因为它直接决定了你后面应该在切块、索引、召回上砸时间而不是急着去微调模型。我见过一个反例某团队为了“让模型更懂公司业务”拿几百份内部文档去做了微调结果模型把文档里的某些具体数字记串了回答时把A产品的保修期说成了B产品的。这种错误比“不知道”危险得多因为它带着模型的自信。信息型需求走微调收益极低、风险极高。1.2 流程重复型把“每次重写一遍”变成“套模板”第二类是格式化输出把会议录音整理成纪要、把工单内容改写成客户可读的回执、把零散的技术变更整理成上线说明、把一段需求描述扩写成测试用例。这类任务的特点是输入结构相对固定、输出格式有明确要求、对事实准确性的要求低于对格式和语气的准确性。流程型需求才是微调真正的主场。因为你要的是“风格”和“格式”的稳定复现而不是“事实”的注入。用少量高质量样本做一次轻量微调能让输出稳定性提升一大截尤其是当你的输出格式比较特殊比如公司内部有一套固定的周报模板、有一套特殊的工单分类标签体系时靠提示词硬掰往往掰不干净模型总会漏字段或者自创格式。1.3 判断辅助型把“人肉比对”变成“先给一版初筛”第三类最诱人也最容易翻车合同条款比对、报表异常解释、投标文件合规性初筛、代码变更的风险提示。这类需求的共同点是答案不是“有或者没有”而是一个需要专业判断的结论。我的建议很明确这类场景可以做但产品定位必须是“初筛”而不是“结论”。界面上要明确写“以下为机器初筛结果需人工复核”输出必须带原文定位。技术上它依然是检索加生成但提示词里要强制模型逐条列出依据并且给出“未发现”和“无法判断”的区分。把这类功能包装成“AI帮你审合同”短期演示很爽长期一定会因为一次漏判而失去信任。需求类型典型场景技术重心微调必要性主要风险信息不对称型制度问答、故障手册查询切块质量、混合检索、重排低引用过期文档、张冠李戴流程重复型会议纪要、工单改写、周报生成提示词模板、轻量微调中到高格式漂移、漏字段判断辅助型条款比对、异常解释逐条溯源、拒答机制低过度自信、漏判2. 语料治理从共享盘里的Word到能检索的知识块这一步是决定成败的分水岭也是最枯燥、最容易被跳过的一步。我的经验是一个企业问答助手最终效果的天花板80%在语料治理阶段就已经定死了后面调模型、调提示词都只是在这个天花板下面挪腾。2.1 先做减法哪些文档压根不该进库新人上手第一反应是“全量导入”把能爬到的文档一股脑塞进去。这个做法几乎必然失败原因有两个一是噪声会淹没信号二是过期内容会污染答案。导入前必须做一轮人工加规则的筛选。我在实际操作中会先划三条线第一只保留当前有效的版本历史版本单独存一个归档库默认不参与检索只在用户明确问“以前是怎么规定的”时才放开第二剔除过程性文档比如各种会议记录草稿、汇报PPT的中间版本这类内容语义模糊、结论未定检索出来只会误导第三剔除纯数据表格而无说明的附件除非你专门为它做了结构化处理。还有一个容易被忽略的点权限。文档在导入前就要打上部门和密级标签因为检索阶段必须做权限过滤。如果你打算上线后再补权限那基本等于重做一遍索引。这件事一定要在第一天就定好字段。2.2 切块不是按字数切那么简单切块chunking直接决定检索粒度。切太大一个块里混了三四个主题向量表示被稀释召回不准切太小一句话被切碎语义不完整模型拿到也没法用。中文场景下我常用的起点是正文类文档按 300 到 600 字一个块重叠 10% 到 15%。重叠的作用是防止关键信息正好落在切口上被劈成两半。但这个数字只是起点真正要按文档结构调有明显标题层级的文档制度、手册、产品说明书优先按标题切把标题路径作为元数据带上比如“第三章 报销管理 3.2 差旅住宿标准”检索命中后模型看到的上下文自带层级回答准确率会明显提升。没有结构的文档聊天记录、纯文本纪要才退回按字数切。表格是最麻烦的。我的处理方式是小表格转成 Markdown 保留在块里大表格单独拆成“一行一记录”的形式把表头拼到每一行前面比如“产品型号X200 | 保修期24个月 | 适用区域境内”。这样每一行都能被独立检索到而不是整张表作为一个巨块。扫描件和图片必须走 OCR这一步别省钱。OCR 质量差的语料进来后面所有环节都在为它买单检索出一堆乱码模型只能瞎编。2.3 元数据是检索质量的一半很多人只关注文本内容忽略元数据这是很大的浪费。我建议每个块至少带这几类字段来源信息文件名、章节路径、页码或段落号用于生成引用时间信息文档生效日期、最后更新时间用于排序和过期判断归属信息所属部门、适用人群、业务线密级信息公开、内部、受限用于权限过滤时间字段的价值特别大。同样一个问题检索到两份内容矛盾的文档按更新时间降序排把新的放前面很多“答错”问题就这么解决了。我在一个项目里加了这个排序规则之后制度类问题的准确率肉眼可见地上升而成本只是加了一个字段。3. 路线选型检索增强、参数微调、提示词工程三者的真实边界技术路线上最常见的误会是把“微调”当成“灌输知识”的手段。这个误会代价很高值得单独掰扯清楚。3.1 检索增强解决“知道什么”微调解决“怎么说”大模型的知识存在参数里但这份参数化记忆有三个毛病不可靠同一个事实可能在不同上下文下给出不同答案、不可控你没法精确指定它记住哪一句、不可更新改一条制度要重训一次成本离谱。所以凡是“会变的事实”都不应该指望微调。检索增强的逻辑正好相反知识留在外部库里每次提问现查现用。好处是更新即时改文档就行、可追溯能给出处、可控不相关的可以不召回。代价是每次请求多了一次检索开销以及依赖检索质量。那微调干什么用我的经验是微调主要改“行为”不改“知识”。它能显著改善的是输出格式的稳定性、语气的一致性、特定任务的指令遵循度比如“永远按‘结论—依据—建议’三段式回答”“永远输出 JSON 且字段名严格按给定 schema”“永远用客服口吻不使用第一人称”。3.2 什么时候值得上微调判断标准很简单如果你发现自己在提示词里反复加同一段约束而且模型遵守率还是不稳定那就是微调的信号。反过来说如果提示词里塞到两三千字还能稳定遵守就别折腾微调维护成本不划算。如果决定做起步规模不用大。我参与过的几个项目任务类微调的数据量都在几百到两千条这个区间用的是 LoRA 这类低秩适配方式只训练一小部分附加参数不动机础权重好处是显存占用低、训练快、可以给不同业务线各挂一个适配器切换成本很低。数据质量远比数量重要。一千条格式规范、答案确切的样本效果远好过一万条从系统里导出的脏数据。我通常会这样构造先用当前最好的提示词跑一遍真实问题把输出人工改到满意改完的问答对就是训练样本。这个过程顺带还能把提示词的短板暴露出来。3.3 一张表把选型说清楚你遇到的问题优先方案为什么不选另一个模型不知道公司制度检索增强微调难以精确注入且制度会变模型答公司制度时引用旧版本检索增强 时间元数据排序微调无法解决版本时效输出格式总是不对、漏字段提示词 少量微调纯提示词在复杂格式上遵守率不稳语气太“AI”不像公司客服微调风格样本检索对此毫无帮助回答太长、抓不住重点提示词约束 输出结构模板微调成本高于收益专业术语老是说错检索增强术语库 提示词微调可以但更新麻烦4. 检索链路把“找得准”拆成四道工序大部分“RAG 效果不好”的问题追到根上都是检索没做好。模型拿到一堆不相关的片段再强也只能编。这条链路我一般拆成四步查询改写、混合召回、重排过滤、上下文拼装。每一步都有具体可调的旋钮。4.1 查询改写用户那句口语不是检索语句真实用户的提问往往极短、指代多、带口语。“那个报销的怎么弄”“上次说的那个流程”“这个能不能过”——这类问题直接拿去做向量检索命中率会惨不忍睹。我常用的三个处理动作指代消解。多轮对话里把“它”“这个”“那个”还原成具体名词。这一步靠把最近两三轮对话一起喂给模型做改写输出一个自包含的检索语句。成本很低收益很明显。关键词抽取。让模型从问题里抽出实体和术语尤其是公司内部的黑话和简称。内部简称往往在嵌入模型那里表示很弱但对关键词检索很有效。多查询扩展。把一个问题改写成两到三个不同角度的检索语句分别召回再合并。比如“出差住宿标准”可以扩展成“差旅费 住宿 上限”“员工出差 酒店 报销额度”。这会增加检索开销但召回率提升通常值这个钱。4.2 混合召回向量和关键词谁也替代不了谁只走向量检索是新手最常见的配置问题在于向量对“精确字符串”不敏感。产品型号、合同编号、错误码、人名这些内容在向量空间里经常糊成一团反而是传统的关键词检索BM25 这类基于词频的算法一击即中。所以生产环境我基本都用混合召回向量检索取 Top 20 到 50关键词检索取 Top 20 到 50然后用倒数排名融合RRF把两路结果合并。RRF 的公式很朴素就是每个文档的得分等于它在各路排名倒数之和常数项一般取 60score(d) Σ 1 / (k rank_i(d))k 通常取 60它的好处是不需要关心两路分数量纲不一致的问题只看排名实现简单且稳定。融合之后取前 20 到 30 条进入下一步。4.3 重排与阈值宁可说“不知道”也别硬编召回阶段追求的是“不漏”重排阶段追求的是“准”。做法是把召回的候选片段和问题一起送进一个重排模型逐条打相关性分数按分数重排然后卡一个阈值。阈值这块我要多说两句因为它是最容易被忽略、又最能提升体验的参数。相似度低于某个值的片段直接丢弃不要硬塞给生成模型。塞进去的后果是模型被迫从一堆不相关的内容里“找话说”幻觉率飙升。阈值定多少要实测。常见的余弦相似度区间在 0.35 到 0.45 之间作为起点但不同嵌入模型的分布差异很大必须在自己的评测集上跑一遍看召回率和准确率的平衡点在哪。我的做法是画一条曲线横轴是阈值纵轴分别是“正确回答率”和“拒答率”找一个正确率还不错、拒答率可接受的拐点。还有一个技巧如果一个片段都没过阈值不要让模型自由发挥直接返回兜底话术并把问题记进“未命中日志”。这份日志是后续补语料的黄金材料我每个项目都会盯着它看看用户到底在问什么我们没覆盖到的东西。4.4 上下文拼装位置、去重、引用一个都不能少拼上下文看起来只是把片段拼起来其实有不少讲究。数量塞太多片段是有害的模型注意力会被稀释还容易把不同片段的信息混在一起。我一般控制在 3 到 6 个片段每个 600 到 800 token总上下文预算控制在模型窗口的 30% 到 50%剩下的留给对话历史和输出。顺序把重排分数最高的放在最前面和最后面中间放次相关的。这是利用了模型对首尾位置更敏感的特点实测能提升一点引用准确率。去重相邻块因为有重叠内容会重复重复内容会让模型误以为某个信息特别重要。简单的做法是对文本做相似度去重超过 0.9 的丢掉。引用标注在每个片段前面加编号和来源标记比如[1] 来源差旅管理制度 2024版 3.2然后在提示词里要求模型引用编号。这一步是后面做可追溯的基础千万别省。用户看到答案下面挂着“依据[2]”信任度是完全不一样的。5. 提示词与输出护栏让回答能追溯、能拒答模型本身没有“我不知道”的自觉它会顺着你的问题往下编。护栏的作用就是在提示词层面把它摁住。5.1 系统提示的结构化写法我习惯把系统提示分成五段顺序固定角色与边界、可用材料说明、回答规则、输出格式、兜底策略。分散着写效果很差模型容易顾此失彼。你是某公司的内部知识助手服务对象是公司员工。 你只能依据【参考资料】中的内容回答不得使用参考资料之外的知识。 如果参考资料不足以回答必须明确说明现有资料中未找到相关内容并建议用户联系对应部门。 回答规则 1. 每个结论后标注依据编号格式为 [编号] 2. 涉及金额、期限、比例等数字必须原样引用不得换算或估算 3. 参考资料之间存在冲突时优先采用发布时间较新的那份并说明存在版本差异 4. 不得对制度条款做扩展解释不得给出法律或合规建议 输出格式 - 先用一句话给出结论 - 再分条列出依据 - 最后列出引用的资料编号与标题 【参考资料】 {context}这段提示词里有几个点值得说。第一“只能依据参考资料”这句话必须放在最前面位置靠后会被稀释。第二“不得换算或估算”这条是吃过亏之后加的——早期模型会把“24个月”自动说成“两年”遇到按月份计算的场景就错了。第三冲突优先取新版这条规则配合前面的时间元数据排序能挡掉很大一部分版本矛盾问题。5.2 拒答不是失败是功能产品侧要把拒答当正例来设计而不是当 bug。我在界面上会明确区分三种状态找到答案、部分找到提示可能不完整、未找到给出可联系的部门或可提交的反馈入口。第三种状态配上“一键反馈”用户点一下就能把问题提交给知识维护人形成闭环。数据上也要监控拒答率。拒答率突然升高通常是索引出问题或者某批文档失效了拒答率长期为零反而要警惕说明模型可能在无差别硬答需要抽查。5.3 输出内容的二次校验生成完之后加一层轻量校验成本不高但很有用。常见规则包括答案里出现的数字是否能在引用片段中原样找到引用的编号是否真实存在于本次上下文中输出长度是否超限是否包含不该出现的敏感字段。这层校验不需要模型正则加字符串匹配就能覆盖大部分场景。命中异常就降级返回“已找到相关资料但自动校验未通过请查看原文”并把原文链接给出来。这种降级体验比给出一个错误答案要好得多。6. 评测没有评测集效果好坏全靠玄学这是我最想强调的一章。没有评测集的项目迭代过程就是几个人凭感觉说“好像好了一点”然后陷入无休止的调参。做评测集不难难的是下决心开始做。6.1 冷启动阶段怎么凑出第一批问题不用等系统上线。项目一开始就可以去找一线同事要问题客服要真实工单标题人事要真实咨询记录技术支持要真实提问。一个下午能收集到一两百条。我一般会要 150 到 300 条覆盖不同业务线然后人工标注每条的标准答案和应该引用的文档片段。这份数据不需要完美但必须真实。自己坐在工位上想出来的问题和用户真问的问题差距大到超出想象。真实问题往往短、口语、信息不全这正是难的地方。6.2 三个层次的指标分开看我不建议只盯一个“准确率”它太粗了出了问题找不到原因。分开看三个层次层次指标怎么算参考目标检索层Top-5 召回率标准答案所在片段是否出现在前 5 条85% 以上生成层忠实度答案中的论断是否都能在引用片段中找到支撑90% 以上生成层拒答正确率无答案的问题是否被正确拒答80% 以上体验层有用性评分人工 1 到 5 分打分平均 4 分以上检索层和生成层要分开评因为它们的优化手段完全不同。召回率低就去改切块和混合检索召回率够但忠实度低就去改提示词和重排阈值。混在一起调等于蒙眼打靶。忠实度这一项可以半自动化让另一个模型逐句判断“这句话能否在给定片段里找到依据”人工抽检 10% 校准。这样评测可以高频跑不至于每改一版都靠人工。6.3 把评测变成回归测试评测集建好之后最重要的事情是把它固化进流水线。每次改切块策略、换嵌入模型、调提示词、升模型版本都跑一遍输出对比报告。这件事的价值在一次模型升级时体现得淋漓尽致。我们当时把一个底层模型换了新版本主观感觉“回答更流畅了”但回归测试一跑制度类问题的忠实度掉了 6 个点——新模型更倾向于“总结归纳”会把原文的限定条件吃掉。如果没有回归测试这个问题可能要等用户投诉才会暴露。提示评测集要定期更新。业务变了、文档变了老问题的标准答案也会变。我一般每个季度补 20 到 30 条新问题同时把已经失效的老问题标注归档避免评测结果失真。7. 上线之后成本、延迟、权限与知识漂移的真实账本Demo 跑通和真正上线之间还隔着一堆工程问题。这一章讲的就是那些演示时看不见、上线后天天找你的东西。7.1 成本结构拆开看钱花在哪企业助手的成本主要三块模型调用、检索服务、语料维护人力。前两块是显性的第三块最容易被低估。模型调用这块优化空间主要在上下文长度。很多人习惯把 Top 10 全塞进去实际有效信息可能只有 3 条。把重排阈值卡严、片段数压到 5 条以内token 消耗能降一半以上效果反而更好。另外一个省钱手段是缓存高频问题比如“年假怎么算”在内部一定是重复被问的把问题和答案缓存起来命中直接返回能省下相当可观的调用量。语义缓存要注意相似度阈值别设太松否则会把不同问题误判成同一个。检索服务的成本相对固定主要看索引规模和查询并发。索引重建是重活别放在业务高峰期做。人力成本这块我得直说语料维护是一个长期投入不是一次性工程。制度更新、产品迭代、组织调整都会让索引里的内容过期。如果没有明确的知识维护责任人这个助手会在半年内自然衰亡。我建议在上线时就指定每个业务域的“知识 owner”把文档更新和索引重建绑进他们的常规流程。7.2 延迟用户能忍多久内部工具的可接受延迟比公有产品宽松但超过 5 秒使用意愿就会明显下滑。优化的几个动作按性价比排序第一流式输出。哪怕实际总耗时没变首字返回时间从 4 秒降到 1 秒主观感受完全不同。这个改动通常只需要前端配合成本最低。第二检索并行。向量检索和关键词检索同时发别串行。多查询扩展的几个查询也并行发。第三把重排模型和生成模型的调用链路理顺避免不必要的串行等待。第四缓存。刚才说过的高频问题缓存对延迟的改善比成本更明显。第五如果 QPS 上来了考虑把推理服务独立部署做批处理调度比逐条调用效率高得多。7.3 权限过滤必须在检索阶段做这一点是硬要求。检索结果返回前必须按用户身份过滤掉无权访问的片段而不是生成完了再脱敏。因为一旦无权限内容进入了模型上下文它就可能以各种变形出现在输出里事后过滤根本拦不住。实现上每个语料块带上部门标签和密级标签检索时把用户身份转成过滤条件在向量检索的元数据过滤里直接生效。同时要留审计日志谁在什么时候问了什么、命中了哪些文档、返回了什么。这份日志在出问题时是唯一的排查依据。7.4 知识漂移索引不会自己保持新鲜语料是会腐烂的。制度改版、产品下线、组织架构调整索引里的内容就变成“历史遗迹”。用户问到一个已经失效的流程模型照着旧文档答得头头是道这是最伤信任的失败模式。我的处理办法有三条。一是给每份文档设“有效期”字段过期文档在检索时降权或直接排除同时通知 owner 更新。二是定期跑一次“孤儿文档”检查找出长时间没被任何查询命中的文档人工判断是没人问还是检索不到。三是把用户反馈闭环接进来点“这个回答不对”的问题自动进待处理队列。这几件事听起来琐碎但它们决定了这个助手在第三个月还有没有人用。技术方案能解决“能不能答”运营机制才解决“答得对不对”。最后分享一个我自己踩过的坑早期我特别执着于把准确率从 78% 推到 85%花了很多时间调重排和提示词。后来发现用户真正抱怨的不是那 7 个百分点而是“答错了还特别自信”。把拒答机制和引用展示做扎实之后即使准确率只涨了 2 个点满意度却上了一个台阶。做这类工具让人知道什么时候该信它比让它显得无所不知重要得多。