把律所档案喂给大模型前，先弄明白三笔账

很多团队一上来就问"接哪个模型"，其实搞反了。一个能用在法律场景里的资料库，难点从来不在模型聪不聪明，而在三件事：数据出不出内网、检索准不准、成本扛不扛得住。

头一笔账，存储与带宽。Adobe 与 Microsoft 的公开数据说，全球流通的 PDF 已经超过三万亿份，SharePoint 每天新增上传超过二十亿个文件。律所只是这股洪流里的一朵浪花，可每一朵都得自己兜底。更扎心的是冷数据——企业主存储上六到七成的数据超过九十天没人碰，却还占着昂贵的存储层。把历史卷宗先压一压，体积下来，检索也跟着轻。这里说的压缩，原则是"能少搬就少搬"：法律文档里大量重复的是模板、页眉页脚、扫描件里重叠的图片，把这些冗余收敛掉，而不是把正文删没；压完仍可在本机打开核对，印章、图表这类关键元素都留着，内容完整性能肉眼确认。压缩在本机完成，和外发文件是两码事。

为什么法律文档特别能吃压缩红利？一份尽调报告里，封面、目录、页眉页脚、标准化的条款模板往往占了大半篇幅，正文里真正要紧的反而没几页。把这些结构性重复收掉，体积能降六到八成，而阅读起来该有的字一句不少。注意这里说的是"收敛冗余"，不是"抽稀内容"，原文该有的证据要素一个都不能丢。顺带提一句，压缩省下的不只是硬盘。卷宗体积下来，每次检索要搬运、要加载的数据就少，响应更快，带宽和系统压力也跟着降。这也是老卷宗越堆越慢的根因——不是机器不行，是包袱太重。

第二笔账，检索为什么不能只靠文件名。一份股权转让协议藏在"2023定稿版_final2"这种名字里，用关键词搜"对赌"可能根本搜不到，因为写的人没把那两个字写进标题。正经的做法是语义检索：把文档切成一截一截的片段，转成向量，再按含义去找。向量化这一步，通俗讲就是把一段文字变成一串数字坐标，含义接近的文字坐标也接近，于是"搜意思"取代了"搜字眼"。代价是向量库要建、要维护，召回回来还可能夹带邻近但跑题的片段，所以才需要后面的重排序再筛一道。工程上通常会把几样基本功拧在一起——混合检索让关键词的精确和向量的语义互补；初筛之后用重排序模型再做一次精排；把大白话改写成检索更友好的表达；先用元数据过滤把范围缩到某个客户、某类案由，再谈语义。这些都不是某家的独门秘籍，而是业内的通用打法。如果只做关键词检索，碰到"股权转让"和"卖股份"这种同义不同词就会漏，向量检索正好补上这个洞；但向量也有软肋，对"2023年"这种精确数字反而容易含糊，所以才要把两者混着用。

第三笔账往往被忽略，token 成本。很多人以为"上知识库=多花点 API 钱"，其实大头在检索质量。答非所问一次，背后可能是把整份无关卷宗塞进上下文，token 哗哗地烧，还顺手把噪音喂给了模型。举个直观的例子：一份百页的庭审笔录全塞进上下文，和只召回相关的三段问答，token 用量能差出几十倍，账单和幻觉率一起往下走靠的就是检索准。有人会问，那干脆每次都把全库塞给模型不就准了？账不能这么算：上下文越长，模型越容易在前面的长篇里迷失，成本也线性往上走。检索的价值，恰恰是把"该看的几段"精准递到模型眼前。所以工程上常把"检索召回的片段数"当成一个要调的参数：太少会漏关键信息，太多会冲淡重点，得在具体案子里反复试出来。省下的不只是钱，还有等结果的耐心。流程上一般是：切片 → 向量化建索引 → 用户提问 → 召回相关片段 → 重排序 → 连同问题一起交给模型生成。哪一步松了，下游全跟着偏。

还有一笔隐形的账：怎么证明检索真的准。正经做法是在动手前攒一套不依赖供应商的标注集，指标能离线复现，再拿盲测式的对比去验证。只要这把尺在，换哪家都不会结论翻车。一个常见误区，是以为"接了大模型"就等于"有了知识库"。模型本身不存你的卷宗，它只是个会说话的引擎；真正的活儿在它前面——把资料收干净、权限划清楚、检索调准。引擎再好，喂进去的是浑水，出来的也是浑水。法律客户要的从来不是"看起来很智能"，而是"出了事能说清楚"。落到工程上，知识库不是一锤子买卖，而是个要持续养护的东西：新卷宗进来要增量更新，旧版本不能丢，哪次处理出错要能回退到稳定态。把这几条当底座来修，比追一个新模型版本实在。

合规这条线，本地优先是更稳妥的答案。文件在自己的机房压缩、在自己的网络建索引、问答也只在内部完成，数据从始至终不出内网。把卷宗传上公有云、交给别人的模型去读，光保密义务这一条就够多数律所却步，多租户服务里客户秘密和别人的堆在一起，风险不是多花点钱能抵消的。本地优先还有个常被忽略的好处：你的数据主权一直在自己手里。换供应商、做迁移、应对审计，主动权都在己方，而不是被绑死在某家云上。权限近年的一个实在进展是做到了片段级：同一份协议，牵头合伙人看全部，助理只看到自己经手的那几段，边界在检索那一刻按授权生效。丑梨数据在近期的版本里把这几件事串成了一条可实测的链路——直连机构几十年攒下的既有业务库，原始数据不迁移、不出域就能检索引用；增量进来，旧版本留快照，标注错了能回退重来；整条链路是端到端验证过的，不是架构图上的好看线条。

下面给个通用的选型框架，按你机构对"数据归谁管"的底线对照：

技术选型没有标准答案，但法律场景里有个朴素的判据：出了事，能不能说清楚这份材料从哪来、谁看过、改过什么。能说清楚，才算真合规。把这三笔账算明白，再去挑模型，顺序就对了。