rag-tender
HunterLzap/rag-tender加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
面向招投标场景的本地化 RAG 标书解析与资质匹配助手
晚上十一点，李工还在加班。明天早上九点要交标书，他刚刚把甲方的招标书翻了三遍，发现里面有 47 条资质要求。营业执照、安全生产许可证、项目经理的建造师证、三年来类似项目的合同……这些材料公司有，但散落在共享盘、邮件附件、财务系统的不同角落。
他一边翻一边在脑子里做排除法："这个业绩项目年份差一年，不行……这个证书刚过期……"
这不是他第一次遇到这种情况。每次投大标，都是这种"大海捞针 + 逐一核对"的重复劳动。他想过用 AI，但公司的标书数据不能上传到云端，用在线大模型有数据泄露风险。
资质通（RAG-Tender） 就是为这种场景而生的——一个完全本地运行的招投标 RAG 系统，不依赖任何外部云服务，所有数据留在本地。
招投标是一个万亿级别的市场。全国每年仅政府采购和工程建设领域的开标项目就超过百万个。对于投标企业来说，编制一份合规的标书本身就是一项高强度脑力劳动：
传统的解决方案是人工编 checklist，但随着业务扩展，checklist 维护成本高，且经验无法系统化复用。资质通将 RAG（检索增强生成）引入这个领域，让 AI 帮助完成"初筛 + 证据召回 + 风险提醒"的工作。
资质通的后端集成了多个文档处理工具，能够处理招投标中常见的各类文件格式：
python-docx 读取 Word 文档，pdfplumber / pypdfium2 解析 PDF 结构化内容。paddleocr（基于 PaddlePaddle）识别图片型文档，这对应了大量纸质扫描件投标材料。raganything 和 minerU——前者负责将文档切分为语义块（chunks），后者处理多栏布局、页眉页脚等复杂版式。解析完成后，标书内容被转化为结构化的要求条目，每条要求带有分类标签（资质类 / 业绩类 / 财务类 / 人员类 / 提交件类），方便后续精准匹配。
检索部分基于 lightrag-hku 实现，这是面向本地场景优化的高效向量检索框架。相比于纯云端方案，lightrag 可以在没有 GPU 的机器上运行，索引数据存储在本地 SQLite 中。
当企业上传资质文件（营业执照、证书、合同等）后，系统自动提取文本、建立向量索引。在匹配阶段，给定一条标书要求，系统通过向量相似度召回最相关的资质证据片段，并结合字段级判断（不是简单的相似度分数），决定该资质是否满足要求。
传统 RAG 系统的典型问题是过度自信——即使召回的证据不够充分，也给出一个看似确定的答案。在投标场景下，这种"幻觉"可能导致企业误以为自己满足资质而报名投标，最终因材料不符被废标，损失投标保证金。
资质通的设计哲学是**"宁可漏报，不可错报"**：当关键证据缺失时，系统将结果标记为"待确认"，而非"通过"，强制要求人工介入复核。这种保守判定策略在实际业务中更安全。
由于是本地部署，用户需要自行提供 LLM API Key（如 OpenAI、Claude、本地部署的开源模型）。资质通通过 cryptography 库的 Fernet 对称加密，将 API Key 加密后写入 SQLite 数据库，而不是明文存储在配置文件或环境变量中。这是一个对安全性敏感的用户非常友好的设计。
┌─────────────────────┐ ┌─────────────────────┐
│ React + MUI 前端 │ ←──→ │ FastAPI 后端 API │
│ (localhost:5173) │ REST │ (localhost:8000) │
└─────────────────────┘ └──────────┬──────────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
┌──────────┐ ┌───────────┐ ┌────────────┐
│ SQLite │ │ 本地文件 │ │ RAG 工作区 │
│ (数据库) │ │ (上传文件)│ │ (向量索引) │
└──────────┘ └───────────┘ └────────────┘
后端基于 FastAPI 构建，采用标准的分层架构：
app/api/：10 个路由模块（tenders、knowledge、match、rules 等），每个对应一个业务域。app/services/：核心业务逻辑，包括 tender_service（标书服务）、match_service（匹配服务）、rag_service（RAG 服务）、rule_library_service（规则库）。app/utils/：工具层，含 crypto.py（API Key 加密）、llm_helpers.py（LLM 调用封装）、text_chunks.py（文本分块）。app/models/ + app/schemas/：Pydantic 数据模型，API 请求/响应结构化验证。前端使用 React 18 + Vite + TypeScript，UI 组件库为 MUI（Material-UI）。通过 React Router 管理页面路由，前端通过 Axios 与后端 REST API 通信。
数据存储使用 aiosqlite（异步 SQLite 驱动），存储标书要求、资质条目、匹配结果、错例和规则。本地文件系统存储上传的原始文件和 RAG 工作区目录。
只需几行命令即可启动：
# 克隆代码
git clone https://github.com/HunterLzap/rag-tender.git
cd rag-tender
# 后端：创建虚拟环境 + 安装依赖
cd backend
python -m venv .venv
.\.venv\Scripts\activate
pip install -r requirements.txt
# 前端：安装 Node 依赖
cd ..\frontend
npm install
# 启动（双击 start.bat 或手动启动）
start.bat
访问 http://localhost:5173 即可使用。API 文档在 http://127.0.0.1:8000/docs。
依赖方面：Python 3.13+、Node.js 22+、LibreOffice（需要加入系统 PATH）。
docker-compose.yml 定义了完整的两容器架构：
services:
backend:
build: ./backend # python:3.13-slim + LibreOffice
volumes:
- ./data:/app/data # 数据持久化到宿主机
environment:
- LIBREOFFICE_PATH=/usr/bin/soffice
frontend:
build: ./frontend # node:22 → nginx:1.27-alpine
depends_on: backend (健康检查通过后启动)
ports:
- "8088:80" # 避免 80 端口冲突
./data 目录挂载到宿主机，即使重建容器也不会丢失业务数据（标书、资质、SQLite 数据库）。这是生产级别部署的推荐方式。
整个使用流程大约分为八个步骤：
整个流程的设计逻辑非常清晰——AI 做初筛，人工做决策，结果可追溯。这正是政企文档处理场景应有的分工。
强烈推荐：
不太适合：
资质通最有价值的地方，不是某一项技术有多前沿，而是它展示了如何将 RAG 真正嵌入一个具体的业务流程，而不是停在 Demo 阶段。
它回答了一个很多人关心的问题：RAG 怎么从"问答机器人"变成"业务辅助工具"？答案是：不要只做相似度排序，要做字段级证据判断；不要只给一个通过/不通过，要保留人工复核入口；不要只追求准确率，要设计保守策略防止误判。
这些取舍，在学术论文里可能只是一两句话，但在实际工程项目中，每一个决策都需要对应的代码实现和界面支持。资质通把这些都做了。
从增长曲线看，开源不到一年（2025 年中发布），已获得 100 stars，对于一个非常垂直的场景来说，这个数字说明确实击中了真实需求。
| 场景 | 推荐方式 |
|---|---|
| Windows 个人开发者 | 克隆 + 虚拟环境 + start.bat，最快上手 |
| Linux 云服务器 | Docker Compose 一键部署，用 nginx 反向代理 |
| 想研究源码 | 看 backend/app/services/match_service.py 和 rag_service.py |
| 想自定义规则 | 修改 backend/app/services/rule_library_service.py |
如果你在政企文档处理、招投标、合同审查等领域工作，这个项目的架构设计和业务逻辑值得仔细研究。如果你在做 RAG 应用的选型参考，它也是一个很好的"业务型 RAG"反面教材——告诉你什么样的设计决策才是工程上合理的。