招标文件智能解析系统

一套面向政企办公场景的招标文件深度解析与标书审查工具。上传招标文件（.doc / .docx / .pdf），AI 自动提取关键信息并生成结构化分析报告、投标文件格式模板、投标文件大纲和资料清单。同时支持两类独立的审查能力：

• 标书合规审查：基于招标文件自动判定投标文件是否满足实质性要求（固定审核 / 智能审核双模式）。
• 暗标审核：在匿名评审场景下自动检测投标文件是否泄露投标人身份信息（格式规则 + 内容规则双引擎）。

一、系统概述

1.1 核心价值

• 提效 — 传统人工阅读一份 100+ 页招标文件需 2-4 小时，AI 解析只需 5-10 分钟
• 全面 — 自动覆盖全部 7 大审查模块 + 暗标格式/内容双类规则，避免人工遗漏
• 可追溯 — 每条提取结果可对照原文定位，审查结论可追溯到具体段落（Word 批注精准锚定）
• 可复用 — 招标解读完成后的结构化数据可多次用于不同版本的标书审查
• 低误报 — 暗标审核采用「可识别性测试 + 候选 severity 分级」机制，显著抑制模型投机性质疑

1.2 业务场景

二、招标解读 — 详细实现

招标解读是将一份非结构化的招标文件（Word/PDF）转化为结构化数据的核心环节，分为以下 5 个步骤：

2.1 文档解析（Parsing）

输入：.doc / .docx / .pdf 格式的招标文件原始文件

处理逻辑：

1. 根据文件后缀选择解析器（docx_parser.py / pdf_parser.py / doc_parser.py）
2. 按 XML body 元素顺序遍历文档内容，保持段落和表格的原始位置关系
3. 对每个段落提取：文本内容、样式名称（标题/正文/列表等）
4. 对每个表格提取：二维行列表数据 table_data，并将表头拼接为摘要文本
5. 输出：List[Paragraph]，包含全文所有段落和表格的索引编号

关键技术点：

• 段落和表格交错排列，而非先列所有段落再列所有表格，确保空间位置关系不丢失
• 样式通过 w:pPr > w:pStyle XML 节点精确获取，区分 Heading 1/2/3 和正文

2.2 智能索引（Indexing）

输入：解析后的段落列表 List[Paragraph]

处理逻辑（混合 3 层策略，取最优结果）：

输出：

• sections：扁平的章节列表（含标题、起始/结束段落号、层级）
• tagged_paragraphs：每个段落被打上分类标签（资格、格式、流程等）
• embeddings_map：各段落的向量表示（用于语义相似度搜索）
• confidence：索引置信度（0-1），反映 TOC 识别的准确度

2.3 结构提取（Extraction）

输入：tagged_paragraphs + embeddings_map

处理逻辑（9 个并行提取模块）：

段落筛选 — 关键词得分制：

各模块的段落筛选现已升级为关键词得分制（config/keyword_scores.yaml），替代了原来各模块独立实现的 _filter_paragraphs() 方法：

1. 得分计算：对每个段落根据 3 类关键词（章节标题、正文、标签）匹配计算加权得分
   • 高档关键词 = 7 分（如 Module E 的"废标"、"无效"）
   • 中档关键词 = 4 分（如 Module B 的"注册资本"、"ISO"）
   • 低档关键词 = 2 分（如 Module F 的"签章"、"密封"）
2. 阈值过滤：得分低于模块阈值的段落直接丢弃（各模块独立阈值，如 Module E 为 5 分）
3. 向量补漏：对被丢弃的段落用语义向量匹配补充（threshold=0.5）
4. 最低数量保障：若筛选后段落数 < min_count，从剩余段落中取得分最高的补够
5. 原文顺序排列：最终输出按段落索引排序，保持文档结构

核心优势：统一配置、可调权重、得分可追溯、向量语义兜底

每个模块的提取流程：

1. 段落筛选 — 关键词得分制 + 语义向量补漏（见上文）
2. 交叉引用解析 — 检测"详见附件X"、"见第X款"等引用，自动追加分段
3. 分批处理 — 超过上下文限制时自动按章节边界分批，防止 LLM 上下文超限
4. LLM 提取 — 云端/本地模型，结构化 JSON 输出
5. JSON 修复 — 自动处理 LLM 常见错误（尾部逗号、单引号、控制字符）
6. 表格渲染 — Word 表格转为 Markdown 格式输入 LLM，确保评分细则完整解析

2.4 人工审核（Review）

功能：逐模块对照原文校对 AI 提取结果

• 左侧显示招标原文，右侧显示 AI 提取的表格数据
• 可对任意单元格添加批注修改意见
• 提交批注后 LLM 根据修改意见重新提取对应 section
• 支持跳过人工审核直接生成

2.5 文档生成（Generation）

自动生成 3 类 Word 文档：

2.6 投标文件大纲生成（Bid Outline）

在招标解读完成后可一键生成投标文件大纲（取代早期的 bid_format 粗粒度抽取），为后续撰写标书提供带章节编号、提示词与示例的骨架文档。

4 层并行架构：

说明：大纲生成走独立流水线，不再进入人工审核环节；审核仅覆盖标准 7 大模块。

三、暗标审核 — 详细实现

暗标审核（又称"匿名评审审查"）用于检测投标文件是否在评审匿名化阶段泄露了投标人身份信息（公司全称、Logo、公章、案例客户名等）。它与第四章「标书审查」相互独立：后者检查实质合规性，前者专查身份暴露。

3.1 规则体系：格式规则 vs 内容规则

系统内置一套默认通用规则（config/anbiao_default_rules.json），并支持为每个项目额外上传一份项目级暗标规则文档（Word/PDF）。系统会用 LLM 自动将两类规则分类合并：

每条规则带 is_mandatory（强制 / 建议）字段，分别映射到后续结果聚合的 mandatory / advisory 封顶约束。

3.2 流水线（7 步）

Step 1  解析暗标规则（项目规则 + 默认规则合并，LLM 分类为 format/content）
Step 2  解析投标文件（docx_parser 提取段落 + 格式信息 DocumentFormat）
Step 3  图片提取 + AI 预描述（证书/公章/Logo 结构化描述）
Step 4  格式规则审查（逐条比对 DocumentFormat）
Step 5  内容规则审查（章节级 LLM 审查 + conclude 聚合）
Step 6  生成双表审查报告（.docx + Word 批注精准锚定违规段落）
Step 7  清理临时文件并更新数据库状态

3.3 内容规则审查：章节审查 + 综合判定

内容审查采用逐章节审查 → 综合判定的两级架构（取代早期的三阶段批处理），显著降低提示词长度和成本：

1. 章节切分：按招标解读索引出的章节树收集叶子节点，按段落数量/图片数量切分为审查批次（ChapterBatch）。
2. 章节审查：每个批次独立调用 LLM，输出 candidates[]（每条含 para_index / severity / identification_path / reason）。
3. 综合判定：将所有章节结果拼接喂给 conclude prompt，LLM 给出 pass / warning / fail 总体结论。
4. 聚合降级：规则级 severity 由候选项 severity 聚合得出，advisory 规则无论模型是否误报 fail，一律封顶 minor。

3.4 误报抑制机制（Prompt Sensitivity Optimization）

暗标审核的核心难点是高误报——模型容易把通用描述（如"我司自研平台"、"某头部城商行"、"ISO9001"、"华为云"）标记为违规。系统通过以下 5 层机制显著抑制误报：

3.5 输出：双表批注报告

最终生成一份投标文件副本（.docx），包含：

• 逐段 Word 批注：在每个违规 para_index 上插入一条 Word 原生批注，显示规则类别 + identification_path + reason。
• 汇总双表：文档末尾插入两张表格——格式规则表 / 内容规则表，各自列出规则编号、规则内容、审查结论、严重度、违规位置索引。

四、标书审查 — 详细实现

标书审查是在招标解读完成后，判定一份投标文件是否满足招标要求的核心功能。提供固定审核和智能审核两种模式。

4.0 前置步骤：条款提取（两种模式共享）

在执行审查之前，系统先从招标解读的结构化数据中自动提取需要审查的条款：

条款来源（按优先级排序）：

1. Module E（废标条款） — severity: critical，最优先审查
2. Module B（资格条件） — severity: major
3. Module F（编制要求） — severity: major
4. Module C（技术评分） — severity: minor

提取规则：

• 遍历各模块的表格数据，提取"风险项/条件/要求/内容/评分"列的文本作为条款
• 跳过"未明确"、"未提及"等无效内容
• 用 [N] 段落索引从招标原文中取完整段落，丰富条款的原文依据
• 重新分配全局唯一编号，按 critical → major → minor 排序

4.1 固定审核（Fixed Review）

适用于快速、标准化的合规检查。处理流程共 7 步：

Step 1: 投标文件索引（0-8%）

将投标文件按与招标文件相同的混合策略解析，构建章节树结构。

Step 2: 条款映射（8-12%）

将每个审查条款通过 LLM 映射到投标文件中最相关的章节节点：

• 将招标文件章节树格式化为带编号的列表（叶子节点标记为"叶子"）
• 逐条调用 LLM，输入条款内容 + 章节列表，输出相关节点编号
• 优先映射到叶子节点（段落数最少，定位最精准）
• 一个条款可映射到多个节点

Step 3: 原文提取（12-15%）

根据映射结果，从投标文件中提取对应章节的原文：

• 将映射的节点路径转换为具体的段落范围
• 提取段落文本，保留 [Pxxx] 标记用于后续批注定位
• 对超长内容自动拆分批次（每批不超过 LLM 上下文限制）

Step 4: 图片提取与描述（15%）

• 从投标文件中提取所有图片（PNG/JPG 等）
• 构建图片映射（filename → file_path）供多模态审查使用

Step 5-6: 逐条审查（15-95%）

并发审查所有条款（最多 8 个并发）：

单条款审查流程：

• 若原文较短（1 批次）→ 直接调用 LLM 审查，输入条款 + 原文 + 项目背景
• 若原文较长（多批次）→ 顺序累积审查：
  1. 第一批：LLM 提取候选问题段落
  2. 中间批次：传递上批摘要，继续扫描
  3. 末批次：综合前序摘要 + 候选段落，做出最终判定

审查输出：

{
  "result": "pass" | "fail" | "warning",
  "confidence": 85,
  "reason": "投标文件第 3 章明确提供了营业执照，满足要求",
  "locations": [
    {"para_index": 123, "text_snippet": "营业执照复印件", "reason": "已提供营业执照"}
  ]
}

Step 7: 生成批注报告（95-100%）

将审查结果写入投标文件副本，生成带 Word 批注的审查报告：

• 在问题段落插入 Word 批注（显示审查结论和理由）
• 在文档末尾插入审查汇总表格
• 生成带高亮标记的 HTML 预览

4.2 智能审核（Smart Review）

适用于复杂、需要深度理解的审查场景。处理流程共 7 步：

Step 1: 投标文件索引（0-5%）

与固定审核相同，解析投标文件并构建章节树。

Step 2: 图片提取与 AI 预描述（5-8%）

• 提取投标文件中所有图片
• 调用多模态 LLM 对每张图片生成结构化描述：
  • 证书类型、编号、有效期、公司名称、盖章情况
• 构建 _图片索引.md，记录所有图片的位置和描述

Step 3: 条款→招标文件映射（8-11%）

与固定审核的关键区别：将条款映射到招标文件章节（而非投标文件）：

• 从招标解读的 indexed.json 构建招标文件章节索引
• LLM 映射条款到招标文件章节节点
• 提取对应招标原文作为条款上下文（tender_context）
• 目的：帮助 Agent 理解条款背景，Agent 自行浏览投标文件

Step 4: 构建 Markdown 文件夹（11-14%）

将投标文件拆分为可浏览的文件夹结构：

tender_folder/
├── _目录.md              # 整体结构和各章节段落范围
├── _图片索引.md           # 所有图片的 AI 描述索引
├── 01_投标函.md          # 章节 1 内容
├── 02_资格证明文件.md     # 章节 2 内容
│   └── images/           # 原始图片文件
│       ├── img001.png
│       └── img002.jpg
├── 03_技术方案.md
...

每个章节 MD 文件中：

• 段落标记 [Pxxx] 用于精确定位
• 图片描述以 > [图片描述] ... 引用块嵌入
• 表格以 Markdown 表格格式渲染

Step 5-6: Agent 自主审查（15-95%）

核心创新：不是 LLM 直接审查，而是驱动 Agent 自主执行审查：

1. 构建审查提示词：

   • 条款内容 + 条款依据 + 严重程度
   • 项目背景 + 招标原文参考（tender_context）
   • 投标文件文件夹路径

2. Agent 执行审查技能（/bid-review）：

   • 第一步：阅读 _目录.md 和 _图片索引.md，了解整体结构
   • 第二步：根据条款判断哪些章节可能相关
   • 第三步：使用 Read/Glob/Grep 工具自主浏览相关章节 MD 文件
   • 第四步：查看图片描述（等同于查看原始图片）
   • 第五步：综合判定并输出 JSON 结果

3. 并发执行：最多 4 个条款并行审查

Agent 审查关键规则：

• 图片描述即审查依据，不要求读取原始图片
• locations 中的 para_index 必须是实际阅读到的 [Pxxx] 标记
• 找不到相关内容时返回 warning 而非 fail
• 跨页文档（如财务报告仅标题页）必须追踪后续页面描述

Step 7: 生成审查报告（95-100%）

与固定审核相同，生成批注报告后自动清理临时文件夹释放磁盘空间。

4.3 两种模式对比

五、技术架构

5.1 整体技术栈

5.2 系统架构图

┌─────────────────────────────────────────────────────────────────┐
│                        用户浏览器                                │
│  ┌──────────┐  ┌──────────  ┌──────────┐  ┌──────────────┐    │
│  │ 登录认证  │  │ 招标解读  │  │ 标书审查  │  │  文件管理     │    │
│  │ (JWT)    │  │ (5步骤)  │  │(固定/智能)│  │ (CRUD+预览)  │    │
│  └──────────┘  └──────────┘  └──────────┘  └──────────────┘    │
│                           ┌──────────────┐                      │
│                           │ 管理员配置    │  ← NEW               │
│                           │(模型/模式切换)│                      │
│                           └──────────────┘                      │
└──────────────────────────┬──────────────────────────────────────┘
                           │ HTTPS
┌──────────────────────────▼──────────────────────────────────────┐
│                          Nginx :80                               │
│  ┌─────────────────────┐  ┌─────────────────────────────────┐   │
│  │  静态文件 (Vue SPA)  │  │  API 代理 /api/*                │   │
│  └─────────────────────┘  └────────────────┬────────────────┘   │
└────────────────────────────────────────────┼─────────────────────┘
                                             │
                    ┌────────────────────────▼────────────────────────┐
                    │              FastAPI API :8000                   │
                    │  ┌─────────────┐  ┌─────────────┐  ┌─────────┐ │
                    │  │  认证路由    │  │  任务路由    │  │ 审查路由 │ │
                    │  │  /auth/*    │  │  /tasks/*   │  │/reviews │ │
                    │  │             │  │  /files/*   │  │/*       │ │
                    │  └─────────────┘  └─────────────┘  └────┬────┘ │
                    │  ┌─────────────────────────────────────────┐   │
                    │  │  管理员配置路由 /admin/config/*  ← NEW    │   │
                    │  │  (模型切换、Ollama 发现、连接测试)        │   │
                    │  └─────────────────────────────────────────┘   │
                    └────────────────────────────────────────────────┘
                                                              │
                    ┌─────────────────────────────────────────┼────────────────────────────┐
                    │                                         │                            │
               ┌────▼────┐                               ┌────▼────┐                 ┌────▼────┐
               │PostgreSQL│                               │  Redis  │                 │ Celery  │
               │  :5432   │                               │  :6379  │                 │ Worker  │
               │(结构化数据)│                               │(消息队列)│                 └────────┘
               └─────────┘                               └─────────                      │
                                                                                     ────┴────┐
                                                                                     │         │
                    ┌──────────────────────────────────────────────────────────────────┐
                    │                 双模式 AI 服务  ← NEW                             │
                    │  ┌──────────────────────┐    ┌──────────────────────────────┐    │
                    │  │  云端模式 (DashScope)  │    │  本地模式 (Ollama)  ← NEW    │    │
                    │  │  qwen3.5-plus API     │    │  gemma4/qwen3 + 嵌入模型     │    │
                    │  └──────────────────────┘    └──────────────────────────────┘    │
                    └──────────────────────────────────────────────────────────────────┘
                                                                                     ┌────────▼───┐
                                                                                     │ haha-code  │
                                                                                     │  Agent     │
                                                                                     │  :3000     │
                                                                                     │(审查技能)  │
                                                                                     └────────────┘

5.3 数据流

招标解读数据流:
  用户上传 .docx ──→ 文档解析 (Paragraphs) ──→ 智能索引 (Sections + TaggedParagraphs)
      ──→ 关键词得分筛选 + 向量补漏 ──→ 结构提取 (9模块 JSON) ──→ 人工审核 ──→ 文档生成

标书审查数据流（固定审核）:
  用户上传投标文件 ──→ 提取条款 (Clauses) ──→ 映射到投标文件章节 ──→ 提取原文
      ──→ LLM 逐条审查 ──→ 生成批注报告 (.docx + Word 批注)

标书审查数据流（智能审核）:
  用户上传投标文件 ──→ 提取条款 (Clauses) ──→ 映射到招标文件原文 ──→ 构建 Markdown 文件夹
      ──→ Agent 自主浏览审查 ──→ 生成批注报告 (.docx + Word 批注)

5.4 关键技术细节

六、管理员功能 — NEW

管理员（role=admin）可通过侧边栏 「模型配置」 页面切换系统运行模式：

6.1 云端模式 vs 本地模式

6.2 本地模式配置流程

管理员在「模型配置」页面操作：

1. 切换到本地模式 — 点击「本地模式 (Ollama)」按钮
2. LLM 配置：
   • 输入 Ollama 服务器地址（如 http://10.165.44.28:11434）
   • 点击「连接测试」→ 自动发现已拉取的模型列表
   • 选择 LLM 模型 → 自动获取上下文长度、自动配置
3. Embedding 配置：
   • 输入 Ollama 服务器地址（可与 LLM 共用或独立）
   • 连接测试 → 选择嵌入模型 → 自动获取维度和上下文长度
   • 嵌入维度变更会触发警告：已有索引将失效，需重新解析
4. Smart Review 配置：
   • 自动关联 LLM 服务器地址
   • 选择 Sonnet / Haiku / 默认审查模型
5. 保存配置 — 配置写入数据库，同步更新 settings.yaml，并热更新 haha-code Agent

6.3 Ollama 发现 API

管理员配置页面提供以下 API 端点（仅管理员可访问）：

七、快速开始

7.1 环境要求

• Docker & Docker Compose
• AI 模型服务（二选一）：
  • 云端模式：通义千问 API Key（DashScope 控制台获取）
  • 本地模式：Ollama 服务器（已拉取 LLM 和 Embedding 模型）

7.2 安装部署

# 1. 克隆项目
git clone https://github.com/sanwudazhiyuan/-bid-analysis.git
cd -bid-analysis

# 2. 配置环境变量
cp .env.example .env
# 编辑 .env，填入：
#   - DB_PASSWORD（数据库密码）
#   - DASHSCOPE_API_KEY（云端模式时填写，本地模式可不填）
#   - JWT_SECRET（JWT 签名密钥）

# 3. 一键启动
docker compose up -d --build

7.3 本地模式配置（首次使用）

启动后以管理员账号登录，进入侧边栏「模型配置」页面：

1. 切换到「本地模式」
2. 输入 Ollama 服务器地址并测试连接
3. 选择 LLM 和 Embedding 模型
4. 保存配置

7.4 访问地址

• 前端界面: http://localhost
• API 文档: http://localhost:8000/docs

7.5 使用流程

招标解读

上传招标文件 → AI 解析提取（5步流水线） → 人工审核批注 → 生成3类文档

标书审查

选择招标任务 → 上传投标文件 → 选择审核模式 → AI 自动审查（7步流水线） → 下载审查报告

八、项目结构

├── web/                    # 前端 (Vue 3 SPA)
│   ├── src/
│   │   ├── views/          # 页面（登录、招标解读、标书审查、暗标审核 ← NEW、审查结果、管理员配置）
│   │   ├── components/     # 组件（上传、处理进度、审核、预览、Anbiao* 暗标系列 ← NEW）
│   │   ├── composables/    # 组合式函数（useSSE 实时进度订阅）
│   │   ├── stores/         # Pinia 状态管理
│   │   ├── api/            # Axios API 封装（含 configApi ← NEW）
│   │   └── assets/         # 设计令牌 (Tailwind @theme)
├── server/                 # 后端 (FastAPI)
│   ├── app/
│   │   ├── routers/        # API 路由（认证、任务、文件、审查、暗标审核 ← NEW、用户、管理员配置）
│   │   ├── services/       # 业务逻辑层（ModelConfigService、review_preview 等）
│   │   ├── models/         # ORM 模型（Task, ReviewTask, AnbiaoReview ← NEW, User, SystemConfig 等）
│   │   ├── tasks/          # Celery 异步任务（review_task + anbiao_review_task ← NEW）
│   │   └── schemas/        # Pydantic 模型
├── haha-code/              # AI 审查 Agent
│   ├── server.ts           # HTTP 服务（/review + /config ← NEW 端点）
│   ├── skills/             # Skills 系统（bid-review 审查技能）
│   ├── src/                # Agent 核心（TUI、工具、服务层）
│   └── tests/              # Agent 集成测试
├── src/
│   ├── parser/             # 文档解析（docx、pdf、doc）
│   ├── extractor/          # AI 提取引擎（9 个模块提取器 + extract_bid_outline 大纲生成 ← NEW + scoring.py 得分制）
│   ├── indexer/            # 智能索引引擎（TOC + 编号 + 关键词）
│   ├── reviewer/           # 审查引擎
│   │   ├── reviewer.py          # 标书审查（固定 / 智能双模式）
│   │   ├── anbiao_rule_parser.py  # ← NEW 暗标规则 LLM 解析与合并
│   │   ├── anbiao_reviewer.py     # ← NEW 暗标格式 / 内容规则审查引擎
│   │   ├── image_describer.py     # ← NEW 图片 AI 预描述
│   │   └── docx_annotator.py      # Word 批注与双表报告生成
│   └── generator/          # 文档生成（报告、格式、投标文件大纲 ← NEW、清单）
├── config/
│   ├── prompts/            # LLM 提示词模板（含暗标 content/conclude 提示词 ← NEW，引入可识别性测试）
│   ├── anbiao_default_rules.json  # ← NEW 暗标默认通用规则库
│   ├── keyword_scores.yaml # 关键词得分制配置
│   ├── settings.yaml       # 全局配置（DB 同步写入，云端模式含 ${DASHSCOPE_API_KEY} 占位符）
│   └── tag_rules.yaml      # 段落分类规则
├── docker-compose.yml      # 7 容器编排
└── requirements.txt

九、许可证

Apache License 2.0