企业官网建设流程全解析

为什么 LLM 评审分数不稳定？Idea2Paper 给出了一个完整的答案：它的锚定式多智能体评审（Anchored Multi-Agent Review）不再让 LLM 直接打 1–10 的绝对分，而是让 LLM 做"盲审相对判断"，再由确定性代码从真实论文的已知分数中反推出最终分数——稳定、可复现、可审计。

Idea2Paper 是一个端到端研究代理框架（Research Agent）：离线构建 ICLR 论文知识图谱，在线从检索到生成一篇完整的研究故事（Story），最后由多智能体评审系统打分与反馈，驱动自动修改。👇

LLM 直接打分，为什么会飘？

如果你的经验是"把 story 丢给 GPT / Claude，让它当审稿人打 1–10 分"，那大概率踩过下面这几个坑：

老式"让 LLM 直接吐分数 + 自由评语"的路径，正是这些问题的重灾区。Idea2Paper 干脆换了一套思路。💡

核心思路：相对判断 + 确定性反推

整个评审系统分两层，各管一件事：

• Score Layer（评分层）：盲审对比 → 确定性分数反推。LLM 只输出better / tie / worse，最终 1–10 分由代码算出，可复现。
• Coach Layer（教练层）：评分完成之后，单独调用 LLM 生成字段级修改建议，完全不参与打分。

评分层的完整链路：

1. 从论文索引中按分位数规则确定性地选出锚点论文（真实论文已有 1–10 的已知分数）；
2. 把待评 Story 和锚点论文都做成匿名盲审卡片；
3. 三个角色智能体（Methodology / Novelty / Storyteller）各自做一次盲评对比；
4. 用离线校准的固定参数τ，通过网格搜索反推出每个角色的确定分数。

下面逐层拆解。🔍

盲审卡片：LLM 只能看到三行字

盲审的前提是"真的盲"。盲审卡片（Blind Card）是整个设计的第一个闸门，实现在 cards.py：

• 只展示 3 个字段：problem（问题）、method（方法）、contrib（贡献），且严格控制长度——分别不超过 220 / 280 / 320 字符，防止"写得更长 = 更好"的长度偏好；
• 硬性屏蔽一切标识信息：卡片里绝不出现paper_id、标题、作者、URL、DOI、score10、pattern_id等字段，从根源上堵住锚定偏差和信息泄露；
• Story 和锚点论文共享完全相同的字段结构，LLM 无从分辨"哪边是待评稿"。

当前卡片版本为blind_card_v2_minimal——注意，卡片结构一旦变动，τ 必须重新校准（原因下文讲）。

盲评判断：只许说"更好/持平/更差"

盲评智能体实现在 blind_judge.py。对每个角色，LLM 只需把 StoryCard 与所有锚点卡片逐一比较，输出严格 JSON：

{ "rubric_version": "rubric_v1", "comparisons": [ {"anchor_id": "A1", "judgement": "better|tie|worse", "strength": "weak|medium|strong", "rationale": "..."} ] }

几个关键约束：

• 禁止输出分数，rationale限 25 词以内，且会做"禁词泄漏检查"——万一 rationale 里写出某篇真实论文的标识，直接判为非法；
• 输出格式不合法时自动走修复重试（最多I2P_CRITIC_JSON_RETRIES次）；
• 判断随后映射为观测值：better → y=1、worse → y=0、tie → y=0.5；strength则作为权重乘数（weak=1、medium=2、strong=3），而不是"置信度"。

确定性反推：分数由代码算出来，而非 LLM 说出来

这一步是"分数稳定"的核心，代码在 score_inference.py。给定锚点的真实分数score10_i和固定 τ：

• 用p = sigmoid((S - score10_i) / τ)估计"待评稿 S 优于锚点 i"的概率；
• 在S ∈ [1, 10]上以 0.01 为步长网格搜索，找到使加权负对数似然NLL(S) = Σ w_i · CE(y_i, p_i)最小的 S；
• 锚点权重来自真实评审统计（评审数量越多、分数越集中，权重越高），再乘以判断强度权重。

同样的输入（比较结果 + 锚点 + τ）永远算出同一个分数——这就是可复现性的来源。代码还会顺便输出诊断信息：损失值、单调性违规次数、近似 95% 置信区间（ci_low / ci_high），方便你判断这一轮评审可不可信。

τ 校准：把"感觉分"对齐到真实分数

τ 是模型分差被"拉伸"的程度，直接决定分数落在哪个区间。Idea2Paper 用离线脚本对每个角色各拟合一个 τ：

python Paper-KG-Pipeline/scripts/tools/fit_judge_tau.py --role Methodology --pairs 2000 python Paper-KG-Pipeline/scripts/tools/fit_judge_tau.py --role Novelty --pairs 2000 python Paper-KG-Pipeline/scripts/tools/fit_judge_tau.py --role Storyteller --pairs 2000

三个角色共约 6000 次 LLM 调用，产出 judge_tau.json（含tau_methodology / tau_novelty / tau_storyteller）。

⚠️ 一旦以下内容变化，必须重新拟合 τ：

• 评审标准RUBRIC_VERSION变更；
• 卡片结构CARD_VERSION变更；
• 评审用 LLM 模型更换；
• 锚点论文分布发生大变化。

拟合时系统会把rubric_version / card_version / judge_model / nodes_paper_hash一并写入 τ 文件，版本不匹配可以直接检测出来，避免"旧 τ 配新 rubric"这种隐蔽错误。

自适应加密：第一轮不稳，自动补锚点重评

如果第一轮反推"看起来不可信"，系统会触发 Densify（加密）机制：

• 触发条件：loss > I2P_DENSIFY_LOSS_THRESHOLD，或monotonic_violations ≥ 1（比较结果与分数高低出现矛盾），或平均判断强度过低；
• 动作：围绕初估分数 S 所在的分数区间，用分桶策略再选一批更贴近的锚点（带缓存避免重复慢查询），然后对全部角色重新盲评。

这相当于"粗评不够就加锚点细评"，让分数在边界区域更精细。🎯

教练层：改稿建议与打分彻底解耦

评分完成后，coach.py 会发起一次独立的 LLM 调用，输出字段级的结构化修改建议：

{ "field_feedback": { "title": {"issue": "...", "edit_instruction": "...", "expected_effect": "..."} }, "suggested_edits": [ {"field": "innovation_claims", "action": "rewrite", "content": "..."} ], "priority": ["innovation_claims", "method_skeleton", "abstract"] }

这条设计非常关键：修改建议来自 LLM，但它碰不到分数。后续 StoryGenerator 拿着field_feedback / suggested_edits / priority逐字段执行修改，形成"生成 → 盲评打分 → 按字段精修"的闭环，而分数始终只由评分层的确定性流程决定。

质量模式配置与源码索引

推荐的"质量模式"环境变量（详见 REVIEWER_SYSTEM_QUALITY_MODE.md）：

export I2P_CRITIC_STRICT_JSON=1 export I2P_CRITIC_COACH_ENABLE=1 export I2P_JUDGE_TAU_PATH="Paper-KG-Pipeline/output/judge_tau.json"

关键配置项一览（优先级：env/.env > i2p_config.json > 默认值）：

💡 提示：I2P_ANCHOR_DENSIFY_ENABLE=0可跳过 Adaptive Densify，评审阶段会明显更快；若频繁遇到 Critic JSON 报错，可临时设I2P_CRITIC_STRICT_JSON=0走兜底（仅建议用于冒烟测试）。

核心模块速查：

小结：这套设计赢在哪？

• 分数稳定：同样的比较结果 + 锚点 + τ → 永远同一个分数，代码可复现；
• 全程可审计：每个比较、每个锚点的score10 / weight、loss / 单调性违规 / 置信区间都落在audit日志里，可事后追查"为什么是这个分"；
• 杜绝偏差：LLM 全程看不到分数与标题，无锚定、无泄露风险；
• 改稿不碰分：教练层专注字段级修改建议，与评分机制彻底解耦。

一句话总结：让 LLM 做它擅长的相对判断，把绝对打分交给确定性代码——这就是 LLM 评审分数不稳定的工程化解法。📊