Обновить

1352 кейса внедрения ИИ в России: почему в продакшене побеждает не модель, а обвязка

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели4.8K
Всего голосов 2: ↑2 и ↓0+2
Комментарии21

Комментарии 21

1352 кейса внедрения ИИ в России: почему в продакшене побеждает не модель, а обвязка

Потому что внедряющие в большинстве своем не умели правильно дообучать модели!

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

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

После чего эти решения худо-бедно переиспользовались на похожих проектах.

Ситуация уже поменялась, но мало кто уже адаптировался к ней.

По поводу статистики, у меня 120 кейсов в 18 отраслях для B2B интеграторов (могу выслать временный доступ на закрытый портал автору в личку для подтверждения своих слов). Так вот, в 87% побеждала именно модель и ее SFT. Приходилось и чужие системы дорабатывать таким образом, чтобы увеличить точность.

Поэтому, по моему мнению, приведенная в статье статистика интересна сама по себе в историческом плане, но уже не отражает текущую реальность.

Теперь в ветке два измеренных вывода с противоположным знаком: 1352 кейса — побеждает обвязка, 120 кейсов @ToxaBes — в 87% модель с SFT. Подозреваю, оба правы, потому что статья сама содержит доказательства тезиса @ToxaBes точность у X5 с 79 до 92 поднялась на дообученных классификаторах, AGIMA дообучал детектор пять раз. Похоже, раскладка по типу задачи: узкие с измеримой точностью — выигрывает SFT и порог с человеком, открытые сценарии — семантический слой. Вопрос автору: можно ли фильтром каталога расщепить ту сотню рублёвых кейсов на эти два класса? Если расщепление подтвердится, спор рассосётся в классификацию.

Я думаю, тут нужно разделять статистику по кейсам с локальными моделями до 100B внутри контура предприятия и по решениям с облачными моделями либо большими локальными (больше 100-200B). Такое деление вызвано целесообразностью и возможностю дообучения модели.

Подозреваю, что выводы статьи полностью справедливы для решений с облачными и большими моделями, а мои наблюдения (и кейсы) лежат исключительно в on-prem решениях с моделями до 100B.

Деление по контуру напрашивается, но статья сама его осложняет: у Альфа-Банка локальная Qwen 35B стала предсказуемой не после дообучения, а после выноса детерминированной логики в сервисы на Go — обвязка в on-prem. VK Tech на локальном gpt-oss:20b нашли границу шести вызовов — тоже обвязка. А у VK дообученная Qwen3-VL-4B — маленькая модель, но SFT-история. Получается, малые локальные модели лежат по обе стороны. Ваше «возможность дообучения» кажется мне правильным механизмом, только работает он через другую ось — тип задачи: узкие с измеримой точностью выигрывают дообучением (дообучать можно только свою модель, поэтому у интеграторов on-prem это главный инструмент), открытые агентные сценарии — обвязкой. Вопрос по вашей выборке: много ли среди 120 кейсов открытых агентных задач — цепочки инструментов, RAG, свободный диалог? Если почти все узкие с целевой точностью, то ваши 87% и выводы статьи вообще не противоречат — просто режете одну карту по разным линиям.

узкие с измеримой точностью

Да, думаю вы правы.

Вопрос по вашей выборке: много ли среди 120 кейсов открытых агентных задач — цепочки инструментов, RAG, свободный диалог? 

Сложно сказать точно, но меньше половины, примерно 30-40%.

Спасибо, цифра полезная. Тогда любопытная арифметика: узких задач у вас 60-70%, а модель побеждала в 87% — получается, SFT выигрывал даже на части открытых агентных задач из ваших 30-40%? Если так, моя ось «тип задачи» неполная: похоже, своя модель в контуре расширяет зону дообучения на то, что в облачном мире лечится только обвязкой. Тогда ваши 87% и выводы статьи — два среза одной карты: интегратор с on-prem режет её там, где всё можно дообучить, облачный мир — там, где можно только обвязать. И был бы рад примеру: хоть один кейс из открытых, где дообучение решило то, что обычно лечат цепочкой инструментов и порогами?

своя модель в контуре расширяет зону дообучения на то, что в облачном мире лечится только обвязкой

Именно так! Я к этому собственно и пришел.

UPD:

И был бы рад примеру: хоть один кейс из открытых, где дообучение решило то, что обычно лечат цепочкой инструментов и порогами?

Из недавнего:

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

  2. Этой весной дообучал локальную модель тк Claude Opus отказывался признавать что PHP 8.5.4 вышел, у клиента была задача переписать на свежую версию с PHP 7.4.6 (вроде), опус постоянно скатывался на 7ю ветку даже если проверял сами и отвечал что "да вы правы, такая версия уже вышла". Дообучил на отличиях + деталях проекта (код и отобранные git коммиты), модель переписала проект (не маленький) за несколько дней с учетом внутренних бизнес-сущностей и абстракций системы.

  3. Заказчику понадобилась расшифровка созвонов и совещаний для HR-департамента, а руководитель HR-направления картавила так сильно, что мне приходилось напрягаться, чтобы разобрать слова. Универсальные модели вроде Whisper не справлялись, дообучил на ее размеченной речи + добавил аугментацию по похожем случаям, в том числе мужским и все получилось.

Примеры сильные. Похоже, правило такое: знания частые и проверяемые — в контекст, большие и приватные — в веса. Как измеряли точность в юридическом RAG — или человек на пороге остался?

Похоже, правило такое: знания частые и проверяемые — в контекст, большие и приватные — в веса.

Не совсем так, дообучение плохо усваивает отдельные факты, но хорошо переносит нужные.. привычки (иначе и не сказать). Суть не в запоминании конкретных номерров или дат, а принципов работы с ними.

Как измеряли точность в юридическом RAG — или человек на пороге остался?

Проверял стандартно, сначала precision/recall, затем вместе с юристом MRR и версионирование (чтобы старые нормы не подтягивал).

Посчитал по выгрузке, грубо, по ключевым словам. Из 221 кейса с суммой в рублях около 100 узкие задачи. антифрод, CV, предиктив, рекомендации. Открытых, где агенты, RAG и ассистенты, около 40. Если убрать “ожидаемый” и “по оценке”, остаётся 43 узких против 24 открытых, причём у открытых сумма чаще про весь портфель ИИ, а не про конкретный проект. Так что ваша ось подтверждается, спор скорее про классификацию.

Спасибо, что пошли в выгрузку. Итого: ~100 узких (SFT-территория), ~40 открытых (обвязка), а после отсева «ожидаемых» и «по оценке» — 43 к 24: у открытых цифры ещё и туманнее, чаще портфельные. Ваша выгрузка подтверждает ваш же пятый паттерн: честные деньги там, где метрика была до ИИ. Спор рассосался в классификацию, как и должно было.

Хочу понять, насколько можно доверять цифрам, на которых стоит статья. Из инструкции кейсов на платформе видно: публикуют вендоры из личного кабинета, дальше модерация — но про неё сказано только «будет комментарий с причиной». Про верификацию цифр эффекта — методика измерения, подтверждение заказчиком — не видно ничего, и анонимные заказчики («Крупный ритейлер») принимаются. При этом «подтверждённый рубль» — ключевая категория, по ней отобрано около сотни кейсов с деньгами. Что вкладывается в «подтверждённый»: проверка командой каталога или цифры берутся из самоотчёта вендора как есть?

Эм, я думаю вполне можно доверять, какой смысл обманывать? Статья хорошая, просто в статистике сразу все (небольшие и большие on-prem и облачные модели) поэтому перекос в одних наиболее частых (исторически) кейсах кроет все остальные.

Полайкал автору во всех местах жду еще статей, более подробных.

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

Автору большой респект за работу. Лайки, подписки, колокольчики.

Блин, а ведь вы правы (снова). Мы же видим верхушку айсберга и пытаемся мерять удава в попугаях.

Метафора прям из классики: удав, как известно, 38 попугаев и одно попугайское крылышко. В каталоге всё ровно так: у ЕвроХима свой попугай (эффект по цеху, внутренняя оценка), у ВТБ свой (9-кратное ускорение поиска при 12 тысячах пользователей), а у половины кейсов — то самое крылышко: «результаты в денежном выражении не раскрыты». И тогда вопрос с вашей стороны баррикад: заказчики у интеграторов вообще спрашивают, как посчитан эффект — методика, базис сравнения, до/после? Или все довольствуются цифрой со слайда? Сдаётся мне, что если даже покупатель не требует линейку, вендор её сам не заведёт — тогда попугаи с нами надолго.

Да, все цифры от авторов кейса, из их публикаций и из карточек, которые они заполняют. Своего аудита эффекта , и “подтверждённый” в статье значит “названа сумма и период”, не больше. Тут, вы правы, это витрина, и сравнивать сотню таких цифр между собой надо с оговоркой. Добавлю её в текст.

Спасибо за прямой ответ и за оговорку в тексте — редкость.

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

ККачество не контролируется каждую минуту, а пересчитывают. Похожие системы Цифра запускала на нефтепереработке (конкретных сроков и данных у меня нет).

Ну а самый показательный пример был на хабре про цементный завод https://habr.com/ru/post/596701/ тоже самое и точно без ИИ.

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

За последние пару лет CV и VLLM шагнуло сильно вперед: например, теперь я могу сделать автоматический контроль флотации для горно-обогатительной фабрики или решение для автоматического извлечения допусков и материалов из обычных 2D-чертежей с генерацией DFMEA матрицы в машиностроении и приборостроении или ИИ понимающий ректификацинную колонну в нефтепереработке и тд.

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

Решает прокладка между рулём и сидением экраном и клавиатурой

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации