分类目录归档:不是技术

无现金社会

整理笔记,没法记录在onenote上。

无现金社会达成后,会出现一种无现金的文化,就跟之前现金文化一样。我们如何看待我们的财富和支付能力,电影和小说中如何描述人们如何有钱或一贫如洗,数字化是可以做到一点,但是信用体系似乎描述起来又只有屈指可数的几个场景。

实体的卡,比如百夫长可以让事情容易一点,但毕竟不如现金那么普及,这世界上很多人也不清楚卡是怎么回事。动不动炫耀账户上的数字更是隐私保护的大忌。

这种无现金文化该怎么表达,还是值得思考的。

所以一些支付应用的卖点的UE,在一个普遍受用的环境下,frictionless的购物、支付,这样就足够了……?

无现金的技术和架构也出来很多年了,大体上不会形成太大的问题。有点可悲的是,由于V和MA实在是太强大了,以至于网上购物也只能沿用老旧的信用卡技术体系。

这是一条当时的笔记记录。CNP(Card not present)欺诈的根源,是信用卡技术体系并非为电子商务而设计的。但电子商务起来迅猛,信用卡产业链又不希望失去这一大市场,于是增加了EMV 3DS这种补丁式的标准。

政府的支持和公众的信任。政府无疑是乐于见到无现金社会出现的,前提是不冲击其法币基础。不受政府监管的加密货币会在强权国家受到政府的抵制和禁止。小政府国家只有靠央行和法庭去限制,民间行为很难控制。

无现金还有一个问题是,当它与现金对立之后,公众会将其视为一种方式,但实际上无现金支付方式五花八门,八仙过海,其通用性和普及性还有漫长的路要走。

最后估计还是政府、央行、卡组织才有能力去统一,也同时可以承担公众普及的成本。

联邦学习与大数据隐私专场

这个专场对于我来说,算是一个扫盲性质的,听了几个讲座后,大概知道联邦学习是一个什么样的模式了。

杨强是港科大的教授,微众银行的高管。他对联邦学习的介绍还是很清晰的:https://www.leiphone.com/news/202008/hBACeSbAY8PIOcbh.html

联邦学习的背景是1.数据的来源碎片化,且难以标准化,2.数据的合规性要求限制了中央处理。

继续阅读

企业服务专场

选这个来听,本意是希望听到关于企业SaaS怎么做的讨论,但遗憾的是,还是偏少。主要是企业服务如何匹配新基建等大方向和大趋势的。

信通院政策与经济研究所副所长何伟,https://www.leiphone.com/news/202008/PG3C7FP2gUzNXNAd.html

重点在于产业发展的时间和方向,企业服务应该与其保持一致。

阿里巴巴副总裁,郭继军,https://www.leiphone.com/news/202008/wvoatM5VImhgvrGQ.html

企业服务中,数据凌驾一切,打通数据间的障碍,后挖掘及形成新的业务。而对阿里来说,目前则不纠结于具体是哪个云,哪一家的云,只考虑将其打通并组合给应用。

继续阅读

AIoT专场

其实这个专场更多的是老生常谈,因为世界的变化方向已经很明显了,我们一天天地看到AIoT的临近,只是是谁推动的差别。

谭建荣院士的报告,应该算是一个总体的介绍,虽然我知道很多人并不需要这样的介绍。https://www.leiphone.com/news/202008/k6OvGuYih46R9IBb.html

印象最深刻就是5G+IoT这种异构网络下,很多传统的网络方式会被替代,沿用过往的经验可能并不合适。自组织网络跟M2M又是相互相成的,M2M会衍生新的业务需求,但基本的M2M需要自组织网络,M2M的业务设计也应假设是自组织网络下。内容分发上也有新的考究,毕竟5G下,存储尚未出现一种更优的形式,P2P该怎么走?

继续阅读

机器人前沿专场

次日,选了机器人前沿专场和AIoT专场来听。

开场的报告是加拿大工程院张宏院士作的。他也即将在深圳建立有实验室,但此次是用远程的方式进行演讲。

https://dy.163.com/article/FK6GSE5D0511DPVD.html

讲的范围不多,集中在机器人如何得知自身处在已知地图的何处。包括对视野中的各种物体的标示(全局/全景描述符),Deja vu的时候各种不同的外部环境产生的变化如何识别,二维点云计算即确认,图像粗匹配、精匹配,雷达和视觉的信息融合等等。

不过他说的是已知地图的情况。结合去年有个讲陌生环境下的digital twin构建地图,就可以多机器人联合制作地图并进行相对定位了。

继续阅读

人工智能前沿专场

今年看着早鸟票(399)便宜,就又参加了一次CCF-GAIR。但疫情的影响很大,去年的诺奖嘉宾的豪华阵容就没见到。但主题和方向是更加专注。我前后三天,主要听了五个专场:人工智能前沿、机器人前沿、AIoT、企业服务、联邦学习与大数据隐私。

继续阅读

通用AI的业态及商业模式

算法团队开始抽象出来,并不集中注意力在某一个固定的领域上。

于是,如何做一个通用的AIaaS,让不同行业不同需求可以运行在一个云AI平台上成了一种趋势。

看到Square收购了Dessa,依稀有一些这种趋势。

AI 2B是一个生存的趋势,因为AI 2C都是一些好看不中用的玩意。但是Big B有点困难,一方面Big B可以养活自己的AI / ML团队,另一方面,Big B的定制化需求太多太复杂,很容易把整个AI团队卷进去,于是就跟平台化无缘了。

注定是Small B。

Small B有数据,缺团队,顶多有一两个data scientist。这样就是AIaaS的机会了。

但AIaaS的考验也不少,需要把AI工程做得通用、可配置,有伸缩性,容易收费。

还要需要提供data cleansing的工具及服务,搞不好,这个数据清洗的工作需要的人力成本远比AI主算法要高。

AIaaS的团队需要补强的是,

1.传统SaaS的架构师,这里可是需要有真材实料,能庖丁解牛的架构师

2.能针对不同行业快速设计AI / ML方案的数据科学家

3.精通data cleansing的脚本工程师

程序员的圈子为何会内卷

留意到知乎上每隔段时间,内卷的话题就会再度出现。

先抛开资本论的角度看这个问题。

程序设计一开始被认为是艺术,能理解程序、编写程序的人,被认为是智者,programmer和writer(作家)享受着差不多同等的待遇。

但新的语言、设计框架、优质架构以及摩尔定律的出现,程序设计的门槛快速降低,于是程序员的地位下降了,慢慢成为一种代码工人(coder)性质。同样,慢慢下降的身份还有设计身份,因为抄起来是很容易。作家的抄袭一开始也会导致声名狼藉,但读者接受,也能出来一堆抄得比原作者更优秀的作家。

但程序员不一样,他的作品的受众是互联网工业、商业本身,相比知识产权本身,更在乎程序/软件的功能和质量、可复制性、可重用性等,在这一点上,程序员必须成为工人而非艺术家。

架构师的身份也在下降,因为架构对着不同的场景,也是套用以往的经验和模板,只要群体变大了,架构师的工作的原创性不需要太多,这样慢慢的,架构设计,也是不断地抄袭和重复自己的过程。

只要一个群体内部,重复度高,快速复制成风,内卷就基本坐实了。

再深究原因,为什么数学家/物理学家并不能弄出一个内卷的行业,主要还是消费主义加上程序员相对于其他行业畸高的收入导致的。

而程序员为什么收入高,因为无论硅谷还是北上广,新资本热衷于颠覆老钱的地位,于是借信息化的机会,希望能重塑各个传统行业。这个重塑的过程需要大量的信息化工人——程序员。行业的颠覆,提升了社会效率,自然出现机器吃人的情况,运作机器的人当然也得到了吃人的好处。

大量无论是否具备条件的人都渴望高收入。工具和生产环境也不断演进,让不那么具备条件的人也可以进入该行业。

然而,颠覆和重塑的过程,总会遇到社会需求的天花板,但人才的供应实在是太多了,程序员终于开始互相倾轧,内卷越来越严重。

AI慢慢也会取代哪些低质量的程序员工种,然而在这之前,AI工程师圈子也已经出现内卷了。

如果你不希望为内卷化添砖加瓦,请不要简单的copy+paste,要用心思考,让作品真正有智慧,同时也考虑不要吃人。

Cloud Kitchen

由于疫情的关系,餐饮业遭受了不少的打击,反而觉得这两年的一个新的趋势值得关注一下,就是云厨房的概念了。

看了篇文章,说到Delivery Kitchen(简称DK)和Ghost Kitchen(简称GK)以及Cloud Kitchen(简称CK)的差别。

DK就是传统的品牌餐饮店提供外卖服务。GK就是一个中央厨房准备食物,还设置若干个到区的外卖点(厨房),由外卖点提供配送服务。GK仍然是有品牌的,而且一个GK做的食物也是比较固定的。

CK的物理模式与GK类似,但中央厨房能提供的餐食则由加盟方决定,也就是说可以退化成,中央厨房对于餐饮组是一个租赁场所和设备的方式,而且是multi-tenant的。按需付费。这样就极大量地利用了中央厨房的场地和设备,厨师更是可以多班倒,甚至个人租用。

还有几篇不一样的商业模式的描述,看完后再总结。

A.最原始的模式,厨房接受线上订单,做好食物后配送到顾客指定地点。这种模式下,只有两个主体,餐馆和顾客,只是餐馆退化成在线订单+厨房+配送的模式,并不具备堂食,也不需要顾客来店打包,因为没有店面,因此也不需要有停车场和其他顾客设施。

B.跟上一种的区别是,多个品牌餐馆共享同一厨房,可以提供多种口味的食品选择。这样在风味上可以满足周边居民的最大需要。

C.跟A的区别是,在配送之外,提供自提的选择,但订单还是线上下的单。顾客可以观看厨房的食品制作过程。单一的餐馆品牌,但可根据季节特点更换菜式。

D.Swiggy平台运作的模式。订单来自Swiggy平台,Swiggy提供一个有基础设施的大空间,提供水电燃气通风排水等。空间划分为若干个小厨房,由不同的餐馆品牌做菜。餐馆负责自己的菜单、厨房设备以及厨师员工等。配送则由Swiggy提供统一的配送服务。三个角色:Swiggy平台——餐馆——顾客

E.Zomato平台运作的模式。同样是三个角色:Zomato平台——餐馆——顾客。不同的地方是,餐馆只负责维护菜单,也就是给品牌。一般是一些知名餐馆,需要在不拓展分店/增加人手的情况下为其他区域的食客提供餐食。

F.Kitopi的模式。有很多角色,Kitopi平台——中央厨房——餐馆——配送——顾客。中央厨房和配送很可能是Kitopi平台的加盟方,而不是其自身的员工在处理。餐馆只负责制作食物。Kitopi及其加盟方采购食物,预处理后送至CK,由餐馆方制作,完成后由Kitopi的配送商进行配送。

Kitopi的模式更新潮一些,但如何控制好各个outsourcing的服务是一个难题。

https://limetray.com/blog/cloud-kitchen-business-model/