我要投稿
微信搜一搜，关注“探索AGI”
正常在处理大规模数据建索引的时候，一般我们需要先对文档进行分块，建立向量索引。 而这个分块大小，设置的都是比较短的，比如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+中大型企业
2025-07-31
进阶版｜企业级 AI Agent 的构建实践
2025-07-31
餐饮业卷生卷死的当下，麦当劳如何用AI突围
2025-07-31
全网疯传GPT-5泄露！首次统一GPT和o系列，编程实测demo抢先曝光，下周发布？
2025-07-31
ODPS重磅升级！全面支撑AI应用爆发
2025-07-31
四步搞定Cursor地区限制
2025-07-31
当AI成为团队“隐形搭档”：Anthropic内部如何用AI重构工作流？
2025-07-31
解锁日志分析新姿势：n8n 工作流 + ES 日志 + AI，数据洞察一键 get
2025-07-31
微软花重金做的Copilot，居然被WPS一个按钮给秒了?
2025-05-29
2025-05-23
2025-06-01
2025-05-07
2025-05-07
2025-05-07
2025-06-07
2025-06-21
2025-06-12
2025-05-20
2025-07-31
2025-07-31
2025-07-31
2025-07-30
2025-07-30
2025-07-30
2025-07-30
2025-07-29
回到顶部
粤ICP备14082021号