开源组件搭建知识蒸馏管线：让电子书、视频、播客变成可检索的AI知识库

知识蒸馏向量数据库RAG

于 2026-08-31 04:06:22 修改

·本内容遵循CC 4.0 BY-SA版权协议

收藏了大量电子书、长视频课程和播客，但真正到需要的时候，却想不起内容在哪、结论是什么。这是典型的“知识吃灰”问题。知识吃灰的本质，不是输入不够，而是输入之后没有形成可索引、可调用的资产。GitHub 上有大量开源项目可以解决这个问题：先用语音识别和文本解析把任何书、长视频、播客转成文字，再用大模型做切分、摘要和结构化，最后放进向量库，变成可以检索、可以对话的 AI 工具。下面这套方案不依赖某个封闭产品，而是基于几个成熟开源项目组合成一条“知识蒸馏管线”，从零跑通后，你完全可以把它整理成自己的 GitHub 项目。

1. 先理解“知识蒸馏”在 AI 工具中的含义和边界

1.1 这里的蒸馏不是模型蒸馏，而是内容结构化

提到蒸馏，算法工程师会先想到模型蒸馏：用一个大模型的输出去训练一个小模型，让模型体积变小、推理更快。但本文讨论的是内容层的知识蒸馏，目标完全不同。

你一定遇到过这种场景：一个 PDF 文件躺在网盘里，一部两小时的视频课程在收藏夹里，一期播客在播放器里。这些内容的原始形态无法被搜索引擎高效处理，更无法被问答系统直接调用。所谓知识蒸馏，就是把原始内容压缩成片段、摘要、关键词、问答对，并为这些片段计算向量表示。这样以后遇到问题时，不是靠记忆搜索，而是靠向量检索快速定位原始资料。

技术上说，这条蒸馏管线包含四个动作：

提取：从书中提取章节文本，从音视频中提取转写文本。
切分：把长文本切成语义完整的片段。
压缩：用大模型生成摘要、标题、关键词或问答对。
索引：把片段和摘要向量化，写入向量数据库。

这套过程的价值在于，它把“内容囤积”变成了“内容资产”。囤积只关心文件是否还在，资产关心内容能否被调用。

1.2 适合处理的三类内容，难点并不相同

不同内容类型的处理难度差别很大。整理成下表，方便后面的选型参考：

内容类型	典型文件	主要难点	推荐处理方式
书	PDF、EPUB、DOCX	版式复杂、目录缺失、图表干扰、扫描版	先解析正文，再按章节或段落切分
长视频	MP4、MKV、MOV	口语化、噪声多、时长长、缺乏目录	提取音轨后用语音识别转写，按语义切分
播客	MP3、M4A、WAV	多人对话、话题穿插、无章节信息	转写后增加说话人标记或按话题切分

书的问题在文本层，视频和播客的问题在语音识别层。视频比播客多了画面信息，但如果没有做视觉理解，画面信息目前会被丢弃。这一点在构建工具时要提前接受，不要期待纯音频转写能处理图表和字幕中的关键信息。

1.3 知识蒸馏能做什么，不能做什么

能做的：

快速了解一本书、一期播客、一门课程的核心主题。
针对收藏内容提出自然语言问题，并返回带出处的回答。
把同一主题的多个资料合并成一份带引用的汇总。
建立个人知识库，后续可以接入更多自动化流程。

不能做的：

不能替代逐字精读。蒸馏后的片段是索引入口，不是原书。
不能保证语义不丢失。模型能力、转写错误、切分粒度都会影响蒸馏质量。
不能自动判断内容是否过时。书里的结论、视频里的技术方案都有时效性。

所以，蒸馏系统的设计原则是：始终保留原始文件和来源元数据，向量库里的片段只作为索引层。回答问题时，要让用户能追溯到原始位置。

2. 开源组件选型：从原始文件到 AI 知识库的四个环节

2.1 解析与转写层：先把一切内容变成干净文本

书、视频、播客的输入格式完全不同，需要分别处理。

处理书籍文本，常见开源项目包括 pypdf、pdfplumber、ebooklib、pandoc。其中：

pypdf 适合提取常规 PDF 文本，简单直接。
pdfplumber 适合带复杂版式或表格的 PDF。
ebooklib 专门处理 EPUB。
pandoc 是一个通用格式转换工具，适合 DOCX 转纯文本。

处理音视频，主流选择是 Whisper 系列。OpenAI 开源的 whisper 支持多语言转写，faster-whisper 在相同模型下推理速度更快、内存占用更低。如果你有 GPU，可以选用 base 或 small 模型；如果只是 CPU 且音频较短，base 模型也够用。

2.2 模型服务层：本地模型和云端 API 如何取舍

转写得到文本后，切分和摘要需要大模型参与。这里有两种路线：

本地模型：通过 Ollama 运行开源模型，例如 qwen2.5:7b、llama3.1:8b。好处是数据不出本机，离线可用，没有按 token 计费。
云端 API：调用 OpenAI、Anthropic、国内大模型平台的 API。好处是效果和速度通常更好，不需要本地 GPU，但会产生费用，也需要把内容发送到第三方服务。

如果处理的是个人笔记、书籍摘要，隐私要求不高，云端 API 更方便。如果处理的是敏感文档，或者需要完全离线，应优先本地模型。

对比项	本地模型（Ollama）	云端 API
隐私性	高，数据不出本机	中，内容会发送到服务商
硬件要求	需要 CPU/GPU 和内存	只需要网络请求
成本	电费和硬件成本	按 token 计费
效果与速度	取决于本地模型和硬件	通常更好、更稳定
适用阶段	离线、隐私、学习	效果优先、快速落地

2.3 存储与检索层：向量数据库负责把“片段”变成“可查内容”

蒸馏后的片段需要向量化。每个片段输入 embedding 模型，生成一个向量，然后写入向量数据库。

个人项目可以选 Chroma，它安装简单，支持持久化，API 直观。团队项目可以考虑 Qdrant 或 Milvus，它们更适合多用户、高并发、大数据量场景。

检索时不需要关键词完全匹配，而是把用户的问题也向量化，然后计算相似度，返回最相关的几个片段。这就是 RAG（检索增强生成）的基本链路：先检索，再生成。

2.4 工作流层：脚本和编排工具如何配合

最简单的实现方式是 Python 脚本，这也是本文示例采用的方式。把解析、切分、向量化、入库写成一个 ingest.py，把检索和问答写成一个 api.py。

如果后续要处理大量文件、定时更新、多人协作，可以使用开源编排工具，比如 LangChain、LlamaIndex、Dify、n8n。它们把流程可视化，但引入更多概念和学习成本。个人自用时，脚本反而更清晰，也更容易排查问题。

3. 环境准备与依赖安装

3.1 明确学习环境的三个目标

学习阶段的目标不是一次处理几百个小时视频，而是用一个小文件把整条链路跑通。所以环境准备需要满足三个条件：

能够解析一种常见文件，推荐先试 PDF 或 TXT。
能够运行一个本地模型服务，推荐 Ollama。
能够把文本写入本地向量库，推荐 Chroma。

不建议一上来就处理 2 小时的高清视频，也不建议直接让 Whisper 转写整个播客目录。先准备一个小文件，时间控制在 5 分钟以内。

3.2 创建项目目录和虚拟环境

BASH

mkdir -p knowledge-distiller

cd knowledge-distiller

python -m venv .venv

source .venv/bin/activate

Windows 下激活命令不同，需要执行：

BASH

.venv\Scripts\activate

检查基础环境：

BASH

python --version

ffmpeg -version

ollama --version

如果 ffmpeg 没有安装，在 Debian/Ubuntu 上可以执行：

BASH

sudo apt update

sudo apt install -y ffmpeg

macOS 可以安装 Homebrew 后再安装 ffmpeg。Windows 用户需要确保 ffmpeg 命令已加入 PATH。

3.3 安装 Python 依赖和 Ollama 模型

本文示例涉及的依赖包括：

BASH

pip install openai-whisper pypdf python-docx ebooklib beautifulsoup4 langchain-text-splitters chromadb fastapi uvicorn requests

如果是新版 pypdf 和 ebooklib，安装命令保持一致。安装完成后，验证导入是否正常：

BASH

python -c "import pypdf, chromadb, langchain_text_splitters; print('ok')"

然后安装 Ollama 并拉取两个模型，一个用于 embedding，一个用于生成回答：

BASH

ollama pull nomic-embed-text

ollama pull qwen2.5:7b

nomic-embed-text 是嵌入模型，负责把片段向量化；qwen2.5:7b 是生成模型，负责根据检索结果回答问题。如果本机内存不足，可以把 qwen2.5:7b 换成更小的 qwen2.5:3b 或 llama3.2:3b。

3.4 学习环境与生产环境的区别

学习环境追求“跑通”，生产环境追求“稳定、安全、可回滚”。区别用表格呈现：

维度	学习环境	生产环境
输入规模	几个小文件	大量文件和持续新增
数据处理	直接执行脚本	使用任务队列和增量索引
向量库	本地目录	独立数据库或对象存储
模型服务	本机 Ollama	独立模型服务，支持并发
日志	控制台输出	结构化日志和监控告警
备份	手动复制	自动备份和恢复演练

4. 手写最小蒸馏管线：把一本书、一段视频、一期播客变成知识片段

4.1 统一文件解析入口

先写一个 loader.py，根据文件后缀调用不同解析器。这样后面只需要传文件路径，不需要关心文件类型。

PYTHON

# loader.py

from pathlib import Path

def load_text(path: str) -> str:

path = Path(path)

suffix = path.suffix.lower()

if suffix == ".txt":

return path.read_text(encoding="utf-8", errors="ignore")

if suffix == ".pdf":

from pypdf import PdfReader

reader = PdfReader(str(path))

return "\n".join(page.extract_text() or "" for page in reader.pages)

if suffix == ".docx":

from docx import Document

doc = Document(str(path))

return "\n".join(p.text for p in doc.paragraphs)

if suffix == ".epub":

import ebooklib

from ebooklib import epub

from bs4 import BeautifulSoup

book = epub.read_epub(str(path))

texts = []

for item in book.get_items():

if item.get_type() == ebooklib.ITEM_DOCUMENT:

soup = BeautifulSoup(item.get_body_content(), "html.parser")

texts.append(soup.get_text("\n"))

return "\n".join(texts)

if suffix in {".mp3", ".mp4", ".m4a", ".wav", ".mkv", ".flac"}:

import whisper

model = whisper.load_model("base")

result = model.transcribe(str(path))

return result["text"]

raise ValueError(f"unsupported file type: {suffix}")

这段代码的关键点是：PDF 使用 pypdf，DOCX 使用 python-docx，EPUB 使用 ebooklib 加 BeautifulSoup，音视频使用 Whisper。如果你的 PDF 是扫描版，extract_text() 会返回空或乱码，需要先做 OCR，这里不展开。

4.2 切分文本并写入向量库

文本清洗和切分直接决定检索效果。这里使用 langchain-text-splitters 的 RecursiveCharacterTextSplitter，它按分隔符优先级切分，能尽量保留语义完整。

PYTHON

# ingest.py

from pathlib import Path

import chromadb

import requests

from chromadb import Documents, EmbeddingFunction, Embeddings

from langchain_text_splitters import RecursiveCharacterTextSplitter

from loader import load_text

class OllamaEmbeddingFunction(EmbeddingFunction):

def __init__(self, model: str = "nomic-embed-text", base_url: str = "http://localhost:11434"):

self.model = model

self.base_url = base_url

def __call__(self, input: Documents) -> Embeddings:

embeddings = []

for doc in input:

response = requests.post(

f"{self.base_url}/api/embeddings",

json={"model": self.model, "prompt": doc},

timeout=60,

)

response.raise_for_status()

embeddings.append(response.json()["embedding"])

return embeddings

def main(file_path: str, collection_name: str = "knowledge"):

client = chromadb.PersistentClient(path="data/chroma")

collection = client.get_or_create_collection(

name=collection_name,

embedding_function=OllamaEmbeddingFunction(),

)

text = load_text(file_path)

splitter = RecursiveCharacterTextSplitter(

chunk_size=800,

chunk_overlap=100,

separators=["\n\n", "\n", "。", "！", "？", " ", ""],

)

chunks = splitter.split_text(text)

ids = []

documents = []

metadatas = []

for idx, chunk in enumerate(chunks):

ids.append(f"{Path(file_path).stem}-{idx}")

documents.append(chunk)

metadatas.append({"source": str(file_path), "seq": idx})

collection.upsert(ids=ids, documents=documents, metadatas=metadatas)

print(f"processed {file_path}, ingested {len(chunks)} chunks")

if __name__ == "__main__":

import sys

main(sys.argv[1])

运行方式：

BASH

python ingest.py data/raw/example.pdf

如果处理的是音频：

BASH

python ingest.py data/raw/lesson.mp3

预期输出：

TEXT

processed data/raw/lesson.mp3, ingested 42 chunks

4.3 为什么 chunk_size 和 chunk_overlap 如此重要

chunk_size 决定每个片段的最大字符数。太小会导致上下文不足，太大则向量表示的语义容易被稀释，检索时也不够精确。chunk_overlap 是为了避免切片把一句话或一个知识点从中间切断。

参考配置：

参数	推荐值	调小的影响	调大的影响
chunk_size	600-1000	片段零碎，上下文不足	语义混杂，召回不精确
chunk_overlap	50-150	边界信息易丢失	重复内容多，占用存储
separators 顺序	段落优先	容易切碎段落	大段内容无法切分

中文文本建议把 。、！、？ 加进分隔符列表中。这样切出来的片段更像“一个完整观点”。

4.4 先入库，再验证

入库后检查向量库文件：

BASH

ls -lh data/chroma

正常情况下会看到 SQLite 或相关数据文件。此时还没有验证检索是否正确，只完成了存储。下一步需要写一个可以问答的接口，用来验证“存进去之后能不能查出来”。

5. 暴露成 AI 问答工具：一个可用的 FastAPI 接口

5.1 检索回答的逻辑：先召回，再生成

知识问答不能直接让大模型凭记忆回答。正确流程是：

用户输入问题。
把问题向量化，从向量库中检索 top_k 个相关片段。
把片段拼接成上下文。
把问题和上下文一起发给大模型。
大模型基于上下文回答，并返回引用来源。

这样回答有依据，后续排查时也能知道是哪个片段导致的错误。

5.2 FastAPI 服务实现

PYTHON

# api.py

from typing import List

import chromadb

import requests

from fastapi import FastAPI

from pydantic import BaseModel

from ingest import OllamaEmbeddingFunction

app = FastAPI()

client = chromadb.PersistentClient(path="data/chroma")

collection = client.get_or_create_collection(

name="knowledge",

embedding_function=OllamaEmbeddingFunction(),

)

class AskRequest(BaseModel):

question: str

top_k: int = 5

class AskResponse(BaseModel):

answer: str

sources: List[str]

@app.post("/ask", response_model=AskResponse)

def ask(req: AskRequest):

results = collection.query(

query_texts=[req.question],

n_results=req.top_k,

)

documents = results["documents"][0]

metadatas = results["metadatas"][0]

context = "\n\n".join(

[f"[{i + 1}] {doc}" for i, doc in enumerate(documents)]

)

prompt = (

"你是个人知识库助手。请只根据下面的参考资料回答问题。\n"

"如果参考资料中没有答案，请直接回答“资料中没有找到相关答案”。\n"

"不要编造事实。回答时尽量说明引用了哪一段资料。\n\n"

f"参考资料：\n{context}\n\n"

f"问题：{req.question}\n\n"

"回答："

)

response = requests.post(

"http://localhost:11434/api/chat",

json={

"model": "qwen2.5:7b",

"messages": [{"role": "user", "content": prompt}],

"stream": False,

timeout=120,

)

response.raise_for_status()

answer = response.json()["message"]["content"]

sources = [meta.get("source", "") for meta in metadatas]

return AskResponse(answer=answer, sources=sources)

启动服务：

BASH

uvicorn api:app --host 0.0.0.0 --port 8000

调用接口：

BASH

curl -X POST http://localhost:8000/ask \

-H "Content-Type: application/json" \

-d '{"question": "这本书的核心观点是什么？", "top_k": 5}'

预期返回 JSON，包含 answer 和 sources 两个字段。sources 是原始文件路径，可以通过它回到原文查看上下文。

5.3 参数调优

参数	位置	作用	建议
top_k	接口请求体	检索返回片段数量	3-8，片段越多上下文越完整，但噪音也增加
chunk_size	ingest.py	控制入库粒度	600-1000
temperature	模型调用参数	控制回答随机性	知识问答建议 0.2 以下
model	模型服务	生成回答的模型	根据显存和效果选择

如果回答总是无法命中，优先调大 top_k，同时检查分块是否太小。

6. 验证蒸馏效果：不能只看程序能不能跑

6.1 建立三层验证体系

很多项目跑通入库后，直接问问题，发现答得不对，却不知道问题出在哪。这里的核心是要分三层验证：

文本层：原始文件是否被完整抽取，有没有乱码、缺页、转写错误。
检索层：用户问题能否检索到相关片段，相关片段是否排在前面。
问答层：大模型是否基于检索片段回答，而不是编造。

每层都有对应的验证方式，不要跳过。

6.2 用检索脚本查看召回结果

写一个 search.py，只做检索，不做生成：

PYTHON

# search.py

import sys

import chromadb

from ingest import OllamaEmbeddingFunction

client = chromadb.PersistentClient(path="data/chroma")

collection = client.get_or_create_collection(

name="knowledge",

embedding_function=OllamaEmbeddingFunction(),

)

question = sys.argv[1]

results = collection.query(query_texts=[question], n_results=5)

for idx, doc in enumerate(results["documents"][0]):

source = results["metadatas"][0][idx].get("source", "")

print(f"--- [{idx + 1}] {source}")

print(doc[:200])

print()

运行：

BASH

python search.py "作者如何定义效率？"

看到输出后，人工判断召回的前几个片段是否真的和问题相关。如果前三个都不相关，说明问题不在大模型，而在切分或 embedding 选择上。

6.3 可接受的验证指标参考

验证层	指标	参考值	说明
文本层	转写错误率	低于 5%	对标准语音，Whisper base 模型可能会偏高
文本层	抽取覆盖率	关键章节无缺失	对比原书目录和抽取文本
检索层	Top1/ Top5 命中	Top1 尽量相关	通过人工抽测 10 个问题
问答层	引用正确率	回答内容能在片段中找到依据	随机抽 5 个问题检查出处
问答层	幻觉率	越低越好	无法引用时，应回答“资料中没有找到”

这些不是严格标准，而是帮助你判断“这套蒸馏工具是否可信任”。

7. 常见坑与排查链路

7.1 中文转写结果没有标点，整段连在一起

现象：Whisper 转写出来的中文内容是一大段没有标点的文字，检索时往往被切分成不完整片段。

原因：Whisper 的标点依赖于模型对语言习惯的预测，中文标点缺失并不少见。

排查方式：先看转写文本，如果整段没有标点，确认是转写问题而不是切分问题。

处理建议：

使用更大的 Whisper 模型，如 small、medium。
转写后先用大模型做一次标点和分段。
在分隔符列表中加入换行和句号，否则 RecursiveCharacterTextSplitter 会把长句从中间切开。

7.2 分块把语义切断了，同一个主题被拆到两个片段

现象：回答问题时，模型只说出一半，或者两个片段内容重叠严重。

原因：chunk_size 太短，或者分隔符优先级没有配置正确。

排查方式：打开向量库中的片段，看相邻片段第一句和最后一句，判断是否语义完整。

处理建议：

优先按段落切分，而不是按固定字符数硬切。
增大 chunk_overlap。
把 。、！、？ 放到分隔符列表靠前的位置。

7.3 向量检索召回不相关，问题问得对却返回无关片段

现象：检索结果里全是其他主题的内容。

原因：embedding 模型对中文理解不够，或者原始片段本身质量过低。

排查方式：运行 search.py，查看检索排序。

处理建议：

更换多语言 embedding 模型，例如 bge-m3，并拉取到 Ollama。
增加关键词过滤或混合检索，把“向量相似度 + BM25 关键词”结合起来。
检查是否存在空白、乱码、无意义字符，并在入库前过滤掉。

7.4 长视频处理过程中内存不足或中断

现象：Whisper 加载模型后，转写几分钟就报 OOM 或卡死。

原因：一次性把整段音频交给模型推理，显存或内存不够。

排查方式：查看进程日志和资源占用。

处理建议：

先用 ffmpeg 抽取音频，再按 10 分钟一段切分。
使用 faster-whisper，并开启 VAD 过滤静音段。
把长任务放到后台队列，不要用同步接口直接处理大文件。

问题现象	常见原因	检查方式	处理建议
转写无标点	Whisper 模型预测问题	查看原始转写	换模型或让 LLM 补标点
切分语义不完整	chunk_size 过小	查看片段头和尾	调大 chunk_size 和 overlap
检索不相关	embedding 模型弱	运行 search.py	换多语言 embedding 或加混合检索
长视频 OOM	整段推理	查看资源使用	分片转写、使用 faster-whisper

8. 从个人工具到生产级知识服务

8.1 个人自用的运行姿态

如果只是自己使用，这套脚本已经足够。建议运行结构如下：

TEXT

knowledge-distiller/

├── data/

│ ├── raw/ # 原始文件

│ ├── chroma/ # 向量库持久化目录

│ └── logs/ # 日志目录

├── loader.py

├── ingest.py

├── search.py

├── api.py

└── requirements.txt

把需要蒸馏的文件放入 data/raw，执行：

BASH

python ingest.py data/raw/xxx.mp3

新文件只需要增量执行 ingest.py，向量库会按 id 去重或更新。

8.2 部署到服务器需要补齐的能力

部署到团队或公网环境后，不能继续用“手动跑脚本”的方式。至少需要补齐以下能力：

任务队列：用 Celery 或 RQ 处理异步转写和入库任务。
对象存储：原始文件放到 MinIO 或云存储，而不是本地磁盘。
增量更新：通过文件 hash 判断文件是否变化，只处理新增内容。
权限控制：API 增加鉴权，避免知识库被无权限调用。
日志和监控：记录每个请求的耗时、检索来源和回答内容。
备份：向量库和原始文件都需要定期备份，否则重建成本很高。
回滚方案：模型或 embedding 升级后，如果效果下降，要能快速切回旧版本。

embedding 模型和向量库维度绑定，更换 embedding 模型意味着需要重建整个向量库。生产环境里要先做小规模验证，确认没有明显回退，再全量重建。

8.3 知识蒸馏实践清单

发布前检查清单：

[ ] 原始文件和蒸馏结果是否分开存储。
[ ] 每个片段是否都带 source 和 seq 元数据。
[ ] 向量库是否已备份。
[ ] 中文文本是否经过清洗，是否有乱码。
[ ] 是否用 search.py 抽测了至少