【0-1的agent进阶篇】LLM基础原理

个人主页代码不加冰欢迎来访作者简介java后端学习者❄️个人专栏LeetCode刷题日记 苍穹外卖日记SSM框架深入JavaWeb✨命运的结局尽可永在不屈的挑战却不可须臾或缺前言大家好我是代码不加冰接着前面的从0-1的agent专栏在那里我们对agent整体有了一个了解而我们接下来就要细致的对agent进行学习让我们一起来看看吧。至于python的基础语法再加上一点python的后端这一部分过几天再学摘要作为一个后端学习者习惯了确定性的代码逻辑刚接触LLM时会经历一段痛苦期。很多系统问题并不是代码 Bug而是模型的不确定性在系统架构中被放大了。我们需要明确一个核心认知大模型并不是真正的智能它本质上是一个基于海量训练数据、预测下一个 Token 的概率机器。学习 LLM 基础的目的不是为了去训练或微调模型而是为了“预测模型在系统里的失败方式”。只有理解了它的底层机理我们才能在接口设计、重试策略、Prompt 工程以及 Agent 系统架构中做好兜底与防御性编程。一、 Token 与上下文窗口1. 什么是 Token模型处理的不是原始文本也不是字符而是 Token词元。Token 是文本片段的最小统计单位例如英文中一个单词可能是 1-2 个 Token中文一个汉字通常对应 1-2 个 Token。计费基础API 调用的成本Input/Output完全由 Token 数量决定。性能瓶颈Token 数量直接决定了首字延迟TTFT和整体推理时间。2. 上下文窗口Context Window每个模型都有其最大的上下文限制如 8k、32k、128k 甚至百万级别。上下文长度不等于长期记忆增加上下文长度只是拉长了模型的“短期工作内存”。它没有真正的、持久化存储的“记忆能力”。截断策略Truncation Strategies当用户的对话历史或注入的背景知识超过限制时系统必须进行截断。是采取“滑动窗口丢弃最旧的对话”还是“总结压缩”这需要后端在业务层实现否则直接调用接口会导致400错误。大海捞针Needle In A Haystack问题即使模型宣称支持 128k 上下文并不意味着它能完美提取中间段落的信息。长上下文中容易出现信息遗忘或注意力偏移通常两头效果好中间效果差。二、 Transformer 与注意力机制我们不需要像算法工程师那样去推导复杂的数学公式但必须在工程直觉上理解Transformer 架构和自注意力机制Self-Attention。1. 下一个 Token 预测Next-Token PredictionLLM 的运行逻辑非常简单输入一段文本模型计算出下一个最可能出现的 Token 的概率分布然后选择一个输出接着将这个新 Token 放入输入中继续预测下一个。状态丢失每一次生成都是基于当前窗口内的所有 Token。模型没有“撤回”或“边想边写”的能力它在写下第一个字时其实并没有想好整句话怎么结尾。为什么叫预测 Token大模型本质上是一个概率文本续写机。它不能像人类大脑一样在落笔前就构思好整句话的结构它每一次只能蹦出一个词Token。其工作流程是一个死循环Loop输入你给模型发了一句话今天天气真。预测模型通过复杂的概率计算从自己的词表Vocabulary里挑出下一个概率最高的 Token。比如它算出来好的概率是 80%糟的概率是 10%……输出模型选择了好并把它吐给你。滚动循环接着模型把今天天气真好整体作为新的输入再次塞入模型去预测下一个 Token比如预测出啊。这个根据前文算出下一个概率最大的词的过程就叫做预测 Token。Transformer 是一种革命性的神经网络架构。现今所有主流的大模型如 GPT-4、Claude、DeepSeek、Llama其底层的核心算法架构都是 Transformer。在它出现之前AI 很难处理长文本。Transformer 的出现改变了这一切它之所以这么强大核心在于解决了两个痛点1. 核心机制自注意力机制Self-Attention在 Transformer 之前模型看句子是一字一句按顺序读的像磁带。读到句尾句头就忘得差不多了。而 Transformer 的注意力机制让模型可以同时“看到”整句话里的所有 Token并自动计算出词与词之间的关联权重。举个例子银行把贷款利率调高了因为他们需要控制风险。当模型处理到他们这个 Token 时Transformer 的注意力机制会像连线一样给银行分配极高的权重。模型瞬间就能精准理解这里的他们指代的就是银行。2. 为什么要了解它因为 Transformer 的这种“同时看所有词”的特性导致了以下两个工程结果显存占用与上下文长度呈二次方爆炸O(N^2)输入的文本越长N越大词与词之间两两计算关联的矩阵就呈指数级飙升。这就是为什么长上下文的 API 极其昂贵且容易导致 GPU 显存溢出OOM。天然支持并行计算正因为不需要像老旧模型那样按顺序死板地读Transformer 可以在训练时大批量并行处理海量数据这才是今天“千亿参数大模型”能够被训练出来的技术基石。总结来说Transformer 是底层的机器发动机架构它运作的方式是通过不断地“预测下一个 Token”来生成文本而在这个过程中每一次计算都在消耗算力和 API 。三、 采样参数如何驯服模型的不确定性调用 LLM API 时参数配置直接决定了输出的稳定性。我们作为后端设计者不能全用默认值要根据业务场景精细化控制参数定义与作用业务场景指导Temperature采样温度。值越高概率分布越平缓输出越随机、有创意值越低越倾向于选概率最高的词。0.0或极接近0用于结构化数据提取、代码生成、SQL生成等需要高确定性的场景。0.7 - 1.0用于文案创作、头脑风暴。Top_p (Nucleus)核采样。模型只在累积概率达到 p 的 Token 集合中进行采样。- 通常与 Temperature二选一调节。- 限制top_p0.1意味着只保留最靠前、最稳妥的 10% 的词汇候选池。Max_tokens最大输出长度限制。防爆控制防止模型陷入死循环或输出过长导致 API 费用暴增。- 需要在接口层做好截断与打断机制。Stop Words停止词。一旦模型生成了指定的 Token立即强行停止输出。Agent开发利器在让模型输出 JSON 或特定工具调用格式如Thought: ... Action: ...时可以用 Stop Words 阻止模型继续往下瞎编从而及时交回控制权给后端代码。四、 幻觉与不确定性1. 为什么会产生幻觉Hallucination幻觉不是 Bug它是 LLM 的原生特性。因为模型是“概率预测机”它的目标是让句子读起来“通顺、合理”而不是“事实正确”。当它的训练数据中缺乏相关知识或者 Prompt 的引导存在偏见时它就会以极其自信的语气编造事实这些都是很常见的问题。2. 哪些任务容易产生幻觉计算与逻辑推理模型无法在内部运行真正的数学公式它只是在“模仿”计算题的文本格式。长尾/冷门知识检索询问知名度极低的人名、罕见的 API 用法。复杂引用让模型指出某句话出自具体哪本书的哪一页。后端防御性思维永远不要信任模型的直接输出。如果业务不允许幻觉如医疗、金融、客服必须在架构上引入RAG检索增强生成注入权威上下文或者在后端使用结构化验证如 Pydantic、Json Schema对模型返回的数据进行强类型校验与解析重试。五、 模型能力差异按需选型的工程策略在后端系统设计中一套架构可能会组合使用多种模型。盲目追求“最贵、最强”的模型往往会导致 ROI投资回报率低下。我们需要区分以下五种模型能力通用对话模型General Chat如 GPT-4o、Claude 3.5 Sonnet。理解复杂指令能力强适合作为 Agent 的核心大脑处理流程调度和复杂意图识别。推理模型Reasoning如 OpenAI o1 / o3 / DeepSeek-R1。这类模型在输出前会进行长期的内部“思考CoT”极大地提升了数学、代码和复杂逻辑推理的准确率但响应时间TTFT较长、成本较高。代码模型Code-specific针对语法、上下文学过专门优化的模型。适合用于代码生成、自动化补全或日志分析。多模态模型Multimodal能同时接收/输出文本、图片、音频。在设计后端接口时需要考虑多媒体流式传输、二进制数据存储及文件生命周期管理。Embedding 模型嵌入模型本质区别它不输出文本而是将文本转化为高维向量Vector。后端核心用途它是 RAG 和向量检索的基石。后端工程师需要处理 Embedding 的批量生成、向量数据库如 Milvus, Pinecone的写入与相似度检索Cosine Similarity。结语站在后端架构的角度LLM 就像是一个极其聪明、但满嘴跑火车、偶尔还会间歇性失忆的外部依赖服务。我们学习上述基础的目的是为了在写下每一行调用代码时心里都能清醒地意识到这个接口随时可能超时需要配置长超时与流式传输Stream。返回的 JSON 格式随时可能崩溃需要写好 Try-Catch 与格式修复逻辑。模型的输出可能因为今天换了一个标点符号而完全不同需要建立自动化评估集进行回归测试。