微信扫码
与创始人交个朋友
我要投稿
正常在处理大规模数据建索引的时候,一般我们需要先对文档进行分块,建立向量索引。 而这个分块大小,设置的都是比较短的,比如512。 一方面是早期bert的处理长度的限制,另一个方面是如果文本太长,包含的信息就越多,那么可能比较难用一个向量来表征出来。
对于前者,如果持续关注向量模型的同学可以发现,无论是开源的BGE系列,还是闭源的API,都在往一个较长的上下文靠齐(比如说8192)。那这就有一些矛盾了,如果工业界只需要512的上下文的向量模型,为什么还要往更长的8192模型发展呢?
对于传统的分块,类似于固定长度的分块。带来的一个比较大的问题是,上下文缺失。就像下图一样,一个句子的主语在段落开头,后面的段落/句子中,有一些代词比如 It's, The city等等来表示主语。这种情况下确实主语的句子基本上就变得比较断章取义了~
与先分块后向量化不同,JinaAI最新提出的“Late Chunking”方法是一个相反的步骤,首先将整个文本或尽可能多的文本输入到嵌入模型中。在输出层会为每个token生成一个向量表示,其中包含整个文本的文本信息。然后我们可以按照需要的块大小对对向量进行聚合得到每个chunk的embedding。这样的优势是,充分利用长上下文模型的优势,同时又不会让每个块的信息过多,干扰向量表征。
在测试中,在所有情况下,与常规的分块相比,Late Chunking提高了召回ndcg@10。在某些情况下,它的性能也优于将整个文档编码为单个嵌入。并且,文档越长,Late Chunking策略就越有效。
开源的实验代码:https://colab.research.google.com/drive/15vNZb6AsU7byjYoaEtXuNu567JWNzXOz?usp=sharing&ref=jina-ai-gmbh.ghost.io
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-09-21
OpenAI o1 团队在线答疑:o1的o指OpenAI,强化后的推理有泛化能力,未来模型思考时间可控!
2024-09-21
大模型的威力,远不只是聊天框
2024-09-21
OpenAI o1的架构流程已被Claude破解了?
2024-09-21
RAG检索失败率降低49%?Anthropic-Contextual-RAG方案解析-兼看老刘的课堂三部曲
2024-09-21
Multi-Agent架构-CrewAI详解
2024-09-21
聊聊RLHF的奖励模型——上海人工智能书生大模型的RW实践
2024-09-21
文档大模型,能否真正解决非结构化数据难题
2024-09-21
全球首发:第二代 RAG 系统 auto-coder.rag 相比市面主流RAG系统 20%-60% 效果提升
2024-07-18
2024-03-30
2024-04-26
2024-04-11
2024-05-06
2024-06-12
2024-07-09
2024-05-09
2024-07-25
2023-07-01
2024-09-21
2024-09-21
2024-09-21
2024-09-21
2024-09-21
2024-09-21
2024-09-21
2024-09-21