大模型应用的10个架构挑战

引\] 在英国，时差有点乱。拾起年初的文字，迎接新春大吉！ ChatGPT从正式发布到拥有1亿用户仅仅用了5天的时间，基于大型语言模型（简称大模型，或基础模型）的应用给软件行业乃至整个社会带来巨大的影响。作为一名软件系统的架构师，除了传统的软件系统质量属性约束之外，还要面对由于大模型应用的自身特点所带来的新约束，面对更多的权衡，也面临着更多的挑战。  基于笔者近年来的探索与实践，这里列举了面向大模型应用系统架构设计的10个挑战。 ### 1. 生产环境的挑战------推理框架的选择 对于大模型应用而言，生成环境的运行时是一个推理架构。自主研发一个推理架构需要的投入较大，而且需要专业人才，并不是每个企业都能够做到的。这是第一架构挑战，选择哪一种现有的推理框架呢？ 当批量提示词的交付需要最大速度时，或许适合使用 vLLM。如果需要本地 HuggingFace 支持，并且不打算为核心模型使用多个适配器，或许TGI是个不错的选择。如果速度成为第一约束，并且计划在 CPU 上运行推理，需要考虑 CTranslate2。如果希望将适配器连接到核心模型并利用 HuggingFace Agent， OpenLLM或许是个不错的选择，特别是不仅仅依赖于 PyTorch 的情况。对于希望相对成熟的项目，需要实现稳定的流水线和灵活的部署，可以考虑使用 Ray Serve。如果在客户端(边缘计算)本机部署 LLM，例如，在 Android 或 iPhone 平台上， MLC LLM会纳入考量的范围。如果已经有使用 DeepSpeed-MII 库的经验并且希望继续使用它来部署 LLM， DeepSpeed-MII就成为了优选。 架构的核心在于权衡，推理框架的选择同样是一个架构权衡的过程，没有最好，需要关注合适于目标需求的推理框架 ### 2. 数据依赖挑战------ 数据流水线的构建 数据是LLM开发的支柱，面向数据的有效管理对于开发准确可靠的大模型应用至关重要。尤其是在需要对大模型进行微调或者蒸馏的时候，在构建数据流水线时一些关键考虑因素包括： * 准备和清洗数据：准备和清洗数据涉及将原始数据转换成可用于LLM训练和推理的格式。这包括数据归一化、特征工程和数据增强等任务。 * 确保数据质量和一致性：确保数据高质量和一致性对于开发准确的LLM模型至关重要。这涉及数据验证和质量控制措施，如异常值检测和数据分析。 * 管理数据隐私和合规性：在处理敏感或个人数据时，数据隐私和合规性是必要的考虑因素。这包括实施数据安全措施，如加密和访问控制，并遵守数据隐私法规，例如GDPR和《个保法》。 有效的数据管理需要数据科学家、工程师和利益相关者之间的协作，以确保数据清洁、可靠和合规的数据采集。投资于数据流水线的建设可以帮助简化数据准备和验证任务，并提高LLM模型的质量。在需要对大模型进行微调或者蒸馏的时候， 数据流水线的构建是一个依赖条件。  ### 3. RAG应用的挑战------分块向量化 将大文档分割成较小的分块是一项关键而复杂的任务，对RAG系统的性能有着重大的影响。一般地，RAG系统旨在通过将基于检索的方法和基于生成的方法相结合，提高产出的质量和相关性。有多种框架提供了文档分块方法，每种方法都有自己的优点和典型用例。根据任务的具体要求，可以以多种方式来实现文本分块，下面是针对不同需求分块方法： * 按字符分块：此方法将文本分解为单个字符。它适用于需要细粒度文本分析的任务，例如字符级语言模型或某些类型的文本预处理。 * 按Token分块：将文本分割成token，是自然语言处理中的一种标准方法。基于令牌的组块对于文本分类、语言建模和其他依赖于token化输入的 NLP 应用程序等任务来说是必不可少的。 * 按段落分块：按段落分段整理文本有助于维护文档的整体结构和流程。此方法适用于需要较大上下文的任务，如文档摘要或内容提取。 * 递归分块：这涉及到重复地将数据分解成更小的块，通常用于分层数据结构。递归组块有利于需要多级分析的任务，如主题建模或层次聚类。 * 语义分块：根据意义而非结构元素对文本进行分组对于需要理解数据上下文的任务至关重要。语义块利用诸如句子嵌入等技术来确保每个块代表一个连贯的主题或想法。 * 代理分块：这种方法的重点是在识别和分组文本的基础上增加参与的代理，如人或组织。它在信息抽取和实体识别任务中非常有用，因为理解不同实体之间的角色和关系非常重要。 在良好分块的基础上， 我们再选择Embedding Model，HuggingFace的排行榜为我们提供了参考。 ### 4. Agent应用的挑战------接口设计的语义化表达 在基于大模型的Agen应用中，接口设计的语义化表达是其中的一个关键所在，也面临诸多挑战。以下是一些主要的挑战： * 多角色处理能力：Agent常常需要在不同任务中扮演多种角色，如代码生成器、测试员等。这要求接口设计能够灵活地适应不同角色的需求，确保每种角色都能准确地理解和执行其对应的任务。 * 复杂输入的处理：Agent感知需要接收并处理来自外部的多模态信息，这些输入形式各异，且往往包含复杂的语义和结构信息，如何将这些信息有效地转换为适合LLM处理的嵌入向量不是一个简单的任务。 * 幻觉问题的解决：由于训练数据的不完整或偏差，Agent也会产生幻觉，即输出不存在的API或错误的代码。这要求接口设计能够具备一定的验证和纠错机制，以减少或避免这类问题的发生。 * 效率问题：在多Agent协作中，计算资源的需求和通信开销可能会影响协作的效率和实时性。因此，接口设计需要考虑如何在保证功能完整性的同时，优化计算资源的使用和降低通信开销。 * 可解释性问题：Agent系统的自主性和交互能力正在重新定义人机协作的模式。然而，为了确保用户对Agent的信任和接受度，接口设计需要具备一定的可解释性，即能够清晰地展示Agent的决策过程和结果依据。 目前缺乏成熟的设计模式来指导Agent接口的设计，这也导致了不同开发者在构建Agent系统时可能采用不同的接口标准和实现方式，从而增加了系统的复杂度和维护成本。  ### 5. 安全性挑战------不一样的访问控制 基于尺寸、复杂性和敏感数据的处理能力，LLM面临着独特的安全挑战。为了确保LLM模型和数据的安全，需要考虑以下问题： * 保护LLM模型和数据：这包括实施访问控制、加密和安全数据存储，以防止未经授权的访问LLM模型和数据。 * 审计LLM使用情况：重要的是要跟踪谁在访问LLM模型和数据以及为什么目的。这有助于检测和防止LLM的未经授权使用或滥用。 * 管理对LLM模型的访问：需要确保只有经过授权的用户和应用程序才能访问LLM模型。这涉及设置身份验证和授权机制，以及实施防火墙和网络隔离。 另外， 提示词注入攻击也是一个不得不考虑的问题。 ### 6. 开发范式的挑战------提示词管理 在很大程度上，大模型应用是一种开发范式的转变------面向提示词的编程。基于AB测试，版本控制等方面的考量，这种开发方式面对的挑战就是提示词管理。 大模型应用需要一个针对产品级大型语言模型的高效管理系统。这一系统致力于精确处理输入至语言模型的各类查询与指令，其运作机制可类比于数字图书馆的管理体系，只不过这里的"藏书"换成了一个个精心设计的提示词。 从抽象视角来看，提示词管理是一系列优化实践的集合，旨在提升应用程序中大模型对提示的处理能力。其核心在于实现提示词的版本控制，确保其与应用程序的核心代码及部署流程相分离，同时保证从请求的角度能够轻松追踪。鉴于多人协作在快速开发中的普遍性，提示词管理系统还支持不同版本的并行开发与测试，确保这一过程不会干扰到生产环境的稳定性。此框架为团队成员提供了一个共享的工作空间，他们可以在此独立地开展工作并对提示词进行测试。 提示词管理框架借鉴了传统软件开发的基本准则，并针对大模型应用程序的独特需求进行了适应性调整，涵盖了其他需要特别关注的"可编码"元素。 另外，提示词管理与提示词工程略有不同。后者关注于创造性的设计提示词以最大化每次与大模型交互的效率，涉及一系列独特的实践和原则。而前者则更侧重于及时、高效的管理流程，与代码或模型管理紧密相连，尽管联系紧密，但二者在概念上仍有明显区别。  ### 7. 设计范式的挑战------大模型应用架构模式的采用 在塑造新领域的过程中，我们往往依赖于一些经过实践验证的策略、方法和模式。这种观念对于软件工程领域的专业人士来说，已经司空见惯，设计模式已成为程序员们的重要技能。然而，当我们转向大模型应用和人工智能领域，情况可能会有所不同。面对新兴技术，例如生成式AI，我们尚缺乏成熟的设计模式来支撑这些解决方案。 尽管我们已经有了一些探索，例如《大模型应用的10个架构模式》(https://mp.weixin.qq.com/s?__biz=MzAwOTcyNzA0OQ==\&mid=2658978952\&idx=1\&sn=3dceab421afe0448f9b6ad190d586c41\&chksm=80d351aeb7a4d8b8f3944343466d45708801af44fd5ddced1042b74f7140ba8a6a38f87a5550\&scene=178\&cur_album_id=2986642575455404032#rd)中所做出的总结： 1. 路由分发模式 2. 大模型代理模式 3. 多任务微调模式 4. 面向微调的分层缓存策略模式 5. 混合规则模式 6. 知识图谱模式 7. 智能体蜂巢模式 8. 智能体组合模式 9. 记忆认知模式 10. 双重安全模式 其中， 双重安全模式也是解决安全性挑战的一种应对方式。围绕大模型的核心安全性至少包含两个关键组件：一是用户组件，我们将其称为用户Proxy代理；二是防火墙，它为模型提供了保护层。用户proxy代理在查询发出和返回的过程中对用户的query进行拦截。该代理负责清除个人身份信息和知识产权信息，记录查询的内容，并优化成本。防火墙则保护模型及其所使用的基础设施。尽管我们对人们如何操纵模型以揭示其潜在的训练数据、潜在功能以及当今恶意行为知之甚少，但我们知道这些强大的模型是脆弱的。在安全性相关的技术栈中，可能还存在其他安全层，但对于用户的查询路径来说，Proxy代理和防火墙是最关键的。 大模型应用的架构模式不仅仅是一种范式，很可能成为未来智能系统赖以成长的框架。随着我们们继续探索和创新，还会涌现出很多新的架构模式。 ### 8. 性能挑战------如何评估大模型应用 对 LLM 输出进行评估对于验证大模型应用能否始终如一地产生高质量的结果至关重要。关键在于准确性，确保 LLM 理解上下文并产生相关响应，以及一致性，评估逻辑一致性。同时，相关性确保响应有效地处理用户查询。然而，偏见和公平性检查对于减少偏见和确保包容性至关重要。 常见的评估指标包括： * Perplexity：当一个模型按顺序预测下一个单词时，它的"困惑"或"混乱"的程度度量。 * BLEU：它通过比较机器生成的翻译和基本事实来评估翻译的准确性。 * ROUGE ：它通过与参考文献摘要进行比较来评估 LLM 生成的文本摘要的质量。 * WER：它通过比较系统生成的转录和人类转录来计算自动语音识别系统的准确性。 * MRR：帮助我们了解系统在寻找相关结果并将其置于最顶端方面的表现如何。 * BERTScore：使用一个预先训练好的 BERT 模型来评估与参考文本相比生成文本的质量。它使用 BERT 嵌入来度量两个文本之间的语义相似度。 评估工具的选择同样是一个挑战，因为有各种各样的开源和商业选择，包括 OpenAI 评估、 Promptfoo、 BenchLLM、 RAGAS、 Deepcheck 和 Guardrails 等等。另外，为了确保准确性，人工评价者应该包括在主观评价任务中，如连贯性、语言流利性和内容相关性。建议在不同的测试数据集和域上交叉验证 LLM，以确保鲁棒性和泛化性。  ### 9. 适用性挑战------大模型的应用边界 大模型在人工智能领域确实展现出了强大的能力，它们在各种控制平面和应用场景中都发挥着重要作用。然而，尽管大模型的应用范围广泛，但并不意味着它们是无所不能的。实际上，只有那些真正需要大模型来解决问题或实现特定功能的场景，才能被称为AI原生应用。 当我们设计系统架构时，需要仔细考虑哪些场景或子系统与大模型相关。这意味着我们仍然需要深入理解业务需求和技术挑战，以确定是否真的需要引入大模型来解决问题。在某些情况下，传统的机器学习算法或者规则引擎可能已经足够满足需求，而无需使用复杂的大模型。 虽然大模型在人工智能领域具有广泛的应用前景，但并不是所有场景都适合使用大模型。在设计系统架构时，我们需要根据具体需求和技术挑战来判断是否需要引入大模型，以确保系统的高效性和可靠性。 ### 10. 运营挑战------从devOps 到 LLMOps DevOps是软件工程效能的重要方法论以及工具集， 在人工智能领域同样如此。 创建、部署和管理这些复杂的大模型应用充满了复杂性，包括需要大量的计算资源，管理大量的数据集，并遵守道德标准。解决这些挑战需要一种称为LLMOps的方法，是机器学习操作(MLOps)的一个关键子集，重点关注从开发到部署和持续管理的大模型应用生命周期的流水线和自动化。LLMOps 通过结合"终身"学习扩展了 MLOps，使机器学习模型能够随着时间的推移不断地从新数据中学习和改进，从而使数据快速变化的应用程序受益。 实施LLMOps 的核心在于，定期监控为分布式训练配置的性能指标，调整超参数、分区策略和通信设置以优化性能，是提升训练效率的关键。实施模型的检查点机制并在发生故障时进行有效的恢复，可以确保训练过程在无需从头开始的情况下继续进行。 另外， 大模型应用的部署和运营操作需要一个复杂的框架来处理它们的复杂性和规模。自动化、编排和管道构成了这个框架的主干，简化了从数据准备到 LLMOps 景观中的模型部署和监控的每一步。 #### 一句话小结 自从生成性人工智能成为焦点以来，基于大模型的应用需求对架构师带来了一系列挑战，包括推理框架选择、数据流水线构建、分块向量化处理、接口设计语义化表达、安全性访问控制、提示词管理、架构模式采用、性能评估方法、应用边界确定以及从DevOps向LLMOps的转变。这些挑战要求我们架构上综合考虑技术、安全和运营等多方面因素，以推动大模型应用的落地。