llmware：把文件解析、向量庫與小型推論模型綁進同一條 RAG 流程

它想解決的不是模型不夠強，而是資料進不來

企業做 RAG 最常卡住的地方不在生成端。檔案散在共用磁碟上，格式混雜，pdf、pptx、docx、xlsx、txt、csv、md、json 與 jsonl 之外還包括 wav 與 png、jpg、html。每一種格式過去都要自己找解析器、自己切塊、自己想辦法把切塊寫進向量庫，然後才輪到挑模型。llmware 把這一段收斂成一個呼叫：Library().create_new_library 建立知識庫容器，接著 lib.add_files 指向一個本機資料夾，文件依副檔名被路由到對應的 parser，解析、切塊、索引一氣做完。README 明確寫出這條路徑，也寫出 add_files 是通用入口。目標讀者是那些想把整套流程留在自己機器上的人，文件反覆強調 on device、local、private、self-hosted，並列出 Windows、Mac、Linux 三種平台。

Library 是容器，不是資料庫：三層抽象怎麼接起來

llmware 的骨架由三個類別撐起。Library 是知識庫容器，文件說明它同時持有文字集合的 DB 資源與檔案資源，實際路徑落在 llmware_data/accounts/{library_name}。向量與查詢都針對 library 執行，這意味著 library 是檢索的邊界單位，不同專案開不同 library，例如 finance_q4_2023 與 hr_policies 各自獨立。第二層是 Query，用 Library().load_library 取回既有 library 後建立查詢物件，提供 text_query、semantic_query，以及可帶文件過濾條件的 text_query_with_document_filter。第三層是 Prompt，把檢索結果包成模型可讀的 context 後送出推論。ModelCatalog 則橫跨這三層，提供 list_all_models 與 load_model，讓 GGUF、OpenVINO、ONNXRuntime、HuggingFace、Sentence Transformers 與雲端 API 模型用同一個名字空間取用。這個設計的關鍵在於推論後端可替換，而檢索層的介面不變。

一個 library 掛多個 embedding，是它少見的設計選擇

多數 RAG 框架把向量庫與嵌入模型綁死。llmware 允許在同一個 library 上反覆呼叫 install_new_embedding，README 給的例子是先掛 mini-lm-sbert 配 milvus、batch_size 設 500，再掛 industry-bert-sec 配 chromadb、batch_size 設 100。查詢時若 library 上有多組嵌入，就在建立 Query 物件時指定 embedding_model_name 與 vector_db，例如 Query(lib, embedding_model_name="mini_lm_sbert", vector_db="milvus")。這種 mix-and-match 的實際用途是同一批文件用通用嵌入做廣召回、用領域嵌入做精排。代價是儲存與索引成本成倍增加，每多一組嵌入就多一份向量要維護，而文件沒有交代切換嵌入後如何處理舊向量的失效問題，這點需要自行驗證。

安裝與最小可跑範例

套件在 PyPI 上以 llmware 為名發布，文件中顯示的匯入路徑包括 from llmware.models import ModelCatalog、from llmware.prompts import Prompt、from llmware.library import Library、from llmware.retrieval import Query。支援的 Python 版本依 README 標章為 3.10 到 3.14。最小流程是四步：Library().create_new_library("my_library") 建庫，lib.add_files("/folder/path/to/my/files") 匯入，lib.install_new_embedding(embedding_model_name="mini-lm-sbert", vector_db="milvus", batch_size=500) 建索引，最後 lib = Library().load_library("my_library") 取回並用 q = Query(lib) 查詢。要接生成端就換成 prompter = Prompt().load_model("llmware/bling-tiny-llama-v0")，再呼叫 prompt_main 帶入 context。單獨測試模型則走 ModelCatalog().load_model("llmware/bling-phi-3-gguf")，用 inference 或 stream 兩種呼叫方式。

模型目錄的規模與它的真實含義

README 宣稱目錄中有 300 多個模型，其中 50 多個是 llmware 自行微調的 SLIM、Bling、Dragon 與 Industry-Bert 系列，針對企業流程自動化的特定任務。同時也支援 OpenAI、Anthropic、Google 的雲端模型。這個數字要拆開看：目錄裡混雜了量化格式的本地模型與需要 API key 的雲端模型，兩者的維運特性完全不同。真正構成差異的是那批小型專用模型，它們能在筆電或 AI PC 上跑，這是 llmware 主張「用最小算力完成任務」的物質基礎。但文件沒有提供各模型在具體任務上的準確率比較，選型時無法只靠目錄名稱判斷 bling 與 dragon 系列哪個適合你的抽取任務，這部分必須自行以實際文件測試。

什麼情況下不該用它

如果你的檢索層已經穩定運行在既有的向量資料庫上，只是想把生成模型從雲端換成本地小模型，引入 llmware 意味著連解析與切塊都要搬進它的 Library 抽象，這是不必要的遷移成本。另一個邊界是規模：文件描述的部署場景集中在單機、筆電、AI PC 與自架主機，add_files 的介面是「指向一個本機資料夾」，沒有出現分散式攝取或跨節點索引的描述。若你的語料是持續成長的串流，或需要多個寫入端並發匯入，這套設計是否撐得住，材料裡看不出答案。第三個限制是 Python 版本下限 3.10，卡在舊版直譯器的環境無法直接採用。

與 LangChain 這類通用編排框架的差別

LangChain 的定位是編排層，把不同供應商的模型、向量庫、工具用 chain 與 agent 介面黏起來，本身不預設你該用哪顆模型，也不預設部署形態。llmware 走的是相反方向：它自帶一份策展過的模型目錄，並把解析、切塊、嵌入、檢索、提示組裝全部收進同一套 API，代價是抽象層的選擇權較少。實務上的差異會出現在兩處。其一，llmware 的 install_new_embedding 讓同一個 library 掛多組嵌入並在查詢時指定，通用編排框架通常要自己寫這層路由。其二，llmware 明確針對 GGUF、OpenVINO、ONNXRuntime-QNN 這類裝置端推論後端做適配，包含 Qualcomm NPU 路徑，這是通用框架較少觸及的區塊。反過來說，若你需要接大量第三方工具或複雜的 agent 狀態機，llmware 的 Prompt 與 Query 介面就顯得單薄。

授權、版本節奏與升級成本

專案採用 Apache-2.0，允許商業使用與修改，但授權只覆蓋 llmware 這個框架本身。它目錄裡引用的第三方模型各自帶著原本的授權條款，README 也提到支援 HuggingFace 上的模型家族，這意味著你在生產環境散布的權重是否合規，取決於那些上游模型，不是 Apache-2.0 能替你解決的。版本節奏方面，近期發布為 v0.4.6（2026-04-14）、v0.4.5（2026-02-21）、v0.4.4（2026-02-11），仍處在 0.x 階段，介面在次版本之間調整的風險不能排除。升級前值得先確認 install_new_embedding 的參數與 Query 建構子的簽名是否變動，因為這兩處直接牽動已建好的索引能否沿用。

編輯結論

llmware 適合需要在筆電、AI PC 或自架環境跑完整檢索流程的團隊，尤其是文件格式雜、又不打算把原始檔送上雲端的情境；若你的檢索層已經建在既有向量資料庫上，只想換一顆生成模型，那引入整套 Library 抽象反而多一層。動手前先確認三件事：目標平台是否落在文件列出的 GGUF、OpenVINO、ONNXRuntime、ONNXRuntime-QNN、WindowsLocalFoundry 或 Pytorch 之內；lib.install_new_embedding 指定的 embedding_model_name 與 vector_db 組合是否真的能在你的機器上跑起來；以及 Apache-2.0 條款下你自行微調或再散布的模型權重，是否與上游模型原本的授權相容。

官方來源

1. License: Apache-2.0
2. llmware-ai/llmware on GitHub
3. Project website
4. README
5. Releases