Хотя ML и является старшим братом LLM, на поверку он всё-таки оказался двоюродным. В этой статье разбираем, чем отличается работа delivery-команд в ML- и LLM-проектах.
В классическом ML мы оптимизируем метрику
Например, предсказываем вероятность оттока клиента или определяем оптимальную цену товара.
У нас есть узкая задача и понятная метрика качества.
Когда мы делаем LLM-проект, то мы оптимизируем работу сотрудника.
В LLM-проекте нужно намногооо больше бизнес-анализа. Нам, по сути, нужно очень хорошо разбираться в бизнесе, который мы пытаемся оптимизировать. Ведь мы хотим сделать систему, которая превзойдёт существующую. Но это же не возможно – где-то срезать угол, если не знаем обычного пути.
1. Бизнес-анализ становится частью разработки, а не подготовительным этапом
Бизнес-анализ начинается и не заканчивается. Если у вас было представление, что вы приходите к бизнесу, он даёт вам инструкцию и вы засовываете её в промпт – забудьте. Инструкций нет, или они 2017 года, и т. д. и т. п.
В реальности приходится сидеть с экспертом и собирать бизнес-процесс частичку за частичкой. Как пазл «Ночной Нью-Йорк», только по памяти.
Конечно, один эксперт это субъективно. Далее мы должны ещё и согласовать всё, что нарисовали, с теми, кто повыше. Они же нередко возвращают на доработку, потому что Эмпайр-стейт-билдинг должен быть чуть выше и чуть правее.
Некоторые правила вообще не поддаются вербализации. Эксперт буквально говорит: «Здесь я полагаюсь на интуицию».
Сколько бы бизнес-аналитиков ни было на проекте, их можно занять на фуллтайм.
2. Подход к определению MVP
Чтобы разобраться в бизнесе и найти оптимальную точку применения LLM, нам потребуются месяцы.
Бизнес – это сложный организм, где процессы взаимосвязаны и сложились неслучайно (хоть и сложились зачастую плохо). Как тогда найти точку применения LLM, которая даст ощутимый результат без глубокого погружения во всю систему?
Прежде всего мы, конечно же, не пытаемся сразу оптимизировать весь процесс. Кумулятивная польза от полного покрытия – очень пагубная идея. Нужно оптимизировать разрозненные процессы, самые жирные по времени и наиболее подходящие для LLM.
Ищем атомарные, хорошо описанные и подходящие для оптимизации процессы.
3. Оценка эффектов
Оптимизируя метрику в ML, мы можем посчитать эффект A/B-тестом. С LLM сложнее. Мы можем посмотреть среднее время работы сотрудника. Но разве сам факт того, что мы и правда делаем полезную фичу, ускорит его работу? Сотрудник, например, может отдыхать то время, которое у него освободилось.
Хорошо, можем ли мы посмотреть не логи, а работу на экранах и зафиксировать, быстрее или медленнее происходит процесс? С наблюдателем сотрудник не будет бездельничать. Да, но сколько работы можно просмотреть таким образом?
Это всё равно срез данных: задачи одной категории могут иметь разную сложность. Документ по расторжению сделки может прийти на 3 листа, а может на 50. Что, если именно в этот день задачи были сложнее?
4. Прыжок в неизвестность
Эта специфика LLM-проектов требует другого подхода к управлению разработкой. Смешно, что все эти вопросы невозможно закрыть на этапе discovery, а от продактов уже требуют план выкатки фич, прогноз по эффектам и много чего ещё.
Поэтому продакту приходится делать этот прыжок веры. Верить в технологию, в то, что она подхватит и понесёт вперёд. Что LLM может всё, а дальше разберёмся.
Но LLM не может всё. И чем меньше мы разобрались в процессе, тем больше работы оставили на это загадочное «дальше».
Поэтому в план разработки придётся закладывать постоянное уточнение того, что мы вообще строим.
Бизнес-анализ здесь продолжается весь проект.
С каждой новой фичей мы берёмся за ещё один кусок работы сотрудника. Снова выясняем, как он устроен, что в нём можно улучшить и какую часть потянет LLM.
Я собираю знания в методологию, еще будет много полезного, чтобы не потеряться – подпишитесь здесь или на тг https://t.me/s/Gpt_budni
Автор: N3VERZzz
