主权限制下搞AI，这三个环节最容易翻车

大家好。大家都能听清我说话吗？好的，太棒了。感谢各位参加本次会议。今天我们要讨论的主题是主权。我是Viguen，在Deepset担任高级开发者关系工程师。不过我想先问个问题：在座有多少人熟悉"主权"这个概念？哇，看来不少人都了解。或许我不用过多介绍了。简单说明一下Deepset的背景——我们公司开发了名为Haystack的开源编排框架，同时也提供企业级平台。

通过这些产品，我们正在为空客、博世、西门子等大型企业，以及欧盟委员会、德国联邦研究与技术部、德国航天局等公共部门机构解决AI挑战。因此，主权对我们而言是一个极其重要的议题。这里可以给出一个政策层面的定义：主权AI是指组织能够自主设计、部署和运营AI系统的能力。但在座的都是工程师，而非政策制定者或律师。若将其转化为技术定义，本质上就是实现对数据流、模型选择、基础设施、可观测性和运营的明确控制。

为了更好地理解这个概念，我想将其拆解为四个支柱。第一个是数据主权，涉及数据存储位置和处理地点。第二个是模型主权，关乎运行模型的控制权以及训练数据的来源。第三个是基础设施主权，即计算发生在何处。最后一个是运营主权，涉及应用程序和系统的可追溯性、更新权限归属以及事件响应责任方。接下来我们深入探讨一下。数据主权方面，数据是企业最重要的资产。要实现数据主权，数据必须在受信任的司法管辖区内进行处理和存储，以满足合规要求。

这是什么意思呢？简单来说，GDPR规定欧洲公民的数据应当留在欧洲境内。但如果将这些数据发送给嵌入模型，发送给托管在美国弗吉尼亚州的嵌入模型，那么你就已经失去了对数据的控制权。这就违反了数据主权原则。另一个方面是访问权限问题。这并非完全关乎数据的存储和处理方式，而是指如果组织内部有用户访问了本不该看到的数据，同样也构成了对数据主权的侵犯。此外还有基础设施主权问题——计算究竟在哪里进行？这意味着我们拥有AI应用层。

那么，我们有rag管道数据摄取，有智能体，还有这些智能体使用的工具，它们都在某个地方运行。而应用层运行的位置决定了系统的"基础设施主权"。从最大控制到最大便利，存在一个完整的频谱。也许你在完全隔离的环境中运行所有内容，这能确保符合欧盟《人工智能法案》的安全要求。也许你在私有VPC上运行，这能保障GDPR合规性。还有主权云方案，这取决于你选择的供应商。最后还有SaaS模式。

在SaaS模式下，你会面临云法案风险。举例来说，如果你使用一家总部位于美国的公司，即便所有数据和应用程序都在欧洲境内存储和运行，他们仍有权访问你的运行数据。这违背了你对系统的自主控制权。另一个支柱是模型主权，即谁掌控着模型以及训练数据的来源？你应当拥有自由选择和切换模型的权利。但现实是，如果你的系统只能适配特定模型，就会与该模型提供商形成强绑定。一旦该模型服务中断，你将失去访问权限；若其涨价，你又会面临成本问题。这完全违背了模型主权的理念。

另一个方面是无需架构变更即可切换的能力。也就是说，你可能不必与某个模型提供商紧密绑定，或许也能使用其他模型。但如果你的系统或代码无法立即支持这种切换，那么尽管技术上你并未被该提供商绑定，却也无法在一天之内更换整个代码库。最后一点是训练数据来源。这有些争议，因为我们无法得知模型是在哪里训练的、使用了哪些数据来训练。不过，如果模型提供商是欧洲公司，那么相比美国公司，它们会更具优势。最后一个支柱是运营主权。

所以，构建整个人工智能系统是一方面，但通过监控、评估和管理来维护整个系统则是另一方面。运营主权指的是监控这些系统在生产环境中的表现，包括模型的输入和输出。在人力资源或金融等高风险的领域，这需要人类参与其中。同时，以可控且可审计的方式管理版本控制、模型更新以及应用层，也属于运营主权的范畴。好消息是，主权是一个范围概念。因此，并非所有人都需要在所有方面都实现完全的主权。当然，如果你身处金融、医疗等高风险的领域，你可能需要一个完全隔离的解决方案。

但如果你是一家不同领域的企业或初创公司，可能根本不需要所有功能。你不需要遵循我之前展示的每一个主权支柱。关键在于你需要了解控制的程度，也就是你对系统的供应商锁定程度。所以，你这周在这里参加会议，但下周一回到工作岗位时，你的经理或首席信息官可能会说：“好吧，我们现在有了一个可运行的系统，但需要让它具备主权性。” 在这张幻灯片中，我想展示你通常首先会做什么，以及在这个现有系统中你会破坏什么。

所以，最直观的做法可能就是替换模型，把现有的前沿模型换成自托管模型。但接下来会发生什么呢？你需要将整个前沿模型的逻辑迁移到新的模型架构上。可能还需要更新提示词。基本上，你需要从头开始评估系统的性能，还得写大量代码。另一种做法是将私有数据迁移到所需的司法管辖区，因为你发现有些信息托管在美国，现在需要把它们转移到欧洲某个地方。但当你这么做时，却发现自己需要管理多个数据库和实例。这时搜索就成了问题。那么，你该如何处理搜索呢？

你是先做分类，比如查询分类，还是把请求同时发送到这两个数据库并从中获取信息？这只是这种转变带来的一个挑战。另一个挑战是，当你用本地部署取代托管基础设施时，你会立刻意识到自己在这方面对供应商的依赖有多深。因为现在你开始考虑，比如Kubernetes集群管理，该如何处理那些原本由云服务商为你处理的所有事情？此外，还有硬件方面的限制，因为现在你需要考虑：我的应用层在CPU上运行，但我的模型现在在GPU上运行。

所以我需要以某种方式将它们连接起来，而这种连接管理、网络管理也成了问题。最后一点是引入可观测性和追踪。我的意思是，如果你的系统在此之前没有可观测性，这本身就已经是个重要问题了。但当你现在需要引入它时，你会发现这完全是个黑箱。所以你实际上不知道AI应用层发生了什么。现在你必须理解这一点，因为你需要将日志记录在某个地方，以便系统可审计。此外还有版本控制的问题。你如何为你的应用层、为你正在管理的整个系统进行版本控制？

我想毫不掩饰地推荐Haystack，因为一个好的编排框架我认为能解决其中一些问题。我的意思是，好的编排无法解决你的局限性，但能在许多不同方面提供帮助。首先，Haystack具有一致的接口。基本上，当你想要将系统从云端迁移到自托管应用时，只需更改几行代码，就能轻松实现，只需专注于你拥有的硬件以及硬件连接。第二点是明确的数据流。因此，Haystack应用中的每个输入和输出都有类型声明。

因此，你可以通过常规方式在整个应用程序中读取管道定义，并确切了解每个数据的位置。即使在确定性较低的结构中，比如代理系统，整个数据、工具调用及工具输出也都是可追溯的。第三点是YAML。Haystack应用程序可序列化为YAML，这使得版本管理变得非常简便。当你用Haystack创建应用程序后，可以将其转换为YAML并存入版本控制系统。当需要回溯历史版本时，只需回到对应的提交记录，就能看到哈希值。最后一点是它真正开源，没有黑箱操作，也没有隐藏假设。

当你需要自定义代码或扩展某个组件时，你可以轻松做到，因为你真正理解了底层的工作原理。今天我想向大家展示一个主权架构，作为高层级概述。想象一下，你正在构建这个智能体，但它需要具备某种主权属性。那么，你首先要做的可能是添加一些防护栏，因为这些防护栏需要检查用户输入中是否存在提示注入攻击，同时还需要进行特定的监管合规检查——也许这个智能体需要以特定方式使用，你需要验证用户是否怀有这种意图。

如果请求不安全，它会立即离开应用层。如果是安全的请求，则会进入代理层。这里的代理本质上是一个带有系统提示词和多种工具的智能体。这些工具可以是函数调用，可能连接到你的知识库进行某种搜索。如果你在处理多智能体系统，可能还会使用其他代理，当然还有连接到代理的MCV服务器。代理会为你生成输出并完成工作，最后一道防护栏会进行合规性检查，因为你也不希望向用户泄露敏感信息，最终形成输出结果。

当然，如何将系统设计成主权系统本身就是一个挑战。而Haystack的职责就是确保所有组件都可替换、可追溯，并且避免供应商锁定。这样，你就可以根据自身需求，在适当的主权级别下开展工作。以下是我从Haystack中挑选出的一些工具，供你使用。比如，你可能需要根据任务选择不同的模型；或者对于公开数据，你可以从那些供应商那里获取一些专有模型，这样就不用担心了。

但对于某些任务，比如护栏机制，或者你的知识库，以及你的 LLM，你可能需要运行来自其他不同提供商的本地模型，例如 Mistral、Google、Nvidia 和 Gina。当然，还有可追溯性的问题。正如我所说，在 Haystack 中，每个进入组件的输入和每个输出，以及代理中的追踪信息都是清晰可见的，因此你可以将这些跨度连接到你的 LLM 可观测性工具。而且，由于集成了 OpenTelemetry，你也可以实现自己的可观测性。最后一部分是存储。

我想挑选一些既能提供云服务又能提供开源版本的供应商，这样你就可以在本地或自己的服务器上轻松托管这些服务。这里有一个护栏代码。实际上，使用Haystack连接或定义护栏非常简单。你只需从一个模型提供商开始。例如，在这个例子中，它是Nvidia聊天生成器。你指定要使用的模型名称。通过将其连接到你的LLM消息路由器，它可以帮助你进行分类。它会检查输入内容，如果安全，则进入安全路线；如果不安全，则进入不安全路线。然后，你可以开始添加工具。

因此，你将本地托管的MCP服务器与MCP工具集连接起来，并指定要从该MCP服务器中选取的工具名称。因为你的MCP服务器上可能运行着大量工具，但你不希望一次性获取所有工具，也不希望单个代理能访问全部工具。例如，你可以选择知识库搜索和生成PDF报告这两个工具。当然，你也可以添加不同的工具——既可以通过Python函数定义工具，也可以将Haystack中的其他组件（如代理组件）接入工具，或者定义数据摄取、Rack流水线等功能，甚至将这些工作流也转化为工具。

在定义完所有这些工具后，将它们放入一个可搜索的工具集中。这样就能实现动态工具搜索，配合BM25功能——因为你的智能体可能拥有数百个工具，但你不希望用工具定义填满整个上下文。接下来是智能体组件部分。本质上你需要定义一个系统提示词，比如"你是一个拥有多工具访问权限的主权智能体"，并定义该智能体的意图，然后为其配备"大脑"——本质上就是一个对话生成器。如果你在本地部署运行该模型，可以创建自定义组件，例如yi现在这个就是我的本地对话生成器，它连接到公司内部URL并从中获取模型推理结果。

当然，如果你有一个兼容Open AI API的dpo端点，就可以直接使用Haystack中的现有组件，然后提供工具并定义确认策略。本质上，你通过将人类纳入循环来确保：如果用户想要提交mit请求，代理必须始终请求人类批准；但如果代理需要使用列表支付请求工具，则需先获得人类许可，之后便可在整个循环中自由使用该工具。最后将所有环节整合together起来。接下来开始定义你的流水线：首先添加一个追踪器组件连接到你的LLM可观测性系统，然后部署输入npu护栏。

你连接你的智能体、输出护栏，然后直接运行这个智能体，让它提取第三季度的未结付款请求并生成PDF。通过智能体自带的工具，它会自动为你创建PDF，并保存到指定目录和文件名。在演示接近尾声时，我想给你一份检查清单。如果你想确认系统是否具备自主性，可以参考这些问题：能否在不修改应用逻辑的情况下更换模型？是否以合规方式存储可复现的运行日志？团队能否在不联系超大规模供应商的情况下独立处理突发事件？感谢参与本次会议。

你可以通过填写表格获取演示文稿，并向我来提问。如果你想在社交媒体上联系我，也可以在那里找到我。我很乐意与你讨论关于智能体、Haystack，特别是在主权环境下的应用。谢谢。