Інженерні нотатки Naly: написання статей із доповненням через пошук і збереженими джерелами

Анотація

Генерація з доповненням через пошук дає статейному конвеєру Naly дослідницьку пам’ять, свіжішу й придатнішу до аудиту, ніж самі лише ваги моделі. Для кожної інженерної нотатки або статті з ринкової аналітики система може шукати в інтернеті та arXiv, зберігати URL джерел разом зі згенерованим артефактом, просити модель спершу дати відповідь і рендерити результат як HTML. Сенс не в автоматизації заради автоматизації; сенс у публікації тверджень, які читачі можуть простежити.

Теза проста: RAG для написання статей слід розглядати як виробничу систему доказів, а не як шаблон чатбота. Чатботу можна пробачити слабку відповідь; опублікована стаття стає довговічною поверхнею довіри. Тому реалізація Naly потребує трьох інваріантів: пошук перед чернеткою, записи джерел, які зберігаються після публікації, і рендерер, що зберігає читабельний Markdown, уникаючи небезпечного HTML.

Де це розташовано в Naly

Статейні завдання Naly розташовані між здобуттям досліджень і публічним публікуванням. Завдання починається з вибраної теми, генерує пошукові наміри, отримує матеріали з вебу та arXiv, нормалізує результати в записи джерел, а потім просить модель написати статтю, орієнтовану на відповідь, із цього обмеженого набору доказів. Вихід — це не просто проза. Це пакет: Markdown-вміст, відрендерений HTML, URL джерел, назви джерел, типи джерел і достатньо метаданих, щоб пояснити, чому було використано кожне джерело.

Це важливо для циклу довіри Naly. Ширша редакційна позиція Naly — публікувати те, що інші приховують: службові записки щодо рішень, межі калібрування, невдачі та докази за твердженнями. Генерація з опорою на джерела робить цю позицію операційною. Читачі не повинні гадати, чи твердження походить із тренувальних даних моделі, офіційного документа, статті чи заяви оператора.

Шар RAG має бути перед написанням чернетки, а не після нього. Постфактумне додавання цитувань слабше, бо модель уже сформувала твердження. У сильнішому дизайні пошук обмежує контекст генерації, а генерація продукує твердження, які можна перевірити щодо знайденого набору. Видима стаття може залишатися стислою, але збережений артефакт має утримувати дослідницький слід.

Технічний механізм

Для написання статей RAG-потік Naly є пакетним конвеєром:

Вибір теми створює обмежене дослідницьке питання, наприклад як генерація з доповненням через пошук обґрунтовує написання статей з опорою на джерела.
Планування запитів розширює це питання на вебзапити, запити до офіційних документів і запити arXiv.
Пошук збирає офіційну документацію, первинні статті та пояснювальні джерела з високим сигналом.
Нормалізація витягує назву, канонічний URL, тип джерела, контекст публікації або оновлення, коли він доступний, і релевантні фрагменти або анотації.
Збереження джерел записує реєстр URL перед генерацією, щоб статтю можна було перевірити пізніше.
Складання промпта дає моделі тему, факти реалізації, специфічні для Naly, обмеження письма та знайдені докази.
Генерація створює Markdown з анотацією, що спершу дає відповідь, явними режимами відмови та розділом посилань.
Валідація перевіряє, що кожне посилання у відрендереній статті відповідає збереженому об’єкту джерела.
Рендеринг перетворює Markdown на HTML для сайту, застосовуючи санітизацію та виробничі перевірки.

Це близько до шаблону пошуку та доповненої генерації, описаного в посібнику Vercel з RAG: спершу знайти релевантний контекст, а потім поєднати його з питанням користувача або завдання перед генерацією. Різниця в тому, що Naly оптимізує не розмовну підтримку. Вона оптимізує довговічну публікацію, де URL джерела є частиною моделі даних статті.

AI SDK є природним шаром оркестрації для такого типу завдань, оскільки його інтерфейс генерації тексту підтримує неінтерактивну автоматизацію, виклики інструментів, багатоетапні результати та метадані джерел, коли провайдери повертають URL-джерела. Навіть коли провайдер не повертає нативні об’єкти джерел, Naly може прикріпити власний список знайдених джерел до артефакту статті й розглядати нативні джерела моделі як додаткові, а не авторитетні.

Що говорить література

Початкове формулювання RAG у Lewis et al. добре окреслило ключову проблему: параметричні мовні моделі зберігають факти у вагах, але оновлення цих знань і надання походження залишаються складними. Їхня модель із доповненням через пошук поєднала послідовнісну модель із щільним векторним індексом і виявила більш конкретну, різноманітну та фактичну генерацію, ніж параметрична базова модель, у завданнях, насичених знаннями.

Пізніший огляд RAG від Gao et al. узагальнює цю ідею в таксономію: наївний RAG, просунутий RAG і модульний RAG. Статейний конвеєр Naly має бути модульним. Пошук, ранжування, збереження джерел, побудова промпта, генерація, валідація посилань і рендеринг — це окремі блоки з окремими режимами відмови. Розгляд їх як окремих блоків полегшує налагодження системи, коли стаття цитує слабке джерело або пропускає краще.

Self-RAG додає важливе застереження. Asai et al. стверджують, що отримання фіксованої кількості уривків незалежно від того, чи потрібен пошук, може погіршувати якість результату. Для Naly це означає, що top-k retrieval не має бути ритуалом. Коротка стаття про стабільну функцію фреймворку може потребувати офіційної документації та однієї статті; літературно насичена стаття може потребувати кількох джерел arXiv і огляду. Глибина пошуку має відповідати ризику тверджень.

RAGChecker дає урок оцінювання. Ru et al. стверджують, що RAG-системам потрібна детальна діагностика як пошуку, так і генерації, особливо для довгих відповідей. Для Naly одиницею оцінювання має бути не лише якість статті. Вона має включати повноту пошуку, релевантність джерел, підтримку тверджень, покриття посиланнями та те, чи непідтримані твердження прослизнули у фінальний Markdown.

Проєктні компроміси

Висока повнота проти низького шуму — центральний компроміс. Більший обсяг пошуку підвищує шанс знайти правильне джерело, але також збільшує шанс, що слабкі фрагменти потраплять у промпт і скерують модель. Naly слід віддавати перевагу поетапному підходу: широке збирання, сувора фільтрація, потім компактний контекст промпта.

Збереження джерел покращує придатність до аудиту, але також створює роботу зі зберігання й підтримки. URL змінюються, статті переглядаються, а сторінки документації переміщуються. Довговічний запис має включати канонічний URL, час отримання, назву, тип джерела й бажано дайджест вмісту або межу уривка. Це дає Naly змогу відрізнити помилку моделі від зміненого джерела.

Письмо, що спершу дає відповідь, підвищує цінність для читача, але може надто агресивно стискати невизначеність. Стаття має починатися з висновку, зберігаючи пізніший розділ для режимів відмови та застережень. Підсумок, орієнтований на відповідь, є точкою входу; це не дозвіл сплощувати докази.

Відрендерений HTML покращує дистрибуцію та досвід читання, але створює межу безпеки. Marked швидкий і корисний для парсингу Markdown, але його документація прямо попереджає, що він не санітизує вихідний HTML. Рендерер статей Naly має санітизувати згенерований HTML і зберігати довірене джерело Markdown доступним для повторного відтворення.

Режими відмови

Промах пошуку: пошуковий крок знаходить правдоподібні, але неповні джерела. Зазвичай це трапляється, коли планувальник запитів надто вузький або використовує продуктові терміни, що відрізняються від літературних. Пом’якшення: використовувати кілька стилів запитів, включати офіційну документацію та вимагати щонайменше два первинні або arXiv-джерела, коли стаття робить дослідницькі твердження.

Відмивання цитувань: джерело з’являється в посиланнях, але насправді не підтримує речення поруч із ним. Це гірше, ніж відсутність цитування, бо створює хибну впевненість. Пом’якшення: перевіряти твердження щодо фрагментів джерел і відхиляти статті, де посилання лише тематичні.

Дрейф застарілого джерела: сторінка офіційної документації змінюється після публікації. Пом’якшення: зберігати метадані джерела під час генерації та записувати мітку дати. Для джерел, що підтримують основні твердження, зберігати знімок або дайджест там, де це дозволяє ліцензування.

Надмірний пошук: забагато фрагментів змушують модель підсумовувати контекст замість відповідати на тезу статті. Пом’якшення: використовувати ранжування джерел, дедуплікувати майже ідентичні документи та обмежувати докази в промпті за релевантністю до тверджень, а не за сирою кількістю.

Отруєння контексту: спам-сторінки, згенеровані SEO-сторінки або низькоякісні підсумки випереджають первинні матеріали. Пом’якшення: ранжувати офіційну документацію, arXiv, стандарти та репозиторії джерел вище за вторинні коментарі, якщо стаття не є явно про реакцію індустрії.

Ризик рендерера: згенерований Markdown може містити сирий HTML, небезпечні посилання або неправильно сформовані таблиці. Пом’якшення: санітизувати відрендерений HTML, нормалізувати посилання, відхиляти скриптовий вміст і запускати виробничі перевірки, узгоджені з настановами Next.js щодо продуктивності, безпеки, метаданих і доступності.

Нотатки щодо реалізації

З огляду на поточні факти середовища виконання Naly, чиста архітектура — це TypeScript-завдання, яке використовує ai@6.0.0-beta.105 для оркестрації моделі, інструменти веб- і arXiv-пошуку для збирання доказів, Drizzle ORM з Neon для записів статей і джерел, marked@17.0.1 для рендерингу Markdown-to-HTML і Next.js 16 для публікаційної поверхні.

База даних має розглядати джерела як рядки першого класу, а не як blob Markdown-тексту. Практична схема має таблицю статей, таблицю зв’язку стаття-джерело та поля джерела для URL, назви, типу джерела, часу отримання, канонічного ідентифікатора, такого як arXiv ID, коли він доступний, і статусу витягування. Тоді запис статті може вказувати на Markdown, відрендерений HTML, підсумок, ключові пункти та публікаційні метадані.

Vercel Blob корисний для більших артефактів або незмінних результатів рендерингу, тоді як Postgres залишається кращим як запитуваний реєстр для джерел і метаданих статей. Такий поділ здешевлює аудиторські запити: перелічити кожну статтю, що використала джерело, кожне джерело, використане статтею, і кожну статтю, де витягування джерел завершилося невдачею.

Промпт генератора має вимагати дисципліни джерел у формі виходу: жодних непідтриманих тверджень, жодних вигаданих URL і розділ посилань, чиї лінки мають збігатися зі збереженим списком джерел. Модель може писати плавну прозу, але завдання має володіти правдою про джерела. Якщо модель видає посилання, яке не було знайдено, валідатор має провалити статтю, а не тихо її опублікувати.

Нарешті, виробнича поведінка має значення. Next.js уже надає серверні компоненти, code splitting, prerendering і стандартні налаштування кешування, але конвеєри згенерованого контенту все одно потребують явної обробки помилок, перевірок безпеки, метаданих і уваги до Core Web Vitals. RAG допомагає Naly писати з доказами. Виробнича інженерія гарантує, що ці докази доходять до читачів швидко, безпечно й повторювано.