假设现在把你公司所有的文档——合同、研报、客服录音转写、几百页的扫描件——原封不动倒进一个“智能系统”，你觉得它会怎么对你？多数人体验过的答案是：要么根本塞不进去，要么塞进去了也答非所问，要么账单悄无声息地涨。
IDC 给过一个数：2024 年全球数据总量大约 149 到 180 ZB，到 2028 年奔着 394 ZB 去，其中八到九成是非结构化数据。文档从来不是太少的问题，是太多、太杂、太贵的问题。McKinsey 另一个数更扎心：职场人差不多 19% 的工作周，一天近一个半小时，耗在搜和凑信息上。Asana 还补了一刀——一个任务被打断后平均要 23 分钟才能重新进入状态，而人每天在 35 个应用之间来回切。文档如果处理不好，它不只是在占硬盘，它在反复放大每一次中断的代价。
新手面对这道“题”，反应通常是两件事：找个工具把文件压小，或者赶紧上个向量数据库让它能搜。做过生产系统的人不会从这里起步。
他们先问的不是“用什么工具”，而是“这些文档到底为什么要变”。是为了省存储？是为了邮件能发出去？是为了喂给大模型做问答时少花 token？还是为了合规留档十年不能丢？同一堆文档，目的不同，做法天差地别。一个懂行的人会在动手前先把“约束”钉死，而不是把“压缩”或“上向量库”当成默认动作。
约束钉死之后，第二步是把这堆东西按“它到底是什么”分开。一份带红章的合同 PDF，和一张 4K 工程扫描图，和一份 200 页的 OFD 报表，是三种完全不同的生物。合同要的是结构与印章一字不差地保留，扫描图压的是冗余的像素，OFD 报表压的是版式里的重复元素。把它们混在一起用一个“默认压缩”去怼，结果往往是：该清楚的糊了，该小的没小下去。这里就显出外行和内行的差别——外行盯“压了多少”，内行先盯“哪里绝对不能动”。
再往下，内行会回到信息本身去想。一份文件为什么大？扫描件大，大在它是高密度栅格，里面充满了人眼看着差不多、字节上却很啰嗦的冗余；文本和版式大，大在重复的结构和嵌入的对象。所以压不压、怎么压，不该按“默认档位”决定，而该按“这份东西拿去干什么”决定：要归档十年、随时能当法律证据的，走无损，原样可逆；要在屏幕上快速预览、要塞进邮件的，走有损但保关键信息的那一路。把"无损还是有损"这个开关从默认值手里抢回来，是内行和工具默认行为之间的分水岭。
分型错了，后面全错。把该走无损的合同误设为有损，红章糊了就是事故；把该走有损的扫描件硬保无损，体积纹丝不动还拖慢整条线。所以内行宁可在前一步多花十分钟问清楚"这份东西归哪类、压完给谁用"，也不愿出了事之后回头擦屁股。分型不是流程里的形式，是整条链路的地基。
举个小例子。一份合同扫描件，红章和签署日期是它的命门，压模糊了在法律上就等于改了文件；一张医疗影像，压掉的可能正好是那处病灶的边缘。外行看“体积少了百分之六十”很爽，内行看的是“那百分之六十里有没有不能动的东西”。所以内行会在压之前先问：这份东西压完之后，谁会因为它“变了”而吃亏？这个问题的答案，决定了能不能压、怎么压。
还有一层新手容易忽略：同一份资料在公司不同系统里往往存了好几份，版本还不一致。内行会先把去重和版本理清，再谈压缩和检索——在脏数据上建索引，检索质量怎么都上不来。成本也要算总账：embedding 算一次、重排跑一次、模型读一遍，token 怎么花最值，多取几段让模型自己挑还是先精排再少取，这笔账不清楚，“省”就只是口号。尤其是 RAG 场景，每一段被捞出来都要被模型再读一遍，文档不干净、切段不讲究，token 账单是按月复利的——先压缩、先理清，往往比事后换更贵的模型更划算。
知识库搭建这件事，外行当成上传一次就完事，内行当成持续运转的系统。文档在变、业务在变，今天能答对的，下个月新版本进来可能就答错。所以内行从第一天就留好评估集和回滚的余地，把“建”和“养”当成一件事。这也解释了为什么不少 demo 看着惊艳、上线就拉胯：demo 只证明它能返回点东西，而生产要的是在真实、脏乱、不断变化的文档上持续答对。把“返回东西”当成终点的人，和把它当成起点的人，做出来的系统完全不是一回事。
很多人以为压缩和检索是两件事，内行不这么看。他们把“整理 → 压小 → 切段 → 转向量 → 检索 → 回答”看成一条线，而且只信整条线的结果，不信任何一段孤立的漂亮数字。而在压缩和检索之前，往往还有一道整理——同一份资料散在十几个文件夹、命名乱成一团，内行会先把“该归到哪、按什么维度分类”想清楚，否则检索再强也救不了放错地方的文档。一份被干净压缩过的文档，进检索时噪音更少、token 更省、召回更稳——压缩在这里不是省存储的附赠，它是检索质量的前置工序。反过来，如果检索老答非所问，内行不会先怪模型，而会先回头看：是不是切段把一句话拦腰斩了？是不是口语化的问题直搜根本捞不到？是不是相关段落被截断了？
说到检索这一步，内行手里的工具箱和外行想象的不一样。他们不会只丢一句原问题进去。真实用户的提问是口语、是缩写、是同义替换、还经常一句话藏三个意图——评测集里那句干净的“请说明退款政策”在现实里基本不存在。所以他们会做混合检索：关键词那一路抓精确匹配，语义向量那一路抓含义相近，两路合并，漏检率立刻下来。初筛之后再接一个重排序，把真正相关的顶上来。碰到复杂问题，还会把一句口语改写成几个检索友好的子查询，分别搜完再拼。权限和来源也先过滤，免得把不该看的捞出来。
这些动作不是为了炫技。它们都指向同一件事：让“答得准”从运气变成可测量的指标。这正是大多数人没要求、但内行一定会做的事——在写第一行代码前先准备一批标注好的问答对和标准答案出处，没有这个，“准”就没有定义；把召回率、答非所问率按问题类型分桶看，哪类总翻车一目了然；再把知识库更新后旧评估集重跑一遍，防止“今天对、下个月错”的悄悄退化。
那凭什么信这一套？不能靠厂商说“我们很准”，也不能靠买家希望“应该够准”。能站住脚的，是第三方也能复现的东西：独立标注的黄金问答集，任何人拿同一批标注重跑你的系统，recall@k 和忠实度摆得上台面；把新旧链路对真实问题的回答匿名交给独立评审做盲测，命中率差异不依赖“内部测过”；再养一套回归测试，已知该答对的必须持续答对，红绿状态公开可查。对压缩本身也一样——压完的文档能不能原样打开、印章在不在、版式歪没歪，重新打开看一眼、和原文件比一比就知道；压小之后喂给模型，token 数到底降了多少、检索还准不准，跑一遍下游任务就有答案。正确性不来自谁的承诺，来自能独立验证的动作。
说到底，上面这一整套不是某个产品的功能清单，而是一种习惯：先问为什么要做，再决定怎么做；先把"对"定义清楚，再谈"快"和"省"；并靠谁都能复现的动作、而非漂亮的口号，来证明它真的对了。
我们近期在压缩与检索的衔接上做了一小步：把文档在进检索前的前置压缩，适配到多家主流大模型，让瘦身后的同一份文档能被不同模型稳定地读进去、用起来。这步解决的正好是上面那道坎——压完不能反而让模型读不懂。它远不是整套工程化深水区，但方向是对的：先把“压得小”和“读得懂”拧成一件事，再往上叠评估、重排和可观测。
下面这张表，是“工具默认行为”和“懂行的人做法”在几个关键处的差别。
| 关键处 | 工具默认行为 | 懂行的人做法 |
|---|---|---|
| 出发点 | 直接压缩 / 直接上向量库 | 先钉死“文档为什么要变”的约束 |
| 文档处理 | 一锅默认压缩 | 按合同/扫描/报表分类型定策略 |
| 无损还是有损 | 跟着档位走 | 按用途决定，归档无损、预览有损 |
| 压缩与检索 | 当成两件事 | 看成一条线，只信整条结果 |
| 查询 | 原句直搜 | 混合检索 + 重排 + 改写分解 |
| 质量验证 | 厂商自述 | 标注黄金集 + 盲测 A/B + 回归套件 |
立即体验
想看一个把“私有化、数据不出内网、压缩与语义检索拧成一条线”落到生产环境的做法，可以看这里：
常见问题
Q：小公司文档不多，是不是用默认压缩就够了？
A：看你要拿文档干什么。内部传个文件，默认压缩通常够。但一旦文档要进检索、要喂模型、要当证据留存，分类型和定策略带来的差别就不小。
Q：压缩之后文档还能当法律证据吗？
A：取决于压法。归档类走无损、原样可逆，内容和印章一字不差，就能当证据；预览类走有损只适合快速看。关键不是“压没压”，是“哪类走了哪条路”。
Q：混合检索听起来复杂，小团队用得起吗？
A：核心就是“关键词 + 语义”两路合并再加一个重排，都有开源实现。门槛不在钱，在愿不愿意把“答得准”当成要持续测量的事。
Q：怎么判断一个知识库真的答得准？
A：别信 demo。要一批标注好的标准问答、一个能复跑的评估，再加盲测和回归测试。能让第三方拿同样的标准重跑你的系统，结论才站得住。
Q：压缩和 RAG 一定要一起做吗？
A：不一定要同一家做，但一定要当一条线看。干净压缩过的文档进检索，噪音少、token 省、召回稳——把这两件事割裂开，往往两头都吃亏。