AI 与大模型应用精华
从模型原理到工程落地，大模型应用开发的核心技术路线和工程要点。
一、AI 工程的核心认知
AI 工程不是从数据开始，而是从产品需求开始。Chip Huyen 把 AI 工程分成三层：应用开发层（需求→选模型→提示工程→RAG/Agent）、模型开发层（微调→数据集工程→评估）、基础设施层（GPU集群→推理优化）。大多数工程师只需要关注前两层。
一个关键判断：不是所有问题都需要 AI。 如果规则系统或简单的 if-else 就能搞定，硬上 LLM 反而增加复杂度和成本。
模型生命周期
阶段 1：预训练（大规模无标签文本，TB 级别）
→ 产出：基础模型（会说话，但不会听话）
阶段 2：监督微调 / 指令微调（指令-回答对，数万到数十万条）
→ 产出：对话模型（能回答问题、执行任务）
阶段 3：对齐（RLHF / DPO，人类偏好反馈）
→ 产出：产品级模型（输出有用、诚实、无害）
GPT vs BERT 两条路线
都来自同一个 Transformer 架构，但走了完全不同的路：GPT 只用解码器（Decoder-only），做"猜下一个词"的自回归生成；BERT 只用编码器（Encoder-only），做"完形填空"的理解任务。ChatGPT 属于 GPT 这条线，本质上是一个文本生成器。
二、Transformer 核心机制
理解大模型最好的方式不是调 API，而是从分词器开始理解内部结构。
注意力机制
本质是加权求和：处理一个词时，模型"看"序列中所有其他词，给每个词打相关性分数。在"把桌上的苹果吃了，因为它很甜"中，"它"会高度关注"苹果"而不是"桌子"。多头注意力是让多组 Q/K/V 并行计算，捕获不同类型的关联。
因果掩码
GPT 的关键设计：用三角矩阵把未来位置遮住，确保模型只能看到当前位置及之前的内容。训练时不偷看未来，推理时本就没有未来。
BPE 分词
字节对编码通过合并高频字符对构建子词词表，能解析任何单词而不需要 <unk> 标记。词表大小通常 3-5 万，是模型输入端的基础设施。
残差连接 + 层归一化
Transformer Block 的标准结构：LayerNorm → 因果注意力 → 残差连接 → LayerNorm → FFN（GELU 激活）→ 残差连接。残差连接防止网络太深时梯度消失，层归一化稳定训练过程。
三、提示工程：不是玄学是工程
核心技巧
- Few-shot prompting：在 prompt 里给几个输入-输出示例
- Chain-of-Thought：让模型"一步一步想"，特别适合数学和逻辑推理
- 角色设定：告诉模型"你是一个资深 XX 工程师"，输出质量明显不同
- 输出格式控制：要求 JSON/Markdown 格式，方便后续处理
关键认知：prompt 不是写一次就完事的，需要持续迭代、A/B 测试、根据用户反馈调整。好的 prompt 和好的代码一样，需要维护。
上下文学习（ICL）
模型不需要重新训练，通过 prompt 里的示例就能理解你要什么。这是提示工程的底层原理——在不改变参数的情况下，通过上下文引导模型行为。
四、RAG：让模型从"我知道什么"变成"我能查到什么"
检索增强生成是目前 LLM 应用中最实用的架构。核心流程：用户提问 → 从外部知识库检索相关片段 → 把检索结果塞进 prompt → LLM 基于事实生成回答。
RAG 调优参数
| 参数 | 影响 | 推荐值 | |------|------|--------| | 分块大小（chunk_size） | 太大噪声多，太小碎片化 | 500-1000 tokens | | 重叠长度（overlap） | 保持跨块语义连续 | chunk_size 的 10-20% | | Top-K | 检索返回文档数 | 3-5 篇 | | 检索策略 | 纯向量 vs 混合检索 | 简单用向量，复杂加 BM25 |
RAG 的局限
检索质量直接影响输出质量。如果文档本身有错，模型也会跟着错。生产环境需要 Reranker 提升检索精度，以及 query rewriting 优化用户查询。
五、Agent：从"只会聊天"到"能干活"
Agent 让 LLM 具备自主决策能力。ReAct 模式（Reason + Act）是核心：模型先推理需要什么工具，再执行，根据结果继续推理——这个循环是 Agent 智能行为的来源。
LangChain 是目前最主流的 Agent 开发框架。核心组件包括：Model I/O（Prompt Template + Chat Model + Output Parser）、Retrieval（Document Loader + Text Splitter + Embedding + Vector Store）、Memory（会话记忆）、Agent + Tools（自主决策调用工具）。LCEL（LangChain Expression Language）用管道操作符把组件像流水线一样串联。
六、微调：Prompt 搞不定的才微调
决策框架很清晰：如果 prompt engineering 和 RAG 已经能解决问题，就不要微调。只在以下情况考虑：
- 需要模型学会特定输出格式或风格
- 领域知识太多，塞不进 prompt 上下文窗口
- 需要大幅降低推理成本（小模型+微调 vs 大模型+长 prompt）
LoRA 是首选方案：在注意力层插入低秩矩阵，训练参数量降到全量微调的 1% 以下，同时保持接近全量微调的效果。DPO 作为 RLHF 的替代方案更简单稳定——不需要训练奖励模型，直接用人类偏好数据对优化。
注意灾难性遗忘：微调后模型在新任务上变好，但旧任务能力可能下降。务必检测微调前后在保留任务上的表现。
七、评估：没有度量就没有改进
评估指标选择
| 任务类型 | 推荐指标 | |---------|---------| | 分类/选择题 | Exact Match / 准确率 | | 翻译 | BLEU / COMET | | 摘要 | ROUGE / BERTScore | | 开放问答 | LLM-as-a-judge | | 总体质量 | 人工评估 + 分数分布 |
关键提醒：不要只看平均分，要看分数分布。 两个模型平均分一样，但一个稳定、一个方差大，在生产环境表现会差很多。
八、推理优化：让模型跑得快花得少
| 技术 | 效果 | |------|------| | 量化（FP16→INT4） | 模型大小减少 75%，速度提升 2-3x，质量下降 1-2% | | KV Cache | 缓存注意力中间结果，避免重复计算 | | 投机解码 | 小模型生成草稿、大模型验证，兼顾速度和质量 | | 批处理 | 多请求合并处理，提高 GPU 利用率 |
量化到 INT4 后的 trade-off 对大多数应用完全值得。
九、系统架构：不只是模型+prompt
生产级 AI 应用需要：模型路由（简单请求走小模型，复杂请求走大模型）、语义缓存（相似问题直接返回缓存结果）、降级策略（模型服务出问题时自动切备用方案）、用户反馈闭环（收集点赞/踩，转化为下次迭代的输入）。
AI 应用的竞争力不在于用了多大的模型，而在于用户体验和工程系统的可靠性。
十、Harness Engineering：AI 编程时代的方法论
当 AI 能写代码之后，人的核心能力变成了给 AI 造缰绳。公式：Agent = Model + Harness。模型决定上限，Harness 决定底线。
Harness 五组件
- 指令：告诉 AI 做什么
- 约束：告诉 AI 不能做什么，必须机械化执行
- 反馈：让 AI 知道做对了还是做错了
- 记忆：让 AI 记住之前发生了什么
- 编排：让多个 AI 协同工作
核心原则
少即是多。 AGENTS.md 写成千页手册反而让 Agent 更蠢。每一条规则都应该对应一个真实发生过的失败案例。没有案例支撑的规则就是噪音。上下文利用率控制在 40% 以内，超过就触发压缩或 context reset。
熵管理。 AI 生成代码的"腐烂速度"远快于人类写的代码。生成速度和清理速度必须匹配，否则技术债会快速积累到不可控。
写在 Slack 里的知识对 Agent 来说等于不存在。 所有团队知识都必须作为版本控制的制品放在仓库中。
来源书籍：《AI工程大模型应用开发实战》奇普萱、《大模型技术30讲》塞巴斯蒂安·拉施卡、《LangChain大模型开发实践》姜春茂、《从零构建大模型》塞巴斯蒂安·拉施卡、《Harness Engineering橙皮书》花叔