вторник, 3 марта 2009 г.

Машина мыслить... может!

От людей, не работающих в области ИИ, я часто слышу такие слова:

"Машина основывается на имеющихся данных и только. Пусть количество этих данных будет великО, а качество -- сложнО...

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

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

Все дело в том, что в большинстве своем эти инструменты построены на основе императивного программирования -- разработчик задает в программе жесткий алгоритм решения задачи. Поэтому такая программа не может
  • решить задачу другим способом
  • или обработать не предусмотренные программистом при разработке входные данные.
Да, она будет работать быстро, будет делать только то, что вы в нее заложили... Но будет тупа, как пробка :)


Ах, да! Еще вы можете кусочки чужих решений всовывать в свои решения :) Прямо как в LEGO!

Если это ваш идеал (как разработчика) -- не стоит читать остаток статьи. Не тратьте время, не тревожьте душу! Ступайте и плодите такой софт себе на здоровье! Кришна вам в помощь.

А с оставшимися мы продолжим дальше.


Итак, еще на заре вычислительной техники группа инициативных товарищей таки хотела научить машину мыслить "аки человеце".


Конечно, они были весьма не удовлетворены императивным подходом и обратили свою неудовлетворенность в другую сторону.

В сторону декларативного программирования и символьного ИИ. В данном подходе разработчик с помощью специального языка описывает:
  • саму решаемую задачу (например, бот должен убить врагов)
  • и знания, которые могут помочь в поиске решения (доступные для бота действия и то, как они влияют на него и окружающих).

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

А входные данные, знания, поведение становятся переменной величинами. Своего рода, типами данных, с которыми можно делать все, что душе угодно.


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

Бот может перестраивать последовательности действий по убиению врагов в зависимости от их действий.

Или разбивать целое на подзадачи.

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


В результате мы переходим на более высокий уровень абстракции (по-сравнению с императивным подходом). Тут программа уже работает с кусками алгоритмов и состояниями фрагментов объектной модели, как с типами данных!!! Это просто потрясающе!!!

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

Но ничего не дается даром. В данном случае приходится платить:
  • производительностью, но только до тех пор, пока мы не найдем новые способы оптимизации работы таких систем. Конечно, более интеллектуальные, чем развертывание циклов или inline-подстановки вызовов функций!
  • сложностью разработки. Есть проблема обучения такой системы. Ей ведь не скажешь, как нужно делать. Необходимо сконструировать ее знания так, чтобы она поступала нужным способом :)


А затем появились агенты и все стало еще веселее :)


5 комментариев:

  1. Анонимный03.04.2009, 11:59

    Позволю себе категорически с вами согласиться =)

    ОтветитьУдалить
  2. Анонимный30.08.2009, 08:33

    По-поводу вашей фразы:
    «кусочки чужих решений всовывать в свои решения»
    Не совсем Вас понял, ведь использовать языки программирования высокого уровня - это, по сути, и есть использования кусочков чужих решений.
    Ведь кто-то до меня уже написал функцию вычисления синуса, что плохого, если я воспользуюсь готовой функцией, включу ее в свою программу?

    ОтветитьУдалить
  3. В первой части статьи речь и идет об императивных ЯВУ. Но тут скорее не функциональная декомпозиция программы на синусы-косинусы, а компонентная.
    Например, OSGi -- одна из самых совершенных и востребованных компонентных технологий на сегодняшнее время.

    ОтветитьУдалить
  4. До кучи можно еще перечислить CORBA/CCM, MS COM, сборки MS .NET...

    ОтветитьУдалить