<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>上下文 - tag - 沐木</title><link>https://oldletter.cn/tags/%E4%B8%8A%E4%B8%8B%E6%96%87/</link><description>上下文 - tag - 沐木</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Sat, 11 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oldletter.cn/tags/%E4%B8%8A%E4%B8%8B%E6%96%87/" rel="self" type="application/rss+xml"/><item><title>知识库工程（二）：LLM 的记忆从哪里来</title><link>https://oldletter.cn/posts/rag-engineering-02-ingestion-pipeline/</link><pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate><author>mumu</author><guid>https://oldletter.cn/posts/rag-engineering-02-ingestion-pipeline/</guid><description><![CDATA[<blockquote>
<p>系列导航：<a href="/posts/rag-engineering-01-adapter-boundary/" rel="">1</a> | <a href="/posts/rag-engineering-02-ingestion-pipeline/" rel="">2</a> | <a href="/posts/rag-engineering-03-retrieval-quality/" rel="">3</a> | <a href="/posts/rag-engineering-04-contract-sse/" rel="">4</a></p></blockquote>
<p>“模型记住了”可能指六件不同的事：训练数据进入参数，当前消息仍在上下文中，推理服务保留了 KV Cache，应用保存了聊天记录，检索器找回一条旧资料，或者 Agent 把经历写进长期存储。这些机制的寿命、容量、成本和风险完全不同。</p>
<p>把它们统称为记忆，会产生常见误判。清空聊天窗口不一定删除服务端保存的摘要，KV Cache 命中也不表示模型拥有长期记忆，向量库召回一段旧对话更不代表这段内容仍然有效。知识库工程先要确定信息存在哪一层，再决定如何写入和遗忘。</p>
<h2 id="参数记忆保存训练中压缩出的规律">参数记忆保存训练中压缩出的规律</h2>
<p>预训练通过梯度下降调整模型参数，使下一个 token 的概率分布更接近训练文本。事实、语言规律和推理模式被分散编码在大量权重中，无法按数据库记录逐条定位。模型能够回答某个事实，不等于内部存在一行可直接读取的键值记录。</p>
<p>参数记忆容量大，推理时无需外部查询，更新却很重。继续预训练、监督微调或参数高效微调都可能引入新知识，也可能损伤已有能力。训练语料中的时间边界、冲突信息和错误内容会一起影响参数。需要频繁更新、删除或审计的企业资料不适合只靠参数保存。</p>
<h2 id="上下文窗口是一次推理的工作区">上下文窗口是一次推理的工作区</h2>
<p>Transformer 使用注意力让当前位置读取上下文中的其他 token。缩放点积注意力写作：</p>
<p>$$
\operatorname{Attention}(Q,K,V)=\operatorname{softmax}\left(\frac{QK^\mathsf{T}}{\sqrt{d_k}}\right)V
$$</p>
<p>系统提示词、用户问题、历史消息、检索片段和工具结果都要占用上下文。它们在一次请求中可见，超出窗口后必须截断、摘要或移到外部存储。上下文属于显式输入，修改后无需训练；其缺点是每次读取都会消耗 token 和计算资源。</p>
<p>窗口长度也不能直接换算成有效记忆容量。重复资料会稀释注意力，冲突版本会让模型难以选择，关键证据所在位置会影响结果。<code>Lost in the Middle</code> 说明长上下文模型对中部信息的利用并不稳定。上下文管理需要排序、去重和预算，不能只执行拼接。</p>
<h2 id="kv-cache-是计算缓存">KV Cache 是计算缓存</h2>
<p>自回归生成每个新 token 时，历史 token 的 Key 和 Value 可以复用。推理服务把它们保存在 KV Cache 中，避免每一步重新计算完整前缀。以普通多头注意力作近似，单个请求的缓存规模与层数 $L$、序列长度 $T$、隐藏维度 $H$ 和数据字节数 $B$ 成正比：</p>
<p>$$
M_{KV}\approx 2LTHB
$$</p>
<p>系数 2 对应 Key 与 Value。分组查询注意力、量化和分页缓存会改变实际占用。KV Cache 保存的是模型计算产生的张量，通常随请求结束、实例回收或缓存淘汰而消失。它不负责判断某条信息是否值得长期保存，也不提供按事实更新、权限过滤和来源追踪。</p>
<p>提示词前缀缓存也属于成本优化。多个请求共享相同前缀时，服务端可以复用计算结果；前缀内容仍要通过应用规则进入请求。把缓存命中率称为“记忆能力”会混淆性能与知识管理。</p>
<h2 id="会话历史和摘要由应用保存">会话历史和摘要由应用保存</h2>
<p>多轮对话常把近期若干条消息原样放入上下文，较早内容压缩成摘要。原始记录有较好的可追溯性，但 token 占用持续增长。摘要控制了长度，也会丢失限定条件、否定词和时间信息。若摘要由模型生成，错误概括还会在后续轮次反复被引用。</p>]]></description></item></channel></rss>