大型语言模型正在通过数据对话方式改变AIOps

在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构建有效的自定义查询引擎时，首先确定了几个关键考虑因素：

1. 设计简单性：复杂的设计会导致性能和可靠性问题。目标是把工程方案设计得简单且健壮。
2. 成本优化：解决方案必须负担得起，主要意味着避免过度查询商业LLM的设计。
3. 性能：快速响应时间至关重要。优化方案以确保快速查询处理，并维护先前查询的历史记录，避免第一层中“已解决”的问题重复询问。同时要通过确保用户查询被正确转换为有效的NoSQL查询来防止幻觉。

将它变为现实：实现细节

为了说明实际方面，来看看具体的实现细节：

第一层：用户-LLM交互

用户通过Senser的聊天功能与LLM交互，该功能为LLM提供方向和指南。如果某个查询已经解答过，聊天功能会直接返回答案，无需咨询LLM。对于新查询，LLM会提取相关信息（时间范围、实体名称、指标或字段、聚合操作、元数据等），根据指南生成准确响应。如果查询不完整，LLM会提示用户补充信息。比如缺少时间范围时，LLM会问：“请指定查询的时间范围。”如果用户提交无效提示（例如简单的“你好”），LLM会礼貌回应，但也会“阻止”某些试图破解系统的一般信息。唯一包含实质内容的答案是直接回答经过批准的数据库查询的答案。

第二层：LLM-数据库交互

在幕后，Senser开发了几个基于查询提取信息的选定生成器。这些生成器将用户意图转换为特定于数据库的查询，然后执行查询，将结果解析乘人类可读的格式并在表格中显示。

一个挑战是处理时间范围计算。我们希望使用UNIX时间格式——数据库中表示时间的标准方式。但LLM在UNIX时间上进行准确数学计算的能力有限。为此，我们要求LLM提供与当前时间相差的[天、小时、分钟]，然后由系统将这些组件转换为UNIX标准格式。

描绘未来：更短的距离

从这里我们可以向几个逻辑方向推进：

1. 增强聊天历史记录：计划增强模型的聊天历史，使LLM能提出更复杂的后继问题。例如，用户先查询过去五天的指标，接着想获取过去十分钟的同样指标，模型应记住先前的查询细节并自动调整时间范围。
2. 细粒度用户交互：用户应能针对特定方向、特定端点或给定交互的API进行询问。
3. 复杂查询：允许更复杂的查询，涉及多个指标或数据集，从而提供更深入的洞察。
4. 算法能力：与LLM协同工作的Senser聊天应用可以建议变量之间有趣的交互，或根据提取的数据预测特定指标何时会超过阈值。

目标是通过解决这些挑战并持续改进实现，为用户提供无缝且高效的查询体验。这一方法简化了与NoSQL数据库的交互，并借力LLM使可观测性数据更易于访问和操作。

正如艾伦·图灵当年设想的思考机器，如今我们正一步步靠近那个愿景。大型语言模型让我们前所未有地接近理解和利用数据。前方的道路越来越清晰，人工智能与可观测性的交汇处，正孕育着令人兴奋的进展。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：大型语言模型正在通过数据对话方式改变AIOps要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题