AI 数据流水线、特征平台与特征工程

• 对 AI 基础设施各组件职责边界的理解
• 数据、特征、模型、推理、监控之间的数据流与依赖关系
• 分层架构与可组合性设计

AI 平台通常按"AI 基础设施"和"AI 应用层"两层组织。底层是训练集群（GPU/CPU 资源池，负责训练与大规模推理），上层是数据流水线（负责数据采集、清洗、转换、批/流处理）、特征平台（负责特征定义、计算、存储与在线/离线服务）、模型仓库（负责模型版本、元数据、产物与依赖的存储）、推理服务（负责模型在线/离线部署与请求响应）、监控系统（负责资源、模型效果、数据质量、特征漂移的全链路观测）。协同关系是：数据流水线产出训练/测试数据集并写入训练集群；特征平台在训练与推理两侧提供一致的"特征读取"（training-serving skew 治理）；训练产出的模型及元数据进入模型仓库，由推理服务拉取并部署；监控系统对数据、特征、模型、在途流量进行全链路观测，并将漂移/衰减信号回传给数据流水线与特征平台触发数据回流或模型重训。分层上，平台遵循"控制面（编排、元数据、治理）与数据面（计算、存储、网络）分离"、"资源与业务解耦"的原则，各组件通过标准 API 与统一元数据（如 OpenTelemetry、统一的模型/特征元数据）松耦合集成。

该题考察的是"端到端"思维。回答时应强调组件不是孤立的，而是通过统一的数据流、元数据与 API 组装成闭环：数据 → 特征 → 模型 → 推理 → 监控 → 回流。A/B 面分离、控制面/数据面分离、标准接口是平台可演进、可插拔的关键。

• PSI/KS 的数学含义与适用场景
• 漂移与模型效果衰减之间的因果/相关分析
• 告警分级与人工介入流程（诊断、决策、处置）

PSI（群体稳定性指数）常用于衡量特征或模型评分分布在不同时间窗口（如训练期 vs 上线后）之间的偏移程度，经验阈值通常为 PSI<0.1 表示稳定、0.1~0.25 表示轻微漂移需要关注、>0.25 表示显著漂移需介入。KS 则用于衡量两个分布之间的最大差异，常用于区分正负样本或判断模型区分能力的衰减。当数据漂移告警触发后，不能仅凭漂移判断，应结合模型业务指标（AUC、准确率、点击率、转化率等）做关联分析：若漂移与效果衰减同时出现，通常是"数据漂移导致模型失效"；若漂移但效果未变，可能只是特征分布的自然变化，模型鲁棒性尚可。人工介入流程一般分四步：一是确认告警真实性（排除数据质量问题、统计口径错误、埋点异常）；二是定位漂移源（单特征还是多特征、上游数据源变更、业务政策变化）；三是评估影响范围（受影响用户/场景、对业务指标的影响量化）；四是决策处置（更新特征、重训模型、加样本回放、校准阈值或回滚到旧版本）。整个过程应形成可追溯的告警工单与复盘记录。

考官既考察对 PSI/KS 定义的理解，也考察"告警如何落地为可执行动作"。核心是"漂移≠一定出问题，需与业务效果关联"，并强调人工介入要有标准化流程而非临时救火。

• training-serving skew 的产生原因
• 在线/离线日志对比（log-based reconciliation）
• 特征值校验机制（统计对比、schema 校验、实时比对）

training-serving skew 指训练时使用的特征与在线推理时使用的特征不一致，来源包括：同一特征在离线用"当天整点"取值、在线用"当前实时值"取值；特征逻辑在离线/在线各写一份导致实现漂移；时间穿越（训练时读到未来数据）；缺失值处理不一致等。检测手段主要有：一是 log-based reconciliation（日志回放对账），把在线推理时真实取到的特征值、时间戳记录下来，与离线按同一逻辑重算的值做对比，统计不一致率与分布差异；二是统一的特征定义做到"一份定义、两处计算"（definition-as-code），从根本上消除双写；三是时间一致性校验，确保训练样本中的特征不包含标签之后的信息（避免 data leakage）。特征值校验可通过 schema 校验（类型、范围、枚举）、值域合理性校验、缺失率与 NaN 统计、以及随机抽样在线/离线特征分布的 PSI/KS 对比来实现。治理上强调"validate before train"与"validate before serve"两道关卡，以及特征审计日志。

这是特征平台的核心价值点。回答应突出"定义单一来源（single source of truth）"加"日志对账"双保险，并点出时间穿越与双写实现是 skew 的两大根源。

• 特征定义即代码（definition-as-code）与 DSL
• 批/流同源同构的共享计算逻辑
• 双链路对账机制（时间窗口、容忍度、差异处理）

共享定义的核心是"定义即代码"：把特征逻辑抽象为一份声明式 DSL 或共享函数库，由同一份描述同时生成离线批处理（Spark SQL/DataFrame）与实时流计算（Flink SQL）的执行计划，确保同一特征在两条链路使用相同的计算表达式、窗口、聚合方式与时间戳语义。对账上，通常以离线批处理为基准（ground truth），把实时链路在相同时间窗口内计算的结果与离线结果做对比，对比维度包括数值差异、缺失率、分布差异；由于实时端存在数据到达延迟与窗口截断，对账需设置合理的时间对齐（如按事件时间对齐）与数值容忍度（容忍误差比例），对差异超阈值的特征触发告警并标记为"不可信"，训练时排除或降权。对账频率可以有每日全量对账与分钟级抽样对账，兼顾成本与时效。

要点是"同一份定义减少双写漂移"加"以离线为基准的对账闭环"。回答应强调时间语义对齐与容忍度是双链路对账的关键工程细节。

• 各仓库的定位差异（ML 元数据 vs 模型权重 vs 容器镜像）
• 版本、stage、血缘管理
• 权限治理（RBAC、审批、审计）

MLflow Model Registry 侧重 ML 元数据与生命周期管理，提供 model version、stage（Staging/Production/Archived）、annotations、webhook 审批流转，适合与训练流程、Kubeflow 深度集成；Hugging Face Hub 侧重模型与权重的分发、社区生态与模型卡片，适合开源模型与模型 hub 场景，但生产级权限与合规治理较弱；Harbor 本质是 OCI 容器镜像仓库，可承载模型镜像（含模型权重+推理运行时），提供镜像签名、漏洞扫描、不可变 tag 等安全能力，适合把模型作为镜像进行部署与审计。工程上常采用"元数据仓库 + 对象存储/镜像仓库"的组合：MLflow/自建 registry 管版本与元数据，模型产物存对象存储或 Harbor 镜像。权限治理上，模型仓库应支持按团队/项目隔离的 RBAC，对"发布到 Production"这一动作进行审批（如需 Reviewer 双人审批），记录不可变版本与不可变 tag（immutable tag），提供完整审计日志（谁、何时、将哪个版本从哪个 stage 提升），并支持模型访问的细粒度授权与数据安全策略（如敏感模型加密存储）。

回答要先区分三类仓库的本质差异（元数据 vs 权重 vs 镜像），再谈组合使用，最后落到权限治理的"审批+不可变+审计"三要素。

• AutoFE 的适用场景（大规模、高维、与 AutoML 结合）
• 自动生成特征的可解释性与可审计性风险
• 与人工特征工程、领域知识的平衡

AutoFE 通过搜索/演化/基于深度学习的方案自动生成交叉特征、组合特征或高阶变换，适合特征维度大、可搜索空间明确、训练迭代频繁的结构化场景，能减少人工探索成本、提升模型上界。但它的适用边界在于：自动生成的特征可能缺乏业务语义、可解释性差、存在过拟合风险，且难以直接度量业务价值；在强监管、需要可解释特征（如风控、信贷、医疗）的领域，AutoFE 生成的复杂交叉特征难以通过合规审查。同时 AutoFE 结果的稳定性与可维护性较弱，生成的"魔法特征"难以在特征平台中进行血缘与版本管理。因此工程上往往把 AutoFE 作为"候选特征生成器"，产出特征后仍需领域专家审核、纳入特征平台做血缘与监控，并保留人工特征作为基线与兜底，保持可解释性与可审计性。

题目关键词是"边界"，回答应既肯定 AutoFE 的价值，又指出其在可解释性、可审计性、过拟合等方面的风险，并给出"自动生成+人工审核+纳入血缘管理"的平衡做法。

• 特征平台的分层（定义层、计算层、存储层、服务层）
• 批/流一致性、在线/离线存储
• 服务 API 的形态与 SLI

特征平台通常分四层：一是特征定义层（registration layer），以声明式 DSL 或 Python SDK 定义特征（名称、来源、计算逻辑、聚合窗口、on-demand 转换），集中登记到特征注册表（feature registry），形成单一事实来源；二是计算层（compute layer），用批处理引擎（Spark）与流计算引擎（Flink）从同一份定义分别生成离线与实时特征，保证训练/serving 一致；三是存储层（storage layer），采用在线存储（如 Redis、DynamoDB、Feast 的 online store）与离线存储（数据湖/对象存储）双写，在线存储面向低延迟读取，离线存储面向训练批量读取；四是服务层（service/API layer），对外提供在线特征查询 API（基于实体 ID 批量取特征，低延迟、高 QPS）与批量特征导出 API（面向训练），并配套特征血缘、监控、对账等治理能力。服务 API 需定义明确的 SLI（如 P99 延迟、正确率、可用性）与缓存策略。

分层回答体现工程组织能力。核心是"定义层单一来源 + 计算层批流同源 + 存储层双写 + 服务层统一 API"的结构，并强调在线/离线一致性由定义层保证。

• 特征版本化与不可变（immutable feature）
• 特征血缘（lineage）追踪上游数据与下游模型
• 特征与模型版本的对齐（绑定、重建）

特征版本管理要做到"不可变"：每份特征定义一经发布即生成不可变版本号，任何变更（逻辑、来源、窗口、补数）都产生新版本，从结构上杜绝"看似同名、实则已变"导致的历史训练不可复现。血缘追踪上，特征注册表记录每个特征的"上游数据源/表 + 计算逻辑 + 下游使用的模型版本"，形成可查询的数据血缘图，当特征变更时能自动盘点受影响模型。与模型版本对齐上，训练时把特征版本号（feature set version）与模型版本一起固化进模型元数据（如 MLflow 的 run 参数），保证"这个模型是用哪一版特征训练的"可追溯；若特征变更导致旧模型失效，可基于特征版本回溯重建训练数据并重训。回滚时，由于特征版本不可变，可安全地把某个模型重跑在旧特征版本上，实现"特征维度的时间旅行"。

核心是"不可变版本 + 血缘 + 元数据绑定"三位一体。回答应强调特征版本与模型版本的绑定关系，使"可回溯、可回滚"落在可操作的机制上。

• 各框架的定位与核心抽象
• 对 Kubernetes、数据、实验追踪的适配
• 适用场景与生态差异

Kubeflow 是面向 Kubernetes 的端到端 ML 平台，提供训练算子（TF/PyTorch Job）、Kubeflow Pipelines、模型服务与 Notebook，适合深度绑定 Kubernetes、需要统一平台能力的团队，但组件多、复杂度高。Metaflow 由 Netflix 开源，强调"数据科学家本地开发 + 云端平滑运行"，以 Python 为核心，通过 step 声明 DAG、内置版本化与数据对象存储，适合从原型到生产快速迭代、团队以 Python 为主、希望减少 K8s 学习成本；Metaflow 也能跑在 K8s/Argo 等后端上。Flyte 是强类型、可编译的编排引擎，把任务当作可复现的"工作流/任务"对象，强调查度、缓存、可重试与多租户，适合为生产级、大规模、强类型数据/ML 管线提供平台支撑。Argo Workflows 是 Kubernetes 原生的工作流引擎，以声明式 YAML 定义 DAG，与 GitOps、K8s 生态天然契合，适合通用 CI/ML 步骤编排，但类型与数据衔接能力较 Flyte 弱。取舍上：重度 K8s 原生选 Argo/Kubeflow；数据科学家友好、Python 优先选 Metaflow；生产级强类型平台选 Flyte。

框架对比题要抓住"定位差异"而非罗列功能。给出"场景→框架"的映射，并说明无需二选一（如 Metaflow 可跑在 Argo 后端上）。

• 批/流同源、同构计算
• 时间语义统一（事件时间、窗口）
• 对账与 Lambda/Kappa 架构

保障批/流特征一致性的核心思路是"同源、同构、同语义"。同源指批与流读取同一份底层数据源（如 Kafka 落地进数据湖的双写），使用统一的事件时间戳而非处理时间；同构指批处理与流计算使用同一份计算逻辑（同一 DSL/共享函数），避免两套实现漂移；同语义指统一窗口定义（如基于事件时间的天窗口）与聚合语义。架构上，传统 Lambda 架构需对批/流结果做对账与合并，复杂且易错；现代趋势是 Kappa/完整流处理，以流为主、批作为流的重放（replay）或补数，从而天然一致。工程上还要配合"以离线为基准的双链路对账"与"时间穿越防护"（防止训练时读到未来数据）。最终目的是让在线推理与离线训练拿到的特征一致，消除 training-serving skew。

关键词是"一致性"，回答应聚焦"同源同构同语义 + 统一时间语义 + 对账"，并顺势提到 Kappa 架构对 Lambda 的简化。

• 在线特征延迟目标（秒级/分钟级）
• 强一致 vs 最终一致的选择
• 一致性校验与延迟的权衡

在线特征存储的更新延迟目标通常取决于业务场景：策略评估/推荐类通常要求秒级到分钟级更新（如 1~5 分钟），交易风控类可能要求毫秒~秒级，而离线特征补数可容忍更长。延迟目标要与计算成本、存储成本、一致性要求三方权衡。在线特征存储一般采用"最终一致性"：批/流计算产出后异步写入在线存储（如 Redis），允许短暂的不一致窗口，通过"以实体维度刷新"与"单调时间戳"避免读到过期数据造成逻辑错乱。一致性校验上，可定期抽样比对在线存储中的值与离线基准，校验更新是否及时、是否丢失、是否错序；当延迟与一致性冲突时，优先保证"不读错"（如带版本号/时间戳，旧值不覆盖新值），再追求"尽快更新"。对强一致要求极高的场景（如金融风控）才考虑同步更新与互斥，但会显著增加延迟与成本。

权衡题回答要体现"最终一致性 + 单调写入 + 抽样校验"的务实方案，并区分不同业务对延迟的容忍度。

• 存储选型（性能、功能、生态、运维成本）
• 开源 vs 自研的取舍
• 上线审批流程（定义→评审→灰度→发布）

存储选型上：Redis 是高性能键值在线存储，适合做特征在线读取层，但缺少特征定义、血缘、一致性等平台能力，需配合特征注册表使用；Feast（以及 Tecton）是开源特征平台，自带 feature registry、在线/离线存储抽象、批/流计算与读取 API，适合中大规模团队快速落地，但功能深度、性能与自研灵活性有上限；自研特征平台适合超大规模、强定制、性能/合规要求极高的场景，可深度控制一致性、存储与监控，但研发与运维成本高。常见做法是"Feast/自研做管理层 + Redis 做在线存储层"。上线审批流程一般设计为：特征定义 & 代码评审 → 离线/在线一致性校验与数据质量检查 → 灰度上线（小流量、单特征或部分实体）→ 监控观察（延迟、覆盖率、正确性）→ 全量发布，并在每个阶段设置明确的门禁与回滚条件；涉及敏感数据或高影响特征还需合规/业务审批。

选型题要给出"场景→方案"的取舍逻辑，审批流程要体现"评审→验证→灰度→发布→回滚"的完整闭环。

• 缺失值处理策略（填充、删除、标记）
• 标准化与归一化的适用场景
• 类别编码（one-hot、label、target、embedding）

缺失值处理上，应先分析缺失率与缺失机制（随机缺失/非随机缺失），缺失率过高的特征可删除或单独标记"缺失"维度，缺失率低的可用均值/中位数/众数填充、或根据业务用前向/后向填充、模型预测填充，并保留缺失指示特征。标准化上，对线性模型、距离类算法（KNN、SVM）一般用 Z-score 标准化或 Min-Max 归一化，树模型对尺度不敏感；注意标准化的均值/方差需在训练集上统计并固化，避免泄漏到验证/测试集。类别编码上，低基数类别用 one-hot/label、高基数类别可用 target encoding（需防泄漏）、frequency encoding 或 embedding 化。特征筛选上，常用方差阈值（低方差特征意义小）、相关性分析（剔除高相关冗余特征）、单变量检验（卡方、互信息）、以及基于模型的特征重要性（树模型 feature importance、SHAP）与 L1 正则化实现稀疏选择。工程上所有变换都应通过 pipeline 固化到训练/推理两侧，保证一致性。

这是特征工程基础题，全面覆盖四类操作即可。要强调"在训练集上拟合、防数据泄漏、固化到 pipeline"这几个工程要点。

• 在线/离线一致性治理
• 特征复用与跨团队共享
• 模型开发与上线加速

特征平台的核心价值在于：一是解决在线/离线一致性，通过"一份定义 + 批/流同源计算 + 在线/离线双存储"从根上降低 training-serving skew；二是特征复用与共享，特征注册表让同一特征可被多个团队/模型复用，避免重复建设和口径不一致，提升一致性并降低重复开发成本；三是加速模型开发，数据科学家通过统一 API 直接取特征，无需每次重写数据管道，训练时可直接批量读离线特征、上线时自动接入在线特征，配合特征血缘与版本管理、对账与监控，显著缩短从特征定义到模型上线的周期；四是提供治理能力（血缘、版本、监控、权限），使特征工程规范可控。Tecton 在 Feast 基础上强化了实时特征、自动化部署与托管能力。整体上特征平台把"数据工程能力"抽象为"可复用的平台能力"，让算法团队聚焦建模本身。

价值题要点是"一致性、复用、加速、治理"四个维度，并落到"减少重复建设、缩短迭代周期"的业务收益。

• 特征监控维度（分布、缺失率、取值域、新鲜度）
• 漂移检测方法（PSI/KS、统计检验）
• 告警阈值与分级

特征监控的核心维度包括：分布漂移（特征当前分布 vs 训练/基线分布）、缺失率（缺失/NaN 比例是否突变）、取值异常（超出值域、非法取值、异常极值、常量值）、新鲜度（特征是否按时更新，上游数据是否滞后）。检测方法上，分布漂移用 PSI/KS、Kullback-Leibler 散度或 AD 检验等对比最近窗口与基线分布；缺失率用滑动窗口统计与阈值突变检测；取值异常用值域校验、枚举校验、z-score 异常值检测；新鲜度用最近更新时间戳与延迟监控。告警上要设置多级阈值（warning/error）与滑动窗口（如连续 3 个窗口超阈值才告警，减少抖动误报），并关联"影响哪些模型/特征"的血缘信息，形成可定位的告警工单。告警后进入"确认→定位→处置"流程，必要时回滚特征或触发重训。

回答要覆盖"监控什么 + 怎么检测 + 怎么告警"三个层面，突出"多维度 + 分级告警 + 血缘关联"。

• 数据版本管理（DVC/git 化数据、快照）
• 数据血缘追踪
• 数据质量监控（完整性、一致性、有效性）

训练数据治理的目标是让数据"可复现、可追溯、可信赖"。数据版本管理上，DVC 等工具把数据版本与代码版本关联，通过 git 记录数据的元数据与哈希，数据本体存对象存储/大文件存储，训练时按固定数据哈希取数，保证"同一 commit 对应同一份数据"，实现可复现训练与回滚。数据血缘上，追踪数据从原始源表 → 转换/清洗 → 训练集 → 模型的完整链路，当上游数据变更时能自动评估对哪些训练集与模型的影响，并支持数据问题溯源。数据质量监控上，围绕完整性（缺失率、覆盖率）、一致性（字段口径、跨表一致性）、有效性（取值域、类型、脏数据比例）、时效性（新数据占比、新鲜度）建立监控指标，训练前做质量门禁（quality gate），不达标则阻断训练或告警。三者结合形成"数据版本 + 血缘 + 质量"的训练数据治理闭环。

治理题按"版本、血缘、质量"三块展开，突出"可复现、可追溯、可信赖"的目标与训练前质量门禁。

• 非结构化数据 → embedding 的离线/在线链路
• embedding 服务化（批处理/在线推理、模型版本）
• 特征缓存与相似检索

非结构化数据特征化链路一般分"离线批处理"与"在线实时"两条：离线时用 embedding 模型（如 BERT、CLIP、多模态模型）对文本/图像批量生成向量并写入向量存储/特征存储；在线时通过 embedding 服务（GPU 推理服务）对请求内容实时向量化，或对高频/静态内容做缓存复用。工程要点：一是 embedding 服务化，把 embedding 模型封装为独立推理服务，支持批量张量、缓存与版本管理，并保证离线与在线使用同一版本模型与预处理（避免 embedding 不一致）；二是特征缓存，对相同的文本/图像内容（如热门商品、常见 query）用内容哈希做缓存，命中直接返回向量，显著降低重复计算与 GPU 成本；三是向量存储，用 FAISS/Milvus/向量数据库存储与检索，支持相似度检索与 ANN 近邻；四是监控 embedding 质量（如分布漂移、距离分布）与延迟。落地时把 embedding 作为"高阶特征"接入特征平台，与结构化特征统一管理。

本题考察链路设计能力，回答应覆盖"离线/在线两条链路 + 服务化 + 缓存 + 向量存储 + 一致性"，并强调 embedding 与结构化特征统一进特征平台。