«Напомним, ранее…»: зачем мы вернули RAG, от которого сами отказались

Мы строим Рерайт-Завод – AI-систему для автоматизации рерайта новостей в региональных СМИ. Основная задача – автоматизировать все тупые бессмысленные рерайты пресс-релизов и прочей обязаловки, чтобы журналисты занимались журналистикой, а не переписыванием ТАСС.

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

Теперь ожидаю видимо того же за этот пост. Он про то, что не делает ни один рерайт-сервис. И что отличает текст, написанный журналистом, от текста, написанного чатГПТ, за секунду, ведь именно столько времени проходит с момента чтения до крика «это же нейросеть написала!!»

Один абзац, который выдаёт машину

Откройте любой региональный новостной портал. Выберите новость про какой-нибудь ремонт какой-то дороги. С вероятностью 80% где-то в тексте будет:

Напомним, ранее администрация планировала завершить ремонт участка улицы Писькина до конца 2025 года. Работы были начаты в июне и заморожены в октябре из-за проблем с подрядчиком. Наш материал

Вот этот блок – бэк. Background, контекст, история вопроса. То, что превращает новость из просто голого факта в историю с продолжением. Журналист помнит, что его СМИ писало об этом три месяца назад, что подрядчик менялся дважды, а в комментариях было 237 разъярённых жителей. И добавляет бэк – потому что без него новость бессмысленна. Это не «ремонт дороги», а очередной провал ремонта дороги, и читатель должен это знать.

AI-рерайтер берёт текст из RSS и пересказывает, пусть даже в стиле этого СМИ, что уже как бы неплохо. Всё. У него нет памяти ^[1], архива, понимания, что издание уже три раза об этом писало. Текст формально правильный и абсолютно дохлый.

Именно поэтому редакторы, которые пробовали ChatGPT для рерайта, говорят одно и то же: «Текст нормальный, но какой-то… пустой». Он пустой не обязательно потому, что модель плохая. У нее просто нет контекста публикации.

Почему это сложная задача

Казалось бы, всё просто: загрузи весь архив издания в векторную базу, найди похожие статьи, вставь ссылку. Десять строчек кода, полдня работы.

Нет.

НЕТ 1: похожее не есть связанное. Статья про ремонт улицы Писькина семантически похожа на статью про ремонт проспекта Мира. Embeddings скажут – 0.89 similarity, отлично. Только это разные улицы, разные подрядчики, разные скандалы. Бэк, ссылающийся на другую улицу, хуже, чем вообще без бэка.

НЕТ 2: релевантность по времени. Статья про ту же дорогу, но от 2019 года – это не контекст, а археология. Бэк должен быть свежим. Но свежий – тоже понятие относительное. Для новости про губернатора бэк годичной давности нормален. Для новости про погоду – нет.

НЕТ 3: у издания нет архива в машиночитаемом виде. Мы общались с десятками редакций. У большинства региональных порталов нет даже нормального экспорта статей. CMS старые, API нет, выгрузка только вручную по одной. Некоторые до сих пор на WordPress 4.x, где REST API выключен из соображений безопасности. Некоторые говорят про авторское право. Тупик, короче.

Как мы к этому подходили (и почему RAG вернулся)

В первой статье я писала, как наш разработчик убедил меня отказаться от RAG для обучения ^[2] стилю. Его аргумент был простой: семантическая близость это как бэ не стилистическая близость. Стиль одинаковый во всех текстах издания (в пределах одной платформы хотя бы), искать похожие по смыслу для обучения стилю – бессмысленно.

Он был прав. Для стиля – бессмысленно. Но для бэков наоборот. Тут нам нужна именно семантическая близость. Вот есть новость про ремонт улицы Писькина: надо найти предыдущие статьи про ремонт улицы Писькина. Новость про нового главу района – найти, что писали про предыдущего. Это ровно то, для чего эмбеддинги и создавались.

Разработчик, когда я пришла с этой идеей: «Ну вот тут – да. Тут вектора реально нужны. Только не для стиля, а для контента. Разные задачи – разные инструменты.»

Перекрестилась, что он не сказал «я же говорил». Сказал: задача другая – инструмент другой. Инженерный подход без эго.

Архитектура: три агента вместо одного

Бэк – это настоящее мини-расследование: что писали раньше? Что из этого важно сейчас? Как это сформулировать в одном абзаце? Мы разбили задачу на трёх агентов:

Три агента, а не один – зачем борщите?

Потому что одному агенту нельзя доверить всю цепочку, точно облажается. Мы это проверяли. Даёшь модели задачу «найди связанные статьи и сгенерируй бэк» – она находит что-то отдалённо похожее и радостно генерирует бэк. Даже если связь натянута и вообще статья про другой объект. Модели хочется быть полезной. А нам нужна точность.

Разделение на поиск – фильтрацию – генерацию позволяет на каждом шаге контролировать качество. Если агент поиска нашёл 5 кандидатов, а агент фильтрации отбросил все 5 – бэка не будет. И это правильный результат, нежели выдать лажу.

Embeddings: что работает, а что нет

Для эмбеддингов мы используем text-embedding-3-small от OpenAI. Не потому что это лучшая модель для русского текста (это не так). Просто это:

• Дёшево – $0.02 за миллион токенов.

• Быстро – batch embedding 1000 статей за пару минут.

• Достаточно хорошо для нашей задачи.

Пробовали text-embedding-3-large. Разница в качестве для русского текста – процентов 5–7 по нашим тестам. Разница в цене х6,5. Не стоит.

Что мешает: русский текст с географическими названиями. Терминаторы пока не различают «Гатчина» и «Гатчинский округ». Для новостного контекста это критично – новость про город и новость про округ могут быть совершенно разными историями. Поэтому агент поиска работает в два прохода: сначала извлекает сущности (NER) и фильтрует по точному совпадению, а потом уже дополняет семантическим поиском.

Порог similarity: 0.82. Подобрали эмпирически на 500 парах «новость – бэк». Ниже 0.82 – слишком много мусора. Выше 0.87 – пропускаем релевантные статьи, где формулировки немного отличаются. Золотая середина зависит от издания: у кого-то архив однородный, у кого-то каша из новостей и портянок. Но 0.82 работает как дефолт.

Проблема архива (она же проблема курицы и яйца)

Бэки работают, когда у издания есть архив в векторной базе. Архив появляется, когда издание загружает статьи. Издание загружает статьи, когда видит результат. Результат видно, когда работают бэки.

Мы решаем это так:

При подключении парсим сайт клиента: система обходит архив издания и вытягивает статьи в векторную базу. Если CMS закрыта или нет открытого RSS, клиент может загрузить выборку вручную. Обычно достаточно 500-700 материалов. Это база для обучения стилю (так было и раньше). Эти же статьи идут в векторную базу для бэков. Две задачи – одна загрузка. Мало, но с чего-то надо начинать.

В процессе работы каждый сгенерированный и опубликованный рерайт тоже попадает в архив. База растёт органически. Через месяц работы у издания, которое публикует 15 новостей в день, в базе уже +450 текстов. Через три месяца +1300. Бэки становятся точнее с каждым днём.

Холодный старт – первые 2–3 недели. Бэков мало, потому что база тонкая. Но мы не станем генерировать фейковые бэки, чтобы «показать возможности». Если релевантной статьи нет – бэка не будет. В зону развития положили возможность генерить бэки из других источников.

Зачем это вообще нужно в цифрах

Можно было бы написать «бэки делают текст более профессиональным» и остановиться. Но само по себе это бессмысленное утверждение. Профессиональным – он для кого вообще?

Для читателя: бэк даёт контекст, без которого новость непонятна. «Возобновили ремонт» – ну и что? А «возобновили ремонт, который заморозили полгода назад после скандала с подрядчиком» – это уже норм история. Читатель остаётся на странице дольше, дочитываемость растет. По нашим тестам на трёх изданиях, средняя глубина прочтения статей с бэками где-то на 23% выше.

Для SEO: бэк содержит внутреннюю ссылку на предыдущий материал. Это перелинковка, которую так любят поисковики. Редакции, которые делают бэки вручную, получают лучшее ранжирование.

Для редактора: не нужно вспоминать ^[3] «а мы об этом писали?» и лезть в архив. Система находит сама. Экономия – 3–5 минут на материал. При 15 материалах в день – час. При 20 рабочих днях – 20 часов в месяц. Это не мелочь.

Для бизнеса издания: бэк со ссылкой – это повторный трафик на старый контент. Мы видели рост pageviews на 8–12% у изданий, которые системно делают бэки. Больше pageviews – больше показов рекламы – больше денег. Как раз что нам всем надо.

Кстати, идею о бэках мне изначально подсказал Виталий Алексеев, шеф-редактор Делового Петербурга, за что ему большое спасибо.

ChatGPT не знает стиль издания, не проверяет факты по источнику, не помнит, что СМИ писало вчера. Его задача – сгенерировать текст по запросу. А задача инструмента для редакции – сгенерировать текст, который можно опубликовать. Разница – как между ножом и скальпелем. Режут оба, но в операционную с кухонным не пускают.

В марте выходим на бета-тест, есть очередь @rewritefact ^[4]

Лена Богданова – основатель Рерайт-Завода, AI-системы для автоматизации рерайта новостей в региональных СМИ. Telegram: @lenabogdanovaaa ^[5]