如何开发AI大模型原生运用?我用2年,总结了这套方法!

· 生产力指南

作者:Almog Baku

编译:活水智能

 

大模型正迅速成为现代人工智能的基石。

然而,目前尚无成熟的最佳实践,开发者们常常没有明确的路线图,需要重新发明轮子或者陷入困境。

过去两年,我帮助各种组织利用大模型构建应用。通过这些经验,我开发出了一种经过实战检验的方法,用于创造创新解决方案,我将在这篇文章中分享这种方法。

本文将为你提供了一个明确的路线图,为你在复杂的大模型原生开发领域少踩坑。

你将学习如何从想法转向实验、评估和产品化,解锁你创造突破性应用的潜力。

如果想在AI时代成为开发者,开发属于自己的产品,了解技术底层原理,可报名我们的AI编程课:以开发产品为导向而非陷入技术细节、AI辅助编程。

我们过往创建的产品,其中不乏上过AI编程课的新手参与开发 👉 八款产品首次亮相!总有一款适合你

如果你不是开发者,可以借鉴本文提供的思路。

 

先看看一些基本问题

 

为什么要标准化流程

大模型领域发展如此迅速,我们经常听到突破性创新。这非常令人兴奋,但也让人迷失,不知道该做什么,或者如何将你的想法变成产品。

如果你是一位AI创新者(一位开发者或创业者)想要有效地构建大模型原生应用,这就是为你准备的。

采用标准化流程有助于启动新项目,还有以下好处:

  1. 标准化流程 —— 有助于协调团队成员,并确保新成员顺利入职(尤其在这种混乱中)。
  2. 划定里程碑 —— 一个直接的方式来跟踪你的工作,衡量它,并确保你在正确的道路上。
  3. 明确决策点 —— 大模型原生开发充满了未知和"小实验"。明确的决策点能够降低开发分风险,使我们精益求精。

 

大模型工程师的基本技能

与软件研发中的任何其他成熟角色不同,大模型原生开发绝对需要一个新角色:大模型工程师AI工程师

大模型工程师是一种独特的混合体,需要以下技能:

  • 软件工程技能 —— 像大多数SWE一样,大部分工作涉及将乐高积木拼凑在一起,并将所有东西粘合在一起。
  • 研究技能 —— 正确理解大模型原生实验性质至关重要。虽然构建"酷炫的演示应用"相当容易,但从"酷炫的演示"到实用解决方案,需要实验和敏捷性。
  • 商业/产品技能 —— 由于模型的脆弱性,理解商业目标和程序,比坚持我们定义的架构更重要。对大模型工程师来说,能够模拟商业过程是一项黄金技能。

大模型工程师仍然是全新的职业,招聘有经验的人员非常难。寻找具有后端开发/数据工程背景的候选人可能是备选方案。

只要你想转到大模型工程师,你必须拥抱新的软技能,你就在正确的道路上!

 

大模型原生应用开发关键要素

 

与传统的后端应用(如CRUD)不同,这里没有逐步的配方。

就像"AI"中的其他所有事物一样,大模型原生应用需要一种研究和实验的心态。

要驾驭大模型,你必须将你的工作划分为更小的实验,尝试其中的一些,并选择最有前景的实验。

我无法过分强调研究心态的重要性。这意味着你可能会投入时间去探索一个方向,然后发现它"不可能"、"不够好"或"不值得"。

这完全没问题——这意味着你在正确的道路上。

实验是构建大模型原生应用的唯一方式(并避开路上的障碍)。

 

从实验开始

 

有时候,你的"实验"会失败,然后你稍微调整你的工作,其他实验就会取得更好的成功。

这就是为什么在设计最终解决方案前,要从简单开始——风险对冲。

确定"预算"或时间周期。

看看我们可以在X周内做什么,然后决定如何或是否继续。通常,理解基本的PoC需要2-4周就足够了。如果看起来有前景,就继续投入资源去改进它。

实验。

无论你选择自下而上还是自上而下的方法进行你的实验,你的目标都是最大化实验成功率。

在第一次实验结束时,你应该有一些PoC(利益相关者可以玩的)和你达到的基线。

总结实验。

在研究阶段结束时,你可以理解构建这样一个应用的可行性、限制和成本。这有助于你决定是否将其产品化,以及如何设计最终产品、用户体验。

产品化。

开发你的项目的生产就绪版本,并通过遵循标准的SWE最佳实践,实施反馈和数据收集机制,将其与你的其他解决方案集成。

 

broken image

图:大模型原生应用开发生命周期

为了更好地实施以实验为导向的过程,我们要明确如何接近和构建这些实验。

包括自上而下,自下而上两种:

 

自下而上:以精益化方式开始

虽然许多早期采用者很快就跳入了最先进的多链代理系统,配备了全功能的Langchain或类似的东西,但我发现"自下而上的方法"往往能产生更好的结果。

从精简开始,拥抱"一条提示词统治一切"的哲学。虽然这种策略可能看起来不合常规,一开始可能会产生糟糕的结果,但它为你的系统建立了一个基线。

从那里开始,不断迭代和精炼你的提示词,采用提示工程技术来优化结果。当你发现精简解决方案的弱点时,通过添加分支来划分过程,以解决这些不足。

在我设计大模型工作流,或大模型原生架构的每一个"叶子"时,我遵循魔法三角³来确定在何处和何时切断分支,分割它们,或者加厚根部(通过使用提示工程技术)并榨取更多的果汁。

broken image

图 自下而上图解(By Almog Baku)

例如,要用自下而上的方法实现"本地语言SQL查询",我们将从直接把提示发送到大模型,并要求它生成一个查询开始。

这并不与"自上而下的方法"相矛盾,而是在它之前的另一步。这使我们能够快速验证想法,并吸引投资。

broken image

 

图 自下而上开发案例(By Almog Baku)

 

自上而下:一开始就看到全局

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

自上而下的方法认识上面这点,并从一开始设计原生架构时,实施其不同的步骤/链。

这样,你可以整体测试你的工作流架,并不断优化方案,而不是分别精炼每一片叶子。

自上而下的方法过程:想法、一次设计你的架构、实施关键步骤、测试。

broken image

图 自上而下开发流程(By Almog Baku)

例如,要用自上而下的方法实现"本地语言SQL查询",我们将在开始编码之前就设计架构,然后跳到完全实施。

broken image

 

 

图 自上而下开发的例子(By Almog Baku)

 

找到平衡

当你开始用大模型进行实验时,你可能会从两个极端中的一个开始(过于复杂的自上而下或超级简单的一次性)。

实际上,没有一种完全解决方法。

理想情况下——你会定义一个标准化程序,并在编码和实验模型之前建模。实际上,建模非常困难;有时,你可能无法接触到这样的专家。

我发现在第一次尝试时很难找到一个好的架构/标注化流程,所以轻微的实验是值得的。

然而,这并不意味着所有的东西都必须过于精简。如果你已经有一个先验理解,某件事必须被分解成更小的部分——那就这么做。

无论如何,你应该利用魔法三角³的范例,在设计你的解决方案时正确地模拟手动过程。

 

不断优化解决方案

 

在实验阶段,我们不断地优化解决方案,添加更多的"复杂性层次":

  • 提示工程技术:如少样本提示,角色分配,甚至动态少数提示
  • 扩大上下文窗口:从简单的变量信息到复杂的RAG流程,可以帮助改善结果。
  • 尝试不同的模型:不同的模型在不同的任务上表现不同。此外,大型大模型通常并不非常具有成本效益,值得尝试更多的任务特定模型。
  • 压缩流程:缩减流程(如提示和请求的输出)"缩减"通常可以改善延迟。通过减少提示的大小和模型需要经历的步骤,我们可以减少模型需要生成的输入和输出数量。缩减提示节食甚至可以提高质量!请注意,缩减也可能导致质量下降,所以在这样做之前,设置一个健全的测试。
  • 将过程分解为更小的步骤:使优化你的SOP的子过程更容易和可行。请注意,这可能会增加解决方案的复杂性或损害性能(例如,增加处理的令牌数量)。为了减轻这种影响,应该寻求简洁的提示和更小的模型。

按照经验,当系统提示戏剧性变化为SOP¹流程的这一部分带来了更好的结果时,通常是分割的好时机。

 

实验工具

我更喜欢使用Python、Pydantic和Jinja2在一个简单的Jupyter Notebook中开始精简的实验:

  1. 使用Pydantic来定义我的模型输出的模式。
  2. 使用Jinja2编写提示模板。
  3. 定义一个结构化的输出格式(在YAML中)。这将确保模型遵循"思考步骤"并由我的SOP指导。
  4. 通过你的Pydantic验证确保这个输出;如果需要——重试。
  5. 稳定你的工作——将你的代码结构化为Python文件和包。

在更广泛的范围内,你可以使用不同的工具,如openai-streaming轻松利用流式处理(和工具),Lite大模型拥有跨不同提供商的标准化大模型SDK,或者使用开源大模型。

 

通过测试和评估确保质量

理智测试评估你的项目质量,并确保你没有降低你定义的某个成功率基线。

将你的解决方案/提示想象成一条短毯子——如果你拉得太紧,它可能突然无法覆盖它曾经覆盖的一些用例。

为此,定义一组你已经成功覆盖的案例,并确保你保持这种状态(或者至少它是值得的)。将其视为表驱动测试可能会有所帮助。

评估一个"生成性"解决方案(例如,写作文本)的成功比使用大模型进行其他任务(如分类、实体提取等)要复杂得多。

对于这类任务,你可能需要引入一个更智能的模型(如GPT4、Claude Opus或LLAMA3–70B)来充当"裁判"。

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

cities:
- New York
- Tel Aviv
vibes:
- vibrant
- energetic
- youthful
target_audience:
age_min: 18
age_max: 30
gender: both
attributes:
- adventurous
- outgoing
- culturally curious
# ignore the above, only show the user the `text` attr.
text: Both New York and Tel Aviv buzz with energy, offering endless activities, nightlife, and cultural experiences perfect for young, adventurous tourists.

 

复盘里程碑/实验

 

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

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

这也是开始讨论这个解决方案的产品化影响并开始"产品工作"的好时机:

  1. 这将在产品中看起来像什么?
  2. 有什么限制/挑战?你将如何缓解它们?
  3. 你当前的延迟是多少?这足够好吗?
  4. UX应该是什么?你可以使用哪些UI技巧?流式处理能帮助吗?
  5. 对代币的预计支出是多少?我们能否使用更小的模型来减少支出?
  6. 优先级是什么?挑战中的任何一项是否是绊脚石?

假设我们达到的基线是"足够好的",并且我们相信我们可以缓解我们提出的问题。那么,我们将继续投资并改进项目,同时确保它永不退化并使用理智测试。

 

最后,产品化和商业化

 

最后但并不是最不重要的,我们必须将我们的工作产品化。

像任何其他生产级别的解决方案一样,我们必须实现生产工程概念,如日志记录、监控、依赖管理、容器化、缓存等。

这是一个复杂的过程,但幸运的是,我们可以借用许多来自传统生产工程的机制,甚至采用许多现有的工具。

话虽如此,对于涉及大模型原生应用的细微差别,我们需要特别小心:

反馈循环

我们如何衡量成功?它只是一个"点赞/点踩"机制,还是一个更复杂的机制,考虑到我们解决方案的采用?

收集这些数据也很重要;未来,这可以帮助我们重新定义我们的理智"基线",或者使用dynamic-few shots或微调模型来微调我们的结果。

缓存

与传统的SWE不同,当我们在解决方案中涉及生成性方面时,缓存可能会非常具有挑战性。

为了缓解这个问题,探索缓存类似的结果(例如,使用RAG)和/或减少生成性输出(通过有一个严格的输出模式)。

跟踪成本

许多公司发现使用一个"强大的模型"(如GPT-4o)开始是非常诱人的,

然而,在生产中,成本可以迅速上升。避免在最后的账单上被惊讶,并确保测量输入/输出代币并跟踪你的工作流影响(没有这些实践——祝你好运在以后对它进行分析)

可调试性和跟踪

确保你已经使用工具来跟踪一个"有问题的"输入,并在整个过程中跟踪它。

这通常涉及保留用户输入以供后续调查,并设置一个跟踪系统。

记住:"与过渡软件不同,AI会默默失败!"

 

结 语

 

大模型原生应用开发是一个不断迭代的过程,它覆盖了更多的用例、挑战和特性,并不断改进我们的大模型原生产品。

在你继续你的AI开发之旅时,保持敏捷,无畏地实验,并始终将最终用户放在心中。在社区分享你的经验和见解,我们一起推动大模型原生应用的可能性边界。

我希望这篇指南在你的大模型原生开发旅程中是一个有价值的伙伴!

 

如果这篇文章对你有帮助,请关注我们的公众号「活水智能」,用AI提升生产力!

 

联系作者:

email:almog.baku@gmail.com

LinkedIn:@Almog Baku (vi/vim)

 

活水智能成立于北京,致力于通过AI教育、AI软件和社群提高知识工作者生产力。中国AIGC产业联盟理事。

活水现有AI线下工作坊等10+门课程,15+AI软件上线,多款产品在研。知识星球中拥有2600+成员,涵盖大厂程序员、公司高管、律师等各类知识工作者。在北、上、广、深、杭、重庆等地均有线下组织。

公众号:「活水智能」、「AI研究速递」

broken image

 

申明:原文版权归作者所有。本文未经允许,禁止转载,侵权必究