Skip to content
Dmitry Ponyatov edited this page Aug 18, 2019 · 9 revisions

Skynet

Which programming language will be best for making Skynet, and why?

https://qr.ae/TWrO0g

Какой язык программирования лучше всего подойдет для создания Skynet и почему?

Для Skynet определенно необходима модель вычислений, специально предназначения для приложений ИИ (искусственного интеллекта). Последние 50 лет для таких задач Lisp и Prolog рассматривались как готовые к использованию языки и абстрактные машины. Но они показали очень скромные результаты.

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

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

Если вы хотите заняться исследованиями в этом направлении, прежде всего посмотрите на фреймовую модель Марвина Мински. Я играл с ней некоторое время, и она показывает себя как нативное представление атрибутной грамматики и методов ООП. Так что уже сейчас мы можем представить любую программу на любом существующем языке программирования, используя фреймы. Кроме того, вам понадобится некоторая абстрактная машина для запуска этих графов объектов/фреймов -- некоторый интерпретатор, написанный на любом ходовом языке (реализации), который вы предпочитаете (я использую Python). Именно интерпретатор способен сделать эту структуру данных исполняемой. Возможно, нам нужен какой-то инструмент, чтобы сохранять эти структуры между несколькими запусками интерпретатора, и разделять их между многими вычислительными узлами. Определенно, это должна быть какая-то объектная база данных, возможно, ZopeDB является одним из кандидатов для среды Python.

Еще штука, которую мы должны иметь в системе, -- это механизм логического вывода, который способен анализировать фреймовые графы, и некоторый инструмент для визуализации этих структур, чтобы они были удобны для человека. Я рассматриваю Yield Prolog как основу для такого механизма логического вывода, но не факт, что модель языка Prolog способна делать то, что требуется для семантического ИИ. Я хочу особенно отметить, и отчетливо разделить семантический искусственный интеллект и машинное обучение, которое сейчас популярно. Они отличаются так же, как аналитическая математика на основе формул от численных расчетов. Фактически, ML это численные методы. Они работают, но имеют те же недостатки, что и численная модель по сравнению с идеальными решениями аналитической математики.

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

Вся модель представления знаний потроена как направленный граф объектов, наследованных от базового класса Frame:

class Frame:
    def __init__(self,V):
        self.type = self.__class__.__name__.lower()
        self.val  = V
        self.slot = {}
        self.nest = []
        self.ref  = 0
    def __repr__(self):
        return self.dump()
    def dump(self,depth=0,prefix=''):
        tree = self._pad(depth) + self.head(prefix)
        if not depth: Frame._dumped = []
        if self in Frame._dumped: return tree + ' _/'
        else: Frame._dumped.append(self)
        for i in self.slot:
            tree += self.slot[i].dump(depth+1,prefix=i+' = ')
        for j in self.nest:
            tree += j.dump(depth+1)
        return tree
    def head(self,prefix=''):
        return '%s<%s:%s> @%x' % (prefix,self.type,self._val(),id(self))
    def _pad(self,depth):
        return '\n' + '\t' * depth
    def _val(self):
        return str(self.val)
    
    def __getitem__(self,key):
        return self.slot[key]
    def __setitem__(self,key,that):
        self.slot[key] = that ; return self
    def __lshift__(self,that):
        self[that.val] = that ; return self
    def __floordiv__(self,that):
        return self.push(that)
    
    def push(self,that):
        self.nest.append(that) ; return self
  • type хранит класс объекта (фрейма); строки используются не только в демонстрационных целях, но также библиотека парсеров PLY требует наличие этого поля как индикатора типа токена
  • val это значение (value): любой скалярный тип данных, доступный в вашем языке реализации
  • slot ассоциативный массив со строковыми ключами, который привязывает имена как это делают слоты Мински -- имя слота указывает на другой экземпляр класса Frame, формируя сеть фреймов (направленный граф).
  • nest значит вложенный (nested): я добавил это поле так как оно необходимо для хранения любых упорядоченных данных, including branches of AST parsing trees (see any computer language design tutorial)
  • ref это счетчик ссылок, который необходим для управления динамической памятью, если ваш язык реализации не поддерживает автоматическую память (например С++)
hello = Frame('hello') ; hello // hello ; hello << hello
print(hello)

Как видите, это не язык программирования, а универсальная форма данных, которая формируется и работает в любой существующей среде программирования, скажем, Python. Эта структура данных может быть выполнена интерпретатором, поэтому я назвал эту модель EDS: Исполняемая структура данных.

Такая KRR-структура является родной для любого языка / среды программирования, она проста в обработке, и легко читаема человеком даже в виде текстового дампа (дерево):

<frame:hello> @7f1569ddec88
	hello = <frame:hello> @7f1569ddec88 _/
	<frame:hello> @7f1569ddec88 _/

Я не буду писать здесь учебник (на самом деле буду, если вам это интересно), но я должен обосновать модель, предлагаемую как ответ на тему вопроса на Quora. Эта фреймовая модель Марвина Мински расширена упорядочением

Ваша EDS-структура данных может трансформировать другую структуру, и даже саму себя, так что метапрограммирование является одном из основых методов. В зависимости от того, как вы реализуете ваш EDS-интерпретатор, вы не ограничены только парадигмой императивного программирования. Система программирования будет намного мощнее со структурным сопоставлением шаблонов, и Prolog-подобной унификацией (см. YieldProlog выше).

Clone this wiki locally