79 lines
4.3 KiB
Markdown
79 lines
4.3 KiB
Markdown
---
|
||
type: draft
|
||
tags:
|
||
- LLM评测
|
||
- 草案
|
||
- 归档
|
||
status: archive
|
||
created: 2026-08-21
|
||
---
|
||
|
||
# 修订版重构纲要：从“数据标注”到“LLM 评测工程”
|
||
|
||
## 新标题
|
||
|
||
**从软件工程到 LLM 评测工程：数据、评测与 AI QA 实战路线**
|
||
|
||
## 核心目标
|
||
|
||
12 周后，读者能独立建立一个小型 **LLM / RAG / Agent Evaluation System**，而不是仅了解数据标注概念。
|
||
|
||
## 叙事主线
|
||
|
||
```text
|
||
软件测试能力
|
||
→ 测试用例（Eval Dataset）
|
||
→ 断言（Rubric / Grader）
|
||
→ 测试运行器（Eval Runner）
|
||
→ 缺陷分类（Failure Taxonomy）
|
||
→ 回归测试（Regression Eval）
|
||
→ CI/CD（Continuous Eval）
|
||
```
|
||
|
||
## 章节重构
|
||
|
||
1. **结论与诚实预警**：明确目标定位，并预先解决“没有数据、不会选题、没有整块时间”三个中断点。
|
||
2. **工作内容与岗位地图**：将 Annotation、Data Quality、Eval、AI QA、Agent/安全测试分层；增加“失败案例是否回流”的岗位判定问题。
|
||
3. **软件工程能力迁移表**：系统地将测试、契约、日志、CI、Code Review 映射到 Eval 工作。
|
||
4. **先选项目，再补知识**：提供按开发背景分类的选题决策树，优先 Agent tool-use evaluation、RAG evaluation、Code agent evaluation。
|
||
5. **72 小时最小项目**：Day 1 20 个用例和 rubric；Day 2 两个模型 + 盲评；Day 3 实现验证、评测与报告。附标准项目目录。
|
||
6. **数据集设计与版本化**：说明 100 条样本必须分层采样；将 Test Definition 与 Test Execution 分离；给出 schema。
|
||
7. **Rubric、人工标注与一致性**：强调 pass/fail 或 0/1/2；双人独立标注、原始一致率、争议归因与规则更新。
|
||
8. **自动评分与 LLM Judge 校准**：混淆矩阵、精确率/召回率、错误代价、位置偏差与人工复核。
|
||
9. **评测系统而不只评模型**：从 RAG 检索到工具执行再到最终答复，使用根因分类；Agent 侧重状态、权限、副作用、幂等性和真实结果。
|
||
10. **小而真实的安全项目**：限定为 RAG prompt injection 或工具越权用例，不做泛化“红队”。
|
||
11. **12 周项目驱动路线**：第一周即运行 eval；随后依次增加失败分类、judge 校准、RAG/Agent、对抗案例、CI 与作品集。
|
||
12. **作品与求职证据链**：Problem → Dataset → Rubric → Evaluation → Failure analysis → Improvement → Regression；提供公开发布、岗位检索与脱敏清单。
|
||
13. **两条下一步路径**：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。
|
||
|
||
## 参考资料定位
|
||
|
||
- OpenAI：任务、测试数据和 grader 是 Evals 的基本构成，并需持续分析运行结果。[1]
|
||
- Anthropic：Agent eval 是对输入、工具、环境、轨迹、状态和 outcome 的系统测试，harness 同时评估模型与 agent scaffold。[2]
|
||
- OWASP：Prompt Injection 不会仅因使用 RAG 或微调而消失，应以小范围用例持续测试缓解措施。[3]
|
||
- Hugging Face：Dataset Card 用于说明数据内容、使用语境及潜在偏差；个人项目应保留必要元数据即可。[4]
|
||
|
||
[1]: https://developers.openai.com/api/docs/guides/evals
|
||
[2]: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
|
||
[3]: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
|
||
[4]: https://huggingface.co/docs/hub/datasets-cards
|