Почему нашим числам можно верить
Главный вопрос к любой «ИИ-аналитике»: откуда цифра и не выдумана ли она. Здесь - прямой ответ, как устроен наш анализ и почему ИИ у нас не может придумать число.
Какую задачу решаем?
Наверняка вы видели ИИ-отчёты с убедительными, но на поверку придуманными числами. Модель уверенно называет цифру, которой в данных нет. А на вопрос «откуда это?» отвечает «извините, не знаю» - и виноватым в итоге оказываетесь вы. После пары таких случаев доверие к «ИИ-аналитике» падает до нуля.
Второй барьер - данные. Логи грязные, из разных систем, не готовы к загрузке. Чистить их вручную ради того, чтобы «просто посмотреть, есть ли смысл», никто не хочет.
Как это устроено у нас
- 1. ИИ - серьёзно и на переднем крае. Несколько продвинутых языковых моделей, каждая под свою задачу: одна пишет разбор находок понятным языком, другая независимо его проверяет. Не «одна нейросеть на всё» - подобранный инструмент под каждый шаг.
- 2. Мы знаем предел ИИ. Языковые модели, даже самые сильные, статистически склонны уверенно выдумывать числа там, где не знают точного ответа - в попытке угодить «заказчику». Это задокументированное свойство их устройства («галлюцинации»), а не редкий сбой конкретной модели.
- 3. Поэтому расчёты ИИ мы не доверяем. Все числа считает детерминированный статистический движок (numpy / scipy / statsmodels - библиотеки для числовых расчётов и статистических тестов). Роль ИИ ограничена на уровне правил: он интерпретирует и оформляет уже посчитанный факт в текст, но не может изменить или придумать цифру.
- 4. Перекрёстная проверка. На платных тарифах вторая независимая модель, отличная по алгоритмам мышления, сверяет текст разбора с посчитанными фактами и ловит расхождения до того, как отчёт попадёт к вам. Вы получаете выверенный результат, а не кухню сверки.
Аналогия: редактор проверяет журналиста. Читатель ценит, что текст прошёл редактуру, но читает готовую статью, а не правки красным на полях. Мы показываем, что редактор есть; отдаём - статью.
Наши результаты на реальных данных
Честность проще всего проверить там, где «удобного» ответа нет. На реальных данных (банковский процессинг) движок при попытке сгруппировать инциденты честно не выдал кластеры: структуры в данных не оказалось (silhouette = 0.169 - ниже порога значимости), и он прямо сообщил об этом. ИИ-помощник, который «хочет» найти хоть что-то, в этой ситуации обычно придумывает правдоподобные группы. Наш движок вместо этого говорит: структуры нет.
А на другом реальном датасете движок ещё до анализа оценил качество выгрузки и дал грейд B: 1047 из 1057 строк валидны. Вы видите, насколько данным можно доверять, прежде чем читать выводы.
Что нужно от ваших данных
Обычно готовить ничего не нужно - данные у вас уже есть. Подходит экспорт из Jira, ServiceNow, Zabbix или простой список инцидентов в CSV / Excel: колонка времени начала и конца события (или готовая длительность) и, желательно, название сервиса. Перед разбором движок сам оценивает полноту и пропуски и честно показывает грейд - а не молчит про грязные данные.
Изредка встречаются нестандартные выгрузки - новый формат, редкий баг экспорта, смешанные источники. В таких случаях мы не отбрасываем данные и не подгоняем их вслепую: подключаем ручной разбор и доочистку под вашу конкретную ситуацию, чтобы результат остался честным.
Первый шаг - грейд качества данных - бесплатный, до всякого обязательства. Все данные обрабатываются изолированно и не передаются третьим лицам.