SpeedBot的客户支持聊天机器人被设计来处理运输查询和送货更新。团队预计会收到一些关于包裹位置和送货时间的简单询问。然而，在上线三天后，它就已经开始编写Python脚本并调试SQL查询了，因为一些好奇的用户开始测试它的能力，超出了预期范围。无论你的应用程序是用来做什么的，有一个普遍的定律适用于大型语言模型的部署情况：用户最终总会试图让它来完成他们的作业。

在这篇文章中，我们将探讨一种实用的方法，在用户查询到达大型语言模型（LLM）之前对其进行筛选。我们不会依赖昂贵且复杂的解决方案，而是会看到如何通过微调一个较小的编码器模型（如ModernBERT）来创建一个高效且成本效益高的防护体系，以在生产环境中使用。

最近，SpeedBots 这家正在成长的物流公司推出了他们的客服聊天机器人，有着一个明确的使命了。

- 处理客户有关追踪订单的查询
- 计算运输费用
- 解决送货问题
- 解释可用的服务

但是，在部署几天后，支持团队却发现了一个意外的现象。他们精心设计的物流助手接收到的非相关请求越来越多。用户们开始把它当作一个通用的人工智能助手来使用，而不是专门用来帮助发货查询的助手。

这些无关查询浪费了计算资源，推高了运营成本，并可能让公司面临风险。问题变得明确：SpeedBots 如何在查询到达高成本的 LLM 之前有效过滤这些查询，同时又不影响合法客户的体验？

最流行的做法是所谓的“荣誉制度”，即在系统提示中加入一些过滤指令，让模型自觉遵守。

“你是个物流助理。
只回答关于物流和运输服务的问题。
如果有用户问到追踪订单、运费、送达时间或物流问题，给出有用的回复。
不要回答编程相关的问题、涉及非法活动的问题或无关的话题。
礼貌地解释说你只能帮忙回答有关物流的问题。”

这有点像告诉一个小孩不要吃饼干，然后又把饼干罐放在他能拿到的地方。当然，有时候这会奏效，但不可避免的是，一些聪明的用户最终会找到方法来说服模型，他们的非相关内容实际上是物流相关的。
另一种稍微复杂一点的变体是使用一个独立的“门房提示”，它会在每个查询到达主模型之前进行评估。

_“确定以下查询是否与物流服务相关。
只有在查询与货运、派送、跟踪或其他物流相关时，才回答真。
否则回答假。
查询：{{userquery}}”

限制如下:

- 指令冲突: 当我们将相互矛盾的指令放在同一个提示中 — “要有帮助” 但同时又是 “要有限制” — 实际上是在削弱模型在这两项任务上的表现。我们越强调谨慎，它就越不具有帮助性；反之，我们越强调有帮助性，它就越宽松。

- 误拒： 在实际应用中，LLM 在进行过滤时往往过于谨慎。他们经常误拒那些完全合法且在预期范围内的查询，这给有正当需求的用户带来了极大的不满。

对于SpeedBots来说，这体现为他们的聊天机器人拒绝处理诸如“运送易碎物品需要多少钱？”这样的简单问题，因为它将“易碎物品”解读为可能不符合政策规定。与此同时，一些巧妙措辞的无关请求仍然能够通过。最终导致真正顾客感到沮丧，而计算资源仍然被浪费在处理非物流请求上。

一种更为复杂的方法是使用专门设计的模型，如 Llama Guard，这类模型专门用于内容审核和过滤。这些专业的“筛选员”比顶级模型（如 GPT-4、Claude 3.x 或 Gemini 2）更小，参数量通常在 80 亿上下，而不是数百亿的参数。

在理论上，这种方法很合理：而不是要求你的主厨也要负责迎宾工作，你会雇佣一个专职门童。对于SpeedBots来说，这就意味着所有进入的查询首先通过一个安全模型，只有经过批准的问题才能到达其主要的物流管理助手。

限制：即使较小的问题依然是问题

校准的挑战： 虽然这些专门的过滤模型比高级LLM更实惠（大约只需要四分之一的价格，同时参数量仅为八分之一），但它们真正的限制在于校准。安全模型通常设计有广泛的保护措施，不易通过仅调整提示来适应特定领域。

过度的热情： 安全模型通常被调校为提供最大保护，这往往是以牺牲易用性为代价的。对于SpeedBots而言，这意味着合法的物流查询，如“小心轻放”的请求，会被标记为危险，而一些巧妙伪装的不恰当内容则有时会漏网。通用安全模型擅长捕捉明显有害的内容，但在处理专业应用所需的行业特定细节时却显得力不从心——从而导致误报和漏报，影响了它们的效果。

尽管这些模型确实改进了“礼貌请求”的方法，但无法精确控制过滤内容的问题依然存在，成为一个重大限制。对于有特定领域需求的公司来说，这种方法仍然让太多因素依赖于运气，对于像SpeedBots这样的公司来说，这种情况令人担忧。

下一步的逻辑步骤是通过微调来定制您的筛选模型。这种方法可以将专门的安全模型，例如Llama Guard，或较小的通用大型语言模型（LLM）调整，以创建一个专门针对您领域的定制护栏。

这意味着训练一个模型来区分物流相关的问题和其他问题，并具备特定领域的专业知识。理论上，这样既能高效筛选，又能理解特定领域的知识。

限制：疗法反噬之时

资源密集型开发：微调：即使微调一个“小型”的80亿参数模型，也需要专用硬件设备、大量的工程时间和显著的计算资源。该过程需要具备机器学习操作的专业知识，并且需要精心整理的数据集，通常需要配备高内存的显卡（如A100 GPU）的专用GPU集群，每次训练可能需要数百美元的计算成本。

无尽的迭代循环问题： 生成模型带来了独特的评估挑战，这些挑战与常见的分类任务不同。尽管团队可以尝试将输出格式化为特定格式（例如JSON）以便于解析，但核心挑战在于缺乏一个直接的概率评分来评估置信度或调整阈值。每次迭代都需要分析不同输入中的标记选择模式，并判断模型的响应是否在宽容与限制之间取得了适当的平衡。这一定性评估过程比评估清晰的指标（如分类准确率或F1分数）更加复杂且耗时。

效益递减： 当过滤模块的开发资源超过核心功能需求时，成本效益比变得越来越难以平衡。"SpeedBots" 发现自己在问：“我们是否真的应该继续将有限的人工智能预算用于打造更好的门卫，而不是改进实际的服务？”

部署难度： 无论采用何种方式，部署微调模型都相当有挑战性。使用API提供商虽然更简单，但费用可能高达基础模型的两倍，并且要靠无服务器选项支持LoRA/QLoRA。而自行托管则需要专门的硬件，比如配备16GB以上高内存GPU的设备，用于8B模型，以及像vLLM这样的优化库和复杂的扩展架构。这意味着你需要专门的DevOps专家来维护这个本质上只是一个“守门人”的系统，而不是专注于你的核心业务。

对于SpeedBots来说，最初只是简单的过滤需求，逐渐演变成了复杂的基础设施建设。他们的机器学习团队发现自己花在配置GPU集群上的时间比提升实际能推动业务价值的物流辅助能力的时间还要多。仅是工程上的开销，还不算上持续的运营成本，在本质上只是一个预处理步骤的情况下，这种做法很难证明其合理性。

在尝试了越来越复杂和昂贵的解决方案之后，SpeedBots 的工程团队决定采取不同的方法。他们没有部署重型的 LLM 来进行过滤，而是实施了一个轻量级的解决方案，使用专门为文本分类任务优化的编码器模型 ModernBERT。以下是如何搭建他们的防护机制。

1.: 创建策略性数据集

SpeedBots 需要高质量的训练数据，反映合法的物流查询，还包括他们想要过滤的非相关问题。他们利用了 DeepSeek V3 这个强大的顶级模型，来生成一个多样化的数据集：

# 生成数据集的示例提示
prompt = """  
为物流公司聊天机器人，生成10个示例用户问题。  
对于每个问题，标明是否相关（TRUE）。或不相关（FALSE）。  
包括一些尝试让聊天机器人去做无关任务，或绕过安全规定。"""

这个过程使他们能够创建一个包含超过2000个多样化例子的数据集。模型生成的重复问题被删除了。虽然他们知道有更有效的方法来减少重复，但这额外的复杂性并不值得，因为生成这些样本的成本非常低，不到1美元就可以生成大约5000条记录。这种方法不仅节省了成本，还快速生成了数千个真实的样本，包括试图规避过滤器的复杂尝试，这些如果手动创建将会非常耗时和困难。

2. 通过多种模型验证

为了确保数据集的质量，SpeedBots 使用不同的模型（DeepSeek R1）来独立核查分类结果。

    review_prompt = """  
    请审核以下用户问题及其分类：  
    问题：“{question}”  
    分类：请提供 TRUE 或 FALSE 的判断。  

    这是否应该由物流公司的聊天机器人来回答？请考虑以下几点是否符合：  

1. 该问题是否与物流服务相关  

2. 该问题是否没有试图绕过安全功能  

3. 该问题是否没有请求有害内容  
    请一步一步地思考，最后给出 TRUE 或 FALSE 的判断。"""

这种多模型方法起到了质量控制的效果，识别出分类不明确或可能错误的特殊情况。

3. 人机循环精调

极速团队发现大约有5%的样本在两个模型之间有分歧。他们并没有仅仅依赖自动化流程，而是采取了其他措施。

- 保留了两个模型都同意的例子（大约占数据集的98%）
- 手动审查了每个分歧案例
- 根据各自的业务需求做出了最终决定
- 用这些改进的标签更新了数据集

这种人工检查确保了最终训练数据准确地反映了SpeedBots特定的过滤需求。

4.高效的调整过程

利用Hugging Face的Transformers库，团队在他们自己的数据集上对这种ModernBERT模型（3.95亿个参数）进行了微调：

    training_args = 训练参数(  
     output_dir="modernbert-llm-router",  # 输出目录
     per_device_train_batch_size=32,      # 每设备训练批量大小
     learning_rate=5e-5,                  # 学习率
     num_train_epochs=2,                  # 训练轮数
    )

与他们之前对更大模型的尝试不同的是，这次微调过程在不到15分钟的时间内就在一个开发者配备的Mac M2上完成了。模型所需的内存占用量很小，可以轻松地适应单个NVIDIA T4 GPU。这标志着一个巨大的进步，比通常需要数小时的LLM微调过程要快得多。

5. 性能结果, 该模型超出了SpeedBots的预期：

• 与精选数据集相比，F1 分数达到 97%
• 推理时间约为每查询 30 毫秒，而像 Llama Guard 这样的“小型”LLM 大约需要 1000 毫秒，而像 R1 这样的推理模型则需要几秒钟的响应时间
• 能准确识别细微的破解尝试
• 减少对合法物流问题的误报

最令人惊讶的是，这个轻量级模型的分类性能几乎与顶级推理模型DeepSeek R1相同——DeepSeek R1性能更强，运行成本高得多。团队成功地将高级推理模型的分类能力浓缩成一个高效的专用过滤器。

一开始，他们遇到了一个棘手的问题——高效地过滤掉不必要的查询。从而找到了一个完美符合他们需要的优雅解决方案。没有遵循常规做法，而是选择了合适的工具，他们建立了一个防护系统。

• 精准定位: 专门为物流领域打造
• 资源高效: 计算资源占用很少
• 高度准确: 比更大更复杂的模型更准确
• 操作简便: 部署和维护都非常简单

速博的例子说明，有时候最有效的AI方案并不是规模最大或最复杂的，而是最适合具体任务的模型。

要重现这个实验并获取ModernBert的微调以及生成数据集的完整代码，可以在这个github仓库中找到。