Экзокортекс: метаинформация
Прежде чем собирать что-то работающее, следует разобраться с центральным элементом всей системы — информацией, которой она управляет. В этом посте я поговорю про метаинформацию текстов, а в следующем про них самих.
Но сначала внесём некоторую ясность в терминологию. Я тут пишу «экзокортекс то», «экзокортекс сё», но ведь софт, о котором я говорю, является только частью экзокортекса. Говорить про него как про целый экзокортекс в корне неправильно. Это, в конце-концов, путает.
Поэтому софту нужно отдельное название: Тарантога. В честь известного профессора. Сначала я думал назвать его Ийоном, но пришёл к выводу, что оригинальный Ийон имеет довольно посредственное отношение к управлению информацией, в отличии от его известного друга. При этом контекст этих персонажей хорошо соответствует уровню бреда, который может породить подобная система.
Напомню примерный перечень метаинформации из описания минимальной функциональности Тарантоги:
- Уникальные сущности, которые упоминаются в тексте: компании, продукты, персоны, географические объекты, события.
- Источник текста: полный url, идентификатор источника (например, «Хабр»).
- Тип текста: комментарий, пост, etc.
- Характер текста. На Хабре это может быть «урок», «перевод».
- Темы текста. Можно определить по хабу на Хабре, разделу форума или упоминаемым сущностям.
- Время создания, обновления.
Требования к метаинформации
Метаинформация, в некотором роде, важнее самих текстов, поскольку именно с её помощью происходит их поиск, а одна из основных задач экзокортекса заключаеся в её модификации и наполнении, чтобы этот поиск облегчать.
В изменении метаинформации заключается и основная сложность работы с ней.
С базой знаний Тарантоги будет взаимодействовать много отличающихся автоматических агентов. Как минимум по агенту на каждый тип источника, на тип выделяемой метаинформации, прочие агенты, дополняющие метаинформацию по хитрым правилам.
Фактически, Тарантога — это blackboard система. Поэтому остро стоит вопрос устойчивости метаинформации и операций над ней к конкурентным изменениям.
Исходя из этого, требования к метаинформации можно разбить на три группы:
- Общие требования.
- Требования к операциям.
- Требования к разрешению противоречий.
Часть требований может быть зачёркнута. Это значит, что далее по тексту я решил от них отказаться, но оставил их упоминание для отслеживания хода рассуждений.
Общие требования
Минимальный набор функциональности и свойств метаинформации, необходимый для работоспособности Тарантоги:
- Хранение множества утверждений о тексте.
- Поддержка CRUD операций над множеством утверждений для автоматики и для пользователя.
- Удобное отображение изменений в метаинформации.
- Возможность отката изменений в метаинформации как одного текста, так и группы текстов, если изменения были связаны.
- Баланс между стандартизацией описания утверждений и свободным форматом.
Для указания на «атомарное свойство текста» я выбрал слово «утверждение». С тем же успехом можно было бы использовать «свойство» или предикат. В этом нет какой-то хитрой логики. «Свойство» мне кажется недостаточно точным, а «предикат» — слишком математическим и чрезмерно конкретным для текущего этапа.
Последнее требование стоит пояснить подробнее.
Поскольку с метаинформацией будет работать множество агентов, часть её структуры должна быть стандартизирована. Например, метки или категории текста должны описываться единообразно. Иначе агенты не будут видеть изменения авторства других агентов.
Однако список утверждений и вариантов их использования не фиксирован. В какую сторону повернётся развитие Тарантоги не известно. Поэтому должна быть возможность записывать в метаинформацию произвольные данные. В частности, любой агент может захотеть хранить дополнительные данные для оптимизации своей работы.
Требования к операциям
С метаинформацией будет конкурентно взаимодействовать множество независимых агентов. Это налагает на неё дополнительные ограничения:
- Метаинформация должна быть идемпотентной.
- Необходимы транзакционные операции над метаинформацией нескольких текстов одно текста.
- Желательны механизмы разрешения классических проблем параллельной обработки данных:
Требования к разрешению противоречий
Из наличия множества независимых агентов также вытекает проблема согласованности изменений, производимых ими. В обычном софте такие проблемы возникают редко, так как большая часть логики линейна. В нашем же случае возможны ситуации, когда два агента имеют диаметрально противоположные мнения о тексте, что приводит к возникновению противоречий в метаинформации.
Противоречия могут быть, как простыми так и весьма сложными, например:
- Агенты А и B одновременно и независимо добавили утверждения о тексте: «X» и «не-X». Должно быть утверждение «X» установлено или нет?
- Агенты A и B независимо добавили утверждение «X», после чего агент C удалил его. Должно ли утверждение «X» быть установлено или нет?
- Аналогичная ситуация, но вместо агента C, утверждение «X» удаляет агент А или B.
- Агент A добавил утверждение «X». На основе «X» агент B добавил утверждение «У». Пользователь отменил изменения агента A. Что должно случиться с утверждением «Y»?
На практике это может случиться, например, если мы запустим двух агентов с одинаковым назначением, но работающих на разных моделях машинного обучения или просто на разных наборах правил.
Чтобы сформулировать требования к разрешению противоречий, необходимо ответить на ряд вопросов:
- Что такое противоречие?
- Возможно ли отсутствие противоречий?
- На что влияет наличие противоречий?
- Необходимо ли определять противоречия?
- Необходимо ли разрешать противоречия или достаточно их определения?
- Какие противоречия необходимо определять / разрешать, а какие нет?
Ответы на эти вопросы особенно важны в контексте реализации минимальной функциональности Тарантоги. Чтобы не закопаться.
Не вдаваться в математику и формализмы, определим противоречие абстрактно. Как нарушение семантической согласованности информации, приводящее к возникновению её различных трактовок. Я думаю этого хватит.
Стоит отметить, что нарушение может быть как в «пространстве», когда одновременно существуют утверждения «X» и «не-X», так и во «времени», когда нарушается последовательность вывода утверждений.
Гарантировать отсутствие противоречий в нашем случае невозможно. Тексты будут описывать не абстрактную математику, а реальный мир, который противоречив по своей природе, не говоря уже о неполноте информации доступной человеку и гарантии ошибок.
Поэтому противоречия будут существовать и влиять на поиск текстов и навигацию по ним. Во время взаимодействия с Тарантогой пользователь среди полезных для него текстов будет видеть нерелевантные.
К сожалению, сейчас нет объективной информации, которая позволит хотя бы примерно определить долю «мусорных» текстов. Может быть такие тексты будут встречаться через один, а может — раз в год. Поэтому определить влияние противоречий на работу с Тарантогой можно только опирайся на субъективный опыт. Например, на опыт использования софта с тегами и категориями, как самой распространённой метаинформацией.
Мой опыт показывает, что почти все варианты появления противоречий встречаются редко. За исключением противоречия при добавлении и удалении одного и того же утверждения. Легко представить ситуацию, когда пользователь удалит или изменит, добавленное автоматикой утверждение, после чего автоматика попытается добавить его ещё раз. Или наоборот.
Поэтому нет необходимости автоматизировать определение или разрешение противоречий в общем виде, до тех пор, пока не появится наработанная статистика по ним. Но необходимо предусмотреть механизм разрешения борьбы агентов за существование конкретного утверждения.
В остальном, достаточно дать пользователю функциональность для просмотра и редактирования метаинформации.
Поэтому требования к разрешению противоречий следующие:
- Возможность для пользователя изучить метаинформацию.
- Возможность для пользователя изучить историю изменения метаинформации.
- Возможность для пользователя вручную изменять метаинформацию.
- Необходим механизм разрешения борьбы агентов за существование конкретного утверждения.
Отношение метаинформации и текста
В предыдущем посте я говорил, что желательно, чтобы логика Тарантоги управлялась текстами, которые в нём же хранятся. Я имел в виду в основном хранение конфигов агентов, как текстов. Но это же соображение хочется распространить и на метаинформацию. Только стоит ли?
В контексте унификации взаимодействия с метаинформацией и с текстами уместно задать два вопроса:
- Может ли метаинформация иметь собственную метаинформацию?
- Возможно ли с метаинформацией взаимодействовать как с текстом?
Представить утверждения не о тексте, а о самой метаинформации, возможно. Например:
- «эта метаинформация содержит много утверждений»;
- «эта метаинформация обновлялась такого-то числа».
С другой стороны, эти утверждения легко трансформируются в утверждения о тексте, например: «метаинформация этого текста содержит много утверждений».
А поскольку метаинформация есть множество утверждений, ничто не мешает хранить в этом множестве утверждения о нём самом.
Поэтому, несмотря на возможную потребность в метаинформации метаинформации (и так далее), вводить рекурсивные отношения для неё нет необходимости. Достаточно разрешить метаинформации хранить утверждения о самой себе.
Теперь посмотрим на особенности взаимодействия с метаинформацией и с текстом, помня об ограничениях минимальной функциональности:
- Метаинформация и текст изменяются в разное время:
- текст — во время импорта или повторного импорта;
- метаинформация — в любой момент после появления текста в Тарантоге.
- Метаинформация и текст имеют разные источники изменений:
- источниками изменения метаинформации являются агенты Тарантоги;
- источниками изменения текста являются внешние по отношению к Тарантоге сущности.
- Метаинформация и текст имеют разную структуру и семантику:
- Метаинформация фрагментирована и может восприниматься как множество независимых утверждений о тексте. Для разных задач могут представлять интересы разные подмножества утверждений из метаинформации.
- Текст обычно представляет собой цельную сущность. Далеко не каждая его часть, например, параграф, может иметь смысл отдельно от текста.
На мой взгляд, различий достаточно, чтобы не пытаться делать метаинформацию подвидом текста.
Но! И это хороший пример, почему в исследовательских задачах не надо сразу бросаться фигачить код.
Мы можем инвертировать вопрос и спросить: можно ли работать с текстом, как с метаинформацией? Нужна ли отдельная сущность «текст» или текст может быть просто одной из записей о сущности в метаинформации? В таком случае, например, может быть несколько текстов об одной сущности или несколько вариантов одного текста в разных форматах или на разных языках.
На этот вопрос я попытаюсь дать ответ в следующем эссе, поскольку пока сам затрудняюсь ответить. Но чуйка говорит, что текст, как отдельная сущность, может быть и не нужен. В этом случае Тарантога превращается в специализированную базу знаний, что куда точнее очерчивает его границы как продукта.
Логика метаинформации
Суммируем предыдущие размышления и на основе их очертим базовые принципы реализации метаинформации.
Метаинформация — множество утверждений, описывающих свойства текста в конкретный момент времени.
Утверждения константны, их можно только добавлять и удалять. Это позволит работать с метаинформацией как с математическим множеством. В частности, позволит сделать её идемпотентной.
Предполагаю, свойства утверждений будут изменяться редко, поэтому их легко можно будет заменить на транзакцию «удалить старое утверждение, добавить новое».
Метаинформация будет определяться историей своих изменений. Это позволит сделать удобный способ отслеживания её состояния, равно как и возможность отката на любой момент в прошлом.
При необходимости, в определении метаинформации через лог легко добавить кэшированием данных на точках сохранения и удаление старой истории.
Откат в прошлое будет выполняться полный — через удаление всех изменений с указанного момента. Сделать выборочный откат всегда можно в будущем, но пока не вижу в нём необходимости — представление метаинформации в виде множества констант практически гарантирует, что агенты смогут самостоятельно восстановить произведённые ими изменения.
Это самые общие моменты реализации, которые ничего не говорят о конкретных её аспектах. А дьявол кроется в деталях. В частности, в решении конфликтов существования утверждений. Напомню, что более сложные противоречия мы пока не трогаем.
Противоречия существования
Как агенты должны решать вопрос (не) существования конкретного утверждения?
Начнём с нескольких тезисов.
В каждом конкретном противоречии может быть верно только одно утверждение из конфликтующих. Поэтому у одного из изменений приоритет должен быть выше, чем у остальных.
Теоретически возможна логика, по которой все утверждения признаются ошибочными, но я предлагаю оставить этот случай для будущих версий Тарантоги.
Агент, утверждение которого отклонили, не должен без обоснования повторно производить вычисления, которые порождают отклонённое утверждение. Это может спровоцировать зацикливание и вызовёт лишнюю трату ресурсов.
Пользователь, в контексте изменения метаинформации, фактически является одним из агентов.
Приоритет изменений можно определять по-разному:
- Для каждого утверждения в отдельности, например, опираясь на достоверность данных, используемых при выводе утверждения, или на бросок кубика.
- Для агента в целом, когда изменения от агента A всегда приоритетнее чем от агента B.
Учитывая:
- Гетерогенную природу агентов, предполагающую использование для их разработки различных технологий различными разработчиками.
- Сложность работы с нестандартными логиками (нечёткой, темпоральной), реализацией которых стал бы первый вариант.
Выбор первого варианта выглядит сомнительным решением. Поэтому остановимся на выдаче приоритетов агентам целиком.
А нестандартных логик вообще будем избегать как огня, потому что мало какой программист сможет реализовать работу с ними без ошибок.
Исправление противоречий существования
Прежде чем перейти к поиску самих противоречий, давайте подумаем как они будут исправляться.
Допустим, у нас есть следующая последовательность событий (не записей в логе, их пока не касаемся, именно событий):
- Агент A добавляет утверждение «X».
- Агент B добавляет утверждение «Y».
- Агент С удаляет утверждение «X», и выигрывает по приоритету.
Останется ли справедливым утверждение «Y»?
Если оно зависело от «X», то его надо удалить, если не зависело — оставить. Но отслеживать зависимости мы не можем — реализовать его нормально для множества агентов не получится — эта функциональность очень чувствительна к ошибкам.
Если мы согласимся оставить «Y» истинным, база знаний начнёт засоряться ложной и информацией.
Если мы согласимся удалить «Y», что эквивалентно откату всех изменений между действиями агентов A и C, то агентам придётся повторно проделать работу по наполнению метаинформации. Даже если она не зависела от утверждения «X».
Изменения агента C должны будут остаться — именно на их основе агенты будут строить новую метаинформацию. Даже если это просто удаление.
Вариант с откатом противоречит требования отсутствия повторных вычислений. Но вариант с появлением «мусорной» информации не предполагает какого-то очевидного (и тем более автоматизируемого) способа борьбы с ней или хотя бы определения её. Поэтому пока остановимся на полном откате, как самом простом и «прямом».
Поскольку в первой версии планируется разрешать только явные противоречия существования, то частный случай приведённого, примера, когда агент C удаляет собственное же утверждение, можно решать аналогичным образом.
Определение противоречий существования
Приорит агентов — это инструмент для разрешения противоречий, но правила его использования пока не ясны. Чтобы сформулировать их, нам необходимо пристальнее взглянуть на утверждения, и на возможные конфликты существования с ними связанные.
Предположим, приоритеты агентов A, B, C таковы, что A < B < C.
Должно ли существовать утверждение «X» после следующих операций?:
- Агент A добавляет утверждение «X».
- Агент С удаляет утверждение «X».
- Агент B добавляет утверждение «X».
Или даже проще:
- Агент C «удаляет» утверждение «X», не проверяя его наличие.
- Агент B добавляет утверждение «X».
Иными словами: считаем ли мы «X не должно быть» отдельным утверждением или операцией над множеством утверждений?
- Если утверждением, то в силе будут изменения агента C.
- Если операцией, то в силе будут изменения агента B.
Если «X не должно быть» — операция
С первого взгляда, в этом случае мы получаем очень простую логику отката неверных утверждений. Если агент с более высоким приоритетом говорит что-то удалить, мы ищем место в логе, в котором находится удаляемое утверждение, и делаем откат на позицию перед ним.
Но у нас появляются проблема, которую можно описать двумя вопросами:
- Как указать агенту A, что не надо снова добавлять утверждение «X»?
- Как агенту C сказать, что «надо удалить утверждение «X»», если он запущен перед агентом A?
Вариантов её решения несколько:
- «X не должно быть» становится утвержденим.
- Добавление отдельного места для хранения такой информации.
Первый вариант очевидно противоречит изначальному предположению.
Второй вариант либо противоречит концепции метаинформации как таковой, если имеется в виду именно отдельная от неё сущность. Либо предполагает использование нестандартных логик и/или множественности представления метаинформации. Оба вариант нам не подходят.
Следовательно, «X не должно быть» — утверждение.
Если «X не должно быть» — утверждение
Если «X не должно быть» — утверждение, то эквивалентно ли оно утверждению «не-X»?
Очевидно нет. «не-X» — явное отрицание «X», а «X не должно быть» — утверждение о неуместности утверждений об «X», про «не-X» данное утверждение ничего не говорит. Например, для утверждения «X» может просто не хватать предпосылок.
Фактически, мы видим три типа значений для утверждения «X»: истинно, ложно, не определено. Последнее — это классический NULL.
В подобной интерпретации операция удаления будет выглядеть в виде отката на состояние до появления удаляемого утверждения и добавление «X» в значении «не определено».
Должны ли агенты знать друг о друге?
Отдельный вопрос, касающийся совместной работы агентов.
Для чего может понадобиться такое знание?
- Для модерирования одним агентом изменений другого. Например, можно было бы для агента со сложным machine learning добавить агента-наблюдателя, который отсеивал бы самые кривые изменения.
- Для формирования «консенсуса», когда один агент следит за изменениями нескольких «дочерних» агентов и, если те вносят одинаковые изменения, подтверждает их своим аналогичным с более высоким приоритетом.
Варианты выглядят интересными, тем более что добавить авторство к утверждениям не составит труда. Поэтому предусмотрим отслеживание авторства, но конкретно его реализовывать будем только, если реально понадобится.
Давать ли агентам доступ в лог метаинформации?
Поскольку лог, в текущей интерпретации логики метаинформации выглядит как append-only последовательность утверждений, то никаких проблем отдача лога не должны вызвать.
Кроме того, интерфейс пользователя — тот же агент, и ему лог нужен.
Поэтому эта функциональность нужна.
Кстати, раз лог изменений append-only, он здорово ложится на блокчейн с агентами в виде умных контрактов и оракулов :-D Прямо стартап получается на стыке ИИ и блокчейна. Можно ещё движок для разработки семантических баз знаний лицензировать на кафедре ИИТ БГУИР :-D
Зависимости между текстами
До сих пор мы говорили об изменениях единственного текста. Теоретически, изменения могут затрагивать несколько текстов или зависеть от нескольких текстов.
Если перенести описанную ранее логику работы с противоречиями на этот случай, получится что периодически потребуется делать откаты куска базы знаний или, не дай бог, всей базы. Что, конечно, нежелательно.
Неизвестно на сколько часто такая ситуация может встречаться, на сколько часто будут всплывать такие зависимости, и на сколько сложно будет жить с ними или без них.
Поэтому в первой версии я предполагаю такие зависимости «запретить». Пока что самая важная логика Тарантоги вырисовывается вокруг работы с одиночными текстами.
Транзакции
Сопровождение идентификатором транзакции записей в логе выглядит несложной задачей.
В этом случае откат изменений происходит, само собой, по транзакциям, а не по операциям.
Поскольку зависимости между текстами пока не предполагаются, реализацию транзакций при изменении нескольких текстов также отложим. Хотя логика в их случае, скорее всего, останется неизменной.