电子商务网站建设配色,怎样给自己的网站做优化,html源码大全,ssh购物网站开发视频开篇 菩提修妙树#xff0c;接引证法源#xff0c;屠龙万仙阵#xff0c;玉虚祭封神。
混战是国内技术圈的常态#xff0c;在众仙跟风与追捧的大潮中#xff0c;如何看清方向至关重要#xff0c;决定谁最终将封神。
语言大模型(LLM)#xff0c;多模态(MM)#xff0c;…开篇 菩提修妙树接引证法源屠龙万仙阵玉虚祭封神。
混战是国内技术圈的常态在众仙跟风与追捧的大潮中如何看清方向至关重要决定谁最终将封神。
语言大模型(LLM)多模态(MM)RAG是当下的热词LLM将NLP带入到了2.0时代LLMMM将媒体带入到了2.0时代必然LLMMMRAG会将检索带入到2.0时代。
混迹于检索领域也有多年从2011年开始先后经历过大小的检索相关项目非线性编辑媒资库检索图片检索文本检索字幕自动生成语音识别文本匹配检索节目检索图片检索音频检索搜剧图片检索视频处理相册管理图片识别检索文本检索视频分析等项目对end to end的流程及优化技术还算了解对AI模型的ensemble使用及performence炼丹接触较多后面针对RAG做一些粗浅的分析欢迎指正和讨论勿喷~。
RAG的本质及作用
RAG Retrieval Augmented Generation本质呢其实是Generation这也定了个下文的基调也是下文分析的基础如何generate如何generate的更好谁有generate的能力。
提到RAG凭借着谷哥度娘的强大能力可能大多数人都能娓娓道来么么哒基于检索增强的内容生成对大模型有好处云云。深究一下在我看来RAG在generate有四方面的作用
协助不正经的LLM产生正经的结果采用多方证据或事实监督LLM防止它胡说八道LLM幻觉和LLM或推荐系统合作五五开共同构建历史性结果防止前后时间上的信息脱节因为LLM训练成本大不大可能频频用最新的样本训练和多模态合作补充优质信息到text2videotext2image等模型生成更符合物理世界的效果生成更丰富的内容long sequencecontext其实对LLM无益处越长attention消失越多占资源越多短紧凑的prompt更能产生优质回答或结果。Is Long Sequence All LLMs Need-Oh No 只是有时候迫不得已物理表示就是这样的叫我怎么办但我并不关心冗余的token要么你玩转高难度的attention pattern要么你用RAG给我精简要么你手工给我摘干净My God所以出现了各种利用windowlocaltrunksparsernn优化attention的方法本质都是不想用那么多attention不想和更多的token关联。起初我以为RAG通过查询向量数据库会增大sequence length但仔细想一下这只是表象RAG需要进一步压缩结果的表示空间这是兵家必争之地也是创造门槛的地方如果只玩vector distancevector similarity想必大家都会玩使得sequence length变短才算无上妙法。
RAG的技术依赖
首先说明一下向量数据库检索不是一个新鲜事物如果track了检索技术发展的整个历史脉络那么肯定不会因为它在LLM时代蹦出来而感到兴奋。 早在2000年百度就follow了谷歌的文本搜索技术构建大规模中文搜索引擎后来构建了大规模图片搜索引擎底层依赖的技术都是向量库索引与检索曾经研究热度很高经过20多年的发展向量embedding生成技术-向量检索与索引技术-大规模检索集群部署其实已经发展相当完善研究热度下降都在搞竞价排名~。
如果非要给retrieval一个蹭LLM热点的理由那么我希望它是“反哺”而不是“投怀”下文再续。
软件依赖
RAG的本质是generation但引起generation质变的是retrieval可能到了这里又可以娓娓道来一次又可以侃侃而谈一次又可以和谷哥度娘有一次亲密接触向量数据库嘛云云。概括起来最关键的软件依赖是向量数据库底层的东西
用于构建索引或进行检索的embedding是否具有简约性shorter dimension越短越好和鉴别性descrimitive构建索引的算法是否具有鉴别性是否能将多维空间可分做到最优构建索引可以理解成train和索引检索可以理解成inference的效率。构建索引一般是离线的数据量很大。构建索引也可能是增量online的数据量不大满足实时完善索引库的需求。索引检索需要照顾到multi request可以理解为batchsize不同batchsize的性能是不同的检索是典型的IO bound的场景。
硬件依赖
(1)通用计算支持能力
Is Vector Processing all RAGs Need? - Oh, No。
RAG中的R就是传统的R技术除了vector similarity计算1D计算外对如下技术的性能依赖性很强
graph/tree数据结构遍历与检索排序递归高并发度细粒度scalar/task操作随机存储与访问等
(2)memory hierachy
向量检索在memory的访问上可能受如下特性影响多级存储和cache同时保证hot-device间的访问或传输延时异构计算可能会比较适合
task粒度小指令散控制逻辑可能比较复杂code size可能更大数据操作粒度小非vector操作较多随机访存场景多并发度高索引巨大不能完全存于device memory和推荐系统的embedding table比较类似 (3)communication
不同于AI多机多卡间的传输数据类型不同sizegranularity
模型依赖
RAG与模型的关系需要特别强调一下团结拼搏共勉创优一直是一件好事情对于G(eneration)来说R(etrieval)“反哺”LLM生成更好的内容对于R(etrieval)来说G(eneration)投怀 向量检索生成更好的embedding representation未来的LLM多模态RAG的流程发展趋势大概就是如下 头部玩家的战场
如上所述得出如下结论
有媒体内容存货的容易进入战场检索和索引技术能力强大的容易进入战场性能突出的硬件芯片厂商容易进入战场啥都不行能给别人提供战场部署RG的容易进入战场大流量大日活大数据存储的厂商容易进入战场垂直领域可能机会较少或没必要借助RAG
硬件芯片厂商
国外nvidia gpuamd gpuintel cpu国内有前途很期待
云服务厂商
腾讯云阿里云
媒体运营商
爱奇艺腾讯视频视觉中国全景中国百度图片Get Image
老牌检索商
百度搜狗360
电商与推荐
京东阿里字节
更多的产品形态预测
媒体方例如get image的AI服务开发RAG接口向多模态生产方提供内容输出服务抱歉除了收正经版权费我也要分AIGC一杯羹电商生成更真实的店家展示图片AI检索Legacy检索增强检索效果实时推荐系统
参考
推荐的其他阅读材料Retrieval-Augmented Generation for Large Language Models: A Survey
