Автор N3VERZzz разобрал, чем отличается разработка продуктов на классическом машинном обучении и больших языковых моделях. Его главный тезис: в первом случае команда улучшает конкретный показатель, например качество прогноза оттока клиентов, а во втором — берётся за часть работы сотрудника. Для руководителя это означает другую задачу: разобраться не только в модели, но и в том, как люди выполняют работу.
Разница не сводится к выбору технологии
В статье «ML и LLM: Разница с продуктовой точки зрения» от 7 ноября автор противопоставляет два подхода к разработке. ML — машинное обучение; в приведённых примерах оно решает узкую задачу: предсказывает вероятность ухода клиента или помогает определить цену товара. У команды есть конкретный показатель качества, который она стремится улучшить.
LLM — большая языковая модель, работающая с текстом. В проектах, которые рассматривает автор, её внедряют в деятельность сотрудника. Поэтому вопрос меняется: не только насколько хорош ответ модели, но и какую часть реального процесса ей можно поручить. Это взгляд автора на организацию разработки, а не результат сравнительного испытания технологий.
Рабочий процесс приходится собирать вместе с экспертами
По наблюдению N3VERZzz, рассчитывать на готовую инструкцию для модели не стоит: описания работы могут отсутствовать или устареть. Команде приходится восстанавливать процесс вместе с экспертом, а затем согласовывать его с руководителями. Часть решений эксперт вообще объясняет интуицией — перенести их в чёткие правила непросто.
Отсюда рекомендация автора: анализ работы бизнеса должен продолжаться весь проект, а не заканчиваться перед началом разработки. Каждая новая функция затрагивает ещё один участок работы, который нужно заново понять. Смежный вопрос — какие просчёты возникают уже при создании такого продукта — разобран в материале про пять ошибок при разработке продукта на языковой модели.
Начинать с отдельной задачи, а не со всего бизнеса
Для первой рабочей версии автор предлагает искать отдельные, хорошо описанные процессы, которые отнимают много времени и подходят для языковой модели. Попытку сразу охватить весь процесс он считает неудачной идеей: его части взаимосвязаны, а глубокое погружение в бизнес, по его оценке, может занять месяцы.
Это не обещание быстрого внедрения. Смысл рекомендации — сузить первоначальную задачу, не делая вид, что команда уже разобралась во всей системе. Конкретных сроков и стоимости такого запуска в статье нет.
Сэкономленное время ещё нужно правильно оценить
Автор отдельно разбирает трудность измерения пользы. Среднее время работы сотрудника не даёт полной картины: освободившиеся минуты не обязательно превращаются в дополнительный результат. Наблюдение за работой тоже охватывает лишь часть задач, а их сложность различается. В его примере документ о расторжении сделки может занимать три страницы или пятьдесят — прямое сравнение времени без учёта этой разницы вводит в заблуждение.
Приведённых измерений экономии или роста производительности в публикации нет. Её полезный вывод для заказчика — не принимать план функций за доказательство эффекта. В описанном автором подходе нужно оставлять место для постоянного уточнения задачи: что именно делает сотрудник, какую часть работы возьмёт модель и с чем сравнивают результат.
