Comments 67
Его подвёл коллега — он выразил своё отношение к коллеге.
По-моему, он там не "пид-регулятор насоса" хотел напечатать...
Как-то не бережливо. Куча работы: заставляете рабочих отчеты писать, их хранить надо, анализ данных делать. И ноль реакции на отчёты. А все это на случай "вдруг кому-то захочется на них посмотреть".
Честно говоря, в промышленности полно не просто специалистов, а целых отделов, которые заняты именно этим: пишут отчёты, которые вдруг кому-то будут нужны. Более того, многие эти люди будут сильно нервничать, если узнают, что их отчёты действительно кто-то будет смотреть - это означает, что возможно что-то произошло, причем не сильно хорошее. То, что люди пишут эти отчёты, для них вовсе не что-то новое наверняка. Раньше они вероятно делали то же самое в бумажном виде и тратили намного больше времени намного более бесцельно
Вообще-то не ноль.
Во-первых, данные о простоях регулярно используются, и рабочие это видят. Анализ проводится не только стратегически раз в полгода-год, но и ежемесячно: одни сотрудники вводят данные, другие их обрабатывают.
Во-вторых, точность анализа помогает выявить частые поломки, причины, оптимизировать закупки комплектующих и снизить издержки. Чем чище данные, тем лучше результат.
Данные о простоях используются в основном при расчете КТУ, где эта система внедрена. А на подобных предприятиях она много где. И да, рабочие это видят! Когда получают 2/3 от номинальной ЗП, и это еще не самый тяжелый случай. А то, что каждую неделю рвется шланг на агрегате №8 - ну на то и обслуживающий персонал, мы им километр шланга купили, пусть меняют, так дешевле.
Никогда не встречал, чтобы данные о простоях, собранные автоматической системой, как то влияла на начальство, систему снабжения и управления. Заявки все равно вручную заполнять, и ее еще надо "защитить", потому что "у завода нет столько денег", пока на пальцах не распишешь, что если они не купят частотник в запас, то простой им выйдет в месяц. Вот это уже аргументы, и программа их привести не сможет, хоть как подробно ни расписывай. Электронные заявки и комментарии - дополнительный плюс к "защите" заявки, но туда никто не смотрит - страшно. Это универсальное правило, действующее от мелких ИП до крупных концернов. Где не так - ну то значит эффективные совы недоглядели, есть еще куда оптимизировать.
О, частотник... Как-то поставили норию (для засыпания зерна в хранилище), так нужно было обеспечить нужную производительность. Закупили ковшички нужных размеров, так неделю эти ковшички монтируют, неделю грузят зерно, потом опять монтируют уже другие.
Выбили закупку частотника, смонтировали. Показали начальству, одобрило. Приезжает через некоторое время "А куда делись 20 тонн зерна?!" "Так усё погрузили начальникама".
У нас нужны эти данные для закупки частотников в будущем.
Сейчас конечно никто не чешется..резерв это дорого. Зато если сломается везут вертолетом, тк ну очень дорого если простой.
Я пытался в игру слов. Не бережливо - не соответствует принципам бережливого производства. По ним любые простои надо устранять. Вы скажете что их слишком много и это невозможно? Нет, после устранения основных причин поток жалоб сильно сократится, и можно реально на каждую жалобу реагировать.
Шланг порвался. Может купленные шланги бракованные и надо все разом менять? Или плановое тех.обслуживание станка забыли сделать? Лучше бы это расследовать и принять меры сразу, а не ждать когда это на статистике через полгода проявится.
С точки зрения производственника, который этих шлангов навидался, то есть меня:
Нет, купленные шланги не бракованные. Просто они рассчитаны на давление 300 Атм. И хорошо бы все, вот только термопласт-автомат при закрытии формы, а точнее при ее трогании, развивает давление в этом шланге порядка 1000 атм. Импульсно, поэтому проблема не проявляется сразу. Шланги на 1000 атм стоят уже "дорого", поэтому купим километр шланга на 300 атм согласно документации термопласт-автомата (это еще хороший вариант). Есть и другие приколы. Шланг и его резина рассчитан под спирт, а через него гонят масло...Шланги в порядке, а на масле сэкономили, или наоборот - распилили миллионы, купили масло но оно ест шланги. Масло дорогущее! Значит шланги виноваты! Или обслуга. Ну если шлангов запасти километр, то с обслуги надо наоборот, списывать.
Я как бережливец со стажем, этих отмазок наслушался достаточно. Конечно всегда есть причины почему оно так, и свалить вину на кого угодно можно, это дело не хитрое. Только пользы от этого нет. Шланги нормальные, но выходят из строя? Считайте расходником, делайте ТО и меняйте заранее. Не хотите менять постоянно? Ок, сделайте запасных, положите возле станка, поставьте быстро разъемные соединения, еще что-то как-то чтобы ремонтировать можно было за 5 минут.
Проблема в том, что никто не хочет брать на себя ответственность. И даже те же самые слесаря, вместо того, чтобы пару дней почесать репу и поставить быстросьемы (заказать, изготовить самим) как показывает опыт, не будут этого делать. Вот они будут мудохаться с заменой шлангов каждый месяц, закупать побольше хомутов и прочего, но переделать - "а нафига нам это надо? Нам за это не платят!". Их начальник мог бы принять такое решение - но это значит расходы, а любые расходы требуют обоснования. Если он пойдет к вышестоящему, и скажет "Мои рабочие заколебались эти шланги менять, давайте переделаем, купим то-то и то-то" то его пошлют. Вот если бы он сказал "простой линии пока они меняют шланги - 10 миллионов рублей в час" - вот это действует на вышестоящих отрезвляюще. Правда есть одно маленькое "но". Большинство высоких начальников стремятся экономить копейку, теряя рубль. Боязнь ответственности, некомпетентность - вот это и оно. А начиналось то все с простых шлангов. Пока наверху порядка нет, и внизу не будет. То же самое и с вашим "бережливым", когда вместо нахождения вот таких вот узких мест на производстве эти берегини придираются к ровности линий на полу, и чтобы инструменты были разложены в алфавитном порядке.
Я вам, в дополнение к плюсу, скажу, что даже сам у себя не всегда решаешься сделать как надо, даже умом понимая, что это в конечном итоге еще и дешевле будет в перспективе. Гидравлические шланги? Они самые - а ведь практически любые шланги с практически любыми соединениями можно сделать на заказ, есть специализированные мастерские, которые только этим и занимаются. Так сам себе - это ты одновременно и руководитель, и исполнитель, и источник финансирования, а заодно еще и единственный эксплуатант. А в конторе среднего и, особенно, большого размера с неизбежной многослойной административной структурой, крайне маловероятно, что будут созданы условия для вертикального обмена через несколько, а их много, иерархических слоев. Исключения я знаю по литературе, а не по личному опыту - некоторые японские концерны в недалеком прошлом.
крайне маловероятно, что будут созданы условия для вертикального обмена через несколько, а их много, иерархических слоев
Вот я о чем и толкую Чем больше слоев, тем ниже эффективность. Верхи вообще на низы забивают, хоть ты им тысячу выкладок с расчетами подготовь - просто потому что ты холоп и ничего тут не решаешь. Проблема больших корпораций. Все эти уровни начальников решают проблемы начальников, им проще так работать, но усложняют работу "низам", то есть по сути перекладывают всю работу на низшие адм. ступени.
Когда наверх таки удается пробиться, то реальное дело ускоряется как SR-71 до сверхзвука и - делается. А в обратку летят кляузы от промежуточных ступеней, мол, чего вы через голову прыгаете? Потому что им надо оправдать свое существование. Которое по сути есть нахлебничество.
Когда наверх таки удается пробиться
А ради чего? В чем профит того, кто боролся против бюрократии и даже, в виде исключения, разок победил? Если наниматель говорит (и впоследствии делает, это критически важно), что если есть годные идеи - приходите и озвучивайте, мы дальше их вместе обдумаем, стóящее применим, за получившееся премируем, то это один разговор. А если наниматель кормит линейный персонал лапшой про миссию, корпоративные ценности, про "мы семья" и прочий булшит с тимбилдингом, то даже довольно недалекие люди быстро научаются делать вид, что жрут эту лапшу тоннами и требуют добавки, в то же время убедительно делая вид, что работают. Но если нанимателя это устраивает, то кто я такой, чтобы пытаться обрушить идиллию своими рацпредложениями?
Правильно делают.
Ниже есть коммент про лень, согласен я полностью тут. Все эти подсказки они конечно облегчают жизнь и порой ты даже не хочешь писать например в поисковике и идешь и прям пытаешься найти в списке то что тебе нужно. К сожалению это точно никак не развивает нейронные связи и в целом снижает общий уровень интеллекта людей на земле...
Да, и почему он выдает подсказки из середины слова? Слово "импидор", извините мой французский, вменяемый человек начнет печатать с "имп...", а не с "пид..."
В данной задаче не подходит вариант с привычным "Т9", когда идет автозаполнение каждой последующей буквы. Здесь нужно угадать целую формулировку, в которой первое напечатанное слово не обязательно должно стоять в начале предложения.
Всегда найдётся человек, который засомневается, как пишется это слово: импидор или энпидор, и попробует найти по однозначно определяемым буквам...
Крутяк. Я когда-то решал похожую задачу, но ещё надо было 1) предложить юзеру варианты, которые вводили другие юзеры, не нарушая приватность, и 2) предложить хоть что-то, когда юзер ничего ранее не вводил вообще. Тогда я взял поисковик второго эшелона (он давал 500 бесплатных запросов на один айпишник в сутки), и стал подмешивать его подсказки к выдаче.
Рабочие вводят причины вручную и творчески, двух одинаковых не найти. У рабочего порвался шланг — он выразил своё отношение к шлангу. Его подвёл коллега — он выразил своё отношение к коллеге. Формулировки крайне редко повторяются.
И для того, чтобы облегчить работу аналитиков, вы решили избавиться от дополнительной информации о проблеме, сведя всё к конечному списку популярных вариантов?
Дальше аббривеатуры триз читать стало не интересно.
Пилил я как-то дашборд по "внутренней" системе автоматизированного перевода... Так вот, при составлении глоссария наиболее часто переводимых словоформ выяснилось, что дяди и тёти в дорогих костюмах и в бизнес-центре класса "А+++" очень быстро кинулись проверять, насколько хорошо система переводит более классические слова из трёх (и более) букв.
Дам еще подсказку, как повысить удобство такого фильтра. Можно бить исходные строки на слова и позволять вводить фильтр по совпадению начала каждого введенного слова с одним из слов в исходной строке (можно даже вообще без соблюдения порядка слов, но это дело вкуса)
Например, если в поиске введено
"пер сты"
то найдёт фразы
переделать стык
переделать сварной стык
и (если делать без учета порядка слов)
стык переделать
стык сварной переделать
Сначала такая фильтрация кажется странной, но она позволяет по первым буквам части слов длинной фразы очень быстро находить такие фразы. В нашей системе такой поиск используется. При этом фильтр с учетом деления на слова считается просто динамически, в момент применения фильтра (т.е. разделенные слова мы не храним, а каждый раз просто "пересчитываем" удовлетворяет ли каждая фраза фильтру, это довольно быстро если фраз меньше 10 тысяч и если они не слишком длинные).
Как пользователь, могу только позавидовать вашим клиентам. Мне по долгу службы приходится пользоваться одной "Интеллектуальной системой...", которой ее создатели очень гордятся. У нее уже есть десятки тысяч вынужденных пользователей, насколько я знаю. Несколько лет назад я ввязался в смертельный бой со службой поддержки этой ИС (который, разумеется, проиграл). Но один эпизод этого боя настолько попадает в тему этой статьи, что мне захотелось про него рассказать. Речь про интерфейс ввода данных - а именно, выпадающий список
Дело в том, что 90% работы юзера в этой ИС - это ввод туда "личных данных"
Я даже не буду тут говорить, что почти все эти данные уже есть в другой общедоступной системе
гораздо менее глючной. Причем туда они загружаются полуавтоматически, без усилий со стороны юзеров. Но импортировать эти данные в ИС почему-то нельзя. Ни автоматически (они там между собой оргвопросы не порешали), ни вручную (если я выгружу свои личные данные из второй системы в стандартном текстовом виде, то корректно загрузить их в себя "Интеллектуальная система..." почему-то не может. Наверно, не любит делать "тупую работу", она ж интеллектуальная? ;-).
Ну да ладно, не буду уходить далеко от темы статьи
Так вот, совершенно типичное действие пользователя "Интеллектуальной системы..." - это выбор страны. Учитывая, что 90% пользователей там из РФ, и что в 80% случаев надо выбрать Россию, то было бы логично ожидать, что в выпадающем списке РФ будет на первом месте, да? А вот и не угадали! В выпадающем списке страны перечислены в алфавитном порядке! Причем окошко прокрутки даже на моем огромном экране минимальное - около 10 строчек. Надо бросать клаву (я же занимаюсь вводом, т.е. преимущественно набираю или копирую текст), брать мышку, и листать, листать, листать....
Впрочем, создатели списка все-таки не совсем идиоты. Они (ура!) оставили мне возможность сначала щелкнуть мышкой по кнопке раскрытия списка, а затем вновь взять в руки клавиатуру и ввести первую букву! Ура!!! Я нажимаю "R" и сразу вижу список стран на R! Но где же РФ? А, она опять не поместилась в окошке... Неужели надо снова брать мышку и листать? Но нет, я ж умный! А попробую-ка я ввести Ru (в руках-то уже снова клавиатура). Теперь-то я попаду куда надо, верно? А вот и нет! Снова не угадали! Теперь у меня в окошке список стран не на "Ru", а на "U"!
Если быть честным
то при очень быстром наборе "Ru" список все-таки воспринимает вторую букву, как буквосочетание, и работает правильно. Проблема, однако, в том, что в период активного ввода данных основной массой пользователей (это конец февраля-март) сервер "Интеллектуальной системы..." всегда перегружен, и система постоянно "полуподвисшая", так что тайм-аут почти всегда превышается, и буква "U" интерпретируется, как начало нового слова.
Я бы не стал тут все это писать, если бы баг со списком был бы единственным
Чего стоит хотя бы требование ее авторов к юзерам никогда не ошибаться при вводе, набирая многие тысячи символов в интерфейсе, который буквально принуждает к ошибкам. А поскольку внутренняя БД организована там довольно сложно, однажды введенная ошибка при каждом следующем пополнении базы мультиплицируется, отображаясь из одной таблицы в другую. Там появляются некорректные записи-дубликаты. Но самый главный прикол в том, что эта вторая таблица также отображается на первую, поэтому каждый дубликат во второй таблице при следующем пополнении базы рождает несколько новых ошибок в первой таблице. И так по кругу. При этом инструменты по исправлению этих ошибок либо глючат, либо требуют административных прав доступа. А наиболее доступный для обычного юзера протокол - это:
1) Удалить из базы все свои глючные данные (которые он, возможно, вводил часами). Фича в том, что к каждому элементу базы данных обычно привязано несколько юзеров, поэтому при такой операции их данные тоже будут удалены
2) Самостоятельно договориться с другими юзерами, которых косвенно затронула эта ошибка, чтобы они самостоятельно удалили из базы введенный ИМИ контент, который был затронут исходной ошибкой в ходе ее мультипликации
3) После этого - заново ввести в базу все удаленные данные всем участвующим в процессе юзерам. Причем НЕ ОШИБАЯСЬ!
Мы писали в поддержку этой "Интеллектуальной системы..." талмуды на много-много страниц. Изредка (далеко не всегда!) оттуда приходили ответы. Как вы думаете, с каким содержанием? А вот и снова не угадали! Основной смысл этих ответов сводился к двум пунктам:
1) а чего Вы хотели? Система ж бесплатная. Так что пользуйтесь, чем дают.
2) Ну а что касается всяких неудобств и ошибок - так это ж вы сами себе злобные буратины! Ибо начали работать с системой, не прочитав справку! Хотя там на первой странице написано: "Прочтите СНАЧАЛА справку!!!". В которой, в свою очередь, черным-по-русскому сказано: "ОШИБАТЬСЯ при работе с системой НЕЛЬЗЯ!!!"
В общем, надежду достучаться до руководства мы давно потеряли. Это все равно, что писать в пустоту. Да и отдельные костыли в ней (для наиболее массовых багов)
иногда все-таки появляются
Но с таким скрипом, что у меня возникает впечатление о неустранимых архитектурных проблемах. Что исходная архитектура просто не была приспособлена к масштабированию. Представьте себе, что Вы сделали систему для учета своих личных домашних вещей. Строго в кругу семьи. И завели в базу "шкаф в комнате", "полка на кухне", "тумбочка в ванной". Для одной квартиры этого описания хватит. А потом Ваша система понравилась руководству, и ее решили внедрять по всей стране сразу. И в базе появились тысячи одинаковых "шкафов в комнате". А еще там лежат "красные полотенца". Которые должны быть привязаны к конкретному шкафу. Только вот совершенно одинаковых шкафов в системе теперь полно, и к какому из них привяжется Ваше "красное полотенце" в процессе ввода - одному богу известно. В результате Ваше полотенце привязывается к шкафу в другой стране. А потом приходит Ваша жена, ей надо в душ, а в Вашем шкафу все еще нет полотенца. Естественно, она вводит его в систему повторно. После чего у лично вашего полотенца появляются точные дубликаты (наряду с почти неотличимыми в интерфейсе системы аналогичными полотенцами от других хозяев)..
Наутро в систему входит Ваш сын, чтобы ввести туда "одеяло". Он гораздо умнее, он хочет убедиться, что привязывает его именно к нужному шкафу. Да и авторы системы не дураки - теперь при вводе данных можно проверить - а что уже лежит в этом шкафу? Поэтому он выбирает из всех доступных шкафов именно тот, где лежит то самое "красное полотенце". Ну и какой вероятностью это будет Ваш шкаф, а не какой-то другой, если совершенно одинаковых полотенец в системе уже штук пять?
В общем, смысл это сообщения сводится к трем основным тезисам:
1) Не каждое восхитительно работающее в камерных условиях приложение можно масштабировать на всю страну без проблем. Иногда для этого лучше сразу переписать ядро и переиначить структуру баз. Но вот что делать, если начальство этого не понимает, и не закладывает соответствующие бюджеты - это вопрос...
2) Если автор однопользовательского приложения, с которым он работает сам, заложил в интерфейс принцип "не ошибайся", то это его проблемы. Но когда основанное на этом принципе приложение масштабируется на многие тысячи юзеров - то это свинство и профнепригодность.
3) А также у меня есть слабая надежда, что у кого-то из присутствующих здесь разработчиков "Интеллектуальной системы..." (уверен, они сразу поймут, о чем речь) наконец проснется профессиональная гордость. И что он начнет более ответственно относиться не столько к своему коду (вполне возможно, что этот код неплохо написан и идеально отвечает ТЗ), но и к тем принципам и задачам, на которые опираются эти ТЗ. И попытается все-таки как-то на своем уровне что-то объяснить руководству. Потому что со стороны вынужденных клиентов достучаться до него невозможно.
P.S. И чтобы не быть совсем уж жалобщиком-попрошайкой
добавлю
что в 2020-21гг я составил баг-репорт в нескольких частях по наиболее злободневным проблемам юзеров этой "Интеллектуальной системы..." (так получилось, что мне тогда приходилось помогать многим коллегами при работе с ИС, и я раз за разом упирался в одни и те же грабли, что и послужило поводом для формализации баг-репорта).
Весной 2023г, когда нам в очередной раз пришлось пополнять базу данных "ИС", основная масса из этих проблем еще не была решена. И принципы разговора с юзерами тоже не поменялись. Увы.
Но! Если вдруг разработчики "Интеллектуальной системы..." поменяют свою позицию, и выразят желание всерьез рассматривать такие баг-репорты (и даже что-нибудь исправлять), то я готов заново перетестировать все замеченные мной баги и подготовить отчет, актуальный на сегодняшний день.
я ввязался в смертельный бой со службой поддержки этой ИС (который, разумеется, проиграл)
Мам, я разговариваю с мертвецом!
Не знаю, о какой системе идет речь, вспомнил про сайт РЖД, а именно систему покупки билетов.
Прикол в том, что ее поведение разное в веб-версии и приложении. Казалось бы, зачем внутри использовать два разных движка?
Отдельная история - с ограничениями на покупку билетов. Которые динамически меняются, зависят от каких-то сезонных акций и ретроградного Меркурия. Но выглядит это обычно так: при невозможности продать билеты (а мне, соответственно - купить) система просто выкидывает на какой-то стартовый экран. Без каких-либо объяснений, сообщений об ошибках и т.д.
Отчаявшись, мы решили попробовать купить билеты в приложении, и, о чудо - оно сумело выдать явную причину вроде "не разрешается одновременно покупать столько-то билетов при таких условиях". Почему сайт это же не может выдать?
Еще я слышал, что на сервисах вроде туту.ру этих же ограничений нет, и сайтом пользоваться проще и удобнее.
Я вот вспоминаю то приложение над которым мы работаем. Клиентов много, очень.
Традиция что если приложение не получает ожидаемый ответ - клиенту показываем сообщение вида "упс что-то пошло не так, наверно у вас VPN". Даже если само приложение - знает, даже если от бэка пришел (и был записан в лог) статус-код по которому можно бы понять, даже если от бэка пришел ответ на русском языке (ну да - там тексты видимо понятные среднему пользователю хабра но совсем не факт что понятные среднему пользователю пикабу) что не так (и был записан в лог).
Так пусть бы хоть что-то написало. А то просто молча либо никак не реагирует на нажатие кнопки "Далее", либо выкидывает на стартовый экран, также молча. Пусть бы даже какое-то невнятное сообщение было - "operation timed out", "нет связи с базой данных" или "невозможно завершить операцию". Это хотя бы как-то могло навести на мысль о причине проблемы. А так можно хоть зазвониться в горячую линию РЖД, там наверняка будет сидеть ничего не знающий оператор, который ответит что-нибудь в духе "Попробуйте еще раз позже".
Одно только слово «железнодорожный» можно написать десятками способов — жд, Жд, ЖД, ж/д, ж\д, ж /д, ж д, Ж д, ЖД!!! — и так далее. С вывернутыми слешами, двойными пробелами и другими творческими формулировками.
И это ещё без учёта опечаток или ошибок. Когда вбивают "второпласт" или "фтулка", то никакая нормализация по регистру и числу спецсимволов в нормальный вид это не приведёт.
Не будьте столь категоричны. Есть метод триграмм, есть фонетические алгоритмы
Есть метод триграмм, есть фонетические алгоритмы
Это все тонкий баланс между "не найти слово с опечаткой" и "найти кучу посторонних слов, потому что алгоритму приглючилось, что они похожи на нужное". Второе обычно бесит сильнее, так что лично мне хотелось бы, чтобы поисковые алгоритмы давали больший приоритет тому, что ввел пользователь, а не тому, что они сами нафантазировали.
В общем, мы сыграли на человеческой лени. Гипотеза в том, что за следующие два года (да, да, у нас не розовые очки) рабочие естественным путём снизят количество используемых причин до более-менее реальных и у них всегда наверху будет релевантное.
Не боитесь, что лень выйдет на следующий уровень, и рабочие начнут просто не задумываясь выбирать первый вариант? Он же самый частый - значит, вероятность его повторения самая высокая - ну так и вероятность выбрать не то минимальная, и зачем задумываться? Пусть начальство думает, нет?
В нашей компании развитие производственной культуры стоит в топе задач и она сейчас на высочайшем уровне. Сотрудники понимают какая ответственность стоит перед ними и какая работа происходит после того, когда он ввел данные. Можно и без «подсказчика» написать всё что угодно, если ты не вовлечен в процесс. Вот вы например забивая в поисковике нужные слова и видя, что первая строчка вам не подходит, все равно используете её?
Поисковик в сети - плохой пример. Всегда ли легко понять, что первая строчка не подходит? Может, как раз подходит?
Я искренне рад, если все ваши сотрудники хорошо понимают, какая на них ответственность, и что происходит после того, как они вводят данные. Но, все-таки, полностью ли здесь исключена вероятность ошибки? Человека может что-то отвлечь, он может быть не в духе, не очень хорошо себя чувствовать и т.д. Он может быть новичком, в конце концов. Имхо, здесь бы еще добавить обязательное подтверждение выбранного варианта другим сотрудником (более опытным, начальником, например).
Можно и без «подсказчика» написать всё что угодно
Можно, но в статье же как раз описаны недостатки такого подхода.
Делал подобный подбор товаров и контрагентов в 1С году так в 2003-2004. Штатными средствами 1С работало чудовищно долго, к дбф версии прикрутил фокспрошный драйвер через ADO. Скульщикам было проще, они сразу могли прямой запрос сделать. Потом и для дбф сделал прямые запросы через 1sqlite.
Делали как-то автодополнение фамилий, имён и отчеств. Бралось просто из справочников (но справочники иногда дополняются вручную). Из особенностей - фильтр по полу, то есть для женского пола показывались только женские имена, для мужских - мужские.
Прежде, чем так напрягаться и привлекать тяжелую артиллерию, можно было обратиться к опыту четверть вековой давности - открыть абсолютно любую программу для ведения медицинских карточек, а именно процесс сбора анамнеза и вы бы увидели решение своей проблемы.
Кстати, этим вы напомнили мне экспертные системы. Не знаю, насколько здесь применимо и как стабильно работало бы.
открыть абсолютно любую программу для ведения медицинских карточек, а именно процесс сбора анамнеза
Слышал, как в одной поликлинике пытались пробиться через такую систему. В какой-то момент в выпадающем списке просто не оказалось нужного варианта, а пока вариант не выберешь, не даёт дальше пройти, и вбить свой вариант нельзя. А если выберешь что-то неподходящее, там дальше какие-то еще более неподходящие варианты действий были доступны вроде записи не к тому врачу, который нужен.
Мой опыт четвертьвековой давности говорит, что в большинстве питерских поликлиник у врачей никаких комплюктеров и в помине не было, а карточки велись от руки.
и вы бы увидели решение своей проблемы
Нет под рукой такой программы, но интересно узнать какое же в итоге решение проблемы?
PS: вы столько слов ругательных написали, а рассказать как надо не захотели (. Прямо как в случае из жизни:
Если написать на форуме "помогите решить проблему Х", то тебе вместо помощи все пошлют и скажут какой ты недалёкий. А если напишешь "смотрите как я решил проблему Х (очевидно не правильно)", то сразу налетят люди которые скажут что ты тут ошибся, и надо было вот так.
Для информации, очень неудобно когда список вариантов не влезает в экран и приходится листать, да варианты которые не относятся к работе, да и дубликаты ответов (изменена одна буква) тоже как то странно выглядит и занимают полезное место.
Не знаю, сталкивались ли с программой "Навигатор образования" для школ. Сейчас, чтобы даже в бесплатный школьный кружок ребенка отдать, необходимо обязательно записаться через эту систему. Это тихий ужас. Огромные выпадающие списки на 100500 вариантов, среди которых нужно найти нужный среди неочевидных названий, и приходится гадать, то ты выбрал или нет. Поиск по названию курса/кружка не работает, хотя поле для поискового запроса есть.
Рабочие вводят причины простоя разными словами, от души. «Шланг порвался»,
Объяснительная вспомнилась
Спасибо за статью. В духе хабра, которого уже нет. Буду рад прочитать о результатах через год.
Было много безуспешных попыток придумать классификатор комментариев. Каждый раз всё упиралось в потрясающее разнообразие жизни, успевать за которым не смогла бы даже сотня ответственных поддержаторов.
И не нужно. Достаточно классификатором покрыть 80% часто-используемого, а для остального уже произвольное поле (причем заполнение произвольного поля должно быть более трудозатратным, нежели выбор из списка, иначе из-за лени и отсутствия проверки все выборы станут произвольным полем).
Еще классификатор позволяет не собирать лишнего - вот когда детализация проблемы "сломался такой то блок" не нужна (до "сломался элемент х из блока"), никто не сможет ее использовать для какой-то пользы. В варианте "комментарии пишут сами себя" вы получили какой-то промежуточный классификатор, который аналитик будет отображать на реальный классификатор для чего-то полезного.
И у этого промежуточного классификатора проблем тоже немало, хотя это огромный прогресс относительно сканирования причин в произвольном тексте.
Когда уже сделаете голосовой ввод?
А что если вводить будут похожее по смыслу слово? Может есть смысл добавить словарь синонимов хотя бы для части терминов?
Найдено 500 тысяч якобы уникальных комментариев - надо помочь в анализе.
-- как разобрались с существующими данными?
-- ТРИЗ!
а, простенькую ЛЛМ, нет? или хотя-бы fuzzy search, даже этого нет?
Сдается мне, что рабочий, смежников, которые не прислали продукцию, не пид-регуляторами хотел назвать...
Недорабатывает ваш ИИ, получается...
Модерацию кометов надо приделать, что бы ответственный человек каждый комет в какую то кассификацию закидывал. Возможно переформулировал комент, при этом оригинал конечно надо сохранять.
После смены пять минут потратить можно, или раз в неделю полчаса, простои же не по пять раз на дню случаются ?
Главное добавить причину "другое", и вот когда этого "другое" становиться много, залазить в коменты и дорабатывать классификатор.
Классификаторы видимо надо делать локальные для каждого цеха и может быть станка
Ребята, спасибо за крутую идею! Как раз такая сейчас стоит задача в цехе и потом примерно к тем же мыслям - что ллм здесь излишне применять. А есть код или пример похожей реализации где-нибудь на github? Задача прямо 1 в 1.
Не советую. Это ж пиар чистой воды. Подумай. кейс был такой: рабочие не понимают нафига это надо и заполняют на халяву. Что стало теперь? Что-то выпало примерно похожее - нажал и пошел дальше. Я уверен, что с момента внедрения уникальные записи появляться перестали и учет перешел в глобальный формализм. Единственный плюс это аналитикам будет проще это свести. Если и делать унификацию на таком уровне, то это только с фиксированными справочниками оставляя возможность внести произвольный комментарий и полем "другое", которое регулярно анализировать и актуализировать справочник. А самое главное работать с персоналом - объяснять зачем это нужно, почему нужно делать именно так и какая от этого польза, на реальных примерах.
Тема интересная, только раскрыта как рекламный буклет. Побольше технических аспектов - на чем сделали, какие библиотеки использовали, какая архитектура системы
Я угадаю, что рабочий цеха хочет ввести, с трёх букв