harrywinner2/synthetic-learner-red-team-harness

# 合成学习者红队测试框架 专为 **Nerdy / Varsity Tutors** 构建 · 联系方式：harrison.glenn@varsitytutors.com AI 导师在演示中看起来很棒，但在真实学生面前却会崩盘——这些学生会瞎猜、拖延、直接要答案、假装理解，并悄无声息地逃避真正的学习任务。本项目构建了一群故意表现得如此糟糕的**合成学习者**，让它们与代数 I（Algebra I）导师进行对抗，找出导师的失败之处，对其进行修复，然后证明这种修复带来了*真正的学习*，而不仅是刷高了的基准分数。 让这个系统值得信赖的是一项在各处反复强调的设计决策：**我们绝不让系统给自己的作业打分。** 每个学习者都有一个导师无法看到的隐藏知识状态，“学习”是通过将其迁移到学习者从未练习过的问题上来衡量的，并且每一个亮眼的指标旁边都会附带一个旨在防止我们自欺欺人的反向指标。 ## 包含内容 一个 FastAPI 后端和一个单页面前端，共同为您提供八个页面： - **概述** — 基线版本与改进版导师对比，四项核心指标，以及可信度判定。 - **学习者实验室** — 八种角色画像、它们的特质雷达图，以及它们*实际掌握的*与*声称掌握的*知识之间的差距。 - **运行竞技场** — 组建一个学习队列并实时运行（使用你的 key 或服务器的 key）。 - **对话记录剧场** — 逐轮观看一个真实的辅导会话，在线标记出回避行为和答案泄露。 - **失败报告** — 角色 × 技能的失败热力图以及“诊断器”提出的修复建议。 - **改进闭环** — v0→v1 的策略差异对比、各子组的前后对比、回归检查以及最终判定。 - **证据与指标** — 每个指标旁边的反向指标，外加留出数据集和评判一致性分析。 - **方法论与局限性** — 产品定位、研究笔记，以及一份诚实的关于此框架遗漏了什么的清单。 ## 实际运行原理 它包含三个活动部件，它们之间的分离正是核心所在。 **1. 合成学习者是受到严格限制的真实 LLM 智能体。** 每个角色画像（盲目自信的猜测者、捷径寻找者、焦虑的半途而废者、死记硬背者等）都是一组行为特质向量。这些特质确定性地决定了学习者在每一轮中采取*什么行动*——尝试、直接要答案、假装理解、转移话题、试图绕开课程——然后 LLM 会根据我们植入的错误认知，以符合其角色的口吻渲染出这一行动。因此，这些对话记录读起来就像真实的学生，但其行为是可复现的，而不是任由模型随心所欲。 **2. 一个隐藏的知识预言机决定了是否有人真正学到了知识。** 每个学习者都拥有针对各项技能的*真实掌握程度*和一系列错误认知，并通过一个贝叶斯知识追踪（Bayesian-Knowledge-Tracing）风格的模型进行更新。关键在于，导师永远看不到这些信息。干巴巴的解释只会略微提升掌握程度；一个提供脚手架、分阶段验证、深挖错误认知的课程能大幅提升它；而直接给出答案则几乎毫无帮助。测试分数是这种潜在状态预测的*预期准确率*——这就是我们如何衡量“不仅限于答案正确”的方法，也是为什么这些数字是可复现的数学计算，而不是智能体的自我报告。 **3. LLM 评判员负责定性工作。** 一个分类器从对话记录文本中标记出回避行为；一个答案泄露检测器标记出导师泄底的情况；一个*不同的*模型充当独立且持怀疑态度的教育者评审，这样我们就可以将（评判间）一致性作为人工审查的替代指标进行报告。改进闭环由一个诊断器收尾，它读取失败聚类并提出有针对性的策略修改建议。 改进闭环的运行流程为：运行基线（v0）→ 对失败进行聚类 → 提出修复方案 → 构建 v1 → 在相同学习者**外加两个留出角色和留出问题**上进行重新测试 → 对比 → 回归检查 → 输出 `REAL_PROGRESS`（实质性进展）、`MIXED`（喜忧参半）或 `LIKELY_GAMING`（疑似钻空子）的判定，并附上促成该判定的证据。 ## 为什么你可以信任该结果（以及它在何处会失效） 本框架的设计初衷就是去*反驳*它自己的好消息： - 如果后测成绩提高了，**迁移能力**是否也随之提升？（如果没有 → 说明是在为应付考试而教）。 - 如果给出答案的情况减少了，**学习效果**是否仍在提升？（如果没有 → 说明导师只是变沉默了）。 - 如果参与训练的学习者取得了进步，**留出集**的学习者是否也有进步？（如果没有 → 说明出现了过拟合）。 - 如果主要评估器对结果感到满意，**独立的评判员**是否同意该结论？ 它仍然会遗漏一些东西，方法论页面对此直言不讳：没有情感或延迟信号，没有长期记忆保持测试，学习者的表现可能*过于*连贯，或者存在与底层模型相同的盲区，且评判员在理论上也存在被钻空子的可能。合成结果只是证据，而非最终证明——诚实且必要的下一步是开展真人受试者试点。 ## 在本地运行 你需要 Python 3.11+ 和一个 OpenAI API key。 ``` cp .env.example .env # then paste your key into OPENAI_API_KEY python -m venv .venv && source .venv/bin/activate pip install -r backend/requirements.txt # (可选) 从真实实验重新生成缓存的 run — 大约需要 3 分钟 python scripts/generate_fixture.py cd backend && uvicorn app.main:app --reload --port 8000 # 打开 http://localhost:8000 ``` 该 key **仅在服务端**读取。它存放在 `.env`（已被 gitignore 忽略）中，且不会出现在磁盘的任何其他位置——绝不会在前端、已提交的测试固件或日志中。在 Run Arena 中，用户可以粘贴他们*自己*的 key；该 key 仅用于那一次请求且绝不存储。在客户审查之后请轮换该 key。 运行测试（无 API 调用——它们确定性地锁定了对可信度至关重要的逻辑）： ``` cd backend && pytest ``` ## 部署 该代码库附带了一个 `Dockerfile` 和 `railway.json`。在 Railway 上：从该代码库创建一个项目，将 `OPENAI_API_KEY`（以及可选的 `OPENAI_MODEL`）添加为服务变量，然后进行部署。该单一服务同时提供 API 和前端服务。SQLite 是默认存储；添加 Postgres 插件后，Railway 的 `DATABASE_URL` 将被自动识别。 ## 目录结构 ``` backend/app/ domain/ personas, skills, the BKT oracle, learner & tutor agents, the simulation engine, classifiers, evaluator, diagnostician, compare llm/ OpenAI provider abstraction (+ a labelled fallback if the API is down) harness.py orchestrates a full baseline→improve→compare experiment api/ FastAPI routes; models.py + store.py persist runs and the interaction log fixtures/ cached_run.json — a recording of a real experiment, shown by default frontend/ index.html — the single-file SPA (extends ui/mockup.html) docs/ expanded PRD, decision log, research notes, failure-mode report, limitations scripts/ fixture generation, secret guard, demo TTS + video assembly ``` 有关简报中提到的交付物，请参阅 `docs/`，有关决策轨迹，请查看 `BUILD_LOG.md`。

标签：AI教育, AI测试, AV绕过, FastAPI, Petitpotam, 合成数据, 后端开发, 红队评估, 请求拦截, 逆向工具