NeMo Guardrails 框架：NVIDIA 的对话安全控制框架——怎么配置和使用

你有没有试过，给AI客服发一句“我心情不好，骂一下我老板”，结果它真的编了一段“老板是头猪”出来？我试过。那一刻我意识到，大模型不是不想守规矩，它根本不懂什么是规矩。你让它“别说坏话”，它只能靠猜什么算坏话。

后来我找到NVIDIA开源的NeMo Guardrails，才明白还有另一种控制方式：不是给它提要求，而是给它的对话过程装上物理护栏。

NeMo Guardrails 到底护的是什么

简单说，这个框架让你用一套脚本语言定义“用户可能说什么”和“机器人应该怎么回应”。它把大模型的自由发挥，限制在你设计的轨道里。

这件事的关键不是“过滤坏词”，而是“控制行为”。举个例子：你可以规定每当用户问政治话题，机器人必须说“我不讨论政治”，而且不管用户怎么换着法儿问，只要识别出意图，就执行这个硬性回复。

安装与配置：五分钟跑通一个demo

先安装：

pip install nemoguardrails

然后建一个配置文件。官方推荐的工作目录长这样：

config/
  config.yml
  rails.co

config.yml告诉框架用哪个大模型。

models:
  - type: main
    engine: openai
    model: gpt-3.5-turbo

  - type: instructions
    engine: openai
    model: gpt-3.5-turbo-instruct

其中main是负责生成回复的对话模型，instructions是负责识别意图、判断安全的辅助模型。别小看这两个模型的分工，这是后面所有机制的地基。

rails.co写的是对话“剧本”。

define user express greeting
    "Hi"
    "Hello"
    "Good morning"

define flow greeting
    user express greeting
    bot express greeting

这里定义了一个用户意图express greeting，并定义了一个流程：当用户说出这些词，机器人就回应一个问候。实际运行时，框架先让指令模型判断用户输入匹配哪个意图，匹配到就按flow走。

最简单的运行方式：

from nemoguardrails import LLMRails, RailsConfig
config = RailsConfig.from_path("./config")
rails = LLMRails(config)
response = rails.generate(messages=[{"role": "user", "content": "Hello!"}])
print(response["content"])

一条不让模型乱说的护栏，怎么写？

再来看一个正经的“安全护栏”：

define user ask about politics
    "What about the election?"
    "What's your opinion on the president?"

define flow refuse politics
    user ask about politics
    bot say "I am not going to discuss politics."

凡是被识别为“政治相关”的输入，机器人都会回答固定语句。这不是靠模型和概率，而是靠代码逻辑强制执行的。

你可能觉得这太死板。但它恰恰是护栏该有的样子——在安全场景下，你不需要创造性，你要的是确定性。

它背后的机制：意图识别 + 流程控制

我最早以为NeMo Guardrails就是敏感词过滤器，读源码后才发现它是“对话状态机”。每一次用户输入，框架都会按顺序做几件事：

用指令模型把用户输入归类到已定义的意图（比如“问候”“政治”“询问订单”）。
从已声明的flow中找匹配当前语境的那条。
如果flow里定义了一步需要模型生成的回复，就调用对话模型生成；如果定义了固定的回复或调API，就直接执行。

这里每一步都是可编程的。你可以在flow里插入Python动作，比如查数据库、调外部API，再将结果返回给用户。这比在系统提示词里求模型“不要编造”可靠得多。

多轮对话也是靠flow维持的。比如：

define flow ask for details
    user ask package status
    bot ask for order id
    user provide order id
    bot call get_package_status

flow里嵌了动作get_package_status，你可以写一个Python函数去查物流。这样模型只需要把订单号从用户话里抽出来，路该怎么走，都由代码决定。

进阶示例：提取动态变量

Colang支持用 $order_id 这样的变量捕获用户输入中的关键信息。

define user provide order id
    "My order id is $order_id"

define flow verify order
    user provide order id
    bot check order status

动作函数可以定义参数order_id，框架会自动把捕获的值传进去。

三类护栏，各守一道门

NeMo Guardrails把护栏分成三层，每个都可以单独配置：

类型	拦截的阶段	典型用途
Input Rails	用户输入进入系统之前	检测提示注入、识别有害请求
Dialog Rails	对话管理过程中	控制流程走向、防止模型跑偏
Output Rails	模型输出返回用户之前	过滤敏感内容、校验正确性

比如你可以在Output Rail里接一个小模型检查输出是否包含手机号，也可以用大模型判断回答是否与知识库矛盾。

它和“系统提示词”的区别，是一场革命

提示词是提醒，护栏是执行。举个例子：系统提示词就像在路口贴一张“禁止右转”的告示，司机心情好就遵守；NeMo Guardrails是把右转的路挖断。

当然，挖路也有挖路的代价。每次对话多一次指令模型调用，延迟和成本都上去了。如果你的场景是开放闲聊，想要模型自由飞翔，那这套流程设计会把你累死。

方案	原理	短板
系统提示词	在模型上下文里写入规则	软约束，容易被绕过
内容审核API	用分类器检查输入输出	只能拦典型违规，无法控制对话
NeMo Guardrails	意图识别+流程执行	需要额外模型调用，流程设计成本