# 怎么用 late chunking 嵌入长文档 (October 22, 2024)

看了 [Jina Embeddings v3: A Frontier Multilingual Embedding Model](https://jina.ai/news/jina-embeddings-v3-a-frontier-multilingual-embedding-model/#parameter-dimensions) 了解到 late chunking（迟分）的技术，正好毕设这边要做论文 RAG，我觉得可以用上。

但是它一个坏处是，模型本身只能 embed 8192 tokens 的文本，所以天生地不适合做论文这种大体量的 embedding

![](/nlark/yuque/0/2024/png/26070246/1729574643206-21f09bfa-24c5-466d-be37-1be2fe5d7d05.png)

于是我想了个办法，就是用滑动窗口。坏处就是，这样的成本会飙升，毕竟相当于 embed 每个块都要用 8192 tokens。但这不失为一种办法。而且做毕设应该不用自己掏钱吧，如果学校一毛不拔的话那不太可能。

刚刚想到一些降低成本的方式：

+ 由于本质上都是对 markdown 进行 indexing，所以其实每个块大概是这样的：
    1. 路径信息（类似面包屑导航，某某大标题某某小标题这样）（这一部分是 sticky 的，每个 chunk 都要带上这个）
    2. 直到下一个小标题之前的所有文本
+ 然后每个标题之间的长度可能超过 8192 可能不超过，所以不会每次都一定要顶满 8192（暂且认为只要带了标题就带上上下文了）
+ 这是不是就是一种 contextual retrieval 了呢？如果我假设面包屑信息就是所需的上下文的话？[Introducing Contextual Retrieval \ Anthropic](https://www.anthropic.com/news/contextual-retrieval)

---

这么一想，觉得应该发个库，用来解决 markdown chunking 的事情。它除了用 AST 分割标题、然后插入面包屑外，还要做下面两件事情：

+ 如果某个块还是太长，则要成小块
+ 如果某个块太短，则相邻几个合并成大块
    - 阈值怎么选择？我觉得和面包屑长度相比是个办法。如果比面包屑还短，那基本上就没必要单独一块了

对 这个才是最先决的条件。基本上我什么 RAG 都是先转成 markdown 再改

更何况最近也准备推一下我这个 [LLM Web Reader Demo](https://llm-web-reader.vercel.app/read) 项目