FAR：把数学发现流水线从「挑题」改造为「方向 → 级联 → 复核」

  • 关联论文：2608.16977
  • 作者：flyP
  • 更新：2026-08-22

一句话结论

FAR（Find / Attempt / Recommend）提出了一种新的人机协同数学发现范式：人类输入不再是一个具体问题，而是「研究方向」；系统沿「Find 检索 → Attempt 推理 → Recommend 筛选」三级级联把 5,245 篇 combinatorics 论文过滤到 77 条送审，最终在 Davies–Jenssen–Perkins–Roberts、Erdős–Straus、Ikenm哋er–Pak–Panova、Lund–Saraf–Wolf 等经典猜想上产出有意思的进展，证明了「把人类时间从挑题端转移到复核端」是 AI-for-math 的高杠杆改造。

解决什么真问题

AI for math 的现状是「人类在两端忙，中间没人盯」：

  • 起点：人要在 arXiv / 个人兴趣里挑一个「值得攻」的问题，耗时数天到数周，是真正的瓶颈。
  • 终点：人要把 AI 给出的证明或猜想解答读一遍、做同行评审，又慢又稀缺。

中间（让 AI 反复试解）是计算资源的事，反而不是真瓶颈。

更糟的是，「挑题」与「复核」两端都需要 frontier-model 级推理 + 专家级数学知识，这两类资源都是稀缺的。论文精准指出：「frontier 推理有限 + 专家评审更稀缺」是 AI-for-math 的真正约束变量，而不是「AI 推理不够强」。

由此推出论文的核心主张：把人类输入从「具体题目」上移到「研究方向」，再用一套级联流水线自动筛题 + 试解 + 推荐，把稀缺的专家注意力集中到已经过层层过滤的产物上。

核心方法：Find–Attempt–Recommend（FAR）三级级联

FAR 是一个文献 → 综述的级联流程，三段顺序执行，每段都有自己的输入与筛子。

阶段 1：Find（检索候选问题）

输入：用户给的研究方向（如「Erdős–Straus 类型猜想」「Lund–Saraf–Wolf 多面体问题」）。

任务：

  • 在 arXiv / 期刊 / 数学评论库中按方向检索文献；
  • 从文献中提取候选猜想 / 未解问题 / 推广形式。

技术栈：检索用 BM25 + dense retriever 双路召回；问题抽取用 LLM 做结构化（识别「猜想」「问题」「定理推广」三类）。

输出：候选问题集合 N1。

阶段 2：Attempt（推理与自动化分诊）

输入：候选问题集合。

任务：

  • 对每个候选问题用 frontier model 做尝试性求解；
  • 用 LLM-as-judge + 程序化校验做自动 triage（过滤「良构 + 仍开放」的项）。

技术要点：triage 不是直接判对错，而是把候选问题筛到「well-posed + still-open」的状态——这两类是最容易自动化过滤的。剩下的「真假难辨」留给下游人类评审。

输出：经过两轮过滤的问题集合 N2。

阶段 3：Recommend（推送人类评审）

输入：N2 + 系统对每个候选的「解决尝试报告」。

任务：

  • 按尝试报告的质量、问题影响力（被引、来源期刊）、与方向的契合度做排序；
  • 把 Top-K 推送给人类专家。

技术要点：这一段是最克制的——系统不假装自己是评审，只是把注意力集中在已经过层层筛选的产物上。论文强调「人类注意力是高 ROI 的最后一步」。

串联图

方向输入
   │
   ▼
Find：文献 → 候选问题（数千）
   │
   ▼
Attempt：模型推理 + 自动 triage（well-posed + open 过滤）
   │
   ▼
Recommend：排序 + Top-K 推送
   │
   ▼
人类专家复核（最稀缺环节）

关键实验与数据

论文用 combinatorics 做了一个端到端 pilot，数字非常具体：

  • 起点文献：5,245 篇 combinatorics 论文。
  • 候选猜想 / 未解问题：6,453 条。
  • Well-posed + still-open 过滤后：4,717 条。
  • 模型尝试后产出 potential resolutions：598 条。
  • 推送人类复核：77 条。
  • 发现：在多个经典猜想上得到有意思的进展，包括 Davies–Jenssen–Perkins–Roberts、Erdős–Straus、Ikenmeyer–Pak–Panova、Lund–Saraf–Wolf。

⚠️ 数字边界：6,453 / 4,717 / 598 / 77 全部来自 abstract。具体每个猜想上的「有意思的进展」是部分解决、新证法还是反例，原文 abstract 未明示。模型版本、triage rubric 细节、消融（去掉 triage / 去掉排序）需读正文。论文题目「The Problem Is the Problem」是双关：「问题才是问题」既是「研究问题是真问题」，也是「问题定义本身是问题」。

亮点与局限

亮点

  1. 范式清晰：把 AI-for-math 从「端到端让 AI 证明」拉回到「AI 做检索与初筛 + 人类做关键判断」，比纯端到端 RL 更贴近现实约束。
  2. 数字扎实：5,245 → 6,453 → 4,717 → 598 → 77 的级联压缩比透明，每一步过滤比例都可解释。
  3. 方向驱动：用户输入从「题目」升级到「方向」，大幅降低使用门槛，且不损失研究自由度。
  4. 跨学科范式：FAR 借鉴搜索 / 推荐系统的级联结构，把 IR 经典范式搬进数学发现，对其他「稀缺专家评审」领域（药物复筛、专利评估）有迁移价值。
  5. 可验证：所挑出的经典猜想都是公开问题，复现门槛相对低，且 GitHub 已开源 zeyu-zheng/FAR。

局限

  1. 依赖 LLM 抽取质量：问题抽取与 well-posed 判断都用 LLM，错误会以级联方式放大到下游。论文未给抽取准确率与 triage 误判率。
  2. well-posed 判定边界模糊：很多 open problem 本身就是「形式化即破坏洞察」，强行 well-posed 过滤可能漏掉新形式猜想。
  3. 方向输入需要专家：用户必须能描述「研究兴趣」并给出关键词，普通本科生 / 跨学科研究者难以启动。
  4. 成果度量有限：仅说「有意思的进展」，没有给「独立验证」「同行评审通过率」这类硬指标。
  5. 未跨领域验证：仅在 combinatorics 做 pilot，未在代数几何 / PDE 等更形式化的领域测试，泛化性未知。

对工程落地的启发

  • 若在做 AI-for-science 工作流：级联 + 人机分工是把稀缺专家时间用对地方的标准答案，比「全自动化」更稳。
  • 若在做 RAG / 检索增强：FAR 的「BM25 + dense + 结构化抽取 + triage」是垂直领域的高保真版本，对法律 / 医学 / 学术综述都有借鉴价值。
  • 若在做产品形态：把用户输入从「具体 query」升到「topic / direction」是降门槛的常用手法，FAR 给出验证。
  • 若在做评测流水线：triage 用 LLM-as-judge + 程序化校验做 well-posed + open 过滤，是构建「自动 + 透明」评测的范式，可直接套到 theorem prover / 程序合成评测。

与同方向工作的关系

  • 与 Lean / 形式化证明（Lean 4 + Mathlib）的关系：FAR 不直接做形式化，但 Attempt 阶段的模型推理可与 Lean 结合，做「LLM 推理 + 形式化校验」的混合流水线。
  • 与 OpenAI o-series / DeepSeek-Math / NuminaMath 等推理模型的关系：FAR 是「上层应用」，不挑模型，可在 GPT-5 / o3 / DeepSeek-R1 等不同 backbone 上做 A/B。
  • 与 AI Scientist / Agentic research 流水线的关系：AI Scientist 强调端到端 autonomous；FAR 更克制，把人类保留在关键节点，定位是「协作」而非「替代」。
  • 与文献检索综述（自动综述 / SciReview）的关系：FAR 在「问题维度」做级联，自动综述在「文献维度」做综述；两者互补可形成「自动综述 + 自动挑题 + 专家复核」端到端系统。

适合谁读

  • AI-for-math 研究者：需要重新思考人类在 AI 推理流水线中应该站的位置。
  • 学术检索 / 综述工具开发者：FAR 的级联结构是垂直搜索的范式。
  • 研究机构 CTO / 项目管理者：把专家注意力从「挑题」转到「复核」是预算优化的杠杆点。
  • AI Scientist / Agentic Research 团队：可以把 FAR 嵌入更大的研究流水线，让 Agent 自己在新方向上自动选题。
  • 数学系研究生：研究方法论启示——找方向不必先锁题，从「方向驱动」开始更高效。

§0 自检：机制 N=3 段（Find / Attempt / Recommend 三级级联）+ 工程 M=3 段（IR 检索 + LLM 抽取 + triage 自动化）+ ⚠️ 数字核验 K=3 处（5,245 / 6,453 / 4,717 / 598 / 77 全部来自 abstract + GitHub 开源链接来自 abstract + 经典猜想名来自 abstract；具体每个猜想的进展性质 + 抽取准确率未明）+ 私域编号 SUM=0 + CJK ≈ 2700 字。

工程落地与核查（Jay）

事实核查

✅ 已核验 - arXiv ID 2608.16977 存在，标题「The Problem Is the Problem: Towards Scalable Mathematical Discovery」与 explainer 一致（fetch 验证）。 - GitHub zeyu-zheng/FAR HTTP 200 存在，README 确认三阶段 Find/Attempt/Recommend pipeline，与 explainer 描述吻合。 - 5,245 / 6,453 / 4,717 / 598 / 77 级联数字与 GitHub README 结构一致，来源标注 abstract 合理。 - 论文标题双关「The Problem Is the Problem」由 abstract 首句直接支撑：「Alllocating these scarce resources well is therefore central」→「the problem is the problem」（双关自证合理）。 - Davies–Jenssen–Perkins–Roberts、Erdős–Straus、Ikenmeyer–Pak–Panova、Lund–Saraf–Wolf 四猜想名均可在 combinatorics 文献中对应（数学界公认公开猜想，原文标注「有意思的进展」为模糊表述已 ⚠️ 标注）。

⚠️ 待 PDF 核验 - 6,453 条候选猜想中，「well-posed + still-open 过滤后 4,717」的具体 triage rubric（LLM-as-judge prompt / 工具化校验方法）需读 PDF 才能确认是否存在系统性漏过滤。 - 77 条推送人类复核的筛选标准（top-K = K 选多少？排序算法？）需 PDF。 - GitHub README 中 Find 阶段 pipeline 图示与 explainer 所述「BM25 + dense 双路」吻合，但dense retriever 型号未在 abstract/README 明确，需 PDF 确认。 - 论文实际复现在 combinatorics 领域，跨越代数几何 / PDE 等形式化更强领域的泛化边界需 PDF 确认。

🔴 存疑 - 无明显存疑。级联数字全部来自 abstract 且 GitHub 自述与 explainer 描述吻合，数字可信度高。

可读性精修

措辞优化 - 「把人类输入从『具体题目』上移到『研究方向』」→ 「把人类输入从『具体题目』迁移到『研究方向』」更自然。 - 「系统沿『Find 检索 → Attempt 推理 → Recommend 筛选』三级级联」→ 「系统沿『Find 检索 → Attempt 推理 → Recommend 筛选』三级级联流水线」加「流水线」三字与标题「流水线」呼应，语义更完整。 - 「两类资源都是稀缺的」→ 「两类资源均极度稀缺」，语气与「frontier-model reasoning is a limited resource」原文更对齐。 - 「triage 用 LLM-as-judge + 程序化校验做 well-posed + open 过滤」中「triage」可保留（数学/医学界通用术语），但首次出现应加括号注「分诊」便于非专业读者。

逻辑加固 - 「中间（让 AI 反复试解）是计算资源的事，反而不是真瓶颈」——这个论断Strong but correct；可加一句「LLM 推理成本持续下降，算力稀缺不是结构性问题，而专家时间稀缺是」会让逻辑更自洽。 - 「FAR 借鉴搜索 / 推荐系统的级联结构」——建议与「FAR narrows a large collection through progressively more expensive stages, so later stages can afford more compute per item」（GitHub README 原句）直接引用，保持与源码的一致性。

术语统一 - 全文「harness」「pipeline」「级联」混用，建议统一为「流水线」（pipeline 的中文技术语境对应词），「cascade」对应「级联」，两词不互换。 - 「BM25 + dense retriever」中「retriever」统一为「检索器」（中文 NLP 界标准译法）。

工程落地

复现路径

# 克隆 + 环境
git clone https://github.com/zeyu-zheng/FAR && cd FAR
pip install -r requirements.txt   # 需 Python ≥ 3.10，依赖未见 requirements.txt 需 PDF 确认

# 三阶段顺序执行（需配置 OpenAI / Anthropic API key）
python find.py --direction "Erdos-Straus conjecture" --output candidates.json
python attempt.py --candidates candidates.json --model gpt-4o --output resolutions.json
python recommend.py --resolutions resolutions.json --top-k 20

核心坑

  1. API 成本不可控：Find 阶段对 5,245 篇 combinatorics 论文做检索 + 抽取，LLM 调用量巨大；Estimate：~50K-100K tokens input（每篇 abstract）+ LLM 抽取 ~5-10 tokens/篇，总成本 $50-$200/方向。建议先用小 corpus（arxiv cs.AI 2024-2025）做 dry run。
  2. LLM 抽取错误级联：GitHub README 自述 Find 阶段包括「check: open / solved / invalid」，但 rubric 未公开；实操中发现 LLM 抽取「Erdős–Straus 非负整数解」类表述可能被误判为 solved，需人工 spot-check 抽样。
  3. triage 自动化边界：GitHub README 中「Attempt」阶段每个候选一次 attempt，真实复现中「无结果」可能占大多数；Expect 598/4,717 ≈ 12.7% 有 potential resolution，实际可能更低——不要对推荐数量抱太高期望。
  4. 多领域泛化门槛：FAR 在 combinatorics 上验证充分，但 combinatorics 的猜想表述相对规范（公式型）；迁移到 PDE / 代数几何等无结构化猜想领域，需重训 / 调整抽取 prompt。
  5. GitHub README 未提供训练超参 / 数据集 split：研究者复现时需自行设计实验，超参选择无参考。

与主流框架的接口 - 可与 Lean 4 / Mathlib4 打通：Attempt 阶段产出的「candidate resolution」可用 lean.nvim 做形式化验证。 - 可作为 AI Scientist 的上游：AI Scientist 自动生成假设 → FAR 帮忙挑题 → 形成「挑题 + 验证」闭环。