Prompt-Versionierung ohne Plattform
Sie benötigen kein Prompt-Management-Produkt, um Änderungen an Prompts nicht blind auszuliefern. Eine Datei, ein Versionskennzeichen und eine Regel über außerbandmäßige Bearbeitungen decken den größten Teil dessen ab, was eine Plattform anbietet.
Das Problem mit der Bearbeitung von Prompts in einer Konsole
Ein bearbeitbarer Prompt in einer Herstellerkonsole ist der höchstgeschwindigkeitsänderungspfad in den meisten KI-Systemen und der am wenigsten dokumentierte. Eine Formulierungsanpassung wird während eines Vorfalls gespeichert, das Verhalten ändert sich für jeden Benutzer sofort, und nichts im Code-Repository, der Überprüfungsverlauf oder die Versionshinweise spiegeln es wider. Wenn die Qualität einen Monat später sinkt, ist die wahrscheinlichste Erklärung unsichtbar.
Eine Plattform ist eine Lösung. Die Version der Lösung, die für ein kleines Team geeignet ist, ist ein Satz von Konventionen, und es dauert weniger Zeit, sie zu übernehmen, als etwas zu beschaffen.
Vier Konventionen, die die Grundlagen abdecken
Prompts leben im Repository. Eine Datei pro Prompt oder ein Verzeichnis mit einer Datei pro Prompt, im gleichen Überprüfungsprozess wie Code. Wenn die Laufzeit Prompts aus einem Dienst lädt, wird dieser Dienst durch eine Bereitstellung aus dem Repository bevölkert — und nicht durch eine Person, die in ein Formular tippt.
Jeder Prompt trägt einen Versionsidentifier. Ein kurzer Hash des Inhalts reicht aus, und er hat die nützliche Eigenschaft, dass es unmöglich ist, ihn zu aktualisieren. Der Identifier wird mit jeder Antwort protokolliert, was es ermöglicht, eine Regression einem Prompt zuzuordnen und nicht einem Modellupdate, einer Korpusänderung oder einem Codepfad.
Ein Wechsel wird auf einer Evaluierungsdifferenz akzeptiert. Der Commit, der einen Prompt ändert, gibt an, welche Evaluierungsartikel sich bewegt haben und in welche Richtung. Dies ist der einzige Mechanismus, der die Ansammlung von Anpassungen verhindert, die jeweils einen Fall behoben und einen anderen kaputt gemacht haben.
Außerbandbearbeitungen werden als Vorfälle behandelt. Wenn jemand den Live-Prompt bearbeitet, um einen Ausfall zu stoppen, muss die gleiche Bearbeitung vor dem Schließen des Vorfalls im Repository landen. Ohne diese Regel weicht das Repository von der Produktion innerhalb eines Vorfalls ab, und jeder nachfolgende Versionsidentifier ist eine Lüge.
Was pro Antwort aufzuzeichnen ist
- Der Prompt-Versionsidentifier und die tatsächlich servierten Modellversionen anstelle der angeforderten.
- Die Parameter, die die Ausgabe beeinflussen: Temperatur, Ausgabelimit, jede Werkzeugdefinition.
- Ein Verweis auf den abgerufenen Kontext, damit eine Qualitätsbeschwerde reproduziert werden kann, anstatt diskutiert zu werden.
- Der Entscheidungspfad, wenn die Anfrage geroutet oder herabgestuft wurde — ein kleineres Modell, das aufgrund der Nichtverfügbarkeit des großen Modells antwortet, sieht in der Antwort identisch aus.
Der Vergleich, der den Aufwand rechtfertigt
Wenn sich die Qualität ändert, ist die erste Frage immer, ob das Modell, der Prompt oder die Daten geändert wurden. Modellupdates werden angekündigt, Datenänderungen sind normalerweise laut. Prompt-Änderungen sind die stillen, und mit dem Identifier in den Protokollen dauert die Antwort Minuten anstelle eines Tages des Aufteilen von Bereitstellungen.
Der zweite Vorteil tritt bei der Überprüfung auf. Ein Prompt-Diff mit einem angehängten Evaluierungsdelta ist überprüfbar; ein Prompt-Diff allein lädt zu einem Streit über die Formulierung ein, den niemand gewinnt und der die Änderung verzögert.
Was daraus folgt
- Prompts gehören in das Repository, nicht in die Konsole
- Protokollieren Sie die Prompt-Version bei jeder Antwort
- Jede Änderung an einem Prompt benötigt die Bewertungsdifferenz, mit der sie akzeptiert wurde