阿甘的博客 | Arganzheng's Blog

置顶致读者的一封信

这里写什么、怎么读、怎么告诉我哪里不对

你好，欢迎来到这里。这封信讲三件事：这里写什么、读的时候有哪些顺手的小功能、怎么告诉我哪里写得不对。这封信本身就是演示场地，下面提到的功能都可以直接在这里试，随便划、随便点，不会弄坏什么。一、这里写什么主要是技术，近两年集中在 AI 工程。内容按三张学习地图组织——AI 算法工程师、AI-Infra 工程师、AI 应用工程师——地图下面是三十多个系列，比如《大模型推理系统揭秘》《GPU Kernel 工程》《通信与互联》。每个系列有总纲、正文和一篇总结自测；文章开头告诉你它是第几篇，文末有整个系列的目录。导航栏的 Series 是全部系列的树，系列列表也标出「入门 / 进阶 / 深入」，方便按难度挑选。更早的文章（2009 年起）是 Java、数据库...

Posted by arganzheng | August 3, 2026

置顶AI 全栈学习地图：造模型、跑模型、用模型的三张图

One System, Three Roles — an Overview of the Three AI Learning Roadmaps

内容简介这个博客的技术文章围绕三张学习地图组织：《AI 算法工程师学习地图》、《AI-Infra 工程师学习地图》、《AI 应用工程师学习地图》。每张地图把一个方向的知识分层，说明每层回答什么问题、按什么顺序学、哪些已经写成了系列。本文是三张地图之上的一页总览，回答的是三张地图各自不回答的问题：为什么是三张而不是一张？三张地图之间怎么分工、在哪里交汇？一个人该从哪一张进入，读到哪里该换到另一张？1 三张地图对应的是同一个系统里的三种角色。一个大模型从数据到用户手里，要被造出来（预训练、后训练、评测）、被跑起来（引擎、集群、平台）、被用起来（检索、工具、编排、产品）。三件事用同一批名词——Python、PyTorch、Transformer、KV c...

Posted by arganzheng | January 1, 2026

检索与知识接入（03）：文档解析与分块——检索失败的上游

Document Parsing and Chunking: Where Retrieval Fails Upstream

向量库里存的是什么，取决于文档被解析成了什么、又被切成了什么。一份两栏 PDF 被逐行交错成流畅的胡话、一张财务表格被压成一段丢掉了行列、每一页的页眉被注入到每一个块里——这些错误产出的 markdown 看起来干净，embedding 照常算，检索照常返回，只是返回的东西不对。一个开源解析器基准的作者把它叫作”RAG（retrieval-augmented generation）流水线里最大的静默失败来源”。本篇讲检索的上游：解析（把文件变成结构化文本）与分块（把文本切成检索的单位），以及块上要带什么元数据。 2025 年这一层的格局换了一遍：Docling 1.0、Marker 1.0、MinerU、Mistral OCR、OlmoOCR、PaddleOCR-...

Posted by arganzheng | October 15, 2026

检索与知识接入（02）：三类检索——词法、向量、结构化，coding agent 为什么只用 grep

Three Kinds of Retrieval: Lexical, Vector, Structured — and Why Coding Agents Grep

“RAG”（retrieval-augmented generation）这个词让很多人以为检索只有一种做法：切块、embedding、向量库、top-k。实际上检索有三类，各有前提条件，生产系统几乎总是混用：词法 / 精确（grep、glob、BM25（Best Matching 25）、全文索引），向量 / 语义（embedding + 近似最近邻），结构化（SQL、API、图谱、本体）。三类不是新旧之分，是适用条件之分——同一份语料满足哪类的前提，就用哪类。 2025–2026 年最好的教材是 coding agent 的架构分歧。Claude Code 的团队公开说他们从 RAG 加本地向量库起步，然后放弃了它，因为 agent 拿着 grep 自己搜”通...

Posted by arganzheng | October 14, 2026

检索与知识接入（01）：进上下文还是进权重——知识类型决定接入方式

Knowledge in Context or in Weights: The Type of Knowledge Decides

通用模型不知道你的业务：不知道你的退款政策、不知道你的产品型号、不知道你的代码库、不知道”活跃客户”在你们公司的定义。让它知道有两条路：放进上下文——每次请求时把相关内容检索出来放在 L2 讲的那一层里，或者让模型调工具去查；放进权重——用你的数据微调或继续预训练。两条路的成本、灵活性、可追溯性差一个量级，而多数团队第一次做决定时选错了方向：想让模型”学会”产品手册，于是拿手册做 SFT（supervised fine-tuning）。这一篇只做一件事：给出知识类型 → 接入方式的决策表，并解释每一格为什么这样填。它是整个系列的入口——后面六篇讲的检索、解析、索引、agentic、结构化、评测，只对走了”进上下文”这条路的知识有意义；而”该不该微调”这个问题，本...

Posted by arganzheng | October 13, 2026

检索与知识接入：私域知识怎么进入模型（总纲）

Retrieval and Knowledge Access: How Private Knowledge Gets into the Model

术语与缩写本文用到的术语与缩写缩写全称一句话解释 L3 — 应用地图第三层：检索与知识接入，即本系列 L1 — 应用地图第一层：模型作为组件 L2 — 应用地图第二层：Prompt 与上下文工程 agent — 能自己调工具、多步完成任务的模型程序 RAG retrieval-augmented generation ...

Posted by arganzheng | October 12, 2026

Prompt 与上下文工程（07）：系列总结与通关自测

Prompt and Context Engineering: Series Recap and Final Self-Test

六篇正文回答了一个问题：模型这一步该看到什么、看多少、按什么顺序，以及怎样像管代码一样管它。第一篇解剖上下文的七层，第二篇讲 system prompt 里稳定的模式与不稳定的措辞，第三篇讲结构化输出的机制与 schema 设计，第四篇讲预算与卸载 → 清理 → 压缩的处理顺序，第五篇讲缓存与排列，第六篇讲版本、评测门禁、两个跨工具标准与上下文 vs 检索的决策。六篇合起来是《AI 应用工程师学习地图》第二层：把”模型看到什么”当作一个有预算、有顺序、有版本的工程对象。本文不讲新内容：一张总表与六段回顾，贯穿六篇的四条线，常见误区，然后是三段式通关自测——判断与计算、跨篇综合、面试题。各篇末尾的自测检验”这一篇读懂了没有”，这里检验”六篇能不能连起来用”。 ...

Posted by arganzheng | October 11, 2026

Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索

Prompts as Code: Versioning, Evals, A/B Testing, and Context vs Retrieval

前五篇讲了上下文的每一层怎么写、怎么约束、怎么压、怎么排。这一篇讲怎么管：prompt 改一个词就是一次发布——它改变模型的行为，可能让评测集里三条用例由对变错，可能让缓存前缀全部失效；模型升级是一次依赖升级——同样的 prompt 在新模型上遵循率不同（第二篇）。把 prompt 当文案管的团队会在某个周五下午改一句话直接上线，周一从用户投诉里发现回归。把 prompt 当代码管的团队有版本、有测试、有灰度、有回滚。本篇有三部分。工件与流程：prompt 放版本库还是注册表，怎么与模型版本绑定，改动要跑什么、怎么灰度、怎么回滚，A/B 怎么做。两个跨工具的 prompt 标准：AGENTS.md（2025 年 8 月发布的开放格式，六万多个开源项目采用，Lin...

Posted by arganzheng | October 11, 2026

Prompt 与上下文工程（05）：prompt caching 与上下文的排列

Prompt Caching and Context Layout

《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》算过缓存的账：命中读价 0.1×（Fable 5.1 0.025×、DeepSeek 0.02×），写入 1.25×，读一次就回本，多轮对话的二次增长被乘上 0.1。这一篇讲怎样让它命中——这是一个排列问题：缓存的是逐字节相同的前缀，所以上下文里每一段的位置、每一个字节是否稳定、每一次修改发生在哪，直接决定命中率。Manus 把 KV-cache（key–value cache）命中率列为”生产 agent 最重要的单一指标”，理由是它同时决定成本与 TTFT（time to first token），而 agent 的输入输出比是 100 : 1——几乎全部成本都在可缓存的那一侧。前四篇讲...

Posted by arganzheng | October 10, 2026

Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办

Context Budgeting, Offloading and Compaction

第一篇算过：一个 agent 会话的上下文按每步几千 token 增长，50 步就能填满 200K 窗口，原始目标漂到窗口中间。这一篇讲怎么办。答案不是一个开关，是一条代价递增的处理顺序：先不让无关内容进来（卸载、隔离），再清掉已经没用的（清理），最后才用一次模型调用把历史摘要成一段（压缩）——压缩最贵、最有损，放在最后。这一篇的材料几乎全部来自公开的生产系统：Claude Code 在窗口约 83.5% 处 auto-compact、预留 33K、压缩后 CLAUDE.md 从磁盘重注入而按路径的规则丢失；Codex 先试”会话记忆压缩”不调模型、不够才调服务端的 /responses/compact 拿回一个加密 blob，触发点在轮前与循环边界两处；Lan...

Posted by arganzheng | October 9, 2026

Prompt 与上下文工程（03）：结构化输出——约束解码、schema 设计与失败修复

Structured Output: Constrained Decoding, Schema Design and Failure Repair

《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》把结构化输出分成三个层次——提示、JSON 模式、schema 约束——并给了一句结论：schema 约束保证语法不保证语义。这一篇把那一句展开成一篇：约束解码在推理引擎里是怎样实现的、为什么它能给出”不可能生成不合法 JSON”这样的硬保证、为什么 strict 模式对 schema 有限制；然后是应用侧的两件事——schema 怎么设计才既可靠又不损害模型的推理（字段顺序就是生成顺序，拒答要有出口，枚举替代自由字符串），解析层怎么写才能处理 schema 保证不了的那一半（业务校验、修复重试、流式部分 JSON、截断）。结构化输出是应用工程里少见的”硬”...

Posted by arganzheng | October 8, 2026

Prompt 与上下文工程（02）：prompt 设计——稳定的模式与不稳定的措辞

Prompt Design: Stable Patterns, Unstable Wording

上一篇把上下文分成七层，第一层——系统指令——是传统意义上”prompt 工程”的对象。这一篇专讲它，但换一个角度：把 prompt 里稳定的部分与不稳定的部分分开。稳定的是模式：明确角色与任务、把规则写成可检验的条款、用结构分区、说明工具何时用、给出输出格式。不稳定的是措辞：具体的句子、例子、语气——它们随模型变，供应商为每个新模型发一份 prompting 指南就是证据；《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》把”prompt 敏感”列为七条失效模式之一，讲的就是这个不稳定。 2026 年还有一件事让这个区分更重要：主力模型都是推理模型（《模型作为组件（03）：API 契约（二）——推理模型：th...

Posted by arganzheng | October 7, 2026

Arganzheng's Blog