Разработка Тарантоги: Минимальная функциональность экзокортекса

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

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

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

Предпосылки

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

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

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

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

Поэтому вот какую минимальную функциональность я ожидаю от экзокортекса:

• Агрегатор новостей.
• База текстов, связанных с моей активностью.
• Выделение и модификация метаинформации.

Агрегатор новостей

Только одних активных RSS подписок у меня около 300, что выливается в те же 300 новостей в сутки, при более чем 100 фильтрах в Feedly. А ещё есть email рассылки, каналы в Telegram…

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

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

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

Функциональность агрегатора новостей я вижу следующей:

• Управление гетерогенным списком источников новостей.
• Автоматическое извлечение метаинформации из тела новостей.
• Управление фильтрами.
• Сбор актуальных новостей с учётом фильтров.
• Просмотр отфильтрованных новостей.
• Сбор статистики по использованию источников и фильтров.

Список источников новостей:

• RSS.
• Почтовые рассылки.
• Каналы в Telegram.
• Ленты в социальных сетях: Facebook, ВКонтакте.

База текстов

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

Поэтому база текстов значительно ускорит:

• Исследовательские и проектировочные задачи.
• Написание постов в блог.
• Создание документации, описание задач, код-ревью.

В моём случае это большой кусок активности.

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

От базы текстов мне необходимо:

• Управление гетерогенным списком источников текстов.
• Импорт текстов из внешних источников.
• Автоматическое извлечение метаинформации из тела текстов.
• Автоматическое обновление метаинформации при изменении текста.
• Ручное редактирование метаинформации.
• Навигация и поиск по текстам.

Также желательно иметь возможность создавать и редактировать тексты в самой базе.

Список источников текстов:

• Тексты в блоге.
• Посты и комментарии в социальных сетях (Facebook, ВКонтакте).
• Посты и комментарии на форумах и сайтах (gamedev.ru, habr.com, etc).
• История чатов, в которых я участвую (Telegram).
• Переписка по электронной почте.
• Тексты как-либо отмеченные мной:
  • ссылка на текст добавлена в избранное;
  • текст добавлен в избранное на платформе, а-ля habr;
  • текст лайкнут в социальной сети.

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

Работы с метаинформацией

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

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

Примерный перечень метаинформации:

• Уникальные сущности, которые упоминаются в тексте: компании, продукты, персоны, географические объекты, события.
• Источник текста: полный url, идентификатор источника (например, «Хабр»).
• Тип текста: комментарий, пост, etc.
• Характер текста. На Хабре это может быть «урок», «перевод».
• Темы текста. Можно определить по хабу на Хабре, разделу форума или упоминаемым сущностям.
• Время создания, обновления.

От автоматизации работы с метаинформацией я ожидаю:

• Автоматическое извлечение метаинформации из текстов.
• Автоматическое обновление метаинформации, при изменении текстов.
• Конфигурация автоматического извлечения метаинформации пользователем.
• Редактирование метаинформации пользователем.
• Автоматическое выделение зависимостей метаинформации. Например, имеет смысл выделять метки разного уровня детализации на основе статистики их соседства друг с другом и соответственно дополнять метаинформацию текстов. Автоматика может определить, что метка «биология» всегда соседствует с меткой «животные» и ставить её везде, где есть метка «животные».

Синтез

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

Выглядит разумным синтезировать общие требования к экзокортексу на основе проведённого анализа его компонентов.

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

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

Прикладные компоненты одинаково извлекают тексты из внешних источников и хранят их.

Остаются следующие отличия:

• Фильтры новостей в агрегаторе.
• Сбор статистики в агрегаторе.
• Редактирование текстов и их метаинформации в базе.

Статистика — та же метаинформация, она может быть полезна и вне агрегатора. Например, для сортировки текстов при поиске.

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

Остаются фильтры, которые должны доставлять пользователю только самый интересный контент. Но что должно происходить с контентом, который их не прошёл? Должен ли он удаляться? Определённо нет.

Как-минимум, отфильтрованный контент необходимо сохранять для отладки фильтров.

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

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

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

Требования

В итоге необходимо разработать систему со следующей функциональностью:

• Хранилище текстов с метаинформацией.
• Автоматический импорт текстов в хранилище из гетерогенных источников.
• Настройка параметров импорта и списка источников.
• Автоматическое формирование и обновление метаинформации текстов.
• Настройка правил обновления метаинформации.
• Ручное редактирование метаинформации и желательно самих текстов.
• Создание запросов к хранилищу с фильтрацией по тексту и метаинформации.
• Просмотр результатов запросов.
• Создание постоянных view с заданными запросами и свойствами интерфейса.

Списки источников и примеры метаинформации уже упоминались.

Ограничения

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

Логика должна управляться текстами

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

Это позволит получить несколько полезных свойств:

• Интроспекцию.
• Самотестирование — при работе экзокортекс будет проверять свою же логику.

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

То есть надо придти к экзокортексу, который работает на экзокортексе :-D

Композиция over классификация

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

В первую очередь это относится к метаинформации.

Максимальное использование сторонних модулей

Как я говорил в описании экзокортекса 3.5, большинство составных частей экзокортекса готовы или почти готовы для использования.

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

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

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

Примеры нежелательных ситуаций:

• При использовании в качестве хранилища проприетарного облачного сервиса, тот в одностороннем порядке увеличивает стоимость услуг в 10 раз или закрывается, без возможности экспорта данных. Один такой пример у меня уже был, когда в New Relic пересмотрели цены на мониторинг.
• Сервис для сбора данных, например Feedly, меняет API на несовместимое или ограничивает его использование.
• Разработчики перестают поддерживать предобученную нейронную сеть для выделения сущностей в тексте.

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

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

Утрируя, никакого closed source ИИ и closed source софта для ведения заметок.

Разделение на GUI, базу и автоматизацию

Долго искал более конкретное выражение чем «естественным образом», но не нашёл.

Естественным образом экзокортекс делится на три слабо зависимых друг от друга части:

• база знаний;
• система автоматизации;
• пользовательский интерфейс.

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

База знаний должна быть локальной

Распределённое хранение информации выглядит интересно. Но на практике это решение чревато серьёзными проблемами, в частности:

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

Поэтому база знаний должна быть в состоянии работать на одной машине.

А вот автоматизация или пользовательский интерфейс, наоборот, может быть полезно размазать по тем же облакам.