<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Long Context - 标签 - lilfry's library</title><link>https://lilfry09.github.io/tags/long-context/</link><description>Long Context - 标签 - 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, 28 Jul 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://lilfry09.github.io/tags/long-context/" rel="self" type="application/rss+xml"/><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>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>读 YaRN：长上下文扩展，核心不是硬拉窗口，而是别把 RoPE 拉坏了</title><link>https://lilfry09.github.io/ai/yarn-context-window-extension/</link><pubDate>Tue, 07 Apr 2026 21:12:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/yarn-context-window-extension/</guid><description><![CDATA[<p>如果只把 <code>YaRN</code> 看成“又一个把上下文从 <code>4k</code> 拉到 <code>64k/128k</code> 的技巧”，其实有点可惜。</p>
<p>它真正碰到的，是一个比“扩窗”更本质的几何问题：</p>
<p><strong>模型原本已经习惯了一套位置相位系统。现在你强行把长度拉大，怎样才能让这套系统在更长范围内继续工作，同时尽量不丢掉近距离的位置分辨率？</strong></p>
<p>这个问题一旦说清楚，<code>YaRN</code> 的设计就会显得非常自然。</p>]]></description></item></channel></rss>