//@长夜微光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 这种程度