AIclinicalresearch/docs/03-业务模块/RVW-稿件审查系统/08-技术架构建议/智能审稿终极稳定架构白皮书.md

智能审稿系统 - 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）解决排版展示，才是云原生时代的终极稳定架构。