【问题标题】:Keras history order problem when saving to GDrive保存到 GDrive 时的 Keras 历史顺序问题
【发布时间】:2019-04-27 15:43:18
【问题描述】:

我的目标是在每个 epoch 之后将 Keras 日志(准确性、损失等)保存到 Google Drive

我正在使用以下代码:

from google.colab import drive
drive.mount('/content/drive')

class HistoryCallback(callbacks.Callback):
    def on_epoch_end(self, epoch, logs={}):
        with open("drive/My Drive/"+csv_path, "a") as myfile:
            myfile.write(str(epoch)+","+str(logs)+"\n")

classifier.fit_generator(..., callbacks=[HistoryCallback()])

在我的驱动器上,我有时会得到奇怪的输出,如下所示:

25  {'acc': 0.963835932997043   loss': 0.10425430848152908  val_acc': 0.7071953016230713    val_loss': 1.1386645126622854   lr': 2.3961632e-06}

2366427 loss': 1.1117452404459112   val_acc': 0.5577092514076597    val_loss': 1.0548135743792362   lr': 4.980681e-06}  
2   {'acc': 0.6330444829612712  loss': 0.9205646275682026   val_acc': 0.5994126287500939    val_loss': 0.9518886575614829   lr': 4.956604e-06}
3   {'acc': 0.6983824379057777  loss': 0.7753418573921365   val_acc': 0.6314243757777277    val_loss': 0.8930798317542336   lr': 4.923029e-06}
4   {'acc': 0.7437319468601393  loss': 0.6659318362681732   val_acc': 0.6464023491359492    val_loss': 0.866631023106596    lr': 4.8800885e-06}
5   {'acc': 0.7798526863016054  loss': 0.5813610065455109   val_acc': 0.6637298091742786    val_loss': 0.8554121221564764   lr': 4.8279526e-06}
6   {'acc': 0.8090410167584868  loss': 0.5098161270401851   val_acc': 0.6657856092579039    val_loss': 0.8496283279291509   lr': 4.7668264e-06}
7   {'acc': 0.8317157712132858  loss': 0.45465362796302755  val_acc': 0.6734214392352559    val_loss': 0.8745797048056179   lr': 4.6969512e-06}
8   {'acc': 0.8491478913819287  loss': 0.4042509938624124   val_acc': 0.688986784105959 val_loss': 0.8465897937878288   lr': 4.6186033e-06}
....

如您所见,排序混乱,缺少 epoch 0,2366427 是缺少 epoch 编号和前面几个数字的准确率的一部分

有没有人遇到过这种情况并知道如何处理?

编辑: 我注意到,经过一些时期后,GDrive 上的文件也是 0 字节,然后在下一个时期它被填满

【问题讨论】:

    标签: callback keras google-colaboratory


    【解决方案1】:

    猜测:您的训练是在多个线程/子进程中进行的,因此您的 on_epoch_end 正在与自己作斗争 - 并发执行的副本都在“追加”模式下打开同一个文件,并且(部分)覆盖彼此的输出. 如果您写入 per-epoch 文件或以其他方式序列化输出,问题会消失吗?

    【讨论】:

    • 有趣的想法,但是为什么 on_epoch_end 会被多次执行呢?我不认为这是问题
    猜你喜欢
    • 2017-04-24
    • 1970-01-01
    • 2018-10-12
    • 2019-06-18
    • 2019-04-04
    • 2020-06-28
    • 2011-05-30
    • 1970-01-01
    相关资源
    最近更新 更多