А еще вот такая библиотека попалась на глаза. Надстройка spacy, которая считает разные характериситки текста.
https://github.com/HLasse/TextDescriptives

Я потихоньку строю свою инфраструктуру управления знаний и иногда у меня возникает дикая боль, что я не Билл Гейтс.

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

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

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

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

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

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

Я его установил и потыкал. В целом пока сыроват: сейчас на одном сервере запустить только одну задачу разметки, нет хоть какого-то экрана приветствия - сразу попадаешь на интерфейс разметки, администрирование происходит через yaml-файлы, элементы UI не очень работают, да и сам UI квадратно-прямоугольный.

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

Еще они обещают конфигурируемый интерфейс, как у Label Studio. Однако, не хочется верить, что конфигурирование через yaml и html файлы в слепую это их конечная цель. А еще они обещают подсчет IIR. Вроде мелочь, а приятно. Разметку нельзя скачать через UI - она сразу пишется в файлы на сервере. Не могу понять, здорово это или хорошо, поскольку когда работаете с персоналкой, например, эта кнопка и не нужна.

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

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

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

Написал статью о способах характеризации текстовых датасетов и об их влиянии на обобщающую способность моделей. Призываю почитать, подумать, написать.
https://habr.com/ru/company/mts_ai/blog/711764/

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

Когда я присоединился к команде волонтеров по борьбе с суицидами, одним из направлений был анализ групп смерти под общим названием Синий кит в Телеграме. Кто не в курсе, что это за группы такие замечательные, прошу к прочтению вот эту статью моей коллеги психолога.
Размышляя о методах, мне пришла в голову идея, что неплохо было бы иметь списки всех диалогов, которые ведутся в группе, чтобы понять кто с кем взаимодействует, насколько активно и прочее. В группах, конечно, делаются реплаи, но не так часто, как этого хотелось бы. Поэтому захотелось заиметь такой инструмент, который бы восстанавливал взаимосвязь "сообщение-ответ". И вот потихоньку работаю в этом направлении.
Покажу вам результаты первичного анализа существующих явных взаимосвязей (картинки - постом ниже).
Всего реплаи имели только 20 процентов из 315834 сообщений. Было интересно, как распределены расстояния (gaps) между сообщением и ответом и каково распределение количества ответов на одно сообщение. В целом, ожидаемо, что оно будет напоминать экспоненциальное, но вот расстояние в одно и два сообщения идут рука об руку.
Далее, было интересно посмотреть, а соберутся ли какие-то сообщения, имеющие реплаи в серию — треды. Замечу, что треды могут иметь две структуры: цепи и деревья.
Тредов собралось 3762, а цепей уже 18342. Соответственно, интересно посмотреть распределение длины цепей, количества вершин и уровней в деревьях.
Имея такие структуры, было интересно посмотреть на сколько они простираются в общем диалоге (spans) по сообщениям.
Как видно, преобладают легковесные структуры: цепи в две вершины и деревья с двумя уровнями, включая корень. И простираются они до 3 сообщений включительно, что согласуется с распределением структур.

Что касается результатов модели, предсказывающей явлется ли сообщением реплаем другого, то там пока особо говорить нечего. Точность в 0,64 на сбалансированном датасете. Но там такие тексты, что самому иногда не сразу верится, что это реплай.

Наводил сегодня порядок в своих датасетах и хочу сказать одно: никогда не делайте копии датасета! Датасет должен быть один. Из этого вытекает другое правило — все датасеты храните в одном месте независимо от проекта и тогда у вас не будет соблазна скопировать датасет из папки одного проекта в другой.

Другой вопрос, что делать с производными датасета. По папочкам их раскладывать долго и муторно, а еще ведь надо описать, как этот датасет был получен из исходного. Если таких производных немного, то это терпимо. А вот если вы итеративно создаете датасете из разных источников, то вы взвоете вспоминать что, куда и для чего, если вы вдруг забыли удалить временные файлы. У меня пока из таких датасетов только датасет по детекции суицидальных наклонностей: там и разные пользователи твиттере, и сообщения из конференций Телеграма, и всякие тексты со скриншотов комментов, распознанных помощью OCR не спрашивайте.

Чтобы избежать таких проблем, я всем рекомендую освоить бесплатный инструмент dvc, если вы еще не. Он вам поможет и данные версионировать, и пайплайны их получения, и метрики, и сами модели. Не, конечно, вы можете пойти во все тяжкие и использовать ClearML - штука бесспорно потрясная, но dvc хорош тем, что он работает поверх гитовых реп, которые спокойно можно хранить и на Гитхабе, и на локальном сервере Гитеи, а сам является утилитой CLI.