从收藏夹到私域知识库：基于RAG打造B站视频问答系统-北京尧图网络

1. 收藏夹里的六百个视频为什么我决定做一个问答系统先说一个我自己的尴尬事。某天晚上我想找半年前看过的一个关于注意力机制的讲解视频印象里UP主拿Transformer铺开讲了一整期当时觉得讲得特别好顺手点了收藏还发了条弹幕说“期末就靠这期了”。结果期末真正到跟前我在收藏夹里翻了整整二十分钟愣是没找到那期视频。收藏夹里躺着的几千条视频标题五花八门有“必看”有“看完这条你也能上手”有“呕心沥血整理”光凭标题完全看不出里面讲的是什么。一个很反直觉的事实是B站收藏夹是我过去几年积累知识密度最高的地方但它几乎是不可检索的。首页推荐、搜索、稍后再看平台给的都是“别人想看什么”不是“我收藏了什么、收藏的东西之间有什么联系”。我需要的不是再看一遍视频而是能针对收藏夹里的内容提问——比如“我收藏过的视频里有哪些讲过Embedding和相似度计算的区别”“关于RAG的架构演进我收藏过的视频都提到了哪些关键节点”——然后系统直接基于这些视频帮我组织答案。这就是Bilibili RAG这个项目要解决的事情。RAG全称Retrieval-Augmented Generation检索增强生成核心思路很简单先从一个私有的知识源里把相关内容检索出来再把这些内容作为上下文喂给大语言模型让它基于这些材料生成回答。本质上就是给语言模型外挂了一个“可检索的笔记本”它不凭空编造而是先翻笔记再开口。而我要做的就是把B站收藏夹——包括视频的字幕、弹幕、评论、简介——变成这个“笔记本”最后输出一个能对话的本地知识库系统。这个项目适合谁参考如果你也攒了几百上千条收藏夹内容却很少回去看如果你在看完某个技术视频后想快速回忆其中的关键结论或者你本身对RAG技术栈想跑通一条完整的落地方案这篇文章都值得你看完。前面是动机后面全部是实操包括数据怎么抓、文本怎么清洗、切块怎么切、检索怎么调优以及我踩过的几个坑。2. 整体链路拆解从UP主视频到可回答的索引在做任何一个RAG项目前我建议先画一张数据流图弄清楚自己到底在搬运什么。这个项目我把它拆成了五个环节缺一个都不行。第一环节是数据采集。B站收藏夹里的视频可用的文本来源有几种视频标题、UP主简介、视频分P标题、字幕CC字幕或UP主上传的字幕文件、弹幕、评论。这里面质量差异非常大。标题和简介信息量太少弹幕噪声太大评论内容漂移严重真正高密度的是字幕。但字幕又不一定每个视频都有所以我最后按优先级设计了采集策略有字幕用字幕没字幕用语音转写实在不行才靠简介加弹幕兜底。这个顺序不是随便拍的是整个项目里我对内容质量最重要的一个判断。第二环节是内容清洗。B站字幕有双重压缩的问题一是B站自己的CC字幕经常缺句缺段二是有些字幕文件本身是二次压制过的里面混着日文韩文碎片、广告、UP主口播的“关注三连”这些垃圾。清洗的时候要做去重、去噪、去无意义符号还要做到“句级的连续性还原”——因为字幕是一句一句分离的要拼回成连贯的段落才能被后续的切分器正确理解。第三环节是切分与向量化。这是RAG质量的地基也是很多人做得最粗的一步。字符合并的问题在于视频这种内容天然地按主题分段一段三分钟的讲解可能围绕一个公式展开。我后来用了层级化切分方案先把同一期视频的字幕按语义边界切成长文本块再在每个文本块内部做更细的段落切分。向量化用了一个常规的文本嵌入模型模型参数不大正常消费级显卡就能跑或者直接走本地向量库。这个细节我放到第四节展开说。第四环节是索引与检索。这一步我在Milvus里建了collection字段包括视频ID、视频标题、UP主信息、文本块内容、时间戳、嵌入向量。查询的时候先做向量相似度检索拿回Top-K候选再做重排。这一步决定了用户提问“我收藏夹里哪些视频讲过不协调的Embedding对齐”系统能不能答到点子上而不是给你返回一堆字面上沾边但内容无关的视频。第五环节是生成。生成端我用的是支持本地部署的对话模型配合自定义的系统提示词。提示词里明确了回答规则优先基于检索到的文本块作答回答标注信息来源——哪一期视频、什么时间段的内容——如果检索内容不足必须明确说“知识库中未找到相关内容”而不是强行编造。这一步看着简单其实直接影响用户体验。第一次跑通的时候模型把我的提示词当耳边风问什么都是一本正经地胡说八道。后来加了一个强约束判断逻辑如果检索结果的相关分很低就先一步拦截直接告诉用户“这个问题的答案不在收藏夹里”这才算真正闭环。3. 数据获取与内容清洗字幕、弹幕和评论的取舍3.1 采集策略优先字幕兜底弹幕接上节我在数据采集里遇到的第一件事是B站不像普通网站它的页面是动态渲染的接口也有风控和签名机制。如果你直接拿requests去抓很大概率抓回来一堆空壳HTML。业内常用的做法是调用公开的非官方接口封装库或者自己带上cookie和签名参数去请求。我的方案是先用浏览器登录态把cookie导出然后在代码里配置请求头模拟真实的播放器环境。这里有个容易翻车的细节B站的接口风控会检查请求频率短时间高频请求会触发验证码甚至封禁所以采集端必须带限速和重试机制。我用了一个很保守的策略单个视频的元信息请求间隔至少两秒弹幕专人通道的间隔保持五秒以上一批采集跑下来稳得多。字幕采集是另一个关键分支。B站存在两种字幕一种是UP主手动上传的CC字幕或JSON字幕另一种是AI生成的自动字幕。自动字幕虽然能覆盖绝大多数视频但错别字和漏句特别多。我在实测里发现技术类视频的AI字幕准确率还算能看但遇到专业名词密集的讲解视频漏句率可能接近一成。所以采集顺序我调整为先检查视频是否有CC字幕文件没有就触发离线语音转写流程把这个视频的音轨抽出来用本地语音识别模型转一遍再用字幕原来的句子边界做对齐。这里我用了ffmpeg抽音频转写速度大概是一比三一个十五分钟的视频五分钟转完完全可接受。3.2 清洗才是真功夫采集下来的原始字幕直接进知识库答案质量会很惨。我踩过一次印象很深的坑某期视频字幕里反复出现“那个那个”“就是就是”这类口语填充词文本块切出来之后向量化语义被严重稀释导致检索时经常把面无表情的口水话当成高相关文本返回。清洗这步我分了三道第一道是符号层清洗。去掉所有非中英文和数字的杂项符号统一引号、括号的格式把全角和半角数字做归一。第二道是口语层清洗去掉重复的语气词、口播的“关注三连”“一键三连”“本期视频”等模板话但要注意不能过度删除——有些口头表达本身承载了句义比如“这个方法是……但有个问题”里的转折词不能丢。第三道是结构层清洗把弹幕里的重复刷屏内容去重比如满屏的“哈哈哈哈”只保留一条把评论里的楼主楼层关系去掉只保留有效文本。最后我会按视频ID做一次段落合并把同一话题的连续句子拼接成逻辑连贯的大段落再送去切分。这里要给一个明确的建议弹幕在大多数场景下不值得进知识库。我曾尝试把弹幕作为补充信号结果检索时经常被“前方高能”“名场面”这类情绪弹幕带偏还增加了不少无效文本。弹幕唯一用得上的场景是热度聚合分析——比如统计某期视频里弹幕高频词辅助判断观看者关心什么但那是另一个项目的事了。评论我的策略是只保留楼中楼主层且超过二十字的认真评论它们的补充信息价值比弹幕高但也只作为字幕的辅助绝不喧宾夺主。4. 切分与向量化决定问答质量的第一道分水岭4.1 先讲清楚切分为什么难做RAG的人最容易犯的一个错是拿通用文档的切分逻辑直接套到视频字幕上。通用文档切断句可以靠句号和换行但视频字幕是“句子碎片”组成的——一个字幕块可能只有四五个字“这个公式”下一个字幕块是“我们代入数据”搁在一起才构成一个完整语义单元。如果按固定字符数硬切很容易把一个完整的论证过程劈成两半向量检索的时候就什么都匹配不上。我采用的方案是两层切分。第一层做“语义段落识别”“这个公式”和“我们代入数据”之间如果没有明显的停顿或话题切换就合并到同一个语义段落。我试过用标点符号加停顿时间戳作为判断依据更稳。第二层再对语义段落做定长切分但切分边界尽量落在句子边界上而不是硬凑字符数。最终文本块大小的选择上我取了一个比较折中的值——单个文本块控制在五百个字符以内。为什么是五百因为向量检索的精度和文本块的语义聚焦度强相关块太小检索回来的是碎片块太大语义被稀释。五百这个值是在我自己的收藏集上对比过几百次检索效果后选出来的我建议你做项目时也花时间做一组类似的对比测试而不是拍脑袋定死参数。4.2 向量化和重排本地模型该怎么选向量化这块市面上可选模型确实不少。但你要考虑自己的硬件和运行场景。B站收藏夹的知识库是个人本地服务不需要走云端API更看重的是稳定可控。我选的嵌入模型是常规开源文本向量模型输出维度768足够表达视频字幕这种中等复杂度的语义。你可能会问为什么不用更大的模型因为在本项目的场景里大模型带来的精度提升非常有限但显存占用和推理延迟直接翻倍。收藏夹这个场景的文本本身就是口语化的、碎片化的模型再大也补不齐源头的信息损耗。我的判断是嵌入模型做到“够用且快”把更多资源留给后面的重排和生成。重排器我叫它“最后一个守卫”。向量检索拿回Top-50的候选文本块质量参差不齐真正相关的可能只有七八条。重排器的作用是对这五十条重新打分排序把真正贴合查询语义的往前顶。我用的是一种轻量的交叉编码器模型输入是用户查询和文本块拼接起来的一对文本输出相关性分数。这一步比单靠向量相似度精多了但计算代价高一些——不过放心只在Top-50上重排消耗完全可以接受。我实测下来加了重排之后回答命中率大概提升了十几个百分点最直接的表现就是用户问“收藏夹里有哪些视频讲过向量数据库的索引结构”返回的不再是讲数据库概述的视频而是真正展开讲HNSW、IVF的段落。5. 检索增强生成混合检索与调优经验5.1 关键词和向量双轨检索向量检索有个天生的盲区——它对专有名词、缩写、型号这类“精确关键词”不敏感。比如你问“P40显卡”向量检索可能返回一堆讲显卡架构的内容而不是真正提到“P40”这个型号的片段。我在项目里补了一条BM25全文检索轨道和向量轨道并行跑最终用RRFReciprocal Rank Fusion把两路结果合并排序。原理不复杂每个文档在两路结果里都有一个排名RRF把每个排名的倒数相加排名越靠前分越高最后统一按综合分取前几十条再进重排器。实测下来混合检索对这个场景非常关键。字幕文本里有大量代码片段、模型名称、版本号这类精确信息BM25对这些是字面量匹配一抓一个准向量检索则擅长抓“语义相似但字面不同”的内容比如“脑内筛选”和“心理过滤”这种表达。两路一合覆盖面宽多了。RRF的权重我只做了最朴素的均权融合没有做复杂的学习式排序因为在对个人开发者的单机场景下复杂排序带来的提升不值得那个维护成本。5.2 不解决问题提示词与拦截策略生成侧我用了本地部署的开源对话模型上下文长度只开了默认窗口。为什么这么吝啬因为RAG场景里塞给模型的上下文远不是“越长越好”。如果两路检索加上重排后拿回十五条文本块全灌进上下文模型反而会迷茫分不清哪条是核心材料。我最终的做法是重排后的Top-5文本块作为主要上下文其他的只保留标题和摘要作为参考信息。每组检索回来的文本还带着它们对应的视频标题、UP主ID、时间戳这些元数据一并交给模型这样模型回答时能准确标注“根据某UP主一期关于某某的视频内容”。最值得分享的是我在提示词之外加的一道硬拦截。单纯在系统提示词里写“请基于检索内容回答不要编造”模型的服从性时好时坏。所以我加了逻辑判断层从重排器拿回来的最高分文本块如果得分低于预先设定的阈值直接判定“本次检索没有找到靠谱材料”返回给用户的回答是“知识库中没有找到相关内容请换一种问法或搜索其他关键词”而不是让模型硬着头皮生成。这个设计看着简单但它是用户体验质变的关键。一个负责任的RAG系统最重要的能力之一是知道自己“不知道什么”。后来我把这个逻辑写成了可配置的阈值项跑了多组测试之后定下默认值。B站收藏夹这种高噪声数据源宁可少答不要错答否则用户问十次有两次是幻觉回答这个系统就没有任何信任可言了。调优过程中我做了个小实验把收藏夹里的视频按“编程”“人工智能基础”“数据分析”“效率工具”四类分别建了子索引。检索时先判断用户提问属于哪一类只在该类索引里检索。效果提升了但代码复杂度也上去了。最后我放弃了自动分类硬路由改成了轻提示在用户输入query时先用模型做一个粗分类提示把类别标签拼进检索逻辑。这样既保证检索粒度又不用维护复杂的分类服务。这个变通的思路值得借鉴一个RAG系统里不是所有模块都要做到极致复杂把复杂留给真正影响体验的环节。5.3 对话式追问的设计“收藏夹变成可对话的知识库”这句话里的关键在于“可对话”。不只是用户问一句、系统答一句还要能针对上一轮的回答继续追问。我的设计是让每一轮历史对话也参与检索拼接最近两个轮次的问题和回答摘要一起生成向量去做检索。这样用户问“那HNSW是什么”系统能顺着上一轮“向量数据库索引”的话题直接定位到收藏夹里讲HNSW的具体视频段落而不是重新泛泛地搜一遍。这个方案带来的问题也很典型历史对话的加入会增加检索噪声。我试过拼接全部历史对话结果显示系统开始答非所问——因为历史会话里包含了太多和当前问题无关的上下文。最后我只保留当前轮次加最近一轮的问答对效果最好。做类似项目的人可以直接抄这个思路但要根据自己的使用习惯微调历史轮次的数量。6. 落地过程中的坑与躲坑姿势单机RAG系统里最容易翻车的往往不是模型本身而是那些“看似不起眼的基础设施”。我总结几个自己踩过的和看朋友踩过的坑。6.1 文本块归属信息丢失这是我踩过最深的一个坑。最初我向量化文本块时只管嵌入向量忘了把视频ID、时间戳、所在分P这些归属字段一并存进向量库。后来检索到一条很好的文本块模型引用了它但是回答里完全无法标注来源——因为真是找不回这条文本到底来自哪个视频了。重新找回来源的办法只有重新遍历字幕文件恶心得要命。改造方案是把元数据全部作为标量字段存进Milvus的同一行记录检索时随向量一起取出来。从第一天起我就在写入这一步强制要求每个文本块必须携带完整血缘信息。6.2 重复内容对索引的污染收藏夹里的视频不是没有重叠的恰恰相反同一个知识点往往被多个UP主反复讲。索引里如果放着几乎一模一样的文本块向量检索会把“相似度高”误当成“相关内容质量高”排名全被重复内容占掉反而把信息密度最高的独有文本挤下去了。解决思路是加一步去重对写入向量库的文本块做一次向量去重相似度超过一个高阈值的文本块就不重复入库了仅在元数据里关联多个视频ID。这样既能提醒用户“这个内容有三个视频讲过”又不会让索引爆炸。6.3 字幕的时间轴错位有些视频的字幕文件是错帧的——字幕文本和音频里的句意对不上。这直接导致我最初做“按时间戳跳转视频”的功能时用户点击引用的时间戳跳到的画面内容压根不是那段字幕对应的内容。排查下来发现问题出在采集流程部分视频的CC字幕是UP主新建的时间轴和视频正片存在偏移。我的处理方法是做音频指纹对齐抽取几个关键句的音频片段和字幕文本的预期时间做比对计算出一个偏移量统一纠正。这一步逻辑不复杂但非常有用跳转功能的准确性一下就上来了。6.4 本地部署的显存焦虑我跑这套系统的时候嵌入模型和一个重排器外加对话模型同时加载三块模型压在显存里单张普通显卡很快就吃紧。我最后采取的做法是把三块模型拆到两个进程里跑对话模型单独占一个进程嵌入模型和重排器共享另一个进程用模型调度顺序串行执行。稍微牺牲一点并发能力但换来了稳定运行。如果你也用类似方案强烈建议先用脚本统计三个模型各自的峰值显存再做进程分配别等到OOM了再拍大腿。6.5 增量更新比全量重建难得多收藏夹是会变的今天又收藏了两个视频明天取消了一个收藏系统不可能每次变动都全量重建索引。我实现了一个比较轻的增量管道定期扫描收藏夹变动把新增视频做“采集—清洗—切分—向量化—入库”全链路处理删除的视频则按视频ID批量删除向量库中对应记录。这里要注意的一个细节是B站视频存在被UP主删稿或设私的情况原链接失效但你的索引里还留着旧内容。我的做法是每周做一次链接健康检查失效视频及时标记下线避免以后检索出一个“不存在”的来源。7. 一个比想象中好用的本地知识库项目跑到今天我已经习惯了遇到问题先去问收藏夹某期讲分布式一致性的视频到底提没提过Raft的选主时间半年前看过的某个手写Transformer的视频里梯度裁剪的具体数值是多少。系统不仅能回答这些问题还能顺着话题牵出我压根忘了收藏过的相关视频这是最惊喜的地方——检索的过程中它像是帮我重新翻了一遍收藏夹。回顾整个项目的投入真正耗费时间的不是模型调参而是数据链路的地基工程采集、清洗、元数据设计、增量更新每一步都在为最终的问答质量买单。如果你也想做类似的系统我最大的建议是先别急着追求花哨的模型和复杂的Agent流程图把“一条文本从视频字幕走到向量库”的链路跑通跑稳再逐步叠加对话、重排、分类那些能力。一条烂数据流上喂再好的模型产出的也是烂答案。B站收藏夹这个场景特别适合做RAG练手因为数据自带时间的价值沉淀你积累的每一期视频都是别人没有的私有知识而检索它们的快乐也是搜索引擎给不了的。

从收藏夹到私域知识库：基于RAG打造B站视频问答系统

相关推荐

AI迈入智能体时代：从生成内容到执行任务的技术演进与落地实践

视觉SLAM前沿思考：几何、学习与多传感器融合的鲁棒性之路

基于扩散模型的年龄迁移：从少年到老年的连续可控人脸生成

更多资讯

业务配置中心架构设计与实践：统一管理、动态生效与容错机制解析

AgentCore：云原生智能体运行时，补齐生产落地的关键一环

AI编程智能体分级与选型指南：从L0到L4的自主性光谱

AI营销SaaS精准获客实战：行为评分与自动化触达全解析

Web Serial API实战：从零搭建网页版串口调试助手

LoG边缘检测与YOLO融合：LoGStem模块提升小目标检测精度

今日更新

电商智能运营体系从0到1：架构设计、落地步骤与避坑指南

压缩空气储能与热网热惯性联合优化调度：热电联产系统建模与求解

若依框架AI代码生成不稳定？用Agent Skill三层结构+五步法搞定

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？