六位一线AI工程师总结爆火！大模型应用摸爬滚打一年心得公开

六位一线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性能始终优于微调。

除了改进性能之外，RAG容易更新而且成本更低。如果知识库中发现错误，RAG方法只需简单删除有问题的文档即可。

RAG还可以给文档权限提供更细粒度的控制，确保每个用户只能访问自己有权限的文档，不会泄露信息。

长上下文不会让RAG过时

首先，即使上下文窗口达到一千万tokens，仍然需要一种方法来选择要输入模型的信息。

其次，除了简单大海捞针评估之外，还没有看到令人信服的数据表明模型可以在如此大的上下文进行有效的推理。

如果没有良好的检索和排名，干扰因素可能淹没模型，甚至可能用完全不相关的信息填满了上下文窗口。

最后还有成本问题，ransformer的推理成本随上下文长度二次增长，过度依赖长上下文可能不划算。