Anmerkung des Autors: Am Beispiel von Proses öffentlich vorgestelltem Ansatz „KI ist Redakteurin, keine Ghostwriterin“ beleuchtet dieser Artikel das vollständige Design für KI-gestützte Textüberarbeitungen: von der Verortung und Anzeige einzelner Änderungen über deren Annahme bis hin zu Rücknahme und menschlicher Bestätigung.
Bitten Sie eine KI, einen Text zu überarbeiten, schreibt sie oft gleich den ganzen Absatz neu. Das Ergebnis liest sich zwar flüssiger, aber welche Sätze entfernt wurden, ob die Verweisnummern noch stimmen und ob wichtige Daten verändert wurden, müssen Nutzer selbst Wort für Wort prüfen. Dieser Artikel stellt ein Interaktions- und Engineering-Konzept für die Prüfung und Rücknahme einzelner KI-Textänderungen vor, das sich direkt für einen Prototyp nutzen lässt.
Dies ist kein weiterer Einführungsartikel nach dem Motto „Ein großes Sprachmodell anschließen und fertig ist das Schreibtool“. Wir betrachten aus Sicht des Produktdesigns und der technischen Umsetzung, warum der Austausch ganzer Absätze beim professionellen Schreiben nicht ausreicht und welche konkreten Probleme die Prüfung einzelner Änderungen lösen muss.
Das nehmen Sie mit: Ein Konzept für die Gestaltung KI-gestützter Textüberarbeitung – von der Verortung und Anzeige von Änderungen über das Annehmen oder Ablehnen einzelner Vorschläge bis hin zur Rücknahme und den Grenzen menschlicher Bestätigung. Dazu gibt es eine Checkliste für die Umsetzung.
Die wichtigsten Prinzipien für die Prüfung einzelner KI-Änderungen
Bevor wir mit dem Design beginnen, lohnt sich ein Blick auf ein öffentliches Beispiel. Ein Entwickler stellte auf V2EX sein Desktop-Schreibprogramm Prose für längere Texte vor. Die Designprinzipien formuliert er klar: „Die KI ist Lektorin, keine Ghostwriterin“ und „Nur was sich überprüfen lässt, zählt“. Das erste Prinzip bedeutet: Die KI überarbeitet den Text, aber jede Änderung braucht die Zustimmung des Nutzers. Das zweite bedeutet: Änderungen müssen als Diff sichtbar sein, und Literaturquellen müssen sich im Original öffnen lassen.
Die Überarbeitungsfunktion beschreibt er so: Die KI ändert die Datei direkt im Editor. Jede Änderung wird einzeln markiert, sodass Nutzer sie annehmen oder ablehnen können. Eine versehentlich angenommene Änderung lässt sich zurücksetzen. Bevor die KI loslegt, sucht sie den relevanten Abschnitt und ändert nur die betroffenen Sätze. Sie schreibt also nicht ein ganzes Kapitel um, nur um ein Wort auszutauschen. Die konkrete technische Umsetzung von Prose wurde allerdings nicht veröffentlicht. Der folgende allgemeine Designrahmen leitet sich aus diesen öffentlich beschriebenen Prinzipien ab und ist keine Rekonstruktion der internen Implementierung.
| Prinzip | Beschreibung | Nutzen für Nutzer |
|---|---|---|
| Erst lokalisieren, dann ändern | Das Modell findet zunächst die betroffenen Abschnitte und Sätze und erstellt dann die Änderungen | Ein einzelnes Wort führt nicht dazu, dass ein ganzes Kapitel neu geschrieben wird |
| Änderungen als unabhängige Einheiten | Jede Änderung ist ein strukturiertes Objekt mit eigener ID | Änderungen lassen sich einzeln prüfen, statt alles auf einmal annehmen zu müssen |
| Unterschiede visualisieren | Ein Diff auf Wort- oder Satzebene zeigt Original und überarbeitete Fassung | Auf einen Blick ist sichtbar, was gelöscht und was hinzugefügt wurde |
| Einzeln annehmen oder ablehnen | Über jede Änderungseinheit wird unabhängig entschieden | Nutzer behalten die Kontrolle über das Ergebnis |
| Zurücksetzen ermöglichen | Ein Aktionsprotokoll wird mit Versions-Snapshots kombiniert | Auch versehentlich angenommene Änderungen lassen sich rückgängig machen |
| Grenzen für die menschliche Bestätigung | Schreibzugriffe auf externe Bibliotheken und Massenänderungen müssen bestätigt werden | Die KI kann Nutzerdaten nicht eigenmächtig ändern |
Warum KI-Überarbeitungen nicht ganze Abschnitte ersetzen sollten
Das Problem beim Ersetzen ganzer Abschnitte ist nicht, dass das Modell schlecht schreibt. Vielmehr wird der gesamte Prüfaufwand auf die Nutzer abgewälzt. Wenn der Originaltext 300 Zeichen und die neue Fassung 320 Zeichen umfasst, müssen sie im Kopf einen vollständigen Diff durchführen, um zu erkennen, ob ein wichtiges Argument verloren gegangen ist. Bei Fachtexten wie wissenschaftlichen Arbeiten, Berichten oder Verträgen kann schon eine unbemerkt entfernte Einschränkung oder eine falsch geänderte Quellenangabe wie [3] erhebliche Folgen haben.
Auch das Referenzmaterial beschreibt die aktuelle Situation: Webbasierte Chat-Tools liefern einen neuen Text, den die Nutzer mit dem Original von Hand vergleichen müssen. Viele in Dokumente integrierte KI-Funktionen ersetzen die Auswahl als Ganzes; eine Prüfung einzelner Änderungen ist nur selten möglich. Genau diese Lücke schließt die Prüfung einzelner Änderungen: Aus „Ich muss darauf vertrauen, dass die KI richtig überarbeitet hat“ wird „Ich kann nachvollziehen, was die KI geändert hat“.
Das Vertrauensmodell hinter der Prüfung einzelner Änderungen
Im Kern verteilt die Prüfung einzelner Änderungen die Aufgaben zwischen Mensch und Modell neu. Das Modell findet Probleme und macht Vorschläge, die Nutzer treffen die endgültige Entscheidung. Das System dokumentiert jede Entscheidung und stellt sicher, dass sie rückgängig gemacht werden kann. So ähnelt die KI eher einem Lektor, der Anmerkungen macht, als einem Ghostwriter, der direkt einen fertigen Text abliefert.
Steht dieses Vertrauensmodell erst einmal fest, lassen sich viele Designentscheidungen leichter treffen. Auf die Frage, ob standardmäßig alle Änderungen angenommen werden sollen, lautet die Antwort beispielsweise klar: Der Standardstatus sollte „Zur Prüfung“ sein, nicht „Übernommen“.
Schnellstart: KI-gestützte Textüberarbeitungen prüfbar gestalten
Im Folgenden zerlegen wir eine prüfbare und rückgängig zu machende KI-Überarbeitung in sechs Schritte – in der Reihenfolge, in der sie tatsächlich entwickelt werden. Damit sich das Konzept mit unterschiedlichen Technologie-Stacks umsetzen lässt, verwenden wir statt konkretem Code Felddefinitionen und Prüfpunkte.
Schritt 1: Den Änderungsbereich für die KI-Überarbeitung bestimmen
Im ersten Schritt soll das Modell noch nichts ändern, sondern zunächst die relevanten Stellen finden. Sagt ein Nutzer etwa: „Gestalte die Argumentation im dritten Kapitel stringenter“, soll das Modell zuerst ausgeben, welche Absätze überarbeitet werden müssen. Bei Bedarf bestätigt der Nutzer diesen Bereich, bevor die eigentliche Überarbeitung beginnt. Das hat zwei Vorteile: Der Kontext wird kleiner und das Modell ändert seltener irrelevante Inhalte. Ausserdem kann der Nutzer frühzeitig eingreifen, falls die Überarbeitung in die falsche Richtung geht.
Bei längeren Texten lässt sich das Dokument zunächst anhand seiner Überschriften in einen Kapitelindex aufteilen. Das Modell gibt dann auf Basis des Index und der Nutzeranweisung eine Liste mit den IDs der betreffenden Absätze zurück. Für die anschliessende Überarbeitung werden nur die Originaltexte dieser Absätze übergeben.
Schritt 2: KI-Überarbeitungen als strukturierte Änderungen ausgeben
Das ist der technische Kern des gesamten Ansatzes. Das Modell soll nicht den vollständig überarbeiteten Text zurückgeben, sondern eine Liste von Änderungen. Jeder Eintrag steht für eine eigenständige Änderung. Folgende Felder bieten sich an:
| Feld | Bedeutung | Hinweise zur Gestaltung |
|---|---|---|
id |
Eindeutige Kennung der Änderung | Wird vom System erzeugt und erleichtert die Prüfung und Nachverfolgung bei einer Rücknahme |
anchor_text |
Zu ersetzender Originaltext | Muss wortwörtlich im Original vorkommen |
context_before / context_after |
Kurzer Text vor und nach dem Anker | Hilft bei der Zuordnung, wenn der Textausschnitt mehrfach vorkommt |
replacement |
Neuer Text | Ein leerer Wert bedeutet, dass der Text gelöscht wird |
reason |
Grund für die Änderung | Ein Satz, der dem Nutzer angezeigt wird |
category |
Art der Änderung | Zum Beispiel Grammatik, Formulierung, Logik oder Fakten; dient zum Filtern |
Eine wichtige Entscheidung: Als Anker dient ein „Zitat aus dem Originaltext“ statt eines „Zeichenoffsets“. Modelle berechnen Zeichenpositionen nicht zuverlässig, während sie einen Originalausschnitt deutlich zuverlässiger wiedergeben können. Nach Erhalt von anchor_text sucht das System im Original nach einer exakten Übereinstimmung. Gibt es keinen Treffer, hat das Modell den Text fehlerhaft wiedergegeben. Bei mehreren Treffern hilft der Kontext bei der Zuordnung.
Schritt drei: Ankerprüfung und Fallback bei fehlgeschlagener KI-Überarbeitung
Änderungen aus der Modellausgabe sollten nicht ungeprüft angezeigt werden. Prüfen Sie mindestens folgende Punkte:
- Eindeutigkeit des Ankers:
anchor_textdarf zusammen mit seinem Kontext nur einmal im Originaltext vorkommen. Andernfalls die Änderung als „Manuelle Zuordnung erforderlich“ markieren. - Keine Überlappungen: Die Ankerbereiche zweier Änderungen dürfen sich nicht überschneiden. Falls doch, die Änderungen zusammenführen oder die zweite verwerfen.
- Geschützte Inhalte: Wenn Quellenverweise wie
[1], Zahlen, Eigennamen oder Formeln bei einer Ersetzung verschwinden oder verändert werden, sollte eine zusätzliche, deutlich hervorgehobene Warnung erscheinen. - Umfang der Änderung: Wenn bei einer einzelnen Änderung ein zu großer Anteil ersetzt wird, sollte der Hinweis „Diese Stelle kommt einer Neufassung nahe“ die Aufmerksamkeit darauf lenken.
Änderungen, die die Prüfung nicht bestehen, müssen nicht sofort verworfen werden. Stattdessen können sie als „Vorschlag“-Karten in der Seitenleiste erscheinen, damit Nutzer sie manuell bearbeiten können. Das entspricht dem Grundsatz „Nur was sich überprüfen lässt, zählt“ besser, als Fehler stillschweigend zu verschlucken.
Schritt vier: Unterschiede bei der KI-Überarbeitung darstellen
Die Darstellung der Unterschiede bestimmt, wie effizient die Prüfung abläuft. Üblich sind drei Varianten: durchgestrichene und hervorgehobene Stellen direkt im Text, ein Vergleich in zwei Spalten und Kommentarkarten in der Seitenleiste. Für sprachliche Verbesserungen auf Satzebene ist ein wortweiser Diff direkt im Text am intuitivsten. Bei Änderungen an der Absatzstruktur ist der Vergleich in zwei Spalten übersichtlicher; für logische Änderungen, die eine Begründung erfordern, eignen sich Kommentarkarten besser.
Praktisch ist es, Änderungen vor allem direkt im Text anzuzeigen und neben jeder Änderung ein kleines Label zu platzieren, das beim Darüberfahren mit der Maus den Inhalt von reason einblendet. Filter wie „Nur sachliche Änderungen“ und „Nur Änderungen an der Formulierung“ helfen dabei, die Prüfung nach Priorität vorzunehmen.
Schritt fünf: Änderungen einzeln annehmen, ablehnen und KI-Überarbeitungen rückgängig machen
Jede Änderung sollte einen von drei Status haben: ausstehend, angenommen oder abgelehnt. Sowohl das Annehmen als auch das Ablehnen wird im Aktionsprotokoll festgehalten – mit Änderungs-ID, Zeitpunkt und dem Text vor und nach der Aktion. Für ein Rollback werden die protokollierten Aktionen in umgekehrter Reihenfolge ausgeführt. So lassen sich einzelne Änderungen rückgängig machen oder ein vollständiger Snapshot von vor einer KI-Überarbeitung wiederherstellen.
Dabei gibt es einen leicht zu übersehenden Fall: Der Nutzer bearbeitet das Dokument während der Prüfung selbst. Dadurch können die Anker noch nicht geprüfter Änderungen ungültig werden. Das System muss sie erneut prüfen und betroffene Änderungen mit „Originaltext hat sich geändert“ kennzeichnen, statt sie trotzdem anzuwenden.
Schritt sechs: Wann KI-Überarbeitungen eine Bestätigung brauchen
Nicht jede Aktion braucht eine gleich strenge Bestätigung. Das Vorgehen von Prose bietet hier eine Orientierung: Neu gefundene Literatur wird erst nach Zustimmung des Nutzers in Zotero gespeichert. Änderungen an Notizen nach der Verknüpfung mit Obsidian werden ebenfalls anhand eines Diffs einzeln bestätigt. Daraus ergibt sich eine klare Grenze: Sobald eine Aktion bestehende Inhalte des Nutzers verändert, braucht sie eine ausdrückliche Bestätigung.
Die Aktionen lassen sich nach Risiko abstufen: Änderungen an einzelnen Sätzen im Editor können einzeln geprüft werden. Bei umfangreichen Änderungen über mehrere Kapitel hinweg muss zunächst der Umfang bestätigt werden. Für das Schreiben in externe Literatur- oder Notizsammlungen braucht es einen eigenen Bestätigungsdialog. Das Löschen ganzer Absätze erfordert eine zweite Bestätigung.
🚀 Tipp für den Prototyp: Wenn Sie prüfen möchten, ob eine „strukturierte Änderungsliste“ für Ihren Anwendungsfall funktioniert, können Sie auf APIYI apiyi.com zunächst einen minimalen Prototyp mit einer OpenAI-kompatiblen Schnittstelle für Chat-Vervollständigungen erstellen. Die Plattform unterstützt den einheitlichen Aufruf verschiedener Modelle. So können Sie mit derselben Eingabeaufforderung und Validierungslogik schnell zwischen Modellen wechseln und vergleichen, wie genau sie die Anker ausgeben. Die genauen Schnittstellenadressen und Parameter finden Sie in der Dokumentation von APIYI.
Vergleich der Interaktionsmodelle für KI-Textüberarbeitungen
| Ansatz | Kernmerkmal | Einsatzszenarien | Wichtigster Nachteil |
|---|---|---|---|
| Vollständiges Ersetzen | Der markierte Abschnitt wird direkt durch neuen Text ersetzt | Entwurfsphase, kurze Texte, Inhalte mit geringem Risiko | Der gesamte Prüfaufwand liegt bei den Nutzenden |
| Vorschlagskarten | Verbesserungsvorschläge stehen in einer Seitenleiste und werden manuell übernommen | Logische oder strukturelle Vorschläge, die eine Begründung erfordern | Nutzende müssen die Änderungen selbst vornehmen; das ist weniger effizient |
| Prüfung einzelner Diffs | Jede Änderung wird separat hervorgehoben und einzeln angenommen oder abgelehnt | Wissenschaftliche Arbeiten, Berichte, Buchmanuskripte und andere professionelle Langtexte | Erfordert strukturierte Ausgaben, Ankerprüfung und Protokollierung |
| Hybridmodus | Änderungen auf Satzebene laufen über Diffs, Strukturvorschläge über Karten | Die meisten ausgereiften Schreibprodukte | Interaktionsdesign und Zustandsverwaltung sind komplexer |
Vergleich der Ansätze zur KI-gestützten Textüberarbeitung
Absatzweise ersetzen: Dieser Ansatz ist beim Implementierungsaufwand im Vorteil und erfordert kaum zusätzliche Entwicklungsarbeit. Die Kontrolle liegt jedoch vollständig bei den Nutzern. Gerade bei Fachtexten können so gestrichene Einschränkungen oder Quellenangaben leicht übersehen werden. Für Texte, die an Auftraggeber geliefert werden, eignet sich die Prüfung einzelner Änderungen per Diff besser.
Vorschlagskarten: Karten bieten Platz für Erklärungen und eignen sich für Probleme, die sich nicht durch eine einzelne Ersetzung lösen lassen – etwa wenn ein Argument in einem Absatz nicht trägt. Sie ändern den Text jedoch nicht direkt; die Nutzer müssen selbst formulieren. Geht es hauptsächlich um Formulierungen und Grammatik, ist die Prüfung einzelner Änderungen per Diff weiterhin die zuverlässigere Wahl.
In der Praxis ist eine Kombination oft am sinnvollsten. Der von Prose öffentlich vorgestellte Assistent „小 P 同学“ stellt jeweils nur eine Frage und hakt aus der Perspektive eines Mentors oder Gutachters bei Forschungsfrage und Argumentation nach. Solche Hinweise eignen sich gut für Karten; die Überarbeitung einzelner Sätze lässt sich dagegen per Diff prüfen.
Bewertungskriterien für Modelle bei der KI-gestützten Textüberarbeitung
Die Prüfung einzelner Änderungen hängt stark davon ab, wie zuverlässig sich ein Modell an Vorgaben hält. Öffentlich zugängliche Daten etwa zur Genauigkeit der Änderungen oder zur Akzeptanz durch Nutzer fehlen derzeit. Deshalb verzichten wir auf eine konkrete Rangliste und nennen stattdessen Kriterien, die in der Prototypphase praktisch getestet werden sollten:
| Bewertungskriterium | Was wird gemessen? | Warum ist es wichtig? | Testplattform |
|---|---|---|---|
| Genauigkeit des Ankertexts | Lässt sich anchor_text exakt im Originaltext finden? |
Entscheidet darüber, ob Änderungen angewendet werden können | Modellwechsel über APIYI apiyi.com |
| Stabilität der strukturierten Ausgabe | Wird zuverlässig eine gültige Änderungsliste zurückgegeben? | Bestimmt die Häufigkeit von Parsing-Fehlern | Unterstützung anhand der offiziellen Dokumentation prüfen |
| Zurückhaltung bei Änderungen | Werden nur die nötigen Stellen geändert? | Bestimmt den Prüfaufwand | Vergleich anhand eines festen Testdatensatzes |
| Erhalt geschützter Inhalte | Werden Quellenangaben und Zahlen versehentlich geändert? | Entscheidet über die fachliche Glaubwürdigkeit | Testabsätze mit Quellenangaben erstellen |
| Qualität der Begründungen | Ist reason konkret und verständlich? |
Bestimmt, wie schnell Nutzer die Änderungen prüfen können | Manuelle Stichprobenbewertung |
💡 Empfehlung zur Auswahl: Die Unterstützung für strukturierte Ausgaben, Tool-Aufrufe und andere Funktionen unterscheidet sich je nach Modell. Orientieren Sie sich an der jeweiligen offiziellen Dokumentation und eigenen Tests. Über die einheitliche Schnittstelle von APIYI können Sie dieselben Testabsätze mit mehreren Modellen vergleichen. Halten Sie dabei fest, wie oft die Ankertextsuche fehlschlägt und geschützte Inhalte versehentlich geändert werden. Entscheiden Sie dann, welches Modell Sie hauptsächlich einsetzen möchten.
Checkliste für KI-gestützte Textüberarbeitung
Die sechs Schritte von oben lassen sich zu einer Checkliste zusammenfassen, die Sie vor dem Livegang Punkt für Punkt durchgehen können:
| Schritt | Prüfpunkt | Erfolgskriterium |
|---|---|---|
| Bereich festlegen | Wird vor dem Umschreiben der Zielabschnitt bestimmt? | Für Nutzer sichtbar und korrigierbar |
| Strukturierte Ausgabe | Werden Änderungen als Liste zurückgegeben? | Jeder Eintrag enthält Anker, Ersatztext und Begründung |
| Anker prüfen | Werden Eindeutigkeit und Überschneidungen geprüft? | Fehlgeschlagene Änderungen werden als Vorschläge angezeigt, nicht stillschweigend verworfen |
| Geschützte Inhalte | Werden Zitate, Zahlen und Formeln überwacht? | Bei Änderungen erscheint eine deutliche Warnung |
| Unterschiede anzeigen | Werden Diffs auf Wort- oder Satzebene unterstützt? | Löschungen und Ergänzungen sind erkennbar |
| Prüfung | Lassen sich Änderungen einzeln annehmen oder ablehnen? | Sammelaktionen sind verfügbar, aber nicht voreingestellt |
| Rückgängig machen | Gibt es ein Aktionsprotokoll und Snapshots? | Einzelne Änderungen und der gesamte Vorgang lassen sich zurücksetzen |
| Gleichzeitige Bearbeitung | Werden manuelle Änderungen während der Prüfung berücksichtigt? | Ungültig gewordene Änderungen werden erneut geprüft |
| Bestätigungsgrenze | Wird das Schreiben in einen externen Datenbestand separat bestätigt? | Vor der Bestätigung wird nichts gespeichert |
Am ehesten werden die Punkte „Gleichzeitige Bearbeitung“ und „Geschützte Inhalte“ gestrichen, weil sie bei Demos selten auffallen. Im Alltag überarbeiten Nutzer Texte jedoch häufig von Hand, während sie Änderungsvorschläge prüfen. Ebenso kommt es vor, dass ein Modell nebenbei Zitiernummern verändert. Deshalb sollten beide Punkte schon in der Prototypenphase berücksichtigt werden.
🎯 Technischer Tipp: Stellen Sie für die Validierung des Prototyps einen anspruchsvollen Testsatz mit Zitiernummern, Zahlen und wiederholten Sätzen zusammen. Rufen Sie über APIYI apiyi.com nacheinander mehrere geeignete Modelle auf und prüfen Sie sie anhand der Checkliste. So erkennen Sie schon vor der Entwicklung des eigentlichen Frontends, wie zuverlässig die Modelle einzelne Textstellen überarbeiten und wo ihre Grenzen liegen.
Häufige Fragen zur KI-gestützten Textüberarbeitung
Q1: Was bedeutet die Prüfung einzelner Änderungen bei der KI-gestützten Textüberarbeitung?
Bei der Einzelprüfung ersetzt die KI nicht den gesamten Textabschnitt, sondern zerlegt die Überarbeitung in unabhängige Änderungen. Jeder Unterschied wird einzeln markiert, sodass Nutzer ihn annehmen oder ablehnen und später rückgängig machen können. Entscheidend ist, dass jede Änderung überprüfbar und widerrufbar bleibt.
Q2: Wie unterscheidet sich die Einzelprüfung vom Ersetzen ganzer Textabschnitte?
Das Ersetzen ganzer Abschnitte ist technisch am einfachsten umzusetzen. Nutzer können die Änderungen aber nur insgesamt annehmen oder verwerfen und müssen sie von Hand vergleichen. Die Einzelprüfung erfordert eine strukturierte Ausgabe und die Validierung von Ankern und ist daher aufwendiger. Dafür ermöglicht sie eine genaue Kontrolle jeder Änderung und eignet sich besonders für Texte wie wissenschaftliche Arbeiten und Berichte.
Q3: Warum werden Änderungen anhand von Originaltext statt anhand von Zeichenpositionen lokalisiert?
Große Sprachmodelle berechnen Zeichen-Offsets nicht zuverlässig. Schon kleine Abweichungen können dazu führen, dass die falsche Stelle geändert wird. Stabiler ist es, einen Abschnitt des Originaltexts wiederzugeben und diesen anschließend programmatisch exakt abzugleichen. Mithilfe des umgebenden Kontexts lassen sich auch wiederkehrende Textstellen unterscheiden. Schlägt der Abgleich fehl, ist das leicht erkennbar und die Stelle kann manuell bearbeitet werden.
Q4: Für welche Anwendungsfälle eignet sich die Einzelprüfung besonders?
Sie eignet sich vor allem für folgende Szenarien:
– **Wissenschaftliches Schreiben**: Beim sprachlichen Überarbeiten von Arbeiten müssen Quellenangaben und Daten unverändert bleiben
– **Geschäftsberichte**: Kleine Änderungen an der Formulierung von Schlussfolgerungen können deren Bedeutung beeinflussen und müssen Satz für Satz geprüft werden
– **Buchmanuskripte und Romane**: Autoren möchten ihren persönlichen Stil bewahren und nur ausgewählte Vorschläge übernehmen
– **Pflege von Notizsammlungen**: Wenn eine KI eine persönliche Wissensdatenbank liest und bearbeitet, muss jede Änderung bestätigt werden
Q5: Wie lässt sich schnell ein Prototyp für die KI-gestützte Textüberarbeitung erstellen, um den Ansatz zu testen?
Für einen ersten einfachen Test empfiehlt sich eine Schnittstellenplattform, die mehrere Modelle unterstützt:
1. Bei APIYI auf apiyi.com registrieren und einen API-Schlüssel abrufen
2. Anhand der Schnittstellenbeschreibung im Dokumentationszentrum eine Anfrage über die mit dem OpenAI-Format kompatible Chat-Completion-Schnittstelle stellen
3. Das Modell die Änderungsliste anhand der in diesem Artikel beschriebenen Felder zurückgeben lassen und anschließend die Anker programmatisch validieren
Da APIYI den einheitlichen Aufruf verschiedener gängiger Modelle unterstützt, lässt sich mit demselben Prototyp schnell zwischen Modellen wechseln und deren Leistung vergleichen. Wie gut die einzelnen Modelle strukturierte Ausgaben unterstützen, zeigen die offizielle Dokumentation und praktische Tests.
Q6: Was passiert, wenn Nutzer das Dokument während der Prüfung manuell ändern?
Dann können die Anker noch nicht geprüfter Änderungen ungültig sein. Das System sollte alle ausstehenden Einträge erneut anhand ihrer Anker validieren. Einträge, die weiterhin übereinstimmen, bleiben erhalten. Bei fehlgeschlagenem Abgleich werden sie als „Originaltext wurde geändert“ markiert. Nutzer können dann entscheiden, ob sie die Änderung neu generieren lassen möchten, statt die alte Änderung zwangsweise anzuwenden.
Q7: Wie lassen sich die Testkosten beim Vergleich mehrerer Modelle begrenzen?
Beginnen Sie am besten mit einem kleinen, aber anspruchsvollen festen Testdatensatz, etwa einem Dutzend Textabschnitten mit Quellenangaben, Zahlen und wiederholten Sätzen. So müssen Sie nicht gleich einen kompletten langen Text testen. Rufen Sie mehrere Modelle gesammelt über die einheitliche Schnittstelle von APIYI auf und erfassen Sie nur wichtige Kennzahlen wie die Trefferquote beim Ankerabgleich und die Anzahl fehlerhafter Änderungen. So lassen sich geeignete Modelle zu überschaubaren Kosten auswählen.
Q8: Welche bekannten Einschränkungen hat die Prüfung einzelner KI-Überarbeitungsvorschläge?
Es gibt einige Einschränkungen: Erstens muss das Modell zuverlässig strukturierte Ergebnisse liefern; falls das Parsing fehlschlägt, braucht es einen Fallback. Zweitens eignet sich der Ansatz weniger für umfangreiche strukturelle Umstellungen – solche Änderungen sind auf Vorschlagskarten besser aufgehoben. Drittens fehlen derzeit öffentliche Daten zu Akzeptanzrate und Genauigkeit. Wie gut der Ansatz funktioniert, muss daher am eigenen Prototyp überprüft werden. Der Autor von Prose räumt ebenfalls ein, dass etwa der Hin- und Rückweg über das Word-Format noch nicht immer reibungslos funktioniert. Das zeigt, wie viele technische Herausforderungen die gesamte Schreibkette noch mit sich bringt.
Überprüfbare KI-Überarbeitungen gestalten: Die wichtigsten Punkte
- Grundprinzip: Eine KI-Überarbeitung sollte aus einzeln überprüfbaren Änderungsvorschlägen bestehen, statt ganze Absätze stellvertretend neu zu schreiben
- Erst finden, dann ändern: Vor der Bearbeitung Kapitel und Absätze lokalisieren, um den Änderungsbereich und den benötigten Kontext einzugrenzen
- Änderungen strukturieren: Jede Änderung als eigenständige Einheit aus Anker im Originaltext, Ersatztext und Begründung erfassen
- Prüfung ist Pflicht: Eindeutigkeit der Anker, überlappende Änderungen und geschützte Inhalte vor der Anzeige prüfen
- Änderungen müssen umkehrbar sein: Ein Operationsprotokoll und Snapshots ermöglichen es, einzelne Änderungen rückgängig zu machen oder den gesamten Stand zurückzusetzen
- Bestätigungen abstufen: Schreibzugriffe auf externe Literatur- oder Notizsammlungen müssen separat bestätigt werden
- Prototyp testen: Über die einheitliche Schnittstelle für mehrere Modelle von APIYI lässt sich praktisch prüfen, wie zuverlässig verschiedene Modelle lokale Textstellen umformulieren
Zusammenfassung
Die wichtigsten Punkte für ein gutes Erlebnis beim Überarbeiten mit KI:
- Vertrauensmodell: Die KI schlägt Änderungen vor, die Nutzer entscheiden, und das System dokumentiert sie und macht sie rückgängig
- Technische Grundlage: Eine strukturierte Änderungsliste und die Prüfung von Ankerstellen im Originaltext sind die Voraussetzung dafür, Änderungen einzeln prüfen zu können
- Interaktionsdesign: Für Formulierungen auf Satzebene eignet sich ein Diff, für strukturelle Probleme eignen sich Vorschlagskarten. Eine Kombination ist am praktischsten
- Grenzen der Bestätigung: Je direkter ein Schreibzugriff bestehende Inhalte der Nutzer verändert, desto ausdrücklicher sollte die Bestätigung ausfallen
Die von Prose formulierten Grundsätze „KI ist Redakteur, kein Ghostwriter“ und „Nur was sich überprüfen lässt, zählt“ zeigen eine klare Richtung für KI-Schreibprodukte: Die Kontrolle der Nutzer steht im Mittelpunkt des Designs, nicht die Generierung per Knopfdruck. Als nächsten Schritt empfiehlt es sich, anhand der Checkliste in diesem Artikel einen minimalen Prototyp zu bauen und die Grenzen des Modells mit echten Texten auszuloten.
Für den Prototyp empfiehlt sich APIYI unter apiyi.com. So kannst du zwischen verschiedenen Modellen wechseln und sie vergleichen, um mit demselben Testdatensatz die beste Lösung für gezielte Textüberarbeitungen zu finden.
📚 Quellen
- V2EX – Prose: Ein besonders einfach zu bedienender und professioneller KI-Agent für lange Texte, den ich für meine Freundin entwickelt habe: Die vom Prose-Entwickler veröffentlichten Designprinzipien und Funktionsbeschreibungen
- Link:
v2ex.com/t/1254240 -
Beschreibung: Enthält vier Designprinzipien, darunter „KI ist Redakteur, kein Ghostwriter“, sowie Beschreibungen von Funktionen wie der Textüberarbeitung per Diff, Literaturrecherche und Anbindung an Zotero und Obsidian
-
Offizielle Prose-Website: Desktop-Tool für das Schreiben langer Texte mit KI
- Link:
prose-ai.cn - Beschreibung: Hier lässt sich die Textüberarbeitung mit Prüfung jeder einzelnen Änderung selbst ausprobieren – als Anregung für das Produktdesign
Autor: APIYI Technikteam
Technischer Austausch: Kontaktiere uns gerne über die Startseite von APIYI. Weitere Informationen zu den Schnittstellen findest du im Dokumentationszentrum unter docs.apiyi.com.
