全景图：LLM 从原理到落地的系统分解

把大语言模型（LLM）当成“一个会说话的模型”很容易把项目带偏：你会把注意力集中在提示词、输出效果，却忽略了其背后是一套端到端的工程系统——从模型目标函数到数据治理，从训练工艺到推理成本，从应用编排到评测闭环，再到安全与合规。真正能稳定上线、可持续迭代的 LLM 产品，往往不是“某个模型很强”，而是“整个系统各环节可控、可测、可回滚”。

下面用一张全景图把核心链路先立起来：模型决定能力上限，数据决定分布与边界，训练决定可用性与对齐程度，推理决定延迟与成本，应用决定价值交付形态，评测决定迭代方向，安全决定能否长期运行。

```mermaid flowchart LR A[模型\n架构/目标函数] --> B[数据\n采集/清洗/标注/治理] B --> C[训练\n预训练/后训练/对齐] C --> D[推理\n服务化/加速/成本] D --> E[应用\nRAG/工具/代理] E --> F[评测\n离线/在线/A-B] F --> B E --> G[安全\n内容/隐私/合规] G --> E ```

模型：从架构到目标函数，理解“它为什么会说话”

Transformer 是“可并行的序列建模器”

主流 LLM 基于 Transformer 解码器架构：自注意力（Self-Attention）把每个 token 与上下文做相关性匹配，前馈网络（FFN）提供非线性表达，残差与归一化保证深层训练稳定。模型参数规模（B）、训练 token 数（T）、计算量（FLOPs）共同决定能力上限，并遵循经验性的 scaling law：在合理的优化与数据条件下，增加计算通常会带来可预测的损失下降，但边际收益递减。

目标函数：下一词预测是“统一接口”

绝大多数通用 LLM 的预训练目标是最小化负对数似然（NLL）：

$$ \mathcal{L}(\theta)= -\sum_{t=1}^{n}\log p_\theta(x_t \mid x_{<t}) $$

这看似简单，却带来两个工程上的关键结论：

1. 模型学到的是“条件分布”：输出不是事实，而是“在当前上下文下最可能的续写”。因此你必须用检索、工具、约束解码等手段，把上下文变成你希望它“条件化”的那部分世界。 2. tokenization 决定表达粒度与成本：同样一句话，不同分词器 token 数差异会直接影响推理成本与上下文长度占用。对中文尤其要注意：分词策略会影响专有名词、代码片段、混合语料的表示效率。

> 侧边栏｜工程提示 > 选型时别只看“榜单分数”。至少要问三件事：最大上下文长度是多少？输出质量在你领域数据上是否稳定？推理吞吐（tokens/s）在你的硬件预算上能否达标？

数据：能力的“地基”，也是风险的“入口”

数据生命周期：采集—清洗—标注—治理

LLM 项目里“数据”不是一个文件夹，而是一套可审计流程。

• **采集（Collection）**：网页、书籍、代码仓库、业务文档、对话日志、工单、知识库等。企业场景更常见的是“内部文档 + 业务系统字段 + 历史问答”。
• **清洗（Cleaning）**：去重（近重复/模版化）、语言检测、脏词与隐私字段脱敏、乱码与表格修复、文档结构化（标题层级/段落/表格/图片 OCR）。
• **标注（Labeling）**：SFT 指令数据、偏好对（preference pairs）、安全红队样本、工具调用轨迹（tool traces）。
• **治理（Governance）**：数据分级（公开/内部/敏感）、访问控制、可追溯血缘、删除权（Right to be forgotten）、训练/评测集隔离。

两个常见“坑”

1. 评测集污染：把线上高频问题直接丢回训练集，短期指标会上升，但你失去了对真实泛化能力的判断。解决：建立固定的“金集”（golden set）与“时间切分”的验证策略。 2. 文档结构丢失：很多企业知识在 Word/PDF/网页里，标题、列表、表格关系就是语义。纯文本抽取会让检索质量大幅下降。解决：在入库时保留层级结构与定位信息（如 section_id、page、anchor）。

训练：预训练、后训练与对齐的分工

预训练：通识能力与语言建模

预训练负责“会说话、会推理的底座”。对大多数团队而言自建预训练成本极高（数据、算力、工程），更常见做法是选一个基础模型，然后做两类后续训练：

• **Continued Pretraining（领域继续预训练）**：用大量领域无标注文本继续做 NLL 训练，让模型吸收术语、写作风格、领域知识分布（如金融、法律、医疗、制造）。
• **Instruction Tuning / SFT（监督微调）**：用指令-回答对，把模型从“会续写”变成“会按格式办事”。

对齐：把“能说”变成“可用、可控”

对齐通常解决三类问题：遵循指令、减少幻觉/有害输出、在多种回答之间选择更符合偏好的版本。

常见路径：

1. RLHF（PPO + Reward Model）：训练奖励模型（RM）评价回答好坏，再用强化学习优化策略模型。优势是可显式优化偏好；代价是训练复杂、稳定性要求高。 2. DPO（Direct Preference Optimization）：直接用偏好对优化策略，工程复杂度更低、稳定性更好，近年在很多场景替代 PPO 成为主流对齐方式。 3. RLAIF（AI Feedback）：用强模型/规则生成偏好与批注，降低人工标注成本，但要警惕“模型偏见放大”。

> 侧边栏｜实践提示 > 企业落地里，“对齐”不只是价值观安全，还包括：固定输出结构（JSON/表格）、拒答策略、工具调用规范、引用来源格式。这些往往比抽象的“更有帮助”更能决定上线质量。

推理：服务化、加速与成本模型

推理性能三要素：延迟、吞吐、成本

在生产环境里，推理系统要回答三个问题：

• **P99 延迟**：用户体验是否可接受（聊天一般希望首 token < 1s，整轮 < 5–15s，取决于场景）。
• **吞吐**：同样硬件上能服务多少并发（tokens/s、requests/s）。
• **成本**：每 1k token 成本、每次会话成本、峰值容量成本。

一个粗略的成本拆解可以写成：

$$ \text{Cost} \approx (\text{input tokens} + \text{output tokens}) \times \text{unit price} + \text{retrieval/tool overhead} $$

其中“retrieval/tool overhead”在代理型应用里可能比模型本身更贵（多次检索、重排、多轮工具调用）。

常见加速与工程策略

• **KV Cache**：解码阶段复用历史注意力键值，显著降低每步计算；但会吃显存，长上下文要注意缓存管理与分页。
• **Continuous Batching**：动态批处理把不同请求的解码步合并，提高 GPU 利用率，是在线服务的关键。
• **量化（INT8/INT4/FP8）**：降低显存与带宽压力，换来吞吐提升；需评估对你领域任务的质量影响。
• **推测解码（Speculative Decoding）**：用小模型草拟、多 token 验证，提高生成速度；适合长输出场景。
• **并行策略**：Tensor Parallel / Pipeline Parallel / Sequence Parallel；在多卡环境下权衡通信开销与吞吐。

应用：四种典型产品形态与技术栈映射

下面把常见 LLM 产品按“交付形态”分类，并映射到系统组件。很多团队在这里踩坑的原因是：用聊天产品的思路去做 Copilot，或者用 RAG 的架构去硬套工作流代理，导致效果与成本不可控。

| 产品形态 | 典型目标 | 关键组件 | 主要风险/难点 | |---|---|---|---| | 聊天助手（Chat） | 通用问答、写作、翻译 | 提示模板、对话记忆、内容安全 | 幻觉、敏感输出、长对话漂移 | | 搜索增强（RAG Search） | 基于资料的可追溯回答 | 文档解析、向量检索、重排、引用 | 召回不足、注入攻击、引用不准 | | Copilot（编码/办公） | 在工作流中补全与建议 | 上下文采集（IDE/表格）、结构化输出、权限 | 上下文质量、权限隔离、低延迟 | | 工作流代理（Agentic Workflow） | 多步骤执行任务 | 规划器、工具调用、状态机、回滚 | 可控性、成本爆炸、失败处理 |

RAG：把“事实”外置，把“推理”内置

RAG（Retrieval-Augmented Generation）不是“加个向量库”，而是一条可优化的链路：解析 → 分块 → 向量化 → 召回 → 重排 → 生成 → 引用校验。

```mermaid flowchart TD A[文档入库] --> B[结构解析\nHTML/PDF/OCR] B --> C[分块策略\n按标题/语义/窗口] C --> D[Embedding 向量化] D --> E[向量检索\nTopK 召回] E --> F[重排 Rerank\nCross-Encoder] F --> G[上下文组装\n去重/压缩/引用] G --> H[LLM 生成\n带引用回答] H --> I[引用与一致性检查] ```

一个最小可用的 RAG 编排（伪代码）通常长这样：

```python def answer(question: str) -> str: q_vec = embed(question) chunks = vector_db.search(q_vec, top_k=30) chunks = rerank(question, chunks)[:6] context = build_context(chunks, with_citations=True) prompt = f"""你是企业知识助手。仅基于资料回答，必须给出引用。 [资料] {context} [问题] {question} """ return llm.generate(prompt, temperature=0.2) ```

关键不在代码，而在四个“可调旋钮”： 1) 分块是否保留结构；2) 召回是否覆盖（TopK/混合检索）；3) 重排是否足够强；4) 上下文是否被压缩到“模型读得进去”。

工具与代理：把不确定性关进“笼子”

当任务需要查数据库、写工单、发邮件、跑脚本时，LLM 应该“提出操作意图”，由工具来执行；同时用结构化输出与状态机把行为约束住。

```plantuml @startuml actor User participant "App API" as API participant "Retriever" as R participant "LLM" as M participant "Tool: TicketSystem" as T

User -> API: 提交问题/任务 API -> R: 检索相关资料 R --> API: 文档片段+引用 API -> M: 带上下文提问\n(约束输出JSON) M --> API: {"action":"create_ticket",...} API -> T: 创建工单(真实执行) T --> API: ticket_id API -> M: 返回执行结果上下文 M --> User: 总结+引用+工单号 @enduml ```

> 侧边栏｜实践提示 > 代理不是“让模型自由发挥”。上线系统里更常用的是“半代理”：规划由模型做，但执行必须经过可验证的 schema、权限校验、预算控制（token/工具次数）、以及失败可回滚的状态机。

评测：离线与在线构成“可迭代的闭环”

离线评测：把主观变成可重复

离线评测的目标不是“给模型打分”，而是让你能在每次改动（prompt、检索、重排、模型版本）后回答：质量是否显著变好，代价是什么。

建议至少包含四类指标：

• **任务正确性**：基于金集的准确率/通过率（QA、分类、抽取、生成格式校验）。
• **检索质量**：Recall@K、MRR、nDCG；以及“引用命中率”（回答引用是否真的支持结论）。
• **鲁棒性**：对提示注入、无资料问题、对抗样本的拒答与安全表现。
• **成本与延迟**：平均 token、P95/P99 延迟、工具调用次数。

在工程上，可以把评测做成“可运行的回归套件”：

```python def eval_case(case): answer = system.answer(case.question) assert json_schema_ok(answer) if case.expect_json else True score = llm_judge(case, answer) # 或人工标注 return score

scores = [eval_case(c) for c in golden_set] report(scores, latency_metrics=True, cost_metrics=True) ```

[^1]: “LLM-as-a-judge”在排序对比（A vs B）上通常比绝对打分更可靠，但必须做偏差校验（对长度、格式、措辞的偏好）。

在线评测：A/B 与观测体系

一旦上线，离线分数只能作为方向参考，最终要看在线指标：

• 任务完成率（是否解决问题/是否提交成功）
• 用户满意度（显式评分 + 隐式行为，如追问率、回退人工率）
• 风险指标（安全拦截率、敏感信息触发率）
• 业务指标（工单减少量、搜索点击提升、处理时长缩短）

A/B 的关键是控制变量：只变一个因素（模型或检索或重排），并保证样本量与实验周期足够覆盖周期性波动（工作日/周末、月结等）。

安全：内容、隐私、合规不是“最后加的开关”

内容安全：从“过滤”到“分层防护”

• **输入侧**：注入检测、敏感指令识别、越权意图识别（例如“导出所有客户数据”）。
• **生成侧**：安全分类器（policy model）、规则与黑名单、输出结构校验、引用强制（RAG 场景）。
• **系统侧**：最小权限的工具访问、审计日志、速率限制、预算控制。

隐私与合规：三条红线

1. 数据最小化：只收集完成任务所需的最少字段；能在客户端处理的不要上送。 2. 可追溯与可删除：训练/索引/缓存中出现的个人信息要能定位与清除。 3. 跨境与第三方风险：如果使用外部模型 API，需要明确数据出境、存储、二次训练条款与日志保留策略。

> 引用提示 > 企业内部常见的“合规误区”是只关注输出是否合规，却忽略了检索与日志本身就是数据处理链路的一部分：向量库、缓存、观测平台都可能成为敏感数据落点。

从 0 到 1：上线“内部知识助手”的里程碑计划与交付物

下面给出一个偏工程落地的计划，假设目标是：面向内部员工提供基于企业文档的问答与引用能力，支持权限隔离（按部门/项目），并可迭代评测。

里程碑 M0：需求与边界（第 1 周）

• **目标定义**：覆盖哪些文档域（制度、产品、研发、客服）、哪些问题类型（解释/流程/查找）。
• **成功标准**：例如金集准确率 ≥ 75%，引用命中率 ≥ 90%，P95 延迟 ≤ 8s，回退人工率下降 20%。
• **交付物**：PRD、风险清单、数据分级与权限矩阵、评测金集大纲（题型分布）。

里程碑 M1：文档入库与检索 MVP（第 2–3 周）

• **解析与分块**：保留标题层级、表格与附件引用；定义 chunk schema（doc_id、section_path、acl、offset）。
• **索引**：向量索引 + 关键词倒排（混合检索），并做去重与增量更新。
• **交付物**：文档解析流水线、索引构建脚本、可回滚的版本化索引、基础检索评测报告（Recall@K）。

里程碑 M2：RAG 生成与引用（第 4 周）

• **上下文组装**：去重、压缩、按 section 聚合；强制引用格式（每条结论绑定来源）。
• **提示与格式**：明确“仅基于资料回答；无资料则拒答并说明缺口”。
• **交付物**：RAG 服务接口、引用规范、拒答策略、端到端离线评测 v1（正确性/引用/成本）。

里程碑 M3：权限与审计（第 5 周）

• **ACL 检索**：按用户/部门过滤可见 chunk；防止“越权引用”。
• **审计日志**：记录检索命中文档、提示摘要、输出摘要、工具调用（如有）。
• **交付物**：权限中间件、审计面板、越权测试用例与报告。

里程碑 M4：在线灰度与 A/B（第 6–7 周）

• **观测**：延迟、token、错误率、拒答率、满意度、追问率。
• **实验**：对比不同分块策略/重排模型/提示模板，建立决策规则。
• **交付物**：灰度发布方案、A/B 实验看板、回归评测自动化（CI 触发）。

里程碑 M5：安全加固与规模化（第 8 周）

• **注入防护**：对“忽略以上资料”“泄露系统提示”等模式做检测与缓解；RAG 上下文做安全清洗。
• **成本优化**：量化/缓存/批处理；将重排与生成拆层，热点问题做答案缓存与“检索缓存”。
• **交付物**：红队报告、成本报表（每问成本、峰值容量）、SLA 与应急预案（降级策略：无重排/短上下文/小模型）。

小结：用系统视角避免“只调提示词”的陷阱

把 LLM 落地当作系统工程，你会获得一套可复制的方法论：用目标函数理解模型边界，用数据治理保证输入分布可控，用后训练与对齐把能力变成产品行为，用推理工程把体验与成本拉回现实，用 RAG/工具/代理选择合适的交付形态，用离线+在线评测形成迭代闭环，最后用安全与合规把系统变成可长期运行的“生产能力”。接下来更深入的章节会分别展开这些模块：每一块都能独立优化，但只有把它们连成闭环，语言之龙才真正被驯服。