大多数 AI evaluation 需求都太模糊

团队经常先说“RAG evaluation”、“LLM evals”或“AI evaluation consultant”，但还说不清到底要测哪个失败。模型可能幻觉、引用错 source、选错工具、漏掉图关系，或者把用户路由到错误工作流。这些失败需要不同证据。

模糊的 eval 项目很容易变成一周 dashboard，但没人真的信。一个有用的第一步诊断应该从运营问题开始：哪些决策错了代价高、已经有哪些日志、哪些标签可信，以及谁可以批准 prompt、retrieval、tool 或 model routing 变更。

把 eval 打包成工作流

务实形状是一个小 Flev 工作流：收集代表性 query 或 trace，定义 oracle label，对比 baseline 和 candidate 行为，把 citation 和 tool call 贴在每个 case 上，并返回一份短报告，区分已确认失败和证据缺口。

如果团队已经有具体 eval 路径，也可以用同一个 Flev DevOps intake 来确认固定范围诊断：把一条 RAG、agent-routing、retrieval 或 tool-selection 工作流发到 Flev intake。只有 scope 匹配后才请求付款；第一封消息不应包含私密 credentials，可以使用脱敏日志或公开 repo 证据。

Evaluation 流程

买方能购买的 eval，会把测试集、标签、trace 和审批决定连在一起。

flowchart TB
  Question[业务失败问题] --> Cases[代表性 query 或 trace]
  Cases --> Labels[Oracle label 和 expected source]
  Cases --> Baseline[当前 RAG 或 Agent 行为]
  Baseline --> Metrics[Precision、recall、tool choice、latency]
  Labels --> Metrics
  Metrics --> Evidence[可复盘证据表]
  Evidence --> Boundary[prompt、retrieval、model 或 tool 变更审批边界]
  Boundary --> Report[诊断报告和下一条工作流]

求助前先发送什么

发送 10 到 30 个代表性问题、expected source id 或可接受答案、可用的 sample trace、当前 retrieval 或 routing stack、真正伤害业务的失败，以及会改变决策的 metric。好的 starter diagnostic 包括 source precision、source recall、answer faithfulness、tool-selection accuracy、graph retrieval coverage，以及每次运行的 latency 或 cost。如果当前证据只是 GitHub issue，先把它标记为 technical need，而不是 paid buyer，直到有人确认预算或 owner。

商业 lesson 很简单：先卖最小、可复盘的 eval 工作流。不要在买方还没看清哪些失败真实、哪些数据缺失之前，就卖一个巨大的 AI quality platform。