📅 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、总耗时和工具权限都有硬上限；同一动作连续失败时应停止或切换策略。模型输出“完成”也要经过程序检查，例如所需字段是否齐全、写操作是否返回成功、引用是否存在。

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

今天谈知识库，常把向量数据库、Embedding 和大模型放在一起。知识库的历史远早于大模型，并且有两条长期并行的技术路线。一条来自专家系统，把事实、规则和推理程序分开；另一条来自信息检索，研究如何从大量文本中找出与查询相关的内容。RAG 延续了第二条路线，同时吸收了第一条路线对“外部知识”的处理方式。

厘清这段历史很重要。向量检索没有废除关键词检索，长上下文也没有消除索引。当前知识库产品中的切片、倒排索引、向量召回、重排和引用，分别来自不同阶段积累的方法。

两条知识库路线在生成模型前已经形成

早期专家系统把领域知识保存为事实和规则，再由推理引擎执行匹配与演绎。修改知识时可以调整规则库，无需重写推理器。它适合边界清楚、规则稳定的任务，却难以直接容纳大量自然语言文档。规则数量增长后，冲突处理和维护成本也会迅速上升。

信息检索处理的是另一类问题：文档已经存在，系统需要计算查询与文档的相关程度。图书目录依靠人工主题词，数字化文档推动了自动索引。倒排索引、词项权重和相关性排序由此成为搜索系统的基础。企业文档问答沿用的正是这套链路，只在候选文档后增加了生成模型。

倒排索引解决候选集规模

顺序扫描每篇文档的代价随文档总量增长。倒排索引反过来记录“词出现在哪些文档中”。查询包含“迁移 校验”时，检索器先取得两个词对应的文档列表，再求交集、并集或带权组合。文档频率、词频和位置信息都可以保存在 posting list 中。

倒排索引擅长精确标识符、人名、错误码和专有术语。它也有明显限制：用户搜索“服务无法启动”，文档只写“进程初始化失败”，词面重合可能很少。分词、同义词和查询扩展可以缓解问题，仍无法完整表达句子语义。

TF-IDF 给词项分配区分度

词频 TF 描述词项 $t$ 在文档 $d$ 中出现的程度，逆文档频率 IDF 降低常见词的权重。一种常见写法是：

$$ \operatorname{tfidf}(t,d)=\operatorname{tf}(t,d)\cdot \log\frac{N}{\operatorname{df}(t)+1} $$

$N$ 是文档总数，$\operatorname{df}(t)$ 是包含词项 $t$ 的文档数。工程实现会采用对数词频、平滑项和向量归一化等变体，因此不同搜索库给出的分数不能脱离实现直接比较。

将文档与查询表示成词项权重向量后，可以计算余弦相似度：

$$ \cos(q,d)=\frac{q\cdot d}{\lVert q\rVert\lVert d\rVert} $$

TF-IDF 建立了可计算的相关性模型，但长文档容易因为词出现次数更多而占优。词频的收益也并非线性增长，一个词出现二十次通常不会比出现十次多一倍信息。