Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

DP: fix Laplace calibration (F4) and label post-training mechanisms experimental (F5)

Aperta
  • Qualcosa non va?
#279 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Abidoyesimze ci sta già lavorando.

Dal 27/10/2026.

  • #288 di @Abidoyesimze — aperta
  • #292 di @Abidoyesimze — aperta
  • #293 di @Abidoyesimze — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
64/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
machine-learning, security

Direzione di ricerca

For Track A, read cache_model_0/services/client.py, Documentation/technical/services/clients.md, and tests/test_cache_client_dp.py. Add a warning when either post-training mechanism is selected and cover it with a test; done means the warning identifies the mechanisms as experimental with no formal privacy guarantee and the docs match. Track B needs differential privacy expertise, while Track C requires real trained weights and accuracy evaluation.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

good first issue help wanted

Summary

Three open items remain from our DP mechanism review (PR #89) and its follow-up fixes (#90, #109, #119). None of them has a GitHub issue yet; two are tracked only in Developer/BACK_LOG.md (BL-23, BL-24).

DP is off by default on DevNet, and our public docs avoid claiming formal differential privacy. The goal here is that, when a model owner turns DP on, every mechanism we offer either carries an honest guarantee or is clearly labelled as not having one.

The three items

F4 / BL-24: Laplace noise is sized against an L2 clip.
post_training_laplace multiplies laplace_scale by the L2 clipping_norm (cache_model_0/services/client.py, require_laplace_scale(params) * clipping_norm), but the Laplace mechanism is calibrated against L1 sensitivity. For model weights, the gap can be up to √d (d = number of parameters), so this mechanism cannot carry any ε today. The docs already note it as an open question (Documentation/technical/services/clients.md).

F5: the post-training mechanisms bound no sensitivity at all.
Both post_training_gaussian and post_training_laplace clip absolute trained weights rather than per-client updates, so they bound nothing an attacker cares about. The review recommends labelling both as experimental baselines with no formal guarantee, and treating update_gaussian as the path forward. Today only the per_layer clip scope is labelled experimental in the docs.

BL-23: the default clip may be destructive on real models.
Since #109, clip_scope: global bounds the whole model's combined L2 norm, but cache_model_0/manifest.json still uses clipping_norm: 1.0, chosen under the old per-layer scope. Tests use synthetic tensors only, so nobody has checked whether this default badly degrades the reference model's real trained weights.

Ways to help

Track A: honest labelling (newcomer-friendly, no DP expertise needed)
  • Emit a clear warning when post_training_gaussian or post_training_laplace is selected (log message or manifest-validation warning): experimental, no formal privacy guarantee.
  • Update Documentation/technical/services/clients.md to match.
  • Add a test in tests/test_cache_client_dp.py covering the warning.
Track B: specialist recommendation for F4 (DP expertise wanted)
  1. Is the mismatch as described, and how large is it in practice for typical model sizes?
  2. Which resolution would you recommend?
    • an update_laplace mechanism: L1-clip the per-client update and add calibrated Laplace noise, mirroring update_gaussian;
    • keep post_training_laplace only as a labelled experimental baseline (Track A);
    • remove the Laplace option entirely.
  3. Given F5, is there any reason to keep weight-level mechanisms at all?

A written recommendation in a comment is a valuable contribution on its own; a PR is even better.

Track C: verify the default clip (ML / Python, moderate)

Run apply_dp_mechanism / clip_state_dict against cache_model_0's actual trained weights under the current default. Report how much the clip changes them and the effect on accuracy, then propose a better clipping_norm if 1.0 is destructive. Ideally add a test using real weights.

Longer-term context

Privacy accounting and DP-SGD (review finding F6) are the bigger roadmap items, described in Developer/issues/DifferentialPrivacy.md. They're out of scope here, but proposals are welcome as separate issues.

cc @tudorcebere : we'd especially value your view on Track B, given your background in privacy-preserving ML. No obligation, of course.

Lingua principale
Python
Stelle
4
Fork
7
Merge medio
3g 58m
PR unite (30g)
39

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InfiniteZeroFoundation/DevNet

Tutte le issue di InfiniteZeroFoundation/DevNet

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.