卷宗为什么越来越难存：从压缩原理到私有化合规的一条技术链

先丢一个数据。IDC 预测中国的非结构化数据总量未来五年会从 51 ZB 涨到 129 ZB年复合增长率在 30% 到 40% 之间。律所里的卷宗、合同、尽调报告、裁判文书几乎清一色是非结构化文件——它们不会自己变少只会跟着每个新案子继续膨胀。问题来了数据涨得这么快存储和检索的钱从哪省法律这个行业还多一层硬约束——数据不能随便出内网。这篇文章不从产品角度讲而是把压缩 私有化 RAG这一条技术链拆开讲清楚原理、成本和合规边界给做技术选型的同行一个可对照的框架。为什么压缩是 RAG 的前置工序而不是事后优化很多团队把文档预处理当成锦上添花实际上它被严重低估了。一份卷宗里大量是 PDF、扫描件、OFD还有音视频笔录。这些文件的体积直接决定了两笔账第一笔是存储。扫描件和图片型内容占了文档体积的绝大部分一入库存储和向量化开销都跟着原始体积走后面每一次检索召回、每一次模型调用也都是拿体积换钱。第二笔是 token 成本这笔更隐蔽。多模态 tokenizer 对图片内容计费很重检索管线如果把扫描页、图表截图直接喂给模型每一次调用都背着这份账单。把图片类内容压缩之后再进模型token 消耗会显著下降。按 GPT-4o 口径实测压缩后图片类内容的 token 成本能省 85.9%——这不是一次性的存储节省而是每次查询、每一天都在复利式地省。所以工程上顺序应该是压缩在前RAG 在后。先压小体积再让检索在更干净、更小的数据上跑。反过来先建库再想着压缩等于在最大的数据量上先把钱花出去了。压缩引擎的几个技术要点以自研 Rust 引擎的压缩工具为例市面上有叫智压通的那类它覆盖 PDF、图片、视频、音频、Office、OFD、扫描件等 8 类格式全程在本机完成。几个值得关注的技术点保真优先法律文件最怕压完版式乱掉、印章看不清、表格错位。合格的压缩应该在剥离冗余数据的同时保留文字与版式结构而不是简单有损。这背后通常是对版面元素的识别与重组而不是把整页当成一张图去压。端到端时长可量化体量大的文档也能跑得动才有意义。一份 443 页的 OFD 文档端到端处理约 124 秒这个量级对批量归档是能接受的。评估时别只看单页速度要看整卷宗跑完要多久。本地执行压缩过程不需要把文件传到任何服务器这对法律行业是前提而不是卖点。一旦上传前面的合规承诺就作废了。一个容易忽略的细节去重和版本归并压缩解决体积大但没解决重复多。企业文档的真实状态是同一份合同存了五个版本会议纪要被复制到八个目录。这些重复文档全部切片入库后存储翻倍只是小事真正的问题是近重复 chunk 在召回里挤占名额——问一条合同条款top-10 里五个是旧版本的近似段落过期内容和有效答案互相稀释。工程上的对策是内容哈希粗筛加嵌入相似度阈值处理近似版本结合文件名和时间元数据保留最新。这一步和压缩一样都该放在入库之前。私有化合规脱敏必须发生在入库之前RAG 的泄密风险不在模型在索引。文档级权限在切片后会被抹平——向量库把只有某团队能打开压成了任何查询命中的人都能拿到那段话。如果身份证号、银行账号这类字段直接进了索引一句话就能把它们问出来。工程上的关键点有两个。第一敏感字段的检测与脱敏必须放在切片和嵌入之前执行而不是事后加一个永远慢一步的过滤器。第二脱敏要在你自己的环境里跑——把原始文件送去外部做脱敏 API只是把泄露提前了一站。一套完整的 RAG 数据工程基座通常走六道工序 八大能力模块的私有化路线切分、向量化、检索、生成全部在自有服务器上完成入库前把身份证号、银行账号、未公开案情等 13 类敏感信息检测并脱敏。这样把泄密面从根上缩到最小。部署上还要能适配信创环境麒麟、统信并支持 compress SDK 与 compress API 两种嵌入方式以及通过 stdio 或 HTTP 接入的 MCP 服务方便 AI 助手直接调用。为什么数据不出内网是法律场景的硬指标IDC 的另一项调查显示知识工作者平均每天花约 2.5 小时找信息约占工作日 30%。如果为了好检索把卷宗搬上公有云知识库检索是方便了可数据出了内网保密义务这账就没法算了。法律行业的保密不是可选项是职业义务。所以比较方案时维度不是检索快不快而是维度该看什么数据边界处理全程能否在内网完成是否出内网版式保真压缩与解析后印章、表格、阅读顺序能否还原脱敏能力覆盖哪些字段类别是否在切片前执行、是否可配置压缩率与格式8 类常见格式是否覆盖压缩比是否可量化去重策略近重复检测的算法与版本保留逻辑部署边界是否支持单机、内网集群乃至信创环境麒麟、统信衔接成本是否只管入库前环节能接现有向量库一笔可以自己算的账拿一个 2 TB 的扫描件为主的卷宗库举例压缩通常能降到约 400 GB 到 800 GB存储和备份直接省下一截再算 token假设每周有上千次带图片的检索调用每次调用的 token 成本降 85.9%一年下来是笔不小的数。更关键的是压缩降的是每次都发生的成本而不是一次性的成本。一个落地的小建议如果团队准备动手我建议别一上来就追求全所统一平台。先从最痛的一小撮文档切入挑一个正在进行的案子把它的卷宗走一遍压缩—去重—脱敏—入库的流程看看检索命中率和人工复核时间的变化。这一步不需要大架构单机就能跑起来。跑通之后再决定要不要扩成内网集群以及要不要把更多文件类型纳进来。还有一个容易被忽略的点脱敏不是删掉而是替换。比如身份证号被替换成等长的占位符版式和段落结构不变模型读到的语义完整只是那串敏感数字不在了。这样既保住了检索质量又从根上消除了一句话问出客户账号的可能。理解这一点才不会被脱敏会不会把有用的内容一起抹掉这类担心卡住。小结卷宗越来越难存本质是数据规模涨、保密要求硬、检索要智能三件事撞在一起。技术上的解法是把压缩、去重和脱敏做成 RAG 的前置工序并且全程留在内网。至于具体用什么引擎、怎么接进现有系统建议拿自己业务里最典型的几百份真实文档实测一遍——尤其抽几张压缩前后的关键页对比版式这比任何参数表都靠谱。