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

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

Все темы | Новая тема  Стр.4 (5) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Планировщик задач (построитель алгоритмов) для робота
victorst Сообщений: 821	На: Планировщик задач (построитель алгоритмов) для робота +1 Добавлено: 24 авг 16 0:29 Изменено: 24 авг 16 8:50, автор изменений: r Я уже приводил эту ссылку на форуме: Языки описания доменов и задач планирования [Ответ][Цитата]
r Сообщений: 837	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 24 авг 16 0:55 Изменено: 24 авг 16 8:49 Спасибо, пригодится. Тогда читал, нужно освежить в памяти. [Ответ][Цитата]
r Сообщений: 837	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 24 авг 16 6:26 Изменено: 24 авг 16 6:27 Цитата: Автор: Vpolevoj ..поскольку не считаю эту задачу настолько сложной, чтобы посвящать ей отдельную тему Однако же там есть что обсудить. Перенес часть постов сюда. [Ответ][Цитата]
rrr3 Сообщений: 11857	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 24 авг 16 10:45 Изменено: 24 авг 16 10:46 Цитата: Автор: r Это не обязательно так. Как я понимаю, почти все существующие когнитивные архитектуры работают схожим образом, соответственно всё это умеют. Если иметь ввиду все что Вы ранее перечислили и в полном объеме, то обязательно и ни одна до сих пор существущих ныне в открытом доступе систем этого делать не умеют..., а если умеют, то что же Вы делаете, возьмите готовую... Но спорить не хочу, Вы во всем правы, оставайтесь при своем, а мои посты удалите. [Ответ][Цитата]
r Сообщений: 837	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 08 окт 16 14:18 Цитата: Автор: Vpolevoj Вот я и предлагаю подумать над "решателем задач", попробовать понять, что же это такое. Что это такое пока мало понятно. Понятно только, что: - У такого решателя обязательно должна быть модель мира. - Модель мира должна быть построена не на объектах и их свойствах, а на бинарных флагах. Бинарных - то есть имеющих тип boolean. Вопрос, поставленный к такому флагу (факту, триггеру) имеет только два ответа: да и нет. - Факты делятся на два типа (хотя я не уверен) узловые и дуговые (то есть связующие между собой два узловых факта). Когда появляется новый дуговой (связующий факт) при помощи него можно связывать существующие (а также вновь добавляемые) узловые факты. - Модель мира представляет собой сеть из связанных между собой фактов. - Чтобы различать факты при обсуждении можно присваивать им словесные идентификаторы, но в самой системе они имени думаю иметь не должны. А вот как их идентифицировать при постановке задачи это вопрос. - Факты могут иметь древовидную иерархию, то есть может быть факт, который объединяет набор других фактов в некую группу. Возможно это просто должно быть реализовано через дуговой факт, означающий иерархию. - Создавать факты по неформатированному потоку данных (как это работает у человека в зрении и пр.) мы не сможем, так как пока не знаем как сделать чтобы система обучаясь постепенно начинала выделять некий формат (находить инварианты) в неформатированном потоке данных. Поэтому остается вариант с разработкой языкового интерфейса для постановки условия задачи извне. Язык думаю должен быть низкоуровневый, точно не похож на естественный, возможно всего из несколько инструкций, возможно оперирующий непосредственно фактами. Но вопрос как их адресовать, они же типа без имени. - Естественно-языковый интерфейс можно будет прикрутить когда вся система будет работать, когда модель мира будет создана. Тогда можно будет линковать (обучением) слова из ЕЯ к триггерам в модели мира. Но это так нескоро, что этот вопрос можно и не подымать. - Решателю ставится задача извне (наверное на начальном этапе только извне) через описание начального условия, через активацию триггеров, значение которых в системе наверняка не определено, но точно потребуется для решения задачи. Я говорил как-то, что у триггера есть его антипод, один из пары должен быть активен, иначе - оба не активны - значение триггерной пары не определено. Так вот задание системе начальных условий для решения задачи сводится к активации одного триггера из каждой такой триггерной пары. После того как условия задачи введены, вводится вопрос задачи, ну или другими словами целевое условие, так же, через активацию набора триггеров. Такое задание начальных условий и конечных есть постановка. - Для решения задачи система использует как начальные условия из задачи, так и связи фактов из своей модели мира, которые закладываются заранее отдельными языковыми инструкциями. - Также для решения потребуется набор методов, которые тоже будут безымянными, а адресоваться должны через набор триггеров (почти как условия), с которыми они работают. Подробнее пока не придумал. - Планировщик берет разницу между целевым условием и текущей ситуацией и разбивает задачу на подзадачи. Каждая подзадача, в результате ее решения, должна приводить к такой ситуации, которая является входящей для следующей подзадачи. При решении подзадач выполняется метод с подходящими параметрами (триггерами), а может и несколько методов, но лучше одна задача - один метод. - Для решение задачи может подходить несколько алгоритмов, то есть может быть создано несколько независимых цепочек подзадач. Планировщик берет одну из них и начинает выполнять выбранную цепочку метод за методом с контролем результатов после выполнения каждого метода. - Если при контроле выполнения метода обнаружено несовпадение ожидаемого состояния триггеров с действительным, создается новая задача по исправлению ситуации, а выполнение текущей цепочки откладывается. Цитата: Автор: Vpolevoj Можно, конечно, ввести такое понятие, как "требуемое состояние триггера". И отталкиваясь от него, сформировать такие понятия как "требуемые условия" и "требуемые состояния" (в том числе и "ожидаемые условия" и "ожидаемые состояния"). И после этого начать рассматривать эти "требуемые" и "ожидаемые" состояния как реально действующие для описания общего состояния системы (как это делаешь ты). И тогда, вроде бы, всё должно получиться, правда, у меня до конца в этом уверенности нет. Потому что, опять же, здесь важно не то, какие условия мы рассматриваем (мнимые или реальные), а то, ОТКУДА программа (робот) будет брать эти "требуемые состояния" (имеется ввиду, что будут возникать новые "требуемые состояния", а ведь именно для них нам нужно составить новую программу)? Через какой-то примитивный языковый интерфейс, думается. Цитата: Автор: Vpolevoj Эта же самая проблема действует и на человека. Как я уже говорил, когда человек решает какую-нибудь задачу, то от того, насколько хорошо и четко он представляет себе "конечный результат", который требуется получить в итоге, он и будет решать эту свою задачу - успешно или не очень. То есть, чем четче представления о том, что требуется получить, тем проще найти решение, и тем компактнее оно будет. Это же относится и к роботу. Может сначала сосредоточиться на четко формулируемых задачах, с одним решением так сказать. Цитата: Автор: Vpolevoj Другими словами, я считаю, что наша проблема сводится не столько к поиску механизмов программирования, сколько к тому, чтобы научить робота вычленять главное от неглавного в формировании "картины будущего", и если он научится это делать, то свести потом это к комплексу автоматных действий, я думаю, будет можно. Но только ПОСЛЕ того, а не ДО. Возможно, но где тогда брать первоначальный набор методов? Цитата: Автор: Vpolevoj Попробую немного порассуждать на эту тему. Допустим, у нас есть уже готовое "требуемое состояние". Что из этого может следовать? Во-первых, система должна проверить текущее состояние на соответствие требуемым, и если всё будет совпадать (кроме состояния незначимых триггеров, которые можно игнорировать), то делать ничего не нужно - итак все хорошо (но это, так сказать, тривиальное решение). Во-вторых, текущее состояние может отличаться от "требуемого" состоянием какого-то одного триггера, и в системе есть действие, которое его меняет. Тогда вполне очевидно, что может быть вызвано это действие, и вполне реально ожидать, что требуемые условия будут в результате этого действия достигнуты. Пример. Мы пришли домой поздно, и в квартире, естественно, темно (а требуется, чтобы было светло). И мы знаем, что для того, чтобы в квартире появился свет, нужно его включить. Щелкаем выключателем, и - ву-аля - да будет свет! (Всё остальное совпадает.) Тут смотря как рассматривать включение света. Как одно действие, или как несколько. Ведь квартира может быть чужая , и где выключатель мы можем не знать. То есть, процесс включения света может растянуться на целую цепочку: поискать выключатель визуально (по горящему индикатору), если не получилось поискать рукой недалеко от дверного проема, в случае удачи, нажать на выключатель, в случае неудачи - посветить спичкой/зажигалкой/телефоном/фонариком. А каждое действие можно разбить на отдельные движения. Тут не понятно, если рассматривать решение задачи как один метод - "включить свет", то в промежуточных состояниях (при какой либо неудаче в поиске выключателя и необходимости выбора другого метода) нужно как-то прервать текущий метод, при чем может потребоваться продолжение его выполнения с момента прерывания. Так что скорее всего нужно разбивать задачу включения света на сотню элементарных подзадач, таких как переместить манипулятор на 10см левее (при поиске выключателя). Чтобы иметь достаточную гибкость в моментальной реакции на возникшую проблему. Цитата: Автор: Vpolevoj В-третьих, эти состояния могут быть разделены двумя-тремя и т.д. шагами. Скажем, мы щелкнули выключателем, а свет в квартире так и не зажегся. Что делать? Проверить пробки. Заменить сгоревшую лампочку. И т.д. То есть, мы просто ввели несколько промежуточных действий между "щелкнуть выключателем" и "да будет свет". Но все равно - все понятно. В-четвертых, таких несовпадающих триггеров может быть несколько, но в этом случае задача будет сводиться к набору последовательных/параллельных задач по приведению этих триггеров в требуемое состояние. Таких несовпадающих триггеров может быть очень много, например при решении математических задач. И тут нужны эвристические методы, которым робота необходимо обучить. Наверное с таких задач начинать не стоит. Цитата: Автор: Vpolevoj В-пятых (и это уже сложнее), когда мы не можем привести триггер (или группу триггеров) сразу в требуемое состояние, и нам для этого нужно приложить и усилия, и терпение. Такие задачи решаются через итерации (то есть, путем организации бесконечного цикла). И я считаю этот подход самым универсальным. Когда мы запускаем какое-нибудь действие на повтор, время от времени проверяя, насколько изменились текущие условия (насколько они стали ближе к требуемым). Так организована, к примеру, ходьба, учеба, готовка пищи, уборка помещения, распиливание дерева, и т.д. и т.д. Это когда мы делаем что-то, постепенно и последовательно приближая себя к конечному результату. Этот же подход позволяет подобрать то или иное действие, которое теоретически способно привести к решению. Если бесконечное повторение какого-нибудь действия не приводит к значительным сдвигам в текущей ситуации, то следовательно, нужно сменить это действие, и выбрать что-то другое. А в целом, здесь действует правило: "Если долго мучиться, то что-нибудь получится!" Да но выбирать методы нужно либо эвристические, для данного класса задач, либо из той же группы методов. А это значит что нужно методы как-то держать упорядоченными, возможно в иерархической структуре, как-то ранжировать их по используемым триггерам. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 09 окт 16 5:51 Изменено: 09 окт 16 5:55 Решатель Цитата: Автор: r Что это такое пока мало понятно. Понятно только, что: - У такого решателя обязательно должна быть модель мира. - Модель мира должна быть построена не на объектах и их свойствах, а на бинарных флагах. - Факты делятся на два типа узловые и дуговые. Когда появляется новый дуговой (связующий факт) при помощи него можно связывать существующие (а также вновь добавляемые) узловые факты. - Модель мира представляет собой сеть из связанных между собой фактов. - Чтобы различать факты при обсуждении можно присваивать им словесные идентификаторы, но в самой системе они имени думаю иметь не должны. А вот как их идентифицировать при постановке задачи это вопрос. - Факты могут иметь древовидную иерархию, то есть может быть факт, который объединяет набор других фактов в некую группу. Возможно это просто должно быть реализовано через дуговой факт, означающий иерархию. - Создавать факты по неформатированному потоку данных (как это работает у человека в зрении и пр.) мы не сможем, так как пока не знаем как сделать чтобы система обучаясь постепенно начинала выделять некий формат (находить инварианты) в неформатированном потоке данных. Поэтому остается вариант с разработкой языкового интерфейса для постановки условия задачи извне. Язык думаю должен быть низкоуровневый, точно не похож на естественный, возможно всего из несколько инструкций, возможно оперирующий непосредственно фактами. Но вопрос как их адресовать, они же типа без имени. - Естественно-языковый интерфейс можно будет прикрутить когда вся система будет работать, когда модель мира будет создана. Тогда можно будет линковать (обучением) слова из ЕЯ к триггерам в модели мира. Но это так нескоро, что этот вопрос можно и не подымать. - Решателю ставится задача извне (наверное на начальном этапе только извне) через описание начального условия, через активацию триггеров, значение которых в системе наверняка не определено, но точно потребуется для решения задачи. Я говорил как-то, что у триггера есть его антипод, один из пары должен быть активен, иначе - оба не активны - значение триггерной пары не определено. Так вот задание системе начальных условий для решения задачи сводится к активации одного триггера из каждой такой триггерной пары. После того как условия задачи введены, вводится вопрос задачи, ну или другими словами целевое условие, так же, через активацию набора триггеров. Такое задание начальных условий и конечных есть постановка. - Для решения задачи система использует как начальные условия из задачи, так и связи фактов из своей модели мира, которые закладываются заранее отдельными языковыми инструкциями. - Также для решения потребуется набор методов, которые тоже будут безымянными, а адресоваться должны через набор триггеров (почти как условия), с которыми они работают. Подробнее пока не придумал. - Планировщик берет разницу между целевым условием и текущей ситуацией и разбивает задачу на подзадачи. Каждая подзадача, в результате ее решения, должна приводить к такой ситуации, которая является входящей для следующей подзадачи. При решении подзадач выполняется метод с подходящими параметрами (триггерами), а может и несколько методов, но лучше одна задача - один метод. - Для решение задачи может подходить несколько алгоритмов, то есть может быть создано несколько независимых цепочек подзадач. Планировщик берет одну из них и начинает выполнять выбранную цепочку метод за методом с контролем результатов после выполнения каждого метода. - Если при контроле выполнения метода обнаружено несовпадение ожидаемого состояния триггеров с действительным, создается новая задача по исправлению ситуации, а выполнение текущей цепочки откладывается. У тебя практически всё описано правильно: и то, что модель мира в таком решателе должна быть логической (то есть иметь бинарную природу и все переходы между различными состояниями должны быть однозначными), и то, что должен существовать какой-то начальный уровень, который, по всей видимости, придется закладывать в систему вручную, иначе она не заработает и т.д. Трудность, насколько я вижу, у тебя возникает только лишь с интерфейсом - как объяснять этой системе условия задачи и какие-то алгоритмы (решения), если это будет нужно. Так как ты считаешь, что внутри самой системы (решателя) никаких языковых обозначений быть не должно, а человек может пользоваться только лишь такими языковыми конструкциями. Но выход, на самом деле, есть. Несмотря на различия (коренные, как ты видишь) в подходах и в представлении мира у Человека и у компьютера, ВСЕГДА (я подчеркиваю это) можно выделить такие объекты, которые будут являться и для Человека и для Программы ОБЩИМИ, и им для удобства общения выгодно будет обзывать их каким-то общим словом (и тогда они будут друг друга понимать). При этом, этот же объект внутри Программы (как и внутри Человека или внутри человеческого сообщества) может назваться совсем не так, фактически как угодно, важно лишь чтобы они ДРУГ ДРУГА ПОНИМАЛИ, то есть, чтобы одно и то же слово обозначало бы для них один и тот же объект. Круг таких объектов (фактов, алгоритмов, условий и пр.), как мне кажется, будет не таким уж и большим (как известно, средний словарный запас обычного человека не превышает 1000 слов, и этого хватает не только для общения, но и для практически всех его дел). И начинаться он должен (я имею ввиду круг объектов с обязательным для них языковым обозначением) с самого низкого уровня, хотя там, по всей видимости, можно не пользоваться языком (высокого уровня), а использовать строгие команды, символы и знаки (типа языка программирования), и лишь постепенно переходить к языку более высокого уровня. Другими словами, для общения с роботом, на мой взгляд, должно хватать небольшого количества слов (от 1000 до 2000 предположительно), которые должны обозначать наиболее значимые и ключевые пункты в Модели Мира программы, для осуществления согласования планов, обучения и постановке задач между Человеком и Программой. [Ответ][Цитата]
r Сообщений: 837	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 09 окт 16 12:59 Изменено: 09 окт 16 13:27 Вот именно что чтобы понимали, только уровень понимания может быть разный. Если мы машине даем конкретную команду сделать то-то и то-то это одно, а другое дело, когда мы говорим роботу, которых спасает тонущих, что мол "в воде кто-то кричит", а он срывается и погнал в воду. То есть машина должна делать выводы и принимать решения независимо от формы нашего изъяснения. Нам же именно такая машина интересна. Поэтому изначальная словесная привязка непосредственно к триггеру малоинформативна. Было бы неплохо, чтобы эти флаги отображали не слова, а образы. Не визуальные, вернее не только визуальные, а образы в более общем смысле. А слова привязывать уже потом нужно. Не знаю как объяснить. Ну допустим есть в модели мира у робота триггер означающий круглость, просто круглость. И мы такие ему "этот объект круглый", и от выдает сотни круглых объектов, к которым этот триггер привязан. Круглым же что угодно может быть. После чего мы уточняем поиск: "объект сделан из резины". Машина выдает уже меньший список. Уточняем дальше: "объект используется в играх". Тут она выдает один единственный триггер, который обладает всеми этими признаками (содержит связи на другие триггеры которые обозначают эти признаки). И мы говорим: "этот объект - мяч" (не обязательно именно в такой форме, то есть в форме естественного языка, скорее наоборот). Теперь можно на него ссылаться по такому идентификатору. Если есть синонимы, и их все можно навесить на триггер. И уже после этого начинать строить с машиной естественноязыковое взаимодействие, знакомить с предложениями, их структурой. Я это так вижу. Не так, что мы создали вручную булевую переменную, присвоили ей имя мяч, сели и не знаем что с этим дальше делать. То есть выходит триггеры в свою очередь также нужно описывать какими-то основными признаками, как-то делать их адресуемыми через эти признаки. Пока не пойму как должно быть правильно. [Ответ][Цитата]
NO. Сообщений: 10700	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 10 окт 16 1:56 Изменено: 10 окт 16 2:00 я вроде написал как оно делается правильно, или вам обязательно нужно из котлет и вантузов интеллект собрать, научные термины отвергаете? вот попроще http://www.softcraft.ru/paradigm/dp/dp04/ [Ответ][Цитата]
r Сообщений: 837	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 10 окт 16 11:30 Изменено: 10 окт 16 11:41 Имхо, там только часть правильно. Знаком я с этим всем, правда поверхностно, ну и в статье автор тоже скакал галопом по европам, к сожалению. А от формул меня укачивает, пусть на формулы математики эякулируют, меня только точный алгорим может возбудить. [Ответ][Цитата]
NO. Сообщений: 10700	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 10 окт 16 11:56 Изменено: 27 апр 17 5:14 Точные алгоритмы как раз только в рамках формальных систем и работают, у математиков. И робот, собирая ягоды, наверняка не приобретет такой сложный жизненный опыт, чтобы далеко уйти от формальной системы. [Ответ][Цитата]
rrr3 Сообщений: 11857	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 27 апр 17 5:10 Цитата: Автор: NO. Точные алгоритмы как раз только в рамках формальных систем и работают, у математиков. И робот, собирая ягоды, наверняка не приобретет такой сложный жизненный опыт, чтобы далекой уйти от формальной системы. В основе любых формальных систем лежат априорные "неформальности"... даже у математиков. Но без картинок понять это дано не многим... [Ответ][Цитата]
NO. Сообщений: 10700	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 27 апр 17 5:19 Например? [Ответ][Цитата]
rrr3 Сообщений: 11857	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 27 апр 17 6:02 Цитата: Автор: NO. Например? Картинки не умею рисовать, Вы уж сами как-нибудь. [Ответ][Цитата]
гость 78.25.120.*	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 28 апр 17 3:41 NO> И робот, собирая ягоды, наверняка не приобретет такой сложный жизненный опыт, чтобы далеко уйти от формальной системы. интересно, как сталкиваются умонастроения.. c одной стороны есть интуиция, что разнообразие сырых данных о мире (сенсорно-интроцептивные потоки) столь гигантски снижается при моделировании мира, что модель может быть 'удовлетворительно' формализована (символическая динамика модели оказывается 'вполне' регуляризируемой на уровне реалистической формальной грамматики), - а с другой стороны есть желание вообще не заворачиваться насчет формализуемости - реализуя 'встроенно-динамический' подход, все эти контроллеры движения на основе самоорганизующихся и саморегуляризирующихся карт (отображений), нейрокритиков etc. все-таки трудно написать универсальное правило для разрешения потока ситуаций типа внезапно возникшего ограничения из-за попадания прутика в шарнир.. то ли адаптировать движение, то ли заняться саморемонтом.. [Ответ][Цитата]
NO. Сообщений: 10700	На: Планировщик задач (построитель алгоритмов) для робота Добавлено: 28 апр 17 15:27 Изменено: 28 апр 17 15:28 Да, это очень разный менталитет. У военных попадалась фраза вроде наступление это тактика обороны, а оборона это вид наступления. Сейчас даже не могу сообразить как они в самом деле связаны, диалектика какая-то. Но было как-то красиво сказано. Типа вот "форма" против "тактики", то есть не противоречащие друг-другу термины, несколько разной природы и разного уровня абстрактности. Получается связная конструкция. На бирже тоже покупают и продают, тоже в разговорах обычно кто-то сосредоточится на одном, а другой ему пытается напомнить, что нужно просто торговать. Трудная тема, обычно объясняют на примерах и сам пример это длинный сюжет с несколькими персонажами. А если у человека понимание понимания такое, что слушая нужно отличить хорошее от плохого или сформировать одну точку зрения, он так ничего и не поймет. [Ответ][Цитата]
Стр.4 (5): 1  2  3  [4]  5 << < Пред. | След. > >>