实战分享 | 抛弃本地Whisper，我用“通义千问+Paraformer”构建了一套B站收藏视频RAG知识库
摘要：
面对 B 站收藏夹中堆积如山的技术视频，如何高效检索内容？传统的本地部署（Whisper + 本地 LLM）方案对硬件要求高且推理速度慢。本文将分享如何利用 阿里云 DashScope（灵积） 全家桶——Paraformer 进行极速语音转写、Qwen-Max 进行逻辑推理、Text-Embedding-v4 进行向量化，构建一个轻量级、高精度的视频 RAG（检索增强生成）系统。
关键词：阿里云 DashScope，通义千问，Paraformer，RAG，LangChain，Bilibili
一、 项目背景与痛点
作为一个重度技术视频消费者，我的收藏夹里躺着数百个关于 System Design、AI 架构的视频。但视频内容是“黑盒”，无法像文字那样直接检索。
起初，我尝试使用开源的 Whisper 模型在本地进行 ASR（语音转文字），配合本地 LLM 做 RAG。但在实际开发中遇到了明显的工程痛点：
- 显存焦虑：本地跑 Whisper-large + LLM，显存经常爆满，普通笔记本根本跑不动。
- 推理龟速：一段 1 小时的视频，本地转写可能需要 20 分钟，效率极低。
- 中英混杂识别差：技术视频中充满了 "Kubernetes", "Transformer", "Deadlock" 等英文术语，普通模型识别率惨不忍睹。
为了解决这些问题，我决定将核心计算压力“上云”，重构了我的开源项目 Bilibili-RAG，全面接入阿里云 DashScope 能力。
二、 技术架构选型
这是一个典型的非结构化数据 RAG 链路，但每个环节都针对云原生能力进行了优化：
- 数据源：Bilibili 视频/音频流
- 听觉层（ASR）：阿里云 Paraformer-v2（秒级转写，专有名词识别强）
- 记忆层（Embedding）：阿里云 Text-Embedding-v4（多语言向量模型）
- 向量库：ChromaDB（本地轻量存储）
- 大脑层（LLM）：通义千问 Qwen-Max（处理长文本和复杂逻辑）
- 编排框架：LangChain + FastAPI
三、 核心实现与代码解析
1. 解决“听得慢”：集成 Paraformer 语音识别
在 app/services/asr.py 中，我放弃了 subprocess 调用 ffmpeg 推流的传统做法，直接使用了 DashScope SDK 提供的 Transcription 接口。
技术亮点：
- 免显卡：无需本地 GPU。
- 临时存储中转：利用 SDK 自带的 OSS 临时空间，解决了本地文件上传的问题。
- 中英混合优化：开启
language_hints=['zh', 'en']，大幅提升技术术语识别率。
关键代码实现：
from dashscope.audio.asr import Transcription
def _transcribe_sync(self, audio_url: str) -> Optional[str]:
"""
提交离线录音文件识别任务
"""
# 针对技术视频，显式声明中英混合，提升术语识别率
kwargs = {
}
if "paraformer" in self.model:
kwargs["language_hints"] = ["zh", "en"]
try:
# 直接调用 DashScope SDK，支持 URL 或 OSS 路径
resp = Transcription.async_call(
model="paraformer-v2", # 使用 Paraformer-v2 模型
file_urls=[audio_url],
**kwargs,
)
except Exception as e:
logger.warning(f"ASR 提交失败: {e}")
return None
# ... 省略轮询任务状态的代码 ...
实测数据：处理一个 45 分钟的 1080P 视频，本地 Whisper 需要 15 分钟左右，而 Paraformer 仅需 40 秒左右即可返回完整带时间戳的文本，效率提升了 20 倍以上。
2. 解决“甚至不用改代码”：Qwen 的 OpenAI 兼容模式
在 LLM 接入环节，很多开发者担心要重写 LangChain 的调用逻辑。但实际上，阿里云 DashScope 提供了完美兼容 OpenAI 协议的接口。
这意味着：我们不需要使用专用的 Tongyi 类，直接用 LangChain 的 ChatOpenAI 即可。
配置方式（.env）：
# 将 Base URL 指向阿里云的兼容接口
OPENAI_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
# 使用 DashScope API Key
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx
# 指定模型为通义千问 Max
LLM_MODEL=qwen3-max
代码实现（app/services/rag.py）：
from langchain_openai import ChatOpenAI
from app.config import settings
# 初始化 LLM
# LangChain 会自动读取 base_url，从而无缝切换到 Qwen
self.llm = ChatOpenAI(
api_key=settings.openai_api_key,
base_url=settings.openai_base_url,
model=settings.llm_model, # qwen3-max
temperature=0.5
)
这种做法极大地降低了迁移成本，原本基于 GPT-4 开发的 Prompt 和逻辑，几乎可以零成本迁移到 Qwen-Max 上，且 token 成本大幅降低。
3. 解决“搜不准”：兼容性 Embedding 策略
在向量化环节，我使用了 text-embedding-v4。为了保证代码在不同环境下的健壮性，我编写了一套兼容性加载逻辑：优先尝试加载阿里云原生 SDK，如果环境不支持，则回退到标准 HTTP 调用。
代码实现：
# app/services/rag.py
try:
# 优先尝试使用 LangChain 社区版集成的 DashScopeEmbeddings
from langchain_community.embeddings import DashScopeEmbeddings
self.embeddings = DashScopeEmbeddings(
dashscope_api_key=settings.openai_api_key,
model="text-embedding-v4"
)
logger.info("使用 DashScopeEmbeddings 初始化成功")
except ImportError:
# 如果依赖缺失，回退到 OpenAI 兼容模式调用 Embedding
self.embeddings = OpenAIEmbeddings(
api_key=settings.openai_api_key,
base_url=settings.openai_base_url,
model="text-embedding-v4",
check_embedding_ctx_length=False
)
四、 效果演示
基于上述架构构建的 Bilibili-RAG，目前已经实现了以下效果：
- 精准定位：用户提问“并发编程中死锁产生的四个条件是什么？”，系统能精准检索到视频中第 14 分 20 秒的片段。
- 内容总结：利用 Qwen-Max 的长文本能力，可以对几万字的字幕进行高质量摘要，不仅是简单的概括，还能提取出 key points。
(B站视频演示：https://b23.tv/bGXyhjU)
五、 开发者总结
通过这次重构，我深刻体会到了 Cloud-Native AI（云原生 AI） 对于独立开发者的价值：
- 极低门槛：不再受限于本地硬件（显卡、内存），任何一台轻量级云服务器甚至本地笔记本都能运行强大的 AI 应用。
- 工程化便利：DashScope 的 SDK 设计非常开发者友好，特别是 OpenAI 兼容接口，让生态迁移变得异常简单。
- 性能与成本的平衡：Paraformer 的按时长计费和 Qwen 的 Token 计费，对于个人开发者来说，比租用 GPU 服务器划算得多。
如果你也在做 RAG 或音视频处理相关的应用，强烈建议尝试一下 Paraformer + Qwen 的组合，这可能是目前中文语境下性价比最高、开发体验最好的技术栈之一。
参考资源：
- 阿里云 DashScope 文档：https://help.aliyun.com/zh/dashscope/
- 项目源码：https://github.com/via007/bilibili-rag （本项目已开源，欢迎通过代码交流学习）
