AI 项目集PERSONAL AI ENGINEERING PORTFOLIO
◆ 个人项目作品集 · 五个端到端 AI 应用

五个 AI 项目，都真跑在线上
从需求到部署，端到端一个人做完

五类场景各落地一个：知识库 RAG、多 Agent 协同助手、合同智能审核、车牌实时识别，以及一套跑通完整交易闭环的智能体编排商城。架构设计、编码、容器化部署与 CI/CD 流水线均由我个人独立完成——每个项目都开源在 GitHub，也都能点开线上直接使用。

P1 知识库 RAG · 数据底座 P2 多 Agent 助手 · 业务应用 P4 合同审核 · 行业纵深 P5 车牌识别 · 实时视觉 P6 智能体商城 · 交易与编排
📚

企业级 RAG 智能知识库问答系统

把散落的制度 / 产品 / 合同文档变成可语义问答的知识库：自然语言秒级检索，并接入飞书机器人直接对话
数据底座 · 知识注入 已上线运行
访问线上站点 ↗

系统架构 · 五层

① 文档接入层
飞书 API · python-docx · openpyxl · unstructured（PDF）
↓
② 处理层
清洗 → 语义分块（chunk 512 / 重叠 64）→ 表格线性化
↓
③ 索引层
bge-m3 Embedding → Milvus（HNSW + cosine）
↓
④ 检索层
BM25 + 向量双路召回 → RRF 融合 → bge-reranker 重排 → Top-5
↓
⑤ 生成层
Qwen2.5-72B（硅基流动）→ 置信度拒答 → RAGAS 评估闭环

技术栈

Flask Milvus bge-m3 BM25 RRF bge-reranker SSE 流式 飞书机器人 RAGAS

量化成果

5000+
索引文档 · 1.6 万 chunks
62% → 89%
Top-5 召回率
<2s
端到端响应
92%
拒答准确率

核心难点与解法

  • 1
    表格解析丢行列关系表格按「表头:值」对线性化，每个单元格绑定完整表头路径 —— 解析不是抽文本，是保结构
  • 2
    向量检索对精确词召回差BM25 + 向量混合检索、RRF 融合、再过 reranker —— 粗召回靠关键词，精排靠语义
  • 3
    知识库没有的内容模型硬编（幻觉）Top1 相似度低于阈值 → 强制拒答转人工 —— 拒答也是一种能力
  • 4
    检索效果难量化RAGAS 评估（faithfulness / context recall）+ 200 条标注集 —— 把 RAG 做成了可回归的工程
🤖

供应链智能运营助手（多 Agent 协同）

基于 LangGraph 的多 Agent 系统：一句话即可跨 ERP / 仓储 / 物流完成查数、分析、报告生成
业务应用层 · Agent 落地 已上线运行
访问线上站点 ↗

系统架构 · Supervisor 模式

用户提问
自然语言：「华东仓上周缺货 SKU 有哪些、影响多少订单」
↓
Supervisor Agent · 规划 Planning
拆解任务 → 分派 → 汇总
↓
四个专家 Agent
订单 Agent（ERP 接口）· 库存 Agent（Text2SQL）· 物流 Agent（TMS 轨迹）· 分析 Agent（结论报告）
↓
人机确认节点
写操作 / 金额相关需人工点击确认
↓
记忆
短期 = LangGraph checkpoint（断点恢复）· 长期 = 用户偏好向量库

技术栈

FastAPI LangGraph LangChain Pydantic Text2SQL ERP/WMS/TMS 微服务

量化成果

5 类
高频场景覆盖
85% → 94%
任务完成率
15min → 30s
跨系统查数
96%
工具调用成功率

核心难点与解法

  • 1
    Agent 幻觉调用不存在的工具/参数所有工具用 Pydantic schema 注册 + 调用前校验，失败自动重规划 —— 工具调用不是祈祷，是契约
  • 2
    多步任务中途失败整个作废LangGraph checkpoint 持久化，失败节点从断点重放 —— 长任务要有存档点
  • 3
    Text2SQL 查错表/查错列白名单视图 + 表结构注入 + Few-shot + EXPLAIN 校验 + 只读账号 —— 给 Agent 权限要像给实习生权限
  • 4
    循环调用不收敛LangGraph 最大迭代步数 + 死循环检测
📄

采购合同智能审核系统

OCR + LLM 自动抽取关键条款、比对业务红线、生成审查报告：一份合同从 40 分钟压到 3 分钟
垂直场景 · 行业应用 已上线运行
访问线上站点 ↗

系统架构 · 五阶段

① 解析层 parser/
pdfplumber（文本层）· OCRProvider → RapidOCR（扫描件）· 条款锚点切分
↓
② 抽取层 extractor/
Pydantic 字段 schema（含 quote 溯源）· Few-shot Prompt · 分段抽取合并
↓
③ 规则引擎 rules/
rules.yaml 红线（账期≤60天、违约金≤20%…）· 通用比对器
↓
④ 报告层 report/
CoT 生成 Markdown 审查报告（高危 / 警告 / 通过）
↓
⑤ 服务层 + 复核闭环
FastAPI /contracts/review · 人工复核修正 → SQLite 沉淀 → LoRA 实验

技术栈

FastAPI PaddleOCR RapidOCR pdfplumber Pydantic YAML 规则引擎 CoT LoRA

量化成果

40min → 3min
单份合同审核耗时
95.2%
字段抽取 F1
8% → <1%
漏审率
800+
复核修正数据沉淀

核心难点与解法

  • 1
    扫描件版面混乱、OCR 串行PP-Structure 版面分析还原阅读顺序，关键字段正则锚点二次校验
  • 2
    长合同超出上下文窗口按条款分段抽取 + 结构化中间结果合并 —— 先分治再汇总
  • 3
    抽取幻觉（编造不存在的条款）Pydantic schema 强约束 + 每个字段强制附原文引用，无引用即无效 —— 让每个字段都能溯源到原文
  • 4
    审查规则随业务变化规则引擎外置配置化（YAML），不改代码即可更新红线 —— 规则外置，改红线不改代码
🚗

车牌识别 · 实时视频流

摄像头 / RTSP / 网页视频流进去，结构化车牌事件出来——是边播边识别，不是离线批处理
实时视觉 · 视频流理解 已上线运行 纯 CPU 部署 · 无需 GPU
访问线上站点 ↗

系统架构 · 四层

① 视频接入层
本机摄像头（DSHOW 首帧 118ms · 只认能读到帧的设备）· RTSP / RTMP · 本地视频 · 网页视频链接（yt-dlp 解析直链）· 首帧看门狗
↓
② 检测层
YOLOv8s 车辆检测 → 车牌定位 → 透视矫正 → 暗光/反光增强 → 车牌小图裁剪
↓
③ 识别层 · 双路径兜底
LPRNet（CTC，自研级联）· hyperlpr3（ONNX 兜底）→ 省份简称纠错 → 置信度过滤 → 三层标注（车牌 / 车辆行人 / 疑似车牌）
↓
④ 输出层
跨帧 3s 时间窗去重（上报置信度最高帧）→ 事件 CSV / JSONL + 标注视频 + 车牌截图 → MJPEG 推流回浏览器 · 60s 无人消费自动停

技术栈

YOLOv8s LPRNet hyperlpr3 ONNX Runtime OpenCV FastAPI MJPEG 推流 Docker Compose

量化成果 · 纯 CPU 环境

491 → 130ms
单次识别耗时 · ONNX 线程池调优
8–12ms
单牌识别核心（车牌检测+识别）
6 fps
实时画面 · 本机摄像头 640×480
169
单元测试全绿

核心难点与解法

  • 1
    自研级联权重未训练，链路不能空转检车 → 检牌 → 矫正 → LPRNet 链路已完整，但权重待 GPU 训练；加 auto 模式让 hyperlpr3（ONNX）在级联无结果时兜底，真实图片当场读出车牌号 —— 先让链路跑通，再让模型变好
  • 2
    实时画面只有 0.7 fps识别原本写在读帧循环里，慢推理把画面一起拖死；改为独立识别线程 + 队列容量 1（只认最新帧，中间帧直接丢），画面回到 5 fps —— 实时系统里，过期结果没有价值
  • 3
    CPU 上单次识别要 500–600 ms定位到 ONNX 多会话线程池互相踩踏，而不是模型慢；把 ORT 会话收敛为单线程，同一段视频 491 ms 降到 130 ms —— 瓶颈不在模型，在线程池
  • 4
    摄像头点「开始」后一直黑屏同一台机器同一设备，默认后端首次取帧要 15s+，显式 DSHOW 只要 118ms；再把播放节奏原点改到首帧，避免首帧慢被误判成落后而一口气丢 444 帧 —— 慢的不是摄像头，是后端选错了
🛍️

AgentMall · 智能体编排商城

从商品检索到售后审批的完整交易闭环，上面再压一层只读的 AI 客服编排——能查、能算，但改不动数据
业务系统 · 交易闭环 已上线运行 Spring Boot 微服务 + FastAPI 编排
访问线上站点 ↗

系统架构 · 四层

① 前端与 BFF 层
零依赖静态 SPA（离线可用）· mall-core：商品 / 购物车 / 结算 / 售后 / 会员 / 运营后台 / BFF 同进程
↓
② 交易域 · TCC + Saga
inventory 库存 TCC 三接口（Try / Confirm / Cancel）· order 订单 Saga 协调者兼金额权威 · payment Mock 渠道（成功 / 失败 / 超时三剧本可注入）
↓
③ 履约与对账层
ops-scheduler 延迟关单 · 补偿扫描 · 三方对账出差异单；退款金额 ≥200 元自动进人工审批队列
↓
④ 智能体编排层
FastAPI + SSE 逐节点回显编排拓扑；只读工具白名单（订单 / 订单列表 / 库存档位 / 售后），写操作在网关层直接拒绝

技术栈

Spring Boot 3.3 Java 17 PostgreSQL 16 Flyway TCC / Saga / Outbox FastAPI + SSE Docker

量化成果

7 / 7
部署单元全部可运行
160
端到端可判定断言全通过
100 并发
同键幂等：只产生 1 次副作用
20/分 · 300/日
AI 层滑动窗口 + 全局日配额

核心难点与解法

  • 1
    跨服务扣库存会超卖库存走 TCC 三接口 + 幂等记录表，同键并发 100 次只落 1 次副作用；先 release 再 reserve 直接 409 拦住 —— 不靠"代码写对"，靠数据库约束兜底
  • 2
    订单与支付对不齐、超时单占着库存订单做 Saga 协调者 + Outbox 事件驱动补偿；调度器负责延迟关单释放库存，并定期跑三方对账出差异单 —— 不一致要被"发现"，不能只靠"不发生"
  • 3
    让 LLM 自己筛数值，它会挑"看起来贵的"数值条件一律下推 SQL：「990元以上」被解析成 minPriceYuan=990 交给 SQL 过滤，模型只负责把中文翻成参数；无证据的场合直接拒答 —— 模型翻译，数据库计算
  • 4
    AI 的答案不可核对每个回答挂引用，引用带原文片段可展开；且「答案里列的单」与「引用挂的单」共用同一个函数与同一个截断上限 —— 答案与引用必须同源，漂移比不回答更伤

五个项目，一条技术主线

不是五个散落的 Demo —— 从数据底座到业务应用，再往文档纵深、实时视觉与系统工程延伸，五个项目串起了 AI 应用工程的完整链路

Layer 1 · 数据底座

P1 知识库 RAG

第一个项目解决「信息检索」——把散落的制度 / 产品 / 合同文档变成可语义问答的知识资产。

Layer 2 · 业务应用

P2 多 Agent 助手

第二个项目解决「任务执行」——多 Agent 打通 ERP / 仓储 / 物流，一句话跨系统查数、分析、出报告。

→
Layer 3 · 行业纵深

P4 合同智能审核

第三个项目往「文档理解」纵深走——OCR + 结构化抽取 + 规则引擎，把合同审核从 40 分钟压到 3 分钟。

→
Layer 4 · 实时视觉

P5 车牌识别

第四个项目把 AI 从「会读」推到「会看」——接上摄像头，视频流边播边识别，车辆进出直接落成结构化事件。

→
Layer 5 · 系统工程

P6 智能体商城

第五个项目回到「系统工程」——把分布式事务、补偿对账、幂等与权限边界做扎实，再让智能体站在只读边界内做编排。