Notatki inżynieryjne Naly: pisanie artykułów wspomagane wyszukiwaniem z trwale zapisanymi źródłami

Abstrakt

Generowanie wspomagane wyszukiwaniem daje pipeline'owi artykułów Naly pamięć badawczą świeższą i bardziej audytowalną niż same wagi modelu. Dla każdego zadania dotyczącego notatki inżynieryjnej lub artykułu market-intelligence system może przeszukać web i arXiv, zachować URL-e źródeł wraz z wygenerowanym artefaktem, poprosić model, by najpierw odpowiedział, a następnie wyrenderować wynik jako HTML. Nie chodzi o automatyzację dla niej samej; chodzi o publikowanie twierdzeń, które czytelnicy mogą prześledzić.

Teza jest prosta: RAG w pisaniu artykułów należy traktować jako produkcyjny system dowodowy, a nie jako wzorzec chatbota. Chatbotowi można wybaczyć słabą odpowiedź; opublikowany artykuł staje się trwałą powierzchnią zaufania. Implementacja Naly potrzebuje więc trzech niezmienników: wyszukiwania przed szkicowaniem, rekordów źródeł, które przetrwają po publikacji, oraz renderera, który zachowuje czytelny Markdown, unikając niebezpiecznego HTML.

Gdzie mieści się to w Naly

Zadania artykułowe Naly znajdują się między pozyskiwaniem badań a publiczną publikacją. Zadanie zaczyna się od wybranego tematu, generuje intencje wyszukiwania, pobiera materiały z webu i arXiv, normalizuje wyniki do rekordów źródeł, a następnie prosi model o napisanie artykułu typu answer-first na podstawie tego ograniczonego zestawu dowodów. Wynikiem nie jest sama proza. To pakiet: treść Markdown, wyrenderowany HTML, URL-e źródeł, tytuły źródeł, typy źródeł i wystarczająco dużo metadanych, by wyjaśnić, dlaczego użyto każdego źródła.

Ma to znaczenie dla pętli zaufania Naly. Szersza postawa redakcyjna Naly polega na publikowaniu tego, co inni ukrywają: notatek decyzyjnych, ograniczeń kalibracji, porażek i dowodów stojących za twierdzeniami. Generowanie oparte na źródłach operacjonalizuje tę postawę. Czytelnicy nie powinni musieć zgadywać, czy dane stwierdzenie pochodzi z danych treningowych modelu, oficjalnego dokumentu, artykułu naukowego czy twierdzenia operatora.

Warstwa RAG powinna znajdować się przed szkicowaniem, nie po nim. Późniejsze dopinanie cytowań jest słabsze, ponieważ model już sformułował twierdzenia. W mocniejszym projekcie wyszukiwanie ogranicza kontekst generowania, a generowanie wytwarza twierdzenia, które można sprawdzić względem pobranego zestawu. Widoczny artykuł może pozostać zwięzły, ale zapisany artefakt powinien zachować ślad badawczy.

Mechanizm techniczny

W przypadku pisania artykułów przepływ RAG Naly jest pipeline'em wsadowym:

Wybór tematu tworzy ograniczone pytanie badawcze, na przykład jak generowanie wspomagane wyszukiwaniem osadza pisanie artykułów opartych na źródłach.
Planowanie zapytań rozwija to pytanie w zapytania webowe, zapytania do oficjalnych dokumentów i zapytania do arXiv.
Wyszukiwanie zbiera oficjalną dokumentację, podstawowe prace naukowe i źródła objaśniające o wysokim sygnale.
Normalizacja wyodrębnia tytuł, kanoniczny URL, typ źródła, kontekst publikacji lub aktualizacji, gdy jest dostępny, oraz istotne fragmenty albo abstrakty.
Trwałe zapisywanie źródeł przechowuje rejestr URL-i przed generowaniem, aby artykuł można było później audytować.
Składanie promptu przekazuje modelowi temat, fakty implementacyjne specyficzne dla Naly, ograniczenia pisarskie i pobrane dowody.
Generowanie tworzy Markdown z abstraktem typu answer-first, jawnymi trybami awarii i sekcją referencji.
Walidacja sprawdza, czy każda referencja w wyrenderowanym artykule mapuje się na zapisany obiekt źródła.
Renderowanie konwertuje Markdown do HTML na potrzeby strony, stosując przy tym sanityzację i kontrole produkcyjne.

Jest to bliskie wzorcowi wyszukiwania i generowania rozszerzonego opisanemu w przewodniku RAG Vercel: najpierw pobierz odpowiedni kontekst, a następnie połącz go z pytaniem użytkownika lub zadania przed generowaniem. Różnica polega na tym, że Naly nie optymalizuje pod wsparcie konwersacyjne. Optymalizuje pod trwałą publikację, w której URL źródła jest częścią modelu danych artykułu.

AI SDK jest naturalną warstwą orkiestracji dla tego rodzaju zadania, ponieważ jego interfejs generowania tekstu wspiera nieinteraktywną automatyzację, wywołania narzędzi, wyniki wieloetapowe i metadane źródeł, gdy dostawcy zwracają źródła URL. Nawet gdy dostawca nie zwraca natywnych obiektów źródłowych, Naly może dołączyć własną listę pobranych źródeł do artefaktu artykułu i traktować źródła natywne modelu jako uzupełniające, a nie autorytatywne.

Co mówi literatura

Oryginalne ujęcie RAG autorstwa Lewisa i in. dobrze sformułowało podstawowy problem: parametryczne modele językowe przechowują fakty w wagach, ale aktualizowanie tej wiedzy i zapewnianie proweniencji pozostają trudne. Ich model wspomagany wyszukiwaniem połączył model sekwencyjny z gęstym indeksem wektorowym i uzyskał bardziej konkretne, zróżnicowane oraz faktograficzne generowanie niż bazowy wariant wyłącznie parametryczny w zadaniach wymagających dużej wiedzy.

Późniejszy przegląd RAG autorstwa Gao i in. uogólnia tę ideę do taksonomii: naiwny RAG, zaawansowany RAG i modułowy RAG. Pipeline artykułów Naly powinien być modułowy. Wyszukiwanie, ranking, trwałe zapisywanie źródeł, konstrukcja promptu, generowanie, walidacja referencji i renderowanie to osobne jednostki z osobnymi trybami awarii. Traktowanie ich jako osobnych jednostek ułatwia debugowanie systemu, gdy artykuł cytuje słabe źródło albo pomija lepsze.

Self-RAG dodaje ważne zastrzeżenie. Asai i in. argumentują, że pobieranie stałej liczby fragmentów niezależnie od tego, czy wyszukiwanie jest potrzebne, może pogarszać jakość wyniku. Dla Naly oznacza to, że wyszukiwanie top-k nie powinno być rytuałem. Krótki artykuł o stabilnej funkcji frameworka może potrzebować oficjalnej dokumentacji i jednej pracy; artykuł mocno oparty na literaturze może potrzebować wielu źródeł z arXiv i przeglądu. Głębokość wyszukiwania powinna wynikać z ryzyka twierdzeń.

RAGChecker daje lekcję ewaluacyjną. Ru i in. argumentują, że systemy RAG potrzebują drobnoziarnistej diagnostyki zarówno w wyszukiwaniu, jak i generowaniu, zwłaszcza dla długich odpowiedzi. Dla Naly jednostką ewaluacji nie powinna być wyłącznie jakość artykułu. Powinna obejmować recall wyszukiwania, trafność źródeł, wsparcie twierdzeń, pokrycie referencji oraz to, czy niepoparte twierdzenia przedostały się do finalnego Markdown.

Kompromisy projektowe

Wysoki recall kontra niski szum to centralny kompromis. Szersze wyszukiwanie zwiększa szansę znalezienia właściwego źródła, ale zwiększa też ryzyko, że słabe fragmenty trafią do promptu i ukierunkują model. Naly powinno preferować podejście etapowe: szerokie zebranie, ścisłe filtrowanie, a następnie zwarty kontekst promptu.

Trwałe zapisywanie źródeł poprawia audytowalność, ale tworzy też pracę związaną ze storage'em i utrzymaniem. URL-e dryfują, prace są rewidowane, a strony dokumentacji się przenoszą. Trwały rekord powinien zawierać kanoniczny URL, znacznik czasu pobrania, tytuł, typ źródła i najlepiej digest treści albo granicę excerptu. To pozwala Naly odróżnić błąd modelu od zmienionego źródła.

Pisanie typu answer-first zwiększa wartość dla czytelnika, ale może zbyt agresywnie kompresować niepewność. Artykuł powinien zaczynać się od wniosku, zachowując późniejszą sekcję na tryby awarii i zastrzeżenia. Podsumowanie answer-first jest punktem wejścia; nie jest licencją na spłaszczenie dowodów.

Wyrenderowany HTML poprawia dystrybucję i doświadczenie czytania, ale tworzy granicę bezpieczeństwa. Marked jest szybki i użyteczny do parsowania Markdown, ale jego dokumentacja wyraźnie ostrzega, że nie sanityzuje wynikowego HTML. Renderer artykułów Naly powinien sanityzować wygenerowany HTML i zachowywać zaufane źródło Markdown dostępne do odtworzenia.

Tryby awarii

Chybione wyszukiwanie: etap wyszukiwania znajduje wiarygodnie wyglądające, ale niepełne źródła. Zwykle dzieje się tak, gdy planer zapytań jest zbyt wąski albo używa terminów produktowych różniących się od literatury. Mitygacja: używać wielu stylów zapytań, uwzględniać oficjalną dokumentację i wymagać co najmniej dwóch źródeł pierwotnych lub arXiv, gdy artykuł formułuje twierdzenia badawcze.

Pranie cytowań: źródło pojawia się w referencjach, ale faktycznie nie wspiera zdania obok niego. To gorsze niż brak cytowania, ponieważ tworzy fałszywą pewność. Mitygacja: walidować twierdzenia względem fragmentów źródeł i odrzucać artykuły, w których referencje są jedynie tematyczne.

Dryf nieaktualnych źródeł: oficjalna strona dokumentacji zmienia się po publikacji. Mitygacja: utrwalić metadane źródła w momencie generowania i zapisać etykietę daty. Dla źródeł napędzających główne twierdzenia przechowywać snapshot lub digest tam, gdzie pozwala na to licencja.

Nadmierne wyszukiwanie: zbyt wiele chunków sprawia, że model streszcza kontekst zamiast odpowiedzieć na tezę artykułu. Mitygacja: używać rankingu źródeł, deduplikować niemal identyczne dokumenty i ograniczać dowody w prompcie według trafności wobec twierdzeń, a nie surowej liczby.

Zatrucie kontekstu: strony spamowe, generowane strony SEO lub niskiej jakości streszczenia wyprzedzają materiały pierwotne. Mitygacja: klasyfikować oficjalną dokumentację, arXiv, standardy i repozytoria źródłowe wyżej niż komentarze wtórne, chyba że artykuł wyraźnie dotyczy odbioru branżowego.

Ryzyko renderera: wygenerowany Markdown może zawierać surowy HTML, niebezpieczne linki lub wadliwe tabele. Mitygacja: sanityzować wyrenderowany HTML, normalizować linki, odrzucać treści skryptowalne i uruchamiać kontrole produkcyjne zgodne z wytycznymi Next.js dotyczącymi wydajności, bezpieczeństwa, metadanych i dostępności.

Notatki implementacyjne

Biorąc pod uwagę obecne fakty runtime Naly, czysta architektura to zadanie TypeScript, które używa ai@6.0.0-beta.105 do orkiestracji modelu, narzędzi wyszukiwania webowego i arXiv do zbierania dowodów, Drizzle ORM z Neon do rekordów artykułów i źródeł, marked@17.0.1 do renderowania Markdown do HTML oraz Next.js 16 jako powierzchni publikacji.

Baza danych powinna traktować źródła jako pełnoprawne wiersze, a nie jako blob tekstu Markdown. Praktyczny schemat ma tabelę artykułów, tabelę łączącą artykuły ze źródłami oraz pola źródła dla URL-a, tytułu, typu źródła, znacznika czasu pobrania, kanonicznego identyfikatora, takiego jak arXiv ID, gdy jest dostępny, i statusu ekstrakcji. Rekord artykułu może następnie wskazywać na Markdown, wyrenderowany HTML, podsumowanie, kluczowe punkty i metadane publikacji.

Vercel Blob jest użyteczny dla większych artefaktów lub niemutowalnych wyników renderowania, podczas gdy Postgres pozostaje lepszy jako przeszukiwalny rejestr źródeł i metadanych artykułów. To rozdzielenie utrzymuje niskie koszty zapytań audytowych: lista każdego artykułu, który użył danego źródła, każdego źródła użytego przez artykuł i każdego artykułu, w którym ekstrakcja źródła się nie powiodła.

Prompt generatora powinien wymagać dyscypliny źródłowej w kształcie wyniku: bez niepopartych twierdzeń, bez wymyślonych URL-i oraz z sekcją referencji, której linki muszą pasować do utrwalonej listy źródeł. Model może pisać płynną prozą, ale zadanie powinno być właścicielem prawdy o źródłach. Jeśli model emituje referencję, której nie pobrano, walidator powinien oblać artykuł, zamiast po cichu go opublikować.

Na koniec znaczenie ma zachowanie produkcyjne. Next.js zapewnia już komponenty serwerowe, code splitting, prerendering i domyślne cache'owanie, ale pipeline'y generowanych treści nadal potrzebują jawnej obsługi błędów, kontroli bezpieczeństwa, metadanych i świadomości Core Web Vitals. RAG pomaga Naly pisać w oparciu o dowody. Inżynieria produkcyjna dopilnowuje, aby te dowody docierały do czytelników szybko, bezpiecznie i wielokrotnie.