NovelForge: Karten, JSON Schema und ein DSL für Langromane

Das Problem: ein Roman passt nicht in ein Kontextfenster

Wer mehr als ein paar Kapitel mit einem Sprachmodell schreibt, kennt drei Ausfälle. Figuren vergessen ihre eigenen Entscheidungen. Ein Modell liefert Prosa, die sich nicht in das bestehende Datenmodell einsortieren lässt. Und nach hundert Seiten weiß niemand mehr, welche Nebenfigur in welchem Kapitel gestorben ist. NovelForge setzt genau dort an. Das README formuliert die Ausgangslage so: Konsistenz halten, Kontrolle behalten, Inspiration aufrechterhalten. Adressat sind Schreibende mit langem Atem, nicht jemand, der eine Kurzgeschichte generieren will. Die Einheit der Arbeit ist die Karte, nicht das Dokument. Eine Karte ist ein typisierter Datensatz, etwa eine Figur, ein Schauplatz, ein Gegenstand oder ein Konzept. Jede Karte hat ein Schema. Das ist die eigentliche Design-Entscheidung des Projekts: Nicht der Text ist die primäre Struktur, sondern das Modell dahinter.

Schema-first: warum Validierung vor Generierung kommt

Das README beschreibt das Kernprinzip als Schema-getriebene Kartenproduktion. Jeder Kartentyp bekommt eine Struktur, und die KI-Ausgabe wird gegen diese Struktur geprüft. Der Nutzen liegt auf der Hand: Ein Modell, das eine Figur beschreiben soll, kann nicht plötzlich in einen freien Fließtext ausweichen, weil das Schema die Felder vorgibt. Der Preis ist weniger offensichtlich. Wer ein Schema zu eng definiert, verliert genau die Assoziationen, die beim Schreiben nützlich sind. NovelForge erlaubt deshalb, pro Karte ein eigenes Schema zu hinterlegen, was Flexibilität zurückgibt, aber auch bedeutet, dass die Qualität der Ausgabe von der Qualität des Schemas abhängt. Das Projekt validiert gegen das Schema, es entwirft es nicht für dich. Die Topics des Repositories nennen pydantic und json-schema, was nahelegt, dass die Validierung über diese Bibliotheken läuft. Das README selbst nennt die konkreten Felddefinitionen nicht, deshalb lässt sich über die genaue Schema-Syntax aus dem vorliegenden Material nichts sagen.

Der Generierungsfluss: Feld für Feld statt Block für Block

Seit Version 0.9.0 ist der Ablauf nicht mehr ein einziger Aufruf, der eine ganze Karte zurückgibt. Die Release Notes beschreiben den neuen Weg als Eingabe der Anforderung, dann feldgranulares Auffüllen im Dialog, dann Bestätigung oder Nachsteuern. Die Generierung gilt dabei ausdrücklich nur für die aktuell geöffnete Karte; sobald der Dialog geschlossen wird, endet die Sitzung. Das ist eine bewusste Einschränkung: Es gibt keinen projektweiten Batch-Lauf, der über Nacht alle Figuren neu erzeugt. Der Vorteil ist Korrigierbarkeit. Wenn Feld drei falsch ist, muss man nicht die ganze Karte verwerfen. Der Nachteil ist Interaktionslast. Bei einem Schema mit zwanzig Feldern und hundert Karten ist das viele Klicks. Für Kapiteltexte existiert daneben eine eigene Wortzahlsteuerung mit zwei Modi. Der Modus 提示词约束 arbeitet nur über den Prompt, ist laut README natürlicher und billiger. Der Modus 控制模式 teilt das Ziel in mehrere Runden mit Budget auf, kontrolliert die Länge stabiler, verbraucht aber mehr Token. Das ist ein ehrlicher Trade-off und keine Marketingentscheidung.

@DSL: Kontext wird referenziert, nicht eingeklebt

Der zweite Mechanismus ist die Kontextinjektion über eine @DSL. Statt relevante Passagen manuell in den Prompt zu kopieren, referenziert man Projektdaten über eine Kurzsyntax, und das System setzt sie zusammen. Das README nennt als Zweck ausdrücklich, spätere Generierungen näher an bereits Geschriebenem und an Figurenbeziehungen zu halten. Dazu kommt ein Wissensgraph. Seit 0.9.1 unterstützt der Graph SQLite als Speicher und bleibt zugleich kompatibel zu Neo4j, was für Einzelnutzer praktisch ist: kein zusätzlicher Dienst, nur eine Datei. Seit 0.9.4 gibt es einen einheitlichen Ablauf für sechs Extraktionsarten (Figuren, Beziehungen, Schauplätze, Organisationen, Gegenstände, Konzepte). Immer gleich: aus dem Kapiteltext extrahieren, Vorschau zeigen, manuell nachbessern, dann bestätigen und in Karten oder Graph schreiben. Dass die Vorschau vorgeschaltet ist, ist die wichtigste Eigenschaft. Automatische Extraktion in einen Wissensgraphen produziert sonst stillen Datenmüll, der jede spätere Generierung verzerrt. Das README warnt selbst, die neuen Statustypen nur nach Bedarf zu nutzen, um die Kontextkomplexität nicht zu erhöhen.

Installation und die Konfiguration, die man wirklich anfasst

Das Repository ist Python-basiert und mit AGPL-3.0 lizenziert. Die Release Notes zu 0.9.2 erwähnen einen Ein-Klick-Start für Frontend und Backend. Eine Web-Variante kam mit 0.8.6 hinzu. Die Portkonfiguration ist der konkreteste Berührungspunkt: Laut 0.9.7 lässt sich der Backend-Port über die Datei backend/.env und den Schlüssel APP_PORT setzen, Standard ist 54321, gültig ist der Bereich 1 bis 65535. Wer den Dienst hinter einem Reverse Proxy betreibt, wird diesen Schlüssel ändern wollen. Ein zweiter Konfigurationspunkt betrifft die Zuverlässigkeit der Assistenten-Tool-Aufrufe: Laut 0.8.2 lässt sich die maximale Anzahl automatischer Wiederholungen über die .env-Datei einstellen, der Schlüsselname wird im README-Auszug allerdings nicht genannt. Für Modelle ohne native Tool-Unterstützung existiert ein ReAct-Modus mit textbasierten Tool-Aufrufen, standardmäßig deaktiviert und in den Einstellungen des Assistenten umschaltbar. Die Release Notes zu 0.8.3 bezeichnen diese Implementierung selbst als grob und empfehlen Modelle mit nativer Tool-Unterstützung. Seit 0.9.6 gibt es zusätzlich eine Fähigkeitsprüfung auf der LLM-Konfigurationsseite, die Basis-Dialog, Streaming, strukturierte Ausgabe und Tool-Aufrufe testet. Das ist der erste Schritt nach der Installation, den man nicht überspringen sollte.

Der Code-Workflow und sein Bruch mit dem DAG

Die auffälligste Änderung in 0.9.0 ist der Wechsel von einem DAG-Editor zu einem Code-Workflow im Python-Stil mit eigenen DSL-Markern. Das README nennt die Gründe und die Kosten in derselben Passage. Als Vorteile gelten lineare Semantik für Sequenz, Warten über Logic.Wait und Asynchronität über async=true, außerdem eine bessere Eignung für Sprachmodelle: Ein Funktionsumfang, der als DAG mehrere hundert Zeilen Knoten und Kanten braucht, lasse sich im Code in einigen Dutzend Zeilen ausdrücken. Als Nachteile nennt das Projekt selbst die geringere Anschaulichkeit und die Empfindlichkeit gegenüber Formatdetails, etwa Parameterserialisierung, Feldtypen in Diktaten und Variablenreferenzen. Das ist bemerkenswert offen formuliert und deckt sich mit der Sache: Eine textuelle DSL verschiebt Fehler von der Konfigurationsoberfläche in die Validierung. Wer Workflows schreibt, braucht Fehlermeldungen, die die Zeile benennen, nicht nur den Typ. Der Workflow-Agent, der Workflows aus natürlicher Sprache erzeugt oder ändert, arbeitet nach dem Muster Vorschau vor Anwendung. Die Release Notes zu 0.9.0 räumen ein, dass er noch Fehler haben dürfte.

Wo NovelForge das falsche Werkzeug ist

Die Migrationsgeschichte ist die deutlichste Warnung im Material. Die Release Notes zu 0.9.0 schreiben, dass Datenbanken älterer Versionen möglicherweise nicht direkt nutzbar sind, dass ein Migrationsskript existiert, dessen Erfolg nicht garantiert wird, und dass vorher eine Sicherung der db-Datei erfolgen sollte. Wer eine bestehende Installation über mehrere Minor-Versionen zieht, sollte mit Handarbeit rechnen. Dazu kommt die Lizenz. AGPL-3.0 bedeutet, dass abgeleitete Werke, die über ein Netzwerk genutzt werden, ebenfalls unter dieser Lizenz stehen müssen. Für private Romanprojekte ist das irrelevant. Wer NovelForge als Backend eines gehosteten Schreibdienstes einsetzen will, muss die Konsequenzen prüfen; das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Wahl der Lizenz hier praktische Folgen hat. Schließlich die Zielgruppe: Wer eine einzelne Kurzgeschichte schreiben will, findet in NovelForge mehr Struktur, als die Aufgabe verlangt. Karten, Schemas, Graph und Workflow sind Investitionen, die sich erst ab einer Größenordnung amortisieren, in der ein Modell den Überblick verliert.

Alternative: Obsidian plus ein Modell-Plugin

Der naheliegende Vergleich ist eine Wissensbasis wie Obsidian, ergänzt um ein Plugin, das ein Sprachmodell aufruft. Der Unterschied liegt nicht in den Funktionen, sondern im Datenmodell. Obsidian speichert Markdown-Dateien und Verweise zwischen ihnen; die Struktur entsteht durch Konvention, und nichts validiert sie. Ein Modell kann dort völlig freie Prosa zurückgeben, und das ist in der Erkundungsphase ein Vorteil. NovelForge dreht das um: Die Struktur steht vor dem Text, und die Ausgabe wird gegen sie geprüft. Wer bereits eine Obsidian-Sammlung mit hunderten Notizen hat, wird den Wechsel als Verlust empfinden, weil die Schemas neu geschrieben werden müssen. Umgekehrt hat NovelForge gegenüber einem reinen Markdown-Ansatz den Vorteil, dass Beziehungen zwischen Figuren als Graph vorliegen und nicht als Fließtext in einer Notiz, was gezieltes Abfragen überhaupt erst möglich macht. Die Entscheidung hängt damit weniger am Funktionsumfang als an der Frage, ob man bereit ist, sein Weltwissen in typisierte Felder zu gießen.

Redaktionelles Fazit

NovelForge passt zu Autorinnen und Autoren, die ihre Welt konsistent halten wollen und bereit sind, Schemas und Workflow-Code zu pflegen. Wer nur einen schnellen Chat zum Diktieren eines Kapitels sucht, ist hier falsch bedient, weil der Aufwand für Karten und Schema-Validierung vor dem ersten brauchbaren Satz liegt. Vor dem Umstieg auf 0.9.x unbedingt die Datenbankdatei sichern und den mitgelieferten Migrationsskript-Lauf prüfen, denn die Release Notes zu 0.9.0 sagen ausdrücklich, dass eine Migration nicht garantiert gelingt.

Offizielle Quellen

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. RhythmicWave/NovelForge on GitHub