这个坑值得记一笔。为了让答案更完整把 chunk 从 512 调到 1024，召回率从 0.81 掉到 0.72，检索回来的段落里混进大量无关内容，重排之后仍然答偏。
刚开始盯着「top_k 不变时总上下文超出预算被截断」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。块变长后单块语义被稀释，向量不够聚焦；重叠比例没跟着调，重复内容占比上升；评测只看了答案质量，没有单独看召回。
先按块长分桶统计召回率
python recall_eval.py --chunks chunk_512,chunk_1024 --queries q_300.jsonl然后把重叠比例从 100 降到 50 再测
python build_chunks.py --size 1024 --overlap 50 --out chunks_v2.jsonl试父子块结构，用小块检索大块补全
python build_chunks.py --size 256 --parent 1024 --out chunks_v3.jsonl剩下的就是对比三种方案的召回与答案质量
python ab_rag.py --sets v1,v2,v3 --queries q_300.jsonl别只看报错消失，验证要多做一步。小块检索加父块补全的方案召回回到 0.83，答案完整度没有下降，平均上下文长度减少 18%。
这里还有个坑。块长不是越大越好，召回看的是块内语义是否聚焦；用小块检索、大块补全，比直接放大块长更划算。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。