业务事实该放哪里？先别急着微调模型

把公司资料拿去微调模型，听起来是在给 AI 补知识，作者却认为，这很像把价格写死进编译后的程序：更新要重新发布，出错难追来源，也不好控制谁能读取。对会变化、要追溯的业务事实，这通常不是合适的存放方式。

作者在 Null Studio 为客户开发 AI 功能，提出了一条实用路线：先做评估，再改提示词，按需加检索、换模型，最后才考虑微调。不过，他自己的 9 个语音代理都没用检索。这个看似矛盾的例子，恰好讲清了真正的判断标准。

提示词、检索和微调，分别该放什么

作者把三种方案比作配置、数据库和编译后的代码。这个类比的价值，是把「要不要训练 AI」转成程序员熟悉的问题：一份信息应该存在哪里，才能方便更新、检查和管理？

提示词（Prompt）像配置。角色、语气、规则、输出格式和示例，都可以放在这里。改完后，下一次请求就能使用新规则，回退也容易。很多看起来需要训练的问题，可能只是指令含糊、缺少示例，或者没有明确规定输出结构。

检索增强生成（RAG）像数据库查询：先从自己的内容中找出相关段落，再连同问题交给模型。文档提供事实，模型负责组织答案。营业时间变了，更新资料即可；需要追溯时，可以展示引用；不同用户能看什么，也可以在查询阶段控制。

微调（Fine-tuning）则通过输入与期望输出的样例，改变模型倾向采用的回答模式。它适合固定分类、严格格式、难以用规则描述的风格，也可能让更小、更便宜的模型完成某个狭窄任务。

问题在于，学过一条事实，不等于能可靠地查出它。模型可能复现训练内容，也可能生成一条听起来相似却错误的信息，输出本身无法证明是哪一种。

微调更适合塑造行为，持续变化的业务事实应优先留在可编辑、可追溯的数据里。

事实进入权重后，改价格可能要重新训练、测试和部署；答错时，也很难定位到某条训练数据。把受限信息训练进去，还会失去按用户权限查询的控制位置。系统提示词里的「不要透露」不能充当安全边界。

为什么他的 9 个代理都把事实放在提示词里

作者检查了从 Retell 导出的客户语音代理，发现全部 9 个都有 knowledge_base_ids: []，没有使用检索。它们把业务资料写在提示词的 ## Context 部分。

其中一个牙科诊所代理，直接列出服务项目、每天的营业时间、地址和电话号码，诊所名称通过 COMPANY_NAME 动态变量传入。

这并不推翻前面的原则。对小商家来说，全部资料只有几百词，放进提示词也装得下；内容是团队能直接编辑的纯文本，保存代理后即可生效。它仍然具备配置的可维护性，没有被压进模型权重。

因此，「事实都应该进检索」更像默认方向，不是要求每个项目都搭一套 RAG。

真正需要检索的时刻，是资料开始超出提示词适合承载的范围：商品目录很大、政策手册很长、不同地区适用不同规则，或者不同来电者只能查看不同内容。此时，检索增加的复杂度才有明确回报。

作者举了 Fortell AI 的多语言语音与 SMS 接入系统。它服务于 Community Action Agencies，覆盖超过 100 种语言，需要依据实际项目规则回答。作者认为，这些规则应该放在团队可更新的内容中，不能靠不断加长提示词来承载。原文没有给出该系统的检索实现或效果数据，不能据此推断具体技术方案。

产品里的其他任务，也可以按这个思路拆开。LectureNotes AI 记录讲座并生成摘要、提纲，忠实性来自对转写文本的依据，结构一致性先靠提示词解决。Lifemaxxing AI 的个性化计划，则使用请求时传入的用户数据，不需要为每个用户训练一个模型。

微调应该解决已经测出来的缺口

作者给出的工作顺序，起点不是选模型，而是建立评估集：使用真实输入，定义什么结果算通过。否则，提示词改得再复杂，也无法判断是否真的进步。

接着修改提示词，补充示例、结构和规则，再测一次。涉及内部资料时加入检索，继续测。作者的经验是，这一步的不少质量问题来自重复、过期或缺失的文档，未必来自模型。演示效果好，也可能只是因为有人提前挑好了资料。

之后可以尝试其他模型。有些能力差距，通过换模型就能补上，不需要承担训练的维护成本。

只有上述方案仍留下明确缺口，才考虑微调，并设定目标分数，与未微调方案比较。它比较适合任务狭窄、重复量大、提示词稳定性不足的情况，例如自定义消息分类、按固定形状抽取字段，或模仿容易展示却难以描述的风格。

另一个动机是成本和延迟：让较小模型在单项任务上接近较大模型，对电话场景尤其有吸引力。但这是候选方向，原文没有提供节省比例或延迟对照。

数据门槛也不能忽略。作者提出，需要数百组或更多高质量输入输出对，并由懂业务的人审核。这个数量不是成功保证；小而混乱的数据集，可能只是让模型更稳定地学会混乱。

训练费用之外，还要计算样例收集、清洗和专家审核，基础模型更新或退役后的重建与复测，供应商绑定，训练数据的处理方式，以及持续维护评估集的成本。

而且，这几种方式可以叠加。微调模型仍然需要提示词，回答业务事实时也仍然可以使用检索上下文。

我的判断

我赞同作者把问题从「能不能训练」转向「信息放在哪里才好维护」。这比先讨论训练参数更贴近业务系统的真实需求，也能防止团队用模型改造去解决资料管理问题。

但标题里的类比有边界。模型权重不能像源码一样直接检查，确实会增加定位和修复难度；这不代表微调完全记不住事实，也不代表加了 RAG 就一定准确。检索可能找错资料，文档可能过期，模型也可能误读正确段落。引用提供的是核查入口，不能自动保证答案正确。

小型资料放提示词，是合理的工程取舍，但「能装下」也不该是唯一标准。还应检查资料是否需要按用户权限过滤，以及团队能否持续维护。原文没有比较长提示词与检索在成本、延迟和准确率上的差异，不能据此认定前者一定更省。

同样，9 个代理的配置证明作者实际采用过这种做法，却不是微调与 RAG 的对照实验。「先评估、再逐步升级」是有说服力的经验路线；「某种方式效果更好」仍需要自己的评估结果支持。

最值得接受的要求，是让微调对应一个可测量的缺口，而不是一句笼统的「模型不懂我们业务」。

能拿来做什么

• 给 Node 服务接入企业问答时，先把回答规则与业务资料分开维护。角色、格式和示例放提示词，政策、目录等内容按规模和权限需求决定直接传入还是检索。
• 做固定字段抽取或消息分类时，先收集真实输入并写清通过标准，再比较提示词、不同模型与微调方案。不要把输出「看起来不错」当作稳定性证明。
• 做会议或课程摘要时，把原始转写作为回答依据，并单独评估事实忠实度和结构一致性，避免把这两类问题都归因于模型能力不足。
• 准备微调前，明确要修复的失败类型、目标分数和未微调基线，同时核算样例审核、模型迁移和持续评估的工作量。