На сегодняшний момент в современных ИИ отсутствует очень важная деталь, без которой любой, даже самый мощный ИИ не сможет сделать того, что мы называем мышлением.
Не существует универсального ИИ. Любой ИИ проектируется и создается для какой-либо цели. И если посмотреть на окружение этого ИИ, то можно увидеть, что ИИ может управлять очень ограниченным числом рычагов. С точки зрения мышления, ясно-понятно, т.к. в каждой конкретной области могут быть тысячи датчиков и регуляторов — но все на одну тему.
Чтобы создать мышление нужно сначала понять, как оно устроено. Но лично мне кажется, что сложность данной задачи превышает наши возможности. Да, у нас очень большая научная база. В университетах мы изучаем только ядро, и тех, кто понимает это ядро, уже очень маленький процент. А если теперь смотреть переферию, то на конце каждого луча работает всего несколько светил науки, которые могут сделать что-то качественно новое. А ведь нужно еще проложить связи между этими лучами. ИМХО, время, требуемое для освоенния информации, необходимой для создания мышления, превысит время жизни человека. Упремся в физическое ограничение. :-)
А что может сделать ИИ без мышления и без рычагов воздействия на окружающий мир? Выдать неверные данные, принять неверное решение, верно? Стало быть, не нужно использовать то, что не умеешь использовать.
Можно возразить, что мы часто используем то, что мы не понимаем, так? Но не забывайте, что при этом есть те люди, кто это хорошо понимает, и если что — сможет помочь. А вот такие штуки, которые никто не понимает, как они работают — вот это уже опасно. Только вовсе не тем, что это мысляший разум, желающий тебе смерти. :-) Так же, как детям опасно играть с ножом — не больше и не меньше.
Видел я один раз алгоритм, который вычислял число «Пи».
Алгоритм был в 6 строк кода, использовал около 8 переменных, одна из которых — массив.
Понять, что он делает, было совершенно нереально, пока не запустил и не увидел результат.
Но это простой случай.
А теперь представим, что вместо операций над переменными используются операции над интерфейсами внешних систем (той же OpenGL, например).
Разберетесь ли Вы в том, что делают эти 6 строк кода?
Правильнее даже задать вопрос по другому.
Разберетесь ли Вы, что делает эта функция? Каков ее смысл?
IMHO, в большинстве случаев Вам придется изучить несколько мест использования этой функции, чтобы это понять.
… А в это время пользователь бьется головой о неработающий банкомат, т.к. до следующего он добежать уже не успеет, а сегодня — последний день оплаты ипотечного кредита…
Ага, и на ней нет формально закрепленного уровня ответственности.
Разрабатывал бы он софт для систем жизнеобеспечения — пел бы совсем другую песню.
:-)
Просто нынче «разработчик» — слишком расплывчатое описание профессии. Чтобы понять сложность и уровень ответственности, нужно уточнять контекст.
Agile строится на доверительных отоношениях в команде.
Если их нет — никогда не взлетит.
Тут менеджер хороший нужен, который видит проблемы взаимодействия.
Разработчик на то и разработчик, чтобы разобраться в проблеме.
Что мешает интерполировать процесс разработки системы на жизненные ситуации?
Системный анализ работает не только с автоматическими системами.
Старшие разработчики также хорошо работают с автоматизированными системами (человек-машина).
Что мешает заранее начать разбираться с системами типа «человек-человек», т.е. с принципами работы организаций?
Тем более что ситуация по развитию организаций всем более-менее известна, и освещается на множестве ресурсов.
И если разработчик не разбирается в этом, это говорит о том, что есму это не интересно — а в этом случае не нужно туда и лезть. А раз уж полез — будь добр, разберись в правилах игры, и построй стратегию.
И если разработчик этого не может — у него либо особенности характера, несовместимые с этим видом деятельности (опять же — тогда не стоит и лезть), либо банальная лень.
Умные постоянно участвую в разного рода олимпиадах
Мне это в свое время надоело.
Я люблю решать сложные задачи, но мне не нравится постоянно находиться в состоянии цейтнота.
Поэтому я не участвую в олимпиадах, но регулярно решаю разные интересные задачки на логику.
При этом часто даже нет смысла писать код — если алгоритм понятен, и его сложность можно оценить без кодинга, я на этом останавливаюсь. Тратить время на кодинг в данном случае является нецелесообразным — лучше закодить какойн-ть полезный инструмент, который позволит убыстрить написание или анализ кода, от этого куда больше пользы.
Есть такая черта у некоторых людей — нежелание разбираться в деталях.
В нашей профессии без этого нельзя. Не хочешь разбираться — не ходи в разработчики.
И еще одна профессиональная черта — внимательность.
Если не можешь гарантировать полноту анализа в указанном контексте — значит, рано еще называться разработчиком.
Как правило этих двух составляющих достаточно для того, чтобы стать полноценным разработчиком — со временем разберешься со всем, чем нужно, и будешь точно знать, чего тебе не хватает в каждом конктретном случае, и, соответственно, сможешь придумать, каким способом это можно покрыть.
И когда приходит такое просветление, мир перестается делиться на правильное и неправильное, удобное и неудобное… Вместо этого мы попадаем в мир связей, определяем нужные целевые точки, и просто идем к ним кратчайшим путем (расстояние = значение весовой функции по целевым показателям).
При владении базой, на которую она опирается — да, не сложно.
Но эта база примерно равна уровню подготовки хорошего студента после гос. экзамена по вышке. :-)
Мне хоть слова и знакомы, но я помню, что за ними скрываются абстракции разных порядков, а также энное количество связанных с ними теорем, которые их увязывают в единую систему. И чтобы действительно понять статью, нужно это все вспомнить, восстановить связки. А это довольно тяжело, если не пользоваться этим постоянно.
:-) Знаете, называться инженером — значит взять на себя ответственность за работу системы.
В этом случае любая ошибка в ее работе указывает на некомпетентность. И никакие сроки в данном случае не могут являться оправданием. Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений. IMHO, реальных инженеров в IT очень мало.
Я бы выразился проще — разработчик должен уметь мыслить системно и быть гибким. :-)
Умение адаптироваться под изменяющиеся условия — одно из главных умений.
Нужно придумать алгоритм — раскопал аналоги, скрутил решение, проверил на примерах и на краевых условиях.
Нужно настроить сервер — полез в доки, мануалы, нашел примеры, подкрутил под свой случай.
Нужно довести «хотелку» до тех. задания — договорился с заказчиком, детализировал сценарии, согласовал дизайн.
Но!
Все компании работают по-разному, и в обязанности разработчика вменяют самые разные вещи. Где-то специализация более узкая, где-то менее. Иметь широту обзора и умений полезно, но не всегда необходимо.
А вот умение обнаружить причину какого-либо поведения системы, имея на руках только частичные данные, и восстановить все возможные варианты развития событий, не пропустив ни одного — без этого просто нельзя. Если разработчик не способен обеспечить полноту анализа, или хотя бы обозначить границы этой полноты — это серьезный минус. Для нашего брата «не могу», «не хочу», «не умею» — не позволительная роскошь. Да, бывают ошибки, куда без них. Но бросить систему на произвол судьбы — это непрофессионализм.
Зависит от того, насколько эффективно собеседующий умеет определять уровень подготовки :-)
Не существует универсального ИИ. Любой ИИ проектируется и создается для какой-либо цели. И если посмотреть на окружение этого ИИ, то можно увидеть, что ИИ может управлять очень ограниченным числом рычагов. С точки зрения мышления, ясно-понятно, т.к. в каждой конкретной области могут быть тысячи датчиков и регуляторов — но все на одну тему.
Чтобы создать мышление нужно сначала понять, как оно устроено. Но лично мне кажется, что сложность данной задачи превышает наши возможности. Да, у нас очень большая научная база. В университетах мы изучаем только ядро, и тех, кто понимает это ядро, уже очень маленький процент. А если теперь смотреть переферию, то на конце каждого луча работает всего несколько светил науки, которые могут сделать что-то качественно новое. А ведь нужно еще проложить связи между этими лучами. ИМХО, время, требуемое для освоенния информации, необходимой для создания мышления, превысит время жизни человека. Упремся в физическое ограничение. :-)
А что может сделать ИИ без мышления и без рычагов воздействия на окружающий мир? Выдать неверные данные, принять неверное решение, верно? Стало быть, не нужно использовать то, что не умеешь использовать.
Можно возразить, что мы часто используем то, что мы не понимаем, так? Но не забывайте, что при этом есть те люди, кто это хорошо понимает, и если что — сможет помочь. А вот такие штуки, которые никто не понимает, как они работают — вот это уже опасно. Только вовсе не тем, что это мысляший разум, желающий тебе смерти. :-) Так же, как детям опасно играть с ножом — не больше и не меньше.
Алгоритм был в 6 строк кода, использовал около 8 переменных, одна из которых — массив.
Понять, что он делает, было совершенно нереально, пока не запустил и не увидел результат.
Но это простой случай.
А теперь представим, что вместо операций над переменными используются операции над интерфейсами внешних систем (той же OpenGL, например).
Разберетесь ли Вы в том, что делают эти 6 строк кода?
Правильнее даже задать вопрос по другому.
Разберетесь ли Вы, что делает эта функция? Каков ее смысл?
IMHO, в большинстве случаев Вам придется изучить несколько мест использования этой функции, чтобы это понять.
Или можно просто не успеть.
rm -rf /
Разрабатывал бы он софт для систем жизнеобеспечения — пел бы совсем другую песню.
:-)
Просто нынче «разработчик» — слишком расплывчатое описание профессии. Чтобы понять сложность и уровень ответственности, нужно уточнять контекст.
Если их нет — никогда не взлетит.
Тут менеджер хороший нужен, который видит проблемы взаимодействия.
Что мешает интерполировать процесс разработки системы на жизненные ситуации?
Системный анализ работает не только с автоматическими системами.
Старшие разработчики также хорошо работают с автоматизированными системами (человек-машина).
Что мешает заранее начать разбираться с системами типа «человек-человек», т.е. с принципами работы организаций?
Тем более что ситуация по развитию организаций всем более-менее известна, и освещается на множестве ресурсов.
И если разработчик не разбирается в этом, это говорит о том, что есму это не интересно — а в этом случае не нужно туда и лезть. А раз уж полез — будь добр, разберись в правилах игры, и построй стратегию.
И если разработчик этого не может — у него либо особенности характера, несовместимые с этим видом деятельности (опять же — тогда не стоит и лезть), либо банальная лень.
Мне это в свое время надоело.
Я люблю решать сложные задачи, но мне не нравится постоянно находиться в состоянии цейтнота.
Поэтому я не участвую в олимпиадах, но регулярно решаю разные интересные задачки на логику.
При этом часто даже нет смысла писать код — если алгоритм понятен, и его сложность можно оценить без кодинга, я на этом останавливаюсь. Тратить время на кодинг в данном случае является нецелесообразным — лучше закодить какойн-ть полезный инструмент, который позволит убыстрить написание или анализ кода, от этого куда больше пользы.
Вы хотели сказать «Можно не знать языка программирования».
Есть такая черта у некоторых людей — нежелание разбираться в деталях.
В нашей профессии без этого нельзя. Не хочешь разбираться — не ходи в разработчики.
И еще одна профессиональная черта — внимательность.
Если не можешь гарантировать полноту анализа в указанном контексте — значит, рано еще называться разработчиком.
Как правило этих двух составляющих достаточно для того, чтобы стать полноценным разработчиком — со временем разберешься со всем, чем нужно, и будешь точно знать, чего тебе не хватает в каждом конктретном случае, и, соответственно, сможешь придумать, каким способом это можно покрыть.
И когда приходит такое просветление, мир перестается делиться на правильное и неправильное, удобное и неудобное… Вместо этого мы попадаем в мир связей, определяем нужные целевые точки, и просто идем к ним кратчайшим путем (расстояние = значение весовой функции по целевым показателям).
При владении базой, на которую она опирается — да, не сложно.
Но эта база примерно равна уровню подготовки хорошего студента после гос. экзамена по вышке. :-)
Мне хоть слова и знакомы, но я помню, что за ними скрываются абстракции разных порядков, а также энное количество связанных с ними теорем, которые их увязывают в единую систему. И чтобы действительно понять статью, нужно это все вспомнить, восстановить связки. А это довольно тяжело, если не пользоваться этим постоянно.
Вот только жизнь ждать не будет, увы.
В этом случае любая ошибка в ее работе указывает на некомпетентность. И никакие сроки в данном случае не могут являться оправданием. Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений. IMHO, реальных инженеров в IT очень мало.
Умение адаптироваться под изменяющиеся условия — одно из главных умений.
Нужно придумать алгоритм — раскопал аналоги, скрутил решение, проверил на примерах и на краевых условиях.
Нужно настроить сервер — полез в доки, мануалы, нашел примеры, подкрутил под свой случай.
Нужно довести «хотелку» до тех. задания — договорился с заказчиком, детализировал сценарии, согласовал дизайн.
Но!
Все компании работают по-разному, и в обязанности разработчика вменяют самые разные вещи. Где-то специализация более узкая, где-то менее. Иметь широту обзора и умений полезно, но не всегда необходимо.
А вот умение обнаружить причину какого-либо поведения системы, имея на руках только частичные данные, и восстановить все возможные варианты развития событий, не пропустив ни одного — без этого просто нельзя. Если разработчик не способен обеспечить полноту анализа, или хотя бы обозначить границы этой полноты — это серьезный минус. Для нашего брата «не могу», «не хочу», «не умею» — не позволительная роскошь. Да, бывают ошибки, куда без них. Но бросить систему на произвол судьбы — это непрофессионализм.
Как-то так.
Насколько я помню, для такого рода систем даже вводят формальные доказательства корректности программ. Что очень накладно по времени.