用一句話區分：Keyword 與 Entity 到底差在哪？
用一句話區分：Keyword 與 Entity 到底差在哪？
在建立知識圖譜（Knowledge Graph）或是實作 GraphRAG 時，最常遇到的一個痛點就是：「Keyword（關鍵字）」 和 「Entity（實體）」 到底有什麼不同？
如果用一句話來區分：
Keyword（關鍵字）：出現在文章裡的「字串」——用來做匹配、搜尋、過濾。
Entity（實體）：你定義的「概念／東西」——有唯一身分、型別、可連線，用來做導航與圖結構。
這篇文章將透過完整的對照與具體範例，帶你理解兩者的差異，並介紹在實際專案中（如 Skill Graph）我們該如何有結構地提煉與定義 Entity。
比較對照表
我們可以從以下幾個維度來對比 Keyword 與 Entity：
| 維度 | Keyword（關鍵字） | Entity（實體） |
|---|---|---|
| 本質 | 字串、詞彙 | 有身分的的具體概念（節點） |
| 同一概念的多種寫法 | 每個寫法都是不同的 Keyword（例如 K8s ≠ Kubernetes） |
多個寫法可以對應同一個 Entity（比如 K8s 和 Kubernetes 都指向 entity:kubernetes） |
| 有沒有型別（Type） | 通常沒有 | 有（例如 skill, tool, framework 等） |
| 關係（Relationship） | 不建模關係 | 可以連 Chunk（內容區塊）、連其他 Entity（作為圖的邊） |
| 主要用途 | 全文搜尋、篩選、統計出現頻率 | 知識導航、關係擴展、GraphRAG、建立技能樹 |
| 怎麼得到它 | 切詞、TF-IDF、Regex 匹配、只要文中有出現就算 | 抽取（Extraction） → 標準化 → 去重（Deduplication） |
具體範例：K8s 與 Docker
讓我們先看一句話：「用 K8s 部署時我們會搭配 Docker。」
1. 當作 Keyword 看
系統會切出三個獨立的詞彙：「K8s」、「對部署」、「Docker」。
在這個層面上，系統沒有「K8s = Kubernetes」的資訊，也沒有「Docker 和 K8s 經常一起出現（有關係）」的結構。
2. 當作 Entity 看
系統經過認知後，會提煉出兩個重點實體：
entity:kubernetes（name: Kubernetes, aliases: [K8s]）entity:docker（name: Docker）
這兩者都可以做為知識圖譜上的「節點」。之後我們可以透過 Embedding 或是手動建立關係，將這兩個節點連成「Kubernetes – Docker」的圖結構。
結論：
Keyword 代表的是「長相（字面出現的詞）」；而 Entity 代表的是「是誰（概念本體）」。
一個 Entity 可以對應很多個 Keyword（如別名、簡稱、錯字）；反過來，一個 Keyword 如果沒有經過標準化，系統並不知道它到底指的是哪一個 Entity。
在 Skill Graph 專案裡的應用對應
如果你正在實作一個自己的知識庫或技術圖譜，你可以這樣理解文件中的標籤與節點：
- Tags（標籤）：比較像是「分類用的 Keyword」——顆粒度較粗、可能會重複，主要用來做簡單的篩選（例如
Backend,DevOps）。 - Entities（實體）：這是經過標準化後的概念清單。每一個實體都有自己的
id、name和type。文檔的內容區塊（Chunk）會透過entities: [entity:...]連結到這些實體上，為 GraphRAG 提供「地圖上的節點」。
記住：在構建知識圖譜時，我們要提煉的是 Entity，而不是單純的 Keyword 列表。 Entity 是你承認的、可重複使用的、且可連線的知識節點。
如何在 YAML 裡標準化定義 Entity？
根據 技能圖譜 (Skill Graph) 的定義標準，我們可以將 Entity 的格式整理成以下規範，並統一放在 Markdown 的 YAML frontmatter 裡。
1. Entity 該放在哪裡？
Entity 屬於文件級別的設定，應該寫在頂層的 entities: 陣列中，與 chunks: 並列：
---
title: "Backend Skills"
entities: # 整份文件共用的 entity 清單
- id: entity:python
name: Python
type: skill
aliases: [python3]
chunks:
- id: skill:python-api
entities: [entity:python, entity:fastapi] # chunk 用 id 來引用 entity
---Tip: 在同一份文件中，每個 Entity 只要定義一次；而不同的 Chunk 只需要透過
entities:陣列使用id去引用就好。
2. 單一 Entity 的核心欄位
每個 Entity 都是一個 YAML 物件，必須包含以下關鍵資訊：
| 欄位 | 必填 | 型別 | 說明 |
|---|---|---|---|
id |
✅ 是 | string | 唯一識別碼，寫給機讀用（格式嚴格，見下文） |
name |
✅ 是 | string | 對外顯示的標準名稱（可含大小寫、空格） |
type |
✅ 是 | string | 概念類型（須從固定清單中選擇） |
aliases |
否 | array | 別名／簡稱／變體寫法，用來對應文中的不同詞彙 |
3. id 的命名格式
- 格式：
entity:{canonical-name} - 規則：
- 前綴必須是
entity: - 後面全部使用 小寫 + kebab-case（單字與單字之間用
-連接） - 在同一份文件內絕對不可重複！
- 前綴必須是
範例對照：
| 概念 | 正確 id |
錯誤示範（千萬別這麼寫） |
|---|---|---|
| Python | entity:python |
entity:Python (不要大寫) |
| FastAPI | entity:fastapi |
entity:FastAPI (不要大寫) |
| PostgreSQL | entity:postgresql |
entity:PostgreSQL (不要大寫) |
| Event-Driven Architecture | entity:event-driven-architecture |
entity:Event Driven Architecture (未轉 kebab) |
| CI/CD | entity:ci-cd |
entity:CI/CD (請將斜線改為 -) |
id是給機器（開發程式、Graph DB）看的穩定唯一代號；而name才是給人類讀者看的正式顯示名稱。
4. name 的命名格式
- 型別： 字串
- 建議： 使用該領域最常見、最正式的技術寫法。
- 規則： 可以保留大小寫、空格、標點符號與縮寫（例如：
FastAPI、CI/CD、Event-Driven Architecture）。 - 目的：
name會出現在 UI 介面、圖表節點標籤或是報表上，所以一切以「高可讀性」為主。
5. type 的分類清單
type 用來區分「這是哪一類別的概念」，請盡量從以下固定清單中挑選，不要自創一堆新分類：
| type 類型 | 用途 | 範例實體 |
|---|---|---|
skill |
技能、程式語言、核心能力 | Python, SQL, System Design |
tool |
工具、CLI、周邊開發工具 | Docker, Git, Redis |
library |
語言生態系的程式庫、套件 | Pandas, Lodash, axios |
framework |
網頁端或後端的應用框架 | FastAPI, React, Spring |
platform |
雲端平台、SaaS 服務、排程平台 | AWS, Vercel, Kubernetes |
database |
各式關聯與非關聯資料庫 | PostgreSQL, MongoDB |
architecture |
架構設計模式 | Event-Driven, Microservices |
protocol |
網路協定、標準規範 | HTTP, JWT, gRPC |
domain |
特定業務／技術領域 | DevOps, Frontend |
product |
產品、系統名稱 | Stripe, Notion |
concept |
無法歸類的其他抽象概念 | Caching, Indexing |
若都不太符合，一律退回使用 concept 即可。
6. aliases（別名）的使用技巧
- 型別： 字串陣列
- 用途： 處理同一概念在不同文章段落中可能出現的異體寫法或縮寫。讓系統遇到各種別名時，都能成功對應回同一個 Entity。
- 允許空白： 若該概念沒有別名，可以寫
aliases: []或直接省略這個欄位不寫。
範例：
- id: entity:kubernetes
name: Kubernetes
type: platform
aliases: [K8s, k8s]
- id: entity:javascript
name: JavaScript
type: skill
aliases: [JS, js]未來系統做語意檢索或內容正規化處理時，可以透過綜合比對
id+name+aliases來判斷「這段落到底在探討哪個技術點」。
完整的 YAML 結構範例
把上述所有規則組合起來，我們來看看一份完整的文件開頭會長什麼樣子：
---
title: "Backend Skills"
entities:
- id: entity:python
name: Python
type: skill
aliases: [python3, py]
- id: entity:fastapi
name: FastAPI
type: framework
aliases: []
- id: entity:postgresql
name: PostgreSQL
type: database
aliases: [postgres, psql]
- id: entity:event-driven-architecture
name: Event-Driven Architecture
type: architecture
aliases: [EDA, event-driven]
chunks:
- id: skill:python-api
tags: [Python, Backend]
entities: [entity:python, entity:fastapi]
context: "Python REST API development with FastAPI"
---Chunk（內容區塊）該如何引用 Entity？
在 chunks 陣列中的每個區塊，若要標示這段內容提到了哪些實體，只需利用 entities 欄位：
- 欄位名稱：
entities - 欄位型別： 字串陣列
- 內容限制： 陣列內的值必須是同一份文件
entities裡已經確確實實定義好的id。
chunks:
- id: skill:python-api
entities: [entity:python, entity:fastapi] # 只能填寫上面已經定義過的 id撰寫小提醒：
- 段落無特別實體： 可以省略
entities屬性或寫entities: []。 - 重在精準： 建議每個 Chunk 大約標註 1 到 6 個 Entity 即可。只列出「這段內容真正在講、具核心關聯」的對象，千萬不要貪心把整份文件的 Entity 全塞進單一 Chunk 裡。
總結對照
最後，用一個簡單的總結表格複習一下如何在 Markdown 文件中管理 Entity 實體：
| 設定項目 | 規範與說明 |
|---|---|
| 位置 | 放在首部 Frontmatter 的頂層 entities: 陣列中 |
| 必填欄位 | 包含 id, name, type 三項 |
| 選填欄位 | aliases |
| id 命名規則 | entity: 開頭 ＋ 全部字母小寫 kebab-case（必須保證文件內唯一） |
| type 選擇規則 | 請從 skill / tool / library / framework / platform / database / architecture / protocol / concept / domain / product 固定清單中選其一 |
| Chunk 的引用 | chunks[].entities: [entity:id, ...]，且引用的 ID 必須預先存在這份文件的 entities 目錄裡 |
釐清 Keyword（字面外觀）與 Entity（知識本體）的差別，並老老實實地遵循規範把圖譜的節點建好，才是邁向進階 GraphRAG 系統、打造專屬技能術的最穩固地基！
- ← Previous
從 HelixDB 開始：中小圖教學系列大綱 - Next →
RAG 檢索升級：從 Anthropic Contextual Retrieval 到 ctxfst 的 Embedding 最佳實踐