Databricks-Praktikant lehrt KI, Code-Schnellkorrektur zu verbessern
So wie Menschen Fähigkeiten durch iteratives Üben und Lernen aus Fehlern verfeinern, werden Künstliche Intelligenz-Modelle nun trainiert, ihr Handwerk in komplexen Bereichen wie der Code-Reparatur zu perfektionieren. Diese grundlegende Feedback-Schleife stand im Mittelpunkt eines kürzlichen Sommerpraktikumsprojekts bei Databricks, das darauf abzielte, die Fähigkeiten ihres Code Assistant zu verbessern. Die Initiative konzentrierte sich darauf, einem spezialisierten „Belohnungsmodell“ beizubringen, optimale Code-Korrekturen zu erkennen und zu priorisieren – ein entscheidender Schritt beim Aufbau eines hochentwickelten Entwickler-Tools.
Die Kerninnovation ist Databricks’ „Quick Fix“-Funktion, die nahtlos in ihre Notebooks und SQL-Editoren integriert ist. Quick Fix wurde für schnelle, hochzuverlässige Lösungen entwickelt und zielt auf häufige Probleme wie Syntaxfehler, falsch geschriebene Spaltennamen und einfache Laufzeitprobleme ab. Wenn ein Entwickler einen Fehler feststellt, wird Quick Fix aktiv, analysiert den problematischen Code und die dazugehörige Fehlermeldung. Anschließend nutzt es ein großes Sprachmodell (LLM), um schnell eine gezielte Lösung zu generieren, typischerweise innerhalb von ein bis drei Sekunden.
Obwohl Quick Fix bereits wertvolle Unterstützung bot, lag die Herausforderung in der Verbesserung seiner Präzision. Selbst nachdem eine Korrektur generiert und grundlegende Syntaxprüfungen bestanden hatte, wie konnte das System garantieren, dass es die relevanteste und genaueste Lösung für den Benutzer war? Die Antwort ergab sich aus einer Technik namens „Best-of-k-Sampling“. Dieser Ansatz beinhaltet die Generierung mehrerer potenzieller Korrekturvorschläge und anschließend die Verwendung eines hochentwickelten Belohnungsmodells, um die einzige beste Option zu bewerten und auszuwählen.
Das Projekt umfasste sowohl Backend-Engineering als auch experimentelle Forschung. Die Anfangsphase konzentrierte sich auf die Erweiterung des Quick Fix-Systems, um eine vielfältige Palette von Vorschlägen parallel zu generieren. Dies beinhaltete Experimente mit verschiedenen Prompts und Kontextinformationen, einschließlich Techniken wie „Chain-of-Thought“-Reasoning, prädiktivem Output-Reasoning und Variationen in System-Prompts, zusammen mit selektivem Datenbankkontext. Während diese Methoden die Qualität und Vielfalt der Vorschläge verbesserten, führten sie auch zu einer gewissen Verarbeitungsverzögerung, was einen kritischen Kompromiss zwischen Ausgabequalität und Betriebsgeschwindigkeit verdeutlichte.
Nachdem mehrere Vorschläge generiert wurden, bestand der nächste Schritt darin, den vielversprechendsten zu identifizieren, der dem Benutzer präsentiert werden sollte. Ein früher Versuch umfasste ein einfaches Mehrheitswahlsystem, das, obwohl es in isolierten Tests gut abschnitt, in realen Benutzer-A/B-Tests keine signifikanten Verbesserungen hervorbrachte und daher nicht eingeführt wurde. Die effektivere Lösung bestand in der Entwicklung und dem Training spezieller Belohnungsmodelle. Diese Modelle wurden entwickelt, um vorherzusagen, welche vorgeschlagenen Korrekturen Benutzer letztendlich akzeptieren und erfolgreich ausführen würden. Interessanterweise nutzte der Entwicklungsprozess sowohl traditionelle maschinelle Lernmethoden wie logistische Regression und Gradient-Boosted Decision Trees (insbesondere unter Verwendung des LightGBM-Pakets) als auch modernere feinabgestimmte große Sprachmodelle.
Ein bemerkenswertes Ergebnis ergab sich aus der Evaluation: Für die spezifische Aufgabe der Vorhersage der Benutzerakzeptanz und des Ausführungserfolgs schnitten die klassischen maschinellen Lernmodelle in Offline-Bewertungen vergleichbar mit den ressourcenintensiveren feinabgestimmten LLMs ab. Insbesondere das Entscheidungsbaummodell erwies sich als hochwirksam. Sein Erfolg wurde der Tatsache zugeschrieben, dass bei den Fehlertypen, die Quick Fix adressiert, Code-Bearbeitungen, die korrekt erscheinen, oft auch korrekt sind. Zu den Schlüsselmerkmalen, die seine Entscheidungen beeinflussten, gehörten die Ähnlichkeit zwischen der ursprünglichen Codezeile und der generierten Korrektur sowie der spezifische Fehlertyp, der auftrat.
Angesichts seiner vergleichbaren Leistung und, was entscheidend ist, seiner signifikant schnelleren Inferenzzeit, wurde das LightGBM-Entscheidungsbaummodell letztendlich für den Einsatz in der Produktion ausgewählt. Geschwindigkeit ist für Quick Fix von größter Bedeutung; Vorschläge müssen fast sofort erscheinen, bevor ein Entwickler manuell eingreifen kann, da jede Verzögerung die Anzahl der schnell lösbaren Fehler reduziert. Die kompakte Größe des LightGBM-Modells machte es zudem bemerkenswert ressourceneffizient und einfacher in die bestehende Infrastruktur zu integrieren. Durch eine Kombination aus Modell- und Infrastruktur-Optimierungen wurde die durchschnittliche Inferenzzeit drastisch um fast das Hundertfache reduziert. Diese Implementierung des Best-of-k-Ansatzes, gepaart mit dem Belohnungsmodell, führte zu einer messbaren Erhöhung der internen Akzeptanzrate von Databricks, was direkt zu höherer Qualität und einem nahtloseren Erlebnis für die Benutzer führte, während die Systemlatenz gut innerhalb akzeptabler Grenzen blieb.