LLM 应用基础

把大语言模型（LLM）当成"会聊天的数据库"或"更聪明的搜索引擎"，是大多数应用失败的起点。它既不存储事实，也不检索网页，而是一个根据上下文预测下一个 Token 的概率模型。理解这一点，才能判断哪些事该交给它、哪些不该。

它本质是在预测下一个 Token

模型把输入文本切成 Token，根据已见过的所有 Token，计算词表中每个候选 Token 出现的概率，挑一个接上去，再循环这个过程。

输入: "今天天气"
  → 计算: 真(0.6) / 很(0.2) / 不(0.1) / ...
  → 选取: "真"
输入: "今天天气真"
  → 计算: 好(0.7) / 不错(0.2) / ...
  → 选取: "好"

这个"逐 Token 生成"带来几个直接后果：

• 没有事实存储：它"知道"的东西，是训练数据在权重里留下的统计痕迹，不是可查询的记录。
• 同一输入不同输出：每次采样带有随机性，问两遍可能得到不同答案。
• 不可靠的计数与推理：长文本字数、列表序号、多步数学推理，常常出错，因为它在"生成"而非"计算"。

Token 与上下文窗口

Token 是模型计费和计长度的单位，大致是"一个汉字约 1-2 个 Token，一个英文单词约 1 个 Token"。上下文窗口是模型一次能"看见"的全部文本长度上限（输入 + 输出）。

概念	含义	实践影响
输入 Token	你发给模型的 prompt 与历史	越长越贵、越慢
输出 Token	模型生成的回复	通常单独计价，更贵
上下文窗口	输入 + 输出的总上限	超出会被截断或报错

超出窗口不是"模型忘了前面"，而是"前面根本没被看见"。塞进去的文本越多，注意力越分散，关键信息反而容易被忽略——这叫"中间迷失"（lost in the middle）。所以并非"上下文越长越好用"。

温度与采样

温度（temperature）控制生成的随机程度：

• 温度趋近 0：几乎总是选概率最高的 Token，输出稳定、确定，适合事实问答、代码、结构化提取。
• 温度较高（如 0.7-1.0）：概率分布被拉平，低概率 Token 也有机会被选中，输出更多样、有创造性，适合文案、头脑风暴。

温度 0:  "今天天气真好"（每次几乎一样）
温度 0.8: "今天阳光挺通透的"（每次不同，但都合理）

需要稳定可复现的场景（如提取 JSON、分类），把温度设为 0；需要发散的场景，再调高。不要用一个高温度配置去跑要求确定性的任务。

能力边界：幻觉从哪里来

幻觉（hallucination）指模型生成看起来合理但与事实不符的内容。它不是 bug，而是概率生成的必然产物：当训练数据里没有准确答案时，模型会生成"统计上最像答案"的文本，而不是承认不知道。

常见的不可靠场景：

场景	为什么不可靠
具体事实、数字、日期	权重里没有精确记录，靠统计拼凑
引用来源、文献	会编造看起来真实的标题、作者、URL
严格计数与长列表	逐 Token 生成不维护内部状态
自我描述	不知道自己的训练数据和版本细节

应对不是"消灭幻觉"，而是把它当作可管理的风险：让模型在有据可查的范围内回答（这就是 RAG 的动机），要求它给出引用，对关键输出做校验，把"可能出错"纳入产品设计而不是假设它一定对。

上层应用的心智模型

理解了上述基础，再去看 Prompt、Agent、RAG，会清晰很多：

• Prompt 工程：在固定权重下，用更好的输入引导出更可靠的输出。
• Agent：让模型通过"调用工具"绕过它不擅长的部分（计算、检索、查询），把可验证的操作交给确定性代码。
• RAG：把私有或最新知识塞进上下文，让模型在"有据"的范围内生成，减少幻觉。

务实的选择清单

• 这个任务需要确定性还是创造性？据此定温度。
• 输入加输出会不会逼近上下文窗口？关键信息放在开头和结尾。
• 模型的回答是否可被外部验证？不能验证的部分不要直接面向用户做关键决策。
• 失败的成本多大？低成本容错场景可以大胆用，高风险场景必须加校验或人工确认。

把 LLM 当成一个"知识渊博但会自信地说错话、不会自己查资料"的合作者，应用层的很多设计就自然落地了。