AI-运维内部-挑战和最佳实践
AI 运维内部：挑战和最佳实践
towardsdatascience.com/ai-operations-under-the-hood-challenges-and-best-practices/单独的模型是不够的；拥有完整的系统栈和优秀、成功的产物才是关键。萨蒂亚·纳德拉 –
微软公司首席执行官 [1]。
在这篇文章中，我们将总结主要问题，并通过一个实际应用示例来展示它们。这不是要详尽无遗，而是旨在说明关键困难。
众所周知，一张图片胜过千言万语（在 AI 的闪光之下，可能更多）。为了说明和强调基于大型语言模型（LLM）开发系统时的核心挑战，我创建了图 1 中的图表，概述了管理长而繁琐合同中隐藏信息的潜在方法。虽然许多人声称 AI 将革命性地改变技术的每一个方面（并让数据科学家和工程师失业），但现实是，构建稳健、可重复和可靠的应用需要持续改进、严格评估和系统验证的框架。掌握这个快速发展的领域绝非易事，而且肯定需要不止一篇文章来突出所有细节。
这个图表（图 1）可能是保险行业客服中心的完美应用。如果你曾经尝试阅读自己的保险合同，你会知道它通常有几十页，充满了密集的法律语言（我们大多数人倾向于跳过的那种）。事实是，即使许多保险员工也不总是了解细节……但让我们之间保留这个秘密！😉毕竟，谁能够记住数百种产品和保险类型的确切承保范围、除外责任和限制？这正是我们希望通过这个系统解决的那种复杂性。
最终目标是创建一个工具，供客户服务中心的员工、理赔人员和欺诈调查员使用，可以立即回答复杂的查询，例如特定情况下的保险限额或具体的承保条件。但尽管这个应用表面上看起来很简单，我想在这里强调的是，任何开发者维护和改进这类系统时都会面临的更深层次的挑战。
图 1. 我最好的尝试来解释基于 LLM 的应用，使用提示工程、微调和 RAG 方法。图片由作者提供。
这远远超出了仅仅构建一个酷炫演示。它需要持续的监控、验证、偏差缓解和用户驱动的改进。这些任务通常被标记为“常规业务”（BAU），但在实践中它们需要大量的时间和精力。这个特定示例的技术债务可以归类为 LLMOps（或更广泛地说，GenAIOps 或 AIOps），尽管它基于与老朋友 MLOps 相似的原则，但它包括了大型语言模型独特的挑战。
这是一个将DevOps 与治理、安全和责任相结合的领域，然而……除非你被视为一个‘创新’，否则没有人会过多关注。直到它出了问题。然后突然之间它变得重要（尤其是当监管机构带着 RAI 罚款来敲门时）****。
正如承诺的那样，在我长时间的抱怨😓之后，让我带你了解图表背后的实际步骤。
当然，一切始于数据（是的……你仍然需要数据科学家或数据工程师）。不是干净、漂亮、标记过的数据……不是。我们说的是原始、非结构化和未标记的数据，“事物”如保险词典、多页政策合同，甚至是客户服务中心对话的记录。因为我们想要构建有用的东西，我们还需要一个真理或黄金标准（你信任的用于评估的基准），或者至少类似的东西……如果你是一个希望创造真正价值的道德专业人士，你需要以最简单但始终正确的方式找到真理。
一旦你获得了原始数据，下一步就是将其处理成 LLM（大型语言模型）能够实际消化的东西。这意味着清洗、分块、标准化，如果你在处理记录，还需要去除所有填充和噪音（图 1 中的第 4 步）。
现在，我们使用一个提示和一个基础LLM（在这种情况下是 LLaMA）来自动从处理过的文档和转录中生成问答对（步骤 5，使用步骤 1-2）。这形成了微调的监督数据集（步骤 6）。这些数据应包含问答对、问题的分类和来源（名称和页面），最后一个是用于验证。提示指导模型明确指出来源是否矛盾或所需信息缺失。对于分类，我们使用固定分类法中的零样本分类为每个问题分配一个类别；当需要更高的准确性时，我们通过向提示中添加少量标记示例切换到少样本分类。
LLM 辅助标注可以加速设置，但存在缺点（幻觉、覆盖面浅、风格漂移），因此在训练前与自动检查和针对性人工审查相结合非常重要。
此外，我们还创建了一个基准集（步骤 3）：由领域专家撰写的带来源的问答对，用作评估解决方案的基准。这个样本的行数比微调数据集要少，但能让我们清楚地了解预期内容。我们还可以在生产前通过小规模用户试点试验来扩展它。
为了使用户的回答个性化（LLM 缺乏专门的领域知识），我们决定使用 LoRA 微调一个开源模型 Mixtral（步骤 6）。我们的想法是让它更加“保险友好”，并能以更接近真实保险人员交流的方式回应，我们通过步骤 3 和 7 来评估结果。当然，我们也想通过长期记忆来补充这一点，这正是 AWS Titan 嵌入和向量搜索发挥作用的地方（步骤 8）。这是RAG 架构，结合语义检索和上下文感知生成。
从那里，流程很简单：
用户提出一个问题（步骤 13），系统使用向量搜索+元数据过滤器从知识库中检索最相关的块（步骤 9 & 10）（以使其更易于扩展到不同的保险分支和客户类型），然后 LLM（微调的多语言 Mixtral）使用精心设计的提示生成一个有充分依据的回答（步骤 11）。
这些元素总结了图表，但在这背后存在挑战和细节，如果不加以注意，可能会导致产生不希望的行为；因此，有必要纳入一些元素，以避免失去对应用程序的控制。
好吧……让我们从这篇文章开始吧 😄…
在生产中，事情会发生变化：
-
用户会提出意想不到的问题。
-
上下文检索失败时无声无息，模型以虚假的自信回答。
-
提示的质量会随时间下降，这被称为提示漂移。
-
业务逻辑（随时间推移，政策演变：新的例外、修正条款、新条款、附加条款/背书，以及由法规、市场变化和风险变化驱动的全新合同版本。）
-
微调模型的行为不一致。
这是大多数人忘记的部分：生命周期并不在部署时结束，而是从那时开始。
“Ops”涵盖什么？
我创建了这张图（图 2）来可视化所有部件如何组合在一起。步骤、逻辑、反馈循环，至少是我根据我的经验所经历的。当然还有其他表示方法，但这是我认为最完整的一种。
图 2.端到端 AI 产品生命周期：负面决策导向弃用，通过反馈循环驱动优化。图由作者提供。
我们假设这个图示在安全的堆栈上运行，具有保护数据和防止未授权访问的控制。这并不免除我们在整个开发过程中验证和验证安全性的责任；因此，我包括一个开发者级别的安全防护框，稍后我会更详细地解释。
我们有意遵循一个线性的门控：数据管理 → 模型开发 → 评估与监控 → 部署（CI/CD）。只有通过离线检查的模型才会被部署；一旦投入生产，在线监控就会反馈到数据和模型优化（循环）。在第一次部署之后，我们使用在线监控来持续优化和改进解决方案。
万一的话，我们将简要描述每个步骤：
-
模型开发：在这里，你定义与业务需求一致的“理想”或“不那么错误”的模型架构。收集初始数据集，也许微调一个模型（或者只是提示工程或 RAG，或者全部）。目标？得到一些可以工作的事情——一个证明可行性的原型/MVP。在第一次生产发布后，通过重新训练保持优化，并在适当的时候，采用高级技术（例如，RL/RLHF）来提高性能。
-
数据管理：处理数据和提示的版本；保留与版本、架构、来源、操作信号（如令牌使用、延迟、日志）等相关的元数据。以所有形式管理并治理原始和经过处理的数据：打印或手写的，结构化和非结构化的，包括文本、音频、视频、图像、关系型、矢量型和图数据库或任何其他系统可以使用的类型。甚至从非结构化格式和元数据中提取信息；维护一个 RAG 可以查询的图存储，以支持分析用例。请不要让我谈论“质量”，这通常处理不当，会向模型引入噪声，并最终使工作更难。
-
模型部署（CI/CD）： 将模型及其依赖项打包成一个可重复的工件，以便在不同环境中推广；暴露工件以进行推理（REST/gRPC 或批量）；并运行测试管道，自动检查每个更改，如果阈值失败则阻止部署（单元测试、数据/模式检查、代码检查器、在黄金集上的离线评估、性能/安全扫描、金丝雀/蓝绿部署并回滚）。
-
监控与可观察性： 跟踪模型性能、漂移、使用情况和生产中的错误。
-
保障措施： 防止提示注入、执行访问控制、保护数据隐私，并评估偏见和毒性。
-
成本管理： 监控和控制使用和成本；预算、团队配额、令牌等。
-
商业价值： 制定一个业务案例来分析预期的结果是否与实际交付的内容相比有意义。此类解决方案的价值并非立即显现，而是在一段时间后。有一系列商业考量会产生成本，并应有助于确定应用程序是否仍然有意义。这一步并不容易（尤其是对于嵌入式应用程序），但至少需要讨论和辩论。这是一项必须完成的练习。
因此，为了将我们的原型转变为一个生产级、可维护的应用程序，必须解决几个关键层。这些不是额外的；它们是确保每个细节都得到适当管理的必要步骤。在接下来的内容中，我将重点关注可观察性（评估和监控）和保障措施，因为更广泛的话题可能需要一本书来阐述。
评估与监控
可观察性是指随着时间的推移持续监控系统，以确保其保持预期的性能。它涉及跟踪关键指标以检测输入、输出和中间步骤（检索结果、提示、API 调用等）的逐渐退化、漂移或其他偏差，并以支持分析和后续改进的形式捕获它们。
表 1. 评估语言模型性能和安全的指标。表由作者提供。
在此基础上，您可以自动化警报，当定义的阈值被跨越时触发，例如，答案相关性的突然下降，检索延迟的增加，或令牌使用量的意外激增。
为了确保应用程序在不同阶段的行为正确，创建由领域专家精心制作的真实或黄金数据集非常有用。此数据集作为在训练、微调和评估（步骤 3，图 1）期间验证响应的基准。
评估微调：
我们首先测量幻觉和答案相关性。然后，我们将这些指标与基线 Mixtral 模型（未微调）和针对特定于保险的语言微调的我们的 Mixtral 模型进行比较（步骤 6，图 1）。
基线模型与微调模型的比较有两个目的：（1）它表明微调模型是否比未调优的基线更适合问答数据集，以及（2）它允许我们设置一个阈值来检测性能随时间下降，无论是相对于先前版本还是相对于基线。
有了这个想法，我们尝试使用 Claude 3（通过 AWS Bedrock）对每个模型响应与领域专家的黄金答案进行评分。最高分意味着“等同于或非常接近黄金真相”，最低分则表示“无关或矛盾”。
Claude 断言级别评估器。我们将每个模型答案分解为原子断言。给定黄金证据，Claude 将每个断言标记为蕴含/矛盾/不在来源中，并返回 JSON。如果没有信息来回答上下文，则正确的响应如蕴含（我们宁愿没有答案也不愿有错误答案）。对于每个答案，我们计算断言支持（CS）=蕴含/总断言数和幻觉率=1-CS，然后通过平均所有答案的 CS（和 HR）来报告数据集分数。这直接衡量了答案中有多少部分得到了领域专家答案的确认，并与文献中发现的断言级别指标相一致[3]。
这个基于断言级别的评估器提供了更高的粒度和有效性，尤其是在答案包含正确和错误陈述的混合时。我们之前的方法将单个等级分配给整体性能，这掩盖了需要解决的具体错误。
目的是将这个指标扩展到验证答案与文档来源的一致性，并且另外维护一个比领域专家集更容易构建和更新的基准（并且更不容易出错）。实现这一点需要进一步的细化。
此外，为了评估答案的相关性，我们计算模型答案和黄金答案嵌入之间的余弦相似度。缺点是即使事实是错误的，嵌入也可能看起来“相似”。作为替代方案，我们使用一个作为法官的 LLM（Claude）来标记相关性为直接、部分或无关（考虑到问题），类似于上述方法。
这些评估和持续的监控可以检测到问题，例如问答数据集缺乏上下文、来源、足够的示例或正确的问题分类。如果微调提示与推理提示不同，模型可能会在生产中忽略来源并产生幻觉，因为它从未学会将输出基于提供的上下文。每当这些变量发生变化时，监控系统应触发警报并提供诊断以促进调查和补救。
审查：
为了衡量调节或毒性，我们使用了DangerousQA基准（200 个对抗性问题）[4]，并让Claude 3使用一个改编的提示评估每个响应，评分从 1（高度负面）到 5（中性），涵盖毒性、种族主义、性别歧视、非法和有害内容。基础和微调的Mixtral模型在所有类别中一致得分4-5，表明没有毒性、非法或不尊重的内容。
公共基准，如 DangerousQA，通常泄漏到 LLM 训练数据中，这意味着新模型会记住这些测试项目。这种训练-测试数据重叠会导致分数膨胀，并可能掩盖真实风险。为了减轻这种情况，需要采取替代方案，如开发私有基准、轮换评估集或生成新的基准变体，以确保测试污染不会人为地提高模型性能。
评估 RAG：
在这里，我们专注于检索上下文的质量。在预处理（步骤 4，图 1）期间，我们将文档分成块，目的是封装信息的有意义片段。目标是确保在到达生成模型之前，检索层将最有用的信息排在最前面。
我们比较了两种检索设置：（A）无重排序：仅使用关键词或密集嵌入返回前 k 个段落；和（B）有重排序：通过嵌入检索候选内容，然后使用重排序器（在 LangChain 中预训练的 ms-marco-mini-L-12-v2 模型）重新排序前 k 个结果。对于每个包含专家黄金真实答案的精选集的问题，我们将检索到的上下文标记为完整、部分或无关，然后总结覆盖范围（百分比完整/部分/无关）和设置之间的胜率。
重排序一致地提高了结果上下文的质量，但收益对分块/分割非常敏感：碎片化或不连贯的块（例如，剪裁的表格、重复项）即使在技术上检索到相关部分时也会降低最终答案的质量。
最后，在生产过程中，收集用户反馈和答案评分以随着时间的推移丰富这个黄金真实答案。常见问题（FAQ）及其验证过的响应也被缓存，以减少推理成本并提供快速、可靠的答案，具有高置信度。
作为替代方案的评分标准：
用于评估 RAG 和微调模型的快速评估方法提供了模型响应的初步一般概述。然而，正在考虑的另一种方法是使用多步骤评估和领域特定评分标准。评分标准不是分配一个单一的总体评分，而是将理想的答案分解为一系列清晰、可验证的二进制清单。每个标准都被标记为是/否或真/假，并辅以证据或来源，从而能够精确地诊断模型在哪些方面表现优异或不足[15]。这种系统性的评分标准方法提供了对模型性能的更详细和可操作的评估，但需要时间进行开发，因此它仍然是我们的技术债务路线图的一部分。
安全措施
常常存在尽快交付最小可行产品的压力，这意味着在数据集、提示和其他开发组件中检查潜在漏洞并不总是首要任务。然而，大量文献强调了模拟和评估漏洞的重要性，例如通过引入在训练/开发过程中应用或系统未曾遇到过的输入来测试对抗性攻击。为了有效地实施这些安全评估，培养对漏洞测试是开发过程和应用程序整体安全的重要组成部分的认识至关重要。
在表 2 中，我们概述了几种攻击类型及其示例影响。例如，GitLab 最近面临了一次远程提示注入攻击，影响了 AI Duo 代码助手，导致源代码被盗。在这起事件中，攻击者在公共存储库中嵌入隐藏的提示，导致助手从私有存储库向外部服务器泄露敏感信息。这一现实案例突出了此类漏洞可能导致的安全漏洞，强调了预测和减轻提示注入和其他新兴人工智能驱动威胁在应用程序安全中的重要性。
表 2. 针对人工智能和语言模型系统的常见攻击类型，包括其目标、机制、典型发生点和实际示例。表由作者编制。
此外，我们必须意识到人工智能结果中的偏差输出。2023 年《华盛顿邮报》一篇题为“这是人工智能图像生成器如何看待世界”的文章通过图像展示了人工智能模型如何复制甚至放大其训练数据中存在的偏差。确保公平性和减轻偏差是一项重要任务，但由于时间限制，它往往被忽视，但对于构建值得信赖和公平的人工智能系统仍然至关重要。
结论
尽管文章的主要目的是通过一个典型（但合成）用例的例子来说明基于 LLM 应用程序的复杂性，但强调需要强大且可扩展的系统的原因是显而易见的：构建这样的应用程序远非简单。如果我们未能持续监控系统、确保公平性和主动应对风险，那么潜在的问题可能会出现。没有这种纪律，即使是前景看好的应用程序也可能迅速变得不可靠、有偏见或与其预期目的不一致。
参考文献
[1] South Park Commons. (2025 年 3 月 7 日)。微软 CEO 讨论人工智能代理与量子 | 桑雅·纳德拉 [视频]。YouTube。www.youtube.com/watch?v=ZUPJ1ZnIZvE — 见 31:05。
[2] Potluri, S. (2025 年 6 月 23 日)。AI 栈正在演变：认识幕后的模型。Medium — 技术女性。Medium
[3] Košprdić, M. 等. (2024)。Verif. ai：向一个开源的科学生成式问答系统迈进，具有可引用和可验证的答案。arXiv 预印本 arXiv:2402.18589。arxiv.org/abs/2402.18589。
[4] Bhardwaj, R. 等. “使用话语链进行安全对齐的 Red-Teaming 大型语言模型” arXiv 预印本 arXiv:2308.09662 (2023)。GitHub 仓库：github.com/declare-lab/red-instruct
[5] Yair, Or, Ben Nassi, 和 Stav Cohen. “邀请即一切：使用简单的 Google 日历邀请调用 Gemini 工作空间代理。” SafeBreach 博客，2025 年 8 月 6 日。www.safebreach.com/blog/invitation-is-all-you-need-hacking-gemini/
[6] Burgess, M.，& Newman, L. H. (2025 年 1 月 31 日)。DeepSeek 的安全护栏在研究人员提出的所有测试中都失败了。WIRED。www.wired.com/story/deepseeks-ai-jailbreak-prompt-injection-attacks/?utm_source=chatgpt.com
[7] Eykholt, K.，Evtimov, I.，Fernandes, E.，Li, B.，Rahmati, A.，Xiao, C.，… & Song, D. (2018)。对深度学习视觉分类的鲁棒物理世界攻击。在 IEEE 计算机视觉与模式识别会议论文集 (第 1625–1634 页)。
[8] Burgess, M. (2025 年 8 月 6 日). 一份受污染的文档可能通过 ChatGPT 泄露“秘密”数据. WIRED. www.wired.com/story/poisoned-document-could-leak-secret-data-chatgpt/?utm_source=chatgpt.com
[9] Epelboim, M. (2025 年 4 月 7 日). 为什么你的 AI 模型可能会泄露敏感数据（以及如何阻止它). NeuralTrust. NeuralTrust.
[10] 周志，Z.，朱，J.，余，F.，李，X.，彭，X.，刘，T.，& 韩博，B. (2024). 模型反演攻击：方法与对策综述. arXiv 预印本 arXiv:2411.10023. arxiv.org/abs/2411.10023
[11] 李，Y.，江，Y.，李，Z.，& 夏，S. T. (2022). 漏洞学习：综述. IEEE 交易在神经网络与学习系统，35(1)，5–22.
[12] Daneshvar, S. S.，Nong, Y.，杨，X.，王，S.，& 蔡海，H. (2025). VulScribeR：探索基于 RAG 的漏洞增强与 LLM。* ACM 软件工程与方法交易*.
[13] Standaert, F. X. (2009). 侧信道攻击简介. 在 安全集成电路与系统 (第 27–42 页). 波士顿，MA：Springer US.
[14] Tiku N.，Schaul K. 和 Chen S. (2023 年 11 月 01 日). 这就是 AI 图像生成器看待世界的方式.* 华盛顿邮报. www.washingtonpost.com/technology/interactive/2023/ai-generated-images-bias-racism-sexism-stereotypes/(最后访问日期：2025 年 8 月 20 日).
[15] Cook J.，Rocktäschel T.，Foerster J，Aumiller D，Wang A. (2024). 检查所有框：生成的清单改善 LLM 评估和生成. arXiv 预印本 arXiv:2410.03608. arxiv.org/abs/2410.03608
浙公网安备 33010602011771号