有很多关于人工智能的炒作，特别是大型语言模型（LLMs）。直截了当地说，这些炒作只是一些演示性的废话，一旦有人试图将其用于他们工作所依赖的真正的任务，就会被推翻。
现实远没有那么光鲜亮丽：在LLM的支持下很难建立一个真正的产品。
下面是我对我们在建立“查询助手”时面临的所有挑战的阐述。并非所有这些都适用于你的用例，但如果你想用LLM构建产品功能，希望这能让你看到你将不可避免地经历什么。
上下文窗口是一个挑战，没有完整的解决方案
我们在提示LLM时使用了 "需要产生查询的模式"。不幸的是，这一点并不随便。
LLM对能接受的输入量有一个限制：这个限制，称为上下文窗口，包括所有的东西：你的输入、LLM的所有可能的输出，以及你想传递给它的任何数据。
因为我们让每个人都能使用“查询助手”，所以我们需要有一种方法来处理比上下文窗口更大的上下文。有些客户的模式有超过5000个独特的字段，而我们没有办法预先知道哪个子集是要选择的 "正确 "子集。所以我们考虑了几种方法：
- 对有 "大模式 "的客户关闭该功能，或者至少只对这些模式关闭该功能。
- 将一个大的模式分块，并对具有某种 "相关性分数 "概念的LLM进行N次并发调用，选择最好的一个，并希望各块之间的界限不会忽略关键信息
- 通过反复建立和完善一个模式子集的查询来连锁调用LLM，希望在连续调用N次后，最终能得到一些相关信息
- 使用嵌入，并向点乘之神祈祷，无论你用什么距离函数从嵌入中提取一个 "相关子集"，都是真的相关。
- 寻找其他方法来创造性地拉出一个模式的子集
我们决定寻找其他方法来发挥创意，尽管我们在不久的将来可能会使用Embeddings。
事实证明，过去人们一般不使用Honeycomb来查询数据。事实上，当你限制一个模式只包括在过去七天内收到数据的字段时，你可以削减一个模式的大小，通常可以把整个东西放在gpt-3.5-turbo的上下文窗口中。
然而，对于一些客户来说，即使通过时间来约束模式也是不够的。在某些情况下，我们仍然需要截断我们使用的字段的数量，这导致了一种不成功的体验，这取决于模式中最相关的字段是否被截断了。我们正在研究用Embeddings来帮助点积神的正确祈祷，因为它似乎是最可行的替代方法。剧透一下：点积之神并不总是正确的，所以我们可能要在prod中测试这个问题，看看它在更广泛地激活时是否是一个整体的改进。
在具有非常大的上下文窗口的模型中，有很好的进步。然而，在我们对克劳德10万的实验中，如果我们把一个完整的模式倒入我们的提示中，它的速度会慢好几倍，而且它比我们使用嵌入来提取一个更小的、更相关的字段子集更经常出现幻觉。也许这个问题会在一段时间内得到解决，但是现在，还没有一个完整的解决方案来解决上下文窗口的问题。
LLMs的速度很慢，串联他们是一个不可能的事情
像gpt-3.5-turbo和Claude这样的商业LLM是我们现在使用的最好的模型。开源世界中没有任何东西能接近。然而，这只意味着它们是现有选项中最好的。它们产生一个有效的Honeycomb查询需要很多秒，延迟时间从2秒到15秒以上，取决于模型、自然语言输入、模式的大小、模式的构成以及提示中的指示。截至目前，虽然我们可以访问gpt-4的API，但它太慢了，无法满足我们的使用需求。
如果你在谷歌上搜索一下，你会发现有人在谈论使用LangChain来串联LLM调用，以获得更好的输出。然而，对LLM的连锁调用只会使LLM的延迟问题变得更糟，这对我们来说是不可能的。但即使不是这样，我们也有可能被复合概率咬住。
让我们想象一下，一个LLM和提示对90%的输入都能产生有效的蜂巢式查询。那是相当好的!然而，如果你需要把对该LLM的调用连在一起，那么就有可能导致准确性降低，因为......数学。一个90%的准确率的过程重复5次是（0.9*0.9*0.9*0.9*0.9），或者0.59，59%的准确率。哎哟。幸运的是，有一些方法可以缓解和改善这个过程，通过调整你连在一起的提示，在实践中，它不会导致准确性的急剧下降。
我们发现，在将LLM调用链在一起时，生成蜂窝状查询的能力没有明显的改善。关于这个概念的书还没有完全关闭，但这里有一个警告：LangChain不会解决你生活中的所有问题。
提示工程很奇怪，没有什么最佳实践
如前所述，查询助手目前的工作方式是通过提示工程。提示工程是让ML模型为你做有用的事情的艺术和科学，而不需要在特定的数据和/或预期的输出上训练它。事情是这样的：这是个他妈的疯狂的西部。看看链接中的所有技术，看看人们在提示方面尝试了哪些疯狂而有趣的东西。下面是我们尝试的一些东西：
- Zero-shot提示：没有作用
- 单次提示：有效，但效果不佳
- 有例子的几张照片提示：似乎效果不错
- "让我们一步一步地思考 "黑客：对于比较模糊的输入，不太可能产生疑问
- 思考链提示：不清楚；没有足够的时间来验证
通过结合一些现有的新兴提示技术，我们可以对我们的提示进行改进。然而，我们想快速提供一些东西，而实验提示是一个耗时的过程。对我们来说，很难评估一个提示的有效性，因为我们有一个有趣的约束条件，即对广泛的输入要正确和有用。
正确性和实用性可能有矛盾
早些时候，我说过，我们使用LLM来产生一个Honeycomb查询。这个查询需要正确才能使用，但这并不是全部。除了产生一个正确的查询之外，我们还必须能够做两件事：
- 接受来自用户的广泛的、可能是模糊的输入
- 根据我们对Honeycomb某些行为的了解，产生一个 "有帮助 "的查询。
正如我们从产品运输中了解到的那样，我们的用户输入了你能想象到的所有可能的东西。我们得到的查询是非常具体的，人们或多或少地用英文输入了一个完整的Honeycomb查询，甚至使用了我们用户界面中的术语。我们也会收到一些查询，字面意思是 "慢"，没有其他意思。
显然，没有任何提示+LLM的组合可以为所有可能的输入产生一个蜂巢式查询，尤其是当这些输入非常模糊的时候（我们到底应该如何解释慢？）然而，对我们来说，迂腐是无益的。我们认为模糊的东西对使用该工具的人来说可能并不模糊，而我们的假设是，显示一些东西比什么都不显示要好。因此，我们的提示需要与可能没有什么意义的输入一起工作。
支持非常广泛的输入是一个领域，在这个领域中，一个所谓的提示技术的改进，即零次思维链提示，似乎使LLM的行为变得 "更糟"。在测试中，当输入很模糊时，零点思维链提示可靠地未能产生一个查询。根据我们所掌握的关于人们向查询助手提问的数据，使用这个方法是一个错误，因为我们得到了很多模糊的输入。
此外，按照别人的要求去做并不总是正确的事情。
例如，我们知道，当你使用AVG()或P90()这样的聚合时，其结果隐藏了一个完整的数值分布。我们已经无数次地发现，虽然聚合可以显示一般的趋势，但它们隐藏了完整的数值分布，这意味着你很容易错过系统中的问题，而这些问题在以后会变成更大的问题。在这种情况下，你通常希望将聚合与HEATMAP()可视化配对。
不幸的是，接受广泛的输入并需要在输出上应用某种形式的 "最佳实践"，这确实给及时的工程努力带来了麻烦。我们发现，如果我们试验一种方法，它就会以接受不那么广泛的输入为代价来改善输出，反之亦然。我们还有很多工作可以做，以改善我们的提示，但现在没有明显的游戏手册可以使用。
提示性注入是一个未解决的问题
如果你不熟悉提示性注入，请阅读这篇解释它的令人难以置信（也很可怕）的博文。它有点像SQL注入，只是更糟糕，而且现在还没有解决方案。当你把LLM连接到你的数据库或你的产品中的其他组件时，你就把你的产品（和基础设施）的所有这些部分暴露在即时注入中。我们采取了以下步骤，我们认为可以帮助：
- 我们的LLM调用的输出是非破坏性的，而且是不可逆转的
- 没有人因为我们的LLM调用的输出而被分页
- LLM没有连接到我们的数据库或任何其他服务
- 我们将 LLM 的输出解析为特定格式，并对其进行验证
- 由于没有聊天用户界面，我们就很难 "实验 "出提示性的注入输入，并看看会有什么输出。
- 我们的输入文本框和允许的输出被截断了
- 我们对每个用户每天都有速率限制
如果有人有足够的动机，这些都不能阻止他们让我们的系统做一些古怪的事情。这就是为什么我们认为最重要的事情是，我们今天用LLM所做的一切都是非破坏性的、可撤销的，而且不触及用户数据。这也是为什么我们目前没有探索一个人们可以互动的完整的聊天界面，而且我们绝对不希望让一个由LLM驱动的代理坐在我们的基础设施中做任务。我们不希望有一个终端用户可重新编程的系统，在我们的基础设施中运行一个流氓代理，谢谢你。
而且，就其价值而言，是的，今天人们已经在尝试在我们的系统中进行提示性注入。几乎所有的都是愚蠢的/无害的，但我们已经看到几个人试图从我们的系统中提取其他客户的信息。谢天谢地，我们的LLM调用与这种东西没有联系。
LLMs不是产品
现在有很多 "产品 "只是对OpenAI的完成度API的一个薄薄的包装，并带有赤裸裸的 "背景 "或 "记忆"（通常通过Embeddings）的程度。随着ChatGPT、Bard和Bing变得更好，并增加了一个强大的生态系统，这些都可能在今年年底前消失。除非你真的从事销售LLM的业务，否则LLM并不是一个产品！它是一个功能的引擎！它是一个功能的引擎。
通过把LLM当作创建Honeycomb查询的引擎，我们把工作重点从主要向用户提供LLM界面转移到了扩展我们的产品用户界面。创建 "HoneycombGPT "并以Honeycomb查询作为其唯一的功能（无提示注入）来运送一个蹩脚的ChatGPT版本可能会更便宜，但我们认为这对大多数人来说是没有吸引力和错误的界面。
构建查询助手的大部分工作与大多数产品工作没有什么不同：设计和设计验证，确定事情的范围（在这种情况下，非常积极地满足一个月的最后期限），根据开发中发现的路障做出决定，以及大量的狗粮和尽可能多的外部验证经验。不要把LLM误认为是一种产品，也不要认为它可以取代标准的产品工作。
LLM迫使你解决法律和合规问题
你不能只是在你的产品中加入一些对OpenAI的API调用，然后发货给客户，如果你有超过一小部分的客户，你就可以指望这样做了。有些客户非常注重隐私，不希望他们的数据，即使只是元数据，被卷入机器学习模型中。有些客户在合同上有义务关注隐私（比如处理医疗数据的客户），无论他们对LLM的看法如何，都需要确保这些数据不被泄露。还有一些客户，作为企业交易的一部分，签署了特定的服务协议。
我们做了一些事情：
- 对LLM供应商进行全面的安全和合规性审计。剧透一下：目前只有OpenAI可以满足我们的要求。赞扬他们建立了一个强大的服务!
- 起草新的条款和条件，详细说明我们向OpenAI发送哪些数据，我们对发送的数据或收到的数据不做任何要求，我们不保证特定的结果/成果等。
- 弄清楚我们的整体服务条款中有哪些（如果有的话）需要修改，这些条款自2021年以来一直没有更新。
- 确保这些条款和条件可以在用户界面本身中获得。
- 确保有简单而明显的控制措施来完全关闭该功能
- 标记出任何与我们签署BAA的客户。虽然OpenAI的平台控制可能会满足每个协议的要求，但我们需要与每个客户逐一合作，而且我们不想耽误我们的初始发布。
在一个较长的时间表下，这些都不会是特别的或具有挑战性的，但我们必须在一个月内与所有其他产品、工程和上市工作一起完成。你可能会认为为最初的发布做这种事情是不必要的，但如果你关心保持你的客户的信任和快乐，它就是。
总结
抢先体验版本也无法使您摆脱我在本文中谈到的问题，除非您的“早期访问计划”非常广泛，以至于您实际上拥有大量具有代表性的用户样本，否则您将要做的就是自欺欺人地认为您的产品对大多数用户输入都表现良好。
现实情况是，这项技术是很难的。LLMs不是魔术，你不会用它来解决世界上所有的问题，你越是推迟向所有人发布你的产品，你就越是落后于曲线。这里没有正确的答案。只有大量的工作，用户会用他们破坏你所建立的东西的方式让你大吃一惊，以及一大堆最先进的机器学习给你的全新问题，因为你决定使用它。