bilibili-rag: Build a searchable Bilibili knowledge base

Why bilibili-rag targets saved Bilibili media

bilibili-rag addresses a specific problem: saved videos are easy to collect but difficult to search later. It is intended for people who bookmark interviews, talks, courses, technical videos, public lessons, meeting recordings, and podcasts, then want to ask questions about that material instead of reopening every video. The intended users are individual learners, developers, researchers, and knowledge workers who need a private, searchable record of their Bilibili favorites.

The application treats a Bilibili favorite folder as the source collection. After QR-code login, it reads the folder and processes its videos into text and vector data. The README says the resulting answers can be traced to source content, while exports can preserve original material or produce AI-organized Markdown notes. That distinction matters. bilibili-rag is not a general-purpose B站 downloader presented as a media archive. Its useful output is the searchable transcript and the knowledge derived from it.

The online service at `www.bilimind.xyz` is a separate hosted option with credits, while the repository supports local deployment with your own model API keys. Local users avoid the hosted credit system described in the README, but they still need access to DashScope or another configured compatible endpoint. The license also does not grant rights to Bilibili videos, audio, subtitles, or other third-party material, so users remain responsible for platform terms and applicable law.

From favorite folder to RAG answer in bilibili-rag

The documented data path has four stages. First, the user selects a favorite folder and authorizes access through Bilibili QR-code login. The backend then obtains the video list and content. Second, the system retrieves audio and performs automatic speech recognition. If a direct audio URL is unavailable, the fallback path downloads audio with a Cookie, converts it with ffmpeg into 16 kHz mono audio, uploads it to DashScope, and recognizes it there. Multi-part videos are transcribed part by part and merged before storage.

Third, the transcript is divided into retrievable material, sent through the configured embedding model, and written to ChromaDB. SQLite stores application and relational data, while the default `.env.example` places it at `./data/bilibili_rag.db` and Chroma data at `./data/chroma_db`. Keeping these stores separate lets the application retain operational records while using ChromaDB for similarity search.

Fourth, a chat request goes through the FastAPI backend and retrieves relevant chunks before the language model generates an answer. The retrieval settings distinguish candidates considered before fusion or reranking from the final results. The defaults are `RETRIEVAL_CANDIDATE_K=24`, `RETRIEVAL_TOP_K=8`, `RETRIEVAL_MMR_FETCH_K=32`, and `RETRIEVAL_MMR_LAMBDA=0.55`. Setting `CHAT_USE_LLM_ROUTER=false` skips an extra routing call before retrieval, which the README associates with faster first output. If the router is enabled, an additional LLM call classifies the question before retrieval.

This design is better suited to question answering over a focused corpus than to exact browsing of the Bilibili account. Its quality also depends on transcript completeness and whether the embedded text contains the answer being requested.

Local installation and the first ingestion

The local path requires ffmpeg on the host because it is used by the audio fallback. The README instructs macOS users to install it with Homebrew, Windows users to add the installer `bin` directory to `PATH`, and Linux users to install it through `apt`, `yum`, or `pacman`. Then create or activate the Python environment and install the pinned dependencies. The documented quick start uses a Conda environment named `bilibili-rag`:

conda activate bilibili-rag
pip install -r requirements.txt

The requirements file pins FastAPI, Uvicorn, LangChain, ChromaDB, DashScope, SQLAlchemy, and related Python packages. Copy the environment template and edit it with real model credentials. Keep `.env` in the repository root rather than `frontend/`:

cp .env.example .env

A working local DashScope-oriented configuration starts with the following values. Replace the placeholder with the API key issued by the provider:

DASHSCOPE_API_KEY=你的百炼 API Key
OPENAI_API_KEY=
OPENAI_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
LLM_MODEL=qwen3-plus
EMBEDDING_MODEL=text-embedding-v4
CHAT_USE_LLM_ROUTER=false

Start the backend and open its generated API documentation:

python -m uvicorn app.main:app --reload

The expected documentation URL is `http://localhost:8000/docs`. In a second terminal, install and start the Next.js frontend:

cd frontend
npm install
npm run dev

Open `http://localhost:3000`, log in by QR code, and begin with a favorite folder containing only one to three short videos. The first real check is whether ingestion reaches a completed state and whether a question returns a source-linked result. The README does not document a rollback command or an automated way to undo one processed video, so folder selection should be deliberate.

Docker deployment and persistent local data

Docker is the shorter installation path when a local Python and Node.js setup is undesirable. The backend image uses Python 3.11, installs build tools and ffmpeg, installs `requirements.txt`, exposes port 8000, and starts Uvicorn. Compose starts both backend and frontend services, binds them to ports 8000 and 3000, and mounts `./data` and `./logs` from the host into the backend container.

Prepare the same root-level environment file before starting the stack:

cp .env.example .env
# 编辑 .env，至少填写 DASHSCOPE_API_KEY 或 OPENAI_API_KEY

Build and start the services:

docker compose up --build

The Compose configuration gives the frontend a default browser API URL of `http://localhost:8000`. After startup, the web interface is available at `http://localhost:3000` and the backend documentation at `http://localhost:8000/docs`. The backend health check calls `/health` every 30 seconds and allows a 20-second startup period.

Stopping the containers does not remove the bind-mounted project data:

docker compose down

If API keys or model settings change, the README calls for rebuilding and starting the services again. Persisting `./data` helps retain SQLite and ChromaDB state, but it also means operators must manage that directory themselves. Deleting or moving it can remove the local knowledge base and vector index. The README does not document backup format compatibility, so a backup should be treated as a copy of the project data directory rather than as a guaranteed restore procedure.

Audio fallback, model quotas, and operational limits

The main ingestion failure mode is media access. The README states that some Bilibili audio URLs return 403 because direct links may be authenticated, expired, or region restricted. bilibili-rag responds with a documented fallback: authenticated download, ffmpeg conversion to 16 kHz mono, upload to DashScope, and ASR. This improves the handling of unavailable direct URLs, but it does not guarantee success. The account still needs valid access, and the content must reach the configured ASR service.

DashScope usage has three separate cost centers. ASR is charged by audio duration, embeddings by tokens, and chat by tokens. Multi-part videos increase processing time and ASR cost because each part is transcribed. The README recommends testing with a video of about ten minutes before ingesting a large folder. The reported credit figures apply to the separate online BiliMind service, not to local API billing, so they should not be treated as local cost estimates.

The error `AllocationQuota.FreeTierOnly` comes from the upstream model service and indicates a free-tier restriction or exhausted free quota. Users must adjust DashScope quota settings or choose an available model. Another documented limitation is configuration sensitivity: `.env` changes require a backend restart, ASR and embedding use `DASHSCOPE_API_KEY`, while chat uses the OpenAI-compatible endpoint. Confusing `DASHSCOPE_BASE_URL` with `OPENAI_BASE_URL` can lead to the wrong service or request path.

The project is therefore a poor fit for users who require offline transcription, guaranteed availability of every favorite, or predictable zero model expense. Although data storage is local, the documented model path still sends transcription, embedding, or chat content to the configured provider.

bilibili-rag alternatives and maintenance costs

A practical alternative is a manual or script-based transcript search workflow. Instead of importing a favorite folder into a combined vector index, you can save each transcript as Markdown and search those files with an editor or a local full-text tool. That approach is more manual and does not provide the same RAG question interface, but it avoids automatic ASR and vector generation for every item. It also makes it easier to review the exact source text without model-generated synthesis.

Another alternative is a general document RAG application that already accepts local text files. bilibili-rag's distinguishing work is upstream: Bilibili QR-code login, favorite-folder retrieval, media acquisition, multi-part ASR, and the fallback path. A general RAG tool may be better if the content already exists as PDFs or Markdown, while bilibili-rag is more relevant when Bilibili favorites are the actual source.

Upgrade cost depends on which layer changes. Python dependency versions are pinned in `requirements.txt`, and the frontend and backend are separate projects. Model configuration can change without a repository update, but an API contract or browser storage compatibility change could require rebuilding and reindexing. The README lists conversation storage, session management, retrieval history, and support for more LLM and embedding models as future work, which indicates that those capabilities are not part of the documented current feature set.

The repository is not archived. Its last push was on 2026-09-27, and the listed releases include `v0.3.0` dated 2026-07-28 and `v0.2.0` dated 2026-06-20. That recency does not guarantee compatibility, but it does mean this is not an archived repository. Operational cost remains tied to DashScope usage, especially audio duration for ASR and token consumption for retrieval and chat. The Apache-2.0 license permits use under its terms, but it does not settle Bilibili content rights or third-party service obligations.

Editorial conclusion

Adopt bilibili-rag if you regularly revisit Bilibili interviews, lectures, or courses and want local retrieval over their transcripts. Do not choose it if you need an official Bilibili export, guaranteed access to protected media, or a zero-cost service. Before processing a large collection, verify the `.env` configuration, confirm that one short favorite folder completes ingestion, and review DashScope quotas for ASR, embedding, and chat usage.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. via007/bilibili-rag on GitHub