完全以T-SQL打造企業級RAG應用
作者：楊先民
精誠資訊/恆逸教育訓練中心資深講師
※網路引用請註明完整出處
前言
完全以 T-SQL 打造企業級 RAG 應用：Azure SQL Database原生向量與 Azure OpenAI 整合實戰。
資料庫架構的生成式 AI 革命
隨著生成式人工智慧（Generative AI）技術在企業端迅速普及，如何讓大語言模型（LLM）精確回答企業內部的專有資料，成為資料團隊面臨的首要課題。傳統上，解決模型「幻覺（Hallucination）」或缺少最新上下文的主要手段包含兩種：模型微調（Fine-Tuning） 與 檢索增強生成（Retrieval-Augmented Generation, RAG）。
然而，微調模型成本昂貴、訓練週期長，且模型一經訓練完成其知識便固定，無法即時反映資料庫中的動態變動（如即時庫存、最新客戶評論）。因此，RAG 架構憑藉「動態檢索最新上下文並強化提示」的優勢，成為企業導入 AI 應用的首選方案。
過往建置 RAG 系統時，系統架構通常相當繁複：開發人員必須架設獨立的向量資料庫（Vector Database），並撰寫
Python 或 Node.js 等中介軟體（Middleware），處理資料同步、向量轉化、語意檢索以及
REST API 呼叫。這不僅大幅增加了運維成本，更衍生出敏感資料跨系統搬移的安全與合規疑慮。
隨著
Azure SQL 資料庫 推出原生向量支援（Vector Data Type）與外部 REST 端點整合能力，現代資料庫工程師已經可以完全在熟悉的 T-SQL 環境下，從零建置完整的 RAG
工作流程。本文將全方位解析如何在 Azure SQL 中實現資料分塊、向量內嵌生成、智慧搜尋以及端對端 RAG 管線。
一、 第一階段：設計與實作模型與向量內嵌 (Embeddings)
在 SQL 資料庫中整合 AI 功能，基礎在於如何將非結構化文字（如客戶評論、產品說明）轉換為高維度的語意向量。
1. 模型評估與核心觀念
選擇外部 AI 模型時，必須針對下列關鍵屬性進行全面評估：
· 模態與語言（Modalities & Languages）： 模型是否支援多語言或跨模態處理。
· 權杖（Tokens）： 文字會被分割為子詞單元（Tokens）。上下文視窗大小、推理能力與權杖計費成本呈現正相關，因此必須選擇合適的模型規模。
· 向量內嵌（Embeddings）： 語意意義的數學向量表示法。例如
Azure OpenAI 的
text-embedding-3-small 模型會產生 1536 維度 的高維向量。
2. 基於受控識別的安全認證配置
在企業環境中，安全永遠是第一要務。Azure SQL 建議使用 系統指派受控識別（System-Assigned Managed
Identity）
取代傳統 API Key，徹底消除將秘密金鑰寫死在資料庫的資安風險。
-- Step 1: 建立資料庫範圍憑證
(使用受控識別)
CREATE
DATABASE SCOPED CREDENTIAL
[https://<your-openai-endpoint>.openai.azure.com]
WITH
IDENTITY = 'Managed Identity',
SECRET =
'{"resourceid":"https://cognitiveservices.azure.com"}';
GO
-- Step 2: 註冊 Azure
OpenAI 外部內嵌模型
CREATE
EXTERNAL MODEL my_embedding_model
WITH (
LOCATION =
'https://<your-openai-endpoint>.openai.azure.com/openai/deployments/text-embedding-3-small/embeddings?api-version=2024-10-21',
API_FORMAT = 'Azure OpenAI',
MODEL_TYPE = EMBEDDINGS,
MODEL = 'text-embedding-3-small',
CREDENTIAL =
[https://<your-openai-endpoint>.openai.azure.com]
);
GO
資安注意事項： SECRET 中的 resourceid 為 Azure Cognitive Services 的固定 OAuth 受眾識別碼（[https://cognitiveservices.azure.com](https://cognitiveservices.azure.com)），切勿隨意改動。
3. 文字分塊（Chunking）與向量生成
若直接對萬字長文進行向量化，會導致重點語意被「稀釋」，或者超出模型的 Token 上下文限制。合理的做法是透過
AI_GENERATE_CHUNKS 將文本切割為固定長度（例如 500 字元）的區塊，再使用 AI_GENERATE_EMBEDDINGS 寫入原生的 VECTOR(1536) 欄位中：
-- 為產品評論資料表擴充向量欄位
ALTER
TABLE dbo.ProductReview
ADD
ReviewVector VECTOR(1536);
GO
-- 批次將文本轉為
1536 維度向量
UPDATE
dbo.ProductReview
SET
ReviewVector = AI_GENERATE_EMBEDDINGS(ReviewText USE MODEL my_embedding_model);
GO
4. 向量資料維護策略
隨著 OLTP 資料庫持續寫入，向量資料的同步與維護可依據業務延遲接受度採用多種架構：
二、 第二階段：設計與實作 SQL 智慧搜尋
擁有了向量欄位後，如何有效率地尋找最相關的上下文？Azure SQL 支援三種不同的搜尋機制，滿足不同的業務情境。
搜尋技術與適用場景對比
1. 全文檢索 (Full-Text Search)
基於 BM25 演算法，支援 CONTAINS 與 FREETEXT 謂詞。例如使用 FORMSOF(INFLECTIONAL) 可以讓搜尋
"ride" 的同時比對出 "riding" 或
"ridden"。
2. 向量搜尋 (Vector Search)：ENN vs. ANN
·
精確最近鄰 (Exact Nearest Neighbor,
ENN)：
使用
VECTOR_DISTANCE('cosine',
@q, Vec) 計算全表夾角餘弦距離。保證
100% 準確度，適合
資料量 < 50,000 筆 的場景。
· 近似最近鄰 (Approximate Nearest
Neighbor, ANN)： 當資料量達到十萬或百萬級別時，採用 DiskANN 圖結構索引。透過
VECTOR_SEARCH 進行快速圖尋路，能在極低延遲下保持高召回率（High
Recall）。
3. 互惠排序融合 (Reciprocal Rank Fusion, RRF) 混合搜尋
為了兼顧關鍵字精確度與語意意圖，混合搜尋會透過 FULL OUTER JOIN 併執行全文檢索與向量搜尋，並以經典的
RRF 公式計算綜合得分：
RRF 能夠平衡兩個列表的排名，使同時出現在雙邊榜單高位的資料獲得最高權重，大幅提升 Top-N 檢索的精準度。
三、 第三階段：完全以 T-SQL 實作 RAG 解決方案
在完成「向量化」與「語意檢索」後，最後一塊拼圖是將檢索到的資料封裝為 Context，並呼叫大型語言模型（如
gpt-5.4-mini）產生回答。
1. 嵌入 (Embed)：將使用者發問字串即時轉為 1536 維度向量。
呼叫 AI_GENERATE_EMBEDDINGS(@Question
USE MODEL my_embedding_model) 將使用者傳入的自然語言提問轉換為向量格式。
2. 搜尋 (Search)：檢索 Top-N 相關資料並轉換為 JSON。
透過 VECTOR_DISTANCE 比對資料庫內資料，並搭配 FOR JSON
PATH, WITHOUT_ARRAY_WRAPPER 將結果自動轉化為 Token 效率極高的 JSON 字串上下文。
3. 提示 (Prompt)：在 T-SQL 中使用 JSON_OBJECT 動態組裝系統層與用戶層 Prompt。
利用 JSON_OBJECT 與 JSON_ARRAY 函數建構符合 OpenAI API 規範的 Request Body，強制加入系統邊界指令（如：「僅能依據提供的評論回答」）。
4. 呼叫 (Call)：使用 sp_invoke_external_rest_endpoint 透過 REST API 呼叫 LLM。
透過系統預存程序發送 HTTP POST 請求給 Azure OpenAI 部署端點，實現無中介軟體的直接溝通。
5. 解析 (Parse)：使用 JSON_VALUE 解析 LLM 回傳內容並返回給前端應用。
提取回傳 JSON Payload 中的 $.result.choices[0].message.content，完成完整的 RAG 管線。
端到端 RAG 預存程序完整實現
以下為可直接於 Azure SQL Database 中執行的完整預存程序腳本：
CREATE
PROCEDURE dbo.AskProductQuestion
@Question NVARCHAR(1000),
@Answer NVARCHAR(MAX) OUTPUT
AS
BEGIN
SET NOCOUNT ON;
DECLARE @questionVector VECTOR(1536);
DECLARE @context NVARCHAR(MAX);
DECLARE @payload NVARCHAR(MAX);
DECLARE @response NVARCHAR(MAX);
DECLARE @returnValue INT;
-- 步驟 1: 嵌入 - 將使用者問題轉換為向量
SELECT @questionVector =
AI_GENERATE_EMBEDDINGS(@Question USE MODEL my_embedding_model);
-- 步驟 2: 搜尋 - 透過向量距離檢索最相關的 3 筆產品評論並轉為 JSON
SET @context = (
SELECT TOP 3
p.Name AS ProductName,
r.ReviewText,
r.Rating
FROM dbo.ProductReview r
JOIN dbo.Product p ON r.ProductID =
p.ProductID
ORDER BY VECTOR_DISTANCE('cosine',
r.ReviewVector, @questionVector)
FOR JSON PATH
);
-- 步驟 3: 提示 - 建立動態增強型
JSON 提示 Payload
SET @payload = JSON_OBJECT(
'messages': JSON_ARRAY(
JSON_OBJECT(
'role': 'system',
'content': 'You are an
Adventure Works product assistant. Answer questions using ONLY the provided
product review data. If info is missing, say so.'
),
JSON_OBJECT(
'role': 'user',
'content': 'Product Data: ' +
@context + ' Question: ' + @Question
)
),
'max_tokens': 500,
'temperature': 0.3
);
-- 步驟 4: 呼叫 - 從 T-SQL 發送 REST 請求至 Azure OpenAI
EXECUTE @returnValue =
sp_invoke_external_rest_endpoint
@url =
N'https://<your-openai-endpoint>.openai.azure.com/openai/deployments/gpt-5.4-mini/chat/completions?api-version=2024-10-21',
@method = 'POST',
@payload = @payload,
@credential =
[https://<your-openai-endpoint>.openai.azure.com],
@response = @response OUTPUT;
-- 步驟 5: 解析 - 檢驗 HTTP 回應狀態並解析最終文字答案
IF @returnValue = 0
BEGIN
SET @Answer = JSON_VALUE(@response,
'$.result.choices[0].message.content');
END
ELSE
BEGIN
SET @Answer = 'Unable to process your
question at this time. (API Error Code: ' + CAST(@returnValue AS NVARCHAR(10))
+ ')';
END
END;
GO
結語：架構演進與未來展望
透過 Azure SQL Database 的原生 AI 整合功能，企業無須重新調整現有的應用程式架構，就能在原本的資料庫層級中解鎖生成式 AI 的龐大價值。
架構轉型的核心優勢
1.
極致簡化的系統架構： 省去獨立向量資料庫（Vector
DB）與 Python/LangChain 中介服務，降低了維運複雜度與故障點。
2.
零時差的資料即時性： 當資料庫內發生 INSERT 或 UPDATE 時，透過內建機制即可完成向量更新，模型回答永遠反映最新業務狀態。
3.
企業級資安與合規性： 所有敏感資料與向量存儲均保留在 Azure SQL 的安全防護邊界內，結合受控識別（Managed Identity）認證，徹底杜絕 API Key 洩漏的隱患。
4.
熟悉的開發體驗： 資料庫管理員（DBA）與 SQL 開發人員無須重新學習昂貴的新語言，只需使用熟悉的 T-SQL 即可封裝完整的 AI 邏輯。
總結來說，Azure SQL 將向量與 RAG 能力納為原生功能，標誌著資料庫正在從傳統的「靜態儲存引擎」演進為「智慧運算中心」。這種「讓 AI 靠近資料，而非將資料搬去 AI」的新典範，無疑為企業資料團隊提供了一條最高效、最安全的 AI 落地轉型之路。
0 意見:
張貼留言