RAG‑система для анализа новостей с позиций исторической личности на основе литературных источников «АЙ_Ленин»

Постановка задачи

Широкое распространение СМИ в сети привело к формированию группы тематических экспертов — лидеров общественного мнения — блогеров. Их задача — оценка и анализ фактов, подача информации через призму собственного мнения.

Закономерно, мысленное упражнение, как человек, оставивший след в истории, оценил бы тот или иной современный факт.

Первичные определения: 

• Интеллект — реакция организма на раздражители.

• Поведение — ответ организма на раздражители исходя индивидуальных когнитивных и биологических особенностей и накопленного опыта. 

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

Единственный доступный источник информации — информационное наследие, которое оставил человек: совокупность статей, книг, переписки, стенограмм выступлений, аудио и видео. 

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

Выбранная историческая личность В.И.Ленин — достаточно удобный источник информации. По ряду причин: 

• Изданное последователями полное собрание сочинений.

• Зафиксированная самим автором философская основа

• Сохранившиеся труды интеллектуальных и политических оппонентов.

Возможно сформировать RAG приемлемого качества. 

Почему RAG, а не fine‑tuning

Доступный технологический стек: 

• Разработка: CPU Ryzen 7 5800X / RAM 64 ГБ/ Диск 500 ГБ (SSD) / GPU RTX 4060 8ГБ

• VPS (prod): CPU 4 x 3.2 ГГц/ RAM 16 ГБ/ Диск 50 ГБ (SSD) 

Тезис: Малая LLM‑модель с достаточной программной обвязкой на узкоспециализированных задачах может показать результат, сопоставимый по качеству с большой LLM‑моделью.

В 25 году сформулировал идею и сделал первые эксперименты. На тот момент, перспективным казался fine‑tuning модели. За основу взял saiga‑mistral:7b‑lora‑q4_K, на моем аппаратном стеке эта модель показалась достаточно удачной.

Результат был слишком далёк от приемлемого: массовые галлюцинации, низкое качество ответа, придумывание цитат и самое неприятное — карикатурные одномерные ответы в духе «революция» или «эксплуатация».

Итог. Чувство стыда за результат, у пользователя формирование негативного отношения к проекту и создание отрицательного представления об исторической фигуре. 

Проект было решено отложить на неопределённый срок. 

В 26 году нашёл силы и желание вернуться к проекту с нуля.

AI Стек:

• DB — Qdrant.

• LLM Модель — Gigachat3-10b‑a1.8b

• Эмбединг модель — Giga‑Embeddings‑instruct. 

Обусловлен возможностью переиспользовать удачные решения на работе и архитектурными стандартами ПАО.

Начал с подготовки литературных источников. Всего работа с текстом сводится в трём этапам: 

Этап очистки. Удаляется типографский шум, номера томов и страниц.

Этап нарезки на чанки.

• Размер чанков: 256–512 токенов.

• Перекрытие между соседними чанками ~10%.

• Границы чанков соблюдаются с учётом структуры текста (главы, тезисы).

Этап разметки позиционными метками (онтологическими тегами).

Напомню, в источники литературы взяты тексты Автора, философская основа и оппозиция. Каждый чанк получает специальную метку, определяющую его роль.

Giga‑Embeddings‑instruct позволил использовать плотные векторы с размерностью 2048.

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

Плотные векторы используются в Qdrant не изолированно, а в составе гибридного поиска вместе BM25. Результаты разных подходов объединяются с помощью RRF. Результатом такого подхода стал качественный ответ по всему корпусу текстов.

Архитектура

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

офлайн контур

Предназначение офлайн контура — работа над литературными источниками, суть которой была описана выше.

Онлайн контур.

Онлайн контур

Источником информации служит RSS лента новостей — простейший и доступный формат. Парсер выполняет периодический опрос источника. Обработанные сообщения фиксируются в SQLite, повторные сообщения пропускаются. Выбор СУБД обусловлен ресурсами и пулом задач, применять что‑то большее — избыточно. 

Вновь опубликованные сообщения направляются в модуль цензурирования 

PreRagCensor. Задача модуля: сокращение обращений и экономия ресурсов. Отсеивается ряд тем, в том числе предотвращается генерация нежелательного контента. Модуль представляет собой многослойный контур, один из слоёв которого работает по принципу поиска подстрок в загруженных YAML‑словарях с тематическими наборами стоп‑слов, что позволяет производить «горячую перезагрузку» без перезапуска. Это сделано намеренно для строгого контроля над списком триггеров и имеет существенный недостаток — неполнота списков. Бывают нежелательные генерации.

Прошедшие цензуру сообщения направляются в модуль оркестрации. 

Диалектическа оркестрация.

В начале 19 века, Георг Вильгельм Фридрих Гегель в своём труде «Наука логики» (Wissenschaft der Logik) предложил метод триады (тезис — антитезис‑ синтез), который в последствии был использован Карлом Марксом и Владимиром Лениным. Суть метода: объединение двух противоположных понятий и какого‑либо третьего понятия, которое выражает внутреннее единство двух противоположных понятий.

Метод лёг в основу оркестратора в виде механизма R1–R3, который заставляет модель рассматривать вопрос с трех противоположных позиций, имитируя диалектический метод. В отличие от классической гегелевской триады, слоты R2 и R3 не являются строгим антитезисом и синтезом, а представляют поддерживающие и критические аргументы, что позволяет LLM синтезировать вывод на основе столкновения этих позиций.

Триада в проекте:

• R1 (тезис / core_self): Прямая позиция. Поиск прямых цитат Ленина (ПСС), формирующих основной аргумент по теме. Это обязательная опора для ответа.

• R2 (поддерживающая позиция / influence_agree): Вспомогательный аргумент. Источники, на которые Ленин опирался (Маркс, Гегель), которые развивают и укрепляют тезис.

• R3 (антитезис / influence_critical): Критическая позиция. Оппозиционные точки зрения, которые испытывают тезис на прочность, позволяя сформировать итоговый вывод через преодоление противоречий.

Оркестратор делает три параллельных запроса в векторную базу. Собранные данные рендерятся в промпт с чёткими секциями R1, R2, R3. Синтез — финальный сбалансированный вывод LLM на основе «диалектического треугольника».

DIALECTICAL_SYSTEM_EXTRA = """
Доказательная база разбита на секции R1/R2/R3. Используй только цитаты и факты из этих блоков.
Не выдумывай цитаты Ленина или других авторов вне блоков.
Если R1 непуст — центральный тезис обязан опираться на R1. R2 = опора/согласие, R3 = полемика/критика.
Если слот помечен «(пусто)» — не заполняй его из знаний модели.
Маркер [multi-stance] означает, что фрагмент попал в несколько ролей; не дублируй один тезис как будто это независимые источники.
Применяй теорию к сообщённым фактам новости; не выдавай себя за очевидца современных гаджетов, приложений или соцсетей.

Пример корректно: опереться на цитату из R1 и связать с новостью.
Пример некорректно: приписать Ленину фразу, которой нет в R1–R3.
"""

Митигация (контроль качества).

• Пустой R3: Система выдаст предупреждение и синтезирует ответ на основе R1+R2.

• Рост задержки: Компенсируется параллельными запросами и кэшированием эмбеддингов.

• Длинный промпт: Ограничивается лимитами и обрезкой слотов.

На основе собранных секций R1, R2, R3 формируется структурированный промпт с четкими секциями для LLM.

На период разработки генерация выполнялась локально на модели GigaChat3 через llama‑server из экосистемы llama.cpp и биндинг llama_cpp_python. В продовой версии генерация была передана на внешнюю LLM с доступом по API. 

Промпт обязывает LLM опираться на R1 (тезис) и синтезировать итоговый вывод через преодоление противоречий между R2 и R3. Без ссылок на доказательную базу ответ запрещён. 

Постобработка

Результат генерации проходит через цепочку гейтов:

• Проверка политик безопасности, по сути аналог цензора.

• Анти‑клише. Анализирует текст на наличие речевых штампов и не пропускает ответ, если находит их превышение. В основе лежит лексическая метрика Jaccard — сравнение множеств токенов ответа с базой клише.

• Анти‑анахронизм. Сканирует итоговый ответ на наличие терминов и реалий, которые появились позже 1924 года. Если находит — публикация блокируется.

• Целостность: проверяет, не является ли ответ пустым, слишком коротким или техническим сбоем.

• Пост‑редактура: В случае незначительных стилистических ошибок возможна автоматическая правка без перегенерации.

Если все гейты пройдены, сообщение публикуется в мессенджер. 

Переход на внешнюю генерацию

После получения приемлемого результата на Gigachat3-10b‑a1.8b, перешёл к тестам в внешней LLM. Переход на внешнюю генерацию необходим из‑за ограничений ресурсов VPS.

Первая попытка «тот же промпт, другой endpoint» дала характерныe поломки.

• Сплющенная триада. Текст часто возвращался в одну строку. 

• «Условие применимости». llama‑промпт в выводе требует «ограничение/условие применимости». Внешняя генерация сделала из этого четвёртый блок текста.

Создан отдельный билдер. Видимо универсализация не возможна и под каждую модель необходимо подбирать индивидуальные решения.

Проблемы и их решения

• Проблемы с качеством генерации. Это были самые первые и болезненные проблемы. Далее по шаблону симптом — рецепт:

  • Выдумывание цитат — механизм «только из RAG» и пост‑валидации цитат.

  • Карикатурная шаблонность — структурированный формат «Факт — Механизм — Вывод»

  • Поверхностный анализ — Требование причинно‑следственной связи в промпте

  • Галлюцинации — Ограничение контекста только RAG‑чанками и жёсткие запреты в промпте

  • Зацикливания — реализация детектора циклов

• Проблемы с диалектической оркестрацией.

  • Пустой слот R3 вследствие чего модель не могла построить антитезис. Применил fallback на R1+R2 с предупреждением в выводе.

  • Нестабильность сборки сортов. Решил увеличением числа запросов + гибридный поиск (dense + BM25)

  • Длинный промпт. Три слота + инструкции не помещались в контекст. Ограничил слоты модели. 

  • Модель не понимала, как синтезировать три слота. Переработал промпт с явной инструкцией: «используй R1, чтобы проверить R3»

• Проблемы с фильтрацией и безопасностью — система должна была не генерировать опасный контент, но фильтры были слишком грубыми. 

  • Блокировка нейтральных новостей. Решилась к переход от бинарного фильтра к троичному + добавление исключений.

  • Пропуск блокированных тем. Ужесточил список стоп‑слов и контекстных условий. Но, как говорилось ранее, это накопительное решение, его надо постоянно пополнять образцами.

  • Неадекватная фильтрация экономических тем, например блокировка заявлений министров, дипломатических инициатив. Был введён белый список.

  • Спорт и развлекательные новости. В результате почти всегда получался шаблонный ответ. Принял решение полного отказа от новостей подобного типа. Но, тут оказался «сюрприз» в виде развитой терминологии и жаргона. Например: «Трансфер Х успешно завершён.» 

• Технические артефакты и постобработка — «головная боль» на протяжении всего проекта. В конце концов, выделил постобработку в многоступенчатый автономный модуль и отдалил его изолировано от проекта. Дольше всего пришлось бороться с артефактами вёрстки например [место], [обезличено] и заменами, например: СЃ вместо «США».

• «Мёртвая онтология» — изначальная архитектурная проблема, заключается в отсутствии покрытия современных тем + проблемы обработки источников, о которых было написано выше. Несколько исправило проблему — определение темы сообщения, а не поиск в RAG точного соответствия. 

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

Известные проблемы без решения: 

• Пустой R3. Практически всегда. Это следствие жёсткой привязки к RAG и недостаточного наполнения онтологии. Как следствие, формирование одностороннего мнения о фактах.

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

• Чистота онтологии. Даже не смотря на проделанную работу, в чанках содержится значительное количество артефактов, препятствующих качественной генерации.

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

• Большой поток новостей. В среднем в публикацию отправляется избыточное количество сообщений, даже с учётом жёсткой фильтрации. Для пользователя это выглядит как нескончаемый информационный поток, где для восприятия каждого сообщения надо приложить интеллектуальное усилие, в какой то момент возникает чувство усталости. Необходимо усиление фильтрации, переход к белым спискам тем. Временным решением стало изменение формата публикации на факт — вывод — механизм. Раздел механизм читается редко. 

• Шаблонность ответа. Даже не смотря на все принятые решения, на длинных дистанциях становится заметно применение моделью одних и тех же языковых клише. Например: достаточно часто используется конструкция «это не..., а...» — «Публичный рынок капитала — это не нейтральный механизм, а...» 

• Потеря ориентации в пространстве. Видимо из‑за отсутствия чётких указаний в промте, LLM в некоторых случаях создаёт анализ с точки зрения действующей социалистической экономики.

Вероятные проблемы: 

• Нестабильность внешнего API и модерации в LLM. Есть известные риски использования внешней генерации: изменение условий, внезапное отключение доступа, ценовые скачки и задержки + сами модели могут отказываться анализировать чувствительные темы. 

  Почему это сейчас не наблюдается:

  1. необходимо лонгитюдное исследование

  2. неопубликованное сообщение лучше, чем ошибочно пропущенное. Особенно ввиду мощного информационного потока

• Нагрузка на оборудование. Прод работает на VPS. Полноценная OPS поддержка и мониторинг отсутствует. 

• Проблемы с синхронизацией офлайн и онлайн‑контуров. Сейчас онтология статична. Если делать обновление онтологии или перестраивать индексы, не останавливая работу, это потребует отдельной разработки и решений. 

Результаты и метрики

• Срез с прода, живая лента TASS за первые дни работы VPS.Воронка (16.08–19.08.2026, 19-е‑ неполный день). 

  В SQLite: 3353 новости, 1257 опубликованных анализов. Доля «дошло до канала» 37,5% от входящих. С учётом неполных дней старта и окончания выборки общая доля составила 37,5%, а на полных сутках стабильно держится около 39%:

  • 16.08 (старт днём): Новостей — 406, Опубликовано — 94, Доля — 23%

  • 17.08: Новостей — 993, Опубликовано — 387, Доля — 39%

  • 18.08: Новостей — 1155, Опубликовано — 450, Доля — 39%

  • 19.08 (до ~18:00): Новостей — 799, Опубликовано — 326, Доля — 41% 

  Итого полный день: около 1000–1150 входящих новостей и 390–450 публикаций. 

  Если анализ уже сгенерирован, в Telegram он уходит почти всегда. Основной отсев происходит до LLM.

• PreRagCensor 

  Кэш решений на проде (1197 записей, 18–19.08): 

  • hard_block — 58,6%,

  • allow — 38,1%, 

  • review — 2,8%, 

  • skip — 0,5%. 

  Лабораторный прогон на 2160 заголовках дал близкую картину:

  • hard_block — 51,0%, 

  • allow — 38,8%. 

  Три часа живых логов 19.08 (n=51):

  • hard_block — 51%, 

  • allow — 43%, 

  • review — 6%.

• Длина ответа. Жёсткий потолок публикуемого текста — 1800 символов, максимальное количество токенов генерации — 512

• Цитаты. На проде модель почти всегда идёт по принципу «без дословной цитаты», в основном модель перерабатывает содержание слотов в свой текст. При этом сами слоты (R1–R3) используются как опора для рассуждения, а не как источник для копирования.

• Время генерации. RAG + LLM + гейты в логах 19.08: 3,5–4 мин на одну новость.

• Деньги.

  • 17.08 — Cost $0.22 USD, Tokens 780,308

  • 18.08 — Cost $0.25 USD, Tokens 926,548

  • 19.08 (до ~18:00) — Cost $0.21 USD, Tokens 705,401 

Выводы и планы

Проект AI_Lenin достиг состояния, когда его можно показывать без чувства стыда. Основной результат — рабочий RAG‑пайплайн с диалектической оркестрацией, который заставляет LLM структурно рассуждать, опираясь на три слота.

Гипотеза «малая LLM с качественной программной обвязкой на узкой задаче даёт результат, сопоставимый с большой моделью» получила подтверждение.

Получен опыт:

• Fine‑tuning малой модели для такой задачи — мёртвый вариант; RAG дал результат.

• Для каждой модели необходимы индивидуальные настройки.

• Постобработка — не косметика, а полноценный слой.

• Фильтрация и безопасность — никогда не будет идеальной без постоянного апдейта.

Ближайшие планы: наблюдение, сбор артефактов для оценки стабильности работы и качества генерации. 

Ссылка на GitHub: https://github.com/Nlegion/AI_Lenin

Ссылка на канал в мессенджере: https://t.me/news_ai_lenin

Laudate Omnissiah!