版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。

一、向量库不是另一个网盘，它是第二次留存

1.1 一份工单在系统里存了几遍

先解释两个词。

向量库（vector store）把每段文字压成一串数字、按「数字像不像」找段落，只保留数字和一小段元数据（metadata，跟着切片走的标签，如来源文件、部门、密级）。切片（chunk）是它的最小单位：长文档按长度切开，每小段单独算一个向量，八千字的制度按五百字切就是十几条。

同一句话上线后通常存在于四个位置：原始文件、切片文本、向量、检索日志。向量能反查出切片，而切片就是原文的一部分；日志则常常把命中内容整段落盘。

1.2 删掉原文，为什么不等于删干净

全文的判断都从这里出发：向量库是一次二次留存，同一个事实在库里存了不止一份，还被切成了碎片。

删文件只动了第一行。切片文本、向量、日志都还在。更麻烦的是，切片把一句话拆开之后，「这条切片属于哪份文件」只能靠元数据指认；元数据一旦在搬运、转格式中被覆盖或丢失，这些切片就成了孤儿——你知道库里有东西，但说不清它是谁。

1.3 一条能当场用的判据

别问「我们的知识库合规吗」，没人答得上来。换个问法：

现在给我一个员工姓名，十分钟内能不能数清这个名字在这套系统里一共存在于几个地方？

数得清，说明删除链路是通的；数不清，说明连「删什么」都没定义。它不依赖法务词汇，只依赖你对自己系统的了解。

二、准入分流：四类语料，四种落库方式

2.1 判定顺序比分类本身更重要

「合规」在工程上要翻译成一句可执行的话：这份材料凭什么可以被处理。

《中华人民共和国个人信息保护法》（自 2021 年 11 月 1 日起施行）第十三条列了七项合法性基础，常用的是：取得个人同意；按依法制定的劳动规章制度实施人力资源管理所必需；在合理范围内处理合法公开的个人信息。除第一项外都不需另行取得同意，但「不需要同意」不等于「不需要告知」。

所以骨架不是「敏感不敏感」，而是「合法性基础在哪」。判定按固定顺序走，先过来源这道闸门：

1. 来源合法吗？追溯不到的，直接进第④类。
2. 触及敏感个人信息或第三方商业秘密？进第③类。
3. 能识别到具体个人？进第②类。
4. 都没有，才是第①类。

顺序反了会出事：一份「来源不明但不含个人信息」的会议纪要，若先判「有没有个人信息」，就会被判成第①类直接入库——它确实没有个人信息，但没有合法来源。

2.2 四类总表

分类分级的依据在《中华人民共和国数据安全法》（自 2021 年 9 月 1 日起施行）第二十一条：国家建立数据分类分级保护制度，按数据的重要程度和一旦遭到篡改、破坏、泄露后的危害程度分级保护。

2.3 一条来源不明的材料是怎么混进来的

最常见的入口不是恶意导入，是「顺手」：同事在群里转了一份离职交接材料，里面有客户对接人的电话；供应商把带报价的比价表发过来说「内部参考」。

共同点是：内容有用、格式干净、看上去就是文档。判定器第一步不看来源，它们全会被判成第①类。所以清单里的「来源」一列不能填「同事提供」，要填到具体系统、路径和授权文件编号。第④类的判定也要留痕：它是什么、为什么不能入库、谁判的——来源方补来授权时，你得知道当初卡在哪。

三、两头的边界：第①类和第④类最容易被判错

3.1 公开文档不等于可以随便入库

第①类的定义里有个陷阱：公开不等于可以任意使用。个人信息保护法第十三条第六项写的是「在合理的范围内」处理个人自行公开或其他合法公开的个人信息。这四个字意味着：一份公开发布的行业报告整篇入库做问答可以；把报告中受访者的姓名、职务、联系方式抽出来建成可检索的表，就越界了。

第十七条要求处理前以显著方式、清晰易懂的语言真实、准确、完整地告知目的、方式、种类和保存期限。注意「处理个人信息前」：员工工单进入问答系统的告知该发生在第一次导入之前，不是上线那天发个公告。

3.2 内部制度给全员问答，算不算人力资源管理所必需

这是我在项目里被问得最多、也最不该由工程师回答的问题。

第十三条第二项允许「按依法制定的劳动规章制度……实施人力资源管理所必需」的处理，员工手册、考勤制度给全员问答看起来很像这一项。但「所必需」门槛很高，而且它约束的是「处理个人信息」，不是「使用制度文本」：不含个人信息的制度本就不落入射程，走第①类；要论证的是带工号、带考核记录、带审批人姓名的材料。边界由法务判断，工程侧能做的是按「含不含个人信息」把材料拆开。

四、第②类：脱敏要按切片适配，不是按文档适配

4.1 实测：一句话被切成九个字加两个字

本机用一条人工构造的假工单做实测，七十六个字符：

工单 2026-0917 客户张某某反馈门禁卡失效，联系电话 13812345678，处理人工号 10237，现场核实后补办了新卡，客户要求周五前完成。

用langchain-text-splitters的RecursiveCharacterTextSplitter按字符硬切（separators里放空串），重叠取 0，扫了十四档长度：十六档切出 5 条、二十档 4 条、二十四档 4 条、四十八档 2 条。

十四档里有六档把手机号切断，一档把工号切断，而且和长度不成单调关系——把chunk_size调大不是解法。取 20 看具体切法：

# 摘自 work/2026-10-20_语料切片脱敏实测.py（本机实测）sp=RecursiveCharacterTextSplitter(chunk_size=20,chunk_overlap=0,separators=[""," ","\n"])chunks=sp.split_text(SAMPLE)# ['工单 2026-0917 客户张某某反馈',# '门禁卡失效，联系电话 138123456',# '78，处理人工号 10237，现场核实后',# '补办了新卡，客户要求周五前完成。']masked=[PHONE.sub("[手机号]",c)forcinchunks]# 逐块跑正则：仍命中完整号码的切片 = 0 条# 把切片里的数字拼起来：2026091713812345678# 其中含完整的 13812345678

问题就在这里。逐块脱敏的返回值是「没有命中」——不是报错，是一个看起来成功的零。但十一号码被切成九位加两位，散在相邻两条切片里，把同一来源的切片按顺序拼回去，号码就回来了。

4.2 overlap 让同一段文本存了不止一份

切片时通常会留一点重叠（chunk_overlap，让相邻切片共享一小段，避免语义在边界断掉）。重叠的代价是同一段文字被存多份：

原文七十六个字符，重叠开到 12，库里存了一百五十多个字符，翻了一倍——同一段话要删八次，漏一次等于没删。更隐蔽的是残留：重叠为 8 时，号码在一条切片里完整（会被正则打掉），在另两条里是残片（345678、3812345678，正则认不出）。一条号码，三种形态。

4.3 顺序：先整体脱敏，再切片

同一份语料、同一套正则、同一个chunk_size：顺序 A 先切片再逐块脱敏，命中数为 0，但把切片拼回去仍能读回完整号码；顺序 B 先整体脱敏再切片，各块都读不出连续数字，代价是切片数会变——chunk_size=24时从 4 条变成 3 条。

顺序 B 是正确做法，理由两条。一是正则的匹配单位必须是「完整字段」，而切片边界不受你控制；二是脱敏会改变长度，先脱敏再切边界才稳定，否则按脱敏前算出的偏移量全部失效。

还有一条容易被忽略：占位符要用定长的。[手机号]五个字符，换成更长的名字切片数就跟着变；定长才能让脱敏前后的边界一致，回滚和比对都方便。

4.4 三类正则兜不住的残留

正则只能处理格式固定的字段，下面三类它处理不了。

交叉指代：原文写「张某某」，下文全是「他」「该员工」，姓名打掉了，代词还在，配合部门和时间照样能定位到人。

上下文推断：工号打掉了，但「唯一一位 2026 年 3 月入职、负责华东区门禁系统的运维」本身就是标识符。

元数据：正文脱敏了，source字段还写着「张某某离职交接.docx」。这一类最容易在抽查里漏掉，因为大家只盯正文。

对应的动作不是「再写几条正则」，而是正文按字段脱敏、元数据按规则重写，再对切片做一次「拼回原文重检」的抽检。

五、第③类：什么时候必须停下来

5.1 五个触发条件

第③类的共同点是：不能靠工程手段自己解决，必须有另一个角色签字。

第一条的原文在第二十八条：敏感个人信息是一旦泄露或者非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息……只有在具有特定的目的和充分的必要性，并采取严格保护措施的情形下，方可处理。第二十九条要求处理敏感个人信息取得单独同意。

「单独同意」不能混在一份总协议里，也不能用一个「同意全部条款」的勾选框代替；具体怎么留证，要法务定。

5.2 影响评估写什么、存多久

第五十五条列了必须事前做个人信息保护影响评估的情形：处理敏感个人信息；利用个人信息做自动化决策；委托处理、向其他处理者提供、公开个人信息；向境外提供；其他有重大影响的活动。

第五十六条给出评估要写的内容：处理目的与方式是否合法正当必要；对个人权益的影响及安全风险；所采取的保护措施是否合法有效、是否与风险程度相适应。同条末款是硬要求——评估报告和处理情况记录应当至少保存三年。

三年意味着评估报告不是上线材料，是长期档案：换了切片策略或向量库产品、处理目的和方式实质变了，评估要重做，旧报告也不能删。

5.3 把切片交给第三方，等于交给另一个处理者

如果向量库用托管服务，或向量化（Embedding，把一段文字压成向量的那一步）走外部接口，含个人信息的切片就离开了你的机房，进入另一个主体。第二十三条要求：告知接收方的名称、联系方式、处理目的、方式和个人信息种类，并取得单独同意。

所以「用哪家的向量库」不是纯技术决策：自建要证明「我有能力管住」，托管要证明「我告知了、拿到同意，合同里约定了目的和范围」。

这份资料是什么：《大模型学习路线图》与 RAG（检索增强生成）落地阶段的资料索引，按「先理清数据边界、再动手搭检索」的顺序编排，和本章讲的语料边界正好对应。放在资料包里，扫码即可获取：

六、谁签字、留什么痕：三张清单

审查真正会看的不是架构图，是三张清单。它们不需要多复杂，但每一列都得能填。

6.1 入库清单：一批语料一行

《数据安全法》第二十七条要求建立全流程数据安全管理制度并组织教育培训，清单就是这条制度的落点。一条记录大概长这样：

batch_id:KB-2026-10-001# 批次号，删除和回滚都靠它corpus_name:门禁故障工单 2026 上半年source_system:ITSM 系统导出source_ref:/export/ticket/2026H1.csv# 追到具体路径，不写"同事提供"category:"2"# 1 可入 / 2 脱敏 / 3 单独授权 / 4 不入库basis:"个人信息保护法 13(2) 人力资源管理所必需"# 判定依据，写条文或授权函编号mask_rule_version:mask-v3# 脱敏规则版本，改了要能追chunk_size:400chunk_overlap:50collection:kb_itsm_2026h1# 落到哪个向量集合approved_by:业务负责人 / 数据管理员approved_at:2026-10-12

两个字段值得说明。mask_rule_version为了回滚：规则改了，旧批次仍按旧规则，出问题能定位到哪版规则漏了哪类字段。collection为了隔离：第③类单独放一个集合，检索时按权限决定查不查，比事后从大集合里筛省事。

6.2 来源与授权依据：一条语料一份凭证

最后一行是最常见的事故：合同写「供甲方内部参考使用」，工程侧理解成「可以进知识库」，法务理解成「只能人看」。

6.3 删除与重建链路：证明它真的删了

删除请求要有编号、有影响范围、有验证方式。影响范围逐项写清：原始文件、切片文本、向量、备份、检索日志。验证方式要写可复现的动作，比如「用原文里的一句话检索，命中数为 0」。

最容易出错的是「只删了切片，没删向量键」。下面这段只是流程骨架，本机没跑过，接口按你的客户端改。

⚠️代码待验证

# 1) 先按批次号统计影响面，别直接删python tools/kb_audit.py--batchKB-2026-10-001 --count-only# 2) 删切片与向量（同一主键，两步）python tools/kb_delete.py--batchKB-2026-10-001--collectionkb_itsm_2026h1# 3) 回收近似索引里的空间，再校验条数是否归零python tools/kb_compact.py--collectionkb_itsm_2026h1 --verify-empty

关于「删不掉」，《网络数据安全管理条例》（国务院令第 790 号，自 2025 年 1 月 1 日起施行）第二十四条给了很实用的处理方式：删除、匿名化从技术上难以实现的，应停止除存储和必要的安全保护措施之外的处理。同条例第二十七条还要求定期自行或委托专业机构做个人信息合规审计。

这条对向量库特别有用。有的切片进了备份，有的向量因索引没重建留在段文件里，有的内容导入时被摘要、原始边界说不清。正确动作不是「假装删掉了」，而是「停止使用」——从检索集合里摘出去，只保留存储，并在清单里写明原因。

七、上线前的五道检查，以及必须交给法务的边界

7.1 五道检查

权限控制必须做在检索层：先按账号范围过滤候选切片，再交给模型。把全部切片检索出来、靠提示词要求模型「不要回答无权查看的内容」，那不是权限控制，是建议——提示词能被绕过，被过滤掉的数据拿不到。

7.2 四条不能自己拍板的边界

工程侧能分类、能脱敏、能跑通删除链路。下面四件事必须由法务或合规确认，别在评审会上替他们表态：

1. 单独同意的形式与留证方式——是勾选、是签字、还是单独弹窗，有效性各不相同。
2. 敏感个人信息处理的「特定目的与充分必要性」论证——这段写不出来，第③类就不该入库。
3. 去标识化与匿名化的界线。第七十三条把两者分开：前者是不借助额外信息就无法识别，后者是无法识别且不能复原；只有匿名化后的信息才不属于个人信息。工号换成随机 ID、映射表还锁在另一台服务器上，那是去标识化。
4. 第三方商业秘密的授权范围，以及跨境路径。

第三条最容易被厂商话术糊住。「我们做了脱敏」在合规上几乎没有信息量，要问：还能不能复原？靠什么复原？映射表在哪、谁能拿到？

7.3 一个最小可跑的判定器，和它漏掉的那一条

把 2.1 节的顺序写成函数，跑六条人工构造的样本：

# 摘自 work/2026-10-20_语料准入判定.py（本机实测，六条样本）defclassify(rec):text=rec["text"]ifrec["provenance"]=="unknown":# 第一道：来源闸门return"4-不入库","来源无法追溯"ifany(wintextforwinNO_REUSE):return"4-不入库","材料自带禁止二次利用标注"ifany(wintextforwinSENSITIVE_HINT)orany(wintextforwinSECRET_HINT):return"3-单独授权","触及敏感信息或第三方秘密"ifPHONE.search(text)orEMPNO.search(text):return"2-脱敏后入库","命中手机号或工号"return"1-可直接入库","无个人信息、来源可追溯"

实测结果：六条里五条判对，一条漏判——体检报告那条判成了「可直接入库」。原因很简单，敏感词表只抄了法条列举的那几类（人脸、指纹、病历、诊断、银行卡、征信），没写「体检」；真实语料里也没人写「病历」，大家写「体检报告」「用药清单」。

这个漏判是本文最想留下的结论：关键词表永远追不上真实写法。第一道筛子可以用正则，但主判据必须是字段级来源标签加人工抽检。补全词表，只会让下一个漏判换个说法出现。

这份资料是什么：《LangChain + LangGraph + MCP 智能体开发实战》的模块目录，第 2 模块讲 Embedding 与 RAG 全流程，正好接在本文的切片与检索之后。放在资料包里，扫码即可获取：

附表 A：本文引用事实与出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：

• 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
• 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
• AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
• 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
• 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「AI」，优先通过。

资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。