德国电信如何利用 Qdrant 构建多智能体企业平台

德国电信如何利用 Qdrant 构建可扩展的多智能体企业平台——为欧洲超过 200 万次对话提供支持

Arun Joseph，领导德国电信 AI 能力中心 (AICC) 的工程和架构部门，面临一个严峻的挑战：如何高效且可扩展地在庞大的企业生态系统中部署 AI 驱动的助手？目标是为客户销售和服务运营部署生成式 AI，以在德国电信运营的 10 个欧洲国家/地区更快地解决客户查询。

为了实现这一目标，德国电信开发了 Frag Magenta OneBOT (英：Ask Magenta)，这是一个包含聊天机器人和语音机器人的平台，作为平台即服务 (PaaS) 构建，以确保在德国电信的十个欧洲子公司之间实现可扩展性。

“我们从一开始就知道，如果没有平台优先的方法，我们无法大规模部署 RAG、工具调用和工作流，”Arun 解释道。“当我审视这个挑战时，它更像是一个分布式系统和工程挑战，而不仅仅是一个 AI 问题。”

扩展企业 AI 智能体的关键要求

虽然华丽的 AI 演示很容易构建，但德国电信的团队很快发现，为企业使用扩展 AI 智能体提出了一个更复杂的挑战。“这不仅仅是关于 AI，”Arun 解释道。“这是一个需要严格工程的分布式系统问题。”基于他们在多个地区部署 AI 的经验，他们确定了在生产中扩展 AI 智能体的三个关键挑战

1. 处理租户和内存管理： 跨 10 个不同国家/地区的 AI 工作负载需要严格的数据隔离和合规性。
2. 横向扩展和上下文共享： AI 智能体需要实时处理，同时保持历史上下文，因此高效地存储、检索和大规模处理 AI 生成的上下文至关重要。
3. 非确定性智能体协作： AI 智能体通常表现出不可预测的行为，使得无缝的智能体间通信和工作流编排变得复杂。

“根据我们的经验，这些挑战本质上是分布式系统问题，而不仅仅是 AI 问题，”Arun 解释道。“我们需要反馈循环、状态管理、生命周期编排和智能路由来实现错开部署。仅仅微服务是不够的——我们需要一种领域驱动的 AI 智能体设计方法。”

这一洞察促成了 LMOS 作为开源 Eclipse Foundation 项目的成立。现在，其他公司可以利用 LMOS 进行自己的 AI 智能体开发。

为什么德国电信必须从头重新思考其 AI 栈

团队于 2023 年 6 月开始了小规模的生成式 AI 计划，专注于使用定制 AI 模型的聊天机器人。最初，他们使用 LangChain 和一家主要的向量数据库提供商进行向量搜索和检索，以及一个针对德语用例进行微调的自定义密集通道检索 (DPR) 模型。

然而，随着规模的扩大，这些问题很快出现

• 由于之前提供的组件数量过多，导致内存飙升和操作不稳定
• 复杂的维护要求，频繁的依赖问题，由于缺少内存优化和简化的部署而导致的高操作开销。

尽管努力改进注释和调优，但很明显，这种方法无法为德国电信扩展。

此外，还有强烈需要利用现有的工程资产，因为大多数开发人员和系统已经配备了 SDK 和熟悉的工具。重点从从头开始构建一个全新的堆栈转移到使开发人员能够在他们已经熟悉的工具和框架中构建 AI 智能体。这种方法使得了解 API 和企业系统的领域专家能够快速开发 AI 智能体，而不会干扰现有工作流。

认识到这一点，团队做出了一个大胆的决定：构建一个功能齐全的 AI 智能体 PaaS 平台，简化开发并加速 AI 智能体的部署。

LMOS：德国电信面向企业 AI 的开源多智能体 AI PaaS

认识到 AI 驱动的平台需要深入的工程严谨性，德国电信团队设计了 LMOS（语言模型操作系统）——一个为高可扩展性和模块化 AI 智能体部署而设计的多智能体 PaaS。关键技术决策包括

• 选择 Kotlin 和 JVM 以确保熟悉现有德国电信系统的工程师可以轻松地与 LMOS 集成。
• 放弃预构建框架，转而采用针对德国电信特定需求量身定制的从头开始、高度优化的解决方案。
• 提供类似 Heroku 的体验，工程师无需担心分类器、智能体生命周期、部署模型、监控和横向扩展。
• 企业级但灵活： LMOS 的构建考虑了企业级可扩展性、版本控制和多租户，同时还提供了与其他框架（不仅仅是基于 JVM 的解决方案）集成智能体的灵活性，确保了跨不同 AI 生态系统的互操作性。

“我们的工程师已经了解他们的 API——计费、购物、用户资料。我们为什么要引入只会使堆栈复杂化的新抽象？”Arun 指出，“而且，我设想我们正在构建我称之为智能体计算的基础，在 LLM 之上塑造未来应用程序堆栈中发挥作用。”

LMOS 架构在云原生环境中为 AI 智能体协作和生命周期管理提供支持。

为什么选择 Qdrant？为 LMOS 寻找合适的向量数据库

当德国电信开始寻找可扩展、高性能的向量数据库时，他们最初的选择面临着运营挑战。为了寻找更适合其 PaaS 优先方法和多租户要求的解决方案，他们评估了替代方案，Qdrant 很快脱颖而出。

“我正在寻找背后有深厚技术专长的开源组件，”Arun 回忆道。“我看了 Qdrant，立刻喜欢上了它的简单性、基于 Rust 的效率和内存管理功能。这些人知道他们在做什么。”

团队围绕两个关键指标构建了评估

1. 定性指标：开发人员体验、易用性、内存效率功能。
2. 操作简单性：它如何很好地适应他们的 PaaS 优先方法和多租户要求。

德国电信的工程师还列举了 Qdrant 的几个突出特点，使其成为合适的选择

1. 操作简单——Qdrant 轻量级，不需要过多的组件堆栈。
2. 开发人员体验——库、多语言客户端和跨框架支持使集成无缝。
3. WebUI 和集合可视化——工程师发现 Qdrant 的内置集合可视化工具非常有用。

作为评估的一部分，德国电信工程师比较了多种解决方案，权衡了操作简单性和可靠性。

一位工程师总结了他们的发现：“Qdrant 的组件少得多，而另一个需要 Kafka、Zookeeper，并且只有其索引和查询节点的热备。如果重新扩展，就会停机。Qdrant 保持运行。”

德国电信的 AI 扩展和 LMOS 的未来

如今，带有 Qdrant 的 LMOS 作为德国电信 AI 服务的主干，处理着三个国家超过 200 万次对话。开发一个新智能体所需的时间已从 15 天缩短到仅 2 天。

随着 LMOS 现已成为 Eclipse Foundation 的一部分，德国电信正在向更广泛的 AI 工程社区开放其平台。Arun 预见到一个由志同道合的开发人员围绕 LMOS、Qdrant 和其他 AI 基础设施组件组成的未来生态系统。

“对于希望构建自己的 AI 智能体平台的企业来说，未来不仅仅是关于 AI 模型——它关乎可扩展、开放且有主见的基础设施。而这正是我们所构建的，”Arun Joseph 说道。

您可以在 Arun 在 InfoQ Dev Summit Boston 上的演讲中了解更多关于德国电信的 AI 智能体和 Arun 对 LMOS 的愿景。

观看 Arun 的直播

在本次 Vector Space 演讲中，来自 Qdrant 的 Thierry 和来自德国电信的 Arun 讨论了扩展企业 AI 智能体的关键要求、关键 AI 堆栈考虑因素，以及团队如何构建平台即服务 (PaaS) - LMOS（语言模型操作系统）——一个为高可扩展性和模块化 AI 智能体部署而设计的多智能体 PaaS。