От проваленного пилота до идеальной системы — как мы научились работать с LLM проектами

LLM — одно из самых сложных и интересных направлений в Data Light. Я Виктория Янышева, занимаюсь LLM-проектами в компании.

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

Если вы работаете с LLM-проектами в своей компании, а особенно — если думаете этим заняться, обязательно прочитайте эту статью! Расскажу об ошибках и как их не повторить, и успехах и как их добиться.

Первый пилот провалился. Что пошло не так?

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

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

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

Как мы работали над первым пилотом?

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

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

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

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

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

А как прошел первый успешный проект?

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

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

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

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

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

Первый проект по разметке в LLM

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

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

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

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

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

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

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

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

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

По твоему опыту, в чем специфика LLM проектов?

В основном это субъективизм. Даже с точки зрения валидации, прав может быть и асессор, и валидатор, но как найти то, что является корректным ответом? Каждый кейс уникален, мы не можем составить ТЗ так, чтобы оно описывало каждый случай, который встречает разметчик. Конечно, мы даем какие-то якоря или направления, список антипримеров, разбираем корнер-кейсы и говорим, как здесь было бы правильнее поступить, но какой-то единой истины нет. 

Как правильно выстроить работу с асессорами на ML направлении? 3 главных совета от Виктории:

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

2. Асессорам мы всегда говорим, что наши звонки, разборы, обучения и тренажеры — лишь 50% успеха. Остальные 50% зависят только от них, от их желания разобраться, иначе у них ничего не получится. 

3. Самому также нужно смотреть на каждое правило и каждую строчку ТЗ с абсолютно разных сторон. То есть, если в обычных проектах всё достаточно очевидно, то здесь при применении любого правила нужно подумать о том, как оно может повлиять на все остальные, и смотреть на общую картину с точки зрения всего проекта, чтобы сохранить логику для ребят и не сломать самих разметчиков.