面向程序员 · 从零开始 · 可直接用于面试复习

大语言模型 LLM 是什么，一次讲明白

LLM 不是搜索引擎，也不是一个真正理解世界的人。更准确地说，它是一个大型概率模型：读入上下文，把文字切成 token，计算关系，再一个 token 一个 token 地生成结果。

它处理的是 token 输入不是整句话，而是一段 token 序列。模型根据上下文预测接下来更可能出现什么。

它靠参数记住模式 训练把海量文本里的语言、代码和知识模式压进参数，不等于保存原文数据库。

它会写，但会错 生成结果常常很像对的答案。是否真实、是否符合公司规则，需要外部校验。

它适合做能力服务 程序员要关心输入约束、输出格式、检索、工具调用、评测、日志和兜底。

llm.generate(context)

用户：解释 LLM 。

token embedding position

attention layers weights

logits sample stop

next token: "模型"

0.64

01 · 先给一个能用的定义

LLM 是会根据上下文生成语言的大型模型

别急着背 Transformer、参数量、注意力机制。先把它当成一个语言生成服务：你给它上下文，它返回一段文本。区别在于，它不是按固定模板拼字符串，而是根据训练得到的参数计算下一个 token。

Large

为什么叫大

模型参数多，训练数据多，训练成本高。规模变大后，它能覆盖更多语言、代码和任务模式。

Language

为什么叫语言

它主要处理文本序列。代码、JSON、SQL、Markdown 也可以看成语言。

Model

为什么叫模型

它不是业务规则集合，而是一组经过训练的参数。参数决定了输入到输出的映射。

Generate

它怎么回答

它不断预测下一个 token，追加到输出里，再继续预测，直到遇到停止条件。

面试里先这样讲 LLM 是一种用大规模文本训练出来的语言模型。它把输入转成 token 序列，在上下文里计算这些 token 的关系，然后逐步生成后续 token。它擅长理解和生成文本，但不天然等于搜索、数据库或业务系统。

02 · 程序员视角

可以先把 LLM 看成一个概率函数

程序员写系统时，最怕概念飘在空中。把 LLM 放成函数会清楚很多：输入是指令和上下文，输出是一段文本或结构化结果。不同的是，这个函数不是确定性业务代码。

Prompt
任务、角色、格式、约束

→

LLM
参数、上下文、采样策略

→

Output
文本、JSON、代码、工具参数

const result = await llm.generate({
  system: "你是企业商品系统的需求分析助手",
  user: "根据这段描述生成 PRD 草稿",
  context: docsFromKnowledgeBase,
  responseFormat: "json"
});

它像服务，不像库函数

同一个输入在不同参数、不同采样配置下可能有细微差异。线上要记录版本和配置。

它会补全，也会猜

上下文缺失时，模型仍然会生成听起来完整的回答。完整不代表正确。

它需要外围系统

真实产品会有检索、工具调用、权限、日志、评测和人工审核，LLM 只是其中一个组件。

03 · Token

LLM 不直接读句子，它读 token

Token 可以理解成模型处理文本的最小片段。一个中文词可能是一个 token，也可能被拆开；英文单词也可能被拆成子词。计费、上下文长度、生成速度，很多都和 token 有关。

原始输入

请根据商品录入系统的现状，生成一份批量导入需求说明。

为什么程序员要关心 token

上下文窗口按 token 计，不是按字数计。
模型生成越长，延迟和成本通常越高。
RAG 塞太多文档会挤掉任务说明和历史对话。
输出 JSON 时，要给模型留下足够的生成空间。

// 一个粗略经验：上下文 = 系统提示 + 用户问题 + 检索文档 + 历史消息 + 预留输出
if (contextTokens > maxWindow - outputBudget) {
  compressOrRetrieveLess();
}

04 · Embedding

文字会被转换成向量，语义才方便计算

模型不能直接对“商品”“订单”“库存”这些词做数学运算。Embedding 会把 token 或文本片段变成一组数字。向量距离能表达语义接近程度，这也是知识库检索常用的基础。

向量化前后

对人来说，“商品”和“SKU”有业务联系。对模型来说，这种关系要落到向量空间里。

"商品"  → [0.12, -0.38, 0.74, ...]
"SKU"   → [0.10, -0.35, 0.71, ...]
"天气"  → [-0.66, 0.18, -0.21, ...]

商品 SKU 库存订单支付天气温度

Embedding 不是答案

它只是表示方式。相似度高说明内容可能相关，不代表内容真实或适合当前问题。

向量库不是万能搜索

企业知识库常把向量检索和关键词检索混合使用，避免字段名、编号、枚举值查不准。

切片很影响效果

文档切得太碎会丢上下文，切得太大又占窗口。RAG 的质量很大一部分来自这里。

05 · Transformer

注意力机制让模型知道该看哪里

现代 LLM 大多基于 Transformer。先不用害怕公式，可以把注意力理解成“每个 token 在生成当前结果时，需要参考哪些 token”。它不是人类注意力，但这个比喻足够用来入门。

一句话里的依赖关系

“它”到底指什么，需要看上下文。注意力机制就是在大量 token 之间计算关系权重。

商品导入失败时它应该提示错误行

商品导入失败时它应该提示错误行权限校验 SKU 模板导入结果按钮日志回滚状态错误下载

位置编码

同样的词放在不同位置，含义可能不同。模型需要知道 token 顺序。

多层堆叠

低层可能处理局部语法，高层可能组合更抽象的任务模式。这里不要理解成固定分工。

参数记忆

训练后的权重保存了大量统计模式。模型不是把原文一条条存起来再检索。

06 · 训练

训练不是让模型背答案，而是调参数

LLM 的训练通常分几个阶段。不同公司做法会有差异，但大方向类似：先学语言和世界知识，再学如何听指令，最后通过评测和偏好数据让回答更可用。

1 收集语料 网页、书籍、代码、文档等，先做清洗和去重。

2 预训练 让模型预测 token，学语言规律和大量模式。

3 指令微调 用问答和任务样例教模型按指令回应。

4 偏好优化 用人工或模型偏好，让输出更符合使用习惯。

5 安全对齐 减少危险内容、隐私泄露和不合规输出。

6 评测发布 跑能力、安全、稳定性和成本评估。

阶段	模型学到什么	程序员可以怎么理解	常见误解
预训练	语言、代码、事实片段、表达模式	像把大量文本压缩进参数，但不是普通压缩包。	以为模型一定能准确复述训练资料。
指令微调	如何按问题、任务和格式回应	让模型从“会续写”变成“会做任务”。	以为只要提示词好，就不需要训练阶段。
偏好优化	哪些回答更有帮助、更稳、更符合规范	让模型学会避开差答案和坏习惯。	以为它能消除所有错误。
领域适配	特定格式、语气、术语或任务套路	可以用微调，也可以用 RAG 或 Prompt 模板。	把微调当成知识库更新。

07 · 推理

线上请求里，模型是在循环生成 token

训练好的模型上线后，每次调用都会走推理流程。程序员要关心的不只是答案质量，还有延迟、成本、并发、缓存、流式输出和失败重试。

1 拼上下文 系统提示、用户输入、历史消息、检索内容。

2 切 token 把文本变成模型能处理的 token id。

3 模型计算 经过多层网络，得到下个 token 的分布。

4 采样选择 根据 temperature、top_p 等参数选 token。

5 追加输出 新 token 加入上下文，继续下一轮。

6 停止返回 遇到结束符、长度限制或业务停止条件。

Temperature

控制随机性。低一些更稳定，高一些更发散。写代码、抽取 JSON 通常不需要太高。

Top-p

从累计概率达到阈值的一组候选里采样。它影响模型输出的多样性。

流式输出

边生成边返回，用户感知更快。后端要处理取消、超时和不完整 JSON。

08 · Prompt

Prompt 是给模型的运行时上下文

Prompt 不是咒语。对程序员来说，它更像接口协议：说明任务、输入、输出格式、边界条件和失败处理。写得好，模型更容易走到你想要的轨道上。

含糊版本

容易得到泛泛回答

帮我写一个商品导入需求。

问题太短，模型不知道系统现状、用户角色、字段规则、异常处理、输出格式。

可落地版本

像接口一样写清楚

你是企业商品系统的需求分析师。
任务：根据资料生成 PRD 草稿。
资料：{knowledge_docs}
输出：JSON，包含 scope、flow、rules、edgeCases、openQuestions。
限制：不能编造不存在的字段，缺信息放入 openQuestions。

任务、资料、格式、限制都给了，后续更容易校验和接入系统。

一个实用的 Prompt 骨架

角色：你在当前系统里扮演什么角色。
任务：本次要完成什么。
上下文：业务资料、接口、字段、历史结论。
边界：哪些不能做，哪些不能猜。
输出：格式、字段、长度、语言。
校验：如果资料不足，应该怎么处理。

09 · RAG、Tool Calling、微调

别把所有问题都交给模型参数

企业系统里的很多知识变化很快，比如字段、接口、权限、政策、库存、订单状态。把这些都寄希望于模型“记住”并不现实。需要事实时，让模型去查；需要动作时，让模型调用工具；需要稳定风格或格式时，再考虑微调。

RAG

让模型查资料

先从知识库检索相关文档，再把片段塞进上下文。适合制度、文档、历史需求、FAQ。

优点：知识更新快，不必重训模型。
风险：检索错了，回答也会偏。

Tool Calling

让模型调工具

模型生成工具参数，系统去查数据库、调接口、跑计算或执行动作。模型不应该直接改生产数据。

优点：能拿实时数据，能接业务系统。
风险：权限、幂等、审计要设计好。

Fine-tuning

让模型学风格或任务

用样本调整模型行为。适合固定格式、专业表达、重复任务，不适合当成实时知识库。

优点：输出更稳定，提示词可变短。
风险：数据准备和评测成本更高。

选择方法时先问这几个问题

答案依赖最新资料吗？ 依赖，就优先 RAG 或工具查询，不要靠模型记忆。

需要执行真实动作吗？ 需要，就做工具调用，并加权限、审批、日志和幂等。

主要问题是格式和风格不稳定吗？ 可以先做更好的 Prompt 和评测，再决定是否微调。

输出能被程序校验吗？ 能结构化就结构化。JSON Schema、枚举校验、引用来源都很有用。

10 · 工程落地

一个 LLM 应用，不只是一次模型调用

做 Demo 可以只写 prompt。进企业系统后，要把 LLM 放进完整链路里：输入怎么来，知识怎么查，输出怎么验，失败怎么兜底，效果怎么评估。

1 入口层 表单、聊天框、批处理任务、接口调用。

2 上下文层 拼 prompt、查知识库、过滤敏感信息。

3 模型层 选择模型、配置采样、控制成本和超时。

4 工具层 查询系统、调用接口、执行安全动作。

5 校验层 JSON 校验、字段校验、引用校验、风控审核。

6 评测层 样例集、人工评分、线上反馈、成本监控。

隐私

不要随便把敏感数据塞进 prompt

用户隐私、密钥、合同、内部策略都要按公司数据规范处理。该脱敏就脱敏。

稳定性

给失败留出口

模型超时、格式错、工具失败、检索为空，都要有明确处理，不要让用户卡死。

可观测

记录足够多，但别记录不该记录的

模型版本、prompt 模板、token 用量、耗时、失败原因、人工修改率，这些能帮你迭代。

11 · 面试表达

回答要能从概念落到系统设计

下面这些问题很常见。短答用于快速建立判断，展开答案用于继续聊工程细节。

大语言模型 LLM 是什么？

短答：LLM 是用大规模文本和代码训练出来的语言模型，它把输入拆成 token，在上下文里计算关系，然后逐步生成后续 token。

展开：它的能力来自模型结构、训练数据、参数规模和后续指令对齐。它擅长文本理解、生成、总结、改写、代码辅助，但不等于数据库或搜索引擎。需要准确事实时，最好接 RAG、工具调用或业务接口。

LLM 为什么会出现幻觉？

因为模型的生成目标是产出在上下文中高概率的 token，而不是逐条查证事实。上下文缺失、检索资料错误、问题本身带误导，都会让它生成看似合理但不真实的内容。

工程上可以用知识库检索、工具调用、引用来源、结构化校验、人工审核和评测集来降低风险，但不能假设模型永远正确。

RAG 和微调有什么区别？

RAG 是在推理时查资料，把相关内容放进上下文，让模型基于资料回答。它适合变化快的知识，比如企业文档、接口说明、制度和历史需求。

微调是用样本调整模型行为，更适合固定格式、特定语气或重复任务。它不是实时知识同步机制。如果公司字段每天都变，先做 RAG 或工具查询更稳。

Prompt 工程到底在做什么？

Prompt 工程是在运行时给模型组织上下文。对程序员来说，它像接口设计：告诉模型角色、任务、输入、边界、输出格式和失败处理。

好的 Prompt 不是越长越好，而是信息足够、结构清楚、约束明确，并且能配合后续程序校验。

如果让你设计一个 LLM 企业应用，你会关注什么？

我会先确定任务是否适合 LLM，再设计上下文来源、输出格式和校验方式。如果答案依赖企业知识，就接 RAG；如果要查实时数据或执行动作，就走工具调用；如果输出要入库，就做结构化 schema 校验。

上线前准备评测样例，记录模型版本、prompt 模板、token 用量、耗时和人工修改率。这样问题出现时能定位，不会只靠感觉判断效果。

12 · 练习和速查

把 LLM 当成工程组件来复盘

学完以后，不要只背定义。用下面几个小题练习判断：什么该交给模型，什么该由系统保证。

练习 A：判断该用什么方案

根据最新订单状态回答客服问题 需要工具调用或业务接口查询，不能只靠模型记忆。

根据公司制度回答报销规则 适合 RAG，把制度文档检索出来再回答。

把固定格式的客服回复改成公司语气 可以先用 Prompt 模板和样例，需求稳定后再考虑微调。

审批一笔高风险付款 模型可以辅助分析，但最终动作要走规则、权限和人工审批。

练习 B：用一句话说清楚

解释“LLM 不是数据库”。
解释 token 和上下文窗口的关系。
解释为什么 RAG 能减少但不能完全消除幻觉。
解释为什么企业系统不能让模型直接改生产数据。
解释 Prompt 为什么更像接口协议，而不是魔法咒语。

速查表

概念	一句话	工程问题
LLM	根据上下文逐步生成 token 的大型语言模型。	任务是否适合生成式模型？
Token	模型处理文本的片段单位。	上下文是否超限，输出空间是否足够？
Embedding	把文本映射成向量，方便计算语义相似度。	知识库切片和检索策略是否可靠？
Transformer	通过注意力机制计算 token 关系的模型结构。	长上下文、延迟和成本是否可接受？
RAG	推理时检索资料，让模型基于资料回答。	资料来源、引用和召回质量怎么评估？
Tool Calling	让模型选择工具和参数，由系统执行真实查询或动作。	权限、审计、幂等和回滚怎么做？
评测	用固定样例和标准判断模型应用是否变好。	有没有覆盖高频、边界和失败场景？