Давайте всё же отвечу, насколько это возможно в данной ситуации, когда полные данные фактически не предоставлены, а "наука о данных" без собственно данных может только гадать.
- Какую архитектуру использовать? Просто делить события по минутам и считать какие-то фичи?
Это два разных вопроса. Под архитектурой обычно имеют в виду какой тип модели планируется использовать. А вы спрашиваете про подготовку данных. Это тоже в какой-то степени архитектура, но не совсем.
А по существу, ну, в первом приближении выглядит так, что да - просто разбиваем входные данные по минутам, подготавливаем какие-то фичи, делаем аггрегаты, берём разметку - и строим модель. Но никто не гарантирует, что сигнал в ваших данных будет и что этой минуты хватит.
- Может нужны будут данные не только за эту минуту, но и раньше
- Может нужно будет "скользящее окно" на минуту назад за каждый момент, а не просто отбрасывание секунд
- Данные могут очень неравномерно разбиться на минуты - где-то одна строка данных, а где-то сто - и тогда аггрегаты у вас сильно "поедут", нужно будет использовать усреднение вместо сумм, например, ну и прочее такое.
- Какие фичи считать? Там, по идее, будет огромный список слов. Использовать TF-IDF или BERT?
У вас же там разные данные. Где-то просто категории (не упорядоченные), там можно использовать OneHotEncoder (каждой категории - свой столбец с нулями и единичками). Где-то упорядоченные категории, их можно переводить в натуральные числа с соблюдением порядка (какая категория "старше", а какая "младше"). Где-то у вас фактически целые тексты (или хотя бы предложения) - там да, можно использовать CountVectorizer или TfidfVectorizer в случае простых моделей, либо если у вас нейросети, то да, можно BERT или другое подобное.
Преобразованные в численные вектора или матрицы столбцы потом конкатенируются горизонтально и получается большая такая матрица, с которой дальше можно использовать любые модели, которые работают с числами. Хоть линейные модели, хоть деревья, хоть бустинги, хоть нейросети. Нужно смотреть, что лучше работает с вашим конкретным случаем.
По-хорошему ещё нужно будет выкинуть бесполезные столбцы (например, заполненные константой), либо не коррелирующие с таргетом от слова совсем. Но можно и не делать этого, если ресурсов хватает, модель может быть сама разберётся, что полезно, а что нет.
Да, и не забудьте про разметку. Вам нужно будет разметить каждую вашу минуту - какой у неё будет таргет. Либо есть/нет событие для бинарной классификации, либо категории событий.
Самые простые модели не умеют в мультилейбл классификацию, там придётся просто строить несколько отдельных моделей, на каждый лейбл свою, которая будет определять именно этот лейбл. Сложные модели умеют в несколько лейблов "из коробки".
- Буду благодарен за ссылку на пример подобной модели.
Конкретный пример не подскажу, хотя если посмотреть на Kaggle, там наверняка были такие соревнования, в том числе именно с парсингом логов. Я там давно просто не был, но вообще там обычно можно найти примеры подготовки данных и построения моделей на все случаи жизни.
Ну, вот, если поверхностно, то как-то так. Но ещё раз подчеркну:
- Нет гарантии, что в ваших данных вообще будет сигнал. Вам может не хватать данных, может быть недостаточная подготовка фич. Или может быть эти данные нужно ещё обогащать каким-то внешним знанием (грубо говоря - сингатурами вирусов, например). Без чего модель может просто не заработать или заработать с очень плохим качеством.
- "Know your data." Вы можете, конечно, закидывать данные не глядя в нейросеть, и пусть она там разбирается, но не ждите от такого подхода хорошего качества предсказаний. Вы должны любить свои данные, изучать их, уметь их готовить.
- Никто заранее вам не скажет, какая подготовка данных и какая модель "взлетит" (а может и никакая не взлетит). Нужно разбираться, пробовать разные подходы, тестировать разные идеи, перебирать модели. Это работа и научная и творческая одновременно.