muteval 变异测试实战：LLM Eval 覆盖率、RAG 与 Agent 回归测试教程

讲解 muteval 如何为 LLM Eval 注入 Prompt、RAG、Tool 与 Model 变异，通过 killed、survived 和 mutation score 找出评测盲区，并完成 Python、Promptfoo 与 CI 实战。

摘要： 本文讲解开源工具 muteval 如何把传统“变异测试”引入 LLM Eval：它会有控制地削弱系统提示词、丢弃或污染 RAG 上下文、破坏 Agent 工具输出，甚至更换模型，然后重新运行现有评测，检查评测套件能否发现这些故意注入的回归。最重要的结论是：Eval 全绿不代表 Eval 有效；muteval 的 mutation score、survivor 列表与严重级别可以帮助团队发现“系统已经变差，但评测仍然放行”的盲区。它适合已经拥有 Prompt、RAG 或 Agent 自动评测的开发者与企业团队，不适合用来替代业务验收、人工标注或模型安全红队。本文提供从安装、离线演示、Python 配置、Promptfoo 接入到 GitHub Actions CI Gate 的完整实战。

核心结论

muteval 值得加入 LLM 应用的评测验证层，因为它测试的不是“模型表现好不好”，而是“当系统故意变差时，你的 Eval 能不能发现”。对于已经把 Eval 作为上线闸门的团队，这一问题甚至比新增几个测试样例更关键：一个无法识别明显退化的绿色测试套件会制造错误安全感。

适用对象： 已建立 Prompt、RAG、客服机器人、内容生成或 Agent Eval 的开发者、LLMOps 团队和质量负责人。
核心机制： 先验证 baseline 为绿色，再创建 mutants；Eval 发现退化即 killed，未发现即 survived，mutation score 为 killed / evaluated。
当前状态： 截至 2026 年 8 月 22 日，PyPI/piwheels 可核验版本为 0.3.1；官方仓库也明确称其为 early、open project，应按早期工具管理版本风险。
成本判断： 核心包是纯 Python、无必需依赖；真实运行成本主要来自被测模型和 LLM Judge 调用，可用缓存、并发与 --max-calls 控制。
实施建议： 先用离线示例理解结果，再对单个高价值 Prompt 试点；不要第一天就用 75% 等阈值阻塞所有 PR，应先消化 survivor、等价变异和 Judge 波动。

背景与主要变化

传统 LLM Eval 的典型工作方式是：准备输入与期望、调用系统、运行规则检查或 LLM Judge、得到通过率。问题在于，通过率只说明“当前样例在当前系统上通过”，并不能证明这些检查能够识别真实回归。例如客服 RAG Prompt 中有一句“若上下文没有答案，必须说不知道”，Eval 只验证回答是否包含引用；当这条拒答规则被删除后，模型依旧可能生成带引用的答案，于是 Eval 继续绿色，但系统的幻觉边界已经明显变差。

muteval 借用了软件工程中的 mutation testing 思路。传统工具会把 > 改成 >=、把条件取反或删除代码，再检查单元测试是否失败。muteval 则把“被测系统”定义为 Prompt、Context、Tools 与 Model 组成的 LLM 系统，通过 weaken_modals、flip_negation、drop_context_doc、corrupt_tool_output、downgrade_model 等算子制造可控退化。

这意味着测试对象发生了转移：普通 Eval 评价 LLM 应用，muteval 评价 Eval 本身。官方 README 将其类比为“mutmut / Stryker, but for evals”，但它不等同于代码层 mutation testing，也不等同于输入红队。Promptfoo red team 或 Giskard 常通过恶意输入、错别字、扰动来观察系统鲁棒性；muteval 主要改变系统内部的 Prompt、检索上下文、工具输出或模型，并观察原有 Eval 是否会失败。

本文讨论的是 AshwinUgale/muteval。另有一个名为 MutEval 的 Code LLM 鲁棒性研究项目，使用自然语言与程序语言 Prompt 变异、HumanEval、pass@k 和 CodeBERTScore；两者名称接近但目标、代码库和使用方法不同。

核心功能拆解

muteval 的执行链可分为 Baseline、Mutate、Grade、Score 与 Triage 五步。

阶段	muteval 做什么	正常结果	异常处理
Baseline	用原始系统运行现有 Eval	原始套件通过	baseline 红色则拒绝计算分数
Mutate	对 Prompt、Context、Tool、Model 注入退化	产生多个 mutants	无有效变化的 mutant 不应伪装成缺口
Grade	对每个 mutant 重跑 Eval	killed 或 survived	运行错误超过预算时标记 partial errors
Score	计算 killed / evaluated	mutation score 与 95% 置信区间	不应只看单个百分比
Triage	按严重程度检查 survivors	添加或改进 Eval	等价变异、噪声和业务无关项需人工判断

Killed、Survived 与 Mutation Score

如果删除关键指令后，groundedness Eval 失败，这个 mutant 被 killed，说明 Eval 能识别该回归。如果系统输出已经改变，但所有 Eval 仍通过，它就是 survived，代表候选覆盖缺口。Mutation score 的基本形式为：

mutation_score = killed_mutants / evaluated_mutants × 100%

分数越高通常说明 Eval 对所选变异更敏感，但不能脱离算子集合、样例数量、严重等级和置信区间比较。100% 可能只是只生成了很少、很容易被发现的 mutants；60% 也可能已经覆盖所有高风险行为，只剩低价值或等价变异。

21 类变异算子

官方当前 README 列出 21 个算子，覆盖四个层面：

Prompt： 弱化 must/only 等模态词、翻转否定、删除指令行、交换相邻指令、改写指令、删除句子、截断 Prompt、移除 few-shot 示例和强调。
RAG Context： 删除、清空、污染、交换、打乱、重复或截断检索文档。
Model： downgrade_model，用于检验 Eval 是否能发现模型能力下降。
Agent Tools： 删除、污染、交换或拒绝工具输出，检验 Agent 在工具失败时的 Eval 覆盖。

muteval 对被测系统注入退化，再重跑现有 Eval，以 killed、survived 和 mutation score 衡量评测敏感度。

Fail-closed 与稳定性处理

muteval 强调 fail-closed：原始 baseline 失败时不计算 mutation score；部分 mutant 错误超过预算时，不使用缩小后的分母给出虚高分；对非确定性套件，可通过多次运行和严格多数判定，并报告 Wilson 置信区间与 flaky mutant。它也区分“输出确实发生变化但 Eval 没发现”和“变异没有产生可观察差异”，避免把所有未失败项都简单视为覆盖漏洞。

想补充 LLM Judge、Agent Eval 和回归测试基础，可使用 AI Stack Nav 的 LLM Judge 与 Agent Eval 站内搜索。

适用人群与使用场景

muteval 最适合已经存在可执行 Eval 的系统，而不是评测从零开始的项目。

RAG 知识库

RAG 团队常验证答案是否引用文档，却没有验证答案是否真正由上下文支持、缺少资料时是否拒答。drop_context_doc、clear_context 与 corrupt_context_doc 可以模拟检索退化；如果答案质量明显下降但 Eval 仍通过，就需要增加 groundedness、关键事实、拒答和引用一致性检查。

客服与业务流程 Agent

客服 Agent 可能依赖订单查询、退款政策、库存工具。通过 drop_tool_output 或 deny_tool_output 可以验证：工具失败时，Eval 是否要求 Agent 明确说明失败、避免编造结果、停止高风险动作并请求人工介入。对于退款、付款、删除账户等动作，muteval 只能验证 Eval 是否识别问题，不能替代真实权限隔离和人工审批。

内容生成工作流

AI Stack Nav 一类内容自动化系统可以测试：删除“不得编造价格”、弱化“必须引用官方来源”、移除“WordPress 默认 draft”后，Eval 是否会失败。如果 mutation survivor 表明评测只检查字数和 Markdown 格式，却不检查事实来源与发布状态，就说明上线闸门仍存在实质性盲区。

不适合直接使用的情况

没有可运行 baseline，只靠人工阅读输出；
系统输出高度随机，尚未确定重复运行与多数判定策略；
每次模型或 Judge 调用成本极高，又没有预算上限和缓存；
试图用 mutation score 直接替代用户满意度、业务 KPI、安全红队或人工标注；
希望通过一个统一阈值比较完全不同的应用和算子集合。

安装、配置与离线演示

官方当前安装方式为 pip install muteval，核心为纯 Python、没有必需依赖。Promptfoo、DeepEval 与 RAGAS 适配器使用可选 extras；不要为了一个简单规则 Eval 一次性安装所有大型依赖树。

创建隔离环境。 使用 Python 虚拟环境，避免与生产项目依赖冲突。
安装并记录版本。 安装 muteval 后运行 muteval --help、muteval list，并在 CI 锁定经过验证的版本。
优先运行无 Key 离线示例。 官方离线示例位于仓库 checkout 的 examples/，不会随 wheel 一起安装。
初始化配置。 使用 muteval init --template rag 或 --template basic 生成可运行骨架。
先执行 check。 muteval check 用来检查 pipeline、Eval 与 baseline；baseline 未绿时不要进入正式 mutation run。
小范围运行。 先限制 Prompt 范围、mutant 数与调用预算，查看 survivor 是否有业务意义。
修补 Eval 后复测。 对高严重度 survivor 添加检查，再验证该 mutant 被 killed 且 baseline 仍保持绿色。

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install muteval

muteval list
muteval init --template rag
muteval check --config muteval_config.py
muteval run --config muteval_config.py --max-calls 100

Windows PowerShell 激活环境的命令通常为：

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
pip install muteval
muteval init --template basic

无 API Key 离线演示需要克隆仓库，因为 README 明确说明 examples/ 不包含在 wheel 中：

git clone https://github.com/AshwinUgale/muteval.git
cd muteval
muteval run --config examples/promptfoo_offline/muteval_config.py --no-color

官方把快速上手描述为 60 秒，但真实项目接入并非开箱即用；README 也明确指出真实套件通常需要约一小时集成，并建议从 adoption checklist 与绿色 baseline 开始。实际耗时取决于系统调用接口、用例格式、Judge 和现有 Eval 的可复用程度。

Python 配置实战：检测 RAG 拒答规则盲区

假设一个知识库助手的系统规则是：只能根据 context 回答；上下文没有答案时必须说不知道。已有 Eval 只检查订单号和引用，容易漏掉拒答规则。

import os
from muteval import MutEvalConfig, checks

SYSTEM_PROMPT = """
You are a support assistant.
Answer using ONLY the provided context.
If the answer is not in the context, say you don't know.
Never invent an order status.
""".strip()


def run_support_bot(prompt: str, case: dict) -> str:
    """调用你的真实应用；示例不写入任何真实密钥。"""
    from myapp.support import answer

    return answer(
        system_prompt=prompt,
        question=case["input"],
        context=case.get("context", ""),
    )


config = MutEvalConfig(
    prompt=SYSTEM_PROMPT,
    cases=[
        {
            "input": "订单 A123 当前状态是什么？",
            "order_id": "A123",
            "context": "订单 A123 已发货，承运商为 Example Express。",
        },
        {
            "input": "订单 B999 什么时候到？",
            "order_id": "B999",
            "context": "",
        },
    ],
    run=run_support_bot,
    evals=[
        checks.contains_case("order_id"),
        checks.grounded("context"),
    ],
)

执行：

export OPENAI_API_KEY="YOUR_API_KEY"
muteval check --config muteval_config.py
muteval run --config muteval_config.py \
  --cache .muteval-cache.sqlite \
  --concurrency 4 \
  --max-calls 200

运行后重点查看 delete_sentences、weaken_modals、clear_context 一类 survivor。如果删除“不知道就拒答”后 Eval 仍通过，应新增明确的 abstention 检查，或用标注好的“应回答/应拒答”用例验证。不要为了提高分数而添加只识别 muteval 字符串差异的脆弱断言；新增 Eval 应捕获真实业务回归。

Promptfoo、Endpoint 与缓存接入

已有 Promptfoo 套件时，可以直接复用 Prompt、测试与 assertions：

pip install "muteval[promptfoo]"
muteval run --promptfoo promptfooconfig.yaml --dry-run
muteval run --promptfoo promptfooconfig.yaml --fail-under 70

如果系统是 Python 函数，使用 --target package.module:function；如果是已部署 HTTP 服务，可用 --endpoint，工具会 POST {prompt, case} JSON 并读取文本输出：

muteval run \
  --endpoint https://YOUR_DOMAIN/api/answer \
  --prompt-file system.txt \
  --cases cases.jsonl \
  --judge "the answer is grounded in the provided context" \
  --max-calls 300

API Key 应通过环境变量或 CI Secret 提供，不得提交到配置、日志或案例文件。生产 Endpoint 还需要认证、速率限制、测试租户和幂等设计，避免 mutation run 触发真实邮件、退款、数据删除或外部发布。

缓存可以显著减少相同配置的重复调用：

muteval run \
  --config muteval_config.py \
  --cache .muteval-cache.sqlite \
  --concurrency 8 \
  --max-calls 500

官方说明，相同运行可复用模型与 Eval 结果；当 runs_per_mutant > 1 用于处理噪声套件时会跳过这一优化。缓存文件也可能包含 Prompt、输出与评测结果，应视为敏感测试资产并设置保留期。

CI Gate 实战

将 mutation testing 加入 CI 时，流程应是“基线通过 → 生成变异 → 执行 Eval → 预算与错误率检查 → 严重度/分数闸门 → 报告”，并避免让不稳定的 LLM Judge 随机阻塞主分支。

name: muteval

on:
  pull_request:

jobs:
  mutation-eval:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install
        run: pip install "muteval==0.3.1"

      - name: Validate baseline
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: muteval check --config muteval_config.py

      - name: Run mutation eval
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          muteval run --config muteval_config.py \
            --fail-under 70 \
            --fail-on-severity high \
            --max-calls 300 \
            --junit junit.xml \
            --badge badge.json

从 baseline 到 survivor 修补和复测，构成可控制成本、错误率与严重度的 LLM Eval 改进闭环。

建议分三阶段启用：第一阶段只生成报告，不阻塞 PR；第二阶段仅对新增高严重度 survivor 阻塞；第三阶段在分数和波动稳定后启用 --fail-under。对 LLM Judge 应先运行 muteval probe 检查重复运行可靠性与区分能力，否则 CI 失败可能来自 Judge 摇摆，而不是系统回归。

相关 CI、LLM Judge 与自动评测资料可继续查看 AI Stack Nav 的 AI Agent 自动评测与 CI Gate 站内搜索。

如何分析结果并修补 Eval

一次运行结束后，muteval 会把最近结果保存到 .muteval/last_run.json，并提供 results、show 与 HTML 报告命令：

muteval results
muteval show 1
muteval report --html coverage.html

处理 survivor 时使用以下顺序：

确认变异是否有效。 对比 baseline 与 mutant，检查系统行为是否真的被削弱。
判断业务严重度。 删除品牌语气和删除安全拒答不能同等处理。
检查现有 Eval 为什么未失败。 是用例缺失、断言错误、阈值过松、Judge 不稳定，还是观测字段不完整？
添加最小有效检查。 新 Eval 应能捕获该行为类别，而不只匹配本次具体字符串。
同时回归 baseline。 修补后必须保证正常系统仍通过，避免过度约束。
复跑对应 mutant 与全套。 局部 killed 不代表没有引入新的 false positive。
记录接受的 survivor。 对等价变异或低价值行为说明原因，避免团队反复分诊。

例如 drop_tool_output survived 时，不应简单增加“输出包含 error”字符串检查，而应验证 Agent 是否：停止依赖缺失结果；不编造工具返回；向用户透明说明失败；对高风险动作请求重试或人工审批。这样的 Eval 才能迁移到未来不同的工具错误。

对比与选型建议

工具/方法	主要改变对象	主要回答的问题	与 muteval 的关系
普通 LLM Eval	不主动改变系统	当前系统表现是否达标	muteval 重用这些 Eval 来测试其敏感度
Promptfoo Red Team	恶意或对抗输入	系统是否抵抗攻击	关注输入安全，不直接评价 Eval 覆盖
DeepEval / RAGAS	指标与评测框架	输出质量、忠实度、相关性如何	可通过适配器成为 muteval 的 grader
传统 mutmut / Stryker	源代码	单元测试能否发现代码缺陷	思想来源相同，被测对象不同
muteval	Prompt、Context、Tools、Model	Eval 是否能发现系统退化	位于 Eval 之上的质量验证层

如果团队还没有 Eval，先建立少量关键行为用例，不要从 mutation score 开始。如果已有 Promptfoo、DeepEval 或 RAGAS，优先复用现有资产，再用 muteval 寻找缺口。如果目标是测试 Code LLM 对 Prompt 同义改写的稳定性，则应研究 MutEval 论文项目或专门鲁棒性基准，而不是把两个工具混为一谈。

风险、限制与注意事项

第一，mutation score 不是通用质量分。不同算子、范围、案例与严重度下的 80% 不可直接比较。报告必须同时保留 evaluated 数量、survivor 类型、置信区间、错误率与高风险缺口。

第二，存在等价或不可观察变异。某条 Prompt 被删除，但模型在当前样例上仍做出相同回答，并不一定表示 Eval 漏洞；可能是模型先验、样例不足或变异没有触达行为。muteval 的 output diff 与 observationally unchanged 分类能提供帮助，最终仍需人工判断。

第三，LLM Judge 自身会波动和偏置。Judge 可能因为位置、冗长、自偏好或阈值问题误杀/漏杀。应使用固定模型版本、低随机性、多次运行、校准样例、人工标签与 muteval probe，不要把单次 Judge 结果当作绝对真值。

第四，真实 Endpoint 有副作用。Agent mutation 可能触发发邮件、发布 WordPress、退款、删除数据、修改权限或调用生产数据库。测试环境应使用 sandbox、mock 工具、测试租户、最小权限和人工审批，禁止直接对生产写接口批量变异运行。

第五，成本与限流会扭曲结果。变异数量乘以用例数和重复次数，可能产生大量模型与 Judge 调用。必须使用 --max-calls、缓存、合理并发、Timeout、Retry 上限与费用监控；429、超时和供应商故障不能静默当作 killed。

第六，项目仍较早期。当前公开版本迭代快，CLI 参数、算子行为和报告结构可能变化。CI 应锁定版本，升级前先跑离线与预发布分支，并保留回退方案。

事实依据与来源

官方已确认： muteval 的定位是“对 LLM Eval 做 mutation testing”，通过故意降低被测系统并检查现有 Eval 是否识别回归。
官方已确认： 当前 README 列出 21 个 Prompt、Context、Model 与 Tool 变异算子；流程包括 baseline、mutate、grade 与 score。
官方已确认： baseline 失败时拒绝评分；支持部分错误预算、重复运行多数判定、Wilson 置信区间、flaky 标记和输出差异分析。
官方已确认： 支持 Promptfoo、DeepEval、RAGAS、Python callable、HTTP endpoint 与 OpenAI-compatible endpoint；可输出 JUnit、Badge 和 HTML 报告。
版本事实： piwheels/PyPI 镜像在核验日列出的最新版本为 0.3.1，发布日期为 2026 年 7 月 22 日。
官方实验： 仓库声称其受控 CI 实验在四个领域随 Eval 覆盖增加呈现 mutation score 单调上升；这是项目自身验证，不是独立第三方基准。
编辑判断： 分阶段启用 CI Gate、优先修复高严重度 survivor、对副作用工具使用 sandbox 属于本文实施建议。
待项目验证： 不同真实企业 Eval、中文 Prompt、复杂多 Agent trace 与大规模用例下的成本、稳定性和最佳阈值仍需实测。

FAQ

muteval 是什么？

muteval 是面向 LLM Eval 套件的开源变异测试工具。它主动削弱 Prompt、RAG Context、Agent 工具输出或模型，然后重新运行现有 Eval，判断这些 Eval 是否能发现回归。

muteval 与 MutEval 论文项目是同一个工具吗？

不是。本文的 muteval 来自 AshwinUgale/muteval，重点是测试 LLM Eval 的覆盖能力；另一个 MutEval 项目重点研究 Code LLM 在自然语言和代码 Prompt 变异下的鲁棒性。安装和引用前应核对仓库所有者。

muteval 是否免费？

代码采用 Apache-2.0 许可证，核心包无必需依赖；但调用被测模型和 LLM Judge 可能产生 API 费用。实际成本与 mutants、cases、重复运行数和 Judge 数量成倍相关，应设置 --max-calls 并查看供应商定价。

当前版本是多少？

截至 2026 年 8 月 22 日，piwheels 可核验的最新发布版本是 0.3.1。项目仍明确属于 early、open project，生产 CI 应锁定版本并在升级前回归验证。

Mutation score 越高越好吗？

在相同算子、案例、运行设置和有效 mutant 集合下，较高分通常表示 Eval 更能发现注入退化；但不能跨项目直接比较。必须同时分析严重度、survivor、置信区间、错误率与等价变异。

什么是 survived mutant？

它表示被测系统被变异后，输出或行为出现了候选退化，但现有 Eval 没有失败。survivor 是需要人工分诊的覆盖缺口候选，不应自动视为真实 Bug。

没有 API Key 可以运行吗？

可以先运行仓库中的离线 mock 示例，也可以测试不需要外部模型的自定义函数与规则检查。真实 OpenAI-compatible 模型或 LLM Judge 调用需要相应凭据，Key 应存入环境变量或 CI Secret。

muteval 能替代 Promptfoo、DeepEval 或 RAGAS 吗？

通常不能，也没有必要。Promptfoo、DeepEval 和 RAGAS 负责执行或定义 Eval，muteval 可复用它们，再检查这些 Eval 是否能识别系统退化。二者是上下层关系。

为什么 baseline 失败时不计算分数？

因为原始系统本就无法通过 Eval 时，mutant 失败不能证明 Eval 捕获了新增回归。拒绝评分能避免得到误导性的高 mutation score，是 fail-closed 设计的重要部分。

是否应该立即把 `--fail-under 75` 加到主分支？

不建议未经基线观察就直接阻塞。先以报告模式运行，处理无效变异、Judge 波动和高严重度 survivor；当分数稳定且团队理解失败原因后，再逐步启用严重度和分数闸门。

参考来源

会员充值教程

会员充值与订阅排查资料

适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。

AI 订阅充值失败排查包 整理常见支付失败、地区限制、订单未到账和账号异常处理步骤。 查看资料包 会员权益对比表 对比不同 AI 工具会员权益、价格、适用人群和购买建议。 查看资料包

AI Stack Nav

muteval 变异测试实战：LLM Eval 覆盖率、RAG 与 Agent 回归测试教程

核心结论

背景与主要变化

核心功能拆解

Killed、Survived 与 Mutation Score

21 类变异算子

Fail-closed 与稳定性处理

适用人群与使用场景

RAG 知识库

客服与业务流程 Agent

内容生成工作流

不适合直接使用的情况

安装、配置与离线演示

Python 配置实战：检测 RAG 拒答规则盲区

Promptfoo、Endpoint 与缓存接入

CI Gate 实战

如何分析结果并修补 Eval

对比与选型建议

风险、限制与注意事项

事实依据与来源

FAQ

muteval 是什么？

muteval 与 MutEval 论文项目是同一个工具吗？

muteval 是否免费？

当前版本是多少？

Mutation score 越高越好吗？

什么是 survived mutant？

没有 API Key 可以运行吗？

muteval 能替代 Promptfoo、DeepEval 或 RAGAS 吗？

为什么 baseline 失败时不计算分数？

是否应该立即把 `--fail-under 75` 加到主分支？

参考来源

会员充值与订阅排查资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复取消回复

muteval 变异测试实战：LLM Eval 覆盖率、RAG 与 Agent 回归测试教程

核心结论

背景与主要变化

核心功能拆解

Killed、Survived 与 Mutation Score

21 类变异算子

Fail-closed 与稳定性处理

适用人群与使用场景

RAG 知识库

客服与业务流程 Agent

内容生成工作流

不适合直接使用的情况

安装、配置与离线演示

Python 配置实战：检测 RAG 拒答规则盲区

Promptfoo、Endpoint 与缓存接入

CI Gate 实战

如何分析结果并修补 Eval

对比与选型建议

风险、限制与注意事项

事实依据与来源

FAQ

muteval 是什么？

muteval 与 MutEval 论文项目是同一个工具吗？

muteval 是否免费？

当前版本是多少？

Mutation score 越高越好吗？

什么是 survived mutant？

没有 API Key 可以运行吗？

muteval 能替代 Promptfoo、DeepEval 或 RAGAS 吗？

为什么 baseline 失败时不计算分数？

是否应该立即把 --fail-under 75 加到主分支？

参考来源

会员充值与订阅排查资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复 取消回复

是否应该立即把 `--fail-under 75` 加到主分支？

发表回复取消回复