#候选研发方向：跨地区合同与法规数据层建设

本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 本文只说明要做什么、为什么这么做，以及如何在十二个月内做完并验收。

#一、这个方向要做什么

建设一套可独立使用、可独立授权的数据资产：把各地已经脱敏的真实合同、软件系统运行中沉淀的合同与复核结论、以及各地法律法规，加工成机器可以判定、人可以复核、结果可以评分的数据层。这套数据层包括语料、规则单元、字段结构、标注规范和独立评测集，并配套来源记录、脱敏协议、版本管理与更新机制。

本项目把「数据」本身作为研发对象，而不是把它当作某个应用的附属材料。交付的是一套别人拿不到、也买不到的判定依据体系，以及一套能证明它有效的评测方法。为验证这套数据层确实可用，项目自带一个最小验证应用：输入一份合同，输出带原文依据的结构化判定结果。

选择这个对象的理由：人工智能模型是通用能力，可以更换、可以采购，任何团队都能调用；但模型判断所依据的数据不是通用的。通用模型读过公开的法条和公开的合同范本，它没有见过真实运营方实际怎么修改条款、修改之后有没有产生争议，也没有一套能证明判断准不准的独立样本。把这些加工成可用资产，是一项需要真实业务环境、专业评审和长时间积累的工作，也是最容易被「套壳」标签误伤、实际上最不可能是套壳的部分。

#二、名词约定

#三、现有基础

#3.1 已建成并运行的软件系统

我们已建成一套面向公寓运营方的多租户软件系统，覆盖房源、租客身份核验、报价、合同模板与合同、签署、账单收款、业主结算、服务工单、管家会话等业务环节，按租户隔离数据。合同链路中，模板有版本与生效状态、条款有多语言正文与变量、合同实例保存生成时的模板版本与内容哈希、签署状态与签署名册逐方记录、租约保存固定租期与押金等条款快照以及印花与提交期限的证据状态。

这意味着系统里本来就在持续产生结构化的合同数据：不是一堆扫描件，而是有版本、有语言、有当事人角色、有状态、有时间戳、能追溯到具体业务对象的记录。这是加工数据层最省事也最可靠的起点。

#3.2 客户与验证条件

已有公寓运营方试用这套系统，其中部分表达了采购意向。

【待补：试用运营方名称、试用起止时间、试用的业务环节、采购意向的具体形式。这部分证据由申请方补充，本文不代为填写。】

#3.3 与本次研发的关系

上列系统与数据是原料来源和验证环境，不是本项目要交付的成果。本项目交付的是语料治理方法、规则单元库、字段结构、标注规范、独立评测集，以及使这套资产能被外部使用的接口与授权形式。这个区分在验收时逐项核对。

#四、现在怎么做，问题在哪里

现在处理合同数据的做法是分散的：

1. 法规以文本形式存在。要判断一份合同是否合适，需要人去读法条、查适用范围，再和合同条款逐条对照。判断过程留在人的脑子里，不进入系统。
2. 合同文本在系统里被存储和渲染，但没有被标注成可供判定的结构化事实。系统知道一份合同的内容哈希，不知道里面押金是几个月、通知期是几天、中英版本是否一致。
3. 租户修改模板的原因、法务看过的意见、以及后来这份模板生成的合同有没有出争议，这些最有价值的信息目前没有被系统记录，也就无法复用。
4. 双语合同里，中英文条款不一致是真实的风险来源。现在靠人逐份对照，没有机器可判定的对齐与冲突标记。

问题不是「模型不够强」，而是「没有可供判定的依据」。 因果链如下：

• 法规是文本，不是可执行的判定单元 ⇒ 模型只能凭公开知识给泛泛意见，说不清依据在哪一条；
• 合同没有统一字段结构和原文定位 ⇒ 输出无法被业务系统消费，也无法被人工逐条核对；
• 没有独立评测样本和固定评分标准 ⇒ 无法回答「准确率是多少」「换模型后有没有变差」，效果只能靠演示；
• 语料来源、脱敏授权、样本独立性没有成文方法 ⇒ 即使做出结果，也不能对外授权、不能公开方法、不能让别人复现；
• 判断结果不回流 ⇒ 每处理一份合同都从零开始，数据不会变厚，成本不随规模下降。

所以本次研发的对象是一套依据体系：让「模型给出的判断」变成「有来源、有结构、可复核、可评分、可授权的数据资产」。

#五、本项目研发内容

#5.1 语料接入与治理

输入：两类来源。第一类是已完成脱敏的各地真实合同数据集，由本项目按授权接入；第二类是系统运行中经租户授权沉淀的合同、租约、模板版本、条款变更历史与附件。

处理：为每条语料建立记录——适用地区、语言（繁体中文／简体中文／英文／双语）、合同类型、签订时间、来源、脱敏方式、授权范围、可否用于评测。脱敏在入库前完成，入库后不保留可识别当事人信息；来源可追溯，任何时候都能回答「这条数据从哪来、允许用在哪」。

输出：可查询、可按条件取用的语料库，以及一份成文的脱敏与授权协议。

要解决的难点：真实合同语料不是买一批文件就完事。来源合法性、脱敏是否彻底、授权是否覆盖二次使用、能否进入公开评测集，这些都要在入库前定好规则，否则后续所有成果都不能对外使用。这项方法学工作本身就是研发内容。

#5.2 规则单元库

输入：各地法律规定、公开范本、专业评审意见。

处理：把法规拆成最小可判定单元，每个单元固定七个部分：条款类别、该地区口径、依据出处、对租客或租户的行动含义、适用边界、生效日期、版本号。规则逐条经专业评审后入库；法律变更时新增版本，不改写旧记录，因为已签合同要按签署当时的规则版本解释。每条规则的输出自动携带「辅助检查，不构成法律意见」的边界声明。

输出：带版本、带依据、带边界的规则单元库，以及规则变更记录。

示例结构（说明用，不是完整规则）：涉及租约印花与提交期限的规则，需写清适用地区、依据的公开条例、对签约方的行动含义（例如需要在什么期限内完成什么动作）、以及本规则不适用的情形。评审要确认依据指向准确、边界不含糊。

要解决的难点：把法律文本翻译成机器可判定的单元，难点不在文字转换，在于写清「什么情况下不适用」。没有边界的规则会被误用，比没有规则更危险。

#5.3 字段结构与标注规范

输入：合同原文与规则单元库。

处理：定义要抽取的字段（当事人与角色、期限与起止、租金、押金、通知期、终止与解除、维修责任、税费、效力语言、附件等），规定每个字段的数据类型、必填证据、以及结论必须附带的原文位置。双语条款做对齐，中英不一致时双列输出并标记冲突。疑点与冲突由人工复核后打标签，标签本身也成为资产。

输出：字段结构定义、标注手册、带原文位置与复核标签的标注数据集。

作用：这一层决定人工智能的输出能不能被业务系统消费、能不能被人工逐条核对、能不能被测试集自动评分。没有它，输出只是一段文字。

#5.4 独立评测集与评分标准

输入：语料库、规则单元库、字段结构。

处理：按类别配比构建样本，明确划分开发样本与独立测试样本；评分标准在测试前写好并固定，包含字段准确率、依据可查率、双语差异识别率、边界情形处理、同一输入多次运行的一致性。独立测试样本只评分一次，开发期间不得用于调参。

输出：评测集、评分标准、评分脚本、逐条判定记录与失败案例库。

要解决的难点：样本独立性是最容易出问题的一环。如果同一批数据既用来迭代、又用来宣布达标、还计划对外发布，得出的数字没有意义。本项目把这一点作为硬性方法学约束写进研发流程。

#5.5 更新与回溯机制

输入：法规变更、规则新版本、新的复核结论、新的争议记录。

处理：建立规则版本与合同签署时点的对应关系；法规变更触发新增规则版本，同时标记受影响的模板与在履约合同；系统能回答「这份合同当时按哪一版规则判断」「如果按现行规则会有什么不同」。

输出：版本对照与影响清单、回溯查询能力。

#5.6 自带的最小验证应用

为了证明数据层可用，项目实现一个最小应用：输入一份合同，按字段结构抽取事实、与规则单元比对、输出带原文依据和边界声明的结构化判定结果。这个应用只用于验证数据层的完整性与判定质量，不作为独立产品交付，也不扩大研发范围。

#5.7 对外授权形式

输入：上述五层资产。

处理：划分可公开部分与专有部分。评测方法、评分标准、样本构建方法、字段结构规范可以对外释出以便复现；规则单元库、标注数据、租户相关的语料与运行回流数据保持专有，按授权使用。

输出：接口说明、使用边界说明、授权方式建议。

#六、数据层为什么「非我不可」

这一节是本方向的核心论据。

第一，只有运行中的多租户系统会持续产生这类数据。 系统按地区发模板、租户改了哪些条款、系统给出什么判断、租户采纳还是坚持、这个模板后来生成的合同有没有产生退租争议、投诉或纠纷——这条记录不是公开资料，也不是买一批脱敏合同能替代的。它只有在真实运营方每天用系统签合同的时候才会产生。

第二，数据会自己变厚。 每多一个租户、多覆盖一个地区、多处理一次争议，规则单元、标注样本、失败案例和边界情形都会增加；下一次判断因此更准，系统也更容易被新租户接受。这是随时间累积的效果，不是一次采购能买到的静态资源。

第三，方法学本身是门槛。 语料来源与授权、脱敏是否彻底、评测样本是否与开发样本分离、评分标准是否预先固定、规则版本如何回溯——这些问题在公开资料里没有现成答案，必须在有真实业务、有专业评审、有可复现环境的条件下才能定下来。定下来之后，这套方法可以反复用于新地区、新行业。

第四，模型可换，依据不可换。 更换基础模型后，全部资产仍然有效，而且能用同一套独立测试集判断新模型是否更好。这说明资产与模型是分离的，也说明它具备独立授权的前提。

#七、工程约束与责任边界

1. 只读与隔离：数据加工服务读取业务数据使用只读通道，租户归属由业务标识反查，调用方不能自行指定租户；未设定归属时默认拒绝访问。
2. 来源可追溯：每条语料、每条规则、每个标签都能查到来源、时间与责任人；不允许无来源的数据进入评测集。
3. 人工复核不可省略：规则入库、疑点标注、边界判定都需要具名复核；系统记录复核人与复核时间。
4. 辅助检查定位：全部输出携带「辅助检查，不构成法律意见」的边界声明；不提供规避法律义务的建议，此类请求直接拒绝并在评测中判为合格行为。
5. 故障降级：数据服务不可用时，原有业务流程照常运行，只缺失新增的数据结论。
6. 不可覆盖：规则版本、评分记录、复核记录只追加，不覆盖、不删除。

#八、十二个月安排

项目周期十二个月，研发集中在前六个月，后六个月用于规模扩充、真实环境验证、独立评测与授权准备。资助按官方计划分两期，每六个月做一次里程碑评估。

第 1 个月：方法学定稿 确定首批地区与合同类型；定稿脱敏协议、来源与授权规则、字段结构、规则单元结构、样本划分方法与评分标准。评分标准在这一步固定，之后不改。交付：方法学文件、字段结构定义、规则单元模板、脱敏与授权协议。

第 2 个月：语料入库 完成首批脱敏语料接入与系统沉淀数据的授权整理；建立来源记录与可追溯查询；完成入库前脱敏检查。交付：第一批可用语料库、来源清单、脱敏检查记录。

第 3 个月：规则单元库第一版 完成首批地区的规则单元拆分与专业评审，逐条核对依据与边界，建立版本机制。交付：规则单元库第一版、评审记录、版本对照。

第 4 个月：标注与字段抽取 完成字段结构实现、原文依据定位、双语对齐与冲突标记、人工复核标签；建立标注数据集。交付：标注数据第一版、标注手册、复核记录。

第 5 个月：评测集与最小验证应用 构建开发样本与独立测试样本；实现最小验证应用；跑第一轮开发样本评分并修正结构问题，独立测试样本不参与。交付：评测集、评分脚本、最小验证应用、首轮开发评分报告。

第 6 个月：研发收口 冻结研发版本；完成更新与回溯机制、只读隔离、故障降级、审计留痕；整理中期交付物。交付：完整数据层第一版、方法学与接口说明、中期评测报告。

第 7 至 9 个月：规模与真实验证 扩充地区、合同类型与规则数量；在试用租户环境中持续采集复核结论与争议记录，回流到标注与失败案例库；对失败案例逐条归因。

第 10 至 12 个月：独立评测与授权准备 用独立测试样本做一次最终评分；整理可对外释出的方法学部分与专有部分的边界；完成接口说明与授权方式建议；形成期末里程碑评估材料。

#九、交付物与验收方法

所有验收以可查记录与可重跑脚本为准，不以演示效果为准。

#十、为什么这个方向值得资助

研发内容是新的，且边界清楚。 现有系统存储合同，但不产出判定依据；本次交付的语料治理、规则单元、字段结构、标注规范、独立评测集与回溯机制全部从零建设。范围收在有限地区与有限合同类型，六个月可以做完并验收。

技术创新在方法与可复现性，不在模型。 把法律文本变成带依据、带边界、带版本的判定单元；把合同变成带原文位置的字段；把「准确」变成开发样本与独立样本分离后一次评分的数字。这些是数据与评测方法上的创新，任何只调用模型的做法都不会产生这些成果。

商业可行性强，因为它不绑定单一应用。 规则单元库、字段结构、评测方法可以作为独立产品授权：其他运营方、其他需要合同审核的行业，不必使用我们的软件系统也能使用这套依据体系，或者按自己的业务接入。同时，我们自己的软件系统因为这套数据而更难被替代。

成果留在香港并可跨行业复用。 研发与行政管理在香港进行，资产归申请主体所有。换一个行业，只要存在「有成文规则、有标准文本、需要逐条核对、判断结果要能追溯到依据」，这套方法就能迁移。首批以公寓租约起步，是因为这里有真实合同、有真实运行、有可观察的结果，而不是因为它只能用于公寓。

直接回应「套壳」质疑。 判断标准：换掉模型，产品还在不在。本方向换掉模型后，语料、规则、字段结构、标注、评测集、评分标准、回溯机制全部保留，且能用同一套独立样本证明新模型是否更好。模型是可替换零件，数据层是产品。

#十一、本次不覆盖的范围

• 不覆盖所有地区与所有合同类型，首批只做有限范围；
• 不训练或自研基础语言模型，基础模型使用第三方服务；
• 不提供法律意见，不出具法律结论，不代替持牌专业人士；
• 不声称评测集已覆盖所有情形，明确写出样本配比与未覆盖类别；
• 不把公开可释出部分与租户专有数据混在一起授权；
• 不建设面向终端用户的完整合同审阅产品，最小验证应用只服务于数据层验收。

#十二、待补证据

以下内容由申请方补充，本文不代为填写：

1. 试用运营方名称、试用起止时间与采购意向的具体形式；
2. 首批覆盖地区与合同类型的最终确认；
3. 脱敏真实合同数据集的来源、授权范围与可出示材料；
4. 参与规则单元专业评审的法律专业人士安排；
5. 系统沉淀合同数据用于研发与对外授权的租户授权安排。