Часть серии статей о |
Искусственный интеллект |
---|
![]() |
Основная идея интеграции систем искусственного интеллекта заключается в том, чтобы сделать отдельные программные компоненты , такие как синтезаторы речи , совместимыми с другими компонентами, такими как базы знаний здравого смысла , чтобы создавать более крупные, широкие и более способные системы ИИ. Основными методами, которые были предложены для интеграции, являются маршрутизация сообщений или протоколы связи, которые программные компоненты используют для связи друг с другом, часто через систему промежуточного программного обеспечения blackboard .
Большинство систем искусственного интеллекта включают в себя некие интегрированные технологии, например, интеграцию технологий синтеза речи с технологиями распознавания речи . Однако в последние годы все чаще обсуждается важность системной интеграции как самостоятельной области. Сторонниками этого подхода являются такие исследователи, как Марвин Мински , Аарон Сломан , Деб Рой , Кристинн Р. Ториссон и Майкл А. Арбиб . Причина недавнего внимания, которое привлекает интеграция ИИ, заключается в том, что уже создано несколько (относительно) простых систем ИИ для определенных проблемных областей (таких как компьютерное зрение , синтез речи и т. д.), и что интеграция того, что уже доступно, является более логичным подходом к более широкому ИИ, чем создание монолитных систем с нуля.
Фокус на интеграции систем, особенно в отношении модульных подходов, вытекает из того факта, что большинство интеллектов значительных масштабов состоят из множества процессов и/или используют многомодальный ввод и вывод. Например, интеллект гуманоидного типа предпочтительно должен был бы уметь говорить, используя синтез речи, слышать, используя распознавание речи, понимать, используя логический (или какой-либо другой неопределенный) механизм и т. д. Для того, чтобы создать искусственно интеллектуальное программное обеспечение более широкого интеллекта, необходима интеграция этих модальностей.
Сотрудничество является неотъемлемой частью разработки программного обеспечения , о чем свидетельствуют размеры компаний-разработчиков программного обеспечения и размеры их отделов программного обеспечения. Среди инструментов, облегчающих совместную работу над программным обеспечением, есть различные процедуры и стандарты, которым разработчики могут следовать, чтобы гарантировать качество, надежность и совместимость своего программного обеспечения с программным обеспечением, созданным другими (например, стандарты W3C для разработки веб-страниц). Однако сотрудничество в области ИИ отсутствует, по большей части не наблюдается за пределами уважаемых школ, отделов или научно-исследовательских институтов (а иногда и внутри них). Это представляет для практиков интеграции систем ИИ существенную проблему и часто заставляет исследователей ИИ «изобретать велосипед» каждый раз, когда они хотят, чтобы определенная функциональность работала с их программным обеспечением. Еще более разрушительным является синдром «не изобретено здесь», который проявляется в сильном нежелании исследователей ИИ основываться на работе других.
Результатом этого в ИИ является большой набор «островов решений»: исследования ИИ создали многочисленные изолированные программные компоненты и механизмы, которые работают с различными частями интеллекта по отдельности. Вот несколько примеров:
С ростом популярности движения свободного программного обеспечения , многие создаваемые программные средства, включая системы ИИ, доступны для публичного использования. Следующим естественным шагом является объединение этих отдельных программных компонентов в согласованные интеллектуальные системы более широкого характера. Поскольку множество компонентов (которые часто служат одной и той же цели) уже созданы сообществом, наиболее доступным способом интеграции является предоставление каждому из этих компонентов простого способа общения друг с другом. При этом каждый компонент сам по себе становится модулем, который затем можно опробовать в различных настройках и конфигурациях более крупных архитектур. Некоторые сложности и ограничения использования программного обеспечения ИИ — это неконтролируемые фатальные ошибки. Например, серьезные и фатальные ошибки были обнаружены в очень точных областях, таких как онкология человека, как в статье, опубликованной в журнале Oral Oncology Reports под названием «Когда ИИ идет не так: фатальные ошибки в онкологических исследованиях, рассматривающих помощь». [1] В статье указывалось на серьезную ошибку в искусственном интеллекте на основе GBT в области биофизики.
Существует множество онлайн-сообществ для разработчиков ИИ, где руководства, примеры и форумы направлены на помощь как новичкам, так и экспертам в создании интеллектуальных систем. Однако немногим сообществам удалось сделать определенный стандарт или кодекс поведения популярным, чтобы позволить интегрировать большую коллекцию разнообразных систем с какой-либо легкостью.
Методология конструкционистского проектирования (CDM, или «конструкционистский ИИ») — формальная методология, предложенная в 2004 году для использования при разработке когнитивной робототехники, коммуникативных гуманоидов и широких систем ИИ. Создание таких систем требует интеграции большого количества функций, которые должны быть тщательно скоординированы для достижения согласованного поведения системы. CDM основана на итеративных этапах проектирования, которые приводят к созданию сети именованных взаимодействующих модулей, взаимодействующих посредством явно типизированных потоков и дискретных сообщений. Протокол сообщений OpenAIR (см. ниже) был вдохновлен CDM и часто использовался для помощи в разработке интеллектуальных систем с использованием CDM.