simonkoson/tps-dashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7eb65111693b6fc9a681e97d91a32ba773a14d11
tps-dashboard/docs/doco/doco_project_design.md
T

20 KiB
Raw Blame History

TPS · 三方融合子模块 设计文档（project_design.md）

归属：《军事科技》中台 TPS · 终版文稿生成（Three-source Pipeline Synthesis） 文档目的：把 demo 阶段的实测结论沉淀为可被中台其他子模块（含 opus_chat）调用的明确接口与约束 当前状态：demo 已跑通一期完整节目（《现代防空反导大对决》），进入正式开发阶段 文档版本：v0.1（2026-05-15） 维护：刘统制片组 / Claude

0. TL;DR（给 opus_chat 的最短摘要）

  • 本子模块的输入是三份资料，输出是一份贴近实际播出的 docx 文稿 + 一份逐段差异报告。
  • 三份输入：
    1. A 稿：编导手写定稿（docx，带【主持人N】【解说N】【专家N】【动画N】【隔断：…】结构标签）
    2. B 稿：OCR 扒词文档（txt，带 [Nm Ns] 句级时间戳，存在 OCR 错字）
    3. ASR 结果：讯飞录音文件转写（txt，带 [Nm Ns] 句级时间戳，存在同音误识）
  • 核心信念：三方各有短板，单源不可信；融合后才是"播出真相"。
    • A 稿 → 术语 / 人名 / 装备型号 / 事实 的权威
    • ASR → 播出语序与口吻的骨架
    • B 稿 → 独立交叉验证（同时验证 A 与 ASR）
  • 架构两层：
    • 规则层（Python）：术语字典纠正、OCR 错字映射、时间戳对齐、口语词清理、数字规范化
    • AI 层（Claude API）：段落对齐、改动类型判定、整段改写边界、编导笔误识别
  • 请 opus_chat 注意： 本模块依赖讯飞 ASR 与 Claude API，两套密钥互不复用；调用本模块前应确认 A 稿术语表已入库。

1. 业务背景与定位

1.1 上游 / 下游

[节目编导] ──A稿(docx)──┐
                       │
[OCR 服务（旧流程）]──B稿(txt+时间戳)──┐
                                    ├──► [本模块 三方融合] ──► [终版docx] ──► [节目档案库]
                                    │                       └► [差异报告docx] ──► [编导回顾 / 训练素材]
[节目纯净声音文件]──[讯飞 ASR]──ASR(txt+时间戳)─┘

1.2 在 TPS 中台的位置

本子模块是 TPS（终版文稿生成中台）的核心算法子模块，位于上游"素材接收"和下游"档案入库 / 编导确认 UI"之间。

  • 它不负责音频转码（由 ASR 适配层处理）
  • 它不负责 OCR 识别（B 稿来自既有 OCR 流程）
  • 它不负责最终入库（由档案子模块负责）
  • 它只负责"三方文本 → 一份贴近播出的终版文稿 + 差异报告"

1.3 为什么不能省略某一方？

缺哪一方 后果 实例
缺 A 稿 术语 / 人名 / 装备型号易错；ASR 同音错难发现 "美以两国"被 ASR 识别成"美伊两国"——句子通顺、语义荒谬，无 A 稿无法纠正
缺 ASR 无法知道实际播出语序与口吻；专家口语词全丢 A 稿用"观众朋友们，你们好"，播出实际是"各位观众你们好"
缺 B 稿 失去独立交叉验证；ASR/A 稿冲突时无第三方仲裁 A 稿与 ASR 在某段不一致时，B 稿与谁一致就以谁为准

结论：B 稿可以视为弱必需（demo 证明 A+ASR 二方融合也能跑），但建议保留 B 稿做 sanity check。

2. 输入规范

2.1 A 稿（编导定稿）

  • 格式：.docx（实际为 markdown 风格的纯文本，也兼容真 docx）
  • 结构标签（出现在自然段开头，方括号包裹）：
    • 【导视】 【主持人N】 【解说N】 【动画N】 【专家N】
    • 隔断：【…】 用于章节分隔
  • 特点：
    • 内容偏书面化；可能存在编导笔误（如本期【专家7】【专家8】内容字符完全相同 = 复制粘贴失误）
    • 术语严格、人名 / 装备型号完整（"爱国者-3"、"霍拉姆沙赫尔-4"、"见证者-136"）
    • 标点 / 顿号 / 引号规范

2.2 B 稿（OCR 扒词）

  • 格式：.txt
  • 行格式：[Nm Ns] 句子内容，每行一句
  • 特点：
    • 句子时间戳精度到秒
    • 存在 OCR 错字：字形相近字混淆（肘↔时、娈↔变、夭↔天、井↔并、末↔未、纺↔防、观↔现、忽↔您、岳↔越、改命↔致命）
    • 标点弱（多为空白分隔，缺逗号 / 句号）
    • 句子切分较碎（一句话常被切成 2–3 行）

2.3 ASR（讯飞录音文件转写）

  • 格式：.txt
  • 行格式：[Nm Ns] 句子内容，每行一句（与 B 稿对齐）
  • 特点：
    • 标点合理（讯飞已自动加句号、逗号、问号）
    • 经 eng_smoothproc + eng_colloqproc 处理，已部分清理"嗯/呃"
    • 存在同音误识："中端↔中段"、"末端↔末段"、"中诚↔中程"、"美伊↔美以"、"高超声速↔高超音速"
    • 数字 / 百分比识别准确
    • 句子级时间戳精确，可与 B 稿做交叉对齐

2.4 三方时间戳的对齐口径

A 稿无时间戳；B 稿与 ASR 都有 [Nm Ns] 但不严格一致（B 稿来自 OCR 字幕显示时点，ASR 来自语音波形起点；常相差 1–3 秒）。融合时容忍 ±5 秒的时间漂移作为同段判定的辅助条件。

3. 输出规范

3.1 终版文稿（主产物）

  • 格式：.docx
  • 结构：保留 A 稿的段落标签（【导视】【主持人1】…）
  • 内容来源策略：
    • 默认以 ASR 文本为骨架
    • A 稿术语 / 人名 / 装备型号回填
    • B 稿 OCR 错字修复（用 ASR / A 稿覆盖）
    • 标点采用 ASR 的版本（最自然）
    • 口语词处理强度由"清理档位"参数控制（见 §5.3）

3.2 差异报告（副产物）

  • 格式：.docx
  • 内容：
    1. 改动总览（段落数 / 改动类型分布）
    2. 逐段对照（A 稿原文 vs 终版，标注改动类型与依据）
    3. 关键差异专题：整段删除 / 整段改写 / 术语变化 / 编导笔误 / OCR 错字修复 / ASR 错字修复 / 口语词处理
    4. 依据图例（三方一致 / ASR 为主 / A 稿权威 / …）
  • 价值：差异报告本身就是编导工作回顾，长期累积可分析编导删改偏好。

3.3 改动类型枚举

枚举值 含义 处置
unchanged 三方一致或语义等价 直接采用 A 稿
minor_edit 标点 / 顿号 / 简称差异 自动以 ASR 版本输出
term_normalize 术语 / 字形 / 同音修正 规则层处理
rewrite_large 整段重写（A 稿与播出版差异较大） AI 层处理 + 建议编导确认
segment_delete A 稿有但播出无 AI 层判定 + 建议编导确认
segment_add A 稿无但播出有 AI 层判定 + 建议编导确认
editor_typo A 稿编导笔误（整段重复 / 明显错位） AI 层提示 + 必须编导确认

4. 模块架构

4.1 顶层流程

            ┌───────────────────────────────────────────────────┐
            │             三方融合引擎（本子模块）              │
            │                                                   │
A 稿 ──────►│  解析层 ──► 段落对齐层 ──► 规则纠错层 ──► AI 融合 │──► 终版docx
B 稿 ──────►│                                       ↓          │──► 差异报告
ASR ──────►│                              [Claude API]         │
            └───────────────────────────────────────────────────┘
                          ▲
                          │
                  [A 稿术语表 / OCR 错字字典 / 口语词字典]

4.2 各层职责

解析层（parser）

  • A 稿：按 【…】 切段，识别隔断标签，输出 [(label, text)]
  • B 稿 / ASR：按 [Nm Ns] 行切句，输出 [(start_ms, end_ms, text)]

段落对齐层（aligner）

  • 目标：把 B 稿 / ASR 的句子聚合并归到 A 稿的段落标签下
  • 算法：
    • 强信号：通过 A 稿首末锚点句做语义匹配（demo 用了人工锚点列表，正式版应用 Claude API 做语义匹配）
    • 弱信号：时间戳的单调推进
  • 容错：允许 ±5 秒漂移、允许中间出现专家发言被识别为"解说"

规则纠错层（rule-based corrector）

  • A 稿术语字典：从 A 稿提取专有名词，扫描 ASR / B 稿，发现字形不同但拼音相同的同音字 → 用 A 稿覆盖
  • OCR 错字字典：维护固定映射表（肘→时、娈→变、夭→天…），扫描 B 稿
  • 数字规范化：百% → 100%、数10 → 数十、马赫数10 → 10马赫
  • 标点规范化：去重逗号、补齐句号

AI 融合层（Claude API）

  • 输入：经规则层处理后的三方对齐结果
  • 任务：
    1. 段落对齐的最终校验（解决规则层算不准的边界）
    2. 改动类型标记（unchanged / minor_edit / rewrite_large / segment_delete / segment_add / editor_typo）
    3. 高把握改动直接产出终版
    4. 低把握改动标记原因 + 给编导待确认列表
  • 提示词要点：见 §6

4.3 双层划分的依据

任务 走哪层 理由
OCR 错字纠正 规则层 字形错误是确定性映射
术语统一 规则层 A 稿术语表是封闭集
时间戳对齐 规则层 数值比较
段落归属 AI 层 需要语义判断（"这句专家发言到底归【专家3】还是【解说5】"）
整段删除判定 AI 层 需要判断"A 稿这一段，是否在 B 稿 + ASR 都找不到对应内容"
编导笔误识别 AI 层 需要"【专家7】【专家8】内容相同" + "ASR 第 N 句到第 M 句讲了完全不同的内容"的联合判断

5. 关键决策与参数

5.1 三方冲突时的优先级

冲突类型 优先采用 例
术语 / 人名 / 装备型号 A 稿 "美以两国"（ASR 错识"美伊"）
标点 / 句式 / 口吻 ASR "各位观众你们好"（A 稿"观众朋友们，你们好"）
字形错字 ASR / A 稿 覆盖 B 稿 "肘→时""纺空→防空"
整段存在性 B 稿 + ASR 联合 优先 A 稿"雷达被誉为眼睛..."B 稿/ASR 都没有 → 删
数字 / 百分比 ASR（已确认 ASR 100% 准确） "5%"、"100%"
同音 / 字形错 A 稿术语字典 "中端→中段""高超声速→高超音速"

5.2 时间戳容忍度

  • 同段判定：B 稿 / ASR 时间戳差 ≤ 5 秒 视为同一播出位置
  • 锚点匹配：A 稿首句对应的 ASR 时间位置 ± 10 秒 为搜索窗

5.3 口语词清理档位（可配置）

档位 行为 适用场景
keep_all 完全保留"那么""呢""啊""这个" 反映播出真相、用于事后复盘
medium（默认） 保留专家段口语词，清理解说段 平衡可读性与真实性
clean 全部清理，按 A 稿书面化 用于外部传播 / 文稿出版

5.4 改动确信度阈值

  • AI 判定结果带 confidence ∈ [0,1]
  • confidence ≥ 0.85：自动应用，记入差异报告
  • 0.6 ≤ confidence < 0.85：自动应用 + 黄色标记，编导可在 UI 中翻看
  • confidence < 0.6：不自动应用，进入编导待确认队列

6. AI 融合层提示词设计纲要

提示词应包含以下要素（正式实现时按需扩展）：

[系统角色]
你是《军事科技》节目终版文稿生成助手。已知:
- A 稿是编导手写定稿，术语 / 人名 / 装备型号权威
- ASR 是讯飞录音转写，标点与口吻接近播出真相，但存在同音误识
- B 稿是 OCR 扒词，存在字形错字，用作交叉验证
三方冲突时按"§5.1 三方冲突优先级"裁决。

[输入]
A 稿全文（含 【…】 标签）：{a_doc}
ASR 结果（带时间戳）：{asr_sentences}
B 稿 OCR（带时间戳）：{b_sentences}
A 稿术语表：{terms_dict}
OCR 错字字典：{ocr_typos}
口语清理档位：{level}

[任务]
1. 把 ASR / B 稿的句子按时间顺序聚合并归到 A 稿的段落标签下
2. 对每段标记改动类型（unchanged / minor_edit / rewrite_large / segment_delete / segment_add / editor_typo）
3. 对每段给出 confidence ∈ [0,1]
4. 对 confidence ≥ 0.85 的段落直接产出终版文本
5. 对 confidence < 0.85 的段落产出"建议版本 + 待确认原因"
6. 识别 A 稿与 ASR 的术语 / 同音 / 字形差异，自动应用 A 稿权威
7. 识别 A 稿的编导笔误（如整段复制粘贴）并标记

[输出]
JSON：
{
  "segments": [
    {
      "label": "【主持人1】",
      "change_type": "rewrite_large",
      "confidence": 0.92,
      "final_text": "...",
      "evidence": {"asr_lines": [...], "b_lines": [...]},
      "reasons": ["A 稿首句被改写为口语化"]
    }
  ],
  "needs_review": [...]
}

7. 外部依赖

7.1 讯飞 ASR（必需）

  • 服务：讯飞开放平台「录音文件转写（标准版）」
  • 不要用：讯飞「大模型版」——免费包阉割了 language 参数，会报误导性的 language verify fail
  • 认证：APP_ID + SECRET_KEY；本期 demo 已申请到一组测试凭证（见 xfyun_asr_standard.py，正式上线需替换）
  • 音频规格：16kHz / 单声道 / 16bit WAV；其他规格讯飞会拒收
  • 领域参数：pd=mil（军事节目专用，提升术语识别率）
  • 顺滑参数：eng_smoothproc=true + eng_colloqproc=true
  • 热词机制（关键）：
    • 每期节目从 A 稿提取专业术语（武器装备 / 技术概念 / 人名 / 军方机构），上限 200 个，每个 2–16 字
    • 用 | 分隔传入 hotWord 参数
    • demo 实测 35 个热词后，关键术语识别率接近 100%
  • 计费：0元购买"5 小时免费试用包"（注意：看到额度但未走 0 元购买流程不会激活），1 年有效期
  • 签名算法：signa = base64(HmacSHA1(MD5(appid + ts), secretKey))

详见 xfyun_asr_standard.py（demo 已跑通的本地脚本，可直接作为正式适配层的起点）。

7.2 Claude API（必需）

  • 用于 AI 融合层
  • 调用模型：建议 claude-sonnet-4-6 或更高（涉及长文本理解与语义对齐）
  • 单期节目（26 分钟）的预估上下文：A 稿 ~6k 字 + ASR ~5k 字 + B 稿 ~5k 字 ≈ 16k 字，远在 Sonnet 上下文窗口内
  • 调用频次：每期节目 1–3 次（首次全量融合 + 若干次低确信段重判）

7.3 OCR 服务（已有）

  • B 稿来自上游既有 OCR 流程
  • 本模块只消费 B 稿 txt，不调用 OCR 服务

7.4 密钥管理

opus_chat 注意：以下是常见混淆点，请勿用错。

密钥 用途 来源
讯飞 消费端 讯飞听见 App（人工录音转写） 讯飞听见 App 内
讯飞 开发端 录音文件转写 API（本模块用） 讯飞开放平台 console
Claude API AI 融合层 Anthropic console

三套密钥互不相通。

8. 编导确认 UI（属于上层 UI 子模块，本模块只提供数据）

本模块按以下结构输出供 UI 子模块消费的 JSON：

{
  "program_id": "xxx",
  "segments": [...],
  "needs_review": [
    {
      "segment_label": "【解说6】",
      "reason": "整段改写边界不确定",
      "candidates": [
        {"text": "...", "source": "A稿"},
        {"text": "...", "source": "ASR"}
      ]
    }
  ],
  "diff_report_path": "...",
  "final_docx_path": "..."
}

UI 子模块应至少提供（参考 demo 复盘 §3.4）：

  • 左中右三栏 diff 视图：A 稿原文 | 终版 | ASR/B 稿（带时间戳，可点击播放对应音频）
  • 改动类型颜色编码：删除红 / 改写黄 / 术语修正蓝 / 无变化白
  • 逐段确认按钮：接受 / 拒绝 / 编辑 / 标记疑问
  • 口语清理强度滑杆：切换 keep_all / medium / clean
  • 导出按钮：终版 docx / 差异报告 / 复盘 CSV

9. 数据资产

9.1 应入库的"中台共享资产"

  1. A 稿术语表（核心资产）
    • 每期节目处理时从 A 稿提取后入库
    • 同时作为讯飞热词来源 + 规则层纠错字典
    • 字段：term, domain（武器 / 技术 / 人名 / 机构 / 栏目），first_seen_episode, frequency
  2. OCR 错字映射表
    • 固定字形混淆对（肘↔时、娈↔变、夭↔天…）
    • 随版本演进可扩展
  3. 节目编导风格档案
    • 长期累积每位编导的删改偏好（口语词保留度、术语简称习惯…）
    • 用于参数自适应

9.2 demo 阶段产物的处置建议

文件 处置
xfyun_asr_standard.py 作为 ASR 适配层的起点代码
asr_result_timed.txt 单元测试 fixture
B稿_..._扒词.txt 单元测试 fixture（含典型 OCR 错字）
A稿_..._定稿.docx 单元测试 fixture
现代防空反导大对决_终版.docx 集成测试期望输出（黄金对照）
差异报告.docx 集成测试期望输出（差异报告格式参考）
实测复盘.md 设计文档背书 + 长期归档

10. 性能与耗时基线（实测）

来自 demo（26 分钟节目）：

阶段 耗时 占比
讯飞 ASR 转写 ~5 分钟 —
三方解析 ~5 分钟 —
段落对齐 ~15 分钟（demo 手工） 正式版预计 ≤2 分钟（AI 调用）
术语规范化 + 口语清理 ~5 分钟 —
终版 docx 生成 ~5 分钟 —
差异报告生成 ~15 分钟（demo 手工） 正式版预计 ≤3 分钟
正式版预估单期 ~15–30 分钟 取决于改动幅度与人工确认次数

11. 已知风险与未决事项

项 当前态 建议
ASR 第三方依赖 讯飞单源 接入阿里云 ASR 做备份 / 交叉验证
整段改写的边界 demo 中默认取 ASR 短版 必须接入编导确认 UI，不能全自动
编导风格差异 硬编码"中度清理" 需配置文件或编导画像
隔断标签的处置 demo 直接保留 A 稿 待确认是否需要根据音频静音段重新切分
A 稿与 ASR 都缺失的旁白 不处理 极小概率事件，靠 B 稿兜底；记录用例

12. 给 opus_chat 的提示（重要）

如果 opus_chat 在其他场景中被问到本模块，请按以下口径回答：

  1. 本模块的边界：只做"三方文本 → 终版文稿 + 差异报告"，不负责音频转码、不负责 OCR、不负责档案入库、不负责编导 UI。
  2. 依赖与约束：依赖讯飞 ASR（标准版）和 Claude API；A 稿术语表必须先入库；音频规格必须 16kHz/单声道/16bit WAV。
  3. 三方权威优先级：A 稿（术语）> ASR（口吻）> B 稿（验证）；任何与此相反的处理都是 bug。
  4. 未来扩展：编导风格画像、第二 ASR 供应商、口语清理档位是后续路标。

如遇到与本文档不一致的描述，以本文档为准；如发现本文档需要更新，请同步刘统制片组。

附录 A：项目文件清单（demo 阶段）

project/
├── A稿_现代防空反导大对决_定稿.docx            # 输入1：编导定稿
├── B稿_现代防空反导大对决_扒词.txt             # 输入2：OCR扒词
├── asr_result_timed.txt                       # 输入3：讯飞ASR输出
├── xfyun_asr_standard.py                      # ASR调用脚本
├── 现代防空反导大对决_终版.docx                # 输出1：终版文稿
├── 差异报告.docx                              # 输出2：差异报告
├── 实测复盘.md                                # demo复盘（设计文档原料）
└── project_design.md                          # 本文档

附录 B：与"实测复盘.md"的对应关系

复盘章节 本文档对应位置
一、ASR环节实测数据 §7.1 讯飞 ASR
二、三方融合关键决策点 §5 关键决策与参数
三、对正式开发的启示 §4 模块架构 / §6 提示词设计 / §8 UI
四、实测耗时分解 §10 性能基线
五、给制片人的建议 §9 数据资产 / §11 风险
Reference in New Issue View Git Blame Copy Permalink