Не надо додумывать :) В названии сказано про AutoML для citizen DS'а, соответственно целевая аудитория инструмента это бизнес-пользователи, а уже опциональная - ИТ спецы.
Бинарные данные необходимы, к примеру, в обработке геопространственных данных,
Геопространственные данные не являются структурированными, соответственно в таблицы и классический интерпретируемый ML не ложатся, а про нейронки мы и не говорим.
А на Azure, действительно возвращаться нет желания, он, кстати, тоже в петабайты данных не умеет и в отличные от табличных, так что нигде не потеряли, тем более последнее и не требуется, как я уже сказал.
Во-первых, мы ничего не сравниваем, а делимся опытом :)
Во-вторых, не надо мешать производственные бизнес-задачи и ИТшные kaggle-like задачи. В случае первых важно не количество данных, а технологичность и интерпретируемость получаемых моделей, которые вполне себе могут быть получены и на основе нескольких тысяч строк. В промышленности задачи решаются не за счет количества, а за счет качества и правильной постановки задачи.
Наш AutoML создавался на основе опыта работы с MS AzureML и решения тех задач, с которыми ранее сталкивались. Есть проекты с сотнями тысяч строк, загружаются и перевариваются такие датасеты без проблем. Бинарные данные использовать нет смысла. Они совсем не ложатся в пайплайн использования citizen DS'ами, потому что мало вообще какими инструментами поддерживаются, в отличии от классических таблиц.
на картинках в статье и вовсе десятки или сотни точек показаны (то есть когда методы машинного обучения вообще не эффективны).
Размер тест сплитов на кросс-валидации сравнивать со всем датасетом не корректно, тем более что шапы и другие графики могут строиться на подвыборках, при больших объемах)
Здесь идет речь не о воде которую кипятят, а о воде, направленной на охлаждение оборудования, в том чисте ТГ. После отработки она сливается в пруд-охладитель. На пути следования идут потери на сети и фильтрация (в почву) в пруду-охладителе.
По дизайну ничего удивительного, дизайнеры на self-service проекты подключаются только в случае продуктивизации, а вот в SSAMaLeT'е учли корпоративную палитру)
А в целом интерфейс ввода через BI системы делать
Мы не делаем интерфейсы ввода через BI, потому что прекрасно понимаем что инструмент абсолютно не для этой задач, да и в power BI такой функции нет. Именно по этому мы разработали собственный фреймворк, который позволяет создавать проекты в том числе с возможностью ввода данных человеком.
Да, вопрос. Как вы объяснили технологам смысл чисел на оси Y?
Как раз по причине сложности восприятия и объяснения чисел на оси Y (shap values) мы цвета очень редко включаем в обсуждения с бизнесом. В целом, придерживаемся такого подхода: shap values оцениваем на summary plot, по сути оцениваем относительность влияние всех параметров и фиксируем, что действительно те или иные параметры влияют больше остальных. А на dependency plots уже смотрим корректность корреляции, действительно ли этот параметр влияет в ту или иную сторону (очень редко обсуждая именно значения "силы влияния") в конкретном диапазоне на графике.
Цементит, Fe3C, явно входит в состав большинства сталей и чугуна. Просто в металлургии, на сколько я понимаю, принято рассматривать сталь не как химическую систему, а как физическую.
В металлургии, на этапе внепечной обработки (рассматриваемый в статье этап) сталь рассматривается как раз как химическая система. Вы приводите в пример хим. формулу цементита, но в металлургии рассматривается не просто перечень элементов, а их процентное содержание.
Разумеется, сталеварение появилось не вчера и уж точно намного раньше, чем machine learning. Как сталевары справлялись раньше? Опять же, с помощью нейросетей. Только не машинных, а естественных.
Говорится о том, как это работает сейчас и работало раньше на практике. Естественно вне производства и на самом производстве было множество разных методов, но эти методы показывают результат действий человека постфактум, не прогнозируя ничего (а еще и требуя время), а человек должен на что-то опираться, чтобы прикинуть сколько отдать сейчас (тот самый опыт), потому что процесс непрерывный и быстротекущий :)
Это средняя температура по больнице, с учетом температуры главврача и медсестер. И как вообще поступать с усредненным содержанием элемента, если одного легирующего сплава нужно много, а другого меньше?
Учитывая, что невозможно отследить когда ту или иную партию ферросплава добавляют в сталь, самым честным подходом было применить средневезвешенную химию поставок на истории и пересчитать сколько на каждую плавку отдавали чистого хим. элемента (по всему списку) в зависимости от известной на истории массы добавок.
Человек как и машина, пытается добрать химию самыми дешевыми ферросплавами, которые можно применять на текущую марку стали. Зная, сколько надо добавить чистого элемента на текущую плавку, оптимизатор как раз рассчитывает каких ферросплавов и сколько будет выгоднее всего отдать.
Тангенс 45 град. это 1.
Вы забываете про размерности осей, или изменив масштаб я изменяю угол прямой на графике?)
Ну хорошо, а что если в легирующем сплаве содержится больше кремния, чем в предыдущие разы,
Колебание хим. состава ферросплавов незначительно относительно средневзешанного, плюс, как писал выше, невозможно отследить путь ферросплава, для отслеживания потоков планируется проект, после которого можно будет внести улучшения в текущий :)
, а в стали кремний уже выжгли на предыдущем этапе и вносить его еще больше нельзя?
Для оптимизации учитываются и верхние и нижние границы по маркам сталей, соответственно если из-за какого-то ферросплава (который содержит много SI) мы можем уйти выше цели, то оптимизатор возьмет ферросплав с меньшим содержанием SI.
Не оценен долгосрочный эффект от ухудшения качества выплавляемых сталей.
Никакого ухудшения качества сталей нет, есть границы требований ОТ и ДО, все в границах удовлетворяет потребителя. Учитывая, что всем важна стабильность продукции (даже внутри границ), с учетом текущей системы мы как раз ее повышаем, потому что снижаем среднекв. отклонение химии, более года эксплуатации это подтверждает.
С логической стороны, при большом числе опытов, они и не могут отличаться т.к. математическая модель построена по уже имевшимся данным, а новые данные получаются в результате подгонки опытов под модель.
А вот тут Вы ошибаетесь, если бы мы прогнозировали отдачи ферросплавов, то да, мы бы просто повторяли за человеком, но мы прогнозируем коэфф-т усвоения, соответственно предлагаем человеку идти оптимальным путем, не обращая внимание на его прошлые "ошибки".
Пример: идет плавка очень идентичная плавке в истории, в истории на нее человек насыпал кучу ферросплава и находился вблизи максимума по химии, модель рассчитает, что на эту плавку коэффициент ~Kx, и с учетом него оптимизатор скажет, что нужно добавлять сильно меньше ферросплава (чем человек добавлял в истории), чтобы быть ближе к середине/низу требования по этой марке стали.
недостаток информации о настоящем составе сплава
Просьба не путать ферросплавы и сплав стали (марочный продукт). Информация о настоящем составе приготавливаемого продукта есть и используется для модели, пробы стали по-прежнему берутся, как и брались ранее, никакую ранее имевшуюся информацию ML'ем мы не заменяли)
Спасибо за развернутый ответ) Но Вы привели пример, где по левой оси у вас SHAP влияние по сути с разделением на два признака, у нас был один, а цвет - это лишь подкраска какое значение было у третьей (цветной) фичи.
Изображение с 3 переменными (shap.dependence_plot(..., interaction_index='auto')):
Изображение с 2 осями (shap.dependence_plot(..., interaction_index=None)):
Как можно увидеть, они полностью идентичны, просто из "цвета" можно вытащить дополнительные инсайты)
Нелинейность видна и на цветном графике, просто на цвет можно не обращать внимание, на корреляцию между базовыми осями он не влияет. А вот то, что цвет может усложнять восприятие, согласен, но почти всегда лучше не терять потенциально полезную информацию :)
Добрый день! R2 для всех химических элементов получился выше 0.85, MAE сильно зависит от химического элемента, потому что их волатильность и порядок значений в целом для марок сильно отличается, например: MAE для MN < 0,011, тогда как для V < 0,0015. Тестировали хим. элементы отдельно, примерно на 5000 плавок каждый.
Пробовали предсказание дельты относительно текущей известной химии (с учетом рекомендуемой отдачи), но, к сожалению, периодические выбросы на некоторых совокупностях параметров плавки все портили, потому решили усреднять на множестве предсказаний коэффициент, это дало нам стабильности. Также, учитывая важность признаков (самое важное для перепада по химии - отдача материала) плюс опыт технологов (относительно волатильности коэффициента усвоения), оставили подход описанный в статье :)
Любой продукт, находящийся в границах ГОСТа считается качественным, ниже ГОСТа, как и выше - брак. В целом, идея проекта в том, чтобы снизить отклонение от желаемого технологами значения, желаемое выставляется относительно базового с небольшим смещением к нижней границе.
Никаких автоматических воздействий на тех процесс пока что не применяем (кроме систем, связанных с ОТиПБ, где критично время отклика), т.к. это довольно рискованное мероприятие, да и требования там совсем другие, если интегрироваться с исполнительными механизмами АСУ ТП... Текущий уровень систем - рекомендации для пользователя, а он уже принимает решение.
Нейронные сети также практически не используются (ну разве что в Computer Vision), потому что довольно сложно интерпретируются, а пользователю важно знать причину той или иной рекомендации/прогноза, потому деревья решений, линейные регрессии и прочие интерпретируемые алгоритмы в связке с SHAP - наше все :)
Отвечу по тем вопросам, с которыми сталкивался сам в рамках направления DS :)
В первую очередь данные технологические агрегирует АСУ ТП, как ни странно, второй уровень консолидации данных, необходимых для конкретного проекта - уже БД самого приложения. Сложности могут возникать на этапе - как передать данные из АСУ ТП в БД приложения, если в АСУ ТП они хранятся в проприетарных форматах Historian хранилищ, на помощь приходят дополнительные коннекторы к таким хранилищам (например, стандартные вендорные, если таковые имеются, или самописные). Также могу быть проблемы с глубиной данных, которую хранит АСУ ТП, например 3-6 месяцев, что сильно усложняет аналитику, в таких случаях приходится начинать с изменения подхода к хранению данных. В консолидации данных в разрабатываемом приложении сложностей нет, сформирован устоявшийся стек/стандарты.
Обратное влияние на технологический процесс по результатам предиктива/решения задачи оптимизации осуществляется почти всегда "через человека", то есть человек получает подсказку и принимает решение по ее использованию (если не говорим про кейсы ОТиПБ, когда, например, необходимо автоматически остановить агрегат при нахождении человека в опасной зоне), потому что системы-подсказчики создаются в помощь человеку, а не на замену, плюс все прекрасно понимают, что машинное обучение в 100% случаев не может отработать идеально и при этом хорошо интерпретироваться. Один из примеров влияния на процесс "через человека" приведен в этой статье, про "Подсказчик по отдаче ферросплавов" планируем сделать отдельную статью.
В рамках проектной работы на проектах Цифровой трансформации используем Agile (дейли, демо, барометры, ретро, в общем "все включено"), незнакомые с этой методологией новые команды проходят обучение. При необходимости в рамках проектов команды могут также обучаться новым инструментам, вплоть до изучения конкретных технологий, которые необходимы для реализации проекта, ничего чересчур топорного или забюрократизированного не было замечено за полтора года работы в ЕвразТехнике ИС :)
Не надо додумывать :) В названии сказано про AutoML для citizen DS'а, соответственно целевая аудитория инструмента это бизнес-пользователи, а уже опциональная - ИТ спецы.
Геопространственные данные не являются структурированными, соответственно в таблицы и классический интерпретируемый ML не ложатся, а про нейронки мы и не говорим.
А на Azure, действительно возвращаться нет желания, он, кстати, тоже в петабайты данных не умеет и в отличные от табличных, так что нигде не потеряли, тем более последнее и не требуется, как я уже сказал.
Во-первых, мы ничего не сравниваем, а делимся опытом :)
Во-вторых, не надо мешать производственные бизнес-задачи и ИТшные kaggle-like задачи. В случае первых важно не количество данных, а технологичность и интерпретируемость получаемых моделей, которые вполне себе могут быть получены и на основе нескольких тысяч строк. В промышленности задачи решаются не за счет количества, а за счет качества и правильной постановки задачи.
Наш AutoML создавался на основе опыта работы с MS AzureML и решения тех задач, с которыми ранее сталкивались. Есть проекты с сотнями тысяч строк, загружаются и перевариваются такие датасеты без проблем. Бинарные данные использовать нет смысла. Они совсем не ложатся в пайплайн использования citizen DS'ами, потому что мало вообще какими инструментами поддерживаются, в отличии от классических таблиц.
Размер тест сплитов на кросс-валидации сравнивать со всем датасетом не корректно, тем более что шапы и другие графики могут строиться на подвыборках, при больших объемах)
Около месяца прошло с момента рекомендации от модели и ее выполнения из-за поломки.
Здесь идет речь не о воде которую кипятят, а о воде, направленной на охлаждение оборудования, в том чисте ТГ. После отработки она сливается в пруд-охладитель. На пути следования идут потери на сети и фильтрация (в почву) в пруду-охладителе.
По дизайну ничего удивительного, дизайнеры на self-service проекты подключаются только в случае продуктивизации, а вот в SSAMaLeT'е учли корпоративную палитру)
Мы не делаем интерфейсы ввода через BI, потому что прекрасно понимаем что инструмент абсолютно не для этой задач, да и в power BI такой функции нет. Именно по этому мы разработали собственный фреймворк, который позволяет создавать проекты в том числе с возможностью ввода данных человеком.
Дико плюсую! Перешел с дизера, там такое есть, теперь не хватает(
Как раз по причине сложности восприятия и объяснения чисел на оси Y (shap values) мы цвета очень редко включаем в обсуждения с бизнесом. В целом, придерживаемся такого подхода: shap values оцениваем на summary plot, по сути оцениваем относительность влияние всех параметров и фиксируем, что действительно те или иные параметры влияют больше остальных. А на dependency plots уже смотрим корректность корреляции, действительно ли этот параметр влияет в ту или иную сторону (очень редко обсуждая именно значения "силы влияния") в конкретном диапазоне на графике.
В статье про это ни слова)
В металлургии, на этапе внепечной обработки (рассматриваемый в статье этап) сталь рассматривается как раз как химическая система. Вы приводите в пример хим. формулу цементита, но в металлургии рассматривается не просто перечень элементов, а их процентное содержание.
Говорится о том, как это работает сейчас и работало раньше на практике. Естественно вне производства и на самом производстве было множество разных методов, но эти методы показывают результат действий человека постфактум, не прогнозируя ничего (а еще и требуя время), а человек должен на что-то опираться, чтобы прикинуть сколько отдать сейчас (тот самый опыт), потому что процесс непрерывный и быстротекущий :)
Учитывая, что невозможно отследить когда ту или иную партию ферросплава добавляют в сталь, самым честным подходом было применить средневезвешенную химию поставок на истории и пересчитать сколько на каждую плавку отдавали чистого хим. элемента (по всему списку) в зависимости от известной на истории массы добавок.
Человек как и машина, пытается добрать химию самыми дешевыми ферросплавами, которые можно применять на текущую марку стали. Зная, сколько надо добавить чистого элемента на текущую плавку, оптимизатор как раз рассчитывает каких ферросплавов и сколько будет выгоднее всего отдать.
Вы забываете про размерности осей, или изменив масштаб я изменяю угол прямой на графике?)
Колебание хим. состава ферросплавов незначительно относительно средневзешанного, плюс, как писал выше, невозможно отследить путь ферросплава, для отслеживания потоков планируется проект, после которого можно будет внести улучшения в текущий :)
Для оптимизации учитываются и верхние и нижние границы по маркам сталей, соответственно если из-за какого-то ферросплава (который содержит много SI) мы можем уйти выше цели, то оптимизатор возьмет ферросплав с меньшим содержанием SI.
Никакого ухудшения качества сталей нет, есть границы требований ОТ и ДО, все в границах удовлетворяет потребителя. Учитывая, что всем важна стабильность продукции (даже внутри границ), с учетом текущей системы мы как раз ее повышаем, потому что снижаем среднекв. отклонение химии, более года эксплуатации это подтверждает.
А вот тут Вы ошибаетесь, если бы мы прогнозировали отдачи ферросплавов, то да, мы бы просто повторяли за человеком, но мы прогнозируем коэфф-т усвоения, соответственно предлагаем человеку идти оптимальным путем, не обращая внимание на его прошлые "ошибки".
Пример: идет плавка очень идентичная плавке в истории, в истории на нее человек насыпал кучу ферросплава и находился вблизи максимума по химии, модель рассчитает, что на эту плавку коэффициент ~Kx, и с учетом него оптимизатор скажет, что нужно добавлять сильно меньше ферросплава (чем человек добавлял в истории), чтобы быть ближе к середине/низу требования по этой марке стали.
Просьба не путать ферросплавы и сплав стали (марочный продукт). Информация о настоящем составе приготавливаемого продукта есть и используется для модели, пробы стали по-прежнему берутся, как и брались ранее, никакую ранее имевшуюся информацию ML'ем мы не заменяли)
Спасибо за развернутый ответ) Но Вы привели пример, где по левой оси у вас SHAP влияние по сути с разделением на два признака, у нас был один, а цвет - это лишь подкраска какое значение было у третьей (цветной) фичи.
Изображение с 3 переменными (shap.dependence_plot(..., interaction_index='auto')):
Изображение с 2 осями (shap.dependence_plot(..., interaction_index=None)):
Как можно увидеть, они полностью идентичны, просто из "цвета" можно вытащить дополнительные инсайты)
Нелинейность видна и на цветном графике, просто на цвет можно не обращать внимание, на корреляцию между базовыми осями он не влияет. А вот то, что цвет может усложнять восприятие, согласен, но почти всегда лучше не терять потенциально полезную информацию :)
Добрый день! R2 для всех химических элементов получился выше 0.85, MAE сильно зависит от химического элемента, потому что их волатильность и порядок значений в целом для марок сильно отличается, например: MAE для MN < 0,011, тогда как для V < 0,0015. Тестировали хим. элементы отдельно, примерно на 5000 плавок каждый.
Пробовали предсказание дельты относительно текущей известной химии (с учетом рекомендуемой отдачи), но, к сожалению, периодические выбросы на некоторых совокупностях параметров плавки все портили, потому решили усреднять на множестве предсказаний коэффициент, это дало нам стабильности. Также, учитывая важность признаков (самое важное для перепада по химии - отдача материала) плюс опыт технологов (относительно волатильности коэффициента усвоения), оставили подход описанный в статье :)
Да, все верно :)
Любой продукт, находящийся в границах ГОСТа считается качественным, ниже ГОСТа, как и выше - брак. В целом, идея проекта в том, чтобы снизить отклонение от желаемого технологами значения, желаемое выставляется относительно базового с небольшим смещением к нижней границе.
Никаких автоматических воздействий на тех процесс пока что не применяем (кроме систем, связанных с ОТиПБ, где критично время отклика), т.к. это довольно рискованное мероприятие, да и требования там совсем другие, если интегрироваться с исполнительными механизмами АСУ ТП... Текущий уровень систем - рекомендации для пользователя, а он уже принимает решение.
Нейронные сети также практически не используются (ну разве что в Computer Vision), потому что довольно сложно интерпретируются, а пользователю важно знать причину той или иной рекомендации/прогноза, потому деревья решений, линейные регрессии и прочие интерпретируемые алгоритмы в связке с SHAP - наше все :)
Отвечу по тем вопросам, с которыми сталкивался сам в рамках направления DS :)
В первую очередь данные технологические агрегирует АСУ ТП, как ни странно, второй уровень консолидации данных, необходимых для конкретного проекта - уже БД самого приложения. Сложности могут возникать на этапе - как передать данные из АСУ ТП в БД приложения, если в АСУ ТП они хранятся в проприетарных форматах Historian хранилищ, на помощь приходят дополнительные коннекторы к таким хранилищам (например, стандартные вендорные, если таковые имеются, или самописные). Также могу быть проблемы с глубиной данных, которую хранит АСУ ТП, например 3-6 месяцев, что сильно усложняет аналитику, в таких случаях приходится начинать с изменения подхода к хранению данных. В консолидации данных в разрабатываемом приложении сложностей нет, сформирован устоявшийся стек/стандарты.
Обратное влияние на технологический процесс по результатам предиктива/решения задачи оптимизации осуществляется почти всегда "через человека", то есть человек получает подсказку и принимает решение по ее использованию (если не говорим про кейсы ОТиПБ, когда, например, необходимо автоматически остановить агрегат при нахождении человека в опасной зоне), потому что системы-подсказчики создаются в помощь человеку, а не на замену, плюс все прекрасно понимают, что машинное обучение в 100% случаев не может отработать идеально и при этом хорошо интерпретироваться. Один из примеров влияния на процесс "через человека" приведен в этой статье, про "Подсказчик по отдаче ферросплавов" планируем сделать отдельную статью.
В рамках проектной работы на проектах Цифровой трансформации используем Agile (дейли, демо, барометры, ретро, в общем "все включено"), незнакомые с этой методологией новые команды проходят обучение. При необходимости в рамках проектов команды могут также обучаться новым инструментам, вплоть до изучения конкретных технологий, которые необходимы для реализации проекта, ничего чересчур топорного или забюрократизированного не было замечено за полтора года работы в ЕвразТехнике ИС :)