Хабр Курсы для менеджеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
Я уже высказывался на страницах хабра, но таки, чего бы не повторить базу ещё раз.
Агенты, да и нейросети вообще, работают как весьма универсальные, но довольно нестабильные функции. У них есть вероятность отказа. Нейросети могут то, чего не могут классические алгоритмы. Это плюс. Их вывод имеет хаотическую природу - это минус. При этом проверить их работу класическими алгоритмами - нетривиальная задача.
Естественный способ уменьшить проблему нестабильности нейросети и существенно поднять надёжность - поставить вторую нейросеть надзирать за первой.
Логично. Вероятность неудачи равно вероятность того, что налажает исполнитель на вероятность того, что налажает проверяющий.
Пример. Конвееру нужно восемь картинок одного объекта отрисованного под разными углами. Проблема в том, что модель-художник иногда лажает и поворачивает объект неправильно. Решение - поставить модель понимающую изображение проверять работу художника. В случае недовольства - перегенерировать с другим зерном.
Такая схема двойной нейронки весьма универсальна. Накладывается практически на любую задачу, какую можно поручить сетке. Из раза в раз паттерн срабатывает, существенно повышая надёжность системы.
Естественный способ уменьшить проблему нестабильности нейросети и существенно поднять надёжность - поставить вторую нейросеть надзирать за первой.
Или воткнуть pydantic.
Там, где процесс проверки можно свести к классическим алгоритмам, логично выбрать классические алгоритмы. Это следует из формулы. У классики надёжность выше.
Там, где процесс проверки можно свести к классическим алгоритмам, логично выбрать классические алгоритмы. Это следует из формулы. У классики надёжность выше.
В этом я с вами полностью согласен, каждой задаче свой инструмент и не нужно пихать нейронные сети во все отверстия.
Мой комментарий относился сугубо к ситуации когда нейронная сеть необходима, например, в задаче распознавания документов/резюме без OCR, а точность которую она выдает недостаточна.
Спасибо за комментарий. Схема с проверяющей моделью действительно работает и по моей практике. Только желательно чтобы это были разные модели. Формула P(исполнитель) × P(контролёр) предполагает независимость отказов, а у моделей с общими обучающими данными, общим контекстом и общими слепыми зонами отказы коррелируют, плюс контроллер приносит собственный класс ошибок - ложные отклонения.
В статье есть ссылка на пример от компании Bayer - из системы PRINCE убрали проверку сгенерированного SQL второй моделью: она стала отклонять корректные запросы, замедляя контур и не дав соразмерного прироста точности (https://martinfowler.com/articles/reliable-llm-bayer.html ). Исследовательская база о том же: без внешней обратной связи модели редко исправляют собственные рассуждения (https://arxiv.org/abs/2310.01798 ), а у модели-судьи есть измеренные систематические смещения - позиционное, на длину ответа, в пользу собственных генераций (https://arxiv.org/abs/2306.05685).
Поделитесь в комментариях, если уже внедряли ИИ‑агентов в процессы организации — какие успехи, какие собрали «грабли». Интересно будет обменяться.
Добрый день, коллега, и охохо, у меня есть, что рассказать.
Прочитал статью и по моему мнению она написана немного оторвано от реальной жизни. Я не увидел рассуждений про окупаемость, то есть ROI, хотя для бизнеса это главная метрика.
Модель может быть трижды красивой и точной, но если её поддержка съедает всю экономию, проект просто бессмыслен. К тому же у нас любят делать автоматизацию в лоб. Берут кривой человеческий процесс с кучей ошибок оператора и тупо перекладывают его на нейросеть. В итоге получают не оптимизацию, а просто автоматизацию совершения ошибок (детальный пример описал в другом комментарии).
На конференциях и в отчетах всё красиво, но в реальности в российском ML до сих пор чистый Дикий Запад. Сильная экспертиза сосредоточена только у IT-гигантов, а B2B-интеграторы регулярно теряют проекты, потому что пытаются оценивать вероятностный ML привычными методами классической разработки.
С финансами тоже беда, т.к. понять, как купить экскаватор и потом обслуживать его, финдиректор может без проблем, а когда встает вопрос о покупке корпоративной системы знаний или RAG-решения, у менеджмента выбивает пробки, ведь непонятно, как амортизировать эти знания и закладывать в бюджет постоянное дообучение.
В итоге интеграторы до сих пор предлагают то, что создали 2,3,5 лет назад в виде коробочного продукта, либо нашли в интернете по устаревшей информации. А технологии не стоят на месте, сейчас полгода-год это уже “устаревшее” решение.
Например, до весны этого года связка Yolo с NMS считалась отраслем стандартом в CV задачах. Сегодня это уже фактически каменный век, потому что появились архитектуры вроде RF-DETR. Но сейлы интеграторов продолжают предлагать клиентам старые коробки.
При этом сам формат коробочных решений в ML также умер, но практически никто из продавцов этого не понял. Раньше можно было один раз написать ядро, а потом продавать его клиентам, меняя только интерфейс и настройки.
Сейчас представитель клиента сам может спросить у чат-бота про самые свежие технологии и прийти с конкретным запросом. Оттуда же клиенты знают, что модель нужно дообучать строго под свои данные и процессы. В итоге клиент говорит что ему не нужна коробка и переписывать приходится само ядро, из-за чего идея коробки теряет всякий смысл.
Даже в речевой аналитике и транскрибации, где готовые решения еще пытаются удержаться, новые модели выходят постоянно. Решение, собранное зимой, к следующей осени уже никому не нужно.
Для меня как субподрядчика, который делает white-label решения для B2B-интеграторов, это означает постоянную работу на опережение. Каждый проект приходится начинать с глубокого анализа того, что прямо сейчас происходит в конкретной нише заказчика.
Поэтому утро у меня начинается не с кофе, а с запуска собственной системы, которая собирает и анализирует свежие препринты с ArXiv. Только так можно вооружить сейлов интегратора актуальной информацией под задачу конкретного клиента. Но я не жалуюсь, я получаю удовольствие от процесса.
Спасибо за комментарий!
Я не пытался объять необъятное, тему окупаемости планировал раскрыть во второй статье триптиха " Особенности ИИ‑агентов в управлении проектной деятельностью. И когда в них вообще есть смысл."
Тем не менее, раздел про экономику в статье есть и тезис там сходен с вашим: считать нужно стоимость надежно завершенного сценария со всеми накладными. Но раз вы раздела не заметили, значит, подвела подача; в следующей статье вынесу окупаемость в явный подзаголовок, замечание принимаю.
А за утренний ритуал отдельный респект: у меня похожая история, только мой агент просеивает поток новостей агентизации, отделяя их от agent-washing, рекламы, перепевок чужих статей. Похоже, агент, который "следит за агентами", становится обязательным инструментом профессии )
тему окупаемости планировал раскрыть во второй статье триптиха
Прошу прощения, что побежал впереди паровоза, не знал что будет продолжение.
Тем не менее, раздел про экономику в статье есть и тезис там сходен с вашим: считать нужно стоимость надежно завершенного сценария со всеми накладными. Но раз вы раздела не заметили, значит, подвела подача;
Заметил, просто на мой взгляд это один из наиболее важных разделов и он был упомянут вскользь, поэтому я и написал комментарий. Прошу относиться к моему изначальному комментарию сугубо как к раскрытию этого раздела.
С удовольствием прочитаю продолжение вашего триптиха.
Хорошая статья! Несколько мыслей и пара вопросов
Верно пишете, что смена модели запускает повторную приёмку. Но если критерии живут внутри текущей сборки — в наборах испытаний под конкретный промпт и в голове эксперта — каждая повторная приёмка будет не проверкой, а новым определением работы. Отделять от исполнителя целесообразно требования к результату и границы допустимого.
Передача работы агенту меняет навыки в нескольких направлениях сразу: часть уходит из практики, часть меняет форму (подготовка результата → его проверка, что часто требует более глубокой экспертизы, а не меньшей), часть возникает заново, а часть нужно сохранять намеренно.
Последнее прямо задевает вашу архитектуру. Вы закладываете безопасную деградацию и ручной маршрут при отказе. Но ручной маршрут — это не строчка в регламенте, а сохранённая способность людей пройти его руками. Через год работы агента она исчезает и обнаружится это в момент отказа.
Смена модели или скиллов запускает у вас повторную приёмку. Тот же триггер должен запускать пересмотр распределения работы и требований к навыкам — иначе конфигурация новая, а подготовка проверяющего от предыдущей. В карте участников для этого не хватает роли: кто отвечает за то, чтобы человек в контуре был способен делать то, что вы на него оставили.
Несколько вопросов по результатам вашего внедрения.
Вы пишете, что конечное состояние здесь подвижное — полномочия и модели периодически пересматриваются. Формально проект закроют и откроют саппорт, но состав работ у этого саппорта необычный: не инциденты и доступность, а повторный пересмотр границы «человек/агент», повторная приёмка после смены модели и обновление требований к работе людей. Это тот же состав участников, что был в проекте. Интересно, во что это у вас оформилось организационно — кто собирает этот пересмотр и какая процедура, когда проект уже закрыт?
В вашей практике критерии приемки появились до внедрения или их вытащили из повторяющихся замечаний эксперта?
Сколько повторная приемка реально стоила при смене модели — сравнимо с предыдущим разом или на порядок дешевле?
Отличная статья!
Спасибо за стать, очень откликается.
Про фиктивный контроль я бы продлил еще дальше - агент забирает лёгкие кейсы, человеку остаются исключения, но пролемав том, что именно рутина была тренажёром насмотренности — через год проверяющий жмёт "одобрить" даже не из лени, а потому что физически перестал различать и в целом включать голову(
Как по мне, часть кейсов принудительно нужно оставлять человеку, чтобы компетенция не терялась.
А владельцев кажется три, потому что процесс может в какой-то момомент разойтись с реальность, потому что он изменился, а знание о нем осталось старое. Ну то есть процесс жив (отрабатывается), агент жив, мониторинг зелёный, а регламент на самом деле изменился, а агент безупречно исполняет устаревшую норму. Это не ловится к сожалению ни eval-набором, ни наблюдаемостью, потому что формально всё в порядке — и в этом главная разница с классическим внедрением на мой взгляд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проекты внедрения ИИ‑агентов. Есть ли отличия от «классических» проектов автоматизации и организационных изменений?