Jina AI 的这篇内容可以一读↓...
- 黄建同学
- 2024-12-10 23:52:25
Jina AI 的这篇内容可以一读↓ ai程序员
Still Need Chunking When Long-Context Models Can Do It All? 当长上下文模型能“一键搞定”时，还需要分段处理吗？
2023年，Jina AI 推出了 jina-embeddings-v2，这是首个支持长达8,192个token输入的开源嵌入模型。今年，又进一步发布了 jina-embeddings-v3，不仅保留了对长输入的支持，还显著提升了性能，超越了OpenAI和Cohere的最新嵌入模型。
这篇文章将探讨以下问题：
- 长上下文嵌入是否实用？
- 分段（chunking）对检索效果是否有提升？
- 如何在分段时保留文档整体语境？
通过比较长上下文嵌入与不同分段策略的表现，可以帮助您选择适合的文本处理方式。
★ 为什么长上下文嵌入可能不够？
长上下文模型可以编码多达10页文本，但也面临一些问题：
1. 表示稀释：当文档包含多个主题时，单个嵌入向量可能无法准确表示特定段落的内容。
2. 容量限制：嵌入向量大小固定，输入越长，模型越难全面表示所有信息。
3. 信息丢失：超过模型最大支持长度（如8,192 tokens）的文档需要截断，部分信息可能被遗漏。
4. 语义分段需求：某些任务需要检索文档的特定段落，而不是整体。
★ 分段策略对比
在实验中，对比了三种嵌入方法：
- 无分段：直接对整篇文档编码一个嵌入向量。适合主题一致的文档，但可能忽略细节信息。
- 朴素分段（Naive Chunking）：将文档按固定大小或语义线索分段，对每个段落单独编码。适合检索特定信息，但会缺失上下文。
- 延迟分段（Late Chunking）：先对整篇文档编码，再根据分段线索创建片段嵌入。保留全文语境，适合需要整体语义的任务。
★ 使用了以下数据集进行测试：
- NFCorpus：医学检索数据集，文档开头通常包含标题和摘要。
- QMSum：会议摘要数据集，用户需要提取会议的特定内容。
- NarrativeQA：长故事问答数据集，问题通常涉及文档特定细节。
- 2WikiMultihopQA：多跳问答数据集，信息分散于文档的不同部分。
- SummScreenFD：电视剧剧本摘要数据集，要求整合分散的情节信息。
★ 实验结果表明
- 在NFCorpus中，由于文档开头的信息最相关，无分段效果最好。
- 在QMSum和NarrativeQA中，朴素分段表现优异，因为用户需要从文档的不同部分提取信息。
- 延迟分段在需要整体语境的任务中略胜一筹，但在信息分散的文档中可能因噪声影响性能。
★ 如何选择适合的策略？
- 长上下文嵌入适合的场景：
如果文档主题一致且查询范围广泛，使用长上下文嵌入效果更好。例如，当用户检索的内容通常集中在文档开头时，无需分段即可获得良好的效果。
- 朴素分段适合的场景：
当文档包含多个主题或查询目标集中于特定细节时，分段可以提升检索效果。例如，对于长故事或会议记录，朴素分段有助于定位用户关心的具体段落。
- 延迟分段适合的场景：
如果文档语境连贯且查询需要平衡整体和细节，可以使用延迟分段。例如，在需要提取主题相关性的任务中，延迟分段能够保留文档的整体语义信息。
访问：jina.ai/news/still-need-chunking-when-long-context-models-can-do-it-all
ChatGPT
Still Need Chunking When Long-Context Models Can Do It All? 当长上下文模型能“一键搞定”时，还需要分段处理吗？
2023年，Jina AI 推出了 jina-embeddings-v2，这是首个支持长达8,192个token输入的开源嵌入模型。今年，又进一步发布了 jina-embeddings-v3，不仅保留了对长输入的支持，还显著提升了性能，超越了OpenAI和Cohere的最新嵌入模型。
这篇文章将探讨以下问题：
- 长上下文嵌入是否实用？
- 分段（chunking）对检索效果是否有提升？
- 如何在分段时保留文档整体语境？
通过比较长上下文嵌入与不同分段策略的表现，可以帮助您选择适合的文本处理方式。
★ 为什么长上下文嵌入可能不够？
长上下文模型可以编码多达10页文本，但也面临一些问题：
1. 表示稀释：当文档包含多个主题时，单个嵌入向量可能无法准确表示特定段落的内容。
2. 容量限制：嵌入向量大小固定，输入越长，模型越难全面表示所有信息。
3. 信息丢失：超过模型最大支持长度（如8,192 tokens）的文档需要截断，部分信息可能被遗漏。
4. 语义分段需求：某些任务需要检索文档的特定段落，而不是整体。
★ 分段策略对比
在实验中，对比了三种嵌入方法：
- 无分段：直接对整篇文档编码一个嵌入向量。适合主题一致的文档，但可能忽略细节信息。
- 朴素分段（Naive Chunking）：将文档按固定大小或语义线索分段，对每个段落单独编码。适合检索特定信息，但会缺失上下文。
- 延迟分段（Late Chunking）：先对整篇文档编码，再根据分段线索创建片段嵌入。保留全文语境，适合需要整体语义的任务。
★ 使用了以下数据集进行测试：
- NFCorpus：医学检索数据集，文档开头通常包含标题和摘要。
- QMSum：会议摘要数据集，用户需要提取会议的特定内容。
- NarrativeQA：长故事问答数据集，问题通常涉及文档特定细节。
- 2WikiMultihopQA：多跳问答数据集，信息分散于文档的不同部分。
- SummScreenFD：电视剧剧本摘要数据集，要求整合分散的情节信息。
★ 实验结果表明
- 在NFCorpus中，由于文档开头的信息最相关，无分段效果最好。
- 在QMSum和NarrativeQA中，朴素分段表现优异，因为用户需要从文档的不同部分提取信息。
- 延迟分段在需要整体语境的任务中略胜一筹，但在信息分散的文档中可能因噪声影响性能。
★ 如何选择适合的策略？
- 长上下文嵌入适合的场景：
如果文档主题一致且查询范围广泛，使用长上下文嵌入效果更好。例如，当用户检索的内容通常集中在文档开头时，无需分段即可获得良好的效果。
- 朴素分段适合的场景：
当文档包含多个主题或查询目标集中于特定细节时，分段可以提升检索效果。例如，对于长故事或会议记录，朴素分段有助于定位用户关心的具体段落。
- 延迟分段适合的场景：
如果文档语境连贯且查询需要平衡整体和细节，可以使用延迟分段。例如，在需要提取主题相关性的任务中，延迟分段能够保留文档的整体语义信息。
访问：jina.ai/news/still-need-chunking-when-long-context-models-can-do-it-all
ChatGPT
