知識圖譜的多重 LoRA：一個模型，多種領域

文章資訊

作者：Alexander Shereshevsky　　日期：2026-06-13

原文標題：Multi-LoRA for Knowledge Graphs: One Model, Many Domains

Medium 原連結：https://medium.com/graph-praxis/multi-lora-for-knowledge-graphs-one-model-many-domains-b6c1f4c96953

⭐ 收藏

🔊 朗讀摘要

🔊 朗讀全文（收藏後自動生成）

---

📝 重點摘要

TL;DR

用單一基底模型搭配多個可熱插拔 LoRA 適配器，低成本解決跨領域三元組抽取。

核心問題

單一微調模型只學會一套謂詞詞彙，無法跨領域遷移（法律、醫療、金融）。在 REBEL 上微調的 Qwen3–8B 雖達 100% 結構可靠，但在領域文本上謂詞與標註慣例不符，Triple F1 崩潰。作者尋求「像一個模型般擴展、像多個模型般專精」的架構。

關鍵發現 / 數據

• 記憶體對比壓倒性：4 個獨立模型需 4×16GB=64GB，而 1 基底+4 個 LoRA 僅 17GB，省下 99.7%，單張 RTX 3090 即可運行。
• 每個 rank 64 適配器約 250MB，僅為 16GB 基底的 1.5%。
• few-shot 抽取品質最佳（Llama 3.1 達 0.732 Triple F1），但 schema 合規率僅 20%（80% 文件無法解析）。
• Punica 的 SGMV kernel 讓跨適配器批次推論達 12 倍吞吐；熱插拔近乎免費，從 CPU 載入僅 50–100ms 開銷。
• 每個適配器訓練 30–45 分鐘，4 個共 2–3 小時。

方法亮點

• 三階段管線：輕量分類器（DistilBERT/metadata/embedding，<5ms）→ vLLM 路由（--enable-lora）→ 領域抽取；信心 <70% 退回通用適配器。
• 訓練資料混比是關鍵：約 85% REBEL（教「如何抽取」）+ 15% 領域樣本（教「抽取什麼」），200–500 筆手標即可。
• 各適配器獨立訓練（非聯合），須由同一基底 checkpoint 出發才能互換；rank 64/alpha 128、QLoRA 4-bit。
• 利用 LoRA「學得少、忘得也少」的抗遺忘特性（Biderman et al. 2024）保留 JSON 生成能力。

對我的研究有用嗎？

非常實用的工程化參考：將「結構抽取」與「領域謂詞」解耦的雙層資料配方，對 GraphRAG 抽取階段的領域遷移問題直接適用。謂詞詞彙先定義、跨適配器共享實體本體的建議，對知識圖譜 schema 一致性有啟發。文末對 token-level 動態路由（LoRA-Switch、MoLoRA、LoRA Soups）的綜述也適合追蹤多領域文件的研究方向。

評語

值得一讀的實作導向文章，工程細節紮實、記憶體論證有力；但缺乏本系列承諾的領域 Triple F1 實測數字，效果宣稱多為定性，部分引用（2025–2026 論文）需自行查證。

---

🌐 中英對照

Author: Alexander Shereshevsky
Published:
Source: https://medium.com/graph-praxis/multi-lora-for-knowledge-graphs-one-model-many-domains-b6c1f4c96953
Fetched: 2026-06-13T00:50:45.477546

---

Multi-LoRA for Knowledge Graphs: One Model, Many Domains / 知識圖譜 (Knowledge Graph) 的 Multi-LoRA：一個模型，多種領域

Our extraction model speaks fluent Wikipedia. Our documents speak legal, medical, and financial. Here’s how we fixed that. / 我們的抽取模型講得一口流利的維基百科語言，但我們的文件講的卻是法律、醫療與金融的語言。以下是我們如何解決這個問題。

Press enter or click to view image in full size

按 Enter 或點擊以全尺寸檢視圖片

This is Part 3 of our series on building knowledge graphs with local LLMs. Part 1 benchmarked four open-weight models on entity-relation extraction. Part 2 fine-tuned Qwen3–8B on the REBEL dataset and achieved 100% structural reliability — but Triple F1 collapsed on domain-specific text. The diagnosis: a single fine-tuned model learns one predicate vocabulary and can’t transfer it across domains. This article is about the architectural solution.

這是我們「使用本地 LLM 建構知識圖譜」系列的第三部分。 第一部分 針對實體—關係抽取 (entity-relation extraction)，對四個開放權重 (open-weight) 模型進行了基準測試。 第二部分 在 REBEL 資料集上微調 (fine-tune) 了 Qwen3–8B，達成了 100% 的結構可靠性——但在特定領域的文本上，三元組 F1 分數 (Triple F1) 卻崩潰了。診斷結果是：單一微調模型只學會了一套謂詞詞彙 (predicate vocabulary)，無法跨領域遷移。本文要談的就是這個問題的架構性解決方案。

The Problem: One Adapter Can’t Speak Every Domain / 問題所在：一個轉接器無法說遍所有領域

In Part 2, we fine-tuned Qwen3–8B on 3,000 REBEL samples and got a model that produces perfect JSON every single time. 100% schema conformance, no parsing failures, no retries. Structurally, the problem was solved.

在第二部分，我們用 3,000 個 REBEL 樣本微調了 Qwen3–8B，得到一個每一次都能產出完美 JSON 的模型。100% 的綱要符合度 (schema conformance)、沒有解析失敗、不需要重試。從結構上來看，問題已經解決了。

But when we pointed it at our legal documents, it produced triples like (TechCorp Industries, filed a patent infringement lawsuit against, DataFlow Systems) instead of the expected (TechCorp Industries, filed_lawsuit_against, DataFlow Systems). When we evaluated it on held-out REBEL data, something even stranger happened: the model extracted entirely different — but equally valid — triples from the same text. A passage mentioning Deutsche Eislauf-Union and Germany would yield (Deutsche Eislauf-Union, organizes, competition) from the model, while REBEL's gold label was (Deutsche Eislauf-Union, country, Germany). Both correct. Neither matching.

但是當我們把它用在法律文件上時，它產出的三元組卻像是 (TechCorp Industries, filed a patent infringement lawsuit against, DataFlow Systems)，而不是預期的 (TechCorp Industries, filed_lawsuit_against, DataFlow Systems)。當我們在保留 (held-out) 的 REBEL 資料上評估它時，發生了更奇怪的事：模型從同一段文字中抽取出了完全不同——但同樣有效——的三元組。一段提到 Deutsche Eislauf-Union 與德國的文字，模型會產出 (Deutsche Eislauf-Union, organizes, competition)，而 REBEL 的黃金標籤 (gold label) 卻是 (Deutsche Eislauf-Union, country, Germany)。兩者都正確，卻都對不上。

The core issue is that a production pipeline doesn’t process one type of document. Ours handles legal filings, medical records, financial reports, and technical documentation. Each domain has its own entity types, predicate vocabularies, and extraction conventions. A legal adapter needs to output filed_lawsuit_against and Party entities. A medical adapter needs treats_condition and Drug entities. A financial adapter needs acquired_by and Instrument entities.

核心問題在於，一條生產級的流程 (pipeline) 不會只處理一種類型的文件。我們的流程要處理法律文件、病歷、財務報告與技術文件。每個領域都有自己的實體類型 (entity type)、謂詞詞彙與抽取慣例。法律轉接器 (adapter) 需要輸出 filed_lawsuit_against 謂詞與 Party 實體；醫療轉接器需要 treats_condition 與 Drug 實體；金融轉接器需要 acquired_by 與 Instrument 實體。

The naive solutions don’t work. Training one model on all domains creates predicate vocabulary conflicts — the model averages across domains and speaks none of them well. Running separate fine-tuned models per domain means 16GB × N domains in GPU memory, which scales terribly. Using few-shot prompting per domain gets the best extraction quality (Part 1 showed Llama 3.1 hitting 0.732 Triple F1 with few-shot), but at 20% schema conformance — meaning 80% of your documents produce unparseable output.

那些直覺式的解法都行不通。在所有領域上訓練單一模型會造成謂詞詞彙衝突——模型在各領域間取了平均，結果哪個領域都說不好。為每個領域各跑一個獨立的微調模型，意味著 GPU 記憶體要佔用 16GB × N 個領域，擴展性極差。為每個領域使用少樣本提示 (few-shot prompting) 能得到最佳的抽取品質（第一部分顯示 Llama 3.1 在少樣本下達到 0.732 的 Triple F1），但綱要符合度只有 20%——意味著你有 80% 的文件會產出無法解析的輸出。

We needed something that scales like one model but specializes like many.

我們需要一種「擴展起來像單一模型、但專精程度像許多模型」的東西。

The Idea: Modular Domain Adapters / 構想：模組化的領域轉接器

LoRA (Low-Rank Adaptation) fine-tuning works by freezing the base model’s weights and training a small set of adapter matrices — low-rank decompositions that modify the attention and feed-forward layers. For a Qwen3–8B model with rank 64, each adapter is roughly 250MB. The base model is 16GB. The adapter is 1.5% of the base.

LoRA（低秩適應，Low-Rank Adaptation）微調的運作方式是：凍結基礎模型 (base model) 的權重，只訓練一小組轉接器矩陣——也就是用來修改注意力層 (attention layer) 與前饋層 (feed-forward layer) 的低秩分解 (low-rank decomposition)。對於秩 (rank) 為 64 的 Qwen3–8B 模型，每個轉接器大約 250MB。基礎模型是 16GB。轉接器只佔基礎模型的 1.5%。

This asymmetry is the whole idea. Instead of N separate fine-tuned models, we keep one base model loaded and swap lightweight adapters in and out depending on the document domain. The memory math makes the case:

這種不對稱性正是整個構想的精髓。我們不再使用 N 個獨立的微調模型，而是保持一個基礎模型載入記憶體，並根據文件領域動態換入換出輕量的轉接器。記憶體帳一算就清楚了：

Four separate fine-tuned models: 4 × 16GB = 64GB. That’s three to four GPUs just for extraction. One base model plus four LoRA adapters: 16GB + 4 × 250MB = 17GB. That fits on a single RTX 3090 with room for KV cache. Same domain coverage, 99.7% less memory.

四個獨立的微調模型：4 × 16GB = 64GB。光是抽取就要用掉三到四張 GPU。一個基礎模型加上四個 LoRA 轉接器：16GB + 4 × 250MB = 17GB。這在單張 RTX 3090 上就放得下，還留有空間給 KV 快取 (KV cache)。同樣的領域涵蓋範圍，記憶體卻少了 99.7%。

But does the theory hold in practice? A key concern with domain-specific adapters is catastrophic forgetting — when specializing for legal text, does the model lose its ability to produce valid JSON or extract entities in general?

但這個理論在實務上站得住腳嗎？特定領域轉接器的一大隱憂是災難性遺忘 (catastrophic forgetting)——當模型為法律文本進行專精化時，它是否會喪失產出有效 JSON、或抽取一般實體的能力？

This is where a 2024 ICML paper, “LoRA Learns Less and Forgets Less” by Biderman et al., becomes directly relevant. They showed that LoRA and full fine-tuning sit on the same Pareto curve: LoRA learns less of the target domain but also forgets less of what the base model already knows. For multi-domain extraction, this tradeoff is exactly what we want. Each adapter specializes in its domain’s predicate vocabulary without destroying the base model’s structural JSON generation ability or general entity recognition. The forgetting resistance isn’t a limitation — it’s the enabling property.

這裡，Biderman 等人於 2024 年發表的 ICML 論文〈LoRA Learns Less and Forgets Less〉就直接派上用場了。他們證明 LoRA 與完整微調 (full fine-tuning) 落在同一條柏拉圖曲線 (Pareto curve) 上：LoRA 對目標領域學得較少，但對基礎模型既有知識也忘得較少。對於多領域抽取而言，這個取捨正是我們想要的。每個轉接器專精於自己領域的謂詞詞彙，卻不會破壞基礎模型的結構化 JSON 生成能力或一般實體辨識 (entity recognition) 能力。這種抗遺忘性並不是一種限制——它正是讓整套方法得以成立的關鍵特性。

The infrastructure to serve this has also matured. S-LoRA (Sheng et al., 2023) demonstrated serving thousands of concurrent LoRA adapters on a single GPU using unified memory paging. Punica (Chen et al., 2023) introduced the SGMV kernel that batches inference across different adapters simultaneously, achieving 12x throughput over sequential serving. vLLM adopted both of these natively. This isn’t experimental — it’s production infrastructure with battle-tested implementations.

支撐這套方案上線服務的基礎設施也已經成熟。S-LoRA（Sheng 等人，2023）展示了如何在單張 GPU 上、透過統一記憶體分頁 (unified memory paging) 同時服務數千個並行的 LoRA 轉接器。Punica（Chen 等人，2023）引入了 SGMV 核心 (kernel)，能同時對不同轉接器的推論進行批次處理 (batch)，相較於循序服務 (sequential serving) 達到 12 倍的吞吐量 (throughput)。vLLM 原生採用了這兩者。這已經不是實驗性質——而是經過實戰驗證、可用於生產環境的基礎設施。

Our Pipeline: Classify, Route, Extract / 我們的流程：分類、路由、抽取

The architecture has three stages: a lightweight classifier that determines the document’s domain, a routing layer that selects the appropriate LoRA adapter, and the extraction model itself. Each stage is independently simple. Together, they solve the multi-domain problem.

這個架構有三個階段：一個判斷文件所屬領域的輕量分類器 (classifier)、一個選擇適當 LoRA 轉接器的路由層 (routing layer)，以及抽取模型本身。每個階段單獨看都很簡單。但組合起來，它們就解決了多領域問題。

Stage 1: Document Classification / 階段一：文件分類

The routing decision — which adapter should process this document? — needs to be fast and doesn’t need to be perfect. We considered three approaches, each with different tradeoffs.

路由決策——也就是「該由哪個轉接器來處理這份文件？」——需要夠快，但不需要完美。我們考慮了三種方法，各有不同的取捨。

The simplest is metadata-based routing. In most production pipelines, documents arrive with context: which system they came from, which department uploaded them, what file type they are. A legal document management system feeds the legal adapter. A clinical notes database feeds the medical adapter. This adds zero latency and requires no model at all. For pipelines with clean metadata, this is the right answer.

最簡單的是基於中繼資料的路由 (metadata-based routing)。在大多數的生產流程中，文件抵達時都帶有上下文：它們來自哪個系統、由哪個部門上傳、是什麼檔案類型。法律文件管理系統餵給法律轉接器；臨床紀錄資料庫餵給醫療轉接器。這幾乎不會增加任何延遲 (latency)，而且完全不需要模型。對於擁有乾淨中繼資料的流程來說，這就是正確答案。

When metadata isn’t available, a lightweight classifier works well. A fine-tuned DistilBERT or RoBERTa-small model classifies documents into domain categories in under 5ms on CPU. These models are 250MB — comparable to a single LoRA adapter — and can be trained on a few hundred labeled document headers. You don’t need 8 billion parameters to distinguish a patent filing from a clinical trial report.

當沒有中繼資料可用時，輕量分類器就能勝任。一個微調過的 DistilBERT 或 RoBERTa-small 模型，能在 CPU 上以不到 5 毫秒的時間將文件分入各個領域類別。這些模型只有 250MB——與單一 LoRA 轉接器相當——而且只需用幾百個標註過的文件標頭就能訓練。要區分一份專利申請與一份臨床試驗報告，你不需要 80 億個參數。

The third option is embedding-based routing: compute document embeddings, compare to domain centroid vectors, and route to the nearest domain. No training required beyond computing the centroids from a handful of example documents per domain. Slightly less accurate than a trained classifier, but deployable immediately.

第三個選項是基於嵌入的路由 (embedding-based routing)：計算文件的嵌入向量 (embedding)，與各領域的質心向量 (centroid vector) 比對，再路由到最接近的領域。除了從每個領域少數幾份範例文件計算出質心之外，不需要任何訓練。準確度比訓練過的分類器略低，但可以立即部署。

We add a confidence threshold to all approaches. If the classifier’s confidence falls below 70%, the document routes to a general-purpose adapter trained on the REBEL base without domain specialization. Better to extract with generic predicates than to apply the wrong domain’s vocabulary.

我們對所有方法都加上了信心門檻 (confidence threshold)。如果分類器的信心低於 70%，這份文件就會被路由到一個未經領域專精、僅以 REBEL 基礎訓練的通用轉接器。用通用謂詞來抽取，總比套用錯誤領域的詞彙要好。

Stage 2: Adapter Routing via vLLM / 階段二：透過 vLLM 進行轉接器路由

The serving layer is where the multi-LoRA magic happens. vLLM supports multiple LoRA adapters natively through its --enable-lora flag. The server loads the base model once and keeps adapter weights either in GPU memory (hot) or CPU memory (warm), swapping them in on demand.

服務層 (serving layer) 正是 multi-LoRA 魔法發生的地方。vLLM 透過其 --enable-lora 旗標原生支援多個 LoRA 轉接器。伺服器只載入基礎模型一次，並將轉接器權重保存在 GPU 記憶體（熱，hot）或 CPU 記憶體（溫，warm）中，按需換入。

The server starts with:

伺服器以下列指令啟動：

vllm serve Qwen/Qwen3-8B \  
  --enable-lora \  
  --max-loras 4 \  
  --max-lora-rank 64 \  
  --max-cpu-loras 8 \  
  --lora-modules \  
    legal=./adapters/legal \  
    medical=./adapters/medical \  
    financial=./adapters/financial \  
    technical=./adapters/technical

--max-loras 4 keeps four adapters in GPU memory simultaneously. --max-cpu-loras 8 keeps an additional four in CPU memory for quick swap-in. The --max-lora-rank must match the rank used during training.

--max-loras 4 讓四個轉接器同時保留在 GPU 記憶體中。--max-cpu-loras 8 在 CPU 記憶體中額外保留四個，以便快速換入。--max-lora-rank 必須與訓練時所用的秩相符。

The API is OpenAI-compatible. The routing layer simply sets the model parameter to the appropriate adapter name:

這個 API 與 OpenAI 相容。路由層只需將 model 參數設定為適當的轉接器名稱即可：

response = client.chat.completions.create(  
    model="legal",  # routes to the legal LoRA adapter  
    messages=[  
        {"role": "system", "content": EXTRACTION_PROMPT},  
        {"role": "user", "content": document_text}  
    ]  
)

Switching between pre-loaded adapters is effectively free — it’s a pointer swap in the attention layers, not a model reload. If an adapter needs to be loaded from CPU memory, the overhead is 50–100ms. We pre-load all hot adapters at startup by sending a dummy request for each one, which primes the LRU cache.

在已預先載入的轉接器之間切換，實質上是免費的——它只是注意力層中的一次指標 (pointer) 交換，而非重新載入整個模型。如果某個轉接器需要從 CPU 記憶體載入，額外開銷是 50–100 毫秒。我們在啟動時為每個熱轉接器各送出一個虛擬請求 (dummy request) 來預先載入，這會預熱 LRU 快取 (LRU cache)。

The SGMV kernel from Punica, integrated into vLLM, means that requests targeting different adapters can be batched in the same forward pass. A batch containing three legal documents and two medical documents processes simultaneously — no need to sort by domain first.

整合進 vLLM 的 Punica SGMV 核心，意味著針對不同轉接器的請求可以在同一次前向傳遞 (forward pass) 中批次處理。一個包含三份法律文件與兩份醫療文件的批次能同時處理——不需要先按領域排序。

Stage 3: Domain-Specific Extraction / 階段三：特定領域抽取

From the model’s perspective, nothing changes between adapters. The system prompt is identical. The JSON schema is identical. The base model is identical. What changes is the learned behavior in the adapter weights: which predicates the model produces, which entity types it recognizes, and how it decomposes complex passages into atomic triples.

從模型的角度來看，不同轉接器之間什麼都沒變。系統提示 (system prompt) 相同，JSON 綱要相同，基礎模型也相同。改變的是轉接器權重中所學到的行為：模型會產出哪些謂詞、辨識哪些實體類型，以及如何將複雜的段落拆解成原子三元組 (atomic triple)。

Here’s a concrete example. Given a passage about a pharmaceutical company’s acquisition, the same system prompt with different adapters produces:

以下是一個具體的例子。給定一段關於某製藥公司收購案的文字，同樣的系統提示搭配不同的轉接器，會產出：

Legal adapter:

法律轉接器：

{  
  "entities": [  
    {"name": "Pfizer", "type": "Party"},  
    {"name": "Seagen", "type": "Party"},  
    {"name": "SEC", "type": "Regulatory_Body"}  
  ],  
  "triples": [  
    {"subject": "Pfizer", "predicate": "acquired", "object": "Seagen"},  
    {"subject": "SEC", "predicate": "approved_merger", "object": "Pfizer"}  
  ]  
}

Financial adapter:

金融轉接器：

{  
  "entities": [  
    {"name": "Pfizer", "type": "Company"},  
    {"name": "Seagen", "type": "Company"},  
    {"name": "$43 billion", "type": "Amount"}  
  ],  
  "triples": [  
    {"subject": "Pfizer", "predicate": "acquired_for", "object": "$43 billion"},  
    {"subject": "Seagen", "predicate": "acquired_by", "object": "Pfizer"}  
  ]  
}

Same passage, same model weights, same prompt. Different adapter, different extraction focus. The legal adapter surfaces regulatory relationships and uses Party entities. The financial adapter surfaces transaction amounts and uses Company entities. Both are correct and useful; each serves a different downstream query pattern.

同一段文字、同樣的模型權重、同樣的提示。不同的轉接器，帶來不同的抽取焦點。法律轉接器凸顯了監管關係，並使用 Party 實體。金融轉接器凸顯了交易金額，並使用 Company 實體。兩者都正確且有用；各自服務於不同的下游查詢模式 (query pattern)。

The extraction format is identical across all adapters — the same JSON schema with the same entities and triples structure. This means downstream graph ingestion doesn't need to change per domain. A single pipeline writes to Neo4j regardless of which adapter produced the triples.

所有轉接器的抽取格式都完全相同——同一套 JSON 綱要、同樣的 entities 與 triples 結構。這意味著下游的圖譜匯入 (graph ingestion) 不需要針對每個領域做改動。無論三元組是由哪個轉接器產出的，都由同一條流程寫入 Neo4j。

Training Multiple Adapters: Practical Guide / 訓練多個轉接器：實務指南

Data Preparation / 資料準備

Each domain adapter needs its own training set, but they all share a common foundation. The recipe we’ve converged on has two layers.

每個領域轉接器都需要自己的訓練集，但它們全都共用一個共同基礎。我們最終收斂出的配方分為兩層。

The base layer is the same across all adapters: 2,500–3,000 samples from REBEL, filtered for quality (100–1500 character passages, 2–15 triples each, no self-referential triples or date entities). This teaches the model the structural extraction pattern — how to read a passage, identify entities, form triples, and output valid JSON. We described the REBEL conversion pipeline in detail in Part 2.

基礎層 (base layer) 在所有轉接器之間都相同：2,500–3,000 個經品質篩選後的 REBEL 樣本（段落長度 100–1500 字元、每段 2–15 個三元組、不含自我指涉 (self-referential) 三元組或日期實體）。這一層教會模型結構化的抽取模式——如何閱讀一段文字、辨識實體、組成三元組，並輸出有效的 JSON。我們在第二部分詳細描述過 REBEL 的轉換流程。

The domain layer is what differentiates each adapter: 200–500 hand-labeled examples using the exact predicate vocabulary and entity types that your domain requires. These samples don’t need to be long or complex. What matters is consistency — every example uses the same predicate names, the same entity type inventory, and the same granularity of triple decomposition.

領域層 (domain layer) 則是區別各個轉接器的關鍵：200–500 個手工標註的範例，使用你的領域所需的精確謂詞詞彙與實體類型。這些樣本不需要又長又複雜。重要的是一致性——每個範例都使用相同的謂詞名稱、相同的實體類型清單，以及相同的三元組拆解粒度 (granularity)。

We blend these at roughly 85% REBEL, 15% domain-specific. The REBEL base prevents overfitting to the small domain set, while the domain overlay teaches the model exactly which predicates to use and which entity types to recognize.

我們大致以 85% 的 REBEL、15% 的特定領域資料混合。REBEL 基礎可防止模型對小型的領域資料集過度擬合 (overfitting)，而領域覆蓋層則精確地教會模型該使用哪些謂詞、辨識哪些實體類型。

The data format is identical across domains: chat-format JSONL with a system prompt, a user message (the passage), and an assistant message (the extraction JSON). Only the content of the assistant messages differs between domains. This means the same training script works for every adapter.

各領域的資料格式完全相同：聊天格式的 JSONL，包含一個系統提示、一則使用者訊息（即段落文字），以及一則助理訊息（即抽取出的 JSON）。各領域之間只有助理訊息的內容不同。這意味著同一支訓練腳本適用於每一個轉接器。

One practical tip that saved us significant rework: define the predicate vocabulary before labeling a single example. Create a spreadsheet of 30–50 target predicates per domain, with clear definitions and examples. filed_lawsuit_against and filed_suit_against in the same training set will confuse the model. Consistency in predicates matters far more than volume of training data.

一個替我們省下大量返工的實務訣竅：在標註任何一個範例之前，先定義好謂詞詞彙。為每個領域建立一份包含 30–50 個目標謂詞的試算表，附上清楚的定義與範例。在同一個訓練集中同時出現 filed_lawsuit_against 與 filed_suit_against 會讓模型混淆。謂詞的一致性，遠比訓練資料的數量重要得多。

Training Configuration / 訓練組態

We train each adapter independently, never jointly. This was a deliberate choice backed by the Mixture-of-LoRAs literature (2024): different domains have different data scales and training difficulty, and joint training causes interference between tasks. Separate QLoRA runs avoid this entirely.

我們獨立訓練每一個轉接器，絕不聯合訓練。這是一個經過深思的選擇，背後有 Mixture-of-LoRAs 文獻（2024）的支持：不同領域有不同的資料規模與訓練難度，而聯合訓練會造成任務之間的干擾。各自獨立的 QLoRA 訓練則完全避開了這個問題。

The critical constraint: all adapters must be trained from the same base model checkpoint. This is what makes them swappable. If adapter A was trained from Qwen3–8B commit abc123 and adapter B from commit def456, they won't behave correctly when hot-swapped on the same base model.

關鍵限制：所有轉接器都必須從同一個基礎模型檢查點 (checkpoint) 訓練出來。 這正是它們得以互換的原因。如果轉接器 A 是從 Qwen3–8B 的 commit abc123 訓練出來的，而轉接器 B 是從 commit def456，那麼當它們在同一個基礎模型上被熱替換 (hot-swap) 時，行為就不會正確。

The rest of the configuration is the same as Part 2:

其餘的組態與第二部分相同：

• Rank 64, alpha 128. Higher than the typical r=16 default. Structured extraction with domain-specific predicates needs more adapter capacity. The alpha-to-rank ratio of 2 keeps the learning rate scaling reasonable.

• 秩 64、alpha 128。 比典型的 r=16 預設值更高。帶有特定領域謂詞的結構化抽取，需要更多的轉接器容量。alpha 對秩的比值為 2，讓學習率 (learning rate) 的縮放維持在合理範圍。

• Learning rate 3e-5 with cosine schedule. Three epochs over the full dataset, warmup over the first 3% of steps.

• 學習率 3e-5，搭配餘弦排程 (cosine schedule)。 在完整資料集上訓練三個週期 (epoch)，並在前 3% 的步數中進行暖身 (warmup)。

• QLoRA with 4-bit quantization. Fits comfortably on 2x RTX 3090 GPUs.

• 採用 4 位元量化 (4-bit quantization) 的 QLoRA。 在兩張 RTX 3090 GPU 上能輕鬆容納。

• User-turn masking. Loss computed only on the assistant’s output, not the input passage.

• 使用者回合遮罩 (user-turn masking)。 損失 (loss) 只在助理的輸出上計算，而非輸入的段落。

• Training time: 30–45 minutes per adapter. Four adapters = 2–3 hours total wall time. Not days.

• 訓練時間：每個轉接器 30–45 分鐘。 四個轉接器共計 2–3 小時的實際耗時 (wall time)，而非數天。

The Training Trick That Matters Most / 最重要的訓練訣竅

The single most impactful decision in our training pipeline isn’t the learning rate or the rank or the number of epochs. It’s the ratio of general-to-domain-specific data.

我們訓練流程中影響最大的單一決策，不是學習率、不是秩、也不是訓練週期數，而是通用資料與特定領域資料的比例。

Training purely on 200 domain-specific examples produces an adapter that overfits to the predicate vocabulary but loses the general extraction ability. It knows to output filed_lawsuit_against but forgets how to decompose complex multi-entity passages into atomic triples. Training purely on REBEL produces the opposite: excellent extraction structure but wrong predicates (the problem from Part 2).

純粹用 200 個特定領域範例來訓練，會產出一個對謂詞詞彙過度擬合、卻喪失了一般抽取能力的轉接器。它知道要輸出 filed_lawsuit_against，卻忘了如何把複雜的多實體段落拆解成原子三元組。純粹用 REBEL 訓練則恰恰相反：抽取結構極佳，但謂詞錯誤（也就是第二部分那個問題）。

The blend is what works. REBEL teaches “how to extract” — the structural pattern of reading text, identifying entities, forming subject-predicate-object triples, and outputting valid JSON. The domain overlay teaches “what to extract” — the specific predicates, entity types, and decomposition conventions your domain requires.

有效的是兩者的混合。REBEL 教的是「如何抽取」——閱讀文字、辨識實體、組成主詞—謂詞—受詞三元組，並輸出有效 JSON 的結構化模式。領域覆蓋層教的則是「抽取什麼」——你的領域所需的特定謂詞、實體類型與拆解慣例。

We start at 85/15 (REBEL/domain) and adjust based on validation metrics. If the adapter produces correct predicates but poor triple decomposition, increase the REBEL proportion. If it decomposes well but uses the wrong predicates, increase the domain proportion. In practice, the sweet spot is usually between 80/20 and 90/10.

我們從 85/15（REBEL/領域）開始，再根據驗證指標 (validation metrics) 調整。如果轉接器產出的謂詞正確、但三元組拆解不佳，就提高 REBEL 的比例；如果拆解得很好、但謂詞用錯了，就提高領域資料的比例。實務上，甜蜜點 (sweet spot) 通常落在 80/20 到 90/10 之間。

Always validate on both domain-specific test samples and a general extraction holdout. If general extraction performance drops more than 10% relative to the REBEL-only adapter, the domain proportion is too high.

務必同時在特定領域測試樣本與一般抽取保留集 (holdout) 上做驗證。如果一般抽取效能相較於純 REBEL 轉接器下降超過 10%，就代表領域資料的比例過高了。

Avoiding Common Pitfalls / 避開常見陷阱

We’ve trained enough adapters to have a list of things that go wrong. Here’s the short version.

我們訓練過的轉接器夠多，足以列出一張「容易出錯」的清單。以下是精簡版。

Entity type alignment across adapters. If the legal adapter uses Organization and the financial adapter uses Company for the same concept, your downstream knowledge graph will have duplicate entity types that should be merged. Define a shared entity type ontology across all domains before training. Domain-specific types (like Statute or Drug) extend the shared base; they don't replace it.

跨轉接器的實體類型對齊。 如果法律轉接器對某個概念使用 Organization，而金融轉接器對同一概念使用 Company，那你下游的知識圖譜就會出現本應合併、卻重複的實體類型。在訓練之前，先跨所有領域定義一套共用的實體類型本體論 (ontology)。特定領域的類型（如 Statute 或 Drug）是在共用基礎上做擴充，而非取代它。

Don’t overtrain. Three epochs are usually enough. LoRA is notably sensitive to hyperparameters — Biderman et al. (2024) showed this clearly. Watch validation loss and stop early if it climbs. We’ve seen adapters degrade after epoch 4–5, even when training loss continues to decrease.

不要過度訓練。 三個週期通常就夠了。LoRA 對超參數 (hyperparameter) 出了名地敏感——Biderman 等人（2024）清楚地證明了這一點。緊盯著驗證損失，一旦它上升就提早停止。我們看過轉接器在第 4 到 5 個週期後開始劣化，即便訓練損失仍在持續下降。

Test the base model too. After training a legal adapter, run it through the general REBEL evaluation from Part 2. If Entity F1 drops below 0.6 or schema conformance drops below 95%, something went wrong — probably too much domain-specific data or too high a learning rate.

也要測試基礎模型。 訓練完一個法律轉接器後，讓它跑一遍第二部分的通用 REBEL 評估。如果實體 F1 (Entity F1) 掉到 0.6 以下、或綱要符合度掉到 95% 以下，就代表哪裡出了問題——很可能是特定領域資料太多，或學習率太高。

Version your adapters. In production, you’ll be updating adapters as your domain vocabulary evolves, as new predicate types emerge, and as you fix extraction errors. Treat adapters like model artifacts: version them, track the training data provenance, log evaluation metrics, and keep rollback copies. A bad adapter update that goes to production will result in corrupted triples in your knowledge graph.

為你的轉接器做版本管理。 在生產環境中，隨著你的領域詞彙演進、新謂詞類型出現、以及你修正抽取錯誤，你會不斷更新轉接器。把轉接器當成模型產物 (model artifact) 來對待：為它們做版本管理、追蹤訓練資料的來源 (provenance)、記錄評估指標，並保留可回滾 (rollback) 的副本。一次糟糕的轉接器更新若上線，就會在你的知識圖譜中造成損壞的三元組。

System Setup: From Training to Serving / 系統建置：從訓練到服務

Hardware Requirements / 硬體需求

The beauty of the multi-LoRA approach is that it fits on hardware you probably already have.

multi-LoRA 方法的妙處在於，它能在你大概已經擁有的硬體上運行。

For development and proof of concept, a single RTX 3090 (24GB) is sufficient. You can train one adapter at a time and serve 2–3 concurrent adapters. This is the setup we used for the experiments in Part 2.

對於開發與概念驗證 (proof of concept)，單張 RTX 3090（24GB）就足夠了。你可以一次訓練一個轉接器，並同時服務 2–3 個轉接器。這正是我們在第二部分的實驗中所用的配置。

For small production, two RTX 3090s or a single A100 (40GB) is the sweet spot. Training with accelerate across two GPUs cuts training time in half (33 minutes down to under 20 minutes per adapter). Serving 4-8 adapters is comfortable.

對於小型生產環境，兩張 RTX 3090 或單張 A100（40GB）是甜蜜點。透過 accelerate 在兩張 GPU 上訓練可將訓練時間減半（每個轉接器從 33 分鐘降到 20 分鐘以內）。同時服務 4–8 個轉接器綽綽有餘。

For scaling up — if you’re serving 16+ domain adapters or handling hundreds of concurrent extraction requests — an A100 80GB or H100 gives you room for both adapter weights and the KV cache that dominates memory at high concurrency.

對於規模擴展——如果你要服務 16 個以上的領域轉接器、或處理數百個並行的抽取請求——A100 80GB 或 H100 能同時為轉接器權重以及在高並行度 (concurrency) 下主導記憶體用量的 KV 快取提供空間。

Storage is never the bottleneck. Each adapter is ~250MB at rank 64. A hundred adapters is 25GB on disk — smaller than the base model.

儲存空間從來不是瓶頸。每個秩 64 的轉接器約 250MB。一百個轉接器在硬碟上佔 25GB——比基礎模型還小。

Training Pipeline / 訓練流程

The end-to-end flow for adding a new domain adapter:

新增一個領域轉接器的端到端 (end-to-end) 流程：

Step 1: Prepare training data. Run the REBEL conversion pipeline (prepare_rebel.py) for the base layer. Hand-label 200-500 domain-specific examples following your predicate vocabulary. Blend into a single JSONL file.

步驟一：準備訓練資料。 為基礎層執行 REBEL 轉換流程（prepare_rebel.py）。依照你的謂詞詞彙手工標註 200–500 個特定領域範例。將它們混合成單一個 JSONL 檔案。

Step 2: Train. Run QLoRA training with accelerate:

步驟二：訓練。 透過 accelerate 執行 QLoRA 訓練：

accelerate launch --num_processes 2 scripts/train_server.py \  
  --data data/legal_train.jsonl \  
  --output outputs/legal-adapter

Step 3: Evaluate. Test the adapter against your domain-specific benchmark and the general REBEL holdout:

步驟三：評估。 用你的特定領域基準測試與通用 REBEL 保留集來測試這個轉接器：

python scripts/evaluate_local.py \  
  --model-path outputs/legal-adapter-merged \  
  --compare-with results/baseline_aggregate.csv

Step 4: Deploy. Copy the adapter weights to the serving directory and register with vLLM. If the server is already running, vLLM picks up new adapters dynamically — no restart required.

步驟四：部署。 將轉接器權重複製到服務目錄並向 vLLM 註冊。如果伺服器已在運行中，vLLM 會動態地接收新的轉接器——無需重新啟動。

The whole cycle from “we need a new domain adapter” to “it’s serving in production” takes a day: half a day for data labeling, an hour for training, an hour for evaluation, and the rest for review and deployment.

從「我們需要一個新的領域轉接器」到「它已在生產環境中服務」的整個週期只需一天：半天用於資料標註、一小時用於訓練、一小時用於評估，其餘時間用於審查與部署。

Serving Architecture / 服務架構

┌──────────────┐     ┌─────────────────┐     ┌──────────────────────┐  
│   Document   │────>│   Classifier    │────>│   vLLM + Multi-LoRA  │  
│   Ingestion  │     │  (DistilBERT /  │     │                      │  
│              │     │   metadata)     │     │  Base: Qwen3-8B      │  
└──────────────┘     └─────────────────┘     │  ├─ legal adapter    │  
                            │                │  ├─ medical adapter  │  
                       domain_id             │  ├─ financial adapter│  
                            │                │  └─ technical adapter│  
                            └───────────────>│                      │  
                                             └──────────┬───────────┘  
                                                        │  
                                                   JSON triples  
                                                        │  
                                             ┌──────────▼───────────┐  
                                             │   Knowledge Graph    │  
                                             │   (Neo4j / Neptune)  │  
                                             └──────────────────────┘

The key vLLM configuration flags:

關鍵的 vLLM 組態旗標：

--enable-lora activates multi-LoRA support. --max-loras 4 controls how many adapters stay in GPU memory simultaneously — set this to the number of domains you expect to serve concurrently. --max-lora-rank 64 must match the rank used during training; mismatches will silently produce garbage output. --max-cpu-loras 8 keeps additional adapters in CPU memory for fast swap-in without reloading from disk. --lora-modules maps human-readable adapter names to weight directories.

--enable-lora 啟用 multi-LoRA 支援。--max-loras 4 控制有多少個轉接器同時保留在 GPU 記憶體中——把它設為你預期要並行服務的領域數量。--max-lora-rank 64 必須與訓練時所用的秩相符；若不一致，會悄無聲息地產出垃圾輸出。--max-cpu-loras 8 在 CPU 記憶體中保留額外的轉接器，以便快速換入而無需從硬碟重新載入。--lora-modules 將人類可讀的轉接器名稱對應到權重目錄。

At request time, the classifier’s output maps directly to a vLLM model name. The routing logic is a single if-statement that sets the model parameter in the API call. No orchestration framework, no message queue, no complexity beyond what's needed.

在請求發生時，分類器的輸出直接對應到一個 vLLM 模型名稱。路由邏輯就是一個 if 判斷式，用來設定 API 呼叫中的 model 參數。沒有編排框架 (orchestration framework)、沒有訊息佇列 (message queue)、沒有任何超出實際所需的複雜度。

What’s Coming Next: Automatic Routing and Adapter Fusion / 接下來會發生什麼：自動路由與轉接器融合

Our current pipeline uses document-level classification: one document, one adapter, one extraction. This handles the vast majority of our workload. But some documents are genuinely multi-domain — a legal brief that discusses financial instruments, or a clinical trial report with regulatory compliance sections. For these, choosing one adapter means losing the other domain’s extraction quality.

我們目前的流程使用文件層級 (document-level) 的分類：一份文件、一個轉接器、一次抽取。這能處理我們絕大部分的工作負載。但有些文件確實是跨領域的——一份討論金融工具 (financial instrument) 的法律摘要，或一份帶有法規遵循 (regulatory compliance) 章節的臨床試驗報告。對這些文件而言，只選一個轉接器，就意味著喪失另一個領域的抽取品質。

The research community is actively working on this problem, and several approaches are worth watching.

研究社群正積極處理這個問題，有幾種方法值得關注。

LoRA-Switch (Kong et al.) introduces token-level dynamic routing with fused CUDA kernels. Instead of choosing one adapter per document, the model routes individual tokens to different adapters during the forward pass. The system-algorithm co-design reduces the latency overhead of dynamic routing from 2.5–3x down to about 24% over static serving. For passages that span legal and financial content in the same paragraph, this could meaningfully improve extraction quality.

LoRA-Switch（Kong 等人）引入了搭配融合 CUDA 核心 (fused CUDA kernel) 的詞元層級 (token-level) 動態路由。模型不再是每份文件選一個轉接器，而是在前向傳遞過程中，把個別的詞元路由到不同的轉接器。這種系統—演算法協同設計 (system-algorithm co-design) 將動態路由相對於靜態服務的延遲開銷，從 2.5–3 倍降到約 24%。對於同一段落內橫跨法律與金融內容的文字，這可能會顯著改善抽取品質。

LORAUTER (Ostapenko et al.) takes a different approach: routing based on task representations rather than document classification. Adapters are selected based on embedding similarity between the input and learned task vectors. More elegant than maintaining a separate classifier, and it scales with the number of tasks rather than the number of adapters.

LORAUTER（Ostapenko 等人）採取了不同的方法：根據任務表徵 (task representation)、而非文件分類來進行路由。轉接器的選擇，是依據輸入與已學習的任務向量 (task vector) 之間的嵌入相似度。這比維護一個獨立的分類器更為優雅，而且它的擴展性取決於任務數量、而非轉接器數量。

MoLoRA (Li et al.) pushes furthest — per-token mixture of LoRA experts with learned gating. The headline result is striking: a 1.7B model with MoLoRA routing exceeds a vanilla 8B model on reasoning benchmarks. For multi-domain extraction, this is the most promising direction. But it’s too new for production deployment, and framework integration is still in early stages.

MoLoRA（Li 等人）走得最遠——逐詞元的 LoRA 專家混合 (mixture of LoRA experts)，搭配可學習的閘控 (gating)。其最醒目的結果令人震撼：一個採用 MoLoRA 路由的 1.7B 模型，在推理基準測試上超越了一個普通的 8B 模型。對於多領域抽取而言，這是最有前景的方向。但它太新，還不適合用於生產部署，框架整合也仍處於早期階段。

Adapter fusion and LoRA Soups (Zhao et al.) take the opposite approach: instead of switching between adapters, merge their weights at inference time with learned mixing coefficients. This works well when domains overlap — a legal-financial contract benefits from a blend of both adapters rather than a hard choice between them. LoRAHub showed this is practical for cross-task composition.

轉接器融合與 LoRA Soups（Zhao 等人）採取了相反的方法：不在轉接器之間切換，而是在推論時用可學習的混合係數 (mixing coefficient) 合併它們的權重。這在領域有重疊時效果很好——一份法律—金融合約，得益於兩個轉接器的混合，而非在兩者之間做出非此即彼的硬性抉擇。LoRAHub 已證明這對於跨任務組合 (cross-task composition) 是可行的。

For our pipeline, document-level routing handles 95% of cases cleanly. The remaining 5% — ambiguous or genuinely multi-domain documents — is where these techniques will matter. We’re watching LoRA-Switch for vLLM integration most closely, as it’s the most mature of the dynamic approaches.

對於我們的流程而言，文件層級路由能俐落地處理 95% 的情況。剩下的 5%——也就是模糊的、或確實跨領域的文件——正是這些技術會發揮作用的地方。我們最密切關注的是 LoRA-Switch 與 vLLM 的整合，因為它是各種動態方法中最成熟的。

Key Takeaways / 重點摘要

One base model + N adapters beats N separate models. The memory math is overwhelming: 17GB vs 64GB for four domains, on a single GPU. The adapters are hot-swappable with zero model reload, and vLLM’s SGMV kernel batches across different adapters in the same forward pass.

一個基礎模型 + N 個轉接器，勝過 N 個獨立模型。 記憶體帳算下來壓倒性地有利：四個領域只需 17GB，對比 64GB，而且就在單張 GPU 上。轉接器可熱替換、完全無需重新載入模型，而 vLLM 的 SGMV 核心能在同一次前向傳遞中跨不同轉接器做批次處理。

Train adapters independently, not jointly. Each domain is its own QLoRA run: same base model, same hyperparameters, different training data. 200–500 domain-specific examples blended with a REBEL base. 30–45 minutes per adapter on consumer GPUs.

獨立訓練轉接器，而非聯合訓練。 每個領域都是自己的一次 QLoRA 訓練：相同的基礎模型、相同的超參數、不同的訓練資料。200–500 個特定領域範例，與 REBEL 基礎混合。在消費級 GPU 上，每個轉接器 30–45 分鐘。

Document classification is the routing layer, not the bottleneck. A tiny classifier, metadata rules, or even embedding similarity handles routing. The adapter selection doesn’t need to be perfect — it needs to be mostly right, with a general-purpose fallback for uncertain cases.

文件分類是路由層，而非瓶頸。 一個極小的分類器、中繼資料規則、甚至是嵌入相似度，都能處理路由。轉接器的選擇不需要完美——它只需大致正確，並為不確定的情況準備一個通用的後備 (fallback) 方案。

vLLM makes this production-ready today. Native multi-LoRA support, OpenAI-compatible API, LRU caching, concurrent adapter batching. The infrastructure exists; the engineering effort is in the training data, not the serving layer.

vLLM 讓這套方案今天就能用於生產環境。 原生 multi-LoRA 支援、OpenAI 相容的 API、LRU 快取、並行的轉接器批次處理。基礎設施已經存在；工程上的力氣應該花在訓練資料上，而非服務層。

LoRA’s forgetting resistance is the enabling property. Each adapter specializes without compromising the base model’s JSON generation or general extraction capabilities. Biderman et al. (2024) showed this empirically: LoRA sits on a Pareto curve of learning more while forgetting less. For modular domain adapters, that tradeoff is exactly what you want.

LoRA 的抗遺忘性正是讓整套方法得以成立的關鍵特性。 每個轉接器在專精化的同時，不會損及基礎模型的 JSON 生成或一般抽取能力。Biderman 等人（2024）以實證證明了這一點：LoRA 落在一條「學得越多、忘得越少」的柏拉圖曲線上。對於模組化的領域轉接器而言，那個取捨正是你所想要的。

Define your predicate vocabulary before labeling. This is the single most impactful thing you can do for extraction quality. A clean, consistent set of 30–50 predicates per domain, defined up front, yields better results than doubling the training data with inconsistent labels.

在標註之前先定義好你的謂詞詞彙。 這是你為抽取品質所能做的、影響最大的單一件事。每個領域一套乾淨、一致、事先定義好的 30–50 個謂詞，比起用不一致的標籤把訓練資料加倍，能帶來更好的結果。

This is Part 3 of our Graph RAG extraction series. Part 1 covers benchmarking local LLMs for extraction. Part 2 covers fine-tuning and the domain transfer problem. All experiments were run on NVIDIA RTX 3090 GPUs, using vLLM for inference and TRL/PEFT for fine-tuning.

這是我們 Graph RAG 抽取系列的第三部分。 第一部分 涵蓋了針對抽取任務對本地 LLM 進行基準測試。 第二部分 涵蓋了微調與領域遷移 (domain transfer) 問題。所有實驗都在 NVIDIA RTX 3090 GPU 上執行，使用 vLLM 進行推論，並以 TRL/PEFT 進行微調。

References

參考文獻

• Biderman et al., “LoRA Learns Less and Forgets Less,” ICML 2024
• Sheng et al., “S-LoRA: Serving Thousands of Concurrent LoRA Adapters,” MLSys 2024
• Chen et al., “Punica: Multi-Tenant LoRA Serving,” MLSys 2024
• Kong et al., “LoRA-Switch: Boosting Efficiency of Dynamic LLM Adapters via System-Algorithm Co-design,” 2024
• Ostapenko et al., “LORAUTER: Effective LoRA Adapter Routing using Task Representations,” 2025
• Li et al., “MoLoRA: Contrastive Learning-Guided Mixture of Long-Short LoRA Experts,” 2025
• Zhao et al., “LoRA Soups: Merging LoRAs for Practical Skill Composition Tasks,” 2024

---

🔤 關鍵術語

英文	繁中譯名	文章中的脈絡 / 簡短說明
Multi-LoRA	多重 LoRA（多適配器）	一個基礎模型搭配多個輕量適配器，依文件領域熱插拔，取代多個獨立微調模型
LoRA (Low-Rank Adaptation)	低秩適應	凍結基礎模型權重，只訓練小型低秩分解的適配器矩陣，修改注意力與前饋層
QLoRA	量化低秩適應	以 4-bit 量化進行 LoRA 訓練，可在消費級 GPU（2× RTX 3090）上完成
Knowledge Graph	知識圖譜	抽取出的實體與三元組最終寫入 Neo4j／Neptune 等圖資料庫
Entity-Relation Extraction	實體關係抽取	從文本中辨識實體並形成三元組的核心任務
Triple (subject-predicate-object)	三元組（主詞-謂詞-受詞）	知識圖譜的基本單位，如 (Pfizer, acquired, Seagen)
Predicate Vocabulary	謂詞詞彙表	每個領域有自己的謂詞集合（如 filed_lawsuit_against），需事先定義以保持一致
Triple F1	三元組 F1 分數	評估抽取三元組正確性的指標；領域文本上會崩跌
Catastrophic Forgetting	災難性遺忘	特化某領域時模型喪失產生有效 JSON 或一般抽取能力的風險
Pareto Curve	帕累托曲線	Biderman 等人指出 LoRA 學得少但也忘得少，位於同一權衡曲線上
Schema Conformance	結構符合度	輸出符合預期 JSON schema 的比例；few-shot 抽取品質高但符合度僅 20%
Few-shot Prompting	少樣本提示	以範例提示提升抽取品質，但結構穩定性差
S-LoRA	S-LoRA（並發適配器服務）	以統一記憶體分頁在單一 GPU 上服務數千個並發 LoRA 適配器
SGMV Kernel (Punica)	SGMV 核心	Punica 提出，可在同一前向傳播中跨不同適配器批次推論，吞吐量提升 12 倍
vLLM	vLLM（推論服務框架）	原生支援多 LoRA，提供 OpenAI 相容 API 與並發適配器批次
KV Cache	KV 快取	高並發時主導記憶體用量，需為其預留空間
Embedding-based Routing	嵌入式路由	計算文件嵌入並比對領域質心向量，路由至最近領域
DistilBERT / RoBERTa	DistilBERT／RoBERTa	輕量分類器，於 CPU 上 5ms 內完成文件領域分類
Entity Type Ontology	實體類型本體	跨領域共享的實體類型定義，避免下游圖譜出現重複類型
Mixture of LoRA Experts (MoLoRA)	LoRA 專家混合	逐 token 的 LoRA 專家混合與學習式門控，1.7B 模型可勝過 8B 基準
Adapter Fusion / LoRA Soups	適配器融合／LoRA 湯	推論時以學習式混合係數合併多適配器權重，適用領域重疊情境
User-turn Masking	使用者輪次遮罩	損失僅計算於助理輸出，不計入輸入段落