几乎每一个法律 AI 创业团队,在写第一行产品代码之前,都要先回答一个看似技术、实则决定生死的问题:数据从哪来?这道题答错了,后面再聪明的模型、再漂亮的界面都救不回来——因为法律 AI 的可信度,归根结底押在它身后那批判决数据上。本文不谈具体产品对比(那是选型对比文的事),而是站在创业 CTO的角度,把「自己爬一个库」和「接一份授权库」这道 build-vs-buy 的题彻底拆开:人读型法律库为什么不能当产品底座、自建爬库的真实成本藏在哪、以及按你团队所处的阶段,到底该怎么选。
一、先分清两种「法律数据」:人读的库 vs 机器吃的语料
很多技术合伙人第一反应是「市面上不是有北大法宝、威科先行这些库吗,接一个不就行了」。这里有一个根本性的错配:这些产品是按席位(per-seat)卖给律师「人读」的检索工具,不是按授权(license)卖给开发者「机器消费」的结构化语料。
两者优化的目标完全不同:
| 维度 | 人读型法律库(per-seat) | 产品底座要的语料(license) |
|---|---|---|
| 买给谁用 | 律师,人坐在网页前检索 | 你的程序,批量摄取进模型/RAG 库 |
| 交付形态 | 网页检索界面、账号席位 | 批量数据集 + API + 增量同步 |
| 数据结构 | 面向阅读排版,字段不对外开放 | 案号/法院/案由/判项等结构化字段 |
| 授权条款 | 通常禁止灌入你自己的模型/产品 | 明确授予摄取与再加工权利 |
| 可回链溯源 | 人工点击查看 | 每条结果带稳定 ID 回链原文 |
结论很直接:人读型库是优秀的律师工具,却是错误的产品底座。你拿它当后端,要么授权不允许、要么拿不到结构化字段、要么没法批量和每日同步——这不是内容质量问题,是 access model 和你的需求根本不匹配。所以「接一个现成法律库」这条路,对做产品的团队多半走不通。真正的选择,落在下面这两条上。
二、路线 A:自己爬一个库——以及它藏起来的四笔账
「裁判文书不是公开的吗?写个爬虫抓下来不就有了?」——这是最常见、也最危险的乐观。免费只是表象,自建爬库的真实成本藏在四个地方,每一个都能拖垮一个早期团队。
1)覆盖:你不知道自己漏了什么
公开渠道近年持续收紧,各地法院上网比例、保留时长、格式都不一致。你抓到一堆判决,但无法回答「这批数据完整到什么程度、漏了哪些案由和地区」。而覆盖缺口一旦无法表征,基于它算出来的任何统计、训练出来的任何模型,结论都站不住——用户问「为什么这类案件你只有这么几条」,你答不上来。
2)合法性:绕过授权批量抓取是有风险的
绕开授权大规模抓取、再把内容商用,存在实打实的合规风险;涉及当事人信息、涉密案件时,还要受《数据安全法》《个人信息保护法》约束。早期为了省一笔授权费埋下的法律风险,在你拿融资、做尽调、签大客户时会被翻出来,代价远高于当初省下的钱。
3)结构:原始判决不是「能用的数据」
判决书是高度格式化、但元数据藏在正文里的长文本。要变成产品能用的东西,得把案号、法院层级、案由、引用法条、判项结果都抽成可检索字段,还要去重(同一纠纷的一审/二审/再审、转载副本要合并)。这件事的魔鬼在规模:一条对 99% 文书都成立的清洗规则,在上亿量级上仍会错几百万条。这套结构化与去重的工程,我们在裁判文书私有库的技术架构里拆得很细——它比写爬虫难得多。
4)维护:这是一条永远停不下来的流水线
数据每天都在新增,格式会漂移,法院网站会改版。爬库不是「抓一次就完事」的一次性任务,而是一支团队要长期养着的基础设施。对一个本该把全部火力压在产品上的早期团队,这是最容易被低估、也最伤的一笔持续支出。
一句话判断:清洗、去重、字段抽取、合规维护这几层,是「成本高、但几乎不带来差异化」的脏活——两个团队就算用同一批判决,最后比的也是产品和场景,而不是谁把文本洗得更干净。把工程力压在这种地方,对早期团队往往是亏的。
三、路线 B:接一份授权好的结构化语料
另一条路,是把上面那四笔脏账外包出去:直接授权一份已经清洗、去重、结构化、可回链、可每日同步的语料,自己只搭产品。它把「覆盖、合法性、结构、维护」这四个最耗人的层一次性解决,换来的代价是一笔授权费和对供应商的依赖。
对早期团队,这条路的吸引力在于它反转了资源分配:本来要拿去养数据团队的人手,全部留给真正决定胜负的产品层——垂直工作流、检索体验、某个细分场景的算法。判断一份语料够不够格当底座,看四个硬指标:
- 是不是 license 而非 per-seat:授权条款明确允许你把数据摄取进自己的模型/产品,而不是只给账号看。
- 是不是结构化 + 可回链:给的是带字段、带稳定 ID、能点回原判决的数据,而不是一堆纯文本。可回链是法律 AI 能不能溯源的命根子。
- 交付形态够不够灵活:批量数据集(灌库/训练)、REST API(线上查询)、MCP(接 AI 助手)、增量同步(保持新鲜)——按你的阶段挑组合。
- 覆盖可表征、来源合法:供应商能说清覆盖范围,数据来源经得起尽调。
文书查提供的正是这样一份底座:1.7 亿+ 篇结构化、去重、可回链的裁判文书语料,支持 REST API、MCP 与批量授权三种交付。检索那一层怎么做得准(语义+关键词混合召回),我们在类案检索:语义向量 vs 关键词里讲透了——你接的是底座,产品的检索体验仍然由你自己掌控。
四、自建 vs 授权:逐项对比
| 维度 | 自建爬库 | 接授权结构化语料 |
|---|---|---|
| 首日成本 | 看着「免费」 | 一笔授权费 |
| 真实总成本 | 爬虫+清洗+去重+合规+长期维护团队 | 授权费 + 极少对接成本 |
| 覆盖可表征 | 难,不知道漏了什么 | 供应商给覆盖说明 |
| 合规风险 | 批量抓取+商用,风险自担 | 授权方承担来源合规 |
| 数据新鲜度 | 靠自己持续重爬 | 增量同步,每日更新 |
| 上线速度 | 数月起步 | 试用 key 当天就能跑 |
| 差异化贡献 | 低(同行都能爬到) | 把人手腾给产品层=高 |
| 适合谁 | 数据本身就是你要卖的核心、且养得起数据团队 | 差异化在产品/场景/算法的多数团队 |
这张表的落点不是「授权一定比自建好」,而是「数据是不是你的差异化」决定了你该把工程力放哪。如果你卖的就是数据本身、并打算长期投入一支数据团队,自建成立;否则,接底座、做产品,是更理性的早期选择。这套判断逻辑,和海外法律 AI 厂商面对中国判例时的 build-vs-buy 取舍是同一个道理。
五、按阶段选:一张给 CTO 的决策表
不必一上来就做终局决策。按团队所处阶段,数据底座的选法是不同的:
| 阶段 | 首要目标 | 数据底座怎么选 |
|---|---|---|
| 验证 MVP | 确认用户为这个场景买单 | 用 API/MCP 接小而真的结构化样本,快速跑通闭环,别投人爬全量 |
| 产品打磨 | 把检索/研判体验做扎实 | 全量授权语料 + 自建检索/重排层,体验掌握在自己手里 |
| 规模化 | 稳定、新鲜、可控成本 | 批量授权 + 增量同步;高频场景考虑缓存/本地化 |
| 涉密/政企客户 | 数据不出域、过等保 | 转私有化离线部署,数据与模型都在客户内网 |
给 CTO 的一条原则:把「要不要自建数据团队」这种重决策,尽量往后推,推到你用真实用户验证过「数据确实是我的差异化」之后再做。早期最贵的不是授权费,是把宝贵的工程人手投错了地方。先接底座跑通产品,永远比先花半年爬一个库、最后发现产品方向不对要划算。
六、选供应商照着问这 6 条
把这几条发给候选数据供应商,一轮就能问出谁能真当底座:
- 授权模式是 license(允许摄取进我的模型/产品)还是 per-seat?条款能否覆盖商用与再加工?
- 给的是结构化数据(案号/法院/案由/判项字段)还是纯文本?每条能否回链原判决?
- 覆盖范围怎么表征?哪些案由/地区/年份全、哪些缺?来源是否经得起尽调?
- 交付支持哪几种:批量数据集 / REST API / MCP / 增量同步?能否先给试用 key?
- 数据多久更新一次?增量同步怎么做?
- 涉密/政企场景能否转私有化离线部署、过等保?
七、常见问题
Q:我们就是想做「中国版某海外法律 AI」,数据自己爬不行吗?
A:能爬到一些,但你会卡在覆盖不可表征、结构化成本、合规风险和永续维护这四关上。海外同类公司面对本国判例同样在做 build-vs-buy 取舍,多数选择授权语料、自建产品。除非数据就是你要卖的核心资产,否则把这几关外包出去更理性。
Q:授权一份语料,会不会被供应商「锁死」?
A:这正是选型时要看交付形态是否灵活的原因。优先选同时提供批量数据集 + API + MCP 的供应商:批量授权让数据落在你自己的库里、训练你自己的模型,而不是只能调它的在线接口。底座在你手里,产品和模型的主权就在你手里。
Q:数据底座选好了,检索和研判还要自己做吗?
A:要,而且这正是你的差异化所在。底座解决「有没有干净可用的数据」,检索召回、重排、研判逻辑、产品体验仍然由你构建——这是你区别于同行的地方。底座是地基,楼还得自己盖。
先用试用 key 跑通你的产品闭环
告诉我们你做的法律 AI 场景与大致规模,1 个工作日内反馈方案,先给一份结构化、可回链的样本数据与试用 API/MCP key,让你在自己的产品里实测召回与溯源效果。验证阶段不收费。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 了解 API / MCP 与数据授权
相关阅读:文书查 vs 北大法宝 vs Alpha:全维度对比 · 5 分钟接入 MCP · 类案检索:语义向量 vs 关键词 · 私有化部署方案