生成式AI除了常聽到文案寫作、翻譯之外，RAG 應該是另一個也很常聽見或看到的應用。RAG 是「檢索增強生成」（Retrieval-Augmented Generation）的縮寫。這個架構可以說是將「檢索」和「生成」的力量結合在一起，簡單來說，RAG 架構的運作方式是這樣的：當你給模型一個問題或輸入，RAG 首先會通過「向量搜索」技術，在一個大的知識庫(向量資料庫)中找出最相關的資料。這些相關資料就像是模型的「輔助資料」，用來幫助 LLM 更精確的生成答案。這就像是 AI 在寫考試時，還開著一堆專業書籍可以隨時查閱。

相比於單純依賴 LLM 生成內容，RAG 的最大優勢就是能夠「即時檢索」相關資訊，一方面讓生成的內容更具體、更有根據，另一方面也有效的降低模型幻覺問題。例如，當一個客戶問一個非常專業的問題時，在RAG 的架構裡可以先去查詢相關的技術文件，再根據查到的資料生成一個精準的答案，而不是讓 LLM 生成可能不夠可靠的回應。因此，RAG 架構非常適合用在需要大量外部資訊的應用中，像是QA系統、客服平台、企業知識應用，甚至是一些專業領域的資料檢索和回應。

RAG 與向量的關係是什麼

RAG 架構和向量有著密不可分的關係，因為向量是 RAG 的搜尋技術核心。當使用 RAG 來回答問題或生成內容時，第一步的「檢索」就是進行「向量檢索」。模型會先將使用者的問題或輸入轉換成向量，然後將這個向量與向量資料庫中的向量資料進行相似度的匹配，找出最相關的資料。
一個好的向量儲存在進行向量搜尋是快速有效率的，因為它能夠在龐大的資料集中進行相似度計算，找到與問題相關的資料，而這些相關資料會被結合到 Prompt 裡送到 LLM，作為輔助參考資料幫助模型生成更精確的回應。換句話說，RAG 中的向量檢索階段就像是在大腦裡快速翻閱書籍，找到可能解答問題的段落。這些「找到的段落」是以向量形式呈現的，它們幫助 LLM 提供更具體、相關性更精準的答案。因此，RAG 的強大之處就在於它能夠透過向量檢索找到關鍵資訊，再用生成模型處理並回應。

什麼是向量？

把「向量」想像成一批數字的集合，而這些數字是描述在空間中的位置，或是更抽象的說，表示某種資料關係。這些向量資料既能說明距離，也能說明方向。例如「座標」資料，它既能說明距離，也能說明方向，導航可能會這麼指引你，向前走10公里，後後往右走300公尺就到達你的目的地，而座標是一個二維向量。當然，在LLM應用裡的向量不會是簡單的二維向量，以 text-embedding-3-large 模型為例，維度可以來到3072維。而不同的模型有不同的向量維度，維度數量指的是向量中包含的數字數量，簡單來說就是向量的「長度」。這些不同的維度反映出每個模型在理解語言時的深度和細節程度。較高維度的模型能夠捕捉到更多語義上的細節與關聯，但這不代表維度越高就越好，畢竟維度越高也相對增加計算的複雜度。

你可能會想：「那向量和AI有什麼關係？」其實，向量幫助我們將複雜的資料（例如文字、圖片、聲音）轉換成可以比較的數字形式。這樣AI才能「理解」並操作這些資料。當我們處理文字的時候，向量會把字詞轉換成數字表示，這樣系統就能計算出兩個字詞或句子之間的相似性。例如，「貓」和「小貓」可能會在向量空間裡非常接近，而「貓」和「汽車」則會相距很遠。這些數字的距離告訴AI，哪兩個東西是相關的，哪兩個是完全不相干的。

embedding 跟向量的關係是什麼？

大型語言模型（LLM）中的「embedding」，是 LLM 將文字（例如字詞、句子或段落）轉換成一組數字，也就是向量，而這個過程就叫做 embedding。這些向量是對文字的數字表示，讓模型能夠理解語言的意義和結構。
想像一下，當你輸入一段文字時，LLM 就會生成一個向量，這個向量在高維空間中代表該段文字的語義。然後，LLM 就可以根據這些向量來做各種運算，比如判斷兩段文字的相似度或提取相關的資料。這個過程就像把文字翻譯成了 AI 可以「看見」的數字世界。
更有趣的是，因為 embedding 是高維向量，這些向量不僅僅是「距離」的比較，而是包含了許多微妙的語義關係，像是同義詞、相似句子結構等。這些都是靠 embedding 在背後默默運作，讓 AI 能夠「理解」我們的語言。

LLM 模型與embedding

並非所有 LLM 都是專門為embedding處理最佳化的，某些模型可能更適合某些特定任務，比如文本生成，而另一些則可能更擅長做語意相似性檢索。因此通常會選擇專用的 embedding 模型，並且還會涉及到語種，以 OpenAI 來說過去有 text-embedding-ada-002，而現在有text-embedding-3，還成有 small 及 large 版本。

另外假設已經用一個特定的 LLM 模型把大量資料轉換成向量並儲存，然後打算換用另一個不同的模型，那麼可能會遇到一些問題：

• 向量維度不一致：
  如果換的模型生成的向量維度和之前不一致，那麼新的模型無法直接與原本的向量進行比較。這樣會導致向量搜索或檢索時出現問題，因為不同維度的向量無法進行有效的相似度計算。

• 語義表達的差異：
  不同的模型對於語義的理解會有所不同，即使是相同的詞句，在不同模型中生成的向量也可能表達不同的語意。因此，即使在同一個資料集上進行檢索，新的模型生成的向量可能會與之前模型生成的結果存在較大差異，進而影響到檢索結果的精確性。

• 相似度計算可能不同：
  不同模型可能採用不同的方式來計算向量之間的相似性。例如，有的模型可能會更注重字詞的具體語義，而有的模型則可能更注重上下文關係。因此，換模型後，檢索出來的資料可能會有所不同，而進一步會影響 RAG 應用的效果。

因此，如果換用不同的模型來處理已經儲存的向量資料，一般會建議重新生成向量，這樣才能確保向量維度和語義表示的一致性，進而能保證檢索和生成內容的準確性。

Semantic Kernel 向量處理

• 部署或建立 Embedding 模型服務
  以Azure OpenAI 為例，可以建立 Embedding 模型服務。本文以 text-embedding-3 large 版本為例，建立完成後取得部署名稱以及金鑰。

• 建立 Kernel 物件，並連接服務

Kernel kernel = Kernel.CreateBuilder()
.AddAzureOpenAITextEmbeddingGeneration(
        endpoint: Config.aoai_endpoint,
        deploymentName: Config.aoai_embedding_deployment,
        apiKey: Config.aoai_apiKey)
.Build();

• 取得實作 ITextEmbeddingGenerationService 物件
  Semantic Kernel 會根據建立 Kernel 物件時所連接服務。來提供實作 ITextEmbeddingGenerationService 的物件。

 var embeddingGenerator = kernel.GetRequiredService<ITextEmbeddingGenerationService>();

• 呼叫 GenerateEmbeddingAsync
  呼叫　GenerateEmbeddingAsync　方法，進行完 Embedding 後為了觀察實際產生的向量，這裡直接將向量顯示出來。

var result = await embeddingGenerator.GenerateEmbeddingAsync("十月十日是中華民國國慶日");

float[] resultArray = result.ToArray();
foreach (var value in resultArray)
{
    Console.WriteLine(value);
}

• 結果

0.0031125182
-0.08318053
-0.00267366
0.025836376
-0.0020738868
-0.0140614705
-0.0049692267
0.042238425
0.040942106
-0.012639119
-0.026106443
-0.028411012
(以下略)

結語

本篇內容在於建構正確理解 LLM RAG以及向量概念，本篇示範使用 Semantic Kernel 進行 embedding ，相同的，你也可以自行更換 OpenAI 平台。這個示範，僅僅只是把向量轉換完成，尚未進行向量的儲存，以及完整的 RAG 實作，接下來幾天我會一一揭曉內容。