一台M3笔记本，8GB内存，22分钟扫完8份政府招标文件，51条资格条款全部提取，模型调用成本0美元。这不是云端跑出来的成绩，是全程在本机完成的。
做这件事的是Tender Radar，一个面向小型承包商的本地化政府招标雷达。它要回答的问题很具体：哪些公告值得看、公司到底符不符合资格、合规材料怎么凑齐而不漏掉任何一条。
漏一份证书，标书就会在技术审查环节被直接判废，前期投入的准备成本全部归零。不少中小微承包商为此按标付佣金给代理，或者干脆错过本来能赢的项目。
三个问题，一台机器
Tender Radar的处理链条可以拆成几层：
- 从每份公告中抽取资格条款，覆盖营业额、投标保证金、业绩经验、执照与认证
- 把每条条款与公司自有文件比对，包括历史标书、完工证书、执照与ISO扫描件、审计财报，每一条结论背后都附原文引用
- 用直白语言标出风险条款，比如保证金占到标的值9%、截止日期只剩三天、工程量是公司做过的十倍
- 基于历史投标记录，用TabPFN估算中标概率
- 起草封面信、合规声明与能力摘要，并加一道引用守卫，删掉自有文件支撑不了的句子
所有环节都在持有敏感文件的那台机器上计算。从克隆仓库到打开看板只需五条命令：安装、生成演示语料、载入、扫描8份标书、启动面板。演示语料是一个合成但贴近真实的电气类中小微企业，位于斋浦尔，持A级执照，平均营业额约3.7 crore卢比，语料有明确标注；真实门户的数据接入则留了带密钥的脚手架。
4B模型逼出来的引用守卫
抽取、判定和起草全部跑在Gemma 4上（gemma4:latest，4.6B Q4），通过Ollama本地运行。金额解析走确定性代码，理由很直接：钱不能取决于模型的情绪。
匹配采用混合检索，内置TF-IDF嵌入器加BM25，之后每份标书跑一次Gemma判定。中标概率用TabPFN v3.5的thinking模式。
引用守卫是这套系统里最值得说的一环，它的存在恰恰因为4B模型不是前沿模型。作者抓到过一次模型把某条款标为"满足"，而它自己给出的理由却在论证公司不达标。于是每一条"满足"都必须携带引用，并在展示前验证：精确匹配，或数字按数值比较的模糊匹配——"INR 84.5 lakh"能通过"INR 84.50 lakh"的比对，"two crore"对"2 crore"则直接失败。另有一道确定性金额交叉校验独立于模型运行。
实测数据如下：8份标书共抽取51条条款，每条都解析出金额；判定结果为24条满足、5条部分满足、19条缺失、3条未知；引用守卫驳回了3条模型引用并降级记录原因，交叉校验抓到4处数字冲突；起草环节在16个章节中删除了8句无支撑内容；共21次模型调用，约83k token，花费0美元；8份标书耗时22分钟。
中标概率模型的同切分对比
在按时间排序的同一数据切分上（147份已提交标书），sklearn基线的AUC为0.731、Brier为0.260；TabPFN v3.5加thinking模式为AUC 0.752、Brier 0.209。一个"该不该投"的数字，成败全在校准。
为什么坚持本地？理由有三条。其一，数据本身具备商业敏感性——审计财报、历史标书和报价是这家公司最敏感的文件，所有读写文档的步骤都由本地开源权重模型完成，系统里唯一的网络调用是TabPFN中标模型，且只发送特征（标的额、距离、竞争对手数量），从不发送文档。其二，零边际成本会改变行为：代理按标收费，SaaS按席位收费，本地推理让多扫一份公告变成免费动作，公司于是每份都查，而不是只查付得起的那几份。其三，小数据问题需要小数据模型加兜底：中标概率建立在约220份历史投标上，TabPFN正是为这种量级设计，而封闭AutoML往往要求上千行数据；整条流水线还能平滑降级到sklearn，没有任何强制外部依赖。
作者也承认代价：按单份标书算，4B本地模型比前沿API更慢，文笔也更粗。守卫让这件事变得安全，隐私与成本属性让这件事值得。用封闭API搭起来会更容易，但根本没法交付给这类客户。
项目在Hacktoberfest第二周的挑战窗口内一天建成，代码在github.com/praneshnikhar/tender-radar，scripts/eval_summary.py可复现上述每一个数字。公司的数据不出笔记本，账单也不会来。
热门跟贴