RAG系统里文档切得太碎反而丢了上下文，大家怎么平衡的？

我之前也踩过这坑，后来发现光调chunk size不够，得配合结构感知切分。比如按标题层级或者段落边界切，再给每个chunk加上它所属的章节路径，这样检索时能带上父级上下文。现在用的方案是子块检索、父块返回，效果比单纯调大小稳不少。你可以试试llama_index的sentence window或者hierarchical node parser，比自己手撸省事。

我一般按语义切，段落完整优先，再配个小overlap，比死磕字数管用。

我感觉chunk size真没万能值，得看文档结构。技术文档可以按标题层级切，父块保留章节摘要，子块细粒度检索，命中后把父块一起喂给模型，这样接口和依赖就不容易被拆散。我一般先试800到1200，再配合overlap 15%左右，效果比死调一个数稳。rerank有用但也别全指望它，检索前先把元数据过滤做好更实在。

我一般按语义切，不按固定字数，标题和正文绑一起效果会好很多。

我一般按语义切，标题+段落为单元，chunk大小随内容走，不硬套数字。

我一般不会只按固定字数切，而是按文档结构来，比如按标题层级、段落或者代码块边界切，这样语义完整度高不少。chunk size也得看embedding模型，像bge-m3对长文本友好些，512确实容易丢上下文。还有个思路是检索时用小块召回、大块喂给LLM，parent-child那种，能兼顾召回和上下文。rerank别全靠LLM，交叉编码器小模型效果稳一点，也便宜。

我一般按语义段落切，chunk size真没固定值，得看文档结构，硬切肯定丢上下文。

我一般不会死磕固定chunk size，先按文档结构切（标题、段落），再对超长段做二次切分，这样跨段落的语义天然就保留了。512确实太碎，1500又容易混，我现在常用800-1000带一点overlap，然后靠rerank兜底。你说的“玄学”我也有同感，后来发现关键其实是query改写和加一层parent-child检索，比单纯调size管用多了。工具的话可以看看LlamaIndex的sentence window和semantic chunker，值得试试。

我之前也踩过这个坑，说实话chunk size这东西真没有万能值，得看你的文档结构长什么样。像我们内部文档有大量API说明和配置项，硬切字符数基本必翻车，后来改成按标题层级切，再在chunk前面拼上所属章节路径，检索准确率明显好了一截。你说的跨段落问题，其实不一定是chunk太大或太小，而是检索单元和语义单元没对齐。可以试试小块检索、大块喂给模型这种方式，用小的chunk去匹配query，命中后把相邻的几个chunk一起塞进上下文，这样召回和完整性都能兼顾。工具的话可以看看LangChain的ParentDocumentRetriever或者LlamaIndex的SentenceWindowNodeParser，思路都差不多。另外rerank确实有用但别当万能药，检索阶段召回本身不行的话，后面怎么排都白搭。

我一般按段落切，再给每块加个标题摘要，检索时命中率高不少。

我一般按语义切，再用小模型做父块召回，比死磕字符数靠谱多了。