rename LLM_Evaluation files to English, keep Chinese content with aliases
This commit is contained in:
windyboy
@@ -0,0 +1,28 @@
|
||||
---
|
||||
aliases:
|
||||
- 材料清单
|
||||
type: reference
|
||||
tags:
|
||||
- LLM评测
|
||||
- 归档
|
||||
status: active
|
||||
created: 2026-08-21
|
||||
---
|
||||
|
||||
# 材料清单与归档说明
|
||||
|
||||
本目录保留早期输出与设计草案，目的是保存职业背景、演化路径和可追溯性；日常学习请从 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]] 开始，不要从草案直接进入。
|
||||
|
||||
| 文件 | 当前角色 | 何时阅读 | 为什么归档而非放在主路线 |
|
||||
|---|---|---|---|
|
||||
| [[02_Areas/Job/llm_data_annotation_programmer_roadmap|大模型数据标注与程序员入门]]（原文存于 02_Areas/Job，本专区不再复制副本） | 职业全景与程序员能力迁移背景 | 想理解岗位、方向与能力地图时 | 覆盖面广，但不是第一个项目的直接操作材料。 |
|
||||
| [[02-Intro-Cognitive-Framework-Draft]] | Why Guide 的概念设计底稿 | 想研究内容设计或自行扩展课程时 | 已被正式 Why Guide 吸收，不建议日常阅读。 |
|
||||
| [[03-Roadmap-Refactor-Outline-Draft]] | Practical Roadmap 的结构设计底稿 | 想理解路线如何从审阅意见演化时 | 正式路线图已更完整，草案只保留历史价值。 |
|
||||
|
||||
## 正式学习材料不在本目录
|
||||
|
||||
- 建立心智模型：[[01-Why/01-Why-Guide]]
|
||||
- 填写第一个项目：[[02-Roadmap-Worksheets/01-First-Week-Worksheet]]
|
||||
- 执行完整路线：[[02-Roadmap-Worksheets/02-LLM-Evaluation-Roadmap]]
|
||||
|
||||
返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
aliases:
|
||||
- 入门认知框架
|
||||
type: draft
|
||||
tags:
|
||||
- LLM评测
|
||||
- 草案
|
||||
- 归档
|
||||
status: archive
|
||||
created: 2026-08-21
|
||||
---
|
||||
|
||||
# 零基础入门：必须先弄懂的核心问题
|
||||
|
||||
## 目标重定义
|
||||
|
||||
初学者的第一目标不是“让模型变聪明”，而是能够回答：
|
||||
|
||||
1. 我希望系统完成什么任务？
|
||||
2. 什么输出算成功，什么算失败？
|
||||
3. 当它失败时，失败属于哪一类？
|
||||
4. 修改系统后，我如何证明它真的变好了且没有伤害原有能力？
|
||||
|
||||
## 起步动作与隐藏原因
|
||||
|
||||
| 起步动作 | 表面上在做什么 | 实际上在解决什么认知问题 |
|
||||
|---|---|---|
|
||||
| 选一个小任务 | 缩小项目范围 | 避免把“模型能力”误当成不可验证的抽象概念。 |
|
||||
| 写 10—20 个 case | 准备样本 | 外化你对真实使用场景和边界的理解。 |
|
||||
| 写 rubric | 写评分标准 | 将个人直觉转化为他人可复现的操作定义。 |
|
||||
| 手工盲评 | 比较答案 | 发现你的规则是否足够清晰，以及自己是否有模型偏好。 |
|
||||
| 保存 run | 存结果 | 分开“应测什么”与“本次实际发生什么”，使比较可追溯。 |
|
||||
| 写最小脚本 | 汇总统计 | 从个别感受转向可重复观察。 |
|
||||
| 分类失败 | 记错题 | 让修复有方向，避免所有问题都归咎于模型。 |
|
||||
| 做回归 | 重跑旧案例 | 防止修一个问题又悄悄损坏另一个问题。 |
|
||||
|
||||
## 初学者最常见的误解
|
||||
|
||||
- 误解：先挑最强模型或最热框架才算开始。
|
||||
- 误解：数据越多，评测越可靠。
|
||||
- 误解：有参考答案就不需要 rubric。
|
||||
- 误解：平均分提高就代表系统变好。
|
||||
- 误解：模型输出错了，一定是模型的问题。
|
||||
- 误解：把所有专业工程概念一次学会，才能动手。
|
||||
|
||||
## 解释风格
|
||||
|
||||
每个概念均应按“它是什么 → 为什么初学者先做它 → 不做会发生什么 → 最小行动 → 完成后学到什么”展开；用 RAG 文档问答作为默认示例，并在结尾映射到 Agent 工具调用。
|
||||
+80
@@ -0,0 +1,80 @@
|
||||
---
|
||||
aliases:
|
||||
- 实战路线图重构大纲
|
||||
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
|
||||
Reference in New Issue
Block a user