kyma_poc

kyma_poc

Kyma (griechisch für Welle, https://www.howtopronounce.com/kyma) ist eine Proof-of-Concept-Demonstration mit generativer KI innerhalb von Konveyor.io, um bei Code-Modernisierungsbemühungen zu helfen.

Folien: Konveyor KymaML: GenAI-Codemigration

Überblick

• Kyma konzentriert sich auf die Nutzung von Daten, die Konveyor bereits über Migration Waves sammelt, und auf die Sicht auf das Anwendungsportfolio eines Unternehmens.
• Kyma prüft den Analysebericht einer bestimmten Anwendung und generiert potenzielle Patches für jeden Vorfall.
  • Dies geschieht durch die Betrachtung ähnlicher Vorfälle, die in anderen Anwendungen gelöst wurden, die Erfassung des Codeunterschieds, der diesen Vorfall behoben hat, und die Zusammenarbeit mit einem LLM, um zu nutzen, wie die Organisation das Problem in der Vergangenheit für diese spezifische Anwendung und diesen Vorfall gelöst hat.
    • Für den POC umfasst dies die Betrachtung von Anwendungen, die sowohl über Javaee- als auch Quarkus-Lösungen verfügen. Wir werden simulieren, wie die Erfahrung in Konveyor aussehen würde, wo wir Zugriff auf ein größeres Anwendungsportfolio haben und ähnliche Anwendungen finden können, die bereits migriert wurden, und sie als verwenden können Beispiele.
• Der Ansatz nutzt schnelles Engineering mit Few-Shots-Beispielen und einer Reihe von Agenten, die mit dem LLM zusammenarbeiten, um den generierten Patch zu verbessern.
  • Hinweis: Modellschulung und Feinabstimmung sind in dieser Phase nicht erforderlich. Wir haben Pläne für eine Feinabstimmung in Verbindung mit Open Data Hub in der Zukunft und nutzen Open-Source-Grundlagenmodelle von Huggingface.co, doch das ist in dieser aktuellen Phase nicht möglich.
• Wir gehen davon aus, dass Kyma mit verschiedenen Modellen arbeiten wird, unser Fokus liegt auf der Werkzeugausstattung/prompten Konstruktion und gehen davon aus, dass wir die Modellkoordinaten als austauschbare Einheit behandeln werden. Dies soll es uns ermöglichen, mit sich entwickelnden Modellen zu experimentieren.

Was sind unsere Erfolgskriterien für den Proof of Concept?

• Wir wollen abschätzen, welches Qualitätsniveau wir durch schnelles Engineering, also ohne Feinabstimmung, erreichen können.
  • Zukünftige Phasen erfordern möglicherweise eine Feinabstimmung, aber in dieser Phase geht es um einen einfacheren Ansatz zum Erstellen von Tools zum Sammeln nützlicher Daten in Konveyor und zum Einsatz von Prompt-Engineering, um Migratoren bei Codeänderungen zu unterstützen
• Dieser POC soll ein kleines Python-Projekt sein, das mit einigen Beispielanwendungen und Analyseberichten arbeitet, um den Nutzen generierter Patches im Bereich der Modernisierung von Java EE-Anwendungen für Quarkus zu beurteilen
• Erfolg bedeutet für uns, Patches generieren zu können, die dem Migrator bei der Modernisierung einer Anwendung Zeit sparen.
  • Wir gehen davon aus, dass die Patches nicht immer zu 100 % funktionsfähig sein werden und einige Benutzereingriffe erfordern. Der Erfolg hängt davon ab, wie viel Eingriff erforderlich ist und ob die Patches ausreichend helfen, um Zeit zu sparen.

Aufstellen

1. python -m venv env
2. source env/bin/activate
3. pip install -r ./requirements.txt
4. Installieren Sie podman, damit Sie Kantra für die statische Codeanalyse ausführen können

Läuft

Führen Sie eine Analyse einer Beispiel-App durch (Beispiel für MacOS)

1. cd data
2. ./fetch.sh # Dadurch werden einige Beispiel-Quellcode-Apps geklont
3. ./darwin_restart_podman_machine.sh # richtet die Podman-VM unter MacOS ein, sodass das Host-Dateisystem in der VM gemountet wird
4. ./darwin_get_latest_kantra_cli.sh # ruft „Kantra“ aus unserem Analysetool ab
5. ./analyzer_coolstuff.sh # Analysiert das Verzeichnis „coolstuff-javaee“ und schreibt eine Analyseausgabe in example_reports/coolstuff-javaee/output.yaml
   • Befolgen Sie dieses Beispiel, um andere Beispielanwendungen zu analysieren

Generieren Sie eine Markdown-Version eines bestimmten Analyseberichts

• Dadurch wird die YAML-Ausgabe übernommen und zur einfacheren Ansicht in Markdown konvertiert

1. Beginnen Sie im Projektstammverzeichnis und führen Sie es aus
   • ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml example_output/coolstuff-quarkus

     • Dies setzt voraus, dass ein Kantra-Analysebericht in YAML unter data/example_reports/coolstuff-javaee/output.yaml vorhanden ist

     • Beispielausgabelauf:

         $ time ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml example_output/coolstuff-quarkus
         We have results from 4 RuleSet(s) in data/example_reports/coolstuff-javaee/output.yaml
       
         Writing eap7/websphere to example_output/coolstuff-quarkus/eap7_websphere.md
         Writing eap8/eap7 to example_output/coolstuff-quarkus/eap8_eap7.md
         Writing openshift to example_output/coolstuff-quarkus/openshift.md
         Writing quarkus/springboot to example_output/coolstuff-quarkus/quarkus_springboot.md
         ./kyma.py report data/example_reports/coolstuff-javaee/output.yaml   1.28s user 2.12s system 337% cpu 1.007 total
       

     • Beispielausgaben können auf Github unter data/example_reports/coolstuff-javaee/output.yaml angezeigt werden

       • example_output/coolstuff-quarkus/eap7_websphere.md
       • example_output/coolstuff-quarkus/eap8_eap7.md
       • example_output/coolstuff-quarkus/openshift.md
       • example_output/coolstuff-quarkus/quarkus_springboot.md

Generieren Sie ein Ergebnis aus der LLM-Interaktion

1. export OPENAI_API_KEY="mysecretkey"
   • Informationen zum Erstellen eines API-Schlüssels finden Sie unter https://platform.openai.com/api-keys
2. ./generate_coolstuff.sh
   • Sehen Sie sich „generate_coolstuff.sh“ als Beispiel für den Aufruf an
3. Sehen Sie sich die Ergebnisse für das Obige unter example_output/coolstuff-quarkus an
   • Für den ersten Vorfall jedes Verstoßes werden zwei Arten von Dateien als Ausgabe erstellt (wir arbeiten derzeit nur am ersten Vorfall).
     • '*_full_run.md' Eine Markdown-Datei, die die Eingabeaufforderung, die an das LLM gesendet wurde, und das vollständige Ergebnis anzeigt
     • „.diff“ – Ein Diff, der für den ersten Vorfall jedes Verstoßes erstellt wird
   • Beachten Sie, dass wir die Ausgabe basierend auf dem zu suchenden Modell aufschlüsseln:
     • example_output/coolstuff-quarkus/gpt-3.5-turbo-16k
     • example_output/coolstuff-quarkus/gpt-4-1106-preview
   • Beispiel für ein konkretes Problem und Ergebnis:
     • example_output/coolstuff-quarkus/gpt-4-1106-preview/quarkus_springboot_cdi-to-quarkus-00050_2_full_run.md

Notizen

• Vorstellung der Laufzeiten, wenn wir coolstuff-store bearbeiten für:
  • -t "quarkus" -t "jakarta-ee" -t "jakarta-ee8+" -t "jakarta-ee9+" -t "cloud-readiness"
    • 'gpt-3.5-turbo-16k'
      • time ./generate_coolstuff.sh 5.12s user 3.46s system 1% cpu 11:02.25 total
    • 'gpt-4-1106-preview'
      • ./generate_coolstuff.sh 4.86s user 3.73s system 0% cpu 15:52.24 total