Инженерные заметки Naly: написание статей с дополненной поиском генерацией и сохраненными источниками

Аннотация

Retrieval-augmented generation дает конвейеру статей Naly исследовательскую память, которая свежее и лучше поддается аудиту, чем одни только веса модели. Для каждой инженерной заметки или статьи о рыночной аналитике система может искать в вебе и arXiv, сохранять URL источников вместе со сгенерированным артефактом, просить модель сначала дать ответ и рендерить результат как HTML. Смысл не в автоматизации ради автоматизации, а в публикации утверждений, путь к которым читатели могут проследить.

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

Где это находится в Naly

Задачи по статьям Naly находятся между сбором исследований и публичной публикацией. Задача начинается с выбранной темы, генерирует поисковые намерения, получает материалы из веба и arXiv, нормализует результаты в записи источников, а затем просит модель написать статью с ответом в начале на основе этого ограниченного набора доказательств. Выход — это не только проза. Это пакет: Markdown-контент, отрендеренный HTML, URL источников, названия источников, типы источников и достаточно метаданных, чтобы объяснить, почему был использован каждый источник.

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

Слой RAG должен располагаться до черновика, а не после него. Постфактумное прикрепление цитат слабее, потому что модель уже сформировала утверждения. В более сильном дизайне поиск ограничивает контекст генерации, а генерация производит утверждения, которые можно проверить по найденному набору. Видимая статья может оставаться краткой, но сохраненный артефакт должен удерживать исследовательский след.

Технический механизм

Для написания статей RAG-поток Naly представляет собой пакетный конвейер:

Выбор темы создает ограниченный исследовательский вопрос, например о том, как retrieval-augmented generation обосновывает написание статей с опорой на источники.
Планирование запросов расширяет этот вопрос до веб-запросов, запросов к официальным документам и запросов в arXiv.
Поиск собирает официальную документацию, первичные статьи и объяснительные источники с высоким сигналом.
Нормализация извлекает название, канонический URL, тип источника, контекст публикации или обновления, когда он доступен, а также релевантные фрагменты или аннотации.
Сохранение источников записывает реестр URL до генерации, чтобы статью можно было позднее проверить.
Сборка промпта передает модели тему, факты реализации, специфичные для Naly, ограничения по письму и найденные доказательства.
Генерация создает Markdown с аннотацией, где ответ идет первым, явными режимами отказа и разделом источников.
Валидация проверяет, что каждая ссылка в отрендеренной статье сопоставляется с сохраненным объектом источника.
Рендеринг преобразует Markdown в HTML для сайта, применяя санитаризацию и производственные проверки.

Это близко к паттерну поиска и дополненной генерации, описанному в руководстве Vercel по RAG: сначала получить релевантный контекст, затем объединить его с вопросом пользователя или задачи перед генерацией. Разница в том, что Naly оптимизируется не под разговорную поддержку. Она оптимизируется под долговечную публикацию, где URL источника является частью модели данных статьи.

AI SDK — естественный слой оркестрации для такого типа задач, потому что его интерфейс генерации текста поддерживает неинтерактивную автоматизацию, вызовы инструментов, многошаговые результаты и метаданные источников, когда провайдеры возвращают URL-источники. Даже когда провайдер не возвращает нативные объекты источников, Naly может прикрепить собственный список найденных источников к артефакту статьи и рассматривать источники, нативные для модели, как дополнительные, а не авторитетные.

Что говорит литература

Оригинальная формулировка RAG у Lewis et al. хорошо описала ключевую проблему: параметрические языковые модели хранят факты в весах, но обновление этих знаний и предоставление происхождения остаются сложными. Их retrieval-augmented модель объединяла последовательностную модель с плотным векторным индексом и показала более конкретную, разнообразную и фактическую генерацию, чем параметрический базовый вариант, на задачах, требующих больших знаний.

Более поздний обзор RAG у Gao et al. обобщает эту идею в таксономию: naive RAG, advanced RAG и modular RAG. Конвейер статей Naly должен быть модульным. Поиск, ранжирование, сохранение источников, построение промпта, генерация, проверка ссылок и рендеринг — это отдельные блоки с отдельными режимами отказа. Рассмотрение их как отдельных блоков упрощает отладку системы, когда статья цитирует слабый источник или пропускает более подходящий.

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

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

Проектные компромиссы

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

Сохранение источников улучшает аудируемость, но также создает работу по хранению и сопровождению. URL меняются, статьи пересматриваются, страницы документации переезжают. Долговечная запись должна включать канонический URL, время получения, название, тип источника и, в идеале, digest контента или границы выдержки. Это позволяет Naly отличить ошибку модели от изменившегося источника.

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

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

Режимы отказа

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

Отмывание цитат: источник появляется в списке литературы, но фактически не поддерживает предложение рядом с ним. Это хуже, чем отсутствие цитаты, потому что создает ложную уверенность. Смягчение: проверять утверждения по фрагментам источников и отклонять статьи, где ссылки лишь тематически связаны.

Дрейф устаревшего источника: страница официальной документации меняется после публикации. Смягчение: сохранять метаданные источника во время генерации и записывать метку даты. Для источников, на которых держатся основные утверждения, хранить снимок или digest там, где это допускает лицензия.

Чрезмерный поиск: слишком много чанков заставляют модель пересказывать контекст, а не отвечать на тезис статьи. Смягчение: использовать ранжирование источников, дедуплицировать почти идентичные документы и ограничивать доказательства в промпте по релевантности утверждениям, а не по сырому количеству.

Отравление контекста: спам-страницы, сгенерированные SEO-страницы или низкокачественные пересказы ранжируются выше первичных материалов. Смягчение: ранжировать официальную документацию, arXiv, стандарты и репозитории исходного кода выше вторичных комментариев, если статья явно не посвящена реакции отрасли.

Риск рендерера: сгенерированный Markdown может включать сырой HTML, небезопасные ссылки или некорректно сформированные таблицы. Смягчение: санитизировать отрендеренный HTML, нормализовать ссылки, отклонять исполняемый контент и выполнять производственные проверки, согласованные с рекомендациями Next.js по производительности, безопасности, метаданным и доступности.

Заметки по реализации

С учетом текущих runtime-фактов Naly чистая архитектура — это TypeScript-задача, которая использует ai@6.0.0-beta.105 для оркестрации модели, инструменты веб- и arXiv-поиска для сбора доказательств, Drizzle ORM с Neon для записей статей и источников, marked@17.0.1 для рендеринга Markdown в HTML и Next.js 16 для публикационной поверхности.

База данных должна рассматривать источники как строки первого класса, а не как blob Markdown-текста. Практичная схема включает таблицу статей, join-таблицу article-source и поля источника для URL, названия, типа источника, времени получения, канонического идентификатора, такого как arXiv ID, когда он доступен, и статуса извлечения. Затем запись статьи может указывать на Markdown, отрендеренный HTML, сводку, ключевые пункты и метаданные публикации.

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

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

Наконец, производственное поведение имеет значение. Next.js уже предоставляет server components, code splitting, prerendering и настройки кэширования по умолчанию, но конвейерам сгенерированного контента все равно нужны явная обработка ошибок, проверки безопасности, метаданные и внимание к Core Web Vitals. RAG помогает Naly писать с доказательствами. Production engineering гарантирует, что эти доказательства доходят до читателей быстро, безопасно и снова и снова.