“技术本身在被应用之前是道德中立的。”
——威廉·吉布森（William Gibson）
“AI 驱动”已经成了各类组织与产品最常用的形容词。夸张宣传当然不少，但确实有越来越多的公司希望利用自身数据，借助最新的 AI 进展做出有用的东西。就像“数字化转型”，AI 转型也是真实且正在发生的。
不过，最大的挑战是在确保完备治理与安全的前提下构建 AI 系统。你可能切身感受过：即便是经典的、相对简单的机器学习项目，也很难真正上线到生产。这往往是因为这些项目通常起步于数据科学家或 ML/AI 工程师的笔记本电脑——他们更关注数学与统计本身，而较少关注如何部署。在大多数 AI 项目中，安全通常是事后补救，治理更是缺位。再加上生成式 AI（GenAI）兴起，尤其是 OpenAI 的 GPT 系列，新的安全与治理难题接踵而至。
有些事件甚至显得“滑稽”。2024 年 1 月 18 日，X（原 Twitter）上有用户晒出与快递公司 DPD 的“AI 客服”对话记录。该机器人不仅没帮上忙，还在提示下写了一首诗自嘲其“无用”，并抱怨 DPD 糟糕。事件在社媒上广泛传播，DPD 迅速“修复”了 AI 模块，但名誉受损已难挽回。更严重的是 2023 年三星事件：员工将公司敏感源代码通过 ChatGPT 提交给 OpenAI，导致三星暂时全面禁止员工使用 GenAI 工具。类似案例不胜枚举，它们反映了 AI 快速落地带来的风险外延。
随着通用型 GenAI 模型（且常由第三方托管）的使用增多，组织的潜在安全暴露面被显著放大——例如将企业数据上传到第三方模型 API 提供方。这要求我们在应用、网络与基础设施多个层面统筹安全与治理。举例说，在网络层面，你得考虑为调用跨区域托管的模型而产生的跨区数据传输，而这在某些合规场景下是不被允许的。即便只在组织内部，要控制谁能访问训练好的模型、如何复现实验与结果，也并不容易。
缺乏完善的数据治理，会显著影响 AI 项目的可持续性——这一点常常让组织感到意外。事实是：AI 项目失败率很高。Gartner 指出，许多 GenAI 项目因数据质量差、缺乏明确业务价值、风险控制不足与成本上升，在概念验证后就被放弃。Gartner 还预测，到 2027 年，60% 的组织将因缺乏一致的道德治理框架而无法实现 AI 用例的预期价值。
由于 AI 的快速发展，更大的社会层面担忧也接踵而至：工作替代、贫富差距扩大、偏见歧视、虚假信息等。应对这些问题需要组织、政府与社会各界共同努力。
什么是 AI 治理？
随着 AI 更深地嵌入业务运营与日常生活，组织与社会必须用稳健的治理机制来同时管理它带来的机会与风险。AI 治理涵盖政策、结构化框架与实践，旨在确保 AI 技术以安全、负责、合乎伦理的方式被开发与部署。其范围很广，且与数据治理类似——没有一个全球“中央权威”来划定边界。它受国际、政府与行业层面的政策、流程与框架趋势影响。
国际层面会提出原则与全球标准，并影响国家与地区政策。例如，联合国（UN）设有 AI 顾问机构，经济合作与发展组织（OECD）发布了政府间 AI 原则。欧盟通过《AI 法案》（EU AI Act）在全球范围内塑造监管路径。微软、Meta、谷歌等科技公司与国际标准化组织（ISO）也在推动落地实践（如 ISO/IEC 42001）。
本质上，AI 治理是跨学科的：把技术、法律与伦理相结合，为 AI 的开发与使用建立结构化的环境与框架，适用于提供方与使用方。它由流程、标准与护栏构成，确保 AI 系统安全运行、符合伦理并遵守法规，覆盖 AI 全生命周期：从开发、部署，到持续监控与管理。
本章仅聚焦 Databricks 平台语境下可落地的治理环节：如训练数据与模型、模型服务化、访问与使用的防护（guardrails），以及可观测性。法律、伦理与社会层面的“责任 AI”不在本章讨论范围。
AI 模型生命周期
AI 项目中最重要的制品是模型，它由数据训练而成。简单说，训练好的模型就是其训练数据的“表征”。而在 AI 用例中，输入与输出也都是数据。因此，AI 治理本质上属于数据治理的一部分。见图 6-1。
图 6-1. AI 模型要素的简化示意
AI 模型生命周期主要分两阶段：训练与服务（推理） 。经典 ML 的训练相对简单，而 GenAI 的训练与对齐更复杂。本文为聚焦治理，仅以简化视角讨论 ML/AI；关于训练的细节可参考 Chip Huyen 的 Designing Machine Learning Systems。
注：本文将“经典 ML”与“生成式 AI”等统称为“AI 项目”。且由于本章聚焦安全与治理，多数 AI 概念都保持高层次描述。
模型训练
训练阶段的核心是训练数据集。在 Databricks 中，你将结构化/非结构化数据引入平台，并在 Unity Catalog 中注册为表或卷（Volume） 。你可将 Delta 表注册为特征表。借助 Databricks 托管的 MLflow，可以构建 ML 模型与 GenAI 应用；其与 OpenAI、Hugging Face Transformers 等工具链的集成，也便于管理与部署大语言模型（LLM）。后文会简述 LLM 相关注意点。
在 Databricks 上做 AI 的优势不止于“更简单”，还在于安全、可扩展与可靠。这主要得益于平台的安全优先理念与 Unity Catalog 的统一访问控制。在 GenAI 新范式带来层出不穷的安全问题之际，这些尤为关键，尤其当你要把模型真正推到生产时。
很多用户计划用外部托管的模型（如 OpenAI），他们最大的担心是组织数据会被发给第三方。不少人默认“发给 LLM 的数据都会被训练使用”，有时确实如此，但通常可以通过与供应商的合同来选择性退出（opt-out） 。当然，自训/自托管 LLM从安全上更可控，且在需要深度定制于自有数据时也更合理。
自训/定制 LLM 也有额外注意点。一些团队倾向于“能拿到的数据全喂给模型”。初衷是想最大化收益，但这可能违反敏感数据（如 PII）使用规范。如果把敏感信息训练进 LLM，后续泄露的风险会被放大。想象一个包含员工薪资的文件被放在了权限管理不严的 SharePoint 目录中——虽然这本来就不妥，但若它进入 LLM 训练集，模型接口就可能成为“更易访问的泄露入口”。因此，需要端到端可控的平台来覆盖模型开发、部署与服务，防止此类风险。
模型服务（推理）
训练或选定模型后，下一步是提供使用。处于“静态”状态的模型只是一组文件，通常只被训练所用的框架理解。你可以做离线（批量）推理：将模型加载到内存，对大量数据一次性推理，追求高吞吐（如定期更新推荐、批量图像分类）。也可以做实时推理：对单条数据低延迟预测（如自动驾驶障碍物检测、刷卡实时反欺诈）。
除了把自有模型上线为实时服务，Databricks 还支持外部模型（External Models） ：例如将 Azure OpenAI 作为后端。在 Databricks 工作区创建一个模型服务端点，其背后调用 Azure OpenAI；你向 Databricks 端点发送请求，平台转发到 Azure OpenAI，再把结果回传给你。
这种方式的好处是：对使用者的体验统一，无论后端模型换成 Azure OpenAI、Hugging Face 还是别的，都不影响上游调用；并且你还能叠加平台级的安全能力，如本章稍后会提到的 AI Gateway。
图 6-2 概括了一个 AI 项目从头到尾需要考虑的安全与治理要点。请注意：这些要点是端到端适用的，而非只在某个环节才考虑。
图 6-2. AI 项目的简化元素与对应的安全/治理关注点
在 Databricks 上治理 AI 系统
在第 1 章中，我们讨论了组织内部的孤岛如何导致不同的治理模型。放在 AI 项目里，这个问题更为突出，主要有两个原因：
- 大规模 AI 项目的迅猛增长跑在了标准化治理模型之前，导致实践支离破碎。
- 多数为结构化数据提供安全与治理框架的平台，并未对 AI 资产（文件、函数、模型）提供同等能力。
本节聚焦如何用 Databricks 平台与 Unity Catalog 来应对这些挑战。先看一个简单例子：假设你是一名参与 “Detecting Nemo（寻找尼莫）” 项目的 ML 工程师，需要训练一个模型，在图片中检测看起来像尼莫（迪士尼 2003 年电影《海底总动员》中的小丑鱼角色）的鱼。你们组织把 Databricks 作为数据平台之一。幸运的是，有平台团队替你完成了底座搭建。作为该项目成员，你在目录 ml_projects_dev 下新建的模式（schema）detecting_nemo 上被授予 ALL PRIVILEGES，并且拥有该目录的 USE CATALOG 权限。
你的训练数据集由一批 JPEG 文件和一个 CSV 构成，CSV 里存着图片文件名中的图像 ID 与“是否存在尼莫”的映射。第一步是把这个数据集引入 Databricks。由于数据集当前是固定的，有两种方案：
- 方案一：用云厂商原生工具拷贝文件到云存储，并在有定义 EXTERNAL LOCATION 的位置落地。随后创建一个外部卷（external volume） ，即可通过 Unity Catalog 访问这些文件。看似最直观，但问题在于：摄取行为本身不受 Unity Catalog 治理，因为你需要直接访问存储账号来拷贝文件。若文件非常大，此方案仍可取。建议务必用自动化方式写入文件，并将直连存储的主体（principal）严格最小化。
- 方案二（我们更推荐）：使用 Files API 将文件摄入 Databricks 平台。做法是创建一个托管卷（managed volume） ，然后以该卷为目标可保对象（securable），通过 Files REST API 上传。这样数据摄取过程也受控且可治理。当数据（尽管仍然是原始形态）被 Unity Catalog 编目后，你即可对其施加访问控制。注意：卷上只能对卷本身授权，不能对卷内单个文件细粒度授权。你可以基于 CSV 建一张表保存映射关系——这样就有了可授权的表级可保对象，并能获得血缘与其他元数据；卷中文件级别是没有这些元数据能力的。
下一步，你用 MLflow 训练多版模型，并将它们持久化到项目对应的目录与模式中。评估后选择表现最好的一个。对于批量图片的“寻找尼莫”，你可以在 Unity Catalog 里创建一个函数，内部调用最佳模型的预测函数并返回结果；或者开通模型服务（Model Serving） ，把模型打包为 REST API 端点，供实时检测新图片。除此之外，你还能做一个 Databricks Apps 应用，让用户使用 Databricks 凭据或 SSO 登录、上传图片，并查看是否检测到尼莫。
我们不展开训练、评估与预测的细节——本书关注点不在 ML/AI 本身，而在治理。从这个简例中可以看到：从原始数据摄取到模型服务，全流程都能受益于 Databricks 平台提供的安全与治理能力。见图 6-3。
图 6-3. 模型训练到服务的端到端简化流程
MLOps
为了更快交付高质量软件并快速吸收反馈，业界形成了 DevOps：把开发（Dev）与运维（Ops）融合，借助自动化提升可靠性。DevOps 反映了软件开发的文化变迁：开发者与工程师也会在一定范围内承担测试、部署与平台管理的职责——这离不开云与 Kubernetes 等技术的兴起。
当 ML 项目走向主流后，自然需要“DevOps 的等价物”。传统软件主要由代码、配置与依赖组成，核心在于版本管理、打包、测试与跨环境部署。而 ML 项目很大一部分由数据集与模型构成，单靠常规 DevOps 远远不够，于是出现了 MLOps——旨在贯穿模型从开发、训练到部署、监控与运维的端到端方法论与最佳实践。本质上，MLOps = DevOps（代码）+ DataOps（数据）+ ModelOps（模型） 。
实施到位的 MLOps 可带来：
- 协作：促进数据科学家、ML 工程师、DevOps 与 IT 的协作，顺畅地把模型从研发推向生产。
- 自动化：自动化数据准备、训练、测试、部署与监控，减少人为错误，加速流转。
- 持续集成与部署（CI/CD） ：将 CI/CD 原则用于 ML，支持版本化、迭代更新与可靠发布。
- 监控与治理：对生产模型进行监控，自动发现数据漂移等问题并缓解；遵循监管合规要求并随法规演进调整流程。
- 可扩展与可复现：标准化框架与流程便于在组织内快速规模化，并保障结果可复现、可审计，同时能承载不断增长的数据量。
在 Databricks 上的 MLOps 走数据中心路径，可依托 MLflow 与 Unity Catalog 等核心能力实现上述目标：
- 协作：工作区（Workspace）的 Notebook、Git 集成与托管 MLflow 支持协同建模；Unity Catalog 通过跨工作区的数据与模型授权，促进协作。
- 自动化：用 Lakeflow Jobs 实现端到端自动化；采用 Databricks Asset Bundles（DABs） 这类 IaC 模板化方式，简化在 Databricks 上落地 MLOps 最佳实践。
- CI/CD：借助 Git 集成、模型版本管理、MLflow 实验跟踪等能力构建 CI/CD；DABs 进一步降低搭建与维护成本。
- 监控与治理：Unity Catalog 负责治理（编目、授权、审计、血缘）。Databricks Lakehouse Monitoring 可监测数据统计性质与质量；通过推理表（Inference Tables） （记录模型服务请求/响应的 Delta 表）监测模型表现与潜在漂移。
- 可扩展与可复现：平台原生的“面向大数据”的设计保障规模化；托管 MLflow 与 DABs 降低复现难度。
在 Databricks 上，通常用独立的工作区与目录隔离开发/预生产/生产等环境。与纯软件不同，数据与 AI 资产的“跨环境传播”要复杂得多。例如：训练几乎总要用生产数据——这意味着在开发环境也要访问生产数据；又如：若在开发环境完成训练，是否需要把“训练代码”同步到预生产与生产（尽管这些环境里不执行训练）？另外，模型上线往往需要支持A/B 测试与灰度发布等业务诉求。深入的工程落地细节超出本书范围，推荐参考 The Big Book of MLOps。
大语言模型（LLM）
2010 年作者 Karthik 入行时，“机器学习/人工智能”还是小众词，多指神经网络、线性/逻辑回归、随机森林等；NLP 以规则、统计与传统 ML 为主，能胜任部分结构化任务（情感分析、文本分类），但灵活性与扩展性有限。如今的 LLM 本质是更强大的 NLP 模型，擅长开放式问答、摘要、文本与代码生成等，用例激增。
LLM 仍是 ML 模型，但训练与使用方式与传统 ML 差异很大：它们“很大”，需要海量数据与算力（含 GPU） ，投入巨大，因此大多数公司不会自训通用 LLM，而是使用厂商提供的通用模型。大体分为两类：
- 闭源：由厂商托管，提供 API/UI，例如 OpenAI、Anthropic。
- 开源：可自由下载、修改与自托管，例如 Meta 的 Llama、Mistral AI 的 Mistral 系列。
通用模型对“通用任务”表现更佳，而对需要组织上下文的任务则需要微调开源模型或自训；前者更现实、成本更低。出于安全考虑，很多组织倾向自托管，避免把数据发给第三方。
今天的“模型服务”可能意味着：
- 服务自训/微调且自托管的模型；
- 服务预训练且自托管的模型；
- 转发到外部托管的模型（新挑战，治理最难）。
对于第 3 种，需要考虑：
- 数据安全：传输需 TLS 1.2+；若涉及敏感数据，建议字段级加密。
- 数据保留策略：核验厂商的保留策略，优先选择零保留。
- 输入/输出过滤：入参预处理（脱敏 PII、凭证等），出参后处理（去除风险内容）。
- API 治理：密钥入库保管而非硬编码；强鉴权与最小权限、限流、请求日志、IP 白名单与防火墙。
- 运维治理：记录请求/响应并监控异常流量与敏感泄露；制定应急预案（如快速吊销凭证）。
- 供应商风险管理：要求安全与合规证明、第三方审计、数据保留/所有权/泄露通报/合规责任等条款。
Databricks 的 Mosaic AI Model Serving 是模型服务能力（“Mosaic” 源自 2023 年并入的 MosaicML），它像一个统一接口层，可同时访问 Databricks 托管与外部模型（见图 6-4）。它提供统一 UI、访问控制，并利用平台的核心安全与治理；还可启用 Mosaic AI Gateway 管理 API 使用。
图 6-4. Mosaic AI Model Serving 为 Databricks 托管与外部模型提供统一接口
注：随着“通过 API 使用通用模型”的趋势兴起（LLM 带动），MLOps 也在演进——训练频次下降，重心转向托管/服务化与通过第三方 API 使用。面向 LLM 的运维也常被称为 LLMOps。
Mosaic AI Gateway
当你在 Databricks 上创建模型服务端点时，可以启用 AI Gateway 功能，包括：
- 限流（Rate limiting） ：按用户、按端点限制请求速率。
- 载荷日志（Payload logging） ：把模型输入/输出记录到 Delta 表，用于监控与审计。
- 用量追踪（Usage tracking） ：在系统表中记录端点的运行与成本，用于运营监控。
- AI 防护（AI guardrails） ：自动检测并拦截不安全/有害内容（暴力犯罪、自残、仇恨等），以及可选的 PII 检测/拦截/掩码；可分别对输入与输出启用。
- 回退（Fallbacks） ：部署或运行异常时，将请求路由到端点上其他模型以降低故障影响。
- 流量分配（Traffic splitting） ：在多模型间分流，便于 A/B 测试 与验证。
这些开箱即用的能力解决了生产模型服务的大部分通用难题，而且对模型类型与来源无关——无论你在/通过 Databricks 使用 Azure OpenAI、AWS Bedrock、Meta Llama 3 等，都可受益于这套通用“网关 + 护栏”。
AI 系统的组成组件
到目前为止，我们已分别讨论了 AI 治理的各个方面与组件。现在让我们拉远视角，从全局看看运行在 Databricks 上的一套 AI 系统，如图 6-5 所示。
图 6-5. Databricks 上端到端 AI 系统的组成组件（简化）
Databricks 上简化的端到端 AI 生命周期可分为四个阶段：
- 从原始数据开始，可在 Unity Catalog 中以 volume 编目。对数据进行清洗与探索性数据分析（EDA），并构建用于训练与测试模型的特征。
- 运行多轮实验来训练、评估并选择表现最佳的模型。若是对现有模型进行微调，步骤基本一致。也可以直接选用外部模型，此时跳过训练、只做评估与选型，可结合公开基准进行对比。
- 模型就绪后，进入使用阶段：要么做批量推理，要么做实时推理。
- 模型服务上线后，将你的 AI 应用接入该模型服务端点以获取预测结果。对离线批推，可使用 Spark DataFrame，或创建可由 SQL 调用的 AI 函数。
如需，还可以将请求/响应日志记录为推理表（inference tables） ，供分析与模型改进。
在治理层面，Unity Catalog 覆盖所有资产：volume 中的原始数据、表格形式的数据集与特征、已训练/微调的模型以及函数。模型服务由工作区（workspace）控制项与 AI Gateway 进行治理。
把 AI 系统当作“黑箱”并无助益；最佳做法是将其拆分为关键组件，识别每个组件的风险并制定缓解策略。这也有助于评估平台是否具备相应能力，便于你高效应对这些风险。关于 Databricks 上 AI 系统的风险与对应缓解策略的详细分析，参见 Databricks AI Security Framework（DASF） 。
实施一套 AI 系统
与许多公司一样，Nexa Boutique 也想抓住 AI 浪潮做出亮眼成果。它们已有多支团队在各类场景里应用传统 ML，但这是首次高层（CTO、CDO、甚至 CEO）高度关注并提供预算。零售业务背景下，团队很快设想出多种可受益于最新 AI 技术的用例；但如何构建安全、可靠、可运维的端到端 AI 系统经验不足。于是他们决定先聚焦一个用例，跑通后再模板化复用。
他们选择了面向终端客户的智能客服聊天机器人：该方向在业界已有诸多落地案例与资料，技术团队也更容易参考与对标。首版计划直接使用一个不做定制的 LLM。
技术栈方面，由于 Databricks 在组织内覆盖面广、团队也熟悉平台，Nexa 评估后发现：Databricks 基本具备搭建与运行 AI 系统所需的能力；更关键的是，大部分数据已在 Databricks 中，可避免跨平台拷贝数据。同时，虽然并非完美，但 Databricks 提供了端到端的安全与治理模型，这是其他平台少见的。
就 GenAI 方案，Nexa 选择 Azure OpenAI：一方面出于 OpenAI 的流行度，另一方面因与微软既有合作，可免去新供应商的冗长安全合规审批。
技术路线选择 RAG（检索增强生成） ：通过在生成前检索实时/专业知识，提高回答的准确性、时效性与上下文相关性。对频繁变化或领域专属的信息（如零售知识库）尤为合适。为加速检索，RAG 依赖向量检索——用向量（文本/图像/音频的数值表示）与相似度算法来匹配语义近似内容，而非关键词匹配。
在 Databricks 上，可结合 MLflow 与 LangChain 来集成 LLM；Mosaic AI Vector Search 可用于构建向量检索索引以加速嵌入向量的检索。Nexa 按如下步骤在 Databricks 上构建了 RAG 链：
- 选定现有 Databricks 工作区搭建聊天机器人 AI 系统；
- 为外部嵌入模型与对话模型创建 Databricks 模型服务端点（底层使用云厂商的 AI 服务）；
- 创建一个 Vector Search 端点；
- 基于该向量检索端点与嵌入模型端点，建立向量索引；
- 使用 MLflow + LangChain 在 Unity Catalog 中创建并注册 RAG 链模型；
- 为 RAG 链创建模型服务端点以编排全流程；
- 创建 Mosaic AI 代理评估应用用于系统评审；
- 使用 MLflow tracing 观察 RAG 链任务；
- 评估通过后，使用具备 OAuth 令牌的 服务主体（SP） 将 RAG 链端点接入到聊天机器人应用；
- 治理由 Unity Catalog、工作区控制项与 Mosaic AI Gateway 共同保障。
图 6-6. 使用外部嵌入与对话模型的 RAG 聊天应用
该聊天机器人 MVP 在数周内完成并快速获得全公司关注，取得成功。一个对 GenAI 了解尚浅的小团队，用极小的成本与工作量完成了高关注度的用例。随后在走向生产时，他们补充了应用层改造、回退机制、事件响应与合规检查等。此方案被模板化，后续用例基本复用相同模式，主要变量是所选 LLM：部分团队采用 Databricks 的基础模型，部分采用外部闭源托管模型——很好地体现了他们“即插即用”的架构。
小结
本章梳理了在实现 AI 用例时需要强治理与高安全的关键动因，聚焦了 Databricks 平台上达成这些目标的核心要点，并展示了一套端到端 AI 系统在 Databricks 上的形态，以及 Nexa Boutique 如何基于 Databricks 实施 RAG 聊天机器人。第 7 章将进一步讨论 Databricks 上数据与 AI 资产的可发现性，并介绍实现可观测性的可用方案。
