发布文章探讨新兴的大型语言模型 (LLM) 技术和库是一件很有趣的事情，但大部分时间都是在幕后致力于 LLM 解决方案的实施。目前许多组织都在致力于此，所以我想分享一些关于我迄今为止的旅程的简短想法。

原型很容易……生产却很难

制作一个快速演示来展示 LLM 的一些惊人功能是件非常容易的事情，但任何负责将它们展示给用户并希望产生明显影响的人很快就会意识到，要驯服它们需要做很多工作。以下是大多数组织可能需要考虑的一些关键领域。

该列表并不详尽（另请参阅Kadour et al 2023），并且上述哪些适用于您的应用程序当然会有所不同，但即使解决安全性、性能和成本问题也可能是一项艰巨的任务。

那么我们能做些什么呢？

并非所有的大模型语言申请都同样可怕

人们对 LLM 的安全使用非常担忧，而且这是非常正确的。它们接受过人类输出的训练，遭受着人类状况的许多不利方面的困扰，而它们的回答如此令人信服又引发了新的安全问题。然而，风险状况并非在所有情况下都相同，有些应用比其他应用安全得多。要求 LLM 直接从其训练数据中提供答案，比使用 LLM 进行低级技术预测元数据更容易产生幻觉和偏见。这是一个显而易见的区别，但对于任何即将构建 LLM 解决方案的人来说都值得考虑——从低风险应用程序开始是显而易见的第一步，并且可以减少启动所需的工作量。

面向未来，防范炒作

我们生活在一个激动人心的时代，每周都有如此多的人工智能快速进步，但这确实使制定路线图变得困难！去年，供应商发布了几次新的功能、开源模型或 Python 包，这极大地改变了格局。弄清楚要使用哪些技术、框架和模型才能使 LLM 应用程序随着时间的推移保持价值是一项挑战。构建一些非常棒的东西只是为了在未来 6 个月内免费或以极低的成本获得其功能的本地支持是没有意义的。

另一个关键考虑因素是，LLM 是否真的是最适合这份工作的工具。去年的兴奋之情让人很容易被迷惑，对一切都不屑一顾。与任何新技术一样，仅仅为了使用而使用它往往是一个大错误，随着 LLM 炒作的调整，人们可能会发现我们时髦的应用程序在现实世界中已经过时了。

尽管如此，毫无疑问，大模型语言(LLM) 可以提供一些令人难以置信的能力，因此，如果继续前进，以下一些想法可能会有所帮助……

采用“廉价大模型语言优先”政策

在网页设计中，有“移动优先”的概念，即首先开发在功能较少的手机和平板电脑上运行的网页应用程序，然后再研究如何让其在更灵活的桌面浏览器上正常运行。这样做有时比反过来做更容易。类似的想法可以应用于 LLM 应用程序 — — 在可能的情况下，从一开始就尝试开发它们，以便它们可以使用更便宜、更快、更低成本的模型，例如 GPT-3.5-turbo 而不是 GPT-4。这些模型的成本只是一小部分，并且通常会迫使设计过程转向更优雅的解决方案，将问题分解为更简单的部分，而不再依赖单片冗长的提示和昂贵而缓慢的模型。

当然，这并不总是可行的，那些高级 LLM 的存在是有原因的，但许多关键功能可以用功能较弱的 LLM 来支持——简单的意图分类、规划和内存操作。也可能是，精心设计您的工作流程可以开启不同的流程的可能性，其中一些使用功能较弱的 LLM，而另一些使用功能较强的 LLM（我将在以后的博客文章中介绍这一点）。

当那些更高级的 LLM 变得更便宜、更快时，你就可以换出更基本的 LLM，而你的应用程序可能会在很少的努力下发生神奇的改进！

避免使用本机 API，而使用通用接口

尽可能使用通用接口是一种很好的软件工程方法。对于 LLM，这可能意味着使用服务或 Python 模块来提供可以与多个 LLM 提供程序交互的固定接口。一个很好的例子是langchain，它提供与各种 LLM 的集成。通过从一开始就使用 Langchain 与 LLM 通信而不是使用本机 LLM API，我们可以在未来以最小的努力交换不同的模型。

另一个例子是使用autogen作为代理，即使使用OpenAI 助手。这样，当其他本机代理可用时，您的应用程序可以比围绕 OpenAI 的本机实现构建整个流程更容易地进行调整。

代理还是连锁？两者皆可！

LLM 开发的一个常见模式是使用promptflow等框架将工作流分解为一系列条件步骤。链定义明确，因此我们或多或少知道应用程序中会发生什么。它们是一个很好的起点，并且具有高度的透明度和可重复性。但是，它们不能很好地支持边缘情况，而自治 LLM 代理组可以很好地工作，因为它们能够迭代以找到解决方案并从错误中恢复（大多数情况下）。这些问题是 – 至少目前 – 代理由于其迭代性质而可能有点慢，由于使用 LLM 令牌而成本高昂，并且有时有点狂野并失败。不过，它们可能是 LLM应用程序的未来，因此即使现在不在您的应用程序中使用它们，也最好做好准备。通过将工作流构建为模块化链，您实际上就是在这样做！工作流中的各个节点可以交换出来以稍后使用代理，在需要时提供两全其美的效果。

需要注意的是，这种方法存在一些局限性，LLM 响应的流式传输变得更加复杂，但根据您的使用情况，其好处可能会超过这些挑战。

您真的希望您的应用程序即时生成代码吗？

看到自动生成代理和开放人工智能助手生成代码并自动调试以解决任务真是太神奇了，对我来说，这感觉就像未来。它还开辟了令人惊叹的机会，例如 LLM As Tool Maker（LATM，Cai 等 2023），您的应用程序可以生成自己的工具。话虽如此，从我的个人经验来看，到目前为止，代码生成可能有点疯狂。是的，可以优化提示并实现验证框架，但即使生成的代码运行完美，在解决新任务时它是否正确？我遇到过很多不正确的情况，而且通常很难发现——图表上的比例、对数组中错误元素求和以及从 API 中检索稍微错误的数据。我认为随着 LLM 和框架的发展，这种情况会发生变化，但现在，我会非常谨慎地让 LLM 在生产中动态生成代码，而是选择一些人为的审查，至少目前是这样。

从 LLM 增强型申请开始，而不是从 LLM 优先型申请开始

当然，有许多用例绝对需要 LLM。但为了使事情变得更容易，选择 LLM 为流程增加价值而不是成为流程的应用程序可能是有意义的。想象一下一个向用户呈现数据的 Web 应用程序，它已经很有用了。该应用程序可以得到增强，以实现 LLM 改进来查找和汇总该数据。通过稍微减少对使用 LLM 的重视，应用程序就不会那么容易受到 LLM 性能问题的影响。当然，这是显而易见的，但很容易在没有先迈出一小步的情况下深入研究生成式人工智能。

不要忘记……呃……哦是的，记忆！

提示 LLM 会产生成本，并且由于等待响应缓慢而导致用户体验不佳。在许多情况下，提示与之前的提示相似或相同，因此能够记住过去的活动以供重复使用而无需再次调用 LLM 非常有用。存在一些很棒的软件包，例如memgpt和GPTCache，它们使用文档嵌入向量存储来保存“记忆”。这是用于常见RAG 文档检索的相同技术，记忆只是分块文档。略有不同的是，像 memgpt 这样的框架做了一些聪明的事情来使用 LLM 来自我管理记忆。

但是，您可能会发现，由于特定用例，您需要某种形式的自定义内存管理。在这种情况下，无需编写代码即可查看和操作内存记录有时很有用。一个强大的工具是pgvector，它将向量存储功能与 Postgres 关系数据库相结合以进行查询，从而可以轻松理解存储在内存中的元数据。

测试，测试，测试

归根结底，无论您的应用程序是否使用 LLM，它仍然是一个软件应用程序，因此将受益于标准工程技术。一种显而易见的方法是采用测试驱动开发。这对于供应商提供的 LLM 尤其重要，以控制这些 LLM 的性能可能随时间而变化的事实，对于任何生产应用程序，您都需要量化这一点。存在多个验证框架，再次 promptflow 提供了一些简单的验证工具，并在 Microsoft AI Studio 中提供本机支持。还有其他测试框架，重点是从一开始就使用一个框架来为验证打下坚实的基础。

话虽如此，应该注意的是，LLM 不是确定性的，每次都会根据用例提供略有不同的结果。这对测试有一个有趣的影响，因为预期结果并不是一成不变的。例如，测试摘要任务是否按要求工作可能具有挑战性，因为摘要每次都会略有不同。在这些情况下，使用另一个 LLM 来评估应用程序 LLM 的输出通常很有用。可以应用诸如接地性、相关性、连贯性、流畅性、GPT 相似性、ADA 相似性等指标，例如，请参阅Azure AI 工作室的实现。

一旦您拥有一组令人惊叹的测试来确认您的应用程序按预期运行，您就可以将它们合并到 DevOps 管道中，例如在部署应用程序之前在 GitHub 操作中运行它们。

使用第三方工具，节省一些工作

当然，没有一种万能的解决方案，但对于实施 LLM 应用程序的小型组织来说，开发解决方案的每个方面都可能是一个挑战。在使用企业工具处理 LLM 安全等领域时，专注于业务逻辑并与用户密切合作可能比自己开发它们更有意义。例如，Azure AI Studio 有一些很棒的功能，只需单击按钮即可对 LLM 进行各种安全检查，以及通过集成监控和安全功能轻松部署到 API 端点。谷歌等其他供应商也有类似的产品。

当然，这样的功能会产生一些成本，但它可能是值得的，因为开发它们是一项重大的任务。

始终以人为本

LLM 远非完美，即使是最强大的 LLM 也是如此，因此任何使用它们的应用程序都必须有人参与，以确保一切按预期运行。为了使这一点有效，必须记录与 LLM 应用程序的所有交互，并安装监控工具。这当然与任何管理良好的生产应用程序没有什么不同，不同之处在于采用新型监控来捕获性能和安全问题。

人类可以发挥的另一个关键作用是纠正和改进 LLM 应用程序的错误。如上所述，查看应用程序内存的能力会有所帮助，特别是如果人类可以调整内存，与 LLM 一起为最终用户提供最佳体验。将这些修改后的数据反馈到 LLM 微调的快速调整中可以成为改进应用程序的有力工具。

结论

以上想法对于 LLM 的实施并非详尽无遗，也不适用于所有情况，但我希望它们对某些人有用。我们现在都在经历一段奇妙的旅程！