You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
⚠️ Add warning guidelines and update codebase to follow best practices (huggingface#2350)
* Add guidelines for working with warnings in the codebase
* Remove unnecessary warnings and improve code initialization
* Fix warnings and improve accuracy calculation
* Add rich library dependency for text formatting
* Update LoRA weight loading warning message
* Fix logging and import issues in AlignPropConfig
* Fix warnings and improve code readability
* Remove unused import statements
* Refactor CPOTrainer class in cpo_trainer.py
* Remove unnecessary warnings and raise ValueError for missing model
* Fix warnings and improve code consistency
* Update CONTRIBUTING.md to clarify the purpose of warnings
* Fix string formatting in DataCollatorForCompletionOnlyLM class
* Update SimPO loss parameters in CPOTrainer
* Fix warnings and remove unnecessary code in ConstantLengthDataset class
* Clarify warning guidelines
* Rewrite the entire section
* Fix capitalization in CONTRIBUTING.md
* Fix formatting in CONTRIBUTING.md
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+53Lines changed: 53 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -283,3 +283,56 @@ The deprecation and removal schedule is based on each feature's usage and impact
283
283
- **Widely-Used Components**: For a feature with high usage, we aim for a more gradual transition period of approximately **5 months**, generally scheduling deprecation around **5 minor releases** after the initial warning.
284
284
285
285
These examples represent the two ends of a continuum. The specific timeline for each feature will be determined individually, balancing innovation with user stability needs.
286
+
287
+
### Working with warnings
288
+
289
+
Warnings play a critical role in guiding users toward resolving potential issues, but they should be used thoughtfully to avoid unnecessary noise. Unlike logging, which provides informational context or operational details, warnings signal conditions that require attention and action. Overusing warnings can dilute their importance, leading users to ignore them entirely.
290
+
291
+
#### Definitions
292
+
293
+
- **Correct**: An operation is correct if it is valid, follows the intended approach, and aligns with the current best practices or guidelines within the codebase. This is the recommended or intended way to perform the operation.
294
+
- **Supported**: An operation is supported if it is technically valid and works within the current codebase, but it may not be the most efficient, optimal, or recommended way to perform the task. This includes deprecated features or legacy approaches that still work but may be phased out in the future.
295
+
296
+
#### Choosing the right message
297
+
298
+
- **Correct → No warning**:
299
+
If the operation is fully valid and expected, no message should be issued. The system is working as intended, so no warning is necessary.
300
+
301
+
- **Correct but deserves attention → No warning, possibly a log message**:
302
+
When an operation is correct but uncommon or requires special attention, providing an informational message can be helpful. This keeps users informed without implying any issue. If available, use the logger to output this message. Example:
303
+
304
+
```python
305
+
logger.info("This is an informational message about a rare but correct operation.")
306
+
```
307
+
308
+
- **Correct but very likely a mistake → Warning with option to disable**:
309
+
In rare cases, you may want to issue a warning fora correct operation that’s very likely a mistake. In such cases, you must provide an option to suppress the warning. This can be done with a flagin the function. Example:
310
+
311
+
```python
312
+
def my_function(foo, bar, _warn=True):
313
+
if foo == bar:
314
+
if _warn:
315
+
warnings.warn("foo and bar are the same, this is likely a mistake. Ignore this warning by setting `_warn=False`.")
316
+
# Do something
317
+
```
318
+
319
+
- **Supported but not correct → Warning**:
320
+
If the operation is technically supported but is deprecated, suboptimal, or could cause future issues (e.g., conflicting arguments), a warning should be raised. This message should be actionable, meaning it must explain how to resolve the issue. Example:
321
+
322
+
```python
323
+
def my_function(foo, bar):
324
+
if foo and bar:
325
+
warnings.warn("Both `foo` and `bar` were provided, but only one is allowed. Ignoring `foo`. Please pass only one of these arguments.")
326
+
# Do something
327
+
```
328
+
329
+
- **Not supported → Exception**:
330
+
If the operation is invalid or unsupported, raise an exception. This indicates that the operation cannot be performed and requires immediate attention. Example:
331
+
332
+
```python
333
+
def my_function(foo, bar):
334
+
if foo and bar:
335
+
raise ValueError("Both `foo` and `bar` were provided, but only one is allowed. Please pass only one of these arguments.")
336
+
```
337
+
338
+
By following this classification, you ensure that warnings, information, and exceptions are used appropriately, providing clear guidance to the user without cluttering the system with unnecessary messages.
Copy file name to clipboardExpand all lines: docs/source/cpo_trainer.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,7 +75,7 @@ While training and evaluating we record the following reward metrics:
75
75
76
76
### Simple Preference Optimization (SimPO)
77
77
78
-
The [SimPO](https://huggingface.co/papers/2405.14734) method is also implemented in the [`CPOTrainer`]. SimPO is an alternative loss that adds a reward margin, allows for length normalization, and does not use BC regularization. To use this loss, we can use SimPO easily by turning on `loss_type="simpo"` and `cpo_alpha=0` in the [`CPOConfig`].
78
+
The [SimPO](https://huggingface.co/papers/2405.14734) method is also implemented in the [`CPOTrainer`]. SimPO is an alternative loss that adds a reward margin, allows for length normalization, and does not use BC regularization. To use this loss, we can use SimPO easily by turning on `loss_type="simpo"` and `cpo_alpha=0.0` in the [`CPOConfig`].
"compute_loss is only implemented for DPODataCollatorWithPadding, and you passed a datacollator that is different than "
1284
-
"DPODataCollatorWithPadding - you might see unexpected behavior. Alternatively, you can implement your own prediction_step method if you are using a custom data collator"
"prediction_step is only implemented for DPODataCollatorWithPadding, and you passed a datacollator that is different than "
1365
-
"DPODataCollatorWithPadding - you might see unexpected behavior. Alternatively, you can implement your own prediction_step method if you are using a custom data collator"
"compute_loss is only implemented for DPODataCollatorWithPadding, and you passed a datacollator that is different than "
851
-
"DPODataCollatorWithPadding - you might see unexpected behavior. Alternatively, you can implement your own prediction_step method if you are using a custom data collator"
"prediction_step is only implemented for DPODataCollatorWithPadding, and you passed a datacollator that is different than "
897
-
"DPODataCollatorWithPadding - you might see unexpected behavior. Alternatively, you can implement your own prediction_step method if you are using a custom data collator"
0 commit comments