21 LLM 应用基础

难度：入门｜前置：系统思维、HTTP｜目标：理解模型调用的输入、输出、限制和不确定性

LLM 在做什么

从应用工程角度，可以先把 LLM 理解为：

根据已有上下文，持续预测下一个 Token 的概率模型。

它不是数据库，也不是确定性函数。即使回答看起来有逻辑，也可能包含错误事实。

一次模型请求

System / Developer Instructions
+ 历史消息
 模型可用工具
 检索到的资料
 用户输入
→ 模型
→ 文本或结构化输出 / Tool Call

模型只能看到本次上下文，不会天然知道业务数据库、用户最新状态和过去任务，除非应用显式提供。

Token 与上下文

Token 是模型处理文本的基本单位。上下文越长：

• 输入成本增加；
• 延迟增加；
• 重要信息可能被淹没；
• 更容易混入无关或恶意内容。

因此不能把所有历史、所有文档都塞进 Prompt。

Temperature 不等于真实性

降低 temperature 通常让输出更稳定，但不能把模型变成事实数据库。正确性仍应来自：

• 业务工具；
• 可靠知识源；
• Schema 和规则；
• Eval；
• 人工复核。

三种输出形态

1. 自然语言：适合解释和草稿；
2. 结构化输出：适合程序继续处理；
3. Tool Call：请求应用执行外部能力。

能产生 JSON 不代表业务正确；能选择工具也不代表拥有执行权限。

模型错误分类

类型	示例	工程措施
事实错误	编造设备记录	RAG/Tool、引用
格式错误	字段缺失	Schema、重试、回退
推理错误	结论与证据矛盾	分步验证、规则
工具错误	选错工具	工具描述、Eval、限制
安全错误	遵循文档恶意指令	隔离数据与指令、权限

自测

1. 为什么同样输入不能保证每次完全相同？
2. 模型为什么不会天然知道最新设备状态？
3. 降低 temperature 为什么不能消除幻觉？
4. 文本、结构化输出和 Tool Call 分别适合什么？

完成标准

• 能画出一次模型请求包含哪些上下文
• 能解释 Token、上下文和成本关系
• 能列出五类模型错误
• 能说明模型与数据库的根本区别

下一单元：结构化输出