#上下文窗口

avatar
wwwgoubuli
3周前
很久没聊 RAG 了，随便说点。 RAG 里的分块技术，某种程度上看起来确实显得越来越过时了。 不是说完全抛弃不要，只是分块带来的弊端越来越明显，多高超的技巧都救不回来“信息完整度”的缺失。 当然总有上下文窗口不够的情况，完整的大型文档丢进去，确实吃不下怎么办？ 凉拌。 你就用最简单粗暴的方法，按长度来，丢过去做点预处理，总结，然后差不多行了。 这种方法下，切割的问题依然存在，会有把完整信息切错乱，让上下文不精准的可能。 但首先，影响真的不大。这种方法会有信息折损，但不会比你以前精妙的各种分块技术，各种组合，效果差到哪里去。 不同的场景下会有差别，肯定有赶不上传统方案的时候，但——无伤大雅。 以前的 RAG 到底做到了个什么水准，那么多雕花，最后的成果如何，大家心里都有数。 其次，你要相信今天的模型。 论聪明程度，这个意义不大。但论长上下文的处理，对超长文本的高维关系分析，人类已经连 LLM 的尾灯都看不到了。 不会差到哪里去的。 节省下来的时间力气，都足以在其他方面做很多新的探索。 比如 PDF 不做 OCR，不分块，而是直接转图片给多模态。 也不是说传统 chunk 技术就有什么问题，那里面其实已经诞生了很多可靠的实践，可以对不少效果兜底。但大多数情况下，做的就还是雕花的工作。 原始数据有多脏，各种格式有多奇葩，各位应该多少有耳闻。 雕花的事，少干点，有这技术就行，没必要天天弄。 你看 Apple 刚 WWDC 上端出来的顶级雕花，真的一言难尽。
#RAG #分块技术 #信息完整度 #上下文窗口 #预处理 #切割问题
avatar
宝玉
5个月前
问：模型支持的TOKEN数量是模型本身的限制还是调用模型的程序限制的呢？ 答：模型会有上下文窗口长度限制，AI聊天应用也会有会话长度限制。 举例来说你的模型最大上下文窗口长度限制是 128K，但是通常应用程序不会让你输入的内容到128K，可能输入内容最多16K就不让你输入了，因为这个上下文窗口长度是针对输入和输出加起来的长度，所以要留一些空间给输出。 另外输入内容越长，模型生成的质量会下降，成本也会增加很多，所以应用要限制最大输入的长度。
#模型 #TOKEN数量 #限制 #上下文窗口 #AI聊天应用 #会话长度 #输入内容 #生成质量