企业官网建设流程全解析

1. 从零开始构建AI工程体系：这不是搭积木，是重建地基

“AI Engineering from Scratch”这个标题乍看像一句技术口号，实则藏着一整套被多数人忽略的底层逻辑——它不是教你怎么调用一个现成的大模型API，也不是手把手带你跑通一个Hugging Face示例，而是回到最原始的起点：当你面前只有一台裸机、一个终端、一份空白文档，你如何在没有预装框架、没有现成pipeline、没有团队支持的前提下，把“人工智能”这四个字，真正变成可部署、可监控、可迭代、可追责的一整套工程化产出？我过去三年带过17个从零启动的AI产品项目，其中12个失败在“能跑通demo却无法上线”，5个卡死在“模型准确率98%但延迟4.2秒、内存暴涨3倍、日志全空、故障无法定位”。这些坑，全是因为我们误把“AI实验”当成了“AI工程”。真正的AI工程，从第一行代码开始就必须考虑可观测性、资源边界、版本契约、数据漂移响应机制和灰度发布路径。它不依赖某个明星框架，而依赖一套可验证、可拆解、可替换的模块化设计哲学。本文面向三类人：刚转行想搞懂AI落地本质的工程师、正在被“模型上线即崩”折磨的算法负责人、以及准备自建AI基础设施的技术决策者。你会看到的不是概念罗列，而是我在生产环境里亲手焊过的每一根管线、踩过的每一个内存泄漏点、重写过七遍的调度器逻辑，以及为什么“从零开始”恰恰是最高效的选择——因为只有亲手拧紧每一颗螺丝，你才真正拥有对系统行为的确定性。

2. 为什么必须“从零开始”：破除三大幻觉，直面AI工程的真实成本

2.1 幻觉一：“框架即工程”——PyTorch/TensorFlow只是计算引擎，不是工程底座

很多人以为装上PyTorch就等于拥有了AI工程能力，这是最危险的认知偏差。PyTorch是一个极其优秀的数值计算图编译器，它的核心使命是把y = f(x)高效地映射到GPU上执行。但它完全不关心：

• 当x来自Kafka Topic时，如何保证消息顺序与batch对齐？
• 当f()在推理时触发OOM，是该杀进程、降batch、还是切回CPU fallback？
• 当y需要写入MySQL+ES+Redis三份存储，哪一份写失败了要触发补偿事务？
• 当模型版本从v1.2.3升级到v1.2.4，如何确保下游所有调用方自动感知并完成灰度切换？

我去年接手一个推荐系统重构项目，原团队用TensorFlow Serving部署了8个模型，表面看QPS稳定在1200，但运维日志显示每天凌晨3:17准时出现17秒服务不可用——查了两周才发现是TF Serving的模型热加载机制在加载新权重时会短暂阻塞整个gRPC线程池，而他们的定时任务恰好卡在这个窗口。解决方案不是换框架，而是在TF Serving外层加一层轻量级代理：用Go写一个仅230行的调度器，接管所有模型加载请求，实现原子化切换+健康检查+失败回滚。这个代理不依赖任何AI框架，只依赖标准HTTP和文件系统。它之所以有效，正是因为剥离了“计算”与“调度”的职责边界。从零开始，首先就要划清这条线：框架负责算得快，工程负责算得稳、算得准、算得可追溯。

2.2 幻觉二：“MLOps平台=自动化”——自动化是结果，不是起点

市面上所有MLOps平台（如MLflow、Kubeflow）都宣称“一键训练、自动部署、全链路追踪”，但真实场景中，它们90%的配置项在第一天就被手动覆盖。为什么？因为自动化必须基于可穷举、可验证、可逆向的流程定义。而AI研发流程天然充满不确定性：

• 数据清洗脚本可能因上游字段变更突然报错，错误类型无法提前注册；
• 超参搜索结果可能因随机种子不同产生3%的指标波动，是否接受需人工判断；
• 模型在A/B测试中表现优于baseline，但业务方发现新策略导致用户停留时长下降——这属于跨域指标冲突，无法被任何平台自动识别。

我在为一家银行构建反欺诈模型时，曾尝试直接接入MLflow。结果发现：他们的特征工程依赖Oracle数据库的特定函数（如REGEXP_SUBSTR），而MLflow的Docker镜像默认不包含Oracle客户端驱动；模型评估脚本调用内部风控规则引擎API，该API要求双向证书认证，但MLflow的secret管理只支持key-value，不支持证书链挂载。最后我们放弃平台，用Python+Airflow+自研的FeatureRegistry类库重写了整套流程。关键不是不用工具，而是先定义清楚每个环节的输入契约、输出契约、失败契约。比如特征生成环节的契约是：“输入为parquet格式的raw_event表，输出为feast FeatureView定义的schema，若任意字段缺失则抛出FeatureSchemaMismatchError异常并附带缺失字段清单”。有了契约，后续才能谈自动化。从零开始，就是从写第一份契约文档开始。

2.3 幻觉三：“模型即产品”——产品交付的是服务契约，不是pkl文件

一个常见误区是把.pt或.onnx文件当作交付物。实际上，客户购买的从来不是“模型权重”，而是“在指定SLA下持续提供预测服务的能力”。这意味着：

• 输入侧：必须定义明确的数据schema（如user_id: string, item_ids: list[int], timestamp: int64），并内置校验逻辑（如item_ids长度不能超过50，否则返回400 Bad Request并记录告警）；
• 输出侧：必须承诺响应格式（JSON Schema）、延迟P99（≤200ms）、错误率（≤0.1%），且这些指标需实时上报至Prometheus；
• 运维侧：必须提供模型版本、特征版本、代码提交哈希的三元组trace ID，当线上指标异常时，能10秒内定位到具体变更点。

我们曾为某电商客户部署一个商品相似度模型，初期交付了一个Flask API。上线三天后，他们反馈“接口偶尔超时”。排查发现：当用户上传的图片尺寸超过2000×2000像素时，预处理阶段的PIL.resize()会占用大量CPU，导致线程阻塞。解决方案不是优化resize算法，而是在API入口强制添加尺寸校验中间件：

def validate_image_size(request): if 'image' not in request.files: raise ValidationError("missing image field") img = Image.open(request.files['image']) if max(img.size) > 1920: # 强制缩放阈值 img = img.resize((1920, int(1920 * img.height / img.width)), Image.BILINEAR) # 重新编码为bytes并替换request.files return img

这个中间件与模型完全解耦，即使更换模型架构也无需修改。它体现的是一种工程思维：把非功能性需求（性能、可靠性、可观测性）作为独立模块前置注入，而非事后补救。从零开始，就是从设计第一个中间件开始。

3. 核心模块拆解：六个不可妥协的基石组件

3.1 数据契约中心（Data Contract Hub）

这是整个AI工程的地基。它不是数据库，而是一套强制执行的schema定义与验证协议。我们采用YAML+JSON Schema组合方案，每个数据集对应一个contract.yaml：

# contracts/user_behavior_v2.yaml name: user_behavior_v2 version: 1.3.0 description: "用户行为埋点数据，用于CTR预估" schema: type: object properties: event_id: type: string pattern: "^[a-f0-9]{32}$" # 强制UUID格式 user_id: type: string minLength: 12 maxLength: 32 item_id: type: integer minimum: 1 maximum: 2147483647 timestamp: type: integer minimum: 1609459200 # 2021-01-01 00:00:00 UTC required: [event_id, user_id, item_id, timestamp] additionalProperties: false validation_rules: - name: "no_duplicate_events" sql: | SELECT COUNT(*) FROM (SELECT event_id FROM {{table}} GROUP BY event_id HAVING COUNT(*) > 1) threshold: 0 - name: "freshness_check" sql: | SELECT MAX(timestamp) FROM {{table}} max_age_seconds: 300 # 数据延迟不能超5分钟

关键设计点：

• 版本锁定：每次数据写入前，必须通过contract_version字段声明所遵循的契约版本，写入服务会校验该版本是否存在且未废弃；
• 双模验证：结构校验（JSON Schema）在应用层做，业务规则校验（SQL）在数据湖层做，避免应用层过度负担；
• 自动归档：当新版本发布时，旧版本契约自动进入archived/目录，但历史数据仍按原契约解析，保证向后兼容。

实操心得：我们曾因未启用additionalProperties: false，导致上游多传了一个debug_info字段，模型训练时意外将其纳入特征，造成线上效果波动。从此所有契约强制开启此选项。另外，validation_rules中的SQL必须能在Trino/Presto上直接执行，避免引入额外计算引擎。

3.2 特征工厂（Feature Factory）

区别于传统特征平台，我们的特征工厂核心是可组合、可回溯、可复用的特征单元（Feature Unit）。每个单元是一个独立Python模块，例如：

# features/item_price_trend.py from feature_factory import FeatureUnit, register_feature @register_feature( name="item_price_trend_7d", inputs=["item_id", "timestamp"], outputs=["price_trend_slope", "price_trend_r2"], dependencies=["item_price_history_v1"] ) class ItemPriceTrend7D(FeatureUnit): def compute(self, df: pd.DataFrame) -> pd.DataFrame: # 使用statsmodels进行线性拟合，返回斜率与R² # 注意：此处不访问数据库，只处理已加载的df pass # features/__init__.py 中统一注册 from .item_price_trend import ItemPriceTrend7D from .user_click_entropy import UserClickEntropy # ... 其他单元

关键机制：

• 依赖声明：dependencies字段明确列出所需的基础特征表，特征工厂在调度时自动构建DAG；
• 版本隔离：每个FeatureUnit可声明min_version和max_version，避免因基础表升级导致衍生特征失效；
• 离线/在线一致性：所有计算逻辑封装在compute()中，离线批量计算与在线实时计算共享同一份代码，仅输入数据源不同（Parquet vs Redis Stream）。

避坑经验：早期我们允许FeatureUnit直接调用数据库，结果导致线上服务因DB连接池耗尽而雪崩。后来强制规定：所有外部依赖必须通过FeatureFactoryContext注入，且上下文对象在初始化时已预加载好所需数据快照。这样既保证了逻辑纯净，又规避了运行时IO风险。

3.3 模型生命周期管理器（Model Lifecycle Manager）

我们摒弃了“训练-评估-部署”线性流程，采用状态机驱动的模型管理。每个模型实例有且仅有以下状态：

关键设计：

• 状态转换强校验：例如从staging到production，必须满足：A/B测试样本量≥10万、胜率≥95%、P99延迟≤150ms、无critical级别告警；
• 不可变性保障：一旦进入production，模型权重、特征版本、代码哈希全部冻结，任何修改必须新建模型实例；
• 自动归档：deprecated状态满30天后自动转入archived，释放存储空间但保留元数据。

实操教训：某次紧急修复bug，开发人员直接修改了production模型的预处理代码，导致线上特征计算错误。此后我们增加硬性约束：所有production状态的模型，其代码仓库分支被设为protected，合并PR必须经过CI/CD流水线+三人审批。

3.4 推理服务网格（Inference Service Mesh）

我们不使用单一推理服务器（如Triton），而是构建一个轻量级服务网格，由三个核心组件构成：

1. Router（路由层）：基于Envoy定制，负责TLS终止、JWT鉴权、流量染色（根据header中的x-model-version路由）；
2. Worker（工作层）：每个Worker是一个独立进程，加载指定模型版本，暴露gRPC接口；
3. Orchestrator（编排层）：用Python编写，监听Kubernetes事件，动态更新Router配置并启停Worker。

典型部署拓扑：

Client → Router (Envoy) → [Worker-v1.2.3] → [Worker-v1.2.4] → [Worker-fallback-cpu]

关键能力：

• 灰度发布：通过Router的weighted cluster功能，将5%流量导向v1.2.4，同时采集其延迟、错误率、特征分布偏移（KS检验）；
• 熔断降级：当Worker错误率连续3分钟>5%，Orchestrator自动将其从Router配置中移除，并激活fallback-cpu Worker；
• 冷热分离：高频模型常驻内存，低频模型按需加载（启动时从S3下载权重，<3秒完成）。

性能实测：在AWS c5.4xlarge机器上，单个Worker处理ResNet50推理，P99延迟从Triton的187ms降至142ms，原因在于去除了Triton的通用序列化开销，直接使用PyTorch的torch.jit.script编译模型。

3.5 可观测性中枢（Observability Hub）

AI系统的可观测性不能只看CPU/Memory，必须覆盖数据层、特征层、模型层、业务层四维指标：

所有指标统一上报至Prometheus，通过Grafana构建四层下钻看板。特别设计：

• 自动根因分析：当业务指标异常时，系统自动关联查询特征层指标，若发现某特征KL散度突增，则标记该特征为可疑源；
• 影子模式对比：新模型上线时，同时运行新旧两套推理服务，将相同请求分发给两者，自动计算预测差异率（diff rate），diff rate>15%即触发人工审核。

经验分享：我们曾发现某次模型更新后CTR上升但GMV下降，通过业务层指标下钻，发现新模型过度偏好高单价商品，导致用户加购转化率下降。这问题在模型层指标中完全不可见，凸显多维可观测的必要性。

3.6 实验治理框架（Experiment Governance Framework）

为避免“实验爆炸”，我们实施严格的实验准入制：

• 命名规范：{project}-{domain}-{hypothesis}-{date}，如recsys-item2vec-bias_correction-20240520；
• 资源配额：每个实验默认分配2核CPU/4GB内存，超限需CTO审批；
• 自动清理：实验运行7天后自动归档，30天后彻底删除；
• 结果登记：必须填写experiment_report.md，包含假设、方法、结果、结论、后续动作，否则无法关闭实验。

最关键的是实验影响范围声明：每个实验必须明确标注其影响的下游系统，例如：

## 影响范围 - ✅ 直接影响：推荐列表排序、商品详情页“猜你喜欢”模块 - ⚠️ 间接影响：用户画像更新频率（因新增特征）、广告竞价策略（因CTR预估变化） - ❌ 不影响：支付成功率、客服对话机器人

这迫使实验设计者主动思考系统耦合关系。去年我们因此拦截了3个可能影响支付链路的实验，避免了一次重大事故。

4. 从零搭建实操指南：12小时完成最小可行AI工程栈

4.1 环境初始化：裸机到可部署环境（2小时）

目标：在一台Ubuntu 22.04服务器上，完成基础环境搭建，支持后续所有模块部署。

步骤详解：

1. 系统加固：禁用root登录，创建ai-engineer用户并加入sudo组，配置SSH密钥登录，关闭不必要的端口（仅开放22/80/443/9090）；
2. 容器运行时：安装containerd而非Docker，因其更轻量且符合Kubernetes标准。关键配置/etc/containerd/config.toml：

   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true # 必须开启，否则cgroup v2下资源限制失效

3. 监控基座：部署Prometheus+Grafana，使用prometheus.yml预置AI工程专用job：

   - job_name: 'ai-engineering' static_configs: - targets: ['localhost:9090', 'localhost:9100', 'localhost:8000'] # 分别对应Prometheus自身、Node Exporter、自研服务 metrics_path: '/metrics'

   此处8000端口预留给我们后续的Feature Factory服务。

避坑提示：Ubuntu 22.04默认启用cgroup v2，而旧版Docker不兼容。我们选择containerd正是为规避此问题。另外，SystemdCgroup = true是硬性要求，否则容器内存限制会失效——我们曾因此让一个训练任务吃光服务器内存。

4.2 数据契约中心部署（1.5小时）

目标：启动一个HTTP服务，支持契约注册、验证、版本查询。

技术选型：FastAPI + SQLite（轻量级，单机足够）+ Pydantic V2。

核心代码（data_contract_api/main.py）：

from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel, Field from typing import List, Optional import sqlite3 import json app = FastAPI() class Contract(BaseModel): name: str = Field(..., example="user_behavior_v2") version: str = Field(..., example="1.3.0") schema: dict = Field(..., example={"type": "object", "properties": {...}}) validation_rules: List[dict] = [] @app.post("/contracts") def register_contract(contract: Contract): conn = sqlite3.connect("contracts.db") cursor = conn.cursor() try: cursor.execute(""" INSERT INTO contracts (name, version, schema, validation_rules, created_at) VALUES (?, ?, ?, ?, datetime('now')) """, (contract.name, contract.version, json.dumps(contract.schema), json.dumps(contract.validation_rules))) conn.commit() except sqlite3.IntegrityError: raise HTTPException(status_code=409, detail="Contract already exists") finally: conn.close() return {"status": "ok"} @app.get("/contracts/{name}/latest") def get_latest_contract(name: str): conn = sqlite3.connect("contracts.db") cursor = conn.cursor() cursor.execute("SELECT * FROM contracts WHERE name = ? ORDER BY version DESC LIMIT 1", (name,)) row = cursor.fetchone() if not row: raise HTTPException(status_code=404, detail="Contract not found") return { "name": row[0], "version": row[1], "schema": json.loads(row[2]), "validation_rules": json.loads(row[3]) }

部署命令：

# 初始化数据库 sqlite3 contracts.db "CREATE TABLE contracts (name TEXT, version TEXT, schema TEXT, validation_rules TEXT, created_at TEXT, PRIMARY KEY(name, version));" # 启动服务 uvicorn data_contract_api.main:app --host 0.0.0.0 --port 8000 --reload

验证方式：

curl -X POST http://localhost:8000/contracts \ -H "Content-Type: application/json" \ -d '{"name":"test_contract","version":"0.1.0","schema":{"type":"object","properties":{"id":{"type":"string"}}},"validation_rules":[]}' curl http://localhost:8000/contracts/test_contract/latest

实操心得：SQLite在单机场景下性能足够，且无需额外运维。但要注意PRIMARY KEY(name, version)的设计，避免重复注册。我们曾因忘记加UNIQUE约束，导致同一契约多个版本混乱。

4.3 特征工厂原型（3小时）

目标：实现一个可运行的特征计算服务，支持离线批量与在线实时两种模式。

架构设计：

• 离线模式：读取Parquet文件 → 应用FeatureUnit → 输出Parquet；
• 在线模式：接收HTTP POST请求 → 解析JSON → 应用FeatureUnit → 返回JSON。

核心抽象（feature_factory/core.py）：

class FeatureUnit(ABC): @abstractmethod def compute(self, df: pd.DataFrame) -> pd.DataFrame: pass class FeatureFactory: def __init__(self, units: List[Type[FeatureUnit]]): self.units = {unit.__name__: unit() for unit in units} def batch_compute(self, input_path: str, output_path: str, unit_name: str): df = pd.read_parquet(input_path) result = self.units[unit_name].compute(df) result.to_parquet(output_path) def online_compute(self, unit_name: str, payload: dict) -> dict: # 将payload转为DataFrame（单行） df = pd.DataFrame([payload]) result = self.units[unit_name].compute(df) return result.iloc[0].to_dict()

示例FeatureUnit（features/user_age_group.py）：

from feature_factory.core import FeatureUnit class UserAgeGroup(FeatureUnit): def compute(self, df: pd.DataFrame) -> pd.DataFrame: df["age_group"] = pd.cut( df["age"], bins=[0, 18, 35, 50, 100], labels=["teen", "young_adult", "middle_aged", "senior"] ) return df[["user_id", "age_group"]]

启动服务（features/api.py）：

from fastapi import FastAPI from feature_factory.core import FeatureFactory from features.user_age_group import UserAgeGroup app = FastAPI() factory = FeatureFactory([UserAgeGroup]) @app.post("/features/{unit_name}") def compute_feature(unit_name: str, payload: dict): return factory.online_compute(unit_name, payload)

部署与测试：

# 启动服务 uvicorn features.api:app --host 0.0.0.0 --port 8001 --reload # 测试在线计算 curl -X POST http://localhost:8001/features/UserAgeGroup \ -H "Content-Type: application/json" \ -d '{"user_id":"u123","age":28}' # 返回: {"user_id":"u123","age_group":"young_adult"}

关键细节：pd.cut()的bins必须是严格递增的数值，否则会报错。我们在生产环境中将bins存入数据库，由契约中心管理，确保所有环境一致。

4.4 模型生命周期管理器（2.5小时）

目标：构建一个CLI工具，支持模型状态流转与元数据管理。

技术选型：Typer（现代化CLI框架）+ SQLite。

核心逻辑（model_lifecycle/cli.py）：

import typer from pathlib import Path import sqlite3 import json from datetime import datetime app = typer.Typer() @app.command() def init(): """初始化模型数据库""" conn = sqlite3.connect("models.db") conn.execute(""" CREATE TABLE models ( id TEXT PRIMARY KEY, name TEXT NOT NULL, status TEXT NOT NULL DEFAULT 'draft', config TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) """) conn.commit() typer.echo("Database initialized") @app.command() def train(model_id: str, config_file: Path): """提交训练任务""" with open(config_file) as f: config = json.load(f) conn = sqlite3.connect("models.db") conn.execute(""" INSERT INTO models (id, name, status, config) VALUES (?, ?, 'training', ?) """, (model_id, config["name"], json.dumps(config))) conn.commit() typer.echo(f"Training started for {model_id}") @app.command() def promote(model_id: str, target_status: str): """状态提升""" valid_transitions = { "training": ["evaluating"], "evaluating": ["staging"], "staging": ["production"], "production": ["deprecated"] } conn = sqlite3.connect("models.db") cursor = conn.cursor() cursor.execute("SELECT status FROM models WHERE id = ?", (model_id,)) current_status = cursor.fetchone()[0] if target_status not in valid_transitions.get(current_status, []): raise typer.BadParameter(f"Invalid transition: {current_status} → {target_status}") conn.execute(""" UPDATE models SET status = ?, updated_at = CURRENT_TIMESTAMP WHERE id = ? """, (target_status, model_id)) conn.commit() typer.echo(f"Model {model_id} promoted to {target_status}")

使用流程：

# 初始化 python -m model_lifecycle.cli init # 创建模型配置 cat > config.json <<EOF {"name": "ctr_model_v1", "framework": "pytorch", "version": "1.0.0"} EOF # 提交训练 python -m model_lifecycle.cli train "ctr-20240520-001" config.json # 训练完成后，进入评估 python -m model_lifecycle.cli promote "ctr-20240520-001" evaluating

安全设计：所有状态变更都记录updated_at，且promote命令强制校验状态转移合法性，杜绝非法跳转。我们曾因允许draft直接到production，导致未测试模型上线。

4.5 推理服务网格雏形（3小时）

目标：部署一个可扩展的推理服务，支持多模型共存与灰度路由。

技术栈：Envoy（Proxy）+ Python Flask（Worker）+ Bash（Orchestrator）。

Envoy配置（envoy.yaml）：

static_resources: listeners: - address: socket_address: address: 0.0.0.0 port_value: 8002 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager codec_type: auto stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: local_service domains: ["*"] routes: - match: { prefix: "/" } route: { cluster: "workers" } http_filters: - name: envoy.filters.http.router clusters: - name: workers connect_timeout: 0.25s type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: workers endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 127.0.0.1 port_value: 8003 # Worker v1.0.0 - endpoint: address: socket_address: address: 127.0.0.1 port_value: 8004 # Worker v1.1.0

Worker示例（worker_v1_0_0.py）：

from flask import Flask, request, jsonify import torch import torchvision.models as models app = Flask(__name__) model = models.resnet18(pretrained=True).eval() @app.route("/predict", methods=["POST"]) def predict(): data = request.json # 简化处理：假设输入是base64编码的图片 import base64, io, numpy as np from PIL import Image img_bytes = base64.b64decode(data["image"]) img = Image.open(io.BytesIO(img_bytes)).convert("RGB").resize((224, 224)) tensor = torch.tensor(np.array(img)).permute(2, 0, 1).float() / 255.0 tensor = tensor.unsqueeze(0) with torch.no_grad(): output = model(tensor) return jsonify({"prediction": output.argmax().item()})

启动命令：

# 启动Envoy envoy -c envoy.yaml & # 启动两个Worker python worker_v1_0_0.py --port 8003 & python worker_v1_1_0.py --port 8004 & # 测试路由 curl -X POST http://localhost:8002/predict \ -H "Content-Type: application/json" \ -d '{"image":"base64_encoded_string"}'

关键技巧：Envoy的STRICT_DNS模式要求后端服务必须注册DNS名称，但我们用127.0.0.1简化了本地测试。生产环境会替换为Kubernetes Service DNS。

5. 常见问题与实战排障手册

5.1 数据漂移检测失效：KL散度为何总为0？

现象：在特征层监控中，user_age特征的KL散度连续一周显示为0，但业务方反馈用户年龄结构明显变化（新增大量Z世代用户）。

排查路径：

1. 确认数据源：检查特征计算脚本，发现user_age是从user_profile表中直接取值，而该表每日全量覆盖，未启用CDC（变更数据捕获）；
2. 验证采样逻辑：监控系统默认对特征抽样1%计算KL，但user_age字段存在大量NULL值（占比37%），抽样后NULL比例波动剧烈，导致KL计算不稳定；
3. 检查分布计算：KL散度要求两个分布定义在同一支撑集上，但监控脚本将NULL视为独立类别，而业务逻辑中NULL被过滤，造成分布定义不一致。

解决方案：

• 数据源改造：将user_profile表改为增量更新，每日只同步变更记录；
• NULL统一处理：在特征工厂中强制将NULL替换为中位数，并在契约中声明nullable: false；
• KL计算修正：改用JS散度（Jensen-Shannon Divergence），它对零概率更鲁棒，且始终有定义。

根本原因：KL散度不是万能的，它对零概率敏感，且要求严格匹配支撑集。在实际工程中，应根据数据特性选择合适指标：对于稀疏分类特征用Hellinger距离，对于连续特征用KS检验，对于高维嵌入用MMD（最大均值差异）。

5.2 模型服务OOM：为什么内存占用持续增长？

现象：ResNet50推理服务运行24小时后，RSS内存从1.2GB涨至4.8GB，最终被OOM Killer杀死。

排查过程：

1. 内存分析：使用pympler跟踪Python对象，发现torch.nn.Module实例数量随请求增加而线性增长；
2. 代码审查：发现预处理中使用了transforms.Compose，而每个请求都新建一个Compose实例，其内部缓存未释放；
3. PyTorch机制：torchvision.transforms中的Resize等操作会缓存插值核，频繁创建导致内存泄漏。

修复方案：

• 全局复用Transform：将transforms.Compose定义为模块级变量，而非每次请求创建；
• 显式清理：在推理函数末尾调用torch.cuda.empty_cache()（GPU场景）；
• 内存限制：在Docker