Qdrant BM25 找到 48/48 份证据后，MiniMax 为什么仍只通过 9/24
产品检索从 Hybrid Qdrant 切到 Sparse BM25 后，固定查询召回达到 48/48；MiniMax 实际运行有 47/48 份证据进入候选，只读取了 29/48。
QdrantBM25MiniMaxGolden DataEvidence
实践记录
实践记录按完成时间排列。每篇文章先说明背景、要解决的问题、采用的做法和结果，再展开过程中的失败、 取舍与可复现资料。
失败实验保留原始结果。后续实现改变文章结论时，原文会补充当前状态，不改写当时的数据。
论文权限与索引生命周期如何收敛为四个事实
上传统一进入个人空间，管理员单独发布全局论文；处理中论文不可检索，Qdrant 每篇只保留一份可重建索引。
论文权限QdrantReading Model索引重建架构
Qdrant 让 76 篇论文的广查询快了 4 倍，证据排序却退化了
共享预构建索引省掉了 Python Worker 的重复加载；同预算下，指定证据命中从 BM25 的 42/48 降到 34/48。
QdrantBM25检索人工复核可靠性
MiniMax 17/30、GPT 14/30，人工盲审却给出相反结果
自动严格评分与人工盲审给出相反排名，因此重新界定指标含义并停止继续增加校验层。
Golden Data人工评估MiniMaxAgent Harness
换成 GPT 后，严格评分为什么从 60% 降到 36.7%
在数据、工具、提示词和单路径编排不变的条件下，只更换模型与 API；Responses API 接入成功，但测试模型出现更多预算耗尽和证据错误。
ProviderResponses API工具调用评估
我让 Agent 同时跑两遍，严格评分从 60% 降到了 53.3%
通过独立运行、理论上限和实际选择结果，判断失败来自答案生成缺少互补性，而非选择规则；并行方案增加了约 73.5 万 Token。
Best-of-NAgent 编排Selector成本
我把检索召回从 16/32 修到 29/32，却只多通过 1 个问题
通过分层记录和固定查询重放，确认检索下降来自测试论文的数据结构；召回恢复后，剩余问题集中在证据选择、引用和成本。
Golden DataReading Model检索评估