本文迁移自 mindcarver/91ai · 原始位置 docs/evaluation/README.md · 由 @阿新聊ai 整理。

AI / 大模型 / Agent 评测专题

TL;DR： AI 评测不能只看模型榜单。真正有用的评测要同时回答五个问题：模型会不会、系统稳不稳、工具调得准不准、结果能不能被证据支撑、上线后是否安全可控。这个专题把 AI、大模型、RAG、Agent、AI Coding 和安全红队评测放在一张地图里，帮助你判断该测什么、用什么框架、怎么把评测做成持续回归。

整理日期：2026-06-30。模型榜单和工具能力变化很快，具体分数不要长期复用，评测方法和维度更值得沉淀。

可复现性状态： 当前两套 91ai 自建评测均为 R1（只有报告，运行产物尚未发布），不能仅从本仓库独立复跑分数。阅读或引用前请先看评测可复现性状态。

先给结论：可以做哪些评测内容

一个好的评测专题不应该只收集榜单，而要沉淀三类资产：

1. 评测地图：不同类型 AI 系统应该测哪些维度。
2. 评测框架索引：哪些开源项目、论文和工具能复用。
3. 91ai 自建协议：逐步沉淀面向真实工具、真实项目、真实任务的可复现评测模板。

一、模型能力评测

模型能力评测适合回答“这个模型作为底座强不强”。它不等于应用质量评测，但能帮助做模型初筛。

使用建议：

• 用公开 benchmark 做模型初筛，不要把公开榜单当成业务结论。
• 对业务场景建私有 eval，因为公开题很难覆盖你的真实输入、约束和风险。
• 分开看能力、成本、延迟和稳定性。能力强但太慢、太贵、格式不稳，应用里仍可能不可用。

二、LLM 应用评测

LLM 应用评测关注的是完整系统，不是模型裸输出。它适合回答“这个 AI 功能能不能上线、改版后有没有退化”。

关键原则：

• 评测输入要来自真实用户、历史失败、边界样本和高风险样本。
• 报告要按标签拆分，不要只看平均分。
• LLM-as-judge 必须用人工标注样本校准，否则它只是另一个不稳定模型。

三、RAG 评测

RAG 评测要拆成“检索是否正确”和“回答是否基于检索”两段。很多 RAG 问题不是模型差，而是文档解析、切分、检索、rerank 或权限过滤出了问题。

可参考：

• Ragas：覆盖 RAG、Agent、工具调用、自然语言比较等指标，适合快速建立系统化评测。
• TruLens：强调 tracing + eval，适合观察 retrieved context、tool calls、plans 等执行流。
• Phoenix：适合把 traces、evals、datasets、experiments 放到一个调试和迭代工作流里。
• 91ai 已有文档：RAG 评估与微调。

91ai 实测专题：四大开源知识库平台 RAG 横评

作者在同一台机器、同一个本地 Ollama 下部署 MaxKB / RAGFlow / FastGPT / Dify，记录了 4 类数据集的运行结果。当前公开内容是作者运行报告，脚本和原始结果尚未进入本仓库，状态为 R1：

• 四大开源知识库平台 RAG 实测横评：主报告，含 4 数据集 × 4 平台召回矩阵、多维评分、纯 API 自动化摩擦，以及一次共享 Ollama 并发请求超时记录。
• MaxKB 技术架构与实现原理：单容器 + PostgreSQL/pgvector 混合检索、split→batch_create 数据流。
• RAGFlow 技术架构与实现原理：DeepDoc（OCR/版式/表格）+ ES/Infinity 多服务架构、task_executor pipeline。
• FastGPT 技术架构与实现原理：Next.js + MongoDB + 三层模型系统（aiproxy/plugin/mongo）、LiteParse 与 pdfjs 的 PDF 解析坑。
• Dify 技术架构与实现原理：Flask + 插件市场 + 新一代 RAG pipeline、base64 密码与 CSRF 鉴权连环坑。

本次运行记录显示：在当时版本、配置和样本下，文本类任务四家均取得较高召回；DocVQA 扫描样本中只有 RAGFlow（DeepDoc OCR）形成有效检索结果；纯 API 自动化摩擦度记录为 MaxKB 最低、Dify 最高。这些结论不能直接外推到其他版本或企业数据。

91ai 实测专题：AI 记忆系统开源项目评测

专题覆盖 13 个 AI 记忆系统项目（Mem0 / Supermemory / Letta / Zep+Graphiti / Cognee / Memvid / LangMem / LlamaIndex / Hindsight / Basic Memory / OpenMemory / Universal Memory / Reference Memory MCP）。其中既有作者 hands-on 结果，也有因安装或服务限制而保留的资料调研；部分运行使用不同 LLM、embedding 或回答协议，当前状态为 R1：

• AI 记忆系统评测专题总览：总索引，含结果快照、协议边界、选型线索与负分排查记录。
• 13 篇项目逐一详解：每篇 1 万+ 字，覆盖技术架构、实现原理、数据流、实测分数与坑。

视角分工：本专题保留作者运行记录与选型线索；同一批项目另有架构解读版讨论“怎么设计、怎么选型、怎么评估”。在可复现产物发布前，具体分数不应作为独立采用依据。

四、Agent 评测

Agent 评测不能只看最终答案。Agent 的核心风险在过程：工具选错、参数错、重复调用、失败不恢复、越权操作、成本失控。

可参考基准：

91ai 自建 Agent 评测应该优先做这些任务：

1. GitHub issue triage：读 issue、分类、找相关文件、给修复建议。
2. 文档 RAG agent：检索资料、引用来源、判断资料不足。
3. 客服工单 agent：多轮澄清、查知识库、生成结构化处理结果。
4. 数据分析 agent：读表、写查询、解释结果、标注不确定性。
5. 自动化 workflow agent：需要工具调用、人工确认、失败恢复。

五、AI Coding 评测

AI Coding 评测是 Agent 评测里最容易做实战验证的一类，因为结果可以用测试、diff、review 和仓库状态检查。

可参考：

• SWE-bench：真实 GitHub issue 级别的软件工程任务。
• BigCodeBench：更偏代码生成能力和真实函数级任务。
• HumanEval：经典函数级代码生成评测，适合作为基础能力参考。
• 91ai 已有文档：Skill 实战评测协议。

六、安全与红队评测

安全评测要覆盖模型、Prompt、RAG、工具权限和运行环境。越接近生产系统，越不能只问“模型会不会拒答”。

可参考：

• HarmBench：自动红队和拒答稳健性的标准化评测框架。
• SafetyBench：大模型安全能力评测。
• Inspect：AI Safety Institute 的评测框架，覆盖 scoring、agents、tools 等组件。
• 91ai 已有文档：Agent 安全与失败模式。

七、生产运行评测

上线后的评测比离线 benchmark 更重要。生产评测不是每天手工问模型，而是把真实流量、trace、人工反馈和失败样本接入回归系统。

最小生产评测闭环：

线上请求
  -> Trace 记录输入、检索、Prompt、模型、工具、输出
  -> 抽样进入人工/模型评分
  -> 失败样本打标签
  -> 回流到离线 eval dataset
  -> 下一次发布前作为回归门禁

必须跟踪：

• 任务成功率；
• 高风险样本通过率；
• 幻觉和引用错误；
• 权限泄露；
• 用户纠错率；
• 人工接管率；
• p50 / p95 延迟；
• 单次任务成本；
• 模型评分和人工评分一致率。

评测工具选型

91ai 后续可以沉淀的专题资产

这个专题建议后续拆成 6 个子专题：

优先级建议：

1. 先做 LLM 应用 Eval 实战，因为它能复用到所有 AI 应用。
2. 再做 RAG 评测实战，这是企业知识库最容易踩坑的地方。
3. 然后做 Agent 评测实战，重点看工具调用轨迹和失败恢复。
4. 最后做 AI Coding 工具横评 和 安全红队模板，需要更强的任务设计和证据留存。

最小自建评测模板

{
  "id": "agent-tool-001",
  "task": "根据客户问题查询知识库并生成工单处理建议",
  "input": "客户说发票金额和合同金额不一致，应该怎么处理？",
  "context": {
    "user_role": "support",
    "tenant_id": "demo"
  },
  "expected": {
    "must_use_tools": ["search_policy"],
    "must_include": ["核对合同金额", "核对发票金额", "升级财务复核"],
    "must_not_include": ["其他客户合同信息"],
    "citation_required": true
  },
  "tags": ["rag", "agent", "permission", "finance"],
  "risk": "high",
  "graders": ["tool_call", "citation", "coverage", "permission", "cost"]
}

最小通过规则：

高风险样本通过率 = 100%
权限泄露 = 0
工具参数错误率 <= 2%
引用错误率 <= 5%
结构化输出通过率 >= 99%
p95 延迟 <= 业务 SLA
平均成本不超过 baseline 20%

和现有 91ai 文档的关系

• Eval 评估体系：讲如何把 AI 质量做成回归测试。
• RAG 评估与微调：专门讲 RAG 评估指标和优化闭环。
• AI Agent 记忆系统专题：包含长期记忆系统的评测方法和项目对比。
• AI 记忆系统评测专题：13 个开源记忆项目实测横评（冒烟 + LongMemEval + 负分校验门），是上面架构专题的实测补充。
• AI / Agent 面试专题：评测也是一线 AI 应用岗和 Agent 岗的高频追问点。

核心判断

评测不是为了证明模型“很强”，而是为了决定系统“能不能交付”。公开 benchmark 适合初筛，自建 eval 才能决定上线。对 91ai 来说，最有价值的方向不是再复制一个榜单，而是沉淀可复现的真实任务评测：有任务、有输入、有日志、有失败样本、有成本、有结论。