招投标 RAG：地域继承机制与 LLM 交互逻辑优化

本文档梳理“地域继承机制”的存储与查询策略，并给出 RAG + LLM 的交互优化流程，确保系统既能回答宏观政策，也能处理细粒度的预算计算与区域判断。

---

1. 地域继承机制（Region Inheritance）

1.1 目标

在招投标数据存储中引入“继承”逻辑，减少重复维护规则的成本，同时确保查询时能自动汇总所有适用条款。

1.2 继承层级

推荐采用以下地域层级树：

• 国家级规则（National）
• 省级规则（Province）
• 市级规则（City）
• 区/县级规则（District，可选）
• 项目级规则（Project）

1.3 存储策略

• 省级通用规则：存储在省节点下（如：福建省）。
• 市级特殊规则：存储在市节点下（如：福州市）。
• 项目级条款：存储在项目节点下（针对具体标的）。

1.4 查询合并逻辑

当查询“福州市某项目”时，系统自动合并：

1. 国家级规则
2. 福建省规则
3. 福州市规则
4. 项目级条款

1.5 冲突处理建议

• 优先级：项目级 > 区县级 > 市级 > 省级 > 国家级
• 规则合并：相同字段以更细粒度规则覆盖。
• 解释输出：答案中注明来源层级，便于追溯。

---

2. LLM 交互逻辑优化（按问题类型路由）

在 RAG 系统中，优先用“结构化查询 + 规则判断”，再交给 LLM 生成可读答案，避免让模型直接“算数或判断”。

场景 1：用户问“资格要求是什么？”

动作

• 到条款向量层检索标题或内容包含“资格要求”的 Chunk。
• 将命中的 Chunk 作为来源资料传给 LLM。

LLM 输出
对条款进行结构化归纳，输出主要资格点，并标注引用来源。

场景 2：用户问“这个预算够买多少吨水泥？”

动作

• 在结构化数据层查找材料清单，定位“水泥”行。
• 获取“单价”和预算数值。
• 先在服务端计算：数量 = 预算 / 单价。

LLM 输出
将计算结果整理成可读答案，例如：
“根据清单单价，预算大约可以购买 X 吨水泥。”

场景 3：用户问“我在鼓楼区能投标吗？”

动作

• 使用行政区划树，判断“鼓楼区”是否在项目覆盖范围内（如“福州市”）。
• 同时检索资格条款，确认是否存在额外限制。

LLM 输出
结合区域判断与资格条款，输出可执行结论和原因。

---

3. 数据入库与检索建议

3.1 结构化清洗

• 使用 Python（如 Pandas）将表格数据清洗为标准 JSON。
• 不建议让 LLM 直接“看图识别”表格。

3.2 实体识别与标注

• 在预处理阶段识别“金额、时间、行政区划、项目编号”等实体。
• 将实体写入元数据层，用于后续结构化检索与过滤。

3.3 混合检索

查询时同时进行：

• 向量检索：获取语义相关内容
• 关键词检索：捕捉项目编号、金额、政策条款

最后进行结果合并与去重，再交给 LLM 生成答案。

---

4. 地域继承冲突处理与版本策略

4.1 冲突处理优先级

当多层级规则对同一字段产生冲突时，按以下优先级覆盖：

1. 项目级
2. 区/县级
3. 市级
4. 省级
5. 国家级

若同一层级出现冲突，以“版本号更高 + 生效时间更新”的规则为准。

4.2 规则类型与合并方式

• 覆盖型字段（如：资质要求、投标保证金比例）：用更细粒度规则覆盖。
• 叠加型字段（如：提交材料清单、评分细则条目）：做并集去重。
• 数值型字段（如：最高限价、保证金上限）：默认取更严格值（如更低上限），并记录冲突来源。

4.3 生效时间与失效时间

规则建议包含：

• effective_at（生效时间）
• expire_at（失效时间，可空）

查询时仅纳入“当前有效”的规则，若无有效规则可回退至最近一次版本并标记“可能过期”。

4.4 版本策略

• 版本号：major.minor.patch（例：2.1.0）
• 变更说明：记录“变更原因 + 影响范围 + 发布人”
• 回溯能力：支持按时间点重放规则（用于审计与复盘）

建议数据结构（示例）：

RuleMeta:
  - id
  - scope_level (national/province/city/district/project)
  - scope_code (如：CN-35-01)
  - version
  - effective_at
  - expire_at
  - supersedes (上一个版本id)
  - status (active/expired/draft)

4.5 冲突检测与告警

系统在合并规则时应输出：

• 冲突字段列表
• 冲突来源层级
• 采用规则与理由

对高风险冲突（如“资质门槛降级”）触发告警，需人工确认。

4.6 合并流程建议（伪流程）

input: project_scope
rules = query_rules_by_scope_chain(project_scope)  # 国家→省→市→区→项目
rules = filter_by_effective_time(rules, now)
rules = sort_by_scope_and_version(rules)
merged = merge_rules(rules, strategy_map)
conflicts = detect_conflicts(rules, merged)
return merged, conflicts

---

5. 按现有接口字段的映射示例

以下映射基于现有 REST API 与数据字典字段（docs/10-rest-api-spec.md、docs/06-domain-model-and-data-dictionary.md）。

5.1 地域继承查询

数据来源

• Project.region_code（GET /projects/{id} 返回）

处理逻辑

1. 由 region_code 推导行政区划链路（国家 → 省 → 市 → 区）。
2. 依链路取规则并按优先级合并。

5.2 资格要求问答

数据来源

• Project.tenders（项目关联标段 ID 列表）
• Tender.qualification_requirements
• Notice.content_raw / Notice.attachments（作为兜底来源）

处理逻辑

1. 由 project_id 获取 tenders。
2. 读取标段的 qualification_requirements。
3. 若字段为空，从 notice.content_raw 中补齐条款。
4. 将命中条款注入 LLM Prompt 进行总结。

5.3 预算/清单计算问答

数据来源

• Project.budget_amount、Project.currency
• Notice.attachments / Notice.content_raw（用于解析材料清单与单价）

处理逻辑

1. 预算来自 budget_amount。
2. 单价需从公告附件/正文解析后写入结构化层（建议存为元数据扩展或独立材料清单表）。
3. 服务端先算 数量 = 预算 / 单价，LLM 负责生成表述。

5.4 区域可投标判断

数据来源

• Project.region_code（项目地域范围）
• Organization.region_code（投标主体所在地）
• Tender.qualification_requirements（额外门槛）

处理逻辑

1. 使用行政区划树判断企业所在区域是否落在项目范围内。
2. 同步校验资质条款的区域限定。
3. 将判断结论与依据交给 LLM 生成解释。

5.5 查询上下文拼装示例

{
  "project": {
    "project_id": "p-123",
    "project_name": "某市轨道交通项目",
    "stage": "award",
    "region_code": "350100",
    "budget_amount": 120000000,
    "currency": "CNY",
    "tenders": ["t-1"]
  },
  "tender": {
    "tender_id": "t-1",
    "tender_name": "A 标段",
    "qualification_requirements": "具备市政工程总承包一级资质"
  },
  "notice": {
    "notice_id": "n-1",
    "notice_type": "tender",
    "title": "招标公告",
    "content_raw": "...",
    "attachments": [
      { "name": "工程量清单.xlsx", "url": "..." }
    ]
  }
}

---

6. 小结

通过地域继承 + 结构化数据优先 + LLM 生成的组合，系统能够既回答宏观政策问题，又能精确处理预算与规则判断，实现“懂政策、算细节”的招投标 RAG 能力。

7. 关联文档

• docs/27-rag-pipeline.md：RAG 数据处理与索引流程
• docs/06-domain-model-and-data-dictionary.md：字段与实体口径
• docs/10-rest-api-spec.md：接口字段与查询参数