<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>AI - 标签 - lilfry's library</title><link>https://lilfry09.github.io/tags/ai/</link><description>AI - 标签 - lilfry's library</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>lilfry@sjtu.edu.cn (lilfry)</managingEditor><webMaster>lilfry@sjtu.edu.cn (lilfry)</webMaster><copyright>All rights reserved.</copyright><lastBuildDate>Tue, 18 Aug 2026 13:38:45 +0800</lastBuildDate><atom:link href="https://lilfry09.github.io/tags/ai/" rel="self" type="application/rss+xml"/><item><title>Looped Transformer 不只是重复计算：从 LoopFormer 到 Elastic-Depth Post-Training</title><link>https://lilfry09.github.io/ai/looped-transformer-elastic-depth-post-training/</link><pubDate>Tue, 18 Aug 2026 13:38:45 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/looped-transformer-elastic-depth-post-training/</guid><description><![CDATA[<p>Looped Transformer 最容易被误解成一句话：把同一组 Transformer block 多跑几遍，用时间换参数。</p>
<p>这句话没有错，但它跳过了真正困难的部分。共享参数只回答了“循环什么”，没有回答另外三个问题：模型如何知道自己处在第几次循环？短预算为什么仍然能给出有用结果？增加循环时，hidden state 为什么不会漂移、坍缩或者干脆变差？</p>
<p>把近期工作放到同一张图里看，我更关心的研究命题不是再从头训练一个固定循环次数的模型，而是：</p>
<blockquote>
<p><strong>Elastic-Depth Post-Training：能否把已有的固定深度或固定循环模型，改造成计算预算可调、迭代过程稳定、并能按样本自动停止的模型？</strong></p></blockquote>
<p>LoopFormer 给出了全局预算和 trajectory consistency；LoopUS 展示了如何改造 pretrained LLM，并用 selective update 与 confidence exit 控制迭代；Relaxed Recursive Transformers 则提供了“共享主参数、保留深度角色”的折中。三条路线尚未被组合验证，但它们拼出了一个比“多循环几次”更完整的研究问题。</p>
<p>本文信息截止到 <strong>2026-08-18</strong>。文中的数值若无特别说明，均为相应论文在其模型、数据和硬件设置下的报告，不能直接外推到其他模型规模或真实部署吞吐。</p>]]></description></item><item><title>蒸馏不只是压缩：从 Self-Distillation 到 Search Distillation 的研究地图</title><link>https://lilfry09.github.io/ai/distillation-beyond-compression-research-map/</link><pubDate>Sun, 09 Aug 2026 21:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/distillation-beyond-compression-research-map/</guid><description><![CDATA[<p>最近我在整理蒸馏方向时，最大的感觉是：这个词被说窄了。</p>
<p>很多人一提 <code>distillation</code>，脑子里先出现的是模型压缩、logit 对齐、teacher/student 这一套老图景。但一旦把它放回后训练和推理系统里看，蒸馏真正传递的常常不是“答案”，而是搜索方式、更新方式、判断方式，甚至是数据该怎么长出来。</p>
<p>如果把它重新定义成“一个学习过程，把可迁移的信息结构交给另一个学习过程”，那它就不再只是压缩术，而是一张更大的信息迁移图。</p>]]></description></item><item><title>读 SFT、RL 与 On-Policy Distillation：后训练真正的变量是 on-policy data</title><link>https://lilfry09.github.io/ai/sft-rl-opd-on-policy-data/</link><pubDate>Sun, 09 Aug 2026 21:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/sft-rl-opd-on-policy-data/</guid><description><![CDATA[<p>这篇原文最值得带走的一句话，我会改写成：</p>
<p><strong>后训练不是在同一条损失曲线上做微调，而是在改模型会访问到的分布形状。</strong></p>
<p>SFT 把模型往外部示范拉，RL 让模型在自己会走到的状态上追逐奖励，OPD 则让 student 在自己的 prefixes 上对齐 teacher。只要盯住“数据来自哪里”，很多看起来玄学的现象就会变得很朴素：为什么 RL 和 OPD 常常比 SFT 更不容易忘，为什么 student 甚至能超过 teacher。</p>
<p>原文在这里：<a href="https://nrehiew.github.io/blog/sft_rl_opd/" target="_blank" rel="noopener noreffer ">SFT, RL, and On-Policy Distillation Through a Distributional Lens</a>。</p>
<p></p>]]></description></item><item><title>FullStack-Agent：全栈 Coding Agent 的训练与评测数据是如何构造的</title><link>https://lilfry09.github.io/ai/fullstack-agent-data-construction/</link><pubDate>Thu, 06 Aug 2026 20:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/fullstack-agent-data-construction/</guid><description><![CDATA[<p>很多“网页生成 Agent”看起来已经能做出漂亮页面：按钮能点，表单能提交，页面还能弹出“保存成功”。但如果继续追问两步，问题就会暴露出来：数据真的写进数据库了吗？刷新页面之后还能读回来吗？后端 API 是否真的存在？</p>
<p><code>FullStack-Agent</code> 这篇论文的核心贡献，正是把网站生成从“看起来像全栈”推进到“前端、后端和数据库都能被验证”。不过，论文里更值得仔细看的其实不只是 Agent 框架，而是它的数据构造方法：<strong>它如何把真实网站代码库转换成 Coding Agent 的训练轨迹，又如何构造能够识别假后端的评测数据？</strong></p>
<p>本文只讨论这两个问题。论文原文是 <a href="https://arxiv.org/abs/2602.03798" target="_blank" rel="noopener noreffer ">FullStack-Agent: Enhancing Agentic Full-Stack Web Coding via Development-Oriented Testing and Repository Back-Translation</a>，代码仓库见 <a href="https://github.com/mnluzimu/FullStack-Agent" target="_blank" rel="noopener noreffer ">GitHub</a>。</p>]]></description></item><item><title>AgentENV：为 Agentic RL 规模化运行可分叉的沙箱环境</title><link>https://lilfry09.github.io/ai/agentenv-agentic-rl-environment-infrastructure/</link><pubDate>Wed, 05 Aug 2026 23:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/agentenv-agentic-rl-environment-infrastructure/</guid><description><![CDATA[<h3 id="agentic-rl-的瓶颈不只在模型和-gpu还在环境当成千上万个-agent-同时运行代码调用工具修改文件并探索不同路径时系统需要的不是更多普通容器而是可快速启动强隔离可暂停可恢复可分叉的大规模沙箱agentenv-要解决的正是这个问题"><strong>Agentic RL 的瓶颈不只在模型和 GPU，还在环境：当成千上万个 Agent 同时运行代码、调用工具、修改文件并探索不同路径时，系统需要的不是更多普通容器，而是可快速启动、强隔离、可暂停、可恢复、可分叉的大规模沙箱。AgentENV 要解决的正是这个问题。</strong></h3>
<p>在传统 LLM 训练中，一条样本往往只是一段静态文本。但在 Agentic RL 中，样本变成了一段持续交互的轨迹：Agent 要进入操作系统，读写文件，执行 shell 命令，安装依赖，运行测试，根据反馈继续决策。训练系统因此不仅要“喂数据”，还要为每条轨迹准备一个安全、可重现的运行世界。</p>
<p><a href="https://github.com/kvcache-ai/AgentENV" target="_blank" rel="noopener noreffer ">AgentENV（AENV）</a> 是一个面向这类工作负载的分布式平台，官方定位是“Running agent environments at scale”，并已用于 Kimi K3 的 Agentic RL 训练。它的核心价值可以压缩成一句话：<strong>把单个隔离环境的创建与恢复，扩展成跨机器、可持久化、可弹性调度的环境基础设施。</strong></p>]]></description></item><item><title>线性注意力从头到尾讲清楚：从注意力矩阵到可递推状态</title><link>https://lilfry09.github.io/ai/linear-attention-from-scratch/</link><pubDate>Tue, 28 Jul 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/linear-attention-from-scratch/</guid><description><![CDATA[<blockquote>
<p><strong>Linear Attention 的目标是避免显式构造 $n\times n$ 的注意力矩阵，而是把“每个 query 与所有 key 的交互”改写成“query 读取一个累积状态”。</strong></p></blockquote>
<p>这句话比“Linear Attention 把复杂度从平方降到线性”更接近本质。复杂度下降只是结果，真正发生的结构变化是：标准 Attention 显式维护 token 与 token 之间的关系，而 Linear Attention 先把所有 key–value 信息写进一个状态，再让 query 从状态中读出结果。</p>
<p>这篇文章从标准 Attention 出发，把这次改写完整推一遍。读完后，你应该能回答四个问题：为什么不能直接先算 $K^\top V$；归一化需要保存什么额外状态；因果 Linear Attention 为什么像 RNN；以及它用固定状态换走 $n\times n$ 矩阵时究竟牺牲了什么。</p>]]></description></item><item><title>训练模型的长程软件工程能力：从 SWE-Marathon 到 FrontierSWE 与 SWE-Together</title><link>https://lilfry09.github.io/ai/long-horizon-swe-agent-training/</link><pubDate>Mon, 20 Jul 2026 21:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/long-horizon-swe-agent-training/</guid><description><![CDATA[<p>如果要训练模型做长程软件工程任务，最容易走错的一步，是把“长程能力”理解成“更长上下文 + 更多 token”。SWE-Marathon、FrontierSWE 和 SWE-Together 这三组工作放在一起看，会给出一个更锋利的答案：长程能力不是文本长度，而是 <strong>在一个可执行环境里，持续维护目标、状态、证据、风险和验证闭环</strong>。</p>
<p>SWE-bench 把真实 GitHub issue 变成了可评分 patch，这是很重要的一步。但它主要回答“模型能不能修一个相对局部的问题”。现在这三组新 benchmark 关心的是另一件事：模型能不能像一个还算可靠的工程师那样，连续几个小时推进一个项目，把中途实验、失败、回滚、测试、用户纠偏、最终提交都组织起来。</p>]]></description></item><item><title>SWE Agent 数据与评测版图</title><link>https://lilfry09.github.io/ai/swe-agent-benchmark-data-report/</link><pubDate>Tue, 14 Jul 2026 20:20:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/swe-agent-benchmark-data-report/</guid><description>这份 HTML 汇报梳理了 SWE agent 的评测版图、现成轨迹数据、可运行/可构建 SWE 环境资产，以及 rollout factory 和数据合成改进方向。</description></item><item><title>Coding Agent 最新论文与工程调研</title><link>https://lilfry09.github.io/ai/coding-agent-latest-research-survey/</link><pubDate>Tue, 14 Jul 2026 03:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/coding-agent-latest-research-survey/</guid><description><![CDATA[<p>这轮调研的核心问题是：<strong>为什么 GPT/Codex、Claude Code 这类 coding agent 突然变得这么能干？</strong></p>
<p>我的结论先放前面：它们不是单靠“模型会写代码”变强的，而是被一整套新的训练与工程范式推上去的：</p>
<ol>
<li><strong>数据从代码片段变成真实软件工程任务</strong>：GitHub issue、PR、测试、依赖、Docker 环境、终端日志、代码审查意见、失败轨迹都成了训练资产。</li>
<li><strong>训练从 next-token code completion 走向可验证交互</strong>：SFT 学轨迹，RL 学“跑测试、看失败、改补丁、再验证”的闭环，critic/verifier 学会挑更可能通过的 patch。</li>
<li><strong>terminal 成了核心训练环境</strong>：真实 agent 不是只输出 diff，而是在 shell 里安装依赖、读日志、运行测试、grep/rg、编辑文件、回滚、调试。</li>
<li><strong>长上下文不只是 1M token，而是 context engineering</strong>：强 agent 会把仓库当文件系统操作，用搜索、摘要、记忆、压缩、多窗口初始化来管理上下文。</li>
<li><strong>harness/runtime 的设计极其关键</strong>：同一个底座模型，换工具接口、权限模型、sandbox、上下文拼装、测试反馈方式，SWE-bench 分数和真实可用性都能差很多。</li>
</ol>
<p>还有一个必须诚实说清楚的点：<strong>OpenAI 和 Anthropic 没有公开完整训练配方</strong>。但它们的官方 blog/system card 已经泄露了足够多的方向信号。OpenAI 明确说 GPT-5-Codex 类模型是针对 agentic coding 优化，并使用真实 coding tasks 的强化学习，让模型学会贴近 human PR preference、遵循指令、迭代跑测试直到通过。Anthropic 则把 Claude Code 的进步拆成 context engineering、工具设计、sandbox、auto mode、long-running harness、多 agent 并行和 eval-aware 开发。把这些和开源论文拼起来，大致能还原“前沿 coding agent 为什么强”的工程轮廓。</p>]]></description></item><item><title>异步 RL：用 Policy Staleness 换掉全局 Barrier</title><link>https://lilfry09.github.io/ai/async-rl-policy-staleness-global-barrier/</link><pubDate>Mon, 13 Jul 2026 23:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/async-rl-policy-staleness-global-barrier/</guid><description><![CDATA[<h3 id="异步-rl-的核心就是rollout-worker-持续生成样本trainer-收到足够样本就立即更新不再等待同一轮所有请求全部完成它用一定程度的-policy-staleness-换掉同步-barrier因此-gpu-更忙吞吐更高但训练数据也不再严格来自当前-policy"><strong>异步 RL 的核心就是：rollout worker 持续生成样本，trainer 收到足够样本就立即更新，不再等待同一轮所有请求全部完成。它用一定程度的 policy staleness 换掉同步 barrier，因此 GPU 更忙、吞吐更高，但训练数据也不再严格来自当前 policy。</strong></h3>
<p>如果只看系统吞吐，异步 RL 很诱人。长 CoT 请求不再把整轮训练卡住，短请求生成完就可以进入训练队列，trainer 不必陪最后几个超长样本一起发呆。</p>
<p>但这笔交易并不免费。同步 RL 里的等待点很烦，却也维护了一个重要假设：本轮训练数据大体来自同一个 policy snapshot。异步 RL 把这个假设拆掉之后，系统变成一条更高吞吐的流水线，同时也把 off-policy correction、数据分布偏差和样本版本管理都请上了牌桌。</p>]]></description></item></channel></rss>