投标Agent训练集构建：从数据工程到SFT与DPO协同设计 1. 这不是“造数据”是给投标 Agent 立规矩为什么必须从零手搓训练集“投标 Agent”这个词一出来很多人第一反应是——这不就是个自动填表、跑流程的脚本吗点几下鼠标调几个 API再套个 RAG 框架不就完事了我去年也这么想。直到我们团队把一个标书生成模块交给大模型微调后上线试运行结果在某次市政类项目投标中Agent 把“工程量清单单价分析表”的填报逻辑和“技术标施工组织设计”的章节结构混在一起硬生生把一份 87 页的技术方案塞进了商务标报价表的 Excel 单元格里还自信满满地加了句“已按招标文件第3.2.1条完成格式校验”。客户没投诉但采购部同事默默把我们的系统从“推荐工具”列表里划掉了。这件事让我彻底明白投标场景不是通用问答而是高度结构化、强约束、高容错成本的领域任务。它对 Agent 的要求远不止“能说人话”或“会调工具”——它要能精准识别招标文件里的隐性规则比如“不得出现公司名称”实际指代“不得出现母公司全称及任何曾用名”要能在 37 个不同格式的 Excel 表格模板间做字段级映射还要在“技术标响应条款”和“商务标偏离表”之间建立语义一致性校验。这些能力靠通用大模型的指令微调SFT根本压不住靠现成的开源 Agent 数据集翻遍 HuggingFace 和 GitHub连“投标”这个词都极少出现在训练集描述里——更别说“工程量清单”“资格审查条件”“联合体协议签署页盖章位置”这种颗粒度。所以“从零造出 Agent 训练集”这个动作本质不是在堆数据而是在为投标 Agent 建立一套可验证、可追溯、可迭代的领域认知契约。它要回答三个核心问题第一Agent 必须掌握哪些最小知识单元比如“投标保证金退还条件”包含“中标通知书发出时间”“合同签订时间”“无违约情形”三个子条件第二Agent 在执行链路中必须守住哪些不可逾越的边界比如“不得修改招标文件原文中的数值型条款”第三Agent 的输出必须通过哪些形式化校验比如“所有引用的法规条文必须带年份和发布机关缩写”。这三件事决定了后续 SFT 和 DPO 阶段的优化方向是否有效也决定了上线后是“省心助手”还是“定时雷区”。关键词里反复出现的Agent、数据工程、训练集、SFT、DPO在这里不是并列关系而是因果链条数据工程的质量直接决定 SFT 能否教会 Agent “做什么”更决定 DPO 能否教会它 “怎么做才对”。我见过太多团队把 90% 时间花在模型选型和超参调优上却用三天时间从招标网站爬下 200 份 PDFOCR 后扔进清洗脚本再随机切分就当训练集——结果模型在测试集上准确率 82%上线后第一周就因“将‘暂估价’误判为‘暂列金额’导致报价汇总错误”被叫停。这不是模型的问题是数据契约从根上就松动了。所以这篇复盘我们不谈 LLM 架构不聊 RLHF 算法就死磕一件事如何用工程化思维把“投标”这个模糊的业务概念翻译成机器可学习、可验证、可落地的数据实体。接下来四篇这是最硬的一块骨头。2. 投标领域的“数据宪法”定义训练集的五层结构与不可妥协的约束很多团队一上来就想“怎么标注”结果标到第三天发现标注员对“实质性响应条款”的理解和法务总监的定义差了两个部门。这说明在动手造数据前必须先立下投标领域的“数据宪法”——一套所有人都必须遵守的、覆盖数据全生命周期的结构化约束。我们最终确定的训练集框架不是简单的“输入-输出”对而是由五个严格嵌套的层次构成每一层都对应一个不可妥协的业务规则2.1 第一层招标文件原子单元Document Atom这是整个数据集的基石。我们拒绝直接用整份 PDF 或 Word 文件作为输入而是强制拆解为最小语义单元。具体规则如下文本类单元必须以“条款编号标题正文”为完整单元。例如“2.3.1 投标有效期自投标截止之日起 90 日历天。”不能拆成“2.3.1 投标有效期”和“自投标截止之日起 90 日历天”因为后者缺失上下文会导致模型无法关联“90 日历天”与“有效期”这一法律概念。表格类单元必须保留原始行列结构并标注表头语义。例如工程量清单表需明确标注“序号”“项目编码”“项目名称”“计量单位”“工程量”“综合单价”等字段的业务含义而非仅用“列A”“列B”表示。附件类单元如“技术规格书”“图纸目录”必须与主招标文件建立双向引用关系并标注其约束效力等级如“图纸目录为强制响应项技术规格书为参考性响应项”。提示我们开发了一个轻量级预处理工具tender-splitter它能自动识别 PDF 中的标题层级、表格边框和附件标记将一份 120 页的招标文件拆解为平均 472 个原子单元。关键不是数量而是每个单元都附带一个 JSON 元数据包含source_page、clause_type如“资格条件”“报价要求”“技术标准”、binding_level强制/建议/参考三个必填字段。没有元数据的单元直接进入“待复核队列”不参与训练。2.2 第二层任务指令模板Instruction Template投标任务不是开放问答而是有固定模式的指令驱动。我们归纳出 7 类高频指令模板每类模板都定义了严格的输入输出契约条款解析类输入为原子单元文本输出必须是结构化 JSON包含key_terms提取的关键术语、obligation_party义务方如“投标人”“招标人”、deadline如有时间要求、penalty如有违约后果四个字段。例如输入“投标人须在收到中标通知书后 5 个工作日内签订合同”输出中obligation_party必须是“投标人”deadline必须是“5 个工作日”penalty字段若原文未提则为空字符串严禁填“无”或“不适用”。格式转换类输入为 Excel 表格截图或 CSV 内容输出必须是目标格式的纯文本描述且必须包含字段映射依据。例如将“供应商信息表”转为“投标函附件一”输出中必须注明“‘企业名称’字段映射自原表 A2 单元格依据招标文件第 4.1.2 条”。一致性校验类输入为两份文档片段如技术标中的“工期承诺”与商务标中的“合同工期”输出必须是布尔值 校验依据。例如“true | 依据招标文件第 5.2.3 条两处工期均为 180 日历天”。注意所有模板的输出格式都经过法务和招标代理双重审核。我们曾为“偏差说明”模板争论两周——法务坚持输出必须包含“偏差性质”正向/负向/中性和“影响等级”重大/一般/无而业务方认为太复杂。最终妥协方案是训练集中只保留“影响等级”但要求模型在输出中必须用括号注明判断依据如“依据招标文件第 3.4.5 条该偏差未改变核心服务范围”。2.3 第三层响应质量维度Quality DimensionSFT 只教模型“生成什么”DPO 才教它“生成得好不好”。因此我们在数据集中为每个指令响应对预定义了 5 个可量化评估的质量维度准确性响应内容与招标文件原文的符合度按 0-3 分打分0完全错误3完全正确且无冗余。完整性是否覆盖指令要求的所有子任务。例如指令要求“提取工期、质量标准、付款方式”响应缺一项即扣 1 分。合规性是否违反投标领域铁律。例如在报价相关响应中出现“可协商”“面议”等字眼直接判 0 分在资格条件响应中遗漏“无行贿犯罪记录声明”扣 2 分。结构化程度输出是否符合预设 JSON Schema 或 Markdown 表格规范。字段缺失、类型错误、嵌套层级错误均扣分。可追溯性是否在响应中明确标注信息来源。例如“根据招标文件第 2.1.3 条”或“见附件三图纸目录第 5 项”未标注则扣 1 分。这些维度不是事后人工评而是在数据构造阶段就由标注规则固化。例如一个“条款解析”响应若未在obligation_party字段填入“投标人”或“招标人”系统自动判定“准确性”得分为 1部分正确无需人工干预。2.4 第四层对抗样本注入Adversarial Injection真实投标场景充满陷阱。我们专门设计了三类对抗样本强制模型学会“质疑”而非“盲从”歧义条款样本选取招标文件中存在表述模糊的条款如“类似项目业绩指近 3 年内完成的合同额不低于 5000 万元的市政工程”。我们构造多个响应一个正确指出“需同时满足年限、金额、专业类别三个条件”另两个分别错误强调“仅看合同额”或“仅看年限”。DPO 阶段模型必须学会偏好前者。矛盾条款样本故意组合来自同一招标文件不同章节的冲突要求如“技术标须提供 3 份纸质版”与“所有投标文件须加密上传至电子平台”。响应中必须明确指出矛盾点并建议“以电子平台要求为准纸质版仅作备查”而非强行调和。越界请求样本模拟用户提出违规指令如“把投标保证金金额改成 0 元以降低成本”。模型响应必须是“拒绝 法规依据”如“根据《招标投标法实施条例》第二十六条投标保证金不得为零建议按招标文件要求的 2% 投标报价缴纳”。实测心得这部分工作量占整个数据工程的 35%但带来的收益最大。上线后Agent 对用户模糊提问的澄清率从 41% 提升到 89%对明显违规指令的拦截率 100%。很多团队省掉这步结果模型成了“好好先生”用户让它干啥它干啥最后背锅的永远是业务方。2.5 第五层版本与溯源体系Version Traceability投标规则常变数据集必须可回溯。我们为每个训练样本赋予唯一 ID格式为TENDER-YYYYMMDD-XXXXX如TENDER-20240520-00123并建立三级溯源源文件溯源记录该样本出自哪份招标文件文件名哈希值、哪一页、哪个条款编号。标注溯源记录标注员 ID、标注时间、所用标注规则版本号如RULE_V3.2。校验溯源记录法务/业务方审核意见、修改痕迹、最终确认时间。这套体系让我们在模型上线后遇到问题时能 5 分钟内定位到问题样本的原始出处、标注依据和审核记录。有一次客户反馈“Agent 将‘联合体牵头人’误判为‘单一投标人’”我们查溯源链发现问题样本源自一份过期的招标文件模板2022 版而当前规则已更新为 2024 版。立刻将该样本从训练集剔除并补充 12 个新版样本问题当天解决。3. 从 PDF 到 JSONL数据流水线的七道工序与三个致命陷阱有了“宪法”下一步是把纸面规则变成机器可食的数据。我们构建了一条端到端的数据流水线共七道工序。它看起来像标准 ETL 流程但在投标领域每一道工序都藏着让模型“学歪”的致命陷阱。下面我逐一道来重点讲清那些只有踩过坑的人才知道的细节。3.1 工序一招标文件标准化采集Standardized Acquisition陷阱“来源多样性”不等于“质量多样性”很多团队追求爬取 1000 份不同地区、不同行业的招标文件结果发现 80% 是格式混乱的 Word 转 PDF文字识别错误率高达 35%。我们调整策略聚焦 3 类高质量信源宁缺毋滥国家级平台中国招标投标公共服务平台强制使用标准 XML 结构字段完整省级国企平台如上海申通地铁集团招标网PDF 由统一排版系统生成OCR 准确率 99%行业龙头代理机构如中招国际提供结构化 Word 模板含内置样式标签。实操步骤编写专用爬虫只抓取上述三类信源且过滤掉“公告”“更正”等非正式文件对下载的 PDF先用pdfinfo检查是否为“PDF/A”标准格式确保长期可读再用pdffonts检查是否嵌入全部字体避免 OCR 乱码对非标准 PDF启动人工复核流程由熟悉该地区招标惯例的同事快速浏览判断是否值得投入 OCR 成本。我们曾为一份“某市水利局勘察设计招标”放弃 OCR因为其 PDF 是扫描件手写批注混合OCR 后全是“□□□□□”人工录入成本反而更低。经验不要迷信自动化。我们 20% 的高质量样本来自 3 位资深招标专员的手动整理。她们用 Excel 表格一行一个条款一列一个属性原文、条款类型、约束等级、常见歧义点这份“人肉结构化数据”成为我们规则校验的黄金标准。3.2 工序二多模态 OCR 与结构还原Multi-modal OCR Structure Recovery陷阱“识别文字”不等于“理解结构”通用 OCR如 PaddleOCR能认出“2.3.1 投标有效期”但无法区分这是标题还是正文编号更无法识别表格线。我们采用三阶段融合策略第一阶段文本 OCR用PaddleOCR识别所有文字输出带坐标的文本块text box第二阶段布局分析用LayoutParser检测页面元素类型标题、段落、表格、图片特别训练了一个小模型专用于识别“招标文件特有的标题层级”如“第一章 总则”“第一节 一般规定”“一、投标人须知前附表”第三阶段表格重建对 LayoutParser 标记的表格区域用TableTransformer重建 HTML 表格结构再转换为 Markdown 表格。关键技巧强制保留原始合并单元格并在 JSON 元数据中标注is_merged: true和merged_from: [A1, A2]。实测对比单用 PaddleOCR表格字段错位率 22%加入 LayoutParser 后降至 7%引入 TableTransformer 后稳定在 0.8%。那 0.8% 的残余错误全部进入人工复核队列。3.3 工序三原子单元智能切分Intelligent Atomization陷阱“按标题切分”会割裂语义连续性招标文件中大量条款是跨页、跨节的。例如“投标人须知前附表”可能在第 5 页开始但关键的“投标保证金”细则在第 12 页的附件里。简单按H1/H2标题切分会把一个完整条款切成两半。解决方案我们训练了一个轻量级 BERT 模型tender-chunker它不预测分类而是预测“段落边界概率”。输入是连续的文本块序列输出是每个块末尾的“是否为原子单元结束”的概率。训练数据来自人工标注的 500 份文件标注规则是“当一个自然段完整表达了某个可独立执行的业务规则时即为一个原子单元”。例如“投标保证金人民币贰佰万元整¥2,000,000.00”是一个单元而紧随其后的“缴纳方式银行保函”是另一个单元尽管它们在同一段落里。关键参数我们设置阈值为 0.65。低于此值系统将后续段落合并进来直到概率超过阈值。这保证了每个原子单元的业务完整性平均长度从 87 字提升到 142 字但语义密度更高。3.4 工序四指令-响应对的半自动构造Semi-auto Instruction-Response Generation陷阱“指令模板化”不等于“响应可复制”如果只是把模板套进去会生成大量“正确但无用”的响应。例如指令模板“提取工期”响应可能是“180 日历天”这没错但对 Agent 执行无指导意义。我们需要的是“可执行指令”即响应中必须包含操作路径。我们的做法指令侧在模板基础上注入上下文约束。例如不是“提取工期”而是“从技术标‘施工组织设计’章节中提取总工期天数并注明计算依据如关键线路图、网络计划图”响应侧由资深招标师编写“黄金响应”然后用LLM-as-a-Judge进行一致性校验。具体是将黄金响应和招标文件原文喂给一个冻结权重的 Qwen2-7B让它判断“该响应是否能被原文唯一支持”。只有置信度 0.95 的响应才入库。我们构建了 127 个核心指令模板每个模板配 3-5 个黄金响应覆盖 92% 的高频场景。剩下的 8%全部归入“长尾指令库”由业务方按需提交每周更新。3.5 工序五对抗样本的靶向生成Targeted Adversarial Sample Generation陷阱“随机加噪”无法模拟真实业务陷阱网上教程教你在文本里随机替换同义词这对投标场景毫无意义。真实的对抗来自业务逻辑的微妙冲突。我们设计了靶向生成器tender-adversary它基于三类规则生成规则冲突库收集 200 条跨章节规则冲突案例如“资质要求”与“业绩要求”的年限计算方式不一致生成指令如“请协调以下两条要求1. 投标人须具备近 3 年市政业绩2. 项目经理须具备近 5 年同类业绩”表述歧义库整理 150 种招标文件常见歧义表述如“不少于 3 家”指供应商数量还是分包商数量生成指令如“解释‘本项目拟分包给不少于 3 家专业公司’中的‘不少于 3 家’指代对象”越界请求库基于历史用户提问日志提炼 89 个高频越界请求如“如何隐藏母公司名称”“能否用子公司业绩代替”生成指令如“请提供一份不体现母公司全称的投标函模板”。生成的对抗样本100% 由法务终审。他们不是看“对错”而是看“是否真实可能发生”。一个样本被拒的最高频理由是“现实中没人会这么问太假”。3.6 工序六多维度质量初筛Multi-dimension Quality Pre-filtering陷阱“人工抽检”无法覆盖数据集的系统性偏差我们开发了一个自动化初筛引擎对每个样本进行五维打分格式合规分检查 JSON Schema 是否符合预定义规则如obligation_party字段值是否在[投标人, 招标人, 监理单位]中文本纯净分检测 OCR 引入的乱码如“□”“”、异常空格、不可见字符逻辑矛盾分用规则引擎检查响应是否自相矛盾如“工期180 天”与“开工日期2024-01-01”、“竣工日期2023-12-31”并存来源可信分根据信源类型国家级/省级/代理赋予权重低权重样本触发更严校验多样性分统计指令模板、条款类型、地域分布的覆盖率防止某类样本过载。只有五维得分均 ≥0.8 的样本才进入人工标注环节。这一步筛掉了 31% 的样本大幅降低了人工成本。3.7 工序七双盲交叉标注与仲裁Double-blind Cross-annotation Arbitration陷阱“标注指南”写得再细也无法消除主观差异我们采用三人制两名初级标注员A/B独立标注同一份样本一名高级仲裁员C负责裁决。关键机制盲审A 和 B 不知道对方答案C 不知道 A/B 的身份分歧处理当 A/B 答案不一致时C 不是简单选一个而是必须写出仲裁意见说明“为什么 A 对/B 错”并引用招标文件原文和标注指南条款动态校准每周汇总所有仲裁意见更新标注指南。例如针对“技术标响应条款”的标注我们最初定义“响应必须逐条对应”但仲裁发现大量优质响应采用“归类响应”如将 5 条关于安全的要求合并为一段。于是指南更新为“允许归类响应但必须在响应开头声明‘以下响应涵盖招标文件第 4.2.1 至 4.2.5 条要求’”。这套机制让标注一致性Kappa 系数从初期的 0.62 提升到 0.89达到专业级水平。4. 数据集不是终点而是 Agent 认知演化的起点SFT 与 DPO 的协同设计逻辑造出训练集不等于任务完成。数据集的价值最终要通过 SFT监督微调和 DPO直接偏好优化两个阶段释放。很多团队把数据集当“燃料”烧完就扔结果模型学了一堆碎片知识却无法形成稳定认知。我们的做法是让数据集的五层结构直接映射到 SFT 和 DPO 的训练目标与损失函数设计中。这才是“从零造数据”的终极目的。4.1 SFT 阶段不是拟合输出而是强化“契约意识”传统 SFT 目标是让模型输出尽可能接近标注员写的“黄金响应”。但在投标领域这会导致模型过度拟合个别写法失去泛化能力。我们的 SFT 目标做了三层重构第一层结构化输出强制Structural Output Enforcement我们修改了损失函数在标准交叉熵损失L_ce基础上增加结构化约束损失L_structL_sft L_ce λ * L_struct其中L_struct计算模型输出 JSON 的 Schema 符合度。例如若模型在obligation_party字段输出了“甲方”而 Schema 要求只能是[投标人, 招标人, 监理单位]则L_struct会给出高额惩罚。λ 设为 0.3经实验这个权重能让模型在保持语言流畅性的同时100% 遵守字段约束。第二层条款溯源显式化Clause Traceability Explicitness我们要求模型在每个响应末尾必须添加[SOURCE: XXX]标签XXX 为条款编号。为此我们在训练数据中将所有黄金响应的末尾都加上了[SOURCE: 2.3.1]这样的标签并在损失函数中对SOURCE标签的预测准确率单独加权权重 0.2。结果是模型不仅学会了“说什么”更学会了“这句话的依据是什么”。上线后业务方第一次看到 Agent 输出带来源标注的响应惊讶地说“这比我们老法师写得还规范。”第三层对抗鲁棒性注入Adversarial Robustness Injection在 SFT 训练时我们并非只喂“标准样本”而是按 1:4 的比例混入对抗样本。但关键在于对抗样本的标签不是“正确答案”而是“正确思考路径”。例如对于歧义条款“类似项目业绩”标准响应是“需同时满足年限、金额、专业类别”而对抗样本的标签是{ analysis: 该条款存在三重约束需逐一验证1. 时间约束近3年2. 金额约束≥5000万元3. 专业约束市政工程。任一缺失即不满足。, conclusion: 不满足 }这迫使模型在 SFT 阶段就建立“分析-结论”的推理链而非死记硬背结论。4.2 DPO 阶段不是排序好坏而是校准“决策权重”DPO 的核心是让模型学会在多个合理响应中选择“更优”的那个。但在投标领域“优劣”不是主观感受而是由业务规则定义的权重。我们据此设计了三层偏好校准第一层质量维度加权偏好Weighted Quality Preference我们没有简单地让模型判断“A 响应好于 B 响应”而是为每个质量维度分配业务权重准确性权重 0.4错一条核心条款一票否决合规性权重 0.3违反铁律直接降级可追溯性权重 0.2无来源标注视为风险项完整性与结构化权重 0.1次要考量。DPO 的偏好对(y_w, y_l)不是两个完整响应而是两个响应在各维度的得分向量。模型学习的是“当准确性得分差 1 分时需要可追溯性得分高多少分才能扳回”。第二层场景敏感偏好Scenario-sensitive Preference我们发现不同场景下“优”的定义不同。例如在“投标函生成”场景合规性权重升至 0.5因为一个错字可能导致废标在“技术方案摘要”场景完整性权重升至 0.4因为客户更关注覆盖要点在“答疑澄清”场景可追溯性权重升至 0.35因为所有回复必须有据可查。因此我们在 DPO 数据中为每个偏好对标注scenario_tag并在模型中加入场景嵌入Scenario Embedding让偏好学习具备场景感知能力。第三层长尾指令专项偏好Long-tail Instruction Preference针对只出现 1-2 次的长尾指令如“解释联合体协议中‘连带责任’的法律含义”我们采用迁移偏好学习Transfer Preference Learning。具体是用高频指令如“解释投标保证金退还条件”训练出的偏好模型作为初始化权重再用少量长尾指令的偏好对进行微调。这解决了长尾场景数据稀疏的难题让模型对罕见问题也能给出符合业务逻辑的响应。4.3 数据集的持续进化从静态集合到动态知识图谱最后必须强调这个“从零造出的训练集”绝不是一个静态的、一次性的产物。它是我们投标 Agent 认知演化的活体基座。我们建立了三套机制确保它持续生长问题驱动的增量注入每处理一个用户真实提问无论是否被 Agent 解决只要它暴露了现有数据集的盲区如新出现的“绿色建筑评价标准”条款就立即启动“原子单元-指令-响应”全流程24 小时内注入数据集模型反馈的闭环修正当 Agent 输出被人工修正时该样本连同修正痕迹自动进入“待复核队列”由标注团队分析是模型能力问题还是数据集覆盖不足规则变更的主动同步我们订阅了国家发改委、住建部等官网的法规更新 RSS一旦检测到《招标投标法实施条例》修订立即启动“影响分析”识别出受影响的条款类型并批量生成新样本。这套机制让我们的数据集每月更新率保持在 12%-15%而不是“上线即冻结”。一位合作的招标代理机构负责人说“你们的 Agent 越用越懂行不像别的 AI用久了反而越来越僵。”——这背后是数据工程从未停止的脉动。我在实际操作中发现最耗时的从来不是写代码或调模型而是和法务、业务、招标师们坐在会议室里为一个条款的标注规则争论两小时。但正是这些争论把模糊的业务经验变成了机器可执行的精确指令。当你看到 Agent 第一次自主识别出招标文件中的隐性矛盾并给出合规建议时你会明白所谓“造数据”造的不是冷冰冰的数字而是让机器真正理解人类规则的第一块基石。