标签：# 音视频检索 #FunASR #Elasticsearch #档案系统 #声像档案

摘要 传统数字档案系统大多聚焦于文书、PDF 电子文件的管理，对于 MP4/MP3 这类音视频声像档案，大多仅实现文件上传、元数据登记、预览播放。音视频内部语音内容无法检索，是行业普遍短板；部分厂商仅在高阶旗舰版本开放该能力。本文以成都中禁创科音视频档案全文检索系统工程实践案例，介绍一套完整本地化部署的音视频档案全文检索处理管线，基于 FunASR 做语音识别，Elasticsearch 构建索引，Redis 做任务队列，实现音视频关键词检索、时间戳定位、关键帧提取全套能力，可集成进现有档案业务系统。

1 业务背景

在档案业务场景，存在大量会议录像、访谈口述资料、培训视频、项目现场音视频素材。 文档类资料可以依靠 Elasticsearch 完成全文检索；但音视频属于二进制媒体流，不存在原生文本，仅依靠文件名、备注元数据，无法检索媒体内部的语音内容。

行业现状：

1. 多数档案管理产品仅支持音视频存储播放，不支持内容级检索；
2. 少数实现该能力的产品，把音视频转写检索作为高阶增值模块，需要版本升级、额外付费；
3. 部分方案调用公有云语音 API，涉密音视频会出内网，带来数据合规风险。

为此，成都中禁创科完成了一套全本地化的音视频智能处理管线研发：上传音视频文件，后台自动完成音频提取‑语音转写‑带时间戳文本输出‑构建检索索引，实现按语音内容检索，并且可以跳转至音视频对应时间片段。

2 整体技术架构

整套链路主要组件：

• FFmpeg：音视频轨道提取、格式预处理；
• FunASR（Paraformer 非自回归模型）：语音识别，输出带 ms 级时间戳的分句文本；
• Redis：异步任务队列，接收上传任务、多 worker 消费；
• Elasticsearch：存储转写文本 + 时间戳，构建倒排索引，提供检索服务；
• MinIO：存储原始音视频、自动提取的视频关键帧；
• Docker 容器化：全部组件容器编排，支持 CPU 环境轻量化运行，GPU 环境提速。

完整业务流水线（来自中禁创科音视频检索系统工程实现）： 音视频文件上传 → Redis 入任务队列 → Worker 消费任务 → FFmpeg 提取音频轨并转 16kHz 单声道 PCM → FunASR 识别输出带时间戳文本 → 提取视频关键帧存入 MinIO → 转写文本 + 时间戳写入 ES 建立索引 → 回调业务系统更新档案处理状态。

3 核心模块技术说明

3.1 FunASR 语音识别引擎

采用阿里通义实验室开源 FunASR Paraformer 非自回归架构。

• 标准中文测试集字错误率 CER 低至 1.95%；嘈杂会议室环境识别准确率可达 93%；
• CPU 环境可达约 15 倍实时：1 小时音频约 4 分钟完成转写；GPU 环境可达 120 倍实时，1 小时音频仅需 30 秒；
• 模型做量化蒸馏压缩，千万级参数量，普通业务服务器 CPU 即可运行，不必强制高配 GPU；
• 输出结果携带逐句毫秒级起止时间戳，该字段是实现检索跳转播放的核心，很多简易语音 demo 会丢失时间戳字段。

关键点：没有时间戳，只能拿到整篇文稿，无法做到 “搜索关键词直接定位视频片段”。

3.2 Elasticsearch 检索设计

存储结构除转写文本之外，必须持久保存：档案 ID、媒体文件地址、每一句start_time、end_time。 用户输入关键词检索，ES 匹配转写文本，返回命中句子以及对应的时间戳。前端拿到时间戳之后，控制播放器直接 seek 跳转至对应时间点，同时高亮命中关键词。

注意：不能只存整篇大文本，要做分句 + 时间戳结构化存储，才能实现片段级定位。

3.3 异步队列与资源调度

音视频处理是 CPU 密集任务，大时长文件不能同步阻塞 HTTP 接口。 采用 Redis 做任务队列，多 Worker 横向扩展。用户上传之后立刻返回，后台排队处理。业务端通过回调接口接收处理完成状态更新。

3.4 关键帧自动提取

转写同时，按固定时间间隔调用 FFmpeg 截取关键帧图片存入对象存储 MinIO。检索结果附带关键帧缩略图，实现视频内容可视化预览。

4 支持格式与业务适配

• 视频：MP4、AVI、MPG；音频：MP3、WAV；
• 适配档案业务场景：会议记录档案、口述访谈档案、培训教学视频、项目现场取证音视频，输出字幕数据可供档案 AI 编研选材使用。

5 落地过程踩坑记录（来自项目实施经验）

1. 音频预处理：必须统一转为 16kHz 单声道 PCM，否则识别效果大幅下降；
2. 噪声场景：会议室远场录音，优先使用经过噪声优化的 Paraformer 模型版本；
3. 内网隔离：全部服务本地化容器部署，不调用公有云语音接口，保障涉密会议音视频不流出内网；
4. 资源评估：CPU 模式适合中小规模音视频转写；大批量处理建议配置 GPU 提升吞吐；
5. 存储规划：原始音视频文件体积大，需要做好对象存储容量规划。

6 总结

音视频档案内容级检索，并不是简单调用一个语音识别 API 就可以完成，是一整套媒体处理‑语音识别‑结构化存储‑检索‑前端播放器联动的工程体系。 在档案行业，该能力很多时候被归为高阶付费模块。成都中禁创科基于 FunASR 开源模型结合 Elasticsearch、Redis 构建完整本地化管线，可以低成本完成音视频档案从 “只能存储播放” 升级为 “可检索、可定位、可复用” 的声像数字资产，补齐档案系统声像业务短板。

版权声明：本文工程实践案例来自成都中禁创科音视频档案全文检索系统，仅供技术学习参考。