将LLMs整合到应用程序中的复杂性和挑战
LLMs整合到应用程序中的复杂性和挑战
计划将一些LLM服务集成到您的代码中吗？在这样做时，您应该期待以下一些常见挑战
在OpenAI发布ChatGPT和GPT API之前，大型语言模型（LLMs）就已经存在了。但是，由于OpenAI的努力，GPT现在对开发人员和非开发人员来说都很容易获得。这次发布无疑在AI的最近复兴中发挥了重要作用。
令人难以置信的是，OpenAI的GPT API在其发布仅六个月内就被广泛接受。几乎每个SaaS服务都以某种方式将其纳入，以提高用户的生产力。
然而，只有那些完成了这些API的设计和集成工作的人，才真正理解其中的复杂性和新的挑战。
在过去的几个月中，我已经实施了几个利用OpenAI的GPT API的功能。在整个过程中，我遇到了几个似乎对于任何使用GPT API或任何其他LLM API的人来说都很常见的挑战。通过在这里列出它们，我希望能帮助工程团队正确准备和设计他们基于LLM的功能。
- 《如何成为数据科学家》一书的9个重要观点（亚当·罗斯·纳尔逊）
- “人工智能将如何影响数据专业人员的角色？”
- ODSC Europe 2023 主题演讲 微软的 Henk Boelman 讲解如何在 Azure 上部署 PyTorch 模型
让我们来看一些典型的障碍。
上下文记忆和上下文限制
这可能是最常见的挑战。LLM输入的上下文是有限的。就在最近，OpenAI为16K个标记发布了上下文支持，而在GPT-4中，上下文限制可以达到32K个标记，相当于几页内容（例如，如果您希望LLM在包含几页内容的大型文档上工作）。但是，在处理多个文档时，每个文档都有数十页时，有很多情况需要更多的内容（想象一下一个需要处理数十份法律文件以使用LLM提取答案的法律技术公司）。
有不同的技术可以克服这个挑战，并且还有其他正在出现的技术，但这意味着您必须自己实施一种或多种这些技术。这又是一项需要实施、测试和维护的工作。
数据丰富
您的基于LLM的功能很可能需要某种专有数据作为输入。无论是作为上下文的一部分输入用户数据，还是使用其他收集的数据或您存储的文档，您都需要一个简单的机制来抽象出从各种数据源中获取数据的调用。
模板化
您提交给LLM的提示将包含硬编码的文本和来自其他数据源的数据。这意味着您将创建一个静态模板，并在运行时动态填充空白处的数据。换句话说，您将为您的提示创建模板，并且可能不止一个。
这意味着您应该使用某种模板化框架，因为您可能不希望您的代码看起来像一堆字符串拼接。
这不是一个很大的挑战，但是另一个需要考虑的任务。
测试和微调
使LLM达到令人满意的准确性水平需要大量的测试（有时只是进行大量的尝试和错误的提示工程）和根据用户反馈进行微调。
当然，还有作为CI的一部分运行的测试来确保所有集成工作正常，但这不是真正的挑战。
当我说测试时，我指的是在沙盒中反复运行提示，以微调结果以提高准确性。
对于测试，您希望有一种方法，测试工程师可以更改模板，使用所需的数据丰富模板，并与LLM一起执行提示，以测试我们是否得到了我们想要的结果。如何建立这样一个测试框架？
此外，我们需要不断根据用户对LLM输出的反馈进行微调模型。如何建立这样的过程？
缓存
LLM模型，例如OpenAI的GPT，有一个参数来控制答案的随机性，使得AI更有创造力。然而，如果您需要处理大规模的请求，您将会产生很高的API调用费用，可能会达到速率限制，并且您的应用性能可能会下降。如果LLM的某些输入在不同的调用中重复出现，您可以考虑缓存答案。例如，您处理了10万次对基于LLM的功能的调用。如果所有这些调用都触发对LLM提供者的API调用，那么成本将会非常高。但是，如果输入重复出现（当您使用模板并使用特定用户字段进行输入时，这种情况可能会发生），那么您可以有很高的机会保存一些经过预处理的LLM输出并从缓存中提供。
在这里的挑战是构建一个缓存机制。实现这一点并不难，只是增加了另一层和需要维护和正确操作的移动部分。
安全和合规性
安全和隐私可能是这个过程中最具挑战性的方面-我们如何确保所创建的过程不会导致数据泄漏，并且如何确保不会泄露个人身份信息（PII）？
此外，您需要审计所有操作，以便可以检查所有操作，确保没有数据泄漏或隐私政策侵犯。
对于依赖第三方服务的任何软件公司来说，这都是一个常见的挑战，也需要在这里解决。
可观测性
与您使用的任何外部API一样，您必须监视其性能。是否有任何错误？处理时间需要多长？我们是否超过或即将超过API的速率限制或阈值？
此外，您将希望记录所有调用，不仅用于安全审计目的，还可以通过对输出进行评分来帮助您微调LLM工作流程或提示。
工作流管理
假设我们开发了一款律师用于提高生产力的法律技术软件。在我们的示例中，我们有一个基于LLM的功能，它从CRM系统中获取客户的详细信息以及正在处理的案件的一般描述，并根据法律先例为律师的查询提供答案。
让我们看看需要完成哪些工作：
- 根据给定的客户ID查找所有客户的详细信息。
- 查找正在处理的当前案件的所有详细信息。
- 使用LLM从正在处理的当前案件中提取相关信息，基于律师的查询。
- 将所有上述信息合并到预定义的问题模板中。
- 使用大量法律案例丰富上下文。（回顾上下文记忆的挑战）
- 让LLM找到与当前案件、客户和律师的查询最匹配的法律先例。
现在，想象一下您有两个或更多具有这样工作流程的功能，最后试着想象一下在您实现这些工作流程后，您的代码会是什么样子。我敢打赌，仅仅考虑这里要做的工作就会让您在椅子上感到不舒服。
为了使您的代码可维护和可读，您需要实现各种抽象层，并且如果您预计将来会有更多工作流程，可能还需要考虑采用或实现某种工作流程管理框架。
最后，这个例子给我们带来了下一个挑战：
代码耦合度高
现在您已经意识到了上述所有挑战和所带来的复杂性，您可能会开始意识到一些需要完成的任务不应该是开发人员的责任。
具体而言，与构建工作流程、测试、微调、监控结果和外部API使用相关的所有任务都可以由更专注于这些任务且其专业不是构建软件的人来完成。我们将这个人称为LLM工程师。
LLM工作流程管理与当前的框架耦合在代码库中。建立这些工作流程的人需要具有软件开发人员和LLM工程师的专业知识。
有多种方式可以进行解耦，比如创建一个专门处理所有工作流程的微服务，但这是另一个需要处理的挑战。
这只是其中一些挑战。
我没有深入讨论如何解决所有这些问题，因为我自己还在努力弄清楚。但可以肯定的是，LangChain似乎是唯一一个在某种程度上解决这些问题的框架，远未解决所有问题，而且似乎朝着正确的方向发展。随着时间的推移，我相信LLM提供商将改进他们的产品，并提供能在一定程度上解决这些挑战的平台。
如果您有其他挑战要分享，请在评论中分享，以造福其他读者。此外，如果您知道任何可以帮助解决这些挑战的工具，请在评论中分享。
希望您觉得本文有启发！如果是这样，请通过掌声和关注我以获取更多关于团队建设、软件工程和技术的文章来表达您的爱。
