关于AIGC人工智能、思维方式、知识拓展，能力提升等。投稿/合作： @inside1024_bot
AIGC 领域的最新工具、开源项目以及行业大事件
AIGC 领域的最新工具、开源项目以及行业大事件
刚刚用了比较多的篇幅来讲Cursor，主要是想说明一个以后我们可能会经常看到的现象：如果你的应用使用今天的模型勉强能跑，那么下一代模型可能会让它的体验有质的飞跃。（这个观点来自Y Combinator的创始人Paul Graham，也就是《黑客与画家》的作者) 就像Cursor一样，去年用GPT-4的时候，只是勉强感觉这个模式可能是work的，效果很一般，但今年有了新一代模型的加持后，体验上犹如跨越了一道鸿沟，从barely works变成了works really well。
过去的一两年里，我们总听到大家在谈AI Native应用，那AI Native应用的一个基本特点是什么呢？模型越弱，应用体验就越差；反之，模型越强，应用体验就越好。如果一个应用的体验与模型的水平关系不太大，那可能说明这个应用还不算是真正的AI Native应用，而Cursor就是一个非常典型的AI Native应用。那么我们来思考一个很有意思的问题：如果我是Cursor的创始人，当我看到今天Claude 3.5 Sonnet的表现之后，才去投入精力做Cursor，还来得及吗？我的答案是No，已经太晚了。
这么说可能有点抽象，我们来打个比方：假如我是一家公司的创始人，我在招人的时候发现一个年轻人很有潜力，但其他公司并没有识别出他的潜力，目前他也还没做出什么成绩，我当时想，“目前我们公司需要的是能干活的人，他经验太少，我等他成长起来再联系”。三年之后，他已经在行业内赫赫有名，我再去联系他时，发现很多家公司都在开高薪挖他，我已经没有机会了。
在做AI Native应用时，几乎面临一样的情况。当我们发现模型在某方面的潜力有一些苗头时，就应该准备入场了。一开始用当前的模型验证时，可能会发现体验没那么好，这很正常。当我们的应用研发得差不多的时候，可能新的模型刚好出来，我们有可能会惊喜地发现，应用体验有了质的提升。那如果提升不太大怎么办呢，那就继续再等一等。当然，要超前，但也不能太超前，否则可能还没等到新模型出来就撑不下去了。
总而言之，见微知著，未雨绸缪，剩下的，就交给时间。
过去的一两年里，我们总听到大家在谈AI Native应用，那AI Native应用的一个基本特点是什么呢？模型越弱，应用体验就越差；反之，模型越强，应用体验就越好。如果一个应用的体验与模型的水平关系不太大，那可能说明这个应用还不算是真正的AI Native应用，而Cursor就是一个非常典型的AI Native应用。那么我们来思考一个很有意思的问题：如果我是Cursor的创始人，当我看到今天Claude 3.5 Sonnet的表现之后，才去投入精力做Cursor，还来得及吗？我的答案是No，已经太晚了。
这么说可能有点抽象，我们来打个比方：假如我是一家公司的创始人，我在招人的时候发现一个年轻人很有潜力，但其他公司并没有识别出他的潜力，目前他也还没做出什么成绩，我当时想，“目前我们公司需要的是能干活的人，他经验太少，我等他成长起来再联系”。三年之后，他已经在行业内赫赫有名，我再去联系他时，发现很多家公司都在开高薪挖他，我已经没有机会了。
在做AI Native应用时，几乎面临一样的情况。当我们发现模型在某方面的潜力有一些苗头时，就应该准备入场了。一开始用当前的模型验证时，可能会发现体验没那么好，这很正常。当我们的应用研发得差不多的时候，可能新的模型刚好出来，我们有可能会惊喜地发现，应用体验有了质的提升。那如果提升不太大怎么办呢，那就继续再等一等。当然，要超前，但也不能太超前，否则可能还没等到新模型出来就撑不下去了。
总而言之，见微知著，未雨绸缪，剩下的，就交给时间。
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正被很多大模型公司赶着上架。
