SYMBAN — Roman-Produktionssoftware

Status: Live unter symban.de Eigenes Produkt · Konzept, Architektur, Entwicklung & Betrieb von Alexia Michailidou seit Januar 2025 Stack: Vite · React · TypeScript · Supabase (Postgres + pgvector) · Multi-Provider-KI (Claude, OpenAI, Gemini) · 5 Sprachen

Was SYMBAN ist

SYMBAN ist eine Software, die Autor:innen beim Schreiben ganzer Romane begleitet. Sie merkt sich konsistent, wer wem was schuldet, welche Augenfarbe die Heldin hat und wo sich Plot-Linien kreuzen — auch in Kapitel 47, auch in Band 5.

Architektur in einem Satz

Multi-Pass-Pipeline + Multi-Index-RAG mit pgvector, in Supabase Edge Functions, multi-Provider-resilient.

Pipeline (11 Stages)

BRIEFING → BRIEFING_QC → RECALL → WRITE → CRITIC → FIX_NARRATIVE → QC → LEKTOR → POLISH → GATES → EXTRACT

Jede Stage hat einen eigenen Handler (30+ TypeScript-Files in run-pipeline/), eigene DB-Prompts mit Approval-Workflow und eigenes Context-Assembly. Jede Szene durchläuft elf Disziplinen vor Auslieferung — kein ChatGPT-Rohguss, sondern druckreifer Text.

RAG-Schicht

Vier Embedding-Tables (logbook_entries, scene_logs, chapter_summaries, concept_documents), je 1536-dim Vektoren. HNSW-Indexes mit getunten Parametern (m=16, ef_construction=64) für schnelle Cosine-Similarity-Search. Plus deterministischer Recall als Komplement — manche Charakter-Facts brauchen exakten Match, nicht semantische Nähe.

Drei RAG-Iterationen bisher (rag_v3_dual_position_format) — jede auf Lessons-Learned der Vorgänger-Version.

Multi-Provider

Pro Stage das beste Modell. Provider-Abstraktion mit Cost-Tracking, API-Key-Management, automatischer Fallback. Vendor-Lock-in ist ein Geschäftsrisiko, nicht nur ein Tech-Detail.

Warum ich es gebaut habe

Ich lese viel und schreibe selbst literarische Kurztexte. Beim Versuch, mit ChatGPT einen Roman aufzubauen, war schon nach Kapitel 5 klar: das Tool vergisst. Es vergisst Augenfarben, Versprechen, Beziehungen. Bestehende Tools wie Sudowrite oder NovelCrafter helfen beim Polish, aber bauen keinen ganzen Roman.

SYMBAN sollte das schließen — und ist parallel mein Hands-on-Beleg, dass ich KI nicht nur predige, sondern wirklich verstehe.

Lessons Learned

1. RAG-Qualität ist Index-Topologie + HNSW-Tuning + Deterministic-Komplement. Vector-Similarity ist nicht der einzige Hebel. Welche Tables embedding kriegen, wie gechunked wird, m/ef_construction-Tuning — das sind Performance-Decisions, nicht Defaults. Plus: Manche Recalls brauchen exakten Match (Charakter-Geburtsdatum), nicht semantische Nähe. Hybrid Retrieval ist die Antwort.

2. Multi-Pass-Pipeline statt Loops. Klassischer Ansatz: WRITE → QC → FIX → QC → FIX → .... Bei SYMBAN: ein Durchlauf pro Stage, kein Loop. Jede zusätzliche QC-Iteration verschiebt Inhalte unkontrolliert. Stattdessen disziplinierte Stages mit klaren Verantwortlichkeiten — LEKTOR fixt Issues einmal, POLISH macht freies literarisches Lektorat einmal, dann GATES → EXTRACT.

3. Migrations als Audit-Trail. Über 200 Migrations bisher, alle idempotent. Cleanup-Migrations bei Refactors. supabase db reset --linked muss von 0 chronologisch funktionieren. Das ist die DB-Architektur-Disziplin — kein "nice to have".

4. Multi-Provider-Architektur ist Pflicht. Ein Provider-Lock-in (z.B. nur OpenAI) ist ein Geschäftsrisiko. SYMBAN nutzt Claude, OpenAI und Gemini parallel — pro Aufgabe das jeweils beste Modell.

5. Brand-Voice ist die Grenze zwischen KI-Tool und Markenwelt. SYMBAN positioniert sich aktiv NICHT als KI-Software (Roman-Produktionssoftware, Schreibwerkstatt) — die Brand-Voice führt die Wahrnehmung weg vom KI-Hype hin zum Werkzeug-Charakter. Das ist Marketing-Disziplin, nicht Tech.

Live ansehen

symban.de — die Software ist live, du kannst sie kostenlos im Einstiegs-Plan ausprobieren.

SYMBAN ist mein eigenes Produkt — diese Case-Story ist daher ohne juristische Auflagen frei verfügbar. Für Beratung, Sparring oder Projekte rund um RAG-Integration: Lass uns sprechen.