從零開始學RAG技術 | 玄貓の秘密

在建構現代AI系統時，檢索增強生成（Retrieval-Augmented Generation，RAG）已成為解決大模型語言知識有限與幻覺問題的關鍵技術。RAG結合了檢索系統與生成模型的優勢，讓AI能夠存取外部知識，並根據檢索到的資訊生成更準確的回應。

在這篇技術中，我將帶你深入探索RAG技術的核心機制、實作方法以及進階應用模式，並透過例項說明如何將RAG整合到智慧代理系統中。

RAG技術的核心：知識與記憶系統

RAG技術本質上是為AI系統建立兩種關鍵能力：

知識系統：允許AI存取並理解大量非結構化檔案
記憶系統：使AI能夠記住並利用過去的互動和資訊

這兩個系統雖然使用相似的技術基礎，但在功能和應用上有著明顯區別。讓我們先從一個簡單的RAG實作開始，瞭解其運作原理。

實作基礎RAG系統

建立一個基礎RAG系統需要幾個關鍵步驟：檔案載入、文字分塊、向量嵌入生成、向量儲存與檢索。以下是使用LangChain和ChromaDB實作的範例：

# 安裝必要套件
!pip install langchain chromadb sentence-transformers

# 引入必要的模組
from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma

# 步驟1: 載入檔案
loader = TextLoader("sample_documents/back_to_the_future.txt")
documents = loader.load()

# 步驟2: 文字分塊
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200
)
chunks = text_splitter.split_documents(documents)

# 步驟3: 生成向量嵌入
embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)

# 步驟4: 建立向量資料函式庫
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

# 步驟5: 檢索相關檔案
query = "Who made the girls cry?"
docs = vectorstore.similarity_search(query, k=3)

# 顯示檢索結果
for i, doc in enumerate(docs, 1):
    print(f"Document {i}: {doc.page_content[:50]}...")

這段程式碼展示了RAG系統的基本建置過程：

首先載入文字檔案（這裡是《回到未來》的劇本）
使用遞迴字元分割器將檔案切分成較小的區塊，設定1000字元為一塊，相鄰區塊重疊200字元
使用Hugging Face的sentence-transformers模型將文字轉換為向量嵌入
將嵌入向量儲存在ChromaDB向量資料函式庫中
最後執行相似度搜尋，找出與查詢最相關的3個檔案區塊

這個基礎實作展示了RAG的核心工作流程，但實際應用中，我們常需要更完整的系統來管理知識和記憶。

將RAG應用於智慧代理的知識系統

智慧代理的知識系統需要能夠處理各種非結構化檔案，從PDF到Word檔案，甚至是程式碼。這些檔案經過處理後，可用於問答、參考查詢和資訊增強等場景。

以下我將介紹如何使用Nexus平台（一個智慧代理開發平台）來建立和管理知識系統：

# 安裝Nexus
pip install git+https://github.com/cxbxmxcx/Nexus.git

# 執行Nexus
nexus run

# 或者以開發模式安裝
git clone https://github.com/cxbxmxcx/Nexus.git
pip install -e Nexus

這段指令用於安裝和執行Nexus平台。Nexus是一個專為開發智慧代理設計的平台，內建了完整的知識和記憶系統管理功能。安裝後，可以透過瀏覽器介面來上載檔案、建立知識函式庫、設定RAG引數，並將知識函式庫連結到智慧代理。

在Nexus平台中，知識函式倉管理的工作流程如下：

建立新的知識函式庫（Knowledge Store）
上載檔案（例如電影劇本或技術檔案）
平台會自動進行檔案切分、嵌入生成和索引建立
設定RAG引數，如切分方式、區塊大小和重疊程度
將知識函式庫連結到智慧代理，使其能夠回答相關問題

目前Nexus支援每次只能連線一個知識函式庫，但未來版本可能會支援同時選擇多個知識函式庫，並提供更多進階選項。

智慧代理的記憶系統實作

智慧代理的記憶系統與知識系統使用相似的技術，但在功能上有所不同。記憶系統主要用於儲存和檢索與使用者互動相關的資訊，例如使用者偏好、過去的對話歷史等。

在認知科學中，記憶可分為感官記憶、短期記憶和長期記憶。這種分類別也可應用於AI代理：

感官記憶：處理輸入資料（文字、影像等）的即時處理，不作長期儲存
短期/工作記憶：作為活躍的記憶緩衝區，儲存最近的對話歷史
長期記憶：儲存與代理或使用者相關的長期資訊，包括語義記憶（事實和概念）

在Nexus平台中，記憶系統的實作方式如下：

建立新的記憶函式庫（Memory Store）
增加記憶（如使用者偏好、背景資訊等）
將記憶函式庫連結到智慧代理
代理會在對話中使用這些記憶來增強回應

Nexus目前的記憶系統仍在開發中，當前實作是一個簡單的記憶儲存函式庫，允許增加記憶並在代理中使用。未來版本將支援更多功能，包括對話上下文外的長期記憶檢索。

進階RAG模式與技術

基礎RAG系統已經很有用，但在實際應用中，我們常需要更進階的技術來處理複雜查詢和提高檢索效果。以下介紹一些值得關注的進階RAG模式：

1. 假設性檔案嵌入（HyDE）

HyDE是一種使用LLM生成假設性檔案來輔助檢索的技術。當查詢複雜與難以直接比對資料函式庫中的檔案時，這種方法特別有效。

工作流程：

使用LLM根據查詢生成一個假設性檔案
使用該假設性檔案在向量資料函式庫中搜尋相似檔案
回傳最相似的檔案
使用查詢和檢索到的檔案生成回應

例如，對於查詢"星際效應的主角如何透過時間與女兒溝通？"，LLM可能會生成一個描述電影情節的假設性檔案，然後用它來檢索相關檔案。

2. 自查詢（Self-Query）

自查詢技術使用LLM將自然語言查詢轉換為結構化查詢，特別適用於需要精確過濾的場景。

工作流程：

使用LLM將自然語言查詢轉換為結構化查詢（包含過濾條件）
使用結構化查詢在向量資料函式庫中搜尋檔案
回傳符合條件的檔案
使用查詢和檢索到的檔案生成回應

例如，查詢"1980年代有哪些關於時間旅行的電影？“可能被轉換為包含年代和主題過濾條件的結構化查詢。

3. 查詢擴充套件（Query Expansion）

查詢擴充套件技術使用LLM從單一查詢生成多個查詢，用於捕捉查詢的不同方面。

工作流程：

使用LLM生成多個相關查詢
使用每個查詢在向量資料函式庫中搜尋檔案
合併所有查詢的結果，回傳最相關的檔案
使用原始查詢和

代理系統中記憶功能的核心機制

在構建人工智慧代理系統時，記憶功能扮演著至關重要的角色。記憶使代理能夠保留過去的互動經驗，從中學習並改進未來的回應。不同於簡單的查詢-回應模式，具備記憶能力的代理能夠提供連貫與個人化的互動體驗。

基本記憶檢索與增強工作流程

記憶系統的基本工作流程包含幾個關鍵步驟：

使用者輸入查詢（例如：“我應該看什麼電影？"）
查詢被轉換為嵌入向量
嵌入向量用於檢索相關記憶
檢索到的記憶與原始查詢一起送入大模型語言(LLM)
LLM生成融合了記憶內容的回應（例如：“依據你喜愛的時空旅行主題，你可能會喜歡這部電影…"）

這個流程允許代理系統在回應時考慮到之前儲存的相關訊息，使互動更加個人化與連貫。

在Nexus中實作記憶功能

Nexus平台提供了一套完整的記憶管理機制，讓開發者能夠為代理系統設定各種型別的記憶儲存。這些記憶儲存的運作方式與知識儲存類別似，但增加了建立新記憶的額外步驟。

建立與使用基本記憶儲存

在Nexus中建立記憶儲存非常直觀：

登入Nexus平台後，選擇「Memory」頁面
建立一個新的記憶儲存（例如命名為「my_memory」）
選擇一個代理引擎來處理記憶
增加一些個人事實和偏好

當訊息被輸入記憶儲存時，系統會透過LLM使用記憶函式進行處理。這個函式的目的是將對話內容轉換成與記憶型別相關的語義訊息。

記憶函式的核心在於它能夠從對話中提取有意義的訊息片段。例如，一個對話記憶函式可能會這樣工作：

Summarize the conversation and create a set of statements that summarize the conversation. 
Return a JSON object with the following keys: 'summary'. 
Each key should have a list of statements that are relevant to that category.
Return only the JSON object and nothing else.

這個函式指示LLM從對話中提取重要訊息，並將其格式化為結構化資料，便於後續儲存和檢索。

測試記憶功能

建立記憶儲存後，可以回到Nexus的聊天區域，啟用剛才建立的記憶儲存，測試代理對你的瞭解程度。這是基本記憶模式的例項，它從對話中提取事實/偏好，並將它們作為記憶儲存在向量資料函式庫中。

語義記憶與其應用

心理學家將記憶分為多種形式，取決於所記憶的訊息型別。語義記憶、情節記憶和程式記憶代表了不同型別的訊息：

情節記憶：關於事件的記憶
程式記憶：關於過程或步驟的記憶
語義記憶：代表意義，可能包括感受或情緒

語義記憶增強機制

語義記憶增強過程為記憶系統增加了一層人工智慧處理：

使用者輸入被送入語義增強函式
該函式根據特定記憶形式提取相關細節
生成與特定記憶型別相關的問題（例如：“使用者喜歡什麼型別的電影？"）
這些問題被轉換為嵌入向量並用於查詢向量資料函式庫
檢索的結果與原始輸入一起送入LLM生成回應

語義增強的價值在於它能提高記憶檢索的相關性。普通記憶系統可能只會直接檢索與輸入字面相似的記憶，而語義增強系統會先理解輸入的意圖和上下文，然後生成能夠檢索到最相關記憶的問題。

例如，當使用者問"我應該看什麼電影？“時，語義增強系統不會直接查詢與"看電影"相關的記憶，而是會生成更具體的問題如"使用者最近看過哪些時空旅行電影？“或"使用者喜歡什麼型別的電影？"，這樣能夠檢索到更加相關的記憶。

在Nexus中設定語義記憶

Nexus允許開發者建立和設定語義記憶儲存：

建立新的記憶儲存
選擇「Configuration」選項卡
將記憶型別設定為「SEMANTIC」

雖然目前Nexus不允許直接設定記憶函式、增強函式和摘要函式的具體提示，但閱讀這些函式提示可以幫助理解它們的工作方式。

語義記憶與普通記憶的比較

相同的訊息輸入到不同型別的記憶儲存中會產生不同的記憶表示。語義記憶會更注重提取資訊的意義和上下文，而不僅是字面內容。

在我實際測試中，將相同的使用者偏好訊息輸入到普通記憶和語義記憶中，結果顯示語義記憶能夠更好地捕捉使用者偏好背後的意圖和原因，而不僅是記錄表面陳述。

記憶與知識壓縮

隨著時間推移，記憶儲存可能會因為冗餘訊息和大量無關細節而變得雜亂。就像人類大腦會壓縮或總結記憶一樣，代理系統也需要記憶壓縮機制。

記憶壓縮的原理類別似於語義增強，但增加了一個預處理步驟來聚類別相關記憶：

首先使用如k-means等演算法對記憶或知識進行聚類別
然後將記憶組群傳遞給壓縮函式
壓縮函式總結並將專案收集到更簡潔的表示中

這種方法特別適用於處理大量重複或相似的記憶條目。例如，多條關於"使用者喜歡時空旅行電影"的記憶可以被壓縮為一條更全面的記憶，同時保留關鍵細節。

記憶系統的實際應用與展望

記憶和知識儲存可以顯著提升代理系統在各種應用型別中的表現。單一記憶/知識儲存可以為一個或多個代理提供服務，允許對這兩種儲存型別進行更專業化的解釋。

在實際開發中，我發現記憶系統的設計需要考慮以下幾點：

記憶粒度：太細粒度的記憶會導致儲存膨脹，太粗粒度則可能丟失重要細節
記憶優先順序：不同記憶應有不同的權重，影響檢索和使用頻率
記憶衰減：實作記憶隨時間自然衰減的機制，模擬人類記憶特性
上下文敏感檢索：確保記憶檢索對當前對話上下文敏感

隨著代理系統變得越來越複雜，記憶管理將成為關鍵的差異化因素。能夠有效利用過去經驗的代理系統將提供更加個人化、連貫與富有洞察力的互動體驗。

記憶功能不僅使代理系統更加人工智慧，也使它們更加人性化。透過有效地實作和管理記憶系統，我們可以建立真正能夠隨時間成長和適應的AI代理，為使用者提供持續改進的體驗。

人工智慧代理的記憶壓縮：從理論到實踐

在構建現代AI代理系統時，記憶與知識管理是核心挑戰之一。隨著互動歷史和知識函式庫的增長，資料量迅速膨脹，這不僅增加了儲存成本，也可能導致檢索效率下降。這就是為什麼記憶與知識壓縮技術變得如此重要。

記憶壓縮的核心機制

記憶壓縮本質上是一個資訊濃縮過程。想像你有成百上千條與使用者的對話記錄，其中許多內容可能重複或高度相似。透過壓縮技術，我們可以將這些資訊濃縮為更精簡的表示形式，同時保留關鍵語意訊息。

記憶壓縮的核心流程包括：

將記憶專案轉換為向量嵌入表示
使用降維技術處理這些向量
應用聚類別演算法（如k-means）將相似記憶分組
為每個聚類別生成摘要或代表性專案
將壓縮後的記憶專案存迴向量資料函式庫

記憶壓縮流程

這一過程使得AI系統能夠保留關鍵訊息的同時大幅減少需要處理的資料量。

k-means聚類別在記憶壓縮中的應用

k-means聚類別是記憶壓縮的核心技術之一。在實作中，系統會自動計算最佳聚類別數量，並將相似的記憶專案分組。

當我在設計記憶壓縮系統時，發現k-means的關鍵優勢在於它能夠識別出語意相似但表達不同的記憶專案。例如，使用者可能用不同方式表達對時間旅行電影的喜好：「我喜歡《回到未來》」、「時空穿越的電影很吸引我」、「昨天看了《信條》，這種扭曲時間線的故事太棒了」。理想的壓縮系統會將這些陳述識別為同一主題的變體，並生成一個精簡的表示，如「使用者喜愛時間旅行/時空穿越類別電影，包括《回到未來》和《信條》」。

Nexus平台中的記憶壓縮介面與功能

Nexus平台提供了直觀的介面來執行記憶和知識壓縮。在壓縮介面中，你可以看到以三維方式展示的記憶專案及其聚類別情況。左側表格顯示每個聚類別的大小（專案數量）。

壓縮過程需要強大的代理引擎，通常推薦使用GPT-4或更高階別的大模型語言。壓縮過程可能需要幾分鐘時間，具體取決於儲存函式庫的大小。

何時應用記憶壓縮？

在以下情況下，記憶壓縮特別有價值：

當儲存函式庫中包含大量重複或高度相似的訊息時
當聚類別大小不平衡，某些聚類別過大而其他過小時
當需要提高檢索效率，特別是在資源受限的環境中

從實際應用來看，不同型別的記憶儲存可能需要不同的壓縮策略。下面我們來探討幾種典型的壓縮應用場景。

知識壓縮的應用場景

知識壓縮的價值

知識檢索和增強也從壓縮中獲益匪淺。效果會因使用場景而異，但一般來說，來源知識越冗長，壓縮帶來的好處就越明顯。

例如，文學作品如故事和小說比程式碼基礎更能從壓縮中受益。不過，如果程式碼也非常重複，壓縮同樣能帶來顯著改善。

在處理技術檔案時，我發現那些包含大量概念解釋和背景訊息的檔案尤其適合進行知識壓縮。壓縮後，核心技術概念和關鍵實作細節會被保留，而冗長的背景說明則會被濃縮，使整體檢索效率大幅提升。

壓縮頻率的考量

記憶儲存通常會從定期壓縮中獲益，而知識儲存通常只在首次載入時進行壓縮即可。具體壓縮頻率將很大程度上取決於記憶的使用方式、頻率和數量。

對於頻繁更新的對話記憶，我建議每隔一定數量的互動（例如每100次對話）進行一次壓縮。而對於相對穩定的知識函式庫，除非有大量新內容增加，否則無需頻繁壓縮。

多次壓縮的效益

在同一時間多次進行壓縮已被證明可以改善檢索效能。其他模式還建議在不同壓縮級別使用記憶或知識。

例如，將知識儲存壓縮兩次，會產生三種不同級別的知識表示：

原始未壓縮知識（完整詳細）
一級壓縮知識（中等詳細度）
二級壓縮知識（高度濃縮）

這種多級壓縮架構使系統能夠根據查詢的複雜性和上下文需求選擇最適合的知識表示層級。對於簡單查詢，可以使用高度壓縮的知識；而對於需要深入細節的複雜查詢，則可以使用較低壓縮級別或原始知識。

高階壓縮策略與架構

知識與記憶壓縮的融合

如果一個系統專門針對特定知識源，同時也使用記憶功能，那麼可能會有進一步最佳化的空間來整合儲存函式庫。另一種方法是直接用檔案的起始知識填充記憶。

在實作中，我發現將領域知識與對話記憶融合特別有效。例如，對於客服機器人，可以將產品知識函式庫的壓縮版本與使用者互動記憶結合，使回答既包含產品專業知識，又能反映使用者的具體情況和歷史互動。

多重記憶或知識儲存的應用

在更高階的系統中，代理可能會使用與其工作流程相關的多個記憶和知識儲存。例如，代理可以使用個別記憶儲存作為與個別使用者對話的一部分，甚至可能包括與不同個人群體分享不同記憶組的能力。

這種多儲存架構使AI代理能夠維護不同型別的記憶和知識：

通用領域知識（如醫學、法律或技術知識）
特定使用者的互動歷史
特定任務或工作流程的操作記憶
組織或團隊層面的分享知識

記憶和知識檢索是代理系統的根本，透過合理的壓縮策略，我們可以顯著提升系統效能和使用者經驗。

實作練習：記憶與知識管理

以下是一些實作練習，可以幫助你深入理解和應用記憶與知識管理技術：

練習1：載入並分割不同檔案（中級）

目標：透過使用LangChain瞭解檔案分割對檢索效率的影響。

任務：

選擇一個不同的檔案（例如新聞文章、科學論文或短篇故事）
使用LangChain載入並將檔案分割成塊
分析檔案如何被分割成塊以及它如何影響檢索過程

實作示範

from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter

# 載入檔案
loader = TextLoader("path_to_your_document.txt")
documents = loader.load()

# 建立文字分割器
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    length_function=len,
)

# 分割檔案
chunks = text_splitter.split_documents(documents)

# 分析分割結果
print(f"檔案被分割為 {len(chunks)} 個塊")
for i, chunk in enumerate(chunks[:3]):  # 顯示前3個塊作為範例
    print(f"塊 {i+1} 長度: {len(chunk.page_content)} 字元")
    print(f"塊 {i+1} 內容預覽: {chunk.page_content[:100]}...\n")

這段程式碼示範瞭如何使用LangChain載入文字檔案並進行分割。TextLoader負責從檔案系統讀取文字檔案，而RecursiveCharacterTextSplitter則負責將文字分割成較小的塊。

在分割設定中，chunk_size=1000指定了每個塊的目標大小（以字元為單位），chunk_overlap=200則指定了相鄰塊之間的重疊區域大小。這種重疊設計非常重要，它能確保語意連續性，防止關鍵訊息因為剛好位於塊邊界而被分割。

最後的分析部分會顯示分割後的塊數量以及前幾個塊的基本訊息，幫助你瞭解分割的效果。在實際應用中，你可能需要調整chunk_size和chunk_overlap引數以達到最佳效果。

練習2：實驗語意搜尋（中級）

目標：透過執行語意搜尋，比較各種向量化技術的效果。

任務：

選擇一組檔案進行語意搜尋
使用Word2Vec或BERT嵌入等向量化方法替代TF-IDF
執行語意搜尋，並且使用TF-IDF獲得的結果進行比較，以瞭解差異和效果

實作示範

from langchain.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS

# 載入檔案
loader = TextLoader("path_to_your_document.txt")
documents = loader.load()

# 分割檔案
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
docs = text_splitter.split_documents(documents)

# 使用BERT嵌入
embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")

# 建立向量儲存
db = FAISS.from_documents(docs, embeddings)

# 執行語意搜尋
query = "你的搜尋查詢"
docs = db.similarity_search(query)

# 顯示結果
print(f"搜尋查詢: '{query}'")
for i, doc in enumerate(docs):
    print(f"結果 {i+1}:")
    print(f"內容: {doc.page_content[:200]}...")
    print(f"中繼資料: {doc.metadata}\n")

這段程式碼展示瞭如何使用HuggingFace的語言模型進行語意搜尋。與TF-IDF不同，這裡使用的是"sentence-transformers/all-MiniLM-L6-v2"模型來生成文字嵌入，這種根據深度學習的嵌入能夠更好地捕捉文字的語意訊息。

FAISS（Facebook AI Similarity Search）是一個高效的向量搜尋函式庫，這裡用它來儲存檔案嵌入並執行相似度搜尋。similarity_search方法會回傳與查詢語意最相似的檔案。

在實際應用中，這種根據語言模型的語意搜尋通常比傳統的TF-IDF方法表現更好，特別是在理解同義詞、上下文關係等方面。不過，它也需要更多的計算資源和更長的處理時間。

練習3：實作自定義RAG工作流程（高階）

目標：在實際環境中應用RAG理論知識，使用LangChain。

任務：

選擇一個特定應用（例如客戶服務查詢或學術研究查詢）
使用LangChain設計並實作自定義RAG工作流程
根據所選應用定製工作流程，並測試其效果

實作示範

from langchain.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

# 載入知識函式庫檔案
loader = TextLoader("path_to_your_knowledge_base.txt")
documents = loader.load()

# 分割檔案
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
texts = text_splitter.split_documents(documents)

# 建立嵌入
embeddings = OpenAIEmbeddings()

# 建立向量儲存
docsearch = Chroma.from_documents(texts, embeddings)

# 建立檢索器
retriever = docsearch.as_retriever(search_kwargs={"k": 4})

# 設定RAG鏈
qa = RetrievalQA.from_chain_type(
    llm=OpenAI(),
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 執行查詢
query = "客戶問題或研究查詢"
result = qa({"query": query})

# 顯示結果
print(f"查詢: {query}")
print(f"回答: {result['result']}")
print("\n來源檔案:")
for i, doc in enumerate(result["source_documents"]):
    print(f"檔案 {i+1}: {doc.page_content[:100]}...\n")

這段程式碼實作了一個完整的檢索增強生成（RAG）工作流程。RAG是一種結合檢索系統和生成模型的技術，能夠讓大模型語言根據外部知識生成更準確、更相關的回答。

工作流程如下：

首先載入知識函式庫檔案並分割成較小的文字塊
使用OpenAI的嵌入模型將文字塊轉換為向量表示
將這些向量儲存在Chroma向量資料函式庫中
建立一個檢索器，設定為每次檢索4個最相關的檔案
建立一個RetrievalQA鏈，它會將使用者查詢與檢索到的相關檔案結合，然後交給LLM生成回答
最後執行查詢並顯示結果，包括回答和來源檔案

這個工作流程的關鍵優勢在於它能夠根據特定的知識函式庫回答問題，而不僅依賴LLM的預訓練知識。在客戶服務場景中，這可以用來回答關於產品、政策或流程的具體問題；在研究場景中，則可以用來從大量論文或報告中提取相關訊息。

練習4：構建知識儲存並實驗分割模式（中級）

目標：瞭解不同分割模式和壓縮如何影響知識檢索。

任務：

構建知識儲存，並用幾個檔案填充它
實驗不同形式的分割/塊模式，並分析它們對檢索的影響
壓縮知識儲存，觀察對查詢效能的影響

練習5：構建和測試各種記憶儲存（高階）

目標：瞭解不同記憶儲存型別的獨特性和使用案例。

任務：

構建各種形式的記憶儲存（對話式、語意式、情景式和程式）
使用每種記憶儲存型別與代理互動，觀察差異
壓縮記憶儲存，分析對記憶檢索的影響

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。