AI应用究竟是什么样的？在构建了几个AI应用之后，现在正适合将其拆解为众多组成部分，并探讨由此带来的运维影响。
我们此前探讨过AI应用有哪些相同之处（很多），又有哪些不同之处（也很多）。AI应用很容易定义为“利用预测式或生成式AI的应用”。
确实如此，但对于必须构建、部署、交付、保护和运维这些新型应用的人员来说，这究竟意味着什么？
首先，这意味着会引入新的动态组件，而且不只是推理服务。向量数据库等其他新组件也正逐渐成为应用架构的标准组成部分。这也意味着会更加依赖API。
此外，这些组件大多采用容器化部署。设置新的AI应用项目时，我会启动一个运行PostgreSQL的容器，将其用作向量数据存储。这是为了支持RAG（检索增强生成）。多份行业报告显示，相当一部分AI应用都在使用RAG（例如Databricks的这份报告）。这是因为，我可以使用任意数据来增强现成的AI模型，而无需自行微调或训练模型。对于相当多的用例，这是实现AI应用的合适方式。
我还可能会启动一个知识图谱，通常是通过运行Neo4J之类的容器化图数据库来实现。图数据库特别适合处理与图结构高度相关的数据，例如社交网络、推荐引擎数据和欺诈检测数据。正如我们年初了解到的，它们还有助于减少策略生成相关的幻觉。引入图数据库可能会让“需要保护的新事物”清单中再增加一种新协议：GraphQL。
接下来，我要决定使用哪种推理服务。可选方案有很多。我可以使用云提供商的服务或AI即服务（例如ChatGPT），也可以运行本地服务。例如，我最近在MacBook上进行实验时使用了Ollama和phi3。在这种情况下，我只运行一个推理服务器实例，因为运行多个实例会消耗超出我现有能力的资源。当然，在生产环境中，可能会部署更多实例，以确保能够满足需求。
由于我打算使用phi3，因此选择phidata作为访问推理服务的框架。在使用颇受欢迎的AI即服务时，我也用过langchain。好消息是，从运维角度来看，该框架并不在核心AI应用本身之外运行。
AI应用的运维影响
我甚至还没写一行代码，就已经有多个组件在运行。每个组件都通过API访问，并在各自的容器中运行。因此，我们首先假定AI应用就是现代应用，同样会面临应用交付、安全和运维方面的常见挑战。也正因如此，我们认为，部署AI模型将大幅增加需要交付和保护的API数量。
AI应用为本已复杂的环境又增加了一个层级，自然会进一步提升复杂性。这意味着AI应用架构将增加从安全、SRE到网络等所有运维职能的负载。每个组件也有各自的扩展特征，也就是说，某些组件需要比其他组件更快地扩展；而且，由于大多数组件使用不同的API，有时还使用不同的协议，请求的分发方式也会有所不同。
此外，AI应用架构的内部差异将非常显著。也就是说，我构建的AI应用与您构建的AI应用很可能具有不同的本地流量特征和需求。异构程度越高，复杂性自然也越高，因为异构与促进同质化的标准化背道而驰。
数十年来，企业一直通过标准化加快向市场交付新功能，提高运营效率，同时释放应对AI应用架构多样性所需的人力资源。
正因如此，我们看到一些共享服务，尤其是应用和API安全服务，正在向边缘迁移，采用安全即服务模式。这类共享服务不仅能更好地保护所有环境（核心、云和边缘）中的工作负载，还能提供一套通用服务，作为各类AI应用的标准。
了解AI应用的构成，不仅有助于确定所需的应用交付和安全服务类型，还能确定需要在何处部署这些服务。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
2023年应用策略现状：成本与复杂性是推动多云网络发展的首要因素
多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联，为解决当今混合IT面临的挑战提供支持，因而备受业界关注。