Transcription
Гонка ИИ, возможно, вступает в новую странную фазу. Годами все были одержимы самой моделью. Но теперь некоторые из крупнейших имен в области ИИ начинают фокусироваться на чем-то совершенно другом. Они называют это инжинирингом обвязки (harness engineering). Потому что, по-видимому, одна и та же модель ИИ может стать до шести раз эффективнее просто за счет изменения системы вокруг нее. Та же модель, та же сырая способность, совершенно другой результат. Так возникает вопрос: в чем реальная разница? Эта разница — обвязка. Проще всего понять это так. Модель — это двигатель интеллекта. Но обвязка — это все вокруг нее, что превращает этот интеллект в надежную работу. Она включает правила, инструменты, память, библиотеки навыков, системы проверки, управление контекстом, разрешения, пути отката, журналы аудита и циклы обратной связи, которые направляют модель перед тем, как она действует, во время действия и после того, как она дает ответ. Митчелл Хашимото, соучредитель Hashi Corp и создатель Terraform, помог вывести этот термин в мейнстрим в начале 2026 года. Его формулировка была очень прямой. Когда агент ИИ совершает ошибку, ответ не должен заключаться в том, чтобы просто повторно запустить тот же запрос и надеяться, что он сработает в следующий раз. Лучший ответ — изменить систему так, чтобы этот класс ошибок перестал возвращаться. Вот в чем настоящий сдвиг. Инжиниринг запросов (prompt engineering) в основном заключался в том, чтобы заставить модель сделать что-то правильно за одно взаимодействие. Инжиниринг обвязки — это создание среды, в которой модель продолжает делать правильные вещи с течением времени. Это разница между однократным исправлением ИИ и проектированием системы таким образом, чтобы одна и та же ошибка стала гораздо труднее повторяемой. И именно поэтому фраза так быстро распространилась. OpenAI, Anthropic, Langchain и другие части индустрии ИИ движутся в этом направлении, даже когда используют немного разные слова. OpenAI опубликовала свое собственное эссе по этой идее и описала, как это работает в больших рабочих процессах генерации кода. Согласно одной статье, OpenAI обработала примерно 1 миллион строк кода и около 1500 pull-запросов за 5 месяцев. Поскольку люди отходят от написания каждой строки вручную и переходят к формированию среды вокруг агента, Langchain сжал идею в простое сообщение, которое люди могли бы повторять. Сайт Мартина Фаулера дал ей более формальную инженерную рамку. Anthropic часто был более практичным, чем терминологическим, фокусируясь на фактических системах и уровнях безопасности, а не на самом ярлыке. И это важно, потому что инжиниринг обвязки — это не какая-то случайная новая модная фраза для старого промптинга. Промптинг, контекст и работа обвязки связаны, но это не одно и то же. Если вы меняете слова, которые модель читает напрямую, это работа промптинга. Если вы меняете информацию, которую получает модель, это работа контекста. Но если вы меняете невидимую структуру вокруг модели, такую как инструменты, которые она может вызывать, проверки, которые она должна пройти, память, которой она может доверять, разрешения, которые у нее есть, и процесс восстановления, когда что-то идет не так. Это работа обвязки. Сам по себе инструмент — это не обвязка. Сам по себе сервер MCP — это не обвязка. Сама по себе библиотека навыков — это не обвязка. Это компоненты. Обвязка — это собранная система, которая решает, как все эти части работают вместе. И вот здесь гонка ИИ начинает выглядеть совсем иначе. Совместное исследование Стэнфордского и Сингуаского университетов, как сообщается, обнаружило, что одна и та же модель с различными конструкциями обвязки может отличаться по производительности до шести раз. Модель осталась прежней. Окружающий каркас изменился. Это огромный результат, потому что он предполагает, что по мере того, как передовые модели становятся более доступными и более схожими по возможностям, преимущество переходит к команде, которая строит лучшую систему вокруг них. Это также помогает объяснить, почему внедрение ИИ в экономику все еще выглядит странно. С одной стороны, Goldman Sachs утверждал в апреле 2023 года, что генеративный ИИ может увеличить мировой ВВП на 7% или почти на 7 триллионов за десятилетие. Это огромное макроэкономическое заявление. Но к апрелю 2024 года Goldman заявил, что только 4% американских фирм фактически внедрили генеративный ИИ. Даже в сфере информационных услуг, где можно было бы ожидать более высокого уровня внедрения, эта цифра составляла всего 16%, при этом ожидалось 23% в течение шести месяцев. Таким образом, обещание огромно, но внедрение все еще неравномерно. Этот разрыв — это не только доступ к моделям. Множество компаний имеют доступ к мощным моделям. Теперь более серьезная проблема заключается в том, что у них еще нет системного уровня, который превращает возможности ИИ в повторяемую продуктивность. Модель может быть мощной, но без обвязки она остается хрупкой. Она может ответить на один вопрос, сгенерировать один файл, написать один фрагмент кода или резюмировать один документ, но она может испытывать трудности с надежной работой в реальном рабочем процессе с памятью, разрешениями, инструментами, сроками, крайними случаями и последствиями. Это особенно очевидно с агентным ИИ. Обычный чат-бот дает ответ. Агент должен работать в течение времени. Ему может потребоваться открыть терминал, искать файлы, читать документацию, писать код, тестировать результат, вызывать API, обновлять базу данных, запрашивать уточнение, хранить память, восстанавливаться после неудачной команды и решать, безопасно ли действие, прежде чем оно коснется рабочей среды. Как только модель ИИ встраивается в инструменты, браузеры, терминалы, репозитории, хранилища памяти и внешние сервисы, ее поведение больше не определяется только моделью. Оно определяется всей системой. Вот почему новая статья UC Berkeley утверждает, что для агентного ИИ масштабирование модели само по себе больше не является полной историей. Для обычных чат-ботов модель имеет наибольшее значение. Но как только ИИ становится агентом, как только он начинает использовать инструменты, открывать файлы, запускать команды, запоминать вещи и предпринимать действия, модель становится лишь частью машины. В статье говорится, что следующим основным узким местом является масштабирование системы или масштабирование обвязки. Реальному агенту требуется несколько работающих вместе уровней. Ему нужен сам LLM, который является движком рассуждений. Ему нужна память, чтобы он мог запоминать полезную информацию между задачами. Ему нужна система контекста, чтобы он знал, какую информацию предоставить модели, а какую исключить. Ему нужен маршрутизатор навыков, чтобы он мог выбирать правильный инструмент или рабочий процесс в нужное время. Ему нужен цикл оркестрации, который контролирует последовательность шагов. И ему нужна проверка и управление. Таким образом, агент не может просто совершать рискованные действия без проверок, разрешений, журналов или путей отката. Это звучит технически, но это уже происходит в серьезных системах ИИ. Clawed code, open claw и cheetah clause — это разные типы агентных систем, но все они сталкиваются с одной и той же основной проблемой. Как контролировать, что ИИ видит, запоминает, использует, проверяет и изменяет? И первая основная проблема — это контекст. Многие люди думают, что большее контекстное окно автоматически делает агента ИИ лучше, но статья UC Berkeley делает более резкое замечание. Трудность заключается не в том, чтобы дать модели больше токенов. Трудность заключается в том, чтобы дать ей правильные токены. Контекстное окно на миллион токенов не сильно поможет, если полезная деталь погребена под старыми журналами, устаревшими заметками, нерелевантными файлами и противоречивой информацией. Вот где возникает гниение контекста. Модель технически имеет информацию где-то в окне, но сигнал тонет в шуме. Вот почему реальные системы уже агрессивно борются с этим. Недавние анализы clawed code описывают пятиуровневую систему компактирования с такими вещами, как микро-компакт для очистки старых результатов инструментов и схлопывание контекста для резюмирования длинных разговоров. И когда инструмент производит массивный вывод, такой как гигантский журнал ошибок сервера, система не просто сбрасывает все в модель. Она может записать полный файл на локальный диск и сначала предоставить модели только 8-килобайтный предварительный просмотр. Таким образом, агент ведет себя больше как разработчик. Проверяет верхнюю часть журнала, понимает суть проблемы, а затем углубляется только при необходимости. Вторая проблема — память. Память звучит полезно, но плохая память может быть опасной. Агент может вспомнить старую заметку о том, как работает кодовая база, упустить тот факт, что код был рефакторингован вчера, а затем уверенно применить неправильное исправление. В статье это называется проблемой "устаревший, но уверенный". Память устарела, но агент относится к ней как к истине. Таким образом, серьезная обвязка относится к памяти с подозрением. Что-то вроде файла Memory MD должно действовать скорее как подсказка, чем как факт. Прежде чем агент будет редактировать файлы или предпринимать рискованные действия, он должен проверить рабочую среду и убедиться, что память по-прежнему верна. Некоторые системы даже очищают память в фоновом режиме во время простоя, устраняя противоречия, сжимая полезные уроки и не позволяя агенту медленно заполняться старой или беспорядочной информацией. Третья проблема — навыки. Предоставление агенту большего количества навыков звучит как очевидное улучшение, но это создает другую проблему. Выбор правильного. Агент должен знать, какой навык использовать, когда его использовать, как комбинировать его с другими навыками и как проверять результат. Специализированный инструмент может дать ответ, который выглядит уверенным и полезным, но при этом совершенно неправильным. Таким образом, реальная проблема не только в наличии навыков. Это маршрутизация и их проверка. Вот где инжиниринг обвязки становится практичным. Сильная обвязка не просто дает модели больше инструментов и надеется, что она будет вести себя должным образом. Она связывает эти инструменты с проверками. Была ли задача фактически завершена? Соответствовал ли вывод запросу? Была ли система безопасно изменена? Был ли результат инструмента проверен? Разрешено ли агенту вообще продолжать? И теперь исследователи идут еще дальше. Они спрашивают, могут ли агенты ИИ улучшать свои собственные обвязки на основе опыта. Вот где возникает ретроспективная оптимизация обвязки, или RHO. Новая статья Microsoft Research Asia и City University of Hong Kong представляет RHO как способ для агента улучшить свою обвязку, анализируя свою собственную прошлую работу. Вместо того, чтобы нуждаться в размеченном наборе валидации с правильными ответами, система изучает старые траектории, находит сложные и разнообразные задачи, повторно запускает их, сравнивает различные попытки, диагностирует, что пошло не так, и предлагает обновления обвязки. Ключевая часть заключается в том, что RHO не нуждается в истинных метках. Он использует собственные предпочтения агента в отношении различных попыток. Сначала он выбирает небольшую группу прошлых задач, которые являются одновременно сложными и разнообразными. В статье используется метод под названием DPP для балансировки этих двух вещей, потому что выбор только самых сложных задач может слишком узко сосредоточиться на одном типе сбоя, в то время как выбор только для разнообразия может упустить серьезные проблемы. Затем он запускает несколько попыток на каждой задаче и ищет два сигнала. Самопроверка проверяет, правильно ли агент завершил задачу, и выявляет такие вещи, как ложные предположения, неправильные вызовы инструментов и преждевременное завершение. Самосогласованность сравнивает различные попытки на одной и той же задаче и ищет серьезные разногласия в плане, используемых инструментах или окончательном ответе. Эти сигналы становятся инструкциями для улучшения обвязки. Затем RHO генерирует несколько кандидатских обвязок, тестирует их против старой, и сохраняет кандидата, который работает лучше, но только если оценка действительно положительная. Таким образом, это не случайное изменение агента. Он использует прошлые ошибки, чтобы решить, чему должна научиться система вокруг модели. И результаты — это то, что делает это трудно игнорировать. Используя codecs с GPT 5.5, RH улучшил S.WEB Pro с 0.59 до 0.78 без внешней оценки. Он также улучшил terminal bench 2 и Gaia 2. Таким образом, прирост проявился в задачах кодирования, технических работах и задачах, связанных со знаниями. Что делает это еще более интересным, так это то, что RHO не просто давал агенту больше памяти. Он менял фактическую систему вокруг него: инструменты, навыки, инструкции и проверки, которые формируют работу агента. После оптимизации агент чаще проверял свою работу, более осторожно использовал инструменты и лучше справлялся с длинными задачами, где обычные агенты обычно начинают разваливаться. Это указывает на более масштабный сдвиг. Будущие агенты могут улучшаться, учась на своей собственной истории работы. Каждая задача оставляет след. Каждая ошибка оставляет подсказку. И повторяющиеся ошибки могут стать обновлениями самой обвязки. Конечно, это также создает риск. Если ИИ может обновлять устойчивое поведение на основе своих собственных суждений, он также может усиливать плохие привычки или небезопасные сокращения. Поэтому серьезные системы по-прежнему нуждаются в журналах аудита, одобрении человека и проверках безопасности. И следующая фаза ИИ может быть выиграна тем, кто построит лучшую обвязку вокруг модели. Также, если вы хотите больше контента о науке, космосе и передовых технологиях, мы запустили отдельный канал для этого. Ссылки в описании. Загляните. Если вы считаете, что инжиниринг обвязки действительно является следующим большим преимуществом ИИ, оставьте свое мнение в комментариях. Нажмите "Подписаться", если это заставило вас по-другому взглянуть на агентов ИИ. Спасибо за просмотр, и увидимся в следующем выпуске.