Форум создателей искусственных интеллектов

Приветствую братьев по разуму. Стена, об которую все разбивается, называется абстракция. Точнее, (не) способность создавать абстракции. Остальное, вроде как, все есть: память, вычислительная мощность, данные из внешнего мира, и искомые критерии (на Kaggle их называют оценками - evaluation) Припоминаю, Игорь Ашманов говорил об современном искусственном интеллекте как о математических библиотеках. А математика и есть та самая абстракция. Современный искусственный интеллект сам не может создавать "эффективную математику" для описания реальности. Есть прекрасный набор данных на тему абстракции https://www.kaggle.com/c/abstraction-and-reasoning-challenge Лучший результат там 0.8 (0 - наилучший возможный результат, 1 - наихудший). Т.к. в 80% случаев предлагаемых задач не решается. Т.к. ранжирования по сложности нет, и, найдены решения, скорее всего, только для тривиальных задач, то можно сказать, что результат нулевой. Советую скачать и посмотреть примеры. Могу на python выложить что у меня есть (просмотр может пригодиться). Примеры простые, но позволяют сконцентрироваться и отслеживать за собой, как решаются задачи. Это практически идеальный набор данных для таких целей. Эту kaggle-проблему, по идее, можно свести к задаче поиска наиболее простых математических функций. И я это делал, и такая штука даже нашла несколько правильных решений. Однако общий перебор функций подходит только для очень коротких функций. Реальные же решения для примеров имеют функции с длиной, недоступной для перебора (даже с учетом предварительной обработки изображений). Проблема колоссального объема перебора может решаться различными способами. Сначала можно попытаться пописать их вручную, а потом обобщить. Будет уже что-то. Например, в примере в описании проблемы есть только перекраска черных клеток в желтые - кандидат-кусочек алгоритма уже есть (операция перекраски). Часть задач там являются небольшой переделкой более простых задач - кусочки могут браться из решенных задач, и т.д. Есть подозрение, что ИИ представляет собой иерархию. Первый уровень, скажем, ищет алгоритмы решения конкретных задач. Второй уровень ищет алгоритмы создания алгоритмов решения конкретных задач, третий уровень ищет алгоритмы для второго уровня, и т.д. На каждом уровне идет перебор вариантов функций - гипотетически так можно преодолевать проклятье экспоненциального взрыва вариантов. Можно ли оставаться на одном уровне и самого себя как-то улучшать - не ясно с теоретической точки зрения. P.S. Есть некоторый сумбур с обозначениями. Это касается Функции (в математическом смысле) и Алгоритма. Нас, конечно, интересуют мат. объекты, которые являются как алгоритмами, так и функциями. Они так и называются - вычислимые функции. Алгоритмы и функции выше - суть одно и то же.

Во-первых, хочу предостеречь. 1. 800 правильных результатов получить не получится, так как, скорее всего, в наборе задач есть ошибки. Часть из них была исправлена - это видно по правкам в репозитории в гитхабе. 2. Нельзя менять местами пары изображений в задаче. Может показаться, что в задаче преобразуется матрица в матрицу. В действительности, преобразуется пара (матрица, "номер задачи в наборе") в матрицу. Архив скриптов вместе с данными находится тут: http://np-soft.ru/downloads/abstract2019.zip Тут, скорее всего содержатся не исправленные примеры, которые выправили в гитхабе. В архиве папки training, test и evaluation содержит наборы данных (900 штук: +100 за счет test). Что в папках training_ и py/training - не помню. Возможно, одна папка содержит найденные ошибки, вторая - "необработанные" данные (см. ниже). В папке py находятся скрипты. * view.py - просмотр файла с числами. Скрипт вызывается с именем файла-json-а. Иногда важно видеть цифры, а не цвета - скрипт может пригодиться. * manual.py - содержит скрипты для "решения" задач. Каждая задача представлена в виде класса с именем Example_папка_файл. Например, класс Example_training_50846271 содержит решение задачи из папки training для файла 50846271.json. Вызов diffAll() покажет, количество различий, даваемых расчетом в классе и данными в библиотека. По умолчанию вызывается Example_training_50846271().diffAll(), который выводит [0, 0, 4, 0, '|', 0]. Это означает, что в примере 3 есть расхождения в 4-х клетках. * tparser.py - библиотека парсинга. Что это и зачем - в следующем сообщении.

Это точно не так - одна функция на все пары в рамках одной задачи. И как я уже говорил, задач 900. Можете открыть архив и посчитать. :-) Но я настаивать не буду.

Вместо предисловия: «Не льсти себе – подойди поближе» - надпись в туалете над писсуаром. Математическая постановка звучит следующим образом: для каждой задачи из набора данных найти функции преобразования исходной матрицы в результирующую. Если иметь в виду, что эти функции могут иметь общие «фрагменты», то к этим функциям нужно добавить еще эту общую часть – библиотеку. Критерий качества составляется из следующих частей. 1. Количество правильно решенных тестовых задач 2. Доли расхождений в отображении тестовых задач, если есть различия 3. Количество правильных преобразований исходной матрицы в результирующую для задачи 4. Доли для пункта 3. 5. Максимальная абстракция – в качестве оценки будем использовать количество «закорючек», используемых для описания функций и библиотеки. Т.е. нам нужно минимизировать количество закорючек. Дополнительные ограничения 1. Потребуем, чтобы используемый «объем памяти» при решении не превышал «100 кб.» 2. Время всех вычислений для каждой из задач не превышал условные 100мс. Если ограничения нарушаются, то считаем, что выходная матрица равна входной. Далее нужно задать «сигнатуру», т.е. элементарные операции, из которых может создаваться функция. Здесь можно пойти задам наперед. Разрешим для использования базовые конструкции Python + работа с матрицами + структуры (классы, например). И скажем, что можно использовать математику, которая за этим стоит. Вроде все. Создание системы, которая решит задачу подбора функции для каждой из задач и библиотек – это огромная и сложная задача. Поэтому, нужно подойти к решению проблемы по этапам. Довольно быстро выяснилось, что нужно сначала пойти по ручному варианту создания функций и библиотеки. Что, собственно, и выложено в архиве. Там есть решение (решающая функция) почти всех задач, и хорошо бы этот этап завершить. Если кто-то найдет, чего там еще нет (это можно сделать скриптом), и дополнит пробелы в этой работе – буду очень благодарен. Этот этап, в некотором смысле, помогает формализовать решение задач. В принципе, с помощью AST (Abstract Syntax Tree) можно Python-ские скрипты превратить в «данные» для работы на более высоком уровне. В частности, можно проявить «сигнатуру» (наборы функций и структур Python, необходимых для решения этой проблемы). И т.д. Как видно из скриптов, что решающие задачи функции имеют довольно большую длину даже без учета парсинга изображений. Поэтому перебор функций даже после парсинга практически невозможен. Поэтому нужны механизмы, которые создадут более эффективным механизмы сборки функции (алгоритма). Например, создание описания структуры изображений на основе характеристик теории информации. Тогда начальную проблему можно превратить в проблему «выравнивания» структур исходного и результирующего изображения. Другой пример, - найти разницу между исходным и результирующим изображением, и свести задачу к нивелированию разницы. Т.е. нужно опять просмотреть все задачи, и для каждой из них создать структуры / действия, повторяющие действия человека. Этот этап нас еще ближе приблизит нас к цели. И т.д. Тут главная проблема – борьба с астрономическим количеством различных функций. Нам нужно найти механизмы, которые обходят это колоссальное количество. И, господа, прежде чем рассказывать, как нужно все делать правильно, покажите что Вы сделали. Но вопросы могут быть любые.

Берем задачу 6150a2bd, которая демонстрировалась выше. По номеру находим ее в файле manual.py. Там есть функция преобразования convert, которая превращает исходное изображение в целевое. Полностью она выглядит так: class Example_training_6150a2bd(Example): def convert(self, parser): return np.rot90(parser.image, 2) Т.е. искомая функция - поворот изображения на 180 градусов. Система перебора функций, конечно, найдет это решение. И еще какое-то количество решений находится перебором (точно не помню сколько, может 1%-2%). Сама идея отбора функций по минимальному количеству закорючек (при прочих равных) вполне себе работает. Далее, если не ограничивать ресурсы при вычислении функций, то все быстро сдохнет. Например, в Python 9 ** 9 ** 9 зависает намертво, хотя закорючек всего 5 (операции и цифры принимает за 1 закорючку). Да и интеллект, вообще, связан с использованием минимального количества ресурсов. Правильно было бы засунуть потребление ресурсов в критерий, но в этой задаче это лишнее усложнение. Поэтому указаны простые ограничения от балды. Замороченная оценка качества, точнее, степень совпадения "предсказания" с результатом, тоже весьма полезна, т.к. мы видим, что есть ошибки в данных. Итак, "мешок функций" все же не имеет признаков неработоспособности - есть подтвержденный критерий о том, чем одна функция при решении задачи лучше другой. Задачу (для всего набора данных) поставить мы можем, не можем решить эффективно. Конечно, может выясниться, это не совсем так. Да, допускаю. Мне казалось что это очевидно и тут нечего обсуждать. ---- Зачем вообще заниматься ручным созданием решений, когда нужно создать универсальный интеллект, а не решить конкретные задачи? Ответ в хохме про писсуар. Конечно, хочется сделать нечто, а потом натравить на задачи и получить результат. К сожалению, скорее всего, это закончится ничем. Можно, конечно, заявлять, что работа с задачами приведет к обучению "программиста", а не самой системы ИИ. В какой-то мере так оно и есть, а в какой-то - нет. Один мой знакомый, которому я показывал перебор функций, воскликнул - да это же дискретная оптимизация! Да, есть что-то похожее. Если покопать "промышленные" системы решения дискретных задач (CBC, например), то там есть и перебор (вершин полиэдра в симплекс-методе при решении релаксационной задачи), и еще перебор (дерево в методе ветвей и границ), есть сжатие границ, преобразования уравнений и уменьшение их количества, есть эвристики при поиске в дереве, есть эвристики для поиска допустимых решений, и т.д. и т.п. Универсальный способ решения дискретных задач - это перебор. Для экспоненциального уменьшения вариантов в некоторых ситуациях могут быть применены полиномиальные (в смысле сложности) алгоритмы. Но применение этих полиномиальных алгоритмов связано с издержками, и поэтому их применение связано с другими алгоритмами более высокого уровня. Если на полную врубить все алгоритмы нижнего уровня, то все сдохнет. Поэтому алгоритм второго уровня аккуратно проверяет условия эффективности применения алгоритмов нижнего уровня, собирает статистику по эффективности их применения и делает коррекции на их основе, и т.д. Так вот. Мы можем применить эти принципы для построения решателя для набора задач. Вопрос о том, обучается ли наш мозг при этом, или же мы получаем какие-то результаты, будет все время стоять. Ну, можно ничего не делать. А можно создавать решатель, и смотреть, как он устроен. Посмотреть, какие принципы себя зарекомендуют. ------ Ручное решение почти все задач вручную дало довольно много. Хотя можно утверждать обратное. Во-первых, выяснен минимальный программно-математический аппарат для создания решателя. Во-вторых, простота обработки изображений обманчива - борьбу с задачами нужно разделить на выделение информации из изображений и все остальное. В-третьих, убедился, что мозг тоже занимается перебором (следил за собой, когда в уме решал задачи). Есть "градиентное" движение при решении (шаг по уменьшению различий матриц). Есть релаксация задачи и создание кусков алгоритма на этой основе (приводил пример с построением гистограмм). В-четвертых, убедился, что все задачи нужно решать "одновременно". Иначе скачок сложности может оказаться непреодолимым.

Egg (9**9)**9 это 196627050475552913618075908526912116283103450944214766927315415537966391196809 А 9**(9**9) - это зависание Целочисленная арифметика в Python написана на C. Поэтому смена языка в данном случае ничего не даст.

Речь идет не о переборе, а о задании пространства, в котором нужно найти функцию с необходимыми нам свойствами. Поиск в пространстве действительно можно вести прямым перебором, но это не представляет практического интереса. Это не значит, что пространство функций задано неправильно или что критерий подбора функций неправильный. Наоборот, для простых задач подтверждается, что это годная постановка задачи. Не знаю, как еще объяснить... Если мы посмотрим на классические алгебраические задачи, то там то же самое. Задаются переменные (пусть это будут ограниченные целочисленные), ограничения и критерий. Постановка задачи таким способом не означает, что есть в наличии эффективные алгоритмы ее решения. Гипотетически можно перебрать все варианты, но это на практике не реально. Разработано множество различных мат. пакетов, которые с разной степенью успешностью борются с такими задачами. Одни пакеты не могут решить одни задачи, другие пакеты - другие. Однако использование пакетов на практике приносит пользу, хотя и множество нерешаемых на данных момент задач велико. Что касается задач ИИ, то ее постановка отличается от алгебраических задач только тем, что в качестве переменных могут быть функции. И все. В постановке задачи участвуют функции и их свойства. Получается своего рода функционально-алгебраическая система, в которой могут участвовать обычные переменные, переменные-функции, можно задавать функции-свойства функций переменных (например, потребление ресурсов), ограничения и можно задавать критерий. UPD. На счет Python и разрядности... Гарантировать, что какой-нибудь промежуточный результат не выкинет какой-нибудь фортель заранее при поиске функций не очень то реально. При "переборе" функция может случиться "любой". Ну вот промежуточная матрица может случиться большой и память кончится. Поэтому есть в постановке задачи ограничения по ресурсам. Ограничения должны отсекать зависания и зажоры памяти, а не я.

Это однозначная задача без ошибок. В файле manual.py подозрительные примеры помечены через TODO. Обычно ошибки видны явно. Здесь решение задачи такое :-) class Example_training_1bfc4729(Example): def convert(self, parser): mainObj = parser.splitObject() def getColor(y, x): ys = [obj.y for obj in mainObj.insides] return (x in (0, parser.image.shape[1]-1) or y in (0, parser.image.shape[0]-1) or y in ys) * \ mainObj.insides[np.argmin([abs(s-y) for s in ys])].color return np.fromfunction(np.vectorize(getColor), parser.image.shape, dtype=int) Короче, результирующее изображение "бинарно" всегда одно и то же, только выкрашено в разные цвета для разных пар.

Ну не обсуждайте... У Вас будет тестовое изображение (без результирующей матрицы), то там будет видно, должны ли находиться точки в строках 3 и 8. Т.е. тесты (в паре отсутствует результирующая матрица) тоже могут являться частью обучения. Поэтому представление, что есть обучающие примеры и отдельно тестовые - вообще говоря, не корректно. В обучающей задаче вопрос о 3 и 8 строках бессмысленнен.

По условиям конкурса "допустим" не предполагается. Но если бы в качестве теста в данной задаче была бы картинка A, тогда была бы действительно возникла неоднозначность. "Допустим" приводит нас к выдуманной неоднозначности. Убираем "допустим" - исчезает неоднозначность. Для обучающих задач корректно использование последней пары для контроля/теста. Как мы видим, вопрос о номерах строк не существует.

Как нас учили, нужно в научных работах нужно избегать изложение от первого лица. Привычка.

В какой ситуации возникло расположение квадратов на главной диагонали? Опять в воображении? Ситуация как в стихах Если б я имел коня Это был бы номер Если б конь имел меня Я б наверно помер

20% - это лучшее решение на Kaggle, а не мое. Так что ваш вопрос адресован земному шару.

У вас, я полагаю, абсолютный ноль. Но много сообщений на форуме. ---- Насколько я понимаю, несуществующий вопрос неоднозначности задач можно закрыть. Припоминаю, какие то из задач показались мне неоднозначными. Однако, припоминаю, что по условиям конкурса ответов может 2 - ответ считается подходящим, если подходит хотя бы один из вариантов.

Мне кажется вам нужно на Kaggle - там уровень подходящий. Создайте там тему, спросите сообщество про 20% и про околачивание груш, про зарплату, изложите им своим идеи без предоставления кода. Уверен, там вас оценят. ------ Ладно, загляну через месяц

Постановка данной задачи несколько непривычна – возможно это и является причиной, по которой некоторые примеры кажутся неоднозначными. Обычно же как: есть набор данных, по нему учимся. Потом берем тестовые данные – и на них проверяем. На Kaggle не раз отмечалось, что сами тестовые данные, даже без ответов, - это будущее. Статистика данных будущего позволяет улучшать результат. Они боролись с этим по-разному. Одни в тестовые данные вводили «мусорные данные», которые неотличимы от настоящих, и пользователи не могли пользоваться статистикой будущего. Другой способ – это Code Competition – здесь пользователь представляет код, который вроде как может выполняться на данных, не показывая их пользователю. Это я к чему. В данной задаче все нет так. Тестовые картинки без ответов – это тоже часть данных. Их не просто можно, а нужно использовать для обучения. Часто исходные картинки описываются одной общей «формулой». Поэтому если вдруг «формула» из исходных обучающих картинок не подходит к исходной тестовой картинке – значит формула неправильная. Учет этого нюанса снимает проблему неоднозначности в большей части примеров.

На счет решающих правил, базирующихся на различиях в картинках… В картинках может поменяться всё. Например, нижняя картинка может представлять собой прямоугольник высотой 1 и шириной с количеством 5-ок в исходной картинке. По-моему, был еще пример, где исходная картинка одинаковая для всех – пустая 5 на 5. А результирующие картинки такие: пустой квадрат 1 на 1 для первой пары, 2 на 2 для второй пары, 3 на 3 для третьей, и так далее. Видел несколько фракталов. Есть повороты изображений. Если взятие по модулю 2 двух половин изображений. В общем, французы - это еще те затейники. Есть примеры с прокладыванием трассы. Есть тетрис! Хе… Пример, который меня добил - это пересечение двух линий, одна из которых была "сверху" и видна полностью, и вторая "снизу", которая частично перекрывалась сверху. Поэтому, работа с разницей, - это, хотя и рабочий, далеко не единственный инструмент. Работа с разницей, в простом случае, может производиться прямо на уровне изображений. Чаще требуется построение «структуры» изображений – выделение фона, выделение объектов, описание их характеристик. Потом, действительно, можно постепенно выравнивая структуры и записывая математические преобразования, получить общую формулу отображения.

На счет совместной работы над задачей, и могли ли на Kaggle получить хороших результат. Формально, может быть да, но фактически, видимо, нет. Из того что я видел, они пытались получить множество алгоритмов, покрывающих решение какого-то количества задач. Приз, по-моему, обещали, если результат будет хотя бы 20%. Видимо это и есть порог «фактического нуля» для данной задачи. В результате нулевой порог был превышен на величину статистической погрешности. Работа над проблемой у меня начиналась с составления Excel-таблички, в которую я вписывал, какие «решающие правила» применялись для решения каждой из задач. Было множество заходов – всегда запутывался. Может у Вас получится :-) Подход я изменил – решил вручную почти все задачи с записью их в виде Python скриптов. Общие функции были вынесены в «tparser.py». Чего только там нет… Описания изображений, структур, их создание, изменение, удаление, перемещение… выделение фона, объектов (вложенных в том числе), поиск сеток, текстур … решение задач локального поиска … Теперь есть почти полный перечень, как Вы их называете, решающих правил. Точнее, есть правила преобразований. Но нет правил их применения. Классическое продолжение темы – это создание эвристик, чтобы был не «поиск формул в ширину», а более экономный алгоритм.

В скрипте tparser.py есть и базовый объект (TObject), и наследуемые графические примитивы, и изображения (как объекты). И есть несколько функций (начинаются с "split") для разбиения изображения на объекты. Фон - это объект-прямоугольник самого нижнего уровня, который может быть одноцветным или текстурой. В некоторых задачах такового объекта нет - значит и нет фона (например, в задаче поворота). Есть операции над объектами: создание, удаление, замещение другим объектом, перемещение, масштабирование и т.п. При парсинге изображения создается иерархия - каждый узел имеет дочерние включаемые insides объекты, и соответственно есть parent. Для получения результирующего пиксельного изображения есть функция draw. В общем, выделение объектов есть. Как уже говорилось, выявлены практически все функции, которые используются для преобразования изображений. Так что нерешаемых задач должно быть не так много. При решении задачи может потребоваться рассматривать несколько вариантов разбиения (или не использование его совсем). Любая характеристика объекта может использоваться для создания результирующего изображения. Например: высота, ширина, цвет/отсортированная гистограмма, положение по x и по y. Могут использоваться выражения/функции от характеристик: (высота=широта?), площадь=высота*широта, количество точек не фонового значения, наиболее частый цвет (после фона), срез (для изображений), количество дочерних объектов и т.п. Поэтому жесткой связи между манипуляциями и правилами и применения вроде как нет.

Один из способов задания "функционального пространства" - это так называемая сигнатура. Сигнатура определяет множество закорючек, из которых может быть создана функция. Допуская определенную вольность речи, можно сказать, что в библиотеке tparser.py находится эта сигнатура - из этих "закорючек" и небольшого количества конструкций Python были созданы решения (функции отображения изображений) manual.py. Хотелось бы, для универсальности, чтобы решение проблемы было бы без использования tparser.py. Однако, как мне представляется, это сделать слишком сложно за один заход. Если сравнить сложности самих функций решения задачи из manual.py и код из tparser.py, то становится ясно, что второе намного сложнее. Тем не менее, после создания эффективного решателя для большей части задач с использованием tparser.py, можно tparser.py постепенно подчищать и разрешать использовать универсальные конструкции Python. Тут скорее вопрос способа декомпозиции большой проблемы на проблемы меньшей сложности, нежели вопрос "методологии".