Ещё недавно вопрос звучал так: «как нам внедрить нейросети». Теперь он звучит иначе: «как нам выжить, когда нейросети есть у всех». Это разные вопросы. Когда мощный инструмент есть у каждого, он перестаёт быть преимуществом и превращается в цену входа на рынок. Ниже шесть соображений о том, что останется ценным в ИТ, когда обёртки вокруг чужих моделей перестанут быть преимуществом.
Что такое harness
Без этого термина дальше не обойтись.
Harness это вся обвязка вокруг языковой модели, которая превращает её из функции «текст на входе, текст на выходе» в систему, способную работать. Сама модель не умеет ни выполнять код, ни ходить в интернет, ни помнить, что было десять шагов назад, ни вовремя останавливаться. Всё это обеспечивает harness: подключает инструменты, организует цикл «действие, проверка, исправление», собирает вызовы модели в граф, подставляет промпты и правила, ограничивает радиус поражения, если агент сошёл с ума. Кодовый агент в IDE, который берёт тикет и правит проект, бот поддержки, который сам добирается до нужной записи в базе, «ИИ-сотрудник» на сайте банка: внутри почти всегда одна и та же чужая модель. Своей у типовой ИТ-компании бывает только harness. Некоторые строят целых агентов поверх чужих агентов, и получается «надагент», но механика та же: модель чужая, логика вокруг неё своя.
Гонка обёрток, у которой нет финиша
Свои языковые модели сегодня есть у нескольких бигтехов и горстки компаний, которым инвесторы разрешили сжечь миллиарды. Все остальные работают с чужими моделями по API и соревнуются качеством обёртки: у кого агент реже выдумывает, у кого аккуратнее длинные цепочки шагов, у кого граф из вызовов продуманнее, чьи скиллы и промпты лучше подобраны под задачу.
Выглядело это как нормальный бизнес, и какое-то время так и было. Но над той же задачей работают вендоры моделей. Помимо самих весов (моделей) они достраивают собственный harness: выпускают своих агентов, расширяют набор встроенных инструментов, перенимают удачные приёмы. Механика простая: если приём стабильно помогает большинству пользователей, вендор встраивает его в продукт. Хорошие промпты, схемы loop- и граф-инжиниринга, целые наборы скиллов. Всё то, что сегодня является вашей кастомной разработкой, через какое-то время становится строчкой в changelog чужого релиза. Вендору это стоит копейки по сравнению с обучением модели, а пользователям даёт ощутимое удобство.
История не новая. Платформы всегда забирали лучшие фичи слоя над собой: то, что вчера продавалось отдельным продуктом, завтра оказывалось бесплатной галочкой. Сейчас эта же машина приехала за агентскими обёртками. Конкурировать качеством harness можно, но это беговая дорожка, которая едет назад: бежать надо быстро, чтобы просто оставаться на месте, и каждый удачный шаг приближает ваш инструментарий к тому, что вендор и так даёт из коробки.
Ценность переезжает в код, который уже работает
Есть категория активов, которую генеративный ИИ воспроизводит с трудом: код, отлаженный годами, особенно если он не участвовал в обучении модели.
Сгенерированный с нуля код выглядит отлично ровно до первого редкого сценария. А вот код, который двадцать лет крутится в банках, больницах и телекоме, эти сценарии уже пережил. Его авторы знают про високосные годы, таймзоны, юникод в имени файла и банк, который присылает выписку в странной кодировке. ИИ-агент, пишущий модуль с нуля, проверит популярные пути и остановится. Изощрённые сценарии он либо не найдёт, точнее найдёт на продакшене за счёт заказчика.
Отсюда неожиданный поворот с легаси. Двадцать лет старый код считали долгом, который надо переписать на чём-нибудь модном. Теперь переписать с нуля означает выбросить накопленную память о тысячах исключений и получить красивый, но наивный код. Легаси превращается в актив: это не «старая система», это система, которой уже почти ничего не страшно. У компаний с длинной историей появляется преимущество, которое сложно скопировать.
У всех топовые модели, решают уникальные инструменты
Успех ИТ-компании раньше складывался из двух вещей: продавцов, которые выигрывают контракты, и инженеров, которые вытягивают проекты. Со второй половиной уравнения происходит интересное: топовая модель по подписке стоит как ужин в ресторане и есть у всех. Когда инструмент одинаковый, выигрывает не тот, у кого он есть, а тот, у кого к нему приложено что-то своё.
Раньше таким «своим» были фреймворки и платформы. Компании строили внутренние инструменты, потом делали вокруг них продукты (ну или наоборот), и конкурент без такого инструмента отставал по скорости.
Следующая итерация той же логики: дообученные нейросети. Не фронтирные гиганты, а небольшие модели, натренированные на своих данных под узкую задачу: разбор отраслевых спецификаций, классификация дефектов, извлечение полей из документов конкретного вида. На своей узкой задаче такая модель обходит generic, потому что видела сто тысяч примеров именно этого, а не «вообще всего». При этом generic-модель никуда не девается и закрывает всё остальное, а специализированная берёт на себя то, за что клиент готов платить.
Цепочка замыкается сама на себя: дообучение требует качественных данных, данные спрятаны в отлаженных системах и накопленной экспертизе, то есть снова в том, что нельзя сгенерировать промптом.
Некритичный софт обесценился, остаётся критичный
Игру, трекер привычек, приложение для учёта личных финансов и даже условный CRM сегодня собирает любой человек за вечер по одному промпту. Когда продукт делается за вечер, рынок перестаёт платить за него команде из двадцати человек. Конкуренция снижает цену некритичного софта до нуля, и это уже происходит.
Остаётся то, где цена ошибки измеряется жизнями и большими деньгами: медицина, авиация, космос, промышленная автоматика, платёжная инфраструктура. Туда нельзя прийти с одним промптом: сертификация, аудиты, регуляторы, ответственность, SLA. Там по-прежнему нужны компании, которые отвечают за результат деньгами и репутацией. Заодно именно там лучше всего монетизируются два предыдущих пункта: отлаженный годами код и узкоспециализированные модели с проверяемым качеством.
Конец большой открытости
Последнее изменение будет не техническим, а культурным. ИТ привыкло быть открытой отраслью: мы выкладываем код в открытые репозитории, рассказываем на конференциях, как построили систему на миллион пользователей, публикуем постмортемы и схемы архитектур. По сути раздаём ноу-хау и опыт бесплатно, из любви к ремеслу.
Но у этой традиции появилась цена: всё это идёт в обучение нейросетей. Приём из вашего доклада попадает в следующую версию модели, и через пару месяцев то, что было вашим преимуществом, умеет каждый. Отдавать знания, из которых тут же печатаются конкуренты, можно было, пока заказов хватало всем. При жёсткой конкуренции и сжимающихся бюджетах это станет роскошью.
Юристы жили иначе. Попробуйте найти в открытом доступе нормальный типовой договор купли-продажи доли в ООО: что-то, конечно, найдётся, но абсолютное большинство юрфирм свои шаблоны не публикует, а продаёт. Знание для них всегда было товаром, а не контентом. ИТ ждёт отчасти то же самое: меньше открытых репозиториев с рабочими решениями, больше демо без начинки, доклады про процессы вместо докладов про детали, датасеты и наработки под NDA. Возможно, вырастут закрытые сообщества, где знаниями обмениваются, но не публикуют.
Ирония в том, что именно открытость вырастила нынешний ИИ: он обучен на наших статьях, коде и докладах. Теперь он же делает открытость слишком дорогой, чтобы продолжать в том же духе.
Данные, которыми мы кормим вендоров
У открытости есть практическое продолжение, о котором редко говорят. Перестать публиковать знания в блогах и репозиториях мало, потому что большинство компаний уже давно отдаёт их по другому каналу: пропускает через API чужих моделей свой код, документы, переписку, данные клиентов. Каждая задача, которую агент решает на серверах вендора, оставляет маленький отчёт о том, как устроен ваш бизнес: что вы автоматизируете, какие документы обрабатываете, где болит у ваших заказчиков.
Официально эти данные не идут в обучение: вендоры обещают, в настройках есть галочка. Но обещание остаётся юридической конструкцией, а не законом физики. Условия пользования меняются в одностороннем порядке, галочки сбрасываются после редизайна настроек, а раз в пару лет в отрасли случается новость формата «мы случайно включили ваши логи в обучающую выборку» или «утекла база обращений в поддержку». К тому же вендор LLM не нейтральный арбитр: он сам выпускает агентов и приложения и в части сценариев конкурирует с теми, кто строит на его API. Отдавать ему данные о своих процессах и клиентах значит бесплатно раскрывать потенциальному конкуренту свои карты.
Логичный ответ: локальные модели. Открытые веса уже закрывают заметную долю задач, для которых пару лет назад требовался фронтирный API: классификация, извлечение полей, работа с документами, код в узком домене. Локальная модель обойдётся дороже по железу и уступит в сообразительности, зато данные не покидают периметр. Никакое изменение договора не превратит вашу экспертизу в чужую, и согласовывать запросы к серверу в чужой юрисдикции ни с кем не придётся.
И дообученные модели, о которых шла речь выше, требуют локального контура по определению. Если тренировать чужую модель своими данными через API, получается ровно то, чего мы пытаемся избежать: данные ушли, контроль остался у вендора.
Что в итоге
Если сжать всё сказанное в короткий список, выживание выглядит так: не строить бизнес на том, что вендор модели рано или поздно заберёт себе; беречь и покупать отлаженный код, а не переписывать его ради моды; собирать уникальные данные и дообучать на них узкие модели; не кормить чужие модели данными, от которых зависит бизнес, а самое чувствительное держать на локальных моделях; уходить туда, где цена ошибки высока и «собрал за промпт» не проходит; и наконец, меньше рассказывать о том, что реально работает.
Следующий раунд конкуренции будет не про то, у кого есть ИИ. Он будет про то, что у вас есть такого, чего нет в модели и обёртке над ней.
ссылка на оригинал статьи https://habr.com/ru/articles/1087002/