Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
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:
И был бы рад примеру: хоть один кейс из открытых, где дообучение решило то, что обычно лечат цепочкой инструментов и порогами?
Из недавнего:
Дообучение модели в контекстуальном RAG для юридической фирмы. Перестала путать номера и даты, галлюцинировать и стала способна нормально сравнивать два документа.
Этой весной дообучал локальную модель тк Claude Opus отказывался признавать что PHP 8.5.4 вышел, у клиента была задача переписать на свежую версию с PHP 7.4.6 (вроде), опус постоянно скатывался на 7ю ветку даже если проверял сами и отвечал что "да вы правы, такая версия уже вышла". Дообучил на отличиях + деталях проекта (код и отобранные git коммиты), модель переписала проект (не маленький) за несколько дней с учетом внутренних бизнес-сущностей и абстракций системы.
Заказчику понадобилась расшифровка созвонов и совещаний для 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 года назад это было практически невозможно сделать, но новые архитектуры и методы обучения сдвинули планку.
Что значит не было технической возможности?
Для построения математической модели нужны данные, а не ИИ. Данные нужно собирать. То есть подключить датчики, контролировать качество по партиям и всё это в одной системе, чтобы можно было проследить выход партии. Дальше идет тестирование модели, когда она только предлагает изменение настраиваемых параметров, затем уже можно доверить и автоматические изменения в пределах техпроцесса.
Не совсем понимаю, что значит "ИИ понимающий ректификационную колонну".
Что значит не было технической возможности?
Модели и их архитектуры еще не были на необходимом уровне развития.
Для построения математической модели нужны данные, а не ИИ
Причем тут мат модели, если нужно распозновать, например, гранулярность руды которая движется по лотку, и в зависимости от размеров фракций регулировать расхол кислот для их обработки дальше по конвееру. Это решается не мат моделью, а пром камерой над лотком и обученным ИИ, который экономит предприятию сотни млн руб в год на снижении расходов реагентов и увеличении выхода полезного продукта.
Не совсем понимаю, что значит "ИИ понимающий ректификационную колонну".
У оператора есть схема колонны, которая отражает приборы контроля и регулирования температуры, давления и уровня жидкости. ИИ-агент понимает и структуру и данные с датчиков и помогает оператору в диалоговом режиме. На что обратить внимание, где какие отклонения, что делать при ЧП и тд.
Тут у вас уже путаница в терминологии. Гранулярность руды в режиме реального времени можно определять с помощью компьютерного зрения, но ИИ в виде LLM здесь как бы не лучший вариант, классический CV справится лучше. С с помощью LLM можно сделать обучающую размеченную выборку, если вручную возиться не хочется или нет времени, но и всё. А вот уже расход в зависимости от размера фракций у вас будет определяться по мат.модели.
Не классический CV в виде YOLO, а современный на RF-DETR, после чего результат пойдет не в мат модель, а в специализированную небольшую LLM для принятия решений. Т. е. это. ансамбль.
Мат модель тут не поможет, тк довольно быстро "задрочит" регуляторы подачи, те это пост-регуляризация, реактивный контроль. Модель же понимает характер изменений и применяет предиктивную регуляцию, оптимизируюя подачу и сохраняя ресурс.
Вы в теме мат моделей, но не в теме деталей производственного процесса. Было бы можно сделать чисто по мат модели давно бы уже сделали. Я сам не сторонник пихать ИИ туда где он не нужен.
Было бы можно сделать чисто по мат модели давно бы уже сделали.
Это не так:
1) На входе часто нет нужных данных, а их сбор это отдельные большие затраты.
2) Нет данных на выходе, а их сбор ещё большие затраты.
3) может не быть нормальной регуляции параметров. На одном производстве нужно было добавлять воды, единственная автоматизация была в том, что повесили лампочку и специальный человек открывал кран на трубе с водой, когда загоралась лампочка.
Тоже вот вопросы в обвязке, как и написал ТС.
Сбор данных не стоит ничего в масштабе стоимости разработки и экономии от внедрения. Большинство данных уже лежит в логах систем управления, они давно уже везде внедрены.
На одном производстве нужно было добавлять воды, единственная автоматизация была в том, что повесили лампочку и специальный человек открывал кран на трубе с водой, когда загоралась лампочка.
Эм, эту автоматизацию можно оптимизировать с помощью одной собаки. Товарищ Павлов не даст соврать.
Решает прокладка между рулём и сидением экраном и клавиатурой
Спасибо, интересная подборка.
В кейсах, которые вы приводите, работу модели оценивают по эталону или ограничивают порогом, и то и другое задано заранее. В X5 это порог уверенности, за которым подключается человек. В VK Видео качество контролирует Golden Set. В Яндексе результат оценивает вторая модель, а качество подтверждено совпадением с проверкой человека. В AGIMA ложные блокировки считали на фиксированном наборе из 179 безопасных текстов.
Это не компоненты стека, а принятое организацией определение того, какой результат годен, какой риск допустим и где решает человек. Обвязка его исполняет, но не создаёт.
Поэтому финальная рамка «чей семантический слой, чьи guardrails, чей MCP-хаб» является неполной. Механизмы вендор поставит. Их содержание в большинстве случаев нет. Ограничения, критерии, пороги и эталоны определяются конкретной работой конкретной компании. Вопрос к вендору «что стоит между моделью и данными» верный, но к нему нужен второй, к организации: есть ли у нее чем наполнить эту обвязку?
Полностью согласен с главным тезисом: в продакшене решает не модель, а обвязка. Мы пришли к тому же на генерации ответов для e-commerce: чистые LLM слишком легко дописывают правдоподобное, а голые регулярки тупы для живого языка. Рабочий вариант — гибрид: модель пишет черновик поверх жёсткого allow-list фактов, а детерминированный слой проверяет, что у каждой фразы есть опора. Если опоры нет — результат падает с ошибкой валидации, а не сглаживается общими словами. Самое ценное в такой обвязке — умение сказать «нет»: у нас это отдельный слой, который режет выдуманную статистику и промо-лексику до того, как текст уйдёт наружу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
1352 кейса внедрения ИИ в России: почему в продакшене побеждает не модель, а обвязка