企业宣传,产品推广,广告招商,广告投放联系seowdb

LLM原生开发路线图指南

译者 | 朱先忠

审校 | 重楼

引言

大型语言模型(LLM)正在迅速成为现代人工智能的基石。然而,目前还没有出现公认的最佳实践,而且先驱们往往没有明确的开发路线图。因此,这种状况急需要有人重新发明有关轮子;否则,将会使人陷入困境。

在过去的两年里,我帮助一些组织利用LLM构建了创新型应用程序。通过这次经历,我开发了一种经得住考验的方法来创建创新型LLM应用解决方案(受LLM.org.il社区的启发而形成),我将在本文中与大家共同分享。

具体来说,本文将为读者朋友在LLM原生开发的复杂环境中导航提供一幅清晰的路线图。你将学习如何从构思转变为实验、评估和产品化的全过程,从而有助于释放出你创建开创性应用程序的所有潜力。

为什么标准化流程至关重要

当今,LLM领域是如此充满活力,以至于我们几乎每天都能够听到新的突破性创新。这很令人兴奋,但也让人陷于迷茫——你可能会发现自己在这个过程中迷失了方向,不知道该做什么,或者如何将你的新颖的想法付诸实践。

长话短说,如果你是一位想要有效地构建LLM原生应用程序的人工智能创新者(经理或从业者),本文正是你的选择。

实施标准化流程有助于启动新项目,并提供以下几个关键好处:

LLM工程师的基本技能

与软件研发中的任何其他既定角色不同,LLM原生开发绝对需要一个新角色:LLM工程师或AI工程师。

LLM工程师是一种独特的综合技能成员,涉及不同(既定)角色的技能:

在写这篇文章的时候,LLM工程仍然是全新的,相应的岗位招聘可能非常具有挑战性。因此,企业较早些时间招聘具有后端/数据工程或数据科学背景的候选人可能是个好主意。

软件工程师可能会期待一个更平稳的过渡,因为实验过程更“工程师化”,而不是“科学化”(与传统的数据科学工作相比)。话虽如此,我看到许多数据科学家也在做这种转变。只要你对自己必须接受新的“软技能”这一事实感到满意,那么你就已经走在了正确的道路上!

LLM原生开发的关键要素

与经典的后端应用程序(如CRUD)不同,这里没有循序渐进的开发方案。像“人工智能”中的其他一切一样,LLM原生应用程序需要开发人员具备研究和实验的心态。

要“驯服一头巨兽”,你必须分而治之,把你的工作划分成更小的实验模块,测试其中的一些,最后再选择最有希望的实验组件。

我再怎么强调研究心态的重要性也不为过。这意味着,你可能会花时间探索一项研究内容,发现它“不可能”、“不够好”或“不值得”。这完全没关系——这意味着我们已经走在了正确的道路上。

使用LLM进行实验是构建LLM原生应用程序的唯一方法(并避免前进中的“陷阱”)(使用Dall-E3创建)

拥抱实验——过程的核心

有时,你的“实验”会失败,然后你稍微调整一下你的工作,从而使得另一项实验取得更好的效果。

这正是为什么,在设计最终解决方案之前,我们必须从简单开始,尽可能规避风险。

LLM原生应用程序开发生命周期(图片由作者提供)​

为了很好地实施以实验为导向的过程,我们必须在处理和构建这些实验时做出明智的决定:

精益起步——自下而上的方法

【译者注】精益即“lean”,起源于日本丰田的创作理念。

虽然许多早期采用者很快就进入了具有成熟Langchain或类似功能的“最先进”多链代理系统,但我发现采用“自下而上的方法”通常会产生更好的结果。

开始精益,非常精益,信奉“one prompt to rule them all(一个提示,统治他们所有人)”的哲学吧。尽管这种策略看起来可能是非常规的,而且一开始可能会产生糟糕的结果,但它可以为你的系统打开基础。

从那里开始,然后不断迭代和完善提示,采用提示工程技术来优化结果。当你发现精益解决方案中的弱点时,通过添加分支来解决这些缺点,从而对流程进行拆分。

在设计我的LLM工作流程图或LLM原生架构的每一片“叶子”时,我都会遵循魔幻三角形(The Magic Triangle)原则来确定何时何地修剪树枝、拆分树枝或加厚根部(通过提示工程技术),并挤出更多的柠檬。

自下而上方法示意图(作者图片)​

例如,要用自下而上的方法实现“原生语言SQL查询”,我们可以从以原生方式将模式发送到LLM并要求它生成查询开始。

自下而上的方法示例(图片由作者提供)​

通常,这与“自上而下的方法”并不矛盾,而是在它之前迈出的又一步。这种方案有利于我们能够快速获胜,吸引更多的项目投资。

大局在前:自上而下的战略

“我们知道LLM工作流并不容易,为了实现我们的目标,我们可能最终会采用一些工作流或LLM原生架构。”

自上而下的方法认识到了这一点,并从第一天开始就着手设计LLM原生架构,并探索实现其不同的步骤/链。

通过这种方式,你可以将工作流架构作为一个整体进行测试,并挤压整个“柠檬”,而不是单独精炼每一片“叶子”。

自上而下的方法过程:设计一次架构,然后实现架构并进行测试和测量(作者图片)

例如,为了用自上而下的方法实现“原生语言SQL查询”,我们将在开始编码之前就开始设计体系结构,然后跳到完整的实现:

自上而下方法的一个例子(作者图片)​

找到正确的平衡

当你开始试验LLM时,你可能会从其中一个极端开始(过于复杂的自上而下或超级简单的一次性)。事实上,没有这样的赢家。

理想情况下,在对模型进行编码和实验之前,你将定义一个好的SoP(标准操作流程),并为专家建模。在现实中,建模是非常困难的;有时,你可能无法接触到这样的专家。

我发现从一开始就要确定一个好的架构/SoP很有挑战性,所以在投入使用之前,值得先进行一些尝试。然而,这并不意味着一切都必须过于精简。如果你已经有了一个预先的理解,即某些东西必须被分解成更小的部分——那么就这样做吧。

在任何情况下,在设计解决方案时,你都应该利用“魔幻三角形”原则,正确地对手动流程进行建模。

优化你的解决方案——挤压“柠檬”

在实验阶段,我们不断挤压“柠檬”,增加更多的复杂“层”:

请注意,这可能会增加解决方案的复杂性或损害性能(例如,增加处理的符号数量)。为了缓解这种情况,请使用简洁的提示和较小的模型。

根据经验,当系统提示的显著变化为SOP的这一部分产生更好的结果时,通常最好进行拆分。

LLM实验的剖析

就我个人而言,我更喜欢从一个简单的Jupyter笔记本开始,使用Python、Pydantic和Jinja2:

在更广泛的范围内,你可以使用不同的工具,如​ ​OpenAI流媒体​ ​​来轻松利用流媒体(和工具),​​​在不同的提供商之间拥有标准化的LLM SDK,或​​来服务开源LLM。

通过健全测试和评估确保质量

健全性测试评估项目的质量,并确保项目质量不会低于你预先定义的成功率基准线。

把你的解决方案/提示词库想象成一条毯子——如果你把它拉得太长,它可能会突然无法覆盖它曾经覆盖的一些使用场景。

要做到这一点,可以先定义一组你已经成功覆盖的案例,并确保你保持这种状态(或者至少值得这样做)。将其视为表驱动的​ ​测试​ ​可能会更易于操作。

请注意,评估“生成”解决方案(例如,编写文本)的成功与否比使用LLM执行其他任务(例如分类、实体提取等)要复杂得多。对于这类任务,你可能希望使用更智能的模型(如GPT4、Claude Opus或LLAMA3-70B)来进行评价。

尝试使输出在“生成”输出之前包含“确定性部分”可能也是一个好主意,因为这些类型的输出更容易测试:

cities New York Tel Avivvibes vibrant energetic youthfultarget_audienceage_min age_max gender bothattributes adventurous outgoing culturally curious# ignore the above only show the user the  attrtext Both New York and Tel Aviv buzz  energy offering endless activities nightlife and cultural experiences perfect  young adventurous tourists

当前,已经存在一些尖端的比较有前景的解决方案值得研究。我发现它们在评估基于RAG的解决方案时特别有用:你可以进一步了解​ ​DeepChecks​ ​​、​​​或​​。

做出明智的决策:复盘的重要性

在每个主要的/时间框架的实验或里程碑之后,我们应该停下来,就如何以及是否继续采用这种方法做出明智的决策。

在这一点上,你的实验将有一个明确的成功率基准线,你将知道需要改进什么。

这也是开始讨论该解决方案的产品化含义并从“产品工作”开始的一个好观点:

假设我们达到的基准线“足够好”,并且我们相信我们可以缓解我们提出的问题。在这种情况下,我们将继续投资和改进该项目,同时确保它永远不会降级并使用健全性测试。

从实验到产品:将你的解决方案变为现实

最后,但同样重要的是,我们必须将我们的工作产品化。与任何其他生产级解决方案一样,我们必须实现生产工程概念,如日志记录、监控、依赖关系管理、容器化、缓存等。

这是一个庞大的世界,但幸运的是,我们可以借鉴经典的生产工程中的许多机制,甚至可以采用许多现有的工具。

话虽如此,还需要格外注意LLM原生应用程序的细微差别:

结语:你在推进LLM原生技术方面的作用

这可能是本文的结束,但肯定不是我们工作的结束。LLM原生开发是一个迭代过程,它涵盖了更多的用例、挑战和功能,并不断改进我们的LLM产品。

当你继续你的人工智能开发之旅时,保持敏捷,大胆地进行实验,并牢记最终用户。与社区分享你的经验和见解,我们可以一起推动LLM原生应用程序的发展。不断探索、学习和建设——可能性是无穷的。

我希望本文能够成为你LLM原生开发之旅中的宝贵伴侣!

本文使用缩略语

【1】SoP/SOP:标准操作流程,这是从魔幻三角形文章借鉴的概念。

【2】YAML:我发现使用YAML来构建输出在LLM中效果更好。为什么?我的理论是,它去掉了不相关的标记,表现得很像原生语言。

【3】魔幻三角形(The Magic Triangle):LLM原生开发蓝图;请继续关注,并在它的蓝图发布时关注我已进行阅读。

附:

原文标题:Building LLM Apps: A Clear Step-By-Step Guide,作者:Almog Baku

链接:

译者介绍

朱先忠,社区编辑,专家博客、讲师,潍坊一所高校计算机教师,自由编程界老兵一枚。

© 版权声明
评论 抢沙发
加载中~
每日一言
不怕万人阻挡,只怕自己投降
Not afraid of people blocking, I'm afraid their surrender