GenAI
生产全指南

Demo 只需要证明"能跑"，生产需要证明"能信"。核心难点：

• 非确定性输出 — 同样的输入可能产生不同的输出，传统软件测试方法失效
• 幻觉问题 — 模型会自信地编造事实，在企业场景中这是不可接受的
• 数据隐私 — 企业数据不能随意发送给第三方 API
• 成本不可控 — Token 计费模式下，一个设计不当的 Prompt 可能烧掉大量预算
• 评估困难 — "好不好"很主观，缺乏标准化的评估方法
• 技术债务 — 快速原型往往绕过了架构设计，导致后期难以扩展

Databricks 的核心主张是：数据平台和 AI 平台不应该分离。

• Lakehouse 架构 — 统一数据湖和数据仓库，结构化和非结构化数据一体化管理
• Unity Catalog — 统一的数据和 AI 资产治理层（模型、特征、向量索引全部纳入管控）
• MLflow — 模型全生命周期管理（实验追踪、注册、部署、监控）
• Mosaic AI — 模型训练、微调、服务的一站式平台

底层逻辑：你的数据已经在 Databricks 里了，AI 也应该在同一个地方构建、训练、部署和监控。

大多数企业卡在 L2 → L3 的跨越上。本指南的核心就是帮你跨过这一步。

分块（Chunking）是 RAG 中最容易被忽视但影响最大的环节。分块太大，噪声多；太小，丢失上下文。

实践建议：从递归分割开始（chunk_size=512, overlap=50），根据评估结果调整。总是加 overlap 防止上下文断裂。

Naive RAG（Demo 级）：

1. 用户 Query → Embedding → 余弦相似度 top-K → 拼入 Prompt → 生成

Production RAG（生产级）需要增加的环节：

• Query 改写/扩展 — 用 LLM 将用户口语化问题改写为多个精确检索 Query
• 混合检索 — BM25（关键词） + Dense Retrieval（语义）双路，加权融合
• 重排序 (Reranking) — 用 Cross-encoder 对 top-N 候选精排，显著提升精度
• 元数据过滤 — 利用时间、来源、权限等元数据预过滤，缩小检索范围
• 答案验证 — 检查生成结果是否有检索证据支撑，标注引用来源

Multi-hop RAG — 多步检索回答复合问题：

1. 将复杂问题分解为子问题
2. 每个子问题独立检索
3. 前一步的答案作为下一步检索的上下文
4. 合并所有中间结果生成最终答案

Graph-based RAG — 利用知识图谱增强检索：

• 构建实体和关系图谱
• 检索时不仅找到直接相关文档，还能沿着关系链找到间接相关信息
• 特别适合需要跨文档推理的场景（如法规关联、产品依赖关系）

Self-RAG — 让模型自己判断是否需要检索、检索结果是否相关、生成的答案是否忠实于证据。通过特殊 token 实现自我反思。

Few-shot 是最被低估的 Prompt 技术。好的示例比长篇说明更有效。

最佳实践：

• 数量 — 3-5 个示例通常足够，超过 8 个收益递减
• 多样性 — 覆盖不同类型的输入和边界情况
• 难度梯度 — 从简单到复杂排列
• 反面示例 — 展示"不该怎么做"有时比正面示例更有效
• 动态选择 — 根据用户输入的类型动态选择最相关的示例

CoT 不只是加一句"Let's think step by step"。在生产系统中，CoT 有更系统的用法：

• Structured CoT — 给模型一个明确的推理框架：分析 → 比较 → 权衡 → 结论
• Self-Consistency — 多次生成推理路径，取多数投票结果
• CoT + Tool Use — 推理过程中决定何时调用工具获取信息
• Hidden CoT — 让模型内部推理但只输出最终结果（减少 Token 消耗）

生产建议：对于关键决策，开启 CoT 并存储推理过程用于审计。对于简单任务，关闭 CoT 节省成本。

生产系统需要可靠的结构化输出。几种方法：

• JSON Mode — 大多数 API 支持强制 JSON 输出模式
• Function Calling — 定义函数 Schema，模型输出结构化参数
• Guided Generation — 在推理阶段约束 Token 生成空间（如 Outlines 库）
• Output Parsing + Retry — 解析失败时自动重试，附带错误信息

在生产系统中，Prompt 需要像代码一样管理：

• 版本控制 — 每个 Prompt 有版本号，变更有审核流程
• 参数化 — 将可变部分提取为变量，避免硬编码
• A/B 测试 — 新 Prompt 先灰度发布，对比核心指标
• 回滚机制 — 效果不好能一键回滚到上一版本
• 监控告警 — 跟踪 Prompt 变更后的输出质量变化

MLflow 可以作为 Prompt Registry：存储 Prompt 模板、版本历史、评估结果，和模型管理使用同一套工具。

用一个"更强"的 LLM 作为评审员，按预定义标准给输出打分。核心注意事项：

• 位置偏差 — Judge 倾向于给第一个选项更高分 → 随机化呈现顺序
• 冗长偏差 — 更长的回答通常得分更高 → 在评分标准中强调简洁性
• 自我偏好 — 同一模型更偏好自己风格的输出 → 用不同模型做 Judge
• 校准 — 必须和人工评估对比校准，Cohen's Kappa > 0.6 才可信

离线评估只是起点，线上行为可能完全不同。生产环境需要：

• A/B 测试 — Model Serving 流量分割，同时运行新旧版本，对比业务指标
• 漂移检测 — 监控输入分布变化（用户行为变了）和输出质量变化（模型退化了）
• 用户反馈 — 收集 thumbs up/down、报告不准确，构建反馈闭环
• 告警机制 — 质量指标低于阈值自动告警，严重时自动回滚

Databricks Lakehouse Monitoring 可以直接对 Inference Table 做漂移分析和质量监控。

LLM 推理延迟的构成：

Streaming 是最容易见效的优化：不等完整生成结束，逐 Token 流式返回。用户感知延迟从"等 5 秒"变成"几乎立刻开始"。

成本构成：

• GPU 计算 — 最大头，自托管模型的固定成本或 API 调用的变动成本
• 存储 — 向量数据库、模型权重、推理日志
• 网络 — 跨区域传输、API 调用

控制策略：

• 模型路由 — 简单问题用小模型，复杂问题才调用大模型。可以节省 60-80% 成本
• 缓存 — 语义缓存，相似问题直接返回缓存结果
• Prompt 优化 — 减少 Token 数（尤其是 System Prompt）
• 批量处理 — 非实时需求用离线批量推理，GPU 利用率更高
• 自动扩缩容 — 流量低谷自动缩容到最小副本数
• 预算告警 — 设置每日/每月预算上限，超出自动降级或熔断

GenAI 应用的监控比传统应用复杂得多——不只看延迟和错误率，还要看输出质量。

三层监控体系：

• 基础设施层 — GPU 利用率、内存占用、Queue 深度、错误率
• 应用层 — 请求延迟（P50/P95/P99）、Token 消耗、缓存命中率
• 质量层 — 输出长度分布、拒答率、用户评分、幻觉率、检索命中率

Databricks Inference Table：自动记录每次推理的完整信息（输入、输出、延迟、Token 数），存入 Delta Table，可以直接用 SQL 分析和 Lakehouse Monitoring 做漂移检测。

GenAI 应用的 CI/CD 和传统软件有关键区别：除了代码，还要管理数据、模型和 Prompt。

完整流水线：

1. 代码变更 — Git PR → 代码审查 → 单元测试
2. Prompt 变更 — Prompt PR → 自动评估 → 回归测试
3. 数据变更 — 数据更新 → 重建向量索引 → 检索质量测试
4. 模型变更 — 新模型/微调 → 离线评估 → A/B 测试 → 全量切换
5. 部署 — 灰度发布 → 质量监控 → 自动回滚机制

关键原则：

• 每次变更都有评估 — 不管是改了一行 Prompt 还是换了整个模型
• 所有资产版本化 — 代码、Prompt、数据快照、模型权重全部有版本
• 可复现 — 任何时间点的系统状态都能完整复现

把所有环节串起来，一个完整的 GenAI 应用生命周期：

1. 数据准备 — 收集、清洗、标注 → Unity Catalog 注册
2. 模型选择/训练 — 评估基座模型 → 决定是否微调 → MLflow 追踪实验
3. RAG 构建 — 文档分块 → Embedding → Vector Search 索引
4. Prompt 开发 — 设计 System Prompt → Few-shot 示例 → 迭代优化
5. 评估 — 自动化指标 + LLM-as-Judge + 人工审核
6. 部署 — Model Serving → 灰度发布 → A/B 测试
7. 监控 — Inference Table → 质量监控 → 漂移检测 → 告警
8. 迭代 — 收集反馈 → 更新数据/Prompt/模型 → 重新评估 → 重新部署