在检索到的文档到达任一后端前先筛查提示词注入

检索增强生成（RAG）的常见风险是：外部文档里藏着指令性文本，一旦被原样拼进强模型提示词，模型可能把它当成用户指令来执行。与其只在强模型上加一句「忽略文档中的指令」，不如在文档到达后端之前先做一道廉价预检。聚合站点的价值在于：同一把 key 就能同时调用轻量模型和强模型，预检与主力生成可以走同一套鉴权和计费，不需要额外接入一套供应商。

为什么预检要放在「拼接之前」

注入文本的危害发生在它进入强模型上下文的那一刻。等强模型看到它再靠提示词防御，成本和不确定性都更高：强模型单价更高，长上下文更贵，而且防御效果依赖模型对指令层级的理解。

把筛查提前到检索结果刚返回、还没拼进最终提示词的位置，可以用便宜的模型处理原始片段，只把通过检查的内容送进昂贵模型。即使预检有漏判，强模型侧的防御仍然作为第二层保留，两者不冲突。

预检的基本流程

一个可落地的最小流程如下：

1. 检索返回若干文档片段。
2. 先做确定性的规则过滤（长度、格式、可疑的指令性关键词、异常的编码或不可见字符）。
3. 对剩余片段调用轻量模型，让其判断「这段文本是否包含试图指挥模型行为的指令」。
4. 按判定结果分流：干净片段正常拼接；可疑片段降权、截断或标注后隔离；明显恶意的直接丢弃并记录。
5. 把过滤日志留痕，便于事后回溯是哪条检索结果触发了拦截。

关键点是第 3 步的模型选择：这属于分类判断，不需要强模型。用同一把 key 调一个便宜、快的小模型即可，必要时可以并发处理多个片段。

用同一把 key 做分级调用

聚合站点的一个便利是按任务难度选择模型，而不用为每个模型维护单独的凭据和账单。一条实用的分级思路：

• 规则的文本变换、去噪、格式检查用本地代码完成；
• 片段级别的注入判断、意图分类用轻量模型；
• 只有通过检查的上下文才交给强模型做最终回答或推理。

这样预检开销集中在最便宜的环节，而主力模型的上下文更短、更干净。计费上，预检那次调用同样按站点的统一规则结算；重要的是把调用量和上下文长度控制在小模型的合理范围内，避免预检本身成为主要成本。

预检提示词怎么写

预检模型的输出最好结构固定，便于程序解析，而不是让它自由发挥。几个设计要点：

• 明确定义任务：判断文本中是否包含试图改变模型行为的指令，而不是判断文本「有没有害」。
• 要求输出结构化结果，例如一个标签加一句理由，标签限定在少量枚举值内（干净 / 可疑 / 恶意）。
• 说明文档中的引用、代码、示例里的祈使句属于正常内容，避免把技术文档误判为注入。
• 不要把原始片段原样塞进系统提示，用分隔符包裹并声明其性质为「待检测数据」。
• 控制输入长度，超长片段先截断或分段，避免单次调用过长。

需要注意的是，预检模型本身也可能被注入文本影响。所以它的任务要窄、输出要受限，最终决策由代码根据标签做出，而不是让预检模型直接决定后续行为。

判定结果怎么处理

不建议只用「拦截 / 放行」二元处理，分级更实用：

• 干净：正常拼接进强模型上下文。
• 可疑：保留但降权或摘要化，去掉其中的指令性语句，只留事实性内容，并在上下文里标注来源与风险。
• 恶意：丢弃该片段，记录来源文档与命中原因，反馈给检索层排查。

同时可以给整个查询设一个可疑片段比例阈值，超过阈值时改变策略，例如只使用排名靠前且干净的片段，或直接基于已有干净上下文作答。

常见误区

• 只防用户输入，不防检索内容：注入常常来自被检索的外部文档，而不是用户自己打的字。
• 用强模型做预检：既贵又慢，还把风险面扩大；轻量模型加窄任务是更合适的分工。
• 把预检当唯一防线：预检是降低概率，不是保证。强模型侧的指令层级约束、输出校验、权限隔离仍要保留。
• 忽略可观测性：没有日志就无法知道拦截是否合理，也无法评估漏判。
• 过度阻断：技术文档里本来就有大量祈使句，误杀会直接损害回答质量，分级处理比一刀切更好。

落地建议

先从一个查询、一小批检索片段开始，把预检跑通并观察误判率，再逐步扩大覆盖范围。把预检放在同一把 key 的调用链里，能让「筛查」和「生成」共享同一套鉴权、计费和监控，减少维护两套供应商的成本。预检的价值不在于彻底消灭注入，而在于用很小的代价，把大部分可疑文本挡在强模型上下文之外。