<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>PaperLoom Engineering Practice</title>
    <link>https://chzarles.github.io/paperloom/</link>
    <description>Evidence-backed notes from building PaperLoom.</description>
    <language>zh-CN</language>
    <item>
      <title>Qdrant BM25 找到 48/48 份证据后，MiniMax 为什么仍只通过 9/24</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/qdrant-bm25-cutover-minimax-evidence-gap</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/qdrant-bm25-cutover-minimax-evidence-gap</guid>
      <pubDate>Sat, 18 Jul 2026 16:00:00 GMT</pubDate>
      <description>产品检索从 Hybrid Qdrant 切到 Sparse BM25 后，固定查询召回达到 48/48；MiniMax 实际运行有 47/48 份证据进入候选，只读取了 29/48。</description>
    </item>
    <item>
      <title>论文权限与索引生命周期如何收敛为四个事实</title>
      <link>https://chzarles.github.io/paperloom/practice/architecture/paper-access-and-index-lifecycle-simplification</link>
      <guid>https://chzarles.github.io/paperloom/practice/architecture/paper-access-and-index-lifecycle-simplification</guid>
      <pubDate>Thu, 16 Jul 2026 16:00:00 GMT</pubDate>
      <description>上传统一进入个人空间，管理员单独发布全局论文；处理中论文不可检索，Qdrant 每篇只保留一份可重建索引。</description>
    </item>
    <item>
      <title>Qdrant 让 76 篇论文的广查询快了 4 倍，证据排序却退化了</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/qdrant-retrieval-impact-benchmark</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/qdrant-retrieval-impact-benchmark</guid>
      <pubDate>Wed, 15 Jul 2026 16:00:00 GMT</pubDate>
      <description>共享预构建索引省掉了 Python Worker 的重复加载；同预算下，指定证据命中从 BM25 的 42/48 降到 34/48。</description>
    </item>
    <item>
      <title>Qdrant 检索切换后的上传与重建规则</title>
      <link>https://chzarles.github.io/paperloom/practice/architecture/qdrant-corpus-plane-cutover</link>
      <guid>https://chzarles.github.io/paperloom/practice/architecture/qdrant-corpus-plane-cutover</guid>
      <pubDate>Tue, 14 Jul 2026 16:00:00 GMT</pubDate>
      <description>以论点、论据和推导逐项决定索引何时可用、谁能重建、重建期间能否检索，以及是否需要保留多个 Generation。</description>
    </item>
    <item>
      <title>MiniMax 17/30、GPT 14/30，人工盲审却给出相反结果</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/hard-pass-human-review-stopping-rule</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/hard-pass-human-review-stopping-rule</guid>
      <pubDate>Tue, 14 Jul 2026 16:00:00 GMT</pubDate>
      <description>自动严格评分与人工盲审给出相反排名，因此重新界定指标含义并停止继续增加校验层。</description>
    </item>
    <item>
      <title>我让 Agent 同时跑两遍，严格评分从 60% 降到了 53.3%</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/best-of-two-agent-orchestration</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/best-of-two-agent-orchestration</guid>
      <pubDate>Mon, 13 Jul 2026 16:00:00 GMT</pubDate>
      <description>通过独立运行、理论上限和实际选择结果，判断失败来自答案生成缺少互补性，而非选择规则；并行方案增加了约 73.5 万 Token。</description>
    </item>
    <item>
      <title>换成 GPT 后，严格评分为什么从 60% 降到 36.7%</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/provider-migration-experiment</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/provider-migration-experiment</guid>
      <pubDate>Mon, 13 Jul 2026 16:00:00 GMT</pubDate>
      <description>在数据、工具、提示词和单路径编排不变的条件下，只更换模型与 API；Responses API 接入成功，但测试模型出现更多预算耗尽和证据错误。</description>
    </item>
    <item>
      <title>我把检索召回从 16/32 修到 29/32，却只多通过 1 个问题</title>
      <link>https://chzarles.github.io/paperloom/practice/evaluation/golden-data-harness-evolution</link>
      <guid>https://chzarles.github.io/paperloom/practice/evaluation/golden-data-harness-evolution</guid>
      <pubDate>Sun, 12 Jul 2026 16:00:00 GMT</pubDate>
      <description>通过分层记录和固定查询重放，确认检索下降来自测试论文的数据结构；召回恢复后，剩余问题集中在证据选择、引用和成本。</description>
    </item>
  </channel>
</rss>
