向量資料庫會以向量的形式儲存和管理資料，這是資料點的數值陣列。
傳統資料庫並不適合處理日益普遍的資料分析中高維度資料。 不過，向量資料庫的設計目的是要藉由以向量表示，來處理高維度資料，例如文字、影像和音訊。 向量資料庫適用於機器學習、自然語言處理和影像辨識等工作，其目標是識別大型資料集中的模式或類似性。
本文提供向量資料庫的背景資訊，並概念性地說明如何在 Real-Time Intelligence in Microsoft Fabric 中將事件屋作為向量資料庫使用。 如需實際範例，請參閱 教學課程：使用事件屋作為使用 LLM 嵌入的向量資料庫 和 教學課程：使用事件屋作為使用 SLM 嵌入的向量資料庫。
重要概念
下列重要概念有在向量資料庫中使用：
向量相似度
向量相似性是量測兩個或多個向量的不同 (或相似) 之處。 向量相似性搜尋是用來在資料集中尋找相似向量的技術。 你可以用距離度量來比較向量，例如歐 幾里得距離 或 餘弦相似度。 兩個向量越接近就越相似。
嵌入式表示
嵌入表示是一種以向量格式表示資料的常見方式，用於向量資料庫。 嵌入是一種對資料（如單字、文字文件或圖片）的數學表示，用以捕捉其語意意義。 你透過演算法分析資料並產生一組代表關鍵特徵的數值來建立嵌入。 例如，文字的內嵌可能代表其意義、其內容，以及與其他單字的關聯性。 嵌入表示是一種以向量格式表示資料的常見方式，用於向量資料庫。 嵌入是一種對資料（如單字、文字文件或圖片）的數學表示，用以捕捉其語意意義。 你透過演算法分析資料並產生一組代表關鍵特徵的數值來建立嵌入。 例如，文字的內嵌可能代表其意義、其內容，以及與其他單字的關聯性。 Eventhouse 支援兩種直接在 KQL 中產生嵌入的方法：
ai_embeddings 外掛：呼叫外部Azure OpenAI 端點，利用大型語言模型（LLM）產生嵌入。 此方法產生最高品質的嵌入，最適合用於生產語意搜尋工作負載。
slm_embeddings_fl（）：在 Kusto Python 沙盒中本地執行小型語言模型（SLM），產生嵌入而無需外部端點。 此方法不需 Azure OpenAI 資源，且不需產生每次嵌入成本。
欲了解更多關於 Azure OpenAI 嵌入的資訊，請參閱「了解 Azure OpenAI 服務 中的嵌入」。
選擇嵌入方法
請參考下表，選擇最適合你情境的方法：
| 考慮事項 | ai_embeddings 外掛（LLM） | slm_embeddings_fl（）（SLM） |
|---|---|---|
| 模型品質 | 最高品質;使用 Azure OpenAI 模型，例如text-embedding-3-large |
品質不錯;使用開源的 SLM，如 harrier-v1-270m、 jina-v2-small、 e5-small-v2 |
| 外部依賴 | 需要一個 Azure OpenAI 資源並部署嵌入模型 | 沒有;模型在 Python 沙盒中本地執行 |
| 成本 | 根據 Azure OpenAI 使用量按要求計價 | 無每次嵌入成本 |
| Throughput | 受 Azure OpenAI 速率限制限制;需批次處理與重試邏輯 | 僅受叢集運算資源限制;自然地隨叢集大小縮放 |
| 設定 | 需要部署 Azure OpenAI 、呼叫政策設定及身份設定 | 需要已啟用 Python 外掛程式，並將 SLM 成品上傳至 Lakehouse |
| 最大上下文長度 | 視已部署的模型而定（例如，text-embedding-3-large 為 8,192 個 token） |
最多可達 32,768 個權杖（搭配 harrier-v1-270m）、8,192 個（搭配 jina-v2-small），以及 512 個（搭配 e5-small-v2） |
| 適用對象 | 生產語意搜尋，將嵌入品質視為首要任務 | 隱私敏感的工作流程、快速原型製作、大量批次嵌入，或是無法存取 Azure OpenAI 的情境 |
一般工作流程
使用向量資料庫的一般工作流程如下所示：
- 嵌入資料：利用嵌入模型將資料轉換為向量格式。
- 儲存向量：將內嵌向量儲存在向量資料庫中。 您可以將內嵌資料傳送至 Eventhouse，以儲存和管理向量。
- 內嵌查詢：使用用來內嵌預存資料的相同內嵌模型，將查詢資料轉換成向量格式。
- 查詢向量：使用向量相似度搜尋來尋找資料庫中類似查詢的專案。
Eventhouse 作為向量資料庫
向量相似性搜尋的核心在於能夠儲存、索引及查詢向量資料。 Eventhouses 提供處理和分析大量數據的解決方案，特別是在需要即時分析和探索的案例中。 此功能使 Eventhouse 成為儲存與搜尋向量的絕佳選擇。
Eventhouse 的以下元件讓你能將其用作向量資料庫：
- 動態資料類型，可儲存非結構化資料，例如數位和屬性包。 使用此資料型態來儲存向量值。 您可以將與原始物件相關的元資料儲存為資料表中的個別資料行，以進一步增強向量值。
- 這種 編碼 類型
Vector16設計用於以 16 位元精度儲存浮點數向量。 此編碼使用Bfloat16而非預設的 64 位元。 使用此編碼來儲存向量嵌入，因為它將儲存需求降低四倍，並大幅加速向量處理函數如 series_dot_product（） 和 series_cosine_similarity（）。 - series_cosine_similarity 功能，你可以用它在 Eventhouse 裡儲存的向量上進行向量相似性搜尋。
為擴展進行最佳化
欲了解更多優化向量相似性搜尋的資訊，請參閱 部落格。
為了最大化效能及搜尋時間，請遵循以下步驟：
- 將內嵌資料行的編碼設定為 Vector16，這是向量係數的 16 位編碼方式(而不是預設的 64 位)。
- 將嵌入向量表儲存在所有叢集節點上，每個處理器至少有一個分片。 要達成這個目標，請遵循以下步驟：
- 藉由改變分區化原則的 ShardEngineMaxRowCount，限制每個分區的內嵌向量數目。 此設定將資料分散到所有可用的運算資源，以加快搜尋速度。
- 變更合併原則的RowCountUpperBoundForMerge。 需要合併原則，以防止在資料引入後合併範圍。
範例優化步驟
在以下範例中，你定義了一個靜態向量表來儲存 1M 向量。 你將嵌入策略定義為 Vector16，並設定分片與合併策略以優化表格以進行向量相似度搜尋。 在此範例中，假設叢集有 20 個節點，每個節點有 16 個處理器。 資料表的分片最多應包含 1,000,000/（20*16）=3,125 列。
請依序執行以下 KQL 指令，建立空資料表並設定所需的政策與編碼：
.create table embedding_vectors(vector_id:long, vector:dynamic) // This is a sample selection of columns, you can add more columns .alter column embedding_vectors.vector policy encoding type = 'Vector16' // Store the coefficients in 16 bits instead of 64 bits accelerating calculation of dot product, suppress redundant indexing .alter-merge table embedding_vectors policy sharding '{ "ShardEngineMaxRowCount" : 3125 }' // Balanced data on all nodes and, multiple extents per node so the search can use all processors .alter-merge table embedding_vectors policy merge '{ "RowCountUpperBoundForMerge" : 3125 }' // Suppress merging extents after ingestion將資料內嵌至上一個步驟中建立和定義的資料表。