企业官网建设流程全解析

网站建设是基于,上海网页制作培训班,培训机构网站模板,玄幻小说排行榜百度风云榜作者#xff1a;来自 Elastic Sean MacKirdy 探索用于生成式 AI 沙箱的配方#xff0c;为开发者提供一个安全的环境来部署应用原型#xff0c;同时实现隐私和创新。 动手体验 Elasticsearch#xff1a;深入了解我们的示例 notebooks#xff0c;开始一个免费的 cloud 试用来自 Elastic Sean MacKirdy探索用于生成式 AI 沙箱的配方为开发者提供一个安全的环境来部署应用原型同时实现隐私和创新。动手体验 Elasticsearch深入了解我们的示例 notebooks开始一个免费的 cloud 试用或者现在就在你的本地机器上尝试 Elastic。构建生成式 AIGenAI应用正在风靡一时而上下文工程context engineering也就是为大型语言模型large language model - LLM提供所需的提示结构和数据使其在不自行补全缺失信息的情况下返回具体且相关的答案是过去 24 个月中出现的最受欢迎的模式之一。上下文工程中的一个重要子集是检索增强生成RAG它通过利用基于自然语言的搜索能力根据语义而非关键词从私有数据集中检索最相关的结果从而为 LLM 交互提供额外的上下文。随着上下文工程的迅猛发展如何确保快速原型项目不会将业务或任务关键数据暴露给未授权的接收方成为一个重要关注点。对于同时关注技术和政策的受众来说我一直在倡导 “隐私优先” 的 GenAI 沙箱概念下面我将其简称为沙箱。在本文中沙箱指的是一个自助式、安全的原型设计空间类似儿童的沙坑木质边缘可以防止沙子外泄它允许组织成员安全地测试其自定义的上下文工程应用而不会有泄露机密数据的风险。生产级 GenAI 沙箱 实现隐私GenAI从像 ChatGPT、Claude 和 Gemini 这样的文本生成工具到像 Google 的 Nano Banana、OpenAI 的 DALL-E 和 Midjourney 这样的图像生成工具在过去两年里引发了无处不在的讨论在课堂上、在餐桌旁、在监管圈、在法庭上以及在董事会会议室中。我有幸与客户分享 Elastic 在上下文工程方面的方法尤其是 RAG这些客户包括开发者和 C-suite 高管也包括我的一些联系人从朋友和家人到立法者。可以将上下文工程理解为一名图书管理员它负责查找并提供上下文数据用来增强文本、音频或图像 GenAI 应用使其补充其训练数据中原本不具备、但完成目标任务所需的信息例如查询体育比分和新闻标题来帮助一个文本生成应用回答 “昨天国家冰球联盟发生了什么” 这个问题。如果你不熟悉这个概念并希望进一步阅读Elasticsearch Labs 在这里提供了关于上下文工程的优秀入门材料在这里也提供了关于 RAG 的介绍。隐私优先的方法可以确保上下文工程为 GenAI 应用提供受保护的、经过选择的或敏感的数据从而生成比仅使用公共信息更充分、更相关的响应。一个例子是为大学生提供一个由 GenAI 驱动的交互式文本聊天体验chatbot用于获取与其个人背景相关的助学金和奖学金信息同时避免将诸如社会安全号码或出生日期等个人可识别信息PII暴露给恶意攻击者防止其通过常见漏洞例如 OWASP Top 10或通过 LLM 本身进行信息提取。部署沙箱背后的核心逻辑原则如下用户无论其组织是否提供相关工具都会找到将 GenAI 融入其日常工作流程的方法。即使在现实中防止此类 “shadow IT” 并不现实或几乎不可能的组织中提供并监控访问以防止组织敏感数据泄露仍然至关重要而沙箱正是释放这些工具的理想场所。提供一个内置 Application Performance MonitoringAPM和信息安全InfoSec最佳实践的沙箱来部署应用可以让组织在保护隐私的同时洞察 GenAI 的潜在使用场景实现对 GenAI 使用的审计和问责并建立集中化的成本管理。组织的沙箱应支持自助式或低接触方式部署经过同行评审的 GenAI 应用以便让有意愿自行开发应用的人在最小摩擦下进行最大程度的实验。如果正确实施并限制在组织受控的边界内沙箱可以在不触发因未经授权或非预期的外部共享、或其他受保护数据如 PII泄露而产生责任的情况下利用组织现有的数据资产——例如加州 CCPA或欧盟 / 英国 GDPR。本文不会重点介绍如何构建 GenAI 应用在 Elasticsearch Labs 中已经有大量优秀示例。相反我将重点介绍部署一个沙箱所需的配方该沙箱能够提供实现上述第 3 条原则所需的安全性和可用性。基础要素要使沙箱被认为是生产级需要考虑以下基础要素图 1我们在实践指南中将使用的要素。点击放大。让我们来探讨为什么每个要素在沙箱配方中都起着关键作用。在此过程中请注意我下面列出的品牌选择基于个人经验并不代表 Elastic 对任何技术的认可。就像任何配方一样这些形成了我偏好的要素。当然你可以在每个环节替换以使配方符合你的需求1. 容器化平台沙箱配方的第一个要素是选择容器化平台。这些平台在概念上类似于过去 15 年企业 IT 的虚拟机但在应用打包和部署方式上有显著演进。它们旨在实现快速部署、无服务中断的升级以及在本地和云计算环境中的原生分发同时提供更高的可测试性、基础设施验证和可审计性。你选择的平台通常通过基础设施即代码IaC进行管理以确保可复现性和一致性是实现 GenAI 应用敏捷性和可扩展性的基础。容器化平台的关键组件健壮的容器化平台由几个关键组件构成容器运行时Container runtime执行容器并管理其生命周期的软件。一个常见示例是 Docker它提供构建、共享和运行容器镜像的工具。镜像构建基础设施Image build infrastructure用于从应用源代码创建容器镜像的过程和工具。像Dockerfiles这样的工具提供了一种清晰、可重复的方法来定义镜像内的环境、依赖和应用代码确保开发、测试和生产环境的一致性。编排引擎Orchestration engine在生产级环境中你需要一个系统来自动化容器的部署、扩展和管理。Kubernetesk8s是行业标准提供强大的负载均衡、自我修复和服务发现功能。下面在要素 #2 中会详细介绍。1.1 基础设施即代码Infrastructure as code为了确保沙箱的可复现性和可维护性容器化平台应使用 IaC 原则进行管理。这意味着你不是手动配置平台而是通过代码文件定义基础设施例如 Kubernetes 集群、网络规则、安全策略可以使用Terraform或Pulumi等工具。该方法提供了多个好处版本控制Version control你的基础设施可以像其他代码一样处理允许跟踪更改、回滚到以前版本并通过 Git 与团队协作。一致性ConsistencyIaC 大幅减少人为错误确保沙箱环境可以在任何云或本地位置完全复现。自动化Automation它使你能够自动化整个搭建和拆除过程轻松为特定项目或测试创建临时沙箱。2. 托管与编排正如在 “容器化平台” 部分介绍的那样我们需要一个强大的编排引擎来大规模管理容器。为此k8s 是编排生产级沙箱的事实标准。如果你不熟悉可以查看 Cloud Native Computing FoundationCNCF提供的 k8s 入门资料。无论是在云端还是本地运行Kubernetes 都提供了部署、扩展和管理容器化应用生命周期所需的稳健框架。主要云提供商如 Google CloudGoogle Kubernetes Engine [GKE]、Amazon Web ServicesElastic Kubernetes Service [EKS]和 Microsoft AzureAzure Kubernetes Service [AKS]都提供成熟的托管 Kubernetes 服务处理底层复杂性特别是合同保障和独立认证的合规性符合法定隐私和信息安全要求让团队可以专注于构建和部署应用。对于 GenAI 沙箱Kubernetes 尤其有价值因为它可以高效管理和扩展 GPU 资源而 GPU 往往是 GenAI 技术栈两个关键组件所必需的1私有托管的 LLM2驱动它们的推理过程在要素 #6 和 #7 中会详细讨论。它自动化部署和资源管理的能力确保快速原型开发者可以在不成为基础设施专家的情况下尝试不同的模型和应用所有操作都在你定义的安全隔离区域中进行这在 k8s 中称为 namespace。这个抽象是沙箱成功的关键它在保持集中控制的同时赋能创新。3. 代码仓库 / 镜像仓库集中式代码仓库是一个安全且协作的 GenAI 沙箱的核心要素。它为开发者提供了一个统一、受控的环境来存储、管理和版本化代码防止敏感信息在不同、不安全的位置扩散。通过建立集中仓库组织可以执行安全策略、监控漏洞并保持所有代码变更的清晰审计记录这对于在沙箱环境中维护数据隐私和完整性至关重要。例如当像 GitHub 这样的服务与组织的身份和访问管理identity and access management - IAM及单点登录SSO解决方案见下面的要素 #4集成时它成为执行最小权限原则的强大工具。这种集成确保只有经过身份验证和授权的开发者才能访问特定代码仓库。你可以创建团队并应用精细化权限限制对敏感项目的访问防止未经授权的代码修改。这在 GenAI 场景中尤为重要因为代码可能包含专有算法、敏感数据连接器甚至在某些情况下包含组织或用户级凭证或其他机密信息。此外现代仓库平台提供自动化安全扫描功能。这些工具会持续扫描代码检测已知漏洞、不安全的编码实践以及暴露的密钥。如果开发者意外提交了密码或 API key系统可以自动标记并通知安全团队。这种主动的安全方法对于防止数据泄露、执行法律要求和保密合同义务以及确保在沙箱中开发的 GenAI 应用的整体完整性至关重要。通过强制所有开发在集中且安全的仓库中进行你为创新创建了透明、可审计且安全的基础让开发者可以自由实验而不影响组织安全。4. 身份和访问管理IAM 是安全、隐私优先的 GenAI 环境的核心组件。它为确保只有授权的个人和服务能够访问敏感数据和强大 AI 模型提供基础。一个健壮的 IAM 框架能够执行最小权限原则为用户或服务授予执行其功能所需的最低访问权限。4.1 单点登录Single sign-onSSO 通过允许用户一次身份验证即可访问多个应用和服务而无需重复输入凭证从而简化了用户访问。在沙箱环境中SSO 简化了开发者、数据科学家和业务用户的使用体验他们需要与 AI 生态系统中的各个组件进行交互例如数据仓库、建模工作台和部署管道。通过集中认证SSO 还增强了安全性减少了可能被泄露的密码数量并提供了执行认证策略的单一入口点。重要的是它降低了经验较少的开发者正确保护沙箱中数据的门槛从而防止敏感信息被内部人员或外部人员意外泄露。4.2 基于角色的访问控制Role-based access controlRBAC 是一种根据组织内用户角色限制网络访问的方法。在 GenAI 沙箱的背景下RBAC 用于定义和执行不同用户角色的权限。例如数据科学家角色可能对特定数据集具有读/写权限并能够应用机器学习模型而业务分析师角色可能只能对这些模型的输出进行只读访问。这确保了职责清晰分离并防止未经授权访问或修改敏感数据和 AI 资产。4.3 基于属性的访问控制Attribute-based access controlABAC 提供比传统 RBAC 更细粒度和动态的访问控制方法。ABAC 基于用户、被访问资源以及环境的属性组合来做出访问决策。例如访问一个特别敏感的数据集可以限制为用户属于数据科学家团队用户属性、访问被标记为 PII 的资源资源属性、并且是在工作时间从公司网络访问环境属性。这种细粒度控制在 GenAI 沙箱中对于执行复杂的数据治理和隐私要求至关重要。稍后在讨论搜索 AI 数据存储时我们会再次提到。4.4 访问可审计性Access auditability一个健壮的 IAM 框架还确保所有访问权限的授予、使用、审查和撤销都被精细地记录、可发现和可审计这样在任何疑似或确认的事件发生时响应人员可以快速了解发生了什么、遏制事件、评估其范围并全面补救其后果。这不仅对组织自身的安全至关重要也有助于遵守可能触发的任何事件报告和泄露通知要求。5. 密钥管理在我们配方中的所有要素中密钥管理或许是最重要的但也是最常被忽视的。就像少量藏红花就能显著改变一道菜的风味一样一个处理不当的 secret 也可能对组织的安全和声誉造成巨大且毁灭性的影响。在我们的场景中secret 指任何应用运行所需的敏感信息用于第一方或第三方服务的 API keys、数据库密码、信任证书或用于认证 LLM 的 tokens。当这些 secrets 被硬编码在源代码中或留在明文配置文件中时就会产生巨大的漏洞。泄露的 API key 或暴露的数据库凭证可以绕过其他所有安全措施为攻击者提供直接访问敏感数据和系统的途径。这在 GenAI 沙箱中尤为关键因为开发者经常需要连接各种数据源和外部模型提供者。如果没有健全的密钥管理策略你就相当于把通往王国的钥匙散落在数字环境中将你的创新沙箱变成潜在的数据泄露源。为妥善保护这些 secrets专用的密钥管理平台是必不可少的要素。这些工具提供集中加密的 vault 来存储 secrets并具备强大的访问控制、审计和动态轮换功能。无论你选择自托管解决方案如 HashiCorp Vault还是托管云服务如 Google Cloud 的 Secret Manager 或 AWS Key Management ServiceKMS原则都是相同的在运行时以编程方式将 secrets 注入到应用中。此做法确保 secrets 永远不会在代码中暴露保护你最有价值的凭证并保障沙箱环境的安全。这不仅仅是最佳实践由于密钥管理技术已经成熟并被广泛使用它构成了某些隐私法律和监管机构所参考的“最先进”标准用以评估组织的信息安全状况。未能使用最新技术保护组织最重要的 secrets不仅是错失良机也可能构成监管不合规因为执法机构和法院常会追究。6. 私有 LLM 部署在现代 GenAI 兴起初期使用托管服务如 Azure OpenAI的主要动因是保证客户的 prompts 和数据不会被用于重新训练公共模型。这是企业采用的关键第一步。然而随着该领域的发展讨论焦点已发生转变。虽然数据隐私仍然至关重要但使用私有 LLM 实例无论是来自主要云提供商还是自托管的决定现在同样受到对保证吞吐量、可预测延迟以及对模型运行环境的精细控制的需求驱动以支持生产级应用。这个关键要素有三种不同形式每种都有其有效使用场景及权衡A. 云托管 SaaS这是最常见且最易获取的方式。像 OpenAI Enterprise、Azure OpenAI、Google Cloud 的 Vertex AI 以及 AWS Bedrock 这样的服务通过托管 API 提供访问强大、最先进模型的能力。优点该方式提供最快的上市时间。云提供商处理所有底层基础设施、扩展和维护让团队可以专注于应用开发。它提供简单的按需付费模式并可访问多样的专有及开源模型库。缺点对底层基础设施的控制最少可能在高峰需求时出现性能波动。在极高使用量下成本可能更高并且依赖提供商的路线图和模型可用性。同时由于数据离开客户环境增加了应用的潜在漏洞面这对高度监管或强调数据主权的客户来说是一个挑战。B. 云托管 GPU 容器化 LLM这种方式是在云提供商的虚拟化 GPU 基础设施上运行开源 LLM如 Mistral 或 Meta 的 Llama 系列模型。通常使用我们之前讨论的容器化和 Kubernetes 编排管理并结合高性能推理服务器如 vLLM。优点提供了控制与灵活性的强大平衡。你可以直接控制资源分配、模型版本和服务配置从而实现显著的性能调优。在高并发场景下优化良好的推理服务器可显著提高吞吐量。例如基准测试显示像 vLLM 的推理引擎在高负载下相比非生产导向服务器提供更高的 tokens-per-second 和更低延迟 [Red Hat, 2025]。缺点运营负担更重。团队需要管理 GPU 实例、容器镜像和推理服务器配置。这需要更深的机器学习运维MLOps和基础设施管理技术以有效实施和维护。C. 本地 GPU 容器化 LLM最可控且通常最复杂的方式是在自己的数据中心内部署容器化 LLM。这种设置在功能上类似于第二种方式但去除了对公共云提供商硬件层的依赖。优点提供最高的安全性、控制力和数据主权。对于需要完全隔离环境、数据不离开物理场所的组织这是唯一选择。对于大规模、可预测的工作负载长期来看可以通过避免云数据出站费用和按交易收费而更具成本效益。缺点购买和维护高端 GPU 硬件的初始资本支出巨大。需要高度专业化的团队来管理物理基础设施、网络和整个软件栈。这种方式更难扩展因为需要物理采购和安装新硬件。7. 搜索 AI 数据存储如果 LLM 是我们 GenAI 应用的大脑那么数据存储就是它的心脏为推理提供相关且富含上下文的信息。为了让 RAG 应用真正有效它不能仅依赖简单的向量数据库。基础数据通常非常复杂包含非结构化文本、结构化元数据以及各种数据类型。因此你选择的数据存储必须具备独特的特性以在大规模下处理这种复杂性。支撑整个过程的是向量嵌入vector embeddings的创建它是相对于该嵌入空间知识集的数据的数值表示。为了实现语义搜索你的数据必须首先通过推理模型转换为这些数值表示。一个灵活的数据存储不仅应存储这些向量还应能够承载推理过程本身。关键是它应允许你使用所选择的模型无论是最先进的多语言模型、针对特定领域如金融或法律微调的模型、为高速度结果构建的紧凑模型还是能够处理图像的模型。通过管理推理该平台确保数据被一致且高效地向量化为后续强大的搜索功能奠定基础。首先它必须掌握混合搜索hybrid search。最优秀的检索系统不会强迫你在传统关键词搜索如 BM25擅长查找特定关键词和现代向量搜索擅长通过语义意义即自然语言查找结果之间做选择。一个真正强大的数据存储允许你在单个查询中同时使用两者。这确保你既可以找到匹配精确产品代码或缩略词的文档也可以找到概念上相关的文档为 LLM 提供最相关的上下文。其次它需要一种智能结果重排序intelligent result reranking的高级方法。当你运行结合多种方法的混合搜索时需要一种方式将不同结果集合并成单一且连贯的排序。倒数排序融合reciprocal rank fusion, RRF等技术在这里至关重要它们智能地结合来自不同查询的相关性分数生成的最终列表比任何单一方法单独提供的结果都更准确、更相关。最后面向搜索 AI 的数据存储必须是一个统一的引擎并内置安全性。对于企业级 RAG仅仅找到相似向量是不够的。你必须能够在搜索之前对数据应用安全和访问控制。前述的 RBAC 和 ABAC 功能允许在搜索时对内容进行预筛选确保向量搜索只在用户有权限访问的数据上执行。这降低了通过沙箱意外或恶意规避访问控制的风险同时保持可证明的隐私和保密合规性。这种能力将过滤、全文搜索和向量搜索结合在单一可扩展平台中是真正能够为安全、隐私优先的 GenAI 沙箱提供支持的数据存储的关键特征。8. APM 与安全我们配方中的最后一个要素确保整个沙箱的健康、安全和性能一个统一的平台用于 APM 和安全信息与事件监控SIEM。一个真正多功能的搜索 AI 数据存储的关键特性在于它不仅能为你的 RAG 应用提供R同时还能作为所有由基础设施和应用生成的日志、指标和追踪的标准化存储库。通过将这些运维数据整合到同一个强大的数据存储中你就创建了一个单一视图的可观测性和安全平台。这种方法提供了若干关键能力。在基础设施层面你可以监控托管沙箱的 k8s 集群和为 LLM 提供支持的 GPU 的性能和资源使用情况从而主动识别瓶颈或故障。在应用层面APM 提供详细的追踪用于诊断 GenAI 原型中的延迟问题或错误。在安全方面这个集中式数据存储成为你的 SIEM将登录事件、应用日志和网络流量关联起来以检测沙箱内的异常行为或潜在威胁。最重要的是这个统一平台让你能够深入了解 GenAI 应用本身的使用情况。通过收集和分析应用遥测数据其中应包括在许可范围内用户提交的 prompts可对 PII 进行脱敏处理你可以识别趋势、了解用户提出的问题类型并发现热门使用场景。这为改进你的 RAG 应用提供了宝贵的反馈循环并展示了使用单一可扩展数据存储来保障、监控和优化整个 GenAI 生态系统的强大能力。制作配方在所有要素就位后让我们看看如何将它们组合成一个生产级 GenAI 沙箱。就像任何食谱一样先来看成品效果的示意图这是最终架构可能的样子。图 2制作配方后的成品沙箱。如图所示的整体环境包括一个 Kubernetes 集群用于托管你的沙箱 AI 应用为持续集成和持续部署 [CI/CD] 管道设置 dev/preprod/prod 命名空间、用于认证的 IAM 基础设施、若干 GenAI 应用、代码和容器镜像仓库以及覆盖整个沙箱的 APM 和网络安全监控层。配方步骤 0策略基线在开始混合任何要素之前每个优秀的厨师都会进行 mise en place准备工作也就是为成功做好准备。在我们的配方中这意味着要为沙箱的使用建立清晰的策略。这是基础步骤你需要决定 “厨房规则”。开发者是否可以使用内部生产数据或者经过假名化pseudonymization、差分隐私differential privacy处理的生产数据或者类似真实的合成数据还是仅使用公开数据沙箱是完全自助的平台还是带有护栏的托管服务应用更新是否需要正式的变更审查委员会Change Review Board还是同行评审即可这些问题高度依赖组织的具体背景和目的。提前回答这些问题至关重要因为这些策略决策会直接影响你如何配置配方中的其他要素。配方步骤 1信息安全基线InfoSec baseline如 “要素” 部分所述IAM 是配方中不可或缺的一部分。在允许任何人进入 “厨房” 之前你必须确保外围安全只允许佩戴经批准的制服和符合要求的防护装备的授权厨师访问工具和原料。这意味着从第一天起就要直接与信息安全团队合作在强安全原则的基础上构建沙箱。对数据存储、代码仓库、Kubernetes 托管环境以及应用本身的访问都必须遵循既定的最佳实践进行限制。在环境中执行组织的 IAM 策略后一个实际的身份验证流程可能如图 3 所示。图 3反向代理认证用于保护工作负载免受未授权访问。如图所示在 Kubernetes 生产命名空间中的应用之间任何通信都必须先通过 OAuth 代理如 Vouch。这确保每个用户都通过中央认证提供者如 Okta进行身份验证并强制执行双因素认证等策略。在此模型中关键的用户上下文信息如用户名和 IP 地址可以随每个请求传递从而在应用层实现强有力的审计和不可否认性。配方步骤 2容器配置基线假设许多快速原型开发者是充满热情的创新者但未必是经验丰富的软件工程师或经过法律培训的数据合规专家那么提供基线配置至关重要以确保他们的成功与安全同时避免无意中违反任何规则或策略。可以将此步骤视为提供一张主配方卡以保证一致性。至少你应该提供关于如何构建容器镜像、将其部署到 Kubernetes 集群以及测试所有连接是否安全的清晰文档。更进一步你可以在代码仓库中创建一个 “Clone This Starter App” 模板。这样开发者就有一个预配置、经过安全验证的起点包含 Dockerfiles 和管道脚本他们可以立即 fork 开始试验大幅降低入门门槛同时从一开始就强制执行最佳实践。此外许多实际的 GenAI 使用场景不可避免地涉及某种形式的 PII 处理或者可能产生对个人如你的员工、消费者或客户的员工产生实质影响的输出。在这种情况下越来越多的州、联邦和国际法律要求在实际工作开始前完成各种风险评估。这些评估如果逐案进行不仅繁琐还难以规模化。使用 “Clone This Starter App” 方法也有助于防止这些合规要求成为创新的瓶颈因为在大多数法律要求下只需为模板完成一次所需评估任何不超出最初定义参数的克隆不必重复。配方步骤 3部署用户应用在策略明确、信息安全基线建立、开发者模板就绪后终于可以 “上菜” 了。无论你选择自助还是托管部署模式都可以自信地邀请组织中的快速原型开发者开始在沙箱中进行创作。由于你从一开始就包含了 APM 和安全日志要素 #8你具备必要的可观测性来监控应用性能和用户活动。这里就是魔力所在你可以从用户构建的应用中学习发现强大的新用例并收集真实世界的数据来改进平台同时保障组织数据安全。顺带一提这种方法还允许你自然收集可能需要记录、向用户披露或向审计员和监管机构共享的信息以展示你的 GenAI 应用的透明性、问责性和可解释性在构建过程中就完成许多合规要求而不是事后处理 —— 这是隐私设计Privacy by Design的典型最佳实践。下一步怎么做我们现在已经浏览完整本配方书从挑选新鲜要素到逐步执行配方。我们讨论的大多数领域容器化、APM、IAM 等本身就是独立的 “烹饪专长”。结论本配方书旨在提供一个清晰的制作生产级 GenAI 沙箱的 “食谱”。通过仔细挑选每一个基础要素从容器化平台和 Kubernetes 编排到搜索 AI 数据存储和统一 APM你可以确保最终成品既成功又安全。遵循配方可确保这个强大的环境从第一天起就建立在安全和周全策略的基础上。目标是赋能你的快速原型开发者而不是限制他们同时培养负责任的创新文化。通过提供一个安全、可观测且设备齐全的“厨房”进行实验你可以抢占先机促进负责任的创新文化。这种主动方法让你能够利用整个组织的创造力将出色的想法转化为可落地的原型同时防止“影子 AI”的出现。你已经完成了这顿创新大餐现在可以享受它带来的成果。如果你想讨论本内容或任何与 Elasticsearch 相关的话题欢迎加入我们的 Discuss 论坛。原文https://www.elastic.co/search-labs/blog/generative-ai-sandbox-data-privacy