Teil 3: Betrieb, Stabilität und Verlagstauglichkeit

Worker-Betrieb im Alltag

Die Worker laufen als systemd-Services:

• reproduzierbare Umgebung
• kein Entwickler-Setup
• keine versteckten Abhängigkeiten

Mehrere Worker erhöhen Durchsatz, nicht Komplexität.

---

Monitoring aus Verlagssicht

Ich will keine Metriken um der Metriken willen. Relevant sind:

• läuft das System?
• wie viele Jobs sind aktiv?
• wo hängt es?
• warum ist ein Job fehlgeschlagen?

Alles andere ist zweitrangig.

---

Logging mit Kontext

Jeder Logeintrag enthält:

• Job-ID
• Pipeline-Schritt
• Modellkennung

So kann ich auch Monate später nachvollziehen, warum ein bestimmtes Buch so übersetzt wurde, wie es übersetzt wurde.

---

Kostenkontrolle

KI-Übersetzung kostet. Besonders bei mehrstufigen Pipelines muss das beachtet werden.

Deshalb:

• harte Limits
• klare Abbruchbedingungen
• keine automatischen Wiederholungen ohne Analyse

Ein Verlag denkt langfristig. Stabilität schlägt Durchsatz.

---

Schlussgedanke

Ich habe diesen Übersetzer nicht gebaut, um „KI zu nutzen“, sondern um Bücher zu veröffentlichen, die es sonst nicht gäbe – auch aus Sprachräumen, die technisch anspruchsvoll sind.

Symfony bietet dafür ein stabiles Fundament. Der Rest ist Architektur, Disziplin und die Bereitschaft, Übersetzung als ernsthaften Produktionsprozess zu begreifen.

Damit wird aus einem Experiment ein Werkzeug, auf das ich mich als Verleger verlassen kann.