1. 课程导入与Databricks平台概览
生成式 AI 项目真正困难的部分，往往不是调用一个大模型，而是让模型稳定地拿到"对的、新的、可追溯的"数据，并把它的输出安全地交付给业务。传统数据平台擅长批处理报表，却难以应对 RAG（检索增强生成）场景下对向量检索、低延迟特征读取、Prompt 版本管理和输出质量评估的混合需求。本节先建立整体认知：生成式 AI 数据工程的核心挑战是什么，Databricks Lakehouse 用什么架构回应这些挑战，以及 Unity Catalog 与 MLflow 在其中各自扮演什么角色。
一、生成式 AI 数据工程的核心挑战
把 GenAI 应用拆开看，它其实是一条从原始数据到最终回答的链路：文档、日志、业务库表经过清洗与切分，转成向量写入索引；用户提问时先做检索，把命中的上下文拼进 Prompt，再交给模型生成答案；答案还要被评估、被记录、被审计。这条链路上有四个典型痛点。
- 数据新鲜度与一致性：企业知识库每天都在变，如果向量索引一周才重建一次，模型就会引用过期制度。数据工程需要支持增量更新，让"源表变更 → 重新切分 → 重新嵌入 → 索引更新"成为可调度、可回溯的流水线。
- 多模态与非结构化数据治理：PDF、图片、工单文本、音视频转写稿，这些数据过去很少进入数仓。它们既要能被检索，也要有权限、血缘和质量约束。
- 成本与延迟的平衡：嵌入模型调用按 token 计费，向量检索有延迟，大模型推理更贵。工程上必须决定哪些内容预计算、哪些实时算，缓存放在哪一层。
- 可评估、可追溯：模型回答错了，是检索没召回，还是 Prompt 写得不好，还是模型本身能力不足？没有实验追踪和评估数据集，团队只能靠"感觉"调参。
这四点决定了 GenAI 数据工程不能只靠一个向量数据库加一段 Python 脚本，而需要一个同时具备数据管理、模型管理、权限治理和实验追踪能力的平台底座。
二、Databricks Lakehouse 架构如何回应
Lakehouse 的核心思路是：用开放格式（Delta Lake）在对象存储上同时提供数据湖的灵活性和数仓的事务能力，再在同一份数据之上叠加计算引擎与 AI 运行时。对 GenAI 而言，它带来三个直接好处。
第一，一份数据、多种负载。原始文档落在 Bronze 层，清洗切分后的文本块落在 Silver 层，向量索引和特征表落在 Gold 层。批处理用 Spark，交互查询用 SQL Warehouse，模型推理用 GPU 集群，它们读的是同一份 Delta 表，不需要在系统之间反复搬运和同步。
第二，Delta 表天然支持增量与时间旅行。当源文档更新时，可以用 MERGE 只处理变化的行，再触发嵌入更新；如果某次索引重建出错，可以用 VERSION AS OF 回滚到上一个正确版本。这对 RAG 索引的稳定性非常关键。
第三，向量检索与结构化过滤可以共存。Databricks 支持在 Delta 表上建立向量索引，检索时既能做相似度搜索，也能叠加 WHERE 条件（例如只检索某部门、某生效日期之后的文档），避免了"向量库和业务库两张皮"的权限与一致性问题。
下面这张图把本节的关键对象放在同一条链路上：左侧是数据与治理层，中间是 Lakehouse 的存储与计算，右侧是 GenAI 应用与评估，Unity Catalog 和 MLflow 分别横跨治理与实验两条主线。
三、Unity Catalog 与 MLflow 的角色定位
Unity Catalog 解决的是"谁能访问什么、数据从哪来、模型和索引归谁管"。在 GenAI 场景里，它把表、视图、函数、模型、向量索引统一纳入三级命名空间 catalog.schema.object，权限可以精确到列和行。这意味着当用户提问时，检索环节可以按调用者的身份过滤文档，而不是先检索出全量结果再在应用层裁剪——后者极易造成越权泄露。同时，血缘信息能回答"这个回答引用了哪些源表"，为审计提供依据。
MLflow 解决的是"这次效果变好是因为改了哪一步"。它记录每次实验的参数（切分长度、嵌入模型、top-k、温度）、指标（召回率、答案忠实度、平均延迟）和产物（Prompt 模板、索引版本）。在 GenAI 中，Prompt 本身就是需要版本管理的资产，MLflow 的 Prompt Registry 让"v3 比 v2 好在哪里"有据可查。当评估发现某类问题回答质量下降时，可以对比两次运行的参数差异，快速定位是切分粒度变了还是模型换了。
四、一个最小可运行的认知示例
假设我们要为企业制度问答搭建原型，可以用如下方式组织第一版流水线（参数为教学示例，非实测结果）：
-- 1. 在 Unity Catalog 下建立分层结构
CREATE CATALOG IF NOT EXISTS genai_demo;
CREATE SCHEMA IF NOT EXISTS genai_demo.knowledge;
-- 2. Silver 层：切分后的文本块，带来源与生效日期
CREATE TABLE genai_demo.knowledge.doc_chunks (
chunk_id STRING,
doc_id STRING,
content STRING,
effective_date DATE,
department STRING
) USING DELTA;
-- 3. 增量更新：只处理新增或变更的文档
MERGE INTO genai_demo.knowledge.doc_chunks AS t
USING staging_new_chunks AS s
ON t.chunk_id = s.chunk_id
WHEN MATCHED AND t.content <> s.content THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
-- 4. 检索时叠加权限与时效过滤
SELECT chunk_id, content
FROM genai_demo.knowledge.doc_chunks
WHERE department = current_user_department()
AND effective_date <= current_date()
ORDER BY vector_similarity(embedding, query_embedding) DESC
LIMIT 5;这段示例体现了本节的核心逻辑：切分结果以 Delta 表落地，用 MERGE 做增量，检索时把权限和时效作为过滤条件与向量相似度结合。嵌入模型的选择、切分长度（例如 512 token、重叠 64 token）和 top-k（例如 5）都属于需要实验对比的参数，应交给 MLflow 记录，而不是凭直觉固定。