SWE-agent, ein automatischer Entwicklungsagent mit 12 % Erfolgsquote bei der Lösung von GitHub-Issues

 (github.com/princeton-nlp)
10 Punkte von GN⁺ 2024-04-04 | 3 Kommentare | Auf WhatsApp teilen
  • SWE-agent behebt Bugs und Issues in echten GitHub-Repositories, indem Sprachmodelle (LMs) wie GPT-4 in Software-Engineering-Agenten umgewandelt werden
  • Über das gesamte SWE-bench-Testset hinweg wurden 12,29 % der Issues gelöst und damit die beste Leistung im vollständigen Testset erreicht

Agent-Computer-Schnittstelle (ACI)

  • Diese Ergebnisse wurden erzielt, indem LM-zentrierte Befehls- und Feedbackformate entworfen wurden, damit der Agent Repositories leichter durchsuchen sowie Codedateien ansehen, bearbeiten und ausführen kann.
  • Dies wird als Agent-Computer-Schnittstelle (ACI) bezeichnet, und es wurde das SWE-agent-Repository aufgebaut, damit sich ACI-Designs für Coding-Agenten auf Repository-Ebene leicht iterieren lassen.
  • Es wird gezeigt, dass ein gutes ACI-Design bei der Nutzung von Agenten zu deutlich besseren Ergebnissen führt.

Einrichtung

  • Docker installieren und Docker lokal starten.
  • Miniconda installieren und mit conda env create -f environment.yml die Umgebung swe-agent erstellen.
  • Mit conda activate swe-agent aktivieren.
  • ./setup.sh ausführen, um das Docker-Image für swe-agent zu erstellen.
  • Im Wurzelverzeichnis dieses Repositories eine Datei keys.cfg erstellen und die erforderlichen API-Keys sowie das GitHub-Token eintragen.

Verwendung

  • Die SWE-agent-Pipeline besteht aus zwei Schritten. Der erste ist die Inferenzphase, in der ein GitHub-Issue als Eingabe verwendet wird und ein Pull Request zurückgegeben wird, der versucht, dieses zu lösen.
  • Der zweite Schritt ist nur für Issues im SWE-bench-Benchmark möglich und ist die Evaluierungsphase, in der geprüft wird, ob der erzeugte Pull Request das Issue tatsächlich gelöst hat.

Evaluierung

  • Dieser Schritt ist nur für Issues aus dem SWE-bench-Set möglich.
  • Um den erzeugten Pull Request zu bewerten, in das Verzeichnis evaluation/ wechseln und ./run_eval.sh ausführen.

Meinung von GN⁺

  • SWE-agent erweitert die Möglichkeiten der Automatisierung im Softwareentwicklungsprozess, indem es einen innovativen Ansatz präsentiert, Sprachmodelle zur Lösung echter GitHub-Issues einzusetzen.
  • Diese Technologie hat das Potenzial, Entwickler von wiederholten Bugfix-Aufgaben zu entlasten, sodass sie sich auf kreativere und komplexere Problemlösungen konzentrieren können.
  • Durch die Hervorhebung der Bedeutung des ACI-Designs wird auch die Wichtigkeit von Schnittstellendesigns betont, die die Interaktion zwischen Maschine und Mensch optimieren.

Verwandte Beiträge

3 Kommentare

 
botplaysdice 2024-04-05

Wenn solche Agenten arbeiten und dabei sogar dem Entwickler solche Fragen stellen, wäre das wirklich ziemlich gut.

"Ich habe die im Bugreport beschriebenen Reproduktionsschritte in Testcode umgesetzt, der das Problem reproduziert. Kannst du dir diesen Code ansehen und prüfen, ob ich es richtig verstanden habe?"

"Statt dieses Designs könnte man durch ein Refactoring in diese und diese Richtung im gesamten Projekt wohl 20.312 Codezeilen einsparen — do you approve?"
 
fastkoder 2024-04-04

Ein attraktives Open-Source-Projekt.
 
GN⁺ 2024-04-04
Hacker-News-Kommentare

  • Kommentar zu Bug-Reports:

    • Die Demo zeigt einen klaren Bug-Report zu Matrixoperationen.
    • Echte Bug-Reports sind meist vage, nach dem Muster „Ich habe auf X geklickt und dann ist Y passiert“.
    • Die Schwierigkeit beim Beheben eines Bugs liegt darin, die Ursache zu finden.
    • Es ist bekannt, dass LLMs einfache Fehler beheben können, aber es wird infrage gestellt, was das eigentlich beweist.
    • Es wird gefragt, ob sich jemand das Paper genauer angesehen hat und worin die Unterschiede zu diesen Problemen bestehen.

  • Kommentar zum Projekt:

    • Es wird als sehr cooles Projekt bewertet.
    • Ähnliche Experimente wurden schon zuvor ausprobiert, endeten aber oft in chaotischen und teuren Fehlschlägen.
    • Auf swe-bench wurde eine Erfolgsquote von 12 % erreicht, aber was ist mit den restlichen 88 %?
    • Es wird gefragt, ob swe-bench von dieser Gruppe erstellt wurde und ob jemals ein Wert für die „Obergrenze erfahrener Menschen“ gemessen wurde.
    • Es wird die Erfahrung geteilt, dass zufällig ausgewählte swe-bench-Aufgaben selbst für erfahrene Menschen schwer zu „lösen“ waren.

  • Kommentar zur verwendeten Methodik:

    • Es sieht so aus, als sei die LangChain-Methodik verwendet worden.
    • Es werden einige Prompts als Beispiele genannt und ein GitHub-Link bereitgestellt.

  • Kommentar zu AI und Bug-Trackern:

    • Wenn von AI erzeugte Pull Requests populär werden, wird das Ende öffentlicher Bug-Tracker erwartet.
    • Die Bugs verschwinden nicht, aber der Projektnutzen im Verhältnis zu den Kosten der Pull-Request-Prüfung wäre ein großer Verlust.

  • Kommentar zum SWEbench-Benchmark:

    • Der SWEbench-Benchmark umfasst nur Python-Code-Projekte und repräsentiert daher nicht alle Programmiersprachen und Frameworks.
    • Es wird vorgestellt, dass an einem allgemeineren Bewertungs-Framework für SWE-Aufgaben für JS, SQL, Python usw. gearbeitet wird.

  • Kommentar zum Demo-Vergleich:

    • Die Demo sei dem Devin-Projekt sehr ähnlich gewesen, weshalb man nachgesehen habe.
    • Es werden Zweifel an der Glaubwürdigkeit der Demo geäußert, und man würde gern eine Bewertung durch Dritte hören.

  • Kommentar zur Review-Arbeit:

    • Es wird gefragt, wie viel zusätzliche Arbeit für echte Menschen dadurch entstanden ist, die von der AI vorgeschlagenen Änderungen zu überprüfen.

  • Kommentar zu ähnlichen Projekten:

    • Es wird ein ähnliches Projekt vorgestellt und ein GitHub-Link bereitgestellt.
    • Der Fokus liegt darauf, wie man damit umgeht, wenn das Modell in die falsche Richtung läuft.
    • Es wird betont, dass das Schließen der Entwickler-AI-Feedback-Schleife der Schlüssel zu echter Produktivitätssteigerung ist.

  • Kommentar mit einem Vorschlag an die Autoren:

    • Es wird darauf hingewiesen, dass die Erfolgsquote nur für Forschende aussagekräftig ist, und vorgeschlagen, im README Beispiele für Tests zu ergänzen, die SWE-agent bestanden bzw. nicht bestanden hat.

  • Kommentar zu Beiträgen für Open-Source-Projekte:

    • Als Junior-Entwickler wünscht man sich ein Tool, das dabei hilft, Wege zu finden, zu Open-Source-Projekten beizutragen.
    • Es wird die Erfahrung geteilt, dass die Python-Packaging-Dokumentation schwer zugänglich war, man das aber überwunden hat und es nun leicht fällt.
    • Es wird angekündigt, nach nicht modernisierten Projekten zu suchen, Verbesserungen vorzuschlagen und diese umzusetzen.
    • Man möchte Ideen mit Menschen teilen, die ähnliche Gedanken oder Inspirationen haben.