基于RAG的视频知识库构建：从多模态信息提取到智能问答实战

1. 项目概述：当视频遇见RAG，我们如何构建一个“会思考”的视频知识库？

最近在折腾一个挺有意思的项目，叫 StreamRAG。简单来说，它想解决一个我们越来越常遇到的问题：如何从海量的视频内容里，快速、精准地找到我们想要的信息？想象一下，你手头有几百小时的内部培训录像、产品发布会录屏，或者是一堆教学视频。当你想找“张三在去年Q3会议上关于某个功能的发言”，或者“李四讲解的那个复杂配置的具体步骤”时，传统方法要么是凭记忆拖动进度条，要么是依赖可能不完整、不准确的字幕文件进行全文搜索，效率极低，且常常找不到。

StreamRAG 这个项目名，直接点明了它的核心技术栈：Stream（流式处理）与RAG（检索增强生成）。它不是一个简单的视频播放器或搜索引擎，而是一个旨在为视频内容构建“智能记忆”的系统。其核心目标，是将非结构化的视频流，通过一系列自动化流水线，转化为结构化的、可被高效检索和问答的知识库。最终，你可以像和一个精通所有视频内容的专家对话一样，用自然语言提问，并立刻得到来自视频片段的精准答案和引用出处。

这背后解决的痛点非常实际。在知识密集型团队、在线教育、媒体资料库等场景下，视频作为信息载体，其价值密度高（包含画面、语音、文字、演示），但“可寻性”极差。StreamRAG 试图打通从“视频数据湖”到“知识答案”的最后一公里。它适合那些拥有大量视频资产，并希望将其知识价值最大化的团队、开发者或技术爱好者。无论你是想为自己团队搭建一个内部视频知识库，还是探索多模态AI的应用前沿，这个项目都提供了一个极具参考价值的实践框架。

2. 核心架构与设计哲学：拆解一个视频RAG系统的四大支柱

要理解 StreamRAG，不能只看它最终酷炫的问答界面，更要深入其设计骨架。一个健壮的视频RAG系统，绝非简单地将文本RAG套用在视频上，它需要专门应对视频这种连续、多模态、高冗余数据的独特挑战。其架构通常围绕以下几个核心支柱展开。

2.1 多模态信息提取：从像素和声波中“榨取”语义

这是整个系统的数据源头，也是最关键、最复杂的一步。视频不是文本，计算机无法直接理解。因此，我们需要一套“组合拳”来提取视频中的结构化信息：

1. 视觉信息提取：通过预训练的视觉模型（如CLIP、DINOv2）对视频进行关键帧采样，并生成对应的图像特征向量。这一步捕获了画面中的物体、场景、人物、图表等视觉语义。更高级的做法可能包括动作识别、OCR（识别视频中的文字，如PPT、字幕）等。
2. 音频信息提取：这是语义的主要来源之一。通过自动语音识别（ASR）技术，将视频中的语音转换为文本。ASR模型的选择至关重要，它需要兼顾准确性、速度和多语言/口音/专业术语的支持能力。提取出的文本（字幕）连同时间戳，构成了视频的时间轴文本流。
3. 元数据与上下文信息：视频文件名、创建日期、分辨率、时长等，虽然简单，但也是重要的检索线索。

实操心得：ASR模型的选择是成败关键。对于中文场景，我强烈建议使用针对中文优化的开源模型，如 FunASR 或 Whisper 的多语言版本。Whisper 虽然通用性强，但在特定领域术语（如技术名词、产品代号）上可能表现不佳。一个实用的技巧是，在ASR后，可以引入一个小的“领域术语纠错”模块，用一个自定义的词表对识别结果进行后处理，能显著提升后续检索的准确性。

所有这些提取出的信息——视觉特征向量、带时间戳的文本、元数据——需要被有机地关联起来，形成一个统一的、带有时序的“视频片段”表示。通常，我们会以固定的时间窗口（如每10秒或每句话）将视频切分成片段（Chunk），每个片段都包含上述所有模态的信息。

2.2 分块与向量化策略：如何为视频“切片”并编码

文本RAG的分块（Chunking）策略已经有很多讨论，但视频分块更为复杂，因为它需要在时间维度上做出合理的切割，同时保证语义的完整性。

1. 基于时间的固定分块：最简单的方法，按固定时长（如30秒）切割。优点是简单均匀，缺点是可能切碎一个完整的句子或概念。
2. 基于语义的分块：这是更优的策略。利用ASR产出的文本和标点，结合语音停顿检测（VAD），在自然的句子或段落边界进行切割。例如，可以在每句话结束、或说话人停顿较长处进行分割。这样得到的每个“块”，在语义上更自洽。
3. 多粒度分块：为了兼顾召回率和精度，可以采用重叠分块或分层分块。例如，同时保存“句子级”小块和“段落级”大块。检索时先粗筛大块，再精查小块。

分块完成后，每个视频块都需要被转化为计算机可以比较的“向量”。这里就涉及到多模态向量编码。主流做法有：

• 文本主导：将视频块的ASR文本、OCR文本等所有文本信息拼接，使用文本嵌入模型（如BGE、text-embedding-ada-002）生成向量。这是目前最主流、效果最稳定的方式，因为语言仍是语义最直接的载体。
• 多模态融合：分别用文本模型和视觉模型生成文本向量和图像向量，然后将它们融合（如拼接、加权平均）成一个联合向量。这种方式理论上能捕获纯文本遗漏的视觉信息，但对融合策略和模型要求高，工程更复杂。

# 一个简化的基于文本的分块与向量化伪代码示例 import whisper from sentence_transformers import SentenceTransformer # 1. 加载ASR模型和嵌入模型 asr_model = whisper.load_model(“base”) embed_model = SentenceTransformer(‘BAAI/bge-large-zh-v1.5’) # 2. 处理视频，提取音频并转写 audio = extract_audio(video_path) result = asr_model.transcribe(audio, word_timestamps=True) # 3. 基于句子进行语义分块 chunks = [] current_chunk = {“text”: “”, “start”: None, “end”: None} for segment in result[“segments”]: for word in segment[“words”]: if current_chunk[“text”] == “”: current_chunk[“start”] = word[“start”] current_chunk[“text”] += word[“word”] current_chunk[“end”] = word[“end”] # 简单以句号、问号等作为分块边界 if word[“word”].strip() in [“。”, “？”, “！”, “.”, “?”, “!”]: if len(current_chunk[“text”]) > 5: # 过滤过短片段 chunks.append(current_chunk.copy()) current_chunk = {“text”: “”, “start”: None, “end”: None} # 4. 为每个文本块生成向量 for chunk in chunks: chunk[“embedding”] = embed_model.encode(chunk[“text”]).tolist()

2.3 检索与重排序：在向量海洋中精准定位

当用户提问时，系统需要从所有视频块中找到最相关的那些。这个过程通常是两阶段的：

1. 向量检索（召回）：将用户的问题也编码成向量，然后在向量数据库（如 Milvus, Qdrant, Pinecone, Chroma）中进行近似最近邻搜索（ANN），召回前K个（比如20个）最相似的视频块。这一步追求高召回率，确保答案可能存在的块不被漏掉。
2. 重排序（精排）：向量检索基于语义相似度，但“相似”不一定等于“能回答问题”。重排序阶段使用一个更精细的、通常是交叉编码器（Cross-Encoder）模型，对用户问题和召回的每一个视频块文本进行深度交互计算，给出一个更精确的相关性分数。然后根据这个分数对Top K结果重新排序，筛选出最顶部的几个（比如3-5个）最相关的块。

注意事项：警惕“幻觉”与无关信息。视频ASR文本常常包含大量口语化填充词（“嗯”、“啊”、“这个”、“那个”）、重复、甚至错误识别。这些噪声会被一并编码进向量。在检索时，如果用户问题恰好与这些噪声词匹配，可能导致召回不相关的片段。因此，在构建索引前，对ASR文本进行简单的清洗（去除停用词、修正明显错误）是很有必要的。重排序模型能在一定程度上缓解这个问题，因为它能理解上下文。

2.4 流式生成与溯源：给出答案并“指明出处”

这是最后一步，也是呈现价值的环节。系统将经过重排序筛选出的、最相关的几个视频块文本（及其时间戳、视频源信息），连同用户的问题，一起构造提示词（Prompt），提交给大语言模型（如 GPT-4, Claude, 或开源的 Llama、Qwen 系列）。

Prompt 的设计至关重要，需要指令LLM：

1. 基于仅提供的视频片段文本上下文来回答问题。
2. 如果信息不足，就诚实地说不知道，严禁编造（减少幻觉）。
3. 在答案中引用具体片段的来源（如“根据视频A在15分30秒处的讲解...”）。

LLM 会生成一个流畅、准确的答案。而“流式”（Stream）在此处可以有两层含义：一是LLM以流式输出的方式逐字返回答案，提升用户体验；二是指整个系统处理视频流数据的特性。最终，用户不仅得到答案，还能直接点击引用跳转到视频的对应时间点进行观看验证，形成了完整的“检索-生成-溯源”闭环。

3. 技术栈选型与实操搭建：手把手组装你自己的StreamRAG

理解了架构，我们来看看如何用具体的工具把它搭建起来。这里我基于一个常见的、可行的开源技术栈，给出一个实操方案。你可以根据自己的需求和资源进行调整。

3.1 核心组件选型解析

1. 视频处理与ASR：

   • FFmpeg：毋庸置疑的音视频处理瑞士军刀，用于提取音频、截取关键帧。
   • OpenAI Whisper：开源ASR的标杆，支持多语言，准确率高，有不同大小的模型权衡速度与精度。对于中文，large-v3模型效果很好。
   • FunASR：达摩院开源，对中文场景优化更深入，特别是在嘈杂环境、专业术语上有时表现更佳，且提供流式ASR接口，更贴合“Stream”理念。
   • 选择建议：如果追求开箱即用和通用性，Whisper是首选。如果主要处理中文，且对实时性有要求，可以深入研究FunASR。

2. 向量数据库：

   • Milvus / Qdrant：专业级、高性能的向量数据库，支持分布式，适合生产环境海量数据。学习曲线稍陡。
   • Chroma：轻量级、嵌入优先的向量数据库，API简单，非常适合原型快速开发和中小规模应用。
   • Pgvector（PostgreSQL扩展）：如果你已有的系统基于PostgreSQL，这是一个非常自然的选择，能统一管理结构化元数据和向量。
   • 选择建议：快速验证想法用 Chroma。准备上生产且数据量大，用 Milvus 或 Qdrant。团队已有PG生态，用 Pgvector。

3. 嵌入模型：

   • 文本嵌入：BAAI/bge系列（如bge-large-zh-v1.5）是当前中文文本嵌入的SOTA选择。英文可选text-embedding-ada-002（OpenAI API）或all-MiniLM-L6-v2（开源轻量）。
   • 多模态嵌入：OpenAI CLIP是经典，能同时编码文本和图像。对于视频，可以采样关键帧用CLIP的视觉编码器，与文本向量融合。
   • 选择建议：起步阶段，全力优化文本嵌入管道（因为信息主要来自语音），使用bge-large-zh-v1.5能获得非常好的效果。后续再考虑引入多模态。

4. 大语言模型：

   • 闭源API：GPT-4 Turbo、Claude 3在遵循指令、生成质量和减少幻觉方面表现最佳，但需付费且数据需出境。
   • 开源模型：Qwen1.5-72B-Chat、Llama 3 70B、GLM-4等，效果逼近第一梯队，可私有化部署，但需要强大的GPU资源。Qwen2.5-7B/14B等较小模型在特定指令微调后也能胜任。
   • 选择建议：个人或小规模试用，闭源API最方便。对数据隐私要求高、有GPU资源，选择开源大模型部署。

3.2 端到端实现流程拆解

假设我们选择Whisper + BGE + Chroma + GPT-4 API的栈来构建一个最小可行产品。

步骤一：环境准备与依赖安装

# 创建Python虚拟环境 python -m venv venv_streamrag source venv_streamrag/bin/activate # Linux/Mac # venv_streamrag\Scripts\activate # Windows # 安装核心库 pip install openai-whisper # ASR pip install sentence-transformers # 嵌入模型 pip install chromadb # 向量数据库 pip install openai # LLM调用 pip install ffmpeg-python # 视频处理 pip install pydub # 音频处理（可选，用于音频分割）

步骤二：视频预处理与信息提取流水线这部分代码负责将原始视频转化为结构化的片段数据。

import whisper from sentence_transformers import SentenceTransformer import chromadb from chromadb.config import Settings import json import os class VideoProcessor: def __init__(self, asr_model_size=“base”, embed_model_name=‘BAAI/bge-large-zh-v1.5’): self.asr_model = whisper.load_model(asr_model_size) self.embed_model = SentenceTransformer(embed_model_name) # 初始化Chroma客户端，持久化到磁盘 self.chroma_client = chromadb.PersistentClient(path=“./video_db”) # 获取或创建集合（类似数据库的表） self.collection = self.chroma_client.get_or_create_collection( name=“video_segments”, metadata={“hnsw:space”: “cosine”} # 使用余弦相似度 ) def process_video(self, video_path, video_meta={}): """处理单个视频：转写、分块、嵌入、存储""" # 1. 提取音频（这里简化，实际应用需用ffmpeg） audio_path = self._extract_audio(video_path) # 2. Whisper转写，获取带时间戳的详细结果 result = self.asr_model.transcribe(audio_path, word_timestamps=True) # 3. 基于句子语义分块（简化版，实际可按VAD或标点优化） segments = result[‘segments’] chunks = [] for seg in segments: chunk = { “text”: seg[‘text’].strip(), “start”: seg[‘start’], “end”: seg[‘end’], “video_id”: os.path.basename(video_path), “video_title”: video_meta.get(“title”, “”), } # 4. 为每个块生成嵌入向量 chunk[“embedding”] = self.embed_model.encode(chunk[“text”]).tolist() chunks.append(chunk) # 5. 批量存入向量数据库 self._store_to_chroma(chunks) return len(chunks) def _store_to_chroma(self, chunks): ids = [] embeddings = [] metadatas = [] documents = [] for i, chunk in enumerate(chunks): vid = chunk[“video_id”] seg_id = f“{vid}_{i}” ids.append(seg_id) embeddings.append(chunk[“embedding”]) metadatas.append({ “start”: chunk[“start”], “end”: chunk[“end”], “video_id”: chunk[“video_id”], “video_title”: chunk[“video_title”], }) documents.append(chunk[“text”]) # 存储原始文本用于后续重排或展示 self.collection.add( embeddings=embeddings, documents=documents, metadatas=metadatas, ids=ids ) print(f“已存储 {len(ids)} 个片段到数据库。”)

步骤三：构建检索与问答引擎这部分代码处理用户查询，完成检索、重排、生成的全流程。

from openai import OpenAI import numpy as np class StreamRAGEngine: def __init__(self, chroma_collection, llm_api_key, embed_model): self.collection = chroma_collection self.embed_model = embed_model self.llm_client = OpenAI(api_key=llm_api_key) # 可以在这里初始化一个重排序模型，如 cross-encoder/ms-marco-MiniLM-L-6-v2 # 此处为简化，暂用向量检索分数排序 def query(self, question, top_k=5): # 1. 将问题编码为向量 query_embedding = self.embed_model.encode(question).tolist() # 2. 向量检索 results = self.collection.query( query_embeddings=[query_embedding], n_results=top_k * 2, # 多召回一些，供后续筛选 ) # 3. 简单重排序：这里可以替换为更复杂的交叉编码器 # 我们根据向量相似度分数排序，并过滤掉分数过低的 retrieved_items = [] for i in range(len(results[‘ids’][0])): item = { “id”: results[‘ids’][0][i], “text”: results[‘documents’][0][i], “score”: results[‘distances’][0][i], # Chroma返回的是距离 “metadata”: results[‘metadatas’][0][i], } retrieved_items.append(item) # 按相似度排序（距离越小越相似） retrieved_items.sort(key=lambda x: x[“score”]) # 取top_k个作为最终上下文 final_contexts = retrieved_items[:top_k] # 4. 构建Prompt，调用LLM生成答案 answer, sources = self._generate_answer_with_llm(question, final_contexts) return {“answer”: answer, “sources”: sources} def _generate_answer_with_llm(self, question, contexts): # 构建带上下文的Prompt context_str = “\n\n”.join([ f“[片段来自视频 ‘{ctx[‘metadata’][‘video_title’]}’ 的 {ctx[‘metadata’][‘start’]:.1f}-{ctx[‘metadata’][‘end’]:.1f}秒]：{ctx[‘text’]}” for ctx in contexts ]) prompt = f“””你是一个专业的视频内容助手。请严格根据以下提供的视频片段文本来回答问题。如果提供的片段中没有足够信息来回答问题，请直接说“根据现有视频资料，无法回答此问题”，不要编造信息。 视频片段上下文： {context_str} 用户问题：{question} 请给出准确、简洁的答案，并在答案中引用所使用的片段来源（例如：根据视频A在xx秒处的讲解...）。直接开始你的回答。 “”” response = self.llm_client.chat.completions.create( model=“gpt-4-turbo-preview”, messages=[{“role”: “user”, “content”: prompt}], temperature=0.1, # 低温度，减少随机性 stream=False, # 此处为非流式，可改为True实现流式输出 ) answer = response.choices[0].message.content # 提取来源信息（这里简化，实际可以从answer中解析，或直接返回contexts） sources = [{ “video”: ctx[‘metadata’][‘video_title’], “timestamp”: f“{ctx[‘metadata’][‘start’]:.1f}s”, “text_preview”: ctx[‘text’][:100] + “…” } for ctx in contexts] return answer, sources

步骤四：组装与运行

# 主程序示例 if __name__ == “__main__”: # 初始化处理器和引擎 processor = VideoProcessor(asr_model_size=“large-v3”) # 使用大模型提高精度 engine = StreamRAGEngine(processor.collection, llm_api_key=“your-key-here”, embed_model=processor.embed_model) # 假设有一个视频文件列表 video_files = [“meeting_202401.mp4”, “tutorial_ai.mp4”] for vf in video_files: print(f“正在处理视频：{vf}”) count = processor.process_video(vf, {“title”: vf}) print(f” -> 生成了 {count} 个知识片段\n”) # 进行问答 while True: user_q = input(“\n请输入您的问题（输入’quit’退出）: “) if user_q.lower() == ‘quit’: break result = engine.query(user_q, top_k=3) print(“\n=== 回答 ===") print(result[“answer”]) print(“\n=== 参考来源 ===") for src in result[“sources”]: print(f”- {src[‘video’]} @ {src[‘timestamp’]}: {src[‘text_preview’]}”)

4. 性能优化与生产级考量：从Demo到可用的距离

上面的代码是一个原理性演示。要将其变成一个真正可用、好用的系统，还需要在性能、准确性、工程化等方面做大量工作。

4.1 处理速度与规模化优化

1. 批量处理与异步化：处理大量视频时，顺序执行ASR（非常耗时）是瓶颈。需要将视频处理任务队列化（使用 Celery、Dramatiq 或 Redis Queue），并行处理多个视频的音频提取和转写。
2. ASR模型加速：
   • 模型量化：使用whisper.cpp或faster-whisper（基于CTranslate2）等库，它们对Whisper模型进行了量化和优化，推理速度可提升数倍，内存占用大幅减少，且精度损失极小。
   • GPU推理：确保CUDA环境正确配置，并使用支持GPU的Whisper库。
   • 分段处理与流式ASR：对于极长视频，可以分段处理。对于实时性要求高的场景，FunASR的流式模式是更好的选择。
3. 向量索引优化：当片段数量达到百万级时，需要调整向量数据库的索引参数。例如，在Milvus或Qdrant中调整HNSW的ef_construction和M参数，在召回率和查询速度间取得平衡。建立分区索引，按视频来源、日期等过滤，可以加速查询。

4.2 检索精度提升技巧

1. 查询扩展与重写：用户的问题可能很短或不精确。可以使用LLM对原始问题进行扩展或重写。例如，将“怎么配置？”重写为“配置该软件的步骤和方法是什么？”，生成多个语义相近的查询向量进行检索，然后取结果并集，提高召回率。
2. 引入重排序模型：这是提升精度最有效的手段之一。使用一个交叉编码器模型（如BAAI/bge-reranker-large）对向量检索返回的Top K结果进行精排。虽然它比向量检索慢，但只对少量候选进行计算，总体开销可控，且能显著提升Top1结果的准确率。
3. 多模态检索融合：如果提取了关键帧向量，可以尝试混合检索。例如，分别用文本和图像向量进行检索，然后对两套结果的分数进行加权融合（如文本权重0.8，图像权重0.2）。这对于寻找包含特定图表、界面或人物的片段特别有效。
4. 元数据过滤：在检索时结合结构化过滤。例如，用户可能问“张三在上次项目会说了什么？”。系统可以先识别出实体“张三”和“项目会”，在向量检索前或后，用这些元数据（说话人标签、视频标题/标签）过滤结果，能极大提升精度。

4.3 系统健壮性与用户体验

1. 错误处理与回退：ASR可能失败，LLM API可能超时。系统需要有完善的错误处理、重试和降级机制。例如，ASR失败时尝试更换模型或分段；LLM调用失败时，可以降级为直接返回最相关的文本片段。
2. 流式响应：对于LLM生成答案的部分，务必使用流式接口（如OpenAI的stream=True），让答案逐字输出，给用户“正在思考”的实时感，极大提升体验。
3. 溯源与可解释性：不仅返回答案，还要高亮显示答案中哪部分来源于哪个视频片段的具体时间点。在前端实现点击时间戳直接跳转播放的功能，这是建立用户信任的关键。
4. 缓存策略：对常见问题、热门视频的检索结果进行缓存，可以大幅减少重复计算和LLM调用成本。

5. 常见问题与实战排坑指南

在实际搭建和调试StreamRAG系统的过程中，我踩过不少坑。这里把一些典型问题和解决方案记录下来，希望能帮你节省时间。

5.1 ASR相关难题

问题1：专业术语或人名识别错误严重。

• 现象：视频中的产品名、技术缩写、同事姓名被识别成其他无关词汇。
• 排查：检查ASR模型的训练语料是否包含相关领域。通用模型（如Whisper）在专业领域表现会下降。
• 解决：
  1. 热词增强：Whisper等模型支持在转录时提供“热词”（hotwords）列表，提升指定词汇的识别优先级。
  2. 后处理纠错：建立一个领域专有名词词典，对ASR结果进行简单的字符串匹配和替换。虽然粗暴，但有效。
  3. 微调ASR模型：如果数据量足够，可以用领域音频数据对开源ASR模型进行微调，这是根本性解决方案，但成本较高。

问题2：长时间视频处理内存溢出或极慢。

• 现象：处理1小时以上的视频时，Whisper加载大模型后内存占用高，甚至崩溃。
• 解决：
  1. 使用faster-whisper：它内存效率更高，支持自动将长音频分割处理。
  2. 手动分段：先用ffmpeg或pydub将长音频按静音检测（VAD）或固定长度（如10分钟）分割成小段，再分别送入ASR，最后合并时间戳。
  3. 选择更小的模型：在精度和资源间权衡，对于内部会议录音，whisper-medium可能已足够。

5.2 检索与问答相关难题

问题3：检索结果看似相关，但无法回答问题（“幻觉”的温床）。

• 现象：LLM基于检索到的片段生成了答案，但答案其实是编造的，或者片段只提到了相关词，并没有实质内容。
• 排查：检查重排序环节是否缺失或太弱。查看被检索到的原始片段文本，是否真的包含答案。
• 解决：
  1. 强制引用：在Prompt中严格要求LLM必须引用片段中的原话，并指出“如果片段中未明确提及，则说不知道”。可以设计输出格式，如答案：... 引用：[片段1]...。
  2. 增强重排序：务必引入交叉编码器进行精排。bge-reranker模型在中文上效果出色，能很好地区分“语义相似”和“答案支持”。
  3. 调整检索数量：增加top_k召回数量，给重排序和LLM更多选择。但太多会增加成本和噪声，需要平衡。

问题4：回答笼统，不精准到具体时间点。

• 现象：答案正确，但引用的视频片段跨度长达几分钟，用户仍需自己寻找。
• 解决：
  1. 更细粒度的分块：采用句子级甚至子句级的分块策略，使每个片段只包含一个核心语义单元。
  2. 时间戳融合：如果答案综合了多个片段的信息，可以在最终输出时，列出所有相关片段的时间戳，而不仅是一个。
  3. 基于单词时间戳定位：Whisper提供了单词级的时间戳。当LLM的答案中包含了片段中的特定词汇时，可以尝试映射回该词汇的精确时间点，实现“词级定位”。这需要更复杂的前后端协同。

问题5：多说话人场景混乱。

• 现象：会议视频中有多人发言，检索时无法区分“谁说了什么”。
• 解决：
  1. 说话人分离：在ASR前，加入说话人分离（Speaker Diarization）步骤，使用如pyannote.audio这样的工具，将音频按说话人分割并标注（如Speaker A, B, C）。然后将说话人标签作为元数据，与文本片段一起存储。
  2. 检索过滤：用户提问“张三说了什么？”，系统可以先过滤出标签为“张三”的片段，再进行语义检索，精度会极大提高。

5.3 工程与部署问题

问题6：向量数据库检索速度随数据量增长变慢。

• 现象：初期很快，存入几十万个片段后，查询延迟明显增加。
• 解决：
  1. 优化索引：重新审视向量数据库的索引创建参数。对于Qdrant/Milvus，重建索引并调整ef_construct、m等参数。
  2. 硬件升级：向量检索是计算密集型，尤其是高维向量。确保数据库运行在有足够内存和CPU的机器上。考虑使用带GPU加速的向量数据库版本。
  3. 分区与过滤：利用元数据（如视频ID、日期）创建分区，查询时先过滤到某个子集，再在这个子集内做向量检索。

问题7：LLM API调用成本失控。

• 现象：用户提问频繁，GPT-4 API费用增长很快。
• 解决：
  1. 缓存：对完全相同的查询进行缓存。甚至可以对语义相似的查询进行缓存（需要计算查询向量的相似度）。
  2. 使用更便宜的模型：在非关键或简单问题上，路由到更便宜的模型，如gpt-3.5-turbo。或者使用开源模型自建。
  3. 优化Prompt：精简Prompt，减少不必要的上下文。确保提供的上下文都是高度相关的，避免发送冗长的无关文本。

构建一个成熟的StreamRAG系统，是一个在“效果”、“速度”、“成本”和“复杂度”之间不断权衡的艺术。从最简单的管道开始，逐步迭代，针对你最关心的场景和数据特点进行优化，才是可持续的路径。这个项目最大的魅力在于，它清晰地展示了一条将原始视频数据转化为智能能力的路径，每一个环节都有深入优化的空间，也充满了挑战和乐趣。