Изначально пост был размещен на Хабре в блоге MWS AI. На правах авторов, дублируем его в нашем блоге.

Привет, Хабр! В этом посте речь пойдет о специфическом датасете, предназначенном для решения очень важной задачи — разработки ML-инструмента, помогающего своевременно выявлять предпосылки и предотвращать суициды. Мы с командой «Пситехлаб», специализирующейся на ИИ-решениях для психотерапии, собирали его по вечерам. Этот проект диссертационный, он не входит в мои обязанности в рамках работы в MWS AI, но опыт, приобретенный в компании, стал базой, без которой его бы не было.

Мы написали научную статью по созданию этого датасета. Если будете использовать наш датасет, пожалуйста, процитируйте.

Давайте начнем с контекста. Почему этот проект так важен

По данным ВОЗ, мир ежегодно теряет более 700 тысяч человек вследствие суицида. Представьте, целый город, причем не маленький, исчезает каждый год. По России свежую статистику мне пока не удалось найти, но вот в 2019-м было 17 тысяч случаев самоубийств, в 2022-м — 13,5 тысяч (это данные Росстата). Хорошая новость в том, что количество таких трагедий у нас сокращается год от года: с момента пика, который пришелся на 1994 год и составил рекордные 61,8 тысяч случаев, — падение почти в шесть раз! Но мы очень хотим, чтобы это число падало еще быстрее. И вообще, чтобы оно было нулевым.

На это и направлена наша инициатива. Мы хотим помочь вовремя оказывать поддержку людям, находящимся на грани. Существуют специализированные НКО, которые ищут таких людей в социальных сетях и помогают им в пределах своих прав и возможностей, а также сотрудничая с МВД и ФСБ. А задача команды «Пситехлаб» — облегчить этот поиск.

Как это происходит

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

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

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

Волонтерский ML

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

Важный дисклеймер: каждый раз, когда я рассказываю про свой проект, почему-то возникает впечатление, будто мы строим модель, предсказывающую именно суицид, что не так. Поэтому регулярно слышу вопрос «У вас психологи размечали?». Нет, не психологи. Мы лишь определяем тексты, которые описывают определенные факторы (пример я приводил чуть выше). Чтобы определить, что человек пишет, что ему плохо или что он пережил насилие или травлю, не нужно быть психологом. Достаточно просто иметь здравый смысл. Наша идея в том, чтобы волонтером мог стать каждый человек. Со всем этим дисклеймером и контекстом давайте перейдем непосредственно к сборке датасета.

Как мы собирали датасет

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

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

Из интересного: обычная модель сентимента, которая предсказывает нейтральный, негативный или позитивный сентимент, тексты с суицидальными мыслями определяла как нейтральные. Например, фраза «я хочу умереть» оценивалась как нейтральная. Для антисуицидальной части датасета, о которой я расскажу чуть позже, нам очень помогла модель эмоций. Это логично, ведь антисуицидальные тексты, как даже из названия можно догадаться, часто связаны с такими эмоциями, как радость (Joy) или удивление (Surprise). Итак, мы собрали и обогатили данные. Теперь перейдем к сердцу любого датасета — инструкции.

Инструкция

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

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

«Я ненадолго отошел, а когда вернулся, она успела прочитать всю нашу откровенную переписку».

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

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

1. Пресуицидальные сигналы: факторы, склоняющие к суициду.
2. Антисуицидальные сигналы: факторы, условно сберегающие.
3. Нерелевантные сигналы: большая часть текстов, которые нам неинтересны и которые мы хотим исключить из рассмотрения.

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

• Атомарность — фактор нельзя «разбить» на составляющие.
• Семантическая независимость — тексты разных классов должны как можно меньше пересекаться по смыслу.

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

На картинке выше показан пример того, как мы анализировали существующие системы классов. Я называю эту технику «Доска настроений». Мы просто выписываем все таблички с факторами и маркируем их одинаковым цветом, если считаем, что они похожи. Затем пытаемся их объединить: какие-то выбрасываем, какие-то добавляем.

Вот пример сигналов, которые мы выделили: красный — пресуицидальный, зеленый — антисуицидальный. Всего у нас получилось 33 пресуицидальных класса, объединенных в семь групп, и 12 антисуицидальных классов без деления на группы.

Тестовая разметка

После того как собрали базовую сетку классов, решили провести тестовую разметку собственными силами. Ее схема состояла из двух кругов:

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

Что мы выявили в результате тестовой разметки?

Во-первых, мы обнаружили, что наши тексты часто содержат несколько классов. Это multi-label. Из этого напрямую возникают некоторые технические вопросы:

• Как объединять разметку, если один текст размечен более чем одним человеком?
• Как считать степень согласия?

Первую проблему мы решили мягким голосованием большинством. Составляем единый список из всех классов, которые поставили люди, и из него выбираем те, что встретились больше, чем n раз. На нашей тестовой разметке такой подход дал хорошие показатели по покрытию — количеству текстов, которые имеют хотя бы один класс, и итоговому качеству меток. У простого голосования большинством слишком много примеров просто не получали никакой метки.

Вторую проблему решили с помощью альфы Криппендорфа и специальной метрики MASI (Measuring agreement of set-valued items), которая используется в качестве ядра. Эта метрика на самом деле представляет собой метрику Жаккара со специальным коэффициентом. Из коробки ее можно посчитать с помощью — барабанная дробь — NLTK.

Еще одна особенность наших данных — это субъективность. Когда мы на этапе обратной связи разговаривали с членами команды, мы не всегда могли оспорить их выбор класса. То есть они ставили какой-то класс, мы считали, что он неправильный, спрашивали «почему?», они отвечали, и мы как будто бы соглашались, что «вроде окей». Это делает нашу задачу очень близкой к сентименту и к эмоциям. Несмотря на то, что классы прописаны довольно хорошо, жизненный опыт все равно играет большую роль. Кто-то спросит, а почему мы не указывали такие примеры как частные случаи (корнер-кейсы)? Проблема в том, что таких текстов было много и мы с коллегой просто бы не вывезли следить за длинным непротиворечивым списком таких случаев.

Где искали разметчиков

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

Проблема в том, что Яндекс.Толока ушла в начале 2024 года, вместо нее появились Яндекс.Задания. Казалось бы, что могло пойти не так? А пошло не так то, что эта платформа не работает с физическими лицами: вы не можете быть заказчиком так просто — вам обязательно нужно юридическое лицо. Мы потратили очень много времени на то, чтобы такое юрлицо организовать.

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

Среди всех платформ, где мы искали разметчиков, нас очень удивил Фриланс.ру, где мы собрали целых 30 откликов. Пришлось даже выбирать по сопроводительным письмам. Мы выстроили процесс найма таким образом, чтобы даже люди без опыта в разметке могли научиться и минимизировать ошибки в результате. В целом, как видно, нам это удалось: 27% ошибок в начале, конечно, много, но 4,6% в конце процесса — это уже приемлемо.

Интересный момент: во время проверки тестовых заданий разметчиков мы чаще всего сталкивались как раз с ошибками, связанными с нарушением тех двух принципов, о которых я говорил: отношение содержания текста к автору и недопустимость интерпретаций. Еще занятный факт: почему-то текст, где было рассуждение типа «А если я не отдохну, то превращаюсь в ходящее зомби», все восемь человек посчитали как свершившийся факт и поставили соответствующий класс.

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

Какие инструменты использовали

Мы размечали данные в Label Studio. Это очень хорошая платформа, ключевая особенность которой в том, что она позволяет создать интерфейс почти под любые задачи. Я пока не встречал задач, для которой бы у меня не получилось создать интерфейс. Плюс у меня большой опыт работы с ней. Вот так выглядит интерфейс разметки, который мы использовали.

Следующий важный вопрос: где мы хранили данные? Мы использовали ClearML. Если вы никогда не сталкивались с потерей данных или путаницей в версиях, то и хорошо. Чтобы и впредь не сталкиваться, используйте ClearML или аналогичные платформы, которые позволяют версионировать датасеты. Поверьте, это очень важный аспект.

Забота о разметчиках

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

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

Как мы верифицировали и исправляли датасет

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

Чтобы проверять датасет глобально, мы сами размечали по 185 примеров с каждого блока параллельно основной разметке. Перфекционистов сейчас щелкнуло: почему не 200? Это артефакт от схемы проверки, которая в итоге не пошла, а менять уже было накладно. После выполнения блока мы сравнивали разметки между собой. Если количество ошибок превышало наперед заданный порог, то мы отсматривали расхождения на предмет спорности разметки. Если после такой проверки количество ошибок все еще превышало порог — такой блок возвращался на доработку.

Порог ошибок от числа проверок у нас был 15%. Это число мы сформулировали на основе похожих работ. Если посчитать общий процент ошибок между разметками, то получается, что мы прошли по тонкому льду: для теста мы получили 13,99%, а для трейна — 14,55%. Когда начали обучать модели, выяснилось, что антисуицидальная модель у нас была ужасной по качеству. Мы это ожидали, но не на таком уровне, который увидели. Ожидали потому, что коллеги во время тестовой разметки отмечали, что антисуицидальная часть шла труднее. После анализа ситуации мы решили пересобрать классы для антисуицидальной части и переразметить ее. Как мы это делали, а также как искали ошибки в пресуицидальной части — отдельно писали в нашем девлоге.

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

Что мы получили в итоге

Всего мы собрали 57 810 примеров. Пресуицидальная часть содержит 38 406 примеров, антисуицидальная часть — 9702 примера, нерелевантных примеров тоже получилось 9702 штуки. Согласие между разметчиками по альфе Криппендорфа для пресуицидальный части для теста — 0,542. Чуть больше четверти примеров содержат больше чем один сигнал. В таблицах ниже показано распределение примеров в соответствующих частях.

Распределение в антисуицидальной части

Распределение в пресуицидальной части

Обучение модели и результаты

Самое время поговорить о результатах обучения модели — то, к чему мы шли все это время. В качестве базовой мы использовали BERT, поскольку за шесть лет своего существования он стал таким своеобразным Бейзлайном Бейзлайновичем для подобных задач и с ним очень удобно работать. Мы пробовали другие модели типа DeBERTa и RoBERTa, но старый добрый ruBERT показывал лучшие результаты.

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

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

Вот такие результаты мы получили.

Кстати, наша формальная цель — 70 пунктов по F1-макро для обеих моделей, в которых от трех до семи классов. Чтобы ее достичь, мы немного поколдовали над структурой классов, а кроме того, выбросили некоторые примеры из трейна, которые были шумными. Под колдовством имеется в виду объединение каких-то классов в один как на уровне группы, так и между собой. Например, мы решили оставить классы чувств как группу, потому что, пожалуй, это самый сложный для модели класс. Классы «мысли о смерти» и «намерения о смерти» было решено объединить в один, потому что второй оказался малочисленным и модель не могла уловить его суть. При этом класс этот очень важен, мы не могли его выбросить.

В итоге смогли подобрать конфигурацию, когда мы имеем наибольшее число классов при заданном пороге по F1 в 70 пунктов. Для пресуицидальной модели получилось 15 классов, для антисуицидальной — 10. Надо сказать, что каждая модель также включает в себя класс антагониста, то есть пресуицидальная модель может определить антисуицидальный сигнал, а антисуицидальная — наоборот.

О нашей платформе

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

Кроме формата «ленты» постов, вы можете посмотреть на временной график предсказаний, чтобы оценить тренды в настроении и состоянии пользователей, — особая фича нашей платформы. Пример интерфейса:

Платформа открытая и вы можете попробовать ее здесь: https://github.com/psytechlab/kitoboy. Там же найдете ссылки на смежные репозитории, модели и датасеты — будем благодарны, если оцените :)

Планы на будущее

После анализа ошибок моделей у нас еще осталось несколько неприятных вещей, которые надо исправить в датасете. Да и вообще хочется значение альфы Криппендорфа >0,7. Для этого надо как-то улучшить методологию разметки, не сводя ее к длиннющему списку корнер-кейсов.

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

• Использовать LLM для суммаризации текстов, которые были определены как какие-либо сигналы.
• Научить LLM определять суицидальные статусы с объяснением. Учитывая, что сейчас модели рассуждают из коробки, это сделать несложно.
• Включить LLM в процесс разметки.

С точки зрения платформы у нас тоже есть идеи, куда расти и что делать:

• Сделать сервис парсинга социальных сетей. Сейчас данные нужно загружать из csv.
• Реализовать записки наблюдателя, куда волонтер может записывать какие-то выводы. Также это интерфейс для функций LLM выше.
• Добавить ролевую систему пользователей платформы с разграничением доступов. В теории должно быть минимум две роли: волонтер, который выполняет анализ пользователя, и супервизор, который проверяет и оценивает самих волонтеров.

Хотим сказать спасибо всем, кто принял участие в разметке данных: Жанна Насхулиян, Анастасия Тюкаева, Артем Загидулин, Ирина Хмелева, Леонид Фомин, Алина Рябушева, Наталья Матвеева, Татьяна Солошенко, Денис Мартынов, Наталья Солошенко.

Давайте сделаем этот мир чуточку лучше.

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

Мы выступали на площадках с разработчиками (Python Meetup, ODS Data Fest) и психологами (CBT FORUM 2025, Открытые Двери.CONF). Наши «агенты» (в смысле человеки) есть как в Москве, так и в Питере. Выступления дают свои плоды: мы запартнерились с проектом «Открытые двери» — платформой доступной психологической помощи. С ними мы делаем бот-тренажер для психологов. Демо-версию мы показали на октябрьской конференции, где получили первый фидбек.

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

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

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

Кстати, если вдруг вы студент, который ищет тему для курсача или диплома, или вы просто хотите что-то поделать для команды, у нас есть для вас кое-что. Нам очень хочется научиться делить сложные предложения на русском языке на составные части. По неведомой причине, нормально работающих методов для этой задачи нет. Всё, что нужно сделать, это разметить датасет и обучить/потестить разные модельки. Если интересно, пишите нам на почту psytechlab24@gmail.com.

Теперь о планах на предстоящий год.

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

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

Еще по айдентике и бренду чуть-чуть. Мы поняли, что о «ПсиТехЛаб» очень спотыкается глаз (и печатать неудобно), поэтому будем везде просто «Пситехлабом», как и весь текущий год. Также надо сделать логотип, а то наша картинка с котом всё-таки больше про настроение.

Есть у нас еще россыпь идей, которые мы прорабатываем и думаем, какую из них взять в первую очередь. Оставайтесь с нами, чтобы узнать о них.

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

Про затравку еще кое-что. Мы тестировали три варианта: zero-shot, few(8)-shot и few-shot with keywords (fskw). Готовы поспорить, вы никогда не слышали про третий. Потому что это наша задумка. Идея вот в чем. Как бы вы не старались, но вы не сможете в какое-то резонное количество примеров для режима few-shot запихнуть различные лексические особенности класса. Тем более, что в некоторых работах отмечается, что с ростом примеров начинается деградация качества. Вот мы и решили добавлять такие классово-значимые слова в затравку.

Еще у нас было шесть моделей, три закрытых и три открытых, и два значения температуры: 0.7 и 1.

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

Мы начали с простого: обучить только на генерате, на половине реального и половине генерата, на всем реальном и таком же количестве генерата. Второй и третий вариант мы рассматривать не будем в этом посте (tl;dr: результаты плюс-минус такие же, как в исходном варианте, где все данные реальны), обойдемся первым.

Если смотреть на качество итогового классификатора по f1-macro в разрезе каждой части конфигурации, то в среднем лучшей моделью стала llama-4-maveric (помните такую?) среди всех трех сеттингов. Изменение температуры влияло на качество только на антисуицидальном датасете: значение 0.7 в среднем лучше на 4 пункта, чем значение 1.0. Наша придумка fskw также показала лучшие результаты по всем трем датасетам.

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

Для начала мы нашли этот условный минимум. Для всех трех датасетов это оказалось 10 процентов от реального объема. Потом в эти 10 процентов добавляли генерат объемом в 25, 50, 75 и 100 процентов от исходного объема каждого класса. Получилось что уже в первом случае для двух из трех датасетов происходит резкий рост качества модели (в целом, такое же рост наблюдается между 10 и 20 процентами реальных данных). После взлета наблюдается уже не такой заметный, но тоже прирост качества. Лучшие варианты миксов отстают от исходной модели на 3-5 пунктов. Кстати, далеко не факт, что лучшим миксом окажется вариант со 100 процентами генерата. Датасет сентиментов стал тем, где этот фокус не получился.

Далее у нас ряд экспериментов с разными метриками данных. Наша цель — найти метрику, которая по паре тысяч семлов модели могла сказать, что использовать перспективно, а что не очень.

В качестве базовой ЯМ у нас была ai-forever/rugpt3small_based_on_gpt2, потому что с ней просто работать в плане запуска на имеющемся железе. Взяли эту модель, наши переводы, прогнали всё и получили перплексию. Быстро поняли, что лучше работать с логарифмированной перплексией, потому что для коротких текстов ее значения иногда долетают до Венеры. В итоге получилось у нас вот такое общее распределение и, далее, распределение, зависящее от длины текста.

На общем распределении видно, что колокол смещен влево, а справа имеем длинный хвост. Такая картина дала надежду на правдоподность гипотезы. На втором распределении хорошо заметно, что размах перплексии изменяется от длины текста. Поскольку на совсем уж коротких текстах перплексия неадекватная, мы решили рассматривать только тексты длиннее пяти токенов. Мы решили в качестве границы брать четвертый квартиль: всё, что выше, мы считаем «плохим» переводом из-за большой перплексией. Чтобы учесть изменчивость размаха, мы распределеям значения длин в «корзинки» по децилям и считать квартили перплексии внутри каждой корзинки.

Вот такие переводы алгоритм посчитал «плохими»:

А как нам убрать кавычки вокруг слова «плохих»? Надо провести стат. тест с людьми! Вот как мы его организовали:

1. Отобрали случайным образом 25 переводов, которые мы определили как плохие.
2. Отобрали случайным образом 25 переводов из всего объема данных.
3. Удостоверились, что выборки не пересекаются.
4. Смешали все примеры в одну кучу таким образом, чтобы потом их можно было разъединить по исходным группам.
5. Разметили переводы по качеству по пятибалльной шкале.
6. Разделили оценки в соответствии с двумя исходными группами.
7. Полученные группы передали в функцию подсчета U-критерия Манна-Уитни scipy.mannwhitneyu(perplexity_selected, random_selected).

Вот, что мы понимали под «качеством перевода»:

Оценивать качество перевода следует по их естественности с точки зрения русского языка. Чтобы было более понятно, вот список некоторых критериев, что мы под этим понимаем:
- Корректность грамматических конструкций (склонения, согласования в падежах и т.д.)
- Перевод должен точно передавать смысл оригинального текста
- Даже если смысл текста передан верно, текст не должен «резать глаз».
- Стиль перевода соответстует стилю оригинала.
- Фразы внутри переведенного текста должны быть связаны друг с другом логически и грамматически.

Разметчиков мы искали на Профи.ру. Критерий — либо образование переводчика, либо опыт работы таковым от 2 лет. Всего нашли трех людей. Итоговая оценка примера считалась как среднее от трех оценок. Иии… p-value=0.08. Это можно читать примерно так: «оно, может, даже работает, но лучше поискать что-нибудь понадежнее».

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

1. Отобрали 200 «плохих» текстов.
2. Переводили с помощью мощной модели (в нашем случае gpt-4o).
3. Просили человека сравнить, какой перевод лучше (или одинаково). Критерии качества см. выше.
4. Результаты запихивали в биномиальный тест binomtest(new_win, n=n, p=0.5, alternative='greater').

В итоге получили p-value=0.001. Правило «просто возьми модель побольше» работает.

Последнее, что мы по касательной затронули, это LLM-as-a-judge. Поскольку мы команда независимая, бережное отношение к ресурсам — наша абсолютная база. Проверка каждого придуманного алгоритма отборщика людьми с этим плохо соотносится. Было бы здорово с помощью БЯМ отбраковывать совсем плохие варианты.

Мы специально ничего не изучали в этой теме, просто решили провести еще один простой стат. тест на тех данных, что у нас есть: есть ли какие-то ассоциации между оценками разных БЯМ и оценками людей по качеству перевода? Тестировали мы вот этих товарищей:

• gpt-4o
• claude-sonnet-4
• gemini-2.5-flash
• qwen3-235b-a22b
• deepseek-chat-v3-0324
• llama-4-maverick

При этом тестировали в двух вариантах:

• стандартный — просили БЯМ поставить оценку от 1 до 5.
• упрощенный — просили БЯМ просто сказать плохой ли перевод или нет, а оценки людей мы схлопнули по схеме {1,2,3} — «плохой», {4,5} — «хороший».

Наличие ассоциации проверяли с помощью хи-квадрата. В результате получили вот такую таблицу

И тут странности. Ни одна БЯМ никак не соотносится с первым разметчиком, со вторым, конечно, не в ноль, но не стат. значимо, а вот с третьим уже соотносится. Средняя оценка и упрощенный вариант тоже не показывают от слова «ничего. Тут мы решили посчитать согласованность разметки качества и получили ни много ни мало -0.09 по Криппендорфу.

Получается, что и оценка отборщика недостоверна, раз у нас три человека, несмотря на критерии, судят о качестве перевода каждый по своим вайбам. Занимательно, что у БЯМ вайбы совпадают с одним из людей. Еще весьма вероятно, что достоверность теста с улучшением качества тоже получилась так себе по той же причине. В общем, нужно искать более надежный способ установления качества переводов. Будем думать.

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

Зачем это вообще и что за датасет такой

Эмпатия играет важную роль в коммуникации между людьми, и в частности, в сервисах психологической помощи. В онлайн-среде, где такая помощь всё чаще оказывается в текстовом формате, появляется много различных сервисов, которые предоставляют психологическую помощь на основе чатботов. Для них способность отвечать эмпатично становится критически важным навыком. В противном случае хорошо если сеанс окажется просто бесполезным и не усугубит имеющиеся проблемы. Успех БЯМ побуждает разработчиков использовать их в качестве основы для таких чатботов. Для оценки их способностей разрабатываются различные бенчмарки, в частности для задач с уклоном в психотерапию. Одним из таких является PsyEval [2]. Однако для автоматической оценки эмпатии в текстах на русском языке размеченных датасетов просто нет. Мы, русскоязычные MLщики, не можем сказать, как сейчас БЯМ справляются с задачами, которые связаны с выявлением эмпатии и генерацией эмпатичных ответов. А ведь эти задачи напрямую влияют на качество инструментов псих-поддержки. Чтобы это хоть как-то исправить, мы приспособили большие языковые модели к переводу датасета с английского на русский язык. Целевым датасетом стал EPITOME, который состоит из текстов с Reddit и включает разметку по трем типам эмпатии:

• Эмоциональные реакции - выражение сопереживания (теплота, сострадание, поддержка) в ответ на сообщение собеседника
• Интерпретации - Показ понимания чувств и опыта собеседника.
• Исследования - Активный интерес к непроявленным переживаниям собеседника Каждый тип эмпатии имеет два уровня выраженности: слабый и сильный. Кроме самих типов датасет содержит аннотированные подстроки — носители эмпатии. Они указывают, какие именно части текста отражают эмпатичный отклик. Вот картинка из оригинальной статьи, которая наглядно показывает все эти виды.

Если кратко, всю работу можно разложить на несколько шагов:

1. Подобрать БЯМ, которая лучше всего справится с переводом.
2. Разработать затравку для перевода.
3. Реализовать полную процедуру перевода датасета.
4. Обучить модели для классификации эмпатии на русском языке, используя оригинальную модель.

Подбор БЯМ и разработка затравки

Для тестов мы выбрали несколько БЯМ: GPT-4o, Qwen-2.5 различных масштабов, Mistral-Small-24B-Instruct-2501, YandexGPT Pro. В довесок мы тестировали переводчик Yandex Translate, как промышленное и специализированное решение. Вместе с тестированием модели итеративно разрабатывалась затравка, в которую включались идеи из анализа ошибок модели. На начальном этапе мы сделали простую затравку для перевода, чтобы получить первичную оценку качества. Для тестового материала были отобраны вручную 20 текстов из датасета, содержащих типичные особенности языка Reddit: сленг, нестандартную пунктуацию, эмоциональные выражения, неформальные конструкции и аббревиатуры (например, “OP”, “DAE”, “yeet”, “tmblr”).

Переводы проверялись вручную перекрестно двумя разработчиками. Особое внимание обращалось на сохранение смысла и стиля. Для дополнительной проверки использовалась метрика L1-diff эмбеддингах LaBSE/en-ru, чтобы измерять семантическое расстояние между оригиналом и переводом. В общем случае метрику можно представить в виде формулы

\(L1= ∣f(t_{src}) - f(f_{trg})∣\) ,

где $f(x)$ - эмбеддер (в данном случае, модель LaBSE), $t_{eng}$ - текст на исходном языке (английском), $t_{trg}$ - текст на переведенном языке (русском). В итоге у нас получился вот такой топ-3 из моделей: GPT-4o, Qwen-2.5-72b-instruct и YandexGPT Pro.

Если обобщить анализ ошибок, то главное препятствие для хорошего перевода это стиль социальных сетей. Сокращения и аббревиатуры — естественные спутники соцсетей, потому что пользователи стремятся быстрее написать текст. Некоторые сокращения переносятся, как есть, типа VR, tmblr (название соц. сети) и, кажется, что это допустимо. Для некоторых сокращений трудно решить, стоит их переводить или нет, например, OP — ОП, автор темы. Есть такие, которые точно нужно раскрыть: rn (right now), asap (as soon as possible). Некоторые аббревиатуры пропускаются моделями (wtf, ish), а аббревиатура DAE (does anyone else) оказалось настолько сложной, что с ней справилась только gpt-4o. Еще тексты соцсетей пестрят междометиями от простых до супер вычурных. С их помощью люди часто пытаются имитировать разговорную речь (aaaaand, иииии). Они часто либо переносятся латиницей как есть, либо транслитерируются.

Также пользователи иногда украшают тексты своеобразным форматированием, из-за чего некоторые модели сбиваются с толку и теряют контекст. Конечно, игра слов тоже иногда моделями не улавливается: в предложении “i’m 24 old old man” некоторые модели просто пропускали второе слово “old”, вместо того, чтобы перевести предложение как «я 24 летний старик».

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

Другие особенности в двух словах:

• Некоторые модели ставят знаки препинания лучше, чем другие.
• Иногда модели исправляют явную логическую ошибку в тексте:
  • compare ur self to others because u will loose and forget who u r — не сравнивай с себя с другими, иначе ты проиграешь и забудешь, кто ты на самом деле.

Изначально мы рассчитывали, что для этой задачи мы сможем обойтись маленькой БЯМ, которой в нашем случае выступала Qwen2.5-7b. Результаты показали, что не обойдемся и вот почему:

• В переведенных текстах много латиницы.
• В сложных случаях, когда текст написан небрежно, модель начинает заниматься словотворчеством,
  • «Как ты? “Я Ф.И.Н.Е.”. Посорванная, неуверенная, нервная и эмоциональная.» (““How are you?” “I’m F.I.N.E.”. Fucked up, insecure, neurotic, and emotional.”)
• На длинных текстах может терять смысл.
  • «Мне 32 года, и у меня nunca была подружка. Очень грустно, что я давно стараюсь найти кого-то, даже используя Онлайн-датинг, но я чувствую, что останусь single вечно.»
• Модель часто использует не совсем те слова, которые следует (не “хочется умереть”, а “хочется погибнуть”), путает части речи и склонения слов.

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

• Требование сохранять оригинальный стиля сообщений, включая эмоциональные и суицидальные выражения.
• Инструкции по обходу фильтров моделей, препятствующих переводу текстов с суицидальной и депрессивной тематикой,
• Требование точно переносить смысловые акценты,
• Требование обязательно включать переведённых носителей эмпатии как подстрок в основном тексте. Еще мы протестировали модель в режиме перевода батчами — одновременного перевода нескольких текстов. Такой подход ставит выбор между скоростью и качеством, потому что чем больше текстов надо переводить, тем вероятнее, что БЯМ сделает что-то не так. Мы именно протестировали, как БЯМ будет работать в таком режиме, но итоговый датасет мы переводили по одному тексту. Ниже в таблице показаны результаты наших топ-3 моделей при переводе батчем в объеме 32 текстов. Видно, что если при обычном переводе у всех моделей все идет хорошо, то вот при переводе объяснений всё не так гладко.

Весь пайплайн целиком

Перевод датасета проходит в два этапа: общий перевод и перевод носителей эмпатии. Для двух этапов в качестве основной модели для перевода использовалась YandexGPT Pro, поскольку она демонстрировала лучшее соотношение по качеству и цене для большинства примеров. Для проблемных случаев, в которых YandexGPT допускала искажения или вкрапления иноязычных символов, применялась Qwen-2.5-72b-instruct. Если проблема сохранялась, то применялась GPT-4o. Такой ступенчатый процесс позволил достичь наилучшего баланса между стоимостью и качеством. На втором этапе специальный скрипт проверял, чтобы каждая переведенная подстрока носителя эмпатии входила в состав основного перевода без изменений. Если хотя бы один из фрагментов не удавалось точно сопоставить — текст переводился повторно с помощью другой более успешной модели.

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

• Тестирование перевода - 500 рублей (200 - YandexGPT Pro, 300 - Bothub (GPT-4o, qwen*))
• 1 800 seeker posts - 1 500 рублей Bothub (GPT-4o)
• Перевод 2 943 носителей, 1 284 seeker posts и 3 084 response posts - 3 000 рублей (YandexGPT Pro - 2 300 рублей, Bothub (GPT-4o, qwen-2.5-72b-instruct) - 700 рублей)

Обучение модели

Чтобы понять, что наш переведенный датасет вообще чего-то стоит, мы обучили оригинальную модель классификации и вычленения носителей эмпатии. В качестве базовых энкодеров мы протестировали rubert-base-cased и xlm-roberta-base. Качество замеряли также по набору оригинальных метрик:

• Accuracy — доля верных предсказаний,
• F1-score — гармоническое среднее точности и полноты,
• Token-level F1 (T-F1) — F1 на уровне токенов для задач извлечения,
• IOU (Intersection over Union) — мера перекрытия предсказанных и эталонных фрагментов

Результаты экспериментов показаны в таблице ниже. В строке «метрики авторов» указаны метрики из оригинальной статьи [3] для косвенного сравнения работоспособности модели. Видно, что порядок значений и распределение качества по подзадачам в целом совпадает, что говорит об адекватности переведенного датасета, а значит работоспособности описанного метода перевода. Интересно отметить, что rubert-base-cased стабильно превосходит xlm-roberta-base по большинству метрик.

Выводы и что дальше

Под конец давайте выпишем все проблемы, с которыми мы столкнулись и которые требуют дальнейше проработки:

• Многие модели по умолчанию отказываются работать с потенциально чувствительным контентом (суицидальные или депрессивные тексты). Иногда это можно обойти промт-инжинирингом, а иногда нет.
• Стиль общения в социальных сетях включает множество особенностей. Не каждая модель может понять и сохранить его при переводе.
• Культурная неоднозначность и субъективность аннотаций: проявления эмпатии в англоязычном и русскоязычном контекстах могут отличаться, а сами аннотации по уровням и подтипам эмпатии зависят от восприятия разметчиков, что влияет на интерпретируемость и обучение моделей. Кроме решения описанных проблем можно также предложить дополнительные направления:
• Расширение датасета за счет дополнительных источников, включая реальные диалоги с психотерапевтических платформ.
• Тонкая настройка и дообучение БЯМ на задачи генерации эмпатичных ответов в условиях диалога.
• Построение открытого бенчмарка для оценки способности БЯМ к распознаванию и генерации эмпатичных ответов на русском язык. Переведенный датасет можно взять здесь, пайплайн можно взять здесь. Канал нашей команды здесь.

До скорого.

[1] D. Popov, E. Terentev, D. Serenko, I. Sochenkov, and I. Buyanov, “Transferring natural language datasets between languages using large language models for modern decision support and Sci-Tech analytical systems,” Big Data and Cognitive Computing, vol. 9, no. 5, p. 116, Apr. 2025, doi: 10.3390/bdcc9050116.

[2] H. Jin, S. Chen, M. Wu, and K. Q. Zhu, “PsyEVAL: a comprehensive large language model evaluation benchmark for mental health,” arXiv (Cornell University), Jan. 2023, doi: 10.48550/arxiv.2311.09189.

[3] A. Sharma, A. S. Miner, D. C. Atkins, and T. Althoff, “A computational approach to understanding empathy expressed in Text-Based Mental Health support,” arXiv (Cornell University), Jan. 2020, doi: 10.48550/arxiv.2009.08441.

Как мы в Питере выступали

В конце мая наш руководитель ездил в Питер на конференцию CBTFORUM, которую проводит Ассоциация когнитивно-поведенческой терапии. Там он рассказывал про нашу платформу Китобой. Среди прочего, мы нашли коннект с руководительницей проекта «Открытые двери» и начали совместный пилотный проект.

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

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

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

Как мы переводили датасеты с помощью БЯМ

Есть много замечательных датасетов, которые решать разные психологические задачи. Правда, есть проблема. Все они на английском языке. И ладно было бы просто дорого их разметить, порой вы данные такие с трудом найдете. Вот было бы классно переводить такие датасеты с одного языка на другой, правда?

Кто-то скажет, а что мешает использовать условный Яндекс.Переводчик? Да в целом ничего. Как-то да переведут. Но что делать, если вам нужно обеспечить перевод какой-нибудь подстроки, как в датасете EPITOME, где кроме разметки на текст есть еще разметка отдельных частей текста, определяющих почему стоит тот или иной класс? Где гарантии, что простой переводчик сможет перевести подстроку так, чтобы ее можно было найти в исходном тексте? Тут на сцену выходят БЯМ. Они и перевести корректно смогут, и стиль сохранят, и управлять ими можно, и выбор богатый.

Как мы это делали, мы рассказывали на Дата Фесте, который прошел 31 мая. Скоро мы подготовим отдельный пост, кто не любит смотреть видосы.

С помощью этого пайплайна мы перевели несколько датасетов:

• psytechlab/epitome-reddit-ru - датасет с разметкой уровней эмпатии в тюрнах диалогов. С этого датасета все началось.
• psytechlab/EmpatheticIntents-ru - большой (когда-то) диалоговый датасет с разметкой чувств для клиента и стратегий для терапевта.
• psytechlab/ESConv-ru - тоже диалоговый датасет с разметкой стратегий для терапевта.
• psytechlab/cognitive_distortions_dataset_ru - датасет, в котором выделены предложения, содержащие когнитивные искажения, с которыми часто работают в парадигме КПТ.
• psytechlab/cognitive_distortions_gpt4_dataset_ru - тоже самое, что и предыдущее, только сгенерированное с помощью GPT4.

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

Продолжение следует.

The easiest way to build Triton is to use Docker.

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

В двух словах, чтобы уменьшить размер контейнера, нужно выпилить фичи, которые вам не нужны. По умолчанию, тритоновский образ вида tritonserve:xx.xx-py3 включает в себя всё: все бекэнды, среди которых Торч, Тензофлоу, Онникс, Питон, ТензорРТ и еще несколько, поддержку гпу, метрики и еще то, что я даже не знаю. Задумка в том, что Тритон разворачивается как один сервис, в который можно загружать множество внешних моделей под любой фреймворк. При таком сценарии нет проблем, что докер-образ весит полтора десятка гигабайт.

Но из тяжеловесов мы используем только ONNX и только на CPU. Почему только CPU? Потому что мы пока не ожидаем, что модели будут обрабатывать 100500 запросов в секунду. Если почуствуем, что нужно скорость увеличить, всегда можно включить GPU, хотя и до этого шага можно поколдовать над настройками онникса. Поэтому мы можем выкинуть, наверное, 90 процентов содержимого полного образа.

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

Инструкция

1. Скачать репозиторий сервера

2. Переключиться на ветку r24.05 - это едниственный релиз, который удалось собрать. Возможно, еще соберуться чуть свежее или чуть старее. Совсем новые, типа 25.01 или 25.03 (на момент написания 02.05.2025) по какой-то причине базовым контейнером выступает Убунта, а менеджер пакетов в Докерфайле почему-то yum, а не apt. Совсем старые релизы, как, например, 22.12, который был изначально, или некоторые из 23 года, которые мы тестили, не собираются из-за того, что не получается скачать крестовую библиотеку Boost. Ссылка больше неактуальна. (issue, еще [issue}(https://github.com/triton-inference-server/server/issues/7997) с проблемами сборки для разных релизов).

3. Применить нижепредставленный патч командой git apply fix.path. Этот патч отключает OpenVINO (несмотря на то, что его никто и не включал при команде сборки), потому что в процессе установки образуется конфликт версий для CMAKE. Вот коммент из issue, который объясняет как именно это происходит и пример решения проблемы через патч.

diff --git a/build.py b/build.py
index e0b66036..455ead8b 100755
--- a/build.py
+++ b/build.py
@@ -685,17 +685,17 @@ def onnxruntime_cmake_args(images, library_paths):
         ):
             cargs.append(
                 cmake_backend_enable(
-                    "onnxruntime", "TRITON_ENABLE_ONNXRUNTIME_OPENVINO", True
-                )
-            )
-            cargs.append(
-                cmake_backend_arg(
-                    "onnxruntime",
-                    "TRITON_BUILD_ONNXRUNTIME_OPENVINO_VERSION",
-                    None,
-                    TRITON_VERSION_MAP[FLAGS.version][3],
+                    "onnxruntime", "TRITON_ENABLE_ONNXRUNTIME_OPENVINO", False
                 )
             )
+            #cargs.append(
+            #    cmake_backend_arg(
+            #        "onnxruntime",
+            #        "TRITON_BUILD_ONNXRUNTIME_OPENVINO_VERSION",
+            #        None,
+            #        TRITON_VERSION_MAP[FLAGS.version][3],
+            #    )
+            #)
 
         if target_platform() == "igpu":
             cargs.append(

1. Выполнить команду:

   $ ./build.py --backend=python --backend=ensemble --backend=onnxruntime --backend=python --enable-logging --enable-stats --enable-metrics --enable-tracing --endpoint=http --enable-cpu-metrics
   

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

2. Выполнить команду:

   $ docker tag tritonserver:latest your/triton_name:your_tag
   

Казалось, это победа: образ собрался, сервер стартанул. Делаю запрос и мне в ответ:

{"error":"in ensemble 'ensemble_model', Failed to process the request(s) for model instance 'text_preprocessing_0_0', message: error: unpack_from requires a buffer of at least 387389211 bytes for unpacking 387389207 bytes at offset 4 (actual buffer size is 27)\n\nAt:\n  /opt/tritonserver/backends/python/triton_python_backend_utils.py(117): deserialize_bytes_tensor\n"}

Кавооо???

На этот раз, оказалось, что это из-за numpy. В контейнере оказывалась версия >2.0 и это за собой несет проблемы совместимости типов. Вот issue, в котором нашел что к чему. Поставил numpy=1.26.4, который вышел в феврале 2024 и он же последний релиз перед numpy==2.0, вышедший в июне 2024, и оно, наконец, полетело.

Новые образы с моделями теперь весят не безумные 16 гигов, в всего два (выкинули 87.5%). Причем половина последнего - это файлы модели. Думаю, что можно урезать еще в полтора раза, но и такой итог нас устраивает. Мы уже впилили его в tritoned-bert, скоро обновим на Гитхабе. Отдельно образ лежит здесь: astromis/tritonserver:24.05-onnx-python-cpu (если ссылка или докер недоступен, значит попробуйте сначала заменить astromis на psytechlab).

Обратите внимание на ссылки issue, благодаря которым мне удалось решить возникающие проблемы. В такие моменты чувствуешь силу сообщества и опенсорса.

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

Хорошо, вот наш пользователь нашел человека на грани, дальше что? Пустить в ход разное психотерапевтическое дзюдо, чтобы отвадить его от смертоносной затеи. А если наблюдаемый уже шагает за перила, как его остановить? Звонить в полицию, друзьям, в школу, работу и так далее. Это единственный способ.

Но есть нюанс — вы должны знать, кому и куда звонить и о ком сообщать. Беда в том, что люди не часто подписываются хотя бы своим настоящим именем, что говорить об адресе или месте работы-учеёбы? Но надежда есть: иногда наблюдаемые в постах выкладывают информацию, по которой их можно идентифицировать, вплоть до телефона или банковской карты. «Банковской карты?» — спросите вы. Да всё просто: иногда у людей настолько все плохо, что просят скинуть деньги на поесть.

Чтобы не шерстить все 100500 постов в поисках персональной информации, мы разработали небольшой сервис kitoboy-pie (personal information extraction). Суть его работы предельно проста: на вход подаете текст, на выход получаете метки с типом персональной информации, которая содержится в тексте. В базовом исполнении сервис поставляется с моделью NER от slovnet, которая по сравнению с другими известными решениями неплохо справляется с базовым набором именованных сущностей (персоны, локации, организации). Однако нужно помнить, что модель в первую очередь предназначена для новостного домена. Оценку того, как она работает на наших данных, мы проводим прямо сейчас.

Другой базовый компонент нашего «пирога» — детектор сущностей на основе регулярных выражений. Он прекрасно подойдет для сущностей, вариативность которых невелика. Это как раз мобильные телефоны, банковские карты, электронные почты ещё. Управляется компонент конфигом, в который в виде словаря прописываются регулярки и соответствующие им сущности.

Если вы хотите реализовать что-то своё, то вам надо просто упаковать это в наследника класса AbstractIE и реализовать метод make_prediction, который на выход должен отдать список классов.

class AbstractIE(InterfaceInformationExtractor):
    def predict(self, texts: str|list[str]):
        if isinstance(texts, str):
            texts = [texts]
        preds = []
        for t in texts:
            entites = self.make_prediction(t)
            entites.sort()
            preds.append(";".join(entites))
        return preds
    
    def make_prediction(self, text: str) -> list[str]:
        pass

Не забудьте только потом инициализировать класс в главном файле.

Чтобы обеспечить единообразие сервисов, мы сделали его похожим на Тритон. Правда, реализовывать всё, как в тритоне, конечно, мы не стали. Лишь необходимый минимум, который позволит встроить этот сервис на равне с реальными тритон-сервисами.

Мы выложим еще чуть позже, напишем об этом в тг.

Картиночки с платформой

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

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

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

Еще в копилку детективности нашей платформы. Аккаунт в социальной сети принадлежит какому-то человеку, но у одного человека может быть несколько аккаунтов в разных социальных сетях. Да даже в одной соцсети может быть сколько угодно, вообще говоря. Часто бывает связка из реального и «фейкового» аккаунта. Поэтому у нас аккаунт в социальной сети — аватары, как мы их называем — и реальная персона отделены друг от друга. При этом у одной персоны может быть несколько аватаров.

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

А вот так выглядит окно с постами аватара:

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

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

Нравится? Нам очень. Не забудьте поставить звезду нашей репе, чтобы нас поддержать.

Доклад на Moscow Python

23 апреля мы выступали на Moscow Python, где рассказали про то, как собирали наш датасет. Смотреть можно на Ютубе и Рутубе.

К сожалению, презентация сшакалилась. Скачать ее можно по этой ссылке.

До скорого.

• ядро написано на плюсах, а пользоваться можно на питоне;
• всеядный — переварит модели на Torch, ONNX, OpenVINO, TensorFlow, Scikit-learn, vLLM и просто питоновские скрипты.
• поддерживает инференс нескольких моделей одновременно;
• может объединять модели в последовательности (ансамбли);
• API-интерфейс по HTTP и gRPC;
• всякие фичи для ускорения инференса, типа динамического батчинга.

Далее мы расскажем необходимый минимум о Тритоне и как мы его используем в нашем проекте, детально вы прочитать про него в официальном руководстве на Гитхабе, которое вас проведет через полный цикл создания сервиса. Ссылка на репу с нашим проектом: tritoned_bert.

Минимальная конфигурация сервиса

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

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

platform: "tensorrt_plan"
max_batch_size: 8
input [
  {
    name: "input0"
    data_type: TYPE_FP32
    dims: [ 16 ]
  },
]
output [
  {
    name: "output0"
    data_type: TYPE_FP32
    dims: [ 16 ]
  }
]

То есть вам необходимо указать:

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

Как не трудно догадаться, ключи в конфигурации данных:

• name — имя конкретного входа/выхода. Именно оно будет фигурировать в API.
• data_type — тип данных, куда без него;
• dims — размерность входного/выходного вектора (тензора, в общем виде)

Кладете модель в папку model_repository/your_model_name/1. Всё, можете запускать:

$ docker run --gpus=all -it --shm-size=256m --rm -p8000:8000 -p8001:8001 -p8002:8002 -v $(pwd)/model_repository:/models nvcr.io/nvidia/tritonserver:22.12-py3 

Чтобы правильно выбрать базовый докер-образ для вашей GPU, если вы хотите ее использовать, смотрите вот это руководство.

Запуск питоновских скриптов на стороне Тритона

Модель-то мы развернули, только вот на вход она принимает тензоры и на выход отдает тоже тензоры. Если мы деплоим какой-нибудь Берт для классификации текстов, то нам сначала надо токенизировать текст, чтобы превратить его в векторы, а над логитами модели мы должны сделать хотя бы argmax, чтобы узнать итоговый класс. Чтобы не заставлять каждого клиента сервиса тащить на себе эту логику, можно сделать питоновскую «модель», которая это будет делать на стороне Тритона.

Чтобы провернуть такой фокус, вам нужно определить вот такой шаблонный класс

class TritonPythonModel:
    def initialize(self, args):
        ...
    def execute(self, requests):
        ...
    def finalize(self):
        ...

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

Вот пример реализации execute для нашей модели постпроцессинга предсказаний, где выполняется argmax и происходит маппинг индекса класса в его название.

def execute(self, requests):
    responses = []

    for request in requests:
        in_0 = pb_utils.get_input_tensor_by_name(
            request, "logits"
        ).as_numpy()

        predicts = in_0.argmax(axis=1)
        predicts = np.array([self.id2label[x] for x in predicts], dtype=object)
        out_tensor_0 = pb_utils.Tensor("predicts", predicts)

        inference_response = pb_utils.InferenceResponse(
            output_tensors=[out_tensor_0]
        )
        responses.append(inference_response)
    return responses

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

Ансамбли

Хорошо, есть у нас две «модели» на пре- и постпроцессинг и сама Бертовая модель. Как нам это заставить все работать вместе? Для этого в Тритоне есть ансамбли — эдакие метамодели, которые могут запускать обычные модели в определенном порядке.

Структура у них такая же: в папке с названием ансамбля должен быть файл config.pbtxt и пустая папка 1. Отличается содержание конфига. В нем, кроме описания входов и выходов, надо описать последовательность запуска моделей ensemble_scheduling. Обязательно также указывать маппинг названий входов и выходов, даже если они совпадают.

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

Наш шаблон тритоновских сервисов

Мы хотим, чтобы в нашу систему было супер-просто интегрировать сторонние модели. Чтобы это сделать, мы разработали шаблон, который позволит вам превратить вашу бертовую модель для классификации в тритоновский сервис. Всё, что вам нужно, это сохраненная модель в формате Hugging Face, наш репозиторий и пара зависимостей. Репозиторий мы открыли, можете пробовать. Помните, что он еще в разработке, поэтому могут быть оказии. Если что, создавайте карточку или пишите напрямую @Astromis в тг.

Пользоваться шаблоном просто: вам нужно запустить скрипт ./make_triton_image.sh, передав ему следующие параметры:

• путь до модели в формате Hugging Face;
• путь до токенизатора;
• путь до словаря, в котором ключами являются индексы классов, а значениями — названия классов.

Кроме того, есть опциональные параметры:

• model_name — имя модели. Если не передать, то будет ensemble model. Также будет называть контейнер.
• container_tag — на самом деде, конечно, тег докер-образа. По умолчанию, latest.
• max_batch_size — максимальный размет батча, который будет обрабатывать сервер.

Далее с помощью магии bash, шаблоны превратятся в конкретные настройки, ваша модель преобразуется в ONNX и всё это зашьётся в докер-образ Тритона с названием tritoned_[model_name]:[container_tag]. Важно сказать, что пока базовый докер-образ не изменяется, потому что шаблон построен так, что сервис будет работать на CPU. Мы добавим возможность выбирать режим, как и базовый контейнер, позже.

Запускать контейнер можно так:

$ docker run --shm-size=256m -p8000:8000 -p8001:8001 -p8002:8002  tritoned_[model_name]:[container_tag]

Протестить можно так:

$ curl -X POST http://127.0.0.1:8000/v2/models/ensemble_model/infer -d '{"inputs":[{"name":"text_input","shape":[1,1],"datatype":"BYTES","data":["тестовый тест"]}]}'

Кто такой этот ваш ONNX?

Что это вообще такое? Это Open Neural Network Exchange — открытый стандарт, для представления архитектуры нейросетей. Его поддерживают, наверное, все фреймворки для нейросеток, которые вам могут прийти в голову. «Поддерживают» значит, что фреймворки могут экспортировать объект сетки в этот формат. С тем же успехом, ее можно импортировать в эти фреймворки. Если представить ситуацию, что вам в руки попала какая-то onnx-модель, то вы сможете посмотреть ее структуру с помощью netron, закодить ее на любом фреймворке, поддерживающем ONNX, и использовать ее.

Кроме переносимости у ONNX есть еще одна фишка — собственная среда выполнения onnxruntime, которая позволяет даже на обычном CPU инференсить модели с большей скоростью, в сравнении с исходными фреймворками. А ведь можно еще задействовать аппаратные возможности. На Хабре есть пост, где можно наглядно посмотреть сравнение скоростей. В добавок, инструменты ONNX позволяют просто и быстро квантизировать модель, если готовы пожертвовать качеством ради скорости.

Может быть, вы думаете, что экспорт в ONNX сложный? Буквально одна строчка, что в tansfromers (точнее optimum):

ort_model = ORTModelForSequenceClassification.from_pretrained(model_path, export=True) 

что в torch:

torch.onnx.export(model, ...)

Эту строчку мы и используем для конвертации в нашей утилите utils/convert_to_onnx.py.

Кстати говоря, утилита поймет не только локальный путь, но адрес в Hugging Face Hub и Clearml. Если хотите, то легко сможете добавить другое хранилище, например, WandB, Artifactory, MLFlow и т.д. Модель и токенизатор нужно прописывать отдельно. С одной стороны, неудобно, но зато токенизатор и модель могут лежать в разных местах. Это актуально, когда вы много файнтюните одну базовую модель. В таком случае каждый раз сохранять токенизатор избыточно, достаточно просто указывать токенизатор базовой модели. Пример команды для конвертации:

$ python utils/convert_to_onnx.py -m models/best_model -t "deeppavlov/RuBert" --where_model local --where_tokenizer hf

На этом всё, на связи.

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

Пересборку классов мы делали по такой схеме:

1. Семплируем из каждого класса несколько десятков примеров.
2. Два «стейкхолдера» задачи размечают основной посыл текста (ака что хотел сказать автор).
3. Размеченные посылы сводятся к закрытым спискам.
4. Списки от разных «стейкхолдеров» объединяются.
5. Отдельные посылы группируются в новые классы.

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

По результатам такой работы у нас появился класс выражения любви. В него попадают тексты, в которых люди пишут о симпатии, восхищение или, собственно, любви к другим людям и животным. В исходном описании этого очевидного класса не было. Мы по умолчанию относили его в класс «наличие позитивных социальных связей». Тут мы плавно переходим к другой проблеме старой версии: время описания. Должен ли текст «У меня был парень, которого я любила до беспамятства» относится к классу, название которого начинается со слова «наличие»? Вот и разметчики отвечали на этот вопрос по-разному. Теперь у нас всё, что про любовь — что в прошлом, что в настоящем — в класс про любовь, а класс про социальные связи акцентирует внимание на слове «позитивные» тоже безотносительно времени. Проблема с временем была и в других классах, которую нам тоже удалось решить.

Поскольку основной бюджет на разметку мы истратили, мы не могли уже позволить себе размечать с тройным перекрытием. Чтобы быть уверенным, что качество остается на уровне, мы через несколько сотен примеров проверяем каждого разметчика и тут же даём обратную связь. Это, конечно, добавляет нам операционки, зато мы сразу получаем верификационный набор. Процесс еще идет, но мы уже попробовали обучить модель на том, что имеем сейчас. Отрезав совсем маленькие классы, мы получили качество по f1_macro 0.71 на 30 процентах от того, что было размечено. Это победа. Нам как минимум нужно держать качество на таком же уровне.

Пресуицидальные данные уже так просто не переразметишь — их 40 тысяч. Если взглянуть на матрицу ошибок, то можно увидеть, что есть хорошие классы, есть плохие. В глаза бросается левая полоска, которой быть не должно. Это у нас нерелевантный класс так или иначе путается со всеми другими.

После анализа неправильно предсказанных примеров мы отметили следующие проблемы:

• Нарушается правило третьего лица — если в тексте что-то плохое говорится не об авторе, то такие тексты мы записываем в нерелевантные, например “он сказал мне, что мечтает о скорой смерти”.
• Есть сложные примеры, для которых нужно “сделать логический шаг”, чтобы отнести их к соответствующему классу, а Берты так не умеют. Пример: “меня обнаружила девушка, лежащего в ванной с ножом в руках”.
• Тексты, попадающие под несколько классов — изначально мы схлопывали несколько классов в один по приоритету важности. Не ожидали, что будет работать хорошо, так оно и вышло.
• Некоторые примеры в тесте лексически просто не покрываются тренировочными данными, в итоге модель даже не знает, что так может быть.
• Ошибки в разметке, само собой.

Главный вопрос: а как проблемные данные-то отобрать? Опыт подсказывает один гениальный метод — картографирование датасетов. Методика позволяет вам распределить примеры на те, что хорошо усваиваются моделью конкретно вашей моделью, и на те, что не очень. Часто, примеры из второй группы как раз размечены криво. Вы хотите спросить, а причем тут карты? Потому что в результате у вас получается залипательный график, как внизу. Подробнее про метод и интерпретацию можно найти в этом посте на Хабре. А нас интересуют примеры, которые лежат в области “hard-to-learn”.

Всего у нас получилось отобрать около 10 тысяч примеров. А вот топ-5 классов, которые лежат в той области:

Нерелевантный                                                                                  	 1726
Антисуицидальный сигнал                                                                         	992
Чувства/душевное опустошение, подавленность, тоска, грусть                                      	860
Чувства/негативное самоощущение, вина, стыд, никчемность, самобичевание                         	763
Чувства/беспомощность, безвыходность, безнажежность, отчаяние                                   	710

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

Сейчас мы работаем над тем, как еще можно обогатить эту выборку, чтобы влезть в наш исхудалый бюджет, плюс еще анализируем мультиинтент-примеры. Мы заметили, что есть повторяющиеся «сценарии», которые вполне можно выделить в отдельный класс. Например, в антисуи очень часто можно встретить тексты типа “я хочу умереть, но мне жалко маму”. В этом тексте содержатся два класса: мысли о смерти и позитивные социальные взаимосвязи (позитивная она потому что автор переживает за чувство другого человека, а значит этот человека не безразличен).