📅 2026-05-28 | 🏷️ LLM, LoRA, RAG, Agent | 📖 阅读约 25 分钟

写作背景

这篇文章站在 Java 后端的视角写。我的切入点并非训练框架本身，重点是把模型能力接进已有系统：接口怎么设计，流式响应怎么落地，知识库怎么更新，工具调用怎么审计。Python 示例能解释原理，真正上线时还要回到鉴权、限流、日志、回滚和成本控制。 后端同学学习 LLM 时，可以先抓住工程边界：模型负责生成，应用负责上下文、权限、状态和证据。只要这个边界稳住，后续换模型、换向量库、换 Agent 框架都不会牵动整套业务。 Java 生态资料少，不代表 Java 不适合做 AI 应用。训练和实验可以交给 Python，在线服务、管理后台、任务调度、数据治理仍然是 Java 很熟悉的战场。 这篇文章按落地顺序展开：先会调用模型，再做 RAG，再理解微调和 Agent，末尾补评估、部署和安全。 数学细节可以以后补，工程上先把数据链路、接口契约和验证方法跑通。

一、全景图：LLM 落地的四层架构

Java 后端开发者的优势在应用层和编排层，你已经会 Spring Boot、会设计 API、会做系统集成。 需要补的是能力层（怎么用 RAG/微调提升效果）和基座层（怎么选模型、怎么部署）。

系列导航：1 | 2 | 3 | 4

“模型记住了”可能指六件不同的事：训练数据进入参数，当前消息仍在上下文中，推理服务保留了 KV Cache，应用保存了聊天记录，检索器找回一条旧资料，或者 Agent 把经历写进长期存储。这些机制的寿命、容量、成本和风险完全不同。

把它们统称为记忆，会产生常见误判。清空聊天窗口不一定删除服务端保存的摘要，KV Cache 命中也不表示模型拥有长期记忆，向量库召回一段旧对话更不代表这段内容仍然有效。知识库工程先要确定信息存在哪一层，再决定如何写入和遗忘。

参数记忆保存训练中压缩出的规律

预训练通过梯度下降调整模型参数，使下一个 token 的概率分布更接近训练文本。事实、语言规律和推理模式被分散编码在大量权重中，无法按数据库记录逐条定位。模型能够回答某个事实，不等于内部存在一行可直接读取的键值记录。

参数记忆容量大，推理时无需外部查询，更新却很重。继续预训练、监督微调或参数高效微调都可能引入新知识，也可能损伤已有能力。训练语料中的时间边界、冲突信息和错误内容会一起影响参数。需要频繁更新、删除或审计的企业资料不适合只靠参数保存。

上下文窗口是一次推理的工作区

Transformer 使用注意力让当前位置读取上下文中的其他 token。缩放点积注意力写作：

$$ \operatorname{Attention}(Q,K,V)=\operatorname{softmax}\left(\frac{QK^\mathsf{T}}{\sqrt{d_k}}\right)V $$

系统提示词、用户问题、历史消息、检索片段和工具结果都要占用上下文。它们在一次请求中可见，超出窗口后必须截断、摘要或移到外部存储。上下文属于显式输入，修改后无需训练；其缺点是每次读取都会消耗 token 和计算资源。

窗口长度也不能直接换算成有效记忆容量。重复资料会稀释注意力，冲突版本会让模型难以选择，关键证据所在位置会影响结果。Lost in the Middle 说明长上下文模型对中部信息的利用并不稳定。上下文管理需要排序、去重和预算，不能只执行拼接。

KV Cache 是计算缓存

自回归生成每个新 token 时，历史 token 的 Key 和 Value 可以复用。推理服务把它们保存在 KV Cache 中，避免每一步重新计算完整前缀。以普通多头注意力作近似，单个请求的缓存规模与层数 $L$、序列长度 $T$、隐藏维度 $H$ 和数据字节数 $B$ 成正比：

$$ M_{KV}\approx 2LTHB $$

系数 2 对应 Key 与 Value。分组查询注意力、量化和分页缓存会改变实际占用。KV Cache 保存的是模型计算产生的张量，通常随请求结束、实例回收或缓存淘汰而消失。它不负责判断某条信息是否值得长期保存，也不提供按事实更新、权限过滤和来源追踪。

提示词前缀缓存也属于成本优化。多个请求共享相同前缀时，服务端可以复用计算结果；前缀内容仍要通过应用规则进入请求。把缓存命中率称为“记忆能力”会混淆性能与知识管理。

会话历史和摘要由应用保存

多轮对话常把近期若干条消息原样放入上下文，较早内容压缩成摘要。原始记录有较好的可追溯性，但 token 占用持续增长。摘要控制了长度，也会丢失限定条件、否定词和时间信息。若摘要由模型生成，错误概括还会在后续轮次反复被引用。