Dokki: eine RAG-Pipeline in drei Planes
PDF/eBook rein, geerdete Antworten mit Quellen raus — aufgeteilt in Data, Control und Query Plane auf dem bestehenden MJTHD-Stack.
BEITRÄGE
Build-Logs, Post-mortems und Notizen, die es wert sind. Neueste zuerst.
PDF/eBook rein, geerdete Antworten mit Quellen raus — aufgeteilt in Data, Control und Query Plane auf dem bestehenden MJTHD-Stack.
Minimum Viable Product richtig verstanden: nicht die halbe Lösung, sondern das schnellste Experiment zum Lernen.
Immutable Versionen, Snapshots als Manifest und Rollback als reiner Pointer-Flip — wie Dokki den produktiven Korpus schützt.
Ein Designprozess in vier Phasen — und warum die meiste Arbeit vor der ersten Lösungsidee passiert.
Zweistufige Prüfung vor jeder Promotion — billiger Sanity-Check, dann Eval-Set gegen den aktiven Snapshot. Aktivierung nur bei mindestens gleicher Qualität.
Wie Dokki eine Frage in Top-k Chunks des aktiven Snapshots übersetzt — HNSW auf halfvec, ein geteiltes Embedding-Modell und Quellen, die man nachschlagen kann.
Die standardmäßig aktive Datensammlung ausschalten — in Dev, in CI und im Image.
Die Deploy-Pipeline hinter dieser Seite: einmal bauen, aus Git synchronisieren, zwei Domains auf einen Service routen.
Warum es diese Seite gibt und was du hier findest.