关于preprocess_input_data.py中line255的注释的疑问

[Vectolyser]

您好，在preprocess_input_data.py中255行开始有“# here we remove +1 as same row represents bn, yn-1, n is the length of amino acids” 的注释，应该是针对上一行的“max_phos_index”的吧？但是我还是不理解为什么这里的max_phos_index不需要+1。您可以做出更详细的解释吗？谢谢！

[gureann]

我也不太理解这个注释，不过可能

1. 不需要+1指的是max_phos_index是0起始的index，而且self.y也就是pep_len \times 8 的intensity matrix的第一行定义为了b_0和y_n，所以在[max_phos_index: ]这里左开区间刚好不需要+1
2. bn, yn-1应该指的是b_i所在的行对应的y离子是y_{n-i}，这里n是肽段原始序列长度

可以举一个例子

• 假设我们有一个肽段序列长度是20，因为我们在肽段序列前面加了@或者*来表示没有或者有Acetyl的N端修饰，所以实际肽段长度会记为21（这里和前面的n不一样）
• 如果只有一个修饰在第5个残基，min_phos_index和max_phos_index因为取的是0起始的index，而且算上起始的一个修饰字符，所以都是5
• 之后在处理intensity matrix的时候，第0行和第20以后的行都会被mask，第5行是b_4所以这一行和之前行的b离子都被mask，第6行是y_15所以这一行和之后的行都被mask

[Vectolyser]

我也不太理解这个注释，不过可能

1. 不需要+1指的是max_phos_index是0起始的index，而且self.y也就是pep_len \times 8 的intensity matrix的第一行定义为了b_0和y_n，所以在[max_phos_index: ]这里左开区间刚好不需要+1
2. bn, yn-1应该指的是b_i所在的行对应的y离子是y_{n-i}，这里n是肽段原始序列长度

可以举一个例子

• 假设我们有一个肽段序列长度是20，因为我们在肽段序列前面加了@或者*来表示没有或者有Acetyl的N端修饰，所以实际肽段长度会记为21（这里和前面的n不一样）
• 如果只有一个修饰在第5个残基，min_phos_index和max_phos_index因为取的是0起始的index，而且算上起始的一个修饰字符，所以都是5
• 之后在处理intensity matrix的时候，第0行和第20以后的行都会被mask，第5行是b_4所以这一行和之前行的b离子都被mask，第6行是y_15所以这一行和之后的行都被mask

感谢。还有一个问题，我使用预训练模型对一个library（使用DIA-NN的DIAUmpire生成）进行40个epoch的微调然后再预测该library，效果比直接拿预训练模型预测要差（DIA-NN鉴定出的肽段变少），这是正常的吗？正确的方法应该是怎么做的呢？

[gureann]

这样其实就是把一个DIA数据来源的library里的谱图和RT替换成了预测值，从检索来看的话应该会和之前相似，多一点和少一点都有可能，我觉得整体是会和DIA数据量和质量相关

不过DIA-NN生成的library本身就是谱图和RT都经过DIA数据修正过的（如果DIA-NN的library generation是默认设置），这个时候其实替换成预测值对检索有不好影响也是符合预期的，有两个比较直观的原因，一个是预测值和实验重复确实有一定的偏差（AlphaPeptDeep），另一个是在其他工作里也有experimental library替换成predicted library之后检索肽段变少的结果（DeepDIA和Deep4D） experimental library信息的全替换的一个应用其实是大规模DDA数据构建的library应用在DIA数据上的时候，对谱图和RT的一定校正

[gureann]

使用预训练模型对一个library（使用DIA-NN的DIAUmpire生成）进行40个epoch的微调然后再预测该library

还有这个DIA-NN生成的library应该是DIA-NN根据你设置的条件从头预测一个library然后检索DIA数据之后，把DIA数据检索得到的谱图和RT替换掉原始预测library得到的，不是DIA-Umpire 不过FragPipe里有DIA-Umpire+MSFragger+DIA-NN这个流程

[Vectolyser]

使用预训练模型对一个library（使用DIA-NN的DIAUmpire生成）进行40个epoch的微调然后再预测该library

还有这个DIA-NN生成的library应该是DIA-NN根据你设置的条件从头预测一个library然后检索DIA数据之后，把DIA数据检索得到的谱图和RT替换掉原始预测library得到的，不是DIA-Umpire 不过FragPipe里有DIA-Umpire+MSFragger+DIA-NN这个流程

抱歉这里说错了，使用的是FragPipe的DIA-Umpire生成的library。该library本身能鉴定5193个肽段，预训练模型预测library能鉴定4869个肽段，结果用library本身微调后的模型预测library却只能鉴定到4663个肽段。按理说微调后的模型在参数更新后，仍然保留了从大量肽段中学习到的特征，所以可以鉴定到原来不能鉴定到的肽段，使总量上升。实际上确实会鉴定到一些新肽段，但是这个总量下降太厉害了，我很疑惑

[gureann]

有可能是过拟合了，library不大的话其实训练不是很稳定，现在模型会保留40个epoch里validation最好的一个 如果需要fine-tune可以考虑把epoch和学习率调小一点，epoch可能5到10就可以了，学习率默认是1e-4可以用5e-5 另外也可以看一下三个检索结果里肽段的重合情况，还有DIA-NN对原始library>预训练>fine-tune这三个结果肽段打分的分布 之前有一个差不多大小的数据，从DIA建的library可以检索到大概6800肽段，替换成predicted大概少240，不过这个只测了fine-tune之后的，没有看pre-train

[Vectolyser]

有可能是过拟合了，library不大的话其实训练不是很稳定，现在模型会保留40个epoch里validation最好的一个 如果需要fine-tune可以考虑把epoch和学习率调小一点，epoch可能5到10就可以了，学习率默认是1e-4可以用5e-5 另外也可以看一下三个检索结果里肽段的重合情况，还有DIA-NN对原始library>预训练>fine-tune这三个结果肽段打分的分布 之前有一个差不多大小的数据，从DIA建的library可以检索到大概6800肽段，替换成predicted大概少240，不过这个只测了fine-tune之后的，没有看pre-train

好的。我也在研究类似课题，您觉得在模型结构参数合理，数据集优秀的情况下，可能训练出一个性能比DIA-Umpire或者是dDIA更好的模型吗？（指能鉴定出更多的肽段）

[gureann]

模型结构参数合理，数据集优秀

这个条件下是可以训练一个模型在各种模型性能测试里表现地很好，只是这个模型结构和数据集的前提很难量化，怎样的模型结构和怎样质量的数据集会得到一个好的预测模型

性能比DIA-Umpire或者是dDIA更好的模型

如果是对下游应用来说，DIA数据质量越高这个目标会越难达到 一个是色谱只要稳定，DIA数据自身构建的library的RT就总是能提供相当好的检索条件；另外质谱仪器信号稳定而且离子累积时间和碎裂这些条件都达到某个及格线的时候，提取的谱图质量也是足够的 这个时候替换DIA library里的信息应该不会提供什么检索优势

[Vectolyser]

模型结构参数合理，数据集优秀

这个条件下是可以训练一个模型在各种模型性能测试里表现地很好，只是这个模型结构和数据集的前提很难量化，怎样的模型结构和怎样质量的数据集会得到一个好的预测模型

性能比DIA-Umpire或者是dDIA更好的模型

如果是对下游应用来说，DIA数据质量越高这个目标会越难达到 一个是色谱只要稳定，DIA数据自身构建的library的RT就总是能提供相当好的检索条件；另外质谱仪器信号稳定而且离子累积时间和碎裂这些条件都达到某个及格线的时候，提取的谱图质量也是足够的 这个时候替换DIA library里的信息应该不会提供什么检索优势

好的。我注意到就算模型鉴定肽段总量更少，但相比原来也会多出一些本不存在的肽段。那么可不可以让模型先判断一条肽段的子离子信息，是预测的还是原来的更好，做一个取舍，生成一个预测和原本的融合库，这样会更容易接近“鉴定出更多肽段”的目标 ？

[gureann]

这样确实是可行的，而且与其说是判断预测的谱图和原始谱图哪个好，应该说是哪个谱图在当前library包含的信息的context下，以某一个检索软件的算法得到的打分是可以达到某个预期目标的，比如让整体鉴定提升这个目标

不过也有一些不能说难解决但是不好处理的问题，比如一个“融合库”是不是对任何来源的谱图是鉴定上公平的，而且这个流程也会增加额外的计算成本

[Vectolyser]

这样确实是可行的，而且与其说是判断预测的谱图和原始谱图哪个好，应该说是哪个谱图在当前library包含的信息的context下，以某一个检索软件的算法得到的打分是可以达到某个预期目标的，比如让整体鉴定提升这个目标

不过也有一些不能说难解决但是不好处理的问题，比如一个“融合库”是不是对任何来源的谱图是鉴定上公平的，而且这个流程也会增加额外的计算成本

好的。在ion_train.py中我注意到line358的scheduler.step()，放在了每个batch之后，但一般不是放在每个epoch之后吗，这一点不太理解

[gureann]

这个应该都可以吧，如果都放在epoch end，那只有1个epoch的LLM不就没有scheduler了 主要还是看具体任务和参数，比如在batch end update scheduler的话，一个简单的cyclical可以设置成1000 step的周期，那对应一个500 batch的dataset就是2个epoch

[Vectolyser]

这个应该都可以吧，如果都放在epoch end，那只有1个epoch的LLM不就没有scheduler了 主要还是看具体任务和参数，比如在batch end update scheduler的话，一个简单的cyclical可以设置成1000 step的周期，那对应一个500 batch的dataset就是2个epoch

理解了。在这个项目中包含了RT的训练和预测，我想知道这项工作一开始是在控制变量的情况下开展的吗？（例如只替换原来library的RT值而不替换intensity，然后对比性能），对RT的预测任务现在是否还有很大的进步空间？

[gureann]

只替换原来library的RT值而不替换intensity，然后对比性能

最开始的时候是做过这样的测试的，结论是大规模DDA library这种RT和DIA数据偏移比较大的情况下是有用的，需要用DIA数据fine-tune一下model 替换一个质量很好的library的结果可以参考这篇Deep4D，替换部分信息确实可能会带来一定的负面影响，DIA library本身的RT替换也是这样

RT的预测任务现在是否还有很大的进步空间

这个要看从哪个方面入手，如果是模型性能或者说预测精度的话，提升空间不算太大但也不是没有，比如AlphaPeptDeep里其实也能看出来预测精度还有提升空间 不过这个任务不像是CV和NLP里那些可以提升1%就很好了，提升一点精度对需要RT的下游任务有什么帮助也很难说，而且还有一个问题是LC本身就是不够稳定的，可能label本身就不够准确，倒不如说如果一个模型能对RT数据集达到比现在好很多的精度，更应该怀疑是过拟合了 现在RT预测的主要应用应该还是从序列构建library，优化DDA library的RT，辅助DDA检索打分，还有PRM schedule list，比起RT预测本身，优化下游任务的用处还是更大一些的（虽然现在基本能做的都做过了

[Vectolyser]

只替换原来library的RT值而不替换intensity，然后对比性能

最开始的时候是做过这样的测试的，结论是大规模DDA library这种RT和DIA数据偏移比较大的情况下是有用的，需要用DIA数据fine-tune一下model 替换一个质量很好的library的结果可以参考这篇Deep4D，替换部分信息确实可能会带来一定的负面影响，DIA library本身的RT替换也是这样

RT的预测任务现在是否还有很大的进步空间

这个要看从哪个方面入手，如果是模型性能或者说预测精度的话，提升空间不算太大但也不是没有，比如AlphaPeptDeep里其实也能看出来预测精度还有提升空间 不过这个任务不像是CV和NLP里那些可以提升1%就很好了，提升一点精度对需要RT的下游任务有什么帮助也很难说，而且还有一个问题是LC本身就是不够稳定的，可能label本身就不够准确，倒不如说如果一个模型能对RT数据集达到比现在好很多的精度，更应该怀疑是过拟合了 现在RT预测的主要应用应该还是从序列构建library，优化DDA library的RT，辅助DDA检索打分，还有PRM schedule list，比起RT预测本身，优化下游任务的用处还是更大一些的（虽然现在基本能做的都做过了

好的。请问这个模型使用多大的数据集进行训练呢？为什么选择这个大小的数据？