如何向别人解释DL工作的实质?

本文深入探讨深度学习(DL)在计算机视觉(CV)领域的应用,解析DL如何解决图像描述、问题刻画与理解及算法求解三大核心问题。同时,文章列举了CV在监控、医疗、ADAS等行业的实际应用案例,以及其对行业效率的提升。

如何向别人解释DL工作的实质?

我的工作是做什么的?

对于这个话题,看到一张图很有说服力。下面列出来。看完之后瞬间从高大上变的low爆了。。。

哦,对了,我研究或者工作的领域叫机器学习和人工智能。这到底是个什么玩意,像我等普通人如何理解,且看下图。

 

废话说道这里,来讲讲主题DL。

DL即Deep Learning,属于计算机视觉的一种。简称CV行业。这两者联系越来越紧密,越来越相似,大有DL代替CV行业中的所有技术的趋势。作为渣渣中的渣渣,还是转载一下知乎前辈的观点:https://zhuanlan.zhihu.com/p/27485775

最近忙里偷闲,刚好有机会整理关于计算机视觉的一些理解。作为一个老兵,又作为一个时刻保持hungry的新人,将自己对cv的很多思考总结一下,仅以抛砖。可能有偏,管中窥豹而已。

大致分成以下几个部分吧:

A. 技术

B. 产品

C. 行业

先谈谈技术,也或许是因为技术是技术人最容易表达清楚的领域吧。最近越来越清晰的感觉到计算机视觉的问题和机器学习的问题更为接近了(排除掉图像预处理等诸多操作),基本上概括起来就3条:1. 描述(特征),或者用英文叫representation;2. 问题的刻画和理解,在这里我没有单一的使用loss function来表述这个问题,问题的刻画和理解应该有更广阔的含义,比如检索问题(当然检索实际上也可以通过loss function来描述);3. 算法、模型、求解:当有了『物』的描述,以及对于问题的刻画,我们需要找到对应的模型来进行求解。上面3条在计算机视觉领域同样适用。

a1. 可以说计算机视觉中有超过60%的工作我们都是在寻找对于图片的一个描述;这个描述可以是0-255的像素值,可以是颜色直方图的分布,可以是我们能够想到的通过各种算子计算到的图像上的局部的,全局的,梯度的,空域的,频域的,各种平滑、锐化、normalization之后的数值表达,也或者是通过类似bow方式获得的图像的统计表达(用block的相似性来表示图片),也或者是计算图像特征点之后的特征计算或者统计(用点的相似性来表示图片),也或者是通过深度学习学习到的某些卷积核作用于图片之后的表达。这些表达我们可能能够描述物理含义,也可能只有统计意义上的物理含义;但有一个趋势:就是这些表达越来越从图像的底层往语意层发生转移,其实追求就只有一个,那就是语意层级的相似性和区分度;无论是光照,大小,角度,噪声,模糊等等可能引起的描述的差异,那么我们终极的追求实际上是语意级的相似性。【在某一个场景下,化成灰我也能认识你】

a2. 问题的刻画和理解。描述这个问题之前我们先来看看目前cv领域最重要也最为基础的task:目标的检测、跟踪、识别,图像的检索,人脸的识别和验证,image caption,image generation,超解像,视觉slam(vo计算)等等,而这些任务本质上都可以概括成几个基本的问题:分类、回归、排序ranking、关联correlation;其实这几个基本的问题放到任何以机器学习为背景的数据科学里面同样适用。搜索引擎是典型的ranking问题,CTR预估是回归问题和ranking问题的结合,topic model是分类问题,人物画像是分类问题(估计把聚类问题归结到分类当中,不一定严谨,见谅),推荐是ranking为主,社交网络则是典型的correlation问题等等。目标检测是典型的分类问题,目前也开始演变成回归问题;物体识别、人脸识别是分类问题;跟踪也是典型的分类+回归的问题;图像检索是ranking问题;image caption是关联问题;image generation是回归问题,视觉slam中最核心的部分特征点的匹配是ranking问题。

a3. 算法、模型、求解:机器学习中一切能够用来求解分类、回归、排序、关联等问题的算法都能够使用,相应的技巧都能够使用,相应的优化方法都能够使用。

总结起来,我们已经有意或无意的在使用更为general的机器学习的方法来处理cv的问题,或者说是用更general的机器学习的观点来刻画和理解cv的应用。


 

产品,其实是我最不想去聊的一个话题。cv的产品层出不穷。监控行业中有大量对cv的需求,工业检测中也对cv的精度有很高的要求,人脸识别、物体识别等都是需求,image caption,拍立淘,百度明星脸,相册分类,手势识别、自然图片中的文字识别、手写识别等。总结起来我们实际上是在把任何需要【人的眼睛+人的记忆能力+人脑的想象力】的任何场景变成cv的场景。能变出什么样的花样呢?视力更好(能够识别比人眼更多的细节),记忆力更好(能够存储、检索比人脑更大的库),想象力更好(比如风格画的生成)。说几个我自己认为能够提升行业效率并真正产生行业价值的产品。

b1. 替代人的智能监控设备,不管智能监控目前是不是效果还不理想,从产品角度他是在替代人工提升行业效率;

b2. 基于视觉的ADAS设备,解放人的部分注意力;

b3. 类似face++等算法的服务,实际上是在通过计算换时间,也是在提升效率;

b4. 医疗图像分析,人脸验证(打卡、解锁),证件识别也实际上是通过密集计算来减少人工成本;

b5. 亚马逊未来超市中通过视觉拿到你所购买的商品信息,并通过人脸等技术完成支付;实际上依然是在通过技术来节省人力成本以及提升行业效率;包括格林深瞳早期希望通过shopping mall的视觉信息进行商业分析都是这个路子。

任何一个以cv为中心的产品,最终能够得以生存下来的原因除了博人眼球之外一定是因为他要么提升了行业效率(时间、人力、计算资源),要么改变了用户体验。


 

行业。轻易不敢谈行业的问题,既没有那个高度,也没有那个能力。一点愚见仅供参考。从入行cv有那么一段时间开始,就在思考cv本身只是一个工具吗?这个工具有可能成为某一个行业不可获取的技术吗?还真有那么几个领域cv不可或缺:

c1. 监控,产品的那一part已经说过,如果智能监控的算法能够好的落地,那cv在这中间一定是提升行业效率的;

c2. 云+端 一体化的cv能力的构建:无论是交通还是医疗领域,云端一体化的cv能力会是未来一个比较长时间的主题;

c3. 很多领域都对cv这个工具有需求,希望借此来完成之前不能完成的任务或者是提升效率;

cv本身有可能能够成为一个行业吗?比如人们对于信息的需求诞生了百度,人们对于商品的需求诞生了阿里,人们对于社交的需求诞生了腾讯,人们对于行、食的需求诞生了滴滴、新美大;那人们对于视觉能力的需求能够诞生什么呢?

从马斯洛需求层级来讲,人对于视觉能力的需求应该是和人对于出行的需求处于同一级?人对于更powerful的视觉能力的需求到底是什么呢?

见微知著?抑或博古通今?

那如果不仅仅是人,如果我们把cv也看成是一个to B的生意,那么B对于更powerful的cv能力的需求是什么呢?

留下这些问题,笔者也会多思考,也希望能够和读者多交流。


 

写到这里,依旧发现技术的那一part是最易书写的。

<think>我们分析的重点是CMake脚本中的一段自定义命令,特别是关于复制文件的部分。用户的问题集中在复制文件是否会影响dl目录(通常用于存放下载的依赖包)从而避免重复下载。 ### 核心问题分析 复制除`dl`外的所有文件,是否就能避免重复下载`dl`目录的内容?答案是否定的。因为`dl`目录通常用于存放下载的依赖包(OpenWrt构建系统中的包),在构建过程中会被使用。复制操作会将源目录中除`dl`外的所有文件(包括可能存在的补丁或其他依赖)复制到目标目录,但构建系统在构建时仍会使用目标目录下的`dl`目录(如果存在)。 ### 关键点解释 1. **`dl`目录的作用**:在OpenWrt构建系统中,`dl`目录存放的是下载的依赖包。构建系统在构建时会检查`dl`目录中是否有需要的包,如果没有就会重新下载。 2. **复制操作的影响**:复制操作会将源目录中的`dl`目录(如果存在)也复制到目标目录(但用户命令中排除了`dl`目录?不对,用户命令中排除的是名为`dl`的文件或目录,但`dl`目录实际是存在的)。这样目标目录中也会有一个`dl`目录,其中包含下载的依赖包。 3. **避免重复下载的关键**:确保构建系统使用同一个`dl`目录(共享下载的依赖包)才是避免重复下载的关键。在原始CMake脚本中,通过为`dl`目录创建符号链接(`create_symlink`)来共享`dl`目录,从而避免重复下载。 ### 命令详解 ```cmake # 创建符号链接指向源目录的dl目录 COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CURRENT_SOURCE_DIR}/dl ${HI_VERSION_DIR}/dl # 复制除dl外的所有文件 COMMAND ls ${CMAKE_CURRENT_SOURCE_DIR}/ | grep -vE "^dl$" | xargs -i cp -rf ${CMAKE_CURRENT_SOURCE_DIR}/{} ${HI_VERSION_DIR} ``` - **符号链接的作用**:创建符号链接`${HI_VERSION_DIR}/dl`指向源目录的`dl`目录,这样构建系统在构建时访问的是同一个物理目录。无论构建多少次,实际依赖包都存储在同一个位置。 - **复制除`dl`外的文件**:复制操作不会复制源目录的`dl`目录(因为被排除),但复制后目标目录中会有一个新的`dl`目录(由复制操作创建),其内容与源目录的`dl`目录无关(因为是复制而非共享)。 ### 结论 - **复制文件不能避免重复下载**:因为复制操作创建的是新的`dl`目录副本(独立于源目录的`dl`),构建系统在每次构建时仍会检查这个新目录中是否有需要的包,如果没有就会重新下载。 - **符号链接才能避免重复下载**:通过符号链接(`create_symlink`)让构建系统实际访问的是源目录的`dl`目录(物理位置相同),这样无论构建多少次都共享同一份依赖包,从而避免重复下载。 ### 改进方案 如果希望复制操作也能避免重复下载,必须确保构建系统在构建时使用的`dl`目录指向同一个物理位置。在原始CMake脚本中,符号链接已经实现了这个目的。而复制操作(如命令中的复制)会导致构建系统使用不同的`dl`目录(物理位置不同),因此无法避免重复下载。 ### 修复建议 如果必须复制文件(而非创建符号链接),则应: 1. 只复制构建所需的文件(排除`dl`目录) 2. 在复制后创建符号链接指向源目录的`dl`目录: ```cmake # 复制后手动创建符号链接(模拟符号链接效果) add_custom_command( COMMAND cd ${HI_VERSION_DIR} && ln -sf ${CMAKE_CURRENT_SOURCE_DIR}/dl ./dl ) ``` §§相关问题§§: 1. 在C语言中如何实现符号链接功能? 2. 文件复制操作如何影响磁盘空间使用效率? 3. 为什么共享依赖包目录能节省构建时间? 4. 如何避免重复下载依赖包(在构建系统中)?</think>### 问题回答 #### 核心结论 复制除`dl`外的所有文件**不能避免重复下载**,因为: 1. **`dl`目录是数据容器** OpenWRT 构建系统在编译时会自动检查 `dl` 目录内容: ```c // 伪代码:构建系统检查 dl 目录 if (dl/package_xyz.ipk 存在) { 跳过下载; } else { 执行下载; } ``` 2. **复制操作创建独立副本** ```cmake # 复制后目标目录结构 ${HI_VERSION_DIR}/dl # 新目录(与原目录无关) ``` 构建系统无法感知这是同一个项目,会重新检查依赖包并触发下载。 #### 避免重复下载的关键 1. **符号链接实现共享** ```cmake # 原始命令 create_symlink ${CMAKE_CURRENT_SOURCE_DIR}/dl ${HI_VERSION_DIR}/dl ``` - 符号链接让构建系统认为 `${HI_VERSION_DIR}/dl` 就是源目录的 `dl` - 实际访问的物理地址相同 2. **复制操作导致隔离** ```cmake # 错误做法(示例) file(COPY ... EXCLUDE dl) # 复制时排除 dl ``` 复制后的新目录与源目录的 `dl` 完全独立,构建系统会将其视为新目录。 #### 解决方案 ```cmake # 正确做法:创建符号链接 add_custom_command( ... create_symlink ${CMAKE_CURRENT_SOURCE_DIR}/dl ${HI_VERSION_DIR}/dl ) ``` ### 代码验证 ```c #include <stdio.h> #include <unistd.h> int main() { // 模拟构建系统行为 char* dl_path = getenv("DL_DIR"); // 获取环境变量 if (dl_path == NULL) { printf("需要重新下载依赖包\n"); // 触发下载代码 } else if (access(dl_path, F_OK) != 0) { printf("需要重新下载依赖包\n"); } else { printf("跳过下载(依赖包已存在)\n"); } return 0; } ``` **输出**: - 当符号链接存在时:`跳过下载(依赖包已存在)` - 当符号链接被复制时:`需要重新下载依赖包`
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值