关于“硬事情”的难点：大型语言模型

在人工智能和机器学习的领域中，我们常会被诸如GPT-3.5-涡轮，克劳德或最近的版本GPT-4之类的大型语言模型（LLMs）的承诺所震撼。这些模型在各个行业中提供了变革性的机遇。但是，它们也有它们自己的局限性和特异性。

就在上周，我们针对 GPT 模型进行了深入的快速工程研究，这是一次启发性和具有挑战性的体验。今天我们将深入探讨我们在那次会议以及与这些模型的其他互动过程中发现的限制和挑战，并阐明仍然有待完善的领域。

上下文窗口的限制

LLM具有固有的限制——称为上下文窗口的输入量限制。这个限制包括您的输入、LLM的潜在输出和任何想要注入的辅助数据。这个窗口的大小可以显著影响模型提供连贯和上下文相关回应的能力。因此，尽管LLM可能很强大，但它们的知识和理解受到该窗口的限制。

延迟问题

性能对于任何人工智能应用程序都至关重要，LLM也不例外。尽管商用LLM像GPT-3.5-turbo和Claude是目前最好的模型，但生成有效响应通常需要几秒钟的时间。这种延迟可以从几秒钟到15秒以上不等，取决于模型、自然语言输入、模式大小、模式组合和提示中的说明等因素。虽然GPT-4可用，但对于实时应用程序来说仍然太慢。

许多人提出使用LangChain来链接LLM调用并提高输出的想法。然而，这种方法加剧了延迟问题，并引入了由于“复合概率”而产生的不准确性风险。当然，有办法减少这些风险，但在许多情况下，仍然无法与几乎实时的响应相比。

快速工程的艺术

在没有训练数据的情况下，即兴工程变得至关重要。这是一项技能，用于制定适当的指令集，使LLM能够提供有用的输出。然而，这个领域高度实验性，缺乏建立良好的规则，使它成为LLM利用的“西部荒野”。

正确性 vs. 有用性

有时，过于强调技术上的正确性可能会导致输出不太有用。 LLM必须在解释模糊的输入的微妙领域中导航，以有意义的方式确保模型的可用性，同时不损害输出的完整性。 像“零-shot思维链”提示这样的有前途的技术存在缺点，往往无法生成任何带有模糊输入的查询。

未解决的提示注入问题

当LLM与您的数据库或其他基础设施连接时，您可能面临向其中注入迅速的攻击的风险，类似于SQL注入，但可能更加严重。这可能会无意中授权模型访问敏感数据，呈现出重大的安全风险。

LLM是引擎。

LLM是功能的引擎，而不是产品本身。尽管它们可以增强功能并简化任务，但它们不能替代标准的产品工作或提供完整的解决方案。将LLM误认为产品可能会导致期望不符和不满意的结果。

法律与合规方面

使用LLM需要处理法律和合规问题。从数据隐私到版权问题，您需要确保使用这些模型与现有的法律框架相一致。听起来很简单，但实际情况并非如此，因为这些是未知领域。

早期购买计划的欺骗

早期访问计划（EAP）是各种开发人员和大型公司想要展示与生成式人工智能相关的内容，提供对LLMs新版本所能实现的一瞥的方式。然而，它们无法使您免受上述固有挑战和限制的影响。因此，它们应该被视为探索的机会，而不是明确的解决方案。

定期更新

同样，必须提及定期模型更新和维护的必要性。由于LLM是在静态数据上训练的，因此他们在训练后不会学习或更新知识。因此，为了使其保持最新且有效，需要定期进行模型更新，这需要额外的时间、资源和可能的复杂性。