在代谢组学项目中我们经常面临一个尴尬局面质谱仪能检测到数千个代谢物峰可真正能注释到结构、能连上代谢通路的往往不足三分之一。即使查到了 HMDB、KEGG、METLIN 这些数据库信息也是割裂的——一个库里能查到分子式另一个库里才有通路关系想把这些知识串起来基本靠人工查文献效率极低。MetaboLLM 这类“领域专用大语言模型”的出现正好提供了一种新思路让大模型学会生化知识再帮我们把零散的代谢物信息组织成可计算的图谱结构。本文不预设你已经掌握大模型原理会从概念、设计、代码到评估完整拆解这个问题希望能帮到正在做代谢组学数据分析或对“LLM 生信”交叉方向感兴趣的读者。1. 背景与核心概念1.1 代谢组学研究中的信息孤岛代谢组学metabolomics研究的是生物体内小分子代谢物的种类、含量及其动态变化。一次典型的非靶向代谢组学实验会从质谱数据中抽出几百到几千个特征峰后续分析链路大致是峰提取、对齐、去噪通过 m/z、保留时间、二级质谱碎片等信息进行代谢物注释将注释结果映射到代谢通路结合统计学与机器学习寻找差异代谢物。问题主要出现在第 2 步和第 3 步。注释依赖数据库而每个数据库都有自己的侧重点HMDB 长于人类代谢物注释KEGG 长于通路与基因关联METLIN 胜在二级谱图资源PubChem 则覆盖更广的化学结构信息。分析人员往往要在多个数据库之间来回切换手工拼接信息。即使完成了注释把代谢物之间的关系整理成图也很麻烦。代谢物之间的关系包括“共享同一反应”“同属一条通路”“结构相似”“浓度相关”等不同类型的关系需要不同的构建策略。传统的做法是写脚本读取数据库文件再按 ID 匹配关系过程繁琐且容易出错。1.2 为什么需要代谢组学专用大模型通用大语言模型large language modelLLM已经能回答很多通用问题但直接用在代谢组学场景中却不太顺手。原因有三专业术语理解不足。通用模型对“m/z 175.1195 [MH]”这类质谱信息缺乏可靠的先验知识容易产生错误推测结构化知识掌握有限。代谢通路、酶-底物关系、物种特异性代谢信息在通用语料中占比极小模型很难准确记忆输出格式不适用。做数据分析时我们需要的是清晰的结构化输出例如 JSON 格式的代谢物属性表、可导入图数据库的边关系列表而通用模型默认倾向于自由文本回答。MetaboLLM 的设计目标就是解决这三个问题。它通过领域语料继续训练continual pre-training和指令微调instruction tuning让模型掌握代谢物命名、结构表示、生化反应规则等知识同时学会把知识以结构化的形式输出服务于下游的预测性代谢物图构建predictive metabolite graph construction。1.3 MetaboLLM 是什么从论文标题可以看出MetaboLLM 的核心任务是两个生化知识整合biochemical knowledge integration把多来源、异构的代谢组学知识整合进大模型参数中预测性代谢物图构建predictive metabolite graph construction利用模型输出构建预测性的代谢物关系图用于下游分析。说得直白一点MetaboLLM 不是一套全新的模型架构而是面向代谢组学场景的“专业增强版 LLM”。它仍然以 Transformer decoder 为主干通过数据工程和微调策略让模型在代谢组学相关任务上表现更好。需要提醒的是这类模型往往还处于研究阶段论文开放的模型权重、训练数据、推理脚本可能并不完整。本文更侧重讲解它背后的通用技术思路这些思路可以直接迁移到你自己的代谢组学项目中。2. 模型设计与技术路线2.1 基座模型与领域适配MetaboLLM 本质上属于“垂直领域大模型”的构建思路。我们不需要从头训练一个几十亿参数的模型而是选择一个性能合适的基座模型再做领域适配。常见的基座选择包括LLaMA 系列开源生态好社区工具链成熟Mistral 系列推理效率高显存占用相对友好Qwen 系列中文和英文能力均衡如果后续要支持中文注释会更有优势。选择基座时要综合考虑三个因素参数量与显存预算。7B 级别的模型在单卡 A10040GB上即可做 LoRA 微调13B 以上则需要多卡或量化词表覆盖。基座模型的 tokenizer 是否需要包含 SMILES简化分子线性输入规范中常见的字符如果不包含需要在继续训练时扩展词表许可证。不同基座模型的开源协议不同商用之前要确认条款。从“领域专用大模型”的一般路线来看MetaboLLM 大概率遵循以下流程基座模型 ↓ 继续预训练代谢组学语料延续原有训练方式 ↓ 指令微调问答对 结构化输出要求 ↓ 人类反馈对齐可选提升回答贴合度 ↓ MetaboLLM2.2 代谢物表示SMILES、InChI 与文本化要让大模型理解代谢物首先需要确定代谢物的“文本表示形式”。代谢物本质上是有机分子计算机里常见的表示方式有表示方式示例特点SMILESCCO乙醇紧凑、可读性好、适合文本模型InChIInChI1S/C2H6O/c1-2-3/h3H,2H2,1H3规范性强、适合去重与匹配InChIKeyLFQSCWFLJHTTHZ-UHFFFAOYSA-N哈希形式数据库通用主键IUPAC 名称ethanol人类可读但命名规则复杂SDF/MOL 文件三维结构块适合计算化学软件不适合文本模型大模型适合处理 SMILES 和 IUPAC 名称因为它们是线性文本。InChI 虽然也是字符串但括号层级较多模型未必能很好地捕捉局部结构特征。一个合理的做法是把同一代谢物的多种表示方式组合成“多视角文本”。例如Metabolite: L-alanine SMILES: C[CH](N)C(O)O InChIKey: QNAYBMKLOCPYGJ-REOHCLBHSA-N Formula: C3H7NO2这种组合式输入能在不改变模型结构的前提下让模型同时学到命名、结构、化学式等多维信息。2.3 从通用 LLM 到领域 LLM 的微调思路严格来说微调并不是 MetaboLLM 独有的方法而是大模型落地到垂直领域的通用方法论。我们可以把它拆成三个层次第一层继续预训练Continual Pre-training。用大量领域语料继续训练基座模型让模型学习代谢组学领域的词汇、表达习惯和基础知识。这个阶段不需要构造问答对只要准备纯文本即可。第二层指令微调Instruction Tuning。构造“指令 输入 输出”格式的数据让模型学会按照指令完成任务。例如{ instruction: 根据给定的代谢物名称输出其 SMILES 结构和 PubChem CID。, input: L-alanine, output: SMILES: C[CH](N)C(O)O\nPubChem CID: 5950 }第三层任务微调Task-specific Tuning。针对特定下游任务做进一步微调。比如“从代谢物列表中预测可能存在的反应关系”这已经有图构建倾向了。MetaboLLM 的创新更多体现在“数据怎么构建”和“任务怎么设计”上而非模型结构本身。这也是领域大模型的主流发展方式。3. 生化知识整合3.1 多源数据库与知识图谱生化知识整合的第一步是数据收集。代谢组学相关的公共数据库丰富但格式差异很大HMDB人类代谢组数据库包含代谢物描述、浓度、疾病关联等KEGG代谢通路、反应、酶、基因等信息Reactome反应级知识库偏通路和反应过程Recon3D人类代谢重建模型适合做通量平衡分析MetaCyc代谢通路与酶的权威库PubChem化合物结构、生物活性数据。把这些数据库整合成模型训练语料需要做 many-to-many 的实体对齐。同一代谢物在不同数据库中有不同的 ID。例如葡萄糖在 HMDB 中可能对应 HMDB0000122在 KEGG 中对应 C00031在 PubChem 中对应 5793。实体对齐是整个数据管线里最耗时的一步。对齐之后可以进一步构建知识图谱KG把“代谢物 - 反应 - 酶 - 通路”的关系结构化(Glucose) --[participates_in]-- (Glycolysis) (Hexokinase) --[catalyzes]-- (Glucose - Glucose-6-phosphate)知识图谱既可以作为模型训练时的高质量语料也可以作为评估模型输出正确性的基准。3.2 指令微调数据构造知识整合能否成功关键在于指令数据质量。实际构建时我们可以设计几类典型任务实体属性问答{ instruction: 回答该代谢物的分子式。, input: Adenosine triphosphate, output: C10H16N5O13P3 }关系抽取{ instruction: 给定两个代谢物判断它们在糖酵解通路中是否存在相邻的反应关系。, input: Glucose-6-phosphate; Fructose-6-phosphate, output: 是二者在糖酵解中通过磷酸己糖异构酶相连。 }数据库记录整合{ instruction: 根据多个数据库信息整理该代谢物的完整档案。, input: Lactate, output: HMDB: HMDB0000190\nKEGG: C00186\nSMILES: CC(O)C(O)O\n相关通路: 糖酵解/糖异生、丙酸代谢 }构造数据时要注意三点错误数据清洗。数据库本身也有错误跨库 ID 对应关系可能不准确需要设计交叉校验负样本构造。关系抽取任务中只给正样本会让模型产生“什么都相关”的幻觉要加入不相关代谢物对作为负样本物种特异性。人类和细菌的代谢网络差异很大指令中必须显式指明物种背景否则模型会混杂不同物种的知识。3.3 知识注入的方式知识注入有两种主流方式参数化注入和检索增强。参数化注入指通过微调把知识写进模型权重。优点是推理时不需要外部查询速度快缺点是训练成本高且模型会遗忘部分旧知识灾难性遗忘更新知识需要重新微调。检索增强Retrieval-Augmented GenerationRAG指在推理阶段先从外部数据库中检索相关内容再拼接到提示词中交给模型生成。优点是知识更新方便、可溯源缺点是需要额外搭建检索系统推理延迟增加。MetaboLLM 这类模型大概率以参数化注入为主因为它的定位就是知识整合与图构建需要模型对代谢知识有稳定的内部表示。但在工程项目中更稳妥的做法是“参数化 检索增强”混合常见知识靠模型记忆冷门或更新频繁的知识靠检索补充。4. 预测性代谢物图构建4.1 代谢物图构建的难点代谢物图metabolite graph是把代谢物当作节点、代谢物间关系当作边的网络结构。图的构建质量直接决定了后续的网络分析、模块识别、通路富集是否可靠。传统构建方式主要有两种基于数据库的映射。把注释到的代谢物映射到 KEGG 或 HMDB 中按照数据库中已有的反应关系连边。这种方法的局限是注释不到的代谢物无法入图数据库覆盖不足的物种构建结果会很稀疏基于统计相关性。根据代谢物浓度变化计算相关矩阵超过阈值的则连边。这种方法的局限是“相关性不等于因果关系”很容易产生假阳性边。预测性图构建的思路是把“节点之间是否可能有关系”当作一个预测任务用大模型来打样。MetaboLLM 的角色就是根据代谢物名称、结构、已知知识预测它们之间可能存在的关系类型从而补全或增强已有图结构。4.2 结合 LLM 的图构建策略可以设计这样一个多阶段管线第一阶段候选关系生成。将代谢物两两组合让模型判断它们是否存在某种关系。如果有 n 个代谢物两两组合数量为 n(n-1)/2数量较大时可以通过结构相似性、通路共现做预筛减少候选数。第二阶段关系类型分类。对存在关系的代谢物对进一步判断关系类型。常见的关系类型包括共享同一代谢通路一个代谢物是另一个的前体或产物结构相似例如同系物存在共同调控机制未知但预测相关。第三阶段置信度输出。模型不仅输出“是/否”还要给出置信度分数便于下游分析设置阈值。一个简化的关系判断提示词可以这样设计你是代谢组学知识库。判断代谢物 A 和代谢物 B 之间是否存在已知或可预测的代谢关系。 代谢物 A: Pyruvate 代谢物 B: Acetyl-CoA 回答格式JSON { related: true, relation_type: precursor_product, description: 丙酮酸在丙酮酸脱氢酶复合体催化下氧化脱羧生成乙酰辅酶A。, confidence: 0.92 }模型输出后用程序解析 JSON按关系类型和置信度筛选边最终构建出预测性代谢物图。4.3 图构建代码示例这里用 NetworkX 展示把模型输出解析为图结构的过程。假设我们已经通过批处理调用了大模型并把结果保存在一个 JSONL 文件中。import json import networkx as nx # 读取模型预测结果 predictions [] with open(metabolite_relations.jsonl, r, encodingutf-8) as f: for line in f: predictions.append(json.loads(line)) # 初始化有向图 G nx.DiGraph() for item in predictions: meta_a item[metabolite_a] meta_b item[metabolite_b] related item[related] confidence item.get(confidence, 0.0) relation_type item.get(relation_type, unknown) # 只保留高置信度的正关系 if related and confidence 0.7: G.add_edge(meta_a, meta_b, relationrelation_type, weightconfidence) print(f节点数: {G.number_of_nodes()}) print(f边数: {G.number_of_edges()}) # 保存为 GraphML方便导入 Gephi 或 Cytoscape nx.write_graphml(G, predictive_metabolite_graph.graphml)节点和边的统计输出类似于节点数: 128 边数: 342如果你要导入 Neo4j 这类图数据库也可以把边列表导出为 CSVimport csv with open(edges.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([source, target, relation, weight]) for u, v, data in G.edges(dataTrue): writer.writerow([u, v, data.get(relation, ), data.get(weight, )])5. 核心代码复现思路5.1 环境准备如果你打算在自己的数据上复现类似 MetaboLLM 的微调和推理流程建议按以下环境准备操作系统Ubuntu 20.04 / 22.04或 Windows WSL2GPUNVIDIA 显卡显存建议 24GB 以上至少支持 CUDA 11.8 或更高版本Python3.10 或 3.11深度学习框架PyTorch 2.x大模型工具库transformers、peft、accelerate、bitsandbytes化学信息学工具RDKit图分析工具NetworkX、igraph。不建议在 CPU 环境执行完整微调但推理和数据处理可以。版本方面我以“常见稳定版”举例实际安装时请以官方最新 release 为准。安装核心依赖的命令pip install torch transformers peft accelerate bitsandbytes pip install rdkit networkx pandas5.2 数据准备微调的第一步是准备训练集。假设我们要训练模型完成“代谢物属性问答”任务。数据文件采用 JSONL 格式每行一个样本{instruction: 回答该代谢物的分子式和 SMILES。, input: Citric acid, output: 分子式: C6H8O7\nSMILES: OC(O)CC(O)(CC(O)O)C(O)O} {instruction: 回答该代谢物的分子式和 SMILES。, input: Oxaloacetic acid, output: 分子式: C4H4O5\nSMILES: OC(O)C(O)CC(O)O}注意这些数据可能来自数据库导出你需要编写一个转换脚本把数据库文本转换成上面的格式。转换时建议保留来源字段方便后期回溯。5.3 LoRA 低秩微调完整微调大模型的成本很高因此实践中广泛使用 LoRALow-Rank Adaptation方式。LoRA 的思想是冻结原模型参数只在注意力层的权重矩阵旁边增加低秩分解矩阵只训练这些新增参数。以下代码演示了基于 HuggingFace PEFT 库的 LoRA 微调核心流程。import torch from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 以 7B 级模型为例实际模型名请按你的选择调整 model_name meta-llama/Llama-2-7b-hf tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) # 冻结原模型参数 model prepare_model_for_kbit_training(model) # LoRA 配置 lora_config LoraConfig( r8, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters()运行这段代码会输出类似trainable params: 4,194,304 || all params: 6,742,609,920 || trainable%: 0.0622也就是说我们只训练了约 400 万参数约占模型总参数的 0.06%。这是 LoRA 的核心价值用极低的训练成本实现领域适配。5.4 推理与结构化输出微调完成后可以编写推理脚本验证模型效果。from transformers import AutoTokenizer, AutoModelForCausalLM from peft import PeftModel import json base_model_name meta-llama/Llama-2-7b-hf lora_model_path ./metabollm-lora tokenizer AutoTokenizer.from_pretrained(base_model_name) model AutoModelForCausalLM.from_pretrained( base_model_name, torch_dtypetorch.float16, device_mapauto ) model PeftModel.from_pretrained(model, lora_model_path) prompt 你是代谢组学知识库。根据代谢物名称输出标准化信息。 代谢物: L-alanine 输出 JSON 格式: {name: ..., formula: ..., smiles: ..., inchi_key: ...} inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokens128, temperature0.1, do_sampleTrue ) response tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) print(response) # 尝试解析 JSON try: parsed json.loads(response) print(解析成功:, parsed) except json.JSONDecodeError: print(模型输出不是合法 JSON需要后处理)这里需要提醒的是大模型输出 JSON 并不总是稳定的。实际工程中应该加一层解析兜底逻辑比如从输出中提取{...}片段后再用json.loads解析并对缺失字段做默认值填充。6. 评估方法6.1 知识问答评估评估 MetaboLLM 的知识整合质量可以沿用大模型评估的常见思路但要结合领域特点。通常可以从三个维度展开准确性。模型回答的分子式、SMILES、数据库 ID 是否与权威数据库一致。评估时可以用 RDKit 做 SMILES 的规范化和等价性比较而不是简单字符串匹配完整性。对于“整理该代谢物档案”这类任务回答是否覆盖了分子式、结构、通路、相关疾病等关键字段格式合规性。在结构化输出任务中JSON 是否能被直接解析字段是否齐全。准确性评估示例from rdkit import Chem def smiles_equivalent(smiles_a, smiles_b): mol_a Chem.MolFromSmiles(smiles_a) mol_b Chem.MolFromSmiles(smiles_b) if mol_a is None or mol_b is None: return False return Chem.MolToInchi(mol_a) Chem.MolToInchi(mol_b) model_smiles C[CH](N)C(O)O true_smiles C[CH](N)C(O)O print(SMILES 等价:, smiles_equivalent(model_smiles, true_smiles))6.2 图构建评估对于预测性代谢物图构建评估的重点是边预测的质量。一种可行的评估方案是从参考知识图谱中划分训练边和测试边让模型预测测试边是否存在。然后计算 Precision、Recall、F1 等指标。from sklearn.metrics import precision_score, recall_score, f1_score y_true [1, 0, 1, 1, 0, 1] y_pred [1, 0, 0, 1, 1, 1] print(Precision:, precision_score(y_true, y_pred)) print(Recall:, recall_score(y_true, y_pred)) print(F1:, f1_score(y_true, y_pred))也可以做更偏应用层面的评估把模型补全后的图与数据库原始图对比检查新增边的合理性。具体操作上建议先把模型预测的新边抽样 50 到 100 条请领域专家或通过文献检索验证看这些边是否有生化依据。7. 常见问题与排查思路在实际复现这类项目时比较容易踩坑。我整理了一份排查表问题现象常见原因解决思路显存不足CUDA out of memory模型参数量过大或 batch size 偏大降低 batch size使用 gradient checkpointing改用 4bit 量化加载LoRA 训练后模型效果没有提升数据量太少或任务设计不合理检查训练数据是否有正确答案增加样本量确认 target_modules 与实际模型结构匹配SMILES 解析失败模型生成的 SMILES 语法错误用 RDKit 校验并清洗多次采样取合法结果必要时加入后处理修正JSON 输出不合法解码参数温度过高或模型未充分对齐调低 temperature增加 Few-shot 示例或使用输出约束解码代谢物 ID 对不上不同数据库 ID 映射不完整建立离线 ID 映射表优先使用 InChIKey 作为统一主键图中出现大量假阳性边模型过度预测关系提高置信度阈值或加入通路共现预筛条件中文输入效果差基座模型中文能力弱或词表覆盖不足换用中文能力更强的基座模型或在继续预训练阶段加入中文代谢组学语料如果在微调阶段遇到 loss 不下降的情况按以下顺序排查检查数据是否存在大量相同标签、相同输入检查 tokenizer 是否正确处理 SMILES 特殊字符尤其是、#、/、\等符号检查学习率是否过高或过低LoRA 微调通常使用 1e-4 到 3e-4 区间如果数据量小于几千条先考虑用较大模型做零样本/少样本测试不做微调。8. 应用场景与工程建议8.1 典型应用场景MetaboLLM 这类领域大模型在实际工作中能够派上用场的场景包括代谢物注释报告生成。把质谱鉴定结果传入模型自动生成包含结构信息、通路注释、生物学意义的中文或英文报告知识图谱补全。在已有代谢网络上预测缺失的边帮助发现潜在的代谢通路新连接差异代谢物功能解读。从差异代谢物列表出发让模型归纳关键通路和生物学主题质谱数据预处理问答。把参数调整问题交给模型例如“如何优化色谱分离度”“怎样选择内标”等教学和知识库检索增强。针对代谢组学课程或实验室新人培训搭建问答助手。8.2 工程落地建议如果你准备把这类技术落地到自己的项目里以下几点值得重视第一数据安全。代谢组学数据可能来自医院或合作单位涉及受试者隐私。如果数据不能出域就不要直接调用外部大模型 API应当在本地部署开源模型并微调。第二知识更新的持续性。代谢组学数据库是不断更新的如果模型只做了参数化知识注入知识就会过时。生产中要设计“定期重训”或“检索增强兜底”机制。第三错误容忍设计。大模型输出不可能完全正确尤其在生成 SMILES 和数据库 ID 时必须设计校验和人工复核环节不能直接进入下游分析流程。第四成本控制。微调和推理都需要 GPU 资源建议先用小规模数据验证可行性再投入全量数据训练。日常推理优先使用低精度量化4bit 或 8bit降低部署成本。第五可复现性。训练时要固定随机种子记录数据版本、基座版本、微调超参数方便后续追溯和复现。9. 总结与学习路线MetaboLLM 代表了一类重要的研究方向把通用大模型改造成具备领域深度知识的专用工具。在代谢组学场景中它解决了知识分散、结构化输出困难、图构建低效这三个核心痛点。如果你正在学习这个方向我认为可以按下面的路线推进第一步掌握大模型基础。熟悉 Transformers 架构、注意力机制、tokenizer 原理能够用 HuggingFace 加载和运行模型。第二步掌握 LoRA 微调。用公开数据集做一次完整的指令微调实验理解数据格式、训练参数和推理方式。第三步学习代谢组学数据基础。了解质谱数据格式mzML、mzXML、代谢物注释流程、公共数据库的下载与解析。第四步整合两者。构造 500 到 1000 条代谢组学指令数据在基座模型上做 LoRA 微调并评估效果改善幅度。第五步实现图构建。把你微调后的模型接入图构建管线在真实数据集上验证边预测的准确率。我的建议是先不要追求复现一个完整的 MetaboLLM而是从一个最小闭环开始用 100 条数据微调验证流程能跑通再逐步扩大数据规模和任务复杂度。领域大模型的魅力在于哪怕只注入了一小部分高质量领域知识模型在对应任务上的表现都会有明显提升。如果你在实践过程中遇到问题也欢迎在评论区交流。觉得有收获的话可以收藏备用后续我会继续分享代谢组学与深度学习结合的相关内容。