如何高效使用 DeepSeek-R1 这种推理模型?
Together AI 今天发布了一篇《DeepSeek-R1 Quickstart》有关如何使用DeepSeek-R1的综合指南!我看了下其中有一些内容很好,翻译了其中核心的内容分享给大家。 DeepSeek-R1 这种推理模型经过专门训练,能够在给出答案前进行逐步思考,这使得它们在复杂的推理任务中表现出色,例如编码、数学、规划、谜题和 AI 智能体的工作流程。 对于一个问题,DeepSeek-R1 会输出其思维链/推理过程(以思考 Token 的形式),这些 Token 被包含在 <think> 标签中,以及最终的答案。 由于这类模型需要消耗更多的计算资源和 Token 才能实现更好的推理能力,因此它们的输出通常更长,计算速度也更慢,成本也高于没有推理能力的对应模型。 Prompt 调优以获得最佳结果 推理模型(如 deepseek-r1、o1、o3-mini等)擅长根据已知信息进行逻辑推理和问题求解,而非推理模型(deepseek-v3、gpt-4o、claude-3.5-sonnet等)则更侧重于信息检索和模式匹配。下面我们提供一份指南,帮助你充分发挥 DeepSeek-R1 的性能: 清晰且具体的提示语 (prompts): 使用简洁明了的语言编写指令,明确表达你的需求。复杂冗长的提示语往往效果不佳。 采样参数: 建议将 temperature (温度系数) 设置在 0.5-0.7 之间 (推荐值 0.6),以避免模型产生重复或不连贯的输出。同时,top-p (概率截断) 建议设置为 0.95。 避免使用系统提示 (system prompt): 不要添加额外的系统提示语,所有指令都应包含在用户提示语中。 避免使用少量样本提示 (few-shot prompting): 不要在提示语中提供任何示例,因为这会降低模型的性能。相反,请详细描述你希望模型解决的问题、执行的任务以及输出的格式。如果确实需要提供示例,请确保示例与你的提示语要求高度一致。 组织你的提示语: 使用清晰的标记 (例如 XML 标签、Markdown 格式或带有标签的段落) 来分解提示语的不同组成部分。 这种结构化的组织方式有助于模型正确理解和处理你的每一个请求。 设置明确的要求: 当你的请求存在特定限制或标准时,请明确地进行说明 (例如 “每行文本的朗读时间不应超过 5 秒…”)。 无论是预算限制、时间限制还是特定的格式要求,都应清晰地概述这些参数,以便引导模型生成符合要求的回复。 清晰地描述输出: 详细描述你期望的输出结果。 描述具体的特征或质量,以便模型生成完全符合你需求的响应,并朝着满足这些标准的方向努力。 多数投票选择回复: 在评估模型性能时,建议生成多个解决方案,然后选择出现频率最高的结果。 避免使用思维链提示 (chain-of-thought prompting): 由于这类模型在回答问题之前会自主进行推理,因此无需指示它们“逐步思考……” 数学任务: 对于数学问题,建议在提示语中添加如下指令:“请逐步进行逻辑推理,并将最终答案置于 \boxed{} 中。” 强制使用 <think> 标签: 极少数情况下,DeepSeek-R1 可能会跳过思考过程,从而对模型性能产生负面影响。 在这种情况下,模型输出的响应将不会以 <think> 标签开头。 如果你遇到此问题,可以尝试引导模型以 <think> 标签开头。 应用场景 评估其他 大语言模型 (Benchmarking other LLMs): 评估 大语言模型 响应的上下文理解能力,这在需要严格验证的领域(如法律、金融和医疗保健)中尤为重要。 代码审查 (Code Review): 执行全面的代码分析,并针对大型代码库提出改进建议。 战略规划 (Strategic Planning): 制定详细的计划,并根据具体的任务需求选择合适的 AI 模型。 文档分析 (Document Analysis): 处理非结构化文档,并识别多个来源之间的模式和关联。 信息提取 (Information Extraction): 从大量非结构化信息中高效地提取相关数据,非常适合 RAG 系统。 歧义消除 (Ambiguity Resolution): 有效地解释不明确的指令,并在需要时主动寻求澄清,而不是直接进行猜测。 上下文和成本 在使用推理模型时,至关重要的是在上下文窗口中保持足够的空间,以便模型能够充分进行推理。推理 Token 的生成数量会因任务的复杂程度而异——简单的问题可能只需要几百个 Token,而复杂的挑战可能需要数万个 Token。...