AI 理赔系统 - AIHub 2022

项目介绍

AI 理赔系统是一个基于 FastAPI 的智能保险理赔处理平台。用户提交理赔申请及辅助材料（发票、病历等），系统通过 AI（OpenAI/Ark API）完成 OCR 文字识别、发票结构化提取、理疗政策校验、补偿金额计算，最终输出理赔决策。

核心功能

理赔申请管理：用户创建理赔、上传附件、查看理赔状态
AI OCR 识别：双模型交叉验证，识别发票及病历中的文字信息
发票信息提取：从 OCR 结果中自动提取发票号、金额、项目明细、分类（甲/乙/丙类）
政策校验：基于浙江医保目录等规则判断项目是否在保障范围内
补偿计算：根据分类扣除、起付线、赔付比例、日额津贴等规则计算最终可赔付金额
OCR 审核：双模型结果不一致时进入人工审核，由用户选择正确结果
后台任务：独立 Job 服务处理耗时任务（OCR、分析、计算），Web 服务通过 HTTP 调用触发
管理后台：用户管理、理赔统计、AI 模型配置、AI 日志查看

用户流程

用户注册登录（需邀请码）
创建理赔申请（每日限额 10 个）
上传发票、病历等附件材料
提交处理，系统进入 OCR → 解析 → 政策校验 → 补偿计算流程
若双模型 OCR 结果不一致，进入人工审核
理赔完成，查看最终补偿金额

技术架构

框架：FastAPI + Uvicorn
数据库：MySQL + SQLAlchemy + Alembic
AI：OpenAI Python SDK（支持双模型交叉验证）
认证：bcrypt 密码 + HttpOnly Session Cookie
文件存储：本地文件系统，按 upload/YYYY/MM/DD/<claim_id>/ 目录结构存储
模板：Jinja2
测试：pytest + fastapi.testclient.TestClient

技术框架文档

技术栈

组件	技术
Web 框架	FastAPI + Uvicorn
数据库	MySQL + SQLAlchemy + Alembic
数据库连接池	DBUtils（PooledDB）+ PyMySQL
AI 客户端	OpenAI Python SDK
认证	bcrypt + 本地 Session Cookie
模板引擎	Jinja2
文档解析	pdfplumber、xlrd
测试	pytest + pytest-asyncio
HTTP 客户端	httpx
命令行	Typer

项目结构

insurance/
├── main.py               # FastAPI app factory（bootstrap + web_app + job_app）
├── web.py                # Web 服务入口（port 8000）
├── job.py                # Job 后台服务入口（port 9000）
├── requirements.txt      # Python 依赖
├── alembic.ini           # Alembic 配置
├── .env.dev / .env.prod  # 环境配置
├── app/
│   ├── config.py         # 环境配置加载器
│   ├── db.py             # 数据库连接池
│   ├── db_schema.py      # SQLAlchemy 表定义（9 张表）
│   ├── models.py         # Pydantic 模型 + 枚举
│   ├── ai_client.py      # OpenAI/Ark API 封装
│   ├── claim_service.py  # 理赔核心流程编排
│   ├── claim_ai.py       # AI 处理流水线（OCR、发票提取、分析）
│   ├── claim_parsers.py  # AI 响应解析与校验
│   ├── claim_policy.py   # 政策性判断逻辑
│   ├── claim_compensation.py  # 补偿金额计算
│   ├── claim_upload.py   # 文件上传处理
│   ├── job_client.py     # HTTP 调用 Job 服务的客户端
│   ├── job_repository.py # Job 任务持久化
│   ├── worker.py         # Job 后台任务处理
│   ├── legacy_worker.py  # 旧版数据库队列 worker
│   ├── model_repository.py  # AI 模型配置 CRUD
│   ├── storage.py        # 本地文件存储抽象
│   ├── auth/             # 认证模块
│   └── routes/           # API 和页面路由
├── migrations/           # Alembic 迁移脚本
├── templates/            # Jinja2 HTML 模板
├── scripts/              # 构建脚本（目录种子数据）
├── tests/                # pytest 测试用例
└── upload/               # 文件存储（YYYY/MM/DD/<claim_id>/）

数据库架构

共 9 张表，无外键约束（使用逻辑外键），所有表均包含 id（BIGINT AUTO_INCREMENT）、created_at、updated_at 字段。

表名	说明
`users`	用户表（用户名、密码哈希、邮箱、是否管理员）
`user_sessions`	Session 表（Token、用户 ID、过期时间）
`claims`	理赔申请主表（用户、产品类型、状态、金额、日期、AI 费用）
`attachments`	附件表（关联 claim、文件路径、OCR 文本、发票 JSON）
`job_tasks`	后台任务表（分布式锁实现、lease 机制）
`invoice` / `invoice_item`	发票主表/明细表（发票号、金额、项目、分类）
`ai_logs`	AI 调用日志（Token 消耗、费用、响应时间）
`zj_medical_service_items_xls`	浙江医疗服务目录（政策校验用）
`invitation_codes`	邀请码表
`models`	AI 模型配置表（Provider、API Key、定价）

双服务架构

服务	入口	端口	职责
Web 服务	`web.py`	8000	用户界面、API、管理后台
Job 服务	`job.py`	9000	OCR、发票解析、政策校验、补偿计算

两个服务共享同一套代码和数据库，Web 服务通过 HTTP 调用 Job 服务触发后台处理。

核心处理流程

📋

提交申请

创建理赔上传材料

→

🔍

AI OCR

双模型交叉验证

→

🧾

发票提取

结构化数据提取

→

✅

政策校验

医保目录规则匹配

→

💰

补偿计算

分类扣除比例计算

→

🎉

完成理赔

输出补偿金额

若双模型 OCR 结果不一致 → status=pending_review（人工审核）
若一致 → status=completed，返回最终补偿金额

配置管理

所有配置通过 .env.dev / .env.prod 加载：

数据库连接（DB_HOST、DB_PORT、DB_USER、DB_PASS、DB_NAME）
服务端口（WEB_PORT、JOB_PORT）
AI API（OPENAI_API_KEY、OPENAI_BASE_URL、OPENAI_MODEL）
Job 任务参数（重试次数、锁超时、续约时间）
文件存储（STORAGE_TYPE、UPLOAD_DIR）

项目雏形简述

起源

本项目源于一个实际需求：传统保险理赔流程依赖人工审核发票、病历等材料，效率低且容易出错。期望利用 AI（OpenAI/Ark）实现理赔材料的自动识别、解析与补偿计算，减少人工介入，提升理赔速度。

实现思路

用户通过 Web 界面上传理赔材料（发票、病历等）
系统调用 Vision API 对图片进行 OCR 识别，使用双模型交叉验证提高准确性
从 OCR 结果中提取发票关键信息（发票号、金额、项目明细、分类）
基于浙江医保目录规则判断项目是否在保障范围内
根据分类扣除、起付线、赔付比例等规则计算最终可赔付金额
若双模型结果不一致，进入人工审核流程

当前状态

项目已完成核心功能开发，包括：

理赔申请管理（创建、上传附件、状态流转）
AI OCR 识别流水线（双模型验证）
发票信息提取与结构化
政策性判断与补偿计算
OCR 人工审核界面
管理后台（用户、统计、模型配置、日志）
双服务架构（Web + Job）

技术选型理由

FastAPI：异步高性能，支持 OpenAPI 自动文档，适合 AI 场景
MySQL：成熟稳定，已有运维经验
双模型验证：AI OCR 存在误差，双模型交叉验证可在一定程度上降低误识别率
无外键设计：简化数据库操作，避免分布式环境下的锁竞争问题
本地文件存储：初期简单直接，避免引入对象存储复杂度

待完善方向

更丰富的政策规则配置化
更多的理赔类型支持
完善的单元测试覆盖
部署文档与 CI/CD 流程