在 1950 年的论文“计算机器与智能”中，艾伦·图灵曾说过：“我们只能看到前方一小段距离，但我们能看到那里有很多需要做的事情。”他指的是开发“能够思考的机器”的挑战。
几十年后，我们在“需要做的事情”方面取得了重大进展，我们也能看到更远一点的距离。大型语言模型 (LLM) 是这个故事的最新篇章，也许是迄今为止所有 AI 开发中最引人注目的。公众第一次直接在日常生活中与 AI 模型互动，让更多人能够围绕这项强大技术的全新应用进行构思。
技术进步通常遵循两阶段旅程：发现和应用。在发现阶段，我们探索和理解技术。在应用阶段，我们利用这种理解来解决现实世界的问题。随着 LLM 的出现，我们现在正处于第二阶段。然而，随着我们开发应用程序，保持务实的态度至关重要。与其沉迷于对 AI 的推测性愿景，我们应该专注于现实可行的目标。虽然考虑 AI 的潜力令人鼓舞，但真正的进步源于在现实世界场景中的有效解决方案。通过设定务实的目标，我们可以确保 AI 既令人印象深刻又真正有用。
我最近一直在思考和撰写关于 LLM 的文章，不仅因为它是一个热门话题，而且因为我们能看到前方的那“一小段距离”对于可观察性中的 AI 来说变得越来越清晰。在我的上一篇博文中, 我提到了我们在 Senser 正在构建的两个 LLM 用例。这篇文章重点介绍了其中之一：与数据聊天。
从命令到对话：语音助手与 LLM
在许多方面，像苹果的 Siri、亚马逊的 Alexa 和谷歌助手这样的语音助手传统上都有其局限性。作为用户，您只能使用一组特定的问题或命令，并且必须以特定的方式表达。否则，语音助手会发出一些类似“抱歉，我现在无法找到有关 [主题] 的信息”的回复，或者更糟糕的是，会回复二十秒钟的随机信息，而这些信息并非您所要求的。不要试图纠正它——语音助手不会考虑之前的回复。
相比之下，LLM 可以识别您试图询问的内容背后的意图，即使您没有使用它所期望的相同词语。它们还可以跟踪对话中的上下文，并允许您修改提示或澄清陈述。这些功能带来了更加自然和舒适的沟通方式，更类似于人类彼此之间的沟通方式。难怪语音助手开始实施 LLM！
释放潜力：Senser 中的 AIOps LLM
作为 AIOps 平台，Senser 将 LLM 的引入视为为我们的用户构建新功能的宝贵机会。LLM 很适合解决支持自定义数据库查询的挑战。与其为每个新的客户请求创建自定义查询，我们可以使用 AI（在适当的护栏下）为我们的用户提供更多关于如何与他们的可观察性数据交互的灵活性，同时确保他们始终收到与 API 查询、工作负载、节点等相关的最相关数据。
通常，支持自定义数据库查询需要用户在编写数据库查询方面具有一定的熟练程度，这对 NoSQL 数据库来说并非易事，因为 NoSQL 数据库通常具有独特的组织数据方式。查询构建器和模板可以提供帮助，但它们需要动手支持，并且可能具有限制性或耗时。
不幸的是，解决方案并不像将 LLM 连接到您的 NoSQL 数据库并以自由文本与之交互那样简单。它比这更复杂，但我们将带您了解一个简单、快速且经济高效的解决方案。
两层解决方案：蓝图
在利用 LLM 进行可观察性中的自定义查询时，需要考虑两个主要层。第一层是用户与 LLM 之间的交互。第二层是 LLM 与数据之间的交互。两层都具有高度的复杂性。
第一层：用户与 LLM 聊天
考虑这个看似简单的示例查询：
哪个 API 的错误数量最多？
此查询需要大量上下文。我们不知道它指的是哪个协议，也不知道它指的是哪个命名空间、工作负载、集群、时间范围或错误类型。缺少这些细节会导致 LLM 做出假设，而这是我们想要避免的。LLM 会提示用户填写必要的细节来解决这个问题。例如，它可能会问：“您指的是哪个 API 协议？”或“您能指定此查询的时间范围吗？”
第二层：LLM 与数据库的聊天
LLM 与数据之间的交互需要对 NoSQL 数据库和 LLM 的工作原理有细致的了解。由于 NoSQL 数据库没有预定义的结构，因此无法被不了解数据库结构的人轻松查询。因此，通用的 LLM 无法直接用于此任务。需要进行专门的训练才能有效地协调用户和数据之间的交互。这种训练包括教 LLM 如何解释和将用户查询转换为特定于数据库的查询。
关键考虑因素
当我们着手在 Senser 构建一个有效的自定义查询引擎时，我们首先确定了几个关键考虑因素：
设计简单性：更复杂的设计会导致性能和可靠性问题。我们的目标是保持工程设计简单且健壮。
成本优化：该解决方案需要负担得起，这主要意味着避免导致过度查询商业 LLM 的设计。
性能：快速响应时间至关重要。我们优化了我们的解决方案，以确保快速查询处理，并维护了先前查询的历史记录，以避免第一层中“已解决”的用户问题。必须通过确保将用户的查询转换为有效的 NoSQL 数据库查询来避免幻觉。
将它变为现实：实现细节
为了说明实际方面，让我们深入探讨实现细节：
第一层：用户-LLM 交互
用户与 Senser 聊天功能交互，该功能为 LLM 提供方向和指南。如果查询已得到解答，则聊天会返回答案，而无需咨询 LLM。LLM 会提取新查询的相关信息，以根据提供的指南生成准确的响应。这包括时间范围、实体名称（集群、命名空间、工作负载、Pod 等）、指标或字段、聚合操作（平均值、中位数、最大值、最小值、阈值、限制等）和元数据。如果查询不完整，LLM 会提示用户提供更多信息。例如，如果缺少时间范围，LLM 可能会问：“请指定查询的时间范围。”如果用户提交无效的提示，例如简单的“你好”，LLM 会礼貌地回答，但它也可以“阻止”某些旨在破解系统的一般信息类型。唯一包含任何实质内容的答案是直接回答批准的数据库查询的答案。
第二层：LLM-数据库交互
在幕后，Senser 开发了几个基于查询提取信息的选定生成器。这些生成器将用户的意图转换为特定于数据库的查询。然后运行查询，并将结果解析为人类可读的格式，并在表格中显示。
我们面临的一个挑战是处理时间范围计算。我们希望使用 UNIX 时间格式，这是一种在数据库中表示时间的标准方法。但是，LLM 在对 UNIX 时间进行准确的数学计算方面受到限制。为了克服这个问题，我们要求 LLM 提供与当前时间相差的 [天、小时、分钟]。然后，我们将这些组件转换为 UNIX 标准格式。
描绘未来：更短的距离
从这里我们可以采取几个逻辑方向：
增强聊天历史记录：我们计划增强模型的聊天历史记录，使 LLM 能够提出更复杂的后继问题。例如，如果用户查询过去五天的指标，并希望获得过去十分钟的相同指标，则模型应记住先前的查询详细信息并相应地调整时间范围。
细粒度用户交互：用户应该能够询问特定方向或特定端点上的给定交互的特定 API。
复杂查询：允许更复杂的查询，这些查询涉及多个指标或数据集，可以提供更好的见解。
算法能力：与 LLM 协同工作的 Senser 基于聊天的应用程序可以建议变量之间有趣的交互，或根据提取的数据预测特定指标何时会超过阈值。
我们的目标是通过解决这些挑战并不断改进我们的实现，为用户提供无缝且高效的查询体验。我们的方法简化了与 NoSQL 数据库的交互，并利用 LLM 的强大功能，使可观察性数据更易于访问和操作。
正如艾伦·图灵设想未来将拥有思考机器一样，我们现在正一步步实现这一愿景，大型语言模型（LLM）让我们前所未有地接近理解和利用数据。前方道路越来越清晰，旅程也预示着人工智能和可观测性领域令人兴奋的发展。
