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
99 lines
7.5 KiB
Markdown
99 lines
7.5 KiB
Markdown
# **智能审稿系统 \- LLM 输出格式隔离与终极稳定架构白皮书**
|
||
|
||
**文档目的：** 彻底解决大模型“自然语言排版”与“系统结构化解析”之间的抢占与冲突，提供可作为平台底层规范的长期稳定架构方案。
|
||
|
||
**适用场景：** RVW 智能审稿、AIA 报告生成、ASL 深度检索总结等一切需要“既要系统存数据，又要给用户看报告”的业务。
|
||
|
||
## **一、 问题本质：为什么大模型总会“格式崩盘”？**
|
||
|
||
大模型本质上是一个“词汇接龙”的概率引擎。当我们要求它\*\*“既做评判专家（逻辑分析），又做排版文秘（JSON转义与文本排版）”**时，它面临着严重的**职责过载 (Responsibility Overload)\*\*。
|
||
|
||
1. **Attention（注意力）稀释**：Prompt 中复杂的业务规则（20条标准）占用了大量的注意力权重，导致模型在生成到后半段时，往往会“忘记”输出合规的格式。
|
||
2. **JSON 转义灾难**：如果采用“将长文本报告塞入 JSON 字段”的做法，模型需要在生成长文本时，对每一个回车换行（\\n）、双引号（\\"）进行严格的转义。一旦模型在几千字中漏掉一个转义符，前端 JSON.parse() 就会直接崩溃。
|
||
|
||
## **二、 终极演进方向：大模型的 MVC 架构 (LLM-MVC)**
|
||
|
||
软件工程中解决耦合的终极方案永远是**分层**。我们需要将大模型的工作流拆分为 **Model（数据层）**、**View（展示层）** 和 **Controller（控制层）**。
|
||
|
||
* **Model (判官)**：彻底剥离排版任务。LLM **只负责**看文章、找问题、打分。强制输出极致精简的、无大段长文本的 JSON 数据。
|
||
* **View (文秘)**：负责将精简的 JSON 数据，渲染成带有专家个人风格（1/2/3 排版、温暖/严厉口吻）的自然语言报告。
|
||
* **Controller (系统)**：负责业务调度、存库、进度条控制。
|
||
|
||
基于这个核心思想，针对贵司当前的基建现状，有以下三套递进的终极解决方案：
|
||
|
||
## **三、 三套终极解决方案 (按彻底程度递进)**
|
||
|
||
### **方案 A：底层原生强约束 (Structured Outputs) —— “从 API 层面锁死”**
|
||
|
||
不要在 Prompt 里写“请输出 JSON”，这是软约束。
|
||
|
||
各大主流模型（OpenAI, DeepSeek-V3）均已支持底层的结构化输出能力。
|
||
|
||
* **架构实现**：
|
||
1. 在你们后端的 LLMFactory / StreamingService 中，调用模型时强行传入 response\_format: { type: "json\_schema", json\_schema: {...} }。
|
||
2. 这个 Schema 由系统通过 Zod 或纯 JSON Schema 严格定义（必须有哪些字段，字段必须是枚举或数字）。
|
||
3. 此时，大模型在底层的 Logits 采样阶段就会被加上 Mask（掩码），**它在物理层面上根本无法输出破坏 JSON 结构的 Token**。
|
||
* **优点**：100% 解决 JSON 解析错误，改造成本极低。
|
||
* **缺点**：依然没有解决“专家想自定义报告文本排版”的问题，且如果 JSON 中包含超长文本，依然可能导致 Token 浪费和轻微的截断。
|
||
|
||
### **方案 B：纯数据 JSON \+ Handlebars 动态模板 —— “零幻觉的完美解”**
|
||
|
||
💡 强烈推荐！我看你们在 ADMIN Phase 3.5.2 中已经实现了 Handlebars，这是最完美的契合点！
|
||
|
||
完全剥夺大模型的排版权利，大模型只负责提取“缺陷数据”。专家的排版要求，通过 Handlebars 模板在运营后台配置。
|
||
|
||
* **工作流**：
|
||
1. **大模型推理**：输出极其干燥的数据（仅供系统流转）。
|
||
{
|
||
"score": 80,
|
||
"issues": \[
|
||
{"code": "ME-01", "name": "未做共线性检验", "suggestion": "补充 VIF 检验"}
|
||
\]
|
||
}
|
||
|
||
2. **专家后台配置 (View 模板)**：主编在运营管理端，像写 Word 模板一样配置：
|
||
\#\#\# 方法学预审报告
|
||
您好，本次得分：{{score}} 分。
|
||
系统发现了以下 {{issues.length}} 个问题：
|
||
{{\#each issues}}
|
||
{{@index}}. 【{{this.name}}】：建议您 {{this.suggestion}}。
|
||
{{/each}}
|
||
|
||
3. **系统渲染**：后端将 LLM 吐出的 JSON 喂给 Handlebars 模板，瞬间生成纯净的 Markdown 报告推给前端。
|
||
* **优点**：
|
||
* **彻底解耦**：专家爱怎么改排版就怎么改，永远不会导致系统报错。
|
||
* **极致稳定**：LLM 只需要输出极短的 JSON，速度飞快，绝无转义灾难。
|
||
* **复用基建**：完美复用你们已有的 PromptService 和 Handlebars 引擎。
|
||
* **缺点**：要求主编掌握一点点 {{}} 占位符的写法（运营端可提供可视化插入按钮来降低门槛）。
|
||
|
||
### **方案 C：双轨 Agent 协同管线 (Pipeline/Map-Reduce) —— “高度拟人化的终局”**
|
||
|
||
如果期刊主编不仅要求格式，还要求极度灵活的语气（例如：“如果得分低于 60，就在开头严厉批评；如果高于 80，就热情表扬”），这就超出了 Handlebars 静态模板的能力。此时需要引入**双 Agent 协同**（类似你们 SSA 模块的 Plan-and-Execute 架构）。
|
||
|
||
* **工作流**：
|
||
1. **Agent 1 (方法学判官 Evaluator)**：搭载复杂的 20 项规则 Prompt，负责深度思考和“找茬”。开启严格的 JSON 模式，只输出结构化问题列表，后台落库。
|
||
2. **Agent 2 (撰稿编辑 Writer)**：接到 Agent 1 的 JSON 后被唤醒。它的 Prompt 是主编配置的口吻与格式要求（“请根据以下 JSON 缺陷数据，以极其严厉的专家口吻，按 1/2/3 的格式写一封给作者的退修信”）。
|
||
3. **流式输出 (Streaming)**：Agent 2 直接采用流式 SSE 输出纯 Markdown 文本，前端打字机般实时渲染给责编。
|
||
* **优点**：
|
||
* **终极体验**：前端用户看到的是行云流水的打字效果，而后端数据库早已稳稳存下了 Agent 1 的结构化数据。
|
||
* **职责单一**：每个 LLM 都在做自己最擅长的事，能力被压榨到极致。
|
||
* **缺点**：消耗 2 次 LLM 调用，略微增加 Token 成本与耗时。但在多模块并行（Promise.allSettled）架构下，这一点时间是可以被接受的。
|
||
|
||
## **四、 给 RVW 模块 V4.0 的最终决策建议**
|
||
|
||
综合考量贵司“敏捷迭代”、“已有基建（Handlebars/PromptService）”和“商业化 SaaS”的诉求，我建议采取 **方案 B 作为核心底座，特定场景引入方案 C** 的融合架构：
|
||
|
||
#### **第一步：重构 PromptService 的输入输出协议 (落实方案 B)**
|
||
|
||
1. 运营端页面拆分：将现有的一个大输入框，拆分为\*\*【评判标准库 (Prompt)】**和**【报告展示模板 (Handlebars)】\*\*两个配置区。
|
||
2. 约束模型：系统底层强制开启模型的 Structured Output (JSON Schema)，LLM 输出只用于落库和填充模板。
|
||
|
||
#### **第二步：引入双通道确认机制 (类似 SSA Phase IV)**
|
||
|
||
在责编工作台中，左侧是 AI 找出的【结构化问题卡片】（供责编打勾/忽略），右侧是实时根据勾选状态，利用 Handlebars 重新渲染的【最终意见函预览】。
|
||
|
||
#### **长期演进**
|
||
|
||
当遇到需要根据不同分数输出截然不同口吻的高级定制化期刊时，再为该期刊开启 **方案 C (双 Agent 模式)**，把撰写意见函的工作交给 Writer Agent 实时生成。
|
||
|
||
**总结**：不要试图在一个 Prompt 里用自然语言去“恳求”大模型兼顾结构化和排版。**用底层 API（JSON Schema）锁死结构化数据，用中间层引擎（Handlebars / Writer Agent）解决排版展示**，才是云原生时代的终极稳定架构。 |