训练与推理
训练一次定下能力上限，推理每次调用都在花你的钱。所以你能改的东西，几乎全在推理这一侧。
模型进工厂之前要先「喂」，出厂之后才是「用」；这前后两件事花的钱、能改的地方、发生的时间，全都不在同一个量级上。日常讨论里它们经常被混成一句「模型能力怎么样」，而产品决策走偏，多半就是从这句话开始的。
读完你能回答：
- 为什么你在对话里纠正了它，换个会话它又错一遍？
- 提示、检索、微调这三件事，各自能改到什么？
- 账单为什么会随着功能上线悄悄失控？
出厂前定死的那份权重
喂的过程叫训练：海量文本送进去，让它一遍遍猜下一个 token，每猜错一次就回调一次参数。这是模型厂商干的事，要在成千上万张卡上连续跑几个月，电费高到不该写进产品预算。跑完之后交付的是一份权重文件，它从此定型，不会因为昨天有人跟它说了什么而改变，也不会自己再长本事。所谓「模型越大、数据越多，能力就越强」，讲的就是这一段的规律。scaling-laws
用起来的过程叫推理：把你的输入送进这份权重，算出这一轮要交付的内容，几秒钟就有结果，单次花费在分毛的量级。关键在于它每次都从零算起。 上次调用算过的东西不留痕迹，也不会让这一次更便宜——哪怕两段话只差一个字，也要整段重新算一遍。
记住这句话，后面的争论大多能自己收场：能力的天花板由训练定，钱的账在推理侧反复发生。
会话一关，你说过的话就没了
有一个反直觉的地方：它能察觉到你在纠正它，但这份纠正不会写进权重。
纠正之所以当场生效，是因为你那段话被放进了本次的输入序列，接下来生成的 token 能读到它。可这段输入只活在这一次会话里。想验证这件事很简单：把同样的错换个新会话再问一遍，原来的毛病一分不少地回来——你上次的纠正从来没有被「记住」，它只是恰好和你在同一段文字里出现过。
分清两者很重要：「它记住了」是你的系统把内容重新塞进了下一次输入，「它学会了」只有训练能做到。这条推论落到产品上，就是所有「让它记住」的设计——系统提示、长期记忆、检索到的资料、工具返回的结果——本质上是同一个动作的不同实现，都是在下一次调用时把东西重新装进去。这也是为什么上下文里装了什么，比「模型聪不聪明」更值得你花时间。
训练侧只剩选型，推理侧全是旋钮
这条线一旦分清，很多争论会当场结束。
训练侧，你唯一的动作是换人。 知识停在哪一天、哪种语言更拿手、写代码行不行、能不能读图、说话的偏好如何，都在训练那一刻固定了。不称心只能改选型，此外没有别的办法——一个没有读图能力的模型，提示词写得再巧也读不了图。怎么按任务选型 是这一侧的全部工作。
推理侧，你能拧的旋钮很多。 提示怎么写、上下文给多少、温度调到哪一档、挂不挂检索、给不给工具、挑哪一档模型、开不开缓存，这些全在你手上。做 AI 产品的日常工作量，九成花在这一侧。
于是有了一条判据：遇到「它做不到」，先分清是哪一侧的问题。选型问题换模型，别的几乎都还有空间。
卡在中间的是微调：能改倾向，不能加知识
训练和推理之间还站着一层，叫微调。它的做法是拿少量数据在现有权重上再训一轮，产出的仍然是一份定型的新权重。它调整的是倾向，不是知识量——风格、格式、领域口径这类东西能改，而「公司制度怎么规定的」这类具体条目，它学不进去。代价比训练低几个数量级，可比改提示词高出太多，而且改完就固化，灵活性远不如提示。openai-finetune
那什么时候值得？看四个条件是否同时成立：输出格式必须极其稳定、口径必须严格统一、提示词已经写不下也写不稳，而且你手上有几千条像样的样本。这四条都满足时，微调买到的是「不用每次都在提示里重复交代」。
反过来，想让它知道上个月发生的事、想让它知道你们刚改的退货规则、手上只有几十条样本——这几种情况下，正确答案几乎总是检索：把资料找出来放进上下文。微调还是 RAG 给了一条更细的判断线。
先后顺序别弄反：提示和检索先用尽，微调放到后面考虑。
账单是怎么长起来的，能压的地方有四处
推理按 token 计价，进和出分别计算，出那一份通常贵出好几倍。所以一次请求的花费是「输入长度 × 输入单价」加上「输出长度 × 输出单价」，再乘以一天的调用次数就是你的账单。这几个因子叠在一起，最容易失控的就是每次请求的输入长度。它不按字数收费 展开了单位本身的问题。
膨胀通常是这样长出来的：一个客服助手，最初只是让提示词写一句「语气礼貌地回复客户」，几十个字。为了让回答专业些，把产品手册的节选挂进上下文，一次请求三千 token 起步。再往后接上工单的完整历史、知识库命中的段落、工具返回的结果，同样的问题一次要送进去四万 token。客户只点了一下，你按四万 token 付钱，而且这一轮之后，下一轮还要把前面的内容再发一遍。
能压的地方有四处，都落在推理侧，也都由你决定：
- 内容不变的前缀固定下来，走缓存；
- 简单任务分流到便宜档位的模型；
- 长文档先做摘要再进上下文；
- 多轮对话隔一段时间压缩一次。
按改动成本排，前两件几乎不碰产品逻辑，值得先做；后两件要动流程设计，收益也更大。
还有一条常被忘掉的账：延迟同样属于推理侧。输出写得越长，用户等得越久，因为内容是逐个 token 往外吐的。想让产品反应快，换一个更强的模型往往不是最有效的办法，让它少说几句才是。
最后一句提醒：只盯着总额会掩盖问题。账单涨了，可能是功能变复杂了，也可能是失败重试变多了，这两件事的解法完全不同。成本要能拆到每一步 讲的就是怎么让这笔账能定位到具体环节。