[Bug]: Hardcoded RERANK_LIMIT logic causes API failures (400) and ignores UI Top-K settings

快速结论：该问题发生在 RAGFlow 的 Reranker 流程中。后端硬编码计算 RERANK_LIMIT 的公式会忽略用户在 UI 中设置的 Top-K 值，导致发送给 Reranker API 的文档数量超过其限制（如 64 个），从而返回 400 Bad Request。优先排查 rag/nlp/search.py 中的 RERANK_LIMIT 计算逻辑，或者作为临时方案，手动修改代码以硬编码该值为 64 或用户的 Top-K 值。

问题场景

用户在使用 RAGFlow v0.24.0 官方镜像时，配置了 Chatbot 并启用 Reranker（例如 Cohere 或 vLLM 托管的 BGE 模型）。在 UI 中将 Top-N (page_size) 设置为 6，Top-K 设置为较低的值（如 10）后，执行查询时触发 400 错误。通过日志或 API 拦截发现，后端计算出的 RERANK_LIMIT 值为 66，超过了 Reranker 的 64 文档限制。

报错原文

# 来自日志或 API 响应
400 Bad Request
Code Analysis - RERANK_LIMIT = math.ceil(64 / page_size) * page_size # 当 page_size=6 时，结果为 66

原因分析

根本原因在于 rag/nlp/search.py 中的 RERANK_LIMIT 计算逻辑是硬编码的，完全忽略了用户在前端设置的 Top-K 值。具体公式如下：

# 位于 rag/nlp/search.py 约第 387-388 行
RERANK_LIMIT = math.ceil(64 / page_size) * page_size if page_size > 1 else 1
RERANK_LIMIT = max(30, RERANK_LIMIT)

该逻辑强制将 RERANK_LIMIT 计算为 page_size 的倍数，且最小为 30。当 page_size=6 时，结果为 66，超出了许多标准 Reranker API（如 Cohere）的 64 文档输入限制，导致 400 错误。即便未超限，该值也远高于用户期望的 Top-K（如 10），从而降低了检索质量。

Issue 评论指出，Go 实现的 Elasticsearch 引擎（internal/engine/elasticsearch/search.go）实际上会将 RERANK_LIMIT 上限限制在 topK，但 Python 实现缺少此安全机制。这是一个已知的设计不一致问题，且在之前的 Issue（#11867、#8626）中有所讨论。PR #12753（2026年1月合并）修复了 top_k 在会话检索中被完全忽略的 bug，但并未解决 RERANK_LIMIT 的计算问题。

环境排查

RAGFlow 版本：v0.24.0（官方镜像）
Reranker 提供商：Cohere、vLLM 托管的 BGE 等
UI 设置：Top-N (page_size) 和 Top-K 值
相关源代码文件：rag/nlp/search.py（Python 实现）与 internal/engine/elasticsearch/search.go（Go 实现，作为对比）

解决步骤

临时修复（修改源代码）：
1. 在 RAGFlow 部署中，找到并编辑 rag/nlp/search.py 文件。
2. 定位 RERANK_LIMIT = math.ceil(64 / page_size) * page_size if page_size > 1 else 1 和 RERANK_LIMIT = max(30, RERANK_LIMIT) 这两行。
3. 方案一（推荐，可优先尝试）： 将 RERANK_LIMIT 的计算结果限制在用户的 Top-K 值范围内。在现有计算完成后，添加一行：RERANK_LIMIT = min(RERANK_LIMIT, top)。这模仿了 Go 实现的行为，确保发送给 Reranker 的文档数量不超过用户指定的 Top-K。
4. 方案二： 直接硬编码 RERANK_LIMIT 为一个固定值，例如 64（如维护者建议）。但这仍然可能忽略用户较小的 Top-K 设置。
临时工作区（不修改代码）：
1. 在 UI 中，将 top_k 和 page_size 设置为相同的期望值。例如，如果希望最终返回 10 个结果，则将两者都设为 10。这可以在一定程度上控制 RERANK_LIMIT，因为它依赖于 page_size。
2. 注意：此方法并不完美，因为它仍然受到硬编码公式（最小 30 且为 page_size 倍数）的限制，可能无法达到非常低的 Top-K 值。
长期方案： 关注上游官方修复。该 Issue 已被标记为 🐞 bug，预计会针对 rag/nlp/search.py 中的 RERANK_LIMIT 逻辑进行重构，使其尊重 UI 中的 Top-K 设置。

验证方法

完成修复步骤后，重启 RAGFlow 服务。使用与复现 Issue 时相同的配置（例如，page_size=6，Top-K 设为 10）执行查询。观察日志或通过 API 拦截确认：

后端计算出的 RERANK_LIMIT 值是否不超过用户设定的 Top-K（例如 10）。
Reranker API 是否返回 200 成功状态码，而非 400。
最终返回给用户的文档数量是否与 UI 设置的 Top-K 值一致。

参考来源

infiniflow/ragflow #14081

关联的已知讨论：

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

[Bug]: Hardcoded RERANK_LIMIT logic causes API failures (400) and ignores UI Top-K settings