文章摘要

招标文件通常同时包含资格条件、技术参数、评分办法、商务条款、合同模板和附件表格。如果简单按固定字数切分，容易把评分条件拆散、把表格表头与数据分离，并导致模型找到了条款却无法判断完整约束。本文给出一套适用于招投标知识库的层级分块方案，包括文档结构识别、章节父子块、评分项原子块、参数表重建、元数据设计和混合检索流程。

一、为什么普通固定分块不适合招标文件

最常见的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"]
}

十二、一个简单的分块数据模型

from pydantic import BaseModel, Field
from typing import Literal


class TenderChunk(BaseModel):
    chunk_id: str
    document_id: str
    parent_id: str | None = None
    content_type: Literal[
        "BACKGROUND",
        "QUALIFICATION",
        "TECHNICAL",
        "SCORE",
        "COMMERCIAL",
        "CONTRACT",
        "TABLE_ROW"
    ]
    chapter: str | None = None
    clause_no: str | None = None
    content: str = Field(min_length=1)
    page_start: int
    page_end: int
    mandatory: bool = False
    veto: bool = False
    score_value: float | None = None
    metadata: dict = Field(default_factory=dict)

十三、分块后必须做质量检查

自动检查：

空Chunk
过短Chunk
超长Chunk
缺少页码
缺少章节
表格行没有表头
评分项没有分值
否决项未标记
重复Chunk
跨页内容断裂

人工抽检重点：

  • 评分章节；
  • 参数表；
  • 废标条款；
  • 付款条款；
  • 交付和验收；
  • 合同违约责任。

十四、如何建立测试集

建议准备真实问题：

本项目最高限价是多少？
有哪些废标条件？
技术方案评分包含哪些小项？
哪些参数必须提供截图？
付款比例和付款节点是什么？
项目要求多久完成？
是否必须提供原厂授权？

每个问题记录：

正确条款
正确页码
正确答案
是否需要多块组合

评测指标：

Recall@K
评分项召回率
否决条款漏召回率
页码准确率
回答忠实度

其中否决条款漏召回率应作为高风险指标单独统计。

十五、推荐的完整处理链路

PDF或Word
→ 版面解析
→ 标题与条款识别
→ 表格重建
→ 内容类型分类
→ 层级父子分块
→ 元数据提取
→ 向量化与关键词索引
→ 质量检查
→ 人工抽检
→ 上线检索

总结

招投标RAG不能把整个文件当成普通文章处理。

正确分块的核心是：

按业务结构切分
而不是按字符数切分

评分项、否决条款、参数表和合同条款都应采用独立策略，并通过父子块、元数据过滤和混合检索保留完整语义。

延伸阅读

如果你正在关注企业级 AI 应用、Agent、RAG、MCP 与大模型工程化落地，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。