RAG on KnightLi的博客

PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex 是一個很有意思的 RAG 專案。它不從「再建一個向量庫」開始，而是把長文件先整理成類似目錄的樹狀結構，再讓 LLM 沿著這棵樹做推理式檢索。

截至本文整理時，GitHub 頁面顯示專案約有 31.8k stars、2.7k forks，授權為 MIT。README 給它的定位是：Vectorless, Reasoning-based RAG，也就是無向量庫、基於推理的 RAG。

它想解決什麼問題

傳統 RAG 的常見路徑是：切塊、向量化、寫入向量資料庫，再用相似度搜尋召回片段。這套方法簡單、通用，也很成熟，但在長篇專業文件裡容易遇到幾個問題：

相似度不等於真正相關。
文件結構被切塊打散，章節關係丟失。
召回結果可解釋性弱，很難說明為什麼命中這一段。
對財報、監管文件、法律文書、技術手冊這類材料，問題往往需要跨章節推理。

PageIndex 的思路是反過來：先把文件組織成語義樹，再讓模型像人類讀目錄、翻章節、逐層定位一樣查找相關內容。

PageIndex 的基本工作流

README 裡把 PageIndex 的檢索分成兩步：

為文件生成類似 Table-of-Contents 的樹狀結構索引。
透過樹搜尋做 reasoning-based retrieval。

這棵樹不是簡單的檔案目錄，而是面向 LLM 使用的文件結構。節點裡會有標題、頁碼範圍、摘要、子節點等資訊。這樣模型在回答問題時，不必一開始就面對大量零散 chunk，而是可以先判斷應該進入哪個章節，再繼續向下搜尋。

這種方式更適合結構清晰但內容很長的文件，例如：

金融報告和 SEC filings。
監管材料和合規文件。
學術教材和論文。
法律文件。
技術手冊和產品文件。
超過模型上下文視窗的大型 PDF。

和傳統向量 RAG 的差異

PageIndex 的主要賣點可以概括成五點。

第一，不需要 Vector DB。它依賴文件結構和 LLM 推理來定位內容，而不是只做向量相似度搜尋。

第二，不做傳統 chunking。文件會按自然章節組織，而不是被切成固定長度片段。

第三，可解釋性更強。檢索路徑可以對應到頁碼、章節和樹節點，比「向量相似度命中某段文字」更容易追蹤。

第四，檢索是上下文感知的。問題、對話歷史、領域背景都可以影響樹搜尋路徑。

第五，更接近人類專家讀文件的方式。人通常不是把整份文件切成小塊再算相似度，而是先看目錄，再定位章節，最後讀細節。

這並不意味著向量庫沒有價值。更準確的說法是：PageIndex 適合那些「語義相似不夠，需要結構和推理參與」的長文件場景。

本地怎麼跑

README 提供了本地自託管方式。先安裝依賴：

`1`	`pip3 install --upgrade -r requirements.txt`

然後在專案根目錄建立 .env，寫入 LLM API key。專案透過 LiteLLM 支援多模型：

`1`	`OPENAI_API_KEY=your_openai_key_here`

對 PDF 生成 PageIndex 結構：

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

也可以處理 Markdown：

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

常見可選參數包括：

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 裡也提醒，本地開源版本使用標準 PDF 解析。如果是複雜 PDF，專案方的雲服務會提供增強 OCR、樹構建和檢索流程。

Agentic Vectorless RAG 示例

專案還提供了一個 agentic vectorless RAG 示例，使用自託管 PageIndex 和 OpenAI Agents SDK。安裝可選依賴後執行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

這個示例的價值在於，它把 PageIndex 從「生成文件樹」推進到「讓 Agent 使用文件樹檢索」。如果你正在做企業知識庫、財報問答、法規問答或技術文件 Agent，這個示例比單純看 README 更值得跑一遍。

雲服務、MCP 和 API

PageIndex 不只是一個 GitHub repo。專案頁面還給了幾類入口：

自託管：用開源程式碼本地執行，適合試驗和可控部署。
Chat Platform：類似 ChatGPT 的文件分析平台。
MCP / API：方便接入現有 Agent 或自動化流程。
Enterprise：面向私有化或本地部署。

這說明它的定位不是單純的 demo，而是想把「推理式文件檢索」做成一套可整合的文件智能基礎設施。

適合哪些場景

PageIndex 比較適合這些任務：

長 PDF 問答。
財報、年報、招股書、監管文件分析。
法律和合規文件檢索。
技術手冊問答。
多章節教材或論文檢索。
需要可解釋檢索路徑的企業知識庫。
給 Agent 提供結構化文件上下文。

如果你的材料本身很短、結構不明顯，或者只是普通 FAQ，傳統 embedding + vector DB 可能已經夠用。PageIndex 的優勢更容易出現在長文件、強結構、專業領域和需要推理的問題裡。

需要注意什麼

第一，PageIndex 仍然依賴 LLM。樹構建、摘要和檢索品質會受模型能力、提示詞、文件解析品質影響。

第二，本地版本使用標準 PDF 解析，複雜掃描件、圖表密集型 PDF、版式混亂材料可能需要 OCR 和更強的預處理。

第三，無向量庫不等於零成本。樹構建本身也會消耗模型呼叫和時間，尤其是大規模文件庫。

第四，它更像是文件結構索引和推理檢索框架，不是直接替代所有 RAG 技術棧。實際生產裡，也可能和向量檢索、關鍵字檢索、權限控制、快取、稽核系統一起使用。

小結

PageIndex 的有趣之處在於，它把 RAG 的重點從「文字相似度召回」轉向「文件結構 + LLM 推理」。對於長文件和專業文件，這個方向很值得關注。

如果你正在做企業文件問答、金融報告分析、法規檢索或技術手冊 Agent，可以把 PageIndex 當成一個新的 RAG 架構參考：先讓文件有結構，再讓模型沿著結構推理，而不是一開始就把所有內容切碎丟進向量庫。

參考來源：

GitHub：VectifyAI/PageIndex

OpenKB：把文件編譯成可持續更新的 LLM 知識庫

Sun, 17 May 2026 17:15:08 +0800

OpenKB 是 VectifyAI 開源的 LLM 知識庫工具。

它不是傳統意義上「把文件切塊、向量化、查詢時再拼上下文」的 RAG 系統，而是把原始文件先編譯成一個結構化 wiki：有文件摘要、有概念頁、有交叉引用，也有後續查詢和 lint 檢查。換句話說，它更像是一個會持續整理資料的知識庫 CLI。

專案地址：https://github.com/VectifyAI/OpenKB

先說結論

OpenKB 值得關注的地方有三點：

它把知識庫輸出成普通 Markdown 文件，而不是鎖在某個專用資料庫裡。
它用 PageIndex 處理長 PDF，主打無向量資料庫的長文件檢索。
它強調「知識編譯」，讓 LLM 生成摘要、概念頁和交叉連結，而不是每次提問都從零檢索。

這讓 OpenKB 更適合長期累積資料的場景，比如論文閱讀、專案文件、公司內部資料、技術規範、產品調研和個人知識庫。

它也不是萬能替代品。如果你需要高併發線上問答、複雜權限管理、Web 管理後台、企業級審計和大規模多租戶能力，OpenKB 現在更像一個開發者工具和知識庫原型，而不是完整企業知識平台。

OpenKB 是什麼

OpenKB 的全名是 Open Knowledge Base。

它以 CLI 形式工作，把放進知識庫的原始文件轉換、整理、總結，並生成一套 wiki 文件。官方 README 的描述很直接：OpenKB 會用 LLM 把原始文件編譯成結構化、互相連結的 wiki 風格知識庫，並透過 PageIndex 支援無向量資料庫的長文件檢索。

支援的輸入格式包括：

PDF
Word
Markdown
PowerPoint
HTML
Excel
純文字
其他可由 markitdown 轉換的格式

生成後的知識庫位於 wiki/ 目錄，主要包括：

index.md：知識庫總覽
log.md：操作時間線
AGENTS.md：知識庫結構和維護說明
sources/：轉換後的原文
summaries/：每份文件的摘要
concepts/：跨文件概念頁
explorations/：保存的查詢結果
reports/：lint 檢查報告

這個設計最大的好處是透明。你可以直接打開 Markdown 文件查看知識庫，而不是只能透過一個黑盒檢索介面拿答案。

它和傳統 RAG 有什麼不同

傳統 RAG 常見流程是：

把文件切塊。
生成 embedding。
存進向量資料庫。
查詢時召回相關片段。
把片段塞給 LLM 生成答案。

這個流程很成熟，也很適合問答系統。但它有一個問題：知識本身沒有真正沉澱。每次提問都在重新找片段、重新拼上下文、重新生成答案。

OpenKB 的思路更偏「先整理，再問答」：

文件進入 raw/。
短文件透過 markitdown 轉成 Markdown。
長 PDF 透過 PageIndex 生成樹狀索引和摘要。
LLM 生成文件摘要。
LLM 讀取已有概念頁，建立或更新跨文件概念。
知識庫索引、日誌和交叉連結同步更新。

這樣做的結果是，新增一份文件不只是多了一個可檢索文件，而是可能更新十幾個 wiki 頁面。知識會被寫進概念頁裡，並和已有資料發生連結。

這更像人類維護知識庫的方式：新資料進來後，不只是存檔，還要更新主題頁、總結差異、補充引用。

PageIndex 解決什麼問題

長文件一直是 RAG 和 LLM 知識庫裡的難點。

如果直接把長 PDF 切成很多 chunk，容易遇到幾個問題：

章節關係丟失。
表格、圖片和註腳難處理。
檢索片段過碎，答案缺少全局結構。
上下文視窗再大，也不適合把整份文件塞進去。
摘要鏈路過長時，細節容易被壓掉。

OpenKB 使用 PageIndex 來處理長 PDF。按專案說明，PageIndex 會為長文件建立樹狀索引和摘要，讓 LLM 在文件樹上推理，而不是直接讀取整篇長文件。

這條路線的重點不是「向量相似度最高的幾段文字」，而是讓模型利用文件層級結構找到相關內容。對於研究報告、論文、說明書、招股書、合規文件這類長材料，這個思路很有意義。

OpenKB 預設可以使用開源版 PageIndex 本地運行；如果需要 OCR、複雜 PDF 處理或更快結構生成，也可以配置 PAGEINDEX_API_KEY 使用 PageIndex Cloud。

安裝和快速開始

OpenKB 可以直接透過 pip 安裝：

`1`	`pip install openkb`

也可以安裝 GitHub 最新版本：

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

從原始碼開發安裝：

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

建立一個知識庫目錄：

1
2

mkdir my-kb && cd my-kb
openkb init

新增文件：

1
2

openkb add paper.pdf
openkb add ~/papers/

提問：

`1`	`openkb query "What are the main findings?"`

進入互動聊天：

`1`	`openkb chat`

如果你想讓知識庫自動處理新文件，可以使用 watch 模式：

`1`	`openkb watch`

之後把文件放進 raw/，OpenKB 會自動更新 wiki。

LLM 配置

OpenKB 透過 LiteLLM 支援多種模型供應商，包括 OpenAI、Claude、Gemini 等。

初始化時可以設定模型，也可以在 .openkb/config.yaml 裡配置：

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

模型名稱遵循 LiteLLM 的 provider/model 格式。OpenAI 模型可以省略 provider 前綴，例如：

`1`	`model: gpt-5.4`

Anthropic、Gemini 這類模型通常寫成：

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

API key 放在 .env：

`1`	`LLM_API_KEY=your_llm_api_key`

如果啟用 PageIndex Cloud，再補充：

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

常用命令

OpenKB 的命令很適合開發者使用：

openkb init：初始化知識庫。
openkb add <file_or_dir>：新增文件或目錄。
openkb remove <doc>：移除文件，並清理相關 wiki 頁面、圖片、註冊表和 PageIndex 狀態。
openkb query "question"：對知識庫進行一次性提問。
openkb chat：進入多輪對話。
openkb watch：監聽 raw/ 目錄並自動更新。
openkb lint：檢查知識庫結構和內容健康狀態。
openkb list：列出已索引文件和概念。
openkb status：查看知識庫統計資訊。

其中 openkb chat 比 openkb query 更適合連續探索。它支援會話恢復、會話列表和刪除，也支援在聊天中使用 slash commands，比如 /status、/list、/add <path>、/save、/lint。

為什麼 Markdown wiki 很重要

很多知識庫工具的麻煩在於遷移成本。

一旦資料進入專有資料庫、專有索引或專有格式，你就很難直接審查、修改、備份和遷移。OpenKB 把結果寫成普通 Markdown，這讓它天然適合和現有工具配合。

最直接的用法是用 Obsidian 打開 wiki/ 目錄：

摘要頁可以直接閱讀。
概念頁可以用 [[wikilinks]] 互相連結。
圖譜視圖可以看到知識之間的關係。
查詢結果可以保存到 explorations/。
AGENTS.md 可以定義知識庫維護方式。

這讓 OpenKB 不只是一個問答工具，也可以變成個人或團隊的知識整理流水線。

適合哪些場景

OpenKB 特別適合這些場景：

論文和技術報告閱讀。
專案文件整理。
產品調研資料庫。
開源專案原始碼之外的文件知識庫。
公司內部規範、會議紀要和說明文件整理。
個人 Obsidian 知識庫自動維護。
長 PDF、PPT、Word 和網頁資料的結構化沉澱。

如果你經常面對一堆文件，卻不只是想「問一句得到答案」，而是希望資料能逐步變成可瀏覽、可復用、可追蹤的知識庫，OpenKB 的方向就很對。

使用時要注意什麼

第一，OpenKB 依賴 LLM 品質。

摘要、概念頁和交叉連結都由模型生成。模型越強，知識編譯品質越穩定；模型能力不足時，概念抽取、衝突識別和跨文件綜合都會打折扣。

第二，成本要提前估算。

如果一次性匯入大量長文件，LLM 調用成本可能不低。建議先用小規模資料集測試，確認輸出結構和品質，再擴大匯入範圍。

第三，生成的 wiki 仍然需要人工審閱。

OpenKB 可以整理資料，但不等於自動保證事實完全正確。重要知識庫仍然需要人工檢查摘要、概念頁和引用關係。

第四，敏感資料要謹慎。

如果使用雲端 LLM 或 PageIndex Cloud，就要注意文件裡的隱私、商業機密和合規要求。內部資料最好先確認模型供應商、資料保留策略和存取邊界。

第五，它目前更偏 CLI 工具。

專案路線圖裡提到未來會有 Web UI、資料庫儲存、大規模集合支援和層級概念索引。但在目前階段，如果團隊成員不熟悉命令列，使用門檻仍然存在。

和 Obsidian、NotebookLM、企業 RAG 的關係

OpenKB 和 Obsidian 的關係更像「自動整理層」和「閱讀編輯層」。

Obsidian 適合人來寫、改、瀏覽和建立連結；OpenKB 適合把原始文件批量整理成可以進入 Obsidian 的 wiki。

OpenKB 和 NotebookLM 的關係則更偏「本地可控」和「開放文件形態」。

NotebookLM 使用體驗更直接，適合把資料丟進去快速問答和生成摘要；OpenKB 更適合開發者把整理結果留在本地目錄裡，用 Markdown 繼續維護。

OpenKB 和企業 RAG 的關係不是替代，而是補位。

企業 RAG 更看重權限、審計、服務化、權限隔離、監控和穩定吞吐。OpenKB 更適合構建一個可讀、可改、可長期沉澱的知識層。未來如果要做線上問答，也可以把 OpenKB 生成的 wiki 作為更高品質的語料來源。

一個推薦工作流

如果你想試 OpenKB，可以按這個順序來：

新建一個測試知識庫目錄。
先放 3 到 5 份同一主題的文件。
運行 openkb add。
打開 wiki/ 查看摘要和概念頁。
用 openkb query 問幾個具體問題。
用 openkb lint 檢查知識庫健康狀態。
用 Obsidian 打開 wiki/，看連結圖譜是否有意義。
確認品質後，再匯入更大的文件集合。

不要一上來就把幾百個文件全丟進去。先看它對你的資料類型是否理解得好，尤其是表格、圖片、長 PDF 和多文件概念合併效果。

總結

OpenKB 的價值在於，它把 LLM 知識庫從「查詢時臨時拼上下文」往前推了一步：先把資料整理成 wiki，再在 wiki 上問答、聊天、檢查和繼續維護。

這條路線不一定適合所有問答系統，但很適合需要長期沉澱的知識工作。Markdown 文件、Obsidian 相容、PageIndex 長文件處理、多模型支援和 CLI 工作流，組合起來就是一個很適合開發者和研究型使用者的知識庫工具。

如果你手上有大量 PDF、報告、網頁、論文和專案文件，OpenKB 值得試一下。它未必能馬上替代成熟企業知識庫，但可以成為一個很實用的資料整理入口：先把文件變成可讀、可連結、可追蹤的知識，再讓 LLM 在這套知識上工作。

參考連結：

計算機術語人話版：TTS、STT、API、RAG、Agent 到底在說什麼

Tue, 12 May 2026 22:15:34 +0800

計算機領域有很多詞，第一次聽會覺得很高級。可一旦翻譯成人話，往往就是日常生活裡很簡單的動作。

比如 AI 能說話，叫 TTS；AI 能聽你說話，叫 STT。聽起來像複雜系統，拆開就是「把文字讀出來」和「把聲音寫下來」。

參考連結：https://www.zhihu.com/question/267978646/answer/2035405228460201515

這篇就從這個角度串講一些常見術語：保留術語本身，但把它們說成人話。

TTS 和 STT：文字和語音互轉

TTS 是 Text-to-Speech，意思是「文本轉語音」。你輸入一段文字，系統把它變成聲音。導航播報、電子書朗讀、AI 客服開口說話，都屬於這個方向。

STT 是 Speech-to-Text，意思是「語音轉文本」。你對手機說一句話，系統先把語音識別成文字，再交給後面的程式處理。語音輸入法、會議轉寫、自動字幕、智慧音箱，都離不開它。

很多語音 AI 產品的流程其實就是：

STT：把你說的話轉成文字。
LLM：根據文字生成回答。
TTS：把回答讀出來。

所以它看起來像在和你自然聊天，底層往往是幾個模組在接力。

OCR：從圖片裡抄字

OCR 是 Optical Character Recognition，中文常說「光學字元識別」。

聽起來很硬核，其實就是從圖片裡把文字抄出來。拍一張發票、掃描一頁書、識別身分證上的姓名和號碼，本質都是 OCR。

以前 OCR 更像「看字形猜文字」，現在會結合深度學習，對複雜背景、傾斜文字、手寫字和低清圖片的容忍度更高。但它解決的核心問題仍然很直接：圖片裡有什麼字？

NLP 和 LLM：讓機器處理人話

NLP 是 Natural Language Processing，自然語言處理。它處理的是人類語言，比如分詞、翻譯、摘要、情感分析、問答、分類。

LLM 是 Large Language Model，大語言模型。它可以理解和生成文字，所以今天很多 NLP 任務都被 LLM 接管了。

人話版理解：

NLP：讓機器處理人說的話、寫的字。
LLM：一個更大的文字模型，能接住很多語言任務。

你讓 AI 總結文章、寫郵件、改標題、解釋程式碼，背後都屬於這個大方向。

API 和 SDK：一個是介面，一個是工具包

API 是 Application Programming Interface，應用程式編程介面。

人話就是：別人把能力開一個入口給你呼叫。比如天氣 API，你傳城市，它返回天氣；支付 API，你傳訂單，它返回支付結果。

SDK 是 Software Development Kit，軟體開發工具包。

人話就是：為了讓你更方便呼叫 API，官方把常用程式碼、類型、範例和工具打包給你。API 像餐廳窗口，SDK 像點餐小程式。你可以直接去窗口說需求，也可以用小程式點得更省事。

CRUD：增刪改查

CRUD 是 Create、Read、Update、Delete。

翻譯成人話就是：新增、查看、修改、刪除。

很多後台系統、管理系統、資料庫操作，本質都在圍繞 CRUD 打轉。使用者管理、文章管理、訂單管理、庫存管理，看起來業務不同，底層經常都是一組表單加一組增刪改查。

這也是為什麼程式員會說「又寫了一個 CRUD」。不是看不起這個工作，而是它確實太常見。

Cache：先放一份，省得每次重算

Cache 是快取。

人話就是：常用的東西先放在手邊，下次直接拿，不要每次都重新找、重新算、重新請求。

網頁載入慢，可以把圖片和腳本快取起來；資料庫查詢慢，可以把熱門結果放進 Redis；模型推理貴，可以快取重複問題的答案。

快取的難點不在「放一份」，而在「什麼時候更新」。資料變了，快取沒變，就會出現舊資料。這就是很多快取問題的根源。

Queue：排隊慢慢處理

Queue 是佇列。

人話就是：事情太多，先排隊，一個一個處理。

比如使用者上傳影片後，不一定馬上轉碼完成。系統可以先把任務放進佇列，背景服務慢慢處理。發簡訊、發郵件、生成報表、處理訂單回調，也經常用佇列。

佇列解決的是「不要所有事情都卡在當前請求裡」。使用者先得到回應，耗時任務放到後面做。

Index：給資料庫做目錄

Index 是索引。

資料庫裡的索引，可以理解成書的目錄。沒有目錄，你要從第一頁翻到最後一頁；有目錄，你可以更快定位到目標內容。

但索引不是越多越好。查詢會變快，寫入和更新可能變慢，因為資料改了，索引也要跟著維護。

所以資料庫最佳化裡常見的一句話是：慢查詢先看索引。但真正做索引時，還要看查詢條件、排序欄位、資料量和寫入頻率。

RPC、REST 和 Webhook：系統之間怎麼說話

RPC 是 Remote Procedure Call，遠端程序呼叫。

人話就是：我像呼叫本地函式一樣，去呼叫另一台機器上的函式。

REST 常見於 Web API。它更像用 URL 和 HTTP 方法來表達資源操作，比如 GET /users 查使用者，POST /orders 建立訂單。

Webhook 則是反過來通知你。你不用一直問「好了沒」，對方處理完後主動回調你的地址。

簡單記：

RPC：像遠端呼叫函式。
REST：用 HTTP 管理資源。
Webhook：事情發生後主動通知你。

CDN 和 Load Balancing：離你近一點，分擔一點

CDN 是 Content Delivery Network，內容分發網路。

人話就是：把靜態資源放到離使用者更近的節點。使用者訪問圖片、影片、CSS、JS 時，不必每次都跑到源站。

Load Balancing 是負載均衡。

人話就是：訪問量太大，不要讓一台伺服器硬扛，把請求分給多台機器。

一個偏「離使用者近」，一個偏「別讓機器累死」。大型網站通常兩個都會用。

Docker、Container 和 Kubernetes：打包、運行、調度

Docker 是常見的容器工具，Container 是容器。

人話就是：把程式和它依賴的環境打包在一起，換一台機器也盡量能一樣運行。這樣可以減少「我電腦上能跑，伺服器上不能跑」的問題。

Kubernetes，常寫作 K8s，是容器編排系統。

人話就是：當容器很多時，幫你安排它們運行在哪裡、掛了怎麼重啟、流量怎麼分、版本怎麼更新。

如果只有一個小服務，Docker 就夠了；如果有很多服務、很多機器、很多副本，才會更需要 K8s。

CI/CD：自動建置、自動發布

CI 是 Continuous Integration，持續整合。

人話就是：程式碼一提交，系統自動拉程式碼、跑測試、建置，盡早發現問題。

CD 可以指 Continuous Delivery 或 Continuous Deployment，持續交付或持續部署。

人話就是：建置通過後，把程式碼更穩定、更自動地送到測試環境或生產環境。

它解決的不是「寫程式碼」，而是「寫完程式碼之後，怎麼少出錯地上線」。

Serialization：把物件打包成可傳輸格式

Serialization 是序列化。

人話就是：把程式裡的物件變成能保存、能傳輸的格式，比如 JSON、XML、Protobuf。

反過來，Deserialization 是反序列化：把這些格式再還原成程式能用的物件。

你在前後端之間傳 JSON，在服務之間傳 Protobuf，本質都離不開序列化。

Token、Embedding、Vector DB：把文字變成模型能處理的形式

Token 在大模型裡通常指文字切分後的基本單位。它不一定等於一個漢字或一個英文單字，更像模型內部處理文字時的顆粒。

Embedding 是嵌入向量。

人話就是：把文字、圖片或其他內容變成一串數字，讓模型可以比較它們之間的相似度。

Vector DB 是向量資料庫。

人話就是：專門存這些向量，並且能快速找出「意思相近」的內容。

比如你問「怎麼重置路由器」，系統可能去向量庫裡找「恢復出廠設定」「忘記 Wi-Fi 密碼」「後台登入失敗」等相近內容，再拿回來給模型參考。

RAG：先查資料，再回答

RAG 是 Retrieval-Augmented Generation，檢索增強生成。

人話就是：模型回答前，先去資料庫查相關內容，再帶著資料回答。

它解決的是大模型容易「憑記憶瞎說」的問題。把企業文檔、知識庫、產品手冊、程式碼片段接進來，模型就不只是靠訓練時的記憶，而是能參考你給它的最新資料。

典型流程是：

使用者提問。
系統把問題轉成 Embedding。
去 Vector DB 裡找相關文檔。
把文檔片段和問題一起交給 LLM。
模型生成回答。

所以 RAG 聽起來高級，本質是「先翻資料，再組織語言」。

Agent：會自己拆任務的自動化流程

Agent 在 AI 語境裡經常被翻譯成智能體。

人話就是：它不只是回答一句話，而是能根據目標拆步驟、呼叫工具、觀察結果，再決定下一步。

比如你讓它「幫我分析這個倉庫為什麼測試失敗」，普通聊天模型可能只給建議；Agent 則可能會讀檔案、運行測試、看報錯、改程式碼、再跑測試。

當然，Agent 不等於一定可靠。它只是把「模型 + 工具呼叫 + 狀態循環」串起來。真正好不好用，還要看工具權限、任務邊界、錯誤處理和人工確認機制。

小結

很多計算機術語之所以顯得高級，是因為它們被英文縮寫、架構圖和產品文案包了一層殼。拆開之後，大多是在描述很樸素的動作：

TTS：把文字讀出來。
STT：把聲音寫下來。
OCR：從圖片裡抄字。
API：開放一個呼叫入口。
SDK：把呼叫工具打包好。
CRUD：增刪改查。
Cache：常用結果先存一份。
Queue：任務排隊慢慢處理。
Index：給資料做目錄。
CDN：把內容放近一點。
Load Balancing：把請求分散一點。
Docker：把運行環境打包。
CI/CD：讓測試和發布自動化。
Embedding：把內容變成數字向量。
RAG：先查資料，再回答。
Agent：讓模型帶著工具分步做事。

術語要保留，因為它們方便搜尋、溝通和查文檔。但理解時不用被它們嚇住。先翻譯成人話，再回到技術細節裡看，很多概念會清楚得多。

參考

知乎回答：https://www.zhihu.com/question/267978646/answer/2035405228460201515

Gemini Embedding 2：把文字、圖像、影片和音訊放進同一個向量空間

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog 介紹了 Gemini Embedding 2 的開發用法。這個模型已經透過 Gemini API 和 Gemini Enterprise Agent Platform 進入 GA，重點不只是「新的 embedding 模型」，而是把文字、圖像、影片、音訊和文件映射到同一個語義空間。

這會讓檢索系統的邊界變寬。過去很多 RAG 流程需要先把圖片、影片、音訊拆成文字或中繼資料，再分別建立索引；Gemini Embedding 2 則可以直接處理多模態輸入，讓代理、搜尋和分類系統更容易圍繞真實業務材料工作。

原文連結：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

模型能力

Gemini Embedding 2 支援 100 多種語言。單次請求可以處理：

最多 8,192 個文字 token
最多 6 張圖片
最多 120 秒影片
最多 180 秒音訊
最多 6 頁 PDF

它的關鍵點是「統一語義空間」。開發者可以把不同模態的內容放在同一套向量表示裡，用同一種檢索、聚類或重排序邏輯處理。

例如，文字描述和圖片可以放在同一次 embedding 請求裡：

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

如果你希望每個輸入分別得到 embedding，而不是聚合成一個向量，可以使用 Batch API。原文也提到，Agent Platform 對這類批次支援還在跟進中。

對 RAG 的意義

多模態 embedding 對代理式 RAG 很有用。一個 AI agent 可能需要同時檢查程式碼倉庫、PDF、截圖、圖表、音訊會議紀錄和產品圖片。如果所有資料都能進入同一個語義空間，檢索鏈路就不必為每種材料單獨設計一套入口。

Google 建議根據任務使用 task prefix，讓 embedding 更貼近檢索目標。例如問答、事實核查、程式碼檢索和搜尋結果，可以使用不同前綴：

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

這種前綴適合非對稱檢索：使用者查詢往往很短，文件內容往往很長。把 query 和 document 分別按任務格式整理，可以改善短查詢到長文件之間的匹配。

原文給了兩個落地回饋：

Harvey 在法律檢索基準上，Recall@20 precision 相比上一代 embedding 提升 3%。
Supermemory 在 Recall@1 搜尋準確率上提升 40%，並把它用於記憶、索引、搜尋和問答管線。

這些數字不代表所有場景都會同幅度提升，但說明多模態 embedding 已經不只是展示能力，而是在真實檢索產品中產生效果。

視覺搜尋

Gemini Embedding 2 也適合做以圖搜圖、圖文混合搜尋和商品識別。原文提到服裝租賃公司 Nuuly 用它匹配倉庫中未打標籤的服裝照片，使 Match@20 從 60% 提升到接近 87%，整體成功識別率從 74% 提升到 90% 以上。

這類場景的關鍵不是生成內容，而是理解「這張圖片和哪個庫存、文件或商品紀錄最接近」。如果你的業務裡有大量圖片、影片片段或掃描件，多模態 embedding 會比純文字索引更自然。

檢索重排序

Embedding 還可以用於 rerank。常見做法是先用基礎檢索拿到一批候選結果，再計算候選結果和使用者查詢之間的相似度，把更相關的內容排到前面：

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文還提到一種思路：先讓模型根據內部知識生成一個假設答案，再把這個假設答案做 embedding，與候選內容比較相似度，用來挑出語義更貼近的結果。這對問答型 RAG 尤其有用。

聚類、分類和異常檢測

除了檢索，embedding 也適合聚類、分類和異常檢測。和前面的問答檢索不同，這些屬於對稱任務，query 和 document 可以使用同一種任務前綴：

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

這類任務可以用於輿情分類、內容審核、相似資產歸類、異常樣本發現，也可以幫助 agent 對大量上下文材料先做整理，再進入後續推理。

儲存和成本

Gemini Embedding 2 預設輸出 3,072 維向量。它使用 Matryoshka Representation Learning，因此可以透過 output_dimensionality 把向量截斷到更小維度。Google 推薦在效率優先時使用 1,536 或 768 維：

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

向量可以存到 Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB 等系統裡。成本方面，原文提到 Batch API 可提供更高吞吐，並達到預設 embedding 價格的 50%。

開發者該怎麼用

如果你已有文字 RAG，可以先從兩類增量改造開始：

把 PDF、截圖、圖片說明和文字文件放入同一個索引，測試查詢召回是否更穩定。
給不同任務加 task prefix，例如問答、事實核查、程式碼檢索、商品搜尋，不要把所有內容都按同一種 embedding 方式處理。

如果你在做新產品，可以優先考慮這些方向：

企業知識庫：同時檢索文件、圖表、簡報截圖和會議材料。
視覺搜尋：用圖片、文字或混合輸入查找商品、資產、設計稿和檔案。
Agent 工具鏈：讓 coding agent、研究 agent 或客服 agent 檢索多種格式的業務材料。
內容治理：對文字、圖片、影片片段做統一分類、聚類和異常檢測。

Gemini Embedding 2 的價值在於把多模態材料變成同一套可檢索資產。對開發者來說，這會減少「先轉文字再檢索」的中間層，也讓 RAG 系統更接近真實世界的資料形態。

常見向量模型怎麼選：OpenAI、BGE、E5、GTE、Jina 對比

Thu, 23 Apr 2026 15:23:47 +0800

做 RAG、語義搜尋、知識庫召回時，很多人一開始都會糾結同一個問題：向量模型這麼多，到底該選哪一個。

常見模型大致可以分成兩組。一組是通用文字向量，覆蓋中英文和多語言任務；另一組更適合中文場景，重點看中文檢索、中文問答和中文知識庫效果。

如果先給一個很短的結論，可以這樣看：

想省事、直接用 API：text-embedding-3-small 或 text-embedding-3-large
想做中文檢索，且希望開源可自部署：bge-base-zh-v1.5、bge-m3、gte-large-zh
想兼顧多語言：multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
想在中文場景裡壓低成本：bge-small-zh-v1.5、gte-base-zh

一、先按類型看這些模型

1. OpenAI 系列

text-embedding-3-small
text-embedding-3-large

這類模型的特點是調用簡單、穩定，適合直接接 API 做檢索、RAG、分類和相似度匹配。它們的優勢不在於「某一個中文榜單分數特別高」，而在整體體驗完整：接入門檻低、效果穩定、工程成本也低。

如果團隊不想自己託管模型、不想維護推理服務，OpenAI 這類方案通常最省時間。

2. BGE 系列

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE 是中文檢索裡很常見的一條線。bge-small-zh-v1.5 和 bge-base-zh-v1.5 更偏中文單語任務，適合中文語義搜尋、知識庫召回、FAQ 匹配。bge-m3 則更通用，能覆蓋多語言、多粒度和更複雜的檢索場景。

如果你的資料主要是中文文本，BGE 往往是最容易進入候選名單的一組。

3. E5 系列

intfloat/multilingual-e5-base
multilingual-e5-large

E5 系列的特點是多語言能力比較均衡，適合中英混合、跨語種檢索、國際化內容庫。它不是只盯中文，而是更強調「不同語言都能放到一個統一檢索體系裡」。

如果你的語料不是純中文，而是中文、英文、日文甚至更多語言混在一起，E5 通常比中文專用模型更穩。

4. GTE 系列

Alibaba-NLP/gte-base-zh
gte-large-zh

GTE 在中文任務裡也很常見，定位和 BGE 有點接近，都是中文檢索的實用型選手。它的特點通常是比較平衡，沒有特別複雜的使用門檻，適合做中文知識庫、站內搜尋和企業內部文件召回。

如果你想在中文開源模型裡多做一組對照，GTE 很值得一起評測。

5. Jina Embeddings

jina-embeddings-v3

Jina 這一類更偏通用和現代工程場景，常見於多語言檢索、長文字、網頁內容處理等任務。它經常出現在「一個模型覆蓋更多任務形態」的討論裡，適合希望統一 embedding 層的團隊。

如果你的內容來源比較雜，既有網頁、文件，也有多語言文本，Jina 往往是一個值得測試的備選。

二、中文場景裡，哪些模型更常用

如果把範圍收窄到中文場景，常見候選基本就是這些：

bge-small-zh-v1.5
bge-base-zh-v1.5
bge-m3
gte-base-zh
gte-large-zh
multilingual-e5-base
multilingual-e5-large

這幾類裡，最典型的分法其實不是「誰絕對更強」，而是下面這三個問題：

你的資料是不是以中文為主
你是不是需要多語言
你更在意效果、成本，還是部署方便

三、把這些模型放在一起看

1. 如果只看中文效果

純中文知識庫、中文問答、中文文件召回，一般優先看 BGE 和 GTE。

bge-small-zh-v1.5：更輕，適合成本敏感場景
bge-base-zh-v1.5：通常是中文場景裡更均衡的一檔
gte-base-zh：和輕量 BGE 類似，適合先做基線
gte-large-zh：更適合追求召回品質的場景
bge-m3：適合希望把中文檢索和更複雜能力放到一起考慮的團隊

如果語料幾乎全是中文，E5 雖然也能用，但很多時候不會是第一優先。

2. 如果需要多語言

這時優先級會明顯變化。

multilingual-e5-base 和 multilingual-e5-large 更適合多語言統一檢索
jina-embeddings-v3 也適合多語言和通用文字任務
bge-m3 比傳統中文專用模型更適合擴展到多語言
text-embedding-3-small 和 text-embedding-3-large 適合想直接上 API 的場景

如果你的庫裡同時有中文、英文、產品文件、網頁文案和使用者問題，多語言模型會比中文專用模型省掉很多後續改造成本。

3. 如果要控制推理和儲存成本

輕量模型更有優勢。

bge-small-zh-v1.5
gte-base-zh
multilingual-e5-base
text-embedding-3-small

這類模型通常更適合：

文件量大
更新頻繁
需要批量向量化
對延遲和成本比較敏感

如果資料規模很大，embedding 維度、推理速度、索引占用都會直接影響總成本，所以「先上小模型做基線」通常是更穩的做法。

4. 如果優先追求上限

更大的模型通常更適合複雜檢索或高品質召回，例如：

text-embedding-3-large
multilingual-e5-large
gte-large-zh
bge-base-zh-v1.5
bge-m3

但這裡要注意，模型越大不代表線上體驗一定越好。很多專案最後的瓶頸不是模型本身，而是切分策略、召回條數、重排、資料清洗和評測方式。

四、每個模型更適合什麼任務

模型	更適合的場景	簡單判斷
`text-embedding-3-small`	通用檢索、RAG、快速接入	API 省事，成本友好
`text-embedding-3-large`	更重視品質的通用檢索	效果優先，工程最省心
`bge-small-zh-v1.5`	中文輕量檢索	中文常用入門款
`bge-base-zh-v1.5`	中文知識庫、FAQ、語義搜尋	中文場景很均衡
`bge-m3`	中文為主但希望兼顧更複雜檢索	擴展性更強
`multilingual-e5-base`	多語言基礎檢索	國際化專案常用
`multilingual-e5-large`	多語言高品質召回	更偏效果導向
`gte-base-zh`	中文輕量召回	適合先做基線
`gte-large-zh`	中文品質優先場景	可作為 BGE 對照組
`jina-embeddings-v3`	多語言、網頁、通用文字任務	統一 embedding 層時值得測

五、實際選型時可以怎麼決策

如果你只是要落地，而不是寫論文，選型順序可以簡單一點：

場景一：中文知識庫

優先測試這幾組：

bge-base-zh-v1.5
gte-large-zh
bge-small-zh-v1.5

如果預算緊，先從小模型開始；如果更重視召回品質，再往更大的模型試。

場景二：中英混合知識庫

優先測試：

multilingual-e5-base
multilingual-e5-large
text-embedding-3-small
text-embedding-3-large

如果不想自部署，OpenAI 會更直接；如果要自己託管，E5 更常見。

場景三：中文為主，但未來可能擴到多語言

優先測試：

bge-m3
multilingual-e5-base
jina-embeddings-v3

這類場景最怕的是一開始只看中文，後面又要重做整個向量庫。

六、最後怎麼選，關鍵不是「榜單第一」

向量模型選型裡，最容易踩的坑就是只看公開分數，然後直接上線。

更可靠的方式通常是：

先挑 2 到 4 個候選模型
用自己的真實資料做 embedding
跑一輪召回評測
再結合成本、延遲、部署方式做決定

因為真正決定結果的，往往不是模型名本身，而是模型和你的語料、分塊策略、查詢形式到底合不合。

總結

如果只想記住一版實用結論，可以這樣：

中文優先：先看 bge-base-zh-v1.5、gte-large-zh
成本優先：先看 bge-small-zh-v1.5、gte-base-zh、text-embedding-3-small
多語言優先：先看 multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
直接上 API：先看 text-embedding-3-small、text-embedding-3-large
想兼顧中文和後續擴展：先看 bge-m3

沒有一個模型適合所有專案，但大多數專案都可以先從這幾組裡很快篩出第一批候選。

AI 名詞解釋：用白話講清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

剛開始接觸 AI，最容易讓人卻步的通常不是模型本身，而是討論裡那些一串一串的名詞。Agent、MCP、RAG、AIGC、Token 看起來都很常見，但如果沒有人先用白話講一遍，很多人其實只是「看過」，不是真的懂。

這篇就順著一組常見入門解釋的思路，把 10 個高頻 AI 名詞壓縮成一套更容易記住的意思。目標不是講得多學術，而是先幫你建立一個能跟上日常 AI 討論的基本框架。

10 個常見 AI 名詞，分別是什麼意思

1. Agent：不只會聊天的執行型 AI

Agent 可以先理解成「會做事的 AI 助手」。

一般聊天機器人比較像是你問一句、它答一句；Agent 則更進一步，它會把任務拆開、安排步驟、調用工具，最後把結果交回來。比如你叫它整理資料、查資訊、生成文件，它不只是給建議，而是可能直接把這些動作串起來完成。

所以 Agent 的重點，不在「會不會說」，而在「能不能做」。

2. OpenClaw：駐留在電腦裡的 AI 助手

這裡的 OpenClaw 被形容成一種住在你電腦裡的 AI 助手。

你可以把這類工具理解成更貼近桌面操作的 AI 幫手。它不只是接收文字，也可能直接觀察介面、調用本地工具、按流程執行任務。和一般網頁聊天相比，這類工具更強調實際操作能力。

如果說 Agent 是抽象層面的執行型 AI，那這種桌面型助手就是它在個人電腦上的一種具體落地形式。

3. Skills：替 Agent 裝上的能力包

Skills 可以理解成 Agent 的功能模組或操作說明。

同一個 Agent，裝上不同的 Skills，就會展現出不同的專長。有些偏文案，有些偏資料整理，有些偏程式處理。它們有點像手機裡的 App，也有點像一套套可重複利用的工作流程。

所以很多時候，不是模型突然變聰明了，而是它背後多了一組更明確的規則、工具和步驟。

4. MCP：AI 連接外部工具的統一方式

MCP 全稱是 Model Context Protocol。

如果用生活化的比喻，它有點像 AI 世界裡的 Type-C 介面。以前模型要接不同工具，往往得一套一套分開整合；有了統一協議之後，接入方式就會更標準，也更容易重複使用。

對大多數使用者來說，最值得記住的一點是：MCP 解決的不是模型會不會回答，而是模型怎麼安全、穩定地接上外部工具和資源。

5. 抽卡：AI 生成結果本來就有隨機性

「抽卡」這個說法常見於 AI 繪圖、影片生成和內容創作場景。

意思很簡單。就算是同樣的提示詞、同樣的大方向，每次生成出來的結果也可能不同。有時候效果很好，有時候明顯翻車，所以很多人會把反覆生成這件事形容成像遊戲裡抽卡。

它真正提醒我們的是：AI 生成不是固定公式，而是一個帶有機率波動的過程。

6. API：應用和模型之間的連接方式

API 全稱是 Application Programming Interface，也就是應用程式介面。

你可以把它理解成程式之間溝通的標準入口。當你在自己的應用、腳本或編輯器裡呼叫模型服務時，本質上就是透過 API 發送請求，再拿回結果。

如果把模型服務比作一家餐廳，那麼：

菜單像 API 文件
點餐像發起 API 請求
廚房出餐像模型回傳結果

所以很多工具表面看起來不一樣，但底層其實都在呼叫某種 API。

7. 多模態：AI 不只會處理文字

「多模態」說的是 AI 不再只會讀寫文字，而是可以同時處理多種形式的資訊。

例如它可以看圖、聽語音、理解影片、生成圖片，甚至支援即時語音和視訊互動。和早期只能處理文字的模型相比，多模態模型更接近同時具備「看、聽、說、寫」的能力。

這也是為什麼現在很多 AI 產品，已經不再只圍繞一個文字輸入框來設計。

8. RAG：先找資料，再組織答案

RAG 是 Retrieval-Augmented Generation，通常譯作檢索增強生成。

它適合用來解決一個很實際的問題：模型的訓練資料有時間邊界，也不會自動知道你公司最新的文件、客服紀錄或業務規則。RAG 的做法是先從指定資料裡找出相關內容，再根據這些內容生成回答。

它的價值通常體現在三點：

答案更容易貼近真實資料
可以追溯答案依據來自哪裡
新文件加入後，知識也能快速更新

所以很多企業知識庫、AI 客服和內部問答系統，底層都會用到 RAG。

9. AIGC：AI 生成內容的總稱

AIGC 是 AI Generated Content 的縮寫。

它不是某一個單獨工具，而是一個總稱，泛指 AI 生成出來的內容，包括文字、圖片、音訊、影片等各種形式。你看到的 AI 寫稿、AI 製圖、AI 做短影片、AI 配音，都可以放進 AIGC 這個大框架裡理解。

這個詞真正重要的地方在於，它描述的是一種內容生產方式，而不是某一個具體模型。

10. Token：模型處理內容時的計量單位

Token 可以理解成模型處理文字時使用的基本計量單位。

它不完全等於「一個字」或「一個單詞」，但在實際使用時，你可以先把它當成模型計算和計費的通用單位。你的輸入會消耗 Token，模型輸出的內容會消耗 Token，上下文裡保留的歷史內容同樣也會占用 Token。

所以為什麼很多模型服務一直強調上下文長度、成本控制和提示詞壓縮，本質上都和 Token 有關。

RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow 是 infiniflow 開源的 RAG（Retrieval-Augmented Generation，檢索增強生成）引擎。它的目標不是只做一個「上傳文件然後問答」的知識庫外殼，而是把文件解析、切分、檢索、重排、引用溯源、模型配置、Agent 能力和 API 整合放進一套完整工作流裡。

如果你正在做企業知識庫、文件問答、客服助手、內部資料檢索，或者想給 LLM 加一層更可靠的上下文來源，RAGFlow 屬於值得重點看的開源方案。

01 RAGFlow 解決什麼問題

普通 RAG 系統最容易遇到的問題有三個：

文件解析品質不穩定，尤其是 PDF、掃描件、表格、圖片、複雜排版文件。
切分策略不透明，命中結果看起來像是「搜到了」，但上下文並不完整。
回答缺少可靠引用，使用者很難判斷答案來自哪裡。

RAGFlow 的重點正好放在這些地方。專案 README 裡強調了 Deep document understanding、模板化切分、可視化 chunk、引用溯源和多路召回加重排。換句話說，它更關注「高品質資料進入，高品質答案輸出」，而不是只把向量資料庫和聊天框接起來。

02 核心功能

1. 深度文件理解

RAGFlow 支援從複雜格式的非結構化資料中抽取知識。README 中列出的資料類型包括 Word、PPT、Excel、TXT、圖片、掃描件、結構化資料、網頁等。

這對企業知識庫很關鍵。真實資料通常不是乾淨的 Markdown，而是合約、報告、表格、掃描 PDF、產品手冊、截圖和網頁混在一起。如果解析品質不夠，後面的向量檢索和 LLM 回答都會被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的價值在於：切分策略不是黑盒，可以根據文件類型選擇更合適的方式。

例如普通文章、論文、表格、問答文件、圖片說明、合約條款，對 chunk 的粒度和邊界要求都不一樣。模板化切分可以減少「句子被切碎」「表格上下文丟失」「標題和正文分離」這類問題。

3. 可追溯引用

RAGFlow 強調 grounded citations，也就是回答要能追溯到來源片段。它還提供 chunk 可視化，方便人工干預解析和切分結果。

這點對生產環境尤其重要。企業內部問答不是只要「看起來像答案」，還要能查證來源。對於政策、合規、財務、技術文件、客戶支持資料來說，引用和溯源幾乎是剛需。

4. 自動化 RAG 工作流

RAGFlow 把 RAG 流程做成相對完整的鏈路：

建立知識庫
上傳或同步資料
解析文件
查看和干預 chunk
配置 LLM 與 embedding 模型
執行多路召回與重排
建立聊天助手
透過 API 整合到業務系統

這讓它更像一個 RAG 平台，而不是單點工具庫。對團隊來說，UI、可視化和 API 都有價值：非研發人員可以維護知識庫，研發人員可以把能力接入既有系統。

5. Agent、MCP 與工作流能力

RAGFlow 的近期更新裡已經包含 Agentic workflow、MCP、Agent Memory、程式碼執行元件等內容。這說明它不只想做傳統知識庫問答，也在向 Agent 場景延伸。

典型方向是：Agent 在執行任務時，可以把 RAGFlow 作為可靠的企業知識上下文層；需要查資料時從知識庫召回，生成回答時保留引用，必要時再組合工具呼叫或工作流。

03 基本使用流程

按照官方快速開始文件，RAGFlow 的常見使用路徑可以概括成下面幾步。

1. 準備執行環境

官方 README 給出的基礎要求是：

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

如果要使用程式碼執行器的沙箱功能，還需要 gVisor。另外要注意，官方 Docker 映像主要面向 x86 平台；如果是 ARM64，需要依照官方說明自行建置映像。

2. 拉取專案

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 檢查 `vm.max_map_count`

RAGFlow 部署會依賴 Elasticsearch / OpenSearch 這類元件，因此在 Linux 上通常需要確認：

`1`	`sysctl vm.max_map_count`

如果數值低於 262144，可以暫時設定：

`1`	`sudo sysctl -w vm.max_map_count=262144`

如果希望重開機後仍然生效，需要寫入 /etc/sysctl.conf。

4. 使用 Docker Compose 啟動

CPU 模式可以直接啟動：

`1`	`docker compose -f docker-compose.yml up -d`

如果要用 GPU 加速 DeepDoc 任務，README 中給出的方式是在 .env 中啟用 DEVICE=gpu 後再啟動：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

啟動後查看日誌：

`1`	`docker logs -f docker-ragflow-cpu-1`

看到服務啟動完成後，再透過瀏覽器訪問伺服器地址。預設配置下，通常可以直接訪問：

`1`	`http://IP_OF_YOUR_MACHINE`

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中選擇預設 LLM factory，並更新對應的 API_KEY。

實際使用時，你需要根據自己的模型供應商配置：

聊天模型
embedding 模型
rerank 模型
多模態模型（如果要理解 PDF / DOCX 中的圖片）

6. 建立知識庫並上傳文件

服務啟動後，典型操作是：

登入 Web UI。
建立 dataset / knowledge base。
上傳文件或配置資料源同步。
等待解析完成。
查看 chunk 結果，必要時人工調整。
建立聊天助手，選擇知識庫。
測試問答效果和引用來源。

如果要接入業務系統，可以繼續使用 RAGFlow 的 API 或 SDK，把知識庫檢索和聊天能力接到自己的應用裡。

04 適合哪些場景

RAGFlow 適合這些需求：

企業內部知識庫問答
產品手冊、技術文件、FAQ 檢索
客服助手和售前支持助手
合約、報告、制度文件的可追溯問答
多格式資料統一整理
需要 UI 維護知識庫，同時又要 API 整合的團隊
想把 RAG 能力作為 Agent 上下文層的系統

它尤其適合文件格式複雜、需要引用溯源、希望人工干預解析結果的場景。

05 使用時要注意什麼

第一，RAGFlow 不是輕量腳本。它對機器資源有要求，官方建議至少 4 核 CPU、16GB 記憶體和 50GB 磁碟。如果只是給少量 Markdown 做問答，可能沒必要上這麼完整的平台。

第二，文件品質仍然重要。RAGFlow 能改善解析和切分，但不能讓低品質、過期、互相矛盾的資料自動變得可靠。真正上線前，知識庫治理仍然要做。

第三，模型配置會直接影響效果。embedding、rerank、聊天模型、多模態模型的選擇，都會影響召回和回答品質。RAGFlow 提供了工作流，但效果仍然要靠資料、模型和參數一起調。

第四，生產環境要關注權限和資料安全。企業知識庫裡往往有內部資料，部署方式、訪問控制、日誌、API Key、模型供應商資料策略都要提前設計。

06 簡短判斷

RAGFlow 的優勢在於把 RAG 裡最麻煩的部分做成了平台化能力：複雜文件解析、可解釋切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 擴展。

如果你要做的是可驗證、可維護、可接入業務系統的企業知識庫，RAGFlow 比「向量庫 + 簡單聊天 UI」的方案更完整。反過來，如果只是個人小規模資料問答，或者資料格式非常簡單，輕量 RAG 框架可能更省資源。