2025/05/11

Quivr 101


🚀 Quivr 的核心功能與特性


根據原始碼內容，Quivr 是一個以生成式 AI 驅動的 RAG（檢索增強生成）系統，設計目的是成為用戶的「第二大腦」。以下是它的主要功能與運作機制。

🔑 核心功能


1️⃣ 精心設計的 RAG 實作架構


Quivr 內建一套高效且有明確設計原則的 RAG 工作流程。

📄 參考：README.md:15

  • 幫助開發者專注於應用層開發，而無需處理繁瑣的底層檢索與生成邏輯。

2️⃣ 支援多家大型語言模型（LLM）


Quivr 可整合多種 LLM 供應商，包含：

📄 參考：README.md:16

  • OpenAI（GPT 系列）

  • Anthropic（Claude）

  • Mistral

  • Google Gemma


→ 使用者可依照成本、效能與模型特性選擇最適合的 LLM。

3️⃣ 通用文件格式支援


Quivr 可處理多種常見文件類型：

📄 參考：README.md:17

  • PDF

  • 純文字（TXT）

  • Markdown

  • 可自定義解析器來支援特殊格式

4️⃣ 可自定義 RAG 流程


使用者可依需求自訂工作流程：

📄 參考：README.md:18

  • 加入網路搜尋功能

  • 整合外部工具與 API

  • 調整檢索與生成策略（如查詢改寫、過濾節點）

5️⃣ 與 Megaparse 整合


Quivr 支援與 Megaparse 整合，提升文件處理與資訊萃取能力。

📄 參考：README.md:19

🧠 Quivr 的核心運作方式


核心邏輯由 Brain 類別負責調度與串接各模組：

📄 參考：index.md:58-61

  • 建立知識庫（從檔案匯入）

  • 將文件轉換為向量嵌入並儲存

  • 透過自然語言查詢知識庫

  • 回傳由 AI 生成的回答

✏️ 使用範例


✅ 基本用法


📄 參考：README.md:57-74

  • 建立一個暫時的文字檔案

  • 建立一個 Brain 實例並匯入檔案

  • 提出問題，獲得 AI 回答

🔧 工作流程設定（YAML）


Quivr 支援使用 YAML 自訂 RAG 工作流程：

📄 參考：README.md:97-115


範例步驟包括：

  • 過濾對話歷史

  • 查詢重寫

  • 進行文件檢索

  • 基於檢索結果生成答案

⚙️ 客製化選項


📄 參考：README.md:120-139

  • 可選擇不同的 reranker 模型（如 Cohere）

  • 設定回傳段落數量（top_n）

  • 調整 LLM 的參數（token 數量、溫度值）

📊 可視化與互動應用

  • 官方文件中包含 工作流程圖解，說明各組件如何協作

    📄 參考：README.md:80-82

  • 也提供建立互動聊天介面的示範（如使用 Chainlit）

    📄 參考：quickstart.md:73-80

🎯 實際應用場景


根據原始碼與設計，Quivr 適用於以下領域：

  • 個人知識管理：建立可查詢的個人筆記與文件資料庫

  • 研究輔助：解析學術論文並提取重點

  • 法律與技術文件分析：例如契約、政策、技術手冊

  • 客服知識庫建置：協助回應顧客常見問題

  • 教育應用：建立互動式學習助手、解說教材內容

🛠️ 快速上手


📄 安裝教學參考：README.md:45-51


只需數行程式碼即可：

from quivr_core import Brain  
from uuid import uuid4  
  
brain = Brain.from_files(  
    name="Research Papers",  
    file_paths=["paper1.pdf", "paper2.pdf", "notes.md"],  
)  
  
run_id = uuid4()  
answer = brain.ask(  
    run_id=run_id,  
    question="這些論文的關鍵發現有哪些？",  
)  
  
print(answer.answer)

🧾 功能總結

功能

說明

完整的 RAG 流程支援

開箱即用，無需手動串接檢索與生成模組

多 LLM 支援

可依需求切換使用不同語言模型供應商

文件格式多元

支援 PDF、TXT、Markdown 及自定義格式

自訂工作流程

YAML 組合節點，自由設計處理步驟

串流式回應（Streaming）

適合即時互動應用與聊天機器人

可整合外部工具與 API

如網路搜尋、Megaparse 解析器等

📌 備註

  • 官方文件中曾提及 Demo 影片，但目前版本的 README 內被註解掉

  • 從 commit 記錄可看出開發仍持續進行，功能與穩定性持續提升中


根據其原始碼與架構設計，Quivr 是一套以生成式 AI 驅動的「第二大腦」系統，旨在成為個人的知識助手。以下是最常見與實用的應用情境，涵蓋個人與專業領域。

1️⃣ 個人知識管理（Personal Knowledge Management）


Quivr 最核心的用途就是成為個人的知識庫，也就是你的「第二大腦」：

  • 儲存並組織個人文件

  • 使用自然語言查詢筆記與資料

  • 根據你自己的內容產生 AI 回答

    📄來源：README.md:11


這是 Quivr 的設計起點，也是最普遍的使用方式。

2️⃣ 文件處理與分析（Document Processing and Analysis）


Quivr 能有效處理多種文件格式並建立可搜尋的內容庫：

  • PDF 文件

  • 純文字檔案（TXT）

  • Markdown 筆記

  • 自定義格式（可自寫 Parser 支援）

    📄來源：README.md:17


對於研究人員、學生、專業人士來說，這是一個強大的知識整理與萃取工具。

3️⃣ 多模型整合（Multi-LLM Integration）


Quivr 支援多家語言模型供應商，提供彈性與可擴展性：

  • OpenAI（GPT）

  • Anthropic（Claude）

  • Mistral

  • Google Gemma

    📄來源：README.md:16


你可以根據預算、表現與語言支援選擇最合適的模型。

4️⃣ 自定義 RAG 工作流程（Custom RAG Workflows）


你可以針對不同應用場景設計工作流程，實現更細緻的控制，例如：

  • 學術研究助理

  • 法律文件分析

  • 醫學文獻整理

  • 技術文件檢索與比對

5️⃣ 多語言內容處理（Multilingual Content Processing）


Quivr 內建語言自動識別與多語重排序模型的支援：

  • 適合處理跨語言資料集

  • 提升國際化研究與多語內容的搜尋效率


適合全球業務情報、跨國研究機構等應用場景。

6️⃣ 互動式聊天應用（Interactive Chat Applications）


透過串流式回應（streaming responses），Quivr 非常適合建立即時對話應用：

📄來源：quivr_rag.py:220-245


可用於：

  • 客服聊天機器人

  • 學習助手

  • 即時研究查詢助理

7️⃣ 結合網路搜尋（Enhanced Web Search with Context）


你可以將 Quivr 擴展為具備網路搜尋能力的工具：

📄來源：README.md:18


應用場景包括：

  • 結合個人知識與最新網路資訊

  • 進行即時事實查核

  • 補充外部資料來源以強化答案

8️⃣ 文件導向應用（Document-Centric Applications）


透過「完整文件語境檢索」，Quivr 特別適合用於需保留文脈的應用：

  • 合約條文分析

  • 政策文件解讀

  • 技術手冊導航

9️⃣ 教育應用（Educational Applications）


Quivr 的 Brain 類別支援多種學習情境：

📄來源：brain.py:87-100


應用實例：

  • 學習助理

  • 課程資料查詢

  • 製作學習素材

🔟 開發者工具整合（Developer Tool Integration）


模組化架構讓 Quivr 可輕鬆整合進開發者工作流程：

📄來源：brain.py:356-358


可應用於：

  • 程式碼文件搜尋

  • API 文件查詢

  • 技術知識管理平台

🧪 實作範例：個人知識管理


以下是如何使用 Quivr 建立個人文件庫並查詢：

from quivr_core import Brain  
from uuid import uuid4  
  
# 建立你的「大腦」並加入文件
brain = Brain.from_files(  
    name="Research Papers",  
    file_paths=["paper1.pdf", "paper2.pdf", "notes.md"],  
)  
  
# 提問：統整這些文件的重點發現
run_id = uuid4()  
answer = brain.ask(  
    run_id=run_id,  
    question="這些論文的關鍵發現有哪些？",  
    retrieval_config=None  # 使用預設設定  
)  
  
print(answer.answer)

📌 備註

  • Quivr 架構高度彈性，能擴展到多種專業領域

  • 透過模組化設計，可自訂 RAG 流程、模型與排序器

  • 支援多 LLM + 多語言 + 多格式文件 = 適用範圍廣泛



🧠 Quivr 如何建立知識庫


根據原始碼來看，需要特別注意的是：Quivr 並不是建立傳統那種具有明確實體關聯的「知識圖譜（Knowledge Graph）」。它所建構的，其實是一種基於向量的知識庫（Vector-Based Knowledge Base），運用的是 RAG（檢索增強生成）技術。


以下是 Quivr 建立知識庫的方式說明：

🔧 Quivr 知識庫的核心組件


Quivr 的核心運作元件是 Brain 類別，負責整個知識庫的構建流程。

📄 參考程式碼位置：brain.py:87-100


建立知識庫的流程包含以下幾個關鍵步驟：

1️⃣ 文件匯入與儲存


當你使用文件建立一個 Brain 實例時，Quivr 首先會將這些文件儲存在所選的儲存系統中。

📄 參考：brain.py:339-345


這部分的程式碼負責將檔案上傳與初始化儲存作業。

2️⃣ 文件處理與切分


文件儲存後，Quivr 會進行以下處理動作：

  • 提取文件中的文字內容

  • 將文件拆分為可管理的「段落區塊（chunk）」

  • 為每個區塊附加相關的中繼資料（metadata）


這些處理動作由 process_files 函式執行：

📄 brain.py:46-84


對純文字檔，Quivr 使用遞迴式字元切分演算法來處理。

3️⃣ 向量嵌入生成


當文件被處理並切分後，Quivr 會將每個段落轉換為向量嵌入（vector embedding），預設使用 OpenAI 的嵌入模型。

📄 參考：brain.py:334-335

4️⃣ 建立向量資料庫


這些嵌入向量會被儲存在向量資料庫中（預設為 FAISS），用以支援後續的語意相似度檢索。

📄 參考：brain.py:356-358


此向量資料庫就是 Quivr 知識庫的核心，能根據語意相似度找出最相關的資訊。

🔍 檢索流程（Retrieval Process）


當你對知識庫提出查詢時，Quivr 會：

  1. 使用向量相似度搜尋找出相關段落

    📄 brain.py:481-483

  2. 使用重排序演算法（如 Cohere 或 Jina）提升檢索結果的準確性

    📄 quivr_rag_langgraph.py:648-650

🔁 RAG 工作流程（RAG Workflow）


整體 RAG 流程由 LangGraph 所建構的有向圖（Directed Graph）實作而成：

📄 quivr_rag_langgraph.py:254-275


這樣的圖形式工作流程允許彈性設定處理步驟，如：

  • 對話歷史過濾

  • 查詢改寫

  • 文件檢索

  • 回答生成


其中檢索步驟是連結向量知識庫的關鍵：

📄 quivr_rag_langgraph.py:617-626

🔄 動態檢索（Dynamic Retrieval）


Quivr 也支援「動態檢索」，可根據查詢需求自動調整檢索區塊的數量，特別適合處理複雜問題。

📄 quivr_rag_langgraph.py:675-684

🧾 總結：Quivr 知識庫的建立流程

步驟

說明

文件匯入

將檔案上傳至儲存系統

文件處理

提取內容並切分為段落區塊

向量嵌入

每個區塊轉為向量表示

建立索引

向量嵌入儲存在向量資料庫中（如 FAISS）

向量檢索

查詢時根據語意找出相關段落

重排序

使用排序模型提升結果品質

回答生成

基於檢索內容由 LLM 產生回答

🧠 備註

  • Quivr 並非建構明確實體關係的知識圖譜，而是基於語意相似度的「向量化知識庫」

  • 架構採模組化設計，可自由替換：

    • 嵌入模型（如換成 Hugging Face）

    • 向量資料庫（如換成 Weaviate、Pinecone）

  • RAG 工作流程亦可針對不同應用情境自訂修改


🔍 Quivr 與主流知識圖譜系統的比較


首先需說明的是：Quivr 並非傳統意義上的知識圖譜系統，而是一種基於向量技術的知識庫，採用 RAG（Retrieval Augmented Generation，檢索增強生成） 方法來進行語意檢索與回答生成。

🧠 Quivr 如何建立知識表示（Knowledge Representation）


Quivr 的知識表示核心由 Brain 類別負責實作：

📄 參考程式碼：brain.py:87-100


主要流程如下：

  1. 文件匯入：使用者將文件上傳到指定儲存系統

  2. 文件處理：提取內容並切分成段落（chunks）

  3. 向量嵌入：每個段落轉換為向量表示（embedding）

  4. 儲存向量：使用 FAISS 建立向量資料庫（預設）

  5. 語意檢索：透過向量相似度搜尋找出相關段落

📊 Quivr 與傳統知識圖譜系統比較


以下為 Quivr 與幾個主流圖譜系統（Neo4j、Amazon Neptune、Stardog、GraphDB、AnzoGraph）的特性對照表：

1️⃣ 

Neo4j

特性

Quivr

Neo4j

資料模型

向量嵌入

屬性標記圖（Labeled Graph）

關係表達

隱性（語意相似度）

顯性（型別化關係）

查詢語言

自然語言

Cypher

實體辨識

倚賴語言模型（LLM）

預先定義的 schema

可擴展性

向量資料庫受限

高度可擴展

AI 整合

原生整合 LLM

需外掛模組整合

2️⃣ 

Amazon Neptune

特性

Quivr

Amazon Neptune

資料模型

向量嵌入

RDF 或屬性圖

查詢語言

自然語言

SPARQL 或 Gremlin

主機環境

自行部署

全託管雲端服務

可擴展性

中等（視向量庫而定）

企業等級

AI 整合

內建 RAG 功能

AI 功能需另建模

成本

開源免費

按用量計費

3️⃣ 

Stardog

特性

Quivr

Stardog

資料模型

向量嵌入

RDF 圖模型

推理機制

基於 LLM

邏輯推理引擎

查詢語言

自然語言

SPARQL

知識表達

隱性語意

顯性本體（Ontology）

企業功能

限制較多

完善的企業等級功能

向量處理

核心功能

附加功能

4️⃣ 

GraphDB

特性

Quivr

GraphDB

資料模型

向量嵌入

RDF 三元組資料庫

標準支援

無明確標準

支援 RDF、OWL、SPARQL

推理能力

語言模型推理

規則式與語意推理引擎

資料視覺化

基礎（需自建）

內建圖譜視覺化工具

實體連結

隱性連結

明確關聯

文本處理

文件切段

NLP 與資訊擷取流程

5️⃣ 

AnzoGraph

特性

Quivr

AnzoGraph

資料模型

向量嵌入

RDF 與屬性圖混合模型

效能架構

單節點向量庫

分散式 MPP 架構

圖分析能力

基礎

進階圖形分析

擴展能力

中等

企業等級大規模

查詢語言

自然語言

SPARQL、Cypher

AI 整合

內建 LLM 支援

額外模組整合

🔍 核心差異分析


1. 關係建模方式：

隱性 vs 顯性

  • 傳統圖譜系統（如 Neo4j、Stardog） 使用節點與邊明確建模資料間的結構化關係。

  • Quivr 則依賴向量空間中的語意相似性，關係為隱性推斷。

    📄 參考：brain.py:481-483

2. 查詢方式：

自然語言 vs 結構語言

  • 圖譜系統 使用結構化語言如 SPARQL、Cypher。

  • Quivr 使用自然語言查詢，經由 RAG 流程解析並回應。

    📄 參考：quivr_rag_langgraph.py:254-275

3. 架構需求：

無結構 vs 嚴謹 Schema

  • 傳統圖譜需定義資料 Schema 與實體類型。

  • Quivr 屬於「無結構」架構，不需預設實體結構。

    📄 參考：brain.py:46-84

4. 推理能力：

語言模型 vs 邏輯推理

  • 知識圖譜 仰賴邏輯規則進行本體推理。

  • Quivr 則使用 LLM 進行語意推理與上下文理解。

    📄 參考：quivr_rag_langgraph.py:617-626

🧭 選擇建議：Quivr vs 傳統知識圖譜


✅ 適合選用 Quivr 的情境：

  • 不需建立明確的關聯圖結構

  • 希望快速上手、無需定義 Schema

  • 主要以自然語言查詢為主

  • 希望直接與語言模型整合

  • 資料來源為文件或筆記，重點在問答與摘要功能


✅ 適合選用傳統圖譜的情境：

  • 資料結構複雜、關係明確

  • 需要邏輯推理與規則處理

  • 須支援標準查詢語言（SPARQL、Cypher）

  • 有企業級效能與資料治理需求

  • 希望進行大規模圖形分析與視覺化

📌 總結

分類

Quivr

傳統知識圖譜系統

知識表示方式

向量語意嵌入

顯性實體與關係

查詢方式

自然語言 → RAG

結構化語言（SPARQL、Cypher）

推理方式

語言模型推論

規則引擎、本體推理

架構彈性

無結構（免定義 Schema）

須明確定義資料架構

適用場景

文件問答、知識摘要、語意檢索

複雜資料建模、圖形推理、企業治理

AI 整合

原生支援（LLM）

需額外整合

📌 備註：

  • Quivr 的設計更貼近現代 AI 驅動的知識系統趨勢

  • 傳統知識圖譜則更適合需要嚴謹資料結構與推理邏輯的場景

  • 越來越多「混合型架構」正在出現，結合向量嵌入與圖形關係建模

當我們比較「向量技術的知識庫」（Vector-Based Knowledge Base）與「知識圖譜」（Knowledge Graph, KG）時，其差異主要體現在資料結構、查詢方式、推理方式與應用場景上。以下為完整對照：

🧠 向量知識庫 vs. 知識圖譜：全面比較

項目

向量技術的知識庫（如 Quivr）

傳統知識圖譜（如 Neo4j、Stardog）

📦 資料結構

向量嵌入（embeddings）

實體 + 關係 + 屬性（節點與邊）

🔍 查詢方式

自然語言查詢 → RAG

結構化語言查詢（SPARQL、Cypher）

🤔 關係建模

隱含語意關聯（語義相似度）

顯性語義關係（明確定義邏輯連結）

🧠 推理方式

LLM 語意推理（上下文理解）

規則式推理 / 本體論推理引擎

🏗️ 架構需求

Schema-free，無需預建結構

Schema-driven，需定義本體與關係

📚 知識表達方式

語意向量空間中的上下文表示

節點（實體）與邊（關係）構成的結構化表示

🔄 資料更新

文件更新後需重新嵌入向量

即時更新關係與屬性即可

📈 可擴展性

向量資料庫受限於記憶體與檢索效能

圖形資料庫可水平擴展、大規模佈署

🔧 AI 整合

原生支援 LLM（如 GPT、Claude）

需額外模組整合 AI 功能

💬 回答風格

生成式回應（摘要式、自由文字）

精準查詢回傳結構化結果

🎯 適合應用場景

非結構化文件檢索、問答系統、知識摘要、個人筆記助理等

複雜資料模型、法規、供應鏈、生醫圖譜、推薦系統等應用

🧩 結論建議


✅ 適合使用向量知識庫（如 Quivr）當你：

  • 想快速上手建立個人或文件型知識系統

  • 主要資料是文字、筆記、PDF、教學內容等

  • 查詢方式偏好自然語言

  • 希望與 LLM 緊密結合（如 GPT 生成回應）

  • 不需要手動建構實體與關係模型


✅ 適合使用知識圖譜當你：

  • 擁有結構化資料，關係複雜（例如人、事件、產品間關係）

  • 需要可解釋推理邏輯、問責性與知識溯源

  • 想透過圖譜分析做複雜的查詢與視覺化

  • 要支援標準語言查詢、規則、推論與驗證

📚 圖書館使用的 Linked Data（連結資料） 明確屬於 傳統知識圖譜（Knowledge Graph） 的範疇，特別是採用了語意網技術（Semantic Web）和W3C 標準。

🧠 為什麼圖書館的 Linked Data 是知識圖譜類型？


以下是幾個關鍵特徵：

特徵

圖書館 Linked Data 描述

對應類型

📦 資料模型

使用 RDF（Resource Description Framework） 三元組模型（主詞-謂詞-賓詞）

✅ 傳統知識圖譜

🧩 架構設計

基於 明確定義的本體（Ontology），如 BIBFRAME、Dublin Core、SKOS

✅ 知識圖譜

🔗 關係表達

顯性語意關係（例如：「書籍」由「作者」創作）

✅ 知識圖譜

🧠 推理能力

可支援推理（Reasoning）與分類，透過 OWL、RDFS 等邏輯推論

✅ 知識圖譜

🌐 資料連結

與其他機構（如 VIAF、Wikidata）交叉連結形成「網狀資料宇宙」

✅ 知識圖譜

🔍 查詢語言

使用標準語言 SPARQL 進行查詢

✅ 知識圖譜

🔗 常見圖書館 Linked Data 標準與實作

  • BIBFRAME：取代 MARC 格式的 RDF 模型，由美國國會圖書館推動

  • Dublin Core：描述資源的核心元素標準（標題、作者、主題等）

  • SKOS：用於表述分類系統、詞彙表（如主題標籤、分類號）

  • VIAF、ISNI：用於人名、機構名的實體標識碼，支援跨機構連結

✅ 結論


圖書館所用的 Linked Data 完全屬於「知識圖譜」類型，其特徵包括：

  • 使用語意標準（RDF, OWL, SPARQL）

  • 本體導向資料建模

  • 高度結構化與可互操作性

  • 適用於大規模查詢、共享與連結知識

📚 

Linked Data 更適合「權威資料」的原因


Linked Data（語意網技術下的知識圖譜）非常適合處理：


✅ 

穩定性高、邏輯結構明確、需標準化的資料

，如：

  • 圖書館目錄（書名、作者、ISBN、主題分類）

  • 法規條文與其解釋關係

  • 地名、歷史事件、專有名詞（如 VIAF、ISNI）

  • 學術本體（如醫學術語、教育分類）


原因：

  • 📐 需嚴格結構化（有 schema、本體）

  • 🧠 需邏輯推論與問責性（可驗證關係是否正確）

  • 🔗 要與其他機構資料互連（如 Wikidata、DBpedia）

  • 🏛️ 通常是權威資料庫，變動不頻繁

⚡ 

向量知識庫更適合「快速變動、非結構化資訊」的原因


Vector-based Knowledge Base（例如使用 RAG 的 Quivr）適合處理：


✅ 

內容快速產生、難以結構化或動態變化的資訊

，如：

  • 最新新聞、技術趨勢文章

  • 使用者筆記、討論紀錄、支援票據（Helpdesk logs）

  • 學習筆記、研究文件、個人知識管理

  • 公司內部報告、簡報、PDF 彙整


原因：

  • 📄 資料是非結構化或半結構化的自然語言

  • ⏱️ 內容更新頻繁，不適合建模型

  • 🧠 查詢方式是語意驅動的問答、摘要、推理

  • 🚀 建置與應用速度快，支援 LLM 整合

🧭 總結比較

特性

Linked Data / 知識圖譜

向量知識庫（Vector KB / RAG）

資料性質

權威性高、穩定、可結構化

快速變動、非結構化、動態生成

架構需求

本體、schema、RDF/SPARQL

無 schema，自然語言為主

資料來源

MARC、規範表、詞彙表、官方資料

PDF、筆記、聊天記錄、報告等

更新頻率

低、可控

高、即時

推理方式

本體論 + 邏輯規則

語言模型（LLM）語意推理

建置與維護成本

高（需建模）

低（只需上傳文件）

適合應用

知識標準化、資料互通、圖譜查詢

文件問答、研究支援、快速整理資訊

✅ 結論：

  • 若你要處理「標準化、可引用、具邏輯關係」的穩定資訊（如圖書分類、人物身份、法律編碼），→ Linked Data 是最佳選擇。

  • 若你要處理「即時收集、語意搜尋、知識萃取」的筆記或文檔，→ 向量知識庫與 RAG 更靈活實用。


🧩 Quivr 所依賴的元件與套件組成


根據 Quivr 的原始碼與設定檔內容，可以將其外部依賴與核心元件分為以下幾大類：

1️⃣ 核心語言與開發框架


Quivr 是以 Python（版本 3.11 或以上） 開發，並使用多個核心函式庫：

  • Pydantic：用於資料驗證與設定管理（pyproject.toml:6-7）

  • Rich：提供美觀的終端機輸出格式（pyproject.toml:12）

2️⃣ LangChain 生態系統依賴


Quivr 的 RAG 系統高度依賴 LangChain 生態系統，作為其語言模型應用框架：

  • LangChain Core：構建 LLM 應用的基礎核心（pyproject.toml:8）

  • LangChain：主程式庫（pyproject.toml:9）

  • LangGraph：用於實作具狀態與流程控制的多步驟對話工作流（pyproject.toml:10）

  • LangChain Community：社群開發的擴充模組（pyproject.toml:17）

3️⃣ LLM 提供者整合模組


Quivr 支援多家語言模型供應商，並透過 LangChain 套件整合：

  • OpenAI 模型整合（pyproject.toml:15）

  • Anthropic（Claude） 模型整合（pyproject.toml:18）

  • Cohere 模型整合（pyproject.toml:16）

  • MistralAI 模型整合（pyproject.toml:25）

4️⃣ 向量資料庫與嵌入模型


文件向量化與相似度檢索的依賴：

  • FAISS（Facebook AI Similarity Search）：高效的向量檢索工具（pyproject.toml:21）

  • Tiktoken：OpenAI 提供的分詞工具，用於切段與 Token 控制（pyproject.toml:13）

5️⃣ 文件處理相關工具


Quivr 能處理多種文件格式，依賴以下模組：

  • Transformers + SentencePiece：用於嵌入與自然語言處理（pyproject.toml:20）

  • FastText-LangDetect：用於自動語言偵測（pyproject.toml:26）

  • MegaParse SDK：文件解析與預處理（pyproject.toml:24）

6️⃣ 實用輔助套件


這些工具用於輔助 Quivr 的基本操作：

  • HTTPX：非同步 HTTP 請求（pyproject.toml:11）

  • AIOFiles：非同步檔案處理（pyproject.toml:14）

  • RapidFuzz：模糊字串比對（pyproject.toml:22）

  • MarkupSafe：安全處理 HTML/文字（pyproject.toml:23）

7️⃣ 監控與可觀測性（Observability）

  • Langfuse：提供語言模型使用追蹤、效能監控與記錄分析（pyproject.toml:27）

8️⃣ 間接依賴（Transitive Dependencies）


根據 lock 檔案，Quivr 間接使用以下重要函式庫：

  • Cohere SDK：用於重排序（requirements.lock:41-42）

  • SQLAlchemy：資料庫操作 ORM（requirements.lock:265-267）

  • Pandas：資料處理工具，間接由其他模組依賴（推測自 tzdata 需求）

9️⃣ 工作流程設定檔（Workflow Configuration）


Quivr 使用 YAML 檔案來定義 RAG 工作流程（如：talk_to_file_rag_config_workflow.yaml）：


可設定內容包括：

  • LLM 參數（模型、溫度、Token 限制）

  • 重排序器設定（模型名稱、返回 top_n）

  • 節點流程邏輯與連接方式

🔟 開發與測試相關依賴


開發者可使用以下工具進行型別檢查、測試與程式碼風格檢查：

  • MyPy：靜態型別檢查（pyproject.toml:39）

  • Pre-commit：Git Hook 管理工具（pyproject.toml:40）

  • Pytest：單元測試框架（pyproject.toml:46）

  • Ruff：快速的 Lint 工具（pyproject.toml:42）

🧠 架構核心組件說明（Component Architecture）


Quivr 架構模組化、職責清晰，各元件間協同運作如下：

組件名稱

說明

Brain

主要協調模組，管理文件儲存、嵌入生成與檢索流程

QuivrQARAGLangGraph

利用 LangGraph 建立的 RAG 流程控制與推理引擎

LLMEndpoint

統一介面，整合各家 LLM 模型供應商

Vector Storage

儲存向量嵌入，支援檢索與比對

整體工作流程包含：

  • 查詢歷史過濾

  • 查詢改寫

  • 文件向量檢索

  • 回答生成與串流輸出

📄 文件處理流程（Document Processing Pipeline）


Quivr 使用 LangChain 的各種 Loader 來載入並解析不同格式文件，例如：PDF、Markdown、TXT 等。

📄 相關程式碼位置：default.py:4-18

📝 備註

  • Quivr 採模組化設計，方便替換各元件（如：更換 LLM、向量庫、排序器）

  • 系統設計具高度擴充性，支援自定義文件處理器與工具整合

  • 其核心功能建構於 LangChain 生態系統之上，因此依賴眾多語言處理相關模組


💡 Quivr 使用的演算法說明


根據 Quivr 的原始碼架構，我們可以了解其所採用的多種演算法，這些演算法涵蓋了從文件處理、檢索、重排序到答案生成等 Retrieval Augmented Generation（RAG，檢索增強生成）工作流程的各個環節。

1️⃣ 文件處理與切分演算法


🔹 遞迴式字元切分（Recursive Character Splitting）

  • 對於純文字文件，Quivr 採用遞迴式字元切分演算法，將文件拆分為可管理的區塊，並維持一定重疊。

  • 功能：

    • 控制每段文字的大小

    • 維持段落間的語境連貫性

    • 遞迴處理整份文件直到完成


🔹 Tiktoken 分段

  • 對於較複雜文件，則使用 OpenAI 的 Tiktoken 分詞器，按語意分段。

  • 優點：

    • 與 LLM 使用相同的分詞規則

    • 保證每段不超過 token 限制

    • 保持語意一致性

2️⃣ 向量嵌入與相似度檢索


🔹 向量嵌入（Vector Embedding）

  • Quivr 預設使用 OpenAI 的嵌入模型，將文本轉換成向量表示，以利後續檢索。


🔹 向量相似度搜尋（Vector Similarity Search）

  • 使用 Facebook AI 所開發的 FAISS 工具執行相似度搜尋。

  • 演算法特點：

    • 計算使用者查詢與文件向量的相似度

    • 回傳前 K 個最相似的結果

    • 可根據文件 metadata 加以篩選

3️⃣ 結果重排序演算法（Reranking）


🔹 兩種支援模型：

  • Cohere Rerank：使用 Cohere 提供的重排序模型

  • Jina Rerank：使用 Jina AI 提供的模型作為替代

  • 重排序流程會結合 contextual compression retriever，以提昇檢索品質與語境相符度。

4️⃣ RAG 工作流程演算法


🔹 LangGraph 工作流程引擎

  • Quivr 採用 LangGraph 架構建立工作流程圖（有向圖）來進行 RAG 流程控制。

  • 優點：

    • 彈性的步驟組合與控制流程

    • 支援條件分支與外部工具整合


🔹 查詢改寫與歷史過濾

  • 包含查詢重寫與對話歷史過濾演算法，用以提升語意檢索準確性。


🔹 語境壓縮的文件檢索

  • 工作流程中將：

    1. 查詢向量比對初步候選資料

    2. 套用重排序

    3. 根據相似度與語境壓縮結果過濾最終答案來源

5️⃣ 答案生成演算法（Answer Generation）


🔹 提示工程（Prompt Engineering）

  • 為 LLM 設計精緻提示，以引導產出高品質答案。


🔹 串流式回答生成（Streaming Response Generation）

  • 為即時聊天回應設計的串流演算法。

  • 功能：

    • LLM 回傳時逐塊處理

    • 即時解析與格式化

    • 回傳格式化的回應段落與 metadata

6️⃣ 語言辨識（Language Detection）

  • 透過語言偵測演算法自動判斷輸入文件語言，以決定後續處理方式。

7️⃣ 設定與客製化能力

  • 所有上述演算法均可透過設定檔（如 rag_config.yaml）進行客製化，包括：

    • 分段大小與重疊程度

    • 選用哪個 Reranker 模型

    • 使用哪個 LLM 及其參數

    • 向量搜尋的 K 值與篩選條件等

📌 重點總結：Quivr 所使用的核心演算法

類別

演算法名稱

文本切分

遞迴式字元切分、Tiktoken 分段

向量處理

向量嵌入生成、FAISS 向量相似度搜尋

結果排序

Cohere 與 Jina 重排序模型

工作流程執行

LangGraph 導向圖結構

回答生成

提示工程、串流式回答產生

語言辨識

自動偵測文件語言

使用者自定義設定

YAML 設定檔調整流程參數

這些演算法組成 Quivr 的意見導向型 RAG 系統，能有效整合文件內容，進行檢索與問答回應，是一個可擴展且靈活的 AI 知識助理核心架構。


🔧 Quivr RAG 系統中的建議演算法組合


根據 Quivr 的原始碼與設定邏輯，我們可以歸納出多種適用於不同場景的演算法組合。以下是這些組合的運作邏輯、優缺點比較，以及適用情境說明。

1️⃣ 標準 RAG 管線組合


✅ 組合一：OpenAI + FAISS + Cohere Reranker（預設組合）

  • 嵌入模型：OpenAI Embedding（default_embedder）

  • 向量資料庫：FAISS（Facebook AI 相似度搜尋）

  • 重排序器：Cohere 的 rerank-multilingual-v3.0

  • 語言模型（LLM）：OpenAI GPT 系列（預設為 gpt-3.5-turbo）


優點：

  • OpenAI 高品質嵌入模型

  • FAISS 提供快速的相似度搜尋

  • Cohere 多語言模型具優秀排序能力

  • 適用於大多數一般用途情境


缺點：

  • 嚴重依賴外部 API 服務

  • 成本偏高（因使用 OpenAI 與 Cohere）

✅ 組合二：OpenAI + FAISS + Jina Reranker

  • 與組合一類似，但重排序使用 Jina AI 模型


優點：

  • 與 Cohere 模型略有不同，對某些領域可能更合適

  • 當 Cohere 不可用時可作為替代方案


缺點：

  • 仍依賴外部服務

  • 執行表現可能依資料領域而異

2️⃣ 自定義工作流程組合


✅ 組合三：動態檢索 + 擴展語境（Dynamic Retrieval with Expanded Context）

  • 動態檢索邏輯：根據查詢複雜度自動調整檢索段數

  • 使用模型：建議 GPT-4 或其他支援長上下文的模型


優點：

  • 根據查詢內容自動擴大語境

  • 適用於需要更多背景資訊的複雜問題

  • 善用 LLM 的大輸入長度


缺點：

  • Token 使用增加，費用上升

  • 多輪檢索導致速度變慢

✅ 組合四：全文件語境的自定義工作流程（Custom Workflow with Document Context）

  • 策略：同時取得文件相關段落與完整語境資訊

  • 設定：使用低溫度 LLM（如 0.3）提高答案一致性


優點：

  • 能維持上下文連貫性，答案更完整

  • 適合結構化文檔問答需求


缺點：

  • Context token 使用量增加

  • 有機會引入部分不相關段落

3️⃣ 特殊應用場景組合


✅ 組合五：多語言處理（Multilingual Processing）

  • 額外元件：自動語言偵測演算法


優點：

  • 適合處理多語種資料

  • 能跨語言提供檢索與回答


缺點：

  • 在專業領域文件表現可能不如單語專用模型

✅ 組合六：串流回應 + 函式呼叫（Streaming + Function Calling）

  • 特色：實現即時回答的串流輸出，支援功能調用格式輸出


優點：

  • 回應即時顯示，提高互動性

  • 支援結構化輸出（如 JSON）


缺點：

  • 需使用支援 Function Calling 的 LLM

  • 實作較為複雜

📊 組合比較表

組合名稱

速度

回答品質

成本

適用情境

OpenAI + FAISS + Cohere

快速

高

高

通用場景

OpenAI + FAISS + Jina

快速

高

高

重排序替代方案

動態檢索 + 擴展語境

中等

非常高

非常高

複雜查詢

自定義工作流程（完整文件語境）

中等

高

高

保持文件語境完整性

多語言處理組合

快速

多語優秀

高

國際化、多語環境

串流回應 + 函式呼叫

快速

高

高

高互動性應用

🧪 範例：實作動態檢索組合

from quivr_core import Brain  
from quivr_core.rag.entities.config import RetrievalConfig, WorkflowConfig, NodeConfig  
  
# 建立自定義工作流程
workflow_config = WorkflowConfig(  
    name="Dynamic Retrieval",  
    nodes=[  
        NodeConfig(name="START", edges=["filter_history"]),  
        NodeConfig(name="filter_history", edges=["dynamic_retrieve"]),  
        NodeConfig(name="dynamic_retrieve", edges=["generate_rag"]),  
        NodeConfig(name="generate_rag", edges=["END"]),  
    ]  
)  
  
# 建立檢索設定
retrieval_config = RetrievalConfig(  
    workflow_config=workflow_config,  
    k=30,  # 初始檢索數量  
    reranker_config={"top_n": 10, "supplier": "cohere"},  
    llm_config={"model": "gpt-4", "max_context_tokens": 8000, "temperature": 0.3}  
)  
  
# 啟用自定義設定
brain = Brain.from_files(  
    name="My Knowledge Base",  
    file_paths=["document1.pdf", "document2.txt"],  
)  
  
answer = brain.ask("有哪些深入見解可以提供？", retrieval_config=retrieval_config)

✅ 建議使用情境

  • 一般使用者：建議從組合一開始（OpenAI + FAISS + Cohere）

  • 進階查詢/研究用途：組合三（動態擴展語境）最合適

  • 需要完整文件語境時：組合四

  • 多語使用者或國際化需求：組合五（支援語言偵測）

  • 互動式應用（如 AI 助手 UI）：組合六（支援串流與函式輸出）

🔧 註：

  • 所有組合均可依照 rag_config.yaml 調整參數

  • 效果會因資料類型與查詢複雜度而異

  • Quivr 架構彈性高，可自由替換或自建模組組合


on

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)