引言:为什么多数企业 AI PoC 走不到生产
近年来中国关键行业 (金融、央企、能源、政务) 启动的"企业 AI 落地"项目数量, 远多于实际走到生产上线的产品数量。多数 PoC 在 18 个月内卡住或被搁置, 失败原因并不收敛于"模型选错"或"供应商选错", 而是架构与流程的早期边界画错。
本白皮书把 6 个最常见的工程决策错位摊开, 给正在评估企业 AI 部署的 CTO/CIO 一份"避坑路线图"。
本白皮书不推销 LYG.AI 任何具体产品。这些经验来自公开案例 + 工程通识 + 母公司在金融资管业务中的内部实践沉淀, 我们认为值得提前公开, 让中国关键行业少走弯路。
决策 1:部署边界 — On-Premises / 私有云 / 混合
这是第一个必须先答清楚, 也是最容易被销售牵着鼻子答错的问题。
三种边界的真实差异
怎么选?三个判断维度
数据是否构成业务核心资产 — 银行交易簿、央企能源调度、政府敏感数据, 三类必须 on-prem。问自己:"如果数据被推断 (inference) 在外部系统上, 我能不能向监管 / 董事会 / 客户解释清楚?"如果答案需要超过 1 页 A4, 那就是不能。
推理 QPS × 上下文长度 × 模型尺寸 之乘积 — 这个量决定了边际成本曲线。当乘积超过某个阈值 (金融场景的典型拐点参考: 单一业务线 > 50 QPS, 平均上下文 > 8K, 模型 > 30B), on-prem 的 3 年总成本会反超公有云。
模型更新频率 vs 业务流程更新频率 — 如果模型每两周一更但业务流程半年一改, 公有云模型即服务划算; 反之 on-prem 划算。这是被绝大多数采购流程忽略的维度。
LYG.AI 在这一点上的工程默认
LYG Ark 一体机的默认形态就是 on-prem 物理隔离 (2U / 4U Rack), 但 LYG Foundry 同时支持私有云 / 混合架构。我们的工程偏好: 能 on-prem 就 on-prem, 但不替客户做意识形态判断。
决策 2:模型选型 — 基础模型 vs 垂直模型 vs 自研
一个反直觉的事实
在金融场景的工程实践中, "用最大基础模型 + 强提示词工程"的总成本与可解释性, 通常劣于"中等基础模型 + 行业微调"。原因不复杂:
- 大模型每次推理成本高, 高 QPS 下 OPEX 爆炸
- 大模型的"全能"特性在垂直场景反而引入不必要的不确定性 (例如金融数值精度漂移)
- 大模型的可解释性更差, 合规答辩成本高
但"中等模型 + 微调"也不是免费午餐, 它需要:
- 一套高质量的领域数据 pipeline (这通常是 60% 的工作量)
- 一支能调微调超参 + 评估 hallucination 的研发团队
- 一套版本管理与回滚机制 (微调模型也会"漂移")
三种路径的决策矩阵
| 场景特征 | 推荐路径 |
|---|---|
| 业务流程标准化高, 数据丰富, QPS 高 | 中等模型 + 行业微调 |
| 业务高度多样化, 数据稀疏, QPS 低 | 大基础模型 + 提示工程 |
| 涉及核心商业机密 / 独家算法 / 高频低延迟 | 完全自研 (从预训练开始) |
| 监管要求"算法可备案" | 中等开源模型 + 微调 + 完整文档 |
LYG.AI 在这一点上的默认
LYG Lumen Agent 默认走中等开源基础模型 (7B-70B) + 行业微调路线。Foundry 平台支持客户自带模型 (BYO Model)。我们不强行绑定特定基础模型供应商, 这是与多数"全栈封闭"方案商的核心区别。
决策 3:数据流架构 — RAG vs 微调 vs 长上下文
这是企业 AI 最常被滥用的概念三件套。多数 PoC 失败在混用这三者却不画清边界。
三者的工程本质
- RAG (检索增强): 模型本体不变, 在推理时外挂检索; 数据更新只需更新向量库; 适合高频更新的事实性内容
- 微调 (Fine-tune): 模型权重被改变; 知识"硬刻"入模型; 适合行业表达风格、稳定格式约束、领域行话
- 长上下文 (Long Context): 把全部内容塞进单次 prompt; 适合一次性任务 + 内容可被压缩进上下文窗口
决策树 (工程实践常用的判断顺序)
你的内容 ── 经常变 (周/月) ──→ RAG
── 几乎不变 + 量大 ── 加微调
── 一次性 / 量小 ── 长上下文
真实陷阱
- 陷阱 1: 用 RAG 处理"格式约束"任务 — RAG 给你事实, 但模型仍按基础模型的风格输出, 风格依然漂移
- 陷阱 2: 用微调处理"事实更新"任务 — 微调一次性能解决, 但下次客户数据更新你还得再微调一次, 成本失控
- 陷阱 3: 用长上下文做需要反复推理的任务 — 长上下文模型在 100K+ 上下文上的实际可用注意力急速衰减, 关键证据在中间会被"遗忘"
LYG.AI 在这一点上的默认
LYG Foundry 把这三者做成可组合的原语 (RAG 索引服务 + 微调任务编排 + 长上下文 router), 让客户的工程团队按场景自由组合, 而不是强行推一套"AI 中台"概念。
决策 4:可解释性与审计 — 不能演示给监管看, 就不能上生产
金融机构的硬约束
金融监管 (银保监会、证监会、央行) 对算法决策的事后可审计性有明确要求。央企/政府监管虽不如金融严, 但事故复盘时同样需要"为什么模型这样决定"。
不能审计的 AI = 业务上的未爆炸弹。
三个层次的可解释性
| 层次 | 含义 | 工程实现 |
|---|---|---|
| L1 输入可追溯 | 每个 inference 的输入数据可回放 | 全链路日志 + 版本快照 |
| L2 决策可解释 | 输出 = f(输入, 模型版本) 可重建 | 模型版本固化 + 推理路径记录 |
| L3 因子可归因 | 输出受哪些输入因子最影响, 量化展示 | SHAP / Integrated Gradients / Attention Map |
容易被忽视的事实
- L1 是基础设施层问题, 不是 AI 问题; 但在企业里常常被 AI 团队接锅
- L2 需要每次模型部署都打 immutable 标签, 这意味着不能用 "auto-deploy from main" 的开发文化
- L3 是研究问题, 现有工具只能给"局部解释"; 整体可解释性仍是开放课题
LYG.AI 在这一点上的默认
LYG Ark 一体机内置不可关闭的全链路审计 (L1) + 模型版本固化 (L2) + 主流可解释性工具集 (L3 部分场景)。我们认为这不是"加分项", 是"金融级 AI"的入场券。
决策 5:运维与生命周期 — Day 2 才是噩梦的起点
PoC 往往在 Day 1 看起来很美。但企业 AI 系统的真实工程考验在Day 2 之后: 模型漂移 / 推理延迟尖刺 / GPU 故障 / 数据 schema 变更 / 版本兼容性 / 安全补丁。
Day-2 检查清单
我们建议客户在 PoC 阶段就预演 Day-2 场景:
- 模型 v1 → v2 灰度发布机制是否就绪?能否快速回滚?
- 单 GPU 节点故障, 业务是否能在 < 60s 内自动迁移?
- 推理延迟突增, 监控告警是否能在 5 分钟内通知到值班工程师?
- 数据源 schema 变更, 推理是否会静默失败 (silently fail)?是否有契约检查?
- 操作系统 / CUDA / driver 安全补丁, 升级会不会破坏模型推理一致性?
- 三个月内, 是否做过一次"红蓝演练": 主动注入故障验证恢复
- 一年内, 是否做过完整 DR (异地灾备) 切换演练?
- 模型供应商若停止维护, 切换到替代模型的代价是?
反模式
- ❌ "PoC 跑通了就让运维接手" — 运维团队没参与设计, Day 2 会爆炸
- ❌ "等出问题再加监控" — Day-0 就要有 SLI/SLO + 错误预算
- ❌ "GPU 就是另一种 CPU" — GPU 故障模式 / 显存碎片 / 驱动兼容性是另一个工程域
LYG.AI 在这一点上的默认
LYG Ark 一体机出厂自带预集成的可观测性栈 (Prometheus + Grafana + 自研推理监控 exporter), Foundry 平台默认按 GitOps 模式做模型生命周期管理。我们不让客户自己拼装 Day-2 工具链。
决策 6:组织与治理 — 谁拥有 AI, 决定它能跑多久
最后一个决策点不在技术层, 但决定其他 5 个技术决策能否被坚持执行。
三种企业 AI 治理模式
| 模式 | 描述 | 适用 | 典型问题 |
|---|---|---|---|
| 中央 AI 团队 | 一个独立 AI 部门服务全公司 | 数字化早期, 业务部门 AI 能力弱 | 容易脱离业务, 变成"内部研究院" |
| 业务嵌入 AI | 各业务部门各自有 AI 工程师 | 业务多样化, AI 能力中等 | 重复造轮子, 标准不一 |
| 平台 + 嵌入混合 | 中央团队负责 AI 平台 + 工程标准, 业务团队负责场景实现 | 数字化成熟期 | 平台与业务边界要持续校准 |
三个治理硬问题
- AI 系统的"事故责任人"是谁? — 模型团队?平台团队?业务团队?预先定义, 否则事故后会变成多团队互相甩锅。
- AI 系统的预算与 OPEX 谁出? — 业务部门拍脑袋说"我们要 AI", 但 GPU 与人力成本谁分摊?
- AI 系统的退出机制? — 哪一刻你判断一个 AI 业务应该下线?以什么 KPI 触发?
LYG.AI 在这一点上的默认
LYG.AI 的产品 (Ark / Lumen / Foundry) 在工程层支持租户隔离 + 多团队权限边界, 但治理决策必须由客户自己做。我们提供一份《企业 AI 治理参考手册》作为咨询资料 — 在 Demo 环节, 销售工程师会与你的 CTO / CDO 讨论你的组织模式适配。
收尾:从"做 PoC"到"建 AI 资产"
如果用一句话概括这 6 个决策点的共同主线:
企业 AI 落地的真正瓶颈, 不是模型选哪个, 而是把 AI 当作长期资产去工程化经营。
这与 LYG.AI 母公司 (一家用 AI 管理真实资金的量化机构) 长期实践得到的核心结论一致: AI 跑在自己的钱上, 才有资格卖给客户。
我们把这一套"投资级严谨"的工程实践打包给中国关键行业的客户, 不是因为"AI 是热点", 而是因为我们相信: 中国未来 10 年最稀缺的 AI 工程能力, 不是会写 prompt 的人, 而是知道如何把 AI 系统经营成业务资产的工程团队。
附录 A:决策点 vs LYG.AI 产品的对照速查
| 决策点 | LYG.AI 产品默认 | 替代选项 |
|---|---|---|
| 部署边界 | LYG Ark on-prem | LYG Foundry on VPC / Hybrid |
| 模型选型 | 中等开源 + 微调 | BYO Model (任意基础模型) |
| 数据流架构 | RAG + 微调 + 长上下文可组合 | 客户自定义编排 |
| 可解释性 | 全链路审计强制开启 | 客户自定义保留期 |
| 运维生命周期 | 预集成可观测性栈 + GitOps | 客户对接已有运维平台 |
| 组织治理 | 多租户权限边界 | 提供咨询资料, 不做组织诊断 |
附录 B:延伸阅读
- LYG Ark 部署文档 (
/resources/docs-ark-deployment/) - LYG Ark 架构白皮书 (
/resources/whitepaper-ark-architecture/) - LYG.AI Trust Center (
/trust/) — 数据主权 / 合规承诺 - LYG.AI Security Policy (
/security/) — 漏洞披露 / vendor review
联系
希望与 LYG.AI 工程团队深入讨论你的企业 AI 部署路线?
- 销售对接:sales@lyg.ai
- 安全与合规问询:security@lyg.ai
- 预约现场 Demo:填写表单, 我们 24 小时内首次响应