了解人工智能application架构
人工智能应用到底是什么样的？ 构建了几个之后，似乎是时候将其分解成（许多）部分并探索其操作含义了。
我们之前已经探讨过人工智能应用的相同之处（很多）和不同之处（很多） 。 将 AI应用定义为“利用 AI 的应用（无论是预测性还是生成性）”非常简单。
确实如此，但是对于必须构建、部署、交付、保护和操作这些新型应用的人们来说，这意味着什么呢？
首先，这意味着有新的活动部件。 而不只是推理服务。 还有其他一些新组件正在成为应用架构的标准附加组件，例如矢量数据库。 这也意味着对API的依赖性增加。
事实上，这些组件大多数都是容器化的。 当我建立一个新的 AI应用项目时，我会启动一个运行 PostgreSQL 的容器作为矢量数据存储。 这是为了支持 RAG（检索增强生成），根据多份行业报告（例如Databricks 的这份报告），相当大比例的 AI应用正在使用 RAG。 这是因为我可以使用任何我喜欢的数据来增强库存 AI 模型，而无需自己对模型进行微调或训练。 对于相当多的用例来说，这是实现人工智能应用的最佳方式。
我可能还会启动知识图谱，通常是通过运行像 Neo4J 这样的容器化图形数据库来启动的。 图形数据库在处理图形仿射数据（如社交网络、推荐引擎数据和欺诈检测）时特别有用。 事实证明，它们还有助于减轻与政策制定相关的幻觉，正如我们今年年初了解到的那样。 图形数据库的加入可以将新协议 GraphQL 添加到“需要保护的新事物”列表中。
然后我要决定要使用哪种推理服务。 我有选择。 我可以使用云提供商服务或 AI 即服务（例如 ChatGPT），或者可以运行本地服务。 例如，我最近的修补是在 MacBook 上使用Ollama和phi3 。 在这种情况下，我只运行推理服务器的一个副本，因为运行多个副本会消耗比我拥有的更多的资源。 当然，在生产中可能会有更多的实例来确保它能够满足需求。
因为我将使用 phi3，所以我选择phidata作为访问推理服务的框架。 在利用 AI 即服务时，我也使用了langchain ，这是一个很受欢迎的选择，好消息是，从操作角度来看，该框架并不是在核心 AI应用之外运行的东西。
人工智能applications对运营的影响
我甚至还没有写一行代码，就已经运行了多个组件，每个组件都通过 API 访问并在自己的容器中运行。 这就是为什么我们从人工智能应用是一种现代应用这一前提开始，并带来了交付、安全和操作方面的所有相同的熟悉挑战。 这也是我们相信部署人工智能模型将从根本上增加需要交付和安全的 API 数量的原因。
人工智能应用为本已复杂的环境增加了另一层，这当然增加了复杂性。 这意味着 AI应用架构将增加所有操作功能的负载，从安全性到 SRE 再到网络。 每个组件都有自己的扩展配置文件；也就是说，某些组件需要比其他组件更快地扩展，并且请求的分配方式会有所不同，因为它们中的大多数都利用不同的 API，在某些情况下还利用不同的协议。
此外，AI应用架构内部也将呈现高度可变性。 也就是说，我构建的AI应用很可能与您构建的AI应用表现出不同的本地流量特征和需求。 异质性越大自然意味着复杂性越大，因为它与标准化相反，标准化促进同质化。
几十年来，标准化一直是企业加速向市场推出新功能、提高运营效率的手段，同时释放了解决人工智能应用架构多变性所需的人力资源。
这就是为什么我们看到一些共享服务（特别是应用程序和 API 安全）转向边缘，即安全即服务。 这样的一套共享服务不仅可以更好地保护所有环境（核心、云和边缘）中的工作负载，而且还可以提供一套可作为跨 AI应用标准的通用服务。
了解人工智能应用的结构将有助于确定您所需的应用交付和安全服务的类型，还有助于确定您需要它们的位置。