怎么样做网站赚钱,网站开发需要的技术的流程,快速排名点击工具,首钢建设网站01
长文本与RAG通用对比
准确率#xff1a;通常情况下长文本优于RAG
长文本#xff1a;可更加综合的去分析所有相关的内容#xff0c;提取相关数字#xff0c;生成图表#xff0c;效果尚可。RAG#xff1a;更适合找到一段或者是几段可能相关的段落。如果希望大模型能够…01
长文本与RAG通用对比
准确率通常情况下长文本优于RAG
长文本可更加综合的去分析所有相关的内容提取相关数字生成图表效果尚可。RAG更适合找到一段或者是几段可能相关的段落。如果希望大模型能够对问题有全局的认识比较困难。如根据上市公司的2020年财务报表绘制图表直接用RAG可能效果就不是很好。
长文本在准确性上表现好的原因以及长度与准确性选择
长文本处理之后会做对齐和专门的Benchmark测试调整。比如说之前的大海捞针以及腾讯的数星星的Benchmark这些是更难一些要求不仅要找到相关的位置还得把具体的数字给出来。现在也出现了一些新的关于长文本模型的bench mark比如legal bench它就是专门测长文本模型的retrieval 和reasoning 的能力。然后如果大家对这个方面的推理有兴趣的话可以去搜最近有一些论文是比较相关的。从实际应用出发其实几十 k token的输入量量并不算很多现在一般的大语言模型都能满足。用额外的辅助就有点像为了10本书去搞一个图书馆可能不太需要。但是如果对这 10 本书有什么特殊的需求没准也需要搞一个图书馆需要搞一个机器人去帮你拿书。比如说是10本某个伟人的手记。就是这个取决于具体的情况。在现实情况中只有十本书的情况毕竟不多。在数据量较大的场景RAG还是非常适合。而且基准是在变化趋势来看大语言模型的文本的 context window会变得越来越长的。如果它普遍的都变得特别长如果推理的成本做了很多优化能够显著的降低那可能就是这么小的文本可能真的不需要去再费功夫给它搞一个数据库去做这个 efficient retrieval靠模型本身就能高效地把这些信息全部扫一遍了。对于效果前面讲的大海捞针都是在几百万的 token 这个量级下去讲的如果几十k可能就不算大海捞针在这个量级上把注意力集中到用户所问的那些问题上不是一个特别难的事情从观测用户使用的情况来看单纯用大模型效果已经很好了。
长度与性能关系RAG线性长文本受限因素更多
长文本受限的因素比较多。比如并发性能会随着上下文长度的增加反比下降预填充的延迟也是会随上下文长度的增长平方级别的增长解码延迟和上下文切换的开销也是会线性的增加最成瓶颈的是预填充延迟因为它是会平方级别的增长这也是构成目前长上下文推理的主要难度。RAG线性变化为主。
展开看上下文长度对长文本成本、延迟的影响
目前主流的长文本推理是根据 token 数去计算最后的价格所以价格看起来是线性的关系。但是背后的长文本模型实际推理成本受很多因素影响。需要有一个推理集群然后做优化。Context window越大除了成本会增长之外首 token 延迟会显著的增加。比如128K的模型如果全用满需要大概几十秒钟的时间才能返回首token。部分厂商提供了更加长上下文的模型。比如月之暗面之前有一个 200 万字的模型包括像Claude也有一个更长的模型。这些模型一次推理可能延迟需要等几分钟。在很多目前的场景下这样的延迟导致模型不能投入实际使用。所以说主要是推理成本和首token的延迟这两个问题以及再把长上下文在进一步扩大的时候还会遇到很多技术上的困难在很多场景下动辄可能需要数据是比如说几GB甚至有更大场景用长上下文就不是特别好的选择。
上下文长度在长文本与RAG的边界
有一些数值的参考坐标如果讲分chunk大概就是500 1000 1500甚至两三千token大概这个量级。所以如果是500个token不需要搜索搜索里边的最小单元都比这个大。几十 k 处在中间状态大语言模型 context window可能是几十 k 这个量级16K、 64K 或者更多的。embedding 模型如果要做搜索的话需要能够把这一段片段塞到embedding 模型的窗口里边。之前的embedding 模型跟大语言模型的架构有一些不同然后现在有一些embedding模型直接用大语言模型的架构去实现。量级大概也就是典型的像 16K context window 的然后长一点儿的比如有64K但没有太长的。文本如果比较多就适合用知识库的方式管理。海量的文本做分段落每个段落用embedding提取向量存到向量数据库里。
长文本如何优化First Token延迟问题
工程层面比如说Flash attention。硬件层面比如说英伟达有一些新的技术。算法的层面用的比较多的是KV cache。可以把一些共同的长上下文先预处理出来然后当需要用的时候就直接调用把 Preview 的时间就给省掉了但是额外需要付出存储的代价以及维护存储时间的开销。
RAG的成本原理
输入阶段输入内容的大小、类型会有很大差别。在RAG环节也会分离线和在线。离线是预先所有内容用Embedding模型等处理一边切分然后生成向量入库甚至在中间还可以做数据挖掘提取各种标签用于搜索中做过滤。在这其中也可以将总结同步生成出来是否要生成总结以及是否伴随细节都会对成本直接影响。入库成本的天花板用小的Embedding模型把所有内容刷一遍然后再用大模型把内容提取标签或总结所产生的成本基本是一次性入库成本的天花板。输出阶段Serving每次的 serving 的服务成本取决于retrieve 出来多少。这和业务逻辑设计的有关可以是TOP3或者TOP5。然后取这里边的乘积比如说五个片段每一个片段的平均长度是 1, 000 个tokens那每一个平均的 context 长度就已经是 5, 000 个tokens。再加上用户的query一般情况下长度还是远小于长文本方案的长度按极限来说长文本是每次付出两个 milliontoken 的推理成本那 RAG 的方案可能就是 5, 000 个token每次的推理成本大概是这么一个感觉但还要考虑到 RAG 有一次性的入库成本包括除了入库之外存储还有成本但是存储成本相对低。其他成本需要维护data pipelines即需要长期的维护数据。做数据更新即增删改查还有很多工程成本。总体分配推理成本不一定是最大的部分如果是使用量非常大的服务推理可能是成本大头。但如果使用量很小比如说企业知识库文档量极多但大多数文档的使用频率非常低。那一次性入库和存储成本变成主要部分。
长文本的降本方向
降本方面有一篇paper就是关于那个长文的推理的一个总结来自于付瑶的博客的最新的一篇从四个角度去分析了目前有可能去降低成本的这个方向。包括https://character.AI他们最近也发了一篇博客就介绍了他们在这方面的一些努力。
具体的选择比较需要看场景
单纯从学术上长文本跟RAG有非常大的差别没有太多互相之间比较的点。很多指标虽然是同样的指标但是要求千差万别。在AI场景里面需要根据不同的场景分析特点。需要从业务实际的情况去考虑支持的业务的性质是什么所需要工具有什么主要特点比如关注延迟关注整个系统的运维成本、机器成本还是关注用户体验比如问答愿意花 10 美金只要这个问答能答对就有价值。长文本是大语言模型能力增长非常好的体现但是大语言模型肯定不只有这一个能力那么即便是短文本里边比如 reasoning 能力数理逻辑的感知在实际业务中非常重要然后 RAG虽然说是叫 retrieval augmented generation其实大家主要的关注点是在retrieval上功能类似于搜索。现在在新的AI体系下包括新的技术软件的基建包括像向量数据库大语言模型也是数据处理或者说数据挖掘的工具之一。以上重新组装成了一套搜索的系统包括数据流转和处理系统然后这套系统再去支撑业务在应用中是否合适在不同的业务下应该有什么样的变化应该选用什么样的变种应该根据实际去判定。
02
部署落地与权限安全差别
RAG部署有许多系统化优化点
RAG分化程度非常高因为RAG是许多东西的组成类似大数据生态里边有非常多的环节从数据抓取、数据清洗、数据挖掘然后预处理再经过模型分析比如说embedding模型生成向量然后再做数据的持久化serving stack就是怎么能够非常 efficiently 把东西检索出来。然后到检索层面上整个serving链路从某个 query 的语义识别到解析可能要路由到不同的业务逻辑上。有的是用向量检索有的直接通过规则有的通过大语言模型进行回答。然后最后再加一些guardrails比如说要检查一下这个是否符合价值观或者不安全的内容然后再去作为回答的后处理。各个环节基本上把数据基础软件的环节都涉及到了还涉及到模型的hostingmachine learning infra stack 里边的东西包括部署到生产环境之中要有 continuous evaluation要有监控 observability 涉及到的方面会非常多。所以在实际部署的时候客户有的是自研一部分然后用一部分开源的组件有的用第三方的服务商所提供的组件也有全部交给集成商去做、交给云厂去做的还有用self service 方式就是用一个定制化程度不高但是前前后后全都给做了公开服务的套件这里边的情况比较复杂。采用什么方法取决于客户业务是什么样的诉求尤其是对定制化对功能有没有客户自己特殊的要求等等造成解决方式的多样性和可选方案的多样性。
长文本大模型的部署相对简单
大模型的部署要么用开放的API服务比如说月之暗面提供的公有云上的服务要么客户自己私有化部署的开源方案或者大模型厂商提供的私有部署方案主要是这两种情况。就从部署技术而言能解决这个问题的人大部分都是大的云厂和大模型公司本身或者有一些开源项目如vLLM 能做一些inference的优化。这一块的分化程度是比较低的。长文本做得比较好的一些模型厂商一般提供的都是闭源模型。可能因为对于长文本模型来说部署和推理中间牵扯到比较复杂现在还没有一个特别好的开源长文本模型支持用户的本地化部署。
RAG可以做到很高精度的权限划分
权限可以分为大权限和小权限。大权限比如数据根本不能上网需要放在本地一体化的硬件数据中或者说数据可以联网但是只能在存储在客户私有的IDC 里但IDC不能连接公有云或者不能使用公有云厂提供的第一方服务。小权限不限制云服务使用方式但是需要保证不同部门不能访问他部门内限制数据。从大权限到小权限中间是连续的光谱采用RAG的方案只要保证基础软件包括machine learningstack 的组装都符合对应的权限的需求即可。保证权限的统一性。比如有不能联网的要求所有stack的行为就必须得在盒子里边发生或者说是我都在公有云上但是不同用户能访问什么要被 stack 里的每一个步骤里边都要遵守。有的客户数据的某些处理可以是上网的某些处理是必须在私有环境中进行那么这种情况会稍微复杂一点需要根据场景定制化一个方案。但一般来说这种方案都是可以实施的因为在每一个成熟的组件里边比如向量数据库像Zilliz其实支持了各种部署方式从私有的到公有的有的用开源有的用商业化服务只要保证每一个组件都能够满足整条业务链路对于前线的要求就可以了。
长文本在权限上更取决于数据架构设计
在权限处理上类似问题在没有大模型的时候也会遇到跟具体用什么样的模型关联不是特别大因为模型技术并不涉及这方面的细节主要还是数据架构设计和权限管理。这个取决于各家的标准。
企业落地RAG时克服冷启动、降低落地难度的方法
落地里边是有很多挑战的尤其对于传统企业没有成熟的AI技术栈又有非常复杂的业务诉求很难通过通用的方案去解决。这个现状造成落地具有很大挑战但这也是商业上的机会。Zilliz选择的方式一方面先做好基础设施同时跟生态比如开源的做逻辑串联或者做某一个方面比如像知识图谱或者 evaluation 这些项目做集成、做合作然后给大家提供更多的工具选择另外一方面也跟商业项目形成伙伴这里边有很多落地的咨询服务、定制化服务甚至本地部署解决数据的管理和安全问题。这些需要一些有服务能力的商业项目去做实施Zilliz也选择合作。需要整个生态包括大模型厂商应用厂商、咨询能力的公司一起构建开发者或者说服务矩阵通过多层的能力去解决客户的实际问题。
月之暗面在长文本使用中的配套方案
目前月之暗面和谷歌的Gemini现在都有上线长上下文缓存的服务给开发者。月之暗面之前在founder park 的 AGI Playground 上面做了发布现在也可以直接使用。以客服群里的文档机器人举例其实只有 32K 的长度但每小时有 20 次提问这其实是很容易达到的。只要群里面随便跟同这个文档机器人聊天几句就能达收支平衡就是推理的开销就超过存储的开销。如果是一些爆款应用比如说之前很火的M.Riddle、哄哄模拟器、拜年模拟器等可能在短时间内比如说几个小时内有一个瞬时的爆发性流量用这种方法也是非常的合适的。这个是目前对开发者来说最容易接触到的推理优化方案。之前月之暗面也发了一篇叫mooncake的论文具体阐述了 KV cache的推理集群是如何优化的并且这个优化方案已经在Kimi智能助手上线了相当长的时间。上了这个方案之后让 Kimi 智能助手每天能够处理的推理量增加了80%。
03
场景客服与Sales Agent
客服与Sales Agent选择取决于知识库复杂度
场景所需要的文档量级会直接影响选择例如几千字或者几万字规模适合长文本模型上下文缓存的方式不仅能优化价格还可以优化First Token的延迟。例如营销群里的段问题多数已经不需要人工介入大模型能回答得很好并且延迟可以控制在2-3秒。例如游戏客服的文档在几万字也符合上面的要求。还有一些特定场景请求比较频繁共同的上下文比较集中例如AI翻译、针对AI文档的回答等也适合长文本。但到了更加复杂的场景例如大型呼叫中心或者作业辅导就需要长文本RAG如果长度特别长那可能就需要主要依靠RAG。
长文本在相对简单知识库时候的优势
单纯从开发角度来说只用长文本会有优势开发比较简单基本上不需要复杂的机构或者使用其他的第三方工具只需要把文本转化成text然后全部给大模型的message里即可这个不在于使用效果有多大的差别而是对于开发者的负担比较小。如果用户侧问经常问一些刁钻的问题比如模型的推理价格报表或一些比较复杂的问题比如用 a 模型相较于 b 模型能省多少钱可能这个时候用长文本是一个比较合适的选择。还是要看具体场景。可能有些场景比如说简单的客服RAG和长上下文它的效果都可以都可以满足日常的需求。
对准确率要求高的场景如何选择
要看具体的场景需要开发人员去测一下。一般来说RAG肯定是相对多一些准确度的损耗。因为最后还是要把过RAG的信息给到大模型RAG本身的准确度损耗大模型的准确度损耗 vs 只有大模型的准确度损耗。但也要具体看用的是什么样的长上下文的模型部分情况也会存在lost in middle 的现象。如果能更精准的把相关内容给到模型那模型回答的是一定更准的因为噪音少了。
04
场景AI Coding
AI Coding如何选择
在很长一段时间内这两种技术都是需要去搭配使用的。产品经理在做技术选型的时候需要更深入的了解这两个技术去设计场景。在AI coding细分赛道已经变得越来越专业对模型的要求也越来越高。对于场景如何去获取信息要求也越来越高。比如GitHub推出了Github copilot workspace这是更加专业的场景。包括字节、腾讯和Google 都推出浏览器VScode 的插件甚至一些IDE能力。这样他们可以更加全面的做代码推理不仅仅是代码补全还包括一跨文档的能力比如在一处进行修改能够帮助把相关联的地方全部都做修改但这也需要更加复杂的产品设计能力。现在什么代码放到Context Window什么放到RAG里没有Best Practise。这类工作具体先要划分出核心逻辑比如用 MVC(model-view-controller)的话是model 层面的逻辑然后把view层面的逻辑给弱化除非具体问到的时候再把它们加进来。需要要看具体的项目去做具体调整。
业务场景看代码库大小
如果是前端代码可能很多都是跟业务没什么关系的代码可能就不那么的关键。如果是一个智能合约其核心逻辑非常短百行之内就能把核心的逻辑描述清楚。产品类型也非常有关。像一些dify的代码大概在几十行就把核心的逻辑表述出来。但比如游戏代码大概一大半的代码是引擎。真正涉及到核心逻辑的代码会很分散这种的实现就会更困难。
1m Context Windown对于大部分科技公司还不够用
百万代码量可能是一个很小的代码库千万代码量可能也是小代码库。一个项目稍微复杂点的就能做到百万的量级的代码量。像 Google这样大的体量2015 年有 20 亿行一行一般几十个token所以代码量在稍微大一点的软件工程的场景下时巨大的。如果能够限定问题所在的代码范围比如说某些文件夹那么代码量并不大一个文件夹里面的几个files可能 5, 000 行什么1万行就到头然后几十个token一行总计大概在几十万token。稍微上体量的中等公司根据业务的情况也有可能达到千万甚至更多的代码行数这样token 数也要上亿了。
对于代码库大的企业可以不用RAG吗
可以不用RAG但是需要有办法把代码筛选出来。RAG背后是向量向量搜索是基于语义的 similarity 去搜对代码的搜索除了语义还能利用其他信息。因为代码是有结构的对于能够解析的结构就不一定需要全用Vector similarity 去search。比如可以根据项目名称模块名称先去找到大概的范围当然这个范围有多大的代码量可能预先并不不知道如果量特别大可以结合长文本。如果量大且对成本的考量比较敏感可以再用向量搜索的方式去做一些切块然后把里边的部分代码通过语义的 similarity 去搜出来甚至可以结合标签根据标签的similarity或者根据大语言模型线下给这一部分代码做的总结去搜索。这里边有很多工程化方法。
客户如何针对代码进行结构解析和工程优化
通用代码结构解析的能够做到的程度比如Java 的项目因为 Java 的语法是相对标准所以能够解析出来它的类function的结构然后建立结构化树该树用来做从项目名到模块的路由。这部分是有通用性的因为各家用的Java的项目结构大体都是一样甚至有一些框架带有一定结构然后这个框架是通用的。不能通用的部分比如某个模块是由某个团队管理该团队要负责给该模块写说明因为代码里几乎找不出来它跟业务逻辑之间的关系。这一段代码具体是给哪个模块给哪个业务里边的哪个功能的如果没有历史背景只有维护这个东西的团队知道甚至维护的团队时间久了也不知道了。企业实际应用中会遇到这类 “三不管”代码是个比较现实的问题。这个现实问题就很难用通用的方法去解可能有的甚至要通过组织架构的方式去解这些就需要做很多定制化的东西。一些开源的项目会相对容易host 在 GitHub 上各方面的文档的read me各种描述软件比如说各种 function 的使用文档都是内嵌在 code 里边有了这些前置条件这属于比较容易触达到这个问题的核心相对好用通用的办法去解决。但如果是个对知识产权有很强的诉求的公司组织架构非常复杂代码的管理也比较的粗糙然后文档什么的建设都不健全如果是这样的场景解决起来就非常困难。
05
场景搜索
搜索场景的选择
这种选择大概率是出于成本等的考量不能承担太高的推理成本的。因为搜索是商业服务而不是慈善业务。所以如果每一个免费用户都花几美金的成本去承担query的成本这肯定是付不起的。所以背后一定是做了大量的优化Perplexity 宣称做了一些小一点的模型并单独为这个场景做了模型优化这样它能够把成本降下来。大家会觉得RAG 就是成本很低但量大情况也不一定。如果使用的体量非常大的话向量数据库本身的存储成本还有进行服务 的serving 成本也是很高也需要做一些优化。比如Zilliz最近在做的冷热存储的切换将价值不高、访问频次不高的数据放到冷存储里以节省成本。如果用 RAG 都有成本的问题那全都用大语言模型去付出高昂的推理成本应该说在这些商业的产品里边一般是不现实的。甚至刚才所说的coding场景成本下降都不一定很明显。举之前有客户疑问Github Copilot 做的不错是否拿长文本做的“我把整个项目给丢进去了然后我去问的时候他这个回答的效果就很好就是说他好像方方面面都照顾到了那不就是长文本吗”。如果一个建库就需要超过 10 分钟背后大概率是离线做了索引。当搜的时候每一个 query的延迟非常短瞬间搜出来了采用的技术一定不是长文本 是结合了RAG的。Github Copilot的建库时间较长单次搜索延迟很短应该是采用了RAG的方案。
AI搜索的语义提取颗粒度
分两部分第一部分是做语义检索语义检索本质上是粗颗粒度的模糊的搜索把这一篇网页分成 50 个片段每个片段 500 个字然后整个片段就生成一个向量然后向量代表了这个网页抽象语义或者是它的一个指纹或表征这是一种抽取的方式它并没有逻辑的关系。至于向量怎么生成出来拿深度神经网络模型训出来的然后对齐了一些业务场景对模型的需求就是语义相似的东西就给把这个向量给分布到相似的空间里边的位置上然后这是一部分的抽取。另外一部分就是给提取出来的东西标签、关键字或者根据它的内容提出来一些描述性的标签。这个一般也是通过模型来实现有的是用大语言模型做的有的是专有模型来做。这两种情况在互联网公司因为技术能力会比较强一般都是存在的。
类似百度和Google已经采用AI搜索还是会偏传统更多采用倒排
是用到向量检索去检索到一些内容然后再搭配关键字的倒排和一些其他标签。Web 搜索里叫token base retrieve把那些 token 相关的东西都去除。然后对所有这些拿出来的东西放在一起进行 merge这个merge 是根据业务和渠道的特点做重排序。然后重排序里边像互联网的话业务是占主流的即要达到什么商业目的重排序要与根据商业目的对齐。对企业知识库谈不上商业考量的场景更多是根据问答质量去考量。
现在有一些做AI搜索公司宣称壁垒是靠去做缓存到的网页的语义索引来积累语义索引库。按照合格逻辑对于百度和谷歌的工作来讲它其实已经建立了全网网页细粒度的索引库的话那么对于 AI 搜索的创业公司大厂还是有领先优势的吗
不好判断。创业公司可能在商业层面上比如说他根据场景做的一些定制或者说从流量获取就是纯商业运营的角度上有自己的独特玩法。具体的价值不一定全是在技术层面上。从技术层面上也很难讲。因为不知道创业公司具体做的事情是什么可能他们有自己独特的东西比如说根据一些具体场景去训的模型比如说对二次元的内容专门做了优化什么。存在大一点体量公司所忽视的细分场景这些都有可能成为创业公司的机会。
06
其他场景
涉及数值计算以及Text2SQL的选择
Text to SQL可以看到成熟度越来越高。但总体而言数值计算并不太适合用大语言模型这种概率模型直接去做。数值计算比较适合使用逻辑模型或者规则工具去做比如说SQL。大语言模型在里面起到的作用是把自然语言所表达的问题拆解成有逻辑关联的步骤然后将这些步骤转化sql。达到的效果是输入自然语言输出是SQL 的查询语句然后SQL查询语句进入数据库运行这是一种比较好的方式。如果非要用大语言模型去解决这样的问题即仍然依赖于概率分布不去借助类似计算器这样的工具则需要给大语言模型很多例子至少告诉大语言模型怎么计算步骤的拆解。但是大语言模型还是摆脱不了next token predictor的情况 即知道自然语言的分布是怎样的回答的结果就是概率分布的结果。比如说之前 3.11 和3.8比大小的情况大预言模型会认为3.11更大是因为大语言模型可能理解的是两个版本号比如Python的3.11和3.8。大语言模型理解的是3.11版本比3.8版本更晚出现肯定更强所以更大而不是不是按照人类日常使用的小数规则。这样的例子非常多有一些非常识性的问题人类可能不可能犯的错误。但是大型语言模型可能是语料被污染或者是人类语言自然就有的歧义可能就会弄错。对于非常严肃的计算场景则一般需要额外的verify手段保证大语言模型做的是正确。
07
技术爬坡
长文本的技术爬坡方向
推理质量不能有所下降如何在保质保量的做长文本的推理是一件非常困难的事。解决了能力问题之后还要解决贵且慢的问题。前面讲到两个瓶颈一个是推理成本会特别高一个是首token会特别慢。在一个阶段解决好这两个问题之后待上下文窗口再提升到下一个里程碑这两个问题又会出现。但还是要持续去研究expand context window, 因为有一个现象表明当长文本能力上去之后有很多附带的能力会涌现出来。具体到以后长度能到多长现在行业没有共识。具体的技术从实验室环境到真正的生产环境会有很大的gap。10 Million 的模型 100 Million的模型可能已经有了但是可能推不到生产。主要是延迟特别高或者精度特别的差。
RAG的技术爬坡方向
整个链路变得更长了远远比半年之前变得更复杂开始有更多的技术栈被加入进来。大概 6- 12 个月之前市场对于 RAG 的印象是先embedding 模型抽象出一个向量然后导入向量数据库里边然后搜索出向量背后代表的短文本块放入大语言模型。6个月之前甚至三五个月之前出现了一种说法如果不用向量数据库把整个文章输入大语言模型就解决问题了所以在Twitter等自媒体上开始有了长文本vsRAG 的提法这个故事很抓眼球。但后来实际的情况没这么简单这里边是一整个链路的问题这两个东西不是简单就能比较的。开始大家都觉得只应该用向量。但慢慢的发现其实向量检索只是很复杂技术栈中间的一块而已。包括有人觉得向量数据库是不是有能力做端到端服务或者向量数据库是不是能做端到端服务直接提供搜索业务但实际不然。实际情况比向量检索加大语言模型拼接更复杂。最近新涌现出来的技术栈提供了很多其他的解决方式比如知识图谱包括长文本用于离线数据的挖掘即给很长的文本进行压缩总结出来一些信息然后这个信息更容易进行搜索。或者因为有长文本所以对文本档案的切分就不用那么精益求精了稍微长一点也没有关系。甚至于其他新的embedding 模型类型根本就不在意切断的具体方法但这个主要还是在学术界领域在讨论实际应用的比较少。从语义的识别query serving角度来说原来觉得query 就应该直接去匹配文本段但实际上不是所以情景都适合这样做。很多时候 query 不是一个简单拿一个文本段就能回答了。很可能query 含有一个复合问题需要分为好几步才能够解答比如说是需要比较分析的问题比如A和B之间的区别是什么如果是人去做这类问题的回答可能会先看 A 是什么然后 B 是什么这两者都充分理解后然后再去做一个比较这就是一个多步问题。大语言模型的进展除了长文本本身之外包括推理和逻辑的能力也在提升然后就出现了用大语言模型去解析query语义将其拆成多步甚至产生了是交互式的问题解答即先解答一步然后根据该步的返回的情况再让大语言模型去决后面一步要解决什么样的问题。这样复杂的 query 的解析和路由的方式已经开始出现了而且在前期生产应用的效果看起来也不错。整个过程是需要online和offline的结合传统搜索就有offline的部分 offline 就是像管理图书馆中的图书一样怎么分门别类的把书放好这样进行检索的的时候更容易。另外一部分是online 的部分 online 的时候就是用户要过来查这个书了那怎么能够快速把这书找到依赖于线下做的事情然后这两块现在都有进化都有新的技术栈的加入整体来看实现效果包括应用情况也比 6 个月之前要好了很多。可以看到整个市场中越来越多的人开始探索更细节的问题比如语义识别应该怎么做用什么模型比较好该用大的模型还是小的模型还是几个模型堆在一起做gate像基层链路关系。然后单纯的问 RAG是什么的问题越来越少说明已经慢慢的开始解决落地的问题而不只是概念验证的问题。
长文本与RAG也在融合部署
比如说开始有离线做数据挖掘的情况出现了比如说最简单的数据挖掘就写一个总结。除了给这一整本书的很长的内容做了场景切分之外还去把这一本书在离线的时候都读了就是拿大语言模型长文本的能力去读了一遍然后写了一个总结这个总结本身也是作为召回的语料之一。然后在serving的阶段原来大家会谨小慎微的往里边塞东西现在可能多塞几个片段甚至切分 chunking 都不用切的特别小可以切很大的chunk。然后把几个很大的 chunk 加在一起非常长的东西扔进去只要能承担这个成本。这里边也会有一些问题有trade off比如说放了很长的东西对大语言模的稳定性要求就很高就是刚才提到大海捞针或者数星星的这种能力要逐步的增强。还有推理的能力大模型需要注意到这些任务里面有自相矛盾的内容它应该有判断。整个进步是螺旋上升的就是一边在系统层比如说搜索数据处理在提升。另外一方面大语言模型作为框架里边非常重要的工具本身也要提升。整个系统会采用大语言模型工具提升的能力来甚至有新的用法就比如说刚才提到的做总结做数据挖掘这类事情。
08
GraphRAG
GraphRAG 带来的启发GraphRAG的技术路线是否是目前的best practice
GraphRAG是一个价值很高的项目。对于知识图谱的提取应用都做了开源的实现填补了市场上的空白知识图谱在实际应用领域需求非常强因为语义检索只能解决一部分问题如果对检索的可靠性、可预测性的要求比较高的话应该加入一些基于规则化的检索。知识图谱是一个非常好的系统化解决知识结构化的问题。因为如果单纯是用专家系统可能用人去编辑能覆盖的范围比较有限体量也会受到限制。但是用知识图谱具有知识图谱的抽取就是三元组的抽取知识图谱构建包括在实际 serving 的过程中也可以把实体做向量化相关的实体作为标量一起存储召回时也参考相关实体的信息实验发现效果提升很明显。同时因为知识图谱是一个很好的系统整理信息的工具也适合基于知识图谱做数据挖掘比如先聚类然后再做总结。
GraphRAG在一些方面填补了知识图谱的空白但实际上它做的不是一个典型传统的知识图谱GraphRAG做了两件事情
一是创造了community的概念本质上是利用知识图谱进行数据挖掘。通俗点说把一个很长的一个文档或者说文档库里边的内容先做了切分这个有点像 RAG 里边做 chunking 切分后对于每一个单元去提取里边的知识三元组比如说一个实体和另外一个实体中间是什么关系。比如说奥巴马是美国总统这样的关系提取出来。二是还把知识图谱跟向量检索做了结合。一方面用知识图谱做了数据挖掘建立树形的信息结构这个叫community相关的 entity 聚合成小的community然后把多个小的 community聚合成大的community相当于采用金字塔型的结构整理了信息并做了总结。使得每一个三元组成为信息单元。对知识三元组本身也做了向量化。然后将所有这些东西放在向量数据库里边根据语义去做召回。GraphRAG召回的方法的设计也比较全面考虑到小的entity也考虑到总结性的信息。最后把这一套东西做了开源的实现这是价值比较大的点。
如何学习AI大模型
作为一名热心肠的互联网老兵我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。我已将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 一、全套AGI大模型学习路线
AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能 二、640套AI大模型报告合集
这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。 三、AI大模型经典PDF籍
随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。 四、AI大模型商业化落地方案 作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
