All Pages Edit on GitHub

LLM Basics

理解大模型应用开发，需要先掌握几个核心概念。你不需要一开始就深入 Transformer 细节，但必须知道模型能做什么、不能做什么，以及为什么它有时会不稳定。

核心概念

概念 解释
Token 模型处理文本的基本单位，影响上下文长度和费用
Context Window 一次请求中模型能看到的最大内容范围
Temperature 控制输出随机性，越高越发散
System Prompt 定义模型角色、边界、输出规范和安全要求
Structured Output 要求模型按 JSON、表格或 schema 输出
Hallucination 模型生成看似合理但不真实的信息
Tool Calling 模型根据上下文选择并调用外部工具

大模型到底在做什么

从应用开发视角看，你可以先把大模型理解成一个“基于上下文生成下一个合理输出”的系统。它不会像数据库一样存储你的私有资料，也不会像普通函数一样保证同样输入永远得到完全相同输出。

这带来两个重要后果：

学习 LLM Basics 的重点不是背模型原理，而是理解模型在产品系统里的行为特点。

Token 为什么重要

Token 会同时影响三件事：

影响 说明
成本 输入和输出 token 都可能计费
延迟 上下文越长，通常响应越慢
质量 上下文过短信息不足，过长又可能稀释重点

新手常犯的错误是把所有历史对话、全部文档、所有规则都塞进 prompt。更好的方式是：只放当前任务真正需要的内容，并用检索、摘要、记忆和缓存管理上下文。

Context Window 不是记忆

上下文窗口只是“一次请求中模型能看到的内容”。它不是长期记忆，也不是数据库。

如果你要让系统记住用户偏好、历史记录或业务状态，应该把这些信息存到数据库里，在需要时取出相关部分放入上下文。这样做有三个好处：

消息角色怎么分工

常见对话接口会区分不同消息角色：

角色 放什么
system 稳定身份、边界、安全规则、输出原则
developer 应用层规则、工具使用方式、格式要求
user 用户当前问题和用户提供的内容
assistant 历史回答或模型中间响应
tool 工具执行结果

好的消息分层能让系统更稳定。不要把所有规则都混在用户问题里，也不要把用户可控内容当成高优先级指令。

LLM 应用的基本架构

一个最小 LLM 应用通常包含：

前端页面
  -> 后端 API
  -> Prompt 构造
  -> 模型调用
  -> 输出解析
  -> 日志和错误处理

复杂一点的系统会加入：

开发者应该理解的能力边界

大模型擅长：

大模型不天然擅长：

模型选择的基本思路

不要只按“最强模型”选择。真实项目里通常要在质量、速度、成本和稳定性之间取舍。

任务 选择建议
分类、打标签、简单抽取 优先小模型，低 temperature
复杂推理、代码分析、长文档综合 使用更强模型
批量离线处理 关注成本和吞吐
用户实时对话 关注延迟和流式输出
高风险答案 更强模型 + 检索 + 人工复核

一个成熟系统可能不会只用一个模型，而是根据任务路由到不同模型。

学习检查点

模型参数怎么选

参数 建议
temperature 分类、抽取、JSON 输出用低温度；创意写作用高一点
max output tokens 给足空间，但不要无限制
system prompt 放稳定角色、边界和规则
user message 放用户当前任务
tools 只暴露当前任务需要的工具

Temperature、Top-p 和稳定性

对新手来说，先记住一个简单规则：越需要稳定和可复现，temperature 越低；越需要创意和多样性，可以适当提高。

典型选择：

但参数不是万能的。如果 prompt 含糊、上下文缺失、输出没有 schema，temperature 再低也可能不稳定。

幻觉从哪里来

常见来源：

缓解方式：

结构化输出为什么重要

只给用户看的回答可以是自然语言，但给程序继续处理的结果应该尽量结构化。比如分类、抽取、评分、路由、工具参数，都适合用 JSON 或 schema。

结构化输出的好处：

常见失败处理：

隐私和安全边界

调用模型时要特别注意：

模型可以参与判断，但最终权限和安全策略应该由系统代码控制。

实战练习