📅 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

提示词、RAG 和 Agent 经常被写成三个可替换的方案。它们处在不同层次：提示词组织一次模型调用中的信息与约束，RAG 从外部知识中选择证据，Agent 根据任务状态决定下一步动作。一个完整应用可以同时使用三者，也可以只使用其中一部分。

分清职责后，很多故障会更容易定位。模型漏掉文档中的事实，应先检查检索与上下文；模型格式不稳定，再检查提示词和结构化输出；模型需要多次查询、计算或调用业务工具，才进入 Agent 编排。只改提示词无法补回没有进入上下文的证据。

Prompt 是一次调用的上下文编排

实际送给模型的输入通常由系统规则、用户任务、少量示例、检索证据、对话状态和工具定义组成。它们共享同一个 token 预算：

$$ T_{sys}+T_{user}+T_{demo}+T_{rag}+T_{history}+T_{tool}+T_{output}\leq T_{window} $$

上下文窗口扩大后，预算约束依旧存在，因为输入长度还会影响延迟、费用与注意力分配。系统规则应该短而稳定，业务数据保持结构清晰，检索片段携带来源与版本。少量示例适合约束输出模式，不能用来长期保存不断变化的知识。

Prompt 中常见的几个区块有不同优先级。系统规则定义身份、权限和禁止事项；用户消息描述当前目标；证据区提供可引用事实；工具定义列出允许执行的动作。检索文档属于不可信数据，其中若出现“忽略系统要求”，应用不能把它提升为指令。

RAG 在生成前选择证据

一次基础 RAG 包含查询改写、候选召回、过滤、重排、上下文组装和生成。查询改写解决代词、省略和多轮上下文问题，召回负责扩大候选范围，重排比较问题与段落的匹配程度，组装阶段处理去重、版本与 token 预算。

检索结果必须连同来源进入 Prompt。只有正文，没有文档标识、页码或更新时间，模型生成后就难以给出可核对引用。旧版制度和新版制度同时被召回时，生成模型也不适合自行猜测哪一版有效，检索前应先按状态和时间过滤。

RAG 适合知识密集且资料可索引的任务，例如制度问答、项目文档检索、代码说明和客服知识。需要精确计算、实时余额或写入业务状态时，应调用确定性工具。模型可以解释工具结果，数据真值仍由业务系统提供。

Agent 把单次问答扩展成有状态循环

ReAct 将推理与动作交替组织。模型根据当前观察选择动作，环境执行工具并返回结果，模型再判断是否继续。工程实现无需暴露完整内部推理文本，可以保留结构化计划摘要、工具调用、观察结果和停止原因。

循环必须由运行时控制。调用次数、总 token、总耗时和工具权限都有硬上限；同一动作连续失败时应停止或切换策略。模型输出“完成”也要经过程序检查，例如所需字段是否齐全、写操作是否返回成功、引用是否存在。