AI 应用工程完整交付包样板¶

样板项目：企业技术知识库 RAG + AI 学习助手
用途：给你一份能直接照着改成自己项目交付包的完整参考。

一、需求文档¶

1.1 背景¶

当前教程内容多、主题广，用户在查资料时主要有三类问题：

1. 找不到正确章节
2. 找到章节但答案不够聚焦
3. 回答质量不稳定，缺少引用和错误兜底

1.2 目标用户¶

• 主用户：你自己
• 使用场景：学习检索、概念讲解、章节跳转、错题定位、复习问答

1.3 范围¶

本期只做：

• 文档检索
• 引用返回
• 对章节内容的讲解与总结
• bad case 标记与人工复核入口

本期不做：

• 多用户权限系统
• 长期会话记忆
• 自动改写教程正文

1.4 验收标准¶

二、架构图与技术设计¶

flowchart TD
    U[浏览器用户] --> W[Docs 前端页面]
    W --> A[AI 助手 API]
    A --> G[Query Rewrite]
    G --> R[检索层]
    R --> V[向量索引]
    R --> K[关键词索引]
    A --> C[上下文组装器]
    C --> M[LLM]
    M --> P[答案后处理]
    P --> Q[引用与来源]
    P --> S[安全与格式检查]
    S --> W
    A --> O[观测与评测]
    O --> L[日志 / Tracing / Bad Case]

2.1 关键设计决策¶

• 检索采用“关键词 + 向量”双路召回，避免只靠 embedding 导致章节标题检索不稳。
• 响应必须附引用，优先返回站内文档路径和章节名。
• 对高风险问题增加“只基于文档回答”的提示，降低幻觉。

2.2 关键异常路径¶

• 检索空结果：回退到关键词搜索 + 提示用户缩小问题范围
• LLM 超时：回退到“仅返回最相关文档与摘要”
• 引用缺失：答案不直接放行，转为“候选文档列表”

三、SLO 与核心指标¶

3.1 错误预算¶

• 月度可用性按 99.5% 计算，错误预算约 216 分钟 / 月。
• 若连续 3 天 P95 超标，暂停新功能，优先处理稳定性。

四、压测与 Benchmark 报告¶

4.1 基线口径¶

• 基线 A：仅关键词检索
• 基线 B：单路向量检索
• 当前方案：混合召回 + 重排 + 引用约束

4.2 评测集设计¶

• 100 条学习问答集
• 30 条跨章节问题
• 20 条故意模糊问题
• 20 条 bad case 回归问题

4.3 记录模板¶

4.4 面试可讲点¶

• 为什么要做混合召回
• 为什么要把“引用完整率”单独拉成硬指标
• 为什么 bad case 回归集不能省

五、成本报告¶

5.1 结论模板¶

• 哪部分成本最高
• 哪个优化手段性价比最好
• 哪个优化虽然降成本，但明显伤害质量，不能上线

六、发布记录¶

七、事故复盘¶

7.1 事故标题¶

某次索引同步后，AI 助手大量返回过期章节引用。

7.2 现象¶

• 问题能答出来，但引用路径指向旧目录
• 用户点击后跳到错误文档或旧锚点

7.3 根因¶

• 文档重命名后，索引增量更新未清理旧路径
• 发布前缺少“引用可点击性”回归

7.4 处置¶

• 全量重建索引
• 增加引用跳转校验脚本
• 把“文档改名”纳入发布 checklist

7.5 追踪动作¶

1. 发布前强制跑引用校验
2. bad case 集新增“重命名后检索”场景
3. 增量同步改为带 tombstone 清理

八、简历条目¶

• 设计并实现企业知识库 RAG 学习助手，构建混合召回、引用约束与 bad case 回归闭环，形成可观测、可复盘的 AI 应用交付包。
• 建立检索质量、引用完整率、P95 延迟与缓存命中率指标体系，将项目从 Demo 推进到可灰度、可回滚、可持续优化的工程状态。

九、面试讲解结构¶

1. 先讲业务问题：为什么单纯全文搜索不够
2. 再讲架构：检索、组装、生成、引用、安全检查
3. 再讲指标：命中率、引用完整率、P95、成本
4. 再讲事故：索引过期导致引用失效，如何定位与修复
5. 最后讲 trade-off：质量、速度、成本如何平衡

十、配套文档¶

• AI 应用工程交付线
• 统一交付模板包
• 项目交付资产打包清单