HaHafeng
ba464082cb
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
89 lines
6.6 KiB
Markdown
89 lines
6.6 KiB
Markdown
# **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 写入原因。前端的“琥珀色警告横幅”会自动提示用户该模块暂时失败，保证系统的绝对健壮性。 |