:配置 `target_lang` 与 `langproviders` 实现跨语言 LLM 漏洞扫描)
garak 多语言翻译支持Translation Support配置target_lang与langproviders实现跨语言 LLM 漏洞扫描【免费下载链接】garakthe LLM vulnerability scanner项目地址: https://gitcode.com/GitHub_Trending/ga/garakgarakthe LLM vulnerability scanner默认以英文 probe/detector 关键字对模型进行越狱与注入攻击测试。当被测目标使用其他语言时translation.rst 文档所描述的翻译支持机制可以把 probe 和 detector 的关键词、触发器翻译成目标语言让针对「非插件编写语言」模型的测试成为可能。阅读本文后你将掌握run段中target_lang与langproviders的完整配置方法能够分别基于 DeepL、NVIDIA Riva、Google Cloud Translation 与本地 Hugging Face 模型搭建双向翻译链路并理解翻译服务在 garak 内部的加载与调用原理。为什么 garak 需要翻译支持garak 的 probe 与 detector 插件在编写时以英文为默认语言其攻击载荷payload、触发器trigger与判定关键字均为英文。当被测模型target under test接受并产生非英文文本时直接套用英文载荷会大幅削弱攻击的有效性。翻译支持正是为了解决这一问题在运行前将 probe 与 detector 的关键字和触发器翻译为target_lang指定的目标语言从而对非英文模型执行与原英文场景等价的测试。从源码结构看这一能力由三个层次组成翻译器的插件包 garak/langproviders/其中 base.py 定义了所有语言提供者LangProvider的公共基类local.py 与 remote.py 分别实现本地与远程翻译器集中调度模块 garak/services/langservice.py负责按配置实例化、校验并分发翻译器消费方是各 probe 基类例如 garak/probes/base.py 中的_get_langprovider()/_get_reverse_langprovider()以及 detector 侧的反向翻译判定流程。当前限制Limitations在使用翻译功能前需要明确文档中列出的限制与 BCP47 码 en 强耦合目前句子检测与结构解析强烈依赖BCP47码 en即默认源语言假设为英文反向翻译的必要性snowball 类 probe 以及 Hugging Face detector 由于模型加载格式的原因必须进行反向翻译reverse translation将目标语言结果再译回英文用于判定Hugging Face detector 的英文模型依赖Hugging Face 的 detector 主要加载英文模型因此需要为目标语言额外准备 NLI自然语言推理模型用于判定资源不足时的降级方案如果 probe 或 detector 加载失败可能需要选择更小的本地翻译模型或改用远程翻译服务运行时间显著增加翻译会引入额外执行时间具体取决于可用计算资源。支持的翻译服务文档列出了四类官方支持的翻译后端后端类型说明Hugging Face本地Helsinki-NLP/opus-mt-{src}-{tgt}MarianMT 系列、facebook/m2m100_418M、facebook/m2m100_1.2BDeepL远程通过 DeepL API 调用配置项remote.DeeplTranslatorNVIDIA Riva for Developers远程通过 Riva API 调用配置项remote或remote.RivaTranslatorGoogle Cloud Translation API远程通过 Google Cloud Translation 调用配置项remote.GoogleTranslator远程服务的具体语言支持范围不在仓库内维护需参考各服务官方支持矩阵DeepL 支持语言列表、Riva NMT 支持矩阵、Google Cloud Translation 支持语言。仓库源码中则各自内置了白名单校验例如 remote.py 中RivaTranslator.lang_support列出了约 33 种语言并对es/zh/pr等做了区域码覆盖es-US、zh-TW、pt-PTDeeplTranslator.lang_support与GoogleTranslator同样会在加载时校验语言对不支持的组合会抛出BadGeneratorException。API Key 的获取与注入使用 DeepL、Riva 或 Google Cloud Translation 等云服务时必须提供 API key。文档给出了各服务的获取入口DeepL Pro-API、build.nvidia.com 上的 Riva Megatron-1B NMT、Google Cloud Translation 认证文档并建议通过环境变量注入避免把密钥写死在配置文件中# DeepL export DEEPL_API_KEYxxxx # Riva export RIVA_API_KEYxxxx # Google Cloud Translation注意这里要求的是服务账号 JSON 凭据文件的路径 export GOOGLE_APPLICATION_CREDENTIALSpath to credential configuration json file对应源码中每个远程翻译器通过ENV_VAR类属性声明所需的环境变量remote.py 的RivaTranslator.ENV_VAR RIVA_API_KEY、DeeplTranslator.ENV_VAR DEEPL_API_KEY、GoogleTranslator.ENV_VAR GOOGLE_APPLICATION_CREDENTIALS。其中GoogleTranslator覆写了_validate_env_var()专门校验该环境变量指向的文件路径真实存在参见 remote.py。值得一提的是garak 的配置加载器 garak/_config.py 会扫描配置文件中出现的api_key字段在非 Windows 平台若检测到配置文件对其他人可读会发出权限告警建议将敏感信息移出配置文件或收紧文件权限。配置文件run段的两把钥匙翻译功能在配置文件的run段配置核心是两个键target_lang一个BCP47语言码指明被测目标的语言例如ja、fr、jap等langproviders一个列表每个元素是一个语言对定向的翻译器配置。配置默认值定义在 garak/_config.pyrun.target_lang en、run.langproviders []即不配置时翻译功能保持关闭、按英文运行。每个语言提供者配置项遵循项目的 configurable 模式包含以下键键必填说明language是以,分隔的一对BCP47语言码如en,ja描述该翻译器支持的翻译方向model_type是要实例化的langproviders模块及可选实例类如local、remote、remote.DeeplTranslatormodel_name条件必填翻译加载的模型名local类型的翻译器必须提供api_key可选远程服务密钥也可以改用环境变量注入此外翻译模型类型还可能定义自己的专属参数model-specific parameters。有两个重要注意事项MarianMT 语言码的不一致Helsinki-NLP/opus-mt-{source}-{target}命名中的语言码格式并不统一。双字母码通常可在 Google Admin SDK 语言列表中查到三字母码则需要搜索确认如jap、cmn等。从 local.py 的源码可以看出model_name中的{}会被替换为source_lang-target_lang拼接而成的模型后缀所以语言码必须与 Hugging Face 上真实存在的模型名一致否则会在下载模型时抛出异常。本地翻译不支持跨多进程边界本地翻译会实际加载模型设计上不用于跨多进程multiprocessing场景local.py 中通过mp.set_start_method(spawn, forceTrue)固定了进程启动方式。langproviders列表中的每一项都对应单一翻译方向single translation pair。由于 snowball 类 probe 与 Hugging Face detector 需要反向翻译运行前必须同时配置正向与反向两个方向的翻译器缺一不可。这一校验逻辑实现在 garak/services/langservice.py加载完成后会遍历所有已加载的语言对若找不到{target},{source}对应的反向条目则抛出GarakException并提示「Configuration must specify language providers for each required direction」。另外若某项配置的source_lang target_lang_load_langprovider会直接返回不做任何翻译的Passthru翻译器garak/services/langservice.py。配置文件写好之后通过--configCLI 选项传入路径即可生效。通用配置模板run: target_lang: target-language-code langproviders: - language: source-language-code,target-language-code api_key: your-API-key model_type: translator-module-or-module.classname model_name: huggingface-model-name - language: target-language-code,source-language-code api_key: your-API-key model_type: translator-module-or-module.classname model_name: huggingface-model-name四种后端的完整配置示例DeepLrun: target_lang: target-language-code langproviders: - language: source-language-code,target-language-code model_type: remote.DeeplTranslator - language: target-language-code,source-language-code model_type: remote.DeeplTranslatorexport DEEPL_API_KEYxxxx python3 -m garak --target_type nim --target_name meta/llama-3.1-8b-instruct --spec probes.encoding --config path-to-your-yaml-config-file仓库测试资产 tests/_assets/langservice/translation_deepl.yaml 给出了实际使用的简化版本en,jaja,en双向、target_lang: ja。NVIDIA Rivarun: target_lang: target-language-code langproviders: - language: source-language-code,target-language-code model_type: remote - language: target-language-code,source-language-code model_type: remoteexport RIVA_API_KEYxxxx python3 -m garak --target_type nim --target_name meta/llama-3.1-8b-instruct --spec probes.encoding --config path-to-your-yaml-config-filemodel_type: remote会加载模块默认类RivaTranslator见 remote.py 的DEFAULT_CLASS RivaTranslator。Riva 翻译器默认连接grpc.nvcf.nvidia.com:443并携带固定的function_id实例化时还会用单个 ASCII 字符A发起一次校验翻译VALIDATION_STRING配置无效会立即报错参见 remote.py。对应测试资产为 tests/_assets/langservice/translation_riva.yaml。Google Cloud Translationrun: target_lang: target-language-code langproviders: - language: source-language-code,target-language-code model_type: remote.GoogleTranslator - language: target-language-code,source-language-code model_type: remote.GoogleTranslatorexport GOOGLE_APPLICATION_CREDENTIALSpath to credential configuration json file python3 -m garak --target_type nim --target_name meta/llama-3.1-8b-instruct --spec probes.encoding --config path-to-your-yaml-config-fileGoogleTranslator默认参数中还有一个可选project_id可通过服务账号文件认证translate.Client.from_service_account_json认证失败时会回退到通用认证路径翻译失败时内置 5 次重试并随机退避0–2 秒每次翻译结果还会经ftfy修正文本参见 remote.py。本地 Hugging Face 模型默认Helsinki-NLP MarianMT不提供model_name时本地翻译默认加载Helsinki-NLP/opus-mt-*系列模型run: target_lang: jap langproviders: - language: en,jap model_type: local - language: jap,en model_type: localpython3 -m garak --target_type nim --target_name meta/llama-3.1-8b-instruct --spec probes.encoding --config path-to-your-yaml-config-file默认model_name为Helsinki-NLP/opus-mt-{}见 local.py 的DEFAULT_PARAMS加载时{}会被替换为en-jap、jap-en等真实模型名。注意测试资产 tests/_assets/langservice/translation_local_low.yaml 中保留了显式写法model_name: Helsinki-NLP/opus-mt-{}作为对照。扩展facebook/m2m100本地翻译额外支持 Hugging Face 的M2M100Model类型只要提供的model_name包含m2m100即按 M2M100 加载run: target_lang: ja langproviders: - language: en,ja model_type: local model_name: facebook/m2m100_418M - language: jap,en model_type: local model_name: facebook/m2m100_418Mpython3 -m garak --target_type nim --target_name meta/llama-3.1-8b-instruct --spec probes.encoding --config path-to-your-yaml-config-fileM2M100 分支会在 local.py 中对源语言与目标语言做白名单校验内置约 100 种语言码含ja、zh、fr等翻译时通过forced_bos_token_idself.tokenizer.get_lang_id(self.target_lang)指定目标语言不支持的组合会抛出BadGeneratorException。仓库测试资产 tests/_assets/langservice/translation.yaml 即采用facebook/m2m100_418M双向配置。翻译服务的加载与双向校验机制理解了配置后再来看 garak 内部是如何把这些 YAML 条目变成可用翻译器的。核心入口是 garak/services/langservice.py 的load()函数流程如下读取配置遍历_config.run.langproviders逐项调用_load_langprovider()实例化翻译器实例化_load_langprovider()把单个条目包装成 configurable 结构通过_plugins.load_plugin(pathflangproviders.{model_type})动态加载插件garak/services/langservice.py因此model_type既可以是模块名local、remote也可以是带类名的路径remote.DeeplTranslator、remote.GoogleTranslator补齐原生方向若配置中不存在{target_lang},{target_lang}的原生语言对象会自动补一个local类型的 no-op 翻译器garak/services/langservice.py双向校验确认每个已配置方向都存在反向条目缺失则抛异常中止运行garak/services/langservice.py。运行时probe/detector 通过get_langprovider(source, reverseFalse)获取单方向翻译器garak/services/langservice.pyreverseTrue时返回目标语言译回源语言的反向翻译器。在 garak/probes/base.py 中probe 初始化即分别取得正向与反向两个翻译器翻译后的载荷会打上lang标签并在探测结果返回后使用反向翻译器把模型输出再译回英文供 detector 判定参见 garak/probes/base.py 附近的reverse_langprovider.get_text(results_text)调用。在文本处理层面base.py 的split_input_text()会按换行拆分输入并对包含:且不含 URL的行进一步按冒号切分尽量保留结构_short_sentence_translate/_long_sentence_translate分别处理 200 字符以内与更长的文本对于不可见 Unicode 字符行、纯空白行、$等特殊行会跳过翻译或原样保留避免破坏编码类 probe 的载荷结构相关逻辑见 base.py。测试 tests/langservice/test_langprovision.py 对split_input_text的冒号切分行为有明确断言同时验证了本地翻译器对多行载荷逐行翻译、保留非文本行的行为tests/langservice/test_langprovision.py。使用建议与注意事项语言码一致性target_lang、language中的语言码必须与所选后端支持的格式一致MarianMT 需匹配 Hugging Face 模型名M2M100/Riva/DeepL 需在各自白名单内远程服务还受各厂商官方支持矩阵约束务必配置双向运行前确认langproviders同时包含源,目标与目标,源两个方向的条目否则langservice.load()会直接中止运行密钥安全优先使用环境变量注入 API key若写在配置文件中注意 garak 会检查文件权限并给出告警garak/_config.py资源规划本地翻译会下载并加载完整的 Hugging Face 模型M2M100 系列体积较大首次运行耗时明显模型加载失败时可换用更小的本地模型或改用远程服务并预留足够的磁盘与内存空间整体开销翻译会为每次探测引入额外的前后向翻译调用整体执行时间会随 prompt 数量与文本长度显著增长可结合--parallel_requests等并发参数权衡。相关代码与测试路径翻译器插件 garak/langproviders/、调度与校验 garak/services/langservice.py、配置默认值 garak/_config.py、probe 侧消费 garak/probes/base.py、测试用例 tests/langservice/test_langprovision.py 与配置样例 tests/_assets/langservice/。【免费下载链接】garakthe LLM vulnerability scanner项目地址: https://gitcode.com/GitHub_Trending/ga/garak创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考