GitHub hat am 23. September in Visual Studio Code (VS Code) drei Inline-Funktionen von Copilot zu einem einzigen Modell vereint. Laut dem Blogpost des Teams sank die Ablehnungsrate der Vorschläge im Online-Test um 10,1 Prozent. Ein Teil dieses Erfolgs geht jedoch auf die Korrektur eines Editor-Fehlers zurück, der die alte Vergleichsbasis um geschätzt 7 bis 8 Prozent aufgebläht hatte.
Drei Vorschlagssysteme arbeiten in VS Code jetzt als ein Modell
Seit dem 23. September übernimmt bei bezahlten Copilot-Konten ein vereinigtes Modell alle Inline-Vorschläge in VS Code, so GitHub. Bisher gab es dafür drei getrennte Systeme: Ghost Text, Next Edit Suggestions (NES) und Long-Distance-Edits. Ghost Text sind die grauen Textvorschläge direkt am Cursor, die beim Tippen erscheinen. NES schlägt Änderungen in der Nähe vor. Long-Distance-Edits betreffen Stellen, die weiter entfernt im Code liegen. Jedes System hatte sein eigenes Modell und eigene Regeln dafür, wann etwas angezeigt wird.
Die Ausgangslage war konfliktträchtig. Ghost Text arbeitet reaktiv und leise. NES tritt proaktiver auf, zeigt eine kleine Vorschau der Änderung und lässt sich mit der Tabulatortaste annehmen. Laufen beide getrennt, wollen sie mitunter an derselben Stelle etwas vorschlagen, und der Editor muss entscheiden, welches System gewinnt. Ein gemeinsames Modell soll diesen Konflikt auflösen, weil es von Beginn an für alle drei Vorschlagsarten zuständig ist.
Wie das Team den Zusammenschluss technisch gelöst hat und was dabei schiefging, beschreibt der zweite Teil der Blogreihe. Für Technikfans ist der Teil mit dem Schiefgehen der deutlich spannendere.
Was bedeutet die sinkende Ablehnungsrate wirklich?
Die Ablehnungsrate sank im Online-Test um 10,1 Prozent, doch diese Zahl allein beweist noch keinen Erfolg des neuen Modells. GitHub hat das vereinte Modell in einem Online-Flight geprüft, also mit echten Nutzenden statt nur an historischen Daten. Als Vergleich diente die alte Baseline aus einem 2-in-1-Modell plus Completions. Mit Ablehnung ist gemeint, dass ein Vorschlag weggeklickt, ignoriert oder aktiv verworfen wird, statt angenommen zu werden. Weniger Ablehnungen gelten als gutes Zeichen, weil die Vorschläge offenbar häufiger treffen, was Entwicklerinnen und Entwickler tatsächlich wollen. Zusätzlich meldet GitHub keine signifikanten Regressionen bei den wichtigsten Kennzahlen. Das liest sich wie ein makelloser Rollout.
Dann folgt ein Detail, das stutzig macht. Der Anteil von Ghost Text am Cursor sank im selben Zeitraum um 13 Prozent. Wenn weniger Ghost Text erscheint, können auch weniger Vorschläge abgelehnt werden. Weniger Angebot ergibt dann weniger Ablehnung, und das wäre bloße Mengenreduktion statt eines Modellerfolgs. An dieser Stelle hat GitHub selbst nachgebohrt und dabei den eigentlichen Knackpunkt gefunden.
Ein Anzeigefehler im Editor verzerrte die alte Vergleichsbasis
Ein alter Pfad im Client von VS Code zeigte abgelehnten Ghost Text nach einer Cursorbewegung erneut als NES-Vorschlag an. Der Ablauf ist schnell erzählt. Ghost Text erscheint, und man tippt einfach weiter, ignoriert ihn also bewusst oder unbewusst. Der Cursor bewegt sich, und derselbe Vorschlag taucht als vermeintlich neue Next Edit Suggestion wieder auf. Wird er abermals abgelehnt, tickt der Zähler ein zweites Mal hoch, obwohl es um denselben Vorschlag geht.
Solche Fehler fallen in Metriken kaum auf, weil sie echte Nutzerinteraktionen erzeugen. Niemand klickt falsch, der Editor zeigt lediglich dasselbe doppelt und dreht sich dabei sozusagen im Kreis. GitHub schätzt, dass dieser Fehler für 7 bis 8 Prozent Inflation der Ablehnungsrate verantwortlich war. Diese Prozentpunkte steckten in der alten Baseline, hatten aber mit der Zufriedenheit der Nutzenden nichts zu tun.
Um den Effekt zu beziffern, fuhr das Team eine A/B-Ablation, gesteuert über das Flag nesMimicGhostTextBehavior. Eine Ablation schaltet gezielt einen einzelnen Faktor ein oder aus, um seinen Einfluss zu messen. Einmal verhielt sich NES wie der alte, fehlerhafte Client und zeigte ignorierten Ghost Text erneut an. Einmal lief sie mit der Korrektur. Die Ergebnisse:
- Mit simuliertem Fehler stieg die Ablehnungsrate um 15,9 Prozent.
- Mit Korrektur sank sie um 10,1 Prozent, also exakt auf den Wert aus dem Online-Test.
Zwischen den beiden Zuständen liegen 26 Prozentpunkte. Verursacht hat sie weder ein neues Modell noch bessere Anweisungen an das Modell oder mehr Trainingsdaten, sondern ein Pfad im Editor-Code, der zeigte, was nur einmal hätte erscheinen sollen. Den Absatz zur Ablation liest man gern dreimal, weil die Zahl so unglaubwürdig groß wirkt.
Ohne diese Ablation wäre unklar geblieben, wie viel der Verbesserung echt ist und wie viel Fehlerkorrektur. Eine Ablehnungsrate ist nur so verlässlich wie die Zähllogik dahinter. Wenn der Client denselben Vorschlag zweimal als neu präsentiert, registriert die Metrik zwei Ablehnungen, obwohl die Nutzerin nur einmal entschieden hat. Die Ursache liegt im Rendering und in der Zustandsverwaltung des Editors, das Modell trifft keine Schuld. Alle genannten Angaben stammen von GitHub selbst und sind nicht unabhängig überprüft.
Offen bleibt, wie viel der Verbesserung dem neuen Modell zusteht
Der Blogpost beantwortet nicht eindeutig, welcher Anteil der 10,1 Prozent auf das Modell entfällt und welcher auf den behobenen Fehler. Die Ablation vergleicht zwei Zustände im selben, neuen System. Ob das 3-in-1-Modell auch ohne den Fehler besser ist als die alte getrennte Architektur, ließe sich erst mit einer dritten Vergleichsgruppe klären. Nötig wären das alte System mit Fehler, das alte System mit Korrektur und das neue System ohne Fehler. Diese Aufteilung liefert der Post nicht ausdrücklich. Die tatsächliche Verbesserung durch das neue Modell fällt daher vermutlich kleiner aus, als die Zahl von 10,1 Prozent nahelegt.
Der sinkende Ghost-Text-Anteil ließe sich auch positiv deuten. Ein Modell, das alle drei Vorschlagsarten gemeinsam sieht, kann Vorschläge in Modi verschieben, die besser zur Situation passen. Es zeigt dann etwa gezielter NES, wenn eine echte Bearbeitung sinnvoll ist, statt bei jedem Tastenanschlag blind Ghost Text einzublenden. In der Theorie ist das plausibel. Gerade weil der Effekt plausibel wirkt, hätte man ihn ohne die Ablation leicht mit dem Fehlereffekt verwechselt: zwei Ursachen, ein Symptom.
Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose photo of a mechanical keyboard and blank sticky notes for A/B notes, warm desk lamp, photorealistic, no logos, no brand names, no readable text, 16:9Weitere Lücken sind überschaubar, aber für Neugierige interessant. Unklar ist, wie lange der Fehler im Live-Betrieb lief, bevor er entdeckt wurde. Ebenso fehlt eine Aufschlüsselung nach Programmiersprache oder Tippverhalten, denn Vieltippende und Wenigtippende könnten unterschiedlich stark betroffen gewesen sein. Auch Zahlen speziell zu Long-Distance-Edits und zu reinen NES-Interaktionen ohne Ghost-Text-Vermischung wären aufschlussreich. Offen bleibt zudem, ob sich die 10,1 Prozent über verschiedene VS-Code-Versionen und Rollout-Phasen stabil zeigen.
Vielleicht beantwortet das ein dritter Teil der Reihe, falls GitHub das Format fortführt. Nach zwei Teilen scheint das Team Freude daran zu haben, öffentlich vorzurechnen, wie die Wurst gemacht wird.
Was Nutzende und andere Teams aus dem Fall mitnehmen
Die Größenordnung erklärt, warum sich die Nachprüfung lohnte. Im ersten Teil der Reihe vom 16. September berichtet GitHub von mehr als 61 Milliarden erfolgreichen Modellanfragen in 90 Tagen für die Inline-Systeme in VS Code. Bei so einem Volumen ist jeder Prozentpunkt der Ablehnungsrate keine akademische Fußnote, denn potenziell verschieben sich Hunderte Millionen einzelner Interaktionen. Sieben bis acht Prozent Scheinablehnungen ließen sich bei dieser Reichweite kaum dauerhaft in der Berichterstattung halten. Ein Team, das dem eigenen Erfolg misstraut und nachrechnet, warum die Zahl so gut aussieht, verdient Anerkennung.
Wer VS Code mit einem bezahlten Copilot-Abo und aktueller Version nutzt, arbeitet bereits mit dem vereinten Modell. Die Oberfläche bleibt nahezu gleich: Ghost Text sieht aus wie Ghost Text, NES-Vorschläge sehen aus wie NES-Vorschläge. Der Unterschied liegt in der Entscheidungslogik, die festlegt, wann welches System zum Zug kommt. Spürbar sein dürfte die Korrektur des Fehlers. Man sollte denselben, bereits abgelehnten Vorschlag seltener ein zweites Mal als scheinbar neue Next Edit Suggestion sehen. Wer den Eindruck hatte, Copilot wiederhole sich nach dem Wegklicken eines Vorschlags, hat vermutlich genau diesen Fehler erlebt, der mit dem aktuellen Rollout behoben sein sollte.
Für andere Teams liefert der Fall ein übertragbares Verfahren. Bevor eine Metrikverbesserung als Modellerfolg verkauft wird, braucht es ein Flag, das den alten, möglicherweise fehlerhaften Zustand simuliert, und eine Ablation gegen den neuen Zustand. Nur so lässt sich die Aussage, das Modell sei besser, von der Tatsache trennen, dass der Editor vorher falsch gezählt hat. Besonders gefährdet sind Produkte, die zuvor getrennte Systeme zusammenlegen. Alte Client-Zustände, Zähllogiken und Zwischenspeicher können im vereinten System Artefakte erzeugen, die wie echte Nutzersignale aussehen. Die Prüfung der Zähllogik gilt als unscheinbarster Teil eines Feature-Starts und wird deshalb gern übersprungen. Persönlich überzeugt die offengelegte Ablation mehr als die eigentliche Funktionsankündigung.
Weitere Beiträge aus dem Magazin zu verwandten Themen:
Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.
Mitreden & diskutieren
Ihre Meinung zählt — teilen Sie Gedanken, Fragen oder Erfahrungen zu diesem Artikel.