ProCyon：蛋白質表型的多模態基礎模型完整教學

Repository: mims-harvard/ProCyon Stars: 60 · Language: Python · License: MIT 分類：分子與蛋白質科學 (Molecular & Protein Science; 分子與蛋白質科學) 論文：Queen et al., ProCyon: A multimodal foundation model for protein phenotypes, bioRxiv 2024.12.10.627665

1. 專案概述 (Project Overview)

1.1 一句話說明

ProCyon 是由 Harvard Medical School 的 Zitnik Lab（也就是 mims-harvard 團隊）開發的多模態基礎模型 (multimodal foundation model; 多模態基礎模型)，目標是「看懂蛋白質的表型 (phenotype; 表型)」——也就是一個蛋白質在細胞裡實際扮演的角色、跟什麼藥物結合、跟什麼疾病有關、屬於哪個功能分類。

1.2 用一個比喻理解 ProCyon 在做什麼

想像你手上有一本「蛋白質身分證資料庫」，裡面每一頁記錄了：

• 這個蛋白質的「基因序列」（就像身分證上的照片和指紋）
• 但完全沒寫「這個人是做什麼工作的」「跟誰有關係」「有沒有前科」

傳統的蛋白質語言模型（例如 ESM2、ProtBERT）很擅長「看懂照片」——也就是從氨基酸序列 (amino acid sequence; 氨基酸序列) 學到結構與演化資訊，但它們對「這個蛋白質在人類疾病中扮演什麼角色」「跟哪種藥物結合」這類文字描述型知識是相對陌生的。

ProCyon 做的事情，就像是雇用一位「雙語翻譯官」：一邊懂蛋白質序列的「生物語言」，一邊懂科學文獻與資料庫的「自然語言」，然後把兩者接起來。你可以：

• 給它一段文字描述（例如「跟重度憂鬱症有關的蛋白質」），它幫你檢索 (retrieval; 檢索) 出最相關的蛋白質
• 給它一個蛋白質序列，它幫你生成 (generation; 生成) 一段描述這個蛋白質功能的自然語言說明
• 你可以直接問它問題（question-answering; 問答），像是「這個蛋白質會不會跟某個藥物結合？」

這就是論文標題裡「multimodal（多模態）」的意思——序列模態 (sequence modality) 與文字模態 (text modality) 被放進同一個共享的語意空間裡。

1.3 為什麼這件事很重要

在藥物開發與精準醫療領域，「蛋白質功能標註 (protein function annotation; 蛋白質功能註解)」長期依賴人工整理的資料庫，如 Gene Ontology (GO; 基因本體論)、UniProt、Reactome、DrugBank、OMIM 等。這些資料庫的問題是：

1. 覆蓋率有限：全世界已知蛋白質序列數以億計，但有詳細功能註解的只是一小部分
2. 更新速度慢：新發現的蛋白質功能要經過同儕審查才能進資料庫
3. 跨資料庫整合困難：GO 講的是分子功能，DrugBank 講的是藥物結合，OMIM 講的是疾病關聯——彼此格式不同、難以聯合查詢

ProCyon 的策略是：把上述所有這些異質資料庫統一轉換成「指令微調 (instruction tuning; 指令微調)」格式的問答/檢索/生成任務，訓練出一個可以同時處理這些任務的通用模型。這意味著使用者不用再為每一種資料庫寫一套專用查詢工具——一個模型就能回答「這個蛋白質功能是什麼」「這個蛋白質跟哪個藥物結合」「哪些蛋白質跟這個疾病有關」。

1.4 相關發表論文與引用

 1@article{Queen2024.12.10.627665,
 2  author = {Queen, Owen and Huang, Yepeng and Calef, Robert and Giunchiglia, Valentina
 3            and Chen, Tianlong and Dasoulas, George and Tai, LeAnn and Ektefaie, Yasha
 4            and Noori, Ayush and Brown, Joseph and Cobley, Tom and Hrovatin, Karin
 5            and Hartvigsen, Tom and Theis, Fabian and Pentelute, Bradley L.
 6            and Khurana, Vikram and Kellis, Manolis and Zitnik, Marinka},
 7  title = {ProCyon: A multimodal foundation model for protein phenotypes},
 8  year = {2024},
 9  doi = {10.1101/2024.12.10.627665},
10  journal = {bioRxiv}
11}

論文作者名單橫跨 Harvard Medical School、MIT（Manolis Kellis 實驗室）、Helmholtz Munich（Fabian Theis，單細胞分析權威）等頂尖機構，通訊作者 Marinka Zitnik 是生醫圖神經網路 (graph neural network for biomedicine; 生醫圖神經網路) 領域的知名學者。

1.5 在 mims-harvard 實驗室生態系中的角色

mims-harvard（Zitnik Lab 的 GitHub 組織）維護一系列聚焦「多模態生醫表徵學習 (multimodal biomedical representation learning; 多模態生醫表徵學習)」的專案，ProCyon 在其中的定位是「蛋白質層級的通才模型 (generalist model; 通才模型)」，與該實驗室其他偏向特定任務（例如藥物交互作用預測、疾病知識圖譜）的專案互補——ProCyon 更像是一個底層基礎設施，其他下游任務可以在它產生的蛋白質-文字聯合嵌入 (joint embedding; 聯合嵌入) 上構建。

1.6 專案定位圖

flowchart TB
    subgraph BIOAI["生醫 AI 版圖"]
        A["序列基礎模型
ESM2 / ProtBERT
(只懂序列)"]
        B["文字基礎模型
PubMedBERT / SciBERT
(只懂文獻)"]
        C["ProCyon
(序列+文字 聯合模型)"]
        D["下游應用
藥物篩選/疾病關聯/功能註解"]
        E["知識庫
GO / UniProt / DrugBank / OMIM / Reactome"]
    end

    A -->|"提供蛋白質表徵"| C
    B -->|"提供語言理解能力"| C
    E -->|"指令微調資料來源"| C
    C -->|"檢索/生成/問答"| D

    style C fill:#2563EB,color:#FFFFFF
    style A fill:#DBEAFE,color:#0F172A
    style B fill:#DBEAFE,color:#0F172A
    style E fill:#FEF3C7,color:#0F172A
    style D fill:#D1FAE5,color:#0F172A

如上圖所示，ProCyon 站在「序列理解」與「文字理解」的交會點上，把兩邊的知識融合，再供下游的藥物開發、疾病研究等應用調用。

2. 核心架構 (Core Architecture)

2.1 系統架構總覽

ProCyon 的模型架構本質上是一個「雙編碼器 + 生成式解碼器」的混合設計，關鍵組件包含：

1. 蛋白質編碼器 (protein encoder; 蛋白質編碼器)：以 ESM2（Facebook/Meta 開發的蛋白質語言模型）為骨幹，把氨基酸序列轉換成向量表徵
2. 文字編碼器 / 解碼器 (text encoder/decoder; 文字編碼器/解碼器)：以 Llama-3-8B（ProCyon-Full）或 Llama-2-7B（ProCyon-Split，用於基準測試）、PMC-LLaMA、PubMedBERT 等作為骨幹，負責理解與生成自然語言描述
3. 對比學習模組 (contrastive learning module; 對比學習模組)：用於將蛋白質向量與文字向量投影進同一個共享的語意空間，讓「相關」的蛋白質-文字配對在向量空間中距離更近
4. 多任務指令微調層 (multi-task instruction tuning layer; 多任務指令微調層)：透過 LoRA/M-LoRA（多重低秩適配; multi-LoRA）等參數高效微調技術，讓同一個底層模型能同時勝任檢索、問答、生成三種任務

flowchart LR
    subgraph INPUT["輸入層"]
        P["蛋白質序列
(amino acid string)"]
        T["文字提示
(task prompt / description)"]
    end

    subgraph ENCODE["編碼層"]
        PE["ESM2 蛋白質編碼器"]
        TE["LLM 文字編碼器
(Llama-3 / PubMedBERT)"]
    end

    subgraph FUSE["融合與任務層"]
        CL["對比學習投影
Contrastive Projection"]
        MLORA["M-LoRA 任務切換
(retrieval / qa / caption)"]
    end

    subgraph OUTPUT["輸出層"]
        R["檢索結果
Top-K 相關蛋白質/表型"]
        G["生成文字
功能描述 / 答案"]
    end

    P --> PE --> CL
    T --> TE --> CL
    CL --> MLORA
    MLORA --> R
    MLORA --> G

    style CL fill:#2563EB,color:#FFFFFF
    style MLORA fill:#7C3AED,color:#FFFFFF
    style PE fill:#DBEAFE,color:#0F172A
    style TE fill:#DBEAFE,color:#0F172A

2.2 資料流向：從原始資料庫到訓練樣本

ProCyon 最巧妙的設計其實不在模型本身，而在資料整合層。研究團隊把八種以上異質資料庫（GO、UniProt、Reactome、DrugBank、OMIM、DisGeNET、Pfam domain、GtoPdb 等）統一轉換成三種標準任務格式：

• caption（生成任務）：給蛋白質，生成一段功能描述
• qa（問答任務）：給蛋白質+問題，生成答案
• retrieval（檢索任務）：給文字描述，從蛋白質池中檢索最相關者

sequenceDiagram
    participant DB as "原始資料庫
(GO/DrugBank/OMIM/...)"
    participant IC as "instruct_constructor.py
指令建構器"
    participant DS as "ProCyon-Instruct
統一資料集"
    participant MD as "metadataset.py
多資料集取樣器"
    participant MODEL as "ProCyon 模型"

    DB->>IC: "原始標註 (蛋白質-GO term 配對等)"
    IC->>IC: "轉換成 caption/qa/retrieval 三種模板"
    IC->>DS: "輸出統一 JSON 指令格式"
    DS->>MD: "依任務類型/資料集比例取樣"
    MD->>MODEL: "batch (蛋白質序列, 文字提示, 標籤)"
    MODEL->>MODEL: "對比學習 + 生成式微調"
    MODEL-->>DS: "推論時：檢索/生成/問答"

用比喻來說：instruct_constructor.py 就像一位「格式轉換員」，把 GO 資料庫的「蛋白質 X 具有分子功能 Y」轉換成三種不同角度的考題——「用一句話描述蛋白質 X 的功能」（caption）、「蛋白質 X 是否具有功能 Y？」（qa）、「哪些蛋白質具有功能 Y？」（retrieval）。這樣同一份原始標註可以被「榨」出三倍的訓練訊號，也讓模型學會從不同角度理解同一件事。

2.3 關鍵演算法：對比學習 + 生成式指令微調的結合

ProCyon 並不是單純的對比學習模型（像 CLIP），也不是單純的生成模型（像 GPT）——它把兩者結合：

步驟一：對比預訓練（讓模型學會「配對」） 用 InfoNCE 風格的對比損失函數，訓練蛋白質嵌入與文字嵌入在共享空間中，正確配對（例如某蛋白質與其真實功能描述）的距離小，錯誤配對的距離大。這一步類似訓練一位翻譯官先學會「聽懂兩種語言指的是不是同一件事」。

步驟二：指令微調（讓模型學會「生成」與「問答」） 在對比預訓練的基礎上，加入生成式任務——給定蛋白質嵌入作為上下文，讓 LLM 解碼器生成自然語言描述，或回答特定問題。這一步類似讓翻譯官不只能判斷「這兩句話是不是同一個意思」，還要能「主動用另一種語言把意思講出來」。

步驟三：M-LoRA 多任務適配 由於檢索、問答、生成三個任務所需的「行為模式」不同，ProCyon 用 M-LoRA（procyon/model/mlora.py）在同一個底層 LLM 上插入多組低秩適配矩陣，依任務類型切換啟用哪一組 LoRA 權重，這樣不用為每個任務訓練一整套獨立模型，大幅節省參數量與訓練成本。

2.4 三個官方發布的模型變體

這種「依用途拆分模型檔」的作法，類似把一個萬用工具箱拆成「日常款」「比賽款」「專項款」——避免使用者為了一個簡單任務背負整套最大模型的運算成本。

2.5 內部元件如何互動：一次「蛋白質檢索」請求的生命週期

flowchart TD
    A["使用者輸入疾病描述
'Major depressive disorder'"] --> B["inference_utils.py
建構 retrieval prompt"]
    B --> C["model_unified.py
ProCyon 統一模型入口"]
    C --> D["文字端：LLM encoder 產生 query 向量"]
    C --> E["蛋白質池：ESM2 產生所有候選蛋白質向量
(可預先快取)"]
    D --> F["retrieval_utils.py
計算向量相似度 (dot product/cosine)"]
    E --> F
    F --> G["排序並回傳 Top-K 蛋白質"]
    G --> H["FastAPI 端點 (procyon/app/main.py)
回傳 JSON 結果"]

    style C fill:#2563EB,color:#FFFFFF
    style F fill:#7C3AED,color:#FFFFFF

這張圖對應到 procyon/app/main.py 提供的本地 API：使用者送出一段疾病描述文字，模型端把它轉成向量，跟預先算好的蛋白質向量庫做相似度比對，回傳最相關的蛋白質清單——概念上跟語意搜尋引擎（如向量資料庫 RAG 系統）非常相似，只是「文件」換成了「蛋白質」。

3. 安裝與設定 (Installation & Setup)

3.1 前置需求

• 作業系統：Linux（官方測試環境），需要 NVIDIA GPU
• CUDA 工具鏈：需要 nvcc（CUDA compiler），用於編譯 flash-attn 等加速套件
• Python 版本：嚴格要求 3.11.9（pyproject.toml 中 requires-python = "==3.11.9"，鎖定到 patch 版本，非常嚴格）
• HuggingFace 帳號權限：需要先在 Llama-3-8B 模型頁 申請存取權限（Meta 官方會審核），才能下載骨幹模型權重
• 磁碟空間：模型權重 + ProCyon-Instruct 資料集，建議預留 100GB+ 空間
• 關鍵版本鎖定警告：README 特別警示 transformers 版本若高於 4.31.0，會導致推論結果與訓練時不一致——這是模型推論可重現性 (reproducibility; 可重現性) 的常見陷阱，套件更新後 API 行為改變但沒有明顯報錯

3.2 逐步安裝指南（方法一：使用 uv，官方推薦）

 1# 1. clone 專案
 2git clone https://github.com/mims-harvard/ProCyon.git
 3cd ProCyon
 4
 5# 2. 用 uv 建立虛擬環境並安裝（官方推薦，10 分鐘內完成，視網速）
 6uv sync --extra build
 7uv sync --extra build --extra compile   # 含 flash-attn 加速編譯
 8uv pip install -e .
 9
10# 3. 啟用虛擬環境
11source .venv/bin/activate

依全域規範，Python 專案優先使用 uv/uvx，禁止把 pip 當主要安裝方式；ProCyon 官方文件本身也把 uv 列為第一推薦，這點與工具鏈規範一致，可以直接照官方流程走。

3.3 逐步安裝指南（方法二：純 pip，備援方案）

1cd ProCyon
2python3 -m pip install -e .

若環境已用 uv 建立過 venv，仍建議在 venv 內執行 pip install -e .，而非依賴系統 Python。

3.4 資料與模型權重設定

ProCyon 需要三種外部資源，全部集中放在一個 DATA_DIR 目錄下：

 1# 設定資料根目錄
 2export DATA_DIR=/desired/path/for/data
 3
 4# 1. clone ProCyon-Instruct 資料集（訓練/評估用的統一指令資料）
 5cd "$DATA_DIR"
 6git clone git@hf.co:datasets/mims-harvard/ProCyon-Instruct
 7
 8# 2. clone Llama-3-8B 權重（需先在 HuggingFace 申請權限）
 9cd /path/to/llama3/
10git clone https://huggingface.co/meta-llama/Meta-Llama-3-8B
11
12# 3. clone Llama-2-7b（若要用 ProCyon-Split 做基準測試）
13cd /path/to/llama2/
14git clone git@hf.co:meta-llama/Llama-2-7b-hf
15
16# 4. 回到 ProCyon 專案目錄，寫入 .env
17cd /path/to/ProCyon
18cat >> .env <<EOF
19DATA_DIR="$DATA_DIR/ProCyon-Instruct"
20HOME_DIR="$(pwd)"
21LLAMA3_PATH=/path/to/llama3/Meta-Llama-3-8B
22EOF

這裡的 .env 設計模式，跟 AIKT 專案自身的 .env.example 慣例是一致的——用環境變數管理機密路徑與大型資源位置，不寫死在程式碼裡。

3.5 驗證安裝是否成功

 1# 確認 Python 版本精確符合要求
 2python3 --version   # 應輸出 Python 3.11.9
 3
 4# 確認 transformers 版本鎖定在已知可重現的版本
 5python3 -c "import transformers; print(transformers.__version__)"
 6# 必須輸出 4.31.0，否則推論結果可能與論文不一致
 7
 8# 確認 procyon 套件可正常 import
 9python3 -c "import procyon; print('ProCyon package OK')"
10
11# 確認 GPU 與 CUDA 可用
12python3 -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

若上述四個檢查都通過，代表安裝環境已具備跑官方 demo notebook 的基本條件。

4. 基本使用 (Basic Usage)

4.1 快速入門：兩個官方 demo notebook

官方提供的最快上手路徑是兩份 Jupyter Notebook：

• examples/phenotype_generation.ipynb：給蛋白質序列，生成表型描述
• examples/retrieval.ipynb：給文字描述，檢索相關蛋白質

官方文件標注「兩個範例應在 5 分鐘內完成，視 GPU 速度」——這代表推論本身不慢，主要耗時是模型與資料載入。

4.2 範例一：載入模型並執行表型生成 (phenotype generation)

以下是根據官方 notebook 架構重建的概念範例（實際 API 細節請對照 notebook 版本更新）：

 1from procyon.model.model_unified import UnifiedProCyon
 2from procyon.data.inference_utils import build_generation_prompt
 3
 4# 載入 ProCyon-Full（會依 .env 中的 LLAMA3_PATH / DATA_DIR 找權重）
 5model = UnifiedProCyon.from_pretrained(
 6    checkpoint_dir="/path/to/model_checkpoints/ProCyon-Full",
 7)
 8model.eval()
 9
10# 一個生物醫學場景範例：分析 TP53（腫瘤抑制蛋白）的功能
11protein_sequence = (
12    "MEEPQSDPSVEPPLSQETFSDLWKLLPENNVLSPLPSQAMDDLMLSPDDIEQWFTEDPG..."
13)
14
15prompt = build_generation_prompt(
16    task="caption",
17    aaseq_type="protein",
18    text_type="go",          # 想生成 Gene Ontology 風格的功能描述
19)
20
21output = model.generate(
22    protein_seq=protein_sequence,
23    prompt=prompt,
24    max_new_tokens=128,
25)
26
27print(output)
28# 範例輸出（示意）：
29# "This protein functions as a transcription factor that regulates
30#  cell cycle arrest and apoptosis in response to DNA damage."

這裡的比喻：這一步就像把一段未知功能的蛋白質「拿去問一位資深生物學家」，請他用一句話總結這個蛋白質大概在幹什麼——只是這位「專家」是被訓練在數百萬筆蛋白質-功能標註資料上的模型。

4.3 範例二：疾病→蛋白質的檢索 (retrieval)

 1from procyon.inference.retrieval_utils import retrieve_top_k
 2
 3# 場景：藥物研發初期，想找出跟「第二型糖尿病」相關的候選蛋白質
 4results = retrieve_top_k(
 5    model=model,
 6    task_desc="Find proteins related to this disease",
 7    query_text="Type 2 diabetes mellitus",
 8    instruction_source_dataset="disgenet",  # 使用 DisGeNET 資料庫的指令格式
 9    k=20,
10)
11
12for rank, (protein_id, score) in enumerate(results, start=1):
13    print(f"{rank:2d}. {protein_id}  (相似度分數: {score:.4f})")

輸出格式示意：

1 1. P35558  (相似度分數: 0.8912)   # PCK1，糖質新生關鍵酶
2 2. Q99640  (相似度分數: 0.8734)   # PKMYT1
3 3. P06213  (相似度分數: 0.8601)   # INSR，胰島素受體
4 ...

4.4 範例三：透過本地 FastAPI 服務進行檢索（不寫 Python，直接呼叫 API）

專案內建了一個可直接啟動的本地 API 服務（procyon/app/main.py），這對不熟悉 Python 但想整合到其他系統（例如內部工具、Slack bot）的使用者特別方便：

1# 啟動本地 API 服務（會佔用 GPU 記憶體載入模型）
2cd procyon/app
3python main.py
4# 服務會在 http://localhost:8000 上線

用 curl 呼叫（跟前面 retrieval.ipynb 概念一致，但走 HTTP）：

1curl -X POST "http://localhost:8000/retrieve" \
2  -H "Content-Type: application/json" \
3  -d '{
4        "task_desc": "Find proteins related to this disease",
5        "disease_desc": "Major depressive disorder",
6        "instruction_source_dataset": "disgenet",
7        "k": 1000
8      }'

回傳的 JSON 會包含 Top-1000 個與「重度憂鬱症」相關性排序的蛋白質清單與分數——這對做全基因體規模的候選基因篩選 (genome-wide candidate screening; 全基因體候選篩選) 相當實用，不需要每次都重新載入模型。

4.5 輸入/輸出格式總結

5. 進階功能與應用場景 (Advanced Features & Use Cases)

5.1 進階配置：批量表型生成與 QA 過濾

對於需要大規模標註未知蛋白質功能的場景（例如剛完成新物種基因體測序後的功能註解），官方提供了批量腳本：

 1# 對整批未標註蛋白質做批量表型生成
 2python scripts/caption_bulk.py \
 3  --input_fasta unannotated_proteins.fasta \
 4  --checkpoint_dir /path/to/model_checkpoints/ProCyon-Full \
 5  --output_dir results/bulk_captions/ \
 6  --batch_size 32
 7
 8# 對生成結果做問答式品質過濾（篩掉生成內容與已知事實矛盾的結果）
 9python scripts/qa_filter_captions.py \
10  --caption_dir results/bulk_captions/ \
11  --output_dir results/filtered_captions/

這個「生成 → 用問答任務反過來驗證生成內容」的設計，概念上類似「自我一致性檢查 (self-consistency check; 自我一致性檢查)」——先讓模型生成一段描述，再拿同一個模型去問「這段描述裡提到的功能，這個蛋白質真的有嗎？」，用第二次推論結果過濾第一次生成的幻覺 (hallucination; 幻覺) 風險。這對生醫領域特別重要，因為錯誤的功能標註若被下游研究引用，成本很高。

5.2 應用案例一：藥物結合域預測 (drug-binding domain prediction)

examples/paper_analyses/drugdomain.ipynb 展示如何用 ProCyon-Bind 模型，針對一個蛋白質，預測其哪個結構域 (domain; 結構域) 最可能是藥物結合位點：

 1from procyon.model.model_unified import UnifiedProCyon
 2
 3model = UnifiedProCyon.from_pretrained(checkpoint_dir="/path/to/ProCyon-Bind")
 4
 5# 場景：藥物化學家想知道某個新發現的膜蛋白，哪個結構域適合設計小分子藥物
 6domain_predictions = model.predict_drug_binding_domains(
 7    protein_sequence=protein_seq,
 8    domain_annotations=pfam_domains,  # 來自 Pfam 資料庫的結構域邊界
 9)
10
11for domain, prob in domain_predictions:
12    print(f"結構域 {domain}: 藥物結合機率 {prob:.2%}")

5.3 應用案例二：蛋白質-胜肽結合預測 (protein-peptide binding)

examples/paper_analyses/prot_pep.ipynb 對應論文中「胜肽藥物 (peptide drug; 胜肽藥物)」的應用場景——這對做胜肽治療藥物開發（例如 GLP-1 類似物研發）的團隊特別相關，因為傳統胜肽-蛋白質結合預測工具往往需要大量結構資料，而 ProCyon 只需要序列與文字描述即可初篩。

5.4 應用案例三：多效性蛋白質檢索 (pleiotropic protein retrieval)

examples/paper_analyses/composition_retrieval.ipynb 展示一個進階檢索模式——組合式查詢 (compositional query; 組合式查詢)：例如「同時跟糖尿病與心血管疾病都有關」的蛋白質檢索，而非單一疾病查詢。這對研究多效性 (pleiotropy; 多效性) 基因（一個基因影響多個表型）特別有用，是傳統單資料庫查詢工具難以直接支援的功能。

5.4.1 應用場景總覽圖

把前面提到的三個應用案例（藥物結合域預測、蛋白質-胜肽結合、多效性蛋白質檢索）與基本使用範例放在同一張圖裡看，可以更清楚看出 ProCyon 的能力邊界與各場景所需的模型變體：

flowchart TD
    START["研究人員的具體問題"] --> Q1{"問題類型？"}

    Q1 -->|"想知道某蛋白質的功能是什麼"| U1["情境一：功能標註
caption 任務"]
    Q1 -->|"想找跟某疾病/藥物相關的蛋白質"| U2["情境二：候選靶點篩選
retrieval 任務"]
    Q1 -->|"想知道藥物該結合在哪個結構域"| U3["情境三：藥物結合域預測
ProCyon_Bind 模型"]
    Q1 -->|"想找同時影響多個疾病的基因"| U4["情境四：多效性蛋白質檢索
組合式查詢"]

    U1 --> M1["模型：ProCyon_Full
notebook：phenotype_generation.ipynb"]
    U2 --> M2["模型：ProCyon_Full
notebook：retrieval.ipynb 或 API"]
    U3 --> M3["模型：ProCyon_Bind
notebook：drugdomain.ipynb"]
    U4 --> M4["模型：ProCyon_Full
notebook：composition_retrieval.ipynb"]

    M1 --> OUT["輸出：自然語言描述/排序清單/機率分數"]
    M2 --> OUT
    M3 --> OUT
    M4 --> OUT

    OUT --> VERIFY["務必：領域專家人工複核
(不可直接當最終結論)"]

    style U1 fill:#DBEAFE,color:#0F172A
    style U2 fill:#D1FAE5,color:#0F172A
    style U3 fill:#FEF3C7,color:#0F172A
    style U4 fill:#FCE7F3,color:#0F172A
    style VERIFY fill:#DC2626,color:#FFFFFF

這張圖的重點在最下方的「務必人工複核」節點——不論走哪一條路徑，ProCyon 的輸出本質上都是機率性推論結果，而非資料庫查證後的既定事實，這一點在後面第 7 節「限制」中會再進一步說明。

5.5 與其他工具/函式庫的整合

flowchart LR
    A["ESM2/ESM3
蛋白質結構預測"] -->|"提供序列表徵基礎"| P["ProCyon"]
    B["AlphaFold
結構預測"] -.->|"互補：結構+功能"| P
    P -->|"檢索結果"| C["下游篩選 pipeline
(化學合成/毒理評估)"]
    P -->|"功能標註"| D["基因體註解流程
(新物種/新蛋白質)"]
    E["ToolUniverse/scikit-learn"] -.->|"評估框架整合"| P

    style P fill:#2563EB,color:#FFFFFF

ProCyon 的評估框架 (procyon/evaluate/framework/) 本身就設計成「模型視為黑盒 (black box; 黑盒)」的可插拔架構，官方文件明確說明可以透過實作 wrapper class 把其他第三方模型（如 ProtST、BioTranslator）納入同一套比較基準，這代表若要整合 ProCyon 到既有的蛋白質分析 pipeline（例如結合 AlphaFold 結構預測結果），架構上是可行的，只是需要額外寫 wrapper。

5.6 效能優化建議

• flash-attn 編譯：uv sync --extra compile 會編譯 flash-attn，可大幅降低 attention 計算的記憶體占用，長序列蛋白質（>1000 residues）建議務必啟用
• DeepSpeed 分散式訓練：configs/deepspeed/full_train_ds.json 顯示官方訓練用 DeepSpeed 做記憶體優化，若要重新訓練或微調，單卡 GPU 極可能吃不下 Llama-3-8B 規模的模型，需要多卡或 ZeRO 分片
• 蛋白質向量預先快取：若檢索任務的候選蛋白質池固定（例如整個人類蛋白質組），應將 ESM2 編碼結果離線算好存成向量索引，避免每次查詢都重跑蛋白質編碼器——這是所有向量檢索系統的標準優化，ProCyon 的 retrieval_utils.py 設計上也支援這種模式

6. AIKT 整合分析與策略 (AIKT Integration & Strategy)

6.1 整合架構圖：ProCyon 如何連接進 AIKT 27 層

flowchart TB
    subgraph ACQ["知識擷取層 L1-L3"]
        L2["L2 gh-save
抓取 ProCyon repo→教學md"]
        L9["L9 paper-search
抓取論文全文/引用"]
    end

    subgraph ORG["知識組織層 L4-L10"]
        L4["L4 graphify
建立 procyon 程式碼知識圖"]
        L6["L6 GitNexus
ProCyon 符號依賴圖"]
        L10["L10 paper-qa-lite
對 ProCyon 論文做本地 RAG 問答"]
    end

    subgraph OUT["專業輸出層 L11-L15"]
        L12["L12 gh-tutorial-qd
本篇教學文件生成"]
        L19["L19 tu-plan-generator
藥物開發計畫引用 ProCyon 檢索結果"]
    end

    subgraph EXT["外部：ProCyon 本體"]
        PROCYON["ProCyon 模型
GPU 推論服務
蛋白質-表型檢索/生成"]
    end

    L2 --> PROCYON
    L9 --> PROCYON
    PROCYON -->|"API 檢索結果
curl POST /retrieve"| L4
    PROCYON --> L10
    L4 --> L12
    L10 --> L12
    PROCYON -.->|"候選蛋白質清單"| L19

    style PROCYON fill:#DC2626,color:#FFFFFF
    style L12 fill:#2563EB,color:#FFFFFF
    style L19 fill:#7C3AED,color:#FFFFFF

關鍵理解：ProCyon 本身是一個需要 GPU、需要大量權重與資料集（>100GB）的科學計算模型，它不會、也不應該被「吸收」進 AIKT 的任何一層——AIKT 的角色是站在 ProCyon 之外，把「如何理解這個工具」「如何呼叫這個工具的結果」「如何把結果整理進研究產出」這幾件事自動化。

6.2 紅海分析 (Red Ocean Analysis)：功能重疊區

嚴格來說，ProCyon 與 AIKT 沒有直接的功能競爭，因為兩者屬於完全不同的軟體類別——一個是科學計算模型，一個是知識工作流編排系統。但若把「檢索」這個動作抽象化來看，仍有幾個值得比較的維度：

結論：這不是紅海，是完全不同的產品類別。唯一容易混淆的地方是「兩者都叫做 retrieval」，但 ProCyon 檢索的是「哪個蛋白質」，AIKT 的 paper-search/paper-qa-lite 檢索的是「哪篇文獻/哪段文字」。若使用者誤以為 AIKT 能取代 ProCyon 做蛋白質功能預測，那是對 AIKT 定位的誤解，需要在文件中明確澄清邊界，而非視為競爭關係去做功能取捨。

6.3 藍海策略 (Blue Ocean Strategy)：AIKT 可以獨特切入的機會

ProCyon 目前作為一個學術開源專案，在「知識工作流」這個維度上明顯不足，這正是 AIKT 的價值所在：

a) 未滿足的需求：ProCyon 缺乏「研究產出自動化」

ProCyon 的官方輸出是 Jupyter notebook 裡的 print 結果或 API 的 JSON——研究人員拿到一份 Top-1000 候選蛋白質清單後，仍要手動：

1. 逐一查詢每個蛋白質 ID 對應的已知功能（回頭查 UniProt）
2. 整理成可以放進研究報告或會議簡報的格式
3. 交叉比對文獻，確認候選蛋白質是否已有藥物開發先例

這一整套「拿到模型輸出之後要做的事」，正好對應到 AIKT 的多個層級：

• L9 paper-search + L10 paper-qa-lite：拿到 ProCyon 檢索出的候選蛋白質清單後，自動對每個蛋白質跑文獻搜尋，看是否已有相關藥物開發論文，省去研究人員逐一手動查詢的時間
• L19 tu-plan-generator：若候選蛋白質是藥物開發的潛在靶點，直接串接到藥物開發計畫生成流程，把 ProCyon 的模型輸出轉化為結構化的開發計畫草稿
• L11 kami：把 Top-K 檢索結果與相似度分數，自動排版成可以直接放進內部簡報的表格與圖表（kami 的品牌化文件輸出），取代研究人員手動複製貼上到 PowerPoint

b) 創造新價值的整合機會：「ProCyon 輸出 → AIKT 知識管線」轉接器

具體設計一個轉接腳本，概念如下（非現成程式碼，屬於策略層設計方向）：

flowchart LR
    A["ProCyon API
POST /retrieve"] --> B["procyon-to-aikt.sh
(建議新增的轉接腳本)"]
    B --> C["inbox/
ai-save 格式 md"]
    C --> D["L9 paper-search
逐一查詢候選蛋白質文獻"]
    D --> E["L10 paper-qa-lite
整合成問答摘要"]
    E --> F["L11 kami
輸出品牌化 PDF 報告"]

    style B fill:#DC2626,color:#FFFFFF
    style F fill:#2563EB,color:#FFFFFF

這個轉接器的價值在於：ProCyon 負責「找出候選蛋白質」這件只有它能做的科學計算，AIKT 負責「把候選結果變成可以交付給老闆/合作方的完整報告」這件它擅長的知識工作流自動化。兩者分工清楚，互不取代，反而互補。

c) 互補的 AIKT 層級

d) 具體的差異化策略

AIKT 不應該嘗試「重新實作」ProCyon 的任何模型能力（這是浪費資源且技術上不對等的競爭），而應該定位為「ProCyon 重度使用者的效率工具層」：

1. 短期：撰寫一份「如何在 AIKT 環境中設置 ProCyon 推論服務」的操作手冊（可用 L12 gh-tutorial-qd 這類流程產出，本文件即是第一步）
2. 中期：若團隊實際開始用 ProCyon 做候選蛋白質篩選，開發前述「procyon-to-aikt.sh」轉接腳本，串連 L9/L10/L11
3. 長期：若研究方向確立聚焦在蛋白質-表型/藥物關聯，考慮把 ProCyon 的 FastAPI 服務常駐化，並在 AIKT 中新增一個對應的 Layer（可透過 L26 layer-creator 走 checklist 流程），把「呼叫 ProCyon API」變成一個標準化的 prefix 觸發指令（例如 procyon: 前綴）

6.4 推薦整合方案：具體實施路徑

階段一（已完成於本次任務）：使用 L2 gh-save / gh-tutorial-qd 流程，產出本教學文件，作為團隊理解 ProCyon 能力邊界的起點。

階段二（建議，若確定要實際部署 ProCyon）：

1. 在具 GPU 的環境中依第 3 節步驟完成安裝，先用 examples/retrieval.ipynb 跑通最小可行範例
2. 針對團隊實際關注的疾病/藥物領域，設計 3-5 個檢索查詢，驗證 Top-K 結果的生物學合理性（找領域內同事複核，不能只信任模型分數）
3. 若驗證結果可靠，把 procyon/app/main.py 的 FastAPI 服務常駐化（建議用 Docker 容器化，符合全域規範「系統服務預設 Docker/Podman」）

階段三（建議，若進入常態使用）：

1. 開發 procyon-to-aikt.sh 轉接腳本，串連 ProCyon API 輸出到 L9/L10/L11
2. 評估是否值得走 L26 layer-creator 流程，正式新增一個 Layer 28（procyon: 前綴），將「候選蛋白質篩選→文獻驗證→報告產出」變成一鍵化流程

不建議做的事：不要嘗試在 AIKT 內重新訓練或微調 ProCyon 模型——這需要多卡 GPU、100GB+ 資料集與領域專業知識，遠超出 AIKT「知識工作流編排」的定位範圍，應該視 ProCyon 為外部黑盒服務調用，而非內部可修改的元件。

7. 效能、限制與替代方案 (Performance, Limitations & Alternatives)

7.1 效能數據

論文（bioRxiv 2024.12.10.627665）中報告 ProCyon 在多個評估任務上超越既有基準模型，包括：

• 蛋白質功能檢索任務上優於 ProtST、BioTranslator 等既有多模態蛋白質模型
• 在零樣本 (zero-shot; 零樣本) 與少樣本 (few-shot; 少樣本) 設定下皆展現優勢，這代表模型具備一定的泛化能力 (generalization; 泛化能力)，而非單純記憶訓練資料庫

注意：具體數值指標（如 Recall@K、BLEU、ROUGE 分數）建議直接查閱論文正文表格，本文件不做二次轉載以避免資料失真——若需精確數字，建議用 L10 paper-qa-lite 對論文全文做問答查詢。

7.2 已知限制

1. 計算資源門檻高：Llama-3-8B 規模的骨幹模型，推論本身就需要相當的 GPU 記憶體（8B 參數模型即使量化後也建議至少 16GB VRAM），訓練/微調需求更高
2. 版本鎖定嚴格：transformers==4.31.0 這類精確版本鎖定，代表這個環境很難跟其他也需要 transformers 的專案共用同一個虛擬環境，隔離成本高
3. 需要申請 Llama-3 存取權限：Meta 的審核流程可能需要等待，不是「clone 就能跑」的即時可用工具
4. 訓練資料截止時間：ProCyon-Instruct 資料集基於現有資料庫（GO、UniProt 等）在特定時間點的快照，資料庫持續更新，但模型不會自動同步最新標註——這跟所有基礎模型一樣有知識截止 (knowledge cutoff; 知識截止) 的限制
5. 生成內容仍可能有幻覺：即使官方提供 qa_filter_captions.py 做二次驗證，生成式模型的輸出仍需要領域專家複核，不能直接當作「已驗證事實」使用，尤其在做藥物開發決策這類高風險場景

7.3 與同類工具比較

7.4 何時使用 vs. 何時不使用

適合使用 ProCyon 的情境：

• 需要對大量未知功能蛋白質做初步功能標註（例如新物種基因體測序後）
• 需要根據疾病/藥物描述，快速篩選候選蛋白質靶點做後續實驗驗證
• 學術研究需要與既有基準模型（ProtST、BioTranslator）比較

不適合使用 ProCyon 的情境：

• 需要蛋白質三維結構預測 → 應使用 AlphaFold
• 只有 CPU 環境、無法申請 Llama-3 權限 → 考慮更輕量的替代方案，或先用既有資料庫（UniProt、GO）直接查詢
• 需要 100% 確定無誤的功能標註用於臨床決策 → 生成式模型的輸出必須經過人工/實驗驗證，不可單獨作為決策依據

8. 總結與建議 (Summary & Recommendations)

8.1 關鍵要點回顧

1. ProCyon 是一個蛋白質序列與表型文字的聯合基礎模型，核心貢獻在於把異質資料庫（GO、DrugBank、OMIM 等）統一成標準化的指令微調格式，訓練出能同時做檢索、問答、生成三種任務的通用模型
2. 架構上結合 ESM2（蛋白質編碼）與 Llama-3/Llama-2（文字理解與生成），透過對比學習 + M-LoRA 多任務適配整合兩種模態
3. 官方提供三個模型變體（Full/Split/Bind），分別對應生產使用、學術基準、藥物結合專項需求
4. 安裝門檻不低——需要 GPU、需要申請 Llama-3 存取權限、需要嚴格版本鎖定的環境，且資料集規模達 100GB+
5. 在 AIKT 生態系中，ProCyon 應被視為外部科學計算黑盒服務，AIKT 的價值在於把它的輸出轉化為可交付的研究報告，而非嘗試取代或重新實作其模型能力

8.2 最佳使用場景總結

如果你的研究團隊正在做：

• 藥物靶點初篩：用 ProCyon 的檢索功能快速從疾病描述找候選蛋白質，再串接 AIKT 的文獻搜尋做交叉驗證
• 新物種/新蛋白質功能註解：用批量生成腳本 (caption_bulk.py) 對大量未標註序列做初步功能猜測，再用問答過濾降低幻覺風險
• 學術基準測試：用 ProCyon-Split 搭配官方評估框架，與其他蛋白質語言模型做系統化比較

這些場景的共同特徵是：需要先有領域專家複核模型輸出的能力，ProCyon 提供的是「快速縮小候選範圍」的效率工具，而非「取代專家判斷」的自動化決策系統。

8.3 未來發展方向建議

1. 對 AIKT 團隊：若確定要在生技/製藥研究中重度使用 ProCyon，優先開發前述「procyon-to-aikt.sh」轉接腳本，把模型輸出自動接進既有的文獻驗證與報告產出流程，這是投資回報率最高的整合方向
2. 對關注 ProCyon 本身發展的使用者：留意 HuggingFace 上模型權重與資料集的更新頻率，以及 GitHub repo 的 issue 討論，特別是關於環境相容性（transformers 版本鎖定）的社群回報，因為這類基礎模型專案常見「官方環境凍結、周邊套件持續更新」導致的相容性問題
3. 長期觀察：蛋白質多模態基礎模型是快速發展的領域（ESM3、ProtGPT2 等競品持續推出），ProCyon 的差異化優勢在於「表型/疾病/藥物」這個特定應用軸線的資料整合深度，若後續有能力擴充更多資料庫來源（例如整合更多罕見病資料庫），競爭力會進一步提升

附錄：快速參考指令表

 1# 安裝
 2git clone https://github.com/mims-harvard/ProCyon.git && cd ProCyon
 3uv sync --extra build --extra compile
 4uv pip install -e .
 5
 6# 啟動本地 API 服務
 7cd procyon/app && python main.py
 8
 9# 呼叫檢索 API
10curl -X POST "http://localhost:8000/retrieve" \
11  -H "Content-Type: application/json" \
12  -d '{"task_desc": "Find proteins related to this disease", "disease_desc": "疾病名稱", "instruction_source_dataset": "disgenet", "k": 100}'
13
14# 批量表型生成
15python scripts/caption_bulk.py --input_fasta proteins.fasta --checkpoint_dir /path/to/ProCyon-Full --output_dir results/
16
17# 評估框架
18bash examples/evaluation/run_eval.sh

本教學文件由 AIKT (AI-Knowledge Template) Layer 12 (gh-tutorial-qd) 流程產出，資料來源為 mims-harvard/ProCyon 官方 GitHub repository 與 README，撰寫日期 2026-07-10。