基于大语言模型的零样本仇恨言论检测：多语言词汇库构建与提示词工程实践

1. 项目概述当大语言模型遇上内容安全最近在做一个挺有意思的项目核心就是利用大语言模型来识别网络上的仇恨言论。这听起来可能有点“用魔法打败魔法”的意思但实际做下来发现LLM在这类任务上的潜力远比我们预想的要大。传统的仇恨言论检测要么依赖大量人工标注的语料去训练一个专门的分类模型要么就是维护一个庞大的、不断更新的敏感词库。前者成本高、迭代慢而且模型往往“偏科”换个平台或者语言效果就大打折扣后者则过于机械容易被谐音、变体、隐喻轻松绕过。我们这个项目的出发点就是想看看能不能用LLM的“通识”能力来构建一个更灵活、更通用的检测框架。具体来说我们做了两件事一是尝试构建一个多语言的仇恨言论词汇库作为基础参考二是探索在零样本Zero-Shot甚至少样本Few-Shot的场景下直接让LLM来判断一段文本是否包含仇恨言论。这背后的逻辑是LLM在预训练阶段“阅读”了海量的互联网文本它对于人类语言中那些微妙的、带有攻击性、歧视性的表达其实已经有了相当程度的“理解”我们只需要用合适的方式去“唤醒”和引导这种能力。这个方向特别适合那些需要快速响应新出现的网络用语、或者需要覆盖多种小众语言的内容审核团队。你不用再苦等标注数据也不用为每一种新出现的攻击性俚语去更新词库理论上一个足够强大的LLM加上精心设计的提示词就能成为一个“万能”的初筛器。当然实际落地远没有这么简单里面充满了各种工程上的权衡和算法上的挑战。接下来我就把我们在构建多语言词汇库和实现零样本检测这两个核心环节中趟过的路、踩过的坑以及一些还算有效的实践经验详细拆解一遍。2. 核心思路与技术选型2.1 为什么是LLM零样本选择LLM和零样本学习作为技术基底是基于我们对业务痛点的深度分析。首先仇恨言论本身就是一个高度语境化和动态演变的问题。同一个词在不同的社区、不同的对话历史、甚至不同的表情符号搭配下其含义可能天差地别。传统的基于关键词匹配的方法正则表达式或Trie树完全无法处理这种复杂性误杀和漏杀是常态。其次多语言和长尾场景是另一个巨大挑战。为全球上百种语言分别训练和维护高质量的检测模型其成本和周期是不可想象的。而LLM特别是那些在多语言语料上训练过的大模型如Qwen、Llama的多语言版本本身就具备跨语言的理解和生成能力。这为我们提供了一个统一的、潜在的解决方案入口。零样本学习的吸引力在于其敏捷性。当一个新的社会事件引发一波新的攻击性话语时我们不需要收集数据、训练模型、部署上线这一整套漫长的流程。理论上我们只需要设计一个新的提示词Prompt描述清楚这种新现象的特征LLM就能立刻具备相应的识别能力。这极大地缩短了响应时间对于内容安全这种需要与黑产“赛跑”的领域价值巨大。我们的技术栈核心是Python主要利用了transformers库来调用开源LLM同时也接入了部分云服务商的API进行效果对比。选择开源模型进行本地部署主要是出于数据隐私和可控性的考虑毕竟处理的是敏感的文本内容。2.2 方案架构总览整个项目的架构可以看作是一个两阶段的流水线但这两个阶段并非严格串行而是可以相互补充。第一阶段多语言仇恨言论词汇库的构建。这个词汇库并非传统意义上的“黑名单”。它的目的不是用于直接匹配而是作为知识锚点和评估基准。我们通过多种方式收集种子词汇然后利用LLM对其进行扩展、分类和净化。例如给出一个英文的种族歧视词汇让LLM生成其在西班牙语、法语、阿拉伯语中的对应表达或者生成其常见的网络变体、谐音。这个词汇库最终会是一个结构化的数据库包含词条、语言、类别如种族、性别、宗教、攻击强度、常见上下文等字段。第二阶段基于提示词的零样本检测。这是核心的推理环节。我们设计了一系列的提示词模板将待检测的文本和任务指令Instruction组合后输入给LLM。LLM的输出被解析为一个结构化的判断例如{“contains_hate_speech”: true, “category”: “religious”, “confidence”: 0.85, “reasoning”: “文本中使用了针对X群体的贬义性历史称谓...”}。这里的“零样本”指的是在针对某个特定子类别的仇恨言论进行检测时我们不提供该子类别的任何正负样本仅通过自然语言描述来定义任务。这两个阶段是联动的词汇库可以帮助我们评估零样本检测的效果例如检查模型是否能识别出词汇库中的词条及其变体而零样本检测中发现的新的、高置信度的仇恨表达又可以反过来补充到词汇库中形成一个自我增强的闭环。3. 多语言仇恨言论词汇库构建实践3.1 种子数据收集与清洗构建词汇库的第一步是获取高质量的种子词条。我们主要从三个公开渠道获取学术数据集如HateXplain, HateSpeech Dataset、非政府组织发布的报告词表、以及经过严格审核的社区维护列表。这里有一个关键原则宁缺毋滥。初始种子的质量直接决定了后续LLM扩展的效果。如果种子词里混入了大量非仇恨的普通贬义词或政治敏感词LLM会沿着错误的方向“放飞自我”。我们收集到的原始数据非常杂乱格式不一且包含大量重复和噪声。清洗流程如下去重与归一化将不同来源的词条进行小写化、去除首尾空格等基础清洗后去重。对于同一词条的不同词性如名词和动词形式我们暂时保留后续分类。语言识别使用langdetect或fasttext的语种识别模型为每个词条打上语言标签。这一步至关重要是后续多语言扩展的基础。初步过滤通过一个简单的规则和基于BERT的语义过滤器剔除明显不符合要求的词条。例如过滤掉纯数字、单个字符、以及明显是网址或乱码的字符串。注意在收集和清洗过程中操作者会反复接触到大量负面内容容易产生心理不适。建议团队采取轮岗制度并为相关人员提供必要的心理支持资源。同时所有原始数据和中间数据必须存储在加密的、访问权限严格控制的环境中。3.2 利用LLM进行语义扩展与分类有了清洗后的种子词条就可以请LLM“出马”了。我们使用类似以下的提示词让LLM进行扩展你是一个专注于网络内容安全分析的语言专家。给定一个仇恨言论词汇请完成以下任务 1. 生成该词汇的5个常见变体或委婉表达例如谐音、缩写、拼写错误、表情符号替代。 2. 生成该词汇在西班牙语、法语、阿拉伯语中的直接对应翻译或同等攻击力的表达。 3. 判断该词汇主要属于哪个仇恨类别如种族、宗教、性别、性取向、残疾等。 词汇[SEED_WORD] 请以JSON格式输出包含字段variants, translations_es, translations_fr, translations_ar, category。这个过程是批量进行的。我们使用Qwen-7B-Chat模型在本地部署通过调整temperature参数通常设为0.3-0.5来控制生成结果的多样性和稳定性。对于每个种子词我们采样生成3次然后人工或通过一个简单的聚类算法来合并相似的结果选出最合理的扩展项。这个步骤产出了大量的候选词条但也引入了新的问题LLM的“幻觉”。它可能会生成一些根本不存在的“翻译”或者创造一些逻辑上合理但实际网络中极少使用的变体。因此人工复核在这一步无法省略。我们建立了一个简单的标注平台让审核员对LLM生成的词条进行“是/否”判断。为了提高效率我们只对LLM生成置信度通过模型输出的logits简单计算较高的部分进行全量审核对低置信度的则进行抽样审核。3.3 词汇库的结构化与维护通过扩展和审核我们得到了一个初具规模的词汇表。接下来需要将其结构化以便于查询和使用。我们设计了一个MongoDB集合文档数据库的灵活模式很适合这种半结构化数据文档结构如下{ “_id”: ObjectId, “core_term”: “原始种子词”, “language”: “en”, “category”: [“race”, “nationality”], “severity”: “high”, // 主观评估的攻击强度 “variants”: [ {“term”: “变体1”, “type”: “misspelling”, “language”: “en”}, {“term”: “变体2”, “type”: “euphemism”, “language”: “en”} ], “translations”: [ {“term”: “对应词1”, “language”: “es”, “confidence”: 0.95}, {“term”: “对应词2”, “language”: “fr”, “confidence”: 0.88} ], “context_examples”: [“一些包含该词的中性或恶意例句用于理解语境”], “source”: “HateXplain”, “review_status”: “approved” // ‘pending’ ‘approved’ ‘rejected’ }维护策略是这个词汇库能否持续生效的关键。我们设定了两个更新触发机制定时更新每月一次用最新的网络热点事件相关报道经过清洗作为输入让LLM主动发现可能的新兴仇恨表达加入待审核队列。被动更新当零样本检测模块连续多次高置信度地识别出某个不在库中的表达时将该表达及其上下文作为候选触发人工审核流程。实操心得不要试图构建一个“完美”或“完整”的词汇库这是不可能完成的任务。我们的目标应该是构建一个“足够好”的、动态生长的参考系。将80%的精力放在维护流程和审核机制上远比追求初始库的规模更重要。4. 零样本仇恨言论检测的提示词工程4.1 提示词模板的设计哲学让LLM做零样本分类提示词就是唯一的“指挥棒”。我们的设计目标是明确、结构化、且具有思维链。一个糟糕的提示词是“这段文本有没有问题” LLM会一头雾水。 一个稍好但仍有问题的提示词是“判断这是否为仇恨言论。” 这依然模糊因为“仇恨言论”的定义本身就有争议。我们的基础模板经历了多次迭代最终版本融合了角色定义、任务定义、分类标准、输出格式和少样本示例虽说是零样本但提供1-2个清晰示例能极大提升效果和稳定性。你是一个严格的内容安全审核专家。请根据以下标准分析用户输入的文本 - **仇恨言论**指基于个人或群体的固有属性如种族、民族、宗教、性别、性取向、残疾等进行攻击、贬低、威胁或煽动暴力的言论。 - **非仇恨言论**即使表达负面情绪、批评或争论但只要不针对上述固有属性进行攻击则不属于仇恨言论。 请按步骤思考 1. 识别文本中提及的个人或群体及其属性。 2. 判断文本对该个人或群体的描述是否构成基于其固有属性的攻击、贬低、威胁或煽动暴力。 3. 综合以上分析给出最终判断。 **输出格式必须严格遵循以下JSON结构** { “contains_hate_speech”: true/false, “targeted_attribute”: “race/gender/religion/etc or null”, “confidence”: 0.0到1.0之间的浮点数, “reasoning”: “你的分析推理过程用中文简述” } **示例1** 输入“你这种智商根本不配在这个部门工作。” 输出{“contains_hate_speech”: false, “targeted_attribute”: null, “confidence”: 0.9, “reasoning”: “该文本进行人身攻击但未针对种族、性别等固有属性属于侮辱而非仇恨言论。”} **示例2** 输入“XX地方的人都是小偷应该滚出去。” 输出{“contains_hate_speech”: true, “targeted_attribute”: “region/nationality”, “confidence”: 0.95, “reasoning”: “该文本基于地域出身对群体进行整体性贬低和驱逐威胁构成仇恨言论。”} 现在请分析以下文本 输入[USER_INPUT_TEXT]这个模板的优点在于角色设定让模型进入“专家”状态。定义清晰减少了“仇恨言论”概念的歧义。思维链Chain-of-Thought强制模型分步推理这通常能提高复杂任务上的准确性并且reasoning字段为人工复核提供了宝贵依据。结构化输出便于程序化解析confidence字段可用于后续的阈值过滤。少样本示例提供了正负案例校准了模型的判断尺度。4.2 多语言与上下文处理对于多语言文本我们只需在提示词的开头用目标语言重写指令和示例即可。例如将角色描述和任务定义翻译成西班牙语示例也换成西语的正负样本。实验表明对于主流语言LLM能够很好地理解并执行跨语言的指令。上下文处理是一个难点。网络评论往往很短且依赖对话历史。我们的策略是在检测时尽可能将当前评论与其上文的1-2条评论一起作为输入上下文。在提示词中明确说明“请结合以下对话上下文分析最后一条用户评论。” 这能有效解决一些指代和语境问题例如上文在讨论某个特定群体下文的“他们”就可能具有攻击性。4.3 温度参数与输出解析temperature参数控制着LLM生成的随机性。在分类任务中我们需要的是确定性高的输出因此通常将其设置为0或一个非常低的值如0.1。这能确保在输入相同的情况下输出尽可能一致。即使要求了JSON格式LLM有时仍会在JSON前后添加额外的解释性文字。因此健壮的输出解析是必不可少的。我们的解析流程是使用正则表达式如r\{.*\}从返回的文本中提取第一个看似JSON的结构。使用json.loads()尝试解析。如果解析失败则回退到字符串匹配寻找contains_hate_speech等关键字段或者直接判定为解析失败将本次请求标记为低置信度或触发重试。注意事项提示词工程是高度模型相关的。为Qwen优化的提示词在Llama上可能效果不佳。因此在切换模型底座时必须重新进行提示词的测试和调优。一个实用的方法是准备一个包含100-200条标注好的测试集用不同的提示词模板进行批量测试选择综合性能准确率、召回率、JSON解析成功率最好的一个。5. 系统集成与性能优化5.1 检测流水线架构在实际部署中我们不会对每一条文本都直接调用大模型那样成本太高、延迟太大。我们设计了一个分层过滤的流水线快速过滤层使用构建好的多语言词汇库进行模糊匹配。不仅仅是精确匹配词条还包括词干匹配、编辑距离匹配容忍1-2个字符的拼写错误。这一层可以极快地过滤掉大量包含明显仇恨词汇的文本命中率可能不高但召回率高目的是减轻后端LLM的压力。LLM零样本检测层对于快速过滤层未拦截的文本以及快速过滤层命中但置信度不高的文本送入LLM进行深度分析。这是系统的核心追求高精度。后处理与仲裁层对于LLM层输出contains_hate_speech为true且confidence高于某个阈值如0.8的直接判定为违规。对于置信度处于中间灰色地带如0.4-0.8的送入人工审核队列。同时这一层会记录LLM的reasoning和targeted_attribute用于丰富词汇库和模型评估。整个流水线用异步任务队列如Celery Redis实现确保高并发下的吞吐量。LLM调用部分我们为开源模型部署了TGIText Generation Inference服务或使用vLLM以支持动态批处理显著提高GPU利用率。5.2 成本与延迟的权衡使用LLM尤其是大型商用API成本是首要考虑因素。我们的优化策略包括缓存对完全相同的输入文本进行哈希缓存LLM的返回结果。网络文本中存在大量重复或高度相似的垃圾评论缓存能节省大量开销。动态批处理将短时间内多个用户的检测请求组合成一个批次一次性发送给LLM推理服务。TGI和vLLM等推理框架对此有很好的支持。模型蒸馏这是中长期策略。我们使用LLM如Qwen-72B对海量未标注数据生成“软标签”然后用这些数据去训练一个轻量级的专用文本分类模型如蒸馏后的BERT。这个学生模型在特定任务上可以逼近老师模型的性能但推理速度快百倍成本极低。零样本LLM则用于处理学生模型不确定的case或生成新的训练数据。延迟方面快速过滤层能在毫秒级响应。LLM层的延迟取决于模型大小和批处理情况。通过设置合理的超时时间如5秒并将超时或失败的请求降级到快速过滤层进行二次判断可以保证服务的可用性。对于实时性要求不高的场景如后台审核可以适当放宽延迟要求换取更高的批处理效率和更低的成本。5.3 评估指标与迭代循环如何评估这个系统的效果我们不再单纯看准确率、召回率因为标注数据本身就有主观性。我们建立了一套混合评估体系基于词汇库的基准测试从词汇库中采样构造正例包含仇恨词和负例不含仇恨词但语义相近的对抗样本测试系统的识别率。人工审核抽样每天随机抽取一定比例系统判定为“违规”和“通过”的文本由专业审核员进行二次判断计算系统判断与人工判断的一致性。LLM输出合理性评估重点审核confidence极高和极低的case以及reasoning字段逻辑混乱的case用以发现提示词或模型本身的问题。评估结果直接驱动迭代如果发现某一类别的仇恨言论如基于某地域的新兴歧视语漏报率高则可以将相关样本作为少样本示例补充到提示词中或将其添加到词汇库的扩展任务中。如果发现误报多集中于某类批评性言论则调整提示词中“仇恨言论”的定义描述使其更严格。定期用评估中发现的问题case对提示词进行A/B测试持续优化。6. 实战中遇到的挑战与解决方案6.1 歧义与语境依赖这是最大的挑战。比如“你真像个娘们”这句话在朋友间戏谑和针对跨性别者的恶意攻击中含义完全不同。LLM虽然有一定语境理解能力但在短文本且缺乏足够上下文时依然容易误判。我们的解决方案强制思维链如前所述要求模型输出reasoning。我们发现当模型误判时其推理过程往往会出现逻辑跳跃或错误归因。人工复核这些reasoning能帮助我们定位问题所在是定义不清还是语境不足。上下文窗口扩充尽最大可能提供对话历史。对于单条评论尝试从其所属的帖子正文、标题中提取关键信息作为补充语境。设置置信度中间地带不追求非黑即白的判断。对于置信度在0.3-0.7之间的“模糊地带”统一标记为“需要人工复核”坦然接受AI的能力边界。6.2 对抗性攻击与“越狱”用户会有意规避检测比如使用谐音、拆字、隐喻、引用典故或使用代码语言。我们构建的词汇库和LLM的语义理解能力在一定程度上能防御这类攻击。应对策略词汇库的动态扩展利用LLM本身让模型生成给定仇恨词汇的“可能变体”或“网络隐语”不断丰富词汇库的variants字段。提示词增强在提示词的任务描述中明确加入“请注意文本中可能存在的拼写错误、谐音、符号替代、隐喻等变体形式。”集成多模态信息对于包含表情符号的文本将表情符号转换为文字描述如[笑哭]后再送入LLM。因为一个“微笑”表情跟在仇恨话语后面可能意味着反讽或威胁升级。6.3 模型偏见与公平性LLM本身是在有偏见的互联网数据上训练的它可能放大某些社会偏见。例如它可能更容易将某些方言或特定文化背景下的粗口判定为仇恨言论而对另一些群体使用的类似语言则更宽容。缓解措施差异化阈值通过数据分析发现模型对A类言论的置信度系统性偏高对B类则偏低。我们可以为不同targeted_attribute设置不同的判定阈值进行粗略的校准。对抗性数据测试构建一个测试集其中包含针对不同群体但攻击性语义完全平行的句子对。测试模型在这些句子对上的判断是否一致。如果不一致则表明存在偏见需要调整提示词或通过少量平衡数据对模型进行微调如果使用可微调的开源模型。透明化与人工监督不将系统作为最终裁决者而是作为“AI助理”。始终将reasoning和confidence呈现给最终的人工审核员由人来做最终决定并将人的判断作为黄金标准反馈给系统用于持续优化。6.4 性能与规模化当检测量达到日均百万甚至千万级时完全依赖大模型API是不现实的。我们的策略是“大小模型结合”小模型蒸馏模型处理大部分用蒸馏出的轻量级BERT模型处理95%以上的流量它速度快、成本低。大模型LLM处理疑难杂症只对小模型置信度低、或属于新出现的热点事件的文本调用LLM进行深度分析。同时LLM的分析结果会持续生成新的标注数据用于迭代优化小模型。这套混合架构在保证检测效果不出现大幅下降的前提下将整体服务成本降低了超过90%并且满足了低延迟的要求。