上半年我是一个RAG或Agent的拥簇者，我坚信只要足够参数规模的强力大模型，加上知识库或者智能体plan及工具调用即可完成大部分应用场景。事实证明确实可以完成，但是能完美地完成吗？如果仅仅考虑及格落地，那是可以，但如果考虑优秀落地，那还是差点意思。为什么呢？

我们举一个【作文智能批改助手】的例子来说，作文批改要求老师从不同方面评定给分，最后汇总，并生成点评和指导意见。有人说那这个可以通过prompt限制。确实是。Prompt的限制是一定要加的，但是仅仅prompt是不够的，大模型回答的时候依然会有部分随机性。这点跟few shot原理是一致的，在prompt中给出的示例，可以让大模型模仿，但是模型并没有真正让大模型成为专业口吻的专业人士，它只是鹦鹉学舌，一旦超出few shot的范畴，回答很有可能”一朝回到解放前“。另一方面，从性能上讲，过多的约束和提示词示例，会大量消耗上下文长度，影响大模型的判断和推理时间（当然推理优化可以通过工程手段如System Prompt Caching，但又增加了复杂度）。

在实战的场景中，我们也确实遇到了诸多相似的困难。比如给客户落地【法律合规助手】的应用时，我们采用了qwen-max这样强大的千亿规模基础模型，加上客户给的70M纯文本专业领域知识，很快构建了一个以知识库为基础的大模型应用。客户在poc阶段时惊叹于落地速度之快、文档召回效果之好、大模型总结能力之强，一度让我们备受鼓舞。但注意，这是poc阶段，真正落地交付的时候，业务专家严格、多样、真实的场景需求便会扑面而来。

举个简单的例子，业务专家希望大模型回答的时候不要使用“不可以”这样的显著否定词，而是要用“不宜”这样的专业但温和的词，我们的工程师将这个词在prompt里面做了约束。过了两天，业务专家又来提意见，对于复杂的主观问题，大模型每段回答的结语都会有兜底的回复比如“必要时，可以向监管部门咨询确认”，业务专家认为多了“确认”二字，意思完全变了，监管只能“指导”，不能“确认”。

类似的回复格式、回复口吻、专业态度等，在实战场景中有非常多的要求，其本质就是大模型+RAG只能解决有没有的问题，不能解决专业不专业的问题。通过Prompt实现不是真正的解决之道，而且增加了很多复杂性，这让我们不得不上大招--微调。

说到微调，我这里又有话要说。

早在去年的时候很多客户领导一开口就是要搞微调，要搞成领域专家模型，当时为了这种局面我写了很多ppt纠正客户的认知，苦口婆心劝说大家先用RAG。如今我又回来说微调，多少有点尴尬。。。需要澄清的是，此【微调】非彼【微调】。我先来张图：

很多客户领导认为，我们可以通过【微调】让大模型掌握一定的领域知识，让它成为一个具有行业知识的专家。实际上这个过程不叫【微调】，而叫【增量预训练】，或者是【Post-pretran】。为啥是增量预训练呢？因为此时用到的数据和算力，是和预训练时候无二的。比如我们预训练一个6B的基础大模型，要用1500B的token通用语料，增量预训练则需要100B的token，同时还要混合预训练时的通用语料。那数据量，那算力，没有千万级的预算咱就先别想。。。但是增量预训练是扎扎实实让模型学习了某种知识，从这个角度来说，付出的努力（钱）是没白费的。

而我现在说的【微调】，其实不是为了 让大模型学习某种领域知识，而只是为了让它能执行特定任务，并且与人类意识对齐，比如能对话、能分类、回答问题无暴力倾向等。这就和我们前文所说的，想要训练一个说话专业点儿的法律专家助手的需求相符合了。在这里我们可以采用【微调】技术，增强我们上一个阶段仅仅用了知识库技术所做的“助手”。

至于如何微调，微调选什么技术框架，要多少算力多少数据，下回分解。