惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
A
About on SuperTechFans
IT之家
IT之家
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Blog — PlanetScale
Blog — PlanetScale
aimingoo的专栏
aimingoo的专栏
云风的 BLOG
云风的 BLOG
The GitHub Blog
The GitHub Blog
Vercel News
Vercel News
G
Google Developers Blog
J
Java Code Geeks
宝玉的分享
宝玉的分享
T
Tailwind CSS Blog
Cloudbric
Cloudbric
L
LINUX DO - 最新话题
MyScale Blog
MyScale Blog
H
Heimdal Security Blog
PCI Perspectives
PCI Perspectives
Attack and Defense Labs
Attack and Defense Labs
S
Security @ Cisco Blogs
Latest news
Latest news
I
Intezer
L
Lohrmann on Cybersecurity
C
CXSECURITY Database RSS Feed - CXSecurity.com
月光博客
月光博客
T
Threatpost
博客园 - 【当耐特】
S
Schneier on Security
P
Privacy International News Feed
G
GRAHAM CLULEY
T
Tenable Blog
AWS News Blog
AWS News Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
雷峰网
雷峰网
博客园 - Franky
Engineering at Meta
Engineering at Meta
美团技术团队
S
Secure Thoughts
T
Troy Hunt's Blog
Microsoft Security Blog
Microsoft Security Blog
SecWiki News
SecWiki News
V
Visual Studio Blog
人人都是产品经理
人人都是产品经理
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Cisco Talos Blog
Cisco Talos Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Martin Fowler
Martin Fowler
Webroot Blog
Webroot Blog
Google DeepMind News
Google DeepMind News
H
Hackread – Cybersecurity News, Data Breaches, AI and More

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
「招投标政策解读」系列2:围串标线索挖掘,平台应该怎么建 – 人人都是产品经理,
雪碧要提升算力 · 2026-05-06 · via 人人都是产品经理

招投标市场的公平性正面临AI技术的深度重塑。195号文提出的围串标识别系统通过四维交叉比对技术,从主体关系穿透到报价特征分析,实现从被动举报到主动发现的模式变革。本文将拆解这套系统如何在数据底座、模型引擎等层面突破传统监管瓶颈,重构招投标市场的信任机制。

把 195 号文的 6 大环节、20 个场景全部过了一遍。这20个场景散布在招投标全链条的不同位置,但其中有两个,牵涉到招投标制度的底层价值——公平公正,以及国家公信力。

一个是智能辅助评标。评标是招投标最核心的环节,评标过程能不能做到客观公正,直接影响每场交易的结果质量。

另一个就是围串标识别。围标串标是招投标制度面对的最直接的破坏性行为,它动摇的不是单个项目的公平性,而是整个市场对公开竞争制度的信任。这一篇先从围串标切入。原因有两个:

第一,围串标识别的数据链条最长,跨系统依赖最深——它需要工商、社保、税务、司法、交易平台等多类数据交叉验证,数据基础设施的打通进度直接决定这个场景的实际效果天花板。

第二,195 号文在推进节奏里,把围串标识别和招标文件检测、智能辅助评标并列,作为三个“2026 年底部分省市全覆盖”的重点场景之一。文件没有给所有 20 个场景都标注优先序,只给了这三个。

下面是 195 号文对围串标识别的原文定义:

“综合运用市场主体分析、投标报价偏离度分析、中标概率异常分析、技术方案相似度分析、商务标关键报价特征比对等方法,实现标前、标中、标后围标串标线索的穿透式发现。”

注意文件的用词——”穿透式发现”。不是”分析”,不是”预警”,是”穿透”。

一、传统围串标查处,到底难在哪

先看数据。2025 年全国公共资源交易平台受理的投诉中,涉及围串标的占比不低,但实际查实的比例远低于投诉率。为什么查不出?不是不想查,是手段跟不上。

难在举报驱动模式的天生局限

围串标案件的线索来源,绝大部分来自举报。但”举报驱动”这个模式的结构性缺陷不是几句话能说清楚的。

第一个局限:只有利益受损方才会成为举报人。

投标失败的第二名或第三名,觉得自己”输得不明不白”,才会去翻中标人的投标文件、去查专家打分是否合理、去核对有没有关联关系。这是最常见的举报路径——第二名检举第一名,第三名检举前两名。举报人的动因很明确:输了,但觉得不该输。

第二个局限比第一个更致命:完全围猎的情况下,不会有任何举报。

如果甲乙双方提前串通好、陪标方拿了”出场费”、甚至连评标专家都提前打过招呼了——所有参与者都是既得利益方。谁举报?没有。

我朋友在交易中心做监管,他原话是这么说的:“真正能查出来的围串标,都是围得不彻底的那些。围得铁桶一样的,连举报的人都找不到——因为所有人都在局里。”

完全围猎的情况下,围串标”看起来”是完全合规的:标书文件齐全、开标程序规范、专家打分都正常。但你知道有问题——就是抓不住证据。因为你没有举报的切入点,也没有足够的数据支持你去”主动发现”。

难在人工审查的上限太低了

即便有举报,线索核查也是人工完成的。一个评标报告几百页,人工比对技术方案的相似度、核对报价清单的异常点——经验丰富的审查人员也需要花一两天的时间细看。而且人的注意力有硬上限,连续看几个标之后,漏掉细节是大概率事件。

某省交易中心的朋友跟我说过一句话:“一年几千个项目,能查几个?查不过来。全靠举报。没举报的项目,默认没问题。”

这就是传统模式的天花板。而 195 号文的思路,就是把天花板往上抬——从一个一个查,变成系统化地看。不让任何线索在没有被审查的情况下滑过去。

二、AI 围串标识别的四个数据维度

195 号文给围串标识别画的框架是四维交叉比对:主体关系穿透 × 投标行为分析 × 技术方案语义分析 × 报价特征比对。四个维度不是并列的,它们的成熟度、数据可得性、技术门槛都不一样。下面一个一个拆。

维度一:主体关系穿透——围串标的”骨架”

围串标的本质是什么?是”人的串通”。用 AI 查围串标,第一步是搞清楚:这些投标主体背后,到底是不是同一拨人。主体关系穿透这个维度的核心逻辑只有一个:把所有参与投标的企业放进一个关系网络里,通过公开注册信息建立连接边,看网络结构中有没有异常节点。这个维度又可以拆成两层来看。

第一层:表层关系——公开注册信息层。

股东结构、法人代表、董监高交叉任职、注册地址雷同、联系人手机号相同。这一层的数据来源是企查查、天眼查等第三方企业信息平台。

市面上大部分围串标分析平台,在表层关系这块都不是自建企业信息数据库——因为自建成本太高、更新太慢、合规风险大。平台的通行做法是跟有资质的数据厂商对接接口,实时调取企业关联数据,然后用自己的模型做关系图谱分析。

这一层能查出什么?A 公司的股东也是 B 公司的高管、C 公司和 D 公司的注册地在同一个门牌号、E 公司和 F 公司留了同一个联系人电话。这些关联在纸面上”不违规”,但组合在一起就是围串标的典型前置信号。

表层关系的公开数据中最有穿透力的一个字段要单独说一下:社保缴纳人数。社保是公开注册信息的一部分,不同企业的主体信息中都有缴纳情况。如果两家投标企业的标书中出现了同一人的社保缴纳记录,或者一家企业声称有 50 名技术团队但社保缴纳只有 3 人——属于数据层面的不匹配,直接抛出异常。这部分数据也是通过第三方企业信息平台获取的,不需要额外对接人社系统。

但表层关系的局限性也是众所周知的——真正做围串标的团队,早就把表层关联清理干净了。表层的法人和高管换过一轮、联系方式全换新、注册地分开——表层关系查不出什么了。这时候需要往下一层走。

第二层:深度关系——多层图谱穿透层。

表层关联查不到不等于没有关联。围串标的利益链条往往绕了好几层。

A 公司的法人是甲,甲不是 B 公司的董监高。但甲持有 C 公司股份,C 公司控股 D 公司,D 公司是 B 公司的最终受益人。这条路径在表层关系里不会直接显示为”A 公司与 B 公司关联”,但三层穿透之后,实控关系是清晰的。

这就是平台建设方要自己建模型的地方。数据厂商给你的是”一层关联”——直接持股、直接任职。你要建的关系图谱模型,要做的是”多层穿透”——两层的间接持股、三层的受益链条、实控人亲属代持的网络。

市面上通行的做法是图数据库 + 社区发现算法:把所有参与投标的企业和个人作为节点,用股权、任职、地址、联系方式作为连接边,构建一个投标关系图谱,然后用算法自动识别图谱中的异常社区结构——比如一个实控人通过十家马甲公司参与同一个项目的投标。

这个做法的产出是一张关系网络图,而不是一个简单的黑白名单。图上标注的是”关联强度”,不是”有关系/没关系”的二元判断。围串标的复杂性决定了它是一个”可疑程度”的问题,不是一个”是/否”的问题。

深度关系穿透的数据来源,严格意义上仍然是表层公开注册信息——只不过它是公开信息的延伸挖掘。你不需要额外采购数据,你需要的是更好的分析模型。这也是主体关系穿透维度跟其他三个维度最大的区别:它不依赖行业交易数据,依赖的是信息挖掘的深度。

维度二:投标行为异常分析——”算出来的异常”

这是四个维度里技术门槛相对偏低、落地最快的。

核心逻辑一句话:每个人在历史投标行为中会形成自己的模式——报价区间、中标概率、伴随投标人名单——当某个投标在某个维度上的数据显著偏离自身历史模式时,系统标记为异常。

常见切入点说几个:

中标概率异常。 某投标人历史投标 50 次,中标 1 次,中标率 2%。但某一次突然中标了,而且那一次其他投标人的报价,恰好都”恰到好处”地比他高了一个比例——比如所有陪标方都比他的报价高 3%-5%。单看个体数据没问题,但放在群体数据里看,规律太整齐了,整齐到不像市场行为。

报价规律偏离度。 某投标人在多个项目中,始终比次低价低一个固定比例。一次两次是巧合,项目数量多了,模型应该标记。

“铁三角”伴随关系。 同一个项目中,三份投标文件里有三个人的名字反复出现——这次是 A 公司的项目经理,下次是 B 公司的技术负责人,再下次是 C 公司的现场代表。人相同,公司不同。这是围串标的经典操作手法。195 号文原文描述了这个场景,模型要做的就是”识别一段时期内特定人员在不同投标单位间的交叉任职和伴随投标关系”。

这一维度模型设计的关键点:不做单项目分析,做跨项目的时间序列分析。 单项目看每个报价都合理,跨项目一串起来,规律就浮现了。

维度三:技术方案语义分析——”改写”藏不住的痕迹

投标文件里,技术方案是最长的部分,也是人工审查最耗时的部分。几十上百页,人看不过来——看完了也不一定记得前面写过什么——但 AI 看几秒就够了。语义分析一般做三件事:

一是相似度比对。两份文件看起来排版不同、章节顺序不同、连图表位置都不同。但语义分析能把核心描述抽出来——施工工艺的描述逻辑一样、设备选型的论证路径一样、项目难点分析的文字结构一样——这是 AI 能识别出来的”改写痕迹”。

195 号文里写的是”技术方案相似度分析”。这里要注意:传统的相似度比对是关键词匹配 + 向量余弦,但现在的做法是用大模型的 Embedding 做语义级相似度计算——两段文字用词完全不同但意思一样,一样会被标记为”语义相似”。

二是错别字一致性。两份文件中出现了同样的错别字。比如把”钢筋混凝土”写成”钢筋混凝士”——不是通用错别字,是手误。同一份手误出现在不同公司的标书里,意味着什么?

第三件事更隐蔽,也是 195 号文没有明说、但技术层面可以做的一件事。

三是文档元数据穿透。创建者用户名、最后一次修改人、文档修订记录、打印机名称——这些信息不会出现在标书正文里,也不会被投标人主动关注,但它们天然存在。AI 采集和比对这些元数据,如果发现两份”独立投标”的标书,创建者字段指向同一个用户名或同一台电脑——这个信号的价值不比正文分析低。

维度四:报价特征比对——最有”可量化”优势

报价比对这个维度在技术层面阻力最小——因为数据是结构化的、量化的、没有歧义的。只要是数字,就能比对、就能算偏离度、就能做聚类分析。常见切入点:

分项不平衡。 两份标书总价相差不到 1%,但打开清单一看——A 公司的混凝土价格比市场均价高 20%,B 公司的钢筋价格比市场均价高 15%,两者互补,总价拉平。这种”互相给对方留空间”的报价模式,人眼看不出,但模型一看就知道。

异常一致的报价策略。 多个投标人的分项报价呈规律性变化——A 报低 B 报正常 C 报高——比如 A 在主体结构上低 5%,B 在装修上低 5%,C 在安装上低 5%。互为陪标关系的模式。

报价偏离度。 投标人的报价显著偏离同期同类项目的正常分布区间,但没有合理的价格支撑依据。

报价比对的好处在于:招标文件、投标文件、中标结果都是结构化数据,可以大规模运算。而且历史数据积累越久,”正常区间”的界定越精确——三年数据算出来的偏离度和五年数据算出来的偏离度,置信度不在一个级别上。

三、顶层设计:围串标 AI 平台怎么建、系统怎么搭

前面把四维交叉的数据维度和分析方法说清楚了。这一节换个视角——如果现在让你来建一个围串标 AI 识别平台,你怎么做顶层设计。

这个框架分四层来说,每一层对应一个不可跳过的建设模块。四个模块之间的依赖关系是自上而下的,没有前一层,后一层就没有意义。

第一层:数据底座——决定平台的实际天花板

195 号文说”鼓励依法依规共享”数据。但”鼓励共享”和”数据到位”之间,有很长很长的路要走。一个围串标 AI 平台,数据底座需要覆盖哪些来源,粗略可以列出六类:

第一类——企业信息数据。 从企查查、天眼查等第三方企业信息平台采购接口。这是最低门槛的数据。现在市面上大部分围串标分析平台在这一层都是”采购 + 接口调用”,不自建企业数据库。一是成本问题(自建和持续更新的投入不划算),二是合规问题(企业信息的采集和使用有明确的资质要求)。平台在这一层做的事不是存数据,而是搭模型——把接口传回来的数据处理成关联图谱。

第二类——历史投标数据。 投标人名单、报价、中标结果、技术方案。这部分平台自己有,关键是你保留了多少年。三年的数据和十年的数据,模型精度差别很大。而且这里有个细节:不仅是数据年限的问题,还有数据质量问题。如果历史数据没有按统一标准归集——有的年份字段不全、有的项目没有完整的技术方案附件、某些年份的报价数据与实际金额有出入——那么要在模型层面先做数据清洗和标准化。

第三类——开评标过程数据。 上传 IP 地址、上传时间、评标专家打分记录、评标过程录音录像。这部分不是所有地方都有。有些交易中心连基本的数据采集系统都还没建成,IP 数据不存、操作日志不记录。如果在过程数据这一层就是空白,后面三个维度的分析会缺失最关键的”行为层”数据。

第四类——信用数据。 企业黑名单、行政处罚记录、失信被执行人信息。这部分相对容易接入——因为全国信用信息共享平台已经存在了,有标准化的接口可以对接。不需要自建。

第五类——社保数据。 这是理论穿透力最强的数据——如果投标人的项目经理同时在几个公司的社保名单里,或者某投标公司的技术负责人的社保记录曾经挂靠在另外一家投标公司名下——这是围串标最直接的证据之一。但接入难度最高,需要跟人社系统对接,涉及到跨部委的数据共享。

第六类——司法数据。 涉及围串标的判例、检察院不起诉决定书。这部分的价值在于训练模型——用历史判例中认定的围串标特征,反推模型应该关注哪些数据维度。数据来源是分散的,但可以系统化抓取。

这一层有一个核心判断:数据治理应该在模型选型之前。 先把数据留好、洗好、规整好,再谈模型。否则模型上去了也是空转。

第二层:模型引擎——从规则到机器学习的渐进路径

模型引擎不是上来就上大模型的。一个务实的搭建路径是分三步走:

第一步:规则引擎打底。

硬编码的规则最好做、最快出效果:IP 地址相同直接标记、创建人相同直接预警、报价偏差超过阈值全部输出。这些不用 AI 也能做。但它们是后面所有模型的基础——没有规则引擎输出的结构化数据,机器学习模型没有训练样本。

规则引擎的另一个价值是”兜底”——深度语义模型再先进,也要保留规则引擎的并行运行。因为规则是确定的、可解释的、不会因为模型更新而波动的。

第二步:传统机器学习做异常检测。

用历史数据训练分类模型,识别报价偏离、中标概率异常、伴随关系等。这个阶段可以产出”可疑指数”或”风险等级”。

传统机器学习的好处是可解释性好——每个特征的权重可以透明展示,审查人员能理解模型为什么觉得某个投标”可疑”。这在围串标识别场景里很重要——预警推送出去,审查人员需要知道”为什么”。

第三步:深度语义模型做深层分析。

用大语言模型做技术方案相似度分析、文档元数据穿透。这个阶段是真正的 AI 能力,对算力和数据质量都有要求。

三步走的时间节奏怎么定?规则引擎可以上线就走。传统机器学习需要 6-12 个月的历史数据做训练集。深度语义模型需要标注数据和算力投入,通常是第二阶段到位之后才启动的。

节奏统筹上的建议:不要一开始就追求全 AI 驱动,规则引擎先跑起来,先把数据治理的进度跑通,再上传统机器学习,最后看资源条件决定要不要上深度语义。

第三层:预警处理——”预警不等于认定”

195 号文在围串标识别场景的定义里,有一句很重要的话需要逐字理解:

“模型判断的结果不改变使用主体的法定责任,不替代招标人、评审专家的自主判断。”

翻译一下:AI 可以预警,但预警不等于认定。决定权在人的手上。

所以平台的”预警处置”模块在设计上要清晰划分两个角色:

  1. AI 做初筛和标记。 把四个维度的异常线索汇总,生成项目级预警报告。模型只管”发现异常”,不管”是否违规”。报告要附带:哪些维度触发了、每个维度的数据依据是什么、历史同类项目的对比情况。
  2. 人做研判和确认。 预警报告推送审查人员,由人来做最终判断——是否值得进一步核查、是否需要约谈、是否移交纪检。模型不能取代这个”拍板”的角色。

这里有一个设计层面的关键要求:每一个预警都必须有可解释性。 因为预警会触发后续的人工核查、约谈、甚至移交——如果模型只是输出一个”风险高”的分数,审查人员拿到手里没法用。必须说清楚:为什么给这个投标人标记了高风险——是主体关系触发了?报价异常触发了?还是技术方案相似度触发了?每个维度的置信度是多少?

没有可解释性的预警,就是无法落地的预警。

第四层:持续迭代——模型只会“越跑越好”嘛?

这是全文最值得停下来想的一个观点。很多人有一个默认假设:AI 模型上线之后,只要跑着,就会越来越好。数据越来越多,训练越来越好,结果越来越准。

这个假设不成立。 模型不会天然地越跑越好。模型可能在持续优于上一次的结果,也可能在持续的某个节点上开始退化。而且”退化”这件事,如果监控没跟上,可能很久都不会被发现。更麻烦的是,有些退化是渐进式的——你今天对比昨天看不出区别,但这个月跟上个月比,准确率已经降了一些。

那么,什么情况下模型会越跑越差?

1. 反馈断裂。

围串标识别模型的迭代,依赖于人工确认结果的”反哺”——平台推送了 100 个预警,审查人员确认了其中 40 个是有效预警、60 个是误报。这 60 个误报的真实结果要回馈给模型做训练,用来降低下一轮的误报率。

但如果中间的反馈链路断了——预警推了,但审查人员没有系统化地记录”哪些有效哪些误报”——模型就收不到训练信号。没有新的标注数据,模型就停在原地。

更具体地说,反馈断裂意味着所有的“误报”都没有被转化为训练样本。同样类型的误报会反复触发,预警效果自然在不断变差。

2. 概念漂移(Concept Drift)。

围串标的手段不是静止的。当你用”IP 地址相同”这个规则查了一批项目之后,围串标团队就知道了——他们会换机器、换 IP、用云电脑或者线下交标书。这时候,”IP 地址相同”这个特征的区分度开始下降。

不只是单一特征,整个”围串标行为模式”都在动态演化的。去年管用的模型特征,今年可能已经失效了。因为围串标的对抗方——围串标利益链条上的人——也在学习和适应。

3. 数据质量衰减。

平台刚刚上线时,数据是最新鲜的、字段最完整的。跑了一年两年后,一些接口可能因为合作方调整而降级、某些数据源的更新频率放慢、部分系统改造后数据格式变了——模型在”脏数据”上跑,结果自然会变差。

数据质量衰减的问题是隐性的——数据还在传,但没有字段不完整或者格式变了,模型不知道。直到你发现某个维度的分析结果突然异常了,回头查才发现,是源数据出了问题。

4. 确认偏差(Confirmation Bias)累积。

这是最容易被忽视的一个退化机制。

审查人员拿到模型输出的预警报告之后,如果指标显示模型在过去一段时间的表现结果比较理想,审查人员可能会不自觉地更倾向于”相信模型判断的正确性”——从而在复核时降低警惕。

这种偏差在模型表现良好的初期作用不大,但时间长了,复核流程中”人工复核”的有效性会逐渐下降。而人工复核有效性的下降,意味着反馈到模型训练中的”真实标签”的准确率也在下降——这构成了一个隐蔽的负向循环:模型在错误的反馈信号上迭代,越跑越偏。

怎么应对?三个防御机制是必须的:

一是建立持续标注机制。 无法撤回的预警核查结果是模型迭代的核心训练素材。每个预警推送出去、经人工复核之后,要有系统化的”标注——回传——再训练”闭环。没有这个闭环,模型就是一次性的。

二是定期做模型重训和回测。 用最近时间窗口的数据重新评估模型准确率,发现指标下滑及时排查原因——是概念漂移、数据质量问题还是确认偏差。

三是独立评估团队。 评估模型效果的人和日常使用审核模型预警的人,最好分开。如果同一个人既负责「判断过往预警」又负责「评估过往预警是否准确」,确认偏差几乎无法避免。

一句话总结这一层:模型不是建完就完的东西,是一个需要持续养护的系统。养护跟不上,模型就会往差的那一端滑过去。

四、三个不确定性

前面把四维交叉的数据维度、平台顶层设计框架、模型迭代机制都说清楚了。但有些边界条件不是”想清楚”就能解决的,它们受制于平台建设方不可控的外部因素。值不值得在某种不确定性上投入资源、投入多少,需要平台建设方自己判断。

1. 数据共享的进度。

围串标识别的模型效果,上限取决于数据的覆盖面和打通速度。

交易中心内部的投标数据、企业信息平台的公开数据、信用系统的失信数据——这三类数据确定性高,相对容易获取。但税务数据、银行流水数据、跨区域投标以及评审数据——这些才是真正能”穿透”围串标的数据——也是最不可控的。

这不是技术问题,是跨部门协调的问题。文件写了”鼓励共享”,但”鼓励”两个字的具体落地空间有多大,不同地区的实践经验差异很大。

2. 预警与误报的经济账。

误报率每降低一个点,需要投入多少标注数据量、多少算力、多少人力去调参——这是需要平台建设方算的账。

如果预警推送太多,人工处理不过来,平台就成了负担。如果预警推送太少,漏掉的线索无人追究,平台就失去了建设意义。找到那个”成本可控且业务可接受”的平衡点,是平台上线后首先要解决的问题。

3. 后续处理流程的配套。

195 号文给围串标识别场景的定位是”为有关部门执纪执法提供参考”。但”提供参考”之后的事情——谁来复核、复核流程走多长、复核结果怎么归档——文件没有细说。

如果后续处理流程没有提前设计好,平台产出再多的预警线索,最后也会卡在”推给别人了,但没有然后了”的状态。

写到这,可以做一个简短的收束。围串标识别是 195 号文 20 个场景中,最能体现”大数据 + AI”价值的场景。四个维度——主体关系穿透、投标行为异常分析、技术方案语义分析、报价特征比对——覆盖了从”人”到”行为”到”文本”到”数据”的全链条。

但从文件到落地,中间的障碍也很清楚:数据共享进度、模型迭代的养护成本、预警后续处理流程的配套——这些都不是一纸文件能解决的。

不过有一件事是确定的:围串标的线索挖掘,正在从“举报驱动”走向“数据驱动”。 这个转变不是 AI 行业推动的,是招投标行业自身发展的需求推动的。

AI 只是工具。真正要建的,是一个数据能流动、模型能学习、预警能落地的系统。

以上场景内容均来自《关于加快招标投标领域人工智能推广应用的实施意见》(发改法规〔2026〕195号),原文和解读请以官方文件为准。

本文由 @雪碧要提升算力 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Pexels,基于CC0协议