📌 📄 内容摘要:
@weeker 在 2.5pro的上下文抗衰减能力这么强，那么现有的rerank反过来成为掣肘了 中发帖
知识库运行体系是先通过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...
────────── 链接信息 ──────────
🔗 论坛链接: linux.do
📎 访问地址: https://linux.do/t/topic/522418/1
─────────────────────────────
📢 来源：LINUX DO
