探究：AI智能的一体化与模型引擎

【探究：AI智能的一体化与模型引擎的构建】—《由周国海教授AI项目办公室供稿》第一章一条链条：从设备换新走到识别效率一、先把四件事摆到一起问题先摆在这里：很多单位谈起一体化平台，会把它拆成四件互不相干的工作。设备采购归设备采购，系统整合归系统整合，数据治理归数据治理，模型开发归模型开发。四拨人各干各的，各自都有验收报告，年底一算账，识别效率却看不出变化。流程上的顺序其实不是这样。把四件事按先后摆好，它们是一条链条：设备换新，算力释放，系统协同，数据归集，识别效率提高。链条上任何一环卡住，后面的效果都出不来。这不是修辞，是工程上的事实。场景里最容易看明白。假设一家机构的老机房还在用十年前的机器，跑一次全量比对要等一个通宵。业务部门上午提一个想法，最快第二天早上才看到结果。这种条件下，模型做得再好也没有机会被反复试用。想法试不出来，模型就停在纸面上。时点上也藏着差别。机器跑得勤，一年能试二十个想法，跑得稀，一年试不了三个。设备更新带来的第一层收益，落在试错次数上，不在跑批时间上。问题在另一头也存在。机器换成了新的，机柜空出来了，任务却还按老办法串着跑，一份数据要在三个系统里各取一遍。算力多了，等待没少。设备换新只是把路修宽，车怎么开是另一回事。目标上还要算折旧。机器有使用年限，换一次要管五到八年。这几年里业务量会涨，规划时留出的余量不够，三年后又要排长队。换新不是一次动作，是一个周期里的起点。这里要提醒一句：四件事的顺序不是行政排序，是依赖排序。前一件没做完，后一件做了也白做，钱花了，账上好看，效果不明显。判断一个项目有没有走对，看它是不是在上一环没通的时候就开始下一环。目标上，链条要有人对整条负责。分段负责容易各扫门前雪，每段都合格，衔接的地方没人管。设一个总协调人，不必管具体事，只管衔接。二、算力释放释放了什么目标上要说清楚一件事：算力释放不是指机器变快，而是指过去因为等不起而放弃的做法，现在可以做了。举一个假设的场景。以前做一次全量关联，要把几千万条流水和几百万户登记信息放在一起对，跑一次要八个小时。八小时的代价是，只能一个月跑一次。月初的问题，等结果出来已经拖到月底。机器换新之后同样一次比对压到两小时，一周可以跑三次，问题的发现从月度挪到了周度。细节里藏着一个变化。压缩时间带来的不只是频率提高，还有试错空间。模型调一个参数，过去要等一天才知道效果，现在等一会儿。试错便宜了，人才愿意多试。多试的次数上来，模型才可能变好。流程上的这一步靠的不是聪明，是等待成本降下来了。流程上的第二个变化是并发。过去一台机器一次只能跑一个任务，几个部门排队，谁先谁后靠协调。现在可以把任务拆开并行跑，排队从人等机器变成机器等任务，协调成本跟着下降。需要提醒的是，算力释放有上限。任务的串行结构不改，机器再多也只是把等待摊薄。真正的提速来自把能并行的部分拆出去，再把必须串行的环节缩短。这件事靠梳理任务，不靠加机器。三、系统协同不是接口打通问题出在对打通这两个字的理解。很多项目把系统协同做成了接口对接，甲系统调用乙系统的接口，取到一个号码，看起来通了。可是同一个业务动作，仍然要在两个系统里各录一遍，两边各存一份，各改一次。接口解决了传输，没解决“谁说了算”。任务落到具体动作上，标准只有一条：同一件事只在一个地方发生。客户改了一个地址，改一次就够，其他系统看到的都是这一份。要做到这一点，得先承认有些系统的字段属于重复建设，需要合并，有的功能需要关停。这一步会动到部门的地盘，比写接口难得多。用户侧的体感很直接。窗口人员办一笔业务，过去要在三个界面之间切换，抄两遍号码，错一个字就要重来。系统真协同之后，界面可以是一个，录入可以是一遍。评价一个单位的协同水平，问窗口人员一天切换几次界面，比看架构图可靠。四、数据归集落到同一个底座策略上有取舍。数据归集不是把所有数据都搬到一个库，那既不现实也不经济。该进来的是需要跨系统比对的那部分，能算清来源、能说清用途、能追到责任人的那部分。任务到这里变成对得上。同一个企业，在申报系统里的名称、在发票系统里的税号、在银行流水里的账户名，未必一致。同一件商品，在不同企业的开票品名可能千差万别。没有标准化，关联是一句空话。假设一家制造企业，登记名叫某某精密机械有限公司，开票时用的是简称，银行开户名里多了两个字。三份材料放在一起，人眼一看就知道是同一家，机器看不出来。这样的情形在一个库里可能有几千处，靠人工逐条核对，成本高得做不下去。流程上，这类情形要先解决高频的。把出现次数最多的几百种写法收干净，能覆盖大部分记录，剩下的交给人工。想等全穷举再动手，往往永远动不了手。五、识别效率是最后出现的结果识别效率这个词，常被当成平台的性能指标，其实它是链条末端的产出。它由三部分组成：该发现的问题发现了多少，不该打扰的对象少打扰了多少，从数据变到结论用了多久。这三件事都取决于前面几环。数据没归集，覆盖不全。口径没统一，判断不准。算力不够，结论出来得太晚。单看某一环的验收报告，都合格，合起来却不产生效率。流程上还有一个容易忽略的环节，是指标本身。什么算该发现的问题，什么算不该打扰，这两句话要先写成条目。条目不清，三个数就成了各说各话，效率高低全凭汇报人的说法。一个单位如果连自己要什么都说不清，平台建得再齐，也只是把力气花在了不合适的地方。问题也就清楚了：一体化平台的建设顺序，不能按部门意愿排，只能按链条依赖排。哪一环还没通，就把资源压到那一环，别急着在末端加模型。末端加模型是见效最快的动作，也是最容易白花钱的动作。目标定下来之后，接下来的任务是把链条的后几环拆开看。系统为什么并不到一起，是下一章要回答的问题。读者可以先做一件事：把自己单位现有的系统列一张表，标出哪些字段在两个以上系统里重复存在。这张表就是后面所有工作的起点，建议本周内先做十个高频字段，不必等全量清单齐备。第二章系统为什么并不到一起一、每个系统当初都是好办法问题得从历史看。任何一个今天拖着后腿的系统，当初上线时都解决过真问题。申报系统解决了纸质报送，发票系统解决了票面核验，流水系统解决了对账。每个系统都在自己的地盘上干得不错，边界也划得清楚：它管什么，不管什么。流程上，系统的边界从来不是数据边界，而是组织边界。谁出钱建的，谁就定字段。谁负责验收，谁就定口径。两个系统之间要不要打通，取决于两个部门当年有没有谈成。数据不会自己长腿，它跟着权力走。场景里能看得很清楚。一个客户信息，在三个系统里有三份，三份都对，因为各有各的用途。申报要的是登记信息，发票要的是开票抬头，流水要的是账户名。三份各自维护，各自准确，合起来却对不上号。时点上，分裂有先后。先建的管申报，后建的管开票，最晚建的管资金。越晚建的越贴近业务，越容易被当成权威，老系统于是被架在半空，谁都改不动。目标上就出现分歧。有的人认为对不上号是技术问题，加一个映射表就解决了。有的人认为这是管理问题，得有人拍板定唯一口径。两种看法都对一半，落在具体工作上，前者便宜，后者难。流程上，还有一个细节常被漏掉，就是更新频率。甲系统每天更新一次，乙系统每月更新一次，两份数据放在一起，同一个时点的差别会被当成矛盾。合并之前，先要把时间口径对齐。二、同一个对象，几套身份用户遇到的麻烦，从身份开始。同一家企业，在不同系统里有不同的编号、不同的名称、不同的联系人和不同的地址。系统各自认为自己那份是真的，谁也不认别人的。场景里有个假设的例子。一家企业变更过名称，登记系统里是新名，发票系统里还有旧名的历史票，银行流水里用的是开户时的简称。三份记录都真实，都能追到人，却指向同一个主体。人工看三眼就明白，机器看三份互不相关的记录。问题在商品这一头更细。同一件东西，在这家企业的开票品名里叫一个名字，在那家叫另一个名字，规格型号的写法也不统一。企业的会计按自己的习惯填，系统按字符存。要按品名归类，先得把几千种写法收成一两百个标准类目。账户的麻烦带点模糊。一户多卡，公私混用，代收代付，同一个账户名背后可能挂着几家企业。这类数据天生不干净，指望它一进来就整齐，不现实。需要说明的是，不干净的数据不能一删了之。它们背后是真实的历史业务，删掉一处就丢一条线索。可行的做法是保留原样，在旁边加一列推断出来的标准身份，同时记录这一列的置信度和来源。三、三笔看不见的账问题在于，系统各自为政的成本不进财务报表，却天天在发生。第一笔是重复录入的账。同一份信息，窗口人员录一遍，后台人员再录一遍，两边都不放心对方。按一个窗口一天办二十笔、每笔多录三分钟算，一年累积下来是一个岗位的工时。第二笔是对不上的账。月底对账，发现两个系统的数目差了几笔，要派人一条条查。查出来的原因往往不是错账，是口径不同。这类工时没有预算科目，也没人统计。场景里，对账还有一笔隐形成本。为了对上，两边各建一套校验，规则互不通气。真对不上时，先怀疑数据错，再怀疑人错，很少想到规则本身就不一样。问题还有第三笔，账在查不动。业务上想问一个跨系统的问题，比如某类企业近半年的开票和收款是否匹配，得先找三个部门取数，再用表格拼。一个问题等一周，问的人就懒得问了。问不出来的问题，其实等于不存在。流程上，这三笔账要有人记。不必做成大报表，一张月度台账就够：重复录入几次，对账耗了几个人天，跨系统取数被退回几次。三个月下来，账上能看出哪个环节最贵，改造的顺序也就有了依据，不必靠开会排序。三笔账加起来，是一个单位真实的信息成本。它不体现在报表上，只体现在人不够用、事办不快上。四、加接口为什么不够策略上，很多单位选择的路径是先加接口。接口便宜，见效快，还能写进验收报告。问题在于接口只搬运数据，不改变数据的样子。任务落到接口这一层，能解决的是“取得到”，解决不了“对得上”。甲系统把一列名称传过来，乙系统拿到的是几百种写法的字符串。要不要合并、按什么规则合并、合并错了谁负责，接口一概不管。流程上的另一个隐患在字段名。两边表里都有同一个词，含义却不一致，对接上线时没人细看，跑出来的结果两头都说不清。场景里还有一种更隐蔽的情况。接口按字段对接，字段名一样，含义不一样。一个叫“状态”，在甲系统指审批状态，在乙系统指账户状态。对接上线时没人细看，跑出来的结果两头都说不清。流程上的顺序应当是先定语义，再定接口。语义这件事靠人谈，谈完写成文档，文档里要写清楚每个字段是什么、从哪来、怎么算、谁能改。这一步谈不完，接口越加越多，最后变成一张谁也看不懂的网。五、不能推倒重来，只能增量整合现实约束摆在那里。系统不能推倒重来，业务不能停，历史数据不能丢，人员习惯也改不动。任何一体化方案，如果前提是“先把旧的都停掉”，基本推不下去。可行的路子是增量整合。先选一条业务链，把这条链上的系统按一个底座接起来，跑通了再往下一条链扩。每扩一条，旧系统退一点，能关的关，能降级成数据源的降级。目标上要接受一个事实：整合是长期工程，不是一次上线。中间会有几年时间是新旧并存的，并存期的问题要有专人管，不能指望它自己消失。策略上还要留一份退场名单。整合方案里写明哪几个系统是过渡件、哪几个要长期保留，没有这份名单，过渡件会一直过渡下去，变成新的包袱。目标上，退场要有次序。先停新增，再停查询，最后停维护。三步走完，数据归档，系统下线。一步跳到停机，业务会反弹，反弹一次就退不回去了。问题回到起点：并不到一起的根子不在技术，在身份和口径没有统一的主人。谁定身份，谁定口径，这是下一章要接着谈的事。读者可以先做一件事：挑一条跨三个系统的业务链，把这条链上每个环节的录入动作列出来，数一数同一份信息被录了几遍。这个数字通常比想象的大，建议一周内完成这条链的梳理，作为整合方案的第一份底稿。第三章把系统并到一个底座上一、底座指的是四样东西问题先定义清楚。底座不是一个软件产品，也不是一个大数据库，它是四样东西叠在一起：一套统一的存储，一套主数据，一套公共服务，一套权限与审计。流程上，这四样各有分工。存储解决数据放在哪里，主数据解决谁是谁，公共服务解决不用重复写代码，权限与审计解决谁能看、看了留不留痕。缺哪一样，底座都撑不住。场景里常有这样的错位。单位买了一套平台软件，装上就算完成，结果发现主数据没建，同一个客户在平台里还是三个号。存储有了，服务有了，人和组织没对齐，平台就只是一个新壳子。目标上要避免一种误解：以为底座必须是一家厂商交钥匙。底座的核心是标准和主数据，技术选型可以分散，标准必须唯一。流程上还有一个常被跳过的环节：给主数据指定责任人。每类主数据都要有一个具体的人，负责它的新增、变更和争议。没有这个人的名字，主数据表建好三个月就开始失真。二、三种并法，各算各的账策略上，业界常见的并法有三种，各有代价。物理集中最直接，把各系统的数据抽到一个库里，统一加工。它的好处是查询快、关联方便，坏处是同步复杂，历史数据要迁一遍，业务系统的更新要实时追。逻辑集中不搬数据，只建一层视图，查询时到各系统取。它的好处是改动小、上线快，坏处是性能受制于源系统，源系统一慢，全链路跟着慢。联邦式介于两者之间，主数据与高频比对的数据集中，明细数据留在原处，用时再取。它的好处是平衡，坏处是边界难划，划不好就变成两头都不够干净。问题在于选哪种，不能凭偏好。要看三件事：比对有多频繁，时效要求多紧，源系统能不能扛住被反复查。三件事都指向集中，就走物理集中。指向宽松，就走联邦。成本上要提前算清楚。物理集中的一次性投入在迁移和清洗，之后每次新增数据源都要接一遍。逻辑集中的一次性投入小，日常却要承担查询带来的压力，源系统一出故障，下游全停。联邦式的账最难算，它把复杂性留在了边界上，需要有人长期盯着。场景里，选法还会受历史包袱影响。老系统跑在旧机器上，迁一次要停机两天，业务部门不批。这类约束摆在明面上，选法就得往逻辑集中偏。三、先定一件事只在一处发生任务落到最具体的一步，是把同一件事的唯一发生地定下来。客户地址在哪里改，企业名称在哪里改，账户状态在哪里改，各定一处。定的过程会遇到阻力。每个系统都认为自己的字段最权威，理由也站得住，因为它离业务最近。这时候需要一个裁决规则，而不是一次次会议。规则可以很简单：以“对外产生法律效力的那份”为准。登记信息以登记系统为准，票面信息以开票系统为准，资金信息以账务系统为准。定完之后，其他系统这份字段改成只读，通过同步获得更新。场景里，这条规则能省掉很多争论。争论的本质是谁的地盘大，规则的用处是把争论变成查表。场景里，迁移期还有一道关，就是双跑。新旧两套并行一段时间，逐日对账，差一笔查一笔。双跑不设期限，就会一直跑下去，成本翻倍，人心也散。目标上，这份规则要落到文件里。哪类字段以哪个系统为准，写成一张对照表，发到各系统归属部门，改动要报批。口头共识撑不过一次人员调动。四、进来什么，留在外面什么问题还得算账。全量归集听着痛快，成本却高，维护也难。合理的边界按用途划：需要跨系统比对、需要长期留存、需要对外出证的，进底座。只服务于本系统操作的，留在原处。时效上分三层。需要秒级响应的，走实时通道。需要分钟级的，走准实时。可以过夜的，走批量。三层分开，成本才压得住。场景里，三层不分会出怪事。一个季度才看一次的分析报表，硬要走实时通道，结果为了它把整套实时链路撑起来，成本翻几倍，业务又用不上。分层的第一件事是问清用途，不是先定技术。流程上要写清楚每层的数据从哪来、多久更新一次、出问题找谁。这三条写不清，底座就会变成一个谁都在用、谁都不负责的地方。问题在这里最容易积压。三层一分，边界上就会冒出没人认领的数据，今天甲部门说该乙部门供，明天反过来。边界要有唯一的一张登记表，不能靠记忆。目标上，底座还要能对外交换。跟上级单位、跟合作机构对数据时，格式要能一键导出，不能临时找人写脚本。交换格式定一次，长期用，比每次现做省事。流程上，迁移要保业务连续。切流放在业务低峰，切换前先演练一次，回退方案写清楚。演练不做，真切的时候才发现少了一步。五、组织前提是谁有权改别人的系统目标最后落在人身上。技术方案写得再细，如果没有人有权要求甲系统改字段、乙系统停功能，整合就推不动。可行的安排是设一个跨部门的常设小组，成员来自各系统的归属部门，组长由能拍板的人担任。小组不管日常运维，只管三件事：定主数据、定口径、裁争议。问题在这里容易半途而废。小组设了，但没有裁决权，开会只能协调，协调不成就搁置。搁置几次之后，没人再来开会。流程上，底座建成之后还要有人值守。每天看三件事：数据到没到，主数据有没有新冲突，服务有没有超时。值守不必专职，但要有人名，谁值班写清楚。没有这道值守，底座出了问题只能等业务部门先发现。场景里还有一种现实困难。有些系统的归属部门已经撤并，找不到人负责。这类系统要先做一件事，指定临时代管人，代管期内把它降级成数据源，别再让它产生新数据。策略上，权限也要跟着一起收。数据并到底座之后，谁能看什么要重新划一遍，不能沿用各系统原来的权限。原来的权限是按部门给的，底座上的权限要按用途给。这一步不做，整合之后反而更容易越权看数。流程上，小组的议事要留记录。每次裁决写清争的是什么、依据是什么、谁签的字。下一次遇到同类问题，翻记录即可，不必重开一次会。任务清单可以很短。第一步选出三条跨系统业务链，第二步为每条链定一个唯一发生地，第三步把这三条链涉及的主数据建起来。三步做完，底座才算有了骨架，剩下的扩容可以慢慢来。建议先把第一步的链选出来，两周内定稿，别等全量方案。第四章标准化：最容易被低估的苦活一、标准化不是格式转换问题从一个常见的误会开始。很多人以为标准化就是把日期统一成年月日，把金额统一成两位小数，把编码统一成大写。这些是格式，做完只花几周，做完也看不出变化。标准化真正的含义是“同一对象同一编码”。同一家企业，无论在哪个系统、哪张表、哪一年出现，都指向同一个编码。同一件商品，无论企业怎么写，都归到同一个类目。这一步不是转换，是判断。流程上的差别很大。格式转换可以由程序自动跑，判断必须有人定规则，还得有人为规则兜底。前者是工程，后者是治理。场景里能看出代价。一家单位的标准化只做了格式，两年后做关联，发现同一个客户有七个号，每个号都格式正确。格式对了，身份还是散的。流程上，判断的标准要写成看得懂的规则。不是给程序看的正则，是给人看的话：名称去掉括号里的后缀算同一个，税号相同算同一个，账户名与登记名相差两个字以内进入人工复核。场景里，规则写得越像人话，越容易被业务接受。写成一行正则，业务看不懂，出事只能找技术。写成一条件一句话，业务能自己判断，也能自己改。二、三个层次，一层比一层难任务可以拆成三层，逐层往上。字段层最浅，把同一含义的字段改成同一个名字、同一种类型、同一套取值。这一层能靠梳理完成，成本可控，收益也直观。流程上，字段层的工作可以用清单推进。把两个系统里含义相近的字段列成一张对照表，逐条确认是不是同一含义，确认一条落一条。这张表做完，对象层的规则才有地方落脚。对象层是核心，把散落在各处的记录归并成唯一主体。企业、个人、商品、账户、地址，每一类都要有一套归并规则。这一层的难点不在算法，在容忍度：并得太松会错并，并得太紧会漏并。关系层最深，把对象之间的关联也标准化。母子公司的关系、代理人与企业的关系、账户与实体的关系，都要有统一的表达。这一层做完，穿透才有可能。问题在于三层不能跳。字段没统一就做对象归并，规则会建在一堆别名上，越往后越乱。对象没归并就做关系，穿透出来的图是一张断线图。场景里，对象层的规则最容易走偏。有人为了追求归并率，把名称相近的都并在一起，结果两家不相干的企业被合成一户，一户的流水挂到另一户头上。这类错误一旦进了库，下游的判断全跟着错。目标上，对象归并要留一条人工入口。自动归并覆盖大多数，剩下的靠人判。人工入口不是补丁，是规则的一部分，得有排班，有记录，有反馈。三、为什么它苦策略上要承认，标准化是苦活，苦在三处。第一处是没有标准答案。同一家企业叫两个名字，哪个算正名，没有教科书。行业惯例、登记信息、历史票面，各有各的道理，最后要靠一个能负责的人拍板。第二处是要长期维护。企业会改名，会迁址，会分立合并。标准表建完那天起就在过期，没人维护，两年后就不可用。第三处是成果不可见。做了半年标准化，界面上什么都没变，业务部门看不出价值。它的价值要到关联和穿透跑起来才显形。目标上要接受这个现实：标准化投入要按年算，不能按项目算。按项目算，验收一过就没钱维护，前面白干。问题在第三处最伤士气。做标准化的人干了一年，写了几百条规则，界面上什么都没多出来，年终考评说不出成绩。留不住人，规则就断档。目标上，标准表要和业务字典对上。业务嘴里说的是行业术语，表里存的是字段名，两套词不通，一线就不知道查哪一条。字典不必大，能覆盖常用说法就够。四、标准表是养出来的流程上更可行的做法，是把标准表当成一份活的资产来养。养的第一步是有一个明确的维护人。这个人不属于任何业务部门，属于数据管理条线，职责是接变更申请、评估影响、发布新版本。养的第二步是版本可追。每一条归并关系都记录什么时候加的、依据是什么、谁批的。将来并错了，能回退，能查到当时的判断。养的第三步是让人愿意报错。一线发现并错了，要有地方报，报了要有人接，接了要有回复。没有这条通道，错误会一直在库里躺着，越积越多。场景里有个细节值得注意。很多单位的标准表是靠一次集中清洗建起来的，建完就封存。封存那天的准确度可能不错，一年后就不行了，因为新数据没进来，旧关系没修。目标上，维护要有固定预算和固定人手。这笔钱不多，一年几个人月，但不能没有。省掉它，前面几年的清洗会在两年内耗光。流程上，外购数据的标准要一起管。买来的工商信息、司法信息自有一套编码，接进来要映射到自己的标准，映射表也要维护。只接不管，两年后两份标准就打架。目标上，标准表要经得起审计。每条规则写清谁提出、谁批、依据是什么。审计问起来，能一条条翻出来，不必临场解释。五、只做格式统一的假标准化问题还有一种表现，叫假标准化。表面上字段都统一了，实际上一到关键判断就绕开标准，回到人工看名字。判断真假有个简单的办法：随机关掉标准表，看系统还能不能跑。能跑，说明标准表只是摆设，关键逻辑还在用原始字段。跑不动，说明它真的在承重。策略上，建议把标准表的调用率当成一项常规指标。哪些业务在调用，调用多少次，绕过的有多少。数字低的地方，就是下一轮要改的地方。场景里，标准化的效果要到第二年才看得见。第一年在建表和改规则，第二年新数据进来，归并自动命中，人力才省下来。急着在第一年要成绩，往往把工程做成演示，演示完就没人再提。流程上还有一个检查动作要固定下来。每季度抽一批新入库的主体，看归并是否命中，抽到的错并要写进规则修订。抽查比例不必高，抽查这件事本身要形成惯例。任务收在这里：标准化没有捷径，但可以分期。先做企业、账户两类对象，再做商品与地址，最后做关系。这两类对象覆盖了大部分关联需求，做完就能看到效果。问题回到一句话：标准化是苦活，也是最不该省的一环。它省不掉，只能排队做。接下来要回答的是，怎么让同一家企业在这个底座上只有一张脸。建议先从一个高频对象开始试点，把归并规则和复核流程跑通，再推广到其他对象。第五章让同一个企业只有一张脸一、四份材料，一个主体场景从一个窗口开始。企业来办一件事，交上来四份材料：营业执照的复印件，上一年度的申报表，一张增值税发票，一份银行开户信息。四份材料上的名字，写得不一致。流程上，窗口人员凭经验判断这是同一家。执照上是全称，申报表上是简称，发票上是开票抬头，开户信息里多了两个字。经验够的人三秒就能判断，经验不够的人要打电话核实。流程上还有一层难处。企业的名字会变，改完名之后旧票还在，新票用新名，两份材料隔了几年，机器更容易判成两家。时点上，改名有滞后。登记变了，票面要等下一次开票才变，流水要等下一次开户才变。三份材料在一年里可能同时存在新旧两个名字，机器若不看时间，还会判成两家。问题就出在这里。人工靠经验能做的事，到了系统里没有经验可用。系统只看到四个字符串，它会认为这是四家企业。一个库里如果有几百万个主体，这种情形会有几万处。目标很清楚：让同一家企业在这个底座上只有“一张脸”，无论它从哪个门进来，都能认出来。二、四类线索，由强到弱任务落到规则设计上，可以把线索排成四档。强标识最可靠，指那些天生唯一、不会重复的东西。统一社会信用代码、税号、开户许可证编号，属于这一档。两个记录强标识相同，基本可以判定为同一主体，不需要人工复核。弱标识次一档，指名称、地址、电话、法人姓名这类可能重复但不必然唯一的信息。名称一字不差也可能撞名，地址相同更是常见。这一档能缩小范围，不能单独定论。行为标识再弱一层，指交易对手、开票品名、申报习惯这类由行为留下的痕迹。两家企业如果长期互开票、共用同一个联系电话、在同一地址申报，它们之间有关系，但不一定是同一家。关系标识指股权、任职、代理这类登记在案的关系。它的作用不是判断同一性，是判断一个主体簇的边界。场景里，四档的强弱不是理论推的，是被数据验证过的。同一个税号同时出现在两份记录里，几乎不可能是巧合。同一个地址挂着十家企业，那多半是写字楼，反而说明不了问题。流程上，个人主体比企业难办。一个人可能有多个身份，法定代表人、股东、经办人、实际控制人，各自登记在不同表里。归并个人，要先分清是哪一种身份在出现。策略上，四档要串起来用。先用强标识做精确归并，再用弱标识做候选，再用行为与关系做验证。单用任何一档，都会出问题。三、机器不敢判的交给谁问题在于，真实数据里有一大批落在中间地带。强标识不全，弱标识相似度七成，机器判不了，人也不能不管。可行的做法是把判断分层。相似度高的自动归并，相似度低的自动分开，中间一段进入人工复核队列。复核队列要有三个设计。一是排序，按影响面排，涉及金额大的先看，涉及户数多的先看。二是留痕，每条判断记录复核人和依据，将来出错能回溯。三是回收，复核过的结果要能反馈到规则里，让下一轮自动判的准确率高一点。场景里，复核队列常被忽视。上线时设了，没人排班，队列越积越长，最后没人看，中间地带等于放弃。问题在于复核人的水平不一致。同一批中间案例，换一个人看，结论可能不同。要让结论稳定，得有一份判断手册，把常见情形写成条目，复核人照条目判，遇到条目外的情形再上报。目标上要给复核定工作量。一天看多少条，一周清一次，这些数要写进岗位职责，不能靠自觉。四、错并比不并更危险策略上有一条容易被忽略的原则：宁可漏并，不可错并。漏并的后果是同一家企业被当成两家，看数时分散，最多是没看出来。错并的后果是两家企业被当成一家，一家的流水挂到另一家头上，结论会直接指向错误的对象。流程上还有一个护栏，归并关系的变更要留审批。有人想把两家并起来，得说明依据，得有人批。放开让谁都能改，错误就会慢慢积累，最后没人敢信这张表。场景里，错并的代价常常延后暴露。并的时候看着合理，半年后一笔资金流向不对，才发现两家企业被合成一户。延后暴露的特点是没有即时反馈，人就容易松。流程上要为此留出回退能力。每一条归并关系都记录来源、依据和版本，错了能拆开，拆开之后下游的结论能重算。没有这项能力，一次错并会在库里留很多年。问题还有一种变体，叫链式错并。甲并到乙，乙并到丙，丙又并到丁，一条链上错一环，整条链都歪。防它的办法是限制归并层级，超过三层的关系必须人工确认。五、商品与账户的口径场景换到商品。同一件东西，企业开票时写法五花八门，有的写型号，有的写用途，有的干脆写一句笼统的话。要按品名做归类，先得把几千种写法收成一套类目。目标不是把所有写法都穷举完，是覆盖高频部分。八成以上的票面集中在一批常见写法上，把这一批收干净，归类就能跑起来，长尾部分用规则加人工慢慢补。账户的口径更麻烦。一户多卡、公私混用、代收代付，同一个账户名后面可能挂着几家企业。处理这类数据，靠的是把账户当成线索，不当成结论。流程上，商品归类要有一条收敛线。收到八成覆盖就可以先跑，剩下的长尾不值得投入同等精力，交给人工判断更划算。任务收在一句话上：企业、商品、账户三类对象，各有各的归并逻辑，但原则一致，强标识优先，弱标识辅助，中间地带交人，错了能退。场景里还有一种情况，账户名里带编号。企业为了区分项目，在账户名后加一段数字，同一个主体在流水里成了几十个不同名字。这类写法有规律，靠规则能收掉大部分。流程上，归并规则要定期复盘。每季度抽一批新判定的案例，看自动判的准不准，人工判的稳不稳。复盘发现的问题写回规则，规则才跟得上数据的变化，不至于两年后又得从头清洗一遍。场景里，归并结果要让人看得懂。每户下面列出曾用名、曾用号，点开能看合并依据。看得懂，业务才敢用，也才愿意报错。问题最后回到治理。谁定归并规则，谁负责复核队列，谁批准规则变更，这三件事定不下来，标准表就养不住。具体可以先从企业这一类对象做起，把四档线索和复核队列跑通，再复制到商品与账户。建议先跑通一个季度的复核闭环，再谈扩大范围，不必一上来就追求归并率。第六章把模型装进平台一、模型睡在个人电脑里问题从一个常见的画面开始。单位花了不少钱请人做模型，模型做出来了，效果也不错，可是它跑在谁的电脑上，只有那个人知道。流程上还有一个信号。一个模型到了只有一个人会跑的地步，它其实已经处在失效边缘，只是暂时没人发现。时点上，模型失效往往没有明显信号。它不会报错，只会慢慢变得不准。等业务部门察觉，通常已经用了几个月。流程上，一个模型从想法到落地要经过很多手。取数是手工的，特征是自己拼的，参数是试出来的，结果存在一个表格里。人一走，表格找不到，模型就没了。场景里还有一种情况，模型在，但没人敢用。问它为什么给出这个结论，答不上来。业务部门不敢拿一个说不出理由的结果去处理具体的事。目标上要解决的不是模型好坏，是模型能不能被复用、被检验、被交接。这三件事，靠的不是更聪明的算法，是平台。二、三种装法，缺一不可策略上，把模型装进平台有三层含义，缺一层都不算装进去。算在平台里，指模型的计算跑在平台的算力上，不再依赖某个人的电脑。它带来的好处是稳定，谁休假都不影响跑批。管在平台里，指模型的输入、输出、版本、责任人都在平台登记。谁在用这个模型，用的哪一版，什么时候上线的，一查就有。用在平台里，指业务人员通过平台调用模型，结果回到业务流程里，不是一个孤立的报告。这一层最难，因为它要求模型嵌进流程，而不是停在演示。场景里，第三层最难落地。业务人员不习惯看模型输出，他们习惯看一张表、一个清单。模型结果要变成清单里的一个标记，才算真的进了流程。问题常在第二层出。模型上线了，版本没登记，半年后两个人各改一版，跑出来的数对不上，谁也说不清哪个是准的。三、从取数脚本到指标定义任务落到最基础的一层，是把手写的取数脚本变成指标定义。取数脚本的问题是它只对写的人友好。换一个人接手，要读代码才知道这个数是怎么来的。指标定义不一样，它用文字写清楚：叫什么，怎么算，数据从哪来，多久更新，谁负责。问题在于指标一多就乱。同一个意思，三个部门各起一个名字，各算一遍，最后对不上。指标要有唯一编号，一个意思一个编号，改口径就是换编号。流程上，模型上线前还有一道手续常被跳过，就是和业务对齐判断标准。模型说异常，业务说的异常是不是同一件事，要先谈清。谈不清，上线后每条结论都要解释一遍。流程上，一个指标定义要经过三道确认。业务确认口径对不对，数据确认取数取不取得到，管理确认这个指标谁来维护。三道都过了，指标才算成立。场景里，指标定义最容易被写成一句空话。比如写成“近半年开票金额”，没写含不含作废票，没写按开票日期还是认证日期。差一个字，算出来的数能差很多。流程上，定义旁边还要放一份说明。说明写给人看，讲清这个指标回答什么问题、适合什么场景、不适合什么场景。没有这份说明，指标会被拿去用在不该用的地方。目标上，指标定义要写到能让人独立复算。拿一份定义给另一个部门，他按定义能算出同样的数，这份定义才合格。四、模型也有寿命问题在于，模型不是上线就完事。它会过期。过期有三个原因。一是数据变了，原来的规律不成立。二是业务变了，政策调整，判断的标准跟着变。三是环境变了，上游系统改了字段，模型的输入悄悄变了样。策略上，要给模型定一套生命周期。上线要有评审，运行要有监控，效果下降要有预警，失效要有下线。监控看什么，至少看三样：每天调用的次数，输出的分布有没有突变，人工复核的推翻率有没有上升。三样里任何一样异常，都要有人去看。问题在于预警的阈值不好定。定得太松，异常报不出来。定得太紧，天天报警，最后没人看。可行的办法是先跑三个月，看正常波动的范围，把线放在范围外一点。场景里，模型说不清理由时，有三种补救。看它依赖哪几个输入，看类似案例的判定，看阈值移动后的变化。三种都不完美，但比一句模型算出来的要强。流程上，下线的动作常被忘记。一个模型没人用了，还挂在平台上，占着资源，还容易被误用。下线要正式，写清时间、原因、替代方案。五、平台该提供什么目标上，平台要提供的不是算法库，是四样基础设施。样本要给得出来。历史上人工判断过的案例，要能按时间、按类型取出来，标签清楚，能直接用于训练和验证。特征要算得出来。企业、账户、商品的基础特征，平台上算一次，各处复用，不要每个模型自己拼一遍。回溯要跑得起来。模型上线前，拿历史数据跑一遍，看它当年会怎么判，和人工结果比一比。没有回溯，模型只能上线后再看效果，代价太大。版本要管得住。指标有版本，模型有版本，规则也有版本。任何一次结论，都能追到当时用的是哪一版。目前，四样里最容易缺的是回溯。很多单位的数据是边用边补的，历史上的时点数据没留，想回溯也回不去。这类问题要在数据归集时一并解决，事后补不回来。不过要说明的是，四样基础设施不是一次建成的。样本可以先攒，特征可以先用现成的，回溯和版本要靠日常积累，急不来。场景里，样本还分好坏。人工判过的案例是好的，被模型标成异常却没核查的案例，标签是空的。拿空标签去训练，等于教模型猜。目标上，指标的名字要稳定。名字一改，用它的报表、模型、文档全要跟着改。可行的做法是名字只增不改，确实要改就新建一个，旧的标明停用，别直接覆盖。流程上，模型要能被复用。同一个判断逻辑，换个业务场景能不能直接用，取决于它的输入是否抽象成指标。绑在一张具体表上的模型，换个场景就要重做。任务收在这里：把模型装进平台，本质是把模型从个人资产变成单位资产。这一步做完，模型才谈得上迭代。读者可以先做一件事：把现在在用的模型列一张表，写清每个模型跑在哪、谁负责、最近一次验证是什么时候。这张表会让很多单位发现，自己以为在用的模型，其实只有两三个还活着。建议本月内完成摸底，先把责任人补齐。第七章从单户画像到关系穿透一、单户全景是一张合并的档案问题先从一个提问方式说起。业务上想问的一句话常常是：这家企业到底什么情况。要回答这句话，得先把散在各处关于它的记录合并到一页上。流程上，单户全景的做法是把三类记录叠起来。登记类记录告诉你它是谁，申报类记录告诉你它报了什么，交易类记录告诉你它跟谁往来、钱从哪来到哪去。三类叠在一起，才算一张完整的档案。场景里，没有全景的时候，业务人员是怎么干的。打开申报系统看一遍，打开发票系统看一遍，打开流水系统再看一遍，三个屏幕来回切，脑子里拼。拼得对不对，全凭经验。目标上，全景的价值是省掉这一次次的拼。点开一家企业，看到的应当是一页能读的档案，而不是三个系统的入口。不过要提醒一句，全景不等于把三张表拼在一页上。拼在一页只是展示，能不能对上号才是关键。前面几章讲的标准化和归并，在这里第一次显出用处。二、为什么单户还不够问题在于，风险很少只藏在一户之内。举一个假设的例子。一家企业自身看着很正常，申报不低，开票不多，流水也平。可是它的上游只有一家供应商，下游只有两家客户，上下游又都和同一批人有关系。单独看每一户都正常，放在一起看，像一个闭环。场景里还有一种情形，钱从多处来。一家企业的账户收款来自十几户，单看每一笔都不大，合起来占了它收入的大半。单户画像里这是一家常户，关系图里它站在一个扇形的中心。时点上，闭环的形成需要时间。今年上下游各一家，明年可能变三家。关系图要按季重画，画一次就封存，看到的只是某一年的样子。场景里还有一种更常见的情形。企业换了名字，旧主体注销，新主体成立，业务接着做。单户看，旧户是结束，新户是开始，两不相干。把关系拉出来看，是同一批人在换壳。目标上，识别不能停在单户，要能从一个点走到一片。流程上，全景还要有时间维度。一张只有当前状态的档案，看不出变化。把近三年的申报、开票、流水按时间排一条线，才能看出什么时候开始不对劲。三、三种关系，各有各的拉法任务落到技术上，关系可以分三类来拉。股权关系最确定，来自登记信息。谁持股谁，持多少，什么时候变的，都能查到。它的价值在于给出一个稳定的骨架，穿透从这里起步最稳。交易关系最活跃，来自票流和资金流。谁给谁开票，开多少，多久一次，钱怎么回流。交易关系反映的是当下的往来，变化快，噪音也大。人员关系最难拉，来自任职、代理、联系方式、地址。同一个人在两户企业任职，可能是正常的兼职，也可能是同一伙人在操作。这类关系要靠多条线索相互印证。流程上，三类关系都有时效。股权关系的变化以登记为准，滞后几天。交易关系按天更新，细一点按小时。人员关系最慢，靠任职变更和联系方式变更才更新。混在一起用，容易把旧关系当新情况。策略上，三类关系的用法不同。股权用来定边界，交易用来找异常，人员用来解释异常。只拉一类，图画不全。四、穿透要拉几层问题在于，关系可以无限往外拉。拉三层是一张图，拉五层是一团网，拉到七层，图上什么都有，什么也看不出来。流程上要定一条停止规则。常见的做法是按关系强度分层，股权关系可以拉到三层，交易关系只拉一跳，人员关系两跳以内。超出这个范围的关系，只做记录，不进图。策略上还有一条成本规则。关系越远，解释力越弱，误伤的可能越大。把远关系当成证据用，等于用猜测替代事实。流程上，记录与入图要分开。超出停止范围的关系照样存下来，进一张底表，供以后查证。图只画关键部分，底表留全量。两者混在一起，图就没法读。场景里，跳层关系最容易被漏掉。股权上三层没有直接持股，却通过两个中间主体互相持有，图上看着无关，实际是一体。看穿透后的合并口径，比看直接持股可靠。场景里，停止规则常常被忽略。业务上要一个结论，技术人员就把所有关系都拉出来，图做得很好看，落到具体处理上没人敢用。图的价值不在全，在能指向一处。五、误伤的成本目标上要算一笔账：关系近不等于风险同。同一栋写字楼里的十家企业，共用一家代理记账公司，关系上连得很紧。按关系判断，它们是一个簇。按事实判断，它们只是邻居。流程上，误伤的成本落在具体的人身上。一家正常经营的企业被列入关注名单，要跑几趟说明情况，要提供账目，要等核查。这类成本不进报表，却真实存在。流程上，关系图要能比较。今天一张图，三个月后再画一张，把两张叠起来看哪些线是新增的。新增的部分，往往就是最该看的部分。问题还有一种变体，叫自我强化的误伤。系统把一批企业标成异常，人工去核查，核查中发现有往来，又把关联企业标成异常，越标越多。没有一条纠错通道，这个圈会越画越大。目标上要接受，穿透给出的只是线索，不是结论。线索的价值在于把注意力引到某处，结论要靠核查去落实。把线索当结论用，出错时就找不到依据。流程上要留一条纠错通道。被标成异常的企业，如果核查后确认无问题，这个结论要能回写，让它不再出现在同类名单里。通道不通，同一家企业会被反复打扰。策略上，穿透的结果要分等级用。关系近只意味着“值得看一看”，不意味着可以直接处理。看与处理之间，要留一道人工判断。六、收口场景收在一张图前。一张好的关系图，不是线越多越好，是每一条线都能说清来源，每一个圈都能说清理由。流程上，图的呈现有讲究。节点按主体类型分色，连线按关系类型分组，超过三层的部分折叠起来，点开才展开。这些细节不影响判断，却决定人愿不愿意看。任务落到做法上，可以先从股权关系做起，把三层以内的骨架拉出来，再叠加交易关系找异常点。人员关系放在最后，作为解释工具，不作为判断依据。这条路径不惊艳，但能站得住。目标上，穿透的产出要能落到名单上。一张图再好看，最后要变成可执行的清单：先查哪几户，查什么，多久查完。清单出不来，穿透就停在展示层，图挂在墙上，活还是原来那些。问题回到一句话：单户全景解决的是看得全，关系穿透解决的是看得远。两者配合，才谈得上识别。这里还有一个前提要说明，穿透能力依赖前面几章的归并质量。身份没归准，穿透出来的关系就是错的。归一户错一户，图上会多出一条不存在的线。读者可以先做一件事：挑十户本单位最熟悉的企业，手工把它们的股权关系和主要交易对手画出来，看能不能在两小时内画清。画不清的地方，就是关系数据还没归集到位的地方。建议本月内做完这十户的试画，作为穿透功能的需求底稿。第八章算力铺开之后一、排队的真相问题常被说成机器不够快。实际情况多数不是这样。流程上，一次跑批要经过取数、清洗、比对、出结果四段，四段串着走。取数等数据库空闲，清洗等上一步落盘，比对等清洗完，出结果再等一次汇总。每段都不慢，串起来就慢。场景里，一家单位的任务表排得满满当当。白天跑查询，夜里跑批量，两拨任务抢同一批资源。谁先谁后没有规则，靠人打招呼。打招呼的人多了，队列就乱了。流程上，还有一个窗口期的说法。跑批占用的不只是一段时间，是一段不能被打断的窗口。窗口被切碎，任务反复重跑，实际耗时比排队更长。场景里，窗口被切碎的原因常常是临时查询。有人白天想看一眼数，随手提一个全量查询，跑起来占了资源，批量任务只能等。临时查询要有单独通道。目标上要说清楚，排队问题的解法不在换更快的机器，在改任务的组织方式。机器快一倍，串行的结构不变，等待也就少一半，抵不过任务量涨一倍。二、三种铺开方式，账不一样策略上，算力铺开有三种做法，各有各的代价。扩容最直接，加机器、加内存、加存储。它的好处是马上见效，坏处是成本线性增长，任务量再涨一倍，还得再加。并行化改的是结构，把一个大任务拆成许多小任务同时跑。它的好处是同样的机器能跑更多活，坏处是拆分有前提，任务之间不能相互依赖。有依赖的任务强行拆开，结果会算错。分层计算改的是频率，把不同时效要求的任务分到不同通道。它的好处是资源按用途分配，坏处是要先把用途梳理清楚。流程上，并行有一个前提常被忽略，任务之间不能相互依赖。同一个名单，先是全量比对，再按比对结果筛，后一步依赖前一步，强行拆开，筛出来的会是半成品。问题在于三种做法常被混着用。加了机器，没改结构，一年后又堵。改了结构，没分层，实时任务还是被批量任务拖住。三、冷热分层流程上，分层的第一步是把任务按用途分类。需要秒级回应的，是查询和验证，比如窗口办理时的一次核验。这类任务量不大，但对延迟敏感，要单独留资源。需要分钟级的，是批量的比对和预警，比如一天内多次刷新的名单。这类任务可以排队，但要保证在约定时间内跑完。可以过夜的，是统计和报表，比如月度汇总、年度分析。这类任务量大，放在夜里跑，白天不占资源。场景里，分层的效果很直观。过去三类任务挤在一条通道上，实时查询被批量任务拖慢，窗口人员抱怨系统卡。分开之后，实时通道只跑小任务，响应稳定，批量任务在夜里慢慢跑，谁也不影响谁。流程上，批量任务要有重试规则。失败一次就整个重来，代价太大。可行的做法是断点续跑，跑到哪记到哪，第二天从断的地方接着跑。流程上，通道之间要留隔离。实时通道不能被批量任务占满，批量任务也不能因为实时任务空闲就挤进去。隔离靠资源配额，不靠人喊。目标上，分层要写进制度。哪类任务走哪条通道，由谁审批，超出约定怎么处理，写成规则，不靠临时协调。四、算力不是免费的问题还有一笔钱要算。算力铺开之后，成本会从一次性投入变成持续支出。机器要电，机房要散热，存储要扩容，备份要另买一份。这些钱按年付，不进项目预算，常被漏算。流程上，成本要摊到任务上。哪类任务占了多少资源，哪个部门用了多少，要能算出来。算不出来，就没人节制，资源会被低价值的任务吃掉。目标上，分摊不必精确到每一分钱。按部门、按任务类型分个大账就够用，目的是让人知道资源有限，不是考核谁用得多。流程上，资源要有计量单位。按核时、按存储容量、按任务次数，选一种能比的单位，各处都按它记账。单位不统一，分摊就变成估算，估算的数字没人服。场景里，业务有峰值。申报期、汇算期，查询量会翻几倍。平时够用的资源，峰值那天就卡。峰值要单独估，按峰值配，平时再降下来。策略上，有个简单可行的办法，给任务定优先级和配额。核心业务的任务不限，分析类的任务给配额，超了排队。配额不是限制，是让人知道资源有限。场景里，配额制推行时常遇到阻力。业务部门认为自己提的需求都重要。这时候比的不是理由，是数据：这个任务上一次跑是什么时候，谁看了结果，看了之后做了什么。答不上来的任务，优先级就该往后排。五、新的瓶颈目标上要承认，算力铺开之后，瓶颈会转移。第一处转移在数据质量。机器跑得快了，脏数据带来的错误也出得快。过去一个月跑一次，错了有一个月时间发现。现在一周跑三次，错三次。第二处转移在任务治理。任务多了，谁负责哪个任务，失败了谁去修，结果给谁看，这些事没人管，跑得再快也没意义。第三处转移在人。机器把重复劳动接过去，人要做的是判断和解释。这部分能力不会随算力增长自动出现，得靠培训和岗位设计。流程上，成本分摊还有一个用处，帮人做取舍。两个任务占的资源差不多，一个的结果有人在用，一个的结果没人看，取舍就有了依据。这个依据过去靠印象，现在靠记录。问题还有一种表现，叫“假繁荣”。任务数量涨了，报表多了，看的人没多。资源投进去了，决策没变。这时候该停下来问一句，这些结果到底改变了什么。六、收口目标上要接受一件事，瓶颈转移是正常的。解决一个问题，下一个问题才浮出来。管理者要做的不是消灭瓶颈，是知道下一个瓶颈在哪。流程上，任务要有人管。谁提的，跑多久，失败了几次，结果给谁，写在一张任务卡上。任务卡不填，跑批就成了黑箱，出了问题只能重启，重启几次，业务就不敢依赖。流程收在一张任务清单上。每个任务写清用途、时效、责任人、结果去哪。清单不长，二十条以内，能覆盖主要的活。任务落到排期上，建议先做分层，再做并行，最后才谈扩容。分层几乎不花钱，收益马上能看见。并行要动结构，得有人牵头。扩容花钱，放在最后，是因为前两步做完，需要的机器可能比原计划少很多。问题回到那句话：算力释放是链条的第二环，它释放的不是机器，是等待的时间。时间省下来，想法才敢多试，模型才可能变好。读者可以先做一件事：把本单位现在跑的任务列出来，按秒级、分钟级、过夜三类分一遍。分完之后，多半会发现有一批任务根本不需要那么快。建议本月内完成这份分类表，先做前二十个任务，作为分层改造的依据。第九章识别效率怎么量一、效率不是跑得快问题从一个误会开始。很多单位把识别效率理解成系统跑得快，跑批时间从八小时压到两小时，就认为效率提高了。流程上，跑得快只是必要条件。跑得快而结论不准，等于更快地给出错误答案。跑得快而没人看，等于白跑。场景里，一个平台上线三个月，跑批时间缩短了大半，报表生成速度提高了几倍，业务部门却还在用原来的办法干活。这时候的效率提高停留在机器里，没落到人身上。目标上，识别效率要落到三个问题上，业内常说的“三问”就是这个意思：该发现的问题发现了多少，不该打扰的对象少打扰了多少，从数据变到结论用了多久。三件事合起来，才叫效率。二、四把尺子任务落到度量上，可以用四把尺子。覆盖率回答第一个问题。一批应该被发现的对象里，系统报出来多少。这个数不好算，因为分母要靠事后核查才能确定。可行的做法是先在一个小范围里把分母做实，再把结论推到大范围。准确率回答第二个问题。系统报出来的对象里，核查后确认为真问题的比例。这个数相对好算，把报出来的逐条核查一遍就有。时效回答第三个问题。从数据发生到结论可用，间隔多久。这个数可以测，把每个环节的耗时记下来，加起来就是答案。可解释性回答第四个问题，虽然它不算效率，却决定效率能不能被用。一条结论能不能说清依据，能不能被复核，能不能在争议时站住。流程上，每个数都要有采集方式。覆盖率靠事后核查，准确率靠逐条复核，时效靠埋点记录，可解释性靠抽查。四种方式各有人负责，数才做得实。场景里，四个数常有一个被忽略，就是可解释性。它不进考核，却决定结论能不能被用。一条说不清依据的结论，业务部门顶多当参考。策略上，四把尺子要一起看。只看覆盖率，系统会把所有人都报出来，覆盖满了，没人受得了。只看准确率，系统会只报最有把握的几条，准确了，问题漏了。三、召回提高，打扰也跟着涨问题在于，覆盖和打扰是一对矛盾。举一个假设的场景。系统把一个判断的门槛调低，原来不报的边缘案例现在报了。覆盖率上去了一截，报出来的总量涨了几倍。核查的人力没涨，积压就出现了。流程上，这个矛盾要靠分级来化解。报出来的对象分三档：高置信的直接进流程，中置信的进复核队列，低置信的只做记录不打扰。三档的比例按人力定，不按愿望定。流程上，人力要提前算。一个复核人员一天看多少条，中置信的量有多大，两边一除，就知道该把门槛放在哪里。这个算法比拍脑袋靠谱。场景里，分级常被做成两档，报或不报。两档的选择很硬，要么漏，要么扰。多一档中间状态，系统才有余地。目标上，抽查要独立。自己报的数自己抽查，抽出来的结论难保客观。让不参与日常运转的人来抽，哪怕一年只抽两次，也比自证强。目标上，要接受一个事实：识别效率有一个上限，上限由核查能力决定。报出来的超过能核查的量，多出来的部分不产生价值，只产生积压。四、基线怎么定任务落到验收上，要有一个基线。基线最靠谱的来源是历史人工结果。过去一年，人工核查了多少户，查出多少问题，误判了多少，这些数都在档案里。把系统的结果和这批历史结果对照，能看出系统是补上了人工的漏，还是重复了人工的活。问题在于，历史人工结果本身也不干净。同一个判断，不同人做的结论可能不同，档案里记的往往只是结果，没记依据。用它当基线，要先承认它有误差。流程上，基线还要分段看。大企业和小企业的判断难度不同，混在一起算平均，会掩盖某一类对象上的短板。分段之后，问题才落得到具体场景。流程上，对照要做两次。一次是回溯，用历史时点的数据跑一遍，看系统当时会怎么判。一次是并行，上线初期让系统和人工同时跑，逐条比对。场景里，回溯最容易被跳过，理由是历史数据不全。数据不全确实存在，但不能因此不做。能回溯一部分，就先把这一部分做出来，剩下的标明范围，别假装全量。策略上，基线要写进验收文件。提高了多少覆盖，降低了多少打扰，缩短了多少时间，三个数都要有，缺一个都不算验收完成。五、别用单点指标汇报问题还有一种表现，汇报时只挑好看的那个数。只报覆盖率，看起来成绩很好。只报准确率，看起来也很体面。两个数单看都行，放在一起可能是矛盾的：覆盖涨了，准确掉了，总体效果未必变好。流程上，汇报的周期要和业务的节奏对上。月度看趋势，季度看结构，年度看投入产出。三个周期各有各的问题，混在一起说，谁也记不住。流程上，汇报要固定成一张表。四把尺子各一行，本期、上期、目标三列。表不长，一目了然。数字不好看也照实写，写出来才能改。场景里，这张表还有一个用处，帮人发现异常。某个季度覆盖率突然跳高，准确率没动，多半是门槛被调松了，或者数据源多接了一路。异常要在表上看得见。场景里，度量结果要有人解读。数字本身不会说话，涨了是门槛松了还是接了一路新数据，得有人看结构。没人解读，这张表就变成一份没人看的月报，填的人也只是填。目标上，要把这张表变成常规动作。月度一张，季度一张，不进抽屉，发到相关人手上。看不见的数，不会被管。六、收口目标上，还要回答一个更难的问题：这些数改变了哪些决定。数好看不等于有用，有用的标志是某次判断因为它改了方向。场景收在一个问题上：这套系统到底帮上了什么忙。回答这个问题，不能靠感觉。要靠四把尺子的数，靠和基线的对照，靠核查人员的实际反馈。三者一致，才说明效率真的提高了。任务落到下一步，建议先选一个业务场景做完整度量。一个场景，一条链路，四把尺子都量一遍，量完再谈推广。一个场景量不清，推广到十个场景只会更糊。问题回到那句话：识别效率是链条末端的产出，量它的时候，量的其实是前面几环做得好不好。数据归集不全，覆盖率上不去。口径没统一，准确率上不去。算力不够，时效上不去。三个数一起低，别在末端找原因，回头查链条。读者可以先做一件事：把本单位过去一年人工核查的结果整理成一张底表，写清核查了多少、查出多少、误判多少。这张表是后面所有度量的起点，没有它，效率永远说不清。建议一个月内把这张底表建起来，先做最近一个季度的数据。第十章建设中最容易踩的坑一、把一体化做成界面一体化问题在验收时最容易暴露，叫“界面一体化”。系统上线，登录一个门户，几个模块并排放在首页，点进去还是各干各的。验收报告写着一体化完成，用户用起来还是原来那套。流程上，界面一体化只改了入口，没改数据。同一个客户在三个模块里还是三个号，同一个数在三张表里还是三个值。入口合了，底下的分裂照旧。场景里，这类项目通常有一个共同特征：投入集中在门户和权限，数据治理的预算很少。门户做得好看，底座是空的。场景里，还有一个坑来自供应商。一家厂商既做平台又做数据治理，交付时把标准表设成私有格式，换厂商就要重来。技术可以外包，标准要留在自己手里，交付时写进合同。目前，把一体化理解成门户整合的单位仍然不少，原因不难理解，门户最容易被看见。真正的整合藏在数据里，看不见，也就容易被跳过。目标上要区分清楚，一体化是数据与流程的整合，不是界面的整合。判断办法很土：随便抽一个业务动作，看它在几个系统里发生。多于一个，就没整合。二、标准表建完就没人管问题出在交付方式。标准化常被当成一次性任务，做完清洗，出一份标准表，项目验收，团队解散。流程上，标准表有生命周期。新企业每天在成立，旧企业在改名，商品在换包装，账户在销户。表不更新，三个月后就开始失真，一年后基本不可用。流程上，维护还要有明确的触发条件。企业改名、注销、分立，这几类事件要能自动报到标准表维护人手上。靠人工发现，永远慢一步。场景里，标准表还会被绕过。业务急的时候，直接按名字手工查，不查标准表。绕一次没人管，绕十次就成了默认做法。调用率要盯着，低了就查原因。场景里，失真的表现很隐蔽。查询还能跑，结果看着正常，实际归并率在悄悄下降。等到业务部门发现同一家企业又出现两个号，往往已经过了很久。目标上，维护要写进常态预算。几个人，一年多少钱，接变更申请，定期抽查，发布新版本。这笔钱占整个项目投入的比例不高，缺了它，前面的投入会白费。三、模型先上，数据后补问题常出现在赶节点的时候。上级要看效果，先上一个模型演示，数据的事以后再说。流程上，模型的效果取决于输入。输入是一堆没归并、没清洗的数据，模型再先进也只能在噪音里找规律。演示时挑几个好例子，真跑起来全是误报。流程上，数据欠账会以复利的方式滚。今天少归并一千户，下个月这千户的票流、流水、关系全都带错，越往后补代价越高。场景里，这类项目的转折点通常在第三个月。演示热度过了，业务部门开始真用，误报一多，信任就没了。信任没了，再好的模型也推不动。目标上，顺序要守住。数据归集和标准化没到位，模型只能做小范围试点，不能对外承诺效果。承诺了做不到，后面每一步都要解释。四、只算技术账，不算人的账问题在于，预算表里通常只有软硬件和人天，没有使用者的时间。流程上，一个新系统上线，业务人员要学新界面，要改老习惯，要多填几个字段。这些时间不进项目预算，却真实发生。多填一个字段，一天两百笔，就是几百次额外操作。流程上，双轨期最费的其实不是钱，是人的注意力。两套流程并行，每笔业务要判一次该用哪套，判多了就烦，烦了就退回老路。场景里，人的账算不清，系统就推不动。上线三个月，使用率不到三成，剩下的人在私下用老办法。老办法没被停掉，新系统就成了多头之一。目标上，人的账要提前算。要改多少人的习惯，要培多少场，要留多久的双轨期，双轨期谁盯着。这些写进方案，比写技术架构更管用。五、一次上线就想全覆盖问题出在野心。方案一做就是全业务、全数据、全区域，时间表排得很紧，第一年就要见效。流程上，全覆盖意味着所有系统齐步改，所有口径一起定，所有人一起学。任何一处卡住，整体就延后。延后几次，项目就失去信任。问题在于，一次铺满还会让责任变模糊。十几条线同时开工，出了问题说不清是谁拖的，最后只能用一句整体延期带过。场景里，分步走的项目反而走得快。先选一条链，接通，跑顺，再扩第二条。第一条链跑顺花了半年，第二条只用三个月，因为规则、工具、经验都有了。目标上，要接受不完美。第一条链只覆盖七成场景，剩下三成先手工补，等第二条链接通再收。追求一次做全，常常一次都做不成。六、不留证据链问题在争议时暴露。系统给了一个结论，业务部门问依据是什么，答不上来。流程上，一条结论要能追到三样东西：用了哪些数据，按什么规则算的，谁在什么时候确认的。三样都在，结论才站得住。缺一样，结论就只能当参考。目前，多数单位对留痕的要求停在日志层面，日志记了系统动作，没记判断依据，出事时还是说不清。流程上，留痕还要能对外说。核查时有外部问起，能不能拿出一份说明，写清用了什么数据、按什么规则、谁批的。这份说明平时不写，事到临头写不出来。场景里，证据链缺失的项目，通常在建的时候没想这件事。数据进来就加工，加工完就出结果，中间没留版本，没留日志。目标上，留痕要作为硬要求写进设计。每一条结论带一个可追的编号，点开能看到输入、规则、时间、责任人。这套东西平时不显眼，出事时是唯一能说清的东西。问题还有一种变体，叫事后补痕。出了争议再回头找依据，往往找不到，只能重新跑一遍，跑出来的结果和当初不一样，越解释越乱。七、收口场景收在这六个坑上。它们不是技术难题，多数是顺序问题和责任问题。技术难题可以攻关，顺序错了要重来。流程上，坑要在立项时对一遍。六个问题写进立项文件的检查表，逐条打勾，打不了勾的写明理由。评审时看这张表，比听汇报可靠，也省得事后追责时各说各的。任务落到检查清单上，项目立项时逐条对照：一体化是不是只做了门户，标准表有没有维护人，模型上线前数据够不够，人的时间算没算，范围是不是一次铺满，结论能不能追到依据。六条都过，项目才有基础。问题回到一句话：这些坑反复出现，是因为它们都能在短期内让报告好看。报告好看，问题被推到后面，后面再花几倍代价补。读者可以在下一次评审会上把这张清单拿出来，逐条问一遍。建议把六条写进立项文件的检查项，从下一个项目开始执行。第十一章谁为口径负责一、口径冲突是权责问题问题每次开会都会出现，讨论的主题是某个数到底该怎么算，讨论的结果通常是“下次再议”。流程上，这类争论之所以议而不决，是因为它被当成技术问题处理。技术问题有对错，口径问题没有唯一答案，只有谁说了算。没有裁决人，讨论就会一直转圈。场景里，两个部门各拿一个数来对，差的不是算法，是定义。一个把作废票算进去，一个不算。一个按开票日期，一个按认证日期。两种都不算错，只是用途不同。流程上还有一层原因不容易说出口：口径背后连着评价。一个数怎么算，往往决定哪个部门的成绩好看，争论到这一层，技术理由都成了掩护。场景里，争议常卡在一个细节上：同一批数据，两个部门各取一段，取的范围不同。范围一不同，后面的讨论就没法进行。争议要先对齐范围，再谈算法。目标上，口径还要能对外解释。同一个指标报给上级、报给合作方，说法要一致。对外一套、对内一套，时间长了没人说得清哪个是真的。流程上，口径要培训。新口径发了，用的人不知道，照样按老办法算。培训不必长，半小时讲清改了什么、影响哪些数、什么时候生效。目标上要先承认，口径必须唯一。同一个名字的指标，在一个单位里只能有一个算法。多种算法并存，等于没有算法。二、三种治理安排策略上，常见的治理安排有三种，各有适用条件。第一种是设数据主人。每一类数据指定一个归属部门，这个部门对该类数据的口径负责，别人要用，按它的口径来。这种安排简单，前提是归属清楚。第二种是设口径委员会。跨部门的口径争议由委员会裁决，裁决结果作为正式口径发布。这种安排适合争议多的单位，前提是委员会真的有裁决权，不只是协调。第三种是设专职的数据管理岗。人不多，一两个人，负责登记口径、收集争议、组织评审、发布版本。这种安排成本低，适合起步阶段。场景里，三种安排怎么选，要看单位规模和争议密度。部门少、业务单一，数据主人就够用。部门多、历史欠账多，得有委员会。起步阶段人手紧，先设一两个人做登记，也能顶一阵。问题在于三种安排常被混着用，结果谁都能说话，谁都不负责。选一种为主，其他作为补充，责任才落得下去。三、一线人员的位置流程上，一线人员是口径的第一现场。他们每天面对具体的材料，知道哪些写法常见，哪些情形容易出错。问题在于，一线参与容易走成两个极端。一个极端是让他们照办，意见没人听，最后靠绕路解决。另一个极端是把定口径的活全交给一线，各窗口各行其是，口径又散了。场景里，一条口径定得不合实际，一线最先受影响。比如要求把所有简称都补成全称，一线一天办几十笔，每笔都要去查，查不到就卡住。卡住几次，他们就开始自己想办法绕过。流程上，争议要有记录。每次争议写清争点、各方理由、最后怎么定。记录攒下来，是一份很好的培训材料，新人看一遍就知道哪些坑不用再踩。目标上，口径的制定要让一线参与。不是让他们投票，是让他们提供情形。哪些写法常见，哪些歧义最多，哪些情形需要人工判断，这些信息只有一线有。策略上，可以用一个简单的机制：每季度收集一次一线的疑难案例，挑出高频的二十条，逐条定口径，定完发回一线。这个循环跑两年，口径会变得很实用。四、考核怎么设问题还有一个更隐蔽的来源，考核。流程上，一个指标一旦进了考核，它就会被优化，包括以不健康的方式优化。要求覆盖率，就把门槛调松。要求准确率，就只报最有把握的。要求及时率，就提前把任务标成完成。流程上，考核还要留时间差。口径刚改的头一个季度，数据会跳一下，这时候不能拿新数去比旧数，否则谁都不敢改口径。目标上，考核指标不宜超过五个。超过五个，人就开始挑容易的做，难的放着。少而稳的一组数，比一长串指标更能反映真实水平。场景里，这种优化不需要谁下指令，压力会自己传导。经办人为了完成指标，会找最省力的路径。目标上，考核要设成一组，不设成单个。覆盖、准确、时效三个数一起看，单点突破就会被发现。再加一条，看结论被采纳的比例，防止为了报而报。策略上，还要留一条反向指标。核查后被推翻的比例，或者被反复打扰的企业数量。这类数不好看，但它能压住前面的漂亮数字。五、口径变更的流程流程上，口径不是定完就不动。业务在变，口径要跟着变，但变更要有规矩。变更的第一步是申请，写清为什么要改，改了影响哪些指标，影响多大范围。第二步是评估，由数据管理岗测算影响面，通知到所有使用方。第三步是发布，选一个统一的时间点生效，历史数据是否重算要一并说明。问题在于，流程一严，人就绕开。变更申请要评估、要审批、要等窗口，急着用的人就自己先算一版，事后也不报。绕开的口径不在登记册上，比不改更难管。场景里，最容易被忽略的是历史数据。口径一改，去年的数和今年的数就不可比。要么按新口径重算历史，要么在报表上标明断层。两样都不做，趋势线就会骗人。目标上，变更要留档。每一次变更记下时间、原因、批准人、影响范围。三年后回头看，这份档案能解释很多当时看