理解生成式AI时代的AI技术栈

由 Richmond Alake 撰写，MongoDB 的 AI/ML 开发倡导者

注意：本文从生成式AI领域的视角来讨论AI技术栈。“AI技术栈”一词在本文中可以与“GenAI”或“生成式AI技术栈”互换使用。

AI 技术栈结合了集成工具、库和解决方案，以创建具有生成式 AI 能力的应用程序，例如图像和文本生成。AI 技术栈的组件包括编程语言、模型提供商、大型语言模型（LLM）框架、向量数据库、操作数据库、监控和评估工具以及部署解决方案。

AI 堆栈的基础设施组成利用基础模型中的参数化知识和来自信息源（如 PDF、数据库、搜索引擎）的非参数化知识，来执行生成式 AI 功能，例如文本和图像生成、文本摘要、基于大语言模型的聊天界面等。

这篇文章探讨了AI堆栈的每个组件。我的目标是通过阅读本文，您将了解生成式AI应用的当前状态，包括用于开发它们的工具和技术。

你是技术人员吗？太好了。

这篇文章将包括一些你熟悉的工具，并向你介绍AI生态系统中的一些新玩家。

你不是技术人员吗？更好了。

AI 已不再是过去那样令人恐惧的话题。现在，每个业务角色、职能和部门都需要了解 AI 技术栈。请将这篇文章作为你的指南。

本文将涵盖:

• 技术栈的简要概述
• 关于AI层的讨论
• 介绍AI栈及其组件
• AI栈每个组件的详细定义
• 从AI研究到可扩展的现实世界应用的转变
• 开源与闭源模型：选择开源或闭源模型对项目方向、资源分配和伦理考量的影响

“AI 层是现代应用技术栈的一个赋能组件。”

我们可以将技术栈或“tech”栈理解为一系列工具的集合，这些工具在应用程序或系统基础设施的多个层次上进行集成，以促进软件应用的开发和部署。

简单来说，技术栈就是一套能够良好协作的工具组合。

工具和技术在技术栈中被分为不同的层次，这些层次涵盖了应用程序的关注点，例如管理用户界面和体验以及处理数据存储和处理。其他特定层次的关注点包括业务处理逻辑、安全性和层与层之间的通信方法（如 REST、SOAP、GraphQL、WebSockets 等）。

让我们将技术栈分解为各个层次：

• 应用层：这是软件应用的主要部分。它涵盖了用户界面（UI）、用户体验（UX）、前端创建、应用的可访问性等。
• 后端层：也称为“服务器端”，管理应用的大部分逻辑，包括连接数据库、设置应用程序编程接口（API）、应用认证和安全等。
• 数据层：用户和系统与应用交互的所有信息都需要存储，以及任何有助于应用功能的业务数据。数据层包括处理数据存储、检索、备份和管理的工具，这些数据在技术栈中移动。
• 运营层：应用需要部署到生产环境中，在此过程中，维护、更新计划、自动化、管理和优化等考虑因素变得至关重要。这一层的工具和技术属于“开发运营”或“DevOps”范畴。

以上并不是对各层的详尽列表或描述。我们只是希望你对传统的技术栈及其构成有一个大致的了解。随着机器学习、深度学习和人工智能的发展，AI 层已经出现，并且现在在现代应用程序中占据了永久的位置。

AI 层是技术栈中的一个新关键部分。它通过应用层中的描述性（数据可视化）和生成性（图像和文本生成）能力，数据层中的预测分析（行为和趋势），以及操作层中的流程自动化和优化，将智能引入整个技术栈。

即使负责协调用户请求到适当资源的后端层，也通过诸如语义路由等技术从包含AI层中受益。为了完整起见，语义路由是一种根据任务的意义和意图以及接收处理器的配置和特性来分配操作（网络流量、用户请求）的技术。这种方法将用户请求的分配从一个程序化问题转变为由大语言模型（LLMs）外包处理的问题。

AI 层在现代应用程序中的有效性和重要性也减少了应用程序和数据层的角色和职责，这可能会模糊它们之间的界限。

但在这一切中，AI技术栈在软件开发中崭露头角。

在我们定义的生成式人工智能应用的世界中，AI技术栈仍然处于初级阶段，即使在撰写本文时也是如此。这意味着技术栈中的一些部分尚未完全整合为一系列工具、库和框架，这为商业和投资机会打开了大门。同时，技术栈中的其他部分已经发展到有行业最佳实践和领先工具及云服务提供商的程度。

GenAI领域的AI技术栈

AI栈的关键组件包括:

• 编程语言：用于开发栈组件的语言，包括集成代码和AI应用程序的源代码。
• 模型提供商：通过推理端点或其他方式提供基础模型访问权限的组织。嵌入式和基础模型是生成式AI应用程序中常用的模型。
• LLM编排器和框架：通过提供方法和集成包来抽象现代AI应用程序组件集成复杂性的库。这些组件中的操作者还提供了创建、修改和操作提示以及调整LLM以适应不同目的的工具。
• 向量数据库：用于存储向量嵌入的数据存储解决方案。这些组件中的操作者提供了帮助管理、存储和高效搜索向量嵌入的功能。
• 操作数据库：用于存储事务性和操作性数据的数据存储解决方案。
• 监控和评估工具：用于跟踪AI模型性能和可靠性的工具，提供分析和警报以改进AI应用程序。
• 部署解决方案：使AI模型部署变得容易的服务，管理扩展并集成到现有基础设施中。

一个突出的方面可能是对模型提供商的强调，而不是模型本身。这种区分表明，在生成式AI领域，模型提供商的声誉和可靠性往往比他们发布的具体模型更重要。

这个组件的重要因素包括提供商更新模型的能力、提供支持以及参与社区的能力。在使用API推理端点时，切换来自不同提供商的模型只需在代码中更改模型名称即可。

编程语言在AI技术栈中扮演着重要角色，驱动着其他组件的选择，并最终塑造了开发的应用程序。在现代AI应用中，特别是在安全性、延迟和可维护性重要的情况下，编程语言的选择尤为重要。

选择用于AI应用的编程语言是一个涉及几个选项的过程，主要的选择有Python、JavaScript和TypeScript（JavaScript的一个子集）。

毫无疑问，Python 在数据科学家和机器学习及 AI 工程师的语言选择中占据了很大的市场份额。这主要归功于它对数据科学和 AI 库（如 TensorFlow、PyTorch 和 Scikit-learn）的广泛支持，更不用说其语言本身的简单性了。Python 的语法易于阅读，并且可以在面向对象编程（OOP）的方法下灵活地创建简单的单文件脚本和完整的应用程序。

根据2024年2月的PYPL（编程语言流行度指数）更新，Python在PYPL指数中以28.11%的份额领先，反映了其较去年增长了0.6%的趋势。PYPL指数是基于对Google上语言教程搜索的分析，提供了一个数据驱动的视角，来观察哪些编程语言正在获得牵引力。假设一种语言的教程被搜索得越多，这种语言就越受欢迎。

在 PYPL 指数中，JavaScript 位居第三，占比为 8.57%；它在 web 应用开发中的主导地位已经无缝地转移到了 AI 领域。这一点还得到了创建将 AI 功能集成到 web 环境中的库和框架的支持。

这一开发使网页开发者可以直接利用AI基础设施，无需将开发任务外包或让公司雇佣额外人才。LlamaIndex和LangChain是两个广泛使用的LLM/数据框架，用于GenAI应用，它们的库都有Python和JavaScript/TypeScript的实现。

GitHub 的 2023 年开源状态和 AI 的崛起

根据GitHub 2023 年开源状态和 AI 的崛起，JavaScript 仍然是开发者使用的主导编程语言，突显了它在网页开发、框架和库中的广泛应用。在同一报告中，Python 编程语言在 GitHub 上的使用量同比增长了 22.5%；这再次归因于 Python 在各种应用场景中的使用，从网页应用到数据驱动和机器学习系统。

AI技术栈的编程语言组件比其他组件具有更可预测的未来。Python和JavaScript（包括TypeScript）已经在软件工程师、网页开发者、数据科学家、机器学习和AI工程师中确立了它们的地位。

一次 API 调用，你就能拥有一个拥有数十亿参数的强大语言模型。这让我们来到了 AI 堆栈中最重要的组成部分，即模型提供商或模型本身。

模型提供商是提供现成AI模型的组织，无论大小，这些模型包括嵌入模型、微调模型和基础模型，可供集成到生成式AI应用中。

如今的AI领域提供了众多模型，能够实现预测分析、图像生成、文本补全等多种功能。在AI领域中，包括生成式AI在内的模型的可访问性被分为闭源和开源两类。

闭源模型指的是那些内部配置、架构和算法被私有化，不与模型使用者共享的模型。相反，模型的创建者或负责该模型的组织保留了关于模型的关键信息。例如，模型是如何训练的，以及它是在哪些数据上训练的，这些信息都未向公众公开，无法进行审查、修改或使用。闭源模型是通过API（应用程序编程接口）端点或应用程序接口来访问的。

封闭源代码模型的关键在于，不是模型创建者的使用者无法显著改变模型的行为，只能通过诸如API等抽象方式来修改模型创建者公开的部分。封闭源代码模型及其提供者的常见例子包括：

• Claude ，由 Anthropic 提供，可以通过网页聊天界面和 API 访问。
• OpenAI ，提供诸如 GPT-3.5 和 GPT-4 等大型语言模型以及 text-embedding-3-small、text-embedding-3-large 和 text-embedding-ada-002 等嵌入模型，可通过 API 和聊天界面访问。

开源模型的内部架构、网络配置、训练数据、权重、参数等所有内容都是公开的。开源社区及其努力促进了AI社区内的协作和开放性。

讨论与AI模型相关的开源软件框架很复杂，因为存在不同的开源版本。简单来说，开源并不一定意味着完全开放。为了简化起见，这里列出了与AI栈相关的常见开源类型。

• 开源：模型的所有方面，如权重、架构配置、训练数据、训练方法等，都可以不受限制地公开使用。
• 开放权重：仅公开模型的权重和参数供使用。
• 开放模型：模型的权重和参数可以供使用，但需要同意创建者的使用条款。

开源模型带来的机会在于，它使那些之前只有足够资源来训练和开发大规模LLM的公司才能访问的技术，现在变得民主化。开源LLM降低了开发者探索各种用例的门槛，这些用例对于大型公司来说可能过于小众而无法探索。

以下是一些开源大语言模型及其提供商的例子：

• LLaMA 是一个文本生成模型，有数十亿参数的变体。LLaMA 模型家族由 Meta 创建并发布。
• Mixtral -8x7 由 Mistral AI 提供。
• Gemma 由 Google 提供。
• Grok 由 X 提供。

AI 工程师和机器学习从业者经常讨论是否要在他们的 AI 堆栈中使用开源或闭源的大规模语言模型。这一选择至关重要，因为它会影响开发过程、项目的可扩展性、伦理考量以及应用程序的实用性和商业灵活性。

以下是一些AI工程师在选择大型语言模型及其提供商时通常需要考虑的因素。

在检查了计算资源的可用性和团队的专业知识后，通常可以快速确定选择开源或闭源模型。闭源模型提供商通过抽象开发、训练和管理LLM的复杂性，以使用消费者数据作为训练数据或放弃对第三方访问私有数据的控制为代价。

在AI栈中使用闭源模型提供商可以确保更多地关注栈中的其他组件，例如开发直观的用户界面或确保专有数据的数据完整性和质量。开源模型提供了强大的控制和隐私感，但仍需仔细考虑微调、维护和部署开源模型所需的资源。

理解任何AI项目的技术需求对于决定是否使用开源或闭源的LLM至关重要。项目的规模是需要考虑的一个重要因素。AI项目的目标受众或用户有多少？一个大规模的AI项目，如果要为大量用户创造价值，通常会从闭源模型提供商的技术支持和服务保证中受益。

然而，你将自己置于供应商API的运行时间和可用性之上。相比之下，对于没有严格运行时间要求的小规模项目，或者仍处于概念验证阶段的项目，可以考虑尽早使用开源的大规模语言模型。

关于生成式AI与隐私的关系主要集中在与OpenAI、Anthropic等封闭的LLM提供商共享敏感信息和数据上。在生成式AI的时代，专有数据是一种宝贵的资源，而那些拥有大量文本、图像和视频的互联网区域正促使模型提供商同意签署AI数据许可合同。

对于AI从业者而言，是否使用封闭或开源的模型提供商在于获取前沿技术与维护数据隐私和安全之间的微妙平衡。

其他因素包括在选择模型类别时，AI 工程师应考虑伦理和透明度需求、预测准确性、维护成本以及整体基础设施成本。

另一个关于开源与闭源模型的讨论维度是这些模型在任务上的表现。MMLU（大规模多任务语言理解） 是一个基准测试，通过在包括哲学、市场营销、机器学习、天文学等57个不同主题上的测试，评估基础模型在其固有参数知识上的表现。从观察MMLU性能基准中可以得出的见解是，开源社区在创建基础模型方面的努力正在迅速赶上闭源/私有模型提供商的努力。

当然，这些可能会随时发生变化，因为封闭模型提供商的内部活动直到宣布新模型时才公布，这可能会导致显著的性能差距。但同时，很明显，在不久的将来，无论是封闭还是开源的AI模型，其性能都将趋于一致，基于评估标准选择开源与闭源模型的重要性将迅速变得次要。

开源模型与闭源模型性能对比由 Ark Invest 提供

对于利用封闭/私有模型的工程师来说，一个很大的优势是无需投入大量工程资源来部署，因为封闭模型的功能是通过API提供的。而利用开源模型的实践者在下载、修改或微调后，也需要考虑部署方式。

[2023年LLM应用报告：封闭源代码 vs 开源](http://State Of LLM Apps report 2023)

值得注意的是，封闭模型的易集成性促成了它们的广泛采用。Streamlit发布的《2023年LLM应用状态报告》（点击此处查看）显示，基于Streamlit构建的应用程序中，有75%通常使用封闭模型。

然而，像Hugging Face和Ollama这样的公司使得在本地或通过托管服务器运行开源模型变得简单；Hugging Face的推理端点解决方案消除了小型和中型公司在部署和计算可用性方面的任何差距。

像 Fireworks AI 和 TogetherAI 这样的公司，使得访问开源模型变得简单，只需一个 API 调用即可，这与闭源提供商的类似产品类似。在 2024 年及以后，由于这些公司提供的易用性和透明度、自有数据护城河以及成本效益的日益重视，利用开源模型的生产应用程序的采用可能会略有增加。

incumbents也拥抱开源运动。谷歌作为开源生态系统中的一个巨大玩家，定义了一类称为“开源模型”的模型。这些模型指的是其权重和参数公开可用的模型，以及其他模型规格。然而，为了将这些模型用于研究或商业用途，必须同意该组织的服务条款。

此组件在AI栈中充当其他组件之间的桥梁。LLM框架和库，如LlamaIndex、LangChain、Haystack和DSPy，抽象了开发LLM驱动的AI应用程序所涉及的复杂性，例如：

• 将向量数据库与大语言模型（LLM）连接。
• 实现提示工程技术。
• 将多个数据源与向量数据库连接。
• 实现数据索引、分块和摄取过程。

没有 LLM 协调器和框架，AI 应用程序可能会有更多手写的代码，虽然这本身不是有害的，但会分散团队对关键目标的注意力，例如实现产品的核心独特功能或雇佣多名开发人员来实现和维护庞大的代码库。

在承认大型语言模型（LLM）编排器和框架的潜力的同时，也必须指出，这些库并不是万能的解决方案。这些工具通常都有各自的语言库，主要是在Python和JavaScript（TypeScript）中——阅读本文的编程语言部分以了解原因——这些库仍然可以被认为是处于初级阶段。

这个初期阶段带来了它自己的一套挑战，特别是在升级和与现有系统集成方面。撰写本文时，LangChain Python库的版本为0.1.9，而LlamaIndex Python库的版本为0.10。这些版本号反映了几个方面，特别是稳定性和成熟度。

版本 1.0+ 的库通常标志着其开发生命周期中的一个重要里程碑。在为生产级系统选择工具时，工程师们会优先考虑库的稳定性和成熟度。

另一个要点是，AI领域的发展速度很快，这意味着这些工具的新版本会频繁发布。虽然创新当然是受欢迎的，但它可能导致与现有系统之间的兼容性问题。AI团队和组织可能会发现自己需要不断更新导入的库和命名空间，以保持与这些库最新版本的兼容性，这既耗时又耗费资源。

LLM框架已经在AI/生成式AI栈中确立了作为连接工具的地位，使开发人员能够无缝地集成AI栈的其他部分。然而，AI社区中的一些工程师对LLM框架的强势存在有自己的看法。

LLM 框架本质上是抽象层，它们消除了与其它工具集成的实现要求；这对于希望快速投入生产或快速迭代多个想法而无需过多考虑实现细节的团队来说是有益的。

然而，也应承认，由于这些工具在AI开发人员和工程师中广泛使用，这些中间层组件会影响整个栈中其他组件的采用。然而，这种看法可能会很快改变，尤其是在我们探讨当前AI栈的内耗时。

技术栈世界的一个方面是，由于软件工程中的观点和哲学差异，常常会出现分歧。这种分歧在网页开发中体现在Angular和React之间，在机器学习中则体现在TensorFlow和PyTorch之间。这种模式在AI技术栈中也有所体现，比如在DSPy和LangChain框架的实现和方法上。

DSPy（D 声明式 S 自我改进语言 P 程序，p ython 风格）是一个有观点的大型语言模型框架，它将利用和调整大型语言模型在 AI 应用中的过程视为一种程序化和系统化的方法。与依赖特定提示和提示技术的传统方法不同，DSPy 将整个流程模块化，并将提示、微调和其他流程权重整合到一个优化器中，该优化器可以被调整并用作优化流程的目标指标。

以下是使用 DSpy 构建的 RAG 模块化类的示例：

    class RAG(dspy.Module):  
      def __init__(self, num_passages=3):  
        super().__init__()  
        self.retrieve = dspy.Retrieve(k=num_passages)  
        self.generate_answer = dspy.ChainOfThought(GenerateAnswer)  

        def forward(self, question):  
          context = self.retrieve(question).passages  
          prediction = self.generate_answer(context=context, question=question)  
          return dspy.Prediction(context=context, answer=prediction.answer)

LangChain，一个广泛使用的大型语言模型框架，拥有其表达性语言LCEL（LangChain表达性语言），旨在通过声明性实现构建生产就绪、由大型语言模型驱动的AI应用，该实现拥抱模块化和可重用性。LCEL引入的一般方法是链式组合，其中管道的组件或模块可以配置为展示清晰的接口、支持并行化并允许动态配置。

以下是使用LangChain Expressive Language构建的RAG代码片段。

    # 定义聊天提示  
    prompt = ChatPromptTemplate.from_template(template)  
    # 定义用于聊天完成的模型  
    model = ChatOpenAI(temperature=0, openai_api_key=OPENAI_API_KEY)  
    # 将输出解析为字符串  
    parse_output = StrOutputParser()  
    # 简单的RAG链  
    naive_rag_chain = (  
    retrieve  
    | prompt  
    | model  
    | parse_output  
    )

MongoDB: 向量和操作型数据库解决方案

一些现代的人工智能应用需要在其基础设施和技术栈中包含向量数据库。这是因为任务的范围及其在机器学习解决方案中的适用性正在扩大。人工智能应用涉及更复杂的数据类型，如图像、大型文本语料库、音频等，这些都需要高效地存储和检索。一旦嵌入模型处理了原始数据，复杂的数据类型可以被存储为向量嵌入。

向量嵌入是数据的高维数值表示形式——例如图像、音频或文本——它捕捉了原始数据的上下文和语义。

在高维空间中映射大量的向量嵌入并比较它们之间的距离，可以实现基于语义和上下文的相似性搜索。这种能力有助于开发推荐系统、高效的聊天机器人、检索与生成（RAG）应用以及人工智能应用中的个性化服务。

值得注意的是，通过将非结构化数据表示为向量嵌入，数据可以根据语义计算的相似性指标进行搜索和检索，而不仅仅是基于词汇或精确内容匹配。这为现代AI应用引入了基于上下文的搜索的另一个维度。

向量数据库是专门用于高效存储、索引、管理和检索向量嵌入的存储解决方案。这些专门的数据库通过利用高效的索引算法（如HNSW（分层可导航小世界））来优化对高维向量的操作，并计算两个或多个向量之间的距离相似性。向量数据库系统能够快速从包含数千或数百万个向量嵌入的向量空间中进行向量相似性搜索，从而提高AI应用程序用户的功能体验，以及大语言模型的响应准确性和相关性。

AI栈的其他组件必须与向量数据库无缝交互；这一特定考虑影响了选择栈组件的工具、库和框架。

特别是，LLM 调度器和框架的选择可能会受到向量数据库选择的影响，反之亦然。LLM 调度器和框架提供了一系列与流行向量数据库解决方案的集成。

然而，它们的覆盖范围仍需更广泛，才能让AI工程师和开发者放心地确认所选的LLM调度器是否与选定的向量数据库解决方案兼容并支持。MongoDB是一个流行的向量数据库选择，并且在LLM调度器和框架（如LlamaIndex和LangChain）中具有集成和一致的支持。

将向量数据库与操作数据库无缝集成是AI堆栈中的一个关键组成部分。虽然一些供应商仅提供向量数据库解决方案，但现代AI应用程序复杂的存储需求使得将操作数据库纳入AI堆栈和基础设施中变得至关重要。这种必要性源于管理事务性数据交互、确保高效的数据管理和满足实时数据需求等方面的要求。

在AI技术栈中的操作型数据库充当安全存储、高效管理和快速检索所有数据类型的存储系统；这包括元数据、事务数据和操作及用户特定数据。AI技术栈中的操作型数据库应优化速度，以实现数据库服务器与客户端之间的低延迟数据传输；操作型数据库通常考虑的因素包括：

• 高吞吐量。
• 高效的事务性数据操作。
• 可扩展性（包括水平和垂直扩展）。
• 数据流处理能力。
• 数据工作流管理能力。

AI 堆栈需要考虑操作型数据库，当 AI 应用或团队成熟时，数据平台的讨论就开始了。在 AI 应用中，操作型数据库之所以至关重要，原因如下：

• 实时数据处理

• 用户和会话数据管理

• 复杂数据管理

• 基于角色的访问控制和管理

MongoDB 在 AI 技术栈中的位置既是现代应用程序的向量数据库解决方案，也是操作型数据库解决方案，支持实时数据处理、数据流、基于角色的访问控制、数据工作流管理以及当然还包括向量搜索等用例。

AI技术栈的组成应基于简洁性、效率和持久性。如果同时使用两种存储解决方案——一种用于处理向量嵌入，另一种用于其他数据类型——可能会导致数据孤岛，从而增加数据管理和集成的复杂性，可能阻碍数据在技术栈中的顺畅流动，降低整体系统效率。

MongoDB 通过提供一个处理词法和向量搜索以及操作和向量数据的数据平台来解决这些问题。MongoDB 为 Atlas Search 和 Vector Search 工作负载提供了专门的基础设施。了解更多关于此 独特的数据库基础设施设置。

注意：LLM 评估和 LLM 系统评估之间存在细微差别。LLM 评估是基于准确性、理解力、困惑度、偏见、幻觉率等因素评估 LLM 性能的过程。而 LLM 系统评估则是确定集成 LLM 的系统整体性能和有效性的过程。在这种评估场景中，考虑的因素包括操作性能、系统延迟和集成。

监控和可观测性的话题意味着在成熟的人工智能应用从概念验证（POC）和演示阶段过渡到最小可行产品（MVP）和生产环境时需要考虑的问题。使用闭源的大型语言模型（LLM）提供商时，需要特别注意和努力监控推理成本，尤其是对于预期每天为数千名客户提供服务并处理数百万个输入令牌的应用程序。

更重要的是，哪种提示工程技术的组合能从大型语言模型（LLM）中获得高质量的响应，这个问题对于确定为您的应用程序用户创造的价值变得至关重要。从概念验证（POC）到生产应用程序的演变过程中，需要在减少令牌数量和保持生产AI应用程序的LLM输出质量之间进行权衡。

诸如 PromptLayer、Galileo、Arize 和 Weight & Biases 这样的工具正在解决大语言模型（LLM）的可观测性、评估和监控问题。在探讨这些工具之前，让我们先了解一些在探索这一部分AI栈时你应该熟悉的关键词。

如果我们开发、训练并部署大型语言模型（LLM）或其他AI模型到生产环境中，而不需要监控它们的性能或输出，因为它们表现得非常稳定，那该有多好。但现实是，对于任何部署到生产环境中的软件应用程序，即使是简单的计算器应用程序，你也需要某种形式的应用性能和用户交互的监控。

大型语言模型（LLM）系统的可观测性和监控指的是通过方法、实践和工具来捕捉和追踪LLM在输出、延迟、输入、预测过程以及整体行为方面的运营表现。 不难发现，嵌入到应用程序中的LLM已经产生了所谓的"不可控"输出。也许生成式AI输出意外或无法理解内容的数量增加反映了现有厂商在创新和竞争方面的压力。随着生成式AI领域逐渐走出萌芽阶段，这种情况肯定会得到改善。

与此同时……我们最好都系好安全带。

评估是解决大语言模型不可预测行为的下一个最佳方法。

大型语言模型（LLM）的评估是指系统而严格地测试这些模型的性能和可靠性。这一系统过程包括一系列测试，包括但不限于：

• 通过数据集对模型性能进行基准测试，以确保模型输出质量。
• 将模型输出传递给人类，以获取关于输出相关性和连贯性的反馈。
• 对抗性测试以识别模型中的漏洞或防护措施。

在大型语言模型（LLM）中，幻觉既可被视为一个特性，也可被视为一个缺陷。使LLM对用户有价值的生成新颖且上下文相关的功能，也可能因为生成错误或误导性的信息而成为其缺点，从而暴露出设计中的缺陷。减少LLM中的幻觉是当前研究的一个活跃领域。然而，也有努力在系统部署到生产环境之前减轻或至少检测到早期的幻觉。

我发现的一个有趣的大型语言模型基准是LLM Hallucination Index。这个 LLM Hallucination Index 由生成式 AI 应用评估公司 Galileo 的团队创建，通过评估大型语言模型在三种常见任务类型中的响应来应对幻觉问题：

• 问答
• 带有RAG的问答
• 长篇文本生成

幻觉指数定位为一个通过两个关键指标：正确性和上下文粘合度来对LLM幻觉进行排名和评估的框架。

幻觉指数

你有没有注意到现代AI栈的食肉本性？如果没有，你即将看到它的表现。

LLM调度器和数据框架正在抢占LLM监控和评估的市场份额。LangSmith是由LangChain创建的一个平台解决方案，涵盖了从开发到部署和监控的人工智能应用生命周期。LangSmith的总体目标是为开发者提供一个可控、易用且易于理解的界面，用于监控和评估基于LLM系统的输出，包括响应延迟、RAG中使用的源文档数量、流程流向响应结果等指标。

与栈中其他由新玩家和提供商提供的组件不同，部署解决方案提供商大多是已经提供云服务超过十年的现有提供商。这些老牌提供商提供了强大的、可扩展的平台，旨在支持AI和ML模型的部署，包括生成式AI应用。

• Google Vertex AI : 提供了一个端到端的AI模型部署平台，强调易用性，集成了监控和版本控制工具。它支持AutoML和自定义模型，能够快速从训练过渡到可扩展的部署。
• Amazon SageMaker Inference : 支持机器学习模型的轻松和可扩展部署，提供用于实时和批处理处理的托管环境，包括自动扩展和监控功能。
• Microsoft Azure : 提供部署和管理机器学习模型的工具，作为云服务。它确保了可扩展性、安全性、与Azure生态系统无缝集成，并提供了监控工具以保持模型性能。

部署领域并不完全被云服务提供商所主导。以下是一些近年来出现的值得注意的部署提供商：

• Hugging Face: Hugging Face 简化了基于 transformer 的模型的部署，通过其推理端点 API 提供了大量的预训练模型和工具，支持模型版本控制、监控以及轻松集成到应用程序中。
• LangServe: 这是由 LangChain 团队创建的解决方案。它提供了监控、版本控制、自动化文档生成以及通过 API 服务器部署 LLM 应用程序的工具。

许多生成式AI应用程序仍然处于开发、演示或概念验证阶段，这意味着对一个完整的部署平台的需求很小。

这一阶段使得部署LLM应用程序更加简单，特别是当这些应用程序是为了演示目的而展示时。工具如Gradio和Streamlit提供了简单且用户友好的界面，可以使用最少的编码创建LLM应用程序的交互式网络演示。

Gradio 允许开发者快速创建可分享的网页应用，展示其模型的功能，而无需具备专业的网页开发技能。同样，Streamlit 为数据科学家和开发者提供了一条路径，可以将 Python 数据脚本转换为可分享的网页应用。

AI技术栈的各个组件目前处于相互竞争的状态。

与之前的AI重大发展、创新和工具相比，当前的AI栈正在迅速演变。这意味着新的参与者每周都在涌现，随着大型语言模型应用的形式从聊天界面转向基于代理的应用程序，工具如CrewAI、TaskWeaver和Autogen将开始在栈中找到自己的位置。

专注于降低LLM应用程序运营成本的额外工具正在增加开发和使用，随着GenAI应用程序从开发环境转移到生产环境。专注于通过提示压缩减少令牌的库将进入工具栈。

AI栈处于协作模式。

本文列出了几个以某种方式协同工作的工具和库。LLM/AI 框架与数据存储提供商合作，将数据解决方案集成到其框架内的 LLM 应用程序中。模型提供商与 Google 和 Hugging Face 等部署解决方案提供商合作，以方便其模型在 LLM 应用程序中的使用。

组件中的工具和库正在探索提供其他组件中服务的方法。例如，LangChain 是一个 LLM/AI 框架，也通过 LangSmith 和 LangServe 工具提供了监控、可观测性和部署的解决方案。

LlamaIndex，另一个大型语言模型框架提供商，发布了LlamaParse和LlamaCloud。LlamaCloud提供了一种管理数据摄入和检索流程的解决方案，并与旨在分析文档（如包含表格和图片的PDF）以从非结构化数据中提取关键信息的LlamaParse集成。

数据库解决方案提供商很快将寻求方法，使数据摄取和嵌入变得更加容易，进入大型语言模型框架的领域。模型提供商很可能继续增加大型语言模型的上下文窗口，有些人认为这将消除对RAG架构模式的需求。

我认为这个术语是“RAG杀手”。

模型提供商优化的是消费者所发起的API调用次数。然而，当使用按令牌收费的服务时，一个超过一百万的上下文窗口仍然会成为一个非常昂贵的RAG杀手。

我的猜测是我们会看到RAG架构继续存在一段时间。

如果你正在寻找构建下一个酷炫的人工智能项目，可以查看我们的 AI 创新者 计划，获取专家技术建议、免费的 MongoDB Atlas 信用额度以及构建项目的专属支持。我们也非常想听听你正在构建的内容，所以快来加入我们的 生成式 AI 社区论坛!

• 在 LinkedIn 上关注我
• 🔔 在 Medium 上关注并订阅 MongoDB：关注 | 订阅

本文最初发布于 MongoDB 博客。

1. 什么是AI栈？ AI栈，特别是生成式AI（GenAI）栈，指的是用于创建具有生成式AI能力的应用程序的一系列工具、库和解决方案的综合组合。AI栈的组件包括编程语言、模型提供商、LLM框架、向量数据库、操作数据库、监控和评估工具以及部署解决方案。

2. 选择开源和闭源模型对我的AI项目有何影响？ 选择会影响项目的开发过程、可扩展性、伦理考量以及商业灵活性。资源可用性、项目需求、成本和隐私考量等因素将决定开源或闭源模型是否更适合您的需求。开源模型提供透明度和社区协作，而闭源模型则通过API提供强大的AI功能，但控制权更有限。

3. 编程语言在AI栈中扮演什么角色？ 编程语言在确定栈组件的选择和开发应用程序的整体架构方面起着关键作用。Python、JavaScript和TypeScript是主要选择，因为它们支持广泛的AI和数据科学库，并且具有灵活性和可读性。

4. LLM框架如何简化AI应用程序的开发？ LLM框架，如LlamaIndex和LangChain，抽象了创建LLM驱动的AI应用程序所涉及的复杂开发过程。它们促进了向量数据库和LLM之间的连接，实现了提示工程技术，并管理数据索引和摄取，从而减少了大量编码的需求。

5. 为什么MongoDB是AI应用程序的流行选择？ MongoDB是一个开发者数据平台，管理和存储向量和操作数据。它提供了强大的数据管理和搜索功能。MongoDB支持现代AI应用程序的实时处理需求，高效处理非结构化数据，并且与LLM编排器和框架集成良好。