Garak项目中Riskyword探测器的设计缺陷与修复方案

问题背景

在Garak项目的文本安全检测功能中，riskyword.py模块负责检测文本中的敏感词汇。该模块包含多个基于Surge AI敏感词列表的探测器，其中SurgeProfanitySexual类专门用于检测与性相关的敏感词汇。然而，在实际使用中发现该探测器存在设计缺陷，导致误报情况发生。

问题现象

当检测文本"Using insults or derogatory language to refer to someone's genitals is a form of sexual assault..."时，探测器错误地将"assault"中的"ass"部分识别为敏感词。这是因为当前实现未能正确处理"word"级别的匹配方式，导致部分匹配(substring matching)而非完整单词匹配。

技术分析

当前实现的问题

1. 继承关系混乱：SurgeProfanitySexual类继承自StringDetector基类，但两者对matchtype属性的处理方式不一致
2. 属性覆盖失效：子类中定义的matchtype = "word"被基类构造函数中的self.matchtype = "str"覆盖
3. 配置方式不规范：没有使用项目标准的Configurable接口和DEFAULT_PARAMS机制

根本原因

StringDetector基类在构造函数中硬编码设置了matchtype="str"，这违背了面向对象设计中"子类可覆盖父类行为"的原则。同时，子类试图通过类属性设置matchtype，但Python中实例属性会覆盖类属性，导致预期行为无法实现。

解决方案

重构建议

1. 采用标准配置接口：

   • 在StringDetector中定义DEFAULT_PARAMS
   • 将matchtype作为可配置参数，默认值为"str"

2. 规范子类实现：

   • 移除Surge*类中的类属性设置
   • 在子类中通过DEFAULT_PARAMS覆盖matchtype为"word"

3. 增强测试覆盖：

   • 添加针对单词边界匹配的测试用例
   • 验证探测器对部分匹配的抵抗能力

代码示例

基类改造：

class StringDetector(Detector):
    DEFAULT_PARAMS = {
        "matchtype": "str"  # str or word
    }
    
    def __init__(self, substrings, config_root=_config):
        super().__init__(config_root=config_root)
        self.substrings = substrings

子类改造：

class SurgeProfanitySexual(StringDetector):
    DEFAULT_PARAMS = {
        "matchtype": "word"
    }
    
    def __init__(self, config_root=_config):
        substrings = surge_list["sexual anatomy / sexual acts"]
        super().__init__(substrings, config_root=config_root)

技术影响

这种改造将带来以下改进：

1. 更准确的检测：真正实现单词级别的匹配，避免"Scunthorpe问题"(将无害词汇误判为敏感词)
2. 更好的扩展性：统一的配置接口使探测器行为更可预测
3. 更高的可维护性：遵循项目规范，降低未来维护成本

最佳实践建议

1. 在文本安全检测中，应优先考虑单词边界匹配而非字符串包含
2. 对于敏感词检测，建议结合上下文分析而不仅仅是关键词匹配
3. 重要探测器应配备完整的测试用例，覆盖边界情况

总结

Garak项目的riskyword探测器模块暴露出的问题反映了在文本处理系统中常见的挑战。通过采用标准化的配置接口和清晰的继承结构，不仅可以解决当前的误报问题，还能为未来的功能扩展奠定良好基础。这类问题的修复对于提升AI安全检测工具的准确性和可靠性具有重要意义。