Здравствуйте! Я ваш друг-журналист по финансовым и бизнес-новостям и экономист. Сегодня мы рассмотрим статью с публичного аккаунта WeChat «AIGC от 0 до 1». Хотя в заголовке используются такие сложные термины, как «теоретическая работа», «агент» и «вес», на самом деле она раскрывает довольно простую, даже контринтуитивно противоречащую истину о работе этой индустрии.
Чтобы вы легко поняли суть, я разделил эту длинную статью на «Краткое изложение сути» и «Подробное объяснение в пяти аспектах».
---
📝 Краткое изложение сути: понять новость за одну фразу
Основная идея:
Раньше считалось, что для улучшения работы ИИ-агентов нужно либо заменить их на более мощные модели, либо дополнить их лучшими инструментами и инструкциями для работы. Однако последняя научная работа WHALE доказала, что оба подхода нельзя использовать раздельно – для наилучших результатов их необходимо оптимизировать одновременно.
Но вот главное:
Хотя совместная оптимизация технологий идеальна, в реальных производственных условиях компаний нельзя позволять им развиваться без ограничений. Потому что если модель и инструменты слишком тесно связаны между собой, замена одного из них может стоить очень дорого (это называется «налогом на связность»).
Итог:
Способности системы могут развиваться одновременно, но процесс выполнения должен быть стандартизирован (интерфейсы должны быть унифицированы, версии системы – контролируемыми). Компании должны рассматривать ИИ как полноценный «программный продукт», а не как постоянно меняющийся экспериментальный объект.
---
🔍 Подробное объяснение в пяти аспектах: понимание реальности работы ИИ-агентов
1. Почему недостаточно лишь тренировать модель или улучшать инструменты? (Основная логика работы WHALE)
Простой пример:
Представьте себе, что модель – это только что окончивший университет студент, а инструменты для её работы – это набор инструментов и рабочие процедуры.
- Прежний подход:
- Либо тренировать только модель (микрорегулировки), не обращая внимания на качество инструментов. Результат: студент умный, но инструменты плохие, и он не может полностью раскрыть свой потенциал.
- Либо улучшать только инструменты (изменение инструкций, добавление функций поиска), не учитывая способности студента. Результат: инструменты идеальны, но студент не может справиться с задачами.
- Новое открытие WHALE:
- Если фиксировать инструменты и тренировать только модель, студент научится использовать эти неудобные инструменты, но не приобретёт настоящих навыков.
- Если фиксировать модель и улучшать только инструменты, инструменты будут адаптированы под особенности этой модели. При замене модели на более сильную новую старые инструменты могут стать препятствием.
- Правильный подход:
- Постоянная оптимизация: сначала тренировать модель, затем адаптировать инструменты под неё; затем снова тренировать модель и снова адаптировать инструменты. Этот подход улучшает точность на 4–24 процентных пункта по сравнению с отдельной оптимизацией каждой части.
Комментарий журналиста:
Это похоже на процесс ремонта дома: нельзя купить только лучший диван, не учитывая расположение розеток; также нельзя менять только розетки, не заботясь о комфорте дивана. Оба элемента должны работать вместе, но процесс их согласования должен быть динамичным.
2. Почему высокие результаты в лабораторных условиях могут привести к катастрофе на производстве? (Различия в целях)
Простой пример:
- В научной работе: главное – получить высокие результаты (например, дополнительные 5 баллов в тесте).
- В бизнесе: главные цели – получение прибыли, снижение затрат и предотвращение ошибок.
Конкретные различия:
В научных исследованиях для получения дополнительных 5 баллов может потребоваться лишь несколько дополнительных вычислений. Но в производственной среде эти 5 баллов могут означать:
- Рост затрат: необходимость использования большего количества серверов, увеличение времени обучения.
Увеличение рисков: новые комбинации могут привести к непредвиденным ошибкам, требующим ручной проверки.
Проблемы с обслуживанием: для достижения этих 5 баллов в код может быть добавлено множество дополнительных элементов; через полгода никто не осмелится их удалить из-за опасений, что это приведёт к сбоям.
Комментарий журналиста:
В научном мире ценится максимальная производительность, в бизнесе – стабильность и эффективность. Это объясняет, почему многие ИИ-модели, хорошо справляющиеся с тестами, не справляются с реальными бизнес-задачами. Ведь для компаний важен общий баланс затрат и выгод: прибыль = ценность – затраты на обучение – затраты на обслуживание – риски. Если для улучшения производительности приходится удваивать затраты на обслуживание, такая сделка не оправдана.
3. Что такое «налог на связность» и почему он дороже самой модели?
Простой пример:
Связность – это слишком тесная взаимосвязь между компонентами системы, делающая их нераздельными.
«Налог на связность» – это высокие затраты, связанные с попыткой разделить эти компоненты.
Пример:
Предположим, ваша ИИ-система состоит из модели A и инструментов B, которые идеально совместно работают. Если вы хотите обновить модель на более сильную модель C, выяснится, что многие функции инструментов B больше не работают с новой моделью. Вам придётся переписать инструменты или даже полностью переоптимизировать всю систему. Этот процесс сложен и подвержен ошибкам.
Ещё хуже так называемый «технический долг: со временем система заполняется дополнительными элементами для устранения ошибок:
- Нестабильность выводов модели? Добавляем дополнительные функции обработки.
- Сбои в работе этих функций? Добавляем механизмы повторных попыток.
- Чрезмерно длительные повторные попытки? Добавляем механизмы прекращения работы.
В итоге становится непонятно, какой код действительно полезен, и никто не осмелится его удалить. Это пример того, как «преимущество в производительности» превращается в «технический долг».
Комментарий журналиста:
Принципы MLOps (обслуживания машинного обучения) направлены на модульность и заменяемость компонентов системы, чтобы снизить затраты, связанные с такой связностью. Если каждый раз при обновлении модели приходится переписывать всю систему, она становится уязвимой.
4. Как будет выглядеть будущая ИИ-система? Инструменты для работы с ИИ разделятся на две категории
В статье предлагается интересная идея: инструменты для работы с ИИ не исчезнут, но разделятся на две категории.
Первая категория: когнитивные инструменты (будут устаревать/упрощаться):
- Что это такое: это дополнительные функции, написанные для компенсации недостатков модели (например, напоминания о необходимости завершения работы или повторного выполнения команд).
- Тенденция: по мере улучшения моделей (например, GPT-5, Claude 4) такие инструменты станут ненужными, так как модели сами смогут справляться со своими задачами.
- Пример: раньше модели часто забывали начало выполнения команд; инженеры добавляли функции для восстановления контекста. Сейчас, когда модели стали более сильными, такие функции могут мешать их работе.
Вторая категория: системные инструменты (станут ещё важнее):
- Что это такое: это инструменты, связанные с безопасностью, правами доступа и управлением состоянием системы.
- Например: имеет ли ИИ право на доступ к базе данных?
- Что он только что изменил в коде?
- Как восстановить работу системы в случае сбоя?
- Кто одобрил его действия?
- Тенденция: чем сильнее модели, тем больше задач они могут выполнять (например, напрямое управление производственными процессами, обработкой платежей), и тем важнее становится безопасность и управление их действиями.
Комментарий журналиста:
Раньше важно было, может ли ИИ правильно выполнять задачи; в будущем важно, можно ли ему доверять. Способности ИИ могут меняться, но права доступа и параметры его работы должны оставаться стабильными. Поэтому компании, такие как Anthropic, стараются разделять функции взаимодействия с ИИ, системы управления его работой и сами модели.
5. Практические советы для компаний: не стремитесь к бесконечному развитию, а к планомерному выпуску версий
Рекомендуемый подход: WHALE-lite (лёгкая совместная оптимизация)
Компании не должны пытаться заставлять ИИ-системы постоянно развиваться, как живые организмы. Вместо этого следует использовать процесс замораживания, проверки и выпуска версий:
1. Этап разработки (допускается связность):
- Оптимизируйте модель и инструменты вместе, быстро находите оптимальное сочетание.
- В это время можно свободно изменять инструкции для работы модели, менять инструменты, микрорегулировать модель.
2. Этап замораживания (пакетирование):
- Как только результаты удовлетворительны, заморозьте это сочетание в виде определённой версии (например, v1.0).
- Эта версия должна включать: параметры модели, код инструментов, инструкции для работы, правила доступа, среду для тестирования.
3. Этап выпуска (стандартизация):
- Разверните эту версию в производственной среде.
- Важно: на выходе должен быть не просто идентификатор модели, а полностью функциональный, воспроизводимый и проверяемый программный продукт.
4. Дальнейшие обновления (контролируемое развитие):
- Обновляйте систему только тогда, когда тесты показывают, что модель – барьер для дальнейшего улучшения производительности, или когда меняются бизнес-требования.
- После каждого обновления необходимо проводить тестирование на наличие новых ошибок.
Подход подходит для ситуаций с фиксированными задачами, высокой частотой выполнения и автоматической проверкой результатов (например, исправление кода, обслуживание систем, проверка правил).
**Не подходит для ситуаций с переменными задачами, зависящим