Хорошо, когда есть праздники. Довел до конца дорожную карту по NLP и анализ вакансий. https://habr.com/ru/post/709364/

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

Усложняется все тем, что если код использует один из DL фреймворков, то знание нужной версии просто жизненно необходимо, потому что ладно будут не стыковки в API, вы замучаетесь от "CUDA devices are not found" потому что не та Куда, не те драйвера и т.д.

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

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

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

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

Last commit date (m-d-y): 06-03-2019
tensorflow<=1.12.2
keras<=2.2.4
numpy<=1.16.4

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

Я бы, конечно, хотел, чтобы этот скрипт еще показывал актуальную версию Куды под соответсвующую версию фреймворка DL, а также драйверы под Куду. Эта инфа доступа в документации, но мне просто было лень парсить ее. А еще можно версию питона указывать. А еще можно упороться и научиться разрешать конфликты версий. А еще можно научиться определять пакеты для версий =<2.7.

Правда, когда я в следующий раз этим займусь, не знаю, да и нужно ли так углубляться. Однако, думаю, что кому-нибудь уже сейчас пригодится этот скрипт сто процентов, поэтому пользуйтесь. Из внешних зависимостей у него только пакет stdlib_list со списком стандартных библиотек. Сам запускал на Python 3.9.

Настало время представить формат, который стал одной из причин, почему я решился создать канал. Я регулярно читаю свежие статьи с arXiv и записываю их краткое содержание себе в obsidian, систему управления заметок, ибо незаписанная статья - потерянная статья. Краткое содержание - это markdown файлик, где кратко, иногда не очень, описано:

* о чем статья,
* метод,
* результат,
* интересные мысли, если есть,
* код из статьи,
* чисто обсидиановские вещи - ссылка на заглушку карты концептов и ссылка на pdf самой статьи

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

Для понимания, какие статьи я читаю:
* эмбеддинги, их свойства, трансформация и анализ;
* NLP в психологии;
* активное обучение, чистка данных, удаление смещения (bias reduction), разметка данных;
* разные задачи: саммаразация, генерация вопросов;
* другие интересные вещи, которые я не вспомнил.

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

Measuring the Measuring Tools. An Automatic Evaluation of Semantic Metrics for Text Corpora

# О чем
В статье проводится масштабное тестирование различных семантических метрик между корпусами. Были указаны критерии, по которым производилась оценка. Предложена методология оценки способности метрик различать человекописные и машинописные тексты.
# Метод
Авторы использовали несколько метрик, сумев разделить их на типы: лексикографический, статистический, дистрибутивный и дискриминативный (Таблица 1). Краткое описание метрик можно почитать в разделе 2.

Для тестирования была использована методология Known Similaryty Corpora (KSC). В двух словах: берем два корпуса (A и B) и смешиваем в различных пропорциях. Зная эту пропорцию, можно ожидать на сколько похожа каждая смесь корпусов на каждый из двух источников. Числом $l$ будем обозначать расстоянием между двумя смесями, если смеси упорядочены по пропорции от A до B. $D_l$ будем называть результат работы метрики, полученной на множестве всех пар смесей, расстояние между которыми равно $l$.

Далее, авторы представили критерии:
* Монотонность - смещение пропорции от корпуса A к корпусу B в смеси должно отражаться монотонно
* Отделимость - два условия: для заданной $l$, $D_l$ имеет низкую вариативность; для $l_2>l_1$ семплы $D_{l_1}$ и $D_{l_2}$ различимы
* Линейность - насколько линейно изменяется метрика при линейном изменении $l$
* Вычислительная эффективность
* Точность - этот критерий не получится описать в одно предложение, поэтому смотрим сами (4.5). Однако, интуитивно понятно, что он означает.
* Устойчивость к объему - неизменяемость метрики при изменении объема корпуса
* Устойчивость к дисбалансу - неизменяемость метрики при использовании корпусов разного объема

Еще авторы проводят тест на способность метрик отделять тексты, написанные людьми, от сгенерированных текстов. Процедура похожа на KSC. Ее смысл в том, что постепенно производить дообучение языковой модели на реальном корпусе A. После каждого дообучения формируется корпус из модели(семплируется) и таким образом набирается множество таких корпусов. Метрика должна убывать по увеличнию количества шагов дообучения.
# Результаты
Довольно большая таблица, результат которой, однако, можно уместить вот в такой красивый график
![[Pasted image 20230109102404.png]]

Касательно теста на способность различать между человекописным и машинописным текстом, не справилась только метрика, основанная на Хи квадрате. Самыми чувствительными оказались метрики FID и IRRP. А метрика ZIPF растет, в отличие от остальных. Авторы это объясняют тем, что хоть корпусы и становятся похожи семантически, лексическое разнообразие падает относительно человекописных текстов.

Код: https://github.com/IBM/comparing-corpora

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

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

Optimizing Readability Using Genetic Algorithms

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

# Метод

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

* Dalle-Chall,
* SMOG,
* ARI,
* Флеш-Кинсайд;

Авторы предлагают три способа для мутаций:
* подбор синонимов через wordnet,
* подбор синонимов через word2vec,
* подбор синонимов из тематических сайтов.

Оптимизация читабельности при минимальном количестве замен, заключается во включении в функцию потерь условия минимальности изменений. Таким образом, условий оптимизаций становится два. Существуют специальные варианты генетических алгоритмов которые умеют работать с несколькими условиями одновременно (см. 4.3)

Для того чтобы быть уверенным в сохранности смысла получаемого текста, авторы вводят третью часть функции, а именно семантическую близость. Делают они это с помощью word mover distance и word2vec.

# Результаты

По результатам бесконтрольной оптимизации читабельности, минимизировать удавалось в среднем на 1 единицу по Флешу-Кинсайду (другие метрики, в таблицах), а максимизировать на 3.5. Однако, такой подход может исказить смысл высказывания. С введением минимизации замен слов, возможно управлять степенью изменений и тем самым контролировать риск изменения смысла. Стоит заметить правило, что чем больше слов позволяется заменить, то больше возможно оптимизировать читабельность. Наконец, введение семантической близости позволяет выбирать слова так, чтобы смысл не был потерян.

Код: https://github.com/jorge-martinez-gil/oruga

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

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

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

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

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

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

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

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

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

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

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

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

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