📚 首页 / 01-llm-foundations/labs / lab.md

模块 1 动手实验 — LLM 基础

目标：把 README 里的概念变成你手指的记忆。全部实验无需 API key（Lab 5 可选接 key 做精确验证）。 预计时长：60–90 分钟。

Lab 1.1 — Token 预算规划器（必做）

🎯 学习重点：会写并解释“输入各项 + 输出预留 ≤ 窗口”，同时证明换大窗口不能消除 context rot 与累计重发成本。

任务：运行并改造 examples/token_estimation.py。

  1. 运行 python3 examples/token_estimation.py，确认输出正常。
  2. 把 plan_context_budget() 中的 history_msgs 扩到能模拟 300 轮对话（约 600 条消息），观察剩余预算何时跌破 10% 阈值。
  3. 切换 model="claude-haiku-4-5"（200K 窗口），观察同样的历史何时超限——记录这个临界点。
  4. 回答：超限时输出提示"压缩历史 / 检索裁剪 / 换更大窗口模型"，结合模块 01 的 context rot 概念，为什么"换更大窗口"不一定是首选？

验收：能说出你的模拟对话在 Haiku 4.5 上大约多少轮超限，以及三种应对策略各自的代价。

架构师加码：

Lab 1.2 — 图片 token 心算（必做）

🎯 学习重点：必会 28×28 patch 的双向上取整，并识别“先按原图算”在自动缩放边界外会高估。

任务：用 ⌈宽/28⌉ × ⌈高/28⌉ 手算三张图，再用脚本验证：

图片你的估算脚本结果
800×600 截图??
1920×1080 全高清??
3840×2160 4K??

注意：手算结果要对照官方 vision 文档的两档分辨率（Claude 4.7+ 高分辨率档：长边上限 2576px、最多 4784 视觉 token；标准档：长边 1568px、最多 1568 token）——超过档位上限的图会被自动缩放，token 不会线性增长。来源: https://platform.claude.com/docs/en/build-with-claude/vision（访问于 2026-08-30）

验收：解释"为什么发 4K 图不一定花 4 倍 token"，以及哪些模型吃高分辨率档。

自检边界：800×600 的原始 patch 计算为 ⌈800/28⌉×⌈600/28⌉=29×22=638；1000×1000 为 36×36=1,296。若你对 4K 直接得到远高于档位上限的数字，下一步不是把该数字用于报价，而是先按官方缩放规则求有效尺寸。

Lab 1.3 — 上下文里什么算 token（必做，纸面审计）

🎯 学习重点：易错题是 cache read——仍占 Context Window，但多数模型不占 ITPM；“缓存”不等于“免费”或“扩窗”。

任务：找一个你真实项目（或想象中的客服助手）的请求，列出下面每一项的 token 占用估算与来源：

组成是否计入上下文窗口计入 ITPM 速率限制？
system prompt
对话历史（含 tool_result）
工具定义 tools 数组
图片（28×28 patch）
本轮输出（含 thinking）
命中 prompt cache 的前缀（多数模型）计入不计入（见模块 3 rate limits）

依据：来源: https://platform.claude.com/docs/en/build-with-claude/context-windows 与 https://platform.claude.com/docs/en/api/rate-limits（访问于 2026-08-30）

验收：表格填对，特别是不掉进"缓存命中 token 也占 ITPM"的坑（多数模型不占；Haiku 3.5 例外，但它已 retired）。

审计追问：若请求已经使用 180K 输入、模型窗口 200K，而 max_tokens=64K，预算是否成立？答案是不成立：最大输出受窗口剩余量与模型自身输出上限的共同约束，不能把 200K 与 64K 相加。

Lab 1.4 — 温度直觉实验（纸面推演）

🎯 学习重点：把“采样概念”与“具体模型 API 支持”分开答；4.7+ 新模型省略参数，格式保证交给 schema。

任务：截至 2026-08-30 的关键事实：temperature/top_p/top_k 仍被 Messages API 文档记录，但在 Claude Opus 4.7 及之后的模型上已弃用——非默认值直接返回 400（来源: https://platform.claude.com/docs/en/about-claude/model-deprecations（访问于 2026-08-30））。

  1. 对下面三个任务，分别写出你会选 temperature 0 / 1，还是"新模型上直接不传"：
  1. 回答：既然 temperature=0 也不能保证 JSON 合法，架构上正确兜底是什么？（提示：模块 05 的 结构化输出 (Structured Output) / schema 校验）

验收：能准确说出"哪些模型还能用 temperature、哪些不能"，以及确定性输出靠什么保证。

反模式检查：如果答案写“Opus 5 用 temperature: 0 保证 JSON”，同时犯了两错：请求会因非默认值返回 400；即使在仍支持该参数的模型上，低温也不能提供 schema 保证。正确链路是省略弃用参数 → Structured Output/strict tool use → 业务字段校验 → 必要时人工兜底。

Lab 1.5 — 用 count_tokens 校准你的启发式（可选，需 key）

🎯 学习重点：架构估算必须量化误差分布；平均误差不能替代最大误差或高分位余量。

任务：若你有 API key，写 10 段中英混合文本（含代码片段、表格），分别用 POST /v1/messages/count_tokens（Token Counting API，来源: https://platform.claude.com/docs/en/api/overview（访问于 2026-08-30））和 Lab 1.1 的启发式估算，记录误差百分比。无 key 则跳过，记住结论：报价前必须用 count_tokens，不能用字符数估。

验收：给出你测得的启发式最大误差，并说明它对成本估算的影响量级。

建议记录 文本类型 / 字符数 / 启发式 token / API token / 绝对误差 / 误差率。至少把中文、英文、代码、JSON、Markdown 表格分组；若样本仅 10 条，不要把结果外推成通用 tokenizer 比例。

完成检查表

🎯 学习重点：完成不等于跑过脚本；必须能用 stop_reason、usage 和预算不等式解释应用层动作。
📚 目录