🤖 AI

Protecting Private Code in IDE Autocomplete using Differential Privacy

Diese Arbeit zeigt, dass das Training eines Modells zur Vervollständigung von Kotlin-Code mittels Differential Privacy die Membership Inference Attacks effektiv abmildert und gleichzeitig eine hohe Utility beibehält, die mit nicht-privaten Modellen vergleichbar ist, selbst wenn mit signifikant weniger Daten trainiert wurde.

Ursprüngliche Autoren: Evgeny Grigorenko, David Stanojević, David Ilić, Egor Bogomolov, Kostadin Cvejoski

Veröffentlicht 2026-02-02

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Evgeny Grigorenko, David Stanojević, David Ilić, Egor Bogomolov, Kostadin Cvejoski

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das Problem: Der „überfürsorgliche“ Koch

Stellen Sie sich vor, Sie engagieren einen Meisterkoch (ein KI-Modell), um Ihnen beim Kochen zu helfen. Sie möchten, dass der Koch von den Geheimrezepten Ihrer Familie lernt, damit er Ihnen die perfekten Zutaten für Ihre nächste Mahlzeit vorschlagen kann. Genau das machen moderne Codierungswerkzeuge: Sie lernen aus dem Code, den Softwareentwickler schreiben, um die nächsten Zeilen Code vorzuschlagen.

Es besteht jedoch ein Risiko. Wenn der Koch zu gut im Auswendiglernen ist, könnte er versehentlich Ihr Familiengeheimnis Wort für Wort ausspucken, wenn er gebeten wird, etwas völlig anderes zu kochen. Schlimmer noch: Ein neugieriger Nachbar (ein Hacker) könnte dem Koch gezielte Fragen stellen, um herauszufinden: „Hast du dieses spezifische Rezept wirklich aus dem Kochbuch meiner Familie gelernt, oder hast du es dir ausgedacht?“ Wenn der Koch mit „Ja, definitiv“ antworten kann, weiß der Nachbar, dass Ihre geheimen Daten zum Training verwendet wurden.

In der Welt des Codierens nennt man dies Memorization (Auswendiglernen) und Membership Inference Attacks (Mitgliedschafts-Inferenz-Angriffe). Die Arbeit zeigt, dass Standard-KI-Modelle wie diese überfürsorglichen Köche sind: Sie merken sich private Code-Schnipsel zu gut, was zu einem Sicherheitsleck führt.

Die Lösung: Der „vernebelte Spiegel“ (Differential Privacy)

Um dies zu beheben, verwendeten die Forscher eine Technik namens Differential Privacy (DP).

Stellen Sie sich das Training einer KI wie das Polieren eines Spiegels vor, um eine Reflexion klar zu sehen.

Ohne DP: Sie polieren den Spiegel, bis er jedes winzige Detail des Objekts vor ihm perfekt reflektiert. Wenn Sie ein spezifisches, einzigartiges Objekt (einen privaten Code-Schnipsel) vor ihn halten, spiegelt der Spiegel es perfekt wider. Ein Hacker kann in die Reflexion schauen und sagen: „Das war definitiv das Objekt, das ich dort platziert habe!“
Mit DP: Die Forscher fügen dem Spiegel beim Polieren ein spezielles „Nebel-Spray“ hinzu. Dieses Spray fügt der Reflexion ein wenig statisches Rauschen hinzu. Jetzt zeigt der Spiegel immer noch die allgemeine Form des Objekts (der Code funktioniert immer noch gut), aber die winzigen, einzigartigen Details werden verschwommen dargestellt.

Aufgrund dieses „Nebels“ kann selbst dann, wenn ein Hacker fragt: „Ist dies ein spezifisches Objekt im Spiegel?“, der Spiegel eine so verschwommene Antwort geben, dass der Hacker nicht sagen kann, ob es stimmt. Er ist gezwungen zu raten, wie beim Münzwurf.

Wie sie es gemacht haben

Das Team nahm ein leistungsstarkes KI-Modell (genannt Mellum), das bereits gut im Schreiben von Code war. Anstatt es komplett neu zu lehren, nutzten sie eine intelligente Abkürzung namens LoRA (Low-Rank Adaptation).

Die Analogie: Stellen Sie sich die KI wie eine riesige Bibliothek mit Milliarden von Büchern vor. Anstatt jedes einzelne Buch neu zu schreiben, um neue Geheimnisse zu lernen, fügten sie einfach ein kleines, spezielles Notizbuch auf dem Schreibtisch des Bibliothekars hinzu. Sie haben nur dieses kleine Notizbuch trainiert.
Warum das wichtig ist: Da sie nur ein kleines Notizbuch trainierten, konnten sie das „Nebel-Spray“ (das Rauschen) viel effizienter hinzufügen, ohne die Fähigkeit des Bibliothekars zu beeinträchtigen, zu helfen.

Sie trainierten dieses Modell mit 80.000 privaten Code-Schnipseln aus den eigenen internen Dateien ihres Unternehmens, während eine „Kontrollgruppe“-Modell mit 8 Millionen Schnipseln ohne den Datenschutz trainiert wurde.

Die Ergebnisse: Sicher und dennoch intelligent

Die Forscher testeten zwei Dinge: Privatsphäre (Kann ein Hacker erraten, was in den Trainingsdaten enthalten war?) und Nutzen (Schreibt die KI immer noch guten Code?).

Der Privatsphäre-Test (Die Vermutung des Hackers):
- Das nicht-private Modell war ein schrecklicher Geheimnisträger. Wenn Hacker versuchten zu erraten, ob ein spezifischer Code-Schnipsel in den Trainingsdaten enthalten war, lag die Erfolgsquote des Modells bei 90 %. Es schrie förmlich heraus: „Ja, ich kenne das!“
- Das privat geschützte Modell war ein Meister der Tarnung. Die Erfolgsquote der Hacker sank auf 60 %. Das ist kaum besser als eine Zufallswahrscheinlichkeit (50 %). Der „Nebel“ funktionierte; das Modell konnte keinen Unterschied zwischen Daten, die es gesehen hatte, und Daten, die es nicht gesehen hatte, feststellen.
Der Nutzen-Test (Die Code-Qualität):
- Normalerweise macht das Hinzufügen von „Nebel“ die Dinge schlechter. Man würde erwarten, dass das privat geschützte Modell schlechten Code schreibt.
- Überraschenderweise war das nicht der Fall. Das privat geschützte Modell schrieb fast so gut wie das nicht-private Modell, obwohl es mit 100 Mal weniger Daten trainiert wurde (80k vs. 8 Millionen).
- Der „Nebel“ wirkte tatsächlich wie ein Filter, der der KI half, die allgemeinen Regeln des Codierens zu lernen, ohne durch spezifische, seltsame Details abgelenkt zu werden.

Das Fazeresultat

Die Arbeit beweist, dass man einen KI-Codierungsassistenten bauen kann, der die Privatsphäre respektiert, ohne seine Intelligenz zu opfern. Durch die Verwendung eines mathematischen „Nebels“ (Differential Privacy) und einer intelligenten Trainingsmethode (LoRA) schufen sie ein Modell, das:

Sich weigert, Ihre privaten Code-Schnipsel preiszugeben.
Hacker stoppt, zu erraten, ob Ihr Code zum Training verwendet wurde.
Immer noch exzellenten Code schreibt, obwohl es von einem viel kleineren Datensatz gelernt hat.

Kurz gesagt: Sie haben einen Weg gefunden, der KI beizubringen, hilfreich zu sein, ohne ihr beizubringen, eine Klatschbase zu sein.

Technisches Resümee: Schutz von privatem Code in der IDE-Autovervollständigung mittels Differential Privacy

Problemstellung

Moderne integrierte Entwicklungsumgebungen (IDEs) verlassen sich zunehmend auf Large Language Models (LLMs) für Funktionen zur Codevervollständigung. Während diese Modelle die Produktivität von Entwicklern steigern, führt das Training auf benutzergeschriebenem Code erhebliche Datenschutzrisiken ein. LLMs sind bekannt für „Memorierung“, wobei sie sensible Trainingsdaten wie Secrets, Passwörter oder proprietäre Algorithmen unter der richtigen Aufforderung (Prompt) wortgetreu reproduzieren können. Jüngste Studien haben gezeigt, dass böswillige Akteure dies über Membership Inference Attacks (MIAs) ausnutzen können, um zu bestimmen, ob spezifische sensible Code-Snippets Teil des Trainingsdatensatzes des Modells waren.

Derzeitige Abwehrmechanismen sind oft unzureichend, und obwohl Differential Privacy (DP) einen mathematischen Rahmen für den Datenschutz bietet, ist seine praktische Anwendung in Deep Learning eine Herausforderung. Es erfordert typischerweise die Berechnung von pro-Beispiel-Gradienten (rechenintensiv) und das Hinzufügen von Rauschen, was den Nutzen des Modells verringert. Darüber hinaus konzentriert sich die bestehende DP-Forschung weitgehend auf allgemeine Sprachmodelle, wodurch eine kritische Lücke im spezialisierten Bereich der Codegenerierung entstanden ist, in dem vor dieser Arbeit kein Code-Completion-LLM mit formalen DP-Garantien entwickelt worden war.

Methodik

Die Autoren schlagen ein Framework vor, um ein großes, vortrainiertes Code-Completion-Modell unter Verwendung formaler Differential-Privacy-Garantien feinabzustimmen, um interne, sensible Code-Repositories zu schützen.

Basismodell: Die Studie verwendet Mellum, einen 4-Milliarden-Parameter-Transformer im LLaMA-Stil, der auf 4 Billionen Token öffentlichem Code vortrainiert wurde und eine Spezialisierung auf Kotlin aufweist. Das Modell unterstützt Fill-in-the-Middle (FIM), was es ermöglicht, Code basierend auf sowohl Präfix- als auch Suffix-Kontexten zu generieren (z. B. <PRE>prefix<SUF>suffix<MID>).
Feinabstimmungsstrategie: Anstatt alle Modellgewichte zu aktualisieren, setzen die Autoren Low-Rank Adaptation (LoRA) ein. Diese parametereffiziente Technik friert die vortrainierten Parameter ein und injiziert trainierbare Low-Rank-Matrizen. Dies reduziert die Dimensionalität der Gradienten, was das Hinzufügen von DP-Rauschen effizienter macht und hilft, den Nutzen des Modells aufrechtzuerhalten.
Privacy-Mechanismus: Der Trainingsprozess nutzt Differentially Private Stochastic Gradient Descent (DP-SGD). Der Workflow umfasst:
1. Berechnung der Pro-Beispiel-Gradienten: Berechnung der Gradienten für jedes Sample innerhalb eines Batches.
2. Gradient Clipping: Begrenzung des Einflusses eines einzelnen Datenpunkts durch Clipping der L2-Norm der Gradienten auf einen Schwellenwert ( $C=0,5$ ).
3. Rauschhinzufung: Hinzufügen von Gaußschem Rauschen (mit einem Rauschmultiplikator $\sigma=0,2746$ ) zu den gemittelten, geclippten Gradienten vor der Aktualisierung des Modells.
4. Privacy Accounting: Verfolgung der kumulativen Privatsphäre-Kosten, um eine endgültige $(\epsilon, \delta)$ -Garantie sicherzustellen.
Experimentelles Setup:
- Baseline: Ein nicht-privates Modell (Mellum Int. Base), das auf 8 Millionen internen Kotlin-Instanzen feinabgestimmt wurde.
- Privates Modell: Ein differenziell privates Modell (Mellum Int. DP), das aufgrund des frühen Abbruchs basierend auf dem Privacy-Budget nur auf 80.000 internen Instanzen feinabgestimmt wurde.
- Hyperparameter: Die optimale Konfiguration wurde mit einem LoRA-Rang von $r=8$ und einem Privacy-Budget von $\epsilon \approx 30$ ermittelt.

Zentrale Beiträge

Erstes DP-geschütztes Code-LLM: Nach Kenntnis der Autoren ist dies das erste Code-Completion-LLM, das speziell für die sichere IDE-Integration unter Verwendung formaler DP-Garantien entwickelt wurde.
Praktischer Privacy-Utility-Trade-off: Die Studie zeigt, dass DP auf groß angelegte Code-Modelle angewendet werden kann, mit minimalen Auswirkungen auf die Performance, selbst wenn es mit wesentlich weniger Daten (Faktor 100 weniger) trainiert wurde als die nicht-private Baseline.
Robuste Abwehr gegen MIAs: Die Arbeit liefert empirische Belege dafür, dass DP die Membership Inference Attacks im Kontext der Codegenerierung effektiv neutralisiert.

Ergebnisse

Die Evaluierung konzentrierte sich auf zwei Dimensionen: Utility (Qualität der Codegenerierung) und Privacy (Widerstandsfähigkeit gegen MIAs).

Privacy-Performance (MIA-Resistenz):
- Die nicht-private Baseline war hochgradig anfällig für MIAs und erreichte eine Area Under the Curve (AUC) von 0,901, was bedeutet, dass ein Angreifer zuverlässig zwischen Trainingsdaten und ungesehenen Daten unterscheiden konnte.
- Das DP-trainierte Modell reduzierte die Erfolgsrate des Angriffs auf eine AUC von 0,606, was nahe an einer Zufallswahrscheinlichkeit (0,5) liegt. Dies bestätigt, dass das Modell den Einfluss einzelner Trainingsbeispiele erfolgreich verschleiert.
Utility-Performance:
- Trotz der Privacy-Beschränkungen und der Verwendung von 100-mal weniger Trainingsdaten behielt das DP-Modell eine hohe Utility bei.
- Auf einem internen Kotlin-Benchmark erreichte das DP-Modell Werte, die mit der nicht-privaten Baseline vergleichbar sind:
  - ChrF++: 74,78 (DP) vs. 75,26 (Nicht-DP).
  - LLM-as-judge: 0,730 (DP) vs. 0,753 (Nicht-DP).
  - LM Score: 0,613 (DP) vs. 0,643 (Nicht-DP).
- Das DP-Modell übertraf das ursprüngliche vortrainierte Mellum SFT-Modell in allen Metriken, was darauf hindeutet, dass DP-SGD als starker Regularisierer wirken kann, der die Generalisierung fördert.
Trainingsdynamik: Wie erwartet wies das DP-Modell aufgrund der Rauschinjektion einen leicht höheren Validierungsverlust auf, wobei das Privacy-Budget ( $\epsilon \approx 30$ ) über die Trainingsepoche hinweg schrittweise aufgebraucht wurde.

Bedeutung und Behauptungen

Das Paper behauptet, dass Differential Privacy eine praktikable und effektive Lösung für den Aufbau vertrauenswürdiger, KI-gestützter IDE-Funktionen ist. Die Autoren betonen, dass obwohl ihr endgültiges Privacy-Budget ( $\epsilon \approx 30$ ) höher ist als die strengen Schwellenwerte, die oft in theoretischen Arbeiten angestrebt werden ( $\epsilon \le 10$ ), es einen starken Schutz in einem realen IDE-Szenario bietet. Die Studie kommt zu dem Schluss, dass selbst mit „lockeren“ Privacy-Budgets DP die Membership Inference Attacks erfolgreich behindert und den Vorteil eines Angreifers auf das Niveau eines Zufallstreffers reduziert, ohne die Fähigkeit des Modells zur Unterstützung von Entwicklern signifikant zu beeinträchtigen.

Die Arbeit hebt hervor, dass der Trade-off zwischen Privacy und Utility in diesem Bereich äußerst günstig ist, was darauf hindeutet, dass sichere, datenschutzbewusste Entwicklertools entwickelt werden können, ohne die Qualität der Code-Vorschläge zu opfern. Zukünftige Arbeiten sollen untersuchen, wie strengere Privacy-Budgets und das Training auf größeren Datensätzen die Balance weiter verfeinern können.