第13周：综合项目实战

本日概要

综合项目的成败大半取决于选题。一个适合的题目要同时满足四条：范围可在给定时间内完成、数据可获得且可公开或可脱敏、成效可用具体指标衡量、以及失败不会造成实际损害。本周的建议题目是企业智能知识助手——它覆盖前面所学的检索、生成、接口、部署与评估，且可以用公开文档完成。选题阶段最重要的产出不是技术方案，而是一份写清「做什么、不做什么、怎么算完成」的项目说明；没有明确的不做清单，范围会在实施过程中不断扩张，最后什么都没做完。

学习目标

• 能用四条标准判断一个选题是否适合作为课程项目
• 能写出包含明确排除项的项目范围说明
• 能把「怎么算完成」转化为可判定的成功标准
• 能识别项目的主要风险并给出应对或降级方案

核心讲解

实践任务

撰写项目说明：目标、范围、明确排除项、成功标准、里程碑与风险，并请同伴按检查表评审。

• 用四条标准评估两到三个候选题目，逐条打分并说明理由，选定其中一个。
• 撰写项目说明：目标、用户与使用场景、范围、明确排除项（每条附理由）。
• 把成功标准写成可判定的形式，包含指标名称、测试样本集与目标值。
• 列出至少五项风险（数据、技术、时间、环境、评估各一），为每项写出应对或降级方案；请同伴按四条标准评审并记录反馈。

自测与答案

今日完成标准

• 提交两到三个候选题目的四条标准评分与选定理由
• 提交项目说明，含目标、范围、明确排除项及每条理由
• 提交可判定的成功标准与不少于五项风险及其应对方案，附同伴评审记录

常见错误与纠正提示

• 选题范围过大，两周只能做出演示而无法评估与复现
• 项目说明只写要做什么，没有不做清单，范围持续扩张
• 成功标准写成主观描述，无法客观判断是否完成

分层任务

关联知识点

• AI Agent
• RAG检索增强生成

延伸阅读

• Prompt engineering overview（Anthropic 官方文档）
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 论文页面）

本日概要

数据准备决定项目的上限。这一天要完成三件事：确定文档来源并确认其可用性与许可、完成清洗与切块并记录处理规则、以及构建评估集。评估集必须在开发开始前完成——先有测试再有实现，才能避免用实现去迁就评估。评估集应覆盖三类问题：能直接从单篇文档回答的、需要综合多篇的、以及应当回答「资料中没有」的。第三类最容易被忽略，却最能反映系统是否诚实：一个对不知道的问题也强行作答的系统，在真实使用中比答不出更危险。

学习目标

• 能确认文档来源的可用性与许可，并记录清洗与切块的处理规则
• 能构建覆盖单篇、多篇与无答案三类问题的评估集
• 能为每条评估问题定义可判定的期望行为
• 能说明为什么评估集必须在实现之前完成

核心讲解

实践任务

完成文档准备与切块，构建包含三类问题的评估集，并为每条问题标注应命中的片段与期望行为。

• 确定文档来源，记录数量、格式、许可状况与需要脱敏的内容；编写可重复执行的清洗与切块脚本。
• 运行脚本并记录统计信息：文档数、块数、块长度分布，以及清洗掉的噪声类型与比例。
• 构建不少于三十条的评估集，三类问题各占一定比例，为每条标注应命中片段与期望行为。
• 对切块参数做至少两组对比，用评估集中的单篇可答问题测量命中率差异，据此确定参数并记录依据。

自测与答案

今日完成标准

• 提交可重复执行的清洗切块脚本与运行统计信息
• 提交不少于三十条的评估集，三类问题齐全且每条标注应命中片段与期望行为
• 提交两组切块参数的对比数据与最终参数的选择依据

常见错误与纠正提示

• 手工处理文档不留脚本，参数调整时无法重跑
• 评估集只含单篇可答的问题，无法发现多篇综合与强行作答的问题
• 先做实现再补评估，评估被设计成能通过当前实现

分层任务

关联知识点

• 大模型训练
• 机器学习基础

延伸阅读

• Chroma Documentation: Introduction（Chroma 官方文档）
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 论文页面）

本日概要

核心开发阶段要抵抗一个常见诱惑：先把整条链路搭起来再统一调试。更稳妥的做法是逐环节可测——检索、重排、上下文组装、生成、引用校验每一环都能单独运行并被评估。这样任一环出问题时可以直接定位，而不必在整条链路上猜测。开发顺序上建议先做检索并用评估集中的单篇问题验证召回，再做生成与引用，最后加重排与组装优化。每完成一环就跑一次评估集并记录当时的指标，形成一条随开发推进的曲线——这条曲线本身就是最好的项目进展记录。

学习目标

• 能把检索增强链路拆分为可单独运行与评估的环节
• 能按由基础到优化的顺序组织开发，并说明理由
• 能在每一环完成后运行评估并记录指标变化
• 能实现引用一致性校验与「资料中没有」的诚实回答路径

核心讲解

实践任务

按逐环节可测的方式实现核心链路，每完成一环运行评估集并记录指标，形成进展曲线。

• 把链路拆成检索、组装、生成、校验四个可单独调用的环节，为每环写出输入输出定义与至少一条测试。
• 先实现检索，用评估集中的单篇可答问题测量召回率，达到预设下限后再进入下一环。
• 实现生成与引用输出，运行完整评估集，记录检索召回率与有正确片段时的回答准确率。
• 实现召回质量下限与引用一致性校验，用无答案问题验证拒答路径；统计校验触发率与其中真正错误的比例，并绘制随开发推进的指标曲线。

自测与答案

今日完成标准

• 提交四个环节的输入输出定义与各自的测试
• 提交每完成一环后的评估结果与随开发推进的指标曲线
• 提交拒答路径的阈值确定过程，以及引用校验的触发率与真正错误比例统计

常见错误与纠正提示

• 先搭完整链路再统一调试，问题无法定位到具体环节
• 先精调提示后发现瓶颈在检索，前期投入浪费
• 不实现拒答路径，系统对无依据问题也强行作答

分层任务

关联知识点

• RAG检索增强生成
• 提示工程

延伸阅读

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 论文页面）
• Chroma Documentation: Introduction（Chroma 官方文档）
• Prompt engineering overview（Anthropic 官方文档）

本日概要

接口与界面是项目从「能跑」变成「能用」的一步，重点不在美观而在把系统的不确定性如实传达给用户。三条设计原则：一是把依据展示出来——引用片段应当可点击查看原文，让用户能自行核对；二是把状态区分清楚——正在检索、正在生成、未找到依据、服务异常应当有不同的表现，而不是统一显示「加载中」或「出错了」；三是保留反馈入口——让用户能标记回答有用或有误，这些标记是后续改进的最直接依据。技术上则沿用第十周的要求：输入校验、流式返回、取消传递与可区分的错误语义。

学习目标

• 能设计把不确定性如实传达给用户的界面表现
• 能区分并实现检索中、生成中、无依据、服务异常四类状态
• 能实现引用片段的可查看与原文定位
• 能设计用户反馈的采集与存储，使其可用于后续改进

核心讲解

实践任务

实现接口与最小界面，验证四类状态的区分展示、引用可查看与反馈记录三项功能。

• 实现接口层：输入校验、流式返回、取消传递与四类可区分的错误语义，并为每类构造触发样例。
• 实现最小界面：展示回答、引用片段与原文定位链接，验证用户能在片段中找到关键陈述。
• 实现四类状态的区分展示，分别构造场景验证提示文案正确且可指导用户下一步操作。
• 实现反馈标记与存储，记录问题、召回片段、回答、引用与系统版本；模拟五条有误反馈并按三类原因归因。

自测与答案

今日完成标准

• 提交接口实现与四类错误语义的触发样例
• 提交界面截图或记录，证明引用可查看、四类状态区分展示
• 提交反馈存储结构与五条模拟反馈的三类归因统计

常见错误与纠正提示

• 只展示答案不展示引用，用户无法核对
• 所有等待统一显示「加载中」，用户无法判断该等还是该重试
• 反馈只记录「有误」不记录上下文与版本，无法归因也无法验证修复

分层任务

关联知识点

• AI开发工具链

延伸阅读

• FastAPI Documentation（FastAPI 官方文档）
• FastAPI: Deployments Concepts（FastAPI 官方文档）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）

本日概要

部署要回答的问题是：怎样让别人能稳定地用上它，并且出问题时能查、能回滚。最小可用的部署方案包含五项：容器化打包（保证运行环境一致）、配置与密钥外置（同一镜像可用于不同环境）、健康检查（区分进程存活与服务就绪）、日志与指标采集（出问题时有据可查）、以及版本化与回滚路径（切换只需改指向）。这一天不追求复杂的编排，追求的是每一项都真实可用并验证过——一个能一键回滚的简单部署，价值远高于一个配置复杂但从未演练过回滚的方案。

学习目标

• 能把应用容器化并说明镜像应包含什么、不应包含什么
• 能实现配置与密钥外置，使同一镜像可用于不同环境
• 能区分存活检查与就绪检查，并说明混用会造成什么问题
• 能实现版本化与回滚，并通过演练验证其可用性与耗时

核心讲解

实践任务

完成容器化部署，验证配置外置、健康检查、日志采集与回滚四项能力，并记录一次回滚耗时。

• 编写容器构建文件，确认镜像中不含配置、密钥与数据；记录镜像体积与构建耗时。
• 实现配置与密钥外置，用两组不同配置启动同一镜像，验证行为差异符合预期。
• 分别实现存活检查与就绪检查；模拟模型加载中的状态，验证就绪检查失败而存活检查通过。
• 部署新版本后执行一次回滚演练，记录从决定回滚到服务恢复的耗时，并确认回滚后的版本与权重版本均为预期值。

自测与答案

今日完成标准

• 提交容器构建文件与镜像内容检查结果，确认不含配置、密钥与数据
• 提交同一镜像在两组配置下的行为差异验证，以及两类健康检查的状态验证
• 提交回滚演练记录，含实际耗时与回滚后版本确认

常见错误与纠正提示

• 把配置或密钥打进镜像，每个环境重复构建且密钥长期留存
• 只实现一种健康检查，模型加载期间流量被打入造成批量失败
• 文档写着支持回滚但从未演练，真正需要时才发现不可行

分层任务

关联知识点

• 云计算
• AI开发工具链

延伸阅读

• FastAPI: Deployments Concepts（FastAPI 官方文档）
• Kubernetes: Configure Liveness, Readiness and Startup Probes（Kubernetes 官方文档）
• OpenTelemetry: Signals（OpenTelemetry 官方文档）

本日概要

测试优化阶段要做的不是把指标调到最高，而是把系统的真实表现测清楚并记录下来。三类测试缺一不可：功能测试（评估集上的各项指标）、性能测试（不同并发下的延迟分位数与吞吐）、以及异常测试（依赖不可用、输入越界、注入尝试时的行为）。优化则应遵循先测后改的原则——每次只改一项，改动前后都跑同一套测试，并记录指标变化。最后要形成一份完整的测试报告，其中最有价值的部分往往不是达标的项，而是明确写出的「当前不满足什么、原因是什么、需要多少投入才能改善」。

学习目标

• 能设计覆盖功能、性能与异常三类的测试方案
• 能按单变量原则组织优化，使指标变化可归因
• 能在报告中如实呈现未达标项及其原因与改善成本
• 能区分测试通过与系统可靠，并说明测试覆盖的边界

核心讲解

实践任务

完成功能、性能与异常三类测试，做至少两轮单变量优化并记录指标变化，形成测试报告。

• 运行功能测试，记录四项指标；按问题类型（单篇、多篇、无答案）分别统计而不只给总分。
• 运行性能测试，覆盖至少三个并发档位，记录延迟分位数与吞吐，标出拐点。
• 运行异常测试：构造依赖不可用、三类越界输入与两类注入尝试，逐项记录系统行为是否符合预设。
• 进行至少两轮单变量优化，每轮记录改动项、改动前后指标与耗时变化；对收益不明显的改动执行回退并记录；最后撰写测试报告，单列未达标项及其原因与改善成本估计。

自测与答案

今日完成标准

• 提交功能测试的四项指标，并按问题类型分别统计
• 提交至少三个并发档位的性能数据与拐点，以及异常测试逐项的行为记录
• 提交两轮单变量优化的改动、前后指标与回退记录，以及含未达标项说明的测试报告

常见错误与纠正提示

• 只做功能测试，上线后在并发或依赖故障下暴露问题
• 一轮同时改多项，指标提升但无法归因
• 报告只写达标项，掩盖系统的真实边界

分层任务

关联知识点

• AI开发工具链
• 机器学习基础

延伸阅读

• Google SRE Book: Service Level Objectives（Google SRE Book 官方页面）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）
• MLflow Tracking（MLflow 官方文档）

本日概要

项目汇报的目标不是展示做了多少工作，而是让听众准确理解系统能做什么、不能做什么、以及结论的可信度。有效的结构是五段：问题与目标、方案与关键决策、证据与指标、局限与未验证事项、以及后续计划。其中「局限」一段最能体现专业性——一个能清楚说出自己系统边界的作者，比一个只展示成功案例的作者更值得信任。演示环节要准备好失败案例，主动展示系统答不出或答错的情形并解释原因，这比精心挑选的成功演示更有说服力，也更接近真实使用体验。

学习目标

• 能按五段式结构组织项目报告，每段有明确的信息职责
• 能用测试数据而非主观描述支撑结论
• 能主动呈现系统局限与失败案例，并解释成因
• 能把同伴提问转化为对局限说明的补充

核心讲解

实践任务

撰写五段式项目报告并做一次包含失败案例的演示，收集同伴提问并据此补充局限说明。

• 按五段式撰写项目报告，确保证据段的每个数字都附测量条件。
• 准备两到三个失败案例，为每个分析成因并归类到具体环节。
• 完成一次演示，包含成功案例与失败案例，并说明系统的能力边界与适用范围。
• 记录同伴提问，把答不上来的问题如实写入局限与未验证事项一段，并据此更新后续计划的优先级。

自测与答案

今日完成标准

• 提交五段式报告，证据段每个数字附测量条件
• 提交两到三个失败案例及其成因归类
• 提交演示记录与同伴提问清单，以及据此更新的局限说明与后续计划

常见错误与纠正提示

• 报告罗列技术栈而不说明关键决策及其理由
• 给出指标数字却不写测量条件，听众无法判断适用范围
• 演示只挑成功案例，听众自行试出问题后信任受损

分层任务

关联知识点

• AI教育
• AI办公

延伸阅读

• Google SRE Book: Service Level Objectives（Google SRE Book 官方页面）
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 论文页面）
• OWASP Top 10 for LLM Applications（OWASP GenAI 官方页面）