restructure 04-Reference: resource map for evaluation engineering (archive old drafts)
This commit is contained in:
windyboy
@@ -0,0 +1,43 @@
|
||||
---
|
||||
aliases:
|
||||
- 材料清单
|
||||
type: reference
|
||||
tags:
|
||||
- llm-evaluation
|
||||
- archive
|
||||
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 的结构设计底稿 | 想理解路线如何从审阅意见演化时 | 正式路线图已更完整，草案只保留历史价值。 |
|
||||
| [[evaluation-guidebook/00-Overview\|HuggingFace Evaluation Guidebook 中文提炼（子目录）]] | 外部权威评测知识参考（自动基准 / 人工评测 / LLM-as-judge / 排错等） | 设计或执行评测时按主题查阅 | 是外部资料的提炼笔记，作为查阅型参考而非个人学习主线的必经之路。 |
|
||||
| [[01-Curated-External-Resources\|精选外部评测资源]] | 外部精选资源清单（顶级大厂与开源组织的生产级方案、评测基建、硬核课程源码） | 想找生产级方案与源码时按类型查阅 | 是外部链接的筛选清单，作为资源索引而非学习主线的必经之路。 |
|
||||
|
||||
## 外部知识参考（evaluation-guidebook 子目录）
|
||||
|
||||
对 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的中文提炼笔记：
|
||||
|
||||
- [[evaluation-guidebook/00-Overview|总览：这是什么、怎么读]]
|
||||
- [[evaluation-guidebook/01-Automatic-Benchmarks|自动基准评测]]
|
||||
- [[evaluation-guidebook/02-Human-Evaluation|人工评测]]
|
||||
- [[evaluation-guidebook/03-LLM-as-a-Judge|LLM-as-a-Judge（模型作评委）]]
|
||||
- [[evaluation-guidebook/04-Troubleshooting|排错（推理 / LaTeX / 可复现性）]]
|
||||
- [[evaluation-guidebook/05-General-Knowledge|通用知识（推理与评测 / Tokenization）]]
|
||||
- [[evaluation-guidebook/06-Yearly-Dives|年度深度文章（2023–2025）]]
|
||||
- [[evaluation-guidebook/07-Resources|资源链接清单]]
|
||||
|
||||
## 正式学习材料不在本目录
|
||||
|
||||
- 建立心智模型：[[02-Why-Guide]]
|
||||
- 填写第一个项目：[[02-First-Week-Worksheet]]
|
||||
- 执行完整路线：[[01-LLM-Evaluation-Roadmap]]
|
||||
|
||||
返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。
|
||||
+91
@@ -0,0 +1,91 @@
|
||||
---
|
||||
aliases:
|
||||
- 精选外部资源
|
||||
- 硬核评测资源
|
||||
type: reference
|
||||
tags:
|
||||
- llm-evaluation
|
||||
- resources
|
||||
- archive
|
||||
status: active
|
||||
created: 2026-08-21
|
||||
---
|
||||
|
||||
# 精选外部评测资源（真材实料级）
|
||||
|
||||
> 目的：不是收藏大量 AI 资料，而是锁定顶级大厂、顶尖开源组织在生产环境中沉淀出的核心方案、底层评测基建与硬核课程源码。按需查阅，不按顺序通读。
|
||||
|
||||
## 1. 国家级与顶级学术机构的"硬核基建"
|
||||
|
||||
这些是真正用于测试前沿模型（Frontier Models）的底层系统，揭示了顶级团队如何解决代码沙箱、评测污染和环境依赖问题。
|
||||
|
||||
### AISI Engineering Playbook & Inspect AI Framework
|
||||
|
||||
- Playbook：<https://engineering-playbook.aisi.org.uk/>
|
||||
- 框架：<https://github.com/UKGovernmentBEIS/inspect_ai>
|
||||
- 来源：英国人工智能安全研究所（UK AISI）官方开源
|
||||
- 含金量：国家级安全评测机构测试顶尖大模型使用的完整底座。Playbook 阐述高难度评测的 5 层架构（Evaluate, Isolate, Connect, Run, Scale），重点解决如何安全运行大模型生成的不受信代码（沙箱环境）以及大规模评测的工程化调度。
|
||||
|
||||
### lm-evaluation-harness
|
||||
|
||||
- <https://github.com/EleutherAI/lm-evaluation-harness>
|
||||
- 来源：EleutherAI 维护的学术界公认标准评测工具
|
||||
- 含金量：几乎所有开源模型在 Hugging Face 排行榜上的分数都是用它在跑。内置严苛的数据去污染（Decontamination）机制（防止模型训练时偷看评测集答案），是深入理解 MMLU、GSM8K 等学术 Benchmark 评测逻辑的必读源码。
|
||||
|
||||
### OLMES
|
||||
|
||||
- <https://github.com/allenai/olmes>
|
||||
- 来源：艾伦人工智能研究所（Ai2），专为 OLMo/Tülu 模型打造的严格可复现评测标准
|
||||
- 含金量：市面上很多评测换个 Prompt 分数就大变。该仓库提供一套极其标准化的 Prompt 模板、格式化和指标度量方案，实现"苹果与苹果对比（Apples-to-Apples）"。
|
||||
|
||||
## 2. 云厂商生产环境的官方一线实战（含源码）
|
||||
|
||||
### AWS Generative AI Evaluations Workshop
|
||||
|
||||
- <https://github.com/aws-samples/sample-gen-ai-evaluations-workshop>
|
||||
- 来源：AWS 官方团队沉淀的大模型垂直场景评测工作坊
|
||||
- 含金量：目前 GitHub 上针对垂直场景最全、最硬核的实战代码库之一，直接给出以下场景的真实评测代码：
|
||||
- 多模态 RAG 评测（混合文本、视觉与音频检索）
|
||||
- 工具调用（Tool Calling）的 5 种渐进式评测方法（无需真实执行工具）
|
||||
- 自动化推理逻辑验证（利用 SMT 求解器检查输出是否违反合规规则）
|
||||
- 多智能体记忆协同（Shared Context）评测
|
||||
|
||||
### Automated RAG with Ragas & CircleCI
|
||||
|
||||
- 博客：<https://circleci.com/blog/automated-rag-pipeline-evaluation-and-benchmarking-with-ragas/>
|
||||
- 源码：<https://github.com/vibrantlabsai/ragas>
|
||||
- 含金量：给出实际配置文件和 Python 脚本，展示如何利用 databricks-dolly-15k 抽样数据集，在代码提交（CI/CD）时自动触发大模型评测，计算 Faithfulness（忠实度）与 Context Recall（上下文召回率），不达标直接拒绝上线。
|
||||
|
||||
## 3. 名校/大牛的工业级可运行课程 Notebook
|
||||
|
||||
### Evaluating and Debugging Generative AI（DeepLearning.AI）
|
||||
|
||||
- <https://www.deeplearning.ai/courses/evaluating-debugging-generative-ai>
|
||||
- 来源：吴恩达的 DeepLearning.AI 与 Weights & Biases 联合出品
|
||||
- 含金量：通过 Jupyter Notebook 讲解如何把评测变成实验追踪（Experiment Tracking），追踪 Prompt 与 Response 的演变，捕获大模型在复杂多轮交互中的微小表现差异，并用 W&B 平台可视化评测结果。
|
||||
|
||||
### Evidently AI — LLM Evaluations 免费课程
|
||||
|
||||
- 相关讨论：<https://www.reddit.com/r/LangChain/comments/1k9z2kk/free_course_on_llm_evaluation/>
|
||||
- 来源：著名开源评测与可观测性框架 Evidently 团队推出的实战微课程
|
||||
- 含金量：包含 10 多个端到端代码教程，亮点在于对抗性测试（Adversarial Testing / 红队测试）与自定义 LLM 裁判（Custom LLM Judges）设计的 Notebook 示例，非常贴近生产环境防护要求。
|
||||
|
||||
## 4. 解决"环境即数据"的下一代框架
|
||||
|
||||
### BenchFlow
|
||||
|
||||
- <https://github.com/benchflow-ai/benchflow>
|
||||
- 含金量：前沿的"环境实验室"评测工程框架。主张大模型与 Agent 的能力很多时候不取决于静态数据集，而取决于它在环境中的交互能力（"Environments are the new data"）。提供构建强化学习环境、评测和 Post-training 的运行时（Runtime）基础设施，附带 SkillsBench 与 ClawsBench 实际评测环境。
|
||||
- 配套清单：<https://github.com/benchflow-ai/awesome-evals>
|
||||
|
||||
## 上手建议
|
||||
|
||||
1. 先 clone AWS 的 Evaluations Workshop 仓库，里面分门别类的工业级评估代码能让你少走几个月的弯路。
|
||||
2. 如果你的精力在 Agent 安全与深度评测，clone Inspect AI 去研究他们的沙箱隔离评测思路。
|
||||
|
||||
## 与本专区的关系
|
||||
|
||||
- 与 [[evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]] 互补：guidebook 回答"具体怎么做、有哪些坑"（概念与方法），本页回答"去哪找真材实料的生产级方案与源码"（资源与基建）。
|
||||
- 按需查阅：设计某个评测类型（如多模态 RAG、工具调用、Agent 安全）时回到对应小节。
|
||||
|
||||
返回 [[01_Projects/Personal-Tech/LLM_Evaluation/README|学习专区首页]]。
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
aliases:
|
||||
- 入门认知框架
|
||||
type: draft
|
||||
tags:
|
||||
- llm-evaluation
|
||||
- draft
|
||||
- archive
|
||||
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-evaluation
|
||||
- draft
|
||||
- archive
|
||||
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