Что я понял про работу над ИИ после нескольких продуктовых запусков

Привет, на связи Антон Проценко, я отвечаю за искусственный интеллект в команде Яндекс 360. Моя цель — делать наши сервисы полезными для миллионов пользователей с помощью нейросетей. Например, вместе с коллегами мы внедрили Нейрофильтр в Почту и Нейроредактор в Документы. Так я не только набил много шишек, но и протестировал множество способов, чтобы добиться от нейросетей желаемого результата (и если ИИ вдруг станет неуправляемым, то за мной он придёт первым). Зато теперь я могу поделиться опытом на случай, если вы тоже решите внедрить ИИ в свой продукт (а вы, конечно, решите). В этой статье я поделюсь советами и подкреплю их примерами из опыта работы над Телемостом, а уже 26-го июля на фестивале Product : Fest расскажу и о других кейсах.

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

Детальное ТЗ на результат работы нейросети — это и есть промт. И да, в реальной жизни я тоже пишу запрос [куда сходить суздаль завтра], и нейросеть меня понимает, но когда вы создаёте фичу, будьте готовы написать 30 строчек текста с детальной инструкцией, как жить.

Например, когда мы запускали суммаризацию (конспекты видеовстреч) встреч в Телемосте, в тексте промта встречалось такое:

— Избегай страдательного залога, вместо «было обсуждено» пиши «обсудили».
— Если понятно, кто совершил действие (договорился, обсудил, решил), указывай говорившего (например: «Владимир договорился, Таня предложила, по итогу договорились до такого-то результата»).
— Форматирование должно быть строго такое же, как в ожидаемом формате. Помимо ожидаемого формата в ответе не должно быть больше ничего: никаких пояснений и дополнений.

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

Казалось бы, встреча в Телемосте — это не «Война и мир». Но если вы активно пообщались полчаса, листов 15 наберётся. Вместить такой объём в нейросеть, конечно, можно, но качество суммаризации, особенно на недорогих моделях, будет посредственным — а в некоторые модели такой текст просто не залезет в контекст. ML-щик может предложить схему — как нарезать встречи, как склеивать суммаризации, — но на каждом из этих этапов будет теряться качество, а ещё для каждого из этих этапов нужна будет своя инструкция.

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

Умение правильно докинуть в модельку контекст — критически важно. Это отмечает, например, Андрей Карпатый, один из основоположников OpenAI, в своей недавней лекции для Y Combinator.

Оценка — самое важное. Точно так же, как вы не катите в продакшн фичу без тестирования (не катите же, да?), LLM-фичу нельзя катить без оценки.

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

Для отзывов с маркетплейсов это:

— отзывы разной длины;
— отзывы с матом и в стиле Пришвина;
— отзывы, которые авторы отзывов посчитали остроумными, но не относящиеся напрямую к товарам;
— с достоинствами на месте недостатков и наоборот.

100–200 примеров (в случае с суммаризацией отзывов — наборов отзывов), в зависимости от искомой точности, нужно будет иметь для постоянной разметки на точность. Советую не строить сложных шкал с десятибалльной системой оценивания, а придерживаться бинарной, максимум трёхбалльной оценки: «стыдно», «нормально», «отлично». Пока качество низкое, можно размечать и 30–50 ответов модели, но для большей точности требуется больше примеров для статистической значимости.

Размечать примеры вручную — трудоёмкий и долгий процесс. Классно, когда можно делегировать его готовым к нему людям, но даже если вы смогли обучить людей корректно проводить разметку — это всё равно потерянные часы, иногда дни ожидания, за которые нужно многократно платить. Секрет, который знает каждый тренер-LLM-щик: чтобы оценить работу LLM, можно нанять другую LLM. И если та, что покатится в продакшн на миллионы пользователей, должна быть достаточно дешёвой с точки зрения использования железа, оценивающей может выступать самая дорогая: на масштабе 200 запросов за итерацию это не будет иметь значения.

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

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

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

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

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

Часто на этом этапе получается уже отличная фича. Вы написали хороший промт, оттестировали, придумали систему, оценили её работу, при необходимости что-то дообучили — и в путь. Вокруг при этом ещё много развилок — вы можете использовать RAG, можете в своей цепочке получения ответа заменять какие-то кусочки на другие ML-решения (например, для одной из задач мы вовсе отказались от LLM уже после внедрения фичи, потому что смогли добиться схожего результата на более дешёвой нейросети, негенеративной), а можете, наоборот, усложнять схему и внедрять вызов функций.

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

Пишите в комментариях, с какими трудностями вы столкнулись, пока достигали этого самого «симбиоза» и строили свои ИИ-фичи. И до встречи на Product : Fest!