AI 系统落地
AI 落地，指的是从一个令人惊艳的演示，走到一套敢摆在客户面前的系统之间的那段工作。模型本身很少是难点。难的是：你敢信任的评测体系、在真实流量下依然扛得住的延迟与成本，以及当用户做出无人预料的操作时，系统行为仍能保持在可接受范围内。我们构建 AI 系统的方式，和构建任何生产系统一样：有测试、有监控、有回滚路径。
为什么 AI 原型常常止步于上线之前
多数团队很快就能做出一个令人信服的演示，然后就卡住了。原因高度一致，而且没有一条是关于选哪个模型的。
- 没有评测集，因此没人说得清一次改动到底是变好了还是变差了。
- 测试阶段微不足道的成本，到了真实用量下变成最大的一笔开支。
- 单用户下没问题的延迟，一旦请求开始排队就变得无法接受。
- 对于模型「自信地给出错误答案」的情况，没有任何预案。
- 什么都没记录，因此故障既无法复现，也无法向客户解释。
我们首先构建什么
在增加能力之前，我们先让系统变得可度量。否则之后的每一次改动都只是猜测。
- 一套取自你真实数据的评测集，其中包含那些失败案例。
- 在 CI 中自动评分，让一次提示词或模型变更成为一个可度量的事件。
- 对每一次调用做链路追踪：输入、输出、延迟、token 数与单次请求成本。
- 为那些绝不能未经检查就到达用户面前的输出，加一层护栏。
选择那个「够用就好」的最小方案
微调、检索、智能体和换更大的模型，是针对四类不同问题的四种不同答案，而它们经常被用错地方。检索解决的是知识缺失。微调解决的是格式与语气。智能体解决的是多步骤工作流。更大的模型解决的是推理深度，代价是钱。我们会在动手之前先诊断你实际面对的是哪一类，因为昂贵的那个选项，往往是在解决一个你根本没有的问题。
让它在大用量下依然负担得起
AI 的成本随用量增长的方式，与多数软件都不同：一套在每天一千次请求时还能赚钱的系统，到了每天十万次可能就是灾难。我们从一开始就为此做设计。
- 对重复出现的请求做缓存——这类请求通常比预期的要多。
- 把廉价请求路由到小模型，把大模型留给真正困难的场景。
- 对提示词与上下文做裁剪，并且是实测的，而不是想当然的。
- 按功能维度做成本看板，让昂贵的路径在账单到来之前就被看见。
什么时候我们会劝你别用 AI
很多被当作 AI 问题提出来的需求，其实是搜索问题、规则问题或数据质量问题，用常规方法解决更便宜、更快，也更可预期。如果我们发现是这种情况，我们会直说。一个调优良好的查询所驱动的推荐引擎，胜过一个会产生幻觉的推荐引擎，而且运行成本只是零头。
常见问题
- 我们需要自己的模型吗？
- 几乎从来不需要。多数生产系统使用托管模型，配合检索与良好的提示词设计。只有在任务范围窄、用量大、对格式敏感的场景下，自己训练或微调才值得——而且那是一项大得多的投入。在你为此花钱之前，我们会告诉你属于哪一种情况。
- 你们怎么防止它给出错误答案？
- 错误无法根除，所以系统必须能够承接它。具体做法是：把答案锚定在你的数据上并附带引用来源、按 schema 校验结构化输出、把高风险动作放在人工确认之后才执行，并且记录足够的信息，以便事后能解释任何一个具体答案是怎么来的。
- 这套系统能跑在我们自己的基础设施上吗？
- 在数据要求如此的情况下可以。自托管开放权重模型，等于用运维成本换掉 API 成本，同时接受能力上限更低。对某些数据敏感的负载，这笔交换值得做；对另一些则不值得——具体是哪一种，我们会讲清楚。
- 你们如何衡量它是否足够好？
- 在上线之前，用一套基于你的数据构建、并有约定通过标准的评测集来衡量。「感觉变好了」不是发布标准；而且没有基线，谁也说不清下一次改动到底有没有帮助。