從 Lance-graph 開始:教學系列大綱
從 Lance-graph 開始:教學系列大綱
如果要把 lance-graph 講清楚,我覺得不能一開始就跳進 GraphRAG、embedding pipeline 或複雜的檢索設計。
比較好的教法是先把最核心的幾件事講明白:
LanceDB在做什麼lance-graph多了什麼能力- graph schema 要怎麼設計
- Cypher 查詢到底怎麼用
- 什麼問題適合用 graph 來解
這篇文章就是我對這套教學系列的整理。目標很單純:先讓人真的看懂 lance-graph。
為什麼值得從 Lance-graph 開始?
lance-graph 有一個很適合教學的特質:它不是一整套包山包海的大框架,而是一個非常清楚的能力延伸。
你可以先這樣理解:
LanceDB負責 table、向量、欄式儲存lance-graph讓你在同一個資料世界裡加入 graph schema 與 traversal query
這種切法很適合教學,因為觀眾不用先吞下一整套新宇宙,只要先理解一個問題:
當資料之間不只是「相似」,而是有明確關聯時,
我們該怎麼把這些關聯也變成可查詢的資料?
這就是 lance-graph 最適合拿來示範的地方。
這套系列想讓讀者學會什麼?
我希望看完這套系列之後,讀者至少能做到下面幾件事:
- 說清楚
LanceDB和lance-graph的關係 - 知道什麼是 node、edge、property、path
- 能設計一個最小可用的 graph schema
- 能寫出基本的 Cypher 查詢
- 能把一份簡單資料整理成 graph demo
這樣就夠了。
先把這些基礎能力建立起來,後面要延伸到知識圖譜、推薦系統、GraphRAG,才會是自然成長,不會像跳級。
目標讀者
這套系列我想對準三種人:
- 已經會 Python,想開始接觸 graph query 的工程師
- 已經知道
LanceDB,但還沒碰過lance-graph的人 - 想做一個小型 graph demo repo 的人
不假設讀者已經熟悉
- Neo4j
- Cypher
- graph database
- 圖演算法
但會假設讀者至少知道
- Python script 怎麼跑
- table / JSON / YAML 這類基本資料格式
- 資料查詢是什麼概念
這套系列的教學原則
1. 先講資料模型,再講查詢語法
如果不知道資料怎麼建模,Cypher 只會變成看不懂的新語法。
2. 先做小圖,再談大規模
一開始用 10 到 30 個節點就夠了。先讓讀者看懂 graph 長什麼樣,比直接談 scale 有用。
3. 每一集都要能自己跑
每一集至少要有一個可以執行的成果:
- 一個 table
- 一個 graph schema
- 一段查詢
- 一個小型 demo
4. 先回答「這能拿來做什麼」
教學不能只停在語法。每個 query 最好都對應一個真實問題。
教學系列總覽
我目前會把系列切成 6 章:
| 章節 | 主題 | 核心問題 | 產出 |
|---|---|---|---|
| Ch1 | LanceDB 到 lance-graph |
兩者差在哪?為什麼要加 graph? | 最小概念 demo |
| Ch2 | Graph schema 設計 | node、edge、property 怎麼建模? | 一份 skills graph schema |
| Ch3 | 把資料放進圖裡 | 怎麼從 JSON/YAML 建 node 與 edge? | 建圖 script |
| Ch4 | Cypher 查詢入門 | 怎麼找鄰居、找路徑、做多跳查詢? | 查詢 notebook |
| Ch5 | 用小案例做完整 demo | 怎麼把 schema + query 串起來? | 可執行示範專案 |
| Ch6 | 往後怎麼延伸 | 之後可以接哪些應用? | 系列收尾與延伸方向 |
Ch1:先搞懂 LanceDB 和 Lance-graph 的關係
第一章的目標不是寫很多 code,而是讓讀者先建立地圖。
要回答的問題
LanceDB本來擅長什麼?lance-graph是新資料庫,還是LanceDB的延伸?- 為什麼不是直接用
NetworkX就好? - 什麼時候 graph query 會比單純 table query 更直覺?
Demo 想法
用一個非常小的技能資料集:
PythonFastAPIDockerKubernetesHonoCloudflare Workers
然後示範兩種不同問題:
- table / vector 類型問題:
有哪些和 container deployment 有關的項目? - graph 類型問題:
FastAPI 兩跳以內相關的技術有哪些?
讀者只要在這一集建立一個直覺就夠了:
graph 的價值不是把資料畫成圖,
而是讓「關聯」本身可以被查詢。
Ch2:Graph Schema 怎麼設計?
第二章是整個系列最關鍵的基礎。
如果 schema 設計得亂,後面查詢一定亂。
這一章會講什麼
- 哪些實體適合當 node
- 哪些關係適合當 edge
- 哪些資訊該放在 property
- edge type 應該切多細
教學用的最小 schema
我會先用一個很適合教學的小模型:
(:Skill)
(:Article)
(:Category)
對應的關係:
(:Skill)-[:RELATED_TO]->(:Skill)
(:Article)-[:MENTIONS]->(:Skill)
(:Skill)-[:IN_CATEGORY]->(:Category)
這一章要讓讀者得到的能力
不是背一套標準答案,而是學會判斷:
- 什麼是資料本體
- 什麼是資料之間的連結
- schema 該怎麼服務後面的查詢需求
Ch3:怎麼把資料真的建成圖?
第三章開始動手做。
前面知道 schema 是什麼,這一章就要把它變成實際資料。
這一章的目標
讓讀者知道 graph 不是抽象概念,而是真的可以從一份結構化資料建立出來。
會做的事
- 讀入
skills.yaml - 讀入
articles.jsonl - 建立 nodes
- 建立 edges
- 檢查資料有沒有符合 schema
教學策略
這一章不追求自動化到最極致,而是優先讓每一步都看得見。
比較理想的節奏是:
- 先手動建 5 到 10 個節點
- 再從檔案讀資料批次建立
- 最後讓讀者看到 graph 結構真的成形
這樣他才會知道 lance-graph 不是神奇黑盒,而是一層清楚的資料建模過程。
Ch4:Cypher 查詢入門
這一章是整個系列最有「上手感」的一集。
目標
讓讀者能自己寫出幾種最基本、但真的有用的查詢。
我想先教的查詢類型
- 單跳鄰居查詢
- 多跳擴展查詢
- 路徑查詢
- 帶條件的節點過濾
- 從文章反查技能,或從技能反查文章
Query 不該只是語法練習
每個查詢都應該搭配一個具體問題,例如:
- 我已經會
FastAPI,下一步還能看哪些技術? - 哪些文章同時提到
Docker和Kubernetes? Hono和Python之間是透過哪些節點連起來的?
這樣讀者才會感受到:Cypher 不是新語法包袱,而是一種很直接的問資料方式。
Ch5:做一個完整的小型 demo
前四章拆開講概念,第五章就把東西串起來。
這一章的目標
做出一個真正能示範 lance-graph 價值的小專案。
demo 不需要很大
我反而覺得越小越好。
一個好的教學 demo 不需要 10 萬筆資料,只需要:
- schema 清楚
- query 有感
- 結果可解釋
demo 可以長這樣
一個技術學習圖譜:
- 技能之間有
RELATED_TO - 文章會
MENTIONS某些技能 - 技能屬於不同 category
讀者可以查:
- 某個技能周圍有哪些相近技術
- 某個主題有哪些文章可以看
- 某篇文章會把你帶到哪些下一步技能
如果這一章做得好,讀者看完就已經有能力自己做變體。
Ch6:往後怎麼延伸
第六章不用塞太多新技術,而是幫讀者看到下一步。
可以延伸的方向
- 更完整的知識圖譜
- 推薦系統
- 技術地圖
- 文件關聯探索
- 之後再接到 GraphRAG
這一章的定位不是再開新坑,而是讓讀者知道:
我現在學的不是孤立工具,
而是一個之後可以長出更多應用的基礎能力。
我想把這套系列做成什麼樣子?
如果順利,我希望它最後是一套很乾淨的教學組合:
- 一篇總綱文章
- 幾篇配套 blog
- 每一章一個 notebook 或 script
- 一個小而完整的 demo repo
理想的 repo 結構可以像這樣:
lance-graph-course/
├── README.md
├── data/
│ ├── skills.yaml
│ └── articles.jsonl
├── src/
│ ├── build_tables.py
│ ├── build_graph.py
│ ├── query_examples.py
│ └── demo.py
└── notebooks/
├── 01_intro.ipynb
├── 02_schema.ipynb
├── 03_build_graph.ipynb
└── 04_queries.ipynb
這樣整套東西就不只是文章,也不只是影片,而是一個真的能拿來學、拿來改、拿來展示的教學資產。
影片節奏怎麼安排比較好?
我會傾向每集都維持在 10 到 20 分鐘,避免一支影片塞太多東西。
比較適合的節奏是:
- 問題場景
- 觀念解釋
- 一小段實作
- 查詢結果解讀
- 下一集預告
這樣觀眾比較容易跟著跑,也比較容易在每一集結束時真的留下收穫。
結語
如果這套系列要成功,重點不是一次講很多,而是先把最重要的東西講清楚。
對 lance-graph 來說,那個最重要的東西不是某個華麗應用,而是這件事:
你怎麼把資料之間的關聯建模出來,並且把它變成可以查詢的結構。
只要這件事教清楚了,後面不管你要走向知識圖譜、推薦系統,還是 GraphRAG,都會順很多。
延伸閱讀
這篇文章是我對 lance-graph 教學系列的起點整理。先把資料模型、graph schema 和查詢講清楚,再慢慢往更大的應用延伸。
- ← Previous
Ch1:為什麼你的 RAG 需要 Skill Entity Graph?