如果n值太低，模型可能会过度依赖这些特定示例，影响其泛化能力。一般来说，n应≥5。不要害怕将n值提高到几十次。
示例应代表预期输入的分布。如果你正在构建一个电影摘要生成器，它应该包含不同类型电影的样本，大致比例与你在实践中期望看到的一致。
不一定需要提供完整的输入-输出对。在许多情况下，仅提供期望输出的示例就足够了。
如果使用的LLM支持工具使用，你的n-shot示例也应该使用你希望智能体使用的这些工具。
然后，检查草稿板中的细节是否与会议记录的事实一致。
最后，将关键点综合成简明的摘要。
messages=[{"role":"user","content":"""Extractthe
提取关键决策、行动项目和负责人并形成结构化格式
检查提取的细节与原始转录的一致性
从结构化细节生成简明摘要
反思问题
对公共测试进行推理
生成可能的解决方案
对可能的解决方案进行排名
生成合成测试
在公共和合成测试上迭代解决方案。
一个尽可能详细的明确计划步骤。考虑使用预定义的计划供选择。
将原始用户提示重写为智能体提示。注意，这一过程有信息丢失的风险！
智能体行为可以是线性链、DAG（有向无环图）和状态机；不同的依赖关系和逻辑关系在不同规模下可能更适用或更不适用。你能从不同的任务架构中挤出性能优化吗？
计划验证；你的计划可以包括如何评估其他智能体响应的指示，以确保最终组装协同工作良好。
具有固定上游状态的提示工程——确保你的智能体提示针对可能发生的各种情况进行评估。
生成的计划可以作为少样本示例来提示或微调智能体。
确定性执行使系统更可靠，因此更容易测试和调试。此外，失败可以追溯到计划中的具体步骤。
生成的计划可以表示为DAG，相对于静态提示，更容易理解和适应新情况。
Honeycomb的自然语言查询助手：起初，“编程手册”与n-shot示例都在提示中用于上下文学习。虽然这种方法的效果尚可，但微调后，模型在特定领域语言的语法和规则方面输出得更好。
Rechat的Lucy：LLM需要以一种特定的格式生成答案，需把结构化和非结构化的数据相结合，以便前端能够正确呈现。微调在使其一致工作中有重要的作用。
控制位置偏差：呈现选项的顺序可能会影响LLM的决策。为了减轻这种影响，每次进行成对比较时都要交换顺序。只是在交换后一定要确保将胜利归因给正确的选项！
允许平局：在某些情况下，两个选项可能同样好。因此，允许LLM宣布平局，这样它就不必任意选择一个赢家了。
使用思维链：在给出最终偏好之前，要求LLM解释其决策可以提高评估的可靠性。而额外的好处是，我们可以使用较弱但更快的LLM，并且仍能获得类似的结果。因为这部分在流程中通常处于批处理模式，思维链的额外时延并不是问题。
控制回答长度：LLM倾向于更长的回答。为了减轻这种影响，确保回答对在长度上类似。
用户手动选择正确的产品类别；语言大模型定期检查新产品并在后端纠正错误分类。
用户不选择任何类别；LLM定期在后端分类产品（可能存在错误）。
LLM实时建议产品类别，用户可按需验证和更新。
编码助手：用户可以接受建议（强正反馈）、接受并微调建议（正反馈），或忽略建议（负反馈）。
Midjourney：用户可以选择放大并下载图片（强正反馈）、变更图片（正反馈），或生成一组新图片（负反馈）。
聊天机器人：用户可以对回答点赞（正反馈）或点踩（负反馈），或者如果回答非常糟糕，选择重新生成回答（强负反馈）。
安全性：不产生冒犯性、不适宜工作场所或有害的内容
事实一致性：忠实于所提供的上下文，不虚构信息
实用性：满足用户的实际需求和请求
可扩展性：符合时延服务等级协议，能够支撑的吞吐量
成本：预算有限
其他：安全性、隐私性、公平性、GDPR合规性、DMA合规性等
定义领域特定的测试（从提示自动引导生成）。这些定义为代码断言或以LLM作为评判者。
对齐测试与人类判断的重要性，以便用户可以检查测试是否捕捉到指定的标准。
随着系统（提示等）的变化，对测试进行迭代。
数据科学家：被描述为“在统计学上比任何软件工程师都要出色，在软件工程上又比任何统计学家都要强”。
机器学习工程师（MLE）：从软件工程视角来看待机器学习。
接下来，通过构建系统和数据收集来打好基础。根据数据的类型和规模，可能需要平台工程师或数据工程师。同时，必须有系统能够查询和分析这些数据，以便于调试问题。
最后一步是优化AI系统。这不一定意味着要训练模型。基本工作包括设计指标、构建评估系统、运行实验、优化RAG检索、调试随机系统等。机器学习工程师在这方面非常擅长，不过AI工程师也可以学会这些技能。通常，在完成上述步骤之前，雇佣机器学习工程师是没有意义的。
成功的产品需要深思熟虑的规划以及优先排序，而不是无休止的原型开发或追随最新的模型发布或趋势。在最后一节中，我们将展望未来，探讨构建出色AI产品的战略考量。我们还将探讨团队面临的关键权衡，如何时构建、何时购买，并提出了一份早期LLM应用开发策略的“操作手册”。
要成为出色的产品，需要的不仅仅是对其他API的简单包装。但相反方向的错误可能代价更大。过去一年，大量风险投资，包括令人瞠目的60亿美元A轮融资，被用于训练和定制模型，却没有清晰的产品愿景或目标市场。本节我们将解释为什么立即跳到训练自己的模型是错误的行为，并探讨自托管的作用。
对于大多数组织来说，从头开始预训练一个LLM是不切实际的，它会分散构建产品的注意力。
尽管这听起来很令人兴奋，看起来其他人好像都在做，但开发和维护机器学习基础设施需要大量的资源。其中包括收集数据、训练和评估模型以及部署。如果你仍在验证产品市场契合度，这些将分散开发核心产品的资源。即便你拥有计算能力、数据和技术能力，预训练的LLM也可能在几个月内就过时。
例如BloombergGPT，这是一个专门为金融任务训练的LLM。该模型由四名AI工程师和五名ML产品与研究人员通过预训练3630亿token完成。尽管如此，BloombergGPT在这些任务上仍在一年内被gpt-3.5-turbo和gpt-4超越。
这个故事和其他类似的故事表明，对于大多数实际应用，从头开始预训练一个LLM，即使是在特定领域数据上，也不是资源的最佳利用方式。相反，团队最好是对他们特定需求的最佳开源模型进行微调。
当然也有例外。一个典型的例子是Replit的代码模型，专门为代码生成和理解而训练。通过预训练，Replit能够超越其他更大尺寸的模型，如CodeLlama7b。但随着其他越来越强大的模型发布，维持其实用性需要持续的投资。
对于大多数组织来说，微调更多是出于FOMO（fearofmissingout）而不是清晰的战略思考。
组织在微调上投资过早，试图击败“只是另一种套壳”的指责。但实际上，微调是重型机械活，只有在收集了大量示例并确信其他方法不足时才应部署。
一年前，许多团队告诉我们他们对微调很感兴趣。但很少有人找到产品市场契合度（PMF），大多数人后悔他们的决定。如果你要进行微调，最好非常确信已经准备好随着基础模型的改进而不断地微调——参见下面的“模型不是产品”和“构建LLMOps”。
什么时候微调实际上是正确的选择？如果使用案例需要现有模型训练所用的大规模开放网络数据集中没有的数据——并且如果你已经构建了一个MVP，证明现有模型的不足。但要小心：如果模型构建者无法轻松获得优秀的训练数据，你又从哪里获得？
LLM驱动的应用程序并非是科学展览项目。对它们的投资应该与它们对企业战略目标和竞争差异化的贡献相称。
有了LLMAPI，初创公司就比以往更容易采用和集成语言建模功能，而无需从头开始训练自己的模型。像Anthropic和OpenAI这样的供应商提供通用API，只需几行代码就可以将智能融入你的产品。通过使用这些服务，可以减少所花费的精力，转而专注于为客户创造价值——这使你能够更快地验证想法并迭代PMF。
但就像数据库一样，托管服务并不适合所有使用案例，特别是随着规模和需求的增加。事实上，自托管可能是在不将机密/私有数据发送出你的网络的情况下使用模型的唯一方式，如医疗和金融等受监管行业所要求的，或由合同义务或保密要求所需。
为了在长期内保持竞争优势，你需要超越模型，考虑什么将使你的产品脱颖而出。尽管执行速度很重要，但它不应该是你唯一的优势。
3.2.1模型不是产品，其周围的系统才是
对于不构建模型的团队来说，快速的创新步伐是一大优势，因为他们从一个SOTA模型迁移到下一个，追求上下文大小、推理能力和性价比的提升，以构建更好的产品。这种进步既令人兴奋又可预测。总的来说，这意味着模型可能是系统中最不持久的组件。
相反，应该将你的精力集中在提供持久价值的组件上，如：
评估：可靠地测量任务在不同模型上的性能
防护措施：无论如何，防止模型产生不良输出
缓存：通过避免使用模型来减少时延和成本
数据飞轮：推动上述所有内容的迭代改进
这些组件比原始模型功能创建了更厚的产品质量护城河。
但这并不意味着在应用层构建没有风险。不要将你的精力集中在OpenAI或其他模型供应商需要解决的问题上，如果他们想提供可行的企业软件。
构建一个试图满足所有人需求的产品是不可能的。为了创造引人注目的产品，公司需要专注于构建能够吸引用户反复使用的粘性体验。
例如一个通用的RAG系统，旨在回答用户可能问的任何问题缺乏专业化意味着系统无法优先处理最新信息、解析特定领域的格式或理解特定任务的细微差别。结果，用户得到了一次浅薄、不可靠的体验，无法满足他们的需求，导致用户流失。
为了解决这个问题，需要专注于特定领域和使用案例。通过深入而不是宽泛来缩小范围。这将创建与用户产生共鸣的特定领域工具。专业化还可以让你公开自己系统的能力和限制。清晰地说明系统能做什么、不能做什么，这显示出自我意识，帮助用户理解它在哪些方面可以增加最多的价值，从而建立对输出的信任和信心。
DevOps的根本目的并不是可复现的工作流程、左移策略（即尽早进行测试和安全检查）或给两个小团队赋能——更不是为了编写YAML文件。
DevOps的真正目的是缩短工作与其结果之间的反馈周期，不断改进而不是不断犯错。其根源可以追溯到精益创业运动，通过精益制造和丰田生产系统，强调单分钟换模（SingleMinuteExchangeofDie，SMED）和持续改进（Kaizen）。
MLOps已经将DevOps的形式用于机器学习。我们拥有可复现的实验和一体化的套件，因此赋能模型构建者进行交付。而且，我们有大量的YAML文件。
但是，作为一个单独的行业，MLOps并没有采用DevOps的功能。它没有缩短模型在生产中的推断和交互之间的反馈差距。
我们已经拥有中立的、能众包评估对话和编码模型的互动平台——这是一个多人参与的、迭代改进的外循环。LangSmith、Log10、LangFuse、W&BWeave、HoneyHive等工具不仅承诺收集和整理生产中系统结果的数据，还通过深度集成开发利用这些数据来改进系统。你可以选择使用这些工具或者构建你自己的工具。
大多数成功的企业不是LLM企业。同时，大多数企业有机会通过LLM改进。
这一对观察结果经常误导领导者仓促地为系统加装LLM，增加成本和降低质量，并将它们作为虚假的、装饰性的“AI”功能发布，带有令人厌恶的闪亮图标。我们其实有更好的方法：专注于真正与产品目标一致并增强核心运营的LLM应用。
构建自定义的文本到SQL功能。
构建与文档对话的聊天机器人。
将公司的知识库与客户支持聊天机器人集成。
虽然以上这些是LLM应用的入门项目，但对产品公司而言是没有意义的。对于很多企业来说，这些是一般性问题，从演示到可靠组件之间存在着巨大的差距——这是软件公司的传统领域。将宝贵的研发资源投入当前YCombinator批次正在大量解决的一般性问题上便是一种浪费。
如果这听起来像是陈词滥调的商业建议，那是因为在当前的热潮中，容易误将任何“LLM”视为前沿的、附加的差异化，而忽略了那些已经过时的应用程序。
目前，LLM驱动的应用很脆弱。这些应用需要大量的安全保障和防御性工程，但仍然难以预测。此外，当范围明确时，这些应用可能非常有用。这意味着LLM是加速用户工作流程的优秀工具。
我们可以想象LLM应用完全取代工作流程或担任某个职位职能，这虽然很诱人，但目前最有效的范式还是人机混合（CentaurChess）。当有能力的人类与快速利用的LLM功能相结合时，生产力和完成任务的满意度可以大大提高。LLM的旗舰应用之一，GitHubCoPilot，展示了这些工作流程的力量：
通过以人为中心，询问LLM如何支持他们的工作流程，产品和设计决策会有显著的不同。最终，它将推动你开发出不同于竞争对手的产品，这些竞争对手试图将所有责任迅速转移给LLM；而你的产品将更好、更有用和风险更低。
前几节已经提供了很多技术和建议，有很多需要消化的内容。现在让我们考虑一套最低限度的有用建议：如果一个团队想要构建LLM产品，应该从哪里开始？
在过去的一年里，我们已经看到成功的LLM应用遵循一致的轨迹。在本节中，我们将探索这个基本的“入门”手册。核心思想是从简单开始，只在必要时增加复杂性。一个好的经验法则是，每个复杂度级别通常需要比前一个多一个数量级的努力。考虑到这一点…
提示设计优化是第一步。使用我们在前面战术部分讨论的所有技术。思维链、n-shot示例、结构化输入和输出几乎总是有用的。在尝试从性能较弱的模型中“挤出”性能之前，先使用最强大的模型进行原型设计。
只有当提示设计优化无法达到所需的性能水平时，才应考虑微调。如果存在阻碍使用专有模型并因此需要自托管的非功能性要求（例如，数据隐私、完全控制、成本），这种情况会更频繁地出现。确保这些相同的隐私要求不会阻止你使用用户数据进行微调！
即便是刚刚起步的团队，评估也是不可或缺的。没有评估，我们就无法判断提示工程是否到位，或者定制模型是否能够取代基础模型。
有效评估应针对具体任务，并与预期使用场景相吻合。我们建议首先进行单元测试，这是一种基础的评估方式。通过这种简单的测试，我们可以发现已知或潜在的失败模式，从而帮助我们做出早期的设计决策。此外，针对分类、摘要等不同任务，还有更多特定的评估方法可供参考。
通过人工评估来衡量模型的性能或发现问题
利用标注数据微调模型或改进提示
重复这一过程
3.4低成本认知的高级发展趋势
1971年，施乐帕洛阿尔托研究中心（XeroxPARC）的科学家们预见了未来：一个利用联网的个人电脑而紧密相连的世界，而这正是我们今天所生活的时代。他们不仅预见了这一未来，更通过在关键技术领域的重要贡献——包括以太网、图形渲染、鼠标以及窗口界面等——直接推动了这一未来的实现。
他们还进行了一项基础练习：审视那些极具价值（如视频显示）但在当时成本过高的应用（例如，获取足够的RAM以驱动视频显示需要花费数千美元）。接着，他们分析了这项技术的历史价格走势（类似于摩尔定律），并预测了这些技术将在何时变得经济实惠。
图表：对于固定成本，其能力正迅速提升。对于固定能力水平，其成本正迅速降低。图表由共同作者CharlesFrye使用2024年5月13日的公开数据绘制而成。
自OpenAI的davinci模型作为API发布四年以来，在一百万词元的任务上（约等于本文档的一百倍）运行同等性能的模型，其成本已从20美元骤降至不到10美分——成本减半的周期为六个月。同样，截至2024年5月，无论是通过API服务还是自行部署，运行Meta的LLaMA38B模型每百万词元的成本仅为20美分，其性能与OpenAI的text-davinci-003模型不相上下，后者正是支撑ChatGPT的模型。2023年11月末发布时，text-davinci-003每百万词元的成本约为20美元。在短短18个月内，成本下降了两个数量级，而按照摩尔定律的预测，这一时期内成本本应只减少一倍。
现在，让我们聚焦于一种极具潜力的LLM应用：视频游戏中的角色生成，正如Park等人的研究所示。尽管这项技术非常有用，但其成本曾高达每小时625美元，尚不具备经济性。然而，自2023年8月论文发布后，其成本已经大幅下降至每小时62.50美元，下降了10倍。根据这一下降趋势，我们预计在未来九个月内，其成本将进一步降至每小时6.25美元，将更具经济可行性。
与此同时，回顾1980年《吃豆人》的问世，以今天的货币价值来衡量，1美元足以让你享受数分钟到数十分钟的游戏乐趣——大致相当于每小时能玩六局，即每小时花费6美元。这一计算表明，这种富有吸引力的由LLM增强的游戏体验，有望在2025年变得具有成本效益。
这些趋势虽然是近几年才出现的，但目前并没有明显的迹象表明其会在未来几年内减缓。尽管我们在算法和数据集方面可能已经充分利用了一些容易实现的改进，例如超越了每参数20个词元的“Chinchilla比率”，但数据中心和硅层面更深层次的创新和投资将继续推动这一趋势向前发展。
这可能是最重要的战略洞见：今天看起来完全不可行或者非常前沿的技术，比如一些复杂的演示或研究论文中提出的理论，在几年之内可能会变成现实。鉴于技术的这种发展趋势，我们在构建系统和组织时，应该考虑到这一点。
我们都知道，构建LLM演示非常有趣。只需几行代码、一个向量数据库和一个精心设计的提示，我们就能创造奇迹。在过去的一年里，人们常常将LLM与互联网、智能手机，甚至印刷机相比较。
然而，任何有实际软件发布经验的人都知道，在受控环境中运行的演示和大规模可靠运行的产品存在天壤之别。
以自动驾驶汽车为例。1988年出现了第一辆由神经网络驱动驾驶的汽车，二十五年后，安德烈·卡帕西在Waymo进行了第一次演示乘坐体验。十年后，该公司获得了无人驾驶许可。从原型到商业产品，自动驾驶汽车经历了三十五年严格的工程、测试、改进和监管导航。
过去一年，工业界和学术界见证了语言大模型应用的起起伏伏，这是LLM应用从演示阶段向产品化转型的第一年。我们在评估、提示设计、安全防护等实操技巧中学到了很多，同时也在运营策略、团队构建以及内部能力建设等策略方面积累了宝贵的经验，希望这些经验教训能在你接下来的旅程中提供指导，因为我们将共同在这个令人振奋的新领域中不断探索前进。