GPT-4.1 mini für Dokumenten-Workflows: Änderungen zusammenführen, offene Entscheidungen behalten

GPT-4.1 mini gehört zur GPT-4.1-Familie, die OpenAI am 14. April 2025 vorgestellt hat. Das kleinere Modell verarbeitet Text und Bilder und gibt Text aus. Für eine Anwendung, die vorhandene Dokumente auswertet, sind vor allem das Befolgen konkreter Anweisungen, der große Kontext und die Unterstützung strukturierter Ausgaben interessant.

Transparenz: Dieser Artikel wurde überwiegend mit KI erstellt. Grundlage sind gespeicherte API-Anfragen, Antworten und lokale Prüfungen. Die deutschen Erläuterungen beziehen sich auf einen chinesischsprachigen Versuch.

Warum beschäftigt mich dieses Modell noch 2026? Ein Dokumenten-Workflow braucht oft einen überschaubaren Verarbeitungsschritt: Zuständigkeiten sammeln, Änderungen einarbeiten und offene Fragen markieren. Laut den am 30. Oktober 2026 geprüften offiziellen API-Preisen von OpenAI liegen die Standard-Tokenpreise für Texteingabe und Textausgabe bei GPT-4.1 mini unter denen des neueren Flaggschiffs GPT-6 Astra. Damit ist es ein Kandidat für eine begrenzte Aufgabe. Ob der Einsatz insgesamt günstiger ist, hängt aber auch vom Prüfaufwand ab. Ich habe weder Arbeitszeit noch Modellrechnungen verglichen; die offiziellen Preise sind keine Abrechnung meines Crazyrouter-Versuchs.

Ich habe GPT-4.1 mini am 30. Oktober 2026 über die Crazyrouter-API mehrere Änderungen zu einem aktuellen Aufgabenstand zusammenführen lassen. Das Modell konnte Informationen aus verschiedenen Dokumenten verbinden. Bei einem ungelösten Terminkonflikt blieb jedoch ein Status stehen, den eine nachgelagerte Anwendung leicht falsch verstehen könnte. An diesem Fall lässt sich zeigen, wo die Ausgabe nützlich ist und wo die Anwendung selbst eine Entscheidung braucht.

Was GPT-4.1 mini in diesem Ablauf übernehmen kann

OpenAI nennt ein Kontextfenster von 1.047.576 Tokens, maximal 32.768 Ausgabetokens und einen Wissensstand vom 1. Juni 2024. Das gibt Raum für zusammengehörige Quellen. Es garantiert weder, dass jedes Detail darin erkannt wird, noch dass die Ausgabe genauso lang sein darf wie die Eingabe.

Für meinen Versuch war entscheidend, dass die ursprüngliche Anforderung neben späteren Änderungen stehen konnte. Wird nur das neueste Dokument gelesen, gehen unveränderte Bedingungen verloren. Werden alle Dokumente einzeln zusammengefasst, muss jemand die Zusammenfassungen noch zusammensetzen. Genau diesen Zwischenschritt wollte ich untersuchen.

Bildverständnis, Codeerklärung und Funktionsaufrufe sind weitere dokumentierte Einsatzmöglichkeiten. Getestet habe ich hier ausschließlich die Verarbeitung chinesischer Texte. Ein Funktionsaufruf würde außerdem eine Anwendung brauchen, die die externe Aktion ausführt. Das Modell erhielt in diesem Versuch keinen Zugriff auf ein reales Aufgabensystem.

Eine Aufgabe, drei Quellen und ein brauchbarer aktueller Stand

Meine künstlichen Projektdaten umfassten 51 kurze Dokumente für zwölf Aufgaben. Dazu gehörten Ausgangsdokumente, genehmigte Änderungen, Entwürfe, Diskussionen und ältere Vorgänge mit wiederverwendeten IDs. Personen und Ereignisse sind erfunden. Der Stichtag im Szenario war der 30. Oktober 2026 um 18 Uhr.

Für T01 stand im Ausgangsdokument B01: Zhou Ning ist zuständig, der Termin ist der 4. November, und Prüfprotokolle müssen 180 Tage aufbewahrt werden. C01 änderte nur den Termin auf den 9. November. C02 übergab die Aufgabe an Zheng Yan; die übrigen Bedingungen sollten bestehen bleiben.

Die Antwort enthielt Zheng Yan, den 9. November 2026 und weiterhin die Aufbewahrung von 180 Tagen. Auch die Quellen B01, C01 und C02 blieben erhalten. Beide regulären Durchläufe lieferten diese Werte.

Abbildung 1: Eine von mir aus den künstlichen Quellen und der ersten regulären Antwort zusammengestellte Darstellung, kein Screenshot einer Anwendung. Chinesische Originalwerte und englische Erläuterungen bleiben erhalten. Die Zuordnung einzelner Felder zu Quellen habe ich anhand der Dokumente erklärt; die API lieferte eine Quellenliste für die gesamte Aufgabe.

Das ist ein sinnvoller Beitrag zu einem Dokumenten-Workflow: Aus mehreren Änderungen wird ein Datensatz, den man prüfen kann. Eine Oberfläche, die für jedes Feld direkt die belegende Textstelle öffnet, ist damit noch nicht gebaut. Dafür müsste die Anwendung zusätzliche Informationen anfordern und prüfen.

Ein leeres Datum kann zwei verschiedene Folgearbeiten bedeuten

Bei T03 fehlten Zuständigkeit und Termin in den Quellen. Das Modell ließ beide Werte auf null. Hier wäre die nächste Arbeit, die fehlenden Angaben einzuholen.

Bei T02 war der Termin ebenfalls null, aber es gab zu viele Angaben: Zwei gültige Entscheidungen nannten den 10. und den 12. November. Keine hob die andere auf. Das Modell behielt beide Termine und ihre Quellen, ließ den Status jedoch auf 待办, also „zu erledigen“. Gefordert war 待确认, also „zu bestätigen“.

Abbildung 2: Zwei Fälle aus der gespeicherten ersten Antwort. Die chinesischen Originalwerte wurden nicht korrigiert; die Bildbeschriftung ist englisch. Die vorgeschlagenen nächsten Schritte sind meine Interpretation, keine ausgeführten Aktionen einer Anwendung.

Zusätzlich enthielt conflicts bei T02 ein verschachteltes Array statt des geforderten Arrays aus Zeichenketten. Die Antwort war gültiges JSON. Ein Parser konnte daher keinen Anlass sehen, die Aufgabe zurückzuhalten.

Für einen Import würde ich den Grund für eine offene Angabe erhalten: „fehlt in der Quelle“ ist eine andere Rückfrage als „zwei gültige Entscheidungen widersprechen sich“. Aus null allein lässt sich dieser Unterschied nicht ableiten. Ebenso wenig darf ein plausibler Status die widersprüchlichen Quellen überstimmen.

Den konkreten Fehler lokal sichtbar machen

Das folgende kleine JavaScript-Beispiel kann ohne API-Schlüssel und ohne Netzwerk ausgeführt werden. Es enthält nur die für die Prüfung benötigten Originalfelder von T02 aus der ersten Antwort. Speichere es als check-task.cjs und starte es mit node check-task.cjs.

const task = {
  id: "T02",
  deadline: null,
  status: "待办",
  conflicts: [["deadline", "2026-11-10", "C03", "2026-11-12", "C04"]]
};

function checkTask(task, sourceHasUnresolvedDeadline) {
  const issues = [];
  if (!Array.isArray(task.conflicts) ||
      !task.conflicts.every(value => typeof value === "string")) {
    issues.push("conflicts_type");
  }
  if (sourceHasUnresolvedDeadline) {
    if (task.deadline !== null) issues.push("deadline_must_be_null");
    if (task.status !== "待确认") issues.push("status_requires_review");
  }
  return issues;
}

// Aus dem Abgleich mit C03 und C04, nicht aus dem Modellstatus.
const sourceHasUnresolvedDeadline = true;
console.log(JSON.stringify(checkTask(task, sourceHasUnresolvedDeadline)));

Bei der lokalen Ausführung erhielt ich:

["conflicts_type","status_requires_review"]

Die entscheidende Einschränkung steckt im zweiten Argument: Dass der Termin ungelöst ist, weiß die Prüfung hier aus dem separat kontrollierten Quellenfall. Der Code entdeckt diesen Sachverhalt nicht selbst in beliebigen Dokumenten. Er prüft auch nicht das vollständige Schema und nicht die Richtigkeit aller übrigen Felder. Er macht zwei konkrete Fehler sichtbar, ohne die ursprüngliche Antwort umzuschreiben.

Auch ein korrigierter Array-Typ würde den fachlichen Widerspruch nicht beseitigen. Für eine Anwendung wäre deshalb mein nächster Schritt, Originalantwort und betroffene Quellen zusammen zur Prüfung bereitzuhalten. Eine solche Freigabeoberfläche habe ich nicht implementiert; das Beispiel ist ein lokaler Prüfbaustein, kein fertiger Importdienst.

GPT-4.1 mini über eine API ansprechen

Die gespeicherten Antworten stammen aus der OpenAI-kompatiblen Chat-Completions-Schnittstelle von Crazyrouter. Das ist eine Angabe zur Herkunft des Versuchs. Für dieselbe Schnittstelle braucht man einen passenden API-Schlüssel und einen Client, der eine eigene Basisadresse akzeptiert:

Base URL: https://api.crazyrouter.com/v1
Model: gpt-4.1-mini
API key: aus der sicheren Konfiguration der Anwendung lesen

Bei einer direkten HTTP-Anfrage geht ein POST an https://api.crazyrouter.com/v1/chat/completions, mit Bearer-Authentifizierung und einem JSON-Body. model enthält die Modell-ID, messages die Anweisungen und Dokumente. Fügt der Client den Endpunkt selbst an, reicht die Basisadresse. Zugangsdaten gehören weder in öffentliches Beispielmaterial noch in geteilte Logs.

Zum Einstieg würde ich zunächst eine kurze Notiz mit bekanntem Ergebnis senden und zuständige Person und Termin extrahieren lassen. Der Antworttext steht in choices[0].message.content. Neben dem HTTP-Ergebnis sind ein nicht leerer, vollständiger Inhalt und der Vergleich mit der Notiz wichtig. Erst danach würde ich eine Änderungsnotiz und schließlich einen ungelösten Konflikt hinzufügen.

In meinen regulären Anfragen waren temperature=0, max_tokens=6000, stream=false und response_format=json_object gesetzt. Ich habe kein strict JSON Schema übergeben. Die geforderten Typen und Regeln standen im Prompt. Der Array-Fehler ist daher kein Test der Schemaerzwingung. Die Einstellungen dokumentieren diesen Versuch und sind keine allgemeine Empfehlung für alle Anwendungen.

Das Prüfmaterial ist auch nach einem Modellwechsel nützlich

Vor den Anfragen legte ich die erwarteten Ergebnisse fest. Anschließend verglich ein lokales Programm Felder, Quellen und Struktur; zusätzlich prüfte ich die Quellen erneut. In jedem der zwei regulären Durchläufe stimmten 47 von 48 Kernfeldern, zwölf von zwölf Aufgaben bestanden die Quellenprüfung und elf von zwölf die Strukturprüfung. Beide Antworten verfehlten wegen T02 die vollständigen Anforderungen.

Ein vorausgehender Probelauf mit drei Aufgaben zeigte dieselbe Art von Problem. Insgesamt waren es drei Generierungsanfragen, keine Reparaturanfrage und keine manuelle Korrektur der Antworten. Jeder reguläre Aufruf hatte 26.430 Eingabetokens. Zwei Wiederholungen derselben zwölf Aufgaben sind keine 24 unabhängigen Aufgaben. Bilder, Tool-Ausführung, das maximale Kontextfenster und deutschsprachige Eingaben wurden nicht getestet.

Die Gültigkeit von Änderungen war ein weiterer Teil des Auftrags: T06 sollte erst ab dem 2. November einen neuen Stand erhalten. Beide Antworten behielten zum früheren Stichtag die alte Zuständigkeit und die Anforderung „die ersten 20 Ergebnisse“, statt die spätere Vorgabe von 50 Ergebnissen vorzeitig anzuwenden. Solche Fälle würde ich zusammen mit fehlenden Angaben und Konflikten in einem kleinen Testsatz aufbewahren.

Zur Planung gehört schließlich die Verfügbarkeit. OpenAI kündigte am 14. Oktober 2026 an, gpt-4.1-mini-2025-04-14 am 14. Januar 2027 aus der OpenAI-API zu entfernen. Der erfolgreiche Aufruf über Crazyrouter bestätigt keinen zukünftigen Bereitstellungszeitraum dieses Dienstes. Vor einem eigenen Versuch sind die aktuellen Bedingungen und die Verfügbarkeit des jeweiligen Zugangs zu prüfen.

Aus diesem Versuch würde ich vor allem den Datenvertrag mitnehmen: Welche Änderungen gelten, welche Werte müssen erhalten bleiben und welche Entscheidungen darf der Import noch nicht übernehmen? Die gespeicherten Quellen und erwarteten Ergebnisse helfen, diese Fragen auch beim nächsten Modell zu stellen. Ein neuer Modellname ersetzt die Antworten darauf nicht.