用途
Error Analysis 用于帮助用户系统性地识别和归类 LLM 流水线中的失败模式。它通过阅读 trace（完整调用记录）来建立系统失败方式的目录，适用于启动新的评估项目，或在系统发生重大变更后重新分析。
主要能力
该技能覆盖从采集 trace 到决定修复动作的完整流程：
- 采集约 100 条代表性 trace，包含输入、所有中间 LLM 调用、工具使用、检索文档、推理步骤和最终输出。
- 逐条阅读 trace，判断通过或失败，并记录出错之处。
- 将相似失败归组为类别，并给出清晰名称和一句话定义。
- 对全部 trace 按类别打二元标签。
- 计算各类失败率并排序，确定优先修复对象。
- 针对每个失败类别决定处理方式：直接修复、构建评估器或暂不处理。
使用方式
核心流程分为七步：
- 采集 trace：目标约 100 条，具体数量取决于系统复杂度。优先使用真实用户数据；小量时随机抽样，大量时按关键维度（查询类型、用户分群、功能区域）抽样，可用嵌入聚类（K-means）保证多样性。真实数据稀疏时，可使用 generate-synthetic-data 技能生成合成数据并跑完整流水线。
- 阅读 trace 并记录：逐条向用户展示，询问结果好坏（通过/失败）。对失败记录出错之处，聚焦 trace 中第一个出错点，因为错误会级联。写观察而非解释，例如写“SQL 漏掉了预算约束”，而不是“模型可能没理解预算”。提供表格模板记录 Trace ID、Trace、出错内容、通过/失败。
- 将失败归组为类别：在审阅 30-50 条 trace 后开始归组，不必等全部 100 条完成。类别会逐步演化，目标是具体且可操作的名称。区分不同根因的失败应拆分，相同根因的应合并。可在用户审阅 30-50 条后使用 LLM 辅助聚类，但必须由用户复核，因为 LLM 常按表面相似性聚类。目标为 5-10 个互斥、清晰、可操作的类别。
- 为每条 trace 打标签：回到全部 trace，为每个失败类别打通过/失败二元标签，每条 trace 每个类别一列。可使用电子表格、标注应用或脚本。
- 计算失败率：使用代码
failure_rates = labeled_df[failure_columns].sum() / len(labeled_df)和failure_rates.sort_values(ascending=False)，最频繁的失败类别优先处理。 - 决定每个失败的处理方式：按顺序考虑——能否直接修复（提示词未提及需求、工具缺失或配置错误、检索/解析/集成中的工程 bug）；评估器是否值得投入（考虑发生频率、业务影响、是否会真正用于迭代）；对值得构建评估器的失败，客观项优先用基于代码的检查（正则、解析、模式验证），需要判断的才用 write-judge-prompt，安全合规等关键需求即使修复提示词后也可保留评估器作为护栏。
- 迭代：预期 2-3 轮审阅和细化类别，合并重叠类别、拆分过宽类别、澄清定义、重新打标签。
适用场景
- 启动新的 LLM 评估项目。
- 系统发生重大变更后（新功能、提示词重写、模型切换、生产事故）重新分析。
- 需要确定优先修复哪些失败模式时。
限制与注意事项
- 停止标准：当新 trace 不再揭示新失败类型时停止，大致为审阅约 100 条且最后 20 条无新类型，具体取决于系统复杂度。
- 反模式：在读 trace 前头脑风暴失败类别；从预定义类别开始；跳过用户初始审阅；使用通用评分作为类别（如“幻觉分数”“有用性分数”“连贯性分数”）；在修复明显问题前构建评估器；将其视为一次性活动。
- 用户必须亲自审阅前 30-50 条 trace，以将类别建立在领域知识上。
- 构建和维护评估器有实际成本，并非每个剩余失败都需要评估器。
- 关于收费、价格、平台等信息，资料中暂未提供。