Есть небольшая база где собираются сообщения из логов одной энтерпрайзной системы. Это или чистые сообщения (редко) об ошибках или (часто) исключения и java stacktrace. В базе собранны не все сообщения а так сказать только представители каждого типа ошибок. Другими словами если ошибка существует, то за день можно сотни тысяч сообщений в логах поиметь и каждое уникально - меняются id и со своим timestamp, но в базе (в идеале) есть только одна запись. Теперь сама проблема: в какой то момент на радаре появляется новое сообщение и стоит задача, найти наиболее похожие сообщения из уже зарегистрированы в базе. Для этих целей есть некая функция, которая вычисляет степень схожести сообщений. Максимальное значение результата функции - мин длина одного из сообщений. «Очевидное» решение в лоб — сравнить новое сообщение с сообщениями в базе и взять наиболее «схожее» не приводит к желаемому результату по двум причинам. Во первых - медленно, т.к. сравнение схожести имеет сложность O(n * m) где n,m длина сообщений. И шаблонов в базе около 50 тысяч. Вторая причина менее очевидна. Пусть ошибка находится в методе CustomerService.getDeliveryAddress. (Пример надуманный). Этот метод может вызываться из разных мест, в разном контексте. Stacktrace для этого метода вызванный как сервис в контексте JBoss имеет приличную (10+) глубину, и большинство стековых фреймов идентичны с другими ошибками в этом же контексте, т.е. например CustomerService.getAddress вызванным как сервис в JBoss и как следствие эти два сообщения очень «похожи». В то же время та же функция вызванная в каком-нибудь отчёте имеет ту же ошибку но имеет очень отличительный stacktrace и контекст и как результат сравнения «не похожа».
Первый вопрос: как бы вы определяли схожесть сообщений?
Моё понимание проблемы - не все строчки сообщений имеют одинаковую значимость для сравнения. Как следствие подзадача вычислить или строчки, которые «уникальны» или вычислить строчки которые «шумят».
Второй вопрос: как бы вы выделили эти «значимые/шумовые» строчки в сообщениях.

Почистить сообщение в общем случае это как-раз то в каком направлении я думаю. Но как чистить тут и есть самый ключевой момент. Я предпологаю расчитать что есть муссор. Просто выделить верхние фреймы (или начало собщений) не всегда даст желаемый результат т.к. текствое сообщение и текст исключения параметризованы. т.е. будут отличатся
SomeAppException: Unable detect delivery address for customer XXXXXXX XXXXXXX / order #### on May 12 2020.
SomeAppException: Unable detect delivery address for customer YYYYY YYYYY YYYYY YYYYY / oder ##### on Dec 21 2019.

А последующие 2 строчки stecktrace идентичны.

А это ни чем не лутче первого варианта.

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

Алексей Роза,

Вы не поняли совсем. Перечитайте внимательно самое первое сообщение.

mayton,

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

mayton,

показать настоящий лог я не могу, могу только напеть. И потом, одного сообщения будет недостаточно.

Первый вопрос: как бы вы определяли схожесть сообщений?
Второй вопрос: как бы вы выделили эти «значимые/шумовые» строчки в сообщениях?

Ржавый гвоздь,

Мои вопросы возможно не всем доступны но вполне конкретны - как бы вы определяли схожесть сообщений?
Какой ваш ответ?

mayton,

имеем:
1.) набор P из ~50K "разнотипных" сообщений - представители каждого типа сообщений.
2.) сообщение M, про которое ничего не известно заранее.

Hайти:
Наиболее "схожие" сообщение из набора (1) в порядке убывания схожести.
Или другими словами определить функцию схожести S(M, Pi), для 0 < i < N.

Простор для полёта мысли не ограничен. Предлагайте, я могу опробовать и сообщу о результатах.