Uwagi inżynierskie Naly: tworzenie artykułów RAG z priorytetem źródeł dla trwałej i audytowalnej publikacji

TL;DRGenerowanie wspomagane wyszukiwaniem (RAG) zamienia pipeline artykułów Naly w system publikacji oparty na źródłach zamiast na składaniu treści z pamięci modelu. Każde żądanie wersji roboczej najpierw zbiera dowody z sieci i arXiv, normalizuje i utrwala adresy URL źródeł, a następnie prosi model o wygenerowanie najpierw wersji odpowiedzi, a potem końcowego artykułu HTML. Przesuwa to ryzyko z pytania „czy model halucynuje?” na „czy warstwa pobierania jest kompletna i możliwa do prześledzenia,” dając redaktorom stabilne artefakty, odtwarzalne zadania i obronne wnioski publiczne.

Streszczenie

RAG w Naly powinien być projektowany wokół utrwalania źródeł i deterministycznych kontraktów. 27 czerwca 2026 praktyczna niezawodność bierze się mniej z większego modelu, a bardziej z tego, czy artefakty pobierania są zapytalne, wersjonowane i walidowane przed publikacją. Ta notatka proponuje projekt o podwójnej płaszczyźnie: płaszczyźnie dowodów dla pobierania/przechowywania i płaszczyźnie generowania dla tworzenia szkiców, a następnie wyjaśnia, jak ta architektura bezpośrednio poprawia zaufanie redakcyjne i obsługę incydentów.

Miejsce w Naly

Naly uruchamia to jako produkcyjny podsystem treści w obrębie stosu Next.js 16.0.7 App Router (next + react), gdzie publikacja artykułów jest częścią ścieżek uruchamiania w czasie działania, a nie oddzielnym etapem redakcyjnego opracowania offline. Ścieżka zadania artykułu to miejsce, gdzie muszą być egzekwowane wszystkie ograniczenia: zadanie nie jest „napisane”, dopóki nie istnieją rekordy źródeł, nie zostanie zweryfikowana struktura podsumowania i nie zostanie utworzony HTML.

Intencjonalne dopasowanie stosu jest następujące:

next@16.0.7 + Komponenty React Server Components hostują renderowanie wyzwalane zadaniem po stronie serwera, dopasowując kontrakty wyjściowe po stronie serwera dla artykułów.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 definiują typowane, trwałe tabele zadań i źródeł, dzięki czemu każde twierdzenie można prześledzić.
ai@6.0.0-beta.105 zapewniają modelowaniu kontrolę wyjścia świadomą schematu.
marked@17.0.1 konwertują wygenerowane podsumowania Markdown do wyrenderowanego HTML do publikacji.
@vercel/blob@2.0.0 przechowują wygenerowane zasoby jako trwałe adresy URL do ponownego użycia.
Narzędzia Anthropic można dodać jako alternatywnego dostawcę modelu w tym samym pakiecie kontraktu, ale nie jako drogę ucieczki od ustrukturyzowanych ograniczeń.

To zastępuje model „wygeneruj, a potem sprawdź” modelem zwartej pętli pisania opartej o źródła: pobieranie, walidacja, generowanie, renderowanie i publikacja muszą się zakończyć pomyślnie, zanim artykuł stanie się widoczny.

Mechanizm techniczny

Solidny projekt Naly ma pięć ograniczonych etapów:

Plan dowodowy i orkiestracja zapytań

Zdefiniuj specyfikację zadania z tematem, oknem dat i zasadami dotyczących dowodów.
Uruchom wyszukiwanie w sieci i wyszukiwanie arXiv dla źródeł pierwotnych.
Usuwaj duplikaty na podstawie kanonicznego URL i normalizuj protokół, hosta i ciąg zapytania.

Warstwa utrwalania źródeł

Przechowuj metadane dla każdego URL (url, kanonikalizowany URL, status pobierania, znacznik czasu pobrania, tytuł, fragment, typ źródła).
Przechowuj fragmenty widziane przez model oddzielnie od surowych ładunków, aby ponowne uruchomienia były deterministyczne nawet w przypadku zmian stron źródłowych.
Dodaj sumy kontrolne dla każdego źródła, aby wykrywać dryf.

Kształtowanie kontekstu i ograniczenia

Buduj kontekst pobierania uporządkowany wg. trafności i aktualności.
Wymagaj jawnych identyfikatorów źródeł w kontrakcie promptu.
Wymuszaj kształt wyjścia zaczynającego się od odpowiedzi (intro claim, evidence bullets, risk caveats, uncertainty), plus uporządkowane odwołania do źródeł.

Strukturalna generacja z rygorystycznym schematem

Używaj ustrukturyzowanego wyjścia, aby odpowiedzi niepoprawne lub niezgodne ze schematem kończyły się błędem natychmiast i były ponawiane z ściślejszym kontekstem.
Utrzymuj generowanie w kontekście serwera i odrzucaj szkice, które zgłaszają niepodparte fakty bez mapowanych ID źródeł.

Renderuj, publikuj i weryfikuj

Konwertuj zweryfikowany Markdown na HTML i utrwalaj zarówno Markdown, jak i HTML.
Buforuj wynik końcowy dopiero po udanej walidacji.
Emituj pola analityczne i audytowe: liczbę źródeł, odrzucone twierdzenia, liczbę ponowień i opóźnienie generowania.

Najważniejszym ruchem projektowym jest separacja odpowiedzialności: jakość pobierania i jakość generowania to różne domeny awarii z różnymi metrykami. Komponenty serwera Next.js doskonale pasują do takiego podziału, ponieważ renderowanie może pozostać deterministyczne, podczas gdy pobieranie i generowanie odbywają się w kontrolowanych zadaniach asynchronicznych.

Co mówią źródła naukowe

Najnowsza literatura o RAG potwierdza ten wzorzec architektoniczny. Przegląd architektury RAG z 2024 roku opisuje, jak systemy oparte na RAG ograniczają dryf faktów, warunkując generowanie na zewnętrznych dowodach, ale wskazuje na kompromisy związane ze złożonością pipeline'u i koordynacją modułową [Gupta et al., 2024]. Uzupełniający przegląd z 2025 roku dodaje, że obecnie niezawodność zależy od adaptacyjnego pobierania, kontroli dekodowania i ewaluacji end-to-end, a nie tylko od jakości samej generacji [Sharma, 2025].

W przypadku kontroli jakości produkcyjnej przegląd z 2025 roku, skoncentrowany na ewaluacji, jawnie dzieli ocenę na metryki wewnętrzne retrievera/generatora oraz metryki zewnętrznego systemu; takie rozbicie jest szczególnie użyteczne dla pipeline'ów artykułów, ponieważ „zły artykuł” może oznaczać nieprawidłowy wybór źródła, nawet gdy jakość języka jest wysoka [Gan et al., 2025]. Badania ukierunkowane na zakotwiczenie wyszły również w kierunku warstw detekcji, które klasyfikują wsparcie twierdzeń przy użyciu pobranego kontekstu oraz kontroli w stylu NLI, wzmacniając praktyczną wartość walidacji po generacji [Gerner et al., 2025].

Krótko mówiąc, publikacje zbieżne są w jednej tezie: RAG to nie tylko sposób na wstrzyknięcie kontekstu, to kontrakt inżynierski między pobieraniem a generowaniem. Naly powinno więc optymalizować ten kontrakt, a nie tylko prompt.

Kompromisy projektowe

Aktualność a deterministyczność: surowsze TTL ograniczają przestarzałość, ale zwiększają koszt ponownego pobierania. Utrwalanie migawki pozwala zachować deterministyczne renderowanie, jednocześnie nadal odświeżając okna świeżości.
Przywołanie a precyzja w pobieraniu: szersze pobieranie może zwiększać pokrycie, ale wprowadza szum; filtr relewancji drugiego etapu chroni jakość twierdzeń.
Ścisłość schematu a płynność wypowiedzi: ścisłe schematy wyjścia poprawiają niezawodność maszynową, ale mogą ograniczać swobodę stylu. Wzorzec answer-first zachowuje czytelność, jednocześnie utrzymując zabezpieczenia.
Szybkość renderowania statycznego a audytowalność: wstępnie renderowany HTML poprawia wydajność dostarczania i redukuje wielokrotne obliczenia, ale tylko wtedy, gdy użyte artefakty źródłowe są niezmiennymi odniesieniami.
Złożoność a koszt operacyjny: każdy dodatkowy krok walidacji (sprawdzanie źródeł, walidacja schematu, utrwalanie artefaktów) zwiększa opóźnienie. Ważna jest praktyczna dokumentacja produkcyjna dotycząca buforowania, granic tras i weryfikacji w czasie budowania, aby system pozostawał wykonalny operacyjnie.

Tryby awarii

Dryf źródeł: adresy URL zwracają 404/miękkie zmiany po utworzeniu zadania. Łagodzenie: klucz kanoniczny + hash migawki + łańcuch zapasowych źródeł.
Nadmierne pobieranie: wysokie przywołanie przy niskiej precyzji powoduje wiarygodną, ale niepodpartą syntezę. Łagodzenie: wymuszaj ograniczenia evidence-first i blokuj twierdzenia bez dopasowanych źródeł.
Awaria formatowania modelu: niezgodność schematu lub obcięty JSON z generacji. Łagodzenie: ścisła walidacja schematu i ponowna próba z węższym kontekstem.
Rywalizacja podwójnej publikacji: równolegli pracownicy mogą publikować częściowe artefakty. Łagodzenie: klucze idempotentne zadania, przejścia stanów na poziomie wiersza (pending -> drafting -> validated -> published).
Regresje renderowania: niepoprawny markdown albo niebezpieczne transformacje HTML. Łagodzenie: deterministyczna marked ścieżka konwersji i testy wyjścia HTML powiązane z manifestami próbki.
Iluzje buforowania: dynamiczne, przestarzałe dane po stronie serwera mogą powodować rozjazd opublikowanego tekstu i indeksu źródeł. Łagodzenie: dopasowanie strategii renderowania tras do jawnej polityki świeżości w czasie wykonania i unikanie domyślnych buforów tam, gdzie wymagana jest świeżość dowodów.

Notatki wdrożeniowe

Dla praktycznego wdrożenia potraktuj to jako kontrakt publikacyjny:

Zdefiniuj tabele źródeł w Drizzle z wyraźnymi ograniczeniami: unikalność URL według kanonicznego hosta/ścieżki, enumy statusu pobierania i kolumny sum kontrolnych.
Konsystentnie używaj ścieżki sterownika zgodnej z Neon pod kątem zachowania serverless; dokumentacja Drizzle opisuje zarówno opcje specyficzne dla runtime'u, jak i neon-* opcje sterownika.
W generowaniu egzekwuj kontrakty ustrukturyzowanego wyjścia i odrzucaj nieprawidłowe obiekty przed renderowaniem.
Korzystaj z wytycznych produkcyjnych Next.js dla granic serwera, stron błędów, buforowania i metadanych SEO dla tras artykułów, aby publikacja pozostawała widoczna i szybka.
Przechowuj wygenerowane bloby (np. obrazki okładki, załączniki, eksporty) przez Vercel Blob z wyraźną polityką dostępu i deterministyczną nazwą, aby uniknąć kolizji.
Emituj kontrole operacyjne przed publikacją: minimalna liczba źródeł, minimalna różnorodność źródeł, świeżość dowodów i minimalny wskaźnik ukończenia przypisanych twierdzeń.

To kluczowa zmiana: artykuł nie jest już oceniany pod kątem sprytu modelu; oceniana jest natomiast zgodność dowodów i generacji podczas ponownych prób i redeploy.