人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载本文以 NeMo Guardrails 仓库中 examples/configs/llm 目录为线索系统梳理 DeepSeek R1、OpenAI Responses API、NVIDIA NIM、HuggingFace Inference Endpoints / Pipeline、Vertex AI 等十余种 LLM 提供方provider在 NeMo Guardrails 中的接入方式。读完本文你将掌握engine与NEMOGUARDRAILS_LLM_FRAMEWORK的框架选择机制、OpenAI 兼容端点的base_url路由技巧、自定义 HuggingFace Pipeline 提供方的注册流程以及每类配置对应的源码级实现细节可直接照搬示例完成自己的接入与验证。目录定位这些示例展示什么、不承诺什么examples/configs/llm/README.md明确说明该文件夹内的示例用于展示不同 LLM 提供方应该如何被配置。每个示例的 guardrails 配置都非常简单其唯一目的是验证 LLM 已被正确配置——这些配置不适用于生产部署生产环境必须基于真实业务场景重新设计 rails、提示词与安全策略。需要特别注意的是该目录中的部分示例如 dolly、falcon、mosaic、vicuna、llama2 等模型配置已被纳入 NeMo Guardrails 的 topical rails 评估集并在对应数据集上取得了良好结果评估详情可参考 nemoguardrails/evaluate/README.md。同时项目团队鼓励社区贡献如果你发现了改进 NeMo Guardrails 与常见 LLM 协作方式的机会欢迎提交 PR——LLM 专属配置正是参与社区的最佳切入点。先理解两个核心概念engine 与 LLM 框架阅读该目录前必须先区分两个容易混淆的概念1.engine引擎config.yml中models[].engine字段声明的提供方类型例如openai、nim、nvidia_ai_endpoints、vertexai、huggingface_endpoint、hf_pipeline_dolly等。engine 决定该模型请求由哪个底层客户端或 provider 处理。2. LLM 框架frameworkNeMo Guardrails 当前支持default默认框架与langchain两种框架通过环境变量NEMOGUARDRAILS_LLM_FRAMEWORK选择。其默认值在源码 nemoguardrails/llm/frameworks/registry.py#L27 中定义_default_framework: str os.environ.get(NEMOGUARDRAILS_LLM_FRAMEWORK, default)框架的懒加载与注册逻辑同样位于 registry.py#L61-L74当请求langchain时会导入nemoguardrails.integrations.langchain.llm_adapter.LangChainFramework请求default时则导入nemoguardrails.llm.frameworks.default.DefaultFramework。关键结论贯穿整个目录的分水岭DefaultFramework默认自带 OpenAI 兼容 HTTP 客户端只调用/v1/chat/completions无需 LangChain 依赖。任何 OpenAI 兼容端点engine: openaiparameters.base_url都可直接接入。LangChain 框架NEMOGUARDRAILS_LLM_FRAMEWORKlangchain通过langchain-provider生态提供huggingface_endpoint、vertexai、use_responses_api等 DefaultFramework 不支持的专属能力。这一选择直接决定了目录中每个示例的可用性下文每个示例都会明确标注其框架要求。OpenAI 兼容端点DefaultFramework 的通用接入范式DefaultFramework 对 provider 有内置的默认base_url与 API Key 环境变量映射见源码 nemoguardrails/llm/frameworks/default.py#L28-L41_DEFAULT_BASE_URLS: Dict[str, str] { openai: https://api.openai.com/v1, nim: https://integrate.api.nvidia.com/v1, nvidia_ai_endpoints: https://integrate.api.nvidia.com/v1, ollama: http://localhost:11434/v1, } _API_KEY_ENV_VARS: Dict[str, str] { openai: OPENAI_API_KEY, nim: NVIDIA_API_KEY, nvidia_ai_endpoints: NVIDIA_API_KEY, ... }当 engine 不在内置映射中如deepseek时default.py#L46-L55 的_resolve_base_url会抛出错误提示你如果端点 OpenAI 兼容请设置parameters.base_url否则请切到 LangChain 框架。这正是目录中多个示例的接入思路。DeepSeek R1一个典型的 OpenAI 兼容接入examples/configs/llm/deepseek-r1/ 展示如何调用 DeepSeek 托管的 R1 推理模型deepseek-reasoner。DeepSeek 的官方 APIhttps://api.deepseek.com/v1与 OpenAI 兼容因此使用 DefaultFramework 的engine: openaiparameters.base_url即可路由到内置的 OpenAI 兼容客户端无需任何 LangChain 依赖。# examples/configs/llm/deepseek-r1/config.yml models: - type: main engine: openai model: deepseek-reasoner api_key_env_var: DEEPSEEK_API_KEY parameters: base_url: https://api.deepseek.com/v1运行前只需设置环境变量export DEEPSEEK_API_KEYsk-...注意api_key_env_var: DEEPSEEK_API_KEY显式指定了 API Key 的来源环境变量默认框架内置映射中没有deepseek因此必须显式给出。该示例还提供了两条可选路径NVIDIA NIM 替代方案DeepSeek R1 权重也可通过 NVIDIA NIM 托管端点获取将模型条目替换为nim引擎与规范的 NIM 模型 IDmodels: - type: main engine: nim model: deepseek-ai/deepseek-r1LangChain 回退方案若偏好使用 LangChain 的langchain-deepseek适配器例如想利用 LangChain 专属特性则设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain、安装pip install langchain langchain-deepseek并在config.yml中使用engine: deepseek。README 明确建议新部署优先走上述 DefaultFramework 路径。OpenAI Responses API切换端点与工具调用的边界examples/configs/llm/openai-responses-api/ 展示如何将 OpenAI 模型路由到 Responses API/v1/responses而非 Chat Completions。该示例必须使用 LangChain 框架DefaultFramework 的 OpenAI 兼容客户端只调用/v1/chat/completions而langchain_openai.ChatOpenAI类支持use_responses_api参数。# examples/configs/llm/openai-responses-api/config.yml models: - type: main engine: openai model: gpt-5-pro parameters: # 将调用路由到 OpenAI 的 /v1/responses 端点而不是 /v1/chat/completions。 # 仅在 LangChain 框架NEMOGUARDRAILS_LLM_FRAMEWORKlangchain下生效参见 README.md。 use_responses_api: true运行前置条件export NEMOGUARDRAILS_LLM_FRAMEWORKlangchain pip install langchain langchain-openai export OPENAI_API_KEYsk-...重要警示如果没有设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain库会把use_responses_api当作未知字段转发给/v1/chat/completions调用并不会真正切换到 Responses API。自托管模型vLLM 及其他 OpenAI 兼容服务器部分推理服务器如 vLLM除/v1/chat/completions外还暴露 OpenAI 兼容的/v1/responses端点。此时可保持engine: openai、设置use_responses_api: true并把base_url指向自己的服务器models: - type: main engine: openai model: openai/gpt-oss-20b api_key_env_var: ANY_KEY_CAN_BE_USED_HERE parameters: base_url: http://localhost:8000/v1 use_responses_api: true该配置仍需NEMOGUARDRAILS_LLM_FRAMEWORKlangchain因为切换开关由langchain_openai.ChatOpenAI提供。启用前务必确认你的服务器实现了/v1/responses——并非所有 OpenAI 兼容服务器都支持。工具调用仅透传函数工具调用可在 Responses API 上以流式和非流式两种模式工作。适配器会将助手的工具调用呈现在LLMResponse.tool_calls与LLMResponseChunk.delta_tool_calls上并将finish_reason报告为tool_calls。但 Responses API 内置工具如web_search、file_search、code_interpreter、computer_use、MCP、图像生成不会被呈现为工具调用——API 将这些工具作为 response output items 返回而非函数调用因此目前仅支持函数工具透传。NVIDIA NIM 与 NVIDIA AI Endpoints零配置的托管端点目录中的 llama-3/ 与 nim/ 两个示例展示了 NVIDIA 生态的两种接入方式。NVIDIA AI Endpointsnvidia_ai_endpoints引擎——llama-3/config.ymlmodels: - type: main engine: nvidia_ai_endpoints model: meta/llama-3.1-70b-instructNVIDIA NIMnim引擎——nim/config.ymlmodels: - type: main engine: nim model: meta/llama3-8b-instruct parameters: base_url: http://localhost:7331/v1从源码 default.py#L30-L31 可以看到nim与nvidia_ai_endpoints的默认 base_url 均为https://integrate.api.nvidia.com/v1API Key 均取自NVIDIA_API_KEY环境变量nim示例通过覆盖parameters.base_url指向本地自托管 NIM 服务http://localhost:7331/v1。在 LangChain 框架中两者统一映射到_init_nvidia_model初始化逻辑见 nemoguardrails/integrations/langchain/langchain_initializer.py#L349-L350。此外 nemoguardrails/llm/models/openai_chat.py#L35 会把https://integrate.api.nvidia.com/v1识别为nim引擎说明模型请求路径与引擎名存在双向关联。HuggingFace Inference EndpointsLangChain 专属与 TGI 替代hf_endpoint/ 示例使用 HuggingFace Inference Endpoints 服务例如databricks/dolly-v2-3b模型。框架要求该示例使用engine: huggingface_endpoint仅由 LangChain 框架提供。运行前必须设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain并安装pip install langchain langchain-community。config.yml中的parameters.model_kwargs块也是 LangChain 专属写法会被默认框架拒绝# examples/configs/llm/hf_endpoint/config.yml models: - type: main engine: huggingface_endpoint model: databricks/dolly-v2-3b parameters: endpoint_url: https://xxx.aws.endpoints.huggingface.cloud task: text2text-generation model_kwargs: temperature: 0.5 max_length: 64 # 此温度将用于需要确定性行为的任务。 # dolly-v2-3b 要求严格为正数。 lowest_temperature: 0.1使用步骤先按 HuggingFace 的端点创建指南创建 Endpoint然后把config.yml中的endpoint_url更新为实际地址。示例附带的最小 Colang 对话流位于 rails.co仅包含express greeting问候与ask capabilities能力询问两条 user intent 及对应 flow。DefaultFramework 替代方案HuggingFace Inference Endpoints 可使用 Text Generation InferenceTGI部署TGI 可选地暴露 OpenAI 兼容的/v1/chat/completions路由。如果你的端点提供该路由可留在 DefaultFramework 上用engine: openai 规范的base_url接入无需 LangChainmodels: - type: main engine: openai model: tgi parameters: base_url: https://xxx.aws.endpoints.huggingface.cloud/v1对于标准的text-generation-inferenceschema无/v1/chat/completions路由则仍需按上述方式使用 LangChain 框架。免责声明dolly-v2-3b仅在基础用例如问候、识别特定问题上测试过面对更复杂的查询该模型可能无法正常工作。生产部署前需要充分的测试与优化。Vertex AILangChain 框架下的 Gemini 接入vertexai/ 展示了使用 Vertex AI API 的基础 guardrails 配置同样可自由扩展。框架要求engine: vertexai仅由 LangChain 框架提供。需设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain并安装pip install langchain langchain-google-vertexai此外还需安装pip install google-cloud-aiplatform1.38.0。调用 Vertex AI API 前需要先完成 Google Cloud 的初始化设置认证、项目配置等。# examples/configs/llm/vertexai/config.yml models: - type: main engine: vertexai model: gemini-1.0-pro rails: input: flows: - self check input output: flows: - self check output注意两点其一示例中的gemini-1.0-pro是为了与历史配置保持连续性建议根据当前项目把model:更新为受支持的 Gemini 模型例如gemini-2.5-flash或gemini-2.5-pro——Vertex AI 的模型目录更新频繁旧模型 ID 可能停止接受请求其二该示例仅在基础用例上测试过复杂查询下的行为取决于所选 Vertex AI 模型可能与 guardrails 流中的断言不符。特别是 self-check 流的提示词假定了特定的响应风格生产部署前必须充分测试与调优不同代际 Vertex AI 模型的提供方内容审核行为也有差异可能以瞬时错误形式出现生产代码路径应优雅处理这些错误。示例还包含 prompts.yml 与 rails.co后者定义了express greeting、ask capabilities两个 intent 与对应 flow和 hf_endpoint 示例结构一致。本地开源模型HuggingFace Pipeline 系列的自定义 Provider目录中最大的一个子族是hf_pipeline_*系列它们展示如何通过自定义注册的 LangChain LLM provider 加载本地/社区开源模型。这些示例都要求 LangChain 框架统一模式为在config.py中用HuggingFacePipelineCompatible包装 transformers pipeline用get_llm_instance_wrapper生成 provider 包装器通过register_llm_provider(hf_pipeline_xxx, provider)注册到框架该 API 在 nemoguardrails/llm/providers/init.py#L38-L50 中实现注意其已标记为弃用0.23.0 将移除应改用register_provider或register_chat_provider在config.yml中声明engine: hf_pipeline_xxx。运行这些示例前需要安装pip install langchain langchain-community transformers torch并设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain。Dolly最小配置 流式输出支持examples/configs/llm/hf_pipeline_dolly 使用databricks/dolly-v2-3b并演示了 HuggingFacePipeline 部署下如何支持流式输出。config.yml中模型声明极简models: - type: main engine: hf_pipeline_dolly其config.py的核心逻辑examples/configs/llm/hf_pipeline_dolly/config.py#L24-L63展示了关键实现用AutoConfig.from_pretrained加载配置并设置init_device与max_seq_len当streamingTrue时创建AsyncTextIteratorStreamer(tokenizer, skip_promptTrue)并注入 pipeline 参数从而实现流式最终llm HuggingFacePipelineCompatible(pipelinepipe, model_kwargsparams)并用lru_cache缓存实例。示例config.yml还给出了完整的instructions、sample_conversation以及五个核心任务提示词general、generate_user_intent、generate_next_steps、generate_bot_message、generate_value与 nemoguardrails/llm/prompts/dolly.yml 保持一致。Falcon / Mosaic / Vicuna同类模式的不同细节hf_pipeline_falcon加载tiiuae/falcon-7b-instruct。config.py使用HuggingFacePipelineCompatible.from_model_id(model_idrepo_id, device0, tasktext-generation, model_kwargs{temperature: 0, max_length: 530, trust_remote_code: True, torch_dtype: bfloat16})。hf_pipeline_mosaic加载mosaicml/mpt-7b-instruct。其config.py注释说明了为什么要用from_pretrained而非from_model_id默认配置使用 CPU 且不可修改为使用 GPU 必须手动构建 config 并设置config.init_device cuda:0、config.max_seq_len 450同时 tokenizer 使用EleutherAI/gpt-neox-20b。hf_pipeline_vicuna加载lmsys/vicuna-7b-v1.3/lmsys/vicuna-13b-v1.3也支持 Bloke 变体TheBloke/wizard-vicuna-13B-HF等以及从本地路径加载 checkpointget_vicuna_13b_llm_from_path并封装了多 GPU 加载逻辑device_mapauto、按 GPU 数分配max_memory。这三个示例的config.yml结构几乎一致engine: hf_pipeline_name 通用instructionssample_conversation 完整 prompt 模板general/generate_user_intent/generate_next_steps/generate_bot_message/generate_value均指定output_parser: verbose_v1。注意 prompt 模板中的 Jinja 过滤器链如history | colang | verbose_v1、examples | remove_text_messages | verbose_v1是 NeMo Guardrails 提示词渲染体系的核心用法。Llama 2模型路径、多 GPU 与事实核查 railexamples/configs/llm/hf_pipeline_llama2 展示meta-llama/Llama-2-13b-chat-hf等 7B/13B 模型的加载并附带事实核查factcheckingrail 的完整示例是这一族中功能最完整的一个。使用前置条件使用社区模型如 llama2需要先在 HuggingFace 上申请 llama2 系列访问权限获得通用访问权限后仍需在具体模型页面如meta-llama/Llama-2-13b-chat-hf单独申请该模型的访问授权。运行前设置环境变量并安装依赖export HF_TOKENYour_HuggingFace_Access_Token pip install accelerate transformers4.33.1 sentencepiece --upgrade配置文件config.yml的关键点models: - type: main engine: hf_pipeline_llama2_13b parameters: path: meta-llama/Llama-2-13b-chat-hf # 你的 GPU 数量可用 nvidia-smi 查看 num_gpus: 2 # 可选 cpu 或 cudamps 不受支持 device: cuda rails: output: flows: - self check facts其config.py中的init_main_llm会从主模型配置读取path支持 HF repo id 或本地 checkpoint 路径、device默认cuda与num_gpus默认 1从HF_TOKEN环境变量读取认证令牌然后加载模型并注册hf_pipeline_llama2_13bprovider。rails 侧配套两个 Colang 文件rails/general.co定义问候、能力询问、知识库询问、一般性问题等 intent 与 flow和 rails/factcheck.co定义answer report question流程并通过$check_facts True触发事实核查。config.yml末尾还给出了self_check_facts任务针对 llama2 指令格式的提示词模板SYS/[INST]包裹的蕴含判定任务。评估与免责声明meta-llama/Llama-2-13b-chat-hf已纳入 topical rails 评估集并取得良好结果factchecking rail 在同模型上也测试良好但该模型仅在结合知识库玩具示例的基础用法上测试过更复杂的查询需要进一步做提示词工程实验生产部署前需充分测试优化。提示词适配每个 engine 的专属 prompt 基线目录中多个示例的config.yml都注明以下提示词与nemoguardrails/llm/prompts/model.yml相同。仓库 nemoguardrails/llm/prompts 中确实按模型族维护了独立提示词文件如 dolly.yml、mosaic.yml、deepseek.yml、llama3.yml、openai.yml 等。这意味着更换 LLM 提供方时除models段外还应对齐该模型族的提示词风格例如 falcon 示例的generate_user_intent提示词比 dolly 多了 Your task is to generate the user intent... 的任务描述说明不同模型对提示词结构的敏感度不同。这在自托管开源模型上尤其重要——提示词与模型训练格式不匹配会直接导致 guardrails 推理质量下降。从示例到生产必须补齐的功课综合目录内所有 README可以总结出生产化前必须完成的四件事框架选择与依赖对齐先确认目标 engine 属于 DefaultFrameworkopenaibase_url的 OpenAI 兼容路线还是 LangChain 专属huggingface_endpoint、vertexai、use_responses_api、hf_pipeline_*并据此设置NEMOGUARDRAILS_LLM_FRAMEWORK与安装对应langchain-provider包。模型与端点的可用性验证如 Vertex AI 示例所述托管模型目录会轮换、旧 ID 可能失效如 Responses API 示例所述自托管服务器不一定实现/v1/responses。配置前先确认端点实际能力。提示词与 rails 的重新设计示例中的 guardrails 应用极简仅为验证连通性生产环境需要按真实业务重写 intent、flow、提示词与安全 rail并参考 nemoguardrails/evaluate/README.md 中的评估流程对 rails 做系统评估。错误处理与稳定性尤其是自托管模型与托管端点的瞬时错误如 Vertex AI 提供方侧的内容审核行为差异生产代码路径必须优雅处理。结语如何继续深入examples/configs/llm是 NeMo Guardrails 换模型只改配置能力的活教材托管 API 走 DefaultFramework 的 OpenAI 兼容路线即可本地开源模型走 LangChain 自定义 provider 注册路线。建议读者按如下顺序继续深入先读 examples/configs/llm/README.md 把握全局 → 对照本文逐个阅读子目录的config.yml与config.py→ 结合 nemoguardrails/llm/frameworks/registry.py 与 default.py 理解框架与默认端点解析 → 参考 nemoguardrails/llm/prompts 中的模型族提示词 → 最后用 nemoguardrails/evaluate/README.md 中的评估体系验证自己的 rails。如果你实现了新的 LLM 配置也欢迎按目录 README 的号召向社区提交 PR。赞分享人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载相关推荐NeMo Guardrails高级配置终极指南自定义LLM提供商与嵌入搜索方案详解NeMo Guardrails高级配置终极指南自定义LLM提供商与嵌入搜索方案详解 想要完全掌控LLM对话系统的行为吗NeMo Guardrails高级配置人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAGCoze Studio 低版本浏览器升级条幅组件 coze-foundation/browser-upgrade-banner 深度解析Coze Studio 低版本浏览器升级条幅组件 coze foundation/browser upgrade banner 深度解析 导读 coze f人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG如何为LLM应用配置多模态护栏NeMo Guardrails终极指南如何为LLM应用配置多模态护栏NeMo Guardrails终极指南 NeMo Guardrails是一款开源工具包专为LLM对话系统提供可编程护栏功能能人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG上一篇POCO多线程设计模式资源书籍与文章下一篇blessed兼容性与FAQ速查清单Windows支持、iTerm2竖线、鼠标255格限制等常见坑一次说清创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NeMo Guardrails 多 LLM 提供方配置实战：examples/configs/llm 全解析
人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载本文以 NeMo Guardrails 仓库中 examples/configs/llm 目录为线索系统梳理 DeepSeek R1、OpenAI Responses API、NVIDIA NIM、HuggingFace Inference Endpoints / Pipeline、Vertex AI 等十余种 LLM 提供方provider在 NeMo Guardrails 中的接入方式。读完本文你将掌握engine与NEMOGUARDRAILS_LLM_FRAMEWORK的框架选择机制、OpenAI 兼容端点的base_url路由技巧、自定义 HuggingFace Pipeline 提供方的注册流程以及每类配置对应的源码级实现细节可直接照搬示例完成自己的接入与验证。目录定位这些示例展示什么、不承诺什么examples/configs/llm/README.md明确说明该文件夹内的示例用于展示不同 LLM 提供方应该如何被配置。每个示例的 guardrails 配置都非常简单其唯一目的是验证 LLM 已被正确配置——这些配置不适用于生产部署生产环境必须基于真实业务场景重新设计 rails、提示词与安全策略。需要特别注意的是该目录中的部分示例如 dolly、falcon、mosaic、vicuna、llama2 等模型配置已被纳入 NeMo Guardrails 的 topical rails 评估集并在对应数据集上取得了良好结果评估详情可参考 nemoguardrails/evaluate/README.md。同时项目团队鼓励社区贡献如果你发现了改进 NeMo Guardrails 与常见 LLM 协作方式的机会欢迎提交 PR——LLM 专属配置正是参与社区的最佳切入点。先理解两个核心概念engine 与 LLM 框架阅读该目录前必须先区分两个容易混淆的概念1.engine引擎config.yml中models[].engine字段声明的提供方类型例如openai、nim、nvidia_ai_endpoints、vertexai、huggingface_endpoint、hf_pipeline_dolly等。engine 决定该模型请求由哪个底层客户端或 provider 处理。2. LLM 框架frameworkNeMo Guardrails 当前支持default默认框架与langchain两种框架通过环境变量NEMOGUARDRAILS_LLM_FRAMEWORK选择。其默认值在源码 nemoguardrails/llm/frameworks/registry.py#L27 中定义_default_framework: str os.environ.get(NEMOGUARDRAILS_LLM_FRAMEWORK, default)框架的懒加载与注册逻辑同样位于 registry.py#L61-L74当请求langchain时会导入nemoguardrails.integrations.langchain.llm_adapter.LangChainFramework请求default时则导入nemoguardrails.llm.frameworks.default.DefaultFramework。关键结论贯穿整个目录的分水岭DefaultFramework默认自带 OpenAI 兼容 HTTP 客户端只调用/v1/chat/completions无需 LangChain 依赖。任何 OpenAI 兼容端点engine: openaiparameters.base_url都可直接接入。LangChain 框架NEMOGUARDRAILS_LLM_FRAMEWORKlangchain通过langchain-provider生态提供huggingface_endpoint、vertexai、use_responses_api等 DefaultFramework 不支持的专属能力。这一选择直接决定了目录中每个示例的可用性下文每个示例都会明确标注其框架要求。OpenAI 兼容端点DefaultFramework 的通用接入范式DefaultFramework 对 provider 有内置的默认base_url与 API Key 环境变量映射见源码 nemoguardrails/llm/frameworks/default.py#L28-L41_DEFAULT_BASE_URLS: Dict[str, str] { openai: https://api.openai.com/v1, nim: https://integrate.api.nvidia.com/v1, nvidia_ai_endpoints: https://integrate.api.nvidia.com/v1, ollama: http://localhost:11434/v1, } _API_KEY_ENV_VARS: Dict[str, str] { openai: OPENAI_API_KEY, nim: NVIDIA_API_KEY, nvidia_ai_endpoints: NVIDIA_API_KEY, ... }当 engine 不在内置映射中如deepseek时default.py#L46-L55 的_resolve_base_url会抛出错误提示你如果端点 OpenAI 兼容请设置parameters.base_url否则请切到 LangChain 框架。这正是目录中多个示例的接入思路。DeepSeek R1一个典型的 OpenAI 兼容接入examples/configs/llm/deepseek-r1/ 展示如何调用 DeepSeek 托管的 R1 推理模型deepseek-reasoner。DeepSeek 的官方 APIhttps://api.deepseek.com/v1与 OpenAI 兼容因此使用 DefaultFramework 的engine: openaiparameters.base_url即可路由到内置的 OpenAI 兼容客户端无需任何 LangChain 依赖。# examples/configs/llm/deepseek-r1/config.yml models: - type: main engine: openai model: deepseek-reasoner api_key_env_var: DEEPSEEK_API_KEY parameters: base_url: https://api.deepseek.com/v1运行前只需设置环境变量export DEEPSEEK_API_KEYsk-...注意api_key_env_var: DEEPSEEK_API_KEY显式指定了 API Key 的来源环境变量默认框架内置映射中没有deepseek因此必须显式给出。该示例还提供了两条可选路径NVIDIA NIM 替代方案DeepSeek R1 权重也可通过 NVIDIA NIM 托管端点获取将模型条目替换为nim引擎与规范的 NIM 模型 IDmodels: - type: main engine: nim model: deepseek-ai/deepseek-r1LangChain 回退方案若偏好使用 LangChain 的langchain-deepseek适配器例如想利用 LangChain 专属特性则设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain、安装pip install langchain langchain-deepseek并在config.yml中使用engine: deepseek。README 明确建议新部署优先走上述 DefaultFramework 路径。OpenAI Responses API切换端点与工具调用的边界examples/configs/llm/openai-responses-api/ 展示如何将 OpenAI 模型路由到 Responses API/v1/responses而非 Chat Completions。该示例必须使用 LangChain 框架DefaultFramework 的 OpenAI 兼容客户端只调用/v1/chat/completions而langchain_openai.ChatOpenAI类支持use_responses_api参数。# examples/configs/llm/openai-responses-api/config.yml models: - type: main engine: openai model: gpt-5-pro parameters: # 将调用路由到 OpenAI 的 /v1/responses 端点而不是 /v1/chat/completions。 # 仅在 LangChain 框架NEMOGUARDRAILS_LLM_FRAMEWORKlangchain下生效参见 README.md。 use_responses_api: true运行前置条件export NEMOGUARDRAILS_LLM_FRAMEWORKlangchain pip install langchain langchain-openai export OPENAI_API_KEYsk-...重要警示如果没有设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain库会把use_responses_api当作未知字段转发给/v1/chat/completions调用并不会真正切换到 Responses API。自托管模型vLLM 及其他 OpenAI 兼容服务器部分推理服务器如 vLLM除/v1/chat/completions外还暴露 OpenAI 兼容的/v1/responses端点。此时可保持engine: openai、设置use_responses_api: true并把base_url指向自己的服务器models: - type: main engine: openai model: openai/gpt-oss-20b api_key_env_var: ANY_KEY_CAN_BE_USED_HERE parameters: base_url: http://localhost:8000/v1 use_responses_api: true该配置仍需NEMOGUARDRAILS_LLM_FRAMEWORKlangchain因为切换开关由langchain_openai.ChatOpenAI提供。启用前务必确认你的服务器实现了/v1/responses——并非所有 OpenAI 兼容服务器都支持。工具调用仅透传函数工具调用可在 Responses API 上以流式和非流式两种模式工作。适配器会将助手的工具调用呈现在LLMResponse.tool_calls与LLMResponseChunk.delta_tool_calls上并将finish_reason报告为tool_calls。但 Responses API 内置工具如web_search、file_search、code_interpreter、computer_use、MCP、图像生成不会被呈现为工具调用——API 将这些工具作为 response output items 返回而非函数调用因此目前仅支持函数工具透传。NVIDIA NIM 与 NVIDIA AI Endpoints零配置的托管端点目录中的 llama-3/ 与 nim/ 两个示例展示了 NVIDIA 生态的两种接入方式。NVIDIA AI Endpointsnvidia_ai_endpoints引擎——llama-3/config.ymlmodels: - type: main engine: nvidia_ai_endpoints model: meta/llama-3.1-70b-instructNVIDIA NIMnim引擎——nim/config.ymlmodels: - type: main engine: nim model: meta/llama3-8b-instruct parameters: base_url: http://localhost:7331/v1从源码 default.py#L30-L31 可以看到nim与nvidia_ai_endpoints的默认 base_url 均为https://integrate.api.nvidia.com/v1API Key 均取自NVIDIA_API_KEY环境变量nim示例通过覆盖parameters.base_url指向本地自托管 NIM 服务http://localhost:7331/v1。在 LangChain 框架中两者统一映射到_init_nvidia_model初始化逻辑见 nemoguardrails/integrations/langchain/langchain_initializer.py#L349-L350。此外 nemoguardrails/llm/models/openai_chat.py#L35 会把https://integrate.api.nvidia.com/v1识别为nim引擎说明模型请求路径与引擎名存在双向关联。HuggingFace Inference EndpointsLangChain 专属与 TGI 替代hf_endpoint/ 示例使用 HuggingFace Inference Endpoints 服务例如databricks/dolly-v2-3b模型。框架要求该示例使用engine: huggingface_endpoint仅由 LangChain 框架提供。运行前必须设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain并安装pip install langchain langchain-community。config.yml中的parameters.model_kwargs块也是 LangChain 专属写法会被默认框架拒绝# examples/configs/llm/hf_endpoint/config.yml models: - type: main engine: huggingface_endpoint model: databricks/dolly-v2-3b parameters: endpoint_url: https://xxx.aws.endpoints.huggingface.cloud task: text2text-generation model_kwargs: temperature: 0.5 max_length: 64 # 此温度将用于需要确定性行为的任务。 # dolly-v2-3b 要求严格为正数。 lowest_temperature: 0.1使用步骤先按 HuggingFace 的端点创建指南创建 Endpoint然后把config.yml中的endpoint_url更新为实际地址。示例附带的最小 Colang 对话流位于 rails.co仅包含express greeting问候与ask capabilities能力询问两条 user intent 及对应 flow。DefaultFramework 替代方案HuggingFace Inference Endpoints 可使用 Text Generation InferenceTGI部署TGI 可选地暴露 OpenAI 兼容的/v1/chat/completions路由。如果你的端点提供该路由可留在 DefaultFramework 上用engine: openai 规范的base_url接入无需 LangChainmodels: - type: main engine: openai model: tgi parameters: base_url: https://xxx.aws.endpoints.huggingface.cloud/v1对于标准的text-generation-inferenceschema无/v1/chat/completions路由则仍需按上述方式使用 LangChain 框架。免责声明dolly-v2-3b仅在基础用例如问候、识别特定问题上测试过面对更复杂的查询该模型可能无法正常工作。生产部署前需要充分的测试与优化。Vertex AILangChain 框架下的 Gemini 接入vertexai/ 展示了使用 Vertex AI API 的基础 guardrails 配置同样可自由扩展。框架要求engine: vertexai仅由 LangChain 框架提供。需设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain并安装pip install langchain langchain-google-vertexai此外还需安装pip install google-cloud-aiplatform1.38.0。调用 Vertex AI API 前需要先完成 Google Cloud 的初始化设置认证、项目配置等。# examples/configs/llm/vertexai/config.yml models: - type: main engine: vertexai model: gemini-1.0-pro rails: input: flows: - self check input output: flows: - self check output注意两点其一示例中的gemini-1.0-pro是为了与历史配置保持连续性建议根据当前项目把model:更新为受支持的 Gemini 模型例如gemini-2.5-flash或gemini-2.5-pro——Vertex AI 的模型目录更新频繁旧模型 ID 可能停止接受请求其二该示例仅在基础用例上测试过复杂查询下的行为取决于所选 Vertex AI 模型可能与 guardrails 流中的断言不符。特别是 self-check 流的提示词假定了特定的响应风格生产部署前必须充分测试与调优不同代际 Vertex AI 模型的提供方内容审核行为也有差异可能以瞬时错误形式出现生产代码路径应优雅处理这些错误。示例还包含 prompts.yml 与 rails.co后者定义了express greeting、ask capabilities两个 intent 与对应 flow和 hf_endpoint 示例结构一致。本地开源模型HuggingFace Pipeline 系列的自定义 Provider目录中最大的一个子族是hf_pipeline_*系列它们展示如何通过自定义注册的 LangChain LLM provider 加载本地/社区开源模型。这些示例都要求 LangChain 框架统一模式为在config.py中用HuggingFacePipelineCompatible包装 transformers pipeline用get_llm_instance_wrapper生成 provider 包装器通过register_llm_provider(hf_pipeline_xxx, provider)注册到框架该 API 在 nemoguardrails/llm/providers/init.py#L38-L50 中实现注意其已标记为弃用0.23.0 将移除应改用register_provider或register_chat_provider在config.yml中声明engine: hf_pipeline_xxx。运行这些示例前需要安装pip install langchain langchain-community transformers torch并设置NEMOGUARDRAILS_LLM_FRAMEWORKlangchain。Dolly最小配置 流式输出支持examples/configs/llm/hf_pipeline_dolly 使用databricks/dolly-v2-3b并演示了 HuggingFacePipeline 部署下如何支持流式输出。config.yml中模型声明极简models: - type: main engine: hf_pipeline_dolly其config.py的核心逻辑examples/configs/llm/hf_pipeline_dolly/config.py#L24-L63展示了关键实现用AutoConfig.from_pretrained加载配置并设置init_device与max_seq_len当streamingTrue时创建AsyncTextIteratorStreamer(tokenizer, skip_promptTrue)并注入 pipeline 参数从而实现流式最终llm HuggingFacePipelineCompatible(pipelinepipe, model_kwargsparams)并用lru_cache缓存实例。示例config.yml还给出了完整的instructions、sample_conversation以及五个核心任务提示词general、generate_user_intent、generate_next_steps、generate_bot_message、generate_value与 nemoguardrails/llm/prompts/dolly.yml 保持一致。Falcon / Mosaic / Vicuna同类模式的不同细节hf_pipeline_falcon加载tiiuae/falcon-7b-instruct。config.py使用HuggingFacePipelineCompatible.from_model_id(model_idrepo_id, device0, tasktext-generation, model_kwargs{temperature: 0, max_length: 530, trust_remote_code: True, torch_dtype: bfloat16})。hf_pipeline_mosaic加载mosaicml/mpt-7b-instruct。其config.py注释说明了为什么要用from_pretrained而非from_model_id默认配置使用 CPU 且不可修改为使用 GPU 必须手动构建 config 并设置config.init_device cuda:0、config.max_seq_len 450同时 tokenizer 使用EleutherAI/gpt-neox-20b。hf_pipeline_vicuna加载lmsys/vicuna-7b-v1.3/lmsys/vicuna-13b-v1.3也支持 Bloke 变体TheBloke/wizard-vicuna-13B-HF等以及从本地路径加载 checkpointget_vicuna_13b_llm_from_path并封装了多 GPU 加载逻辑device_mapauto、按 GPU 数分配max_memory。这三个示例的config.yml结构几乎一致engine: hf_pipeline_name 通用instructionssample_conversation 完整 prompt 模板general/generate_user_intent/generate_next_steps/generate_bot_message/generate_value均指定output_parser: verbose_v1。注意 prompt 模板中的 Jinja 过滤器链如history | colang | verbose_v1、examples | remove_text_messages | verbose_v1是 NeMo Guardrails 提示词渲染体系的核心用法。Llama 2模型路径、多 GPU 与事实核查 railexamples/configs/llm/hf_pipeline_llama2 展示meta-llama/Llama-2-13b-chat-hf等 7B/13B 模型的加载并附带事实核查factcheckingrail 的完整示例是这一族中功能最完整的一个。使用前置条件使用社区模型如 llama2需要先在 HuggingFace 上申请 llama2 系列访问权限获得通用访问权限后仍需在具体模型页面如meta-llama/Llama-2-13b-chat-hf单独申请该模型的访问授权。运行前设置环境变量并安装依赖export HF_TOKENYour_HuggingFace_Access_Token pip install accelerate transformers4.33.1 sentencepiece --upgrade配置文件config.yml的关键点models: - type: main engine: hf_pipeline_llama2_13b parameters: path: meta-llama/Llama-2-13b-chat-hf # 你的 GPU 数量可用 nvidia-smi 查看 num_gpus: 2 # 可选 cpu 或 cudamps 不受支持 device: cuda rails: output: flows: - self check facts其config.py中的init_main_llm会从主模型配置读取path支持 HF repo id 或本地 checkpoint 路径、device默认cuda与num_gpus默认 1从HF_TOKEN环境变量读取认证令牌然后加载模型并注册hf_pipeline_llama2_13bprovider。rails 侧配套两个 Colang 文件rails/general.co定义问候、能力询问、知识库询问、一般性问题等 intent 与 flow和 rails/factcheck.co定义answer report question流程并通过$check_facts True触发事实核查。config.yml末尾还给出了self_check_facts任务针对 llama2 指令格式的提示词模板SYS/[INST]包裹的蕴含判定任务。评估与免责声明meta-llama/Llama-2-13b-chat-hf已纳入 topical rails 评估集并取得良好结果factchecking rail 在同模型上也测试良好但该模型仅在结合知识库玩具示例的基础用法上测试过更复杂的查询需要进一步做提示词工程实验生产部署前需充分测试优化。提示词适配每个 engine 的专属 prompt 基线目录中多个示例的config.yml都注明以下提示词与nemoguardrails/llm/prompts/model.yml相同。仓库 nemoguardrails/llm/prompts 中确实按模型族维护了独立提示词文件如 dolly.yml、mosaic.yml、deepseek.yml、llama3.yml、openai.yml 等。这意味着更换 LLM 提供方时除models段外还应对齐该模型族的提示词风格例如 falcon 示例的generate_user_intent提示词比 dolly 多了 Your task is to generate the user intent... 的任务描述说明不同模型对提示词结构的敏感度不同。这在自托管开源模型上尤其重要——提示词与模型训练格式不匹配会直接导致 guardrails 推理质量下降。从示例到生产必须补齐的功课综合目录内所有 README可以总结出生产化前必须完成的四件事框架选择与依赖对齐先确认目标 engine 属于 DefaultFrameworkopenaibase_url的 OpenAI 兼容路线还是 LangChain 专属huggingface_endpoint、vertexai、use_responses_api、hf_pipeline_*并据此设置NEMOGUARDRAILS_LLM_FRAMEWORK与安装对应langchain-provider包。模型与端点的可用性验证如 Vertex AI 示例所述托管模型目录会轮换、旧 ID 可能失效如 Responses API 示例所述自托管服务器不一定实现/v1/responses。配置前先确认端点实际能力。提示词与 rails 的重新设计示例中的 guardrails 应用极简仅为验证连通性生产环境需要按真实业务重写 intent、flow、提示词与安全 rail并参考 nemoguardrails/evaluate/README.md 中的评估流程对 rails 做系统评估。错误处理与稳定性尤其是自托管模型与托管端点的瞬时错误如 Vertex AI 提供方侧的内容审核行为差异生产代码路径必须优雅处理。结语如何继续深入examples/configs/llm是 NeMo Guardrails 换模型只改配置能力的活教材托管 API 走 DefaultFramework 的 OpenAI 兼容路线即可本地开源模型走 LangChain 自定义 provider 注册路线。建议读者按如下顺序继续深入先读 examples/configs/llm/README.md 把握全局 → 对照本文逐个阅读子目录的config.yml与config.py→ 结合 nemoguardrails/llm/frameworks/registry.py 与 default.py 理解框架与默认端点解析 → 参考 nemoguardrails/llm/prompts 中的模型族提示词 → 最后用 nemoguardrails/evaluate/README.md 中的评估体系验证自己的 rails。如果你实现了新的 LLM 配置也欢迎按目录 README 的号召向社区提交 PR。赞分享人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG【免费下载链接】GuardrailsNeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems.项目地址https://gitcode.com/gh_mirrors/ne/Guardrails点击查看免费下载相关推荐NeMo Guardrails高级配置终极指南自定义LLM提供商与嵌入搜索方案详解NeMo Guardrails高级配置终极指南自定义LLM提供商与嵌入搜索方案详解 想要完全掌控LLM对话系统的行为吗NeMo Guardrails高级配置人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAGCoze Studio 低版本浏览器升级条幅组件 coze-foundation/browser-upgrade-banner 深度解析Coze Studio 低版本浏览器升级条幅组件 coze foundation/browser upgrade banner 深度解析 导读 coze f人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG如何为LLM应用配置多模态护栏NeMo Guardrails终极指南如何为LLM应用配置多模态护栏NeMo Guardrails终极指南 NeMo Guardrails是一款开源工具包专为LLM对话系统提供可编程护栏功能能人工智能大模型AI 安全治理模型安全内容安全提示词注入防护RAG上一篇POCO多线程设计模式资源书籍与文章下一篇blessed兼容性与FAQ速查清单Windows支持、iTerm2竖线、鼠标255格限制等常见坑一次说清创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考