Repository: mims-harvard/PINNACLE Stars: 109 · Forks: 26 · Language: Python · License: MIT 論文:Li et al., Contextual AI models for single-cell protein biology, Nature Methods (2024)(前身為 bioRxiv 2023.07.18.549602) 專案首頁:zitniklab.hms.harvard.edu/projects/PINNACLE Demo:huggingface.co/spaces/michellemli/PINNACLE 分類:Molecular & Protein Science(分子與蛋白質科學)
1. 專案概述 (Project Overview)
1.1 這個專案在解決什麼問題?
想像你要幫一間跨國公司畫一張「員工能力地圖」。傳統做法是:每個員工只有一張履歷,寫著「軟體工程師」、「五年經驗」,不管他被派去台北分公司做後端開發、還是被派去矽谷分公司帶新創團隊,履歷上的描述都一樣。但任何一個懂人資的人都知道,同一個人在不同的組織情境 (context; 情境) 裡,展現出來的能力、扮演的角色、甚至他跟同事互動的方式都截然不同——在台北他可能是資深導師,在矽谷他可能還在摸索文化差異中的新人。如果你的「能力地圖」完全忽略了這個情境差異,只給每個人一張「通用履歷」,那這張地圖對於「該把誰派去哪裡救火」這種決策幾乎沒有參考價值。
蛋白質在人體裡的處境,其實跟這個比喻驚人地相似。同一個蛋白質(比方說 TP53 這個抑癌基因編碼的蛋白質)在肝臟細胞裡、在免疫 T 細胞裡、在腦部神經元裡,它會跟哪些其他蛋白質互動、扮演什麼功能角色,其實是不一樣的——這種現象在生物學上稱為蛋白質的情境依賴功能 (context-dependent protein function; 情境依賴蛋白質功能)。但過去二十年,計算生物學界用來表徵蛋白質的主流做法(不管是傳統的蛋白質互動網路 (protein-protein interaction network, PPI; 蛋白質交互作用網路) 分析,還是近年的圖神經網路嵌入方法),幾乎都是把「一個蛋白質」對應到「一組固定的數值向量」——就像那張通用履歷,不管這個蛋白質此刻身處哪個細胞、哪個組織,它的數字表徵永遠一樣。
PINNACLE 要解決的正是這個「情境失憶症」問題。PINNACLE 是 Protein-cell type-tissue network model 的簡稱,它訓練出的不是「一個蛋白質一個向量」,而是「一個蛋白質在每一種它出現過的細胞類型情境下,各有一個向量」——同一個蛋白質可能在 156 種不同的細胞類型情境裡,各自擁有一份「因地制宜」的表徵。這就好比幫每一位員工做了 156 份「情境化履歷」,每一份都精確描述他在那個特定分公司、特定團隊裡展現出的真實能力樣貌。
用更技術的語言來說:PINNACLE 是一個幾何深度學習 (geometric deep learning; 幾何深度學習) 模型,它同時對三種尺度的生物網路做自我監督學習 (self-supervised learning; 自我監督學習)——(1) 蛋白質互動網路(分子尺度)、(2) 細胞類型異質性網路(細胞尺度)、(3) 組織/器官的層級關係(組織尺度)——並把三者統一到同一個嵌入空間 (embedding space; 嵌入空間) 裡。最終產出 394,760 個蛋白質表徵,橫跨 156 種細胞類型情境、24 種組織/器官,全部來自一個涵蓋人體多器官的單細胞轉錄體圖譜 (single-cell transcriptomic atlas; 單細胞轉錄體圖譜)。
1.2 為什麼「情境感知」在生醫 AI 領域這麼重要?
如果你只是想知道「A 蛋白質跟 B 蛋白質會不會結合」,情境感知也許不是必需品——結構生物學層面的物理結合,很多時候確實不太在乎細胞情境。但只要你的問題稍微往下游走一步,變成「這個藥物靶點在哪個組織、哪種細胞裡最值得下手」、「這個藥物在心肌細胞裡的副作用機轉是什麼」,情境感知立刻變成不可迴避的核心問題。這正是 PINNACLE 論文特別關注的應用場景:
- 精準藥物靶點篩選:許多藥物開發失敗,不是因為靶點分子機制錯了,而是因為靶點在「不該作用的細胞類型」裡也被打到,引發副作用;或者藥物在「該起作用的細胞類型」裡表現力不足。PINNACLE 讓研究者能問一個更精確的問題:「這個候選靶點在發炎相關的滑膜纖維母細胞 (synovial fibroblast; 滑膜纖維母細胞) 裡是什麼樣子,跟它在一般結締組織細胞裡有什麼不同?」
- 藥物基因體效應的情境解讀:藥物進入人體後,會在不同組織引發不同的基因表現變化。PINNACLE 論文示範了如何微調模型,讓其在多種細胞情境下比較藥物的基因體效應,找出「哪種細胞類型的反應最能預測藥物療效」。
- 零樣本組織層級檢索 (zero-shot tissue hierarchy retrieval; 零樣本組織層級檢索):PINNACLE 訓練完成後,即使沒有針對「組織分類」這個任務額外訓練,它產生的組織嵌入向量依然能重建出人體組織的解剖層級關係(例如「小腸」跟「大腸」的嵌入距離,應該比「小腸」跟「腦」的嵌入距離更近)。這說明模型確實學到了有意義的生物組織結構,不是隨機的數字。
- 臨床轉譯導向的目標提名 (therapeutic target nomination; 治療靶點提名):論文團隊實際針對類風濕性關節炎 (rheumatoid arthritis, RA; 類風濕性關節炎) 和發炎性腸道疾病 (inflammatory bowel disease, IBD; 發炎性腸道疾病) 這兩個真實臨床適應症做微調,結果顯示 PINNACLE 提名的候選靶點,比起不考慮情境的傳統方法,跟已知藥物靶點的重疊度更高——這代表這種「情境感知」不只是理論上優雅,在實際藥物開發漏斗裡也有實用價值。
在生醫 AI 版圖裡,PINNACLE 代表了一種重要的方法論轉向:從「蛋白質功能是靜態、通用的」這種簡化假設,走向「蛋白質功能是動態、情境依賴的」這種更貼近生物真實性的建模範式。這個轉向不只發生在蛋白質層級——近年單細胞基因體學 (single-cell genomics; 單細胞基因體學) 的爆炸性發展,讓「情境感知」幾乎變成整個計算生物學界的共同方向,PINNACLE 是把這個方向系統性地帶入蛋白質交互作用建模領域的早期代表作之一。
1.3 相關發表論文與引用
- 主論文:Li, M. M., Huang, Y., Sumathipala, M., Liang, M. Q., Valdeolivas, A., Ananthakrishnan, A. N., Liao, K., Marbach, D., & Zitnik, M. (2024). Contextual AI models for single-cell protein biology. Nature Methods, 1–12.
- 前身預印本:同標題,2023 年 7 月上線於 bioRxiv,DOI: 10.1101/2023.07.18.549602。從預印本到正式發表於 Nature Methods 歷經約一年的同儕審查,反映這項工作在方法學上經過相對嚴格的驗證。
- 資料集:訓練用的網路資料與預訓練嵌入,發佈於 Figshare。
- 共同作者的臨床背景:論文團隊納入了消化系內科(IBD 專科)與風濕免疫科的臨床合作者,這在計算生物學論文中並不常見,反映出這項工作從設計之初就有意識地朝著「臨床可轉譯」的方向靠攏,而不只是純方法學展示。
- 截至本文撰寫時,GitHub star 數為 109、fork 數 26,屬於在計算生物學領域有穩定關注度、但尚未成為業界標配工具的中型專案規模。
1.4 在 mims-harvard 實驗室生態系中的角色
PINNACLE 出自 Marinka Zitnik 教授主持的 Zitnik Lab(哈佛醫學院生物醫學資訊系)。這個實驗室的研究主軸長期圍繞著「如何用圖結構化的機器學習方法理解生物醫學系統」,PINNACLE 在這個脈絡下扮演的角色,可以放進一條清晰的技術演進軸線來理解:
- Decagon(該實驗室較早期的作品)處理的是藥物-藥物交互作用預測,用的是「多重關係圖 (multi-relational graph; 多重關係圖)」的概念,但沒有考慮細胞或組織情境;
- PrimeKG 建構的是跨越 10 個生醫資料來源、統一格式的知識圖譜,提供的是「關係型知識」的骨架,本身不含蛋白質的數值表徵學習;
- TxGNN 專注於零樣本藥物重定位 (zero-shot drug repurposing; 零樣本藥物重定位),是「藥物-疾病」關係層級的推理引擎;
- PINNACLE 補上的是「蛋白質表徵要不要考慮情境」這個更底層卻長期被忽視的問題,可以視為把「情境感知」這個設計哲學,從網路關係層級(如 Decagon、TxGNN 處理的藥物-疾病關係),下沉到蛋白質表徵本身這個更基礎的層級;
- 更晚近的 ATOMICA 則是把情境感知的顆粒度再往下推進一層——從「哪個細胞類型」的情境,推進到「哪個原子交互作用介面」的情境,兩者的方法論精神一脈相承,都是「拒絕用一個通用向量代表一個生物實體」的立場。
換句話說,如果你把 Zitnik Lab 的產出線畫成一條光譜,一端是「巨觀的疾病-藥物關係圖譜」(PrimeKG、TxGNN、Decagon),另一端是「微觀的原子交互作用」(ATOMICA),PINNACLE 恰好卡在中間的「細胞情境」這一格——它既不是純粹的關係推理,也不是原子級的結構建模,而是聚焦在「同一個分子在不同細胞裡的多重身分」這個特殊而關鍵的中間層級。
1.5 專案定位圖
flowchart TB subgraph SG_MACRO["巨觀層:疾病與藥物關係圖譜"] PRIMEKG["PrimeKG
生醫知識圖譜骨架"] TXGNN["TxGNN
零樣本藥物重定位"] DECAGON["Decagon
藥物-藥物交互作用"] end subgraph SG_MESO["中觀層:細胞情境化的蛋白質表徵"] PINNACLE["PINNACLE
情境感知蛋白質嵌入"] end subgraph SG_MICRO["微觀層:原子尺度的分子交互作用"] ATOMICA["ATOMICA
原子解析度交互作用嵌入"] end subgraph SG_INPUT["PINNACLE 的資料輸入"] TS["Tabula Sapiens
多器官單細胞轉錄體圖譜"] PPI["全局蛋白質交互作用網路"] CPDB["CellPhoneDB
細胞-細胞通訊分析"] end TS --> PINNACLE PPI --> PINNACLE CPDB --> PINNACLE PINNACLE -.可作為節點特徵注入.-> TXGNN PINNACLE -.可作為節點特徵注入.-> PRIMEKG ATOMICA -.互補:原子級介面細節.-> PINNACLE DECAGON -.早期奠基.-> PINNACLE style PINNACLE fill:#DC2626,color:#F8FAFC style TS fill:#2563EB,color:#F8FAFC style PPI fill:#2563EB,color:#F8FAFC style CPDB fill:#2563EB,color:#F8FAFC
1.6 一個更貼近生活的比喻:機場的「情境化身分」
再換一個比喻幫助理解。想像一個機場地勤人員——他在「報到櫃檯」情境下,是幫旅客托運行李、核對證件的服務者;在「登機門」情境下,是引導旅客排隊、廣播航班資訊的協調者;在「行李轉盤」情境下,又變成處理行李遺失、協調地面作業的問題解決者。這是同一個人,但他的行為模式、跟周遭人事物的互動方式,完全隨著他所處的「情境」而變化。傳統的蛋白質表徵方法,就像只給這個地勤人員一張寫著「機場員工」的識別證,不管他在哪個情境都用同一張識別證來描述他——資訊量太粗糙,無法支撐「派誰去處理行李遺失事件」這種需要情境細節的決策。PINNACLE 做的事,就是幫這個地勤人員準備三張不同的識別證(報到櫃檯版、登機門版、行李轉盤版),每一張都精確反映他在那個情境下真正在做的事。
1.7 涵蓋的資料規模一覽
| 項目 | 規模 |
|---|---|
| 蛋白質-情境表徵總數 | 394,760 |
| 涵蓋細胞類型情境數 | 156 |
| 涵蓋組織/器官數 | 24 |
| 單細胞轉錄體資料來源 | Tabula Sapiens(多器官人類單細胞圖譜) |
| 細胞-細胞通訊分析工具 | CellPhoneDB |
| 微調驗證的臨床適應症 | 類風濕性關節炎(EFO_0000685)、發炎性腸道疾病(EFO_0003767) |
1.8 核心術語速查表
| 術語 | 英文 | 說明 |
|---|---|---|
| 全局參考網路 | Global reference PPI network | 不分細胞情境的通用蛋白質交互作用網路,是所有細胞類型子網路的「母體」 |
| 細胞類型特異性 PPI | Cell type specific PPI network | 從全局網路中,依據該細胞類型的單細胞表現量排序篩選出的子網路 |
| 元圖 | Metagraph | 描述細胞類型之間、細胞類型與組織之間關係的上層網路 |
| 上池化 / 下池化 | Up-pooling / Down-pooling | PINNACLE 架構中,資訊從蛋白質層級彙聚到細胞類型/組織層級(上池化),再從細胞類型層級傳回蛋白質層級(下池化)的雙向資訊流動機制 |
| 中心損失 | Center loss | 強迫同一細胞類型情境下的蛋白質表徵,向該情境的「中心點」靠攏的損失函數 |
| 零樣本檢索 | Zero-shot retrieval | 模型未經該任務的直接監督訓練,仍能完成該任務的能力 |
1.9 研究團隊背景與臨床轉譯脈絡
PINNACLE 的作者名單裡除了計算方法學專家(Michelle M. Li 為第一作者,長期在 Zitnik Lab 從事圖神經網路方法研究),還包含消化系內科與風濕免疫科的臨床專家,以及具備藥廠背景的計算生物學家。這種「方法學家 + 臨床專家 + 產業界」三方合作的作者結構,直接反映在論文的驗證設計上——選擇 RA 與 IBD 作為微調驗證的兩個適應症,而不是選擇「隨便一個資料充足的疾病」,正是因為團隊中有這兩個領域的臨床專家可以提供領域知識校驗模型輸出是否合理。這對於評估一個計算方法論文的可信度是重要的訊號:當方法學論文的驗證場景是由該領域臨床專家共同設計時,其結論的臨床相關性通常比純資料驅動的驗證更值得信賴。
1.10 專案健康度指標解讀
109 顆星、26 個 fork,對於一個 2024 年才在 Nature Methods 正式發表的計算生物學方法論文配套程式碼而言,是相對健康但仍屬「小眾工具」的規模——這類工具的採用曲線通常較長,因為使用者需要先具備單細胞資料處理與圖神經網路訓練的雙重背景知識,門檻明顯高於一般的資料分析腳本。MIT 授權條款代表商業與學術使用都不受限制,這對於希望在藥物開發流程中採用該方法的產業使用者而言是友善的授權選擇。26 個 fork 對 109 個 star 的比例(約 24%)偏高,通常暗示這個 repo 被不少人拿去做二次開發或改寫,而不只是「加星收藏」,這與 PINNACLE 提供了完整的微調範例程式碼(finetune_pinnacle/)、方便使用者直接套用到自己的資料集這件事相符。
2. 核心架構 (Core Architecture)
2.1 三層次網路輸入:從單細胞資料到訓練用圖結構
PINNACLE 的訓練資料不是「憑空存在」的,而是經過一套完整的前處理管線 (data_prep/ 目錄) 從原始單細胞轉錄體資料一步步構建出來的。理解這條前處理管線,是理解 PINNACLE「為什麼知道每個蛋白質屬於哪個情境」的關鍵。
flowchart TB A["Tabula Sapiens
多器官單細胞轉錄體 AnnData (.h5ad)"] --> B["0.constructPPI.py -rank True
對每個細胞類型的基因做差異表現排序"] B --> C["輸出:每個細胞類型的
基因排序表 + p-value 表"] C --> D["0.constructPPI.py -rank False
依 p-value 與基因數門檻篩選"] D --> E["輸出:每個細胞類型的
顯著表現基因清單"] E --> F["從全局參考 PPI 網路中
抽取對應子圖"] F --> G["1.evaluatePPI.py
驗證抽取出的子網路品質"] G --> H["細胞類型特異性 PPI 網路
(156 個子網路)"] A --> I["2.prepCellPhoneDB.py
準備配體-受體分析輸入"] I --> J["3.run_cellphonedb.sh
CellPhoneDB 細胞-細胞通訊分析"] J --> K["4.constructCCI.py
建構細胞-細胞交互作用邊"] H --> L["5.constructMG.py
整合細胞類型關係+組織層級+CCI 邊"] K --> L L --> M["元圖 (Metagraph)
細胞類型-組織層級網路"] H --> N["pinnacle/train.py"] M --> N P["全局參考 PPI edgelist"] --> N N --> O["PINNACLE 模型訓練"] style A fill:#2563EB,color:#F8FAFC style H fill:#DC2626,color:#F8FAFC style M fill:#DC2626,color:#F8FAFC style O fill:#B91C1C,color:#F8FAFC
這條管線的關鍵洞察是:「細胞類型特異性」並不是靠人工標註,而是靠統計方法從單細胞表現量資料中「反推」出來的。具體來說,0.constructPPI.py 先對 Tabula Sapiens 圖譜裡每一種細胞類型(如 cell_ontology_class 欄位所標註)跑差異表現分析,找出「在這個細胞類型裡顯著高表現」的基因,再用一個雙重篩選條件(p-value 門檻、最大基因數上限,預設為 4000 個基因)決定哪些基因夠格代表這個細胞類型。這份基因清單接著被用來從「全局參考 PPI 網路」中抽取子圖——如果 A 蛋白質和 B 蛋白質都出現在某細胞類型的顯著基因清單裡,且兩者在全局網路裡本來就有一條邊,這條邊就會被保留到該細胞類型的子網路裡。
而元圖 (metagraph) 這一層的建構同樣有趣:它不只是「細胞類型屬於哪個組織」這種靜態的層級標註,還融合了 CellPhoneDB 分析出來的細胞-細胞通訊證據——也就是說,如果 A 細胞類型分泌的配體 (ligand; 配體) 會被 B 細胞類型表面的受體 (receptor; 受體) 接收,這種真實存在的細胞間通訊關係,也會反映在元圖的邊結構上。這代表 PINNACLE 學到的「情境」不只是解剖學上的位置關係,還包含了功能性的細胞間溝通關係。
2.2 異質圖的三種節點類型
前處理管線的輸出,最終匯聚成一個異質圖 (heterogeneous graph; 異質圖),包含三種本質不同的節點:
- 蛋白質-情境節點 (protein-context node):注意這裡的關�键設計——同一個蛋白質(比方說 TP53)如果出現在 10 個不同的細胞類型子網路裡,它就會被實例化成 10 個不同的節點,而不是共用一個節點。這正是 PINNACLE 能產生「情境化表徵」而非「通用表徵」的架構根源。
- 細胞類型節點 (cell type node):代表 156 種細胞類型本身的抽象實體節點,用來彙聚該細胞類型內所有蛋白質-情境節點的訊息。
- 組織節點 (tissue node):代表 24 種組織/器官,是元圖裡的上層節點,彙聚屬於該組織的所有細胞類型節點的訊息。
2.3 模型架構:雙向池化的兩層卷積網路
從 pinnacle/model.py 的實際程式碼可以看到,PINNACLE 的核心模型類別 Pinnacle 由兩個堆疊的「複合層」構成,每個複合層內部又拆成上池化 (PCTConv,Protein-Celltype-Tissue Conv) 與下池化 (PPIConv) 兩個子模組:
flowchart TB subgraph SG_LAYER1["複合層 #1"] A1["蛋白質-情境節點特徵
(隨機高斯向量, 2048 維初始化)"] --> B1["PCTConv 上池化
蛋白質→細胞類型→組織"] B1 --> C1["更新後的元圖節點特徵"] C1 --> D1["PPIConv 下池化
細胞類型→蛋白質"] D1 --> E1["更新後的蛋白質-情境節點特徵"] E1 --> F1["LayerNorm + LeakyReLU
+ BatchNorm + Dropout"] end subgraph SG_LAYER2["複合層 #2"] A2["來自複合層 #1 的輸出"] --> B2["PCTConv 上池化"] B2 --> C2["更新後的元圖節點特徵"] C2 --> D2["PPIConv 下池化"] D2 --> E2["最終蛋白質-情境嵌入
+ 最終細胞類型/組織嵌入"] end F1 --> A2 style A1 fill:#2563EB,color:#F8FAFC style E2 fill:#DC2626,color:#F8FAFC
有幾個架構細節值得特別說明,因為它們直接體現了 PINNACLE 的設計哲學:
- 初始特徵是隨機的,不是有生物意義的向量:這是一個容易被忽略但重要的設計選擇——每個蛋白質-情境節點的初始輸入特徵是一組隨機高斯向量 (
feat_mat=2048),而不是像許多其他蛋白質嵌入方法那樣,拿蛋白質序列的 one-hot 編碼或既有的預訓練嵌入當輸入。這個選擇背後的邏輯是:PINNACLE 想學到的,是「網路拓樸結構」和「情境歸屬關係」所蘊含的資訊,而不是想重新編碼蛋白質的胜肽序列特徵。換句話說,PINNACLE 本質上更接近圖結構嵌入方法(如 node2vec 的精神),只是用了更複雜的異質圖注意力機制,而不是序列語言模型的路線。 - 上池化與下池化的雙向設計:
PCTConv負責把資訊從蛋白質層級「向上」彙聚到細胞類型與組織層級(同時也讓細胞類型/組織的表徵反過來影響自己),PPIConv則負責把彙聚後的細胞類型層級資訊「向下」傳回給蛋白質節點,更新蛋白質在該情境下的表徵。這種雙向流動確保了「蛋白質影響細胞類型的整體樣貌」和「細胞類型情境影響蛋白質的個體表徵」這兩個方向的因果關係都被模型捕捉到,而不是單向的訊息傳遞。 - 多頭注意力貫穿全模型:
n_heads=8個注意力頭同時運作於蛋白質層級,sem_att_channels=8個語意注意力通道用於處理元圖裡不同關係類型(如「屬於同一組織」vs.「有細胞通訊證據」)的權重分配,pc_att_channels則專門處理蛋白質-細胞類型跨層級的注意力。這種多層次的注意力設計,正是論文摘要中提到的「蛋白質層級、細胞類型層級、組織層級的注意力機制」的具體實現方式。
2.4 目標函數:三種力量塑造嵌入空間
PINNACLE 的訓練目標由多個損失函數協同構成,對應論文摘要中「讓有邊的節點靠近、讓同細胞類型的蛋白質靠近、讓蛋白質靠近其細胞類型」這三個直覺:
| 損失來源 | 對應直覺 | 相關超參數 |
|---|---|---|
連結預測損失 (BCE, 對應 loss.py) | 在網路裡有邊相連的節點對,嵌入應該相近 | theta(PPI 損失權重),loss_type="BCE" |
中心損失 (center_loss.py) | 同一細胞類型情境下的蛋白質,應該向該情境的「中心」靠攏,遠離其他情境的中心 | lmbda(中心損失整體權重),lr_cent(中心點自身的學習率) |
| 元圖關係解碼損失 | 細胞類型與組織之間的層級/通訊關係應該被正確重建 | mg_relw(元圖關係權重矩陣,以 Xavier 初始化) |
值得注意的是lr_cent(中心點學習率)是一個獨立於主模型的學習率,這代表「每個細胞類型情境的中心點在嵌入空間裡的位置」本身也是可學習的參數,而不是訓練前就固定算好的統計量(如簡單平均值)——這讓中心點可以隨著訓練動態調整,找到真正能區分不同情境的最佳位置,而不受限於初始嵌入分佈的雜訊。
2.5 資料流向圖:一次完整訓練迴圈的生命週期
sequenceDiagram participant U as 使用者 participant T as train.py participant M as Pinnacle 模型 participant L as Loss 模組 participant S as save_prefix 輸出 U->>T: 指定 --G_f --ppi_dir --mg_f T->>T: 讀入 156 個細胞類型 PPI 子圖
+ 元圖 + 全局參考網路 T->>T: 以 GraphSAINT 或 Neighbor Loader
做子圖採樣 minibatch loop 每個 epoch (預設 300 次) T->>M: 送入採樣後的蛋白質特徵+邊 M->>M: 複合層1: 上池化+下池化 M->>M: 複合層2: 上池化+下池化 M->>L: 輸出蛋白質/細胞類型/組織嵌入 L->>L: 計算 BCE 連結損失+中心損失+元圖解碼損失 L->>M: 反向傳播更新權重 end T->>S: 儲存最終嵌入 (.pth/.pkl)
與模型 checkpoint U->>S: 讀取嵌入做下游分析或視覺化
2.6 三種嵌入輸出的意義
訓練完成後,PINNACLE 產出三類嵌入向量,各自對應不同的分析用途:
- 蛋白質-情境嵌入:394,760 個向量,每個代表「某蛋白質在某細胞類型情境下」的樣貌,是下游微調任務(如靶點提名)最主要使用的表徵。
- 細胞類型嵌入:156 個向量,代表整個細胞類型的整體樣貌,可用於比較不同細胞類型之間的相似性(例如,兩種都參與免疫反應的細胞類型,嵌入距離應該較近)。
- 組織嵌入:24 個向量,代表組織/器官層級的整體樣貌,論文用這組嵌入做零樣本組織層級檢索的驗證。
2.7 微調階段的架構銜接:凍結表徵 + 輕量分類器
微調 (finetune_pinnacle/model.py) 階段完全不會重新訓練上述的圖神經網路主體——PINNACLE 的預訓練嵌入被視為固定不變的特徵輸入,微調只訓練一個相對輕量的下游分類器(依據 setup.py 裡的預設超參數,是一個 2 層的 MLP,hidden_dim_1=64、hidden_dim_2=32,hidden_dim_3=0 代表可選的第三層預設關閉)。這種「凍結預訓練表徵 + 輕量下游頭」的設計,跟 BERT/GPT 類語言模型的微調範式(fine-tuning a frozen backbone)在精神上完全一致,只是這裡的「backbone」是一個圖神經網路,不是 Transformer。
這個架構選擇有一個重要的實務意義:微調速度極快、GPU 需求極低,因為真正吃運算資源的圖神經網路訓練只需要做一次(產出通用的情境化嵌入),之後任何新的下游任務(不同疾病、不同靶點提名場景)都只需要在幾百維的向量上訓練一個小型分類器,幾乎可以在筆記型電腦的 CPU 上完成。
2.8 內部元件互動總覽
flowchart LR subgraph SG_PRETRAIN["預訓練階段(一次性、重運算)"] DP["data_prep/
五步驟前處理管線"] --> PN["pinnacle/
雙層 PCTConv+PPIConv"] PN --> EMB["pinnacle_embeds/
三類嵌入輸出"] end subgraph SG_FINETUNE["微調階段(重複執行、輕運算)"] EMB --> FP["finetune_pinnacle/
data_prep.py 切分資料"] FP --> FT["finetune_pinnacle/
train.py 訓練 MLP 分類器"] FT --> RES["靶點提名結果
(每種疾病一份)"] end subgraph SG_EVAL["評估與視覺化"] EMB --> VIS["evaluate/
visualize_representations.py"] RES --> METRIC["evaluate/
evaluate_target_prioritization.py"] end style PN fill:#DC2626,color:#F8FAFC style EMB fill:#B91C1C,color:#F8FAFC
2.9 為什麼選擇「異質圖注意力」而非簡單的圖卷積
一個容易被問到的設計問題是:為什�麼不直接用最簡單的 GCN (Graph Convolutional Network) 處理這個問題?答案在於這個問題本質上是多重異質關係的:蛋白質-蛋白質邊、細胞類型-蛋白質的歸屬關係、細胞類型-細胞類型的通訊關係、細胞類型-組織的層級關係,這四種關係的語意完全不同,不能用同一組卷積權重去處理。這也是為什麼模型裡有 num_ppi_relations 和 num_mg_relations 兩組獨立的關係類型參數,以及 sem_att_channels(語意注意力通道)專門用來學習「不同關係類型該被賦予多少權重」——這正是異質圖神經網路 (heterogeneous graph neural network; 異質圖神經網路) 領域的標準做法,而不是簡單套用同質圖 (homogeneous graph) 的方法論。
2.10 GraphSAINT 採樣:為什麼百萬級節點的圖需要特殊的 minibatch 策略
394,760 個蛋白質-情境節點,加上邊的數量,構成的圖遠遠超過一般 GPU 記憶體能一次性放入的規模。這也是為什麼 train.py 的 --loader 參數提供 graphsaint(預設)和 neighbor 兩種選擇——GraphSAINT (Graph SAmpling based INductive learning meThod) 是一種專門為大規模圖神經網路訓練設計的子圖採樣方法,它會先對整張圖做重要性採樣,抽取出一個「小而有代表性」的子圖來做一次前向/反向傳播,而不是把整張圖硬塞進記憶體。這個技術細節解釋了為什麼 PINNACLE 儘管規模龐大,依然能在合理的硬體資源下完成訓練——這是大規模圖神經網路工程實踐裡一個相當重要卻常被忽略的基礎設施選擇。
3. 安裝與設定 (Installation & Setup)
3.1 前置需求
PINNACLE 的技術堆疊建立在 PyTorch 生態系之上,前置需求如下:
- Conda:官方安裝方式完全依賴 conda 環境管理,建議先確認系統已安裝 Miniconda 或 Anaconda。
- GPU(強烈建議):預訓練階段需要處理近 40 萬個節點的異質圖,雖然作者提供了預訓練好的 checkpoint(可跳過訓練直接用),但若打算重新訓練或在自己的網路資料上訓練,沒有 GPU 幾乎不可行。
- 磁碟空間:Figshare 上的資料集(全局 PPI 網路、156 個細胞類型子網路、元圖、預訓練嵌入)加總起來屬於中大型資料集,建議預留至少 10-20 GB 空間。
- Python 版本:由
environment.yml決定,建議直接使用該檔案建立環境而非手動指定版本,避免 PyTorch Geometric 相依版本衝突。
3.2 逐步安裝指南
步驟一:下載 repository
1git clone https://github.com/mims-harvard/PINNACLE
2cd PINNACLE
步驟二:建立並啟用 conda 環境
1conda env create -f environment.yml
2conda activate pinnacle
3bash install_pyg.sh
這裡值得留意的是,PyTorch Geometric (PyG) 的安裝被拆成獨立的 install_pyg.sh 腳本執行,而不是直接寫進 environment.yml——這是因為 PyG 的相依套件(如 torch-scatter、torch-sparse)必須嚴格對應到已安裝的 PyTorch 版本與 CUDA 版本,用一般的 conda/pip 解析器很容易裝錯 wheel。若在此步驟遇到問題,建議先確認 nvidia-smi 顯示的 CUDA 版本,再對照 PyG 官方安裝矩陣 手動調整 install_pyg.sh 內指定的版本號。
步驟三:下載資料集
資料放在 Figshare(DOI 連結),下載時務必選取所有檔案並保持原始目錄結構,下載後記得解壓縮所有 .zip。資料包含:
- 全局參考蛋白質交互作用網路(edgelist 格式)
- 156 個細胞類型特異性 PPI 網路
- 元圖(細胞類型-組織關係網路)
如果你想用自己的資料集訓練,data_prep/README.md 有詳細規範,關鍵格式要求是:每個細胞類型子網路必須是「tab 分隔的表格,每行代表一個情境,依序包含索引、情境名稱、以逗號分隔的節點清單」。
步驟四(可選):下載預訓練 checkpoint
同樣在 Figshare 上,可以下載已經訓練完成的模型 checkpoint 與嵌入向量。強烈建議大多數使用者從這裡開始,除非你的研究目的是驗證訓練流程本身或在全新的資料上重新預訓練——這能省下數小時到數天的 GPU 訓練時間。
3.3 環境設定注意事項
- 記憶體規劃:即使使用 GraphSAINT 採樣,異質圖的節點特徵矩陣(每個節點 2048 維隨機初始特徵)本身就佔用相當可觀的記憶體,建議至少 32GB 系統記憶體 + 16GB 以上顯示卡記憶體用於訓練。若只做微調(凍結嵌入 + 訓練 MLP),記憶體需求則大幅降低,一般消費級筆電即可應付。
- 隨機種子:微調腳本提供
--random_state參數(預設 1)與--random開關(關閉固定種子做多次隨機重跑),建議在正式分析前先跑幾次不同種子確認結果穩定性,而不是只信任單次隨機種子的結果。 - CellPhoneDB 獨立環境:如果打算重新跑資料前處理管線(而非直接使用作者提供的網路資料),
data_prep/3.run_cellphonedb.sh需要額外建立一個獨立的 conda 環境(cpdb,Python 3.7 +pip install cellphonedb),因為 CellPhoneDB 的相依版本跟 PINNACLE 主環境不相容。這是多環境協作專案常見的設計模式,值得在規劃時間表時預先納入考量。
3.4 驗證安裝是否成功
1# 驗證 PyTorch 與 PyTorch Geometric 是否正確安裝且能偵測到 GPU
2python -c "
3import torch
4import torch_geometric
5print('PyTorch version:', torch.__version__)
6print('PyTorch Geometric version:', torch_geometric.__version__)
7print('CUDA available:', torch.cuda.is_available())
8"
1# 驗證能否成功載入模型定義(不需要 GPU 也能跑通這一步)
2cd pinnacle
3python -c "
4from model import Pinnacle
5print('Pinnacle 模型類別載入成功:', Pinnacle)
6"
若上述兩段程式都能無錯誤執行,代表核心依賴安裝正確,可以進入下一節的資料下載與基本使用流程。
3.5 常見安裝陷阱
| 問題現象 | 可能原因 | 解決方向 |
|---|---|---|
torch-scatter 編譯失敗 | PyG 相依套件版本與已安裝 PyTorch/CUDA 版本不符 | 對照官方 wheel 索引手動指定版本,勿用 pip install torch-scatter 裸裝 |
| Figshare 下載後目錄結構錯亂 | 未一次性選取全部檔案下載,或漏解壓某個子資料夾 | 重新下載並確認目錄樹與 README 描述一致 |
| CellPhoneDB 步驟報 Python 版本錯誤 | 誤在 pinnacle 主環境執行,而非獨立的 cpdb 環境 | 依 data_prep README 建立獨立 conda 環境 |
| GraphSAINT 採樣時記憶體爆滿 | 系統記憶體不足以放入完整異質圖的特徵矩陣 | 改用 --loader neighbor,或先在較小的細胞類型子集上測試流程 |
4. 基本使用 (Basic Usage)
4.1 快速入門:三條路徑
PINNACLE 的使用場景大致分成三條路徑,依照你的目的選擇最短的一條:
flowchart TB
START["我想使用 PINNACLE"] --> Q1{"我有自己的
下游任務資料嗎?"}
Q1 -->|有,想直接微調| P1["路徑一:直接微調
下載作者預訓練 checkpoint
用 finetune_pinnacle/"]
Q1 -->|沒有,只想探索表徵| P2["路徑二:視覺化探索
下載預訓練嵌入
用 evaluate/visualize_representations.py"]
Q1 -->|我有全新的 PPI 資料
想重新訓練| P3["路徑三:從頭訓練
準備自己的三層網路資料
用 pinnacle/train.py"]
style P1 fill:#2563EB,color:#F8FAFC
style P2 fill:#059669,color:#F8FAFC
style P3 fill:#DC2626,color:#F8FAFC
對絕大多數想要「應用」PINNACLE 而非「研究其方法論本身」的使用者,路徑一是最常見也最推薦的起點——因為預訓練這一步已經由作者在龐大的多器官單細胞資料上完成,重新訓練通常沒有必要,除非你的研究對象是完全不同的物種、或想納入作者資料集裡沒有的組織/細胞類型。
4.2 範例工作流一:從零開始的靶點提名分析
假設情境:你是一位免疫學研究者,想知道 PINNACLE 對類風濕性關節炎能提名出哪些候選治療靶點,並且想理解整個流程的輸入輸出格式。
第一步:確認磁碟上已有的資源
1ls data/pinnacle_embeds/
2# 預期看到類似:
3# pinnacle_protein_embed.pth
4# pinnacle_celltype_embed.pth
5# pinnacle_tissue_embed.pth
第二步:執行微調訓練
1cd finetune_pinnacle
2python train.py \
3 --disease EFO_0000685 \
4 --embeddings_dir ./data/pinnacle_embeds/
這裡的 EFO_0000685 是類風濕性關節炎在 Experimental Factor Ontology (EFO) 裡的標準識別碼,也是 OpenTargets 平台用來標註「疾病-基因關聯證據」的識別系統。訓練腳本內部會依這個疾病 ID,從 OpenTargets 既有的證據資料裡拉出「已知與此疾病相關的蛋白質」作為正樣本,並取樣其他蛋白質作為負樣本,在凍結的 PINNACLE 嵌入上訓練一個分類器來學習「什麼樣的情境化蛋白質表徵,傾向於是治療靶點」。
第三步:檢視輸出
1ls tmp_evaluation_results/
2ls tmp_model_outputs/
輸出包含每個候選蛋白質在特定細胞類型情境下被模型判定為「潛在治療靶點」的分數,研究者可以依分數排序,結合臨床知識篩選出最值得進一步濕實驗驗證的候選者與細胞情境組合。
4.3 範例工作流二:比較不同疾病的靶點提名結果
1cd finetune_pinnacle
2
3# 類風濕性關節炎
4python train.py \
5 --disease EFO_0000685 \
6 --embeddings_dir ../data/pinnacle_embeds/ \
7 --metrics_output_dir ./results_RA/ \
8 --models_output_dir ./models_RA/
9
10# 發炎性腸道疾病
11python train.py \
12 --disease EFO_0003767 \
13 --embeddings_dir ../data/pinnacle_embeds/ \
14 --metrics_output_dir ./results_IBD/ \
15 --models_output_dir ./models_IBD/
透過分別指定不同的 --metrics_output_dir,可以避免兩次執行的結果互相覆蓋,方便後續交叉比較兩種疾病提名出的靶點在細胞情境分佈上是否有系統性差異(例如,RA 提名的靶點是否更集中在滑膜相關的細胞類型,IBD 提名的靶點是否更集中在腸道上皮相關的細胞類型)。
4.4 範例工作流三:視覺化蛋白質表徵的細胞情境結構
1cd evaluate
2python visualize_representations.py \
3 --embeddings_dir ../data/pinnacle_embeds/ \
4 --output_dir ./viz_output/
這個腳本通常會產出類似 UMAP 或 t-SNE 的降維視覺化圖,讓使用者用肉眼確認:「同一種細胞類型的蛋白質表徵,是否真的在嵌入空間裡聚在一起?」以及「相近的細胞類型(如不同種類的免疫細胞),是否比不相關的細胞類型(如免疫細胞 vs. 神經元)在嵌入空間裡更靠近?」——這是驗證模型是否學到有意義結構的最直觀方式,也是任何要在正式分析前建立信心的必經步驟。
4.5 輸入/輸出格式規範一覽
| 資料類型 | 格式 | 範例內容 |
|---|---|---|
全局 PPI 網路 (--G_f) | Edgelist(每行一條邊) | TP53\tMDM2 |
細胞類型 PPI 網路目錄 (--ppi_dir) | 每個細胞類型一個 edgelist 檔 | T_cell.txt、hepatocyte.txt … |
元圖 (--mg_f) | Edgelist,節點為細胞類型與組織 | T_cell\tlymph_node |
| 正樣本蛋白質(微調輸入) | JSON | {"T_cell": ["IL2RA", "CD28"]} |
| 負樣本蛋白質(微調輸入) | JSON | {"T_cell": ["ALB", "INS"]} |
| 預訓練嵌入輸出 | PyTorch .pth 或 pickle | 字典結構,key 為 (蛋白質名, 細胞類型),value 為向量 |
理解這套格式規範的關鍵,是意識到 PINNACLE 的所有輸入輸出都以「(實體, 情境)」這種配對結構為核心單位——不管是輸入的正/負樣本 JSON,還是輸出的嵌入字典,都不是「一個蛋白質對應一筆資料」,而是「一個蛋白質-情境配對對應一筆資料」。這個設計原則貫穿整個 repository,是初次使用時最容易誤解、也最需要建立正確心智模型的部分。
5. 進階功能與應用場景 (Advanced Features & Use Cases)
5.1 進階配置:調整訓練超參數的實務考量
pinnacle/parse_args.py 暴露的超參數涵蓋了模型容量、學習動態、損失權重三個維度,進階使用者若打算在自己的資料上重新訓練,以下幾個參數特別值得留意調整策略:
1cd pinnacle
2python train.py \
3 --G_f ../data/networks/global_ppi_edgelist.txt \
4 --ppi_dir ../data/networks/ppi_edgelists/ \
5 --mg_f ../data/networks/mg_edgelist.txt \
6 --save_prefix ../data/pinnacle_embeds/pinnacle \
7 --epochs 300 \
8 --hidden 16 \
9 --output 8 \
10 --n_heads 8 \
11 --lr 0.001 \
12 --wd 5e-4 \
13 --dropout 0.5 \
14 --theta 0.1 \
15 --lmbda 0.01 \
16 --lr_cent 0.01 \
17 --loader graphsaint \
18 --plot True
--theta(連結預測損失權重)與--lmbda(中心損失權重)的相對比例,直接決定模型「更重視保留原始網路拓樸結構」還是「更重視讓同情境蛋白質聚集」。若下游任務更依賴「同情境蛋白質要能被明確分群」(如靶點提名這類需要按細胞類型篩選候選者的任務),適度提高lmbda相對於theta的比例是合理的調整方向;但若下游任務更依賴「精確重建原始交互作用網路的細節」,則應該保守調整,避免中心損失過度扭曲了原始的網路結構訊息。--loader graphsaintvs.neighbor:GraphSAINT 通常在超大規模圖上有更好的訓練效率與收斂穩定性,但neighborloader(基於鄰居採樣)在除錯階段(想確認模型邏輯本身是否正確,而非追求訓練效率)通常更容易預測與追蹤,建議開發階段先用neighbor,確認流程無誤後再切換到graphsaint做正式規模訓練。--plot True:開啟後會自動做 UMAP 視覺化並儲存,對於快速判斷「這次訓練的嵌入品質是否合理」是一個低成本的健檢手段,建議在每次調整重要超參數後都開啟這個選項,累積成一組可比較的視覺化診斷記錄。
5.2 實際應用案例:暗蛋白質的細胞情境功能標註
一個具體的進階應用場景(呼應 PINNACLE 論文與其姊妹專案 ATOMICA 論文都討論過的「功能未知蛋白質」問題):假設你手上有一份「功能未明」的蛋白質清單,想知道這些蛋白質在哪些細胞情境下最活躍、最可能跟哪些已知功能的蛋白質群聚。
1import torch
2
3# 讀取預訓練嵌入(假設格式為字典:(protein_name, celltype) -> tensor)
4embeddings = torch.load("data/pinnacle_embeds/pinnacle_protein_embed.pth")
5
6# 篩選出某個感興趣的暗蛋白質,在所有它出現過的細胞情境下的表徵
7target_protein = "C9orf72" # 範例:一個功能部分未明的蛋白質
8contexts_for_protein = {
9 celltype: emb
10 for (protein, celltype), emb in embeddings.items()
11 if protein == target_protein
12}
13
14print(f"{target_protein} 出現在 {len(contexts_for_protein)} 個細胞情境中")
15
16# 找出在每個情境下,嵌入距離最近的已知功能蛋白質(做最近鄰檢索)
17import torch.nn.functional as F
18
19def find_nearest_neighbors(query_emb, all_embeddings, top_k=5):
20 scores = []
21 for (protein, celltype), emb in all_embeddings.items():
22 if protein == target_protein:
23 continue
24 sim = F.cosine_similarity(query_emb.unsqueeze(0), emb.unsqueeze(0))
25 scores.append((protein, celltype, sim.item()))
26 return sorted(scores, key=lambda x: -x[2])[:top_k]
27
28for celltype, emb in contexts_for_protein.items():
29 neighbors = find_nearest_neighbors(emb, embeddings)
30 print(f"\n情境:{celltype}")
31 for protein, ctx, sim in neighbors:
32 print(f" 最近鄰:{protein} (於 {ctx}), 相似度 {sim:.3f}")
註:上述程式碼的具體張量格式(是
.pth字典還是分開存的 numpy 陣列)請以實際下載的 Figshare 檔案結構為準,此處示範的是概念性的分析邏輯,實際欄位名稱需對照evaluate/utils.py裡的載入函式確認。
這種「跨情境比較同一個蛋白質的最近鄰」的分析方式,可以幫研究者產生具體的生物學假設——例如,如果一個功能未明的蛋白質在「肝細胞情境」下的最近鄰全部是脂質代謝相關蛋白,但在「T 細胞情境」下的最近鄰卻是免疫訊號傳遞相關蛋白,這種「情境依賴的功能轉換」訊號,本身就是值得後續濕實驗驗證的假說。
5.3 與其他工具/函式庫的整合
與 OpenTargets 平台的整合:微調腳本內建對 OpenTargets 疾病 ID 系統的支援,這代表 PINNACLE 的靶點提名結果可以直接跟 OpenTargets 平台上已有的其他證據型別(基因體學關聯、文獻共現、通路富集分析等)交叉比對,不需要額外做識別碼轉換的工程工作。
與 UMAP/降維視覺化生態系的整合:evaluate/visualize_representations.py 依賴標準的 umap-learn 套件,這代表任何熟悉 Scanpy(單細胞分析標準工具)生態系的研究者,幾乎可以直接沿用既有的視覺化美化技巧(色彩映射、圖層疊加)套用到 PINNACLE 的嵌入視覺化上。
與圖神經網路生態系的整合:PINNACLE 基於 PyTorch Geometric 建構,這代表其產出的異質圖結構理論上可以被匯出、餵入其他基於 PyG 的下游模型架構,而不僅限於作者提供的 MLP 微調頭——進階使用者若想嘗試更複雜的下游架構(如 Graph Attention Network 微調頭,而非簡單 MLP),可以直接沿用 PyG 的 API 銜接。
5.4 效能優化建議
- 善用預訓練 checkpoint,避免不必要的重新訓練:如第 2.7 節所述,微調階段的運算成本遠低於預訓練階段。除非你的研究對象是全新的物種、組織或細胞類型組合(作者提供的 156 種細胞類型與 24 種組織未涵蓋的範圍),否則直接使用作者提供的預訓練嵌入通常是效能與時間成本的最優解。
- 微調階段善用批次化多疾病比較:若需要對多個疾病 ID 跑靶點提名(如同時分析 5-10 種自體免疫疾病),可以寫一個簡單的 bash 迴圈批次執行,由於每次微調的運算成本很低,批次跑幾十個疾病 ID 在單張消費級 GPU 甚至 CPU 上都是可行的:
1for disease_id in EFO_0000685 EFO_0003767 EFO_0000384 EFO_0000474; do
2 python train.py \
3 --disease "$disease_id" \
4 --embeddings_dir ../data/pinnacle_embeds/ \
5 --metrics_output_dir "./results_${disease_id}/" \
6 --models_output_dir "./models_${disease_id}/"
7done
- 善用
--random開關做穩健性檢驗,而非只信任單次結果:微調分類器的訓練資料通常規模不大(正樣本數受限於已知疾病關聯基因數量),單次隨機種子的結果可能有相當的變異性,建議跑 5-10 次不同隨機種子並報告平均與變異範圍,而不是只呈現單一次的排序結果。
5.5 一個完整的應用場景示意圖:從單細胞資料到臨床決策支援
flowchart TB A["臨床問題:
RA 患者的哪些細胞情境值得優先
做藥物靶點篩選?"] --> B["取得 Tabula Sapiens
相關組織的單細胞資料"] B --> C["PINNACLE 預訓練嵌入
(可直接使用作者提供版本)"] C --> D["finetune_pinnacle
以 EFO_0000685 微調靶點分類器"] D --> E["產出:各細胞情境下
候選靶點排序清單"] E --> F{"排序靠前的候選者
是否與已知 RA 藥物靶點吻合?"} F -->|吻合度高,建立信心| G["篩選出新穎候選靶點
供濕實驗團隊優先驗證"] F -->|吻合度低| H["檢視微調資料品質
或重新檢視細胞情境定義"] G --> I["結合臨床專家知識
(如風濕免疫科醫師)校驗合理性"] I --> J["納入藥物開發早期靶點
篩選漏斗的其中一項證據"] style A fill:#2563EB,color:#F8FAFC style G fill:#DC2626,color:#F8FAFC style J fill:#B91C1C,color:#F8FAFC
這張圖刻意在流程中段加入「與已知藥物靶點吻合度檢查」這一步驟,反映一個重要的方法論原則:任何計算靶點提名工具的輸出,都應該先用「能否找回已知的真陽性」來校驗其可信度,而不是直接把模型輸出當作定論——這也是 PINNACLE 論文本身驗證其方法有效性時所採用的核心策略。
6. AIKT 整合分析與策略 (AIKT Integration & Strategy)
6.1 整合架構圖
flowchart TB subgraph SG_AIKT_CAPTURE["AIKT 知識擷取層 L1-L3"] L2["ai_gh_save
已擷取 PINNACLE repo 為本教學"] L3["autofetch
可持續追蹤 mims-harvard 新發表"] end subgraph SG_AIKT_ORG["AIKT 知識組織層 L4-L6"] L4["graphify
索引本文件到知識圖譜"] L9["paper_search
交叉搜尋 PINNACLE 引用/被引文獻"] L10["paper_qa_lite
本地問答:針對此教學做 RAG"] end subgraph SG_AIKT_OUTPUT["AIKT 專業輸出層 L7・L11-L12"] L7["quarkdown
本 md 可編譯為 PDF/slides"] L11["kami
可產出品牌化簡報"] end subgraph SG_PINNACLE["PINNACLE 專案本體"] PIN["PINNACLE
情境感知蛋白質嵌入引擎"] PIN_EMB["三類嵌入輸出
蛋白質/細胞類型/組織"] PIN_TARGET["微調輸出
疾病靶點提名排序"] end subgraph SG_AIKT_RESEARCH["AIKT 研究管線層 L18-L19"] L18["research_pipeline_v2
納入靶點提名結果做多輪研究"] L19["tu_plan_generator
藥物開發計畫引用靶點提名證據"] end subgraph SG_AIKT_IP["AIKT IP 層 L13"] end L2 --> PIN L3 -.持續監控.-> L2 PIN --> PIN_EMB PIN_EMB --> PIN_TARGET PIN_EMB --> L4 PIN_TARGET -.結果彙整.-> L18 L18 --> L19 L18 -.可能.-> L13 PIN -.文件.-> L7 L7 --> L11 L4 --> L10 L9 -.補充文獻.-> L4 style PIN fill:#DC2626,color:#F8FAFC style PIN_EMB fill:#DC2626,color:#F8FAFC style PIN_TARGET fill:#B91C1C,color:#F8FAFC style L18 fill:#2563EB,color:#F8FAFC
6.2 紅海分析 (Red Ocean Analysis):功能重疊之處
跟先前分析過的 ATOMICA 類似,PINNACLE 與 AIKT 的核心功能定位在完全不同的抽象層次——AIKT 是「知識管理與研究流程編排系統」,PINNACLE 是「情境感知蛋白質表徵學習模型」,直接的正面競爭關係並不存在。但仔細檢視邊界地帶,仍能找出幾個值得誠實面對的重疊點:
| 重疊功能點 | AIKT 現況 | PINNACLE 現況 | 誰做得更好、為什麼 |
|---|---|---|---|
| GitHub repo → 知識文件轉換 | L2 ai-gh-save/L12 gh-tutorial-qd 可將 PINNACLE repo 轉為結構化教學(本文件即為產出) | 無此功能,PINNACLE 本身是模型工具,不做知識轉換 | AIKT 完勝,這本來就不是同類產品 |
| 嵌入向量的降維視覺化 | AIKT 無內建視覺化引擎,可透過 matplotlib/plotly/seaborn skill 補足 | PINNACLE 依賴 umap-learn 自帶視覺化腳本(visualize_representations.py) | 平手,兩者各自用不同路徑解決,無明顯優劣差異 |
| 文獻搜尋(理解 PINNACLE 研究脈絡) | L9 paper-search 可搜尋 PINNACLE 引用的文獻與後續引用它的論文,含 RA/IBD 相關臨床文獻 | PINNACLE repo 本身完全沒有文獻搜尋功能 | AIKT 完勝,但這也不是 PINNACLE 該做的事 |
| 疾病相關基因/靶點資料查詢 | AIKT 的 database-lookup skill 可查詢 Open Targets、ClinVar、GWAS Catalog 等疾病-基因關聯資料庫 | PINNACLE 微調腳本內建對 OpenTargets 疾病 ID 的支援,直接抓取關聯基因作正樣本 | PINNACLE 略勝——它是把資料庫查詢直接嵌入訓練流程自動化,AIKT 的資料庫查詢是通用型工具,需要額外整合才能對接 PINNACLE 的訓練管線 |
| 藥物開發計畫生成(靶點篩選章節) | L19 tu-plan-generator 生成藥物開發計畫時可以引用靶點提名結果,但不會自己跑任何嵌入模型或分類器訓練 | PINNACLE 能實際跑出靶點提名的數值排序結果 | PINNACLE 完勝——這是最需要說清楚的邊界,若使用者誤以為 AIKT 能自己產生這類分析結果會失望 |
結論:紅海範圍極小,且大多是「工具互補」而非「工具替代」的關係。唯一真正需要明確界定的邊界,是 AIKT 的任何 layer 都不會、也不應該重新實作 PINNACLE 這種需要異質圖神經網路訓練、大規模單細胞資料前處理、GPU 運算資源的科學計算能力。這與 CLAUDE.md 對 AIKT 的定位陳述完全一致:「AIKT 不做直接科學計算——它編排知識,不是演算法」。
6.3 藍海策略 (Blue Ocean Strategy):AIKT 可以獨特切入的機會
a) 未滿足的需求:PINNACLE 輸出結果缺乏「跨疾病、跨情境的敘事整合」
PINNACLE 微調一次只針對一個疾病 ID 產出一份靶點排序清單。如果研究者想比較 5 種自體免疫疾病的靶點提名結果,找出「哪些細胞情境在多種疾病裡都反覆出現」這種跨疾病的共通模式,PINNACLE 本身不提供這層整合分析——使用者需要自己寫程式碼彙整多次微調的輸出,再手動判讀模式。這正是 AIKT 擅長的「多源資訊整合成敘事」的空間。
b) 創造新價值的整合機會:「多疾病靶點提名 → 跨疾病共通機轉假說」自動化管線
具體設想一個工作流:研究者依第 5.4 節的批次腳本,跑完 10 種自體免疫相關疾病的 PINNACLE 靶點提名,得到 10 份排序清單。若串接:
- 一個簡單的比對邏輯,找出在多份清單中重複出現、且排序都靠前的細胞情境-蛋白質配對;
paper-search(L9)針對這些重複出現的候選配對,自動搜尋既有文獻,確認是否已有跨疾病機轉的實驗證據(如某個發炎訊號路徑同時牽涉多種自體免疫疾病);paper-qa-lite(L10)對搜尋到的文獻做本地 RAG 問答,摘要「這個蛋白質在不同疾病脈絡下的既有研究進展」;research-pipeline-v2(L18)把跨疾病比對結果、文獻佐證整合成一輪研究摘要,供團隊評估是否值得投入「廣效性(pan-disease)藥物靶點」的開發策略;kami(L11)把整合結果排版為簡報,供組會或跨部門溝通使用。
這一整串下來,AIKT 把 PINNACLE 一次一種疾病的「孤立分析結果」,轉化為「跨疾病模式辨識 + 文獻佐證 + 決策建議」的知識產出——這正是 PINNACLE 團隊本身的專業(圖神經網路方法學)不會、也不該去做的延伸工作。
c) 互補的 AIKT 層級
| AIKT 層級 | 與 PINNACLE 的互補關係 |
|---|---|
| L9 paper-search | 補足 PINNACLE 靶點提名結果缺乏的文獻脈絡佐證,尤其是跨疾病比對後的機轉假說驗證 |
| L10 paper-qa-lite | 讓使用者針對本教學文件或 PINNACLE 論文本身做本地問答,加速理解模型設計動機 |
| L18 research-pipeline-v2 | 把單次或多次 PINNACLE 微調結果,串接進多輪迭代的研究假設驗證流程 |
| L19 tu-plan-generator | 若 PINNACLE 分析揭示某疾病的高信心候選靶點,可作為藥物開發計畫中靶點篩選章節的量化證據來源 |
| L4 graphify | 把多次 PINNACLE 分析累積的知識(哪些疾病、哪些細胞情境、哪些靶點)索引進知識圖譜,累積成團隊的機構記憶 |
| database-lookup skill | 可作為 PINNACLE 微調輸入前的疾病 ID 確認工具(查詢 Open Targets、ClinVar 等),減少使用者手動查找 EFO ID 的摩擦 |
d) 具體差異化策略
AIKT 不該嘗試「懂 PINNACLE 的圖神經網路架構細節」,而該專注在「懂如何把 PINNACLE 一次一種疾病的分析結果,擴展成跨疾病、跨情境、有文獻佐證的決策知識」。差異化的核心主張是:PINNACLE 賣的是「單一情境下的精準表徵能力」,AIKT 賣的是「把多次精準分析串成一個更大敘事」的整合能力。這跟 AIKT 對 ATOMICA 等其他分子科學工具一致的定位邏輯完全吻合。
6.4 推薦整合方案
第一階段(已完成):知識擷取
本教學文件即為第一階段產出,透過 L2/L12 把 PINNACLE 的架構、用法、應用場景轉譯成團隊可快速上手的知識資產,存放於 projects/260710 mims-harvard/tutorials/22-PINNACLE.md。
第二階段(建議短期執行):建立「多疾病靶點提名比對」的輕量分析腳本
第三階段(視實際需求評估):與 database-lookup skill 打通疾病 ID 查詢
建議評估是否值得在 database-lookup skill 與 PINNACLE 微調流程之間建立一個薄的橋接——使用者用自然語言描述疾病(如「類風濕性關節炎」),自動轉換為對應的 EFO ID,再帶入 finetune_pinnacle/train.py 的 --disease 參數,省去使用者手動查找 Open Targets 疾病識別碼的步驟。這是一個工程成本低、但能明顯降低使用門檻的整合點。
6.5 建議整合方案的具體工作流圖
flowchart TB A["對 N 個疾病 ID
批次執行 PINNACLE 微調"] --> B["N 份靶點排序清單
(每份對應一種疾病)"] B --> C["比對邏輯:
找出跨清單重複出現的
細胞情境-蛋白質配對"] C --> D{"重複出現的配對
是否有既有文獻支持?"} D -->|觸發| E["paper_search L9
搜尋相關機轉文獻"] E --> F["paper_qa_lite L10
本地摘要文獻脈絡"] F --> G["整合排序結果+文獻脈絡
產出結構化摘要 md"] G --> H{"是否涉及機密專有資訊"} H -->|是| I["存入受限目錄
chmod 700 + gitignore"] H -->|否| J["存入 inbox/ 或
projects/research-*/"] J --> K["可選:graphify L4
索引進知識圖譜"] J --> L["可選:kami L11
排版為跨疾病比對簡報"] style A fill:#DC2626,color:#F8FAFC style C fill:#2563EB,color:#F8FAFC style E fill:#2563EB,color:#F8FAFC style I fill:#B91C1C,color:#F8FAFC
6.6 決策矩陣:是否值得投入資源整合
| 檢核問題 | 若答案偏向「是」 | 若答案偏向「否」 |
|---|---|---|
| 團隊近期(3-6 個月內)有跨多個適應症的靶點篩選需求嗎? | 值得投入第二階段的多疾病比對整合 | 先擱置,僅保留本教學文件供未來查閱 |
| 團隊有 GPU 資源可跑預訓練或熟悉單細胞資料前處理嗎? | 可考慮在自有資料上重新訓練,獲得更貼合自身研究物種/組織的表徵 | 直接沿用作者提供的預訓練嵌入,聚焦在微調與分析層 |
| 分析結果會影響到高風險決策(如候選靶點是否進入濕實驗驗證)? | 務必先做跨隨機種子的穩健性檢驗(見第 5.4 節),整合時保留完整可追溯性 | 可作為探索性分析使用,容錯空間較大 |
| 分析結果涉及機密專有候選靶點資訊? | 必須套用機密邊界隔離協議,不可自動化到一般 Discord 流程 | 可考慮標準化的 inbox/research 流程 |
| 團隊是否已有 Open Targets/ClinVar 等疾病-基因資料庫查詢的既有習慣? | 整合 database-lookup skill 的邊際效益較低,可略過第三階段 | database-lookup 橋接的價值較高,值得優先評估 |
6.7 與現有 AIKT 使用者記憶脈絡的呼應
7. 效能、限制與替代方案 (Performance, Limitations & Alternatives)
7.1 效能數據與基準測試
論文報告的核心效能結論包括:(1) 在藥物基因體效應預測任務上,情境感知(PINNACLE)的表現顯著優於情境無關(不區分細胞類型)的基準模型;(2) 在 RA 與 IBD 兩個真實臨床適應症的靶點提名任務上,PINNACLE 提名的候選靶點跟已知藥物靶點的重疊度,優於未考慮細胞情境的傳統方法;(3) 零樣本組織層級檢索的準確度顯示模型學到的組織嵌入確實反映了解剖學層級關係。需注意的是,這些效能數據都來自論文本身報告的比較,建議使用者在應用到自己的資料集前,先在已知答案的小規模驗證集上重新確認效能表現,而不是直接假設論文報告的效能可以無條件遷移。
7.2 已知限制
- 資料來源的物種與族群侷限:訓練資料完全來自 Tabula Sapiens 這一份特定的人類多器官單細胞圖譜,若研究對象是模式動物(小鼠、斑馬魚等)或某個在 Tabula Sapiens 取樣不足的特定族群/年齡層,現有預訓練嵌入的適用性需要謹慎評估,不宜直接套用。
- 156 種細胞類型與 24 種組織的覆蓋範圍有限:人體實際存在的細胞類型數量遠超過 156 種,若研究興趣的細胞類型不在既有涵蓋範圍內,需要重新跑完整的前處理管線與預訓練,這是相當可觀的工程與運算成本。
- 初始特徵為隨機向量,不含蛋白質序列/結構資訊:如第 2.3 節提到,PINNACLE 完全依賴網路拓樸與情境歸屬關係學習表徵,不利用蛋白質序列或結構的先驗知識。這代表 PINNACLE 對「網路資料稀疏或品質不佳的蛋白質」的表徵品質,可能不如結合序列/結構資訊的方法(如 ESM 系列蛋白質語言模型)穩健。
- 微調任務高度依賴 OpenTargets 既有證據作為訓練標籤:對於證據累積不足的罕見疾病或新興適應症,微調用的正樣本數量可能過少,導致微調結果的統計穩健性存疑。
- 模型解釋性有限:雖然中心損失讓嵌入空間有一定的結構化意義,但要從「為什麼這個蛋白質-情境配對被排到很前面」倒推出具體的生物學機轉解釋,仍需要額外的下游分析(如注意力權重視覺化),模型本身不直接提供這層可解釋性。
7.3 與同類工具比較
| 工具 | 核心方法 | 情境感知程度 | 適用場景 |
|---|---|---|---|
| PINNACLE | 異質圖神經網路,細胞類型/組織層級注意力 | 高(蛋白質級 × 細胞類型級雙重情境) | 需要「哪個細胞情境」這個維度的靶點篩選、藥物基因體效應分析 |
| 傳統 STRING/BioGRID PPI 嵌入(如 node2vec) | 同質圖嵌入,不區分細胞情境 | 無 | 快速取得通用蛋白質相似度,不需要情境細節的場景 |
| ESM 系列蛋白質語言模型 | 序列基礎的 Transformer 預訓練 | 無(序列不變,情境無關) | 蛋白質功能/結構預測,不涉及細胞類型差異的任務 |
| ATOMICA | 原子解析度幾何深度學習 | 高,但情境是「交互作用介面」而非「細胞類型」 | 需要原子級交互作用細節的分子對接、脫靶效應分析 |
| TxGNN | 疾病-藥物關係圖神經網路 | 中(疾病層級的情境,非細胞層級) | 零樣本藥物重定位,關係層級推理 |
7.4 何時使用 vs. 何時不使用
適合使用 PINNACLE 的情境:
- 研究問題明確涉及「同一蛋白質在不同細胞類型/組織中的角色差異」;
- 有明確的疾病適應症(且該適應症在 OpenTargets 有一定證據累積),想做情境感知的靶點提名;
- 想驗證某個藥物的基因體效應是否在特定細胞類型情境下特別顯著;
- 研究物種為人類,且關注的細胞類型/組織落在 Tabula Sapiens 的取樣範圍內。
不適合使用 PINNACLE 的情境:
- 研究問題純粹是分子結構/序列層級的預測(如蛋白質折疊、結合親和力數值預測),此時 AlphaFold、ESM 或 ATOMICA 更合適;
- 研究物種是非人類模式動物,且缺乏對應的多器官單細胞圖譜資料;
- 需要即時、高頻率的線上推論場景(PINNACLE 的預訓練是一次性、批次的離線計算,不是設計來做即時推論的架構);
- 研究興趣的細胞類型/組織完全落在 Tabula Sapiens 未涵蓋的範圍,且沒有資源重新跑前處理管線與預訓練。
8. 總結與建議 (Summary & Recommendations)
8.1 關鍵要點回顧
PINNACLE 的核心貢獻,是把「蛋白質的功能是情境依賴的」這個生物學常識,系統性地轉化成一套可訓練、可驗證的圖神經網路方法論。它的技術核心是一個雙層的異質圖神經網路,透過 PCTConv(上池化)與 PPIConv(下池化)的雙向資訊流動,同時對蛋白質-蛋白質、蛋白質-細胞類型、細胞類型-組織這三個尺度的關係做聯合建模,並用連結預測損失與中心損失共同塑造出一個「同時保留原始網路拓樸、又能清楚區分不同情境」的嵌入空間。最終產出的 394,760 個情境化蛋白質表徵,經過在類風濕性關節炎與發炎性腸道疾病兩個真實臨床適應症上的微調驗證,展現出優於情境無關方法的靶點提名能力。
從方法論演進的角度看,PINNACLE 在 Zitnik Lab 的產出線裡,精準卡在「巨觀疾病-藥物關係圖譜」(如 PrimeKG、TxGNN)與「微觀原子交互作用」(如 ATOMICA)之間的中間層級,填補了「同一分子在不同細胞情境下的多重身分」這個過去被主流方法忽視的建模空缺。
8.2 最佳使用場景
PINNACLE 最能發揮價值的場景,是藥物開發流程中的早期靶點篩選階段,尤其是當研究問題天然帶有「哪個細胞類型/組織情境」這個維度時——例如篩選發炎性疾病的候選靶點、評估藥物在不同組織的基因體效應差異、或是對功能未明的蛋白質做情境化的功能推測。對於已經有明確疾病適應症、且該適應症在 OpenTargets 累積了一定證據基礎的研究團隊,PINNACLE 提供了一條相對低成本(善用預訓練嵌入 + 輕量微調)就能取得情境感知分析能力的路徑。
8.3 未來發展方向與建議
對於考慮採用 PINNACLE 的團隊,建議的推進路徑是:先用作者提供的預訓練嵌入與微調範例,在一個資料證據充足、且團隊有臨床/生物學專家可以校驗結果合理性的適應症上做試點分析,驗證方法在自身研究情境下的實用性,再決定是否投入資源做更深度的整合(如跨疾病比對分析、或在自有資料上重新預訓練)。同時,考慮到 PINNACLE 依賴的 Tabula Sapiens 資料涵蓋範圍有限,若研究興趣落在該圖譜未充分取樣的細胞類型或組織,應誠實評估重新訓練的工程成本是否合理,而非強行套用現有嵌入到分佈外的場景。
在 AIKT 的框架下,PINNACLE 最適合的角色定位是一個「上游的情境感知分析引擎」——AIKT 不應該、也不會嘗試複製其圖神經網路建模能力,而應該專注於把 PINNACLE 產出的單次、單一疾病的分析結果,透過既有的文獻搜尋、知識圖譜索引、跨輪次研究管線等層級,擴展成跨疾病、有文獻佐證、可供決策參考的完整知識敘事——這正是 AIKT 對所有分子科學工具(不論是 PINNACLE 還是 ATOMICA)一致採取的定位邏輯:專注在「計算結果出來之後」的知識轉譯與整合,而不涉入計算本身。
Comments