-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not perform reverse update weights. #13364
Comments
@cainiao123s hello, Thank you for providing detailed information about your issue. It seems you are encountering variability in loss values across epochs even though the model parameters are not being updated. This can happen due to several reasons, even with a fixed seed:
To further investigate, you might want to ensure that all data loading and augmentation steps are deterministic. Also, check if any external libraries or functions you use in the data preprocessing or loss computation might introduce randomness. If the issue persists, providing more details about the data handling and any preprocessing steps might help in diagnosing the problem more effectively. |
After a long time of effort, I found that it is very likely that the data will be processed for each epoch. Do you operate like this?
The data above indicates that the first data in the first column, the third data in the second column, and the first data in the third column have changed, which suggests that some operations should be performed on the dataset for each epoch, and not every data loading process for each epoch is the same. |
Hello @cainiao123s, Thank you for sharing your observations. Yes, in YOLOv8, data processing can indeed vary for each epoch. This variation is typically due to the data augmentation techniques applied during training to enhance the model's ability to generalize. These techniques might include random transformations like scaling, cropping, flipping, or color adjustments, which can lead to different loss values even for the same image across different epochs. The changes you're observing in the loss items across epochs are expected behavior when such data augmentations are active. If you need consistent data input for each epoch to test specific behaviors or modifications, you might consider disabling these augmentations temporarily. Let us know if you have further questions or need more details on how to proceed! 😊 |
I also conducted some other ablation experiments. I found the shuffle-related code and, according to the data, shuffle does change the data loading order for each epoch. However, I discovered other issues. On the same dataset, the loss values are not the same when using shuffle and not using shuffle (shuffle = mode == 'train' is equivalent to shuffle = True). Can you please provide an answer to this? I would like to investigate further. The following data were obtained from the ablation experiment: <style> </style>shuffle = mode == 'val',Original datasetepoch1 | epoch2 | epoch3 |
👋 Hello there! We wanted to give you a friendly reminder that this issue has not had any recent activity and may be closed soon, but don't worry - you can always reopen it if needed. If you still have any questions or concerns, please feel free to let us know how we can help. For additional resources and information, please see the links below:
Feel free to inform us of any other issues you discover or feature requests that come to mind in the future. Pull Requests (PRs) are also always welcomed! Thank you for your contributions to YOLO 🚀 and Vision AI ⭐ |
Search before asking
Question
Due to certain special needs, I don't need to update the model parameters, so I made a series of modifications to the training part of the code to some extent to meet my requirements, but I encountered a new problem. The loss calculated for each Epoch when the model parameters are not updated is not the same. After multiple calculations, the results are as follows each time:
Here is the training code:
from ultralytics.models.yolo.detect import DetectionTrainer
if name == 'main':
Additional
No response
The text was updated successfully, but these errors were encountered: