Как построить агрегатор ИБ-новостей: гибридный подход к склейке сюжетов и оценке важности

Короткий ответ: агрегатору нужен LLM не вместо правил, а поверх них

Надежный агрегатор ИБ-новостей строится как конвейер: сбор материалов, извлечение текста, нормализация сущностей, дедупликация, склейка в сюжеты, расчет признаков, ранжирование, публикация и пересчет при появлении новых сведений. LLM полезна внутри этого конвейера: она извлекает CVE, продукты, версии, организации и утверждения, классифицирует тип публикации, сравнивает спорные материалы и готовит краткие сводки.

Решение о важности и публикации лучше оставить прозрачному слою правил и признаков. Он должен объяснять, почему сюжет попал в верх ленты: есть ли первоисточник, подтверждена ли эксплуатация, затронуты ли конкретные версии, присутствует ли CVSS, включена ли уязвимость в KEV, каков сигнал EPSS, есть ли индикаторы компрометации и не получил ли материал промо-штраф.

Для ИБ такая архитектура особенно нужна из-за цены ошибок. ИИ ускоряет поиск уязвимостей, эксплуатацию и подготовку вредоносного кода, а защитные команды подключают модели к обнаружению и блокировке активности. SOC, MDR, SIEM/SOAR и команды управления уязвимостями должны быстро увидеть важное обновление, не пролистывая десять пересказов одного инцидента и поток приглашений на вебинары.

Базовый конвейер агрегатора

1. Сбор. Получайте записи из RSS, API, рассылок и выбранных страниц. Сохраняйте оригинальный заголовок, текст, дату публикации, домен, автора при наличии и ссылку.
2. Нормализация. Приводите даты к одной временной зоне, очищайте трекинговые параметры ссылок, сопоставляйте варианты имен компаний, продуктов и групп.
3. Извлечение фактов. Находите CVE, версии, затронутые продукты, организации, тип атаки, меры защиты, статус эксплуатации и признаки промо.
4. Поиск кандидатов. Отбирайте похожие материалы через временное окно, общие сущности и технические идентификаторы.
5. Кластеризация. Привязывайте публикацию к существующему сюжету, создавайте новый сюжет или отправляйте связь на проверку.
6. Скоринг. Считайте подтвержденность, серьезность, применимость для защиты, новизну, качество источника, CVSS, KEV, EPSS и штрафы.
7. Публикационная политика. Направляйте материал в основной поток, краткое обновление, очередь редактора, архив или блокировку.
8. Пересчет. Обновляйте карточку сюжета, когда появился первоисточник, патч, подтверждение эксплуатации, опровержение или новые технические детали.

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

Что можно поручить LLM, а что лучше оставить правилам

Задача	Подход	Причина
Извлечь CVE, продукт, версию, организацию	LLM со структурированным выводом и валидацией	Факты часто разбросаны по тексту и названы разными словами
Определить тип материала	LLM плюс правила	Модель лучше различает отчет, комментарий, новость и промо, но явные маркеры регистрации или покупки проще ловить правилами
Сформировать краткое описание	RAG-суммаризация по сохраненным фрагментам	Сводка должна опираться на текст публикаций, а не на память модели
Проверить CVE, дату, домен, дубль URL	Детерминированные проверки	Здесь нужен воспроизводимый результат
Решить, публиковать ли материал	Признаки, веса и политика порогов	Редактор должен видеть причину каждого балла и менять правила без переобучения модели
Проверить связь двух материалов	Каскад фильтров, затем LLM для спорных пар	Семантическое сравнение полезно после сокращения числа кандидатов

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

Почему обычная новостная подборка плохо работает для ИБ

Обычная лента часто сортирует записи по свежести, числу ссылок или реакции аудитории. В ИБ эти признаки дают много шума. Поздний технический отчет с затронутыми версиями и IOC полезнее раннего эмоционального пересказа. Сообщение об умеренной уязвимости в реально атакуемом продукте может требовать реакции быстрее, чем высокий CVSS у компонента без известных случаев эксплуатации.

Практическая ценность ИБ-ленты зависит от ответа на четыре вопроса: что произошло, насколько это подтверждено, кого затрагивает и какие действия доступны защитнику. Количество публикаций о событии не отвечает ни на один из них.

Один инцидент - много публикаций

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

Например, первый материал говорит о CVE, второй использует название продукта и версии, третий описывает атаку через уязвимость без упоминания идентификатора. Если показывать все три записи отдельно, читатель тратит время на повторный контекст. Если склеить их без проверки, можно ошибочно объединить две разные проблемы одного вендора.

Сигнал, контекст и промо не равно одно и то же

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

Промо-материал не обязательно нужно удалять из базы. Он может быть полезен для отдельной витрины рынка, но не должен конкурировать с уведомлениями об активной эксплуатации. Проблема начинается, когда анонс с большим числом ИБ-терминов получает высокий балл лишь за свежесть.

Почему объяснимость важнее магического балла

Оценка 87 без расшифровки ничего не говорит редактору. Карточка должна показывать вклад признаков: подтверждено официальным уведомлением, есть затронутые версии, есть патч, CVE присутствует в KEV, материал добавляет новые IOC, вторичный источник, промо-штраф отсутствует.

Такой формат упрощает спорные решения. Редактор может снизить вес свежести, если лента перегружена короткими пересказами, или поднять вес наличия патча для аудитории, которая отвечает за управление уязвимостями. Модельный балл без причин такой настройки почти не дает.

Как склеивать новости в сюжет: от нормализации до кластера

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

Единая схема материала и события

Разделите сущности материал и сюжет. Материал хранит конкретную публикацию. Сюжет описывает развивающееся событие и объединяет материалы, которые добавляют подтверждение или новые факты.

Поле материала	Зачем нужно
Заголовок и очищенный текст	Поиск утверждений, сущностей и смысловых совпадений
Дата публикации и дата события	Разделение пересказа и свежего факта
Источник и каноническая ссылка	Оценка происхождения и устранение дублей
Тип публикации	Разные правила для отчета, уведомления, анонса и комментария
Организации, продукты, версии, CVE	Точные сигналы для кластеризации и технического скоринга
Кампания, группа, география, отрасль	Контекст для инцидентов без CVE
Ключевое утверждение о событии	Проверка, что публикации говорят об одном факте
IOC, условия эксплуатации, меры защиты	Оценка применимости для защитной команды

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

Как находить кандидатов на объединение

Сравнение каждого текста со всеми накопленными материалами быстро становится дорогим и дает ложные совпадения. Используйте каскад.

1. Отберите материалы в подходящем временном окне.
2. Найдите точные совпадения CVE, названий продуктов, организаций и кампаний.
3. Сопоставьте нормализованные сущности и ключевые фразы.
4. Проверьте лексическую и векторную близость заголовков и ключевых утверждений.
5. Передайте спорные пары в LLM с требованием назвать совпадающие признаки и противоречия.

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

Когда материалы относятся к одному сюжету

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

• Одинаковый CVE или другой уникальный технический идентификатор.
• Совпадающий продукт и версия в совместимом временном контексте.
• Одна организация, кампания или атакующая группа при наличии подтверждения.
• Явная ссылка на уже известное первичное сообщение.
• Новые сведения развивают уже опубликованный факт, а не описывают другой инцидент.
• Нет конфликта по масштабу, времени, продукту или механизму атаки.

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

Обновление сюжета не всегда означает новую новость

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

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

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

Как обрабатывать сомнительные совпадения

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

Редактору нужны действия «объединить», «оставить отдельно» и «разъединить сюжет». Последнее особенно важно: ошибка слияния портит доверие сильнее, чем две похожие карточки. После ручного исправления систему можно повторно прогнать по связанным материалам, сохранив старую версию решения в журнале.

Прозрачный ранжирующий слой: из каких признаков складывается важность

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

priority = confirmation + impact + actionability + source + novelty + vulnerability_signals - promo_penalty - duplicate_penalty

Вес каждого слагаемого зависит от аудитории. Команде SOC важнее скорость, IOC и подтвержденная активность. Для разработчиков критичнее затронутые версии, патч и условия эксплуатации. Редакторская лента может сильнее штрафовать вторичные пересказы, чтобы не создавать видимость новизны.

Подтвержденность и качество источника

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

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

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

Серьезность и потенциальный ущерб

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

Разделяйте потенциальный ущерб и зафиксированный ущерб. Уязвимость с удаленным выполнением кода может иметь высокий потенциальный риск. Подтвержденная компрометация конкретной организации добавляет фактический контекст. Эти признаки нельзя склеивать в одну категоричную фразу.

Техническая применимость и срочность

Высокий приоритет получают материалы, после которых защитник понимает, что проверить. Полезные поля: затронутые версии, условия эксплуатации, вектор атаки, доступный патч, временная мера защиты, IOC, сигнатуры, хеши, домены, IP-адреса или рекомендации по поиску следов активности.

Публикация с формулировкой «обнаружена критическая проблема» без идентификатора, продукта, версии и способа проверки редко требует срочного действия. Ее можно оставить в очереди на уточнение, а не продвигать в основной поток.

Первоисточник, свежесть и уникальность

Разделяйте свежесть публикации и свежесть факта. Текст, опубликованный сегодня, может пересказывать уведомление недельной давности. Напротив, обновление старого сюжета новым IOC способно быть полезнее свежей заметки без технического содержания.

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

Штрафы за промо и низкую информационную плотность

Промо-штраф должен быть отдельным и объяснимым. Его нельзя заменять субъективным решением модели «текст похож на рекламу». Используйте наблюдаемые признаки.

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

Штраф не обязан вести к блокировке. Он снижает видимость в основной ленте. Отдельная витрина обзоров рынка, сервисов SOC, MDR или новых средств защиты может использовать иную политику.

Как показывать расшифровку итогового балла

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

Плохой формат: «Оценка важности 92». Хороший формат: «Повышено за KEV и первоисточник; снижено за отсутствие данных о затронутых версиях». Второй вариант можно проверить и оспорить.

CVSS, KEV и EPSS: как учесть техническую опасность уязвимости

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

Что показывает CVSS и чего он не показывает

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

Высокий CVSS без затронутых версий и условий эксплуатации требует осторожности. Лента может показать такой сюжет, но в объяснении нужно отделить потенциальную тяжесть от подтвержденной угрозы.

Почему наличие в KEV меняет приоритет

Включение CVE в KEV дает сильный признак того, что уязвимость известна как эксплуатируемая. Для ИБ-ленты это весомая причина поднять сюжет, особенно когда публикация содержит список версий, сроки исправления, меры снижения риска или признаки компрометации.

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

Как использовать EPSS без ложной точности

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

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

Пример комбинирования сигналов

Сценарий	Сигналы	Логика приоритета
Высокий CVSS, нет сведений об эксплуатации	Высокая потенциальная тяжесть, есть версии и патч	Высокая заметность для затронутых пользователей, но без формулировки о подтвержденной атаке
Умеренный CVSS, CVE есть в KEV	Подтвержденная эксплуатация, возможно есть меры защиты	Часто приоритетнее первого случая, поскольку риск уже перешел из потенциального в наблюдаемый
Высокий EPSS, нет списка версий	Вероятностный сигнал без достаточного контекста	Очередь на уточнение или пониженная видимость, пока не появятся применимые детали

Универсальных весов здесь нет. Их калибруют на размеченной выборке и на задачах конкретной аудитории. Для одного потока приоритетом будет активная эксплуатация, для другого - ранние уведомления о патчах в используемом стеке.

Порог публикации: как не получить пустую ленту или поток пресс-релизов

Бинарное правило «публиковать при балле выше N» быстро ломается. Раннее сообщение об атаке бывает неполным, но полезным как сигнал. Пресс-релиз может набрать баллы за свежесть, упоминание ИИ и большое число терминов. Нужна многоуровневая политика.

Почему один высокий порог делает ленту пустой

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

Вместо полного скрытия используйте статус «предварительное сообщение». Оно получает компактную карточку с явно указанной неполнотой сведений, не конкурирует с подтвержденными инцидентами и автоматически пересчитывается при новых фактах.

Почему низкий порог запускает поток шума

Низкий порог пропускает публикации, где единственный сигнал - свежая дата и набор ИБ-слов. В ленту попадают вебинары, анонсы, ежегодные отчеты без новых инцидентов и вторичные пересказы.

Защитой служат минимальные требования к фактам. Для основного потока можно потребовать хотя бы один сильный признак: первоисточник, CVE с техническим контекстом, подтвержденный инцидент, конкретные IOC, патч, сведения об эксплуатации или подтвержденное изменение регуляторных требований. Остальные материалы получают пониженную видимость или попадают на ручную проверку.

Многоуровневая политика публикации

Уровень	Условия	Показ в продукте
Основной поток	Высокая подтвержденность или сильный технический сигнал, нет критичного конфликта	Полная карточка сюжета с причиной приоритета
Краткое обновление	Существенный новый факт внутри существующего сюжета	Обновленная карточка и отметка о новом факте
Очередь на проверку	Высокая потенциальная ценность, но не хватает подтверждений или есть конфликт	Внутренний интерфейс редактора
Архив или низкая видимость	Вторичный пересказ, контекст без действий, слабая новизна	Доступен в поиске и внутри сюжета
Блокировка	Явное промо, спам, повтор URL, отсутствие проверяемого утверждения	Не попадает в публичную ленту

Пересчет при появлении новых данных

Оценка сюжета не должна быть постоянной. Пересчитывайте ее, когда появляется первоисточник, подтверждение эксплуатации, запись KEV, обновленный EPSS, патч, IOC, уточненный список версий или опровержение.

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

Роль LLM в системе: извлечение, обогащение и объяснение, а не источник истины

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

Какие поля извлекать из текста

• Организации, продукты, компоненты и версии.
• CVE и другие технические идентификаторы.
• Тип угрозы, вектор атаки, этап атаки и последствия.
• Даты обнаружения, раскрытия, исправления и эксплуатации.
• Меры защиты, патчи, временные обходные меры и IOC.
• Первичный источник и статус подтверждения отдельных утверждений.
• Признаки промо-контента: регистрация, продажа, демо, вебинар, рекламные формулировки.

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

LLM для проверки связи между материалами

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

decision: same_story | update | separate | uncertain
shared_evidence: [CVE, product, organization, event_claim]
conflicts: [date, version, scope]
reason: краткое объяснение по переданным фрагментам

Ответ uncertain полезнее искусственной уверенности. Его можно направить редактору или оставить материалы раздельными до появления первоисточника.

RAG и доказательная база

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

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

Защитные ограничения для модели

• Требуйте JSON или другой строгий структурированный вывод.
• Валидируйте CVE, даты, домены, типы полей и допустимые статусы.
• Проверяйте критичные утверждения вторым проходом или правилами.
• Не позволяйте модели повышать итоговый приоритет без проверяемых признаков.
• Логируйте промпт, версию модели, контекст и результат.
• Поддерживайте ручное исправление сущностей, статусов и связей между сюжетами.

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

Как проверить качество агрегатора до запуска

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

Метрики склейки сюжетов

• Доля правильных объединений: материалы одного события попали в общий сюжет.
• Ошибочные слияния: система объединила разные CVE, инциденты или кампании.
• Раздробленные сюжеты: одно событие осталось в нескольких карточках.
• Повторные карточки: сколько раз лента показала один факт как новую новость.
• Время исправления: как быстро система и редактор исправляют спорную связь.

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

Метрики ранжирования и публикации

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

Не пытайтесь свести качество к одному числу. Высокая полнота при большом шуме утомляет читателя. Идеально чистая лента, которая поздно замечает эксплуатацию, тоже бесполезна.

Аудит объяснимости

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

Сверяйте объяснение с исходными полями. Генерация красивой причины задним числом не решает задачу. Объяснение должно отражать фактически сработавшие правила и сохраненные сведения.

Минимальная архитектура MVP и порядок запуска

Не начинайте с автономного редактора на LLM. Первый рабочий релиз строится на ограниченном наборе качественных источников, нормализации и прозрачных правилах. После появления размеченных примеров можно добавлять embeddings, LLM для спорных связей, RAG-сводки и адаптацию весов.

Слой сбора и нормализации

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

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

Слой кластеризации и сюжеты

Храните связь каждого материала с сюжетом, решение о связи, уверенность, совпавшие признаки, новые факты и историю изменений. Добавьте ручное объединение и разъединение. Эти действия формируют ценную разметку для последующей настройки правил и моделей.

Слой признаков и ранжирования

Рассчитывайте подтвержденность, серьезность, техническую применимость, свежесть факта, уникальность, качество источника, CVSS, KEV, EPSS и промо-штраф. Храните составляющие отдельно от итогового балла. Тогда смена веса не потребует повторного извлечения всего корпуса.

Полезно разделить признаки на фактические и редакционные. Наличие CVE или патча относится к фактам. Допустимый объем ленты и видимость промо зависят от политики продукта.

Редакторский интерфейс и журнал решений

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

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

Порядок запуска без лишней сложности

1. Подключите ограниченный список источников и сохранение оригинальных материалов.
2. Добавьте нормализацию URL, дат, организаций, продуктов и CVE.
3. Сделайте точную дедупликацию и простую кластеризацию по сильным признакам.
4. Введите объяснимый скоринг и несколько уровней публикации.
5. Соберите редакторские исправления и эталонную выборку.
6. Добавьте embeddings для поиска кандидатов.
7. Подключите LLM для извлечения спорных сущностей и проверки сложных связей.
8. Добавьте RAG-сводки с привязкой к исходным фрагментам.

Такой порядок дает полезную ленту раньше и снижает риск, что сложная модель начнет маскировать проблемы сбора, структуры полей или редакционной политики. Подходы к узким локальным моделям и проверке качества fine-tune могут пригодиться при выборе отдельного извлекателя, об этом есть материал о локальной модели для узкой задачи очистки текста.

Итоговая схема: что должно быть видно в каждой карточке ИБ-сюжета

Хорошая карточка ИБ-сюжета уменьшает неопределенность. Читатель за несколько секунд понимает, что произошло, насколько сведения подтверждены, есть ли риск для его стека и почему сюжет находится на текущем месте ленты.

• Короткое описание события без неподтвержденных домыслов.
• Статус подтверждения и дата последнего существенного обновления.
• Ключевые первичные и независимые источники внутри сюжета.
• CVE, продукт и затронутые версии, если они известны.
• CVSS, KEV и EPSS как отдельные сигналы, а не единый вердикт.
• Технические детали: патч, обходная мера, IOC, условия эксплуатации.
• Причина приоритета и примененные штрафы.
• Отметка о роли материала: первичный, подтверждающий, техническое обновление, вторичный пересказ или промо.

Чек-лист перед публикацией

• Материал связан с конкретным событием или содержит самостоятельный проверяемый факт.
• Система проверила, что это не дубль существующей публикации и не повтор сюжета без новых сведений.
• Первичный источник найден либо отсутствие первоисточника явно отмечено.
• CVE, названия продуктов и версии прошли валидацию.
• Статус эксплуатации и масштаб последствий отделены от предположений.
• Карточка содержит практический вывод для читателя или честно указывает, что данных для действий пока недостаточно.
• Уровень видимости соответствует политике публикации.
• Редактор может восстановить причины объединения и расчета приоритета.

Главный принцип гибридного подхода

LLM помогает читать поток, извлекать сущности, находить смысловые связи и готовить сводки. Прозрачный слой признаков принимает проверяемые решения о склейке, важности и публикации. Такое разделение дает контроль над лентой, позволяет исправлять ошибки и объясняет читателю, почему конкретный ИБ-сюжет заслуживает внимания.

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

Подписаться на канал