先厘清概念
意图识别:判断用户想问什么、该不该走知识库检索、要不要拒绝、要不要走业务接口
围栏(Guardrail,护栏 / 边界管控):拦截越界问题,防止 RAG“答非所问、越权回答、幻觉、跑出知识库范围、违规内容”,分为前置围栏、检索围栏、生成围栏、后置围栏。
RAG 里的意图识别核心目标不是分类闲聊,而是决策路由:
路由分支:
1️⃣ 查询知识库 (RAG)|2️⃣ 调用工具 / 业务 API|3️⃣ 闲聊,不走知识库|4️⃣ 拒绝回答
用户 query → 发给一个轻量 LLM(也可以用主模型),输出结构化 JSON 意图结果。
{
"intent_type": "rag_query|chat|api_call|reject",
"topic": "产品售后问题",
"need_retrieval": true,
"retrieval_filter": {"product_id":"A001"},
"confidence": 0.95,
"reason": "用户询问售后保修政策,知识库包含该内容"
}
表格
intent_type | 含义 | 路由动作 |
|---|---|---|
rag_query | 知识库问题 | 进入向量检索→召回文档→生成答案 |
chat | 闲聊、问候、情绪对话 | 直接模型回答,跳过检索 |
api_call | 需要实时数据(订单、余额) | 调用后端接口,不走知识库 |
reject | 违规、超出业务范围 | 直接拒绝,不走 RAG |
优点:开发快、不用标注样本;缺点:高并发成本高、偶发不稳定。适合中小项目。
你是RAG路由意图分类器。
任务:判断用户问题是否属于本企业知识库可回答范围。
知识库范围:公司产品手册、售后政策、收费标准、常见问题。
禁止回答:时政、娱乐、无关闲聊、内部未公开数据。
输出严格返回JSON,不要多余文字:
{
"intent_type": "rag_query/chat/api_call/reject",
"need_retrieval": true/false,
"confidence":0~1小数,
"reason":"简短理由"
}
用文本分类模型:BERT/ERNIE、text‑cnn,做二分类 / 多分类
是否需要检索知识库(0/1)知识库问题 / 闲聊 / 实时查询 / 违规问题
优点:速度快、成本低、延迟稳定;缺点:需要标注数据集。
适合高流量线上生产环境。
适合简单场景:黑名单词、触发词
例:命中【订单号】→路由 API;命中【你好、谢谢】→闲聊。
一般只做第一层前置过滤,不能单独当意图识别。
计算用户 query 和 知识库文档标题 / 问题库的向量相似度。
缺点:容易误判;适合和意图模型配合使用,不能单独作为围栏。
用户 Query
→1. 规则黑名单过滤(前置围栏)
→2. 意图识别(LLM / 小分类模型)
→3. 路由:
・reject →拒绝
・chat →直接回答
・api_call →调用接口
・rag_query →向量检索→重排→围栏校验→生成答案
围栏本质:把回答锁死在知识库边界,防止越界、幻觉、违规、泄露
四层围栏:前置围栏、检索围栏、生成围栏、后置围栏
目标:拦截坏问题,还没走检索就拒绝 执行时机:意图识别之前。
管控内容:
实现方式:
示例护栏 Prompt
如果用户问题不在【XX产品知识库】范围内,直接回复:
"抱歉,我无法回答该问题,请咨询产品相关问题。"
禁止编造知识库不存在的内容。
RAG 最常见坑:召回无关文档,然后模型顺着无关文档胡说;或者召回不到内容,模型凭空幻觉。 检索围栏 = 管控召回质量,只允许召回匹配的内容。
例:相似度 < 0.75,判定【知识库无相关资料】,放弃检索,直接返回无答案,禁止大模型编造