一套法律 AI 项目的成败,一半在评标会上就已经决定了——决定它的不是哪家厂商讲得好,而是招标文件里的技术参数怎么写。参数写虚了,招来一堆套壳 demo,谁的话术漂亮谁中标,落地一地鸡毛;参数写死了、写出了指向性,要么流标重来,要么被质疑废标。更常见的是第三种:参数写了一大堆"模型参数量""并发数",却把最该写硬的数据底座、引证可核验、私有化合规写得含糊,结果买回来一个会编案例、数据来路不明、过不了等保的系统。这篇写给真正负责起草采购需求书、技术规格书的人:把法律 AI 招标的技术参数拆成六大模块,逐块给可以直接套用的指标,并讲清参数怎么写既硬又不锁定单一厂商、怎么用验收条款把"参数虚标"堵死。
一、为什么"技术参数怎么写"是采购里最高杠杆的一步
很多单位把精力放在评标打分、商务谈判上,却忽略了:招标文件的技术参数,才是整个采购的"游戏规则"。规则定得准,优质供应商才进得来、滥竽充数的才进不来;规则定歪了,后面再怎么评标都是在一堆不合适的投标里挑。法律 AI 这类专业系统尤其如此,因为它有三个特点,让"参数写得对不对"格外致命:
- 能力差异藏在水面下。两家厂商的 PPT 可能长得几乎一样,都说"基于大模型、支持类案检索、可私有化"。但一家背后是 1.5 亿份可回链原文的真实裁判文书语料,另一家是爬来的残缺数据加一个套壳模型——这个差距,只有把参数写到"语料规模 + 可回链 + 更新频率"这种层面,才逼得出来。
- 出错的代价是法律责任。法律 AI 编一个不存在的判例、把败诉案当胜诉案引,后果不是体验差,是办案出错、是执业风险。所以参数里必须包含"引用可核验"这类别的行业不需要、法律行业不可省的硬要求。
- 合规是入围资格,不是加分项。对党政机关、法院、检察院、国企,私有化、等保、信创往往是"不满足就出局"的实质性条款,写漏了等于把项目暴露在合规风险里。
换句话说:技术参数清单,就是你对"什么是一套合格法律 AI"的定义。把这份定义写扎实,采购就成功了一大半。本文配套的两篇——地方法院信息中心 AI 系统采购清单 和 律所采购 AI 系统的 5 个坑——分别从"采购全流程"和"避坑"角度补充,本文则专注在最硬核的一环:技术参数本身怎么落笔。
二、动笔之前先定三件事
参数不是从天上抄一份模板填进去的。落笔前,先把三个前置判断想清楚,否则参数会自相矛盾。
| 要先定的 | 两种取向 | 它如何决定后面的参数 |
|---|---|---|
| ① 部署形态 | 私有化离线 vs 公有云 SaaS | 涉密、内网、数据不出域的场景,直接写"必须支持完全离线私有化部署",后面所有数据、合规参数随之确定。详见 为什么大型律所不能用 SaaS。 |
| ② 数据来源 | 买现成语料 vs 自建/自爬 | 决定你是把"语料规模 + 可回链 + 更新"写成对供应商的硬指标,还是只采购工具、数据自备。法律 AI 绝大多数情况下,数据底座应由供应商提供并写进参数。 |
| ③ 验收口径 | 看演示勾选 vs 真题实测 | 这一条决定参数的"可验证性"。凡是想写进参数的能力,都要先问:它能不能在验收时用我方真实数据当场测出来?测不出来的参数等于没写。 |
这三件事定下来,参数才有骨架。下面进入正题——六大模块,每块给一份可直接改用的清单。
三、六大模块:可直接套用的技术参数清单
下面的指标是一套"骨架模板",请按本单位实际需求增删、按市场实际能力调整数值,不要原样照抄(照抄容易写出指向性或不切实际的参数)。其中标★的,是建议作为实质性条款/一票否决项的关键能力。
模块 1 · 数据底座(法律 AI 的根,最该写硬)
| 参数项 | 建议写法(示意) |
|---|---|
| ★语料规模 | 裁判文书语料规模不低于 ___ 亿份(可按需求设定,如 1 亿份以上),投标方须提供可核验的规模证明 |
| ★可回链原文 | 每一条引用/检索结果均须能回链到对应的原始裁判文书全文,供办案人逐条核对 |
| 覆盖年限与范围 | 覆盖年限不少于 ___ 年;覆盖审级/案由/地域范围满足本单位业务需要(列明) |
| 更新频率 | 语料具备持续更新机制,更新周期不低于 ___(如季度/月度),并说明更新方式 |
| 来源合规 | 数据来源合法合规,投标方须就数据来源与授权作出书面说明并承担相应责任 |
| 脱敏与隐私 | 涉及个人信息的内容具备脱敏处理能力,符合个人信息保护相关要求 |
为什么数据要写得比模型还硬?模型是可替换、可升级的部件;数据底座的真实性、完整性、可回链性,直接决定这套系统会不会编案例、能不能被信任。把大量参数花在"模型参数量"上、却对"语料从哪来、能不能回链"含糊其辞,是本末倒置。相关架构可参考 1.5 亿裁判文书私有库的本地化部署架构。
模块 2 · 模型与推理能力
| 参数项 | 建议写法(示意) |
|---|---|
| 核心功能 | 具备类案检索、要素抽取、文书辅助生成、法律问答等功能(按本单位业务列明必选项) |
| 效果指标(优于参数量) | 以可实测的效果指标约束:类案检索准确率、要素抽取准确率达到约定阈值,验收时以我方真题实测为准 |
| 本地化推理 | 模型可在采购方内网/本地算力上完成推理,不依赖外部公网调用(私有化场景) |
| 模型可升级/可替换 | 支持模型迭代升级,不绑定单一模型;具备模型管理与版本回退能力 |
| 性能与并发 | 在约定硬件配置下满足 ___ 并发、响应时延不高于 ___(按实际规模设定) |
提醒:不要把"模型参数量必须达到 ___B"写成硬指标。参数量大不等于法律场景准,且这类参数极易写成指向性条款。用"可实测的效果指标 + 我方真题验收"来约束模型,比纠结参数量科学得多。
模块 3 · 检索与引证核验(法律行业专属、不可省)★
| 参数项 | 建议写法(示意) |
|---|---|
| ★引用可核验 | 系统输出的每一条案例/法条引用,须可回链原文、可核对案号真实存在 |
| ★结果一致性校验 | 具备对引用裁判结果与原文一致性的校验能力(防"张冠李戴""结果说反"),不只校验案号是否存在 |
| ★查不到如实告知 | 检索不到相关结果时,系统须明确告知"未检索到",不得编造 |
| 混合检索 | 支持语义向量 + 关键词 + 结构化条件(案由/法院/年份/审级等)的混合检索 |
| 法条时效 | 法条引用具备现行有效性校验,避免引用已废止/已修订的旧法 |
这一模块是把法律 AI 和"通用聊天机器人"区分开的关键。一套不能逐条回链原文、不做结果一致性校验的系统,在法律场景里就是不可用的——理由详见 法律 AI 幻觉怎么治:裁判文书引证核验落地指南。强烈建议把本模块整体设为实质性条款。
模块 4 · 私有化部署与合规(政企/司法机关的入围资格)★
| 参数项 | 建议写法(示意) |
|---|---|
| ★离线私有化 | 支持完全离线的私有化部署,断网状态下核心功能仍可用,数据全程不出域 |
| ★等保合规 | 满足等级保护相关要求(等级以本单位定级备案为准),提供相应测评/合规材料 |
| 信创适配 | 支持信创环境(国产 CPU/操作系统/数据库/算力卡)适配,提供适配清单与实测结果(按本单位要求设为实质性条款或加分项) |
| 数据主权 | 全部数据、模型、日志存储于采购方可控环境,供应商不得留存或外传 |
| 审计留痕 | 具备操作日志与审计追溯能力,关键操作可追责 |
信创这一层尤其要小心"承诺易、落地难"。法律大模型推理迁到国产算力卡上仍有工程难度,招标时应要求投标方就国产算力卡上的真实可用性、性能与精度提供实测,警惕"无缝零损耗"这类不实承诺——展开见 信创环境下的法律 AI 私有化部署适配实战。等保三级合规架构见 司法机关数据中台等保三级合规架构。
模块 5 · 系统集成与权限
| 参数项 | 建议写法(示意) |
|---|---|
| 对接能力 | 提供标准 API,可与本单位现有办案/办公系统对接(列明需对接的系统) |
| 权限与隔离 | 支持分级分角色权限管理、数据隔离;敏感数据按需限定可见范围 |
| 账号与审批 | 支持与本单位统一身份认证对接;关键操作可设审批流 |
| 导出与留存 | 检索/分析结果可按权限导出,导出行为可审计 |
模块 6 · 服务、培训与 SLA
| 参数项 | 建议写法(示意) |
|---|---|
| 实施与培训 | 提供部署实施、管理员与终端用户培训;交付完整文档 |
| ★服务期与响应 | 免费维保期不少于 ___ 年;故障响应时间、到场时间、解决时限写明 SLA 并设违约责任 |
| 数据/模型更新 | 服务期内提供语料更新与模型升级,明确更新频率与方式 |
| 退出机制 | 合同到期或终止时,数据可完整导出/迁移,不被锁定 |
四、参数怎么写得"既硬又不锁死单一厂商"
这是起草人最纠结的一点:写松了招来李鬼,写紧了被质疑指向性、排斥性条款。平衡的诀窍只有一条——写"业务真需要的能力指标",不写"只有一家能满足的实现路径或品牌"。
- 写能力,不写品牌/型号。写"支持国产数据库",不写某个具体数据库品牌;写"语料可回链原文",不写某家产品的功能名。
- 每条参数过"三家测试"。每写一条,问自己:这条业务上是不是真需要?市场上是不是至少有三家能满足?如果一条参数业务上可有可无、却恰好只有一家能过,它就有指向性嫌疑,删掉或放宽。
- 关键能力设阈值而非唯一值。用"不低于/不少于 ___"的下限式写法,而不是卡一个只有某家正好满足的精确数字。
- 把"硬"放在实质性、可验证、与采购需求强相关的能力上。数据可回链、引用可核验、离线可部署、等保可合规——这些"硬"是法律业务的刚需,经得起质疑;而"模型参数量必须 ___B"这种"硬"既不科学又易指向,反而是风险。
合规口径提醒:政府采购与招投标的指向性/排斥性条款认定,以《政府采购法》《招标投标法》及本单位采购制度、当地财政与招标主管部门的具体要求为准。本文只给技术起草思路,涉及具体合规判断请咨询本单位法务与采购主管部门。
五、用验收条款堵死"参数虚标"
再好的参数,如果验收只是"对着表格勾满足",照样会被套壳产品蒙混过关。真正让参数有牙齿的,是把关键能力从"勾选题"变成"用我方真实数据现场实测的量化题"。建议把下面几条写进验收方案,并设为验收必过项:
# 法律 AI 验收实测条款(建议设为一票否决)
1. 真题盲测 → 用采购方提供的 ___ 道真实业务问题现场测试,非厂商演示
2. 引用错误率 → 统计编造/张冠李戴的引用占比,须低于约定阈值(如 ___%)
3. 回链可核 → 随机抽取引用,须能当场点开回链原始裁判文书核对
4. 诱导红队测试 → 故意问不存在的法条/诱导给结论,系统须如实说"未检索到"
5. 语料可核验 → 现场核验语料规模、覆盖、更新证明,而非一句话承诺
6. 离线实测 → 私有化部署在内网完成全流程演示,含断网状态可用性
7. 信创/等保 → 提供测评报告或现场验证,而非仅凭承诺函
这套验收条款的意义在于:它把"信不信厂商"从一个话术问题,变成了一个可现场对账的工程问题。把"引用错误率""离线可用性"写进验收并设阈值,套壳 demo 和数据残缺的产品就无处遁形——这也正是 让案件胜算精确到小数点 这类有真实数据底座的产品,和裸调一个大模型的本质区别。
六、给采购委员会的招标参数自查清单
- 数据底座写硬了吗?语料规模、可回链原文、覆盖、更新频率,是不是都作为硬指标/实质性条款写进去了?
- "引用可核验"这条有没有?这是法律 AI 不可省的一条,缺了它,买回来的可能是个会编案例的系统。
- 私有化/等保/信创按本单位合规要求写齐了吗?是入围资格还是加分项,有没有按上级规定定清楚?
- 有没有把"实现路径/品牌/型号"误写成参数?逐条过"三家测试",剔除指向性条款。
- 关键参数是不是下限式("不低于")而非精确卡值?避免一个数字正好只有一家满足。
- 验收用的是我方真题实测,还是厂商演示?引用错误率、回链可核、离线可用,有没有写成可量化的验收必过项?
- 服务期、SLA、退出机制(数据可迁出)写了吗?避免买完被锁定、出问题没人管。
- 每一条参数,验收时测得出来吗?测不出来的参数等于没写,要么补验收办法,要么删掉。
七、常见问题
Q:技术参数写多细才不算指向性、排斥性条款?
A:原则是"写功能与能力指标,不写品牌与唯一实现路径"。把要求落在客观、可验证、与采购需求实质相关的能力上(如语料可回链、支持离线部署、引用可核验),避免直接写品牌、型号或只有一家能满足的非必要参数。每条参数自检:业务是否真需要?是否至少三家能满足?具体合规口径以《政府采购法》《招标投标法》及本单位与主管部门要求为准。
Q:怎么防止参数表全勾"满足",到货却是套壳 demo?
A:把关键能力从"是否满足"的勾选,改成"用我方真实数据现场实测 + 量化指标"的验收必过项:真题盲测算引用错误率、随机抽引用当场回链核对、私有化在内网断网实测、语料规模要可核验证明。把这些设为一票否决,套壳产品过不了。
Q:数据参数和模型参数,哪个更该写硬?
A:数据底座更该写硬。模型可替换可升级,而语料的真实性、完整性、可回链性直接决定系统会不会编案例、能不能被信任。建议数据规模/来源可核验/回链/更新作硬指标,模型用"可实测效果指标"约束,不纠结参数量或品牌。
要起草一份法律 AI 招标技术参数?我们可以帮你把"硬指标"落到能验收
文书查提供 1.5 亿份真实裁判文书的私有化数据底座 + 引证回链与核验能力,支持离线私有化、等保与信创适配。把你的采购场景和需求发来,我们可协助梳理可验收的技术参数清单,并用你的真实业务做一轮实测,1 个工作日内反馈。
📞 联系商务 Jack · 131 6872 7779相关阅读:地方法院信息中心 AI 系统采购清单 · 律所采购 AI 系统的 5 个坑 · 法律 AI 幻觉与引证核验 · 信创环境法律 AI 私有化适配 · 1.5 亿裁判文书私有库部署架构 · 私有化部署方案