Beispielanleitung
Suchen Sie nach Code, den Sie anpassen können, statt nach einem Screenshot, den Sie nur bewundern können? Ermitteln Sie zuerst, welche Aufgabe, welches Modell und welche Antwortdaten Ihr Projekt benötigt. Diese Anleitung trennt die Suche nach Repositorys von drei beispielhaften Workflows. Die Modell-Links führen zur Modell-API, nicht zu einem GitHub-Repository von Runware. Verwenden Sie für Anfragen an die Modell-API die Modell-API-Beispiele der Zielseite.
Ein Repository-Suchergebnis kann relevant wirken und trotzdem die falsche Frage beantworten. Prüfen Sie, ob das Beispiel zu Ihrem Anwendungsfall passt, bevor Sie seine Anfrage übernehmen.
Sie möchten eine vom Nutzer eingegebene Beschreibung in ein Bild umwandeln. Ein Repository-Beispiel kann jedoch Eingabe, Modell oder Verarbeitung der Ausgabe fest vorgeben. Eine erfolgreiche Beispielanfrage ist noch keine Funktion für Nutzer.
Verfolgen Sie nach, wo der Prompt in die Anfrage eingeht, wo die Antwort ausgelesen wird und wo Fehler angezeigt werden. Eine allgemeinere Schrittfolge finden Sie in der verlinkten Nutzungsanleitung.
So verwenden Sie runware AISie möchten aus demselben Briefing mehrere visuelle Richtungen entwickeln. Ein Beispiel zeigt möglicherweise nur ein einzelnes Ergebnis, ohne zu erklären, ob die Modellwahl zu Ihrem Motiv oder gewünschten Stil passt.
Notieren Sie das im Beispiel genannte Modell und vergleichen Sie Ergebnisse anhand eines einheitlichen Briefings, bevor Sie dessen Einstellungen übernehmen.
runware-ModelleSie haben einen Codeausschnitt gefunden, können aber nicht erkennen, welchen Dienst er aufruft, welche Zugangsdaten er erwartet oder ob das Format seiner Antwort noch mit der Dokumentation des Dienstes übereinstimmt.
Ermitteln Sie zuerst den Dienst und den dokumentierten Ablauf für Anfragen. Testen Sie den Codeausschnitt anschließend in einer kontrollierten Umgebung, statt Repository-Code als Produktgarantie zu betrachten.
Was ist runware?Nutzen Sie diese drei Wege als Lesereihenfolge: Klären Sie die grundlegende Anfrage, prüfen Sie die Modellwahl und stellen Sie dann fest, was der Dienst und das Beispiel tatsächlich abdecken.
Die folgenden Ergebnisse sind beispielhafte Akzeptanzprüfungen, keine aufgezeichneten Antworten oder Aussagen über ein bestimmtes GitHub-Repository. Die tatsächlich beobachtete Ausgabe hängt vom getesteten Beispiel ab.
Eingabe: eine kurze Beschreibung eines Produktbilds durch einen Nutzer. Erwartetes Anwendungsergebnis: das zurückgegebene Bild anzeigen und einen Fehlerzustand sichtbar halten, wenn die Anfrage nicht abgeschlossen werden kann. Ein nützliches Beispiel zeigt sowohl den Aufbau der Anfrage als auch die Verarbeitung der Antwort; ein Bild in einer README beweist nicht, dass beides in Ihrer Oberfläche funktioniert. Bauen Sie nicht auf einem angenommenen Antwortfeld auf, bevor Sie die aktuelle Dokumentation geprüft und eine tatsächliche Antwort getestet haben.
Eingabe: eine Beschreibung, die für mehrere visuelle Versuche wiederverwendet wird. Erwartetes Evaluationsergebnis: eine kurze Vergleichsübersicht mit der Beschreibung, dem verwendeten Modell und jedem beobachteten Ergebnis. So kann ein Team erklären, warum es sich für eine Richtung entschieden hat, ohne ein Beispielbild aus einem Repository mit einem reproduzierbaren Benchmark zu verwechseln. Wenn das Beispiel Einstellmöglichkeiten bietet, ändern Sie jeweils nur eine; andernfalls beschränken Sie den Vergleich auf Einstellungen, die Sie überprüfen können.
Eingabe: eine Testanfrage aus einer Nicht-Produktionsumgebung. Erwartetes technisches Ergebnis: eine Aufzeichnung der Antwortfelder, die Ihr Code tatsächlich erhält, sowie des Verhaltens bei ungültigen Anfragen und fehlender Ausgabe. Das ist weniger fotogen als eine Galerie, aber genau hier wird aus einem ansprechenden Codebeispiel ein Kandidat für eine zuverlässige Integration. Protokollieren Sie keine geheimen Zugangsdaten und gehen Sie nicht davon aus, dass ein Beispiel Wiederholungsversuche, Speicherung oder Zugriffskontrolle abdeckt.
Betrachten Sie GitHub-Beispiele als Code, den Sie prüfen müssen, nicht als Erlaubnis, alle darin enthaltenen Abhängigkeiten, Bilder oder anderen Assets wiederzuverwenden. Lesen Sie die Lizenz jedes Repositorys, prüfen Sie die Abhängigkeiten und vergewissern Sie sich, dass die Anweisungen mit der aktuellen Servicedokumentation übereinstimmen. Speichern Sie Zugangsdaten nicht in Dateien, die Sie committen, verwenden Sie keine sensiblen Nutzerinhalte in Test-Prompts und prüfen Sie die Bedingungen für Ihre beabsichtigte Nutzung. Wenn bei einem Beispiel die Lizenz oder der Kontext der Maintainer unklar ist, fragen Sie nach oder wählen Sie einen besser dokumentierten Ausgangspunkt.
Bilderzeugung entdeckenSuchen Sie auf GitHub nach dem Namen des Dienstes zusammen mit der Aufgabe, die Sie ausführen möchten, etwa Bilderzeugung oder die Verarbeitung von Antworten. Prüfen Sie die Maintainer, den Aktualisierungsverlauf und die Lizenz des Repositorys, bevor Sie ein Ergebnis als verlässlichen Ausgangspunkt betrachten.
Gehen Sie nicht davon aus. Ein Beispiel kann von bestimmten Zugangsdaten, Modellkennungen, Bibliotheksversionen oder Antwortfeldern abhängen. Vergleichen Sie es daher mit der aktuellen Dokumentation und führen Sie einen kleinen Test durch, bevor Sie es integrieren.
Achten Sie auf die Eingaben der Anfrage, die Modellauswahl und Code, der sowohl Ergebnisse als auch Fehler verarbeitet. Ein Beispielbild allein zeigt nicht, wie die Anwendung eine Ausgabe empfängt oder anzeigt.
Prüfen Sie zuerst die Lizenz und etwaige Hinweise für einzelne Assets; für Code und Bilder können unterschiedliche Nutzungsrechte gelten. Wenn die Bedingungen unklar sind, verwenden Sie eigene Assets, statt davon auszugehen, dass das Repository eine Wiederverwendung erlaubt.
Betrachten Sie die Ausgabe als unbekannt, bis Sie das Beispiel in einer Testumgebung ausführen und eine tatsächliche Antwort prüfen. Halten Sie die beobachteten Felder fest und prüfen Sie, wie sich das Beispiel bei einer fehlgeschlagenen Anfrage verhält.