工作汇报网 >地图 >

工作总结

工作总结

时间:2026-04-21 作者:工作汇报网

人工智能实施工程师工作总结[推荐]。

说实话,干我们这行,跟以前带毕业班特别像——你备的课再精彩,到了课堂上学生听不懂、考不出来,一切都是白搭。今年我主要跟了三个制造业的视觉质检项目和一个政务智能客服落地,踩了不少坑,也攒了一些“土办法”。下面按时间顺序捋一捋,权当给自己做一次教学复盘。

一、蹲在产线上“摸底”,比看一百份文档管用

年初接了个汽车零部件厂的活,他们想用AI识别铸件表面的砂眼和裂纹。客户很爽快,甩给我两千张标注好的图片,说“你就按这个训练”。我当时多留了个心眼——当老师二十年的习惯,拿到任何“标准答案”之前,先去看看学生平时作业是怎么错的。

我跟产线工人混了三天。第一天夜班,我发现灯光偏黄,原本灰白的裂纹拍出来成了淡金色,跟砂眼的颜色混一块儿了。第二天,工人老张跟我抱怨:“你们这AI要是跟上次那家一样,把油污当裂纹,我可不伺候。”第三天更绝——我蹲在传送带侧面,发现有些裂纹只有逆光时才反光,正面拍根本看不见。

这下我明白了:数据不是越多越好,是越“全”越好。我回去跟客户说:“这批标注图片得重采。”对方技术负责人脸都绿了:“这花了两个月才标好的!”我没急,把手机里拍的三组对比照片给他看——同一块铸件,白天拍、夜班拍、侧面打光拍,出来的特征完全不一样。他沉默了五分钟,最后拍板:“听你的。”

后来我们重新制定了采集方案:分时段、分角度、分光照强度,还让质检班长亲自参与标注规范的修订。这件事让我记住一个道理:需求调研就像开家长会,你得听到孩子自己怎么说,不能只看成绩单。

二、模型上了产线就“翻车”,我蹲在传送带旁边改代码

模型在测试集上跑出96%的准确率,我们信心满满地部署到产线。结果第一天就炸了——误报率高得离谱,正常工件被频繁判为次品。产线组长打电话来,语气很冲:“你们这玩意儿还不如老师傅拿手电筒照!”

我当时血压也上来了,但知道发火没用。拎着笔记本就蹲到传送带旁边,实时截取每一张被误报的图片。看了两百多张后,我发现规律:所有误报都出现在传送带接头处,那里有油污积累,反光特别强。更坑的是,这些油污的局部高亮形态,跟裂纹的灰度梯度几乎一样——模型根本没法学区分。

我试了第一招:调图像预处理的阈值,想把高亮噪点直接抹掉。结果误报率从15%降到12%,但代价是真实裂纹也被削淡了三个百分点。这不行。第二招:改光源。我跟机械部门商量,把原来的顶光改成斜侧45度打光。效果立竿见影——油污反光变成了大面积漫反射,而裂纹因为深度不同,仍然保留明显的阴影边缘。误报率掉到5%左右。但还不够,偶尔还是会把划痕当裂纹。

最后我干了一件“笨”事:在损失函数里给“反光噪点”这类误判加了一个惩罚权重。说白了,就是告诉模型:“你再把油污当裂纹,我就扣你双倍分。”这个参数我调了整整一个下午,从0.5试到2.0,最后锁定在1.8。连续跟踪三天,误报率稳定在2.3%。

这事儿过了之后,我请产线工人喝了顿酒。老张跟我说:“其实我们早就知道油污反光的问题,但以前来的工程师没人肯蹲在这儿看。”我心想,这跟改学生作文一样,你不坐在他旁边看他怎么落笔,光给个评语有什么用?

三、“错题本分析会”比任何技术文档都好使

政务热线的智能派单项目,差点栽在一个我以为很简单的地方。模型能把“噪音扰民”分到环保局,准确率87%。但上线第一周,坐席员几乎没人点“AI推荐”按钮。我去问一个老坐席,她翻了个白眼:“你们这破系统,把夜间施工噪音分给环保局,可我们这儿的规定是归城管。我每次都要改,还不如自己选。”

我被噎住了。回来一查,原来本地有个管理办法:晚上十点后的施工噪音,不管什么来源,统一由城管执法。这个知识,再大的预训练模型也学不会,因为它不在任何公开语料里。

我没急着改模型。第二周,我组织了一场“错题本分析会”,把模型所有误判的case打印出来,贴在会议室墙上。请了五个坐席骨干、两个业务科长、一个IT运维,每人发一支红笔,像批改作业一样圈出错在哪里。一开始气氛有点僵,有个科长说:“这模型是智障吗?”我接了一句:“那你们之前给的训练数据里,有没有把这类case标对?”他愣了,回去翻了翻,发现他们自己的历史工单里,确实有一半夜间施工投诉归到了环保局。

吵了两个小时,最后大家一条一条地捋,整理出17条本地业务规则。我没把这些规则硬塞进模型,而是写了一个轻量级的后处理脚本——模型先分类,如果结果命中这17条中的任一条,就自动替换成正确部门。脚本跑起来只增加5毫秒延迟,但派单准确率直接跳到了99%。

后来我每周五下午开半小时线上答疑,不是讲技术,是讲“模型为什么会这么判”。我用坐席员能听懂的话解释:比如“模型看到‘噪音’和‘施工’两个词在一起,权重高的是环保,但它不知道你们的时间规则”。说白了,AI不是来取代人的,是来帮人减少重复劳动的。你尊重人家的经验,人家才会配合你迭代。

四、几个差点让我失眠的细节

数据版本管理这件事,我是被坑过一次才重视的。有个客户自己往训练集里加了新图片,没告诉我,结果模型精度突然暴跌。我查了两天才发现,他加的图片里有一批是手机拍的,分辨率跟工业相机不一样。从那以后,我定了个死规矩:谁要动数据,先写个“变更说明”发我邮箱,内容包括改了哪些文件、谁改的、为什么改、旧版本备份在哪儿。新来的同事觉得我事儿多,我说你等踩一次坑就懂了——这跟学生档案一样,你不能今天记80分,明天改成90分,还不留痕迹。

推理速度优化那次,我试了四种方案。通道剪枝最快,但精度掉了1.2%,客户不答应。量化从FP32降到INT8,速度快了但边缘设备不支持。最后用了TensorRT配合FP16,精度掉0.3%,速度从120ms压到45ms。我把每次实验的数据都记在一张表格里,分五列:方法、耗时、精度变化、速度变化、是否采纳。这张表现在成了我们组里的“避坑指南”,新项目直接查表选方案。

异常处理机制是我最得意的设计。模型推理时遇到从未见过的光照(比如断电后的应急照明),输出置信度会低于0.6。我们加了一个“人工兜底”开关——低于0.6的判定自动推送到主管手机,由人复核。这个思路其实是从考试来的:超纲题允许学生先跳过,但老师要标记出来,课后重点讲。后来统计发现,有30%的情况是模型正确但工人看错了——这反过来帮我们优化了人机协作界面。

五、那些我没写进周报的教训

有一个项目,我犯了低级错误。当时急着上线,没仔细验证新版本的预处理代码,结果模型把所有的蓝色工件都判成了缺陷。后来发现是一个实习生改了颜色空间的转换参数,但没更新注释。我当时挺生气,但冷静下来想,是我没建立“提交通道强制校验”的流程。后来我写了个小脚本,任何代码提交前自动跑一组基准测试,过不了阈值直接拒绝。这事之后,我每次带新人都会讲一遍:“改参数之前,先想清楚你动了什么,再想清楚谁会倒霉。”

还有一个教训是关于“说人话”。有次给客户汇报,我讲了二十分钟的“注意力机制”和“特征金字塔”,对方技术总监直接打断:“你就告诉我,这玩意儿能帮我们省几个人?”从那以后,我养成了一个习惯:先拿一张纸,用三句话把方案翻译给非技术人员听。比如“这个模型就像一个有经验的质检员,他看过十万个零件,现在看到新的,能快速判断好坏。但他有时候会被反光骗,所以我们要给他配一个手电筒(指光源调整)。”

六、一点实在的体会

回头看这一年,我最自豪的不是准确率从90%提到98%,而是学会了“留余地”。技术方案永远要给业务规则、人工干预、甚至物理调整留出接口。比如在每个模型的输出层,我都加了一个“人工复核”的数据埋点。后来发现,工人在点击“复核”时,有30%的情况是模型正确但工人看错了——这个数据反过来帮我们优化了操作界面。

我越来越觉得,AI实施工程师的核心能力不是刷榜,是“翻译”。把业务痛点翻译成数据需求,把模型错误翻译成改进动作,把技术限制翻译成用户预期。你懂的,这跟教了二十年书的道理一模一样:没有差学生,只有没找到适配方法的教学设计。

明年我打算干一件“笨”事:把这三个项目的踩坑记录整理成内部案例库,按“场景-问题-措施-效果”的格式归档,再配上每个错误对应的现场照片和代码片段。新来的同事谁再踩一遍,就请全组喝奶茶——不是惩罚,是提醒我们,有些坑光看文档是记不住的。

    为了您方便浏览更多的工作总结网内容,请访问工作总结

本文来源://www.gsi8.com/gongzuozongjie/191462.html