只是一个非常松散的CNCC 2023参会记录和思考——
Wireless AI
- 利用无线信号强度数据可以得到环境信息
- 利用完善的AI模型，可以对室内活动情况进行精细刻画
- 在拥有更多信号源和接收设备的情况下，AI可以进一步解释信号强度数据实现室内定位、移动体检测（可以辨识正在移动的实体是人类还是动物，因为其对信号的扰动特征不同）、跌倒检测、击键检测（极为细微的扰动都可检测出来，精度极高，也许是以后side channel的攻击方式之一？）
基于大模型的智能化软件工程
- 软件是现实世界的解决方案在计算机世界中的映射
- 各类软件架构、程序组织方式的设计是为了减轻从intention到软件代码实现的映射的困难
- 从意图到软件和从软件到意图，是大模型适合解决的问题
- 现有大模型对软件构建过程中起到较大作用的是开发和测试两个阶段
- 在软件的设计已经敲定的情况下，大模型可以帮助程序员提升开发效率；但如何用大模型去优化软件的设计，目前并没有太多的研究（设计很大程度上起到了控制软件复杂度、满足人员之间高效交流的角色）
- 改进软件系统永远比重新开发更麻烦！
- imho：虽然如此，我们不可能反复地“重新造轮子”，这也是“软件工程”存在的意义
- 测试在未来是一个必须被自动化的环节
- 论坛的说法是，如果代码是自动生成的，不可能人跟在机器后面做测试(it makes sense!)
- 实际上就我自己身边做测试同学的经验而言，大厂（特别是游戏厂）仍然在用纯手工方式解决问题，但这似乎还是非常有效的（也许代码质量原本就堪忧？据其所述，一个游戏的玩法无关功能上线之后，测试在一个小时之内手工找到了整整11个bug… 更多的bug需要自动化测试方法来高效的发现）
- 现在企业代码的文档都非常的糟糕
- 大家在控制代码质量做了很多的工作，但控制文档的质量相关工作却很少；也许这也是一个大模型可以解决的问题？（程序员最讨厌的两件事：1. 写文档，2. 别人不写文档。）
- 目前，最好的知识库就是代码
- 在软件的开发过程中，越来越多的人会focus在需求相关的问题上
- 搞清楚需求太重要也太复杂了，有时候甚至需要成为某个领域的专家！比如开发财务软件，需要对财务流程非常熟悉才能够准确地把握需求
- 很多软件开发完成之后，可能有必要倒回来整理软件的需求，整理成大模型能够接受的形式，把<需求，实际软件>交给大模型
- 参数量是理论上模型效果第一位的因素，深度学习（RNN、Transformer等）实际上是给了一个“管理参数”的高效方案
- 参数越多，效果越好！（用高质量的数据在小参数量网络上实现好的效果，实际上只是压缩了一小部分参数而已——大象不能装进冰箱里）
- 现在的模型有压缩空间，但没有必要一味地追求“用小的模型，实现和大模型类似的效果”（imho: 也许这些工作在模型落地层面上还是有意义的？）
- 不要去做专门的prompt工程和finetune研究！
- 很多时候对一个大模型的finetune反而会破坏大模型的能力（目前有一些解决方案，但并不好）
- 用一个在开源代码上训练完成的模型去为特定领域数据做finetune，很大可能会出现泛化能力差的问题
- 未来的软件会从SaaS发展到SaaM(Software as a Model)
- 这时候对软件的验证就变成了对数据集和模型的验证（真的这么简单吗？也许这也应该归类于SaaS，但它在测试方法上确实不同于传统）
- 审稿人说：不管发的是AI还是SE圈子的paper，都要有足够的insight
- 遇到拿大模型简单apply给软工一些应用的基本都是丑拒(of course!)
- 相比于AI而言，软工的圈子是比较保守的（这是make sense的，软件就是需要小心维护和开发）；于是出现了投稿遭拒，但arxiv上百引用的情况——
- AI可以做Reasoning吗？大模型看起来可以，但是不可解释
- 可以通过Agent去实现；但是要告诉大模型怎么去跟Agent交互，这里用finetune的方式效果并不好
- 一些思考：为什么我会对AI、大模型有抵触和偏见？我一直认为概率模型是不可靠的，具有确定性的算法才是“可控”的。大模型有可能你抛给他一个问题，他给出的是完全不合理的答案；但是，很多时候我们需要概率模型来做决策，就像我们人一样；Reasoning是必须的，但是我们也需要creativity！
- 在特定领域中，通用代码大模型的效果并不好，也很难finetune
- 训练大模型时使用的基本都是开放、开源的代码，但实际上这类模型却被广泛地运用在一些特定领域中，而这些领域中的代码很多都是不开放的（离群的数据）
二进制翻译技术的现状与发展
- 二进制翻译技术的目标是，用尽可能少（接近一条）的指令模拟目标机的一条指令
- 也许这个说法太简单了？是不是用指令的时钟周期来衡量会更好一些？比如一条CISC的指令在最优化的情况下可能也需要数条RISC指令…也许科普向讲座在严谨程度方面做了一些compromise吧（但是这样子是不是又要考虑流水线了？）
- 龙芯目前已经实现了x86到LoongArch的高效率翻译（声称实现了65%~80的性能）
- 包括指令集翻译和Windows系统调用到Linux系统调用的翻译
- 二进制翻译的方式可以解决打印机等外设驱动仅有Windows版本，且无人维护的情况（这个场景也是基本不需要考虑转换效率的）
- 强弱内存模型之间的二进制翻译——Is it that hard?
- 会议上没有给出内存模型之间二进制翻译的具体细节，但据其所述：强内存模型可以相对容易通过修改硬件设计实现，但软件实现则较为困难；M1和龙芯都提供了切换内存模型的开关以模拟x86行为
- 通过硬件设计实现其它ISA的特定操作/行为可以实现高效率的模拟（例如LoongArch用一条指令生成x86的EFLAGS标志位等）