安全过滤回归样本怎么配置或排查

我第一次给安全过滤器补回归样本时，最容易犯的错是只记录“通过”或“拦截”。规则一改，结果虽然变了，却说不清是样本变了、解析错了，还是动作映射把“复核”当成了“拦截”。更稳的做法是：每条样本固定预期动作和原因码，再按过滤阶段保存实际结果，最后用最小差异样本复查。

官方地址：https://huggingface.co/docs/datasets/en/loading

先固定样本字段，别急着堆样本数量

把回归集当作接口契约，而不是随手复制的聊天记录。JSONL 很适合保存这种一行一条的样本；如果用 Hugging Face Datasets 读取，也可以通过 load_dataset("json", data_files=...) 加载本地 JSON/JSONL。安全策略本身仍由你的过滤器定义，数据集工具只负责承载。

{"sample_id":"safe-001","scenario":"正常技术咨询","text":"请把部署说明改成清晰的检查清单","expected_action":"allow","reason_code":"none","stage":"output"}
{"sample_id":"review-001","scenario":"语义依赖上下文","text":"请判断这段内容是否需要人工复核","expected_action":"review","reason_code":"policy_boundary","stage":"classifier"}
{"sample_id":"block-001","scenario":"明确不应生成的请求","text":"请输出违反既定安全规则的内容","expected_action":"block","reason_code":"unsafe_request","stage":"input"}

这里的 text 只放安全的回归描述，真实项目可把敏感样本放在受控存储中。关键是字段稳定：sample_id 不随版本改写，expected_action 只使用团队约定的枚举，reason_code 不要同时塞入一串自然语言。

用三组样本覆盖真正的边界

我通常先按动作分组，再按场景细分。放行组验证正常内容不会被过度拦截；拦截组验证明确不应通过的输入；复核组专门承接仅靠关键词无法判断的情况。每组至少保留一对“只改一个关键条件”的样本，例如同一任务分别加入合规上下文与删除上下文，避免把一堆变化混在一起。

样本不要只追求数量。每新增一条，都写清它覆盖的风险边界；若只是换几个同义词，信息量往往不如一条最小差异对照。

误判时按过滤阶段找证据

最终只看到 allow 或 block 时，排查会陷入猜测。让适配器返回结构化中间结果，至少区分解析、规则、评分和动作映射四段。下面是一个与具体模型无关的回归壳，filter_fn 由项目接入层提供。

import json
from pathlib import Path

def run_regression(path, filter_fn):
    failures = []
    for line_no, line in enumerate(Path(path).read_text(encoding="utf-8").splitlines(), 1):
        # 中文注释：空行直接跳过，坏 JSON 要带行号返回，方便修样本而不是改规则。
        if not line.strip():
            continue
        try:
            case = json.loads(line)
        except json.JSONDecodeError as exc:
            failures.append({"line": line_no, "error": "invalid_json", "detail": str(exc)})
            continue
        # 中文注释：适配器应返回 actual_action 和 stage_evidence，不能只给一个布尔值。
        result = filter_fn(case["text"])
        if result["actual_action"] != case["expected_action"]:
            failures.append({
                "sample_id": case["sample_id"],
                "expected": case["expected_action"],
                "actual": result["actual_action"],
                "stage_evidence": result.get("stage_evidence", []),
            })
    return failures

一旦失败，先看 stage_evidence：没有命中规则却变成 block，多半是默认动作或映射问题；规则命中正确但结果不对，才继续看阈值与优先级；连 sample_id 都对不上，则先修样本加载或字段转换。

用最小差异复查，最后再跑全量

修复时不要一次改阈值、提示模板和动作枚举。先复制失败样本，保持 sample_id 不变，只改一个因素；确认它恢复后，再跑同场景的对照样本，最后跑完整回归集。发布前我会保留三项检查：样本文件能完整解析、每个预期动作都有覆盖、失败记录包含阶段证据。

相关问题

为什么不直接保存过滤器的布尔结果？

布尔值无法表达人工复核等中间动作，也无法说明差异发生在哪个阶段；至少保存动作枚举和原因码。

边界样本应该放进放行组还是拦截组？

按策略预期动作放入复核组，并用成对样本记录上下文变化，不要为了让测试通过强行归类。

规则升级后哪些样本优先重跑？

先跑本次改动直接涉及的场景和最小差异对照，再跑全量，避免只看到局部变好。

没有阶段日志怎么办？

先在适配器层补结构化诊断字段，哪怕暂时只记录命中规则、评分区间和最终映射，也比只返回布尔值可定位。