基础

transformer架构、transformers库

Google 2018 年的论文Attention is all you need，提出了Transformer架构。Transformer是几乎所有预训练模型的核心底层架构。基于Transformer预训练所得的大规模语言模型也被叫做“基础模型”（Foundation Model 或Base Model）。在这个过程中，模型学习了词汇、语法、句子结构以及上下文信息等丰富的语言知识。这种在大量数据上学到的知识，为后续的下游任务（如情感分析、文本分类、命名实体识别、问答系统等）提供了一个通用的、丰富的语言表示基础。

• transformers库是一个用于自然语言处理（NLP）的Python库，它提供大量预训练的 Transformer 模型、tokenizers、训练与推理工具，支持 PyTorch、TensorFlow、JAX。适合快速用预训练模型微调或部署。

• 可以使用 Hugging Face 的 transformers 库来加载并使用大部分开源模型，只要模型权重和配置文件遵循 Transformers/Hub 的约定。

• 大模型（几十亿/千亿参数）需要大量显存/内存。即使能加载，运行成本和延迟也很高。可能需要分布式、模型并行、量化或使用更小的蒸馏模型。

预训练模型的微调（Fine-tuning）

• 预训练：在大规模无标注文本数据上进行模型的训练，目标是让模型学习自然语言的基础表达、上下文信息和语义知识，为后续任务提供一个通用的、丰富的语言表示基础。
• 微调：在预训练模型的基础上，根据特定的下游任务对模型进行微调。因为经过预训练的大模型中所习得的语义信息和所蕴含的语言知识，能够非常容易地向下游任务迁移。NLP应用人员可以对模型的头部或者部分参数根据自己的需要进行适应性的调整，这通常涉及在相对较小的有标注数据集上进行有监督学习，让模型适应特定任务的需求。

预训练+微调的大模型应用模式

预训练模型能够将大量的通用语言知识迁移到各种下游任务上，作为应用人员，我们不需要自己寻找语料库，从头开始训练大模型，这减少了训练时间和数据需求；

微调过程可以快速地根据特定任务进行优化，简化了模型部署的难度；

预训练+微调的架构具有很强的可扩展性，可以方便地应用于各种自然语言处理任务，大大提高了NLP技术在实际应用中的可用性和普及程度。

base 模型、instruct 模型区别

• base 模型：通常指未经专门对齐或人类反馈微调（或仅做基础微调）的语言模型。它更接近原始自回归预训练模型，目标是拟合训练语料的下一个词分布。
  • 特点：能力强、泛化好，但没有明确学习去遵守指令或对话礼貌性、安全性约束。

• instruct 模型：在 base 基础上，经过专门的微调，使其更擅长理解和执行“人类指令”（instructions）。
  • 特点：更擅长按照用户指令产出可用、简洁、有组织的回答；通常使用人工标注的数据、专家演示、或人类反馈（例如 RLHF）训练得到。

https://huggingface.co/deepseek-ai/DeepSeek-V3.1-Base 名称带 -Base，通常表示未经指令微调。

模型 URL 和标题里有 -Base，这是社区约定中常见的“原始/基础权重”命名（作者通常会把指令微调版本单独命名为 -Instruct、-Assistant、或直接去掉 -Base 后缀并在 README 明确说明）

DeepSeek-V3.1（没有 -Base） 是在其上做了后续训练或扩展。

“DeepSeek-V3.1 is post-trained on the top of DeepSeek-V3.1-Base”
这说明 DeepSeek-V3.1-Base 是基础权重，而 DeepSeek-V3.1 是在其上做了后续训练（post-training/finetune/extension）。通常 authors 会把指令微调、对话优化或 agent 能力加入到 post-trained 版本，所以 DeepSeek-V3.1 更可能是实用的 instruct/chat 版本。

Hugging Face 上如何查看base模型、instruct模型

• Base 模型：通常是原始预训练模型（例如 gpt2, bert-base-uncased, llama-7b 等原始权重）。发布者会在名称或说明里标明“base”或不带任何指令微调说明。

• Instruct / Instruction-tuned 模型：经过指令微调（supervised fine-tuning 或 RLHF）的模型，会在模型名或 README 中写明如 -instruct, -alpaca, -flan, -instruction 等关键字。

• Chat / Dialogue 模型：为多轮对话或聊天优化的模型，常在名字中出现 chat, conversational, belle-chat 等字样，或提供对话 API 接口/示例。

• 查看模型页面的模型卡（Model card / README）

  • 查找关键词：base、instruct、chat、fine-tuned、RLHF、supervised_finetune、alpaca、flan 等。
  • README 通常会说明训练数据、训练方法及适用场景。

混合推理模型

大模型里的快思考 vs 慢思考

有些事情几乎瞬间就能想到：“今天星期几？” 其他事情则需要更多的脑力，比如解决一个隐晦的填字游戏或调试一段复杂的代码。我们可以选择根据手头的任务投入或多或少的认知努力。

• 快：纯模型内知识
• 慢：检索知识库、调用工具/代码执行、运行时记忆、约束求解器等

其实混合推理模型已经有不少了，例如 Claude 3.7 Sonnet 和 Gemini 2.5 Flash。

混合推理（Hybrid Reasoning），或者说“快/慢思考”，我们这里统一称为混合推理。

qwen3模型

参考文章：https://juejin.cn/post/7499354223328903202

Qwen3 提供了一个参数 enable_thinking，当将其设置为 True 的时候，模型就会像一般的思考模型那样开启深度思考；而将其设置为 False 的时候，模型就会像一般的模型那样快速回复。

这个 enable_thinking 的参数是在哪里作用的呢？根据官方代码示例，我们可以看到它是在 tokenizer.apply_chat_template() 这个方法中传递的。

text = tokenizer.apply_chat_template(messages,tokenize=False,add_generation_prompt=True,enable_thinking=False  # True is the default value for enable_thinking.
)

将一个多轮对话的 messages（包含 system/user/assistant 等角色）按照模型需要的聊天模板拼接成最终的文本提示 text，方便后续送入模型进行生成或推理。

• messages：

  • 输入对话列表，每个元素一般是一个字典，格式示例：
    {"role": "system", "content": "You are a helpful assistant"}、{"role": "user", "content": "你好"} 等。
  • 该函数会根据 chat template（模型定义的模板）把这些消息按顺序拼接成一个完整的 prompt。

• tokenize=False：

  • 作用：不对生成的字符串立即进行分词（tokenize）。
  • 含义：返回的是原始字符串 text，而不是 token id 序列。常用于在发送到模型或进一步处理前先查看/调试拼接结果。

• add_generation_prompt=True：

  • 作用：在拼接结果后面附加用于触发模型生成的提示（generation prompt）。
  • 含义：通常会在最后加上模型期望的生成起始标记或光标位置（例如 <｜Assistant｜> 或 <think> 等），以告诉模型现在应该开始生成回复。设置为 True 可以确保输出是一个完整的、可直接用于生成的 prompt。

• enable_thinking=False：

  • 作用：是否启用“thinking”模式相关的 token（模型区分 thinking 与 non-thinking 两种生成行为）。
  • 含义：False 表示使用 非思考（non-thinking） 模式拼接模板（例如使用 </think> 结尾的形式）；如果为 True（默认值），会使用 thinking 模式（例如在生成时放置 <think>，使模型进入“思考/链式推理”状态）。
  • 注意：这里显式设置 False，表示希望模板采用非思考模式（可能更偏向直接输出而非内部思路展示）。

这样得到的 text 可以直接用于调用模型进行回复生成或用于调试查看完整 prompt。

apply_chat_template() 这个方法，这是一个构建对话模板的方法，不涉及任何模型侵入。apply_chat_template 把结构化 messages 转成 DeepSeek 的 ChatML 字符串，并通过 thinking 与 add_generation_prompt 控制生成提示和思考标记。
你不应在 message content 中混用模型控制标签与 tokenizer 的 thinking 管理，否则会产生不匹配或冲突的标签。

对话模板其实是一种便于模型区分对话角色的工具，它并不复杂，其实就是利用特殊 token 构建一个让模型“看得懂”的对话方式，而这个方式往往是模型在 post-training 中针对性训练的。这样模型就能像我们平时使用的那样，完成问答等任务了。

比如，使用 LangChain，要了解并正确使用对话模板（ChatML / chat template），因为 LangChain 主要负责对话管理与工具整合，但最终发送给模型的 prompt 必须符合模型期望的模板格式才能获得正确输出。在 LangChain 中，用 PromptTemplate（或自定义模板）来精确拼接符合模型要求的 ChatML 格式。

ChatML（Chat Markup Language）格式
ChatML（Chat Markup Language）是一种用于在对话中定义消息格式的标记语言，它允许开发者以结构化的方式传递消息内容、元数据、角色信息等。这种格式特别适用于训练和使用对话模型，因为它能够清晰地标识不同角色的消息，使模型能够更好地理解和生成对话内容。

注意：
模型接收的是token 序列（由 tokenizer 把字符串分成 tokens）。它并不“知道”你给它的标签是 ChatML 标准还是你临时发明的，模型只学到：在训练数据中，某种 token 序列模式通常与某类输出关联。

标签（ChatML）起到的是“协议/提示”的作用：它告诉模型“这里是 system 指令/这里是 user 的问题/这里需要开始生成/这里是工具调用参数”。
模型最终是靠上下文模式与概率分布生成文本：标签只是影响上下文模式的一个强信号。模型没有内在的“语法解析器”去理解 ChatML 标记的定义；相反，它在训练中学到“当遇到这类标记序列时，常见的合适输出是什么”。

如果训练/微调和推理都采用同样的 ChatML 协议，模型行为会更稳定和可预测。

可以这样理解和总结：raw prompt 可以是 ChatML 格式；ChatML 是常见且推荐用于对话模型的 raw prompt 格式之一。

在可能的情况下，使用模型方提供的 helper（例如 tokenizer.apply_chat_template）来生成 ChatML，避免手工错误。

为什么需要关注对话模板，LangChain 会把消息按通用模板拼接或直接把字符串传给模型，可能不匹配模型期望的 ChatML，导致输出不稳定或工具调用失败。自定义 PromptTemplate，按模型模板拼接 system/user/assistant、<think> 标记等。

若社区或模型方提供了 LangChain adapter（LLM wrapper / PromptTemplate），优先使用，减少手工适配工作。

# 收集 LangChain messages
messages = [{"role":"system","content":"You are a helpful assistant"},{"role":"user","content":"搜索关于A的信息"},
]# 方法：用模型提供的 tokenizer 拼接符合 ChatML 的 prompt
chat_prompt = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True, enable_thinking=False)# 把 chat_prompt 传给模型做生成（而不是直接让 LangChain 默认拼接）
response = client.generate(chat_prompt)

含特殊 ChatML / 模型标记的 raw prompt（模型专用）

<｜begin_of_conversation｜>
<|system|>You are a senior software engineer who writes bug-free code.</|system|>
<|user|>Please provide a secure login example in Python.</|user|>
<|assistant|>

• 许多模型有自己的专用标记（如上示例），把这些标记包含在 raw prompt 中可触发模型的特定行为（thinking、toolcall 等）。

包含思考/内部链式推理的 raw prompt（需要模型支持）

System: You are allowed to show internal chain-of-thought between <think>...</think>.
User: Solve: If x+2=5, what is x? Show your reasoning.
Assistant: <think>First subtract 2 from both sides... </think> Final answer:

• 只有当模型/平台支持并愿意返回思考内容时，这种 raw prompt 才有意义。

• 特点	raw prompt	messages（结构化）
  形式	单一字符串	JSON 列表（role/content）
  控制粒度	高（可以包含任意标记）	受限（由平台或规范解释）
  安全 / 审计	不易被平台中间件自动过滤	平台更容易插入策略与过滤
  兼容性	需平台支持原样透传	大多数平台默认支持（更通用）

• Raw prompt = 你完全控制的、以字符串形式发送给模型的输入。它适合需要精确模板或模型特定标记的高级用例，但许多平台不原样透传 raw prompt，所以使用前应确认平台支持并做好安全/测试。

deepseek模型

deepseek官方文档: https://api-docs.deepseek.com/zh-cn/

deepseek-chat 和 deepseek-reasoner 都已经升级为 DeepSeek-V3.1。deepseek-chat 对应 DeepSeek-V3.1 的非思考模式，deepseek-reasoner 对应 DeepSeek-V3.1 的思考模式.

DeepSeek-V3.1是一个混合模型，支持思考模式和非思考模式。 与之前的版本相比，此次升级在多个方面带来了改进：

• 混合思考模式: 一个模型通过改变聊天模板来支持思考模式和非思考模式。
• 更智能的工具调用：通过后训练优化，模型在工具使用和代理任务中的性能得到了显著提升。
• 更高的思考效率：DeepSeek-V3.1-Think实现了与DeepSeek-R1-0528相当的答案质量，同时响应速度更快。

DeepSeek-V3.1是一个混合模型，支持思考模式和非思考模式。
标签预示着接下来进行慢思考，标签代表不思考

混合思考模式: 一个模型通过改变聊天模板来支持思考模式和非思考模式。

Claude 3.7 Sonnet

官网文档：https://www.anthropic.com/news/claude-3-7-sonnet
"思考"工具：使 Claude 能够在复杂的工具使用场景中停下来思考
https://www.anthropic.com/engineering/claude-think-tool
Anthropic 的 Claude 3.7 Sonnet 混合推理模型现已在 Amazon Bedrock 上线
原文链接： https://aws.amazon.com/cn/blogs/china/anthropics-claude-3-7-sonnet-the-first-hybrid-reasoning-model-is-now-available-in-amazon-bedrock/
新的 Claude 3.7 Sonnet，用户可以打开或关闭“扩展思维模式”，指导模型更深入地思考棘手的问题。

作为 Anthropic 迄今为止最智能的模型，Claude 3.7 Sonnet 是其首款混合推理模型，能够快速提供回复，也能进行深度思考，这意味着它可以通过细致的逐步推理来解决复杂问题。

Claude 3.7 Sonnet 提供了兩種思考模式：標準模式和擴展思考模式。

官方文档，如何使用 extended thinking
https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking

curl https://api.anthropic.com/v1/messages \--header "x-api-key: $ANTHROPIC_API_KEY" \--header "anthropic-version: 2023-06-01" \--header "content-type: application/json" \--data \
'{"model": "claude-sonnet-4-20250514","max_tokens": 16000,"thinking": {"type": "enabled","budget_tokens": 10000},"messages": [{"role": "user","content": "Are there an infinite number of prime numbers such that n mod 4 == 3?"}]
}'

要启用扩展思考，需要添加一个类型为 thinking 的对象，并将其 type 参数设为 enabled，同时用 budget_tokens 指定用于内部推理的最大令牌数。budget_tokens 决定模型（如 Claude 4）在内部思考时可消耗的令牌上限——该限制针对完整的思考令牌，而不限制最终输出长度；增加预算有助于复杂问题的更深入分析，但模型未必会用尽分配的全部预算，尤其是在超过 32k 的范围时。budget_tokens 必须小于 max_tokens；不过，在与工具交错使用思考（interleaved thinking）时，可以突破该限制，令牌上限将变为整个上下文窗口（例如 200k）。

ChatML vs Harmony：OpenAI全新对话结构格式的变化

ChatML vs Harmony：深度解析OpenAI全新对话结构格式的变化
原文链接：https://developer.volcengine.com/articles/7538387123313836068

ChatML（聊天标记语言）一直是许多开源模型（特别是 Qwen 系列）的首选格式。它本质上是一种受 XML 启发的对话结构化方式，旨在清晰地分隔对话的不同部分。

Harmony 是 OpenAI 专门为 gpt-oss 模型设计的新型响应格式。它不仅仅是一种提示格式，更是对模型如何构造输出（特别是针对复杂推理和工具使用）的全面重新思考。