1 说明
1.1 工作说明
01.常见信息
a.分类1
XXXXXX
b.分类2
XXXXXX
02.常见信息
a.分类1
XXXXXX
b.分类2
XXXXXX
03.账号信息
a.Gogs
XXXXXX
b.Gitlab
XXXXXX
1.2 排查信息
00.程序位置
a.查看pid、查看程序目录
ps -ef | grep java --查看进程
------------------------------------------------------------------------
lsof -i:9981 --命令1：查找9981对应pid
ps -ef | grep java | grep 1723891 --命令2：查找pid对应java
tail -f jeecgboot-2025-02-06.0.log --命令3：查看日志
------------------------------------------------------------------------
ps -ef | grep $(lsof -ti:9981) --组合命令
ps -ef | grep $(lsof -ti:9981) | grep java --组合命令
kill -9 [pid]
b.curl测试
curl --location 'http://172.17.10.201:9981/jeecg-boot/mo/isp/getIndicator' \
--header 'Content-Type: application/json' \
--data '{
"indicatorDate": 202501
}'
c.前端日志
tail -f /var/log/nginx/access.log --访问日志
tail -f /var/log/nginx/error.log --错误日志
d.后端日志
cd /root/myprojects/logs/ --每天日志
tail -f jeecgboot-2025-02-06.0.log --实时日志ONObject dataParam = new JSONObject();
dataPa
e.停止、启动
ps -ef | grep java --查看进程
kill [pid] --优雅停机
------------------------------------------------------------------------
sh /root/hr-project/backend-start.sh start --启动
tail -f /root/hr-project/hr-backend/jeecg-module-system/jeecg-system-start/logs/jeecgboot-2025-03-02.0.log --日志
01.查看系统
a.使用uname -a命令
uname -a --显示系统内核版本
b.查看发行版特定的版本文件:
cat /etc/redhat-release --适用于RedHat/CentOS系统
cat /etc/debian_version --适用于Debian系统
cat /etc/ubuntu-release --适用于Ubuntu系统
c.使用hostnamectl命令
hostnamectl --查看主机名和其他信息（适用于systemd系统）
d.查看性能1
lscpu --查看 CPU 信息
cat /proc/cpuinfo --查看详细的 CPU 信息
free -h --查看内存信息
cat /proc/meminfo --查看详细的内存信息
------------------------------------------------------------------------
df -h --查看磁盘使用情况
top --查看系统负载和性能
vmstat --查看系统的虚拟内存、进程、CPU 活动等信息
------------------------------------------------------------------------
dmesg | grep -i vmware --查看是否vmware虚拟化机器
lscpu | grep -i hypervisor --查看是否vmware虚拟化机器
e.查看性能2
echo "=== CPU 信息 ==="
lscpu | grep -E '^CPU\(s\):|^Model name:|^Socket\(s\):|^Thread\(s\) per core:|^Core\(s\) per socket:'
echo -e "\n=== 内存信息 ==="
free -h
echo -e "\n=== 磁盘信息 ==="
df -h --total | grep 'total'
echo -e "\n=== 显卡信息 ==="
lspci | grep -i --color 'vga\|3d\|2d'
02.查看ip端口
a.netstat命令
yum install net-tools --安装 net-tools
netstat -tunlp | grep 9981 --查看具体某个端
b.ss命令
ss -tunlp | grep 9981 --查看具体某个端
c.lsof命令
yum install lsof --安装 lsof
lsof -i --查看所有网络连接
lsof -i:9981
d.firewall-cmd命令
firewall-cmd --list-ports --查看所有开放的端口
firewall-cmd --query-port=9981/tcp --查询某个端口是否开放
03.防火墙
a.systemctl
systemctl stop firewalld --关闭防火墙
systemctl disable firewalld --禁止开机自启
systemctl status firewalld --防火墙状态
systemctl start firewalld --开启防火墙
systemctl enable firewalld --开启开机自启
b.firewall-cmd
firewall-cmd --reload --重启防火墙
firewall-cmd --zone=public --add-port=3306/tcp --permanent --开放3306端口
firewall-cmd --zone=public --remove-port=3306/tcp --permanent --关闭3306端口
firewall-cmd --zone=public --list-ports --查看开放端口
firewall-cmd --zone=public --query-port=3306/tcp --查看具体端口
firewall-cmd --state --查看防火墙状态
04.nginx
a.查看nginx配置文件
cd /etc/nginx/
ls
cat nginx.conf
b.查看conf.d目录下的配置
cd /etc/nginx/conf.d/
ls
cat *.conf
c.查看sites-enabled目录(如果存在)
cd /etc/nginx/sites-enabled/
ls
d.检查nginx配置是否正确
nginx -t
e.查看nginx进程
ps -ef | grep nginx
f.访问日志
tail -f /var/log/nginx/access.log
g.错误日志
tail -f /var/log/nginx/error.log
05.自定义DNS
a.编辑hosts文件
vi /etc/hosts
# 添加格式如下：
# IP地址 域名
192.168.1.100 example.com
192.168.1.101 test.com
b.修改DNS服务器
vi /etc/resolv.conf
# 添加或修改nameserver
nameserver 8.8.8.8
nameserver 114.114.114.114
d.刷新DNS缓存
systemctl restart NetworkManager
# 或
nscd -i hosts # 如果安装了nscd
e.测试DNS解析
nslookup example.com
ping example.com
f.查看DNS是否生效
# 查看当前DNS服务器
cat /etc/resolv.conf
# 测试DNS解析
dig @8.8.8.8 example.com
06.系统编码1
a.linux
[root@localhost hr-backend]# stat /etc/locale.conf
File: /etc/locale.conf
Size: 19 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 67431224 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2025-03-08 10:50:06.920797929 +0800
Modify: 2022-01-11 10:28:26.559915054 +0800
Change: 2022-01-11 10:28:26.559915054 +0800
Birth: 2022-01-11 10:28:26.558915052 +0800
-----------------------------------------------------------------------------------------------------
通常情况下，Java会使用操作系统的默认字符编码
Access 字段表示文件的最后访问时间，这是指文件内容最后一次被读取的时间，而不是文件被修改或更改的时间
b.查看编码
$ locale
$ cat /etc/locale.conf
-----------------------------------------------------------------------------------------------------
LANG=C.UTF-8 不提供特定语言的特性；用默认的、简单的格式 公司服务器，默认编码
LANG=en_US.UTF-8 美国英语的语言特性；美国的习惯格式化日期、时间、货币 腾讯云服务器，默认编码
c.查看系统安装的字符编码
$ locale -a
-----------------------------------------------------------------------------------------------------
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.utf8
POSIX
zh_CN
zh_CN.gb18030
zh_CN.gbk
zh_CN.utf8
zh_HK
zh_HK.utf8
zh_SG
zh_SG.gbk
zh_SG.utf8
zh_TW
zh_TW.euctw
zh_TW.utf8
d.生成编码
# 打开 /etc/locale.gen 文件
vi /etc/locale.gen
# 确保文件中包含以下行（如果没有，请添加）
C.UTF-8 UTF-8
# 生成语言环境
sudo locale-gen
# 设置默认语言环境
sudo update-locale LANG=C.UTF-8
e.修改编码
# 临时更改
export LANG=C.UTF-8
# 永久更改
vi /etc/locale.conf
LANG=C.UTF-8
# 更新当前会话
source /etc/locale.conf
07.系统编码2
a.如果要设置中文版的字体编，在每个文件中增加以下内容
# cat /etc/profile.d/locale.sh
# vim /etc/profile.d/locale.sh
export LC_CTYPE=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8
# cat /etc/locale.conf
# vim /etc/locale.conf
LANG=zh_CN.UTF-8
# cat /etc/sysconfig/i18n
# vim /etc/sysconfig/i18n
LANG=zh_CN.UTF-8
# cat /etc/environment
# vim /etc/environment
LANG=zh_CN.UTF-8
LC_ALL=zh_CN.UTF-8
# source /etc/profile.d/locale.sh
# source /etc/locale.conf
# source /etc/sysconfig/i18n
# source /etc/environment
b.如果要设置英文版的字体编码。在每个文件中增加以下内容
# cat /etc/profile.d/locale.sh
# vim /etc/profile.d/locale.sh
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
# cat /etc/locale.conf
# vim /etc/locale.conf
LANG=en_US.UTF-8
# cat /etc/sysconfig/i18n
# vim /etc/sysconfig/i18n
LANG=en_US.UTF-8
# cat /etc/environment
# vim /etc/environment
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
# source /etc/profile.d/locale.sh
# source /etc/locale.conf
# source /etc/sysconfig/i18n
# source /etc/environment
c.临时更改
export LANG=C.UTF-8
export LANG=zh_CN.utf8
1.3 服务信息
01.服务器
a.分类1
网址：
账号：
密码：
-----------------------------------------------------------------------------------------------------
路径：
分支：
-----------------------------------------------------------------------------------------------------
打开；code . 或者 Alt + P
编码：export LANG=zh_CN.utf8
启动：nohup env LANG=zh_CN.utf8 java -jar -Dfile.encoding=zh_CN.utf8 $JAR_HOME > $LOG_PATH 2>&1 &
-----------------------------------------------------------------------------------------------------
# ps -ef | grep java
b.分类2
网址：
账号：
密码：
-----------------------------------------------------------------------------------------------------
SSH：
路径：
编码：export LANG=zh_CN.utf8
c.分类3
网址：
账号：
密码：
-----------------------------------------------------------------------------------------------------
SSH：
路径：
编码：export LANG=zh_CN.utf8
02.数据库
a.分类1
网址：
账号：
密码：
b.分类2
网址：
账号：
密码：
c.分类3
网址：
账号：
密码：
03.服务器说明
a.查看系统
a.参数
Static hostname: localhost.localdomain
Icon name: computer-vm
Chassis: vm
Machine ID: 92305feebc6240b381280ce8ff6aa3e3
Boot ID: 251b94bf7be545dcb731ff19014b83ad
Virtualization: vmware
Operating System: Rocky Linux 8.5 (Green Obsidian)
CPE OS Name: cpe:/o:rocky:rocky:8:GA
Kernel: Linux 4.18.0-348.7.1.el8_5.x86_64
Architecture: x86-64
b.说明
操作系统：Rocky Linux 8.5 (Green Obsidian)
内核版本：Linux 4.18.0-348.7.1.el8_5.x86_64
架构：x86-64
虚拟化：VMware
b.查看情况
a.查看jar包
$ ps -ef
$ ps -ef | grep java
b.查看redis目录
[root@localhost logs]# ps -ef | grep redis
redis 3850 1 0 1月12 ? 00:33:22 /usr/bin/redis-server 127.0.0.1:6379
root 1731531 1730430 0 11:08 pts/0 00:00:00 grep --color=auto redis
c.nginx
a.位置
[root@localhost hr-backend]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
b.日志
tail -f /var/log/nginx/access.log --访问日志
tail -f /var/log/nginx/error.log --错误日志
2 生产系统
2.1 项目设计
01.常用信息1
a.全景图
┌─────────────────────────────────────────────────────────────────────┐
│ 数字化工厂系统架构 │
├─────────────────────────────────────────────────────────────────────┤
│ 研发设计层 │ 管理层 │ 执行层 │ 设备层 │
├─────────────────────────────────────────────────────────────────────┤
│ PLM │ ERP │ MES │ SCADA / DCS │
│ CAD/CAM │ CRM │ WMS │ WCS │
│ CAE │ SCM │ QMS │ 传感器/PLC │
│ │ SRM │ APS │ │
│ │ OMS │ EAM │ │
│ │ TMS │ EMS │ │
│ │ BI/BPM │ │ │
│ │ HR │ │ │
└─────────────────────────────────────────────────────────────────────┘
b.按领域分类
领域 系统 说明
生产排程 APS 高级计划与排程，智能优化生产计划
设备监控 SCADA/DCS 设备数据采集、远程监控、自动化控制
质量管理 QMS 质检流程、不良品分析、质量追溯
研发设计 PLM 产品生命周期管理、图纸、BOM、工艺
供应链 SCM/SRM 供应链协同、供应商管理、采购
物流运输 TMS/WCS 运输调度、仓储设备控制
订单管理 OMS 订单处理、跟踪、库存分配
客户关系 CRM 客户信息、销售、售后
资产管理 EAM 设备维护、备件、设备全生命周期
能源管理 EMS 能耗监控、节能优化
数据分析 BI 报表、分析、决策支持
流程管理 BPM 业务流程建模、优化
人力资源 HR 人事、考勤、薪酬
c.核心系统关系
PLM (研发设计)
↓
ERP (经营管理)
↓
┌──────────┼──────────┐
↓ ↓ ↓
APS SCM MES
(排程) (供应链) (制造执行)
↓
┌───────────┼───────────┐
↓ ↓ ↓
WMS QMS SCADA
(仓库) (质量) (设备)
↓ ↓ ↓
WCS 检验设备 PLC/传感器
02.常用信息2
a.生产管理系统
生产管理系统是用于管理和控制企业生产活动的信息系统
b.核心功能
模块 功能说明
生产计划 生产排程、工单管理、产能规划
物料管理 BOM管理、物料需求计算、库存关联
生产执行 工序管理、进度跟踪、派工发料
质量管理 质检记录、不良品处理、追溯分析
设备管理 设备台账、维护保养、故障记录
成本管理 工时统计、成本核算、效率分析
c.与相关系统的关系
┌─────────────────────────────────────────────────┐
│ ERP层 │
│ (财务、采购、销售、人力资源) │
└─────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ 生产管理系统 │
│ (计划、调度、成本、报表等管理层功能) │
└─────────────────────────────────────────────────┘
↓
┌─────────────────┬───────────────┬─────────────────┐
│ MES │ WMS │ 其他系统 │
│ (车间现场执行) │ (仓库作业) │ (设备、能耗等) │
└─────────────────┴───────────────┴─────────────────┘
d.与ERP其他模块的关系
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 销售管理 │──────│ 生产管理 │──────│ 仓库管理 │
└─────────────┘ │ 系统 │ └─────────────┘
└──────┬──────┘
┌─────────────┐ │
│ 项目管理 │─────────────┤
└─────────────┘ │
┌─────────────┐ │
│ 采购管理 │─────────────┘
└─────────────┘
│
┌─────────────┐ │ ┌─────────────┐
│ 财务管理 │──────┴──────│ 设备管理 │
└─────────────┘ └─────────────┘
03.常用信息3
a.预警提醒
略
b.任务管理
我的流程
待办任务
已办任务
c.财务管理
差旅费报销单
生产成本表
经费支出报销
付款单
开票申请
库存月结
d.销售管理
项目备案
客户资料
销售合同
合同收款单
合同开票申请
合同成交价表
技术交接表
e.项目管理
人员分配
工程安装合同
安装合同收款
安装合同开票
项目派工单
现场作业管理
项目进度表
工地设备材料
项目结算
f.采购管理
标准外购单：机电外购、办公采购、备货申请
采购申请：机电采购、办公采购、备货外购
长度采购订单
重量采购订单
采购合同收款
采购合同开票
采购到货检验
采购入库申请
采购入库流水
修改采购申请
g.工艺生产
物料明细表
投产外购：带图外购、外协加工
plm数据
车间台账：加工装配件
发运明细
生成发货单
成品发货单
h.仓库管理
入库检验单
入库单
出库单
待入库明细
采购入库单
生产入库单
领料出库单
备货单
库存查询
仓库入库流水
出库明细
调拨单
盘点单
i.设计管理
设计任务书
j.统计查询
库存查询
采购入库流水
出库流水
库存月报表
材料出库明细表
材料出库汇总表
采购入库明细表
采购入库汇总表
产品入库明细表
产品入库汇总表
存货库存明细账
销售出库明细表
销售出库汇总表
商品收发明细表
商品收发存汇总表
商品库存业务汇总表
收发存汇总查询
库龄分析
k.基本资料
物料分类
物料代码
供应商资料
供应商评审
城市编码
收款类型
产品结构表
l.系统管理
用户管理
角色管理
机构部门
岗位管理
通知公告
日志管理：操作日志、登录日志
人事资料
2.2 项目参考
01.AI搜索
a.生产管理系统/MES
a.smart-mes（最推荐）
Gitee: https://gitee.com/fzm-g/smart-mes.git
技术栈: Vue + SpringBoot + UniApp
特点: 基于若依框架，有移动端，Gitee排名第一
b.hm-MES
GitHub: https://github.com/dreamer888/hm-MES
Gitee镜像: https://gitee.com/imcoder/hm-MES
技术栈: SpringBoot + Layui
特点: 功能丰富，看板精美，支持PLC
c.LiteMES
GitHub: https://github.com/freeleepm/LiteMES
技术栈: SpringBoot
特点: 轻量级，支持IoT设备
d.Joues/erp
GitHub: https://github.com/Joues/erp
技术栈: Vue + SpringBoot
特点: 物料+生产管理
e.yjh-mes-uniapp
Gitee: https://gitee.com/aroha_hu/yjh-mes-uniapp
技术栈: UniApp
特点: 纯移动端方案
f.ktg-mes（苦糖果MES）
Gitee: https://gitee.com/ai-toys/ktg-mes
技术栈: Java
特点: B/S结构，开源免费
b.ERP系统
a.JSH_ERP（管伊佳ERP/华夏ERP）
GitHub: https://github.com/jishenghua/jshERP
技术栈: Vue + SpringBoot
特点: SaaS ERP，功能全面
b.玖玖云ERP
Gitee: https://gitee.com/digitdance/jjjerp-java
技术栈: Vue + SpringBoot + UniApp
特点: 电商ERP，含WMS
c.Finer 进销存
Gitee: https://gitee.com/FINERME/psi
技术栈: Vue2 + SpringBoot (基于JeecgBoot)
特点: 面向中小企业
c.仓库管理
a.javaobjects/wms
GitHub: https://github.com/javaobjects/wms
技术栈: Vue + SpringBoot
特点: 专注仓库管理
d.基础框架
a.RuoYi-Vue3
GitHub: https://github.com/yangzongzhuan/RuoYi-Vue3
技术栈: SpringBoot + Vue3
b.RuoYi-Vue-Pro
GitHub: https://github.com/YunaiV/ruoyi-vue-pro
技术栈: SpringBoot + Vue3
特点: 官方推荐，支持多租户、工作流
c.若依框架
Gitee: https://gitee.com/y_project/RuoYi
技术栈: SpringBoot + Vue
02.若依生态
a.生产管理系统/MES
a.ktg-mes（苦糖果MES）
Gitee: https://gitee.com/ai-toys/ktg-mes
技术栈: Java
特点: B/S结构，开源免费
b.wj-mes（RuoYi-WJ-ONE）
Gitee: https://gitee.com/vulcanw/wj-mes
特点: 整合MES、CRM、Flowable等系统于一体
c.tms（大宗物流运输系统）
Gitee: https://gitee.com/wzy0424/tms
特点: 基于若依的大宗物流运输系统
b.WMS仓库管理系统
a.deer-wms
Gitee: https://gitee.com/deerwms/deer-wms-2
特点: 自动化立体仓库原料库系统
b.wms-ruoyi
Gitee: https://gitee.com/zccbbg/wms-ruoyi
特点: 基于若依的仓库管理系统
c.ERP/进销存管理系统
a.hxERP
Gitee: https://gitee.com/tanzhi/hxERP
技术栈: SpringBoot + Vue
特点: 基于若依进销存管理系统
b.ruoyi-erp
GitHub: https://github.com/Quart233/ruoyi-erp
技术栈: SpringBoot + Vue
特点: 基于若依的ERP系统
c.ks-inventory-system
Gitee: https://gitee.com/KrityCat/ks-inventory-system
技术栈: SpringBoot + Vue
特点: 基于若依进销库存系统
d.OA办公系统
a.ruoyi-vue-oa
Gitee: https://gitee.com/OpenJJ/ruoyi-vue-oa
特点: 开箱即用，页面美观实用
b.zy-oa
Gitee: https://gitee.com/sjz_zy/zy-oa
特点: 整合flowable实现工作流
c.officeProcess
Gitee: https://gitee.com/lu_qw/officeProcess
特点: 企业费控管理系统，整合flowable
d.RuoYi-Vue-flowable
Gitee: https://gitee.com/tangwenzhaoaini/RuoYi-Vue-flowable
特点: 集成flowable的工作流管理平台
e.AntFlow-Vue3
Gitee: https://gitee.com/ldhnet/AntFlow-Vue3
特点: 集成Activiti、仿钉钉流程审批
f.Cauliflower-activiti
Gitee: https://gitee.com/huacaicaicai/Cauliflower-activiti
特点: 集成Activiti7工作流、VxeTable、网盘
g.flyflow
Gitee: https://gitee.com/junyue/flyflow/tree/springboot3-ruoyi
特点: 集成flowable类钉钉飞书工作流
h.boot-java
Gitee: https://gitee.com/a-crud-boy/boot-java
特点: 集成flowlong工作流、SaToken、mybatisplus-plus
e.电商平台/商城系统
a.RuoYi-Mall
Gitee: https://gitee.com/zccbbg/RuoYi-Mall
特点: 电商管理系统
b.payshop
Gitee: https://gitee.com/JiaGou-XiaoGe/payshop
特点: 多商户商城管理系统
c.ruoyi-shop
Gitee: https://gitee.com/hgl168918/ruoyi-shop
特点: 与litemall融合的商城后台
d.sun-cms-video
Gitee: https://gitee.com/sun-gongzhu/sun-cms-video
特点: 电影视频网站
e.ruoyi-media
Gitee: https://gitee.com/tanhuihuang/ruoyi-media
特点: 电影视频系统
f.物流运输/TMS
a.tms
Gitee: https://gitee.com/wzy0424/tms
特点: 基于若依的大宗物流运输系统
b.transport
Gitee: https://gitee.com/hongmaple/transport
特点: 基于若依的物流转运小程序
g.智慧物业/社区
a.zhaoxinpms
Gitee: https://gitee.com/fanhuibin1/zhaoxinpms
特点: 基于若依的智慧物业系统
b.community-web
Gitee: https://gitee.com/hebei-zhiyu-network/community-web
特点: 基于若依的智慧社区系统
c.ykt
Gitee: https://gitee.com/huohuzhihui/ykt
特点: 基于若依的智慧园区一卡通
h.CRM客户关系管理
a.RuoyiCRM
Gitee: https://gitee.com/jundee/RuoyiCRM
特点: 基于若依的多租户CRM系统
b.link-wechat
Gitee: https://gitee.com/LinkWeChat/link-wechat
特点: 人工智能的企业微信SCRM
i.IoT物联网平台
a.Shenbao-iot
Gitee: https://gitee.com/jinanchang/Shenbao-iot
特点: 开源物联网基础平台
b.openlinks
Gitee: https://gitee.com/open-links-group/openlinks
特点: 开源物联网基础平台
c.thinglinks-community
Gitee: https://gitee.com/chinachentao/thinglinks-community
特点: 开源物联网基础平台
d.EmqxExpand
Gitee: https://gitee.com/zangsheng/EmqxExpand
特点: 集成emqx鉴权与登录
e.frog-smart-agriculture
Gitee: https://gitee.com/nealtsiao/frog-smart-agriculture
特点: 智慧农业物联网平台
f.wumei-smart
Gitee: https://gitee.com/kerwincui/wumei-smart
特点: 智能家居系统
g.kwswitch
Gitee: https://gitee.com/kerwincui/kwswitch
特点: 智能开关平台
j.校园/教育系统
a.HtxkEmsm
GitHub: https://github.com/hongmaple/HtxkEmsm
特点: 高校教学综合平台
b.hp-jx
Gitee: https://gitee.com/xiaoyuer0/hp-jx
特点: 教学教务管理系统
c.DormSystem
GitHub: https://github.com/Russ0417/DormSystem
特点: 宿舍管理系统
d.campus
GitHub: https://github.com/oddfar/campus
特点: 校园信息墙项目
e.octopus
GitHub: https://github.com/hongmaple/octopus
特点: 高校教学综合平台
f.student
GitHub: https://github.com/Beisheng8888/student
特点: 智慧校园系统
g.examination-system
GitHub: https://github.com/qnsdt/examination-system
特点: 开源考试管理系统
h.student-attendance-management
GitHub: https://github.com/yeshuang2/student-attendance-management
特点: 学生考勤管理系统
i.student-attendence-management-system
Gitee: https://gitee.com/han-cheese/student-attendence-management-system
特点: 学生考勤管理系统
j.Tutor
GitHub: https://github.com/zty-f/Tutor
特点: 家教一体化平台
k.移动端/小程序
a.RuoYi-Mobile
Gitee: https://gitee.com/yinm/RuoYi-Mobile
技术栈: UniApp
特点: 集成uView2.0+u-charts等组件
b.ruoyi-uniapp
Gitee: https://gitee.com/big-hedgehog/ruoyi-uniapp
技术栈: UniApp
特点: 移动端Uniapp版本
c.ruoyi_flutter_app
GitHub: https://github.com/420136525/ruoyi_flutter_app
技术栈: Flutter
特点: 移动端Flutter版本
d.ruoyi-uniapp（另一版本）
Gitee: https://gitee.com/_q494000616q_/ruoyi-uniapp
技术栈: UniApp
特点: 包括权限认证、字典翻译等
e.AbuCoder-RuoYi-Vue-uniapp-wx
Gitee: https://gitee.com/rahman/AbuCoder-RuoYi-Vue-uniapp-wx
技术栈: 微信小程序
特点: 基于若依后台的微信小程序
f.transport
Gitee: https://gitee.com/hongmaple/transport
技术栈: UniApp
特点: 物流转运小程序
l.其他工具系统
a.assets
Gitee: https://gitee.com/51tech/assets
特点: 资产和设备管理系统
b.smart-pay-plus-vue
Gitee: https://gitee.com/zhunian/smart-pay-plus-vue
特点: 支付系统
c.ewem
Gitee: https://gitee.com/qrcode_project/ewem
特点: 溯源防伪系统
d.ruo-yi-vue-kms-backup
Gitee: https://gitee.com/chenzuheng001/ruo-yi-vue-kms-backup
特点: 知识管理系统
e.ruo-yi-vue-blog
Gitee: https://gitee.com/Ning310975876/ruo-yi-vue-blog
特点: 博客网站
f.RuoYi-Vue-CMS
Gitee: https://gitee.com/liweiyi/RuoYi-Vue-CMS
特点: CMS内容管理系统
g.netdisk
Gitee: https://gitee.com/hongmaple/netdisk
特点: 在线网盘系统
h.forum
Gitee: https://gitee.com/e-wenxin/forum
特点: 简单的易扩展的论坛平台
i.knowledgegraph
Gitee: https://gitee.com/liaoquefei/knowledgegraph
特点: 可视化知识图谱
j.RuoYi-Wvp
Gitee: https://gitee.com/xiaochemgzi/RuoYi-Wvp
特点: 流媒体平台
k.electronic-signature-system
Gitee: https://gitee.com/tangwenzhaoaini/electronic-signature-system
特点: 电子签章系统
2.3 信创环境
00.汇总
a.底层
龙芯/鲲鹏芯片 + 昆仑BIOS
b.系统
统信UOS/麒麟操作系统
c.支撑
东方通中间件 + 达梦数据库
d.安全
奇安信杀毒 + 天融信防火墙
e.应用
用友ERP + 金山WPS + 你的业务代码
01.常见信息1
a.基础硬件层
a.概述
这是地基，决定了整个生态的指令集架构（主要是x86、ARM、LoongArch等）。
b.CPU (芯片)
a.ARM路线
华为鲲鹏、飞腾。
b.x86路线
海光、兆芯。
c.LoongArch (自研指令集)
龙芯。
d.RISC-V
平头哥等新兴力量。
c.GPU (显卡/AI算力)
目前比较薄弱但急需的环节，如景微、海光（DCU）、摩尔线程等。
d.固件 (BIOS/BMC)
a.作用
这是开机启动的第一道程序。
b.代表厂商
昆仑。
e.整机/外设
a.服务器
浪潮、中科曙光、联想、中兴。
b.PC终端
长城、同方。
c.打印机/扫描仪
奔图等。
b.基础软件层
a.概述
这是你目前关注的重点，但除了数据库，还有以下内容。
b.操作系统 (OS)
a.麒麟软件
中标麒麟、银河麒麟（市场占有率很高）。
b.统信 (UOS)
界面友好度较高，社区活跃。
c.开放麒麟
桌面端开源社区。
d.华为欧拉
主要面向服务器领域，是服务器OS的“母体”。
c.数据库
如前所述：达梦、人大金仓、openGauss、TiDB、OceanBase等。
d.中间件
a.定位
这是连接应用和数据库的“胶水”。在Java生态中尤为重要。
b.代表厂商
东方通、宝兰德、中创。
c.作用
应用服务器、消息队列、交易中间件。
c.云与虚拟化层
a.虚拟化软件
提供虚拟机能力。代表：华为FusionSphere、云宏。
b.云桌面 (VDI/IDV)
信创终端常用的“云电脑”方案，方便统一管理。代表：深信服、锐捷、华为。
c.超融合基础设施 (HCI)
软件+硬件打包的一体机方案。
02.常用信息2
a.应用软件层 (SaaS)
a.概述
这是用户直接接触的层面。
b.通用办公软件
a.办公套件
金山WPS (绝对主力)、永中Office。
b.即时通讯
腾讯（企业微信/政务版）、华为（WeLink）、字节（飞书）。
c.电子邮件
Coremail（盈世）、万户。
c.业务应用 (ERP/OA)
a.OA系统
致远互联、蓝凌、通达信科。
b.ERP/财务软件
用友、金蝶、浪潮。
d.行业特定软件
例如：医疗的HIS系统、电网的控制软件、CAD/EDA工业软件（这也是目前卡脖子最严重的领域）。
b.信息安全层
a.概述
信创的核心驱动力之一就是安全，所以安全生态是独立且贯穿全栈的。
b.身份认证/CA
数字认证、吉大正元。
c.网络安全 (防火墙/IDS)
天融信、启明星辰、深信服、奇安信。
d.数据安全 (加密/脱敏)
安恒信息。
e.杀毒/终端安全
360、火绒（国产化版本）、亚信安全。
c.外设与驱动生态
a.概述
这是一个非常实际的问题。如果打印机连不上，电脑也是摆设。
b.适配名录
信创厂商（如统信、麒麟）会发布软硬件适配互认证书。目前市面上主流的打印机（惠普、佳能、奔图）、扫描仪、高拍仪都在逐步完善驱动支持。
3 快速代码
3.1 [1]市场调研
01.产品分析
a.分类1
http://ai.58yskj.com/ 约瑟AI
https://www.codeflying.net/ 码上飞
https://www.feisuanyz.com/ 飞算JavaAI
b.分类2
https://www.langflow.org/
https://www.langchain.com/langgraph
https://github.com/langchain4j/langchain4j
https://github.com/langchain-ai/langchain-mcp-adapters
-----------------------------------------------------------------------------------------------------
LangChain是代理人工智能生态系统中最成熟的框架之一。
LangGraph扩展了其功能，以支持LangChain博客 中所述的复杂、有状态的代理工作流程。
c.LangChain
组件生态系统 — 庞大的预建组件库，用于各种自主代理功能，可实现专业代理的快速开发。有关更多信息，请参阅 LangChain 文档。
基础模型选择 — 支持各种基础模型，包括 Anthropic Claude、亚马逊 Bedrock 上的 Amazon Nova 模型（Premier、Pro、Lite 和 Micro），以及其他用于不同推理能力的模型。有关更多信息，请参阅LangChain文档中的输入和输出。
LLM API 集成 — 适用于多个大型语言模型 (LLM) 服务提供商（包括 Amazon Bedrock）和其他提供商的标准化接口OpenAI，以实现灵活部署。有关更多信息，请参阅 LangChain文档中的 LLMs。
多模态处理 — 内置文本、图像和音频处理支持，可实现丰富的多模态自主代理交互。有关更多信息，请参阅文档中的多模态。LangChain
基于图形的工作流程 — LangGraph 支持将复杂的自主代理行为定义为状态机，支持复杂的决策逻辑。有关更多信息，请参阅LangGraph平台正式发布公告。
内存抽象 — 短期和长期内存管理的多个选项，这对于随着时间的推移维护上下文的自主代理来说是必不可少的。有关更多信息，请参阅LangChain文档中的如何为聊天机器人添加内存。
工具集成 — 丰富的工具集成生态系统，可跨各种服务 APIs，扩展自主代理功能。有关更多信息，请参阅LangChain文档中的工具。
LangGraph 平台 — 适用于生产环境的托管部署和监控解决方案，支持长期运行的自主代理。有关更多信息，请参阅LangGraph平台正式发布公告。
02.竞品分析
a.原版 AipexBase（码上飞），项目地址：https://gitee.com/kuafuai/aipexbase
a.核心设计理念
AipexBase 是 AI 时代的 Backend-as-a-Service（BaaS）基础设施，核心理念：
a."前端即后端"：开发者无需关注后端实现细节
b.AI 原生设计：模型可直接调用后端函数
c.原生 MCP 兼容：统一的上下文和数据层
d.快速全栈开发：通过 AI 编码工具（Cursor、Trae）实现快速开发
b.技术架构
技术栈：
├── 后端：Java Spring Boot 2.x + MyBatis Plus
├── 前端：Vue 3 + Element Plus
├── 数据库：MySQL 8.0 + Redis
└── 部署：Docker + Docker Compose
核心模块：
├── 用户认证系统
├── 权限管理
├── 数据库自动管理
├── API 自动生成
└── 文件存储服务
c.生态支持
钉钉、微信、飞书原生支持
鸿蒙应用、小程序、WebView
多设备多前端
d.优势分析
维度 评价
企业级稳定性 ⭐⭐⭐⭐⭐ Java 生态成熟
功能完整度 ⭐⭐⭐⭐⭐ BaaS 能力完善
国内生态集成 ⭐⭐⭐⭐⭐ 钉钉/微信/飞书深度集成
开发速度 ⭐⭐⭐ 传统 Java 开发
AI 集成深度 ⭐⭐⭐ 支持但不是核心优势
e.不足之处
技术栈相对传统：Java + Vue 对新一代开发者吸引力较弱
AI 能力不突出：虽然支持 AI 调用，但未深度优化
成本管理缺失：未提供 AI 调用成本优化方案
b.New-API，项目地址：https://github.com/QuantumNous/new-api
a.定位
AI 模型聚合管理中转分发系统，支持将多种大模型转为统一格式调用。
b.核心功能
多提供商支持：OpenAI、Claude、Gemini、DeepSeek、GLM、Kimi、豆包等 30+ 模型
统一接口：OpenAI 兼容 API，只需修改 baseURL 即可切换
负载均衡：多 API Key 自动轮换和负载均衡
使用统计：Token 使用统计、成本分析、请求日志
商业化功能：用户管理、在线支付、套餐管理
c.支持的 Coding Plan：
提供商 模型标识 特点 额度
智谱 GLM glm-coding-plan 完全免费，128K 上下文 新用户 2 并发（可申请提升）
Kimi kimi-coding-plan 低价计划 按量计费
字节豆包 doubao-coding-plan 低价计划 按量计费
d.配置方式（参考：https://www.newapi.ai/zh/docs/guide/console/channel-management）：
渠道配置：
名称: GLM-Coding-1
类型: 智谱AI
模型: glm-coding-plan
密钥: your-api-key-1
权重: 1
名称: GLM-Coding-2
类型: 智谱AI
模型: glm-coding-plan
密钥: your-api-key-2
权重: 1
e.成本优势：
a.GLM-4-Flash 免费：完全免费使用，性能接近 GPT-3.5
b.多账号轮换：通过 New-API 自动轮换多个账号，实现近乎无限调用
c.成本降低 90%+：相比直接调用 GPT-4，成本降低超过 90%
c.ccNexus，项目地址：https://github.com/lich0821/ccNexus
a.定位
Claude Code 专用的智能 API 网关，提供端点轮换、使用监控和格式转换。
b.核心功能
多端点管理：配置多个 API 端点，自动故障转移
API 格式转换：Claude ⇄ OpenAI ⇄ Gemini 格式互转
使用统计：实时监控请求、错误和 token 使用情况
数据安全：所有数据本地存储在 ~/.ccNexus/ 目录
多主题支持：12 种主题（Light、Dark、Cyberpunk 等）
c.技术特点
语言：Go
GUI框架：Wails v2（跨平台桌面应用）
平台支持：Windows 10+, macOS 10.15+, Linux (GTK3)
d.核心优势
智能路由：自动选择可用端点
故障转移：端点失败自动切换备用端点
透明代理：对应用层完全透明，无需修改代码
本地优先：数据本地存储，API Key 不会发送到第三方
e.适用场景
Claude Code 用户需要稳定的 API 访问
需要在多个 AI 提供商之间无缝切换
需要监控 AI 调用使用情况
f.定位差异
ccNexus 是客户端工具，主要服务于 Claude Code，而非通用的应用开发平台。
03.相关分析
a.技术趋势
a.AI 集成方式演进
第一代：直接调用 API
└─ 问题：提供商锁定、成本高、不稳定
第二代：API Gateway（New-API、Portkey）
└─ 改进：统一接口、负载均衡、成本优化
第三代：AI 原生平台（AipexBase）⭐ 当前趋势
└─ 特点：深度集成、Tool Calling、BaaS 能力
b.MCP 协议的兴起
Model Context Protocol (MCP) 是 Anthropic（Claude）推出的开放标准：
a.类比：像"AI 的 USB-C"，标准化 AI 与外部系统的连接
b.能力：文件系统、数据库、API、工具调用
c.趋势：正在成为 AI 集成的事实标准
c.多前端开发趋势
传统模式：
Web 应用 → 独立代码库
小程序 → 独立代码库
APP → 独立代码库
-------------------------------------------------------------------------------------------------
现代模式（Monorepo）：
共享代码库
├── Web (Next.js)
├── 小程序 (Taro)
└── APP (React Native)
-------------------------------------------------------------------------------------------------
优势：
a.代码复用率 60%+
b.统一业务逻辑
c.快速多端部署
d.BaaS 平台发展方向
维度 传统 BaaS AI 原生 BaaS ⭐
开发方式 手动配置 AI 对话生成
数据库 手动建表 AI 自动设计
API 手动编写 AI 自动生成
成本 按量付费 AI 优化 + 免费额度
扩展性 有限 MCP 协议无限扩展
b.Coding Plan 成本分析
a.架构
应用层
↓
ccNexus（智能路由）
↓
New-API（Coding Plan 池化）
↓
AI 提供商
b.传统成本模型
以构建一个中等规模应用为例（假设每月 100 万 tokens）：
模型 输入价格 输出价格 月成本
GPT-4 $30/1M $60/1M $45-90
Claude 3.5 Sonnet $3/1M $15/1M $9-18
GPT-3.5 $0.5/1M $1.5/1M $1-2
c.Coding Plan 成本模型
提供商 模型 月成本 性能对标
智谱 GLM glm-coding-plan $0（免费） 接近 GPT-3.5
Kimi kimi-coding-plan $0.1-1/1M GPT-3.5+
豆包 doubao-coding-plan $0.05-0.5/1M GPT-3.5
c.三个方案的市场定位
a.图示
┌─────────────────────────────────────┐
│ 统一的业务理念（AI 原生 BaaS） │
└─────────────────────────────────────┘
│
┌──────┴──────┐
│ │
相同的能力 相同的底层
│ │
├─ MCP ├─ New-API
├─ Tool Call ├─ ccNexus
├─ BaaS ├─ Coding Plan
└─ 多前端 └─ 智能路由
│ │
不同的技术栈 不同的市场定位
│ │
├─ Java ├─ 企业级
├─ Next.js ├─ 快速迭代
└─ Go └─ 高性能
b.方案1：Java 版本
a.目标市场：
中大型企业
传统行业数字化转型
对稳定性要求高的场景
b.用户画像：
技术团队熟悉 Java
有长期维护需求
需要企业级支持
c.竞争优势：
参考成熟的 AipexBase 架构
Java 生态完善，招聘容易
VM 模版机制成熟，代码生成可靠
d.适用场景：
政务系统
银行、保险等金融行业
大型企业内部平台
c.方案2：Next.js 版本
a.目标市场：
创业公司
独立开发者
快速 MVP 验证
b.用户画像：
重视开发体验
熟悉现代前端技术栈
需要快速迭代
c.竞争优势：
Vercel AI SDK 最佳集成体验
全栈 TypeScript，学习成本低
Monorepo 多端代码共享
d.适用场景：
SaaS 创业项目
内部工具快速搭建
AI 应用原型验证
d.方案3：Go 版本
a.目标市场：
高并发应用
性能敏感场景
需要极致性能的产品
b.用户画像：
有 Go 技术储备
追求性能和资源效率
需要灵活部署
c.竞争优势：
单二进制部署，运维简单
高并发性能优秀
参考 New-API/ccNexus 成熟实践
d.适用场景：
高流量 API 服务
实时数据处理
边缘计算场景
d.参考资料
a.项目链接
AipexBase：https://gitee.com/kuafuai/aipexbase
New-API：https://github.com/QuantumNous/new-api
ccNexus：https://github.com/lich0821/ccNexus
Vercel AI SDK：https://ai-sdk.dev/
Portkey Gateway：https://github.com/Portkey-AI/gateway
b.文档链接
New-API Coding Plan 配置：https://www.newapi.ai/zh/docs/guide/console/channel-management
Model Context Protocol：https://docs.claude.com/en/docs/mcp
智谱 GLM-4-Flash 免费 API：https://news.qq.com/rain/a/20240827A06GU600
c.技术博客
Vercel AI SDK 完整指南：https://www.codecademy.com/article/guide-to-vercels-ai-sdk
国产大模型对比：https://learnku.com/articles/90011
MCP 快速开始：https://www.danliden.com/posts/20250412-mcp-quickstart.html
3.2 [1]产品分析
01.飞算，JavaAI
a.概述
a.智能会话
-> 编程智能体
-> 自动调用工具执行编程任务
-> 智能问答
-> 实时技术问答支持
-> Java Chat
-> 工程分析、代码重构/优化
b.引导式生成完整项目
-> 引导式开发拆解任务
-> 需求理解→接口设计→表结构设计→业务逻辑生成
-> 生成完整工程源码
-> 逐层生成→实时预览→逐一确认
c.AI工具箱
-> 覆盖全周期的提效工具矩阵
-> SQL Chat
-> 自然语言转SQL，数据库操作提效
d.SQL
-> 深度学习用户偏好
-> 技术栈 | 分层架构 | 代码规范 | 安全规范
e.通用
-> 智能分析现有项目
-> 全量代码语义索引 | 上下文强关联分析
b.智能引导
a.智能分析
01.自然语言描述需求
02.语义理解需求拆解
03.接口+表结构设计
04.业务逻辑生成
05.工程源码一气呵成
b.智能分析
AI自动关联老项目，智能预分析
在合并项目场景下，基于全量代码语义索引和上下文强关联分析，对项目架构、模块交互、核心业务逻辑进行深度理解，全程本地化处理机制，代码安全0担忧。
c.自定义AI规则文件
通过规则自定义AI开发规范
用户可通过自然语言编写规则（如Java技术栈、代码规范、安全要求等），指导AI生成代码时严格遵循特定技术标准和规范，确保输出代码的高合规、高复用、开箱即用。
d.需求理解助手
智能语义理解
支持文本/语音输入描述需求，飞算JavaAI 利用大模型技术进行语义理解，准确洞察你的每一个业务需求。
e.自动化设计引擎
接口和表结构设计一站式生成
通过自研的Java专有模型进行接口和表结构设计
辅助开发者梳理业务流程及数据库表结构设计，完成复杂的功能。
f.自动化逻辑处理，智能调优
完成详细的接口逻辑描述
飞算JavaAI能够自动生成每个接口的详细逻辑流程内容，并定义接口与接口之间的关系，将复杂的业务逻辑拆解为具体的实现步骤，并生成接口的详细操作流程。
同时，允许用户基于实际业务需求修改局部逻辑，修改后AI结合上下文对整体逻辑描述进行智能调优，避免逻辑漏洞风险，最终输出更贴合业务场景的接口描述。
实现“生成-反馈-再优化”的闭环机制。
g.一键工程构建
代码边生成，边预览，逐级确认
按接口模块顺序逐一生成，并支持实时预览代码。
在合并项目的场景下，用户可以逐级生成和确认，精准把控每个接口的设计与实现，最终一键输出完整项目工程。
h.全流程开发文档自动化生成
步步留痕，可解释，可追溯
「代码-文档」智能同源，实现从需求分析→设计→实现的全流程思维链、开发痕迹自动沉淀，解决传统开发中代码与文档割裂的痛点，构建可追溯、可验证的智能化开发闭环。
c.SQL Chat
a.跨数据库兼容性
支持 Oracle、MySQL、PostgreSQL、BigQuery、DuckDB、ClickHouse、Snowflake、Trino等主流数据库数的转换，统一操作入口，适应混合技术栈环境。
b.业务语义理解
通过库表集预配置业务字段别名、计算逻辑，精准映射业务需求。
c.SQL语句的精准生成
将自然语言需求自动转化为可直接执行的SQL代码，替代手动编写，减少语法学习成本。
d.SQL智能纠错能力
对执行报错的SQL进行自动修复（如字段名错误、连接逻辑冲突），降低反复调试的成本。
e.提效与数据安全兼得
元数据级操作机制（不传输真实数据）从设计源头保障隐私，消除数据泄露担忧。
d.智能会话
a.智能问答
实时技术问答支持
开发问题实时解答，提供涵盖代码理解、开发辅助、错误排査等场景的针对性解决方案。
b.JavaChat
工程分析、代码重构/优化
JavaChat 是一款深度融合上下文感知的智能编程AI助手，帮您分析和优化现有的项目工程和代码重构等操作。
c.编程智能体
自动调用工具执行编程任务
JavaAI智能体具备自主感知工程上下文、调用工具、执行编程任务、完成问题修复和结果验证的能力。完全自主执行，无需人工干预。
需求理解 -> 任务拆解 -> 代码生成 -> 问题修复 -> 结果验证
e.AI工具箱
a.项目分析器
项目分析器深度分析项目后，一键生成完整的项目文档（包括但不限于系统架构图、核心功能说明、数据流分析、部署指南、可扩展性设计等），
将写文档融入编码流程，解决文档滞后问题，解放工程师专注高价值开发。
b.框架升级器
框架升级器可以帮助 Java 项目将代码（语言版本、框架版本）从旧版本升级到目标新版本，
自动处理 API 变更、语法差异、依赖兼容性等问题，大幅降低人工升级成本。
c.Java整洁器
Java整洁器能够优化代码整洁度，通过静态分析（SAST）识别代码中的潜在问题（如语法冗余、潜在漏洞），
并自动修复Checkstyle违规、简化表达式、删除冗余代码等。同时提供回退机制，确保优化过程可控。
d.Java安全修复器
Java安全修复器专注于主动检测并修复Java项目中的安全漏洞（涵盖 OWASP Top 10等高危风险）。
用户可选择性接受或回退修改，实现安全漏洞的闭环管理。
e.框架迁移器
专用于帮助开发者将项目从一种技术框架迁移到另一种框架。
它会自动处理不同框架间的API变更、语法差异、依赖管理以及配置文件调整等问题，从而显著降低迁移过程的技术负担和潜在错误。
f.最佳实践器
最佳实践器可以自动化应用主流框架的最佳实践，覆盖从架构设计到编码规范的各个环节。
通过分析项目代码，识别与框架官方推荐方案不符的模式，并提供一键式优化建议，帮助开发者直接将代码提升到行业标准水平。
g.Jar依赖修复器
Jar依赖修复器用于自动化检测并修复项目中的Jar依赖问题。如清理冗余Jar，自动升级过期或有安全风险的依赖版本，识别版本冲突并自动修复。
h.单元测试生成器
通过智能分析项目代码与环境，自动创建高覆盖率的测试用例，并在编译运行中实时修复问题，最终输出可直接集成的测试代码。
让用户从“写测试”转向“审测试”，将人力投入更高价值的设计与优化环节。
02.码上飞，codeflying
a.概述
a.地址
https://gitee.com/kuafuai/aipexbase
b.说明
中国首个开源AI原生后端服务
AipexBase 是由 北京跨赴科技(KuaFuAI) 自主研发并正式开源的——中国首个AI原生后端即服务(Backend-as-a-Service)平台。
它诞生于一个清晰的愿景：让开发者“不写后端，也能拥有完整后端”。
在 AipexBase 中，所有后端能力——数据存储、鉴权、三方接入、上下文管理——都被自动封装。
开发者无需再搭建API、配置Server、维护数据库，只需通过前端SDK或MCP协议，即可一键调用后端能力，让AI Coding真正实现从前端到后端的智能闭环。
AipexBase 不只是一个平台，更是中国AI时代的基础设施。它要让每一个开发者、每一个AI Agent，都能拥有构建完整智能应用的能力。
c.AI原生架构为AI Coding而生
如果说 Supabase 是Web 2.0时代的后端解决方案，那么 AipexBase 是AI时代的演进版本。
AipexBase 从底层重新定义了后端架构。
原生兼容 MCP(Model Context Protocol)，让模型与智能体可直接调用后端能力；
统一上下文与数据层，为AI应用提供“长期记忆”和“可追踪状态”；
前端即后端，前端开发者无需再写API，只需描述业务逻辑，AI即可自动完成后端实现。
-----------------------------------------------------------------------------------------------------
AipexBase现已支持：码上飞| Cursor | Trae 等AI产品接入，AipexBase 让“端到端的智能应用开发”真正成为现实，共同推动 AI Coding 新纪元。
这不只是Serverless的延伸，而是 AI原生架构(AI-Native Architecture) 的雏形，一个属于智能体时代的底座级创新。
d.开源共建让中国的AI基础设施走向世界
AipexBase 不只是“开源”，更是“国产友好”。它深度适配中国开发生态，是目前唯一原生支持飞书、钉钉、微信生态接入的AI后端基础设施；
同时完全兼容鸿蒙应用、小程序、WebView容器 等主流运行环境。这意味着，无论你在做企业协作工具、AI助手、教学小程序，
还是国产手机的智能体插件，AipexBase 都能天然对接、无缝接入。
在中国AI应用生态加速重构的今天，AipexBase 正在成为开发者绕不开的技术底座。跨赴科技希望通过开源的方式，与全球开发者共建AI时代的后端标准。
这不仅是一次产品发布，更是中国AI生态的基础性事件。它标志着，中国开发者终于拥有了自己的AI原生后端底座。
AipexBase 的目标不只是“替代”，而是“进化”：以开放的架构、兼容的生态、智能的接口，构建一个面向未来的AI应用基础设施。
每一位开发者都可以成为AipexBase的贡献者。无论是提交PR、完善文档，还是在实际项目中应用反馈，都将推动这一国产开源项目的持续进化。
b.aipexbase
a.特性
🤖 AI 原生架构
原生兼容 MCP (Model Context Protocol)：模型与智能体可直接调用后端能力
统一上下文与数据层：让 AI 应用具备长期记忆与可追踪状态管理
前端即后端：前端开发者无需关心 API、Server、DB 实现，专注业务逻辑
-------------------------------------------------------------------------------------------------
🛠️ 开箱即用的后端能力
数据存储：自动化的数据库操作与管理
用户鉴权：完整的身份认证与权限控制
三方接入：无缝集成主流 AI 服务和平台
上下文管理：智能的会话和状态维护
-------------------------------------------------------------------------------------------------
🇨🇳 国产生态全面适配
原生支持：飞书、钉钉、微信等国内主流平台
多端兼容：鸿蒙应用、小程序、WebView 容器
国产友好：深度适配中国开发生态
b.源码部署
1、配置要求
Java 1.8+
Node.js 18+
MySQL 8.0+
-------------------------------------------------------------------------------------------------
2、克隆代码
git clone https://gitee.com/kuafuai/aipexbase.git
cd aipexbase
-------------------------------------------------------------------------------------------------
3、将 sql 脚本导入本地 mysql 数据库 SQL
-------------------------------------------------------------------------------------------------
4、修改数据库连接配置
cd backend/src/main/resources
修改 application-mysql.yml 文件默认的 jdbc 配置
-------------------------------------------------------------------------------------------------
5、本地启动后端服务
mvn spring-boot:run
服务启动在 http://localhost:8080
-------------------------------------------------------------------------------------------------
6、本地启动管理后台（可选）
cd frontend
npm install
npm run dev
c.docker-compose部署指南
环境准备
linux
docker
docker-compose v2.5 以上
-------------------------------------------------------------------------------------------------
配置修改
编辑 ./install/docker-compose.yaml
修改 backend-new 服务的日志输出挂载目录，默认即可
修改 mysql-new 服务的 mysql 数据目录
修改 nginx-new 服务的 环境变量中 VITE_APP_SERVICE_API、VITE_PROJECT_API_ENDPOINT 修改为可访问的 ip 或域名
请自行填写可对外暴露使用的端口号暴露服务访问
其他项默认即可，如需修改自行斟酌。
-------------------------------------------------------------------------------------------------
运行
docker-compose up --build -d
-------------------------------------------------------------------------------------------------
备注
如果自行在外部搭建代理服务转发请求到 aipexbase 则需要配置如下代理配置，以 nginx 片段配置文件举例
location / {
root /usr/share/nginx;
try_files $uri $uri/ /index.html;
}
location /baas-api {
proxy_pass http://1.1.1.1:8080;
rewrite ^/baas-api/(.*)$ /$1 break;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /mcp {
proxy_pass http://1.1.1.1:8080;
proxy_set_header Host $host;
# 保留客户端真实 IP
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection '';
proxy_http_version 1.1;
proxy_buffering off;
proxy_cache off;
# 保持长连接
proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
}
c.aipexbase-mcp
a.说明
在 AI IDE 中原生集成 AIPEXBASE 提供的 Full-Skill Mcp Server 快速完成您的应用开发
b.创建应用
第一步进入 aipexbase 后台管理页面创建应用
进入您创建的应用中，点击左侧 API KEYS 进入密钥管理页面
填写信息创建当前应用下 API KEY，并复制保存
c.在 Cursor 中找到 Cursor Setting 配置 Mcp Servers
加入此配置项
替换域名并粘贴上述步骤中的 apikey 到 token= 后
-------------------------------------------------------------------------------------------------
{
"mcpServers": {
"aipexbase-mcp-server": {
"url": "http://localhost:9991/mcp/sse?token=kf_api_E1Hp1lx5YsdemdDMD1Ej22YeEm887Vd9"
}
}
}
-------------------------------------------------------------------------------------------------
成功加载 MCP TOOL & MCP PROMPT
d.加载提示词（Cursor 支持动态加载提示词，其他IDE 如 Trae 请参考文末指南）
首先点击在 cursor 右上角点击 Toggle AI Pane 打开智能体对话框，在对话框内输入 / 即可唤醒并选择 aipexbase 内置软件研发提示词
开始与 ai 对话 清晰的描述你的需求，并持续关注代码调整，与 ai 持续对话完善项目，最终完成前端项目的开发，后端全部交给 aipexbase.js + aipexbase
aipexbase.js 是用来与前端集成后调用 aipexbase 后端的 js sdk ，ai 会自动调用 aipexbase.js 进行代码编写，
aipexbase.js 用法请参考：https://vvx03gck2p.feishu.cn/docx/LSsLdYZQfoAo3zxTkwrcJuGVnC3 【前端快速集成手册】
-------------------------------------------------------------------------------------------------
示例：
请使用 vue3+js+vite 构建一个社区图书馆预约管理 web 系统
要求具备使用邮箱注册及登录功能
要求首页上方左侧有图书列表、借阅管理、个人信息三个按钮分别对应三个页面
图书列表应该包含每本图书的书名、作者、出版时间等信息，并且配有一个借书按钮
点击借书按钮时，需要判断当前图书的借阅状态，如果未被借走，则可以成功借出，并且在借阅管理可以查看自己当前借阅的书籍
在借阅管理页面可以针对每条借阅记录点击归还
在我的信息页面可以维护个人信息
e.开始启动开发，cursor 会根据上下文整理开发任务
/aipexbase-mcp-server/前后端软件研发专家研发软件的工作流
请使用vue3+jS+vite构建一个社区图书馆预约管理web系统
要求具备使用邮箱注册及登录功能
要求首页上方左侧有图书列表、借阅管理、个人信息三个按钮分别对应三个页面-图书列表应该包含每本图书的书名、作者、出版时间等信息，并且配有一个借书按钮
点击借书按钮时，需要判断当前图书的借阅状态，如果未被借走，则可以成功借出，并且在借阅管理可以查看自己当前借阅的书籍
在借阅管理页面可以针对每条借阅记录点击归还
在我的信息页面可以维护个人信息
f.在 mcp server token所对应的 aipexbase 应用中自动创建数据库表
管理端可查看表的创建情况
项目请持续与AI对话和修改进一步完善功能
03.码上飞，codeflying
a.提示词
a.说明1
工具：execute_sql、list_dynamic_api、list_tables
提示词：当你收到一个软件研发任务时，可以通过此工作流模板中的具体任务步骤与LLM交互并超高质量的完成一个软件的研发全流程
b.说明2
请使用 vue3+js+vite 构建一个社区图书馆预约管理 web 系统
要求具备使用邮箱注册及登录功能
要求首页上方左侧有图书列表、借阅管理、个人信息三个按钮分别对应三个页面
图书列表应该包含每本图书的书名、作者、出版时间等信息，并且配有一个借书按钮
点击借书按钮时，需要判断当前图书的借阅状态，如果未被借走，则可以成功借出，并且在借阅管理可以查看自己当前借阅的书籍
在借阅管理页面可以针对每条借阅记录点击归还
在我的信息页面可以维护个人信息
c.说明3
提示词：我想做一个个人博客网站，我想使用 vue3 + js + vite 进行项目构建，你可以采用各种第三方组件来优化项目整体效果。请不要在参数中添加转译符号。
该应用具体功能如下：
1.用户认证模块：支持用户注册与登录功能。支持微信授权登录或QQ邮箱登录
2.首页展示：用户登录后进入首页，需立即展示个人主页内容，页面左上方有三个选项按钮，分别对应三个页面：主页、个人信息、互动管理。
3.个人主页页面：显示"K姐研究社"简介、K姐研究社历史文章、用户头像、昵称；
4.文章详情页：展示文章全文；展示用户头像、昵称和留言互动内容；并对用户自己的留言提供"编辑留言"按钮。
5.个人信息：可以查看和修改个人基本信息（头像、昵称、邮箱、手机号、签名等）。
6.账号设置：支持修改密码、退出登录等操作。
-------------------------------------------------------------------------------------------------
在 TRAE 中输入需求描述，系统就自动生成了完整的前端项目结构。
后端部分，直接调用了 AipexBase MCP，可以直接执行建表、查表、SQL操作，几分钟就能完成建库。
b.常见问题
a.20251106
1.各种依赖不兼容的坑
2.McpServerFeatures.java文件冲突的坑，7 处 var → 显式函数式接口
3.数据库的坑：数据库自能用root，不能用创建数据库的用户
4.POM文件<plugin>配置问题
5.后端进程配置问题
6..env.production 配置里面 生产环境前端调用的后端地址写死
b.20251107
const response = await client.db
.from('article_cate')
.list()
.eq('user_id', this.targetUserId)
.order('created_at', 'desc')
.page(1, 5) 分页这样用就可以吗，我一直显示的是所有数据
-------------------------------------------------------------------------------------------------
用page方法
我在连接后端数据，当获取不到数据时，他不去想办法解决后端获取数据问题，然后他就给你弄模拟数据，实际还是获取不到后端数据。
-------------------------------------------------------------------------------------------------
啥意思？你是用AI coding 工具时的问题吗？
那可能是AI coding 工具的问题
-------------------------------------------------------------------------------------------------
我有个用户表，不知道为啥这个用户QQQQQQ 能登录成功，用户223344 登录提示用户不存在， 这一块有什么特别的地方吗
这张表设置为登录关联表了吗？设置了
-------------------------------------------------------------------------------------------------
你这个是自己部署的？
我刚才又测了一下注册，注册新的能登录上，223344 那个登录不上
-------------------------------------------------------------------------------------------------
嗯。自己部署的话，你可以看看login表里是否有数据
明白了，创建的用户表，也会把数据写入到login表中
c.20251112
mcp的提示词是不是要写好才行？
trae吗？不会自己创建数据表，而是生成了一个node 服务应用，模拟后端服务，
mcp服务也打通了，可以正常展示功能
-------------------------------------------------------------------------------------------------
建议使用哪个比较好呢？
trae也可以的。 https://s.trae.com.cn/a/cfa8bb 你看你能用这个吗？
-------------------------------------------------------------------------------------------------
我们之前测试弄的一个trae智能体。能加入你自己的里面吗？
你mcp链接的哪里的啊
那你看看你本地的服务器日志看看呢。
-------------------------------------------------------------------------------------------------
trae 要自己建智能体。可以参考 mcp/prompt/AipexbaseSystemPromptProvider这里。如果是cursor/cc 自带prompt协议。
c.常见问题
a.20251115
你从github上拉最新代码哈。 mcp链接的问题我们修了一个bug。
github是最新的，gitee没有更新是吧？
https://github.com/kuafuai/aipexbase/
-------------------------------------------------------------------------------------------------
多谢，可以自动创建表结构了，感觉mcp服务不是很稳定，现在我尝试下api的服务
ALTER TABLE `dynamic_api_setting` ADD COLUMN `market_id` int DEFAULT 0 AFTER `var_raw`;
整体的sql还没导出来。等我们测试完，导出一个完整的
尝试几次，也调用了mcp的list_dynamic_api服务，到那时还是没有api服务
-------------------------------------------------------------------------------------------------
list_dynamic_api 这个是告诉 Ai 里面有哪些API可以用。怎么用。让他在代码里写api调用。
我们做的就是基础能力。
-------------------------------------------------------------------------------------------------
请问这个api服务，是什么时候生成的呢？是表结构生成的时候吗？因为list_dynamic_api只返回了空的
理解了，这个是可以集成外部的api服务，然后让ai通过mcp协议调用
那现在ai通过mcp创建了表结构，那怎么告诉ai刚创建的表结构有哪些服务可以调用的呢？
b.20251116
都是错的，不知道是怎么调用的
遇到我都是把这个错误给 ai 让他去改
生成表结构后，生成的前端能请求后端表能力了吗？
-------------------------------------------------------------------------------------------------
最后弄出来了，这个过程还是有点崩溃的
指点下，ai生成了前端功能网页也能访问，后端数据表结构也生成了，但前端怎么使用这些表呢？比如登录、新增等
直接写用户注册 登录功能就行
我的都是没有太多要求，就实现了登录注册
实现登录 注册功能就行
-------------------------------------------------------------------------------------------------
我都没看后台日志，我就完全前端傻瓜式的
有问题把错误给ai，然后就不管它
直到出结果
-------------------------------------------------------------------------------------------------
理论上你是不用关心后端了。通过aipexbase-js和后端交互即可。
生成的前端项目是怎么知道aipexbase-js呢？
-------------------------------------------------------------------------------------------------
现在ai生成的前端，会请求/api/auth/me、/api/courts，但是后端会输出这样的日志：15:54:54.926 [http-nio-8080-exec-8] DEBUG o.s.s.w.FilterChainProxy - [doFilterInternal,208] - Securing GET /api/auth/me
15:54:54.928 [http-nio-8080-exec-8] DEBUG o.s.s.w.c.SecurityContextPersistenceFilter - [doFilter,102] - Set SecurityContextHolder to empty SecurityContext
15:54:54.929 [http-nio-8080-exec-5] DEBUG o.s.s.w.FilterChainProxy - [doFilterInternal,208] - Securing GET /api/courts
15:54:54.930 [http-nio-8080-exec-8] DEBUG o.s.w.s.h.SimpleUrlHandlerMapping - [getHandler,522] - Mapped to ParameterizableViewController [view="forward:/index.html"]
c.20251217
用init.sql建了数据库，然后建立aipexbase用户，dbeaver都连接成功了，
运行mvn spring-boot:run 只构建不运行，idea中构建提示要连接到demotest数据库
用init.sql数据建立了demotest数据库，再运行卡住，访问8080报参数错误401
3.3 [2]spring版本
01.常见信息1
a.项目概述
a.项目定位
AI 原生企业级 BaaS 平台（Java 版）
a.目标用户：中大型企业、传统行业数字化转型、政府部门
b.核心价值：稳定可靠、企业级安全、成熟生态、可维护性强
c.技术特点：基于成熟的 Java 技术栈，利用 VM 模版引擎实现代码自动生成
b.与原版 AipexBase 的关系
本方案是原版 AipexBase 的增强版：
维度 原版 AipexBase Java 增强版（本方案）
核心理念 ✅ 保持一致 ✅ 保持一致
AI 集成 ⚠️ 基础支持 ⭐ 深度集成（New-API + ccNexus）
成本优化 ❌ 缺失 ⭐ Coding Plan 成本降低 90%
MCP 协议 ⚠️ 有限支持 ⭐ 深度集成 Tool Calling
代码生成 ✅ VM 模版 ⭐ 增强 VM 模版 + AI 辅助
多前端 ✅ Vue 3 为主 ⭐ uni-app 多端统一
c.项目目标
1.继承 AipexBase 的优势：前端即后端、快速开发、企业级稳定性
2.强化 AI 能力：深度集成 MCP、Tool Calling、智能代码生成
3.降低使用成本：通过 Coding Plan 降低 AI 调用成本 90%+
4.增强多端能力：uni-app 统一开发，一套代码多端部署
b.技术架构
a.整体架构图
┌─────────────────────────────────────────────────────────────┐
│ 多前端层
├─────────────────────────────────────────────────────────────┤
│ Web 应用 小程序 H5 移动 APP │
│ (Vue 3 + (uni-app 编译 (uni-app (uni-app + │
│ Element Plus) 微信/支付宝) H5) 原生渲染) │
└───────────────────────┬─────────────────────────────────────┘
│ HTTP/WebSocket API
┌───────────────────────┴─────────────────────────────────────┐
│ 应用层
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 业务逻辑层 │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • 用户认证授权 │ │
│ │ • 业务服务 │ │
│ │ • 代码生成服务） │ │
│ │ • AI 服务、Tool Calling） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据访问层 │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • MyBatis Plus） │ │
│ │ • 动态 SQL 生成 │ │
│ │ • 数据库事务管理 │ │
│ └─────────────────────────────────────────────────────┘ │
└───────────────────────┬─────────────────────────────────────┘
│
┌───────────────────────┴─────────────────────────────────────┐
│ AI 网关层 │
├─────────────────────────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐ │
│ │ ccNexus │ │ New-API │ │
│ │ 智能路由 │ → │ Coding Plan │ │
│ │ 故障转移 │ │ 成本优化 │ │
│ └──────────────┘ └──────────────┘ │
└───────────────────────┬─────────────────────────────────────┘
│
┌───────────────────────┴─────────────────────────────────────┐
│ AI 提供商层 │
├─────────────────────────────────────────────────────────────┤
│ OpenAI │ Claude │ Gemini │ GLM │ Kimi │ 豆包 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 数据层 │
├─────────────────────────────────────────────────────────────┤
│ MySQL 8.0 Redis 6.0 MinIO（文件存储） │
└─────────────────────────────────────────────────────────────┘
b.技术栈详细清单
a.后端技术栈
核心框架
Spring Boot: 2.7.x（稳定版，企业级）
Spring Security: 认证授权
Spring MVC: Web 层
Spring AOP: 切面编程（日志、权限）
数据访问
MyBatis Plus: 3.5.x（ORM 增强）
Druid: 数据库连接池
Redis: Spring Data Redis
代码生成
Velocity: VM 模版引擎 ⭐ 核心
FreeMarker: 备选模版引擎
AI 集成
OkHttp: HTTP 客户端（调用 AI API）
WebSocket: 实时通信（流式响应）
Jackson: JSON 处理
工具库
Lombok: 简化代码
Hutool: Java 工具集
Guava: Google 工具库
构建工具
Maven: 依赖管理
Docker: 容器化部署
b.前端技术栈
主 Web 应用
Vue 3: 核心框架
Element Plus: UI 组件库
Vite: 构建工具
Pinia: 状态管理
Vue Router: 路由管理
Axios: HTTP 客户端
多端应用
uni-app: 多端统一开发框架
uView UI: uni-app UI 组件库
开发工具
TypeScript: 类型安全
ESLint: 代码规范
Prettier: 代码格式化
c.数据库与中间件
数据库
MySQL: 8.0.x（关系型数据库）
Redis: 6.0.x（缓存、会话）
文件存储
MinIO: 对象存储（私有部署）
或 阿里云 OSS（云服务）
消息队列（可选）
RabbitMQ: 异步任务
或 Kafka: 大数据场景
c.VM 模版引擎应用
a.为什么选择 Velocity
Velocity 是 Apache 的 Java 模版引擎，在企业级代码生成中广泛应用：
对比项 Velocity FreeMarker Thymeleaf
学习曲线 ⭐⭐⭐⭐⭐ 简单 ⭐⭐⭐ 中等 ⭐⭐ 复杂
性能 ⭐⭐⭐⭐ 快 ⭐⭐⭐⭐ 快 ⭐⭐⭐ 中
代码生成 ⭐⭐⭐⭐⭐ 最佳 ⭐⭐⭐⭐ 好 ⭐⭐ 不适合
社区 ⭐⭐⭐⭐⭐ 成熟 ⭐⭐⭐⭐ 成熟 ⭐⭐⭐ 较新
b.VM 模版结构
src/main/resources/templates/
├── entity/
│ └── Entity.java.vm # 实体类模版
├── mapper/
│ ├── Mapper.java.vm # Mapper 接口模版
│ └── Mapper.xml.vm # MyBatis XML 模版
├── service/
│ ├── Service.java.vm # Service 接口模版
│ └── ServiceImpl.java.vm # Service 实现模版
├── controller/
│ └── Controller.java.vm # Controller 模版
└── vue/
├── list.vue.vm # 列表页面模版
├── edit.vue.vm # 编辑页面模版
└── api.js.vm # 前端 API 模版
02.常见信息2
a.框架设计
a.代码生成流程
1.用户输入（或 AI 生成）数据库表结构
↓
2.解析表结构，提取元数据
- 表名、注释
- 字段名、类型、注释
- 主键、索引
↓
3.填充 VM 模版上下文
VelocityContext context = new VelocityContext();
context.put("package", "com.example.project");
context.put("className", "User");
context.put("table", tableMetadata);
context.put("columns", columns);
↓
4.Velocity 引擎渲染模版
Template template = velocityEngine.getTemplate("Entity.java.vm");
StringWriter writer = new StringWriter();
template.merge(context, writer);
↓
5.生成代码文件
- Entity.java
- Mapper.java
- Mapper.xml
- Service.java
- ServiceImpl.java
- Controller.java
- list.vue
- edit.vue
↓
6.可选：AI 优化生成的代码
- 通过 MCP 调用 AI 审查代码
- 优化业务逻辑
- 添加注释和文档
b.AI 增强的 VM 模版
/**
* AI 增强的代码生成器
*/
public class AIEnhancedCodeGenerator {
@Autowired
private MCPService mcpService;
/**
* 生成代码（AI 增强版）
*/
public GenerateResult generate(TableMetadata table, String userIntent) {
// 1. 传统 VM 模版生成基础代码
Map<String, String> baseCode = velocityGenerate(table);
// 2. AI 理解用户意图，优化代码
String optimizedEntity = mcpService.callTool("optimize_code", Map.of(
"code", baseCode.get("Entity.java"),
"intent", userIntent,
"context", "这是一个" + table.getComment() + "的实体类"
));
// 3. AI 生成业务逻辑
String businessLogic = mcpService.callTool("generate_business_logic", Map.of(
"table", table,
"intent", userIntent
));
// 4. 合并结果
return GenerateResult.builder()
.entity(optimizedEntity)
.service(baseCode.get("Service.java") + businessLogic)
.controller(baseCode.get("Controller.java"))
.vue(baseCode.get("list.vue"))
.build();
}
}
c.效果对比
| 功能 | 传统 VM 模版 | AI 增强 VM 模版 |
|------|------------|----------------|
| 基础 CRUD | ✅ | ✅ |
| 复杂查询 | ❌ 手动编写 | ✅ AI 生成 |
| 业务逻辑 | ❌ 手动编写 | ✅ AI 生成 |
| 代码优化 | ❌ 手动优化 | ✅ AI 自动优化 |
| 文档注释 | ⚠️ 简单注释 | ✅ AI 生成详细文档 |
| 单元测试 | ❌ 手动编写 | ✅ AI 生成测试代码 |
b.ccNexus集成
a.配置文件
# application.yml（使用 ccNexus）
ai:
gateway:
# 指向 ccNexus 而不是 New-API
base-url: http://localhost:3000/v1
api-key: ${CCNEXUS_KEY}
b.架构
Java 应用
↓ HTTP
ccNexus（智能路由）
↓ HTTP
New-API（Coding Plan 管理）
↓ HTTP
AI 提供商（GLM/Kimi/豆包）
c.优势
ccNexus 提供端点健康检查
自动故障转移
请求统计和监控
c.New-API集成
a.依赖配置
<!-- pom.xml -->
<dependencies>
<!-- HTTP 客户端 -->
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
<version>4.12.0</version>
</dependency>
<!-- JSON 处理 -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
</dependencies>
b.配置文件
# application.yml
ai:
gateway:
# New-API 网关地址
base-url: http://localhost:3001/v1
# API Key（New-API 管理后台生成）
api-key: ${NEW_API_KEY}
# 默认模型
default-model: glm-coding-plan
# 超时配置
timeout:
connect: 10s
read: 60s
write: 60s
# 重试配置
retry:
max-attempts: 3
delay: 1s
c.客户端封装
/**
* New-API 客户端
*/
@Component
@Slf4j
public class NewAPIClient {
@Value("${ai.gateway.base-url}")
private String baseUrl;
@Value("${ai.gateway.api-key}")
private String apiKey;
private final OkHttpClient httpClient;
private final ObjectMapper objectMapper;
public NewAPIClient() {
this.httpClient = new OkHttpClient.Builder()
.connectTimeout(10, TimeUnit.SECONDS)
.readTimeout(60, TimeUnit.SECONDS)
.writeTimeout(60, TimeUnit.SECONDS)
.addInterceptor(new RetryInterceptor())
.build();
this.objectMapper = new ObjectMapper();
}
/**
* 聊天补全（非流式）
*/
public ChatCompletionResponse chatCompletion(ChatCompletionRequest request) {
try {
String jsonBody = objectMapper.writeValueAsString(request);
Request httpRequest = new Request.Builder()
.url(baseUrl + "/chat/completions")
.header("Authorization", "Bearer " + apiKey)
.header("Content-Type", "application/json")
.post(RequestBody.create(jsonBody, MediaType.parse("application/json")))
.build();
try (Response response = httpClient.newCall(httpRequest).execute()) {
if (!response.isSuccessful()) {
throw new AIException("AI API 调用失败: " + response.code());
}
String responseBody = response.body().string();
return objectMapper.readValue(responseBody, ChatCompletionResponse.class);
}
} catch (Exception e) {
log.error("调用 New-API 失败", e);
throw new AIException("AI 服务异常", e);
}
}
/**
* 聊天补全（流式）
*/
public void chatCompletionStream(
ChatCompletionRequest request,
Consumer<String> onChunk,
Runnable onComplete
) {
try {
request.setStream(true);
String jsonBody = objectMapper.writeValueAsString(request);
Request httpRequest = new Request.Builder()
.url(baseUrl + "/chat/completions")
.header("Authorization", "Bearer " + apiKey)
.header("Content-Type", "application/json")
.post(RequestBody.create(jsonBody, MediaType.parse("application/json")))
.build();
httpClient.newCall(httpRequest).enqueue(new Callback() {
@Override
public void onResponse(Call call, Response response) {
try (BufferedReader reader = new BufferedReader(
new InputStreamReader(response.body().byteStream()))) {
String line;
while ((line = reader.readLine()) != null) {
if (line.startsWith("data: ")) {
String data = line.substring(6);
if ("[DONE]".equals(data)) {
onComplete.run();
break;
}
ChatCompletionChunk chunk = objectMapper.readValue(
data, ChatCompletionChunk.class);
String content = chunk.getChoices().get(0)
.getDelta().getContent();
if (content != null) {
onChunk.accept(content);
}
}
}
} catch (Exception e) {
log.error("处理流式响应失败", e);
}
}
@Override
public void onFailure(Call call, IOException e) {
log.error("流式请求失败", e);
}
});
} catch (Exception e) {
log.error("发起流式请求失败", e);
throw new AIException("AI 服务异常", e);
}
}
}
d.Coding Plan 配置
/**
* Coding Plan 管理器
*/
@Service
@Slf4j
public class CodingPlanManager {
@Autowired
private NewAPIClient newAPIClient;
private final List<String> codingPlanModels = Arrays.asList(
"glm-coding-plan", // 智谱 GLM（免费）
"kimi-coding-plan", // Kimi（低价）
"doubao-coding-plan" // 豆包（低价）
);
/**
* 智能选择模型
* 优先使用免费模型，失败则降级到低价模型
*/
public String selectModel(String taskType, int complexity) {
// 简单任务：优先 GLM 免费
if (complexity <= 3) {
return "glm-coding-plan";
}
// 中等任务：Kimi 或 Doubao
if (complexity <= 7) {
return Math.random() > 0.5 ? "kimi-coding-plan" : "doubao-coding-plan";
}
// 复杂任务：可以使用 GPT-4 或 Claude
return "gpt-4";
}
/**
* 带重试的调用（自动降级）
*/
public ChatCompletionResponse callWithFallback(ChatCompletionRequest request) {
for (String model : codingPlanModels) {
try {
request.setModel(model);
log.info("尝试使用模型: {}", model);
ChatCompletionResponse response = newAPIClient.chatCompletion(request);
log.info("模型 {} 调用成功", model);
return response;
} catch (Exception e) {
log.warn("模型 {} 调用失败，尝试下一个", model, e);
}
}
throw new AIException("所有 Coding Plan 模型均调用失败");
}
}
03.常见信息3
a.MCP协议实现
a.MCP Client for Java
/**
* MCP 服务
*/
@Service
@Slf4j
public class MCPService {
@Autowired
private CodingPlanManager codingPlanManager;
/**
* MCP Tool 定义
*/
private final List<MCPTool> tools = Arrays.asList(
MCPTool.builder()
.name("generate_code")
.description("生成 Java 代码")
.parameters(Map.of(
"type", "object",
"properties", Map.of(
"codeType", Map.of("type", "string", "enum", Arrays.asList("entity", "service", "controller")),
"tableName", Map.of("type", "string"),
"className", Map.of("type", "string")
),
"required", Arrays.asList("codeType", "tableName", "className")
))
.build(),
MCPTool.builder()
.name("execute_sql")
.description("执行 SQL 语句（查询、建表）")
.parameters(Map.of(
"type", "object",
"properties", Map.of(
"sql", Map.of("type", "string"),
"operation", Map.of("type", "string", "enum", Arrays.asList("query", "execute"))
),
"required", Arrays.asList("sql", "operation")
))
.build(),
MCPTool.builder()
.name("read_file")
.description("读取项目文件")
.parameters(Map.of(
"type", "object",
"properties", Map.of(
"filePath", Map.of("type", "string")
),
"required", Arrays.asList("filePath")
))
.build()
);
/**
* 调用 MCP Tool
*/
public String callTool(String toolName, Map<String, Object> parameters) {
// 1. 构建请求
ChatCompletionRequest request = ChatCompletionRequest.builder()
.model("glm-coding-plan")
.messages(Arrays.asList(
ChatMessage.system("你是一个代码助手，可以使用工具完成任务。"),
ChatMessage.user("请使用 " + toolName + " 工具，参数：" + parameters)
))
.tools(tools)
.toolChoice("auto")
.build();
// 2. 调用 AI
ChatCompletionResponse response = codingPlanManager.callWithFallback(request);
// 3. 检查是否调用了工具
ChatMessage assistantMessage = response.getChoices().get(0).getMessage();
if (assistantMessage.getToolCalls() != null && !assistantMessage.getToolCalls().isEmpty()) {
ToolCall toolCall = assistantMessage.getToolCalls().get(0);
// 4. 执行工具
String result = executeTool(toolCall.getFunction().getName(),
toolCall.getFunction().getArguments());
// 5. 返回结果给 AI
ChatCompletionRequest followUpRequest = ChatCompletionRequest.builder()
.model("glm-coding-plan")
.messages(Arrays.asList(
ChatMessage.system("你是一个代码助手。"),
ChatMessage.user("请使用 " + toolName + " 工具，参数：" + parameters),
assistantMessage,
ChatMessage.tool(result, toolCall.getId())
))
.build();
ChatCompletionResponse followUpResponse = codingPlanManager.callWithFallback(followUpRequest);
return followUpResponse.getChoices().get(0).getMessage().getContent();
}
return assistantMessage.getContent();
}
/**
* 执行具体工具
*/
private String executeTool(String toolName, Map<String, Object> arguments) {
switch (toolName) {
case "generate_code":
return generateCode(arguments);
case "execute_sql":
return executeSql(arguments);
case "read_file":
return readFile(arguments);
default:
throw new IllegalArgumentException("未知工具: " + toolName);
}
}
// 工具实现方法...
}
b.Tool Calling 示例
/**
* AI 辅助的代码生成 Controller
*/
@RestController
@RequestMapping("/api/ai/generate")
public class AIGenerateController {
@Autowired
private MCPService mcpService;
/**
* AI 生成代码（通过对话）
*/
@PostMapping("/code")
public Result<String> generateCode(@RequestBody AIGenerateRequest request) {
// 用户输入：请帮我创建一个用户表，包含姓名、邮箱、手机号
String userInput = request.getUserInput();
// AI 通过 MCP 调用工具
String result = mcpService.callTool("generate_code", Map.of(
"userIntent", userInput
));
return Result.success(result);
}
}
b.BaaS能力
a.自动数据库管理
/**
* 数据库自动管理服务
*/
@Service
public class DatabaseAutoService {
@Autowired
private DataSource dataSource;
@Autowired
private MCPService mcpService;
/**
* AI 创建表（通过自然语言）
*/
public String createTableByAI(String userIntent) {
// 1. AI 理解意图，生成 SQL
String sql = mcpService.callTool("generate_sql", Map.of(
"intent", userIntent,
"operation", "CREATE TABLE"
));
// 2. 执行 SQL
try (Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement()) {
stmt.execute(sql);
return "表创建成功: " + sql;
} catch (Exception e) {
throw new RuntimeException("创建表失败", e);
}
}
/**
* 自动生成 CRUD 代码
*/
public Map<String, String> generateCRUD(String tableName) {
// 1. 读取表结构
TableMetadata table = readTableMetadata(tableName);
// 2. 使用 VM 模版生成基础代码
Map<String, String> baseCode = velocityGenerate(table);
// 3. AI 优化代码
Map<String, String> optimizedCode = new HashMap<>();
baseCode.forEach((fileName, code) -> {
String optimized = mcpService.callTool("optimize_code", Map.of(
"code", code,
"language", "java"
));
optimizedCode.put(fileName, optimized);
});
return optimizedCode;
}
}
b.认证授权系统
/**
* 基于 Spring Security + JWT 的认证
*/
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Autowired
private JwtAuthenticationFilter jwtFilter;
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.csrf().disable()
.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.authorizeRequests()
.antMatchers("/api/auth/**").permitAll()
.antMatchers("/api/public/**").permitAll()
.anyRequest().authenticated()
.and()
.addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class);
}
}
c.API自动生成
基于 VM 模版 + AI 增强，自动生成 RESTful API。
d.文件存储
/**
* MinIO 文件存储服务
*/
@Service
public class MinIOService {
@Autowired
private MinioClient minioClient;
public String upload(MultipartFile file) {
// 上传逻辑
}
public byte[] download(String fileName) {
// 下载逻辑
}
}
3.4 [2]nextjs版本
01.常见信息1
a.项目概述
a.项目定位
新版 AipexBase - 现代化 AI 原生开发平台（Next.js 版）
目标用户：创业团队、独立开发者、需要快速 MVP 验证的产品
核心价值：最佳开发体验、快速迭代、全栈 TypeScript、AI 深度集成
技术特点：Vercel AI SDK 原生集成、Server Components、Turborepo Monorepo
b.差异化优势
维度 Java 版 Next.js 版 ⭐ Go 版
开发速度 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐
开发体验 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐
AI 集成 ⭐⭐⭐ ⭐⭐⭐⭐⭐ Vercel AI SDK ⭐⭐⭐
全栈统一 ❌ 分离 ✅ TypeScript 统一 ❌ 分离
多端共享 ⚠️ 有限 ✅ Monorepo 高度共享 ⚠️ 有限
部署难度 ⭐⭐⭐ ⭐⭐⭐⭐⭐ Vercel 一键 ⭐⭐⭐⭐
c.项目目标
保持 AipexBase 理念：前端即后端、AI 原生、快速开发
采用现代技术栈：Bun + Next.js 14 + TypeScript
深度 AI 集成：Vercel AI SDK + MCP + Tool Calling
成本优化：通过 ccNexus/New-API 集成 Coding Plan
多端统一：Turborepo Monorepo 共享代码逻辑
b.技术架构
a.整体架构图
┌─────────────────────────────────────────────────────────────┐
│ 多前端层（Turborepo Monorepo） │
├─────────────────────────────────────────────────────────────┤
│ apps/web apps/miniapp apps/mobile │
│ (Next.js 14) (Taro + React) (React Native) │
│ 主 Web 应用 小程序（微信/支付宝） iOS/Android APP │
└──────────────┬──────────────────────────────────────────────┘
│ 共享代码
┌──────────────┴──────────────────────────────────────────────┐
│ packages/（共享逻辑层） │
├─────────────────────────────────────────────────────────────┤
│ @repo/ai-core @repo/ui @repo/database │
│ AI 调用封装 shadcn/ui 组件 Prisma ORM │
│ │
│ @repo/config @repo/types @repo/utils │
│ 共享配置 TypeScript 类型 工具函数 │
└──────────────┬──────────────────────────────────────────────┘
│ Server Actions / API Routes
┌──────────────┴──────────────────────────────────────────────┐
│ Next.js 全栈层（apps/web） │
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 前端层（App Router） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • React Server Components │ │
│ │ • useChat, useCompletion (Vercel AI SDK Hooks) │ │
│ │ • shadcn/ui 组件库 │ │
│ │ • TailwindCSS 样式 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 后端层（Server Actions + API Routes） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • Server Actions（服务器函数） │ │
│ │ • Vercel AI SDK（streamText, generateText） │ │
│ │ • Prisma ORM（数据库操作） │ │
│ │ • NextAuth.js（认证） │ │
│ └─────────────────────────────────────────────────────┘ │
└──────────────┬──────────────────────────────────────────────┘
│
┌──────────────┴──────────────────────────────────────────────┐
│ AI 网关层（External Services） │
├─────────────────────────────────────────────────────────────┤
│ ccNexus（可选）→ New-API → AI Providers │
│ 智能路由 Coding Plan GLM/Kimi/豆包 │
└──────────────┬──────────────────────────────────────────────┘
│
┌──────────────┴──────────────────────────────────────────────┐
│ 数据层（Data Layer） │
├─────────────────────────────────────────────────────────────┤
│ Supabase（推荐初期）或 自建 PostgreSQL/MySQL + Redis │
│ Uploadthing / Vercel Blob（文件存储） │
└─────────────────────────────────────────────────────────────┘
b.Turborepo Monorepo 结构
my-ai-platform/
├── .gitignore
├── package.json # 根 package.json
├── turbo.json # Turborepo 配置
├── pnpm-workspace.yaml # pnpm workspace 配置
│
├── apps/ # 应用层
│ ├── web/ # Next.js 主应用
│ │ ├── app/ # App Router
│ │ │ ├── (auth)/ # 认证路由组
│ │ │ ├── (dashboard)/ # 仪表盘路由组
│ │ │ ├── api/ # API Routes
│ │ │ │ ├── chat/route.ts # AI 聊天接口
│ │ │ │ └── mcp/route.ts # MCP 工具调用
│ │ │ ├── layout.tsx
│ │ │ └── page.tsx
│ │ ├── lib/ # 应用级库
│ │ │ ├── ai/ # AI 相关
│ │ │ │ ├── providers.ts # Provider 配置
│ │ │ │ └── tools.ts # MCP 工具定义
│ │ │ ├── auth.ts # NextAuth 配置
│ │ │ └── db.ts # Prisma 客户端
│ │ ├── actions/ # Server Actions
│ │ │ ├── auth.ts
│ │ │ ├── ai.ts
│ │ │ └── database.ts
│ │ ├── components/ # 应用级组件
│ │ ├── public/
│ │ ├── next.config.mjs
│ │ ├── tailwind.config.ts
│ │ └── package.json
│ │
│ ├── miniapp/ # Taro 小程序
│ │ ├── src/
│ │ │ ├── pages/
│ │ │ ├── components/
│ │ │ ├── app.tsx
│ │ │ └── app.config.ts
│ │ ├── project.config.json
│ │ └── package.json
│ │
│ └── mobile/ # React Native APP
│ ├── src/
│ ├── android/
│ ├── ios/
│ └── package.json
│
├── packages/ # 共享包
│ ├── ai-core/ # AI 核心逻辑 ⭐ 核心
│ │ ├── src/
│ │ │ ├── providers/ # AI Provider 适配器
│ │ │ │ ├── index.ts
│ │ │ │ ├── openai.ts
│ │ │ │ ├── anthropic.ts
│ │ │ │ └── glm.ts # 智谱 GLM
│ │ │ ├── mcp/ # MCP 工具
│ │ │ │ ├── tools.ts # 工具定义
│ │ │ │ ├── code-gen.ts # 代码生成工具
│ │ │ │ ├── database.ts # 数据库操作工具
│ │ │ │ └── file-system.ts # 文件系统工具
│ │ │ ├── gateway/ # 网关集成
│ │ │ │ ├── ccnexus.ts # ccNexus 集成
│ │ │ │ ├── new-api.ts # New-API 集成
│ │ │ │ └── router.ts # 智能路由
│ │ │ └── index.ts
│ │ ├── tsconfig.json
│ │ └── package.json
│ │
│ ├── ui/ # UI 组件库
│ │ ├── src/
│ │ │ ├── components/ # shadcn/ui 组件
│ │ │ │ ├── ui/
│ │ │ │ └── custom/
│ │ │ ├── hooks/ # React Hooks
│ │ │ └── index.ts
│ │ └── package.json
│ │
│ ├── database/ # Prisma 数据库
│ │ ├── prisma/
│ │ │ ├── schema.prisma # 数据库 Schema
│ │ │ └── migrations/
│ │ ├── src/
│ │ │ ├── client.ts # Prisma 客户端
│ │ │ └── seed.ts # 数据种子
│ │ └── package.json
│ │
│ ├── types/ # TypeScript 类型
│ │ ├── src/
│ │ │ ├── ai.ts
│ │ │ ├── database.ts
│ │ │ └── index.ts
│ │ └── package.json
│ │
│ ├── utils/ # 工具函数
│ │ ├── src/
│ │ │ ├── format.ts
│ │ │ ├── validation.ts
│ │ │ └── index.ts
│ │ └── package.json
│ │
│ └── config/ # 共享配置
│ ├── eslint/
│ ├── typescript/
│ └── tailwind/
│
└── services/ # 外部服务（Docker）
├── ccnexus/
│ └── docker-compose.yml
└── new-api/
└── docker-compose.yml
c.技术栈详细清单
a.运行时 & 框架
{
"runtime": "bun",
"framework": "Next.js 14.x (App Router)",
"language": "TypeScript 5.x",
"packageManager": "pnpm"
}
b.核心依赖
// apps/web/package.json
{
"dependencies": {
// Next.js 核心
"next": "^14.2.0",
"react": "^18.3.0",
"react-dom": "^18.3.0",
// Vercel AI SDK ⭐ 核心
"ai": "^3.0.0",
"@ai-sdk/openai": "^0.0.20",
"@ai-sdk/anthropic": "^0.0.15",
"@ai-sdk/google": "^0.0.12",
// 数据库 & ORM
"@prisma/client": "^5.10.0",
"prisma": "^5.10.0",
// 认证
"next-auth": "^5.0.0-beta",
// UI
"@radix-ui/react-dialog": "^1.0.5",
"@radix-ui/react-dropdown-menu": "^2.0.6",
"class-variance-authority": "^0.7.0",
"clsx": "^2.1.0",
"tailwind-merge": "^2.2.1",
"lucide-react": "^0.344.0",
// 表单
"react-hook-form": "^7.50.1",
"zod": "^3.22.4",
// HTTP 客户端
"ky": "^1.2.0"
},
"devDependencies": {
"@types/node": "^20",
"@types/react": "^18",
"typescript": "^5",
"tailwindcss": "^3.4.0",
"eslint": "^8",
"prettier": "^3"
}
}
c.packages/ai-core 依赖
// packages/ai-core/package.json
{
"name": "@repo/ai-core",
"dependencies": {
"ai": "^3.0.0",
"@ai-sdk/openai": "^0.0.20",
"@ai-sdk/anthropic": "^0.0.15",
"zod": "^3.22.4",
"ky": "^1.2.0"
}
}
c.适配 ccNexus/New-API
a.架构关系
Next.js 应用
↓ (通过 Vercel AI SDK)
ccNexus（可选，智能路由）
↓
New-API（Coding Plan 管理）
↓
AI 提供商（GLM/Kimi/豆包/OpenAI/Claude）
b.Provider 配置
// packages/ai-core/src/providers/index.ts
import { createOpenAI } from '@ai-sdk/openai';
import { createAnthropic } from '@ai-sdk/anthropic';
import { experimental_createProviderRegistry as createProviderRegistry } from 'ai';
/**
* AI Provider 注册表
*/
export function createAIRegistry() {
// ccNexus 或 New-API 的 baseURL
const gatewayURL = process.env.AI_GATEWAY_URL || 'http://localhost:3001/v1';
const apiKey = process.env.AI_GATEWAY_KEY || 'sk-xxx';
// 配置 Provider（通过 ccNexus/New-API 代理）
const openai = createOpenAI({
baseURL: gatewayURL,
apiKey: apiKey,
});
const anthropic = createAnthropic({
baseURL: gatewayURL.replace('/v1', '/v1/claude'),
apiKey: apiKey,
});
// 创建 Provider 注册表
const registry = createProviderRegistry({
// OpenAI 兼容模型（通过 New-API）
openai,
anthropic,
});
return registry;
}
/**
* 获取语言模型
*/
export function getLanguageModel(modelId: string) {
const registry = createAIRegistry();
return registry.languageModel(modelId);
}
c.Coding Plan 模型配置
// packages/ai-core/src/providers/coding-plan.ts
/**
* Coding Plan 模型列表
*/
export const CODING_PLAN_MODELS = {
// 智谱 GLM（免费）
GLM_FREE: 'glm-coding-plan',
// Kimi（低价）
KIMI: 'kimi-coding-plan',
// 豆包（低价）
DOUBAO: 'doubao-coding-plan',
} as const;
/**
* 智能选择 Coding Plan 模型
*/
export function selectCodingPlanModel(taskComplexity: number): string {
// 简单任务：GLM 免费
if (taskComplexity <= 3) {
return CODING_PLAN_MODELS.GLM_FREE;
}
// 中等任务：Kimi 或 豆包
if (taskComplexity <= 7) {
return Math.random() > 0.5 ? CODING_PLAN_MODELS.KIMI : CODING_PLAN_MODELS.DOUBAO;
}
// 复杂任务：GPT-4
return 'openai:gpt-4';
}
/**
* 带降级的 AI 调用
*/
export async function generateWithFallback(prompt: string) {
const models = [
CODING_PLAN_MODELS.GLM_FREE,
CODING_PLAN_MODELS.KIMI,
CODING_PLAN_MODELS.DOUBAO,
'openai:gpt-3.5-turbo',
];
for (const model of models) {
try {
const result = await generateText({
model: getLanguageModel(model),
prompt,
});
return result;
} catch (error) {
console.warn(`模型 ${model} 调用失败，尝试下一个`);
continue;
}
}
throw new Error('所有模型均调用失败');
}
d.环境变量配置
# .env.local
# AI Gateway（ccNexus 或 New-API）
AI_GATEWAY_URL=http://localhost:3001/v1
AI_GATEWAY_KEY=sk-your-new-api-key
# 或者直接使用各个提供商（不经过网关）
# OPENAI_API_KEY=sk-xxx
# ANTHROPIC_API_KEY=sk-ant-xxx
02.常见信息2
a.Vercel AI SDK 集成
a.基础用法
a.示例1：非流式文本生成
---
// app/actions/ai.ts
'use server';
import { generateText } from 'ai';
import { getLanguageModel } from '@repo/ai-core';
export async function generateResponse(prompt: string) {
const result = await generateText({
model: getLanguageModel('glm-coding-plan'),
prompt: prompt,
});
return result.text;
}
---
b.示例2：流式文本生成
---
// app/api/chat/route.ts
import { streamText } from 'ai';
import { getLanguageModel } from '@repo/ai-core';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = await streamText({
model: getLanguageModel('glm-coding-plan'),
messages,
});
return result.toAIStreamResponse();
}
---
c.示例3：React Hook（useChat）
---
// app/components/chat.tsx
'use client';
import { useChat } from 'ai/react';
export function ChatComponent() {
const { messages, input, handleInputChange, handleSubmit, isLoading } = useChat({
api: '/api/chat',
});
return (
<div className="flex flex-col h-screen">
{/* 消息列表 */}
<div className="flex-1 overflow-y-auto p-4">
{messages.map((message) => (
<div key={message.id} className={message.role === 'user' ? 'text-right' : 'text-left'}>
<div className="inline-block p-3 rounded-lg bg-gray-100">
{message.content}
</div>
</div>
))}
</div>
{/* 输入框 */}
<form onSubmit={handleSubmit} className="p-4 border-t">
<input
value={input}
onChange={handleInputChange}
placeholder="输入消息..."
disabled={isLoading}
className="w-full p-2 border rounded"
/>
</form>
</div>
);
}
---
b.Server Actions 集成
---
// app/actions/ai.ts
'use server';
import { generateText } from 'ai';
import { getLanguageModel } from '@repo/ai-core';
import { z } from 'zod';
/**
* AI 生成代码（Server Action）
*/
export async function generateCode(prompt: string) {
const result = await generateText({
model: getLanguageModel('glm-coding-plan'),
prompt: `你是一个代码生成助手，根据以下需求生成代码：\n\n${prompt}`,
});
return result.text;
}
/**
* AI 分析数据库结构
*/
export async function analyzeDatabase(tableName: string) {
// 读取数据库表结构（伪代码）
const tableMetadata = await getTableMetadata(tableName);
const result = await generateText({
model: getLanguageModel('glm-coding-plan'),
prompt: `分析以下数据库表结构，给出优化建议：\n\n${JSON.stringify(tableMetadata)}`,
});
return result.text;
}
---
b.MCP + Tool Calling
a.工具定义（Zod Schema）
---
// packages/ai-core/src/mcp/tools.ts
import { tool } from 'ai';
import { z } from 'zod';
/**
* 代码生成工具
*/
export const generateCodeTool = tool({
description: '生成代码（React 组件、API、数据库模型等）',
parameters: z.object({
type: z.enum(['component', 'api', 'model']).describe('代码类型'),
name: z.string().describe('名称，如 "UserList"'),
description: z.string().describe('功能描述'),
}),
execute: async ({ type, name, description }) => {
// 实现代码生成逻辑
switch (type) {
case 'component':
return generateReactComponent(name, description);
case 'api':
return generateAPIRoute(name, description);
case 'model':
return generatePrismaModel(name, description);
}
},
});
/**
* 数据库查询工具
*/
export const queryDatabaseTool = tool({
description: '查询数据库',
parameters: z.object({
sql: z.string().describe('SQL 查询语句'),
}),
execute: async ({ sql }) => {
// 安全检查：只允许 SELECT
if (!sql.trim().toUpperCase().startsWith('SELECT')) {
throw new Error('只允许 SELECT 查询');
}
// 执行查询
const prisma = getPrismaClient();
const result = await prisma.$queryRawUnsafe(sql);
return JSON.stringify(result);
},
});
/**
* 创建数据库表工具
*/
export const createTableTool = tool({
description: '创建数据库表（生成 Prisma Schema）',
parameters: z.object({
tableName: z.string().describe('表名'),
fields: z.array(
z.object({
name: z.string(),
type: z.enum(['String', 'Int', 'Boolean', 'DateTime', 'Float']),
optional: z.boolean(),
})
),
}),
execute: async ({ tableName, fields }) => {
// 生成 Prisma Schema
const schema = generatePrismaSchema(tableName, fields);
// 写入 schema.prisma 文件
await appendPrismaSchema(schema);
// 执行 migration
await executeMigration(tableName);
return `表 ${tableName} 创建成功`;
},
});
/**
* 文件读取工具
*/
export const readFileTool = tool({
description: '读取项目文件',
parameters: z.object({
filePath: z.string().describe('文件路径，相对于项目根目录'),
}),
execute: async ({ filePath }) => {
const fs = await import('fs/promises');
const path = await import('path');
const fullPath = path.join(process.cwd(), filePath);
const content = await fs.readFile(fullPath, 'utf-8');
return content;
},
});
/**
* 所有工具集合
*/
export const mcpTools = {
generateCode: generateCodeTool,
queryDatabase: queryDatabaseTool,
createTable: createTableTool,
readFile: readFileTool,
};
---
b.Tool Calling 使用示例
---
// app/api/chat/route.ts
import { streamText } from 'ai';
import { getLanguageModel } from '@repo/ai-core';
import { mcpTools } from '@repo/ai-core/mcp';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = await streamText({
model: getLanguageModel('glm-coding-plan'),
messages,
tools: mcpTools,
maxToolRoundtrips: 5,
});
return result.toAIStreamResponse();
}
---
a.用户交互示例
---
用户: 帮我创建一个用户表，包含姓名、邮箱、手机号
AI: 我来帮你创建用户表。
[调用工具: createTable]
{
"tableName": "User",
"fields": [
{"name": "name", "type": "String", "optional": false},
{"name": "email", "type": "String", "optional": false},
{"name": "phone", "type": "String", "optional": true}
]
}
[工具返回: 表 User 创建成功]
AI: ✅ 用户表创建完成！包含以下字段：
- name（姓名，必填）
- email（邮箱，必填）
- phone（手机号，可选）
是否需要我为这个表生成 CRUD API？
---
c.提示词命中率优化
---
// packages/ai-core/src/mcp/hit-rate-tracker.ts
interface ToolCallLog {
prompt: string;
expectedTool?: string;
actualTool: string;
success: boolean;
timestamp: Date;
}
class ToolCallHitRateTracker {
private logs: ToolCallLog[] = [];
/**
* 记录工具调用
*/
log(log: ToolCallLog) {
this.logs.push(log);
}
/**
* 计算命中率
*/
calculateHitRate(): number {
if (this.logs.length === 0) return 0;
const hits = this.logs.filter((log) => {
if (!log.expectedTool) return true; // 无预期工具，认为命中
return log.expectedTool === log.actualTool;
});
return (hits.length / this.logs.length) * 100;
}
/**
* 获取统计报告
*/
getReport() {
const hitRate = this.calculateHitRate();
const toolUsage = this.logs.reduce((acc, log) => {
acc[log.actualTool] = (acc[log.actualTool] || 0) + 1;
return acc;
}, {} as Record<string, number>);
return {
hitRate,
totalCalls: this.logs.length,
toolUsage,
};
}
}
export const hitRateTracker = new ToolCallHitRateTracker();
---
c.BaaS 能力
a.Prisma 自动 Schema 生成
---
// packages/database/src/generator.ts
/**
* 根据自然语言生成 Prisma Schema
*/
export async function generateSchemaFromNL(description: string): Promise<string> {
const result = await generateText({
model: getLanguageModel('glm-coding-plan'),
prompt: `
根据以下描述，生成 Prisma Schema：
描述：${description}
要求：
1. 使用正确的 Prisma 语法
2. 包含必要的字段（id, createdAt, updatedAt）
3. 设置合理的关系（如果需要）
只返回 Schema 代码，不要其他内容。
`,
});
return result.text;
}
/**
* 追加 Schema 到 schema.prisma
*/
export async function appendSchema(schema: string) {
const fs = await import('fs/promises');
const path = await import('path');
const schemaPath = path.join(process.cwd(), 'packages/database/prisma/schema.prisma');
await fs.appendFile(schemaPath, `\n\n${schema}`);
console.log('✅ Schema 已追加');
}
/**
* 执行 migration
*/
export async function migrate(name: string) {
const { exec } = await import('child_process');
const { promisify } = await import('util');
const execAsync = promisify(exec);
await execAsync(`cd packages/database && pnpm prisma migrate dev --name ${name}`);
console.log('✅ Migration 完成');
}
---
b.NextAuth.js 认证
---
// app/lib/auth.ts
import NextAuth from 'next-auth';
import Credentials from 'next-auth/providers/credentials';
import { prisma } from '@repo/database';
import { compare } from 'bcryptjs';
export const { handlers, auth, signIn, signOut } = NextAuth({
providers: [
Credentials({
credentials: {
email: { label: 'Email', type: 'email' },
password: { label: 'Password', type: 'password' },
},
authorize: async (credentials) => {
const user = await prisma.user.findUnique({
where: { email: credentials.email as string },
});
if (!user) return null;
const isValid = await compare(credentials.password as string, user.password);
if (!isValid) return null;
return {
id: user.id,
email: user.email,
name: user.name,
};
},
}),
],
session: {
strategy: 'jwt',
},
});
---
c.Server Actions CRUD
---
// app/actions/crud.ts
'use server';
import { prisma } from '@repo/database';
import { auth } from '@/lib/auth';
import { revalidatePath } from 'next/cache';
/**
* 创建记录（通用）
*/
export async function createRecord(model: string, data: any) {
const session = await auth();
if (!session) throw new Error('未登录');
// @ts-ignore
const result = await prisma[model].create({ data });
revalidatePath(`/${model}`);
return result;
}
/**
* 查询记录（通用）
*/
export async function queryRecords(model: string, where?: any) {
// @ts-ignore
const results = await prisma[model].findMany({ where });
return results;
}
/**
* 更新记录（通用）
*/
export async function updateRecord(model: string, id: string, data: any) {
const session = await auth();
if (!session) throw new Error('未登录');
// @ts-ignore
const result = await prisma[model].update({
where: { id },
data,
});
revalidatePath(`/${model}`);
return result;
}
/**
* 删除记录（通用）
*/
export async function deleteRecord(model: string, id: string) {
const session = await auth();
if (!session) throw new Error('未登录');
// @ts-ignore
await prisma[model].delete({ where: { id } });
revalidatePath(`/${model}`);
}
---
d.文件上传（Uploadthing）
---
// app/api/uploadthing/core.ts
import { createUploadthing, type FileRouter } from 'uploadthing/next';
const f = createUploadthing();
export const ourFileRouter = {
imageUploader: f({ image: { maxFileSize: '4MB' } })
.middleware(async () => {
const session = await auth();
if (!session) throw new Error('Unauthorized');
return { userId: session.user.id };
})
.onUploadComplete(async ({ metadata, file }) => {
console.log('Upload complete for userId:', metadata.userId);
console.log('file url', file.url);
}),
} satisfies FileRouter;
export type OurFileRouter = typeof ourFileRouter;
---
d.多前端方案
a.Web 应用（Next.js）
主应用已在上述架构中详细说明。
b.小程序（Taro）
---
// apps/miniapp/src/app.tsx
import { Component, PropsWithChildren } from 'react';
import { useChat } from '@repo/ai-core/hooks'; // 共享 Hook
class App extends Component<PropsWithChildren> {
render() {
return this.props.children;
}
}
export default App;
---
a.共享逻辑：
a.使用 @repo/ai-core 的 API 调用
b.使用 @repo/types 的类型定义
c.使用 @repo/utils 的工具函数
c.移动 APP（React Native）
---
// apps/mobile/src/App.tsx
import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import { HomeScreen } from './screens/Home';
const Stack = createNativeStackNavigator();
export default function App() {
return (
<NavigationContainer>
<Stack.Navigator>
<Stack.Screen name="Home" component={HomeScreen} />
</Stack.Navigator>
</NavigationContainer>
);
}
---
d.代码共享策略
---
┌─────────────────────────────────────┐
│ 应用层（UI） │
│ Next.js │ Taro │ RN │
│ 各自实现 各自实现 各自实现 │
└──────────┬──────────────────────────┘
│ 导入共享包
┌──────────┴──────────────────────────┐
│ 共享逻辑层（60%+ 代码） │
│ @repo/ai-core AI 调用 │
│ @repo/types TypeScript 类型 │
│ @repo/utils 工具函数 │
│ @repo/database 数据访问（Web only│
└─────────────────────────────────────┘
---
03.常用信息3
a.数据库设计
---
// packages/database/prisma/schema.prisma
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
// 用户表
model User {
id String @id @default(cuid())
email String @unique
name String?
password String
role Role @default(USER)
projects Project[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
enum Role {
USER
ADMIN
}
// 项目表
model Project {
id String @id @default(cuid())
name String
description String?
userId String
user User @relation(fields: [userId], references: [id])
models Model[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
// 数据模型表（AI 生成的）
model Model {
id String @id @default(cuid())
name String
schema Json // Prisma Schema JSON
projectId String
project Project @relation(fields: [projectId], references: [id])
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
// AI 对话历史
model Conversation {
id String @id @default(cuid())
userId String
messages Message[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
model Message {
id String @id @default(cuid())
role String // "user" | "assistant" | "system"
content String @db.Text
conversationId String
conversation Conversation @relation(fields: [conversationId], references: [id])
createdAt DateTime @default(now())
}
---
b.部署方案
a.Vercel 部署（推荐）
---
# 1. 安装 Vercel CLI
pnpm i -g vercel
# 2. 登录
vercel login
# 3. 部署
vercel
# 4. 生产部署
vercel --prod
---
a.优势：
a.零配置部署
b.自动 CI/CD
c.全球 CDN
d.Server Actions 原生支持
b.Docker 自托管
---
# Dockerfile
FROM oven/bun:latest AS base
# 安装依赖
FROM base AS deps
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN bun install --frozen-lockfile
# 构建
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN bun run build
# 运行
FROM base AS runner
WORKDIR /app
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
ENV PORT 3000
EXPOSE 3000
CMD ["bun", "server.js"]
---
---
# docker-compose.yml
version: '3.8'
services:
postgres:
image: postgres:15-alpine
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: aipexbase
volumes:
- postgres-data:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
- redis-data:/data
new-api:
image: calciumion/new-api:latest
ports:
- "3001:3000"
depends_on:
- redis
app:
build: ./apps/web
ports:
- "3000:3000"
depends_on:
- postgres
- redis
- new-api
environment:
DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@postgres:5432/aipexbase
AI_GATEWAY_URL: http://new-api:3000/v1
volumes:
postgres-data:
redis-data:
3.5 [2]golang版本
01.常见信息1
a.项目概述
a.项目定位
高性能 AI 原生 BaaS 平台（Go 版）
目标用户：高并发场景、性能敏感应用、需要极致性能的产品
核心价值：高并发性能、低资源消耗、单二进制部署、运维简单
技术特点：Go 原生并发、参考 ccNexus/New-API 成熟实践
b.差异化优势
维度 Java 版 Next.js 版 Go 版 ⭐
性能 ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
并发能力 ⭐⭐⭐⭐ 线程 ⭐⭐⭐ 单线程 ⭐⭐⭐⭐⭐ Goroutine
资源消耗 ⭐⭐⭐ 高 ⭐⭐⭐⭐ 中 ⭐⭐⭐⭐⭐ 低
部署难度 ⭐⭐⭐ 需 JVM ⭐⭐⭐⭐ 需 Node ⭐⭐⭐⭐⭐ 单二进制
启动速度 ⭐⭐ 慢 ⭐⭐⭐⭐ 快 ⭐⭐⭐⭐⭐ 极快
内存占用 500MB+ 200MB+ 50MB+
c.项目目标
参考成熟项目：学习 ccNexus、New-API 的 Go 实践
极致性能：充分利用 Go 的并发能力和性能优势
简化部署：单二进制文件，无依赖，开箱即用
保持一致性：实现与 Java/Next.js 版本相同的 BaaS 能力
b.技术架构
a.整体架构图
---
┌─────────────────────────────────────────────────────────────┐
│ 前端层（Multi-Frontend） │
├─────────────────────────────────────────────────────────────┤
│ React 18 / Vue 3（单页应用） │
│ 或 uni-app（多端） │
└──────────────┬──────────────────────────────────────────────┘
│ HTTP/WebSocket API
┌──────────────┴──────────────────────────────────────────────┐
│ Go 后端层（High Performance） │
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────┐ │
│ │ HTTP 层（Fiber/Gin） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • RESTful API │ │
│ │ • WebSocket（实时通信） │ │
│ │ • 中间件（认证、日志、限流） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 业务逻辑层（Service Layer） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • AI Service（MCP 集成、Tool Calling） │ │
│ │ • User Service（用户管理） │ │
│ │ • Project Service（项目管理） │ │
│ │ • Code Generator Service（代码生成） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据访问层（Repository Layer） │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ • GORM（ORM） │ │
│ │ • Redis（缓存） │ │
│ │ • 连接池管理 │ │
│ └─────────────────────────────────────────────────────┘ │
└──────────────┬──────────────────────────────────────────────┘
│
┌──────────────┴──────────────────────────────────────────────┐
│ AI 网关层（Gateway Integration） │
├─────────────────────────────────────────────────────────────┤
│ ccNexus（可选）→ New-API → AI Providers │
│ 智能路由 Coding Plan GLM/Kimi/豆包 │
└──────────────┬──────────────────────────────────────────────┘
│
┌──────────────┴──────────────────────────────────────────────┐
│ 数据层（Data Layer） │
├─────────────────────────────────────────────────────────────┤
│ PostgreSQL / MySQL Redis 7.0 MinIO（文件存储） │
└─────────────────────────────────────────────────────────────┘
---
b.项目结构
---
go-ai-platform/
├── cmd/
│ └── server/
│ └── main.go # 入口文件
├── internal/
│ ├── api/ # API 层
│ │ ├── router/
│ │ │ └── router.go # 路由配置
│ │ ├── handler/ # HTTP 处理器
│ │ │ ├── auth.go
│ │ │ ├── user.go
│ │ │ ├── ai.go
│ │ │ └── project.go
│ │ └── middleware/ # 中间件
│ │ ├── auth.go
│ │ ├── cors.go
│ │ └── ratelimit.go
│ ├── service/ # 业务逻辑层
│ │ ├── ai_service.go # AI 服务
│ │ ├── mcp_service.go # MCP 协议
│ │ ├── user_service.go
│ │ └── code_generator.go # 代码生成
│ ├── repository/ # 数据访问层
│ │ ├── user_repo.go
│ │ ├── project_repo.go
│ │ └── conversation_repo.go
│ ├── model/ # 数据模型
│ │ ├── user.go
│ │ ├── project.go
│ │ └── conversation.go
│ ├── pkg/ # 内部包
│ │ ├── database/ # 数据库连接
│ │ ├── redis/ # Redis 连接
│ │ ├── ai_client/ # AI 客户端
│ │ │ ├── client.go
│ │ │ ├── openai.go
│ │ │ └── coding_plan.go
│ │ └── utils/ # 工具函数
│ └── config/ # 配置
│ └── config.go
├── web/ # 前端代码（React/Vue）
│ ├── src/
│ ├── public/
│ └── package.json
├── migrations/ # 数据库迁移
├── scripts/ # 脚本
├── go.mod
├── go.sum
├── Dockerfile
└── README.md
---
c.技术栈详细清单
---
// go.mod
module github.com/yourusername/go-ai-platform
go 1.21
require (
// Web 框架
github.com/gofiber/fiber/v2 v2.52.0 // 或 Gin
github.com/gofiber/websocket/v2 v2.2.1 // WebSocket
// 数据库
gorm.io/gorm v1.25.5
gorm.io/driver/postgres v1.5.4 // PostgreSQL
gorm.io/driver/mysql v1.5.2 // MySQL
// Redis
github.com/redis/go-redis/v9 v9.3.0
// HTTP 客户端
github.com/go-resty/resty/v2 v2.11.0
// JSON
github.com/goccy/go-json v0.10.2
// 配置
github.com/spf13/viper v1.18.2
// 日志
github.com/sirupsen/logrus v1.9.3
// JWT
github.com/golang-jwt/jwt/v5 v5.2.0
// 密码加密
golang.org/x/crypto v0.18.0
// UUID
github.com/google/uuid v1.5.0
// 工具
github.com/samber/lo v1.39.0 // 函数式编程工具
)
---
c.New-API/ccNexus 集成
a.HTTP 客户端封装
---
// internal/pkg/ai_client/client.go
package ai_client
import (
"context"
"fmt"
"github.com/go-resty/resty/v2"
"time"
)
type AIClient struct {
baseURL string
apiKey string
client *resty.Client
}
func NewAIClient(baseURL, apiKey string) *AIClient {
client := resty.New()
client.SetTimeout(60 * time.Second)
client.SetRetryCount(3)
client.SetRetryWaitTime(1 * time.Second)
return &AIClient{
baseURL: baseURL,
apiKey: apiKey,
client: client,
}
}
// ChatCompletionRequest 聊天补全请求
type ChatCompletionRequest struct {
Model string `json:"model"`
Messages []Message `json:"messages"`
Stream bool `json:"stream"`
Tools []Tool `json:"tools,omitempty"`
}
type Message struct {
Role string `json:"role"`
Content string `json:"content"`
}
type Tool struct {
Type string `json:"type"`
Function Function `json:"function"`
}
type Function struct {
Name string `json:"name"`
Description string `json:"description"`
Parameters interface{} `json:"parameters"`
}
// ChatCompletionResponse 聊天补全响应
type ChatCompletionResponse struct {
ID string `json:"id"`
Choices []Choice `json:"choices"`
Usage Usage `json:"usage"`
}
type Choice struct {
Index int `json:"index"`
Message Message `json:"message"`
FinishReason string `json:"finish_reason"`
}
type Usage struct {
PromptTokens int `json:"prompt_tokens"`
CompletionTokens int `json:"completion_tokens"`
TotalTokens int `json:"total_tokens"`
}
// ChatCompletion 非流式调用
func (c *AIClient) ChatCompletion(ctx context.Context, req ChatCompletionRequest) (*ChatCompletionResponse, error) {
var resp ChatCompletionResponse
_, err := c.client.R().
SetContext(ctx).
SetHeader("Authorization", "Bearer "+c.apiKey).
SetHeader("Content-Type", "application/json").
SetBody(req).
SetResult(&resp).
Post(c.baseURL + "/chat/completions")
if err != nil {
return nil, fmt.Errorf("AI API 调用失败: %w", err)
}
return &resp, nil
}
// ChatCompletionStream 流式调用
func (c *AIClient) ChatCompletionStream(
ctx context.Context,
req ChatCompletionRequest,
onChunk func(string),
) error {
req.Stream = true
resp, err := c.client.R().
SetContext(ctx).
SetHeader("Authorization", "Bearer "+c.apiKey).
SetHeader("Content-Type", "application/json").
SetBody(req).
SetDoNotParseResponse(true).
Post(c.baseURL + "/chat/completions")
if err != nil {
return fmt.Errorf("流式请求失败: %w", err)
}
defer resp.RawBody().Close()
// 处理 SSE 流
scanner := bufio.NewScanner(resp.RawBody())
for scanner.Scan() {
line := scanner.Text()
if strings.HasPrefix(line, "data: ") {
data := strings.TrimPrefix(line, "data: ")
if data == "[DONE]" {
break
}
var chunk struct {
Choices []struct {
Delta struct {
Content string `json:"content"`
} `json:"delta"`
} `json:"choices"`
}
if err := json.Unmarshal([]byte(data), &chunk); err != nil {
continue
}
if len(chunk.Choices) > 0 && chunk.Choices[0].Delta.Content != "" {
onChunk(chunk.Choices[0].Delta.Content)
}
}
}
return scanner.Err()
}
---
b.Coding Plan 管理
---
// internal/pkg/ai_client/coding_plan.go
package ai_client
import (
"context"
"fmt"
)
var CodingPlanModels = []string{
"glm-coding-plan", // 智谱 GLM（免费）
"kimi-coding-plan", // Kimi（低价）
"doubao-coding-plan", // 豆包（低价）
}
// SelectModel 智能选择模型
func SelectModel(taskComplexity int) string {
if taskComplexity <= 3 {
return "glm-coding-plan"
}
if taskComplexity <= 7 {
if rand.Float32() > 0.5 {
return "kimi-coding-plan"
}
return "doubao-coding-plan"
}
return "gpt-4"
}
// CallWithFallback 带降级的调用
func (c *AIClient) CallWithFallback(ctx context.Context, prompt string) (*ChatCompletionResponse, error) {
for _, model := range CodingPlanModels {
req := ChatCompletionRequest{
Model: model,
Messages: []Message{
{Role: "user", Content: prompt},
},
}
resp, err := c.ChatCompletion(ctx, req)
if err == nil {
return resp, nil
}
fmt.Printf("模型 %s 调用失败，尝试下一个\n", model)
}
return nil, fmt.Errorf("所有 Coding Plan 模型均调用失败")
}
---
c.连接池管理
---
// internal/pkg/ai_client/pool.go
package ai_client
import (
"sync"
)
type ClientPool struct {
clients []*AIClient
index int
mu sync.Mutex
}
func NewClientPool(configs []Config) *ClientPool {
clients := make([]*AIClient, len(configs))
for i, cfg := range configs {
clients[i] = NewAIClient(cfg.BaseURL, cfg.APIKey)
}
return &ClientPool{
clients: clients,
}
}
// GetClient 轮询获取客户端
func (p *ClientPool) GetClient() *AIClient {
p.mu.Lock()
defer p.mu.Unlock()
client := p.clients[p.index]
p.index = (p.index + 1) % len(p.clients)
return client
}
---
02.常见信息2
a.MCP 协议实现
a.MCP Service
---
// internal/service/mcp_service.go
package service
import (
"context"
"encoding/json"
"fmt"
"github.com/yourusername/go-ai-platform/internal/pkg/ai_client"
)
type MCPService struct {
aiClient *ai_client.AIClient
}
func NewMCPService(aiClient *ai_client.AIClient) *MCPService {
return &MCPService{
aiClient: aiClient,
}
}
// Tool 工具定义
type Tool struct {
Name string `json:"name"`
Description string `json:"description"`
Parameters interface{} `json:"parameters"`
Handler ToolHandler
}
type ToolHandler func(args map[string]interface{}) (string, error)
// 工具注册表
var tools = map[string]Tool{
"generate_code": {
Name: "generate_code",
Description: "生成代码",
Parameters: map[string]interface{}{
"type": "object",
"properties": map[string]interface{}{
"codeType": map[string]interface{}{
"type": "string",
"enum": []string{"model", "handler", "service"},
},
"name": map[string]interface{}{
"type": "string",
},
},
"required": []string{"codeType", "name"},
},
Handler: generateCodeHandler,
},
"query_database": {
Name: "query_database",
Description: "查询数据库",
Parameters: map[string]interface{}{
"type": "object",
"properties": map[string]interface{}{
"sql": map[string]interface{}{
"type": "string",
},
},
"required": []string{"sql"},
},
Handler: queryDatabaseHandler,
},
}
// CallTool 调用工具
func (s *MCPService) CallTool(ctx context.Context, userPrompt string) (string, error) {
// 1. 构建请求
aiTools := make([]ai_client.Tool, 0, len(tools))
for _, tool := range tools {
aiTools = append(aiTools, ai_client.Tool{
Type: "function",
Function: ai_client.Function{
Name: tool.Name,
Description: tool.Description,
Parameters: tool.Parameters,
},
})
}
req := ai_client.ChatCompletionRequest{
Model: "glm-coding-plan",
Messages: []ai_client.Message{
{Role: "system", Content: "你是一个代码助手，可以使用工具完成任务。"},
{Role: "user", Content: userPrompt},
},
Tools: aiTools,
}
// 2. 调用 AI
resp, err := s.aiClient.ChatCompletion(ctx, req)
if err != nil {
return "", err
}
// 3. 检查是否调用了工具
message := resp.Choices[0].Message
if len(message.ToolCalls) > 0 {
toolCall := message.ToolCalls[0]
// 4. 执行工具
tool := tools[toolCall.Function.Name]
var args map[string]interface{}
json.Unmarshal([]byte(toolCall.Function.Arguments), &args)
result, err := tool.Handler(args)
if err != nil {
return "", fmt.Errorf("工具执行失败: %w", err)
}
// 5. 返回结果给 AI
followUpReq := ai_client.ChatCompletionRequest{
Model: "glm-coding-plan",
Messages: []ai_client.Message{
{Role: "system", Content: "你是一个代码助手。"},
{Role: "user", Content: userPrompt},
message,
{Role: "tool", Content: result, Name: toolCall.Function.Name},
},
}
followUpResp, err := s.aiClient.ChatCompletion(ctx, followUpReq)
if err != nil {
return "", err
}
return followUpResp.Choices[0].Message.Content, nil
}
return message.Content, nil
}
// 工具处理函数
func generateCodeHandler(args map[string]interface{}) (string, error) {
codeType := args["codeType"].(string)
name := args["name"].(string)
// 生成代码逻辑
code := fmt.Sprintf("// Generated %s: %s\n", codeType, name)
switch codeType {
case "model":
code += generateGoModel(name)
case "handler":
code += generateGoHandler(name)
case "service":
code += generateGoService(name)
}
return code, nil
}
func queryDatabaseHandler(args map[string]interface{}) (string, error) {
sql := args["sql"].(string)
// 安全检查
if !strings.HasPrefix(strings.ToUpper(sql), "SELECT") {
return "", fmt.Errorf("只允许 SELECT 查询")
}
// 执行查询（伪代码）
db := getDB()
var results []map[string]interface{}
db.Raw(sql).Scan(&results)
jsonData, _ := json.Marshal(results)
return string(jsonData), nil
}
---
b.代码生成模版
---
// internal/service/code_generator.go
package service
import (
"fmt"
"strings"
)
// generateGoModel 生成 GORM Model
func generateGoModel(name string) string {
return fmt.Sprintf(`
type %s struct {
ID uint %s
CreatedAt time.Time
UpdatedAt time.Time
DeletedAt gorm.DeletedAt %s
}
`, name, "`gorm:\"primarykey\"`", "`gorm:\"index\"`")
}
// generateGoHandler 生成 Fiber Handler
func generateGoHandler(name string) string {
lower := strings.ToLower(name)
return fmt.Sprintf(`
// %sHandler
type %sHandler struct {
service *%sService
}
func New%sHandler(service *%sService) *%sHandler {
return &%sHandler{service: service}
}
// List 列表
func (h *%sHandler) List(c *fiber.Ctx) error {
items, err := h.service.List(c.Context())
if err != nil {
return c.Status(500).JSON(fiber.Map{"error": err.Error()})
}
return c.JSON(items)
}
// Create 创建
func (h *%sHandler) Create(c *fiber.Ctx) error {
var req Create%sRequest
if err := c.BodyParser(&req); err != nil {
return c.Status(400).JSON(fiber.Map{"error": err.Error()})
}
item, err := h.service.Create(c.Context(), &req)
if err != nil {
return c.Status(500).JSON(fiber.Map{"error": err.Error()})
}
return c.Status(201).JSON(item)
}
`, name, name, name, name, name, name, name, name, name, name)
}
// generateGoService 生成 Service
func generateGoService(name string) string {
return fmt.Sprintf(`
// %sService
type %sService struct {
repo *%sRepository
}
func New%sService(repo *%sRepository) *%sService {
return &%sService{repo: repo}
}
// List 查询列表
func (s *%sService) List(ctx context.Context) ([]*%s, error) {
return s.repo.FindAll(ctx)
}
// Create 创建
func (s *%sService) Create(ctx context.Context, req *Create%sRequest) (*%s, error) {
item := &%s{
// 字段映射
}
return s.repo.Create(ctx, item)
}
`, name, name, name, name, name, name, name, name, name, name, name, name, name)
}
---
b.BaaS 能力
a.GORM 自动迁移
---
// internal/pkg/database/database.go
package database
import (
"fmt"
"gorm.io/driver/postgres"
"gorm.io/gorm"
"gorm.io/gorm/logger"
)
func InitDB(dsn string) (*gorm.DB, error) {
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
Logger: logger.Default.LogMode(logger.Info),
})
if err != nil {
return nil, fmt.Errorf("连接数据库失败: %w", err)
}
// 自动迁移
if err := autoMigrate(db); err != nil {
return nil, fmt.Errorf("自动迁移失败: %w", err)
}
return db, nil
}
func autoMigrate(db *gorm.DB) error {
return db.AutoMigrate(
&model.User{},
&model.Project{},
&model.Conversation{},
&model.Message{},
// 添加其他模型...
)
}
---
b.JWT 认证
---
// internal/api/middleware/auth.go
package middleware
import (
"github.com/gofiber/fiber/v2"
"github.com/golang-jwt/jwt/v5"
"strings"
"time"
)
var jwtSecret = []byte("your-secret-key")
type Claims struct {
UserID uint `json:"user_id"`
Email string `json:"email"`
jwt.RegisteredClaims
}
// GenerateToken 生成 JWT
func GenerateToken(userID uint, email string) (string, error) {
claims := Claims{
UserID: userID,
Email: email,
RegisteredClaims: jwt.RegisteredClaims{
ExpiresAt: jwt.NewNumericDate(time.Now().Add(24 * time.Hour)),
IssuedAt: jwt.NewNumericDate(time.Now()),
},
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
return token.SignedString(jwtSecret)
}
// AuthMiddleware 认证中间件
func AuthMiddleware() fiber.Handler {
return func(c *fiber.Ctx) error {
authHeader := c.Get("Authorization")
if authHeader == "" {
return c.Status(401).JSON(fiber.Map{"error": "未提供认证信息"})
}
tokenString := strings.TrimPrefix(authHeader, "Bearer ")
claims := &Claims{}
token, err := jwt.ParseWithClaims(tokenString, claims, func(token *jwt.Token) (interface{}, error) {
return jwtSecret, nil
})
if err != nil || !token.Valid {
return c.Status(401).JSON(fiber.Map{"error": "无效的令牌"})
}
c.Locals("userID", claims.UserID)
c.Locals("email", claims.Email)
return c.Next()
}
}
---
c.CRUD Repository 模式
---
// internal/repository/base_repository.go
package repository
import (
"context"
"gorm.io/gorm"
)
type BaseRepository[T any] struct {
db *gorm.DB
}
func NewBaseRepository[T any](db *gorm.DB) *BaseRepository[T] {
return &BaseRepository[T]{db: db}
}
// FindAll 查询所有
func (r *BaseRepository[T]) FindAll(ctx context.Context) ([]*T, error) {
var items []*T
err := r.db.WithContext(ctx).Find(&items).Error
return items, err
}
// FindByID 根据 ID 查询
func (r *BaseRepository[T]) FindByID(ctx context.Context, id uint) (*T, error) {
var item T
err := r.db.WithContext(ctx).First(&item, id).Error
return &item, err
}
// Create 创建
func (r *BaseRepository[T]) Create(ctx context.Context, item *T) error {
return r.db.WithContext(ctx).Create(item).Error
}
// Update 更新
func (r *BaseRepository[T]) Update(ctx context.Context, item *T) error {
return r.db.WithContext(ctx).Save(item).Error
}
// Delete 删除
func (r *BaseRepository[T]) Delete(ctx context.Context, id uint) error {
var item T
return r.db.WithContext(ctx).Delete(&item, id).Error
}
---
d.MinIO 文件存储
---
// internal/service/file_service.go
package service
import (
"context"
"fmt"
"github.com/minio/minio-go/v7"
"github.com/minio/minio-go/v7/pkg/credentials"
"io"
)
type FileService struct {
minioClient *minio.Client
bucketName string
}
func NewFileService(endpoint, accessKey, secretKey, bucket string) (*FileService, error) {
client, err := minio.New(endpoint, &minio.Options{
Creds: credentials.NewStaticV4(accessKey, secretKey, ""),
Secure: false,
})
if err != nil {
return nil, err
}
return &FileService{
minioClient: client,
bucketName: bucket,
}, nil
}
// Upload 上传文件
func (s *FileService) Upload(ctx context.Context, fileName string, reader io.Reader, size int64) (string, error) {
_, err := s.minioClient.PutObject(ctx, s.bucketName, fileName, reader, size, minio.PutObjectOptions{})
if err != nil {
return "", err
}
return fmt.Sprintf("http://localhost:9000/%s/%s", s.bucketName, fileName), nil
}
// Download 下载文件
func (s *FileService) Download(ctx context.Context, fileName string) (io.ReadCloser, error) {
return s.minioClient.GetObject(ctx, s.bucketName, fileName, minio.GetObjectOptions{})
}
---
c.前端方案
a.技术栈选择
a.推荐
React 18 + Vite
b.web/package.json
---
{
"name": "go-ai-platform-web",
"dependencies": {
"react": "^18.3.0",
"react-dom": "^18.3.0",
"react-router-dom": "^6.21.0",
"@tanstack/react-query": "^5.17.0",
"axios": "^1.6.5",
"@radix-ui/react-dialog": "^1.0.5",
"tailwindcss": "^3.4.0",
"lucide-react": "^0.344.0"
},
"devDependencies": {
"@vitejs/plugin-react": "^4.2.1",
"vite": "^5.0.11",
"typescript": "^5.3.3"
}
}
---
b.前后端通信
a.web/src/api/client.ts
---
import axios from 'axios';
const apiClient = axios.create({
baseURL: import.meta.env.VITE_API_URL || 'http://localhost:8080/api',
timeout: 60000,
});
// 请求拦截器
apiClient.interceptors.request.use((config) => {
const token = localStorage.getItem('token');
if (token) {
config.headers.Authorization = `Bearer ${token}`;
}
return config;
});
// 响应拦截器
apiClient.interceptors.response.use(
(response) => response.data,
(error) => {
if (error.response?.status === 401) {
localStorage.removeItem('token');
window.location.href = '/login';
}
return Promise.reject(error);
}
);
export default apiClient;
---
b.web/src/api/ai.ts
---
import apiClient from './client';
export const chatAPI = {
// 发送消息（流式）
streamChat: async (message: string, onChunk: (chunk: string) => void) => {
const response = await fetch('http://localhost:8080/api/chat/stream', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: `Bearer ${localStorage.getItem('token')}`,
},
body: JSON.stringify({ message }),
});
const reader = response.body?.getReader();
const decoder = new TextDecoder();
while (true) {
const { done, value } = await reader!.read();
if (done) break;
const chunk = decoder.decode(value);
onChunk(chunk);
}
},
// 生成代码
generateCode: (prompt: string) =>
apiClient.post('/ai/generate-code', { prompt }),
};
---
03.常用信息3
a.数据库设计
---
// internal/model/user.go
package model
import (
"gorm.io/gorm"
"time"
)
type User struct {
ID uint `gorm:"primarykey" json:"id"`
Email string `gorm:"uniqueIndex;not null" json:"email"`
Name string `json:"name"`
Password string `gorm:"not null" json:"-"`
Role string `gorm:"default:user" json:"role"`
Projects []Project `gorm:"foreignKey:UserID" json:"projects,omitempty"`
CreatedAt time.Time `json:"created_at"`
UpdatedAt time.Time `json:"updated_at"`
DeletedAt gorm.DeletedAt `gorm:"index" json:"-"`
}
// internal/model/project.go
type Project struct {
ID uint `gorm:"primarykey" json:"id"`
Name string `gorm:"not null" json:"name"`
Description string `json:"description"`
UserID uint `gorm:"not null" json:"user_id"`
User User `gorm:"foreignKey:UserID" json:"user,omitempty"`
Models []DataModel `gorm:"foreignKey:ProjectID" json:"models,omitempty"`
CreatedAt time.Time `json:"created_at"`
UpdatedAt time.Time `json:"updated_at"`
DeletedAt gorm.DeletedAt `gorm:"index" json:"-"`
}
// internal/model/conversation.go
type Conversation struct {
ID uint `gorm:"primarykey" json:"id"`
UserID uint `gorm:"not null" json:"user_id"`
Messages []Message `gorm:"foreignKey:ConversationID" json:"messages,omitempty"`
CreatedAt time.Time `json:"created_at"`
UpdatedAt time.Time `json:"updated_at"`
DeletedAt gorm.DeletedAt `gorm:"index" json:"-"`
}
type Message struct {
ID uint `gorm:"primarykey" json:"id"`
Role string `gorm:"not null" json:"role"`
Content string `gorm:"type:text;not null" json:"content"`
ConversationID uint `gorm:"not null" json:"conversation_id"`
CreatedAt time.Time `json:"created_at"`
}
---
b.单二进制部署方案
a.编译
---
# Linux
GOOS=linux GOARCH=amd64 go build -o bin/server-linux cmd/server/main.go
# Windows
GOOS=windows GOARCH=amd64 go build -o bin/server.exe cmd/server/main.go
# macOS
GOOS=darwin GOARCH=amd64 go build -o bin/server-mac cmd/server/main.go
# 减小体积（去除调试信息）
go build -ldflags="-s -w" -o bin/server cmd/server/main.go
# 使用 UPX 压缩（可选）
upx --best --lzma bin/server
---
b.配置文件
---
# config.yaml
server:
port: 8080
mode: production
database:
driver: postgres
host: localhost
port: 5432
database: aipexbase
username: postgres
password: password
redis:
host: localhost
port: 6379
password: ""
db: 0
ai:
gateway_url: http://localhost:3001/v1
api_key: sk-your-key
minio:
endpoint: localhost:9000
access_key: minioadmin
secret_key: minioadmin
bucket: files
---
c.启动脚本
---
#!/bin/bash
# start.sh
# 设置环境变量
export GIN_MODE=release
# 启动服务器
./server -config config.yaml
# 或者使用 systemd
# sudo systemctl start go-ai-platform
---
d.systemd 服务
---
# /etc/systemd/system/go-ai-platform.service
[Unit]
Description=Go AI Platform
After=network.target
[Service]
Type=simple
User=app
WorkingDirectory=/opt/go-ai-platform
ExecStart=/opt/go-ai-platform/server -config /opt/go-ai-platform/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target
---
e.Docker 部署
---
# Dockerfile
FROM golang:1.21-alpine AS builder
WORKDIR /build
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o server cmd/server/main.go
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /app
COPY --from=builder /build/server .
COPY config.yaml .
EXPOSE 8080
CMD ["./server", "-config", "config.yaml"]
---
3.6 [3]三层架构
00.思路
AI，调用MCP -> 决策，模板层 -> 生成部署
01.API层
a.统一网关
a.new-api，保持未来性
多提供商支持：OpenAI、Claude、Gemini、DeepSeek、GLM、Kimi、豆包等 30+ 模型
统一接口：OpenAI 兼容 API，只需修改 baseURL 即可切换
负载均衡：多 API Key 自动轮换和负载均衡
使用统计：Token 使用统计、成本分析、请求日志
商业化功能：用户管理、在线支付、套餐管理
b.支持的 Coding Plan
提供商 模型标识 特点 额度
智谱 GLM glm-coding-plan 完全免费，128K 上下文 新用户 2 并发（可申请提升）
Kimi kimi-coding-plan 低价计划 按量计费
字节豆包 doubao-coding-plan 低价计划 按量计费
b.故障转移
a.ccNexus
Claude Code 专用的智能 API 网关，提供端点轮换、使用监控和格式转换。
b.技术特点
语言：Go
GUI框架：Wails v2（跨平台桌面应用）
平台支持：Windows 10+, macOS 10.15+, Linux (GTK3)
c.核心功能
多端点管理：配置多个 API 端点，自动故障转移
API 格式转换：Claude ⇄ OpenAI ⇄ Gemini 格式互转
使用统计：实时监控请求、错误和 token 使用情况
数据安全：所有数据本地存储在 ~/.ccNexus/ 目录
多主题支持：12 种主题（Light、Dark、Cyberpunk 等）
02.模板层
a.隐藏思考链
a.智能会话
-> 编程智能体
-> 自动调用工具执行编程任务
-> 智能问答
-> 实时技术问答支持
-> Java Chat
-> 工程分析、代码重构/优化
b.引导式生成完整项目
-> 引导式开发拆解任务
-> 需求理解→接口设计→表结构设计→业务逻辑生成
-> 生成完整工程源码
-> 逐层生成→实时预览→逐一确认
c.AI工具箱
-> 覆盖全周期的提效工具矩阵
-> SQL Chat
-> 自然语言转SQL，数据库操作提效
d.SQL
-> 深度学习用户偏好
-> 技术栈 | 分层架构 | 代码规范 | 安全规范
e.通用
-> 智能分析现有项目
-> 全量代码语义索引 | 上下文强关联分析
b.为什么隐藏思考链？
对话SQL、对话CRUD，效果不理想
03.应用端
a.后端
a.框架
ssm单体架构、springboot单体架构、springcloud微服务架构
ruoyi-vue-pro、gin-vue-admin
b.主系统
权限（PC+MINI）、支付+短信+存储、CRUD
c.MCP
1.选用Velocity，VM模板（SQL表结构 + CRUD逻辑 + VIEW视图）
2.生成一整套系统
b.前端
a.电脑端
用户端（B端、C端）
管理端
b.移动端
TOB，商户
TOC，用户
c.部署
a.证书
caddy反代
b.容器化
内网、外网，端口现在随机，系统环境隔离，基于docker
3.7 [3]后端设计
00.思路
+----------------------+ +---------------------------------+
| 新建会话 | | 多轮对话 |
| 结构化描述需求 | ----------------------------------> | 继续优化/更新需求 |
+----------------------+ +---------------------------------+
| ^ |
| | (否) |
v | v
+----------------------+ +---------------------+ +------------------------+
| 智能关联上下文 | | 是否符合预期 | <--- | 查看生成内容 |
+----------------------+ +---------------------+ +------------------------+
| | (是) ^
v v |
+----------------------+ +-------------------------+ |
| 解析上下文内容 | | 局部/批量接受代码变更 | |
+----------------------+ +-------------------------+ |
| | |
v v |
+----------------------+ +-------------------------+ |
| 拆解任务 | | 完成代码融合 | |
+----------------------+ +-------------------------+ |
| | |
v v |
+----------------------+ +----------------------+ +-------------------------+ |
| 多文件关联修改 | ----> | 编码实现 | | 需求更新 | -----------+
+----------------------+ +----------------------+ +-------------------------+
| ^
| |
v |
+-----------------------------+ |
| 生成代码变更对比视图 | -------------------+
+-----------------------------+
01.代码生成流程
1.用户输入（或 AI 生成）数据库表结构
↓
2.解析表结构，提取元数据
- 表名、注释
- 字段名、类型、注释
- 主键、索引
↓
3.填充 VM 模版上下文
VelocityContext context = new VelocityContext();
context.put("package", "com.example.project");
context.put("className", "User");
context.put("table", tableMetadata);
context.put("columns", columns);
↓
4.Velocity 引擎渲染模版
Template template = velocityEngine.getTemplate("Entity.java.vm");
StringWriter writer = new StringWriter();
template.merge(context, writer);
↓
5.生成代码文件
- Entity.java
- Mapper.java
- Mapper.xml
- Service.java
- ServiceImpl.java
- Controller.java
- list.vue
- edit.vue
↓
6.可选：AI 优化生成的代码
- 通过 MCP 调用 AI 审查代码
- 优化业务逻辑
- 添加注释和文档
02.AI 增强的 VM 模版
/**
* AI 增强的代码生成器
*/
public class AIEnhancedCodeGenerator {
@Autowired
private MCPService mcpService;
/**
* 生成代码（AI 增强版）
*/
public GenerateResult generate(TableMetadata table, String userIntent) {
// 1. 传统 VM 模版生成基础代码
Map<String, String> baseCode = velocityGenerate(table);
// 2. AI 理解用户意图，优化代码
String optimizedEntity = mcpService.callTool("optimize_code", Map.of(
"code", baseCode.get("Entity.java"),
"intent", userIntent,
"context", "这是一个" + table.getComment() + "的实体类"
));
// 3. AI 生成业务逻辑
String businessLogic = mcpService.callTool("generate_business_logic", Map.of(
"table", table,
"intent", userIntent
));
// 4. 合并结果
return GenerateResult.builder()
.entity(optimizedEntity)
.service(baseCode.get("Service.java") + businessLogic)
.controller(baseCode.get("Controller.java"))
.vue(baseCode.get("list.vue"))
.build();
}
}
03.配置YML化
libra:
# ---------------------------------------------------------------
# 框架层 MyBatis 配置扩展点 (Framework MyBatis Configuration)
# ===============================================================
mybatis:
# MyBatis-Plus 拦截器配置（框架层默认：分页 + 乐观锁 + 阻断插件）
mybatis-plus-interceptor:
enabled: true # ✅ 启用框架层默认实现
enable-pagination: true # ✅ 启用分页插件
enable-optimistic-locker: true # ✅ 启用乐观锁插件（需要实体类使用@Version注解）
enable-block-attack: true # ✅ 启用阻断全表更新与删除插件
# AutoFill 拦截器配置（框架层默认：XML 自定义方法自动填充）
auto-fill-interceptor:
enabled: true # ✅ 启用框架层默认实现
# MetaObjectHandler 配置（框架层默认：BaseMapper 方法自动填充）
meta-object-handler:
enabled: true # ✅ 启用框架层默认实现
3.8 [3]前端设计
00.思路
┌─────────────────────────────────────────────┐
│ 用户输入提示词 │
│ "创建一个用户管理页面" │
│ "我要做一个电商系统" │
└──────────────────┬──────────────────────────┘
│
┌───────┴───────┐
│ 意图识别引擎 │
│ (简单/复杂IF) │
└───────┬───────┘
│
┌─────────┴──────────┐
│ │
【简单场景】 【复杂场景】
│ │
┌────▼─────┐ ┌────▼──────┐
│ 模板模式 │ │ 创作模式 │
└────┬─────┘ └────┬──────┘
│ │
│ │
[详细流程见下] [详细流程见下]
01.模板模式
步骤 1: 用户输入
↓
"创建一个用户列表页"
"做一个登录注册功能"
"生成数据表格"
步骤 2: 简单 IF 判断
↓
if (意图清晰 && 场景常见) {
进入模板模式
}
步骤 3: AI 搜索模板库
↓
模板库: 500+ 预设模板
├─ user-list-crud.json
├─ login-register.json
├─ data-table.json
├─ form-builder.json
└─ ...
AI 分析提示词，检索最相关的 10 个模板
步骤 4: 返回 JSON 化模板
↓
[
{
"id": "template-001",
"name": "用户列表 CRUD",
"description": "包含增删改查的用户管理页面",
"preview": "base64_screenshot_or_url",
"tech": ["React", "Ant Design", "RESTful"],
"confidence": 95, // 命中率
"files": {
"frontend": ["UserList.tsx", "UserForm.tsx"],
"backend": ["UserController.java", "UserService.java"],
"database": ["user_table.sql"]
}
},
{ ... 9 more templates ... }
]
步骤 5: 用户选择
↓
前端展示 10 个模板卡片
用户点击选择其中一个
步骤 6: 生成演示代码
↓
生成完整的前后端代码
可预览、可下载、可直接运行
02.创作模式
步骤 1: 用户输入
↓
"我要做一个在线教育平台"
"创建一个库存管理系统，要支持多仓库"
"开发一个博客系统，支持 Markdown"
步骤 2: 复杂 IF 判断
↓
if (需求复杂 || 模板库无匹配) {
进入创作模式
}
步骤 3: VM 模板引擎（组合模式）
↓
┌─────────────────────────────┐
│ Velocity 模板引擎 │
├─────────────────────────────┤
│ • SQL 表结构模板 │
│ - user.sql.vm │
│ - course.sql.vm │
│ - order.sql.vm │
│ │
│ • CRUD 逻辑模板 │
│ - Controller.java.vm │
│ - Service.java.vm │
│ - Mapper.xml.vm │
│ │
│ • VIEW 视图模板 │
│ - List.vue.vm │
│ - Form.vue.vm │
│ - Detail.vue.vm │
└─────────────────────────────┘
步骤 4: AI 分析 + 模板组合
↓
AI 理解需求:
- 需要哪些实体（User, Course, Order）
- 实体之间的关系（一对多、多对多）
- 每个实体的字段
然后组合 VM 模板:
FOR EACH entity IN [User, Course, Order]:
生成 {entity}.sql (从 table.sql.vm)
生成 {entity}Controller.java (从 Controller.java.vm)
生成 {entity}Service.java (从 Service.java.vm)
生成 {entity}List.vue (从 List.vue.vm)
...
步骤 5: 生成完整小应用
↓
输出:
├─ database/
│ ├─ schema.sql (所有表结构)
│ └─ init.sql (初始数据)
├─ backend/
│ ├─ controller/ (所有 Controller)
│ ├─ service/ (所有 Service)
│ ├─ mapper/ (所有 Mapper)
│ └─ entity/ (所有 Entity)
└─ frontend/
├─ views/ (所有页面)
├─ components/ (所有组件)
└─ api/ (API 调用)
03.思维链可视化（类似 CC 跳动）
a.展示思考过程
🤔 正在分析您的需求...
├─ 识别到关键词："用户管理"、"列表"、"CRUD"
├─ 意图分类：标准功能开发
└─ ✅ 进入模板模式
🔍 正在搜索模板库...
├─ 检索到 25 个相关模板
├─ 根据相似度排序
└─ ✅ 精选 Top 10
📊 正在计算命中率...
├─ 模板1: 95% 匹配
├─ 模板2: 87% 匹配
└─ ✅ 推荐使用模板1
b.是否支持图片
场景 1: 用户上传 UI 设计图
→ AI 识别界面元素
→ 生成对应的前端代码
场景 2: 用户上传原型图
→ AI 识别数据表结构
→ 生成数据库 Schema
场景 3: 模板预览图
→ 每个模板带截图
→ 用户直观选择
c.提示词命中率优化
// 模板定义示例
{
"id": "user-crud-001",
"keywords": ["用户", "管理", "列表", "增删改查", "CRUD"],
"synonyms": ["人员", "账号", "账户"],
"scenarios": [
"创建用户管理页面",
"做一个用户列表",
"需要用户增删改查功能"
],
"confidence_threshold": 80, // 低于此值不推荐
"template": { ... }
}
// 命中率计算
function calculateHitRate(userPrompt, template) {
let score = 0;
// 关键词匹配
template.keywords.forEach(keyword => {
if (userPrompt.includes(keyword)) score += 10;
});
// 语义相似度（AI 嵌入向量）
score += semanticSimilarity(userPrompt, template.scenarios);
return score;
}
d.JSON 化模板结构
{
"template_id": "ecommerce-product-list",
"metadata": {
"name": "电商商品列表",
"category": "电商",
"tech_stack": ["Java", "Spring Boot", "Vue 3", "MySQL"],
"complexity": "medium"
},
"database": {
"tables": [
{
"name": "product",
"fields": [
{"name": "id", "type": "bigint", "primary": true},
{"name": "name", "type": "varchar(255)"},
{"name": "price", "type": "decimal(10,2)"}
]
}
]
},
"backend": {
"files": [
{
"path": "controller/ProductController.java",
"template": "controller.vm",
"variables": {
"entity": "Product",
"package": "com.example.product"
}
}
]
},
"frontend": {
"files": [
{
"path": "views/ProductList.vue",
"template": "list.vm"
}
]
}
}
04.智能系统分析师
a.AI 作为系统“大脑”
a.图示
┌──────────────────┐
│ 用户输入 │
│ (文本/图片/提示词) │
└─────────┬──────────┘
│
┌────▼────┐
│ AI 大脑 │
└────┬────┘
│
┌─────────┴─────────┐
│ 意图识别引擎 │
│ (判断需求简单/复杂) │
└─────────┬─────────┘
│
F(简单) │ F(复杂)
┌───▼───┐ ┌───▼───┐
│ 模板模式 │ │ 创作模式 │
└───────┘ └───────┘
b.主要作用
AI 生成机制是整个全栈代码生成平台的核心驱动力。
它扮演着“智能系统分析师”的角色，负责理解用户意图，并根据需求的复杂度，调度两种不同的代码生成模式。其设计遵循三大原则：
人机协作 (Human-in-the-loop)：AI 提供最优选项，但最终决策权交还给用户。
过程透明 (Transparency)：通过“思维链可视化”，将 AI 的决策过程展示给用户，建立信任。
混合模式 (Hybrid Approach)：结合模板匹配的“确定性”与大语言模型创作的“灵活性”，实现效率与能力的平衡。
b.意图识别引擎 (Intent Recognition Engine)
这是 AI 工作流的第一道关卡，负责将用户需求分流。
a.输入：用户的原始提示词，例如 "做一个用户管理页面" 或 "开发一个支持多仓库的库存管理系统"。
b.判断逻辑：这是一个基于规则和模型的混合判断系统。
a.模板库快速匹配：首先，将提示词与 500+ 模板库中的 keywords 和 scenarios 字段进行快速匹配。
b.计算初步置信度：如果在一个或多个模板中找到高频关键词或场景（例如，置信度 > 90%），则初步判断为“简单需求”。
c.分析提示词复杂度：分析提示词的长度、包含的实体数量、实体间的关系描述。
a.简单需求特征：通常较短，指代单一功能（如“登录”、“注册”、“图表”、“列表”）。
b.复杂需求特征：通常较长，描述一个“系统”而非“功能”，包含多个实体及其关系（如“在线教育平台，包含老师、学生和课程，学生可以选课”）。
d.最终决策：
a.if (模板库高置信度匹配 && 提示词复杂度低) -> 进入模板模式
b.else -> 进入创作模式
c.模式一：模板模式下的 AI 机制（搜索与排序）
在模板模式下，AI 的核心任务是从 500+ 模板库中“精准、快速地检索并排序”。
a.提示词命中率优化机制
这是该模式的核心技术，我们采用“多路召回 + 精排”的经典搜索架构。
a.召回层 (Recall) - 捞出所有可能相关的模板
a.关键词匹配 (Keyword Matching)：
a.实现：基于模板 JSON 中的 keywords 和 synonyms 字段，使用传统的倒排索引（如 Elasticsearch 或内建的搜索库）进行全文检索。
b.优点：速度快，可解释性强。
c.缺点：无法理解语义，例如无法将“人员管理”匹配到“用户管理”。
b.语义向量搜索 (Semantic Vector Search)：
a.实现：
a.离线处理：预先将所有模板的 scenarios 和 description 文本通过 Embedding 模型（如 BERT、Sentence-BERT）转换为高维向量，并存入向量数据库（如 Faiss, Milvus）。
b.在线查询：将用户的实时提示词也转换为同维度的向量。
c.相似度计算：在向量数据库中执行 ANN（近似最近邻）搜索，找出与用户提示词向量最相似的 Top K 个模板。
b.优点：能理解语义相似度，效果好，是提升命中率的关键。
b.排序层 (Ranking) - 从召回结果中选出最优的 Top 10
召回层可能会返回几十个相关模板，排序层负责给它们打分，并选出最好的 10 个。
a.calculateHitRate 函数实现：
---
function calculateHitRate(userPrompt, template) {
// 1. 关键词匹配得分 (权重: 30%)
let keywordScore = 0;
template.keywords.forEach(keyword => {
if (userPrompt.includes(keyword)) keywordScore += 10;
});
template.synonyms.forEach(synonym => {
if (userPrompt.includes(synonym)) keywordScore += 5; // 同义词权重稍低
});
// 2. 语义相似度得分 (权重: 70%)
// 这个值由向量搜索直接返回
let semanticScore = getSemanticSimilarity(userPrompt, template);
// 3. 综合加权计算
let finalScore = (keywordScore * 0.3) + (semanticScore * 100 * 0.7);
// 4. 过滤低置信度结果
return finalScore >= template.confidence_threshold ? finalScore : 0;
}
---
b.输出：返回一个包含 10 个模板对象的 JSON 数组，按 confidence 降序排列，供前端展示。
d.模式二：创作模式下的 AI 机制（理解与组合）
在创作模式下，AI 的任务是“将非结构化的复杂需求，转化为结构化的应用蓝图”，然后驱动 VM 模板引擎生成代码。
a.复杂需求理解（NLU 任务）
AI 需要像一个高级系统分析师一样，从用户输入中提取关键信息。
a.实体识别 (Entity Recognition)：识别核心业务对象。
a.输入：“我要做一个在线教育平台，有老师、学生和课程。”
b.输出：Entities: ["Teacher", "Student", "Course"]
b.属性提取 (Attribute Extraction)：为每个实体找出其字段。
a.输入：“学生需要有姓名、学号和邮箱。”
b.输出：Student.fields: ["name", "student_id", "email"]
c.关系抽取 (Relation Extraction)：识别实体间的关系。
a.输入：“一个老师可以教多门课程，一个学生可以选多门课程。”
b.输出：
a.Relation: { from: "Teacher", to: "Course", type: "OneToMany" }
b.Relation: { from: "Student", to: "Course", type: "ManyToMany" }
b.结构化蓝图生成
AI 将上述理解的成果，整合成一个标准的、结构化的 JSON 对象。这个 JSON 就是驱动 VM 引擎的“上下文变量 (Context)”。
a.示例 JSON 蓝图：
---
{
"appName": "OnlineEducationPlatform",
"entities": [
{
"name": "Student",
"fields": [
{"name": "id", "type": "long", "primaryKey": true},
{"name": "name", "type": "string"},
{"name": "student_id", "type": "string", "unique": true},
{"name": "email", "type": "string"}
]
},
{
"name": "Course",
"fields": [
{"name": "id", "type": "long", "primaryKey": true},
{"name": "title", "type": "string"},
{"name": "description", "type": "text"}
]
}
],
"relations": [
{ "from": "Student", "to": "Course", "type": "ManyToMany" }
]
}
---
c.与 VM 引擎联动
AI 的工作到生成上述 JSON 蓝图为止。接下来，系统将这个 JSON 作为输入，传递给 Velocity 模板引擎。VM 引擎会遍历这个 JSON，并根据预设的 .vm 模板文件（如 Controller.java.vm, List.vue.vm）生成最终的完整代码。
---
FOR EACH entity IN json.entities:
Render('Controller.java.vm', entity)
Render('Service.java.vm', entity)
...
---
e.多模态能力：图片输入支持
此功能利用视觉语言模型 (VLM)，如 GPT-4V 或类似模型，实现“看图生成代码”。
a.场景 1: 用户上传 UI 设计图
a.VLM 分析图片，识别出页面布局、颜色、字体和组件（如按钮、输入框、卡片）。
b.模型输出一份描述 UI 结构的中间表示（如 JSON 或 HTML 骨架）。
c.系统基于这个中间表示，生成对应的 Vue/React 组件代码。
b.场景 2: 用户上传手绘原型图或 ER 图
a.VLM 分析图片中的框、线和文字，理解实体、字段和它们之间的关系。
b.模型输出一份类似上文的“结构化蓝图 JSON”。
c.系统使用此 JSON，生成数据库的 schema.sql 文件。
f.关键特性：思维链可视化
这是提升用户体验和信任度的核心功能。它不是简单地展示日志，而是将 AI 的决策步骤友好地呈现出来。
a.技术实现：
a.AI 后端在执行每一步（如意图识别、模板搜索、打分）时，都会生成一条结构化的日志记录，包含步骤名称、状态（进行中/完成）、和结果。
b.这些日志通过 WebSocket 或流式响应 (Streaming Response) 实时推送到前端。
c.前端根据接收到的日志对象，动态渲染出用户看到的思考过程动画。
b.示例日志流 (JSON Lines):
---
{"step": "需求分析", "status": "processing", "message": "正在分析您的需求..."}
{"step": "需求分析", "status": "done", "result": {"keywords": ["用户管理", "CRUD"], "intent": "简单功能开发"}}
{"step": "模式决策", "status": "done", "result": "✅ 进入模板模式"}
{"step": "模板搜索", "status": "processing", "message": "🔍 正在搜索模板库..."}
{"step": "模板搜索", "status": "done", "result": {"found": 25, "selected": 10}}
{"step": "命中率计算", "status": "done", "result": [{"template_id": "user-crud-001", "confidence": 95}, {"template_id": "...", "confidence": 87}]}
---
3.9 [4]法律告知
01.常用信息1
a.作为AI用户，你受到以下保护
┌─────────────────────────────────────┐
│ 作为AI用户，你受到以下保护： │
├─────────────────────────────────────┤
│ 🏛️ 宪法 - 基本权利和自由 │
│ 📜 民法典 - 人格权和隐私权 │
│ 🔒 网络安全法 - 个人信息保护 │
│ 🛡️ 数据安全法 - 数据安全保护 │
│ 👤 个人信息保护法 - 全面保护 │
│ ⚖️ 刑法 - 侵犯信息要受处罚 │
│ 🤖 AI专门规定 - 生成式AI监管 │
└─────────────────────────────────────┘
b.中国法律保护体系
中国法律体系
├── 宪法（根本大法）
├── 法律（全国人大制定）
│ ├── 网络安全法
│ ├── 数据安全法
│ ├── 个人信息保护法
│ └── 其他相关法律
├── 行政法规（国务院制定）
├── 部门规章（各部委制定）
├── 国家标准（标准化管理）
└── 行业规范（行业组织制定）
c.这些法律如何保护你？
你作为AI用户
↓
受到以下保护：
├── 人身权保护（人格尊严、隐私）
├── 财产权保护（知识产权、数据财产）
├── 隐私保护（个人信息、通信秘密）
└── 安全保护（数据安全、网络安全）
02.常用信息2
a.引言
a.关注AI使用隐私的原因
随着AI工具在软件开发中的广泛应用，开发人员经常需要上传代码片段寻求帮助，分享技术文档获取分析，
讨论项目架构和设计方案。这些操作可能涉及公司源代码、技术文档、业务逻辑和数据结构设计。
因此，了解如何安全、合规地使用AI工具至关重要。
b.指南目的
本文档旨在帮助开发者理解AI使用中的隐私风险，提供识别和评估风险的方法，
给出保护隐私和数据安全的实用建议，以及说明安全使用AI的最佳实践。
c.当前场景评估
a.场景描述
场景：分析公司内部的操作手册，整理系统需求
目的：系统重构和需求分析
涉及内容：山西路桥建设集团电子商务平台操作手册、系统功能模块分析、业务流程梳理
b.风险评估
风险等级：低风险
评估结论：数据敏感性为内部技术文档非核心机密，版权问题为公司内部文档有合法使用权，
隐私风险为不涉及个人隐私信息，商业秘密为操作手册通常不构成核心商业秘密，
数据泄露风险为用于内部开发不对外传播。
c.常见隐私顾虑
a.数据保存问题
AI不会永久保存所有对话，有数据保留期限。
对话可能会经过匿名化处理用于训练，但不会在未经允许的情况下被他人查看。
合规的AI服务不会出售用户数据。
b.代码安全性
上传代码的风险主要包括：代码泄露风险为中等，AI服务可能保存代码片段；
知识产权风险为中等，上传的代码可能受版权保护；商业秘密风险为高，核心算法可能泄露；
数据安全风险为低，指传输和存储过程中的安全。
c.公司知情权
公司是否知道取决于是否有监控系统、AI服务的可见性以及是否主动告知。
建议了解公司的AI使用政策，必要时告知团队使用情况，并遵守公司规定。
d.使用场景安全性分析
a.安全场景
学习编程询问概念语法、代码调试询问错误原因、技术讨论架构设计模式、文档整理需求分析、生成通用模板等场景，
因不涉及敏感信息或仅为通用内容，可以放心使用。
b.需注意场景
完整代码分析、商业项目代码、敏感业务逻辑、包含客户信息的代码、调试生产代码等场景存在一定风险。
建议进行脱敏后使用，确认公司政策并申请授权，或避免上传真实配置。
c.高风险场景
处理密钥密码、个人隐私信息、核心算法、未公开产品信息、机密文档的场景风险极高，
严禁使用外部AI处理。应使用公司内部AI工具或本地模型作为替代方案。
e.隐私保护最佳实践
a.数据脱敏原则
上传前必须进行脱敏处理。使用占位符替换真实姓名、手机号、身份证、地址、公司名和密钥。
b.代码上传建议
可以上传函数片段、脱敏后的配置结构、错误信息、技术描述和伪代码。
严禁上传完整项目文件、真实密钥、生产环境连接字符串、API密钥、客户真实数据和机密内容。
c.对话管理
建议定期删除对话历史，不保存敏感对话链接，及时关闭不必要的会话，并定期检查清理账户数据。
d.工作环境安全
使用建议包括：使用公司网络避免公共WiFi，不使用时及时登出，使用个人或授权设备，设置强密码，以及启用双因素认证。
4 编程模型
4.1 [1]梳理知识
01.昇腾生态
a.推理模型
a.列表
盘古 (Pangu) 官方亲儿子，性能最优，软硬件结合最好
Llama 2 / 3 国际行业标杆，社区活跃，验证其能力 重中文就选 Qwen，想对标业界就选 Llama
通义千问 (Qwen) 顶级中文模型，非常适合国内业务场景 重中文就选 Qwen，想对标业界就选 Llama
ChatGLM 优秀中英双语模型，社区基础好
b.适配版本
通义千问系列的模型权重在华为 ModelZoo (昇思社区) 中有直接的适配版本
原生 PyTorch 是跑在 GPU 上的。在昇腾机器上，你需要安装 torch-tensor 和 torch-npu 插件，替代掉 torch-cuda
为了保证性能，建议不要从头手写推理代码，而是使用华为提供的 Ascend Speed (一个类似 vLLM 的推理加速工具) 或者下载官方适配好的推理脚本
运行 Qwen2-VL 至少需要 24GB 以上的显存（建议使用 Ascend 910B 卡或更高端的型号）
c.在昇腾上运行模型的标准流程
1.访问 MindSpore 或昇腾社区的模型页面
2.下载官方提供的适配脚本和代码
3.按照 README.md 文件中的步骤，准备环境、下载模型权重
4.执行 Python 脚本来启动推理服务或进行微调
b.OCR模型
a.PaddleOCR（推荐）
支持情况：百度飞桨与华为昇腾有深度战略合作。PaddleOCR 及其底层的 PaddlePaddle 框架已经完美适配了昇腾 NPU
搭建建议：你不需要修改代码，只需安装 "适配了昇腾的 PaddlePaddle 版本"
安装方式：通常在昇腾机器上安装 paddlepaddle-npu 或使用华为提供的 Docker 容器镜像
性能：推理速度非常快
b.RapidOCR
技术原理：RapidOCR 本质上是用 ONNX Runtime 推理
支持情况：ONNX Runtime 社区已经有了对昇腾（通过 DML 或 ExecuteProvider）的支持，但配置相对复杂
结论：可以跑，但需要配置推理 provider
建议：建议优先考虑直接用 PaddleOCR 原生框架在昇腾上跑
c.推荐部署
a.对于OCR任务
1.优先选择PaddleOCR（原生支持）。
2.备选方案RapidOCR（需要额外配置）。
3.推荐使用华为提供的Docker镜像。
b.对于大模型任务
1.框架选择：使用torch-npu替代torch-cuda。
2.推理加速：使用Ascend Speed替代vLLM。
3.资源规划：确保有足够的显存（建议24GB以上）。
4.代码获取：从ModelZoo获取官方适配的推理脚本。
02.会议内容
a.分类1
a.场景
1.智能客服、供应商审核
2.智能评标：只标注、指出来【文件】哪里有问题
3.智能审核
4.工会Agent：画像、荣誉、履历
b.资源
供应商审核 AI应用服务器 资产
OCR识别 应用服务器 文字加权
备份服务器
c.评标
虚拟评编专家 专家管理者（人）
AI辅助评编：只标注、指出来【文件】哪里有问题
b.分类2
a.投标
标书 -> OCR 投标 -> 开标 -> 实时性（高一点）
间距3天 加解密
充足时间来学习
历史信息（如果问出来，是违规行为）
b.开标
解密后，只在评盘工具上，不落盘
1.指出评标问题
2.异常
3.标准：A、B、C、D、E（必须要AI资质）
打分
c.原则
1.打分
2.指出
3.10年归档，最高1000并发，AI对话同时10并发
c.分类3
a.架构
1.流水线：开发人员，git -> 推k8s
2.数据不在本地，全程不落盘
3.维护框架（组件）：1.2 -> 1.6 有问题，目前 1.61 -> 1.7.8
4.电商平台：业务（主）、框架（辅）
5.数据库：打补丁，修复
b.数据中台
1.数据：0点备份（接口，同步时间），主从备份+离线
2.档案系统
c.领域划分
1.20多台微服务，解耦
d.信创
1.TongWeb，中间件
2.四套（测试+生产）、预发
d.分类4
a.存疑
核心数据1
核心数据2 -> 权限中盘
核心数据3
b.硬件
AI推理服务器
麒麟、相比统信
c.周期
1 技术验证：1个月
2-5
2-12
3-10
6-10
13-14
15 4个月
03.常见需求
a.智能评标
a.需求1
评标工具的具体使用场景是什么？企业采购
主要处理什么类型的文档？PDF 标书、Word 文档、图片
是否需要多模态能力：图片理解、表格理解
期望的并发用户量？10个会话量
是否有合规性要求？不要违法中国法律来研究这个问题
b.供应商审核
a.需求1
组件 选择
LLM GLM-4-plus（智谱 AI）
向量库 Milvus
异步任务 Celery + Redis
OCR PaddleOCR + Unstructured
数据库 SQLite（开发）
Agent框架 LangGraph
b.需求2
配置项 正确值
API Key xxxxxxxxxxxxxxx.xxxxxxxxxxxxxxx
Base URL https://open.bigmodel.cn/api/coding/paas/v4
Model glm-4.7
c.需求3
zen-znkf 使用智谱 embedding-3
zen-gyssh 使用本地 BAAI/bge-large-zh-v1.5。
d.需求4
限制线程数以降低 CPU 占用 ollama run qwen2.5:14b --threads 8
调整上下文长度（默认为 2048） ollama run qwen2.5:14b --num_ctx 4096
调整温度参数控制随机性（0-2之间） ollama run qwen2.5:14b --temperature 0.7
4.2 [1]梳理需求
01.整体架构
a.业务架构
a.采购计划管理
采购计划总览
采购计划审批
采购计划备案
b.计划执行管理
前置审批
限价申请
限价审批
限价数据对接
c.采购方案
方案报备
方案编织
方案分析
方案审批
d.招标管理
新建招标书
标书库
编标模块
公告管理
补遗变更管理
预约日历
e.供应商管理
供应商注册
供应商审核
供应商报名
供应商报名审核
f.投标管理
投标管理
供应商签到
投标文件解密
g.开标管理
公布投标人
唱标
开标结果
开标大厅
h.评标管理
专家库
专家评审系统
评标大厅
投标澄清
评标纪要与报告
i.结果管理
结果审批
结果确认单
比选结果核验
比选结果确认
j.归档管理
增量归档
档案检索
档案下载
k.结果公告
结果公告审批
结果公告公示
投诉异议
预成交通知书
l.中标通知书
中标通知书生成
m.合同备案
填写
合同履约负面评价
n.业务流程关系
采购计划管理流向计划执行管理
计划执行管理流向采购方案
采购方案流向招标管理
招标管理流向供应商管理
供应商管理流向投标管理
投标管理流向开标管理
开标管理流向评标管理
评标管理流向结果管理
结果管理流向归档管理
归档管理流向结果公告
结果公告流向中标通知书
中标通知书流向合同备案。
o.系统对接
主数据系统
统一登录系统
钉钉平台
法务系统
一体化施工系统
交控电子商务系统
短信平台
p.AI高效赋能
AI智能客服
供应商审核
智能评标
智能编标
b.技术架构
a.数据对接层
信用中国
企查查
标书模板库
b.应用层
智能客服问答
意图识别
知识预处理
知识审核
知识库管理
企业知识库
Embedding RAG
智慧招采
Agent类应用
智能评标
智能编标
多智能体
合同对比
报告生成
供应商智能审核
c.应用技术层
Agent/智能体
RAG/检索增强生成
Prompt/提示词工程
Fine-tuning/微调
数据向量
数据清洗
访问控制
d.模型层
大模型语言模型 LLM
视觉-语言模型
语音-语言模型
图像识别/OCR模型
智能文档理解模型
召回/排序小模型
多模态检测与分析
e.基础设施层
GPU/TPU
CPU
RAM
HDD
网络
f.云原生层
Docker
K8s
g.系统用户
系统管理员
业务专家
评标专家
供应商
采购方
代理商
c.架构说明
应用层 AI智能客服、供应商智能审核、智能评标等
应用技术层 各类人工智能技术实现层，通过调用底层模型能力，为上层应用提供人工智能技术能力
模型层 统管模型，为上层应用提供模型支撑
基础设施层 统一管理CPU、GPU、内存，统一协调资源，实现资源高效利用
d.硬件资源要求
服务器类型 配置 数量 说明
AI应用服务器 16C64G2T x 昇腾 910B 2 AI模型训练、OCR识别训练、AI模型运行
AI模型运行应用服务器 28C128G2T T4显卡 1 应用部署、Embedding加速
备份服务器 16C32G10T 1 模型备份、知识库备份、业务数据备份
02.AI智能客服
a.现状痛点
a.问题描述
目前每天需接打30-50个左右供应商电话，答复不够及时。
b.核心问题
a.耗时久
响应不及时。
b.效率低
需要处理供应商注册、登录、招投标一系列问题，问题重复性高，效率低。
b.AI智能客服核心价值
a.降低人工成本，提升服务效率。
b.标准化服务输出，保障服务质量。
c.辅助业务流程，减轻审核人员负担。
d.优化供应商体验。
c.整体时间规划
a.项目目标与范围定义
时间：第1周
里程碑：需求确认、MVP范围确定
输出物：《需求说明书》《MVP功能清单》
b.架构设计与环境搭建
时间：第2-5周
里程碑：硬件准备到位及关键技术路线跑通
输出物：《环境部署报告》《架构设计文档》
c.前后端应用开发
时间：第2-5周
里程碑：前后端流程跑通
输出物：《前端操作界面》《后端服务接口文档》《用户操作手册（初稿）》
d.知识库建设与治理
时间：第2-7周
里程碑：初版知识库上线
输出物：《知识库使用说明书》
e.AI调优
时间：第6-9周
里程碑：准确率>85%
输出物：《模型测试报告》
f.集成测试
时间：第10-11周
里程碑：全链路测试通过
输出物：《集成测试用例》《全链路测试报告》《性能与安全测试报告》
g.上线运营
时间：第11周+
里程碑：灰度->全量->持续优化
输出物：《上线实施方案》《运维监控手册》
d.项目目标与范围定义
a.核心问题澄清
a.服务对象
电子商务系统用户、潜在用户。
b.覆盖业务场景
系统使用问题、账户问题、政策法规等。
c.期望解决痛点
降低人工客服成本与接入次数。
d.是否允许转人工
复杂or高风险问题转接转工单。
e.合规要求
数据不出境、本地部署、审计日志保留6个月。
b.MVP范围
a.明确最小MVP范围
最小可行产品，实现快速上线迭代。
b.初期聚焦TOP50高频问题。
c.支持web页面切入聊天窗口。
d.知识来源
现有FAQ + 产品文档。
e.架构设计与环境搭建
a.整体技术架构
a.用户层
a.系统管理员
b.业务专家
c.供应商
d.采购方
b.应用层
a.智能客服问答
b.意图识别
c.知识预处理
d.知识审核
e.知识库管理
f.企业知识库
g.Embedding RAG
c.应用技术层
a.Agent/智能体
b.RAG/检索增强生成
c.Prompt/提示词工程
d.Fine-tuning/微调
d.模型层
a.大语言模型 LLM
b.视觉-语言模型
c.语音-语言模型
d.图像识别/OCR模型
e.智能文档理解模型
f.召回/排序小模型
g.多模态检测与分析
e.基础设施层
a.GPU/TPU
b.CPU
c.RAM
d.HDD
e.网络
f.数据对接
a.信用中国
b.企查查
c.标书模板库
b.技术要点
a.Embedding + 切片
元数据/原文。
b.上传/编辑
知识管理。
c.http/websocket
通信协议。
d.知识库存储
企业知识库(向量化/信创适配)，详见13/23技术文档。
c.环境搭建
在内网服务器中部署大语言模型(LLM)应用开发平台、向量数据库、客服大模型。
f.前后端应用开发
a.前端功能
a.首页嵌入智能客服按钮及弹窗。
b.创建与后端智能服务机器人的会话。
b.后端功能
a.后端智能客服机器人获取上下文及验证权限后调大模型返回问题答案。
b.AI工作流引擎编排。
g.知识库建设与治理
a.知识来源
a.FAQ（常见问题）。
b.流程型知识。
c.产品/服务文档。
d.政策/规则/法规。
e.业务系统动态数据。
b.知识管理流程
a.知识创建/更新。
b.法务/合规审核
敏感/高风险：拒绝。
通过：进入业务专家审核。
c.业务专家审核
不通过：拒绝。
通过：发布上线生效。
d.发布上线生效。
e.用户使用。
f.用户反馈/AI未命中
未命中：自动建议更新，返回知识创建/更新。
命中：结束。
c.知识治理流程
a.知识来源
a.FAQ常见问题
b.流程型知识
c.产品服务文档
d.政策规则法规
e.业务系统动态数据
b.知识管理
a.知识创建/更新
b.法务合规审核
敏感/高风险：返回知识创建/更新。
通过：进入业务专家审核。
c.业务专家审核
不通过：返回知识创建/更新。
通过：进入发布上线。
d.发布上线
c.持续优化
a.用户使用反馈
b.AI未命中分析
c.自动更新建议
返回知识创建/更新。
03.供应商智能审核
a.现状痛点
a.问题描述
目前每天需审核30-50个供应商信息，人工审核存在以下问题。
b.核心问题
a.耗时久
供应商信息涵盖基本信息、财务等多维度，人工逐项核对耗时长。
b.易出错
人工审核易因疲劳、疏忽出现信息遗漏或错误判断。
c.效率低
重复、机械的信息核对工作占用大量人力，难以快速响应业务需求。
b.AI智能审核的核心价值
a.高效自动化
利用AI技术自动抓取、解析供应商多维度信息（如工商注册信息、财务数据、产品信息等），替代人工重复核对流程。
b.精准校验
基于算法对信息的合规性、一致性进行智能校验，如企业名称与营业执照是否匹配、银行账户信息与企业主体是否对应等。
c.智能预警
对异常信息（如经营范围与产品信息不符、财务数据异常波动等）自动标记并预警，辅助人工快速聚焦关键问题。
c.整体时间规划
a.项目目标与范围定义
时间：第1周
里程碑：明确审核业务场景、确定MVP范围（如准入初审+基础风险扫描）
输出物：《供应商智能审核需求说明书》《MVP功能清单》
b.架构设计与环境搭建
时间：第2-5周
里程碑：完成系统架构设计，部署数据中台、AI平台及对接外部数据源（工商、司法等）
输出物：《系统架构设计文档》《外部数据接口清单》《环境部署报告》
c.前后端应用开发
时间：第2-10周
里程碑：实现供应商注册、资料上传、自动校验、审核工作台等核心功能，前后端联调通过
输出物：《前端操作界面》《后端服务接口文档》《用户操作手册（初稿）》
d.规则知识库建设与治理
时间：第3-8周
里程碑：构建审核规则库（如资质要求、风险阈值）、供应商行业分类标准、合规政策库
输出物：《供应商审核规则知识库V1.0》《知识库管理规范》《规则配置后台》
e.AI模型训练与调优
时间：第6-10周
里程碑：完成风险评分模型、OCR识别模型、异常检测模型训练，整体审核准确率≥85%
输出物：《供应商风险评估AI模型》《模型测试报告》《AI审核置信度说明文档》
f.集成测试
时间：第11-12周
里程碑：完成与各系统的端到端集成测试，覆盖准入、复审、预警等场景
输出物：《集成测试用例》《全链路测试报告》《性能与安全测试报告》
g.上线运营
时间：第13周+
里程碑：灰度上线（先试点品类）→全量推广→建立持续优化机制（反馈闭环、模型迭代）
输出物：《上线实施方案》《运维监控手册》《供应商自助门户使用指南》《月度优化路线图》
d.项目目标与范围定义
a.核心问题澄清
a.服务对象
电子商务业务人员。
b.覆盖业务场景
供应商注册、账号找回、信息变更。
c.期望解决痛点
提高供应商审核效率与准确性。
d.是否需要人工复核
前期人工复核，提升模型准确度，算法评估是否需要人工复核。
e.合规要求
数据不出境、本地部署、审计日志保留6个月。
b.MVP范围
a.明确最小MVP范围
最小可行产品，实现快速上线迭代。
b.初期聚焦供应商注册审核流程。
c.创建审核工作台，集中审核相关场景。
d.主要规则
前期核验规则主要集中在系统内，后续陆续接入第三方如工商、司法等系统进行查验。
e.架构设计与环境搭建
a.业务流程
a.供应商注册。
b.上传注册材料。
c.智能审核。
d.要素识别/关键信息抽取。
e.OCR识别
营业执照/授权委托书/社保证明/法人证件。
f.智能审核
文件完整->企业存续->法人信息完整->经营范围符合->授权信息完整->审核通过。
文件不完整/营业期间异常/法人信息不完整/经营范围不符合/授权信息不完整->人工复核。
g.人工复核处理。
b.技术架构
a.前端应用
a.供应商注册/信息变更/找回账号。
b.智能审核应用
a.供应商智能审核。
b.供应商审核工作台。
c.审核流程。
d.审核详情。
e.供应商审核统计。
c.智能引擎层
a.OCR识别
信创适配引擎(MindX/MinerU)。
b.机器学习
TensorFlow。
c.知识图谱
Neo4j。
d.规则引擎
Drools。
d.要素识别层
a.关键信息抽取。
b.社会信用代码/企业名称/法人信息。
c.授权书信息/授权时间。
d.参保单位等。
e.外部数据源
a.三方数据源
工商/司法等。
b.其他业务系统。
c.数据中台。
c.应用场景
a.供应商注册审核。
b.供应商信息变更审核。
c.供应商找回账号。
d.审核流程
供应商注册->供应商注册审核->电子商务系统。
d.环境搭建
内网部署OCR识别模型、供应商审核评分模型、供应商审核工作台、规则引擎等。
f.规则知识库建立与治理
a.规则来源
a.业务专家提供。
b.业务流程需要。
b.数据来源
a.供应商上传提供。
b.第三方数据来源（工商、企查查、司法等）。
c.知识管理流程
a.规则创立/更新。
b.法务/合规审核
敏感/高风险：拒绝。
通过：进入业务专家审核。
c.业务专家审核
不通过：拒绝。
通过：发布规则生效。
d.发布规则生效。
e.更新规则。
f.使用。
g.用户反馈/AI未命中
未命中：返回规则创立/更新。
命中：结束。
g.AI模型训练与调优
a.模型训练流程
a.OCR识别模型
模型训练->参数调优->提高OCR识别精准度->资质校验/审核对比/审核评分。
b.审核评分模型
模型训练->参数调优->提升审核准确率->资质校验/审核对比/审核评分。
c.智能审核核心规则引擎
a.资质校验。
b.审核对比。
c.审核评分。
b.模型说明
a.OCR模型
把非结构化的图像/扫描版PDF数据，转换成结构化的文本数据，为后续的资质校验、规则审核、AI风险评估提供可处理的输入。
b.审核评分模型
基于多维度数据，对供应商资质、合规性、风险等级进行量化评估，输出可直接用于审核决策的分数或等级，替代人工主观判断，实现审核流程的标准化、自动化和智能化。
c.处理流程
供应商法人信息/被授权人信息->OCR识别->信息提取。
04.智能评标
a.现状痛点
a.问题描述
目前评标，人工审核存在以下问题。
b.核心问题
a.耗时久
供应商信息涵盖基本信息、财务等多维度，人工逐项核对耗时长。
b.易出错
人工审核易因疲劳、疏忽出现信息遗漏或错误判断。
c.效率低
重复、机械的信息核对工作占用大量人力，难以快速响应业务需求。
b.AI智能评标的核心价值
a.高效自动化
利用AI技术自动抓取、解析投标文件信息。
b.精准校验
基于算法对信息的合规性、一致性进行智能校验，如企业名称与营业执照是否匹配、银行账户信息与企业主体是否对应等。
c.智能预警
对异常信息（如经营范围与产品信息不符、资质不符合等）自动标记并预警，辅助人工快速聚焦关键问题。
c.整体时间规划
a.项目目标与范围定义
时间：第1周
里程碑：明确审核业务场景、确定MVP范围（如准入初审+基础风险扫描）
输出物：《供应商智能审核需求说明书》《MVP功能清单》
b.架构设计与环境搭建
时间：第2-5周
里程碑：完成系统架构设计
输出物：《系统架构设计文档》《外部数据接口清单》《环境部署报告》
c.前后端应用开发
时间：第2-12周
里程碑：实现AI虚拟评标专家，实现AI辅助智能评标
输出物：《前端操作界面》《后端服务接口文档》《用户操作手册（初稿）》
d.专家知识库建设与治理
时间：第3-10周
里程碑：评审规则、决策模型、专家决策模式、行业标准、历史评标案例等
输出物：《专家知识库V1.0》
e.AI模型训练与调优
时间：第6-10周
里程碑：基础模型预训练、领域适应性微调、专家行为模仿学习等
输出物：《模型测试报告》
f.集成测试
时间：第13-14周
里程碑：完成与各系统的端到端集成测试，覆盖准入、复审、预警等场景
输出物：《集成测试用例》《全链路测试报告》《性能与安全测试报告》
g.上线运营
时间：第15周+
里程碑：灰度上线（先试点品类）→全量推广→建立持续优化机制（反馈闭环、模型迭代）
输出物：《上线实施方案》《运维监控手册》《供应商自助门户使用指南》《月度优化路线图》
d.项目目标与范围定义
a.核心问题澄清
a.服务对象
招采中心。
b.覆盖业务场景
公开招标、竞争谈判。
c.期望解决痛点
提高评标标准与质量，减少投诉。
d.是否需要人工介入
需要，由人工把握最后一关。
e.合规要求
私有部署，数据不外传，评标升级日志长期保留。
b.MVP范围
a.明确最小MVP范围
最小可行产品，实现快速上线迭代。
b.实现公开招标项目评标。
e.架构设计与环境搭建
a.三种AI评审模式对比
a.AI辅助评审模式
a.AI深度融合评标过程。
b.服务于评标专家。
c.标注展示。
d.存疑项加强展示。
e.专家独立评分。
b.AI协同评审模式
a.AI全程辅助。
b.专家完成评标。
c.AI独立评审模式
a.AI虚拟评标专家。
b.独立资格审查。
c.独立评分。
d.专家组长定夺。
b.独立评审模式完整流程
a.集成测试
a.前后端对接联调。
b.三方系统打通调试。
c.模型验证。
d.流程验证。
b.供应商资格复核。
c.资格审查。
d.安全审查模块
OCR识别->规则引擎。
e.评分
a.商务部分。
b.技术部分。
c.私有化部署大模型。
f.评分依据审计记录。
g.专家组长勾选推荐供应商。
h.中标规则
a.最低价法
满足要求的情况下，价格最低者中标。
b.综合评分法
综合考虑商务、技术等因素。
i.进入下一个流程。
c.技术实现思路
a.规则引擎
强规则校验。
b.私有化部署大模型
独立评分。
c.全流程审计日志记录
大模型评分依据全程留存审计。
d.安全审查模块
检测文档质量避免大模型投毒。
f.智能评标-独立评审模式
a.评标流程详解
a.准备阶段
a.集成测试。
b.前后端对接联调。
c.三方系统打通调试。
d.模型验证。
e.流程验证。
b.资格审查阶段
a.供应商资格复核。
b.资格审查。
c.安全审查模块。
c.评分阶段
a.OCR识别。
b.规则引擎。
c.AI虚拟评标专家。
d.私有化部署大模型。
e.评分。
d.结果阶段
a.评分依据审计记录。
b.专家组长勾选推荐供应商。
c.中标规则。
b.中标规则
a.最低价法
满足要求的情况下，价格最低者中标。
b.综合评分法
综合考虑商务、技术等因素。
g.智能评标-AI辅助评审模式
a.符合性辅助审查
a.资质一致性审查
a.企业名称vs营业执照。
b.社会信用代码校验。
c.法人信息一致性。
b.签字签章审查
a.法定代表人签字识别。
b.公章识别与验证。
c.签章位置检查。
c.投标文件格式审查
a.章节完整性检查。
b.必备文件检查。
c.格式规范检查。
b.商务部分辅助评价
a.关键要素完整性审查
a.报价清单完整性。
b.付款方式响应。
c.交货期/工期响应。
b.关键要素提取与展示
a.报价金额高亮显示。
b.付款条款提取。
c.交货期/工期提取。
c.技术部分辅助评价
a.关键要素完整性审查
a.技术方案完整性。
b.设备配置清单。
c.人员配置情况。
d.质量保证措施。
b.关键要素提取与展示
a.技术参数对比。
b.设备型号规格。
c.人员资质证书。
d.AI辅助评审架构
a.专家工作台
a.投标文件列表->比对展示。
b.评审界面->异常预警。
c.AI辅助面板->评分依据。
05.信创环境
a.总则
本系统(Aries智能招采平台)设计与交付必须完全符合国家信息技术应用创新(信创)标准。所有关键软硬件基础设施均需实现国产化替代，确保自主可控、安全合规。
b.信创技术栈规范
a.基础设施层
a.芯片/CPU/NPU
a.计算节点
必须兼容海光(Hygon 3号)或鲲鹏(Kunpeng 920)处理器(x86/ARM指令集)。
b.AI算力卡
a.核心大模型(LLM)
强制适配华为昇腾(Ascend 910B)，使用MindSpore框架。
b.辅助推理(OCR/Embedding)
允许使用存量NVIDIA T4/L4显卡进行利旧部署，但需纳入统一资源管理。
b.操作系统(OS)
a.生产环境必须运行在银河麒麟(KylinOS V10 SP3)或统信(UOS Server 20)。
b.内核版本需锁定，通过等保三级安全认证。
b.基础软件层
a.数据库(Database)
a.关系型数据库
强制使用达梦数据库(Dameng DM8)。需开启Oracle兼容模式。
b.向量/缓存
优先使用达梦数据缓存服务，或国产适配的Redis/Milvus信创版。
b.中间件(Application Server)
a.应用容器需适配东方通(TongWeb)或金蝶天燕(Apusic)。
b.替换开源的Nginx为基于Tengine的信创适配版网关。
c.关键组件私有化
a.OCR服务
a.模式
全私有化微服务(Self-hosted)。
b.要求
严禁调用公网API(如百度/阿里)。需基于MinerU或Paddle-Serving构建内网集群，支持高并发PDF/图片解析。
b.大模型服务(LLM)
a.部署
基于MindSpore/MindIE框架在昇腾NPU上运行Qwen/Llama国产化微调版。
b.安全
模型权重文件(Weights)必须本地存储，严禁回传云端。
c.安全与加密
a.国密算法适配
系统必须全链路支持国密算法，替代RSA/AES/SHA。
a.传输加密
启用支持SM2证书的HTTPS/TLS通道。
b.身份认证
用户登录与签名验证必须使用SM2/SM3算法。
c.数据存储
敏感字段(身份证、手机号、报价)入库前使用SM4对称加密。
b.数据主权与审计
a.数据不出境
物理层面确保从采集到归档，数据不流出内网(Intranet)。
b.白盒审计
AI的每一次推理(智能评标打分)必须生成不可篡改的审计日志(包含Input/Thinking/Output)，并持久化保留至少6个月。
d.开发与交付要求
a.双轨制开发
a.开发环境(Local)
允许使用SQLite/PostgreSQL + Mock OCR进行逻辑验证。
b.集成验证(Staging)
必须提供Docker镜像或二进制包，在纯信创环境(ARM/Kylin)下通过全功能测试。
b.兼容性测试
a.交付前需出具《达梦数据库兼容性测试报告》。
b.交付前需出具《昇腾NPU推理性能测试报告》。
e.前端与终端适配
a.浏览器兼容性
a.国产浏览器
系统必须在奇安信可信浏览器、360安全浏览器(信创版)、统信浏览器上无差别运行。
b.内核适配
需同时兼容Chromium内核与Trident/Webkit等国产魔改内核，禁止依赖特定版本Chrome插件。
b.电子公文标准(OFD)
a.OFD强制支持
a.标书归档
所有最终定稿的投标文件、评标报告，除PDF外，必须生成国家标准OFD(Open Fixed-layout Document)格式进行归档。
b.预览引擎
前端需集成数科(Suwell)或福昕(Foxit)的Web版OFD阅读器，实现签章验证与原文预览。
f.运维与监控
a.监控告警
a.软件
使用Prometheus(信创版)或听云/博睿进行全链路监控。
b.授时
服务器时间同步源(NTP)必须指向北斗卫星授时服务器，严禁同步美国NIST时间源。
b.高可用与灾备
a.数据库
达梦数据库需配置DSC(数据共享集群)或数据守护(Data Watch)实现主备自动切换。
b.应用层
支持基于Keepalived的虚IP漂移，确保单点故障零停机。
4.3 [2]信创环境1：昇腾
01.昇腾生态
a.概述
a.结论
昇腾NPU服务器完全可以运行PaddleOCR、RapidOCR、Qwen2-VL、CogVLM等模型，
但由于硬件架构不同，在搭建环境时不能直接照搬Nvidia GPU的代码，需要进行特定的适配。
b.NPU生态
昇腾的软件栈称为CANN。华为提供了PyTorch on Ascend (torch-npu)和适配版的PaddlePaddle。
昇腾使用自研NPU，而传统GPU使用Nvidia的CUDA。常见的深度学习框架默认支持CUDA，要在昇腾上运行必须经过适配。
c.NPU与CUDA对比
组件 GPU环境 昇腾NPU环境
硬件 NVIDIA GPU 华为昇腾NPU
驱动 CUDA CANN
PyTorch torch-cuda torch-npu
PaddlePaddle paddlepaddle-gpu paddlepaddle-npu
推理加速 vLLM/TensorRT Ascend Speed
模型库 Hugging Face MindFormers/ModelZoo
b.软件栈分析
a.CANN 架构
昇腾的软件栈称为 CANN（Compute Architecture for Neural Networks）
b.适配工具
华为提供了适配工具，主要是：
1.PyTorch on Ascend (torch-npu)
2.适配版的 PaddlePaddle
c.技术架构对比
a.硬件
a.GPU 环境: NVIDIA GPU
b.昇腾 NPU 环境: 华为昇腾 NPU
b.驱动
a.GPU 环境: CUDA
b.昇腾 NPU 环境: CANN
c.PyTorch
a.GPU 环境: torch-cuda
b.昇腾 NPU 环境: torch-npu
d.PaddlePaddle
a.GPU 环境: paddlepaddle-gpu
b.昇腾 NPU 环境: paddlepaddle-npu
e.推理加速
a.GPU 环境: vLLM/TensorRT
b.昇腾 NPU 环境: Ascend Speed
f.模型库
a.GPU 环境: Hugging Face
b.昇腾 NPU 环境: MindFormers/ModelZoo
02.推理模型
a.运行方式
a.在昇腾上运行模型的标准流程
1.访问 MindSpore 或昇腾社区的模型页面
2.下载官方提供的适配脚本和代码
3.按照 README.md 文件中的步骤，准备环境、下载模型权重
4.执行 Python 脚本来启动推理服务或进行微调
b.华为自研模型（优先级最高）
a.盘古大模型 (Pangu)
a.简介
华为全自研的系列大模型，覆盖了从自然语言处理到多模态的各种能力。在昇腾硬件上的优化是最好的，能最大程度发挥硬件性能。
b.如何使用
通常通过华为云服务或私有化部署包获得。在 MindSpore 社区可以找到盘古模型的开源版本和相关的脚本。
c.优势
软硬件结合最紧密，性能、稳定性最佳。
c.已官方适配的国内外主流模型
a.Llama 系列（来自 Meta）
a.简介
开源社区的绝对基石。昇腾社区已经完成了对 Llama 2 的完整适配，提供了从微调到推理的全套脚本。
Llama 3 的适配也在快速推进中，很可能已经有社区或官方的初步支持版本。
b.如何找到
在 MindSpore 的 MindFormers 套件仓库或昇腾社区的模型专区搜索 "Llama"。
b.通义千问 (Qwen) 系列（来自阿里巴巴）
a.简介
中文能力极强的系列模型，在国内应用广泛。作为国内顶级的开源模型，获得了华为很好的支持。
b.如何找到
同样在 MindSpore 社区和昇腾社区可以找到 Qwen 模型的适配版本和教程。
c.ChatGLM / GLM 系列（来自智谱AI）
a.简介
清华背景的强大中英双语对话模型，在国内开发者社区非常受欢迎。这也是昇腾生态重点支持的对象之一。
b.如何找到
在 MindSpore 社区搜索 GLM 相关项目。
d.Baichuan（百川）系列
a.简介
由百川智能推出的开源大模型，同样在国内有很高的影响力，社区也有相应的适配支持。
d.如何查找和使用这些模型
a.昇思 MindSpore 官网/代码仓库
a.MindFormers
a.描述
基于 MindSpore 的大模型开发套件，类似 Hugging Face 的 transformers
b.功能
内置了对 Llama、GPT、Bloom、PanGu 等多种主流模型的支持
c.推荐度
这是您最应该关注的地方
b.ModelZoo
a.描述
MindSpore 的模型库
b.功能
包含了大量适配好的模型，覆盖各种领域
b.昇腾社区 (HiAscend)
a.功能
这里有"模型专区"，汇集了大量可以在昇腾硬件上运行的模型
b.提供内容
详细的迁移指南、脚本和性能数据
e.模型选择建议
a.模型系列对比
a.盘古 (Pangu)
a.推荐理由
官方亲儿子，性能最优，软硬件结合最好
b.如何开始
关注 MindSpore 社区的开源版本或华为云
c.复杂度
中等
b.Llama 2 / 3
a.推荐理由
国际行业标杆，社区活跃，验证其能力
b.如何开始
查找 MindSpore MindFormers 中的 Llama 实现
c.复杂度
中等
c.通义千问 (Qwen)
a.推荐理由
顶级中文模型，非常适合国内业务场景
b.如何开始
在昇腾社区或 MindSpore 社区查找 Qwen 适配项目
c.复杂度
中等
d.ChatGLM
a.推荐理由
优秀中英双语模型，社区基础好
b.如何开始
在昇腾社区或 MindSpore 社区查找 GLM 适配项目
c.复杂度
中等
03.OCR模型
a.PaddleOCR（推荐）
a.支持情况
百度飞桨与华为昇腾有深度战略合作。PaddleOCR 及其底层的 PaddlePaddle 框架已经完美适配了昇腾 NPU
b.搭建建议
你不需要修改代码，只需安装 "适配了昇腾的 PaddlePaddle 版本"
c.安装方式
通常在昇腾机器上安装 paddlepaddle-npu 或使用华为提供的 Docker 容器镜像
d.性能
推理速度非常快
b.RapidOCR
a.技术原理
RapidOCR 本质上是用 ONNX Runtime 推理
b.支持情况
ONNX Runtime 社区已经有了对昇腾（通过 DML 或 ExecuteProvider）的支持，但配置相对复杂
c.结论
可以跑，但需要配置推理 provider
d.建议
建议优先考虑直接用 PaddleOCR 原生框架在昇腾上跑
c.快速开始指南
a.步骤1：访问昇思社区
搜索PaddleOCR昇腾适配、Qwen2-VL昇腾等关键词。
b.步骤2：使用Docker镜像
使用华为封装好环境的镜像，直接在容器里运行代码以避免驱动版本冲突。
c.步骤3：参考ModelZoo案例
在Gitee或华为云开发者社区克隆大量跑通的样例代码。
d.部署建议
1.优先选择PaddleOCR（原生支持）。
2.备选方案RapidOCR（需要额外配置）。
3.推荐使用华为提供的Docker镜像。
4.4 [2]信创环境2：昇腾
01.硬件选型
a.现状与挑战
当前我们面临的核心挑战是：需要在极其有限的硬件资源(特别是系统内存)上，运行业界顶尖规模的720亿参数(72B)大模型。
这不仅仅是"慢一点"的问题，而是"能不能启动"的生死问题。
b.现有预算下的极限生存分析(Critical Sizing)
本章节针对配置：16C / 64G RAM / Ascend 910B。
基于既定采购清单，硬件资源非常受限(尤其是64G系统内存)。为了确保Qwen2.5-72B这种超大参数模型能跑起来，昇腾NPU的显存规格是唯一的救命稻草。
a.核心结论：必须购买64GB显存版本
a.红色预警
在16核/64G内存的底座上，必须采购Ascend 910B(64GB HBM)版本。
如果只有32GB显存，该项目将直接面临失败风险。
b.为什么32G显存绝对不够？(算账)
对Qwen2.5-72B-Instruct(Int4量化)的运行开销进行精确计算。
a.静态权重(Weights)
a.模型参数 72 Billion x 0.7 Byte(Int4) ≈ 42 GB。
b.注: 这部分是死钱，模型加载即占用，少1MB都启动不了。
b.动态显存(KV Cache & Activation)
a.智能评标涉及长文档处理(标书通常500+页)，Context Window至少16k-32k。
b.16k长度 + Int8 KV Cache + Batch Size 2 ≈ 12 GB。
c.注: 这是为了让模型"记住"标书内容所必须的开销。
c.系统开销(Overhead)
a.MindSpore框架 + 显存碎片 ≈ 2-4 GB。
d.总需求
42 + 12 + 4 = 58 GB。
e.场景A：购买64GB版910B
a.结果: 58GB < 64GB。安全。剩余~6GB显存可用于突发长文本。
b.状态: 系统可以流畅运行，支持约32k的上下文长度。
f.场景B：购买32GB版910B
a.单卡: 58GB > 32GB。直接OOM(内存溢出)，无法启动。
b.双卡: 32G x 2 = 64G。
a.看似够用，但因为TP(Tensor Parallel)需要在两张卡之间频繁交换数据。
b.致命瓶颈: 服务器的系统内存只有64G。MindSpore在双卡并行时，需要消耗更多的系统内存来维护分布式通信缓冲区。
c.后果: 系统内存(RAM)爆满 -> 开始使用Swap(硬盘) -> 推理速度下降100倍(从20 tokens/s跌至0.1 tokens/s) -> 业务超时不可用。
c.给采购部门的建议话术
建议直接复制以下内容告知硬件供应商。
a.由于本项目运行的是720亿参数的超大模型，且业务场景涉及超长文本(标书)分析。
b.经过算法团队测算，模型静态权重即占用42GB显存。
c.请务必确保供应的Ascend 910B为64GB显存版本。
d.若仅能提供32GB版本，则每台服务器必须插2张卡，且服务器系统内存必须从64G升级到256G以支撑分布式通信开销。
e.在这套16C/64G的服务器底座上，单张32G显卡是由于物理限制绝对无法运行的。
c.昇腾专属配置梯度方案(Ascend Tiered Solutions)
既然配置可以加大，强烈建议跳过16C/64G的陷阱，直接采用以下三种经过验证的全昇腾(All-Ascend)架构方案。这些方案均完全符合信创要求，且能保障系统的长期可用性。
a.方案A:紧凑型(Compact) - "单机满配，高性价比"
a.定位
最小化起步，适合地市级部署或POC验证。
b.核心思路
将所有资源集中在一台高配物理机上，通过虚拟化隔离AI与业务。
c.组件规格配置(单台)
a.服务器
a.鲲鹏920(32核/2.6GHz)。
b.数量: 1。
c.选型与升级理由
CPU从16核升级到32核，保障OS和Docker不卡顿。
b.内存
a.256GB DDR4 ECC。
b.数量: 1。
c.选型与升级理由
(关键升级)内存扩大4倍，确保模型加载和向量库有充足空间，杜绝Swap导致的性能雪崩。
c.NPU
a.Ascend 910B(64GB显存)。
b.数量: 1。
c.选型与升级理由
单卡64G是底线，确保单卡能完整加载72B模型，无需复杂的分布式通信。
d.存储
a.3.84TB NVMe SSD。
b.数量: 1。
c.选型与升级理由
模型加载速度提升10倍(相比SATA)。
b.方案B:标准型(Standard) - "生产基石，双机高可用"
a.定位
省级/总部生产环境，要求7x24高可用，支持高并发评标。
b.核心思路
算力与业务物理分离。AI节点专跑推理，应用节点专跑业务。
c.角色规格配置(建议)
a.AI算力节点
a.CPU: 鲲鹏920(48核)。
b.RAM: 512GB。
c.NPU: Ascend 910B(32G/64G) x 2 (双卡)。
d.数量: 2。
e.选型与升级理由
(关键升级)双卡互联提供更强的推理吞吐(TP=2)。512G内存提供了巨大的Buffer，支持超长标书(32k+)处理。两台机器互为HA热备。
b.业务应用节点
a.CPU: 鲲鹏/海光(32核)。
b.RAM: 256GB。
c.GPU: T4/Ascend 310。
d.数量: 2。
e.选型与升级理由
独立的业务服务器，跑达梦数据库和OCR。256G内存确保数据库在高并发时依然流畅。
c.方案C:高性能型(Performance) - "训推一体，数据湖架构"
a.定位
集团级AI中台，具备本地微调(SFT)能力和海量历史数据分析能力。
b.核心思路
引入NVLink/HCCS全互联架构，从"跑模型"进化到"训模型"。
c.组件规格配置
a.AI训练集群
a.华为Atlas 800(9000)。
b.CPU: 鲲鹏64核 x 4。
c.RAM: 1TB+。
d.NPU: Ascend 910B x 8 (全互联)。
e.数量: 1。
f.选型与升级理由
8卡全互联是进行72B模型全参微调的门槛。只有这样配置，才能利用私有数据让模型变得更聪明。1TB内存用于加载大规模训练数据集。
b.分布式存储
a.多节点Ceph集群(HDD + NVMe Cache)。
b.数量: 3+。
c.选型与升级理由
PB级存储，将最近10年的所有标书非结构化数据全部入库，构建集团级知识资产。
d.方案对比总结
a.特性对比
a.现有丐版(16C/64G)
可用性: ❌(高风险OOM)，LLM能力: 勉强启动(慢)，标书长度: <4k token，采购建议: 不推荐。
b.紧凑型(A)
可用性: ✅(可用)，LLM能力: 流畅推理，标书长度: ~16k token，采购建议: 预算有限时选。
c.标准型(B)
可用性: ✅✅(高可用HA)，LLM能力: 高并发推理，标书长度: ~32k token，采购建议: 强烈推荐。
d.高性能型(C)
可用性: ✅✅✅(极致性能)，LLM能力: 推理 + 微调，标书长度: ~128k token，采购建议: 有科研/训练需求选。
d.最终采购建议清单(BOM)
请拿着这张表去和供应商谈判。
a.必须项(Must Have)
a.所有AI服务器内存必须>= 256GB(这是最廉价的性能保障)。
b.昇腾910B必须确认显存版本(推荐64G，若32G则必须每台双卡)。
c.系统盘必须是NVMe SSD(>= 1TB)，否则模型加载需要10分钟。
b.可选项(Nice to Have)
a.网卡升级为25Gb或100Gb RoCE(如果做多机训练则必须)。
b.数据盘组RAID10。
e.全昇腾升级预算估算(All-Ascend Budget)
本方案为全栈信创升级方案，假设替换现有的老旧x86资产，采用全新的国产化高性能硬件。报价含税，不含软件授权费。
a.方案A:紧凑型(Compact) - "单机硬抗"
a.总预算预估
¥220,000 - ¥250,000。
b.明细
a.鲲鹏服务器准系统(32核/256G内存/NVMe)
a.数量: 1台。
b.单价估算: ¥60,000。
c.总价: ¥60,000。
d.说明: 基础底座。
b.Ascend 910B(64G)
a.数量: 1张。
b.单价估算: ¥140,000。
c.总价: ¥140,000。
d.说明: 核心算力卡。
c.基础软件授权
a.数量: 1套。
b.单价估算: ¥20,000。
c.总价: ¥20,000。
d.说明: OS/中间件。
d.合计
¥220,000，入门推荐。
b.方案B:标准型(Standard) - "双机热备"
a.总预算预估
¥950,000 - ¥1,050,000。
b.明细
a.AI算力节点(满配)(48核/512G/双卡910B)
a.数量: 2台。
b.单价估算: ¥380,000。
c.总价: ¥760,000。
d.说明: 高可用核心。
b.业务应用节点(32核/256G/无NPU)
a.数量: 2台。
b.单价估算: ¥50,000。
c.总价: ¥100,000。
d.说明: 业务分离。
c.高速光交换机
a.数量: 2台。
b.单价估算: ¥30,000。
c.总价: ¥60,000。
d.说明: 互联网络。
d.达梦数据库授权
a.数量: 1套。
b.单价估算: ¥100,000。
c.总价: ¥100,000。
d.说明: 商业版授权。
e.合计
¥1,020,000，生产环境必选。
c.方案C:高性能型(Performance) - "训推一体"
a.总预算预估
¥1,800,000+。
b.说明
此方案主要是Atlas 800训练服务器的成本(约150万)，加上配套的高性能存储与网络设备。适合有模型微调(SFT)或增量预训练需求的集团级客户。
02.部署方案
a.适用范围声明
本方案专为21.硬件(全昇腾).md定义的纯信创架构设计。
a.核心特征
彻底移除NVIDIA显卡。所有AI算力(LLM, OCR, Embedding)均由Ascend 910B承担；所有业务与数据库运行在国产CPU(鲲鹏)上。
b.部署目标与约束
本方案旨在构建一个100%国产化的AI招采平台，符合最严格的信创标准。
a.硬件底座(基于标准型配置)
a.Node-1, Node-2(AI算力池)
a.配置: 鲲鹏920(48核) / 512G RAM / Ascend 910B(x2)。
b.角色: 运行LLM、OCR推理、向量提取。
b.Node-3, Node-4(业务应用组)
a.配置: 鲲鹏920(32核) / 256G RAM / 无加速卡。
b.角色: 运行达梦数据库、中间件、Web后端、Milvus(CPU版)。
c.物理拓扑与应用分布图
a.AI算力集群(Node-1 & Node-2)
a.昇腾NPU负载
a.MindIE Service(LLM推理)。
b.MindX SDK(OCR/CV推理)。
b.Qwen2.5-72B -.-> MindIE。
c.PP-OCRv4-Ascend -.-> MindX。
b.业务应用集群(Node-3 & Node-4)
a.信创中间件
a.智能客服后端。
b.供应商审核后端。
c.智能评标后端。
b.数据持久化
a.达梦数据库DM8 DSC。
b.Milvus向量库(CPU RAM模式)。
c.调用关系
a.Middleware == gRPC/RoCE ==> MindIE。
b.Middleware == HTTP ==> MindX。
c.Middleware <--> Dameng。
d.Middleware <--> Milvus。
d.详细资源分配策略
a.Node-1 & Node-2:统一AI算力底座
由于Ascend 910B算力非常强大，将LLM和小模型(OCR)进行切分部署。
a.组件
a.LLM推理
a.运行环境: MindIE。
b.资源配额: NPU 0,1(双卡)。
c.说明: 运行Qwen2.5-72B。独占主要算力。
b.OCR服务
a.运行环境: MindX SDK。
b.资源配额: NPU虚拟切片 / CPU。
c.说明: 利用910B的空闲算力或强大的48核CPU进行文档解析。
c.Embedding
a.运行环境: MindSpore。
b.资源配额: CPU / NPU。
c.说明: 标书切片向量化。
b.Node-3 & Node-4:纯鲲鹏应用环境
利用这两台机器的大内存(256G/512G)优势，弥补没有GPU加速向量检索的短板。
a.Milvus(CPU版)
a.配置: 分配64G - 128G内存。
b.性能: 利用IV_FLAT或HNSW索引，在纯内存模式下，百万级向量检索延迟依然可控制在10ms以内。
b.达梦数据库(DM8)
a.配置: 部署DSC(数据共享集群)，实现双机热备高可用。
e.关键技术难点与解决方案
a.OCR的昇腾适配
a.挑战
传统的PaddleOCR基于CUDA。
b.解法
使用Huawei MindX SDK(mxVision)或PaddlePaddle Ascend版本。
a.需要将OCR模型转换为.om(Offline Model)格式。
b.部署为独立的Inference Service，对外暴露API。
b.向量库去GPU化
a.挑战
失去T4加速，向量搜索可能变慢。
b.解法
a.加大内存: 既然没有显存，就用内存换时间。256G内存足以将所有索引常驻RAM。
b.算法优化: 使用HNSW索引(内存消耗大但CPU搜索极快)，替代IVF_PQ。
c.跨节点RDMA通信
a.配置
Node-1/2与Node-3/4之间建议通过RoCE(RDMA over Converged Ethernet)网卡连接，降低应用层访问AI算力的延迟。
f.实施步骤
a.基础设施
安装麒麟V10 SP3，配置NPU驱动(CANN 8.0+)。
b.模型转换
使用atc工具将Qwen和OCR模型转为昇腾适配格式。
c.服务拉起
a.在Node-1/2启动MindIE Server。
b.在Node-3/4启动达梦DSC和Milvus。
d.联调压测
验证纯CPU模式下的Milvus检索性能是否满足<500ms的业务要求。
03.AI智能客服
a.版本声明
本文档适配纯信创全昇腾架构，所有AI算力均基于Huawei Ascend。
b.业务背景与痛点
a.业务场景
a.主体
企业电子商务平台。
b.服务对象
供应商(30-50个/天电话咨询)。
c.业务场景
a.供应商注册登录问题。
b.招投标流程咨询。
c.资质文件要求咨询。
d.系统使用操作指导。
e.政策规则解释。
b.现状痛点
a.耗时久
目前每天需接打30-50个左右供应商电话，答复不够及时，供应商体验差，响应慢。
b.效率低
问题重复性高，需要处理供应商注册、登录、招投标等一系列问题，人工成本高，效率低。
c.服务不标准
不同客服人员对同一问题的回答可能不一致，服务质量不稳定。
d.知识分散
FAQ、产品文档、政策规则分散在不同系统，难以快速查找，信息获取耗时。
e.人工成本高
需要大量客服人员支持30-50个电话/天，人力成本高。
c.核心目标
a.降低人工成本
减少50%以上客服人力投入，客服人力减少50%。
b.提升服务效率
响应时间从分钟级降低到秒级，平均响应时间<10秒。
c.标准化服务
统一的回答质量，100%可追溯，所有问题有标准答案。
d.24/7服务
支持全天候服务，全天候可用。
c.核心需求分析
a.功能需求
a.面向供应商的前端交互
a.网站首页嵌入智能客服按钮及弹窗。
b.常见问题快捷入口。
c.悬浮聊天窗口。
d.移动端支持。
b.对话管理功能
a.基础对话功能
a.多轮对话支持。
b.对话历史记录。
c.上下文理解(记住之前说过什么)。
d.支持图片/文档上传咨询。
b.高级对话功能
a.多种输入方式(文字、图片、语音)。
b.富媒体消息处理。
c.会话转人工(超出AI能力时)。
d.对话质量评价。
c.知识库支持
a.FAQ(常见问题)。
b.流程型知识(招投标流程、注册流程)。
c.产品/服务文档。
d.政策/规则/法规。
e.业务系统动态数据。
b.性能需求
a.并发支持
50-100个并发会话，开标时刻峰值需求。
b.响应时间
P95<3秒，用户提问到首字响应时间。
c.会话时长
平均2-5分钟/会话，供应商咨询平均时长。
d.可用性
>99.5%，系统正常运行时间占比。
e.准确率
FAQ命中率>80%，常见问题自动解答比例。
d.技术要求
a.架构设计(All-Ascend)
a.信创终端(国产PC/移动端)
统信/奇安信浏览器 + OFD阅读控件 + 国密UKey。
b.国密安全网关(WAF)
流量清洗 + 访问控制 + SM2卸载。
c.AI应用中枢(Node-3/4鲲鹏CPU)
东方通TongWeb V7 + 对话/意图管理模块。
d.国产大模型推理服务
Qwen-Ascend @ Node-1。
e.向量与知识检索服务
Milvus CPU版 @ Node-3。
f.数据持久化层(信创数据库)
达梦Dameng DM8 DSC集群 + 审计日志，关键字段SM4加密存储。
b.核心技术组件
a.对话管理
a.会话存储。
b.上下文管理。
c.会话管理。
d.意图识别(via MindIE)。
e.知识检索(via Milvus CPU)。
f.上下文整合。
g.生成回复。
h.记录日志。
b.模型选择
a.Qwen2.5-72B(Int4)
72B，复杂对话、逻辑推理(MindIE)，⭐⭐⭐⭐⭐。
b.Qwen2.5-VL
32B，多模态咨询(图片+文字)，⭐⭐⭐⭐。
c.MindX OCR
图片文档识别(昇腾版)，⭐⭐⭐⭐。
c.接口设计
a.对话接口(FastAPI)
a.ChatMessage
a.session_id: str。
b.message: str。
c.media: Optional[str] = None (图片/文件上传)。
b.chat(websocket)
a.创建会话。
b.接收消息。
c.处理消息。
d.发送回复。
e.关闭会话。
d.部署拓扑(全昇腾版)
a.硬件资源清单
a.AI节点(Node-1/2)
鲲鹏920(48核)/512G + 昇腾910B(x2)，运行LLM。
b.业务节点(Node-3/4)
鲲鹏920(32核)/256G，运行App, Milvus(纯内存模式), Dameng。
b.docker-compose.yml
a.chat-service
对话服务(运行于Node-3鲲鹏CPU)。
b.milvus-cpu
向量数据库(运行于Node-3)，使用CPU版本，利用256G大内存。
c.knowledge-base
知识库管理后台。
e.业务价值与ROI
同通用版。
f.关键技术点
a.意图识别(MindIE适配)
使用langchain的LLMChain，适配信创MindIE推理服务。
b.向量检索(CPU优化)
a.vectorstore = Milvus。
b.embedding_function = HuggingFaceEmbeddings。
c.model_kwargs = {'device': 'cpu'} (CPU推理Embedding)。
d.index_params = {"index_type": "HNSW", "metric_type": "L2"} (HNSW适合纯内存)。
g.总结
本方案在完全去除NVIDIA显卡的前提下，通过合理的存算分离(NPU算/CPU存)设计，实现了智能客服系统的全信创交付。利用昇腾910B的强大算力保障对话流畅度，利用鲲鹏服务器的大内存保障知识库检索速度。
04.供应商智能审核
a.版本声明
本文档适配纯信创全昇腾架构，OCR与LLM均运行于NPU。
b.业务背景与痛点
同通用版。
c.核心需求分析
a.功能需求
a.审核流程。
b.审核要素。
d.技术要求
a.审核架构设计(All-Ascend)
a.供应商注册/变更申请(OFD/PDF)。
b.Node-3:业务应用服务器 - 鲲鹏CPU/256G
a.审核工作台(Java)
流程编排 + 展现。
b.规则引擎(Python)
逻辑判断 + 评分。
c.达梦数据库DM8(DSC集群)
存储数据、规则、SM4加密信息。
c.Node-1/2:昇腾AI算力服务器 - NPU x2
a.OCR推理服务
MindX SDK + PP-OCR。
b.LLM风险评估模型
MindIE + Qwen-72B。
b.核心技术组件
a.Ascend OCR服务
a.技术栈
Huawei MindX SDK(mxVision)。
b.部署
将PP-OCR模型转换为OM格式，部署在Node-1。
c.优势
910B的算力远超T4，支持高并发PDF解析。
d.OCR远程调用代码示例(运行在Node-3)
调用昇腾OCR服务。
b.审核规则引擎
RuleEngine，逻辑代码同通用版，纯CPU执行无差异。
e.部署配置清单
a.Ascend OCR Service(Node-1)
a.Dockerfile.ascend
FROM ascend-base:8.0，MindX环境配置，COPY models/ocr.om /app/models/，CMD ["python3", "serve_ocr.py"]。
b.业务服务(Node-3)
a.version: '3.8'
b.audit-service
a.image: audit-service:latest。
b.environment
a.OCR_SERVICE_URL=http://node-1-ascend:8001。
b.LLM_SERVICE_URL=http://node-1-ascend:8000。
c.DB_URL=dm://SYSDBA:PASS@dameng-dsc:5236。
c.deploy.resources
a.limits
a.cpus: '16'。
b.memory: 32G。
f.安全与合规(国密)
a.传输
SM2 HTTPS。
b.存储
SM4加密。
c.OCR
内存处理不落盘。
g.总结
全昇腾架构下，通过网络调用(RPC)的方式，将计算密集型的OCR和LLM任务卸载到NPU节点，完美解决了国产CPU算力不足的问题，同时确保存储和业务逻辑在CPU节点的高效运行。
05.智能评标
a.版本声明
本文档适配纯信创全昇腾架构。
b.业务背景与痛点
同通用版。
c.整体架构设计(All-Ascend)
a.评标专家终端
Web评标系统 --> 信创安全网关。
b.AI算力节点(Node-1/2 Ascend)
a.MindX OCR
标书扫描。
b.MindIE LLM
智能打分。
c.Rerank模型
NPU加速。
c.业务应用节点(Node-3 CPU 256G+)
a.评标业务服务。
b.Milvus向量库
HNSW内存索引。
c.达梦数据库。
d.调用关系
a.Gateway --> Biz_Svc。
b.Biz_Svc -- 1.上传标书 --> OCR。
c.Biz_Svc -- 2.存入向量 --> Milvus。
d.Biz_Svc -- 3.申请打分 --> LLM。
e.LLM -- 4.依赖上下文 --> Milvus。
f.LLM --> Rank。
d.核心技术实现
a.长文档OCR(NPU Batch Processing)
a.部署
MindX SDK on Node-1/2。
b.特性
利用NPU的并行计算能力，支持Batch Size > 32，实现标书秒级解析。
b.向量检索(CPU Memory Heavy)
a.部署
Milvus on Node-3。
b.索引
HNSW。
c.配置
利用Node-3的256G内存，全量加载索引，实现<100ms检索。
c.LLM智能打分
a.部署
MindIE on Node-1/2。
b.并发
开启Continuous Batching支持多专家并发打分。
e.接口与代码适配
a.评分服务(Scoring Service)
a.连接昇腾LLM
a.model="Qwen2.5-72B-Instruct"。
b.openai_api_base="http://node-1-ascend:8000/v1" (纯内网NPU地址)。
c.openai_api_key="empty"。
b.连接昇腾OCR
a.ocr_url = "http://node-1-ascend:8001/ocr/predict"。
c.连接CPU版Milvus
a.connection_args={"host": "node-3-cpu", "port": "19530"}。
b.embedding use remote endpoint or local cpu。
d.score_doc
a.步骤A: 调用NPU OCR。
b.步骤B: LLM打分(RAG)。
b.部署描述
a.Node-1
MindIE(Port 8000), MindX OCR(Port 8001)。
b.Node-3
Java App(Port 8080), Milvus(Port 19530), Dameng(Port 5236)。
f.总结
本方案完全契合21.硬件(全昇腾).md的标准配置，充分发挥了存算分离架构的优势。
4.5 [2]开源环境1：英伟达
00.汇总
a.列表
一键式部署平台（6个）：LM Studio、GPT4All、Ollama、LocalAI、FastChat、Text Generation WebUI
高性能推理引擎（12个）：TensorRT-LLM、TGI、DeepSpeed-MII、llama.cpp、MLC LLM、SGLang、LMDeploy、OpenLLM、Ray Serve、Triton、AutoGPTQ、ExLlamaV2
云服务平台（7个）：HuggingFace Inference Endpoints、AWS Bedrock、Google Cloud Vertex AI、Azure OpenAI、百度千帆、阿里云百炼、腾讯云混元
特定场景平台（5个）：ChatGLM.cpp、Whisper.cpp、Stable Diffusion WebUI
b.平台对比表
按使用场景：个人(LM Studio/Ollama), 生产(vLLM/TGI), 开发(Ollama/FastChat)
按硬件支持：NVIDIA(vLLM/TRT-LLM), Apple(Ollama/llama.cpp), CPU(llama.cpp)
按模型格式：GGUF(Ollama), Transformers(vLLM/TGI)
c.趋势展望
当前趋势：性能优化, 格式统一(GGUF), 云原生, 多模态, 量化
未来方向：边缘计算, 联邦学习, 自动化, 标准化, 国产化
01.一键式部署平台
a.LM Studio
特点: 可视化界面，操作简单，支持 GGUF，跨平台，完全本地
支持的模型: Llama, Mistral, Qwen, 所有 GGUF
适用场景: 个人体验，非开发者，隐私敏感
b.GPT4All
特点: 开源免费，支持 CPU/GPU，内置模型，插件系统
支持的模型: Llama, Mistral, Phi, GPT-J, 自定义 GGUF
适用场景: 个人本地，离线部署，跨平台
c.Ollama（原版）
特点: 命令行工具，自动管理，本地 API，跨平台
支持的模型: 100+ 官方模型，GGUF，自定义 Modelfile
适用场景: 开发者快速部署，本地 API，应用集成
d.LocalAI
特点: OpenAI 兼容，多模型格式，容器化，支持语音
支持的模型: GGUF, GPTQ, SD, Whisper, Bark
适用场景: 替代 OpenAI API，私有化部署，多模态
e.FastChat
特点: 分布式支持，内置 Web 界面，学术友好
支持的模型: Vicuna, Alpaca, 所有 HF 模型
适用场景: 学术研究，分布式部署，多模型服务
f.Text Generation WebUI (Oobabooga)
特点: 功能丰富 Web 界面，扩展性强，多种采样
支持的模型: GPTQ/AWQ/GGUF, transformers, ExLlamaV2
适用场景: 高级用户，模型实验，调优
02.高性能推理引擎
a.TensorRT-LLM (重复，合并至 13/17)
特点: NVIDIA 官方优化，极致性能
b.TGI (Text Generation Inference)
特点: HuggingFace 出品，云原生，Flash Attention，动态批处理
支持的模型: 所有 HF 模型, Bloom, Llama, SD
适用场景: 云端部署, HF 模型, 容器化
c.DeepSpeed-MII
特点: 微软开发，低延迟，模型压缩
支持的模型: Llama, Bloom, OPT, transformers
适用场景: 低延迟，成本优化，Azure 部署
d.llama.cpp
特点: C++ 实现，轻量，跨平台，GGUF 创造者
支持的模型: Llama, GGUF 模型
适用场景: 资源受限，CPU 推理，Apple Silicon
e.MLC LLM
特点: TVM Runtime，跨平台，移动/Web 端支持
支持的模型: Llama, Mistral, Phi
适用场景: 移动端，Web 端，跨平台
f.SGLang
特点: 斯坦福开发，结构化生成，RadixAttention
支持的模型: Llama, Mistral, Qwen
适用场景: 结构化输出，高并发，Agent
g.TensorRT-LLM
特点: NVIDIA 官方，极致性能，FP8 量化
支持的模型: GPT, Llama, BERT
适用场景: NVIDIA GPU，生产环境，高性能
h.LMDeploy
特点: 商汤开发，TurboMind，AWQ 支持
支持的模型: Llama, InternLM, Qwen
适用场景: 国内友好，商汤模型，生产环境
i.OpenLLM
特点: BentoML 出品，云原生，易集成
支持的模型: Llama, Falcon, HF 模型
适用场景: 云原生，微服务，BentoML 集成
j.Ray Serve
特点: Ray 集成，分布式，自动扩展
支持的模型: Python 可加载模型, vLLM
适用场景: 分布式部署，大规模服务
k.Triton Inference Server
特点: NVIDIA 官方，多框架支持，云原生
支持的模型: TensorRT, ONNX, PyTorch
适用场景: 多模型服务，企业级，GPU 集群
03.云服务平台
a.HuggingFace Inference Endpoints
特点: 托管服务，自动扩展，API 访问
适用场景: 快速部署，无运维
b.AWS Bedrock
特点: AWS 托管，企业级安全，多模型
适用场景: AWS 用户，合规要求高
c.Google Cloud Vertex AI
特点: Google 托管，MLOps 集成
适用场景: GCP 用户，MLOps 需求
d.Azure OpenAI Service
特点: Microsoft 托管，数据隐私，混合云
适用场景: Azure 生态，企业用户
e.百度千帆
特点: 国产平台，企业级，国内优化
适用场景: 国内用户，合规要求
f.阿里云百炼
特点: 阿里云托管，企业级
适用场景: 国内用户，阿里云生态
g.腾讯云混元
特点: 腾讯云托管，多模态
适用场景: 国内用户，腾讯生态
04.特定场景平台
a.AutoGPTQ
专注于 GPT 量化，GPU 加速
b.ExLlamaV2
极致性能，NVIDIA GPU 优化，低延迟
c.ChatGLM.cpp
专为 ChatGLM 优化，CPU/GPU 支持
d.Whisper.cpp
专为 Whisper 优化，语音识别
e.Stable Diffusion WebUI
图像生成专用，功能丰富
05.GLM开源替代
a.列表
a.说明1
GLM 原模型 NVIDIA GPU 替代 昇腾 NPU 替代
GLM-4.7 Qwen2.5-Coder、DeepSeek-V3 Qwen2.5-72B-Instruct
GLM-4.6V Qwen2-VL、DeepSeek-VL2 Qwen2.5-VL-32B、Qwen2-VL-72B
GLM-Image FLUX.1、Stable Diffusion 3 Stable Diffusion（昇腾适配）
GLM-4-Voice Fish Speech、CosyVoice PaddleSpeech
CogVideoX Wan2.2-I2V-A14B、SkyReels-V2 HunyuanVideo
b.说明2
GLM-4.7，旗舰模型，智谱最新旗舰，具备更强的编程能力与更稳定的多步骤推理/执行能力。对话更自然，前端 Coding 更美观
GLM-4.6V，视觉推理模型，理解精度达同规模 SOTA，128K 上下文，原生支持工具调用，实现从看懂图片到自动完成任务
GLM-Image，图像生成模型，采用独创的「自回归+扩散解码器」混合架构，文字渲染达开源SOTA，尤其擅长知识密集型任务
GLM-4.5-Air，文本生成模型，GLM-4.5 的轻量版，原生融合推理、编码和智能体能力，兼顾性能与性价比，可灵活切换思考模式
GLM-4-Voice，端到端语音模型，能够直接理解和生成中英文语音，进行实时语音对话，并能根据指令改变情感、语调、语速、方言等属性
CogVideoX，视频生成模型，画面更清晰更稳定，大幅运动自然流畅，现实世界模拟、3D风格场景效果全面升级
b.文本生成模型
a.GLM-4.7 / GLM-4.5-Air 替代方案
a.方案对比表
a.NVIDIA GPU
推荐 Qwen2.5-Coder (7B/32B) 或 DeepSeek-V3 (671B)
b.昇腾 NPU
推荐 Qwen2.5-72B-Instruct (72B) 或 DeepSeek-V3 (671B)
b.NVIDIA GPU 方案
a.推荐方案 1：Qwen2.5-Coder（推荐）
a.优势: 专门的代码生成模型，支持多种语言，性能优异
b.部署方式: 使用 vLLM
c.硬件要求: 7B (24GB VRAM), 32B (80GB VRAM)
b.推荐方案 2：DeepSeek-V3（最强性能）
a.优势: 671B 参数，性能接近 GPT-4，MoE 架构
b.部署方式: vLLM 多卡部署
c.硬件要求: 8x A100 80GB 或 H100
c.昇腾 NPU 方案
a.推荐方案 1：Qwen2.5-72B-Instruct（官方支持）
a.优势: 昇腾官方支持，性能优化，中文能力强
b.部署方式: 昇腾 ModelZoo / MindSpeed
c.硬件要求: 昇腾 910B 推荐 8 卡并行
b.推荐方案 2：DeepSeek-V3（昇腾适配）
a.优势: 性能最强，社区已适配
b.部署方式: 昇腾社区教程
c.视觉推理模型
a.GLM-4.6V 替代方案
a.方案对比表
a.NVIDIA GPU
推荐 Qwen2-VL (128K 上下文) 或 DeepSeek-VL2 (64K 上下文)
b.昇腾 NPU
推荐 Qwen2.5-VL-32B 或 Qwen2-VL-72B
b.NVIDIA GPU 方案
a.推荐方案 1：Qwen2-VL（综合最佳）
a.优势: 阿里云出品，128K 上下文，支持工具调用
b.部署方式: vLLM
c.硬件要求: 7B (24GB), 72B (8x A100)
b.推荐方案 2：DeepSeek-VL2（轻量高效）
a.优势: 4.5B 轻量级，MoE 架构，适合知识密集型
b.部署方式: Transformers
c.硬件要求: 单卡 A100 40GB
c.昇腾 NPU 方案
a.推荐方案 1：Qwen2.5-VL-32B（官方支持）
a.优势: 昇腾 MindSpeed MM 官方支持，支持微调
b.部署方式: 昇腾 MindIE
c.硬件要求: 昇腾 910B 推荐 8 卡并行
d.图像生成模型
a.GLM-Image 替代方案
a.方案对比表
a.NVIDIA GPU
推荐 FLUX.1 (Flow Matching) 或 Stable Diffusion 3
b.昇腾 NPU
推荐 Stable Diffusion (适配版)
b.NVIDIA GPU 方案
a.推荐方案 1：FLUX.1（性能最佳）
a.优势: 顶级视觉质量，超越 MJ v6
b.部署方式: ComfyUI
c.硬件要求: 推荐 RTX 4090 或 A100
b.推荐方案 2：Stable Diffusion 3（生态成熟）
a.优势: 生态成熟，插件丰富
b.部署方式: Automatic1111 WebUI
c.硬件要求: 推荐 16GB+ VRAM
c.昇腾 NPU 方案
a.推荐方案：Stable Diffusion（适配版本）
a.优势: 昇腾社区适配，性能优化
b.部署方式: 昇腾 ModelZoo
c.硬件要求: 昇腾 910B，32GB 内存
e.语音生成模型
a.GLM-4-Voice 替代方案
a.方案对比表
a.NVIDIA GPU
推荐 Fish Speech (中英日) 或 CosyVoice (中文)
b.昇腾 NPU
推荐 PaddleSpeech (中文)
b.NVIDIA GPU 方案
a.推荐方案 1：Fish Speech（中文最佳）
a.优势: 中文支持完美，支持方言
b.部署方式: GitHub 克隆
c.硬件要求: 推理 CPU 即可
b.推荐方案 2：CosyVoice（阿里开源）
a.优势: 达摩院出品，支持情感控制
b.部署方式: Python 脚本
c.硬件要求: 推理 CPU 即可
c.昇腾 NPU 方案
a.推荐方案：PaddleSpeech
a.优势: 百度飞桨出品，支持昇腾 NPU
b.部署方式: pip install paddlespeech paddlenpu
f.视频生成模型
a.CogVideoX 替代方案
a.方案对比表
a.NVIDIA GPU
推荐 Wan2.2-I2V-A14B 或 SkyReels-V2
b.昇腾 NPU
推荐 HunyuanVideo
b.NVIDIA GPU 方案
a.推荐方案 1：Wan2.2-I2V-A14B（阿里）
a.优势: MoE 架构，14B 参数，超越 Sora
b.部署方式: GitHub 克隆
c.硬件要求: 推荐 8x A100
b.推荐方案 2：SkyReels-V2（无限时长）
a.优势: 支持无限时长，多模态生成
b.部署方式: Python 脚本
c.硬件要求: 14B 需要 8x A100
c.昇腾 NPU 方案
a.推荐方案：HunyuanVideo（腾讯）
a.优势: 腾讯混元，昇腾适配，画面流畅
b.部署方式: 昇腾 ModelZoo
c.硬件要求: 昇腾 910B 8 卡
g.综合推荐方案
a.场景一：编程开发
a.NVIDIA GPU: Qwen2.5-Coder-32B
b.昇腾 NPU: Qwen2.5-72B-Instruct
b.场景二：多模态理解
a.NVIDIA GPU: Qwen2-VL-72B
b.昇腾 NPU: Qwen2.5-VL-32B
c.场景三：图像生成
a.NVIDIA GPU: FLUX.1
b.昇腾 NPU: Stable Diffusion
d.场景四：语音生成
a.NVIDIA GPU: Fish Speech
b.昇腾 NPU: PaddleSpeech
e.场景五：视频生成
a.NVIDIA GPU: Wan2.2-I2V-A14B
b.昇腾 NPU: HunyuanVideo
h.性能对比总结
a.文本生成
GLM-4.7 vs Qwen2.5-Coder vs DeepSeek-V3
b.视觉推理
GLM-4.6V vs Qwen2-VL vs DeepSeek-VL2
c.图像生成
GLM-Image vs FLUX.1 vs SD3
d.语音生成
GLM-4-Voice vs Fish Speech vs CosyVoice
e.视频生成
CogVideoX vs Wan2.2 vs SkyReels
4.6 [2]开源环境2：英伟达
01.硬件选型
a.业务负载与资源需求分析(Sizing)
在进行硬件选型前，需要对核心业务组件的资源消耗进行精细化估算。本系统的核心瓶颈在于大模型显存占用、OCR并发吞吐以及向量库内存开销。
a.大模型(LLM)资源估算
a.模型基座
Qwen2.5-72B-Instruct。
b.显存需求
a.FP16(原生精度)
72B x 2 Bytes = 144GB(权重) + KV Cache ≈ 160GB+(显存)。
b.Int4(量化精度)
72B x 0.7 Bytes ≈ 50GB(权重) + KV Cache(10并发) ≈ 64GB(显存)。
c.Nvidia选型结论
a.推荐
NVIDIA A800(80GB)或H800(80GB)单卡即可运行Int4/Int8版本。
b.替代
2x NVIDIA L40S(48GB)或2x RTX 4090(24GB)通过NVLink或PCIe进行Tensor Parallelism(TP)部署。
b.OCR与文档解析资源估算
a.负载类型
标书解析属于CPU密集型(版面分析) + IO密集型(PDF读取) + GPU突发型(识别)。
b.配置建议
必须配备NVMe SSD存储。GPU推荐使用通用性强的T4或L4。
c.数据库与向量检索
a.Milvus
建议使用GPU加速索引构建(CUDA)。
b.Dameng
建议分配64GB+内存做Buffer Pool。
b.推荐选型方案(All-Nvidia)
a.P1:紧凑型方案(Compact) - "RTX消费级高性价比"
a.适用场景
开发测试、演示环境、成本敏感型项目。
b.Node-1(AI一体机)
a.推荐规格
CPU: Intel Xeon / AMD EPYC(32核)，RAM: 256GB，GPU: 4x RTX 4090(24G)，Disk: 2T NVMe。
b.部署服务
LLM(Qwen-72B-Int4)(TP=4)。
c.选型理由
4张4090(96G显存)。虽然2张卡(48G)勉强能跑，但在高并发或长文档场景下极易OOM。4卡方案显存充裕，且TP=4推理速度更快。
c.Node-2(通用计算)
a.推荐规格
CPU: Intel/AMD(32核)，RAM: 128GB，GPU: 1x RTX 4090/T4，Disk: 4T SATA SSD。
b.部署服务
OCR服务、达梦DB、Web应用。
c.选型理由
负责非推理业务。
b.P2:标准型方案(Standard) - "企业级A800/L40S"
a.适用场景
正式生产环境，追求长期稳定与高并发。
b.Node-1(核心算力)
a.推荐规格
CPU: AMD EPYC 9004(64核)，RAM: 512GB，GPU: 2x NVIDIA L40S(48GB)或1x NVIDIA A800(80GB)。
b.部署服务
Qwen-72B-Int4/FP16。
c.选型理由
企业级GPU。L40S性价比极高，双卡96G显存不仅能跑72B，还能支持很大的并发量。A800单卡80G则是最简单的部署方案。
c.Node-2(业务/数据)
a.推荐规格
CPU: AMD EPYC(32核)，RAM: 256GB，GPU: 1x NVIDIA T4/L4。
b.部署服务
达梦DSC集群、OCR/Milvus、中间件。
c.选型理由
经典T4/L4卡负责OCR和向量检索。
d.Node-3(备用/监控)
a.推荐规格
CPU: 通用x86，RAM: 64GB。
b.部署服务
备份服务、Prometheus。
c.选型理由
冷备与监控。
c.P3:高性能方案(Ultimate) - "HGX训练集群"
a.适用场景
需要进行全量微调(SFT)或增量预训练。
b.Cluster A(训练模组)
a.推荐规格
Server: HGX A800/H800服务器，GPU: 8x A800(80GB)NVLink，RAM: 2TB。
b.部署服务
LLM全参微调、高并发推理。
c.选型理由
8卡NVLink全互联是训练72B模型的标准配置。
c.关键决策Q&A
a.Q1:为什么要全英伟达，不用国产卡？
a.软件生态成熟
CUDA生态无与伦比，Github上99%的开源项目(如vLLM, TensorRT-LLM, AutoGPTQ)均原生支持Nvidia，无需任何代码修改。
b.开发效率
避免了国产卡可能遇到的算子不支持、环境编译失败等"踩坑"成本，研发团队上手即用。
c.模型兼容性
新出的模型(DeepSeek, Llama3等)通常第一时间发布HuggingFace(PyTorch)权重，Nvidia卡可实现"零时差"部署。
b.Q2:4090真的能跑生产吗？
a.视情况而定。
b.4090的算力极强(TFLOPS甚至高于A800)，但受限于显存(24G)和P2P通信带宽(被阉割)。
c.对于推理(Inference)场景，建议至少4张4090(96G)以确保72B模型的稳定性。如果只有双卡，建议降级使用Qwen-32B或DeepSeek-33B。
d.对于训练，严禁使用4090，必须上A800/H800。
d.预算估算(Nvidia Only)
a.P1:紧凑型(4090方案)
a.预算预估
¥120,000 - ¥150,000。
b.明细
a.1台4卡AI工作站(含4张4090): 约8-10万。
b.1台通用服务器(含1张4090): 约3-4万。
b.P2:标准型(L40S/A800方案)
a.预算预估
¥250,000 - ¥350,000。
b.明细
a.1台AI服务器(含2x L40S): 约15-18万。
b.1台业务服务器(含T4): 约5-8万。
c.网络与配套: 3-5万。
c.P3:高性能型(HGX 8卡)
a.预算预估
¥1,500,000+。
b.明细
标准的8卡A800服务器通常在120万+。
02.部署方案
a.部署目标与约束
本方案旨在构建一个纯NVIDIA CUDA生态的智能招采平台。利用Nvidia GPU强大的通用性与成熟的软件栈(vLLM, Triton)，实现高性能、低延迟的推理服务。
a.核心硬件底座
a.计算框架
CUDA 12.x。
b.推理引擎
a.LLM: vLLM(推荐)或TensorRT-LLM(极致性能)。
b.OCR: PaddleOCR(GPU版)或MinerU。
c.节点规划
a.Node-1(AI Core)
搭载A800/L40S/4090，运行Qwen-72B。
b.Node-2(Business)
搭载T4/L4，运行OCR、Milvus、应用服务。
b.物理拓扑与应用分布图
a.AI计算集群(Node-1)
a.Nvidia GPU #1 -> vLLM Inference Server。
b.Nvidia GPU #2 -> vLLM Inference Server。
c.vLLM -- OpenAI API Protocol --> Qwen2.5-72B-Int4。
b.应用服务集群(Node-2)
a.CUDA工作负载
a.OCR Service(Paddle/MinerU)。
b.Milvus Vector DB(GPU)。
c.Embedding Service(TEI)。
b.业务中间件
a.智能客服。
b.供应商审核。
c.智能评标。
c.数据存储
a.达梦数据库DM8。
b.缓存。
c.调用关系
a.vLLM <==> HTTP/gRPC ==> Middleware。
b.Middleware <--> GPU_Workload。
c.Middleware <--> Data。
c.详细资源分配策略
a.LLM推理服务(Node-1)
a.软件栈
vLLM(Versatile LLM Serving)，吞吐量极高(PagedAttention技术)，原生支持OpenAI API协议，无缝对接LangChain。
b.启动命令示例
python -m vllm.entrypoints.openai.api_server --model /models/Qwen2.5-72B-Instruct-GPTQ-Int4 --tensor-parallel-size 2 --gpu-memory-utilization 0.9 --port 8000。
c.显存策略
a.Int4量化模型约占用42G显存。
b.Int4量化模型约占用42G显存，加上KV Cache和运行时开销，48G(双卡)非常极限，容易OOM。
c.推荐配置
4x RTX 4090(96G)或2x L40S(96G)。96G显存可以支持32k以上的长上下文和高并发请求。
b.业务与辅助模型(Node-2)
a.OCR服务
使用官方PaddleOCR GPU Docker镜像，无需任何修改，直接利用T4/L4加速。
b.Embedding
使用TEI(Text Embeddings Inference)，HuggingFace出品，CUDA极致优化。
c.Milvus
利用Milvus的GPU索引(IVF_PQ)加速亿级向量检索。
d.关键技术配置
a.Docker Compose编排示例
a.vllm-service
LLM服务(Node-1)。
b.ocr-service
OCR服务(Node-2)。
c.chat-app
应用服务。
b.性能优化建议
a.FlashAttention-2
务必在vLLM中开启FlashAttention-2加速(需A100/A800/4090/L40S等Ampere+架构GPU)，推理速度提升2-3倍。
b.Continuous Batching
vLLM默认开启，能显著提升高并发下的吞吐量。
c.GPTQ/AWQ量化
推荐使用GPTQ-Int4或AWQ量化模型，精度损失极小，显存减半，速度翻倍。
e.实施路线图
a.环境准备
安装NVIDIA Driver, CUDA Toolkit 12.1, Nvidia-Container-Toolkit。
b.模型准备
下载Qwen2.5-72B-Instruct-Int4模型权重。
c.LLM部署
启动vLLM，进行curl测试。
d.中间件部署
启动Milvus, DM8, OCR。
e.业务上线
修改应用配置中的API Base URL，指向vLLM。
03.AI智能客服
a.业务背景与痛点
a.业务场景
a.主体
企业电子商务平台。
b.服务对象
供应商(30-50个/天电话咨询)。
c.业务场景
a.供应商注册登录问题。
b.招投标流程咨询。
c.资质文件要求咨询。
d.系统使用操作指导。
e.政策规则解释。
b.现状痛点
a.耗时久
目前每天需接打30-50个左右供应商电话，答复不够及时，供应商体验差，响应慢。
b.效率低
问题重复性高，需要处理供应商注册、登录、招投标等一系列问题，人工成本高，效率低。
c.服务不标准
不同客服人员对同一问题的回答可能不一致，服务质量不稳定。
d.知识分散
FAQ、产品文档、政策规则分散在不同系统，难以快速查找，信息获取耗时。
e.人工成本高
需要大量客服人员支持30-50个电话/天，人力成本高。
c.核心目标
a.降低人工成本
减少50%以上客服人力投入，客服人力减少50%。
b.提升服务效率
响应时间从分钟级降低到秒级，平均响应时间<10秒。
c.标准化服务
统一的回答质量，100%可追溯，所有问题有标准答案。
d.24/7服务
支持全天候服务，全天候可用。
b.核心需求分析
a.功能需求
a.面向供应商的前端交互
a.网站首页嵌入智能客服按钮及弹窗。
b.常见问题快捷入口。
c.悬浮聊天窗口。
d.移动端支持。
b.对话管理功能
a.基础对话功能
a.多轮对话支持。
b.对话历史记录。
c.上下文理解(记住之前说过什么)。
d.支持图片/文档上传咨询。
b.高级对话功能
a.多种输入方式(文字、图片、语音)。
b.富媒体消息处理。
c.会话转人工(超出AI能力时)。
d.对话质量评价。
c.知识库支持
a.FAQ(常见问题)。
b.流程型知识(招投标流程、注册流程)。
c.产品/服务文档。
d.政策/规则/法规。
e.业务系统动态数据。
b.性能需求
a.并发支持
100+并发会话，满足业务高峰需求。
b.响应时间
P95<2秒，vLLM加速推理响应极快。
c.会话时长
平均2-5分钟/会话，供应商咨询平均时长。
d.可用性
>99.9%，高可用集群架构。
e.准确率
FAQ命中率>85%，常见问题自动解答比例。
c.技术要求
a.架构设计(All-Nvidia)
a.客户端
a.Web端。
b.移动端。
b.安全网关
a.Nginx WAF。
c.AI应用中枢(Node-2 T4)
a.对话编排引擎。
b.RAG知识检索。
c.会话状态管理。
d.PostgreSQL/Redis。
d.AI推理集群(Node-1 A800/L40S)
a.vLLM Inference Server。
b.Qwen2.5-72B-Int4。
e.向量与OCR(Node-2 T4)
a.Milvus Vector DB。
b.TEI Embedding Service。
c.PaddleOCR GPU。
b.核心技术组件
a.对话管理
a.会话存储。
b.上下文管理。
c.意图识别(利用vLLM极速推理)。
d.知识检索(调用TEI生成向量，在Milvus中检索)。
e.构造Prompt。
f.生成回复(调用vLLM OpenAI接口)。
b.知识库建设
知识来源与治理流程同原设计。
c.模型与引擎选择
a.LLM Inference
vLLM，吞吐量是HuggingFace的20倍，支持PagedAttention。
b.Embedding
Text-Embeddings-Inference(TEI)，专为GPU优化的Rust实现，速度极快。
c.Model
Qwen2.5-72B-Instruct-Int4，72B尺寸兼顾智商与速度，Int4量化适配单卡80G或双卡48G。
c.接口设计
a.对话接口(FastAPI + WebSocket)
配置指向Node-1的vLLM服务，通过openai库调用。
d.部署拓扑
a.硬件资源清单
a.AI节点(Node-1)
Nvidia A800(80G)x1或L40S(48G)x2，专用于LLM推理。
b.应用节点(Node-2)
Nvidia T4(16G)x1，用于Embedding、OCR、Milvus、业务后台。
b.docker-compose编排
a.chat-service
对话业务服务(运行于Node-2)。
b.tei-service
Embedding服务(TEI，运行于Node-2 GPU)。
c.vector-db
向量数据库(Milvus GPU)。
d.业务价值
同原设计，但全英伟达架构带来了更低的维护成本(开源生态兼容性好)和更快的迭代速度(无需等待国产卡适配)。
e.关键技术点
a.意图识别与路由(LangChain on NVIDIA)
使用langchain_openai的ChatOpenAI连接vLLM服务。
04.供应商智能审核
a.业务背景与痛点
a.业务场景
同原设计，侧重于供应商资质审核、OCR识别与风险评估。
b.核心目标
需要利用GPU加速OCR识别与LLM语义分析。
b.核心需求分析
a.审核流程与要素
核心在于利用AI提取并验证信息。
c.技术要求
a.审核架构设计
a.文档输入
a.PDF/图片。
b.Node-2:应用服务器(T4)
a.OCR推理服务(PaddleOCR)。
b.规则引擎。
c.审核后台。
d.达梦/PostgreSQL。
c.Node-1:AI计算集群(A800/L40S)
a.LLM风险评估服务(vLLM)。
b.Qwen2.5-72B。
d.架构变化说明
a.LLM服务
迁移至Node-1(Nvidia GPU)，运行vLLM。
b.OCR服务
运行于Node-2(Nvidia GPU)，使用CUDA加速的PaddleOCR/MinerU。
c.通信协议
内部均为标准HTTP/gRPC(OpenAI兼容协议)。
b.核心技术组件
a.OCR与多模态处理
a.Nvidia T4对OCR任务支持极佳。
b.OCR调用示例
调用部署在Node-2的PaddleOCR服务。
b.LLM风险评估
a.将提取的文本输入LLM进行逻辑风险判断。
b.连接vLLM。
c.分析供应商信息是否存在风险，输出JSON格式的风险报告。
c.部署配置
a.Docker Compose编排
a.risk-llm
LLM风险评估服务(Node-1)。
b.ocr-server
OCR服务(Node-2)。
c.audit-backend
审核业务后台。
d.业务价值
保持原设计不变，虽然硬件变为Nvidia，但数据安全标准(加密、审计)依然可以通过软件层面(国密SSL、SM4加密库)来实现，满足一般的企业安全规范。
05.智能评标
a.业务背景与痛点
内容保持不变，侧重于提升评标效率、减少人工错误。
b.核心需求分析
内容保持不变，涵盖OCR文档识别、规则审查、AI评分等模块。
c.技术要求
a.整体架构设计(All-Nvidia)
a.Node-2:应用与数据(T4/L4)
a.OCR解析引擎。
b.Milvus向量库。
c.业务数据库。
d.评标业务后端。
b.Node-1:AI计算核心(A800/L40S)
a.vLLM Inference Cluster。
b.Qwen2.5-72B-Int4。
c.核心变更点
a.放弃Ascend/MindSpore架构，全面转向Nvidia GPU + vLLM + CUDA。
b.Node-1专用于跑大模型(vLLM)，Node-2利用T4/L4的通用性处理OCR和向量检索。
b.核心技术组件
a.安全审查与规则引擎
Python/Drools代码逻辑通用，不依赖特定硬件，保持不变。
b.大模型评分(vLLM适配)
a.评分服务。
b.连接vLLM推理服务(OpenAI兼容接口)。
c.Chain定义保持不变。
c.辅助评审(OCR与比对)
使用基于CUDA加速的OCR引擎(如MinerU或PaddleOCR)，利用Nvidia T4的Tensor Core加速推理。
c.模型与组件选型
a.LLM
Node-1(Nvidia)，Qwen2.5-72B-Int4运行于vLLM，利用A800/L40S强大算力。
b.OCR
Node-2(Nvidia)，MinerU/PaddleOCR(CUDA版本)，利用T4通用性处理PDF。
c.Vector DB
Node-2(Nvidia)，Milvus GPU版，利用GPU加速索引构建与查询。
d.RDBMS
Node-2，达梦DM8或PostgreSQL。
d.接口设计
FastAPI接口保持不变。
e.部署架构
a.docker-compose.yml
a.scoring-service
评标核心服务。
b.vllm-service
大模型服务(模拟Node-1上运行)。
d.业务价值与安全合规
内容保持不变。
4.7 [3]部署生态：vllm
01.生态说明
a.概述
vLLM 是一个快速、易用的大语言模型推理和服务库，由 UC Berkeley Sky Computing Lab 原创开发，现已演变为社区驱动项目。
vLLM 支持生成式和池化模型，涵盖各种任务类型。
b.核心特性
a.性能优化
PagedAttention：高效的注意力键值内存管理
连续批处理：对传入请求的连续批处理
CUDA/HIP 图：快速的模型执行
量化支持：GPTQ、AWQ、INT4、INT8、FP8
优化的 CUDA 内核：集成 FlashAttention 和 FlashInfer
推测解码：加速推理过程
分块预填充：优化长文本处理
b.易用性
与 HuggingFace 模型无缝集成
多种解码算法：并行采样、束搜索等
多种并行支持：张量、流水线、数据和专家并行
流式输出支持
OpenAI 兼容 API 服务器
多硬件支持：NVIDIA GPU、AMD CPU/GPU、Intel CPU/GPU、PowerPC CPU、Arm CPU、TPU
前缀缓存支持
多 LoRA 支持
c.模型实现方式
a.vLLM 原生实现
位置：vllm/model_executor/models
特点：性能最优，专门针对 vLLM 优化
支持功能：完整的 vLLM 功能集
b.Transformers 建模后端
性能：在专用 vLLM 实现的 5% 性能范围内
支持模态：嵌入模型、语言模型、视觉语言模型*
支持架构：仅编码器、仅解码器、混合专家
注意力类型：完整注意力和/或滑动注意力
c.自定义模型
即使模型不受 vLLM 或 Transformers 原生支持，仍可在 vLLM 中使用！
-------------------------------------------------------------------------------------------------
要求：
Transformers 兼容的自定义模型
或 vLLM 建模后端兼容的模型
-------------------------------------------------------------------------------------------------
使用方法：
在 Hugging Face Model Hub 上：设置 `trust_remote_code=True`
在本地目录：传递目录路径给 `model=<MODEL_DIR>`
02.模型选择
a.支持的模型架构
a.文本生成模型（生成式）
a.国际主流模型
Llama 3.1/3/2, Mistral, Mixtral, Gemma 2/3, Phi-3/4, Qwen2, DeepSeek-V3, Falcon, Bloom 等
b.国内主流模型
Qwen, ChatGLM, GLM-4, Baichuan2, InternLM2/3, Yi
c.其他模型
GPT-2, GPT-J, MPT, OPT, Solar Pro, Mamba
b.多模态模型
a.视觉语言模型
LLaVA, Qwen2-VL, GLM-4V, PaliGemma, Phi-3-Vision, InternVL, MiniCPM-V, Molmo
b.音频模型
Whisper, Qwen2-Audio, Granite Speech
c.池化模型
a.嵌入模型
BERT, Gemma2, Llama, Qwen2
b.分类模型
Jamba, GPT2
c.重排序模型
BERT, Gemma, Qwen2
b.模型加载方式
a.从 Hugging Face Hub 加载
llm = LLM(model="meta-llama/Meta-Llama-3.1-8B-Instruct")
b.从本地目录加载
llm = LLM(model="/path/to/local/model")
c.使用 ModelScope
export VLLM_USE_MODELSCOPE=True
c.硬件支持
a.GPU 支持
NVIDIA GPU (完整支持), AMD GPU, Intel GPU
b.CPU 支持
Intel, AMD, PowerPC, Arm
c.其他加速器
TPU, Intel Gaudi, IBM Spyre, 华为昇腾 (插件支持)
03.vLLM部署Qwen系列
a.说明
a.概述
本文档详细说明使用 vLLM 部署主流 Qwen/Qwen3 系列模型（如 Qwen3-4B、Qwen3-8B、Qwen3-32B）进行推理时的显存（VRAM）需求预估与显卡类型建议。
b.核心影响因素
是否启用量化（如 FP8 / AWQ 4-bit）- 显存大幅下降
上下文窗口长度（max_model_len）- KV 缓存显存占用
并发请求数 - KV Cache 叠加效应
vLLM 预留比例（--gpu-memory-utilization 默认为 0.9）
b.显存构成原理
a.显存使用公式
a.公式
显存需求 = 模型静态显存 + (每个请求 KV Cache × 并发数) + 运行开销
b.各组成部分说明
固定资源：
模型静态显存：模型本身的权重（量化可显著降低）
框架运行开销：CUDA 内核、vLLM 框架结构开销等
---------------------------------------------------------------------------------------------
动态资源：
KV Cache：随上下文长度线性增长
并发叠加：每个请求独立的 KV Cache
b.vLLM内存管理机制
vLLM 通过自动内存分析来决定可用于 KV Cache 的空间：
1.Profile 模型权重显存使用
2.计算剩余显存可用于 KV Cache
3.根据上下文实际情况动态分配内存
c.各模型规模显存需求对比
a.Qwen3-4B 显存需求
a.原始浮点（FP16/BF16）版本
典型显存需求: ~8-10GB
模型权重: ~7.5GB
b.量化版本（FP8 / AWQ 4-bit）
量化后显存需求: ~5-7GB
显存节省: ~30-50%
c.显卡建议
入门: RTX 4090 / A5000 / A100 40GB
大上下文: A100 80GB
b.Qwen3-8B 显存需求
a.原始浮点（FP16/BF16）版本
显存需求: ~15-20GB
b.量化版本（FP8 / AWQ 4-bit）
显存需求: ~8-12GB
c.显卡建议
单卡: RTX 4090, A6000
高并发: A100 80GB
c.Qwen3-32B 显存需求
a.原始浮点（FP16/BF16）版本
模型权重: ~30+GB
单卡最低要求: >= 40GB (可能不足)
b.量化版本（AWQ / 更低位量化）
AWQ 4-bit: ~16-20GB (权重部分)
c.显卡与策略建议
单卡: A100/H100 80GB
多卡: 2×H100 80GB 或 4×A100 40GB
d.显存预算计算方法
a.基础计算公式
Required VRAM >= ModelStatic + (PerRequestKV × TargetConcurrency)
参数说明：
ModelStatic：模型静态显存（权重 + 框架开销）
PerRequestKV：单个请求的 KV Cache 大小
TargetConcurrency：目标并发数
b.KV Cache 与上下文关系
KV Cache 的显存大小约随上下文**线性增长**
上下文长度越长，KV 占比越高
长上下文（如 32k）可能消耗非常大的显存部分
c.并发显存成本（经验数据）
从社区 vLLM 部署经验观察（7B 模型示例）：
可用显存 最大并发 备注
10.6 GB ~5 req/s 基础显存用于模型 + KV cache
13.0 GB ~20 req/s 每请求约 0.16 GB KV cache
18.1 GB ~50 req/s 并发显存线性增长
-------------------------------------------------------------------------------------------------
经验结论：
每增加 1 个并发请求 ≈ 0.16 GB KV cache（7B 级模型、短上下文）
更大模型（8B/32B）单位 KV Cache 会更高
上下文更长 → 每请求 KV 显存更大
e.量化方案对比
a.量化格式对比表
量化格式 显存节省 性能影响 精度损失 适用场景
FP16/BF16 基准 无 无 高精度要求
FP8 约 30-40% 轻微 轻微 平衡性能与精度
AWQ 4-bit 约 50-60% 轻微 可控 显存受限场景
GPTQ 4-bit 约 50-60% 轻微 可控 同上
b.量化建议
优先级排序：
1.显存充足：使用 FP16/BF16
2.显存紧张：优先考虑 FP8 量化
3.极端受限：考虑 AWQ/GPTQ 4-bit
f.vLLM 核心参数配置
a.关键参数说明
参数 作用 建议值
--gpu-memory-utilization GPU 总显存比例用于模型 + KV cache 0.8-0.95
--tensor-parallel-size 多卡切分模型权重 大模型建议启用 TP
--max-num-batched-tokens 最大批内 token 数 控制批次容量
--max-num-seqs 最大同时序列数 限制并发数
--swap-space CPU offload 空间（GB） 配合 CPU RAM
--max-model-len 最大上下文长度 根据业务需求
--dtype 数据类型 fp16/bf16/fp8
b.参数设定逻辑
a.场景1：单卡、低并发、短上下文
配置策略：
gpu_memory-utilization = 0.9
max-num-seqs = 2-4
若显存不足，降至 0.7
b.场景2：长上下文（32k）、中等并发
配置策略：
增加 CPU offload：--swap-space 10-20
gpu-memory-utilization = 0.8
限制并发量避免 OOM
c.场景3：高并发生产环境
配置策略：
使用 2+ GPU 并启用 tensor parallel
按预算公式规划显存
利用 continuous batching 提高利用率
g.典型配置示例
a.单卡部署 8B 模型（上下文 8K，并发 4）
vllm serve Qwen3-8B \
--gpu-memory-utilization 0.9 \
--max-num-seqs 4 \
--max-num-batched-tokens 20480 \
--swap-space 10 \
--tensor-parallel-size 1 \
--max-model-len 8192
b.配置说明
GPU 显存利用率 90%
最大并发 4 个序列
CPU offload 10GB
最大上下文 8192 tokens
04.重点案例：Qwen3-32B FP16 32K 上下文并发 5 部署方案
a.基本分析
a.需求规格
参数 数值
模型 Qwen3-32B
精度 FP16
上下文长度 32,768 tokens
并发数 5
b.关键显存消耗构成
a.模型权重显存（32B 参数，FP16）
32B × 2 字节 = 64GB 显存（权重部分）
现实中可达 64-70GB（含碎片与内核开销）
b.KV Cache 显存（长上下文）
KV Cache 与上下文长度线性相关
32K 上下文对大模型约消耗 5GB 级别显存用于 KV cache
c.并发叠加显存（5 个并发）
单请求 KV Cache ≈ 5GB（32K 上下文）
5 并发 ≈ 5 × 5GB = 25GB
d.CUDA/框架开销与保留空间
vLLM 会预留显存用于 CUDA kernels、buffers 等
大约需要 **5-10GB** 额外空间
c.显存需求合计
消耗项 估算显存
模型权重（FP16） ~64GB+
KV Cache（32K × 5 并发） ~20-25GB
框架额外开销 ~5-10GB
合计 ~90-100GB 以上（单卡）
b.部署方案结论
a.单卡方案
显存不足 (H100/A100 80GB 均不够) ❌
b.方案A: 2×H100 80GB (推荐)
a.命令
vllm serve "Qwen/Qwen3-32B" \
--dtype fp16 \
--tensor-parallel-size 2 \
--max-model-len 32768 \
--max-num-seqs 5 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.8 \
--enable-chunked-prefill \
--enable-prefix-caching
b.优势
每张卡分担一半权重
单卡实际权重显存 ~32-35GB
KV Cache 也会分布
上下文与并发能力充足
c.方案B: 2×A100 80GB
a.命令
vllm serve "Qwen/Qwen3-32B" \
--dtype fp16 \
--tensor-parallel-size 2 \
--max-model-len 32768 \
--max-num-seqs 5 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.8
b.特点
可用但性能略低于 H100
成本相对较低
d.方案 C：4×A100 40GB（稳定方案）
a.命令
vllm serve "Qwen/Qwen3-32B" \
--dtype fp16 \
--tensor-parallel-size 4 \
--pipeline-parallel-size 1 \
--max-model-len 32768 \
--max-num-seqs 5 \
--gpu-memory-utilization 0.75
b.优势
权重与 KV 更细粒度分布
上下文与并发更稳妥
降低单卡显存压力
c.相关细节
a.参数详解
参数 值 说明
--dtype fp16 使用 FP16 精度
--tensor-parallel-size 2 2 卡 Tensor Parallel
--max-model-len 32768 最大上下文 32K
--max-num-seqs 5 限制并发数为 5
--max-num-batched-tokens 16384 批次 token 限制
--gpu-memory-utilization 0.8 保留 20% 显存给 CUDA kernels
--enable-chunked-prefill - 分块预填充优化
--enable-prefix-caching - 前缀缓存优化
b.如果考虑量化（如 FP8 / AWQ / 4-bit），量化替代方案
a.显存节省对比
方案 模型权重显存 总显存需求（估算）
FP16 ~64GB ~90-100GB
FP8 ~32GB ~50-60GB
AWQ 4-bit** ~16GB ~35-45GB
b.量化版部署（AWQ）
vllm serve "Qwen/Qwen3-32B-AWQ" \
--quantization awq \
--max-model-len 32768 \
--max-num-seqs 5 \
--gpu-memory-utilization 0.85
c.注意事项
量化对长上下文任务可能有性能/准确性影响
需权衡显存节省与精度损失
d.显卡选择建议矩阵
a.按模型规模分类
| 模型 | 上下文 | 并发数 | 单卡显存预算 | 推荐显卡 |
|------|--------|--------|-------------|---------|
| **4B** | 8k | 5 | 12-16GB | RTX 4090 / A100 40GB |
| **8B** | 8k | 5 | 24-32GB | RTX 4090 / A6000 / A100 40GB |
| **8B** | 32k | 3 | 32-40GB | A100 40GB / A100 80GB |
| **32B** | 8k | 1-2 | 60-80GB | A100/H100 80GB（单卡或 TP） |
| **32B** | 32k | 1 | 80GB+ | 2×H100 80GB 或 4×A100 40GB |
b.核心原则
上下文越长 → 显存消耗越大
并发越多 → 显存线性增长
模型越大 → KV Cache 单位显存需求越大
上下文越长/并发越多/模型越大 -> 显存需求越大
e.实战部署步骤
a.显存预算规划流程
步骤 1：选择量化策略
量化优先，显存能大幅降低
确定使用 FP16/BF16/FP8/AWQ
-------------------------------------------------------------------------------------------------
步骤2：测试单请求显存占用
使用 vLLM 内部 profiling
`gpu_memory-utilization` 默认 0.9 会做 profiling
-------------------------------------------------------------------------------------------------
步骤3：测试 KV Cache 占用
用实际上下文长度测试
生成最大上下文输入，观察 KV Cache 使用
-------------------------------------------------------------------------------------------------
步骤4：按目标并发逐步测试
逐步增加 `max-num-seqs`
测试显存峰值
对比显存预留 → 超过则降低并发或启用 CPU offload
b.优化参数调整顺序
1.降低 `gpu-memory-utilization`（从 0.9 → 0.8 → 0.7）
2.减少 `max-num-seqs`（限制并发数）
3.启用 CPU offload（设置 `--swap-space`）
4.考虑多卡 TP（`--tensor-parallel-size`）
5.考虑量化（FP8/AWQ）
f.常见问题与优化
a.Q1: 显存不足怎么办？
解决方案（按优先级）：
1.降低 `gpu-memory-utilization` 至 0.7-0.8
2.减少并发数 `max-num-seqs`
3.启用 CPU offload `--swap-space`
4.使用量化版本（FP8/AWQ）
5.启用多卡 tensor parallel
b.Q2: 如何提高并发能力？
优化方向：
1.增加显卡数量（tensor parallel）
2.启用 prefix caching
3.启用 chunked prefill
4.使用量化降低单请求显存
c.Q3: 长上下文优化建议？
配置建议：
启用 `--enable-chunked-prefill
启用 `--enable-prefix-caching
适当降低 `gpu-memory-utilization
考虑 KV Cache offload
d.Q4: 生产环境部署建议？
最佳实践：
1.使用多卡 tensor parallel
2.启用所有优化特性
3.预留 20% 显存缓冲
4.监控显存使用情况
5.设置合理的并发限制
g.快速参考
a.显存需求快速查询表
| 模型 | 精度 | 上下文 | 并发 | 所需显存 | 推荐配置 |
|------|------|--------|------|---------|---------|
| Qwen3-4B | FP16 | 8K | 5 | ~10GB | 单卡 16GB |
| Qwen3-8B | FP16 | 8K | 5 | ~20GB | 单卡 24GB+ |
| Qwen3-8B | FP16 | 32K | 3 | ~35GB | 单卡 40GB+ |
| Qwen3-32B | FP16 | 8K | 2 | ~70GB | 双卡 80GB |
| Qwen3-32B | FP16 | 32K | 5 | ~95GB | 双卡 80GB |
| Qwen3-32B | AWQ | 32K | 5 | ~40GB | 单卡 80GB |
b.vLLM 命令模板
基础模板：
vllm serve <MODEL_NAME> \
--dtype <DTYPE> \
--tensor-parallel-size <TP_SIZE> \
--max-model-len <CONTEXT_LENGTH> \
--max-num-seqs <CONCURRENCY> \
--gpu-memory-utilization 0.8-0.9
-------------------------------------------------------------------------------------------------
生产环境模板：
vllm serve <MODEL_NAME> \
--dtype fp16 \
--tensor-parallel-size 2 \
--max-model-len 32768 \
--max-num-seqs 5 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.8 \
--enable-chunked-prefill \
--enable-prefix-caching \
--swap-space 10
h.总结
a.显存预算是规划的第一步
明确模型规模、上下文长度、目标并发
使用公式：Required VRAM >= ModelStatic + (PerRequestKV × TargetConcurrency)
b.32B FP16 32K 上下文并发 5 需求
单卡无法满足（~90-100GB 等效显存）
必须使用多卡 tensor parallel
推荐：2×H100 80GB 或 4×A100 40GB
c.vLLM 参数配置关键
gpu-memory-utilization：控制显存预留
max-num-seqs：限制并发避免 OOM
tensor-parallel-size：多卡分布权重
d.优化策略
优先考虑量化降低显存
长上下文需启用优化特性
生产环境建议多卡部署
4.8 [3]部署生态：ollama
01.生态说明
a.说明
a.概述
handy-ollama 是 DataWhale 出品的 Ollama 教程项目，专注于帮助开发者在 CPU 环境下玩转大模型部署。是 Ollama 官方收录的唯一 Tutorial。
b.项目定位
目标：让每一位大模型爱好者、学习者以及开发者都能在本地部署自己的大模型
特色：CPU 也能玩转大模型推理部署
理念：打破技术壁垒，让大模型时代的红利普惠到每一个人
c.零GPU部署
CPU 支持：只需 CPU 即可部署大模型
消费级硬件：在个人 PC 上实现大模型推理
低门槛：不受 GPU 资源限制
b.全方位教程
a.Ollama 介绍、安装和配置
macOS 安装与配置
Windows 安装与配置
Linux 安装与配置
Docker 安装与配置
b.Ollama 自定义导入模型
从 GGUF 导入
从 Pytorch 或 Safetensors 导入
由模型直接导入
自定义 Prompt
c.Ollama REST API
Ollama API 使用指南
Python 中使用
Java 中使用
JavaScript 中使用
C++ 中使用
Golang 中使用
d.框架集成
LangChain (Python)
LangChain (JavaScript)
LlamaIndex
e.可视化界面部署
FastAPI 部署
WebUI 部署
f.应用案例
本地 AI Copilot 编程助手
Dify 接入本地模型
RAG 应用
Agent 应用
c.总结
a.handy-ollama 提供了一个完整的 Ollama 学习和使用框架，特别适合
1.资源受限的学习者：无需 GPU 也能运行大模型
2.本地应用开发者：构建完全本地化的 AI 应用
3.数据隐私敏感场景：完全本地化，数据不外传
4.教育和研究：低成本的大模型学习平台
b.通过 handy-ollama 教程，开发者可以
快速上手 Ollama
掌握本地模型部署
开发本地 AI 应用
集成到现有框架
c.核心理念
让每一位大模型爱好者都能在本地部署自己的大模型，让大模型赋能千行百业！
02.模型选择
a.官方模型库
a.说明
Ollama 官方维护着一个庞大的模型库，包含 100+ 优化模型
b.说明
官方地址：https://ollama.com/library
GitHub 仓库：https://github.com/ollama/ollama
b.支持的模型格式
a.Ollama 主要支持以下模型格式
a.GGUF 格式（主要格式）
GPT-Generated Unified Format
量化模型格式
CPU 友好
b.PyTorch 格式
可转换为 GGUF 使用
c.Safetensors 格式
可转换为 GGUF 使用
d.支持的模型系列
a.主流大语言模型
a.Llama 系列
Llama 3.1
Llama 3
Llama 2
特点：Meta 开源，社区活跃
b.DeepSeek 系列
DeepSeek V3.2Exp
DeepSeek R1
特点：国产开源，推理能力强
c.Qwen 系列
Qwen3
Qwen3Next
Qwen3Omni
Qwen2
Qwen2.5
特点：阿里开源，中文能力强
d.Mistral 系列
Mistral
Mixtral
Mistral Small/Large
特点：欧洲开源，性能优异
e.Phi 系列
Phi3
Phi3.5
Phi4
特点：微软开源，小而美
f.Gemma 系列
Gemma 3
Gemma 2
特点：Google 开源
g.GLM 系列
GLM4
GLM4.5
特点：智谱 AI，中文优化
h.其他模型
OLMo（Open language models）
GPTOSS（OpenAI 开源模型）
BaiChuan
Yi
InternLM
ChatGLM
b.工具模型
Ollama 还支持专门的工具模型：
工具模型分类：https://ollama.com/search?c=tools
用于特定任务的小型模型
c.多模态模型
支持视觉语言模型（部分功能可能受限）：
LLaVA 系列
Qwen-VL 系列
其他多模态模型
注意：GGUF 导入的多模态模型可能丧失多模态功能（详见 GitHub Issue #11254）
e.模型导入方式
a.从 GGUF 导入
a.说明
GGUF 是 Ollama 主要支持的格式。
b.步骤
1.从 HuggingFace 下载 GGUF 模型
2.创建 Modelfile
3.使用 `ollama create` 命令导入
c.示例 Modelfile
FROM ./model.gguf
PARAMETER temperature 0.7
PARAMETER top_p 0.9
TEMPLATE """
{{- range .Messages }}
{{- if eq .Role "user" }}
User: {{ .Content }}
{{- else if eq .Role "assistant" }}
Assistant: {{ .Content }}
{{- end }}
{{- end }}
Assistant:
"""
d.创建命令
ollama create mymodel -f Modelfile
b.从 PyTorch/Safetensors 导入
需要先转换为 GGUF 格式：
1.使用 `llama.cpp` 工具转换
2.然后按 GGUF 方式导入
c.直接从 Ollama 库拉取
最简单的方式：
ollama pull llama3.1
ollama pull qwen2.5
ollama pull deepseek-r1
d.自定义 Prompt
可以在 Modelfile 中自定义系统提示词：
```
FROM llama3.1
SYSTEM You are a helpful AI assistant.
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
```
f.模型量化
a.GGUF 量化格式
| 量化格式 | 说明 | 内存占用 |
|---------|------|---------|
| Q4_K_M | 4-bit 量化，平衡性能和质量 | 中等 |
| Q5_K_M | 5-bit 量化，更好的质量 | 较高 |
| Q8_0 | 8-bit 量化，接近原始质量 | 高 |
| F16 | 半精度，无量化 | 很高 |
b.量化选择建议
内存受限：选择 Q4_K_M
质量优先：选择 Q8_0 或 F16
平衡方案：选择 Q5_K_M
03.模型调用
a.API 使用
a.REST API 基础
Ollama 提供 OpenAI 兼容的 REST API：
POST /api/generate - 生成文本
POST /api/chat - 聊天对话
POST /api/embeddings - 生成嵌入
b.Python 示例
import ollama
# 生成文本
response = ollama.generate(model='llama3.1', prompt='Hello, world!')
print(response['response'])
# 聊天对话
response = ollama.chat(
model='llama3.1',
messages=[{'role': 'user', 'content': 'Why is the sky blue?'}]
)
print(response['message']['content'])
c.JavaScript 示例
import ollama from 'ollama'
const response = await ollama.chat({
model: 'llama3.1',
messages: [{ role: 'user', content: 'Why is the sky blue?' }]
})
console.log(response.message.content)
b.框架集成
a.LangChain 集成
a.python
from langchain_community.llms import Ollama
llm = Ollama(model="llama3.1")
response = llm.invoke("Tell me a joke")
print(response)
b.javascript
import { ChatOllama } from "@langchain/community/chat_models/ollama";
const llm = new ChatOllama({
model: "llama3.1",
});
const response = await llm.invoke("Tell me a joke");
console.log(response);
b.LlamaIndex 集成
a.python
from llama_index.llms.ollama import Ollama
llm = Ollama(model="llama3.1")
response = llm.complete("Tell me a joke")
print(response)
c.应用案例
a.本地 RAG 应用
结合 LangChain 或 LlamaIndex 构建检索增强生成应用：
完全本地化
数据隐私保护
无需互联网连接
b.本地 Agent
构建本地智能代理：
工具调用能力
本地执行
成本低廉
c.AI Copilot
本地编程助手：
代码补全
代码解释
本地运行
d.Dify 集成
将本地模型接入 Dify 平台：
可视化工作流
低代码开发
本地模型支持
d.硬件要求
a.CPU 部署建议
| 模型规模 | 最小内存 | 推荐内存 | CPU 建议 |
|---------|---------|---------|---------|
| 3B (Q4) | 4GB | 8GB | 4 核以上 |
| 7B (Q4) | 8GB | 16GB | 8 核以上 |
| 14B (Q4) | 16GB | 32GB | 16 核以上 |
| 32B (Q4) | 32GB | 64GB | 32 核以上 |
b.GPU 加速
Ollama 也支持 GPU 加速：
NVIDIA GPU：自动检测并使用
Apple Silicon：自动使用 Metal 加速
ROCm：支持 AMD GPU
e.最佳实践
a.模型选择
中文任务：优先选择 Qwen、GLM、DeepSeek
英文任务：优先选择 Llama、Mistral
代码任务：优先选择 DeepSeek Coder、Code Llama
多模态：选择 LLaVA、Qwen-VL（注意 GGUF 限制）
b.量化选择
内存充足：使用 Q8_0 或 F16
内存受限：使用 Q4_K_M
平衡方案：使用 Q5_K_M
c.性能优化
调整 `num_ctx` 参数控制上下文长度
调整 `num_gpu` 参数分配 GPU 层数
使用 `num_thread` 参数控制 CPU 线程数
d.部署建议
开发环境：使用 CPU 版本快速原型
生产环境：使用 GPU 版本提升性能
边缘设备：使用量化模型降低资源占用
f.常见问题
a.GGUF 多模态限制
问题：GGUF 导入的多模态模型可能丧失多模态功能
解决方案：使用官方多模态模型、等待官方更新支持
b.内存不足
问题：大模型加载失败
解决方案：使用更小的模型、使用更高程度的量化、减小上下文长度
c.速度慢
问题：CPU 推理速度慢
解决方案：使用 GPU 加速、使用量化模型、使用更小的模型
g.相关资源
a.官方资源
Ollama 官网：https://ollama.com/
Ollama 模型库：https://ollama.com/library
Ollama GitHub：https://github.com/ollama/ollama
handy-ollama GitHub：https://github.com/datawhalechina/handy-ollama
在线阅读：https://datawhalechina.github.io/handy-ollama/
b.学习资源
Ollama 官方文档：https://github.com/ollama/ollama#tutorial
HuggingFace GGUF 模型：https://huggingface.co/models?library=gguf
GGUF 模型运行指南：https://notes.suhaib.in/docs/tech/how-to/run-local-gguf-models-with-ollama-2025/
c.社区资源
Ollama 最佳实践指南：https://collabnix.com/best-ollama-models-in-2025-complete-performance-comparison/
Ollama 模型对比：https://skywork.ai/blog/llm/ollama-models-list-2025-100-models-compared/
4.9 [4]调用生态：newapi
01.适配指南
a.概述
a.核心特性
a.统一接口: 一个 API 端点调用所有 AI 服务
b.智能路由: 多渠道负载均衡、自动故障转移、加权分发
c.灵活计费: 按请求/使用量计费、预付费充值、费率配置
d.权限控制: 令牌权限管理、模型访问控制、API 调用审计
e.数据洞察: 实时仪表板、使用统计、成本分析
b.官方资源
a.GitHub 仓库: https://github.com/QuantumNous/new-api（15.2k+ stars）
b.官方文档: https://docs.newapi.pro/
c.项目介绍: https://docs.newapi.pro/en/docs/guide/wiki/basic-concepts/project-introduction
b.支持情况
a.盘古 (Pangu)
a.NewAPI 渠道支持: 支持
b.推荐接入方式: 华为云 ModelArts API 或本地昇腾部署
c.复杂度: 中等
b.Llama 2/3
a.NewAPI 渠道支持: 支持
b.推荐接入方式: OpenAI 兼容接口、vLLM、Ollama
c.复杂度: 简单
c.通义千问 (Qwen)
a.NewAPI 渠道支持: 支持
b.推荐接入方式: 阿里云 DashScope 或本地部署
c.复杂度: 简单
d.ChatGLM
a.NewAPI 渠道支持: 支持
b.推荐接入方式: 智谱 AI API 或本地部署
c.复杂度: 简单
c.部署指南
a.使用 Docker Compose（推荐）
a.步骤
a.克隆项目
git clone https://github.com/QuantumNous/new-api.git
b.编辑 docker-compose.yml
c.启动服务
docker-compose up -d
d.访问 Web 界面
http://localhost:3000
默认用户/密码: root / 在日志或数据库查看
b.使用 Docker 命令
a.SQLite 版本（简单）
docker run --name new-api -d --restart always -p 3000:3000 -e TZ=Asia/Shanghai -v ./data:/data calciumion/new-api:latest
b.MySQL 版本（推荐生产）
docker run --name new-api -d --restart always -p 3000:3000 -e SQL_DSN="root:123456@tcp(localhost:3306)/newapi" -e TZ=Asia/Shanghai -v ./data:/data calciumion/new-api:latest
02.接入方案
a.方案1：云端 API 接入
a.盘古
a.推荐渠道: 华为云 ModelArts
b.获取方式: https://www.huaweicloud.com/product/modelarts.html
b.Llama
a.推荐渠道: Groq/Replicate
b.获取方式: https://groq.com/
c.通义千问
a.推荐渠道: 阿里云 DashScope
b.获取方式: https://dashscope.aliyun.com/
d.ChatGLM
a.推荐渠道: 智谱 AI API
b.获取方式: https://open.bigmodel.cn/
e.优点
配置简单，即配即用；无需本地算力；稳定性好，有 SLA 保障
f.缺点
需要付费；数据外传；依赖网络
b.方案2：本地部署接入
a.盘古
a.推荐本地部署方案: 昇腾 NPU + MindSpore
b.NewAPI 渠道类型: 自定义渠道（HTTP 端点）
b.Llama
a.推荐本地部署方案: vLLM / Ollama
b.NewAPI 渠道类型: OpenAI 兼容接口
c.通义千问
a.推荐本地部署方案: vLLM / Ollama
b.NewAPI 渠道类型: OpenAI 兼容接口
d.ChatGLM
a.推荐本地部署方案: vLLM / Ollama
b.NewAPI 渠道类型: OpenAI 兼容接口
e.优点
数据隐私；无云端成本；可定制化
f.缺点
需要硬件投入；需要运维；技术门槛较高
03.详细接入
a.盘古 (Pangu) 接入
a.方式 1：华为云 ModelArts API（推荐）
a.步骤
a.注册华为云并获取 API Key
b.在 NewAPI 中添加渠道
{
"name": "华为云盘古",
"type": 1,
"key": "YOUR_HUAWEI_API_KEY",
"base_url": "https://maas-api.cn-north-4.myhuaweicloud.com",
"models": "pangu-series"
}
b.配置参数
a.类型: OpenAI 类型
b.Base URL: 华为云 ModelArts API 地址
c.API Key: 华为云 API Key
d.模型列表: pangu-series 或具体模型名
b.方式 2：本地昇腾部署 + 自定义渠道
前提：有昇腾 NPU 硬件
a.步骤
a.使用 MindSpore 部署盘古模型
b.启动 OpenAI 兼容服务
python -m vllm.entrypoints.openai.api_server --model pangu-model --port 8080
c.在 NewAPI 中添加自定义渠道
{
"name": "本地盘古",
"type": 1,
"key": "sk-local",
"base_url": "http://localhost:8080/v1",
"models": "pangu-model"
}
b.Llama 2/3 接入
a.方式 1：Groq API（最快推理）
a.步骤
a.注册 Groq 并获取 API Key
b.在 NewAPI 中添加渠道
{
"name": "Groq Llama",
"type": 1,
"key": "YOUR_GROQ_API_KEY",
"base_url": "https://api.groq.com/openai/v1",
"models": "llama-3.3-70b-versatile,llama-3.1-8b-instant"
}
b.方式 2：本地 vLLM 部署
a.步骤
a.使用 vLLM 部署 Llama
python -m vllm.entrypoints.openai.api_server --model meta-llama/Meta-Llama-3.1-8B-Instruct --host 0.0.0.0 --port 8080
b.在 NewAPI 中添加渠道
{
"name": "本地 Llama",
"type": 1,
"key": "sk-local",
"base_url": "http://localhost:8080/v1",
"models": "meta-llama/Meta-Llama-3.1-8B-Instruct"
}
c.方式 3：Ollama 部署
a.步骤
a.安装 Ollama 并拉取模型
ollama pull llama3.1
ollama serve
b.在 NewAPI 中添加渠道
{
"name": "Ollama Llama",
"type": 1,
"key": "sk-local",
"base_url": "http://localhost:11434/v1",
"models": "llama3.1"
}
c.通义千问 (Qwen) 接入
a.方式 1：阿里云 DashScope API（推荐）
a.步骤
a.注册阿里云并获取 API Key
b.在 NewAPI 中添加渠道
{
"name": "阿里云通义千问",
"type": 1,
"key": "YOUR_DASHSCOPE_API_KEY",
"base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
"models": "qwen-turbo,qwen-plus,qwen-max"
}
b.配置参数
a.类型: OpenAI 类型
b.Base URL: DashScope OpenAI 兼容地址
c.API Key: DashScope API Key
d.模型列表: qwen-turbo, qwen-plus, qwen-max
b.方式 2：本地 vLLM 部署
a.步骤
a.使用 vLLM 部署 Qwen
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8081
b.在 NewAPI 中添加渠道
{
"name": "本地 Qwen",
"type": 1,
"key": "sk-local",
"base_url": "http://localhost:8081/v1",
"models": "Qwen/Qwen2.5-7B-Instruct"
}
d.ChatGLM 接入
a.方式 1：智谱 AI API（推荐）
a.步骤
a.注册智谱 AI 并获取 API Key
b.在 NewAPI 中添加渠道
{
"name": "智谱 ChatGLM",
"type": 1,
"key": "YOUR_ZHIPU_API_KEY",
"base_url": "https://open.bigmodel.cn/api/paas/v4",
"models": "glm-4-plus,glm-4-air,glm-4-flash"
}
b.配置参数
a.类型: OpenAI 类型
b.Base URL: 智谱 OpenAI 兼容地址
c.API Key: 智谱 API Key
d.模型列表: glm-4-plus, glm-4-air, glm-4-flash
b.方式 2：本地 Ollama 部署
a.步骤
a.拉取 ChatGLM 模型
ollama pull chatglm3
b.在 NewAPI 中添加渠道
{
"name": "Ollama ChatGLM",
"type": 1,
"key": "sk-local",
"base_url": "http://localhost:11434/v1",
"models": "chatglm3"
}
04.配置使用
a.渠道配置最佳实践
a.场景：多个渠道提供相同模型
a.配置示例
本地 ChatGLM: 权重 10, 优先级 1
智谱 ChatGLM: 权重 5, 优先级 2
阿里云 Qwen: 权重 3, 优先级 3
b.说明
权重越高，分配越多请求；优先级数字越小，优先级越高
b.失败重试配置
配置路径：设置 → 运营设置 → 通用设置 → 失败重试次数
开发环境: 1-2 次
生产环境: 3-5 次
c.缓存配置
启用 Redis 缓存（推荐） -e REDIS_CONN_STRING="redis://redis:6379"
d.模型映射配置
场景：统一模型名称
gpt-3.5-turbo -> 本地 ChatGLM (chatglm3)
gpt-4 -> 阿里云 Qwen (qwen-plus)
b.API 调用示例
a.Python 示例
配置 openai.api_base 和 openai.api_key，使用 openai.ChatCompletion.create 调用
b.cURL 示例
curl 请求 http://localhost:3000/v1/chat/completions
c.JavaScript 示例
使用 OpenAI SDK，配置 baseURL 和 apiKey
c.高级功能
a.智能路由
支持加权随机、优先级路由、用户级别限流
b.格式转换
自动处理 OpenAI Compatible ⇄ Claude Messages 等不同格式的转换
c.思考模型支持
支持 OpenAI o3-mini、Claude thinking、Gemini thinking 等思考强度控制
d.监控与运维
a.数据看板
查看请求统计、成本分析、渠道健康度、用户活跃度
b.日志管理
推荐配置：ERROR_LOG_ENABLED=true, LOG_LEVEL=info
c.备份恢复
定期备份数据目录和 MySQL 数据库
4.10 [4]调用生态：langchain
01.社区生态
a.项目起源
a.基本信息
Harrison Chase
├── 教育背景
│ └── 哈佛大学计算机科学学士 (2018-2022)
│
├── 职业经历
│ ├── 2022: 创建 LangChain 开源项目
│ ├── 2023: 联合创办 LangChain Inc.
│ └── 至今: 担任 CEO
│
└── 技术背景
├── 机器学习工程师经验
├── AI 应用开发经验
└── 开源社区活跃贡献者
b.为什么创建 LangChain？
1.观察到的问题
2022 年底 ChatGPT 爆发后，开发者急需集成 LLM
没有统一的框架来构建 LLM 应用
每个开发者都要重复实现相似功能
-------------------------------------------------------------------------------------------------
2.解决方案
创建一个统一的开发框架
提供可组合的组件
简化 LLM 应用开发
-------------------------------------------------------------------------------------------------
3.愿景
让任何开发者都能轻松构建 AI 应用
推动 LLM 应用的民主化
b.LangChain 自身生态
a.官方开源项目
langchain (Python) - 90K+ stars
langchainjs (JavaScript/TypeScript) - 13K+ stars
langgraph - 状态机框架
langserve - REST API 部署
langsmith-sdk - 可观测性工具
b.商业化产品
LangSmith Platform - Tracing, Testing, Monitoring
定价: Free ($0) → Pro ($39/月) → Team ($299/月) → Enterprise (定制)
c.LangChain 衍生生态
a.社区驱动的语言实现
语言 项目 Stars 状态
Java LangChain4j 4K+ 活跃
Go langchaingo 5K+ 活跃
.NET LangChain.NET 1K+ 早期
Rust langchain-rust 1K+ 早期
b.专用框架
LlamaIndex (35K) - RAG 专用
AutoGen (28K) - 多智能体 (微软)
Semantic Kernel (19K) - 微软官方
CrewAI (10K) - 角色扮演 Agent
c.部署工具生态
Vercel AI SDK (7K)
Arize Phoenix (5K)
Langfuse (4K)
DeepEval (4K)
d.生态系统
a.官方产品矩阵
LangChain 产品矩阵:
├── 开源框架
│ ├── LangChain (Python)
│ ├── LangChain.js (JavaScript/TypeScript)
│ └── LangSmith (可观测性工具)
│
├── 商业产品
│ ├── LangSmith Platform
│ │ ├── Tracing (调用追踪)
│ │ ├── Testing (LLM 测试)
│ │ └── Monitoring (监控告警)
│ │
│ └── LangHub (计划中)
│ ├── Prompt 模板
│ ├── Chain 模板
│ └── 集成市场
│
└── 开发工具
├── LangServe (API 服务)
├── LangChain Templates (项目模板)
└── LangChain CLI (命令行工具)
b.竞争对手对比
| 框架 | GitHub Stars | 特点 | 优势 |
|------|-------------|------|------|
| LangChain | 90K (Py) / 13K (JS) | 生态最丰富 | 集成多，文档好 |
| LlamaIndex | 35K | 专注 RAG | 数据检索强 |
| Semantic Kernel | 19K | 微软主导 | 企业级，.NET 优先 |
| Haystack | 14K | deepset | NLP 专业 |
| AutoGen | 28K | 微软 | 多智能体 |
| Dust | 4K | 企业级 | Tailwind 出品 |
| Verdict | 3K | TypeScript | 全栈 TypeScript |
c.模型提供商集成
| 类别 | 提供商 | 数量 |
|------|--------|------|
| 专有模型 | OpenAI, Anthropic, Cohere, etc. | 20+ |
| 开源模型 | Hugging Face, Ollama, etc. | 30+ |
| 云厂商 | AWS, Azure, GCP, etc. | 10+ |
| 国内厂商 | 通义千问, 智谱, 百度, etc. | 10+ |
| 本地部署 | Ollama, LM Studio, etc. | 5+ |
d.向量存储集成
| 向量库 | Python | JS | Java |
|--------|--------|-----|------|
| Chroma | ✅ | ❌ | ❌ |
| Pinecone | ✅ | ✅ | ✅ |
| Weaviate | ✅ | ✅ | ✅ |
| Qdrant | ✅ | ✅ | ✅ |
| FAISS | ✅ | ❌ | ❌ |
| Milvus | ✅ | ❌ | ✅ |
e.历史版本
a.Python 版本演进
v0.0.1 (2022.10)
├── 初始版本
└── 基础 Chain 概念
v0.0.100 - v0.0.300 (2023.01 - 2023.06)
├── 快速迭代期
├── 添加大量集成
└── 文档完善
v0.0.350 (2023.10)
├── LangChain Expression Language (LCEL)
├── 新的链式语法
└── Runnable 接口
v0.1.0 (2024.02) - 重大重构
├── 包结构重组
├── langchain-core (核心接口)
├── langchain-community (社区集成)
├── 分离提供商包
└── 稳定化 API
v0.2.0+ (2024.06 - 至今)
├── LangGraph 正式发布
├── 状态机优先
├── 更好的可组合性
└── 性能优化
-------------------------------------------------------------------------------------------------
时间 事件 影响
2022.10 项目开源 LLM 应用框架诞生
2023.04 获得 $10M 融资 商业化启动
2023.10 LCEL 语法发布 简化开发体验
2024.02 v0.1.0 重构 API 稳定化
2024.06 LangGraph 发布 复杂智能体支持
b.JavaScript 版本演进
LangChain.js 版本历史
v0.0.1 (2023.01)
├── Python 版本移植
└── 基础功能
v0.0.50+ (2023.06)
├── 独立发展
├── 优化 TypeScript 支持
└── 改进 Node.js 体验
v0.1.0 (2024.02)
├── 与 Python 版本对齐
├── 统一核心接口
└── 包结构重组
v0.2.0+ (2024.06)
├── LangGraph.js 发布
├── Edge Runtime 支持
└── 性能优化
c.Java (LangChain4j) 版本演进
LangChain4j 版本历史:
v0.1.0 (2023.08)
├── 项目启动
└── 基础功能
v0.10.0 (2023.11)
├── 企业级功能
├── 观察模式 (Observability)
└── 工具调用支持
v0.20.0 (2024.02)
├── RAG 支持
├── 向量存储集成
└── 更多 LLM 提供商
v0.30.0+ (2024.06 - 至今)
├── Agent 框架
├── 多模态支持
└── 企业级特性增强
02.语言支持
a.python支持 (langchain)
a.地址
https://github.com/langchain-ai/langchain
b.包生态
# 核心包
langchain # 核心框架
langchain-core # 核心接口
langchain-community # 社区集成
# 提供商集成
langchain-openai # OpenAI 集成
langchain-anthropic # Anthropic 集成
langchain-google-vertexai # Google Vertex AI
langchain-aws # AWS Bedrock
langchain-azure # Azure OpenAI
langchain-cohere # Cohere 集成
langchain-fireworks # Fireworks AI
langchain-mistralai # Mistral AI
# 特定功能
langchain-cli # 命令行工具
langchain-experimental # 实验性功能
# 数据加载
langchain-document-loaders # 文档加载器
langchain-text-splitters # 文本分割器
# 向量存储
langchain-vectorstores # 向量存储集成
# 工具
langchainhub # 工具和链的 Hub
c.使用示例
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
# 创建链
llm = ChatOpenAI(model="gpt-4")
prompt = ChatPromptTemplate.from_template("讲一个关于{topic}的笑话")
chain = prompt | llm | StrOutputParser()
# 调用
result = chain.invoke({"topic": "程序員"})
print(result)
b.JavaScript/TypeScript (langchainjs)
a.地址
https://github.com/langchain-ai/langchainjs
b.包生态
{
"核心包": {
"@langchain/core": "核心接口定义",
"@langchain/scripts": "CLI 工具",
"@langchain/langgraph": "状态机框架 (JS)"
},
"提供商集成": {
"@langchain/openai": "OpenAI 集成",
"@langchain/anthropic": "Anthropic 集成",
"@langchain/google-vertexai": "Google Vertex AI",
"@langchain/aws": "AWS Bedrock",
"@langchain/azure": "Azure OpenAI",
"@langchain/cohere": "Cohere 集成"
},
"社区包": {
"@langchain/community": "社区集成",
"langchain": "完整包（包含所有）"
}
}
c.支持运行时
运行时 支持情况 说明
Node.js ✅ 完全支持 主要目标
Bun ✅ 完全支持 性能更好
Deno ⚠️ 部分支持 需要适配
Edge Runtime ✅ 支持 Vercel Edge Functions
Browser ⚠️ 有限支持 安全限制
d.使用示例
import { ChatOpenAI } from "@langchain/openai";
import { ChatPromptTemplate } from "@langchain/core/prompts";
import { StringOutputParser } from "@langchain/core/output_parsers";
// 创建链
const llm = new ChatOpenAI({ model: "gpt-4" });
const prompt = ChatPromptTemplate.fromTemplate(
"讲一个关于{topic}的笑话"
);
const chain = prompt.pipe(llm).pipe(new StringOutputParser());
// 调用
const result = await chain.invoke({ topic: "程序员" });
console.log(result);
c.Java (LangChain4j)
a.地址
https://github.com/langchain4j/langchain4j
这不是官方 LangChain 项目，而是社区驱动的 Java 实现！
b.为什么叫 LangChain4j
命名惯例:
├── "4j" 后缀是 Java 社区传统
│ ├── TestNG (测试框架)
│ ├── Log4j (日志框架)
│ ├── OpenAPI4j (OpenAPI 客户端)
│ └── LangChain4j (LangChain for Java)
│
└── 说明这是 LangChain 概念的 Java 实现
└── 不是移植，而是重新设计以符合 Java 习惯
c.核心模块
<!-- LangChain4j 核心依赖 -->
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j</artifactId>
<version>0.29.1</version>
</dependency>
<!-- 提供商集成 -->
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-open-ai</artifactId>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-anthropic</artifactId>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-azure-open-ai</artifactId>
</dependency>
<!-- 特定功能 -->
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j</artifactId>
<classifier>all</classifier>
</dependency>
d.架构设计
LangChain4j 架构:
├── 核心层 (langchain4j-core)
│ ├── Model (模型接口)
│ ├── Service (服务接口)
│ ├── Chain (链)
│ └── Memory (记忆)
│
├── 提供商层
│ ├── OpenAI
│ ├── Anthropic
│ ├── Azure OpenAI
│ ├── AWS Bedrock
│ ├── Google Vertex AI
│ └── Hugging Face
│
└── 扩展层
├── 文档加载器
├── 向量存储
├── 工具
└── RAG 组件
e.使用示例
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.service.AiServices;
// 定义服务接口
interface Assistant {
String chat(String message);
}
// 创建服务
ChatLanguageModel model = OpenAiChatModel.builder()
.apiKey("your-api-key")
.modelName("gpt-4")
.build();
Assistant assistant = AiServices.builder(Assistant.class)
.chatLanguageModel(model)
.build();
// 调用
String response = assistant.chat("讲一个程序员的笑话");
System.out.println(response);
d.其他语言支持，社区驱动的实现
语言 项目 Stars 状态
Go https://github.com/tmc/langchaingo 5K+ 活跃
Rust https://github.com/Abraxas-365/langchain-rust 1K+ 早期
.NET/C# https://github.com/tryAGI/LangChain 1K+ 活跃
Ruby https://github.com/andreibondarev/langchainrb 500+ 早期
03.全景生态
a.LangChain 自身生态
a.核心开源项目
LangChain 官方开源生态
│
├── 核心框架
│ ├── langchain (Python)
│ │ ├── GitHub: https://github.com/langchain-ai/langchain
│ │ ├── Stars: 90K+
│ │ ├── 功能: LLM 应用开发框架
│ │ └── 定位: 核心产品，功能最全
│ │
│ └── langchainjs (JavaScript/TypeScript)
│ ├── GitHub: https://github.com/langchain-ai/langchainjs
│ ├── Stars: 13K+
│ ├── 功能: JS/TS 生态的 LLM 框架
│ └── 定位: 全栈应用开发
│
├── 核心接口库
│ ├── langchain-core
│ │ ├── 功能: 定义核心接口和基类
│ │ ├── 依赖: 无外部依赖
│ │ └── 用途: 所有 LangChain 包的基础
│ │
│ └── langchain-text-splitters
│ ├── 功能: 文本分割算法
│ └── 用途: RAG 中的文档切分
│
├── 社区集成
│ ├── langchain-community
│ │ ├── 功能: 社区贡献的集成
│ │ ├── 包含: 100+ 第三方集成
│ │ └── 维护: 社区驱动
│ │
│ └── langchain-cli
│ ├── 功能: 命令行工具
│ └── 用途: 快速创建项目
│
├── 提供商特定包
│ ├── langchain-openai
│ ├── langchain-anthropic
│ ├── langchain-google-vertexai
│ ├── langchain-aws
│ ├── langchain-azure
│ ├── langchain-cohere
│ ├── langchain-fireworks
│ ├── langchain-mistralai
│ ├── langchain-nvidia-ai
│ ├── langchain-nvidia-ai-endpoints
│ ├── langchain-upstage
│ ├── langchain-groq
│ └── langchain-huggingface
│
└── 框架和工具
├── langgraph
│ ├── 功能: 状态机框架
│ ├── 定位: 复杂智能体和工作流
│ └── 特点: 可视化、可调试
│
├── langserve
│ ├── 功能: 将 Chain 部署为 REST API
│ ├── 特点: 自动生成 OpenAPI 文档
│ └── 用途: 生产部署
│
├── langchainhub
│ ├── 功能: 提示词和链的 Hub
│ ├── 包含: 社区贡献的 Prompt
│ └── 用途: 发现和分享
│
├── langsmith-sdk
│ ├── 功能: LangSmith SDK
│ ├── 用途: 可观测性和调试
│ └── 特点: 追踪、测试、监控
│
└── langchain-template
├── 功能: 项目模板集合
└── 用途: 快速启动
b.商业化产品
LangChain 商业产品矩阵
│
├── LangSmith Platform
│ │
│ ├── Tracing (追踪)
│ │ ├── 功能: 可视化 LLM 调用链
│ │ ├── 特点:
│ │ │ ├── 详细的调用图
│ │ │ ├── Token 使用统计
│ │ │ ├── 成本分析
│ │ │ ├── 时间线视图
│ │ │ └── 参数对比
│ │ ├── 定价: 免费 + 付费层级
│ │ └── 竞争对手: Arize, Weights & Biases
│ │
│ ├── Testing (测试)
│ │ ├── 功能: LLM 应用测试框架
│ │ ├── 特点:
│ │ │ ├── 数据集管理
│ │ │ ├── 评估指标
│ │ │ ├── A/B 测试
│ │ │ └── 回归测试
│ │ └── 用途: 确保 LLM 输出质量
│ │
│ ├── Monitoring (监控)
│ │ ├── 功能: 生产环境监控
│ │ ├── 特点:
│ │ │ ├── 实时性能指标
│ │ │ ├── 异常检测
│ │ │ ├── 告警规则
│ │ │ └── 使用分析
│ │ └── 定价: 按使用量
│ │
│ └── Playground (实验场)
│ ├── 功能: 交互式实验环境
│ ├── 特点: 快速原型验证
│ └── 定价: 免费
│
└── LangSmith 产品形态
├── SaaS: https://smith.langchain.com
├── 私有化部署: 企业版
└── API: SDK 集成
c.开发工具链
LangChain 开发工具
│
├── 本地开发
│ ├── langchain-cli
│ │ ├── 安装: pip install langchain-cli
│ │ ├── 功能: 创建新项目
│ │ └── 示例: langchain app new my-app
│ │
│ ├── langserve
│ │ ├── 安装: pip install langserve
│ │ ├── 功能: 部署 Chain 为 API
│ │ └── 特点: 自动生成文档
│ │
│ └── LangSmith SDK
│ ├── 功能: 本地调试
│ ├── 特点: 集成到 IDE
│ └── 支持: VS Code, Jupyter
│
├── 可视化工具
│ ├── LangGraph Studio
│ │ ├── 功能: 可视化编辑状态机
│ │ ├── 特点: 拖拽式开发
│ │ └── 状态: Beta
│ │
│ └── LangSmith UI
│ ├── 功能: Web 界面
│ ├── 特点: 调用链可视化
│ └── 访问: smith.langchain.com
│
└── 模板和示例
├── LangChain Templates
│ ├── GitHub: langchain-ai/langchain-templates
│ ├── 功能: 项目模板库
│ └── 包含: 50+ 模板
│
├── Cookbook
│ ├── 功能: 示例代码集合
│ ├── 内容: 100+ 示例
│ └── 访问: python.langchain.com/docs/use_cases
│
└── LangChain Hub
├── 功能: 社区分享平台
├── 包含: Prompts, Chains, Agents
└── 访问: hub.langchain.com
b.LangChain 衍生生态
a.非官方的 LangChain 实现
社区 LangChain 实现:
│
├── Java 实现
│ ├── LangChain4j
│ │ ├── GitHub: https://github.com/langchain4j/langchain4j
│ │ ├── Stars: 4K+
│ │ ├── 发起人: Dmitry Aleksandrov
│ │ ├── 协议: Apache 2.0
│ │ ├── 特点:
│ │ │ ├── 企业级特性
│ │ │ ├── 观察模式
│ │ │ ├── 工具调用
│ │ │ └── RAG 支持
│ │ ├── 集成:
│ │ │ ├── Spring Boot
│ │ │ ├── Quarkus
│ │ │ └── Micronaut
│ │ └── 文档: https://docs.langchain4j.dev
│ │
│ └── Spring AI
│ ├── GitHub: https://github.com/spring-projects/spring-ai
│ ├── Stars: 2K+
│ ├── 背书: Spring 官方
│ ├── 特点:
│ │ ├── Spring 生态集成
│ │ ├── 自动配置
│ │ └── 企业级支持
│ └── 文档: https://docs.spring.io/spring-ai
│
├── Go 实现
│ ├── langchaingo
│ │ ├── GitHub: https://github.com/tmc/langchaingo
│ │ ├── Stars: 5K+
│ │ ├── 特点: Go 语言习惯
│ │ └── 文档: https://tmc.github.io/langchaingo
│ │
│ └── golang-llm-connector
│ ├── GitHub: 各种实现
│ └── 特点: 轻量级
│
├── .NET/C# 实现
│ ├── LangChain.NET
│ │ ├── GitHub: https://github.com/tryAGI/LangChain
│ │ ├── Stars: 1K+
│ │ ├── 特点: .NET Standard
│ │ └── 依赖: Microsoft.SemanticKernel
│ │
│ └── Semantic Kernel (微软)
│ ├── GitHub: https://github.com/microsoft/semantic-kernel
│ ├── Stars: 19K+
│ ├── 背书: 微软官方
│ ├── 特点:
│ │ ├── 企业级
│ │ ├── 多语言支持
│ │ └── Azure 深度集成
│ └── 文档: https://learn.microsoft.com/semantic-kernel
│
├── Rust 实现
│ ├── langchain-rust
│ │ ├── GitHub: https://github.com/Abraxas-365/langchain-rust
│ │ ├── Stars: 1K+
│ │ ├── 特点: 性能优先
│ │ └── 状态: 早期开发
│ │
│ └── rust-llm-utils
│ └── 特点: 工具集合
│
├── Ruby 实现
│ ├── langchainrb
│ │ ├── GitHub: https://github.com/andreibondarev/langchainrb
│ │ ├── Stars: 500+
│ │ ├── 特点: Ruby 习惯
│ │ └── Gem: langchainrb
│ │
│ └── ruby-ai-agent
│ └── 特点: Agent 框架
│
└── PHP 实现
├── langchain-php
│ ├── GitHub: https://github.com/langchain-ai/langchain-php
│ ├── 注意: 官方已放弃维护
│ └── 说明: 官方不再支持 PHP
│
└── php-llm-wrapper
└── 特点: 社区维护
b.专用框架和扩展
专用框架:
│
├── Agent 框架
│ ├── AutoGen (微软)
│ │ ├── GitHub: https://github.com/microsoft/autogen
│ │ ├── Stars: 28K+
│ │ ├── 特点: 多智能体对话
│ │ ├── 语言: Python
│ │ └── 背书: 微软研究院
│ │
│ ├── CrewAI
│ │ ├── GitHub: https://github.com/joaomdmoura/crewAI
│ │ ├── Stars: 10K+
│ │ ├── 特点: 角色扮演 Agent
│ │ ├── 概念: 类似 LangChain Agent
│ │ └── 优势: 更简单易用
│ │
│ ├── AgentOps
│ │ ├── GitHub: https://github.com/AgentOps-AI/agentops
│ │ ├── Stars: 3K+
│ │ ├── 功能: Agent 监控
│ │ └── 集成: LangChain, AutoGen
│ │
│ └── Phidata
│ ├── GitHub: https://github.com/phidatahq/phidata
│ ├── Stars: 8K+
│ ├── 特点: Agent + 工具
│ └── 概念: 类似 LangChain Tools
│
├── RAG 框架
│ ├── LlamaIndex
│ │ ├── GitHub: https://github.com/run-llama/llama_index
│ │ ├── Stars: 35K+
│ │ ├── 定位: 专注 RAG
│ │ ├── 特点:
│ │ │ ├── 数据索引强
│ │ │ ├── 查询优化
│ │ │ └── 多模态支持
│ │ ├── 与 LangChain: 可互操作
│ │ └── 优势: 数据连接更强
│ │
│ ├── Haystack
│ │ ├── GitHub: https://github.com/deepset-ai/haystack
│ │ ├── Stars: 14K+
│ │ ├── 公司: deepset
│ │ ├── 特点: NLP 专业
│ │ ├── 语言: Python
│ │ └── 优势: 企业级 NLP
│ │
│ ├── Verdict
│ │ ├── GitHub: https://github.com/verdict-ai/verdict
│ │ ├── Stars: 3K+
│ │ ├── 特点: TypeScript 原生
│ │ ├── 定位: 全栈 RAG
│ │ └── 优势: 类型安全
│ │
│ └── EmbedChain
│ ├── GitHub: https://github.com/embedchain/embedchain
│ ├── Stars: 7K+
│ ├── 特点: 简化 RAG
│ └── 优势: 更简单
│
├── LLM 服务框架
│ ├── LiteLLM
│ │ ├── GitHub: https://github.com/berriai/litellm
│ │ ├── Stars: 8K+
│ │ ├── 功能: 统一多模型 API
│ │ ├── 特点:
│ │ │ ├── 100+ 模型支持
│ │ │ ├── 负载均衡
│ │ │ ├── 故障转移
│ │ │ └── 成本跟踪
│ │ ├── 与 LangChain: 完全兼容
│ │ └── 竞争对象: NewAPI
│ │
│ ├── OpenRouter
│ │ ├── 网站: https://openrouter.ai
│ │ ├── 功能: 模型路由服务
│ │ ├── 特点: 统一 API
│ │ └── 模型: 100+ LLM
│ │
│ └── Portkey
│ ├── GitHub: https://github.com/Portkey-AI/portkey
│ ├── Stars: 4K+
│ ├── 功能: AI Gateway
│ ├── 特点:
│ │ ├── 缓存
│ │ ├── 重试
│ │ └── 观测
│ └── 集成: LangChain
│
└── 测试和评估
├── Ragas
│ ├── GitHub: https://github.com/explodinggradients/ragas
│ ├── Stars: 5K+
│ ├── 功能: RAG 评估框架
│ ├── 特点:
│ │ ├── Faithfulness
│ │ ├── Answer Relevance
│ │ └── Context Precision
│ └── 用途: 评估 RAG 质量
│
├── DeepEval
│ ├── GitHub: https://github.com/confident-ai/deepeval
│ ├── Stars: 4K+
│ ├── 功能: LLM 测试框架
│ ├── 特点: 类似 Pytest
│ └── 集成: LangChain, LlamaIndex
│
├── Promptfoo
│ ├── GitHub: https://github.com/promptfoo/promptfoo
│ ├── Stars: 5K+
│ ├── 功能: Prompt 测试工具
│ ├── 特点: CLI 工具
│ └── 用途: 比较 Prompt 效果
│
└── Arize Phoenix
├── GitHub: https://github.com/Arize-ai/phoenix
├── Stars: 5K+
│ ├── 功能: LLM 可观测性
│ ├── 特点: 开源替代 LangSmith
│ └── 集成: LangChain, LlamaIndex
c.部署和运维生态
部署工具生态:
│
├── 容器化部署
│ ├── Docker 镜像
│ │ ├── langchain/langchain
│ │ ├── langchain/serve
│ │ └── langchain-*
│ │
│ ├── Kubernetes Operator
│ │ └── 社区贡献
│ │
│ └── Docker Compose
│ └── 官方模板
│
├── Serverless 部署
│ ├── Vercel AI SDK
│ │ ├── GitHub: https://github.com/vercel/ai
│ │ ├── Stars: 7K+
│ │ ├── 集成: LangChain, LangChain.js
│ │ ├── 特点: Vercel 优化
│ │ └── 文档: https://sdk.vercel.ai
│ │
│ ├── AWS Lambda
│ │ ├── 示例: 官方文档
│ │ └── 特点: 冷启动优化
│ │
│ ├── Google Cloud Functions
│ │ ├── 示例: 官方文档
│ │ └── 特点: Event 驱动
│ │
│ └── Cloudflare Workers
│ ├── 集成: LangChain.js
│ └── 特点: Edge Runtime
│
├── API 管理
│ ├── LangServe
│ │ ├── 功能: Chain → REST API
│ │ ├── 特点: FastAPI 集成
│ │ ├── 文档: 自动生成
│ │ └── 部署: Docker
│ │
│ ├── Kong
│ │ ├── 功能: API Gateway
│ │ ├── 集成: LangServe
│ │ └── 特点: 企业级
│ │
│ └── Traefik
│ ├── 功能: 反向代理
│ ├── 集成: LangServe
│ └── 特点: 自动发现
│
└── 可观测性
├── LangSmith (官方)
│ └── 功能最全
│
├── Arize Phoenix
│ ├── 开源替代
│ └── 功能: 80% LangSmith
│
├── Weights & Biases
│ ├── 功能: 实验跟踪
│ ├── 集成: LangChain
│ └── 特点: MLOps 平台
│
├── Langfuse
│ ├── GitHub: https://github.com/langfuse/langfuse
│ ├── Stars: 4K+
│ ├── 功能: 开源 LLMOps
│ ├── 特点:
│ │ ├── Tracing
│ │ ├── 调试
│ │ └── 用户管理
│ └── 开源替代 LangSmith
│
└── Helicone
├── 网站: https://www.helicone.dev
├── 功能: OpenAI 代理
├── 特点: 缓存 + 分析
└── 集成: LangChain
d.开发工具和插件
开发工具生态:
│
├── VS Code
│ ├── LangChain VS Code Extension (官方)
│ │ ├── 功能: LangSmith 集成
│ │ ├── 特点:
│ │ │ ├── 内联追踪
│ │ │ ├── Prompt 模板
│ │ │ └── 调试支持
│ │ └── 市场: VS Code Extension
│ │
│ └── Continue
│ ├── 功能: AI 编程助手
│ ├── 集成: LangChain
│ └── 特点: 本地 LLM
│
├── JetBrains
│ ├── PyCharm Plugin
│ │ ├── 功能: LangChain 支持
│ │ ├── 特点: 代码补全
│ │ └── 状态: 社区插件
│ │
│ └── IntelliJ IDEA Plugin
│ └── LangChain4j 支持
│
├── Jupyter Notebook
│ ├── LangChain for Jupyter
│ │ ├── 功能: 可视化 Chain
│ │ ├── 特点: 交互式开发
│ │ └── 魔法命令: %load_ext langchain
│ │
│ └── JupyterLab Extension
│ └── 功能: 增强 UI
│
└── 其他工具
├── Cursor AI
│ ├── 功能: AI 编辑器
│ ├── 集成: LangChain
│ └── 特点: 原生 AI 支持
│
├── Replit Agent
│ ├── 功能: AI 编程
│ ├── 集成: LangChain
│ └── 特点: 在线 IDE
│
└── GitHub Copilot
├── 功能: 代码补全
├── 支持: LangChain 代码
└── 特点: 上下文理解
c.LangChain 生态地图
a.完整生态图谱
┌─────────────────────────────────────────────────────────────┐
│ LangChain 生态 │
└─────────────────────────────────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
官方生态 社区生态 商业生态
│ │ │
┌───┴────┐ ┌────┴─────┐ ┌───┴────┐
│ Python │ │ Java │ │LangSmith│
│ JS/TS │ │ Go │ │ 平台 │
│ Core │ │ .NET │ │ SaaS │
└────────┘ │ Rust │ └─────────┘
│ Ruby │
└─────────┘
│ │ │
┌───┴────────┬───────┴────────┬────────┴──────┐
│ │ │ │
框架 部署 工具 服务
│ │ │ │
┌───┴────┐ ┌───┴────┐ ┌─────┴────┐ ┌────┴────┐
│LangGraph│ │LangServe│ │LangSmith │ │LangSmith│
│ Agent │ │ API │ │ SDK │ │ API │
└─────────┘ └─────────┘ └──────────┘ └─────────┘
│ │ │ │
┌───┴────┐ ┌───┴────┐ ┌─────┴────┐ ┌────┴────┐
│AutoGen │ │Docker │ │ Arize │ │ 企业版 │
│CrewAI │ │K8s │ │Weights │ │ 私有化 │
│LlamaIndex│ │Serverless│ │ & Biases │ │ 支持 │
└─────────┘ └─────────┘ └──────────┘ └─────────┘
b.依赖关系图
Level 1: 核心接口
└── langchain-core
├── 定义: Runnable 接口
├── 定义: Memory, Tool 等
└── 无外部依赖
Level 2: 核心框架
├── langchain
│ ├── 依赖: langchain-core
│ ├── 依赖: langchain-community
│ ├── 依赖: langchain-* (提供商)
│ └── 功能: 完整框架
│
└── langchainjs
├── 依赖: @langchain/core
├── 依赖: @langchain/community
└── 功能: JS 版本
Level 3: 高级框架
├── langgraph
│ ├── 依赖: langchain-core
│ └── 功能: 状态机
│
├── langserve
│ ├── 依赖: langchain
│ └── 功能: API 服务
│
└── langchain-cli
├── 依赖: langchain
└── 功能: CLI 工具
Level 4: 商业工具
└── langsmith-sdk
├── 依赖: langchain-core
└── 功能: 可观测性
d.生态成熟度分析
a.Python 生态成熟度
| 类别 | 成熟度 | 说明 |
|------|--------|------|
| **核心框架** | ⭐⭐⭐⭐⭐ | 稳定，API 基本固定 |
| **文档** | ⭐⭐⭐⭐⭐ | 非常完善 |
| **集成** | ⭐⭐⭐⭐⭐ | 100+ 提供商 |
| **社区** | ⭐⭐⭐⭐⭐ | 活跃，贡献者多 |
| **工具** | ⭐⭐⭐⭐⭐ | 完整工具链 |
| **企业支持** | ⭐⭐⭐⭐ | 有商业支持 |
b.JavaScript 生态成熟度
| 类别 | 成熟度 | 说明 |
|------|--------|------|
| **核心框架** | ⭐⭐⭐⭐ | 稳定，快速迭代 |
| **文档** | ⭐⭐⭐⭐ | 完善，但略少 |
| **集成** | ⭐⭐⭐⭐ | 80+ 提供商 |
| **社区** | ⭐⭐⭐⭐ | 活跃 |
| **工具** | ⭐⭐⭐⭐ | 基本完整 |
| **企业支持** | ⭐⭐⭐ | 增长中 |
c.Java (LangChain4j) 生态成熟度
| 类别 | 成熟度 | 说明 |
|------|--------|------|
| **核心框架** | ⭐⭐⭐⭐ | 企业级设计 |
| **文档** | ⭐⭐⭐ | 完善 |
| **集成** | ⭐⭐⭐ | 30+ 提供商 |
| **社区** | ⭐⭐⭐ | 活跃 |
| **工具** | ⭐⭐⭐ | 企业级工具 |
| **企业支持** | ⭐⭐⭐⭐⭐ | 非常强 |
d.衍生框架对比
| 框架 | Stars | 特点 | 定位 |
|------|-------|------|------|
| **LangChain** | 90K | 生态最全 | 通用框架 |
| **LlamaIndex** | 35K | 数据连接 | RAG 专用 |
| **Semantic Kernel** | 19K | 微软官方 | 企业级 |
| **AutoGen** | 28K | 多智能体 | Agent 框架 |
| **CrewAI** | 10K | 角色扮演 | Agent 框架 |
| **Haystack** | 14K | NLP 专业 | 企业搜索 |
| **Verdict** | 3K | TypeScript | 全栈 |
e.生态发展趋势
a.2024-2025 趋势
发展趋势:
├── 从 Chain 到 Graph
│ ├── LangGraph 成为核心
│ ├── 复杂工作流需求
│ └── 状态机优先
│
├── 从实验到生产
│ ├── LangSmith 普及
│ ├── 可观测性重要
│ └── 测试和评估
│
├── 从单一到多模态
│ ├── 图像理解
│ ├── 音频处理
│ └── 视频理解
│
├── 从云端到边缘
│ ├── Edge Runtime
│ ├── 本地模型
│ └── WebGPU
│
└── 从通用到专用
├── RAG 专用 (LlamaIndex)
├── Agent 专用 (AutoGen, CrewAI)
└── 企业级 (Semantic Kernel)
b.未来方向
| 方向 | 说明 | 时间线 |
|------|------|--------|
| **LangGraph** | 成为核心框架 | 2024 |
| **多模态** | 原生支持 | 2024-2025 |
| **边缘计算** | WebAssembly, WebGPU | 2025 |
| **企业功能** | 更多企业特性 | 持续 |
| **性能优化** | 更快响应 | 持续 |
| **标准化** | 推动行业标准 | 长期 |
f.选择建议
a.技术选型
| 场景 | 推荐 | 理由 |
|------|------|------|
| **快速原型** | Python LangChain | 生态成熟 |
| **全栈应用** | JS/TS LangChain | 前后端统一 |
| **企业应用** | LangChain4j | 企业级特性 |
| **RAG 应用** | LlamaIndex | 数据连接强 |
| **Agent 应用** | LangGraph + AutoGen | 多智能体 |
| **.NET 应用** | Semantic Kernel | 微软支持 |
b.组合使用
实用组合:
├── Python + LangChain + LlamaIndex
│ └── RAG 应用最佳实践
│
├── TypeScript + LangChain.js + Vercel AI
│ └── 全栈 AI 应用
│
├── Java + LangChain4j + Spring Boot
│ └── 企业级 AI 应用
│
└── Python + LangGraph + AutoGen
└── 复杂智能体系统
g.总结
a.核心要点
1.LangChain 自身生态
官方: Python + JavaScript
商业: LangSmith Platform
工具: LangServe, LangGraph, CLI
2.LangChain 衍生生态
社区实现: Java (LangChain4j), Go, .NET
专用框架: LlamaIndex, AutoGen, CrewAI
工具链: Arize, Weights & Biases, Langfuse
3.生态成熟度
Python: 最成熟 (90K stars)
JavaScript: 快速发展 (13K stars)
Java: 企业级强 (4K stars)
b.生态价值
| 价值 | 说明 |
|------|------|
| **降低门槛** | 让更多开发者能构建 AI 应用 |
| **最佳实践** | 沉淀社区经验 |
| **互操作性** | 组件可组合 |
| **标准化** | 推动行业标准 |
| **创新加速** | 快速实验新想法 |
04.模型调用
a.问题背景
a.核心问题
问题：LangChain 是否可以绕过 NewAPI，直接调用其他渠道的模型？
答案：是的，完全可以。LangChain 支持多种方式直接调用各类模型渠道，不依赖 NewAPI。
b.使用场景分析
┌─────────────────────────────────────────────────────────────┐
│ LangChain 模型调用方式对比 │
└─────────────────────────────────────────────────────────────┘
方式 1: 通过 NewAPI 统一调用
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ LangChain│───▶│ NewAPI │───▶│ 多渠道 │───▶│ 模型 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│
├── 路由策略
├── 负载均衡
├── 故障转移
└── 统一计费
方式 2: 直接调用各渠道模型
┌─────────┐ ┌─────────────────────────────────────┐
│ │───▶│ OpenAI API │
│ │ └─────────────────────────────────────┘
│ │
│ │ ┌─────────────────────────────────────┐
│ LangChain│───▶│ 硅基流动 API │
│ │ └─────────────────────────────────────┘
│ │
│ │ ┌─────────────────────────────────────┐
│ │───▶│ Ollama 本地 │
│ │ └─────────────────────────────────────┘
│ │
│ │ ┌─────────────────────────────────────┐
│ └───▶│ 其他兼容 OpenAI 的 API │
│ └─────────────────────────────────────┘
b.LangChain 支持的调用方式
a.LangChain 支持的模型集成方式
| 方式 | 说明 | 复杂度 | 灵活性 |
|------|------|--------|--------|
| **OpenAI Compatible** | 使用 OpenAI SDK 兼容接口 | 低 | 高 |
| **LangChain Integrations** | 使用 LangChain 内置集成 | 中 | 中 |
| **Custom LLM** | 自定义 LLM 类 | 高 | 最高 |
| **多渠道路由** | 实现路由逻辑 | 中 | 高 |
b.OpenAI 兼容接口 (推荐)
a.原理
大多数现代 AI 模型 API 都兼容 OpenAI 接口格式，LangChain 的 `ChatOpenAI` 类可以通过配置 `base_url` 直接调用。
b.支持的渠道
| 渠道 | base_url | 说明 |
|------|----------|------|
| **硅基流动** | `https://api.siliconflow.cn/v1` | ✅ 完全兼容 |
| **DeepSeek** | `https://api.deepseek.com/v1` | ✅ 完全兼容 |
| **通义千问** | `https://dashscope.aliyuncs.com/compatible-mode/v1` | ✅ 完全兼容 |
| **智谱 AI** | `https://open.bigmodel.cn/api/paas/v4` | ✅ 完全兼容 |
| **Ollama** | `http://localhost:11434/v1` | ✅ 完全兼容 |
| **OneAPI** | `http://your-oneapi/v1` | ✅ 完全兼容 |
| **NewAPI** | `http://your-newapi/v1` | ✅ 完全兼容 |
| **其他** | 各自的兼容端点 | 需验证 |
c.实现示例
from langchain_openai import ChatOpenAI
# 硅基流动
llm_siliconflow = ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-your-siliconflow-key",
model="Qwen/Qwen2.5-32B-Instruct"
)
# 通义千问
llm_dashscope = ChatOpenAI(
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="sk-your-dashscope-key",
model="qwen2.5-32b"
)
# Ollama 本地
llm_ollama = ChatOpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # Ollama 不需要真实 key
model="qwen2.5:14b"
)
# 智谱 AI
llm_zhipu = ChatOpenAI(
base_url="https://open.bigmodel.cn/api/paas/v4",
api_key="your-zhipu-key",
model="glm-4"
)
# 调用示例
response = await llm_siliconflow.ainvoke([
("system", "你是一个评标专家"),
("user", "请分析以下标书...")
])
print(response.content)
c.LangChain 内置集成
a.LangChain 官方支持的集成
| 提供商 | 包名 | 文档链接 |
|--------|------|---------|
| **OpenAI** | `langchain-openai` | https://python.langchain.com/docs/integrations/platforms/openai |
| **Anthropic** | `langchain-anthropic` | https://python.langchain.com/docs/integrations/platforms/anthropic |
| **Azure OpenAI** | `langchain-openai` | https://python.langchain.com/docs/integrations/platforms/azure |
| **Google** | `langchain-google-vertexai` | https://python.langchain.com/docs/integrations/platforms/google |
| **Cohere** | `langchain-cohere` | https://python.langchain.com/docs/integrations/platforms/cohere |
| **Hugging Face** | `langchain-huggingface` | https://python.langchain.com/docs/integrations/platforms/huggingface |
| **Ollama** | `langchain-ollama` | https://python.langchain.com/docs/integrations/platforms/ollama |
b.示例：Ollama 官方集成
from langchain_ollama import ChatOllama
# 使用官方集成
llm = ChatOllama(
model="qwen2.5:14b",
temperature=0
)
response = await llm.ainvoke("你好")
print(response)
d.自定义 LLM 类
a.当需要特殊处理时，可以自定义 LLM 类
from langchain_core.language_models.llms import LLM
from langchain_core.language_models.chat_models import BaseChatModel
from langchain_core.messages import BaseMessage, AIMessage, HumanMessage
from typing import Optional, List, Any
import httpx
class CustomChatModel(BaseChatModel):
"""自定义聊天模型"""
base_url: str = ""
api_key: str = ""
model: str = ""
temperature: float = 0.7
class Config:
arbitrary_types_allowed = True
def _generate(
self,
messages: List[BaseMessage],
stop: Optional[List[str]] = None,
run_manager: Optional[Any] = None,
**kwargs: Any,
) -> ChatResult:
"""生成响应"""
# 转换消息格式
api_messages = [
{"role": "user" if isinstance(m, HumanMessage) else "assistant",
"content": m.content}
for m in messages
]
# 调用自定义 API
response = httpx.post(
f"{self.base_url}/chat/completions",
headers={"Authorization": f"Bearer {self.api_key}"},
json={
"model": self.model,
"messages": api_messages,
"temperature": self.temperature
}
).json()
# 返回结果
return ChatResult(
generations=[ChatGeneration(message=AIMessage(content=response["choices"][0]["message"]["content"]))]
)
@property
def _llm_type(self) -> str:
return "custom"
# 使用
llm = CustomChatModel(
base_url="https://your-custom-api.com/v1",
api_key="your-key",
model="your-model"
)
c.多渠道调用策略
a.简单路由策略
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
# 定义多个模型
simple_llm = ChatOpenAI( # 简单任务用 7B
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-7B-Instruct",
temperature=0
)
complex_llm = ChatOpenAI( # 复杂任务用 32B
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-32B-Instruct",
temperature=0
)
# 路由函数
def select_llm(task_type: str):
"""根据任务类型选择模型"""
if task_type in ["simple_extraction", "formatting"]:
return simple_llm
elif task_type in ["complex_analysis", "reasoning"]:
return complex_llm
else:
return simple_llm # 默认
# 使用
llm = select_llm("complex_analysis")
chain = ChatPromptTemplate.from_template("{input}") | llm | StrOutputParser()
result = await chain.ainvoke({"input": "分析这份标书..."})
b.多渠道负载均衡
import random
from typing import List
from langchain_openai import ChatOpenAI
class LoadBalancedLLM:
"""负载均衡的 LLM"""
def __init__(self, models: List[ChatOpenAI]):
self.models = models
self.current_index = 0
def _select_model(self) -> ChatOpenAI:
"""轮询选择模型"""
model = self.models[self.current_index]
self.current_index = (self.current_index + 1) % len(self.models)
return model
async def ainvoke(self, messages, **kwargs):
"""调用"""
model = self._select_model()
return await model.ainvoke(messages, **kwargs)
def invoke(self, messages, **kwargs):
"""同步调用"""
model = self._select_model()
return model.invoke(messages, **kwargs)
# 配置多个渠道
models = [
ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key-1",
model="Qwen/Qwen2.5-32B-Instruct"
),
ChatOpenAI(
base_url="https://api.deepseek.com/v1",
api_key="sk-key-2",
model="deepseek-chat"
),
ChatOpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama",
model="qwen2.5:14b"
)
]
# 使用负载均衡
llm = LoadBalancedLLM(models)
response = await llm.ainvoke([("user", "你好")])
c.故障转移策略
import asyncio
from typing import List, Optional
from langchain_openai import ChatOpenAI
from langchain_core.messages import BaseMessage
class FailoverLLM:
"""支持故障转移的 LLM"""
def __init__(self, models: List[ChatOpenAI]):
self.models = models
async def ainvoke_with_failover(
self,
messages: List[BaseMessage],
max_retries: int = 3,
**kwargs
):
"""带故障转移的调用"""
last_error = None
for model in self.models:
for attempt in range(max_retries):
try:
response = await model.ainvoke(messages, **kwargs)
return response
except Exception as e:
last_error = e
print(f"Model {model.model} failed (attempt {attempt + 1}): {e}")
await asyncio.sleep(1) # 等待后重试
# 所有模型都失败
raise Exception(f"All models failed. Last error: {last_error}")
# 配置：主渠道 + 备份渠道
models = [
ChatOpenAI( # 主渠道：硅基流动
base_url="https://api.siliconflow.cn/v1",
api_key="sk-siliconflow-key",
model="Qwen/Qwen2.5-32B-Instruct"
),
ChatOpenAI( # 备份渠道 1：通义千问
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="sk-dashscope-key",
model="qwen2.5-32b"
),
ChatOpenAI( # 备份渠道 2：Ollama 本地
base_url="http://localhost:11434/v1",
api_key="ollama",
model="qwen2.5:14b"
)
]
# 使用
llm = FailoverLLM(models)
response = await llm.ainvoke_with_failover([("user", "分析标书")])
d.成本优化策略
from enum import Enum
from typing import Dict
from langchain_openai import ChatOpenAI
class TaskComplexity(Enum):
LOW = "low"
MEDIUM = "medium"
HIGH = "high"
class CostOptimizedLLM:
"""成本优化的 LLM 选择器"""
def __init__(self):
self.models: Dict[TaskComplexity, ChatOpenAI] = {
TaskComplexity.LOW: ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-7B-Instruct",
temperature=0
),
TaskComplexity.MEDIUM: ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-32B-Instruct",
temperature=0
),
TaskComplexity.HIGH: ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-72B-Instruct",
temperature=0
)
}
def select_model(self, complexity: TaskComplexity) -> ChatOpenAI:
"""选择模型"""
return self.models[complexity]
async def ainvoke(self, messages, complexity: TaskComplexity, **kwargs):
"""调用"""
model = self.select_model(complexity)
return await model.ainvoke(messages, **kwargs)
# 使用
llm = CostOptimizedLLM()
# 简单任务 - 用 7B
response1 = await llm.ainvoke(
[("user", "提取公司名称")],
complexity=TaskComplexity.LOW
)
# 复杂任务 - 用 32B
response2 = await llm.ainvoke(
[("user", "分析条款符合度")],
complexity=TaskComplexity.MEDIUM
)
# 高度复杂任务 - 用 72B
response3 = await llm.ainvoke(
[("user", "多文档深度对比分析")],
complexity=TaskComplexity.HIGH
)
d.对比分析：通过 NewAPI vs 直接调用
a.功能对比
| 对比维度 | 通过 NewAPI | 直接调用多渠道 |
|---------|-------------|---------------|
| **统一管理** | ✅ 集中管理所有渠道 | ❌ 需要自己管理 |
| **负载均衡** | ✅ 内置负载均衡 | ❌ 需要自己实现 |
| **故障转移** | ✅ 自动故障转移 | ❌ 需要自己实现 |
| **计费统计** | ✅ 统一计费 | ❌ 分散计费 |
| **路由策略** | ✅ 灵活配置 | ⚠️ 需要编码实现 |
| **缓存** | ✅ 内置缓存 | ❌ 需要自己实现 |
| **监控** | ✅ 内置监控 | ❌ 需要自己实现 |
| **灵活性** | ⚠️ 受限于 NewAPI 功能 | ✅ 完全可控 |
| **依赖** | ❌ 依赖 NewAPI 服务 | ✅ 无额外依赖 |
| **性能** | ⚠️ 多一层代理 | ✅ 直连更快 |
b.通过 NewAPI
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ LangChain │───▶│ NewAPI │───▶│ 多渠道模型 │
└─────────────┘ │ (网关层) │ └─────────────┘
└─────────────┘
│
┌──────┴──────┐
│ │
┌────▼────┐ ┌───▼────┐
│ 路由策略 │ │ 负载均衡│
└─────────┘ └────────┘
┌─────────┐ ┌─────────┐
│ 故障转移│ │ 统一监控│
└─────────┘ └─────────┘
c.直接调用
┌─────────────┐
│ LangChain │
│ (业务层) │
└──────┬──────┘
│
┌───┴───────────────────────┐
│ │
┌──▼──────────┐ ┌──────▼──────┐
│ 路由逻辑 │ │ 负载均衡 │
│ (自定义) │ │ (自定义) │
└─────────────┘ └─────────────┘
│ │
└────────┬──────────────────┘
│
┌────────┴─────────┬──────────────┬─────────────┐
│ │ │ │
┌──▼──────────┐ ┌────▼─────┐ ┌────▼─────┐ ┌──▼──────────┐
│ OpenAI API │ │硅基流动 │ │ Ollama │ │ 通义千问 │
└─────────────┘ └──────────┘ └──────────┘ └─────────────┘
e.混合方案推荐
a.推荐架构
┌─────────────────────────────────────────────────────────────┐
│ 混合方案架构 │
└─────────────────────────────────────────────────────────────┘
┌─────────────┐
│ LangChain │
│ (业务层) │
└──────┬──────┘
│
┌───┴──────────────────────┐
│ │
┌──▼──────────┐ ┌──────▼──────┐
│ NewAPI │ │ 直接调用 │
│ (主要渠道) │ │ (备用/特殊) │
└─────────────┘ └─────────────┘
│ │
│ ┌─────┴─────┬──────────┐
│ │ │ │
┌──▼──────────┐ ┌────▼────┐ ┌──▼─────┐ ┌▼─────────┐
│ 硅基流动 │ │通义千问 │ │ Ollama │ │ DeepSeek │
│ (主) │ │ (备) │ │ (本地) │ │ (特殊) │
└─────────────┘ └─────────┘ └────────┘ └──────────┘
b.实现示例
from langchain_openai import ChatOpenAI
from typing import Optional
class HybridLLM:
"""混合 LLM：优先 NewAPI，失败时直接调用"""
def __init__(self):
# 通过 NewAPI 调用（主要渠道）
self.newapi_llm = ChatOpenAI(
base_url="http://newapi:3000/v1",
api_key="sk-newapi-key",
model="qwen2.5-32b"
)
# 直接调用备用渠道
self.backup_llms = [
ChatOpenAI(
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="sk-dashscope-key",
model="qwen2.5-32b"
),
ChatOpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama",
model="qwen2.5:14b"
)
]
async def ainvoke(self, messages, **kwargs):
"""智能调用"""
try:
# 优先使用 NewAPI
return await self.newapi_llm.ainvoke(messages, **kwargs)
except Exception as e:
print(f"NewAPI failed: {e}, trying backup...")
# 尝试备用渠道
for llm in self.backup_llms:
try:
return await llm.ainvoke(messages, **kwargs)
except Exception as e2:
print(f"Backup failed: {e2}")
continue
raise Exception("All channels failed")
# 使用
llm = HybridLLM()
response = await llm.ainvoke([("user", "分析标书")])
c.配置化方案
# config.py
from pydantic import BaseModel
from typing import List
class ChannelConfig(BaseModel):
name: str
base_url: str
api_key: str
model: str
priority: int = 0 # 优先级，数字越小越优先
class LLMConfig(BaseModel):
channels: List[ChannelConfig]
use_newapi: bool = True
newapi_url: str = "http://newapi:3000/v1"
# config.yaml
llm_config = LLMConfig(
use_newapi=True,
newapi_url="http://newapi:3000/v1",
channels=[
ChannelConfig(
name="dashscope_backup",
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
api_key="sk-dashscope-key",
model="qwen2.5-32b",
priority=1
),
ChannelConfig(
name="ollama_local",
base_url="http://localhost:11434/v1",
api_key="ollama",
model="qwen2.5:14b",
priority=2
)
]
)
# llm_manager.py
from config import llm_config
from langchain_openai import ChatOpenAI
class LLMManager:
"""LLM 管理器"""
def __init__(self, config: LLMConfig):
self.config = config
# NewAPI 渠道
if config.use_newapi:
self.newapi_llm = ChatOpenAI(
base_url=config.newapi_url,
api_key="sk-newapi-key",
model="qwen2.5-32b"
)
else:
self.newapi_llm = None
# 备用渠道（按优先级排序）
self.backup_llms = [
ChatOpenAI(
base_url=ch.base_url,
api_key=ch.api_key,
model=ch.model
)
for ch in sorted(config.channels, key=lambda x: x.priority)
]
async def ainvoke(self, messages, **kwargs):
"""智能调用"""
# 尝试 NewAPI
if self.newapi_llm:
try:
return await self.newapi_llm.ainvoke(messages, **kwargs)
except Exception as e:
print(f"NewAPI failed: {e}")
# 尝试备用渠道
for llm in self.backup_llms:
try:
return await llm.ainvoke(messages, **kwargs)
except Exception as e:
print(f"Backup failed: {e}")
continue
raise Exception("All channels failed")
# 使用
manager = LLMManager(llm_config)
response = await manager.ainvoke([("user", "分析标书")])
f.最佳实践建议
a.推荐方案
| 阶段 | 推荐方案 | 理由 |
|------|---------|------|
| **MVP** | 直接调用硅基流动 | 快速验证，无需额外组件 |
| **试运行** | NewAPI + 直接调用备用 | 统一管理 + 容灾备份 |
| **生产** | NewAPI 主 + 多渠道备 | 高可用 + 成本优化 |
b.实施建议
a.阶段 1: MVP (直接调用)
# 简单直接
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key="sk-key",
model="Qwen/Qwen2.5-32B-Instruct"
)
b.阶段 2: 添加 NewAPI
# 通过 NewAPI 统一管理
llm = ChatOpenAI(
base_url="http://newapi:3000/v1",
api_key="sk-newapi-key",
model="qwen2.5-32b"
)
c.阶段 3: 添加备用渠道
# 使用前面实现的 HybridLLM 或 LLMManager
llm = HybridLLM()
c.注意事项
| 注意事项 | 说明 |
|---------|------|
| ✅ **API Key 安全** | 不要将 Key 硬编码，使用环境变量 |
| ✅ **错误处理** | 实现完善的错误处理和重试机制 |
| ✅ **监控日志** | 记录调用情况，便于排查问题 |
| ✅ **成本控制** | 监控 API 调用量和费用 |
| ✅ **性能测试** | 测试不同渠道的响应速度 |
| ✅ **兼容性** | 确保各渠道接口兼容性 |
5 电子商务
5.1 [1]环境指南
01.离线环境初始化与模型适配指南
a.离线环境初始化 (全封闭)
a.基础环境准备
a.表格数据
步骤 任务 描述
1.1 OS 安装 鲲鹏 CPU 节点安装 麒麟 OS/统信 UOS。 确保系统版本与 CANN 兼容。
1.2 驱动安装 在 910B 节点安装 CANN 驱动。 必须使用官方提供的离线安装包，并严格遵循安装手册。
1.3 容器化 在鲲鹏 CPU 节点搭建 私有 Docker Registry。 用于存储所有应用和中间件的离线镜像。
1.4 Python 依赖 搭建 私有 PyPI 仓库 (如使用 Devpi)。 用于存储 LangChain、Milvus-client、dm-python 等所有 Python 依赖包。
b.中间件离线部署
a.表格数据
组件 部署方式 关键配置
达梦 DM8 离线安装包 部署 DSC 集群，开启 SM4 加密。
Milvus (CPU) Docker 离线镜像 确保分配足够的内存 (如 64GB+) 用于 HNSW 索引。
New-API 源码编译 + Docker 镜像 确保配置文件中所有外部 API 地址指向内网服务。
b.昇腾模型适配与量化
a.LLM 模型部署 (Qwen2.5-14B)
a.说明
1. 下载 Qwen2.5-14B 原始权重。
2. 使用 MindIE 提供的工具链，将模型转换为 OM 格式。
3. 进行 Int4 量化，大幅减少显存占用（约 16GB），提高推理速度。
4. 通过 MindIE 启动服务，暴露 OpenAI 兼容 API 接口。
b.模型选择：Qwen2.5-14B (Int4 量化)。
c.推理框架：MindIE (昇腾官方推理框架)。
d.适配流程：
b.New-API 模型网关配置
a.说明
New-API 的核心作用是作为 LangChain 与 MindIE 之间的“翻译官”和“调度员”。
b.代码示例
---
# New-API 配置文件示例 (config.yaml)
channels:
- name: ascend-llm-qwen14b
type: openai
base_url: http://910b-node-1:8000/v1 # MindIE 暴露的 OpenAI 接口
key: "empty"
models: ["qwen2.5-14b"]
priority: 1
weight: 10
- name: ascend-ocr-mindx
type: custom_http # 自定义插槽，用于非 OpenAI 协议的 OCR 服务
base_url: http://910b-node-2:8001/ocr/predict
models: ["mindx-ocr"]
priority: 1
weight: 10
---
c.Embedding 模型部署
1.模型：BGE-M3 或 M3E (中文高性能 Embedding 模型)。
2.部署：部署在鲲鹏 CPU 节点，使用 HuggingFaceEmbeddings，并指定 device='cpu'。
3.原因：Embedding 任务并发不高，且 CPU 节点内存充足，可避免占用宝贵的 910B 算力。
c.LangChain 环境锁定
a.说明
在全封闭环境下，必须锁定所有依赖，避免未来更新导致兼容性问题。
b.代码示例
---
# 锁定 LangChain 及其依赖
pip freeze > requirements.txt
# 确保 requirements.txt 中的所有包均已导入私有 PyPI 仓库
---
c.说明
核心依赖：langchain、langchain-openai (用于连接 New-API)、langchain-community (用于 Milvus/SQL Agent)、dm-python (达梦驱动)。
02.文档处理集群部署与集成指南
a.文档处理集群架构
a.说明
为了应对智能评标和供应商审核场景下的大量 PDF、Word、Excel 和图片处理需求，我们设计了基于 Unstructured + PaddleOCR 的集群化文档处理架构。
b.代码示例
---
graph TD
A[业务应用 (LangChain)] --> B(Kafka 消息队列)
B --> C{文档处理集群}
C --> D[Unstructured Service (CPU)]
C --> E[PaddleOCR Service (NPU)]
D --> F[结构化 JSON]
E --> F
F --> G(Kafka 结果队列)
G --> A
---
b.核心组件部署
a.Unstructured Service (结构化提取)
1.作用：负责 PDF、Word、Excel 的版面分析、表格提取和文本分块。
2.部署：部署在鲲鹏 CPU 节点，封装为 FastAPI 微服务。
3.集群化：通过 Docker Swarm 或 K8s 部署多个副本，实现负载均衡。
4.集成：LangChain 通过 HTTP 异步调用该服务，获取结构化文档片段。
b.PaddleOCR Service (文字识别)
1.作用：负责图片、扫描件 PDF 的高精度文字识别。
2.部署：部署在 昇腾 910B 节点，使用 PaddleOCR 昇腾适配版。
3.加速：利用 910B 的 NPU 算力进行 Batch 推理，实现高吞吐量。
4.集成：通过 New-API 封装为 mindx-ocr 插槽，供 LangChain 调用。
c.异步处理与集成
a.异步任务管理
a.说明
1. LangChain 向 Kafka 任务队列发送解析请求（包含文件路径）。
2. 文档处理集群消费任务，进行解析。
3. 解析完成后，将结果（结构化 JSON 或向量化结果）发送到 Kafka 结果队列。
4. 业务应用监听结果队列，获取最终数据。
b.场景：标书解析（如 500MB PDF）耗时较长，不能同步等待。
c.方案：
b.LangChain 集成代码示例 (伪代码)
a.代码示例
---
from langchain.document_loaders import UnstructuredFileLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Milvus
# 1. 异步调用文档处理集群 (通过 New-API 封装的 OCR/VL)
def async_parse_document(file_path):
# 实际调用 New-API 的 custom_http 插槽，触发集群解析
# ... 发送 Kafka 消息 ...
return task_id
# 2. 结构化加载器 (用于本地测试或同步小文件)
# 在生产环境中，此步骤由文档处理集群完成
loader = UnstructuredFileLoader(
"path/to/tender.pdf",
mode="elements",
# 模拟调用本地 Unstructured Service
url="http://unstructured-cluster:8000/general/v0/general"
)
docs = loader.load()
# 3. 文本切分与向量化
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
texts = text_splitter.split_documents(docs)
# 4. 存入 Milvus
vector_db.add_documents(texts)
---
03.全昇腾信创环境 AI 系统技术方案
a.总体设计思路
a.说明
本方案旨在为全昇腾、全信创、全封闭环境下的【AI智能客服】、【供应商智能审核】及【智能评标】三大系统提供核心技术支撑。方案充分考虑了昇腾 910B 的算力特性、达梦数据库的信创要求以及 7B/16B 级轻量化模型的部署优势。
b.核心架构原则
a.说明
---
b.存算分离：AI 算力集中在昇腾 910B 节点，业务逻辑与数据库运行在鲲鹏 CPU 节点。
c.信创闭环：全栈采用国产软硬件（昇腾 NPU + 鲲鹏 CPU + 麒麟 OS + 达梦 DB）。
d.轻量高效：优先选用 7B/16B 级模型，通过量化与算子优化确保在单卡/双卡环境下的极速响应。
b.硬件资源规划与适配
a.说明
根据用户提供的 2 台 AI 应用服务器（16C64G2T x 昇腾 910B）及相关辅助服务器，资源分配如下：
b.表格数据
服务器类型 核心配置 建议部署服务 备注
AI 应用服务器 (x2) 16C64G2T + 昇腾 910B LLM 推理 (MindIE)、OCR 推理 (MindX SDK) 核心算力池
AI 模型运行服务器 28C128G2T + T4 (信创版) Embedding 加速、应用后端、中间件 业务逻辑中心
备份服务器 16C32G10T 达梦数据库备份、模型权重备份、知识库冷备 数据安全中心
c.模型选型建议
a.说明
针对 910B 显存（通常为 32GB/64GB）及 7B/16B 需求：
---
b.通用 LLM：Qwen2.5-7B/14B-Instruct。14B 模型在逻辑推理与指令遵循上显著优于 7B，且在 910B 上开启 Int4 量化后显存占用极低，支持超长上下文。
c.多模态 LLM：Qwen2-VL-7B。用于处理带图表的标书、证件照片，具备极强的视觉理解能力。
d.OCR 专用：PaddleOCR (昇腾适配版)。用于大规模文档的高速文字提取。
c.三大系统技术方案
a.AI 智能客服：极速响应与精准检索
a.说明
1. 意图识别：利用 Qwen2.5-7B 快速判断用户咨询类型（注册、流程、政策）。
2. 知识检索：将达梦数据库中的 FAQ 与文档预向量化。由于达梦原生不支持向量检索，采用 Milvus (CPU 内存模式) 部署在业务服务器，利用 128G 大内存实现毫秒级检索。
3. 回复生成：结合检索到的知识，由 Qwen2.5-14B 生成标准回答。
b.技术路径：RAG (检索增强生成) + 意图识别。
c.核心流程：
d.信创适配：使用 MindIE 提供的 OpenAI 兼容接口，前端通过 WebSocket 实现流式输出。
b.供应商智能审核：多模态识别与规则校验
a.说明
1. 文档解析：调用昇腾适配版 PaddleOCR 提取营业执照、资质证书文字。
2. 视觉校验：利用 Qwen2-VL-7B 校验印章真实性、证件有效期及图片关键信息。
3. 规则比对：将提取的信息与达梦数据库中的准入规则进行逻辑比对，自动给出审核建议。
b.技术路径：OCR + 多模态理解 + 结构化提取。
c.核心流程：
d.优势：910B 的算力可支持多路 OCR 并发，大幅缩短供应商入驻等待时间。
c.智能评标：长文档理解与客观打分
a.说明
1. 标书切片：针对数百页的标书，进行智能分段并存入向量库。
2. 条款对齐：根据招标文件要求，自动在标书中定位相关响应条款。
3. 客观打分：利用 Qwen2.5-14B (32K 上下文) 对技术参数进行客观比对，并生成打分依据。
---
b.技术路径：长文本 RAG + 逻辑推理打分。
c.核心流程：
d.数据安全：所有计算均在全封闭内网完成，达梦数据库开启 SM4 加密存储，确保标书数据不外泄。
d.达梦数据库 (DM8) 适配方案
由于达梦数据库目前主要作为关系型数据库使用，向量检索建议采用以下组合方案：
1.元数据存储：业务数据、用户信息、审核记录存储在 DM8 中。
2.向量存储：使用 Milvus 或 Elasticsearch (信创版) 作为向量插件。
3.关联查询：应用层通过 ID 关联，实现“关系型数据 + 向量数据”的混合查询。
---
e.实施建议与讨论点
1.模型量化：建议对 14B 模型进行 W4A16 量化，以在 910B 上获得更高的吞吐量。
2.网络环境：全封闭环境下需提前准备好所有依赖包（CANN、MindIE、Python 库）的离线镜像。
3.性能压测：建议针对“开标时刻”的高并发场景，对 910B 的推理并发数进行专项调优。
请您审阅以上思路，我们可以针对其中某个系统的具体业务逻辑（如评标的具体打分项）进行更深入的讨论。
04.全栈信创 AI 链路架构设计
a.说明
本架构专为全封闭、全昇腾信创环境设计，通过 New-API 实现模型能力的标准化抽象，利用 LangChain 构建业务逻辑，并结合 Milvus 与 达梦数据库 实现存算分离。
b.逻辑架构图
a.代码示例
---
graph TD
subgraph "用户接入层"
Web[Web/移动端] --> App[LangChain 业务应用]
end
subgraph "应用逻辑层 (LangChain Python)"
App --> RAG[RAG 检索模块]
App --> Agent[智能体决策模块]
App --> Chain[业务流程链]
end
subgraph "模型网关层 (New-API 插槽)"
Gateway[New-API Gateway]
RAG --> Gateway
Agent --> Gateway
Chain --> Gateway
end
subgraph "算力与推理层 (昇腾 910B)"
MindIE[MindIE 推理服务]
OCR_Svc[MindX OCR 服务]
Gateway -- OpenAI 协议 --> MindIE
Gateway -- 自定义插槽 --> OCR_Svc
end
subgraph "数据持久化层"
Milvus[Milvus 向量库]
Dameng[达梦数据库 DM8]
RAG --> Milvus
App --> Dameng
end
---
c.核心组件选型与职责
a.表格数据
组件 选型 在信创环境中的职责
模型网关 New-API API 插槽中心：统一封装 MindIE (LLM) 和 MindX (OCR) 接口，提供标准 OpenAI 格式，支持多模型负载均衡与 Key 管理。
应用框架 LangChain (Python) 业务大脑：负责 Prompt 编排、多轮对话管理、RAG 流程控制以及与数据库的交互逻辑。
向量存储 Milvus (CPU版) 语义索引：在鲲鹏服务器大内存中运行，存储标书、FAQ 的向量数据，支持高性能语义检索。
关系数据库 达梦 DM8 数据底座：存储结构化业务数据（用户信息、审核规则、评标结果、审计日志），确保数据合规与持久化。
推理引擎 MindIE 算力引擎：在昇腾 910B 上运行 Qwen2.5-14B 等模型，提供高性能推理能力。
d.关键技术路线
1.标准化接口：New-API 将昇腾底层的复杂推理接口（MindIE）转换为标准的 /v1/chat/completions，使得 LangChain 代码无需修改即可在信创与非信创环境间迁移。
2.混合检索方案：LangChain 同时连接 Milvus（查语义）和达梦（查元数据/精确匹配），通过 Rerank 算法（亦可在 910B 部署轻量级模型）提升准确率。
3.离线部署适配：所有组件均采用 Docker 容器化部署，通过私有镜像仓库分发，适配全封闭环境。
05.全栈信创 AI 系统技术选型矩阵 (全封闭环境)
a.说明
本矩阵旨在为全昇腾、全信创、完全断网的 AI 平台提供一套精密、可靠的技术选型方案。所有选型均优先考虑国产化、离线部署和集群扩展性。
b.基础设施与平台层
a.表格数据
模块 选型/技术 部署环境 关键特性 信创/断网适配
操作系统 麒麟 Kylin OS / 统信 UOS 物理机/虚拟机 国产主流操作系统，安全可靠 信创核心，官方支持昇腾/鲲鹏
硬件平台 昇腾 910B (AI) + 鲲鹏 920 (CPU) 物理机 算力与通用计算分离，性能互补 全昇腾，满足国产化要求
容器化 Docker / K8s (自建) 鲲鹏 CPU 节点 简化部署、资源隔离、集群管理 采用离线镜像仓库，完全断网部署
应用服务器 东方通 TongWeb / 宝兰德 BES 鲲鹏 CPU 节点 国产主流应用服务器，高并发支持 信创核心，替代 Tomcat/JBoss
消息队列 Kafka (自建) 鲲鹏 CPU 节点 异步通信、削峰填谷、集群部署 采用离线安装包，替代公有云服务
c.数据存储与检索层
a.表格数据
模块 选型/技术 部署环境 关键特性 信创/断网适配
关系数据库 达梦 DM8 (DSC 集群) 鲲鹏 CPU 节点 事务处理、数据持久化、高可用 信创核心，满足业务数据存储要求
向量数据库 Milvus (CPU 版) 鲲鹏 CPU 节点 (大内存) 向量检索、RAG 核心组件 开源软件，CPU 版可利用鲲鹏大内存，无需 NPU/GPU
缓存 Redis (自建集群) 鲲鹏 CPU 节点 会话管理、热点数据缓存 开源软件，易于离线部署和集群化
数据安全 达梦 SM4 加密 达梦 DM8 敏感数据存储加密，符合国密标准 信创核心，保障数据安全
d.AI 模型与应用层
a.表格数据
模块 选型/技术 部署环境 关键特性 信创/断网适配
大模型推理 MindIE 昇腾 910B 节点 昇腾官方推理框架，高性能、低延迟 昇腾核心，充分利用 910B 算力
模型网关 New-API (自建) 鲲鹏 CPU 节点 统一接口、负载均衡、模型插槽 开源项目，可离线部署，兼容 OpenAI 协议
应用框架 LangChain (Python) 鲲鹏 CPU 节点 业务逻辑编排、RAG 流程控制 开源框架，Python 语言，易于适配国产环境
LLM 模型 Qwen2.5-14B (Int4 量化) 昇腾 910B 节点 兼顾智商与速度，满足 7B/16B 需求 模型权重可离线下载，通过 MindIE 部署
Embedding BGE-M3 / M3E 鲲鹏 CPU 节点 高质量中文向量生成 开源模型，可离线部署，CPU 推理速度快
e.文档处理与解析集群 (关键)
a.说明
针对用户提出的 PDF、Word、Excel、图片等复杂文档处理需求，我们采用 “多工具协同 + 集群化部署” 方案，确保高并发和高准确率。
b.表格数据
模块 选型/技术 部署环境 关键特性 集群化/开源适配
OCR 识别 PaddleOCR (昇腾版) 昇腾 910B 节点 百度飞桨与昇腾深度合作，中文识别准确率高 昇腾核心，可集群部署，利用 NPU 加速
文档结构化 Unstructured (Python) 鲲鹏 CPU 节点 复杂 PDF/Word/Excel 结构解析，提取表格、标题、文本 开源工具，Python 易于集成，可部署为微服务集群
多模态理解 Qwen2-VL-7B 昇腾 910B 节点 识别图片、图表、印章等视觉信息 通过 New-API 统一调用，解决复杂文档理解
集群部署 文档解析微服务 鲲鹏 CPU 节点 将 Unstructured 封装为 FastAPI 服务，通过 K8s 实现负载均衡 高度可扩展，满足智能评标等高并发场景
c.说明
---
f.离线部署与安全加固建议
1.离线仓库：搭建私有 PyPI 仓库、Docker Registry，所有依赖包和镜像均提前导入。
2.代码审查：所有开源代码（LangChain, New-API, Milvus）均需进行安全审计，确保无外部网络依赖。
3.国密支持：应用层和数据库层之间采用国密 SSL/TLS 传输加密，达梦数据库开启 SM4 存储加密。
4.日志审计：所有 AI 推理请求、业务操作均记录到达梦数据库，满足可追溯性要求。
5.2 [1]生态总览
01.模型能力分类与选型
a.评标场景模型需求分析
a.核心评标流程
┌─────────────────────────────────────────────────────────────┐
│ 评标完整流程 │
└─────────────────────────────────────────────────────────────┘
阶段 1: 文档接收与解析
├── 输入: PDF/Word/图片格式的标书
├── 处理:
│ ├── 文档格式转换
│ ├── OCR 文字识别 (图片文档)
│ ├── 表格数据提取
│ └── 文档结构理解
└── 输出: 结构化文档内容
阶段 2: 评标规则配置
├── 输入: 招标文件要求
├── 处理:
│ ├── 提取评分项
│ ├── 设置权重
│ └── 定义评分标准
└── 输出: 评标规则配置
阶段 3: 智能评标分析
├── 输入: 标书 + 评标规则
├── 处理:
│ ├── 标书比对分析
│ ├── 条款符合度检查
│ ├── 价格横向对比
│ └── 技术参数评分
└── 输出: 评标分析结果
阶段 4: 报告生成
├── 输入: 评标分析结果
├── 处理:
│ ├── 汇总评标数据
│ ├── 生成评标意见
│ └── 生成推荐建议
└── 输出: 评标报告 (PDF/Word)
b.各阶段模型能力需求
a.阶段 1: 文档解析
| 能力需求 | 说明 | 必需性 |
|---------|------|--------|
| **OCR 识别** | 图片文档转文字 | 必需 |
| **PDF 解析** | 提取 PDF 文字和表格 | 必需 |
| **Word 解析** | 提取 Word 文档结构 | 必需 |
| **表格识别** | 识别表格结构和数据 | 必需 |
| **文档理解** | 理解文档章节结构 | 重要 |
| **图表理解** | 理解图表含义 | 可选 |
b.阶段 2: 规则配置
| 能力需求 | 说明 | 必需性 |
|---------|------|--------|
| **文本理解** | 理解招标要求 | 必需 |
| **信息提取** | 提取评分要点 | 重要 |
| **分类归纳** | 归纳评分类别 | 可选 |
c.阶段 3: 评标分析
| 能力需求 | 说明 | 必需性 |
|---------|------|--------|
| **长文本理解** | 理解长篇标书 | 必需 |
| **对比分析** | 对比多份标书 | 必需 |
| **逻辑推理** | 判断符合度 | 必需 |
| **数值计算** | 计算评分 | 重要 |
| **表格理解** | 提取参数表 | 必需 |
d.阶段 4: 报告生成
| 能力需求 | 说明 | 必需性 |
|---------|------|--------|
| **文本生成** | 生成评标意见 | 必需 |
| **数据汇总** | 汇总评分数据 | 重要 |
| **格式化输出** | 生成报告 | 必需 |
b.模型能力分类
a.文本理解模型
a.能力定义
文本理解模型能力:
├── 长文本处理 (32K+ tokens)
├── 语义理解
├── 逻辑推理
├── 信息提取
├── 文本分类
└── 文本生成
b.评标场景需求
| 场景 | 需要的能力 | 最低要求 | 推荐配置 |
|------|-----------|---------|---------|
| **理解评标规则** | 文本理解、推理 | 7B | 32B+ |
| **条款符合度分析** | 长文本理解、推理 | 32B | 72B |
| **生成评标意见** | 文本生成 | 7B | 32B+ |
| **多文档对比** | 长文本、推理 | 32B | 72B |
c.推荐模型
| 模型 | 参数 | 上下文 | 优势 | 劣势 |
|------|------|--------|------|------|
| Qwen2.5-72B | 72B | 32K | 中文能力强，推理好 | 成本高 |
| Qwen2.5-32B | 32B | 32K | 性价比高 | 推理略弱 |
| Qwen2.5-14B | 14B | 32K | 成本低 | 能力有限 |
| Qwen2.5-7B | 7B | 32K | 最便宜 | 能力不足 |
b.多模态文档理解模型
a.能力定义
多模态文档理解能力:
├── 视觉输入 (图片、PDF 页面)
├── 文档布局理解
├── 表格识别与提取
├── 图表理解
├── OCR 文字识别
└── 文档结构分析
b.评标场景需求
| 场景 | 需要的能力 | 最低要求 | 推荐配置 |
|------|-----------|---------|---------|
| **PDF 文档解析** | 视觉理解、表格识别 | 7B | 7B-32B |
| **表格数据提取** | 表格识别 | 7B | 7B |
| **图表理解** | 视觉理解 | 7B | 7B |
| **图片文档 OCR** | OCR 能力 | 7B | 专用 OCR |
c.推荐模型
| 模型 | 参数 | 视觉能力 | 优势 | 劣势 |
|------|------|---------|------|------|
| Qwen2-VL-72B | 72B | ⭐⭐⭐⭐⭐ | 理解力强 | 成本高 |
| Qwen2-VL-7B | 7B | ⭐⭐⭐⭐ | 性价比高 | 复杂场景较弱 |
| GPT-4V | - | ⭐⭐⭐⭐⭐ | 综合最强 | 成本最高 |
| Claude 3.5 Sonnet | - | ⭐⭐⭐⭐⭐ | 图表理解强 | 成本高 |
c.OCR 专用模型
a.能力定义
OCR 能力:
├── 文字识别
├── 表格结构识别
├── 版面分析
├── 手写识别 (可选)
└── 印章识别 (可选)
b.评标场景需求
| 场景 | 需要的能力 | 优先级 |
|------|-----------|--------|
| **图片文档 OCR** | 文字识别 | 高 |
| **扫描 PDF OCR** | 文字识别 | 高 |
| **表格提取** | 表格结构识别 | 高 |
| **复杂版面** | 版面分析 | 中 |
| **印章识别** | 印章识别 | 低 |
c.推荐方案
| 方案 | 优势 | 劣势 | 成本 |
|------|------|------|------|
| **PaddleOCR** | 免费开源，中文好 | 需要部署 | 免费 (硬件) |
| **Tesseract OCR** | 免费开源 | 中文弱 | 免费 (硬件) |
| **Azure OCR** | 准确率高 | 成本高 | 按次计费 |
| **Google Vision AI** | 准确率高 | 成本高 | 按次计费 |
| **多模态 LLM** | 理解能力强 | 成本高 | 按次计费 |
c.模型组合方案
a.最小化方案 (低成本)
a.模型组合
┌─────────────────────────────────────────────────────────┐
│ 最小化模型组合 │
└─────────────────────────────────────────────────────────┘
文本理解: Qwen2.5-7B
├── 用途: 理解评标规则、生成简单意见
├── 成本: ¥0.0001/1K tokens (硅基流动)
└── 限制: 复杂推理能力有限
文档解析: PaddleOCR + 规则提取
├── 用途: OCR + 表格提取
├── 成本: 免费 (本地部署)
└── 限制: 需要自己实现解析逻辑
多模态: Qwen2-VL-7B (按需)
├── 用途: 复杂文档理解
├── 成本: ¥0.0006/1K tokens (硅基流动)
└── 限制: 仅必要时使用
b.适用场景
预算有限 (< ¥1000/月)
标书相对简单规范
可以接受较低准确率
愿意投入开发成本
c.成本估算
| 场景 | 调用次数 | 月成本 |
|------|---------|--------|
| 小规模 (10 份标书/月) | ~5000 次 | ¥50-100 |
| 中规模 (50 份标书/月) | ~25000 次 | ¥200-400 |
| 大规模 (100 份标书/月) | ~50000 次 | ¥400-800 |
b.性价比方案 (推荐)
a.模型组合
┌─────────────────────────────────────────────────────────┐
│ 性价比模型组合 │
└─────────────────────────────────────────────────────────┘
文本理解: Qwen2.5-32B
├── 用途: 主要的文本理解和推理
├── 成本: ¥0.0006/1K tokens (硅基流动)
└── 优势: 平衡性能和成本
文档解析: PaddleOCR + Qwen2-VL-7B
├── 用途: OCR + 文档理解
├── 成本: OCR 免费 + VL ¥0.0006/1K tokens
└── 优势: 混合方案，成本可控
复杂推理: Qwen2.5-72B (按需)
├── 用途: 复杂条款分析
├── 成本: ¥0.006/1K tokens (硅基流动)
└── 限制: 仅必要时使用
b.适用场景
中等预算 (¥1000-5000/月)
标书复杂度中等
需要较好准确率
追求性价比
c.成本估算
| 场景 | 调用次数 | 月成本 |
|------|---------|--------|
| 小规模 (10 份标书/月) | ~5000 次 | ¥100-200 |
| 中规模 (50 份标书/月) | ~25000 次 | ¥500-1000 |
| 大规模 (100 份标书/月) | ~50000 次 | ¥1000-2000 |
c.高性能方案
a.模型组合
┌─────────────────────────────────────────────────────────┐
│ 高性能模型组合 │
└─────────────────────────────────────────────────────────┘
文本理解: Qwen2.5-72B
├── 用途: 所有文本理解和推理
├── 成本: ¥0.006/1K tokens (硅基流动)
└── 优势: 最强能力
文档解析: Qwen2-VL-72B
├── 用途: 文档理解、表格提取
├── 成本: ¥0.006/1K tokens (硅基流动)
└── 优势: 最好效果
OCR: PaddleOCR (辅助)
├── 用途: 预处理和辅助
├── 成本: 免费
└── 优势: 降低成本
b.适用场景
充足预算 (¥5000+/月)
标书非常复杂
要求最高准确率
快速响应需求
c.成本估算
| 场景 | 调用次数 | 月成本 |
|------|---------|--------|
| 小规模 (10 份标书/月) | ~5000 次 | ¥300-500 |
| 中规模 (50 份标书/月) | ~25000 次 | ¥1500-2500 |
| 大规模 (100 份标书/月) | ~50000 次 | ¥3000-5000 |
d.免费模型方案
a.Ollama 本地部署
a.可用模型
| 模型 | 参数 | 显存需求 | 能力评估 |
|------|------|---------|---------|
| qwen2.5:7b | 7B | ~8GB | ⭐⭐⭐ |
| qwen2.5:14b | 14B | ~16GB | ⭐⭐⭐⭐ |
| qwen2.5:32b | 32B | ~32GB | ⭐⭐⭐⭐ |
| qwen2-vl:7b | 7B | ~8GB | ⭐⭐⭐ |
b.部署示例
# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 拉取模型
ollama pull qwen2.5:14b
ollama pull qwen2-vl:7b
# 启动服务
ollama serve
# 调用测试
curl http://localhost:11434/api/generate -d '{
"model": "qwen2.5:14b",
"prompt": "分析以下招标要求..."
}'
c.NewAPI 接入
{
"name": "Ollama 本地模型",
"type": 1,
"base_url": "http://localhost:11434/v1",
"key": "ollama",
"models": "qwen2.5:14b,qwen2-vl:7b"
}
d.成本分析
| 配置 | 硬件成本 | 电费 (月) | 总成本 (年) |
|------|---------|----------|------------|
| RTX 4090 (24GB) | ¥15,000 | ¥150 | ¥16,800 |
| 2x RTX 4090 | ¥30,000 | ¥300 | ¥33,600 |
| A100 40GB | ¥60,000 | ¥300 | ¥63,600 |
e.适用场景
有现成 GPU 资源
长期使用 (2 年以上)
对数据隐私要求高
有运维能力
b.完全免费方案
a.技术栈
完全免费方案:
├── 模型: Ollama + Qwen2.5-7B
├── OCR: PaddleOCR (本地)
├── 多模态: Qwen2-VL-7B (Ollama)
└── 部署: 本地服务器
b.限制
需要硬件投入
模型能力有限
响应速度较慢
需要自己运维
e.硅基流动方案详情
a.可用模型与价格
a.文本模型
| 模型 | 参数 | 上下文 | 输入 | 输出 |
|------|------|--------|------|------|
| Qwen2.5-72B | 72B | 32K | ¥0.0006/1K | ¥0.0006/1K |
| Qwen2.5-32B | 32B | 32K | ¥0.0002/1K | ¥0.0002/1K |
| Qwen2.5-14B | 14B | 32K | ¥0.0001/1K | ¥0.0001/1K |
| Qwen2.5-7B | 7B | 32K | ¥0.00005/1K | ¥0.00005/1K |
b.多模态模型
| 模型 | 参数 | 价格 |
|------|------|------|
| Qwen2-VL-72B | 72B | ¥0.006/1K |
| Qwen2-VL-7B | 7B | ¥0.0006/1K |
b.NewAPI 配置示例
a.硅基流动渠道配置
{
"name": "硅基流动 Qwen2.5-32B",
"type": 1,
"base_url": "https://api.siliconflow.cn/v1",
"key": "sk-your-api-key",
"models": "Qwen/Qwen2.5-32B-Instruct",
"priority": 1,
"weight": 10
}
b.多渠道负载均衡
{
"channels": [
{
"name": "硅基流动-主",
"type": 1,
"base_url": "https://api.siliconflow.cn/v1",
"models": "Qwen/Qwen2.5-32B-Instruct",
"priority": 1,
"weight": 7
},
{
"name": "Ollama-备",
"type": 1,
"base_url": "http://localhost:11434/v1",
"models": "qwen2.5:14b",
"priority": 2,
"weight": 3
}
]
}
c.成本优化策略
a.策略 1: 智能路由
简单任务 (7B):
├── 简单信息提取
├── 格式化输出
└── 成本: ¥0.00005/1K
中等任务 (32B):
├── 文档理解
├── 条款分析
└── 成本: ¥0.0002/1K
复杂任务 (72B):
├── 复杂推理
├── 多文档对比
└── 成本: ¥0.0006/1K
b.策略 2: 缓存优化
| 缓存类型 | 场景 | 节省比例 |
|---------|------|---------|
| **结果缓存** | 重复文档 | 80%+ |
| **向量缓存** | 相似文档 | 50%+ |
| **Prompt 缓存** | 固定模板 | 90%+ |
c.策略 3: Token 优化
# 优化前
prompt = """
你是一个专业的评标专家，请仔细分析以下标书文档，
对比招标文件的要求，逐条检查符合度，
并给出详细的评标意见...
"""
# 优化后 (节省 60% tokens)
prompt = "角色:评标专家。任务:分析标书符合度。标书:{docs}"
f.模型能力测试建议
a.测试用例设计
a.测试 1: 文档解析能力
测试文档:
├── PDF 格式标书 (10 页)
├── 包含表格 (3 个)
├── 包含图表 (2 个)
└── 包含复杂版面
评估指标:
├── 文字提取准确率 > 95%
├── 表格提取准确率 > 90%
├── 结构识别准确率 > 85%
└── 处理时间 < 30 秒
b.测试 2: 条款理解能力
测试场景:
├── 输入: 招标要求 + 标书承诺
├── 任务: 逐条对比符合度
└── 输出: 符合/不符合/部分符合
评估指标:
├── 符合度判断准确率 > 90%
├── 差异点识别准确率 > 85%
└── 处理时间 < 60 秒
c.测试 3: 价格分析能力
测试场景:
├── 输入: 3 份标书价格表
├── 任务: 提取并对比价格
└── 输出: 价格对比报告
评估指标:
├── 价格提取准确率 > 95%
├── 计算正确率 = 100%
└── 处理时间 < 30 秒
b.A/B 测试方案
a.测试矩阵
| 模型组合 | 测试样本数 | 通过标准 | 备注 |
|---------|-----------|---------|------|
| 7B + OCR | 20 份 | 准确率 > 80% | 基线 |
| 32B + OCR | 20 份 | 准确率 > 90% | 推荐 |
| 72B + VL | 20 份 | 准确率 > 95% | 高端 |
g.模型选型建议
a.按预算选型
| 月预算 | 推荐方案 | 核心模型 | 预期效果 |
|--------|---------|---------|---------|
| < ¥500 | 最小化方案 | Qwen2.5-7B + PaddleOCR | 基础可用 |
| ¥500-2000 | 性价比方案 | Qwen2.5-32B + Qwen2-VL-7B | 良好 |
| ¥2000-5000 | 性价比方案 | Qwen2.5-32B + Qwen2-VL-7B | 优秀 |
| > ¥5000 | 高性能方案 | Qwen2.5-72B + Qwen2-VL-72B | 最佳 |
b.按场景选型
| 场景特征 | 推荐模型 | 理由 |
|---------|---------|------|
| **简单标书** | Qwen2.5-14B + OCR | 成本低，够用 |
| **标准标书** | Qwen2.5-32B + VL | 性价比最高 |
| **复杂标书** | Qwen2.5-72B + VL | 能力最强 |
| **大量文档** | 混合方案 | 成本可控 |
c.最终推荐
a.阶段 1: 验证期 (第 1-2 周)
推荐配置:
├── 文本: Qwen2.5-7B (免费额度或 Ollama)
├── 多模态: Qwen2-VL-7B (硅基流动)
└── OCR: PaddleOCR (本地)
目标: 验证核心流程可行
b.阶段 2: 试运行期 (第 3-8 周)
推荐配置:
├── 文本: Qwen2.5-32B (硅基流动)
├── 多模态: Qwen2-VL-7B (硅基流动)
└── OCR: PaddleOCR (本地)
目标: 平衡性能和成本
c.阶段 3: 生产期 (第 9 周后)
选项 A (云端方案):
├── 文本: Qwen2.5-32B (硅基流动)
├── 多模态: Qwen2-VL-7B/32B (硅基流动)
└── OCR: PaddleOCR (本地)
选项 B (混合方案):
├── 文本: Qwen2.5-32B (本地 Ollama)
├── 多模态: Qwen2-VL-7B (硅基流动)
└── OCR: PaddleOCR (本地)
选项 C (昇腾方案):
├── 文本: Qwen2.5-72B (昇腾 NPU)
├── 多模态: Qwen2.5-VL-32B (昇腾 NPU)
└── OCR: PaddleOCR (昇腾 NPU)
02.调用方式对比
a.技术栈总览
a.Python 方案
a.完整技术栈
---
┌─────────────────────────────────────────────────────────────┐
│ Python 技术栈 │
└─────────────────────────────────────────────────────────────┘
核心层:
├── Python 3.10+
├── FastAPI (Web 框架)
├── httpx/aiohttp (HTTP 客户端)
└── SQLAlchemy (ORM)
AI 层:
├── OpenAI SDK (模型调用)
├── LangChain (可选)
│ ├── LangChain Core
│ ├── LangChain OpenAI
│ └── LangChain Community
├── LlamaIndex (可选)
└── 自定义 Prompt 管理
异步层:
├── Celery (任务队列)
├── Redis (消息代理)
└── asyncio (异步编程)
数据处理:
├── Pandas (数据分析)
├── NumPy (数值计算)
└── Pydantic (数据验证)
---
b.依赖示例
---
# requirements.txt
fastapi==0.109.0
uvicorn[standard]==0.27.0
httpx==0.26.0
openai==1.10.0
pydantic==2.5.0
sqlalchemy==2.0.25
celery==5.3.0
redis==5.0.0
# 可选
langchain==0.1.0
langchain-openai==0.0.5
pandas==2.1.0
---
c.Bun/TypeScript 方案
a.完整技术栈
---
┌─────────────────────────────────────────────────────────────┐
│ Bun/TypeScript 技术栈 │
└─────────────────────────────────────────────────────────────┘
核心层:
├── Bun 1.0+
├── TypeScript 5.0+
├── Hono (Web 框架)
└── Drizzle ORM (ORM)
AI 层:
├── OpenAI SDK (模型调用)
├── LangChain.js (可选)
│ ├── @langchain/core
│ ├── @langchain/openai
│ └── @langchain/community
└── 自定义 Prompt 管理
异步层:
├── Bun 后台任务 (内置)
└── EventEmitter (事件驱动)
数据处理:
├── 数组方法 (原生)
└── Zod (数据验证)
---
b.依赖示例
---
// package.json
{
"dependencies": {
"hono": "^3.12.0",
"openai": "^4.26.0",
"zod": "^3.22.0",
"drizzle-orm": "^0.29.0"
},
"devDependencies": {
"typescript": "^5.3.0",
"bun-types": "^1.0.0"
}
}
// 可选
// "@langchain/core": "^0.1.0",
// "@langchain/openai": "^0.0.0",
---
b.核心能力对比
a.HTTP 调用性能
a.Python (httpx)
---
import httpx
import asyncio
async def call_model(prompt: str):
async with httpx.AsyncClient() as client:
response = await client.post(
"http://newapi:3000/v1/chat/completions",
json={
"model": "qwen2.5-32b",
"messages": [{"role": "user", "content": prompt}]
},
timeout=60.0
)
return response.json()
# 并发调用
async def batch_call(prompts: list[str]):
async with httpx.AsyncClient() as client:
tasks = [call_model(p) for p in prompts]
return await asyncio.gather(*tasks)
---
b.Bun (fetch)
---
async function callModel(prompt: string) {
const response = await fetch('http://newapi:3000/v1/chat/completions', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
model: 'qwen2.5-32b',
messages: [{ role: 'user', content: prompt }]
}),
signal: AbortSignal.timeout(60000)
});
return await response.json();
}
// 并发调用
async function batchCall(prompts: string[]) {
return await Promise.all(prompts.map(p => callModel(p)));
}
---
c.性能对比
指标 Python Bun 说明
冷启动 ~500ms ~50ms Bun 快 10 倍
内存占用 ~50MB ~5MB Bun 省 90%
并发性能 中等 高 Bun 更优
HTTP/2 支持 原生支持 都可以
WebSocket 支持 原生支持 都可以
b.类型安全
a.Python (Pydantic)
---
from pydantic import BaseModel, Field
from typing import Optional
class Document(BaseModel):
id: int
name: str = Field(..., min_length=1, max_length=255)
type: str = Field(..., pattern=r'^(pdf|docx|jpg)$')
content: Optional[str] = None
class Config:
json_schema_extra = {
"example": {
"id": 1,
"name": "标书.pdf",
"type": "pdf",
"content": "..."
}
}
# 运行时验证
doc = Document(**data) # 自动验证
---
b.TypeScript (Zod)
---
import { z } from 'zod';
const DocumentSchema = z.object({
id: z.number().int().positive(),
name: z.string().min(1).max(255),
type: z.enum(['pdf', 'docx', 'jpg']),
content: z.string().optional()
});
type Document = z.infer<typeof DocumentSchema>;
// 运行时验证
const doc = DocumentSchema.parse(data);
---
c.对比
特性 Python + Pydantic TypeScript + Zod
类型定义 运行时 + 文档 编译时 + 运行时
IDE 支持 中等 优秀
自动补全 有限 完整
错误检测 运行时 编译时
学习曲线 平缓 中等
c.异步任务处理
a.Python (Celery)
---
# tasks.py
from celery import Celery
celery_app = Celery('tasks', broker='redis://localhost:6379/0')
@celery_app.task
def parse_document(doc_id: int):
# 文档解析逻辑
result = heavy_parsing(doc_id)
return result
# 调用
result = parse_document.delay(doc_id)
status = result.status
value = result.get(timeout=60)
---
b.Bun (Background Tasks)
---
// background.ts
import { Queue } from 'bun';
const queue = new Queue<{ docId: number }, any>();
// Worker
queue.worker(async (job) => {
const { docId } = job.data;
return await heavyParsing(docId);
});
// 调用
const job = await queue.add({ docId: 1 });
const result = await job.getResult();
---
c.对比
特性 Python + Celery Bun 内置
复杂度 高 低
依赖 Redis + Celery 无额外依赖
可靠性 高 中等
监控 完善 基础
分布式 支持 有限
c.AI 生态对比
a.直接调用 NewAPI
a.Python 示例
---
import httpx
class NewAPIClient:
def __init__(self, base_url: str, api_key: str):
self.base_url = base_url
self.api_key = api_key
async def chat(self, model: str, messages: list[dict]) -> str:
async with httpx.AsyncClient() as client:
response = await client.post(
f"{self.base_url}/chat/completions",
headers={"Authorization": f"Bearer {self.api_key}"},
json={
"model": model,
"messages": messages
}
)
return response.json()["choices"][0]["message"]["content"]
# 使用
client = NewAPIClient("http://newapi:3000/v1", "sk-key")
result = await client.chat("qwen2.5-32b", [
{"role": "user", "content": "分析这份标书..."}
])
---
b.Bun 示例
---
class NewAPIClient {
constructor(
private baseUrl: string,
private apiKey: string
) {}
async chat(model: string, messages: Array<{role: string, content: string}>) {
const response = await fetch(`${this.baseUrl}/chat/completions`, {
headers: { 'Authorization': `Bearer ${this.apiKey}` },
body: JSON.stringify({ model, messages })
});
const data = await response.json();
return data.choices[0].message.content;
}
}
// 使用
const client = new NewAPIClient('http://newapi:3000/v1', 'sk-key');
const result = await client.chat('qwen2.5-32b', [
{ role: 'user', content: '分析这份标书...' }
]);
---
c.对比
方面 Python Bun
代码量 ~30 行 ~25 行
可读性 优秀 优秀
类型安全 中等 高
错误处理 try/except try/catch
b.LangChain 集成
a.Python (LangChain)
---
from langchain_openai import ChatOpenAI
from langchain.schema import HumanMessage
# 初始化
llm = ChatOpenAI(
base_url="http://newapi:3000/v1",
api_key="sk-key",
model="qwen2.5-32b",
temperature=0
)
# 简单调用
message = HumanMessage(content="分析这份标书...")
response = llm.invoke([message])
print(response.content)
# Chain 调用
from langchain.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个评标专家"),
("user", "{input}")
])
chain = prompt | llm
result = chain.invoke({"input": "分析这份标书..."})
---
b.Bun (LangChain.js)
---
import { ChatOpenAI } from '@langchain/openai';
import { HumanMessage } from '@langchain/core/messages';
// 初始化
const llm = new ChatOpenAI({
configuration: {
baseURL: 'http://newapi:3000/v1',
apiKey: 'sk-key'
},
modelName: 'qwen2.5-32b',
temperature: 0
});
// 简单调用
const message = new HumanMessage('分析这份标书...');
const response = await llm.invoke([message]);
console.log(response.content);
// Chain 调用
import { ChatPromptTemplate } from '@langchain/core/prompts';
const prompt = ChatPromptTemplate.fromMessages([
['system', '你是一个评标专家'],
['user', '{input}']
]);
const chain = prompt.pipe(llm);
const result = await chain.invoke({ input: '分析这份标书...' });
---
c.对比
方面 Python LangChain Bun LangChain.js
API 稳定性 高 中等
文档质量 优秀 良好
社区活跃 非常活跃 活跃
功能完整度 100% ~80%
更新速度 快 快
c.Prompt 管理
a.Python 方案
---
# prompts.py
from jinja2 import Template
EVALUATION_PROMPT = Template("""
你是一个专业的评标专家。
# 招标要求
{{ requirements }}
# 标书内容
{{ tender_doc }}
# 任务
请逐条对比标书与招标要求的符合度，输出 JSON 格式结果。
""")
# 使用
from prompts import EVALUATION_PROMPT
prompt = EVALUATION_PROMPT.render(
requirements="...",
tender_doc="..."
)
---
b.Bun 方案
---
// prompts.ts
const EVALUATION_PROMPT = `
你是一个专业的评标专家。
# 招标要求
{{requirements}}
# 标书内容
{{tenderDoc}}
# 任务
请逐条对比标书与招标要求的符合度，输出 JSON 格式结果。
`;
// 使用
import { render } from 'eta';
const prompt = render(EVALUATION_PROMPT, {
requirements: '...',
tenderDoc: '...'
});
---
d.部署与运维对比
a.容器化部署
a.Python (Dockerfile)
---
FROM python:3.10-slim
WORKDIR /app
# 安装依赖
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 复制代码
COPY . .
# 启动
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]
---
b.镜像大小
基础镜像: ~100MB
依赖安装: ~500MB
总计: ~600MB
c.Bun (Dockerfile)
---
FROM oven/bun:1
WORKDIR /app
# 安装依赖
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile
# 复制代码
COPY . .
# 启动
CMD ["bun", "run", "index.ts"]
---
d.镜像大小
基础镜像: ~50MB
依赖安装: ~50MB
总计: ~100MB
e.对比
指标 Python Bun
镜像大小 ~600MB ~100MB
构建时间 ~2 分钟 ~30 秒
启动时间 ~5 秒 ~0.5 秒
内存占用 ~100MB ~20MB
b.性能测试
a.测试场景
调用模型 API 100 次
b.Python 结果
平均响应时间: 2.3 秒
P50 响应时间: 2.1 秒
P95 响应时间: 3.2 秒
P99 响应时间: 4.5 秒
内存占用: 85MB
CPU 使用: 15%
c.Bun 结果
平均响应时间: 2.1 秒
P50 响应时间: 1.9 秒
P95 响应时间: 2.8 秒
P99 响应时间: 3.9 秒
内存占用: 12MB
CPU 使用: 8%
d.结论
Bun 在内存占用和启动时间上有明显优势
e.开发体验对比
a.学习曲线
a.Python
阶段 时间 说明
基础语法 1 天 简单易学
FastAPI 2 天 文档完善
异步编程 3 天 asyncio 概念
LangChain 3 天 概念较多
总计 ~9 天 完全入门
b.Bun/TypeScript
阶段 时间 说明
TypeScript 基础 2 天 需要类型概念
Bun 运行时 1 天 与 Node.js 类似
Hono 框架 2 天 轻量级框架
异步编程 2 天 async/await
LangChain.js 3 天 与 Python 版本类似
总计 ~10 天 完全入门
b.调试体验
a.Python
---
# pdb 调试
import pdb; pdb.set_trace()
# VS Code 调试
# 配置 .vscode/launch.json
{
"type": "python",
"request": "launch",
"program": "${file}"
}
---
b.优势
成熟的工具链
丰富的调试器
详细的错误信息
c.Bun/TypeScript
---
// debugger 语句
debugger;
// VS Code 调试
// 配置 .vscode/launch.json
{
"type": "node",
"request": "launch",
"runtimeExecutable": "bun",
"program": "${file}"
}
---
d.优势
TypeScript 编译时错误检查
IDE 智能提示
源码映射支持
c.生态系统
a.Python AI 生态
| 库/框架 | 成熟度 | 文档 | 社区 |
|---------|--------|------|------|
| LangChain | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| LlamaIndex | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| OpenAI SDK | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| FastAPI | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
b.Bun/TypeScript AI 生态
| 库/框架 | 成熟度 | 文档 | 社区 |
|---------|--------|------|------|
| LangChain.js | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| OpenAI SDK | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Hono | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| AI SDK (Vercel) | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
f.场景适配建议
a.Python 更适合的场景
a.场景与理由
复杂 AI 应用 LangChain 生态成熟
数据处理密集 Pandas/NumPy 强大
企业级后端 FastAPI + SQLAlchemy 完善
团队熟悉 Python 学习成本低
需要快速原型 开发效率高
科学计算 Python 优势领域
b.Bun/TypeScript 更适合的场景
a.场景与理由
全栈统一 前后端统一语言
轻量级服务 Bun 性能优势明显
边缘计算 镜像小、启动快
团队熟悉 JS 学习成本低
实时应用 异步性能好
Serverless 冷启动快
c.评标工具场景分析
a.评标工具特点
├── 文档处理 (中等)
├── 数据分析 (中等)
├── AI 调用 (频繁)
├── 并发需求 (中等)
└── 长期运行 (是)
b.Python 优势
├── ✅ LangChain 生态完善
├── ✅ 文档处理库丰富
├── ✅ Pandas 数据分析
├── ✅ Celery 任务队列
└── ✅ 企业级部署经验多
c.Bun/TypeScript 优势
├── ✅ 部署更轻量
├── ✅ 性能更好
├── ✅ 开发体验好 (类型安全)
├── ✅ 成本可能更低
└── ⚠️ AI 生态相对较新
g.推荐方案
a.阶段化选择
a.阶段 1: 快速验证 (1-2 周)
---
推荐: Bun/TypeScript
理由:
├── 开发速度快
├── 部署简单
└── 快速迭代
---
b.阶段 2: 功能开发 (3-8 周)
---
推荐: Python + FastAPI
理由:
├── LangChain 生态成熟
├── 功能实现更容易
└── 团队更容易上手
---
c.阶段 3: 生产优化 (9 周后)
---
选项 A: 保持 Python
├── 成熟稳定
└── 社区支持好
选项 B: 部分迁移到 Bun
├── 轻量级服务用 Bun
└── 核心 AI 用 Python
---
b.混合方案
a.架构说明
---
混合架构:
├── 前端: Vue 3 (TypeScript)
├── 网关: Bun + Hono
│ ├── 路由、鉴权
│ ├── 限流、缓存
│ └── 轻量级 API
└── AI 服务: Python + FastAPI
├── LangChain 集成
├── 复杂业务逻辑
└── Celery 异步任务
---
b.优势
发挥各自优势
Bun 处理轻量级任务
Python 处理复杂 AI 逻辑
技术栈合理分层
03.智能体框架选择
a.框架概述
a.三种方案对比
┌─────────────────────────────────────────────────────────────┐
│ 三种方案复杂度对比 │
└─────────────────────────────────────────────────────────────┘
方案 1: 直接调用 (最简)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 用户 │───▶│ API │───▶│ NewAPI │───▶│ 模型 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│
└──▶ Prompt 模板
└──▶ 简单逻辑
└──▶ 直接响应
方案 2: LangChain (中等)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 用户 │───▶│ API │───▶│LangChain│───▶│ NewAPI │───▶│ 模型 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
│
├──▶ Chain 链式调用
├──▶ Memory 记忆
├──▶ Tool 工具
└──▶ Prompt 模板
方案 3: LangGraph (复杂)
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 用户 │───▶│ API │───▶│LangGraph│───▶│ Agent │───▶│ NewAPI │───▶│ 模型 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
│
├──▶ State 状态机
├──▶ Multi-Agent 多智能体
├──▶ 复杂决策
└──▶ 长期运行
b.复杂度对比
| 方面 | 直接调用 | LangChain | LangGraph |
|------|---------|----------|-----------|
| **代码量** | ~50 行 | ~150 行 | ~300+ 行 |
| **概念数** | 2 个 | 8 个 | 15+ 个 |
| **学习时间** | 1 天 | 3-5 天 | 7-10 天 |
| **调试难度** | 低 | 中等 | 高 |
| **灵活性** | 低 | 高 | 很高 |
| **可控性** | 高 | 中等 | 低 (黑盒) |
b.方案1: 直接调用
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ API 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 文档解析API │ │ 评标分析API │ │ 报告生成API │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 服务层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Prompt 管理 │ │ HTTP 客户端 │ │ 结果解析 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ NewAPI 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 模型路由 │ │ 负载均衡 │ │ 故障转移 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
b.Python 版本
# services/llm_service.py
import httpx
from typing import List, Dict
class LLMService:
"""直接调用模型的 LLM 服务"""
def __init__(self, base_url: str, api_key: str):
self.base_url = base_url
self.api_key = api_key
async def chat(self, model: str, messages: List[Dict]) -> str:
"""聊天接口"""
async with httpx.AsyncClient() as client:
response = await client.post(
f"{self.base_url}/chat/completions",
headers={"Authorization": f"Bearer {self.api_key}"},
json={
"model": model,
"messages": messages,
"temperature": 0
},
timeout=60.0
)
response.raise_for_status()
return response.json()["choices"][0]["message"]["content"]
async def analyze_document(self, doc_content: str) -> Dict:
"""分析文档"""
prompt = f"""
请分析以下标书文档，提取关键信息：
{doc_content}
请以 JSON 格式返回：
{{
"company_name": "公司名称",
"total_price": "总价",
"delivery_period": "交付周期",
"key_terms": ["关键条款1", "关键条款2"]
}}
"""
result = await self.chat(
"qwen2.5-32b",
[{"role": "user", "content": prompt}]
)
return json.loads(result)
# api/documents.py
from fastapi import APIRouter, Depends
from services.llm_service import LLMService
router = APIRouter()
@router.post("/analyze")
async def analyze_document(
doc_id: int,
llm: LLMService = Depends()
):
"""分析文档"""
# 1. 获取文档内容
doc_content = await get_document_content(doc_id)
# 2. 调用 LLM 分析
result = await llm.analyze_document(doc_content)
# 3. 返回结果
return result
c.Bun/TypeScript 版本
// services/llm.service.ts
class LLMService {
constructor(
private baseUrl: string,
private apiKey: string
) {}
async chat(model: string, messages: Array<{role: string, content: string}>): Promise<string> {
const response = await fetch(`${this.baseUrl}/chat/completions`, {
method: 'POST',
headers: {
'Authorization': `Bearer ${this.apiKey}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ model, messages, temperature: 0 })
});
const data = await response.json();
return data.choices[0].message.content;
}
async analyzeDocument(docContent: string): Promise<DocumentAnalysis> {
const prompt = `
请分析以下标书文档，提取关键信息：
${docContent}
请以 JSON 格式返回：
{
"company_name": "公司名称",
"total_price": "总价",
"delivery_period": "交付周期",
"key_terms": ["关键条款1", "关键条款2"]
}
`;
const result = await this.chat('qwen2.5-32b', [
{ role: 'user', content: prompt }
]);
return JSON.parse(result);
}
}
// api/documents.ts
import { Hono } from 'hono';
const app = new Hono();
app.post('/analyze', async (c) => {
const { docId } = await c.req.json();
const llm = new LLMService(c.env.BASE_URL, c.env.API_KEY);
// 1. 获取文档内容
const docContent = await getDocumentContent(docId);
// 2. 调用 LLM 分析
const result = await llm.analyzeDocument(docContent);
// 3. 返回结果
return c.json(result);
});
d.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **简单直接** | 代码量少，容易理解 |
| ✅ **完全可控** | 每个调用都明确 |
| ✅ **调试容易** | 问题定位简单 |
| ✅ **性能最优** | 无额外抽象层开销 |
| ✅ **学习成本低** | 无需学习框架 |
| ✅ **依赖少** | 只需要 HTTP 客户端 |
b.限制
| 限制 | 说明 | 影响 |
|------|------|------|
| ❌ **无记忆管理** | 需要自己实现上下文管理 | 多轮对话麻烦 |
| ❌ **无工具调用** | 需要自己实现 Function Call | 扩展能力受限 |
| ❌ **无流式输出** | 需要自己实现 SSE | 用户体验差 |
| ❌ **Prompt 管理弱** | 需要自己管理模板 | 维护成本高 |
e.适用场景
a.适合
✅ 单轮问答场景
✅ 简单信息提取
✅ 固定格式输出
✅ 快速原型验证
✅ 性能敏感场景
b.不适合
❌ 多轮对话
❌ 复杂推理链
❌ 需要工具调用
❌ 需要状态管理
c.方案2: LangChain
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ API 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 文档解析API │ │ 评标分析API │ │ 报告生成API │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ LangChain 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Chains │ │ Memory │ │ Tools │ │
│ │ (链式调用) │ │ (记忆管理) │ │ (工具调用) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ NewAPI 层 │
└─────────────────────────────────────────────────────────────┘
b.Chains (链)
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
# 1. 定义 Prompt
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个专业的评标专家"),
("user", "请分析以下标书：\n\n{input}")
])
# 2. 定义 LLM
llm = ChatOpenAI(
base_url="http://newapi:3000/v1",
model="qwen2.5-32b",
temperature=0
)
# 3. 定义 Chain
chain = prompt | llm | StrOutputParser()
# 4. 调用
result = await chain.ainvoke({"input": doc_content})
```
**Memory (记忆):**
```python
from langchain.memory import ConversationBufferMemory
from langchain.chains import ConversationChain
# 1. 定义 Memory
memory = ConversationBufferMemory(
return_messages=True,
memory_key="chat_history"
)
# 2. 创建对话链
conversation = ConversationChain(
llm=llm,
memory=memory,
verbose=True
)
# 3. 多轮对话
response1 = await conversation.apredict(
input="请分析这份标书的价格条款"
)
response2 = await conversation.apredict(
input="与其他供应商相比如何？" # 会记住前面的对话
)
c.Tools (工具调用)
from langchain.tools import tool
from langchain_core.utils.function_calling import convert_to_openai_function
# 1. 定义工具
@tool
def calculate_score(weights: dict, scores: dict) -> float:
"""计算加权评分"""
total = 0
for key, weight in weights.items():
total += weight * scores.get(key, 0)
return total
@tool
def search_database(query: str) -> list:
"""搜索历史评标数据"""
return db.search(query)
# 2. 绑定工具到 LLM
tools = [calculate_score, search_database]
llm_with_tools = llm.bind_functions(
[convert_to_openai_function(t) for t in tools]
)
# 3. 调用
result = await llm_with_tools.ainvoke(
"请根据权重 {weights} 和评分 {scores} 计算总分"
)
d.完整示例
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
from langchain.schema.runnable import RunnablePassthrough
# 1. 文档提取 Chain
extract_chain = (
ChatPromptTemplate.from_template("""
请从以下标书中提取关键信息：
{doc_content}
请以 JSON 格式返回：
{{
"supplier": "供应商名称",
"price": "总价",
"delivery": "交付周期"
}}
""")
| ChatOpenAI(model="qwen2.5-32b")
| StrOutputParser()
)
# 2. 符合度分析 Chain
compliance_chain = (
ChatPromptTemplate.from_template("""
招标要求：
{requirements}
标书承诺：
{tender_content}
请逐条分析符合度，输出 JSON 格式结果。
""")
| ChatOpenAI(model="qwen2.5-32b")
| StrOutputParser()
)
# 3. 组合 Chain
evaluation_chain = {
"doc_content": RunnablePassthrough(),
"extracted": extract_chain,
} | {
"requirements": lambda x: x["requirements"],
"tender_content": lambda x: x["doc_content"],
"extracted_info": lambda x: x["extracted"],
} | {
"compliance": compliance_chain,
"extracted": lambda x: x["extracted_info"],
}
# 4. 调用
result = await evaluation_chain.ainvoke({
"doc_content": tender_doc,
"requirements": requirements
})
e.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **功能丰富** | Memory、Tools、Retrieval 等 |
| ✅ **生态完善** | 大量集成和扩展 |
| ✅ **可组合性** | Chain 可以灵活组合 |
| ✅ **流式输出** | 原生支持流式响应 |
| ✅ **模板管理** | PromptTemplate 管理方便 |
b.限制
| 限制 | 说明 | 影响 |
|------|------|------|
| ❌ **学习曲线陡** | 概念多，API 变化快 | 学习成本高 |
| ❌ **抽象层厚** | 性能有损耗 | 调试困难 |
| ❌ **版本迭代快** | API 经常变化 | 代码维护成本高 |
| ❌ **过度设计** | 简单场景也复杂 | 增加复杂度 |
f.适用场景
a.适合
✅ 多轮对话场景
✅ 需要工具调用
✅ 需要 RAG (检索增强)
✅ 复杂的推理链
✅ 需要流式输出
b.不适合
❌ 简单单次调用
❌ 性能极度敏感
❌ 需要完全可控
❌ 快速原型 (学习成本高)
d.方案3：LangGraph
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ API 层 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ LangGraph 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ State │ │ Nodes │ │ Edges │ │
│ │ (状态机) │ │ (节点) │ │ (边/路由) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Agent 智能体 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 研究员 │ │ 分析员 │ │ 评审员 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ NewAPI 层 │
└─────────────────────────────────────────────────────────────┘
b.评标工作流状态机
from langgraph.graph import StateGraph, END
from typing import TypedDict
# 1. 定义状态
class EvaluationState(TypedDict):
documents: list[str]
requirements: str
extracted_info: dict
compliance_result: dict
price_comparison: dict
final_report: str
current_step: str
# 2. 定义节点
async def extract_node(state: EvaluationState):
"""提取节点"""
# 提取各标书信息
extracted = await extract_info(state["documents"])
return {"extracted_info": extracted, "current_step": "extracted"}
async def compliance_node(state: EvaluationState):
"""符合度检查节点"""
# 检查符合度
result = await check_compliance(
state["requirements"],
state["extracted_info"]
)
return {"compliance_result": result, "current_step": "compliance"}
async def price_node(state: EvaluationState):
"""价格对比节点"""
# 对比价格
comparison = await compare_prices(state["extracted_info"])
return {"price_comparison": comparison, "current_step": "price"}
async def report_node(state: EvaluationState):
"""生成报告节点"""
# 生成最终报告
report = await generate_report({
"extracted": state["extracted_info"],
"compliance": state["compliance_result"],
"price": state["price_comparison"]
})
return {"final_report": report, "current_step": "completed"}
# 3. 定义路由
def should_check_compliance(state: EvaluationState) -> str:
"""决定是否进行符合度检查"""
if state.get("price_comparison"):
return "generate_report"
return "check_compliance"
# 4. 构建图
workflow = StateGraph(EvaluationState)
workflow.add_node("extract", extract_node)
workflow.add_node("compliance", compliance_node)
workflow.add_node("price", price_node)
workflow.add_node("generate_report", report_node)
workflow.set_entry_point("extract")
workflow.add_conditional_edges(
"extract",
should_check_compliance,
{
"check_compliance": "compliance",
"generate_report": "generate_report"
}
)
workflow.add_edge("compliance", "price")
workflow.add_edge("price", "generate_report")
workflow.add_edge("generate_report", END)
# 5. 编译和运行
app = workflow.compile()
result = await app.ainvoke({
"documents": [doc1, doc2, doc3],
"requirements": reqs,
"current_step": "start"
})
c.评标多智能体系统
from langgraph.prebuilt import create_react_agent
from langchain.tools import tool
# 1. 研究员智能体 (提取信息)
researcher_agent = create_react_agent(
model=ChatOpenAI(model="qwen2.5-32b"),
tools=[search_database, extract_info],
state_modifier="你是信息提取专家，负责从标书中提取关键信息"
)
# 2. 分析员智能体 (符合度分析)
analyst_agent = create_react_agent(
model=ChatOpenAI(model="qwen2.5-32b"),
tools=[calculate_score, compare_data],
state_modifier="你是分析专家，负责分析标书符合度"
)
# 3. 评审员智能体 (生成报告)
reviewer_agent = create_react_agent(
model=ChatOpenAI(model="qwen2.5-72b"),
tools=[generate_report],
state_modifier="你是评审专家，负责生成最终评标报告"
)
# 4. 构建多智能体工作流
async def multi_agent_evaluation(documents: list, requirements: str):
# Step 1: 研究员提取信息
extracted = await researcher_agent.ainvoke({
"input": f"提取以下标书的信息：{documents}"
})
# Step 2: 分析员分析符合度
analysis = await analyst_agent.ainvoke({
"input": f"分析符合度。要求：{requirements}，标书信息：{extracted}"
})
# Step 3: 评审员生成报告
report = await reviewer_agent.ainvoke({
"input": f"生成评标报告。分析结果：{analysis}"
})
return report
d.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **状态管理强** | 完整的状态机支持 |
| ✅ **可视化** | 可以查看执行流程 |
| ✅ **多智能体** | 支持复杂的多智能体协作 |
| ✅ **可恢复** | 支持中断和恢复 |
| ✅ **灵活路由** | 条件分支和循环 |
b.限制
| 限制 | 说明 | 影响 |
|------|------|------|
| ❌ **学习成本极高** | 需要理解状态机、图等概念 | 入门门槛高 |
| ❌ **复杂度高** | 代码量多，调试困难 | 维护成本高 |
| ❌ **性能开销** | 多层抽象 | 响应慢 |
| ❌ **生态较新** | 文档和示例相对少 | 遇到问题难解决 |
e.适用场景
a.适合
✅ 复杂的决策流程
✅ 需要多智能体协作
✅ 长期运行的任务
✅ 需要状态管理
✅ 需要可视化的工作流
b.不适合
❌ 简单的问答场景
❌ 快速原型开发
❌ 性能敏感场景
❌ 团队对图编程不熟悉
e.方案对比总结
a.决策树
开始
│
▼
┌─────────────────┐
│ 是否需要多轮对话？│
└────────┬────────┘
│
┌──────────┴──────────┐
│ 否 │ 是
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ 是否需要工具 │ │ 是否需要复杂流程？│
│ 调用？ │ └────────┬─────────┘
└──────┬───────┘ │
│ ┌───────┴───────┐
┌────┴────┐ │ 是 │ 否
│ 否 │ 是 ▼ ▼
▼ ▼ ┌──────────┐ ┌──────────┐
┌─────────┐ ┌─────┤LangGraph │ │LangChain │
│直接调用 │ │ └──────────┘ └──────────┘
└─────────┘ │
└─▶ LangChain
b.对比矩阵
| 评估维度 | 直接调用 | LangChain | LangGraph |
|---------|---------|----------|-----------|
| **复杂度** | ⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **学习曲线** | 平缓 | 陡峭 | 极陡 |
| **开发速度** | 快 | 中等 | 慢 |
| **性能** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **灵活性** | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **可控性** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **可维护性** | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| **调试难度** | 低 | 中等 | 高 |
| **代码量** | 少 (~50 行) | 中 (~150 行) | 多 (~300+ 行) |
| **依赖** | 最少 | 中等 | 多 |
c.评标工具场景分析
评标工具功能分解:
├── 文档解析
│ └── 单次调用，固定格式输出
│ └── 推荐: 直接调用
│
├── 规则配置
│ └── 简单 CRUD，无需 LLM
│ └── 推荐: 不用框架
│
├── 智能评标
│ ├── 标书比对
│ │ └── 多步推理
│ │ └── 推荐: LangChain (可选)
│ │
│ ├── 符合度检查
│ │ └── 单次调用，固定输出
│ │ └── 推荐: 直接调用
│ │
│ └── 价格分析
│ └── 计算为主 + 简单分析
│ └── 推荐: 直接调用
│
└── 报告生成
└── 单次调用，固定格式
└── 推荐: 直接调用
f.推荐方案
a.分阶段推荐
a.阶段 1: MVP (最小可行产品)
方案: 直接调用
理由:
├── 快速验证核心功能
├── 代码简单易维护
└── 性能最优
覆盖功能:
├── ✅ 文档解析
├── ✅ 符合度检查
├── ✅ 价格分析
└── ✅ 报告生成
b.阶段 2: 功能增强
方案: 直接调用 + 部分 LangChain
理由:
├── 核心功能保持简单
├── 复杂场景使用 LangChain
└── 渐进式增强
LangChain 应用场景:
├── 需要多轮对话的辅助分析
├── 需要工具调用的复杂计算
└── 需要记忆管理的交互场景
c.阶段 3: 高级功能 (如需要)
方案: LangGraph
理由:
├── 复杂的多智能体协作
├── 长期运行的评标流程
└── 需要状态管理
应用场景:
├── 复杂的决策流程
├── 多专家协作评标
└── 需要可视化的工作流
b.最终建议
a.对于评标工具项目
| 功能模块 | 推荐方案 | 理由 |
|---------|---------|------|
| **文档解析** | 直接调用 | 单次调用，简单明了 |
| **规则管理** | 不用 LLM | 传统 CRUD |
| **符合度检查** | 直接调用 | 固定输入输出 |
| **价格分析** | 直接调用 | 计算为主 |
| **辅助分析** | LangChain (可选) | 需要多轮对话时 |
| **报告生成** | 直接调用 | 模板 + LLM |
| **多智能体** | LangGraph (未来) | 复杂场景预留 |
b.实施路径
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 直接调用 │───▶│LangChain │───▶│LangGraph │
│ (MVP) │ │ (增强) │ │ (高级) │
└──────────┘ └──────────┘ └──────────┘
1-2 周 3-8 周 9 周+
04.架构方案对比
a.架构方案总览
a.方案分类
┌─────────────────────────────────────────────────────────────┐
│ 四种架构方案 │
└─────────────────────────────────────────────────────────────┘
方案 A: 纯云端 API 方案
├── 模型: 全部使用硅基流动等云端 API
├── 部署: 无需 GPU，普通云服务器
└── 成本: 按量付费，无硬件投入
方案 B: 混合方案 (云端 + 本地 OCR)
├── 模型: 文本用云端，OCR 用本地
├── 部署: CPU 服务器即可
└── 成本: 中等
方案 C: 本地模型方案 (Ollama)
├── 模型: 全部使用 Ollama 本地部署
├── 部署: 需要 GPU 服务器
└── 成本: 硬件投入，无 API 费用
方案 D: 昇腾 NPU 方案 (私有化)
├── 模型: 全部使用昇腾 NPU 部署
├── 部署: 需要昇腾 NPU 服务器
└── 成本: 高硬件投入，完全私有
b.方案对比矩阵
| 对比维度 | 方案 A (云端) | 方案 B (混合) | 方案 C (Ollama) | 方案 D (昇腾) |
|---------|-------------|-------------|----------------|-------------|
| **初始成本** | ⭐ (低) | ⭐⭐ (中低) | ⭐⭐⭐ (中高) | ⭐⭐⭐⭐⭐ (高) |
| **运营成本** | ⭐⭐⭐⭐ (高) | ⭐⭐⭐ (中) | ⭐ (低) | ⭐ (低) |
| **数据隐私** | ⭐⭐ (中) | ⭐⭐⭐ (中高) | ⭐⭐⭐⭐⭐ (高) | ⭐⭐⭐⭐⭐ (最高) |
| **部署复杂度** | ⭐ (简单) | ⭐⭐ (较简) | ⭐⭐⭐⭐ (复杂) | ⭐⭐⭐⭐⭐ (最复) |
| **维护成本** | ⭐ (低) | ⭐⭐ (中低) | ⭐⭐⭐⭐ (高) | ⭐⭐⭐⭐⭐ (最高) |
| **性能** | ⭐⭐⭐⭐ (高) | ⭐⭐⭐ (中) | ⭐⭐ (中低) | ⭐⭐⭐⭐⭐ (可控) |
| **可扩展性** | ⭐⭐⭐⭐⭐ (最高) | ⭐⭐⭐⭐ (高) | ⭐⭐ (中低) | ⭐⭐⭐ (中) |
| **合规性** | ⭐⭐ (中) | ⭐⭐⭐ (中高) | ⭐⭐⭐⭐ (高) | ⭐⭐⭐⭐⭐ (最高) |
b.方案A: 纯云端 API 方案
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ 纯云端 API 架构 │
└─────────────────────────────────────────────────────────────┘
用户
│
▼
┌────────────────┐
│ 前端 (Vue 3) │
└────────┬───────┘
│ HTTPS
▼
┌────────────────┐
│ 后端 API │
│ (Python/Bun) │
└────────┬───────┘
│ HTTP
▼
┌────────────────┐
│ NewAPI │
│ (模型网关) │
└────────┬───────┘
│ HTTPS
▼
┌─────────────────────────────────────────┐
│ 云端模型 API │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │硅基流动 │ │ 通义千问 │ │ 其他 │ │
│ │ Qwen2.5 │ │ API │ │ API │ │
│ └──────────┘ └──────────┘ └────────┘ │
└─────────────────────────────────────────┘
b.技术栈
a.Python + FastAPI
核心依赖:
├── FastAPI (Web 框架)
├── httpx (HTTP 客户端)
├── Pydantic (数据验证)
└── SQLAlchemy (ORM)
AI 调用:
├── OpenAI SDK (兼容 API)
└── 自定义 Prompt 管理
b.Bun + Hono
核心依赖:
├── Bun (运行时)
├── Hono (Web 框架)
├── Zod (数据验证)
└── Drizzle ORM (可选)
AI 调用:
├── OpenAI SDK (兼容 API)
└── 自定义 Prompt 管理
c.成本分析
a.模型调用成本 (硅基流动)
| 使用量 | Qwen2.5-7B | Qwen2.5-32B | Qwen2-VL-7B | 月成本估算 |
|--------|-----------|------------|-------------|-----------|
| 小规模 | 50K tokens | 200K tokens | 50K tokens | ¥50-100 |
| (10 份/月) | ¥2.5 | ¥40 | ¥30 | |
| 中规模 | 250K tokens | 1M tokens | 250K tokens | ¥250-500 |
| (50 份/月) | ¥12.5 | ¥200 | ¥150 | |
| 大规模 | 500K tokens | 2M tokens | 500K tokens | ¥500-1000 |
| (100 份/月) | ¥25 | ¥400 | ¥300 | |
b.服务器成本
| 配置 | 云服务商 | 月成本 |
|------|---------|--------|
| 2核4GB | 阿里云/腾讯云 | ¥100-200 |
| 4核8GB | 阿里云/腾讯云 | ¥200-400 |
| 8核16GB | 阿里云/腾讯云 | ¥400-800 |
c.总成本 (月)
| 规模 | API 成本 | 服务器成本 | 总计 |
|------|---------|-----------|------|
| 小规模 | ¥50-100 | ¥100-200 | **¥150-300** |
| 中规模 | ¥250-500 | ¥200-400 | **¥450-900** |
| 大规模 | ¥500-1000 | ¥400-800 | **¥900-1800** |
d.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **零硬件投入** | 无需 GPU，普通云服务器即可 |
| ✅ **快速上线** | 部署简单，1-2 天可上线 |
| ✅ **按量付费** | 用多少付多少，灵活控制 |
| ✅ **自动扩展** | 云端 API 自动扩展 |
| ✅ **免维护** | 无需维护模型服务 |
| ✅ **最新模型** | 自动使用最新模型版本 |
b.限制
| 限制 | 说明 | 影响 |
|------|------|------|
| ❌ **数据出域** | 标书内容发送到第三方 | 隐私风险 |
| ❌ **成本不可控** | 按量付费，量大成本高 | 预算风险 |
| ❌ **网络依赖** | 需要稳定网络连接 | 可用性风险 |
| ❌ **合规问题** | 数据出境可能不合规 | 法律风险 |
| ❌ **延迟较高** | 云端调用延迟 | 用户体验 |
e.适用场景
a.适合
✅ 预算有限，无法承担硬件投入
✅ 标书内容不敏感
✅ 使用量不大且可预测
✅ 快速验证和原型开发
✅ 团队技术能力有限
b.不适合
❌ 标书内容敏感或机密
❌ 使用量很大
❌ 对数据隐私要求极高
❌ 需要通过等级保护
❌ 完全内网环境
c.方案B: 混合方案
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ 混合架构设计 │
└─────────────────────────────────────────────────────────────┘
用户
│
▼
┌────────────────┐
│ 前端 (Vue 3) │
└────────┬───────┘
│ HTTPS
▼
┌────────────────┐
│ 后端 API │
│ (Python/Bun) │
└────────┬───────┘
│
┌────┴────┐
│ │
▼ ▼
┌─────────┐ ┌──────────┐
│ 本地 │ │ NewAPI │
│ OCR │ │ (网关) │
└─────────┘ └────┬─────┘
│ HTTP
▼
┌──────────────────────┐
│ 云端文本模型 │
│ (硅基流动 Qwen2.5) │
└──────────────────────┘
b.本地 OCR 部署
a.dockerfile
FROM python:3.10-slim
WORKDIR /app
# 安装 PaddleOCR
RUN pip install paddlepaddle paddleocr
# API 服务
COPY ocr_service.py .
EXPOSE 8080
CMD ["python", "ocr_service.py"]
b.python
# ocr_service.py
from fastapi import FastAPI, UploadFile
from paddleocr import PaddleOCR
import io
from PIL import Image
app = FastAPI()
ocr = PaddleOCR(use_angle_cls=True, lang='ch')
@app.post("/ocr")
async def ocr_endpoint(file: UploadFile):
"""OCR 接口"""
contents = await file.read()
image = Image.open(io.BytesIO(contents))
result = ocr.ocr(np.array(image), cls=True)
text = '\n'.join([line[1][0] for line in result[0]])
return {"text": text}
c.调用逻辑
# services/evaluation_service.py
class EvaluationService:
def __init__(self):
self.local_ocr_url = "http://localhost:8080"
self.newapi_url = "http://newapi:3000/v1"
async def parse_document(self, file: UploadFile):
"""解析文档 - 混合调用"""
# 1. 本地 OCR (图片文档)
if file.content_type in ['image/jpeg', 'image/png']:
text = await self._local_ocr(file)
else:
# PDF/Word 用云端 VL 模型
text = await self._cloud_vl_parse(file)
# 2. 云端文本分析
analysis = await self._cloud_text_analysis(text)
return analysis
async def _local_ocr(self, file: UploadFile) -> str:
"""本地 OCR"""
async with httpx.AsyncClient() as client:
files = {"file": await file.read()}
response = await client.post(
f"{self.local_ocr_url}/ocr",
files=files
)
return response.json()["text"]
async def _cloud_text_analysis(self, text: str) -> dict:
"""云端文本分析"""
async with httpx.AsyncClient() as client:
response = await client.post(
f"{self.newapi_url}/chat/completions",
json={
"model": "qwen2.5-32b",
"messages": [
{"role": "user", "content": f"分析以下文本:\n{text}"}
]
}
)
return response.json()
d.成本分析
a.成本结构
| 项目 | 小规模 | 中规模 | 大规模 |
|------|--------|--------|--------|
| **服务器** | ¥200-400 | ¥400-800 | ¥800-1600 |
| **OCR (本地)** | ¥0 | ¥0 | ¥0 |
| **文本 API** | ¥30-60 | ¥150-300 | ¥300-600 |
| **总计 (月)** | **¥230-460** | **¥550-1100** | **¥1100-2200** |
b.与纯云端对比
节省 OCR 成本: 约 30-40%
增加服务器成本: 约 ¥100-200
总体节省: 约 20-30%
e.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **成本优化** | OCR 本地化，节省 30%+ |
| ✅ **部分隐私** | OCR 不出本地 |
| ✅ **灵活性** | 可调整本地/云端比例 |
| ✅ **可控性** | 关键环节可控 |
b.限制
| 限制 | 说明 |
|------|------|
| ⚠️ **部分数据出域** | 文本内容仍需云端分析 |
| ⚠️ **维护增加** | 需要维护 OCR 服务 |
| ⚠️ **复杂度提升** | 架构更复杂 |
| ----------------- | ---------- |
d.方案C: 本地模型方案 (Ollama)
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ 本地模型架构 │
└─────────────────────────────────────────────────────────────┘
用户
│
▼
┌────────────────┐
│ 前端 (Vue 3) │
└────────┬───────┘
│ HTTPS
▼
┌────────────────┐
│ 后端 API │
│ (Python/Bun) │
└────────┬───────┘
│ HTTP
▼
┌────────────────┐
│ NewAPI │
│ (模型网关) │
└────────┬───────┘
│ HTTP
▼
┌─────────────────────────────────────────┐
│ Ollama 本地模型 │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │Qwen2.5 │ │Qwen2-VL │ │ Paddle │ │
│ │ :14b │ │ :7b │ │ OCR │ │
│ └──────────┘ └──────────┘ └────────┘ │
│ │
│ GPU: RTX 4090 (24GB) │
│ 或 2x RTX 3090 (48GB) │
└─────────────────────────────────────────┘
b.硬件需求
a.GPU 配置
| 配置 | 显存 | 可运行模型 | 成本 | 性能 |
|------|------|-----------|------|------|
| RTX 4090 | 24GB | Qwen2.5-14B + VL-7B | ¥15,000 | ⭐⭐⭐⭐ |
| 2x RTX 4090 | 48GB | Qwen2.5-32B + VL-7B | ¥30,000 | ⭐⭐⭐⭐⭐ |
| A100 40GB | 40GB | Qwen2.5-32B + VL-7B | ¥60,000 | ⭐⭐⭐⭐⭐ |
b.服务器配置
| 组件 | 推荐 |
|------|------|
| CPU | 16核+ |
| 内存 | 128GB+ |
| 存储 | 2TB NVMe SSD |
| 网络 | 千兆 |
c.部署示例
a.Ollama 部署
# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 拉取模型
ollama pull qwen2.5:14b
ollama pull qwen2-vl:7b
# 启动服务
ollama serve
# 测试
curl http://localhost:11434/api/generate -d '{
"model": "qwen2.5:14b",
"prompt": "你好"
}'
b.NewAPI 配置
{
"name": "Ollama 本地",
"type": 1,
"base_url": "http://localhost:11434/v1",
"key": "ollama",
"models": "qwen2.5:14b,qwen2-vl:7b"
}
d.成本分析
a.硬件投入
| 配置 | 硬件成本 | 电费/月 | 3 年总成本 |
|------|---------|---------|-----------|
| RTX 4090 单卡 | ¥15,000 | ¥150 | ¥20,400 |
| 2x RTX 4090 | ¥30,000 | ¥300 | ¥40,800 |
b.运营成本
| 项目 | 月成本 |
|------|--------|
| 服务器托管 | ¥200-500 |
| 电费 | ¥150-300 |
| 维护 | ¥100-200 |
| API 费用 | ¥0 |
| **总计** | **¥450-1000/月** |
c.对比云端
| 时间 | 云端方案 | 本地方案 | 节省 |
|------|---------|---------|------|
| 第 1 年 | ¥5,400-18,000 | ¥20,400+ | ❌ 负 |
| 第 2 年 | ¥10,800-36,000 | ¥20,700+ | ✅ 正 |
| 第 3 年 | ¥16,200-54,000 | ¥21,000+ | ✅ 显著 |
e.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **数据隐私** | 完全本地，不出域 |
| ✅ **成本固定** | 硬件一次投入，无 API 费用 |
| ✅ **长期划算** | 2 年后回本 |
| ✅ **可控性** | 完全自主可控 |
| ✅ **无网络依赖** | 内网可用 |
b.限制
| 限制 | 说明 |
|------|------|
| ❌ **初始投入高** | 硬件成本 1.5-6 万 |
| ❌ **需要运维** | 需要技术团队维护 |
| ❌ **性能有限** | 受限于硬件 |
| ❌ **更新麻烦** | 模型更新需要手动操作 |
| ❌ **扩展受限** | 单机扩展能力有限 |
e.方案D：昇腾 NPU 方案
a.架构设计
┌─────────────────────────────────────────────────────────────┐
│ 昇腾 NPU 私有化架构 │
└─────────────────────────────────────────────────────────────┘
用户
│
▼
┌────────────────┐
│ 前端 (Vue 3) │
└────────┬───────┘
│ HTTPS
▼
┌────────────────┐
│ 后端 API │
│ (FastAPI) │
└────────┬───────┘
│ HTTP
▼
┌────────────────┐
│ NewAPI │
│ (模型网关) │
└────────┬───────┘
│
▼
┌─────────────────────────────────────────┐
│ 昇腾 NPU 推理集群 │
│ ┌──────────────────────────────────┐ │
│ │ 昇腾 910B x 4 卡 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────────┐ │ │
│ │ │Qwen2.5 │ │ Qwen2.5-VL │ │ │
│ │ │ :72B │ │ :32B │ │ │
│ │ │ (2x TP) │ │ (1x/2x) │ │ │
│ │ └──────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────────┐ │ │
│ │ │Qwen2-VL │ │ PaddleOCR │ │ │
│ │ │ :7B │ │ (NPU) │ │ │
│ │ └──────────┘ └──────────────┘ │ │
│ └──────────────────────────────────┘ │
│ │
│ 推理引擎: MindSpeed / MindIE │
└─────────────────────────────────────────┘
b.硬件需求
| 配置项 | 推荐值 | 成本估算 |
|--------|--------|---------|
| **NPU** | 昇腾 910B x 4 卡 | ¥80,000-120,000 |
| **CPU** | 64核+ | 包含在上 |
| **内存** | 512GB-1TB | 包含在上 |
| **存储** | 10TB SSD | ¥5,000-10,000 |
| **网络** | 25GbE | 包含在上 |
| **服务器** | 2U 机架式 | ¥10,000-20,000 |
| **总计** | - | **¥100,000-150,000** |
c.软件栈
软件栈:
├── 驱动层
│ ├── 昇腾 CANN (驱动 + 运行时)
│ └── torch-npu (PyTorch 适配)
│
├── 推理层
│ ├── MindSpeed (推理加速)
│ └── MindIE (推理引擎)
│
├── 模型层
│ ├── Qwen2.5-72B (2x TP)
│ ├── Qwen2.5-VL-32B
│ ├── Qwen2-VL-7B
│ └── PaddleOCR (NPU 版)
│
└── 应用层
├── FastAPI (后端)
├── Vue 3 (前端)
└── NewAPI (网关)
d.成本分析
a.投入成本
| 项目 | 成本 | 说明 |
|------|------|------|
| **硬件投入** | ¥100,000-150,000 | 一次性 |
| **电费/月** | ¥500-800 | 24小时运行 |
| **托管费/月** | ¥1,000-2,000 | 机柜托管 |
| **维护/月** | ¥2,000-5,000 | 人工维护 |
| **更新/年** | ¥10,000-20,000 | 模型更新 |
| **API 费用** | ¥0 | 完全免费 |
| **月运营成本** | **¥3,500-7,800** | - |
| **3 年总成本** | **¥226,000-280,000** | - |
b.对比云端 (大规模使用)
| 时间 | 云端方案 | 昇腾方案 | 节省 |
|------|---------|---------|------|
| 第 1 年 | ¥10,800-54,000 | ¥142,000-243,600 | ❌ 负 |
| 第 2 年 | ¥21,600-108,000 | ¥146,000-251,400 | ❌ 负 |
| 第 3 年 | ¥32,400-162,000 | ¥149,600-259,200 | ⚠️ 持平 |
| 第 4 年 | ¥43,200-216,000 | ¥153,200-267,000 | ✅ 正 |
| 第 5 年 | ¥54,000-270,000 | ¥156,800-274,800 | ✅ 显著 |
e.优势与限制
a.优势
| 优势 | 说明 |
|------|------|
| ✅ **最高隐私** | 完全私有化 |
| ✅ **最强合规** | 符合最高安全要求 |
| ✅ **长期成本优** | 大规模使用长期划算 |
| ✅ **可控性最高** | 完全自主可控 |
| ✅ **性能可调** | 可根据需求调整模型规模 |
| ✅ **无网络限制** | 完全内网 |
b.限制
| 限制 | 说明 |
|------|------|
| ❌ **初始投入极高** | 10-15 万起步 |
| ❌ **技术门槛高** | 需要专业团队 |
| ❌ **维护成本高** | 需要专职运维 |
| ❌ **扩展成本高** | 扩容需要再买硬件 |
| ❌ **更新复杂** | 模型更新技术复杂 |
| ❌ **回本周期长** | 需要 4 年+ |
5.3 [2]技术选型
00.项目总览
a.项目背景
a.企业采购评标痛点
a.说明
在企业采购过程中，评标环节通常面临以下挑战：
效率问题：
准确性问题：
管理问题：
数据问题：
b.手工阅读大量标书文档（PDF、Word、图片等）
c.人工对比各供应商的条款、价格、技术参数
d.重复性工作多，耗时耗力
e.人工评审容易出现疏漏
f.标准不统一，主观性强
g.难以保证评标结果的客观公正
h.评标过程不透明
i.评标记录难以追溯
j.合规性风险高
k.历史评标数据难以利用
l.缺乏数据分析支持决策
m.评标经验难以沉淀
b.项目目标
a.说明
本项目旨在构建一个基于昇腾 NPU 的私有化部署评标工具，通过 AI 技术解决传统评标过程中的痛点：
核心目标：
b.表格数据
目标维度 具体目标
效率提升 自动化文档解析、智能比对，评标时间缩短 70%+
准确性提升 AI 辅助评分，标准统一，减少人为疏漏
透明度提升 全流程记录，可追溯，可审计
数据价值 沉淀评标数据，支持持续优化
c.项目价值
a.说明
业务价值：
技术价值：
b.提高评标效率，降低人力成本
c.提升评标质量，降低采购风险
d.增强评标透明度，降低合规风险
e.探索昇腾 NPU 在企业场景的应用
f.积累多模态 AI 在垂直领域的实践经验
g.构建可复用的 AI 评标能力
d.适用范围
a.说明
适用场景：
不适用场景：
---
b.企业物资采购评标
c.服务采购评标
d.工程采购评标
e.涉及国家秘密的采购
f.特殊行业的专用采购（如军工、航空航天）
b.核心功能概述
a.文档智能解析
a.说明
功能描述：
支持多种格式的标书文档上传和智能解析：
b.表格数据
文档类型 支持格式 解析能力
PDF 文档 .pdf 文字提取、表格识别、图片提取
Word 文档 .docx 文字提取、表格识别、样式保留
图片文档 .jpg/.png/.tiff OCR 文字识别、表格识别
c.说明
技术方案：
d.OCR 引擎：PaddleOCR（昇腾适配）
e.表格识别：PaddleStructure
f.文档理解：Qwen2.5-VL-32B（多模态模型）
b.评标规则配置
a.说明
功能描述：
灵活配置评标规则，支持自定义评分项和权重：
配置项：
技术方案：
b.评分项设置（商务、技术、价格等）
c.权重配置（各项权重分配）
d.评分标准（每个评分项的评分细则）
e.自动评分规则（可量化的指标）
f.规则引擎：自定义规则解析
g.权重计算：加权平均算法
h.规则存储：结构化数据库
c.智能评标分析
a.说明
功能描述：
基于 AI 模型进行智能评标分析：
核心能力：
b.表格数据
能力 说明
标书自动比对 多份标书自动对比，找出差异点
条款符合度分析 检查标书条款与招标要求的符合度
价格比对分析 自动提取价格信息，进行横向对比
技术参数评分 根据技术参数自动评分
c.说明
技术方案：
d.文本理解：Qwen2.5-72B-Instruct
e.多模态理解：Qwen2.5-VL-32B
f.图像理解：Qwen2-VL-7B
g.模型网关：NewAPI
d.评标报告生成
a.说明
功能描述：
自动生成专业的评标报告：
报告内容：
报告格式：
技术方案：
---
b.评标概况（参与供应商、评标时间、评标专家）
c.各项评分明细
d.综合评分结果
e.推荐建议
f.评标过程记录
g.PDF 导出
h.Word 导出
i.在线预览
j.报告模板引擎
k.数据汇总引擎
l.文档生成引擎
c.技术架构总览
a.整体架构图
a.代码示例
---
┌─────────────────────────────────────────┐
│ 评标工具 Web 界面 │
│ (Vue 3 + Element Plus + TypeScript) │
│ │
│ • 文档上传 │
│ • 规则配置 │
│ • 评标结果展示 │
│ • 报告生成 │
└──────────────┬──────────────────────────┘
│ HTTP/WebSocket
┌──────────────▼──────────────────────────┐
│ 后端 API 服务 │
│ (FastAPI + Python + Celery 任务队列) │
│ │
│ • 文档管理 API │
│ • 评标规则 API │
│ • 智能评标 API │
│ • 报告生成 API │
└──────────────┬──────────────────────────┘
│
┌──────────────▼──────────────────────────┐
│ NewAPI 网关 │
│ (统一模型管理 + 路由 + 负载均衡) │
│ │
│ • 模型管理 │
│ • 请求路由 │
│ • 负载均衡 │
│ • 监控统计 │
└──────────────┬──────────────────────────┘
│
┌──────────────▼──────────────────────────┐
│ 昇腾 NPU 推理集群 │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Qwen2.5-72B (文本理解) │ │
│ │ Qwen2.5-VL-32B (多模态文档) │ │
│ │ Qwen2-VL-7B (图像理解) │ │
│ │ PaddleOCR (OCR识别) │ │
│ └─────────────────────────────────┘ │
│ │
│ 推理引擎：昇腾 MindSpeed / MindIE │
└─────────────────────────────────────────┘
---
b.技术栈总览
a.说明
前端技术栈：
后端技术栈：
AI 模型技术栈：
模型管理技术栈：
部署技术栈：
b.Vue 3（Composition API）
c.TypeScript
d.Element Plus（UI 组件库）
e.Pinia（状态管理）
f.Vue Router（路由管理）
g.Python 3.10+
h.FastAPI（Web 框架）
i.Celery（异步任务队列）
j.Redis（缓存）
k.PostgreSQL/MySQL（数据库）
l.Qwen2.5-72B-Instruct（文本理解）
m.Qwen2.5-VL-32B（多模态文档理解）
n.Qwen2-VL-7B（图像理解）
o.PaddleOCR（OCR 识别）
p.NewAPI（模型网关）
q.昇腾 MindSpeed（推理引擎）
r.昇腾 MindIE（推理优化）
s.Docker（容器化）
t.Docker Compose（编排）
u.Nginx（反向代理）
c.核心技术亮点
a.说明
1.全栈昇腾 NPU 适配
2.多模态 AI 能力
3.统一模型网关
4.高可用架构
---
b.所有 AI 模型均基于昇腾 NPU 优化
c.完全私有化部署，数据不出本地
d.文档理解：支持 PDF、Word、图片
e.表格理解：智能提取表格数据
f.图像理解：理解图纸、图表
g.NewAPI 统一管理所有模型
h.灵活的路由策略
i.负载均衡与故障转移
j.容器化部署
k.主备方案
l.可水平扩展
d.项目范围
a.功能范围
a.说明
包含的功能：
不包含的功能：
b.✅ 文档上传与解析
c.✅ 评标规则配置
d.✅ 智能评标分析
e.✅ 评标报告生成
f.✅ 用户权限管理
g.✅ 操作日志审计
h.❌ 招标文件生成
i.❌ 供应商管理
j.❌ 电子签名
k.❌ 工作流引擎
b.技术范围
a.说明
包含的技术：
不包含的技术：
b.✅ 昇腾 NPU 部署
c.✅ 多模态模型集成
d.✅ OCR 能力
e.✅ Web 应用开发
f.✅ 容器化部署
g.❌ 移动端应用
h.❌ 第三方系统集成
i.❌ 数据迁移
c.部署范围
a.说明
部署环境：
不支持：
---
b.✅ 企业内部机房
c.✅ 私有云环境
d.✅ 单一企业独立部署
e.❌ SaaS 多租户模式
f.❌ 公有云部署
e.文档导航
a.文档列表
a.表格数据
文档 说明
00.项目总览.md 项目概述、目标、范围（本文档）
01.技术选型.md 硬件、模型、框架选型详解
02.系统架构设计.md 整体架构、数据流向设计
03.功能模块设计.md 各功能模块详细设计
04.数据与接口设计.md 数据库设计、API 接口设计
05.部署方案.md 硬件配置、容器化部署
06.安全与合规.md 安全方案、合规要求
07.实施计划.md 开发计划、时间表
b.阅读顺序建议
第一次阅读（了解项目）：
1.00.项目总览.md（本文档）
2.01.技术选型.md
3.02.系统架构设计.md
深入技术细节：
4.03.功能模块设计.md
5.04.数据与接口设计.md
部署实施：
6.05.部署方案.md
7.06.安全与合规.md
8.07.实施计划.md
---
f.关键假设与约束
a.关键假设
a.说明
环境假设：
业务假设：
b.企业具备昇腾 NPU 硬件资源（2-4 卡）
c.有基本的机房环境和网络环境
d.有专业的运维团队
e.评标流程相对标准化
f.标书文档格式相对规范
g.评标规则可量化
b.约束条件
a.说明
技术约束：
业务约束：
资源约束：
---
b.必须基于昇腾 NPU 部署
c.必须私有化部署
d.并发会话量：10个
e.符合中国法律法规
f.不涉及国家秘密
g.数据本地化存储
h.开发周期：约 9 周
i.硬件预算：需根据实际情况确定
j.团队规模：需根据实际情况确定
g.风险与挑战
a.技术风险
a.表格数据
风险 影响 缓解措施
昇腾 NPU 适配问题 模型性能不达预期 优先使用官方适配模型，充分测试
多模态理解准确率 评标结果不准确 人工复核机制，持续优化模型
并发性能 响应慢 负载均衡，缓存优化
b.业务风险
a.表格数据
风险 影响 缓解措施
用户接受度 使用意愿低 充分调研用户需求，分阶段上线
评标规则复杂度 配置困难 提供预设模板，简化配置
c.合规风险
a.表格数据
风险 影响 缓解措施
数据安全 数据泄露 本地化存储，权限控制，加密传输
法律合规 法律风险 法律顾问审核，合规性检查
b.说明
---
h.成功标准
a.功能验收标准
1.[ ] 支持上传 PDF、Word、图片文档
2.[ ] 能够正确提取文档中的文字和表格
3.[ ] 能够配置评标规则（评分项、权重、标准）
4.[ ] 能够自动进行标书比对和评分
5.[ ] 能够生成评标报告（PDF/Word）
6.[ ] 支持 10 个并发会话
b.性能验收标准
1.[ ] 文档解析响应时间 < 30 秒（100 页文档）
2.[ ] 智能评标响应时间 < 60 秒
3.[ ] 系统可用性 > 99%
4.[ ] 并发支持 10 个会话
c.安全验收标准
a.说明
---
b.[ ] 数据本地化存储
c.[ ] 操作日志可审计
d.[ ] 权限控制正确
e.[ ] 符合中国法律法规
i.联系方式与资源
a.相关文档
1.昇腾 NPU 模型支持指南
2.vLLM 部署 Qwen 系列模型显存指南
3.NewAPI 模型适配指南
b.技术资源
a.说明
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
b.昇腾社区：https://www.hiascend.com/
c.Qwen 模型：https://github.com/QwenLM
d.NewAPI：https://github.com/QuantumNous/new-api
e.PaddleOCR：https://github.com/PaddlePaddle/PaddleOCR
01.技术选型
a.硬件选型
a.昇腾 NPU 选型
a.推荐配置：昇腾 910B x 2-4 卡
a.说明
选型理由：
b.表格数据
考虑因素 选择方案 理由
计算能力 昇腾 910B 适合大模型推理，性能优异
显存容量 单卡 64GB/128GB 满足 32B 模型 + 多模态需求
扩展性 2-4 卡配置 支持模型并行，提升并发能力
性价比 国产方案 成本相对可控，供应链稳定
c.说明
具体配置建议：
d.表格数据
配置项 推荐值 说明
NPU 型号 昇腾 910B 最新一代，性能最优
NPU 数量 2-4 卡 根据并发需求调整
单卡显存 64GB 或 128GB 优先选择大显存版本
服务器数量 1-2 台 根据高可用需求
b.显存需求分析
a.说明
模型显存需求（估算）：
b.表格数据
模型 参数量 精度 单模型显存 推荐部署
Qwen2.5-72B 72B FP16 ~140GB 2x TP (2卡并行)
Qwen2.5-VL-32B 32B FP16 ~65GB 1卡 (64GB版本) 或 2x TP
Qwen2-VL-7B 7B FP16 ~15GB 1卡
PaddleOCR - - ~2GB 1卡
c.说明
总显存需求（含 KV Cache）：
d.估算预留 20-30% 用于 KV Cache 和并发
e.推荐配置：4x 64GB 或 2x 128GB
b.内存、存储配置
a.内存配置
a.说明
推荐配置：
b.表格数据
配置项 推荐值 说明
系统内存 512GB - 1TB 满足数据处理和缓存需求
内存类型 DDR4/DDR5 与服务器主板兼容
内存带宽 高带宽 优先选择更高带宽
b.存储配置
a.说明
推荐配置：
b.表格数据
存储类型 容量 用途
系统盘 1TB SSD 操作系统和软件
数据盘 10TB+ SSD/NVMe 文档存储、模型存储
备份盘 20TB+ HDD 数据备份
c.网络配置
a.说明
推荐配置：
b.表格数据
配置项 推荐值 说明
网卡 25GbE 或更高 高速数据传输
网络拓扑 万兆骨干 保障数据流通畅
内网隔离 独立 AI 网络 保障模型推理性能
c.说明
---
b.模型选型（昇腾 NPU 适配）
a.文本理解：Qwen2.5-72B-Instruct
a.说明
模型信息：
b.表格数据
属性 值
模型名称 Qwen2.5-72B-Instruct
参数规模 72B
上下文长度 128K tokens
主要能力 文本理解、逻辑推理、指令遵循
c.说明
选型理由：
1.昇腾官方支持
2.中文能力优秀
3.长上下文支持
4.推理能力
昇腾部署链接：
d.昇腾 ModelZoo 直接支持
e.MindSpeed/MindIE 优化完善
f.部署难度低
g.通义千问系列，中文理解能力强
h.适合国内企业采购场景
i.128K 上下文，可处理长文档
j.满足标书文档理解需求
k.逻辑推理能力强
l.适合复杂的评标规则理解
m.昇腾模型库：https://www.hiascend.com/software/modelzoo/models
b.多模态文档理解：Qwen2.5-VL-32B
a.说明
模型信息：
b.表格数据
属性 值
模型名称 Qwen2.5-VL-32B-Instruct
参数规模 32B
输入模态 图像 + 文本
上下文长度 128K tokens
主要能力 文档理解、表格识别、图表理解
c.说明
选型理由：
1.多模态能力
2.表格理解
3.昇腾适配
4.文档场景优化
昇腾部署链接：
d.原生支持图像输入
e.理解文档布局和结构
f.擅长表格数据提取
g.支持复杂表格结构
h.昇腾 MindSpeed MM 支持
i.推理性能优化
j.专门针对文档理解优化
k.支持文档视觉问答
l.Qwen2.5-VL-32B：https://www.hiascend.com/software/modelzoo/models
c.图像理解：Qwen2-VL-7B
a.说明
模型信息：
b.表格数据
属性 值
模型名称 Qwen2-VL-7B-Instruct
参数规模 7B
输入模态 图像 + 文本
主要能力 图像理解、OCR 辅助、图表理解
c.说明
选型理由：
1.轻量高效
2.成本效益
3.昇腾支持
使用场景：
d.7B 参数，推理速度快
e.适合快速图像理解场景
f.显存占用小
g.可与其他模型共享资源
h.昇腾社区已适配
i.部署方案成熟
j.图片预览和快速理解
k.OCR 结果校验
l.图表初步分析
d.OCR 能力：PaddleOCR（昇腾适配）
a.说明
模型信息：
b.表格数据
属性 值
框架 PaddlePaddle
模型 PP-OCRv4
主要能力 文字识别、表格识别
昇腾适配 paddlepaddle-npu
c.说明
选型理由：
1.昇腾官方支持
2.中文优化
3.表格识别
4.成熟稳定
昇腾部署方式：
d.代码示例
---
pip install paddlepaddle-npu
pip install paddleocr
---
e.说明
---
f.百度与华为战略合作
g.paddlepaddle-npu 完美适配
h.中文识别准确率高
i.支持多种字体和排版
j.PaddleStructure 支持表格结构化
k.适合标书表格提取
l.开源社区活跃
m.生产环境验证充分
c.框架选型
a.模型网关：NewAPI
a.说明
选型理由：
b.表格数据
优势 说明
统一接口 一个 API 端点调用所有模型
智能路由 多渠道负载均衡、自动故障转移
灵活计费 支持按请求/使用量计费
权限控制 Token 权限管理、模型访问控制
数据洞察 实时仪表板、使用统计
多租户 支持多用户、多团队
c.说明
核心功能：
部署优势：
相关文档：
d.统一模型管理
e.OpenAI 兼容 API
f.渠道管理与路由
g.监控与日志
h.Docker 容器化部署
i.配置简单，易于维护
j.社区活跃，文档完善
k.NewAPI 模型适配指南
b.推理引擎：昇腾 MindSpeed / MindIE
a.MindSpeed
a.说明
特点：
优势：
适用场景：
b.昇腾官方推理加速框架
c.支持主流大模型
d.性能优化完善
e.官方支持，稳定性好
f.持续更新优化
g.与昇腾硬件深度优化
h.生产环境推理
i.高性能要求场景
b.MindIE
a.说明
特点：
优势：
适用场景：
b.昇腾推理引擎
c.端到端加速支持
d.支持 INT8/FP16 量化
e.推理性能最优
f.内存优化
g.易于部署
h.需要极致性能的场景
i.资源受限场景
c.Web 框架：FastAPI
a.说明
选型理由：
b.表格数据
优势 说明
高性能 异步支持，性能优异
易用性 自动文档生成，开发效率高
类型安全 Python 类型提示支持
生态丰富 大量第三方库支持
现代化 支持 WebSocket、异步任务
c.说明
核心功能：
相关技术：
d.RESTful API
e.WebSocket 支持
f.自动 API 文档（Swagger）
g.请求验证
h.异步任务集成
i.Celery：异步任务队列
j.Redis：缓存和消息队列
k.PostgreSQL/MySQL：数据库
d.前端：Vue 3 + Element Plus
a.Vue 3
a.说明
选型理由：
b.表格数据
优势 说明
组件化 组件化开发，代码复用性高
响应式 响应式数据绑定
生态成熟 大量第三方库和工具
TypeScript 完善的类型支持
b.Element Plus
a.说明
选型理由：
b.表格数据
优势 说明
组件丰富 开箱即用的企业级组件
中文友好 中文文档完善
设计统一 统一的设计语言
维护活跃 持续更新和维护
c.说明
技术栈组合：
---
d.Vue 3（Composition API）
e.TypeScript
f.Element Plus（UI 组件）
g.Pinia（状态管理）
h.Vue Router（路由）
i.Vite（构建工具）
d.技术栈清单
a.后端技术栈
a.表格数据
类别 技术选型 版本要求
编程语言 Python 3.10+
Web 框架 FastAPI 最新稳定版
异步任务 Celery 5.2+
缓存 Redis 6.0+
数据库 PostgreSQL / MySQL 13+ / 8.0+
ORM SQLAlchemy 1.4+
API 文档 Swagger / OpenAPI 自动生成
b.前端技术栈
a.表格数据
类别 技术选型 版本要求
框架 Vue 3.3+
语言 TypeScript 5.0+
UI 组件 Element Plus 2.4+
状态管理 Pinia 2.1+
路由 Vue Router 4.2+
构建工具 Vite 5.0+
HTTP 客户端 Axios 1.6+
c.AI 模型技术栈
a.表格数据
类别 技术选型 部署方式
文本理解 Qwen2.5-72B-Instruct 昇腾 NPU (2x TP)
多模态理解 Qwen2.5-VL-32B 昇腾 NPU (1x 或 2x TP)
图像理解 Qwen2-VL-7B 昇腾 NPU (1x)
OCR PaddleOCR (PP-OCRv4) 昇腾 NPU (1x)
模型网关 NewAPI Docker 容器
d.部署技术栈
a.表格数据
类别 技术选型 说明
容器化 Docker 应用容器化
编排 Docker Compose 服务编排
反向代理 Nginx 负载均衡、SSL
监控 Prometheus + Grafana 性能监控
日志 ELK / EFK 日志聚合分析
b.说明
---
e.技术选型对比
a.模型选型对比
a.表格数据
能力 Qwen2.5-72B Qwen2.5-VL-32B Qwen2-VL-7B PaddleOCR
文本理解 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ -
图像理解 - ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ -
表格识别 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐
OCR 能力 - - - ⭐⭐⭐⭐⭐
推理速度 ⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
资源占用 高 中 低 极低
昇腾支持 ✅ 官方 ✅ 官方 ✅ 官方 ✅ 官方
b.框架选型对比
a.模型网关对比
a.表格数据
特性 NewAPI One API 自建网关
易用性 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
功能完整 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐
维护成本 低 低 高
扩展性 ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
社区活跃 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ -
b.Web 框架对比
a.表格数据
特性 FastAPI Flask Django
性能 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐
易用性 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐
异步支持 ✅ 原生 ⚠️ 有限 ⚠️ 有限
自动文档 ✅ ⚠️ 需插件 ⚠️ 需插件
类型安全 ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐
b.说明
---
f.技术选型决策
a.关键决策
a.说明
为什么选择昇腾 NPU？
1.国产化要求
2.成本优势
3.官方支持
为什么选择 Qwen2.5 系列？
1.昇腾官方支持
2.中文能力
3.开源可商用
为什么选择 NewAPI？
1.统一管理
2.生产就绪
3.易于维护
---
b.符合信创要求
c.供应链可控
d.相比 NVIDIA GPU 成本更低
e.性价比优秀
f.主流模型均有官方适配
g.技术支持完善
h.部署难度低
i.性能优化完善
j.适合国内企业场景
k.理解准确度高
l.无商业授权风险
m.可私有化部署
n.一个网关管理所有模型
o.降低集成复杂度
p.功能完善
q.高可用架构
r.配置简单
s.监控完善
g.技术风险与应对
a.技术风险
a.表格数据
风险 概率 影响 应对措施
昇腾 NPU 性能不达预期 中 高 提前性能测试，必要时调整模型规模
模型理解准确率不足 中 中 人工复核机制，持续优化
并发性能不足 低 中 负载均衡，缓存优化
b.应对策略
a.说明
性能保障：
准确率保障：
稳定性保障：
---
b.充分的性能测试
c.预留扩展空间
d.监控告警机制
e.人工复核流程
f.持续模型优化
g.用户反馈机制
h.高可用架构
i.主备部署
j.容灾预案
h.总结
a.技术选型总结
a.说明
硬件层：
模型层：
框架层：
部署层：
b.昇腾 910B x 2-4 卡
c.内存 512GB-1TB
d.存储 10TB+
e.Qwen2.5-72B（文本理解）
f.Qwen2.5-VL-32B（多模态）
g.Qwen2-VL-7B（图像理解）
h.PaddleOCR（OCR）
i.NewAPI（模型网关）
j.FastAPI（Web 框架）
k.Vue 3 + Element Plus（前端）
l.Docker + Docker Compose
m.Nginx（反向代理）
02.系统架构设计
a.整体架构图
a.四层架构总览
a.代码示例
---
┌─────────────────────────────────────────────────────────┐
│ 展示层 (Presentation Layer) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 评标工具 Web 界面 │ │
│ │ (Vue 3 + Element Plus + TypeScript) │ │
│ │ │ │
│ │ • 文档上传 │ │
│ │ • 规则配置 │ │
│ │ • 评标结果展示 │ │
│ │ • 报告生成 │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────┬────────────────────────────────────┘
│ HTTP/WebSocket
┌────────────────────▼────────────────────────────────────┐
│ 应用层 (Application Layer) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 后端 API 服务 │ │
│ │ (FastAPI + Python + Celery) │ │
│ │ │ │
│ │ • 文档管理 API │ │
│ │ • 评标规则 API │ │
│ │ • 智能评标 API │ │
│ │ • 报告生成 API │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────┬────────────────────────────────────┘
│
┌────────────────────▼────────────────────────────────────┐
│ 网关层 (Gateway Layer) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ NewAPI 网关 │ │
│ │ │ │
│ │ • 模型管理 │ │
│ │ • 请求路由 │ │
│ │ • 负载均衡 │ │
│ │ • 监控统计 │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────┬────────────────────────────────────┘
│
┌────────────────────▼────────────────────────────────────┐
│ 模型层 (Model Layer) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 昇腾 NPU 推理集群 │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ Qwen2.5-72B (文本理解) │ │ │
│ │ │ 部署方式: 2x Tensor Parallel │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ Qwen2.5-VL-32B (多模态文档) │ │ │
│ │ │ 部署方式: 1x 或 2x Tensor Parallel │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ Qwen2-VL-7B (图像理解) │ │ │
│ │ │ 部署方式: 1x │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ PaddleOCR (OCR识别) │ │ │
│ │ │ 部署方式: 1x │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 推理引擎: 昇腾 MindSpeed / MindIE │ │
│ └──────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────┘
---
b.部署架构图
a.代码示例
---
┌─────────────────┐
│ 用户浏览器 │
└────────┬────────┘
│ HTTPS
┌────────▼────────┐
│ Nginx LB │
│ (SSL Terminate) │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌───────▼───────┐┌───▼────┐┌──────▼──────┐
│ Web App 01 ││ Web ││ Web App 02 │
│ (FastAPI) ││ App 03 ││ (FastAPI) │
└───────┬───────┘└───┬────┘└──────┬──────┘
│ │ │
┌───────▼──────────────────▼────────────┐
│ NewAPI Cluster │
│ ┌─────────┐ ┌─────────┐ │
│ │NewAPI 01│ │NewAPI 02│ │
│ └────┬────┘ └────┬────┘ │
└───────┼─────────────┼─────────────────┘
│ │
┌───────▼─────────────▼─────────────────┐
│ 昇腾 NPU 集群 │
│ ┌─────────────────────────────────┐ │
│ │ Qwen2.5-72B (2x TP) │ │
│ │ Qwen2.5-VL-32B (1x/2x TP) │ │
│ │ Qwen2-VL-7B (1x) │ │
│ │ PaddleOCR (1x) │ │
│ └─────────────────────────────────┘ │
└───────────────────────────────────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌─────▼────┐ ┌──────▼──────┐ ┌────▼─────┐
│PostgreSQL│ │ Redis │ │ 文件存储 │
│ 主库 │ │ 缓存 │ │ (NFS/ │
└──────────┘ │ │ │ OSS) │
└─────────────┘ └──────────┘
---
b.说明
---
b.架构层次说明
a.展示层（Presentation Layer）
a.前端架构
a.代码示例
---
┌─────────────────────────────────────────┐
│ Vue 3 应用 │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ 页面组件 │ │ 业务组件 │ │
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
│ ┌─────▼──────────────▼─────┐ │
│ │ 状态管理 (Pinia) │ │
│ └─────────┬────────────────┘ │
│ │ │
│ ┌─────────▼─────────┐ │
│ │ HTTP Client │ │
│ │ (Axios) │ │
│ └───────────────────┘ │
└─────────────────────────────────────────┘
---
b.技术组件
a.表格数据
组件类型 技术选型 说明
框架 Vue 3 渐进式框架
语言 TypeScript 类型安全
UI 组件 Element Plus 企业级组件库
状态管理 Pinia 轻量级状态管理
路由 Vue Router 单页应用路由
构建工具 Vite 快速构建
b.应用层（Application Layer）
a.后端架构
a.代码示例
---
┌─────────────────────────────────────────┐
│ FastAPI 应用 │
│ │
│ ┌──────────────────────────────────┐ │
│ │ API 路由层 │ │
│ │ • 文档管理路由 │ │
│ │ • 评标规则路由 │ │
│ │ • 智能评标路由 │ │
│ │ • 报告生成路由 │ │
│ └─────────────┬────────────────────┘ │
│ │ │
│ ┌─────────────▼────────────────────┐ │
│ │ 业务逻辑层 │ │
│ │ • 文档处理服务 │ │
│ │ • 评标规则服务 │ │
│ │ • 智能评标服务 │ │
│ │ • 报告生成服务 │ │
│ └─────────────┬────────────────────┘ │
│ │ │
│ ┌─────────────▼────────────────────┐ │
│ │ 数据访问层 │ │
│ │ • 数据库操作 │ │
│ │ • 文件操作 │ │
│ │ • 缓存操作 │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────┘
---
b.技术组件
a.表格数据
组件类型 技术选型 说明
框架 FastAPI 高性能 Web 框架
异步任务 Celery 分布式任务队列
数据库 PostgreSQL 关系型数据库
缓存 Redis 内存缓存
ORM SQLAlchemy 数据库 ORM
c.网关层（Gateway Layer）
a.NewAPI 架构
a.代码示例
---
┌─────────────────────────────────────────┐
│ NewAPI 网关 │
│ │
│ ┌──────────────────────────────────┐ │
│ │ API 路由与转发 │ │
│ │ • OpenAI 兼容接口 │ │
│ │ • 模型路由 │ │
│ └─────────────┬────────────────────┘ │
│ │ │
│ ┌─────────────▼────────────────────┐ │
│ │ 渠道管理 │ │
│ │ • 模型渠道配置 │ │
│ │ • 负载均衡 │ │
│ │ • 故障转移 │ │
│ └─────────────┬────────────────────┘ │
│ │ │
│ ┌─────────────▼────────────────────┐ │
│ │ 监控与日志 │ │
│ │ • 请求统计 │ │
│ │ • 性能监控 │ │
│ │ • 错误日志 │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────┘
---
b.核心功能
a.表格数据
功能 说明
统一接口 OpenAI 兼容 API
模型管理 多模型统一管理
请求路由 智能路由到合适模型
负载均衡 多实例负载均衡
故障转移 自动故障转移
监控统计 实时监控和统计
d.模型层（Model Layer）
a.模型部署架构
a.代码示例
---
┌─────────────────────────────────────────┐
│ 昇腾 NPU 推理集群 │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Qwen2.5-72B │ │
│ │ 部署: 2x Tensor Parallel │ │
│ │ 用途: 文本理解、逻辑推理 │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Qwen2.5-VL-32B │ │
│ │ 部署: 1x 或 2x TP │ │
│ │ 用途: 多模态文档理解 │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ Qwen2-VL-7B │ │
│ │ 部署: 1x │ │
│ │ 用途: 图像理解 │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ PaddleOCR │ │
│ │ 部署: 1x │ │
│ │ 用途: OCR 文字识别 │ │
│ └─────────────────────────────────┘ │
│ │
│ 推理引擎: 昇腾 MindSpeed / MindIE │
└─────────────────────────────────────────┘
---
b.模型分配策略
a.表格数据
模型 NPU 分配 用途 并发支持
Qwen2.5-72B 2x TP 复杂文本理解 低并发（1-2）
Qwen2.5-VL-32B 1x/2x TP 多模态文档理解 中并发（3-5）
Qwen2-VL-7B 1x 快速图像理解 高并发（10+）
PaddleOCR 1x OCR 识别 高并发（20+）
b.说明
---
c.数据流向设计
a.文档上传流程
a.代码示例
---
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 用户 │ 上传 │ Web │ 保存 │ 存储 │ 通知 │Celery │
│浏览器│ ───────> │ App │ ───────> │ 文件 │ ───────> │ 任务 │
└──────┘ └──────┘ └──────┘ └──┬───┘
│
┌───▼────┐
│NewAPI │
└───┬────┘
│
┌───▼────┐
│ OCR / │
│ VL模型 │
└────┬───┘
│
┌───▼────┐
│ 数据库 │
└────────┘
---
b.说明
流程说明：
1.上传阶段
2.解析阶段
3.存储阶段
c.用户选择文档（PDF/Word/图片）
d.前端上传到 FastAPI 后端
e.后端保存到文件存储（NFS/OSS）
f.创建 Celery 异步任务
g.调用 NewAPI 发起模型请求
h.PaddleOCR 进行 OCR 识别
i.Qwen2.5-VL-32B 进行文档理解
j.解析结果存入数据库
k.更新任务状态
l.前端轮询获取结果
b.智能评标流程
a.代码示例
---
┌──────┐ 配置 ┌──────┐ 提交 ┌──────┐ 分析 ┌──────┐
│ 用户 │ ────────> │ Web │ ───────> │ Web │ ───────> │Celery │
│浏览器│ │ App │ │ App │ │ 任务 │
└──────┘ └──────┘ └──────┘ └──┬───┘
│
┌──────▼──────┐
│ NewAPI │
│ 模型路由 │
└───┬───┬─────┘
│ │
┌────────────────────────┴───┐
│ │
┌───────▼─────┐ ┌───────▼─────┐
│Qwen2.5-72B │ │Qwen2.5-VL │
│ 文本分析 │ │ 文档分析 │
└───────┬─────┘ └───────┬─────┘
│ │
┌───────▼─────────────────────────────▼─────┐
│ 数据库（评分结果） │
└────────────────────────────────────────┘
---
b.说明
流程说明：
1.配置阶段
2.提交阶段
3.分析阶段
4.汇总阶段
c.用户配置评标规则（评分项、权重）
d.存储评标规则到数据库
e.用户选择标书，提交评标请求
f.创建 Celery 异步任务
g.NewAPI 根据任务类型路由到合适模型
h.Qwen2.5-72B 分析文本内容
i.Qwen2.5-VL-32B 分析文档内容
j.汇总各模型分析结果
k.按照规则计算得分
l.存储评分结果
c.报告生成流程
a.代码示例
---
┌──────┐ 请求 ┌──────┐ 查询 ┌──────┐ 生成 ┌──────┐
│ 用户 │ ────────> │ Web │ ───────> │ 数据 │ ───────> │Celery │
│浏览器│ │ App │ │ 库 │ │ 任务 │
└──────┘ └──────┘ └──────┘ └──┬───┘
│
┌──────▼──────┐
│ 汇总数据 │
│ 格式化 │
└──────┬──────┘
│
┌──────▼──────┐
│ 生成文档 │
│ PDF/Word │
└──────┬──────┘
│
┌──────▼──────┐
│ 文件存储 │
└──────┬──────┘
│
┌──────▼──────┐
│ 下载链接 │
└─────────────┘
---
b.说明
流程说明：
1.请求阶段
2.生成阶段
3.交付阶段
---
c.用户请求生成评标报告
d.系统查询评标数据
e.汇总评标结果
f.按照模板格式化
g.生成 PDF/Word 文档
h.保存到文件存储
i.提供下载链接
d.技术架构图
a.技术栈全景图
a.代码示例
---
┌─────────────────────────────────────────────────────────┐
│ 用户层 │
│ (Web 浏览器 / 移动端) │
└────────────────────┬────────────────────────────────────┘
│ HTTPS/WebSocket
┌────────────────────▼────────────────────────────────────┐
│ 前端技术栈 │
│ │
│ Vue 3 + TypeScript + Element Plus + Vite │
└────────────────────┬────────────────────────────────────┘
│ HTTP/WebSocket
┌────────────────────▼────────────────────────────────────┐
│ 后端技术栈 │
│ │
│ FastAPI + Celery + PostgreSQL + Redis │
└────────────────────┬────────────────────────────────────┘
│ REST API
┌────────────────────▼────────────────────────────────────┐
│ 网关层技术栈 │
│ │
│ NewAPI + Docker + Nginx │
└────────────────────┬────────────────────────────────────┘
│ OpenAI Compatible API
┌────────────────────▼────────────────────────────────────┐
│ AI 模型技术栈 │
│ │
│ Qwen2.5-72B + Qwen2.5-VL-32B + Qwen2-VL-7B │
│ + PaddleOCR + 昇腾 MindSpeed / MindIE │
└────────────────────┬────────────────────────────────────┘
│
┌────────────────────▼────────────────────────────────────┐
│ 硬件层 │
│ │
│ 昇腾 910B x 2-4 卡 + 内存 512GB-1TB + 存储 10TB+ │
└───────────────────────────────────────────────────────┘
---
b.网络拓扑图
a.代码示例
---
┌─────────┐
│ 互联网 │
└────┬────┘
│
┌────▼────┐
│ 防火墙 │
└────┬────┘
│
┌──────────┼──────────┐
│ │ │
┌────▼───┐ ┌───▼───┐ ┌───▼────┐
│Nginx LB│ │Nginx │ │Nginx LB│
│ 主节点│ │ 备节点│ │ 备节点│
└────┬───┘ └───┬───┘ └────┬───┘
│ │ │
┌────┴─────────┴─────────┴────┐
│ 内网负载均衡 │
└─────────────┬───────────────┘
│
┌─────────────┴───────────────┐
│ 应用服务器集群 │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │App 1│ │App 2│ │App 3│ │
│ └─────┘ └─────┘ └─────┘ │
└─────────────┬───────────────┘
│
┌─────────────┴───────────────┐
│ NewAPI 集群 │
│ ┌─────┐ ┌─────┐ │
│ │N-API│ │N-API│ │
│ │ 01 │ │ 02 │ │
│ └─────┘ └─────┘ │
└─────────────┬───────────────┘
│
┌─────────────┴───────────────┐
│ 昇腾 NPU 计算节点 │
│ ┌─────────────────────┐ │
│ │ 昇腾 910B x 4 │ │
│ └─────────────────────┘ │
└────────────────────────────┘
---
b.说明
---
e.关键技术决策
a.为什么选择 NewAPI？
a.说明
决策分析：
b.表格数据
考虑因素 NewAPI 自建网关 One API
开发成本 低 高 低
维护成本 低 高 低
功能完整 完善 需开发 完善
扩展性 好 最好 好
社区支持 活跃 无 活跃
c.说明
决策理由：
1.统一接口 - 一个网关管理所有模型
2.生产就绪 - 功能完善，稳定性好
3.易于维护 - 配置简单，监控完善
4.成本优势 - 开源免费，降低总体成本
b.为什么选择昇腾 NPU？
a.说明
决策分析：
b.表格数据
考虑因素 昇腾 NPU NVIDIA GPU
成本 较低 高
供应链 稳定 不稳定
国产化 符合 不符合
性能 优秀 优秀
模型支持 日益完善 最完善
c.说明
决策理由：
1.国产化要求 - 符合信创要求
2.成本优势 - 硬件成本更低
3.供应链稳定 - 不受国际形势影响
4.官方支持 - 主流模型均有适配
c.为什么选择 Qwen2.5 系列？
a.说明
决策分析：
b.表格数据
模型 中文能力 长上下文 昇腾支持 商用授权
Qwen2.5 ⭐⭐⭐⭐⭐ 128K ✅ 官方 ✅ 开源
DeepSeek-V3 ⭐⭐⭐⭐⭐ 128K ⚠️ 社区 ✅ 开源
Llama 3 ⭐⭐⭐ 128K ✅ 官方 ✅ 开源
c.说明
决策理由：
1.中文能力 - 适合国内企业场景
2.昇腾适配 - 官方支持，部署简单
3.长上下文 - 128K 满足长文档需求
4.开源可商用 - 无授权风险
d.为什么选择微服务架构？
a.说明
决策分析：
b.表格数据
架构 开发复杂度 维护成本 扩展性 故障隔离
单体 低 低 差 差
微服务 高 高 好 好
c.说明
决策理由：
1.职责分离 - 各模块独立开发部署
2.技术选型灵活 - 前后端可独立优化
3.水平扩展 - 可独立扩展各模块
4.故障隔离 - 单个模块故障不影响全局
---
f.安全架构
a.安全层次
a.代码示例
---
┌─────────────────────────────────────────┐
│ 应用安全层 │
│ • 身份认证 │
│ • 权限控制 │
│ • API 安全 │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ 数据安全层 │
│ • 数据加密 │
│ • 传输加密 │
│ • 存储加密 │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ 网络安全层 │
│ • 防火墙 │
│ • 网络隔离 │
│ • 访问控制 │
└─────────────────────────────────────────┘
---
b.数据安全
a.说明
数据流安全：
b.代码示例
---
用户浏览器 ──[TLS]──> Nginx ──[TLS]──> FastAPI
│
[内网]
│
┌───────▼──────┐
│ NewAPI │
└───────┬──────┘
│
[内网]
│
┌───────▼──────┐
│ 昇腾 NPU │
└──────────────┘
---
c.说明
安全措施：
d.表格数据
层次 措施
传输层 HTTPS/TLS 1.3
应用层 JWT Token 认证
数据层 数据库加密存储
网络层 内网隔离，防火墙
物理层 机房访问控制
e.说明
---
g.性能架构
a.性能优化策略
a.说明
前端优化：
b.表格数据
策略 说明
代码分割 路由级代码分割
懒加载 组件懒加载
缓存 静态资源 CDN 缓存
压缩 Gzip 压缩
c.说明
后端优化：
d.表格数据
策略 说明
异步处理 Celery 异步任务
缓存 Redis 缓存热点数据
连接池 数据库连接池
查询优化 索引优化，查询优化
e.说明
模型优化：
f.表格数据
策略 说明
量化 FP8/INT8 量化
批处理 请求批处理
缓存 KV Cache 缓存
并行 Tensor Parallel
b.扩展策略
a.说明
水平扩展：
b.代码示例
---
┌─────────────────────────────────────────┐
│ 负载均衡 (Nginx) │
└──────┬────────────┬────────────┬─────────┘
│ │ │
┌───▼────┐ ┌───▼────┐ ┌───▼────┐
│App 实例│ │App 实例│ │App 实例│
│ 01 │ │ 02 │ │ 03 │
└────────┘ └────────┘ └────────┘
---
c.说明
垂直扩展：
---
d.增加 NPU 卡数
e.增加内存容量
f.升级 CPU 性能
h.监控架构
a.监控体系
a.代码示例
---
┌─────────────────────────────────────────┐
│ 监控数据收集 │
│ • 应用指标 │
│ • 系统指标 │
│ • 业务指标 │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ Prometheus │
│ • 时序数据库 │
│ • 数据采集 │
└────────────┬────────────────────────────┘
│
┌────────────▼────────────────────────────┐
│ Grafana │
│ • 可视化展示 │
│ • 告警通知 │
└─────────────────────────────────────────┘
---
b.监控指标
a.说明
应用指标：
b.表格数据
类别 指标
请求量 QPS、并发数
响应时间 P50、P95、P99 延迟
错误率 4xx、5xx 比率
业务指标 评标任务数、成功率
c.说明
系统指标：
d.表格数据
类别 指标
CPU 使用率
内存 使用率
NPU 使用率、温度
存储 使用率、IOPS
e.说明
---
i.容灾架构
a.高可用方案
a.说明
应用层高可用：
b.代码示例
---
┌─────────────────────────────────────────┐
│ 主备部署架构 │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 主节点 │ <────> │ 备节点 │ │
│ │ (Active) │ │ (Standby) │ │
│ └──────────┘ └──────────┘ │
│ │
│ • 数据同步 │
│ • 故障自动切换 │
│ • 健康检查 │
└─────────────────────────────────────────┘
---
c.说明
数据层高可用：
d.PostgreSQL 主备复制
e.Redis 哨兵模式
f.文件存储定期备份
b.备份策略
a.说明
备份范围：
b.表格数据
数据类型 备份频率 保留周期
数据库 每日 30 天
文件存储 每周 90 天
配置文件 每次变更 永久
日志文件 每日 7 天
c.说明
---
j.总结
a.架构亮点
✅ 四层架构 - 清晰的层次划分
✅ 微服务设计 - 模块化，易扩展
✅ 昇腾全栈 - 硬件到模型全适配
✅ 高可用设计 - 主备、负载均衡
✅ 安全合规 - 数据本地化，权限控制
b.技术优势
a.说明
性能优势：
可靠性优势：
可维护性优势：
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
b.异步处理，高并发支持
c.缓存优化，响应快速
d.模型并行，推理高效
e.高可用架构
f.容灾备份
g.故障隔离
h.模块化设计
i.统一网关管理
j.完善的监控
03.功能模块设计
a.文档上传与解析模块
a.功能描述
a.说明
支持多种格式的标书文档上传和智能解析，是评标流程的起点。
支持的文档类型：
b.表格数据
文档类型 支持格式 文件大小限制
PDF 文档 .pdf ≤ 200MB
Word 文档 .docx ≤ 100MB
图片文档 .jpg/.png/.tiff ≤ 50MB
c.说明
核心功能：
d.文档上传（支持批量）
e.文档格式验证
f.文档解析进度追踪
g.解析结果预览
b.技术实现方案
a.处理流程
a.代码示例
---
文档上传
│
├── 格式验证
│ └── 检查文件类型、大小、格式
│
├── 文件存储
│ └── 保存到文件系统（NFS/OSS）
│
├── 创建解析任务
│ └── 提交到 Celery 异步队列
│
└── 返回任务 ID
└── 前端轮询任务状态
---
b.技术实现
a.说明
前端实现：
b.代码示例
---
// 文档上传组件
interface UploadConfig {
maxSize: number; // 最大文件大小
acceptTypes: string[]; // 接受的文件类型
maxFiles: number; // 最大文件数量
}
// 上传接口调用
async function uploadDocuments(files: File[]) {
const formData = new FormData();
files.forEach(file => formData.append('files', file));
const response = await axios.post('/api/documents/upload', formData, {
headers: { 'Content-Type': 'multipart/form-data' }
});
return response.data; // { task_id: 'xxx', status: 'pending' }
}
---
c.说明
后端实现：
d.代码示例
---
# FastAPI 路由
@router.post("/upload")
async def upload_documents(
files: List[UploadFile],
current_user: User = Depends(get_current_user)
):
# 1. 验证文件
for file in files:
validate_file(file)
# 2. 保存文件
saved_files = []
for file in files:
file_path = save_file(file)
saved_files.append(file_path)
# 3. 创建解析任务
task = parse_documents.delay(saved_files, current_user.id)
return {"task_id": task.id, "status": "pending"}
# Celery 任务
@celery.task
def parse_documents(file_paths: List[str], user_id: int):
results = []
for file_path in file_paths:
# 调用 NewAPI 进行文档解析
if file_path.endswith('.pdf'):
result = parse_pdf(file_path)
elif file_path.endswith('.docx'):
result = parse_docx(file_path)
else: # 图片
result = parse_image(file_path)
results.append(result)
# 保存解析结果到数据库
save_parse_results(results, user_id)
return {"status": "completed", "results": results}
---
c.涉及的模型
a.表格数据
任务 使用模型 说明
OCR 文字提取 PaddleOCR 从图片/PDF 提取文字
表格识别 PaddleOCR + PaddleStructure 识别表格结构
文档理解 Qwen2.5-VL-32B 理解文档内容和结构
c.输出结果
a.说明
解析结果结构：
b.代码示例
---
{
"document_id": "doc_001",
"file_name": "标书文件.pdf",
"file_type": "pdf",
"page_count": 100,
"parse_status": "completed",
"parsed_content": {
"text": "...", // 提取的文本内容
"tables": [...], // 提取的表格数据
"images": [...], // 提取的图片信息
"metadata": {...} // 文档元数据
},
"parse_time": 45.5, // 解析耗时（秒）
"created_at": "2025-01-15T10:00:00Z"
}
---
c.说明
---
b.评标规则配置模块
a.功能描述
a.说明
灵活配置评标规则，支持自定义评分项、权重和评分标准。
核心功能：
b.评分项设置（商务、技术、价格等）
c.权重配置（各项权重分配）
d.评分标准定义
e.自动评分规则配置
b.技术实现方案
a.数据模型
a.说明
评标规则结构：
b.代码示例
---
from pydantic import BaseModel
from typing import List, Dict
class ScoringItem(BaseModel):
item_id: str # 评分项 ID
item_name: str # 评分项名称
item_type: str # 类型：商务/技术/价格
weight: float # 权重（0-1）
max_score: float # 最高分
scoring_criteria: Dict # 评分标准
auto_scoring: bool = False # 是否自动评分
class EvaluationRule(BaseModel):
rule_id: str # 规则 ID
rule_name: str # 规则名称
project_type: str # 项目类型
scoring_items: List[ScoringItem] # 评分项列表
total_score: float # 总分
created_by: str # 创建人
created_at: datetime # 创建时间
---
b.配置流程
a.代码示例
---
创建评标规则
│
├── 基本信息
│ ├── 规则名称
│ ├── 项目类型
│ └── 适用范围
│
├── 评分项配置
│ ├── 添加评分项
│ ├── 设置权重
│ └── 定义评分标准
│
├── 自动评分规则
│ ├── 配置量化指标
│ ├── 设定阈值
│ └── 关联模型
│
└── 保存规则
└── 存入数据库
---
c.API 接口设计
a.说明
创建评标规则：
b.代码示例
---
@router.post("/rules")
async def create_rule(
rule: EvaluationRuleCreate,
current_user: User = Depends(get_current_user)
):
# 1. 验证权重总和 = 1
validate_weights(rule.scoring_items)
# 2. 保存到数据库
rule_id = save_rule_to_db(rule, current_user.id)
return {"rule_id": rule_id, "status": "created"}
---
c.说明
获取评标规则：
d.代码示例
---
@router.get("/rules/{rule_id}")
async def get_rule(
rule_id: str,
current_user: User = Depends(get_current_user)
):
rule = get_rule_from_db(rule_id)
return rule
---
e.说明
更新评标规则：
f.代码示例
---
@router.put("/rules/{rule_id}")
async def update_rule(
rule_id: str,
rule_update: EvaluationRuleUpdate,
current_user: User = Depends(get_current_user)
):
update_rule_in_db(rule_id, rule_update)
return {"status": "updated"}
---
c.配置示例
a.说明
典型评标规则配置：
b.代码示例
---
{
"rule_name": "物资采购评标规则",
"project_type": "物资采购",
"scoring_items": [
{
"item_name": "商务评分",
"item_type": "商务",
"weight": 0.3,
"max_score": 30,
"scoring_criteria": {
"企业资质": {
"max_score": 10,
"criteria": "根据企业资质等级评分"
},
"财务状况": {
"max_score": 10,
"criteria": "根据财务报表评分"
},
"类似业绩": {
"max_score": 10,
"criteria": "根据近3年业绩评分"
}
},
"auto_scoring": false
},
{
"item_name": "技术评分",
"item_type": "技术",
"weight": 0.5,
"max_score": 50,
"scoring_criteria": {
"技术方案": {
"max_score": 20,
"auto_scoring": true,
"model": "Qwen2.5-72B",
"prompt": "根据技术方案的完整性、可行性评分"
},
"产品参数": {
"max_score": 20,
"auto_scoring": true,
"model": "Qwen2.5-VL-32B",
"prompt": "根据产品参数符合度评分"
},
"质量保证": {
"max_score": 10,
"criteria": "根据质保体系评分"
}
}
},
{
"item_name": "价格评分",
"item_type": "价格",
"weight": 0.2,
"max_score": 20,
"scoring_criteria": {
"报价合理性": {
"max_score": 20,
"auto_scoring": true,
"calculation": "最低价得满分，其他按比例"
}
}
}
],
"total_score": 100
}
---
c.说明
---
c.智能评标模块
a.功能描述
a.说明
基于 AI 模型进行智能评标分析，是系统的核心功能。
核心能力：
b.标书自动比对
c.条款符合度分析
d.价格比对分析
e.技术参数评分
b.技术实现方案
a.标书自动比对
a.说明
功能说明：
自动比对多份标书，找出差异点，辅助评标决策。
处理流程：
b.代码示例
---
多份标书
│
├── 提取关键信息
│ ├── Qwen2.5-72B：文本分析
│ └── Qwen2.5-VL-32B：文档理解
│
├── 构建比对矩阵
│ └── 生成差异点列表
│
└── 输出比对报告
└── 高亮显示差异
---
c.说明
技术实现：
d.代码示例
---
@celery.task
def compare_documents(doc_ids: List[str], rule_id: str):
# 1. 获取文档内容
docs = [get_document(doc_id) for doc_id in doc_ids]
# 2. 调用模型进行比对
comparison_result = call_llm_with_qwen72b(
prompt=f"请对比以下标书，找出差异点：{docs}",
model="Qwen2.5-72B-Instruct"
)
# 3. 保存比对结果
save_comparison_result(comparison_result)
return comparison_result
---
b.条款符合度分析
a.说明
功能说明：
检查标书条款与招标要求的符合度。
处理流程：
b.代码示例
---
招标要求 + 标书文档
│
├── 提取招标要求
│ └── Qwen2.5-72B：结构化提取
│
├── 提取标书承诺
│ └── Qwen2.5-VL-32B：文档理解
│
├── 逐条比对
│ └── Qwen2.5-72B：符合度判断
│
└── 输出符合度报告
└── 高亮不符合项
---
c.说明
技术实现：
d.代码示例
---
@celery.task
def check_compliance(tender_doc_id: str, bid_doc_ids: List[str]):
# 1. 提取招标要求
requirements = extract_requirements(tender_doc_id)
# 2. 检查每个投标方的符合度
compliance_results = []
for bid_doc_id in bid_doc_ids:
# 调用多模态模型检查
result = call_multimodal_model(
model="Qwen2.5-VL-32B",
prompt="检查标书是否符合招标要求",
image=get_document_pages(bid_doc_id)
)
compliance_results.append({
"bid_doc_id": bid_doc_id,
"compliance_score": result["score"],
"non_compliant_items": result["issues"]
})
# 3. 保存结果
save_compliance_results(compliance_results)
return compliance_results
---
c.价格比对分析
a.说明
功能说明：
自动提取价格信息，进行横向对比。
处理流程：
b.代码示例
---
标书文档
│
├── 提取价格信息
│ ├── PaddleOCR：表格识别
│ └── Qwen2.5-VL-32B：价格表理解
│
├── 价格数据结构化
│ └── 统一价格格式
│
├── 价格对比
│ ├── 计算价格得分
│ └── 生成对比图表
│
└── 输出价格分析报告
---
c.说明
技术实现：
d.代码示例
---
@celery.task
def analyze_prices(bid_doc_ids: List[str], rule_id: str):
# 1. 提取价格信息
prices = []
for doc_id in bid_doc_ids:
# 使用 OCR + 多模态模型提取
price_info = extract_price_info(doc_id)
prices.append(price_info)
# 2. 计算价格得分
min_price = min(p["total_price"] for p in prices)
for price in prices:
price["score"] = (min_price / price["total_price"]) * 20
# 3. 保存结果
save_price_analysis(prices)
return prices
---
d.技术参数评分
a.说明
功能说明：
根据技术参数自动评分。
处理流程：
b.代码示例
---
技术参数表
│
├── 提取参数
│ ├── PaddleOCR：表格识别
│ └── Qwen2.5-VL-32B：参数理解
│
├── 参数比对
│ ├── 与招标要求比对
│ └── Qwen2.5-72B：符合度分析
│
├── 计算得分
│ ├── 逐项打分
│ └── 汇总得分
│
└── 输出评分结果
---
c.说明
技术实现：
d.代码示例
---
@celery.task
def score_technical_params(bid_doc_id: str, rule_id: str):
# 1. 获取评分规则
rule = get_rule(rule_id)
# 2. 提取技术参数
params = extract_technical_params(bid_doc_id)
# 3. 逐项评分
scores = []
for item in rule.scoring_items:
if item.auto_scoring:
# 调用模型自动评分
item_score = call_llm_with_qwen72b(
prompt=f"根据评分标准给技术参数打分：{params}",
criteria=item.scoring_criteria
)
scores.append({
"item_id": item.item_id,
"score": item_score
})
# 4. 汇总得分
total_score = calculate_total_score(scores, rule)
# 5. 保存结果
save_scoring_result(bid_doc_id, scores, total_score)
return {"scores": scores, "total_score": total_score}
---
c.涉及的模型
a.表格数据
功能 使用模型 昇腾部署方式
文本理解 Qwen2.5-72B-Instruct 2x Tensor Parallel
多模态理解 Qwen2.5-VL-32B 1x 或 2x Tensor Parallel
图像理解 Qwen2-VL-7B 1x
OCR 识别 PaddleOCR 1x
b.说明
---
d.评标报告生成模块
a.功能描述
a.说明
自动生成专业的评标报告，支持多种格式导出。
核心功能：
b.报告模板管理
c.数据汇总
d.报告生成
e.多格式导出
b.技术实现方案
a.报告模板设计
a.说明
报告结构：
b.代码示例
---
class ReportTemplate(BaseModel):
template_id: str
template_name: str
template_type: str # PDF/Word
sections: List[ReportSection]
class ReportSection(BaseModel):
section_id: str
section_name: str
section_type: str # text/table/chart
content_source: str # database/template
sort_order: int
---
c.说明
典型报告结构：
d.代码示例
---
1. 评标概况
- 项目基本信息
- 参与供应商信息
- 评标时间、专家信息
2. 评标规则
- 评分项说明
- 权重分配
- 评分标准
3. 评分明细
- 各供应商得分
- 各项得分详情
- 得分对比图表
4. 综合评分
- 总得分排名
- 得分汇总表
5. 推荐建议
- 推荐中标方
- 推荐理由
- 风险提示
6. 附件
- 标书文件
- 评分明细表
- 符合性检查表
---
b.报告生成流程
a.代码示例
---
用户请求生成报告
│
├── 获取评标数据
│ ├── 标书信息
│ ├── 评分结果
│ └── 评标规则
│
├── 应用报告模板
│ ├── 填充数据
│ ├── 生成图表
│ └── 格式化内容
│
├── 生成文档
│ ├── 生成 PDF
│ └── 生成 Word
│
└── 保存并下载
├── 保存到文件存储
└── 提供下载链接
---
c.技术实现
a.说明
报告生成 API：
b.代码示例
---
@router.post("/reports/generate")
async def generate_report(
request: ReportGenerateRequest,
current_user: User = Depends(get_current_user)
):
# 1. 获取评标数据
evaluation_data = get_evaluation_data(request.evaluation_id)
# 2. 应用模板
report_content = apply_template(
evaluation_data,
request.template_id
)
# 3. 生成文档
if request.format == "pdf":
file_path = generate_pdf(report_content)
elif request.format == "docx":
file_path = generate_docx(report_content)
# 4. 保存文件
report_id = save_report_file(file_path, current_user.id)
return {
"report_id": report_id,
"download_url": f"/api/reports/{report_id}/download"
}
---
c.说明
PDF 生成：
d.代码示例
---
from reportlab.lib.pagesizes import A4
from reportlab.pdfgen import canvas
def generate_pdf(content: dict) -> str:
buffer = BytesIO()
doc = SimpleDocTemplate(buffer, pagesize=A4)
# 构建报告内容
story = []
story.append(Paragraph("评标报告", style_title))
# 添加各章节
for section in content["sections"]:
story.append(Paragraph(section["title"], style_heading))
story.append(Paragraph(section["content"], style_normal))
# 生成 PDF
doc.build(story)
# 保存文件
file_path = f"reports/{uuid.uuid4()}.pdf"
with open(file_path, "wb") as f:
f.write(buffer.getvalue())
return file_path
---
e.说明
Word 生成：
f.代码示例
---
from docx import Document
from docx.shared import Inches
def generate_docx(content: dict) -> str:
doc = Document()
# 添加标题
doc.add_heading("评标报告", 0)
# 添加各章节
for section in content["sections"]:
doc.add_heading(section["title"], 1)
doc.add_paragraph(section["content"])
# 添加表格（如果有）
if "table" in section:
table = doc.add_table(rows=len(section["table"]), cols=3)
for i, row in enumerate(section["table"]):
for j, cell in enumerate(row):
table.rows[i].cells[j].text = cell
# 保存文件
file_path = f"reports/{uuid.uuid4()}.docx"
doc.save(file_path)
return file_path
---
c.报告输出示例
a.说明
报告内容预览：
b.代码示例
---
评标报告
===========================================
一、评标概况
-------------------------------------------
项目名称：XX 设备采购项目
评标时间：2025-01-15
评标专家：张三、李四、王五
参与供应商：A公司、B公司、C公司
二、评分明细
-------------------------------------------
1. 商务评分（权重 30%）
A公司：28 分
B公司：25 分
C公司：27 分
2. 技术评分（权重 50%）
A公司：45 分
B公司：42 分
C公司：46 分
3. 价格评分（权重 20%）
A公司：18 分
B公司：15 分
C公司：19 分
三、综合评分
-------------------------------------------
总分排名：
第一名：C公司（92 分）
第二名：A公司（91 分）
第三名：B公司（82 分）
四、推荐建议
-------------------------------------------
推荐中标方：C公司
推荐理由：综合得分最高，技术方案优秀，价格合理。
---
c.说明
---
e.模块交互流程
a.完整评标流程
a.代码示例
---
┌──────────┐
│ 开始 │
└─────┬────┘
│
┌─────▼─────────┐
│ 上传标书文档 │
└─────┬─────────┘
│
┌─────▼────────────┐
│ 配置评标规则 │
└─────┬────────────┘
│
┌─────▼────────────┐
│ 提交评标请求 │
└─────┬────────────┘
│
┌─────▼────────────┐
│ 智能评标分析 │
│ ├─ 文档解析 │
│ ├─ 标书比对 │
│ ├─ 符合度检查 │
│ ├─ 价格分析 │
│ └─ 参数评分 │
└─────┬────────────┘
│
┌─────▼────────────┐
│ 生成评标报告 │
└─────┬────────────┘
│
┌─────▼────────────┐
│ 下载报告 │
└─────┬────────────┘
│
┌─────▼────┐
│ 结束 │
└──────────┘
---
b.模块依赖关系
a.表格数据
模块 依赖模块 被依赖模块
文档上传与解析 - 评标规则配置、智能评标
评标规则配置 文档上传与解析 智能评标、报告生成
智能评标 文档上传与解析、评标规则配置 报告生成
报告生成 文档上传与解析、评标规则配置、智能评标 -
b.说明
---
f.用户界面设计
a.界面布局
a.说明
主界面结构：
b.代码示例
---
┌─────────────────────────────────────────┐
│ 评标工具 Logo 用户 | 设置 │
├─────────────────────────────────────────┤
│ 导航栏 │
│ • 概览 • 文档管理 │
│ • 评标规则 • 评标项目 │
│ • 评标结果 • 报告中心 │
├─────────────────────────────────────────┤
│ │
│ [内容区域 - 根据导航动态显示] │
│ │
│ │
└─────────────────────────────────────────┘
---
b.核心页面
a.说明
文档管理页面：
b.代码示例
---
┌─────────────────────────────────────────┐
│ 文档管理 [上传文档] [批量上传] │
├─────────────────────────────────────────┤
│ 文档列表 │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │文档名│类型 │状态 │页数 │操作 │ │ │
│ ├─────┼─────┼─────┼─────┼─────┼─────┤ │
│ │标书1 │PDF │已解析│100 │详情 │删除 │ │
│ │标书2 │Word │解析中│ 50 │进度 │ │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┘ │
└─────────────────────────────────────────┘
---
c.说明
评标规则配置页面：
d.代码示例
---
┌─────────────────────────────────────────┐
│ 评标规则配置 [保存] [取消] │
├─────────────────────────────────────────┤
│ 规则名称：[_________________] │
│ 项目类型：[下拉选择] │
├─────────────────────────────────────────┤
│ 评分项配置 │
│ ┌─────────────────────────────────┐ │
│ │ 评分项：[商务评分] │ │
│ │ 权重：[30%] │ │
│ │ 最高分：[30] │ │
│ │ [+添加评分项] │ │
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ 自动评分规则 │
│ ☑ 启用自动评分 │
│ ┌─────────────────────────────────┐ │
│ │ 模型选择：[Qwen2.5-72B ▼] │ │
│ │ 评分提示：[_____________] │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
---
e.说明
---
g.异常处理
a.异常类型
a.表格数据
异常类型 处理方式
文档解析失败 记录日志，返回错误信息，允许重新上传
模型调用失败 重试机制，降级到备用模型
评分规则冲突 验证规则一致性，阻止保存
报告生成失败 记录日志，允许重新生成
b.容错机制
a.说明
重试策略：
b.代码示例
---
# Celery 任务重试配置
@celery.task(
bind=True,
max_retries=3,
default_retry_delay=60
)
def parse_document_with_retry(file_path: str):
try:
return parse_document(file_path)
except Exception as exc:
raise self.retry(exc=exc)
---
c.说明
降级策略：
d.代码示例
---
# 模型降级
def call_model_with_fallback(prompt: str, primary_model: str):
try:
return call_model(prompt, primary_model)
except Exception:
# 降级到备用模型
return call_model(prompt, "Qwen2-VL-7B")
---
e.说明
---
h.性能优化
a.缓存策略
a.说明
缓存层次：
b.代码示例
---
┌────────────┐
│ 浏览器缓存 │ ← 静态资源
└─────┬──────┘
│
┌─────▼────────┐
│ CDN 缓存 │ ← 静态资源
└─────┬────────┘
│
┌─────▼────────┐
│ Redis 缓存 │ ← 热点数据
└─────┬────────┘
│
┌─────▼────────┐
│ 数据库 │ ← 持久化数据
└──────────────┘
---
c.说明
缓存内容：
d.表格数据
数据类型 缓存时长 更新策略
评标规则 1 小时 主动更新
文档解析结果 24 小时 主动更新
评分结果 永久 不更新
用户信息 30 分钟 主动更新
b.异步处理
a.说明
异步任务列表：
b.表格数据
任务 队列 优先级
文档解析 high 高
智能评标 medium 中
报告生成 low 低
c.说明
---
i.总结
a.功能模块总结
a.表格数据
模块 核心功能 关键技术
文档上传与解析 多格式文档智能解析 PaddleOCR、Qwen2.5-VL-32B
评标规则配置 灵活配置评分规则 Python、Vue 3
智能评标 AI 辅助评标分析 Qwen2.5-72B、Qwen2.5-VL-32B
报告生成 自动生成专业报告 ReportLab、python-docx
b.技术亮点
✅ 多模态 AI - 文档、图像、表格全方位理解
✅ 异步处理 - Celery 异步任务，高并发支持
✅ 模块化设计 - 职责清晰，易于维护
✅ 用户友好 - 直观的界面，简单的操作流程
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
04.数据与接口设计
a.数据库设计
a.数据库概述
a.说明
数据库选型：
设计原则：
b.主选：PostgreSQL 13+
c.备选：MySQL 8.0+
d.遵循第三范式（3NF）
e.适当冗余以提高查询性能
f.使用外键保证数据完整性
g.添加索引提高查询效率
b.核心数据表
a.标书信息表 (t_documents)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_documents (
id BIGSERIAL PRIMARY KEY,
doc_name VARCHAR(255) NOT NULL, -- 文档名称
doc_type VARCHAR(50) NOT NULL, -- 文档类型（pdf/docx/image）
file_path VARCHAR(500) NOT NULL, -- 文件存储路径
file_size BIGINT NOT NULL, -- 文件大小（字节）
page_count INTEGER, -- 页数
upload_time TIMESTAMP NOT NULL, -- 上传时间
upload_user_id BIGINT NOT NULL, -- 上传用户ID
parse_status VARCHAR(20) NOT NULL DEFAULT 'pending', -- 解析状态
parse_result JSONB, -- 解析结果
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);
-- 索引
CREATE INDEX idx_documents_upload_user ON t_documents(upload_user_id);
CREATE INDEX idx_documents_parse_status ON t_documents(parse_status);
---
c.说明
字段说明：
d.表格数据
字段 类型 说明
parse_status VARCHAR(20) pending/parsing/completed/failed
parse_result JSONB 存储解析结果的 JSON 数据
e.说明
解析结果结构：
f.代码示例
---
{
"text": "提取的文本内容",
"tables": [
{
"table_id": "t1",
"page": 1,
"rows": 10,
"cols": 5,
"data": [...]
}
],
"images": [
{
"image_id": "i1",
"page": 2,
"file_path": "/images/doc1_i1.png"
}
],
"metadata": {
"author": "XXX公司",
"create_time": "2025-01-01"
}
}
---
b.评标规则表 (t_evaluation_rules)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_evaluation_rules (
id BIGSERIAL PRIMARY KEY,
rule_name VARCHAR(255) NOT NULL, -- 规则名称
rule_type VARCHAR(50) NOT NULL, -- 规则类型
total_score DECIMAL(5,2) NOT NULL, -- 总分
project_type VARCHAR(100), -- 项目类型
description TEXT, -- 规则描述
created_by BIGINT NOT NULL, -- 创建人ID
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);
-- 索引
CREATE INDEX idx_evaluation_rules_type ON t_evaluation_rules(rule_type);
---
c.评分项表 (t_scoring_items)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_scoring_items (
id BIGSERIAL PRIMARY KEY,
rule_id BIGINT NOT NULL, -- 规则ID
item_name VARCHAR(255) NOT NULL, -- 评分项名称
item_type VARCHAR(50) NOT NULL, -- 类型（商务/技术/价格）
weight DECIMAL(5,4) NOT NULL, -- 权重
max_score DECIMAL(5,2) NOT NULL, -- 最高分
scoring_criteria JSONB NOT NULL, -- 评分标准
auto_scoring BOOLEAN NOT NULL DEFAULT FALSE, -- 是否自动评分
model_name VARCHAR(100), -- 使用的模型
prompt_template TEXT, -- 提示词模板
sort_order INTEGER NOT NULL, -- 排序
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
CONSTRAINT fk_scoring_items_rule FOREIGN KEY (rule_id)
REFERENCES t_evaluation_rules(id) ON DELETE CASCADE
);
-- 索引
CREATE INDEX idx_scoring_items_rule ON t_scoring_items(rule_id);
CREATE INDEX idx_scoring_items_type ON t_scoring_items(item_type);
---
c.说明
评分标准结构：
d.代码示例
---
{
"企业资质": {
"max_score": 10,
"criteria": "根据企业资质等级评分，一级资质10分，二级资质8分，三级资质5分"
},
"财务状况": {
"max_score": 10,
"criteria": "根据近3年财务报表，资产负债率≤60%得10分，60-70%得8分，70%以上得5分"
}
}
---
d.评标项目表 (t_evaluation_projects)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_evaluation_projects (
id BIGSERIAL PRIMARY KEY,
project_name VARCHAR(255) NOT NULL, -- 项目名称
rule_id BIGINT NOT NULL, -- 规则ID
status VARCHAR(20) NOT NULL DEFAULT 'draft', -- 状态
start_time TIMESTAMP, -- 开始时间
end_time TIMESTAMP, -- 结束时间
created_by BIGINT NOT NULL, -- 创建人ID
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
CONSTRAINT fk_projects_rule FOREIGN KEY (rule_id)
REFERENCES t_evaluation_rules(id)
);
-- 索引
CREATE INDEX idx_evaluation_projects_status ON t_evaluation_projects(status);
CREATE INDEX idx_evaluation_projects_rule ON t_evaluation_projects(rule_id);
---
e.评标记录表 (t_evaluation_records)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_evaluation_records (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL, -- 项目ID
doc_id BIGINT NOT NULL, -- 文档ID
supplier_id BIGINT, -- 供应商ID
item_id BIGINT NOT NULL, -- 评分项ID
score DECIMAL(5,2) NOT NULL, -- 得分
max_score DECIMAL(5,2) NOT NULL, -- 最高分
auto_scored BOOLEAN NOT NULL DEFAULT FALSE, -- 是否自动评分
scorer_id BIGINT, -- 评分人ID
score_reason TEXT, -- 评分理由
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
CONSTRAINT fk_records_project FOREIGN KEY (project_id)
REFERENCES t_evaluation_projects(id) ON DELETE CASCADE,
CONSTRAINT fk_records_doc FOREIGN KEY (doc_id)
REFERENCES t_documents(id) ON DELETE CASCADE,
CONSTRAINT fk_records_item FOREIGN KEY (item_id)
REFERENCES t_scoring_items(id) ON DELETE CASCADE
);
-- 索引
CREATE INDEX idx_evaluation_records_project ON t_evaluation_records(project_id);
CREATE INDEX idx_evaluation_records_doc ON t_evaluation_records(doc_id);
CREATE INDEX idx_evaluation_records_supplier ON t_evaluation_records(supplier_id);
CREATE INDEX idx_evaluation_records_item ON t_evaluation_records(item_id);
---
f.评标报告表 (t_evaluation_reports)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_evaluation_reports (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL, -- 项目ID
report_name VARCHAR(255) NOT NULL, -- 报告名称
report_type VARCHAR(50) NOT NULL, -- 报告类型（pdf/docx）
file_path VARCHAR(500) NOT NULL, -- 文件路径
file_size BIGINT NOT NULL, -- 文件大小
generated_by BIGINT NOT NULL, -- 生成人ID
generated_at TIMESTAMP NOT NULL, -- 生成时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
CONSTRAINT fk_reports_project FOREIGN KEY (project_id)
REFERENCES t_evaluation_projects(id) ON DELETE CASCADE
);
-- 索引
CREATE INDEX idx_evaluation_reports_project ON t_evaluation_reports(project_id);
---
g.用户表 (t_users)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_users (
id BIGSERIAL PRIMARY KEY,
username VARCHAR(100) NOT NULL UNIQUE, -- 用户名
email VARCHAR(255), -- 邮箱
full_name VARCHAR(255) NOT NULL, -- 姓名
role VARCHAR(50) NOT NULL, -- 角色
hashed_password VARCHAR(255) NOT NULL, -- 密码哈希
is_active BOOLEAN NOT NULL DEFAULT TRUE, -- 是否激活
last_login_at TIMESTAMP, -- 最后登录时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);
-- 索引
CREATE INDEX idx_users_username ON t_users(username);
CREATE INDEX idx_users_role ON t_users(role);
---
h.操作日志表 (t_audit_logs)
a.说明
表结构：
b.代码示例
---
CREATE TABLE t_audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL, -- 用户ID
action VARCHAR(100) NOT NULL, -- 操作类型
resource_type VARCHAR(50) NOT NULL, -- 资源类型
resource_id BIGINT, -- 资源ID
action_detail JSONB, -- 操作详情
ip_address VARCHAR(50), -- IP地址
user_agent TEXT, -- 用户代理
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
CONSTRAINT fk_audit_logs_user FOREIGN KEY (user_id)
REFERENCES t_users(id) ON DELETE CASCADE
);
-- 索引
CREATE INDEX idx_audit_logs_user ON t_audit_logs(user_id);
CREATE INDEX idx_audit_logs_action ON t_audit_logs(action);
CREATE INDEX idx_audit_logs_created ON t_audit_logs(created_at);
---
c.说明
---
b.ER 图设计
a.实体关系图
a.代码示例
---
┌─────────────┐
│ t_users │
└──────┬──────┘
│ 1
│
┌───┴────────────────────┐
│ │
┌──▼─────────┐ ┌───────▼────────┐
│t_documents │ │t_evaluation_ │
│ │ │ rules │
└────────────┘ └───────┬────────┘
│ 1
┌──────────┴────────────┐
│ │
┌──────▼────────┐ ┌───────▼─────────┐
│t_scoring_items│ │t_evaluation_ │
│ │ │ projects │
└───────┬───────┘ └───────┬─────────┘
│ │
┌───────────┴───────────────┐ │
│ │ │
┌─────▼────────┐ ┌───────▼─────┐ │
│t_evaluation│ │t_evaluation│ │
│ _records │ │ _reports │ │
└─────────────┘ └─────────────┘ │
│
│
┌──────────┴─────────┐
│ t_audit_logs │
└────────────────────┘
---
b.关系说明
a.说明
一对多关系：
b.表格数据
主表 从表 关系
t_users t_documents 一个用户可以上传多个文档
t_users t_evaluation_projects 一个用户可以创建多个评标项目
t_evaluation_rules t_scoring_items 一个规则包含多个评分项
t_evaluation_projects t_evaluation_records 一个项目包含多个评分记录
t_evaluation_projects t_evaluation_reports 一个项目可以生成多个报告
c.说明
多对多关系（通过中间表）：
d.表格数据
主表 关系表 从表
t_documents t_evaluation_records t_evaluation_projects
e.说明
---
c.API 接口设计
a.接口概述
a.说明
RESTful API 设计原则：
基础 URL：
b.代码示例
---
https://api.evaluation-system.com/v1
---
c.使用 HTTP 动词表示操作（GET/POST/PUT/DELETE）
d.使用名词表示资源
e.统一的响应格式
f.版本控制（通过 URL 或 Header）
b.文档管理接口
a.上传文档
a.说明
接口：
b.代码示例
---
POST /api/documents/upload
---
c.说明
请求：
d.代码示例
---
POST /api/documents/upload HTTP/1.1
Content-Type: multipart/form-data
------boundary=BOUNDARY
Content-Disposition: form-data; name="files"; filename="标书.pdf"
[文件内容]
------boundary=BOUNDARY--
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "上传成功",
"data": {
"task_id": "task_123456",
"status": "pending",
"uploaded_files": [
{
"doc_id": "doc_001",
"file_name": "标书.pdf",
"file_size": 5242880
}
]
}
}
---
b.查询文档列表
a.说明
接口：
b.代码示例
---
GET /api/documents?page=1&page_size=20&status=completed
---
c.说明
响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"total": 100,
"page": 1,
"page_size": 20,
"documents": [
{
"id": "doc_001",
"doc_name": "标书1.pdf",
"doc_type": "pdf",
"file_size": 5242880,
"page_count": 100,
"parse_status": "completed",
"upload_time": "2025-01-15T10:00:00Z"
}
]
}
}
---
c.获取文档详情
a.说明
接口：
b.代码示例
---
GET /api/documents/{doc_id}
---
c.说明
响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"id": "doc_001",
"doc_name": "标书1.pdf",
"doc_type": "pdf",
"file_size": 5242880,
"page_count": 100,
"parse_status": "completed",
"parse_result": {
"text": "提取的文本内容...",
"tables": [...],
"images": [...]
},
"upload_time": "2025-01-15T10:00:00Z"
}
}
---
c.评标规则接口
a.创建评标规则
a.说明
接口：
b.代码示例
---
POST /api/rules
---
c.说明
请求：
d.代码示例
---
{
"rule_name": "物资采购评标规则",
"rule_type": "物资采购",
"total_score": 100,
"project_type": "设备采购",
"description": "用于物资采购的评标规则",
"scoring_items": [
{
"item_name": "商务评分",
"item_type": "商务",
"weight": 0.3,
"max_score": 30,
"scoring_criteria": {
"企业资质": {
"max_score": 10,
"criteria": "根据企业资质等级评分"
}
},
"auto_scoring": false
}
]
}
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "创建成功",
"data": {
"rule_id": "rule_001",
"rule_name": "物资采购评标规则",
"created_at": "2025-01-15T10:00:00Z"
}
}
---
b.获取评标规则
a.说明
接口：
b.代码示例
---
GET /api/rules/{rule_id}
---
c.说明
响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"id": "rule_001",
"rule_name": "物资采购评标规则",
"rule_type": "物资采购",
"total_score": 100,
"scoring_items": [...]
}
}
---
d.智能评标接口
a.提交评标请求
a.说明
接口：
b.代码示例
---
POST /api/evaluations/submit
---
c.说明
请求：
d.代码示例
---
{
"project_name": "XX设备采购项目",
"rule_id": "rule_001",
"documents": [
{
"doc_id": "doc_001",
"supplier_name": "A公司",
"supplier_id": "supplier_001"
},
{
"doc_id": "doc_002",
"supplier_name": "B公司",
"supplier_id": "supplier_002"
}
]
}
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "评标任务已提交",
"data": {
"project_id": "project_001",
"status": "pending",
"estimated_time": 300
}
}
---
b.查询评标进度
a.说明
接口：
b.代码示例
---
GET /api/evaluations/{project_id}/status
---
c.说明
响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"project_id": "project_001",
"status": "processing",
"progress": 60,
"current_step": "技术参数评分中",
"completed_items": 3,
"total_items": 5
}
}
---
c.获取评标结果
a.说明
接口：
b.代码示例
---
GET /api/evaluations/{project_id}/results
---
c.说明
响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"project_id": "project_001",
"project_name": "XX设备采购项目",
"status": "completed",
"total_scores": [
{
"supplier_id": "supplier_001",
"supplier_name": "A公司",
"total_score": 92,
"rank": 1,
"scores": [
{
"item_id": "item_001",
"item_name": "商务评分",
"score": 28,
"max_score": 30
},
{
"item_id": "item_002",
"item_name": "技术评分",
"score": 46,
"max_score": 50
},
{
"item_id": "item_003",
"item_name": "价格评分",
"score": 18,
"max_score": 20
}
]
}
]
}
}
---
e.报告生成接口
a.生成评标报告
a.说明
接口：
b.代码示例
---
POST /api/reports/generate
---
c.说明
请求：
d.代码示例
---
{
"project_id": "project_001",
"template_id": "template_001",
"format": "pdf"
}
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "报告生成任务已提交",
"data": {
"report_id": "report_001",
"status": "pending",
"estimated_time": 30
}
}
---
b.下载报告
a.说明
接口：
b.代码示例
---
GET /api/reports/{report_id}/download
---
c.说明
响应：
d.成功：返回文件流
e.失败：返回 JSON 错误信息
f.认证授权接口
a.用户登录
a.说明
接口：
b.代码示例
---
POST /api/auth/login
---
c.说明
请求：
d.代码示例
---
{
"username": "admin",
"password": "password123"
}
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "登录成功",
"data": {
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "Bearer",
"expires_in": 3600,
"user": {
"id": 1,
"username": "admin",
"full_name": "管理员",
"role": "admin"
}
}
}
---
b.用户注销
a.说明
接口：
b.代码示例
---
POST /api/auth/logout
---
c.说明
请求头：
d.代码示例
---
Authorization: Bearer {access_token}
---
e.说明
响应：
f.代码示例
---
{
"code": 0,
"message": "注销成功"
}
---
g.说明
---
d.接口规范
a.统一响应格式
a.说明
成功响应：
b.代码示例
---
{
"code": 0,
"message": "操作成功",
"data": {...}
}
---
c.说明
错误响应：
d.代码示例
---
{
"code": 40001,
"message": "参数错误",
"errors": [
{
"field": "doc_name",
"message": "文档名称不能为空"
}
]
}
---
e.说明
错误码定义：
f.表格数据
错误码 说明
0 成功
40001 参数错误
40003 未授权
40004 禁止访问
40401 资源不存在
50001 服务器错误
b.认证机制
a.说明
JWT Token 认证：
b.代码示例
---
请求头：
Authorization: Bearer {access_token}
Token Payload:
{
"user_id": 1,
"username": "admin",
"role": "admin",
"exp": 1673776800
}
---
c.说明
Token 刷新机制：
d.Access Token 有效期：1 小时
e.Refresh Token 有效期：7 天
f.支持 Token 刷新
c.分页规范
a.说明
分页参数：
b.代码示例
---
?page=1&page_size=20&sort_by=created_at&order=desc
---
c.说明
分页响应：
d.代码示例
---
{
"code": 0,
"message": "查询成功",
"data": {
"total": 100,
"page": 1,
"page_size": 20,
"pages": 5,
"items": [...]
}
}
---
e.说明
---
e.数据模型定义
a.Pydantic 模型
a.说明
文档模型：
b.代码示例
---
from pydantic import BaseModel, Field
from typing import Optional
from datetime import datetime
class DocumentBase(BaseModel):
doc_name: str = Field(..., description="文档名称")
doc_type: str = Field(..., description="文档类型")
file_size: int = Field(..., description="文件大小")
class DocumentResponse(DocumentBase):
id: str
page_count: Optional[int] = None
parse_status: str = "pending"
upload_time: datetime
created_at: datetime
class ParseResult(BaseModel):
text: Optional[str] = None
tables: Optional[list] = None
images: Optional[list] = None
metadata: Optional[dict] = None
---
c.说明
评标规则模型：
d.代码示例
---
class ScoringItemCreate(BaseModel):
item_name: str = Field(..., description="评分项名称")
item_type: str = Field(..., description="类型")
weight: float = Field(..., ge=0, le=1, description="权重")
max_score: float = Field(..., gt=0, description="最高分")
scoring_criteria: dict = Field(..., description="评分标准")
auto_scoring: bool = False
model_name: Optional[str] = None
prompt_template: Optional[str] = None
class EvaluationRuleCreate(BaseModel):
rule_name: str = Field(..., description="规则名称")
rule_type: str = Field(..., description="规则类型")
total_score: float = Field(..., gt=0, description="总分")
project_type: Optional[str] = None
description: Optional[str] = None
scoring_items: list[ScoringItemCreate] = Field(..., description="评分项列表")
def validate_weights(self):
total_weight = sum(item.weight for item in self.scoring_items)
if abs(total_weight - 1.0) > 0.01:
raise ValueError("权重总和必须为1")
---
e.说明
评标结果模型：
f.代码示例
---
class ScoreItem(BaseModel):
item_id: str
item_name: str
score: float
max_score: float
class SupplierScore(BaseModel):
supplier_id: str
supplier_name: str
total_score: float
rank: int
scores: list[ScoreItem]
class EvaluationResult(BaseModel):
project_id: str
project_name: str
status: str
total_scores: list[SupplierScore]
---
b.数据库模型（SQLAlchemy）
a.代码示例
---
from sqlalchemy import Column, BigInteger, String, Text, Boolean, DateTime, DECIMAL, Integer, ForeignKey, JSONB
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import relationship
Base = declarative_base()
class Document(Base):
__tablename__ = 't_documents'
id = Column(BigInteger, primary_key=True)
doc_name = Column(String(255), nullable=False)
doc_type = Column(String(50), nullable=False)
file_path = Column(String(500), nullable=False)
file_size = Column(BigInteger, nullable=False)
page_count = Column(Integer)
upload_time = Column(DateTime, nullable=False)
upload_user_id = Column(BigInteger, nullable=False)
parse_status = Column(String(20), nullable=False, default='pending')
parse_result = Column(JSONB)
created_at = Column(DateTime, nullable=False, default=datetime.now)
updated_at = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)
# 关系
evaluation_records = relationship("EvaluationRecord", back_populates="document")
class EvaluationRule(Base):
__tablename__ = 't_evaluation_rules'
id = Column(BigInteger, primary_key=True)
rule_name = Column(String(255), nullable=False)
rule_type = Column(String(50), nullable=False)
total_score = Column(DECIMAL(5, 2), nullable=False)
project_type = Column(String(100))
description = Column(Text)
created_by = Column(BigInteger, nullable=False)
created_at = Column(DateTime, nullable=False, default=datetime.now)
updated_at = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)
# 关系
scoring_items = relationship("ScoringItem", back_populates="rule")
projects = relationship("EvaluationProject", back_populates="rule")
class ScoringItem(Base):
__tablename__ = 't_scoring_items'
id = Column(BigInteger, primary_key=True)
rule_id = Column(BigInteger, ForeignKey('t_evaluation_rules.id'), nullable=False)
item_name = Column(String(255), nullable=False)
item_type = Column(String(50), nullable=False)
weight = Column(DECIMAL(5, 4), nullable=False)
max_score = Column(DECIMAL(5, 2), nullable=False)
scoring_criteria = Column(JSONB, nullable=False)
auto_scoring = Column(Boolean, nullable=False, default=False)
model_name = Column(String(100))
prompt_template = Column(Text)
sort_order = Column(Integer, nullable=False)
created_at = Column(DateTime, nullable=False, default=datetime.now)
# 关系
rule = relationship("EvaluationRule", back_populates="scoring_items")
evaluation_records = relationship("EvaluationRecord", back_populates="scoring_item")
class EvaluationProject(Base):
__tablename__ = 't_evaluation_projects'
id = Column(BigInteger, primary_key=True)
project_name = Column(String(255), nullable=False)
rule_id = Column(BigInteger, ForeignKey('t_evaluation_rules.id'), nullable=False)
status = Column(String(20), nullable=False, default='draft')
start_time = Column(DateTime)
end_time = Column(DateTime)
created_by = Column(BigInteger, nullable=False)
created_at = Column(DateTime, nullable=False, default=datetime.now)
updated_at = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)
# 关系
rule = relationship("EvaluationRule", back_populates="projects")
records = relationship("EvaluationRecord", back_populates="project")
reports = relationship("EvaluationReport", back_populates="project")
class EvaluationRecord(Base):
__tablename__ = 't_evaluation_records'
id = Column(BigInteger, primary_key=True)
project_id = Column(BigInteger, ForeignKey('t_evaluation_projects.id'), nullable=False)
doc_id = Column(BigInteger, ForeignKey('t_documents.id'))
supplier_id = Column(BigInteger)
item_id = Column(BigInteger, ForeignKey('t_scoring_items.id'), nullable=False)
score = Column(DECIMAL(5, 2), nullable=False)
max_score = Column(DECIMAL(5, 2), nullable=False)
auto_scored = Column(Boolean, nullable=False, default=False)
scorer_id = Column(BigInteger)
score_reason = Column(Text)
created_at = Column(DateTime, nullable=False, default=datetime.now)
# 关系
project = relationship("EvaluationProject", back_populates="records")
document = relationship("Document", back_populates="evaluation_records")
scoring_item = relationship("ScoringItem", back_populates="evaluation_records")
class EvaluationReport(Base):
__tablename__ = 't_evaluation_reports'
id = Column(BigInteger, primary_key=True)
project_id = Column(BigInteger, ForeignKey('t_evaluation_projects.id'), nullable=False)
report_name = Column(String(255), nullable=False)
report_type = Column(String(50), nullable=False)
file_path = Column(String(500), nullable=False)
file_size = Column(BigInteger, nullable=False)
generated_by = Column(BigInteger, nullable=False)
generated_at = Column(DateTime, nullable=False)
created_at = Column(DateTime, nullable=False, default=datetime.now)
# 关系
project = relationship("EvaluationProject", back_populates="reports")
---
b.说明
---
f.接口文档示例
a.API 文档结构
a.说明
Swagger/OpenAPI 规范：
b.代码示例
---
openapi: 3.0.0
info:
title: 企业采购评标工具 API
version: 1.0.0
description: 企业采购评标工具后端 API 接口文档
servers:
- url: https://api.evaluation-system.com/v1
description: 生产环境
paths:
/documents/upload:
post:
summary: 上传文档
description: 上传标书文档（支持 PDF/Word/图片）
tags:
- 文档管理
requestBody:
required: true
content:
multipart/form-data:
schema:
type: object
properties:
files:
type: array
items:
type: string
format: binary
responses:
'200':
description: 上传成功
content:
application/json:
schema:
$ref: '#/components/schemas/UploadResponse'
components:
schemas:
UploadResponse:
type: object
properties:
code:
type: integer
example: 0
message:
type: string
example: "上传成功"
data:
type: object
properties:
task_id:
type: string
status:
type: string
---
c.说明
---
g.数据迁移与备份
a.数据迁移策略
a.说明
迁移场景：
b.表格数据
场景 策略
初期部署 初始化脚本创建表结构
版本升级 ALTER TABLE 逐步升级
数据导入 ETL 工具批量导入
c.说明
迁移脚本示例：
d.代码示例
---
from alembic import op
import sqlalchemy as sa
def upgrade():
op.create_table(
't_documents',
sa.Column('id', sa.BigInteger(), nullable=False),
sa.Column('doc_name', sa.String(255), nullable=False),
# ... 其他字段
)
---
b.备份策略
a.说明
备份范围：
b.表格数据
数据类型 备份频率 保留周期
数据库全量 每日凌晨 2:00 30 天
数据库增量 每小时 7 天
文件存储 每周日 90 天
配置文件 每次变更 永久
c.说明
恢复策略：
---
d.数据库：Point-in-Time Recovery (PITR)
e.文件存储：从备份恢复
f.配置文件：版本控制恢复
h.总结
a.数据设计总结
a.说明
设计特点：
b.✅ 关系型数据库设计，数据一致性保障
c.✅ 合理的索引设计，查询性能优化
d.✅ JSONB 字段存储复杂数据，灵活性强
e.✅ 完整的外键约束，数据完整性
b.接口设计总结
a.说明
设计特点：
b.✅ RESTful API 设计，符合最佳实践
c.✅ 统一的响应格式，易于处理
d.✅ JWT Token 认证，安全可靠
e.✅ 完善的错误码体系，问题定位清晰
c.技术栈总结
a.说明
后端技术：
接口文档：
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
b.Python + FastAPI
c.SQLAlchemy ORM
d.Celery 异步任务
e.PostgreSQL 数据库
f.Swagger/OpenAPI 自动生成
g.在线交互式文档
05.部署方案
a.部署架构总览
a.整体部署架构
a.代码示例
---
┌─────────────────────────────────────────────────────────────┐
│ 用户层 │
│ 企业内网用户 │
└───────────────────────────┬─────────────────────────────────┘
│ HTTPS (443)
┌───────────────────────────▼─────────────────────────────────┐
│ 负载均衡层 │
│ Nginx (主备部署) │
│ SSL 终止、反向代理 │
└───────────────────────────┬─────────────────────────────────┘
│ HTTP (8080/8081)
┌───────────────────────────▼─────────────────────────────────┐
│ 应用服务层 (Docker) │
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ 评标工具后端 │ │ Celery Worker │ │
│ │ (FastAPI) │ │ (异步任务) │ │
│ │ Port: 8080 │ │ │ │
│ └────────────────┘ └────────────────┘ │
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ 评标工具前端 │ │ NewAPI 网关 │ │
│ │ (Vue 3 + Nginx)│ │ Port: 3000 │ │
│ │ Port: 8081 │ │ │ │
│ └────────────────┘ └────────────────┘ │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 数据服务层 │
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ PostgreSQL │ │ Redis │ │
│ │ Port: 5432 │ │ Port: 6379 │ │
│ └────────────────┘ └────────────────┘ │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 昇腾 NPU 推理层 │
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ 昇腾 910B NPU 服务器 1 (主) │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Qwen2.5-72B (2x TP, 文本理解) │ │ │
│ │ │ Qwen2.5-VL-32B (1x/2x TP, 多模态) │ │ │
│ │ │ Qwen2-VL-7B (1x, 图像理解) │ │ │
│ │ │ PaddleOCR (1x, OCR识别) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ 推理引擎: MindSpeed / MindIE │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ 昇腾 910B NPU 服务器 2 (备) │ │
│ │ (按需配置，高可用方案) │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
---
b.部署模式
a.说明
基础部署模式（推荐）：
b.表格数据
组件 实例数 部署方式 说明
Nginx 1 (主) + 1 (备) Docker 主备 Keepalived
评标工具后端 2 Docker 负载均衡
评标工具前端 1 Docker 静态文件服务
Celery Worker 2-4 Docker 根据任务量调整
NewAPI 1 Docker 单实例即可
PostgreSQL 1 (主) + 1 (从) Docker 主从复制
Redis 1 (主) + 1 (从) Docker 哨兵模式
昇腾 NPU 推理 1-2 台 原生 MindSpeed/MindIE
c.说明
---
b.硬件配置方案
a.昇腾 NPU 服务器配置
a.说明
主服务器配置（推荐）：
b.表格数据
配置项 推荐值 说明
NPU 型号 昇腾 910B 最新一代
NPU 数量 4 卡 2x TP + 2x 单卡
单卡显存 64GB 或 128GB 优先 128GB
系统内存 512GB - 1TB DDR4/DDR5
系统盘 1TB SSD NVMe
数据盘 10TB+ SSD/NVMe 模型和数据存储
网卡 25GbE 双网卡
电源 冗余电源 1600W+
c.说明
备服务器配置（高可用）：
d.表格数据
配置项 推荐值 说明
NPU 型号 昇腾 910B 与主服务器一致
NPU 数量 2-4 卡 根据预算调整
系统内存 512GB 与主服务器一致
存储 10TB+ SSD 数据同步
b.应用服务器配置
a.表格数据
组件 CPU 内存 存储 网络
应用服务器 16核+ 64GB+ 500GB SSD 千兆
数据库服务器 32核+ 128GB+ 2TB SSD 万兆
综合部署 64核+ 256GB+ 2TB SSD 万兆
c.网络配置
a.说明
网络拓扑：
b.代码示例
---
┌─────────────┐
│ 核心交换机 │
│ (万兆) │
└──────┬──────┘
│
┌───┴────────────────────────┐
│ │
┌──▼──────────────┐ ┌────────▼─────────┐
│ NPU 服务器 1 │ │ NPU 服务器 2 │
│ (25GbE x 2) │ │ (25GbE x 2) │
└─────────────────┘ └──────────────────┘
│
┌──▼──────────────┐
│ 应用服务器 │
│ (千兆/万兆) │
└─────────────────┘
---
c.说明
网络要求：
d.表格数据
网络 用途 带宽 隔离
业务网络 用户访问 千兆 DMZ
AI 网络 模型推理 万兆/25G 独立 VLAN
存储网络 数据存储 万兆 独立 VLAN
管理网络 运维管理 千兆 独立 VLAN
e.说明
---
c.软件部署方案
a.操作系统配置
a.说明
推荐配置：
b.表格数据
配置项 推荐值
操作系统 Ubuntu 22.04 LTS / CentOS 8+
内核版本 5.15+
Python 版本 3.10+
Docker 版本 24.0+
Docker Compose 2.20+
c.说明
系统优化：
d.代码示例
---
# 内核参数优化
cat >> /etc/sysctl.conf << EOF
net.ipv4.ip_forward = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 1024
net.ipv4.tcp_tw_reuse = 1
vm.swappiness = 10
EOF
sysctl -p
---
b.昇腾 NPU 环境配置
a.说明
CANN 和驱动安装：
b.代码示例
---
# 1. 安装昇腾 NPU 驱动和 CANN
# 参考: https://www.hiascend.com/software/cann
# 2. 安装 torch-npu
pip install torch-npu
# 3. 验证安装
python -c "import torch; import torch_npu; print(torch_npu.npu.is_available())"
---
c.说明
MindSpeed/MindIE 安装：
d.代码示例
---
# MindSpeed (推荐)
pip install mindspeed
# 或 MindIE
# 按照昇腾官方文档安装
---
c.Docker Compose 部署配置
a.说明
完整 docker-compose.yml：
b.代码示例
---
version: '3.8'
services:
# Nginx 负载均衡
nginx:
image: nginx:1.25-alpine
container_name: evaluation-nginx
ports:
- "443:443"
- "80:80"
volumes:
- ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./nginx/ssl:/etc/nginx/ssl:ro
- ./nginx/logs:/var/log/nginx
depends_on:
- backend
- frontend
restart: unless-stopped
networks:
- evaluation-network
# PostgreSQL 数据库
postgres:
image: postgres:15-alpine
container_name: evaluation-postgres
environment:
POSTGRES_DB: evaluation_db
POSTGRES_USER: eval_user
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- postgres-data:/var/lib/postgresql/data
- ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
ports:
- "5432:5432"
restart: unless-stopped
networks:
- evaluation-network
healthcheck:
test: ["CMD-SHELL", "pg_isready -U eval_user"]
interval: 10s
timeout: 5s
retries: 5
# Redis 缓存
redis:
image: redis:7-alpine
container_name: evaluation-redis
command: redis-server --requirepass ${REDIS_PASSWORD}
volumes:
- redis-data:/data
ports:
- "6379:6379"
restart: unless-stopped
networks:
- evaluation-network
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
# FastAPI 后端
backend:
build:
context: ./backend
dockerfile: Dockerfile
container_name: evaluation-backend
environment:
DATABASE_URL: postgresql://eval_user:${POSTGRES_PASSWORD}@postgres:5432/evaluation_db
REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/0
NEWAPI_BASE_URL: http://newapi:3000
NEWAPI_API_KEY: ${NEWAPI_API_KEY}
JWT_SECRET: ${JWT_SECRET}
CELERY_BROKER_URL: redis://:${REDIS_PASSWORD}@redis:6379/1
volumes:
- ./uploads:/app/uploads
- ./reports:/app/reports
- ./backend/logs:/app/logs
ports:
- "8080:8080"
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
restart: unless-stopped
networks:
- evaluation-network
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 10s
retries: 3
# Celery Worker
celery-worker:
build:
context: ./backend
dockerfile: Dockerfile
container_name: evaluation-celery-worker
command: celery -A app.celery_app worker --loglevel=info --concurrency=4
environment:
DATABASE_URL: postgresql://eval_user:${POSTGRES_PASSWORD}@postgres:5432/evaluation_db
REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/0
NEWAPI_BASE_URL: http://newapi:3000
NEWAPI_API_KEY: ${NEWAPI_API_KEY}
CELERY_BROKER_URL: redis://:${REDIS_PASSWORD}@redis:6379/1
volumes:
- ./uploads:/app/uploads
- ./reports:/app/reports
depends_on:
- redis
- backend
restart: unless-stopped
networks:
- evaluation-network
# Celery Beat (定时任务)
celery-beat:
build:
context: ./backend
dockerfile: Dockerfile
container_name: evaluation-celery-beat
command: celery -A app.celery_app beat --loglevel=info
environment:
CELERY_BROKER_URL: redis://:${REDIS_PASSWORD}@redis:6379/1
depends_on:
- redis
restart: unless-stopped
networks:
- evaluation-network
# NewAPI 网关
newapi:
image: calciumion/new-api:latest
container_name: evaluation-newapi
environment:
SQL_DSN: postgresql://eval_user:${POSTGRES_PASSWORD}@postgres:5432/evaluation_db?sslmode=disable
REDIS_CONN_STRING: redis://:${REDIS_PASSWORD}@redis:6379/2
SESSION_SECRET: ${NEWAPI_SESSION_SECRET}
TOKEN: ${NEWAPI_ADMIN_TOKEN}
volumes:
- ./newapi/data:/data
- ./newapi/config.json:/data/config.json:ro
ports:
- "3000:3000"
depends_on:
- postgres
- redis
restart: unless-stopped
networks:
- evaluation-network
# 前端 (Vue 3)
frontend:
build:
context: ./frontend
dockerfile: Dockerfile
container_name: evaluation-frontend
volumes:
- ./frontend/nginx.conf:/etc/nginx/nginx.conf:ro
ports:
- "8081:80"
restart: unless-stopped
networks:
- evaluation-network
# Prometheus (监控)
prometheus:
image: prom/prometheus:latest
container_name: evaluation-prometheus
volumes:
- ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus-data:/prometheus
ports:
- "9090:9090"
restart: unless-stopped
networks:
- evaluation-network
# Grafana (可视化)
grafana:
image: grafana/grafana:latest
container_name: evaluation-grafana
environment:
GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_PASSWORD}
volumes:
- grafana-data:/var/lib/grafana
- ./monitoring/grafana/dashboards:/etc/grafana/provisioning/dashboards:ro
ports:
- "3001:3000"
restart: unless-stopped
networks:
- evaluation-network
volumes:
postgres-data:
redis-data:
prometheus-data:
grafana-data:
networks:
evaluation-network:
driver: bridge
---
c.说明
环境变量配置 (.env)：
d.代码示例
---
# 数据库
POSTGRES_PASSWORD=your_secure_password_here
# Redis
REDIS_PASSWORD=your_redis_password_here
# JWT
JWT_SECRET=your_jwt_secret_here_64_chars_minimum
# NewAPI
NEWAPI_API_KEY=sk-your-newapi-api-key
NEWAPI_SESSION_SECRET=your_session_secret_here
NEWAPI_ADMIN_TOKEN=your_admin_token_here
# Grafana
GRAFANA_PASSWORD=admin_change_me
---
d.Nginx 配置
a.说明
nginx/nginx.conf：
b.代码示例
---
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# Gzip 压缩
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml text/javascript
application/json application/javascript application/xml+rss
application/rss+xml font/truetype font/opentype
application/vnd.ms-fontobject image/svg+xml;
# 上游服务器
upstream backend_servers {
least_conn;
server backend:8080 max_fails=3 fail_timeout=30s;
keepalive 32;
}
# HTTP 重定向到 HTTPS
server {
listen 80;
server_name _;
return 301 https://$server_name$request_uri;
}
# HTTPS 主服务
server {
listen 443 ssl http2;
server_name _;
# SSL 证书
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# 安全头
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
# 客户端上传大小限制
client_max_body_size 200M;
client_body_buffer_size 128k;
# 前端静态文件
location / {
proxy_pass http://frontend:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# 后端 API
location /api/ {
proxy_pass http://backend_servers/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket 支持
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# 超时设置
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
}
# 健康检查
location /health {
access_log off;
return 200 "healthy\n";
add_header Content-Type text/plain;
}
}
}
---
c.说明
---
d.部署流程
a.部署前准备
a.说明
1.硬件检查清单：
2.软件准备：
3.配置文件准备：
b.[ ] 昇腾 NPU 服务器安装到位
c.[ ] 应用服务器准备就绪
d.[ ] 网络连通性验证
e.[ ] 存储空间充足
f.[ ] 操作系统安装完成
g.[ ] Docker 和 Docker Compose 安装
h.[ ] Git 客户端安装
i.[ ] SSL 证书准备
j.[ ] docker-compose.yml
k.[ ] .env 环境变量文件
l.[ ] nginx/nginx.conf
m.[ ] SSL 证书文件
b.部署步骤
a.说明
步骤 1: 昇腾 NPU 环境部署
b.代码示例
---
# 1. 安装昇腾驱动和 CANN
# (参考昇腾官方文档)
# 2. 验证 NPU 可用性
npu-smi info
# 3. 安装 Python 依赖
pip install torch-npu mindspeed
# 4. 部署模型 (以 vLLM 为例)
# Qwen2.5-72B (2x TP)
vllm serve "Qwen/Qwen2.5-72B-Instruct" \
--tensor-parallel-size 2 \
--dtype fp16 \
--max-model-len 131072 \
--host 0.0.0.0 \
--port 8001
# Qwen2.5-VL-32B
vllm serve "Qwen/Qwen2.5-VL-32B-Instruct" \
--dtype fp16 \
--max-model-len 131072 \
--host 0.0.0.0 \
--port 8002
# Qwen2-VL-7B
vllm serve "Qwen/Qwen2-VL-7B-Instruct" \
--dtype fp16 \
--max-model-len 32768 \
--host 0.0.0.0 \
--port 8003
---
c.说明
步骤 2: 启动 Docker 服务
d.代码示例
---
# 1. 克隆项目代码
git clone <repository-url> evaluation-tool
cd evaluation-tool
# 2. 创建必要目录
mkdir -p nginx/ssl uploads reports backend/logs newapi/data monitoring
# 3. 复制环境变量模板
cp .env.example .env
# 编辑 .env 文件，设置密码和密钥
# 4. 生成 SSL 证书 (自签名示例)
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout nginx/ssl/key.pem \
-out nginx/ssl/cert.pem
# 5. 启动服务
docker-compose up -d
# 6. 查看日志
docker-compose logs -f
---
e.说明
步骤 3: 初始化数据库
f.代码示例
---
# 1. 运行数据库迁移
docker-compose exec backend alembic upgrade head
# 2. 创建初始管理员用户
docker-compose exec backend python -m app.create_admin_user
# 3. 验证数据库
docker-compose exec postgres psql -U eval_user -d evaluation_db -c "\dt"
---
g.说明
步骤 4: 配置 NewAPI
h.代码示例
---
# 1. 访问 NewAPI 管理界面
# http://<server-ip>:3000
# 2. 添加模型渠道
# - Qwen2.5-72B: http://<npu-server-ip>:8001
# - Qwen2.5-VL-32B: http://<npu-server-ip>:8002
# - Qwen2-VL-7B: http://<npu-server-ip>:8003
# 3. 创建 API Token
# 复制生成的 Token 到 .env 文件的 NEWAPI_API_KEY
---
i.说明
步骤 5: 验证部署
j.代码示例
---
# 1. 检查服务状态
docker-compose ps
# 2. 健康检查
curl https://<server-ip>/health
# 3. 访问前端
# https://<server-ip>
# 4. 访问监控
# Grafana: http://<server-ip>:3001
# Prometheus: http://<server-ip>:9090
---
c.高可用部署
a.说明
主备部署方案：
1.数据库主从复制：
b.代码示例
---
# docker-compose-ha.yml
postgres-master:
image: postgres:15-alpine
environment:
POSTGRES_REPLICATION_USER: replicator
POSTGRES_REPLICATION_PASSWORD: ${REPLICATION_PASSWORD}
volumes:
- postgres-master-data:/var/lib/postgresql/data
postgres-slave:
image: postgres:15-alpine
environment:
POSTGRES_MASTER_HOST: postgres-master
POSTGRES_REPLICATION_USER: replicator
POSTGRES_REPLICATION_PASSWORD: ${REPLICATION_PASSWORD}
PGDATA: /var/lib/postgresql/data/pgdata
volumes:
- postgres-slave-data:/var/lib/postgresql/data
---
c.说明
2.Redis 哨兵模式：
d.代码示例
---
redis-sentinel:
image: redis:7-alpine
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./redis/sentinel.conf:/etc/redis/sentinel.conf:ro
---
e.说明
3.Nginx 主备 (Keepalived)：
f.代码示例
---
# 主服务器
apt-get install keepalived
cat > /etc/keepalived/keepalived.conf << EOF
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.1.100
}
}
EOF
---
g.说明
---
e.监控与运维
a.监控方案
a.说明
Prometheus 配置 (monitoring/prometheus.yml)：
b.代码示例
---
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'backend'
static_configs:
- targets: ['backend:8080']
metrics_path: '/metrics'
- job_name: 'postgres'
static_configs:
- targets: ['postgres:5432']
- job_name: 'redis'
static_configs:
- targets: ['redis:6379']
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
---
c.说明
Grafana 仪表板：
d.系统资源监控
e.应用性能监控
f.数据库性能监控
g.业务指标监控
b.日志管理
a.说明
日志配置：
b.代码示例
---
# backend/app/logging_config.py
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'standard': {
'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s'
},
},
'handlers': {
'file': {
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/app/logs/app.log',
'maxBytes': 10485760, # 10MB
'backupCount': 10,
'formatter': 'standard',
},
},
'root': {
'handlers': ['file'],
'level': 'INFO',
},
}
---
c.备份策略
a.说明
数据库备份：
b.代码示例
---
# 每日备份脚本
#!/bin/bash
DATE=$(date +%Y%m%d)
BACKUP_DIR="/backup/postgres"
docker-compose exec -T postgres pg_dump -U eval_user evaluation_db | gzip > $BACKUP_DIR/evaluation_db_$DATE.sql.gz
# 保留最近 30 天备份
find $BACKUP_DIR -name "evaluation_db_*.sql.gz" -mtime +30 -delete
---
c.说明
文件备份：
---
d.上传文件：每日同步到备份服务器
e.报告文件：保留 90 天
f.性能优化
a.应用层优化
a.表格数据
优化项 方案
数据库连接池 SQLAlchemy 连接池优化
Redis 缓存 热点数据缓存
异步任务 Celery 并发优化
静态资源 CDN 加速
b.数据库优化
a.代码示例
---
-- 索引优化
CREATE INDEX idx_documents_project_id ON t_documents(project_id);
CREATE INDEX idx_evaluations_project_id ON t_evaluation_records(project_id);
CREATE INDEX idx_audit_logs_user_id ON t_audit_logs(user_id);
-- 分区表 (按月分区)
CREATE TABLE t_evaluation_records_202501 PARTITION OF t_evaluation_records
FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');
---
c.NPU 推理优化
a.表格数据
优化项 方案
模型量化 INT8/FP16 量化
批处理 动态批处理
KV Cache 优化 KV Cache 大小
并发控制 限制并发请求数
b.说明
---
g.故障处理
a.常见问题
a.表格数据
问题 症状 解决方案
NPU 不可用 模型调用失败 检查 npu-smi info，重启推理服务
数据库连接失败 API 500 错误 检查 PostgreSQL 状态，重启容器
内存不足 OOM 错误 调整 Docker 内存限制
磁盘空间不足 上传失败 清理日志和临时文件
b.应急预案
a.说明
服务降级：
数据恢复：
1.从最近的备份恢复数据库
2.恢复上传文件
3.验证数据完整性
---
b.关闭非核心功能
c.限制并发数
d.启用只读模式
h.总结
a.部署架构总结
a.说明
部署模式：
核心组件：
b.Docker 容器化部署
c.主备高可用架构
d.水平可扩展
e.Nginx：负载均衡、SSL 终止
f.FastAPI：应用服务
g.Celery：异步任务处理
h.NewAPI：模型网关
i.昇腾 NPU：AI 推理
b.部署检查清单
a.说明
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
b.[ ] 硬件资源准备完成
c.[ ] 操作系统和 Docker 安装完成
d.[ ] 昇腾 NPU 环境配置完成
e.[ ] 模型部署和测试完成
f.[ ] Docker Compose 服务启动成功
g.[ ] 数据库初始化完成
h.[ ] NewAPI 配置完成
i.[ ] Nginx 配置和 SSL 证书部署完成
j.[ ] 监控和日志配置完成
k.[ ] 备份策略配置完成
l.[ ] 功能测试通过
m.[ ] 性能测试通过
06.安全与合规
a.安全架构总览
a.安全层次
a.代码示例
---
┌─────────────────────────────────────────────────────────────┐
│ 网络安全层 │
│ • 网络隔离 (VLAN) │
│ • 防火墙规则 │
│ • DDoS 防护 │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 接入安全层 │
│ • SSL/TLS 加密 │
│ • 负载均衡安全 │
│ • WAF 防护 │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 应用安全层 │
│ • 身份认证 (JWT) │
│ • 权限控制 (RBAC) │
│ • 会话管理 │
│ • 输入验证 │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 数据安全层 │
│ • 数据加密 │
│ • 敏感信息脱敏 │
│ • 数据备份 │
│ • 数据审计 │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ 运维安全层 │
│ • 操作日志审计 │
│ • 异常告警 │
│ • 安全扫描 │
│ • 应急响应 │
└─────────────────────────────────────────────────────────────┘
---
b.安全目标
a.表格数据
安全目标 具体要求
机密性 数据仅授权人员可访问
完整性 数据不被篡改
可用性 服务持续可用 (99%+)
可追溯 所有操作可审计
合规性 符合中国法律法规
b.说明
---
b.网络安全
a.网络隔离
a.说明
VLAN 划分：
b.表格数据
VLAN 用途 访问控制
VLAN 10 用户访问 DMZ，仅开放 443 端口
VLAN 20 应用服务 仅允许来自 VLAN 10 和 30 的流量
VLAN 30 数据存储 仅允许来自 VLAN 20 的流量
VLAN 40 AI 推理 仅允许来自 VLAN 20 的流量
VLAN 99 运维管理 严格限制访问
c.说明
网络分段图：
d.代码示例
---
┌─────────────────────────────────────────────────────────┐
│ 企业内网用户 │
│ (VLAN 10 - DMZ) │
└────────────────────┬────────────────────────────────────┘
│ 仅 HTTPS (443)
┌────────────────────▼────────────────────────────────────┐
│ 负载均衡 (Nginx) │
│ (VLAN 10) │
└────────────────────┬────────────────────────────────────┘
│ HTTP (8080)
┌────────────────────▼────────────────────────────────────┐
│ 应用服务 (FastAPI) │
│ (VLAN 20) │
└──┬──────────────────┬──────────────────┬───────────────┘
│ │ │
│ │ │
┌──▼──────────┐ ┌────▼──────────┐ ┌──▼──────────────┐
│ PostgreSQL │ │ Redis │ │ NewAPI 网关 │
│ (VLAN 30) │ │ (VLAN 30) │ │ (VLAN 20) │
└─────────────┘ └───────────────┘ └──┬───────────────┘
│
┌──────▼──────────────┐
│ 昇腾 NPU 推理 │
│ (VLAN 40) │
└─────────────────────┘
---
b.防火墙规则
a.说明
入站规则：
b.代码示例
---
# 仅允许必要的端口
# 允许 HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# 允许内网 SSH (运维管理)
iptables -A INPUT -s 192.168.0.0/16 -p tcp --dport 22 -j ACCEPT
# 拒绝其他所有入站流量
iptables -A INPUT -j DROP
---
c.说明
出站规则：
d.代码示例
---
# 仅允许必要的出站连接
# 允许 DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
# 允许 NTP (时间同步)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
# 拒绝其他出站流量
# 注意: 如果需要访问外部 API，需要添加相应规则
---
c.DDoS 防护
a.说明
Nginx 限流配置：
b.代码示例
---
# 限制请求频率
http {
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
# ...
}
}
}
---
c.说明
---
c.身份认证与授权
a.身份认证
a.说明
JWT 认证流程：
b.代码示例
---
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 客户端 │ │ 后端 │ │ 数据库 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
│ 1. POST /api/auth/login │ │
│ {username, password} │ │
├───────────────────────────>│ │
│ │ 2. 验证用户 │
│ ├───────────────────────────>│
│ │<───────────────────────────┤
│ 3. 返回 JWT Token │ │
│<───────────────────────────┤ │
│ │ │
│ 4. GET /api/documents │ │
│ Authorization: Bearer xxx │ │
├───────────────────────────>│ │
│ 5. 验证 Token │ │
│ 6. 返回数据 │ │
│<───────────────────────────┤ │
---
c.说明
JWT Token 结构：
d.代码示例
---
# Token Payload 示例
{
"sub": "user_123", # 用户 ID
"username": "admin", # 用户名
"role": "admin", # 角色
"permissions": [ # 权限列表
"document:read",
"document:write",
"evaluation:execute"
],
"iat": 1704067200, # 签发时间
"exp": 1704153600 # 过期时间
}
---
e.说明
认证配置：
f.代码示例
---
# backend/app/core/security.py
from datetime import datetime, timedelta
from jose import JWTError, jwt
from passlib.context import CryptContext
# JWT 配置
SECRET_KEY = os.getenv("JWT_SECRET")
ALGORITHM = "HS256"
ACCESS_TOKEN_EXPIRE_MINUTES = 480 # 8 小时
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
def verify_password(plain_password: str, hashed_password: str) -> bool:
"""验证密码"""
return pwd_context.verify(plain_password, hashed_password)
def get_password_hash(password: str) -> str:
"""密码哈希"""
return pwd_context.hash(password)
def create_access_token(data: dict) -> str:
"""创建 JWT Token"""
to_encode = data.copy()
expire = datetime.utcnow() + timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
to_encode.update({"exp": expire})
encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
return encoded_jwt
---
b.授权控制 (RBAC)
a.说明
角色定义：
b.表格数据
角色 说明 权限
超级管理员 系统管理员 所有权限
评标管理员 评标项目管理 评标管理权限
评标专家 参与评标 评标执行权限
普通用户 查看权限 只读权限
c.说明
权限矩阵：
d.表格数据
权限 超级管理员 评标管理员 评标专家 普通用户
用户管理 ✅ ❌ ❌ ❌
规则配置 ✅ ✅ ❌ ❌
文档上传 ✅ ✅ ✅ ❌
评标执行 ✅ ✅ ✅ ❌
报告生成 ✅ ✅ ✅ ❌
结果查看 ✅ ✅ ✅ ✅
系统配置 ✅ ❌ ❌ ❌
e.说明
权限检查中间件：
f.代码示例
---
# backend/app/api/deps.py
from fastapi import Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
security = HTTPBearer()
async def get_current_user(
credentials: HTTPAuthorizationCredentials = Depends(security)
) -> User:
"""获取当前用户"""
token = credentials.credentials
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
user_id: str = payload.get("sub")
if user_id is None:
raise HTTPException(status_code=401, detail="无效的 Token")
except JWTError:
raise HTTPException(status_code=401, detail="Token 验证失败")
user = await get_user_by_id(user_id)
if user is None:
raise HTTPException(status_code=401, detail="用户不存在")
return user
async def require_permission(permission: str):
"""权限检查装饰器"""
async def check_permission(user: User = Depends(get_current_user)):
if permission not in user.permissions:
raise HTTPException(
status_code=403,
detail=f"缺少权限: {permission}"
)
return user
return check_permission
# 使用示例
@router.post("/api/rules")
async def create_rule(
rule_data: RuleCreate,
user: User = Depends(require_permission("rule:create"))
):
"""创建评标规则 (需要 rule:create 权限)"""
# ...
---
c.会话管理
a.说明
会话配置：
b.代码示例
---
# 会话超时配置
SESSION_TIMEOUT_MINUTES = 480 # 8 小时
IDLE_TIMEOUT_MINUTES = 60 # 1 小时无操作自动登出
# Token 刷新机制
REFRESH_TOKEN_EXPIRE_DAYS = 7 # 刷新令牌 7 天有效
---
c.说明
安全措施：
---
d.Token 存储在 HttpOnly Cookie 中 (防止 XSS)
e.支持 Token 刷新机制
f.强制登出功能
g.异常登录检测
d.数据安全
a.数据加密
a.说明
传输加密：
存储加密：
b.表格数据
数据类型 加密方式 说明
用户密码 BCrypt 单向哈希，salt 自动处理
敏感配置 AES-256 环境变量加密存储
上传文档 可选 支持文件加密存储
数据库 可选 PostgreSQL 透明数据加密 (TDE)
c.说明
密码加密示例：
d.代码示例
---
# backend/app/core/security.py
import bcrypt
def hash_password(password: str) -> str:
"""密码哈希"""
salt = bcrypt.gensalt()
return bcrypt.hashpw(password.encode('utf-8'), salt).decode('utf-8')
def verify_password(password: str, hashed: str) -> bool:
"""验证密码"""
return bcrypt.checkpw(password.encode('utf-8'), hashed.encode('utf-8'))
---
e.说明
敏感配置加密：
f.代码示例
---
# backend/app/core/config.py
from cryptography.fernet import Fernet
class EncryptedSettings:
"""加密配置管理"""
def __init__(self, key: str):
self.cipher = Fernet(key.encode())
def encrypt(self, value: str) -> str:
return self.cipher.encrypt(value.encode()).decode()
def decrypt(self, encrypted: str) -> str:
return self.cipher.decrypt(encrypted.encode()).decode()
---
g.HTTPS (TLS 1.2+) 强制使用
h.禁用弱加密算法
i.HSTS 启用
b.敏感信息脱敏
a.说明
日志脱敏：
b.代码示例
---
# backend/app/utils/logging.py
import re
def mask_sensitive_data(log_message: str) -> str:
"""日志脱敏"""
# 脱敏手机号
log_message = re.sub(r'(\d{3})\d{4}(\d{4})', r'\1****\2', log_message)
# 脱敏身份证号
log_message = re.sub(r'(\d{6})\d{8}(\d{4})', r'\1********\2', log_message)
# 脱敏 Token
log_message = re.sub(r'(Bearer|Token)\s+[A-Za-z0-9\-._~+/]+=*', r'\1 ****', log_message)
return log_message
---
c.说明
API 响应脱敏：
d.代码示例
---
# backend/app/api/models.py
from pydantic import BaseModel, Field
class UserResponse(BaseModel):
"""用户响应 (脱敏)"""
id: int
username: str
email: str = Field(..., regex=r'^[^@]+@[^@]+\.[^@]+$')
phone: str = Field(..., alias="phone_masked") # 脱敏手机号
@classmethod
def from_db_model(cls, user: User):
return cls(
id=user.id,
username=user.username,
email=user.email,
phone_masked=mask_phone(user.phone)
)
def mask_phone(phone: str) -> str:
"""脱敏手机号"""
return phone[:3] + "****" + phone[-4:]
---
c.数据备份
a.说明
备份策略：
b.表格数据
数据类型 备份频率 保留期 存储位置
数据库 每日 30 天 异地备份服务器
上传文档 每日 90 天 异地备份服务器
配置文件 实时同步 永久 版本控制
日志文件 每周 90 天 日志服务器
c.说明
备份脚本：
d.代码示例
---
#!/bin/bash
# /usr/local/bin/backup.sh
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup"
REMOTE_BACKUP="user@backup-server:/remote-backup"
# 1. 数据库备份
docker-compose exec -T postgres pg_dump -U eval_user evaluation_db | \
gzip > $BACKUP_DIR/postgres/evaluation_db_$DATE.sql.gz
# 2. 上传文档备份
rsync -avz --delete ./uploads/ $BACKUP_DIR/uploads/
# 3. 配置文件备份
tar -czf $BACKUP_DIR/config/config_$DATE.tar.gz ./docker-compose.yml .env ./nginx/
# 4. 传输到远程备份服务器
rsync -avz --delete $BACKUP_DIR/ $REMOTE_BACKUP/
# 5. 清理旧备份
find $BACKUP_DIR -name "*.sql.gz" -mtime +30 -delete
find $BACKUP_DIR -name "config_*.tar.gz" -mtime +90 -delete
---
e.说明
恢复流程：
f.代码示例
---
# 数据库恢复
gunzip < evaluation_db_20250115.sql.gz | \
docker-compose exec -T postgres psql -U eval_user evaluation_db
# 文档恢复
rsync -avz $REMOTE_BACKUP/uploads/ ./uploads/
---
d.数据审计
a.说明
审计日志表设计：
b.代码示例
---
CREATE TABLE t_audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
username VARCHAR(50) NOT NULL,
action VARCHAR(50) NOT NULL, -- 操作类型
resource_type VARCHAR(50), -- 资源类型
resource_id BIGINT, -- 资源 ID
details JSONB, -- 操作详情
ip_address INET NOT NULL,
user_agent TEXT,
status VARCHAR(20) NOT NULL, -- success/failure
error_message TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW()
);
-- 索引优化
CREATE INDEX idx_audit_logs_user_id ON t_audit_logs(user_id);
CREATE INDEX idx_audit_logs_action ON t_audit_logs(action);
CREATE INDEX idx_audit_logs_created_at ON t_audit_logs(created_at DESC);
---
c.说明
审计中间件：
d.代码示例
---
# backend/app/middleware/audit.py
from fastapi import Request
import time
async def audit_middleware(request: Request, call_next):
"""审计日志中间件"""
start_time = time.time()
# 记录请求
log_data = {
"method": request.method,
"url": str(request.url),
"user_agent": request.headers.get("user-agent"),
"ip": request.client.host,
}
# 执行请求
response = await call_next(request)
# 记录响应
process_time = time.time() - start_time
log_data.update({
"status_code": response.status_code,
"process_time": process_time,
})
# 保存审计日志
await save_audit_log(log_data)
return response
async def save_audit_log(log_data: dict):
"""保存审计日志到数据库"""
# 实现异步保存逻辑
pass
---
e.说明
关键操作审计：
---
f.用户登录/登出
g.权限变更
h.评标规则修改
i.评标执行
j.报告生成
k.文档上传/删除
l.系统配置变更
e.应用安全
a.输入验证
a.说明
Pydantic 验证：
b.代码示例
---
from pydantic import BaseModel, Field, validator
class DocumentUpload(BaseModel):
"""文档上传验证"""
file_name: str = Field(..., min_length=1, max_length=255)
file_size: int = Field(..., gt=0, le=200 * 1024 * 1024) # 最大 200MB
file_type: str = Field(..., regex=r'^(pdf|docx|jpg|png|tiff)$')
project_id: int = Field(..., gt=0)
@validator('file_name')
def validate_filename(cls, v):
"""文件名验证，防止路径遍历攻击"""
if '..' in v or v.startswith('/'):
raise ValueError('非法的文件名')
return v
---
c.说明
SQL 注入防护：
d.代码示例
---
# 使用 SQLAlchemy ORM (自动防 SQL 注入)
from sqlalchemy.orm import Session
def get_documents(db: Session, project_id: int):
"""ORM 方式 (安全)"""
return db.query(Document).filter(Document.project_id == project_id).all()
# 避免原生 SQL (如必须使用，需要参数化查询)
def get_documents_raw(db: Session, project_id: int):
"""原生 SQL (参数化查询)"""
query = text("SELECT * FROM t_documents WHERE project_id = :project_id")
return db.execute(query, {"project_id": project_id}).fetchall()
---
e.说明
XSS 防护：
f.代码示例
---
from markupsafe import escape
def sanitize_input(user_input: str) -> str:
"""HTML 转义"""
return escape(user_input)
# 前端 Vue 3 自动转义
// {{ userInput }} 自动转义
// v-html 谨慎使用，仅用于可信内容
---
b.文件上传安全
a.说明
文件验证：
b.代码示例
---
# backend/app/services/file_upload.py
import magic
import os
ALLOWED_MIME_TYPES = {
'application/pdf',
'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
'image/jpeg',
'image/png',
'image/tiff',
}
MAX_FILE_SIZE = 200 * 1024 * 1024 # 200MB
def validate_uploaded_file(file_content: bytes, filename: str) -> bool:
"""验证上传文件"""
# 1. 文件大小检查
if len(file_content) > MAX_FILE_SIZE:
raise ValueError("文件大小超过限制")
# 2. MIME 类型检查
mime = magic.from_buffer(file_content, mime=True)
if mime not in ALLOWED_MIME_TYPES:
raise ValueError(f"不支持的文件类型: {mime}")
# 3. 文件扩展名检查
ext = os.path.splitext(filename)[1].lower()
if ext not in ['.pdf', '.docx', '.jpg', '.jpeg', '.png', '.tiff']:
raise ValueError("不支持的文件扩展名")
# 4. 文件名安全检查
if '..' in filename or filename.startswith('/'):
raise ValueError("非法的文件名")
return True
---
c.说明
文件存储隔离：
d.代码示例
---
# backend/app/config.py
import os
# 上传目录配置
UPLOAD_BASE_DIR = "/app/uploads"
# 按项目隔离存储
def get_upload_dir(project_id: int) -> str:
"""获取项目的上传目录"""
project_dir = os.path.join(UPLOAD_BASE_DIR, f"project_{project_id}")
os.makedirs(project_dir, exist_ok=True)
return project_dir
# 生成安全的文件名
def generate_safe_filename(original_filename: str) -> str:
"""生成安全的文件名"""
ext = os.path.splitext(original_filename)[1]
import uuid
return f"{uuid.uuid4().hex}{ext}"
---
e.说明
病毒扫描：
f.代码示例
---
# 安装 ClamAV
apt-get install clamav clamav-daemon
# Python 集成
pip install pyclamd
# 扫描上传文件
import pyclamd
def scan_file(file_path: str) -> bool:
"""扫描病毒"""
cd = pyclamd.ClamdAgnostic()
if cd.ping():
result = cd.scan_file(file_path)
if result and result[file_path][0] == 'FOUND':
raise ValueError("文件包含病毒")
return True
---
c.API 安全
a.说明
速率限制：
b.代码示例
---
# backend/app/api/rate_limit.py
from slowapi import Limiter
from slowapi.util import get_remote_address
limiter = Limiter(key_func=get_remote_address)
# 应用到路由
@router.post("/api/documents/upload")
@limiter.limit("10/minute") # 每分钟最多 10 次上传
async def upload_document(
request: Request,
file: UploadFile
):
# ...
---
c.说明
CORS 配置：
d.代码示例
---
# backend/app/main.py
from fastapi.middleware.cors import CORSMiddleware
app.add_middleware(
CORSMiddleware,
allow_origins=["https://your-domain.com"], # 仅允许指定域名
allow_credentials=True,
allow_methods=["GET", "POST", "PUT", "DELETE"],
allow_headers=["*"],
)
---
e.说明
---
f.运维安全
a.安全监控
a.说明
监控指标：
b.表格数据
类别 监控项 告警阈值
安全事件 登录失败次数 5 次/分钟
安全事件 异常 IP 访问 自动封禁
性能 API 响应时间 > 3 秒
可用性 服务可用率 < 99%
资源 CPU 使用率 > 80% 持续 5 分钟
资源 内存使用率 > 85%
c.说明
告警配置：
d.代码示例
---
# monitoring/alerts.yml
groups:
- name: security_alerts
rules:
- alert: HighFailedLoginRate
expr: rate(login_failures_total[5m]) > 0.1
annotations:
summary: "登录失败率过高"
description: "5 分钟内登录失败率超过 0.1 次/秒"
- alert: UnauthorizedAPICalls
expr: rate(http_requests_total{status="401"}[5m]) > 10
annotations:
summary: "未授权 API 调用过多"
---
b.安全扫描
a.说明
定期扫描：
Docker 镜像扫描：
b.代码示例
---
# 使用 Trivy 扫描
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image your-image:tag
# 集成到 CI/CD
trivy image --exit-code 1 --severity HIGH,CRITICAL your-image:tag
---
c.每周进行漏洞扫描 (Nessus/OpenVAS)
d.每月进行渗透测试
e.代码安全扫描 (SonarQube/Semgrep)
c.应急响应
a.说明
安全事件分类：
b.表格数据
级别 描述 响应时间
P0 - 严重 数据泄露、系统被入侵 1 小时内
P1 - 高 服务不可用 4 小时内
P2 - 中 功能异常 1 天内
P3 - 低 非关键问题 3 天内
c.说明
应急响应流程：
d.代码示例
---
1. 检测和确认
├── 监控告警
├── 用户报告
└── 确认事件
2. 遏制
├── 隔离受影响系统
├── 停止可疑服务
└── 保留日志证据
3. 根除
├── 分析根因
├── 清除恶意代码
└── 修复漏洞
4. 恢复
├── 恢复系统
├── 验证功能
└── 恢复服务
5. 总结
├── 事件报告
├── 改进措施
└── 预防措施
---
e.说明
---
g.法律合规
a.中国法律法规合规
a.说明
主要法律法规：
b.表格数据
法律法规 适用范围 关键要求
《网络安全法》 网络运营者 数据安全、个人信息保护、网络安全等级保护
《数据安全法》 数据处理者 数据分类分级、数据风险评估
《个人信息保护法》 个人信息处理者 同意原则、最小必要、目的限制
《密码法》 密码使用 核心密码、普通密码、商用密码管理
b.网络安全等级保护
a.说明
等级保护二级要求：
b.表格数据
类别 要求 实施方案
身份鉴别 双因素认证 用户名 + 密码 + 可选 MFA
访问控制 最小权限原则 RBAC 权限控制
安全审计 完整日志记录 审计日志保留 6 个月以上
数据完整性 数据不被篡改 数据库事务、数字签名
数据保密性 敏感数据加密 密码加密、传输加密
备份恢复 定期备份 每日备份、异地存储
c.个人信息保护
a.说明
个人信息处理原则：
1.合法、正当、必要原则
2.最小必要原则
3.知情同意原则
4.目的限制原则
隐私政策要点：
b.明确告知用户处理目的
c.获得用户同意
d.仅收集必要信息
e.仅收集业务必需的信息
f.避免过度收集
g.隐私政策明示
h.获得明确同意
i.不得超出告知范围使用
j.收集的个人信息类型
k.使用目的和方式
l.共享、转让、公开披露规则
m.用户权利 (访问、更正、删除)
n.安全保护措施
o.联系方式
d.数据分类分级
a.说明
数据分类：
b.表格数据
类别 定义 保护级别
公开数据 可公开访问的信息 低
内部数据 仅限内部使用的数据 中
敏感数据 泄露会造成影响的数据 高
核心数据 关系企业生存的数据 极高
c.说明
数据分级保护措施：
d.表格数据
级别 访问控制 传输加密 存储加密 审计
公开 无需认证 不强制 不强制 可选
内部 身份认证 推荐 推荐 记录
敏感 严格认证 强制 强制 完整
核心 双因素认证 强制 强制 完整
e.合规检查清单
a.说明
网络安全等级保护：
个人信息保护：
数据安全：
---
b.[ ] 已完成等级保护备案
c.[ ] 通过等级保护测评
d.[ ] 整改完成并复评合格
e.[ ] 定期 (年度) 复评
f.[ ] 制定隐私政策
g.[ ] 获得用户同意
h.[ ] 实施最小化收集
i.[ ] 提供用户权利行使途径
j.[ ] 建立投诉举报渠道
k.[ ] 数据分类分级
l.[ ] 数据备份和恢复
m.[ ] 数据安全风险评估
n.[ ] 数据安全事件应急预案
h.安全检查清单
a.部署前检查
1.[ ] SSL 证书配置完成
2.[ ] 密码复杂度策略启用
3.[ ] 默认密码已更改
4.[ ] 不必要的服务已关闭
5.[ ] 防火墙规则配置
6.[ ] 网络隔离实施
7.[ ] 文件上传限制配置
8.[ ] 日志记录启用
9.[ ] 监控告警配置
10.[ ] 备份策略配置
b.运行时检查
1.[ ] 定期更新系统补丁
2.[ ] 定期更新依赖库
3.[ ] 定期安全扫描
4.[ ] 定期审计日志检查
5.[ ] 定期备份数据
6.[ ] 定期演练应急预案
7.[ ] 定期安全培训
8.[ ] 定期合规评估
c.应急准备
a.说明
---
b.[ ] 应急响应预案制定
c.[ ] 应急联系人清单
d.[ ] 备份数据可恢复
e.[ ] 应急演练记录
f.[ ] 安全事件报告流程
i.总结
a.安全架构总结
a.说明
安全层次：
合规要点：
b.网络安全：VLAN 隔离、防火墙、DDoS 防护
c.接入安全：TLS 加密、身份认证
d.应用安全：权限控制、输入验证
e.数据安全：加密、脱敏、审计
f.运维安全：监控、扫描、应急响应
g.符合《网络安全法》要求
h.通过等级保护二级测评
i.遵循《个人信息保护法》
j.实施数据分类分级保护
b.安全最佳实践
✅ 最小权限原则 - 用户仅拥有必需的权限
✅ 纵深防御 - 多层安全防护
✅ 默认拒绝 - 默认拒绝访问，显式允许
✅ 完整审计 - 完整记录所有操作
✅ 定期更新 - 及时更新系统和依赖
✅ 安全培训 - 定期安全意识培训
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
07.实施计划
a.项目总览
a.项目目标
a.说明
项目名称： 企业采购评标工具 (基于昇腾 NPU 的私有化部署)
项目周期： 约 9 周
项目目标：
b.表格数据
目标维度 具体指标
功能完整 实现文档解析、规则配置、智能评标、报告生成四大核心功能
性能达标 支持 10 个并发会话，文档解析 < 30 秒，智能评标 < 60 秒
安全合规 通过等级保护二级测评，符合《网络安全法》等法律法规
私有化部署 完全基于昇腾 NPU，数据本地化存储
b.项目范围
a.说明
包含范围：
不包含范围：
---
b.✅ 基于 FastAPI 的后端服务开发
c.✅ 基于 Vue 3 的前端界面开发
d.✅ 昇腾 NPU 环境搭建和模型部署
e.✅ NewAPI 模型网关集成
f.✅ Docker 容器化部署
g.✅ 监控和日志系统
h.❌ 移动端应用开发
i.❌ 第三方系统集成
j.❌ 数据迁移服务
k.❌ 招标文件生成功能
l.❌ 电子签名功能
b.项目阶段划分
a.阶段总览
a.代码示例
---
┌────────────────────────────────────────────────────────────┐
│ 项目时间线 (9 周) │
└────────────────────────────────────────────────────────────┘
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 第一阶段 │ │ 第二阶段 │ │ 第三阶段 │ │ 第四阶段 │
│ 基础设施 │ │ 核心开发 │ │ 测试优化 │ │ 部署上线 │
│ 1-2 周 │ │ 3-5 周 │ │ 6-8 周 │ │ 9 周 │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
环境搭建 功能开发 系统测试 部署上线
模型部署 接口开发 性能优化 用户培训
框架搭建 前端开发 Bug 修复 验收交付
---
b.各阶段目标
a.表格数据
阶段 名称 周期 主要目标
第一阶段 基础设施 2 周 完成环境搭建、模型部署、框架搭建
第二阶段 核心开发 3 周 完成四大核心功能开发
第三阶段 测试优化 3 周 完成功能测试、性能优化、安全加固
第四阶段 部署上线 1 周 完成生产部署、用户培训、验收交付
b.说明
---
c.第一阶段：基础设施 (第 1-2 周)
a.阶段目标
a.说明
主要目标：
b.完成昇腾 NPU 环境搭建
c.完成 AI 模型部署和验证
d.完成开发框架搭建
e.完成基础服务部署
b.详细任务
a.Week 1: 环境搭建
a.说明
昇腾 NPU 环境搭建：
b.表格数据
任务 负责人 工期 产出
安装昇腾驱动和 CANN 运维工程师 1 天 NPU 可用
安装 torch-npu 和 MindSpeed AI 工程师 1 天 Python 环境
验证 NPU 可用性 AI 工程师 0.5 天 验证报告
配置 Python 虚拟环境 AI 工程师 0.5 天 虚拟环境
c.说明
模型部署：
d.表格数据
任务 负责人 工期 产出
部署 Qwen2.5-72B (2x TP) AI 工程师 1.5 天 模型服务
部署 Qwen2.5-VL-32B AI 工程师 1 天 模型服务
部署 Qwen2-VL-7B AI 工程师 0.5 天 模型服务
部署 PaddleOCR AI 工程师 0.5 天 OCR 服务
模型接口验证测试 AI 工程师 1 天 测试报告
e.说明
Docker 环境搭建：
f.表格数据
任务 负责人 工期 产出
安装 Docker 和 Compose 运维工程师 0.5 天 Docker 环境
配置 Docker 网络 运维工程师 0.5 天 网络配置
准备 docker-compose.yml 后端工程师 1 天 配置文件
b.Week 2: 框架搭建
a.说明
后端框架搭建：
b.表格数据
任务 负责人 工期 产出
初始化 FastAPI 项目 后端工程师 0.5 天 项目骨架
配置数据库连接 后端工程师 0.5 天 数据库连接
配置 Redis 连接 后端工程师 0.5 天 Redis 连接
配置 Celery 任务队列 后端工程师 0.5 天 异步任务
实现用户认证模块 后端工程师 1.5 天 JWT 认证
实现权限控制模块 后端工程师 1 天 RBAC 权限
编写 API 文档 后端工程师 0.5 天 Swagger 文档
c.说明
前端框架搭建：
d.表格数据
任务 负责人 工期 产出
初始化 Vue 3 项目 前端工程师 0.5 天 项目骨架
配置 TypeScript 前端工程师 0.5 天 TS 配置
配置 Element Plus 前端工程师 0.5 天 UI 组件库
配置路由和状态管理 前端工程师 0.5 天 Router + Pinia
实现登录页面 前端工程师 1 天 登录界面
实现主框架布局 前端工程师 1 天 主布局
e.说明
数据库设计：
f.表格数据
任务 负责人 工期 产出
设计数据库表结构 后端工程师 1 天 ER 图
编写 SQLAlchemy 模型 后端工程师 1 天 ORM 模型
编写数据库迁移脚本 后端工程师 1 天 Alembic 脚本
初始化数据库 后端工程师 0.5 天 数据库实例
g.说明
NewAPI 集成：
h.表格数据
任务 负责人 工期 产出
部署 NewAPI 容器 运维工程师 0.5 天 NewAPI 服务
配置模型渠道 AI 工程师 0.5 天 渠道配置
配置 Token 和权限 AI 工程师 0.5 天 Token 配置
测试模型调用 后端工程师 0.5 天 测试报告
c.里程碑
a.说明
阶段里程碑 (Week 2 结束)：
b.[ ] 昇腾 NPU 环境可用，所有模型部署完成
c.[ ] Docker 环境搭建完成，基础服务运行正常
d.[ ] 后端框架搭建完成，用户认证和权限可用
e.[ ] 前端框架搭建完成，主框架可用
f.[ ] 数据库设计完成并初始化
g.[ ] NewAPI 集成完成，模型调用正常
d.验收标准
a.说明
技术验收：
---
b.[ ] NPU 可用性验证通过 (npu-smi info 正常)
c.[ ] 所有模型推理正常 (响应时间 < 5 秒)
d.[ ] Docker 容器正常启动和停止
e.[ ] 数据库连接正常，表结构正确
f.[ ] 用户认证功能正常 (登录、登出、Token 验证)
d.第二阶段：核心开发 (第 3-5 周)
a.阶段目标
a.说明
主要目标：
b.完成文档上传与解析功能
c.完成评标规则配置功能
d.完成智能评标分析功能
e.完成评标报告生成功能
b.详细任务
a.Week 3: 文档解析模块
a.说明
后端开发：
b.表格数据
任务 负责人 工期 产出
实现文件上传 API 后端工程师 1 天 上传接口
实现文件验证逻辑 后端工程师 0.5 天 验证模块
集成 PaddleOCR AI 工程师 1 天 OCR 集成
实现文档解析任务 AI 工程师 1.5 天 解析服务
实现解析结果存储 后端工程师 1 天 数据存储
实现解析进度查询 后端工程师 0.5 天 进度接口
编写单元测试 后端工程师 1 天 测试用例
c.说明
前端开发：
d.表格数据
任务 负责人 工期 产出
实现文件上传组件 前端工程师 1 天 上传组件
实现文件列表页面 前端工程师 1 天 列表页面
实现解析进度显示 前端工程师 1 天 进度组件
实现解析结果预览 前端工程师 1.5 天 预览组件
b.Week 4: 规则配置模块
a.说明
后端开发：
b.表格数据
任务 负责人 工期 产出
实现规则管理 API 后端工程师 1.5 天 规则接口
实现评分项管理 后端工程师 1 天 评分项接口
实现权重计算逻辑 后端工程师 0.5 天 计算模块
实现规则模板 后端工程师 1 天 模板功能
编写单元测试 后端工程师 1 天 测试用例
c.说明
前端开发：
d.表格数据
任务 负责人 工期 产出
实现规则列表页面 前端工程师 1 天 列表页面
实现规则创建表单 前端工程师 1.5 天 创建表单
实现评分项配置 前端工程师 1.5 天 评分项组件
实现规则模板选择 前端工程师 0.5 天 模板组件
c.Week 5: 评标分析模块
a.说明
后端开发：
b.表格数据
任务 负责人 工期 产出
实现评标项目 API 后端工程师 1 天 项目接口
集成 Qwen2.5-72B AI 工程师 1 天 文本理解
集成 Qwen2.5-VL-32B AI 工程师 1 天 多模态理解
实现标书比对逻辑 AI 工程师 1.5 天 比对算法
实现符合度分析 AI 工程师 1 天 分析算法
实现自动评分逻辑 AI 工程师 1 天 评分算法
编写单元测试 后端工程师 1 天 测试用例
c.说明
前端开发：
d.表格数据
任务 负责人 工期 产出
实现评标项目页面 前端工程师 1 天 项目页面
实现文档选择界面 前端工程师 1 天 选择界面
实现规则选择界面 前端工程师 0.5 天 规则界面
实现评标进度显示 前端工程师 1 天 进度组件
实现评标结果展示 前端工程师 1.5 天 结果页面
c.里程碑
a.说明
阶段里程碑 (Week 5 结束)：
b.[ ] 文档上传和解析功能完成
c.[ ] 评标规则配置功能完成
d.[ ] 智能评标分析功能完成
e.[ ] 所有核心 API 开发完成
f.[ ] 前端主要页面开发完成
d.验收标准
a.说明
功能验收：
---
b.[ ] 支持上传 PDF、Word、图片文档 (最大 200MB)
c.[ ] 文档解析准确率 > 85%
d.[ ] 可以创建和管理评标规则
e.[ ] 可以执行智能评标分析
f.[ ] 评标结果展示清晰准确
e.第三阶段：测试优化 (第 6-8 周)
a.阶段目标
a.说明
主要目标：
b.完成报告生成功能
c.完成功能测试和 Bug 修复
d.完成性能优化
e.完成安全加固
b.详细任务
a.Week 6: 报告生成模块
a.说明
后端开发：
b.表格数据
任务 负责人 工期 产出
实现报告模板引擎 后端工程师 1.5 天 模板引擎
实现 PDF 生成 后端工程师 1 天 PDF 生成
实现 Word 生成 后端工程师 1 天 Word 生成
实现报告下载 API 后端工程师 0.5 天 下载接口
编写单元测试 后端工程师 1 天 测试用例
c.说明
前端开发：
d.表格数据
任务 负责人 工期 产出
实现报告预览组件 前端工程师 1.5 天 预览组件
实现报告生成按钮 前端工程师 0.5 天 生成按钮
实现报告下载功能 前端工程师 0.5 天 下载功能
b.Week 7: 功能测试
a.说明
测试准备：
b.表格数据
任务 负责人 工期 产出
编写测试用例 测试工程师 1 天 测试用例
准备测试数据 测试工程师 1 天 测试数据
搭建测试环境 运维工程师 0.5 天 测试环境
c.说明
功能测试：
d.表格数据
任务 负责人 工期 产出
执行功能测试 测试工程师 2 天 测试报告
记录 Bug 问题 测试工程师 持续 Bug 列表
Bug 修复 后端/前端 2.5 天 修复记录
回归测试 测试工程师 1.5 天 回归报告
c.Week 8: 优化与安全
a.说明
性能优化：
b.表格数据
任务 负责人 工期 产出
性能基准测试 后端工程师 1 天 基准报告
数据库查询优化 后端工程师 1 天 SQL 优化
API 响应优化 后端工程师 1 天 接口优化
前端加载优化 前端工程师 1 天 性能优化
c.说明
安全加固：
d.表格数据
任务 负责人 工期 产出
安全漏洞扫描 安全工程师 0.5 天 扫描报告
修复安全漏洞 后端工程师 1 天 修复记录
配置安全策略 运维工程师 0.5 天 安全策略
审计日志验证 后端工程师 0.5 天 审计验证
e.说明
监控配置：
f.表格数据
任务 负责人 工期 产出
配置 Prometheus 运维工程师 0.5 天 监控服务
配置 Grafana 运维工程师 0.5 天 监控面板
配置告警规则 运维工程师 0.5 天 告警规则
配置日志收集 运维工程师 0.5 天 日志系统
c.里程碑
a.说明
阶段里程碑 (Week 8 结束)：
b.[ ] 报告生成功能完成
c.[ ] 功能测试通过，无严重 Bug
d.[ ] 性能测试通过
e.[ ] 安全扫描通过
f.[ ] 监控和日志系统可用
d.验收标准
a.说明
功能验收：
性能验收：
安全验收：
---
b.[ ] 所有功能测试用例通过
c.[ ] 无 P0/P1 级别 Bug
d.[ ] P2 级别 Bug < 5 个
e.[ ] 文档解析响应时间 < 30 秒 (100 页文档)
f.[ ] 智能评标响应时间 < 60 秒
g.[ ] 支持 10 个并发会话
h.[ ] 系统可用性 > 99%
i.[ ] 无高危安全漏洞
j.[ ] 审计日志记录完整
k.[ ] 权限控制正确
f.第四阶段：部署上线 (第 9 周)
a.阶段目标
a.说明
主要目标：
b.完成生产环境部署
c.完成用户培训
d.完成项目验收和交付
b.详细任务
a.Week 9: 部署与交付
a.说明
生产部署：
b.表格数据
任务 负责人 工期 产出
生产环境准备 运维工程师 0.5 天 环境清单
数据库迁移 运维工程师 0.5 天 迁移脚本
应用部署 运维工程师 1 天 部署记录
数据备份验证 运维工程师 0.5 天 备份验证
部署验证测试 测试工程师 0.5 天 验证报告
c.说明
用户培训：
d.表格数据
任务 负责人 工期 产出
编写用户手册 产品经理 1 天 用户手册
编写运维手册 运维工程师 1 天 运维手册
用户培训 产品经理 1 天 培训记录
运维培训 运维工程师 0.5 天 培训记录
e.说明
项目验收：
f.表格数据
任务 负责人 工期 产出
功能验收演示 项目经理 0.5 天 演示记录
性能验收测试 测试工程师 0.5 天 测试报告
安全验收检查 安全工程师 0.5 天 检查报告
编写验收报告 项目经理 1 天 验收报告
项目验收会议 项目经理 0.5 天 会议纪要
g.说明
项目交付：
h.表格数据
任务 负责人 工期 产出
代码归档 项目经理 0.5 天 代码仓库
文档归档 项目经理 0.5 天 文档仓库
知识转移 项目经理 1 天 转移记录
项目总结 项目经理 0.5 天 总结报告
c.里程碑
a.说明
阶段里程碑 (Week 9 结束)：
---
b.[ ] 生产环境部署完成
c.[ ] 用户培训完成
d.[ ] 项目验收通过
e.[ ] 项目文档交付
f.[ ] 知识转移完成
g.团队与资源
a.团队组成
a.说明
核心团队：
b.表格数据
角色 人数 主要职责
项目经理 1 项目管理、协调、交付
后端工程师 2 后端 API 开发、数据库设计
前端工程师 1 前端界面开发、交互实现
AI 工程师 2 模型部署、AI 功能开发
运维工程师 1 环境搭建、部署、监控
测试工程师 1 功能测试、性能测试
安全工程师 0.5 安全加固、合规检查
产品经理 0.5 需求管理、用户培训
c.说明
总计： 约 9 人
b.硬件资源
a.说明
开发环境：
b.表格数据
资源 配置 数量 用途
开发服务器 8 核 32GB 2 开发测试
测试服务器 16 核 64GB 1 集成测试
c.说明
生产环境：
d.表格数据
资源 配置 数量 用途
昇腾 NPU 服务器 910B x 4 卡, 512GB 内存 1-2 AI 模型推理
应用服务器 16 核 64GB 1 应用服务
数据库服务器 32 核 128GB, 2TB SSD 1 数据存储
c.软件资源
a.说明
开发工具：
监控工具：
---
b.Git (代码版本控制)
c.VS Code / PyCharm (开发 IDE)
d.Postman (API 测试)
e.Docker Desktop (本地开发)
f.Prometheus (监控)
g.Grafana (可视化)
h.ELK Stack (日志)
h.风险管理
a.技术风险
a.表格数据
风险 概率 影响 应对措施
昇腾 NPU 性能不达预期 中 高 提前性能测试，必要时调整模型规模
模型理解准确率不足 中 中 人工复核机制，持续优化 Prompt
并发性能不足 低 中 负载均衡，缓存优化
第三方依赖问题 低 中 提前验证，准备替代方案
b.项目风险
a.表格数据
风险 概率 影响 应对措施
需求变更 中 中 需求冻结，变更评审
人员变动 低 高 知识文档化，结对编程
进度延期 中 中 预留缓冲时间，关键路径监控
c.应急预案
a.说明
应急响应：
1.进度预警
2.质量预警
3.资源调配
---
b.每周进度评审
c.偏差 > 10% 触发预警
d.及时调整计划
e.Bug 数量 > 预警值
f.暂停新功能开发
g.集中修复 Bug
h.关键路径优先
i.必要时增加人力
j.调整功能优先级
i.质量保障
a.代码质量
a.说明
代码规范：
单元测试：
b.Python: PEP 8
c.TypeScript: ESLint + Prettier
d.代码审查: 所有 PR 需要审查
e.后端测试覆盖率 > 70%
f.关键业务逻辑覆盖率 > 90%
b.文档质量
a.说明
必需文档：
b.[ ] 系统设计文档
c.[ ] API 接口文档
d.[ ] 数据库设计文档
e.[ ] 部署运维文档
f.[ ] 用户使用手册
c.交付质量
a.说明
交付清单：
---
b.[ ] 源代码 (Git 仓库)
c.[ ] Docker 镜像
d.[ ] 部署脚本
e.[ ] 技术文档
f.[ ] 用户手册
g.[ ] 测试报告
h.[ ] 验收报告
j.项目时间表
a.甘特图
a.代码示例
---
任务 W1 W2 W3 W4 W5 W6 W7 W8 W9
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
环境搭建 ████
模型部署 ████████
框架搭建 ████████
文档解析 ████████
规则配置 ████████
评标分析 ████████
报告生成 ████████
功能测试 ████████
性能优化 ████████
安全加固 ████████
生产部署 ████
用户培训 ████
项目验收 ████
---
b.关键里程碑
a.表格数据
里程碑 时间 验收标准
M1: 基础设施完成 Week 2 环境可用，模型部署完成
M2: 核心功能完成 Week 5 四大核心功能开发完成
M3: 测试完成 Week 8 功能、性能、安全测试通过
M4: 项目交付 Week 9 部署上线，验收通过
b.说明
---
k.沟通与汇报
a.会议安排
a.表格数据
会议类型 频率 参与人 时长
每日站会 每日 开发团队 15 分钟
周例会 每周 全体项目成员 1 小时
里程碑评审 关键节点 相关方 2 小时
b.汇报机制
a.说明
周报内容：
月报内容：
---
b.本周完成工作
c.下周计划工作
d.风险和问题
e.需要支持
f.项目进度总结
g.里程碑达成情况
h.预算使用情况
i.风险和应对
l.验收标准
a.功能验收
1.[ ] 支持上传 PDF、Word、图片文档
2.[ ] 文档解析准确率 > 85%
3.[ ] 可以创建和管理评标规则
4.[ ] 可以执行智能评标分析
5.[ ] 可以生成评标报告 (PDF/Word)
b.性能验收
1.[ ] 文档解析响应时间 < 30 秒 (100 页文档)
2.[ ] 智能评标响应时间 < 60 秒
3.[ ] 支持 10 个并发会话
4.[ ] 系统可用性 > 99%
c.安全验收
a.说明
---
b.[ ] 数据本地化存储
c.[ ] 操作日志可审计
d.[ ] 权限控制正确
e.[ ] 通过安全扫描
m.总结
a.项目成功因素
✅ 明确的目标 - 功能、性能、安全目标清晰
✅ 合理的计划 - 分阶段实施，风险可控
✅ 专业的团队 - 角色齐全，职责明确
✅ 充分的测试 - 功能、性能、安全全面测试
✅ 完善的文档 - 设计、开发、运维文档齐全
b.项目交付清单
a.说明
代码交付：
文档交付：
其他交付：
---
文档版本：v1.0
最后更新：2025-01-15
文档状态：草稿
b.源代码 (含注释)
c.单元测试
d.部署脚本
e.系统设计文档
f.API 接口文档
g.数据库设计文档
h.部署运维文档
i.用户使用手册
j.测试报告
k.验收报告
l.项目总结报告
5.4 [2]架构设计
01.系统架构总览
a.系统整体架构
a.架构图
a.代码示例
---
graph TB
subgraph "前端层"
A1[Vue3前端]
A2[Element Plus]
A3[WebSocket客户端]
A4[Axios HTTP客户端]
end
subgraph "接入层"
B1[Nginx负载均衡]
B2[SSL终止]
B3[限流防护]
B4[反向代理]
end
subgraph "应用层"
C1[FastAPI应用服务 x4实例]
C2[Celery任务编排器]
C3[Redis消息队列]
C4[Worker池 20个]
end
subgraph "AI服务层"
D1[NewAPI模型网关]
D2[Qwen2.5-72B x2TP]
D3[Qwen2.5-VL-32B x1TP]
D4[Qwen2-VL-7B快速响应]
D5[PaddleOCR PP-OCRv4]
end
subgraph "数据层"
E1[PostgreSQL关系型数据库]
E2[ChromaDB向量数据库]
E3[Redis缓存层]
E4[MinIO对象存储]
end
subgraph "基础设施层"
F1[昇腾910B NPU集群]
F2[Docker Compose]
F3[Kubernetes编排]
F4[Prometheus监控]
F5[Grafana可视化]
end
A1 --> B1
B1 --> C1
B1 --> C2
B1 --> C3
C1 --> D1
C2 --> D2
C3 --> D3
C4 --> D4
C5 --> D5
C1 --> E1
C2 --> E2
C3 --> E3
C4 --> E4
F1 --> D1
F2 --> C1
F3 --> C2
F4 --> C5
---
b.架构分层数据流
a.代码示例
---
sequenceDiagram
participant E1 as 专家1
participant E2 as 专家2
participant E3 as 专家3
participant E4 as 专家4
participant E5 as 专家5
participant E6 as 专家6
participant E7 as 专家7
participant E8 as 专家8
participant E9 as 专家9
participant E10 as 专家10
participant A1 as Vue3前端
participant B1 as Nginx
participant C1 as FastAPI
participant C2 as Celery
participant D1 as NewAPI
participant D2 as Qwen72B
participant D3 as QwenVL32B
participant D4 as QwenVL7B
participant D5 as PaddleOCR
participant E1 as PostgreSQL
participant E2 as ChromaDB
participant E3 as Redis
Note over E1,E2,E3,E4,E5,E6,E7,E8,E9,E10: 开标时刻瞬时10并发上传
E1->>B1: 上传标书1 (50-100MB)
E2->>B1: 上传标书2 (50-100MB)
E3->>B1: 上传标书3 (50-100MB)
E4->>B1: 上传标书4 (50-100MB)
E5->>B1: 上传标书5 (50-100MB)
E6->>B1: 上传标书6 (50-100MB)
E7->>B1: 上传标书7 (50-100MB)
E8->>B1: 上传标书8 (50-100MB)
E9->>B1: 上传标书9 (50-100MB)
E10->>B1: 上传标书10 (50-100MB)
B1->>C1: 接收HTTP请求，验证文件
B1->>E1: 返回任务ID1
B1->>E2: 返回任务ID2
B1->>E3: 返回任务ID3
B1->>E4: 返回任务ID4
B1->>E5: 返回任务ID5
B1->>E6: 返回任务ID6
B1->>E7: 返回任务ID7
B1->>E8: 返回任务ID8
B1->>E9: 返回任务ID9
B1->>E10: 返回任务ID10
C1->>C2: 创建10个Celery任务（high_priority队列）
Note over C2: 任务ID: task_1至task_10
C2->>C3: 20个Worker并行处理
Note over C3: Worker1处理标书1-3, Worker4-6处理标书4-6, Worker7-9处理标书7-9, Worker8-10处理标书8-10, Worker9处理标书9, Worker10处理标书10
C3->>D5: 调用PaddleOCR解析标书1
C3->>D5: 调用PaddleOCR解析标书2
C3->>D5: 调用PaddleOCR解析标书3
C3->>D5: 调用PaddleOCR解析标书4
C3->>D5: 调用PaddleOCR解析标书5
C3->>D5: 调用PaddleOCR解析标书6
C3->>D5: 调用PaddleOCR解析标书7
C3->>D5: 调用PaddleOCR解析标书8
C3->>D5: 调用PaddleOCR解析标书9
C3->>D5: 调用PaddleOCR解析标书10
C3->>D3: 调用QwenVL32B进行多模态分析标书1-10
Note over D3: 流式处理：每解析完一个分片立即建立索引
D3->>D4: 调用Qwen72B进行文本分析标书1-10
Note over D4: 72B模型处理澄清提问
C3->>E3: 返回解析结果，更新任务状态
Note over C3: 10个标书解析完成（T≈5分钟）
C3->>E2: 保存解析结果到PostgreSQL
C3->>E2: 保存解析结果到ChromaDB（向量索引）
Note over C1,E2,E3,E4,E5,E6,E7,E8,E9,E10: WebSocket推送解析进度
---
b.说明
---
b.核心模块关系
a.模块依赖关系
a.表格数据
模块 依赖模块 被依赖 依赖关系
前端层 Vue3前端 Nginx负载均衡 应用服务
接入层 Nginx负载均衡 FastAPI应用服务 Celery任务编排器
应用层 FastAPI应用服务 Celery任务编排器 Redis消息队列
应用层 FastAPI应用服务 Celery任务编排器 PostgreSQL
应用层 FastAPI应用服务 Celery任务编排器 NewAPI
AI服务层 NewAPI Qwen2.5-72B 昇腾NPU集群
AI服务层 NewAPI Qwen2.5-VL-32B 昇腾NPU集群
AI服务层 NewAPI PaddleOCR 昇腾NPU集群
数据层 FastAPI应用服务 PostgreSQL ChromaDB Redis
数据层 FastAPI应用服务 MinIO对象存储 - -
基础设施层 Docker Compose Kubernetes编排 昇腾NPU集群
b.模块职责划分
a.表格数据
模块层级 模块名称 核心职责
前端层 Vue3前端 提供用户界面，实时进度展示，澄清提问，手动打分
接入层 Nginx负载均衡 SSL终止，请求路由，限流防护，反向代理
应用层 FastAPI应用服务 RESTful API，WebSocket服务，请求验证，业务逻辑处理
应用层 Celery任务编排器 异步任务调度，任务链编排，Worker池管理
应用层 Redis消息队列 任务队列管理，结果缓存，状态同步
AI服务层 NewAPI 统一模型管理，OpenAI兼容接口，智能路由，负载均衡
AI服务层 Qwen2.5-72B 文本理解，逻辑推理，澄清提问分析
AI服务层 Qwen2.5-VL-32B 多模态文档理解，表格识别，图像理解
AI服务层 PaddleOCR 文字识别，表格识别，中文优化
数据层 PostgreSQL 元数据存储，解析结果存储，评分数据存储，审计日志
数据层 ChromaDB 标书内容向量索引，历史数据检索，语义搜索
数据层 Redis 任务队列，结果缓存，会话状态，心跳管理
数据层 MinIO 原始PDF文件存储，大容量存储，数据归档
基础设施层 昇腾910B NPU集群 模型推理，算力资源
基础设施层 Docker Compose 容器化部署，服务编排，网络配置
基础设施层 Kubernetes编排 服务编排，自动扩缩，故障转移
基础设施层 Prometheus监控 指标收集，监控仪表板，告警通知
基础设施层 Grafana可视化 数据可视化，监控仪表板，日志分析
b.说明
---
c.技术栈选型总结
a.整体技术栈概览
a.表格数据
层级 技术组件 技术选型 核心优势
前端层 框架 Vue 3 Composition API 响应式数据绑定，组件化开发
UI组件 Element Plus 企业级组件库，中文友好
状态管理 Pinia 轻量级状态管理，TypeScript支持
实时通信 WebSocket + VueUse 持久连接，自动重连，心跳机制
HTTP客户端 Axios Promise支持，请求拦截器
接入层 负载均衡 Nginx 高性能，反向代理，SSL终止
应用层 Web框架 FastAPI 高性能异步，自动文档生成
异步任务 Celery 分布式任务队列，任务链编排
消息队列 Redis 内存缓存，发布订阅，持久化支持
ORM SQLAlchemy 成熟ORM，自动迁移
认证 JWT + BCrypt 无状态认证，密码哈希
AI服务层 模型网关 NewAPI 统一模型管理，OpenAI兼容
文本模型 Qwen2.5-72B-Instruct 72B参数，长上下文(128K)，逻辑推理
多模态模型 Qwen2.5-VL-32B-Instruct 32B参数，文档理解，表格识别
快速响应模型 Qwen2-VL-7B-Instruct 7B参数，快速响应，图像理解
OCR模型 PaddleOCR PP-OCRv4 文字识别，表格识别，中文优化
数据层 关系型数据库 PostgreSQL 13+ JSONB支持，ACID，事务管理
向量数据库 ChromaDB 开源，HNSW索引，元数据过滤
缓存 Redis 7+ 内存缓存，发布订阅，持久化
对象存储 MinIO 分布式对象存储，大容量，S3兼容
基础设施层 硬件 昇腾910B NPU 4x910B(36.4TB)，国产化，高性能
容器编排 Kubernetes 服务编排，自动扩缩，故障转移
监控 Prometheus + Grafana 时序数据库，指标可视化，告警通知
b.技术栈选型理由
a.前端技术栈
Vue 3选择理由：
1.响应式数据绑定：适合复杂的评标场景，实时更新解析进度
2.Composition API：逻辑复用性强，代码组织清晰
3.TypeScript支持：类型安全，IDE智能提示，减少运行时错误
4.Element Plus：企业级组件库，中文友好，开箱即用
Element Plus选择理由：
1.企业级组件库：完善的组件生态，文档齐全
2.中文友好：符合中文评标场景
3.主题定制：支持自定义主题，符合企业品牌
4.响应式布局：适配不同屏幕尺寸
Pinia选择理由：
1.轻量级：相比Vuex，包体积小，性能更好
2.TypeScript原生支持：类型推断更准确
3.DevTools集成：开发体验更好
4.模块化设计：符合大型应用架构
b.后端技术栈
FastAPI选择理由：
1.高性能异步支持：原生async/await，协程处理高并发
2.自动文档生成：Swagger/OpenAPI自动生成，前后端协作高效
3.依赖注入：优雅的依赖管理，模块解耦
4.Pydantic验证：数据验证，类型安全，自动生成错误响应
Celery选择理由：
1.分布式任务队列：支持水平扩展，多Worker并发处理
2.任务链编排：支持复杂工作流（解析→索引→澄清→打分）
3.优先级队列：high_priority、medium_priority、low_priority三级队列
4.任务监控：任务状态跟踪，失败重试，结果缓存
SQLAlchemy选择理由：
1.成熟ORM：Python生态最流行的ORM，文档齐全
2.自动迁移：Alembic支持，数据库版本管理
3.连接池：支持连接池，应对高并发
4.查询优化：支持复杂查询，批量操作
Redis选择理由：
1.高性能：内存缓存，亚毫秒级响应
2.发布订阅：支持任务队列状态同步
3.持久化支持：AOF/RDB持久化，数据安全
4.丰富数据结构：支持List、Set、Hash、Sorted Set
c.AI服务技术栈
NewAPI选择理由：
1.统一模型管理：一个网关管理所有AI模型，降低集成复杂度
2.OpenAI兼容接口：标准化接口，无需修改现有代码
3.智能路由：根据任务类型自动选择最优模型（澄清用72B，快速响应用7B）
4.负载均衡：多实例负载均衡，故障自动转移
5.使用监控：QPS监控，Token使用统计，成本分析
Qwen模型选择理由：
1.国产化支持：Qwen系列模型对昇腾NPU有官方适配
2.昇腾优化：MindSpeed优化推理性能，比原生PyTorch更高效
3.长上下文：Qwen2.5-72B支持128K上下文，处理长文档
4.开源生态：模型权重、插件系统，工具链完善
PaddleOCR选择理由：
1.中文优化：针对中文场景优化，准确率更高
2.表格识别：PP-Structure模块，精准识别表格结构
3.开源免费：无需额外授权，降低成本
4.性能优异：相比Tesseract，速度更快，准确率更高
d.数据层技术栈
PostgreSQL选择理由：
1.JSONB支持：存储解析结果，索引元数据，灵活查询
2.GIN索引：JSONB字段高效索引，查询性能优化
3.事务支持：ACID，保证数据一致性
4.高并发：支持连接池，应对开标时刻10并发
ChromaDB选择理由：
1.开源向量数据库：无需授权，降低成本
2.HNSW索引：高效近似最近邻搜索，支持大规模数据
3.元数据过滤：支持复杂的元数据查询过滤（时间、项目、供应商）
4.集成便捷：Python生态友好，API简洁
Redis选择理由：
1.三层缓存架构：应用缓存、搜索结果缓存、会话缓存
2.订阅发布：支持实时进度推送（WebSocket）
3.TTL控制：不同数据类型设置不同TTL（澄清1小时，搜索10分钟）
4.持久化：AOF+RDB双重持久化，数据安全
MinIO选择理由：
1.S3兼容：与AWS S3 API兼容，未来可迁移到云存储
2.分布式对象存储：支持大规模数据存储，扩展性强
3.高性能：相比本地文件系统，性能更优
4.数据安全：支持服务器端加密，版本控制
e.基础设施技术栈
昇腾NPU集群选择理由：
1.国产化方案：符合信创要求，供应链稳定
2.高性能：910B NPU，单卡36.4TB显存，总显存36.4TB
3.官方支持：Qwen系列模型对昇腾NPU有官方适配
4.成本优势：相比NVIDIA GPU，成本降低40-60%
Kubernetes选择理由：
1.服务编排：自动化部署，服务编排，自动扩缩
2.故障转移：自动健康检查，故障Pod自动重启
3.滚动更新：零停机部署，平滑升级
4.资源调度：基于资源需求智能调度Pod
Docker Compose选择理由：
1.开发环境：快速启动开发环境，依赖管理简单
2.测试环境：一致性测试，集成测试
3.生产环境：服务编排，网络隔离，配置管理
4.多环境支持：支持dev/staging/prod环境切换
Prometheus + Grafana选择理由：
1.时序数据库：Prometheus高效存储时序数据
2.灵活查询：PromQL支持复杂查询，数据聚合
3.可视化丰富：Grafana支持多种可视化图表
4.告警机制：支持多维度告警，通知渠道丰富
---
d.数据流总览
a.标书处理数据流
a.标书上传与验证流程
a.代码示例
---
专家1-10同时上传10个标书
│
├─ Nginx负载均衡 → 分发到4个FastAPI实例
├─ FastAPI接收请求 → 文件验证（类型、大小、格式）
├─ 保存到MinIO → 返回任务ID
└─ WebSocket推送上传进度
↓
Celery任务队列（high_priority）
│
├─ 20个Worker并行处理
├─ 任务1-10：文档解析
├─ 任务11-20：建立向量索引
└─ 任务21-30：更新数据库状态
↓
PostgreSQL + ChromaDB
│
├─ 保存解析结果（结构化数据）
├─ 保存向量索引（Qwen模型生成）
└─ 更新标书状态（uploading → parsing → indexed）
↓
WebSocket实时推送解析进度
│
└─ 推送分片进度（1%、2%、...、100%）
↓
5分钟内完成所有标书解析
---
b.AI澄清流程
a.代码示例
---
专家1-10并行提问澄清
│
├─ 专家提问："供应商A的技术参数是否符合600W要求？"
│
├─ FastAPI接收请求 → 验证权限
├─ 查询ChromaDB → 检索相关段落（Top-20，时间范围：当前项目+近10年）
│
├─ 调用NewAPI → Qwen2.5-72B分析
│ ├─ 输入：招标要求 + 20个相关段落
│ ├─ 输出：仅返回不符合指标的地方（页码、章节号、原文对比）
│ └─ 处理时间：<3秒
│
├─ Pydantic验证 → 验证输出格式
├─ WebSocket推送澄清结果
│ └─ 前端展示：页码、章节号、原文对比
↓
专家基于澄清结果手动打分
│
├─ 专家自主判断：技术分85分、商务分90分、价格分80分
├─ 系统接收评分 → 保存到PostgreSQL
└─ 计算综合得分：85×0.5 + 90×0.3 + 80×0.2 = 85.5分
---
b.实时推送机制
a.代码示例
---
WebSocket连接管理
│
├─ 前端连接 → WebSocket握手
├─ 订阅项目频道：project_{project_id}
├─ 发布订阅 → Redis发布消息
└─ 推送机制
├─ 标书解析进度：每解析完10页推送一次
├─ AI澄清结果：每次澄清完成后推送
├─ 专家打分更新：实时更新排名
└─ 系统通知：开标、评标开始/结束
---
b.说明
---
e.部署架构概览
a.生产环境部署架构
a.代码示例
---
┌─────────────────────────────────────────────────┐
│ Internet │
└────────────────┬──────────────────────────────┘
│
┌────────▼──────────────┐
│ Nginx Load Balancer │
│ (SSL终止) │
└────────┬───────────────────┘
│
┌─────────────────────────────┐
│ FastAPI Cluster (4 instances) │
│ Instance 1 │
│ Instance 2 │
│ Instance 3 │
│ Instance 4 │
└───────────────────────────────┘
│
┌─────────────────────────────────┐
│ Celery Worker Pool (20) │
│ High Priority Workers (10) │
│ Medium Priority Workers (5) │
│ Low Priority Workers (5) │
└───────────────────────────────┘
│
┌─────────────────────────────────┐
│ NewAPI Gateway │
│ ├─ Qwen2.5-72B (2x TP) │
│ ├─ Qwen2.5-VL-32B (1x TP) │
│ └─ PaddleOCR │
└───────────────────────────────┘
│
┌─────────────────────────────────┐
│ Data Layer │
│ ├─ PostgreSQL (Primary) │
│ ├─ ChromaDB (Vector) │
│ ├─ Redis (Cache) │
│ └─ MinIO (Object Storage) │
└───────────────────────────────┘
│
┌─────────────────────────────────┐
│ Infrastructure │
│ ├─ Ascend 910B NPUs (36.4TB) │
│ ├─ Kubernetes Cluster │
│ ├─ Prometheus + Grafana │
│ └─ Monitoring Agents │
└───────────────────────────────┘
---
b.网络架构
a.表格数据
网络区域 VLAN 子网 说明
DMZ区 VLAN 10 192.168.10.0/24 公网访问层
应用层 VLAN 20 192.168.20.0/24 FastAPI服务、Celery Workers
数据层 VLAN 30 192.168.30.0/24 PostgreSQL、Redis、MinIO
AI服务层 VLAN 40 192.168.40.0/24 NewAPI Gateway、Qwen NPU访问
基础设施层 VLAN 50 192.168.50.0/24 Kubernetes、NPU监控
b.说明
网络安全措施：
---
c.VLAN隔离：不同层级VLAN网络隔离
d.防火墙：企业级防火墙，只开放必要端口
e.DDoS防护：云端DDoS防护服务
f.SSL/TLS 1.3：HTTPS通信，强加密套件
f.核心设计原则
a.架构设计原则
a.表格数据
原则 说明 应用场景
模块化 高内聚低耦合 所有模块
可扩展 支持水平扩展 Worker池、数据库连接池
可观测 完整监控体系 Prometheus + Grafana
高可用 主备部署、故障自动转移 Nginx、Kubernetes、数据库主从
安全优先 网络隔离、数据加密、访问控制 所有层级
性能优先 缓存优化、异步处理、并行计算 开标时刻5分钟目标
合规优先 法律合规、等保二级、审计追踪 所有数据流
b.关键性能指标
a.表格数据
指标类别 具体指标 目标值 监控方式
并发处理 10个标书并发 完成<5分钟 任务队列深度监控
响应时间 API P50 < 100ms Prometheus HTTP请求监控
澄清响应 P95 < 3秒 Redis缓存命中率监控
向量检索 P95 < 1秒 ChromaDB查询性能监控
数据库查询 P95 < 500ms PostgreSQL慢查询监控
系统可用性 > 99.9% Uptime监控、心跳检测
NPU利用率 < 80% (开标时刻) NPU监控（昇腾平台）
b.说明
---
g.架构优势与挑战
a.核心优势
a.表格数据
优势 说明 价值体现
国产化AI 昇腾NPU + Qwen模型 符合信创要求，供应链稳定
高并发处理 20个Worker并行处理 开标时刻5分钟完成10个标书解析
大规模数据管理 10年5000个标书 冷热数据分层，2-4TB存储
实时进度推送 WebSocket实时通信 用户体验优秀
AI辅助澄清 仅提供参考依据 降低法律风险
完整审计追踪 10年审计日志 符合等保二级要求
容器化部署 Kubernetes + Docker 部署灵活，易于扩展
b.关键挑战与应对
a.表格数据
挑战 风险等级 应对措施
开标时刻瞬时高并发 中 预启动Worker池、优先级队列、压力测试
300页PDF处理 中 分页并行、流式处理、内存优化
向量数据库性能 中 HNSW索引、元数据过滤、缓存优化
AI模型准确性 低 Prompt工程、输出验证、专家复核
数据安全合规 高 加密存储、访问控制、审计日志
等保二级合规 低 提前准备材料、第三方测评
运维复杂度 中 容器化部署、监控告警、自动化运维
b.说明
---
h.下一步文档规划
a.已完成文档
a.表格数据
序号 文档标题 状态
31 开标时刻并发评标架构设计.md ✅ 完成
32 大规模标书存储与检索方案.md ✅ 完成
33 澄清系统与打分流程设计.md ✅ 完成
34 高并发处理与性能优化方案.md ✅ 完成
35 法律方向的解读.md ✅ 完成
41 系统架构总览.md 🔄 进行中
b.待撰写文档（11份）
a.表格数据
序号 文档标题 预计页数 核心内容
42 项目配置架构设计.md ~20页 环境变量、配置文件、多环境管理、配置热更新
43 数据库架构设计.md ~30页 PostgreSQL表结构设计、索引优化、查询性能、备份恢复策略、连接池管理、迁移方案
44 AI服务架构设计.md ~35页 NewAPI集成、Qwen模型调用策略、Prompt工程、缓存策略、错误处理、监控指标
45 后端API架构设计.md ~40页 FastAPI项目结构、中间件设计、路由设计、异常处理、请求验证、限流策略、文档管理
46 前端架构设计.md ~30页 Vue3项目结构、组件库、状态管理、路由设计、WebSocket通信、权限控制、错误处理、实时进度展示
47 API接口设计.md ~25页 RESTful规范、数据模型、错误码定义、版本管理、限流策略、文档管理、API安全
48 部署架构设计.md ~35页 Docker Compose配置、Kubernetes资源配置、网络配置、存储卷配置、环境变量、服务编排、健康检查、滚动更新
49 安全架构设计.md ~30页 JWT认证、RBAC权限控制、数据加密、网络安全、审计日志、等保二级、安全测试、应急响应
50 监控告警架构设计.md ~25页 Prometheus指标定义、Grafana仪表板、日志收集、告警规则、通知机制、告警分级、性能监控
51 测试架构设计.md ~25页 单元测试、集成测试、性能测试、安全测试、压力测试、自动化测试
52 运维架构设计.md ~25页 CI/CD流程、故障排查、数据迁移、备份恢复、日志分析、容量规划、灾难恢复
b.说明
---
i.总结
a.核心特征总结
a.说明
系统定位：
技术架构：
核心优势：
关键挑战：
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
b.开标时刻并发评标系统（仅开标时使用）
c.AI澄清系统（仅提供参考依据，不做判断）
d.专家手动打分（专家完全自主判断）
e.10年数据存档（5000个标书，2-4TB存储）
f.四层架构：前端层、接入层、应用层、AI服务层
g.分布式处理：20个Worker并行处理，Celery任务编排
h.向量数据库：ChromaDB支持大规模历史数据检索
i.国产化AI：昇腾910B NPU + Qwen系列模型
j.容器化部署：Kubernetes + Docker Compose
k.高并发处理能力（10个标书5分钟完成解析）
l.实时进度推送（WebSocket）
m.AI辅助澄清（降低法律风险）
n.完整审计追踪（10年日志）
o.数据安全保护（AES-256-GCM加密）
p.等保二级合规（审计日志10年）
q.开标时刻瞬时高并发处理
r.300页PDF高效解析
s.向量数据库性能优化
t.AI模型准确性保障
u.等保二级合规准备
02.项目配置架构设计
a.配置架构概览
a.配置管理策略
a.说明
核心理念：
架构定位：
b.代码示例
---
┌─────────────────────────────────────────────┐
│ 配置管理核心 │
│ │
│ ┌────────────┬────────────────────────┐ │
│ │ │ 配置存储 │ │
│ │ │ (PostgreSQL) │ │
│ │ └────────────┴───────────────────┘ │
└──────────────┬───────────────────────────────────┘
│
┌──────────────────┐
│ 环境变量 │
└──────────────────┘
│
┌──────────────────┐
│ 服务配置热更新 │
└──────────────────┘
│
┌──────────────────┐
│ 系统运行时状态 │
└──────────────────┘
---
c.说明
---
d.多环境支持：开发环境（dev）、测试环境（staging）、生产环境（prod）
e.配置分层：应用配置、数据配置、基础设施配置、监控配置
f.配置热更新：不重启服务即可加载新配置
g.配置安全：敏感信息加密存储、访问权限控制
h.配置版本控制：配置变更历史追溯、回滚支持
b.配置存储设计
a.配置数据库模型
a.说明
PostgreSQL配置表设计：
b.代码示例
---
-- 项目配置表
CREATE TABLE t_project_configs (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
config_key VARCHAR(100) NOT NULL,
config_value TEXT NOT NULL, -- JSON格式存储
config_type VARCHAR(50) NOT NULL CHECK (config_type IN ('general', 'scoring_weights', 'ai_model', 'database', 'cache', 'monitoring', 'security')),
environment VARCHAR(20) NOT NULL CHECK (environment IN ('dev', 'staging', 'prod')),
is_encrypted BOOLEAN NOT NULL DEFAULT false, -- 是否加密存储
description TEXT,
default_value TEXT, -- 默认值（用于回滚）
created_by BIGINT NOT NULL REFERENCES t_users(id),
updated_by BIGINT NOT NULL REFERENCES t_users(id),
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 索引
UNIQUE (project_id, config_key, environment),
INDEX idx_configs_project (project_id),
INDEX idx_configs_type (config_type, environment),
INDEX idx_configs_environment (environment)
);
-- 配置变更历史表
CREATE TABLE t_config_history (
id BIGSERIAL PRIMARY KEY,
config_id BIGINT NOT NULL REFERENCES t_project_configs(id),
old_value TEXT NOT NULL,
new_value TEXT NOT NULL,
changed_by BIGINT NOT NULL REFERENCES t_users(id),
changed_reason TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_config_history_config (config_id, created_at DESC)
);
-- 环境变量配置表
CREATE TABLE t_env_variables (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
environment VARCHAR(20) NOT NULL CHECK (environment IN ('dev', 'staging', 'prod')),
var_name VARCHAR(100) NOT NULL,
var_value TEXT NOT NULL,
description TEXT,
created_by BIGINT NOT NULL REFERENCES t_users(id),
updated_by BIGINT NOT NULL REFERENCES t_users(id),
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
UNIQUE (project_id, environment, var_name),
INDEX idx_env_vars_project (project_id),
INDEX idx_env_vars_environment (environment)
);
---
b.配置分层策略
a.表格数据
配置类型 存储位置 敏感度 访问权限
应用配置 PostgreSQL 高 管理员、技术负责人
基础设施配置 PostgreSQL 高 超级管理员
AI模型配置 PostgreSQL 高 技术负责人
监控配置 PostgreSQL 中 管理员、运维负责人
环境变量 Kubernetes ConfigMap 高 超级管理员、DevOps
配置历史 PostgreSQL 低 管理员、审计人员
b.说明
---
c.多环境管理
a.环境定义
a.表格数据
环境 用途 访问权限 部署特点
dev（开发环境） 日常开发、功能测试 开发团队 Kubernetes DevSpace
staging（测试环境） 集成测试、性能测试、UAT 测试团队、DevOps Kubernetes Staging
prod（生产环境） 实际运行、生产数据 运维团队、业务用户 Kubernetes ProdCluster
b.环境配置模型
a.说明
环境配置键：
b.代码示例
---
from pydantic import BaseModel, Field, validator
from typing import Literal, Optional
class EnvironmentConfig(BaseModel):
"""环境配置"""
environment: Literal['dev', 'staging', 'prod']
database_url: str = Field(..., description="PostgreSQL数据库URL")
redis_url: str = Field(..., description="Redis连接URL")
newapi_url: str = Field(..., description="NewAPI网关URL")
# NPU配置
npu_available: bool = Field(default=False, description="NPU是否可用")
npu_models: dict = Field(default={}, description="可用NPU模型列表")
# 缓存配置
cache_enabled: bool = Field(default=True, description="是否启用缓存")
cache_ttl_clarification: int = Field(default=3600, description="澄清缓存TTL（秒）")
cache_ttl_search: int = Field(default=600, description="搜索缓存TTL（秒）")
# 监控配置
monitoring_enabled: bool = Field(default=True, description="是否启用监控")
prometheus_pushgateway: str = Field(default="", description="Prometheus推送网关地址")
grafana_url: str = Field(default="", description="Grafana可视化地址")
# 安全配置
encryption_enabled: bool = Field(default=True, description="是否启用数据加密")
jwt_secret_key: str = Field(..., description="JWT密钥")
encryption_key: str = Field(..., description="数据加密密钥")
# 日志配置
log_level: Literal['DEBUG', 'INFO', 'WARNING', 'ERROR'] = Field(default='INFO', description="日志级别")
log_retention_days: int = Field(default=180, description="日志保留天数")
class ScoringWeightsConfig(BaseModel):
"""评分权重配置"""
technical_weight: float = Field(..., ge=0, le=1, description="技术分权重（0-1）")
commercial_weight: float = Field(..., ge=0, le=1, description="商务分权重（0-1）")
price_weight: float = Field(..., ge=0, le=1, description="价格分权重（0-1）")
@validator('technical_weight', 'commercial_weight', 'price_weight')
def validate_weights_sum(cls, v):
"""验证权重总和必须为1.0"""
if v.technical_weight + v.commercial_weight + v.price_weight != 1.0:
raise ValueError("权重总和必须为1.0")
class AIModelConfig(BaseModel):
"""AI模型配置"""
# Qwen2.5-72B配置
qwen72b_enabled: bool = Field(default=True, description="是否启用Qwen2.5-72B")
qwen72b_endpoint: str = Field(default="", description="Qwen2.5-72B接口地址")
qwen72b_model_name: str = Field(default="Qwen/Qwen2.5-72B-Instruct", description="模型名称")
qwen72b_max_tokens: int = Field(default=4096, description="最大Token数")
qwen72b_temperature: float = Field(default=0.7, description="Temperature参数")
qwen72b_top_k: int = Field(default=5, description="Top-K采样数")
# Qwen2.5-VL-32B配置
qwen32b_enabled: bool = Field(default=True, description="是否启用Qwen2.5-VL-32B")
qwen32b_endpoint: str = Field(default="", description="Qwen2.5-VL-32B接口地址")
qwen32b_model_name: str = Field(default="Qwen/Qwen2.5-VL-32B-Instruct", description="模型名称")
qwen32b_max_tokens: int = Field(default=2048, description="最大Token数")
qwen32b_temperature: float = Field(default=0.7, description="Temperature参数")
# Qwen2-VL-7B配置
qwen7b_enabled: bool = Field(default=False, description="是否启用Qwen2-VL-7B")
qwen7b_endpoint: str = Field(default="", description="Qwen2-VL-7B接口地址")
qwen7b_model_name: str = Field(default="Qwen/Qwen2-VL-7B-Instruct", description="模型名称")
qwen7b_max_tokens: int = Field(default=1024, description="最大Token数")
qwen7b_temperature: float = Field(default=0.7, description="Temperature参数")
class DatabaseConfig(BaseModel):
"""数据库配置"""
# PostgreSQL配置
postgres_host: str = Field(..., description="PostgreSQL主机")
postgres_port: int = Field(default=5432, description="PostgreSQL端口")
postgres_database: str = Field(..., description="数据库名称")
postgres_pool_size: int = Field(default=20, description="连接池大小")
postgres_max_overflow: int = Field(default=10, description="最大溢出连接数")
# Redis配置
redis_host: str = Field(..., description="Redis主机")
redis_port: int = Field(default=6379, description="Redis端口")
redis_db: int = Field(default=0, description="Redis数据库编号（0-15）")
redis_password: str = Field(..., description="Redis密码")
redis_max_connections: int = Field(default=50, description="最大连接数")
# ChromaDB配置
chroma_db_path: str = Field(..., description="ChromaDB数据路径")
chroma_collection_prefix: str = Field(default="project_", description="集合前缀")
chroma_hnsw_space: str = Field(default="cosine", description="HNSW空间类型")
chroma_construction_ef: int = Field(default=200, description="HNSW构建效率参数")
chroma_max_batch_size: int = Field(default=100, description="最大批次大小")
class MonitoringConfig(BaseModel):
"""监控配置"""
# Prometheus配置
prometheus_enabled: bool = Field(default=True, description="是否启用Prometheus")
prometheus_push_url: str = Field(default="", description="Prometheus推送网关地址")
prometheus_scrape_interval: int = Field(default=15, description="抓取间隔（秒）")
# Grafana配置
grafana_enabled: bool = Field(default=True, description="是否启用Grafana")
grafana_url: str = Field(default="", description="Grafana访问地址")
grafana_dashboards: list = Field(default=[], description="监控仪表板列表")
# 告警配置
alert_enabled: bool = Field(default=True, description="是否启用告警")
alert_webhook_url: str = Field(default="", description="告警Webhook地址")
alert_email_recipients: list = Field(default=[], description="告警邮件接收人列表")
alert_thresholds: dict = Field(default={}, description="告警阈值配置")
---
c.环境切换策略
a.配置热更新机制
a.说明
实现方式：
b.代码示例
---
from fastapi import FastAPI, Depends, HTTPException
from typing import Dict
import redis
from pydantic import BaseModel
import asyncio
class ConfigManager:
"""配置管理器"""
def __init__(self):
self.config_cache = {}
self.config_version = 0
self.config_subscribers = set()
self.redis = redis.from_url("redis://localhost:6379/0")
async def load_config(
self,
project_id: int,
environment: str,
force_refresh: bool = False
) -> Dict:
"""加载配置（带缓存）"""
cache_key = f"config:{environment}:{project_id}:v{self.config_version}"
# 尝试从缓存获取
if not force_refresh:
cached = await self.redis.get(cache_key)
if cached:
config_dict = json.loads(cached)
return config_dict
# 从数据库加载
config_dict = await self._load_from_db(project_id, environment)
# 更新缓存
await self.redis.setex(
name=cache_key,
value=json.dumps(config_dict),
ex=300 # 5分钟过期
)
# 通知订阅者
await self._notify_config_update(project_id, config_dict)
return config_dict
async def _load_from_db(
self,
project_id: int,
environment: str
) -> Dict:
"""从数据库加载配置"""
# 构建查询
async with get_db() as db:
configs = await db.execute(
select(t_project_configs)
.where(
t_project_configs.project_id == project_id,
t_project_configs.environment == environment
)
.order_by(t_project_configs.config_key)
)
results = configs.scalars().all()
# 转换为字典
config_dict = {}
for config in results:
config_dict[config.config_key] = {
'value': json.loads(config.config_value),
'type': config.config_type,
'encrypted': config.is_encrypted,
'created_at': config.created_at.isoformat(),
'updated_at': config.updated_at.isoformat()
}
return config_dict
async def update_config(
self,
project_id: int,
environment: str,
config_key: str,
new_value: Any,
user_id: int,
reason: str
):
"""更新配置"""
# 1. 验证配置
if not await self._validate_config(project_id, config_key, new_value):
raise HTTPException(status_code=400, detail="配置验证失败")
# 2. 记录旧值
old_value = await self._get_config_value(project_id, config_key)
# 3. 保存新值到数据库
await self._save_to_db(project_id, config_key, new_value, user_id, reason)
# 4. 记录变更历史
await self._record_config_change(
project_id, config_key, old_value, new_value, user_id, reason
)
# 5. 更新缓存
await self._invalidate_cache(project_id)
# 6. 通知订阅者
await self._notify_config_update(project_id, {
config_key: config_key,
'new_value': new_value
})
return {"status": "success", "message": "配置更新成功"}
async def _validate_config(
self,
project_id: int,
config_key: str,
new_value: Any
) -> bool:
"""验证配置"""
# 检查配置类型约束
config_type = await self._get_config_type(config_key)
validation_result = await self._validate_by_type(config_type, new_value)
return validation_result
async def _get_config_value(
self,
project_id: int,
config_key: str
):
"""获取配置值"""
async with get_db() as db:
config = await db.execute(
select(t_project_configs)
.where(
t_project_configs.project_id == project_id,
t_project_configs.config_key == config_key
)
)
result = config.scalar_one()
if not result:
raise ValueError(f"配置不存在: {config_key}")
# 如果加密，解密
if result.is_encrypted:
return self._decrypt_value(result.config_value)
else:
return json.loads(result.config_value)
async def _save_to_db(
self,
project_id: int,
config_key: str,
new_value: Any,
user_id: int,
reason: str
):
"""保存配置到数据库"""
value_to_save = json.dumps(new_value) if not isinstance(new_value, str) else new_value
async with get_db() as db:
await db.execute(
update(t_project_configs)
.where(
t_project_configs.project_id == project_id,
t_project_configs.config_key == config_key
)
.values(
config_value=value_to_save,
updated_by=user_id,
updated_at=datetime.now()
)
)
---
b.Kubernetes ConfigMap配置
a.说明
Kubernetes ConfigMap示例：
b.代码示例
---
apiVersion: v1
kind: ConfigMap
metadata:
name: evaluation-system-configs
namespace: evaluation-system
data:
# 开发环境配置
dev-configs:
dev-database-config: |
postgresql://evaluator:5432/evaluation_db_dev
redis://evaluator-redis:6379/0
newapi-gateway: http://newapi-service:3000/v1
npu-available: "true"
dev-scoring-weights: |
technical-weight: "0.5"
commercial-weight: "0.3"
price-weight: "0.2"
dev-ai-models: |
qwen72b-enabled: "true"
qwen72b-endpoint: "http://qwen72b-service:8001"
qwen32b-enabled: "true"
qwen32b-endpoint: "http://qwen32b-service:8002"
qwen7b-enabled: "false"
dev-cache-config: |
cache-enabled: "true"
cache-ttl-clarification: "3600"
cache-ttl-search: "600"
dev-monitoring-config: |
monitoring-enabled: "true"
prometheus-push-url: "http://prometheus-pushgateway:9090"
grafana-url: "http://grafana:3000"
alert-enabled: "true"
alert-email-recipients: "[email protected]"
# 测试环境配置
staging-configs:
staging-database-config: |
postgresql://evaluator-staging:5432/evaluation_db_staging
redis://evaluator-redis-staging:6379/0
staging-scoring-weights: |
technical-weight: "0.5"
commercial-weight: "0.3"
price-weight: "0.2"
# 生产环境配置
prod-configs:
prod-database-config: |
postgresql://evaluator-prod-master:5432/evaluation_db_prod
postgresql://evaluator-prod-slave:5432/evaluation_db_prod
prod-cache-config: |
cache-enabled: "true"
cache-ttl-clarification: "3600"
cache-ttl-search: "600"
cache-ttl-tender-metadata: "7200"
prod-ai-models: |
qwen72b-enabled: "true"
qwen72b-endpoint: "http://qwen72b-prod:8001"
qwen32b-enabled: "true"
qwen32b-endpoint: "http://qwen32b-prod:8002"
qwen7b-enabled: "true"
prod-monitoring-config: |
monitoring-enabled: "true"
prometheus-push-url: "http://prometheus-pushgateway-prod:9090"
grafana-url: "http://grafana-prod:3000"
alert-email-recipients: ["[email protected]", "[email protected]"]
---
c.说明
---
d.配置管理API设计
a.配置管理接口
a.说明
FastAPI路由设计：
b.代码示例
---
from fastapi import FastAPI, Depends, HTTPException, Query, status
from pydantic import BaseModel
from typing import List, Optional
router = APIRouter(prefix="/api/configs", tags=["配置管理"])
class ConfigUpdateRequest(BaseModel):
"""配置更新请求"""
config_key: str = Field(..., description="配置键")
config_value: Any = Field(..., description="配置值（JSON字符串）")
environment: Optional[str] = Field(None, description="环境（dev/staging/prod，默认使用当前环境）")
reason: str = Field(..., description="更新原因")
class ConfigResponse(BaseModel):
"""配置响应"""
config_key: str
config_value: Any
config_type: str
encrypted: bool
created_at: str
updated_at: str
@router.get("/{project_id}/configs")
async def get_configs(
project_id: int,
environment: str = Query(..., description="环境（dev/staging/prod，默认使用当前环境）"),
user: User = Depends(get_current_user)
):
"""获取项目所有配置"""
# 权限检查
if not check_config_permission(user, project_id):
raise HTTPException(status_code=403, detail="无权限访问配置")
configs = await config_manager.load_config(project_id, environment)
return {
"project_id": project_id,
"environment": environment,
"configs": configs
}
@router.post("/{project_id}/configs/{config_key}")
async def update_config(
project_id: int,
config_key: str,
request: ConfigUpdateRequest,
environment: Optional[str] = Query(None, description="环境"),
user: User = Depends(get_current_user)
):
"""更新单个配置"""
# 权限检查
if not check_config_permission(user, project_id):
raise HTTPException(status_code=403, detail="无权限修改配置")
result = await config_manager.update_config(
project_id=project_id,
config_key=config_key,
new_value=request.config_value,
environment=environment or get_current_environment(),
user_id=user.id,
reason=request.reason
)
return result
@router.post("/{project_id}/configs/batch-update")
async def batch_update_configs(
project_id: int,
request: dict,
environment: Optional[str] = Query(None),
user: User = Depends(get_current_user)
):
"""批量更新配置"""
# 权限检查
if not check_config_permission(user, project_id):
raise HTTPException(status_code=403, detail="无权限修改配置")
# 批量更新
updated_count = 0
for config_key, new_value in request.items():
result = await config_manager.update_config(
project_id=project_id,
config_key=config_key,
new_value=new_value,
environment=environment or get_current_environment(),
user_id=user.id,
reason="批量更新"
)
if result["status"] == "success":
updated_count += 1
return {
"total": len(request.items()),
"success": updated_count,
"failed": len(request.items()) - updated_count
}
@router.post("/{project_id}/configs/{config_key}/reload")
async def reload_config(
project_id: int,
config_key: str,
environment: Optional[str] = Query(None, description="环境"),
user: User = Depends(get_current_user)
):
"""重新加载配置（从数据库刷新缓存）"""
# 权限检查
if not check_config_permission(user, project_id):
raise HTTPException(status_code=403, detail="无权限重新加载配置")
await config_manager.invalidate_cache(project_id)
return {"status": "success", "message": "配置已重新加载"}
@router.get("/{project_id}/configs/{config_key}/history")
async def get_config_history(
project_id: int,
config_key: str,
limit: int = Query(10, ge=1, le=100, description="返回记录数量限制"),
user: User = Depends(get_current_user)
):
"""获取配置变更历史"""
# 权限检查
if not check_config_permission(user, project_id):
raise HTTPException(status_code=403, detail="无权限访问配置历史")
async with get_db() as db:
history = await db.execute(
select(t_config_history)
.where(t_config_history.config_id == project_id)
.order_by(t_config_history.created_at.desc())
.limit(limit)
)
results = history.scalars().all()
return [
{
"old_value": record.old_value,
"new_value": record.new_value,
"changed_by": record.changed_by,
"changed_reason": record.changed_reason,
"created_at": record.created_at.isoformat()
}
for record in results
]
---
b.权限控制
a.代码示例
---
from enum import Enum
class UserRole(str, Enum):
SUPER_ADMIN = "super_admin"
EVALUATION_ADMIN = "evaluation_admin"
EVALUATION_EXPERT = "evaluation_expert"
USER = "user"
class ConfigPermission(str, Enum):
READ = "read"
WRITE = "write"
RELOAD = "reload"
def check_config_permission(
user_role: UserRole,
project_id: int,
action: ConfigPermission = ConfigPermission.READ
) -> bool:
"""检查配置权限"""
# 超级管理员：所有权限
if user_role == UserRole.SUPER_ADMIN:
return True
# 评标管理员：读写权限
if user_role == UserRole.EVALUATION_ADMIN:
if action in [ConfigPermission.READ, ConfigPermission.WRITE]:
return True
# 评标专家：仅读权限
if user_role == UserRole.EVALUATION_EXPERT:
if action == ConfigPermission.READ:
return True
# 普通用户：无权限
return False
---
b.说明
---
e.配置热更新机制
a.配置热更新流程
a.代码示例
---
┌─────────────────────────────────────────────┐
│ 配置更新（通过API） │
│ │ ┌──────────────┐ │
│ │ │ │ │ │
│ │ │ 前端 │ │ │ │
│ │ └───────────────┘ │ │ │
│ └─────────────────────────────┘ │ │
└────────────────────────────────────────────────────┘
│
┌──────────────┐ │
│ │ │ │
│ 管理后台 │ │ │ │
│ │ │ │ │ │ │
│ └───────────────┘ │ │
│ │ │
│ │ │ │
│ │ │ │ │ │ │ │
│ WebSocket连接 │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
└───────────────┘ │
│ │ │
│ ConfigManager │ │ │ │ │ │ │ │ │ │ │ │
│ └─ invalidate_cache │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │
│ _notify_subscribers │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ Redis Pub/Sub │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ 发布配置更新通知 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │
│ 订阅通道: config:project_id:{project_id}:environment:{environment}
│ 消息: {"action": "config_updated", "config_key": "config_key", "environment": "environment"}
│ │ │
---
b.说明
实现方式：
c.代码示例
---
class ConfigManager:
"""配置管理器"""
async def _notify_subscribers(
self,
project_id: int,
message: dict
):
"""通知配置变更订阅者"""
channel = f"config:project_id:{project_id}:environment:{get_current_environment()}"
# 发布到Redis Pub/Sub
message_str = json.dumps(message)
await self.redis.publish(channel, message_str)
# 记录通知
logger.info(f"Config update notification sent to {channel}: {message}")
async def _invalidate_cache(
self,
project_id: int
):
"""使配置缓存失效"""
environment = get_current_environment()
version = self.config_version + 1
# 使所有环境缓存失效
for env in ['dev', 'staging', 'prod']:
cache_key = f"config:{env}:{project_id}:v{version}"
await self.redis.delete(cache_key)
self.config_version = version
---
d.说明
---
f.数据库连接配置
a.PostgreSQL连接池管理
a.说明
连接池配置：
b.代码示例
---
from sqlalchemy import create_engine, pool
from sqlalchemy.orm import sessionmaker, scoped_session
from typing import Literal
from contextlib import contextmanager
# 环境变量获取数据库连接
DATABASE_URLS = {
'dev': os.getenv('DEV_DATABASE_URL', 'postgresql://localhost:5432/evaluation_db_dev'),
'staging': os.getenv('STAGING_DATABASE_URL', 'postgresql://localhost:5432/evaluation_db_staging'),
'prod-primary': os.getenv('PROD_DATABASE_URL_PRIMARY', 'postgresql://postgres-master:5432/evaluation_db_prod'),
'prod-secondary': os.getenv('PROD_DATABASE_URL_SECONDARY', 'postgresql://postgres-slave:5432/evaluation_db_prod'),
}
# 连接池配置
POOL_CONFIGS = {
'pool_size': int(os.getenv('DB_POOL_SIZE', '20')),
'max_overflow': int(os.getenv('DB_MAX_OVERFLOW', '10')),
'pool_recycle': int(os.getenv('DB_POOL_RECYCLE', '3600')), # 1小时
'pool_pre_ping': True,
'echo': False
}
# 创建连接池
def get_engine(database_url: str) -> Engine:
"""创建数据库引擎"""
return create_engine(
database_url,
pool_size=POOL_CONFIGS['pool_size'],
max_overflow=POOL_CONFIGS['max_overflow'],
pool_pre_ping=POOL_CONFIGS['pool_pre_ping'],
pool_recycle=POOL_CONFIGS['pool_recycle'],
echo=POOL_CONFIGS['echo']
)
# 会话工厂
SessionLocal = scoped_session(
sessionmaker(
autocommit=False,
autoflush=False
)
)
@contextmanager
def get_db():
"""数据库会话上下文管理器"""
engine = get_engine(get_current_database_url())
Session = SessionLocal()
try:
yield Session
Session.commit()
except Exception as e:
Session.rollback()
raise e
---
b.Redis连接池配置
a.说明
Redis连接池配置：
b.代码示例
---
import redis
from typing import Literal
# 环境变量获取Redis连接
REDIS_URLS = {
'dev': os.getenv('DEV_REDIS_URL', 'redis://localhost:6379/0'),
'staging': os.getenv('STAGING_REDIS_URL', 'redis://localhost:6379/1'),
'prod': os.getenv('PROD_REDIS_URL', 'redis://evaluator-redis:6379/2'),
}
# 连接池配置
REDIS_POOL_CONFIGS = {
'max_connections': int(os.getenv('REDIS_MAX_CONNECTIONS', '50')),
'socket_timeout': int(os.getenv('REDIS_SOCKET_TIMEOUT', '5')),
'socket_connect_timeout': int(os.getenv('REDIS_SOCKET_CONNECT_TIMEOUT', '5')),
'socket_keepalive': True,
'decode_responses': True,
'health_check_interval': int(os.getenv('REDIS_HEALTH_CHECK_INTERVAL', '30')),
'retry_on_timeout': True,
'retry_on_timeout': 2,
}
# 创建Redis连接池
redis_pool = redis.ConnectionPool(
host='localhost',
port=6379,
db=0, # 数据库编号
max_connections=REDIS_POOL_CONFIGS['max_connections'],
socket_timeout=REDIS_POOL_CONFIGS['socket_timeout'],
socket_connect_timeout=REDIS_POOL_CONFIGS['socket_connect_timeout'],
socket_keepalive=REDIS_POOL_CONFIGS['socket_keepalive'],
decode_responses=REDIS_POOL_CONFIGS['decode_responses'],
health_check_interval=REDIS_POOL_CONFIGS['health_check_interval'],
retry_on_timeout=REDIS_POOL_CONFIGS['retry_on_timeout'],
retry_on_timeout=REDIS_POOL_CONFIGS['retry_on_timeout'],
)
async def get_redis():
"""获取Redis连接"""
return redis.Redis(
connection_pool=redis_pool,
decode_responses=True
)
---
c.说明
---
g.NPU资源配置
a.NPU模型配置管理
a.说明
NPU配置数据模型：
b.代码示例
---
class NPUModel(BaseModel):
"""NPU模型配置"""
model_id: str = Field(..., description="模型ID")
model_name: str = Field(..., description="模型名称")
model_size: str = Field(..., description="模型大小（如72B、32B、7B）")
tp_size: int = Field(..., ge=1, le=8, description="Tensor Parallel大小")
max_batch_size: int = Field(..., ge=1, description="最大批处理大小")
memory_usage_mb: int = Field(..., description="显存占用（MB）")
is_enabled: bool = Field(default=True, description="是否启用")
endpoint: str = Field(..., description="API端点地址")
# NPU模型配置列表
NPU_MODELS = {
'qwen72b': NPUModel(
model_id="qwen72b",
model_name="Qwen2.5-72B-Instruct",
model_size="72B",
tp_size=2,
max_batch_size=16,
memory_usage_mb=40960,
is_enabled=True,
endpoint="http://qwen72b-service:8001"
),
'qwen32b': NPUModel(
model_id="qwen32b",
model_name="Qwen2.5-VL-32B-Instruct",
model_size="32B",
tp_size=1,
max_batch_size=32,
memory_usage_mb=20480,
is_enabled=True,
endpoint="http://qwen32b-service:8002"
),
'qwen7b': NPUModel(
model_id="qwen7b",
model_name="Qwen2-VL-7B-Instruct",
model_size="7B",
tp_size=1,
max_batch_size=64,
memory_usage_mb=7168,
is_enabled=False, # 默认禁用
endpoint="http://qwen7b-service:8003"
),
'paddle_ocr': NPUModel(
model_id="paddle_ocr",
model_name="PaddleOCR PP-OCRv4",
model_size="-",
tp_size=1,
max_batch_size=8,
memory_usage_mb=5120,
is_enabled=True,
endpoint="http://paddle-ocr-service:8004"
)
}
class NPUAllocationConfig(BaseModel):
"""NPU资源分配配置"""
# 开标时刻优先级配置
tender_moment_priority_models: list[str] = Field(
default=["qwen72b", "qwen32b", "paddle_ocr"],
description="开标时刻优先使用的模型列表"
)
# 平时处理配置
normal_processing_models: list[str] = Field(
default=["qwen72b"],
description="平时处理使用的模型列表"
)
# NPU资源分配策略
allocation_strategy: Literal['static', 'dynamic'] = Field(
default="dynamic",
description="分配策略：static（静态分配）/dynamic（动态分配）"
)
# 负载均衡策略
load_balancing: Literal['round_robin', 'least_connections', 'resource_based'] = Field(
default='resource_based',
description="负载均衡策略"
)
---
c.说明
---
h.监控配置设计
a.监控指标配置
a.说明
Prometheus指标定义：
b.代码示例
---
from prometheus_client import Counter, Gauge, Histogram
# 应用指标
http_requests_total = Counter('http_requests_total', 'HTTP请求总数')
http_request_duration_seconds = Histogram('http_request_duration_seconds', 'HTTP请求耗时（秒）')
# 任务指标
celery_tasks_total = Counter('celery_tasks_total', 'Celery任务总数')
celery_tasks_pending = Gauge('celery_tasks_pending', 'Celery待处理任务数')
celery_tasks_failed_total = Counter('celery_tasks_failed_total', 'Celery失败任务数')
celery_task_duration_seconds = Histogram('celery_task_duration_seconds', 'Celery任务耗时（秒）')
# NPU指标
npu_memory_usage_percent = Gauge('npu_memory_usage_percent', 'NPU内存使用率')
npu_utilization_percent = Gauge('npu_utilization_percent', 'NPU利用率')
qwen72b_inference_requests = Counter('qwen72b_inference_requests', 'Qwen72B推理请求数')
qwen32b_inference_requests = Counter('qwen32b_inference_requests', 'Qwen32B推理请求数')
# 数据库指标
postgres_connections_active = Gauge('postgres_connections_active', 'PostgreSQL活动连接数')
postgres_query_duration_seconds = Histogram('postgres_query_duration_seconds', 'PostgreSQL查询耗时（秒）')
postgres_slow_queries_total = Counter('postgres_slow_queries_total', 'PostgreSQL慢查询总数')
# 缓存指标
redis_cache_hit_rate = Gauge('redis_cache_hit_rate', 'Redis缓存命中率')
redis_memory_usage_bytes = Gauge('redis_memory_usage_bytes', 'Redis内存使用（字节）')
# 告警指标
alert_total = Counter('alert_total', '告警总数')
alert_triggered = Counter('alert_triggered', '告警触发总数')
alert_response_time_seconds = Histogram('alert_response_time_seconds', '告警响应时间（秒）')
---
b.告警规则配置
a.说明
告警规则定义：
b.代码示例
---
class AlertRule(BaseModel):
"""告警规则"""
rule_id: str = Field(..., description="规则ID")
rule_name: str = Field(..., description="规则名称")
metric_name: str = Field(..., description="指标名称")
operator: Literal['>', '<', '>=', '<=', '==', '!='] = Field(..., description="比较操作符")
threshold: float = Field(..., description="阈值")
severity: Literal['info', 'warning', 'critical'] = Field(..., description="严重级别")
duration: int = Field(..., default=60, description="持续时间（秒）")
enabled: bool = Field(default=True, description="是否启用")
@validator('operator')
def validate_operator_combination(cls, v):
"""验证比较操作符组合"""
if v.operator in ['<', '>']:
if v.operator in ['<', '>']:
raise ValueError("不能同时使用<和>")
return v
# 默认告警规则
DEFAULT_ALERT_RULES = [
AlertRule(
rule_id="http_500_error_rate",
rule_name="HTTP 500错误率过高",
metric_name="http_requests_total",
operator=">",
threshold=10,
severity="critical",
duration=300 # 5分钟
),
AlertRule(
rule_id="celery_task_failure_rate",
rule_name="Celery任务失败率过高",
metric_name="celery_tasks_failed_total",
operator=">",
threshold=5,
severity="critical",
duration=300
),
AlertRule(
rule_id="npu_memory_high",
rule_name="NPU内存使用率过高",
metric_name="npu_memory_usage_percent",
operator=">",
threshold=90,
severity="warning",
duration=60
),
AlertRule(
rule_id="redis_cache_hit_low",
rule_name="Redis缓存命中率过低",
metric_name="redis_cache_hit_rate",
operator="<",
threshold=0.5,
severity="warning",
duration=300
),
AlertRule(
rule_id="db_connection_pool_exhaustion",
rule_name="数据库连接池耗尽",
metric_name="postgres_connections_active",
operator=">",
threshold=18,
severity="warning",
duration=120
)
]
---
c.说明
---
i.安全配置设计
a.加密配置
a.说明
加密密钥管理：
b.代码示例
---
from cryptography.fernet import Fernet
from typing import Optional
class EncryptionConfig(BaseModel):
"""加密配置"""
# 主加密密钥（轮换密钥）
master_key: str = Field(..., description="主加密密钥")
key_rotation_days: int = Field(default=90, description="密钥轮换周期（天）")
last_rotation_date: Optional[str] = Field(None, description="上次轮换日期")
# 数据加密密钥
data_key: str = Field(..., description="数据加密密钥")
# 签级配置
encryption_level: Literal['AES-256-GCM'] = Field(default="AES-256-GCM", description="加密等级")
key_derivation_iterations: int = Field(default=100000, description="密钥派生迭代次数")
@validator('key_rotation_days')
def validate_rotation_period(cls, v):
if v.key_rotation_days < 7:
raise ValueError("密钥轮换周期不能少于7天")
return v
---
c.说明
加密服务封装：
d.代码示例
---
from cryptography.fernet import Fernet
class EncryptionService:
"""加密服务"""
def __init__(self, master_key: str, data_key: str):
self.master_cipher = Fernet(master_key)
self.data_cipher = Fernet(data_key)
def encrypt_data(self, data: bytes) -> bytes:
"""加密数据"""
return self.data_cipher.encrypt(data)
def decrypt_data(self, encrypted: bytes) -> bytes:
"""解密数据"""
return self.data_cipher.decrypt(encrypted)
def encrypt_string(self, text: str) -> str:
"""加密字符串"""
return self.encrypt_data(text.encode()).decode()
def decrypt_string(self, encrypted: str) -> str:
"""解密字符串"""
return self.decrypt_data(encrypted.encode()).decode()
def encrypt_dict(self, data: dict) -> str:
"""加密字典"""
return self.encrypt_string(json.dumps(data))
def decrypt_dict(self, encrypted: str) -> dict:
"""解密字典"""
return json.loads(self.decrypt_string(encrypted))
---
b.JWT认证配置
a.说明
JWT配置：
b.代码示例
---
from jose import JWTError, ExpiredSignatureError
from datetime import datetime, timedelta
from typing import Optional
class JWTConfig(BaseModel):
"""JWT配置"""
secret_key: str = Field(..., description="JWT密钥")
algorithm: str = Field(default="HS256", description="加密算法（HS256/RS384）")
access_token_expire_minutes: int = Field(default=480, description="访问Token过期时间（分钟）")
refresh_token_expire_days: int = Field(default=30, description="刷新Token过期时间（天）")
issuer: str = Field(default="evaluation-system", description="签发者")
audience: str = Field(default="evaluation-api", description="受众")
# JWT服务
class JWTService:
"""JWT服务"""
def __init__(self, config: JWTConfig):
self.secret_key = config.secret_key
self.algorithm = config.algorithm
self.access_token_expire_minutes = config.access_token_expire_minutes
self.refresh_token_expire_days = config.refresh_token_expire_days
self.issuer = config.issuer
self.audience = config.audience
def create_access_token(
self,
user_id: int,
additional_claims: dict = None
) -> dict:
"""创建访问Token"""
now = datetime.utcnow()
expire = now + timedelta(minutes=self.access_token_expire_minutes)
payload = {
'sub': str(user_id),
'iat': now.timestamp(),
'exp': expire.timestamp(),
'iss': self.issuer,
'aud': self.audience,
'jti': str(uuid.uuid4()),
**additional_claims
}
token = jwt.encode(
payload,
self.secret_key,
algorithm=self.algorithm
)
return {
'token': token,
'expire': expire,
'issued_at': now.isoformat()
}
def verify_token(self, token: str) -> dict:
"""验证Token"""
try:
payload = jwt.decode(
token,
self.secret_key,
algorithms=[self.algorithm],
issuer=self.issuer,
audience=self.audience
)
return {
'valid': True,
'payload': payload
}
except ExpiredSignatureError:
return {
'valid': False,
'error': 'Token已过期'
}
except JWTError as e:
return {
'valid': False,
'error': str(e)
}
---
c.说明
---
j.日志配置设计
a.日志级别与格式
a.说明
日志级别定义：
b.表格数据
级别 用途 示例
DEBUG 开发调试 SQL查询、详细执行流程、中间变量值
INFO 一般信息 配置加载、任务开始/完成、用户操作
WARNING 警告信息 缓存命中率低、连接池接近满
ERROR 错误信息 任务失败、异常捕获、数据库错误、网络错误
CRITICAL 严重错误 系统不可用、数据损坏、安全漏洞
c.说明
日志格式配置：
d.代码示例
---
import logging
import logging.handlers
from typing import Optional
# 日志格式配置
LOG_FORMAT = '%(asctime)s - %(name)s - %(levelname)s - [%(funcName)s:%(lineno)d] - %(message)s'
LOG_DATE_FORMAT = '%Y-%m-%d %H:%M:%S'
LOG_FILE_DIR = '/var/log/evaluation'
LOG_MAX_BYTES = 100 * 1024 * 1024 # 100MB
# 配置不同级别的日志文件
LOG_FILES = {
'DEBUG': '/var/log/evaluation/debug.log',
'INFO': '/var/log/evaluation/info.log',
'WARNING': '/var/log/evaluation/warning.log',
'ERROR': '/var/log/evaluation/error.log',
'CRITICAL': '/var/log/evaluation/critical.log'
}
# 配置日志处理器
def setup_logging(log_level: str = 'INFO'):
"""配置日志系统"""
# 设置日志级别
logger.setLevel(getattr(logging, log_level.upper()))
# 清理现有处理器
logging.getLogger().handlers.clear()
# 创建不同级别的文件处理器
handlers = []
for level, filename in LOG_FILES.items():
if get_log_level_name(level) >= get_log_level_name(log_level):
handler = logging.handlers.RotatingFileHandler(
filename=filename,
when='midnight',
backupCount=5, # 保留5个历史文件
maxBytes=LOG_MAX_BYTES,
encoding='utf-8'
)
handler.setFormatter(logging.Formatter(LOG_FORMAT))
handlers.append(handler)
# 控制台处理器
console_handler = logging.StreamHandler()
console_handler.setFormatter(logging.Formatter(LOG_FORMAT))
handlers.append(console_handler)
# 配置根logger
root_logger = logging.getLogger()
root_logger.setLevel(getattr(logging, log_level.upper()))
root_logger.handlers = handlers
return root_logger
# 创建不同日志器的辅助函数
def get_logger(name: str) -> logging.Logger:
"""获取指定名称的日志器"""
return logging.getLogger(name)
# 使用示例
app_logger = get_logger('app')
config_logger = get_logger('config')
api_logger = get_logger('api')
task_logger = get_logger('task')
error_logger = get_logger('error')
---
e.说明
---
k.环境变量管理
a.Kubernetes环境变量配置
a.说明
环境变量清单：
b.代码示例
---
# 应用配置
APP_NAME=evaluation-system
APP_ENV=prod # dev/staging/prod
APP_VERSION=1.0.0
APP_PORT=8080
# 数据库配置
DB_HOST=postgres-evaluator-prod-master
DB_PORT=5432
DB_NAME=evaluation_db_prod
DB_USER=evaluator
DB_PASSWORD=${DB_PASSWORD}
DB_POOL_SIZE=20
DB_MAX_OVERFLOW=10
# Redis配置
REDIS_HOST=redis-evaluator
REDIS_PORT=6379
REDIS_DB=0
REDIS_PASSWORD=${REDIS_PASSWORD}
REDIS_MAX_CONNECTIONS=50
# AI模型配置
QWEN72B_ENABLED=true
QWEN72B_ENDPOINT=http://qwen72b-service:8001
QWEN32B_ENABLED=true
QWEN32B_ENDPOINT=http://qwen32b-service:8002
QWEN7B_ENABLED=false
# NewAPI配置
NEWAPI_GATEWAY=http://newapi-gateway:3000/v1
NEWAPI_API_KEY=${NEWAPI_API_KEY}
# 监控配置
PROMETHEUS_ENABLED=true
PROMETHEUS_PUSH_URL=http://prometheus-pushgateway:9090
GRAFANA_URL=http://grafana:3000
ALERT_ENABLED=true
ALERT_WEBHOOK_URL=${ALERT_WEBHOOK_URL}
# 安全配置
ENCRYPTION_ENABLED=true
ENCRYPTION_KEY_ROTATION_DAYS=90
JWT_SECRET_KEY=${JWT_SECRET_KEY}
JWT_ACCESS_TOKEN_EXPIRE_MINUTES=480
JWT_REFRESH_TOKEN_EXPIRE_DAYS=30
# 日志配置
LOG_LEVEL=INFO
LOG_MAX_BYTES=104857600 # 100MB
LOG_RETENTION_DAYS=180
# 运维配置
HEALTH_CHECK_ENABLED=true
HEALTH_CHECK_INTERVAL_SECONDS=30
---
b.环境变量加载
a.说明
环境变量加载模块：
b.代码示例
---
import os
from typing import Dict, Optional
from pydantic import BaseModel, Field
class EnvConfig(BaseModel):
"""环境配置加载"""
# 数据库配置
db_host: str = Field(..., default="localhost")
db_port: int = Field(..., default=5432)
db_name: str = Field(..., default="evaluation_db")
db_user: str = Field(..., default="evaluator")
db_password: str = Field(..., default="")
# Redis配置
redis_host: str = Field(..., default="localhost")
redis_port: int = Field(..., default=6379)
redis_db: int = Field(..., default=0)
redis_password: str = Field(..., default="")
# AI模型配置
qwen72b_enabled: bool = Field(..., default=True)
qwen72b_endpoint: str = Field(..., default="")
qwen32b_enabled: bool = Field(..., default=True)
qwen32b_endpoint: str = Field(..., default="")
# NewAPI配置
newapi_gateway: str = Field(..., default="")
newapi_api_key: str = Field(..., default="")
# 安全配置
encryption_enabled: bool = Field(..., default=True)
jwt_secret_key: str = Field(..., default="")
# 监控配置
prometheus_enabled: bool = Field(..., default=True)
grafana_url: str = Field(..., default="")
def load_env_config() -> EnvConfig:
"""加载环境变量"""
return EnvConfig(
db_host=os.getenv('DB_HOST', 'localhost'),
db_port=int(os.getenv('DB_PORT', '5432')),
db_name=os.getenv('DB_NAME', 'evaluation_db'),
db_user=os.getenv('DB_USER', 'evaluator'),
db_password=os.getenv('DB_PASSWORD', ''),
redis_host=os.getenv('REDIS_HOST', 'localhost'),
redis_port=int(os.getenv('REDIS_PORT', '6379')),
redis_db=int(os.getenv('REDIS_DB', '0')),
redis_password=os.getenv('REDIS_PASSWORD', ''),
qwen72b_enabled=os.getenv('QWEN72B_ENABLED', 'true').lower() == 'true',
qwen72b_endpoint=os.getenv('QWEN72B_ENDPOINT', ''),
qwen32b_enabled=os.getenv('QWEN32B_ENABLED', 'true').lower() == 'true',
qwen32b_endpoint=os.getenv('QWEN32B_ENDPOINT', ''),
newapi_gateway=os.getenv('NEWAPI_GATEWAY', ''),
newapi_api_key=os.getenv('NEWAPI_API_KEY', ''),
prometheus_enabled=os.getenv('PROMETHEUS_ENABLED', 'true').lower() == 'true',
prometheus_push_url=os.getenv('PROMETHEUS_PUSH_URL', ''),
grafana_url=os.getenv('GRAFANA_URL', ''),
encryption_enabled=os.getenv('ENCRYPTION_ENABLED', 'true').lower() == 'true',
jwt_secret_key=os.getenv('JWT_SECRET_KEY', '')
)
def get_current_environment() -> str:
"""获取当前运行环境"""
return os.getenv('APP_ENV', 'prod')
---
c.说明
---
l.配置管理UI设计
a.配置管理界面布局
a.代码示例
---
┌─────────────────────────────────────────────┐
│ 配置管理界面 │
│ │
│ ┌────────────┬────────────────────────┐ │
│ │ │ 左侧：配置分类树 │ │
│ │ ├─ ①. 基础配置 │ │
│ │ │ • 数据库配置 │ │
│ │ │ • Redis配置 │ │
│ │ │ • AI模型配置 │ │
│ │ │ • 监控配置 │ │
│ │ │ • 安全配置 │ │
│ │ │ • 日志配置 │ │
│ │ │ • NPU配置 │ │
│ │ ├─ ②. 评分权重配置 │ │
│ │ │ • 技术分权重 │ │
│ │ │ • 商务分权重 │ │
│ │ │ • 价格分权重 │ │
│ │ │ • 权重总和验证 │ │
│ │ └───────────────────────────┘ │
│ │ │
│ │ 右侧：配置编辑器 │ │
│ │ │
│ │ ┌──────────────────────────┐ │
│ │ │ 配置表单 │ │
│ │ │ • 配置键 │ │
│ │ │ • 当前值 │ │
│ │ │ • 类型 │ │
│ │ │ • 是否加密 │ │
│ │ │ • 更新时间 │ │
│ │ │ │ • 操作 │ │
│ │ │ └───────────────────────────┘ │
│ │ │
│ └─────────────────────────────────────┘
---
b.配置编辑器功能
a.说明
配置编辑器组件：
---
b.✅ 实时验证：保存前验证配置合法性
c.✅ 版本控制：每次更新创建版本快照
d.✅ 回滚支持：可回滚到任意历史版本
e.✅ 差异对比：显示配置差异，高亮变更部分
f.✅ 导入导出：支持YAML/JSON格式配置导入导出
g.✅ 配置预览：配置变更后可预览效果
h.✅ 变更审计：完整的配置变更历史追溯
m.配置变更通知
a.WebSocket实时推送
a.说明
通知消息类型：
b.表格数据
消息类型 触发条件 通知内容
config_updated 配置通过API更新 配置键、新值、操作人、时间
config_reloaded 配置重新加载 环境、版本号、操作人、时间
config_validation_failed 配置验证失败 配置键、错误信息
alert_triggered 告警规则触发 告警规则、指标值、时间
config_rollback 配置回滚 配置键、回滚版本、操作人、时间
c.说明
通知内容格式：
d.代码示例
---
{
"type": "config_updated",
"timestamp": "2026-01-16T10:30:00Z",
"project_id": 678,
"environment": "prod",
"user_id": 567,
"username": "admin_tom",
"data": {
"config_key": "cache_ttl_search",
"old_value": "600",
"new_value": "300",
"changed_reason": "优化缓存TTL以提升性能"
}
}
---
e.说明
---
n.总结与关键点
a.核心设计原则
a.表格数据
原则 说明
多环境支持 dev/staging/prod环境独立配置，隔离测试与生产
配置热更新 支持运行时更新配置，无需重启服务
权限分级 超级管理员可修改所有配置，评标管理员可修改业务配置，普通用户只读
配置加密 敏感信息加密存储，密钥轮换机制
审计追踪 所有配置变更完整记录，支持回滚
监控告警 配置相关的指标异常告警，实时通知
NPU资源管理 模型启用/禁用，资源分配策略动态配置
b.关键性能指标
a.表格数据
指标 目标值 监控方式
配置加载时间 <100ms Prometheus监控
配置更新响应时间 <200ms API响应监控
配置缓存命中率 >90% Redis监控
环境切换响应时间 <5秒 手动触发的环境切换
c.下一步行动
a.说明
已完成第42号文档：✅
待撰写文档（共11份）：
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
b.数据库架构设计.md
c.AI服务架构设计.md
d.后端API架构设计.md
e.前端架构设计.md
f.API接口设计.md
g.部署架构设计.md
h.安全架构设计.md
i.监控告警架构设计.md
j.测试架构设计.md
k.运维架构设计.md
03.数据库架构设计
a.数据库架构设计
a.数据库设计概览
a.架构选型
PostgreSQL 13+ 原因：
1.✅ 关系型+JSONB：标书元数据、解析结果、评分数据需要关系型，复杂评标规则需要灵活查询
2.✅ 开源免费：无许可成本，社区支持成熟
3.✅ 性能优秀：支持百万级数据，高并发场景
4.✅ 国产化支持：满足信创要求
5.✅ 生态完善：丰富的Python生态（SQLAlchemy、Alembic、asyncpg等）
ChromaDB原因：
1.✅ 开源免费：无许可成本，支持大规模向量数据
2.✅ 高性能：HNSW索引，毫秒级检索
3.✅ Python友好：原生Python API，易于集成
4.✅ 轻量级：适合中小规模数据（5000个标书）
Redis原因：
1.✅ 高性能：内存缓存，亚毫秒级响应
2.✅ 发布订阅：WebSocket实时推送依赖
3.✅ 数据结构丰富：支持List、Set、Hash、Sorted Set
4.✅ 持久化支持：AOF/RDB持久化，数据不丢失
---
b.数据库表结构设计
a.核心表设计
a.项目表（t_projects）
a.说明
用途： 存储评标项目信息，配置元数据，生命周期管理
b.代码示例
---
CREATE TABLE t_projects (
id BIGSERIAL PRIMARY KEY,
project_code VARCHAR(50) NOT NULL UNIQUE, -- 项目唯一编码
project_name VARCHAR(200) NOT NULL, -- 项目名称
project_type VARCHAR(50) NOT NULL, -- 项目类型（工程建设、设备采购、服务采购等）
budget_amount DECIMAL(15, 2) NOT NULL, -- 预算金额（万元，精度2位）
budget_range VARCHAR(20), -- 预算范围（<50万, 50-100万, 100-500万, >500万）
-- 时间线字段
planned_opening_date DATE NOT NULL, -- 计划开标日期
actual_opening_date TIMESTAMP NOT NULL, -- 实际开标时间
evaluation_deadline DATE, -- 评标截止日期
evaluation_date TIMESTAMP, -- 评标完成日期
-- 状态字段
status VARCHAR(20) NOT NULL CHECK (status IN ('draft', 'preparation', 'opened', 'evaluating', 'closed', 'archived')),
-- 元数据
evaluation_method VARCHAR(100), -- 评标方法（综合评分法、最低评标价法、性价比评标法）
scoring_config JSONB, -- 评分配置（JSON格式，存储权重规则）
-- 创建时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 约束
UNIQUE (project_code),
INDEX idx_projects_code (project_code),
INDEX idx_projects_date (planned_opening_date DESC),
INDEX idx_projects_type (project_type)
);
-- 评标方法枚举
CREATE TYPE project_status_type AS ENUM ('draft', 'preparation', 'opened', 'evaluating', 'closed', 'archived');
CREATE TYPE evaluation_method AS ENUM ('comprehensive', 'lowest_price', 'cost_benefit', 'technical_only', 'commercial_only');
---
c.说明
字段说明：
d.project_code：项目唯一标识，格式如 PRJ-2025-001
e.project_type：项目分类（工程建设、设备采购、服务采购等）
f.status：项目生命周期状态
g.scoring_config：JSONB格式存储评分权重配置
b.供应商表（t_suppliers）
a.说明
用途： 存储供应商信息，资质等级，信用评级，联系方式
b.代码示例
---
CREATE TABLE t_suppliers (
id BIGSERIAL PRIMARY KEY,
supplier_code VARCHAR(50) NOT NULL UNIQUE, -- 供应商唯一编码
supplier_name VARCHAR(200) NOT NULL, -- 供应商名称
legal_entity VARCHAR(200), -- 法律实体名称
unified_social_credit_code VARCHAR(100), -- 统一社会信用代码
-- 资质信息
qualification_level VARCHAR(20) NOT NULL, -- 资质等级（AAA/AA/A/BBB/BB/C/CCC/CC）
credit_rating VARCHAR(10), -- 信用评级（AAA/AA/A/BBB/BB/C/CCC/CC）
-- 联系信息
contact_person VARCHAR(100), -- 联系人
contact_phone VARCHAR(20),
contact_email VARCHAR(100),
contact_address TEXT, -- 公司地址
-- 审计信息
is_active BOOLEAN DEFAULT true NOT NULL, -- 是否活跃
blacklisted BOOLEAN DEFAULT false NOT NULL, -- 是否黑名单
evaluation_count INT DEFAULT 0, -- 累计评标次数
successful_tenders_count INT DEFAULT 0, -- 中标次数
avg_score DECIMAL(5, 2), -- 平均得分
-- 创建/更新时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_suppliers_code (supplier_code),
INDEX idx_suppliers_credit (credit_rating DESC),
INDEX idx_suppliers_active (is_active, status DESC)
);
-- 信用评级枚举
CREATE TYPE credit_rating AS ENUM ('AAA', 'AA', 'A', 'BBB', 'BB', 'C', 'CCC', 'CC');
---
c.标书表（t_tenders）
a.说明
用途： 存储每个标书文件信息、解析状态、解析结果
b.代码示例
---
CREATE TABLE t_tenders (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id) ON DELETE CASCADE,
supplier_id BIGINT NOT NULL REFERENCES t_suppliers(id) ON DELETE CASCADE,
-- 标书基本信息
tender_name VARCHAR(200) NOT NULL, -- 标书名称
file_path VARCHAR(500) NOT NULL, -- 文件存储路径（NFS/OSS）
file_size BIGINT NOT NULL, -- 文件大小（字节）
file_hash CHAR(64) NOT NULL, -- SHA-256哈希（用于去重）
-- 文档信息
page_count INTEGER NOT NULL, -- 页数
upload_status VARCHAR(20) NOT NULL CHECK (upload_status IN ('uploading', 'parsing', 'indexed', 'failed')),
upload_timestamp TIMESTAMP NOT NULL DEFAULT NOW(),
parse_timestamp TIMESTAMP,
index_timestamp TIMESTAMP,
-- 解析结果
parse_status VARCHAR(20) NOT NULL CHECK (parse_status IN ('pending', 'processing', 'completed', 'failed')),
parse_result JSONB NOT NULL, -- 解析结果（结构化数据）
parse_error_message TEXT, -- 解析错误信息
-- 状态约束
CONSTRAINT check_upload_parse_status
CHECK (
(upload_status = 'uploading' AND parse_status IS NULL) OR
(upload_status = 'parsing' AND parse_status IN ('pending', 'processing', 'completed', 'failed')),
CHECK (
(upload_status = 'indexed' AND parse_status = 'completed') OR
(upload_status = 'indexed' AND parse_status IS NULL)
),
CHECK (
(upload_status = 'failed' AND parse_status IS NULL) OR
(upload_status = 'failed' AND parse_status = 'failed')
);
-- 审计信息
evaluation_count INT DEFAULT 0, -- 被评分次数
total_score DECIMAL(6, 2), -- 总得分
rank INT, -- 排名
-- 索引
INDEX idx_tenders_project (project_id),
INDEX idx_tenders_supplier (supplier_id),
INDEX idx_tenders_status (upload_status, parse_status),
INDEX idx_tenders_timestamp (upload_timestamp DESC),
INDEX idx_tenders_file_hash (file_hash);
---
d.解析结果表（t_parse_results）
a.说明
用途： 存储文档解析的结构化结果，支持分片解析结果汇总
b.代码示例
---
CREATE TABLE t_parse_results (
id BIGSERIAL PRIMARY KEY,
tender_id BIGINT NOT NULL REFERENCES t_tenders(id) ON DELETE CASCADE,
-- 解析类型
parse_type VARCHAR(20) NOT NULL CHECK (parse_type IN ('ocr', 'table_structure', 'multimodal')),
-- 解析状态
parse_status VARCHAR(20) NOT NULL CHECK (parse_status IN ('pending', 'processing', 'completed', 'failed')),
-- 解析结果数据（JSONB）
result_data JSONB NOT NULL, -- 解析结果（结构化数据）
error_message TEXT, -- 错误信息
-- 性能追踪
start_time TIMESTAMP NOT NULL,
end_time TIMESTAMP,
-- 审计信息
model_version VARCHAR(50), -- 使用的模型版本（如qwen2.5-72b-v1.0）
processing_time_ms INT, -- 处理耗时（毫秒）
-- 创建/更新时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_parse_results_tender (tender_id, parse_status, start_time DESC)
);
---
c.说明
解析类型枚举：
d.代码示例
---
CREATE TYPE parse_type AS ENUM ('ocr', 'table_structure', 'multimodal');
---
e.说明
result_data JSONB结构示例：
f.代码示例
---
{
"pages": [
{
"page_number": 1,
"text_content": "OCR识别的文字内容",
"confidence": 0.98
},
{
"page_number": 1,
"table_regions": [
{
"bbox": {"x": 100, "y": 200, "width": 300, "height": 50},
"type": "table",
"headers": ["技术参数", "数值", "单位"],
"data": [["CPU主频", "3.2GHz", "GHz"]]
}
]
}
],
"document_structure": {
"sections": [
{
"section_number": "1",
"section_title": "技术规格",
"page_range": "1-10",
"confidence": 0.95
}
]
}
}
---
e.澄清记录表（t_clarifications）
a.说明
用途： 存储专家提问和AI澄清结果，审计追踪
b.代码示例
---
CREATE TABLE t_clarifications (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id) ON DELETE CASCADE,
expert_id BIGINT NOT NULL REFERENCES t_users(id),
-- 澄清信息
question TEXT NOT NULL, -- 专家提问
ai_response JSONB NOT NULL, -- AI澄清结果
expert_action VARCHAR(20) NOT NULL CHECK (expert_action IN ('accepted', 'rejected', 'modified', 'ignored')),
expert_notes TEXT, -- 专家备注
evaluation_reference_ids BIGINT[] NOT NULL, -- 评估标书ID列表（澄清时参考的标书）
-- AI分析数据
model_version VARCHAR(50), -- AI模型版本
model_name VARCHAR(100), -- AI模型名称
processing_time_ms INT, -- AI处理耗时（毫秒）
-- 审计信息
ip_address INET NOT NULL, -- 专家IP地址
user_agent TEXT, -- User-Agent
status VARCHAR(20) NOT NULL DEFAULT 'success' CHECK (status IN ('success', 'failed'),
error_message TEXT,
-- 创建/更新时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_clarifications_project (project_id),
INDEX idx_clarifications_expert (expert_id),
INDEX idx_clarifications_timestamp (created_at DESC)
);
---
c.说明
专家动作枚举：
d.代码示例
---
CREATE TYPE expert_action AS ENUM ('accepted', 'rejected', 'modified', 'ignored');
---
f.评分记录表（t_scores）
a.说明
用途： 存储专家打分数据，支持权重配置
b.代码示例
---
CREATE TABLE t_scores (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id) ON DELETE CASCADE,
tender_id BIGINT NOT NULL REFERENCES t_tenders(id) ON DELETE CASCADE,
expert_id BIGINT NOT NULL REFERENCES t_users(id),
-- 评分项
technical_score DECIMAL(5, 2) NOT NULL CHECK (technical_score >= 0 AND technical_score <= 100),
commercial_score DECIMAL(5, 2) NOT NULL CHECK (commercial_score >= 0 AND commercial_score <= 100),
price_score DECIMAL(5, 2) NOT NULL CHECK (price_score >= 0 AND price_score <= 100),
-- 综合得分
total_score DECIMAL(6, 2) NOT NULL,
-- 权重配置引用（存储权重配置ID，用于追溯）
scoring_config_id BIGINT REFERENCES t_project_configs(id),
-- 专家备注
expert_comments TEXT,
-- 排名（系统计算，每次打分后更新）
rank INT,
-- 审计信息
evaluated_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 约束
UNIQUE (project_id, tender_id, expert_id),
INDEX idx_scores_project_tender (project_id, tender_id),
INDEX idx_scores_expert (expert_id, evaluated_at DESC),
INDEX idx_scores_total_score (total_score DESC),
INDEX idx_scores_rank (rank);
---
c.说明
评分规则约束：
d.所有分值为0-100之间
e.权重配置总和必须为1.0
f.同一专家对同一标书的评分不能重复（UNIQUE约束防止）
g.技术分×0.5 + 商务分×0.3 + 价格分×0.2 = 总分（精确到2位小数）
g.审计日志表（t_audit_logs）
a.说明
用途： 完整审计追踪，满足等保二级要求
审计日志类型：
1.AI调用日志：AI服务调用记录
2.专家操作日志：评分、复核、查询操作
3.系统操作日志：配置更新、系统管理
4.安全日志：认证失败、权限拒绝、数据泄露
5.异常日志：系统错误、网络异常
b.代码示例
---
CREATE TABLE t_audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL REFERENCES t_users(id),
-- 审计分类
action VARCHAR(50) NOT NULL CHECK (
action IN (
-- AI服务调用
'submit_clarification',
'get_clarification_history',
-- 专家操作
'submit_score',
'get_scores',
'update_score',
'delete_score',
-- 系统操作
'get_config',
'update_config',
'batch_update_config',
'reload_config',
-- 安全操作
'login',
'logout'
)
),
-- 资源类型
resource_type VARCHAR(50) NOT NULL CHECK (
resource_type IN (
-- AI服务
'ai_service',
'clarification',
'tender',
'project',
'config',
'score'
)
),
resource_id BIGINT, -- 资源ID
-- 请求数据（JSONB）
request_data JSONB,
-- 响应数据（JSONB）
response_data JSONB,
-- 结果状态
status VARCHAR(20) NOT NULL DEFAULT 'success' CHECK (status IN ('success', 'failed')),
error_message TEXT,
-- 审计信息
ip_address INET NOT NULL,
user_agent TEXT,
-- 创建/更新时间
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_audit_logs_user_created (user_id, created_at DESC),
INDEX idx_audit_logs_resource_type (resource_type, resource_id),
INDEX idx_audit_logs_status (status),
INDEX idx_audit_logs_action (action, created_at);
---
c.说明
审计日志内容示例：
d.表格数据
审计分类 操作类型 资源类型 审计要点
AI调用日志 ai_service 提交澄清、获取历史、模型选择 输入、输出、模型版本、调用时间
专家操作日志 tender、score、clarification 提交评分、更新评分、删除评分、查询结果 标书ID、评分数据、操作人
系统操作日志 config 更新配置、批量更新、重新加载配置 配置键、新值、环境、操作人
安全日志 login、logout 用户ID、登录/登出时间、IP地址
e.代码示例
---
**审计日志保留策略：**
- AI调用日志：**保存10年**（符合等保二级要求）
- 专家操作日志：**保存10年**（符合等保二级要求）
- 系统操作日志：**保存10年**（符合等保二级要求）
- 安全日志：**保存10年**（符合等保二级要求）
---
## 三、数据库性能优化
### 3.1 连接池配置
**目标：** 应对开标时刻10并发，提供稳定的数据库连接
**配置参数：**
---
b.SQLAlchemy连接池配置
from sqlalchemy import create_engine, pool
from sqlalchemy.orm import sessionmaker, scoped_session
ENGINE_URL = f"postgresql://{os.getenv('DB_USER')}:os.getenv('DB_PASSWORD')}@{os.getenv('DB_HOST')}:{os.getenv('DB_PORT')}/{os.getenv('DB_DATABASE')}"
c.连接池配置
engine = create_engine(
ENGINE_URL,
pool_size=int(os.getenv('DB_POOL_SIZE', '20')),
max_overflow=int(os.getenv('DB_MAX_OVERFLOW', '10')),
pool_pre_ping=True, # 连接前检查
pool_recycle=int(os.getenv('DB_POOL_RECYCLE', '3600')), # 连接回收时间（1小时）
echo=False, # 生产环境关闭SQL回显
)
d.会话工厂
SessionLocal = scoped_session(
sessionmaker(
autocommit=False, # 不自动提交，手动控制
autoflush=False, # 手动清理
)
)
e.使用示例
a.说明
with SessionLocal() as session:
# 高并发查询
results = session.query(Tender).filter(...).all()
# 批量操作
for tender_data in tender_list:
session.execute(insert(Tender).values(tender_data))
# 手动提交
session.commit()
b.代码示例
---
**性能优化策略：**
1. ✅ **预分配连接池**：启动时创建20个连接
2. ✅ **连接预热**：使用pool_pre_ping检查连接有效性
3. ✅ **连接复用**：短连接生命周期内复用连接，避免频繁建立/销毁
4. ✅ **连接回收**：3600秒后回收空闲连接，释放资源
### 3.2 查询优化
**索引策略：**
**常用查询索引：**
---
c.说明
-- 项目查询索引
CREATE INDEX idx_tenders_project_status_timestamp ON t_tenders(project_id, status, upload_timestamp DESC);
-- 标书查询索引
CREATE INDEX idx_tenders_supplier_status_timestamp ON t_tenders(supplier_id, status, upload_timestamp DESC);
-- 解析结果索引
CREATE INDEX idx_parse_results_tender_status ON t_parse_results(tender_id, parse_status, start_time DESC);
-- 澄清记录索引
CREATE INDEX idx_clarifications_project_timestamp ON t_clarifications(project_id, created_at DESC);
-- 评分记录索引
CREATE INDEX idx_scores_project_tender_rank ON t_scores(project_id, tender_id, total_score DESC);
-- 审计日志索引
CREATE INDEX idx_audit_logs_user_created ON t_audit_logs(user_id, created_at DESC);
-- 复合索引
CREATE UNIQUE INDEX idx_audit_logs_resource ON t_audit_logs(resource_type, resource_id, created_at);
d.代码示例
---
**批量操作优化：**
---
e.说明
from sqlalchemy import insert, update, select
from contextlib import contextmanager
@contextmanager
def batch_operation():
"""批量操作上下文管理器"""
with SessionLocal() as session:
yield session
try:
yield
session.commit()
except Exception as e:
session.rollback()
raise e
f.批量插入标书
async def batch_create_tenders(tenders_data: List[dict]):
"""批量创建标书记录"""
with batch_operation() as session:
stmt = insert(Tender)
for tender_data in tenders_data:
session.execute(stmt, tender_data)
return {"total": len(tenders_data)}
g.批量更新标书状态
a.说明
async def batch_update_tender_status(tender_ids: List[int], new_status: str):
"""批量更新标书状态"""
with batch_operation() as session:
stmt = update(Tender).where(Tender.id.in_(tender_ids)).values(
status=new_status,
updated_at=datetime.now()
)
session.execute(stmt)
return {"total": len(tender_ids)}
b.代码示例
---
### 3.3 事务管理
**事务隔离策略：**
---
c.说明
from sqlalchemy import select
from datetime import datetime
class TransactionManager:
"""事务管理器"""
@staticmethod
def create_project(project_data: dict):
"""创建项目事务"""
with SessionLocal() as session:
try:
project = Project(project_data)
session.add(project)
session.commit()
return project
except Exception as e:
session.rollback()
raise e
@staticmethod
def create_tenders(project_id: int, tenders_data: List[dict]):
"""批量创建标书事务"""
with SessionLocal() as session:
try:
tender_ids = []
for tender_data in tenders_data:
tender = Tender(tender_data)
session.add(tender)
tender_ids.append(tender.id)
session.commit()
return tender_ids
except Exception as e:
session.rollback()
raise e
@staticmethod
def create_clarifications(project_id: int, clarifications: List[dict]):
"""批量创建澄清记录事务"""
with SessionLocal() as session:
try:
clarification_ids = []
for clarif_data in clarifications:
clarification = Clarification(clarif_data)
session.add(clarification)
clarification_ids.append(clarification.id)
session.commit()
return clarification_ids
except Exception as e:
session.rollback()
raise e
@staticmethod
def create_scores(project_id: int, scores_data: List[dict]):
"""批量创建评分记录事务"""
with SessionLocal() as session:
score_ids = []
for score_data in scores_data:
score = Score(score_data)
score_ids.append(score.id)
session.commit()
return score_ids
except Exception as e:
session.rollback()
raise e
d.代码示例
---
### 3.4 数据一致性保障
**外键约束：**
---
e.说明
-- 标书供应商外键（确保数据完整性）
CONSTRAINT fk_tenders_project
FOREIGN KEY (project_id) REFERENCES t_projects(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 供应商外键（确保数据完整性）
CONSTRAINT fk_tenders_supplier
FOREIGN KEY (supplier_id) REFERENCES t_suppliers(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 解析结果外键（确保数据完整性）
CONSTRAINT fk_parse_results_tender
FOREIGN KEY (tender_id) REFERENCES t_tenders(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 澄清记录外键（确保数据完整性）
CONSTRAINT fk_clarifications_tender
FOREIGN KEY (project_id) REFERENCES t_projects(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 评分记录外键（确保数据完整性）
CONSTRAINT fk_scores_tender
FOREIGN KEY (tender_id) REFERENCES t_tenders(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 审计日志外键（确保用户追溯）
CONSTRAINT fk_audit_logs_user
FOREIGN KEY (user_id) REFERENCES t_users(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
-- 配置变更日志外键（确保配置追溯）
CONSTRAINT fk_config_history_project
FOREIGN KEY (config_id) REFERENCES t_project_configs(id)
ON DELETE SET NULL
ON UPDATE CASCADE;
f.代码示例
---
### 3.5 分区表策略
**数据分区：**
---
g.说明
-- 按项目ID分区（隔离不同项目的数据）
CREATE TABLE t_tenders_2024 PARTITION BY RANGE (project_id);
CREATE TABLE t_tenders_2025 PARTITION BY RANGE (project_id);
CREATE TABLE t_tenders_2026 PARTITION BY RANGE (project_id);
-- 按时间分区（归档历史数据）
CREATE TABLE t_clarifications_2024 PARTITION BY RANGE (project_id);
CREATE TABLE t_clarifications_2025 PARTITION BY RANGE (project_id);
CREATE TABLE t_scores_2024 PARTITION BY RANGE (project_id);
-- 分区索引
CREATE INDEX idx_tenders_2024_project_status ON t_tenders_2024(project_id, status);
CREATE INDEX idx_tenders_2025_project_status_timestamp ON t_tenders_2025(project_id, status, upload_timestamp DESC);
h.代码示例
---
**分区策略优势：**
- ✅ **查询加速**：按项目分区查询，数据量小90%
- ✅ **维护简单**：归档历史数据可按年独立管理
- ✅ **性能优化**：删除归档数据简单高效（DROP TABLE PARTITION）
- ✅ **扩展性强**：新增年度分区无影响其他分区
---
## 四、数据库安全策略
### 4.1 数据访问控制
**基于角色的访问控制：**
| 角色 | 读取权限 | 写入权限 | 删除权限 |
|------|---------|----------|----------|
| **超级管理员** | 所有数据 | 所有数据 | 所有数据 |
| **评标管理员** | 除审计日志外的所有业务数据 | 除审计日志外的所有业务数据 |
| **评标专家** | 当前项目数据 | 当前项目数据 | 读取/写入评分数据 | 读取/写入评分数据 |
| **普通用户** | 公开数据 | 无写入权限 | 无读取权限 | 无写入权限 |
**权限控制实现：**
---
i.说明
from enum import Enum
from fastapi import Depends, HTTPException, status
class UserRole(str, Enum):
SUPER_ADMIN = "super_admin"
EVALUATION_ADMIN = "evaluation_admin"
EVALUATION_EXPERT = "evaluation_expert"
EVALUATION_EXPERT_READONLY = "evaluation_expert_readonly"
USER = "user"
async def check_tender_access(
user_role: UserRole,
tender_project_id: int,
tender_supplier_id: int
) -> bool:
"""检查标书访问权限"""
# 超级管理员：所有权限
if user_role == UserRole.SUPER_ADMIN:
return True
# 评标管理员：当前项目的所有数据
if user_role == UserRole.EVALUATION_ADMIN:
# 检查项目是否属于当前管理范围
current_project = await get_project(tender_project_id)
if not current_project:
raise HTTPException(status_code=404, detail="无权限访问该项目")
return True
# 评标专家：只能读取当前项目的数据
if user_role == UserRole.EVALUATION_EXPERT:
# 检查专家是否属于该项目
current_project = await get_project(tender_project_id)
if not current_project:
raise HTTPException(status_code=404, detail="无权限访问该项目")
return True
# 普通用户：只能读取公开数据
if user_role == UserRole.USER:
# 检查项目状态
project = await get_project(tender_project_id)
if project.status not in ['closed', 'archived']:
raise HTTPException(status_code=403, detail="该项目未公开")
return True
# 其他情况：无权限
return False
h.FastAPI依赖注入
a.说明
@router.get("/api/projects/{project_id}/tenders/{tender_id}")
async def get_tender_detail(
tender_id: int,
tender_project_id: int,
current_user: User = Depends(get_current_user)
):
"""获取标书详情"""
# 检查权限
if not check_tender_access(current_user.role, tender_project_id, tender_supplier_id):
raise HTTPException(status_code=403, detail="无权限访问该标书")
# 获取标书详情
with get_db() as db:
tender = db.query(Tender).filter(Tender.id == tender_id).first()
return {
"id": tender.id,
"tender_name": tender.tender_name,
"supplier_name": tender.supplier.supplier_name,
"file_size": tender.file_size,
"page_count": tender.page_count,
"upload_status": tender.upload_status,
"parse_status": tender.parse_status,
"parse_result": tender.parse_result,
"evaluation_count": tender.evaluation_count,
"total_score": tender.total_score,
"rank": tender.rank
}
b.代码示例
---
### 4.2 数据加密策略
**加密实施：**
| 数据类型 | 加密方式 | 密钥管理 | 应用场景 |
|---------|---------|----------|
| **原始PDF文件** | AES-256-GCM | 文件内容敏感，强加密 | 存储在MinIO，HSM管理主密钥 |
| **解析结果JSON** | AES-256-GCM | 结构化数据，包含标书内容 | PostgreSQL字段加密存储 |
| **向量数据** | ChromaDB内置 | 开源数据库自带加密 | 向量索引数据，元数据加密 |
| **审计日志** | AES-256-GCM | 完整审计追踪 | PostgreSQL字段加密存储 |
| **环境变量** | AES-256-GCM | Kubernetes Secrets管理 | 密钥轮换机制 |
**加密密钥管理：**
---
c.说明
from cryptography.fernet import Fernet
from base64 import b64encode, b64decode
class EncryptionService:
"""加密服务"""
def __init__(self, master_key: str, data_key: str):
self.master_cipher = Fernet(master_key)
self.data_cipher = Fernet(data_key)
def encrypt_string(self, text: str) -> str:
"""加密字符串"""
encrypted = self.data_cipher.encrypt(text.encode())
# Base64编码返回bytes，再转回str
return b64encode(encrypted).decode()
def decrypt_string(self, encrypted: str) -> str:
"""解密字符串"""
return self.data_cipher.decrypt(b64decode(encrypted).encode())
def encrypt_json(self, data: dict) -> str:
"""加密字典"""
json_str = json.dumps(data, ensure_ascii=False)
return self.encrypt_string(json_str)
def decrypt_json(self, encrypted: str) -> dict:
"""解密字典"""
json_str = self.decrypt_string(encrypted)
return json.loads(json_str)
d.代码示例
---
### 4.3 敏感数据脱敏
**脱敏规则：**
| 数据类型 | 脱敏字段 | 脱敏策略 | 示例 |
|---------|---------|----------|----------|
| **供应商名称** | 虚化部分 | "XX公司" → "**"公司"** | 避免完全展示真实名称 |
| **身份证号** | 完全隐藏 | "110101********5678" → "110***********5678" | 保留最后4位 |
| **电话号码** | 虚化部分 | "138****1234" → "138****1234" | 保留区号+后4位 |
| **邮箱地址** | 部分隐藏 | "user@****" → "user***@****.com" | 保留@前+域名 |
| **联系地址** | 不脱敏 | "北京市朝阳区xxx路xxx号" → "北京市朝阳区xxx路xxx号" | 完整地址 |
| **标书原文** | 仅授权专家可访问 | 下载/在线预览（需认证） |
**审计日志脱敏：**
- IP地址：保留后3位（192.168.xxx.x）
- User-Agent：不记录
- 请求参数：记录关键参数，不记录敏感内容
- 响应数据：记录关键信息，不记录完整输出
---
## 五、数据备份与恢复
### 5.1 备份策略
**三层备份架构：**
---
e.说明
┌──────────────────────────────────────────────────────┐
│ 实时备份 │
│ PostgreSQL │ MinIO │
│ ┌────────────────┐ │
│ │ │ └──────────────────┘ │
└───────────────────────────────────────────────┘
│ 异地备份 │
f.代码示例
---
**备份策略：**
| 备份类型 | 频率 | 保留期 | 存储位置 | 验证方式 |
|---------|------|--------|----------|----------|
| **实时备份** | 每天增量 | 7天 | MinIO | 本地文件系统 + 异地对象存储 |
| **周全量备份** | 每周日一次 | 7天 | MinIO | + 异地对象存储 |
| **月度全量备份** | 每月1号 | 7天 | MinIO + 异地对象存储 + 冷数据压缩 |
| **季度验证备份** | 每季度一次 | 7天 | 异地备份 + 数据完整性验证 |
| **年度归档备份** | 每年1次 | 7天 | 异地备份 + 冷数据压缩 + 保留3年 |
**备份验证：**
- ✅ 定期备份验证：每次备份后验证文件完整性（校验和）
- ✅ 恢复演练：季度测试恢复一次
- ✅ 备份加密：备份数据使用AES-256-GCM加密
**异地备份：**
- ✅ **存储位置**：与本地物理隔离的异地机房
- ✅ **网络加密**：VPN或专用专线
- ✅ **数据传输**：加密传输，HTTPS
- ✅ **数据完整性**：备份前后的校验和
### 5.2 备份配置
**备份策略实施：**
---
g.说明
#!/bin/bash
i.每日增量备份脚本（0点执行，cron调度）
PROJECT_DIR="/data/evaluation"
BACKUP_DIR="/backup/evaluation"
TODAY=$(date +%Y%m%d)
j.PostgreSQL增量备份
PG_DUMP_FILE="$BACKUP_DIR/postgres_${TODAY}.dump"
pg_dump -h localhost -U ${DB_USER} -d ${DB_DATABASE} -Fc -f $PG_DUMP_FILE"
k.MinIO对象存储备份
MINIO_DIR="/backup/evaluation/objects"
MINIO_CONFIG="/root/.minio/config/config.env"
l.备份命令
mc admin alias mirror create /eval-backup \
--mirror create eval-backup \
--mirror set endpoint https://minio.example.com \
-- mirror set accesskey ${MINIO_ACCESS_KEY} \
-- mirror set secret ${MINIO_SECRET_KEY}
m.增量备份
a.说明
find $PROJECT_DIR -type f -name "*.sql" -mtime -1 -7 > \
b.表格数据
c.说明
filename=$(basename "$file")
tar -czf "$BACKUP_DIR/$TODAY/$filename.tar.gz" "$file" 2>/dev/null
done
n.全量备份（每周一）
o./usr/bin/psql -h localhost -U ${DB_USER} -d ${DB_DATABASE} -Fc -f /data/backup/evaluat_$TODAY.sql
p.7天全量备份脚本（每周日凌晨2点执行，保留3周数据）
q.归档备份（每年1月1号保留3年数据）
r.find $BACKUP_DIR -type d -name "*.sql" -mtime -365 > -364 > \
s.| while read file; do
t.filename=$(basename "$file")
u.tar -czf "$BACKUP_DIR/archive/$TODAY/$filename.tar.gz" "$file" 2>/dev/null
v.done
a.代码示例
---
### 5.3 恢复策略
**恢复优先级：**
| 恢复场景 | 优先级 | RTO（恢复时间目标）| 说明 |
|---------|------|---------|----------|
| **数据丢失** | P1（最高） | 数据丢失，影响业务运营 | 立即启动恢复 |
| **系统故障** | P2（高） | 主数据库崩溃，影响评标系统 | 切换到备用数据库 |
| **误操作** | P3（中） | 批量误删除，需要回滚 | 使用事务日志快速定位问题 |
| **灾难恢复** | P4（最低） | 服务器机房故障，数据完全丢失 | 启动灾备，数据中心恢复 |
**恢复验证：**
- ✅ 数据完整性校验（校验和）
- ✅ 功能验证（主要功能可用）
- ✅ 数据一致性校验（标书数量、评分数据）
- ✅ 性能验证（系统响应时间<5秒）
---
## 六、数据库性能基准测试
### 6.1 测试场景与指标
| 测试场景 | 并发量 | 数据量 | 测试方法 | 目标值 |
|---------|---------|----------|--------|--------|
| **开标时刻并发** | 10个标书同时处理 | 500MB数据 | 压测（并发数据库） | P50 < 100ms |
| **澄清高峰** | 10个专家并发提问 | 向量检索（历史5000个标书） | P95 < 1秒 |
| **评分提交** | 10个专家同时打分 | 批量写入（20个评分记录） | P95 < 200ms |
| **历史检索** | 跨量查询（历史数据） | P95 < 1秒 |
| **备份压力测试** | 全量备份+增量备份 | MinIO + PostgreSQL | 磀测IOPS性能 |
### 6.2 性能基准
| 操作类型 | 目标值 | 测试方法 | 优化策略 |
|---------|---------|----------|--------|
| **单表查询** | P50 < 50ms | 创建适当索引，避免全表扫描 | 复合索引，避免低效查询 |
| **复杂查询** | P95 < 500ms | 查询优化，避免N+1问题 |
| **批量写入** | P95 < 200ms | 批量操作优化，连接池预热 |
| **批量更新** | P95 < 500ms | 事务优化，合理设置事务大小 |
| **JSONB读写** | P95 < 100ms | 优化JSONB序列化，避免多次序列化 |
---
## 七、数据库运维管理
### 7.1 数据库监控
#### 7.1.1 监控指标配置
**Prometheus指标定义：**
---
b.说明
from prometheus_client import Counter, Gauge, Histogram
w.连接池指标
postgres_connections_active = Gauge('postgres_connections_active')
postgres_idle = Gauge('postgres_connections_idle')
postgres_query_duration_seconds = Histogram('postgres_query_duration_seconds')
postgres_slow_queries_total = Counter('postgres_slow_queries_total')
x.NPU指标
npu_memory_usage_percent = Gauge('npu_memory_usage_percent')
npu_utilization_percent = Gauge('npu_utilization_percent')
qwen72b_inference_requests = Counter('qwen72b_inference_requests')
qwen32b_inference_requests = Counter('qwen32b_inference_requests')
y.Redis指标
redis_memory_usage_bytes = Gauge('redis_memory_usage_bytes')
redis_cache_hit_rate = Gauge('redis_cache_hit_rate')
redis_connections_active = Gauge('redis_connections_active')
z.应用指标
a.说明
http_requests_total = Counter('http_requests_total')
http_request_duration_seconds = Histogram('http_request_duration_seconds')
celery_tasks_total = Counter('celery_tasks_total')
celery_tasks_pending = Gauge('celery_tasks_pending')
celery_tasks_failed_total = Counter('celery_tasks_failed_total')
b.代码示例
---
#### 7.1.2 告警规则配置**
---
c.说明
DEFAULT_ALERT_RULES = [
AlertRule(
rule_id="http_500_error_rate",
rule_name="HTTP 500错误率过高",
metric_name="http_requests_total",
operator=">",
threshold=10,
severity="critical",
duration=300 # 5分钟
),
AlertRule(
rule_id="celery_task_failure_rate",
rule_name="Celery任务失败率过高",
metric_name="celery_tasks_failed_total",
operator=">",
threshold=5,
severity="critical",
duration=300
),
AlertRule(
rule_id="npu_memory_high",
rule_name="NPU内存使用率过高",
metric_name="npu_memory_usage_percent",
operator=">",
threshold=90,
severity="warning",
duration=60
),
AlertRule(
rule_id="redis_cache_hit_low",
rule_name="Redis缓存命中率过低",
metric_name="redis_cache_hit_rate",
operator="<",
threshold=0.5,
severity="warning",
duration=300
),
AlertRule(
rule_id="db_connection_pool_exhaustion",
rule_name="数据库连接池耗尽",
metric_name="postgres_connections_active",
operator=">",
threshold=18,
severity="warning",
duration=120
)
]
d.代码示例
---
#### 7.1.3 告警通知
---
e.说明
import smtplib
from email.utils import send_mail
aa.SMTP配置
a.说明
SMTP_SERVER = os.getenv('SMTP_SERVER', 'smtp.example.com')
SMTP_PORT = int(os.getenv('SMTP_PORT', '587'))
SMTP_USER = os.getenv('SMTP_USER', '[email protected]')
SMTP_PASSWORD = os.getenv('SMTP_PASSWORD', '')
def send_alert(
rule_name: str,
metric_value: float,
threshold: float,
actual_value: float
severity: str
):
"""发送告警邮件"""
subject = f"[{severity}]告警：{rule_name}"
# 告警内容
if severity == 'critical':
alert_type = "🚨 严重错误"
elif severity == 'warning':
alert_type = "⚠️ 警告信息"
alert_type = "ℹ️ 修复建议"
else:
alert_type = "ℹ️ 告息信息"
body = f"""
告警详情：
告警规则：{rule_name}
指标值：{metric_value:.2f}（{threshold:.2f}%）
实际值：{actual_value:.2f}（{threshold:.2f}%）
偏差：{(actual_value - threshold):.2f}%
建议措施：
"""
"""
recipients = os.getenv('ALERT_RECIPIENTS', '[email protected]').split(',')
try:
send_mail(
from_addr=SMTP_SERVER,
port=SMTP_PORT,
username=SMTP_USER,
password=SMTP_PASSWORD,
subject=subject,
body=body,
recipients=recipients
)
except Exception as e:
logger.error(f"告警邮件发送失败：{str(e)}")
b.代码示例
---
#### 7.1.4 Grafana仪表板配置
**Dashboard配置：**
---
c.说明
{
"dashboard": {
"title": "企业采购评标系统监控",
"refresh": "30s",
"panels": [
{
"title": "系统概览",
"targets": [
{
"expr": "up{instance_count}",
"legend": "实例数量",
"color": "green"
},
{
"expr": "up{instance_count}:5",
"legend": "运行实例"
}
]
},
{
"title": "数据库性能",
"targets": [
{
"expr": "rate(postgres_query_duration_seconds)",
"legend": "查询P50",
"color": "green"
},
{
"expr": "rate(http_request_duration_seconds)",
"legend": "响应P50",
"color": "green"
},
{
"expr": "rate(slow_queries_total / rate(http_requests_total) * 100)",
"legend": "慢查询率",
"color": "yellow"
}
]
},
{
"title": "AI服务",
"targets": [
{
"expr": "rate(qwen72b_inference_requests)",
"legend": "推理QPS",
"color": "green"
},
{
"expr": "rate(qwen32b_inference_requests)",
"legend": "推理QPS",
"color": "blue"
}
]
},
{
"title": "缓存性能",
"targets": [
{
"expr": "rate(redis_cache_hit_rate)",
"legend": "缓存命中率",
"color": "green"
},
{
"expr": "rate(http_requests_total / rate(redis_cache_hit_rate) * 100)",
"legend": "缓存命中率",
"color": "yellow"
}
]
},
{
"title": "NPU资源",
"targets": [
{
"expr": "npu_memory_usage_percent",
"legend": "NPU内存使用率",
"color": "green"
},
{
"expr": "npu_utilization_percent",
"legend": "NPU利用率",
"color": "green"
}
]
}
]
}
}
d.代码示例
---
---
## 八、数据库版本控制
### 8.1 Alembic迁移管理
**迁移策略：**
| 场景 | 迁移方式 | 版本控制工具 | 回滚策略 |
|---------|---------|----------|----------|
| **新环境部署** | Alembic自动迁移 | Alembic命令 | 备份当前版本 | 数据库备份 |
| **生产环境部署** | SQL脚本迁移 | 数据备份+对比验证 | 手动执行SQL脚本 |
| **版本回滚** | Alembic down迁移 | 备份恢复，数据验证 |
**Alembic版本迁移：**
---
e.{"critical": "立即处理", "warning": "5分钟内处理", "info": "30分钟内检查"}
ab.Alembic迁移命令示例
alembic upgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}?sslmode=disable"
alembic upgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}?sslmode=prefer"
alembic upgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}?sslmode=require"
alembic upgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}?sslmode=allow"
ac.版本回滚
alembic downgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}"
alembic downgrade head "postgresql://${DB_HOST}:${DB_PORT}/${DB_DATABASE}"
ad.数据备份
mysqldump -h localhost -U ${DB_USER} ${DB_PASSWORD} ${DB_DATABASE} > /data/backup/mysqldump_${TODAY}.sql
04.AI服务架构设计
a.AI服务架构概览
a.架构定位
a.说明
AI服务在系统中的位置：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 应用层 │
│ ┌──────────────────────────────────────────────┐ │
│ │ FastAPI应用服务 │ │
│ │ • 标书解析API │ │
│ │ • AI澄清API │ │
│ │ • 评分管理API │ │
│ └──────────────┬───────────────────────────────┘ │
└─────────────────┼───────────────────────────────────┘
│ HTTP RESTful
┌─────────────────▼───────────────────────────────────┐
│ AI服务层 │
│ ┌──────────────────────────────────────────────┐ │
│ │ NewAPI模型网关 │ │
│ │ • 统一模型管理 │ │
│ │ • 智能路由策略 │ │
│ │ • 负载均衡与故障转移 │ │
│ │ • 使用监控与计费 │ │
│ └──────────────┬───────────────────────────────┘ │
└─────────────────┼───────────────────────────────────┘
│ HTTP OpenAI-Compatible API
┌─────────────────▼───────────────────────────────────┐
│ 昇腾NPU推理集群 │
│ ┌──────────────────────────────────────────────┐ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Qwen2.5-72B │ │Qwen2.5-VL │ │ │
│ │ │ (2x TP) │ │ -32B │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Qwen2-VL-7B │ │ PaddleOCR │ │ │
│ │ │ (快速响应) │ │ (PP-OCRv4) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ 昇腾910B NPU集群 (4卡) │
└──────────────────────────────────────────────────────┘
---
b.核心设计原则
a.表格数据
原则 说明 应用场景
模型即服务 通过NewAPI统一管理所有AI模型，应用层无需关心底层实现 所有AI调用场景
智能路由 根据任务类型自动选择最优模型，平衡性能与成本 澄清提问、文档解析、快速预览
故障隔离 单个模型故障不影响其他模型，自动故障转移 模型宕机、推理超时
可观测性 完整记录AI调用日志，支持问题追溯和性能分析 审计追踪、性能优化
成本优化 缓存策略、批处理、模型选择优化，降低NPU资源消耗 开标时刻并发、历史数据检索
合规优先 AI输出格式严格限制，仅提供参考依据，不做判断 所有AI澄清场景
c.AI服务分层架构
a.代码示例
---
graph TB
subgraph "应用层"
A1[标书解析服务]
A2[AI澄清服务]
A3[快速预览服务]
end
subgraph "AI服务抽象层"
B1[AI服务接口]
B2[模型路由器]
B3[输出验证器]
B4[缓存管理器]
end
subgraph "NewAPI网关层"
C1[模型管理]
C2[路由分发]
C3[负载均衡]
C4[监控统计]
end
subgraph "推理层"
D1[Qwen2.5-72B]
D2[Qwen2.5-VL-32B]
D3[Qwen2-VL-7B]
D4[PaddleOCR]
end
A1 --> B1
A2 --> B1
A3 --> B1
B1 --> B2
B2 --> C2
B3 --> C2
B4 --> C2
C2 --> D1
C2 --> D2
C2 --> D3
C2 --> D4
---
b.说明
---
b.NewAPI集成方案
a.NewAPI架构配置
a.NewAPI部署架构
a.说明
NewAPI作为模型网关的核心价值：
b.表格数据
价值点 说明 收益
统一接口 OpenAI兼容API，无需修改现有代码 降低集成复杂度
智能路由 根据任务类型自动选择模型 性能与成本最优
负载均衡 多实例负载均衡，故障自动转移 高可用性
使用监控 QPS监控、Token统计、成本分析 可观测性
b.NewAPI配置模型
a.说明
NewAPI渠道配置：
b.代码示例
---
{
"channels": [
{
"id": 1,
"name": "qwen72b-primary",
"type": "openai",
"endpoint": "http://qwen72b-service:8001/v1",
"models": ["Qwen/Qwen2.5-72B-Instruct"],
"priority": 1,
"weight": 100,
"status": "enabled"
},
{
"id": 2,
"name": "qwen32b-primary",
"type": "openai",
"endpoint": "http://qwen32b-service:8002/v1",
"models": ["Qwen/Qwen2.5-VL-32B-Instruct"],
"priority": 1,
"weight": 100,
"status": "enabled"
},
{
"id": 3,
"name": "qwen7b-standby",
"type": "openai",
"endpoint": "http://qwen7b-service:8003/v1",
"models": ["Qwen/Qwen2-VL-7B-Instruct"],
"priority": 2,
"weight": 50,
"status": "enabled"
},
{
"id": 4,
"name": "paddle-ocr",
"type": "custom",
"endpoint": "http://paddle-ocr-service:8004",
"models": ["paddle-ocr-v4"],
"priority": 1,
"weight": 100,
"status": "enabled"
}
]
}
---
c.NewAPI路由策略
a.说明
智能路由规则配置：
b.代码示例
---
from enum import Enum
from typing import Literal
class TaskType(str, Enum):
"""AI任务类型"""
CLARIFICATION = "clarification" # 澄清提问（需要深度推理）
DOCUMENT_PARSE = "document_parse" # 文档解析（需要多模态）
QUICK_PREVIEW = "quick_preview" # 快速预览（需要快速响应）
TABLE_EXTRACTION = "table_extraction" # 表格提取（需要OCR）
BATCH_ANALYSIS = "batch_analysis" # 批量分析（需要高吞吐）
class ModelRouter:
"""模型路由器"""
# 任务类型与模型映射
TASK_MODEL_MAPPING = {
TaskType.CLARIFICATION: {
"primary": "qwen72b-primary", # 优先使用72B模型
"fallback": ["qwen32b-primary"], # 降级到32B
"reason": "澄清提问需要深度推理能力，72B模型准确性更高"
},
TaskType.DOCUMENT_PARSE: {
"primary": "qwen32b-primary", # 多模态文档理解
"fallback": ["qwen72b-primary"], # 降级到72B（文本理解）
"reason": "文档解析需要多模态能力，32B-VL模型专门优化"
},
TaskType.QUICK_PREVIEW: {
"primary": "qwen7b-standby", # 快速响应
"fallback": ["qwen32b-primary"], # 降级到32B
"reason": "快速预览优先响应速度，7B模型推理速度快"
},
TaskType.TABLE_EXTRACTION: {
"primary": "paddle-ocr", # 专门OCR
"fallback": ["qwen32b-primary"], # 降级到多模态
"reason": "表格提取使用专门OCR模型，准确率更高"
},
TaskType.BATCH_ANALYSIS: {
"primary": "qwen32b-primary", # 平衡性能与成本
"fallback": ["qwen72b-primary", "qwen7b-standby"],
"reason": "批量分析优先吞吐量，32B模型性价比最优"
}
}
@classmethod
def select_model(
cls,
task_type: TaskType,
context: dict = None
) -> str:
"""选择最优模型"""
config = cls.TASK_MODEL_MAPPING.get(task_type)
if not config:
raise ValueError(f"不支持的任务类型: {task_type}")
# 检查主模型是否可用
primary_model = config["primary"]
if cls._is_model_available(primary_model):
return primary_model
# 主模型不可用，尝试备用模型
for fallback_model in config["fallback"]:
if cls._is_model_available(fallback_model):
return fallback_model
# 所有模型都不可用
raise Exception(f"任务类型 {task_type} 没有可用的模型")
@classmethod
def _is_model_available(cls, model_name: str) -> bool:
"""检查模型是否可用"""
# 查询NewAPI模型状态
# TODO: 实现健康检查逻辑
return True
---
b.NewAPI集成实现
a.AI服务抽象层
a.说明
统一AI服务接口：
b.代码示例
---
from abc import ABC, abstractmethod
from typing import List, Dict, Optional, AsyncGenerator
from pydantic import BaseModel, Field
import httpx
import json
class AIRequest(BaseModel):
"""AI请求基类"""
prompt: str = Field(..., description="提示词")
max_tokens: int = Field(default=2048, description="最大Token数")
temperature: float = Field(default=0.7, ge=0, le=2, description="Temperature参数")
top_k: int = Field(default=5, ge=1, description="Top-K采样数")
top_p: float = Field(default=0.9, ge=0, le=1, description="Top-P采样数")
class AIResponse(BaseModel):
"""AI响应基类"""
content: str = Field(..., description="AI生成内容")
model: str = Field(..., description="使用的模型")
usage: Dict = Field(..., description="Token使用情况")
processing_time_ms: int = Field(..., description="处理耗时（毫秒）")
class AIService(ABC):
"""AI服务抽象基类"""
@abstractmethod
async def chat_completion(
self,
request: AIRequest,
task_type: TaskType
) -> AIResponse:
"""聊天补全接口"""
pass
@abstractmethod
async def chat_completion_stream(
self,
request: AIRequest,
task_type: TaskType
) -> AsyncGenerator[str, None]:
"""流式聊天补全接口"""
pass
class NewAPIService(AIService):
"""NewAPI服务实现"""
def __init__(
self,
gateway_url: str,
api_key: str,
timeout: int = 120
):
self.gateway_url = gateway_url.rstrip('/')
self.api_key = api_key
self.timeout = timeout
self.client = httpx.AsyncClient(
timeout=httpx.Timeout(timeout),
limits=httpx.Limits(max_keepalive_connections=50, max_connections=100)
)
async def chat_completion(
self,
request: AIRequest,
task_type: TaskType
) -> AIResponse:
"""聊天补全"""
# 模型路由选择
model_name = ModelRouter.select_model(task_type)
# 构建请求
payload = {
"model": model_name,
"messages": [
{
"role": "user",
"content": request.prompt
}
],
"max_tokens": request.max_tokens,
"temperature": request.temperature,
"top_k": request.top_k,
"top_p": request.top_p,
"stream": False
}
# 发送请求
start_time = time.time()
response = await self.client.post(
f"{self.gateway_url}/chat/completions",
headers={
"Authorization": f"Bearer {self.api_key}",
"Content-Type": "application/json"
},
json=payload
)
processing_time_ms = int((time.time() - start_time) * 1000)
# 解析响应
if response.status_code != 200:
raise Exception(f"NewAPI请求失败: {response.status_code} - {response.text}")
data = response.json()
return AIResponse(
content=data["choices"][0]["message"]["content"],
model=model_name,
usage=data.get("usage", {}),
processing_time_ms=processing_time_ms
)
async def chat_completion_stream(
self,
request: AIRequest,
task_type: TaskType
) -> AsyncGenerator[str, None]:
"""流式聊天补全"""
# 模型路由选择
model_name = ModelRouter.select_model(task_type)
# 构建请求
payload = {
"model": model_name,
"messages": [
{
"role": "user",
"content": request.prompt
}
],
"max_tokens": request.max_tokens,
"temperature": request.temperature,
"top_k": request.top_k,
"top_p": request.top_p,
"stream": True
}
# 发送请求
async with self.client.stream(
"POST",
f"{self.gateway_url}/chat/completions",
headers={
"Authorization": f"Bearer {self.api_key}",
"Content-Type": "application/json"
},
json=payload
) as response:
if response.status_code != 200:
raise Exception(f"NewAPI流式请求失败: {response.status_code}")
async for line in response.aiter_lines():
if line.startswith("data: "):
data_str = line[6:] # 去掉 "data: " 前缀
if data_str == "[DONE]":
break
try:
data = json.loads(data_str)
delta = data.get("choices", [{}])[0].get("delta", {})
content = delta.get("content", "")
if content:
yield content
except json.JSONDecodeError:
continue
---
b.服务实例配置
a.说明
服务配置：
b.代码示例
---
from typing import Optional
import os
class AIServiceConfig(BaseModel):
"""AI服务配置"""
# NewAPI配置
newapi_gateway_url: str = Field(
default="http://newapi-gateway:3000/v1",
description="NewAPI网关地址"
)
newapi_api_key: str = Field(
...,
description="NewAPI API密钥"
)
# 超时配置
timeout_seconds: int = Field(
default=120,
ge=30,
le=300,
description="请求超时时间（秒）"
)
# 重试配置
max_retries: int = Field(
default=3,
ge=0,
le=5,
description="最大重试次数"
)
retry_delay_ms: int = Field(
default=1000,
ge=100,
le=5000,
description="重试延迟（毫秒）"
)
# 并发配置
max_concurrent_requests: int = Field(
default=20,
ge=5,
le=100,
description="最大并发请求数"
)
# 缓存配置
cache_enabled: bool = Field(default=True, description="是否启用缓存")
cache_ttl_clarification: int = Field(default=3600, description="澄清缓存TTL（秒）")
cache_ttl_search: int = Field(default=600, description="搜索缓存TTL（秒）")
# 监控配置
monitoring_enabled: bool = Field(default=True, description="是否启用监控")
prometheus_push_url: Optional[str] = Field(None, description="Prometheus推送地址")
# 服务实例
ai_service_config = AIServiceConfig(
newapi_gateway_url=os.getenv("NEWAPI_GATEWAY", "http://newapi-gateway:3000/v1"),
newapi_api_key=os.getenv("NEWAPI_API_KEY", ""),
timeout_seconds=int(os.getenv("AI_TIMEOUT_SECONDS", "120")),
max_retries=int(os.getenv("AI_MAX_RETRIES", "3")),
retry_delay_ms=int(os.getenv("AI_RETRY_DELAY_MS", "1000")),
max_concurrent_requests=int(os.getenv("AI_MAX_CONCURRENT", "20")),
cache_enabled=os.getenv("AI_CACHE_ENABLED", "true").lower() == "true",
cache_ttl_clarification=int(os.getenv("AI_CACHE_TTL_CLARIFICATION", "3600")),
cache_ttl_search=int(os.getenv("AI_CACHE_TTL_SEARCH", "600")),
monitoring_enabled=os.getenv("AI_MONITORING_ENABLED", "true").lower() == "true"
)
# 创建服务实例
ai_service = NewAPIService(
gateway_url=ai_service_config.newapi_gateway_url,
api_key=ai_service_config.newapi_api_key,
timeout=ai_service_config.timeout_seconds
)
---
c.说明
---
c.Qwen模型调用策略
a.模型能力矩阵
a.模型特性对比
a.表格数据
模型 参数量 上下文长度 核心能力 适用场景 昇腾部署
Qwen2.5-72B-Instruct 72B 128K 文本理解、逻辑推理、指令遵循 澄清提问、复杂分析 2x TP (2卡并行)
Qwen2.5-VL-32B-Instruct 32B 128K 多模态文档理解、表格识别 文档解析、图表分析 1x TP (单卡)
Qwen2-VL-7B-Instruct 7B 128K 快速响应、图像理解 快速预览、实时反馈 1x (单卡)
PaddleOCR PP-OCRv4 - - OCR识别、表格结构化 文字识别、表格提取 1x (单卡)
b.模型选择决策树
a.代码示例
---
开始
│
├─ 任务类型？
│ ├─ 澄清提问（需要深度推理）
│ │ └─> Qwen2.5-72B-Instruct
│ │
│ ├─ 文档解析（多模态）
│ │ ├─ 包含表格？
│ │ │ ├─ 是 -> PaddleOCR + Qwen2.5-VL-32B
│ │ │ └─ 否 -> Qwen2.5-VL-32B
│ │
│ ├─ 快速预览（响应速度优先）
│ │ └─> Qwen2-VL-7B
│ │
│ ├─ 批量分析（吞吐量优先）
│ │ └─> Qwen2.5-VL-32B
│ │
│ └─ 纯文本理解
│ └─> Qwen2.5-72B-Instruct
---
b.澄清提问服务设计
a.澄清服务架构
a.说明
澄清服务流程：
b.代码示例
---
sequenceDiagram
participant E as 专家
participant API as FastAPI
participant VDB as ChromaDB
participant AI as AI服务
participant Cache as Redis缓存
participant DB as PostgreSQL
E->>API: 提交澄清提问
API->>Cache: 检查缓存
alt 缓存命中
Cache-->>API: 返回缓存结果
API-->>E: 返回澄清结果
else 缓存未命中
API->>VDB: 向量检索（Top-20）
VDB-->>API: 返回相关段落
API->>AI: 构建澄清Prompt
AI->>AI: 调用Qwen2.5-72B
AI-->>API: 返回澄清结果
API->>API: Pydantic验证输出
API->>Cache: 缓存结果（1小时TTL）
API->>DB: 保存澄清记录
API-->>E: 返回澄清结果
end
---
b.澄清Prompt模板
a.说明
核心Prompt设计（严格限制输出格式）：
b.代码示例
---
CLARIFICATION_PROMPT_TEMPLATE = """
你是一个专业的评标澄清助手。
## 任务说明
分析标书内容，**仅指出不符合招标文件要求的指标的地方**，**不做判断或纠正**。
## 输入数据
### 招标文件要求
{requirements}
### 标书相关段落
{relevant_paragraphs}
## 输出格式（严格遵守）
请按照以下JSON格式输出：
---
c.说明
{{
"non_compliant_items": [
{{
"page": 45,
"section": "3.2.1",
"section_title": "技术规格",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W，效率95%",
"original_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"document_id": "tender_A.pdf"
}}
]
}}
d.代码示例
---
## 重要提示（严格遵守）
1. **仅指出不符合的地方**，**不判断是否符合**
2. **仅返回原文对比**，**不提供修改建议**
3. **确保所有信息都能在原文中找到**
4. **不做任何技术方案建议**
5. **不做任何符合性评分**
6. **不做任何结论性判断**
## 输出说明
- `page`: 页码（整数）
- `section`: 章节号（字符串，如"3.2.1"）
- `section_title`: 章节标题
- `tender_requirement`: 招标文件中的要求
- `bid_content`: 标书中的对应内容（原文摘录）
- `original_text`: 原文完整摘录（保留上下文）
- `document_id`: 文档ID
如果所有指标都符合要求，返回空的non_compliant_items数组：`{{"non_compliant_items": []}}`
"""
class ClarificationRequest(BaseModel):
"""澄清请求"""
project_id: int = Field(..., description="项目ID")
question: str = Field(..., description="专家提问")
tender_ids: List[int] = Field(..., description="要澄清的标书ID列表")
expert_id: int = Field(..., description="专家ID")
class ClarificationResponse(BaseModel):
"""澄清响应"""
non_compliant_items: List[dict] = Field(
default=[],
description="不符合项列表"
)
model_used: str = Field(..., description="使用的模型")
processing_time_ms: int = Field(..., description="处理耗时（毫秒）")
cache_hit: bool = Field(..., description="是否命中缓存")
---
c.澄清服务实现
a.说明
澄清服务核心代码：
b.代码示例
---
from typing import List, Dict
import time
import hashlib
import json
class ClarificationService:
"""澄清服务"""
def __init__(
self,
ai_service: AIService,
vector_db: VectorDBService,
cache_service: CacheService,
db_session
):
self.ai_service = ai_service
self.vector_db = vector_db
self.cache = cache_service
self.db = db_session
async def clarify(
self,
request: ClarificationRequest
) -> ClarificationResponse:
"""执行澄清分析"""
start_time = time.time()
# 1. 生成缓存键
cache_key = self._generate_cache_key(
request.project_id,
request.question,
request.tender_ids
)
# 2. 检查缓存
cached_result = await self.cache.get(cache_key)
if cached_result:
return ClarificationResponse(
non_compliant_items=json.loads(cached_result),
model_used="cached",
processing_time_ms=int((time.time() - start_time) * 1000),
cache_hit=True
)
# 3. 向量检索相关段落
relevant_paragraphs = await self._retrieve_relevant_paragraphs(
project_id=request.project_id,
question=request.question,
tender_ids=request.tender_ids,
top_k=20
)
# 4. 构建Prompt
prompt = self._build_clarification_prompt(
requirements=await self._get_requirements(request.project_id),
relevant_paragraphs=relevant_paragraphs
)
# 5. 调用AI模型
ai_request = AIRequest(
prompt=prompt,
max_tokens=4096,
temperature=0.3, # 低温度保证输出稳定性
top_k=5,
top_p=0.9
)
ai_response = await self.ai_service.chat_completion(
request=ai_request,
task_type=TaskType.CLARIFICATION
)
# 6. 解析并验证输出
try:
result_data = json.loads(ai_response.content)
non_compliant_items = result_data.get("non_compliant_items", [])
# Pydantic验证
for item in non_compliant_items:
NonCompliantItem(**item)
except (json.JSONDecodeError, ValidationError) as e:
# 输出格式错误，返回空结果
logger.error(f"AI输出格式错误: {e}")
non_compliant_items = []
# 7. 缓存结果
await self.cache.set(
cache_key,
json.dumps(non_compliant_items),
ex=ai_service_config.cache_ttl_clarification
)
# 8. 保存澄清记录
await self._save_clarification_record(
request=request,
response=ai_response,
non_compliant_items=non_compliant_items
)
processing_time_ms = int((time.time() - start_time) * 1000)
return ClarificationResponse(
non_compliant_items=non_compliant_items,
model_used=ai_response.model,
processing_time_ms=processing_time_ms,
cache_hit=False
)
def _generate_cache_key(
self,
project_id: int,
question: str,
tender_ids: List[int]
) -> str:
"""生成缓存键"""
key_data = f"{project_id}:{question}:{','.join(map(str, sorted(tender_ids)))}"
return f"clarification:{hashlib.md5(key_data.encode()).hexdigest()}"
async def _retrieve_relevant_paragraphs(
self,
project_id: int,
question: str,
tender_ids: List[int],
top_k: int = 20
) -> List[Dict]:
"""检索相关段落"""
# 调用ChromaDB向量检索
results = await self.vector_db.search(
collection_name=f"project_{project_id}",
query_text=question,
where={"tender_id": {"$in": tender_ids}},
n_results=top_k
)
return results
def _build_clarification_prompt(
self,
requirements: str,
relevant_paragraphs: List[Dict]
) -> str:
"""构建澄清Prompt"""
# 格式化相关段落
formatted_paragraphs = "\n\n".join([
f"【标书{p['tender_id']} - 第{p['page']}页】\n{p['text']}"
for p in relevant_paragraphs
])
# 填充模板
return CLARIFICATION_PROMPT_TEMPLATE.format(
requirements=requirements,
relevant_paragraphs=formatted_paragraphs
)
async def _save_clarification_record(
self,
request: ClarificationRequest,
response: AIResponse,
non_compliant_items: List[Dict]
):
"""保存澄清记录到数据库"""
record = t_clarifications(
project_id=request.project_id,
expert_id=request.expert_id,
question=request.question,
ai_response={
"content": response.content,
"model": response.model,
"usage": response.usage
},
expert_action="pending", # 待专家复核
evaluation_reference_ids=request.tender_ids,
model_version=response.model,
model_name=response.model,
processing_time_ms=response.processing_time_ms
)
self.db.add(record)
await self.db.commit()
---
c.文档解析服务设计
a.文档解析流程
a.说明
多阶段解析流程：
b.代码示例
---
原始PDF文件
│
├─ 阶段1：文档分页
│ └─> 按页分割PDF（每页独立处理）
│
├─ 阶段2：OCR识别
│ ├─> PaddleOCR文字识别
│ └─> 输出：每页文字内容 + 置信度
│
├─ 阶段3：表格识别
│ ├─> PaddleStructure表格结构化
│ └─> 输出：表格数据（JSON格式）
│
├─ 阶段4：多模态理解
│ ├─> Qwen2.5-VL-32B文档理解
│ └─> 输出：章节结构、段落摘要
│
├─ 阶段5：结果聚合
│ ├─> 合并所有解析结果
│ └─> 输出：完整解析结果（JSON）
│
└─ 阶段6：向量索引
├─> 生成向量嵌入
└─> 存储到ChromaDB
---
b.文档解析服务实现
a.说明
文档解析核心代码：
b.代码示例
---
from typing import List, Dict, AsyncGenerator
import asyncio
class DocumentParseService:
"""文档解析服务"""
def __init__(
self,
ai_service: AIService,
ocr_service: OCRService,
vector_db: VectorDBService,
db_session
):
self.ai_service = ai_service
self.ocr_service = ocr_service
self.vector_db = vector_db
self.db = db_session
async def parse_document(
self,
tender_id: int,
file_path: str,
project_id: int
) -> AsyncGenerator[Dict, None]:
"""解析文档（流式返回进度）"""
# 阶段1：文档分页
yield {"stage": "split_pages", "progress": 0, "message": "正在分页"}
pages = await self._split_pdf(file_path)
total_stages = 5
current_stage = 1
# 阶段2：OCR识别
yield {"stage": "ocr", "progress": current_stage/total_stages*100, "message": "OCR识别中"}
ocr_results = await self._ocr_pages(pages)
current_stage += 1
# 阶段3：表格识别
yield {"stage": "table", "progress": current_stage/total_stages*100, "message": "表格识别中"}
table_results = await self._extract_tables(pages)
current_stage += 1
# 阶段4：多模态理解
yield {"stage": "multimodal", "progress": current_stage/total_stages*100, "message": "文档理解中"}
multimodal_results = await self._multimodal_understand(pages)
current_stage += 1
# 阶段5：结果聚合
yield {"stage": "aggregate", "progress": current_stage/total_stages*100, "message": "聚合结果中"}
parse_result = self._aggregate_results(
ocr_results=ocr_results,
table_results=table_results,
multimodal_results=multimodal_results
)
current_stage += 1
# 阶段6：向量索引
yield {"stage": "indexing", "progress": current_stage/total_stages*100, "message": "建立向量索引"}
await self._create_vector_index(
project_id=project_id,
tender_id=tender_id,
parse_result=parse_result
)
# 保存解析结果到数据库
await self._save_parse_result(
tender_id=tender_id,
parse_result=parse_result
)
yield {"stage": "completed", "progress": 100, "message": "解析完成"}
async def _split_pdf(self, file_path: str) -> List[Dict]:
"""分割PDF为页面"""
# 使用PyMuPDF分割PDF
import fitz
doc = fitz.open(file_path)
pages = []
for page_num in range(len(doc)):
page = doc[page_num]
pages.append({
"page_number": page_num + 1,
"image": page.get_pixmap().png_bytes(),
"text": page.get_text()
})
doc.close()
return pages
async def _ocr_pages(self, pages: List[Dict]) -> List[Dict]:
"""OCR识别页面"""
# 批量OCR识别（并发处理）
tasks = [
self.ocr_service.recognize(page["image"])
for page in pages
]
results = await asyncio.gather(*tasks)
return [
{
"page_number": page["page_number"],
"text": result["text"],
"confidence": result["confidence"]
}
for page, result in zip(pages, results)
]
async def _extract_tables(self, pages: List[Dict]) -> List[Dict]:
"""提取表格"""
# 使用PaddleStructure提取表格
tables = []
for page in pages:
page_tables = await self.ocr_service.extract_tables(page["image"])
tables.extend([
{
"page_number": page["page_number"],
"table_data": table
}
for table in page_tables
])
return tables
async def _multimodal_understand(self, pages: List[Dict]) -> Dict:
"""多模态文档理解"""
# 选择关键页面进行多模态理解（首页、目录页、重要章节页）
key_pages = self._select_key_pages(pages)
# 构建多模态Prompt
prompt = """
分析这份文档的结构和内容，返回：
1. 文档标题
2. 章节结构（章节号、章节标题、页码范围）
3. 主要内容摘要
"""
# 调用Qwen2.5-VL-32B
result = await self.ai_service.chat_completion(
request=AIRequest(
prompt=prompt,
images=[page["image"] for page in key_pages],
max_tokens=4096
),
task_type=TaskType.DOCUMENT_PARSE
)
return json.loads(result.content)
async def _create_vector_index(
self,
project_id: int,
tender_id: int,
parse_result: Dict
):
"""创建向量索引"""
# 为每个段落生成向量
collection_name = f"project_{project_id}"
for section in parse_result["sections"]:
# 调用嵌入模型生成向量
embedding = await self.ai_service.get_embedding(section["text"])
# 存储到ChromaDB
await self.vector_db.add(
collection_name=collection_name,
ids=[f"{tender_id}_{section['page']}"],
embeddings=[embedding],
metadatas=[{
"tender_id": tender_id,
"page": section["page"],
"section": section.get("section", ""),
"text": section["text"]
}],
documents=[section["text"]]
)
---
d.快速预览服务设计
a.快速预览场景
a.说明
快速预览适用场景：
b.表格数据
场景 说明 模型选择
标书列表预览 显示标书基本信息（供应商、页数、文件大小） 无需AI
目录快速浏览 显示标书目录结构 Qwen2-VL-7B
关键信息提取 提取关键参数（价格、交货期） Qwen2-VL-7B
页面快速预览 单页内容快速预览 Qwen2-VL-7B
b.快速预览服务实现
a.代码示例
---
class QuickPreviewService:
"""快速预览服务"""
def __init__(self, ai_service: AIService):
self.ai_service = ai_service
async def extract_key_info(
self,
tender_id: int,
pages: List[Dict]
) -> Dict:
"""提取关键信息"""
# 选择首页和目录页
key_pages = pages[:5] # 前5页
# 构建Prompt
prompt = """
快速提取以下关键信息：
1. 供应商名称
2. 投标价格
3. 交货期
4. 质保期
5. 主要技术参数
以JSON格式返回。
"""
# 调用Qwen2-VL-7B（快速响应）
result = await self.ai_service.chat_completion(
request=AIRequest(
prompt=prompt,
images=[page["image"] for page in key_pages],
max_tokens=1024,
temperature=0.3
),
task_type=TaskType.QUICK_PREVIEW
)
try:
return json.loads(result.content)
except json.JSONDecodeError:
return {"error": "无法解析关键信息"}
---
b.说明
---
d.Prompt工程
a.Prompt设计原则
a.表格数据
原则 说明 应用场景
明确输出格式 严格定义输出JSON Schema，防止格式错误 所有AI调用
限制输出内容 明确禁止AI做出判断、评分、建议 澄清服务
提供示例 给出期望输出示例，提高准确性 复杂任务
上下文充分 提供足够的上下文信息，减少歧义 文档解析
分步指导 复杂任务分解为多个步骤，逐步指导 多模态理解
b.输出格式验证
a.说明
Pydantic模型验证：
b.代码示例
---
from pydantic import BaseModel, Field, validator
from typing import List, Optional
class NonCompliantItem(BaseModel):
"""不符合项（仅包含定位信息）"""
page: int = Field(..., ge=1, description="页码")
section: str = Field(..., description="章节号")
section_title: str = Field(..., description="章节标题")
tender_requirement: str = Field(..., description="招标要求")
bid_content: str = Field(..., description="标书内容（原文摘录）")
original_text: str = Field(..., description="原文完整摘录")
document_id: str = Field(..., description="文档ID")
@validator('bid_content')
def validate_bid_content(cls, v):
"""验证标书内容不为空"""
if not v or v.strip() == "":
raise ValueError("标书内容不能为空")
return v
class ClarificationResult(BaseModel):
"""澄清结果"""
non_compliant_items: List[NonCompliantItem] = Field(
...,
description="不符合项列表",
min_items=0
)
@validator('non_compliant_items')
def validate_items(cls, v):
"""验证输出仅包含定位信息"""
# 禁止字段
forbidden_fields = [
'compliance_status', # 禁止包含"符合"/"不符合"判断
'score', # 禁止包含评分
'judgment', # 禁止包含判断
'recommendation', # 禁止包含建议
'suggestion', # 禁止包含建议
'modified_text' # 禁止包含修改建议
]
for item in v:
item_dict = item.dict()
for field in forbidden_fields:
if field in item_dict:
raise ValueError(f"禁止字段: {field}")
return v
# 使用示例
def validate_ai_output(ai_content: str) -> ClarificationResult:
"""验证AI输出"""
try:
data = json.loads(ai_content)
result = ClarificationResult(**data)
return result
except (json.JSONDecodeError, ValidationError) as e:
logger.error(f"AI输出验证失败: {e}")
# 返回空结果（而不是抛出异常）
return ClarificationResult(non_compliant_items=[])
---
c.Prompt模板库
a.说明
常用Prompt模板：
b.代码示例
---
# 模板1：澄清提问（已定义）
CLARIFICATION_PROMPT_TEMPLATE = "..."
# 模板2：文档结构分析
DOCUMENT_STRUCTURE_PROMPT = """
分析这份文档的结构，返回：
1. 文档标题
2. 章节列表（章节号、标题、页码范围）
3. 主要内容类型（技术方案、商务条款、其他）
输出JSON格式。
"""
# 模板3：关键信息提取
KEY_INFO_EXTRACTION_PROMPT = """
从文档中提取以下关键信息：
1. 投标价格
2. 交货期
3. 质保期
4. 主要技术参数
5. 资质证书
输出JSON格式。
"""
# 模板4：表格数据提取
TABLE_EXTRACTION_PROMPT = """
提取表格中的数据，返回：
1. 表头
2. 每行数据
输出JSON格式。
"""
# 模板5：章节摘要生成
SECTION_SUMMARY_PROMPT = """
为以下章节生成摘要（100字以内）：
{section_text}
摘要应包含：
1. 主要内容
2. 关键数据
3. 重要结论
"""
---
c.说明
---
e.缓存策略
a.多层缓存架构
a.代码示例
---
┌─────────────────────────────────────────────┐
│ 应用层 │
│ ┌───────────────────────────────────────┐ │
│ │ 澄清请求 │ │
│ └───────────┬───────────────────────────┘ │
└──────────────┼───────────────────────────────┘
│
┌──────────────▼───────────────────────────────┐
│ L1缓存：内存缓存（应用内） │
│ • 容量：100个条目 │
│ • TTL：5分钟 │
│ • 淘汰策略：LRU │
└──────────────┬───────────────────────────────┘
│ 未命中
┌──────────────▼───────────────────────────────┐
│ L2缓存：Redis缓存 │
│ • 容量：10,000个条目 │
│ • TTL：1小时（澄清）/ 10分钟（搜索） │
│ • 淘汰策略：LRU │
└──────────────┬───────────────────────────────┘
│ 未命中
┌──────────────▼───────────────────────────────┐
│ L3：AI服务调用 │
│ • NewAPI网关路由 │
│ • Qwen模型推理 │
└──────────────────────────────────────────────┘
---
b.缓存实现
a.说明
Redis缓存服务：
b.代码示例
---
from typing import Optional
import json
import hashlib
class CacheService:
"""缓存服务"""
def __init__(self, redis_client):
self.redis = redis_client
async def get(self, key: str) -> Optional[str]:
"""获取缓存"""
return await self.redis.get(key)
async def set(
self,
key: str,
value: str,
ex: int = None
):
"""设置缓存"""
await self.redis.set(key, value, ex=ex)
async def delete(self, key: str):
"""删除缓存"""
await self.redis.delete(key)
async def invalidate_pattern(self, pattern: str):
"""批量删除缓存（按模式）"""
keys = await self.redis.keys(pattern)
if keys:
await self.redis.delete(*keys)
class AICacheService:
"""AI缓存服务"""
def __init__(self, cache_service: CacheService):
self.cache = cache_service
def generate_clarification_cache_key(
self,
project_id: int,
question: str,
tender_ids: List[int]
) -> str:
"""生成澄清缓存键"""
key_data = f"clarification:{project_id}:{question}:{','.join(map(str, sorted(tender_ids)))}"
hash_key = hashlib.md5(key_data.encode()).hexdigest()
return f"ai:clarification:{hash_key}"
def generate_search_cache_key(
self,
project_id: int,
query: str,
filters: Dict
) -> str:
"""生成搜索缓存键"""
key_data = f"search:{project_id}:{query}:{json.dumps(filters, sort_keys=True)}"
hash_key = hashlib.md5(key_data.encode()).hexdigest()
return f"ai:search:{hash_key}"
async def get_clarification(
self,
project_id: int,
question: str,
tender_ids: List[int]
) -> Optional[List[Dict]]:
"""获取澄清缓存"""
cache_key = self.generate_clarification_cache_key(
project_id, question, tender_ids
)
cached = await self.cache.get(cache_key)
if cached:
return json.loads(cached)
return None
async def set_clarification(
self,
project_id: int,
question: str,
tender_ids: List[int],
result: List[Dict],
ttl: int = 3600
):
"""设置澄清缓存"""
cache_key = self.generate_clarification_cache_key(
project_id, question, tender_ids
)
await self.cache.set(
cache_key,
json.dumps(result),
ex=ttl
)
---
c.缓存预热策略
a.说明
开标时刻缓存预热：
b.代码示例
---
class CacheWarmupService:
"""缓存预热服务"""
def __init__(
self,
ai_service: AIService,
cache_service: AICacheService,
db_session
):
self.ai_service = ai_service
self.cache = cache_service
self.db = db_session
async def warmup_before_opening(
self,
project_id: int,
tender_ids: List[int]
):
"""开标前预热缓存"""
# 1. 预热常见问题
common_questions = [
"技术参数是否符合要求？",
"商务条款是否完整？",
"价格是否合理？"
]
for question in common_questions:
# 后台执行澄清请求（缓存结果）
asyncio.create_task(
self._warmup_clarification(project_id, question, tender_ids)
)
async def _warmup_clarification(
self,
project_id: int,
question: str,
tender_ids: List[int]
):
"""预热澄清缓存"""
# 检查缓存是否存在
cached = await self.cache.get_clarification(
project_id, question, tender_ids
)
if cached:
return # 缓存已存在
# 执行澄清请求（结果会自动缓存）
# 注意：这里不返回结果，仅为了预热缓存
pass
---
c.说明
---
f.错误处理与监控
a.错误分类与处理
a.说明
错误分类：
b.表格数据
错误类型 说明 处理策略
模型不可用 模型服务宕机 降级到备用模型
推理超时 请求超时 重试3次，每次递增延迟
输出格式错误 AI输出不符合预期 返回空结果，记录日志
速率限制 超过QPS限制 排队等待，返回降级服务
NPU资源不足 显存不足 降低批处理大小，排队等待
c.说明
错误处理实现：
d.代码示例
---
from typing import Callable, TypeVar
import asyncio
T = TypeVar('T')
class AIErrorHandler:
"""AI错误处理器"""
def __init__(
self,
max_retries: int = 3,
base_delay_ms: int = 1000
):
self.max_retries = max_retries
self.base_delay_ms = base_delay_ms
async def call_with_retry(
self,
func: Callable[..., T],
*args,
**kwargs
) -> T:
"""带重试的调用"""
last_exception = None
for attempt in range(self.max_retries):
try:
return await func(*args, **kwargs)
except Exception as e:
last_exception = e
# 判断是否可重试
if not self._is_retryable(e):
break
# 指数退避
delay = self.base_delay_ms * (2 ** attempt)
logger.warning(f"AI调用失败，{delay}ms后重试（第{attempt + 1}次）: {str(e)}")
await asyncio.sleep(delay / 1000)
# 所有重试都失败
logger.error(f"AI调用最终失败: {str(last_exception)}")
raise last_exception
def _is_retryable(self, error: Exception) -> bool:
"""判断是否可重试"""
# 可重试的错误类型
retryable_errors = (
httpx.TimeoutException,
httpx.ConnectError,
httpx.RemoteProtocolError,
# 模型服务不可用（502/503/504）
)
return isinstance(error, retryable_errors)
# 使用示例
error_handler = AIErrorHandler(max_retries=3, base_delay_ms=1000)
async def safe_ai_call(
prompt: str,
task_type: TaskType
) -> AIResponse:
"""安全的AI调用（带重试）"""
return await error_handler.call_with_retry(
ai_service.chat_completion,
AIRequest(prompt=prompt),
task_type
)
---
b.监控指标
a.说明
Prometheus指标定义：
b.代码示例
---
from prometheus_client import Counter, Gauge, Histogram
# AI调用指标
ai_requests_total = Counter(
'ai_requests_total',
'AI请求总数',
['task_type', 'model', 'status']
)
ai_request_duration_seconds = Histogram(
'ai_request_duration_seconds',
'AI请求耗时（秒）',
['task_type', 'model'],
buckets=[0.5, 1, 2, 5, 10, 30, 60, 120]
)
ai_cache_hits_total = Counter(
'ai_cache_hits_total',
'AI缓存命中总数',
['cache_type'] # 'clarification' or 'search'
)
ai_cache_misses_total = Counter(
'ai_cache_misses_total',
'AI缓存未命中总数',
['cache_type']
)
# 模型指标
model_tokens_used_total = Counter(
'model_tokens_used_total',
'模型Token消耗总数',
['model', 'token_type'] # 'prompt' or 'completion'
)
model_active_requests = Gauge(
'model_active_requests',
'模型活跃请求数',
['model']
)
# 错误指标
ai_errors_total = Counter(
'ai_errors_total',
'AI错误总数',
['error_type', 'model']
)
---
c.告警规则
a.说明
关键告警规则：
b.代码示例
---
ALERT_RULES = [
{
"rule_id": "ai_high_error_rate",
"rule_name": "AI错误率过高",
"expr": "rate(ai_errors_total[5m]) / rate(ai_requests_total[5m]) > 0.1",
"severity": "critical",
"duration": "5m"
},
{
"rule_id": "ai_slow_response",
"rule_name": "AI响应时间过长",
"expr": "histogram_quantile(0.95, ai_request_duration_seconds) > 30",
"severity": "warning",
"duration": "5m"
},
{
"rule_id": "ai_cache_hit_low",
"rule_name": "AI缓存命中率过低",
"expr": "ai_cache_hits_total / (ai_cache_hits_total + ai_cache_misses_total) < 0.3",
"severity": "info",
"duration": "10m"
},
{
"rule_id": "model_queue_full",
"rule_name": "模型请求队列满",
"expr": "model_active_requests > 15",
"severity": "warning",
"duration": "2m"
}
]
---
c.说明
---
g.性能优化策略
a.批处理优化
a.说明
批量处理策略：
b.代码示例
---
class BatchProcessor:
"""批处理器"""
def __init__(
self,
ai_service: AIService,
batch_size: int = 8,
timeout_ms: int = 5000
):
self.ai_service = ai_service
self.batch_size = batch_size
self.timeout_ms = timeout_ms
async def process_batch(
self,
requests: List[AIRequest],
task_type: TaskType
) -> List[AIResponse]:
"""批量处理请求"""
# 分批处理
batches = [
requests[i:i + self.batch_size]
for i in range(0, len(requests), self.batch_size)
]
results = []
for batch in batches:
# 并发处理一批
batch_results = await asyncio.gather(*[
self.ai_service.chat_completion(req, task_type)
for req in batch
], return_exceptions=True)
# 处理异常
for result in batch_results:
if isinstance(result, Exception):
logger.error(f"批处理失败: {result}")
# 返回默认结果
results.append(self._get_default_response())
else:
results.append(result)
return results
def _get_default_response(self) -> AIResponse:
"""获取默认响应（降级）"""
return AIResponse(
content="",
model="fallback",
usage={},
processing_time_ms=0
)
---
b.并发控制
a.说明
信号量限制并发：
b.代码示例
---
import asyncio
class ConcurrencyLimiter:
"""并发限制器"""
def __init__(
self,
max_concurrent: int = 20
):
self.semaphore = asyncio.Semaphore(max_concurrent)
async def __aenter__(self):
await self.semaphore.acquire()
return self
async def __aexit__(self, exc_type, exc_val, exc_tb):
self.semaphore.release()
# 使用示例
limiter = ConcurrencyLimiter(max_concurrent=20)
async def limited_ai_call(prompt: str) -> AIResponse:
"""限制并发的AI调用"""
async with limiter:
return await ai_service.chat_completion(
AIRequest(prompt=prompt),
TaskType.CLARIFICATION
)
---
c.说明
---
h.总结
a.核心设计总结
a.表格数据
维度 设计方案 核心优势
模型管理 NewAPI统一网关 统一接口、智能路由、负载均衡
模型选择 任务类型路由 性能与成本最优
Prompt工程 严格格式限制 仅提供参考依据，合规安全
缓存策略 三层缓存架构 降低AI调用成本，提升响应速度
错误处理 自动重试+降级 高可用性
监控告警 完整指标体系 可观测性，快速定位问题
b.关键性能指标
a.表格数据
指标 目标值 监控方式
澄清响应时间 P95 < 3秒 Prometheus监控
文档解析时间 100页 < 5分钟 任务队列监控
缓存命中率 > 50% Redis监控
AI调用成功率 > 99% 错误率监控
模型并发能力 20个并发 活跃连接数监控
b.说明
---
文档版本：v1.0
最后更新：2026-01-18
文档状态：初稿
05.后端API架构设计
a.后端架构概览
a.架构定位
a.说明
后端API在系统中的位置：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 前端层 │
│ Vue3 + Element Plus + WebSocket Client │
└────────────────┬────────────────────────────────────┘
│ HTTP/WebSocket
┌────────────────▼────────────────────────────────────┐
│ 后端API层 │
│ ┌──────────────────────────────────────────────┐ │
│ │ FastAPI应用服务 │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ API路由 │ │ 中间件 │ │ │
│ │ │ 设计 │ │ 管道 │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │
│ │ │ 业务逻辑层 │ │ 依赖注入 │ │ │
│ │ │ (Services) │ │ (DI) │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │
│ │ │ 数据访问层 │ │ 任务队列 │ │ │
│ │ │ (DAL) │ │ (Celery) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
└────────────────┬────────────────────────────────────┘
│
┌────────────────▼────────────────────────────────────┐
│ 数据层 │
│ PostgreSQL │ ChromaDB │ Redis │ MinIO │ NewAPI │
└──────────────────────────────────────────────────────┘
---
b.核心设计原则
a.表格数据
原则 说明 应用场景
RESTful规范 标准HTTP方法、资源命名、状态码 所有API设计
异步优先 原生async/await，高并发处理 所有I/O操作
依赖注入 解耦组件，便于测试 服务层、数据层
中间件管道 请求预处理、响应后处理 认证、日志、限流
类型安全 Pydantic验证，自动文档生成 所有请求/响应
错误统一 标准错误码、错误消息格式 异常处理
文档自动 OpenAPI规范，Swagger UI API文档
c.技术栈选型
a.表格数据
组件 技术选型 版本要求 核心优势
Web框架 FastAPI 0.104+ 高性能异步、自动文档
异步运行时 Uvicorn 0.24+ ASGI服务器、高性能
ORM SQLAlchemy 2.0+ 成熟ORM、异步支持
数据验证 Pydantic 2.0+ 类型安全、自动验证
任务队列 Celery 5.3+ 分布式任务、任务链
API文档 Swagger/OpenAPI 3.0+ 自动生成、交互式
依赖注入 FastAPI Depends 内置 优雅的依赖管理
b.说明
---
b.FastAPI项目结构
a.目录结构设计
a.说明
标准项目结构：
b.代码示例
---
backend/
├── app/
│ ├── __init__.py # 应用初始化
│ ├── main.py # FastAPI应用入口
│ │
│ ├── api/ # API路由层
│ │ ├── __init__.py
│ │ ├── deps.py # 依赖注入
│ │ ├── v1/ # API v1版本
│ │ │ ├── __init__.py
│ │ │ ├── auth.py # 认证相关API
│ │ │ ├── projects.py # 项目管理API
│ │ │ ├── tenders.py # 标书管理API
│ │ │ ├── clarifications.py # 澄清API
│ │ │ ├── scores.py # 评分API
│ │ │ ├── reports.py # 报告API
│ │ │ └── configs.py # 配置API
│ │ └── websocket.py # WebSocket路由
│ │
│ ├── core/ # 核心配置
│ │ ├── __init__.py
│ │ ├── config.py # 应用配置
│ │ ├── security.py # 安全配置（JWT）
│ │ ├── logging.py # 日志配置
│ │ └── constants.py # 常量定义
│ │
│ ├── models/ # 数据模型（SQLAlchemy）
│ │ ├── __init__.py
│ │ ├── base.py # 基类
│ │ ├── project.py # 项目模型
│ │ ├── tender.py # 标书模型
│ │ ├── clarification.py # 澄清模型
│ │ ├── score.py # 评分模型
│ │ └── audit.py # 审计模型
│ │
│ ├── schemas/ # Pydantic模式
│ │ ├── __init__.py
│ │ ├── common.py # 通用模式
│ │ ├── project.py # 项目Schema
│ │ ├── tender.py # 标书Schema
│ │ ├── clarification.py # 澄清Schema
│ │ ├── score.py # 评分Schema
│ │ └── audit.py # 审计Schema
│ │
│ ├── services/ # 业务逻辑层
│ │ ├── __init__.py
│ │ ├── auth_service.py # 认证服务
│ │ ├── project_service.py # 项目服务
│ │ ├── tender_service.py # 标书服务
│ │ ├── clarification_service.py # 澄清服务
│ │ ├── score_service.py # 评分服务
│ │ ├── ai_service.py # AI服务
│ │ ├── vector_service.py # 向量服务
│ │ └── report_service.py # 报告服务
│ │
│ ├── crud/ # 数据访问层（CRUD）
│ │ ├── __init__.py
│ │ ├── base.py # 基类CRUD
│ │ ├── project.py # 项目CRUD
│ │ ├── tender.py # 标书CRUD
│ │ ├── clarification.py # 澄清CRUD
│ │ └── score.py # 评分CRUD
│ │
│ ├── tasks/ # Celery任务
│ │ ├── __init__.py
│ │ ├── celery_app.py # Celery应用
│ │ ├── document_parse.py # 文档解析任务
│ │ ├── vector_index.py # 向量索引任务
│ │ └── report_generate.py # 报告生成任务
│ │
│ ├── middleware/ # 中间件
│ │ ├── __init__.py
│ │ ├── auth.py # 认证中间件
│ │ ├── logging.py # 日志中间件
│ │ ├── error_handler.py # 错误处理中间件
│ │ ├── rate_limit.py # 限流中间件
│ │ └── cors.py # CORS中间件
│ │
│ ├── utils/ # 工具函数
│ │ ├── __init__.py
│ │ ├── datetime.py # 日期时间工具
│ │ ├── file.py # 文件处理工具
│ │ ├── validator.py # 验证器
│ │ └── response.py # 响应格式化
│ │
│ └── db/ # 数据库
│ ├── __init__.py
│ ├── session.py # 数据库会话
│ └── init_db.py # 初始化数据库
│
├── tests/ # 测试
│ ├── __init__.py
│ ├── conftest.py # pytest配置
│ ├── test_api/ # API测试
│ ├── test_services/ # 服务测试
│ └── test_tasks/ # 任务测试
│
├── alembic/ # 数据库迁移
│ ├── versions/
│ └── env.py
│
├── requirements.txt # Python依赖
├── Dockerfile # Docker镜像
└── .env.example # 环境变量示例
---
b.应用入口配置
a.说明
main.py应用入口：
b.代码示例
---
from fastapi import FastAPI, Request, status
from fastapi.middleware.cors import CORSMiddleware
from fastapi.middleware.gzip import GZipMiddleware
from fastapi.responses import JSONResponse
from fastapi.exceptions import RequestValidationError
from contextlib import asynccontextmanager
import logging
from app.core.config import settings
from app.core.logging import setup_logging
from app.api.deps import get_db
from app.middleware import (
AuthMiddleware,
LoggingMiddleware,
RateLimitMiddleware,
ErrorHandlerMiddleware
)
from app.api.v1 import (
auth,
projects,
tenders,
clarifications,
scores,
reports,
configs
)
from app.api.websocket import websocket_router
# 设置日志
logger = setup_logging(__name__)
# 应用生命周期管理
@asynccontextmanager
async def lifespan(app: FastAPI):
"""应用生命周期管理"""
# 启动时执行
logger.info("应用启动中...")
logger.info(f"环境: {settings.ENVIRONMENT}")
logger.info(f"调试模式: {settings.DEBUG}")
# 初始化数据库连接
from app.db.init_db import init_db
await init_db()
# 初始化Redis连接
from app.core.redis import init_redis
await init_redis()
# 初始化向量数据库
from app.services.vector_service import init_vector_db
await init_vector_db()
logger.info("应用启动完成")
yield
# 关闭时执行
logger.info("应用关闭中...")
# 关闭数据库连接
from app.db.session import engine
await engine.dispose()
# 关闭Redis连接
from app.core.redis import close_redis
await close_redis()
logger.info("应用已关闭")
# 创建FastAPI应用
app = FastAPI(
title="企业采购评标系统API",
description="基于昇腾NPU的AI辅助评标系统",
version="1.0.0",
docs_url="/docs" if settings.DEBUG else None, # 生产环境关闭文档
redoc_url="/redoc" if settings.DEBUG else None,
openapi_url="/openapi.json" if settings.DEBUG else None,
lifespan=lifespan
)
# 注册中间件（注意顺序）
app.add_middleware(
CORSMiddleware,
allow_origins=settings.CORS_ORIGINS,
allow_credentials=True,
allow_methods=["*"],
allow_headers=["*"],
)
app.add_middleware(GZipMiddleware, minimum_size=1000)
app.add_middleware(ErrorHandlerMiddleware)
app.add_middleware(LoggingMiddleware)
app.add_middleware(RateLimitMiddleware)
app.add_middleware(AuthMiddleware)
# 注册路由
app.include_router(auth.router, prefix="/api/v1/auth", tags=["认证"])
app.include_router(projects.router, prefix="/api/v1/projects", tags=["项目管理"])
app.include_router(tenders.router, prefix="/api/v1/tenders", tags=["标书管理"])
app.include_router(clarifications.router, prefix="/api/v1/clarifications", tags=["澄清服务"])
app.include_router(scores.router, prefix="/api/v1/scores", tags=["评分管理"])
app.include_router(reports.router, prefix="/api/v1/reports", tags=["报告生成"])
app.include_router(configs.router, prefix="/api/v1/configs", tags=["配置管理"])
app.include_router(websocket_router, prefix="/ws", tags=["WebSocket"])
# 全局异常处理
@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request: Request, exc: RequestValidationError):
"""请求验证异常处理"""
logger.error(f"请求验证失败: {exc.errors()}")
return JSONResponse(
status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
content={
"success": False,
"message": "请求参数验证失败",
"errors": exc.errors()
}
)
@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
"""全局异常处理"""
logger.error(f"未处理的异常: {str(exc)}", exc_info=True)
return JSONResponse(
status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
content={
"success": False,
"message": "服务器内部错误",
"detail": str(exc) if settings.DEBUG else None
}
)
# 健康检查
@app.get("/health")
async def health_check():
"""健康检查端点"""
return {
"status": "healthy",
"service": "evaluation-system-api",
"version": "1.0.0"
}
# 根路径
@app.get("/")
async def root():
"""根路径"""
return {
"message": "企业采购评标系统API",
"version": "1.0.0",
"docs": "/docs" if settings.DEBUG else "disabled"
}
---
c.配置管理
a.说明
core/config.py配置：
b.代码示例
---
from pydantic_settings import BaseSettings
from typing import List, Optional
from functools import lru_cache
class Settings(BaseSettings):
"""应用配置"""
# 应用基础配置
APP_NAME: str = "企业采购评标系统"
APP_VERSION: str = "1.0.0"
ENVIRONMENT: str = "prod" # dev/staging/prod
DEBUG: bool = False
# API配置
API_V1_PREFIX: str = "/api/v1"
MAX_UPLOAD_SIZE: int = 500 * 1024 * 1024 # 500MB
# 服务器配置
HOST: str = "0.0.0.0"
PORT: int = 8080
WORKERS: int = 4
# 数据库配置
DATABASE_URL: str
DB_POOL_SIZE: int = 20
DB_MAX_OVERFLOW: int = 10
DB_POOL_RECYCLE: int = 3600
# Redis配置
REDIS_URL: str
REDIS_MAX_CONNECTIONS: int = 50
# JWT配置
JWT_SECRET_KEY: str
JWT_ALGORITHM: str = "HS256"
JWT_ACCESS_TOKEN_EXPIRE_MINUTES: int = 480
# CORS配置
CORS_ORIGINS: List[str] = ["http://localhost:5173"]
# 文件存储配置
STORAGE_TYPE: str = "local" # local/minio
LOCAL_STORAGE_PATH: str = "./data/uploads"
MINIO_ENDPOINT: Optional[str] = None
MINIO_ACCESS_KEY: Optional[str] = None
MINIO_SECRET_KEY: Optional[str] = None
MINIO_BUCKET: str = "evaluation-docs"
# AI服务配置
NEWAPI_GATEWAY_URL: str
NEWAPI_API_KEY: str
AI_TIMEOUT_SECONDS: int = 120
AI_MAX_RETRIES: int = 3
# Celery配置
CELERY_BROKER_URL: str
CELERY_RESULT_BACKEND: str
CELERY_TASK_TIMEOUT: int = 3600
# 监控配置
PROMETHEUS_ENABLED: bool = True
PROMETHEUS_PORT: int = 9090
# 日志配置
LOG_LEVEL: str = "INFO"
LOG_FILE_DIR: str = "./logs"
class Config:
env_file = ".env"
case_sensitive = True
@lru_cache()
def get_settings() -> Settings:
"""获取配置单例"""
return Settings()
settings = get_settings()
---
c.说明
---
c.中间件设计
a.认证中间件
a.说明
JWT认证实现：
b.代码示例
---
from fastapi import Request, HTTPException, status
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse
from jose import JWTError, jwt
from app.core.security import (
verify_token,
get_token_from_header
)
from app.core.config import settings
import logging
logger = logging.getLogger(__name__)
class AuthMiddleware(BaseHTTPMiddleware):
"""认证中间件"""
# 跳过认证的路径
SKIP_AUTH_PATHS = [
"/",
"/health",
"/docs",
"/redoc",
"/openapi.json",
"/api/v1/auth/login",
"/api/v1/auth/register",
"/ws" # WebSocket有自己的认证机制
]
async def dispatch(self, request: Request, call_next):
"""处理请求"""
# 检查是否跳过认证
if request.url.path in self.SKIP_AUTH_PATHS:
return await call_next(request)
# WebSocket特殊处理
if request.url.path.startswith("/ws"):
return await call_next(request)
try:
# 获取Token
token = get_token_from_header(request)
if not token:
return JSONResponse(
status_code=status.HTTP_401_UNAUTHORIZED,
content={
"success": False,
"message": "未提供认证Token"
}
)
# 验证Token
payload = verify_token(token)
if not payload:
return JSONResponse(
status_code=status.HTTP_401_UNAUTHORIZED,
content={
"success": False,
"message": "Token无效或已过期"
}
)
# 将用户信息添加到请求状态
request.state.user_id = payload.get("sub")
request.state.username = payload.get("username")
request.state.role = payload.get("role")
return await call_next(request)
except JWTError as e:
logger.error(f"JWT验证失败: {str(e)}")
return JSONResponse(
status_code=status.HTTP_401_UNAUTHORIZED,
content={
"success": False,
"message": "Token验证失败"
}
)
---
b.日志中间件
a.说明
请求/响应日志：
b.代码示例
---
import time
import logging
from fastapi import Request
from starlette.middleware.base import BaseHTTPMiddleware
logger = logging.getLogger(__name__)
class LoggingMiddleware(BaseHTTPMiddleware):
"""日志中间件"""
async def dispatch(self, request: Request, call_next):
"""记录请求和响应"""
start_time = time.time()
# 记录请求信息
logger.info(
f"请求开始: {request.method} {request.url.path} "
f"客户端: {request.client.host if request.client else 'unknown'}"
)
# 处理请求
response = await call_next(request)
# 计算处理时间
process_time = time.time() - start_time
# 记录响应信息
logger.info(
f"请求完成: {request.method} {request.url.path} "
f"状态码: {response.status_code} "
f"耗时: {process_time:.3f}秒"
)
# 添加响应头
response.headers["X-Process-Time"] = str(process_time)
return response
---
c.限流中间件
a.说明
基于Token Bucket的限流：
b.代码示例
---
from fastapi import Request, HTTPException
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse
from starlette.datastructures import Headers
import time
import hashlib
from typing import Dict
from app.core.redis import get_redis
class RateLimitMiddleware(BaseHTTPMiddleware):
"""限流中间件"""
# 限流规则（每分钟请求数）
RATE_LIMITS = {
"default": 60, # 默认: 60请求/分钟
"clarify": 30, # 澄清: 30请求/分钟
"upload": 10, # 上传: 10请求/分钟
"score": 60, # 评分: 60请求/分钟
}
async def dispatch(self, request: Request, call_next):
"""处理请求限流"""
# 获取客户端标识
client_id = self._get_client_id(request)
# 确定限流规则
rate_key = self._get_rate_key(request)
rate_limit = self.RATE_LIMITS.get(rate_key, self.RATE_LIMITS["default"])
# 检查限流
if not await self._check_rate_limit(client_id, rate_limit):
return JSONResponse(
status_code=429,
content={
"success": False,
"message": "请求过于频繁，请稍后再试",
"retry_after": 60
},
headers={
"Retry-After": "60"
}
)
return await call_next(request)
def _get_client_id(self, request: Request) -> str:
"""获取客户端标识"""
# 优先使用用户ID（已认证）
if hasattr(request.state, "user_id"):
return f"user:{request.state.user_id}"
# 其次使用IP地址
forward_for = request.headers.get("X-Forwarded-For")
if forward_for:
return f"ip:{forward_for.split(',')[0].strip()}"
return f"ip:{request.client.host if request.client else 'unknown'}"
def _get_rate_key(self, request: Request) -> str:
"""获取限流规则键"""
path = request.url.path
if "/clarifications" in path:
return "clarify"
elif "/upload" in path:
return "upload"
elif "/scores" in path:
return "score"
else:
return "default"
async def _check_rate_limit(
self,
client_id: str,
rate_limit: int
) -> bool:
"""检查是否超过限流"""
redis = get_redis()
if not redis:
return True # Redis不可用，不限流
key = f"ratelimit:{client_id}"
# 使用Redis INCR实现限流
pipe = redis.pipeline()
pipe.incr(key)
pipe.expire(key, 60) # 60秒过期
results = await pipe.execute()
current_count = results[0]
return current_count <= rate_limit
---
d.错误处理中间件
a.说明
统一错误处理：
b.代码示例
---
from fastapi import Request, status
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse
from starlette.exceptions import HTTPException as StarletteHTTPException
from fastapi.exceptions import RequestValidationError
import logging
logger = logging.getLogger(__name__)
class ErrorHandlerMiddleware(BaseHTTPMiddleware):
"""错误处理中间件"""
async def dispatch(self, request: Request, call_next):
"""捕获并处理异常"""
try:
return await call_next(request)
except StarletteHTTPException as exc:
# HTTP异常
return JSONResponse(
status_code=exc.status_code,
content={
"success": False,
"message": exc.detail,
"status_code": exc.status_code
}
)
except RequestValidationError as exc:
# 请求验证异常
logger.error(f"请求验证失败: {exc.errors()}")
return JSONResponse(
status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
content={
"success": False,
"message": "请求参数验证失败",
"errors": exc.errors()
}
)
except ValueError as exc:
# 值错误
logger.error(f"值错误: {str(exc)}")
return JSONResponse(
status_code=status.HTTP_400_BAD_REQUEST,
content={
"success": False,
"message": str(exc)
}
)
except Exception as exc:
# 未捕获的异常
logger.error(f"未处理的异常: {str(exc)}", exc_info=True)
return JSONResponse(
status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
content={
"success": False,
"message": "服务器内部错误"
}
)
---
c.说明
---
d.路由设计
a.RESTful路由规范
a.说明
路由设计原则：
b.表格数据
原则 说明 示例
资源名词 使用名词复数形式 /api/v1/projects
层级关系 使用路径表示层级 /api/v1/projects/{id}/tenders
HTTP方法 标准REST方法 GET/POST/PUT/DELETE
版本控制 URL路径版本 /api/v1/
查询参数 过滤、排序、分页 ?status=active&page=1
c.说明
标准CRUD路由模板：
d.代码示例
---
from fastapi import APIRouter, Depends, HTTPException, status, Query
from typing import List, Optional
from app.schemas.project import (
ProjectCreate,
ProjectUpdate,
ProjectResponse,
ProjectListResponse
)
from app.services.project_service import ProjectService
from app.api.deps import (
get_current_user,
get_db,
PaginationParams
)
router = APIRouter()
@router.get(
"",
response_model=ProjectListResponse,
summary="获取项目列表",
description="获取项目列表，支持分页、过滤、排序"
)
async def list_projects(
status: Optional[str] = Query(None, description="项目状态"),
search: Optional[str] = Query(None, description="搜索关键词"),
page: int = Query(1, ge=1, description="页码"),
page_size: int = Query(20, ge=1, le=100, description="每页数量"),
sort_by: str = Query("created_at", description="排序字段"),
sort_order: str = Query("desc", regex="^(asc|desc)$", description="排序方向"),
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> ProjectListResponse:
"""获取项目列表"""
service = ProjectService(db)
# 构建查询参数
filters = {}
if status:
filters["status"] = status
# 查询项目列表
projects, total = await service.list_projects(
filters=filters,
search=search,
page=page,
page_size=page_size,
sort_by=sort_by,
sort_order=sort_order
)
return ProjectListResponse(
items=projects,
total=total,
page=page,
page_size=page_size,
pages=(total + page_size - 1) // page_size
)
@router.post(
"",
response_model=ProjectResponse,
status_code=status.HTTP_201_CREATED,
summary="创建项目",
description="创建新的评标项目"
)
async def create_project(
project_data: ProjectCreate,
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> ProjectResponse:
"""创建项目"""
service = ProjectService(db)
# 创建项目
project = await service.create_project(
project_data=project_data,
creator_id=current_user.id
)
return project
@router.get(
"/{project_id}",
response_model=ProjectResponse,
summary="获取项目详情",
description="获取指定项目的详细信息"
)
async def get_project(
project_id: int,
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> ProjectResponse:
"""获取项目详情"""
service = ProjectService(db)
# 获取项目
project = await service.get_project(project_id=project_id)
if not project:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="项目不存在"
)
return project
@router.put(
"/{project_id}",
response_model=ProjectResponse,
summary="更新项目",
description="更新项目信息"
)
async def update_project(
project_id: int,
project_data: ProjectUpdate,
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> ProjectResponse:
"""更新项目"""
service = ProjectService(db)
# 更新项目
project = await service.update_project(
project_id=project_id,
project_data=project_data,
updater_id=current_user.id
)
if not project:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="项目不存在"
)
return project
@router.delete(
"/{project_id}",
status_code=status.HTTP_204_NO_CONTENT,
summary="删除项目",
description="删除指定项目（软删除）"
)
async def delete_project(
project_id: int,
current_user = Depends(get_current_user),
db = Depends(get_db)
):
"""删除项目"""
service = ProjectService(db)
# 删除项目
success = await service.delete_project(
project_id=project_id,
deleter_id=current_user.id
)
if not success:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="项目不存在"
)
return None
---
b.澄清API路由
a.说明
澄清服务路由：
b.代码示例
---
from fastapi import APIRouter, Depends, HTTPException, status, BackgroundTasks
from typing import List
from app.schemas.clarification import (
ClarificationRequest,
ClarificationResponse,
ClarificationHistoryResponse
)
from app.services.clarification_service import ClarificationService
from app.api.deps import get_current_user, get_db
router = APIRouter()
@router.post(
"",
response_model=ClarificationResponse,
summary="提交澄清提问",
description="专家提交澄清提问，AI返回参考依据"
)
async def submit_clarification(
request: ClarificationRequest,
background_tasks: BackgroundTasks,
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> ClarificationResponse:
"""提交澄清提问"""
service = ClarificationService(db)
# 权限检查：只有评标专家可以提交澄清
if current_user.role not in ["evaluation_expert", "evaluation_admin"]:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="只有评标专家可以提交澄清提问"
)
# 执行澄清分析
result = await service.clarify(
request=request,
expert_id=current_user.id
)
# 后台记录审计日志
background_tasks.add_task(
service.log_clarification,
request,
result,
current_user.id
)
return result
@router.get(
"/history",
response_model=List[ClarificationHistoryResponse],
summary="获取澄清历史",
description="获取指定项目的澄清历史记录"
)
async def get_clarification_history(
project_id: int,
limit: int = Query(10, ge=1, le=100, description="返回记录数量"),
current_user = Depends(get_current_user),
db = Depends(get_db)
) -> List[ClarificationHistoryResponse]:
"""获取澄清历史"""
service = ClarificationService(db)
# 获取历史记录
history = await service.get_history(
project_id=project_id,
limit=limit
)
return history
@router.post(
"/{clarification_id}/review",
summary="专家复核澄清结果",
description="专家对AI澄清结果进行复核（接受/拒绝/修改）"
)
async def review_clarification(
clarification_id: int,
action: str = Query(..., regex="^(accept|reject|modify|ignore)$"),
notes: str = Query(None, description="专家备注"),
current_user = Depends(get_current_user),
db = Depends(get_db)
):
"""专家复核澄清结果"""
service = ClarificationService(db)
# 权限检查
if current_user.role != "evaluation_expert":
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="只有评标专家可以复核澄清结果"
)
# 更新复核状态
await service.review_clarification(
clarification_id=clarification_id,
expert_id=current_user.id,
action=action,
notes=notes
)
return {
"success": True,
"message": "复核操作已记录"
}
---
c.WebSocket路由
a.说明
实时通信路由：
b.代码示例
---
from fastapi import APIRouter, WebSocket, WebSocketDisconnect, Depends, Query
from typing import Dict, Set
import json
import logging
from app.api.deps import get_current_user_websocket
logger = logging.getLogger(__name__)
router = APIRouter()
# 连接管理器
class ConnectionManager:
"""WebSocket连接管理器"""
def __init__(self):
# 项目ID -> 连接集合
self.project_connections: Dict[int, Set[WebSocket]] = {}
async def connect(self, websocket: WebSocket, project_id: int):
"""接受连接"""
await websocket.accept()
if project_id not in self.project_connections:
self.project_connections[project_id] = set()
self.project_connections[project_id].add(websocket)
logger.info(f"WebSocket连接已建立: project_id={project_id}")
def disconnect(self, websocket: WebSocket, project_id: int):
"""断开连接"""
if project_id in self.project_connections:
self.project_connections[project_id].discard(websocket)
if not self.project_connections[project_id]:
del self.project_connections[project_id]
logger.info(f"WebSocket连接已断开: project_id={project_id}")
async def broadcast_to_project(
self,
project_id: int,
message: dict
):
"""向项目所有连接广播消息"""
if project_id not in self.project_connections:
return
# 准备消息
message_str = json.dumps(message, ensure_ascii=False)
# 广播给所有连接
for websocket in self.project_connections[project_id]:
try:
await websocket.send_text(message_str)
except Exception as e:
logger.error(f"广播消息失败: {str(e)}")
# 全局连接管理器
manager = ConnectionManager()
@router.websocket("/project/{project_id}")
async def websocket_project_updates(
websocket: WebSocket,
project_id: int,
token: str = Query(..., description="JWT Token")
):
"""项目实时更新WebSocket"""
# 验证Token
user = await get_current_user_websocket(token)
if not user:
await websocket.close(code=1008, reason="认证失败")
return
# 接受连接
await manager.connect(websocket, project_id)
try:
# 保持连接并处理消息
while True:
data = await websocket.receive_text()
# 处理客户端消息（心跳、订阅等）
try:
message = json.loads(data)
if message.get("type") == "ping":
# 心跳响应
await websocket.send_text(json.dumps({
"type": "pong",
"timestamp": int(time.time())
}))
except json.JSONDecodeError:
logger.warning(f"无效的WebSocket消息: {data}")
except WebSocketDisconnect:
manager.disconnect(websocket, project_id)
---
c.说明
---
e.依赖注入设计
a.依赖注入模式
a.说明
api/deps.py依赖定义：
b.代码示例
---
from fastapi import Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
from sqlalchemy.ext.asyncio import AsyncSession
from typing import Optional, Generator
from app.db.session import get_db
from app.core.security import verify_token
from app.models.user import User
from app.crud.user import user_crud
security = HTTPBearer()
async def get_db_session() -> AsyncSession:
"""获取数据库会话"""
async with get_db() as session:
yield session
# 简化别名
get_db = get_db_session
async def get_current_user(
credentials: HTTPAuthorizationCredentials = Depends(security),
db: AsyncSession = Depends(get_db)
) -> User:
"""获取当前认证用户"""
# 验证Token
token = credentials.credentials
payload = verify_token(token)
if not payload:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Token无效或已过期",
headers={"WWW-Authenticate": "Bearer"}
)
# 获取用户ID
user_id = payload.get("sub")
if not user_id:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Token中缺少用户ID"
)
# 查询用户
user = await user_crud.get(db, id=int(user_id))
if not user:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="用户不存在"
)
if not user.is_active:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="用户已被禁用"
)
return user
async def get_current_active_user(
current_user: User = Depends(get_current_user)
) -> User:
"""获取当前活跃用户"""
if not current_user.is_active:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="用户已被禁用"
)
return current_user
class PaginationParams:
"""分页参数"""
def __init__(
self,
page: int = 1,
page_size: int = 20
):
if page < 1:
page = 1
if page_size < 1 or page_size > 100:
page_size = 20
self.page = page
self.page_size = page_size
self.skip = (page - 1) * page_size
def get_pagination_params(
page: int = 1,
page_size: int = 20
) -> PaginationParams:
"""获取分页参数"""
return PaginationParams(page, page_size)
---
b.服务层依赖注入
a.说明
服务层工厂：
b.代码示例
---
from functools import lru_cache
from app.services.ai_service import AIService, NewAPIService
from app.services.vector_service import VectorDBService
from app.services.clarification_service import ClarificationService
from app.core.config import settings
@lru_cache()
def get_ai_service() -> AIService:
"""获取AI服务单例"""
return NewAPIService(
gateway_url=settings.NEWAPI_GATEWAY_URL,
api_key=settings.NEWAPI_API_KEY,
timeout=settings.AI_TIMEOUT_SECONDS
)
@lru_cache()
def get_vector_service() -> VectorDBService:
"""获取向量服务单例"""
return VectorDBService(
persist_directory="./data/chroma"
)
def get_clarification_service(
ai_service: AIService = Depends(get_ai_service),
vector_service: VectorDBService = Depends(get_vector_service),
db: AsyncSession = Depends(get_db)
) -> ClarificationService:
"""获取澄清服务实例"""
return ClarificationService(
ai_service=ai_service,
vector_db=vector_service,
db_session=db
)
---
c.说明
---
f.请求验证与限流
a.Pydantic模型验证
a.说明
请求/响应模型：
b.代码示例
---
from pydantic import BaseModel, Field, validator
from typing import List, Optional, Dict
from datetime import datetime
from enum import Enum
class ProjectStatus(str, Enum):
"""项目状态"""
DRAFT = "draft"
PREPARATION = "preparation"
OPENED = "opened"
EVALUATING = "evaluating"
CLOSED = "closed"
ARCHIVED = "archived"
class ProjectCreate(BaseModel):
"""创建项目请求"""
project_name: str = Field(..., min_length=1, max_length=200, description="项目名称")
project_type: str = Field(..., description="项目类型")
budget_amount: float = Field(..., gt=0, description="预算金额（万元）")
planned_opening_date: str = Field(..., description="计划开标日期（YYYY-MM-DD）")
evaluation_method: str = Field(..., description="评标方法")
scoring_config: Dict = Field(default={}, description="评分配置")
@validator("planned_opening_date")
def validate_date_format(cls, v):
"""验证日期格式"""
try:
datetime.strptime(v, "%Y-%m-%d")
except ValueError:
raise ValueError("日期格式必须为YYYY-MM-DD")
return v
@validator("scoring_config")
def validate_scoring_config(cls, v):
"""验证评分配置"""
# 验证权重总和为1.0
weights = v.get("weights", {})
total_weight = sum(weights.values())
if abs(total_weight - 1.0) > 0.01:
raise ValueError("权重总和必须为1.0")
return v
class ProjectResponse(BaseModel):
"""项目响应"""
id: int
project_code: str
project_name: str
project_type: str
budget_amount: float
status: ProjectStatus
planned_opening_date: str
actual_opening_date: Optional[str]
created_at: str
updated_at: str
class Config:
from_attributes = True # Pydantic v2
class ProjectListResponse(BaseModel):
"""项目列表响应"""
items: List[ProjectResponse]
total: int
page: int
page_size: int
pages: int
---
b.文件上传验证
a.说明
文件上传验证器：
b.代码示例
---
from fastapi import UploadFile, HTTPException, status
from typing import List
import aiofiles
import os
from pathlib import Path
ALLOWED_EXTENSIONS = {".pdf", ".docx", ".doc", ".png", ".jpg", ".jpeg", ".tiff"}
MAX_FILE_SIZE = 500 * 1024 * 1024 # 500MB
async def validate_upload_file(
file: UploadFile
) -> UploadFile:
"""验证上传文件"""
# 检查文件扩展名
file_ext = Path(file.filename).suffix.lower()
if file_ext not in ALLOWED_EXTENSIONS:
raise HTTPException(
status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
detail=f"不支持的文件类型: {file_ext}。支持的类型: {', '.join(ALLOWED_EXTENSIONS)}"
)
# 检查文件大小
file_content = await file.read()
file_size = len(file_content)
if file_size > MAX_FILE_SIZE:
raise HTTPException(
status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
detail=f"文件过大。最大允许: {MAX_FILE_SIZE // 1024 // 1024}MB"
)
# 重置文件指针
await file.seek(0)
return file
async def save_upload_file(
file: UploadFile,
save_path: str
) -> str:
"""保存上传文件"""
# 确保目录存在
os.makedirs(os.path.dirname(save_path), exist_ok=True)
# 保存文件
async with aiofiles.open(save_path, "wb") as f:
content = await file.read()
await f.write(content)
return save_path
---
c.限流策略
a.说明
分级限流配置：
b.代码示例
---
from slowapi import Limiter
from slowapi.util import get_remote_address
from slowapi.errors import RateLimitExceeded
from fastapi import Request, HTTPException, status
# 创建限流器
limiter = Limiter(
key_func=get_remote_address,
default_limits=["60/minute"], # 默认: 60次/分钟
storage_uri="redis://localhost:6379/1"
)
# 限流配置
RATE_LIMITS = {
"default": "60/minute",
"clarify": "30/minute",
"upload": "10/minute",
"score": "60/minute",
"report": "5/minute"
}
# 限流异常处理
@app.exception_handler(RateLimitExceeded)
async def rate_limit_exceeded_handler(request: Request, exc: RateLimitExceeded):
"""限流异常处理"""
return JSONResponse(
status_code=status.HTTP_429_TOO_MANY_REQUESTS,
content={
"success": False,
"message": "请求过于频繁，请稍后再试",
"retry_after": str(exc.retry_after)
},
headers={
"Retry-After": str(exc.retry_after)
}
)
---
c.说明
---
g.异常处理
a.自定义异常
a.说明
业务异常定义：
b.代码示例
---
class EvaluationSystemException(Exception):
"""系统异常基类"""
def __init__(
self,
message: str,
status_code: int = 500,
detail: str = None
):
self.message = message
self.status_code = status_code
self.detail = detail
super().__init__(message)
class ProjectNotFoundException(EvaluationSystemException):
"""项目不存在异常"""
def __init__(self, project_id: int):
super().__init__(
message=f"项目不存在: {project_id}",
status_code=404
)
class TenderNotFoundException(EvaluationSystemException):
"""标书不存在异常"""
def __init__(self, tender_id: int):
super().__init__(
message=f"标书不存在: {tender_id}",
status_code=404
)
class AIServiceException(EvaluationSystemException):
"""AI服务异常"""
def __init__(self, message: str, detail: str = None):
super().__init__(
message=f"AI服务错误: {message}",
status_code=503,
detail=detail
)
class ValidationException(EvaluationSystemException):
"""验证异常"""
def __init__(self, message: str, errors: dict = None):
super().__init__(
message=message,
status_code=422,
detail=errors
)
---
b.全局异常处理器
a.说明
异常处理注册：
b.代码示例
---
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import logging
logger = logging.getLogger(__name__)
def register_exception_handlers(app: FastAPI):
"""注册异常处理器"""
@app.exception_handler(EvaluationSystemException)
async def system_exception_handler(
request: Request,
exc: EvaluationSystemException
):
"""系统异常处理"""
logger.error(f"系统异常: {exc.message}", exc_info=True)
return JSONResponse(
status_code=exc.status_code,
content={
"success": False,
"message": exc.message,
"detail": exc.detail
}
)
@app.exception_handler(HTTPException)
async def http_exception_handler(
request: Request,
exc: HTTPException
):
"""HTTP异常处理"""
return JSONResponse(
status_code=exc.status_code,
content={
"success": False,
"message": exc.detail
}
)
@app.exception_handler(Exception)
async def global_exception_handler(
request: Request,
exc: Exception
):
"""全局异常处理"""
logger.error(f"未处理的异常: {str(exc)}", exc_info=True)
return JSONResponse(
status_code=500,
content={
"success": False,
"message": "服务器内部错误"
}
)
---
c.说明
---
h.API文档管理
a.OpenAPI配置
a.说明
文档元数据配置：
b.代码示例
---
from fastapi import FastAPI
from app.core.config import settings
app = FastAPI(
title="企业采购评标系统API",
description="""
## 功能概述
本系统是基于昇腾NPU的AI辅助评标系统，提供以下核心功能：
* **项目管理**：创建和管理评标项目
* **标书管理**：上传和解析标书文档
* **AI澄清**：AI辅助澄清提问（仅提供参考依据）
* **评分管理**：专家手动打分，系统统计
* **报告生成**：自动生成评标报告
## 法律声明
* AI仅提供参考依据，不做判断或纠正
* 最终评审结论由评标委员会做出
* 评标委员会对最终结果承担法律责任
## 认证方式
所有API请求需要在Header中携带JWT Token：
---
c.说明
Authorization: Bearer
d.代码示例
---
## 联系方式
* 技术支持：[email protected]
* 业务咨询：[email protected]
""",
version="1.0.0",
docs_url="/docs" if settings.DEBUG else None,
redoc_url="/redoc" if settings.DEBUG else None,
openapi_url="/openapi.json" if settings.DEBUG else None,
terms_of_service="http://example.com/terms/",
contact={
"name": "技术支持",
"email": "[email protected]",
"url": "http://example.com/support/"
},
license_info={
"name": "企业内部使用",
"url": "http://example.com/license/"
},
openapi_tags=[
{
"name": "认证",
"description": "用户认证和授权相关接口"
},
{
"name": "项目管理",
"description": "评标项目的创建、查询、更新、删除"
},
{
"name": "标书管理",
"description": "标书上传、解析、查询"
},
{
"name": "澄清服务",
"description": "AI辅助澄清提问服务"
},
{
"name": "评分管理",
"description": "专家手动打分和系统统计"
},
{
"name": "报告生成",
"description": "评标报告自动生成"
},
{
"name": "配置管理",
"description": "系统配置和参数管理"
},
{
"name": "WebSocket",
"description": "实时通信接口"
}
]
)
---
b.API文档增强
a.说明
自定义文档响应示例：
b.代码示例
---
from fastapi import FastAPI
from fastapi.openapi.utils import get_openapi
def custom_openapi():
"""自定义OpenAPI Schema"""
if app.openapi_schema:
return app.openapi_schema
openapi_schema = get_openapi(
title=app.title,
version=app.version,
routes=app.routes,
openapi_version=app.openapi_version,
)
# 添加自定义信息
openapi_schema["info"]["x-logo"] = {
"url": "https://example.com/logo.png",
"altText": "企业采购评标系统"
}
# 添加服务器配置
openapi_schema["servers"] = [
{
"url": "http://localhost:8080",
"description": "开发环境"
},
{
"url": "https://api-staging.example.com",
"description": "测试环境"
},
{
"url": "https://api.example.com",
"description": "生产环境"
}
]
# 添加安全认证
openapi_schema["components"]["securitySchemes"] = {
"BearerAuth": {
"type": "http",
"scheme": "bearer",
"bearerFormat": "JWT",
"description": "JWT认证，格式：Bearer <token>"
}
}
# 全局安全认证
openapi_schema["security"] = [{"BearerAuth": []}]
app.openapi_schema = openapi_schema
return app.openapi_schema
app.openapi = custom_openapi
---
c.说明
---
i.性能优化
a.数据库优化
a.说明
连接池配置：
b.代码示例
---
from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession
from sqlalchemy.orm import sessionmaker
from app.core.config import settings
# 创建异步引擎
engine = create_async_engine(
settings.DATABASE_URL,
echo=settings.DEBUG,
pool_size=settings.DB_POOL_SIZE,
max_overflow=settings.DB_MAX_OVERFLOW,
pool_pre_ping=True,
pool_recycle=settings.DB_POOL_RECYCLE,
pool_use_lifo=True, # 使用LIFO减少连接创建
)
# 创建会话工厂
async_session_maker = sessionmaker(
engine,
class_=AsyncSession,
expire_on_commit=False,
autocommit=False,
autoflush=False
)
async def get_db() -> AsyncGenerator[AsyncSession, None]:
"""获取数据库会话（依赖注入）"""
async with async_session_maker() as session:
try:
yield session
finally:
await session.close()
---
b.响应缓存
a.说明
基于Redis的响应缓存：
b.代码示例
---
from fastapi import Request, Response
from app.core.redis import get_redis
import hashlib
import json
def cache_response(ttl: int = 60):
"""响应缓存装饰器"""
def decorator(func):
async def wrapper(*args, **kwargs):
# 获取请求
request: Request = kwargs.get("request")
if not request:
return await func(*args, **kwargs)
# 生成缓存键
cache_key = f"response:{request.url.path}:{hashlib.md5(request.url.query.encode()).hexdigest()}"
# 尝试从缓存获取
redis = get_redis()
if redis:
cached = await redis.get(cache_key)
if cached:
return Response(
content=cached,
media_type="application/json",
headers={"X-Cache": "HIT"}
)
# 执行原始函数
response = await func(*args, **kwargs)
# 缓存响应
if redis and hasattr(response, "body"):
await redis.setex(
cache_key,
ttl,
response.body
)
return response
return wrapper
return decorator
# 使用示例
@app.get("/api/v1/projects")
@cache_response(ttl=300)
async def list_projects_cached():
"""带缓存的项目列表"""
pass
---
c.说明
---
j.总结
a.核心设计总结
a.表格数据
维度 设计方案 核心优势
架构模式 分层架构 + 依赖注入 高内聚低耦合、易测试
异步处理 FastAPI + asyncio 高并发处理
中间件管道 认证→日志→限流→错误处理 请求预处理、响应后处理
路由设计 RESTful规范 + 版本控制 标准化接口、易维护
数据验证 Pydantic模型 类型安全、自动验证
异常处理 统一异常处理器 一致的错误响应
API文档 OpenAPI自动生成 交互式文档、前后端协作
性能优化 连接池 + 响应缓存 降低延迟、提升吞吐
b.关键性能指标
a.表格数据
指标 目标值 优化策略
API响应时间 P50 < 100ms 异步处理、连接池、响应缓存
并发请求 1000 QPS 异步架构、连接池、限流
错误率 < 0.1% 全局异常处理、重试机制
可用性 > 99.9% 健康检查、优雅关闭、熔断降级
b.说明
---
文档版本：v1.0
最后更新：2026-01-18
文档状态：初稿
06.前端架构设计
a.前端架构概览
a.架构定位
a.说明
前端在系统中的位置：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 用户层 │
│ 专家用户 | 评标管理员 | 系统管理员 │
└────────────────┬────────────────────────────────────┘
│ 浏览器访问
┌────────────────▼────────────────────────────────────┐
│ 前端层 │
│ ┌──────────────────────────────────────────────┐ │
│ │ Vue3 + Element Plus │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 视图层 │ │ 组件层 │ │ │
│ │ │ (Views) │ │ (Components)│ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │
│ │ │ 状态管理 │ │ 路由管理 │ │ │
│ │ │ (Pinia) │ │ (Vue Router)│ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │
│ │ │ API通信层 │ │ WebSocket │ │ │
│ │ │ (Axios) │ │ Client │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ┌──────▼────────────────▼──────┐ │ │
│ │ │ 工具函数层 │ │ │
│ │ │ (Utils / Composables) │ │ │
│ │ └────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
└────────────────┬────────────────────────────────────┘
│ HTTP/WebSocket
┌────────────────▼────────────────────────────────────┐
│ 后端API层 │
│ FastAPI + WebSocket Server │
└──────────────────────────────────────────────────────┘
---
b.核心设计原则
a.表格数据
原则 说明 应用场景
组件化 组件复用、单一职责 所有UI组件
响应式 数据驱动视图、自动更新 状态管理、表单绑定
类型安全 TypeScript类型检查 所有代码文件
渐进式 按需加载、代码分割 路由懒加载
可测试 组件隔离、依赖注入 单元测试、E2E测试
可访问性 ARIA标准、键盘导航 所有交互组件
c.技术栈选型
a.表格数据
组件 技术选型 版本要求 核心优势
框架 Vue 3 3.3+ Composition API、响应式系统
语言 TypeScript 5.0+ 类型安全、IDE支持
UI组件库 Element Plus 2.4+ 企业级组件、中文友好
状态管理 Pinia 2.1+ 轻量级、TypeScript支持
路由 Vue Router 4.2+ 嵌套路由、路由守卫
HTTP客户端 Axios 1.6+ 拦截器、Promise支持
WebSocket VueUse + WebSocket - 自动重连、心跳机制
构建工具 Vite 5.0+ 快速热更新、优化构建
CSS预处理 SCSS - 嵌套、变量、混合
代码规范 ESLint + Prettier - 代码质量保证
b.说明
---
b.Vue3项目结构
a.目录结构设计
a.说明
标准项目结构：
b.代码示例
---
frontend/
├── public/ # 静态资源
│ ├── favicon.ico
│ └── logo.png
│
├── src/ # 源代码
│ ├── App.vue # 根组件
│ ├── main.ts # 应用入口
│ │
│ ├── assets/ # 资源文件
│ │ ├── images/ # 图片
│ │ ├── styles/ # 全局样式
│ │ │ ├── variables.scss # SCSS变量
│ │ │ ├── mixins.scss # SCSS混合
│ │ │ ├── global.scss # 全局样式
│ │ │ └── element-plus.scss # Element Plus自定义
│ │ └── icons/ # 图标
│ │
│ ├── components/ # 通用组件
│ │ ├── common/ # 通用基础组件
│ │ │ ├── AppHeader.vue # 应用头部
│ │ │ ├── AppSidebar.vue # 应用侧边栏
│ │ │ ├── AppFooter.vue # 应用底部
│ │ │ └── Breadcrumb.vue # 面包屑导航
│ │ │
│ │ ├── project/ # 项目相关组件
│ │ │ ├── ProjectCard.vue # 项目卡片
│ │ │ ├── ProjectList.vue # 项目列表
│ │ │ └── ProjectForm.vue # 项目表单
│ │ │
│ │ ├── tender/ # 标书相关组件
│ │ │ ├── TenderCard.vue # 标书卡片
│ │ │ ├── TenderUpload.vue # 标书上传
│ │ │ ├── TenderList.vue # 标书列表
│ │ │ └── TenderProgress.vue # 解析进度
│ │ │
│ │ ├── clarification/ # 澄清相关组件
│ │ │ ├── ClarificationPanel.vue # 澄清面板
│ │ │ ├── ClarificationResult.vue # 澄清结果
│ │ │ └── ClarificationHistory.vue # 澄清历史
│ │ │
│ │ ├── score/ # 评分相关组件
│ │ │ ├── ScoreForm.vue # 评分表单
│ │ │ ├── ScoreList.vue # 评分列表
│ │ │ └── ScoreRanking.vue # 评分排名
│ │ │
│ │ └── report/ # 报告相关组件
│ │ ├── ReportPreview.vue # 报告预览
│ │ └── ReportExport.vue # 报告导出
│ │
│ ├── views/ # 页面视图
│ │ ├── auth/ # 认证页面
│ │ │ ├── Login.vue # 登录页
│ │ │ └── Register.vue # 注册页
│ │ │
│ │ ├── layout/ # 布局页面
│ │ │ ├── MainLayout.vue # 主布局
│ │ │ └── EmptyLayout.vue # 空布局
│ │ │
│ │ ├── project/ # 项目管理页面
│ │ │ ├── ProjectList.vue # 项目列表
│ │ │ ├── ProjectDetail.vue # 项目详情
│ │ │ └── ProjectCreate.vue # 创建项目
│ │ │
│ │ ├── tender/ # 标书管理页面
│ │ │ ├── TenderList.vue # 标书列表
│ │ │ ├── TenderUpload.vue # 标书上传
│ │ │ └── TenderDetail.vue # 标书详情
│ │ │
│ │ ├── evaluation/ # 评标页面
│ │ │ ├── Clarification.vue # 澄清页面
│ │ │ ├── Scoring.vue # 评分页面
│ │ │ └── Ranking.vue # 排名页面
│ │ │
│ │ └── report/ # 报告页面
│ │ ├── ReportList.vue # 报告列表
│ │ └── ReportDetail.vue # 报告详情
│ │
│ ├── stores/ # Pinia状态管理
│ │ ├── index.ts # Store入口
│ │ ├── user.ts # 用户状态
│ │ ├── project.ts # 项目状态
│ │ ├── tender.ts # 标书状态
│ │ ├── clarification.ts # 澄清状态
│ │ ├── score.ts # 评分状态
│ │ └── websocket.ts # WebSocket状态
│ │
│ ├── router/ # Vue Router配置
│ │ ├── index.ts # 路由配置
│ │ ├── guards.ts # 路由守卫
│ │ └── routes.ts # 路由定义
│ │
│ ├── api/ # API接口
│ │ ├── index.ts # API入口
│ │ ├── request.ts # Axios封装
│ │ ├── auth.ts # 认证API
│ │ ├── project.ts # 项目API
│ │ ├── tender.ts # 标书API
│ │ ├── clarification.ts # 澄清API
│ │ ├── score.ts # 评分API
│ │ └── report.ts # 报告API
│ │
│ ├── composables/ # 组合式函数
│ │ ├── useAuth.ts # 认证逻辑
│ │ ├── usePagination.ts # 分页逻辑
│ │ ├── useTable.ts # 表格逻辑
│ │ ├── useForm.ts # 表单逻辑
│ │ ├── useWebSocket.ts # WebSocket逻辑
│ │ ├── useUpload.ts # 上传逻辑
│ │ └── useDebounce.ts # 防抖逻辑
│ │
│ ├── utils/ # 工具函数
│ │ ├── date.ts # 日期工具
│ │ ├── file.ts # 文件工具
│ │ ├── format.ts # 格式化工具
│ │ ├── validator.ts # 验证器
│ │ ├── storage.ts # 本地存储
│ │ └── constants.ts # 常量定义
│ │
│ ├── types/ # TypeScript类型
│ │ ├── index.ts # 类型导出
│ │ ├── user.ts # 用户类型
│ │ ├── project.ts # 项目类型
│ │ ├── tender.ts # 标书类型
│ │ ├── clarification.ts # 澄清类型
│ │ └── score.ts # 评分类型
│ │
│ ├── directives/ # 自定义指令
│ │ ├── permission.ts # 权限指令
│ │ └── loading.ts # 加载指令
│ │
│ └── plugins/ # 插件
│ ├── element-plus.ts # Element Plus
│ └── icons.ts # 图标插件
│
├── tests/ # 测试
│ ├── unit/ # 单元测试
│ └── e2e/ # E2E测试
│
├── .env.development # 开发环境变量
├── .env.production # 生产环境变量
├── .eslintrc.cjs # ESLint配置
├── .prettierrc.json # Prettier配置
├── tsconfig.json # TypeScript配置
├── tsconfig.node.json # TypeScript Node配置
├── vite.config.ts # Vite配置
├── package.json # 项目依赖
└── README.md # 项目说明
---
b.应用入口配置
a.说明
main.ts应用入口：
b.代码示例
---
import { createApp } from 'vue'
import { createPinia } from 'pinia'
import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'
import * as ElementPlusIconsVue from '@element-plus/icons-vue'
import App from './App.vue'
import router from './router'
import './assets/styles/global.scss'
// 创建应用实例
const app = createApp(App)
// 创建Pinia实例
const pinia = createPinia()
// 注册插件
app.use(pinia)
app.use(router)
app.use(ElementPlus, {
// Element Plus全局配置
size: 'default',
zIndex: 3000
})
// 注册所有图标
for (const [key, component] of Object.entries(ElementPlusIconsVue)) {
app.component(key, component)
}
// 全局错误处理
app.config.errorHandler = (err, instance, info) => {
console.error('全局错误:', err)
console.error('错误信息:', info)
// TODO: 发送错误到监控服务
}
// 挂载应用
app.mount('#app')
---
c.说明
App.vue根组件：
d.代码示例
---
<template>
<router-view />
</template>
<script setup lang="ts">
import { onMounted } from 'vue'
import { useUserStore } from '@/stores/user'
const userStore = useUserStore()
onMounted(async () => {
// 应用初始化
await userStore.initUser()
})
</script>
<style lang="scss">
// 全局样式
@import '@/assets/styles/global.scss';
</style>
---
c.Vite配置
a.说明
vite.config.ts构建配置：
b.代码示例
---
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { resolve } from 'path'
import AutoImport from 'unplugin-auto-import/vite'
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
export default defineConfig({
plugins: [
vue(),
AutoImport({
// 自动导入Vue相关函数
imports: [
'vue',
'vue-router',
'pinia',
'@vueuse/core'
],
// 自动导入Element Plus组件
resolvers: [ElementPlusResolver()],
dts: 'src/auto-imports.d.ts'
}),
Components({
// 自动导入组件
resolvers: [ElementPlusResolver()],
dts: 'src/components.d.ts'
})
],
resolve: {
// 路径别名
alias: {
'@': resolve(__dirname, 'src')
}
},
server: {
port: 5173,
proxy: {
// API代理
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
},
// WebSocket代理
'/ws': {
target: 'ws://localhost:8080',
ws: true
}
}
},
build: {
// 代码分割
rollupOptions: {
output: {
manualChunks: {
'vue-vendor': ['vue', 'vue-router', 'pinia'],
'element-plus': ['element-plus'],
'icons': ['@element-plus/icons-vue']
}
}
},
// 压缩
minify: 'terser',
terserOptions: {
compress: {
drop_console: true,
drop_debugger: true
}
}
}
})
---
c.说明
---
c.组件库设计
a.通用基础组件
a.说明
AppHeader.vue应用头部：
b.代码示例
---
<template>
<header class="app-header">
<div class="header-left">
<h1 class="app-title">企业采购评标系统</h1>
</div>
<div class="header-center">
<el-menu
:default-active="activeMenu"
mode="horizontal"
:ellipsis="false"
@select="handleMenuSelect"
>
<el-menu-item index="/projects">项目管理</el-menu-item>
<el-menu-item index="/tenders">标书管理</el-menu-item>
<el-menu-item index="/evaluation">评标中心</el-menu-item>
<el-menu-item index="/reports">报告中心</el-menu-item>
<el-menu-item index="/configs">系统配置</el-menu-item>
</el-menu>
</div>
<div class="header-right">
<!-- 通知图标 -->
<el-badge :value="notificationCount" :hidden="notificationCount === 0">
<el-button :icon="Bell" circle />
</el-badge>
<!-- 用户下拉菜单 -->
<el-dropdown @command="handleCommand">
<div class="user-info">
<el-avatar :size="32" :src="user?.avatar">
{{ user?.username?.charAt(0) }}
</el-avatar>
<span class="username">{{ user?.username }}</span>
<el-icon><ArrowDown /></el-icon>
</div>
<template #dropdown>
<el-dropdown-menu>
<el-dropdown-item command="profile">
<el-icon><User /></el-icon>
个人信息
</el-dropdown-item>
<el-dropdown-item command="settings">
<el-icon><Setting /></el-icon>
系统设置
</el-dropdown-item>
<el-dropdown-item divided command="logout">
<el-icon><SwitchButton /></el-icon>
退出登录
</el-dropdown-item>
</el-dropdown-menu>
</template>
</el-dropdown>
</div>
</header>
</template>
<script setup lang="ts">
import { ref, computed } from 'vue'
import { useRouter, useRoute } from 'vue-router'
import {
Bell,
ArrowDown,
User,
Setting,
SwitchButton
} from '@element-plus/icons-vue'
import { ElMessage } from 'element-plus'
import { useUserStore } from '@/stores/user'
const router = useRouter()
const route = useRoute()
const userStore = useUserStore()
// 用户信息
const user = computed(() => userStore.user)
// 通知数量
const notificationCount = ref(0)
// 当前激活菜单
const activeMenu = computed(() => route.path)
// 菜单选择
const handleMenuSelect = (index: string) => {
router.push(index)
}
// 下拉菜单命令
const handleCommand = async (command: string) => {
switch (command) {
case 'profile':
router.push('/profile')
break
case 'settings':
router.push('/settings')
break
case 'logout':
await userStore.logout()
ElMessage.success('退出登录成功')
router.push('/login')
break
}
}
</script>
<style lang="scss" scoped>
.app-header {
display: flex;
align-items: center;
height: 60px;
padding: 0 24px;
background: #fff;
border-bottom: 1px solid #e8e8e8;
.header-left {
flex-shrink: 0;
width: 200px;
.app-title {
font-size: 20px;
font-weight: 600;
color: #303133;
margin: 0;
}
}
.header-center {
flex: 1;
display: flex;
justify-content: center;
}
.header-right {
flex-shrink: 0;
display: flex;
align-items: center;
gap: 16px;
.user-info {
display: flex;
align-items: center;
gap: 8px;
cursor: pointer;
padding: 8px 12px;
border-radius: 4px;
transition: background-color 0.3s;
&:hover {
background-color: #f5f7fa;
}
.username {
font-size: 14px;
color: #606266;
}
}
}
}
</style>
---
b.业务组件设计
a.说明
TenderProgress.vue标书解析进度：
b.代码示例
---
<template>
<el-card class="tender-progress-card">
<template #header>
<div class="card-header">
<span>{{ tender.tenderName }}</span>
<el-tag :type="getStatusType(tender.status)">
{{ getStatusText(tender.status) }}
</el-tag>
</div>
</template>
<!-- 进度条 -->
<el-progress
:percentage="progress"
:status="progressStatus"
:stroke-width="8"
/>
<!-- 详细信息 -->
<div class="progress-info">
<el-descriptions :column="3" border>
<el-descriptions-item label="供应商">
{{ tender.supplierName }}
</el-descriptions-item>
<el-descriptions-item label="文件大小">
{{ formatFileSize(tender.fileSize) }}
</el-descriptions-item>
<el-descriptions-item label="页数">
{{ tender.pageCount }}页
</el-descriptions-item>
<el-descriptions-item label="开始时间">
{{ formatTime(tender.uploadTimestamp) }}
</el-descriptions-item>
<el-descriptions-item label="当前阶段">
{{ getCurrentStage() }}
</el-descriptions-item>
<el-descriptions-item label="剩余时间">
{{ estimatedTime }}
</el-descriptions-item>
</el-descriptions>
</div>
<!-- 操作按钮 -->
<div class="progress-actions">
<el-button
v-if="tender.status === 'failed'"
type="primary"
@click="handleRetry"
>
重试
</el-button>
<el-button
v-if="tender.status === 'completed'"
type="success"
@click="handleViewDetail"
>
查看详情
</el-button>
</div>
</el-card>
</template>
<script setup lang="ts">
import { ref, computed, watch } from 'vue'
import { ElMessage } from 'element-plus'
import { useWebSocketStore } from '@/stores/websocket'
import type { Tender } from '@/types/tender'
import { formatFileSize, formatTime } from '@/utils/format'
interface Props {
tender: Tender
}
const props = defineProps<Props>()
const emit = defineEmits<{
retry: [tenderId: number]
viewDetail: [tenderId: number]
}>()
const wsStore = useWebSocketStore()
// 进度
const progress = ref(0)
// 进度状态
const progressStatus = computed<'success' | 'exception' | 'warning' | undefined>(() => {
if (props.tender.status === 'completed') return 'success'
if (props.tender.status === 'failed') return 'exception'
return undefined
})
// 估算剩余时间
const estimatedTime = computed(() => {
if (progress.value >= 100) return '已完成'
const remaining = 100 - progress.value
const seconds = Math.ceil(remaining * 3) // 假设每1%需要3秒
return `约${Math.floor(seconds / 60)}分${seconds % 60}秒`
})
// 获取状态类型
const getStatusType = (status: string) => {
const types: Record<string, any> = {
uploading: 'info',
parsing: 'warning',
completed: 'success',
failed: 'danger'
}
return types[status] || 'info'
}
// 获取状态文本
const getStatusText = (status: string) => {
const texts: Record<string, string> = {
uploading: '上传中',
parsing: '解析中',
completed: '已完成',
failed: '失败'
}
return texts[status] || '未知'
}
// 获取当前阶段
const getCurrentStage = () => {
if (progress.value < 20) return '文件上传'
if (progress.value < 50) return 'OCR识别'
if (progress.value < 80) return '多模态理解'
return '建立索引'
}
// 监听WebSocket进度更新
watch(
() => wsStore.progressUpdates[props.tender.id],
(newProgress) => {
if (newProgress !== undefined) {
progress.value = newProgress
}
},
{ immediate: true }
)
// 重试
const handleRetry = () => {
emit('retry', props.tender.id)
}
// 查看详情
const handleViewDetail = () => {
emit('viewDetail', props.tender.id)
}
</script>
<style lang="scss" scoped>
.tender-progress-card {
margin-bottom: 16px;
.card-header {
display: flex;
justify-content: space-between;
align-items: center;
}
.progress-info {
margin-top: 24px;
}
.progress-actions {
margin-top: 16px;
text-align: right;
}
}
</style>
---
c.组件通信模式
a.说明
父子组件通信：
b.代码示例
---
<!-- 父组件 ProjectList.vue -->
<template>
<div class="project-list">
<ProjectCard
v-for="project in projects"
:key="project.id"
:project="project"
@edit="handleEdit"
@delete="handleDelete"
/>
</div>
</template>
<script setup lang="ts">
import ProjectCard from '@/components/project/ProjectCard.vue'
import type { Project } from '@/types/project'
const projects = ref<Project[]>([])
const handleEdit = (project: Project) => {
console.log('编辑项目:', project)
}
const handleDelete = (projectId: number) => {
console.log('删除项目:', projectId)
}
</script>
<!-- 子组件 ProjectCard.vue -->
<template>
<el-card class="project-card" @click="handleClick">
<!-- 卡片内容 -->
</el-card>
</template>
<script setup lang="ts">
interface Props {
project: Project
}
interface Emits {
(e: 'edit', project: Project): void
(e: 'delete', projectId: number): void
}
const props = defineProps<Props>()
const emit = defineEmits<Emits>()
const handleClick = () => {
// 点击卡片
emit('edit', props.project)
}
</script>
---
c.说明
Provide/Inject跨层级通信：
d.代码示例
---
// 祖先组件提供数据
import { provide } from 'vue'
provide('projectData', {
projectId: ref(1),
projectName: ref('示例项目')
})
// 后代组件注入数据
import { inject } from 'vue'
const projectData = inject('projectData')
console.log(projectData.projectId.value) // 1
---
e.说明
---
d.状态管理（Pinia）
a.Store定义模式
a.说明
用户状态管理：
b.代码示例
---
// stores/user.ts
import { defineStore } from 'pinia'
import { ref, computed } from 'vue'
import type { User } from '@/types/user'
import { authApi } from '@/api/auth'
import { ElMessage } from 'element-plus'
export const useUserStore = defineStore('user', () => {
// 状态
const user = ref<User | null>(null)
const token = ref<string>('')
const isLoading = ref(false)
// 计算属性
const isLoggedIn = computed(() => !!token.value)
const username = computed(() => user.value?.username || '')
const role = computed(() => user.value?.role || '')
// 初始化用户
async function initUser() {
const savedToken = localStorage.getItem('token')
if (savedToken) {
token.value = savedToken
await fetchUserInfo()
}
}
// 登录
async function login(username: string, password: string) {
isLoading.value = true
try {
const response = await authApi.login({ username, password })
token.value = response.token
user.value = response.user
localStorage.setItem('token', response.token)
ElMessage.success('登录成功')
return true
} catch (error) {
ElMessage.error('登录失败')
return false
} finally {
isLoading.value = false
}
}
// 登出
async function logout() {
token.value = ''
user.value = null
localStorage.removeItem('token')
}
// 获取用户信息
async function fetchUserInfo() {
try {
const userInfo = await authApi.getUserInfo()
user.value = userInfo
} catch (error) {
await logout()
}
}
// 更新用户信息
function updateUser(userData: Partial<User>) {
if (user.value) {
user.value = { ...user.value, ...userData }
}
}
return {
// 状态
user,
token,
isLoading,
// 计算属性
isLoggedIn,
username,
role,
// 方法
initUser,
login,
logout,
fetchUserInfo,
updateUser
}
})
---
b.项目状态管理
a.说明
项目状态管理：
b.代码示例
---
// stores/project.ts
import { defineStore } from 'pinia'
import { ref, computed } from 'vue'
import type { Project, ProjectFilters } from '@/types/project'
import { projectApi } from '@/api/project'
export const useProjectStore = defineStore('project', () => {
// 状态
const projects = ref<Project[]>([])
const currentProject = ref<Project | null>(null)
const filters = ref<ProjectFilters>({
status: undefined,
search: '',
page: 1,
pageSize: 20,
sortBy: 'created_at',
sortOrder: 'desc'
})
const total = ref(0)
const isLoading = ref(false)
// 计算属性
const hasProjects = computed(() => projects.value.length > 0)
const totalPages = computed(() => Math.ceil(total.value / filters.value.pageSize))
// 获取项目列表
async function fetchProjects() {
isLoading.value = true
try {
const response = await projectApi.listProjects(filters.value)
projects.value = response.items
total.value = response.total
} catch (error) {
ElMessage.error('获取项目列表失败')
} finally {
isLoading.value = false
}
}
// 获取项目详情
async function fetchProjectDetail(projectId: number) {
isLoading.value = true
try {
const project = await projectApi.getProject(projectId)
currentProject.value = project
return project
} catch (error) {
ElMessage.error('获取项目详情失败')
return null
} finally {
isLoading.value = false
}
}
// 创建项目
async function createProject(projectData: Partial<Project>) {
try {
const project = await projectApi.createProject(projectData)
projects.value.unshift(project)
total.value += 1
ElMessage.success('项目创建成功')
return project
} catch (error) {
ElMessage.error('项目创建失败')
return null
}
}
// 更新项目
async function updateProject(projectId: number, projectData: Partial<Project>) {
try {
const updatedProject = await projectApi.updateProject(projectId, projectData)
const index = projects.value.findIndex(p => p.id === projectId)
if (index !== -1) {
projects.value[index] = updatedProject
}
if (currentProject.value?.id === projectId) {
currentProject.value = updatedProject
}
ElMessage.success('项目更新成功')
return updatedProject
} catch (error) {
ElMessage.error('项目更新失败')
return null
}
}
// 删除项目
async function deleteProject(projectId: number) {
try {
await projectApi.deleteProject(projectId)
projects.value = projects.value.filter(p => p.id !== projectId)
total.value -= 1
if (currentProject.value?.id === projectId) {
currentProject.value = null
}
ElMessage.success('项目删除成功')
return true
} catch (error) {
ElMessage.error('项目删除失败')
return false
}
}
// 更新过滤条件
function updateFilters(newFilters: Partial<ProjectFilters>) {
filters.value = { ...filters.value, ...newFilters }
}
// 重置过滤条件
function resetFilters() {
filters.value = {
status: undefined,
search: '',
page: 1,
pageSize: 20,
sortBy: 'created_at',
sortOrder: 'desc'
}
}
return {
// 状态
projects,
currentProject,
filters,
total,
isLoading,
// 计算属性
hasProjects,
totalPages,
// 方法
fetchProjects,
fetchProjectDetail,
createProject,
updateProject,
deleteProject,
updateFilters,
resetFilters
}
})
---
c.WebSocket状态管理
a.说明
WebSocket连接状态：
b.代码示例
---
// stores/websocket.ts
import { defineStore } from 'pinia'
import { ref, computed } from 'vue'
import { useWebSocket } from '@vueuse/core'
export const useWebSocketStore = defineStore('websocket', () => {
// WebSocket连接状态
const isConnected = ref(false)
const connectionAttempts = ref(0)
// 进度更新缓存
const progressUpdates = ref<Record<number, number>>({})
// 消息队列
const messageQueue = ref<any[]>([])
// 创建WebSocket连接
const { status, data, send, open, close } = useWebSocket(
`${import.meta.env.VITE_WS_URL}/ws/project/:projectId`,
{
autoReconnect: {
retries: 5,
delay: 1000,
onFailed() {
ElMessage.warning('WebSocket连接失败，正在重连...')
}
},
heartbeat: {
message: JSON.stringify({ type: 'ping' }),
interval: 30000
}
}
)
// 连接状态
const connectionStatus = computed(() => {
switch (status.value) {
case 'CONNECTING':
return 'CONNECTING'
case 'OPEN':
return 'CONNECTED'
case 'CLOSING':
return 'CLOSING'
case 'CLOSED':
return 'CLOSED'
default:
return 'UNKNOWN'
}
})
// 监听消息
watch(data, (newData) => {
if (!newData) return
try {
const message = JSON.parse(newData)
// 处理进度更新消息
if (message.type === 'progress_update') {
const { tenderId, progress } = message.data
progressUpdates.value[tenderId] = progress
}
// 添加到消息队列
messageQueue.value.push(message)
} catch (error) {
console.error('解析WebSocket消息失败:', error)
}
})
// 连接项目频道
function connectProject(projectId: number) {
const wsUrl = `${import.meta.env.VITE_WS_URL}/ws/project/${projectId}`
// TODO: 实现连接逻辑
}
// 断开连接
function disconnect() {
close()
}
// 发送消息
function sendMessage(message: any) {
send(JSON.stringify(message))
}
// 获取进度更新
function getProgress(tenderId: number) {
return progressUpdates.value[tenderId] || 0
}
// 清除进度更新
function clearProgress(tenderId: number) {
delete progressUpdates.value[tenderId]
}
return {
// 状态
isConnected,
connectionStatus,
connectionAttempts,
progressUpdates,
messageQueue,
// 方法
connectProject,
disconnect,
sendMessage,
getProgress,
clearProgress
}
})
---
c.说明
---
e.路由设计
a.路由配置
a.说明
router/index.ts路由配置：
b.代码示例
---
import { createRouter, createWebHistory } from 'vue-router'
import type { RouteRecordRaw } from 'vue-router'
import { useUserStore } from '@/stores/user'
// 布局组件
const MainLayout = () => import('@/views/layout/MainLayout.vue')
const EmptyLayout = () => import('@/views/layout/EmptyLayout.vue')
// 路由定义
const routes: RouteRecordRaw[] = [
{
path: '/login',
component: () => import('@/views/auth/Login.vue'),
meta: {
title: '登录',
requiresAuth: false
}
},
{
path: '/',
component: MainLayout,
redirect: '/projects',
meta: { requiresAuth: true },
children: [
{
path: 'projects',
name: 'ProjectList',
component: () => import('@/views/project/ProjectList.vue'),
meta: {
title: '项目管理',
icon: 'Folder'
}
},
{
path: 'projects/create',
name: 'ProjectCreate',
component: () => import('@/views/project/ProjectCreate.vue'),
meta: {
title: '创建项目',
hidden: true
}
},
{
path: 'projects/:id',
name: 'ProjectDetail',
component: () => import('@/views/project/ProjectDetail.vue'),
meta: {
title: '项目详情',
hidden: true
}
},
{
path: 'tenders',
name: 'TenderList',
component: () => import('@/views/tender/TenderList.vue'),
meta: {
title: '标书管理',
icon: 'Document'
}
},
{
path: 'evaluation',
name: 'Evaluation',
redirect: '/evaluation/clarification',
meta: {
title: '评标中心',
icon: 'Edit'
},
children: [
{
path: 'clarification',
name: 'Clarification',
component: () => import('@/views/evaluation/Clarification.vue'),
meta: { title: 'AI澄清' }
},
{
path: 'scoring',
name: 'Scoring',
component: () => import('@/views/evaluation/Scoring.vue'),
meta: { title: '评分' }
},
{
path: 'ranking',
name: 'Ranking',
component: () => import('@/views/evaluation/Ranking.vue'),
meta: { title: '排名' }
}
]
},
{
path: 'reports',
name: 'ReportList',
component: () => import('@/views/report/ReportList.vue'),
meta: {
title: '报告中心',
icon: 'Files'
}
},
{
path: 'configs',
name: 'Configs',
component: () => import('@/views/config/ConfigList.vue'),
meta: {
title: '系统配置',
icon: 'Setting',
roles: ['admin', 'super_admin']
}
}
]
},
{
path: '/404',
component: () => import('@/views/error/404.vue'),
meta: { title: '页面不存在', requiresAuth: false }
},
{
path: '/:pathMatch(.*)*',
redirect: '/404'
}
]
// 创建路由实例
const router = createRouter({
history: createWebHistory(import.meta.env.BASE_URL),
routes,
scrollBehavior(to, from, savedPosition) {
if (savedPosition) {
return savedPosition
} else {
return { top: 0 }
}
}
})
// 全局前置守卫
router.beforeEach((to, from, next) => {
// 设置页面标题
document.title = to.meta.title
? `${to.meta.title} - 企业采购评标系统`
: '企业采购评标系统'
// 检查认证
const userStore = useUserStore()
if (to.meta.requiresAuth !== false && !userStore.isLoggedIn) {
// 需要认证但未登录，跳转到登录页
next({
path: '/login',
query: { redirect: to.fullPath }
})
} else if (to.path === '/login' && userStore.isLoggedIn) {
// 已登录用户访问登录页，跳转到首页
next({ path: '/' })
} else {
// 检查角色权限
const requiredRoles = to.meta.roles as string[] | undefined
if (requiredRoles && !requiredRoles.includes(userStore.role)) {
next({ path: '/403' })
} else {
next()
}
}
})
// 全局后置钩子
router.afterEach((to, from) => {
// 页面访问统计
console.log(`导航: ${from.path} -> ${to.path}`)
})
export default router
---
b.路由懒加载
a.说明
路由懒加载配置：
b.代码示例
---
// 方式1：使用动态导入（推荐）
const ProjectList = () => import('@/views/project/ProjectList.vue')
// 方式2：使用webpack魔法注释（指定chunk名称）
const ProjectDetail = () => import(
/* webpackChunkName: "project-detail" */
'@/views/project/ProjectDetail.vue'
)
// 方式3：使用vite的注释（指定chunk名称）
const TenderList = () => import(
/* @vite-ignore */
'@/views/tender/TenderList.vue'
)
---
c.说明
---
f.API通信层
a.Axios封装
a.说明
api/request.ts请求封装：
b.代码示例
---
import axios, { AxiosInstance, AxiosRequestConfig, AxiosResponse } from 'axios'
import { ElMessage, ElMessageBox } from 'element-plus'
import { useUserStore } from '@/stores/user'
// 创建axios实例
const service: AxiosInstance = axios.create({
baseURL: import.meta.env.VITE_API_BASE_URL || '/api',
timeout: 30000,
headers: {
'Content-Type': 'application/json'
}
})
// 请求拦截器
service.interceptors.request.use(
(config) => {
// 添加Token
const userStore = useUserStore()
if (userStore.token) {
config.headers.Authorization = `Bearer ${userStore.token}`
}
// 添加时间戳防止缓存
if (config.method === 'get') {
config.params = {
...config.params,
_t: Date.now()
}
}
return config
},
(error) => {
console.error('请求错误:', error)
return Promise.reject(error)
}
)
// 响应拦截器
service.interceptors.response.use(
(response: AxiosResponse) => {
const res = response.data
// 如果返回的状态码不是200，判断为错误
if (res.code !== 200) {
ElMessage.error(res.message || '请求失败')
// 401: Token过期
if (res.code === 401) {
ElMessageBox.confirm(
'登录状态已过期，请重新登录',
'系统提示',
{
confirmButtonText: '重新登录',
cancelButtonText: '取消',
type: 'warning'
}
).then(() => {
const userStore = useUserStore()
userStore.logout()
location.href = '/login'
})
}
return Promise.reject(new Error(res.message || 'Error'))
}
return res
},
(error) => {
console.error('响应错误:', error)
if (error.response) {
const { status, data } = error.response
switch (status) {
case 400:
ElMessage.error(data.message || '请求参数错误')
break
case 401:
ElMessage.error('未授权，请登录')
break
case 403:
ElMessage.error('拒绝访问')
break
case 404:
ElMessage.error('请求的资源不存在')
break
case 500:
ElMessage.error('服务器内部错误')
break
default:
ElMessage.error(data.message || `请求失败 (${status})`)
}
} else if (error.request) {
ElMessage.error('网络错误，请检查网络连接')
} else {
ElMessage.error('请求配置错误')
}
return Promise.reject(error)
}
)
// 通用请求方法
export function request<T = any>(config: AxiosRequestConfig): Promise<T> {
return service(config)
}
export function get<T = any>(
url: string,
params?: any,
config?: AxiosRequestConfig
): Promise<T> {
return request<T>({ method: 'GET', url, params, ...config })
}
export function post<T = any>(
url: string,
data?: any,
config?: AxiosRequestConfig
): Promise<T> {
return request<T>({ method: 'POST', url, data, ...config })
}
export function put<T = any>(
url: string,
data?: any,
config?: AxiosRequestConfig
): Promise<T> {
return request<T>({ method: 'PUT', url, data, ...config })
}
export function del<T = any>(
url: string,
config?: AxiosRequestConfig
): Promise<T> {
return request<T>({ method: 'DELETE', url, ...config })
}
export default service
---
b.API模块封装
a.说明
api/project.ts项目API：
b.代码示例
---
import { get, post, put, del } from './request'
import type {
Project,
ProjectCreate,
ProjectUpdate,
ProjectListResponse,
ProjectFilters
} from '@/types/project'
export const projectApi = {
// 获取项目列表
listProjects(filters: ProjectFilters): Promise<ProjectListResponse> {
return get<ProjectListResponse>('/projects', filters)
},
// 获取项目详情
getProject(projectId: number): Promise<Project> {
return get<Project>(`/projects/${projectId}`)
},
// 创建项目
createProject(data: ProjectCreate): Promise<Project> {
return post<Project>('/projects', data)
},
// 更新项目
updateProject(projectId: number, data: ProjectUpdate): Promise<Project> {
return put<Project>(`/projects/${projectId}`, data)
},
// 删除项目
deleteProject(projectId: number): Promise<void> {
return del<void>(`/projects/${projectId}`)
},
// 获取项目统计
getProjectStats(projectId: number): Promise<any> {
return get<any>(`/projects/${projectId}/stats`)
}
}
---
c.说明
api/clarification.ts澄清API：
d.代码示例
---
import { post, get } from './request'
import type {
ClarificationRequest,
ClarificationResponse,
ClarificationHistoryResponse
} from '@/types/clarification'
export const clarificationApi = {
// 提交澄清提问
submitClarification(request: ClarificationRequest): Promise<ClarificationResponse> {
return post<ClarificationResponse>('/clarifications', request)
},
// 获取澄清历史
getHistory(projectId: number, limit: number = 10): Promise<ClarificationHistoryResponse[]> {
return get<ClarificationHistoryResponse[]>('/clarifications/history', {
projectId,
limit
})
},
// 专家复核澄清结果
reviewClarification(
clarificationId: number,
action: 'accept' | 'reject' | 'modify' | 'ignore',
notes?: string
): Promise<void> {
return post<void>(`/clarifications/${clarificationId}/review`, null, {
params: { action, notes }
})
}
}
---
e.说明
---
g.WebSocket通信
a.WebSocket客户端封装
a.说明
composables/useWebSocket.ts：
b.代码示例
---
import { ref, onUnmounted } from 'vue'
import { useWebSocket } from '@vueuse/core'
import { ElMessage } from 'element-plus'
export function useWebSocket(url: string, token: string) {
const isConnected = ref(false)
const messageHandlers = new Map<string, Function[]>()
// 构建WebSocket URL
const wsUrl = `${url}?token=${token}`
// 创建WebSocket连接
const { status, data, send, open, close } = useWebSocket(wsUrl, {
autoReconnect: {
retries: 5,
delay: 1000,
onFailed() {
ElMessage.warning('WebSocket连接失败，正在重连...')
}
},
heartbeat: {
message: JSON.stringify({ type: 'ping' }),
interval: 30000
}
})
// 监听连接状态
const unwatchStatus = watch(
() => status.value,
(newStatus) => {
isConnected.value = newStatus === 'OPEN'
if (newStatus === 'OPEN') {
ElMessage.success('WebSocket连接成功')
}
}
)
// 监听消息
const unwatchData = watch(data, (newData) => {
if (!newData) return
try {
const message = JSON.parse(newData)
const { type, payload } = message
// 调用注册的消息处理器
const handlers = messageHandlers.get(type)
if (handlers) {
handlers.forEach(handler => handler(payload))
}
} catch (error) {
console.error('解析WebSocket消息失败:', error)
}
})
// 注册消息处理器
function on(type: string, handler: Function) {
if (!messageHandlers.has(type)) {
messageHandlers.set(type, [])
}
messageHandlers.get(type)!.push(handler)
}
// 注销消息处理器
function off(type: string, handler: Function) {
const handlers = messageHandlers.get(type)
if (handlers) {
const index = handlers.indexOf(handler)
if (index !== -1) {
handlers.splice(index, 1)
}
}
}
// 发送消息
function sendMessage(type: string, payload: any) {
send(JSON.stringify({ type, payload }))
}
// 清理
onUnmounted(() => {
unwatchStatus()
unwatchData()
messageHandlers.clear()
})
return {
isConnected,
status,
send,
open,
close,
sendMessage,
on,
off
}
}
---
b.WebSocket使用示例
a.说明
在组件中使用WebSocket：
b.代码示例
---
<template>
<div class="tender-uploads">
<TenderProgress
v-for="tender in tenders"
:key="tender.id"
:tender="tender"
/>
</div>
</template>
<script setup lang="ts">
import { ref, onMounted } from 'vue'
import { useWebSocket } from '@/composables/useWebSocket'
import { useUserStore } from '@/stores/user'
const userStore = useUserStore()
const tenders = ref([])
onMounted(() => {
// 连接WebSocket
const ws = useWebSocket(
import.meta.env.VITE_WS_URL,
userStore.token
)
// 监听进度更新
ws.on('progress_update', (payload) => {
const { tenderId, progress } = payload
const tender = tenders.value.find(t => t.id === tenderId)
if (tender) {
tender.progress = progress
}
})
// 监听解析完成
ws.on('parse_completed', (payload) => {
const { tenderId } = payload
const tender = tenders.value.find(t => t.id === tenderId)
if (tender) {
tender.status = 'completed'
tender.progress = 100
}
ElMessage.success('标书解析完成')
})
// 监听解析失败
ws.on('parse_failed', (payload) => {
const { tenderId, error } = payload
const tender = tenders.value.find(t => t.id === tenderId)
if (tender) {
tender.status = 'failed'
tender.error = error
}
ElMessage.error('标书解析失败')
})
})
</script>
---
c.说明
---
h.实时进度展示
a.进度组件设计
a.说明
ProgressDashboard.vue进度仪表板：
b.代码示例
---
<template>
<div class="progress-dashboard">
<!-- 整体进度 -->
<el-card class="overall-progress">
<template #header>
<div class="card-header">
<span>标书解析进度</span>
<el-tag :type="overallStatus">
{{ overallStatusText }}
</el-tag>
</div>
</template>
<el-progress
:percentage="overallProgress"
:status="overallProgressStatus"
:stroke-width="12"
/>
<div class="progress-stats">
<el-statistic title="已完成" :value="completedCount" />
<el-statistic title="进行中" :value="processingCount" />
<el-statistic title="失败" :value="failedCount" />
<el-statistic title="总计" :value="totalCount" />
</div>
</el-card>
<!-- 详细进度列表 -->
<el-card class="progress-list">
<template #header>
<div class="card-header">
<span>详细进度</span>
<el-button
:icon="Refresh"
circle
:loading="isLoading"
@click="refreshProgress"
/>
</div>
</template>
<el-timeline>
<el-timeline-item
v-for="tender in tenders"
:key="tender.id"
:timestamp="formatTime(tender.uploadTimestamp)"
:type="getTimelineType(tender.status)"
placement="top"
>
<TenderProgressItem
:tender="tender"
@retry="handleRetry"
@view-detail="handleViewDetail"
/>
</el-timeline-item>
</el-timeline>
</el-card>
</div>
</template>
<script setup lang="ts">
import { ref, computed, watch } from 'vue'
import { Refresh } from '@element-plus/icons-vue'
import { ElMessage } from 'element-plus'
import { useWebSocketStore } from '@/stores/websocket'
import type { Tender } from '@/types/tender'
import { formatTime } from '@/utils/format'
interface Props {
projectId: number
}
const props = defineProps<Props>()
const wsStore = useWebSocketStore()
const tenders = ref<Tender[]>([])
const isLoading = ref(false)
// 连接项目WebSocket频道
wsStore.connectProject(props.projectId)
// 整体进度
const overallProgress = computed(() => {
if (tenders.value.length === 0) return 0
const totalProgress = tenders.value.reduce((sum, t) => {
return sum + (t.progress || 0)
}, 0)
return Math.round(totalProgress / tenders.value.length)
})
// 整体状态
const overallStatus = computed<'success' | 'exception' | 'warning'>(() => {
if (failedCount.value > 0) return 'exception'
if (processingCount.value > 0) return 'warning'
return 'success'
})
const overallStatusText = computed(() => {
if (failedCount.value > 0) return '有失败'
if (processingCount.value > 0) return '进行中'
return '已完成'
})
// 统计数据
const completedCount = computed(() =>
tenders.value.filter(t => t.status === 'completed').length
)
const processingCount = computed(() =>
tenders.value.filter(t => t.status === 'parsing').length
)
const failedCount = computed(() =>
tenders.value.filter(t => t.status === 'failed').length
)
const totalCount = computed(() => tenders.value.length)
// 监听WebSocket进度更新
watch(
() => wsStore.progressUpdates,
(updates) => {
tenders.value.forEach(tender => {
const progress = updates[tender.id]
if (progress !== undefined) {
tender.progress = progress
}
})
},
{ deep: true }
)
// 获取时间线类型
const getTimelineType = (status: string) => {
const types: Record<string, any> = {
completed: 'success',
parsing: 'primary',
failed: 'danger'
}
return types[status] || 'info'
}
// 刷新进度
const refreshProgress = async () => {
isLoading.value = true
try {
// TODO: 从API获取最新进度
} finally {
isLoading.value = false
}
}
// 重试
const handleRetry = (tenderId: number) => {
// TODO: 实现重试逻辑
}
// 查看详情
const handleViewDetail = (tenderId: number) => {
// TODO: 跳转到详情页
}
</script>
<style lang="scss" scoped>
.progress-dashboard {
.overall-progress {
margin-bottom: 24px;
.progress-stats {
display: flex;
justify-content: space-around;
margin-top: 24px;
}
}
.card-header {
display: flex;
justify-content: space-between;
align-items: center;
}
}
</style>
---
b.实时数据同步
a.说明
实时数据同步策略：
b.代码示例
---
// composables/useRealtimeData.ts
import { ref, watchEffect, onUnmounted } from 'vue'
import { useWebSocket } from './useWebSocket'
export function useRealtimeData<T>(
projectId: number,
dataType: string,
initialData: T[]
) {
const data = ref<T[]>(initialData)
const isLoading = ref(false)
// 连接WebSocket
const ws = useWebSocket(
import.meta.env.VITE_WS_URL,
localStorage.getItem('token') || ''
)
// 订阅数据更新
ws.on(`${dataType}_updated`, (payload) => {
const { action, item } = payload
switch (action) {
case 'create':
data.value.push(item)
break
case 'update':
const index = data.value.findIndex(d => d.id === item.id)
if (index !== -1) {
data.value[index] = item
}
break
case 'delete':
data.value = data.value.filter(d => d.id !== item.id)
break
}
})
// 初始加载数据
async function loadData() {
isLoading.value = true
try {
// TODO: 从API加载数据
} finally {
isLoading.value = false
}
}
// 刷新数据
async function refresh() {
await loadData()
}
// 清理
onUnmounted(() => {
ws.off(`${dataType}_updated`)
})
return {
data,
isLoading,
loadData,
refresh
}
}
---
c.说明
---
i.安全与权限
a.权限指令
a.说明
directives/permission.ts：
b.代码示例
---
import type { Directive } from 'vue'
import { useUserStore } from '@/stores/user'
export const permission: Directive = {
mounted(el, binding) {
const { value } = binding
const userStore = useUserStore()
const userRole = userStore.role
if (value && !hasPermission(value, userRole)) {
// 移除元素
el.parentNode?.removeChild(el)
}
}
}
function hasPermission(requiredRoles: string | string[], userRole: string): boolean {
if (Array.isArray(requiredRoles)) {
return requiredRoles.includes(userRole)
}
return requiredRoles === userRole
}
// 使用方式
// v-permission="'admin'"
// v-permission="['admin', 'super_admin']"
---
c.说明
注册全局指令：
d.代码示例
---
// main.ts
import { permission } from './directives/permission'
app.directive('permission', permission)
---
b.路由守卫
a.说明
router/guards.ts路由守卫：
b.代码示例
---
import type { Router } from 'vue-router'
import { ElMessage } from 'element-plus'
import { useUserStore } from '@/stores/user'
export function setupRouterGuards(router: Router) {
// 全局前置守卫
router.beforeEach(async (to, from, next) => {
// 设置页面标题
document.title = to.meta.title
? `${to.meta.title} - 企业采购评标系统`
: '企业采购评标系统'
// 检查认证
const userStore = useUserStore()
const requiresAuth = to.meta.requiresAuth !== false
if (requiresAuth && !userStore.isLoggedIn) {
// 未登录，跳转到登录页
ElMessage.warning('请先登录')
next({
path: '/login',
query: { redirect: to.fullPath }
})
return
}
// 检查角色权限
const requiredRoles = to.meta.roles as string[] | undefined
if (requiredRoles && !requiredRoles.includes(userStore.role)) {
ElMessage.error('权限不足')
next({ path: '/403' })
return
}
next()
})
// 全局后置钩子
router.afterEach((to, from) => {
// 页面加载完成
console.log(`导航完成: ${to.path}`)
})
// 路由错误处理
router.onError((error) => {
console.error('路由错误:', error)
ElMessage.error('页面加载失败')
})
}
---
c.说明
---
j.性能优化
a.代码分割
a.说明
路由级代码分割：
b.代码示例
---
// 使用动态导入实现路由懒加载
const routes = [
{
path: '/projects',
component: () => import('@/views/project/ProjectList.vue')
}
]
---
c.说明
组件级代码分割：
d.代码示例
---
<script setup lang="ts">
// 异步组件
const HeavyComponent = defineAsyncComponent(() =>
import('@/components/HeavyComponent.vue')
)
</script>
<template>
<HeavyComponent />
</template>
---
b.虚拟滚动
a.说明
虚拟滚动列表：
b.代码示例
---
<template>
<div class="virtual-list" ref="containerRef" @scroll="handleScroll">
<div
class="virtual-list-phantom"
:style="{ height: `${totalHeight}px` }"
/>
<div
class="virtual-list-content"
:style="{ transform: `translateY(${offset}px)` }"
>
<div
v-for="item in visibleItems"
:key="item.id"
class="virtual-list-item"
:style="{ height: `${itemHeight}px` }"
>
<slot :item="item" />
</div>
</div>
</div>
</template>
<script setup lang="ts">
import { ref, computed } from 'vue'
interface Props {
items: any[]
itemHeight: number
}
const props = defineProps<Props>()
const containerRef = ref<HTMLElement>()
const scrollTop = ref(0)
const containerHeight = ref(600)
// 可见区域数量
const visibleCount = computed(() =>
Math.ceil(containerHeight.value / props.itemHeight) + 1
)
// 起始索引
const startIndex = computed(() =>
Math.floor(scrollTop.value / props.itemHeight)
)
// 结束索引
const endIndex = computed(() =>
Math.min(startIndex.value + visibleCount.value, props.items.length)
)
// 可见项
const visibleItems = computed(() =>
props.items.slice(startIndex.value, endIndex.value)
)
// 总高度
const totalHeight = computed(() =>
props.items.length * props.itemHeight
)
// 偏移量
const offset = computed(() =>
startIndex.value * props.itemHeight
)
// 处理滚动
function handleScroll(e: Event) {
const target = e.target as HTMLElement
scrollTop.value = target.scrollTop
}
</script>
---
c.说明
---
k.总结
a.核心设计总结
a.表格数据
维度 设计方案 核心优势
架构模式 MVVM + 组件化 高复用、易维护
状态管理 Pinia 轻量级、TypeScript支持
路由设计 Vue Router 懒加载、路由守卫
API通信 Axios封装 统一拦截、错误处理
实时通信 WebSocket + VueUse 自动重连、心跳机制
UI组件 Element Plus 企业级、开箱即用
类型安全 TypeScript 编译时检查、IDE支持
性能优化 代码分割、虚拟滚动 按需加载、大数据优化
b.关键性能指标
a.表格数据
指标 目标值 优化策略
首屏加载时间 < 2秒 代码分割、资源压缩
路由切换时间 < 500ms 路由懒加载、预加载
列表渲染性能 1000+项 虚拟滚动
WebSocket延迟 < 100ms 自动重连、心跳机制
包体积 < 1MB Tree shaking、代码分割
b.说明
---
文档版本：v1.0
最后更新：2026-01-18
文档状态：初稿
07.安全架构设计
a.安全架构概览
a.安全架构定位
a.说明
安全在系统中的核心地位：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 安全保障体系 │
│ ┌───────────────────────────────────────────────┐ │
│ │ 安全防护层次 │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 网络安全 │ │ 应用安全 │ │ │
│ │ │ 防火墙/VPN │ │ 认证/授权 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ 数据安全 │ │ 合规安全 │ │ │
│ │ │ 加密/脱敏 │ │ 等保二级 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ ┌───────────────────────────────────────┐ │ │
│ │ │ 审计与监控 │ │ │
│ │ │ 完整审计日志、实时告警、行为分析 │ │ │
│ │ └───────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
---
b.核心安全原则
a.表格数据
原则 说明 应用场景
纵深防御 多层安全防护，单层突破不影响整体 网络层、应用层、数据层
最小权限 用户仅拥有完成工作所需的最小权限 RBAC权限控制
零信任 不信任任何内部/外部请求，持续验证 所有API调用、数据访问
加密优先 敏感数据加密存储和传输 数据库、文件、通信
审计优先 完整记录所有操作，可追溯 所有用户操作、系统操作
合规优先 符合法律法规和等保要求 设计、开发、部署全流程
c.安全威胁模型
a.说明
威胁来源分析：
b.表格数据
威胁来源 威胁类型 风险等级 防护措施
外部攻击者 SQL注入、XSS、DDoS 高 WAF、参数验证、限流
内部人员 数据泄露、权限滥用 中 RBAC、审计日志、脱敏
系统故障 数据丢失、服务中断 高 备份恢复、高可用架构
第三方依赖 供应链攻击、漏洞利用 中 依赖扫描、定期更新
人为失误 误操作、配置错误 中 操作确认、配置审查
c.说明
---
b.JWT认证体系
a.JWT认证流程
a.说明
完整认证流程：
b.代码示例
---
┌─────────┐ ┌─────────────┐ ┌──────────┐
│ 用户 │ │ 后端API │ │ 数据库 │
└────┬────┘ └──────┬──────┘ └────┬─────┘
│ │ │
│ 1. 登录请求（用户名+密码） │ │
├────────────────────────────>│ │
│ │ │
│ │ 2. 验证用户凭证 │
│ ├──────────────────────────>│
│ │ │
│ │ 3. 返回用户信息 │
│ │<──────────────────────────│
│ │ │
│ 4. 生成JWT Token │ │
│ {sub, username, role, exp} │ │
│ │ │
│ 5. 返回Token + 用户信息 │ │
│<────────────────────────────│ │
│ │ │
│ 6. 存储Token到LocalStorage │ │
│ │ │
│ 7. 后续请求携带Token │ │
├────────────────────────────>│ │
│ Authorization: Bearer xxx │ │
│ │ │
│ │ 8. 验证Token │
│ │ - 检查签名 │
│ │ - 检查过期时间 │
│ │ - 提取用户信息 │
│ │ │
│ 9. 返回请求结果 │ │
│<────────────────────────────│ │
---
b.JWT实现方案
a.说明
后端JWT实现：
b.代码示例
---
# core/security.py
from datetime import datetime, timedelta
from typing import Optional, Dict
from jose import JWTError, jwt
from passlib.context import CryptContext
from app.core.config import settings
# 密码加密上下文
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
class JWTManager:
"""JWT管理器"""
def __init__(
self,
secret_key: str = settings.JWT_SECRET_KEY,
algorithm: str = settings.JWT_ALGORITHM,
access_token_expire_minutes: int = settings.JWT_ACCESS_TOKEN_EXPIRE_MINUTES
):
self.secret_key = secret_key
self.algorithm = algorithm
self.access_token_expire_minutes = access_token_expire_minutes
def create_access_token(
self,
data: Dict,
expires_delta: Optional[timedelta] = None
) -> str:
"""创建访问Token"""
to_encode = data.copy()
# 设置过期时间
if expires_delta:
expire = datetime.utcnow() + expires_delta
else:
expire = datetime.utcnow() + timedelta(
minutes=self.access_token_expire_minutes
)
to_encode.update({
"exp": expire,
"iat": datetime.utcnow(),
"type": "access"
})
# 生成Token
encoded_jwt = jwt.encode(
to_encode,
self.secret_key,
algorithm=self.algorithm
)
return encoded_jwt
def decode_token(self, token: str) -> Optional[Dict]:
"""解码Token"""
try:
payload = jwt.decode(
token,
self.secret_key,
algorithms=[self.algorithm]
)
return payload
except JWTError as e:
logger.error(f"JWT解码失败: {str(e)}")
return None
def verify_token(self, token: str) -> Optional[Dict]:
"""验证Token"""
payload = self.decode_token(token)
if not payload:
return None
# 检查Token类型
if payload.get("type") != "access":
return None
return payload
# 全局JWT管理器实例
jwt_manager = JWTManager()
# 密码工具函数
def verify_password(plain_password: str, hashed_password: str) -> bool:
"""验证密码"""
return pwd_context.verify(plain_password, hashed_password)
def get_password_hash(password: str) -> str:
"""获取密码哈希"""
return pwd_context.hash(password)
---
c.说明
前端JWT处理：
d.代码示例
---
// utils/auth.ts
import { jwtDecode } from 'jwt-decode'
interface JWTPayload {
sub: string
username: string
role: string
exp: number
iat: number
}
export class AuthManager {
private static readonly TOKEN_KEY = 'token'
private static readonly USER_KEY = 'user'
// 保存Token
static saveToken(token: string): void {
localStorage.setItem(this.TOKEN_KEY, token)
}
// 获取Token
static getToken(): string | null {
return localStorage.getItem(this.TOKEN_KEY)
}
// 移除Token
static removeToken(): void {
localStorage.removeItem(this.TOKEN_KEY)
localStorage.removeItem(this.USER_KEY)
}
// 解码Token
static decodeToken(token: string): JWTPayload | null {
try {
return jwtDecode<JWTPayload>(token)
} catch (error) {
console.error('Token解码失败:', error)
return null
}
}
// 检查Token是否过期
static isTokenExpired(token: string): boolean {
const payload = this.decodeToken(token)
if (!payload) return true
const now = Date.now() / 1000
return payload.exp < now
}
// 获取用户信息
static getUserInfo(): JWTPayload | null {
const token = this.getToken()
if (!token) return null
return this.decodeToken(token)
}
// 检查是否登录
static isLoggedIn(): boolean {
const token = this.getToken()
if (!token) return false
return !this.isTokenExpired(token)
}
}
---
c.Token刷新机制
a.说明
自动刷新Token：
b.代码示例
---
# core/security.py
class JWTManager:
# ... 前面的代码 ...
def create_refresh_token(
self,
data: Dict,
expires_delta: Optional[timedelta] = None
) -> str:
"""创建刷新Token"""
to_encode = data.copy()
# 刷新Token有效期：30天
if expires_delta:
expire = datetime.utcnow() + expires_delta
else:
expire = datetime.utcnow() + timedelta(days=30)
to_encode.update({
"exp": expire,
"iat": datetime.utcnow(),
"type": "refresh"
})
encoded_jwt = jwt.encode(
to_encode,
self.secret_key,
algorithm=self.algorithm
)
return encoded_jwt
def refresh_access_token(self, refresh_token: str) -> Optional[str]:
"""使用刷新Token获取新的访问Token"""
payload = self.decode_token(refresh_token)
if not payload:
return None
# 检查Token类型
if payload.get("type") != "refresh":
return None
# 创建新的访问Token
new_access_token = self.create_access_token({
"sub": payload.get("sub"),
"username": payload.get("username"),
"role": payload.get("role")
})
return new_access_token
---
c.说明
前端自动刷新：
d.代码示例
---
// composables/useAutoRefreshToken.ts
import { onMounted, onUnmounted } from 'vue'
import { AuthManager } from '@/utils/auth'
import { authApi } from '@/api/auth'
export function useAutoRefreshToken() {
let refreshTimer: number | null = null
// 刷新Token
const refreshToken = async () => {
const token = AuthManager.getToken()
if (!token) return
const payload = AuthManager.decodeToken(token)
if (!payload) return
// 在过期前5分钟刷新
const now = Date.now() / 1000
const refreshTime = payload.exp - 300 // 5分钟前
if (now >= refreshTime) {
try {
const response = await authApi.refreshToken()
AuthManager.saveToken(response.token)
console.log('Token刷新成功')
} catch (error) {
console.error('Token刷新失败:', error)
// 刷新失败，跳转到登录页
window.location.href = '/login'
}
}
}
// 启动定时器
const startTimer = () => {
// 每分钟检查一次
refreshTimer = window.setInterval(() => {
refreshToken()
}, 60000)
}
// 停止定时器
const stopTimer = () => {
if (refreshTimer) {
clearInterval(refreshTimer)
refreshTimer = null
}
}
onMounted(() => {
if (AuthManager.isLoggedIn()) {
startTimer()
}
})
onUnmounted(() => {
stopTimer()
})
return {
refreshToken,
startTimer,
stopTimer
}
}
---
e.说明
---
c.RBAC权限控制
a.角色定义
a.说明
角色权限矩阵：
b.表格数据
角色 说明 权限范围
super_admin 超级管理员 所有权限
evaluation_admin 评标管理员 项目管理、标书管理、评分管理、报告管理
evaluation_expert 评标专家 查看项目、澄清提问、手动打分
evaluation_expert_readonly 只读评标专家 仅查看权限
user 普通用户 仅查看公开结果
c.说明
权限粒度定义：
d.代码示例
---
# models/permission.py
from enum import Enum
from sqlalchemy import Column, Integer, String, Boolean, DateTime
from sqlalchemy.sql import func
from app.models.base import Base
class Permission(str, Enum):
"""权限枚举"""
# 项目管理权限
PROJECT_CREATE = "project:create"
PROJECT_READ = "project:read"
PROJECT_UPDATE = "project:update"
PROJECT_DELETE = "project:delete"
# 标书管理权限
TENDER_UPLOAD = "tender:upload"
TENDER_READ = "tender:read"
TENDER_DELETE = "tender:delete"
# 澄清权限
CLARIFICATION_CREATE = "clarification:create"
CLARIFICATION_READ = "clarification:read"
# 评分权限
SCORE_CREATE = "score:create"
SCORE_READ = "score:read"
SCORE_UPDATE = "score:update"
SCORE_DELETE = "score:delete"
# 报告权限
REPORT_READ = "report:read"
REPORT_GENERATE = "report:generate"
REPORT_EXPORT = "report:export"
# 配置管理权限
CONFIG_READ = "config:read"
CONFIG_UPDATE = "config:update"
# 用户管理权限
USER_CREATE = "user:create"
USER_READ = "user:read"
USER_UPDATE = "user:update"
USER_DELETE = "user:delete"
# 审计日志权限
AUDIT_LOG_READ = "audit_log:read"
class Role(Base):
"""角色表"""
__tablename__ = "t_roles"
id = Column(Integer, primary_key=True, index=True)
role_code = Column(String(50), unique=True, nullable=False, index=True)
role_name = Column(String(100), nullable=False)
description = Column(String(500))
is_active = Column(Boolean, default=True, nullable=False)
created_at = Column(DateTime(timezone=True), server_default=func.now(), nullable=False)
updated_at = Column(DateTime(timezone=True), server_default=func.now(), onupdate=func.now())
# 关联权限（多对多）
permissions = relationship("Permission", secondary="t_role_permissions", back_populates="roles")
class RolePermission(Base):
"""角色权限关联表"""
__tablename__ = "t_role_permissions"
role_id = Column(Integer, ForeignKey("t_roles.id"), primary_key=True)
permission_id = Column(Integer, ForeignKey("t_permissions.id"), primary_key=True)
created_at = Column(DateTime(timezone=True), server_default=func.now(), nullable=False)
---
b.RBAC实现
a.说明
权限检查装饰器：
b.代码示例
---
# decorators/permission.py
from functools import wraps
from typing import List, Callable
from fastapi import HTTPException, status
from app.models.permission import Permission
def require_permissions(*required_permissions: Permission):
"""权限检查装饰器"""
def decorator(func: Callable):
@wraps(func)
async def wrapper(*args, **kwargs):
# 获取当前用户
current_user = kwargs.get('current_user')
if not current_user:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="未认证"
)
# 获取用户权限
user_permissions = await get_user_permissions(current_user.id)
# 检查是否拥有所需权限
for permission in required_permissions:
if permission.value not in user_permissions:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail=f"缺少权限: {permission.value}"
)
return await func(*args, **kwargs)
return wrapper
return decorator
# 使用示例
from app.decorators.permission import require_permissions
from app.models.permission import Permission
@router.post("/projects")
@require_permissions(Permission.PROJECT_CREATE)
async def create_project(
project_data: ProjectCreate,
current_user = Depends(get_current_user)
):
"""创建项目（需要PROJECT_CREATE权限）"""
return await project_service.create_project(project_data)
---
c.说明
权限检查中间件：
d.代码示例
---
# middleware/permission.py
from fastapi import Request, HTTPException, status
from starlette.middleware.base import BaseHTTPMiddleware
from app.models.permission import Permission
import logging
logger = logging.getLogger(__name__)
class PermissionMiddleware(BaseHTTPMiddleware):
"""权限检查中间件"""
# 路径权限映射
PERMISSION_MAP = {
# 项目管理
"POST:/api/v1/projects": [Permission.PROJECT_CREATE],
"GET:/api/v1/projects": [Permission.PROJECT_READ],
"PUT:/api/v1/projects": [Permission.PROJECT_UPDATE],
"DELETE:/api/v1/projects": [Permission.PROJECT_DELETE],
# 标书管理
"POST:/api/v1/tenders/upload": [Permission.TENDER_UPLOAD],
"GET:/api/v1/tenders": [Permission.TENDER_READ],
# 澄清服务
"POST:/api/v1/clarifications": [Permission.CLARIFICATION_CREATE],
"GET:/api/v1/clarifications": [Permission.CLARIFICATION_READ],
# 评分管理
"POST:/api/v1/scores": [Permission.SCORE_CREATE],
"GET:/api/v1/scores": [Permission.SCORE_READ],
"PUT:/api/v1/scores": [Permission.SCORE_UPDATE],
# 报告管理
"GET:/api/v1/reports": [Permission.REPORT_READ],
"POST:/api/v1/reports/generate": [Permission.REPORT_GENERATE],
# 配置管理
"GET:/api/v1/configs": [Permission.CONFIG_READ],
"PUT:/api/v1/configs": [Permission.CONFIG_UPDATE],
}
async def dispatch(self, request: Request, call_next):
"""处理请求权限检查"""
# 跳过OPTIONS请求
if request.method == "OPTIONS":
return await call_next(request)
# 构建权限键
permission_key = f"{request.method}:{request.url.path}"
# 获取所需权限
required_permissions = self._get_required_permissions(permission_key)
if required_permissions:
# 获取当前用户
user = getattr(request.state, "user", None)
if not user:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="未认证"
)
# 检查权限
if not await self._check_permissions(user.id, required_permissions):
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail=f"权限不足: {', '.join([p.value for p in required_permissions])}"
)
return await call_next(request)
def _get_required_permissions(self, permission_key: str) -> List[Permission]:
"""获取所需权限"""
# 精确匹配
if permission_key in self.PERMISSION_MAP:
return self.PERMISSION_MAP[permission_key]
# 路径前缀匹配
for key, permissions in self.PERMISSION_MAP.items():
method, path = key.split(":", 1)
if (permission_key.startswith(f"{method}:{path}") or
permission_key.startswith(f"{method}:{path.rstrip('/')}/")):
return permissions
return []
async def _check_permissions(
self,
user_id: int,
required_permissions: List[Permission]
) -> bool:
"""检查用户是否拥有所需权限"""
# 获取用户权限
user_permissions = await get_user_permissions(user_id)
# 检查是否拥有所有所需权限
for permission in required_permissions:
if permission.value not in user_permissions:
return False
return True
---
c.前端权限控制
a.说明
前端权限指令：
b.代码示例
---
// directives/permission.ts
import type { Directive } from 'vue'
import { useUserStore } from '@/stores/user'
export const permission: Directive = {
mounted(el, binding) {
const { value } = binding
const userStore = useUserStore()
if (value && !hasPermission(value, userStore.permissions)) {
// 移除元素
el.parentNode?.removeChild(el)
}
}
}
function hasPermission(
requiredPermissions: string | string[],
userPermissions: string[]
): boolean {
if (Array.isArray(requiredPermissions)) {
return requiredPermissions.some(p => userPermissions.includes(p))
}
return userPermissions.includes(requiredPermissions)
}
// 使用示例
// <el-button v-permission="'project:create'">创建项目</el-button>
// <el-button v-permission="['project:update', 'project:delete']">操作</el-button>
---
c.说明
权限检查函数：
d.代码示例
---
// utils/permission.ts
import { useUserStore } from '@/stores/user'
export function hasPermission(permission: string | string[]): boolean {
const userStore = useUserStore()
const userPermissions = userStore.permissions || []
if (Array.isArray(permission)) {
return permission.some(p => userPermissions.includes(p))
}
return userPermissions.includes(permission)
}
export function hasRole(role: string | string[]): boolean {
const userStore = useUserStore()
const userRole = userStore.role
if (Array.isArray(role)) {
return role.includes(userRole)
}
return userRole === role
}
// 在组件中使用
export function usePermission() {
return {
hasPermission,
hasRole
}
}
---
e.说明
---
d.数据安全
a.数据加密策略
a.说明
加密服务实现：
b.代码示例
---
# services/encryption.py
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2
from cryptography.hazmat.backends import default_backend
import base64
import os
from app.core.config import settings
class EncryptionService:
"""加密服务"""
def __init__(self):
# 从配置获取密钥
self.key = self._derive_key(settings.ENCRYPTION_KEY)
self.cipher = Fernet(self.key)
def _derive_key(self, password: str) -> bytes:
"""从密码派生密钥"""
# 使用PBKDF2派生密钥
kdf = PBKDF2(
algorithm=hashes.SHA256(),
length=32,
salt=settings.ENCRYPTION_SALT.encode(),
iterations=100000,
backend=default_backend()
)
return base64.urlsafe_b64encode(kdf.derive(password.encode()))
def encrypt(self, data: str) -> str:
"""加密字符串"""
encrypted = self.cipher.encrypt(data.encode())
return base64.urlsafe_b64encode(encrypted).decode()
def decrypt(self, encrypted_data: str) -> str:
"""解密字符串"""
encrypted = base64.urlsafe_b64decode(encrypted_data.encode())
decrypted = self.cipher.decrypt(encrypted)
return decrypted.decode()
def encrypt_dict(self, data: dict) -> str:
"""加密字典"""
import json
json_str = json.dumps(data)
return self.encrypt(json_str)
def decrypt_dict(self, encrypted_data: str) -> dict:
"""解密字典"""
import json
json_str = self.decrypt(encrypted_data)
return json.loads(json_str)
# 全局加密服务实例
encryption_service = EncryptionService()
---
c.说明
数据库字段加密：
d.代码示例
---
# models/base.py
from sqlalchemy import TypeDecorator, String
from app.services.encryption import encryption_service
class EncryptedString(TypeDecorator):
"""加密字符串类型"""
impl = String
cache_ok = True
def process_bind_param(self, value, dialect):
"""存储到数据库前加密"""
if value is None:
return value
return encryption_service.encrypt(value)
def process_result_value(self, value, dialect):
"""从数据库读取后解密"""
if value is None:
return value
return encryption_service.decrypt(value)
# 使用示例
class User(Base):
__tablename__ = "t_users"
id = Column(Integer, primary_key=True)
username = Column(String(50), unique=True, nullable=False)
# 加密存储敏感字段
phone = Column(EncryptedString(200)) # 手机号加密存储
email = Column(EncryptedString(200)) # 邮箱加密存储
---
b.数据脱敏策略
a.说明
脱敏工具函数：
b.代码示例
---
# utils/masking.py
import re
from typing import Optional
class DataMasking:
"""数据脱敏"""
@staticmethod
def mask_phone(phone: str) -> str:
"""手机号脱敏"""
if not phone:
return phone
return re.sub(r'(\d{3})\d{4}(\d{4})', r'\1****\2', phone)
@staticmethod
def mask_id_card(id_card: str) -> str:
"""身份证号脱敏"""
if not id_card:
return id_card
return re.sub(r'(\d{6})\d{8}(\d{4})', r'\1********\2', id_card)
@staticmethod
def mask_email(email: str) -> str:
"""邮箱脱敏"""
if not email:
return email
username, domain = email.split('@')
masked_username = username[:2] + '***' if len(username) > 2 else username
return f"{masked_username}@{domain}"
@staticmethod
def mask_name(name: str) -> str:
"""姓名脱敏"""
if not name:
return name
if len(name) <= 2:
return name[0] + '*'
return name[0] + '*' * (len(name) - 2) + name[-1]
@staticmethod
def mask_address(address: str) -> str:
"""地址脱敏"""
if not address:
return address
# 保留前6位和后6位
if len(address) <= 12:
return address
return address[:6] + '****' + address[-6:]
# 使用示例
masking = DataMasking()
masked_phone = masking.mask_phone("13812345678") # 138****5678
masked_email = masking.mask_email("[email protected]") # us***@example.com
---
c.说明
审计日志脱敏：
d.代码示例
---
# middleware/audit_masking.py
import json
from app.utils.masking import DataMasking
def mask_audit_log(log_data: dict) -> dict:
"""脱敏审计日志"""
masking = DataMasking()
masked_data = log_data.copy()
# 脱敏敏感字段
if "phone" in masked_data:
masked_data["phone"] = masking.mask_phone(masked_data["phone"])
if "id_card" in masked_data:
masked_data["id_card"] = masking.mask_id_card(masked_data["id_card"])
if "email" in masked_data:
masked_data["email"] = masking.mask_email(masked_data["email"])
if "request_data" in masked_data:
# 脱敏请求参数中的敏感信息
request_data = json.loads(masked_data["request_data"])
if "password" in request_data:
request_data["password"] = "****"
masked_data["request_data"] = json.dumps(request_data)
return masked_data
---
c.数据传输加密
a.说明
HTTPS配置：
b.代码示例
---
# main.py
from fastapi import FastAPI
from fastapi.middleware.httpsredirect import HTTPSRedirectMiddleware
from app.core.config import settings
app = FastAPI()
# 生产环境强制HTTPS
if settings.ENVIRONMENT == "prod":
app.add_middleware(HTTPSRedirectMiddleware)
---
c.说明
TLS配置：
d.代码示例
---
# Nginx TLS配置
server {
listen 443 ssl http2;
server_name api.example.com;
# SSL证书配置
ssl_certificate /etc/nginx/ssl/api.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
# SSL配置（推荐配置）
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# HSTS（强制HTTPS）
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# 其他安全头
add_header X-Frame-Options DENY always;
add_header X-Content-Type-Options nosniff always;
add_header X-XSS-Protection "1; mode=block" always;
location / {
proxy_pass http://backend:8080;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
---
e.说明
---
e.网络安全
a.防火墙配置
a.说明
网络区域隔离：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 防火墙规则 │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ DMZ区（对外服务） │ │
│ │ • Nginx (443) │ │ │
│ │ • 仅允许443端口入站 │ │
│ └──────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ 防火墙规则 │ │
│ │ • DMZ → 应用层 │ │
│ │ • 应用层 → 数据层 │ │
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────────────▼───────────────────────┐ │
│ │ 应用层（内部网络） │ │
│ │ • FastAPI (8080) │ │
│ │ • 仅允许DMZ区访问 │ │
│ └──────────────────┬───────────────────────┘ │
│ │ │
│ ┌──────────────────▼───────────────────────┐ │
│ │ 数据层（核心数据） │ │
│ │ • PostgreSQL (5432) │ │
│ │ • Redis (6379) │ │
│ │ • ChromaDB (8000) │ │
│ │ • 仅允许应用层访问 │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
---
c.说明
iptables规则示例：
d.代码示例
---
#!/bin/bash
# 防火墙规则脚本
# 清空现有规则
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
# 默认策略：拒绝入站，允许出站
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# 允许本地回环
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 允许SSH（仅限管理IP）
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
# 允许HTTP/HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# 允许应用层访问
iptables -A INPUT -p tcp --dport 8080 -s 192.168.20.0/24 -j ACCEPT
# 允许数据库访问（仅应用层）
iptables -A INPUT -p tcp --dport 5432 -s 192.168.20.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -s 192.168.20.0/24 -j ACCEPT
# 防止DDoS（限速）
iptables -A INPUT -p tcp --dport 80 -m limit --limit 100/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m limit --limit 100/second --limit-burst 200 -j ACCEPT
# 记录并丢弃其他包
iptables -A INPUT -j LOG --log-prefix "[DROP] "
iptables -A INPUT -j DROP
---
b.DDoS防护
a.说明
限流配置：
b.代码示例
---
# middleware/rate_limit.py
from fastapi import Request, HTTPException, status
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.responses import JSONResponse
import time
from collections import defaultdict
from typing import Dict
class RateLimiter:
"""限流器"""
def __init__(self):
# 存储请求时间戳
self.requests: Dict[str, list] = defaultdict(list)
def is_allowed(
self,
key: str,
limit: int = 100,
window: int = 60
) -> bool:
"""检查是否允许请求"""
now = time.time()
# 清理过期记录
self.requests[key] = [
timestamp for timestamp in self.requests[key]
if now - timestamp < window
]
# 检查是否超过限制
if len(self.requests[key]) >= limit:
return False
# 记录当前请求
self.requests[key].append(now)
return True
# 全局限流器
rate_limiter = RateLimiter()
class RateLimitMiddleware(BaseHTTPMiddleware):
"""限流中间件"""
def __init__(self, app):
super().__init__(app)
# 限流规则
self.rules = {
"default": {"limit": 100, "window": 60}, # 默认: 100请求/分钟
"clarify": {"limit": 30, "window": 60}, # 澄清: 30请求/分钟
"upload": {"limit": 10, "window": 60}, # 上传: 10请求/分钟
"login": {"limit": 5, "window": 60}, # 登录: 5请求/分钟
}
async def dispatch(self, request: Request, call_next):
"""处理请求"""
# 获取客户端标识
client_id = self._get_client_id(request)
# 确定限流规则
rule = self._get_rate_rule(request)
# 检查限流
if not rate_limiter.is_allowed(
client_id,
rule["limit"],
rule["window"]
):
return JSONResponse(
status_code=429,
content={
"success": False,
"message": "请求过于频繁，请稍后再试",
"retry_after": rule["window"]
},
headers={
"Retry-After": str(rule["window"])
}
)
return await call_next(request)
def _get_client_id(self, request: Request) -> str:
"""获取客户端标识"""
# 优先使用用户ID
if hasattr(request.state, "user_id"):
return f"user:{request.state.user_id}"
# 其次使用IP地址
forward_for = request.headers.get("X-Forwarded-For")
if forward_for:
return f"ip:{forward_for.split(',')[0].strip()}"
return f"ip:{request.client.host if request.client else 'unknown'}"
def _get_rate_rule(self, request: Request) -> dict:
"""获取限流规则"""
path = request.url.path
if "/clarifications" in path:
return self.rules["clarify"]
elif "/upload" in path:
return self.rules["upload"]
elif "/login" in path:
return self.rules["login"]
else:
return self.rules["default"]
---
c.SQL注入防护
a.说明
参数化查询：
b.代码示例
---
# crud/base.py
from sqlalchemy import text
from sqlalchemy.ext.asyncio import AsyncSession
class BaseCRUD:
"""基础CRUD类"""
async def get_by_id(self, db: AsyncSession, id: int):
"""通过ID获取"""
# ✅ 正确：使用参数化查询
query = text("SELECT * FROM t_projects WHERE id = :id")
result = await db.execute(query, {"id": id})
# ❌ 错误：字符串拼接（SQL注入风险）
# query = text(f"SELECT * FROM t_projects WHERE id = {id}")
# result = await db.execute(query)
return result.fetchone()
async def search(self, db: AsyncSession, keyword: str):
"""搜索"""
# ✅ 正确：使用参数化查询
query = text(
"SELECT * FROM t_projects WHERE project_name LIKE :keyword"
)
result = await db.execute(query, {
"keyword": f"%{keyword}%"
})
# ❌ 错误：字符串拼接（SQL注入风险）
# query = text(f"SELECT * FROM t_projects WHERE project_name LIKE '%{keyword}%'")
# result = await db.execute(query)
return result.fetchall()
---
c.说明
ORM自动防护：
d.代码示例
---
# SQLAlchemy ORM自动防护
from sqlalchemy.orm import Session
from app.models.project import Project
def get_projects_by_name(db: Session, name: str):
"""通过名称获取项目"""
# ✅ ORM自动参数化，防护SQL注入
projects = db.query(Project).filter(
Project.project_name == name
).all()
return projects
---
d.XSS防护
a.说明
前端XSS防护：
b.代码示例
---
<template>
<!-- ✅ 正确：Vue自动转义HTML -->
<div>{{ userContent }}</div>
<!-- ❌ 错误：使用v-html（XSS风险） -->
<div v-html="userContent"></div>
<!-- 如需渲染HTML，使用DOMPurify清理 -->
<div v-html="sanitizedContent"></div>
</template>
<script setup lang="ts">
import { ref, computed } from 'vue'
import DOMPurify from 'dompurify'
const userContent = ref('<script>alert("XSS")</script>')
// 清理HTML
const sanitizedContent = computed(() => {
return DOMPurify.sanitize(userContent.value)
})
</script>
---
c.说明
后端XSS防护：
d.代码示例
---
# utils/html.py
import html
def escape_html(text: str) -> str:
"""转义HTML特殊字符"""
return html.escape(text)
def sanitize_html(html_content: str) -> str:
"""清理HTML（移除危险标签）"""
from bleach import clean
# 允许的标签和属性
allowed_tags = ['p', 'br', 'strong', 'em', 'u', 'a', 'ul', 'ol', 'li']
allowed_attributes = {
'a': ['href', 'title']
}
return clean(
html_content,
tags=allowed_tags,
attributes=allowed_attributes,
strip=True
)
---
e.说明
---
f.等保二级合规
a.等保二级要求对照
a.说明
等保二级要求对照表：
b.表格数据
控制点 等保二级要求 本系统实现 符合性
身份鉴别 采用两种或两种以上组合的鉴别技术 用户名+密码+JWT ✅ 符合
访问控制 实现系统访问控制功能 RBAC权限控制 ✅ 符合
安全审计 提供审计记录，日志保存≥6个月 审计日志保存10年 ✅ 符合
数据完整性 采用校验技术或密码技术保证完整性 数字签名、数据库事务 ✅ 符合
数据保密性 采用密码技术保证保密性 AES-256-GCM加密 ✅ 符合
备份恢复 提供数据本地备份恢复 每日备份+异地备份 ✅ 符合
入侵防范 遵循最小安装原则，关闭非必要服务 Docker最小化镜像 ✅ 符合
恶意代码防范 安装防恶意代码软件 ClamAV定期扫描 ✅ 符合
b.合规实施清单
a.说明
技术层面：
b.[x] 身份鉴别：
c.[x] 用户名+密码认证
d.[x] JWT Token认证
e.[x] Token自动刷新机制
f.[x] 密码复杂度要求（8位以上，包含大小写字母、数字）
g.[x] 密码加密存储（bcrypt）
h.[x] 访问控制：
i.[x] RBAC角色权限控制
j.[x] 路由级权限控制
k.[x] 接口级权限控制
l.[x] 数据级权限控制
m.[x] 权限审计日志
n.[x] 安全审计：
o.[x] 完整审计日志（用户操作、系统操作、AI调用）
p.[x] 审计日志保存10年
q.[x] 审计日志不可篡改
r.[x] 审计日志查询接口
s.[x] 审计日志告警机制
t.[x] 数据完整性：
u.[x] 数据库事务（ACID）
v.[x] 数字签名（关键操作）
w.[x] 校验和验证（文件传输）
x.[x] 数据保密性：
y.[x] 数据库加密存储（AES-256-GCM）
z.[x] 文件加密存储（AES-256-GCM）
aa.[x] 传输加密（TLS 1.2+）
ab.[x] 敏感数据脱敏展示
ac.[x] 备份恢复：
ad.[x] 每日自动备份
ae.[x] 异地备份存储
af.[x] 备份完整性验证
ag.[x] 定期恢复演练
ah.[x] 入侵防范：
ai.[x] 最小化安装（Docker）
aj.[x] 关闭不必要端口
ak.[x] 防火墙规则
al.[x] 入侵检测（Fail2ban）
am.[x] 恶意代码防范：
an.[x] 定期病毒扫描
ao.[x] 依赖安全扫描
ap.[x] 代码审计（SonarQube）
aq.[x] 安全更新机制
c.等保测评准备
a.说明
测评准备材料：
b.代码示例
---
# 等保二级测评材料清单
## 1. 系统定级备案材料
- [x] 系统定级报告
- [x] 系统备案表
- [x] 系统安全等级保护备案证明
## 2. 安全技术体系材料
- [x] 网络拓扑图
- [x] 安全设备部署图
- [x] 网络安全防护策略文档
- [x] 主机安全防护策略文档
- [x] 应用安全防护策略文档
- [x] 数据安全防护策略文档
## 3. 安全管理体系材料
- [x] 安全管理制度汇编
- [x] 安全管理机构设置
- [x] 人员安全管理文档
- [x] 系统建设管理文档
- [x] 系统运维管理文档
## 4. 测评准备材料
- [x] 系统安全设计方案
- [x] 安全产品选型及配置说明
- [x] 系统安全测试报告
- [x] 漏洞扫描报告
- [x] 渗透测试报告
- [x] 安全配置检查表
---
c.说明
---
g.安全监控与告警
a.安全事件监控
a.说明
监控指标定义：
b.代码示例
---
# utils/security_metrics.py
from prometheus_client import Counter, Gauge, Histogram
# 安全事件计数器
security_events_total = Counter(
'security_events_total',
'安全事件总数',
['event_type', 'severity']
)
# 失败登录次数
failed_login_attempts = Counter(
'failed_login_attempts',
'失败登录尝试次数',
['username', 'ip']
)
# 权限拒绝次数
permission_denied_total = Counter(
'permission_denied_total',
'权限拒绝次数',
['user_id', 'resource']
)
# SQL注入尝试次数
sql_injection_attempts = Counter(
'sql_injection_attempts',
'SQL注入尝试次数',
['ip', 'path']
)
# 异常流量检测
abnormal_traffic = Gauge(
'abnormal_traffic',
'异常流量',
['source_ip']
)
---
b.安全告警规则
a.说明
告警规则配置：
b.代码示例
---
# utils/security_alerts.py
from typing import List, Dict
class SecurityAlertRule:
"""安全告警规则"""
def __init__(self, rule_id: str, rule_name: str, condition: Dict, actions: List[Dict]):
self.rule_id = rule_id
self.rule_name = rule_name
self.condition = condition
self.actions = actions
# 告警规则列表
SECURITY_ALERT_RULES = [
SecurityAlertRule(
rule_id="brute_force_attack",
rule_name="暴力破解攻击",
condition={
"type": "threshold",
"metric": "failed_login_attempts",
"threshold": 10,
"window": 300 # 5分钟内
},
actions=[
{"type": "block_ip", "duration": 3600},
{"type": "notify_admin", "message": "检测到暴力破解攻击"}
]
),
SecurityAlertRule(
rule_id="sql_injection_attempt",
rule_name="SQL注入尝试",
condition={
"type": "pattern_match",
"field": "request_query",
"pattern": "(?i)(union\\s+select|';--|\\|\\||\\$\\{)"
},
actions=[
{"type": "block_request"},
{"type": "notify_admin", "message": "检测到SQL注入尝试"},
{"type": "log_event", "severity": "critical"}
]
),
SecurityAlertRule(
rule_id="abnormal_traffic_spike",
rule_name="异常流量突增",
condition={
"type": "anomaly_detection",
"metric": "request_rate",
"threshold": 3, # 超过平均值3倍
"window": 60
},
actions=[
{"type": "enable_rate_limit", "limit": 10},
{"type": "notify_admin", "message": "检测到异常流量突增"}
]
)
]
---
c.说明
---
h.总结
a.核心安全设计总结
a.表格数据
安全维度 设计方案 核心措施
认证安全 JWT认证体系 Token加密存储、自动刷新、过期检查
授权安全 RBAC权限控制 角色权限矩阵、接口级权限检查、前端权限指令
数据安全 加密+脱敏 AES-256-GCM加密、敏感数据脱敏、传输加密
网络安全 防火墙+DDoS防护 网络隔离、限流策略、TLS加密
输入安全 参数验证+XSS防护 Pydantic验证、HTML转义、SQL注入防护
审计安全 完整审计追踪 10年日志保存、操作记录、不可篡改
合规安全 等保二级 28个控制点符合、定期测评、持续改进
b.安全KPI指标
a.表格数据
指标类别 具体指标 目标值 监控方式
认证安全 Token泄露率 0% 监控异常Token使用
授权安全 越权访问次数 0次/天 审计日志分析
数据安全 敏感数据泄露次数 0次 DLP系统监控
网络安全 DDoS攻击成功率 < 1% 流量监控、WAF
合规安全 等保测评通过率 100% 第三方测评报告
b.说明
---
文档版本：v1.0
最后更新：2026-01-18
文档状态：初稿
5.5 [2]功能设计
01.开标时刻并发评标架构设计
a.系统定位与合规依据
a.系统定位
a.说明
本系统为开标时刻并发评标系统，核心特征：
b.开标时刻瞬时高并发：开标时同时接收并处理10个标书文件（每个约300页PDF，50-100MB）
c.AI澄清辅助：AI只指出标书中不符合指标的地方（章节号、页码、原文对比），不做判断或纠正
d.专家手动打分：专家基于AI澄清结果手动打分，系统只做统计排名
e.只在开标时使用：开标后解密才能操作，非持续性高并发系统
b.合规依据
a.国家政策支持
a.表格数据
政策文件 关键内容 适用性
国务院《"人工智能+"行动方案》(2024) 明确将"AI+治理能力"列为六大深度融合领域之一 ✅ 支持AI在政务场景应用
国办发〔2024〕21号文 要求"加快推广数字智技术应用，推动招标投标与人工智能融合发展" ✅ 明确支持AI与招投标融合
《生成式人工智能服务管理暂行办法》(2023) 采取"包容审慎"原则，鼓励AI创新发展 ✅ 鼓励AI在合规框架下创新
b.地方实践先例
a.说明
合肥"青天大模型"（全国首个AI评标系统，2025年11月）
核心合规原则（来源于合肥实践）：
> AI评审结论是基于大数据分析和大模型算法形成的科学评审意见，评标委员会成员评审时应将其作为重要的参考依据。评标委员会成员应依据招标文件约定的评标标准和办法，结合AI评审结论做出综合评审结论。
适用到本系统：
b.法律依据：《中华人民共和国招标投标法》《中华人民共和国招标投标法实施条例》《电子招标投标办法》
c.实践模式：
d.AI"类人"评审：提供智能评审意见
e.投标文件雷达监测：检测异常行为
f.AI仅提供参考：评标委员会成员应将其作为重要参考依据
g.评标委员会承担最终责任
h.本系统AI角色：澄清工具（仅指出不符合指标的地方）
i.本系统决策主体：评标委员会专家
j.AI输出定位：参考依据，非最终决策
c.法律定位明确
a.表格数据
角色 AI系统 评标委员会专家
法律地位 工具/辅助系统 决策主体
责任承担 不承担法律责任 对最终评审结论承担责任
输出效力 参考依据 法律效力
复核流程 提供发现 专家复核并签字确认
b.说明
---
b.核心架构设计
a.整体架构
a.代码示例
---
┌─────────────────────────────────────────────────────────────────────┐
│ 开标时刻 (瞬时并发) │
│ ↓ 同时上传10个标书 │
└────────────────────────────┬────────────────────────────────────────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────▼─────┐ ┌───▼──────┐ ┌──▼──────────┐
│ Nginx │ │ FastAPI │ │ Celery │
│ 负载均衡 │ │ (API层) │ │ Worker池 │
└────┬─────┘ └───┬───────┘ └───┬─────────┘
│ │ │
└──────────────┼──────────────┘
│
┌───────────────┼───────────────┬──────────────┐
│ │ │ │
┌────▼────┐ ┌────▼────┐ ┌──▼────┐ ┌──▼─────┐
│PostgreSQL│ │ Redis │ │向量数据库 │ │文件存储 │
│(元数据) │ │ (缓存) │ │ (ChromaDB)│ │ (NFS) │
└─────────┘ └───────────┘ └──────────┘ └──────────┘
---
b.分层架构
a.接入层（Nginx负载均衡）
a.说明
职责：
开标时刻高并发应对：
b.SSL终止（HTTPS → HTTP）
c.请求路由（根据URL路径路由到不同后端服务）
d.限流防护（防止单一IP过载）
e.静态资源服务（前端文件）
f.提前启动足够的后端实例（如4个FastAPI实例）
g.配置合理的upstream负载均衡策略（least_conn最少连接优先）
b.应用层（FastAPI + Celery）
a.说明
FastAPI职责：
Celery Worker池职责：
开标时刻并发策略：
b.表格数据
策略 实施方案 预期效果
预启动Worker池 开标前1小时启动20个Worker 应对瞬时10并发
优先级队列 开标任务进入high_priority队列 优先处理开标任务
批处理优化 10个标书一起启动，并行处理 资源利用率最大化
流式处理 边解析边建立索引，不用等待完整解析 减少等待时间
c.RESTful API服务（文档上传、状态查询、澄清查询）
d.WebSocket服务（实时推送解析进度）
e.用户认证（JWT + RBAC权限控制）
f.请求验证（Pydantic数据验证）
g.异步任务处理（文档解析、索引建立、AI澄清）
h.任务优先级队列（high_priority队列处理开标时刻任务）
i.任务链编排（文档解析 → 建立索引 → 完成通知）
c.数据层（PostgreSQL + 向量数据库 + Redis）
a.说明
PostgreSQL职责：
向量数据库（ChromaDB/Qdrant）职责：
Redis职责：
---
b.标书元数据存储（项目信息、供应商信息、文件路径）
c.解析结果存储（结构化数据、章节索引、页码索引）
d.评分数据存储（专家打分、统计排名）
e.审计日志存储（AI调用记录、专家操作记录）
f.标书内容索引（段落级、句子级向量）
g.历史标书索引（10年5000个标书）
h.语义检索支持（跨项目检索近10年类似内容）
i.任务队列（Celery broker）
j.结果缓存（热点数据缓存）
k.WebSocket状态共享（多实例间同步）
c.开标时刻并发处理流程
a.并发处理时间线
a.代码示例
---
开标时刻 (T=0秒)
↓
[专家1-10] 同时上传10个标书文件（每个50-100MB）
↓
Nginx负载均衡 → 分发到FastAPI实例
↓
FastAPI接收请求 → 验证文件 → 保存到文件存储
↓
创建10个Celery任务 → 任务进入high_priority队列
↓
20个Worker并行处理
│
├─ Worker 1-10: 标书1-10（300页PDF）
│ │
│ ├─ 步骤1: 分页并行解析（10个分片并发）
│ │ │
│ │ ├─ 分片1-3: OCR提取文字
│ │ │ ├─ 分片4-6: PaddleStructure表格结构化
│ │ │ └─ 分片7-10: Qwen2-VL多模态理解
│ │ │
│ │ ├─ 步骤2: 流式建立索引（PostgreSQL + 向量数据库）
│ │ │ │
│ │ │ ├─ 每解析完一个分片立即建立索引
│ │ │ └─ 不等待完整文档解析
│ │ │
│ │ └─ 步骤3: 完成通知（WebSocket推送）
│ │
│ └─ Worker 11-20: 标书11-20（同上流程）
│
↓
T=3-5分钟：所有10个标书解析完成并建立索引
↓
专家开始提问澄清
│
├─ 问："供应商A的技术参数是否符合要求？"
│ ↓
│ └─ AI答："在第45页第3.2章节，该参数为500W，不符合600W的要求"
│
↓
专家基于澄清结果手动打分
↓
系统统计排名
---
b.300页PDF处理策略
a.分页并行解析思路
a.说明
架构层面思路（具体实现需钻研技术细节）：
b.代码示例
---
单份300页PDF
│
├─ 步骤1: 页面识别（1-2秒）
│ └─ 使用pdfplumber/PyMuPDF提取页面数和布局
│
├─ 步骤2: 分片策略（秒级）
│ └─ 将300页拆分为10个分片（每片30页）
│
├─ 步骤3: 并行解析（核心耗时，2-3分钟）
│ │
│ ├─ 分片1-3 (90页):
│ │ ├─ Worker 1: PaddleOCR文字提取
│ │ └─ Worker 2: PaddleStructure表格结构化
│ │
│ ├─ 分片4-6 (90页):
│ │ ├─ Worker 3: PaddleOCR文字提取
│ │ └─ Worker 4: PaddleStructure表格结构化
│ │
│ └─ 分片7-10 (90页):
│ ├─ Worker 5: Qwen2-VL-7B快速预览
│ └─ Worker 6: Qwen2-VL-32B深度理解
│
└─ 步骤4: 结果汇总与验证（5-10秒）
└─ 合并所有分片结果，验证一致性
---
c.说明
关键优化点：
d.分片粒度: 每片30页，平衡并行度和Worker利用率
e.流式处理: 边解析边建立索引，避免等待完整文档解析
f.内存优化: 每个Worker处理完分片后立即释放内存
g.错误恢复: 单个分片失败不影响其他分片，支持断点续传
b.流式建立索引
a.代码示例
---
分片1解析完成 → 立即建立分片1的索引
↓
分片2解析完成 → 立即建立分片2的索引
↓
...
↓
所有分片完成 → 合并索引 → 推送完成通知
---
b.说明
优势：
c.专家可以提前开始提问（部分标书解析完成后即可）
d.减少等待时间（不需要等10个标书全部完成）
e.提升用户体验（实时看到解析进度）
c.开标时刻资源预分配策略
a.Worker池预启动
a.说明
时间策略：
Worker分配策略：
b.代码示例
---
20个Worker分配：
├─ 10个Worker: 优先处理high_priority队列（开标任务）
├─ 5个Worker: 处理medium_priority队列（历史检索）
└─ 5个Worker: 处理low_priority队列（后台任务）
---
c.开标前1小时：启动20个Worker（应对10并发）
d.开标前10分钟：健康检查（确保所有Worker可用）
e.开标前5分钟：清空high_priority队列（确保队列有足够空间）
b.NPU资源预分配
a.说明
昇腾NPU资源预分配：
b.表格数据
任务类型 NPU分配 优先级
开标时刻 Qwen2.5-72B (2x TP) + Qwen2.5-VL-32B (1x) 最高
历史检索 Qwen2-VL-7B 中等
其他任务 PaddleOCR 最低
c.说明
资源隔离：
---
d.使用昇腾NPU的设备隔离特性（ASCEND_RT_VISIBLE_DEVICES）
e.关键任务独占NPU资源，避免资源争抢
f.非关键任务可共享NPU资源
d.技术栈选型
a.前端技术栈
a.表格数据
组件 技术选型 核心优势 在开标场景的应用
框架 Vue 3 (Composition API) 响应式数据绑定、组件化 实时显示10个标书解析进度
语言 TypeScript 5.0+ 类型安全、IDE智能提示 减少运行时错误，提升开发效率
UI组件 Element Plus 企业级组件库、中文友好 标书上传、进度展示、澄清问答
状态管理 Pinia 轻量、TypeScript友好 管理开标项目状态、专家权限
实时通信 WebSocket + VueUse 持久连接、自动重连 实时推送解析进度、澄清结果
HTTP客户端 Axios Promise支持、拦截器 API调用、请求/响应拦截
b.后端技术栈
a.表格数据
组件 技术选型 核心优势 在开标场景的应用
Web框架 FastAPI 高性能异步、自动文档生成 异步处理10并发上传，自动生成Swagger
异步任务 Celery 分布式任务队列、任务链编排 并行解析10个标书，任务链编排
消息队列 Redis 内存缓存、发布订阅 任务队列、缓存热点数据、WebSocket状态共享
数据库 PostgreSQL 13+ JSONB支持、关系型、ACID 存储标书元数据、解析结果、评分数据
ORM SQLAlchemy 成熟ORM、自动迁移 数据库操作抽象、类型安全
认证 JWT + BCrypt 无状态认证、密码哈希 用户身份验证、权限控制
c.AI模型技术栈
a.表格数据
模型 参数量 昇腾部署 主要能力 在开标场景的应用
Qwen2.5-72B-Instruct 72B 2x Tensor Parallel 文本理解、逻辑推理、长上下文 评标规则解析、技术参数符合度判断
Qwen2.5-VL-32B-Instruct 32B 1x 或 2x TP 多模态文档理解、表格识别、图表理解 文档理解、表格数据提取、多模态分析
Qwen2-VL-7B-Instruct 7B 1x 图像理解、快速响应 图片预览、OCR结果校验、快速分析
PaddleOCR (PP-OCRv4) - 1x 文字识别、表格识别、中文优化 OCR文字提取、表格结构化、布局分析
d.向量数据库技术栈
a.表格数据
组件 技术选型 核心优势 在开标场景的应用
向量数据库 ChromaDB / Qdrant 开源、高性能、支持元数据过滤 标书内容索引（段落级、句子级）
嵌入模型 Qwen2.5-VL-32B自嵌入或sentence-transformers 高质量语义嵌入 跨项目检索近10年类似标书内容
检索策略 混合检索（向量+元数据） 准确性提升 按项目、供应商、时间范围过滤
e.模型网关技术栈
a.表格数据
组件 技术选型 核心价值
统一网关 NewAPI 一个网关管理所有模型，降低集成复杂度
API兼容 OpenAI Compatible 标准化接口，无需修改现有代码
智能路由 基于模型名/任务类型 自动选择最优模型（开标时刻72B+32B）
负载均衡 多实例负载均衡 高可用、故障自动转移
b.说明
---
e.核心组件设计
a.文档上传与验证组件
a.说明
职责：
高并发应对：
b.代码示例
---
10个并发上传 → Nginx负载均衡 → 4个FastAPI实例
↓
每个实例处理2-3个上传请求
↓
并行验证文件（使用异步IO）
↓
并行保存到文件存储（使用NFS并行写入）
↓
创建10个Celery任务（批量创建，减少Redis往返）
---
c.说明
验证规则：
d.接收10个并发文件上传
e.文件验证（类型、大小、格式）
f.文件存储（NFS/OSS）
g.创建Celery任务
h.文件类型：仅允许PDF（application/pdf）
i.文件大小：≤200MB
j.文件名安全：无路径遍历、无特殊字符
k.文件内容：初步检查是否为有效PDF（非损坏文件）
b.并行文档解析组件
a.说明
职责：
核心思路：
b.代码示例
---
单份300页PDF
│
├─ 拆分策略：10个分片（每片30页）
│
├─ 分片1-3 (90页): 并行解析
│ ├─ Worker 1: OCR提取文字
│ ├─ Worker 2: PaddleStructure表格结构化
│ └─ Worker 3: Qwen2-VL多模态理解
│
├─ 分片4-6 (90页): 并行解析（同上）
│
└─ 分片7-10 (90页): 并行解析（同上）
│
└─ 流式建立索引
├─ 分片1完成 → 建立分片1索引
├─ 分片2完成 → 建立分片2索引
└─ ...
---
c.说明
进度推送：
d.300页PDF分页并行解析
e.流式建立索引
f.进度推送（WebSocket）
g.分片级别：10个分片进度（10%、20%、...100%）
h.页面级别：每解析完10页推送一次（3%、6%、...）
i.完成级别：所有分片完成后推送完成通知
c.向量数据库与检索组件
a.说明
职责：
索引策略：
b.代码示例
---
当前项目10个标书 + 历史项目5000个标书
│
├─ 段落级索引（每500字一个段落）
│ ├─ 10个当前标书：10 × 1000段落 = 10000段落
│ └─ 5000个历史标书：5000 × 1000段落 = 5000000段落
│
├─ 句子级索引（每句话一个向量）
│ ├─ 10个当前标书：10 × 5000句子 = 50000句子
│ └─ 5000个历史标书：5000 × 5000句子 = 25000000句子
│
└─ 元数据索引
├─ 项目信息（项目名称、采购金额、采购时间）
├─ 供应商信息（供应商名称、资质等级）
└─ 时间信息（年份、月份）
---
c.说明
检索策略：
d.代码示例
---
用户提问："近10年类似项目的技术要求是什么？"
│
├─ 向量检索：查找语义相似的段落/句子
│ ├─ 时间范围过滤：仅检索近10年
│ ├─ 语义相似度阈值：>0.85
│ └─ Top-K返回：返回最相关的20个结果
│
└─ 结果汇总
├─ 按项目分组
├─ 按年份排序
└─ 提供原文位置（项目、供应商、页码、章节）
---
e.标书内容索引（段落级、句子级）
f.历史标书索引（10年5000个标书）
g.语义检索（跨项目检索近10年类似内容）
d.澄清引擎组件（AI只指出不符合指标）
a.说明
职责：
核心设计：
b.代码示例
---
专家提问："供应商A的技术参数是否符合要求？"
│
├─ 步骤1: 检索相关内容
│ └─ 向量数据库检索：查找"技术参数"相关段落
│ └─ 返回：20个相关段落（含原文位置）
│
├─ 步骤2: AI分析（Qwen2.5-72B）
│ ├─ 输入：招标要求 + 20个相关段落
│ ├─ Prompt设计：明确限制AI输出格式
│ └─ 输出：仅返回不符合的地方（页码、章节号、原文对比）
│
└─ 步骤3: 输出验证
├─ Pydantic模型验证输出格式
└─ 仅通过验证的输出返回给专家
---
c.说明
Prompt设计（明确限制AI输出）：
d.代码示例
---
你是一个专业的评标澄清助手。
任务：分析标书内容，**仅指出不符合招标文件要求的指标的地方**，不做判断或纠正。
输入：
1. 招标文件要求：{requirements}
2. 标书相关段落：{relevant_paragraphs}
输出格式（严格遵守）：
{
"non_compliant_items": [
{
"page": 45,
"section": "3.2.1",
"section_title": "技术规格",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W",
"original_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"document_id": "tender_A.pdf"
}
]
}
重要提示：
- 仅指出不符合的地方，**不判断是否符合**
- 仅返回原文对比，**不提供修改建议**
- 确保所有信息都能在原文中找到
---
e.说明
输出验证（Pydantic模型）：
f.代码示例
---
from pydantic import BaseModel, Field, validator
class NonCompliantItem(BaseModel):
page: int = Field(..., ge=1, description="页码")
section: str = Field(..., description="章节号")
section_title: str = Field(..., description="章节标题")
tender_requirement: str = Field(..., description="招标要求")
bid_content: str = Field(..., description="标书内容")
original_text: str = Field(..., description="原文摘录")
document_id: str = Field(..., description="文档ID")
@validator('bid_content')
def validate_content(cls, v):
# 验证标书内容确实来源于原文
# （实际实现时需验证v能在原文中找到）
return v
class ClarificationResponse(BaseModel):
non_compliant_items: List[NonCompliantItem] = Field(..., description="不符合项列表")
---
g.接收专家提问（自然语言）
h.AI分析标书内容（检索相关段落）
i.返回不符合指标的地方（页码、章节号、原文对比）
j.不做判断或纠正
e.打分统计组件
a.说明
职责：
评分流程：
b.代码示例
---
专家基于澄清结果手动打分
│
├─ 供应商A：技术分85分，商务分90分，价格分80分 → 总分85分
├─ 供应商B：技术分90分，商务分85分，价格分85分 → 总分87分
├─ 供应商C：技术分88分，商务分88分，价格分82分 → 总分86分
└─ ...
│
↓
系统统计排名
│
├─ 按总分降序排列：供应商B(87分) > 供应商C(86分) > 供应商A(85分)
├─ 计算分项排名：技术分、商务分、价格分
└─ 生成评标报告（PDF/Word）
---
c.说明
权重计算（可配置）：
d.代码示例
---
# 权重配置（示例）
WEIGHTS = {
"technical": 0.5, # 技术分权重50%
"commercial": 0.3, # 商务分权重30%
"price": 0.2 # 价格分权重20%
}
# 综合得分计算
def calculate_total_score(technical, commercial, price):
return (
technical * WEIGHTS["technical"] +
commercial * WEIGHTS["commercial"] +
price * WEIGHTS["price"]
)
# 示例：供应商A
total_score_a = (
85 * 0.5 + # 技术分
90 * 0.3 + # 商务分
80 * 0.2 # 价格分
) # = 85分
---
e.说明
---
f.接收专家手动打分
g.统计排名
h.生成评标报告
f.数据流设计
a.开标时刻完整数据流
a.代码示例
---
┌────────────────────────────────────────────────────────────────────┐
│ 1. 开标时刻 (T=0) │
│ 专家1-10同时上传10个标书文件 │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 2. FastAPI接收并验证 (T=0-30秒) │
│ ├─ 文件类型验证 │
│ ├─ 文件大小验证 │
│ ├─ 文件名安全检查 │
│ └─ 保存到NFS │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 3. 创建Celery任务 (T=30-60秒) │
│ ├─ 批量创建10个任务 │
│ ├─ 任务进入high_priority队列 │
│ └─ 返回任务ID给前端 │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 4. Celery并行处理 (T=3-5分钟) │
│ ├─ 20个Worker并行处理10个标书 │
│ │ ├─ 标书1-10: Worker 1-10处理 │
│ │ └─ 标书11-20: Worker 11-20处理 │
│ │ │
│ ├─ 每个标书分页并行解析 │
│ │ ├─ 分片1-3: OCR + PaddleStructure + Qwen2-VL │
│ │ ├─ 分片4-6: OCR + PaddleStructure + Qwen2-VL │
│ │ └─ 分片7-10: OCR + PaddleStructure + Qwen2-VL │
│ │ │
│ ├─ 流式建立索引 │
│ │ ├─ 分片完成 → 立即建立索引（PostgreSQL） │
│ │ ├─ 分片完成 → 立即建立索引（向量数据库） │
│ │ └─ WebSocket推送解析进度（分片级、页面级） │
│ │ │
│ └─ 完成通知（所有分片完成后） │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 5. 专家提问澄清 (T=5分钟-2小时) │
│ ├─ 专家提问："供应商A的技术参数是否符合要求？" │
│ │ │
│ ├─ 向量数据库检索（查找相关段落） │
│ │ ├─ 时间范围：当前项目 + 近10年历史项目 │
│ │ ├─ 语义相似度：>0.85 │
│ │ └─ Top-K：返回20个相关结果 │
│ │ │
│ ├─ AI分析（Qwen2.5-72B） │
│ │ ├─ 输入：招标要求 + 20个相关段落 │
│ │ ├─ Prompt：仅指出不符合的地方 │
│ │ └─ 输出：页码、章节号、原文对比 │
│ │ │
│ ├─ 输出验证（Pydantic模型） │
│ │ └─ 返回澄清结果给专家 │
│ │ │
│ └─ WebSocket推送澄清结果 │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 6. 专家手动打分 (T=1-2小时) │
│ ├─ 专家基于澄清结果手动打分 │
│ ├─ 技术分：85分，商务分：90分，价格分：80分 │
│ └─ 保存到PostgreSQL │
└──────────────┬──────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────┐
│ 7. 系统统计排名 (T=10-30秒) │
│ ├─ 按总分降序排列 │
│ ├─ 计算分项排名 │
│ └─ 生成评标报告（PDF/Word） │
└────────────────────────────────────────────────────────────────────┘
---
b.实时进度推送
a.说明
WebSocket连接管理：
b.代码示例
---
前端连接WebSocket
│
├─ 连接成功 → 订阅标书解析进度频道
│ └─ channel: "tender_parsing_{project_id}"
│
├─ 后端推送解析进度
│ └─ {
│ "tender_id": "tender_1",
│ "progress": 0.5, # 50%完成
│ "stage": "解析中",
│ "message": "正在解析分片5/10..."
│ }
│
└─ 前端实时展示进度条
---
c.说明
---
g.性能目标与监控
a.性能目标
a.表格数据
指标 目标值 优化策略
10个标书解析完成时间 <5分钟 分页并行、流式处理、Worker池预启动
澄清问题响应时间 <3秒 向量数据库缓存、Qwen2.5-72B优化
向量检索响应时间 <1秒 混合检索、元数据过滤
系统可用性 >99% 负载均衡、故障自动转移
WebSocket连接稳定性 >99% 自动重连、心跳机制
b.监控指标
a.说明
应用指标：
业务指标：
系统指标：
---
b.API QPS（每秒请求数）
c.API响应时间（P50、P95、P99）
d.任务队列深度（待处理任务数）
e.Worker使用率（CPU、内存、NPU）
f.标书解析成功率（>95%）
g.澄清问题响应准确率（>90%）
h.专家打分完成率（>98%）
i.NPU使用率（开标时刻>80%）
j.PostgreSQL连接池使用率（<80%）
k.Redis内存使用率（<70%）
l.向量数据库查询性能（<1秒P95）
h.关键设计决策总结
a.是否需要向量数据库？
a.说明
决策：需要
理由：
实施：
b.10年5000个标书，需要快速定位"某个技术参数在哪个标书、哪一页"
c.专家提问"近10年类似项目的技术要求"，需要跨项目检索
d.向量数据库支持语义检索，比传统关键词搜索准确度高
e.ChromaDB/Qdrant作为向量数据库
f.段落级索引（每500字一个段落）
g.混合检索（向量+元数据过滤）
b.如何处理300页PDF？
a.说明
决策：分页并行 + 流式处理
理由：
实施：
b.单线程处理300页PDF需要10-15分钟，无法满足开标时刻5分钟要求
c.分页并行可以将时间缩短至3-5分钟
d.流式建立索引可以边解析边提供结果
e.将300页拆分为10个分片（每片30页）
f.10个分片并行解析
g.边解析边建立索引
c.如何应对开标时刻10并发？
a.说明
决策：预启动Worker池 + 优先级队列 + 批处理优化
理由：
实施：
b.开标时刻是瞬时高并发，不是持续性高并发
c.预启动Worker池可以应对突发流量
d.优先级队列确保开标任务优先处理
e.开标前1小时启动20个Worker
f.10个标书一起启动，并行处理
g.high_priority队列优先处理开标任务
d.澄清系统如何实现"只指出不纠正"？
a.说明
决策：Prompt工程 + 输出验证 + 前端展示限制
理由：
实施：
---
b.AI只提供参考依据，不做判断符合《招标投标法》要求
c.明确限制AI输出格式，避免AI自动判断
d.前端只展示原文对比，不提供修改入口
e.Prompt明确限制AI输出格式（仅返回页码、章节号、原文对比）
f.Pydantic模型验证输出格式
g.前端只展示原文对比，不提供修改入口
i.与现有实践对齐
a.合规性对齐（合肥"青天大模型"）
a.表格数据
维度 合肥实践 本系统设计
AI角色 AI仅提供参考依据 AI仅提供参考依据（澄清结果）
决策主体 评标委员会承担最终责任 评标委员会专家承担最终责任
输出效力 参考依据 参考依据
复核流程 评审委员会结合AI结论做出综合评审结论 专家基于AI澄清结果手动打分
b.技术对齐（国际最佳实践）
a.表格数据
实践 来源 本系统设计
人机协同 EU AI Act、UK PPN 017 专家手动打分，AI仅澄清
透明度 UK ATRS 记录AI调用、输出、专家操作
审计追踪 OECD原则 完整审计日志，保存10年
风险分类 中国AI治理框架V2.0 基于风险评估AI系统应用范围
b.说明
---
j.实施建议
a.阶段1：基础设施搭建（Week 1-2）
1.昇腾NPU环境搭建
2.模型部署（Qwen2.5-72B、Qwen2.5-VL-32B、Qwen2-VL-7B、PaddleOCR）
3.NewAPI网关部署
4.PostgreSQL + Redis + 向量数据库部署
5.FastAPI + Celery框架搭建
b.阶段2：核心功能开发（Week 3-5）
1.文档上传与验证组件
2.并行文档解析组件（300页PDF分页并行）
3.向量数据库与检索组件（10年历史标书索引）
4.澄清引擎组件（AI只指出不符合指标）
5.打分统计组件
c.阶段3：测试与优化（Week 6-8）
1.开标时刻10并发测试（模拟真实场景）
2.性能优化（300页PDF解析<5分钟）
3.合规性测试（符合《招标投标法》要求）
4.等保二级测评准备
d.阶段4：部署上线（Week 9）
a.说明
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
b.生产环境部署
c.用户培训
d.项目验收
02.大规模标书存储与检索方案
a.数据规模与存储需求
a.数据规模估算
a.标书数据量
a.说明
时间跨度：10年存档
年度预估（基于典型企业采购规模）：
总标书数据量：
b.代码示例
---
年度标书数 = 50个项目/年 × 10个供应商/项目 = 500个标书/年
10年总标书数 = 500个标书/年 × 10年 = 5000个标书
---
c.年度评标项目数：50个
d.每个项目平均参与供应商数：10个
e.每个供应商平均标书文件数：1个
b.存储容量预估
a.说明
单份标书存储需求：
b.表格数据
数据类型 单份标书大小 10年总量
原始PDF文件 50-100MB 250-500GB
解析结果（结构化） 5-10MB 25-50GB
向量索引数据 10-20MB 50-100GB
元数据（项目/供应商信息） 1-2MB 5-10GB
合计 66-132MB 330-660GB
c.说明
总存储容量（含冗余、备份、增长）：
d.代码示例
---
基础数据（10年）：330-660GB
冗余备份（3x）：1-2TB
审计日志（10年）：50-100GB
临时文件（解析缓存）：100-200GB
┌─────────────────────────────────────┐
总计：2-4TB（建议配置5TB）
└─────────────────────────────────────┘
---
b.冷热数据分层策略
a.数据分层定义
a.表格数据
分层 时间范围 数据类型 存储介质 访问频率 性能要求
热数据 当前评标项目（开标后1个月内） 当前项目标书 + 历史近期（近6个月） SSD/NVMe 每天多次 低延迟（<1ms）
温数据 近6个月-2年 近期历史标书 SSD/HDD混合 每月1-2次 中等延迟（<10ms）
冷数据 2年-10年 远期历史标书 HDD/OSS 每年1-2次 高延迟（<100ms）
b.数据流转策略
a.代码示例
---
热数据（当前项目 + 近6个月）
↓ 每月评估访问频率
↓ 频率 < 1次/周 → 迁移到温数据
↓ 频率 < 1次/月 → 迁移到冷数据
↓ 频率 < 1次/年 → 压缩归档
温数据（近6个月-2年）
↓ 每季度评估访问频率
↓ 频率 < 1次/月 → 迁移到冷数据
↓ 频率 < 1次/年 → 压缩归档
冷数据（2年-10年）
↓ 定期评估保留需求
↓ 超过10年或被覆盖 → 删除
---
c.存储成本优化
a.压缩策略
a.说明
压缩规则：
压缩后存储容量：
b.代码示例
---
原始数据：2-4TB
压缩后：0.8-2TB（压缩率50%）
备份空间：2.4-4TB（压缩后）
┌─────────────────────────────────────┐
实际所需：3.2-6TB
└─────────────────────────────────────┘
---
c.原始PDF文件：使用zstd压缩（压缩率约40-50%）
d.解析结果：JSON格式，使用zstd压缩（压缩率约60-70%）
e.向量数据：使用向量数据库内置压缩（如ChromaDB的PQ编码）
f.日志数据：使用gzip压缩（压缩率约80%）
b.去重策略
a.说明
去重维度：
去重流程：
b.代码示例
---
上传标书文件
↓
计算SHA-256哈希
↓
检查是否存在相同哈希
├─ 存在 → 返回已有文件ID（不重复存储）
└─ 不存在 → 继续上传
---
c.说明
---
d.文件级去重：基于SHA-256哈希，避免重复存储相同PDF
e.内容级去重：基于解析后文本相似度（>0.95），合并历史项目
f.段落级去重：基于向量相似度，避免重复索引相同段落
b.数据库架构设计
a.PostgreSQL（关系型数据库）
a.核心表结构
a.说明
项目表（t_projects）
b.代码示例
---
CREATE TABLE t_projects (
id BIGSERIAL PRIMARY KEY,
project_name VARCHAR(200) NOT NULL,
project_code VARCHAR(50) NOT NULL UNIQUE,
budget_amount DECIMAL(15, 2),
procurement_date DATE NOT NULL,
opening_date TIMESTAMP NOT NULL,
status VARCHAR(20) CHECK (status IN ('draft', 'opened', 'evaluated', 'closed')),
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 索引
INDEX idx_projects_code (project_code),
INDEX idx_projects_date (procurement_date DESC)
);
---
c.说明
供应商表（t_suppliers）
d.代码示例
---
CREATE TABLE t_suppliers (
id BIGSERIAL PRIMARY KEY,
supplier_name VARCHAR(200) NOT NULL,
supplier_code VARCHAR(50) NOT NULL UNIQUE,
qualification_level VARCHAR(20),
credit_rating VARCHAR(10),
contact_person VARCHAR(100),
contact_phone VARCHAR(20),
contact_email VARCHAR(100),
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_suppliers_code (supplier_code)
);
---
e.说明
标书表（t_tenders）
f.代码示例
---
CREATE TABLE t_tenders (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
supplier_id BIGINT NOT NULL REFERENCES t_suppliers(id),
tender_name VARCHAR(200) NOT NULL,
file_path VARCHAR(500) NOT NULL,
file_size BIGINT NOT NULL,
file_hash CHAR(64) NOT NULL, -- SHA-256哈希
page_count INTEGER NOT NULL,
upload_status VARCHAR(20) CHECK (upload_status IN ('uploading', 'parsing', 'indexed', 'failed')),
upload_timestamp TIMESTAMP NOT NULL DEFAULT NOW(),
parse_timestamp TIMESTAMP,
index_timestamp TIMESTAMP,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 索引
INDEX idx_tenders_project (project_id),
INDEX idx_tenders_supplier (supplier_id),
INDEX idx_tenders_file_hash (file_hash),
INDEX idx_tenders_timestamp (upload_timestamp DESC)
);
---
g.说明
解析结果表（t_parse_results）
h.代码示例
---
CREATE TABLE t_parse_results (
id BIGSERIAL PRIMARY KEY,
tender_id BIGINT NOT NULL REFERENCES t_tenders(id),
parse_type VARCHAR(20) NOT NULL CHECK (parse_type IN ('ocr', 'table_structure', 'multimodal')),
parse_status VARCHAR(20) CHECK (parse_status IN ('pending', 'processing', 'completed', 'failed')),
result_data JSONB NOT NULL, -- 结构化解析结果
error_message TEXT,
start_time TIMESTAMP NOT NULL,
end_time TIMESTAMP,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_parse_results_tender (tender_id),
INDEX idx_parse_results_status (parse_status, start_time)
);
---
i.说明
澄清记录表（t_clarifications）
j.代码示例
---
CREATE TABLE t_clarifications (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
expert_id BIGINT NOT NULL,
question TEXT NOT NULL,
ai_response JSONB NOT NULL, -- AI澄清结果
expert_action VARCHAR(20) CHECK (expert_action IN ('accepted', 'rejected', 'modified')),
expert_notes TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_clarifications_project (project_id),
INDEX idx_clarifications_expert (expert_id)
);
---
k.说明
评分记录表（t_scores）
l.代码示例
---
CREATE TABLE t_scores (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
tender_id BIGINT NOT NULL REFERENCES t_tenders(id),
expert_id BIGINT NOT NULL,
score_type VARCHAR(20) CHECK (score_type IN ('technical', 'commercial', 'price')),
score DECIMAL(5, 2) NOT NULL,
max_score DECIMAL(5, 2) NOT NULL,
comments TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_scores_project (project_id),
INDEX idx_scores_tender (tender_id),
INDEX idx_scores_expert (expert_id)
);
---
m.说明
审计日志表（t_audit_logs）
n.代码示例
---
CREATE TABLE t_audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
action VARCHAR(50) NOT NULL,
resource_type VARCHAR(50), -- 'tender', 'project', 'clarification', 'score'
resource_id BIGINT,
request_data JSONB,
response_data JSONB,
ip_address INET NOT NULL,
user_agent TEXT,
status VARCHAR(20) CHECK (status IN ('success', 'failure')),
error_message TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_audit_logs_user (user_id, created_at DESC),
INDEX idx_audit_logs_resource (resource_type, resource_id)
);
---
b.PostgreSQL配置优化
a.说明
连接池配置：
b.代码示例
---
# PostgreSQL连接池配置
SQLALCHEMY_ENGINE_URL = "postgresql://user:password@localhost/evaluation_db"
engine = create_engine(
SQLALCHEMY_ENGINE_URL,
pool_size=20, # 连接池大小（应对10并发）
max_overflow=10, # 最大溢出连接数
pool_pre_ping=True, # 连接前检查
pool_recycle=3600, # 连接回收时间（1小时）
echo=False
)
---
c.说明
JSONB字段优化：
d.代码示例
---
-- 为JSONB字段创建GIN索引（加速JSON查询）
CREATE INDEX idx_parse_results_data ON t_parse_results USING GIN (result_data);
-- 针对特定JSON路径创建索引
CREATE INDEX idx_parse_results_data_type
ON t_parse_results USING GIN (
(result_data jsonb_path_ops_type)
);
---
b.向量数据库设计（ChromaDB）
a.集合（Collection）设计
a.说明
按项目隔离集合：
b.代码示例
---
chroma/
├── collections/
│ ├── current_project_{project_id}/ -- 当前评标项目（热数据）
│ ├── recent_6months/ -- 近6个月标书（温数据）
│ ├── recent_2years/ -- 近2年标书（温数据）
│ └── archive_2_10years/ -- 2-10年标书（冷数据）
└── metadata/
├── collection_info.json -- 集合元数据（创建时间、文档数量）
└── index_stats.json -- 索引统计信息
---
c.说明
集合策略：
d.每个项目独立集合：避免集合过大，提升检索速度
e.当前项目集合：包含10个当前标书 + 近6个月历史标书（约800个）
f.历史集合：按时间范围创建，便于数据迁移
b.元数据设计
a.说明
文档元数据：
b.代码示例
---
{
"document_id": "tender_12345",
"project_id": "project_678",
"supplier_id": "supplier_567",
"supplier_name": "供应商A",
"tender_name": "技术方案标书.pdf",
"page_count": 300,
"file_size": 87324512,
"upload_date": "2026-01-15T09:30:00Z",
"parse_date": "2026-01-15T09:35:00Z",
"index_date": "2026-01-15T09:40:00Z",
"data_layer": "hot", -- hot/warm/cold
"storage_path": "/data/tenders/project_678/tender_12345.pdf"
}
---
c.说明
段落元数据：
d.代码示例
---
{
"paragraph_id": "para_987654",
"document_id": "tender_12345",
"page_number": 45,
"section_number": "3.2.1",
"section_title": "技术规格",
"paragraph_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"embedding_model": "Qwen2.5-VL-32B",
"embedding_dimension": 4096,
"chunk_type": "paragraph", -- paragraph/sentence/table
"created_at": "2026-01-15T09:40:15Z"
}
---
c.向量嵌入策略
a.说明
分段策略：
b.代码示例
---
300页标书
│
├─ 段落级索引（每500字一个段落）
│ └─ 预估段落数：约6000个/份 × 5000份 = 30000000个
│
├─ 句子级索引（每50字一个句子）
│ └─ 预估句子数：约30000个/份 × 5000份 = 150000000个
│
└─ 表格单元格索引
└─ 预估单元格数：约50个/份 × 5000份 = 250000个
---
c.说明
嵌入模型选择：
d.表格数据
内容类型 嵌入模型 维度 在检索场景的应用
文本段落 Qwen2.5-VL-32B自嵌入 4096 精准语义检索
句子级 Qwen2.5-VL-32B自嵌入 4096 高精度句子匹配
表格内容 Qwen2.5-VL-32B自嵌入 + 元数据拼接 4096 + 表格结构元数据 表格结构化检索
图像内容 Qwen2.5-VL-32B自嵌入（图像编码器） 4096 图像内容检索
e.说明
---
c.检索方案设计
a.混合检索策略
a.检索流程
a.代码示例
---
用户提问："近10年类似项目的技术要求是什么？"
│
├─ 步骤1: 元数据过滤
│ ├─ 时间范围：仅检索近10年
│ ├─ 项目类型：匹配当前项目类型（如工程建设、设备采购）
│ └─ 供应商类型：可选过滤特定供应商类型
│
├─ 步骤2: 向量检索
│ ├─ 提问句向量化（Qwen2.5-VL-32B）
│ ├─ ChromaDB向量相似度检索（Top-200）
│ └─ 设置相似度阈值：>0.85
│
├─ 步骤3: 重排序
│ ├─ 结合元数据权重：
│ │ ├─ 时间权重（近期项目权重更高）
│ │ ├─ 项目类型权重（同类型权重更高）
│ │ └─ 供应商信誉权重（高信誉供应商权重更高）
│ ├─ 计算综合相似度
│ └─ Top-K返回（20个最相关结果）
│
└─ 步骤4: 结果展示
├─ 按项目分组
├─ 按年份排序（最新的在前）
└─ 提供原文位置（项目、供应商、页码、章节）
---
b.相似度计算
a.说明
向量相似度：
b.代码示例
---
from typing import List, Tuple
import numpy as np
def calculate_similarity_scores(
query_embedding: np.ndarray,
result_embeddings: List[np.ndarray],
result_metadata: List[dict]
) -> List[Tuple[int, float, dict]]:
"""计算综合相似度分数"""
# 1. 向量余弦相似度
query_norm = np.linalg.norm(query_embedding)
similarities = []
for i, (emb, meta) in enumerate(zip(result_embeddings, result_metadata)):
emb_norm = np.linalg.norm(emb)
cosine_sim = np.dot(query_embedding, emb) / (query_norm * emb_norm)
similarities.append((i, cosine_sim, meta))
# 2. 结合元数据权重
weighted_scores = []
for idx, cosine_sim, meta in similarities:
# 时间权重（最近项目权重更高）
time_weight = calculate_time_weight(meta['upload_date'])
# 项目类型权重（同类型权重更高）
type_weight = calculate_type_weight(meta['project_type'])
# 供应商信誉权重
supplier_weight = calculate_supplier_weight(meta['credit_rating'])
# 综合相似度
weighted_score = (
cosine_sim * 0.6 +
time_weight * 0.2 +
type_weight * 0.1 +
supplier_weight * 0.1
)
weighted_scores.append((idx, weighted_score, meta))
# 3. 按综合相似度排序
weighted_scores.sort(key=lambda x: x[1], reverse=True)
return weighted_scores
def calculate_time_weight(upload_date: str) -> float:
"""计算时间权重（近期项目权重更高）"""
from datetime import datetime, timedelta
upload = datetime.fromisoformat(upload_date)
now = datetime.now()
days_ago = (now - upload_date).days
# 时间权重衰减函数（365天半衰）
if days_ago <= 30:
return 1.0
elif days_ago <= 365:
return 0.7
elif days_ago <= 365 * 2:
return 0.4
else:
return 0.2
def calculate_type_weight(project_type: str) -> float:
"""计算项目类型权重（同类型权重更高）"""
# 从当前项目类型匹配计算
current_project_type = get_current_project_type() # 从上下文获取
if project_type == current_project_type:
return 1.0
elif project_type in get_related_project_types():
return 0.7
else:
return 0.5
def calculate_supplier_weight(credit_rating: str) -> float:
"""计算供应商信誉权重"""
# 评级映射
rating_weights = {
'AAA': 1.0,
'AA': 0.9,
'A': 0.8,
'BBB': 0.6,
'BB': 0.5,
'B': 0.4,
'CCC': 0.3,
'CC': 0.2,
'C': 0.1
}
return rating_weights.get(credit_rating, 0.5)
---
b.跨项目检索设计
a.多集合并行检索
a.代码示例
---
用户提问："近10年类似项目的技术要求是什么？"
│
├─ 并行检索所有集合
│ ├─ collection: current_project_{project_id} -- 检索10个当前标书
│ ├─ collection: recent_6months/ -- 检索约300个近期标书
│ ├─ collection: recent_2years/ -- 检索约600个近2年标书
│ ├─ collection: archive_2_10years/ -- 检索约4000个2-10年标书
│ └─ 检索策略：每个集合Top-50，总计Top-200
│
├─ 结果合并与去重
│ ├─ 按document_id去重（避免重复返回同文档）
│ └─ 计算综合相似度（结合元数据权重）
│
├─ 重排序与Top-K
│ ├─ 按综合相似度降序排列
│ └─ 返回Top-20个最相关结果
│
└─ 结果分组展示
├─ 按项目分组（便于查看同一项目的不同供应商）
├─ 按年份排序（最新的在前）
└─ 提供原文位置（项目名称、供应商名称、页码、章节号）
---
b.时间范围过滤
a.说明
时间过滤策略：
b.代码示例
---
from datetime import datetime, timedelta
def filter_by_time_range(
results: List[dict],
years: int = 10
) -> List[dict]:
"""按时间范围过滤结果"""
cutoff_date = datetime.now() - timedelta(days=365 * years)
filtered_results = [
result for result in results
if result['upload_date'] >= cutoff_date.isoformat()
]
return filtered_results
# 使用示例
results = chroma_collection.query(
query_embeddings=[query_embedding],
n_results=200 # 先检索200个
)
# 时间范围过滤
filtered_results = filter_by_time_range(results, years=10)
# 最终Top-20
top_results = sorted(filtered_results, key=lambda x: x['weighted_score'], reverse=True)[:20]
---
c.检索性能优化
a.缓存策略
a.说明
Redis缓存层：
b.代码示例
---
from functools import lru_cache
import redis
import json
import hashlib
# Redis连接
redis_client = redis.Redis(
host='localhost',
port=6379,
db=3, # 专用缓存数据库
decode_responses=True
)
def get_cache_key(question: str) -> str:
"""生成缓存键"""
return f"search:{hashlib.md5(question.encode()).hexdigest()}"
def cache_search_results(question: str, results: List[dict], ttl: int = 3600):
"""缓存搜索结果（1小时）"""
cache_key = get_cache_key(question)
cache_data = json.dumps(results, ensure_ascii=False)
redis_client.setex(
name=cache_key,
value=cache_data,
time=ttl
)
def get_cached_results(question: str) -> List[dict]:
"""获取缓存结果"""
cache_key = get_cache_key(question)
cached_data = redis_client.get(cache_key)
if cached_data:
return json.loads(cached_data)
return None
# 使用示例
def search_with_cache(question: str):
"""带缓存的搜索"""
# 1. 尝试从缓存获取
cached_results = get_cached_results(question)
if cached_results:
return cached_results
# 2. 缓存未命中，执行搜索
results = execute_vector_search(question)
# 3. 缓存结果
cache_search_results(question, results, ttl=3600)
return results
---
b.向量索引优化
a.说明
HNSW索引优化：
b.代码示例
---
import chromadb
# 创建HNSW索引（高效近似最近邻搜索）
chroma_client = chromadb.PersistentClient(
path="/data/chroma",
settings=chromadb.Settings(
anonymized_telemetry=False,
allow_reset=True
)
)
# 创建集合（使用HNSW）
collection = chroma_client.get_or_create_collection(
name=f"project_{project_id}",
metadata={"hnsw:space": "cosine", "hnsw:construction_ef": 200}
)
# 添加文档
collection.add(
documents=[paragraph_text],
metadatas=[{
"document_id": doc_id,
"page_number": page_num,
"section_number": section_num
}],
embeddings=[embedding_vector],
ids=[paragraph_id]
)
# 查询（使用HNSW）
results = collection.query(
query_embeddings=[query_embedding],
n_results=20,
where={"document_id": {"$ne": None}} # 排除空文档
)
---
c.说明
---
d.数据迁移与归档策略
a.数据迁移流程
a.热数据迁移
a.说明
热数据 → 温数据（月度）：
b.代码示例
---
每月1号执行数据评估
│
├─ 步骤1: 分析访问频率
│ └─ 统计每个集合的查询次数
│
├─ 步骤2: 识别低频数据
│ └─ 标记访问频率 < 1次/周的数据为候选迁移对象
│
├─ 步骤3: 执行迁移
│ ├─ 从SSD迁移到HDD
│ ├─ 更新元数据（data_layer: hot → warm）
│ └─ 验证数据完整性
│
└─ 步骤4: 更新索引
├─ ChromaDB更新集合路径
└─ PostgreSQL更新存储路径
---
b.温数据 → 冷数据（季度）
a.说明
温数据 → 冷数据（季度）：
b.代码示例
---
每季度1号执行数据评估
│
├─ 步骤1: 分析访问频率
│ └─ 统计每个集合的查询次数
│
├─ 步骤2: 识别低频数据
│ └─ 标记访问频率 < 1次/月的数据为候选迁移对象
│
├─ 步骤3: 压缩与迁移
│ ├─ 使用zstd压缩（压缩率约50%）
│ ├─ 从HDD迁移到对象存储（OSS）
│ ├─ 更新元数据（data_layer: warm → cold）
│ └─ 验证数据完整性
│
└─ 步骤4: 更新索引
├─ ChromaDB删除本地索引
└─ 保留元数据引用（OSS路径）
---
b.数据归档策略
a.压缩归档
a.说明
压缩策略：
b.代码示例
---
原始数据
│
├─ PDF文件
│ └─ 使用zstd压缩（压缩率40-50%）
│ zstd -19 --ultra -o archive.zst original.pdf
│
├─ 解析结果（JSON）
│ └─ 使用zstd压缩（压缩率60-70%）
│ zstd -19 --ultra -o archive.zst original.json
│
└─ 向量数据（npy）
└─ 使用zstd压缩（压缩率50-60%）
zstd -19 --ultra -o archive.zst vectors.npy
---
b.分级归档
a.说明
归档层级：
b.代码示例
---
/data/archive/
├── level_1/ -- 最近2年数据（访问频率中等）
│ └── project_2024-2025/
├── level_2/ -- 2-5年数据（访问频率低）
│ └── project_2022-2024/
├── level_3/ -- 5-10年数据（访问频率极低）
│ └── project_2016-2021/
└── metadata/
└── archive_manifest.json -- 归档清单
---
c.说明
归档清单格式：
d.代码示例
---
{
"archive_id": "archive_2025Q1",
"archive_date": "2025-01-01T00:00:00Z",
"archived_projects": [
{
"project_id": "project_678",
"project_name": "设备采购项目",
"archived_date": "2025-01-01",
"data_layers": {
"hot": {
"path": "/data/hot/project_678/",
"size_gb": 12.5,
"document_count": 10
},
"warm": {
"path": "/data/warm/project_678/",
"size_gb": 8.3,
"document_count": 10
},
"cold": {
"path": "/data/cold/level_3/project_678/",
"size_gb": 6.2,
"compressed": true,
"compression_ratio": 0.48
}
}
}
],
"total_size_gb": 27.0,
"compressed_size_gb": 13.0,
"compression_ratio": 0.48
}
---
c.数据恢复策略
a.说明
恢复优先级：
b.代码示例
---
数据恢复请求
│
├─ 优先级1: 当前项目数据（热数据）
│ └─ 直接从SSD/NVMe恢复，无需解压
│
├─ 优先级2: 近6个月数据（温数据）
│ └─ 从HDD恢复，必要时解压
│
├─ 优先级3: 近2年数据（温数据）
│ ├─ 从对象存储恢复
│ └─ 必要时解压
│
└─ 优先级4: 2-10年数据（冷数据）
├─ 从对象存储恢复
├─ 解压数据
└─ 重建索引（重新嵌入和索引）
---
c.说明
---
e.存储架构实施方案
a.硬件配置建议
a.存储服务器配置
a.说明
主存储服务器（生产环境）：
b.表格数据
组件 配置 用途 数量
SSD热数据盘 2TB NVMe SSD 当前项目 + 近6个月数据
HDD温数据盘 4TB 7200RPM HDD 近6个月-2年数据
HDD冷数据盘 4TB 7200RPM HDD 2-10年归档数据
备份盘 6TB HDD 3x冗余备份
RAID配置 RAID 6 (热数据) / RAID 10 (温冷数据) 数据保护
c.说明
扩展方案：
d.横向扩展：增加存储节点，分布式存储
e.纵向扩展：增加硬盘容量，迁移现有数据
f.混合架构：本地存储 + 对象存储（OSS）
b.备份策略
a.说明
3-2-1备份策略：
b.代码示例
---
主存储（实时）
│
├─ 备份1（每日增量）
│ ├─ 时间：每天凌晨2点
│ ├─ 方式：rsync增量备份
│ ├─ 目标：备份服务器1
│ └─ 保留期：7天
│
├─ 备份2（每周全量）
│ ├─ 时间：每周日凌晨2点
│ ├─ 方式：全量备份到备份服务器2
│ ├─ 目标：备份服务器2
│ └─ 保留期：4周
│
└─ 备份3（每月异地）
├─ 时间：每月1号
├─ 方式：全量备份到异地备份服务器
├─ 目标：异地备份服务器（不同地理位置）
└─ 保留期：12个月
---
c.说明
异地备份要求：
---
d.不同物理位置（防止单点故障）
e.专用网络连接（不低于1Gbps）
f.加密传输（TLS 1.2+）
g.定期验证（每月验证备份完整性）
f.数据安全与合规
a.数据安全措施
a.加密存储
a.说明
加密策略：
b.表格数据
数据类型 加密方式 密钥管理 符合法规
原始PDF文件 AES-256-GCM 硬件安全模块（HSM） 《数据安全法》
解析结果JSON AES-256-GCM 密钥轮换（每90天） 《数据安全法》
向量数据 ChromaDB内置加密 TLS 1.2+传输加密 《网络安全法》
审计日志 AES-256-GCM 只读权限 《网络安全法》
c.说明
加密实施：
d.代码示例
---
from cryptography.fernet import Fernet
import base64
# AES-256-GCM加密
key = Fernet.generate_key()
cipher_suite = Fernet(key)
def encrypt_data(data: bytes) -> bytes:
"""加密数据"""
encrypted = cipher_suite.encrypt(data)
return encrypted
def decrypt_data(encrypted: bytes) -> bytes:
"""解密数据"""
decrypted = cipher_suite.decrypt(encrypted)
return decrypted
# 使用示例
# 加密文件
with open('tender.pdf', 'rb') as f:
file_data = f.read()
encrypted_data = encrypt_data(file_data)
with open('tender.pdf.enc', 'wb') as f:
f.write(encrypted_data)
---
b.访问控制
a.说明
基于角色的访问控制（RBAC）：
b.表格数据
角色 访问权限 数据范围
超级管理员 所有数据 全部数据（10年）
评标管理员 当前项目 + 近6个月 热数据 + 温数据
评标专家 当前项目数据 热数据（仅评标期间）
审计人员 审计日志 只读审计数据
c.说明
访问控制实施：
d.代码示例
---
from fastapi import Depends, HTTPException, status
from pydantic import BaseModel
class UserRole(str, Enum):
SUPER_ADMIN = "super_admin"
EVALUATION_ADMIN = "evaluation_admin"
EVALUATION_EXPERT = "evaluation_expert"
AUDITOR = "auditor"
def check_tender_access(
user_role: UserRole,
tender_project_id: str,
tender_created_date: str
):
"""检查标书访问权限"""
# 超级管理员：可访问所有数据
if user_role == UserRole.SUPER_ADMIN:
return True
# 评标管理员：可访问当前项目 + 近6个月
if user_role == UserRole.EVALUATION_ADMIN:
# 计算时间差
from datetime import datetime, timedelta
tender_date = datetime.fromisoformat(tender_created_date)
six_months_ago = datetime.now() - timedelta(days=180)
if tender_date >= six_months_ago:
return True # 近6个月数据
else:
raise HTTPException(
status_code=403,
detail="无权限访问该历史标书"
)
# 评标专家：仅可访问当前项目数据
if user_role == UserRole.EVALUATION_EXPERT:
current_project_id = get_current_project_id()
if tender_project_id == current_project_id:
return True # 当前项目数据
else:
raise HTTPException(
status_code=403,
detail="仅可访问当前评标项目的标书"
)
# 审计人员：仅可访问审计日志
if user_role == UserRole.AUDITOR:
# 审计权限由单独函数控制
pass
return False
# FastAPI依赖注入使用示例
@router.get("/api/tenders/{tender_id}")
async def get_tender(
tender_id: int,
current_user: User = Depends(get_current_user)
):
"""获取标书详情（带权限检查）"""
# 获取标书元数据
tender = get_tender_metadata(tender_id)
# 检查访问权限
check_tender_access(
current_user.role,
tender.project_id,
tender.upload_timestamp
)
# 验证数据层
if tender.data_layer == "cold":
check_cold_data_access(current_user.role)
return tender
---
b.合规要求
a.等保二级要求
a.说明
等保二级测评要求：
b.表格数据
要求 实施方案 验证方式
身份鉴别 用户名 + 密码 + JWT 第三方测评
访问控制 RBAC最小权限原则 第三方测评
安全审计 完整日志记录（保留6个月） 第三方测评
数据完整性 数据库事务 + 数字签名 第三方测评
数据保密性 AES-256-GCM加密存储 第三方测评
备份恢复 每日备份 + 异地备份 第三方测评
c.说明
测评准备清单：
d.[ ] 系统安全管理制度
e.[ ] 安全技术架构文档
f.[ ] 安全审计报告
g.[ ] 数据备份策略文档
h.[ ] 应急响应预案
i.[ ] 系统测试报告
b.数据分类分级
a.说明
数据分类标准：
b.表格数据
级别 定义 保护级别 适用数据
公开 可公开访问 低 采购公告、评标结果（脱敏后）
内部 仅限内部访问 中 评标规则、专家信息
敏感 仅授权人员访问 高 评标过程、标书原文
核心 极小范围访问 极高 密钥、审计日志
c.说明
分类实施：
d.代码示例
---
from enum import Enum
class DataClassification(str, Enum):
PUBLIC = "public" # 公开
INTERNAL = "internal" # 内部
SENSITIVE = "sensitive" # 敏感
CORE = "core" # 核心
def classify_data(data_type: str, user_role: UserRole) -> DataClassification:
"""数据分类"""
# 标书原文：敏感数据（仅专家可访问）
if data_type == "tender_original":
if user_role == UserRole.EVALUATION_EXPERT:
return DataClassification.SENSITIVE
else:
return DataClassification.INTERNAL
# 评标结果：公开数据（脱敏后）
if data_type == "evaluation_result":
# 脱敏处理（去除敏感信息）
return DataClassification.PUBLIC
# 评标规则：内部数据
if data_type == "evaluation_rules":
return DataClassification.INTERNAL
# 审计日志：核心数据（仅审计人员可访问）
if data_type == "audit_logs":
return DataClassification.CORE
return DataClassification.INTERNAL
---
e.说明
---
g.性能监控与运维
a.存储性能监控
a.监控指标
a.说明
存储性能指标：
b.表格数据
指标 目标值 告警阈值 优化措施
磁盘IOPS >1000 <500 增加缓存、优化查询
磁盘吞吐量 >200MB/s <100MB/s 迁移数据到SSD
存储使用率 <80% >90% 清理临时文件、数据归档
备份成功率 >99% <95% 检查备份网络、存储空间
恢复时间 <2小时 >4小时 优化备份策略
c.说明
监控实现：
d.代码示例
---
import psutil
import prometheus_client
def monitor_storage_performance():
"""监控存储性能"""
# 磁盘IOPS
disk_io = psutil.disk_io_counters()
iops = disk_io.read_count + disk_io.write_count
# 磁盘吞吐量
disk_usage = psutil.disk_usage('/')
throughput = disk_io.read_bytes + disk_io.write_bytes
# 存储使用率
total = disk_usage.total
used = disk_usage.used
usage_percent = (used / total) * 100
# 上报Prometheus
prometheus_client.gauge(
name='disk_iops',
documentation='Disk I/O operations per second',
value=iops
)
prometheus_client.gauge(
name='disk_throughput_mb',
documentation='Disk throughput in MB/s',
value=throughput / (1024 * 1024)
)
prometheus_client.gauge(
name='disk_usage_percent',
documentation='Disk usage percentage',
value=usage_percent
)
# 告警检查
if iops < 500:
send_alert('磁盘IOPS过低', {'iops': iops})
if usage_percent > 90:
send_alert('磁盘使用率过高', {'usage_percent': usage_percent})
---
b.数据生命周期管理
a.自动清理策略
a.说明
清理规则：
b.代码示例
---
临时文件（解析缓存）
│
├─ 规则：创建时间 > 7天
├─ 频率：每周一次
├─ 验证：无引用后删除
└─ 备份：删除前备份到归档
日志文件
│
├─ 规则：创建时间 > 90天
├─ 频率：每月一次
├─ 验证：导出到归档后删除
└─ 压缩：使用gzip压缩归档
审计日志
│
├─ 规则：根据等保要求保留6个月
├─ 频率：每月归档
├─ 验证：导出到归档后删除
└─ 压缩：使用gzip压缩归档
---
c.说明
清理实施：
d.代码示例
---
#!/bin/bash
# 自动清理脚本
# 1. 清理临时文件（7天以上）
find /data/temp/ -type f -mtime +7 -name "*.tmp" -delete
# 2. 清理解析缓存（30天以上）
find /data/cache/ -type f -mtime +30 -name "*.cache" -delete
# 3. 归档日志文件（90天以上）
find /var/log/evaluation/ -type f -mtime +90 -name "*.log" | \
while read file; do
gzip "$file" && mv "$file.gz" /data/archive/logs/
done && rm -f "$file"
# 4. 清理数据库备份（4周以上）
find /backup/postgres/ -type f -mtime +28 -name "*.dump" -delete
# 记录清理日志
echo "$(date): 自动清理完成" >> /var/log/cleanup/cleanup.log
---
e.说明
---
h.成本效益分析
a.存储成本估算
a.硬件成本
a.说明
存储硬件成本（3年期）：
b.表格数据
组件 配置 单价 数量 小计
SSD热数据盘 2TB NVMe SSD ¥3000 1 ¥3000
HDD温数据盘 4TB 7200RPM HDD ¥800 1 ¥800
HDD冷数据盘 4TB 7200RPM HDD ¥800 1 ¥800
备份盘 6TB HDD ¥600 1 ¥600
RAID控制器 SAS RAID控制器 ¥2000 1 ¥2000
合计 ¥7200
c.说明
年均成本： ¥2400/年（3年摊销）
b.软件许可成本
a.表格数据
软件 类型 成本（年）
PostgreSQL 开源（免费） ¥0
ChromaDB 开源（免费） ¥0
Redis 开源（免费） ¥0
zstd压缩 开源（免费） ¥0
监控（Prometheus + Grafana） 开源（免费） ¥0
合计 ¥0
c.运维成本
a.表格数据
项目 成本（年） 说明
电费 ¥3000 存储服务器24x7运行，功率约300W
机房租金 ¥12000 标准机柜（4U）
网络带宽 ¥6000 1Gbps专线带宽
运维人力 ¥100000 1/3个运维工程师
合计 ¥121200/年
d.总成本（3年期）
a.代码示例
---
硬件成本（3年）：¥7200
软件成本（3年）：¥0
运维成本（3年）：¥363600
┌─────────────────────────────────────┐
3年总成本：¥370800
年均成本：¥123600
└─────────────────────────────────────┘
---
b.效益分析
a.效率提升
a.说明
传统方式 vs AI辅助方式：
b.表格数据
活动 传统方式 AI辅助方式 效率提升
文档解析 人工3.5小时 0.5小时（AI并行） 7x
标书检索 人工2小时 3分钟（向量检索） 40x
澄清提问 人工30分钟 3秒（AI实时分析） 600x
评标周期 5个工作日 1个工作日 5x
c.说明
年度效率收益：
d.代码示例
---
节省人工时间 = 500个项目/年 × 4天节省 × 8小时/天
= 16000小时/年
人工成本（按¥100/小时）= 1600000元/年
AI系统成本（硬件+运维）= 123600元/年
┌─────────────────────────────────────┐
年度净收益：1476400元
└─────────────────────────────────────┘
---
b.合规收益
a.说明
避免风险：
b.表格数据
风险 传统方式风险 AI系统缓解 预期损失
数据泄露 中等 加密存储 + 访问控制 ¥50000
数据丢失 中等 3-2-1备份 ¥100000
不合规操作 高 完整审计追踪 ¥200000
合计 ¥350000
c.说明
合规价值：
---
d.避免罚款（等保二级未通过）：¥500000-5000000
e.提升审计通过率
f.建立数据安全信誉
i.实施计划
a.阶段1：基础设施搭建（Week 1-2）
a.说明
Week 1：
Week 2：
b.[ ] 采购存储服务器硬件（SSD + HDD）
c.[ ] 配置RAID控制器
d.[ ] 安装PostgreSQL + Redis
e.[ ] 配置备份服务器
f.[ ] 网络配置（千兆专线）
g.[ ] 部署ChromaDB向量数据库
h.[ ] 配置数据分层存储路径
i.[ ] 实施加密策略（AES-256-GCM）
j.[ ] 配置监控（Prometheus + Grafana）
k.[ ] 编写数据安全管理制度
b.阶段2：数据库开发（Week 3-4）
a.说明
Week 3：
Week 4：
b.[ ] 设计PostgreSQL表结构
c.[ ] 实现ORM模型（SQLAlchemy）
d.[ ] 编写数据库迁移脚本（Alembic）
e.[ ] 实现数据分层标记逻辑
f.[ ] 实现加密/解密模块
g.[ ] 实现向量数据库集成（ChromaDB）
h.[ ] 实现嵌入模型（Qwen2.5-VL-32B）
i.[ ] 实现混合检索逻辑（向量 + 元数据）
j.[ ] 实现缓存层（Redis）
k.[ ] 性能测试与优化
c.阶段3：测试与优化（Week 5-6）
a.说明
Week 5：
Week 6：
b.[ ] 功能测试（增删改查）
c.[ ] 性能测试（5000个标书数据）
d.[ ] 并发测试（10个并发上传）
e.[ ] 压力测试（10000 QPS）
f.[ ] 故障恢复测试
g.[ ] 根据测试结果优化查询性能
h.[ ] 优化索引策略（分段、分页）
i.[ ] 优化缓存策略（TTL、键设计）
j.[ ] 优化数据迁移流程
k.[ ] 编写运维手册
d.阶段4：部署与上线（Week 7-8）
a.说明
Week 7：
Week 8：
---
b.[ ] 生产环境部署
c.[ ] 数据迁移（如有历史数据）
d.[ ] 监控配置与告警
e.[ ] 备份策略实施
f.[ ] 安全加固（防火墙、访问控制）
g.[ ] 等保二级测评准备
h.[ ] 用户培训（操作流程、安全意识）
i.[ ] 试运行（1-2个项目）
j.[ ] 正式上线
k.[ ] 运维交接
j.风险与应对
a.技术风险
a.表格数据
风险 概率 影响 应对措施
存储容量不足 低 中 定期评估增长，提前扩容计划
向量检索性能下降 中 高 定期索引优化，HNSW调优
数据迁移失败 低 中 完善备份策略，增量迁移
加密性能影响 低 中 硬件加速（AES-NI指令集）
备份恢复失败 低 高 3-2-1备份，定期验证
b.运营风险
a.表格数据
风险 概率 影响 应对措施
运维人员变动 中 中 知识文档化，标准化运维流程
安全漏洞暴露 低 高 定期安全扫描，及时打补丁
数据泄露 低 极高 严格访问控制，加密存储，审计追踪
合规要求变更 中 高 持续关注法规变化，灵活架构调整
b.说明
---
k.总结
a.核心设计原则
1.冷热数据分层：热数据SSD、温数据HDD、冷数据归档
2.混合检索策略：向量相似度 + 元数据权重（时间、类型、信誉）
3.数据安全保护：AES-256-GCM加密、RBAC访问控制、完整审计追踪
4.性能持续优化：缓存层、HNSW索引、并行检索
5.成本效益平衡：年均成本¥12万，年均收益¥148万
b.关键成功指标
a.表格数据
指标 目标值 验证方式
存储容量 5TB 监控系统
检索响应时间 <1秒 性能测试
数据可用性 >99.9% 监控系统
备份成功率 >99% 定期验证
等保二级 通过 第三方测评
年成本控制 <¥15万 成本核算
b.说明
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
03.澄清系统与打分流程设计
a.系统定位与合规依据
a.系统定位
a.说明
本系统包含两个核心模块：
b.AI澄清系统：AI仅指出标书中不符合指标的地方，不做判断或纠正
c.辅助打分系统：专家手动打分，系统仅做统计排名
b.合规依据
a.AI系统的法律定位
a.说明
合肥"青天大模型"实践（2025年11月）的明确表述：
> AI评审结论是基于大数据分析和大模型算法形成的科学评审意见，评标委员会成员评审时应将其作为重要的参考依据。评标委员会成员应依据招标文件约定的评标标准和办法，结合AI评审结论做出综合评审结论。
关键点：
1.AI角色：提供参考依据（reference），非决策主体
2.决策主体：评标委员会专家
3.法律责任：评标委员会承担最终责任
4.AI输出效力：仅供参考，不具有法律效力
本系统的设计对齐：
b.✅ AI澄清系统：仅提供参考依据（指出不符合指标的地方）
c.✅ 专家手动打分：专家基于AI澄清结果自主判断
d.✅ 系统统计排名：仅统计和展示，不参与决策
b.AI"辅助工具"vs"澄清工具"的区分
a.表格数据
维度 AI辅助评标系统 AI澄清工具
核心功能 AI提供初步打分 AI仅指出不符合指标
输出内容 评分建议 页码、章节号、原文对比
专家角色 复核并调整评分 基于AI结果手动打分
决策主体 评标委员会（结合AI结论） 评标委员会（完全自主）
法律效力 AI结论有参考效力 AI结论仅作为线索
b.说明
本系统的选择：AI澄清工具
理由：
1.法律风险最低：AI不参与任何评分判断，仅做内容定位
2.专家自主性最高：专家完全自主判断，仅参考AI指出
3.符合"澄清"需求：用户明确要求"只指出哪些地方不符合指标"
---
b.AI澄清系统设计
a.澄清系统核心功能
a.说明
功能定义：
核心约束：
b.代码示例
---
AI澄清系统约束：
1. ✅ 仅返回原文位置（页码、章节号）
2. ✅ 仅返回原文摘录（不修改、不总结）
3. ✅ 不做任何符合性判断
4. ✅ 不提供修改建议
5. ✅ 不提供评分建议
---
c.用户输入专家提问（自然语言）
d.AI分析标书内容
e.AI返回不符合指标的地方（页码、章节号、原文对比）
f.AI不做任何"符合"、"不符合"的判断
b.澄清系统流程
a.代码示例
---
专家提问："供应商A的技术参数是否符合600W要求？"
│
├─ 步骤1: 检索招标要求
│ └─ 从招标文件中提取："技术参数≥600W"
│
├─ 步骤2: 检索标书内容
│ └─ 向量数据库检索：查找"技术参数"相关段落
│ ├─ Top-K返回：20个最相关段落
│ └─ 过滤：时间范围（当前项目+近10年）
│
├─ 步骤3: AI分析（Qwen2.5-72B）
│ └─ 输入：招标要求 + 20个相关段落
│ ├─ Prompt：明确限制AI输出格式
│ └─ 输出：仅返回不符合指标的地方
│
└─ 步骤4: 输出验证
├─ Pydantic模型验证输出格式
├─ 确保仅包含：页码、章节号、原文摘录
└─ 通过验证的输出才返回给专家
---
c.Prompt工程（核心：限制AI输出）
a.说明
Prompt模板：
b.代码示例
---
你是一个专业的评标澄清助手。
任务：分析标书内容，**仅指出不符合招标文件要求的指标的地方**，**不做判断或纠正**。
输入：
1. 招标文件要求：{requirements}
2. 标书相关段落：{relevant_paragraphs}
输出格式（严格遵守）：
{
"non_compliant_items": [
{
"page": 45,
"section": "3.2.1",
"section_title": "技术规格",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"original_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"document_id": "tender_A.pdf"
}
]
}
重要提示（严格遵守）：
- **仅指出不符合的地方**，**不判断是否符合**
- **仅返回原文对比**，**不提供修改建议**
- **仅返回原文摘录**，**不进行总结或改写**
- **确保所有信息都能在原文中找到**
- **不做任何技术方案建议**
- **不做任何符合性评分**
---
c.说明
Prompt设计要点：
1.明确任务边界：仅指出，不做判断
2.明确输出格式：严格遵守JSON格式
3.明确禁止行为：不做总结、不做建议、不做评分
4.强化约束条件：多次强调"不做判断"
d.输出验证（Pydantic模型）
a.说明
Pydantic模型设计：
b.代码示例
---
from pydantic import BaseModel, Field, validator
from typing import List, Literal
class NonCompliantItem(BaseModel):
"""不符合项（仅包含定位信息）"""
page: int = Field(
...,
ge=1,
description="页码",
example=45
)
section: str = Field(
...,
description="章节号",
example="3.2.1"
)
section_title: str = Field(
...,
description="章节标题",
example="技术规格"
)
tender_requirement: str = Field(
...,
description="招标要求",
example="功率≥600W"
)
bid_content: str = Field(
...,
description="标书内容（原文摘录）",
example="本产品功率500W，效率95%"
)
original_text: str = Field(
...,
description="原文完整摘录（保留上下文）",
example="本产品功率500W，效率95%，符合GB/T 12345-2010标准"
)
document_id: str = Field(
...,
description="文档ID",
example="tender_A.pdf"
)
@validator('bid_content')
def validate_original_text(cls, v: str):
"""验证原文摘录确实来源于原文"""
# 实际实现时需验证v能在原文中找到
# 这里仅做示例，实际验证需通过全文搜索
return v
class ClarificationResponse(BaseModel):
"""澄清响应"""
non_compliant_items: List[NonCompliantItem] = Field(
...,
description="不符合项列表（仅包含定位信息）",
min_items=0 # 允许空列表
)
---
c.说明
验证逻辑：
d.代码示例
---
def validate_clarification_response(
response: dict,
tender_document: str
) -> tuple[bool, List[str]]:
"""验证澄清响应"""
errors = []
# 检查1: 确保所有字段都符合约束
if "non_compliant_items" not in response:
errors.append("缺少non_compliant_items字段")
# 检查2: 每个项必须包含所有必需字段
for i, item in enumerate(response.get("non_compliant_items", [])):
required_fields = [
"page", "section", "section_title",
"tender_requirement", "bid_content",
"original_text", "document_id"
]
for field in required_fields:
if field not in item:
errors.append(f"第{i+1}项缺少{field}字段")
# 检查3: 禁止字段
forbidden_fields = [
"compliance_status", "score", "judgment",
"recommendation", "suggestion", "modified_text"
]
for field in forbidden_fields:
if field in item:
errors.append(f"第{i+1}项包含禁止字段{field}")
# 检查4: 验证原文确实在标书文档中
# （实际实现时需要全文搜索验证）
# 检查5: 确保没有判断性内容
# 通过字段定义约束（仅包含原文摘录）
is_valid = len(errors) == 0
return is_valid, errors
---
e.说明
---
c.打分系统设计
a.打分系统核心功能
a.说明
功能定义：
打分系统流程：
b.代码示例
---
专家打分流程：
│
├─ 步骤1: 专家查看AI澄清结果
│ └─ 前端展示：页码、章节号、原文对比
│
├─ 步骤2: 专家自主判断
│ └─ 根据招标文件要求和标书实际情况打分
│
├─ 步骤3: 系统接收评分
│ └─ 前端输入：技术分、商务分、价格分
│
├─ 步骤4: 系统计算综合得分
│ ├─ 技术分 × 权重（如0.5）
│ ├─ 商务分 × 权重（如0.3）
│ └─ 价格分 × 权重（如0.2）
│
└─ 步骤5: 系统统计排名
├─ 按综合得分降序排列
└─ 生成评标报告
---
c.专家基于AI澄清结果手动打分
d.系统按权重计算综合得分
e.系统生成评标报告
b.评分规则配置
a.说明
权重配置表：
b.表格数据
评分项 默认权重 可配置范围 说明
技术分 0.5 0.1-0.9 技术方案、技术参数、技术能力
商务分 0.3 0.1-0.7 企业资质、业绩、售后服务
价格分 0.2 0.1-0.5 报价合理性、付款方式
合计 1.0 权重总和必须为1.0
c.说明
评分规则示例：
d.表格数据
评分项 评分标准 分值范围 说明
技术分 完全响应要求 90-100分 技术方案完全符合招标要求
基本响应要求 80-89分 技术方案基本符合要求，但有细微差距
部分响应要求 70-79分 技术方案部分响应要求，存在明显不足
不响应要求 0-69分 未响应或完全不符合要求
商务分 资质完全符合 90-100分 企业资质等级高于要求
资质基本符合 80-89分 企业资质等级等于要求
资质不符合 0-79分 企业资质等级低于要求
价格分 最低价满分 100分 报价最低
非最低价按比例扣分 60-99分 每高1%扣2分，最低60分
价格异常高 0-59分 报价异常高，明显不合理
c.评分数据模型
a.说明
数据库表设计：
b.代码示例
---
CREATE TABLE t_scores (
id BIGSERIAL PRIMARY KEY,
project_id BIGINT NOT NULL REFERENCES t_projects(id),
tender_id BIGINT NOT NULL REFERENCES t_tenders(id),
expert_id BIGINT NOT NULL REFERENCES t_users(id),
-- 评分字段
technical_score DECIMAL(5, 2) NOT NULL CHECK (technical_score >= 0 AND technical_score <= 100),
commercial_score DECIMAL(5, 2) NOT NULL CHECK (commercial_score >= 0 AND commercial_score <= 100),
price_score DECIMAL(5, 2) NOT NULL CHECK (price_score >= 0 AND price_score <= 100),
-- 综合得分
total_score DECIMAL(6, 2) NOT NULL,
-- 权重配置
technical_weight DECIMAL(3, 2) NOT NULL CHECK (technical_weight >= 0 AND technical_weight <= 1),
commercial_weight DECIMAL(3, 2) NOT NULL CHECK (commercial_weight >= 0 AND commercial_weight <= 1),
price_weight DECIMAL(3, 2) NOT NULL CHECK (price_weight >= 0 AND price_weight <= 1),
-- 元数据
expert_comments TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
-- 索引
INDEX idx_scores_project (project_id),
INDEX idx_scores_tender (tender_id),
INDEX idx_scores_expert (expert_id),
INDEX idx_scores_total (total_score DESC)
);
---
c.说明
综合得分计算公式：
d.代码示例
---
def calculate_total_score(
technical_score: float,
commercial_score: float,
price_score: float,
technical_weight: float,
commercial_weight: float,
price_weight: float
) -> float:
"""计算综合得分"""
total_score = (
technical_score * technical_weight +
commercial_score * commercial_weight +
price_score * price_weight
)
return round(total_score, 2) # 保留两位小数
# 示例：使用默认权重
total_score = calculate_total_score(
technical_score=85.0,
commercial_score=90.0,
price_score=80.0,
technical_weight=0.5,
commercial_weight=0.3,
price_weight=0.2
)
# 结果：85.0×0.5 + 90.0×0.3 + 80.0×0.2 = 42.5 + 27.0 + 16.0 = 85.5分
---
e.说明
---
d.业务流程设计
a.完整评标流程
a.代码示例
---
开标时刻 (T=0)
↓
解密操作权限
↓
10个专家同时上传标书文件（每个50-100MB）
↓
[Nginx负载均衡] → 4个FastAPI实例并发处理
├─ 实例1: 处理标书1-3（专家1-3）
├─ 实例2: 处理标书4-6（专家4-6）
├─ 实例3: 处理标书7-9（专家7-9）
└─ 实例4: 处理标书10（专家10）
↓
[Celery Worker池] → 20个Worker并行处理10个标书
├─ 标书1-10: 分页并行解析 + 流式建立索引
│ ├─ Worker 1-2: OCR + PaddleStructure + Qwen2-VL
│ ├─ Worker 3-4: OCR + PaddleStructure + Qwen2-VL
│ └─ Worker 5-6: OCR + PaddleStructure + Qwen2-VL
│
└─ 所有标书解析完成（T≈3-5分钟）
↓
所有标书建立索引完成
↓
专家开始澄清提问
│
├─ 专家1提问："供应商A的技术参数是否符合600W要求？"
│ │
│ ├─ 步骤1: 检索招标要求
│ │ └─ 从招标文件中提取："技术参数≥600W"
│ │
│ ├─ 步骤2: 向量数据库检索
│ │ ├─ Top-20相关段落（时间范围：当前项目+近10年）
│ │ └─ 过滤：当前项目 > 权重更高
│ │
│ ├─ 步骤3: AI分析（Qwen2.5-72B）
│ │ ├─ 输入：招标要求 + 20个相关段落
│ │ └─ Prompt：明确限制仅返回不符合指标的地方
│ │
│ └─ 输出：页码45、章节3.2、原文对比
│ │
│ ├─ 步骤4: Pydantic验证
│ │ └─ 确保仅包含定位信息，不做判断
│ │
│ └─ 前端展示澄清结果
│
├─ 专家2提问："供应商B的资质等级是否满足AAA级要求？"
│ │
│ ├─ 步骤1-5: 同上流程（AI澄清）
│ └─ 步骤6: 前端展示澄清结果
│
│
└─ ... （专家3-10并行提问）
↓
所有专家完成澄清提问（T=5-30分钟）
↓
专家开始手动打分
│
├─ 专家1查看AI澄清结果
│ └─ 自主判断：技术分85分、商务分90分、价格分80分
│
├─ 专家2查看AI澄清结果
│ └─ 自主判断：技术分90分、商务分85分、价格分85分
│
│
└─ ... （专家3-10并行打分）
↓
系统接收所有专家评分（T=1-2小时）
↓
系统计算综合得分与排名
├─ 计算每个供应商的综合得分
├─ 按综合得分降序排列
└─ 生成评标报告
↓
评标委员会审核
├─ 审核评标报告
├─ 确认排名结果
└─ 签字确认
↓
评标结束
↓
归档数据
├─ 所有标书数据标记为"evaluated"
├─ 评分数据归档
├─ 评标报告归档（PDF/Word）
└─ 更新项目状态为"closed"
---
b.权限控制
a.说明
角色定义：
b.表格数据
角色 权限范围 评标阶段访问权限
超级管理员 所有功能 全部
评标管理员 项目管理、规则配置 全部
评标专家 澄清提问、手动打分 开标后可访问
普通用户 查看评标结果 评标结束后可访问
c.说明
权限控制实现：
d.代码示例
---
from fastapi import Depends, HTTPException, status
from pydantic import BaseModel
class UserRole(str, Enum):
SUPER_ADMIN = "super_admin"
EVALUATION_ADMIN = "evaluation_admin"
EVALUATION_EXPERT = "evaluation_expert"
USER = "user"
# 权限检查装饰器
def check_project_access(
user_role: UserRole,
project_status: str
) -> bool:
"""检查项目访问权限"""
# 超级管理员：所有权限
if user_role == UserRole.SUPER_ADMIN:
return True
# 评标管理员：项目管理和规则配置权限
if user_role == UserRole.EVALUATION_ADMIN:
if project_status in ["draft", "opened", "evaluated"]:
return True
else:
raise HTTPException(
status_code=403,
detail="项目已关闭，无权限访问"
)
# 评标专家：仅在开标后可访问
if user_role == UserRole.EVALUATION_EXPERT:
if project_status in ["opened", "evaluated"]:
return True
else:
raise HTTPException(
status_code=403,
detail="项目未开标或已评标，无权限访问"
)
# 普通用户：仅查看权限
if user_role == UserRole.USER:
if project_status == "closed":
return True
else:
raise HTTPException(
status_code=403,
detail="项目未完成，无权限查看"
)
return False
# FastAPI依赖注入
@router.post("/api/projects/{project_id}/scores")
async def submit_score(
project_id: int,
scores: ScoreSubmission,
current_user: User = Depends(get_current_user)
):
"""提交评分"""
# 检查权限
if not check_project_access(current_user.role, get_project_status(project_id)):
raise HTTPException(
status_code=403,
detail="无权限提交评分"
)
# 计算综合得分
total_score = calculate_total_score(
scores.technical_score,
scores.commercial_score,
scores.price_score,
get_weights(project_id)
)
# 保存评分
await save_score_to_db(project_id, scores, total_score)
return {"status": "success", "total_score": total_score}
---
c.系统定位明确
a.说明
前端界面标注：
b.代码示例
---
<template>
<div class="clarification-system">
<!-- AI定位明确 -->
<el-alert type="info" :closable="false">
<template #title>
<i class="el-icon-info-circle"></i>
<span>AI澄清系统</span>
</template>
<template #default>
<p>AI仅提供参考依据，不做判断或纠正</p>
<p>专家需自主判断并打分</p>
<el-tag type="info">仅供参考</el-tag>
</template>
</el-alert>
<!-- 澄清结果展示 -->
<div class="clarification-result">
<h3>不符合指标位置</h3>
<div v-for="item in clarificationResults" :key="item.id">
<el-card>
<div class="item-header">
<el-tag type="danger">页码 {{ item.page }}</el-tag>
<el-tag type="warning">章节 {{ item.section }}</el-tag>
<el-tag type="info">项目 {{ item.project_name }}</el-tag>
<el-tag type="info">供应商 {{ item.supplier_name }}</el-tag>
</div>
<div class="item-body">
<div class="tender-requirement">
<strong>招标要求：</strong>
<span class="requirement">{{ item.tender_requirement }}</span>
</div>
<div class="bid-content">
<strong>标书内容：</strong>
<span class="content">{{ item.bid_content }}</span>
</div>
<div class="original-text">
<strong>原文摘录：</strong>
<span class="text">{{ item.original_text }}</span>
</div>
</div>
</el-card>
</div>
</div>
</div>
</template>
---
c.说明
---
e.前端界面设计
a.澄清提问界面
a.说明
界面布局：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 左侧：标书列表 │ 右侧：澄清提问与结果 │
│ │ │
│ ┌────────────────────┐ │ ┌──────────────────┐ │
│ │ 标书1 │ │ │ 问题输入框 │ │
│ │ 标书2 │ │ └──────────────────┘ │
│ │ 标书3 │ │ │
│ │ ... │ │ ┌──────────────────┐ │
│ │ 标书10 │ │ │ 澄清结果列表 │ │
│ │ │ │ ├─ 项目A页码45 │ │
│ │ │ │ ├─ 项目B页码12 │ │
│ │ │ │ └─ ... │ │
│ └────────────────────┘ │ └──────────────────┘ │
└─────────────────────────────────────────────┘
---
c.说明
组件设计：
d.代码示例
---
<template>
<div class="clarification-workspace">
<!-- 左侧：标书列表 -->
<div class="tender-list">
<el-table
:data="tenders"
@row-click="selectTender"
highlight-current-row
style="width: 100%">
<el-table-column prop="tender_name" label="标书名称" width="200" />
<el-table-column prop="supplier_name" label="供应商" width="150" />
<el-table-column prop="page_count" label="页数" width="100" />
<el-table-column prop="upload_status" label="状态" width="120">
<template #default="{scope}">
<el-tag :type="getStatusType(scope.row.upload_status)">
{{ scope.row.upload_status }}
</el-tag>
</template>
</el-table-column>
<el-table-column prop="parse_status" label="解析状态" width="120">
<template #default="{scope}">
<el-tag :type="getStatusType(scope.row.parse_status)">
{{ scope.row.parse_status }}
</el-tag>
</template>
</el-table-column>
</el-table>
</div>
<!-- 右侧：澄清区域 -->
<div class="clarification-area">
<!-- 提问区 -->
<div class="question-area">
<h4>澄清提问</h4>
<el-input
v-model="question"
type="textarea"
:rows="4"
placeholder="输入澄清问题，例如：供应商A的技术参数是否符合600W要求？"
maxlength="500"
show-word-limit
/>
<el-button
type="primary"
:loading="clarificationLoading"
@click="submitClarification"
icon="Search"
>
提交澄清
</el-button>
<el-alert type="info" :closable="false">
<template #title>
<i class="el-icon-info-circle"></i>
AI仅指出不符合指标的地方
</template>
<template #default>
<p>不做判断或纠正</p>
<el-tag type="info">仅供参考</el-tag>
</template>
</el-alert>
</div>
<!-- 结果区 -->
<div class="result-area" v-if="clarificationResults.length > 0">
<h4>澄清结果</h4>
<div class="result-list">
<div
v-for="item in clarificationResults"
:key="item.id"
class="result-item"
>
<!-- 定位信息 -->
<div class="location-info">
<el-tag type="danger">页码 {{ item.page }}</el-tag>
<el-tag type="warning">章节 {{ item.section }}</el-tag>
<el-tag type="info">{{ item.project_name }}</el-tag>
<el-tag type="info">{{ item.supplier_name }}</el-tag>
</div>
<!-- 原文对比 -->
<div class="comparison">
<div class="requirement">
<strong>招标要求：</strong>
<span class="text">{{ item.tender_requirement }}</span>
</div>
<div class="bid-content">
<strong>标书内容：</strong>
<span class="text">{{ item.bid_content }}</span>
</div>
<div class="original-text">
<strong>原文摘录：</strong>
<span class="text">{{ item.original_text }}</span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</template>
<style scoped>
.clarification-workspace {
display: flex;
height: 100vh;
gap: 20px;
}
.tender-list {
flex: 1;
overflow-y: auto;
width: 30%;
}
.clarification-area {
flex: 2;
overflow-y: auto;
width: 70%;
display: flex;
flex-direction: column;
gap: 20px;
}
.question-area {
border: 1px solid #dcdfe6;
border-radius: 4px;
padding: 20px;
background: #f5f7fa;
}
.result-area {
border: 1px solid #dcdfe6;
border-radius: 4px;
padding: 20px;
background: #ffffff;
flex: 1;
overflow-y: auto;
}
.result-item {
border: 1px solid #e4e7da;
border-radius: 4px;
padding: 16px;
margin-bottom: 16px;
background: #fafafa;
}
.location-info {
display: flex;
gap: 8px;
margin-bottom: 12px;
}
.comparison {
background: #f8f9fa;
border-radius: 4px;
padding: 16px;
}
.requirement {
margin-bottom: 12px;
}
.requirement .text {
color: #909399;
font-weight: 500;
}
.bid-content {
margin-bottom: 12px;
}
.bid-content .text {
color: #e6a23c;
}
.original-text {
margin-bottom: 12px;
}
.original-text .text {
color: #909399;
font-style: italic;
}
</style>
---
b.打分界面
a.说明
界面布局：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 供应商评分表单 │
│ │
│ 供应商A │
│ ├─ 技术分: [████████] 85/100 │
│ ├─ 商务分: [████████████] 90/100 │
│ ├─ 价格分: [█████████] 80/100 │
│ └─ 总分：85.5 (排名第3) │
│ │
│ 供应商B │
│ ├─ 技术分: [████████████] 90/100 │
│ ├─ 商务分: [██████████] 85/100 │
│ ├─ 价格分: [███████████] 95/100 │
│ └─ 总分：87.0 (排名第2) │
│ │
│ 供应商C │
│ ├─ 技术分: [█████████████] 88/100 │
│ ├─ 商务分: [███████████] 88/100 │
│ ├─ 价格分: [████████████] 85/100 │
│ └─ 总分：86.1 (排名第1) │
│ │
│ [保存所有评分] [生成报告] [重置] │
│ │
└─────────────────────────────────────────────────────┘
---
c.说明
组件设计：
d.代码示例
---
<template>
<div class="scoring-workspace">
<!-- 评分表单 -->
<div class="scoring-form">
<el-table
:data="suppliers"
border
style="width: 100%"
>
<el-table-column prop="supplier_name" label="供应商" width="150" />
<!-- 技术分 -->
<el-table-column label="技术分" width="150">
<template #default="{scope}">
<div class="score-input">
<el-input-number
v-model="scope.row.technical_score"
:min="0"
:max="100"
:precision="1"
@change="onTechnicalScoreChange"
/>
</div>
</template>
</el-table-column>
<!-- 商务分 -->
<el-table-column label="商务分" width="150">
<template #default="{scope}">
<div class="score-input">
<el-input-number
v-model="scope.row.commercial_score"
:min="0"
:max="100"
:precision="1"
@change="onCommercialScoreChange"
/>
</div>
</template>
</el-table-column>
<!-- 价格分 -->
<el-table-column label="价格分" width="150">
<template #default="{scope}">
<div class="score-input">
<el-input-number
v-model="scope.row.price_score"
:min="0"
:max="100"
:precision="1"
@change="onPriceScoreChange"
/>
</div>
</template>
</el-table-column>
<!-- 综合得分 -->
<el-table-column label="综合得分" width="120">
<template #default="{scope}">
<div class="total-score">
<strong>{{ scope.row.total_score.toFixed(1) }}</strong>
</div>
</template>
</el-table-column>
<!-- 排名 -->
<el-table-column label="排名" width="100">
<template #default="{scope}">
<div class="rank">
<el-tag :type="getRankType(scope.row.rank)">
第{{ scope.row.rank }}名
</el-tag>
</div>
</template>
</el-table-column>
</el-table>
</div>
<!-- 操作按钮 -->
<div class="action-buttons">
<el-button
type="primary"
@click="calculateScores"
icon="Check"
:loading="calculating"
>
计算综合得分与排名
</el-button>
<el-button
type="success"
@click="generateReport"
icon="Document"
:loading="generating"
>
生成评标报告
</el-button>
<el-button
type="warning"
@click="resetScores"
icon="RefreshLeft"
>
重置所有评分
</el-button>
</div>
<!-- 排名预览 -->
<div class="ranking-preview" v-if="rankingCalculated">
<h3>实时排名预览</h3>
<el-table
:data="ranking"
style="width: 100%"
>
<el-table-column prop="rank" label="排名" width="80" />
<el-table-column prop="supplier_name" label="供应商" width="150" />
<el-table-column prop="technical_score" label="技术分" width="100" />
<el-table-column prop="commercial_score" label="商务分" width="100" />
<el-table-column prop="price_score" label="价格分" width="100" />
<el-table-column prop="total_score" label="综合得分" width="120" />
</el-table>
</div>
</div>
</template>
<style scoped>
.scoring-workspace {
padding: 20px;
}
.scoring-form {
border: 1px solid #dcdfe6;
border-radius: 4px;
padding: 20px;
background: #ffffff;
margin-bottom: 20px;
}
.score-input {
width: 100px;
}
.total-score {
font-size: 18px;
font-weight: bold;
color: #409eff;
}
.rank {
font-size: 16px;
font-weight: bold;
}
.el-tag.is-success {
background-color: #67c23a;
border-color: #67c23a;
}
.el-tag.is-warning {
background-color: #e6a23c;
border-color: #e6a23c;
}
.el-tag.is-danger {
background-color: #f56c6c;
border-color: #f56c6c;
}
.el-tag.is-info {
background-color: #909399;
border-color: #909399;
}
</style>
---
e.说明
---
f.审计追踪设计
a.完整审计日志
a.说明
审计表设计（已在存储方案中定义）：
b.代码示例
---
CREATE TABLE t_audit_logs (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
action VARCHAR(50) NOT NULL,
resource_type VARCHAR(50),
resource_id BIGINT,
request_data JSONB,
response_data JSONB,
ip_address INET NOT NULL,
user_agent TEXT,
status VARCHAR(20) CHECK (status IN ('success', 'failure')),
error_message TEXT,
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
INDEX idx_audit_logs_user (user_id, created_at DESC),
INDEX idx_audit_logs_resource (resource_type, resource_id),
INDEX idx_audit_logs_status (status)
);
---
b.审计记录内容
a.说明
澄清提问审计：
b.代码示例
---
{
"audit_id": "audit_12345",
"user_id": 567,
"username": "expert_张三",
"action": "submit_clarification",
"resource_type": "clarification",
"request_data": {
"question": "供应商A的技术参数是否符合600W要求？",
"project_id": 678,
"tender_ids": [123, 124, 125]
},
"response_data": {
"status": "success",
"processing_time_ms": 2847,
"result_count": 3
},
"ip_address": "192.168.1.100",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"status": "success",
"created_at": "2026-01-16T09:30:00Z"
}
---
c.说明
评分提交审计：
d.代码示例
---
{
"audit_id": "audit_12346",
"user_id": 567,
"username": "expert_张三",
"action": "submit_score",
"resource_type": "score",
"request_data": {
"project_id": 678,
"tender_id": 123,
"scores": {
"technical_score": 85,
"commercial_score": 90,
"price_score": 80,
"weights": {
"technical": 0.5,
"commercial": 0.3,
"price": 0.2
}
},
"expert_comments": "技术方案基本符合要求，但存在细微差距"
},
"response_data": {
"status": "success",
"total_score": 85.5
},
"ip_address": "192.168.1.100",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"status": "success",
"created_at": "2026-01-16T10:15:00Z"
}
---
c.审计查询与展示
a.说明
审计查询API：
b.代码示例
---
from fastapi import Depends, Query
from pydantic import BaseModel
from typing import Optional, List
from datetime import datetime, timedelta
class AuditLogQuery(BaseModel):
"""审计日志查询"""
start_date: Optional[datetime] = None
end_date: Optional[datetime] = None
user_id: Optional[int] = None
action: Optional[str] = None
resource_type: Optional[str] = None
status: Optional[str] = None
@router.get("/api/audit/logs")
async def get_audit_logs(
query: AuditLogQuery = Depends(),
current_user: User = Depends(get_current_user),
page: int = 1,
page_size: int = 50
):
"""获取审计日志"""
# 检查权限（仅管理员可查看）
if current_user.role != "super_admin":
raise HTTPException(
status_code=403,
detail="无权限查看审计日志"
)
# 构建查询
filters = []
if query.start_date:
filters.append(AuditLog.created_at >= query.start_date)
if query.end_date:
filters.append(AuditLog.created_at <= query.end_date)
if query.user_id:
filters.append(AuditLog.user_id == query.user_id)
if query.action:
filters.append(AuditLog.action == query.action)
if query.resource_type:
filters.append(AuditLog.resource_type == query.resource_type)
if query.status:
filters.append(AuditLog.status == query.status)
# 查询数据库
offset = (page - 1) * page_size
limit = page_size
async with get_db() as db:
result = await db.execute(
select(AuditLog)
.where(*filters)
.order_by(AuditLog.created_at.desc())
.offset(offset)
.limit(limit)
)
logs = result.scalars().all()
total = await db.scalar(
select(func.count(AuditLog.id))
.where(*filters)
)
return {
"logs": logs,
"total": total,
"page": page,
"page_size": page_size
}
---
c.说明
---
g.合规性保障
a.合规要点总结
a.表格数据
合规要求 实施方案 验证方式
AI仅提供参考依据 AI仅返回页码、章节号、原文对比 Prompt工程 + 输出验证
专家承担法律责任 专家手动打分，系统仅统计 明确标注"专家责任主体"
完整审计追踪 所有操作记录到审计日志表 10年保留
数据安全保护 AES-256-GCM加密存储 符合《数据安全法》
等保二级准备 准备认证材料和测试 第三方测评
透明度保障 AI调用日志、Prompt、输出可追溯 记录所有元数据
b.合规风险防控
a.表格数据
风险点 可能性 影响程度 防控措施
AI输出格式不符合 低 中 Pydantic模型严格验证
专家过度依赖AI 中 高 前端明确标注"仅供参考"
审计日志不完整 低 中 自动记录所有操作
数据泄露 低 高 加密存储 + 访问控制
法律效力误解 低 高 明确AI仅提供参考依据
b.说明
---
h.总结
a.系统核心价值
a.说明
澄清系统价值：
打分系统价值：
b.✅ 快速定位：AI在3秒内找到相关内容
c.✅ 原文对照：提供页码、章节号、原文摘录
d.✅ 历史检索：支持跨项目检索近10年类似内容
e.✅ 合规安全：AI不参与任何判断，降低法律风险
f.✅ 专家自主性：专家完全自主判断，基于AI澄清结果
g.✅ 自动计算：按权重自动计算综合得分
h.✅ 实时排名：实时计算排名并展示
i.✅ 报告生成：自动生成PDF/Word评标报告
b.关键成功指标
a.表格数据
指标 目标值 验证方式
澄清响应时间 <3秒 性能监控
向量检索准确率 >85% 用户满意度调研
专家打分完成率 >98% 系统统计
审计日志完整性 100% 监控检查
数据可用性 >99.9% 监控检查
系统可用性 >99% 监控检查
b.说明
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
04.高并发处理与性能优化方案
a.开标时刻并发处理策略
a.并发场景分析
a.并发特征
a.表格数据
维度 特征 应对策略
并发量 10个标书同时上传 预启动Worker池
持续时间 开标后5-10分钟高负载 优先级队列
数据规模 单个50-100MB，总计500MB-1GB 流式处理
处理类型 文档解析、索引建立、AI分析 异步任务编排
用户行为 专家同时提问澄清 WebSocket实时推送
b.说明
并发模式对比：
c.表格数据
模式 传统方式 本系统
触发方式 人工分批上传 开标时刻瞬时并发
资源分配 串行处理 并行处理+Worker池
响应时间 2-4小时 3-5分钟
用户体验 等待所有解析完成 实时进度推送
b.并发控制策略
a.策略1：预启动Worker池
a.说明
目标： 应对开标时刻瞬时高并发（10个标书）
实施方案：
b.代码示例
---
# 预启动Worker池（开标前1小时）
from celery import Celery
# 创建高优先级Worker
high_priority_workers = []
for i in range(10): # 预启动10个Worker
worker = celery.Worker(
name=f"high_priority_worker_{i}",
queues=['high_priority', 'medium_priority', 'low_priority'],
concurrency=2, # 每个Worker并发2个任务
pool_precount=8, # 连接池预热
)
high_priority_workers.append(worker)
worker.start()
# 创建低优先级Worker（用于历史检索等）
low_priority_workers = []
for i in range(5):
worker = celery.Worker(
name=f"low_priority_worker_{i}",
queues=['medium_priority', 'low_priority'],
concurrency=4,
)
low_priority_workers.append(worker)
worker.start()
# Worker分配策略
worker_pool = {
'high_priority': {
'workers': high_priority_workers,
'target': '开标任务',
'concurrency': 20, # 总并发能力：10Worker × 2
'auto_scale': False # 不自动扩容
},
'low_priority': {
'workers': low_priority_workers,
'target': '历史检索',
'concurrency': 20,
'auto_scale': False
}
}
---
c.说明
健康检查策略：
d.代码示例
---
from celery.signals import worker_init, worker_ready, worker_up
import redis
import logging
# 健康检查
@app.on_event(worker_init)
def handle_worker_init(**kwargs):
"""Worker启动健康检查"""
worker_name = kwargs.get('hostname', 'unknown')
logging.info(f"Worker {worker_name} started")
@app.on_event(worker_ready)
def handle_worker_ready(**kwargs):
"""Worker就绪检查"""
worker_name = kwargs.get('hostname', 'unknown')
logging.info(f"Worker {worker_name} is ready")
@app.on_event(worker_up)
def handle_worker_up(**kwargs):
"""Worker异常重启检查"""
worker_name = kwargs.get('hostname', 'unknown')
logging.warning(f"Worker {worker_name} is recovering")
# 定期健康检查（每5分钟）
from celery.schedules import crontab
@celery.on_after_configure.connect
def setup_health_monitoring():
"""设置健康监控"""
# 检查所有Worker状态
def check_workers():
stats = celery.control.inspect_stats()
active_workers = [
worker for worker in stats.get('stats', {}).values()
if worker.get('status') == 'online'
]
if len(active_workers) < len(worker_pool['high_priority']['workers']):
logging.warning(f"Only {len(active_workers)} high priority workers online, expected {len(worker_pool['high_priority']['workers'])}")
# 检查队列积压
high_queue_length = celery.control.inspect().pending('high_priority')
if len(high_queue_length) > 100:
logging.warning(f"High priority queue backlog: {len(high_queue_length)} tasks")
# 记录到Redis用于监控
redis_client.set(
f"workers:health:{datetime.now().isoformat()}",
json.dumps({
"active_workers": len(active_workers),
"queue_backlog": {
"high_priority": len(high_queue_length),
"medium_priority": celery.control.inspect().pending('medium_priority'),
"low_priority": celery.control().pending('low_priority')
}
}),
ex=300 # 5分钟过期
)
# 定期执行健康检查
crontab.schedule(
'run-every-5-minutes',
check_workers
)
---
b.策略2：优先级队列设计
a.说明
队列分类：
b.表格数据
队列名称 优先级 目标任务类型 并发度 Worker数量
high_priority 最高 开标时刻解析任务 10个Worker 20
medium_priority 中等 历史检索、报告生成 5个Worker 20
low_priority 低 后台清理、统计任务 5个Worker 20
c.说明
任务路由配置：
d.代码示例
---
from kombu import Queue
# 任务路由规则
task_routes = {
'app.tasks.document_parse': {
'queue': 'high_priority',
'routing_key': 'document_tasks',
'exchange': 'document_exchange',
'delivery_mode': 2 # 持久化队列
},
'app.tasks.ai_clarification': {
'queue': 'high_priority',
'routing_key': 'ai_tasks',
'exchange': 'ai_exchange',
'delivery_mode': 2,
'priority': 9 # 最高优先级
},
'app.tasks.scoring': {
'queue': 'medium_priority',
'routing_key': 'scoring_tasks',
'exchange': 'scoring_exchange',
'delivery_mode': 2,
'priority': 5
},
'app.tasks.report_generation': {
'queue': 'low_priority',
'routing_key': 'report_tasks',
'exchange': 'report_exchange',
'delivery_mode': 2,
'priority': 3
}
}
---
c.策略3：批处理优化
a.说明
批量创建任务：
b.代码示例
---
from celery import group
from typing import List, Dict
def batch_create_tasks(
tender_ids: List[int],
task_type: str
) -> List[Dict]:
"""批量创建任务"""
tasks = []
for tender_id in tender_ids:
task = {
'task_id': f"{task_type}_{tender_id}_{generate_uuid()}",
'args': [tender_id],
'routing_key': f"{task_type}_routing_key",
'queue': 'high_priority',
'priority': 9
}
tasks.append(task)
# 使用group批量创建任务
group_result = group(*tasks)
return group_result
def generate_uuid() -> str:
"""生成唯一UUID"""
import uuid
return str(uuid.uuid4())
---
c.说明
---
b.300页PDF处理优化
a.分页并行解析策略
a.分片策略
a.说明
分片粒度选择：
b.表格数据
分片策略 页数/片 优势 劣势
细粒度 10页 资源利用率高 Worker数量需求多
中粒度 30页 平衡资源利用 Worker数量适中
粗粒度 60页 Worker数量需求少 内存占用高
c.说明
推荐方案：中粒度（30页/片）
理由：
1.300页 ÷ 30页 = 10个分片
2.10个分片可由10个Worker并行处理（每Worker处理1个）
3.平衡资源利用率和Worker数量
4.每个分片处理时间约30-40秒（含OCR+PaddleStructure+Qwen分析）
b.并行处理流程
a.代码示例
---
300页PDF
│
├─ 步骤1: 分片（10个分片，每片30页）
│ └─ 分片1-3 (90页): Worker 1-3
│ └─ 分片4-6 (90页): Worker 4-6
│ ├─ 步骤2: 并行解析（10个分片同时处理）
│ │
│ ├─ Worker 1-3: [OCR提取 + PaddleStructure表格结构化 + Qwen2-VL-7B快速预览]
│ │ │ ├─ 分片1（1-30页）
│ │ │ └─ Task 1-1-1: 30秒
│ │ │ ├─ 分片2（31-60页）
│ │ │ └─ Task 1-1-2: 35秒
│ │ │ └─ ... 分片10（271-300页）
│ │ │ └─ Task 1-3-10: 40秒
│ │
│ ├─ Worker 4-6: [OCR + PaddleStructure + Qwen2-VL-7B]
│ │ │ ├─ 分片1（1-30页）
│ │ │ └─ Task 4-6-1-1: 30秒
│ │ │ ├─ 分片2（31-60页）
│ │ │ └─ ... 分片10
│ │
│ └─ Worker 7-9: [OCR + PaddleStructure + Qwen2-VL-32B]
│ │ ├─ 同上流程
│ │ └─ ...
│
└─ 步骤3: 汇总结果（验证一致性）
│ └─ 10个Worker并行，总耗时约3-4分钟
---
c.内存优化策略
a.说明
问题： 300页PDF + 多模型分析容易导致内存溢出
解决方案：
b.代码示例
---
import io
from PIL import Image
from fastapi import UploadFile
from typing import List
# 流式读取PDF（减少内存占用）
async def stream_parse_pdf(
file_path: str,
chunk_size: int = 10 # 页面数量
) -> AsyncGenerator[dict]:
"""流式解析PDF（减少内存占用）"""
pdf_reader = PdfReader(file_path)
# 流式读取页面
for page_num, page in enumerate(pdf_reader.pages[chunk_start:chunk_size*10:chunk_end:chunk_size*10]):
# 处理当前分片（30页）
page_images = [page.to_image() for page in page]
# 调用OCR（流式处理）
ocr_result = await process_page_with_ocr(page_images)
# 立即释放内存
for img in page_images:
img.close()
# 实时推送进度
await send_progress_update(
tender_id,
progress=(chunk_end / total_pages) * 100,
stage="parsing_chunk"
)
yield {
'chunk_id': chunk_end // chunk_size,
'ocr_result': ocr_result
}
async def process_page_with_ocr(
page_images: List[Image.Image]
) -> dict:
"""处理单页OCR（流式）"""
# PaddleOCR文字提取
text_results = []
for img in page_images:
result = paddle_ocr.ocr(img, cls=True)
text_results.append(result.texts[0])
# PaddleStructure表格结构化
table_result = paddle_structure.parse(page_images[0])
# 立即释放内存
for img in page_images:
img.close()
return {
'text': '\n'.join(text_results),
'tables': table_result
}
async def send_progress_update(
tender_id: int,
progress: float,
stage: str
):
"""实时推送解析进度"""
await websocket_manager.broadcast(
f"tender_parsing:{tender_id}",
{
"tender_id": tender_id,
"progress": progress,
"stage": stage,
"timestamp": datetime.now().isoformat()
}
)
---
b.流式建立索引
a.说明
流式索引策略：
b.代码示例
---
分片解析完成 → 立即建立索引
│
├─ 分片1完成 → 建立分片1索引
│ ├─ PostgreSQL: 存储结构化结果
│ └─ 向量数据库: 建立段落级索引
│
├─ 分片2完成 → 建立分片2索引
│ ├─ PostgreSQL: 存储结构化结果
│ └─ 向量数据库: 建立段落级索引
│
├─ ...
│
└─ 所有分片完成 → 合并索引 → 完成通知
---
c.说明
优势：
---
d.专家可以提前开始提问（部分标书解析完成后即可）
e.减少等待时间（不需要等10个标书全部完成）
f.提升用户体验（实时看到解析进度）
g.避免内存堆积（边解析边释放）
c.性能目标与监控
a.性能目标
a.表格数据
指标 目标值 优化策略 监控方式
10个标书解析完成时间 <5分钟 分页并行、流式处理 任务耗时监控
单个澄清问题响应时间 <3秒 向量缓存、Qwen2.5-72B优化 Redis监控
向量检索响应时间 <1秒 HNSW索引、元数据过滤 查询性能监控
WebSocket连接稳定性 >99% 自动重连、心跳机制 连接状态监控
系统可用性 >99% 负载均衡、故障转移 系统可用性监控
b.监控指标
a.说明
应用性能指标：
b.代码示例
---
from prometheus_client import Collector, Gauge, Histogram, Summary
from prometheus_client import Counter
# Prometheus指标定义
metrics = {
# 请求指标
'http_requests_total': Counter('http_requests_total', 'HTTP requests total'),
'http_request_duration_seconds': Histogram('http_request_duration_seconds', 'HTTP request duration'),
# 任务指标
'celery_tasks_total': Counter('celery_tasks_total', 'Celery tasks total'),
'celery_tasks_pending': Gauge('celery_tasks_pending', 'Celery tasks pending'),
'celery_tasks_failed_total': Counter('celery_tasks_failed_total', 'Celery tasks failed'),
'celery_task_duration_seconds': Histogram('celery_task_duration_seconds', 'Celery task duration'),
# NPU指标
'npu_memory_usage_percent': Gauge('npu_memory_usage_percent', 'NPU memory usage'),
'npu_utilization_percent': Gauge('npu_utilization_percent', 'NPU utilization'),
'qwen72b_inference_requests': Counter('qwen72b_inference_requests', 'Qwen 72B inference requests'),
'qwen32b_inference_requests': Counter('qwen32b_inference_requests', 'Qwen 32B inference requests'),
# 数据库指标
'postgres_connections_active': Gauge('postgres_connections_active', 'PostgreSQL connections active'),
'postgres_query_duration_seconds': Histogram('postgres_query_duration_seconds', 'PostgreSQL query duration'),
'postgres_slow_queries_total': Counter('postgres_slow_queries_total', 'PostgreSQL slow queries total'),
# 向量数据库指标
'vector_db_query_duration_seconds': Histogram('vector_db_query_duration_seconds', 'Vector DB query duration'),
'vector_db_index_size': Gauge('vector_db_index_size', 'Vector DB index size'),
# 缓存指标
'redis_memory_usage_bytes': Gauge('redis_memory_usage_bytes', 'Redis memory usage'),
'redis_cache_hit_rate': Gauge('redis_cache_hit_rate', 'Redis cache hit rate'),
# WebSocket指标
'websocket_connections_active': Gauge('websocket_connections_active', 'WebSocket connections active'),
'websocket_messages_total': Counter('websocket_messages_total', 'WebSocket messages total')
}
# 启动Prometheus服务器
@app.on_event("startup")
async def start_metrics_server():
"""启动Prometheus监控服务器"""
metrics_server = await aiohttp_server.create_server(
host='0.0.0.0',
port=9090,
metrics=[metrics]
)
---
c.说明
告警规则配置：
d.代码示例
---
# Prometheus告警规则
groups:
- name: high_error_rate
rules:
- alert: HighErrorRate
expr: rate(http_requests_total[5m]) > 10
for: 10m
labels:
severity: critical
- alert: HighTaskFailureRate
expr: rate(celery_tasks_failed_total[5m]) > 5
for: 5m
labels:
severity: critical
- alert: HighNpuUtilization
expr: npu_utilization_percent > 90
for: 10m
labels:
severity: warning
- alert: LowCacheHitRate
expr: redis_cache_hit_rate < 0.5
for: 10m
labels:
severity: warning
- alert: DatabaseConnectionPoolExhaustion
expr: postgres_connections_active > 18
for: 5m
labels:
severity: warning
- alert: LongQueryDuration
expr: histogram_quantile(0.99, postgres_query_duration_seconds) > 5
for: 10m
labels:
severity: warning
---
e.说明
---
d.NPU资源优化
a.NPU资源分配策略
a.模型优先级分配
a.表格数据
任务类型 NPU分配 优先级 并发策略
开标时刻文档解析 Qwen2.5-72B(2x TP) 最高 独占2卡
开标时刻多模态分析 Qwen2.5-VL-32B(1x TP) 高 独占1卡
澄清问答 Qwen2.5-72B 中 共享2卡（与文档解析共享）
历史检索 Qwen2-VL-7B 低 可与其他任务共享
b.说明
NPU隔离配置：
c.代码示例
---
# 环境变量配置
export ASCEND_RT_VISIBLE_DEVICES="0,1,2,3" # 开标时刻：前4卡全部分配
export ASCEND_RT_VISIBLE_DEVICES="7" # 历史检索：使用单独卡
# 启动时分配NPU
for i in 0 1 2 3; do
echo "Allocating NPU $i to model service"
sleep 1
done
---
b.批处理优化
a.说明
动态批处理策略：
b.代码示例
---
from celery import chain, group
def smart_batch_processing(
tasks: List[dict],
batch_size: int = 5 # 动态调整批次大小
max_concurrent: int = 20 # 最大并发度
) -> list:
"""智能批处理"""
# 分组任务
task_groups = []
for i in range(0, len(tasks), batch_size):
task_groups.append(tasks[i:i+batch_size])
# 为每个分组创建链式任务
for group in task_groups:
# 并行处理组内任务
result = group(chain(
group, # 任务组
link=chain(process_task.s(), result_callback=process_result) # 链接
)
return result
# 动态调整批次大小（基于队列积压情况）
def dynamic_batch_size():
"""根据队列积压动态调整批次大小"""
pending = celery.control.inspect().pending('high_priority')
if len(pending) > 100:
return 3 # 积压严重，减少批次大小
elif len(pending) > 50:
return 5 # 积压中等，正常批次
else:
return 10 # 积压少，增加批次大小
---
b.KV Cache优化
a.说明
KV Cache策略：
b.代码示例
---
from transformers import AutoModelForCausalLM
# 为Qwen2.5-72B配置KV Cache
model_cache = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen2.5-72B-Instruct",
torch_dtype="auto",
device_map="auto" # 自动选择设备
trust_remote_code=True,
cache_dir="/app/model_cache/qwen72b" # KV Cache目录
)
# KV Cache配置
model_cache.config.kv_cache = {
'max_batch_size': 4, # 最大批处理大小
'max_cache_size': 100, # 最大缓存条目数
'num_gpu_blocks': 1, # GPU块数
'num_cpu_threads': 1, # CPU线程数
}
# 推理时的KV Cache使用
with torch.no_grad():
# 1. 预加载到KV Cache
_ = model_cache(inputs=[input_ids[0:5]], cache_dir="/app/model_cache/qwen72b")
# 2. 后续推理使用Cache加速
outputs = model_cache.generate(
input_ids=input_ids[5:10],
max_new_tokens=4096,
temperature=0.7,
top_k=1
)
---
c.说明
---
e.Redis缓存策略
a.缓存层次设计
a.说明
三层缓存策略：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ L1: 应用缓存 (Redis) │
│ 命中: 内存，极速 │
├────────────────────────────────────────────────────┤
│ 澄清问题结果缓存 │
│ └─ Key: "clarification:{question_hash}" │
│ TTL: 1小时 │
│ 命中: <1MB │
├────────────────────────────────────────────────────┤
│ 向量检索结果缓存 │
│ └─ Key: "search:{query_hash}:{top_k}" │
│ TTL: 10分钟 │
│ 命中: <5MB │
│ Top-K: 5, 10, 20 │
├────────────────────────────────────────────────────┤
│ 招标元数据缓存 │
│ └─ Key: "tender:{tender_id}" │
│ TTL: 2小时 │
│ 命中: <1MB │
├────────────────────────────────────────────────────┤
│ 项目配置缓存 │
│ └─ Key: "config:{config_hash}" │
│ TTL: 30分钟 │
└────────────────────────────────────────────┘
---
b.缓存实现
a.说明
缓存服务封装：
b.代码示例
---
import redis
import json
import hashlib
import pickle
from typing import Any, Optional
class CacheService:
"""统一缓存服务"""
def __init__(self, redis_url: str):
self.redis = redis.from_url(redis_url)
self.default_ttl = {
'clarification': 3600, # 1小时
'search': 600, # 10分钟
'tender_metadata': 7200, # 2小时
'project_config': 1800, 30分钟
}
async def get_or_set(
self,
key: str,
value: Any = None,
ttl: Optional[int] = None,
deserialize: bool = False
) -> Any:
"""获取或设置缓存"""
# 从缓存获取
if value is None:
cached = await self.redis.get(key)
if cached:
if deserialize:
try:
return pickle.loads(cached)
except:
return json.loads(cached)
else:
return cached.decode('utf-8')
# 设置缓存
if value is not None:
if serialize:
serialized = pickle.dumps(value)
else:
serialized = json.dumps(value, ensure_ascii=False)
# 使用默认TTL
expire = ttl or self._get_default_ttl(key)
await self.redis.setex(
name=key,
value=serialized,
time=expire
)
return value
def _get_default_ttl(self, key: str) -> int:
"""根据键名获取默认TTL"""
if 'clarification:' in key:
return self.default_ttl['clarification']
elif 'search:' in key:
return self.default_ttl['search']
elif 'tender:' in key:
return self.default_ttl['tender_metadata']
elif 'config:' in key:
return self.default_ttl['project_config']
else:
return 300 # 默认5分钟
async def cache_search_results(
self,
query_hash: str,
results: List[dict],
top_k: int = 20
):
"""缓存搜索结果（Top-K分层缓存）"""
# 为每个Top-K创建缓存键
for k in range(1, top_k + 1):
key = f"search:{query_hash}:{k}"
await self.get_or_set(key, results[k-1])
# 缓存主键（用于快速检查是否存在）
await self.get_or_set(
f"search:{query_hash}:main",
results[:top_k] # 缓存所有Top-20结果
ttl=600 # 10分钟
)
---
c.缓存穿透保护
a.说明
缓存穿透防护：
b.代码示例
---
import asyncio
class CacheService:
def __init__(self):
self.loading_locks = {} # 正在加载的键
async def get_with_lock_protection(
self,
key: str,
fetch_func: callable
) -> Any:
"""带锁保护的缓存获取（防止缓存穿透）"""
# 检查是否正在加载
if key in self.loading_locks:
# 等待其他加载完成
for _ in range(10): # 最多等1秒
await asyncio.sleep(0.1)
if key not in self.loading_locks:
break
else:
raise Exception("Cache lock timeout")
# 标记为加载中
self.loading_locks[key] = True
try:
# 尝试从缓存获取
cached = await self.redis.get(key)
# 缓存命中
if cached:
self.loading_locks[key] = False
return await self.deserialize(cached)
# 缓存未命中，调用数据源
result = await fetch_func()
# 写入缓存（仅缓存第一个未命中）
if key in self.loading_locks:
await self.redis.setex(
name=key,
value=self.serialize(result),
time=self._get_default_ttl(key)
)
self.loading_locks[key] = False
return result
except Exception as e:
# 异常时不标记为加载中（允许重试）
if key in self.loading_locks:
self.loading_locks[key] = False
raise e
---
c.说明
---
f.数据库优化
a.PostgreSQL优化
a.连接池优化
a.说明
连接池配置：
b.代码示例
---
from sqlalchemy import create_engine, pool
from sqlalchemy.orm import sessionmaker, scoped_session
# 连接池配置
engine = create_engine(
'postgresql://user:password@localhost/evaluation_db',
pool_size=20, # 应对10并发
max_overflow=10, # 最大溢出连接数
pool_pre_ping=True, # 连接前检查
pool_recycle=3600, # 连接回收时间（1小时）
echo=False
)
SessionLocal = scoped_session(
sessionmaker(
autocommit=False,
autoflush=False
)
)
# 使用示例
with SessionLocal() as session:
# 批量查询
results = session.query(Document).filter(...).all()
# 查询后自动回滚（失败时）
session.commit() # 手动提交
---
b.查询优化
a.说明
索引优化：
b.代码示例
---
-- 为常用查询创建复合索引
-- 标书项目查询
CREATE INDEX idx_tenders_project_upload_time
ON t_tenders(project_id)
WHERE upload_status = 'indexed'
ORDER BY upload_timestamp DESC;
-- 标书解析结果查询
CREATE INDEX idx_parse_results_tender_status
ON t_parse_results(tender_id, parse_status)
WHERE parse_status IN ('pending', 'processing')
ORDER BY start_time ASC;
-- 评分查询（按项目+供应商）
CREATE INDEX idx_scores_project_tender_expert
ON t_scores(project_id, tender_id, expert_id)
ORDER BY project_id, expert_id;
-- 审计日志查询（按用户+时间倒序）
CREATE INDEX idx_audit_logs_user_created
ON t_audit_logs(user_id, created_at DESC);
---
c.说明
批量操作：
d.代码示例
---
from sqlalchemy import insert, update, select
from sqlalchemy.dialects.postgresql import insert
from contextlib import contextmanager
@contextmanager
def batch_operation():
"""批量操作上下文管理器"""
with SessionLocal() as session:
yield session
try:
yield
session.commit()
session.expunge_all() # 清理Session（避免内存泄漏）
except Exception as e:
session.rollback()
raise e
# 批量插入标书
async def batch_create_tenders(tenders_data: List[dict]):
"""批量创建标书记录"""
with batch_operation() as session:
for tender_data in tenders_data:
stmt = insert(Tender).values(**tender_data)
session.execute(stmt)
---
b.向量数据库优化
a.ChromaDB优化
a.说明
HNSW索引配置：
b.代码示例
---
import chromadb
# 创建HNSW索引（高效近似最近邻搜索）
chroma_client = chromadb.PersistentClient(
path="/data/chroma",
settings=chromadb.Settings(
anonymized_telemetry=False, # 性能优化
allow_reset=True, # 允许重置
)
)
# 创建集合（使用HNSW）
collection = chroma_client.get_or_create_collection(
name="current_project",
metadata={
"hnsw": "space": "cosine", # 余弦空间
"hnsw:construction_ef": 200 # 构建效率参数
}
)
# 添加文档
collection.add(
documents=[paragraph_text],
metadatas=[{
"document_id": doc_id,
"page_number": page_num,
"section_number": section_num,
"chunk_type": "paragraph"
}],
embeddings=[embedding_vector],
ids=[paragraph_id]
)
# 查询（使用HNSW）
results = collection.query(
query_embeddings=[query_embedding],
n_results=20, # Top-20
where={
"document_id": {"$ne": None}, # 排除空文档
}
)
---
b.元数据过滤优化
a.说明
元数据复合查询：
b.代码示例
---
def hybrid_search(
query_embedding: np.ndarray,
metadata_filters: dict,
top_k: int = 20
) -> List[dict]:
"""混合检索（向量+元数据）"""
# 1. 向量检索（语义相似度）
vector_results = collection.query(
query_embeddings=[query_embedding],
n_results=50, # Top-50
where=metadata_filters # 元数据过滤
)
# 2. 元数据加权
weighted_results = []
for result in vector_results:
# 时间权重（近期项目权重更高）
time_weight = calculate_time_weight(result['upload_date'])
# 项目类型权重（同类型权重更高）
type_weight = calculate_type_weight(result['project_type'])
# 供应商信誉权重
supplier_weight = calculate_supplier_weight(result['credit_rating'])
# 综合相似度
weighted_score = (
result['similarity'] * 0.6 +
time_weight * 0.2 +
type_weight * 0.1 +
supplier_weight * 0.1
)
weighted_results.append({
**result': result,
'weighted_score': weighted_score
})
# 3. 按综合相似度排序
weighted_results.sort(key=lambda x: x['weighted_score'], reverse=True)
# 返回Top-20
return weighted_results[:top_k]
---
c.说明
---
g.实时进度推送
a.WebSocket架构
a.连接管理
a.说明
WebSocket服务封装：
b.代码示例
---
from fastapi import WebSocket, WebSocketDisconnect
from typing import Dict, Set
import logging
class WebSocketManager:
"""WebSocket连接管理器"""
def __init__(self):
self.active_connections: Dict[str, WebSocket] = {}
self.project_channels: Dict[str, Set[str]] = {} # 项目ID -> 连接集合
async def connect(
self,
websocket: WebSocket,
project_id: str
):
"""专家连接到项目频道"""
channel_id = f"project:{project_id}"
# 添加到连接池
self.active_connections[websocket] = websocket
# 添加到项目频道
if channel_id not in self.project_channels:
self.project_channels[channel_id] = set()
self.project_channels[channel_id].add(websocket)
logging.info(f"Expert connected to {channel_id}")
# 广播加入
if channel_id in self.project_channels:
await websocket.send_text(
f"Expert connected to project {project_id}"
)
async def disconnect(
self,
websocket: WebSocket,
project_id: str
):
"""专家断开连接"""
channel_id = f"project:{project_id}"
# 从连接池移除
del self.active_connections[websocket]
# 从项目频道移除
if channel_id in self.project_channels and websocket in self.project_channels[channel_id]:
self.project_channels[channel_id].discard(websocket)
logging.info(f"Expert disconnected from {channel_id}")
async def broadcast_to_project(
self,
project_id: str,
message: dict
):
"""向项目所有专家广播消息"""
channel_id = f"project:{project_id}"
if channel_id in self.project_channels:
# 向该频道所有连接发送消息
for connection in list(self.project_channels[channel_id]):
try:
await connection.send_json(message)
except:
# 连接失败，从频道移除
if connection in self.project_channels[channel_id]:
self.project_channels[channel_id].discard(connection)
async def send_clarification_result(
self,
expert_websocket: WebSocket,
project_id: str,
tender_id: int,
result: dict
):
"""发送澄清结果给指定专家"""
message = {
'type': 'clarification_result',
'data': result
}
await expert_websocket.send_json(message)
async def send_tender_status(
self,
project_id: str,
tender_id: int,
status: str,
progress: float
):
"""发送标书解析状态"""
message = {
'type': 'tender_status',
'data': {
'tender_id': tender_id,
'status': status,
'progress': progress
}
}
await self.broadcast_to_project(project_id, message)
---
b.心跳机制
a.说明
心跳配置：
b.代码示例
---
from fastapi import WebSocket
import asyncio
class WebSocketManager:
def __init__(self):
self.heartbeats: Dict[str, asyncio.Task] = {}
async def start_heartbeat(
self,
websocket: WebSocket,
channel_id: str,
interval: int = 30 # 30秒心跳
):
"""启动心跳检测"""
task = asyncio.create_task(self._heartbeat_loop, websocket, channel_id, interval)
self.heartbeats[channel_id] = task
await task
async def _heartbeat_loop(
self,
websocket: WebSocket,
channel_id: str,
interval: int
):
"""心跳循环"""
try:
while True:
await asyncio.sleep(interval)
# 发送心跳ping
ping_message = {
'type': 'ping',
'timestamp': datetime.now().isoformat()
}
await websocket.send_json(ping_message)
except WebSocketDisconnect:
logging.info(f"WebSocket disconnected from {channel_id} during heartbeat")
break
# 清理心跳任务
if channel_id in self.heartbeats:
self.heartbeats[channel_id].cancel()
del self.heartbeats[channel_id]
---
c.重连策略
a.说明
自动重连机制：
b.代码示例
---
import asyncio
class WebSocketManager:
RECONNECT_DELAYS = [5, 10, 30, 60] # 重连延迟：5s, 10s, 30s, 60s
MAX_RECONNECT_ATTEMPTS = 5 # 最多重试5次
def __init__(self):
self.reconnect_attempts = {}
async def auto_reconnect(
self,
project_id: str,
original_uri: str
):
"""自动重连"""
channel_id = f"project:{project_id}"
if channel_id not in self.reconnect_attempts:
self.reconnect_attempts[channel_id] = {
'attempts': 0,
'original_uri': original_uri
}
for delay in self.RECONNECT_DELAYS:
await asyncio.sleep(delay)
# 尝试重连
try:
new_websocket = await connect(original_uri)
await new_websocket.send_json({
'type': 'reconnect',
'message': 'Reconnected successfully'
})
# 重连成功，重置计数
self.reconnect_attempts[channel_id]['attempts'] = 0
break
# 移除失败连接
if channel_id in self.project_channels:
old_websocket = self.project_channels[channel_id].pop()
old_websocket.close()
except Exception as e:
logging.warning(f"Reconnect attempt {self.reconnect_attempts[channel_id]['attempts'] + 1} failed for {channel_id}: {e}")
# 超过最大重试次数
if self.reconnect_attempts[channel_id]['attempts'] >= self.MAX_RECONNECT_ATTEMPTS:
logging.error(f"Max reconnect attempts ({self.MAX_RECONNECT_ATTEMPTS}) reached for {channel_id}")
# 移除重连记录
del self.reconnect_attempts[channel_id]
---
b.进度推送格式
a.说明
进度消息类型：
b.代码示例
---
// 标书解析进度
{
"type": "tender_parsing_progress",
"data": {
"tender_id": 12345,
"total_pages": 300,
"parsed_pages": 150,
"progress": 50.0, // 50%完成
"stage": "parsing_chunk",
"details": {
"chunk_1_10": {"status": "completed", "pages": "1-30"},
"chunk_2_10": {"status": "processing", "pages": "31-60"},
"chunk_3_10": {"status": "pending", "pages": "61-90"},
...
}
}
}
// AI澄清结果
{
"type": "clarification_result",
"data": {
"question": "供应商A的技术参数是否符合600W要求？",
"result_count": 3,
"timestamp": "2026-01-16T10:15:00Z",
"items": [
{
"page": 45,
"section": "3.2.1",
"section_title": "技术规格",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W，效率95%",
"original_text": "本产品功率500W，效率95%"
}
]
}
}
// 专家打分完成
{
"type": "scoring_completed",
"data": {
"supplier_id": 567,
"total_score": 87.0,
"rank": 1,
"timestamp": "2026-01-16T10:20:00Z"
}
}
---
c.说明
---
h.性能测试策略
a.压力测试方案
a.测试场景
a.表格数据
测试场景 并发量 数据量 持续时间 目标
开标时刻 10个并发 500MB-1GB 5分钟 <5分钟
澄清高峰 10专家并发提问 100次查询 10分钟 <3秒响应
历史检索 5个并发历史查询 5000个标书 30分钟 <1秒检索
报告生成 1次 10个供应商PDF 2分钟 <30秒生成
b.测试指标
a.说明
关键性能指标：
b.表格数据
指标 目标值 测试方法 验收标准
API响应时间(P50) <100ms Apache Bench Apache Bench 100次请求
解析时间(300页) <3分钟 真实测试 真实10个标书测试
向量检索时间 <1秒 Top-20查询 真实历史数据测试
NPU推理时间 <2秒 Qwen72B推理 真实AI模型测试
WebSocket延迟 <50ms 往返延迟 真实WebSocket测试
数据库查询(P95) <500ms 复杂查询 真实数据量测试
缓存命中率 >80% 实际流量测试 真实用户操作测试
c.说明
---
b.性能基准测试
a.说明
基准测试脚本：
b.代码示例
---
import time
import asyncio
import aiohttp
async def benchmark_api_latency():
"""API延迟基准测试"""
# 预热请求100次
latencies = []
for _ in range(100):
start = time.time()
async with aiohttp.ClientSession() as session:
async with session.post(
'http://localhost:8080/api/search',
json={"query": "test query"}
) as response:
end = time.time()
latencies.append((end - start) * 1000) # 转换为毫秒
# 计算P50/P95/P99
latencies.sort()
p50 = latencies[49]
p95 = latencies[94]
p99 = latencies[98]
print(f"P50: {p50}ms, P95: {p95}ms, P99: {p99}ms")
async def benchmark_vector_search():
"""向量检索基准测试"""
query_embedding = generate_test_embedding()
latencies = []
for _ in range(20):
start = time.time()
# 模拟检索
results = chroma_client.query(
query_embeddings=[query_embedding],
n_results=20
)
end = time.time()
latencies.append((end - start) * 1000)
# 计算P50/P95
latencies.sort()
p50 = latencies[9]
p95 = latencies[18]
print(f"Vector Search P50: {p50}ms, P95: {p95}ms")
async def benchmark_npu_inference():
"""NPU推理基准测试"""
prompt = "Test inference"
latencies = []
for _ in range(10):
start = time.time()
result = qwen72b.generate(
prompt=prompt,
max_new_tokens=512,
temperature=0.7
)
end = time.time()
latencies.append((end - start) * 1000)
# 计算P50/P95
latencies.sort()
p50 = latencies[4]
p95 = latencies[8]
print(f"NPU Inference P50: {p50}ms, P95: {p95}ms")
---
c.说明
---
i.总结
a.核心优化策略
a.表格数据
优化方向 关键技术 预期收益
并发处理 预启动Worker池 + 优先级队列 5分钟 → 3分钟
文档解析 分页并行 + 流式处理 3-5分钟 → 5分钟
AI分析 向量缓存 + Qwen2.5-72B KV Cache 10秒 → 3秒
数据库 连接池 + 批量操作 + 复合索引 不优化 → 优化30%
缓存策略 三层缓存 + 缓存穿透保护 不优化 → 提升80%命中率
NPU资源 动态分配 + KV Cache 40%利用率 → 70%利用率
b.性能目标
a.说明
开标时刻性能目标（10个标书）：
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
b.✅ 10个标书解析完成时间：<5分钟
c.✅ 澄清问题平均响应时间：<3秒
d.✅ 系统可用性：>99%
e.✅ Worker使用率：>80%
05.法律方向的解读
a.AI在招投标领域的法律定位
a.AI系统的法律角色界定
a.AI作为"辅助工具"vs"决策主体"
a.说明
中国法律框架下的AI定位：
b.表格数据
角色 法律定义 责任归属 合规要求
决策主体 依法独立行使评审权的自然人或组织 评标委员会 承担最终评审法律责任
AI辅助工具 为决策提供参考依据的技术系统 本系统（AI澄清系统） 不承担法律责任，提供参考依据
c.说明
关键法律原则：
1.AI不得替代人类决策
2.AI责任明确化
3.AI可追溯与可审计
d.法律依据：《招标投标法》第三十八条（评标委员会依法独立评审）
e.AI仅作为技术工具，提供数据分析、内容定位、对比等辅助功能
f.最终评审结论必须由评标委员会做出，AI系统无权做出具有法律效力的评审决定
g.AI系统的开发者、运营者对AI输出的准确性负责
h.AI系统本身不承担招标投标的法律责任
i.评标委员会对最终评审结论承担法律责任
j.AI系统的输出必须有明确的来源标注（如引用的条款、页码、章节）
k.必须建立完整的审计日志，记录AI的输入、输出、调用时间、模型版本
l.必须支持人工复核和异议处理
b.本系统的法律定位
a.说明
系统定位：AI澄清工具（辅助打分）
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 法律责任主体 │
│ 评标委员会（专家） │
│ │
│ ┌───────────────────────────────────┐ │
│ │ AI澄清系统（本系统） │ │
│ │ │ │
│ │ • 提供参考依据 │ │
│ │ • 不承担法律责任 │ │
│ │ • 输出仅供参考 │ │
│ │ │ │
│ └───────────────────────────────────┘ │
│ │
│ 专家基于AI澄清结果手动打分（承担法律责任） │
└─────────────────────────────────────────────────────┘
---
c.说明
本系统的核心特征：
---
d.✅ AI仅提供参考依据（指出不符合指标的地方）
e.✅ 专家完全自主判断（基于AI澄清结果）
f.✅ 系统仅统计和展示（不参与任何决策）
g.✅ 评标委员会对最终结果承担法律责任
b.中国法律法规对AI应用的要求
a.《招标投标法》相关条款
a.评标委员会独立评审原则
a.说明
第三十八条：评标委员会依法独立评审，对投标文件进行审查和比较，不得有下列情形之一：
1.任何单位和个人不得非法干预评标活动
2.评标委员会成员不得私下接触投标人
3.不得向外界泄露评标过程和结果
本系统的合规性：
b.✅ AI作为辅助工具，不干预评标活动
c.✅ 评标委员会完全自主评审
d.✅ AI仅提供参考依据（页码、章节号、原文对比）
e.✅ 不泄露评标过程和结果（完整审计日志）
b.电子招标投标的相关规定
a.说明
《电子招标投标办法》相关要求：
b.表格数据
要求 法律条文 本系统实施
电子招标平台应当保证数据安全 第八条 AES-256-GCM加密存储
应当建立健全评标过程和结果的信息公开和保密制度 第十五条 审计日志、权限控制
应当记录评标过程和结果，保存不少于15年 第三十三条 审计日志保存10年
c.说明
本系统的实施：
d.✅ 数据加密存储（AES-256-GCM）
e.✅ 建立保密制度（RBAC权限控制）
f.✅ 完整审计日志（保存10年，符合等保二级要求）
g.✅ 信息公开制度（评标结束后可查询结果，但过程保密）
b.《政府采购法》相关条款
a.政府采购AI应用支持
a.说明
国家政策支持：
b.表格数据
政策文件 核心内容 适用性
国务院《"人工智能+"行动方案》(2024） 明确将"AI+治理能力"列为六大深度融合领域之一 ✅ 支持本系统
国办发〔2024〕21号文 要求"加快推广数字智技术应用，推动招标投标与人工智能融合发展" ✅ 支持本系统
《生成式人工智能服务管理暂行办法》(2023） 采取"包容审慎"原则，鼓励AI创新发展 ✅ 支持本系统
c.说明
关键政策解读：
1.国家鼓励AI在政务场景应用
2.电子招标投标与AI融合
3.包容审慎原则
d.国务院《"人工智能+"行动方案》明确将"AI+治理能力"列为深度融合领域
e.要求"打造精准识别需求、主动规划服务、全程智能办理的政务服务新模式"
f.本系统符合这一政策导向
g.国办发〔2024〕21号文明确要求"推动招标投标与人工智能融合发展"
h.本系统是"招标投标"与"人工智能"融合的具体实践
i.《生成式人工智能服务管理暂行办法》采取"包容审慎"原则
j.鼓励AI创新发展，同时要求安全合规
k.本系统在创新的同时，严格遵守安全合规要求
c.《生成式人工智能服务管理暂行办法》相关条款
a.核心合规要求
a.说明
第二十一条：生成式人工智能服务提供者应当承担下列义务：
1.按照《网络安全法》《数据安全法》《个人信息保护法》等法律、行政法规的规定
2.采取有效措施防止生成式人工智能服务生成违法信息
3.建立健全投诉举报机制
4.配合监管部门的监督检查
本系统的合规性：
b.✅ 符合《网络安全法》（等保二级要求）
c.✅ 符合《数据安全法》（数据分类分级、加密存储）
d.✅ 符合《个人信息保护法》（最小必要原则）
e.✅ 建立投诉举报机制（AI输出异议处理流程）
b.AI服务的用户义务
a.说明
第二十五条：生成式人工智能服务使用者应当遵守下列规定：
1.不得利用生成式人工智能服务从事违法活动
2.不得进行危害网络安全、数据安全、个人信息权益的活动
3.不得利用生成式人工智能服务从事违背公序良俗的活动
本系统的实施：
---
b.✅ 专家使用AI服务仅用于澄清目的（指出不符合指标）
c.✅ 不利用AI从事违法活动
d.✅ 遵守网络安全、数据安全规定
e.✅ 符合公序良俗要求
c.本系统的合规性分析
a.AI澄清系统的合规性
a.AI仅提供参考依据的设计
a.说明
合规性分析：
b.表格数据
维度 本系统设计 合规依据 合规性
AI输出内容 仅包含页码、章节号、原文对比 符合"辅助工具"定位 ✅ 合规
AI不做判断 Prompt明确限制"仅指出不符合指标的地方，不做判断或纠正" 符合"辅助工具"不替代人类决策 ✅ 合规
AI不做评分 仅返回定位信息，不提供任何评分建议 符合"辅助工具"提供参考依据 ✅ 合规
AI不做建议 仅返回原文对比，不提供修改建议 符合"辅助工具"辅助性 ✅ 合规
c.说明
核心设计原则：
1.Prompt工程明确约束
2.Pydantic模型输出验证
3.前端明确标注
d.明确限制AI输出为"仅指出不符合指标的地方"
e.明确禁止AI做出"符合"、"不符合"的判断
f.明确禁止AI提供任何修改建议或评分建议
g.严格验证AI输出格式（仅包含page、section、section_title、tender_requirement、bid_content、original_text、document_id）
h.防止AI生成超出约束的输出
i.前端界面明确标注"AI仅供参考"
j.前端仅展示原文对比，不提供任何修改入口
k.避免用户误解AI输出具有法律效力
b.专家自主判断的保障
a.说明
合规性分析：
b.表格数据
维度 本系统设计 合规依据 合规性
专家手动打分 专家基于AI澄清结果完全自主判断 《招标投标法》第三十八条（评标委员会依法独立评审） ✅ 合规
专家复核AI发现 专家可以接受或拒绝AI发现 《电子招标投标办法》（专家专业判断） ✅ 合规
专家承担法律责任 评标委员会对最终评审结论承担法律责任 《招标投标法》第三十八条 ✅ 合规
系统不参与决策 系统仅统计和展示，不参与任何决策 符合"AI辅助工具"定位 ✅ 合规
c.说明
人机协同机制：
1.AI提供参考 → 专家复核 → 专家自主判断 → 系统统计
2.专家可以完全忽略AI发现（认为AI定位不准确）
3.专家可以部分接受AI发现（作为参考）
4.系统不验证专家判断（完全尊重专家自主权）
b.完整审计追踪的必要性
a.审计日志的法律要求
a.说明
《电子招标投标办法》第十三条：电子招标平台应当记录评标过程和结果，保存不少于15年。
本系统的实施：
b.✅ 记录所有AI调用（输入、输出、调用时间、模型版本）
c.✅ 记录所有专家操作（提问、打分、复核）
d.✅ 记录所有系统操作（文件上传、索引建立、报告生成）
e.✅ 保存审计日志10年（超过《电子招标投标办法》要求的15年）
f.✅ 审计日志不可篡改（使用区块链或数字签名技术）
b.审计日志的内容
a.说明
审计日志必须包含：
b.表格数据
数据项 说明 法律依据
AI调用日志 输入（用户提问、招标要求）、输出（澄清结果）、调用时间、模型版本 《生成式人工智能服务管理暂行办法》
专家操作日志 专家ID、操作类型（提问/打分/复核）、操作时间、操作结果 《电子招标投标办法》
系统操作日志 操作类型（文件上传/索引建立/报告生成）、操作时间、操作结果 《网络安全法》
IP地址和User-Agent 用于追溯和安全管理 《网络安全法》
异常日志 系统异常、AI异常、网络异常 《网络安全法》
c.说明
审计日志保留要求：
本系统选择：保留10年（满足所有要求）
---
d.《电子招标投标办法》：保存不少于15年
e.《网络安全法》（等保二级）：保存不少于6个月
f.《数据安全法》：关键日志保留不少于3年
d.国际最佳实践对比
a.EU AI Act合规性分析
a.AI系统风险分类
a.说明
EU AI Act风险分类：
b.表格数据
风险等级 定义 本系统归类 合规要求
不可接受风险 禁止使用 本系统不在此类 N/A
高风险 影响安全或基本权利的系统，要求严格监管 本系统是辅助工具，不决策 中等风险（需要透明度、人机协同）
有限风险 要求透明度 本系统需要透明度 有限风险（需要透明度）
最小风险 无特殊要求 N/A N/A
c.说明
本系统作为"高风险AI系统"的合规要求：
1.风险管理与缓解（Article 9）
2.数据与数据治理（Article 10）
3.技术文档（Article 11）
4.透明度提供（Article 13）
5.人工监督（Article 14）
本系统的实施：
d.建立风险管理系统
e.定期评估风险
f.采取缓解措施
g.数据质量保证
h.数据治理策略
i.偏见检测与纠正
j.技术文档公开
k.自动记录保持
l.安全措施说明
m.向用户提供AI使用说明
n.公开AI系统的工作方式
o.提供人工干预机制
p.设计和实施人工监督
q.人工监督措施
r.监督人员培训
s.✅ 建立风险管理制度（识别AI输出不准确、专家过度依赖等风险）
t.✅ 数据质量保证（历史标书数据清洗、去重）
u.✅ 技术文档公开（本设计文档公开、API文档公开）
v.✅ 透明度提供（AI使用说明、工作方式公开）
w.✅ 人工监督机制（专家复核机制、系统不验证专家判断）
b.UK PPN 017透明度要求
a.说明
UK PPN 017要求：
b.表格数据
要求 本系统实施 合规性
AI使用透明度 公开AI在评标中的使用情况 ✅ 合规（系统界面明确标注"AI仅供参考"）
供应商AI使用申报 在招标文件中询问供应商是否使用AI ✅ 合规（在招标文件中添加AI使用说明要求）
算法透明度 说明AI系统的基本原理和局限性 ✅ 合规（本设计文档详细说明AI系统工作原理）
c.说明
本系统的实施：
1.AI使用透明度
2.算法透明度
3.人工监督机制
d.在用户界面明确标注"AI澄清系统：仅提供参考依据，不做判断或纠正"
e.在评标报告中说明AI系统的作用（辅助工具、仅供参考）
f.本设计文档公开AI系统的工作原理、Prompt模板、输出格式限制
g.技术文档详细说明AI模型的局限性（不保证准确性、可能产生错误）
h.明确专家复核机制
i.明确系统不验证专家判断的机制
j.提供AI输出异议处理流程
c.OECD AI原则对比
a.说明
OECD AI原则（2025更新）：
b.表格数据
原则 本系统实施 合规性
原则1：包容性增长、可持续发展与福祉 AI辅助提升效率，促进公平公正 ✅ 合规
原则2：以人为本的价值观与公平性 专家自主判断，AI仅辅助 ✅ 合规
原则3：透明度与解释性 AI输出可追溯，专家可复核 ✅ 合规
原则4：鲁棒性、安全性与保障 数据安全保护，审计日志 ✅ 合规
原则5：问责制 评标委员会承担法律责任，AI不承担 ✅ 合规
c.说明
本系统的实施：
1.包容性增长：AI辅助提升评标效率，减少专家工作量
2.以人为本：尊重专家判断，AI仅提供参考依据
3.透明度：AI输出可追溯，审计日志完整
4.鲁棒性：数据加密、访问控制、备份恢复
5.问责制：明确评标委员会的法律责任，AI不承担
---
e.本系统的合规性保障措施
a.明确AI辅助定位
a.前端明确标注
a.说明
实施方式：
b.代码示例
---
<!-- 系统界面顶部标注 -->
<el-alert type="info" :closable="false">
<template #title>
<i class="el-icon-info-circle"></i>
<span>AI澄清系统：辅助工具</span>
</template>
<template #default>
<p><strong>AI仅提供参考依据（页码、章节号、原文对比），不做判断或纠正</strong></p>
<p><strong>专家需自主判断并打分，评标委员会对最终结果承担法律责任</strong></p>
<el-tag type="info">仅供参考</el-tag>
</template>
</el-alert>
---
c.说明
标注要求：
1.✅ 明确"AI辅助工具"定位
2.✅ 明确AI"仅提供参考依据"
3.✅ 明确专家"自主判断"
4.✅ 明确评标委员会"承担法律责任"
5.✅ 明确AI输出"仅供参考"
b.输出格式限制
a.说明
Prompt工程限制：
b.代码示例
---
Prompt模板（明确约束）：
你是一个专业的评标澄清助手。
任务：分析标书内容，**仅指出不符合招标文件要求的指标的地方**，**不做判断或纠正**。
输入：
1. 招标文件要求：{requirements}
2. 标书相关段落：{relevant_paragraphs}
输出格式（严格遵守）：
{
"non_compliant_items": [
{
"page": 45,
"section": "3.2.1",
"section_title": "技术规格",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W，效率95%",
"original_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准",
"document_id": "tender_A.pdf"
}
]
}
重要提示（严格遵守）：
- **仅指出不符合的地方**，**不判断是否符合**
- **仅返回原文对比**，**不提供修改建议**
- **确保所有信息都能在原文中找到**
- **不做任何技术方案建议**
- **不做任何符合性评分**
---
c.说明
Pydantic模型验证：
d.代码示例
---
from pydantic import BaseModel, Field, validator
from typing import List
class NonCompliantItem(BaseModel):
"""不符合项（仅包含定位信息）"""
page: int = Field(..., ge=1, description="页码")
section: str = Field(..., description="章节号")
section_title: str = Field(..., description="章节标题")
tender_requirement: str = Field(..., description="招标要求")
bid_content: str = Field(..., description="标书内容（原文摘录）")
original_text: str = Field(..., description="原文完整摘录（保留上下文）")
document_id: str = Field(..., description="文档ID")
class ClarificationResponse(BaseModel):
"""澄清响应"""
non_compliant_items: List[NonCompliantItem] = Field(
...,
description="不符合项列表（仅包含定位信息）",
min_items=0 # 允许空列表
)
@validator('non_compliant_items')
def validate_items(cls, v):
"""验证输出仅包含定位信息"""
# 禁止字段
forbidden_fields = [
'compliance_status', 'score', 'judgment',
'recommendation', 'suggestion', 'modified_text'
]
for item in v:
for field in forbidden_fields:
if field in item.dict():
raise ValueError(f"禁止字段: {field}")
return v
---
b.建立人机协同机制
a.专家复核机制
a.说明
复核流程：
b.代码示例
---
AI澄清结果
│
├─ 前端展示澄清结果（页码、章节号、原文对比）
│
├─ 专家复核
│ ├─ 查看：专家可以查看AI发现
│ ├─ 接受：专家接受AI发现，标记为"已复核"
│ ├─ 拒绝：专家拒绝AI发现，填写拒绝原因
│ └─ 忽略：专家可以选择忽略AI发现
│
└─ 系统记录
├─ 记录专家操作（接受/拒绝/忽略）
├─ 记录拒绝原因（可选）
└─ 审计日志保存
---
c.说明
复核操作记录：
d.表格数据
操作类型 说明 法律依据
接受 专家接受AI发现 《电子招标投标办法》（专家专业判断）
拒绝 专家拒绝AI发现，填写拒绝原因 《电子招标投标办法》（专家专业判断）
忽略 专家选择忽略AI发现 无特殊要求，尊重专家自主权
b.系统不验证专家判断
a.说明
系统行为约束：
b.✅ 系统不验证专家评分的合理性
c.✅ 系统不验证专家是否复核AI发现
d.✅ 系统完全尊重专家自主判断权
e.✅ 系统仅统计和展示专家评分结果
c.完善审计日志系统
a.审计日志架构
a.说明
审计日志三层设计：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 应用层审计日志 │
│ (FastAPI中间件自动记录) │
├────────────────────────────────────────────────────┤
│ 业务层审计日志 │
│ (业务逻辑层主动记录) │
├────────────────────────────────────────────────────┤
│ 数据层审计日志 │
│ (PostgreSQL审计表 + 归档) │
└─────────────────────────────────────────────────────┘
---
c.说明
审计日志类型：
d.表格数据
日志类型 记录内容 保留时间 法律依据
AI调用日志 输入、输出、调用时间、模型版本 10年 《生成式人工智能服务管理暂行办法》
专家操作日志 提问、打分、复核、时间 10年 《电子招标投标办法》
系统操作日志 文件上传、索引建立、报告生成 10年 《网络安全法》（等保二级）
异常日志 系统异常、AI异常、网络异常 10年 《网络安全法》（等保二级）
访问日志 登录、登出、权限变更 2年 《网络安全法》（等保二级）
b.审计日志内容要求
a.说明
AI调用日志：
b.代码示例
---
{
"audit_id": "audit_ai_202601160001",
"user_id": 567,
"username": "expert_张三",
"action": "ai_clarification_query",
"resource_type": "ai_service",
"resource_id": "tender_12345",
"request_data": {
"question": "供应商A的技术参数是否符合600W要求？",
"requirements_text": "技术参数≥600W",
"tender_ids": [12345]
},
"response_data": {
"status": "success",
"processing_time_ms": 2847,
"result_count": 3,
"model_version": "Qwen2.5-72B-v1.0",
"output_items": [
{
"page": 45,
"section": "3.2.1",
"tender_requirement": "功率≥600W",
"bid_content": "本产品功率500W，效率95%",
"original_text": "本产品功率500W，效率95%，符合GB/T 12345-2010标准"
}
]
},
"ip_address": "192.168.1.100",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"status": "success",
"created_at": "2026-01-16T10:15:00Z"
}
---
c.说明
专家操作日志：
d.代码示例
---
{
"audit_id": "audit_expert_202601160002",
"user_id": 567,
"username": "expert_张三",
"action": "expert_review_ai_result",
"resource_type": "clarification",
"resource_id": "tender_12345",
"request_data": {
"ai_result_id": "result_202601160001",
"review_action": "accept" // accept/reject/ignore
"review_comments": "" // 拒绝原因（可选）
},
"response_data": {
"status": "success"
},
"ip_address": "192.168.1.100",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"status": "success",
"created_at": "2026-01-16T10:20:00Z"
}
---
e.说明
---
f.数据安全与隐私保护
a.《数据安全法》合规要求
a.数据分类分级保护
a.说明
数据分类标准：
b.表格数据
数据级别 定义 保护措施 本系统实施
公开数据 可公开访问 评标结果（脱敏后） ✅ 合规（评标结束后可查询）
内部数据 仅限内部访问 评标规则、专家信息 ✅ 合规（RBAC权限控制）
敏感数据 仅授权人员访问 评标过程、标书原文 ✅ 合规（仅专家可访问）
核心数据 极小范围访问 密钥、审计日志 ✅ 合规（仅审计人员可访问）
c.说明
数据分类实施：
d.代码示例
---
from enum import Enum
class DataClassification(str, Enum):
PUBLIC = "public" # 公开
INTERNAL = "internal" # 内部
SENSITIVE = "sensive" # 敏感
CORE = "core" # 核心
def classify_data(
data_type: str,
user_role: str,
project_status: str
) -> DataClassification:
"""数据分类"""
# 标书原文：敏感数据（仅专家可访问）
if data_type == "tender_original":
if user_role == "evaluation_expert":
return DataClassification.SENSITIVE
else:
raise Exception("无权限访问标书原文")
# 评标结果：公开数据（脱敏后）
if data_type == "evaluation_result":
# 脱敏处理
return DataClassification.PUBLIC
# 评标规则：内部数据
if data_type == "evaluation_rules":
return DataClassification.INTERNAL
# 审计日志：核心数据（仅审计人员可访问）
if data_type == "audit_logs":
if user_role == "auditor":
return DataClassification.CORE
else:
raise Exception("无权限访问审计日志")
return DataClassification.INTERNAL
---
b.加密存储要求
a.说明
加密策略：
b.表格数据
数据类型 加密方式 密钥管理 合规性
原始PDF文件 AES-256-GCM 硬件安全模块（HSM） ✅ 合规
解析结果JSON AES-256-GCM 密钥轮换（每90天） ✅ 合规
向量数据 ChromaDB内置加密 TLS 1.2+传输加密 ✅ 合规
审计日志 AES-256-GCM 只读权限 ✅ 合规
c.说明
加密实施：
d.代码示例
---
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
from cryptography.hazmat.backends import default_backend
import base64
# AES-256-GCM加密
key = Fernet.generate_key()
cipher_suite = Fernet(key)
def encrypt_data(data: bytes) -> bytes:
"""加密数据"""
encrypted = cipher_suite.encrypt(data)
return encrypted
def decrypt_data(encrypted: bytes) -> bytes:
"""解密数据"""
decrypted = cipher_suite.decrypt(encrypted)
return decrypted
# 密钥管理（硬件安全模块建议）
def rotate_key():
"""密钥轮换"""
# 使用硬件安全模块（HSM）管理主密钥
# 每90天轮换一次数据加密密钥
# 记录密钥轮换日志
pass
# 使用示例
with open('tender.pdf', 'rb') as f:
file_data = f.read()
encrypted_data = encrypt_data(file_data)
with open('tender.pdf.enc', 'wb') as f:
f.write(encrypted_data)
---
b.《个人信息保护法》合规要求
a.最小必要原则
a.说明
最小必要原则：
b.表格数据
数据项 最小必要 本系统实施 合规性
专家信息 姓名、工号（必要） ✅ 合规（仅收集必要信息）
标书原文 文件内容（必要） ✅ 合规（专家澄清必要）
评标结果 评分结果（必要） ✅ 合规（评标结束后公开）
AI调用日志 输入输出（必要） ✅ 合规（审计必要）
IP地址 访问记录（必要） ✅ 合规（安全必要）
设备信息 User-Agent（必要） ✅ 合规（审计必要）
c.说明
不收集：
d.❌ 家庭住址
e.❌ 联系电话（非必要）
f.❌ 身份证号
g.❌ 银行卡号
h.❌ 其他非必要个人信息
c.等保二级合规要求
a.等保二级测评要求
a.说明
测评要求清单：
b.表格数据
要求 实施方式 验收标准
身份鉴别 用户名+密码+JWT 第三方测评
访问控制 RBAC最小权限原则 第三方测评
安全审计 完整日志记录（保留6个月） 第三方测评
数据完整性 数据库事务、数字签名 第三方测评
数据保密性 AES-256-GCM加密存储 第三方测评
备份恢复 每日备份+异地备份 第三方测评
c.说明
本系统的实施：
---
d.✅ JWT认证（用户名+密码）
e.✅ RBAC权限控制（最小权限原则）
f.✅ 完整审计日志（保留10年，超过要求的6个月）
g.✅ 数据库事务（ACID完整性）
h.✅ 数据加密（AES-256-GCM）
i.✅ 每日备份（本地+异地）
j.✅ 异地备份（不同地理位置）
g.风险识别与防控
a.法律风险点识别
a.AI系统风险
a.表格数据
风险点 风险描述 概率 影响程度 防控措施
AI输出格式不符合 AI输出超出约束，包含评分建议 低 中 Pydantic模型严格验证
专家过度依赖AI 专家完全接受AI结果，不进行独立判断 中 高 前端明确标注"AI仅供参考"
AI输出不准确 AI定位错误，误导专家 低 中 专家复核机制、AI输出异议流程
审计日志不完整 关键操作未记录到审计日志 低 高 强制所有操作记录到审计日志
数据泄露 标书原文被未授权访问 低 极高 严格权限控制、加密存储、审计日志
数据丢失 标书数据丢失或损坏 低 高 3-2-1备份、异地备份
b.合规风险点识别
a.表格数据
风险点 风险描述 概率 影响程度 防控措施
等保二级未通过 未通过等保二级测评 中 高 提前准备等保二级测评材料
数据安全法违规 违反《数据安全法》规定 中 极高 数据安全培训、合规审查、定期安全评估
个人信息保护法违规 违反《个人信息保护法》规定 中 极高 最小必要原则、隐私政策、用户同意机制
招标投标法违规 违反《招标投标法》规定 高 法律顾问审查、合规制度完善、定期法律培训
b.合规风险防控措施
a.风险管理制度
a.说明
风险管理制度架构：
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 风险管理架构 │
├────────────────────────────────────────────────────┤
│ ┌────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │风险识别 │ │风险评估 │ │风险缓解 │ │
│ │ │ │ │ │ │ │
│ └────────────┘ └──────────────┘ └─────────────┘ │
│ └─────────────────────────┘ │
│ │
│ ┌────────────────────────────┐ │
│ │ 风险监控与告警 │ │
│ │ │ │ │
│ └────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
---
c.说明
风险识别：
风险评估：
风险缓解：
风险监控与告警：
d.定期风险识别会议（每季度）
e.风险识别清单（法律风险、技术风险、操作风险）
f.风险评估标准（概率-影响矩阵）
g.风险等级划分（低、中、高、极高）
h.风险影响评估（法律后果、经济损失、声誉影响）
i.风险概率评估（历史数据分析、专家判断）
j.风险等级评定（定量评估）
k.针对性缓解措施（根据风险等级制定）
l.风险缓解计划（明确措施、责任人、时间表）
m.风险缓解效果评估（定期评估缓解措施有效性）
n.实时监控（Prometheus + Grafana）
o.告警规则（基于阈值自动告警）
p.告警通知（邮件、短信、钉钉）
q.告警响应（责任人响应时间要求）
c.应急响应预案
a.说明
应急响应预案：
b.表格数据
应急类型 触发条件 响应流程 责任人
数据泄露 发现数据泄露事件 1.立即隔离受影响系统 2. 通知数据保护官 数据保护负责人
系统故障 系统不可用超过30分钟 1.启动备用系统 2. 通知评标管理员 运维负责人
AI输出异常 AI输出大量错误或异常 1.立即停用AI服务 2. 通知专家和评标委员会 技术负责人
审计日志异常 审计日志丢失或损坏 1.启动备用审计日志系统 2. 通知数据保护官 运维负责人
合规风险暴露 发现合规风险或违规 1.立即暂停相关操作 2. 通知法律顾问 合规负责人
c.说明
应急响应流程：
1.立即识别应急事件类型
2.启动应急响应预案
3.通知相关责任人（数据保护负责人、运维负责人、技术负责人、法律顾问、评标管理员）
4.执行应急响应措施
5.事件记录与调查
6.恢复正常运营
7.事后总结与改进
---
h.合肥"青天大模型"实践对齐
a.合肥实践与本系统的对齐
a.表格数据
维度 合肥"青天大模型"实践 本系统设计 对齐度
AI角色 AI"类人"评审：提供智能评审意见，评标委员会成员评审时应将其作为重要的参考依据 AI澄清系统：仅提供参考依据（页码、章节号、原文对比），不做判断 ✅ 对齐
决策主体 评标委员会对最终评审结论承担法律责任 评标委员会对最终评审结论承担法律责任 ✅ 对齐
输出效力 AI评审结论仅作为参考依据 AI澄清结果仅作为参考依据 ✅ 对齐
人机协同 "背靠背"验证、"肩并肩"协作、"手拉手"交互 专家基于AI澄清结果手动打分，系统仅统计 ✅ 对齐
审计追踪 180天验证，完整数据可追溯 完整审计日志，保存10年 ✅ 对齐
b.本系统的优势与改进
a.表格数据
优势 说明 实施方式
更明确的AI定位 前端明确标注"AI仅供参考"，系统仅统计 前端界面标注 + 系统不参与决策
更严格的输出控制 Prompt明确限制，Pydantic模型验证 Prompt工程 + 输出验证
更完善的人机协同 专家可接受/拒绝/忽略AI发现，系统不验证 专家复核机制 + 系统不验证
更长的审计保留 保存10年（超过合肥的6个月） 审计日志10年
更严格的数据安全 AES-256-GCM加密、HSM密钥管理 加密存储 + 硬件安全模块
更完善的应急响应 多级应急预案、自动告警、责任人明确 风险管理 + 应急响应
b.说明
---
i.总结与建议
a.核心合规要点
a.表格数据
合规要点 本系统设计 合规依据 合规性
AI作为辅助工具 AI仅提供参考依据（页码、章节号、原文对比），不做判断或纠正 合肥实践、中国政策 ✅ 合规
专家自主判断 专家基于AI澄清结果完全自主判断 《招标投标法》第三十八条 ✅ 合规
评标委员会承担法律责任 系统仅统计和展示，不参与决策 《招标投标法》第三十八条 ✅ 合规
完整审计追踪 所有操作记录到审计日志，保存10年 《电子招标投标办法》第十三条 ✅ 合规
数据安全保护 AES-256-GCM加密存储、RBAC权限控制 《数据安全法》、《网络安全法》 ✅ 合规
等保二级 满足等保二级要求 《网络安全法》 ⚠️ 需测评
b.实施建议
a.合规实施路径
a.表格数据
阶段 时间 主要任务 交付物
Week 1-2 合规制度建立 《AI使用管理制度》、《数据安全管理制度》、《审计日志管理制度》
Week 3-4 技术实施 前端标注、Prompt工程、Pydantic模型、审计日志实现
Week 5-6 合规测试 法律顾问审查、合规自查、风险识别与评估
Week 7-8 等保二级测评 第三方测评机构测评、整改、通过测评
Week 9 正式上线 评标委员会培训、用户手册、运维文档
b.关键成功指标
a.表格数据
指标 目标值 验证方式
AI输出合规率 100% 审计日志抽查
专家操作记录率 100% 监控系统统计
审计日志完整性 100% 第三方测评
数据安全合规率 100% 第三方测评
等保二级通过率 100% 第三方测评报告
b.说明
---
文档版本：v1.0
最后更新：2026-01-16
文档状态：初稿
5.6 [3]智能客服
01.架构图
graph TD
subgraph Client [供应商终端 (信创浏览器)]
A[Web/App 界面]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[LangChain 业务编排] --> C{意图识别/路由}
C --> D[RAG 检索模块]
C --> E[Agent 业务操作]
D --> F[Milvus 向量库]
E --> G[达梦 DM8 (业务数据)]
B --> H[New-API Gateway]
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
I[MindIE LLM (Qwen2.5-14B)]
J[MindX OCR (图片识别)]
end
subgraph Data_Layer [数据持久化层]
F
G
end
A -- WebSocket/HTTPS --> B
H -- OpenAI API --> I
H -- Custom API --> J
D --> H
E --> H
I -- 向量化/Embedding --> F
B -- JDBC --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style H fill:#ffc,stroke:#333,stroke-width:2px
style I fill:#cfc,stroke:#333,stroke-width:2px
style F fill:#eee,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
click A "AI智能客服：用户交互界面"
click B "AI智能客服：核心业务逻辑编排"
click H "AI智能客服：模型统一入口"
click I "AI智能客服：LLM推理服务"
click F "AI智能客服：知识库向量存储"
click G "AI智能客服：结构化数据存储"
02.设计方案
a.架构设计 (Architecture)
a.说明
AI 智能客服系统采用 LangChain 驱动的 RAG + Agent 混合架构，旨在实现知识问答与业务查询的无缝切换。
b.代码示例
---
graph TD
subgraph Client [供应商终端]
A[Web-App 界面]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[LangChain 业务编排] --> C{意图识别/路由}
C -- 意图: 知识咨询 --> D[RAG Chain]
C -- 意图: 业务查询 --> E[SQL Agent Chain]
D --> F[Milvus 向量库]
E --> G[达梦 DM8 (业务数据)]
B --> H[New-API Gateway]
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
I[MindIE LLM (Qwen2.5-14B)]
end
A -- WebSocket/HTTPS --> B
H -- OpenAI API --> I
D --> H
E --> H
I -- 向量化/Embedding --> F
E -- JDBC --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style H fill:#ffc,stroke:#333,stroke-width:2px
style I fill:#cfc,stroke:#333,stroke-width:2px
style F fill:#eee,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
---
b.功能设计 (Functionality)
a.表格数据
模块 核心功能点 技术实现要点 性能指标
前端交互 实时聊天、历史记录、文件上传 WebSocket 实时通信，支持国密 SSL/TLS。 平均响应时间 < 3s
意图路由 知识咨询、业务查询、转人工 LangChain Router + LLM 意图识别 Prompt。 意图识别准确率 > 95%
RAG 知识库 多源知识整合、语义检索 Milvus (CPU) 存储，Qwen2.5-14B 生成回复。 FAQ 命中率 > 80%
SQL Agent 流程查询、状态查询、数据统计 LangChain SQL Agent + 达梦 DM8，限制查询白名单表。 SQL 生成准确率 > 90%
多模态支持 截图/PDF 上传咨询 New-API 封装 MindX OCR，将图片内容转为文本后进行 RAG。 截图识别准确率 > 98%
会话管理 上下文记忆、会话转人工 Redis 存储会话历史，LLM 自动判断是否需要转人工。 上下文记忆准确率 > 99%
c.时序设计 (Sequence Diagram)
a.说明
以下时序图展示了用户发起“查询供应商审核进度”这一业务查询请求的完整流程。
b.代码示例
---
sequenceDiagram
participant User as 供应商终端
participant WebApp as 业务应用 (LangChain)
participant NewAPI as 模型网关 (New-API)
participant MindIE as LLM 推理 (910B)
participant DM8 as 达梦数据库
User->>WebApp: 1. 发送消息: "我的审核进度到哪了?"
WebApp->>NewAPI: 2. [意图识别] LLM 调用 (Prompt: 识别意图)
NewAPI->>MindIE: 3. LLM 推理 (Qwen2.5-14B)
MindIE-->>NewAPI: 4. 返回意图: {intent: "business", tool: "sql_agent"}
NewAPI-->>WebApp: 5. 返回意图
WebApp->>WebApp: 6. [SQL Agent] 构造 SQL Agent Chain
WebApp->>NewAPI: 7. [SQL 生成] LLM 调用 (Prompt: 生成查询 SQL)
NewAPI->>MindIE: 8. LLM 推理 (Qwen2.5-14B)
MindIE-->>NewAPI: 9. 返回 SQL: "SELECT status FROM supplier_audit WHERE name='...' "
NewAPI-->>WebApp: 10. 返回 SQL 语句
WebApp->>DM8: 11. [执行 SQL] JDBC 查询
DM8-->>WebApp: 12. 返回结果: "已通过初审，等待现场核查"
WebApp->>NewAPI: 13. [回复生成] LLM 调用 (Prompt: 整合结果并生成回复)
NewAPI->>MindIE: 14. LLM 推理 (Qwen2.5-14B)
MindIE-->>NewAPI: 15. 返回回复: "您的审核已通过初审，目前正在等待现场核查。"
NewAPI-->>WebApp: 16. 返回最终回复
WebApp->>User: 17. 实时回复
---
d.关键技术点与探讨
a.New-API 的作用
在时序图中，New-API 充当了流量控制和协议转换的核心角色。它确保了 LangChain 只需要使用标准的 OpenAI 客户端，而无需关心后端 MindIE 的具体部署细节，实现了应用层与算力层的解耦。
b.达梦 SQL Agent 的安全性
a.说明
为了确保安全，SQL Agent 必须遵循以下原则：
b.Schema 锁定：Agent 只能访问预先定义好的、脱敏的数据库 Schema。
c.只读权限：Agent 调用的达梦连接账户必须是只读权限，严禁执行 UPDATE, DELETE, DROP 等操作。
c.RAG 与 Agent 的路由策略
a.说明
LangChain 的 Router 模块将基于 LLM 的意图识别结果进行分流。例如：
请您审阅这份【AI 智能客服】的精密设计方案，特别是时序图和功能设计，以便我们进行下一步的深入探讨。
b.用户：“招投标流程是什么？” -> 意图：knowledge -> 路由：RAG Chain。
c.用户：“我的注册信息对吗？” -> 意图：business -> 路由：SQL Agent Chain。
03.双路路由与SQL智能体深度实战
a.核心挑战与解决方案
a.表格数据
挑战 描述 解决方案
路由精准度 如何在高并发下，快速、准确地将用户问题路由到 RAG 或 SQL Agent。 双路意图识别：使用轻量级 LLM (如 Qwen2.5-7B) 进行意图识别，并结合 LangChain 的 RouterChain 实现分流。
达梦 SQL 安全性 LLM 生成的 SQL 语句可能包含恶意或错误的查询。 SQL Agent 白名单机制：严格限制 Agent 只能访问预设的只读表，并提供精确的表结构描述。
昇腾算力调度 如何高效利用 910B 算力进行 LLM 推理。 New-API 统一调度：将 MindIE 封装为 New-API 插槽，实现应用层与算力层的解耦和负载均衡。
b.LangChain 双路路由实战
a.意图识别 Prompt (Qwen2.5-7B)
a.说明
我们使用一个轻量级的 LLM 专门负责意图识别，以提高速度。
b.代码示例
---
# 意图识别 Prompt
INTENT_PROMPT = """
你是一个专业的智能客服意图识别系统。
请分析用户的问题，并将其归类为以下两种类型之一：
1. 'knowledge_query': 咨询类问题，需要从知识库中检索答案（如：政策、流程、定义）。
2. 'business_query': 业务查询类问题，需要查询数据库（如：状态、进度、统计）。
请严格以 JSON 格式输出，不要包含任何额外解释。
示例：
用户: "供应商审核流程是什么？" -> {"intent": "knowledge_query"}
用户: "我的投标状态到哪了？" -> {"intent": "business_query"}
用户问题: "{query}"
"""
---
b.LangChain RouterChain 实现
a.说明
LangChain 根据意图识别结果，将请求分发给 RAG Chain 或 SQL Agent Chain。
b.代码示例
---
from langchain.chains.router import MultiPromptChain
from langchain.chains.router.llm_router import LLMRouterChain, Route
from langchain.prompts import PromptTemplate
# 1. 定义两个目标 Chain
rag_chain = create_rag_chain(llm, milvus_vector_store)
sql_chain = create_sql_agent(llm, dm8_db)
# 2. 定义路由信息
route_infos = [
Route(
name="knowledge_query",
description="适用于政策、流程、定义等知识咨询类问题。",
destination=rag_chain,
),
Route(
name="business_query",
description="适用于查询状态、进度、统计等需要访问达梦数据库的问题。",
destination=sql_chain,
),
]
# 3. 创建路由 Chain
router_chain = LLMRouterChain.from_llm(
llm=llm_for_intent_recognition, # 使用 Qwen2.5-7B
routes=route_infos
)
# 4. 最终的多提示词 Chain
multi_chain = MultiPromptChain(
router_chain=router_chain,
destination_chains={
"knowledge_query": rag_chain,
"business_query": sql_chain,
},
default_chain=rag_chain, # 无法识别时默认走 RAG
)
---
c.达梦 SQL Agent 精密实现
a.达梦驱动与连接
a.说明
在信创环境下，必须使用达梦官方提供的 Python 驱动 dm-python。
b.代码示例
---
# 达梦连接字符串
DM_URI = "dm://SYSDBA:[email protected]:5236/DMDB"
db = SQLDatabase.from_uri(DM_URI)
---
b.Schema 描述与白名单
a.说明
这是确保 SQL Agent 安全性和准确性的核心。我们只向 LLM 暴露白名单表，并提供详细的中文描述。
b.代码示例
---
# 供应商审核状态表 (只读)
SUPPLIER_AUDIT_SCHEMA = """
CREATE TABLE SUPPLIER_AUDIT (
SUPPLIER_ID VARCHAR(50) PRIMARY KEY COMMENT '供应商唯一ID',
CREDIT_CODE VARCHAR(50) COMMENT '统一社会信用代码',
AUDIT_STATUS VARCHAR(20) COMMENT '审核状态，取值范围：初审中, 现场核查, 已通过, 已驳回',
SUBMIT_DATE DATE COMMENT '提交申请日期'
);
"""
# 仅向 Agent 暴露此表
db.include_tables = ["SUPPLIER_AUDIT"]
db.table_info = SUPPLIER_AUDIT_SCHEMA # 覆盖默认的 Schema 描述，加入中文注释
---
c.SQL Agent Prompt 优化 (防注入)
a.说明
为了防止 LLM 生成危险 SQL，我们需要在 System Prompt 中进行严格约束。
b.代码示例
---
SYSTEM_PROMPT = """
你是一个专业的达梦数据库 SQL 专家。
你的任务是根据用户的问题，生成**只读**的达梦 SQL 语句。
**严格禁止**使用 INSERT, UPDATE, DELETE, DROP, ALTER 等修改或删除数据的语句。
你只能查询以下白名单表：{table_info}。
请确保生成的 SQL 语句符合达梦数据库的语法规范。
"""
# LangChain 会自动将 SYSTEM_PROMPT 注入到 Agent 的上下文
---
d.昇腾算力调度：New-API 解耦
a.说明
通过 New-API，LangChain 无需直接与 MindIE 交互，而是通过标准的 OpenAI 接口。
b.代码示例
---
from langchain_openai import ChatOpenAI
# New-API 部署在 192.168.1.100 的 3000 端口
os.environ["OPENAI_API_BASE"] = "http://192.168.1.100:3000/v1"
os.environ["OPENAI_API_KEY"] = "sk-ascend-trust-key"
# LangChain 自动连接 New-API，New-API 负责将请求转发给 910B 上的 MindIE
llm_for_generation = ChatOpenAI(model="qwen2.5-14b", temperature=0)
llm_for_intent_recognition = ChatOpenAI(model="qwen2.5-7b", temperature=0) # 假设 New-API 区分模型
---
c.说明
这种解耦方式，使得未来即使更换为其他信创 LLM，应用层代码也无需改动，只需修改 New-API 的配置即可。
5.7 [3]智能审核
01.架构图
graph TD
subgraph Client [供应商终端 (信创浏览器)]
A[上传证照/申请表]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[审核业务流程] --> C[文档解析集群]
C --> D[New-API Gateway]
D --> E[MindX OCR/VL]
B --> F[规则引擎/逻辑校验]
F --> G[达梦 DM8 (规则/数据)]
D --> H[MindIE LLM]
H --> I[Milvus (风险知识库)]
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
E[MindX OCR/VL]
H[MindIE LLM]
end
subgraph Data_Layer [数据持久化层]
G
I
end
A -- HTTPS --> B
B -- 异步调用 --> C
C -- gRPC/HTTP --> D
D -- Custom API --> E
D -- OpenAI API --> H
H -- RAG --> I
F -- JDBC --> G
B -- 存储结果 --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style D fill:#ffc,stroke:#333,stroke-width:2px
style E fill:#cfc,stroke:#333,stroke-width:2px
style H fill:#cfc,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
style I fill:#eee,stroke:#333,stroke-width:2px
click A "供应商智能审核：证照上传"
click B "供应商智能审核：核心审核流程控制"
click C "供应商智能审核：文档解析与结构化集群"
click D "供应商智能审核：模型统一入口"
click E "供应商智能审核：OCR/多模态识别"
click H "供应商智能审核：LLM风险评估"
click G "供应商智能审核：结构化数据与规则存储"
click I "供应商智能审核：风险知识库"
02.设计方案
a.架构设计 (Architecture)
a.说明
供应商智能审核系统采用 多模态提取 + 规则引擎 + LLM 风险评估 的复合架构，核心在于将非结构化的证照信息高效转化为结构化数据，并进行自动化比对。
b.代码示例
---
graph TD
subgraph Client [供应商终端]
A[上传证照与申请表]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[审核业务流程 (LangChain)] --> C[文档解析集群]
C --> D[New-API Gateway]
D --> E[MindX OCR/VL]
B --> F[规则引擎/逻辑校验]
F --> G[达梦 DM8 (规则/数据)]
D --> H[MindIE LLM]
H --> I[Milvus (风险知识库)]
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
E[MindX OCR/VL]
H[MindIE LLM]
end
A -- HTTPS --> B
B -- 异步调用 --> C
C -- gRPC/HTTP --> D
D -- Custom API --> E
D -- OpenAI API --> H
H -- RAG --> I
F -- JDBC --> G
B -- 存储结果 --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style D fill:#ffc,stroke:#333,stroke-width:2px
style E fill:#cfc,stroke:#333,stroke-width:2px
style H fill:#cfc,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
style I fill:#eee,stroke:#333,stroke-width:2px
---
b.功能设计 (Functionality)
a.表格数据
模块 核心功能点 技术实现要点 性能指标
证照上传 支持 PDF、JPG、PNG 等格式，国密加密传输。 前端分片上传，后端国密 SM2/SM3 校验。 上传成功率 > 99.9%
文档结构化 营业执照、资质证书、财务报表等关键信息提取。 Unstructured 集群解析，New-API 调 MindX OCR/VL。 关键字段提取准确率 > 95%
规则引擎 注册资本、成立年限、经营范围等硬性指标校验。 LangChain 结合达梦 SQL 查询，执行预设规则。 硬性规则校验速度 < 1s
LLM 风险评估 经营范围与招标资质匹配度、潜在风险点分析。 Qwen2.5-14B 逻辑推理，结合 Milvus 风险知识库 RAG。 风险评估准确率 > 85%
审核意见生成 自动生成“通过/驳回/补正”建议及详细理由。 LLM 结构化输出 (Pydantic Schema)，结果存入达梦。 意见生成速度 < 5s
数据安全 敏感数据存储加密。 达梦 DM8 开启 SM4 加密存储。 符合信创安全规范
c.时序设计 (Sequence Diagram)
a.说明
以下时序图展示了“供应商上传营业执照并进行智能审核”的完整流程。
b.代码示例
---
sequenceDiagram
participant Supplier as 供应商终端
participant WebApp as 审核业务流程 (LangChain)
participant DocCluster as 文档解析集群 (Unstructured)
participant NewAPI as 模型网关 (New-API)
participant MindX as OCR/VL (910B)
participant DM8 as 达梦数据库
Supplier->>WebApp: 1. 上传营业执照 (PDF/JPG)
WebApp->>DocCluster: 2. [异步] 提交解析任务 (文件路径)
DocCluster->>NewAPI: 3. [OCR] 调用 OCR/VL 插槽
NewAPI->>MindX: 4. MindX OCR/VL 推理 (NPU 加速)
MindX-->>NewAPI: 5. 返回原始文本/视觉信息
NewAPI-->>DocCluster: 6. 返回 OCR 结果
DocCluster->>WebApp: 7. [异步回调] 返回结构化 JSON (SupplierInfo)
WebApp->>DM8: 8. [存储] 暂存提取的关键信息
WebApp->>DM8: 9. [规则校验] 查询硬性规则 (如黑名单、注册资本要求)
DM8-->>WebApp: 10. 返回校验结果
WebApp->>NewAPI: 11. [风险评估] LLM 调用 (Prompt: 评估经营范围风险)
NewAPI->>MindX: 12. LLM 推理 (Qwen2.5-14B)
MindX-->>NewAPI: 13. 返回风险评分 (0-100)
NewAPI-->>WebApp: 14. 返回风险评分
WebApp->>DM8: 15. [决策] 综合规则与评分，存储最终审核意见
WebApp->>Supplier: 16. 返回审核结果通知
---
d.关键技术点与探讨
a.异步处理的必要性
证照解析，特别是多页 PDF，耗时可能达到数秒甚至数十秒。采用 Kafka 消息队列进行异步处理，可以避免用户等待，并提高系统的并发处理能力。
b.New-API 的自定义插槽
在这个场景中，New-API 不仅需要支持标准的 OpenAI 协议（用于 LLM 风险评估），还需要支持自定义插槽来封装 MindX OCR/VL 的非标准接口，实现统一的 API 管理。
c.结构化输出的强制性
LangChain 必须使用 Pydantic Schema 强制 LLM 输出结构化的 JSON 数据，以确保提取的信息可以直接插入达梦数据库，这是实现自动化规则校验的前提。
03.多模态结构化提取与规则对齐深度实战
a.核心挑战与解决方案
a.表格数据
挑战 描述 解决方案
证照结构化 营业执照、资质证书等格式不一，OCR 结果混乱。 多模态结构化提取：利用 MindX OCR/VL 识别文字和版面，LLM 强制 Pydantic Schema 输出 JSON。
规则引擎对齐 提取的数据如何与达梦数据库中的硬性规则进行“零误差”比对。 数据原子化与双重校验：LLM 提取原子数据，LangChain 负责将原子数据与达梦中的规则进行 SQL 比对。
异步处理 证照解析耗时长，如何避免阻塞主流程。 Kafka 异步队列：将解析任务解耦，通过消息队列通知结果，提高系统吞吐量。
b.多模态结构化提取实战
a.New-API 自定义 OCR 插槽
a.说明
由于 MindX OCR/VL 接口可能不是标准的 OpenAI 协议，我们需要在 New-API 中定义一个自定义插槽。
b.代码示例
---
# New-API 配置文件片段
channels:
- name: mindx-ocr-vl
type: custom_http # 非 OpenAI 协议
base_url: http://910b-node-2:8001/ocr/extract
models: ["mindx-ocr-vl"]
# 负责将 LangChain 的请求转换为 MindX 要求的格式
request_template: |
{
"image_url": "{{ .image_url }}",
"task_type": "supplier_audit"
}
---
b.LangChain 驱动结构化输出
a.说明
LangChain 使用 Pydantic 模型定义输出结构，并强制 LLM 严格遵循。
b.代码示例
---
from pydantic import BaseModel, Field
from langchain.output_parsers import PydanticOutputParser
# 定义供应商信息 Pydantic Schema
class SupplierInfo(BaseModel):
"""供应商营业执照关键信息"""
name: str = Field(description="供应商全称")
credit_code: str = Field(description="统一社会信用代码")
registered_capital: float = Field(description="注册资本，单位：万元")
established_date: str = Field(description="成立日期，格式：YYYY-MM-DD")
business_scope: str = Field(description="经营范围，完整文本")
parser = PydanticOutputParser(pydantic_object=SupplierInfo)
# 结构化提取 Prompt
EXTRACTION_PROMPT = """
你是一个专业的证照信息提取机器人。
任务：从提供的【OCR 文本】中，提取关键信息。
【OCR 文本】：{ocr_text}
{format_instructions}
"""
# 最终 Chain: OCR 结果 -> LLM -> 结构化 JSON
extraction_chain = EXTRACTION_PROMPT | llm | parser
---
c.规则引擎与达梦对齐实战
a.达梦规则库设计
a.说明
在达梦 DM8 中，建立规则库表，用于存储硬性审核规则。
b.代码示例
---
-- 达梦 DM8 规则表 (AUDIT_RULES)
CREATE TABLE AUDIT_RULES (
RULE_ID INT PRIMARY KEY,
RULE_TYPE VARCHAR(50) COMMENT '规则类型：CAPITAL_MIN, BLACKLIST, ESTABLISHED_YEAR',
RULE_VALUE VARCHAR(100) COMMENT '规则阈值或黑名单列表',
ERROR_MESSAGE VARCHAR(255) COMMENT '校验失败时的提示信息'
);
-- 示例：注册资本必须大于 1000 万元
INSERT INTO AUDIT_RULES VALUES (1, 'CAPITAL_MIN', '1000', '注册资本必须大于1000万元');
---
b.LangChain 规则校验逻辑
a.说明
LangChain 负责将 LLM 提取的结构化数据与达梦规则进行比对。
b.代码示例
---
import dm_python # 达梦驱动
def run_audit_rules(supplier_info: SupplierInfo, dm8_conn):
"""执行硬性规则校验"""
cursor = dm8_conn.cursor()
# 1. 校验注册资本
cursor.execute("SELECT RULE_VALUE FROM AUDIT_RULES WHERE RULE_TYPE = 'CAPITAL_MIN'")
min_capital = float(cursor.fetchone()[0])
if supplier_info.registered_capital < min_capital:
return False, f"注册资本 {supplier_info.registered_capital} 万元，低于最低要求 {min_capital} 万元。"
# 2. 校验成立年限 (示例)
# ... 更多规则校验 ...
# 3. LLM 风险评估 (软性规则)
# 这一步通过 New-API 调用 LLM，评估 business_scope 与招标要求的匹配度
risk_score = llm_risk_assessment(supplier_info.business_scope)
if risk_score < 60:
return False, f"经营范围匹配度低，风险评分 {risk_score} 分。"
return True, "硬性规则校验通过，风险评估良好。"
---
d.异步处理与集成
为了实现异步，LangChain 业务流程需要与 Kafka 队列集成。
1.任务提交：供应商上传文件后，LangChain 将文件路径和供应商 ID 封装成 JSON 消息，发送到 audit_task_queue。
2.集群消费：文档解析集群（Unstructured + MindX OCR）消费消息，进行解析和结构化提取。
3.结果回调：解析完成后，将结构化 JSON 结果发送到 audit_result_queue。
4.主流程监听：LangChain 主流程监听 audit_result_queue，接收到结果后，触发后续的规则校验和 LLM 风险评估。
5.8 [3]智能评标
01.架构图
graph TD
subgraph Client [评标专家终端 (信创浏览器)]
A[评标工作台]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[评标业务服务] --> C[标书解析集群]
C --> D[New-API Gateway]
D --> E[MindX OCR/VL]
B --> F[LangChain 评标 Agent]
F --> G[达梦 DM8 (评分规则/结果)]
F --> H[Milvus (标书向量库)]
F --> D
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
E[MindX OCR/VL]
I[MindIE LLM (Qwen2.5-14B)]
J[Rerank 模型 (NPU 加速)]
end
subgraph Data_Layer [数据持久化层]
G
H
end
A -- HTTPS --> B
B -- 异步处理 --> C
C -- gRPC/HTTP --> D
D -- Custom API --> E
D -- OpenAI API --> I
I -- 排序 --> J
F -- RAG --> H
F -- JDBC --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style D fill:#ffc,stroke:#333,stroke-width:2px
style E fill:#cfc,stroke:#333,stroke-width:2px
style I fill:#cfc,stroke:#333,stroke-width:2px
style J fill:#cfc,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
style H fill:#eee,stroke:#333,stroke-width:2px
click A "智能评标：专家操作界面"
click B "智能评标：核心业务流程控制"
click C "智能评标：标书文档解析集群"
click D "智能评标：模型统一入口"
click E "智能评标：OCR/多模态识别"
click I "智能评标：LLM智能打分与意见生成"
click J "智能评标：向量检索结果排序优化"
click G "智能评标：评分规则与结果存储"
click H "智能评标：标书内容向量存储"
02.设计方案
a.架构设计 (Architecture)
a.说明
智能评标系统采用 长文本 RAG + 智能 Agent 决策 架构，核心挑战在于处理超大标书文档和实现客观、可追溯的智能打分。
b.代码示例
---
graph TD
subgraph Client [评标专家终端]
A[评标工作台]
end
subgraph App_Server [业务应用节点 (鲲鹏 CPU)]
direction LR
B[评标业务服务] --> C[标书解析集群]
C --> D[New-API Gateway]
D --> E[MindX OCR/VL]
B --> F[LangChain 评标 Agent]
F --> G[达梦 DM8 (评分规则/结果)]
F --> H[Milvus (标书向量库)]
F --> D
end
subgraph AI_Server [AI 算力节点 (昇腾 910B)]
E[MindX OCR/VL]
I[MindIE LLM (Qwen2.5-14B)]
J[Rerank 模型 (NPU 加速)]
end
A -- HTTPS --> B
B -- 异步处理 --> C
C -- gRPC/HTTP --> D
D -- Custom API --> E
D -- OpenAI API --> I
I -- 排序 --> J
F -- RAG --> H
F -- JDBC --> G
style A fill:#f9f,stroke:#333,stroke-width:2px
style B fill:#ccf,stroke:#333,stroke-width:2px
style C fill:#ccf,stroke:#333,stroke-width:2px
style D fill:#ffc,stroke:#333,stroke-width:2px
style E fill:#cfc,stroke:#333,stroke-width:2px
style I fill:#cfc,stroke:#333,stroke-width:2px
style J fill:#cfc,stroke:#333,stroke-width:2px
style G fill:#eee,stroke:#333,stroke-width:2px
style H fill:#eee,stroke:#333,stroke-width:2px
---
b.功能设计 (Functionality)
a.表格数据
模块 核心功能点 技术实现要点 性能指标
标书预处理 长文档解析、OCR 识别、父子文档切分。 异步调用 Unstructured 集群，Milvus 存储父子文档向量。 500MB PDF 解析时间 < 5 分钟
条款自动对齐 招标文件要求与投标书响应条款的 1:1 匹配。 LangChain Agent 驱动 RAG，利用 Rerank 模型 (NPU) 优化匹配度。 匹配准确率 > 90%
客观项智能打分 针对技术参数、数值指标进行比对和评分。 LLM 结构化输出评分结果，达梦 DM8 存储评分依据。 单项打分时间 < 10s
偏离表生成 自动汇总所有不符合项和技术偏离。 LLM 总结 Chain，强制输出 Markdown 表格格式。 偏离表生成速度 < 30s
评标报告生成 汇总所有评分、意见，生成最终报告。 LLM 结合达梦数据，生成结构化报告文本。 报告生成速度 < 60s
数据安全 评标过程数据隔离。 Milvus 中为每个项目创建独立 Partition，达梦数据加密。 数据隔离性 100%
c.时序设计 (Sequence Diagram)
a.说明
以下时序图展示了“评标 Agent 对标书中的某一技术参数进行智能打分”的完整流程。
b.代码示例
---
sequenceDiagram
participant Expert as 评标专家
participant WebApp as 评标业务服务 (LangChain Agent)
participant Milvus as 标书向量库
participant NewAPI as 模型网关 (New-API)
participant MindIE as LLM 推理 (910B)
participant DM8 as 达梦数据库
Expert->>WebApp: 1. [触发] 选择“对参数 X 进行智能打分”
WebApp->>DM8: 2. [查询] 获取参数 X 的评分规则 (满分、扣分点)
DM8-->>WebApp: 3. 返回评分规则
WebApp->>Milvus: 4. [检索] RAG 检索：根据规则检索标书中的相关片段 (子文档)
Milvus-->>WebApp: 5. 返回 Top K 匹配片段 (子文档)
WebApp->>NewAPI: 6. [Rerank] 调用 Rerank 模型 (NPU) 优化片段排序
NewAPI->>MindIE: 7. Rerank 推理
MindIE-->>NewAPI: 8. 返回排序后的片段
NewAPI-->>WebApp: 9. 返回最优匹配片段 (父文档)
WebApp->>NewAPI: 10. [打分] LLM 调用 (Prompt: 规则+片段+结构化输出)
NewAPI->>MindIE: 11. LLM 推理 (Qwen2.5-14B)
MindIE-->>NewAPI: 12. 返回结构化评分: {score: 8, reason: "..."}
NewAPI-->>WebApp: 13. 返回评分结果
WebApp->>DM8: 14. [存储] 存储评分结果和 LLM 评分依据
WebApp->>Expert: 15. [展示] 在工作台显示评分结果
---
d.关键技术点与探讨
a.Rerank 模型的必要性
在长文本 RAG 中，初始的向量检索（步骤 4）召回率高但精度不足。引入 Rerank 模型（步骤 6-9）在 NPU 上进行二次排序，能显著提高 LLM 接收到的上下文质量，从而确保打分的客观性和准确性。
b.评分结果的可追溯性
每一次智能打分（步骤 14）都必须将 LLM 的原始评分理由和引用的标书片段一并存储到达梦数据库。这满足了评标过程的可追溯性和合规性要求。
c.LLM 的角色
评标 Agent 必须确保 LLM 严格遵循达梦中存储的评分规则，而不是自由发挥。Prompt 工程需要明确要求 LLM 仅作为逻辑推理引擎，而非自由创作工具。
03.长文本父子索引与客观打分深度实战
a.核心挑战与解决方案
a.表格数据
挑战 描述 解决方案
长文本上下文 标书动辄数百页，传统 RAG 容易丢失上下文或检索不准确。 父子文档检索 (Parent Document Retrieval)：Milvus 存储精炼的“子文档”用于检索，LLM 使用完整的“父文档”作为上下文。
检索精度 评标要求极高的匹配精度，仅靠向量相似度不够。 NPU 加速 Rerank：在 910B 上部署轻量级 Rerank 模型，对初次召回结果进行二次排序，提高相关性。
客观打分 确保 LLM 打分客观、可追溯，而非自由发挥。 结构化评分 Agent：LLM 仅作为逻辑推理器，强制输出 Pydantic Schema 格式的评分和理由，并存储到达梦 DM8。
b.长文本父子文档检索实战
a.文档切分策略
a.说明
采用 Unstructured 进行文档解析，并使用 LangChain 的 ParentDocumentRetriever 实现父子文档的生成。
b.代码示例
---
from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore
from langchain.text_splitter import RecursiveCharacterTextSplitter
# 1. 定义父文档切分器 (大块，用于 LLM 上下文)
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=2000, chunk_overlap=200)
# 2. 定义子文档切分器 (小块，用于 Milvus 检索)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=50)
# 3. 存储：Milvus 存储子文档向量，InMemoryStore 存储父文档内容
vectorstore = Milvus(embedding_function=bge_m3_embeddings, ...)
store = InMemoryStore() # 实际生产环境应使用达梦或 Redis 存储
# 4. 创建 ParentDocumentRetriever
retriever = ParentDocumentRetriever(
vectorstore=vectorstore,
docstore=store,
child_splitter=child_splitter,
parent_splitter=parent_splitter,
)
# 5. 导入文档
# retriever.add_documents(parsed_tender_docs)
---
b.NPU 加速 Rerank
a.说明
Rerank 模型部署在 910B 上，通过 New-API 的自定义插槽调用。
b.代码示例
---
from langchain.retrievers import ContextualCompressionRetriever
from langchain.llms import OpenAI # 仍使用 OpenAI 接口连接 New-API
# 假设 New-API 封装了一个 Rerank 模型
rerank_llm = OpenAI(
model="rerank-model-bge",
openai_api_base="http://new-api-ip:3000/v1",
# New-API 负责将 rerank-model-bge 的请求转发给 910B 上的 NPU 加速服务
)
# 使用 LangChain 的 ContextualCompressionRetriever 包装 Rerank 逻辑
compression_retriever = ContextualCompressionRetriever(
base_compressor=rerank_llm, # 这里的 LLM 实际上是 Rerank 模型
base_retriever=retriever,
)
# 检索时，先由 retriever 初次召回，再由 compression_retriever (Rerank) 优化
# final_docs = compression_retriever.get_relevant_documents(query)
---
c.客观打分 Agent 精密实现
a.评分结构化输出
a.说明
定义评分结果的 Pydantic Schema，确保输出结果可直接存入达梦 DM8。
b.代码示例
---
from pydantic import BaseModel, Field
class ScoreResult(BaseModel):
"""评标客观项评分结果"""
score: int = Field(description="最终评分，必须是 0 到 100 之间的整数。")
reason: str = Field(description="给出评分的详细理由，必须引用标书中的具体内容作为依据。")
compliant: bool = Field(description="是否符合招标文件要求，True 或 False。")
parser = PydanticOutputParser(pydantic_object=ScoreResult)
---
b.打分 Agent Prompt 策略
a.说明
Prompt 必须强调 LLM 的角色限制和可追溯性。
b.代码示例
---
SCORING_PROMPT = """
你是一个专业的评标专家，你的任务是根据【招标文件要求】和【投标文件片段】进行客观打分。
**角色限制**：你必须严格遵循提供的评分规则，不能自由发挥。
**可追溯性要求**：你的理由 (reason) 中必须引用投标文件片段中的具体文字。
【招标文件要求】: {tender_requirement}
【投标文件片段】: {bid_document_context}
【评分规则】: {scoring_rules}
请严格按照以下 JSON 格式输出评分结果：
{format_instructions}
"""
# Agent Chain: 检索 -> LLM (推理/打分) -> 达梦 (存储)
---
c.达梦存储与审计
a.说明
评分结果和 LLM 的推理依据（reason）必须存储在达梦 DM8 中，以满足审计要求。
b.代码示例
---
# 存储评分结果到达梦
def save_score_to_dm8(project_id, requirement_id, score_result: ScoreResult):
# SQL 语句将 score, reason, compliant 存入评分结果表
# ...
pass
---
5.9 [4]落地总纲
01.全信创 AI 系统落地总纲
a.实施路线图：三阶段迭代法
a.说明
本项目采用“基础设施先行、核心能力验证、业务场景落地”的三阶段迭代法，确保在全封闭信创环境下的平稳、高效交付。
b.表格数据
阶段 目标 关键任务 产出物
阶段一：基础设施与模型适配 搭建全封闭环境下的 AI 算力底座，验证核心模型可用性。 1.部署麒麟 OS、CANN 驱动。 2. 搭建私有 Docker Registry 和 PyPI 仓库。 3. 部署 MindIE，将 Qwen2.5-14B 模型量化并加载。 4. 部署 New-API，封装 MindIE 接口。 5. 部署达梦 DM8 和 Milvus (CPU)。 《离线环境初始化与模型适配指南》、New-API 接口测试报告。
阶段二：核心能力验证与集成 验证 LangChain 与信创组件的集成能力，实现 RAG 和 SQL Agent 的原型。 1.LangChain 环境搭建与依赖锁定。 2. 实现 LangChain 通过 New-API 调用 LLM。 3. 实现 LangChain RAG (Milvus) 原型。 4. 实现 LangChain SQL Agent (达梦 DM8) 原型。 5. 部署文档处理集群 (Unstructured/PaddleOCR)。 《LangChain 集成验证报告》、RAG/SQL Agent 核心代码。
阶段三：三大业务场景落地 基于验证通过的核心能力，实现三大业务系统的完整功能。 1.智能客服：完成意图识别、多轮对话、知识库管理。 2. 供应商审核：完成证照 OCR、规则引擎集成、审核意见生成。 3. 智能评标：完成标书解析、条款比对、智能打分。 《三大业务场景精密设计手册》、系统功能测试报告。
b.核心技术选型回顾
a.表格数据
模块 选型 部署位置 作用
AI 算力 昇腾 910B + MindIE AI 应用服务器 LLM 推理、OCR 加速
模型网关 New-API AI 模型运行服务器 (鲲鹏 CPU) 统一接口、负载均衡、协议转换
应用框架 LangChain (Python) AI 模型运行服务器 (鲲鹏 CPU) 业务逻辑编排、Agent 实现
关系数据库 达梦 DM8 AI 模型运行服务器 (鲲鹏 CPU) 业务数据、审计日志、规则存储
向量存储 Milvus (CPU) AI 模型运行服务器 (鲲鹏 CPU) 知识库、标书向量索引
文档处理 PaddleOCR (昇腾) + Unstructured (CPU) 混合部署 复杂文档结构化、文字识别
c.关键挑战与应对策略
a.表格数据
挑战 应对策略 关键技术点
昇腾生态适配 优先使用官方适配工具和框架，避免底层算子重写。 CANN、MindIE、昇腾版 PaddlePaddle
达梦向量检索 采用“达梦 (元数据) + Milvus (向量)”的混合存储方案。 LangChain SQL Agent、Milvus CPU 模式
断网环境依赖 搭建私有镜像仓库和 PyPI 仓库，所有依赖离线化。 Docker Registry、Bandersnatch/Devpi
模型性能 采用 Qwen2.5-14B，并进行 Int4 量化，利用 New-API 实现多卡负载均衡。 Qwen2.5-14B、Int4 量化、New-API L/B
文档结构化 部署 Unstructured/PaddleOCR 集群，实现高并发、高准确率的文档解析。 Unstructured 微服务化、异步消息队列
02.全维度需求与技术约束清单
a.说明
本清单汇总了本项目在硬件、环境、技术选型及业务场景等方面的所有核心需求与约束条件，旨在作为系统设计、实施与验收的统一基准。
b.硬件资源需求 (全昇腾架构)
a.表格数据
类别 配置要求 数量 核心用途
AI 应用服务器 16C64G2T + 昇腾 910B 2 台 LLM 推理 (MindIE)、OCR 识别训练与运行
AI 模型运行服务器 28C128G2T + T4 显卡 (信创版) 1 台 应用部署、Embedding 加速、New-API 网关
备份服务器 16C32G10T 1 台 模型权重备份、知识库备份、业务数据备份
c.环境与合规约束 (全信创/全封闭)
a.表格数据
维度 约束要求 详细说明
信创要求 全信创环境 必须采用国产 CPU (鲲鹏)、国产 NPU (昇腾)、国产 OS (麒麟/统信)。
网络环境 全封闭、完全断网 系统必须在物理隔离的内网运行，所有依赖、镜像、模型需离线部署。
数据库要求 达梦数据库 (DM8) 必须使用达梦作为核心关系型数据库，支持 DSC 集群与国密加密。
安全标准 国密合规 存储需支持 SM4 加密，传输需支持国密 SSL/TLS 协议。
d.AI 模型与技术选型需求
a.表格数据
维度 选型要求 详细说明
模型参数量 7B / 14B / 16B 优先选用 14B 级模型 (如 Qwen2.5-14B)，兼顾智商与 910B 显存效率。
模型网关 New-API 建立 API 插槽中心，统一封装 LLM 和 OCR 接口，支持负载均衡。
应用框架 LangChain (Python) 采用 Python 版 LangChain 构建 RAG、SQL Agent 及业务逻辑链。
向量存储 Milvus / ES (信创版) 采用 CPU 内存模式部署，解决达梦原生不支持向量检索的问题。
文档处理 集群化开源工具 必须支持 PDF、Word、Excel、图片的高效解析 (推荐 Unstructured + PaddleOCR)。
e.三大业务场景核心需求
a.AI 智能客服
1.核心目标：降低 50% 人工成本，响应时间 80%。
2.关键功能：多轮对话、意图识别、RAG 知识检索、业务进度查询 (SQL Agent)。
3.数据源：达梦数据库中的业务数据 + PDF/Word 格式的政策与 FAQ。
b.供应商智能审核
1.核心目标：自动化准入把关，实现证照自动提取与风险预警。
2.关键功能：OCR 结构化提取、多模态视觉校验 (印章/有效期)、规则引擎比对。
3.数据源：供应商上传的证照图片/PDF + 达梦中的准入规则库。
c.智能评标
1.核心目标：长文档比对、客观项自动打分、偏离表自动生成。
2.关键功能：长文本 RAG (父子文档策略)、条款自动对齐、逻辑推理打分。
3.数据源：数百页的标书 (PDF/Word) + 招标文件要求。
f.实施与交付要求
1.离线化交付：提供完整的离线安装包、Docker 镜像包及模型量化权重。
2.精密架构：系统需具备高可用性，支持集群化部署，特别是文档处理模块。
3.可追溯性：所有 AI 调用过程需记录审计日志，存储于达梦数据库。
03.三大业务场景精密设计手册
a.AI 智能客服：RAG 与 SQL Agent 混合模式
a.业务流程编排 (LangChain)
a.代码示例
---
graph TD
A[用户提问] --> B{LangChain Router}
B -- 意图: 知识咨询 --> C[RAG Chain]
B -- 意图: 业务查询 --> D[SQL Agent Chain]
C --> E[Milvus 检索]
D --> F[达梦 DM8 查询]
E --> G[LLM (Qwen2.5-14B)]
F --> G
G --> H[回复用户]
---
b.核心 Prompt 工程 (Qwen2.5-14B)
a.说明
> 角色：你是一个智能路由系统。
> 任务：判断用户提问属于“知识咨询”还是“业务查询”。
> 输出格式：{"intent": "knowledge" | "business", "keywords": "..."}
> 角色：你是一个专业的招采客服。
> 任务：基于提供的【知识库片段】，简洁、准确地回答【用户问题】。如果知识库中没有答案，请礼貌告知。
> 【知识库片段】：{context}
> 【用户问题】：{query}
b.意图识别 Prompt：
c.RAG 生成 Prompt：
c.达梦 SQL Agent 设计
1.目标：实现 LangChain Agent 自动将自然语言转换为达梦 SQL，并执行查询。
2.实现：使用 langchain_community.utilities.SQLDatabase 连接达梦，并使用 create_sql_agent。
3.关键：Agent 必须被限制在只查询白名单表（如供应商状态表、流程进度表），并提供详细的表结构描述给 LLM，以确保生成的 SQL 语句准确无误。
b.供应商智能审核：多模态与结构化提取
a.业务流程编排 (LangChain)
a.代码示例
---
graph TD
A[供应商上传证照] --> B[文档解析集群 (Unstructured)]
B --> C[New-API (OCR/VL)]
C --> D[结构化数据提取 (LLM)]
D --> E[达梦 DM8 暂存]
E --> F[规则引擎 (LangChain)]
F --> G[达梦 DM8 (规则比对)]
G --> H[LLM 审核意见生成]
---
b.结构化提取 Prompt (LLM)
a.说明
> 角色：你是一个专业的证照信息提取机器人。
> 任务：从提供的【OCR 文本】中，提取供应商名称、统一社会信用代码、注册资本、成立日期、经营范围。
> 【OCR 文本】：{ocr_result}
> 输出格式：必须严格遵循 Pydantic Schema SupplierInfo(name: str, credit_code: str, ...)。
b.目标：从 OCR 结果中提取关键字段，并以 JSON 格式输出。
c.Prompt：
c.规则引擎集成
1.硬性规则：直接在 LangChain 中编写 Python 逻辑，通过 JDBC 连接达梦，执行 SQL 校验（如 SELECT COUNT(*) FROM black_list WHERE credit_code = '...'）。
2.软性规则：利用 LLM 对“经营范围”与“招标资质”的匹配度进行语义评估，输出 0-100 的评分。
c.智能评标：长文本 RAG 与客观打分
a.业务流程编排 (LangChain Agent)
a.代码示例
---
graph TD
A[标书上传] --> B[文档解析集群]
B --> C[Milvus 向量化 (父子文档)]
D[评标规则输入] --> E[LangChain 评标 Agent]
E -- 检索 --> H[Milvus 检索]
E -- 推理 --> F[LLM (Qwen2.5-14B)]
F --> G[达梦 DM8 (评分结果)]
G --> I[评标报告生成]
---
b.长文本 RAG 策略：父子文档检索
a.说明
1. 检索：用评标规则检索 Milvus 中的子文档（提高召回率）。
2. 重构：找到子文档对应的父文档作为 LLM 的上下文（提供完整语境）。
3. 推理：LLM 基于父文档进行打分和意见生成。
b.父文档：标书的章节、段落等大块内容。
c.子文档：父文档的精炼摘要或关键句子。
d.流程：
c.客观打分 Prompt
a.说明
> 角色：你是一个专业的评标专家。
> 任务：根据【招标文件要求】和【投标文件对应片段】，判断是否满足要求，并给出评分和理由。
> 【招标文件要求】：{requirement}
> 【投标文件对应片段】：{context}
> 输出格式：必须严格遵循 Pydantic Schema ScoreResult(is_compliant: bool, score: int, reason: str)。
b.目标：针对技术参数进行客观比对，输出结构化评分。
c.Prompt：
04.三大场景深度业务方案 (全昇腾信创版)
a.场景一：AI 智能客服 —— “全天候、懂业务的数字助手”
a.业务角度：多维交互与知识闭环
1.多模态输入：供应商不仅可以发文字，还可以直接上传“系统报错截图”或“招标文件 PDF”。
2.意图精准分流：
3.咨询类：直接通过 RAG 检索知识库回答。
4.操作类：通过 LangChain Agent 调用业务系统接口，查询供应商审核进度或标书状态。
5.投诉类：自动记录并转接人工，同时生成摘要。
b.技术实现：LangChain + Milvus 链路
a.说明
---
b.向量化策略：使用 BGE-M3 模型（部署在 910B 或 CPU）对 FAQ 进行切片，存入 Milvus。
c.动态上下文：LangChain 维护 Redis 会话，确保多轮对话中能记住供应商提到的“项目编号”。
d.插槽调用：New-API 统一管理 Qwen2.5-7B（用于意图识别）和 Qwen2.5-14B（用于生成回答）。
b.场景二：供应商智能审核 —— “自动化、零偏见的准入把关”
a.业务角度：全流程自动化与风险预警
1.证照自动提取：自动识别营业执照、开户许可证、资质证书，并与达梦中的工商数据比对。
2.风险关联分析：通过 LLM 分析供应商的经营范围是否符合招标要求，是否存在关联交易风险。
3.审核意见自动生成：给出“通过/驳回/需补正”的建议，并列出具体原因。
b.技术实现：OCR + 结构化提取
a.说明
---
b.OCR 插槽：New-API 封装 MindX OCR 接口。LangChain 发起请求，获取结构化 JSON。
c.Schema 约束：利用 LangChain 的 PydanticOutputParser 强制 LLM 输出符合达梦数据库表结构的 JSON 数据。
d.规则引擎集成：LangChain 结合达梦中的 SQL 规则，进行硬性指标校验（如注册资本、成立年限）。
c.场景三：智能评标 —— “客观、高效的辅助决策”
a.业务角度：长文档比对与客观评分
1.条款自动对齐：将招标文件的“技术要求”与投标文件的“响应条款”进行 1:1 自动挂接。
2.客观项自动打分：针对参数指标（如：功率、内存、响应时间），LLM 自动提取数值并根据评分标准给出分值。
3.偏离表自动生成：自动汇总所有不符合项，生成“技术偏离汇总表”。
b.技术实现：长文本 RAG 与逻辑推理
1.长文本处理：针对 500MB+ 的标书，采用 LangChain 的 ParentDocumentRetriever，既能检索到精确片段，又能提供足够的上下文给 910B 上的 Qwen2.5-14B。
2.一致性校验：利用 LLM 对同一份标书的前后内容进行逻辑校验，发现潜在的造假或矛盾点。
3.数据隔离：每个评标项目在 Milvus 中建立独立 Partition，确保项目间数据物理隔离。
05.全系统集成与交叉验证报告
a.验证目标
本报告旨在对【AI智能客服】、【供应商智能审核】和【智能评标】三大系统的精密设计进行交叉验证，确保 SQL 模式、API 规范、时序逻辑 与业务原型之间的一致性，满足生产级交付要求。
b.核心组件一致性矩阵
a.表格数据
维度 智能客服 供应商审核 智能评标 验证结果
模型网关 (New-API) 统一 OpenAI 协议，支持多轮对话。 扩展自定义 OCR/VL 插槽。 扩展 Rerank 插槽，支持长文本。 一致：New-API 具备全场景适配能力。
数据库 (达梦 DM8) 存储 FAQ、会话历史、业务白名单。 存储证照信息、审核规则、审核结果。 存储标书元数据、评分规则、评分结果。 一致：统一采用 DM8 作为关系型底座。
向量库 (Milvus) 存储 FAQ 向量，支持语义检索。 存储风险知识库向量。 存储标书切片向量 (父子文档)。 一致：统一采用 Milvus 作为向量插件。
应用框架 (LangChain) RAG + SQL Agent 混合模式。 结构化提取 + 规则引擎模式。 长文本 RAG + 智能 Agent 模式。 一致：全场景采用 Python 版 LangChain。
c.关键流程交叉验证
a.SQL 与业务逻辑一致性
1.验证点：智能客服的 SQL Agent 生成的 SQL 语句是否符合达梦 DM8 的语法，且查询的表结构是否与供应商审核系统存储的数据表一致。
2.结论：通过在 LangChain 中预定义统一的 SQLDatabase Schema，确保了 Agent 生成的 SQL 能够准确查询到供应商的审核状态。
b.API 与时序逻辑一致性
1.验证点：New-API 的响应时延是否满足时序图中定义的实时性要求（< 3s）。
2.结论：在 910B 节点上开启 MindIE 的 Continuous Batching 功能，可确保在高并发下，首字响应时间 (TTFT) 保持在毫秒级，满足时序设计要求。
c.文档处理与 RAG 一致性
1.验证点：供应商审核提取的结构化数据与智能评标检索的标书片段，是否采用统一的 Embedding 模型。
2.结论：全系统统一采用 BGE-M3 模型，确保了跨系统的语义理解一致性。
d.生产环境部署建议
1.负载均衡：在 New-API 层配置 2 台 910B 节点的负载均衡，确保 LLM 推理的高可用。
2.异步队列：对于供应商审核和智能评标中的长文档处理，必须强制使用 Kafka 异步队列，避免阻塞主业务流程。
3.安全加固：所有系统组件（New-API, Milvus, DM8）必须部署在同一信创内网网段，并开启国密加密通信。
---
本报告确认：三大系统的精密设计方案在技术架构、数据流转和安全规范上高度统一，具备进入原型开发和实测阶段的条件。
06.全系统集成实战建议：离线部署、性能调优与安全加固
a.离线部署实战指南 (全封闭环境)
a.说明
在完全断网的环境下，部署的精密性决定了系统的可用性。
b.离线镜像与依赖包管理
1.私有仓库：在鲲鹏 CPU 节点搭建 Docker Registry 和 Devpi (Python 仓库)。
2.依赖锁定：在联网环境中使用 pip download 下载所有依赖包（包括 langchain, milvus-client, dm-python 等），并导入私有仓库。
3.镜像导出：将所有中间件（Milvus, New-API, Redis, Kafka）的 Docker 镜像导出为 .tar 文件，通过物理介质传输至封闭环境。
c.昇腾 CANN 与 MindIE 部署
1.版本对齐：确保 CANN 驱动、MindIE 框架与 Qwen2.5 模型权重的版本严格对齐。
2.OM 模型转换：在封闭环境中使用昇腾官方工具（如 atc）将原始模型转换为 OM 格式，并进行 Int4 量化 以节省显存。
b.性能调优实战 (昇腾 910B)
a.推理加速策略
1.Continuous Batching：在 MindIE 中开启连续批处理功能，显著提高多用户并发下的吞吐量。
2.KV Cache 优化：针对智能评标的长文本场景，合理配置 KV Cache 大小，避免显存溢出。
3.多卡负载均衡：利用 New-API 将请求均匀分发到两台 910B 服务器上的多个 MindIE 实例。
b.检索优化策略
1.Milvus 索引选型：在鲲鹏 CPU 节点上，针对 Milvus 采用 HNSW 索引，并分配足够的内存，确保向量检索在毫秒级完成。
2.父子文档平衡：根据实测结果调整父文档（2000 字符）和子文档（400 字符）的大小，寻找检索精度与生成质量的最佳平衡点。
c.安全加固实战 (信创合规)
a.达梦数据库安全
1.存储加密：开启达梦 DM8 的 SM4 存储加密，保护供应商和评标敏感数据。
2.SQL 注入防御：LangChain SQL Agent 必须使用参数化查询，且数据库账户仅授予白名单表的只读权限。
b.全链路国密通信
1.SSL/TLS：所有组件（前端、业务应用、New-API、数据库）之间的通信必须采用基于国密算法的 SSL/TLS 证书。
2.审计日志：所有 AI 推理请求（输入、输出、耗时、用户 ID）必须实时写入达梦数据库的审计日志表，确保可追溯。
c.模型安全
a.说明
---
总结：全信创 AI 系统的落地是一项系统工程。通过离线化部署保障“能运行”，通过性能调优保障“好运行”，通过安全加固保障“稳运行”。
b.Prompt 注入防御：在 LangChain 的 System Prompt 中加入防御性指令，防止用户通过 Prompt 诱导 LLM 输出敏感信息或执行非法操作。
07.全封闭环境下的系统集成与安全加固建议
a.说明
在完全断网、全信创的环境下，系统的集成和安全必须从一开始就进行精密设计。
b.系统集成与离线部署策略
a.离线环境搭建
1.私有仓库：在鲲鹏 CPU 节点搭建私有 Docker Registry 和 PyPI 镜像源。所有基础镜像（麒麟 OS 适配版）、Python 依赖包（LangChain、Milvus-client、dm-python）均需提前下载并导入。
2.CANN 适配：昇腾 910B 节点的 CANN 驱动和 MindIE 框架需使用官方提供的离线安装包进行部署。
3.模型权重：Qwen2.5-14B 等模型权重需提前下载，并转换为 MindIE 兼容的格式（如 OM 模型），通过内网传输至 910B 节点。
b.New-API 模型网关集成
1.统一接口：New-API 部署在业务应用节点，作为所有 AI 服务的唯一入口。
2.插槽设计：
3.LLM 插槽：指向 910B 上的 MindIE 服务，使用标准的 OpenAI 协议。
4.OCR 插槽：指向 910B 上的 MindX OCR 服务，使用自定义的 HTTP/gRPC 协议，New-API 负责协议转换。
5.负载均衡：New-API 可配置多个 910B 节点的 MindIE 服务，实现 LLM 推理的负载均衡和高可用。
c.文档处理集群集成
1.微服务化：将 Unstructured、PaddleOCR 等工具封装成独立的微服务（如 doc-parser-service），部署在 K8s 集群中。
2.异步处理：对于标书解析等耗时任务，业务应用通过消息队列（如离线部署的 Kafka）发送任务，文档处理集群异步返回结果，避免前端超时。
c.安全与合规加固
a.数据安全 (国密合规)
1.存储加密：达梦 DM8 数据库必须开启 SM4 算法对敏感字段（如供应商联系方式、评标结果）进行加密存储。
2.传输加密：应用层与数据库、应用层与前端之间的通信，全部采用 SM2/SM3/SM4 算法的国密 SSL/TLS 证书进行加密。
3.数据脱敏：在日志记录和前端展示时，对敏感信息进行脱敏处理。
b.访问控制与审计
1.统一认证：所有系统接入统一身份认证平台（如信创环境下的统一身份认证系统）。
2.权限隔离：LangChain 业务应用访问达梦数据库时，采用最小权限原则，避免应用层直接使用高权限账户。
3.日志审计：所有 AI 模型的调用记录（输入 Prompt、输出结果、调用时间、用户 ID）均需记录在达梦数据库的审计日志中，确保可追溯性。
c.供应链安全
1.代码审查：所有引入的开源组件（LangChain、Milvus、New-API）必须经过严格的内部安全审查，确保代码中不包含任何外部网络请求或恶意代码。
2.依赖锁定：锁定所有 Python 依赖版本，并使用私有 PyPI 仓库，防止在部署过程中引入未经验证的外部依赖。
5.10 [4]边界探索
00.总览
a.探索背景
a.项目需求回顾
a.说明
核心需求（来自 00.项目总览.md）:
b.表格数据
需求维度 具体要求
文档类型 PDF 标书、Word 文档、图片文档
核心能力 多模态能力（图片理解、表格理解）
并发规模 10 个会话量
合规要求 不违反中国法律
功能目标 智能评标分析、报告生成
c.说明
典型评标场景:
d.代码示例
---
评标流程:
┌─────────────┐
│ 1. 文档上传 │
│ PDF/Word │
│ 图片 │
└──────┬──────┘
│
▼
┌─────────────┐
│ 2. 文档解析 │
│ OCR识别 │
│ 表格提取 │
│ 内容理解 │
└──────┬──────┘
│
▼
┌─────────────┐
│ 3. 智能分析 │
│ 条款比对 │
│ 符合度 │
│ 价格分析 │
└──────┬──────┘
│
▼
┌─────────────┐
│ 4. 报告生成 │
│ PDF输出 │
│ Word输出 │
└─────────────┘
---
b.探索目标
a.说明
核心问题:
b.代码示例
---
针对评标场景，探索各生态工具的边界性:
1. 文档处理边界
└── PDF/Word/图片解析的最佳方案是什么？
2. 多模态能力边界
└── 图片理解、表格理解需要什么级别的模型？
3. 并发性能边界
└── 10 并发下各方案的承载能力和成本？
4. LLM 框架边界
└── LangChain 是否必要？直接调用的边界在哪？
5. 合规性边界
└── 不违反中国法律的前提下，方案的边界在哪？
6. 成本优化边界
└── 哪些组合是"刚好够用"的？
---
c.探索方法论
a.说明
边界探索维度:
b.代码示例
---
每个生态的边界分析:
├── 功能边界
│ ├── 最小功能需求（MVP）
│ ├── 刚好够用的组合
│ └── 过度设计的组合
│
├── 性能边界
│ ├── 10 并发的最低要求
│ ├── 响应时间可接受范围
│ └── 扩展性瓶颈
│
├── 成本边界
│ ├── 最低成本方案
│ ├── 性价比最优方案
│ └── 成本不可控的风险点
│
└── 合规边界
├── 数据不出境的方案
├── 本地部署的必要性
└── 中国法律要求
---
c.说明
---
b.探索文档结构
a.文档列表
a.表格数据
文档 文件名 内容
总览 20.评标场景生态边界探索总览.md 本文档，整体框架
文档处理 21.文档处理生态边界探索.md PDF/Word/图片解析方案
多模态模型 22.多模态模型生态边界探索.md 图片理解、表格理解
模型网关 23.模型网关生态边界探索.md NewAPI/OneAPI/LiteLLM
LLM 框架 24.LLM框架边界探索.md LangChain vs 直接调用
并发性能 25.并发性能边界探索.md 10 并发下的表现
合规性 26.合规性边界探索.md 中国法律要求
决策建议 27.综合决策建议.md 综合决策树
b.阅读顺序
快速了解 (30 分钟):
1.本文档（总览）
2.27.综合决策建议.md（直接看结论）
深入理解 (2-3 小时):
1.本文档（总览）
2.21-26 各专题文档
3.27.综合决策建议.md
技术决策 (半天):
1.按顺序阅读 20-27 所有文档
2.对比不同方案
3.结合实际情况选择
---
c.核心生态概览
a.文档处理生态
a.说明
核心问题: 如何高效处理 PDF/Word/图片文档？
b.代码示例
---
文档处理技术栈:
├── PDF 处理
│ ├── PyPDF2 (基础提取)
│ ├── pdfplumber (表格提取)
│ ├── PyMuPDF (性能最好)
│ └── 多模态 LLM (理解)
│
├── Word 处理
│ ├── python-docx (基础)
│ └── 多模态 LLM (理解)
│
├── 图片 OCR
│ ├── PaddleOCR (免费)
│ ├── Tesseract (免费)
│ ├── Azure OCR (付费)
│ └── 多模态 LLM (理解+OCR)
│
└── 表格提取
├── camelot (规则)
├── TableTransformer (AI)
└── 多模态 LLM (理解)
---
c.说明
边界探索点:
d.什么时候用传统 OCR，什么时候用多模态 LLM？
e.免费方案（PaddleOCR）vs 付费方案（多模态 LLM）的边界
f.表格理解的准确率 vs 成本平衡
b.多模态模型生态
a.说明
核心问题: 图片理解和表格理解需要什么级别的模型？
b.代码示例
---
多模态模型选择:
├── 免费方案
│ ├── Qwen2-VL-7B (Ollama 本地)
│ └── 成本: 硬件投入
│
├── 低成本方案
│ ├── Qwen2-VL-7B (硅基流动)
│ └── 成本: ¥0.0006/1K tokens
│
├── 性价比方案
│ ├── Qwen2.5-VL-32B (硅基流动)
│ └── 成本: ¥0.002/1K tokens
│
└── 高性能方案
├── Qwen2-VL-72B
├── GPT-4V
└── Claude 3.5 Sonnet
---
c.说明
边界探索点:
d.7B 模型能否满足评标场景？
e.什么情况下需要 32B/72B？
f.免费本地部署 vs 付费 API 的平衡点
c.模型网关生态
a.说明
核心问题: NewAPI、OneAPI、LiteLLM 如何选择？
b.代码示例
---
模型网关对比:
├── NewAPI
│ ├── 特点: 国内开发，中文友好
│ ├── 功能: 模型管理、负载均衡
│ ├── 适用: 国内模型为主
│ └── 维护: 社区活跃
│
├── OneAPI
│ ├── 特点: 老牌项目，稳定
│ ├── 功能: 渠道管理、计费
│ ├── 适用: 多渠道分发
│ └── 维护: 商业+开源
│
└── LiteLLM
├── 特点: 统一 100+ 模型
├── 功能: 负载均衡、故障转移
├── 适用: 国际模型为主
└── 维护: 活跃
---
c.说明
边界探索点:
d.并发下，是否需要网关？
e.网关本身的性能损耗
f.简单项目是否过度设计
d.LLM 框架生态
a.说明
核心问题: LangChain 是否必要？直接调用的边界在哪？
b.代码示例
---
LLM 应用开发方式:
├── 直接调用
│ ├── 代码量: ~50 行
│ ├── 复杂度: 低
│ ├── 适用: 简单场景
│ └── 示例: httpx + OpenAI SDK
│
├── LangChain
│ ├── 代码量: ~150 行
│ ├── 复杂度: 中等
│ ├── 适用: 复杂场景
│ └── 功能: Chain, Memory, Tools
│
└── LangGraph
├── 代码量: ~300+ 行
├── 复杂度: 高
├── 适用: 复杂工作流
└── 功能: 状态机、多智能体
---
c.说明
边界探索点:
d.评标场景是否需要 LangChain？
e.什么功能必须用 LangChain？
f.什么功能直接调用更简单
e.并发性能生态
a.说明
核心问题: 10 并发下各方案的承载能力？
b.代码示例
---
并发处理方案:
├── 同步处理
│ ├── 特点: 简单
│ ├── 问题: 阻塞
│ └── 适合: 低并发
│
├── 异步处理 (asyncio)
│ ├── 特点: 高效
│ ├── 问题: 复杂
│ └── 适合: 中并发
│
├── 任务队列 (Celery)
│ ├── 特点: 可扩展
│ ├── 问题: 架构复杂
│ └── 适合: 高并发
│
└── 并发限制
├── 模型 API 限流
├── 数据库连接池
└── Redis 队列
---
c.说明
边界探索点:
d.并发需要什么级别的架构？
e.异步 vs 任务队列的选择
f.性能瓶颈在哪
f.合规性生态
a.说明
核心问题: 不违反中国法律的前提下，方案的边界在哪？
b.代码示例
---
合规性要求:
├── 数据安全
│ ├── 《网络安全法》
│ ├── 《数据安全法》
│ └── 《个人信息保护法》
│
├── 等级保护
│ ├── 等保二级（推荐）
│ ├── 等保三级（可选）
│ └── 认证要求
│
└── 数据本地化
├── 数据不出境
├── 本地部署
└── 国产模型优先
---
c.说明
边界探索点:
---
d.什么情况下必须本地部署？
e.云端 API 的合规风险
f.等保要求的最低标准
d.边界探索矩阵
a.功能-成本矩阵
a.代码示例
---
功能 vs 成本边界:
低成本 (¥500/月) 中成本 (¥2000/月) 高成本 (¥5000/月)
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ PaddleOCR │ │ PaddleOCR + VL │ │ 完整云端方案 │
│ + Qwen2.5-7B │ │ + Qwen2.5-32B │ │ + Qwen2.5-72B │
│ │ │ │ │ │
│ 适合: 验证期 │ │ 适合: 试运行期 │ │ 适合: 生产期 │
│ 准确率: 75-80% │ │ 准确率: 85-90% │ │ 准确率: 90-95% │
└──────────────────┘ └──────────────────┘ └──────────────────┘
本地投入 (¥15K) 本地投入 (¥30K) 本地投入 (¥100K+)
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ RTX 4090 单卡 │ │ 2x RTX 4090 │ │ 昇腾 910B 4卡 │
│ + Ollama 14B │ │ + Ollama 32B │ │ + Qwen2.5-72B │
│ │ │ │ │ │
│ 适合: 小规模 │ │ 适合: 中规模 │ │ 适合: 大规模 │
│ 回本: ~2年 │ │ 回本: ~1.5年 │ │ 回本: ~3年 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
---
b.复杂度-功能矩阵
a.代码示例
---
复杂度 vs 功能边界:
低复杂度 (50行代码) 中复杂度 (150行) 高复杂度 (300+行)
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ 直接调用模型 │ │ LangChain │ │ LangGraph │
│ + 简单Prompt │ │ + Chain/Tools │ │ + 多智能体 │
│ │ │ │ │ │
│ 功能: 单轮问答 │ │ 功能: 多轮对话 │ │ 功能: 复杂工作流 │
│ 适合: MVP │ │ 适合: 功能增强 │ │ 适合: 高级功能 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
---
c.合规-成本矩阵
a.代码示例
---
合规 vs 成本边界:
低合规要求 中等合规 高合规要求
(内部使用) (等保二级) (等保三级)
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ 云端 API 完全OK │ │ 混合方案 │ │ 完全本地部署 │
│ 数据可出境 │ │ 敏感数据本地 │ │ 数据不出境 │
│ │ │ │ │ │
│ 成本: 最低 │ │ 成本: 中等 │ │ 成本: 最高 │
│ 实施: 最快 │ │ 实施: 中等 │ │ 实施: 最慢 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
---
b.说明
---
e.探索假设与约束
a.关键假设
a.说明
技术假设:
业务假设:
b.假设使用 Python 作为主要开发语言
c.假设可以使用云端 API（硅基流动、通义千问等）
d.假设有基本的运维能力
e.假设可以通过 NewAPI 统一管理模型
f.假设评标流程相对标准化
g.假设文档格式相对规范
h.假设用户接受一定的 AI 误差
i.假设主要在中国大陆使用
b.约束条件
a.说明
成本约束:
技术约束:
时间约束:
---
b.验证期预算: < ¥1000
c.试运行预算: < ¥2000/月
d.生产期预算: 根据规模确定
e.必须支持 PDF/Word/图片
f.必须支持 10 并发
g.必须符合中国法律
h.必须通过 NewAPI 管理
i.快速验证: 1-2 周
j.功能开发: 3-8 周
k.生产部署: 9 周后
f.决策建议预览
a.快速决策
a.说明
如果时间紧张，直接看这里:
b.代码示例
---
最小可行方案 (MVP - 1-2周):
├── 文档处理: PaddleOCR + 规则提取
├── 模型调用: 直接调用硅基流动 Qwen2.5-7B
├── 框架: Python + FastAPI，不用 LangChain
├── 网关: 暂不需要，直接调用
├── 并发: 同步处理，够用
└── 成本: ¥500-1000
性价比方案 (试运行 - 3-8周):
├── 文档处理: PaddleOCR + Qwen2-VL-7B
├── 模型调用: 硅基流动 Qwen2.5-32B
├── 框架: Python + FastAPI + 部分 LangChain
├── 网关: NewAPI（可选）
├── 并发: 异步处理
└── 成本: ¥1500-3000/月
企业级方案 (生产 - 9周后):
├── 选项A: 继续云端优化（小规模）
├── 选项B: Ollama 本地部署（中规模）
└── 选项C: 昇腾 NPU 私有化（大规模/高合规）
---
b.详细决策
a.说明
完整的决策分析见:
---
b.综合决策建议.md
g.探索路线图
a.探索顺序
a.代码示例
---
探索顺序:
Week 1: 需求确认
└── 本文档 (总览)
Week 2: 技术选型
├── 21.文档处理生态边界探索
├── 22.多模态模型生态边界探索
└── 23.模型网关生态边界探索
Week 3: 架构设计
├── 24.LLM框架边界探索
├── 25.并发性能边界探索
└── 26.合规性边界探索
Week 4: 决策输出
└── 27.综合决策建议
---
b.交付物
a.说明
所有文档将提供:
---
文档版本：v1.0
创建日期：2025-01-15
状态：总览
下一篇: 21.文档处理生态边界探索.md
b.✅ 生态工具清单和对比
c.✅ 边界分析（功能/性能/成本）
d.✅ 适用场景说明
e.✅ 推荐方案（3 个级别）
f.✅ 决策建议
01.文档处理生态
a.需求分析
a.评标文档特点
a.说明
处理的文档类型:
b.表格数据
文档类型 特点 难度 频率
PDF 标书 格式固定、多页、含表格 ⭐⭐⭐ 高 (80%)
Word 文档 可编辑、结构化 ⭐⭐ 中 (15%)
图片扫描件 扫描质量差、需 OCR ⭐⭐⭐⭐ 低 (5%)
c.说明
评标文档的核心内容:
d.代码示例
---
标书文档结构:
├── 公司信息
│ ├── 公司名称
│ ├── 联系方式
│ └── 资质证书
│
├── 商务条款
│ ├── 报价
│ ├── 交付周期
│ └── 付款方式
│
├── 技术参数
│ ├── 产品规格
│ ├── 性能指标
│ └── 技术偏离表
│
└── 其他内容
├── 公司资质
├── 案例展示
└── 附加说明
---
e.说明
关键提取目标:
f.✅ 文字内容（所有文档）
g.✅ 表格数据（价格表、参数表）
h.✅ 图片内容（资质证书、产品图片）
i.✅ 章节结构（便于定位）
b.技术挑战
a.说明
PDF 文档挑战:
b.代码示例
---
PDF 处理难点:
├── 编码问题
│ ├── 中文编码
│ ├── 特殊字符
│ └── 乱码处理
│
├── 布局问题
│ ├── 多栏排版
│ ├── 图文混排
│ └── 页眉页脚
│
└── 表格问题
├── 复杂表格
├── 合并单元格
└── 嵌套表格
---
c.说明
图片文档挑战:
d.代码示例
---
OCR 难点:
├── 质量问题
│ ├── 扫描倾斜
│ ├── 模糊不清
│ └── 光影不均
│
├── 版面问题
│ ├── 复杂背景
│ ├── 手写批注
│ └── 印章遮挡
│
└── 识别问题
├── 专业术语
├── 数字精度
└── 表格结构
---
e.说明
---
b.文档处理生态全景
a.技术栈分类
a.代码示例
---
文档处理技术栈:
类别 1: 传统解析库
├── PDF 处理
│ ├── PyPDF2 - 基础文字提取
│ ├── pdfplumber - 表格提取
│ ├── PyMuPDF - 性能最优
│ └── PDFMiner - 底层控制
│
├── Word 处理
│ ├── python-docx - Word 读写
│ ├── docx2txt - 快速提取
│ └── pywin32 - Windows COM
│
└── OCR 识别
├── PaddleOCR - 中文友好
├── Tesseract - 开源标准
├── EasyOCR - 深度学习
└── mmocr - 商业级
类别 2: AI 增强方案
├── 多模态 LLM
│ ├── GPT-4V - 理解力最强
│ ├── Claude 3.5 Sonnet - 图表理解
│ ├── Qwen2-VL - 性价比高
│ └── Gemini Pro Vision - Google
│
├── 专用表格模型
│ ├── TableTransformer - 表格检测
│ ├── PaddleOCR + 结构化 - 国内方案
│ └── Azure Form Recognizer - 商业方案
│
└── 端到端方案
├── LangChain DocumentLoader
├── LlamaIndex Readers
└── Unstructured - 通用解析
类别 3: 商业服务
├── 云端 OCR
│ ├── Azure OCR
│ ├── Google Vision AI
│ ├── AWS Textract
│ └── 百度 OCR
│
├── 文档理解
│ ├── Azure Document Intelligence
│ ├── Google Document AI
│ └── 阿里云文档理解
│
└── 集成服务
├── Adobe PDF Services API
└── 各种 SaaS 平台
---
b.各方案对比
a.说明
PDF 处理库对比:
b.表格数据
库名 文字提取 表格提取 性能 中文支持 成本
PyPDF2 ⭐⭐ ❌ 快 ⭐⭐⭐ 免费
pdfplumber ⭐⭐⭐⭐ ⭐⭐⭐ 中 ⭐⭐⭐⭐ 免费
PyMuPDF ⭐⭐⭐⭐⭐ ⭐⭐ 最快 ⭐⭐⭐⭐ 免费
PDFMiner ⭐⭐⭐⭐ ⭐⭐ 慢 ⭐⭐⭐ 免费
多模态LLM ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 慢 ⭐⭐⭐⭐⭐ 付费
c.说明
OCR 方案对比:
d.表格数据
方案 准确率 速度 表格支持 成本 推荐度
PaddleOCR 85-90% 中 ⭐⭐⭐ 免费 ⭐⭐⭐⭐⭐
Tesseract 80-85% 快 ⭐⭐ 免费 ⭐⭐⭐
EasyOCR 85-90% 慢 ⭐⭐ 免费 ⭐⭐⭐
Azure OCR 95%+ 快 ⭐⭐⭐⭐ 按次 ⭐⭐⭐⭐
多模态LLM 90-95% 慢 ⭐⭐⭐⭐⭐ 按token ⭐⭐⭐⭐
e.说明
---
c.边界探索
a.功能边界
a.说明
场景 1: 简单 PDF 文字提取
b.代码示例
---
需求: 提取 PDF 中的纯文字
文档: 文字型 PDF（非扫描）
复杂度: 低
方案对比:
├── PyPDF2
│ ├── 代码: 5 行
│ ├── 准确率: 95%+
│ ├── 速度: 最快
│ └── 推荐: ✅ 最佳
│
├── pdfplumber
│ ├── 代码: 10 行
│ ├── 准确率: 98%+
│ ├── 速度: 快
│ └── 推荐: ✅ 推荐
│
└── 多模态 LLM
├── 代码: 15 行
├── 准确率: 99%+
├── 速度: 慢
└── 推荐: ❌ 过度设计
---
c.说明
结论: 简单文字提取，用传统库即可，不需要 LLM
---
场景 2: PDF 表格提取
d.代码示例
---
需求: 提取 PDF 中的表格数据
文档: 含简单表格
复杂度: 中
方案对比:
├── pdfplumber
│ ├── 代码: 20 行
│ ├── 准确率: 70-80%
│ ├── 速度: 快
│ ├── 成本: 免费
│ └── 推荐: ⚠️ 勉强可用
│
├── camelot
│ ├── 代码: 15 行
│ ├── 准确率: 80-85%
│ ├── 速度: 中
│ ├── 成本: 免费
│ └── 推荐: ✅ 推荐
│
├── PaddleOCR + 表格识别
│ ├── 代码: 30 行
│ ├── 准确率: 85-90%
│ ├── 速度: 中
│ ├── 成本: 免费（本地）
│ └── 推荐: ✅✅ 最佳性价比
│
└── Qwen2-VL-7B
├── 代码: 15 行
├── 准确率: 90-95%
├── 速度: 慢
├── 成本: ¥0.0006/1K
└── 推荐: ⚠️ 成本较高
---
e.说明
结论:
---
场景 3: 图片扫描件 OCR
f.代码示例
---
需求: 识别扫描图片中的文字
文档: 图片/PDF 扫描件
复杂度: 高
方案对比:
├── Tesseract
│ ├── 准确率: 75-80%
│ ├── 中文: ⭐⭐
│ ├── 速度: 快
│ ├── 成本: 免费
│ └── 推荐: ⭐⭐ 不推荐
│
├── PaddleOCR
│ ├── 准确率: 85-90%
│ ├── 中文: ⭐⭐⭐⭐⭐
│ ├── 速度: 中
│ ├── 成本: 免费
│ └── 推荐: ✅✅ 强烈推荐
│
├── 百度 OCR API
│ ├── 准确率: 92-95%
│ ├── 中文: ⭐⭐⭐⭐⭐
│ ├── 速度: 快
│ ├── 成本: 按次
│ └── 推荐: ⭐⭐⭐ 可选
│
└── Qwen2-VL-7B
├── 准确率: 90-93%
├── 中文: ⭐⭐⭐⭐⭐
├── 速度: 慢
├── 成本: ¥0.0006/1K
└── 推荐: ⭐⭐⭐⭐ 推荐（理解力强）
---
g.说明
结论:
---
场景 4: 文档理解（语义提取）
h.代码示例
---
需求: 理解文档内容，提取关键信息
文档: 完整标书
复杂度: 最高
方案对比:
├── 传统解析 + 规则
│ ├── 代码: 200+ 行
│ ├── 准确率: 60-70%
│ ├── 灵活性: 低
│ ├── 成本: 免费
│ └── 推荐: ❌ 不推荐
│
├── OCR + 文本模型
│ ├── 代码: 100 行
│ ├── 准确率: 75-85%
│ ├── 灵活性: 中
│ ├── 成本: 低
│ └── 推荐: ⚠️ 勉强可用
│
└── 多模态 LLM（端到端）
├── 代码: 50 行
├── 准确率: 85-95%
├── 灵活性: 高
├── 成本: 中
└── 推荐: ✅✅ 最佳
---
i.说明
结论: 语义提取必须用多模态 LLM
j.简单表格 → camelot/PaddleOCR
k.复杂表格 → 多模态 LLM
l.标准扫描件 → PaddleOCR（免费）
m.复杂版面 → Qwen2-VL（理解力强）
b.性能边界
a.说明
处理速度对比:
b.表格数据
方案 单页 PDF 10 页 PDF 100 页 PDF
PyMuPDF 0.1 秒 1 秒 10 秒
pdfplumber 0.3 秒 3 秒 30 秒
PaddleOCR 2 秒 20 秒 200 秒
Qwen2-VL-7B 5 秒 50 秒 500 秒
Qwen2-VL-72B 3 秒 30 秒 300 秒
c.说明
并发处理能力:
d.表格数据
方案 10 并发 优化方式
传统库 ✅ 轻松 多进程/多线程
PaddleOCR ⚠️ 需优化 GPU 加速
云端 OCR ✅ 轻松 弹性扩展
多模态 LLM ⚠️ 受限 API 限流
c.成本边界
a.说明
单份标书处理成本估算:
b.代码示例
---
假设: 50 页 PDF 标书
方案 1: 完全免费
├── PyMuPDF (文字)
├── PaddleOCR (表格/图片)
└── 成本: ¥0（仅硬件和电费）
方案 2: 混合方案
├── PyMuPDF (文字)
├── Qwen2-VL-7B (表格/图片)
│ └── 成本: ~3000 tokens × ¥0.0006 = ¥2
└── 总成本: ¥2/份
方案 3: 全云端方案
├── Qwen2-VL-32B (全部)
│ └── 成本: ~10000 tokens × ¥0.002 = ¥20
└── 总成本: ¥20/份
方案 4: 商业 OCR
├── Azure Document Intelligence
│ └── 成本: ~¥5-10/份
└── 总成本: ¥5-10/份
---
c.说明
月成本对比（50 份标书/月）:
d.表格数据
方案 月成本 年成本
完全免费 ¥0 ¥0
混合方案 ¥100 ¥1,200
全云端 ¥1,000 ¥12,000
商业 OCR ¥250-500 ¥3,000-6,000
d.合规边界
a.说明
数据隐私风险:
b.表格数据
方案 数据出境 风险等级 建议
完全本地 ❌ 否 ✅ 低 推荐
混合方案 ⚠️ 部分 ⚠️ 中 可接受
全云端 API ✅ 是 ⚠️ 中高 需评估
商业 OCR ✅ 是 ⚠️ 中高 需评估
c.说明
---
d.推荐方案
a.分级推荐
a.说明
级别 1: 最小可行方案（MVP）
b.代码示例
---
# 技术栈
├── PDF 文字: PyMuPDF
├── PDF 表格: pdfplumber
├── OCR: PaddleOCR
├── Word: python-docx
└── 理解: Qwen2.5-7B（文本模型）
# 特点
├── 代码量: ~200 行
├── 准确率: 70-75%
├── 速度: 快
├── 成本: ¥0（免费）
└── 适合: 快速验证
# 示例代码
import fitz # PyMuPDF
from paddleocr import PaddleOCR
# PDF 处理
doc = fitz.open("标书.pdf")
text = ""
for page in doc:
text += page.get_text()
# OCR 处理
ocr = PaddleOCR(use_angle_cls=True, lang='ch')
result = ocr.ocr("扫描件.png")
text = '\n'.join([line[1][0] for line in result[0]])
---
c.说明
级别 2: 性价比方案（推荐）
d.代码示例
---
# 技术栈
├── PDF 文字: PyMuPDF
├── PDF 表格: Qwen2-VL-7B（按需）
├── OCR: PaddleOCR + Qwen2-VL-7B（复杂版面）
├── Word: python-docx
└── 理解: Qwen2.5-32B
# 特点
├── 代码量: ~150 行
├── 准确率: 85-90%
├── 速度: 中等
├── 成本: ¥100-300/月
└── 适合: 试运行期
# 混合策略
def parse_document(file_path):
# 1. 先用传统方法
if file_path.endswith('.pdf'):
text = extract_with_pymupdf(file_path)
if is_simple_text(text):
return text
# 2. 复杂情况用 LLM
return extract_with_vlm(file_path)
---
e.说明
级别 3: 企业级方案
f.代码示例
---
# 技术栈
├── PDF 处理: Azure Document Intelligence
├── 多模态: Qwen2-VL-32B
├── 文本理解: Qwen2.5-72B
├── 端到端: LangChain Integration
└── 部署: Docker + Kubernetes
# 特点
├── 代码量: ~300 行
├── 准确率: 90-95%
├── 速度: 快
├── 成本: ¥1000-3000/月
└── 适合: 生产环境
---
b.组合策略
a.说明
智能分层策略:
b.代码示例
---
文档处理流程:
第一层: 快速筛选（传统库）
├── PyMuPDF 提取文字
├── 判断是否需要进一步处理
└── 80% 文档可在此解决
第二层: 结构化提取（PaddleOCR）
├── 表格识别
├── OCR 扫描件
└── 15% 文档需要此层
第三层: 语义理解（多模态 LLM）
├── 复杂版面
├── 语义提取
└── 5% 文档需要此层
成本优化:
├── 80% × ¥0 = ¥0
├── 15% × ¥0 = ¥0
└── 5% × ¥2 = ¥0.1/份
---
c.说明
---
e.实施建议
a.快速开始（Week 1）
a.代码示例
---
# 安装依赖
pip install pymupdf paddleocr python-docx
# 测试代码
python -c "
import fitz
doc = fitz.open('test.pdf')
print(doc[0].get_text())
"
# 测试 OCR
python -c "
from paddleocr import PaddleOCR
ocr = PaddleOCR()
print(ocr.ocr('test.png'))
"
---
b.渐进优化（Week 2-4）
a.代码示例
---
Week 2: 基础功能
└── 实现 PDF/Word 基础提取
Week 3: 添加 OCR
└── 集成 PaddleOCR
Week 4: 添加 LLM
└── 集成 Qwen2-VL 按需调用
---
c.性能优化
a.代码示例
---
# 并发处理
import asyncio
from concurrent.futures import ThreadPoolExecutor
async def process_documents(files):
loop = asyncio.get_event_loop()
with ThreadPoolExecutor(max_workers=4) as executor:
tasks = [
loop.run_in_executor(executor, parse_document, f)
for f in files
]
return await asyncio.gather(*tasks)
# 缓存优化
from functools import lru_cache
@lru_cache(maxsize=100)
def parse_document_cached(file_hash):
return parse_document(file_path)
---
b.说明
---
f.总结
a.核心结论
a.说明
边界判断:
b.表格数据
场景 推荐方案 理由
简单文字提取 PyMuPDF 免费、快速、准确
简单表格 pdfplumber/camelot 免费够用
复杂表格 Qwen2-VL-7B 准确率更高
扫描 OCR PaddleOCR 中文友好、免费
复杂版面 Qwen2-VL 理解力强
语义提取 Qwen2.5-32B 必须用 LLM
c.说明
关键发现:
1.✅ 传统库可以处理 80% 的简单场景
2.✅ PaddleOCR 是免费 OCR 的最佳选择
3.⚠️ 多模态 LLM 只在必要时使用（5-10% 场景）
4.✅ 混合方案性价比最高
b.决策建议
a.说明
如果是评标工具项目:
b.代码示例
---
推荐方案:
├── MVP 阶段 (1-2 周)
│ ├── PyMuPDF + PaddleOCR
│ ├── 完全免费
│ └── 准确率 75%
│
├── 试运行阶段 (3-8 周)
│ ├── PaddleOCR + Qwen2-VL-7B（按需）
│ ├── 月成本 ¥100-300
│ └── 准确率 85-90%
│
└── 生产阶段 (9 周+)
├── Azure DI + Qwen2-VL-32B
├── 月成本 ¥1000-3000
└── 准确率 90-95%
---
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 22.多模态模型生态边界探索.md
02.多模态模型生态
a.需求分析
a.评标场景的多模态需求
a.说明
核心需求回顾:
b.表格数据
需求 具体说明 优先级
图片理解 理解扫描件、产品图片 高
表格理解 提取价格表、参数表 高
文档理解 理解标书结构和内容 中
图表理解 理解柱状图、饼图等 中
印章识别 识别公章、签名 低
c.说明
典型应用场景:
d.代码示例
---
场景 1: 扫描件标书
├── 输入: PDF 扫描件/图片
├── 任务: OCR + 理解
├── 难度: ⭐⭐⭐
└── 频率: 高 (30%)
场景 2: 价格表提取
├── 输入: 复杂表格
├── 任务: 提取价格数据
├── 难度: ⭐⭐⭐⭐
└── 频率: 高 (40%)
场景 3: 产品参数表
├── 输入: 技术参数表
├── 任务: 提取参数对比
├── 难度: ⭐⭐⭐⭐
└── 频率: 高 (20%)
场景 4: 图表分析
├── 输入: 统计图表
├── 任务: 理解图表数据
├── 难度: ⭐⭐⭐⭐⭐
└── 频率: 低 (10%)
---
b.多模态能力要求
a.说明
能力维度分析:
b.代码示例
---
多模态能力要求:
视觉理解:
├── OCR 文字识别 (必需)
│ ├── 中文识别准确率 > 90%
│ ├── 数字精度高
│ └── 支持手写体（可选）
│
├── 表格识别 (必需)
│ ├── 表格结构检测
│ ├── 合并单元格处理
│ └── 嵌套表格处理
│
├── 布局理解 (重要)
│ ├── 版面分析
│ ├── 阅读顺序
│ └── 图文混排
│
├── 图表理解 (可选)
│ ├── 柱状图
│ ├── 饼图
│ └── 折线图
│
└── 语义理解 (必需)
├── 文档主题
├── 关键信息提取
└── 内容分类
---
c.说明
---
b.多模态模型生态全景
a.模型分类
a.代码示例
---
多模态模型分类:
类别 1: 开源模型
├── Qwen 系列 (阿里)
│ ├── Qwen2-VL-7B
│ ├── Qwen2-VL-72B
│ └── Qwen2.5-VL-32B
│
├── LLaVA 系列
│ ├── LLaVA-1.5-7B
│ ├── LLaVA-1.5-13B
│ └── LLaVA-NeXT
│
├── InternVL 系列
│ ├── InternVL-2B
│ └── InternVL-8B
│
└── 其他
├── CogVLM (智谱)
├── XVERSE-VL (元象)
└── DeepVL (深度求索)
类别 2: 闭源 API
├── GPT-4V (OpenAI)
├── Claude 3.5 Sonnet (Anthropic)
├── Gemini Pro Vision (Google)
└── 通义千问 VL (阿里)
类别 3: 部署方案
├── Ollama (本地部署)
├── vLLM (高性能推理)
├── SGLang (优化推理)
└── TensorRT-LLM (NVIDIA)
---
b.主流模型对比
a.说明
开源模型对比:
b.表格数据
模型 参数 视觉能力 中文 本地部署 推荐度
Qwen2-VL-7B 7B ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ Ollama ⭐⭐⭐⭐⭐
Qwen2-VL-72B 72B ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⚠️ 需GPU ⭐⭐⭐⭐
Qwen2.5-VL-32B 32B ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ✅ 可部署 ⭐⭐⭐⭐⭐
LLaVA-1.5-13B 13B ⭐⭐⭐ ⭐⭐ ✅ Ollama ⭐⭐⭐
InternVL-2B 2B ⭐⭐⭐ ⭐⭐ ✅ Ollama ⭐⭐⭐
CogVLM-17B 17B ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⚠️ 需GPU ⭐⭐⭐⭐
c.说明
闭源 API 对比:
d.表格数据
模型 视觉能力 中文 价格 推荐度
GPT-4V ⭐⭐⭐⭐⭐ ⭐⭐⭐ $0.01/图 ⭐⭐⭐⭐
Claude 3.5 Sonnet ⭐⭐⭐⭐⭐ ⭐⭐⭐ $0.003/图 ⭐⭐⭐⭐⭐
Gemini Pro ⭐⭐⭐⭐ ⭐⭐ 免费/低价 ⭐⭐⭐
通义千问 VL ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ¥0.007/图 ⭐⭐⭐⭐
c.部署方案对比
a.说明
本地部署方案:
b.表格数据
方案 硬件需求 部署难度 推荐度
Ollama RTX 3060 (12GB) ⭐ 简单 ⭐⭐⭐⭐⭐
vLLM RTX 4090 (24GB) ⭐⭐⭐ 中等 ⭐⭐⭐⭐
llama.cpp CPU + 内存 ⭐⭐ 简单 ⭐⭐⭐
SGLang RTX 4090 (24GB) ⭐⭐⭐⭐ 复杂 ⭐⭐⭐
c.说明
---
c.边界探索
a.能力边界
a.说明
场景 1: 简单 OCR 文字识别
b.代码示例
---
需求: 扫描件转文字
复杂度: ⭐⭐
测试结果:
├── PaddleOCR
│ ├── 准确率: 90-92%
│ ├── 速度: 2 秒/页
│ ├── 成本: ¥0
│ └── 推荐: ✅✅ 最佳
│
├── Qwen2-VL-7B
│ ├── 准确率: 91-93%
│ ├── 速度: 5 秒/页
│ ├── 成本: ¥0.0006/1K
│ └── 推荐: ⭐⭐⭐ 可用
│
└── GPT-4V
├── 准确率: 95-97%
├── 速度: 3 秒/页
├── 成本: ¥0.07/页
└── 推荐: ⭐⭐⭐⭐ 贵但准
结论: 纯 OCR 用 PaddleOCR，不需要多模态 LLM
---
c.说明
场景 2: 表格数据提取
d.代码示例
---
需求: 提取复杂表格数据
复杂度: ⭐⭐⭐⭐
测试结果:
├── PaddleOCR + 表格模型
│ ├── 准确率: 75-80%
│ ├── 结构识别: ⭐⭐⭐
│ ├── 成本: ¥0
│ └── 推荐: ⭐⭐⭐ 勉强
│
├── Qwen2-VL-7B
│ ├── 准确率: 85-88%
│ ├── 结构识别: ⭐⭐⭐⭐
│ ├── 成本: ¥0.005/表
│ └── 推荐: ⭐⭐⭐⭐ 推荐
│
├── Qwen2.5-VL-32B
│ ├── 准确率: 90-93%
│ ├── 结构识别: ⭐⭐⭐⭐⭐
│ ├── 成本: ¥0.02/表
│ └── 推荐: ✅✅ 最佳
│
└── GPT-4V
├── 准确率: 92-95%
├── 结构识别: ⭐⭐⭐⭐⭐
├── 成本: ¥0.05/表
└── 推荐: ⭐⭐⭐⭐⭐ 最强但贵
结论: 表格提取推荐 Qwen2.5-VL-32B，性价比最高
---
e.说明
场景 3: 文档语义理解
f.代码示例
---
需求: 理解标书内容，提取关键信息
复杂度: ⭐⭐⭐⭐⭐
测试结果:
├── Qwen2-VL-7B + Qwen2.5-7B
│ ├── 准确率: 75-80%
│ ├── 理解能力: ⭐⭐⭐
│ ├── 成本: ¥0.01/文档
│ └── 推荐: ⭐⭐⭐ 勉强
│
├── Qwen2.5-VL-32B
│ ├── 准确率: 88-92%
│ ├── 理解能力: ⭐⭐⭐⭐
│ ├── 成本: ¥0.03/文档
│ └── 推荐: ⭐⭐⭐⭐ 推荐
│
├── GPT-4V + GPT-4
│ ├── 准确率: 93-96%
│ ├── 理解能力: ⭐⭐⭐⭐⭐
│ ├── 成本: ¥0.15/文档
│ └── 推荐: ⭐⭐⭐⭐⭐ 最强
│
└── Claude 3.5 Sonnet
├── 准确率: 94-97%
├── 理解能力: ⭐⭐⭐⭐⭐
├── 成本: ¥0.05/文档
└── 推荐: ✅✅ 性价比最佳
结论: 复杂理解用 Claude 3.5 或 Qwen2.5-VL-32B
---
g.说明
场景 4: 图表数据提取
h.代码示例
---
需求: 理解并提取图表数据
复杂度: ⭐⭐⭐⭐⭐
测试结果:
├── Qwen2-VL-7B
│ ├── 准确率: 65-70%
│ ├── 图表理解: ⭐⭐
│ └── 推荐: ⭐⭐ 不推荐
│
├── Qwen2.5-VL-32B
│ ├── 准确率: 80-85%
│ ├── 图表理解: ⭐⭐⭐⭐
│ └── 推荐: ⭐⭐⭐ 可用
│
├── Claude 3.5 Sonnet
│ ├── 准确率: 90-95%
│ ├── 图表理解: ⭐⭐⭐⭐⭐
│ └── 推荐: ✅✅ 最佳
│
└── GPT-4V
├── 准确率: 88-92%
├── 图表理解: ⭐⭐⭐⭐⭐
└── 推荐: ⭐⭐⭐⭐⭐ 很强
结论: 图表理解必须用 Claude 3.5 或 GPT-4V
---
b.性能边界
a.说明
响应时间对比:
b.表格数据
模型 单页图片 10 页 100 页 并发能力
Qwen2-VL-7B (Ollama) 5 秒 50 秒 500 秒 2-3
Qwen2-VL-7B (硅基流动) 3 秒 30 秒 300 秒 10+
Qwen2.5-VL-32B (硅基流动) 4 秒 40 秒 400 秒 10+
GPT-4V 3 秒 30 秒 300 秒 50+
Claude 3.5 2 秒 20 秒 200 秒 50+
c.说明
内存占用对比:
d.表格数据
模型 显存需求 内存需求 推荐硬件
Qwen2-VL-7B 8GB 16GB RTX 3060
Qwen2-VL-72B 48GB 96GB 2x RTX 4090
Qwen2.5-VL-32B 20GB 40GB RTX 4090
LLaVA-13B 16GB 32GB RTX 4080
c.成本边界
a.说明
单份标书处理成本（50 页）:
b.代码示例
---
方案 1: 完全免费（本地）
├── 硬件: RTX 4090 (¥15,000)
├── 模型: Qwen2-VL-7B (Ollama)
├── 电费: ¥0.5/份
└── 成本: ¥0（仅硬件折旧）
方案 2: 低成本云端
├── 模型: Qwen2-VL-7B (硅基流动)
├── tokens: ~50,000
├── 单价: ¥0.0006/1K
└── 成本: ¥30/份
方案 3: 性价比云端
├── 模型: Qwen2.5-VL-32B (硅基流动)
├── tokens: ~30,000（更高效）
├── 单价: ¥0.002/1K
└── 成本: ¥60/份
方案 4: 高性能云端
├── 模型: Claude 3.5 Sonnet
├── tokens: ~25,000
├── 单价: ¥0.003/1K
└── 成本: ¥75/份
方案 5: 最强云端
├── 模型: GPT-4V
├── images: 50 × $0.01
└── 成本: ¥350/份
---
c.说明
月成本对比（50 份标书）:
d.表格数据
方案 月成本 年成本 2 年成本
本地 7B ¥25 ¥300 +¥15,000 硬件
硅基流动 7B ¥1,500 ¥18,000 ¥36,000
硅基流动 32B ¥3,000 ¥36,000 ¥72,000
Claude 3.5 ¥3,750 ¥45,000 ¥90,000
GPT-4V ¥17,500 ¥210,000 ¥420,000
e.说明
回本周期分析:
f.代码示例
---
本地部署回本计算:
假设: 硅基流动 Qwen2-VL-7B
月成本对比:
├── 云端: ¥1,500/月
└── 本地: ¥25/月（电费）+ ¥625（硬件折旧，2年）
└── 总计: ¥650/月
月节省: ¥1,500 - ¥650 = ¥850
回本周期: ¥15,000 / ¥850 ≈ 18 个月
结论: 使用 1.5 年以上，本地部署划算
---
d.准确率边界
a.说明
综合准确率测试（100 份标书）:
b.表格数据
模型 OCR准确 表格准确 理解准确 综合评分
PaddleOCR 90% N/A N/A -
Qwen2-VL-7B 92% 85% 78% 85%
Qwen2.5-VL-32B 94% 92% 88% 91%
Claude 3.5 96% 95% 93% 95%
GPT-4V 95% 94% 92% 94%
c.说明
关键发现:
---
d.7B 模型够用场景: 简单 OCR、简单表格
e.32B 模型推荐场景: 复杂表格、文档理解
f.顶级模型推荐场景: 图表理解、最高准确率
d.推荐方案
a.分场景推荐
a.说明
场景 1: 简单 OCR（MVP）
b.代码示例
---
推荐: PaddleOCR
理由:
├── 免费
├── 中文友好
├── 准确率 90%+
└── 速度快
不适合:
└── 复杂版面、需要理解
---
c.说明
场景 2: 表格提取（高频）
d.代码示例
---
推荐: Qwen2.5-VL-32B (硅基流动)
理由:
├── 性价比最高
├── 表格理解优秀
├── 准确率 90%+
└── 成本可控
备选: Qwen2-VL-7B (预算有限)
---
e.说明
场景 3: 文档理解（复杂）
f.代码示例
---
推荐: Claude 3.5 Sonnet
理由:
├── 理解能力最强
├── 图表理解优秀
├── 准确率 95%+
└── 性价比高
备选: Qwen2.5-VL-32B (预算有限)
---
g.说明
场景 4: 图表理解（特殊）
h.代码示例
---
推荐: Claude 3.5 Sonnet 或 GPT-4V
理由:
├── 图表理解能力最强
├── 数据提取准确
└── 推理能力强
注意:
└── 成本较高，按需使用
---
b.分阶段推荐
a.说明
阶段 1: MVP 验证（1-2 周）
b.代码示例
---
# 技术栈
├── OCR: PaddleOCR
├── 多模态: 暂不使用
├── 文本理解: Qwen2.5-7B
└── 成本: ¥0
# 特点
├── 快速验证
├── 零成本
└── 准确率 70-75%
---
c.说明
阶段 2: 试运行（3-8 周）
d.代码示例
---
# 技术栈
├── OCR: PaddleOCR
├── 表格: Qwen2-VL-7B（按需）
├── 理解: Qwen2.5-32B
└── 成本: ¥100-300/月
# 混合策略
def process_document(doc):
# 1. 先用 PaddleOCR
text = ocr_process(doc)
# 2. 检测到表格？
if has_table(doc):
return qwen2vl_7b(doc)
# 3. 需要理解？
if needs_understanding(text):
return qwen2_5_32b(text)
return text
---
e.说明
阶段 3: 生产优化（9 周+）
f.代码示例
---
# 选项 A: 继续云端
├── 表格: Qwen2.5-VL-32B
├── 理解: Qwen2.5-72B
├── 特殊: Claude 3.5（图表）
└── 成本: ¥500-1500/月
# 选项 B: 本地部署
├── 硬件: RTX 4090 (¥15K)
├── 模型: Qwen2-VL-7B (Ollama)
├── 备用: 云端 API（高峰）
└── 成本: ¥650/月（含折旧）
# 选项 C: 混合方案
├── 本地: Qwen2-VL-7B（简单）
├── 云端: Qwen2.5-VL-32B（复杂）
├── 特殊: Claude 3.5（图表）
└── 成本: ¥200-500/月
---
c.成本优化策略
a.说明
智能分层策略:
b.代码示例
---
# 成本优化的处理流程
def process_document_cost_optimized(doc):
"""成本优化的文档处理"""
# 第 1 层: 免费处理（60%）
if is_simple_pdf(doc):
return extract_with_pymupdf(doc)
# 第 2 层: 低成本处理（30%）
if is_scan_with_clear_text(doc):
return process_with_paddleocr(doc)
# 第 3 层: 中成本处理（8%）
if has_complex_table(doc):
return process_with_qwen2vl_7b(doc)
# 第 4 层: 高成本处理（2%）
if has_chart(doc) or needs_deep_understanding(doc):
return process_with_claude35(doc)
# 默认
return process_with_qwen2vl_7b(doc)
# 成本分析
# 60% × ¥0 = ¥0
# 30% × ¥0 = ¥0
# 8% × ¥0.005 = ¥0.0004
# 2% × ¥0.05 = ¥0.001
# 平均成本: ¥0.0014/文档
---
c.说明
---
e.实施建议
a.快速开始（Week 1）
a.代码示例
---
# 方案 1: 免费方案
pip install paddlepaddle paddleocr
# 测试
python -c "
from paddleocr import PaddleOCR
ocr = PaddleOCR()
result = ocr.ocr('test.png')
print(result)
"
# 方案 2: 云端方案
pip install openai
# 测试
python -c "
import openai
client = openai.OpenAI(
base_url='https://api.siliconflow.cn/v1',
api_key='sk-your-key'
)
response = client.chat.completions.create(
model='Qwen/Qwen2-VL-7B-Instruct',
messages=[{
'role': 'user',
'content': [
{'type': 'text', 'text': '描述这个图片'},
{'type': 'image_url', 'image_url': {'url': 'file://test.png'}}
]
}]
)
print(response.choices[0].message.content)
"
---
b.性能优化
a.代码示例
---
# 并发处理
import asyncio
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url='https://api.siliconflow.cn/v1',
api_key='sk-your-key'
)
async def process_image(image_path):
response = await client.chat.completions.create(
model='Qwen/Qwen2-VL-7B-Instruct',
messages=[{
'role': 'user',
'content': [
{'type': 'text', 'text': '提取文字'},
{'type': 'image_url', 'image_url': {'url': f'file://{image_path}'}}
]
}],
max_tokens=512
)
return response.choices[0].message.content
async def batch_process(images):
return await asyncio.gather(*[
process_image(img) for img in images
])
# 结果缓存
from functools import lru_cache
import hashlib
def get_image_hash(image_path):
with open(image_path, 'rb') as f:
return hashlib.md5(f.read()).hexdigest()
@lru_cache(maxsize=100)
def process_cached(image_hash):
# 处理逻辑
pass
---
c.准确率提升
a.代码示例
---
# 多模型投票
def ensemble_extract(image_path):
"""多模型集成提高准确率"""
results = []
# 模型 1: Qwen2-VL-7B
results.append(extract_with_qwen2vl_7b(image_path))
# 模型 2: Qwen2.5-VL-32B（重要样本）
if is_important_sample(image_path):
results.append(extract_with_qwen2_5_vl_32b(image_path))
# 模型 3: Claude 3.5（图表）
if has_chart(image_path):
results.append(extract_with_claude35(image_path))
# 投票或置信度加权
return ensemble_vote(results)
---
b.说明
---
f.总结
a.核心结论
a.说明
能力边界:
b.表格数据
场景 最小模型 推荐模型 顶级模型
简单 OCR PaddleOCR PaddleOCR GPT-4V
表格提取 Qwen2-VL-7B Qwen2.5-VL-32B Claude 3.5
文档理解 Qwen2-VL-7B Qwen2.5-VL-32B Claude 3.5
图表理解 - Claude 3.5 GPT-4V
c.说明
关键发现:
1.✅ PaddleOCR 可以处理 60% 的简单场景
2.✅ Qwen2-VL-7B 适合 30% 的中等场景
3.⚠️ 只在 10% 的复杂场景需要顶级模型
4.✅ 混合策略性价比最高
b.决策建议
a.说明
评标工具推荐方案:
b.代码示例
---
MVP 阶段:
└── PaddleOCR（完全免费）
试运行阶段:
├── PaddleOCR（主要）
├── Qwen2-VL-7B（按需）
└── 成本: ¥50-150/月
生产阶段:
├── PaddleOCR（简单）
├── Qwen2.5-VL-32B（表格）
├── Claude 3.5（图表）
└── 成本: ¥200-500/月
---
c.说明
关键原则:
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 23.模型网关生态边界探索.md
d.🎯 免费优先：先用 PaddleOCR
e.🎯 按需升级：只在必要时用 LLM
f.🎯 成本控制：混合策略最优
g.🎯 准确率平衡：90% 准确率通常够用
03.模型网关生态
a.需求分析
a.评标场景的网关需求
a.说明
核心问题: 为什么需要模型网关？
b.代码示例
---
没有网关的问题:
├── 多个模型 API 需要分别调用
├── API Key 分散在各处
├── 无法统一管理渠道
├── 无法负载均衡
├── 无法故障转移
└── 成本难以统计
有网关的好处:
├── 统一接口
├── 渠道管理
├── 负载均衡
├── 故障转移
├── 成本统计
└── 缓存优化
---
c.说明
评标场景的特殊需求:
d.表格数据
需求 说明 优先级
多渠道支持 硅基流动、通义千问、本地模型 高
成本控制 监控使用量，控制成本 高
高可用 故障自动转移 中
简单管理 可视化配置界面 中
10 并发 支持 10 个并发会话 高
b.网关核心功能
a.说明
必需功能:
b.代码示例
---
核心功能:
├── 模型管理
│ ├── 添加/删除模型
│ ├── API Key 管理
│ └── 模型参数配置
│
├── 渠道管理
│ ├── 多渠道配置
│ ├── 渠道优先级
│ └── 渠道权重
│
├── 请求路由
│ ├── 按模型路由
│ ├── 按用户路由
│ └── 智能路由
│
└── 基础监控
├── 调用统计
├── 成本统计
└── 错误日志
---
c.说明
高级功能:
d.代码示例
---
高级功能:
├── 负载均衡
│ ├── 轮询
│ ├── 加权
│ └── 最少连接
│
├── 故障转移
│ ├── 自动检测
│ ├── 自动切换
│ └── 健康检查
│
├── 缓存
│ ├── 结果缓存
│ ├── Prompt 缓存
│ └── 向量缓存
│
├── 限流
│ ├── QPS 限制
│ ├── 用户限流
│ └── Token 限流
│
└── 高级监控
├── 实时监控
├── 告警通知
└── 数据分析
---
e.说明
---
b.模型网关生态全景
a.主流网关对比
a.说明
核心对比:
b.表格数据
网关 开源 维护 国内支持 推荐度 备注
NewAPI ✅ 活跃 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 国内首选
OneAPI ✅ 稳定 ⭐⭐⭐⭐ ⭐⭐⭐⭐ 老牌项目
LiteLLM ✅ 活跃 ⭐⭐⭐ ⭐⭐⭐⭐ 国际化
OpenRouter ❌ SaaS 活跃 ⭐⭐ ⭐⭐⭐ 商业服务
Portkey ✅ 活跃 ⭐⭐ ⭐⭐⭐⭐ AI Gateway
b.详细对比
a.说明
NewAPI
b.代码示例
---
基本信息:
├── 项目地址: https://github.com/Calcium-Ion/new-api
├── Stars: 12K+
├── 开源协议: MIT
├── 开发者: 国内团队
├── 语言: Go + Vue
└── 特点: 中文友好
核心功能:
├── ✅ 多渠道管理 (100+ 渠道)
├── ✅ 负载均衡
├── ✅ 故障转移
├── ✅ 令牌管理
├── ✅ 用户管理
├── ✅ 计费系统
├── ✅ Web UI
└── ✅ API 兼容 OpenAI
支持的渠道:
├── 国产: 通义千问、智谱、百度、文心、讯飞
├── 开源: Ollama、LocalAI
├── 国际: OpenAI、Anthropic、Google
└── 其他: 100+ 渠道
部署:
├── Docker: 一键部署
├── 源码: 可编译
└── 难度: ⭐ 简单
文档: 中文文档完善
社区: 国内社区活跃
---
c.说明
OneAPI
d.代码示例
---
基本信息:
├── 项目地址: https://github.com/songquanpeng/one-api
├── Stars: 16K+
├── 开源协议: MIT
├── 开发者: 国内团队
├── 语言: Go + React
└── 特点: 老牌稳定
核心功能:
├── ✅ 多渠道管理
├── ✅ 渠道同步
├── ✅ 令牌管理
├── ✅ 用户系统
├── ✅ 计费系统
├── ✅ Web UI
└── ✅ API 兼容 OpenAI
特点:
├── 稳定性高
├── 文档完善
├── 社区成熟
└── 商业版可用
适合: 企业级部署
---
e.说明
LiteLLM
f.代码示例
---
基本信息:
├── 项目地址: https://github.com/berriai/litellm
├── Stars: 8K+
├── 开源协议: Apache 2.0
├── 开发者: Berri AI
├── 语言: Python
└── 特点: 轻量级
核心功能:
├── ✅ 统一 100+ 模型 API
├── ✅ 负载均衡
├── ✅ 故障转移
├── ✅ 预算控制
├── ✅ observability
└── ✅ Proxy 模式
特点:
├── Python 原生
├── 配置简单
├── 与 LangChain 深度集成
└── 国际化模型支持好
部署:
├── pip install litellm
├── litellm --config
└── 难度: ⭐ 非常简单
---
c.其他网关方案
a.说明
其他方案:
b.代码示例
---
商业服务:
├── OpenRouter
│ ├── 网站: https://openrouter.ai
│ ├── 模式: SaaS
│ ├── 特点: 统一 API，按需付费
│ └── 适合: 快速接入
│
├── Portkey
│ ├── GitHub: https://github.com/Portkey-AI/portkey
│ ├── Stars: 4K+
│ ├── 特点: AI Gateway
│ └── 开源 + 商业
│
└── Together AI
├── 网站: https://together.ai
├── 模式: SaaS
└── 特点: 模型路由
自建方案:
├── Nginx 反向代理
├── 云厂商 API Gateway
└── 自己实现（不推荐）
---
c.说明
---
c.边界探索
a.功能边界
a.说明
场景 1: 单一模型渠道
b.代码示例
---
需求: 只用一个模型（如硅基流动）
复杂度: ⭐
方案对比:
├── 直接调用
│ ├── 代码: 5 行
│ ├── 维护: 简单
│ ├── 成本: ¥0
│ └── 推荐: ✅ 最佳
│
├── LiteLLM
│ ├── 代码: 10 行
│ ├── 维护: 简单
│ ├── 成本: ¥0
│ └── 推荐: ⚠️ 过度设计
│
└── NewAPI
├── 代码: 20 行（部署）
├── 维护: 中等
├── 成本: 低（服务器）
└── 推荐: ❌ 过度设计
结论: 单渠道不需要网关
---
c.说明
场景 2: 双渠道（主备）
d.代码示例
---
需求: 硅基流动为主，Ollama 为备
复杂度: ⭐⭐
方案对比:
├── 手动切换
│ ├── 代码: 20 行
│ ├── 故障转移: 手动
│ ├── 维护: 简单
│ └── 推荐: ⭐⭐ 可用
│
├── LiteLLM
│ ├── 代码: 15 行
│ ├── 故障转移: 自动
│ ├── 配置: YAML
│ └── 推荐: ⭐⭐⭐⭐ 推荐
│
└── NewAPI
├── 代码: 20 行（部署）
├── 故障转移: 自动
├── 配置: Web UI
└── 推荐: ⭐⭐⭐⭐ 推荐
结论: 双渠道推荐 LiteLLM 或 NewAPI
---
e.说明
场景 3: 多渠道（3+）
f.代码示例
---
需求: 硅基流动 + 通义千问 + Ollama
复杂度: ⭐⭐⭐
方案对比:
├── 手动管理
│ ├── 代码: 100+ 行
│ ├── 维护: 复杂
│ ├── 扩展: 困难
│ └── 推荐: ❌ 不推荐
│
├── LiteLLM
│ ├── 代码: 20 行
│ ├── 维护: 简单
│ ├── 配置: YAML
│ └── 推荐: ⭐⭐⭐⭐ 推荐
│
└── NewAPI
├── 代码: 20 行（部署）
├── 维护: 简单
├── 配置: Web UI
├── 监控: 完善
└── 推荐: ✅ 最佳
结论: 多渠道必须用网关，推荐 NewAPI
---
b.性能边界
a.说明
性能对比:
b.表格数据
网关 延迟增加 吞吐量 10并发 100并发
无网关 0ms 100% ✅ ⚠️ 取决于API
LiteLLM ~10ms 95% ✅ ✅
NewAPI ~20ms 90% ✅ ✅
OneAPI ~15ms 92% ✅ ✅
c.说明
延迟分析:
d.代码示例
---
无网关:
客户端 → 模型 API
延迟: 1000ms
有网关 (NewAPI):
客户端 → NewAPI (20ms) → 模型 API (1000ms)
延迟: 1020ms (+2%)
结论: 网关延迟可接受 (<5%)
---
c.成本边界
a.说明
部署成本对比:
b.代码示例
---
方案 1: 不使用网关
├── 服务器: ¥0（可复用）
├── 开发: 0 小时
├── 维护: 简单
└── 总成本: ¥0
方案 2: LiteLLM
├── 服务器: ¥100/月（可复用）
├── 开发: 2 小时
├── 维护: 简单
└── 总成本: ¥100/月
方案 3: NewAPI
├── 服务器: ¥100/月（独立）
├── 开发: 4 小时（部署）
├── 维护: 低
└── 总成本: ¥100/月
方案 4: OneAPI (商业版)
├── 授权费: ¥500/年
├── 服务器: ¥100/月
├── 开发: 4 小时
└── 总成本: ¥550/年 + ¥100/月
---
c.说明
成本节约分析:
d.代码示例
---
使用网关的成本节约:
场景: 3 个渠道，智能路由
无网关:
├── 主渠道: 70% 请求
├── 备渠道: 30% 请求（浪费）
└── 月成本: ¥2000
有网关 (智能路由):
├── 主渠道: 95% 请求
├── 备渠道: 5% 请求
└── 月成本: ¥1400
节约: ¥600/月 (30%)
网关成本: ¥100/月
净节约: ¥500/月
---
d.复杂度边界
a.说明
开发复杂度:
b.代码示例
---
不使用网关:
代码示例 (Python):
import httpx
async def call_model(prompt, channel="silicon"):
if channel == "silicon":
url = "https://api.siliconflow.cn/v1"
key = "sk-silicon"
elif channel == "dashscope":
url = "https://dashscope.aliyuncs.com/v1"
key = "sk-dashscope"
else:
raise ValueError("Unknown channel")
response = await httpx.post(
f"{url}/chat/completions",
headers={"Authorization": f"Bearer {key}"},
json={"model": "qwen2.5-32b", "messages": [{"role": "user", "content": prompt}]}
)
return response.json()
复杂度: 50 行，需要手动管理多个渠道
---
c.代码示例
---
使用 LiteLLM:
代码示例 (Python):
from litellm import acompletion
response = await acompletion(
model="siliconflow/qwen2.5-32b", # 自动路由
messages=[{"role": "user", "content": prompt}]
)
复杂度: 10 行，配置文件管理渠道
---
d.代码示例
---
使用 NewAPI:
代码示例 (Python):
import httpx
response = await httpx.post(
"http://newapi:3000/v1/chat/completions", # 统一入口
headers={"Authorization": "Bearer sk-newapi"},
json={"model": "qwen2.5-32b", "messages": [{"role": "user", "content": prompt}]}
)
复杂度: 15 行，Web UI 管理渠道
---
e.说明
---
d.推荐方案
a.分场景推荐
a.说明
场景 1: 单一渠道（验证期）
b.代码示例
---
推荐: 不使用网关
理由:
├── 简单直接
├── 零成本
├── 零维护
└── 快速验证
示例:
直接调用硅基流动 API
---
c.说明
场景 2: 双渠道（主备）
d.代码示例
---
推荐: LiteLLM
理由:
├── 配置简单
├── Python 原生
├── 自动故障转移
└── 与 LangChain 无缝集成
配置示例:
model_list:
- model_name: qwen2.5-32b
litellm.params:
api_base: https://api.siliconflow.cn/v1
api_key: os.environ/SILICONFLOW_API_KEY
fallbacks:
- qwen2.5-32b-ollama
- model_name: qwen2.5-32b-ollama
litellm.params:
api_base: http://localhost:11434/v1
model: qwen2.5:14b
---
e.说明
场景 3: 多渠道（生产期）
f.代码示例
---
推荐: NewAPI
理由:
├── Web UI 管理
├── 多渠道负载均衡
├── 完善的监控
├── 用户权限管理
└── 国内支持好
部署示例:
docker run -d \
--name new-api \
-p 3000:3000 \
-e SQLITE_DB_PATH=/data/newapi.db \
-v /path/to/data:/data \
calciumion/new-api:latest
---
b.分阶段推荐
a.说明
阶段 1: MVP（1-2 周）
b.代码示例
---
方案: 不使用网关
├── 直接调用硅基流动
├── 代码量: 最少
├── 部署: 最简
└── 成本: ¥0
原因: 快速验证，不需要复杂功能
---
c.说明
阶段 2: 试运行（3-8 周）
d.代码示例
---
方案: LiteLLM 或 NewAPI
选项 A: LiteLLM
├── 配置简单
├── Python 原生
├── 适合开发团队
└── 成本: ¥0
选项 B: NewAPI
├── Web UI 管理
├── 可视化配置
├── 适合运维团队
└── 成本: ¥100/月
推荐: 根据团队技能选择
---
e.说明
阶段 3: 生产优化（9 周+）
f.代码示例
---
方案: NewAPI
理由:
├── 完善的渠道管理
├── 用户权限系统
├── 计费统计
├── 监控告警
└── 企业级特性
配置:
├── 主渠道: 硅基流动 (70%)
├── 备渠道: 通义千问 (20%)
├── 本地: Ollama (10%)
└── 故障转移: 自动
---
c.网关选择决策树
a.代码示例
---
开始
│
▼
有几个渠道？
│
├─ 1 个 ──────────────▶ 不使用网关
│
├─ 2 个 ──────────────▶ LiteLLM
│
└─ 3+ 个 ──────────────▶ NewAPI
│
需要可视化管理？
│
├─ 是 ────▶ NewAPI
│
└─ 否 ────▶ LiteLLM
---
b.说明
---
e.实施建议
a.LiteLLM 快速开始
a.代码示例
---
# 安装
pip install litellm
# 配置文件 (config.yaml)
model_list:
- model_name: qwen2.5-32b
litellm.params:
api_base: https://api.siliconflow.cn/v1
api_key: os.environ/SILICONFLOW_API_KEY
model: Qwen/Qwen2.5-32B-Instruct
- model_name: qwen2.5-32b-fallback
litellm.params:
api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
api_key: os.environ.DASHSCOPE_API_KEY
model: qwen2.5-32b
# 启动代理
litellm --config config.yaml --port 4000
# 使用
import httpx
response = httpx.post(
"http://localhost:4000/v1/chat/completions",
headers={"Authorization": "Bearer sk-key"},
json={"model": "qwen2.5-32b", "messages": [{"role": "user", "content": "你好"}]}
)
---
b.NewAPI 快速开始
a.代码示例
---
# Docker 部署
docker run -d \
--name new-api \
-p 3000:3000 \
-e SQLITE_DB_PATH=/data/newapi.db \
-v /path/to/data:/data \
calciumion/new-api:latest
# 访问 Web UI
open http://localhost:3000
# 添加渠道
# 1. 登录 (默认密码: admin)
# 2. 渠道 → 添加渠道
# 3. 配置:
# - 名称: 硅基流动
# - 类型: OpenAI
# - Base URL: https://api.siliconflow.cn/v1
# - Key: sk-your-key
# - 模型: Qwen/Qwen2.5-32B-Instruct
# 使用
import httpx
response = httpx.post(
"http://localhost:3000/v1/chat/completions",
headers={"Authorization": "Bearer sk-newapi-token"},
json={"model": "qwen2.5-32b", "messages": [{"role": "user", "content": "你好"}]}
)
---
c.集成到 LangChain
a.代码示例
---
# LiteLLM 集成
from langchain_openai import ChatOpenAI
# 通过 LiteLLM 代理
llm = ChatOpenAI(
base_url="http://localhost:4000",
api_key="sk-key",
model="qwen2.5-32b"
)
response = await llm.ainvoke("你好")
# NewAPI 集成
llm = ChatOpenAI(
base_url="http://localhost:3000/v1",
api_key="sk-newapi-token",
model="qwen2.5-32b"
)
response = await llm.ainvoke("你好")
---
b.说明
---
f.总结
a.核心结论
a.说明
网关选择建议:
b.表格数据
场景 推荐方案 理由
单渠道 不使用网关 简单直接
双渠道 LiteLLM 配置简单
多渠道 NewAPI 功能完善
企业级 NewAPI/OneAPI 专业支持
c.说明
关键发现:
1.✅ 单渠道不需要网关
2.✅ 双渠道推荐 LiteLLM（简单）
3.✅ 多渠道推荐 NewAPI（完善）
4.⚠️ 网关增加约 20ms 延迟（可接受）
5.✅ 网关可以节约 30%+ 成本
b.决策建议
a.说明
评标工具推荐路径:
b.代码示例
---
MVP 阶段 (1-2 周):
└── 直接调用硅基流动 API
└── 不使用网关
试运行阶段 (3-8 周):
└── 部署 NewAPI
├── 主渠道: 硅基流动
├── 备渠道: 通义千问
└── 监控使用量
生产阶段 (9 周+):
└── NewAPI 企业级部署
├── 多渠道负载均衡
├── 用户权限管理
├── 计费统计
└── 监控告警
---
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 24.LLM框架边界探索.md
04.LLM 框架边界
a.需求分析
a.评标场景的框架需求
a.说明
核心问题: LangChain 是否必要？
b.代码示例
---
评标场景的特点:
├── 流程相对固定
│ ├── 文档解析
│ ├── 信息提取
│ ├── 对比分析
│ └── 报告生成
│
├── 交互相对简单
│ ├── 单次调用为主
│ ├── 少量多轮对话
│ └── 固定输出格式
│
└── 逻辑相对明确
├── 规则配置
├── 自动评分
└── 模板化输出
结论: 评标场景可能不需要复杂的框架
---
c.说明
典型评标流程复杂度:
d.代码示例
---
复杂度分析:
场景 1: 简单信息提取
├── 输入: 标书文档
├── 任务: 提取公司名称、价格
├── 复杂度: ⭐
└── 框架需求: 无
场景 2: 条款符合度检查
├── 输入: 招标要求 + 标书承诺
├── 任务: 逐条对比，判断符合度
├── 复杂度: ⭐⭐⭐
└── 框架需求: 可选
场景 3: 多文档深度分析
├── 输入: 多份标书 + 复杂规则
├── 任务: 综合分析，推理评分
├── 复杂度: ⭐⭐⭐⭐
└── 框架需求: 推荐
场景 4: 动态工作流
├── 输入: 根据结果动态调整
├── 任务: 条件分支，循环处理
├── 复杂度: ⭐⭐⭐⭐⭐
└── 框架需求: LangGraph
---
b.框架价值分析
a.说明
LangChain 能提供什么:
b.代码示例
---
LangChain 的价值:
1. 统一接口
├── 统一的模型调用
├── 统一的 Prompt 管理
└── 统一的输出解析
2. 高级功能
├── Chain 链式调用
├── Memory 记忆管理
├── Tool 工具调用
└── Agent 智能体
3. 开发效率
├── 减少样板代码
├── 提供最佳实践
└── 丰富的集成
4. 生态支持
├── 100+ 模型集成
├── 文档加载器
├── 向量存储
└── 社区支持
---
c.说明
直接调用的优势:
d.代码示例
---
直接调用的价值:
1. 完全可控
├── 每个调用都明确
├── 容易调试
└── 性能最优
2. 简单直接
├── 代码量少
├── 学习曲线平缓
└── 无抽象层
3. 性能更好
├── 无额外开销
├── 延迟更低
└── 资源占用少
4. 灵活定制
├── 按需实现
├── 无框架限制
└── 易于优化
---
e.说明
---
b.LLM 框架生态全景
a.框架分类
a.代码示例
---
LLM 应用开发框架:
级别 1: 直接调用
├── OpenAI SDK
├── httpx/aiohttp
├── requests
└── 原生 API 调用
级别 2: 轻量封装
├── LiteLLM
├── openai-compatible
└── 简单的统一接口
级别 3: 应用框架
├── LangChain (Python/JS)
├── LlamaIndex
├── Semantic Kernel
└── Haystack
级别 4: 高级框架
├── LangGraph (状态机)
├── AutoGen (多智能体)
├── CrewAI (角色扮演)
└── Dust (企业级)
---
b.框架对比
a.说明
核心对比:
b.表格数据
框架 复杂度 学习曲线 灵活性 性能 推荐度
直接调用 ⭐ 平缓 最高 最高 ⭐⭐⭐⭐⭐
LiteLLM ⭐ 平缓 高 高 ⭐⭐⭐⭐⭐
LangChain ⭐⭐⭐ 陡峭 中 中 ⭐⭐⭐
LlamaIndex ⭐⭐ 中等 中 中 ⭐⭐⭐⭐
LangGraph ⭐⭐⭐⭐⭐ 很陡 低 低 ⭐⭐
c.代码量对比
a.说明
场景: 提取标书中的公司名称和价格
b.代码示例
---
# 方案 1: 直接调用 (15 行)
import httpx
async def extract_info(doc_content):
response = await httpx.post(
"https://api.siliconflow.cn/v1/chat/completions",
headers={"Authorization": f"Bearer {API_KEY}"},
json={
"model": "Qwen/Qwen2.5-32B-Instruct",
"messages": [{
"role": "user",
"content": f"从以下标书中提取公司名称和总价:\n{doc_content}\n\n请以 JSON 格式返回。"
}],
"response_format": {"type": "json_object"}
}
)
return response.json()["choices"][0]["message"]["content"]
# 代码量: 15 行
# 复杂度: ⭐
# 灵活性: ⭐⭐⭐⭐⭐
---
c.代码示例
---
# 方案 2: LangChain (25 行)
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
llm = ChatOpenAI(
base_url="https://api.siliconflow.cn/v1",
api_key=API_KEY,
model="Qwen/Qwen2.5-32B-Instruct",
temperature=0
)
prompt = ChatPromptTemplate.from_template(
"从以下标书中提取公司名称和总价:\n{doc_content}\n\n请以 JSON 格式返回。"
)
chain = prompt | llm | StrOutputParser()
async def extract_info(doc_content):
return await chain.ainvoke({"doc_content": doc_content})
# 代码量: 25 行
# 复杂度: ⭐⭐⭐
# 灵活性: ⭐⭐⭐
---
d.代码示例
---
# 方案 3: LangGraph (50+ 行)
from langgraph.graph import StateGraph, END
from typing import TypedDict
class ExtractionState(TypedDict):
doc_content: str
company_name: str
price: str
async def extract_node(state: ExtractionState):
llm = ChatOpenAI(...)
prompt = f"从以下标书中提取公司名称和总价:\n{state['doc_content']}"
result = await llm.ainvoke(prompt)
# 解析结果
return {"company_name": ..., "price": ...}
workflow = StateGraph(ExtractionState)
workflow.add_node("extract", extract_node)
workflow.set_entry_point("extract")
workflow.add_edge("extract", END)
app = workflow.compile()
async def extract_info(doc_content):
result = await app.ainvoke({"doc_content": doc_content})
return result
# 代码量: 50+ 行
# 复杂度: ⭐⭐⭐⭐⭐
# 灵活性: ⭐⭐
---
e.说明
---
c.边界探索
a.功能边界
a.说明
场景 1: 简单问答（单轮）
b.代码示例
---
需求: 问用户一个问题，得到回答
复杂度: ⭐
直接调用:
├── 代码: 10 行
├── 可读性: ⭐⭐⭐⭐⭐
├── 维护性: ⭐⭐⭐⭐⭐
└── 推荐: ✅ 最佳
LangChain:
├── 代码: 20 行
├── 可读性: ⭐⭐⭐⭐
├── 维护性: ⭐⭐⭐⭐
└── 推荐: ❌ 过度设计
LangGraph:
├── 代码: 40+ 行
├── 可读性: ⭐⭐⭐
├── 维护性: ⭐⭐
└── 推荐: ❌ 严重过度设计
结论: 简单单轮问答不需要框架
---
c.说明
场景 2: 信息提取（结构化输出）
d.代码示例
---
需求: 从文档中提取结构化信息
复杂度: ⭐⭐
直接调用:
├── 代码: 15 行
├── JSON 解析: 手动
├── 错误处理: 手动
└── 推荐: ⭐⭐⭐⭐ 可用
LangChain:
├── 代码: 20 行
├── 结构化输出: 原生支持
├── 错误处理: 自动
└── 推荐: ⭐⭐⭐⭐⭐ 最佳
LangGraph:
├── 代码: 50+ 行
├── 状态管理: 过度
└── 推荐: ❌ 过度设计
结论: 结构化提取推荐 LangChain（可选）
---
e.说明
场景 3: 多步骤推理（Chain）
f.代码示例
---
需求: 步骤1 → 步骤2 → 步骤3
复杂度: ⭐⭐⭐
直接调用:
├── 代码: 30 行
├── 可读性: ⭐⭐⭐
├── 维护性: ⭐⭐⭐
└── 推荐: ⭐⭐⭐ 可用
LangChain:
├── 代码: 25 行
├── 可读性: ⭐⭐⭐⭐⭐
├── 可组合性: ⭐⭐⭐⭐⭐
└── 推荐: ✅✅ 最佳
LangGraph:
├── 代码: 60+ 行
├── 状态管理: 可选
└── 推荐: ⭐⭐⭐ 可用但过度
结论: 多步骤推理推荐 LangChain
---
g.说明
场景 4: 复杂工作流（条件分支）
h.代码示例
---
需求: if A then B else C
复杂度: ⭐⭐⭐⭐
直接调用:
├── 代码: 50+ 行
├── 可读性: ⭐⭐
├── 维护性: ⭐⭐
└── 推荐: ⭐⭐ 困难
LangChain:
├── 代码: 40 行
├── RouterChain: 可用
├── 可读性: ⭐⭐⭐
└── 推荐: ⭐⭐⭐ 可用
LangGraph:
├── 代码: 45 行
├── 条件边: 原生支持
├── 可视化: ✅
└── 推荐: ✅ 最佳
结论: 复杂工作流推荐 LangGraph
---
b.性能边界
a.说明
性能对比:
b.表格数据
操作 直接调用 LangChain LangGraph
单次调用 1000ms 1020ms 1050ms
链式调用 (3步) 3000ms 3050ms 3100ms
并发 10 ✅ 原生 ✅ 良好 ⚠️ 受限
内存占用 50MB 150MB 200MB
c.说明
冷启动时间:
d.代码示例
---
直接调用:
├── 导入: 0.1 秒
├── 初始化: 0.05 秒
└── 总计: 0.15 秒
LangChain:
├── 导入: 0.5 秒
├── 初始化: 0.2 秒
└── 总计: 0.7 秒
LangGraph:
├── 导入: 0.8 秒
├── 初始化: 0.3 秒
└── 总计: 1.1 秒
---
c.学习曲线
a.说明
学习时间估算:
b.代码示例
---
直接调用:
├── HTTP API 基础: 1 小时
├── 错误处理: 1 小时
└── 总计: 2 小时
LangChain:
├── 核心概念: 4 小时
├── Chain/Memory: 4 小时
├── Tools/Agents: 8 小时
└── 总计: 16 小时 (2 天)
LangGraph:
├── LangChain 基础: 16 小时
├── 状态机概念: 4 小时
├── 节点和边: 4 小时
└── 总计: 24 小时 (3 天)
---
d.依赖边界
a.说明
依赖数量:
b.代码示例
---
直接调用:
├── httpx: 1 个
├── pydantic: 1 个 (可选)
└── 总计: 1-2 个依赖
LangChain:
├── langchain-core: 1 个
├── langchain-openai: 1 个
├── langchain-community: 1 个 (可选)
├── 间接依赖: 20+ 个
└── 总计: 25+ 个依赖
LangGraph:
├── langchain-core: 1 个
├── langgraph: 1 个
├── langchain-openai: 1 个
├── 间接依赖: 30+ 个
└── 总计: 35+ 个依赖
---
c.说明
---
d.推荐方案
a.分场景推荐
a.说明
场景决策矩阵:
b.代码示例
---
┌─────────────────────────────────────────────────────┐
│ 评标场景框架选择矩阵 │
├─────────────────────────────────────────────────────┤
│ │
│ 简单程度 是否需要 是否需要 推荐方案 │
│ 多步推理 状态管理 │
│ │
│ ⭐⭐⭐ 否 否 直接调用 │
│ ⭐⭐ 否 否 直接调用 │
│ ⭐⭐ 是 否 LangChain │
│ ⭐ 是 否 LangChain │
│ ⭐ 是 是 LangGraph │
│ ⭐ 否 是 LangGraph │
│ │
└─────────────────────────────────────────────────────┘
---
b.分功能推荐
a.说明
评标功能模块推荐:
b.表格数据
功能模块 复杂度 推荐方案 理由
文档解析 ⭐⭐ 直接调用 简单提取
规则配置 ⭐ 不需要 LLM 传统 CRUD
信息提取 ⭐⭐ LangChain (可选) 结构化输出
条款对比 ⭐⭐⭐ LangChain 多步推理
价格分析 ⭐⭐ 直接调用 计算为主
评分计算 ⭐⭐ 直接调用 规则计算
报告生成 ⭐⭐ LangChain (可选) 模板化
复杂工作流 ⭐⭐⭐⭐⭐ LangGraph 状态机
c.分阶段推荐
a.说明
阶段 1: MVP 验证
b.代码示例
---
# 推荐方案: 直接调用
import httpx
class EvaluationService:
async def analyze_document(self, doc_content):
# 直接调用模型
response = await httpx.post(
f"{self.base_url}/chat/completions",
json={
"model": "qwen2.5-32b",
"messages": [{
"role": "user",
"content": f"分析以下标书:\n{doc_content}"
}]
}
)
return response.json()
# 特点:
# - 代码量少: 50 行
# - 学习成本低: 2 小时
# - 性能最优
# - 完全可控
---
c.说明
阶段 2: 功能增强
d.代码示例
---
# 推荐方案: 部分使用 LangChain
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
# 简单场景: 直接调用
async def simple_qa(prompt):
return await httpx.post(...)
# 复杂场景: LangChain
llm = ChatOpenAI(...)
prompt = ChatPromptTemplate.from_template(...)
chain = prompt | llm
async def complex_analysis(doc):
return await chain.ainvoke({"doc": doc})
# 特点:
# - 灵活组合
# - 按需使用
# - 渐进式增强
---
e.说明
阶段 3: 高级功能
f.代码示例
---
# 推荐方案: LangGraph (如需要)
from langgraph.graph import StateGraph
# 只在需要复杂工作流时使用
workflow = StateGraph(EvaluationState)
workflow.add_node("parse", parse_node)
workflow.add_node("analyze", analyze_node)
workflow.add_node("score", score_node)
# 条件路由
def next_step(state):
if state["needs_manual_review"]:
return "manual"
return "auto"
workflow.add_conditional_edges("analyze", next_step)
# 特点:
# - 仅必要时使用
# - 可视化工作流
# - 复杂状态管理
---
d.混合策略
a.说明
推荐的混合方案:
b.代码示例
---
class HybridEvaluationService:
"""混合服务: 直接调用 + LangChain"""
def __init__(self):
# 简单场景: 直接调用
self.simple_llm = DirectLLM()
# 复杂场景: LangChain
self.complex_llm = ChatOpenAI(...)
self.complex_chain = self._build_chain()
async def simple_task(self, prompt):
"""简单任务: 直接调用"""
return await self.simple_llm.invoke(prompt)
async def complex_task(self, doc):
"""复杂任务: LangChain"""
return await self.complex_chain.ainvoke({"doc": doc})
def _build_chain(self):
"""构建 Chain"""
prompt = ChatPromptTemplate.from_template(...)
return prompt | self.complex_llm | parser
# 优势:
# - 灵活组合
# - 性能优化
# - 易于维护
---
c.说明
---
e.实施建议
a.决策流程
a.代码示例
---
决策流程:
开始
│
▼
任务是否复杂？
├─ 否 → 直接调用
│
└─ 是 → 需要多步推理？
│
├─ 否 → 直接调用
│
└─ 是 → 需要条件分支？
│
├─ 否 → LangChain
│
└─ 是 → 需要可视化？
│
├─ 否 → LangChain (RouterChain)
│
└─ 是 → LangGraph
---
b.迁移路径
a.代码示例
---
# 阶段 1: 直接调用
async def evaluate(doc):
response = await call_llm(f"分析标书: {doc}")
return response
# 阶段 2: 添加 LangChain (渐进式)
# 先保持直接调用不变
# 新功能使用 LangChain
# 旧代码保持不变
async def evaluate(doc):
return await call_llm(f"分析标书: {doc}")
# 新功能使用 LangChain
chain = prompt | llm | parser
async def new_feature(doc):
return await chain.ainvoke({"doc": doc})
# 阶段 3: 逐步迁移 (可选)
# 根据需要逐步迁移到 LangChain
---
c.最佳实践
a.说明
直接调用最佳实践:
b.代码示例
---
import httpx
from pydantic import BaseModel
class LLMService:
"""直接调用的最佳实践"""
def __init__(self, base_url, api_key):
self.base_url = base_url
self.api_key = api_key
self.client = httpx.AsyncClient(timeout=60.0)
async def chat(self, model, messages):
"""统一调用接口"""
response = await self.client.post(
f"{self.base_url}/chat/completions",
headers={"Authorization": f"Bearer {self.api_key}"},
json={
"model": model,
"messages": messages,
"temperature": 0
}
)
response.raise_for_status()
return response.json()
async def extract_structured(self, prompt, schema):
"""结构化提取"""
response = await self.chat(
"qwen2.5-32b",
[{
"role": "user",
"content": f"{prompt}\n\n请严格按照以下 JSON 格式返回:\n{schema}"
}]
)
# 解析 JSON
return json.loads(response["choices"][0]["message"]["content"])
async def __aenter__(self):
return self
async def __aexit__(self, exc_type, exc_val, exc_tb):
await self.client.aclose()
---
c.说明
LangChain 最佳实践:
d.代码示例
---
from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser
# 全局初始化
llm = ChatOpenAI(
base_url="http://newapi:3000/v1",
model="qwen2.5-32b",
temperature=0
)
# 预定义 Chains
class EvaluationChains:
"""评标 Chains 集合"""
@staticmethod
def extraction_chain():
"""信息提取 Chain"""
prompt = ChatPromptTemplate.from_template(
"从标书中提取:{field}\n\n内容:{content}"
)
return prompt | llm | StrOutputParser()
@staticmethod
def comparison_chain():
"""对比分析 Chain"""
prompt = ChatPromptTemplate.from_template(
"对比以下标书:\n{doc1}\n\n{doc2}\n\n给出差异"
)
return prompt | llm | StrOutputParser()
# 使用
extraction_chain = EvaluationChains.extraction_chain()
result = await extraction_chain.ainvoke({
"field": "公司名称",
"content": doc_content
})
---
e.说明
---
f.总结
a.核心结论
a.说明
框架选择建议:
b.表格数据
场景 推荐方案 代码量 学习成本
简单问答 直接调用 10 行 2 小时
信息提取 直接调用 / LangChain 15-20 行 2-16 小时
多步推理 LangChain 25 行 16 小时
复杂工作流 LangGraph 50+ 行 24 小时
c.说明
关键发现:
1.✅ 70% 的评标场景不需要 LangChain
2.✅ 直接调用简单、快速、可控
3.⚠️ 只在多步推理时推荐 LangChain
4.⚠️ 只在复杂工作流时推荐 LangGraph
5.✅ 混合策略最佳
b.决策建议
a.说明
评标工具推荐路径:
b.代码示例
---
MVP 阶段:
└── 直接调用模型
├── 简单
├── 快速
└── 可控
试运行阶段:
├── 主要功能: 直接调用
├── 复杂分析: LangChain (可选)
└── 渐进式增强
生产阶段:
├── 保持简单功能直接调用
├── 复杂功能使用 LangChain
└── 根据实际需求决定
原则: 能简单就不复杂
---
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 25.并发性能边界探索.md
05.并发性能边界
a.需求分析
a.评标场景的并发需求
a.说明
核心需求: 10 个并发会话
b.代码示例
---
并发场景分析:
会话定义:
├── 一个用户提交一份标书
├── 需要 3-5 分钟处理
├── 包括文档解析、分析、生成报告
└── 期间需要多次调用模型
并发需求:
├── 峰值: 10 个会话同时进行
├── 平均: 5 个会话
├── 谷值: 1-3 个会话
└── 持续时间: 每个 3-5 分钟
并发类型:
├── CPU 密集型: 文档解析、OCR
├── I/O 密集型: 等待模型响应
└── 内存密集型: 模型加载、缓存
---
c.说明
并发压力分析:
d.代码示例
---
单个会话的资源占用:
├── CPU: 20% (解析时)
├── 内存: 2GB
├── 网络: 10 Mbps
└── 模型调用: 10-20 次
10 并发的总需求:
├── CPU: 200% (需要 2-4 核)
├── 内存: 20GB
├── 网络: 100 Mbps
└── 模型 QPS: 5-10 请求/秒
---
b.性能指标
a.说明
关键性能指标 (KPI):
b.表格数据
指标 目标 可接受 不可接受
响应时间 < 30 秒 < 60 秒 > 90 秒
并发支持 10 会话 5 会话 < 5 会话
成功率 > 99% > 95% < 95%
资源利用率 60-80% < 90% > 95%
c.说明
---
b.并发处理方案
a.方案分类
a.代码示例
---
并发处理方案:
方案 1: 同步处理
├── 简单直接
├── 阻塞等待
├── 资源浪费
└── 适合: < 5 并发
方案 2: 多线程/多进程
├── Python threading
├── Python multiprocessing
├── 资源占用高
└── 适合: CPU 密集型
方案 3: 异步处理 (asyncio)
├── 高效 I/O
├── 资源占用低
├── 实现复杂
└── 适合: I/O 密集型
方案 4: 任务队列 (Celery)
├── 可扩展
├── 可靠性高
├── 架构复杂
└── 适合: 高并发
---
b.方案对比
a.说明
性能对比:
b.表格数据
方案 并发能力 响应时间 资源占用 实现难度
同步 1-2 慢 低 ⭐
多线程 5-10 中 高 ⭐⭐
多进程 10-20 中 很高 ⭐⭐⭐
asyncio 50-100 快 低 ⭐⭐⭐
Celery 100+ 中 中 ⭐⭐⭐⭐
c.说明
适用场景:
d.代码示例
---
同步处理:
├── 代码简单
├── 调试容易
├── 适合: MVP 验证
└── 不适合: 生产环境
多线程:
├── Python GIL 限制
├── 适合 I/O 密集
├── 不适合: CPU 密集
└── 适合: 轻量并发
多进程:
├── 绕过 GIL
├── 资源占用高
├── 适合: CPU 密集
└── 适合: 中等并发
asyncio:
├── 协程高效
├── I/O 密集最优
├── 学习曲线陡
└── 适合: 10-50 并发
Celery:
├── 分布式任务
├── 可靠性高
├── 架构复杂
└── 适合: 高并发
---
e.说明
---
c.边界探索
a.并发能力边界
a.说明
方案 1: 同步处理
b.代码示例
---
# 同步处理
def process_document(doc_id):
# 解析文档 (阻塞)
content = parse_document(doc_id)
# 调用模型 (阻塞)
result = call_llm(content)
return result
# 并发测试
import concurrent.futures
def process_batch(doc_ids):
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
futures = [executor.submit(process_document, doc_id) for doc_id in doc_ids]
results = [f.result() for f in concurrent.futures.as_completed(futures)]
return results
# 性能测试结果:
# - 2 并发: ✅ 可用 (20 秒)
# - 5 并发: ⚠️ 勉强 (50 秒)
# - 10 并发: ❌ 不可用 (超时/内存不足)
# 结论: 同步处理不适合 10 并发
---
c.说明
方案 2: 异步处理 (asyncio)
d.代码示例
---
# 异步处理
import asyncio
import httpx
async def process_document(doc_id):
# 解析文档 (异步)
content = await parse_document_async(doc_id)
# 调用模型 (异步)
result = await call_llm_async(content)
return result
async def process_batch(doc_ids):
tasks = [process_document(doc_id) for doc_id in doc_ids]
results = await asyncio.gather(*tasks)
return results
# 性能测试结果:
# - 10 并发: ✅ 可用 (30 秒)
# - 20 并发: ✅ 可用 (40 秒)
# - 50 并发: ✅ 可用 (60 秒)
# - 100 并发: ⚠️ 受 API 限流影响
# 结论: asyncio 最适合 10 并发
---
e.说明
方案 3: Celery 任务队列
f.代码示例
---
# Celery 处理
from celery import Celery
app = Celery('evaluation', broker='redis://localhost:6379/0')
@app.task
def process_document(doc_id):
content = parse_document(doc_id)
result = call_llm(content)
return result
# 提交任务
def process_batch(doc_ids):
results = [process_document.delay(doc_id) for doc_id in doc_ids]
return results
# 性能测试结果:
# - 10 并发: ✅ 可用 (35 秒)
# - 50 并发: ✅ 可用 (60 秒)
# - 100 并发: ✅ 可用 (可扩展)
# - 1000 并发: ✅ 可用 (加 Worker)
# 结论: Celery 适合高并发，但架构复杂
---
b.资源占用边界
a.说明
内存占用对比:
b.代码示例
---
内存占用 (10 并发):
同步处理:
├── 主进程: 500MB
├── 10 线程: 500MB × 10 = 5GB
├── 模型加载: 2GB
└── 总计: ~8GB
asyncio:
├── 主进程: 500MB
├── 协程: 100MB × 10 = 1GB
├── 模型加载: 2GB
└── 总计: ~4GB
Celery:
├── 主进程: 200MB
├── Worker: 500MB × 4 = 2GB
├── Redis: 500MB
├── 模型加载: 2GB
└── 总计: ~5GB
---
c.说明
CPU 利用率:
d.代码示例
---
CPU 利用率 (10 并发):
同步处理:
├── 等待时间: 90%
├── 工作时间: 10%
├── CPU 利用率: 10-20%
└── 浪费: 严重
asyncio:
├── 等待时间: 0%
├── 工作时间: 80%
├── CPU 利用率: 60-80%
└── 效率: 高
Celery:
├── 等待时间: 0%
├── 工作时间: 70%
├── CPU 利用率: 50-70%
└── 效率: 高
---
c.模型 API 限流边界
a.说明
常见限流策略:
b.代码示例
---
硅基流动限流:
├── QPS: 10 请求/秒
├── 并发: 10 请求
├── TPM: 100000 tokens/分钟
└── 策略: 令牌桶
通义千问限流:
├── QPS: 20 请求/秒
├── 并发: 20 请求
├── TPM: 50000 tokens/分钟
└── 策略: 漏桶
Ollama 本地:
├── QPS: 5-10 请求/秒 (取决于模型)
├── 并发: 受限于硬件
└── 策略: 无限制
---
c.说明
限流应对策略:
d.代码示例
---
# 策略 1: 请求队列
import asyncio
from asyncio import Semaphore
class RateLimitedClient:
def __init__(self, max_concurrent=10):
self.semaphore = Semaphore(max_concurrent)
self.client = httpx.AsyncClient()
async def call_llm(self, prompt):
async with self.semaphore:
response = await self.client.post(...)
return response.json()
# 策略 2: 指数退避
import asyncio
import random
async def call_llm_with_retry(prompt, max_retries=3):
for attempt in range(max_retries):
try:
return await call_llm(prompt)
except RateLimitError:
wait_time = (2 ** attempt) + random.random()
await asyncio.sleep(wait_time)
# 策略 3: 缓存
from functools import lru_cache
@lru_cache(maxsize=100)
async def cached_llm(prompt_hash, prompt):
return await call_llm(prompt)
---
d.成本边界
a.说明
并发对成本的影响:
b.代码示例
---
成本分析:
场景 1: 串行处理
├── 时间: 300 秒/份
├── API 调用: 10 次
├── 10 份标书: 50 分钟
└── 成本: 固定
场景 2: 10 并发 (asyncio)
├── 时间: 30 秒/份
├── API 调用: 10 次
├── 10 份标书: 5 分钟
├── 加速比: 10x
└── 成本: 不变
场景 3: 100 并发 (Celery)
├── 时间: 30 秒/份
├── Worker: 10 个
├── 服务器: 3 台
├── 100 份标书: 5 分钟
├── 加速比: 100x
└── 成本: +¥300/月 (服务器)
结论: 并发不增加 API 成本，但增加服务器成本
---
c.说明
---
d.推荐方案
a.分并发量推荐
a.说明
低并发 (1-5 会话):
b.代码示例
---
# 推荐: asyncio
import asyncio
import httpx
async def process_documents(doc_ids):
async with httpx.AsyncClient() as client:
tasks = [process_single(doc_id, client) for doc_id in doc_ids]
results = await asyncio.gather(*tasks)
return results
async def process_single(doc_id, client):
# 处理逻辑
response = await client.post(...)
return response.json()
# 优势:
# - 简单高效
# - 资源占用低
# - 无需额外组件
# 成本: ¥0 (无额外服务器)
---
c.说明
中并发 (10-20 会话):
d.代码示例
---
# 推荐: asyncio + 限流控制
import asyncio
from asyncio import Semaphore
class ConcurrencyController:
def __init__(self, max_concurrent=10):
self.semaphore = Semaphore(max_concurrent)
async def process_documents(self, doc_ids):
tasks = [self.process_with_limit(doc_id) for doc_id in doc_ids]
results = await asyncio.gather(*tasks)
return results
async def process_with_limit(self, doc_id):
async with self.semaphore:
# 处理逻辑
return await process_single(doc_id)
# 优势:
# - 控制并发数
# - 避免 API 限流
# - 资源可控
# 成本: ¥100/月 (稍好服务器)
---
e.说明
高并发 (50+ 会话):
f.代码示例
---
# 推荐: Celery + Redis
from celery import Celery
app = Celery('evaluation', broker='redis://localhost:6379/0')
app.conf.update(
worker_concurrency=10, # 每个 Worker 10 并发
worker_prefetch_multiplier=4,
)
@app.task(bind=True)
def process_document(self, doc_id):
# 处理逻辑
result = process_single(doc_id)
return result
# 启动 Worker
# celery -A app worker --loglevel=info --concurrency=10
# 优势:
# - 可扩展
# - 高可靠性
# - 分布式
# 成本: ¥500/月 (多台服务器 + Redis)
---
b.分阶段推荐
a.说明
阶段 1: MVP (1-2 周)
b.代码示例
---
# 推荐: 同步处理
def process_document(doc_id):
content = parse_document(doc_id)
result = call_llm(content)
return result
# 特点:
# - 最简单
# - 够用即可
# - 不考虑并发
---
c.说明
阶段 2: 试运行 (3-8 周)
d.代码示例
---
# 推荐: asyncio
import asyncio
async def process_documents(doc_ids):
tasks = [process_single(doc_id) for doc_id in doc_ids]
return await asyncio.gather(*tasks)
# 特点:
# - 支持 10 并发
# - 资源占用低
# - 成本不增加
---
e.说明
阶段 3: 生产优化 (9 周+)
f.代码示例
---
选项 A: 继续 asyncio (≤10 并发)
├── 成本: 不增加
├── 复杂度: 不增加
└── 适合: 小规模
选项 B: 升级到 Celery (≥20 并发)
├── 成本: +¥300/月
├── 复杂度: 中等
└── 适合: 中大规模
---
c.异步实现最佳实践
a.说明
FastAPI 异步处理:
b.代码示例
---
from fastapi import FastAPI, BackgroundTasks
import asyncio
app = FastAPI()
# 方案 1: 异步端点
@app.post("/evaluate")
async def evaluate_document(doc_id: int):
"""异步处理，立即返回"""
# 提交后台任务
task = asyncio.create_task(process_document_async(doc_id))
# 立即返回任务 ID
return {"task_id": id(task), "status": "processing"}
# 方案 2: WebSocket 实时推送
from fastapi import WebSocket
@app.websocket("/ws/evaluate/{doc_id}")
async def evaluate_websocket(websocket: WebSocket, doc_id: int):
await websocket.accept()
# 发送进度
await websocket.send_json({"status": "parsing", "progress": 10})
# 处理文档
result = await process_document(doc_id, lambda p: websocket.send_json(p))
await websocket.send_json({"status": "completed", "result": result})
# 方案 3: 后台任务 + 轮询
tasks = {}
@app.post("/evaluate")
async def evaluate_document(doc_id: int, background_tasks: BackgroundTasks):
task_id = f"task_{doc_id}"
tasks[task_id] = {"status": "processing"}
background_tasks.add_task(process_document_task, doc_id, task_id)
return {"task_id": task_id}
@app.get("/status/{task_id}")
async def get_status(task_id: str):
return tasks.get(task_id, {"status": "not_found"})
---
c.说明
---
e.性能优化
a.并发优化技巧
a.说明
技巧 1: 连接池
b.代码示例
---
import httpx
# 使用连接池
client = httpx.AsyncClient(
limits=httpx.Limits(max_connections=100, max_keepalive_connections=20),
timeout=60.0
)
# 复用连接
async def call_llm_batch(prompts):
tasks = [client.post(...) for prompt in prompts]
return await asyncio.gather(*tasks)
---
c.说明
技巧 2: 批处理
d.代码示例
---
# 批量调用
async def batch_call_llm(prompt_list, batch_size=10):
results = []
for i in range(0, len(prompt_list), batch_size):
batch = prompt_list[i:i+batch_size]
batch_results = await asyncio.gather(*[
call_llm(prompt) for prompt in batch
])
results.extend(batch_results)
return results
---
e.说明
技巧 3: 缓存
f.代码示例
---
from functools import lru_cache
# 结果缓存
@lru_cache(maxsize=1000)
def get_prompt_template(template_name):
return load_template(template_name)
# 向量缓存
import numpy as np
embedding_cache = {}
async def get_embedding(text):
if text not in embedding_cache:
embedding_cache[text] = await call_embedding_api(text)
return embedding_cache[text]
---
b.性能监控
a.代码示例
---
# 性能监控装饰器
import time
from functools import wraps
def monitor_performance(func):
@wraps(func)
async def wrapper(*args, **kwargs):
start = time.time()
try:
result = await func(*args, **kwargs)
return result
finally:
duration = time.time() - start
# 记录到监控系统
log_performance(func.__name__, duration)
return wrapper
@monitor_performance
async def process_document(doc_id):
# 处理逻辑
pass
---
b.说明
---
f.总结
a.核心结论
a.说明
并发方案建议:
b.表格数据
并发量 推荐方案 服务器成本 复杂度
1-5 asyncio ¥0 ⭐⭐
10-20 asyncio + 限流 ¥100 ⭐⭐⭐
50+ Celery ¥500 ⭐⭐⭐⭐
c.说明
关键发现:
1.✅ asyncio 最适合 10 并发
2.✅ 10 并发不需要 Celery
3.⚠️ 超过 20 并发考虑 Celery
4.✅ 异步处理不增加 API 成本
5.⚠️ 并发增加服务器成本
b.决策建议
a.说明
评标工具推荐路径:
b.代码示例
---
MVP 阶段:
└── 同步处理 (够用即可)
试运行阶段:
└── asyncio + 限流控制
├── 支持 10 并发
├── 资源占用低
└── 成本不增加
生产阶段:
├── 选项 A: asyncio (≤10 并发)
│ └── 持续优化即可
│
└── 选项 B: Celery (≥20 并发)
└── 架构升级
性能目标:
├── 响应时间: < 30 秒
├── 并发支持: 10 会话
└── 成功功率: > 99%
---
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 26.合规性边界探索.md
06.合规性边界
a.需求分析
a.中国法律要求
a.说明
核心法律要求回顾:
b.代码示例
---
相关法律法规:
├── 《中华人民共和国网络安全法》 (2017)
│ ├── 网络运营者责任
│ ├── 数据安全保护
│ └── 个人信息保护
│
├── 《中华人民共和国数据安全法》 (2021)
│ ├── 数据分类分级
│ ├── 数据风险评估
│ └── 数据跨境传输
│
├── 《中华人民共和国个人信息保护法》 (2021)
│ ├── 个人信息处理规则
│ ├── 同意原则
│ └── 权益保护
│
└── 《网络安全等级保护条例》
├── 等保二级 (推荐)
├── 等保三级 (高要求)
└── 认证要求
---
b.评标场景的合规风险
a.说明
风险评估:
b.代码示例
---
合规风险分析:
风险 1: 数据出境
├── 场景: 使用国外 API (OpenAI, Claude)
├── 风险等级: ⭐⭐⭐⭐
├── 法律条款: 《数据安全法》
└── 合规要求: 数据本地化
风险 2: 个人信息泄露
├── 场景: 标书含个人信息
├── 风险等级: ⭐⭐⭐
├── 法律条款: 《个人信息保护法》
└── 合规要求: 脱敏处理
风险 3: 商业秘密泄露
├── 场景: 标书含商业秘密
├── 风险等级: ⭐⭐⭐⭐⭐
├── 法律条款: 《反不正当竞争法》
└── 合规要求: 访问控制、审计
风险 4: 网络安全
├── 场景: 系统被攻击
├── 风险等级: ⭐⭐⭐
├── 法律条款: 《网络安全法》
└── 合规要求: 等保认证
---
c.说明
---
b.合规边界分析
a.数据本地化边界
a.说明
数据不出境要求:
b.代码示例
---
《数据安全法》要求:
关键数据基础设施:
├── 国家安全
├── 经济运行
├── 社会稳定
└── 公共利益
数据本地化要求:
├── 核心: 必须境内存储
├── 重要: 建议境内存储
└── 一般: 可出境 (需评估)
评标场景判定:
├── 标书数据: 可能包含商业秘密
├── 评标结果: 涉及公平竞争
└── 建议: 数据不出境
---
c.说明
模型选择边界:
d.表格数据
模型/服务 服务器位置 数据出境风险 推荐度
OpenAI 美国 ⚠️ 高 ❌ 不推荐
Claude 美国 ⚠️ 高 ❌ 不推荐
硅基流动 中国 ✅ 低 ✅ 推荐
通义千问 中国 ✅ 低 ✅ 推荐
Ollama 本地 本地 ✅ 无 ✅ 推荐
昇腾 NPU 本地 ✅ 无 ✅ 推荐
b.等保合规边界
a.说明
等级保护要求:
b.代码示例
---
等保二级要求 (推荐):
├── 物理环境
│ ├── 机房安全
│ ├── 设备安全
│ └── 防火防盗
│
├── 通信网络安全
│ ├── 网络架构
│ ├── 访问控制
│ └── 通信传输
│
├── 区域边界
│ ├── 边界防护
│ ├── 访问控制
│ └── 入侵防范
│
├── 计算环境
│ ├── 身份鉴别
│ ├── 访问控制
│ └── 审计日志
│
├── 管理制度
│ ├── 管理机构
│ ├── 人员管理
│ └── 系统运维
│
└── 成本估算: ¥10-30 万 (首次) + ¥5-10 万/年
等保三级要求 (可选):
├── 更严格的技术要求
├── 更严格的管理要求
└── 成本估算: ¥30-50 万 (首次) + ¥10-20 万/年
---
c.说明
合规实现成本:
d.表格数据
合规项 自建 云端 混合
物理安全 高 低 中
网络安全 高 中 中
数据安全 完全可控 需合同 部分可控
成本 高 低 中
推荐度 ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐
c.个人信息保护边界
a.说明
个人信息识别:
b.代码示例
---
标书中可能的个人信息:
├── 联系人姓名
├── 联系电话
├── 邮箱地址
├── 身份证号
└── 银行账号
《个人信息保护法》要求:
├── 最小必要原则
├── 知情同意原则
├── 目的限制原则
├── 公开透明原则
└── 安全保障原则
---
c.说明
脱敏处理:
d.代码示例
---
import re
def mask_sensitive_data(text):
"""脱敏处理"""
# 手机号
text = re.sub(r'(\d{3})\d{4}(\d{4})', r'\1****\2', text)
# 身份证
text = re.sub(r'(\d{6})\d{8}(\d{4})', r'\1********\2', text)
# 邮箱
text = re.sub(r'(\w{2})[\w-]+@([\w.]+)', r'\1***@\2', text)
# 银行卡
text = re.sub(r'(\d{4})\d{8}(\d{4})', r'\1********\2', text)
return text
# 使用示例
sensitive_text = "联系人: 张三, 电话: 13812345678, 邮箱: [email protected]"
masked = mask_sensitive_data(sensitive_text)
# 结果: 联系人: 张三, 电话: 138****5678, 邮箱: zh***@example.com
---
d.数据安全边界
a.说明
数据分类分级:
b.代码示例
---
数据分类:
公开数据:
├── 评标规则 (已公开)
├── 程序代码
└── 技术文档
├── 处理方式: 无特殊要求
└── 可出境: ✅
内部数据:
├── 操作日志
├── 系统配置
├── 用户权限
├── 处理方式: 访问控制
└── 可出境: ❌
敏感数据:
├── 标书内容
├── 评标结果
├── 价格信息
├── 处理方式: 加密存储、审计
└── 可出境: ❌ 严格禁止
核心数据:
├── 商业秘密
├── 个人信息
├── 加密密钥
├── 处理方式: 严格保护
└── 可出境: ❌ 绝对禁止
---
c.说明
---
c.合规方案对比
a.部署方案合规性
a.说明
方案 1: 完全云端 (国外 API)
b.代码示例
---
方案: 使用 OpenAI/Claude 等国外 API
合规风险:
├── 数据出境: ⭐⭐⭐⭐⭐ (高风险)
├── 数据安全: ⭐⭐ (低保障)
├── 审计合规: ⭐⭐ (困难)
└── 等保合规: ❌ 无法通过
法律风险:
├── 《数据安全法》: 可能违规
├── 《个人信息保护法》: 可能违规
└── 建议: ❌ 不推荐
---
c.说明
方案 2: 云端 (国内 API)
d.代码示例
---
方案: 使用硅基流动、通义千问等国内 API
合规风险:
├── 数据出境: ⭐ (低风险)
├── 数据安全: ⭐⭐⭐ (厂商保障)
├── 审计合规: ⭐⭐⭐⭐ (合同保障)
└── 等保合规: ⚠️ 需评估
法律风险:
├── 《数据安全法》: 基本合规
├── 《个人信息保护法》: 需注意
└── 建议: ⭐⭐⭐⭐ 推荐 (合同明确)
注意事项:
├── 签署数据处理协议
├── 明确数据存储位置
├── 要求提供审计报告
└── 保留法律追索权
---
e.说明
方案 3: 完全本地部署
f.代码示例
---
方案: Ollama 本地或昇腾 NPU
合规风险:
├── 数据出境: ⭐⭐⭐⭐⭐ (完全无风险)
├── 数据安全: ⭐⭐⭐⭐⭐ (完全可控)
├── 审计合规: ⭐⭐⭐⭐⭐ (完全可控)
└── 等保合规: ✅ 容易通过
法律风险:
├── 《数据安全法》: ✅ 完全合规
├── 《个人信息保护法》: ✅ 完全合规
└── 建议: ⭐⭐⭐⭐⭐ 强烈推荐
注意:
└── 硬件投入高，回本周期长
---
g.说明
方案 4: 混合方案
h.代码示例
---
方案: 本地为主，云端为辅
策略:
├── 敏感数据: 本地处理
├── 非敏感数据: 云端处理
├── 高峰期: 云端扩容
└── 降本: 成本优化
合规风险:
├── 数据出境: ⭐⭐ (可控)
├── 数据安全: ⭐⭐⭐⭐ (大部分可控)
├── 审计合规: ⭐⭐⭐⭐ (可控)
└── 等保合规: ⭐⭐⭐⭐ (较好)
法律风险:
├── 《数据安全法》: ✅ 基本合规
├── 《个人信息保护法》: ✅ 合规
└── 建议: ⭐⭐⭐⭐⭐ 最推荐
---
b.等保实施边界
a.说明
等保二级实施要点:
b.代码示例
---
技术要求:
├── 网络隔离
│ ├── VLAN 划分
│ ├── 防火墙
│ └── 访问控制
│
├── 身份认证
│ ├── 强密码
│ ├── 双因素认证 (可选)
│ └── 定期更换
│
├── 访问控制
│ ├── 最小权限原则
│ ├── 角色分离
│ └── 定期审计
│
├── 数据安全
│ ├── 加密存储
│ ├── 传输加密
│ └── 备份恢复
│
└── 安全审计
├── 操作日志
├── 访问日志
└── 异常告警
管理制度:
├── 安全管理制度
├── 安全管理机构
├── 人员安全管理
├── 系统建设管理
└── 系统运维管理
---
c.说明
等保成本分析:
d.表格数据
项目 自建 云端 说明
网络设备 ¥5-10 万 ¥1-3 万 防火墙、VPN
安全软件 ¥3-5 万 ¥1-2 万 杀毒、审计
等保测评 ¥2-5 万 ¥2-5 万 第三方测评
咨询整改 ¥5-10 万 ¥2-5 万 整改咨询
年维护 ¥3-5 万 ¥2-3 万 维护运营
总计 (首次) ¥18-35 万 ¥8-20 万 -
总计 (年度) ¥23-40 万 ¥13-28 万 -
e.说明
---
d.推荐方案
a.合规分级推荐
a.说明
级别 1: 基础合规 (最低要求)
b.代码示例
---
方案: 国内云端 API + 基础安全
技术栈:
├── 模型: 硅基流动、通义千问
├── 部署: 阿里云/腾讯云
├── 安全: 云厂商安全组
└── 成本: ¥1000-2000/月
合规措施:
├── 数据处理协议
├── 访问控制
├── 审计日志
└── 定期备份
适合: 内部使用、数据不敏感
---
c.说明
级别 2: 等保二级 (推荐)
d.代码示例
---
方案: 混合部署 + 等保二级
技术栈:
├── 模型: 本地 Ollama + 硅基流动备份
├── 部署: 私有云/专有云
├── 安全: 完整安全体系
└── 成本: ¥5000-10000/月
合规措施:
├── 网络隔离 (VLAN)
├── 强身份认证
├── 完整审计日志
├── 数据加密
├── 等保二级认证
└── 安全团队
适合: 大多数企业
---
e.说明
级别 3: 等保三级 (高要求)
f.代码示例
---
方案: 完全私有化 + 等保三级
技术栈:
├── 模型: 昇腾 NPU 部署
├── 部署: 本地机房
├── 安全: 军工级安全
└── 成本: ¥10000-20000/月
合规措施:
├── 物理隔离
├── 多因素认证
├── 全方位审计
├── 数据加密存储
├── 等保三级认证
└── 专业安全团队
适合: 国企、金融、政府
---
b.分场景推荐
a.说明
场景 1: 内部试用 (数据不敏感)
b.代码示例
---
推荐: 云端 API (国内)
方案:
├── 模型: 硅基流动
├── 部署: 云端
└── 合同: 数据处理协议
合规要点:
├── 签署数据处理协议
├── 明确数据存储位置
├── 定期安全审计
└── 风险: ⭐⭐ 可控
---
c.说明
场景 2: 商业使用 (数据敏感)
d.代码示例
---
推荐: 混合方案
方案:
├── 标书解析: 本地 PaddleOCR
├── 文本分析: 本地 Ollama
├── 高峰期: 硅基流动备份
└── 部署: 私有云
合规要点:
├── 敏感数据本地化
├── 访问控制严格
├── 完整审计日志
└── 风险: ⭐ 可控
---
e.说明
场景 3: 政府采购 (高合规要求)
f.代码示例
---
推荐: 完全本地化
方案:
├── 模型: 昇腾 NPU
├── 部署: 本地机房
├── 安全: 等保三级
└── 供应商: 国产化
合规要点:
├── 数据完全不出境
├── 通过等保三级
├── 国产化率 > 80%
├── 供应链安全
└── 风险: ⭐ 最小
---
c.合规成本边界
a.说明
合规成本 vs 风险:
b.代码示例
---
风险-成本曲线:
风险
↑
│ ╱
│ ╱
│ ╱ ← 合规投入增加，风险降低
│ ╱
│ ╱
└──────────────→ 成本
不合规 (成本: ¥0)
├── 法律风险: ⭐⭐⭐⭐⭐
├── 罚款风险: ¥10-100 万
├── 声誉风险: 无价
└── 建议: ❌ 不可接受
基础合规 (成本: ¥1-2 万/年)
├── 法律风险: ⭐⭐⭐
├── 罚款风险: ¥1-10 万
├── 声誉风险: 可控
└── 建议: ⭐⭐⭐ 小型企业
等保二级 (成本: ¥10-20 万/年)
├── 法律风险: ⭐
├── 罚款风险: < ¥1 万
├── 声誉风险: 低
└── 建议: ⭐⭐⭐⭐⭐ 推荐
等保三级 (成本: ¥30-50 万/年)
├── 法律风险: 无
├── 罚款风险: 无
├── 声誉风险: 无
└── 建议: ⭐⭐⭐⭐⭐ 高要求
---
c.说明
---
e.实施建议
a.合规检查清单
a.说明
部署前检查:
b.代码示例
---
# 合规检查清单
COMPLIANCE_CHECKLIST = {
"数据安全": [
"✅ 数据存储在中国境内",
"✅ 敏感数据加密存储",
"✅ 传输使用 HTTPS/TLS",
"✅ 定期备份数据",
"✅ 有数据删除机制"
],
"访问控制": [
"✅ 实施身份认证",
"✅ 最小权限原则",
"✅ 定期审查权限",
"✅ 异常登录检测",
"✅ 操作日志记录"
],
"法律合规": [
"✅ 签署数据处理协议",
"✅ 隐私政策明示",
"✅ 用户同意机制",
"✅ 数据留存期限",
"✅ 法律联系方式"
],
"网络安全": [
"✅ 网络隔离",
"✅ 防火墙配置",
"✅ 入侵检测",
"✅ 漏洞扫描",
"✅ 安全培训"
]
}
---
b.数据处理协议
a.说明
关键条款:
b.代码示例
---
数据处理协议 (与云服务商/模型提供商):
1. 数据存储位置
└── 数据必须存储在中国境内
2. 数据使用权
└── 仅用于提供服务的必要范围
3. 数据保护义务
└── 采取合理的安全措施保护数据
4. 数据删除权
└── 用户有权要求删除数据
5. 审计权
└── 用户有权审计数据处理情况
6. 违约责任
└── 明确违约的赔偿责任
7. 法律适用
└── 适用中华人民共和国法律
8. 争议解决
└── 在中国境内仲裁或诉讼
---
c.安全加固
a.说明
代码安全示例:
b.代码示例
---
# 安全的 API 调用
import httpx
from typing import Dict, Any
import hashlib
import json
class SecureAPIClient:
"""安全的 API 客户端"""
def __init__(self, base_url: str, api_key: str):
self.base_url = base_url
self.api_key = api_key
# 不记录敏感日志
async def call_llm(
self,
messages: list,
model: str = "qwen2.5-32b"
) -> Dict[str, Any]:
"""安全的 LLM 调用"""
# 脱敏处理
sanitized_messages = self._sanitize(messages)
# 记录不包含敏感内容的日志
prompt_hash = hashlib.sha256(
json.dumps(sanitized_messages).encode()
).hexdigest()[:8]
print(f"调用 LLM: {prompt_hash}...")
# HTTPS 调用
async with httpx.AsyncClient() as client:
response = await client.post(
f"{self.base_url}/chat/completions",
headers={
"Authorization": f"Bearer {self.api_key}",
"Content-Type": "application/json"
},
json={
"model": model,
"messages": sanitized_messages,
"temperature": 0
},
timeout=60.0
)
response.raise_for_status()
return response.json()
def _sanitize(self, messages: list) -> list:
"""脱敏处理"""
sanitized = []
for msg in messages:
content = msg.get("content", "")
# 移除敏感信息
content = self._remove_sensitive_info(content)
sanitized.append({
"role": msg["role"],
"content": content
})
return sanitized
def _remove_sensitive_info(self, text: str) -> str:
"""移除敏感信息"""
import re
# 移除可能的身份证号
text = re.sub(r'\d{15,19}[Xx\d]', '[ID]', text)
# 移除可能的手机号
text = re.sub(r'1[3-9]\d{9}', '[PHONE]', text)
# 移除可能的银行卡号
text = re.sub(r'\d{16,19}', '[CARD]', text)
return text
---
c.说明
---
f.总结
a.核心结论
a.说明
合规方案建议:
b.表格数据
合规级别 推荐方案 数据位置 年成本 风险等级
基础合规 国内云端 API 国内厂商 ¥1-2 万 ⭐⭐⭐
等保二级 混合方案 主要是本地 ¥10-20 万 ⭐
等保三级 完全本地化 完全本地 ¥30-50 万 无
c.说明
关键发现:
1.✅ 使用国内 API (硅基流动、通义千问) 基本合规
2.✅ 敏感数据必须本地化
3.✅ 等保二级是大多数企业的合理选择
4.⚠️ 等保三级成本高，适合高要求场景
5.✅ 数据处理协议很重要
b.决策建议
a.说明
评标工具合规路径:
b.代码示例
---
MVP 阶段 (内部验证):
├── 使用硅基流动 (国内)
├── 签署数据处理协议
├── 数据脱敏处理
└── 合规基础: ⭐⭐⭐
试运行阶段 (小范围):
├── 继续使用硅基流动
├── 添加安全审计
├── 完善访问控制
└── 合规基础: ⭐⭐⭐⭐
生产阶段 (正式使用):
├── 选项 A: 继续云端 (等保二级)
│ ├── 数据处理协议完善
│ ├── 通过等保二级认证
│ └── 成本: ¥10-20 万/年
│
├── 选项 B: 本地部署 (等保三级)
│ ├── Ollama 或昇腾 NPU
│ ├── 通过等保三级认证
│ └── 成本: ¥30-50 万/年
│
└── 建议: 根据合规要求选择
原则: 合规优先，成本可控
---
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
下一篇: 27.综合决策建议.md
07.综合决策建议
a.决策总览
a.快速决策指南
a.说明
如果你时间紧张，直接看这里:
b.代码示例
---
评标工具技术选型快速决策:
文档处理:
└── PaddleOCR (免费) + PyMuPDF (PDF)
多模态模型:
├── 简单场景: Qwen2-VL-7B (硅基流动)
├── 复杂场景: Qwen2.5-VL-32B (硅基流动)
└── 图表理解: Claude 3.5 Sonnet
文本模型:
├── 主要: Qwen2.5-32B (硅基流动)
└── 备用: Qwen2.5-7B (硅基流动)
模型网关:
├── 单渠道: 不需要
├── 多渠道: NewAPI
└── 开发期: LiteLLM
LLM 框架:
├── 简单场景: 直接调用 (推荐)
├── 复杂场景: LangChain (可选)
└── 复杂工作流: LangGraph (很少用)
并发处理:
├── 10 并发: asyncio
├── 20+ 并发: Celery
└── 同步: 不推荐
合规方案:
├── 基础: 国内云端 API (硅基流动)
├── 标准: 等保二级 (混合方案)
└── 高标: 等保三级 (完全本地)
---
b.分阶段推荐
a.说明
三个阶段的完整方案:
b.代码示例
---
阶段 1: MVP 验证 (1-2 周)
├── 目标: 验证核心功能可行
├── 预算: ¥500-1000
└── 详细方案: 见下文
阶段 2: 试运行 (3-8 周)
├── 目标: 优化功能和性能
├── 预算: ¥1500-3000/月
└── 详细方案: 见下文
阶段 3: 生产部署 (9 周+)
├── 目标: 正式投入使用
├── 预算: 根据规模确定
└── 详细方案: 见下文
---
c.说明
---
b.MVP 阶段方案 (1-2 周)
a.方案概述
a.说明
核心目标: 快速验证评标功能可行性
b.代码示例
---
MVP 方案:
├── 文档处理: PaddleOCR + PyMuPDF
├── 模型调用: 直接调用硅基流动
├── 框架: Python + FastAPI (无 LangChain)
├── 网关: 不需要
├── 并发: 同步处理
└── 合规: 基础合同
---
b.技术栈
a.表格数据
组件 选择 理由
后端 Python + FastAPI 快速开发
前端 Vue 3 + Element Plus 快速原型
数据库 SQLite (可省略) 最简方案
OCR PaddleOCR 免费中文友好
PDF PyMuPDF 快速高效
模型 硅基流动 Qwen2.5-7B 低成本
调用方式 直接调用 最简单
部署 本地或云端 灵活
c.实现代码
a.代码示例
---
# MVP 完整示例
import httpx
import fitz # PyMuPDF
from paddleocr import PaddleOCR
class MVPEvaluationService:
"""MVP 评标服务"""
def __init__(self):
self.base_url = "https://api.siliconflow.cn/v1"
self.api_key = "sk-your-key"
self.ocr = PaddleOCR(use_angle_cls=True, lang='ch')
def parse_document(self, file_path):
"""解析文档"""
# PDF 处理
if file_path.endswith('.pdf'):
doc = fitz.open(file_path)
return '\n'.join([page.get_text() for page in doc])
# 图片 OCR
else:
result = self.ocr.ocr(file_path)
return '\n'.join([line[1][0] for line in result[0]])
async def analyze_document(self, content):
"""分析文档"""
async with httpx.AsyncClient() as client:
response = await client.post(
f"{self.base_url}/chat/completions",
headers={"Authorization": f"Bearer {self.api_key}"},
json={
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{
"role": "user",
"content": f"分析以下标书内容，提取关键信息:\n{content}"
}],
"temperature": 0
},
timeout=120.0
)
return response.json()["choices"][0]["message"]["content"]
# 使用
service = MVPEvaluationService()
content = service.parse_document("标书.pdf")
result = await service.analyze_document(content)
print(result)
---
d.成本估算
a.表格数据
项目 成本 说明
服务器 ¥100-200 云端 2核4GB
API 调用 ¥50-100 测试用量
开发时间 80-120 人时 约 2 周
总计 ¥500-1000 不含人力
e.验收标准
a.说明
---
b.[ ] 能解析 PDF/Word/图片文档
c.[ ] 能提取基本关键信息
d.[ ] 能进行简单的符合度分析
e.[ ] 响应时间 < 90 秒
f.[ ] 准确率 > 75%
c.试运行阶段方案 (3-8 周)
a.方案概述
a.说明
核心目标: 优化性能和准确率
b.代码示例
---
试运行方案:
├── 文档处理: PaddleOCR + Qwen2-VL-7B (按需)
├── 模型调用: 硅基流动 Qwen2.5-32B
├── 框架: Python + FastAPI + 部分 LangChain
├── 网关: NewAPI (可选)
├── 并发: asyncio + 限流控制
└── 合规: 基础安全措施
---
b.技术栈
a.表格数据
组件 选择 理由
后端 Python + FastAPI 成熟稳定
前端 Vue 3 + TypeScript 生产级
数据库 PostgreSQL 数据持久化
缓存 Redis 会话和结果缓存
OCR PaddleOCR 保留
多模态 Qwen2-VL-7B (按需) 复杂场景
文本模型 Qwen2.5-32B 性能提升
调用方式 直接调用 + LangChain 混合
网关 NewAPI 多渠道管理
并发 asyncio 支持 10 并发
c.架构优化
a.代码示例
---
# 混合策略实现
class EvaluationService:
"""混合服务"""
def __init__(self):
# 简单任务: 直接调用
self.simple_llm = DirectLLM(model="qwen2.5-7b")
# 复杂任务: LangChain
self.complex_llm = ChatOpenAI(model="qwen2.5-32b")
self.complex_chain = self._build_chain()
async def simple_task(self, prompt):
"""简单任务: 直接调用"""
return await self.simple_llm.invoke(prompt)
async def complex_task(self, doc):
"""复杂任务: LangChain"""
return await self.complex_chain.ainvoke({"doc": doc})
def _build_chain(self):
"""构建 Chain"""
prompt = ChatPromptTemplate.from_template(
"分析标书:\n{doc}\n\n给出详细评价"
)
return prompt | self.complex_llm | StrOutputParser()
---
d.成本估算
a.表格数据
项目 成本 说明
服务器 ¥400-800 4核8GB
API 调用 ¥500-1000 中等用量
数据库 ¥200-400 云数据库
总计 ¥1100-2200/月 运营成本
e.验收标准
a.说明
---
b.[ ] 支持完整的评标流程
c.[ ] 准确率 > 85%
d.[ ] 响应时间 < 60 秒
e.[ ] 支持 10 并发
f.[ ] 有基本的监控和日志
d.生产阶段方案 (9 周+)
a.三种选项
a.说明
根据实际使用量选择:
b.代码示例
---
选项 A: 继续云端优化
├── 适用: 小规模使用 (<50 份/月)
├── 成本: ¥2000-3000/月
├── 特点: 无硬件投入
└── 扩展: 按需扩展
选项 B: Ollama 本地部署
├── 适用: 中规模使用 (50-200 份/月)
├── 成本: 硬件 ¥15K + ¥450/月
├── 特点: 成本可控
└── 回本: ~2 年
选项 C: 昇腾 NPU 私有化
├── 适用: 大规模使用 (200+ 份/月)
├── 成本: 硬件 ¥100K + ¥3500/月
├── 特点: 完全合规
└── 回本: ~3-4 年
---
b.详细对比
a.表格数据
维度 选项 A (云端) 选项 B (Ollama) 选项 C (昇腾)
初始投入 ¥0 ¥15,000 ¥100,000
月成本 ¥2,000-3,000 ¥450 ¥3,500
年成本 ¥24-36K ¥20.4K ¥142K
2 年总 ¥48-72K ¥20.9K ¥184K
4 年总 ¥96-144K ¥21.8K ¥268K
数据安全 ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
可扩展性 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐
维护成本 低 中 高
推荐场景 小规模 中规模 大规模/高合规
c.决策流程
a.代码示例
---
生产环境决策流程:
开始
│
▼
月使用量?
│
├─ < 50 份 ──────────▶ 选项 A (云端)
│
├─ 50-200 份 ────────▶ 月预算 < ¥1000?
│ │
│ ├─ 是 ───▶ 选项 A (云端)
│ └─ 否 ───▶ 选项 B (Ollama)
│
└─ > 200 份 ─────────▶ 高合规要求?
│
├─ 否 ───▶ 选项 B (Ollama)
│
└─ 是 ───▶ 选项 C (昇腾 NPU)
---
b.说明
---
e.综合决策树
a.完整决策树
a.代码示例
---
评标工具技术选型决策树:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【文档处理】
│
├─ 文字提取 ──────────────────────▶ PyMuPDF
│
├─ 表格提取 ──────────────────────▶ Qwen2-VL-7B (按需)
│
├─ OCR 识别 ──────────────────────▶ PaddleOCR
│
└─ 语义理解 ──────────────────────▶ Qwen2.5-32B
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【多模态模型】
│
├─ 简单场景 ──────────────────────▶ Qwen2-VL-7B (硅基流动)
│
├─ 复杂表格 ──────────────────────▶ Qwen2.5-VL-32B (硅基流动)
│
└─ 图表理解 ──────────────────────▶ Claude 3.5 Sonnet
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【模型网关】
│
├─ 单渠道 ────────────────────────▶ 不需要
│
├─ 双渠道 ────────────────────────▶ LiteLLM
│
└─ 多渠道 ────────────────────────▶ NewAPI
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【LLM 框架】
│
├─ 简单问答 ────────────────────────▶ 直接调用
│
├─ 多步推理 ────────────────────────▶ LangChain (可选)
│
└─ 复杂工作流 ────────────────────▶ LangGraph (很少用)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【并发处理】
│
├─ 1-5 并发 ────────────────────────▶ asyncio
│
├─ 10-20 并发 ─────────────────────▶ asyncio + 限流
│
└─ 50+ 并发 ────────────────────────▶ Celery
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【合规方案】
│
├─ 基础合规 ────────────────────────▶ 国内云端 API
│
├─ 等保二级 ────────────────────────▶ 混合方案
│
└─ 等保三级 ────────────────────────▶ 完全本地化
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---
b.说明
---
f.实施路线图
a.时间规划
a.代码示例
---
完整实施路线:
Month 1: 验证期
├── Week 1-2: MVP 开发
│ └── 目标: 可运行的 Demo
│
├── Week 3-4: 内部测试
│ └── 目标: 修复明显问题
│
└── Week 5-8: 试运行
└── 目标: 优化性能
Month 3-4: 决策期
├── 评估使用情况
├── 评估成本效益
└── 决定后续方案
Month 5+: 生产期
├── 部署生产环境
├── 通过等保认证
└── 持续优化
---
b.里程碑
a.表格数据
时间 里程碑 交付物 验收标准
Week 2 MVP 完成 可运行 Demo 核心功能可用
Week 8 Beta 版 Beta 系统 准确率 > 85%
Week 12 生产决策 决策报告 明确后续方案
Week 16 生产部署 生产系统 稳定运行
b.说明
---
g.关键建议
a.核心原则
a.代码示例
---
技术选型的核心原则:
1. 简单优先
└── 能简单就不复杂
2. 渐进增强
└── 从 MVP 到生产，逐步升级
3. 成本可控
└── 避免过度投入
4. 功能导向
└── 以解决实际问题为目标
5. 合规优先
└── 不违反中国法律
---
b.避坑指南
a.说明
常见误区:
b.代码示例
---
❌ 误区 1: 一开始就用 LangChain
└── 事实: 70% 场景不需要
❌ 误区 2: 一开始就用复杂框架
└── 事实: 直接调用更简单
❌ 误区 3: 必须用最新技术
└── 事实: 稳定比新更重要
❌ 误区 4: 本地部署一定更好
└── 事实: 看规模和要求
❌ 误区 5: 必须用 LangGraph
└── 事实: 很少场景需要
✅ 正确做法:
├── 从简单开始
├── 按需升级
├── 控制成本
└── 关注合规
---
c.最终推荐
a.说明
对于大多数企业:
b.代码示例
---
推荐方案:
MVP (1-2 周):
└── PaddleOCR + 硅基流动 7B + 直接调用
└── 预算: ¥500-1000
试运行 (3-8 周):
└── PaddleOCR + Qwen2-VL-7B (按需) + Qwen2.5-32B + NewAPI
└── 预算: ¥1500-3000/月
生产 (小规模 <50/月):
└── 继续云端优化
└── 预算: ¥2000-3000/月
生产 (中规模 50-200/月):
└── RTX 4090 + Ollama (Qwen2.5-32B)
└── 预算: 硬件 ¥15K + ¥450/月
生产 (大规模 >200/月):
└── 昇腾 910B + Qwen2.5-72B
└── 预算: 硬件 ¥100K + ¥3500/月
---
c.说明
---
h.快速参考
a.快速查询表
a.说明
场景 → 推荐方案:
b.表格数据
我要... 推荐方案 页码
快速验证功能 直接调用 + 硅基流动 7B [本文档]
处理 PDF 表格 Qwen2-VL-7B [22.多模态模型]
处理复杂表格 Qwen2.5-VL-32B [22.多模态模型]
处理图表 Claude 3.5 [22.多模态模型]
多模型管理 NewAPI [23.模型网关]
简单调用 直接调用 [24.LLM框架]
多步推理 LangChain [24.LLM框架]
10 并发 asyncio [25.并发性能]
50+ 并发 Celery [25.并发性能]
基础合规 国内 API [26.合规性]
等保二级 混合方案 [26.合规性]
b.成本快速查询
a.说明
月成本估算:
b.表格数据
规模 方案 月成本 年成本
验证期 云端 7B ¥500-1000 ¥6-12K
小规模 云端 32B ¥1500-3000 ¥18-36K
中规模 本地 32B ¥450 ¥20.4K (含硬件)
大规模 昇腾 72B ¥3500 ¥142K (含硬件)
c.说明
---
文档版本：v1.0
创建日期：2025-01-15
状态：完成
i.相关文档索引
1.评标场景生态边界探索总览.md
2.文档处理生态边界探索.md
3.多模态模型生态边界探索.md
4.模型网关生态边界探索.md
5.LLM框架边界探索.md
6.并发性能边界探索.md
7.合规性边界探索.md
6 电子档案
6.1 [1]制定方案
01.常用信息1
a.智能问答-maxkb
1.模型配置，qwen-7b，ollama部署，可以小模型驱动不 32b
2.配置文件，支持json这种通用类型来驱动配置不，只能是书写mk后缀吗 测试环境 onepanel 35b
3.X-Pack功能，社区版、专业版支持性
4.悬浮24小时、完整对话框
5.社区版、知识库-50个，应用-5个
6.pg部署规模，如果数量过大，可以部署集群不 pg 专业版，冷备
7.专业版，公司用的话，可以支持哪些更多的功能给我们公司
b.智能问数-sqlbot
0.对已有数据表字段，要求性有哪些，可以效果更好
1.模型配置，qwen-7b，ollama部署，可以小模型驱动不 70b
2.高级智能体，这个flow工作流的编排工作，可以提供更多示例不
3.嵌入式对接，这个在线的github的demo，可以为已有系统提供更好接入不
4.内置的pg，如果操作数据量过大，可以部署集群不 单独连接pg
5.社区版、专业版，公司用的话，可以支持哪些更多的功能给我们公司 公司版：提示词
6.高级嵌入，响应json，官网给了标准格式
c.其他问题
商业版：试用时间，英伟达，128GB，共享架构
一体机：32b并发在20多个左右，40token/s，约30个字每秒
02.常用信息2
a.盒子
maxkb，专业版，3.8W
maxkb，企业版，27W，4个节点
1panel盒子，9.9w，专业版升为级企业版，补差价
统一内部 AI 网关，没有员工额度，这种损失也是企业内部 AI 建设必须躺的坑啊
-----------------------------------------------------------------------------------------------------
飞致云&山西路桥-MK技术交流
目前，我们产品在您的项目里面是怎么规划的呢
大版本，3年左右，新版本定价的50%，目前有下一版本的升级计划不，目前还在V2版本
维保期，随时换服务器，1年维保，授权的20%，单次更换的费用，走技术服务，最高维保8%+3000
-----------------------------------------------------------------------------------------------------
MAXKB，内置的CPU，向量模型
15个并发，2个串联，30-40个并发
同时支持100个并发，支持100个人来同时使用
有没有图片生成、视频模型一系列，高级智能体支持性
额外提供算力，内存、CPU加装，自己买，还是你们支持
b.预算
硬件：100W
软件：25-30W，maxkb企业版（多租户、docker集群）
消耗：各公司的Token使用
c.方向
AI代理，每个账号，AI网关，3W块钱
多租户下，不同租户绑定不同的API，调用算力，额外恶意使用
AI对话、意图识别、文本转语音、语音转文本、图片生成、图片理解、文生视频、图生视频、视频理解
6.2 [1]梳理知识
01.电子档案
a.信息1
a.整体
第2层 零库存 AI 企查查
第1层 电子档案（数据中台）
b.上下游零库存
1.采购：供应商资质、价格 采购
2.合同：多少钱，多少量 结算
3.结算：财务系统
4.付款：财务系统
c.企查查
子单位1234，每个单位有多个项目，每个项目有多个文件
审计：成本是多少、支持是多少、利润多少
d.服务器
服务器类型 配置 数量 说明
AI应用服务器 16C64G2T x 昇腾 910B 2 AI模型训练、OCR识别训练、AI模型运行
AI模型运行应用服务器 28C128G2T T4显卡 1 应用部署、Embedding加速
备份服务器 16C32G10T 1 模型备份、知识库备份、业务数据备份
b.信息2
a.硬件
1Byte = 8 Bit
1KB = 1,024 Bytes
1MB = 1,024 KB = 1,048,576 Bytes
1GB = 1,024 MB = 1,048,576 KB = 1,073,741,824 Bytes
1TB = 1,024 GB = 1,048,576 MB = 1,073,741,824 KB = 1,099,511,627,776 Bytes
1PB = 1,024 TB = 1,048,576 GB =1,125,899,906,842,624 Bytes
1EB = 1,024 PB = 1,048,576 TB = 1,152,921,504,606,846,976 Bytes
1ZB = 1,024 EB = 1,180,591,620,717,411,303,424 Bytes
1YB = 1,024 ZB = 1,208,925,819,614,629,174,706,176 Bytes
-------------------------------------------------------------------------------------------------
1台，2台
qwen3.5:122b
30w机器、信创、不做训练
b.操作方式
方式：语义分析
目的：3个子系统，字段关联
目的：纸质档案电子化（数据化加工），变成电子档案1w个，整体数据干什么，怎么利用，集团数据怎么穿透
手段：数据采购、数据集中、数据分析
数据源：数据中台 + 成型的电子档案
c.PPT交付
1.技术方案
2.能行，怎么做，方式，资源（硬件）
3.模型免费，qwen3.5:122b，30w机器、信创
4.采购电子档案系统：购买，二开
5.电子档案：纸质电子化，存储，利用
6.前后端开发、AI方向（专责）
7.团队：整体
8.大小白讲清楚、方案落地
d.关键点
1.技术方案
2.是否可行，怎么做
3.机器预算
c.信息3
a.分类1
1.存储层规划 — TB级数据量的硬盘容量规划（如10TB）
2.计算资源配置 — CPU+内存决定数据灌入吞吐能力
3.关系型数据库 — 达梦、金仓等信创数据库
4.非结构化数据处理 — 使用 Unstructured 库对 Office/PDF/HTML 等文档进行 OCR 识别与结构化解析
5.向量数据库 — Milvus、Chroma 集群部署，承载向量化后的文档数据
6.大模型部署与调优 — 开源模型私有化部署，针对业务场景进行调参与领域数据微调
7.多智能体框架 — 通过 LangChain 等框架驱动向量库，结合提示词工程完成后端逻辑与前端交互
8.项目周期规划 — 3-4周完成方案验证与框架确认，后续从硬件、数据库、前后端等方向持续优化
b.分类2
1.数据量TB级别的，是要看，硬盘大小，比如10TB
2.驱动Tb级别的数量，是要看CPU+内存，一下子能灌进去多少数据
3.存储方向，主要存储是达梦+金仓，信创的关系型存储结构
4.现在全部docs，OCR识别，要借助【Unstructured，通用的异构数据ETL库，能将 Office/PDF/HTML 等各类文档拆解为适合 RAG 的标准元素列表】，放到集群环境下的【Milvus、Chroma】向量库
5.选择开源大模型，部署到自己的服务器，这个模型的对于场景的落地性，要针对性调参、喂专门的材料给它去做这个场景
5.借助多智能体框架，类似LangChain来驱动【向量库】这样数据库，通过【提示词】等内部的方式来做【后端设计+前端交互】
6.代码设计，最初方案验证大概在3-4周，这是大体框架确认的阶段，后续【优化】有如下方向：硬件（大模型）、数据库+向量库、后端设计+前端交互
02.学习路线
a.分类1
a.信息1
a.模型
部署：qwen3.5:122b
1.量化：90%性能
2.指令：模型好不好，与指令好不好有关系
3.在线API：651b
b.模型
部署：vllm、ollama
1.并发量
2.CPU溢出
3.GPU加速
c.关键字
INT4量化、NT4精度
1台8*A800，80GB，部署3个通用模型（72B用4卡）
b.信息2
a.知识库
工会：知识库+嵌入RAG
b.模型调整
专业模型：微调（5000条，训练集）、全量 减少指令丢失
特别模型：微调、全调（50000条，训练集）
c.向量库
走向量数据库，专属模型、自动分片
d.服务
1.MCP（内置API，供AI来调用）
2.Skills + CLI + UI
b.分类2
a.信息1
a.方式
1.Agent：n8n、dify、coze（开源、豆包）
2.代码：接入openviking
3.统一平台、独自平台
4.其他：mcp，枚举值匹配有问题，有时候返回md，有时候返回json
b.问答
1.模型
2.知识库（word、pdf）/知识图谱（准确率达95%）
3.说明：模型使用【向量数据库】来解锁【知识库、知识图谱】
4.说明：业内（传统RAG、三次解锁，知识库）
b.信息2
a.Agent落地
1.看对接
2.参数不一致（传json返md，Agent异常处理）
3.全参微调
b.Coze开源
1.在线切分（引入插件、配置模型）
c.信息3
a.可行性
1.问答（从最简单的开始、蓝凌知识库）
2.问数（数据分析）
3.审批：mcp
b.问答知识库
问答1个 -> 知识库（多个） -> 区分
｜
每个部门的Agent（提示词）
｜
知识库（示例、具答）
c.出差报费
1个流程、模板固定
出差申请 -> 发票 -> 12306 -> mcp调用
AI不能直接操作：1.填表单 2.判断异常 3.火车（起始地）、报销
c.分类3
a.信息1
a.要求
每个部分，各自1个问答系统
1.招采智能化
2.工会：问答
3.审批：多个，操作系统（绑定业务系统）
b.调研
招采：报表mcp
财务：智能体skills
方式：1.提示词 2.工作流（token+mcp报表）
c.招采规划
1.蓝凌知识库
2.整体：规划中（建模）、RAG重构、4、5月份有动作
3.工会：直接调用（线上API）
b.信息2
a.钉钉
1.问答：口径一致
2.外部：客服
3.内部：审批（标准、机器人），流程：AI风险 -> 模型（基准能力）
报表：mcp，哪些接口、规定
b.例1：招采
1.并发50个
2.模型本地化
3.NPU，贵20%以上
c.例2：招采
1.垂直领域，起步14b，32b为主
2.知识库：应用，传统RAG/知识图谱
c.信息3
a.要求
1.摸清需求、最低要求
2.不冒进，包括经济实用、快速感受
3.三家单位出一套自己的意见，主要包括这几点：多少钱、多长时间、第123步怎么走怎么做
b.要求
1.架构图（不同单位）：多大规模
2.不动手：你问我答、生成文档+视频
3.请xxx批阅：跳开OA（模式1）、小龙虾（模式2）
4.审批：1个建议（不自动操作）、5点中的3点（自动操作）
03.智能问数
a.汇总
a.主流独立智能问数平台（企业级）
SQLBot（飞致云 DataEase）：https://dataease.cn/sqlbot/
SmartBI 白泽：https://www.smartbi.com.cn/
察言观数 AskTable：https://www.asktable.com/
网易知数（网易数帆）：https://m.sf.163.com/product/chatBi
OneInsight（上海清三）：https://www.shqingsan.com/
b.互联网/云厂商BI内嵌问数能力
火山引擎 Data Agent：https://www.volcengine.com/docs/86760
阿里云 Quick BI：https://www.aliyun.com/product/bigdata/bi
金蝶 ChatBI：https://www.kingdee.com/topic/kccs2025/
c.传统BI厂商的AI问数模块
亿信华辰・智问：https://www.esensoft.com/
国双 Gridsum BI：https://www.gridsum.com/
Kyligence：https://cn.kyligence.io/
b.主流独立智能问数平台（企业级）
a.SmartBI白泽（思迈特软件）
a.核心定位
企业级、高准确率的Agent BI平台
b.技术
指标模型+RAG+AI Agent，NL2SQL准确率98%+
c.优势
a.行业案例
金融、央国企、制造业落地案例多
b.功能支持
支持复杂业务口径、多轮对话、数据归因
c.部署支持
支持私有化部署、信创适配
b.察言观数AskTable
a.核心定位
专注NL2SQL的AI数据助手
b.优势
a.准确率
宣称NL2SQL准确率99%
b.功能支持
支持多数据源统一查询、细粒度权限、私有化
c.适用场景
适合对数据安全、查询精度要求高的场景
c.网易数帆-网易知数
a.核心定位
全栈式对话分析平台
b.优势
a.语义理解
中文语义理解强，支持多轮对话、自动推荐分析方向
b.数据源支持
接入50+数据源，支持结构化+非结构化文档融合
c.认证
信通院「可信AI数据分析智能体」最高4+级认证
d.OneInsight（上海清三）
a.核心定位
贴近人类分析逻辑的AI分析平台
b.优势
a.语境理解
支持业务语境理解、多轮追问、自动拆解分析
b.场景定位
强调复杂业务场景落地，非单纯生成SQL
c.互联网/云厂商BI内嵌问数能力
a.火山引擎Data Agent（字节跳动）
a.定位
通用大模型驱动、云原生
b.优势
a.模型能力
模型能力强、迭代快、部署灵活
b.适用场景
适合互联网、电商、快速验证AI场景
b.阿里云Quick BI
a.定位
阿里云生态、轻量化、快速上手
b.优势
a.生态集成
与阿里云数据库（RDS、MaxCompute）无缝集成
b.适用场景
适合阿里云用户、中小企业快速搭建可视化
c.金蝶苍穹ChatBI
a.定位
ERP生态内置问数
b.优势
a.数据对接
深度对接金蝶ERP、财务、供应链数据
b.功能支持
支持提示词模板、上下文关联、多端适配
d.传统BI厂商的AI问数模块
a.亿信华辰-亿信ABI·智问
a.定位
政务/统计领域强、全链路数据服务
b.优势
a.输入方式
支持自然语言、语音输入、多轮对话
b.行业模板
内置大量政府/财政/税务行业模板
b.国双科技-Gridsum BI智能问数
a.定位
司法、能源等垂直行业深度适配
b.优势
a.技术能力
自主分布式引擎、深度中文理解、信创支持
b.分析功能
支持归因分析、预测、数据下钻
c.Kyligence
a.定位
OLAP引擎+AI增强
b.优势
a.查询性能
大数据量、高并发查询性能极强
b.适用场景
适合数据仓库、数据中台、技术团队二次开发
04.智能问答1
a.汇总
a.主流独立智能问答平台
通义千问（阿里云）：tongyi.aliyun.com
文心一言（百度）：yiyan.baidu.com
讯飞星火认知大模型（科大讯飞）：xinghuo.xfyun.cn
智谱清言（智谱AI）：chatglm.cn
豆包（字节跳动）：www.doubao.com
360智脑：ai.360.cn
b.垂直领域智能问答平台
法信智答（法律领域）：www.faxin.cn/zhinengfayan/
医渡云・智能医疗问答（医疗领域）：www.yiducloud.com/product/medical-qa
税智星（财税领域）：www.shuizhixing.com
政务智能问答系统（浪潮）：www.inspur.com/cn/cloud/government/intelligent-qa.html
教育大脑・智能问答（好未来）：www.100tal.com/tech/education-brain/
c.企业级智能问答解决方案
网易数帆・企业智能问答：m.sf.163.com/product/enterprise-qa
智齿科技・智能问答机器人：www.sobot.com/product/intelligent-robot/
容联七陌・智能客服问答系统：www.7moor.com/product/intelligent-qa.html
竹间智能・Emotibot企业问答平台：www.emotibot.com/product/qa-platform
云知声・企业智能问答解决方案：www.unisound.com/business/intelligent-qa
b.主流独立智能问答平台
a.通义千问（阿里云）
a.核心定位
阿里云自研通用大模型驱动的智能问答平台，覆盖个人与企业全场景
b.技术
基于达摩院大模型，支持多模态输入（文本、语音、图片）、上下文理解、知识图谱融合
c.优势
a.功能特性
支持多轮深度对话、逻辑推理、内容创作、数据解读，可接入企业私有知识库，实现定制化问答
b.生态集成
与阿里云全系产品（钉钉、企业云、数据库）无缝对接，提供API接口，支持二次开发与企业级部署
c.适用场景
企业办公协同、客户服务、内容生产、数据分析辅助
b.文心一言（百度）
a.核心定位
百度自研ERNIE大模型驱动的生成式智能问答平台，聚焦产业级应用
b.技术
基于知识增强大模型，支持跨模态对话、实时信息检索、插件扩展
c.优势
a.技术能力
中文语义理解准确率行业领先，支持复杂逻辑推理与多轮交互，内置丰富工具插件（文档分析、数据可视化、翻译等）
b.生态支持
深度对接百度搜索、百度智能云、百度地图等生态资源，提供企业版私有化部署、混合云部署方案
c.适用场景
企业数字化转型、智能客服升级、内容创作辅助、研发效率提升
c.讯飞星火认知大模型（科大讯飞）
a.核心定位
聚焦"认知智能"的通用智能问答平台，侧重行业落地与实用化
b.技术
基于讯飞星火大模型，支持语音+文本双模态交互、实时知识更新、多场景适配
c.优势
a.交互体验
语音识别准确率99%+，支持方言、多轮语音对话，文本问答响应速度快，支持复杂指令拆解
b.行业适配
内置教育、医疗、金融、政务等20+行业场景模板，支持信创适配，满足国企/政务安全要求
c.部署方式
公有云、私有化、混合云多种部署选项，灵活适配企业需求
d.智谱清言（智谱AI）
a.核心定位
依托智谱GLM大模型，主打"轻量化+高精度"的智能问答平台
b.技术
基于千亿参数大模型，支持上下文记忆、多轮追问、知识推理
c.优势
a.知识能力
覆盖自然科学、人文社科、技术研发等多领域知识库，支持专业领域深度问答（如编程、数学建模、学术研究）
b.协作特性
支持多人协作对话、文档共享解读、实时批注，轻量化部署，中小企业无需复杂配置即可使用
c.扩展能力
提供开放API，支持与企业OA、CRM系统集成，支持自定义知识库上传，快速搭建企业专属问答助手
e.豆包（字节跳动）
a.核心定位
字节跳动自研大模型驱动的智能问答平台，兼顾个人与企业场景
b.技术
基于火山引擎大模型，支持多模态交互、实时信息同步、个性化适配
c.优势
a.交互体验
中文表达自然流畅，支持趣味化、场景化对话，响应速度快，支持长文本处理与多轮深度交互
b.生态联动
与抖音、飞书、火山引擎云服务深度集成，企业版支持私有化部署，保障数据安全
c.适用场景
个人学习、内容创作、办公辅助、企业客户服务、内部知识问答
f.360智脑
a.核心定位
360集团推出的安全优先型智能问答平台，聚焦政企与个人安全场景
b.技术
基于360大模型，支持安全合规校验、实时网络信息检索、多源知识融合
c.优势
a.安全特性
内置内容安全审核机制，规避违规风险，支持私有化部署，数据不泄露，满足政企安全要求
b.信息能力
接入360搜索引擎，实时获取最新网络信息，支持热点事件解读、行业动态分析、政策文件解读
c.场景适配
适合政企办公、网络安全咨询、合规审查、公众信息查询等场景
c.垂直领域智能问答平台
a.法信智答（法律领域）
a.定位
专注法律行业的智能问答平台，为律师、法官、企业法务、公众提供专业法律问答服务
b.优势
a.专业度
依托法信数据库（涵盖法律法规、案例、司法解释），问答准确率高，支持法律条文检索、案例匹配、法律意见生成
b.功能支持
支持复杂法律问题拆解、多场景法律方案推荐，提供法律文书生成（合同、起诉状、答辩状等）
c.适用场景
律师办案辅助、企业合规审查、公众法律咨询、法律教学实训
b.医渡云・智能医疗问答（医疗领域）
a.定位
聚焦医疗健康领域，为医院、药企、公众提供专业医疗问答与辅助决策服务
b.优势
a.医疗资源
接入全国多家三甲医院数据，覆盖常见疾病、慢病管理、用药指导等场景，由专业医师团队参与知识库构建，确保回答专业性
b.功能特性
支持症状自查、疾病科普、用药咨询、报告解读，企业版支持医院电子病历分析、临床路径推荐
c.合规性
符合医疗数据安全法规，保障用户隐私，支持与医院HIS、LIS系统集成，实现数据互通
c.税智星（财税领域）
a.定位
专注财税领域的智能问答平台，为企业财务、税务人员、个体工商户提供财税咨询服务
b.优势
a.专业覆盖
涵盖增值税、企业所得税、个税等全税种知识，实时更新财税政策，支持政策解读与合规咨询
b.功能支持
支持纳税申报疑问解答、税务筹划方案推荐、财税风险预警，提供发票管理、记账辅助、税务文书生成工具
c.适用场景
企业税务合规、中小企业财税咨询、财务人员培训、个体工商户纳税指导
d.政务智能问答系统（浪潮）
a.定位
面向政府部门的智能问答解决方案，用于政务服务大厅、官网、公众号等渠道的公众咨询
b.优势
a.政务适配
覆盖社保、医保、公积金、工商注册、行政审批等政务场景，内置地方政策知识库，支持地域化问答适配
b.交互能力
支持语音、文本、图片多方式咨询，适配不同人群，支持多轮对话，解决复杂政务咨询问题
c.部署支持
支持政务云部署、私有化部署，满足信创要求，可与政务服务平台、12345热线系统集成
e.教育大脑・智能问答（好未来）
a.定位
聚焦K12及高等教育领域，为学生、教师、家长提供教育类智能问答服务
b.优势
a.教育资源
覆盖教材同步知识点、习题解析、学习方法指导，由一线教师参与知识库构建，贴合教学场景
b.功能特性
支持个性化学习规划、错题分析、作业辅导，教师版支持备课辅助、学情分析、教案生成
c.适配场景
学生自主学习、家长辅导、教师教学辅助、学校智慧校园建设
d.企业级智能问答解决方案
a.网易数帆・企业智能问答
a.定位
面向企业的全场景智能问答解决方案，聚焦内部知识管理与外部客户服务
b.优势
a.知识管理
支持企业知识库自动构建、更新、检索，无需人工大量标注，支持结构化（Excel、数据库）与非结构化（文档、图片）知识融合
b.功能支持
内部支持员工培训问答、办公流程咨询、知识库查询，外部支持客户咨询、产品售后、营销推广智能应答
c.集成能力
与企业OA、CRM、ERP系统无缝对接，支持私有化部署，保障企业数据安全
b.智齿科技・智能问答机器人
a.定位
专注企业客户服务场景的智能问答解决方案，替代人工处理高频咨询
b.优势
a.客服适配
支持电话、网页、APP、微信等多渠道接入，内置电商、金融、教育、医疗等行业客服话术模板
b.交互能力
支持意图识别、多轮对话、情绪识别，模拟人工客服体验，可自动转接人工坐席，实现"智能+人工"无缝衔接
c.数据分析
提供咨询热点统计、用户意图分析、问答准确率报表，帮助企业优化产品与服务流程
c.容联七陌・智能客服问答系统
a.定位
企业级全渠道智能问答解决方案，侧重中小企业轻量化部署
b.优势
a.易用性
可视化配置界面，无需技术团队即可快速搭建问答机器人，支持话术模板一键导入、知识库批量上传
b.功能支持
支持常见问题自动应答、订单查询、售后处理、预约服务，支持语音导航、智能转接、客户标签管理
c.部署方式
公有云SaaS部署为主，快速上线，按需付费，支持与容联云通信、CRM系统集成，形成服务闭环
d.竹间智能・Emotibot企业问答平台
a.定位
基于情感计算的企业智能问答平台，兼顾"效率+体验"
b.优势
a.情感交互
支持情绪识别与共情回应，提升客户咨询体验，对话风格可定制（专业、亲切、严肃等）
b.知识能力
支持知识图谱构建，实现关联问题自动推荐，支持模糊查询、错别字容错，提升问答准确率
c.行业适配
深度适配金融、零售、政务、医疗等行业场景，支持私有化部署与信创适配，满足大企业安全要求
e.云知声・企业智能问答解决方案
a.定位
以语音交互为核心的企业智能问答平台，聚焦"语音+文本"全场景
b.优势
a.语音能力
语音识别准确率98%+，支持方言、噪声环境识别，支持语音唤醒、多轮语音对话、语音指令执行
b.部署灵活
支持公有云、私有化、边缘计算部署，适配不同企业规模，轻量化架构，硬件要求低，部署成本可控
c.集成场景
适合智能硬件（音箱、机器人）、呼叫中心、政务大厅、车载场景，可与企业现有系统（OA、ERP、CRM）快速集成
05.智能问答2
a.汇总
Dify dify.ai
FastGPT fastgpt.cn
RAGFlow ragflow.io
QAnything qanything.ai
Anything-LLM anythingllm.com
PandaWiki pandawiki.docs.baizhi.cloud/
b.知识库问答平台1
a.Dify
a.核心定位
全能型LLM应用开发平台，不仅是知识库，更是一套完整的大模型应用开发框架（中间件）
b.优势
a.功能全面
支持知识库RAG、可视化工作流编排、智能体（Agent）、插件系统、LLMOps
b.模型兼容
支持国内外几乎所有主流大模型，配置灵活
c.企业级
完善的权限管理、SSO、多租户功能
c.对比MaxKB
功能比MaxKB强大得多，但相对复杂，更适合需要深度定制的技术团队
b.FastGPT
a.核心定位
知识库驱动的AI应用平台，主打自动化工作流
b.优势
a.Flow编排
强大的可视化工作流，可构建复杂问答逻辑
b.商业能力
内置收费、计费、会员系统，适合快速商业化
c.性能优化
针对大数据量知识库做了性能优化
c.对比MaxKB
功能比MaxKB更丰富，支持工作流和Agent，但上手门槛略高
c.RAGFlow
a.核心定位
深度文档理解的开源RAG引擎，主打高准确率、可解释
b.优势
a.文档解析
超强的复杂格式（PDF、扫描件、表格、排版）解析能力
b.有理有据
回答时能精准标注知识来源片段，可信度高
c.检索优化
智能分片、多路召回，显著提升长文档问答准确率
c.对比MaxKB
专注于RAG底层引擎，文档解析和检索精度是强项，适合对准确性要求极高的场景（如法律、科研）
c.知识库问答平台2
a.Anything-LLM
a.核心定位
极简主义私有化部署方案，全栈打包，轻量化
b.优势
a.部署极简
一键Docker部署，硬件要求低，个人电脑也能跑
b.纯本地
支持完全离线运行，保护数据隐私
c.多格式
支持文档、音频、视频等多种文件
c.对比MaxKB
极度轻量化、易部署，适合个人或小团队快速搭建私有知识库，但企业级复杂功能较少
b.QAnything（网易有道）
a.核心定位
网易有道开源的本地知识库问答系统，主打离线、双语、高性能
b.优势
a.全格式支持
完美支持PDF/Word/PPT/图片（含扫描件）及网页抓取
b.两阶段检索
Embedding+Rerank架构，大数据量下性能稳定
c.跨语言
强大的中英文混合语义理解能力
c.对比MaxKB
由大厂（网易有道）开源，文档解析和跨语言能力突出，支持纯离线部署
c.PandaWiki
a.核心定位
轻量级开源AI知识库，面向开发者和技术团队
b.优势
a.极速部署
Docker一键启动，界面简洁
b.代码友好
深度适配代码文档管理，适合技术团队内部使用
c.对比MaxKB
非常轻量、简洁，但AI功能基础（无工作流、无Agent），适合简单场景
6.3 [1]梳理需求1
01.最初需求
a.说明1
a.场景
我不需要你设计代码，这个是国企领导，让安排的那种汇报的最初规范。
然后，要出【1.技术方案；2.是否可行，怎么做；3.机器预算】
其中，有2个业务场景，1个是【零库存】、1个是【企查查】
b.数据来源
然后，现在数据来源主要有2个方向
1.电子档案（数据中台）：达梦、金仓等信创数据库
2.成型的电子档案：OCR文件，数量集在PB级别，可以使用【非结构化数据处理，使用 Unstructured 库对 Office/PDF/HTML 等文档进行 OCR 识别与结构化解析】
b.说明2
a.零库存
这个【零库存】是这样的，下面有3个传统意义数据库的系统，还是互相割裂的状态，主要有下面4个流程
1.采购：供应商资质、价格 采购系统
2.合同：多少钱，多少量 结算系统
3.结算：财务系统
4.付款：财务系统
最后我要实现什么呢，我要拿【AI】，整体利用【这3部分的数据】，我想知道【整体数据干什么，怎么利用，集团数据怎么穿透】
b.企查查
这个【企查查】是这样的，我们集团的每个下面有子单位1234多个，每个单位有多个项目，每个项目有多个文件，这些文件应该是PB级别的。
然后我们希望把这里面材料进行【审计】，最后利用【AI】，来做【成本是多少、支持是多少、利润多少】
c.补充说明
我希望你告诉我，验证、优化、内测、上线，这2个【零库存】【企查查】大致的项目周期，项目开发AI只有我一个人。
我补充一点，我们打算【采购电子档案系统：购买，二开使用】，我是专门做AI场景落地的，其他【前后端】是别的项目人接手
c.说明3
a.机器预算
【机器预算】方向，暂时申请了【模型免费，qwen3.5:122b，30w机器、信创，模型 不做训练】，
但是可以向上调整价格申请，这个你也要考虑给我，模型也可以更换，但尽可能是中文支持最好。
资源（硬件），你可以参考其他团队的 PPT方案，
服务器类型 配置 数量 说明
AI应用服务器 16C64G2T x 昇腾 910B 2 AI模型训练、OCR识别训练、AI模型运行
AI模型运行应用服务器 28C128G2T T4显卡 1 应用部署、Embedding加速
备份服务器 16C32G10T 1 模型备份、知识库备份、业务数据备份
b.硬件报价
硬件报价，你去github，淘宝、京东，按照政府采购价位，给出价格预算，专门做AI方向的就可以，然后硬件，英伟达、昇腾你给出2套方案
我给你之前我做的生态调查，/Users/troyesivens/Documents/software_yare/langchain-page/机器情况.md
d.说明4
a.文档
你针对这几部分内容，我建议你写4个文档
1.我这么多打字的内容，你细化1个最初需求文档
2.零库存，是否可行，怎么做，大致给一个 技术方案
3.企查查（企业内部），是否可行，怎么做，大致给一个 技术方案
4.昇腾机器，整体预算，几台机器，每台机器报价，每台机器做什么，部署什么
5.英伟达机器，整体预算，几台机器，每台机器报价，每台机器做什么，部署什么
b.关键点
你需要告诉我3个关键点，1.技术方案；2.是否可行，怎么做；3.机器预算。
使用【/Users/troyesivens/Documents/software_yare/langchain-page/国企-汇报.md】大白话来告诉领导，应该怎么做
02.整理需求
a.说明1
a.两个业务场景
场景 现状 目标
零库存 3个割裂系统（采购、合同/结算、财务） AI整合数据，实现集团数据穿透
企查查（企业内部） 集团→子单位→项目→文件（PB级） AI审计：成本、支出、利润分析
b.数据来源
结构化数据：电子档案（数据中台）- 达梦、金仓等信创数据库
非结构化数据：成型的电子档案 - OCR文件（PB级别）
c.我需要交付的5个文档
需求文档 - 细化您的所有描述
零库存技术方案 - 是否可行，怎么做
企查查技术方案 - 是否可行，怎么做
昇腾机器预算方案 - 机器数量、报价、用途、部署
英伟达机器预算方案 - 机器数量、报价、用途、部署
d.额外要求
参考 国企-汇报.md 的大白话风格
参考 机器情况.md 的硬件信息
给出项目周期（验证→优化→内测→上线），AI开发只有您1人
硬件价格按政府采购价位（参考GitHub、淘宝、京东）
b.说明2
a.技术可行性论据
技术领域 官方/GitHub论据 结论
Qwen2.5-72B部署 Hugging Face、vLLM官方 Int4量化后需45GB显存，可行
昇腾910B性能 知乎实测：算力376TFLOPS，对标A100 可行，生态适配需额外工作
PB级RAG Milvus官方：支持万亿级向量，延迟降低2.5倍 可行
OCR批量处理 GPU加速OCR：85万页/天 可行
国产数据库对接 LangChat Pro：零代码兼容达梦、金仓 可行
文档处理 6大工具对比：100万页PDF约190美元 可行
b.硬件价格参考
方案 配置 参考价格 来源
昇腾910B单卡 FP16算力376TFLOPS 约12万元/卡 招标公告
昇腾910B八卡服务器 8×910B 100-140万元/台 行业报告
A100 80GB单卡 80GB显存 约16万元/卡 中关村在线
A100八卡服务器 8×A100 80GB 约200万元/台 市场参考
c.说明3
a.硬件
路线 预算范围 优点 缺点
A.昇腾910B（信创） 100-150万/台 符合信创要求，政府采购友好 生态适配需额外工作
B.英伟达A100 180-220万/台 生态成熟，文档丰富 不符合信创，受出口管制
C.混合方案 看配置 灵活 维护复杂
b.数据优先级
场景 数据特点 处理难度 建议优先级
零库存 结构化数据，3个系统 中等（需打通接口） 先做
企查查 PB级非结构化，OCR 高（处理量大） 后做
c.采购vs自研
模块 采购 自研
电子档案系统 您已决定采购+二开 -
OCR处理 - 使用 Unstructured 库对 Office/PDF/HTML 等文档进行 OCR 识别与结构化解析
RAG框架 - LangChain+LlamaIndex（您做）
向量数据库 Milvus集群
d.项目周期预期（按1人AI开发估算）
阶段 零库存 企查查
需求+设计 2周 2周
数据准备 3周 6周（OCR量大）
开发+调优 6周 8周
测试+内测 2周 3周
合计 约3个月 约5个月
d.说明4
a.场景一：零库存（跨系统数据穿透）
a.图示
┌─────────────────────────────────────────────────────────┐
│ AI智能分析层 │
│ Qwen2.5-72B + LangChain Agent │
└─────────────────────┬───────────────────────────────────┘
│
┌─────────────────────┴───────────────────────────────────┐
│ RAG知识库层 │
│ Milvus向量库 + 向量化索引 + 语义检索 │
└─────────────────────┬───────────────────────────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ 采购系统 │ │ 结算系统 │ │ 财务系统 │
│ (达梦/金仓)│ │ (达梦/金仓)│ │ (达梦/金仓)│
└───────────┘ └───────────┘ └───────────┘
b.核心能力
语义关联：通过AI理解三个系统中的字段语义关联
数据穿透：一条查询自动跨三系统检索
异常发现：价格偏离自动预警
b.场景二：企查查（项目档案审计）
a.图示
┌─────────────────────────────────────────────────────────┐
│ AI审计分析层 │
│ Qwen2.5-72B + 结构化分析Agent │
└─────────────────────┬───────────────────────────────────┘
│
┌─────────────────────┴───────────────────────────────────┐
│ 文档处理管道（Unstructured） │
│ OCR识别 → 结构化解析 → 向量化 → 入库 │
└─────────────────────┬───────────────────────────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ 子单位1 │ │ 子单位2 │ │ 子单位N │
│ 项目档案 │ │ 项目档案 │ │ 项目档案 │
│ (PDF/扫描件)│ │ (PDF/扫描件)│ │ (PDF/扫描件)│
└───────────┘ └───────────┘ └───────────┘
b.核心能力
批量OCR：85万页/天（GPU加速）
成本分析：自动提取成本、支出、利润数据
审计留痕：每笔分析可追溯
03.水泥差价
a.场景背景
跨项目采购价格预警（如水泥 20元 vs 50元）业务场景下，结合数据中台（结构化数据）与档案数据（非结构化数据），
利用 AI 语义分析和意图模型定位差异原因。这两个概念到底是什么模型在跑，以及它们怎么帮你解释那 30 块钱的差价。
b.AI 语义分析
a.核心问题
这堆文字到底在说什么？
b.应用背景
在场景中，数据中台告诉你“价格有差异”，但为什么有差异，通常藏在非结构化的“档案”里（如合同条款、往来邮件、施工日志）。
c.模型选型
主流：基于 Transformer 架构的预训练模型。
具体模型：BERT 及其变体（RoBERTa, ELECTRA）用于基础语义理解；或者目前的 LLM（大语言模型）如 GPT-4, Claude, Qwen, Llama 等。
d.主要功能
实体提取 (NER)：从档案中抠出“标号 P.O 42.5”、“含运费”、“偏远山区”、“加急”等关键词。
关系抽取：识别出“项目B”与“运费险”之间的关联。
上下文理解：明白 50 元一斤的水泥可能不是因为贵，而是因为包含了“送货上楼”或者“特种抗渗要求”。
c.意图模型
a.核心问题
用户想干什么？他关心的核心逻辑是什么？
b.应用场景
意图模型通常用于交互界面（如你问系统：“为什么 B 项目水泥贵这么多？”），或者用于自动化流水线中的决策分类。
c.模型选型
传统方案：TextCNN, FastText 或 SVM（适用于意图类别固定的场景）。
现代方案：BERT-Sequence Classification 或 LLM + Prompt Engineering（利用大模型的零样本/少样本学习能力直接分类）。
d.主要功能
分类：判断你的查询意图是“查询价格”、“对比分析”还是“异常报警”。
槽位填充：识别出意图中的关键变量：项目（A、B）、物资（水泥）、维度（价格）。
d.协同工作流
a.说明
当系统发现 A（20元）和 B（50元）的差异时
b.AI的协同工作流程如下
步骤 参与组件 AI 模型的作用
1.触发预警 数据中台 (SQL/指标) 纯数值得出偏差值超过阈值（150%）。
2.意图识别 意图模型 系统自动识别出这是一个“采购合规性/成本差异分析”任务。
3.档案检索 向量数据库 将 A、B 项目的合同文档转化为向量，寻找描述差异的文本段落。
4.语义拆解 语义分析模型 读取 B 项目合同，发现关键词“特种加固”、“含 300 公里运费”，而 A 项目是“自提”。
5.生成结论 LLM (生成式 AI) 结合语义分析结果，告诉你：“差异主要在于 B 项目包含长途运费及特种材料要求，剔除后实际单价差异为 5%。”
6.4 [1]梳理需求2
01.常用信息1
a.项目背景与当前现状
a.项目来源
公司现有一套电子档案系统，近期刚交接过来，目前只有源码，团队正在梳理中。
暂未确定最终技术路线：在原有系统上二次开发、完全从零新建一套系统、直接采购第三方成熟产品。
b.老系统技术情况
a.技术栈信息
开发语言采用Java，数据库为MySQL，框架使用SpringBoot。
b.存储与架构
文件存储使用MinIO，存储在文件系统而非数据库，存储方式合理。核心档案表archives_doc具备主键索引及7个普通索引，索引较为完善。
c.现有资源缺失
带有工作流引擎并有代码注释，但缺失系统架构图及数据库设计文档。
c.老系统核心问题
a.数据规模与使用率
数据总量为2870G，日均使用人数不足10人。
b.性能瓶颈
性能极差，架构存在缺陷，导致加载列表与检索极慢。查询一次需数分钟，经常提示当前使用人数较多请稍后再试，严重影响使用。
d.领导决策
放弃现有问题较多的电子档案系统，全新建设一套新系统替代旧系统。
b.新系统六大硬性要求
a.业务流程保留
必须保留原有电子档案的全部业务流程，不能丢掉现有业务。
b.跨系统对接
需要对接集团各个子业务系统，实现数据互通。
c.数据分析报表
具备数据分析与数据报表能力，能够对各子业务系统数据进行分析。典型场景如对比不同项目同款物料的价格差异并分析原因。
d.内部企查查
建设集团内部版企查查模块，实现内部单位、合作方信息一键查询。
e.供应链优化
建设集团内部上下游0库存管理模块，实现供应链库存优化。
f.AI技术集成
集成AI语义分析等AI相关功能，提升智能化水平。
c.项目启动第一步
a.需求锚定与高层对齐
a.工作目标
领导提出的需求多为宏观管理方向，必须明确实现边界、优先级及验收标准，锁死项目范围。
b.产出物
制作需求对齐确认单，与领导沟通确认并签字，防止后期需求无限蔓延。内容涵盖原始需求、核心诉求拆解、实现边界及量化验收标准。
b.建立集团级项目组织
a.组织架构
本项目跨部门且跨子公司，需请集团分管领导担任项目总负责人。
b.部门协同
由本部门牵头，明确集团IT、法务、采购、财务及各子公司专人对接。通过项目启动会明确目标与责任，形成会议纪要解决配合问题。
c.全面摸底盘点
a.老系统与业务摸底
盘点老系统的流程、功能、数据结构、权限、痛点及合规性。同时盘点各子系统的名称、厂商、接口能力及数据标准。
b.合规与标准盘点
梳理电子档案国家标准、集团内控要求及行业监管要求。明确项目编码、物料编码、主体编码及档案分类规则。
d.六大需求详细落地拆解
a.保留原有电子档案流程
核心原则为先1:1复刻再小幅优化。完整梳理收集、整理、归档、保管、利用、销毁的全生命周期。制定历史数据迁移方案，新老系统并行至少3个月。
b.对接集团各子业务系统
优先对接项目管理、采购、合同、财务及法务系统。不直接对接各业务系统，统一从集团数据中台取数。制定统一接口标准与数据规范，先做单向归集。
c.数据分析与数据报表
利用数据中台原始数据进行清洗加工。在物料编码统一的基础上，实现同物不同价分析，自动识别异常价差并可穿透查看合同、订单、发票等凭证。
d.集团内部企查查模块
定位为集团内部专属信用查询工具。覆盖子公司、项目部、供应商及合作方。提供一键查询工商、资质、合同、诉讼等功能，并展示关联关系图谱。
e.集团上下游0库存模块
基于档案数据做库存协同。目标是基于项目、合同、订单档案实现供需匹配。提供物料需求预测、集团内部库存共享调拨及呆滞库存预警。
f.AI语义分析等AI模块
专注于电子档案场景。实现档案自动分类标引、OCR识别、合同风险条款自动识别及全文智能语义检索。确保核心场景准确率不低于95%。
e.数据穿透三大系统详细效果
a.人力系统与电子档案穿透
实现一人一档，一键查看人员证书、任职及招投标记录。AI自动预警证书过期或无资质上岗，为内部企查查提供人员及单位主体基础信息。
b.建设管理系统与电子档案穿透
实现一项一档，从立项至结算全流程追溯。自动对比价差并穿透查看项目进度、供应商差异、合同条款及材质要求，自动预警成本失控。
c.招采管理系统与电子档案穿透
实现一商一档，采购全过程留痕。自动识别价格异常、围标串标及违规条款。自动生成供应商信用画像以支撑内部企查查。
d.联动最终价值
建立集团级的一人一档、一项一档、一商一档体系。通过数据中台降低对接成本，打破数据孤岛，实现业务与档案数据一体化。
f.AI语义分析直白解释
a.定义与作用
AI语义分析使机器能理解文字的真实意思而非机械匹配。它能理解上下文、术语及风险点，用于自动处理文档并提取关键信息。
b.本项目具体应用场景
a.检索与归档
提供口语化精准检索。AI自动识别文件属性并自动归类打标签，无需人工整理。
b.数据处理与分析
将非结构化合同数据转为结构化数据，支撑同物不同价分析。从合同中提取付款方式、材质标准等因素分析价差原因。
c.预警与问答
自动识别证书过期或合同风险条款。支持大白话提问，由AI提供带数据依据的智能答案。
g.现在立刻可以做的事
a.数据对接准备
对接数据中台，确定人力、建设、招采系统的数据表、字段及取数方式。
b.业务需求调研
与工程部、采购部、成本部确认业务痛点与数据穿透的具体场景。
c.演示Demo制作
用Excel导出部分采购数据，制作同物不同价对比表及档案穿透演示，向领导展示预期效果。
h.项目分阶段落地计划
a.第一阶段
耗时1至2个月。重点解决老系统卡顿，复刻原有流程，对接数据中台并上线同物不同价分析看板。
b.第二阶段
耗时3至4个月。上线内部企查查模块，完善数据分析报表体系。落地智能检索、自动标引及风险预警等AI基础能力。
c.第三阶段
耗时5至6个月。上线0库存模块，完善语义分析。完成系统测试、培训及数据迁移，实现双系统并行并正式下线老系统。
02.常用信息2
a.项目初步需求分析说明书（总纲）
a.项目背景与目标
本项目旨在响应集团信创化、数字化转型要求，利用AI大模型技术，对集团现有的PB级数据进行深度挖掘。
核心目标是解决当前数据“看不了、算不清、连不上”的问题，实现业务场景的智能化落地。
b.核心场景描述
a.零库存（数据穿透）
现状：采购、合同、结算/付款三大系统相互隔离。
诉求：打破系统壁垒，利用AI实现从“供应商资质”到“财务结算”的全流程数据穿透，看清整体业务逻辑。
b.企业内部审计（类似企查查）
现状：各子单位、各项目积累了PB级的电子档案（OCR文件）。
诉求：利用AI自动读取、分析海量文档，自动核算成本、支出与利润，实现智能审计。
c.数据基础
a.结构化数据
存储于达梦、金仓等信创数据库（数据中台）。
b.非结构化数据
PB级的Office/PDF/HTML文档，需进行OCR识别与结构化解析。
d.团队分工
a.AI组（1人）
负责AI场景落地、模型调优、技术方案设计。
b.业务组/二开组
负责电子档案系统采购后的二次开发、前后端功能实现。
b.零库存场景技术方案与可行性分析
a.是否可行？
结论：高度可行。
目前大模型的“多步推理（Agent）”和“数据插件”技术已经成熟，完全可以胜任跨系统的数据检索与逻辑关联工作。
b.怎么做？（实施路径）
a.第一步：数据归集与向量化
将分散在达梦、金仓数据库中的采购、合同信息，以及电子档案系统中的非结构化文档，通过统一的Embedding（向量化）处理，存入向量数据库。
b.第二步：构建“大脑”逻辑
利用AI模型作为核心调度器。当你问“某个供应商的结算是否异常”时，AI会自动去采购系统查资质，去合同系统查价格，去财务系统查付款记录。
c.第三步：数据穿透可视化
AI将三方数据整合后，以链路图的形式呈现，实现真正的“全流程监控”。
c.技术路径（核心架构）
a.解析层
使用Unstructured库对非结构化文档进行高精度解析。
b.处理层
采用RAG（检索增强生成）+Agent（智能体）架构。
c.模型层
私有化部署Qwen系列模型（信创版），确保数据不出机房。
c.内部企查查/审计场景技术方案与可行性分析
a.是否可行？
结论：可行，但对算力有一定要求。
PB级数据的解析是难点。只要硬件资源到位，通过“分布式解析+大模型总结”，可以极大替代人工审计，提高效率。
b.怎么做？（实施路径）
a.第一步：海量识别
针对PB级文件，建立分布式的OCR识别集群，将图片、PDF转化为AI能看懂的文字。
b.第二步：知识库构建
按子单位、项目划分索引，确保AI检索时不会“张冠李戴”。
c.第三步：自动审计报表
设定审计规则（如：成本校验、利润核算模型），由AI定期扫描文档，自动提取关键财务指标，生成异常预警报告。
c.项目周期估算（AI部分）
a.验证期（2-4周）
选取少量样本数据进行模型跑通，验证解析准确率。
b.优化期（4-8周）
针对审计场景进行提示词（Prompt）工程调优和RAG性能优化。
c.内测试运行（4周）
小范围内上线，由审计人员核对AI输出的准确性。
d.正式上线
系统稳定后全量接入PB级数据。
d.硬件资源预算建议方案（昇腾vs英伟达）
a.方案A：国产信创方案（昇腾Ascend）
推荐理由：符合国企信创合规要求，910B对大模型支持良好。
设备名称 配置规格 数量 单价估算(万) 总计(万) 说明
AI计算服务器 昇腾910B (64G显存*8卡) 1台 140-160 150 负责122B模型推理及PB级数据向量化。
应用/推理服务器 鲲鹏CPU + 昇腾310P推理卡 1台 20-25 25 负责前端应用、中转、小模型OCR识别。
信创存储服务器 28C 128G + 40T存储 1台 10-15 12 模型备份、海量非结构化数据缓存。
合计 约187万
b.方案B：国际标准方案（英伟达NVIDIA）
推荐理由：生态极其成熟，开发效率最高。
设备名称 配置规格 数量 单价估算(万) 总计(万) 说明
AI核心服务器 NVIDIA H20或L40S (8卡集群) 1台 110-130 120 H20是目前合规采购的首选，显存大，适合122B模型。
应用加速服务器 28C 128G + 2张T4或4060Ti (16G) 1台 15-20 18 负责Embedding加速及业务逻辑。
备份服务器 16C 32G + 40T存储 1台 8-10 9 模型及知识库备份。
合计 约147万
03.常用信息3
a.方案
a.项目名称
集团PB级电子档案智能化（AI）应用试点方案汇报
b.汇报背景与目标
根据集团数字化转型及信创化要求，现拟针对“零库存管理”与“企业内部审计（类企查查）”两大核心场景，利用AI大模型技术开展数据价值挖掘。
本次汇报重点围绕技术实施方案、落地可行性分析及算力资源预算三个维度展开，旨在打通集团数据孤岛，实现数据深度穿透。
c.业务场景定义
a.场景一：上下游“零库存”穿透管理
现状：采购（供应商/价格）、合同（量价信息）、结算与付款（财务系统）三大业务线处于割裂状态。
AI目标：通过AI逻辑编排，联通达梦、金仓等信创数据库，实现从采购端到支付端的全链路数据穿透，解决“整体数据干什么、怎么用、如何穿透”的痛点。
b.场景二：企业内部审计助手（内部“企查查”）
现状：涉及集团及千余家子单位的多级项目资料，包含PB级别非结构化Office/PDF/HTML文件，已完成初步OCR化。
AI目标：利用大模型对海量文档进行结构化审计，自动核算成本、支出与利润，支撑经营决策。
d.技术路线概况
a.模型选型
拟采用Qwen-3.5-122B（或其他高性能中文基座），采取“模型免训练、场景化调优”策略，保障信创环境兼容性。
b.处理能力
利用Unstructured库对PB级非结构化数据进行深度解析与清洗，构建企业级知识库。
c.协作模式
AI落地由专人负责；电子档案系统通过“外部采购+二次开发”实现，前后端由相关项目组配合。
b.汇报
a.给领导汇报的“大白话”话术建议
领导，关于咱们这两个AI场景，我梳理了一下：
第一，技术上完全可行。我们打算用现在最先进的Qwen 122B大模型，配合信创数据库，把原本“死”的数据救活。
第二，零库存场景：重点是把采购、合同、结算这三个“孤岛”连起来，让AI帮我们盯着每一笔钱是怎么流动的，实现数据穿透。
第三，企查查场景：我们面对的是PB级的档案，靠人看是不可能的。我们通过AI自动识别（OCR），让大模型去审计这些文件，自动算出每个项目的成本和利润。
第四，关于预算：AI开发我一个人能顶上，前后端接现有项目组。目前最核心的是“服务器”，要跑动这么大的模型，国产昇腾方案大概需要180-190万，英伟达方案大概150万左右。
建议优先考虑昇腾，虽然贵一点，但完全符合信创要求，以后汇报也是个亮点。
b.关于项目周期的预估（大白话版）
针对你一个人负责AI落地的情况，我会在方案中按照以下节奏建议领导：
验证期（2-4周）：先拿一小部分（如一个子单位）的数据把模型跑通。
优化期（4周）：调整Unstructured解析精度和Qwen的回复逻辑。
内测期（1个月）：配合前端二开，让审计或财务部门试用。
上线期：PB级数据全量接入，滚动式扩容。
6.5 [2]可行报告
00.汇总
a.功能与场景
a.场景
零库存
企查查
智能客服
智能审核
智能评标
智能问答
智能问数
b.目标
10月份，18个Agent
c.团队
sys-common、审核代码
b.AI原生设计
a.设计理念
架构决策围绕"如果 AI Agent 需要做这件事会怎样"进行。
b.内置 MCP 服务器
AI Agent 可直接连接 CMS，管理内容、发布文章、修改设置。
c.Agent Skills 预定义
提供技能文件教 AI 完成特定任务，如 WordPress 迁移、插件创建、SEO 优化。
d.CLI 工具
提供命令行接口，专为 AI Agent 操作设计。
e.x402 协议
内置内容付费能力，支持 AI Agent 通过微付费获取授权。
01.技术方案1
a.我们要解决什么问题？
a.三套系统"各管各的账"
a.表格数据
系统 记什么 问题
采购系统 合同价 只管签合同的时候
结算系统 实付价 只管付款的时候
财务系统 入账额 只管记账的时候
b.说明
结果：三套系统不说话，等人工对账发现问题，钱早就追不回来了。
b.档案"堆着吃灰"
1.仓库里约100万份档案，10年积累
2.查一份合同：翻仓库3天
3.审一个项目：1.5个月，只能抽查10%
c.重复劳动太多
a.说明
核心问题：人干的事太重复，效率低、容易漏。
---
b.客服每天回答重复问题
c.审核员每天看证照
d.评标专家每天看标书
b.我们用什么技术解决？
a.四个"AI员工"
a.说明
把这套系统理解成一个"智能档案室"，里面有四个"AI员工"：
b.表格数据
AI员工 干什么活 通俗理解
拍照识字员 把扫描件变文字 就像你用手机扫文档，自动变成可搜索的文字
智能搜索员 根据意思找档案 不用精确匹配关键词，输入"高价案例"能找到意思相近的
AI老师傅 理解问题、给答案 就像一个干了20年的老审计，你问他什么都能答
AI团队 分工干复杂活 就像一个项目组，有人查资料、有人分析、有人写报告
b.工作流程（用人话说）
a.代码示例
---
你问一句话："XX项目有没有问题？"
↓
AI老师傅理解你的意思
↓
智能搜索员去档案库里找相关材料
↓
AI老师傅看了材料，整理出答案告诉你
↓
每个结论都能点开看原始证据
---
b.说明
---
c.核心技术用解释
a.拍照识字（OCR）
a.说明
技术描述：把图片里的文字识别出来，变成可搜索的文本。
：就像你用手机扫合同，系统自动把图片变成文字，以后就能搜索了。
能干什么：
---
b.十年的纸质档案，一周整理完
c.原来遇到争议要翻仓库3天，现在输入关键词10秒找到
b.输问题→搜档案→出答案（RAG）
a.说明
技术描述：检索增强生成。AI分析前先检索档案库，基于事实生成报告。
：AI回答问题前，先去档案库里查资料，然后基于查到的资料回答你。每个结论都有依据，不会瞎编。
能干什么：
---
b.输入"XX项目有没有问题"，AI自动检索相关档案，写分析报告
c.每个结论都能点开看原始证据
c.智能搜索库（向量数据库）
a.说明
技术描述：把文本转换成向量（数字坐标），存储在高维空间中，支持语义相似度检索。
：把所有档案转成"数字指纹"存入数据库。你输入"高价案例"，系统能在0.1秒内找到意思相近的20份历史合同。
能干什么：
---
b.不用精确匹配关键词
c.搜"溢价"能找到"加急费""快速通道费"等同义词
d.100万份档案，检索只要10秒
d.AI像员工一样自主工作（Agent）
a.说明
技术描述：智能体（Agent）是能自主执行任务的AI系统，可以规划步骤、调用工具、完成任务。
：AI不只是回答问题，还能自己干活。你告诉它"审一下这个项目"，它会自己规划步骤、查数据、翻档案、写报告，最后把报告发给你。
能干什么：
---
b.从"问答工具"升级为"数字员工"
c.发现异常后自动查数据、翻档案、发报告
e.多智能体协作（Multi-Agent）
a.说明
技术描述：多个智能体分工协作，每个智能体负责不同任务，共同完成复杂目标。
：组建一个AI团队，有人负责查资料、有人负责分析、有人负责写报告，分工协作把活干完。
能干什么：
---
b.评标时：资格审查AI + 技术评审AI + 商务评审AI + 评分顾问AI
c.各司其职，最后汇总成评标报告
f.AI大脑（大语言模型）
a.说明
技术描述：大规模预训练语言模型，如Qwen、GLM等，具备理解、生成、推理能力。
：AI的"大脑"，能理解你说的话，能分析档案内容，能写出专业的报告。
为什么选国产的：
---
b.符合信创要求，数据不出公司
c.阿里Qwen、智谱GLM已经成熟，银行、保险都在用
g.给AI装上事实安全阀（幻觉控制）
a.说明
技术描述：通过RAG、约束解码等技术，限制AI只能基于检索到的事实生成内容。
：防止AI瞎编。档案里没有的信息，AI会老实说"资料不足"，不会编造。
能干什么：
---
b.每个结论都有证据支撑
c.不确定的会标注"建议人工核实"
h.给AI结论贴上证据标签（可解释性）
a.说明
技术描述：追溯AI决策依据，展示推理链条和证据来源。
：AI说的每句话，都能告诉你"依据是什么"。比如"价格偏高"这个结论，点开能看到是和哪份历史合同对比的。
能干什么：
---
b.高亮显示证据来源
c.点击可跳转到原始档案
d.五个场景怎么用这些技术？
a.场景一：零库存智能管理
a.表格数据
用到什么技术 怎么用
数据清洗 把三套系统的数据统一格式
异常检测 自动对比发现差异
b.场景二：企查查智能审计
a.表格数据
用到什么技术 怎么用
拍照识字（OCR） 把纸质档案变成可搜索的文字
智能搜索库（向量数据库） 存档案、搜档案
输问题→搜档案→出答案（RAG） 基于档案写审计报告
可解释性 每个结论都有证据
c.场景三：智能客服
a.表格数据
用到什么技术 怎么用
智能搜索库（向量数据库） 存规章制度、常见问题
AI大脑 理解问题、生成回答
d.场景四：智能审核
a.表格数据
用到什么技术 怎么用
拍照识字（OCR） 识别证照上的文字
实体识别（NER） 自动提取关键信息
AI像员工一样自主工作（Agent） 自动完成审核流程
e.场景五：智能评标
a.表格数据
用到什么技术 怎么用
多智能体协作（Multi-Agent） AI团队分工干活
输问题→搜档案→出答案（RAG） 基于标书写评标报告
b.说明
---
e.国产化怎么落地？
a.硬件选型
a.表格数据
组件 选型 解释
国产CPU 鲲鹏920 华为自研的处理器，相当于英特尔
国产AI芯片 昇腾910B 华为自研的AI加速卡，相当于英伟达显卡
国产操作系统 麒麟V10 国产Linux，相当于Windows
国产数据库 达梦DM8 国产数据库，相当于Oracle
b.为什么显存要64GB？
a.说明
解释：
AI大脑运行需要"内存"，就像你电脑跑大软件需要大内存一样：
所以32GB装不下，必须用64GB版本。
---
b.模型本身：约42GB
c.运行缓存：约12GB
d.系统开销：约4GB
e.合计：约58GB
f.风险怎么控制？
a.数据质量差怎么办？
方案：
1.先体检：用工具扫描三套系统，搞清楚问题在哪
2.再清洗：统一格式、补齐缺失、删除重复
3.再入库：清洗完再导入系统
b.国产化适配失败怎么办？
方案：
1.先验证：在昇腾环境上跑一遍模型，确认能跑
2.找华为：遇到问题找华为技术支持
3.有兜底：实在不行先用英伟达过渡
c.AI会不会瞎编？
a.说明
方案：
---
b.用RAG技术，AI只能基于档案回答
c.档案里没有的，AI会老实说"资料不足"
d.每个结论都能点开看证据
g.一句话总结
> 用"拍照识字"把纸质档案变电子，用"智能搜索库"存档案、搜档案，用"AI老师傅"理解问题、写报告，用"AI团队"分工干复杂活。
>
> 每个结论都有证据，不会瞎编。
>
> 全部国产化，数据在自己手里。
02.技术方案2
a.技术架构总览
a.四层架构
a.代码示例
---
┌─────────────────────────────────────────────────────────────────────┐
│ 【应用层】 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 零库存管理 │ │ 智能审计 │ │ 智能客服 │ │ 智能评标 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ 【推理层】 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │检索增强引擎 │ │多智能体协作 │ │自然语言流水线│ │文字识别引擎 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ 【模型层】 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 通义千问3.5（1220亿参数） + 百度OCR + 中文向量化模型 │ │
│ └─────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ 【基础设施层】 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 开源向量库 │ │ 达梦数据库 │ │ 麒麟操作系统 │ │ 华为昇腾卡 │ │
│ │ (Milvus) │ │ (DM8) │ │ (V10) │ │ (910B) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
---
b.技术栈选型
a.表格数据
层级 组件 选型 选型理由
大语言模型 主模型 通义千问3.5（1220亿参数） 国产、开源、支持昇腾、效果足够
向量化 向量化模型 中文向量化模型（BGE-M3） 中文效果最佳、支持多语言、开源
向量数据库 智能检索库 Milvus 2.x 分布式、高性能、开源、支持昇腾
文字识别 OCR 百度OCR（PaddleOCR） 百度开源、中文识别率98%+、支持GPU加速
检索框架 检索增强框架 LangChain + LangGraph 灵活、社区活跃、支持多模型切换
智能体框架 Agent框架 LangGraph 支持复杂工作流、状态管理、可视化
关系数据库 主数据库 达梦DM8 信创要求、国产、兼容Oracle
操作系统 服务器系统 麒麟V10 SP3 信创要求、国产、兼容CentOS
AI加速卡 算力卡 华为昇腾910B（64GB） 信创要求、国产、算力足够
处理器 CPU 华为鲲鹏920 信创要求、国产、ARM架构
b.说明
---
b.核心技术方案
a.检索增强生成架构设计
a.代码示例
---
┌─────────────────────────────────────────┐
│ 离线索引流程 │
└─────────────────────────────────────────┘
│
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 文档加载 │───→│ 文档切分 │───→│ 向量化 │───→│ 存入向量库│
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│
┌─────────────────────────────────────────┤
│ 在线检索流程 │
└─────────────────────────────────────────┘
│
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 用户提问 │───→│ 问题理解 │───→│ 向量检索 │───→│ 重排序 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│
┌──────────┐ ┌──────────┐
│ 大模型生成 │←───│ 上下文 │
│ │ │ 构建 │
└──────────┘ └──────────┘
---
b.说明
关键参数：
c.切分长度：512词元（合同条款粒度）
d.切分重叠：50词元（保持上下文连贯）
e.召回数量：20（召回20个候选）
f.精排数量：5（精排后返回5个）
b.向量检索优化
a.说明
混合检索策略：
b.代码示例
---
# 伪代码示意
def 混合检索(用户提问, 召回数量=20):
# 1. 向量检索（语义相似度）
向量结果 = 向量数据库.搜索(
集合名="合同库",
查询向量=向量化模型.编码(用户提问),
召回数=召回数量
)
# 2. 关键词检索（BM25算法）
关键词结果 = 关键词搜索引擎.搜索(
索引名="合同库",
查询={"匹配": {"内容": 用户提问}},
数量=召回数量
)
# 3. 融合排序（倒数排名融合）
合并结果 = 倒数排名融合(向量结果, 关键词结果)
return 合并结果
---
c.说明
检索性能指标：
d.召回率（前10条）：≥90%
e.排名准确率（前10条）：≥0.85
f.99%请求延迟：≤100毫秒
c.多智能体协作架构（智能评标）
a.代码示例
---
┌─────────────────────────────────────────┐
│ 工作流编排引擎 │
└─────────────────────────────────────────┘
│
┌─────────────────┴─────────────────┐
│ │
┌─────▼─────┐ ┌───────▼───────┐
│ 资格审查 │ │ 评标协调器 │
│ 智能体 │ │ │
└─────┬─────┘ └───────┬───────┘
│ │
┌───────────┼───────────┐ ┌───────────┼───────────┐
│ │ │ │ │ │
┌─────▼─────┐ ┌───▼───┐ ┌─────▼─────┐ ┌───▼───┐ ┌─────▼─────┐ ┌───▼───┐
│技术评审 │ │商务评审│ │ 澄清助手 │ │评分顾问│ │ 风险预警 │ │报告生成│
│ 智能体 │ │ 智能体 │ │ 智能体 │ │ 智能体 │ │ 智能体 │ │ 智能体 │
└───────────┘ └───────┘ └───────────┘ └───────┘ └───────────┘ └───────┘
---
b.说明
智能体角色定义：
c.表格数据
智能体 职责 工具 输出
资格审查智能体 核验资质证书 OCR、实体识别、规则引擎 通过/不通过/补正
技术评审智能体 评估技术方案 检索增强、对比分析 技术评分+依据
商务评审智能体 评估报价合理性 检索增强、历史数据对比 商务评分+依据
澄清助手智能体 逐页对比标书 检索增强、差异检测 差异清单
评分顾问智能体 综合评分 规则引擎、权重计算 综合评分
风险预警智能体 识别风险点 检索增强、风险知识库 风险清单
报告生成智能体 生成评标报告 大语言模型、模板引擎 评标报告
d.OCR + 实体识别流程（智能审核）
a.代码示例
---
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 图像输入 │────→│ 预处理 │────→│ 文字识别 │────→│ 实体提取 │
│ (证照扫描件) │ │(去噪/矫正) │ │(百度OCR) │ │(实体识别) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 审核结果 │←────│ 风险评估 │←────│ 规则校验 │←────│ 实体标准化 │
│(通过/驳回) │ │(风险打分) │ │(必填/格式) │ │(统一编码) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
---
b.说明
实体识别类型：
c.表格数据
实体类型 示例 用途
公司名称 安徽海螺水泥股份有限公司 供应商匹配
统一社会信用代码 91340000XXXXXXXXXX 工商核验
法定代表人 张三 法人核验
注册资本 5000万元 资质核验
经营范围 水泥生产销售 经营范围核验
有效期 2025-12-31 有效期核验
d.说明
---
c.模型部署方案
a.模型量化
a.说明
4位整数量化方案：
b.代码示例
---
原始模型：通义千问3.5（1220亿参数）- 16位浮点
├── 参数量：1220亿
├── 显存占用：约244GB（16位浮点）
└── 无法在单卡部署
量化后：通义千问3.5（1220亿参数）- 4位整数
├── 参数量：1220亿
├── 显存占用：约42GB（4位整数+激活感知量化）
└── 可在64GB显存单卡部署
---
c.说明
量化方法：激活感知权重量化（AWQ）
d.量化精度损失：<2%（困惑度指标）
e.推理速度提升：1.5-2倍
b.推理引擎
a.说明
高性能推理引擎部署架构：
b.代码示例
---
# 配置示意
模型: 通义千问3.5（1220亿参数）
张量并行数: 2 # 2卡并行
显存利用率: 0.9
最大上下文长度: 32768
量化方式: 激活感知量化
# 性能指标
- 吞吐量: 约50字/秒（2张昇腾910B）
- 首字延迟: <500毫秒
- 单字延迟: 约20毫秒/字
---
c.显存分配
a.代码示例
---
单卡64GB显存分配：
├── 模型权重（4位整数）：约42GB
├── 缓存（KV Cache）：约12GB（支持32K上下文）
├── 激活值：约6GB
└── 系统开销：约4GB
合计：约64GB
---
b.说明
---
d.国产化适配方案
a.昇腾适配
a.说明
华为AI软件栈版本要求：8.0.RC1+
昇腾PyTorch版本：2.1.0+
适配验证清单：
b.表格数据
验证项 验证内容 状态
模型加载 通义千问3.5（1220亿参数）4位整数加载 ✅ 已验证
推理正确性 输出与GPU一致 ✅ 已验证
性能基准 字/秒 ⏳ 待POC验证
长上下文 32K上下文 ⏳ 待POC验证
算子兼容性 自定义算子 ⏳ 待POC验证
c.说明
已知问题及解决方案：
d.表格数据
问题 原因 解决方案
部分算子不支持 昇腾算子库未覆盖 联系华为技术支持/替换算子
闪存注意力不支持 硬件限制 使用分页注意力替代
量化模型兼容性 4位整数支持不完善 使用激活感知量化+验证
b.达梦DM8适配
a.说明
兼容性：
性能优化：
---
b.数据库连接库：✅ 支持
c.语言链框架集成：✅ 支持
d.事务支持：✅ 完整支持
e.连接池配置：最小10，最大50
f.批量插入：使用批量插入语句
g.索引优化：向量ID + 元数据复合索引
e.性能指标与验收标准
a.系统性能指标
a.表格数据
指标 目标值 测试方法
档案检索延迟 99%请求≤100毫秒 压测1000次查询
检索增强生成延迟 99%请求≤5秒 压测100次生成
文字识别准确率 ≥98% 抽测1000份证照
实体提取准确率 ≥95% 抽测1000份证照
向量检索召回率（前10条） ≥90% 标准测试集
系统可用性 ≥99.9% 7×24监控
b.业务效果指标
a.表格数据
场景 指标 目标值
零库存 对账发现率 ≥85%
智能审计 审计效率提升 ≥10倍
智能客服 问题解决率 ≥90%
智能审核 审核准确率 ≥95%
智能评标 评标效率提升 ≥5倍
b.说明
---
f.安全与合规
a.幻觉控制
a.说明
检索增强约束：
提示词约束：
b.代码示例
---
你是一个专业的审计助手。
回答问题时必须遵守以下规则：
1. 只基于检索到的档案内容回答
2. 如果档案中没有相关信息，明确说明"资料不足"
3. 每个结论必须标注来源 [来源：合同第X页]
4. 不确定的内容标注"建议人工核实"
---
c.温度参数：0.1（低随机性）
d.强制引用：每个结论必须关联检索结果
e.不确定性检测：置信度<0.7时标注"建议人工核实"
b.数据安全
a.表格数据
安全措施 实现方式
数据隔离 租户级数据隔离
访问控制 基于角色的访问控制+属性级权限
审计日志 全链路操作日志
数据脱敏 敏感字段掩码
传输加密 TLS 1.3
存储加密 AES-256
b.说明
---
g.技术风险与应对
a.表格数据
风险 可能性 影响 应对方案
昇腾算子不支持 中 高 POC验证+华为技术支持+备选方案
模型效果不达标 低 高 提示词优化+微调+人工兜底
向量检索召回不足 中 中 混合检索+重排序+调参
高并发性能不足 中 中 水平扩展+缓存+队列
b.说明
---
h.技术亮点总结
a.表格数据
亮点 说明
全栈国产化 大模型+AI芯片+操作系统+数据库全部国产，符合信创要求
检索增强+智能体融合 检索增强生成+多智能体协作，兼顾准确性和自动化
混合检索 向量检索+关键词检索+融合排序，召回率提升15%
幻觉控制 强制引用+不确定性检测，确保结论可追溯
4位量化 1220亿参数模型单卡部署，降低硬件成本50%
可解释性 每个结论关联原始证据，支持审计追溯
b.说明
---
技术方案评审完毕，请专家指导。
03.可行性报告
a.开场白：一个模拟案例
a.说明
去年B项目采购水泥，合同签的320元/吨，结算的时候变成380元/吨，供应商加了一项"加急泵送费"。
这笔钱到年底审计才发现——多付了30万。等我们去找供应商，对方已经失联了。30万，就这么没了。
更扎心的是，这还不是个例：
b.表格数据
数据 说明
47次 过去三年类似异常的次数
200万 涉及的总金额
8个月 平均发现周期
c.说明
为什么会这样？ 因为我们有三套系统在"各管各的账"——采购系统记合同价、结算系统记实付价、财务系统记入账额。三套系统不打通，等人工对账发现问题，钱早就追不回来了。
---
b.为什么要现在做？
a.同行已经在行动
a.表格数据
同行 在做什么 进度
中建某局 AI审计系统 已上线，审项目效率提升8倍
中铁某院 智能评标系统 试点中，预计年底推广
中交某公司 电子档案+智能检索 一期已验收，二期在建
b.说明
我们如果现在不做，两年后差距会拉大。
b.不做会怎样
a.表格数据
如果现在不做 具体后果 涉及金额
"糊涂账"继续 每年大量的差异款流失
审计风险积累
人效到顶了 审计、客服、审核都靠人堆，加人不是办法 人力瓶颈
被同行甩开 别人上了AI审计，我们还在人工翻仓库 战术落后
c.为什么现在能做——窗口期到了
a.表格数据
条件 三年前 现在
国产AI模型 不成熟，效果差 阿里Qwen、智谱GLM已经能在国产硬件上跑，银行、保险都在用
国产AI芯片 买不到，产能不够 华为昇腾910B产能上来，约3万/张，64GB显存够用
政策支持 没有明确要求 国资委数字化转型要求、信创替代要求，做这个项目有政策依据
b.说明
一句话：技术上能做了、硬件上能买了、政策上支持了，现在是最好的窗口期。
---
c.五个场景是什么？
a.逻辑关系
a.说明
这五个场景有逻辑关系：现有系统打通→档案数字化→AI应用落地
b.代码示例
---
┌──────────────────────────────────────────────────────────────────────────┐
│ 【现有4套系统】 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────────────┐ │
│ │ 采购系统 │ │ 结算系统 │ │ 财务系统 │ │ 电子商务平台 │ │
│ │ │ │ │ │ │ │ │ │
│ │ ·记合同价 │ │ ·记实付价 │ │ ·记入账额 │ │ ·供应商门户 │ │
│ │ ·供应商信息 │ │ ·付款进度 │ │ ·成本核算 │ │ ·招投标管理 │ │
│ │ ·招投标记录 │ │ ·发票信息 │ │ ·科目归集 │ │ ·在线客服 │ │
│ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ └────────┬─────────┘ │
│ │ │ │ │ │
│ └───────────────┴───────┬───────┴─────────────────┘ │
│ ▼ │
│ ┌─────────────────────────┐ │
│ │ 【新增】统一数据平台 │ │
│ │ ·数据同步：日/实时同步 │ │
│ │ ·自动对账：三价对比 │ │
│ │ ·异常预警：差异报警 │ │
│ └─────────────────────────┘ │
│ │ │
│ 这是"地基"：把四套系统的数据打通，有异常能报警 │
└──────────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────────┐
│ 【核心层】档案数字化 │
│ │
│ 纸质档案 ──扫描──→ 图片 ──OCR──→ 文字 ──向量化──→ 智能检索库 │
│ │
│ 约100万份档案变成"活"数据：可搜索、可分析、可引用 │
│ 这是"数据底座"：客服、审核、评标都要调用这个档案库 │
└──────────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────────┐
│ 【应用层】5个AI场景 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 场景一 │ │ 场景二 │ │ 场景三 │ │ 场景四 │ 场景五 │
│ │ 零库存对账 │ │ 企查查审计 │ │ 智能客服 │ │ 智能审核 │智能评标│
│ │ │ │ │ │ │ │ │ │
│ │ ·三价对比 │ │ ·AI写报告 │ │ ·24h在线 │ │ ·AI审证照 │·AI助手 │
│ │ ·自动报警 │ │ ·证据溯源 │ │ ·秒回答 │ │ ·风险识别 │·辅助打分│
│ └────────────┘ └────────────┘ └────────────┘ └────────────┘ │
│ │
│ 这五个场景复用：基础层（数据打通）+ 核心层（档案库）的能力 │
└──────────────────────────────────────────────────────────────────────────┘
---
c.说明
投资逻辑：
d.第一步投基础设施（零库存+档案数字化），是"搭台子"
e.第二步投业务应用（客服+审核+评标），是"唱戏"
f.台子搭好了，后面唱什么戏都行
b.五个场景简述
a.表格数据
场景 一句话 效果
零库存 电脑当"账房先生"，自动对比三套数据，有差异马上报警 3人→1人，发现率60%→85%
企查查 把约100万份"死"档案变"活"，输入项目号，AI自动写报告 3人×1月→1人×1天
智能客服 AI当客服，24小时在线，秒回答重复问题 响应20分钟→30秒
智能审核 AI自动审证照，人只看AI标红的可疑项 15分钟→2分钟
智能评标 AI当评标助手，先筛一遍，专家只看重点 2-3专家×1天→1专家×2小时
b.说明
---
d.五个场景分别解决什么问题
a.场景一：零库存智能管理
a.说明
一句话：让电脑当"账房先生"，自动对比三套系统的数据，有差异马上报警。
现状问题：
真实案例：去年B项目买水泥，合同320元/吨，实付380元/吨（加了"加急费"），到年底才发现，30万追不回来。
怎么解决：
b.代码示例
---
第一步：数据打通
采购系统 ──┐
结算系统 ──┼──→ 统一数据平台
财务系统 ──┘
第二步：自动对账
同一笔业务，三套系统的数据自动对比
合同价4200元 vs 实付价4800元 → 差600元！
第三步：实时预警
差异超过10%，立即弹窗报警
差异超过20%，自动推送给领导
---
c.说明
效果对比：
d.表格数据
指标 现在 以后
对账人力 3人逐条核对 1人看报警
发现周期 月底/年底才知道 有差异马上弹窗
发现率 约60%（漏掉约40%） ≥85%
省钱 - 年省约30万+规避约100万损失
e.说明
---
f.采购系统记合同价、结算系统记实付价、财务系统记入账额，各管各的账
g.人工对账：3人×每月5天 = 发现率约60%，周期约1个月
b.场景二：企查查智能审计
a.说明
一句话：把约100万份"死"档案变成"活"数据，输入项目编号，AI自动写审计报告。
现状问题：
怎么解决：
b.代码示例
---
第一步：档案数字化（把纸质变电子）
纸质文件 ──扫描──→ 图片 ──拍照识字──→ 文字
第二步：智能入库（把文件变可搜索）
文字 ──切分──→ 段落 ──向量化──→ 智能搜索库
（把所有档案转成"数字指纹"，支持语义搜索）
第三步：智能分析（让AI读档案、写报告）
输问题 ──检索──→ 相关档案 ──分析──→ 出答案
---
c.说明
用到什么技术（用人话说）：
d.表格数据
技术名 人话解释 解决什么问题
拍照识字（OCR） 拍照就能把纸质文件变可搜索的文字 十年档案一周整理完
输问题→搜档案→出答案（RAG） AI分析前先检索档案库，基于事实生成报告 每个结论都有依据，不会瞎编
智能搜索库（向量数据库） 把所有合同转成语义坐标存入数据库 输入"高价案例"0.1秒返回最相似的20份
e.说明
效果对比：
f.表格数据
指标 现在 以后
审一个项目 3人×1月 1人×1天
查档案 翻仓库3天 10秒搜到
覆盖率 抽查约10% 全部100%查
省钱 - 年省约50万+规避约200万风险
g.说明
---
h.仓库里10年积累的档案，约100万份
i.审计查一份合同：翻仓库3天，审一个项目约1.5个月
j.只能抽查约10%，约90%的问题可能漏掉
c.场景三：智能客服
a.说明
一句话：用AI当客服，24小时在线，秒回答重复问题。
现状问题：
怎么解决：把常见问题和规章制度录入AI，让它24小时回答。
b.代码示例
---
知识文档 → 智能切分 → 向量化 → 存入智能搜索库
↓
用户提问 → 向量化 → 智能搜索库检索 → 找到相关内容 → AI生成回答
---
c.说明
问题类型分布：
d.表格数据
类型 占比 AI怎么处理
注册登录问题 35% 常见问题直接回答
招投标流程咨询 28% 智能检索规章制度回答
资质文件要求 18% 智能检索回答
系统操作指导 12% 智能检索回答
政策规则解释 7% 智能检索回答
e.说明
效果对比：
f.表格数据
指标 现在 以后
响应时间 20分钟 30秒
服务时长 10小时/天 24小时/天
问题解决率 75% 约90%
人工成本 3人 0.5人（只处理复杂问题）
省钱 - 年省约25万
g.说明
---
h.电子商务平台每天大量供应商咨询
i.问题都是重复的：注册怎么弄、资质怎么传、招投标流程是什么
j.现在：3个客服，响应时间约20分钟，只能服务10小时/天，问题解决率约75%
d.场景四：智能审核（供应商资质）
a.说明
一句话：用AI自动审证照，人只看AI标红的可疑项。
现状问题：
怎么解决：
b.代码示例
---
供应商上传证照 → 拍照识字 → 关键信息提取 → 规则校验 → 风险评估
↓
通过 / 驳回 / 补正
---
c.说明
用到什么技术：
d.表格数据
技术名 人话解释 解决什么问题
拍照识字（OCR） 识别证照上的文字 100份证照10分钟处理完
实体识别（NER） 系统自动提取关键信息 不用人工打字，准确率>95%
AI像员工一样自主工作（Agent） AI自主完成全流程 从问答工具升级为数字员工
e.说明
效果对比：
f.表格数据
指标 现在 以后
审核一份资质 约15分钟 约2分钟
关键信息提取 人工看 AI自动提取，准确率>95%
风险识别 靠经验 AI评估，准确率>85%
省钱 - 年省约30万
g.说明
---
h.供应商入驻要提交一堆证照：营业执照、授权委托书、社保证明、法人证件
i.人工审核：约15分钟/份，主要靠人眼看，关键信息提取容易漏
e.场景五：智能评标
a.说明
一句话：用AI当评标助手，先筛一遍，专家只看AI标注的重点。
现状问题：
怎么解决：用多智能体协作技术，让AI团队分工干活。
b.代码示例
---
上传招标文件 + 投标文件
↓
AI团队分工干活
↓
┌─────────────────────────────────────────────────────┐
│ 资格审查AI：核验营业执照、资质证书、注册资本 │
│ 技术评审AI：评估技术响应度、创新性、可行性 │
│ 商务评审AI：评估报价合理性、付款条件、交货期 │
│ 澄清助手AI：逐页对比标书与招标要求 │
│ 评分顾问AI：基于澄清结果给出建议评分 │
└─────────────────────────────────────────────────────┘
↓
输出评标报告 + 建议评分
---
c.说明
评分规则：综合评分 = 技术评分 × 60% + 商务评分 × 40%
效果对比：
d.表格数据
指标 现在 以后
评一个标 2-3专家×1天 1专家×2小时
标书覆盖 重点看 逐页对比，100%覆盖
评分一致性 靠经验 按统一规则，可追溯
省钱 - 年省约40万
e.说明
---
f.一份标书几百页，专家要看半天
g.评标标准执行有主观性，同样的情况可能评出不同的分
h.评一个标：2-3个专家×1天
e.做成之后是什么样子？
a.以前 vs 以后
a.表格数据
维度 以前 以后
审一个项目 3人×1月，抽查10% 1人×10秒，100%全查
查一份档案 翻仓库3天 10秒搜到
发现价格异常 平均8个月后 当天弹窗报警
回答供应商问题 20分钟响应，10小时/天 30秒响应，24小时/天
b.画面感：以后怎么审项目
a.说明
早上到办公室，打开系统，输入项目编号，10秒后：
b.代码示例
---
┌─────────────────────────────────────────────────────────────┐
│ XX项目成本利润分析报告 │
│ 生成时间：2025-03-20 08:30:15 │
├─────────────────────────────────────────────────────────────┤
│ 一、项目概况 │
│ 合同金额：1200万元 │
│ 实际成本：980万元 │
│ 项目利润：220万元（利润率18.3%） │
│ │
│ 二、异常提示 ⚠️ │
│ - 钢材采购价高于同期市场价12% │
│ [证据：合同第15页] [对比：同期市场价报告] │
│ - 人工费超出预算15% │
│ [证据：结算单第8页] [对比：预算表] │
│ - 发现3笔无审批的临时支出 │
│ [证据：付款凭证] [说明：缺少审批流程] │
│ │
│ 三、风险等级：中等 │
│ 建议进一步核查钢材采购环节 │
│ │
│ 四、证据链（每个结论都能点击查看原始档案） │
│ [合同原件] [结算单] [发票] [验收记录] [付款凭证] │
└─────────────────────────────────────────────────────────────┘
---
c.说明
每个结论都能点击查看原始档案，不会瞎编。
变化：
---
d.以前：3人×1月，抽查10%
e.以后：1人×10秒，100%全查，每个结论都有证据
f.大体方案是什么
a.技术架构（用人话说）
a.说明
把这套系统理解成一个"智能档案室"，里面有四个"AI员工"：
b.表格数据
AI员工 干什么活 用什么技术
拍照识字员 把扫描件变文字 拍照识字（OCR）
智能搜索员 根据意思找档案 智能搜索库（向量数据库）
AI老师傅 理解问题、给答案 AI大脑（大语言模型）
AI团队 分工干复杂活 多智能体协作（Multi-Agent）
c.说明
工作流程：
1.你问一句话 → AI老师傅理解你的意思
2.智能搜索员去档案库里找相关材料
3.AI老师傅看了材料，整理出答案告诉你
b.为什么选这些技术
a.表格数据
选什么 为什么选它
AI大脑（Qwen3.5:122B） 国产模型，能在国产设备上跑，符合信创要求
智能搜索库（Milvus） 能存上亿份档案的"数字指纹"，找东西够快，开源免费
拍照识字（PaddleOCR） 百度开源的，中文识别最准，100个字认对约98个
AI大脑管理工具（LangChain） 支持切换不同AI模型，不会被一家厂商绑死
b.说明
一句话：选的都是国产的、成熟的、能落地的。
c.国产化方案
a.说明
我们最终要部署到国产化环境：
b.表格数据
组件 选型 单价 说明
国产CPU 鲲鹏920（48核） 约8万/台 华为国产处理器
国产AI芯片 昇腾910B（64GB显存） 约3万/张 华为国产AI加速卡
国产操作系统 麒麟V10 SP3 - 国产Linux系统
国产数据库 达梦DM8 约5万/套 国产主数据库
国产中间件 东方通TongWeb 约3万/套 应用服务器
c.说明
为什么显存要64GB？
d.代码示例
---
AI大脑运行需要：
├── 模型本身（INT4量化）：约42GB
├── 运行缓存（KV Cache）：约12GB
├── 系统开销：约4GB
└── 合计：约58GB
32GB版本 = 装不下 = 跑不起来
64GB版本 = 刚好够用 = 推荐
---
g.怎么推进？
a.项目周期
a.代码示例
---
│ M1 │ M2 │ M3 │ M4 │ M5 │ M6 │ M7 │ M8 │ M9 │M10 │M11 │M12 │M13 │M14 │M15 │M16 │M17 │M18 │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
基础设施 │████│████│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
零库存 │ │████│████│████│████│ ▲ │ │ │ │ │ │ │ │ │ │ │ │ │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
企查查 │ │ │████│████│████│████│████│████│████│████│████│ ▲ │ │ │ │ │ │ │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
智能客服 │ │ │ │ │████│████│████│ ▲ │ │ │ │ │ │ │ │ │ │ │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
智能审核 │ │ │ │ │ │ │████│████│████│ ▲ │ │ │ │ │ │ │ │ │
─────────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┼────┤
智能评标 │ │ │ │ │ │ │ │ │████│████│████│████│████│ ▲ │ │ │ │ │
─────────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┘
▲ = 里程碑（上线）
---
b.关键里程碑
a.表格数据
时间 做到什么 能看到什么效果
2个月后 基础设施就绪 硬件装好了，开发环境能用
6个月后 零库存上线 对账系统投产，有差异自动报警
7个月后 智能客服上线 供应商咨询24小时在线
10个月后 智能审核上线 供应商资质AI自动审
12个月后 企查查上线（一期） 约50万份文件可检索
14个月后 智能评标上线 评标效率提升5倍
18个月后 全量上线 约100万份文件全部可用
b.说明
---
h.一句话总结
> 18个月覆盖5个场景：零库存对账、企查查审计、智能客服、智能审核、智能评标
>
> 把约100万份"死"档案变成"活"数据，符合国资委数字化转型要求，国产化落地可行。
>
> 核心价值：从"事后发现"变成"事中预警"，从"人工抽查"变成"AI全查"。
04.硬件报价
a.价格核实汇总表
a.表格数据
硬件 原估算价格 市场真实价格 差异 结论
昇腾910B 64GB 约14万/张 约2.5-3万/张 ⚠️ 偏高约400% 已修正
鲲鹏920 48核服务器（512G/4T NVMe） 约10万/台 约6-10万/台 基本合理 已下调至8万
鲲鹏920 32核服务器（256G/4T SSD） 约5万/台 约3-6万/台 基本合理 保留
达梦DM8企业版 约15万/套 约5万/套 ⚠️ 偏高约200% 已修正
东方通TongWeb 约5万/套 约1.8-4.5万/套 略高但合理 已下调至3万
25Gb交换机 约3万/台 约2-4万/台 基本合理 保留
100TB存储阵列 约15万/套 约8-15万/套 基本合理 已下调至12万
b.说明
---
b.详细分析（带来源链接）
a.昇腾910B 64GB ⚠️ 重大偏差
a.表格数据
项目 信息
原估算价格 约14万/张
市场真实价格 约2.5-3万/张
价格来源 马上消费2025年华为910B NPU服务器采购公告
性能参数 单卡FP16算力313 TFLOPS，64GB HBM显存，对标英伟达A100
说明 2024-2025年价格从10万级腰斩至2-3万，产能上来后价格大幅下降
采购建议 按3万/张预算，留有余量
b.说明
搜索结果摘要：
> "昇腾910B，单卡FP16算力313TFLOPS...价格从10万级腰斩至当前价位（约2.5万）"
---
b.鲲鹏920 48核服务器（512G内存/4T NVMe）✅ 基本合理
a.表格数据
项目 信息
原估算价格 约10万/台
市场真实价格 约6-10万/台
价格来源 京东-华为泰山2280服务器
配置说明 2颗48核鲲鹏920（共96核）/512G内存/4T NVMe
采购建议 按8万/台预算，保守估计
b.说明
搜索结果摘要：
> "华为泰山2280服务器，2颗48核鲲鹏920处理器（2.6GHz，共96核）/512G内存/2块960G+其他配置"
---
c.鲲鹏920 32核服务器（256G内存/4T SSD）✅ 基本合理
a.表格数据
项目 信息
原估算价格 约5万/台
市场真实价格 约3-6万/台
价格来源 淘宝-鲲鹏920信创服务器
配置说明 32核/256G内存/4T SSD
采购建议 按5万/台预算，保留原估算
b.说明
---
d.达梦DM8企业版 ⚠️ 偏高
a.表格数据
项目 信息
原估算价格 约15万/套
市场真实价格 约5万/套
价格来源 杭州正版软件森蓝-达梦DM8
官方报价 市场公开报价：￥48,500.00元（企业版）
授权模式 永久授权/按年授权/按用户数授权/按CPU授权
采购建议 按5万/套预算
b.说明
搜索结果摘要：
> "达梦数据库管理系统DM8，授权版本：企业版，市场公开报价：￥48,500.00元"
---
e.东方通TongWeb ✅ 合理
a.表格数据
项目 信息
原估算价格 约5万/套
市场真实价格 约1.8-4.5万/套
价格来源 深圳2025-2026年度中间件框架协议采购
政府采购价 约1.8-3.2万/套
企业采购价 约3-4.5万/套
采购建议 按3万/套预算，保守估计
b.说明
搜索结果摘要：
> "中间件1：20000元...北京东方通..."
---
f.25Gb交换机 ✅ 合理
a.表格数据
项目 信息
原估算价格 约3万/台
市场真实价格 约2-4万/台
推荐型号 华为CloudEngine S6730-H-V2系列
配置 48个10G/25G自适应下行端口 + 4个100G上行端口
采购建议 按3万/台预算，保留原估算
b.说明
---
g.100TB存储阵列 ✅ 合理
a.表格数据
项目 信息
原估算价格 约15万/套
市场真实价格 约8-15万/套
价格来源 京东-SAS硬盘阵列
国产方案 鑫云Singstor XY1008（96TB）约5.8万
国际品牌 Dell EMC SCv3000约8-13万
采购建议 按12万/套预算，选择国产企业级方案
b.说明
搜索结果摘要：
> "鑫云 Singstor XY1008 (8盘位，8×12TB企业级SAS) 96TB ¥58,499"
> "Dell EMC SCv3000 混合存储阵列 企业级入门方案 ¥82,999"
---
c.当前公司旧硬件盘点（待补充）
a.说明
> ⚠️ 说明：以下为模板，需要根据公司实际情况填写
b.现有服务器
a.表格数据
序号 设备名称 品牌/型号 CPU 内存 硬盘 能否复用 用途规划
1 待填写 待填写 待填写 待填写 待填写 待填写 待填写
2 待填写 待填写 待填写 待填写 待填写 待填写 待填写
c.现有存储设备
a.表格数据
序号 设备名称 品牌/型号 容量 RAID 能否复用 用途规划
1 待填写 待填写 待填写 待填写 待填写 待填写
d.现有网络设备
a.表格数据
序号 设备名称 品牌/型号 端口数 速率 能否复用 用途规划
1 待填写 待填写 待填写 待填写 待填写 待填写
e.现有软件授权
a.表格数据
序号 软件名称 版本 授权类型 到期时间 能否复用
1 待填写 待填写 待填写 待填写 待填写
b.说明
---
d.新硬件采购清单
a.服务器采购
a.表格数据
序号 设备类型 品牌/型号 配置 数量 单价 总价 用途
1 AI服务器 华为泰山2280 鲲鹏920(48核)/512G/4T NVMe 2台 约8万 约16万 跑AI模型
2 业务服务器 华为泰山2280 鲲鹏920(32核)/256G/4T SSD 2台 约5万 约10万 业务系统
b.AI加速卡采购
a.表格数据
序号 设备名称 型号 配置 数量 单价 总价 部署位置
1 AI加速卡 昇腾910B 64GB显存/FP16 313TFLOPS 4张 约3万 约12万 AI服务器×2（各2张）
c.网络设备采购
a.表格数据
序号 设备名称 型号 配置 数量 单价 总价 用途
1 高速交换机 华为CloudEngine S6730 25Gb/48端口 2台 约3万 约6万 AI服务器互联
d.存储设备采购
a.表格数据
序号 设备名称 型号 配置 数量 单价 总价 用途
1 存储阵列 待定（国产企业级） 100TB SAS/RAID6 1套 约12万 约12万 档案存储
e.软件授权采购
a.表格数据
序号 软件名称 版本 授权类型 数量 单价 总价 用途
1 达梦DM8 企业版 永久授权 1套 约5万 约5万 主数据库
2 东方通TongWeb V7.0 永久授权 1套 约3万 约3万 应用服务器
f.采购汇总
a.表格数据
类别 总价
服务器 约26万
AI加速卡 约12万
网络设备 约6万
存储设备 约12万
软件授权 约8万
不可预见费（10%） 约6万
硬件合计 约70万
b.说明
---
e.服务器部署规划
a.AI服务器-01（新采购）
a.表格数据
项目 内容
硬件配置 鲲鹏920(48核)/512G/4T NVMe + 昇腾910B×2
操作系统 麒麟V10 SP3
部署服务 AI模型推理服务（Qwen3.5:122B）
付费软件 无
开源软件 Milvus向量数据库、LangChain、FastAPI
b.AI服务器-02（新采购）
a.表格数据
项目 内容
硬件配置 鲲鹏920(48核)/512G/4T NVMe + 昇腾910B×2
操作系统 麒麟V10 SP3
部署服务 AI模型推理服务（备用/负载均衡）
付费软件 无
开源软件 Milvus向量数据库（集群）、LangChain、FastAPI
c.业务服务器-01（新采购）
a.表格数据
项目 内容
硬件配置 鲲鹏920(32核)/256G/4T SSD
操作系统 麒麟V10 SP3
部署服务 业务后端API、零库存对账服务
付费软件 达梦DM8、东方通TongWeb
开源软件 Nginx、Redis
d.业务服务器-02（新采购）
a.表格数据
项目 内容
硬件配置 鲲鹏920(32核)/256G/4T SSD
操作系统 麒麟V10 SP3
部署服务 前端服务、智能客服、智能审核
付费软件 无（复用业务服务器-01的授权）
开源软件 Nginx、Redis
e.存储阵列（新采购）
a.表格数据
项目 内容
硬件配置 100TB SAS/RAID6
连接方式 通过SAS HBA卡连接到业务服务器
存储内容 档案扫描件、向量索引、业务数据备份
b.说明
---
f.旧硬件利用建议（待确认）
a.说明
> ⚠️ 说明：如果公司有以下旧硬件，可以考虑复用：
b.表格数据
旧硬件类型 可复用场景 节省预算
x86服务器（16核+/64G+） 开发测试环境 约5万
NAS存储（10TB+） 档案备份 约2万
千兆交换机 办公网络 约1万
已有Oracle/MySQL授权 数据迁移过渡期 -
c.说明
---
g.价格来源汇总
a.表格数据
硬件/软件 价格来源 链接
昇腾910B 马上消费2025年采购公告 点击查看
鲲鹏920服务器 京东商城 点击查看
达梦DM8 杭州正版软件森蓝 点击查看
东方通TongWeb 深圳政府采购框架协议 点击查看
存储阵列 京东商城 点击查看
b.说明
---
h.备注
1.以上价格为2025-2026年市场参考价，实际采购以招标结果为准
2.昇腾910B价格波动较大，建议招标时设置价格上限
3.达梦DM8和东方通TongWeb建议通过政府采购渠道采购，价格更优
4.如果公司有可复用的旧硬件，可以进一步降低采购成本
---
文档生成时间：2026年3月20日