文章摘要招标文件通常同时包含资格条件、技术参数、评分办法、商务条款、合同模板和附件表格。如果简单按固定字数切分容易把评分条件拆散、把表格表头与数据分离并导致模型找到了条款却无法判断完整约束。本文给出一套适用于招投标知识库的层级分块方案包括文档结构识别、章节父子块、评分项原子块、参数表重建、元数据设计和混合检索流程。一、为什么普通固定分块不适合招标文件最常见的RAG分块方式是每800个字符切一块 重叠100个字符这种方法适合普通文章却很容易破坏招标文件结构。例如评分规则3.2 技术方案评分共20分 1整体架构完整得5分 2实施计划合理得5分 3安全设计完善得5分 4售后服务清晰得5分。 注缺少任意一项该项不得分。如果被切成两个Chunk模型可能只召回前半部分漏掉“缺少任意一项不得分”。招标文件的核心问题不是文本长度而是一个可以独立理解、独立引用、独立响应的业务语义单元有多大。二、先识别招标文件的六类内容建议先进行文档分类资格与合规条件 采购需求和项目背景 技术参数与功能要求 评分办法 商务与报价条款 合同、附件和响应表格不同内容应采用不同分块策略。内容类型分块重点资格条件每个条件独立成块保留否决属性技术要求按功能或参数项拆分评分办法按评分项和得分规则拆分商务条款保留付款、交付、保证金等完整约束合同条款按条款号拆分并保留父章节参数表表头、行号、参数值和备注必须绑定三、第一步保留文档层级结构解析后不要只保存纯文本应保留文档 → 章 → 节 → 条款 → 子条款 → 表格行推荐结构{document_id:BID-2026-018,chapter:第三章 采购需求,section:3.2 技术要求,clause_no:3.2.6,title:批次效期管理,content:系统应支持批次、生产日期和有效期管理……,page_start:42,page_end:42}层级信息既用于检索也用于回答时显示来源。四、使用父子分块而不是只保留小块子块用于精准检索例如一个评分点或一个参数项。父块用于向模型提供完整上下文例如整个评分章节。检索流程用户问题 → 检索子块 → 找到对应父块 → 将子块和必要父块一起送入模型示例{child_id:CHILD-102,parent_id:PARENT-18,content:实施计划完整、进度合理得5分。}父块项目实施方案评分共15分包括项目组织、实施计划和风险控制。这样既提高召回精度也避免失去评分项的整体背景。五、资格条件必须标记“否决项”招标文件中常见未提供营业执照复印件投标无效。这不是普通说明而是硬性否决条件。元数据应包含{content_type:QUALIFICATION,mandatory:true,veto:true,required_material:营业执照复印件,response_action:上传证明文件}检索时否决项应该获得更高优先级。响应生成时系统不能只生成文字还要检查附件是否已经存在。六、评分项应拆成“评分原子块”评分原子块至少包含评分项名称 分值 评分条件 分档规则 扣分条件 需要的证据 来源页码示例{score_item_id:SCORE-TECH-03,name:项目实施方案,max_score:5,rules:[{condition:方案完整、进度合理、职责清晰,score:5},{condition:内容基本完整但职责不够清晰,score:3},{condition:未提供,score:0}],required_evidence:[实施计划,项目组织图,里程碑]}后续Agent可以按每个评分原子块生成响应而不是一次生成整本投标文件。七、技术参数表不能直接转成无结构文本参数表如果被解析成支持 是 支持 不支持 备注几乎无法使用。应转换成每行独立对象{table_id:T-3-2,row_no:18,category:仓储管理,parameter:批次效期管理,requirement:支持批次、生产日期、有效期及预警,mandatory:true,deviation_allowed:false,remark:需提供系统截图}同时保留表头和原始页码。跨页表格招标PDF中的表格经常跨页第二页没有完整表头。解析时需要识别同一表格 → 继承上一页表头 → 合并跨页行 → 保留原页码范围否则第二页数据会失去字段含义。八、推荐的分块尺寸不存在所有文件通用的固定数值但可以使用以下起点块类型建议大小普通背景段落500—1000中文字符单个资格条件完整条件不强制长度单个评分项一个评分项及全部分档单个技术参数一行或一组强关联参数合同条款一个完整条款号父章节1500—4000字符用于上下文扩展重叠不应机械固定为100字符。更推荐按结构重叠子块携带章节标题 子条款携带上级条款摘要 表格行携带表头 评分项携带评分章节总说明九、元数据决定检索质量上限建议至少存储document_id document_version tender_name buyer content_type chapter section clause_no page_start page_end mandatory veto score_value industry publish_date deadline confidentiality_level查询“所有废标条件”时不能只依赖向量相似度应直接过滤veto true查询“技术评分20分中有哪些评分项”时应过滤content_type SCORE十、混合检索比纯向量检索更适合招投标招标文件中有大量精确术语3.2.6 ISO 27001 等保三级 API接口 履约保证金 5个工作日纯向量检索可能忽略精确编号。推荐组合BM25关键词检索 向量语义检索 元数据过滤 Reranker示例权重关键词分数 40% 向量分数 40% 结构和元数据分数 20%实际权重应通过测试集调整。十一、查询改写应该保留硬条件用户问找出所有需要原厂授权并且属于废标项的条款。改写后不能只剩原厂授权要求应生成结构化查询{keywords:[原厂授权,制造商授权],filters:{veto:true,mandatory:true},content_types:[QUALIFICATION,TECHNICAL]}十二、一个简单的分块数据模型frompydanticimportBaseModel,FieldfromtypingimportLiteralclassTenderChunk(BaseModel):chunk_id:strdocument_id:strparent_id:str|NoneNonecontent_type:Literal[BACKGROUND,QUALIFICATION,TECHNICAL,SCORE,COMMERCIAL,CONTRACT,TABLE_ROW]chapter:str|NoneNoneclause_no:str|NoneNonecontent:strField(min_length1)page_start:intpage_end:intmandatory:boolFalseveto:boolFalsescore_value:float|NoneNonemetadata:dictField(default_factorydict)十三、分块后必须做质量检查自动检查空Chunk 过短Chunk 超长Chunk 缺少页码 缺少章节 表格行没有表头 评分项没有分值 否决项未标记 重复Chunk 跨页内容断裂人工抽检重点评分章节参数表废标条款付款条款交付和验收合同违约责任。十四、如何建立测试集建议准备真实问题本项目最高限价是多少 有哪些废标条件 技术方案评分包含哪些小项 哪些参数必须提供截图 付款比例和付款节点是什么 项目要求多久完成 是否必须提供原厂授权每个问题记录正确条款 正确页码 正确答案 是否需要多块组合评测指标RecallK 评分项召回率 否决条款漏召回率 页码准确率 回答忠实度其中否决条款漏召回率应作为高风险指标单独统计。十五、推荐的完整处理链路PDF或Word → 版面解析 → 标题与条款识别 → 表格重建 → 内容类型分类 → 层级父子分块 → 元数据提取 → 向量化与关键词索引 → 质量检查 → 人工抽检 → 上线检索总结招投标RAG不能把整个文件当成普通文章处理。正确分块的核心是按业务结构切分 而不是按字符数切分评分项、否决条款、参数表和合同条款都应采用独立策略并通过父子块、元数据过滤和混合检索保留完整语义。