专栏 · Agent 工程手艺 › 第 185 期 · AGENT 工程 · 收录于 2026 年 8 月 21 日
2026 年的上下文工程——Towards AI
LB
Louis Bouchard · AI Engineer
6,071观看
142赞
2.3%点赞率
10评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一花 500 多美元跑完 11 组对照实验后，他们撞上一个所有人都没料到的结论：完全不动 context、把完整历史原样留着，在「记得住 / 更便宜 / 更快」三条战线上同时打赢了所有 compaction（压缩，即把长对话历史摘要成短的再喂回去）技巧——因为一旦把历史 tool 输出裁掉，agent 就得为它本来已经拿到过的信息再检索一遍，反而更慢更贵。→ 详细
- 二让这个反直觉结论成立的是 prompt caching（提示词缓存，同样的开头部分第二次发就便宜很多）：「保留完整历史」那套配置发的 token 最多，但其中 97% 命中缓存，而缓存 token 在 DeepSeek 上便宜到 50 倍——所以「发得最多的那套跑起来反而最便宜」；反过来，任何 summarize / compaction 都会把缓存打掉、按全价重算，要划算得先把 context 压缩 50 倍以上。→ 详细
- 三真正能抄走的不是结论而是方法：他们把每一轮的 token 数 / 缓存命中 / 成本 / 首字延迟全埋点，定义死 preset / task / run / bundle 四个口径，用 60 对真实学生问答 + 人造多轮探针跑 eval（自动化打分）——这才发现自己凭「看着不错」定下的默认配置（5,000 token 清输出、3 万 token 摘要）在多轮任务上把质量拖到了 38%。→ 详细
01
起点：agent 犯蠢不是模型变笨了，是 context 被塞满了
- Louis-François 开场就把痛点摆出来：你让 agent 做事，它偏偏做出你最不想要的那个，你气得直接回怼它，指望它长记性。但「问题通常不是模型突然变笨了、你得换去 Claude 或者 Codex 或者别的什么 harness，而是 context 被越塞越满」——结果因此越来越差。→ 详细
- 这不是抽象烦恼，是他们的生意。Towards AI 做 AI engineer 的技术课程，配套功能之一是 AI tutor（基于课程内容答疑的助教机器人）。学员要是被气到，「他们可能直接就来退款」。→ 详细
- 三位讲者与分工：Louis-François Bouchard（Towards AI 几年前和合伙人一起创立，一直做教育，从早年的 computer vision 转到今天的 AI engineering / agent）讲理论与技术地图；Omar Solano 讲 AI tutor 的系统设计与第一批实验；Samridhi Vaid 讲扩展实验（换便宜模型、长 context、本地部署、规模化成本）。全部实验放在一个 Hugging Face space 上，AI tutor 本身也开源，在线可试。→ 详细
- 这个 AI tutor 就是所有实验的 baseline（基准物），基于真实用户交互来测各种方案。他们给它定了 5 条硬要求：① 回答必须扎根自家内容而不是模型自己的知识；② 锚定当前学员、当前这节课（他们有多门课程）；③ 撑得住长时间答疑会话（学员调 bug 会反复来回）；④ 能处理代码；⑤ 延迟足够低、用起来不挫败。这五条全都落在 context engineering 上。→ 详细
02
两个根问题：context window 有限 + 模型无状态
- 问题一，context window 是有限的——指令、课程内容、代码全挤在同一个有限空间里，塞得越多结果越差、花钱越多。问题二，模型是无状态的——学员重开一次 tutor，模型什么都不记得，从零开始。→ 详细
- 于是派生出两条工作线：context management（单次会话内部怎么管）和 memory（跨会话怎么记）。这场 workshop 只讲前者，理由很实在：「如果单次会话本身就一塌糊涂，那多轮会话根本无从谈起」——memory 那批实验做了但塞不进 80 分钟。→ 详细 → 详细
- tutor 每次调用时 context 里到底装了什么：system prompt（角色定义 + 课程背景）、tool 定义（有哪些工具、怎么用、何时用）、chat history、之前所有 tool 的输出（检索出来的课程 chunk）、最后才是用户提问。用户提问通常是里面最小的一块，但也可能塞满待调试代码和错误日志。→ 详细
03
真正撑爆 context 的是历史 tool 输出——而它的代价有三层
- 膨胀的主凶不是用户提问，是历史 tool 输出：所有旧 chunk、所有 tool call 与 tool result 的配对（来自一次会话中的很多轮、很多次调用）、以及它在自己 memory 里做的文件读取和搜索。→ 详细
- 第一层代价是质量，也就是 context rot（上下文腐烂，即塞进模型的历史越长、它反而越记不准前面说过什么）。Louis-François 给的成因解释很具体：大模型被训练去处理长 context 的方式，基本是「往一大堆语料里注入事实点」，这并没有教会它统筹管理整个 context、或者理解全局脉络。→ 详细
- 第二层是钱：一段对话里每追问一次，前面所有 token 都要再发一遍，同样的 token 付两遍、三遍、四遍。第三层是速度：TTFT（time to first token，从你发出到看见第一个字的等待时间）变长，体验直接变糟。所以「管理 context 不只是因为质量会下滑，也是为了速度和为了省钱」——这句话是整场实验的动机三角。→ 详细
04
compaction 第一层：不动大模型的土办法就能省一大截
- compaction 的思路一句话说完：让 context 小到刚好装下回答这个问题所需的信息，其余的要么丢掉、要么存到别处。而且不一定非得用大语言模型。→ 详细
- 三个便宜招：① 截断异常输出——某个工具平常吐 10 行、这次吐了 300 行，就把中间砍掉只留头尾，补一句「此处已截断」，模型觉得不够时可以再调一次；② 滑动窗口 / 直接截断——只保留用户最近 n 轮，n 按自己的系统和用户定，这是「最简单、但效果往往最好」的办法；③ 针对某些特定工具，永远把它们的大部分输出直接清掉。→ 详细
05
compaction 第二层：花 token 去省更多 token
- 上了语言模型这一层，本质是「花一些 token 去省下更多 token」。而且不用大模型也行，小模型、甚至能在一台 MacBook 上跑的超小本地模型就够。→ 详细
- 他们实验里效果最明显的几种：selective retention（选择性保留，让模型按对话走向判断哪些该留、哪些该丢）、summarization（持续把前面若干轮做摘要）、以及 Claude Code 那一套——触到上限就把前面所有内容生成一份摘要、带着摘要彻底重置。→ 详细
- 单独点名 delta summarization（增量摘要，Claude Code 在用）：维护一份摘要、根据后续产出的新摘要不断更新它，sub agent 再把它交回主 agent，在用 sub agent 时特别有用。但他们自己没用 sub agent——「这个 tutor 只用一个主 agent 就跑得很好，没必要为此增加复杂度」。→ 详细
06
第三条路 offload：RAG + Karpathy 的「LLM wiki」+ 一个 450 token 的索引
- 除了压缩，还可以把东西 offload（卸载）到外面——存进 memory 文档，或者用那个已经存在好多年的老办法 RAG（retrieval augmented generation，检索增强生成，即先去资料库里搜出相关片段、再喂给模型作答）。offload 的关键好处是完全可逆：什么都不丢，进行中的对话一点也不丢，只是存好等着被调回来。→ 详细
- 他们的结构照搬了 Karpathy 的 LLM wiki 想法：所有东西存成 chunk，chunk 之间用指针交叉链接，chunk 再链回来源的原始数据文件；上面架一个 index（索引），映射所有 chunk 并附一小段「这些讲的是什么」的说明。这套东西「既便宜又耐用，而且人和 agent 都很容易检查它」。→ 详细
- 关键数字：agent 平时只看到那个 index，大概只有 450 个 token。用户提问后，如果看起来跟 memory 里的东西相关，它才扫索引 → 顺着回到对应 chunk → 够了就答、不够就再回到原始数据拿更多。Louis-François 的定性是：「这是按任务复杂度来拉取 context 的最好方式——任务复杂就多拉一点，任务简单就少拉一点。」→ 详细
- 顺带一个被很多人忽略的对照结论：graph RAG（图谱式检索）他们也比过，在自己场景下「搭起来成本高得多，而效果基本打平」，这个判断 100% 基于真实用户评测。所以他们不用。但他不把话说死——如果你的数据集非常大、话题之间高度互联，可能就值得上，「你还是应该亲自测一测」。→ 详细
07
行业正在往「更多、更小的 skill」收敛
- 一句题外话但信息量很大：他们服务客户和自己实践看到的趋势是，大家都在往「skill 更多、更小」的方向收敛——做一堆小而精准、彼此可以互相引用的 skill，远好过做大 skill，可以按需一个一个加载，甚至只带着某一个专用 skill 的 context 去 spawn 一个 sub agent。归根到底是省 context，也就是 progressive disclosure（渐进式披露，只加载此刻真正需要的东西）。→ 详细
08
prompt caching 把整笔账重写了：于是 summarization 可能是个陷阱
- 这一段是整场的转折点。因为每次追问都要重算前面所有 token，各家 provider 现在提供 prompt caching：把 embedding 和 KV cache 存下来，已经算过的部分直接加载。关键在于这些被复用的 token 便宜非常非常多——在某些 API 上能便宜到 50 倍，比如 DeepSeek。意思是你发一段很长的 context，每个 token 只付十五分之一到五十分之一的价，只有新的这一轮交互按全价算。→ 详细
- 然后是那个刀刃般的推论：当你在做 compaction、做摘要、对 context 做任何变换时，provider 就用不上 cache 了——因为那是一段全新的 context，「模型没聪明到能理解这还是同一个话题、只是换了个写法」。这些被变换过的 token 你得按全价付。于是——要让 compaction 划算，你必须把 context 压缩 50 倍以上，而且不能掉质量，「某些情况下相当困难」。→ 详细
- 通用行情：开了 caching 一般能省掉约 90% 的成本，某些场景省得还要多得多；而且缓存的 token 是已经算过的，拿到第一个回答的速度也快得多。所以 Louis-François 下了一个很重的判断：「summarization 有可能是个陷阱。你可能压根就不该用它，或者只在非常特定的场合用。」→ 详细
- 佐证是那些「最认真的 harness」的做法：Claude Code、Codex 都在用 context caching，同时用另一套 compaction 方法——这一点他们能知道，一是因为那次泄漏，二是因为 Codex 是开源的。当你像他们一样自己搭 harness 时，「搞清楚什么时候该用哪种技术、并且真的去测它们，就变得特别有意思」。→ 详细
09
2026 年的实操清单：什么时候清、怎么优化命中、以及「把一切都 log 下来」
- 该清的时候清：用户明显换了个完全不同的话题时，刷新 session 把它清干净；限定范围或处理文件时，用 progressive disclosure 只露出最少量 context；把已经没用的旧 tool 输出全清掉；某些情况下才做 compaction。→ 详细 → 详细
- 为 cache 命中做优化，并且保持跟进——各家 provider 一直在改进管理 cache 的功能集，方法各不相同。他在 slides 第六、七页附了一篇讲 prompt caching 的文章链接，专门推荐去看。另外可以上 model router（模型路由器，按任务难度自动分派给不同价位的模型）来优化成本。→ 详细
- 最重要、也是大多数人不做的一件事：log everything（把所有东西都记下来）。他的说法几乎带着不耐烦：「这太简单了，你直接让 Claude 去实现、把一切都埋点追踪起来，你自己什么都不用干，所以绝对值得做。」可以追踪 cache 命中率、追踪用户挫败感（「我们看到 Claude 就在这么干，所以我不满意的时候会一直跟它讲」）、以及那些异常长的输出或任何小模型能识别出来的怪异行为。→ 详细
- 全场对 context engineering 的定义就一句话：「每次调用模型时，决定模型看到什么。」 落到 AI tutor 上就是——决定当前 context window 里保留什么以优化 caching、丢掉什么或 compact 什么、以及什么时候动手。前两件事正是后面所有实验研究的对象。→ 详细
10
AI tutor 的系统设计：一个 ReAct agent，靠 middleware 换装备
- Omar 接手第二部分。tutor 本身「其实非常简单」：一个 ReAct 型 agent（Reason + Act，即在「思考」和「调用工具」之间不断循环的经典形态），用 LangChain 的
create agent 方法搭、配 in-memory saver——他们不保存历史对话，只用当前这一轮的 history。外面套 FastAPI 做 endpoint，再加 Next.js UI 给学生用。→ 详细
- 定制全靠 LangChain 的 middleware（中间件，可在运行时改变 agent 行为的插件层）：summarize、清 tool 输出、让用户自选来源都挂在这一层——这正是后面能一口气跑 11 套配置做对照的工程前提。→ 详细
11
Tool 1：800 万 token 语料上的 hybrid search
- 语料库有多大：过去两年所有课程的全部课时，加上一堆公开开源库的文档——LangChain、LlamaIndex、OpenAI 官方文档（他们把「怎么用 OpenAI API、怎么用 Codex」的 markdown 都开放了）、Claude Code 文档。总共超过 800 万 token，根本塞不进任何一个 context window。→ 详细
- 第一个 tool 叫
retrieve tutor context，走经典 hybrid search（混合检索，语义检索 + 关键词检索两路并跑再合并）：用 Cohere 的 embedding 模型配 BM25（一种经典的关键词打分算法）做关键词索引，各取 top 30 chunk，两路合并后 rerank 到 top 5 返回给 agent，并设 10 万 token 上限——超了就把最后几个 chunk 去掉。→ 详细
- Omar 特意强调这些数字不是随便定的：他们做过专门实验优化这条 pipeline，方法是「尽可能多试各种配置、把 recall 提上去」，而 recall（召回率，即该找出来的资料实际找出来了几成）的判定标准是「有没有在知识库里检索到正确的那一页」。用户还可以事先勾选来源，等于给知识库加一层过滤提高 precision（精确率，即找出来的东西里有几成是真相关的）。→ 详细
12
Tool 2：让 agent 用 bash 自己去逛知识库（raw / generated / wiki 三层）
- 动机是个好问题：hybrid search 很精确，但如果 agent 需要浏览整个知识库才能给出最好的答案呢？比如「我想同时学 Codex 和 Claude Code，这两个工具怎么配合最好」这种要横跨好几页文档的问题。他在 slides 里附了一篇论文，结论是让 agent 去浏览知识库可能非常有帮助。→ 详细
- 于是有了第二个 tool
run knowledge base command，让 agent 用 bash 命令逛文件系统。知识库被离线整理成三个文件夹：raw（所有 markdown 原文件）、generated（自动生成的每个文件的标题清单，方便 agent 快速定位）、wiki（由 Claude Code 通读 raw 后生成的一组精炼文件，按主题 / 框架 / 来源组织，比如一个 fine-tuning 主题就能牵出所有相关原始文件）。→ 详细
- 安全与限流做得很细：只读沙箱（只放行不会改动文件系统的 bash 命令，只能逛知识库那一个文件夹）、单条命令超 8 秒就返回报错、tool 输出截断在 4 万字符（超长课时让 agent 自己发后续命令取剩下的）、每轮最多 20 条命令——「我们从没见过 agent 超过这个上限，这只是个兜底」。加新课程时就跟 Claude Code 说一句「把这个加到 raw 文件夹，顺便围绕新内容建几个新主题」。→ 详细
- 现在的 system prompt 下，agent 差不多 90% 的轮次都会用这个 tool。他们说这个比例是可调的，只是没专门优化。→ 详细
13
最诚实的一张成绩单：第二个 tool 加了等于没加，还慢 50%
- 这一段的价值在于它是个「否定结果」，而大多数分享不会讲。他们把这个 bash 浏览 tool 关掉再量一次，结果：recall 完全一样。也就是说「只用第一个 tool 就足以拿到全部相关信息」。→ 详细
- 而带着它的代价是：慢 50%。原因很朴素——「不用这个 tool 反而更快，因为 tool call 更少」。在「能不能引用正确的文档作答」这件事上也没看到任何提升。Omar 的原话是：「加它的过程挺好玩，但确实没看到什么收益。」→ 详细
- 他给了一个诚实的归因，而不是简单宣判这个技术无用：他们用的是真实世界的学生问题来测，「我们猜那些问题还不够复杂，没复杂到需要靠这套新配置才能受益」。换句话说——不是这个能力没价值，是你的真实流量还没难到需要它。这是一个可以直接搬到任何 agent 脚手架评估里的判断句式。→ 详细
14
他们承认：production 的默认配置是「看着不错」定的，一个数都没量过
- 这是全场我认为最值得记住的自曝。上线跑着的那套 context 管理配置，是这么来的：「我们一开始这么做，是因为它看起来快、看起来不错，其实我们什么都没量，就是觉得哦看着还行，那就这么设吧。」→ 详细
- 这套「看着还行」的默认配置具体是三条：① 超过 5,000 token 就清掉 tool 输出，但至少保留最近 5 条；② 超过 3 万 token 就把 history 摘要掉，但至少保留最近 20 条消息；③ source preference，让用户自选回答用哪些来源。三条听起来都很讲道理——这正是危险的地方。→ 详细
- Omar 给它下的定语是 unproven defaults（未经验证的默认值），然后接了那句贯穿全场的转折：「Lou 讲的那些技术听起来都很聪明，你会以为它们很有用，但有时候并不是。而且正如我们在实验里发现的，它甚至可能起反作用。」原因就是各家 API 缓存 token 的方式不同，「而且你也很难事先知道用哪种最好」。→ 详细 → 详细
15
每一轮都埋点：他们记了哪七个字段
- 现场演示了 Hugging Face 上那个独立 UI（课程页面里还嵌了聊天气泡版），左侧勾选数据源，右侧看 Gemini 3.5 Flash 做 reasoning 和 tool calling。活动面板里能看到这一轮「思考了四次、用了 10 个来源」，然后是最终答案。→ 详细
- 真正的地基是这句：「每次学生用这个 chatbot，我们其实都会把全部过程记录下来。」每一轮记七项：input token、output token、其中有多少命中缓存、花了多少钱、首个 token 的耗时、做了几次 tool call、系统有没有真的触发 summarization。→ 详细
- 请注意这七项的构成——它不是「用户满意度」这类事后问卷，而是每一轮都自动落下来的机器可读事实，而且成本、缓存、延迟、行为触发四类各有专项。后面所有实验之所以能跑，是因为这套埋点在上线第一天就有了：「这些非常有用，也正是我们衡量各种技术时要用的数据。」→ 详细
16
实验口径：preset / task / run / bundle 四个词必须先定死
- Omar 在放任何结果之前先花时间定义了四个词，这本身就是一个方法论信号——没有统一口径的 A/B 对比等于没做：→ 详细
- preset（配置档）：AI tutor 在这次实验里的配置方式。比如「这个 preset 在 X token 时做 summarization」「那个 preset 用 sliding window」。
- task（任务类型）：这批初始实验只做两种——single turn（单轮问答） 和 multiple turn / session（多轮会话）。
- run（一次运行）：把某个 preset 在某个 task 上完整跑一遍，就得到一次 run。
- bundle（结果包）：结果本身，一个落盘的 JSON 文件，里面是各项指标。
- 一个很省钱的工程决定：「我们可以把所有东西先跑出来，之后再打分」——跑一次、事后再评。这让「换个打分口径重评」不需要重跑一遍昂贵的模型调用。→ 详细
17
两个数据集：60 对真实问答，和一套人造的「事实 → 填充 → 探针」多轮测试
- 数据集一（single turn）：不是合成数据。 他让 Codex 把自家网站上所有「学生提问 + 工作人员解答」的问答对抓下来，清洗后只留 60 对。剔掉的是「关于某些库旧版本的老问题」——tutor 现在回答肯定不会再用那个旧版本了——以及重复项。测两件事：retrieval（有没有检索到正确的那节课，这个看代码就能自动判定）、以及回答里的事实对不对、回答类型是不是要的那种。→ 详细 → 详细
- 数据集二（session）：这个是刻意人造的，因为要测的是「多轮之后还记不记得」。 结构是四段式——① fact：让一个假学生在开头陈述一个事实（例：「我想学 RAG evaluation」）；② filler：往对话里塞一大堆填充消息，就是要把消息量堆起来；③ probe：让学生再问一句（例：「我今天该学哪个主题？」），期望 tutor 答出「你该学 RAG evaluation，更具体点比如 hit rate 和 MRR」；④ gate：确认被测的那个技术到底有没有真的发生（测 summarization 就得确认 summarization 真的触发了）。→ 详细 → 详细
- 这个 gate 环节是很多人做 eval 会漏的一环——如果被测机制压根没触发，这次 run 的结论就是假的。他们把它做成流程里的强制检查。→ 详细
18
eval harness 长什么样：代码校验 + LLM 打分 + 触发检查 + 自动报告
- 主函数就是 run task / run battery，负责把任务批量跑起来。打分分两路：代码校验（有没有检索到正确的那节课，机器可判）和 LLM as a judge（大模型当裁判，给事实准确性和回答类型打分）。→ 详细
- 一个很实用的省钱经验：LLM 打分别调 API。Omar 的原话是「现在最划算的方式是直接用你手上的 Claude Code 订阅或者 Codex 订阅，比调 API 便宜」。他们的裁判就是跑在 Claude Code 订阅上的。→ 详细 → 详细
- 另外两块：check triggers（确认这次 run 有效、compaction 到底有没有真发生，有效才存盘）和自动生成报告（latency、首个 token 时间，以及所有能测的指标）。整套东西加起来其实就是「一个能被重复跑、能被事后重评、能自己判断自己有没有跑坏的实验台」。→ 详细
19
11 个 preset、500 多美元，换来一个反直觉结论：什么都不动，三条战线全胜
- 实验设计：跑 11 个 preset，其中两个是参照点——full history（完全不动 context、历史原样保留）和 production（他们上线用的那套默认配置）——外加要对比的六种技术（sliding window、prompt compression、selective retention 等）。其他条件全部锁死：同一个模型、同一套 prompt、同样的工具、同样的数据集，只看 memory recall 差多少。→ 详细
- 账单：Omar 说「我没想到会超过 500 美元，但确实超了」；Samridhi 在接棒时把这个数说成「差不多 600 美元」。 这笔钱正是他们后来改用更便宜模型做跟进实验的直接原因。他们还跑了两组——一组每个配置跑 1 次，一组跑 2 次，「统计上会稍微稳一点，不过因为只跑了一到两次，数字未必准」，他自己承认最有价值的是排序而不是绝对值。→ 详细
- 结果出乎他们意料：跨多轮把那个事实回忆出来这件事上，「完全不动 context」反而是最好的策略。 而 production——「我们以为够好的那套默认配置」——并不是最优的，什么都不做反而更好。→ 详细
- 成本与质量的具体数字：production 配置下，单轮问答差不多 50 美分，多轮会话每轮 24 美分。单轮任务里几乎所有技术的 recall 都很好——因为单轮的 token 量根本不够触发那些策略，回答一次用不着 summarization、compaction。但到了多轮任务，质量掉到了 38%。跟 full history 一比，不动 context 更便宜、更快、整体 recall 也更好——「『全部保留』在这三条战线上都赢了」。→ 详细
- 为什么连延迟都更低？ 这是全场最漂亮的因果解释：「如果你一直把 tool 的输出裁掉，agent 之后就得为它本来已经拿到过的信息再去检索一遍。」 你等于是在逼 agent 做更多次 tool call——于是钱花得更多、token 用得更多、memory recall 反而更差。你以为你在省 context，实际上你在制造重复劳动。→ 详细
- 他也主动划定了这个结论的边界：这批结果是在 Gemini 3.5 Flash 上、用一个只有 11 到 13 轮的数据集跑出来的，「不算大，消息也不多」——所以才有了后半场的扩展实验。→ 详细
20
换 DeepSeek V4 Flash：缓存折扣是 Gemini 的 50 倍，而结论不变
- Samridhi 接棒后先框定问题：「compaction 到底什么时候才有意义？你到底该不该做 compaction？」 因为已经很清楚地看到，把完整答案都留在窗口里效果非常好，但很费钱——在 Gemini 这种前沿模型上跑 full history「会非常非常贵」。→ 详细
- 她先把 AI tutor 实际遇到的 context 分成三类，因为「每一类需要的解法也不一样」：① 很长的聊天历史（学生问过什么、聊过什么，细节全被埋掉）；② 粘贴进来的文档（不少学生会直接复制粘贴一大堆进来，而 context window 是有限的）；③ 内部工具吐出来的一堆日志。→ 详细
- 然后换模型：DeepSeek V4 Flash。成本差距「非常悬殊」，主要原因是缓存折扣——DeepSeek 的缓存折扣是 Gemini 的 50 倍。而关键在于：在 DeepSeek 上，「保留全部 context」依然是性能最好的那一档。「便宜的模型是把成本压下来的原因，但结果是一样的。」→ 详细
21
记忆实测：全保留 95%，摘要后 32%
- 测法很干净：拿系统里真实的学生对话（问的是环境配置、遇到的报错、已经试过哪些办法），针对里面的具体细节提问，看模型能不能把它挖出来。→ 详细
- 结果：保留全部细节时，95% 的时候模型能给出那个准确细节；先做 summarize 或对 context 做 compaction，只有 32%。 差距近三倍。→ 详细
- 原因不玄：「一做 summarize，那些必要的细节就被删掉了。」 你留不住细节，模型就会一直漏。她顺手推翻了一个流行的直觉：并不是对话一长模型就记不住了——用 DeepSeek 这类模型时，它 95% 的时候都答对。→ 详细
22
最反直觉的一笔账：发 token 最多的那套跑起来最便宜
- 「在 DeepSeek 上我们看到的结果是：发送 token 最多的那套配置，跑起来反而最便宜。」保留完整历史的配置发的 token 最多，效果还最好——因为其中 97% 的 token 都命中了缓存，而 cached token 是单独计费的、非常便宜。→ 详细
- 而 summarize 的效果正好相反：每一轮模型都要重新读、重新写新的 token——每一次摘要都是一批全价的新 token。→ 详细
- 压力测试的规模：她在一段 36 轮、约 178 万 token 的对话上跑过这个实验，结果还是「全都留着」更划算。这也回答了前半场留下的疑问——这不只是 Gemini 的特性，DeepSeek 上同样成立。→ 详细
23
长 context 压测到 80 万 token，没看到 context rot——以及规模化时的真实账单
- 长 context 结果：即使只是从里面捞某一个特定细节，模型表现也相当好。图上那条绿线代表「有明显区分度的事实」——一直到 80 万 token，模型都没有漏掉这些事实，结果既准确又稳定。对于比较模糊、有歧义的事实，表现会掉到区分度高的那一半左右，但「对我们的 AI tutor 来说，这个结果已经很好了」。结论：即使完全不做 compaction，哪怕对话非常长，模型也扛得住。→ 详细
- 然后她把账从「每轮」放大到「规模」——这是很多成本讨论会漏掉的一步：「chatbot 不是一轮就结束的事情」，tutor 是长期服务，学生会大规模地提问。假设每天 10 万到 100 万轮提问，在 DeepSeek 上算下来大约是每月 1.8 万到 18 万美元。 她坦承「我们现在还没有这个量级，但按 token 付费确实会越滚越多」。→ 详细
- 另一个口径的同一笔账（她后面总结时给的）：按一千名学生算，Gemini 大约每月 4 万美元，DeepSeek 只要 1,900 美元左右——同样架构只换模型，成本差 20 倍以上。正是这个数字把「要不要转本地模型」推上了议程。→ 详细
24
本地路线的天花板：MacBook 32K，把模型从 7B 换到 32B 也救不回来
- 硬件限制下他们只在一台 MacBook 上测，能跑到的最大 context window 是 32K。而他们自己的课程内容单篇就超过 32K——一旦对话装不进窗口，缓存就帮不上忙了，必须把 context 变小：要么压缩，要么只检索用得上的那部分。在本地，「什么都留着」这条路直接走不通。→ 详细
- 一个必须点破的误解：他们从 7B 换到 8B、再换到 32B，结论是「模型规模再怎么加，也不会把 context window 变大，这一点是修不了的，你必须在这里做取舍」。 参数量和上下文窗口是两件事。→ 详细
- 意外的好消息与意外的坑各一个：本地对文档做检索效果非常好，准确率能到 100%，处理时间在 25 到 65 秒之间——所以「当学生粘贴进来的内容太大时，RAG 是个好选择」。但如果你硬要往窗口里塞超出容量的 context，在对话非常长的情况下，大约要 340 秒才出结果，而输出只有一个 token——「你什么都没拿到，还白白浪费了大量时间」。→ 详细 → 详细
25
检索策略压测：dense RAG 在 40 万 token 掉到 0%，BM25 每次 100%
- 默认的检索方式是语义搜索（去匹配文本的含义，图表上标 dense RAG）。从 5 万 token 一路试到 20 万 token，dense RAG 表现都很好，大概能到 80%。→ 详细
- 但当量提到 40 万 token 时，它就找不出「埋在中间」的事实了，召回率直接掉到 0%；而同样条件下 BM25 依然每次都是 100%。 这是全场落差最大的一组数字——语义检索不是渐进变差，是断崖式失效，而那个被认为「土」的关键词算法稳如老狗。→ 详细
- 结论直白：「光靠语义搜索是不够的」——这正是他们 AI tutor 一开始就用 hybrid search、把 dense 和 BM25 结合起来的原因。前后两段在这里闭环了。→ 详细
26
本地 vs 云端并排，五条总结论，和一句话总纲
- 并排对比：在 chat 这块，云端「全都留着」能拿到 92%–95% 的分数，而本地卡在 33% 左右，瓶颈就是 context window。但本地模型确实可行——硬件是你自己的，成本那一栏几乎看不到数字，代价是吞吐量受限；而且只要用上检索这类技术，本地方案也能拿到不错的准确率。→ 详细
- 她把全场收成五条：① 记忆——全保留召回约 95%，summarize 只有 32%；② 长 context——找单个事实很容易，测到 80 万 token 都没观察到 context rot；③ 单轮成本——最便宜的那次运行恰恰是发 token 最多的那一次；④ 规模化成本——一千名学生时 Gemini 约 4 万美元/月、DeepSeek 约 1,900 美元/月，走本地还能再省；⑤ 总纲——「不要默认就去做 compaction。你得先说清楚自己面对的约束是什么，然后再去找更好的方案。」→ 详细
- 最终选型：DeepSeek V4 Flash（有硬件限制，云端架构对他们效果最好；按当前学生量算也是最便宜的）+ hybrid retrieval + 记忆全保留，只设一个默认上限——超过 3 万 token 之后才做 compaction，在那之前全部保留。有意思的是这个 3 万 token 的阈值和他们原来「看着还行」定的 summarize 阈值数值一样，但这次是被 500 多美元的实验反复验证过才留下的。→ 详细
- 收尾时她说明了取舍：「因为时间有限，我能塞进这段分享的评测和实验就这些了」，想深入或想自己做一个 tutor，可以去他们的全栈 AI 工程课程。现场以掌声结束，没有留下 Q&A 内容。→ 详细 → 详细
27
联系方式 / 公开资源
- Towards AI Academy 全栈 AI 工程课程：
academy.towardsai.net（Samridhi 收尾时给出，想自己做一个 tutor 或深入了解这批评测就去这里）→ 详细
- 全部实验 + 在线可试的 AI tutor：现场二维码指向的 Hugging Face space（URL 未在口播中念出，在 slides 里）→ 详细
- AI tutor 全部代码开源：repo 链接同样在 Hugging Face space 与 slides 上——「你们可以用自己顺手的 coding agent 去逛这个代码库，看我们具体是怎么实现的」→ 详细