//@长夜微光bit:金融领域实践：八百到两千
一个常见的 RAG 问题：为什么 RAG 中文档的分块都很小？
一个很好的答案：
by zair (x.com/yhcnux)
回帖中有几位朋友已经指出了chunk太大存在embedding语义无法内聚和准确表达问题，所以可能导致召回不到。所以，利用好长上下文能力并不是把要chunk弄大，而是通过小chunk准确内聚的召回到那个点后，把那个点放大后再取回来，这就是small to big的RAG思路
这种small to big的方案有很多具体的实现变体，比如召回的时候附加语义chunk的前后chunk；比如层次chunk（大中小）,小chunk用于语义匹配，取回的时候取回其父（中大）chunk作为上下文；再比如广义上来说GraphRAG，Contextual RAG等都是类似的思路
回过头来我们再看世面上大多数前后端一体化成形的产品，其实大多把精力是放在了Workflow型的Agent这个层面上了，在高级RAG上反而是做得非常粗糙的。如早期的Coze、Dify等等（现在不知道，很久没看了）。反而是一些框架型的产品在这方面的方案比较多和细，比如LlamaIndex，LangChain等
***
by heycc (x.com/iheycc)
这受限于 embedding 模型的能力
对于 embedding 模型，单个文档的 token 越长，包含的语义就越多，embedding 后的 vector 的区分度越低，在 vector 搜索时就越难筛选到准确的文档
其实 5k token已经太长了。实际经验是 500、1k 这种程度
一个很好的答案：
by zair (x.com/yhcnux)
回帖中有几位朋友已经指出了chunk太大存在embedding语义无法内聚和准确表达问题，所以可能导致召回不到。所以，利用好长上下文能力并不是把要chunk弄大，而是通过小chunk准确内聚的召回到那个点后，把那个点放大后再取回来，这就是small to big的RAG思路
这种small to big的方案有很多具体的实现变体，比如召回的时候附加语义chunk的前后chunk；比如层次chunk（大中小）,小chunk用于语义匹配，取回的时候取回其父（中大）chunk作为上下文；再比如广义上来说GraphRAG，Contextual RAG等都是类似的思路
回过头来我们再看世面上大多数前后端一体化成形的产品，其实大多把精力是放在了Workflow型的Agent这个层面上了，在高级RAG上反而是做得非常粗糙的。如早期的Coze、Dify等等（现在不知道，很久没看了）。反而是一些框架型的产品在这方面的方案比较多和细，比如LlamaIndex，LangChain等
***
by heycc (x.com/iheycc)
这受限于 embedding 模型的能力
对于 embedding 模型，单个文档的 token 越长，包含的语义就越多，embedding 后的 vector 的区分度越低，在 vector 搜索时就越难筛选到准确的文档
其实 5k token已经太长了。实际经验是 500、1k 这种程度
