Naly Engineering Notes: Retrieval-augmentiertes Artikelschreiben mit dauerhaft gespeicherten Quellen

Zusammenfassung

Retrieval-Augmented Generation gibt Nalys Artikel-Pipeline ein Recherchegedächtnis, das aktueller und besser auditierbar ist als Modellgewichte allein. Für jede Engineering Note oder jeden Market-Intelligence-Artikeljob kann das System Web und arXiv durchsuchen, die Quell-URLs zusammen mit dem erzeugten Artefakt speichern, das Modell zuerst antworten lassen und das Ergebnis als HTML rendern. Es geht nicht um Automatisierung um ihrer selbst willen; es geht darum, Claims zu veröffentlichen, die Leser zurückverfolgen können.

Die These ist einfach: RAG für das Artikelschreiben sollte als produktives Evidenzsystem behandelt werden, nicht als Chatbot-Muster. Einem Chatbot kann man eine schwache Antwort verzeihen; ein veröffentlichter Artikel wird zu einer dauerhaften Vertrauensfläche. Nalys Implementierung braucht daher drei Invarianten: Retrieval vor dem Entwurf, Quellendatensätze, die nach der Veröffentlichung erhalten bleiben, und einen Renderer, der lesbares Markdown bewahrt und zugleich unsicheres HTML vermeidet.

Wo es in Naly sitzt

Naly-Artikeljobs liegen zwischen Recherchebeschaffung und öffentlicher Veröffentlichung. Der Job beginnt mit einem ausgewählten Thema, erzeugt Suchintentionen, ruft Web- und arXiv-Material ab, normalisiert die Ergebnisse zu Quellendatensätzen und bittet dann ein Modell, aus diesem begrenzten Evidenzsatz einen antwortorientierten Artikel zu schreiben. Die Ausgabe ist nicht nur Prosa. Sie ist ein Paket: Markdown-Inhalt, gerendertes HTML, Quell-URLs, Quellentitel, Quellentypen und genug Metadaten, um zu erklären, warum jede Quelle verwendet wurde.

Das ist wichtig für Nalys Vertrauensschleife. Nalys breitere redaktionelle Haltung ist, zu veröffentlichen, was andere verbergen: Entscheidungsmemos, Kalibrierungsgrenzen, Fehler und die Evidenz hinter Claims. Quellenbasierte Generierung macht diese Haltung operativ. Leser sollten nicht raten müssen, ob eine Aussage aus den Trainingsdaten eines Modells, einem offiziellen Dokument, einem Paper oder einer Betreiberbehauptung stammt.

Die RAG-Schicht gehört vor den Entwurf, nicht danach. Nachträglich angehängte Zitationen sind schwächer, weil das Modell seine Claims bereits gebildet hat. In einem stärkeren Design begrenzt Retrieval den Generierungskontext, und die Generierung erzeugt Claims, die gegen den abgerufenen Satz geprüft werden können. Der sichtbare Artikel kann knapp bleiben, aber das gespeicherte Artefakt sollte die Recherchespur bewahren.

Technischer Mechanismus

Für das Artikelschreiben ist Nalys RAG-Fluss eine Batch-Pipeline:

Die Themenauswahl erzeugt eine begrenzte Recherchefrage, etwa wie Retrieval-Augmented Generation quellenbasiertes Artikelschreiben fundiert.
Query-Planung erweitert diese Frage zu Webabfragen, Abfragen offizieller Dokumente und arXiv-Abfragen.
Retrieval sammelt offizielle Dokumentation, primäre Papers und erklärende Quellen mit hohem Signalwert.
Die Normalisierung extrahiert Titel, kanonische URL, Quellentyp, Veröffentlichungs- oder Aktualisierungskontext, wenn verfügbar, sowie relevante Snippets oder Abstracts.
Quellenpersistenz speichert das URL-Ledger vor der Generierung, damit der Artikel später auditiert werden kann.
Prompt-Assemblierung gibt dem Modell das Thema, Naly-spezifische Implementierungsfakten, Schreibvorgaben und abgerufene Evidenz.
Die Generierung erzeugt Markdown mit einer antwortorientierten Zusammenfassung, expliziten Fehlermodi und einem Referenzabschnitt.
Die Validierung prüft, dass jede Referenz im gerenderten Artikel auf ein gespeichertes Quellenobjekt verweist.
Das Rendering wandelt Markdown für die Website in HTML um und wendet dabei Bereinigung und Produktionschecks an.

Das liegt nahe am Retrieval- und Augmented-Generation-Muster, das in Vercels RAG-Leitfaden beschrieben wird: zuerst den relevanten Kontext abrufen und ihn dann vor der Generierung mit der Nutzer- oder Jobfrage kombinieren. Der Unterschied ist, dass Naly nicht für Konversationssupport optimiert. Es optimiert für dauerhafte Veröffentlichung, bei der eine Quell-URL Teil des Datenmodells des Artikels ist.

Das AI SDK ist eine natürliche Orchestrierungsschicht für diese Art von Job, weil seine Textgenerierungsoberfläche nicht-interaktive Automatisierung, Tool-Aufrufe, mehrstufige Ergebnisse und Quellenmetadaten unterstützt, wenn Provider URL-Quellen zurückgeben. Selbst wenn ein Provider keine nativen Quellenobjekte zurückgibt, kann Naly seine eigene Liste abgerufener Quellen an das Artikelartefakt anhängen und modellnative Quellen als ergänzend statt maßgeblich behandeln.

Was die Literatur sagt

Die ursprüngliche RAG-Formulierung von Lewis et al. fasste das Kernproblem gut: Parametrische Sprachmodelle speichern Fakten in Gewichten, aber dieses Wissen zu aktualisieren und Provenienz bereitzustellen bleibt schwierig. Ihr retrieval-augmentiertes Modell kombinierte ein Sequenzmodell mit einem dichten Vektorindex und fand bei wissensintensiven Aufgaben spezifischere, vielfältigere und faktischere Generierung als eine rein parametrische Baseline.

Der spätere RAG-Survey von Gao et al. verallgemeinert diese Idee zu einer Taxonomie: naives RAG, fortgeschrittenes RAG und modulares RAG. Nalys Artikel-Pipeline sollte modular sein. Retrieval, Ranking, Quellenpersistenz, Prompt-Konstruktion, Generierung, Referenzvalidierung und Rendering sind getrennte Einheiten mit getrennten Fehlermodi. Sie als getrennte Einheiten zu behandeln macht das System leichter zu debuggen, wenn ein Artikel eine schwache Quelle zitiert oder eine bessere übersieht.

Self-RAG fügt eine wichtige Warnung hinzu. Asai et al. argumentieren, dass das Abrufen einer festen Anzahl von Passagen unabhängig davon, ob Retrieval nötig ist, die Ausgabequalität verschlechtern kann. Für Naly bedeutet das: Top-k-Retrieval sollte kein Ritual sein. Ein kurzer Artikel über ein stabiles Framework-Feature braucht vielleicht offizielle Dokumentation und ein Paper; ein literaturlastiger Artikel braucht möglicherweise mehrere arXiv-Quellen und einen Survey. Die Retrieval-Tiefe sollte dem Claim-Risiko folgen.

RAGChecker liefert die Evaluationslehre. Ru et al. argumentieren, dass RAG-Systeme feingranulare Diagnostik über Retrieval und Generierung hinweg brauchen, besonders für Langform-Antworten. Für Naly sollte die Evaluationseinheit nicht nur Artikelqualität sein. Sie sollte Retrieval-Recall, Quellenrelevanz, Claim-Unterstützung, Referenzabdeckung und die Frage umfassen, ob nicht gestützte Claims ins finale Markdown gerutscht sind.

Design-Abwägungen

Hoher Recall versus geringes Rauschen ist die zentrale Abwägung. Mehr Retrieval erhöht die Chance, die richtige Quelle zu finden, erhöht aber auch die Chance, dass schwache Snippets in den Prompt gelangen und das Modell steuern. Naly sollte einen gestuften Ansatz bevorzugen: breite Sammlung, strenge Filterung, dann kompakter Prompt-Kontext.

Quellenpersistenz verbessert die Auditierbarkeit, erzeugt aber auch Speicher- und Wartungsaufwand. URLs wandern, Papers werden überarbeitet und Dokumentationsseiten ziehen um. Der dauerhafte Datensatz sollte kanonische URL, Abrufzeitpunkt, Titel, Quellentyp und idealerweise einen Content-Digest oder eine Auszugsgrenze enthalten. So kann Naly einen Modellfehler von einer veränderten Quelle unterscheiden.

Antwortorientiertes Schreiben erhöht den Lesernutzen, kann Unsicherheit aber zu stark komprimieren. Der Artikel sollte mit der Schlussfolgerung beginnen und zugleich einen späteren Abschnitt für Fehlermodi und Vorbehalte bewahren. Die antwortorientierte Zusammenfassung ist der Einstiegspunkt; sie ist keine Lizenz, die Evidenz zu glätten.

Gerendertes HTML verbessert Distribution und Leseerlebnis, schafft aber eine Sicherheitsgrenze. Marked ist schnell und nützlich für Markdown-Parsing, doch seine Dokumentation warnt ausdrücklich, dass es ausgegebenes HTML nicht bereinigt. Ein Naly-Artikelrenderer sollte generiertes HTML bereinigen und die vertrauenswürdige Markdown-Quelle für Wiederholbarkeit verfügbar halten.

Fehlermodi

Retrieval-Fehlschlag: Der Suchschritt findet plausible, aber unvollständige Quellen. Das passiert meist, wenn der Query-Planner zu eng ist oder Produktbegriffe nutzt, die sich von der Literatur unterscheiden. Abhilfe: mehrere Query-Stile verwenden, offizielle Dokumentation einbeziehen und mindestens zwei Primär- oder arXiv-Quellen verlangen, wenn der Artikel Forschungsclaims macht.

Citation Laundering: Eine Quelle erscheint in den Referenzen, stützt den Satz in ihrer Nähe aber tatsächlich nicht. Das ist schlimmer als gar keine Zitation, weil es falsche Sicherheit schafft. Abhilfe: Claims gegen Quell-Snippets validieren und Artikel ablehnen, bei denen Referenzen nur thematisch passen.

Veraltender Quellen-Drift: Eine offizielle Dokumentationsseite ändert sich nach der Veröffentlichung. Abhilfe: Quellenmetadaten zum Generierungszeitpunkt persistieren und das Datumslabel erfassen. Für Quellen, die zentrale Claims tragen, eine Momentaufnahme oder einen Digest speichern, soweit die Lizenz es erlaubt.

Over-Retrieval: Zu viele Chunks bringen das Modell dazu, den Kontext zusammenzufassen, statt die Artikelthese zu beantworten. Abhilfe: Quellenranking nutzen, nahezu identische Dokumente deduplizieren und Prompt-Evidenz nach Claim-Relevanz statt nach roher Anzahl begrenzen.

Context Poisoning: Spam-Seiten, generierte SEO-Seiten oder minderwertige Zusammenfassungen ranken vor Primärmaterial. Abhilfe: offizielle Dokumentation, arXiv, Standards und Source-Repositories höher einstufen als sekundäre Kommentare, außer der Artikel handelt ausdrücklich von der Branchenresonanz.

Renderer-Risiko: Generiertes Markdown kann Roh-HTML, unsichere Links oder fehlerhafte Tabellen enthalten. Abhilfe: gerendertes HTML bereinigen, Links normalisieren, scriptfähige Inhalte ablehnen und Produktionschecks ausführen, die mit der Next.js-Leitlinie zu Performance, Sicherheit, Metadaten und Barrierefreiheit übereinstimmen.

Implementierungshinweise

Angesichts der aktuellen Laufzeitfakten von Naly ist die saubere Architektur ein TypeScript-Job, der ai@6.0.0-beta.105 für Modellorchestrierung, Web- und arXiv-Retrieval-Tools zur Evidenzsammlung sowie Drizzle ORM mit Neon für Artikel- und Quellendatensätze verwendet, marked@17.0.1 für Markdown-zu-HTML-Rendering und Next.js 16 für die Veröffentlichungsoberfläche.

Die Datenbank sollte Quellen als erstklassige Zeilen behandeln, nicht als Blob von Markdown-Text. Ein praktikables Schema hat eine Artikeltabelle, eine Artikel-Quelle-Join-Tabelle und Quellenfelder für URL, Titel, Quellentyp, Abrufzeitpunkt, kanonische Kennung wie arXiv ID, wenn verfügbar, und Extraktionsstatus. Der Artikeldatensatz kann dann auf Markdown, gerendertes HTML, Zusammenfassung, Kernpunkte und Veröffentlichungsmetadaten verweisen.

Vercel Blob ist nützlich für größere Artefakte oder unveränderliche Render-Ausgaben, während Postgres als abfragbares Ledger für Quellen und Artikelmetadaten besser bleibt. Diese Trennung hält Audit-Abfragen günstig: jeden Artikel auflisten, der eine Quelle verwendet hat, jede von einem Artikel verwendete Quelle und jeden Artikel, dessen Quellenextraktion fehlgeschlagen ist.

Der Generator-Prompt sollte Quellendisziplin in der Form der Ausgabe verlangen: keine nicht gestützten Claims, keine erfundenen URLs und ein Referenzabschnitt, dessen Links zur persistierten Quellenliste passen müssen. Das Modell kann flüssige Prosa schreiben, aber der Job sollte die Quellenwahrheit besitzen. Wenn das Modell eine Referenz ausgibt, die nicht abgerufen wurde, sollte der Validator den Artikel fehlschlagen lassen, statt ihn still zu veröffentlichen.

Schließlich zählt Produktionsverhalten. Next.js bietet bereits Server Components, Code-Splitting, Prerendering und Caching-Defaults, doch Pipelines für generierte Inhalte brauchen weiterhin explizite Fehlerbehandlung, Sicherheitschecks, Metadaten und Bewusstsein für Core Web Vitals. RAG hilft Naly, mit Evidenz zu schreiben. Production Engineering stellt sicher, dass diese Evidenz Leser schnell, sicher und wiederholt erreicht.