Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.23 (27) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Программирование поведения робота без доступа к коду
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 8:14 Изменено: 09 окт 16 8:16 Цитата: Автор: r Если мы допустим имеем решатель, который разбивает задачу на сотню мельчайших задач, где каждая задача решается выполнением элементарного метода, то возможно внутренний язык будет лишним. Мы сразу на заводе заливаем в робота весь набор методов, скажем на С++, и он только ими и оперирует. Но тогда вопрос как покупателю обучить робота новому методу. Я не отрицаю наличия внутреннего языка ИИ. Более того, я долгое время таким языком занимался. Первоначально он назывался AIGL. Даже на нем приводил примеры простых программ. И начинал делать движок, который мог бы динамически создавать алгоритмы. Любой язык должен основываться на некотором количестве аксиом, включая неделимые в рамках этого языка атомарные сущности, как, например, в математике понятие точки или бесконечности. Цитата: Автор: r Если не будет внутреннего языка, то как обучить робота новым эвристическим методам? Да, внутренний язык должен быть, но он должен быть более глубинным, основываясь на котором можно было бы индуцировать любые другие вторичные доступные человечеству языки включая языки математики и программирования. Цитата: Автор: r Если использовать парный подход в определении триггеров, когда одну и ту же суть отражают два триггера, но один в утвердительной форме, а другой в отрицательной (с частицей "не"), то ситуация с неопределенностью значения чего либо решается одновременно деактивацией триггерной пары. Например если есть пара "кот шредингера жив" и "кот шредингера не жив", то до открытия ящика оба эти триггеры неактивны (что говорит о неопределенности), а после открытия - активируется один из них. А вот потребуются ли триггеры с большей разрядностью, чем 2, я не знаю, может быть для некоторых задач и потребуются. Вы в данном примере ввели кодирование некоторого количества знаний о мире с помощью сочетания значений двух триггеров (неопределенность, определенно да, определенно нет). Но точно так же можно и в какой-то другой другой плоскости определить множество значений, кодируемых регистром из триггеров. Тогда переменные и триггеры - практически одно и то же. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 8:47 Изменено: 09 окт 16 8:53 Цитата: Автор: r Как я понял, ты предложил готовые блоки тоже строить по принципу "от цели", но у меня с этим возникли трудности. Я попытался посмотреть на код своей змейки и прикинуть как он должен быть изменен, чтобы условия срабатывали не на текущую ситуацию, а для достижения требуемой ситуации. И застрял. То есть вроде понятно, какая должна быть разница между новым решением и существующим, но не понятно, как в таком случае все должно работать. Вот например у меня есть условие, которое срабатывает в момент, когда змейка уткнулась в границу поля. Обработчик этого условия меняет направление движения змейки. Это условие срабатывает на определенную ситуацию - дальше двигаться прямо невозможно, ну и как решение - поворачиваем. Как переделать условие так, чтобы оно срабатывало на достижение целевой ситуации? И какая это ситуация вообще? И самое главное нужно ли переделывать чтобы низкоуровневый код мог сам принимать решения? Ведь если мы делаем так, что условия срабатывают на достижение ситуации и у нас есть несколько условий, которые позволяют достичь одной и той же ситуации только разными методами, то интерпретатор сам выберет какой-то первый попавшийся метод. Наверное должно было быть разделение на программирование человеком (но с использованием такого подхода, который в перспективе позволит сделать надстройку для автоматического программирования поведения робота) и самопрограммирования по принципу разбиения задачи на множество подзадач. Я предлагаю строить программу одновременно и сверху и снизу. И для того, чтобы они могли друг с другом состыковаться в середине, у них должны быть "зацепочки и крючочки" по типу пазлов, то есть, у низовых методов, которые отталкиваются от текущих условий, должно быть указано, что они в итоге меняют, а у блоков, построенных сверху (от планирования), у которых известно, что должно быть, есть требования к низовым параметрам (условиям, с которых уже может начаться действие). И тогда их можно подбирать друг к другу (как пазлы). И это, если ты понимаешь, общее требование ко всем методам, созданным как снизу, так и сверху, так сказать, единое универсальное описание любой процедуры, где бы она ни находилась, вверху или внизу. Возьмем к примеру твою змейку. Ты организуешь её поведение как реакции на события (условия). И не понимаешь, как тоже самое можно было бы организовать при подходе "сверху". Но, как мне кажется, сделать это совсем нетрудно. Для этого нужно всего лишь обозначить (и сформулировать) конечную цель. А цель же вовсе не в реагировании на стенки, а, скорее всего, в непрерывном движении змейки (разве не так?). Значит, когда змейка упирается в стенку, её движение остановлено, и цель не достигается (видишь, я упираю не на то, что есть какое-то реальное событие (триггеры, как это говоришь ты), а на то, что конечное состояние - цель - перестает быть активной), и следовательно, надо что-то сделать. Что? Допустим, у нас уже есть метод, который связывает между собой наличие стенки (условие) и продолжение движения (искомую цель) - и этот метод - скажем, поворот направо. И тогда, попадая в состояние, в котором цель перестает быть доступной, змейка прибегает к этому методу, и её движение продолжается. Этот пример, впрочем, не настолько показательный, так как он, хоть снизу, хоть сверху, использует один и тот же метод, а для примера, на мой взгляд, лучше было бы подобрать такую ситуацию, в которой одновременно применялся бы и метод сверху и метод снизу, и в середине они состыковались бы. Есть такой пример? [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 12:02 Изменено: 09 окт 16 12:05 Цитата: Автор: victorst Я не отрицаю наличия внутреннего языка ИИ. Более того, я долгое время таким языком занимался. Первоначально он назывался AIGL. Даже на нем приводил примеры простых программ. И начинал делать движок, который мог бы динамически создавать алгоритмы. Любой язык должен основываться на некотором количестве аксиом, включая неделимые в рамках этого языка атомарные сущности, как, например, в математике понятие точки или бесконечности. Нагуглить вашу разработку не получилось. По поводу каким должен быть язык я ничего не скажу. Моя реализация мне не нравится, хотя это и не важно, главное что есть реализация и она дала понимание что это должно быть не так. Я сейчас конкретно о программных инструкциях. Но что стало понятно, так это то, что нужно больше внимания уделить триггерам, как фактам. Эта сущность - центральная, так как она одновременно является и контейнером для данных и элементом связывающим все данные в единую модель и элементом управления программным потоком. Если говорить как о контейнере для данных то больше подходит термин "факт", если говорить как об элементе - связке, то я и названия сходу не подберу, так как этот момент еще не проработан, а он очень важен. Если говорить о элементе управления потоком, то это триггер (либо состояние, либо событие). Но все это одна сущность, и программные инструкции - методы во-первых ею адресуются, а во-вторых ее изменяют. А как должен выглядеть безымянный метод в коде, чтобы было понятно человеку - не понятно. Я все это к тому, что вид языка зависит от сущностей, которыми он оперирует. И мне сначала нужно разобраться что эти сущности из себя представляют, не как управляющие потоком (тут уже более-менее ясно), а как контейнер для данных, и как элемент сети данных. Цитата: Автор: victorst Да, внутренний язык должен быть, но он должен быть более глубинным, основываясь на котором можно было бы индуцировать любые другие вторичные доступные человечеству языки включая языки математики и программирования. Вот я об этом тоже думаю. Если рассматривать триггерную пару, как элемент с тремя состояниями, то их совокупностью можно закодировать все, что угодно. Главное сделать это красиво. Цитата: Автор: victorst Вы в данном примере ввели кодирование некоторого количества знаний о мире с помощью сочетания значений двух триггеров (неопределенность, определенно да, определенно нет). Но точно так же можно и в какой-то другой другой плоскости определить множество значений, кодируемых регистром из триггеров. Не уловил, что вы хотели этим сказать. Цитата: Автор: victorst Тогда переменные и триггеры - практически одно и то же. Да, если угодно, аналог булевой переменной. Но как я уже говорил триггер является не только контейнером для данных, а и связующим элементом сети, контейнером для группы триггеров, элементом адресующим условия и методы, элементом адресующим как текущую ситуацию, так и желаемую ситуацию для задач и подзадач. [Ответ][Цитата]
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 12:33 Изменено: 09 окт 16 12:34 Цитата: Автор: r Нагуглить вашу разработку не получилось. Это потому, что ее засосала трясина времени. Вот фрагменты, датированные маем 2006 года: Семантическая структура мира в языке AIGL Однако все мои материалы сохранились в моем архиве. Если кому-то будет интересно, могу поискать. Я несколько раз пытался продолжить разработки этого языка под этим же названием, и под другим (Robolon - с большим рефакторингом), но жизненные обстоятельства не позволили мне его довести до результата, представление о котором у меня в голове почти сложилось. [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 15:02 Изменено: 09 окт 16 15:14 Цитата: Автор: Vpolevoj Я предлагаю строить программу одновременно и сверху и снизу. И для того, чтобы они могли друг с другом состыковаться в середине, у них должны быть "зацепочки и крючочки" по типу пазлов, то есть, у низовых методов, которые отталкиваются от текущих условий, должно быть указано, что они в итоге меняют, а у блоков, построенных сверху (от планирования), у которых известно, что должно быть, есть требования к низовым параметрам (условиям, с которых уже может начаться действие). И тогда их можно подбирать друг к другу (как пазлы). И это, если ты понимаешь, общее требование ко всем методам, созданным как снизу, так и сверху, так сказать, единое универсальное описание любой процедуры, где бы она ни находилась, вверху или внизу. Понимаю, но с трудом, а может понимаю, но не то. Надо поразмышлять. Цитата: Автор: Vpolevoj Возьмем к примеру твою змейку. Ты организуешь её поведение как реакции на события (условия). И не понимаешь, как тоже самое можно было бы организовать при подходе "сверху". Но, как мне кажется, сделать это совсем нетрудно. Для этого нужно всего лишь обозначить (и сформулировать) конечную цель. А цель же вовсе не в реагировании на стенки, а, скорее всего, в непрерывном движении змейки (разве не так?). Так. Тоже такое было подумал. Но у змейки на самом деле аж 3 метода достижения этой цели - движения, а другими словами постоянного перепрыгивания в новую ячейку. И прыгать она так может прямо, влево и вправо. Получается, шла прямо - уперлась, тыкнулась вправо - не получилось, влево - удача. Просто настораживает такое "умное" (и не совсем предсказуемое) поведение на таком низком уровне выполнения. Цитата: Автор: Vpolevoj Этот пример, впрочем, не настолько показательный, так как он, хоть снизу, хоть сверху, использует один и тот же метод, а для примера, на мой взгляд, лучше было бы подобрать такую ситуацию, в которой одновременно применялся бы и метод сверху и метод снизу, и в середине они состыковались бы. Есть такой пример? Пример со сбором ягод не подойдет? Я бы предложил полностью не выбрасывать (не переделывать) условия с реакцией на текущую ситуацию, а комбинировать их с условиями достижения требуемого состояния. То есть оставить условие 1,2 и т.д. без изменений. условие 1 ( ягода выбрана ) { сорвать выбранную ягоду } условие 2 ( ягода сорвана ) { выполнить оценку сорванной ягоды } Потому что, например, второе условие должно сработать конкретно после первого. А вот условие 3 можно сделать таким, которое срабатывает на достижение желаемого состояния. условие 3 { выбрать ягоду } ( манипулятор свободен ) Тут круглые скобки идут после фигурных. Таким образом можно в одном условии задавать одновременно и триггеры-предпосылки (в круглых скобках перед фигурными) и триггеры желаемого состояния (в круглых скобках после фигурных). Только надо придумать как такую запись выражать схематически. Такие условия можно снабдить встроенной в систему проверкой реально ли выполнение обработчика позволило достигнуть желаемого состояния, и если нет - генерировать ошибку (передавать ее наверх для обработки). [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 15:45 Изменено: 09 окт 16 15:48 Цитата: Автор: victorst Это потому, что ее засосала трясина времени. Вот фрагменты, датированные маем 2006 года: Семантическая структура мира в языке AIGL Однако все мои материалы сохранились в моем архиве. Если кому-то будет интересно, могу поискать. Я несколько раз пытался продолжить разработки этого языка под этим же названием, и под другим (Robolon - с большим рефакторингом), но жизненные обстоятельства не позволили мне его довести до результата, представление о котором у меня в голове почти сложилось. По крайней мере с теоретическими основами я бы ознакомился. Кстати, насчет возможной совместной реализации. Имхо наиболее подходящим языком был бы Java. Синтаксис такой же как и везде: классы да объекты, компилируемый (а не интерпретируемый как Питон), не проприетарный, как С# или Делфи, разработку можно вести не только в Windows (я например пользуюсь Линуксом, а кто-то другой может пользуется iOS), работает везде, в процессорах arm есть встроенная аппаратная виртуальная машина java, то есть в робота можно запихнуть мобильный телефон и работать будет сравнительно быстро. Ну а про С++ я просто промолчу, наелся в свое время его указателей и шаблонов. [Ответ][Цитата]
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 16:28 Изменено: 09 окт 16 16:30 Цитата: Автор: r По крайней мере с теоретическими основами я бы ознакомился. Хорошо, попробую завтра порыться в архивах. Цитата: Автор: r Кстати, насчет возможной совместной реализации. Имхо наиболее подходящим языком был бы Java. Синтаксис такой же как и везде: классы да объекты, компилируемый (а не интерпретируемый как Питон), не проприетарный, как С# или Делфи, разработку можно вести не только в Windows (я например пользуюсь Линуксом, а кто-то другой может пользуется iOS), работает везде, в процессорах arm есть встроенная аппаратная виртуальная машина java, то есть в робота можно запихнуть мобильный телефон и работать будет сравнительно быстро. Ну а про С++ я просто промолчу, наелся в свое время его указателей и шаблонов. Мне почти все равно на каком языке писать. На Java - неплохо, если не требуется большая работа с GUI. Я что-то однажды сильно притомился, делая на Java специализированный графический редактор. С этой точки зрения удобнее IDE Lazarus, на основе Object Pascal, который стал на удивление менее глючный. И он кроссплатформенный. Но я предпочитаю писать на ANSI C, чтобы никаких классов и объектов близко не было. В последнее время писал на FORT, когда синтезировал в FPGA самодельный процессор. ОС - мне все равно. Windows, Linux, OsX или BareMetall. А вообще, можем пообщаться речью в скайпе, если хотите. А то много давить на кнопки клавиатуры немного лень. Мой скайп victorkazarinov. Может быть вам не захочется со мной в тандеме поработать над ИИ. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 10 окт 16 8:14 Изменено: 10 окт 16 8:25 Цитата: Автор: r Пример со сбором ягод не подойдет? Я придумал другой пример (думаю, он нам подходит). Назовем его "Смешиватель цветов" (помощник художника). Пусть у нас есть робот (программа в компьютере), которая умеет поддерживать диалог (собственно, для этого мы её и делаем), и которая предназначена для помощи художникам и дизайнерам, позволяя подбирать на экране монитора различные цвета и оттенки, при этом сам процесс управляется голосом. Возьмем для начала какую-нибудь простейшую задачу (предположим, что мы еще только начинаем программировать этого робота). Допустим, у нас в программе есть всего два блока (назовем их А и Б), каждый из которых может находиться всего в двух состояниях (определенных цветов), допустим, блок А может находиться в состоянии "красный" и "синий", а блок Б - в состоянии "желтый" и "белый". При этом подразумевается, что эти цвета потом можно будет смешивать. Собственно, я хочу воспроизвести классическую (детскую) ситуацию, когда при смешении "желтого" и "синего" получается "зеленый". Поскольку А и Б - это реальные объекты внутри нашей программы, то существует интерфейс, который позволяет, с одной стороны, устанавливать любое из предопределенных значений в любом из этих блоков, скажем, мы можем сказать программе: "Установи блок А в состояние "красный", - и она это сделает, потому что у неё есть соответствующие методы (я пока опускаю проблемы непосредственного ведения диалога), а можем запросить у программы текущее состояние того или иного блока, скажем, мы можем спросить: "Какое состояние у блока Б?" - и программа нам ответит: "желтый", опять же, почему, потому что у неё есть для этого соответствующие методы, и сами эти переменные доступны для внешнего пользователя. И предположим также, что эта программа умеет эти цвета смешивать, но не виртуально, а - непосредственно, выводя получаемый в результате такого смешения цветов на монитор (на обозрение пользователя). То есть, пользователь программы видит получившийся цвет, а сама программа его "не видит" (и поэтому программа не знает, что у неё получилось, у неё есть лишь два блока, состояние которых ей доступно и известно, а то, что показывает экран, ей не доступно). Что из этого примера можно вытащить? Пройдусь для начала первым путем. Мы же хотим с этой программой разговаривать, и хотим, чтобы она нас понимала. Вот и попробуем её обучить. Будем последовательно говорить ей устанавливать в двух её блоках те или иные значения, затем просить её их смешать, и НАЗЫВАТЬ ей, какой цвет у неё в результате получился (чтобы она его запомнила). Может ли программа это запомнить? А почему бы и нет. У неё же нет цветов, как таковых. Даже те цвета, которые условно обозначают состояние двух её блоков - для неё это просто цифры (числа), а то, что мы при этом говорим "красный", "желтый" и т.д. - для неё это всего лишь абстракция (называйте как хотите). Поэтому и для получающихся у неё результатов смешения двух произвольно взятых цветов она тоже может установить соответствие и хранить эти значения где-нибудь, скажем, в Базе Данных (чтобы иметь возможность извлекать эти значения и их соответствия в любой удобный момент времени). И таким образом (через обучение), она запомнит, что если смешать "красный" и "белый", то получится "розовый", если смешать "красный" и "желтый", то получится "оранжевый", если смешать "синий" и "белый", то получится "голубой", а если смешать "синий" и "желтый", то получится "зеленый". И это для нас (например, для детей) может показаться удивительным, как это из смешения двух разных цветов получается третий цвет, непохожий на них, но для программы, как я уже говорил, это безразлично - числа и числа, хоть как их назови. И тогда, после такого обучения, программу можно уже спрашивать. Скажем, мы ей говорим: "Установи блок А в состояние "красный", а блок Б в состояние "желтый", смешай - что получилось?" И она ответит: " Оранжевый". А можно ей сказать, выведи на экран "зеленый", и она сама смешает два цвета: "синий" и "желтый", и выведет нам "зеленый". Но это, скажем так, ситуация тривиальная. Сами всему научили свою программу, сами всё обозвали, чему же тут удивляться, если она просто тупо реагирует на наши же, нами же придуманные и нами же установленные слова, сигналы и команды. Все очевидно и предсказуемо. Поэтому рассмотрю ситуацию ДВА. Мы не станем заранее обучать свою программу. Вот есть у неё два блока, которые могут быть в двух заданных состояниях (и мы можем и узнать это состояние и принудительно установить любое из них), но мы не хотим тратить своё время на обучение программы, а хотим, чтобы ОНА САМА... Как это может быть? Предположим, что пользователь сел за монитор, и просит эту программу вывести ему "зеленый" цвет, а программа пока не знает, что это такое, и как это можно сделать (у неё есть и пока что определены лишь "красный", "синий", "желтый" и "белый", а её просят вывести "зеленый"). Что она может сделать в такой ситуации? Как видишь, Цель у программы уже есть, а готовых методов решения у неё на данный момент нет (наша искомая ситуация, ради чего, собственно, я и придумал этот пример). Она может начать перебирать цвета в двух имеющихся у неё блоках, смешивать их и выводить на экран. А человек будет ей говорить, угадала она или нет. И как только искомая комбинация будет ею получена - всё - Цель достигнута. Полученный результат запоминается. И далее, когда пользователь попросит вывести на экран "зеленый" цвет, она уже не будет сомневаться, и сразу сделает требуемое. В чем тут фишка? Дело в том, что состояние своих блоков программа знает (они ей доступны), а результат смешения - это понятие виртуальное, так как никакого объекта, который бы имел такой цвет, внутри программы нет (он всего лишь как бы подразумевается). Предположим на время, что мы вводим в программу некий новый объект С, состояние которого является суммой цветов блоков А и Б. Тогда в любое время можно будет спросить у программы, чему равна сумма А и Б, и она посмотрит на блок С и скажет точно чему именно. Но у неё такого объекта нет. Другими словами, все операции по смешению цветов для неё являются чистой абстракцией. Это пользователь видит что-то конкретное на своем мониторе, а программа ничего этого не видит. Но при этом как-то изъясняться с человеком она должна, и вдобавок еще и понимать. Так что, я думаю, из этого примера можно будет еще кое-что вытянуть. Например, определиться с тем, что же именно следует обозначать СЛОВАМИ, и на каком этапе общения. [Ответ][Цитата]
Victor G. Tsaregorodtsev Сообщений: 3187	На: Программирование поведения робота без доступа к коду Добавлено: 10 окт 16 8:39 Цитата: Автор: Vpolevoj Я представляю себе всю процедуру программирования в этом стиле по типу ИНЬ-ЯН, когда два процесса проектирования (условно: сверху - от цели, и снизу - от готовых простейших блоков) сталкиваются в середине, где они сцепляются друг с другом, и получается одновременно как бы и готовое работающее решение, поскольку оно опирается на уже проверенные существующие блоки, и достижение именно того результата, который был запланирован изначально. А также, чисто из-за системного эффекта, возникнет букет непредвиденных реакций/ошибок/условий неработы. А иначе это будет результатом работы всего одного процесса (сверху или снизу). Потому что у двух - всегда найдутся такие противоречия, которые либо не могут быть отражены (и учтены) в ходе реализации каждого конкретного поделия (отсюда и будущая непредсказуемость поведения системы), либо не могут быть совместимы с какими-то из нижележащих блоков (и придётся вводить костыли, с их собственными "целеполаганиями"). [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 10 окт 16 9:01 Изменено: 10 окт 16 9:23 Цитата: Автор: VPolevoj Я представляю себе всю процедуру программирования в этом стиле по типу ИНЬ-ЯН Цитата: Автор: Victor G. Tsaregorodtsev А также, чисто из-за системного эффекта, возникнет букет непредвиденных реакций/ошибок/условий неработы. А иначе это будет результатом работы всего одного процесса (сверху или снизу). Потому что у двух - всегда найдутся такие противоречия, которые либо не могут быть отражены (и учтены) в ходе реализации каждого конкретного поделия (отсюда и будущая непредсказуемость поведения системы), либо не могут быть совместимы с какими-то из нижележащих блоков (и придётся вводить костыли, с их собственными "целеполаганиями"). Эх, Victor G. Tsaregorodtsev... Немного сумбурно высказано, и поэтому недостаточно понятно..., но если бы ты знал, насколько ты прав. Вот смотри. Берем любого человека. Что он может? Может копать, а может не копать, может пилить, а может не пилить, может рубить, а может не рубить, и т.д. То есть, на нижнем уровне исполнения у него всё в порядке. Посмотрим, что творится на верхнем. Как все мы знаем, каждый человек прекрасно представляет, как следует руководить страной, какие нужно принимать законы, как именно наша сборная по футболу должна играть для того, чтобы всех выигрывать и т.д. То есть, и на верхнем уровне, будем считать, у всех всё тоже в полном порядке. Но ты только посмотри на то, какая хрень у нас у всех получается на среднем уровне, там, где два предыдущих уровня сталкиваются. Но эта "хрень" и есть наша жизнь... "Снизу" мы всё можем и всё умеем, "сверху" мы всё знаем и всё понимаем, а как доходит до непосредственно дела, так начинается та самая "хрень", которая, как выяснилось, и есть наша жизнь. А мы что от роботов хотим? Чтобы они "всё умели" (строили своё поведение снизу), или чтобы они "всё понимали" (планировали свои действия сверху), или чтобы у них всё было "как у нас"? (Как та обезьяна, которая никак не могла решить, куда ей следует встать: к умным или к красивым. "А мне что - разорваться, что ли?" Так и тут.) [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 10 окт 16 11:39 Цитата: Автор: victorst А то много давить на кнопки клавиатуры немного лень. Кажется в кнопках больше пользы. Больше времени на подумать - больше сосредоточенности, глубже ответы. [Ответ][Цитата]
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 10 окт 16 12:35 Цитата: Автор: r Кажется в кнопках больше пользы. Больше времени на подумать - больше сосредоточенности, глубже ответы. Ок [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 11 окт 16 3:27 Изменено: 11 окт 16 3:48 TimKruz, извини, что не сразу тебе отвечаю, как видишь, приходится реагировать прежде всего на другие сообщения, которые ближе к теме, тем более, что наш с тобой разговор ушел в сторону обсуждения концептуальных базовых представлений, имеющихся у каждого из нас, а тут - такое дело - спорить об этом, а уж тем более пытаться переубедить, я считаю, бесполезно, каждый всё равно останется при своём мнении, так что... в лучшем случае - можно обсудить и попробовать переосмыслить собственную концепцию, но для того лишь, чтобы еще сильнее уверовать в её "правильность" (тем более, что в конечном итоге можешь оказаться прав именно ты, а не я). Цитата: Автор: TimKruz Речь ведь идёт не о дружеских или любовных, а о симбиотических отношениях с программой. Программа дополняет пользователя, пользователь дополняет программу. И вместе они решают определённые задачи, которые встают перед ними. Так что тут не может быть речи о том, что "пользователю стало скучно общаться с программой". Эта твоя фраза (выделенная мною), пожалуй, является ключевой. Так как и я сам тоже постоянно пытаюсь выстроить подобный симбиоз, когда "программа дополняет пользователя, а пользователь дополняет программу". Но это лишь звучит красиво, а сделать в реальности подобное взаимное дополнение намного труднее, чем кажется. Вот ты, к примеру, идёшь по пути организации подобного дополнения через обучение программы (робота) каким-то рутинным (однотипным) действиям, и разгрузки Человека за счет этого, так сказать, освобождая его ресурсы. Правда, я не вижу, в чем именно заключается выгода такого взаимодействия для программы (робота), но, допустим, что она - эта выгода - в том, что за счет этого симбиоза она становится нужной и её не выбросят, и не заменят на какой-нибудь другой гаджет, более интересный. И, в общем-то, такой подход понятен. Тем более, что такое разделение обязанностей напрашивается само собой, так как пока (ПОКА) все роботы и программы намного глупее Человека (за исключением шахматных программ, и программ играющих в Го, и некоторых экспертных систем, и ... т.д., но в целом, все же, это так). Поэтому Человеку отводится роль "умного" (назовём эту роль "хозяин"), а программе (роботу) - роль "дурачка" (назовём эту роль "слуга" или, как на этом форуме уже было озвучено - "раб"). Обратная ситуация, почему-то, даже не рассматривается (ан нет, рассматривается, например, в фильме "Матрица", но там люди борются против "машин", что как бы глупо, и подразумевает их равенство друг по отношению к другу, а это не так). Поэтому вопрос, как же именно должно быть организовано это взаимодействие - этот симбиоз - всегда остаётся открытым. Я лично считаю, что наиболее оптимальным (во всяком случае, на сегодня) было бы такое распределение обязанностей: Человеку отдается "творческая" составляющая - он волен фантазировать на любые темы и выдумывать всё что угодно, а Программе отводится роль "контролера", фиксирователя, проверятеля и прорабатывателя всех выдумок и фантазий Человека. И такое дополнение мне представляется более выгодным, так как из такой комбинации ролей получается так называемый "усилитель интеллекта", когда у Человека происходит активация всех его творческих способностей, его раскрепощение, при этом из его "полета фантазии" не будет теряться ничего ценного и продуктивного. Программа же, поскольку она лишена творческого начала (во всяком случае, ПОКА), вынуждена обращаться за этим компонентом к Человеку, но окончательное РЕШЕНИЕ, так сказать, последнее слово, всё равно остаётся за ней, так как именно она будет доводить найденное Человеком решение "до ума", то есть, до готового к реализации проекта. Что и самому Человеку тоже оказывается на руку. На лицо - симбиоз. Цитата: Автор: TimKruz Имхо, концентрироваться на "модели собеседника" - тупик в плане разработки широкого ИИ, потому что это не первопричина интеллекта, а его следствие, продукт. Программа должна уметь делать что угодно; создание модели собеседника - это одно из частных умений программы, результат её "интеллектуальной" деятельности. Т.е. описанный мною диалог юзера с ИИ - это всего лишь один из вариантов обучения этого ИИ. Он так поступает, потому что его этому научили. Его можно было обучить совершенно другим задачам, изменив реплики/коды, флаги и последовательности действий. И тогда он бы поддерживал не "модель собеседника", а уже какую-то другую "модель". Вот это - возможность научить ИИ чему угодно, в том числе поддержанию "модели собеседника" и связного диалога - и есть моя цель. По порядку. Ты считаешь, что "концентрироваться на "модели собеседника" - тупик в плане разработки широкого ИИ". Но дело в том, что интеллектуальные задачи подразделяются по уровням, и одним из высших уровней этих интеллектуальных задач как раз и является межличностное взаимодействие. Я где-то уже писал, что, скажем при игре в шахматы, можно выделить следующие уровни: 1) начальный уровень, когда программой освоены правила игры (это когда программа просто умеет делать правильные ходы и играет по правилам - обучилась играть); 2) игра на среднем уровне, когда программа показывает достаточно хорошие и стабильные результаты, сопоставимые с уровнем обычного нормального человека, но звезд с неба при этом не хватает; 3) высшие достижения - когда программа обыгрывает лучших представителей человечества - чемпионов (каждый раз, или в турнире - по совокупности партий); 4) индивидуальный подход - когда программой разрабатывается определенная стратегия поведения, с учетом индивидуальных особенностей того или иного противника, и она её придерживается (то есть, используется "Модель этого человека"). Как видишь, работа ИИ на основе "модели собеседника" - это высшее проявление интеллекта (я даже не знаю, что может быть выше). Поэтому, если мы действительно хотим построить "Сильный ИИ", то нужно ориентироваться именно на этот - самый высший уровень работы Интеллекта (а не думать, что оно само как-нибудь сложится). А ты пишешь, что "это одно из частных умений программы, результат её "интеллектуальной" деятельности". Да, можно представлять себе это и так. Что когда мы запрограммируем собственно "интеллектуальную деятельность", то в ней, как по волшебству, будут возникать (либо мы будем этому программу обучать целенаправленно) различные умения, и одним из таких умений будет как раз-таки возможность создавать внутри себя "модель собеседника" - почему бы и нет. То есть, сначала мы сделаем Интеллект, а уж он потом и сам как-нибудь научится "межличностным взаимодействиям". Но я считаю иначе. Что нужно посмотреть в конец (туда, где написаны ответы в конце учебника), и увидеть там, что всё упирается в эти самые "межличностные отношения", и что Интеллект мы, оказывается, оцениваем именно с этой точки зрения - есть ли у него "межличностные отношения" или же их нет (а не по тому, выигрывает ли программа партию в шахматы или в Го у чемпиона мира - так как это для нас не Интеллект). И еще оказывается, что сделать эти самые "межличностные отношения" не так уж и просто, во всяком случае, сами они почему-то не появляются, даже у тех программ, которые уже выигрывают у чемпионов мира. Поэтому, когда ты пишешь, что программу "можно было бы обучить совершенно другим задачам, изменив реплики/коды, флаги и последовательности действий, и тогда она бы поддерживала не [только] "модель собеседника", а уже какую-то другую "модель" - в корне не верно. Для того, чтобы программа могла поддерживать какую-нибудь модель (другую или вполне определенную, скажем "модель собеседника"), эта модель должна у неё уже быть, или хотя бы в ней должна быть ПОТЕНЦИАЛЬНАЯ ВОЗМОЖНОСТЬ создания подобной модели. И тогда, наполняя её, и обучая программу различным действиям, мы можем инициировать у неё что-то похожее на "модель собеседника" (или на какую-нибудь другую модель по нашему желанию), но для этого программа ДОЛЖНА БЫТЬ заточена под такого рода задачи, во всяком случае, потенциально, но лучше - целенаправленно. Цитата: Автор: TimKruz Вот это - возможность научить ИИ чему угодно, в том числе поддержанию "модели собеседника" и связного диалога - и есть моя цель. Поэтому, когда ты говоришь, что твоя цель это - "возможность научить ИИ чему угодно", то ты на самом деле подразумеваешь, что обучать ты будешь ДЕЙСТВИЯМ, а еще точнее, реакциям на заданные события. А вот поддержанию "модели собеседника" ты свою программу обучить не сможешь, если она не будет для этого изначально приспособлена. Так как, обучать действиям - это одно, а обучать "поддержанию модели" - это совсем другое. Как говорил бургомистр из к/ф "Тот самый Мюнхаузен": "Война - это война! Её нельзя объявлять когда вздумается." Но это же самое относится и к моделям. Нельзя создать модель чего бы то ни было, если для этого изначально нет возможностей, и поэтому их нужно заранее подготовить. А для этого - НУЖНО ПОДУМАТЬ, как это следует сделать. ЗАРАНЕЕ. До того, как дойдут руки до непосредственно проблемы "межличностного взаимодействия". Иначе может оказаться поздно. То есть, я считаю, что нужно думать об этом прямо сейчас, до того, как сделан первый шаг на пути реализации ИИ, и закладывать потенциальные возможности для образования внутри Программы подобной "модели собеседника" - ЗАРАНЕЕ, умышленно и целенаправленно. [Ответ][Цитата]
Victor G. Tsaregorodtsev Сообщений: 3187	На: Программирование поведения робота без доступа к коду Добавлено: 11 окт 16 7:42 Цитата: Автор: Vpolevoj "Снизу" мы всё можем и всё умеем, "сверху" мы всё знаем и всё понимаем, а как доходит до непосредственно дела, так начинается та самая "хрень", которая, как выяснилось, и есть наша жизнь. На самом деле, тут нет никакого снизу и сверху - Вы просто необоснованно/бездоказательно предполагаете обязательное одновременное наличие как компетенций, так и энтузиазма (вернее, жертвенности в пользу некоторых бенефициаров, коим нет числа - начиная с манагеров и заканчивая простыми вэлферщиками). Увы, ан масс это осталось в прошлом. [Ответ][Цитата]
kondrat Сообщений: 4026	На: Программирование поведения робота без доступа к коду Добавлено: 11 окт 16 9:08 Цитата: Автор: Vpolevoj ... Как видишь, работа ИИ на основе "модели собеседника" - это высшее проявление интеллекта (я даже не знаю, что может быть выше). Поэтому, если мы действительно хотим построить "Сильный ИИ", то нужно ориентироваться именно на этот - самый высший уровень работы Интеллекта (а не думать, что оно само как-нибудь сложится). ... По-моему, еще круче - работа на основе модели сообщества собеседников. Прогноз - это важно, без коммуникаций и памяти он не возможен. Существо должно помнить историю своего вида, свою, своего сообщества и должно обладать способностями сформировать организм следующего уровня в результате личного развития, сотрудничества, симбиоза, когда даже конкуренты становятся необходимыми элементами этого сверх существа. [Ответ][Цитата]
Стр.23 (27): 1  ...  19  20  21  22  [23]  24  25  26  27 << < Пред. | След. > >>