AI 工程实战指南：从零开始构建 AI 应用
这是一本关于如何在现成 AI 大模型上构建真正可用产品的书。不讲如何训练模型，讲的是一个工程师在面对这些强大但复杂的工具时，怎么把它们变成能用、好用、安全的东西。
目录
- 入门：这个时代，我们在做什么
- 读懂模型：它为什么这么做
- 评估方法：怎么知道它做得好不好
- 系统化评估：从想法到流水线
- 提示工程：和模型"说话"的艺术
- [RAG 与智能体：给模型接上眼睛和手](#RAG 与智能体：给模型接上眼睛和手)
- 微调：改造模型本身
- 数据集工程：垃圾进，垃圾出
- 推理优化：让它跑得快一点、便宜一点
- 架构与用户反馈：把所有东西拼在一起
第一章
入门：这个时代，我们在做什么
规模改变了一切
2020 年之后，AI 这个词的含义发生了质变。变化的核心只有一个字：大。
ChatGPT、Gemini、Midjourney 背后的模型大到什么程度？大到已经消耗了全球相当一部分电力，大到几乎要把公开互联网上能找到的文字都用光了。
但"大"带来的不只是成本问题，更重要的是两个结果：
第一，模型变强了，能做的事情多了，于是想用它做事的人也多了。
第二，训练这样的模型太贵了，贵到大多数公司和团队根本负担不起。
这两件事加在一起，催生了一个新的职业方向：AI 工程师。不是研究怎么训练模型的科学家，而是研究怎么用别人训练好的模型做出有用产品的人。
"基础模型"是什么意思
语言模型的原理说起来很简单：给一段文字，预测下一个词最可能是什么。
这件事听起来很基础，但它意外地强大------翻译、摘要、写代码、做数学题，本质上都可以被理解成"给一段文字，把它补全"。
从只处理文字，到同时处理图片、音频、视频，这类模型逐渐有了一个新名字：基础模型（Foundation Model）。"基础"这个词说的是：它可以作为起点，被进一步调整以适应各种需求。
把一个现成的基础模型改造成你想要的样子，主要有三种方法：
- 提示工程：精心设计给模型的指令，不改变模型本身
- RAG（检索增强生成）：让模型在回答时，先去查相关资料
- 微调：用自己的数据对模型做进一步训练
现在都在拿它做什么
通过研究大量开源项目和商业案例，AI 应用大致落在八个方向：
| 方向 | 代表场景 |
|---|---|
| 编程辅助 | GitHub Copilot，写代码、改 bug |
| 图像与视频 | Midjourney，生成广告素材 |
| 写作 | 辅助写报告、邮件、文章 |
| 教育 | 个性化辅导、练习题生成 |
| 聊天机器人 | 客服、AI 伴侣 |
| 信息聚合 | 文档问答、会议总结 |
| 数据组织 | 从非结构化内容提取信息 |
| 工作流自动化 | 让 AI 执行一系列任务 |
企业通常先从内部工具起步（风险低），再逐步拓展到面向用户的产品。
做之前，想清楚几件事
你为什么要做这个 AI 应用？
动机不同，决策也会不同。是因为不做就活不下去，还是看到了赚钱机会，还是只是不想落后？不同的动机对应不同的投入力度。
竞争壁垒在哪里？
门槛低是双刃剑------你能做，别人也能做。真正的护城河来自三个地方：技术、数据、用户渠道。其中数据飞轮（先拿到用户，用用户数据改进产品，吸引更多用户）是 AI 时代最持久的优势。
警惕"最后一公里"陷阱
基础模型让搭一个演示变得极其容易，可能一个周末就能做出来。但要做出真正的产品，可能需要几个月甚至几年。LinkedIn 的经验是：达到 80% 的预期体验只用了 1 个月，但从 80% 到 95% 又花了 4 个月。演示和产品之间，差的不是功能，是那最后一公里的细节。
第二章
读懂模型：它为什么这么做
你用的数据，决定了它能做什么
最朴素的一个事实：模型从数据中学，训练数据里没有的东西，模型就不会。
但现实是，收集"理想数据"太贵了。大多数模型只能用已有的互联网数据，而互联网上充斥着假新闻、低质内容和各种偏见。这就导致一个直接结果：模型在训练数据覆盖好的任务上表现好，在其他地方不一定。
语言偏差问题很典型。英语在训练数据中占了将近一半，所以英语任务的表现远好于其他语言。GPT-4 回答英语数学题的成功率，是回答亚美尼亚语数学题的 3 倍多。更麻烦的是，同样的安全限制在不同语言下效果也不一样------用中文问某些问题，绕过限制的概率比英文高得多。
甚至连费用都受影响。用缅甸语表达和英语同样的意思，需要的 token（计费单位）大约是英语的 10 倍，也就是 10 倍的延迟和 10 倍的费用。
模型的"大脑"是怎么工作的
目前主流的语言模型，核心都用了一个叫 Transformer 的架构。它解决了两个老问题：
- 旧架构只能"看"输入的末尾，Transformer 让模型在生成每个词时都能参考所有输入内容
- 旧架构必须一个词一个词地处理，Transformer 可以并行处理整个输入，快得多
Transformer 的核心机制叫注意力（Attention）：模型在生成某个词时，会权衡输入中所有位置的"重要性"，就像你读文章时，某些关键词会自然吸引更多注意力。
关于模型的大小，有三个维度：
- 参数量：模型有多少个"可调节的旋钮"，代表学习能力
- 训练数据量：喂了多少 token（文字单元）给它
- 训练成本：消耗了多少计算资源
这里有个反直觉的事情：参数多不代表运行时就贵。Mixtral 8x7B 总共有 467 亿参数，但处理每个词时只用其中约 129 亿------所以它的实际运行成本只有真正的 1/3 左右。
扩大模型有没有瓶颈？ 有两个很现实的：
一是数据快用完了。训练数据集增长的速度，远比互联网产生新内容的速度快。而且互联网正越来越多地被 AI 生成的内容填满------如果用 AI 的输出来训练下一代 AI，最终可能越训越差。
二是电力跟不上。AI 数据中心目前消耗全球 1%~2% 的电力，预计到 2030 年会升到 4%~20%。
为什么对话型 AI 和单纯的预训练模型不一样
预训练模型只学会了一件事：补全文字。你输入"如何做比萨"，它可能会继续补充更多问题，而不是给你菜谱。
让模型变成一个能正常对话的助手，需要两轮额外训练：
第一轮：教它怎么对话（监督微调）
给模型看大量"提问→合适回答"的例子，让它学会用正确的方式响应用户。这个数据的收集很贵------需要有专业背景的人来写高质量回答，一条数据可能要花 30 分钟和几十美元。
第二轮：教它应该怎么对话（偏好微调）
上面那步只教了"怎么对话"，但没告诉模型什么话该说、什么话不该说。这步让标注人员比较两个回答哪个更好，用这些比较结果训练模型往"人类喜欢的方向"靠。
核心矛盾在于：人类偏好本身就有争议，审查太严模型变得无趣，审查不够模型可能说有害的话。
AI 说的话为什么会"一本正经地胡说八道"
语言模型的输出本质是概率采样------不是查字典给出唯一答案，而是从所有可能的词里，按概率随机选一个。
这个机制带来两个重要特性：
不一致性：同样的问题问两次，可能得到两个不同的答案。同一篇作文，AI 打分可能一次给 3 分，一次给 5 分。
幻觉：模型会自信地说出不存在的事实。有两种解释：一是模型在生成过程中一旦方向偏了就会越跑越远；二是在后训练阶段，标注员写的答案有时用了模型不知道的信息，实际上是在教模型"编造"。
这两个问题目前没有完美的解决方案，只能通过设计来缓解。
第三章
评估方法：怎么知道它做得好不好
为什么 AI 很难评估
一名律师用 AI 生成了不存在的判例，提交给法庭，被发现后被罚款。一个聊天机器人怂恿用户走上了绝路。加拿大航空公司因为 AI 给出了错误的退款信息，被法院判决必须履行。
这些都是真实发生的事。缺乏质量控制的 AI 应用，风险可能远超收益。
评估基础模型之所以难，主要有几个原因：
- AI 越强，越难评估。评判博士级别数学题的对错，本身就需要博士水平
- 开放式输出没有标准答案。"用 5 种方式描述这幅画"------正确答案有无数种
- 模型是个黑盒。提供商不会告诉你模型内部是怎么工作的
- 基准测试很快就过时。模型进步太快，一个新的测试集往往一两年内就被"解决"了
几种主要的评估方式
方式一：看"困惑度"
困惑度（Perplexity）衡量模型预测下一个词时有多不确定。想象模型在 4 个等概率选项中猜测------困惑度就是 4。越低说明模型越"胸有成竹"。
这个指标对训练有用，但有个陷阱：经过对话优化的模型，困惑度反而可能比原始模型高。因为它被训练得更像人类助手，而不是像机器那样预测下一个词。
方式二：精确对比
直接检测输出是否符合预期，最硬核的方式。代码生成是最适合的场景------写单元测试，跑一跑就知道对不对。对其他任务，可以做精确匹配（完全一致才算对）、词汇相似度（共用的词有多少）或语义相似度（意思有多接近）。
方式三：用 AI 来当裁判
用一个更强的 AI（通常是 GPT-4 这个级别）来评分其他 AI 的输出。
研究发现 GPT-4 作为裁判的判断，和人类评估员的一致性达到 85%，甚至超过了两个人类评估员之间 81% 的一致性。这让"AI 当裁判"成了目前最常用的评估方式之一。
但它有明显的问题：偏心。AI 裁判倾向于给自己（同一家公司）的模型打高分，倾向于给排在前面的答案打高分，倾向于给更长的答案打高分------即使那个长答案是错的。
方式四：让模型互相比较
不给每个模型单独打分，而是让两个模型直接对战------哪个更好？用胜负记录来计算排名。
这种方式更接近人类的自然判断方式（比较两首歌比分别打分容易），也永远不会"饱和"------只要有更强的模型，就能继续比下去。但它只能告诉你谁更好，不能告诉你好多少。
第四章
系统化评估：从想法到流水线
评估应该驱动开发，而不是事后补救
本章提出一个核心理念：评估驱动开发。
在你动手构建应用之前，先想清楚怎么衡量它做得好不好。这不是在给自己增加工作量，而是避免做了很多事之后发现根本无法判断做没做对。
一个已经上线但无法评估的应用，比从没上线过的更糟------它需要持续维护，下线又有成本。
评估什么？
领域能力：模型在你关心的具体任务上做得怎样？代码任务看功能是否正确，其他任务常用选择题形式（因为容易自动化验证）。
事实一致性：模型会不会乱说不存在的事实？
- 有参考资料的情况（比如总结一篇文章）：输出和文章内容一致吗？
- 没有参考资料的情况（开放问答）：输出和公认事实一致吗？
后者更难评估，一种方法是把输出拆成一条条陈述，分别用搜索引擎验证。
安全性：有没有生成不该生成的内容？不同应用有不同的安全红线。值得注意的是，研究发现不同模型存在不同的政治倾向------这是选择模型时容易被忽视的一个维度。
指令遵循：模型有没有按照你要求的格式、长度、风格输出？要求用 JSON，它给没给 JSON？要求不超过 200 字，它有没有超？
成本和速度：能用得起吗？快不快？这两点往往比性能更先成为上线的瓶颈。
自己买还是自己训？
这是每个团队都会反复面对的问题。没有标准答案，但有几个维度可以帮助判断：
数据隐私：如果用第三方 API，你的数据要发送到别人的服务器。三星曾有员工通过 ChatGPT 泄露了公司机密------这种风险是真实存在的。自己部署模型则不存在这个问题。
版权风险：大多数模型的训练数据来源不透明。如果你的应用基于这些模型，产生纠纷时责任怎么算，目前法律还不清晰。商业模型提供商通常会对此做出更明确的承诺。
成本结构：小规模用 API 可能更经济，大规模用就可能发现自己部署反而更便宜。没有通用答案，需要根据实际用量测算。
控制权：用别人的 API，对方可以随时改定价、改政策、改模型行为（甚至不通知你）。自己部署虽然麻烦，但行为是可控的。
设计评估流水线
评估不是"跑一次完事"，而是一套持续运行的系统。
评估所有组件，而不只是最终输出。一个 RAG 系统，检索到的内容相关吗？传给模型的信息准确吗？每个环节都需要单独看。
写清楚评估标准，这一步最关键也最容易被跳过。"质量好"不是标准，"回答与用户问题直接相关、没有引入文档中没有的信息、不超过 200 字"才是标准。
把评估指标和业务结果连起来。评估的分数不是目的，业务指标才是。"事实一致性达到 80% = 可以自动处理 30% 的客服请求"------这样的连接才有意义。
第五章
提示工程：和模型"说话"的艺术
它不只是"调措辞"
提示工程（Prompt Engineering）听起来像在随意换词，但它背后有真实的规律和技巧。可以把它理解为：用语言告诉模型你想要什么、以什么方式给你、避免什么。
一段完整的提示词通常包含三部分：
- 任务描述：你是谁，你要做什么，输出什么格式
- 示例：展示你期望的输出长什么样
- 具体任务：这次具体要处理的内容
几个实用的原则
说清楚，而不是含糊地期待模型猜对
"帮我总结"不如"用 3 句话总结，聚焦在主要结论上，不要提背景信息"。你觉得显然的事，对模型来说未必显然。
给模型设定角色
同一篇作文，让模型以"无设定"状态评分可能得 2 分，让它以"小学一年级语文老师"的角色评分可能得 4 分。角色帮助模型采用正确的视角和语气。
提供示例
模型看到一个例子胜过看到十句描述。尤其是对格式要求复杂的输出，直接给一个样本往往最有效。
把复杂任务拆开
不要用一段超长的提示词完成所有事情。拆成几步：先分类意图，再根据意图选择对应的处理逻辑。这样不仅更容易调整，出了问题也更容易定位是哪一步出了错。
让模型"慢慢想"
在提示词里加上"一步一步地思考"，往往会让模型表现明显变好。这不是魔法，而是给了模型"展开推理过程"的空间，而不是直接跳到结论。这个技巧有个名字叫思维链（Chain of Thought）。
提示词也是攻击面
模型越擅长遵循指令，就越容易被恶意指令利用。
攻击者会试图：
- 提取系统提示词（把你精心设计的指令偷走，复制你的应用）
- 越狱（绕过安全限制，让模型说它"不该说"的话）
- 注入恶意指令（把指令藏在模型会读取的外部内容里，比如被索引的网页）
防御没有银弹，但有几层可以叠加：
- 在提示词里明确说明模型不该做什么
- 对用户输入和模型输出都做过滤检查
- 把敏感操作（比如删除数据）设计成需要人工确认
第六章
RAG 与智能体：给模型接上眼睛和手
模型的"知识截止"问题
模型的知识是有截止日期的------训练结束那一天之后的事，它一概不知。而且它的记忆容量有限，装不进所有你可能需要的信息。
RAG（Retrieval-Augmented Generation，检索增强生成）是解决这个问题的主要方式。
简单说：用户提问 → 先从知识库里检索相关内容 → 把检索到的内容连同问题一起送给模型 → 模型基于这些内容回答。
这比让模型"死记硬背"更灵活，知识库可以随时更新，而不用重新训练模型。
RAG 的关键：怎么找到"相关内容"
基于关键词的检索：像搜索引擎一样，找包含特定词的文档。速度快，开箱即用，但对同义词和语义理解能力弱。
基于语义的检索：把文字转换成向量（可以理解成把文字变成坐标），找语义上接近的内容，而不只是词语相同的内容。"How are you"和"What's up"词语完全不同，但语义相近，语义检索能把它们关联起来。
实际系统通常混合使用：先用关键词快速筛出候选，再用语义重新排序。
检索质量的两个核心指标：
- 精度：找到的内容里，真正有用的占多少？
- 召回率：所有有用的内容，找到了多少？
智能体：让模型能"动手"
普通的 RAG 只是让模型"看"到更多信息。智能体（Agent）走得更远------它让模型能使用工具，真正做事。
工具可以是：
- 检索文档、查数据库
- 执行代码、调用计算器
- 搜索网络、查询实时数据
- 发邮件、下订单、修改数据
有了工具，一个文字模型可以变成数据分析师、研究助理，甚至帮你完成整个工作流程。
但工具也带来了风险。模型能"改"数据了，就意味着一旦判断错了，后果可能是真实且不可逆的。对涉及写入、删除、支付的操作，必须设计人工确认或回滚机制。
模型的"记忆"
智能体需要处理"记住什么、忘记什么"的问题。可以分三层：
- 模型训练里学到的：永久存在，但只到训练截止日期，且不能实时更新
- 当前对话的上下文：类似短期记忆，对话结束就清空了，容量也有限
- 外部数据库：类似长期记忆，可以跨对话保存，RAG 系统就是调用这里的内容
第七章
微调：改造模型本身
提示词搞不定的事，才轮到微调
微调（Fine-tuning）是在现有模型基础上，用你自己的数据继续训练，让它更符合你的需求。
典型的适用场景：
- 模型输出格式总是不对（比如总多余地说废话）
- 需要模型掌握某个冷门领域的知识或风格
- 用大模型的输出数据来训练一个更小、更便宜的小模型（蒸馏）
不适合微调的情况：模型缺的是知识（应该用 RAG）、还没充分测试过提示词（先把提示词做好再说）。
实验数据表明，RAG 带来的性能提升通常比微调更显著，而且更灵活。建议的顺序是：先调提示词，再试 RAG，都不够了再考虑微调。
最大的问题：内存装不下
全量微调一个 130 亿参数的模型，光是存储训练过程中的"中间状态"就需要超过 100 GB 内存。普通 GPU 远远不够。
这催生了两类解决思路：
第一类：减少需要更新的参数
LoRA（Low-Rank Adaptation，低秩适应）是目前最流行的方法。
直白地说：全量微调时，模型的每一个"旋钮"都要调。LoRA 的思路是：大部分旋钮其实不需要动，只需要在原来的矩阵旁边加两个小矩阵，调这两个小矩阵就够了。效果接近全量微调，但需要的内存和数据少得多。
训练完之后，小矩阵可以合并回原来的权重里，不增加任何运行时的速度损耗。
第二类：降低数值精度
模型里的每个数字，正常情况下用 32 位或 16 位来存储。把它压缩到 8 位甚至 4 位，内存占用大幅下降，速度也提升了，但精度会有所损失。
QLoRA 把这两件事结合起来：4 位存储 + LoRA 训练，让在单张消费级 GPU 上微调 650 亿参数的模型成为可能。
不用训练的"合并"方式
还有一种很有意思的思路：不训练，直接把两个模型"混合"在一起。
把一个擅长代码的模型和一个擅长写作的模型平均一下------得到的新模型两个都能做，而且效果比单独使用任一个都好。
这背后的逻辑是：基于同一个基础模型微调出来的两个模型，虽然各有侧重，但底层结构是兼容的，参数之间可以"互补"。
第八章
数据集工程：垃圾进，垃圾出
数据质量比数量更重要
这是数据领域最常被说、也最常被忽视的一句话。但有实验数据支撑：
- Yi 模型用 1 万条精心设计的指令，效果优于几十万条含噪数据
- LIMA 实验发现，650 亿参数的模型只用 1000 条精选数据微调，在 43% 的情况下表现与 GPT-4 相当或更好
高质量数据有六个特征：与任务高度相关、符合具体要求、标注一致、格式规范、足够多样、符合合规要求。
AI 生成数据：潜力与陷阱
用 AI 来生成训练数据，是目前缓解数据稀缺问题的主流做法。
它能做什么：
- 改写已有数据（一个问题变成 10 种表达方式）
- 生成指令和答案
- 把大模型的"知识"蒸馏到小模型里
它的真实局限：
模型可能只是模仿了教师模型的"风格"，没有真正学到能力。更危险的是模型坍塌：如果不断用 AI 生成的数据来训练 AI，模型会越来越倾向于生成"常见"的内容，逐渐遗忘罕见但重要的东西。Anthropic 的研究发现，哪怕只有 0.1% 的数据被重复了 100 次，就可能让模型表现大幅下降。
最有效的策略是：合成数据 + 真实数据混合使用，并对合成数据做质量验证。
数据处理：容易被忽视的环节
清理数据比大多数人想的重要。Databricks 发现，仅仅移除多余的 Markdown 和 HTML 格式标记，模型准确率就提升了 20%，同时 token 长度缩短了 60%（意味着费用也降了）。
人工检查数据是机器学习里最被低估的活动。通常只需要 15 分钟仔细看一看，就能发现用程序扫描发现不了的问题，避免后续数小时的排查。
第九章
推理优化：让它跑得快一点、便宜一点
两种瓶颈，两种解法
模型运行速度受限于两类不同的瓶颈：
计算受限：处理用户输入的阶段。能同时处理多少内容，取决于芯片的运算能力。
内存带宽受限：生成输出的阶段。每生成一个词，都需要把模型的全部权重读一遍，受限于内存的数据传输速度。
这两种瓶颈需要不同的优化策略。实际生产系统里，通常把这两个阶段分配到不同的机器上处理。
衡量速度的几个指标
- TTFT（首词延迟）：从用户提交问题到看到第一个字的时间
- TPOT（每词生成时间）：后续每个词平均需要多长时间
- 吞吐量：每秒总共能处理多少词，决定了单位成本
不同应用对这三个指标的侧重不同：聊天机器人最在乎首词延迟（用户最先感知到的等待），长文档处理更在乎总吞吐量。
几种主要的优化手段
量化：降低模型存储精度。从 32 位降到 16 位，再降到 8 位、4 位......每降一级，内存少一半，速度快一倍，但精度也会有损失。目前有方案做到每个参数只用 1.58 位，性能还能和 16 位的版本相当。
推测解码：用一个小模型先快速猜一串词，再让大模型并行验证哪些猜对了、哪些没有。验证比生成快得多（可以并行化），所以整体速度能提升一倍以上，且输出质量不受影响。
提示词缓存：如果很多请求都有相同的开头部分（比如系统提示词），就把这部分处理结果存起来，下次直接用，不用重新计算。对于有大量重复系统提示词的应用，可以节省最高 90% 的成本。
连续批处理：一个请求处理完立刻放进下一个，而不是等一批凑齐再一起处理。这样 GPU 始终保持忙碌，利用率大幅提升。
第十章
架构与用户反馈：把所有东西拼在一起
从最简单的架构开始
一个 AI 应用最简单的样子：用户发问 → 发给模型 → 返回答案。
但这样的系统什么防护都没有，什么优化都没有。真实的产品需要一步步叠加更多组件：
第一步：增强上下文（接入 RAG，让模型能查资料）
↓
第二步：设置防护（过滤危险输入，检查有问题的输出）
↓
第三步：路由和网关（不同问题走不同模型，统一管理 API）
↓
第四步：缓存（重复的问题直接取缓存，不重复调用 API）
↓
第五步：智能体能力（循环执行、写入数据、触发动作）
↓
始终贯穿：监控与可观测性防护措施：输入和输出都要管
输入防护：防止用户把公司机密粘贴进提示词发给第三方 API（这事真的发生过）；防止恶意输入绕过系统限制。
实际做法是脱敏：识别敏感信息（电话号码、账户、关键词）并替换成占位符，发给模型的是脱敏版本，返回给用户时再还原回去。
输出防护：检查模型输出是否满足要求------格式对不对？有没有产生有害内容？事实有没有明显错误？
出了问题怎么办？最简单的是重试------AI 的输出是概率性的，同样的问题多问一次可能得到不同的答案。但重试会增加时间和成本，所以有时会并行发两次请求，取更好的那个。
监控：不仅要知道"出事了"，还要知道"为什么"
三个衡量监控质量的指标：
- 平均检测时间：出了问题，多久能发现？
- 平均恢复时间：发现问题，多久能解决？
- 变更失败率：每次上线新版本，有多大比例引入了新问题？
需要追踪的东西很多：用户中途停止生成的频率、每次对话有几轮、API 花了多少钱、模型输出格式出错的比例......
一个容易被忽视的变化来源是模型的静默更新：同一个 API 接口，底层模型可能已经换了，提供商不一定会通知你。研究发现 GPT-4 不同时间版本的表现差异非常显著------你的应用可能在不知情的情况下变差了。
用户反馈：产品改进最真实的信号
用户反馈不只是"产品好不好"的参考，在 AI 应用里，它直接就是数据------用来改进模型的数据。
显式反馈：点赞、点踩、评分。明确，但很多用户不愿意费这个功夫。
隐式反馈（更有价值，也更难解读）：
| 用户行为 | 可能意味着 |
|---|---|
| 中途停止生成 | 对结果不满意 |
| 回复以"不"或"我的意思是"开头 | 模型没理解对 |
| 修改模型的输出 | 强烈的负面信号，同时是偏好数据 |
| 要求重新生成 | 不满意，或想要更多选择 |
| 删除对话 | 强烈的负面信号 |
| 对话轮数很多 | 效率应用意味着问题没解决；陪伴应用意味着体验好 |
Midjourney 的设计值得借鉴：生成 4 张图，用户可以选某张"放大"或"变体"------这个选择动作本身就是反馈，告诉系统哪张图最受欢迎。用户完全没有意识到自己在"提供数据"。
反馈的陷阱
收集到反馈不等于反馈是准确的。几个常见的偏差：
宽容偏差：用户倾向于给出比真实体验更正面的评价，因为给差评需要解释原因，懒得填。
位置偏差：当两个选项并排时，用户倾向于选第一个，而不一定因为第一个更好。
最危险的是恶性反馈循环：系统根据用户反馈调整行为，调整后的行为又影响用户行为，这样循环下去，可能放大初始的偏差。举个例子：某类内容被推荐后获得更多点击，点击又加强了推荐，热门内容越来越占据主导，新内容越来越难露出来。类似的机制也会让模型变成"迎合者"------越来越倾向于说用户想听的话，而不是正确的话。
整本书的主线
把十章的内容串起来，本书回答的是同一个问题：怎么在强大但不完美的基础模型之上，构建真正可用的产品？
答案不是一个技术，而是一套系统：
理解模型（第2章）→ 评估能力（第3、4章）→ 适配模型（第5、6、7章）
→ 准备数据（第8章）→ 优化性能（第9章）→ 整合产品（第10章）贯穿始终的几个核心认知：
1. AI 的概率特性是根本。它不是查字典，是在猜。这带来了创造力，也带来了不一致和幻觉。所有的架构设计和评估策略，本质上都是在围绕这个特性打转。
2. 评估是最被低估的环节。做出演示很容易，做出可靠的产品很难。可靠性来自系统化的评估，而不是直觉。
3. 用户数据是真正的护城河。基础模型大家都能用，但用户反馈形成的数据飞轮是自己的。先上线，收集数据，持续改进------这比追求完美的第一版更重要。
4. AI 工程越来越靠近产品。不只是写代码，还需要理解用户、设计反馈机制、权衡成本与体验。会写代码的产品经理，或者懂产品的工程师，在这个时代有独特的优势。