Tweets

Today Gmail is taking the first big step into the Gemini era, say hello to AI Inbox, AI Overviews in Gmail, and so much more!!

New post: nanochat miniseries v1

The correct way to think about LLMs is that you are not optimizing for a single specific model but for a family models controlled by a single dial (the compute you wish to spend) to achieve monotonically better results. This allows you to do careful science of scaling laws and ultimately this is what gives you the confidence that when you pay for "the big run", the extrapolation will work and your money will be well spent. For the first public release of nanochat my focus was on end-to-end pipeline that runs the whole LLM pipeline with all of its stages. Now after YOLOing a few runs earlier, I'm coming back around to flesh out some of the parts that I sped through, starting of course with pretraining, which is both computationally heavy and critical as the foundation of intelligence and knowledge in these models.

After locally tuning some of the hyperparameters, I swept out a number of models fixing the FLOPs budget. (For every FLOPs target you can train a small model a long time, or a big model for a short time.) It turns out that nanochat obeys very nice scaling laws, basically reproducing the Chinchilla paper plots:

Which is just a baby version of this plot from Chinchilla:
Very importantly and encouragingly, the exponent on N (parameters) and D (tokens) is equal at ~=0.5, so just like Chinchilla we get a single (compute-independent) constant that relates the model size to token training horizons. In Chinchilla, this was measured to be 20. In nanochat it seems to be 8!

Once we can train compute optimal models, I swept out a miniseries from d10 to d20, which are nanochat sizes that can do 2**19 ~= 0.5M batch sizes on 8XH100 node without gradient accumulation. We get pretty, non-itersecting training plots for each model size.

Then the fun part is relating this miniseries v1 to the GPT-2 and GPT-3 miniseries so that we know we're on the right track. Validation loss has many issues and is not comparable, so instead I use the CORE score (from DCLM paper). I calculated it for GPT-2 and estimated it for GPT-3, which allows us to finally put nanochat nicely and on the same scale:
The total cost of this miniseries is only ~$100 (~4 hours on 8XH100). These experiments give us confidence that everything is working fairly nicely and that if we pay more (turn the dial), we get increasingly better models.

TLDR: we can train compute optimal miniseries and relate them to GPT-2/3 via objective CORE scores, but further improvements are desirable and needed. E.g., matching GPT-2 currently needs ~$500, but imo should be possible to do <$100 with more work.

Full post with a lot more detail is here:
github.com/karpathy/nanoc…
And all of the tuning and code is pushed to master and people can reproduce these with scaling_laws .sh and miniseries .sh bash scripts.

--- 提示词 ---

# 角色定义
你是一位专业的小红书视觉内容策划师，擅长将复杂内容拆解为吸引眼球的卡通风格系列信息图。

# 任务
请分析以下输入内容，将其拆解为 1-10 张小红书风格的系列信息图，并为每张图片输出独立的生成提示词。

# 拆解原则
1. **封面图（第1张）**：必须有强烈视觉冲击力，包含核心标题和吸引点
2. **内容图（中间）**：每张聚焦1个核心观点，信息密度适中
3. **结尾图（最后1张）**：总结/行动号召/金句收尾

# 图片数量判断标准
- 简单观点/单一主题：2-3 张
- 中等复杂度/教程类：4-6 张
- 深度干货/多维度分析：7-10 张

# 视觉风格规范（重要）
## 基础设定
- **图片类型**：信息图（Infographic）
- **方向比例**：竖版，3:4 或 9:16
- **整体风格**：卡通风格、手绘风格

## 背景与配色
- 背景色：莫兰迪色系 / 奶油色 / 米白色 / 浅粉 / 薄荷绿等温柔色调
- 配色柔和统一，符合小红书审美

## 文字风格
- **必须使用手绘风格文字**
- 大标题突出醒目，重点文字加粗放大
- 可使用荧光笔划线效果强调关键词
- 禁止使用写实风格字体

## 装饰元素
- 加入少量简洁的**卡通元素、图标或名人画像**，增强趣味性和视觉记忆
- 可使用：emoji 风格图标、手绘贴纸、便签纸质感、对话气泡等
- 如涉及敏感人物或版权内容，画一个风格相似的卡通替代形象，不要拒绝生成
- **所有图像元素必须是手绘/卡通风格，禁止写实风格图画**

## 排版原则
- 信息精简，突出关键词与核心概念
- 多留白，易于一眼抓住重点
- 要点分条呈现，层次清晰

# 输出格式
对于每张图片，请按以下结构输出：

---
### 第 X 张 / 共 N 张
**图片定位**：[封面图 / 内容图 / 结尾图]
**核心信息**：[这张图要传达的1句话核心]

**文字内容**：
- 主标题：xxx
- 副标题/要点：xxx
- 补充说明（如有）：xxx

**视觉提示词**：
```
小红书风格信息图，竖版（3:4），卡通风格，手绘风格文字，[具体背景色]背景。

[具体内容布局描述]

加入简洁的卡通元素和图标增强趣味性和视觉记忆：[具体元素描述]

整体风格：手绘、可爱、清新，信息精简，多留白，重点突出。所有图像和文字均为手绘风格，无写实元素。
右下角水印：“宝玉”
```
---

# 语言规则
- 除非特别要求，输出语言与输入内容语言保持一致
- 中文内容使用全角标点符号（“”，。！）

Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon

@Aish_Reganti and @KiritiBadam have built 50+ enterprise AI products across companies like @OpenAI, @Google, @Amazon, and @Databricks. Based on these experiences, they’ve developed a small set of best practices for building and scaling successful AI products. Our goal with this conversation is to save you and your team a lot of pain and suffering while building your AI products.

We discuss:
🔸 Two key ways AI products differ from traditional software
🔸 Common patterns and anti-patterns when building successful AI products
🔸 Their framework for iteratively building AI products
🔸 Why evals aren’t a cure-all
🔸 Why obsessing about customer trust and reliability is an underrated driver of successful AI products
🔸 The skills that matter most for builders in the AI era

Listen now 👇
• Yoyoutube.com/watch?v=z7T1pC…um0oykC
• Spopen.spotify.com/episode/5KABq3…X3HDtcA
• podcasts.apple.com/us/podcast/wha…O2Pwwbb

Thank you to our wonderful sponsors for supporting the podcast: 
🏆 @merge_api — The fastest way to ship 220+ integrmerge.dev/lennyYWXAImDG
🏆 @strella_io — The AI-powered customer research pstrella.io/lennyt9eCM2jnG
🏆 @brexHQ — The banking solution for brex.com/product/busine…3Er6oYC7vL

为什么说 Dify 这样的 workflow 编排有市场：
1. 如 @hongming731 所说，确定性强，可观测可审计
2. 简单方便，拖拽就可以
3. 使用者不需要写代码或者少量代码

workflow 编排的缺点是：
1. 不如代码强大
2. 不如 Agent 灵活可以应对很多复杂场景
3. 同样的 flow 不方便移植，比如你有个牛逼的 flow

为什么说大部分场景会被 agent + skills 替代：
1. 有价值的workflow可以由有经验的程序员（甚至普通人借助 AI）把它变成skill（prompt + script + docs + etc）
2. 接入 Agent 后会让它更灵活更强大
3. 一旦 workflow 被变成 skills，可以方便的分享和移植

agent + skills 当然也有不足：
1. 更费 Tokens，对模型要求也高
2. Skills 是本地执行，或者说和 Agent 一起执行，特定场景还是需要外部服务支撑，比如说你本地就不方便做 RAG，可能还得放到服务端，这些服务得以 MCP 形式提供

[Anthropic Engineering]
AI Agents 评估方法论：从混沌到清晰的工程实践
anthropic.com/engineering/de…

核心问题与背景
Anthropic 指出了 AI Agents 评估的本质矛盾：使 Agents 有用的那些能力（自主性、智能性和灵活性），恰恰是让其难以评估的根源。 与传统的单轮对话不同，Agents 系统需要跨多轮交互、调用工具、修改状态并基于中间结果进行动态调整，这使得评估复杂度呈指数级增长。

评估的结构化框架
一套清晰的术语体系对于标准化评估实践至关重要：
· 任务层面（Task）：单个测试案例包含明确的输入和成功标准。由于模型输出的非确定性，需要多次试验来获得稳定结果。
· 评分层面（Grader）：通过“评分器”来检验 Agents 性能的各个方面。一个任务可以有多个评分器，每个评分器包含多项断言检查。
· 记录层面（Transcript）：“转录本”记录完整的试验过程，包括所有工具调用、推理步骤和中间结果。这与最终的“结果”不同—— Agents 可能声称完成了任务，但环境中的实际状态才是真正的验证标准。
· 基础设施层面（Harness）：“评估框架”负责端到端运行评估，而“Agents 工具”则是使模型能够作为 Agents 运行的系统。评估的实际对象是两者的组合。

为什么要构建评估系统
评估系统的价值是复合的，它不仅能防止回归，还能建立基准、加速新模型的采用。演进路径如下：
· 早期阶段：依赖手动测试和直觉。
· 崩溃点：当系统规模化后，用户反馈“系统变差了”，团队却无法验证，只能盲目猜测。
· 成熟阶段：如 Claude Code 案例，从针对简洁性、文件编辑等具体行为构建评估，到结合生产监控和 A/B 测试，形成完整的质量保障体系。

针对不同类型 Agents 的评估策略（类型、核心评估方法和关键指标/工具）
· 编程 Agents：确定性评分器（代码能否运行、测试能否通过），SWE-bench Verified, Terminal-Bench
· 对话 Agents：多维度评估（问题解决、转录约束、语气恰当），通常需要另一个 LLM 模拟用户交互
· 研究 Agents：组合评分器（事实性、覆盖率、来源质量），专家人工判断校准 LLM 评分
· 计算机使用 Agents：真实/沙箱环境交互（截图、点击、输入），平衡 Token 效率（DOM）与视觉准确度（截图）

应对非确定性的度量方法
文章引入了两个关键指标来捕捉 Agents 行为的随机性：
· pass@k：衡量在 k 次尝试中至少获得一次正确解的可能性。适用于提出多个方案只要有一个有效即可的场景。
· pass^k：衡量所有 k 次试验都成功的概率。对于面向客户、要求高可靠性的 Agents，这个指标尤为重要。
· 洞察：在 k=1 时两者相同，但随着试验次数增加，它们讲述的是截然相反的故事——这正是选择正确指标的关键所在。

从零到一的实践路线图（8 步走）
· 尽早开始：20-50 个来自真实失败的简单任务就是很好的起点。
· 从手动测试开始：将开发中已经运行的手动检查转化为测试用例。
· 编写明确的任务和参考方案：确保两位领域专家能独立达成相同的通过/失败判断。
· 构建平衡的问题集：测试行为“应该发生”和“不应该发生”的情况，避免单侧优化。
· 构建稳定的评估工具：确保环境不引入额外噪声，每次试验都从干净状态开始。
· 深思熟虑地设计评分器：优先选择确定性评分器，必要时使用 LLM 评分，谨慎使用人工评分。
· 检查转录本：阅读试验记录是验证评分器是否正常工作的唯一方法。
· 监控能力评估饱和度：当评估达到 100% 时，它只能跟踪回归而无法提供改进信号。

评估在整体理解中的定位
自动化评估并非万能，文章采用了“瑞士奶酪模型”作为类比：没有单一的评估层能捕获所有问题，但通过组合多种方法，漏洞会被不同层级拦截。
· 发布前/CI-CD：自动化评估。
· 发布后：生产监控（检测分布漂移）。
· 重大变更：A/B 测试。
· 持续性实践：用户反馈与转录审查。
· 校准：系统性人工研究。

MIT这篇论文最近也很热门，听起来很简单的思路，但感觉很重要。

递归语言模型：让AI突破上下文限制的新思路

为什么最先进的AI模型，面对超长文档时还是会"犯糊涂"？

就像人的记忆一样，AI也有它的"工作记忆"限制。

即便是GPT-5这样的顶级模型，当输入内容超过一定长度，表现就会明显下滑。

研究人员把这个现象叫做"上下文腐烂"（context rot），听起来有点可怕，但确实很形象。

MIT的研究团队最近提出了一个挺有意思的解决方案：递归语言模型（Recursive Language Models，简称RLM）。

这个想法的核心特别简单，简单到让人觉得"怎么之前没人想到"。

把超长文本当成"外部环境"

传统做法是什么？

把整个文档塞进AI的"大脑"里，让它一次性处理。

就像让你一口气读完一本百科全书，然后回答问题。

RLM的思路完全不同。

它把超长文本放在外面，就像放在你的书桌上。

AI可以随时翻看、做笔记、甚至把复杂问题拆解成小块，再调用"另一个自己"来处理这些小块。

具体怎么做？

研究团队用了一个Python环境（REPL），把文档当成一个变量存在里面。

AI可以：
• 写代码查看文档的某一部分
• 用正则表达式搜索关键词
• 把文档切成合理的片段
• 对每个片段调用一个"子AI"来分析
• 把所有结果汇总起来

这就像你做研究时的真实工作流程。

你不会从头到尾死记硬背，而是会做标记、写摘要、分章节理解。

效果怎么样？

研究团队在四个不同类型的任务上测试了RLM，输入长度从几千到上千万个token。

最直观的对比在图1里：
• 普通GPT-5：随着输入变长，准确率快速下降，尤其是复杂任务
• RLM版GPT-5：即便输入长度超出模型上下文窗口两个数量级，依然保持稳定表现

举个具体例子。

有个叫OOLONG-Pairs的任务，需要在数据中找出所有满足特定条件的"配对"。

这种任务的复杂度随输入长度呈平方增长。

结果：
• GPT-5的F1分数：0.04%（基本没做对）
• RLM(GPT-5)的F1分数：58%

在另一个需要处理1000份文档（约800-1100万token）的深度研究任务中：
• 普通方法：0%准确率（根本装不下）
• RLM(GPT-5)：91.33%准确率

更重要的是成本。

你可能会想，这么复杂的操作，成本会不会爆炸？

研究发现，RLM的中位数成本其实和直接调用基础模型差不多，有时甚至更便宜。

虽然极端情况下会贵一些（因为可能需要很多递归调用），但总体来说是可控的。

AI是怎么"思考"的？

研究团队深入分析了RLM的运行轨迹，发现了一些有意思的模式：

1. 聪明的过滤策略
AI不会傻乎乎地从头看到尾。

它会先用关键词搜索，找到可能相关的部分，再仔细分析。

比如在一个关于节日的问题中，它会先搜索"festival"、"La Union"这些词。

2. 递归分解问题
面对超长文档，AI会把它切成合理的块，对每块调用"子AI"处理，最后汇总结果。

就像你写论文时会分章节写，最后再整合。

3. 答案验证
有时AI会通过多次调用来验证答案的正确性。虽然这会增加成本，但提高了可靠性。

4. 处理超长输出
当需要输出很长的结果时，RLM可以把多个子调用的输出存在变量里，最后拼接起来。

这样就突破了单次输出的长度限制。

不同模型的"个性"

有意思的是，不同的基础模型作为RLM时，表现出不同的"风格"：

• GPT-5：比较保守，会精心设计查询策略，尽量减少子调用次数
• Qwen3-Coder：更激进，倾向于对每一行都做单独的子调用

这导致在某些任务上，Qwen3-Coder可能会发起成百上千次子调用，而GPT-5只需要十几次。

研究团队甚至不得不在给Qwen3-Coder的提示词里加了一句："小心使用子调用，成本很高！"

RLM不是完美的。

运行时间：因为涉及多次模型调用，RLM比直接调用慢。不过这可以通过异步调用来优化。

模型能力要求：RLM需要模型有足够的编程能力。小模型可能搞不定。

决策效率：现有模型在管理上下文时还不够高效。

比如前面提到的Qwen3-Coder，有时会做很多不必要的子调用。

训练优化空间：目前的RLM都是用现成模型，没有专门训练。

如果专门训练模型来做RLM，效果应该会更好。

为什么重要？

我们正在进入一个AI需要处理海量信息的时代。想想这些场景：
• 分析整个代码仓库来理解项目架构
• 阅读几十篇论文来做文献综述
• 处理数百份文档来回答复杂问题

传统的"扩大上下文窗口"思路，就像给人脑增加内存条，理论上可行，但成本高昂，而且有物理限制。

RLM提供了另一条路：

不是让AI的"大脑"变大，而是教它更聪明地使用外部资源。

这更接近人类的思维方式，也更可扩展。

更深一层说，RLM展示了一个重要的设计理念：

把推理过程显式化。

AI不再是一个黑盒，而是可以看到它如何分解问题、查找信息、验证答案。

这种透明度对于构建可靠的AI系统很重要。

未来会怎样？

研究团队提到了几个值得期待的方向：

异步优化：让多个子调用并行运行，大幅降低延迟

更深的递归：目前只用了一层递归（子调用是普通LM），如果允许更深的递归会怎样？

专门训练：如果从头训练一个专门用于RLM的模型，把这种递归思维内化到模型里，效果会不会更好？

我觉得最后一点特别有意思。

这有点像人类学习的过程，你刚开始做研究时，需要刻意地提醒自己"要做笔记"、"要分段理解"，但慢慢地，这些就变成了自然而然的习惯。

RLM可能不只是一个工程技巧，而是一种新的模型能力。就像思维链（Chain-of-Thought）从一个提示技巧，逐渐演变成了模型的内在能力。

从第一性原理来思考产品设计准则的变化

产品价值的第一性原理是什么？
是这个公式：
产品价值=（新体验-旧体验）- （学习成本+迁移成本）

当你是一个新的AI产品时，一方面要思考如何提高体验增量，比如找到10倍好的场景

另外一方面要想办法降低学习成本和迁移成本

---学习成本-----
降低学习成本的一个方法是，将用户的学习成本转移成Agent的调用成本

比如原来一个web2.0界面，用户要走完onboarding去了解如何使用
但现在完全可以Agent来执行Skills（里面封装了API）完成任务

就拿xaicreator的发推文来说
我现在把推文API封装了，就完全可以让Agent代替我操作界面，我不需要再次打开网址自己去创建草稿，编辑推文了，这一切Agent都可以做

Agent在干完事儿之后，只需要返回给我一个草稿分享地址，我点开可以二次编辑，甚至让Agent帮我编辑，然后设定预发布时间发布即可

最终你会发现，用户不需要熟悉新的产品
因为Agent会参考API文档来帮助他熟悉
或者说这个产品本身封装的Skills里面，学习成本成为了黑盒，用户只需要让Agent用就好了

在这种情况下，如果你还在使用传统GUI的策略去建设产品，那么学习成本仍然是攀高的

---迁移成本-----
接下来的问题是，用户的数据中心都在哪里？

可能散落在本地电脑里，可能散落在私有云上，可能散落在一些服务商的数据库里

本地电脑里的最简单，授权访问就可以
私有云的也容易，API访问也能获得，比如存储在google drive或者dropbox的

散落在其他服务商数据库里的，就需要一些转移工具
比如网易云的歌单导入，支持导入其他平台的歌单
比如Beehiiv到Substack的迁移工具

---未来设计-----
从这些角度来看待问题的话
未来绝大部分产品应该是优先toA的，Agent要先了解如何使用
然后才是将GUI降级提供给人类

比如我发推文，只有当Agent写的推文不好的时候，或者我想确认一下Threads样式的时候，我才会打开那个web页面

其余时间可能Agent直接就发布了
根本不再需要软件交互了

以前我们要统计人类的使用数据
未来要统计Agent的采样数据

我们从23年就在思考如何为AI构建工具
在26年，这件事将成为习以为常的普遍共识

[论文解读] DeepSeek 和北京大学联合发表论文「Engram: Conditional Memory via Scalable Lookup」，提出名为 Engram 的“条件记忆”模块。它通过引入一个全新的稀疏化维度，解决 Transformer 模型在处理静态知识检索时效率低下的核心问题。

核心科学假设：语言建模的二元性
论文指出，语言建模包含两个本质不同的子任务：
· 组合推理：需要深层的、动态的神经计算。
· 知识检索：针对实体、公式化模式等静态内容。由于标准 Transformer 缺乏原生的查找原语，目前模型被迫通过多层注意力和前馈网络进行昂贵的运行时“重建”来模拟检索。

Engram 架构设计：现代化的 N-gram 条件记忆
Engram 模块通过 O(1) 的查找复杂度将静态模式存储从动态计算中分离出来。核心流程如下：
· 分词器压缩：预先计算映射函数，将语义等价但 ID 不同的词项（如 "Apple" 和 "apple"）折叠为统一标识符，将有效词表大小减少了 23%。
· 多头哈希检索：利用局部上下文（N-grams）作为键，通过哈希函数在巨大的嵌入表中检索静态向量。
· 上下文感知门控：这是 Engram 的关键创新。利用当前层的隐藏状态作为 Query，与检索到的内存进行语义匹配。如果检索内容与上下文矛盾，门控值会趋近于零，从而抑制哈希冲突带来的噪声。
· 混合分枝集成：专门针对多分枝架构（如 mHC）进行了优化，通过参数共享策略（共享 Embedding 表和 Value 投影，保持独立 Key 投影）平衡了表达能力与计算效率。

关键发现：稀疏分配律与 U 型曲线
论文提出了 “稀疏分配问题”：在固定总参数和计算量（Iso-FLOPs）的情况下，如何在 MoE 专家（条件计算） 和 Engram 存储（条件记忆） 之间分配能力？
· U 型缩放定律：实验发现，纯 MoE 模型并非最优。将约 20%-25% 的稀疏参数预算分配给 Engram 时，模型性能达到最佳。
· 无限内存机制：在内存预算放宽时，验证损失随嵌入槽数量呈对数线性趋势，表明 Engram 是一个可预测的、无需增加额外计算量的缩放拉杆。

性能表现：不仅是知识库，更是推理加速器
在 27B 参数规模的对比测试中，Engram 展示了显著优势：
· 通用领域全面超越：相比同参数、同算力的 MoE 基准，Engram-27B 在知识任务（MMLU +3.0）上表现出色，但在通用推理（BBH +5.0）、代码（HumanEval +3.0）和数学（MATH +2.4）领域的提升更为显著。
· 长文本优势：通过将局部依赖模型化为查找任务，Engram 释放了注意力的容量去处理全局上下文。在长文本检索测试（Multi-Query NIAH）中，准确率从 84.2% 提升至 97.0%。

机械论解释：有效深度的增加
研究人员通过 LogitLens 和 CKA（中心内核对齐） 分析了 Engram 的内部工作机制：
· 加速预测收敛：Engram 变体的早期层 KL 散度显著更低，说明模型更早地进入了“准备好预测”的状态。
· 等效深度提升：CKA 热图显示，Engram 模型的浅层在功能上等同于 MoE 基准模型的更深层（例如，Engram 的第 5 层表示与 MoE 基准的第 12 层最接近）。

系统工程优化
Engram 的设计考虑了硬件协同：
· 预测性预取：不同于 MoE 依赖运行时状态进行动态路由，Engram 的索引仅取决于输入 Token。这允许系统从主机内存异步预取数据，掩盖 PCIe 通信延迟。
· 极低开销：实验证明，即便将 100B 参数的表卸载到主机内存，其推理吞吐量损失也小于 3%。

论文在这：
github.com/deepseek-ai/En…

“After careful evaluation, Apple determined that Google's Al technology provides the most capable foundation for Apple Foundation Models and is excited about the innovative new experiences it will unlock for Apple users.”

: )