wwwgoubuli
1个月前
很久没聊 RAG 了,随便说点。 RAG 里的分块技术,某种程度上看起来确实显得越来越过时了。 不是说完全抛弃不要,只是分块带来的弊端越来越明显,多高超的技巧都救不回来“信息完整度”的缺失。 当然总有上下文窗口不够的情况,完整的大型文档丢进去,确实吃不下怎么办? 凉拌。 你就用最简单粗暴的方法,按长度来,丢过去做点预处理,总结,然后差不多行了。 这种方法下,切割的问题依然存在,会有把完整信息切错乱,让上下文不精准的可能。 但首先,影响真的不大。这种方法会有信息折损,但不会比你以前精妙的各种分块技术,各种组合,效果差到哪里去。 不同的场景下会有差别,肯定有赶不上传统方案的时候,但——无伤大雅。 以前的 RAG 到底做到了个什么水准,那么多雕花,最后的成果如何,大家心里都有数。 其次,你要相信今天的模型。 论聪明程度,这个意义不大。但论长上下文的处理,对超长文本的高维关系分析,人类已经连 LLM 的尾灯都看不到了。 不会差到哪里去的。 节省下来的时间力气,都足以在其他方面做很多新的探索。 比如 PDF 不做 OCR,不分块,而是直接转图片给多模态。 也不是说传统 chunk 技术就有什么问题,那里面其实已经诞生了很多可靠的实践,可以对不少效果兜底。但大多数情况下,做的就还是雕花的工作。 原始数据有多脏,各种格式有多奇葩,各位应该多少有耳闻。 雕花的事,少干点,有这技术就行,没必要天天弄。 你看 Apple 刚 WWDC 上端出来的顶级雕花,真的一言难尽。
宝玉
1个月前
不知道你看到图下面这张图的 3 种模式有何感想,我只想说现在你用 AI 写代码,千万不要用第一和第三种模式,只能采用第二种模式! Vibe Coding 的最佳实践仍然是 Agile 的版本迭代模式,而不是瀑布模型那样的一次性完成一个无法运行的半成品,再,像图中第三种先做个不伦不类的东西出来,想优化成真正的产品,是不太现实,即使对于专业程序员来说也会相当有挑战,否则程序员们也不会那么热衷于“推翻重写”! 举个例子,比如你要做一个 ERP 系统,你把完整需求一次性发给 Claude Code,也很专业的要它拆分成模块,再让它按照模块一个个去开发(像图2那样),但这样做出来的东西也基本上是不可控的,做出来的东西基本上无法满足需求的甚至无法运行的。因为无论是 AI 还是人类,都无法掌控这么多模块的协作,更何况还要保障每一个模块自身的稳定性。 那么更好的做法是什么呢? 还是要像图1 中 Agile 的做法那样——每次做一个完整的能稳定运行的版本出来。 距离来说,你要做一个 ERP 系统,分成若干版本来迭代,每一个版本都是可以独立稳定运行的,举例来说(仅供参考): - v0.1: 一个可以运行的 Nextjs/TanStack 程序,有欢迎页面,可以跳转 - v0.1: 实现 users 相关数据库访问功能,在 mysql 中创建 users 表,实现 users 表的读写功能,添加读写功能的测试代码 - v0.2: 实现用户注册的网页,连接 users 相关数据库方法,能写入注册用户信息到数据库 - v0.3: 实现用户登录、注销的网页功能 - v0.4: 实现简单的 dashboard 页面 - v0.5: 实现 products 相关数据库访问功能,写功能代码和测试 - v0.6: 实现 products 在 dashboard 的管理页面,能显示列表 - v0.7: 实现 products 的添加、编辑和删除功能 。。。 这里就不一一列举,核心还是每一个版本功能是完整的,可以独立运行的,测试稳定后再下一个模块。 这样你基本可以保证你做出来的是可以掌控的,而不是一次性做出来一个几乎无法维护的庞大半成品。