Загадочное
Пребываю в некоторой задумчивости.
Один лжеюзер решил написать об опасностях ИИ:
Поскольку тратить месяцы на изучение алгоритмов поиска путей для робота-пылесоса программисту абсолютно не хотелось, то он решил эту задачу автоматизировать. И написал небольшую самообучающуюся программу - которая анализировала частоту срабатывания датчиков столкновения робота. Те варианты действий, при которых частота срабатывания датчиков снижалась, программа отмечала как “хорошие” (“вознаграждение”), а те, при которых повышалась, как “плохие” (“наказание”). Целью программы было максимизировать вознаграждение.
Результат: робот-пылесос начал ездить задним ходом, потому что сзади у него датчиков столкновения не было.
Этот пример наглядно демонстрирует основную проблему искусственного интеллекта - он очень хорош в поиске формального решения задачи, но понимание самой задачи у него отсутствует.
Еще сценарий, где ИИ "накосячил":
Задача: программа должна была собрать колебательный контур на 25 килогерц. “Вознаграждалось” увеличение амплитуды и усиление сигнала.
Результат: программа собрала радиоприемник, принимавший и усиливающий соответствующий сигнал из внешней среды.
И потрясающее моралитэ:
В этом и заключается основная проблематика - и опасность - применения искусственного интеллекта. ... А в том, что понимает он их исключительно буквально, и, как правило, толком не в состоянии объяснить, почему он делает так, а не иначе (он ведь и сам этого не знает - он просто пошел по пути, который давал формально лучшие результаты).
Потому немного букв, дабы и ибо.
Подобные тексты есть прямое и непосредственное следствие того явления, которое начало процветать в IT-сфере. Точнее, не в самой IT-сфере, но в среде пользователей и клиентов оной. У меня основным маркером для обозначения этого явления выступает слово "компьютерщик". Это когда некий гражданин интуитивно понимает, что ему нужен специалист в этой области, но погружаться в детали не хочет от слова совсем. Напротив, хочет чтобы один студент на половину минимальной ставки решил вопросы администрирования сети на 200 с лишком пользователей, настройку беспроводного оборудования и развертывания проводной сети в новом здании, поддержку 1С с терминальным сервером и вообще всех юзеров с офисным пакетом. И картриджи, разумеется - куда же без них! Парадоксальным образом этот вид сомнительного спроса даже иногда получает столь же сомнительное удовлетворение. А для обозначения людей, занимающихся этим видом заработка внутри IT придумали слово эникейщик.
В данном случае наблюдаем наиболее частое заблуждение, когда программиста путают с алгоритмистом и постановщиком задачи. Собственно, про алгоритмистов я не слышу уже очень давно, что бесконечно удивляет. Постановщик задач же как понятие применяется, но в несколько искаженном виде - обычно понимают под этим представителя клиента, который в рамках интервью объясняет неформальным языком консультанту то, чего хотел бы. А потом под формализованным изложением ставит свою подпись. Естественно, это совсем не та роль, о которой речь была изначально. И вообще это все про смешение ролей и функционала в рамках проекта.
Очевидно, что в рамках первого казуса с постоянным включенным задним ходом проблема вообще не уровня программиста, но уровней постановщика задачи и алгоритмиста. Если совсем кратко, то речь о том, что целевая функция была выбрана сомнительно. А именно применили упрощенное условие минимизации F(x), где переменной является только количество столкновений.
Это подобно тому, как если бы вы в известной транспортной задаче с доставкой наиболее дешевым способом товаров со складов потребителям исключили количество товара на конкретном складе а(i,j) и потребность конкретного потребителя b(i,j). Т.е. не сформулировали бы условие:
И ограничились бы только минимизацией целевой функции:
Естественно, вся бесконечность вариантов решения транспортной задачи дала бы "сбой" при таком подходе. И креативный гражданин даже смог бы написать критический текст на тему опасности методов линейного программирования. Но, как по мне, все же грамотнее просто взять и выписать нужные условия, не пренебрегая и не умалчивая в надежде, что кто-то там должен догадаться.
Кстати говоря, про пылесос имею вопрос! Если целевой функцией является время уборки помещения ака достижение состояния при котором нет неубранной площади за минимально возможное время, то езда задним ходом не означает ничего. Вот вообще ничего не означает, от слова совсем. Пусть ездит задним ходом, если при этом он убирает комнату за минимальное время при заданном уровне качества. Пусть хоть противолодочным зигзагом передвигается или рисует зловещие пентаграммы - это не имеет значения. И - да, на условие минимизации времени уборки площади с заданным качеством можно натянуть сверху условие по количеству бампинга. Но - потом, а не до и не вместо.
Элементарная же вещь, если задуматься на секунду. В excel каждый делал сортировку по двум столбцам. И там есть первичная сортировка, а внутри первичной будет еще и сортировка по второму столбцу. Хотите - сделайте по трем или четырем. Главное их указать в соответствии со своими приоритетами явным образом и станет счастье. И нет никакой "опасности". Опасность есть только в том случае, если не указывать и надеяться, что оно само там все вот это самое.
Дело вообще не в опасности и тем более не в буквальности. Дело в явности. Просто скажи, напиши, сформулируй или укажи иным способом условия, при которых ты лично будешь считать задачу решенной. Просто - скажи. Никто не должен догадываться вообще в этом мире о том, что ты там имеешь в виду, ты не пуп Земли и не кто-то там еще с бугра. Сними корону, собери пальцы так, чтобы в дверь проходили и вперед, корректно выписывать условия задачи про куски сахара и чашки.
Это те моменты, которые алгоритмисты старой школы выявляли на счет раз. И отправляли с кривой постановкой задач в сад, допиливать документы. А многоопытные постановщики задач таких глупостей не только не писали, но и могли подвести клиента к полезным мыслям в рамках интервьюирования. И добиться таки нужных ответов на правильные вопросы, а потом изложить их в чуть более формализованном и достаточном для начала разработки виде. Но мы же и ролей таких уже почти не помним, потому кушайте вот такие тексты про "опасности".
На самом деле опасности, конечно же, есть. Не столько в ИИ, сколько в компьютерной технике вообще. Компьютеру действительно плевать, кто там кнопки топчет - если топчет бездумно, то выдаваемый результат будет соответствующий. И ни звания, ни репутация, ни положение в обществе с имущественным цензом на этот результат не повлияют. Удивительно бессердечное создание, старшего прапорщика от контр-адмирала не отличает от слова совсем. А уж на то, кто там у кого папа, а кто чья жена ему и подавно без разницы. Абсолютно бездушная тварь, как с такими работать?
А так - ставьте правильно задачи и все будет хорошо. Сформулируйте то, чего хотите. И это не только и не столько про IT.
Поставлю по этому песню веселую песенку.
PS: А по второй задаче, с внешним сигналом, даже и сказать-то нечего. Некорректно поставленный эксперимент и полное непонимание процесса тестирования. Тоже можно поговорить про QA, но тут все настолько криво, что просто неудобно.
Один лжеюзер решил написать об опасностях ИИ:
Поскольку тратить месяцы на изучение алгоритмов поиска путей для робота-пылесоса программисту абсолютно не хотелось, то он решил эту задачу автоматизировать. И написал небольшую самообучающуюся программу - которая анализировала частоту срабатывания датчиков столкновения робота. Те варианты действий, при которых частота срабатывания датчиков снижалась, программа отмечала как “хорошие” (“вознаграждение”), а те, при которых повышалась, как “плохие” (“наказание”). Целью программы было максимизировать вознаграждение.
Результат: робот-пылесос начал ездить задним ходом, потому что сзади у него датчиков столкновения не было.
Этот пример наглядно демонстрирует основную проблему искусственного интеллекта - он очень хорош в поиске формального решения задачи, но понимание самой задачи у него отсутствует.
Еще сценарий, где ИИ "накосячил":
Задача: программа должна была собрать колебательный контур на 25 килогерц. “Вознаграждалось” увеличение амплитуды и усиление сигнала.
Результат: программа собрала радиоприемник, принимавший и усиливающий соответствующий сигнал из внешней среды.
И потрясающее моралитэ:
В этом и заключается основная проблематика - и опасность - применения искусственного интеллекта. ... А в том, что понимает он их исключительно буквально, и, как правило, толком не в состоянии объяснить, почему он делает так, а не иначе (он ведь и сам этого не знает - он просто пошел по пути, который давал формально лучшие результаты).
Потому немного букв, дабы и ибо.
Подобные тексты есть прямое и непосредственное следствие того явления, которое начало процветать в IT-сфере. Точнее, не в самой IT-сфере, но в среде пользователей и клиентов оной. У меня основным маркером для обозначения этого явления выступает слово "компьютерщик". Это когда некий гражданин интуитивно понимает, что ему нужен специалист в этой области, но погружаться в детали не хочет от слова совсем. Напротив, хочет чтобы один студент на половину минимальной ставки решил вопросы администрирования сети на 200 с лишком пользователей, настройку беспроводного оборудования и развертывания проводной сети в новом здании, поддержку 1С с терминальным сервером и вообще всех юзеров с офисным пакетом. И картриджи, разумеется - куда же без них! Парадоксальным образом этот вид сомнительного спроса даже иногда получает столь же сомнительное удовлетворение. А для обозначения людей, занимающихся этим видом заработка внутри IT придумали слово эникейщик.
В данном случае наблюдаем наиболее частое заблуждение, когда программиста путают с алгоритмистом и постановщиком задачи. Собственно, про алгоритмистов я не слышу уже очень давно, что бесконечно удивляет. Постановщик задач же как понятие применяется, но в несколько искаженном виде - обычно понимают под этим представителя клиента, который в рамках интервью объясняет неформальным языком консультанту то, чего хотел бы. А потом под формализованным изложением ставит свою подпись. Естественно, это совсем не та роль, о которой речь была изначально. И вообще это все про смешение ролей и функционала в рамках проекта.
Очевидно, что в рамках первого казуса с постоянным включенным задним ходом проблема вообще не уровня программиста, но уровней постановщика задачи и алгоритмиста. Если совсем кратко, то речь о том, что целевая функция была выбрана сомнительно. А именно применили упрощенное условие минимизации F(x), где переменной является только количество столкновений.
Это подобно тому, как если бы вы в известной транспортной задаче с доставкой наиболее дешевым способом товаров со складов потребителям исключили количество товара на конкретном складе а(i,j) и потребность конкретного потребителя b(i,j). Т.е. не сформулировали бы условие:
И ограничились бы только минимизацией целевой функции:
Естественно, вся бесконечность вариантов решения транспортной задачи дала бы "сбой" при таком подходе. И креативный гражданин даже смог бы написать критический текст на тему опасности методов линейного программирования. Но, как по мне, все же грамотнее просто взять и выписать нужные условия, не пренебрегая и не умалчивая в надежде, что кто-то там должен догадаться.
Кстати говоря, про пылесос имею вопрос! Если целевой функцией является время уборки помещения ака достижение состояния при котором нет неубранной площади за минимально возможное время, то езда задним ходом не означает ничего. Вот вообще ничего не означает, от слова совсем. Пусть ездит задним ходом, если при этом он убирает комнату за минимальное время при заданном уровне качества. Пусть хоть противолодочным зигзагом передвигается или рисует зловещие пентаграммы - это не имеет значения. И - да, на условие минимизации времени уборки площади с заданным качеством можно натянуть сверху условие по количеству бампинга. Но - потом, а не до и не вместо.
Элементарная же вещь, если задуматься на секунду. В excel каждый делал сортировку по двум столбцам. И там есть первичная сортировка, а внутри первичной будет еще и сортировка по второму столбцу. Хотите - сделайте по трем или четырем. Главное их указать в соответствии со своими приоритетами явным образом и станет счастье. И нет никакой "опасности". Опасность есть только в том случае, если не указывать и надеяться, что оно само там все вот это самое.
Дело вообще не в опасности и тем более не в буквальности. Дело в явности. Просто скажи, напиши, сформулируй или укажи иным способом условия, при которых ты лично будешь считать задачу решенной. Просто - скажи. Никто не должен догадываться вообще в этом мире о том, что ты там имеешь в виду, ты не пуп Земли и не кто-то там еще с бугра. Сними корону, собери пальцы так, чтобы в дверь проходили и вперед, корректно выписывать условия задачи про куски сахара и чашки.
Это те моменты, которые алгоритмисты старой школы выявляли на счет раз. И отправляли с кривой постановкой задач в сад, допиливать документы. А многоопытные постановщики задач таких глупостей не только не писали, но и могли подвести клиента к полезным мыслям в рамках интервьюирования. И добиться таки нужных ответов на правильные вопросы, а потом изложить их в чуть более формализованном и достаточном для начала разработки виде. Но мы же и ролей таких уже почти не помним, потому кушайте вот такие тексты про "опасности".
На самом деле опасности, конечно же, есть. Не столько в ИИ, сколько в компьютерной технике вообще. Компьютеру действительно плевать, кто там кнопки топчет - если топчет бездумно, то выдаваемый результат будет соответствующий. И ни звания, ни репутация, ни положение в обществе с имущественным цензом на этот результат не повлияют. Удивительно бессердечное создание, старшего прапорщика от контр-адмирала не отличает от слова совсем. А уж на то, кто там у кого папа, а кто чья жена ему и подавно без разницы. Абсолютно бездушная тварь, как с такими работать?
А так - ставьте правильно задачи и все будет хорошо. Сформулируйте то, чего хотите. И это не только и не столько про IT.
Поставлю по этому песню веселую песенку.
Click to viewPS: А по второй задаче, с внешним сигналом, даже и сказать-то нечего. Некорректно поставленный эксперимент и полное непонимание процесса тестирования. Тоже можно поговорить про QA, но тут все настолько криво, что просто неудобно.