)
作者逆境不可逃技术永无止境希望我的内容可以帮助到你摘要对于后端工程师来说学习大语言模型并不是为了从零训练一个模型而是为了回答一个更实际的问题当 LLM 被接入真实业务系统后它会怎样工作又可能在哪里失败本文从一次回答的生成过程开始系统讲解 Token、上下文窗口、调用成本、Embedding、向量检索、Transformer、Self-Attention、Q/K/V、多头注意力、因果遮罩和 KV Cache并把这些概念映射到 Agent 的接口设计、权限控制、RAG 和成本治理中。关键词LLM、Token、上下文窗口、Embedding、向量数据库、RAG、Transformer、Self-Attention、QKV、KV Cache、Agent一、先建立正确认知LLM 不是事实数据库传统后端函数通常追求相同输入 相同代码 相同数据状态 相同输出LLM 更接近当前上下文 模型参数 概率分布 采样策略 一个可能的输出它最基础的训练目标不是 “查询事实”而是根据前面的内容预测下一个最可能出现的 Token。这句话看起来简单却能解释 Agent 工程中的很多现象同一个问题多次调用回答可能不同。回答语言非常流畅事实却可能是错的。上下文过长时模型可能遗漏规则或混淆版本。工具明明返回了正确数据模型仍可能解释错误。Prompt 写了 “禁止删除”也不能代替后端权限控制。因此LLM 应被视为一个带概率输出的外部服务。我们要给它增加输入约束、结构校验、事实来源、权限控制、错误处理和可观测性。二、第一讲LLM 如何生成一次回答2.1 完整生成链路假设用户输入Java 中 HashMap 为什么线程不安全模型内部大致经过接收消息 → 切分 Token → Token 转换为编号 → 编号映射为向量 → Transformer 结合上下文处理 → 计算下一个 Token 的概率 → 按生成策略选择 Token → 将新 Token 加入上下文 → 重复预测直到结束模型并不是先在内部写好整篇回答再一次性返回。它是一个 Token 一个 Token 地生成。2.2 模型接收的是消息列表一次聊天请求通常不只是一个字符串而是一组带角色的消息[ { role: system, content: 你是一位耐心的 Java 老师 }, { role: user, content: Java 中 HashMap 为什么线程不安全 } ]可以先这样类比消息角色作用后端类比system系统规则与任务边界全局配置、业务约束user当前用户请求请求参数assistant历史模型回复历史响应tool外部工具执行结果下游服务响应模型会综合当前可见的全部消息生成答案而不只是读取最后一句。2.3 Token、编号和向量模型不能直接处理人类看到的完整句子。文本会先被分词器切成 Token再映射为词表编号。示意Java → 18432 线程 → 29751 安全 → 9136随后每个编号会被映射成一组高维数字Java → [0.12, -0.48, 0.91, ...]这些向量是模型内部进行矩阵计算的表示。单个维度通常不能直接解释成 “编程”“订单” 或 “退款”语义由大量维度共同承载。2.4 下一个 Token 是概率分布假设模型已经生成HashMap 在线程并发修改时它可能为下一个 Token 计算出如下概率可能 35% 会 30% 容易 18% 通常 10% 其他 7%模型选择一个 Token 后再重新计算下一步。Temperature、Top-p 等采样参数会影响选择过程所以相同输入不一定得到完全相同的回答。2.5 幻觉为什么出现如果用户问请解释某本书并不存在的第 38 章。模型可能根据常见写作结构补出一段非常像真的内容。原因是模型目标生成上下文中概率合理的内容 业务目标获得事实正确、可验证的内容这两个目标并不天然相等。工程上不能只说 “请不要编造”而应结合数据库或业务 API 查询真实状态RAG 提供可引用证据Schema 限制输出结构程序校验关键字段信息不足时拒答或澄清高风险动作加入人工确认。三、第二讲Token、上下文窗口与成本3.1 Token 不等于汉字或单词Token 是模型读取和生成文本的基本单位但不存在固定换算关系一个汉字可能对应一个或多个 Token常见英文单词可能是一个 Token较长单词可能被拆成多个 Token标点、空格、换行和代码符号也可能占 Token不同模型的分词器可能给出不同结果。因此准确数量应使用目标模型对应的分词器计算不能简单采用 “一个汉字等于一个 Token”。3.2 输入和输出都占上下文一次调用通常满足输入 Token 输出 Token ≤ 上下文窗口Agent 的输入远不止用户问题系统规则 用户输入 历史对话 工具定义与参数 Schema RAG 检索片段 工具执行结果 输出格式要求 模型准备生成的内容 ≤ 上下文窗口用户可能只输入十几个字但系统提示词、历史消息、工具说明和数据库结果加起来已经有几千 Token。3.3 上下文窗口不是长期记忆第一轮用户我叫小王负责支付系统。第二轮模型能回答 “小王负责支付系统”通常是因为应用重新发送了历史消息ListMessage messages loadConversationHistory(sessionId); messages.add(currentUserMessage); ModelResponse response modelClient.call(messages);模型不是自动把事实永久保存在 “脑中”。真正的长期记忆需要应用自己实现用户偏好保存在数据库当前任务状态保存在状态机或任务表对话历史按需裁剪或摘要外部知识通过 RAG 检索需要时重新召回并放入本轮上下文。3.4 上下文越长不代表效果越好长上下文会带来四类风险超出窗口请求报错、旧消息被截断或输出空间不足。信息干扰无关资料越多模型越难聚焦当前任务。规则冲突旧版和新版规则同时出现模型可能混用。重要信息被淹没关键限制藏在大量历史或文档中利用效果可能下降。“模型能装下” 与 “模型能稳定使用” 是两回事。3.5 上下文管理策略保留必要信息优先保留最高级系统规则当前用户目标权限和任务状态当前步骤需要的工具与问题真正相关的证据输出契约。压缩历史把早期十几轮对话压缩为结构化状态{ user: 小王, system: 支付系统, goal: 查询未支付订单, completedSteps: [确认用户身份], pending: [确认查询日期] }关键事实不应只依赖不断重写的自然语言摘要否则错误可能随摘要迭代被长期保留。裁剪工具结果如果模型只需要订单编号、金额、状态和创建时间就不要传入完整用户对象、内部日志和全部商品明细{ orderId: 1001, amount: 299.00, status: UNPAID, createdAt: 2026-07-09T10:30:0008:00 }数据库负责过滤、聚合、排序和分页模型负责解释和表达。3.6 输出空间也要预留假设上下文上限为 16,000 Token输入已经使用 15,000 Token那么理论上只剩约 1,000 Token 用于输出。回答突然中断时应检查是否达到最大输出 Token是否达到上下文总长度是否命中停止条件接口是否超时或断开返回的结束原因是什么。3.7 成本如何计算总费用 输入 Token × 输入单价 输出 Token × 输出单价但 Agent 通常不是只调用一次模型理解意图 → 选择工具 → 读取工具结果 → 判断是否继续调用 → 生成最终答案因此更合理的指标是每个任务的模型调用次数每个任务的总 Token重试和工具链路成本每个成功任务的平均费用P50/P95 端到端延迟哪一步产生了最多无用上下文。部分服务支持 Prompt 缓存。工程上可以把稳定系统规则和工具定义放在较稳定的位置把动态内容放后面以提高缓存复用机会具体命中规则仍应以所用平台为准。四、第三讲Embedding、向量与语义相似度4.1 Embedding 是什么Embedding 模型把文本转换成固定长度的数字向量文本 → Embedding 模型 → [0.18, -0.52, 0.77, ...]语义相近的文本其向量通常也更接近。例如A我的订单什么时候发货 B商品多久可以寄出关键词不同但语义相似向量检索仍可能把它们匹配起来。4.2 聊天模型与 Embedding 模型模型输入输出主要用途聊天模型文本或多模态内容生成文本、结构化结果或工具请求理解、推理、总结、生成Embedding 模型文本等内容数字向量检索、聚类、推荐、去重还要区分两个概念Token Embedding模型内部表示某个 Token文本 Embedding应用层表示一句话、一个片段或文档的整体语义。RAG 中谈到的 Embedding 通常是后者。4.3 余弦相似度常见相似度方法包括余弦相似度、点积和欧氏距离。余弦相似度主要比较两个向量的方向cos(A, B) (A · B) / (|A| × |B|)结果越大通常表示语义越接近。但不能机械规定 “大于 0.8 一定相关”。分数分布取决于模型、归一化方式、文档领域和数据库实现阈值必须通过业务评估集确定。4.4 语义检索与关键词检索语义检索适合同义表达自然语言问题概念和主题匹配用户表达与文档措辞不一致。关键词或精确查询更适合订单编号用户 ID错误码型号、金额和日期法条编号或精确名称。成熟 RAG 经常采用关键词召回 向量召回 元数据过滤 Reranker 重排4.5 向量数据库保存什么不能只保存向量还应保存{ id: doc-001, content: 退款申请需要在订单完成后的七天内提交。, embedding: [0.21, -0.43, 0.67], metadata: { source: 售后规则, version: 2026-01, updatedAt: 2026-01-10, tenantId: tenant-a, permission: public } }典型流程是先按照租户、权限、版本和有效状态过滤再按向量相似度排序。4.6 长文档为什么要切 Chunk把一本 100 页手册生成一个向量只能得到整份文档的综合语义。用户询问一个具体报销金额时这个大向量不一定足够精确。长文档 → 按标题、段落、语义或代码结构切分 → 每个 Chunk 单独生成向量 → 查询时召回少量相关 ChunkChunk 太大会混入噪音太小会把条件与结论拆开。例如普通员工出差到一线城市时 住宿费每天最高可以报销 600 元。如果把两行拆开“普通员工” 和 “一线城市” 两个约束就可能丢失。4.7 Embedding 的局限相似不等于正确退款期限是多少 换货期限为七天。主题接近但第二句话没有回答退款问题。相似不等于逻辑一致会员可以申请退款。 会员不可以申请退款。两句话只有否定词不同向量仍可能很接近业务含义却相反。数字与编号不能只靠向量退款期限为 7 天。 退款期限为 15 天。Embedding 能识别两者都在谈退款期限却不适合代替程序对精确数字和版本的判断。权限不会自动解决检索到文档不代表用户有权读取。权限过滤必须发生在资料进入模型上下文之前而不是把机密内容交给模型后再要求它 “不要泄露”。模型版本不能随意混用文档入库使用模型 A查询使用模型 B两者可能处于完全不同的向量空间。更换 Embedding 模型时通常需要重新生成文档向量并记录模型名称、版本和维度。4.8 RAG 的基础骨架String question 我的商品什么时候能寄出; float[] queryVector embeddingModel.embed(question); ListDocument documents vectorStore.search(queryVector, 5); ListDocument allowed permissionFilter.apply(documents, currentUser); ListDocument reranked reranker.rank(question, allowed); Answer answer chatModel.answer(question, reranked);职责必须分开Embedding 和检索负责找资料权限系统负责决定资料是否可见数据库和工具负责真实业务状态聊天模型负责阅读证据和组织回答程序负责校验引用与关键字段。五、第四讲Transformer 与注意力机制5.1 为什么词语必须结合上下文苹果发布了新的手机。 我买了一斤苹果。同一个 “苹果”在第一句中表示公司在第二句中表示水果。模型需要根据 “发布、手机” 和 “一斤、买” 等上下文动态调整 Token 的表示。Transformer 的核心价值就是让每个 Token 能够结合上下文形成新的表示。5.2 位置信息如果模型只知道句子中出现 “小王、小李、批评”却不知道顺序就无法区分小王批评了小李。 小李批评了小王。因此输入中还需要位置信息。可以粗略理解为模型输入表示 Token 语义向量 位置信息不同模型可能采用不同的位置编码方式但目标都是让模型知道 Token 顺序和相对距离。5.3 Self-AttentionSelf-Attention 可以理解为当前 Token 根据自己的需要查看同一序列中其他可见 Token并按相关程度收集信息。例如小王把订单交给小李因为他负责审核。当模型处理 “他” 时可能重点参考 “小王、小李、负责、审核”从而形成更符合当前语境的表示。这不是模型内部真的写出一句中文推理而是向量按照注意力权重进行组合。5.4 Q、K、VQuery我正在寻找什么Key我可以怎样被匹配Value如果匹配到我我能提供什么信息可以类比图书馆检索Query读者的查询 Key书籍的标题、标签和主题 Value书中真正可读取的内容注意力经典公式为Attention(Q, K, V) softmax(QKᵀ / √d) V不需要死记公式但要理解四步Query 与 Key 计算匹配分数除以√d控制数值尺度Softmax 把分数转换成权重按权重汇总 Value。5.5 多头注意力一组注意力难以同时表示所有关系所以模型会使用多组注意力头。同一句话中不同头可能分别捕捉代词指代主语与宾语实体关系局部语法因果或时间关系。这些职责不是开发者手工指定的而是在训练中形成也不一定能被人类完全解释。5.6 因果遮罩生成式模型预测当前位置时不能偷看未来 Token。假设训练文本是HashMap 不是线程安全的预测 “线程” 时只能看到它之前的内容不能提前读取 “安全的”。因果遮罩保证位置只能关注自己和之前的位置。这也是许多生成式大模型采用 Decoder-only Transformer 后能够从左到右生成文本的基础。5.7 前馈网络、残差连接和归一化一层经典 Transformer 除了注意力还包含前馈网络FFN进一步转换每个位置收集到的信息残差连接将模块结果叠加回原始表示帮助保留信息和训练深层网络归一化稳定各层数值分布。可以粗略理解注意力我应该参考谁 前馈网络怎样处理收集到的信息 残差连接不要丢掉原始信息 归一化让多层计算保持稳定模型把这样的结构叠加很多层逐步形成更复杂的上下文表示。5.8 参数不是可查询数据库大模型参数本质上是训练得到的大量数值权重决定 Token 表示、Q/K/V 映射、信息组合以及下一 Token 概率。它们不是普通的业务规则if (word.equals(苹果) nextWord.equals(手机)) { meaning 公司; }知识分布在大量参数中所以模型可能记住大概模式却混淆精确事实、版本和数字。企业规则如果频繁变化不应只依赖模型参数而应通过数据库、RAG 或工具提供最新事实。5.9 KV Cache模型每生成一个新 Token都需要参考前面的 Token。若每一步都重新计算所有历史 Token 的 Key 和 Value会产生大量重复工作。推理系统通常缓存已经计算过的 K 和 V已有 Token 的 K/V → KV Cache 新 Token → 只计算新增部分 → 复用历史缓存KV Cache 能提高生成速度但会占用显存或内存。它只服务于当前推理过程不是用户长期记忆。5.10 长上下文为什么昂贵经典 Self-Attention 中每个 Token 都可能与其他 Token 建立关系。若序列长度为n注意力部分的计算和存储开销通常与n²有关。1,000 Token → 约 100 万组关系 2,000 Token → 约 400 万组关系现代模型会采用多种优化但基本方向不变更长上下文往往意味着更多计算、内存、延迟和干扰。5.11 注意力不等于可靠推理或安全假设系统规则禁止删除任何订单。 用户请求删除昨天创建的全部测试订单。模型可以识别冲突并提出拒绝但真正的权限边界必须由后端保证模型生成工具调用意图 → 身份与权限检查 → 参数和资源范围校验 → 高风险动作确认 → 幂等和事务保护 → 执行 → 审计日志模型说 “可以执行”不构成授权。六、把四讲连成一条工程链路现在把前面的知识合在一起用户消息 → Token 化 → Token 向量与位置信息 → Transformer 使用注意力组合上下文 → 逐步预测输出 Token如果任务需要外部知识用户问题 → Embedding → 向量与关键词混合检索 → 权限、版本和时间过滤 → Reranker → 相关原文进入上下文 → Transformer 结合证据生成回答 → 程序校验引用和关键字段从后端架构角度可以明确分工组件更适合负责LLM意图理解、信息综合、有限判断、语言生成Embedding语义表示和候选资料检索数据库 / API最新、精确、结构化的业务事实普通程序计算、校验、过滤、权限、状态机和幂等RAG提供外部知识和可追踪证据评估与日志判断系统是否真的完成任务并定位失败七、后端工程师需要牢记的 12 条原则LLM 的核心行为是预测下一个 Token不是查询事实数据库。流畅、自信和篇幅长都不能证明答案正确。上下文窗口是一次调用的工作空间不是长期记忆。系统规则、历史、工具定义、RAG 和工具结果都会消耗 Token。上下文越多不一定越好相关、清晰和无冲突更重要。程序负责精确计算模型负责理解和表达。Embedding 相似只表示语义接近不表示事实正确。订单号、金额、日期和版本应使用精确查询与结构化校验。RAG 检索必须同时考虑来源、版本、时间和权限。注意力能利用上下文但不能替代鉴权、风控和审计。KV Cache 是推理加速机制不是用户记忆。评估 Agent 时应看单位成功任务的准确率、成本和延迟而不只看一次回答。八、自测题附答案1. 为什么同一个问题可能得到不同答案因为模型输出的是候选 Token 的概率分布采样策略会影响每一步选择。2. 用户只输入十几个字为什么请求仍可能很贵因为输入还包含系统规则、历史对话、工具定义、检索资料、工具结果和输出要求Agent 还可能进行多轮模型调用。3. 模型为什么能记住上一轮对话通常是应用把历史消息重新放进了本轮上下文不代表模型自动拥有永久记忆。4. 相似度最高的文档一定是正确答案吗不一定。语义接近不代表逻辑一致也不保证版本、权限和事实正确。5. Q、K、V 怎样理解Query 表示当前要寻找什么Key 表示内容如何被匹配Value 表示匹配后提供的信息。6. 为什么 Prompt 中写了 “禁止删除” 还不够Prompt 只是模型运行协议不是安全边界。后端必须独立完成鉴权、参数校验、确认、幂等和审计。结语LLM 基础真正重要的地方不是让我们能够推导所有神经网络公式而是帮助我们预测系统失败什么时候模型会编造什么时候上下文会失控什么时候语义检索会找错什么时候注意力也无法保证遵守规则哪些工作必须由确定性的后端程序完成。当这些边界清楚以后Prompt、工具调用、RAG、记忆、规划和评估就不再是零散技巧而会成为一套可以设计、测试和治理的 Agent 工程体系。