即刻App年轻人的同好社区
下载
App内打开
Songv
497关注1k被关注0夸夸
终身学习
Songv
04:08
在这个难且有趣的问题下,终于写完解字了
10
Songv
6天前
最近深有体感的几件事情:
1. 一个新技术在创新扩散的不同阶段都有不同的机会。
2. day0考虑竞争优势对于创业公司没有任何意义,可能更适合大厂团队。
3. "套壳"产品是跨越鸿沟的一种尝试,一个技术出现大量"套壳"是一种强烈市场信号。
00
Songv
21天前
一个人如果不用睡觉,24h都在用电脑,混社区。他到底会做些什么?
未来衡量一个公司/个人是否牛逼,最重要的一个指标可能是提出的能24h运行的任务数量。

这个真挺难的,想了很久我现在大概只想出两个。
00
Songv
2月前
朝闻道,午证之,夕死可矣。
00
Songv
3月前
Skill可能就是现阶段模型完成online learning最好的媒介。

试想现在需要爬虫一个电商网站5页的商品。你作为一个每天紧跟AI动向的Vibe boy,对WebArena排名倒背如流。心想这种小任务不是信手拈来,你扶了扶自己的刘海,唤来你最忠实的仆人cc。刷了5分钟美女短视频以后,切回来准备收收菜。结果一看,cc卡在首页连商品信息div都找不到,试了3次自己把任务关掉了。“哎,这xx公司又刷分了”,然后你不甘的开始 import requests。

进入正题,首先不得不承认现在在真实场景模型就是很难泛化。像这种长任务只能手把手先教模型一遍,你先打开浏览器去到xx网页,能顺利完成再进行下一步,现在截图或者拿回DOM解析xx div。一个能解析出来再解析下一个,再下滑拉更多的。这样来来回回能爬下来一页数据以后。就可以输入一个神奇的指令,“请把刚才你成功爬取一页的经验总结成一个skill存下来”。完成以后不出意外你就能成功的爬5页数据了。

以上我们半自动的帮助模型完成了一次无参数修改的学习。这里面人类参与了两个环节,一个是手把手传授经验,一个是触发skill总结。第二步看起来是能很好的自动化的,第一步就很难了。但已经是个不错的开始。

另外再YY一下,过了一到两年人类写了10w个有用的skill了,这些专家过程数据的价值非常大。以及skill的形态应该也可以是多种多样的,是一段文本还是一段代码,是一个LoRA Adapter,甚至是一些现在还比较难想象的东西。
01
Songv
8月前
对于做笔的人,人类要记录信息不是需求,在记录过程中犯了错误需要改才是需求。
当然如果能能更好的满足记录信息的需求也可以不要做笔了。
00
Songv
1年前
越焦虑越学习😭起床就开始
21
Songv
1年前
一个flag:在春节之前把这篇一直想写的数据系统新浪潮文章写完,也算为2024年的工作画上句号。

Songv: 为模型服务的数据系统正在从0开始发展: 1. 传统机器学习领域虽然已经发展了多年,但是由于算力和架构的限制,对数据的消耗能力非常有限。大模型时代pre training, post training 阶段数据的消费能力是非常惊人的。特别是在大家尝到1 epoch的甜头以后,对于数据的需求上涨了成千上万倍。 2. 如何在短时间内生产这么多数据来供应模型训练就成了很大的问题。其中最重要的是计算和存储。 先说计算,近几年如此大规模的计算需求基本发生在互联网公司的数据仓库链路中,承担ETL,数据建模,adhoc查询等需求。Spark也在这些IO密集型,重shuffle,aggregate的场景中胜出,所以生态基建和普及率是最高的。也正因为此成为了各家模型公司的主要数据计算引擎。但也明显有水土不服,早期版本无法使用GPU,pyspark 昂贵的序列化反序列化代价,虽然都已经补上,但异构集群困难的自定义调度,昂贵的容错代价等还是阻碍了它接管所有计算场景。 3. 一众像ray一样提供更底层任务/数据编排调度的框架弥补了Spark的不足,在这种map算子占绝大多数的轻分布式计算场景中获得了先机。我觉得ray.data被推崇的主要原因是开放了task的调度接口,以及放弃对job级别幂等性保障而全面转向到min batch带来更低的心里使用成本。 4. 但是年轻的ray.data问题还非常多,经常被我吐槽还是一个toy project。缝合的类型系统洞非常多,经常出现写出去读不回来的尴尬处境。一些为了避免OOM的提前资源切分又做的很粗,在追求性能的场景下成为累赘。聊胜于无的auto scale和backpressure机制等都让它看起来无法胜任超大型的任务。但也正是因为这个生态位的短缺,ray.data正被很多大模型公司赶着上架。

10
Songv
1年前
招1-2名实习生:
- 大模型公司数据团队,多模态(video/audio)方向
- 算法背景主要会来做 pretrain 数据实验和优化 pipeline labeling 模型效果相关工作
- 工程背景主要会来做分布式数据处理框架的优化以及数据 pipeline 的优化相关工作
- base 北京(暂不考虑远程),实习时间6个月及以上
- 希望 coding 基本功扎实,最好简历里能附带可以证明自己 coding 能力的信息

不想暴露个人信息没写公司名字,简历或者细节咨询都可以直接加我wx 或者发邮件:
- wx: Songvvvvvvvv
- gmail: miraculouscodersong@gmail.com
10
Songv
2年前
为模型服务的数据系统正在从0开始发展:
1. 传统机器学习领域虽然已经发展了多年,但是由于算力和架构的限制,对数据的消耗能力非常有限。大模型时代pre training, post training 阶段数据的消费能力是非常惊人的。特别是在大家尝到1 epoch的甜头以后,对于数据的需求上涨了成千上万倍。

2. 如何在短时间内生产这么多数据来供应模型训练就成了很大的问题。其中最重要的是计算和存储。
先说计算,近几年如此大规模的计算需求基本发生在互联网公司的数据仓库链路中,承担ETL,数据建模,adhoc查询等需求。Spark也在这些IO密集型,重shuffle,aggregate的场景中胜出,所以生态基建和普及率是最高的。也正因为此成为了各家模型公司的主要数据计算引擎。但也明显有水土不服,早期版本无法使用GPU,pyspark 昂贵的序列化反序列化代价,虽然都已经补上,但异构集群困难的自定义调度,昂贵的容错代价等还是阻碍了它接管所有计算场景。

3. 一众像ray一样提供更底层任务/数据编排调度的框架弥补了Spark的不足,在这种map算子占绝大多数的轻分布式计算场景中获得了先机。我觉得ray.data被推崇的主要原因是开放了task的调度接口,以及放弃对job级别幂等性保障而全面转向到min batch带来更低的心里使用成本。

4. 但是年轻的ray.data问题还非常多,经常被我吐槽还是一个toy project。缝合的类型系统洞非常多,经常出现写出去读不回来的尴尬处境。一些为了避免OOM的提前资源切分又做的很粗,在追求性能的场景下成为累赘。聊胜于无的auto scale和backpressure机制等都让它看起来无法胜任超大型的任务。但也正是因为这个生态位的短缺,ray.data正被很多大模型公司赶着上架。
03