陈勇 | AI全栈开发者

1

突破 A：差异架构集成

换用 3 种不同容量的网络：ResNet1D (3.9M 参数，残差连接) + DANN-CNN (82K) + MultiScale-CNN (27K)。单模型 ResNet1D 从零训练即达 99.78%。最终三架构软投票稳定在 99.22%（独立三分离测试集验证：800 标注 / 9200 开发 / 36800 测试）。核心发现："大模型从零训练"比"小模型微调"更有效——即使只有 800 标注样本，ResNet1D 的架构优势远超 DANN 微调的预训练权重。

突破 B：跨域适应实验体系

系统性地验证了 4 种域适应方法在 CWRU→HUST 跨设备场景下的效果：标准 DANN 无监督仅 41.54%（对抗均衡但标签偏移未解决）、CDAN 条件对抗 44.23%（提升仅 2.7pp）、线性探针 86.81%、DANN 微调 95.91%。最终通过差异架构集成突破到 99.22%。同时探索了 CWRU→MFPT、多源域泛化等迁移场景，形成完整的跨域诊断实验矩阵（6 个公开数据集交叉验证）。

突破 C：工程化落地

将训练好的 CNN1D (82K 参数) 和 ResNet1D (3.9M 参数) 嵌入 FastAPI 后端，提供实时振动信号诊断 API。设计单例模式封装 ML 模型（全局加载一次、多 worker 共享），支持 GPU/CPU 自适应推理，4096 点原始信号自动切分滑动窗口。前端 Vue3 实时展示诊断结果和置信度，STM32 端预留边缘部署接口——从算法研究到可部署产品的完整链路。

关键教训与决策记录

同构 Bagging 无效：5 个相同 CNN 软投票仅 88.18%（方差极低），必须用差异架构。标签分布偏移是 DANN 失效根因：CWRU 外圈故障占 56% 而 HUST 均匀 25%，GRL 只对齐边缘分布 P(X) 无法修正 P(Y|X)。CDAN 预训练反而拖后腿：epoch 4 早停导致 Arch-A 微调精度从 95.91% 降到 93.31%。Paderborn 数据集标签陷阱：官方 PDF 确认 KB=复合故障（非滚动体），排除后 v2 微调精度提升 12pp。每项决策都有实验数据和 ADR 记录支撑。

2

突破 A：分批 + 半精度 + GC 三重防 OOM

逐文件加载（而非全量读入 4000+ chunk）→ 每 5 个文件一批写入向量库 → float16 半精度嵌入降低显存占用 → 显式 GC 释放内存。从"每次必崩"到稳定导入 60+ 法律文档 / 6000+ 检索块。核心经验：批处理大小从 500 降到 100，用 continue 而非 raise 做单批次容错——这种"分批+容错"模式适用于所有大批量数据处理场景。

突破 B：RRF 融合 + 多模型抽象层

用 Reciprocal Rank Fusion（只排 rank 不比分数）融合 BM25 关键词检索和 ChromaDB 向量语义检索，解决双路分数量纲不同无法加权的问题。LLMClient 单例抽象层统一 Ollama 本地推理 / DeepSeek-R1 远程 API / 其他 LLM 的切换入口，所有子模块（RAG Pipeline / Query Enhancer / Memory Manager）通过 llm_client.chat() 统一调用，消除各处硬编码 URL。额外实现 HyDE 假设文档增强（生成假设文档再检索）、Multi-Query 多路查询扩展、对话记忆压缩——完整 RAG 全链路的工程化落地。

突破 C：SSE 流式输出 + 知识图谱

后端用 FastAPI StreamingResponse 实现 SSE（Server-Sent Events）流式输出，前端 EventSource 逐 token 渲染——用户无需等待整段回答生成完毕。query_stream 接口与 query 共用 _retrieve_and_rank() 私有方法避免平行维护。纯 Python 邻接表实现法律知识图谱（实体/关系/三元组），ingest 时同步更新 KG 区分增量 add_documents 和全量 build 两种场景，零额外图数据库依赖。权重调优：本地 bm25_weight=0.45、vector_weight=0.70，确保本地法律文档在融合排序时处于优势。

工程挑战与解决方案

.env 配置动态暴露到前端：后端 Request Schema 加 Optional 字段（enhance_mode / enable_kg / top_k），Pipeline 方法签加 override 参数（请求参数 > 全局配置），前端 store 持有配置状态 + 分段控制器 UI。启动脚本健壮性：start.bat 实现 Ollama 多层路径查找（PATH → 标准安装路径）、pip 国内镜像源自动设置、端口残留清理；stop.bat 新增模型卸载。打包部署：pip download --dest wheels 离线安装包随项目发送、npm run build 后对方无需 Node.js 用 python -m http.server 托管、大模型 BGE-M3 (~2GB) 可随包或在 .env 配置远程拉取。

3

突破 A：从零构建数据集

绿萝病害无公开数据集——这是最大的起点障碍。从零开始：实地/网络采集绿萝不同生长阶段图片（爆盆期 / 生长期 / 扦插期 / 幼苗期，覆盖不同光照和角度）→ 用 LabelImg 手工标注 4 类病害边界框（叶斑病 / 叶枯病 / 根腐病 / 正常健康，每类约 100 张）→ 处理类别不平衡（部分病害样本稀少）。完整走通了 CV 项目最耗时但最关键的数据工程环节。

突破 B：资源约束下的模型调优

硬件约束：RTX 4060 Laptop 仅 8GB 显存。在有限算力下完成 YOLOv5s 训练全流程：Mosaic + MixUp 数据增强缓解小样本过拟合 → FocalLoss 处理类别不平衡 → batch-size 从默认 16 降到 8、input-resolution 从 640 调到 512 以适配显存 → 迁移学习用 COCO 预训练权重 warm-up 前 3 个 epoch。推理端用 OpenCV 构建图像预处理管线（resize / normalize / BGR转换 / NMS 非极大值抑制后处理），单图推理 <50ms。

技术栈与部署形态

训练框架：PyTorch + Ultralytics YOLOv5 + CUDA 11.8。标注工具：LabelImg (PascalVOC 格式)。推理部署：OpenCV DNN 模块加载 ONNX 格式模型（无需 PyTorch 运行时），封装为本地 Python GUI 工具（tkinter 界面）。支持两种使用模式：图片批量检测（拖入文件夹自动逐张识别并保存结果 CSV）和实时摄像头模式（USB 摄像头 15fps 实时框选病害区域）。覆盖了计算机视觉项目的完整生命周期：数据采集 → 标注 → 模型训练 → 导出优化 → 应用部署。

4

突破 A：56 套独立牌义模板体系

核心挑战：78 张塔罗牌中，22张大阿尔卡纳有公认含义但 56 张小阿尔卡纳（Wands / Cups / Swords / Pentacles 每组 14 张）缺乏标准化解读——通用 prompt 只能输出泛泛而谈。解决方案：为每张小阿尔卡纳手工编写独立的语义模板（含正位/逆位双重含义、关键词、关联意象），共 56 套结构化模板。AI 解读时根据抽到的牌组合动态拼接 prompt，确保每次输出都有针对性和深度而非套话。这是从"能跑的 Demo"到"有质量的产品"的关键区分点。

突破 B：延迟验证机制 — 用户体验闭环

设计了独特的延迟验证反馈系统：用户抽牌获得 AI 解读后，解读结果存入 localStorage 历史记录；3 天后系统推送"验证提醒"（首页角标 + 历史页筛选 tab），用户可回头对当初的 AI 解读打分（1-5 星 + 文字反馈）。这个机制解决了塔罗类产品的核心痛点——解读当下感觉准不准和事后灵不灵是两回事。积累的验证数据可用于后续分析哪些牌面/场景下 AI 解读准确率最高，形成产品迭代的数据飞轮。

技术实现与向量检索升级

后端 Python FastAPI 提供 78 张牌的完整定义 API（大阿尔卡纳含 astrological / elemental / numerological 属性，小阿尔卡纳含正逆位双模板）。前端原生 HTML/CSS/JS 三栏式布局（牌阵区 / 解读区 / 历史区）。LLM 集成层支持 Ollama 本地推理和 DeepSeek 远程 API 双模式一键切换。向量检索升级：用 Ollama /api/embeddings + numpy cosine 实现语义搜索（替代了 chromadb 因 Python 3.8 32bit 无法安装的困境），BM25 关键词检索做降级兜底，RRF (Reciprocal Rank Fusion) 融合双路结果——用户输入模糊意图时也能匹配到相关牌义。历史记录 localStorage 持久化 + 后端写入降级双保险策略。

5

突破 A：从"500 错误"到完整上线

接手时项目处于"完全无法运行"状态：5 个 WXML 页面中有 3 个引用了不存在的 JPG 图片资源（sheet1-3.jpg、lesson1-2.jpg），分享功能依赖不存在的 share.png——用户端直接 500 白屏。排查方法：逐页面扫描 <image> 标签 src 属性与 static/images/ 目录做交叉比对，定位全部 5 处断裂引用。修复策略：用现有 PNG 图标库替换缺失的 JPG 资源（保持视觉一致性），分享功能降级为微信默认截图 API（wx.previewImage）。从接手到修复上线仅用一次会话，体现了快速定位和务实降级的能力。

突破 B：微信小程序云开发全栈链路

独立完成了 5 个功能页面的全栈实现，覆盖微信小程序开发的完整技术栈。前端层：WXML 模板 + WXSS 样式（含 rpx 响应式适配不同屏幕）+ JS 逻辑处理（页面路由 / 数据绑定 / 事件监听）。后端层：微信云函数（Node.js 运行时）处理搜索 / 收藏 / 播放记录等业务逻辑，无需自建服务器。数据层：云数据库（类似 MongoDB 文档型）存储乐谱元数据（曲名/调性/BPM/难度等级）、用户进度（已学/收藏列表）、播放统计。额外实现了音频播放器组件（支持后台持续播放 + 进度条拖拽 + 播放模式切换），这是小程序音频开发中较复杂的部分。

技术细节与架构设计

技术选型理由：选择云开发而非传统服务器方案是因为项目规模适合免运维模式——无需域名备案 / SSL 证书 / 服务器运维，适合个人项目快速迭代。云数据库天然支持离线缓存和冲突解决（小程序特有场景）。页面结构：首页（推荐乐谱 + 分类导航）→ 学习页（乐谱详情 + 音频同步播放）→ 详情页（作曲家背景 / 乐理知识扩展）→ 练习页（节拍器工具 + 跟练模式）→ 个人中心（进度统计 / 收藏管理）。关键设计决策：乐谱数据采用 JSON 格式预置在云数据库中（非实时请求外部 API），保证加载速度和离线可用性；用户数据用 OpenID 做隔离确保隐私安全。

我是陈勇

项目经验

IndustrialMind — IoT 设备故障预测与健康管理