1. Formulieren Sie die Frage, bevor Sie die Varianten vorbereiten
Ein nützlicher Vergleich beantwortet eine präzise Entscheidung: Verhindert eine höhere Maximallänge abgeschnittene Antworten? Bewahrt ein Detailgrad die nötigen Konturen? Schließt eine größere Gruppe ohne Fehler ab? Wählen Sie eine Frage und einen einzigen Parameter. „Die besten Einstellungen finden“ ist für eine erste Sitzung zu weit gefasst.
Nennen Sie A die Referenz und B die Variante. Notieren Sie den genauen geänderten Wert. Wenn Sie gleichzeitig das Modell, die Dimensionen und die Anzahl der Durchläufe ändern, kann ein anderes Ergebnis entstehen, ohne dass erkennbar ist, welche Änderung es erklärt. Bewahren Sie solche Versuche für getrennte Vergleiche auf.
2. Legen Sie einen kleinen Korpus und die Beurteilungsregeln fest
Stellen Sie dieselben Eingaben für A und B zusammen. Ein Dutzend Fälle kann für eine erste begrenzte Entscheidung ausreichen, wenn sie die Schwierigkeiten des Projekts abdecken: feiner Text in einem Bild, langes Dokument, fehlende Angabe oder ungewöhnliches Format. Diese Zahl ist eine praktische Wahl, keine statistische Garantie. Vermeiden Sie es, nur die Beispiele aufzunehmen, die bereits erfolgreich waren.
Schreiben Sie für jede Eingabe vor dem Test die Erfolgsbedingungen auf. Unterscheiden Sie eine Darstellungsvorliebe von einem blockierenden Mangel. In einem Dokumentenassistenten kann eine angenehmere Antwort weiterhin abgelehnt werden, wenn sie eine Regel erfindet. Bei einem Produktbild wiegt eine attraktive Farbe nicht das Verschwinden eines wichtigen Elements auf.
Legen Sie außerdem die Mindestanzahl akzeptierter Fälle, die verbotenen Mängel und die maximale Kontrollzeit fest. Diese projektspezifischen Schwellenwerte müssen bei der Prüfung der Ergebnisse identisch bleiben.
| Festzulegen | Beispiel einer Notiz | Warum das wichtig ist |
|---|---|---|
| Eingaben | cas-01 bis cas-12, dieselben Dateien und dieselben Formulierungen | Dieselben Schwierigkeiten vergleichen |
| Qualitätskriterium | Im Dokument überprüfbare Antwort und ohne Erfindung | Vermeiden, dass eine flüssige Ausgabe einen Fehler verdeckt |
| Kritischer Fehler | Fehlende Regel als sicher dargestellt | Einen Mangel ablehnen, auch wenn die Gesamtbilanz besser scheint |
| Variable | A: 128; B: höchstens 256 neue Tokens | Den Unterschied einer identifizierten Änderung zuschreiben |
3. Behalten Sie dieselbe Sitzung und dieselben Abhängigkeiten bei
Behalten Sie das Modell, seine Version, die Erweiterungen, die Rechen-Engine und die übrigen Parameter bei. Nutzen Sie dieselbe Umgebung und dieselbe GPU, ohne zwischen den beiden Varianten eine weitere Verarbeitung zu starten. Notieren Sie, was Sie nicht kontrollieren können: sichtbare konkurrierende Aktivität, aufgezwungener Versionswechsel oder abweichendes Laden. Ein Vergleich, der durch solche Änderungen beeinträchtigt wird, erfordert mehr Vorsicht.
Wenn das Tool einen Zufallsseed verwendet und ihn festlegen lässt, behalten Sie den Wert für jedes Durchlauf-Paar bei. Das erleichtert einen Vergleich, verspricht aber keine überall identische Ausgabe. PyTorch weist darauf hin, dass vollständige Reproduzierbarkeit zwischen Versionen oder Plattformen nicht garantiert ist, selbst bei identischem Seed.
Erstellen Sie zwei Ordner, A und B, mit derselben Liste von Kennungen. Bewahren Sie die Rohausgaben vor jeder manuellen Korrektur auf. Eine nachträgliche Überarbeitung muss als zusätzlicher Vorgang mit ihrem Arbeitsaufwand erscheinen und darf nicht der Einstellung zugerechnet werden, die die ursprüngliche Datei erzeugt hat.
4. Führen Sie einen Kontrolldurchlauf durch und vergleichen Sie dann die Paare
Prüfen Sie zunächst, ob eine einfache Eingabe bis zur abgerufenen Datei oder Antwort durchläuft. Dieser Durchlauf kontrolliert die Methode. Melden Sie ein erstes Laden oder eine besondere Vorbereitung getrennt: Vergleichen Sie nicht den vollständigen Start von A mit einem Durchlauf B, bei dem alle Elemente bereits geladen sind.
Führen Sie dieselben Fälle für A und B aus. Wechseln Sie die Reihenfolge, wenn das Tool es zulässt, und spielen Sie dann einige entscheidende Paare in umgekehrter Reihenfolge erneut durch. Prüfen Sie, ob ein einzelnes Ergebnis oder ein Reihenfolgevorteil die gesamte Schlussfolgerung bestimmt.
Halten Sie auch Fehler und abgelehnte Ausgaben fest. Wenn B bei einer großen Eingabe scheitert, entfernen Sie diese nicht aus der Tabelle, um den Durchschnitt zu verbessern. Beheben Sie gegebenenfalls die Ursache in einem gesonderten Versuch B2. So behalten Sie einen lesbaren Vergleich statt eines Ordners, in dem die Variante im Laufe der Schwierigkeiten wechselt.
5. Trennen Sie das akzeptierte Ergebnis und die beobachtete Zeit
Prüfen Sie zunächst die Qualität in der Größe oder im Tool des tatsächlichen Einsatzes. Wenn möglich, blenden Sie zum Zeitpunkt der Beurteilung die Namen A und B vorübergehend aus. Eine Person kann die Ausgaben einfach in gemischter Reihenfolge sichten und anschließend ihre Zuordnung wiederherstellen. Behalten Sie die angekündigten Kriterien und eine kurze Begründung für jede Ablehnung bei.
Wählen Sie für die Zeit eine einheitliche Definition: zum Beispiel vom Start bis zur vollständig gespeicherten Ausgabe. Trennen Sie anschließend die menschliche Kontrolle und die Korrekturen ab. Eine Stoppuhr um einen GPU-Aufruf herum ist nicht immer eine Messung der abgeschlossenen Berechnung: Bei PyTorch/CUDA können Vorgänge asynchron sein. Verwenden Sie die vom Tool dokumentierte Messmethode, wenn Sie die Berechnung isolieren möchten.
Wenn sich die Wiederholungen überschneiden oder die Zeitmessung ungenau bleibt, notieren Sie „Zeitunterschied nicht aussagekräftig“. Eine kleine Abweichung bei einem einzigen Durchlauf rechtfertigt keinen prozentualen Gewinn, der als sicher dargestellt wird.
Beispiel: 128 oder 256 neue Tokens für einen Dokumenten-Assistenten
Ein kleines Team möchte vollständige Antworten auf zwölf feste Fragen. Es behält dasselbe Modell, dieselben Dokumente, dieselbe Anweisung und dieselbe GPU bei. Nur das Antwortlimit ändert sich: A erlaubt 128 neue Tokens, B erlaubt 256. In Transformers begrenzt max_new_tokens die Generierung, ohne die Tokens des Eingabetexts mitzuzählen. Ein Token ist kein Wort: Das Limit legt keine genaue Anzahl von Sätzen fest.
Vor dem Versuch legt das Team eine beispielhafte Regel fest: mindestens zehn akzeptierte Antworten von zwölf und keine erfundene Regel. Die folgende Tabelle ist ein fiktives Szenario zum Lesen der Ergebnisse. Sie beschreibt keinen gemessenen Assistenten und sagt nicht voraus, wie sich diese Werte auf Ihr Modell auswirken.
A erreicht das Minimum, B erzielt mehr akzeptierte Antworten, behält aber einen kritischen Mangel. Die Entscheidung lautet, A für diesen Umfang beizubehalten, mit einer Nachprüfung der Antworten, und die Ursache des Mangels von B vor einem weiteren Vergleich zu untersuchen. Die größere Länge ist weder ein Beweis für Qualität noch die sichere Ursache der Erfindung.
Das Team spielt die Fragen erneut durch, die A und B unterscheiden, sowie zwei bereits erfolgreiche Fragen. Tritt der Mangel auch bei A auf, setzt es das Urteil aus: Der ursprüngliche Korpus hatte nicht ausgereicht, um die Stabilität zu belegen. Es bewahrt die Aufzeichnung beider Durchläufe auf, statt nur den günstigeren zu behalten.
| Kriterium des Szenarios | A: maximal 128 Tokens | B: maximal 256 Tokens |
|---|---|---|
| Akzeptierte Antworten | 10 von 12 | 11 von 12 |
| Kritische Mängel | 0 | 1 erfundene Regel |
| Dauer | In der realen Sitzung zu erfassen | Mit derselben Methode zu erfassen |
| Einhaltung der angekündigten Regel | Ja, in diesem begrenzten Szenario | Nein, trotz des besten Gesamtergebnisses |
Vermeiden Sie Schlussfolgerungen, die Ihr Test nicht zulässt
Wählen Sie B nicht, weil eine seiner Ausgaben spektakulär ist, während sich die anderen verschlechtern. Ändern Sie das Korpus nicht zwischendurch, zählen Sie zwei Wiederholungen nicht als zwei verschiedene Eingaben und streichen Sie einen Fehlschlag nicht aus dem Nenner. Zwölf vorgestellte Eingaben bleiben zwölf zu erklärende Fälle, auch wenn einige davon keine Datei erzeugt haben.
Die gewählte Einstellung gilt für die geprüften Eingaben, Versionen und Kriterien. Sie kann für ein zehnmal längeres Dokument oder für andere Bilder nicht mehr passen. Fügen Sie schrittweise repräsentative Fälle hinzu. Diese Erweiterung vergrößert die Kontrolle; sie macht aus einem kleinen Test keine Zertifizierung des Systems.
Halten Sie eine kurze Entscheidung und die nächste Prüfung fest
Ihre abschließende Dokumentation enthält das Korpus, die beiden Konfigurationen, die Ausgaben, die Urteile pro Kennung und einige Zeilen Fazit. Geben Sie die gewählte Einstellung, den Grund und die Grenze an: „A hat sich bei diesen zwölf Fragen durchgesetzt; zwei Antworten sind noch zu überprüfen; zusätzliche lange Dokumente sind nicht abgedeckt“. Eine andere Person muss die Entscheidung verstehen können, ohne an der Sitzung teilgenommen zu haben.
Behalten Sie A als Referenz für die nächste Diagnose. Wenn keine Variante die Kriterien erfüllt, behalten Sie keine davon für die Auslieferung; formulieren Sie eine neue Hypothese. Planen Sie Zeit für das Kopieren und die Kontrolle ein, bevor Sie diese Fortsetzung starten. Ein abgeschlossener Versuch mit einer klaren Grenze liefert bereits eine Entscheidung; er verpflichtet Sie nicht, weiterzumachen, bis sich ein Sieger findet.