4.3 KiB
4.3 KiB
aliases, type, tags, status, created
| aliases | type | tags | status | created | ||||
|---|---|---|---|---|---|---|---|---|
|
draft |
|
archive | 2026-08-21 |
修订版重构纲要：从“数据标注”到“LLM 评测工程”
新标题
从软件工程到 LLM 评测工程：数据、评测与 AI QA 实战路线
核心目标
12 周后，读者能独立建立一个小型 LLM / RAG / Agent Evaluation System，而不是仅了解数据标注概念。
叙事主线
软件测试能力
→ 测试用例（Eval Dataset）
→ 断言（Rubric / Grader）
→ 测试运行器（Eval Runner）
→ 缺陷分类（Failure Taxonomy）
→ 回归测试（Regression Eval）
→ CI/CD（Continuous Eval）
章节重构
- 结论与诚实预警：明确目标定位，并预先解决“没有数据、不会选题、没有整块时间”三个中断点。
- 工作内容与岗位地图：将 Annotation、Data Quality、Eval、AI QA、Agent/安全测试分层；增加“失败案例是否回流”的岗位判定问题。
- 软件工程能力迁移表：系统地将测试、契约、日志、CI、Code Review 映射到 Eval 工作。
- 先选项目，再补知识：提供按开发背景分类的选题决策树，优先 Agent tool-use evaluation、RAG evaluation、Code agent evaluation。
- 72 小时最小项目：Day 1 20 个用例和 rubric；Day 2 两个模型 + 盲评；Day 3 实现验证、评测与报告。附标准项目目录。
- 数据集设计与版本化：说明 100 条样本必须分层采样；将 Test Definition 与 Test Execution 分离；给出 schema。
- Rubric、人工标注与一致性：强调 pass/fail 或 0/1/2；双人独立标注、原始一致率、争议归因与规则更新。
- 自动评分与 LLM Judge 校准：混淆矩阵、精确率/召回率、错误代价、位置偏差与人工复核。
- 评测系统而不只评模型：从 RAG 检索到工具执行再到最终答复，使用根因分类；Agent 侧重状态、权限、副作用、幂等性和真实结果。
- 小而真实的安全项目：限定为 RAG prompt injection 或工具越权用例，不做泛化“红队”。
- 12 周项目驱动路线：第一周即运行 eval；随后依次增加失败分类、judge 校准、RAG/Agent、对抗案例、CI 与作品集。
- 作品与求职证据链：Problem → Dataset → Rubric → Evaluation → Failure analysis → Improvement → Regression；提供公开发布、岗位检索与脱敏清单。
- 两条下一步路径：2 天快速试探或 72 小时完整启动。
写作原则
- 每个抽象概念后给一个可执行动作、结构模板或验收标准。
- 初学者的第一版不使用复杂框架；Python、Git、JSONL、验证脚本和 API 调用即足够。
- 把 Dataset Card 限制在 1—2 页的必要字段，避免形式主义。
- 所有示例仅使用公开、明确许可或合成数据；禁止将真实客户数据用于公开作品。
- 对 Agent 测试重点呈现工具选择、参数、授权、环境状态和真实执行结果，而非只评最终文本。
需在最终正文中明确的验收能力
- 设计分层 eval dataset，构造正常、负例、边界和对抗样本。
- 编写可复用、可校准的 rubric。
- 执行盲评并分析标注分歧。
- 写出 schema validation 与 eval runner。
- 把自动 grader 或 LLM judge 与人工真值校准。
- 建立 failure taxonomy 和回归测试集。
- 对 RAG、Agent 的链路和安全边界进行系统级验证。
- 产出可复跑的报告并接入 CI。