LLM 基础概念

做 AI 应用，首先要搞清楚你在接入什么——它能做什么，边界在哪里，哪些地方会出问题。

本章目标

• 能用自己的话解释 LLM、Token、Context Window、Temperature 这几个高频概念
• 知道大模型既不是数据库，也不是天然可靠的事实来源
• 能把模型能力边界和工程补偿手段对应起来

什么是 LLM

LLM（Large Language Model）可以先理解成一种基于海量文本训练出来的语言理解与生成系统。它擅长：

• 文本生成
• 摘要与改写
• 信息抽取
• 基础问答
• 分类与归纳
• 代码解释与辅助生成

但它本质上不是按规则硬编码输出，而是根据上下文不断预测下一个最可能的 token。

LLM 真正擅长的是根据上下文组织最可能出现的表达和推理路径，不是"存储知识"。它表现得像懂了很多，是因为训练数据里确实包含了大量模式；但这种"懂"是统计压缩后的语言能力，跟数据库逐条存事实不是一回事。

LLM 和传统程序的区别

传统程序

• 输入明确
• 规则明确
• 输出可预测
• 逻辑由程序员显式编写

LLM

• 输入通常是自然语言
• 输出是概率生成结果
• 它更像根据上下文做近似推理和语言组织
• 同一个问题，不同提示方式、上下文和参数可能得到不同回答

模型是怎么生成内容的

理解这个有助于你预判模型什么时候会出错，为什么会出错。

LLM 生成内容的基本方式是：每次只预测下一个 token，预测完成后这个 token 成为上下文的一部分，再预测再下一个，一直到遇到停止条件。

举个例子，假设你发送了"北京的首都是"，模型拿到这段上下文后，会计算词表里每个 token 出现在这个位置的概率，然后从高概率的 token 里选一个（不一定是最高的，具体怎么选取决于 Temperature 参数）。选出来的 token 追加到上下文里，再算下一个……

理解了这个过程，下面几个问题就好回答了：

为什么模型输出有随机性：即使同样的输入，每次选 token 时的概率采样结果不同，所以输出会有差异。Temperature 参数控制这个随机程度——越低越倾向于选概率最高的 token，越高越倾向于随机。

为什么模型会"言之凿凿地说错话"：模型看到的是上下文，它做的是"什么词在这个上下文里最可能出现"，而不是"什么话是真的"。一段让模型自圆其说的上下文，会让它生成听起来有道理但实际错误的内容。

为什么给更好的上下文能得到更好的结果：模型的输出质量直接受输入质量影响。上下文更清晰、任务说明更具体，模型预测下一个 token 时能参考的信息就更准确。Prompt 工程之所以存在，原因就在这里。

为什么结构化约束有效：当你要求模型输出 JSON，或者用厂商的原生结构化输出 API 时，实际上是在限制模型可以选择的 token 范围，让它不能随意生成不符合格式的内容。

训练和推理，是两件很不一样的事

很多初学者会把模型训练时学到的东西，和你现在调用模型时发生的事情混在一起。其实它们分属两个阶段：

• 训练阶段：模型从海量数据里学习参数，形成对语言模式和任务结构的统计表示
• 推理阶段：模型在当前上下文里，根据这些参数和你提供的输入，逐 token 生成结果

所以你在 API 调用时没法"临时教会"模型一个真正的新知识——你能做的是在推理阶段给它补上下文，让它在这一轮里看起来像知道了某件事。Prompt、RAG、Tool Calling 存在的理由都跟这一点有关。

什么是 Token

Token 是模型处理文本时使用的最小单元。它不完全等于一个汉字或一个英文单词，但工程上你要记住三件事：

• 输入长度通常按 token 计费
• 输出长度也按 token 计费
• 对话越长、检索资料越多，成本和延迟越高

什么是 Context Window

Context Window 是模型在一次生成时能“同时看到”的上下文上限。它包括：

• System Prompt
• User Prompt
• 对话历史
• 工具调用结果
• 检索到的资料
• 模型已经生成的内容

上下文不是越多越好。无关内容太多会带来：

• token 成本上升
• 重要信息被噪音淹没
• 旧信息被截断
• 回答质量下降

可以把 Context Window 理解成模型这一轮推理时的"工作记忆"。工作记忆越大，不代表一定越聪明；真正重要的是，你往里放的内容是不是和当前任务高度相关。

LLM 不是数据库

这个判断越早建立越好。模型根据训练里学到的模式可以“像知道很多东西”，但它不能保证：

• 实时天气正确
• 最新新闻准确
• 企业私有资料可用
• 数据库实时状态一致

遇到这类需求时，通常要引入：

• Tool Calling
• RAG
• 数据库查询
• 外部 API

LLM 也不是逻辑引擎

LLM 也不是严格意义上的逻辑引擎。这一点比"不是数据库"更容易踩坑。

它可以表现出推理能力，但这种推理更多是语言和模式驱动的近似推理，不是像定理证明器那样稳定、可枚举、可证明。对简单逻辑题，它往往表现不错；一旦进入长链路、多约束、需要精确中间步骤的任务，就更容易漂移、跳步或者把看似合理的结论接上去。

真实系统里，一到需要高精度逻辑、确定性执行或外部事实的地方，就得把一部分能力交给工具、程序规则或校验系统。

为什么模型会“像懂了”，但不完全可靠

模型很擅长生成看起来合理的语言表达，但这跟"说得对"是两回事。常见的问题：

• 事实性错误
• 过度推断
• 编造细节
• 编造来源

结构化输出、检索、工具调用、评测和安全这些手段不是锦上添花，是必须的。

工程里常见的模型参数

Temperature

控制输出的随机性。一般来说：

• 越低：结果更稳定，适合抽取、分类、结构化输出
• 越高：表达更发散，适合创意生成

Max Output Tokens

控制单次最多生成多少内容。过短会截断，过长会增加成本。

Streaming

流式输出不是让模型“更聪明”，而是让前端体验更好，用户能更早看到内容返回。

参数不是"性格开关"

Temperature 这类参数影响的是采样分布，不是给模型切换一种本质不同的大脑。低 Temperature 让输出更保守；高 Temperature 让输出更发散，但不会带来更深的思考能力。参数调优是输出分布控制，不是能力升级。

一个最小模型应用链路

1. 用户在前端输入问题
2. 前端把问题发给后端
3. 后端组织 prompt
4. 后端调用模型 API
5. 模型返回结果
6. 前端展示结果

后面学的内容，基本都是在这条链路上叠加：

• 结构化输出
• 工具调用
• 检索增强
• 安全校验
• 日志与评测

容易踩的误区

误区：Context Window 越大越好，尽量多塞

初学者调 API 时，容易把所有能用上的内容都往 prompt 里加：完整的系统说明、所有历史对话、全量检索结果、详细的工具说明……觉得给模型"更多信息"总是有帮助的。

实际效果往往相反：

• 重要信息被无关内容稀释，模型更难找到关键点
• Token 成本直线上升，延迟也会增加
• 超出上下文窗口时，最早的对话会被截断，而模型不会提示你

更好的做法：只放和本次任务直接相关的内容，把"如何选择放什么"当成一项工程能力来建立，而不是默认塞满。

误区：模型回答得自信，说明它答对了

模型的表达风格和它的准确率没有直接关系。它完全可以用非常肯定的语气说出一件错误的事，或者编造一个看起来合理的来源引用。这不是 bug，是语言生成模型的基本特性。

遇到需要事实可靠的场景，必须用工具获取实时数据、用检索系统查真实来源，而不是相信模型"说得很有把握"。

语言流畅不代表事实可靠。越靠近真实业务，约束、校验和回退机制就越不能省。

为什么“同一个模型”在不同产品里表现会差很多

同一个底层模型，放在不同产品里看起来像完全不一样。通常不是模型变了，而是外围系统差异很大：

• Prompt 是否清楚
• 上下文组织是否合理
• 有没有检索和工具
• 有没有结构化输出和校验
• 有无安全边界、失败兜底和日志

别把产品效果简单归到"模型强不强"上。真实工程里，模型能力只解释一部分，系统设计往往解释更多。

从 Claude Code 看 Prompt Cache 成本控制

只知道"Token 计费"还不够用，生产环境里有一个更精细的成本控制手段：Prompt Cache（提示词缓存）。

每次调用 API 时，系统提示词和工具描述通常是固定的，每次都重新发送、重新计费是在浪费钱。Prompt Cache 的做法是把不变的那部分上下文缓存在 API 侧，后续请求复用，费用大幅下降。

Claude Code 的实现里（来自 v2.1.88 constants/prompts.ts）有一个常量叫 SYSTEM_PROMPT_DYNAMIC_BOUNDARY，它把系统提示词切成两块：边界之前是静态内容——工具描述、基础规则、不变的上下文——跨请求共享缓存；边界之后是动态内容——当前工作目录、Git 状态、用户的 CLAUDE.md——每次重新生成。

落到工程上：设计系统提示词时，把稳定的部分和每次变化的部分分开，就能有效降低 API 成本。省钱靠的是缓存结构，不是压短文字。

写代码时容易忘的几件事：训练阶段决定模型大概会什么，推理阶段决定这一次怎么表现，两者不要混。Context Window 是工作记忆，放得下不等于放得好。还有，真实产品效果往往不是模型单独决定的，Prompt 设计、检索、校验、兜底逻辑加在一起才是用户体验。

常见面试考点

基础概念页对应的题目会很散，但高频点其实都围绕“模型为什么这样工作，以及工程上怎么处理它的边界”。

1. Token 计算：Token 是计费、上下文长度和延迟的基本单位；输入、输出、历史消息、工具结果都会占用 token。
2. Context Window 限制：窗口大不代表可以无脑塞资料，关键信息被噪音稀释、旧上下文被截断，都会让回答质量下降。
3. 训练与推理区别：训练改变参数，推理只是在当前上下文里生成；临时补资料更适合 RAG 或工具，不是“现场训练模型”。
4. Temperature：它控制采样随机性，不是智商开关；抽取和结构化任务通常更适合低温度。
5. 幻觉根因：模型生成的是上下文中高概率的表达，不直接验证事实；需要检索、工具、校验和评测来补工程边界。
6. 模型能力和产品体验：同一个模型在不同产品里效果差很多，常常是 Prompt、上下文组织、工具链和安全兜底不同。

#下一章：Prompt 工程——模型是什么搞清楚了，接下来是怎么稳定地给它下任务。