Разбор логов нейросетью: как найти причину сбоя

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

Что модель делает хорошо

Пять операций, где выигрыш очевиден.

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

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

Объяснение незнакомого. Ошибка чужой библиотеки, непонятный код возврата, стектрейс на языке, с которым вы редко работаете.

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

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

Общее: модель сокращает объём чтения, а не принимает решение.

Что она делает плохо

Четыре вещи, из-за которых слепое доверие обходится дорого.

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

Корреляция во времени. «Ошибки начались после деплоя» — наблюдение, которое модель охотно превращает в причинно-следственную связь.

Арифметика по логам. Считать частоты, доли и перцентили должен ваш код, а не модель.

Знание вашей системы. Что в вашей архитектуре норма, а что аномалия, — контекст, которого в логах нет.

Практическое следствие: просите факты, а не выводы. «Перечисли уникальные ошибки с числом вхождений и первым появлением» даёт проверяемый результат; «в чём причина сбоя» — красивый текст.

Что подавать на вход

Здесь решается почти всё качество и весь бюджет.

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

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

С контекстом системы. Пара строк о том, что за сервис и что считается нормой, экономят больше, чем удвоение объёма логов.

Без шума. Отладочные сообщения, health-check, ротация — выбросьте до отправки.

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

Что нельзя отправлять

Отдельный раздел, потому что логи — недооценённый источник утечек.

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

Минимальная очистка до отправки:

Вырезать заголовки авторизации. Ключ в логе — отдельная проблема сама по себе — где хранить и где нельзя.

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

Убрать тела запросов и ответов либо обрезать до безопасной длины.

Решить, какие сервисы вообще обрабатываются. Не «все логи», а конкретный перечень.

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

Сколько это стоит

Считаем, потому что здесь легко получить неожиданный счёт.

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

Отсюда два правила:

Сворачивайте до отправки. Дедупликация по шаблону сокращает объём на порядки и почти не теряет информацию.

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

Задача не требует сильной модели: группировка и извлечение — это не рассуждение. Начинать разумно снизу: платные текстовые позиции в каталоге на 7 сентября 2026 года идут от 1 ₽ за миллион, восемь тарифицируются по нулевой ставке — что там доступно. Как перевести объём в рубли — методика.

Как встроить в дежурство

Порядок, который приживается.

1. Начните с постфактум-разбора, а не с реального времени. Инцидент закрыт, времени нет давления, ошибка модели ничего не стоит.
2. Дайте инженеру сводку, а не вывод. Список уникальных ошибок с частотами и временем первого появления.
3. Сохраняйте разборы. Через месяц станет видно, какие вопросы повторяются, — их стоит закрыть дашбордом, а не моделью.
4. Не подключайте к алертам сразу. Модель в цепочке оповещений добавляет задержку и новый источник ложных срабатываний.
5. Считайте сэкономленное время в минутах. Если разбор всё равно требует чтения исходных логов, схема не состоялась.

Чего это не заменяет

Три вещи, которые остаются на своём месте.

Мониторинг. Модель работает поверх собранных данных; собирать и следить должна система.

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

Знание системы. Инженер, понимающий архитектуру, найдёт причину быстрее, чем любая модель. Экономится чтение, а не понимание.

Формулировки, которые работают

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

«Сгруппируй сообщения по шаблону и укажи число вхождений и время первого появления». Основной запрос. Результат сверяется с исходником программно.

«Найди сообщения, встречающиеся реже десяти раз». Редкое среди частого — обычно самое интересное.

«Перечисли, что появилось сегодня и отсутствовало вчера». Требует двух выборок, зато сразу указывает на изменение.

«Объясни, что означает эта ошибка». Для незнакомых форматов и чужих библиотек.

«Восстанови последовательность событий для запроса с этим идентификатором». Работает, если у вас есть сквозной идентификатор.

Чего не спрашивать: «в чём причина сбоя» и «что произошло». Ответ будет связным, убедительным и непроверяемым.

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

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

Чего мы не утверждаем

Не сравниваем модели по качеству разбора. Своих замеров мы не делали.

Не рекомендуем конкретные системы логирования. Выбор зависит от стека.

Не обещаем, что модель найдёт причину. Она сокращает объём чтения; выводы делает человек.

Цифры каталога — на дату. Состояние на 7 сентября 2026 года.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

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

Что держать в голове

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Разобрать свой инцидент: keydealer.ru/login.