从数据到回答：LLM 全链路
一个 LLM 产品不是“调用一次模型 API”。它是一条从数据治理、训练、对齐、发布、请求编排到反馈闭环的链路。面试系统设计题最容易失分的地方，是把模型当成没有版本、没有成本、没有风险的黑盒。本页用一条可追踪的数据流把每一层串起来。
一、先看全景：两个闭环而不是一条直线
离线能力闭环：原始数据 -> 清洗/去重 -> Tokenizer -> 预训练 -> SFT/偏好优化 -> 离线评测 -> 发布
在线产品闭环：用户请求 -> 鉴权/策略 -> 上下文组装 -> 模型推理/工具 -> 输出校验 -> 观测/反馈 -> 评测集离线闭环决定模型“学会了什么”；在线闭环决定用户“实际得到什么”。二者用版本和数据相连：线上 bad case 进入标注、脱敏与回归集，新的训练或 prompt 版本再经过离线评估后发布。没有这个回路，模型质量一旦回退就只能靠用户投诉发现。
二、数据层：训练开始于删数据
2.1 数据不是越多越好
原始网页、代码、文档、问答、合成样本会包含重复、模板化内容、乱码、隐私、版权风险、低质量翻译和互相矛盾的事实。大模型训练具有放大效应：高频的脏模式会被反复学习，低质量数据既浪费 token 预算，也会降低指令跟随与事实可靠性。
一条典型数据管线包含：
- 采集与许可记录：来源、时间、许可范围、地域与删除请求要可追溯。
- 解析与规范化：统一编码、抽取正文、保留语言与文档类型等 metadata。
- 质量过滤：长度、字符比例、语言识别、重复句、广告模板、困惑度或质量分类器。
- 去重：精确哈希去重处理完全相同文本；MinHash/SimHash 或语义去重处理近重复。
- 安全与隐私处理：检测 PII、密钥、账号、受限内容；不能只依赖正则，还要有复核和删除链路。
- 混合与切分：为语言、代码、数学、长文档设置配比，并严格隔离训练、验证、测试集。
2.2 去重为什么是能力问题
训练集大量重复会让模型记住某些样本而非泛化，验证集若与训练集污染，离线分数会虚高。对 benchmark 的污染尤其危险：模型看似“会做题”，实际可能记住了题目或答案。面试中应区分三个概念：训练去重降低样本冗余，评测去污染保证结论可信，在线知识库去重降低检索结果同质化；三者工具相似，但风险目标不同。
2.3 数据混合是一个控制旋钮
设语料集合为 D_i，采样概率为 p_i，训练并非简单地按原始数据量混合。小而重要的数据域常被上采样，大而低质量的数据域可能被下采样。若代码比重过低，代码能力不足；若合成指令数据过度重复，模型会学到固定套话。混合策略需要版本化，并对每类数据贡献做消融评估。
三、Tokenizer：数据与模型权重的契约
文本必须先映射为 token id。Tokenizer 的词表、特殊 token、规范化规则与 chat template 共同定义了模型看到的输入空间。训练集里新增了 <tool_call>、<image> 或角色标记，却没有正确扩词或初始化 embedding，会导致这些符号无法被稳定学习。
关键工程约束：
- tokenizer 版本必须与 checkpoint 绑定；替换 tokenizer 意味着 embedding 和 LM head 的 id 语义不再对齐。
- 长度统计应以 token 计，不能只看字符数；中英文、代码、JSON 的压缩率差异明显。
- 训练、评测和线上服务要使用同一 chat template，否则模型实际接收到的是不同任务格式。
- 特殊 token 应有明确的停止、转义和日志策略，避免用户文本伪造控制标记。
详见 Tokenizer 与分词 和 Mask 与 Padding。
四、预训练：让模型学会世界的统计结构
自回归预训练的最常见损失是：
$$\mathcal{L}=-\frac{1}{N}\sum_{t=1}^{N}\log p_\theta(x_t\mid x_{<t})$$
每个位置预测下一个真实 token。teacher forcing 允许训练阶段并行计算所有位置，但必须用 causal mask 防止未来 token 泄漏。优化器根据 loss 的梯度更新参数；训练数十亿到万亿 token 后，权重中形成语言、代码、世界知识和模式识别能力的压缩表示。
4.1 训练系统关心什么
- 数据并行：不同 GPU 处理不同 batch，聚合梯度；通信瓶颈主要是梯度同步。
- 张量并行：把大矩阵切到多卡，解决单卡放不下模型；层内通信频繁。
- 流水线并行：把层分段放到不同设备；需处理 micro-batch 调度与 pipeline bubble。
- 混合精度：前向/反向使用低精度加速，关键累积用更高精度保持稳定。
- checkpoint：保存模型、优化器、学习率调度、数据位置和随机状态，支持恢复与可复现。
训练 loss 降低并不等于产品质量提升。loss 是 token 预测的平均指标，无法完整覆盖工具调用、拒答、长文档事实性或用户偏好；它是必要信号，不是发布标准。
五、后训练：把“会续写”变成“可被使用”
5.1 SFT
监督微调让模型观察高质量的多轮消息、答案、结构化输出和工具轨迹。训练时通常只对 assistant token 计算 loss，用户输入和 system 指令被 mask 掉。需要注意：模板错一个角色分隔符、EOS 或 loss mask，模型就会学习错误的轮次边界。
5.2 偏好优化与安全对齐
偏好数据形式通常是同一 prompt 下的 chosen/rejected 回答。RLHF、DPO、IPO、KTO 等方法在实现细节上不同，但共同目标是让模型更偏向有帮助、诚实、安全且风格合适的响应。好的回答不能只说“DPO 不用训练奖励模型”；还要补充它依赖偏好对质量、参考策略和超参数，仍需防范 reward hacking、过度拒答与能力回退。
5.3 工具与结构化输出训练
如果产品需要调用订单系统、数据库或浏览器，训练样本必须覆盖：何时调用、参数如何填、调用失败如何解释、何时不该调用、如何引用结果。只训练“输出一段 JSON”不等于具备可靠工具能力；实际还需要 schema 校验、权限检查、幂等键和审计日志。
六、评测：把“感觉不错”换成证据
评测至少分四层：
| 层次 | 问题 | 例子 |
|---|---|---|
| 基准能力 | 模型总体能力如何 | 数学、代码、知识 benchmark |
| 任务能力 | 目标业务能否完成 | 意图识别、字段抽取、工单总结 |
| 安全可靠性 | 会不会越权或编造 | 注入、PII、拒答、事实引用 |
| 系统指标 | 能否稳定经济地服务 | P50/P95、TTFT、错误率、单请求成本 |
发布前的比较应该锁定模型版本、prompt 版本、工具版本、检索索引、采样参数和测试集版本。若只改了 prompt 却拿不同流量和不同温度比较，A/B 结论不可解释。线上应保留可脱敏的 trace：请求路由、上下文 token 数、模型、工具调用、延迟、输出校验结果和用户反馈。
七、在线请求的逐步拆解
以企业知识助手为例，一次请求不应直接从“用户问题”跳到“模型回答”：
1. 身份与租户校验
2. 内容安全、限流、请求大小检查
3. 意图路由：普通对话 / RAG / 工具任务 / 人工转接
4. 检索或读取可信业务上下文，并按 ACL 过滤
5. 组装 system、history、检索证据、工具结果和输出契约
6. 选择模型、区域、超时和采样配置
7. 流式生成；若需要则执行受策略约束的工具循环
8. 校验 JSON/schema、敏感输出、引用覆盖与业务规则
9. 返回答案与可解释证据，记录 trace 和成本7.1 上下文预算是在线系统的核心
上下文窗口不是无限背包。请求会竞争有限 token 预算：system 指令、聊天历史、检索 chunk、工具结果和预留输出长度。可用公式表达：
$$T_{input}+T_{reserved\ output}\leq T_{context\ window}$$
超过窗口时不能盲目截断末尾，因为可能删掉安全策略或最近一轮用户目标。常见策略是固定 system 预算、保留最近若干轮、对历史摘要、对检索结果 rerank 后按证据价值填充，并给输出保留硬预算。每一种策略都要在长会话和关键任务上评测。
7.2 模型路由不是“永远用最大模型”
路由器可以根据语言、任务风险、上下文长度、延迟 SLO、结构化输出需求与成本预算选择模型。低风险的分类、摘要或提取由小模型承担；复杂推理或关键决策升级到强模型；高风险操作要求人工确认。路由本身也要可观测，避免“模型省钱了但失败率升了”被平均指标掩盖。
八、失败处理与降级
在线系统必须假设模型和工具会失败：超时、限流、空输出、schema 不合法、工具参数缺失、检索无证据、内容策略命中、外部系统返回 5xx。合理的降级不是把错误偷偷改写成看似确定的回答，而是区分：
- 可重试：网络瞬断、幂等读取、瞬时限流；使用指数退避和总 deadline。
- 可切换：兼容模型或区域；需验证能力与合规边界一致。
- 需要澄清：缺少关键参数或证据不足；向用户提出最小必要问题。
- 需要拒绝或转人工：高风险操作、权限不足、策略命中或不可验证事实。
对写操作尤其要设计幂等键、审批、补偿和审计。模型给出“调用成功”的自然语言不构成事实，必须以工具返回的结构化结果为准。
九、版本、观测与反馈闭环
一份可复现的线上 trace 至少记录：
{
"request_id": "...",
"policy_version": "2026-07-20",
"prompt_version": "support-rag-v18",
"model": "provider/model@revision",
"temperature": 0.2,
"input_tokens": 1840,
"retrieval_index": "kb-2026-07-19",
"tool_calls": [{"name": "search_ticket", "status": "ok"}],
"latency_ms": 2310,
"validation": {"schema": "pass", "citation": "pass"}
}日志应脱敏、分级、设保留期，并满足删除与访问控制要求。不能为了调试把用户原始隐私、密钥或完整敏感文档永久写入 trace。Bad case 要按任务、用户群、语言、文档类型和失败模式切片；否则平均分上升可能掩盖一个重要群体明显退化。
十、面试高频问答
Q1：LLM 项目怎样形成闭环？
**答法：**离线端将合法、可追溯的数据经过清洗、训练、对齐和评估形成可发布模型；在线端做鉴权、上下文编排、模型/工具调用、输出校验和观测。线上 bad case 经脱敏标注进入固定回归集，驱动下一轮 prompt、检索或训练更新。关键是所有版本可关联，才能知道一次回退来自哪个环节。
Q2：为什么要同时做离线评测和线上监控？
**答法：**离线评测可控、可复现，适合比较版本并设置发布门禁；线上流量具有真实分布、真实延迟与真实用户行为，能发现测试集没有覆盖的漂移。两者不能互相替代：只看线上会让问题影响用户后才暴露，只看离线会遗漏集成和数据分布问题。
Q3：如何解释“模型回答错了”的排查顺序？
**答法：**先确认问题是否可回答以及证据是否存在；再看身份/ACL 与检索是否取回正确内容；检查上下文是否被截断、模板和工具结果是否注入正确；确认模型/采样/路由版本；最后看输出校验和展示层是否改变了原始答案。这样能把“模型幻觉”拆成可修复的链路故障。
Q4：如何控制 LLM 成本？
**答法：**成本由输入、输出、模型单价、缓存命中、重试和工具调用共同决定。先通过 token 观测找最大头，再做上下文压缩、检索精排、语义缓存、模型路由、输出长度约束和批量处理。不能只把所有请求切到小模型，因为必须同时看质量、人工兜底率和业务损失。
十一、白板回答模板
当面试官让你“设计一个企业 LLM 助手”，可按以下顺序组织：
- 明确目标、成功指标与不能做的高风险动作。
- 画身份/租户边界和可信数据源。
- 画请求编排：路由、RAG、工具、模型、输出校验。
- 说明 token/延迟/成本预算和降级路径。
- 给出离线评测、线上 trace、灰度和回滚方案。
- 说明 bad case 如何回流，而不是把系统停在一次性 demo。
本页的重点不是让每个人去训练底座模型，而是建立系统感：每个答案、每一次工具调用、每一次发布都应有数据来源、版本和可验证的边界。