fix: 完成 doco src layout 重构,文件移至 src/doco/ 子目录
This commit is contained in:
@@ -0,0 +1,151 @@
|
||||
# 《现代防空反导大对决》三方融合demo实测复盘
|
||||
|
||||
> 日期:2026年5月13日 | 报告人:Claude | 节目时长:26分钟 | 实施耗时:约2小时
|
||||
|
||||
---
|
||||
|
||||
## 一、ASR环节实测数据
|
||||
|
||||
### 1.1 服务选型最终结果
|
||||
|
||||
**最终采用:讯飞开放平台「录音文件转写(标准版)」**
|
||||
|
||||
| 维度 | 实测结果 |
|
||||
|---|---|
|
||||
| 转写耗时 | 5分钟左右(26分钟音频) |
|
||||
| 识别句子数 | 307句(含片尾彩蛋) |
|
||||
| 主体节目识别 | 297句对齐节目主体 |
|
||||
| 关键术语识别率 | **接近100%**(开启35条热词后) |
|
||||
| 数字/百分比识别 | 100%准确 |
|
||||
| 文档显示价格 | 5小时免费试用包,1年有效期 |
|
||||
|
||||
### 1.2 ASR亮点
|
||||
|
||||
- 讯飞自动加入了合理的标点(句号、逗号、问号)
|
||||
- 开启 `eng_smoothproc=true` 和 `eng_colloqproc=true` 后,已自动清理了大部分"嗯/那个/呃"等口语词
|
||||
- **热词机制效果显著**:`霍拉姆沙赫尔-4` `见证者-136` `塔米尔` `大卫投石索` `本古里安` `拉斐尔` 等生僻军事术语全部正确识别
|
||||
- 句子级时间戳精准,可直接与B稿做时间对齐
|
||||
|
||||
### 1.3 ASR短板(需要A稿术语表后处理修正)
|
||||
|
||||
| 错误类型 | 实例 | 修复依据 |
|
||||
|---|---|---|
|
||||
| 同音误识 | "中端/末端" → 应为"中段/末段" | A稿术语 |
|
||||
| 同音误识 | "中诚防御" → 应为"中程防御" | A稿术语 |
|
||||
| 事实错误 | "美伊两国" → 应为"美以两国"(最严重) | A稿/语境 |
|
||||
| 表述偏好 | "高超声速" → A稿用"高超音速" | A稿术语统一 |
|
||||
| 百分比表达 | "百%" → 应为"100%" | 后处理规则 |
|
||||
| 数字表达 | "数10" → 应为"数十" | 后处理规则 |
|
||||
| 口语词残留 | 专家发言里仍有"啊呢这个" | 部分保留以反映播出状态 |
|
||||
|
||||
### 1.4 关于'美伊→美以'这类事实错误的反思
|
||||
|
||||
ASR第18行把"美以两国"识别成了"美伊两国"。**这是最危险的一类错误**——拼音相同、字形不同,单独看ASR文本完全像是合法的事实陈述("美国和伊朗两国协同向伊朗发起军事打击"语义虽然荒谬但句子通顺),人工审校如果不熟悉上下文也可能漏过。
|
||||
|
||||
这印证了交接说明里的设计判断:**A稿的术语和事实必须作为权威源参与融合**,不能让ASR单独输出,否则会引入危险的事实错误。
|
||||
|
||||
---
|
||||
|
||||
## 二、三方融合环节关键决策点
|
||||
|
||||
### 2.1 把握大的判断(demo中AI判断高确信度)
|
||||
|
||||
1. **整段删除的识别**:A稿【解说2】末尾'雷达被誉为中段反导体系的眼睛...'在B稿和ASR里完全找不到对应内容 → 信号非常明确,删除
|
||||
2. **整段重复笔误**:A稿【专家7】和【专家8】内容字符完全相同 → 编导笔误,按ASR的真实内容(讲效费比)替换【专家8】
|
||||
3. **术语事实错误的修复**:ASR'美伊→美以'类同音错误 → A稿权威覆盖
|
||||
4. **OCR错字的批量修复**:'肘→时''娈→变''夭→天'等字形混淆 → ASR提供正确版本
|
||||
|
||||
### 2.2 把握较小的判断(demo中AI判断中等确信度,未来需要编导确认)
|
||||
|
||||
1. **解说6"整段改写"的边界**:A稿80字版本和ASR/B稿40字版本,**究竟保留哪个细节合并哪个细节**——目前demo直接采用了ASR的40字版本,但A稿那80字版本里有"信任危机""推迟采购方案"等A稿独有的内容,编导可能想保留。**未来应该让编导在UI上看diff后人工确认**
|
||||
2. **专家发言的口语词处理**:'呢''啊'保留多少?太多影响阅读,太少违背播出真相。本次demo保留较多,倾向"播出真相"。**未来可做个可调档位("完全保留口语 / 中度清理 / 完全书面化"三档)**
|
||||
3. **A稿首句被改写的情况**:A稿"观众朋友们,你们好!欢迎来到这一期的《军事科技》节目",播出时改为了"各位观众,你们好!欢迎收看《军事科技》"——句式接近但用词全变。demo靠手工锚点列表匹配上了,未来要让Claude做语义对齐而非字符匹配。
|
||||
|
||||
### 2.3 把握很小的判断(demo中AI暂时不处理,必须人工确认)
|
||||
|
||||
1. **句子级的微小增删**:如A稿"在涉及远、中、近程"和ASR"在涉及远中近程"——只是顿号差异。这种差异融合时按ASR走、还是按A稿格式来?**未来UI应该展示句子级diff让编导决定**
|
||||
2. **专有名词的简写问题**:A稿严格用"爱国者-3",播出时多数说"爱国者"。这是术语统一问题还是口语化问题?**取决于该期节目的风格定位**
|
||||
|
||||
---
|
||||
|
||||
## 三、对正式开发TPS子模块的启示
|
||||
|
||||
### 3.1 模块架构建议
|
||||
|
||||
```
|
||||
[音频上传] → [ASR服务(讯飞)] → [OCR处理(B稿)] → [三方融合引擎] → [编导确认UI] → [终版docx]
|
||||
↓
|
||||
[大模型API(Claude)]
|
||||
```
|
||||
|
||||
**核心是"三方融合引擎"应当分两层**:
|
||||
- **规则层**:OCR错字纠正(固定映射表)、术语统一(A稿术语权威)、时间戳对齐 — 走Python代码
|
||||
- **AI层**:段落对齐、整段改写判定、'编导笔误'识别 — 走大模型API
|
||||
|
||||
### 3.2 关于讯飞ASR的具体集成建议
|
||||
|
||||
**应该写进project_design.md【外部依赖】章节的内容**:
|
||||
|
||||
1. 优先使用讯飞「录音文件转写(标准版)」API,**不要**用大模型版(免费包阉割了language参数)
|
||||
2. 音频必须先转码为 **16kHz / 单声道 / 16bit WAV**,否则讯飞会报误导性的`language verify fail`错误
|
||||
3. **热词词库**是关键能力:每期节目从A稿提取专业术语作为热词上传给ASR
|
||||
4. **领域参数** `pd=mil` 对军事节目有显著效果
|
||||
5. 开启 `eng_smoothproc=true` + `eng_colloqproc=true` 让ASR输出更接近书面文稿
|
||||
6. 讯飞密钥分两套:消费端(讯飞听见App)和开发端(讯飞开放平台),**互不相通**
|
||||
7. "免费5小时"需要走0元购买流程才激活,不是看到额度就能用
|
||||
|
||||
### 3.3 关于大模型融合提示词的设计
|
||||
|
||||
未来正式开发时调Claude API做段落对齐,prompt应该包含:
|
||||
|
||||
- **输入1**:A稿全文 + 标签序列
|
||||
- **输入2**:ASR结果(句子+时间戳)
|
||||
- **输入3**:B稿OCR结果(句子+时间戳,作为交叉验证)
|
||||
- **任务1**:把ASR句子按A稿标签序列归类
|
||||
- **任务2**:对每段标记改动类型(无变化/细微改写/整段改写/整段删除/整段新增)
|
||||
- **任务3**:对'高把握'改动直接产出终版;对'低把握'改动标记原因,等编导确认
|
||||
- **任务4**:识别A稿术语和ASR结果的字形/同音差异,用A稿权威修正
|
||||
|
||||
### 3.4 关于编导确认UI的设计
|
||||
|
||||
借鉴本次demo发现的痛点,UI应该至少提供:
|
||||
|
||||
- **左中右三栏diff视图**:A稿原文 | 终版 | ASR/B稿(带时间戳,可点击播放对应音频片段)
|
||||
- **改动类型颜色编码**:删除红色 / 改写黄色 / 术语修正蓝色 / 无变化白色
|
||||
- **逐段确认按钮**:接受 / 拒绝 / 编辑 / 标记疑问
|
||||
- **口语清理强度滑杆**:让编导决定保留多少口语词
|
||||
- **导出按钮**:终版docx / 差异报告 / 复盘CSV
|
||||
|
||||
---
|
||||
|
||||
## 四、实测耗时分解(用于未来效率评估)
|
||||
|
||||
| 阶段 | 实测耗时 | 主要消耗 |
|
||||
|---|---|---|
|
||||
| 讯飞ASR申请+踩坑 | 约45分钟 | 大模型版语种权限问题、音频规格转码 |
|
||||
| 老版讯飞ASR调通 | 约15分钟 | 申请+脚本+调用 |
|
||||
| 三方解析 | 约5分钟 | A稿/B稿/ASR解析为统一结构 |
|
||||
| 段落对齐 | 约15分钟 | 锚点匹配算法+单调推进 |
|
||||
| 术语规范化+口语清理 | 约5分钟 | 字符级规则映射 |
|
||||
| 终版docx生成 | 约5分钟 | python-docx写文档 |
|
||||
| 差异报告+复盘 | 约15分钟 | 这份报告本身 |
|
||||
|
||||
**总耗时约2小时**,其中近一半花在讯飞踩坑上——正式开发后这部分会清零,每期实际处理时间预计15-30分钟(取决于改动幅度)。
|
||||
|
||||
---
|
||||
|
||||
## 五、给您(刘统制片)的几点直接建议
|
||||
|
||||
1. **TPS正式开发时,不必把ASR作为强依赖**。本次demo证明,即便没有ASR,A稿+B稿做二方融合也能产出接近播出版的终版。ASR的价值在于"独立第三方仲裁"——值得做但不应阻塞主流程。
|
||||
|
||||
2. **A稿术语表应该入库管理**,作为TPS的核心知识资产之一。每期节目处理时都从该表查找"权威术语",自动覆盖ASR的同音错误。本次demo手工列出的35个热词清单是个起点。
|
||||
|
||||
3. **节目编导习惯的差异要预留可配置项**。比如有的编导喜欢保留口语词、有的喜欢全部规整化;有的喜欢保留专家发言的原始措辞、有的喜欢编辑过的书面版本。这些应该在配置文件里,而不是硬编码。
|
||||
|
||||
4. **差异报告的价值可能比终版docx更大**。每期节目处理完,差异报告其实是个"编导工作回顾"——能看到自己当初做了哪些删改、哪些是OCR错字。长期累积下来可以分析编导的删改偏好,作为节目优化的素材。
|
||||
|
||||
5. **本次踩的坑值得专门整理一个"讯飞集成踩坑笔记"文档**入TPS知识库。未来下次开发新供应商接入时(比如阿里云ASR),可以走更顺的路。
|
||||
|
||||
---
|
||||
|
||||
*本复盘为demo阶段产物,不代表正式开发的最终决策。所有结论以下次设计文档为准。*
|
||||
Reference in New Issue
Block a user