基礎

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 模型設計的新型響應格式。它不僅僅是一種提示格式，更是對模型如何構造輸出（特別是針對復雜推理和工具使用）的全面重新思考。