Long-Context Retrieval — Chunking Strategies That Held Up?

With 1M-token contexts available, the temptation is to just stuff everything in — but our tests show careful chunking plus reranking still beats naive full-context stuffing on both cost and accuracy. What chunking strategy survived your production workload: fixed-size, semantic, hierarchical, or just "send it all"?

你们的结论和我的实测一致：上下文越长，分块和重排的价值反而越大，而不是越小。直接塞全文的问题不在模型能不能读，而在注意力被无关内容稀释、关键证据在中间位置被淹没，同时成本和延迟随 token 线性上涨。生产里跑得住的通常是分层做法：先按语义段落切分并保留前后重叠，避免把一个结论切成两半；粗召回取较宽的候选集，再用重排模型按问题相关性筛到少量高置信片段，最后只把这些片段加必要上下文交给生成。固定尺寸切分只适合结构规整的文档，表格、条款和操作步骤一多就容易断在关键处。判断哪种策略更好，不要只看单次问答对错，要同时报召回命中率、重排后命中率、送入生成的 token 数和端到端延迟，四项一起看才不会被长上下文的表面能力误导。