网站开发总结与收获安卓app开发环境搭建和配置

• 👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家
• 📕系列专栏：Spring原理、JUC原理、Kafka原理、分布式技术原理、数据库技术、JVM原理、AI应用
• 🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦
• 🍂博主正在努力完成2025计划中：逆水行舟，不进则退
• 📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀

作为企业负责人，或者个人应用开发者，当下如何在，推理模型 和 普通大模型做出选择？

需不需要把自己AI产品中的模型都替换成DeepSeek这样的推理模型呢？或者说普通大模型是不是已经没有了用武之地了呢？

另外是不是有了推理模型，提示词工程这项能力要求就不重要了呢？

结合我自己这几个月在模型定制 和 智能体项目 遇到的问题 和 解决经验，我觉得有必要和大家聊一下，我自己的理解。

首先，提示词工程依然很重要！

只要你的应用涉及到：复杂任务、工作流、智能体场景，提示词的操刀能力依然是基本功，推理模型实际上并不能让你偷懒。

其次推理模型 和 普通大模型之间不是二选一，目前我使用下来的经验是，两者甚至存在互补，这个结论怎么来的，结合我看到了大量的资料，以及openai最近发布的最佳实践指南，分三个部分详细和大家聊聊。

推理大模型和普通大模型的区别

首先聊下推理大模型 和 普通大模型的区别，千万不要小瞧这个问题，看过很多的文章报道，其实很多人都理解偏了，没有搞明白什么是推理模型，抛个问题，GPT-4O、OpenAi、豆包、DeepSeek R1等那些模型是推理模型？

除了deepseek R1 ,openAi o1 也是推理模型。

并且推理模型的概念大规模传播，早在24年9月份openai官方就开始宣布o1就开始了。

理解推理模型要抓住一个重要的概念：思维链-chain of Thought，其是一种指导大语言模型进行逐步推理的提示词方法，它在模型在得出最终答案之前，先显示写出推理的中间步骤，就像人类解决复杂问题会先规划步骤一样，如果模型在回复你之前有一长串的思考过程，探索了不同路径之后给出答案的话，有这个能力的大模型才是推理大模型。

当我们使用claude3.5 和 deepseek对比的时候，claude会直接输出答案，没有任何推导，而deepseek会有一个思考的过程，会进行解题步骤的拆解思考，一步一步的推导才能得出这种答案，这就是deepseek在训练时强化学习了思维链的成果。

值得补充的一点，其实可以使用思维链提示词让普通大模型马上表现出推理模式的行为。

如果把刚才的解题要求加入到 思维链提示词，让claude再解一遍，可以看到明显的推导过程，和deepseek并没有明显的差别。

如果我们做一个简单的表格，不同维度下的两个大模型的区别

也就是从这个表格开始，延伸出来了第二个问题，到底什么时候要使用推理大模型？

什么时候该使用推理大模型

从使用场景上讲，推理大模型其实更擅长解决复杂编码、数学推理这些问题，普通模型更适合简单直接的任务，在响应延迟上推理模型的运算时间会更长一些，用户需要花费更多的时间去等待一个好的结果。

比如在这种翻译的简单场景上：

推理可能并非是必要的，可以看到同样的一段文档翻译工作，claude会直接给出翻译结果，而deepseek会遵循推理模型的行为，先进行多步骤分析推导，包含术语专业性、句子通顺、连接词考究这些，基本上会多出来30秒左右的推理时间，最终翻译后的结果显然也会更好一点。

如果一个原有的智能体产品将原有的普通大模型替换成推理模型，其实会出现各种不同的取舍问题。

以openai最新发布的《推理模型最佳实践指南》抛出来了一个简单的选择标准，结合我个人摸索的经验，我觉得非常值得借鉴。

相应速度与成本

如果你的应用对相应延迟特别敏感，或者预算比较紧张，那就选择普通大模型，相应更快，成本更低，别忘了用户的时间成本其实也是成本，比如我之前研究过的一个智能客服智能体，大部分都是标准回答：

你们什么时候发货？

这个尺码偏大吗？

能不能七天无理由退货

这种场景用普通模型 + RAG知识库就可以啦。用推理模型反而会显得大材小用。

任务定义与目标足够清晰

如任务翻译、文章改写，这些有明确输入输出的场景，用普通模型也是足够的，刚才的翻译例子虽然推理模型结果更好，站在我自己的经验来看，速度始终是这类明确任务的关键。****

准确性和可靠性

但是如果你的产品有很高的准确性和可靠性的要求，特别是在金融法律这些领域的话，推理模型就有更好的选择，openai提供的合同审查B端案例，就是使用o1分析企业并购文件时，模型在文件的角注中发现了一个隐藏的坑，避免了7500w美元的损失，这种需要连接上下文复杂的分析，普通模型很难做到这么细致，我相信很多律所或者企业法务都在这么做了。

复杂问题的稳定性

这个时候推理模型的优势就特别明显了，openai重点提到了代码审查、代码调试和改进的场景，对于任务本身的响应延迟极其不敏感，但是准确稳定是第一要素的。推理模型在后台定期执行针对性工作就可以了。

但是以上这些其实并不是二选一的关系。

openai自己提供的客服系统案例就提到了复杂工作流的场景建议使用 “推理模型 + 普通大模型”混合的打开方式。案例中是由普通大模型也就是gpt-4o进行信息分类及识别，推理大模型将信息汇总后进行最终的决策，等于在相应延迟以及任务稳定性 与 准确性上 进行一个平衡的处理。

在一些写专利的复杂工作流智能体也是这样的路子，每个单元的写作交给普通智能体，整体的效果把控及优化决策交给推理模型R1，效果其实还是不错的，所以各位大佬，你们在做模型选择的时候，没有必要非此即彼，得全盘考虑，这个世界除了deepseek还有很多模型的。

如何编写推理大模型的prompt

这份指南还提出了一些有意思的观点：

看到这句话真的有一种相见恨晚的感觉，因为我才从这个坑里面爬出来，小伙伴们都知道多智能体必定会用到复杂的提示词吧，但是调度模型我换成了deepseek以后，提示词遵从性的混乱感觉很让人崩溃。但是偶然间发现简单提示词反而效率更高，说到这里，可能大家懵逼了，既然推理模型 加 简单提示词效果更好，不就代表提示词不重要了吗？

但是如果这样理解就真的太片面了，openai想要表达的意思是对于任务的规划和反思，推理模型已经内置了这样的提示，外部给一个额外的提示词可能会导致冲突，对于如何高效编写推理模型的提示词，我们可以重点关注这三点建议。

避免提供 思维链提示词

就是刚才说的，不需要再提示推理模型 think step by step

多使用分隔符来提高任务清晰度 以及多使用markdown格式

也就是要明确不同的输入部分

可以尝试零样本提示词

这一点有点反常识，以往普通大模型提示词为了规范输出，基本上都会提供预期要求的格式示例，推理模型反而不需要一些实例样本就可以达到这个效果，这一点其实后续需要实践一下。