Разработка Тарантоги: Мемплексы

Заметки о разработке Тарантоги — экзокортекса для управления информацией:

Про метаинформацию поговорили, теперь можно поговорить и про тексты. Затронем в том числе и поднятый в предыдущем эссе вопрос: является ли текст отдельной сущностью или утверждением метаинформации.

По названию поста уже можно сделать вывод, что говорить мы будем не совсем про тексты, но давайте не забегать вперёд.

Сначала определимся с тем что такое текст.

Я немного схитрил в предыдущих постах, когда говорил, что экзокортекс управляет текстами. Важны не только тексты, но и картинки, видеоролики, звукозаписи, чертежи и так далее.

Поэтому под текстами я имел в виду не «последовательность символов», а скорее «текстовый документ», который может содержать разнородную информацию, включающую и сам текст и какие-то медиа-объекты.

Далее под текстом я буду понимать именно «текстовый документ», если явно не будет указано обратное.

Концепция текста

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

Каждый из этих элементов может представлять интерес для пользователя, а может не представлять его вовсе. Пользователь может захотеть отметить как целую книгу, так и отдельную главу, абзац или схему. Соответственно, при навигации и поиске может потребоваться найти и отобразить как весь текстовый документ. так и его малую часть.

Поэтому возникает вопрос: что считать единицей оперирования информацией? Что и как необходимо сопровождать метаинформацией: книгу, главу, абзац?

Ответ на эти вопросы зависит от того, как мы собираемся взаимодействовать с текстами.

При этом надо учесть, что представление текста для пользователя и для программы может значительно отличаться. Поэтому следует рассмотреть как минимум два типа взаимодействия с информацией: агентами через API и пользователем через GUI.

Поскольку экзокортекс делается для человека, разумнее начать с GUI.

Про редактирование текстов

Начав писать про GUI я чуть не шагнул в бездну.

Если помните, минимальная функциональность экзокортекса описана как преимущественно readonly с возможностью модификации метаинформации текстов, но не их самих.

Сделано это специально, так как редактирование текстов, особенно импортируемых, имеет огромное количество нюансов, которые в голове удержать сложно.

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

Поэтому ещё раз себе напомню: первая версия тарантоги, если таковая состоится, будет без редактирования текстов.

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

Работа пользователя с текстами

В голову сразу приходит решение в лоб: сопровождать метаинформацией только импортированный текст целиком. В большинстве случаев этого будет достаточно:

• Комментарии и посты в социальных сетях обычно довольно короткие.
• Статьи обычно нужны целиком.

Но бывают случаи, когда важен не только текст целиком, но его конкретная часть:

• В статье про конфигурирование софта может быть важен и весь материал в целом, как урок, и конкретный конфиг, как решение специфической проблемы. Когда эта проблема случится, хочется найти её решение сразу, а не перечитывать весь урок.
• Помещённая в экзокортекс книга, без разметки метаинформацией её меньших частей, будет практически бесполезной.

Я вижу несколько вариантов реализации подобной функциональности:

1. Пользователь копирует интересные ему фрагменты в отдельные тексты с отдельной метаинформацией. Система работает с такими текстами как с полностью независимыми.
2. Пользователь выделяет в оригинальном тексте интересные фрагменты и сопровождает выделения дополнительной информацией. В этом случае текст сопровождается иерархической метаинформацией, а система учится по-хитрому учитывать все уровни её иерархии при поиске.
3. Пользователь выделяет в оригинальном тексте интересные фрагменты, но не сопровождает их метаинформацией, а создаёт прокси-текст, который ссылается на выделенный фрагмент. Этот текст уже сопровождается метаинформацией.

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

Кроме того, не будем забывать про автоматизацию:

• Экзокортекс может самостоятельно предлагать разбиение документов на фрагменты. Например, выделяя цитаты на основе HTML-разметки оригинального текста.
• В метаинформации можно хранить и отношения между текстами. Экзокортекс может самостоятельно определить что текст является частью большего текста и установить соответствующие связи.

С этими фичами, все варианты функциональности для пользователя выглядят более-менее одинаково.

С технической точки зрения:

• Вариант 2 выглядит переусложнённым, так как вводит иерархические зависимости.
• Варианты 1 и 3 начинают выглядеть очень близкими.

Однако копия фрагмента текста может появиться не только вследствие действий пользователя в экзокортексе, но и импортироваться из сторонних ресурсов, причём из нескольких. Поэтому вариант 1 выглядит предпочтительнее:

• не усложняет логику метаинформации;
• не вводит дублирующие механики взаимодействия с софтом;
• не мешает введению дополнительной логики в будущем, например, добавлению прокси-текстов.

Тот приятный случай, когда самое простое решение оказывается и самым правильным.

Работа автоматики с текстами

Так как наши тексты пока readonly, автоматика может взаимодействовать с базой знаний только следующим образом:

• добавлять новые тексты;
• удалять тексты;
• изменять метаинформацию текстов;
• искать тексты по метаинформации и содержимому.

Самый важный момент тут — изменение метаинформации. Для этого агенту необходимо провести некоторый анализ текста. То есть текст должен быть представлен в понятном агенту формате.

Учитывая предполагаемое большое количество агентов и их гетерогенную природу, уместно поставить вопрос: необходим ли универсальный формат представления текстов для агентов? Или один текст может быть одновременно представлен в нескольких форматах?

Агенту от текста могут потребоваться:

• Сами символы текста, без форматирования, если агент будет делать над ним какой-нибудь machine learning или просто регулярки запускать.
• Общая структурно-семантическая разметка, а-ля html, если агент будет пытаться определить что-нибудь по ней. Этот же формат может потребоваться для отображения текста пользователю.
• Специализированная разметка для особых текстов: субтитры, произношение для генерации голоса, программный код, ascii графика, описания таблиц и диаграмм.
• Сырое представление, аналогичное данным в источнике текста.

Как минимум, тексту необходим два формата: сырое представление, чтобы всегда можно было проанализировать его заново, и структурно-семантическая разметка, чтобы его можно было отобразить пользователю.

Теоретически, из структурно-семантической разметки можно автоматически переходить к чистому тексту. В неё же можно встраивать специализированные форматы, как отдельные её блоки.

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

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

В пользу этого говорит и следующее соображение.

Тексты — одно из представлений мемплексов

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

Тем более что концептуально они похожи и имеют такую же рекурсивную структуру.

Возьмём для примера звукозапись. В ней интерес для пользователя может представлять как вся запись целиком, так и её часть. Как и в случае с текстом, разные части звукозаписи могут иметь разную семантику и структуру. Например, запись подкаста может состоять из диалога, монолога, песни, рекламы, блока новостей.

Эти же соображения справедливы для изображений и видеозаписей.

Поэтому уместно говорить не столько о текстах, сколько разных формах представления мемплексов: текстах, аудио, видео, изображениях.

Мемплекс может иметь несколько представлений или срезов. Например, разговор может быть представлен как видео-/аудио-записью, так и её стенограммой.

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

В то же время, часть метаинформации может относится именно к конкретному представлению. Как минимум, для каждого представления будут уникальны: формат, дата создания, источник.

Кроме того, в каждом представлении для пользователя могут быть важны разные части.

Как Тарантога должен работать с мемплексами?

Или, перефразируя: как соотносятся мемплекс, его представления и метаинформация?

Однозначно можно сказать, что каждое представление может сопровождаться уникальной для него метаинформацией и должно по ней находиться, не путаясь с родственными представлениями того же мемплекса.

Также очевидно, что метаинформацией сопровождается и сам мемплекс.

Поэтому главный вопрос: как соотносятся мемплекс и его представления?

Вариантов может быть несколько:

1. Мемплекс и представление вводятся как равноправные сущности, каждая со своей метаинформацией. Представление хранит в метаинформации ссылку на мемплекс. Утверждения метаинформации явно делятся на утверждения о мемплексе, которые всегда записываются в его метаинформацию, и на утверждения о представлении мемплекса, которые всегда записываются в конкретное представление.
2. Мемплекс вводится формально, как идентификатор, который присутствует в метаинформации каждого представления. Общая метаинформация распространяется по всем представлениям одного мемплекса.
3. Представление вводится формально, как идентификатор, который сопровождает часть метаинформации мемплекса, или как его неотделимый элемент.
4. И мемплекс и представления вводятся формально, через идентификаторы, которые могут присутствовать как часть утверждения о сущностях, которые просто являются контейнерами для метаинформации.

Вариант 1 усложняет реализацию агентов и запросов в целом, так как требует учитывать разделение на несколько сущностей как при поиске так и при изменении метаинформации. Возможно потребует транзакций над несколькими сущностями или некоторого их урезанного варианта.

Вариант 2 требует транзакций над несколькими сущностями. В посте про метаинформацию было решено не делать их в первой версии из-за потенциальной сложности. Распространение изменений метаинформации по представлениям может оказаться нетривиальным.

Вариант 3 вводит иерархичность / множественность части метаинформации, так как одинаковые утверждения могут относиться к разным представлением. Например, может быть две звукозаписи в разном качестве.

Вариант 4 может в разных пропорциях сочетать особенности вариантов 2 и 3, что потребует, потенциально, большей стандартизации протокола чем вариант 1.

Варианты 2 и 4 выглядят менее выгодными из-за потенциальных проблем при распространении изменений метаинформации и транзакций.

Вариант 1 выглядит лучше за счёт нормализации, но требует что-то вроде транзакций над несколькими сущностями.

Вариант 3 удобен для навигации по мемплексам и прозрачен для агентов, которые не завязаны на конкретные представления. В то же время он усложняет реализацию агентов, которые на них завязаны, в том числе реализацию GUI, которому потребуется эти представления различать и по-разному отображать.

Я считаю задачи, поставленные вариантов 3, решаемыми, поэтому остановлюсь на нём.

Итого

Тарантога будет управлять не текстами, а мемплексами.

Каждый мемплекс может иметь несколько представлений, которые хранятся в его метаинформации.

Это усложнит реализацию части агентов и GUI, но сделает его потенциально более гибким и устойчивым к изменениям.

Таким образом, Тарантога превращается в blackboard базу знаний, которая оперирует множествами утверждений и умеет делать работать с историей их изменений.

Основное отличие Тарантоги от других баз знаний в том, что он будет ориентирован на активную интеграцию с человеком и не делает ставку на математичность и строгость своей логики.