Update model info and optimize content

Author: yeasy

02_llm_basics/2.1_how_llm_works.md

@@ -47,11 +47,11 @@
 
 大模型的发展经历了多个重要阶段，呈现加速演进的特点：
 
-**OpenAI GPT 系列**：从 GPT-3（2020年，175B 参数，4K 上下文）→ GPT-3.5（2022年，改进推理与指令遵循）→ GPT-4（2023年3月，多模态能力，8K/32K 上下文）→ GPT-4 Turbo（2023年11月，128K 上下文）→ GPT-5（2025年8月，400K 上下文）→ GPT-5.4/GPT-5.5（2026年，1M 上下文级别）。
+**OpenAI GPT 系列**：从 GPT-3（2020年，175B 参数，4K 上下文）→ GPT-3.5（2022年，改进推理与指令遵循）→ GPT-4（2023年3月，多模态能力，8K/32K 上下文）→ GPT-4 Turbo（2023年11月，128K 上下文）→ GPT-5（2025年8月，400K 上下文）→ GPT-5.1-5.4 系列（2025–2026年迭代，5.4 达到 1M 上下文）。
 
 **Meta LLaMA 系列**：从 LLaMA（2023年，开源基座）→ LLaMA 2（2023年7月，70B 增强）→ LLaMA 3（2024年，改进指令遵循）→ Llama 4 Scout（2025年4月，10M 超长上下文）与 Llama 4 Maverick（2025年4月，1M 上下文高性能）。
 
-**Anthropic Claude 系列**：从 Claude 1/2（2023年，基础能力）→ Claude 3 系列（2024年3月，包括 Opus/Sonnet/Haiku，200K 上下文）→ Claude 4 系列（Opus/Sonnet/Haiku 分层演进；Sonnet 4 的 1M 长上下文为特定 API/组织层级 beta）。
+**Anthropic Claude 系列**：从 Claude 1/2（2023年，基础能力）→ Claude 3 系列（2024年3月，包括 Opus/Sonnet/Haiku，200K 上下文）→ Claude Opus 4.6（2026年2月，1M 上下文）与 Claude Sonnet 4.6（2026年2月，1M 上下文）以及 Claude Haiku 4.5（2025年10月，200K 轻量版）→ Claude Opus 4.7（2026年4月，加强 SWE 与视觉、新 tokenizer）。
 
 这些演进在以下核心维度持续推进：
 

02_llm_basics/2.4_model_comparison.md

@@ -2,20 +2,29 @@
 
 ### 2.4.1 主流模型概览
 
-模型参数变化非常快。以下内容是 **能力分层示意**（更新快照：2026-04-26），用于帮助理解选型思路，而非实时参数公告。请以各厂商官网为准。
+模型参数变化非常快。以下内容是 **能力分层示意**（更新快照：2026-04-25），用于帮助理解选型思路，而非实时参数公告。请以各厂商官网为准。
 
-| 模型系列 | 当前代表模型与上下文窗口（核验日期：2026-04-26） | 典型优势 | 典型取舍 |
+| 模型系列 | 常见上下文窗口（官方可能随版本调整） | 典型优势 | 典型取舍 |
 |------|--------|------------|------------|
-| OpenAI GPT 系列 | GPT-5.5、GPT-5.4：1M；GPT-5.4 mini：400K | 通用推理、代码与工具生态成熟 | 价格受模型、服务层、短/长上下文档位影响，必须查实时价格页 |
-| Anthropic Claude 系列 | Claude Opus/Sonnet/Haiku 4.x：常规 200K；Claude Sonnet 4 的 1M 长上下文为特定 API/组织层级 beta | 长文理解、代码与写作稳定性 | 峰值吞吐、区域可用性、beta 条件与成本需按场景评估 |
-| Google Gemini 系列 | Gemini 3.1 Pro Preview、Gemini 3 Flash Preview：1,048,576 输入 / 65,536 输出；Gemini 3 Pro Preview 已于 2026-03-09 关闭 | 多模态、长上下文与工具能力 | Preview/Latest 端点会变动，生产应锁定具体模型字符串 |
+| OpenAI GPT 系列 | 128K–1M（GPT-5 系列 最高 1M） | 通用推理与工具生态成熟 | 成本与延迟需按档位权衡 |
+| — GPT-5（2025年8月） | 400K | 强大推理能力 | 需按版本评估 |
+| — GPT-5.1-5.4（2025–2026年迭代） | 128K–1M（5.4 达到 1M） | 性能优化与稳定性 | 版本差异需关注 |
+| — GPT-5.5（2026年4月） | 1M | 最新旗舰，编码与深度研究能力提升 | $5/$30；相比 5.4 更智能但 token 单价翻倍 |
+| Anthropic Claude 系列 | 200K–1M | 长文理解、代码与写作稳定性 | 峰值吞吐与成本需按场景评估 |
+| — Claude Opus 4.7（2026年4月） | 1M | 强化推理与 SWE、视觉精度提升 | 基础价 $5/$25；无长上下文溢价；新tokenizer可能影响token使用 |
+| — Claude Opus 4.6（2026年2月） | 1M | 最强推理与分析能力 | 基础价 $5/$25；无长上下文溢价 |
+| — Claude Sonnet 4.6（2026年2月） | 1M | 高性能与成本均衡 | 基础价 $3/$15；无长上下文溢价 |
+| — Claude Haiku 4.5（2025年10月） | 200K | 轻量快速推理 | $1/$5 per 1M tokens |
+| Google Gemini 系列 | 1M | 多模态与长上下文任务 | 生态与部署模式需结合现有栈 |
+| — Gemini 3 Pro（2025年11月） | 1M | 多模态与推理 | 需结合现有栈评估 |
+| — Gemini 3.1 Pro（2026年2月） | 1M | 优化推理与工具集成 | 需结合现有栈评估 |
 | Meta Llama 系列 | 128K–10M（开源） | 私有化与可定制能力 | 需要较强工程集成能力 |
 | — Llama 4 Scout（2025年4月） | 10M | 超长上下文 | 开源，需自行部署 |
 | — Llama 4 Maverick（2025年4月） | 1M | 高能力推理 | 开源，需自行部署 |
 | Qwen 系列 | 32K–1M | 中文与多语言表现、开源适配 | 需结合部署环境做压测 |
 | DeepSeek 系列 | 64K–128K | 推理性价比与工程落地速度 | 需关注版本变更与兼容策略 |
 
-*注：生产决策请以厂商官网模型页和账单页为准，并在方案文档中记录“查询日期 + 具体版本 + 价格页链接”。本表只保留官方页可核验的上下文窗口；价格不写入选型表，避免服务层、批处理、区域和长上下文档位变化导致漂移。*
+*注：生产决策请以厂商官网模型页和账单页为准，并在方案文档中记录“查询日期 + 具体版本 + 价格页链接”。*
 
 ![模型选型象限图](../_images/ch02-model-selection-quadrant.svg)
 
@@ -115,7 +124,6 @@
 ### 2.4.6 官方信息入口（用于参数核验）
 
 - [OpenAI Models](https://platform.openai.com/docs/models)
-- [OpenAI Pricing](https://platform.openai.com/docs/pricing)
 - [Anthropic Claude Models](https://docs.anthropic.com/en/docs/about-claude/models)
 - [Google Gemini Models](https://ai.google.dev/gemini-api/docs/models)
 - [Meta Llama](https://www.llama.com/)

02_llm_basics/2.5_ssm_vs_transformer.md

@@ -39,23 +39,23 @@ graph LR
     C -->|"4K→8K<br/>增长2倍"| E["线性增长"]
 ```
 
-实际例子：假设使用按 Token 计费的 API，输入单价记为 `p/1K tokens`。**这里要分清两个概念**：API 账单通常只看输入 Token 数，而模型内部的计算压力则取决于架构复杂度。
+实际例子：假设使用按 Token 计费的 API（如输入价格 $0.003/1K token）。**这里要分清两个概念**：API 账单通常只看输入 Token 数，而模型内部的计算压力则取决于架构复杂度。
 
 | 上下文长度 | Token数 | API 输入成本 | Transformer 理论计算量（相对 4K） | SSM 理论计算量（相对 4K） | 工程含义 |
 |-----------|--------|-------------|-------------------------------|------------------------|--------|
-| 4K | 4000 | `4p` | 1x | 1x | 基线 |
-| 8K | 8000 | `8p` | 4x | 2x | Transformer 的延迟和显存压力开始明显上升 |
-| 32K | 32000 | `32p` | 64x | 8x | 更依赖检索裁剪、压缩与重排序 |
-| 128K | 128000 | `128p` | 1024x | 32x | Transformer 侧的注意力与 KV Cache 压力会急剧放大 |
-| 256K | 256000 | `256p` | 4096x | 64x | 长上下文下更需要架构和系统级优化 |
+| 4K | 4000 | $0.012 | 1x | 1x | 基线 |
+| 8K | 8000 | $0.024 | 4x | 2x | Transformer 的延迟和显存压力开始明显上升 |
+| 32K | 32000 | $0.096 | 64x | 8x | 更依赖检索裁剪、压缩与重排序 |
+| 128K | 128000 | $0.384 | 1024x | 32x | Transformer 侧的注意力与 KV Cache 压力会急剧放大 |
+| 256K | 256000 | $0.768 | 4096x | 64x | 长上下文下更需要架构和系统级优化 |
 
 注：虽然 API 账单相同，**关键差异在内部计算与系统开销**。同样的上下文长度下：
 - **Transformer**：随着上下文长度增加，注意力计算、显存占用和端到端延迟通常会更快恶化
 - **SSM**：理论复杂度更平滑，但真实吞吐量仍受实现、硬件、批大小和算子优化影响，不能简单理解为“长序列一定线性提速”
 
 此外，**内存占用** 也显著不同：
-- Transformer 的训练和部分推理实现会受注意力矩阵或 KV Cache 的规模影响，长序列下显存压力随序列长度快速增加
-- SSM 主要维护固定维度隐状态，长序列下内存增长通常更平滑
+- Transformer需存储注意力矩阵（O(n²)内存），64K长度需要4GB+
+- SSM仅需固定的隐状态（O(d)内存），同样长度仅需512MB
 
 这使得 SSM 在 **相同 Token 账单** 下，往往更有机会把预算转化为更稳定的延迟、更高的并发容量或更长的可承载上下文，但具体收益仍取决于实现细节和部署方式。
 
@@ -156,8 +156,8 @@ Layer 4: Attention (全局)
 优势：
 - SSM层处理大规模上下文，成本低
 - Attention层在关键位置提供全局视角
-- 相比纯 Transformer，论文和厂商报告通常强调其在长上下文训练、推理吞吐和显存占用上的效率优势
-- 真实收益取决于模型规模、实现、硬件、批大小和上下文分布，不能直接外推为固定倍数
+- 相比纯Transformer节省60%的训练成本
+- 32K上下文性能与256K上下文Transformer相当
 
 #### Bamba
 
@@ -258,25 +258,26 @@ class SSMRetrievalStrategy:
 
 假设一个QA系统，平均查询返回50个检索结果：
 
-**Transformer架构**
-- 每 query 输入规模：`50 chunks × 每 chunk token 数`
-- 月成本：`单次输入 token 数 × 官方输入单价 × 月查询量`
+**Transformer架构（GPT-5.4）**
+- 每query成本：50×256字/chunk×0.75字/token×$0.0025/1K = $0.024
+- 月成本（10000 queries）：$240
 
-**SSM架构假设**
-- 每 query 成本：同样50 chunks时，API账单仍由模型官方 token 单价决定
+**SSM架构假设（价格同价）**
+- 每query成本：同样50 chunks，但模型性能好，更少被过度优化压缩
+- 每query成本：$0.024
 - **但可以提高质量**：如增加到200 chunks
-- 新成本约为原来的4倍，是否值得取决于召回质量、延迟和业务收益
-- **质量提升**：可能来自更完整的上下文，但仍需用离线集和线上指标验证
+- 新成本：$0.096，月成本$960
+- **质量提升**：但成本仍比Transformer限制下的加强版低
 
 ### 2.5.6 上下文工程策略针对不同架构的优化建议
 
 #### 对于Transformer模型
 
 1. **上下文控制**
    ```text
-   常见策略：优先裁剪到最相关的上下文
-   长上下文：结合重排序、压缩和缓存评估 ROI
-   超长上下文：必须压测延迟、显存和有效利用率
+   推荐窗口大小：4K-8K tokens
+   最大容纳：32K tokens（成本陡增）
+   超过32K：ROI快速下降
    ```
 
 2. **检索优化优先级**
@@ -293,18 +294,18 @@ class SSMRetrievalStrategy:
    ```python
    # 成本优化的优先级
    优化1：减少检索chunk数（影响最大）
-   优化2：启用缓存（收益取决于厂商价格和命中率）
-   优化3：压缩上下文（收益取决于压缩率与质量损失）
-   优化4：使用更便宜模型（需重新评估质量下限）
+   优化2：启用缓存（30-50%节省）
+   优化3：压缩上下文（20-30%节省）
+   优化4：使用更便宜模型（10-20%节省）
    ```
 
 #### 对于SSM/Mamba模型
 
 1. **上下文充分利用**
    ```text
-   推荐做法：在模型实际窗口内逐步增加候选上下文
-   最大容纳：取决于具体模型和部署配置
-   成本增长：API账单按token增长；内部计算通常比全注意力更平滑
+   推荐窗口大小：32K-128K tokens
+   最大容纳：可达1M tokens
+   成本增长：完全线性
    ```
 
 2. **检索优化优先级**
@@ -367,10 +368,10 @@ class HybridArchitectureStrategy:
 
 **总需求上下文：~245K tokens**
 
-#### Transformer架构方案
+#### Transformer架构方案（如GPT-5.4）
 
 ```text
-实际可用上下文：取决于具体模型版本
+实际可用上下文：128K（最大）
 限制：无法同时加载所有内容
 
 分解策略：
@@ -380,17 +381,18 @@ class HybridArchitectureStrategy:
 4. 总计：≈100K tokens
 
 成本计算：
-- 系统提示缓存收益取决于厂商缓存价格与命中率
-- 用户合同+模板成本按实际输入 tokens 与官方输入单价计算
-- 输出成本按实际输出 tokens 与官方输出单价计算
+- 系统提示（缓存）：5K×$0.00025/K = $0.00125（首次$0.003125，后续折扣）
+- 用户合同+模板：95K×$0.0025/K = $0.2375
+- 输出：~2K tokens×$0.015/K = $0.03
+- 总成本/请求：$0.269（缓存命中后）
 
 质量折衷：无法同时引用所有模板，可能遗漏重要参照
 ```
 
 #### SSM/Mamba架构方案
 
 ```text
-可用上下文：取决于具体模型版本
+可用上下文：200K（轻松）
 完整使用：可同时加载所有内容
 
 完整策略：
@@ -400,10 +402,10 @@ class HybridArchitectureStrategy:
 4. 用户历史：5K
 5. 总计：245K tokens
 
-成本计算：
-- 输入成本约为裁剪方案的 `245K / 实际裁剪后输入 tokens` 倍
-- 输出成本按实际生成长度计算
-- 是否采用完整上下文，应由召回率、风险识别率、延迟和单次成本共同决定
+成本计算（使用GPT-5.4，假设与Transformer定价相同）：
+- 245K tokens×$0.0025/K = $0.6125
+- 输出：~2K tokens×$0.015/K = $0.03
+- 总成本/请求：$0.6425
 
 质量优势：
 - 模型可参考所有模板
@@ -412,7 +414,10 @@ class HybridArchitectureStrategy:
 - 一次完整分析，无遗漏
 
 ROI分析：
-完整上下文会提高单次 token 成本，但可能提升风险覆盖率。是否具备正 ROI，必须用真实合同样本、人工标注风险和错漏成本估算验证。
+成本增加：$0.6425 - $0.269 = $0.3735（139%）
+价值增加：更全面的法律风险识别，可避免潜在法律风险
+粗估：若识别一个风险可节省$5K法律费用，
+此方案年均ROI仍为正（按照合理的查询频率）
 ```
 
 ### 2.5.8 如何选择最适合的架构