Files

HaHafeng ba464082cb feat(core): finalize rvw stability updates and pending module changes

Summary:
- Harden RVW prompt protocol handling and methodology review flow with 20-checkpoint coverage, divide-and-conquer execution, and timeout tuning
- Update RVW frontend methodology report rendering to show real structured outputs and grouped checkpoint sections
- Include pending backend/frontend updates across IIT admin, SSA, extraction forensics, and related integration files
- Sync system and RVW status documentation, deployment checklist, and RVW architecture/plan docs

Validation:
- Verified lint diagnostics for touched RVW backend/frontend files show no new errors
- Kept backup dump files and local test artifacts untracked

Made-with: Cursor

2026-03-14 00:00:04 +08:00

6.6 KiB

Raw Blame History

RVW 模块方法学解析失败 - 架构方案评审意见

仔细阅读了您的分析与解决方案，以及《RVW稿件审查模块 - 当前状态与开发指南 (v6.1)》，我对您的整体思路表示高度赞同。您的分析非常精准地抓住了当前大模型（LLM）工程化落地中的核心痛点：人类语言的弹性与机器协议的刚性之间的矛盾。

以下是我对您方案的详细评审，包括我完全认可的部分，以及我认为需要微调或补充的“不认可/需优化”部分。

✅ 一、我完全认可的观点（高度赞同）

1. 对“为什么必须是 JSON”的业务判定

完全认可。 您的分析一针见血。在 RVW V3.0.1 的架构中，方法学评估并不是一个“终点”，而是流水线的一环。

系统依赖解析出 overall_score 和 methodologyStatus 来更新数据库。
前端的 MethodologyReport.tsx 和 TaskDetail.tsx 依赖结构化数组（parts[]/issues[]）来渲染多维度的进度条和增量展示。
如果退化为纯文本，RVW 模块引以为傲的“4模块并行”、“增量结果持久化”和“结构化 Word 导出”将全线崩溃。

2. 对“核心区别：软约束 vs 硬约束”的定性

完全认可。 仅在 Prompt 中强调“请输出JSON”是典型的软约束。业务专家在运营端（PromptService）修改提示词时，往往会引入更多复杂的业务逻辑描述，这极易稀释模型对格式指令的注意力（Attention 偏移），导致模型在输出时“情不自禁”地加上“好的，以下是评估结果：”等前缀，从而破坏 JSON 解析。

3. 将“方案A（Structured Output）”作为最优解

完全认可。 采用 Function Calling 或 Structured Output（Response Format）是当前 LLM 工程界的最佳实践。它将“格式对齐”的工作下沉到了 API 协议层甚至模型的推理采样层（通过 Logits 掩码强制符合 Schema），从而释放了 Prompt 的空间，让 Prompt 可以纯粹服务于业务逻辑。

❌ 二、我不完全认可 / 需要补充完善的观点

虽然大方向极佳，但从您当前的系统架构（已使用 DeepSeek-V3，具有 LLMFactory 和 PromptService）来看，有几个工程落地的细节我不完全认可或认为需要优化：

1. 关于“方案B：先自然语言，再二次抽取结构”的定位

您的观点：这是一个可选方案，增加了修复层。
我的意见（不推荐）：在你们当前的 V3.0.1 架构中，极度不建议将其作为常规链路。你们的核心指标是“上传到出报告 < 3分钟（4模块并行）”。如果方法学每次都跑两遍 LLM（甚至第二遍还要等第一遍长文本生成完），不仅 token 成本翻倍，时延也会大幅增加，破坏现有的并发体验。二次抽取只能作为万不得已的 Error Retry 兜底，绝不能是主干方案。

2. 关于“schema优先 + JSON兜底”的必要性

您的观点：优先走结构化输出，失败再走 JSON 解析或修复，本质是多层容灾。
我的意见（略显冗余）：现在的基座模型（如你们默认的 DeepSeek-V3 和备选的 Qwen3-72B）对 Structured Output / JSON Mode 的支持已经非常成熟。
- 如果您在 API 层面开启了 response_format: { type: "json_object" } 或提供了强 Schema，模型返回的一定是格式完好的 JSON 字符串。
- 此时如果解析失败，往往是模型幻觉导致缺少必填字段，而不是JSON格式本身损坏。因此，容灾的重点不应是“尝试用正则重新抠 JSON”，而应该是直接记录 error_details（你们已在 V3.0 支持 partial_completed）并触发基于格式错误的重试逻辑。

3. 遗漏了最核心的系统层解法：“Prompt 动静分离”（关键补充！）

您的方案主要集中在 LLM 的调用方式上，但忽略了运营管理端的设计缺陷。专家修改 Prompt 导致 JSON 崩坏，根本原因是专家触碰了他们不该触碰的代码约定。

真正的解法：在您的 PromptService 中，应该将 Prompt 拆分为两部分：
1. System/Format Prompt（系统保留，研发控制）：包含严格的 JSON Schema 定义、输出格式要求等。这部分在前端运营管理后台是隐藏或只读的。
2. Business Criteria Prompt（专家可编辑）：仅包含纯粹的评估标准，如“如何判定T检验误用”、“FINER标准是什么”。
3. 最终组装：在 MethodologySkill 执行时，由代码自动将两部分拼接发送给 LLM。这样无论专家怎么改业务逻辑，都不会破坏格式指令。

🚀 三、针对 RVW V3.0.1 的具体落地建议

结合您的现有代码结构（backend/src/modules/rvw/），我建议您按以下三步实施“彻底解决 JSON 崩溃”的方案：

Step 1: 在 LLMFactory 中启用 JSON Mode

修改 @/common/llm/LLMFactory，支持传入 response_format 或 tools。DeepSeek-V3 原生支持强校验的 JSON 输出。

// 示例：强制要求模型仅返回 JSON
const response = await llmClient.chat.completions.create({
model: 'deepseek-chat',
messages: [...],
response_format: { type: 'json_object' } // 启用 JSON Mode
});

Step 2: 实施 Prompt 动静分离 (改造 PromptService)

在数据库 prompt_templates 表或 MethodologySkill 中做拆分：

// 在 methodologyService.ts 或 methodologySkill.ts 中组装
const formatInstruction = `
你必须严格按照以下 JSON 结构输出结果，不要包含任何额外的解释文本或 Markdown 标记：
{
"overall_score": 85,
"methodologyStatus": "error" | "warn" | "pass",
"parts": [
{ "name": "统计方法描述", "issues": [{"severity": "high", "desc": "..."}] }
]
}`;

// expertPrompt 是专家在运营管理端配置的内容
const finalPrompt = expertPrompt + '\n\n' + formatInstruction;

Step 3: 善用 V3.0 现有的 partial_completed 兜底

既然 V3.0 已经实现了 Promise.allSettled 和 error_details，如果（极小概率下）大模型返回的 JSON 缺少了关键字段导致 Schema 校验失败（比如少了 parts 数组）：

不要尝试用正则表达式去猜。
直接 throw new Error("Methodology JSON schema validation failed")。
让外层的 SkillExecutor 捕获，把当前任务标记为 partial_completed，并在 error_details 写入原因。前端的“琥珀色警告横幅”会自动提示用户该模块暂时失败，保证系统的绝对健壮性。

6.6 KiB Raw Blame History Unescape Escape