关于AIGC人工智能、思维方式、知识拓展，能力提升等。投稿/合作： @inside1024_bot
AIGC 领域的最新工具、开源项目以及行业大事件
AIGC 领域的最新工具、开源项目以及行业大事件
Cursor最早进入我的视野是在2023年4月份左右，当时Cursor刚推出不久，底层用的是GPT-4模型，现在饱受好评的Chat功能，当时其实已经具备了，但是我当时体验完之后，效果并不是很惊艳。用它来写点玩具代码片段是可以的，但当我尝试用它去给稍微大点的项目做新功能的开发时，就发现模型的能力严重限制了它。主要是两个问题，一是上下文不够长，当时它使用的是8K上下文的GPT-4，这就决定了它能够理解的背景信息非常有限，很难在这么短的上下文里去塞给它足够的代码和文档；二是GPT-4本身的幻觉比较严重，当你让它帮你写代码时，经常出现Bug，或者用了一些根本不存在的库或方法，导致要花很多精力去检查、修改它写的代码，反而可能拖慢了效率。
然而，仅仅是升级了一个模型，一切都变了。今年7月21日，Anthropic发布了Claude 3.5 Sonnet，其编码能力大幅提升，并拥有200K长度的上下文。当Cursor把底层依赖的模型换到了3.5 Sonnet之后，体验有了质的飞跃。我们对比一下之前影响其体验的两大问题：首先，上下文长度从8K提升到200K，实现了数量级的飞跃，可以在如此大的上下文里塞下数十个代码文件及文档，让模型充分理解项目背景、代码结构和编码风格；其次，Claude 3.5 Sonnet在编码时的幻觉惊人地少，不知Anthropic使用了什么技巧。大多数情况下，它写出的代码无需任何修改即可运行，我猜这也是Anthropic在其官方Claude应用里自信地开放Artifacts功能的原因——它在Artifacts中写出的网页，在大多数情况下可以一次性跑起来，没有任何语法错误。当这两点问题都得到极大改善后，神奇的现象发生了：以前我们使用AI编码时，几乎是抱着非常提防的低预期心态，但现在，我们可以很自信地让Claude发挥作用，我只需要提供必要的引导即可。
他们新开了一个 Civita Green 站点，里面只有安全的图片和模型，没有色情内容。
我上班找模型终于不用偷偷摸摸了。
同样在摆脱了色情和重口味内容后，他们也将开始更加大脚步推进商业化的进度。
这里访问：https://civitai.green/models
做了个Cursor的实操演示视频。
作为一个确实不太懂代码，只自己看书学过点python皮毛的人。向你演示完全使用自然语言，一行代码不写、不改也确实能制作出一些简单的应用。
FireCrawl可以将整个网站转换为可用于 LLM 的 Markdown 或结构化数据。使用单个 API 进行抓取、抓取和提取。
说白了就是将一个 URL 转换为 Markdown，很方便的和各种大模型进行对接，而且还支持各种各样的 SDK。
目前GitHub Stars 量已经突破 11K。
不想自己部署的话，可以直接使用它们的在线服务，直接转Markdown 格式，效果还不错。
开源地址：https://github.com/mendableai/firecrawl
为模型服务的数据系统正在从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正被很多大模型公司赶着上架。
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正被很多大模型公司赶着上架。
