直接回答：大语言模型（Large Language Model，LLM）是一类在大量序列数据上训练、根据已有上下文预测 Token 的模型。Token 可以是一个词、子词、字符或代码片段。现代 LLM 多采用 Transformer 或其变体；它能生成连贯文本、代码和结构化结果，但不是数据库、搜索引擎或“装进全部知识的巨大大脑”，流畅输出也不自动等于事实正确。
用户实际接触的聊天助手通常还包含系统指令、检索增强生成（RAG）、工具调用、安全策略、缓存、内容过滤和界面。底层模型能力与整个应用的结果必须分开评测。选择 LLM 时，不应只比参数量或排行榜，而要用自己的任务保留集比较准确性、来源忠实度、拒答、延迟、成本、数据边界和可回滚性。
大语言模型和聊天机器人有什么区别？
LLM 是模型层；聊天机器人或 AI 助手是产品与系统层。同一个底层模型换了系统提示、知识库、工具权限、采样参数或审核策略，表现可能明显不同。反过来，一次产品回答也不能证明底层模型“知道”某件事，更不能证明回答中的内容一定来自训练数据。
| 层级 | 负责什么 | 常见误解 |
|---|---|---|
| 基础模型 | 根据 Token 上下文计算后续 Token 概率 | 等同实时搜索或事实数据库 |
| 对齐后的助手模型 | 遵循指令、对话和安全偏好 | 对齐后就不会犯错 |
| RAG | 检索资料并放入本次上下文 | 接入知识库就保证忠实引用 |
| 工具与智能体 | 查询、计算或调用外部系统执行动作 | 会规划就可以自动获得高权限 |
| 产品层 | 身份、日志、限额、缓存、界面与审核 | 产品名等于固定模型版本 |
Token、参数和上下文窗口分别是什么？
Google Machine Learning Crash Course 的 LLM 模块把语言模型描述为估计 Token 或 Token 序列在更长序列中出现的概率。不同模型使用不同 tokenizer，同一句中文在不同模型中的 Token 数可能不同。因此 API 计费、上下文容量和输出上限要按目标模型实际分词器计算，不能用“中文字数”直接代替。
| 概念 | 准确含义 | 不代表什么 |
|---|---|---|
| Token | 模型处理序列的离散单位 | 固定等于一个汉字或单词 |
| 参数 | 训练得到、参与计算的数值权重 | 可逐条查询的知识记录 |
| 上下文窗口 | 一次推理可处理的 Token 范围 | 模型能同等关注窗口内每个细节 |
| 输出上限 | 一次调用允许生成的最大 Token 数 | 上下文窗口全部可用于输出 |
| Embedding | Token 或文本的向量表示 | 原文的无损压缩副本 |
Hugging Face tokenizer 文档说明了词级、字符级和子词分词的取舍。对中文、代码、表格、罕见名称和多语言混合文本，先用模型对应 tokenizer 试算，才能估计截断位置、延迟和费用。
LLM 怎样一步步生成文字？
以常见的自回归、decoder-only 文本生成模型为例，输入先被转为 Token ID，再叠加位置信息并经过多层 Transformer。模型为词表中的候选 Token 计算分数，经过 softmax 等处理形成概率分布；解码策略选出一个 Token，把它追加到上下文，再重复计算，直到遇到停止 Token、长度限制或应用设定的停止条件。Hugging Face 因果语言建模文档将其概括为：模型只能关注左侧 Token，并预测序列中的下一个 Token。
| 阶段 | 输入/输出 | 容易影响结果的因素 |
|---|---|---|
| 分词 | 文本 → Token ID | 词表、语言、空格、代码符号 |
| 上下文计算 | Token → 隐藏表示 | 位置、注意力、窗口和模型权重 |
| 概率计算 | 隐藏表示 → 候选分数 | 模型版本与数值精度 |
| 解码 | 概率分布 → 下一个 Token | temperature、top-p、约束 |
| 循环与停止 | 新上下文 → 最终文本 | 最大长度、停止串、工具流程 |
Transformer 和自注意力是什么？
《Attention Is All You Need》原始论文提出了基于注意力的 Transformer 架构。自注意力让序列中每个位置根据其他位置计算相关性，从而构建上下文表示；多头注意力可以在不同投影空间学习不同关系。Transformer 层还包含前馈网络、残差连接、归一化等组件，不能把整个模型简化成“只有注意力”。
| 架构 | 典型输入输出 | 常见任务 | 注意 |
|---|---|---|---|
| Encoder-only | 整段输入 → 表示/标签 | 分类、检索、抽取 | 不以长文本续写为主要目标 |
| Decoder-only | 左侧上下文 → 后续 Token | 对话、写作、代码生成 | 生成事实仍需外部验证 |
| Encoder-decoder | 输入序列 → 输出序列 | 翻译、摘要、转换 | 输入编码和输出生成分开 |
BERT 论文是 encoder-only 路线的经典示例；T5 论文系统研究了把多类任务统一为 text-to-text 的 encoder-decoder 路线；GPT-3 论文则展示了自回归模型在不更新权重时通过文本示例完成 zero-shot、one-shot 和 few-shot 任务的能力与局限。
LLM 是怎样训练和变成“助手”的？
“训练一个 LLM”不是单一步骤。预训练先让模型从大规模序列中学习统计规律；随后可进行监督式指令微调，让模型按任务与对话格式回答；再通过人类或 AI 偏好数据优化有用性和安全行为。企业还可能做领域继续预训练、微调、蒸馏或量化，但这些操作解决的问题不同。
| 阶段 | 主要目标 | 需要的数据 | 不能保证 |
|---|---|---|---|
| 预训练 | 学习语言、代码和数据中的模式 | 大规模清洗语料 | 按用户意图回答 |
| 指令微调 | 学习指令—回答格式与任务行为 | 高质量示范 | 所有事实正确 |
| 偏好对齐 | 优化有用、安全等偏好 | 比较、评分或反馈 | 消除偏见和越狱 |
| 领域适配 | 强化特定术语或行为 | 合法、代表性的领域数据 | 自动获得最新事实 |
| 量化/蒸馏 | 降低部署资源 | 校准集或教师输出 | 能力完全无损 |
InstructGPT 论文显示，更大模型并不会天然更会遵循用户意图；作者通过监督微调和人类反馈训练改善了偏好表现，但论文也明确保留模型仍会犯简单错误的限制。这说明参数规模、指令遵循、事实性和安全性必须分别测试。
Prompt、RAG、微调和工具调用怎样选？
先用 Prompt 和少量示例验证任务边界；如果缺的是可更新、可引用的私有资料，优先评估 RAG；如果缺的是稳定输出行为、领域语气或固定格式，且有代表性样本，再评估微调；如果任务需要精确计算、实时查询或改变外部状态，则使用受控工具。四种路线可以组合，但不应把任何一种包装成万能方案。
| 问题 | 优先路线 | 核心证据 | 主要风险 |
|---|---|---|---|
| 任务或格式没说清 | Prompt/示例 | 同一保留集输出稳定性 | 注入、脆弱提示 |
| 答案依赖最新/私有资料 | RAG | 召回率、来源忠实度、权限 | 错检索、越权、旧版本 |
| 行为长期不符合领域要求 | 微调/LoRA | 训练外测试集和回归 | 过拟合、遗忘、数据权利 |
| 需要计算或业务动作 | 工具调用 | 参数正确率与动作结果 | 过度权限、重复执行 |
RAG 原始论文把参数化记忆与可检索的非参数化记忆结合，以改善知识密集任务和来源问题；它并未证明任意知识库接入后都能可靠回答。检索切分、索引、召回、重排、上下文拼装和生成忠实度都要单独验收。站内的Few-shot Prompting 示例选择与评测指南及Zero-shot Prompting 模板与失效排查可用于先完成低成本基线。
LoRA 原始论文通过冻结预训练权重并注入可训练的低秩矩阵，减少特定适配任务的可训练参数；它不等于给模型实时更新事实，也不免除训练素材授权、隐私、过拟合和基础模型许可检查。需要实践路线时参见LoRA/QLoRA 训练与上线验收指南。
为什么 LLM 会出现幻觉或编造？
LLM 的训练目标和解码过程优化的是序列预测，不是对每个事实查询权威数据库。提示含糊、知识缺口、检索错误、上下文冲突、长文本遗漏、随机解码和应用拼装错误都可能生成看似自信但不准确的内容。NIST AI 600-1 生成式 AI 风险框架使用“confabulation”描述模型自信生成错误、虚假或相互矛盾内容的现象，并强调在高影响场景中监测其下游后果。
| 错误来源 | 表现 | 更有效的控制 |
|---|---|---|
| 问题定义 | 回答了错误任务 | 明确成功、边界和拒答 |
| 模型知识/能力 | 事实、计算或推理错误 | 检索、工具、专项模型、人工复核 |
| 检索层 | 引用无关或过期资料 | 权限过滤、版本、召回与重排评测 |
| 生成层 | 来源与结论不一致 | 原子主张核验、引用忠实度 |
| 产品层 | 截断、缓存或工具结果拼错 | 端到端日志、超时和错误回传 |
降低 temperature 可能减少随机性，但不能把错误知识变成正确事实。要求“不要编造”也不是可靠防线。对新闻、医疗、法律、金融、人员决策或会执行外部动作的场景，应把关键主张拆成可核验单位，要求一手来源、工具结果和人工批准，并把停止、复核与恢复写入AI 安全全生命周期门禁。
怎样选择合适的 LLM？
先写任务卡，再看模型卡。任务卡至少包含输入、期望输出、语言、最长上下文、数据敏感级别、延迟目标、峰值并发、成本上限、允许的错误、人工接管和部署限制。随后选 2 至 4 个候选模型在同一保留集上盲测，避免根据宣传样例或综合榜单直接采购。
| 选择维度 | 应测什么 | 不要用什么代替 |
|---|---|---|
| 任务质量 | 领域正确率、完整性、格式 | 通用榜单总分 |
| 中文与多语言 | 真实术语、方言、混合代码 | 英文样例 |
| 上下文 | 有效召回、长文定位、截断 | 标称窗口长度 |
| 运行 | P50/P95 延迟、并发、失败率 | 单次最快结果 |
| 成本 | 完整任务成功成本 | 每百万 Token 单价 |
| 数据与许可 | 日志、保留、区域、权重/API 条款 | “开源”或“企业级”标签 |
开放权重、自托管和官方 API 也不是简单的“免费与收费”区别。自托管带来更多环境和数据流控制，也把硬件、容量、补丁、模型来源、日志、安全、许可和事故响应交给团队；API 降低基础设施负担，但要核对数据保留、区域、限流、版本和退出路线。以具体开放权重模型为例，可参考Llama 3 版本、部署与许可指南，但不要把某一个家族的结论外推到所有 LLM。
长上下文、RAG 和微调怎样取舍？
把整份资料塞进长上下文，优点是原型简单、减少检索漏召回；缺点是输入 Token、延迟和成本增加，模型也可能忽略中间位置、混淆相似段落或被文档内的恶意指令影响。RAG 可以按查询选择少量片段、控制权限并保留来源，但多了切分、索引、召回、重排和版本治理。微调主要改变模型行为或任务适配，不应作为频繁更新事实的首选。
| 资料特征 | 优先尝试 | 必须验证 | 停止条件 |
|---|---|---|---|
| 单份、较短、每次都需全局比较 | 长上下文 | 不同位置召回、交叉引用、截断 | 成本或遗漏超过阈值 |
| 文档多、频繁更新、需要出处 | RAG | 权限、Recall@k、重排、忠实度 | 关键资料持续漏召回 |
| 固定规则可直接计算 | 数据库/搜索/规则工具 | 参数、结果、超时与错误处理 | 模型承担了确定性计算 |
| 稳定风格或领域行为不合格 | 微调/LoRA | 训练外样本、遗忘、偏差和权利 | 只记住样本或破坏通用能力 |
| 混合企业任务 | Prompt + RAG + 受控工具 | 端到端成功率与权限边界 | 系统复杂度超过业务收益 |
不要先决定技术再寻找问题。可以用逐级实验：先以一页明确 Prompt 建立基线；再加入少量人工挑选资料，确认事实缺口是否真的被外部上下文解决；随后自动化检索并单独评测召回；需要实时计算时才接工具；只有行为在大量保留样本上仍不稳定，且数据足以覆盖目标分布时，才进入微调。每增加一层，都记录它对质量、延迟、成本和安全的净变化。
长上下文也需要信息架构。给文档稳定标题、章节、日期、来源和唯一 ID；把问题、材料与输出格式分隔；要求结论指向具体段落；对冲突版本明确采用规则。若模型无法从给定材料回答，应允许它返回“证据不足”，而不是强迫生成完整答案。对于多轮对话，摘要不能被当作无损记忆，应保留关键事实、用户确认和工具结果的结构化状态。
LLM 的成本和延迟怎样算？
API 页面常列输入与输出 Token 单价，自托管常列显存或每秒 Token，但业务要比较的是“一个合格任务的总成本”。一次用户请求可能触发改写查询、Embedding、向量检索、重排、主模型生成、工具调用、事实复核和重试；失败输出虽未交付，也会消耗资源。把全部调用、存储、网络、人工审核和失败重试归集到同一个任务 ID，才知道方案是否真的便宜。
| 运行指标 | 定义 | 为什么单看平均值不够 |
|---|---|---|
| TTFT | 请求到首个 Token 的时间 | 决定聊天体感，但不代表完成速度 |
| 输出速度 | 稳定生成阶段的 Token/秒 | 长输出、并发和量化会改变 |
| 端到端延迟 | 检索、工具、模型、校验全部完成 | 隐藏了排队和外部 API 时间 |
| P95/P99 | 高分位请求耗时 | 比平均值更能暴露高峰失败 |
| 合格任务成本 | 总费用 ÷ 通过验收的任务数 | 包含失败、重试与人工复核 |
| 并发容量 | 阈值内可稳定处理的请求量 | 单用户测试不能证明生产容量 |
成本优化应在质量门禁之后进行。可先缩短无价值上下文、缓存稳定前缀和检索结果、限制最大输出、把分类或抽取交给足够小的模型，并为工具设置超时和重试上限。不要只为降低 Token 数删除必要证据，也不要让失败请求无限重试。自托管还要把 GPU 空闲率、模型加载时间、扩容、监控、工程值守、电力和硬件折旧纳入核算。
性能测试要模拟真实输入长度、输出长度、并发、中文比例、RAG 文档数和工具延迟，分别记录冷启动与稳定状态。设定超时后还要定义降级：可切换只读检索、较小模型、人工队列或明确失败；不能在主模型超时时悄悄换成未经评测的模型，并继续向用户声称结果等价。
采购或迁移前，团队应要求候选方案完成同一份可导出的测试记录：模型和端点名称、访问区域、计费单位、限流、数据保留、输入输出上限、工具支持、错误码、停服或版本升级通知机制。再用实际峰值流量压测，计算每日和月度预算区间。若供应商不能固定模型版本，应准备回归触发器和替代路线；若自托管模型的许可证、权重来源或依赖无法追溯，则不应仅凭本地可运行就进入生产。最终决策记录要写明接受了哪些剩余风险、由谁批准、何时复核。
面向用户的界面还应清楚标注能力边界、数据用途和人工渠道；在模型超时、证据不足或工具失败时给出真实状态，不用一段看似完整的生成文本掩盖系统错误，并保留用户撤回、申诉、反馈和纠错入口。
怎样建立可信的 LLM 评测？
评测从任务和影响开始，不从“选哪个 benchmark”开始。建立覆盖常规、边界、失败和对抗输入的保留集，保存期望结果、评分规则、来源、版本和人工判定依据。自动指标适合规模化回归，但开放式回答仍需人工或经过验证的判分器；用另一个 LLM 打分时，也要抽样校准偏差和位置效应。
| 指标层 | 示例指标 | 判分单位 |
|---|---|---|
| 任务 | 正确、完整、格式合格、拒答 | 每个业务样本 |
| 事实 | 主张正确率、来源充分性、忠实度 | 每个原子主张 |
| 检索 | Recall@k、权限命中、版本新鲜度 | 每个查询 |
| 工具 | 工具选择、参数、动作结果、幂等 | 每个调用 |
| 运行 | P95 延迟、错误率、成功任务成本 | 每次端到端请求 |
| 安全 | 注入成功、泄露、越权、人工接管 | 每个攻击/高风险场景 |
Stanford HELM强调在多场景、多指标下提高模型评测透明度。业务应用还必须补充自己的数据，因为公开 benchmark 可能与真实输入、语言、工具链和错误成本不同。评测记录应包含模型/端点、提示、检索版本、工具版本、参数、日期和代码提交，以便复现。
LLM 应用有哪些安全边界？
OWASP GenAI LLM 风险清单覆盖 Prompt Injection、敏感信息泄露、供应链、数据/模型投毒、不安全输出处理和过度代理权等问题。系统提示不能被当成密码保险箱；外部网页、邮件、文档和图片都可能携带间接指令；模型输出必须视为不可信输入，在进入 SQL、Shell、HTML、邮件或支付系统前做确定性校验。
| 风险 | 最低控制 | 高风险时再加 |
|---|---|---|
| 提示注入 | 数据与指令分层、内容来源标记 | 隔离检索、策略引擎、攻击回归 |
| 敏感信息 | 输入分类、脱敏、日志最小化 | 私有部署、DLP、区域与密钥隔离 |
| 工具越权 | 工具白名单、最小权限、参数校验 | 人工批准、沙箱、双人复核 |
| 不安全输出 | 转义、模式校验、禁止直接执行 | 静态分析、事务与回滚 |
| 供应链 | 模型/依赖来源、哈希和许可证 | 签名、隔离构建、漏洞响应 |
LLM 生产上线需要哪些门禁？
| 门禁 | 发布证据 | 停止/回滚条件 |
|---|---|---|
| 任务质量 | 保留集达到分场景阈值 | 关键错误或拒答不达标 |
| 事实与来源 | 关键主张可追溯且忠实 | 伪引用、来源冲突未处理 |
| 安全与权限 | 注入、泄露、越权测试通过 | 可执行未授权动作 |
| 运行与成本 | P95、失败率、峰值和预算通过 | 重试风暴、费用或延迟越界 |
| 治理 | 责任人、日志、版本和回滚包 | 无法定位版本或撤销影响 |
小流量上线后监控任务成功率、事实错误、拒答、人工接管、P95 延迟、Token、工具调用、异常费用和安全事件。版本记录不能只写“换了新模型”，而应保存模型/端点、提示、采样参数、知识库快照、检索配置、工具权限、代码版本和审批人。涉及多步工具与智能体时，可结合LangChain 组件选择与生产验收指南理解编排层，但仍要让权限和最终动作由确定性系统控制。
常见问题
LLM 是真正理解语言，还是只在预测下一个词？
“预测下一个 Token”描述训练与生成机制，但不能单独回答哲学意义上的理解。工程上更有用的做法是按任务测量：模型能否在未见样本上正确转换、推断、引用、拒答和使用工具，并明确哪些表现不稳定。
参数越多，模型一定越好吗？
不一定。参数只是影响能力、成本和容量的因素之一。训练数据、架构、训练计算、对齐、推理策略、量化和应用系统都会影响结果。较小模型在明确任务、低延迟或本地部署中可能更合适。
上下文窗口越长，模型就能记住整份文档吗？
不能这样推断。标称窗口只说明可接收的 Token 上限；有效利用还受位置、注意力、文档结构、提示、检索和任务影响。应测长文不同位置的召回、交叉引用和关键信息遗漏。
RAG 能消除幻觉吗？
不能。RAG 可以提供外部资料和出处，但仍可能召回错误、越权、使用旧版本，或生成与来源不一致的结论。必须分别测试检索质量、权限、来源充分性和回答忠实度。
普通用户怎样安全使用 LLM？
不要输入不该交给该服务的密码、身份、客户或商业机密；关键事实回到一手来源核对；代码在隔离环境测试；医疗、法律、财务和会改变真实系统的建议交由合格人员确认。把 LLM 当作可提高效率但需要验收的工具，而不是最终责任主体。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。旧稿中的“巨大知识库”、参数越大必然更强和过时模型名录已删除；新版依据 Transformer、BERT、T5、GPT-3、RAG、InstructGPT、LoRA 原始论文，以及 Google、Hugging Face、NIST、OWASP 和 Stanford 的公开资料，重建 Token、架构、训练、适配、评测、安全和上线门禁。本文不声称一次测评适用于所有模型版本；重要项目应记录访问日期、模型/端点和本地保留集结果。本站来源、更新与纠错原则见关于本站与编辑规范。
