Naly-Ingenieursnotizen: Source-First RAG-Artikelentwurf für persistentes, auditierbares Publizieren

TL;DRRetrieval-augmented Generation (RAG) macht Nalys Artikelpipeline zu einem quellengeführten Veröffentlichungssystem statt zu Modellgedächtnis-Komposition. Jede Entwurfsanforderung sammelt zuerst Web- und arXiv-Beweise, normalisiert und persistiert Quellen-URLs und fordert das Modell dann auf, einen Answer-First-Entwurf und einen finalen HTML-Artikel zu erzeugen. Dadurch verschiebt sich das Risiko von „Kann das Modell halluzinieren?“ zu „Ist die Retrieval-Ebene vollständig und nachverfolgbar?“, was Editoren stabile Artefakte, wiederholbare Jobs und belastbare öffentliche Behauptungen liefert.

Zusammenfassung

RAG bei Naly sollte um Quellenpersistenz und deterministische Verträge. Zum 27. Juni 2026 ist praktische Zuverlässigkeit weniger das Ergebnis eines größeren Modells als vielmehr der Frage, ob Abruf-Artefakte abfragbar, versioniert und vor der Veröffentlichung validiert sind. Diese Notiz schlägt ein Dual-Plane-Design vor: eine Evidenz-Ebene für Abruf/Speicherung und eine Generierungs-Ebene für Entwürfe, und erklärt, wie diese Architektur die redaktionelle Vertrauensbildung und die Incident-Bearbeitung direkt verbessert.

Einordnung in Naly

Naly betreibt dies als Produktions-Content-Subsystem innerhalb eines Next.js 16.0.7 App Router-Stacks („next + react), in dem die Artikelpublikation Teil der Runtime-Codepfade ist statt eines separaten Offline-Schreibschritts. Der Artikel-Job-Pfad ist der Ort, an dem alle Beschränkungen eingehalten werden: Ein Job ist nicht „geschrieben“, bis Quellen-Datensätze existieren, die Zusammenfassungsstruktur validiert ist und HTML materialisiert wurde.

Die Stack-Ausrichtung ist beabsichtigt:

next@16.0.7 + React Server Components hosten jobausgelöstes Rendering im Serverkontext und erfüllen serverseitige Ausgabeverträge für Artikel.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 definieren typisierte, persistente Job- und Quelltabellen, damit jede Behauptung nachverfolgbar ist.
ai@6.0.0-beta.105 liefert der Generierung schema-aware Ausgabesteuerungen.
marked@17.0.1 wandelt generierte Markdown-Zusammenfassungen in gerendertes HTML für die Veröffentlichung um.
@vercel/blob@2.0.0 speichert generierte Assets als dauerhafte URLs zur Wiederverwendung.
Anthropic-Tools können als alternativer Modellprovider innerhalb desselben Vertragsschemas ergänzt werden, aber nicht als Fluchtweg aus strukturierten Einschränkungen.

Das ersetzt ein „erst generieren, dann korrigieren“-Modell durch einen quellengebundenen Schreibzyklus: Retrieval, Validierung, Generierung, Rendering und Veröffentlichung müssen alle bestanden werden, bevor der Artikel sichtbar ist.

Technischer Mechanismus

Ein robustes Naly-Design hat fünf abgegrenzte Stufen:

Evidenzplan und Abfrage-Orchestrierung

Definiere die Job-Spezifikation mit Thema, Datumsfenster und Evidenzrichtlinie.
Starte sowohl Web-Suche als auch arXiv-Suche für Primärquellen.
Duplizierung nach kanonischer URL entfernen und Protokoll, Host sowie Query-String normalisieren.

Schicht der Quellenpersistenz

Speichere Metadaten pro URL (url, kanonisierte URL, Abrufstatus, Abrufzeitstempel, Titel, Auszug, Quellentyp).
Speichere modellseitige Ausschnitte getrennt von Rohdaten, damit Wiederholläufe deterministisch bleiben, selbst wenn sich upstream Seiten ändern.
Füge je Quelle Prüfsummen hinzu, um Drift zu erkennen.

Kontextgestaltung und Einschränkungen

Erstelle einen Retrieval-Kontext, sortiert nach Relevanz und Aktualität.
Erzwinge explizite Quellen-IDs im Prompt-Vertrag.
Erzwinge ein Answer-First-Ausgabeformat (intro claim, evidence bullets, risk caveats, uncertainty), plus geordnete Quellenverweise.

Strukturierte Generierung mit striktem Schema

Nutze strukturierte Ausgabe, damit fehlerhafte oder schema-konforme Antworten sofort fehlschlagen und mit engerem Kontext erneut versucht werden.
Halte Generierung im Serverkontext und lehne Entwürfe ab, die nicht unterstützte Fakten ohne gemappte Quellen-IDs beanspruchen.

Rendern, veröffentlichen und prüfen

Konvertiere validiertes Markdown in HTML und persistiere Markdown + HTML.
Cache finaler Ausgabe nur nach erfolgreicher Validierung.
Gib Analysedaten und Audit-Felder aus: Quellenzahl, abgelehnte Behauptungen, Wiederholungsanzahl und Generierungs-Latenz.

Die wichtigste architektonische Bewegung ist die Trennung der Verantwortlichkeiten: Retrieval-Qualität und Generierungsqualität sind unterschiedliche Fehlerdomänen mit unterschiedlichen Metriken. Next.js Server Components passen zu dieser Aufteilung, weil Rendering deterministisch bleiben kann, während Retrieval und Generierung in kontrollierten asynchronen Tasks stattfinden.

Was die Fachliteratur sagt

Aktuelle RAG-Literatur unterstützt dieses Architekturmuster. Eine Umfrage zu RAG-Architekturen aus 2024 beschreibt, wie Retrieval-augmentierte Systeme Fact Drift verringern, indem sie Generierung auf externe Evidenz stützen, nennt aber Kompromisse in Pipeline-Komplexität und modularer Koordination [Gupta et al., 2024]. Eine Anschluss-Umfrage von 2025 ergänzt, dass Robustheit heute von adaptivem Retrieval, Dekodierungssteuerung und End-to-End-Evaluation abhängt, nicht nur von der reinen Generierungsqualität [Sharma, 2025].

Für die Produktionsqualitätssicherung teilt die 2025 auf Evaluierung fokussierte Umfrage die Bewertung explizit in interne Retriever-/Generator-Metriken und externe Systemmetriken auf; diese Zerlegung ist für Artikelpipelines besonders nützlich, weil ein „schlechter Artikel“ auch bei hoher Sprachqualität falsch gewählte Quellen bedeuten kann [Gan et al., 2025]. Groundedness-spezifische Arbeiten setzen ebenfalls auf Erkennungsschichten, die die Unterstützbarkeit von Behauptungen mit abgerufenem Kontext und NLI-ähnlichen Prüfungen klassifizieren und so den praktischen Wert einer Validierung nach der Generierung bestätigen [Gerner et al., 2025].

Kurz gesagt konvergieren die Arbeiten auf eine These: RAG ist nicht nur eine Methode, um Kontext einzuspeisen, sondern es ist ein technischer Vertrag zwischen Retrieval und Generierung. Naly sollte daher den Vertrag optimieren, nicht nur den Prompt.

Design-Trade-offs

Aktualität vs. Determinismus: strengere TTLs verringern Veralterung, erhöhen aber die Kosten für erneutes Abrufen. Durch persistierte Snapshots bleibt deterministisches Rendering möglich, während Aktualitätsfenster weiterhin revalidiert werden.
Recall vs. Präzision bei Retrieval: breiter Retrieval kann die Abdeckung erhöhen, fügt jedoch Rauschen hinzu; ein Zweistufen-Relevanzfilter schützt die Claim-Qualität.
Schema-Strenge vs. Textfluss: strenge Ausgabeschemata erhöhen die Maschinenzuverlässigkeit, können aber stilistische Freiheit reduzieren. Das Answer-First-Schema-Muster erhält die Lesbarkeit, während Guardrails erhalten bleiben.
Statische Rendergeschwindigkeit vs. Auditierbarkeit: vorgerendertes HTML verbessert die Auslieferungsleistung und reduziert wiederholte Berechnung, aber nur, wenn die genutzten Quellenartefakte unveränderliche Referenzen sind.
Komplexität vs. Betriebskosten: jeder hinzugefügte Validierungsschritt (Quellenprüfungen, Schemavalidierung, Artefakt-Persistenz) erhöht die Latenz. Aktuelle Produktionsleitlinien zu Caching, Route-Grenzen und Build-Time-Verification sind wichtig, um den Betrieb praktikabel zu halten.

Fehlermodi

Quellen-Drift: URLs liefern nach Job-Erstellung 404/Soft-Änderungen. Gegenmaßnahme: kanonischer Schlüssel + Snapshot-Hash + Fallback-Quellenkette.
Retrieval-Übersteuerung: hoher Recall bei niedriger Präzision führt zu plausibler, aber nicht unterstützter Synthese. Gegenmaßnahme: Evidenz-First-Einschränkungen erzwingen und Behauptungen ohne Quellenübereinstimmung blockieren.
Modell-Formatierungsfehler: Schema-Mismatch oder abgeschnittenes JSON bei der Generierung. Gegenmaßnahme: strikte Schemagültigkeitsprüfung und Retry mit reduziertem Kontext.
Doppelveröffentlichungsrennengleichzeitige Worker können Teil-Artefakte veröffentlichen. Gegenmaßnahme: Idempotenzschlüssel pro Job, Zustandsübergänge auf Zeilenebene („pending -> drafting -> validated -> published“ ).
Rendering-Regressionen: fehlerhaftes Markdown oder unsichere HTML-Transformationen. Gegenmaßnahme: deterministischer marked Konvertierungspfad und HTML-Ausgabetests, verknüpft mit Beispielmanifests.
Cache-Illusionen: veraltete dynamische Daten im Server-Output können veröffentlichte Texte und Quellenindex entkoppeln. Gegenmaßnahme: Renderstrategie der Route an eine explizite Laufzeit-Frischepolitik koppeln und implizite Caches dort vermeiden, wo Evidenzfrische erforderlich ist.

Implementierungshinweise

Behandle dies für einen praxistauglichen Rollout als Veröffentlichungs-Vertragskonzept:

Definiere Quelltabellen in Drizzle mit expliziten Constraints: URL-Eindeutigkeit nach kanonischem Host/Pfad, Enumerationen für Abrufstatus und Prüfsummen-Spalten.
Verwende konsistent einen Neon-kompatiblen Treiberpfad mit dem Ausführungsverhalten von Serverless; die Drizzle-Dokumentation beschreibt sowohl runtime-spezifische als auch neon-* Treiber-Optionen.
Erzwinge in der Generierung strukturierte Ausgabeverträge und lehne ungültige Objekte vor dem Rendering ab.
Nutze die Next.js-Produktionsleitlinien für Servergrenzen, Fehlerseiten, Caching und SEO-Metadaten von Artikelrouten, damit Publikation beobachtbar und schnell bleibt.
Persistiere generierte Blobs (z. B. Titelbilder, Anhänge, Exporte) über Vercel Blob mit expliziter Zugriffspolitik und deterministischer Benennung, um Kollisionen zu vermeiden.
Gib Betriebsprüfungen vor der Veröffentlichung aus: Mindestanzahl an Quellen, minimale Quellenvielfalt, Evidenzfrische und Mindest-Erfüllungsquote für gemappte Behauptungen.

Das ist der zentrale Wandel: Der Artikel wird nicht mehr nach Modellklugheit beurteilt, sondern danach, ob Evidenz und Generierung unter Retries und Redeploys synchron bleiben.