Kernel Memory：把檔案切塊、向量化、附引用問答的 .NET 參考實作
Research project. A Memory solution for users, teams, and applications.
秒懂
- 它是什麼？
- 微軟的 Kernel Memory 是一套示範性質的多模態索引服務，用管線把文件轉成可檢索的記憶，並以標籤做過濾與權限切分。本文說明它的資料流、啟動方式、被官方標為研究專案後的使用邊界，以及何時該改用其他方案。
- 適合誰用？
- 需要 .NET 生態內一套可讀、可改的 RAG 管線範本，或想在 Semantic Kernel、Copilot 外掛情境中快速驗證檢索品質的團隊，可以採用 Kernel Memory。要把它放進有 SLA 的生產路徑則不合適：README 開頭的警示已明言這是歸檔的研究專案、非正式支援產品、不提供支援。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 99 天前。
- 用什麼語言寫的？
- 主要是 C#（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「文件進得去、答案出得來、引用查得到」這條鏈
多數 RAG 專案卡住的不是模型，而是中間那段工程：檔案格式怎麼解析、切多大、向量存哪裡、問答時怎麼把來源一起帶回來。Kernel Memory 把這段做成可替換的管線，並在回答中附上引用與原始來源連結。README 對自己的定位寫得很直白：這是一份「best practices and a reference implementation」，程式碼「serves as a demonstration」，不是微軟正式支援的產品。
目標使用者因此分成兩類。一類是 .NET 團隊，想在自家應用裡嵌入一套語意記憶層，用 KernelMemoryBuilder 直接組裝；另一類是已經在用 Semantic Kernel、Copilot 或 ChatGPT 的人，把 KM 當外掛接上去。README 也提到它可作為 Web Service、Docker 容器、外掛與嵌入式函式庫四種形態存在，這四種形態對應的維運責任差別很大，選之前要先想清楚。
管線的四個階段，以及標籤如何變成權限邊界
README 描述預設的文件擷取管線有四個階段：自動辨識檔案格式並抽取文字、把文字切成小塊供搜尋與 RAG 提示使用、用任意 LLM 嵌入產生器算出向量、把向量寫進 Azure AI Search 或 Qdrant 這類向量索引。這條鏈是同步的順序描述，實際上每個階段都可以換實作。
真正決定這套系統能不能用在多人環境的，是標籤。匯入時可以指定 Document ID 與多組標籤，例如把 user 設成 devis@contoso.com、collection 設成 business 與 plans、fiscalYear 設成 2025。查詢時再用 MemoryFilters.ByTag("user", "devis@contoso.com") 把檢索範圍縮到單一使用者。README 把這個用法直接連到「safeguard private information」與「implement security filters」，也就是說權限過濾是掛在檢索層，靠標籤比對完成，而不是靠獨立的授權服務。這個設計的含意是：標籤寫錯或漏寫，過濾就會失效，因為沒有第二道防線。
另一個值得注意的細節是 token 用量回報。用 LLM 產生答案時，結果會附上每個服務的輸入與輸出 token 數，README 的範例輸出顯示 Azure OpenAI 的 gpt-4o 在 TextGeneration 角色下輸入 24356、輸出 103。對要估算成本的人來說，這個回報比事後從帳單反推可靠。
三種啟動路徑：Aspire、Web Service、嵌入式 Serverless
最省事的是 Docker 映像 kernelmemory/service，README 給的 .NET Aspire 範例直接把它當容器加進來，並用環境變數注入設定：KernelMemory__TextGeneratorType 設為 OpenAI、KernelMemory__DataIngestion__EmbeddingGeneratorTypes__0 設為 OpenAI、KernelMemory__Retrieval__EmbeddingGeneratorType 設為 OpenAI，金鑰放 KernelMemory__Services__OpenAI__APIKey。這組鍵名是雙底線分隔的巢狀設定，對應 JSON 裡的階層結構，改設定時要照這個格式寫。
第二種是走 Web Service。C# 端用 Microsoft.KernelMemory.WebClient 套件，new MemoryWebClient("http://127.0.0.1:9001") 指向服務位址，再呼叫 ImportDocumentAsync 匯入檔案。Python 端不需要專用 SDK，直接對 /upload 發 POST，表單欄位帶 documentId 與 tags 陣列，標籤寫成 "user:devis@contoso.com" 這種冒號分隔的字串。跨語言能用同一組 HTTP 介面，是這個形態最實際的好處。
第三種是嵌入式。KernelMemoryBuilder 搭配 WithOpenAIDefaults(Environment.GetEnvironmentVariable("OPENAI_API_KEY"))，最後 Build<MemoryServerless>()，整個索引流程跑在行程內，不經過網路。適合本機驗證與小型工具，代價是索引與問答的資源都吃在同一個行程上。
歸檔與支援狀態，是採用前最該讀懂的一行
README 最上方有一段 CAUTION，內容是：這是歸檔的研究專案，程式碼作為學習資源而非生產軟體，使用需謹慎並自行承擔風險，不提供支援。這段話的份量比其他任何技術描述都重。它意味著遇到問題時，沒有官方修補時程，也不會有相容性承諾。
版本節奏可以佐證這個判斷。近期發布集中在 0.98 系列，例如 packages-0.98.250508.3 與 packages-0.98.250324.1，版本號仍停在 0.98，沒有 1.0。對照之下，把這套東西放進需要長期演進的產品，等於接受一個不會有主版本穩定承諾的依賴。
授權是 MIT，這是寬鬆授權，允許修改與再散布，但這裡不談法律層面的解讀。實務上要留意的是：MIT 給你使用與修改的權利，並不代表有人會替你維護。若你的團隊決定繼續用，維護成本實際上由你們自己承擔，包括追蹤上游變更、自行修補缺陷，以及承擔未來 .NET 或相依套件升版時的適配工作。
什麼情況下它會是錯的工具
第一種情況是需要索引層具備強一致性的場景。管線把抽取、切塊、嵌入、寫入拆成多個階段，任何一段失敗都會留下部分完成的狀態，而 README 沒有描述補償或重試機制。若你的資料必須保證「匯入即完整可查」，這條管線的語意不夠強。
第二種是權限模型比標籤更複雜的組織。標籤過濾是在檢索時比對欄位，適合「同一份文件給同一群人」的粗略切分。如果權限來自組織架構、需要繼承或動態撤銷，用標籤硬編會很快失控，因為撤銷一份文件的存取權等於要重新處理它的所有標籤。
第三種是只想找現成託管服務、不打算碰 .NET 的團隊。Kernel Memory 的嵌入式路徑是 C# 專屬，Python 使用者只能透過 Web Service 的 HTTP 介面操作，等於多一層要自己部署與監控的服務。
還有一種容易被忽略：把它當成聊天記憶體。README 描述的是文件索引與檢索，不是對話狀態管理。這兩件事常被混為一談，但管線設計完全不同。
與 LangChain 的差異在於編排方式，不在功能清單
拿 LangChain 對照最清楚。LangChain 以 Python 為核心，把檢索、提示、代理流程寫成可組合的鏈，生態系龐大，幾乎每個向量資料庫與模型供應商都有對應整合。Kernel Memory 走的是另一條路：它把「文件匯入到可問答」這段固定成單一管線，用 .NET 的 builder 模式組裝，並把標籤過濾做進檢索介面。
差別在於彈性與約束的方向相反。LangChain 給你零件，管線怎麼接由你決定，代價是你得自己處理切塊策略、重試與狀態一致性。Kernel Memory 給你一條已經接好的線，代價是超出這條線的需求要改原始碼，而且改完之後沒有上游支援可以依靠。
如果你的團隊是 .NET 為主、需求落在標準的文件問答與過濾檢索上，Kernel Memory 的約束反而省事。如果需求會長成多代理、多工具呼叫的複雜流程，LangChain 那類可自由編排的框架更合適。兩者的選擇其實是「接受一條既定管線」與「自己組一條管線」之間的選擇。
編輯結論
需要 .NET 生態內一套可讀、可改的 RAG 管線範本，或想在 Semantic Kernel、Copilot 外掛情境中快速驗證檢索品質的團隊，可以採用 Kernel Memory。要把它放進有 SLA 的生產路徑則不合適：README 開頭的警示已明言這是歸檔的研究專案、非正式支援產品、不提供支援。動手前先確認三件事：你打算用的向量索引（Azure AI Search 或 Qdrant）是否已在程式碼中支援、標籤過濾能否對應你的權限模型、以及 0.98 系列套件版本與你鎖定的 Semantic Kernel 版本是否相容。這三項都對得上，再評估 MIT 授權下的自行維護成本。
社群筆記