用大模型做文档敏感判断:RAG工程化的几个坑

用大模型做文档敏感判断：RAG工程化的几个坑

引言

最近看到一个实践分享挺有意思：有人用大模型做文档敏感判断——识别公开社区里泄露的项目文档和述职报告。技术栈很朴素，老Mac上装ollama跑Deepseek r1 1.5b，向量模型用nomic-embed-text，框架选了langchain。

跑通原型不算难，难的是RAG这个环节的工程细节。原型能跑，跟跑得可靠，中间隔着一堆边界问题。

文档敏感检测拆开看有两层。

第一层是分类——这篇文档包不包含不该公开的内容。项目文档、述职报告、内部数据，都属于敏感范畴。难点在于"敏感"的边界是模糊的，不像关键词匹配那样有明确规则。

第二层是上下文关联。单看一段话可能没问题，但放到特定场景下就敏感了。比如某个内部项目代号，单独出现就是一个词，但如果能关联到具体业务线，性质就变了。

这种模糊判断恰好是大模型擅长的。但问题来了：怎么让模型"知道"什么是敏感的？

敏感判断的两层逻辑：分类层与上下文关联层

最直接的办法，是把历史标记过的敏感文档喂给模型做参考——RAG 在这儿派上用场。

RAG敏感判断流程：从文档输入到结构化输出

1.5b参数的模型跑敏感判断，听起来像开玩笑。但实际跑下来，表现比预期好。

道理不复杂。敏感判断本质是分类任务，不是生成任务。模型不需要写出优美文章，只需要判断"是"或"否"再给个理由。分类任务输出空间小，容错率高，对小模型更友好。

这里有个选型上的判断：判断类任务，小模型可以撑住；生成类任务，别勉强。硬件预算有限时，把资源花在刀刃上。

原型第一版跑通后，第二次执行新任务，检索回来的内容是上一轮的旧数据。

这不是bug，是RAG工程里最常见的坑。根源在向量库的生命周期管理。

langchain默认的内存向量库在进程内是持久的。同一个脚本里连续跑多个任务，上一轮写入的向量不会被自动清除。新一轮检索时，top-k结果里混入旧任务的文档片段，模型拿到的上下文就是错的——你问它A文档是否敏感，它参考的却是B文档的内容。

关键要想清楚一件事：你的RAG是"全局知识库"还是"任务级上下文"。

敏感判断这个场景，每次判断应该是独立的。拿当前待判断的文档，加上预设的敏感特征描述，去检索匹配。不是"参考之前所有判断过的文档"。

正确的做法是每次任务开始前清空向量库，或者用独立的collection隔离不同任务。后者更好——每个判断任务创建一个临时collection，任务结束后销毁。既避免交叉污染，又保留了同一任务内的多次检索能力。

RAG上下文管理对比：全局混用 vs 任务级隔离

1.5b模型跑分类还行，但有个毛病：太自信了。

不管给它什么内容，它都倾向于给出明确判断。哪怕输入完全无关的内容，也会努力"分析"出点敏感特征来。大参数模型在不确定时更倾向于说"无法判断"，小模型倾向于强行给答案。

工程上的应对是加一层置信度过滤。让模型输出结构化结果，比如{"sensitive": true, "confidence": 0.7, "reason": "..."}，低于阈值的转人工复核。

这层逻辑加完后，系统才真正可用。模型不是替代人工，是把人工从"看全部"变成"看可疑的"。准确率不够100%没关系，只要召回率够高、误报率可控，就能大幅减少人工工作量。

用大模型做自动化判断，文档敏感检测只是其中一个方向。英伟达开源的Garak走了另一条路——评估大模型本身的脆弱性。

Garak定义自己为"生成式AI红队和评估套件"。原理是：内置一批精心设计的prompt作为payload，自动发送给目标模型，然后检查模型回复是否命中预设的漏洞规则。比如是否会泄露训练数据、是否会被prompt injection绕过安全限制、是否生成有害内容。

这两个场景底层逻辑其实一样：用自动化方式做批量判断。一个判断文档是否敏感，一个判断模型是否安全。区别在评估对象不同，但工程模式高度相似——都需要设计评估标准、管理测试用例隔离、做置信度兜底。

一个场景想通了，迁移到另一个并不费劲。

跑完这轮原型，总结几条给同样在摸索的同行。

小模型够不够用，看任务类型。分类、抽取这类输出空间小的任务，1.5b级别的模型可以跑。生成类任务对模型能力要求高，别图省事。

RAG用之前想清楚检索边界。全局知识库和任务级上下文是两种用法，混在一起就是坑。任务隔离是必须的，不管你用清空还是独立collection。

别指望模型自己知道什么时候不该回答。置信度过滤这一层工程上一定要加，没有它系统就不算"可用"。

自动化评估的思路是通用的。文档敏感判断和模型脆弱性扫描，底层都是"用规则或模型做批量判断"的模式。一个场景想通，迁移不难。

用大模型做文档敏感判断，技术上不难，难在工程化。原型跑通可能只需要一个下午，但把RAG隔离、置信度兜底、误报处理这些细节补上，花的时间远多于写第一版代码。

AI工程实践的现状就是这样：模型能力已经不是瓶颈，工程化才是。把"能跑的原型"变成"可用的系统"，中间隔着的全是细节。