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

В поисках работ, посвященных метрикам читабельности для русского, я нашел диссертацию Ирины Оборневой "Автоматизированная оценка сложности учебных текстов на основе статистических параметров" 2006 года, в которой Ирина адаптирует несколько формул для английского языка под русский. Кстати, диссер можно найти только в отделе Ленинки в Химках, но разве меня остановишь.

Первая формула называется формулой Флеша и в оригинале для английского (как и все формулы далее) считается так:

K = 206.836-84.6*W-1.015*S (W- средняя длина слова в слогах, S - средняя длина предложения в словах)

Результат лежит на отрезке [0, 100], чем выше, тем проще. 70-80 считается, как "сравнительно легко".

Вторая формула - Флеша-Кинсайда - завязана на уровне образования: результат от 1 до 10 значит, что легко прочитает школьник соответствующего класса; от 11 до 15 - высшее учебное заведение; 16-20 имеют сложные научные статьи. Формулу можно использовать как для всего текста, так и для фрагмента.

K=(0.39x*S) + (11.8*W) - 15.59

И, наконец, индекс туманности. Берем 100 слов в середине текста, подсчитыванием S, а также количество слов, кроме имен собственных, состоящих из трех и более слогов (обозначим за C). В диссере приводятся такие референсы для интерпретации: большинство любовных романов имеют индекс от 7 до 8; люди с высшим образованием могут читать тексты с индексом 16; газеты имеют индекс 7-8.

I = (S + 0.01 * C) * 0.4

Главный вопрос. Как эти индексы скорректировать для русского языка? А давайте возьмем несколько известных литературных произведений, переведенные на оба языка, посчитаем во сколько раз отличаются значения S и W и на такую же пропорцию изменим соответствующие индексы. Гениально и просто. На таких же парах затем измерялась корреляция между читабельностью для английского и русского языка и она составила 0,95.

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

Хорошо, когда есть праздники. Довел до конца дорожную карту по 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

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

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