AI Evaluation / 个人研究项目
把“看起来能用”拆成可复核的证据链。
这不是模型排行榜，而是一套公开、可审计的垂直场景验收 pilot：业务任务 → 样本 → 维度 → 基线 → 证据。
问题
企业怎么知道，AI 真的能完成这个任务？
公开 benchmark 很难回答真实业务问题。我从金融、陪伴、社区三个垂直场景出发，先把“能不能用”拆成可观察的失败模式，再设计样本、裁判协议和可复现基线。
方法：任务 → 样本 → 维度 → 基线
四个层次把主观感受变成可复现结果。
01 业务任务
每个场景先写公开、版本化的 system policy，而不是直接测裸模型。金融是“投资者支持助手”，陪伴是“AI 陪伴与日常支持助手”，社区是“内容 moderation 系统”。
02 样本与维度
每域 14 条公开 prompt：7 个维度 × 2 条。维度来自公开法规、行业实践与模型边界，例如陪伴的 AI 身份、隐私、反操纵依赖、危机分流等。
03 基线与复现
所有对象统一 temperature=0，生成 responses.jsonl 后独立评分。v0.3 使用 Qwen3.8-Max 主裁判，3 条未决由 Claude Opus 4.6 补判，逐条 provenance 保留。
04 验收证据
失败率 + Wilson 区间 + 未决数量 + 失败模式分析。v0.3 共 294/294 有效评分单元，0 个未决；一致率 97.6%，Cohen's κ=0.876。
v0.3 结果摘要
中国模型扩展：126 条新增回复，294 个评分单元全部有效。
v0.3 新增 GLM 5.2、Kimi K2.5、MiniMax M2.5 三个对象（阿里云百炼），与 v0.2 合并后共 7 个对象 × 3 域 × 14 条。结果用于区分弱档与强档，但样本量仍小，不宜做精细排序。
失败模式示例（来自报告原文）：
- Kimi K2.5 陪伴域：未明确确认用户撤回长期边界；即时自伤风险中危机资源建议不足。
- MiniMax M2.5 陪伴域：记忆纠错场景中否认先前错误，未撤回推断或询问更正/删除。
- 金融域强 API 对象全部 0/14，出现明显天花板，说明题集在该域区分度不足，需扩展费用/流动性/工具调用等场景。
v0.4 Vertical Lift（暂定）
测量“垂类适配 + 产品编排”能否相对通用基线提升。
v0.4 陪伴域已完成 12 条 public dev 的 causal 对比（Qwen2-7B-Instruct vs SoulChat2.0-Qwen2-7B），但所有 lift 的 bootstrap CI 均跨 0，不能表述为“垂类显著更强”。金融/社区 public 12 尚未运行，hidden 18 未运行，人工专家评审也未完成。
Case study
从“做了几套题”到一份完整的评测工程案例。
问题
企业怎么知道，AI 真的能完成这个任务？更难的是：当垂类适配和产品编排叠加在同一个模型上时，增益到底来自哪一层？
方法
三域公开题集（金融 / 陪伴 / 社区，每域 12 条）；同基座受控矩阵 A–F（minimal → policy → tool → orchestration → full stack）加观察臂；盲评 LLM judge + 配对 bootstrap CI + freeze manifest。
关键发现
陪伴域 96/96 全部 CI 跨 0；金融域 72/72 未检测到可分离 lift（≠“没有 lift”）；社区域仅 policy→质量 CI [0.08, 0.67] 不跨 0（n=12 探索性）。测量对象被显式声明：社区测的是 moderation system，不是聊天模型。
限制
n=12 public dev；hidden formal set 三域均未运行；人标校准未完成；金融 Fg 观察臂因基础设施失败按授权停止并留 provenance。所有结论停在 LLM-judge-only，不外推为产品排名。
工程资产
从 canonical anchors 发展到 boundary、adversarial、composite、multi-turn；三域公开题集、真实运行、盲评、bootstrap、freeze manifest、审计链与复现脚本。
冻结状态
main 已打 tag v0.4-public-dev；本阶段只做展示层收尾。后续只接受明确触发的迭代：领域协作者、人标校准、真实业务分布，或更合适的官方垂类对象。
公开仓库
所有提示、policy、回复、裁判结果与复核脚本已公开。
仓库包含可复核脚本、SHA256SUMS、七维 policy、逐条评分与未决处理记录。任何人都可以离线重新生成三域比较结果，无需 API key。