人工智能工程概念及其重要性层级图
了解哪些人工智能工程概念决定了系统是否能够正常运行，哪些在投入生产时至关重要，以及哪些可以暂缓处理。
名词列表将全部二十个项视为等同，但实际上并非如此。其中六个决定了系统是否能够正常运行。另外七个在开始构建可用于生产的系统时才变得重要。最后的七个则是你在交流中应该能够识别的概念，但可以安全地推迟一年再深入学习——不幸的是，这些往往正是人们会利用空闲时间去研究的内容。
接下来的内容将探讨同样的主题，但会为每个概念附加三方面信息：它实际能为你带来什么、它在何时开始变得重要，以及一种方法来检验你是否真正理解了它，而不仅仅是认出了这个术语。
这些检验方法才是值得关注的部分。大多数人直到第一次尝试大声解释某个主题时，才会发现自己已经听了好几个月却并未真正理解。
第一层：决定系统能否正常运行的六个要素
1. 嵌入模型与向量搜索
其作用：几乎所有与检索相关的功能都依赖于这一概念，若处理不当就会导致系统故障，但往往不会抛出错误信息。
检验方法：两个嵌入模型分别生成1024维的向量。请解释为何基于其中一个模型输出结果训练的分类器，在接收到另一个模型的向量时仍会生成错误的判断。
如果认为维度匹配就意味着兼容，那完全是误解。嵌入模型会定义自己的几何结构。两个不同的模型会将完全相同的句子放置在仅形状相同但实际位置截然不同的空间中。你的系统架构中没有任何机制能提醒你这一点。
2. 检索质量，它与RAG不同
它带来的优势：几乎涵盖了基于检索系统的所有答案质量——而这些质量几乎都不是来自语言模型本身。
检验标准：列举出在调用语言模型之前，RAG流程可能出错的三个环节。
这三个环节分别是分块、嵌入和排序。如果文档分割的边界有误，就会丢失能够回答问题的那句话；若使用的嵌入模型训练数据领域不当，术语会在向量空间中处于错误的位置；省略重排步骤则会导致检索器返回在主题上相关但在事实层面无关的结果。那些认为存在幻觉问题的团队，往往实际上存在检索问题，他们常常会花一个月时间调整提示词，却从不先检查这一点。
3. 评估
它带来的好处：能够判断某项改动是否真正提升了性能，这正是工程方法与盲目猜测的区别所在。
评估标准：需明确所依据的黄金标准——包括样本数量、来源、评分依据以及谁来审核这些分数。
如果无法用具体数字回答，那便不算真正的评估，只是凭感觉加上周二恰好有效的演示而已。一个合理的起点是从实际生产流量中抽取两百到五百组真实的提示词与响应对，从若干既定维度进行评分，并由人工抽查部分结果。还需注意的是，若使用模型作为评估者，该模型本身也需要被评估——这是一个令人不适但不可避免的递归问题。
4. 结构化输出与工具使用
其优势：将生成文本的系统与实际执行任务的系统连接起来。
验证要点：模型返回的JSON数据不符合你的架构规范。需明确说明系统接下来的操作。
大多数人只停留在“我们重新尝试”这一步，但真正的难题才刚刚开始。需要重试多少次？采用何种延迟策略？重试时是否要包含验证错误信息，以便模型有机会自行修正错误？最终失败后会发生什么——用户会看到错误消息，还是只能得到质量下降但仍可使用的答案？工具调用本质上就是跨越可能产生幻觉的边界进行的函数调用，因此所有针对不可信输入的验证标准在这里同样适用。
5. 成本与延迟控制
它能带来什么：真正投入使用的功能与因财务原因被否决的演示版本之间的区别。
评估标准：说明当前每次请求的成本，然后列出五种将其减半的方法，并按每种方法带来的影响程度进行排序。
有五种方法值得提前准备。对于简单的请求，可以发送给价格更低、规模更小的模型，而非默认的模型。为那些在语义上与已处理请求相似的请求缓存响应，而不仅仅是完全相同的请求。削减或压缩输入提示词中的内容。将那些不需要实时响应的内容分批处理，并在离线环境下执行。此外还要缩短模型生成的输出内容，因为它所生成的标记通常比用户输入的标记成本更高。据报道，Stripe本月为OpenRouter支付了超过70亿美元——这家公司的核心产品实际上就是自动化实现上述前两种方法——这表明业界已不再将成本控制视为无关紧要的细节。
6. 上下文管理
其优势：当输入内容超出上下文窗口时仍能保持可预测的行为，这种情况在实际应用中屡见不鲜，而在演示环境中几乎不会发生。
需要核查的问题：当上下文窗口被填满时，哪些内容会被舍弃？又是谁做出了这个决定？
合理的回答会明确具体的策略：先舍弃最旧的对话内容，或先丢弃得分最低的检索结果片段，对中间部分进行总结，或者直接拒绝请求。而令人担忧的回答则是称框架会自动处理，因为这通常意味着有重要内容被悄悄丢弃，且实际上没人去检查过具体是哪些内容。
第二层级：在开发实际产品时会学到的七项知识
一旦系统正式上线且有真实用户开始使用，这些问题就会变得重要起来。提前研究它们并无坏处，但在第一阶段之前就进行研究则属于本末倒置。
7. 作为版本化对象的提示词
对提示词的撰写技巧给予了远超其实际价值的关注，而围绕提示词的工程规范却鲜受重视。实际上，由于提示词本质上是一种无需经过编译器就能直接投入使用的代码，因此需要有一个注册表、固定版本、并行对比功能以及回滚能力。
8. 分块策略
将文本分割成固定大小的片段、沿语义边界进行划分，以及在各片段之间设置重叠区域，这些都是在召回率与精确度之间做出的不同权衡。正确的选择取决于底层文档的结构，而非教程所推荐的默认设置。
9. 重新排序
通常的做法是先获取大量且成本较低的候选列表，然后再对这些候选列表进行成本较高的评分处理。跳过这第二步处理很可能是导致检索流程产生的结果看似正确却又不够精准的最常见原因。
10. 限制措施与提示注入
这需要多层防御机制：在入口处使用低成本过滤器，在更靠近模型本身的位置进行更高成本的检测。来自用户或系统获取的文档中的任何文本都应被视为潜在的恶意输入，绝不能当作可信的指令。
11. 非确定性系统的可观测性
这里需要的是追踪信息，而非普通的日志。真正关键的问题是：三天前出现某个错误答案时，具体检索了哪些内容，当时使用的是哪个提示版本，只有追踪层面的细节才能回答这些问题。
12. 在提示生成、信息检索与微调之间做选择
这一决策的重要性远超过掌握任何单一技术。检索功能能够提供知识，微调则可控制形状、行为及输出格式，而提示词则涵盖了无需借助前两者即可处理的所有其他事务。一个常见的错误是试图用微调来解决实际上属于检索缺陷的问题。
13. 智能体循环与工具选择
一个配备了精心挑选的工具集且具有有限执行循环的单一智能体，就能处理相当大比例人们试图通过多智能体架构来解决的问题。
第三层级：值得了解并暂缓深入的七项内容
对于这一层级，只需足够熟悉相关术语以便参与相关讨论即可。若没有具体问题迫使需要更深入的了解，也可以暂缓学习，而对许多从业者而言，这样的时刻永远不会到来。
14. 多智能体协调
这是列表中最为被过度夸大的条目。已有越来越多的研究探讨了为何这些系统在部署后会出问题，得出的普遍结论是：协调开销与累积的错误率往往会导致其在大多数应用场景中的表现不如一个设计合理的单一智能体。只要了解该术语的含义，仅在万不得已时才考虑使用这种架构。
15. 量化与服务优化
如果你需要自己托管模型权重，这一点非常重要；而只是调用API的话则几乎无关紧要。
16. Transformer内部机制
注意力机制、位置编码以及该架构的其他组成部分在面试中出现频率远高于实际工作场景。了解一次固然有价值，但深入理解它们对系统构建方式的影响其实相当有限。
17. 蒸馏技术
当你已经拥有一个可用但成本高昂的系统且需要削减开支时，这一方法才会派上用场——这是后续出现的问题，而非初始就存在的问题。
18. 语义缓存
这是一种效果显著但风险极高的技术：对于近似匹配的查询，缓存命中会以十足的确定性返回错误答案。
19. 知识图谱与GraphRAG
当底层数据真正具备关联结构时，这些技术能带来实际好处，但要实现这些优势则需要大幅增加系统复杂性。
20. 偏好调优与RLHF系列技术
这主要适用于那些实际负责训练模型的团队，而非在现有模型基础上开发应用程序的团队。
令人困扰的部分
回顾这三个层级，你会发现有些情况本应相反。
多智能体协调、Transformer内部机制以及提示词编写是占据人们最多学习精力的主题，这三者都属于第二级或第三级难度。而评估、检索质量与成本控制才是决定系统能否真正发挥作用的关键因素，却只得到了极少的关注，主要是因为它们都无法形成令人印象深刻的演示效果。
出现这种差异有明确的原因，与其作为批评提出，不如直截了当地说明。第三级主题易于理解——你可以在通勤时阅读有关多智能体协调的内容，读完后会觉得自己学到了东西。而评估则要求你构建高质量的数据集，与团队成员探讨“优秀”标准究竟是什么，有时还得接受自己的系统其实并不如演示时那么强大这一事实。其中一种活动很轻松，另一种才是真正有帮助的。
如何真正学会这些知识而非仅仅收集它们
像这样的清单容易让人误以为只是需要通读的教学大纲。仅靠阅读最多只能达到识别的程度，一旦有人提出进一步的问题，这种认知立刻就会瓦解。
养成两种习惯比单纯阅读效果要好得多。
首先，从头到尾构建一个小型系统，然后故意破坏它。将检索流程指向你真正关心的文档，再刻意破坏其中的每个环节。把文本分割得过碎，就会看到回答质量急剧下降。移除重排器，观察会发生什么变化。向系统输入提示注入尝试，看看它会泄露哪些信息。用这种方式度过一个周末所学到的，比一个月的阅读还要多，因为留下的都是具体故障的记忆，而非抽象的定义。
其次，要用实际问题来检验这些词汇掌握情况。本文中提到的各种测试都是基于现实中真实出现的问题设计的，通过处理真实的系统设计类题目是发现自身理解漏洞的最快方法，因为实际问题往往会有后续追问，而恰恰在这些追问面前，仅靠表面认知已远远不够。
我可能出错的地方
这个排名是基于此处所分析的特定系统得出的主观判断，并非正式调查的结果，因此称其为有依据的排序比称之为绝对正确的排名更为准确。
有两个排序位置值得公开讨论。多智能体协调被归为第三级，部分原因是目前关于这些系统在实际应用中表现的证据并不理想，而若未来出现真正可靠的框架，很可能会将其提升等级。Transformer内部机制在此处的排名较低，因为与AI模型打交道越来越偏向于集成工作而非建模工作，那些直接从事模型开发的人应该将这一项的排名大幅提高。
最需要坚决捍卫的排序位置是第三位的评估工作，实际上有充分的理由将其置于首位。没有评估，列表中的其他所有项目都只能靠猜测，因为无法衡量的事物就无法改进，而如今基于模型开发的团队中，几乎没人能够准确判断上周的改动是让情况变好还是变差。
如果要对这一排名进行重新排序，最有趣的分歧很可能出现在第一层级与第二层级之间。更有价值的讨论应是明确哪些项目应该上调排名，以及这样的调整究竟带来了什么好处，而非再列出一份包含二十个项目的清单。
相关阅读
- 将LLM作为法官式实时生产系统进行管理 — 了解Netflix如何通过四阶段生命周期——真实数据、基于评分标准的训练、安全部署以及持续监控——来确保大规模应用中的LLM法官系统保持准确性。