知识库运行体系是先通过embedding模型把文件分块、拆解为chunk、向量化，使用者提问后，找出相关chunk再通过rerank模型重组，LLM模型读取后执行生成任务。 
但是有个问题是一旦chunk超过rerank长度，传入rerank的文本就可能会被截断，影响重排结果。比如bge的embedding文本长度是8192、rerank文本长度512，即使是voyage的embedding长度是32k、rerank长度是4096，所以以前需要人为减小索引长度，去匹配rerank最佳性能。 
在以前LLM模型普遍上下文能力不强的情况下，“Embedding + Rerank + LLM”的组合拳效果很好。 
现在2.5pro的上下文能力是1M， Fiction.LiveBench里2.5pro的120k上下文抗衰减能力是90.6%。 
如果说仅仅是为了迁就 rerank，那就浪费了2.5p...