六位一线 AI 工程师和创业者，把在大模型使用开发上摸爬滚打一整年的心得，全！分！享！了！
（奇怪的六一儿童节大礼包出现了）
这篇干货长文，一时间成为开发者社区热议的话题。
有网友评价为，大模型领域少有的“有操作性”的实用见解，非常值得一读。
这 6 位作家来自不同背景，比如有大厂工程师，也有独立开发者，还有咨询顾问。
但他们的共同之处，是过去一年里一直在大模型之上构建真实使用程序，而不只是炫酷的 Demo 演示，他们认为：
现在正是非呆板进修工程师或科学家，也能把 AI 构建到产物中的时候。
在他们的一系列分享中，网友热议的亮点包括但不限于：
-何时用长上下文、何时 RAG、何时微调模型
多样化输入不止提高温度，改变提醒词中示例的秩序也影响结果
长上下文不会让 RAG 过时
“实习生测试”：如果大学生能根据提醒词完成使命，说明比较完善了
每个大模型都有自己的偏好，Claude 更喜欢 XML 格式，GPT 系列更喜欢 Markdown 和 JSON
如果靠提醒词已完成了 90% 的使命，微调能够就不值得投资
大模型当裁判评价结果能够起作用，但不是万能的
……
总之，无论是大厂工程师、创业者还是参加个人开发者，都值得一看。
全程高能干货分享
提醒词、RAG 和微调都是改善大模型输入结果的有效方法。
但是何时该用何种方法，还没有定论。
作家们认为，必要根据具体的使用场景、使命需求、利润效益和性能目标来做出决策：
建议在开发新使用程序时从提醒词开始
必要大模型掌握新知识时优先使用 RAG
当必要针对特定使命优化时再考虑微调
最后，他们还重点讨论了对大模型使用的评价和监测，认为是应当贯穿开发全流程的重要环节。
提醒词篇
很多开发者都陷入了一个误区：以为设计一个涵盖一切的“终极提醒词”就能完美解决问题。
就像过去软件开发中也有希望一个类或函数可以完成所有事情的误区。
实际情况恰恰相反，随着需求的复杂化，这样的 Prompt 会越来越臃肿，性能反而每况愈下。
那么正确的做法是什么呢？提醒词也应当像代码一样保持简洁，以会议记录归纳场景来说，可以分解为以下步骤：
将关键决策、待办事项和执行者提取为结构化格式
检查提取的详细信息与原始会议记录的一致性
从结构化详情生成简明摘要
通过拆分，每个提醒词都简单、突出重点且易于理解，更重要的是接下来可以单独迭代和评价每个提醒词。
比如思维链鼓励 AI 在最终回答之前写下思维过程，除了“一步一步思考”之外，还可以用一些技巧显著降低幻觉。
还以会议记录归纳场景为例，迭代后的提醒词示例为：
- 首先，在草稿中列出关键决策、待办事项和相关执行者。- 然后，检查草稿中的细节是否与文字记录相符。- 最后，根据要点合成简洁的归纳。
在提醒词方面，作家们还提出了更多具体经验。
对于给大模型提供示例的上下文进修：
提醒词中的示例数量追求≥5（也不要害怕用上几十个）。太少会让模型过度遵循特定示例、损害泛化能力。
示例应当反映预期的输入分布。比如做电影剧情归纳，示例中不同类型电影的比例大致应与实践中期望看到的相同。
不一定必要提供完整的输入-输入对。在许多情况下，只有输入的示例就足够了。
如果所用的大模型支持工具调用，则示例也应包含希望 AI 使用的工具。
对于结构化输入输入：
优化上下文结构，让模型更容易理解和处理。单纯打包一堆文件人类看着头疼，AI 看着也费劲。
只保留必要信息，像雕刻艺术家一样剔除冗余、自相矛盾和格式化错误。
每个大模型都有自己的偏好，Claude 更喜欢 xml 格式，GPT 系列更喜欢 Markdown 和 JSON。
比如给 Claude 的提醒词，甚至可以用 xml tag 来预填充输入模板。
RAG（检索增强生成）篇
不要忘记关键词搜索
基于 Embedding 的 RAG 演示很多，让人们容易忘记信息检索领域数十年来积累的经验。
作家认为向量检索无疑是强大的工具，但不是全部。虽然擅长捕获高级语义相似性，但它们能够难以处理更具体的关键字，比如人名、首字母缩略词或者 ID。
不要忘记传统的关键词匹配（如 BM25 算法），在大多数情况下，混合关键字匹配和向量搜索效果最好：
先匹配最明显的关键词，再对同义词、上位概念和拼写错误做向量查询，以及多模态向量查询。
RAG 输入的质量取决于检索文档的质量
具体来说，检索文档的质量又取决于几个因素。
第一个也是最明显的目标是相关性。与传统举荐系统一样，检索到的项目的排名对大模型输入产生重大影响，要衡量这种影响，可以试试打乱秩序并观察大模型行为变化。
第二个是信息密度。如果两份文档同样相关，应当选择更简洁、无关细节更少的那个。
最后是信息的详细程度，附加的详细信息可以帮助大模型更好地理解。
优先 RAG，而不是对新知识微调
RAG 和微调都可让大模型掌握新知识并提高特定使命的性能。那么，应当优先选择哪一个呢？
微软一篇论文比较 RAG 与无监督微调（又叫持续预训练），发现对于新知识 RAG 性能始终优于微调。
△arxiv.org/abs/2312.05934
除了改进性能之外，RAG 容易更新而且利润更低。如果知识库中发现错误，RAG 方法只需简单删除有问题的文档即可。
RAG 还可以给文档权限提供更细粒度的控制，确保每个用户只能访问自己有权限的文档，不会泄露信息。
长上下文不会让 RAG 过时
首先，即使上下文窗口达到一千万 tokens，仍然必要一种方法来选择要输入模型的信息。
其次，除了简单大海捞针评价之外，还没有看到令人信服的数据表明模型可以在如此大的上下文进行有效的推理。
如果没有良好的检索和排名，干扰因素能够淹没模型，甚至能够用完全不相关的信息填满了上下文窗口。
最后还有利润问题，Transformer 的推理利润随上下文长度二次增长，过度依赖长上下文能够不划算。
微调篇
当最巧妙的提醒词设计也无法完成一些使命时，能够就必要考虑微调了。
虽然微调能够是有效的，但它会带来巨大的利润。必须注释微调数据、执行微调和评价模型，并最终自行部署模型。因此，请考虑较高的前期利润是否值得。
作家们的经验是：
如果提醒词已完成了 90% 的使命，那么微调能够不值得投资。
如果确定要微调，可以考虑合成数据或开源数据集，降低人工收集注释数据的利润。
Agent 与工作流
最成功的 Agent 开发者能够也是工程师团队的管理者，因为给 AI 制定计划的过程和管理初级员工的方式类似。
我们给人类新手明确的目标和具体的计划，而不是模糊的开放式指示，对 Agent 也应当这样做。
优先考虑确定性工作流程
Agent 被期待动态对用户请求做反应，但随着执行步数增加，失败的能够性指数增加，并且从错误中恢复的机会很小。
一种有前途的方法是使用 Agent 系统来生成确定性计划，然后以结构化、可重复的方式执行这些计划，好处包括：
生成的计划可以作为提醒词中的少数样本，或微调数据。
使系统更加容易测试和调试，失败可以追溯到计划中的具体步骤。
生成的计划可以表示为有向无环图 (DAG)，相对于静态提醒词，它更容易理解和适应新情况。
多样化输入不止提高温度
如果使命必要输入的多样性，比如根据用户之前购买过的产物举荐新产物，简单增加大模型的温度参数能够会产生问题。
如果温度太高，能够会生成不存在的产物，甚至输入乱码。
其他增加输入多样性的方法包括：
最简单的是调整提醒词内的元素秩序，打乱用户历史购买记录的秩序，就能够产生显著差异。
还可以在上下文中保留前几轮的输入，并要求大模型避免重复最近举荐过的产物。
另一个策略是改变提醒词的措辞，比如“选择用户喜欢经常使用的产物”和“选择用户能够会举荐给朋友的产物”。
评价与监测
大模型的输入和输入是任意文本，要完成的使命是多种多样的。尽管如此，严格且深思熟虑的评价仍至关重要。
从真实的输入 / 输入样本中创建基于断言的单元测试
作家建议创建由生产中的输入和输入样本组成的单元测试，并基于至少 3 个目标测试。
3 个目标是实践中归纳出来的，更少能够表明使命没有充分定义，或过于开放。
这些单元测试应当由工作流的任何更改触发，无论是编辑提醒词、通过 RAG 添加新上下文还是其他修改。
大模型当裁判能够起作用，但不是万能的
作家认为，让最强大的模型当裁判、给其他模型的输入打分，用于定性比较优劣能够有用，但具体输赢的幅度就没什么参考价值了。
不要让大模型在量表上对单个输入进行评分，而是提供两个选项，要求选择更好的一个，这往往会带来更稳定的结果。
提供的选项秩序能够会影响结果，为了缓解这种情况，请将每个成对比较进行两次，每次交换秩序。
在某些情况下，两种选择能够同样好。因此允许大模型宣布平局，这样就不会武断地选一个胜者。
使用思维链：要求大模型在给出最终偏好之前解释其决定，可以提高评价的可靠性，还可以让更小的模型获得与大模型类似的结果。
（这部分流程通常处于并行批处理模式，思维链带来的额外延迟并不造成问题。）
大模型往往偏向于较长的回答，为减少这种情况，请确保成对的回答长度相似。
“实习生测试”
如果将提醒词（包括上下文）作为一项使命，交给相关专业的普通大学生，他们能成功吗？必要多长时间？
如果大学生都做不到，就该考虑如何给大模型提供更丰富的上下文资料了。
如果根本无法通过改进上下文来解决这个问题，那么这就是对当代大模型来说太难的使命。
如果大学生能做到，但必要一段时间。可以尝试降低使命的复杂性。分解使命，或某些方面是否可以更加模板化。
如果大学生能做到，而且很快，但大模型不行。那么就该深入研究大模型反馈的数据了。尝试找到失败的模式，让模型在输入之前或之后解释自己。
过分强调某些目标能够影响整体
著名的古德哈特定律表示，“当一项目标成为目标时，它就不再是一项好目标”。
比如针对长上下文的“大海捞针”测试最早是网友提出的，迅速成为行业通用方法之后，就很容易针对性优化、刷榜。
更好的目标能够正是复杂的实际使命，比如“给定一个小时的会议记录，大模型能否归纳出关键决策、待办事项和相关负责人”。
这项使命更切合实际，超越了死记硬背的范畴，还考虑到了解析复杂讨论、识别相关信息和归纳归纳的能力。
在归纳中强调事实一致性能够会导致摘要不那么具体（因此不太能够与事实不一致），也能够不那么相关。
反之，如果强调写作风格和口才，则能够导致更多花哨的话术，从而造成与事实不符的情况。
LLMs 甚至会在不应当返回输入时返回输入
大模型经常会在不应当生成输入的情况下生成输入。能够是无害但无意义的输入，也能够是更严重有害输入。
例如，当被要求从文档中提取特定属性或元数据时，大模型能够会自信地返回不存在的结果。可以尝试让大模型回答“不适用”或“不知道”，但也并非万无一失。
虽然谨慎的提醒工程可以在一定程度上起作用，但还应辅之以强大的“护栏”机制，以检测和过滤 / 重新生成不受欢迎的输入。
例如，OpenAI 提供了一个内容过滤 API，可识别不安全的响应，如仇恨言论、自残或性内容。同样，还有许多用于检测个人身份信息 (PII) 的软件包。这样做的好处之一是，”护栏”在很大程度上与场景无关，因此可广泛使用于特定语言的所有输入。
此外，通过精确检索，如果没有相关文档，系统也可以确定地回答 “我不知道”。
在实际使用中，最好持续记录输入和输入，以便进行调试和监控。
幻觉很难彻底解决
与安全问题不同，幻觉能够很难被发现。
根据作家们从大模型供应商那里了解到的情况，要将幻觉率降低到 2% 以下是非常困难的，即使是在摘要等简单使命中也是如此。
为了解决这个问题，可以将提醒工程（生成的上游）和事实不一致护栏（生成的下游）结合起来。
对于提醒词工程，思维链等技术可以让大模型在最终返回输入之前解释其推理，从而帮助减少幻觉。然后，可以使用事实不一致护栏来评价摘要的事实性，并过滤或重新生成。
技术篇结束，还有运营、战略篇
对于这篇精彩的实战经验分享，沃顿商学院教授 Ethan Molick 举荐并感慨：
这篇文章显示了从传统软件角度来看，使用大模型是多么奇怪，以及人们还有多少东西必要进修。
事实上这只是六位作家完整分享的三分之一：战术篇。
第二部分运营篇也刚刚发布，围绕数据、模型、产物、团队发展四个话题展开分享。
接下来还有最后一部分战略篇，也是狠狠期待了。
最后，不妨再来认识一下六位作家。
Eugene Yan
他目前是亚马逊高级使用科学家，负责构建服务全球数百万客户的举荐系统，并使用大语言模型来更好地服务客户。
此前，他曾在 Lazada（被阿里巴巴收购）和一家健康科技初创公司领导呆板进修团队。他在 eugeneyan.com 和 ApplyingML.com 上撰写并发表关于呆板进修、举荐系统、大语言模型及工程方面的文章和演讲。
Bryan Bischof
Bryan Bischof 是 Hex 的 AI 负责人，领导工程师团队开发了 Magic—— 数据科学和分析助手。
他在数据领域有丰富的工作经验，曾创建了 Blue Bottle Coffee、Weights and Biases 的数据团队，领导了 Stitch Fix 的多个项目，还曾与 O’Reilly 合写了“Building Production Recommendation Systems”一书，并在罗格斯大学教授数据科学和分析课程。他拥有纯数学博士学位。
Charles Frye
Charles Frye 在加州伯克利获得了神经网络优化方面的博士学位。
他通过在 Weights and Biases、Full Stack Deep Learning 和 Modal 的教育和咨询工作，教授了数千人从线性代数基础到 GPU 奥秘以及构建可行商业模式的整个 AI 使用开发过程。
Hamel Husain
Hamel Husain 是一位拥有超过 25 年经验的呆板进修工程师。
他曾就职于 Airbnb 和 GitHub 等，参与了 OpenAI 用于代码理解的早期大语言模型研究，还领导许多受欢迎的开源呆板进修工具。Hamel 目前是一名帮助公司将 LLM 投入运营加速其 AI 产物开发的独立顾问。
Jason Liu
Jason Liu 是一位知名的呆板进修顾问，在个性化算法、搜索优化、合成数据生成和 MLOps 系统方面拥有技术专长。
他曾在 Stitchfix 创建了一个处理每日 3.5 亿次请求的举荐框架和可观测性工具，还曾在 Meta、纽约大学以及 Limitless AI 和 Trunk Tools 等初创公司担任重要角色。
Shreya Shankar
Shreya Shankar 是加州伯克利计算机科学博士生和呆板进修工程师。
她曾是两家初创公司的首席呆板进修工程师，从零开始构建 AI 产物。她的工作重点是通过以人为中心的方法解决生产级呆板进修系统中的数据挑战，研究成果发表在 VLDB、SIGMOD、CIDR 和 CSCW 等顶级数据管理和人机交互会议上。
另外，作家们还计划举办一场线上直播（北京时间 6 月 21 日上午），就大模型产物开发展开更多分享，感兴趣的朋友可以报名了。
阅读原文
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/
线上直播活动：
https://lu.ma/e8huz3s6
参考链接：
[1]https://news.ycombinator.com/item?id=40508390
本文来自微信公众号：量子位 （ID：QbitAI），作家：梦晨 西风