TranscriptFlow¶

韌性 AI 資料管道，將原始逐字稿轉換為可搜尋、可摘要、向量化的知識庫。

TranscriptFlow 將 YouTube／SRT 字幕檔案轉換為語意區塊、LLM 生成的摘要與標籤、批次嵌入向量，以及 LanceDB 向量索引。專為長篇逐字稿與批次任務設計，注重可觀測性、重試機制與可復原性。

SRT 字幕 → 語意區塊 → 摘要/標籤 → 嵌入向量 → LanceDB

開始使用功能特色在 GitHub 查看

這是什麼¶

一條從字幕檔案 + 主清單到 LanceDB 知識庫的靈活、容錯路徑：

具備確定性、嵌入輔助的 Smart Merge 區塊切割（非 LLM 臆造時間戳）
四個可復原階段：區塊切割 → 摘要 → 嵌入 → 資料庫寫入
區塊層級重試、原子化檢查點、失敗關閉驗證，以及冪等 LanceDB 寫入
看門狗自動化：批次狀態、並發控制、卡住任務復原
OpenAI 相容的聊天與嵌入 API（OpenAI、LiteLLM、OpenRouter、vLLM 等）

輸出為結構化、RAG 就緒的記錄，適用於語意搜尋、個人知識系統、研究檔案與代理記憶。

這不是什麼¶

不是一鍵影片歸檔工具 — 不會下載影片；你需提供 .srt 與清單檔
不是單一檔案的「幫我摘要這個」示範 — 是具備明確狀態的多階段批次管道
不是由 LLM 主導分段 — 模型在驗證後的區塊切割完成後，才負責摘要與標記
不是託管 SaaS — 你自行執行腳本、指向 API 端點，並管理儲存路徑

為何存在¶

大多數逐字稿工具止步於「摘要這個檔案」。TranscriptFlow 將逐字稿視為資料管道問題——尤其當來源檔案庫龐大、雜亂，且難以僅靠標題搜尋時。

它源自一個實際的保存問題：某個長期更新的心理學頻道計畫下架影片存檔。標題往往與實際討論關聯鬆散，一般搜尋不夠用。早期讓 LLM 自行發明分段邊界的實驗，產生了不穩定的時間軸與幻覺時間戳。那次失敗塑造了目前設計：先做確定性、嵌入輔助的區塊切割，再把 LLM 用在它們最擅長的地方——摘要、標記與元資料。

最終成果不只是摘要工具，而是可復原的逐字稿 → 向量資料庫管道，用來把大量字幕轉成 RAG 就緒的知識庫。

你會得到什麼¶

階段	結果
匯入	SRT／字幕檔與主清單
區塊切割	經驗證的 Smart Merge 語意單元
摘要	每區塊摘要、標籤與模型診斷
嵌入	具備維度檢查與斷路器的批次向量
儲存	以穩定 ID 為鍵的冪等 LanceDB 記錄

適用情境：大量長篇逐字稿、內容難以用標題找到、講者或主題混雜、任務可能耗費數小時或數天，或無法接受模型失敗被靜默吃掉。

文件導覽¶

頁面	說明
功能特色	Smart Merge、四階段管道、重試、檢查點、失敗關閉、看門狗
架構	流程圖、階段、狀態機、元件對照、主清單形狀
快速開始	安裝、主清單、初始化批次、看門狗或手動階段指令
設定	環境變數、設定優先順序、旋鈕與機密衛生
變更紀錄（英文）	精簡版近期版本摘要；完整歷史見 GitHub
English docs	英文文件入口

授權¶

MIT — 詳見儲存庫授權條款。