详细评分 Rubric 与评估框架 · Jimmy Huang's Blog

详细评分 Rubric 与评估框架

本页目录· 7 条

第1部分：Web Service API Engineering（20分）
第2部分：Containerization and Optimisation（10分）
第3部分：Infrastructure as Code（IaC）（10分）
第4部分：Kubernetes Deployment（15分）
第5部分：Load Generation and Performance Baseline（20分）
第6部分：Empirical Benchmark Report（10分）
第7部分：Interview（15分）

本评估采用 Monash University 的标准评分体系：Pass（P：50-59）、Credit（C：60-69）、Distinction（D：70-79）以及 High Distinction（HD：80-100）。以下为完整 rubric，定义了作业七个组成部分在各分数档位下的具体基线与技术要求。

第1部分：Web Service API Engineering（20分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	API 无法初始化、在接收 HTTP 请求时崩溃，或完全无法解码 base64 图像字符串。机器学习推理失败，且 JSON 响应格式错误或缺失。	已基本实现 FastAPI 框架。`/api/predict` 端点能够成功解码图像、执行 YOLO 模型推理，并返回包含边界框坐标的有效 JSON 响应。标注图像 API 可能存在 bug、不完整，或缺失。	JSON API 和图像 API 都能依照严格的负载规范正确运行。然而，由于对推理任务的异步处理较差，并发请求偶尔会导致服务器阻塞或 HTTP 超时。代码结构缺乏模块化。	API 非常稳健。图像编码与解码通过优化过的库高效处理。应用架构体现了清晰的关注点分离，将路由逻辑与机器学习推理逻辑隔离开来。对无效 JSON 负载的错误处理已实现。	非常出色的实现，展现出对 Python 并发的深刻理解。学生使用了高级 FastAPI 特性，明确确保 CPU 密集型的 YOLO 推理不会阻塞异步事件循环，从而实现更优越的并发能力和最小化的延迟排队。

第2部分：Containerization and Optimisation（10分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	Dockerfile 完全缺失，或无法构建镜像，或生成的容器由于依赖缺失或语法错误，在启动后立即崩溃。	提供了一个基础 Dockerfile，能够成功构建并运行应用。但由于安装了不必要的库，镜像体积过大。	Dockerfile 功能完整，并恰当地使用了 Python 专用的轻量级基础镜像。应用依赖通过标准的 `requirements.txt` 文件进行了清晰管理和安装。	Dockerfile 已高度优化。通过先复制 requirements 再复制应用源代码，有效利用了 Docker layer caching。	无可挑剔、达到生产级别的 Dockerfile。学生展示了高级技术，例如 multi-stage builds，将依赖编译与最终运行时镜像分离。最终镜像体积被大幅缩小，并且容器配置为以非 root 用户身份执行，以增强安全合规性。

第3部分：Infrastructure as Code（IaC）（10分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	未提供任何 IaC 实现。所有云基础设施，包括网络和集群，均通过图形化 Web 控制台手动配置。	提供了基础 IaC 脚本，但只配置了所需基础设施的一部分。脚本可能需要大量人工干预、变量硬编码，或需要通过控制台调整后才能成功执行。	提供了 IaC 脚本，但只配置了所需基础设施的一部分。脚本执行不需要人工干预。	完整且可运行的 IaC 实现。IaC 脚本能够通过一次自动化 `apply` 命令成功配置整个生态系统——VCN、子网、路由表、Internet Gateway 以及完整集群。	专业级自动化。配置变量被抽象到专门的 variables 文件中。配置依赖高级模块化结构，并使用 data sources 动态获取所需的 OCID，体现出对云自动化原理的深刻理解。

第4部分：Kubernetes Deployment（15分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	Kubernetes 部署完全失败。Pods 频繁进入 `CrashLoopBackOff` 或 `ImagePullBackOff` 状态。服务未能成功暴露到公网，导致 API 无法访问。	应用已部署到 K8s。创建了基础的 Deployment 和 Service manifest。API 可以通过公网 IP 访问，但关键资源限制（CPU 和内存）在 YAML 中要么完全被忽略，要么配置错误。	Deployment 和 Service manifest 配置正确。要求的资源 requests 和 limits（每个 pod 严格为 1 vCPU）在 deployment YAML 中被严格且正确地实施。	部署架构无明显缺陷。Service 能正确分发流量。Replica sets 可以通过配置变更轻松扩展。YAML 文件严格遵循 Kubernetes 最佳实践，使用了明确的 label selectors 和合适的 namespace 管理。	在满足所有 Distinction 标准之外，学生还主动在 deployment manifest 中实现了 readiness probes 和 liveness probes。这确保 Kubernetes 调度器只会将负载均衡流量路由到那些已经完全初始化并将 YOLO 模型权重加载到内存中的 pods，从而避免扩容过程中请求丢失。

第5部分：Load Generation and Performance Baseline（20分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	Locust 负载生成脚本无法运行，或生成了无效的 HTTP 请求。未进行任何有效的性能测试或系统基准测试。	Locust 脚本可以运行，并发送有效的 base64 JSON 负载。能够成功对集群施加负载，但应用未达到基线性能指标：在 1 vCPU pod 上，在出现超时失败或 HTTP 错误之前，吞吐量低于每秒 1 次查询（QPS）。	系统能够平稳处理适度并发负载（每个 pod 1 到 5 QPS）。Locust 脚本能够正确验证 HTTP 响应。随着并发增加，观察到一定的延迟退化。	系统达到了要求的性能基线（每个 1 vCPU pod 可持续承载 5 到 10 QPS），错误率低且延迟可接受，展示了足够好的应用层工程设计和事件循环管理。	系统远超性能基线（每个 pod 可持续承载 >10 QPS，且平均延迟 <500ms）。学生对 FastAPI 服务进行了工程优化，使其在高并发负载下高效最大化 CPU 利用率，有效缓解了 Python 在推理操作中的局限性。

第6部分：Empirical Benchmark Report（10分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	基准测试报告缺失、严重不完整，或包含在数学上不可能成立或伪造的负载测试数据。	报告包含要求的表格和基础图表。但分析性讨论极少。对于 pod 数量扩展与系统性能结果之间的关系解释得很差，仅停留在描述层面，没有洞见。	表格和图形绘图格式清晰、标注明确。分析性讨论能够准确描述观察到的扩展行为。	深入的实证分析。学生准确识别了具体的计算瓶颈。图表绘制专业，具有正确的坐标轴、单位和说明性图例。	极其出色、达到发表质量的基准测试报告。分析应用了理论框架来解释系统何时达到饱和，以及何时出现指数级延迟退化。讨论还批判性地指出了在受限的边缘/云环境中部署复杂机器学习模型所固有的权衡。

第7部分：Interview（15分）

评分档位	F（<50）	P（50-59）	C（60-69）	D（70-79）	HD（80-100）
评估标准说明	门槛失败（Hurdle Fail）。学生无法解释其提交的代码，无法演示正在运行的集群，或能明确看出存在学术不端，例如未说明或自己都无法理解的生成式 AI 使用。总作业分数将被封顶为 45%（NH）。	学生能够成功演示运行中的系统，并对其 Python 代码、Dockerfile 和基础 Kubernetes `kubectl` 命令作出基本、可接受的解释。系统只能处理较低并发。	学生能够成功演示运行中的系统，并对其 Python 代码、Dockerfile 和基础 Kubernetes `kubectl` 命令作出可接受的解释。系统只能处理基线并发。	学生能够非常自信地讲解其系统架构。他们能为自己的架构决策给出清晰、合逻辑的理由，并展现出对 Docker 优化和 Kubernetes 网络路由的强实践理解。	学生对主题内容展现出完全掌握。他们能够毫不费力地阐述复杂概念，例如详细说明服务器在同步模型推理期间如何与 Python 后端交互，或解释其状态管理的底层机制和依赖映射。

请注意： 面试是本次作业的门槛要求。即使你的提交和演示都很完美，如果你不能证明自己对项目具有足够理解（是这个作业本身，不是整门课），你的最高得分也只有 45 分。