微调 vs. 提示工程:生产级 LLM 的决策框架
· 阅读需 9 分钟
大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上,结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理,同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。
决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。
大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上,结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理,同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。
决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。
大多数工程师学习提示工程都是倒着来的。他们从“发挥创意”和“一步一步思考”开始,反复迭代一个演示直到它奏效,然后在生产环境中发现模型有 15% 的时间在“幻觉”(胡编乱造),他们的 JSON 解析器每隔几小时就会抛出异常。让聊天机器人令人印象深刻的技术,往往不是让生产系统可靠的技术。
在将 LLM 功能部署到真实系统一年后,以下是真正区分有效提示和在负载下仍能保持稳定的提示的关键。