Prompt Engineering, gemessen: Was die Ausgabe verändert

Vor den Messungen eine Tatsache, die still die Hälfte dessen erklärt, was folgt.

Das Modell hat kein Gedächtnis. Zwischen zwei Aufrufen behält es nichts — nicht deine letzte Frage, nicht seine eigene letzte Antwort, nicht die Datei, die du angehängt hast, nicht die Tatsache, dass du schon zweimal gefragt hast. Jeder Aufruf startet mit einer leeren Maschine, und das Einzige, was diese Maschine kennt, ist die Sequenz von tokens, die du ihr gerade gegeben hast.

Was in einer Chat-Oberfläche wie Gedächtnis aussieht, ist dein Client, der die ganze Unterhaltung bei jedem Turn erneut sendet, von Anfang an. Das Modell liest alles jedes Mal wieder von null. Kapitel 13 hat gemessen, was dieses erneute Lesen in einem Forward Pass kostet; Kapitel 16 macht daraus eine Zeile auf einer Rechnung. Hier zählt die Konsequenz fürs Design: Der prompt ist keine Nachricht an ein System, das Zustand hat. Er ist der Zustand.

Damit erledigt sich eine ganze Familie von Verwirrungen. „Das Modell hat vergessen, was ich ihm gesagt habe“ heißt meistens: Es wurde nie gesendet. „Es hat meine frühere Anweisung ignoriert“ heißt meistens: Die Anweisung fiel aus dem Fenster, als der Verlauf gekürzt wurde. „Es verhielt sich in Produktion anders“ heißt meistens: Produktion baut einen anderen prompt zusammen als den, den du getestet hast. Nichts davon ist ein Modellproblem, und nichts davon wird durch Umformulieren behoben.

Die Behauptung „dieser prompt ist besser“ ist eine Behauptung über eine Verteilung, und eine Verteilung sieht man nicht, indem man eine Ausgabe anschaut. Was du brauchst, ist langweilig: Fälle mit bekannten Antworten, N Varianten und ein Intervall.

Der harness besteht aus fünfzig Zeilen TypeScript mit derselben Form wie der Client aus Kapitel 14 — eine Anfrage, eine Deadline, etwas Parallelität, eine Zählung. Er taucht in Kapitel 19 wieder auf, um einen Retriever zu evaluieren, und in Kapitel 29 als Golden Set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

Die Zahl, die zurückkommt, ist nicht das Ergebnis. Das hier ist es:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

Kapitel 4 hat das Argument gemacht, dieses Kapitel löst es ein. Siebzehn richtige von zwanzig sind 85 %, und das 95-%-Intervall läuft von 64 % bis 95 %. Eine Variante mit 13 von 20 — 65 %, was sich deutlich schlechter anfühlt — hat ein Intervall von 43 % bis 82 %. Diese beiden Intervalle überlappen fast auf ihrer gesamten Länge. Zwanzig Fälle können einen guten prompt nicht von einem mittelmäßigen unterscheiden, und die meisten veröffentlichten prompt-Ratschläge wurden mit weniger validiert.

Sechzig Fälle, so viele nutzt dieses Kapitel, sind immer noch nicht viel. Es reicht, um große Effekte zu sehen, und es ist ehrlich genug, zuzugeben, wenn es kleine nicht sehen kann — und das wird weiter unten mehrfach passieren.

Drei Blöcke — die Regeln R, das Ticket T, die Anweisung I — zu einer User-Nachricht verkettet. Alle sechs Permutationen, byte-identischer Inhalt, je sechzig Fälle.

Vom besten zum schlechtesten sind es 28,3 Punkte, und die Intervalle überlappen nicht, also ist das keine Geschichte über Rauschen. Da jeder Arm auf denselben sechzig Items bewertet wird, ist die schärfere Frage die gepaarte: Bei den Fällen, in denen zwei Arme widersprechen, wie einseitig ist die Aufteilung? Der Wechsel von der schlechtesten zur besten Reihenfolge drehte 21 Fälle auf richtig und 4 auf falsch — exakte gepaarte Wahrscheinlichkeit 0,0009.³

Lies die Tabelle wegen ihrer Form, nicht wegen ihres Siegers. Die zwei besten Zeilen enden beide mit dem Ticket; die zwei schlechtesten vergraben die Anweisung in der Mitte oder ziehen sie hinter die Daten. Das ist dasselbe Phänomen, das Liu et al. Lost in the Middle nannten: Material an den Rändern eines prompt wird zuverlässiger genutzt als Material in der Mitte.⁴ Kapitel 16 bepreist das Fenster, und Kapitel 24 misst den Effekt sauber in der Länge, wo die Mitte wie beschrieben kollabiert und die Erholung ganz am Ende nicht wieder auftaucht. Hier fällt die praktische Regel von selbst heraus: Aufgabe nach oben, Daten nach unten, nichts Wichtiges in die Mitte.

Jetzt verschiebe dieselben Wörter zwischen Turns. Kapitel 11 hat gezeigt, dass das Chat-Template keine Dekoration um das Modell ist, sondern Teil davon — <|im_start|>system und <|im_start|>user sind echte tokens, die das Modell während des fine-tuning millionenfach genau an diesen Positionen gesehen hat. Also sollte es eine Rolle spielen, auf welcher Seite dieser Marker deine Anweisung landet, und das tut es:

Regeln und Anweisung über die Template-Grenze zu verschieben brachte 21,7 Punkte — 19 Fälle gewonnen, 6 verloren, gepaarte Wahrscheinlichkeit 0,0146 — ohne ein Zeichen zu ändern. Das ist die konkrete Antwort auf system prompt versus user prompt: Es sind nicht zwei Arten, dasselbe zu sagen. Es sind zwei verschiedene token-Positionen in einer Struktur, auf die das Modell trainiert wurde, und die System-Position ist der Ort, an den Anweisungen gehören, die für die ganze Unterhaltung gelten.

Beachte auch die dritte Zeile. Die Anweisung nach dem Ticket zu wiederholen — ein häufig empfohlener Trick — lag unter der einmaligen Angabe. Bei diesem Modell, für diese Aufgabe, war zweimal sagen schlechter als einmal sagen.

Derselbe prompt, beste Platzierung, sechzig Fälle. Das Einzige, was sich ändert, ist, was den Tickettext umgibt.

Achtzehn Punkte Spanne durch Zeichensetzung. Aber schau auf die beiden extremen Intervalle: [73,9, 91,9] und [54,1, 77,3]. Sie überlappen. Nach der groben Lesart — vergleiche die Fehlerbalken, und wenn sie sich berühren, sage nichts — beweist diese Tabelle gar nichts.

Die grobe Lesart ist hier falsch, und zu verstehen warum ist mehr wert als die Tabelle. Jede Variante wurde auf denselben sechzig Tickets bewertet, also sind die beiden Messungen keine unabhängigen Stichproben; sie sind gepaart. Der größte Teil der Breite jedes Intervalls stammt aus einer Unsicherheitsquelle, die beide Arme teilen — ob diese sechzig Tickets repräsentativ sind — und diese Quelle hebt sich auf, wenn du sie miteinander vergleichst. Stell stattdessen die gepaarte Frage, und die Antwort ist scharf: Der Wechsel von doppelten Anführungszeichen zum XML-Tag drehte 12 Fälle auf richtig und 1 auf falsch, gepaarte Wahrscheinlichkeit 0,0034. Das ist ein echter Unterschied.

Und dann entzaubert derselbe Test die Schlagzeile. Das XML-Tag schlug das einfache Ticket:-Label um 8,3 Punkte, genau die Zahl, die ein Blogpost in seinen Titel schreiben würde. Gepaart: 6 gewonnen, 1 verloren, Wahrscheinlichkeit 0,1250. Nicht belegt. Auf sieben Fällen ruht diese berühmte Verbesserung.

Es gibt also zwei Fragen mit zwei unterschiedlichen Instrumenten, und sie zu vermischen ist der Weg, auf dem prompt-Ratschläge in beide Richtungen zugleich falsch werden:

Der allgemeine Befund — dass Modelle stark und unvorhersehbar auf Formatierungsentscheidungen reagieren, die keinen semantischen Inhalt tragen — ist nicht neu. Sclar et al. variierten über Dutzende Aufgaben hinweg nichts außer Trennern, Abständen und Groß-/Kleinschreibung und fanden Genauigkeitsspannen, die groß genug waren, um veröffentlichte Modellrankings umzudrehen.⁵ Die praktische Konsequenz ist nicht „nutze XML-Tags“. Sie ist: Formatierung ist ein Hyperparameter, sie kostet nichts zu sweepen, und jeder Vergleich zweier Modelle, der ein Format fixiert, vergleicht Formate ebenso sehr wie Modelle.

In-context learning — dem Modell im prompt ausgearbeitete Beispiele zu zeigen und es ohne weight update daraus generalisieren zu lassen — ist die Fähigkeit, die GPT-3 berühmt gemacht hat.⁶ Die praktische Frage ist nie, ob es funktioniert. Sie lautet, für wie viele Beispiele man bezahlen sollte.

Beispiele gehen als echte frühere Turns hinein, abwechselnd User und assistant, weil das die Struktur ist, auf die das Template trainiert wurde. Jedes k wurde mit fünf unterschiedlichen Zufallsziehungen aus einem getrennten Pool von sechzehn gelabelten Tickets ausgeführt:

Zwei Beispiele brachten sieben Punkte. Die nächsten sechs Beispiele brachten nichts Messbares — 83,7, dann 81,7, dann 83,7, eine Sequenz, die in ihrem eigenen Rauschen wandert. Sechzehn brachten weitere fünfeinhalb. Die Kurve steigt nicht glatt; sie ist ein Schritt, ein Plateau und ein Schritt.

Die wichtigste Spalte ist die letzte. Bei k = 8 verschoben die acht Beispiele, die du zufällig ausgewählt hast, die Genauigkeit um 10 Punkte — mehr als der gesamte Gewinn beim Wechsel von zwei auf acht Beispiele. Und die unterste Zeile ist die schärfste Version davon: Bei k = 16 ist der Pool erschöpft, also enthalten alle fünf Läufe exakt dieselben sechzehn Beispiele, sie unterscheiden sich nur in der Reihenfolge. Allein die Reihenfolge verschob die Genauigkeit um 8,3 Punkte.

Das ist das Ergebnis, das Lu et al. berichteten, und es überlebt überall, wo man danach gesucht hat: Die Reihenfolge von Beispielen ist ein echter Hyperparameter mit Effekten, die mit der Beispielanzahl vergleichbar sind.⁷ Der ehrliche Rat zu few-shot prompting ist also keine Zahl. Er lautet:

Jetzt die Folklore. Jeder davon ist ein einzelner Satz, der einem ansonsten identischen system prompt vorangestellt wird, auf denselben sechzig Fällen.

Vier von fünf taten nichts. Nicht „ein bisschen“; nichts, was sechzig gepaarte Fälle sehen können. Die Expertenpersona und die Bestechung lagen beide unter der unberührten Baseline, und selbst diese Rückgänge bestehen den gepaarten Test nicht — sie sind Rauschen, das bergab zeigt.

Die dritte Zeile ist die, bei der man verweilen sollte. „Das ist sehr wichtig für meine Karriere“ erzeugte exakt dieselbe Genauigkeit, 46 von 60 — und zehn der sechzig Antworten änderten sich, fünf in jede Richtung. Die Zusammenfassungsstatistik war identisch, das Verhalten nicht. Wenn deine Evaluation eine einzelne Zahl über ein kleines Set ist, kann eine Änderung, die ein Sechstel deiner Ausgaben umschreibt, aussehen wie eine Änderung, die nichts getan hat, und du lieferst sie in dem Glauben aus, sie sei kostenlos.

Und dann die Drohung, der einzige Satz, der die Nadel bewegte, und zwar 35 Punkte nach unten, indem er 24 Fälle von richtig auf falsch drehte. Das ist kein Rundungsartefakt; es ist ein anderes Modellverhalten. Die Lektion ist nicht „bedrohe niemals ein Modell“. Sie ist: Emotionales Framing ist nicht inert. Es verschiebt die Verteilung, manchmal stark, in eine Richtung, die niemand aus dem Lesen des Satzes vorhersagen kann — genau deshalb muss es gemessen statt hergeleitet werden.

Eine Einschränkung schuldet dir dieses Kapitel: Diese fünf Sätze wurden an einem kleinen Modell und einer Aufgabe getestet. Einige haben anderswo veröffentlichte Unterstützung — „take a deep breath“ stammt aus einem Paper, das nach hoch bewerteten Anweisungen gesucht hat, statt sie zu erfinden; das ist eine andere und bessere Behauptung als die, die danach kursierte.⁸ Was generalisiert, sind nicht die Sätze. Es ist, dass die Liste, die in Blogposts überlebt hat, und die Liste, die Messung überlebt, zwei verschiedene Listen sind, und der einzige Weg zu wissen, welche du in der Hand hältst, ist, den bench laufen zu lassen.

Eine Regel, die alle wiederholen — sage, was du willst, nicht was du nicht willst — mit der üblichen Abwesenheit einer Zahl. Hier ist die Zahl. Dieselbe Formatvorgabe, auf drei Arten geschrieben, wobei das Modell frei generiert, damit Compliance beobachtet werden kann:

Drei Verbote schnitten schlechter ab als eine Anweisung und brachten das Modell dazu, fünfmal mehr Text zu schreiben — das genaue Gegenteil aller drei zugleich. Den positiven Satz wieder hinzuzufügen rettete es auf 68 %.

Der Mechanismus ist nicht mysteriös, wenn du dich an Kapitel 8 erinnerst. Das Modell wählt ein nächstes token aus einer Verteilung, bedingt auf alles davor, und ein Verbot bringt das Verbotene in diese Bedingung hinein. Es gibt keinen Operator für Negation; es gibt einen Kontext, in dem ein Wort jetzt vorkommt.

Das lässt sich direkt messen. Nimm den Baseline-prompt und füge eine Zeile hinzu: Do not use the shipping queue for software problems. Dann betrachte nur die fünfundvierzig Tickets, die keine Versandtickets sind:

Eine Warteschlange zu benennen, um sie auszuschließen, brachte das Modell dazu, sie dreimal häufiger zu wählen, verdreifachte fast die Wahrscheinlichkeitsmasse, die es ihr zuwies, und kostete 25 Punkte Gesamtgenauigkeit — 16 Fälle verloren gegen 1 gewonnen, gepaarte Wahrscheinlichkeit 0,0003.

Denk nicht an einen Elefanten, gemessen. Der Rewrite ist immer derselbe: Ersetze das Verbot durch die positive Regel, die es überflüssig macht. Nicht „nutze Versand nicht für Softwareprobleme“, sondern „nutze Versand nur, wenn ein physisches Paket betroffen ist“.

Kapitel 12 hat chain of thought sauber aufgebaut — zuerst als prompting-Technik,⁹¹⁰ dann als etwas, das mit verifizierbaren Rewards hineintrainiert wird — und endete mit einer Warnung, die es auf dieses Kapitel verschob: Einem Modell zu sagen, es solle Schritt für Schritt denken, hilft nicht mehr, sobald das Modell von selbst schlussfolgert, und kann schaden. Hier ist diese Warnung mit einer Tabelle darunter, bei einer Aufgabe, bei der man leicht annimmt, mehr Denken müsse besser sein.

Beide Arme werden mit demselben Instrument an derselben Position gelesen. Der einzige Unterschied ist, ob eine chain of thought, die das Modell selbst geschrieben hat, zuerst im Kontext steht.

Die Genauigkeit sank und die Kosten stiegen, und die eigene Regel dieses Kapitels gilt auch für sein eigenes Ergebnis: Der Rückgang ist 7 Fälle gewonnen gegen 10 verloren, gepaarte Wahrscheinlichkeit 0,629, also nicht belegt. Was belegt ist: Es erzeugte achtundneunzig zusätzliche Ausgabe-tokens pro Aufruf und kaufte damit nichts Messbares. Die Unsicherheit liegt vollständig auf der Nutzenseite. Die Rechnung ist sicher.

Eine scheiternde chain ist lehrreicher als eine funktionierende. Gebeten, über „Deine Slack-Integration hat nach Dienstag aufgehört, Nachrichten zu posten“ nachzudenken, schrieb das Modell:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

Das ist kompetenter Troubleshooting-Rat, aber nicht die Aufgabe. Aufgefordert zu denken, driftete das Modell in das Genre, dem „think step by step about this support ticket“ in seinen Trainingsdaten am meisten ähnelt — und beantwortete dann eine Klassifikationsfrage mit fünfhundert Zeichen irrelevanter Begründung im eigenen Kontext. Chain of thought hilft bei Problemen mit Zwischenzustand, den es zu berechnen lohnt: Arithmetik, Multi-Hop-Lookups, Constraint Satisfaction. Einen Satz in einen von vier Buckets zu routen hat keinen Zwischenzustand. Es gibt nichts, was die chain halten könnte, also fügt sie nur plausiblen Text hinzu, den die finale Entscheidung dann überleben muss.

Zwei praktische Folgerungen. Erstens: Für ein Modell, das zum Reasoning trainiert wurde — die RLVR-Modelle aus Kapitel 12 — ist die Anweisung schlimmer als redundant: Sie kann die lange chain, die das Modell erzeugt hätte, durch eine kurze, prompt-förmige ersetzen. Und mehrere chains zu samplen und abstimmen zu lassen, wie es self-consistency tut,¹¹ kann eine Aufgabe, bei der es nichts zu uneinig sein gibt, nicht retten: Es multipliziert die Kosten mit der Zahl der Samples, um Ties zu brechen, die nicht existieren. Kapitel 12 hat diesen Trade dort gemessen, wo er gilt. Zweitens: Beachte, was das Vergleichsgerüst selbst gekostet hat. Die Antwort in eine Final queue:-Zeile zu zwingen, drückte den Arm ohne Reasoning von 76,7 % auf 61,7 %. Fünfzehn Punkte, bezahlt, um die zwei Arme vergleichbar zu machen. Struktur, die zu deiner Bequemlichkeit existiert, ist ebenfalls nicht kostenlos.

Eine letzte Messung, weil es die Frage ist, die alle nach dem ersten überraschenden Ergebnis stellen. Sechzig prompts, greedy decoding, wiederholt ausgeführt:

• Derselbe Aufruf, wiederholt mit allem fixiert, gab bit-identische Wahrscheinlichkeiten zurück. Deterministisch.
• Derselbe Aufruf, gebatched mit unterschiedlichen Nachbarn — Batchgrößen 1, 4, 12, 30 und 60 — gab Wahrscheinlichkeiten zurück, die sich um bis zu 0,0128 unterschieden. Das gewählte Label änderte sich nie, in 0 von 60 Fällen.

Das Label überlebte, weil es Platz dafür hatte: Über die sechzig Fälle hinweg betrug der kleinste Abstand zwischen den zwei besten Warteschlangen 0,0459, dreieinhalbmal so viel wie die Drift. Die Stabilität war keine Eigenschaft des Algorithmus. Sie war eine Marge, und Margen gehen aus. Kapitel 17 enthält den arithmetischen Grund und nimmt die Sampling-Regler auseinander, die diese Abstände vergrößern und verkleinern. Der Grund, es hier zu platzieren, ist, dass es begrenzt, was eine prompt-Messung überhaupt bedeuten kann: Der bench misst ein System, das nur bis zu einer Toleranz reproduzierbar ist, und ein Zwei-Punkte-Unterschied zwischen Varianten liegt an einem schlechten Tag innerhalb dieser Toleranz.

Alles oben ist ein Mensch, der eine Variante wählt, und eine Maschine, die sie bewertet. Der offensichtliche nächste Schritt ist, die Maschine auch die Varianten wählen zu lassen.

APE tut genau das: Ein Modell schlägt Kandidatenanweisungen vor, sie werden an zurückgehaltenen Beispielen bewertet, und die besten überleben.⁸ Die Anweisungen, die es findet, sind häufig solche, die kein Mensch schreiben würde, und genau darum geht es — die Suche läuft über das, was punktet, nicht über das, was professionell klingt.

DSPy geht weiter und ist die nützlichere Idee für ein Produkt.¹² Du deklarierst, was jeder Schritt einer Pipeline nimmt und zurückgibt, und das Framework kompiliert daraus prompts, wählt Demonstrationen aus und optimiert Anweisungen gegen deine Metrik. Wechselst du das Modell, kompilierst du neu, statt umzuschreiben. Der prompt hört auf, Source Code zu sein, den jemand von Hand tuned, und wird zu einem Artefakt, das gegen eine Metrik erzeugt wird — was er von Anfang an hätte sein sollen.

Keines von beidem beseitigt die Notwendigkeit des bench. Beides macht ihn zum Einzigen, was du brauchst, denn ein Optimizer ohne Metrik optimiert nichts.

Bleibt die Disziplin. Prompts gehören in die Versionskontrolle, in Dateien, neben den Code, der sie sendet — nicht in eine Datenbankzeile, die jemand an einem Dienstag editiert hat. Sie brauchen eine Versionskennung, die neben jeder von ihnen erzeugten Ausgabe gespeichert wird, sonst kannst du an dem Tag, an dem etwas regressiert, nicht herausfinden, was sich geändert hat. Sie brauchen den bench in Continuous Integration, weil ein prompt der eine Teil deines Systems ist, den ein Anbieter still invalidieren kann, indem er ein neues Modell ausrollt. Und sie brauchen Fälle: nicht hundert clevere, nur die langweiligen zwanzig, die im letzten Quartal kaputtgingen, für immer aufbewahrt. Der bench ist das Deliverable. Der prompt ist sein Nebenprodukt.

Alles in diesem Kapitel wurde in Genauigkeit gemessen. Jede einzelne dieser Varianten hat auch einen Preis.

Der system prompt, der 21,7 Punkte kaufte, wird bei jedem Aufruf gesendet, für immer. Die zwei Beispiele, die sieben Punkte kauften, werden bei jedem Aufruf gesendet, für immer. Die sechzehn, die zwölf kauften, werden bei jedem Aufruf gesendet, für immer, und sie sind ungefähr zehnmal so lang wie die Frage, die der Nutzer tatsächlich gestellt hat. Die chain of thought, die nichts kaufte, erzeugte achtundneunzig zusätzliche tokens pro Request, und Ausgabe-tokens sind die teure Sorte.

Nichts davon ist in einer Genauigkeitstabelle sichtbar, und alles davon ist auf einer Rechnung sichtbar.

Kapitel 16 handelt von der Einheit, in der diese Entscheidungen tatsächlich denominiert sind. Der token als Abrechnungseinheit, die context window als Budget statt als Gedächtnis, warum eine Unterhaltung mit vierzig Turns weit mehr kostet als vierzigmal der erste Turn, was prompt caching bezahlt und was nicht, und warum die Reihenfolge deines prompt entscheidet, ob der Cache überhaupt trifft — was sich als zweiter, rein ökonomischer Grund herausstellt, stabiles Material nach vorn und variables Material nach hinten zu setzen.

Der bench und jede Tabelle wurden mit Qwen/Qwen2.5-0.5B-Instruct unter greedy decoding erzeugt, sodass sie exakt reproduzierbar sind. Die Hugging-Face-Dokumentation zu Chat-Templates ist die Referenz dafür, worauf sich die Template-Marker aus Kapitel 11 tatsächlich expandieren, und für die Tatsache, dass ein Modell, das mit dem falschen Template ausgeliefert wird, ein realer und wiederkehrender Fehler ist. Für Positions- und Formateffekte im Produktionsmaßstab statt im Labormaßstab sind die oben genannten Zitate die Primärquellen; die Prompting-Guides der Anbieter sind wegen ihrer Beispiele nützlich und sollten mit dem Wissen gelesen werden, dass keiner davon ein Intervall veröffentlicht.