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

Рабочие вводят причины простоя разными словами, от души. «Шланг порвался», «они не успевают дать продукцию», «безобразно обрезана кромка» — это ещё цветочки. Одно только слово «железнодорожный» можно написать десятками способов — жд, Жд, ЖД, ж/д, ж\д, ж /д, ж д, Ж д, ЖД!!! — и так далее. С вывернутыми слешами, двойными пробелами и другими творческими формулировками.

В базе 13 миллионов записей, из них 700 тысяч уникальных, из которых остаётся примерно 500 тысяч после нормализации по регистру, слешам, пробелам и т. п. А нам нужно как-то разобраться, что не так и с кем.

Если вы сейчас думаете про ML, LLM и прочие модные слова, я вас огорчу. Оказалось, что есть простой кондовый способ, если применить немного ТРИЗа. В итоге получилось, что мы умудрились и рабочим сделать намного удобнее (что вообще-то редкость в реалиях производства), и дико помочь аналитикам.

Зачем нам знать причины простоев

Простои случаются всегда — либо нет заготовок (продукции), либо плановый или оперативный ремонт, либо тысяча других причин. Как выяснилось, пока элемент завода не становится бутылочным горлышком — причину простоев знать нам даже не надо. Они просто есть, они регистрируются, с этим можно жить. Условно, если бригада за смену делает 500 труб, а в суточном задании их 300 штук, простой на час вообще ничего не значит.

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

В этот момент (а лучше заранее, за год или полгода, чтобы простои не возникали) предполагается, что умные люди посмотрят все зарегистрированные причины и с ними разберутся. То есть нужен аналитический отчёт и какой-то дашборд.

Рабочие вводят причины вручную и творчески, двух одинаковых не найти. У рабочего порвался шланг — он выразил своё отношение к шлангу. Его подвёл коллега — он выразил своё отношение к коллеге. Формулировки крайне редко повторяются.

Анализ по-дедовски

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

Вот тут-то начиналась настоящая боль аналитика. Ему надо было открыть эту портянку за два года по конкретному участку и, стирая скролл на колесе мышки до рези в глазах, проматывать все комментарии про этот участок и цех. Считать на палке, калькуляторе или как угодно ещё, сколько же раз там обрывался этот шланг. А комментарии все как есть разрозненные и нетиповые. Это больно.

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

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

ИИ нас всех спасёт?

Изначально предполагалось, что мы возьмём какой-нибудь NLP-движок, соберём причины в большую красивую таблицу и расклассифицируем по полочкам.

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

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

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

Дата-сайентисты плакали и страдали.

Рабочие вводили в комментарии про причины простоя свои творческие формулировки как умели, от души, соревнуясь кто в литературности, кто в краткости, кто в аббревиатурах.

Жизнь продолжалась.

ТРИЗ-подход

Мы решили подойти по-тризовски и задали себе вопрос — как бы сделать так, чтобы комментарии стандартизовали сами себя? И подумали — а что если дать рабочим не вводить творчески-неповторимые формулировки, а сгруппировать все комментарии в базе один раз и давать выбрать причину простоя?

Так! Где-то уже это было! Идея с классификаторами уже не раз проваливалась. Что в ней было не так — классификатор кто-то должен поддерживать и актуализировать. Это нам не годится.

Значит, надо, чтобы комментарии ещё и писали сами себя! При этом ещё и самоунифицировались.

И мы решили поэкспериментировать с подсказками и сыграть на лени.

Прямо на стадии прототипа мы наткнулись на одну суперидею — сделать так же, как в поисковой строке браузера. Ну или там Яндекса. У них функционал похож на браузерный )



Опять же, если вы думаете, что мы нашли LLM и всё такое — сообщу что нет.

Короче, Elastic без LLM-наворотов. Просто очищена исходная база, английские «c» сведены к русским «с», слеши в одну сторону, строки подрезаны по пробелам и так далее, регистр не играет значения.

Получилось вот что:

В чём прикол

Ну сделали поисковик по вычищенной базе комментариев и что здесь такого? Прикол в том, что у нас есть вес показа подсказки:

• Частота ввода — чем чаще подсказка использовалась, тем она выше.
• В зависимости от места ввода. Каждый терминал расположен на определённом месте, мы это место знаем, и знаем, что в архитектуре цеха к нему близко. То есть нас интересует не просто частотность строки в базе — мы ещё даём дополнительный вес за то, что она вводилась с этого места или рядом. То есть характерные для места причины всплывают выше.
• Свежесть. Если такой комментарий использовался недавно, есть шанс, что он понадобится снова — он всплывает выше. Дремучие комментарии 2010-х годов, соответственно, спускаются ниже, а их там довольно много.

Система работает просто, как колесо!

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

В общем, мы сыграли на человеческой лени. Гипотеза в том, что за следующие два года (да, да, у нас не розовые очки) рабочие естественным путём снизят количество используемых причин до более-менее реальных и у них всегда наверху будет релевантное. Соответственно, для того, чтобы строить красивые картинки и дашборды, не надо будет очищать данные и пытаться понять, как конкретно эти краны называются в этом цехе и почему в зависимости от цеха одна и та же аббревиатура может значить 5 разных вещей. Методологи автоматизированно определяют уже давно, как это влияет на производительность цеха, там развитый аппарат. Им нужны только чистые данные, и они будут.

100 мс

Чтобы это работало, нужно соблюсти условие показа подсказки за 100 мс. Мы с UX-специалистом посчитали, сколько пользователь готов ждать, чтобы не вводить творческие комментарии. Получилось, что граница где-то в районе 400 мс. Терпение у пользователей далеко не бесконечное. В ТЗ записали 100, потому что кто будет ждать больше 100 мс? И вот Elastic (точнее OpenSearch), правильно сделанный индекс с учётом весов и обычный запрос без нечёткого поиска.

Просто, дёшево, сердито, быстро.

Итог

Система несколько месяцев в эксплуатации.

Измеряем три метрики:

• Долю ответов внутри 100 мс (всё в порядке).
• Количество уникальных комментариев в неделю (сколько не воспользовались подсказкой).
• Долю уникальных комментариев в неделю.

За эти недели выяснилось, что, оказывается, за 14-то лет многое уже случалось (почти всё) и, просто назвав одно слово из проблемы, можно получить целый длинный комментарий.

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

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

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

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

— Мужики, а когда подсказки-то заработают? Поломались!
— Когда исправите? Ничего нормально сделать не можете!

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