Чому більше AI-агентів не завжди означають вищу продуктивність

icon MarsBit
Поділитися
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconКороткий зміст

expand icon
Альткоїни, за якими слід стежити, отримують увагу, оскільки розробники стикаються з прихованими витратами на управління AI-агентами. Зростання простоти розгортання змістило фокус на те, як люди можуть найкраще керувати виводами. «Податок на оркестрування» включає перевірку результатів та вирішення конфліктів — завдання, які не можна паралелізувати. Зі збільшенням кількості агентів зростають черги на перевірку, що призводить до виснаження та боргів. Зміни індексу страху ти жадоби можуть відображати ці узькі місця. Зростання продуктивності досягається не за рахунок більшої кількості агентів, а за рахунок робочих процесів, що відповідають обмеженням уваги людини.

Редакційна примітка: Коли AI-агенти стають все дешевшими і простішими у використанні, розробка програмного забезпечення входить у нову фазу: питання вже не в тому, чи можна запустити більше агентів, а в тому, чи мають люди достатньо уваги, щоб керувати, оцінювати та об’єднувати їхні результати.

Ця стаття пропонує дуже вражаючу концепцію — «оркеструвальний податок». Витрати на запуск агента низькі: достатньо одного запиту або одного кліку; але справжні витрати полягають у наступних етапах: перевірці правильності результатів, розумінні їх впливу на архітектуру системи, вирішенні конфліктів між різними агентами та, нарешті, визначенні, який код може бути доданий до головної гілки. Ці завдання не можна просто паралелізувати — вони все одно зводяться до одного послідовного ресурсу: людського судження.

Автор порівнює розробників з «GIL» у системі AI Agent — це однопотоковий блокувальний механізм, що обмежує кінцеву пропускну здатність паралельної системи. Кілька Agent можуть працювати одночасно, але щойно вони досягають етапів архітектурного аналізу, перевірки коду та об’єднання конфліктів, їм потрібно знову пройти через мозок розробника. Тому чим більше Agent, тим не обов’язково вищий вихід — можливо, це лише довша черга завдань на перевірку та більш часті переключення контексту та когнітивне виснаження розробника.

Це також один із моментів, які часто не враховуються в поточній хвилі інструментів AI для програмування: відчуття ефективності та реальна продуктивність — не завжди одне й те саме. Панель із заповненим екраном агентів створює ілюзію «високої продуктивності»; але якщо розробники не розуміють, не перевіряють і не інтегрують ці зміни, система в кінцевому підсумку може накопичити не продуктивність, а технічний борг і когнітивний борг.

Тому справжній предмет цієї статті — не «як використовувати більше агентів», а «як перепроектувати робочі процеси навколо уваги людини». У епоху агентів ключові навички — це не просто вміння ставити запитання та розподіляти завдання, а розуміння, які завдання можна передати машині для паралельної обробки, а які повинні залишитися за людським судженням; коли варто проводити пакетний огляд, а коли слід припинити оркестрування і знову зосередитися на одній ключовій проблемі.

Штучний інтелект розширює паралельну здатність виробництва програмного забезпечення, але увага людини залишається найбільш обмеженим і незамінним ресурсом системи. Справжньо дорослий робочий процес агента — це не викидання всіх завдань машині, а серйозне проектування архітектури власної уваги, як при проектуванні виробничої системи.

Нижче наведено оригінал:

Зараз запуск більшої кількості AI-агентів став набагато простішим. Але більше агентів, що працюють одночасно, не означає, що «ви» також збільшилися. Ваша когнітивна пропускна здатність не може бути паралелізована. Уся справжня здатність керувати ними, оцінювати результати та об’єднувати зміни все ще повинна пройти через один і той самий послідовний процесор — вас самих.

Так звана «податкова вартість» — це насправді ціна, яку ви платите, коли забуваєте про це. Єдиним справжнім рішенням є початок проектування вашої уваги так, як ви проектуєте будь-яку паралельну систему.

Раніше я брав участь у круглому столі на Google I/O, де обговорював сучасний стан програмної інженерії та її майбутнє розвиток разом із Річардом Серотером, Аджо Гаммерлі та Сієрою Джаспан. Коли ми майже закінчували, Річард запитав нас: що саме найважливіше, що розробники повинні винести з цього виступу й змінити?

Архітектура уваги

Я висловив те, що протягом кількох місяців неодноразово обдумував: відчуття, що ти дуже зайнятий, не означає, що ти справді щось досягнув. Ти можеш одночасно запускати 20 агентів і відчувати, що повністю зайнятий. Але це не означає, що ти виконав роботу, що відповідає 20 агентам.

На початку цієї розмови Річард дав цьому питанню назву. Він сказав: «Про що ви щойно говорили, це насправді організація податків. Ви не зможете успішно керувати 20 агентами у своїй голові».

Він абсолютно правий. Я хочу детальніше розібрати цю концепцію, бо це не проблема самодисципліни, а проблема архітектури.

У тій круглій таблиці було одне моє майже випадкове зауваження, яке потім не виходило з моєї голови: запуск кількох агентів не означає, що у світі з’явився ще один ти.

Асиметрія, яку люди не враховують

У робочому процесі агента існує прихована асиметрія.

Запуск агента дуже недорогий. Вам потрібно лише натиснути клавішу або написати один запит. Але завершення циклу агента коштує дуже дорого. Хтось завжди повинен перевірити, чи правильні результати, які він повертає, і знову синхронізувати їх із змінами, внесеними іншими агентами.

Ця людина — ти. І ти тільки один.

Минулого місяця я частково розглядав це питання у статті «Ваша межа паралельних агентів», зосереджуючись на так званій оточувальній тривозі: ви не знаєте, яка паралельна нитка тихо зазнає невдачі. Ця стаття присвячена структурі, що стоїть за цими витратами.

Коли ви починаєте сприймати розробку агента як паралельну систему, ви розумієте, що людина — це лише один із компонентів цієї системи. Дуже повільний послідовний компонент.

Ти той самий однопотоковий ресурс

Якщо ви коли-небудь писали паралельний код, ви вже маєте інтуїтивне розуміння цього питання. Просто раніше ви використовували цю інтуїцію не там.

У Python є глобальна блокувальна блокування інтерпретатора (GIL). Ви можете створювати будь-яку кількість потоків, але одночасно лише один потік може виконувати байт-код Python, оскільки всі вони повинні спочатку отримати цей замок.

Ти — твій GIL для AI-агенту.

Вони можуть працювати одночасно. Але щоразу, коли їх робота вимагає справжнього розуміння архітектури системи або вирішення конфліктів злиття, потрібно спочатку отримати цей замок. А цей замок єдиний і знаходиться у вашому розпорядженні.

Закон Амдаля дуже точно описує це: обмеження прискорення через паралелізацію залежить від частини роботи, яка все ще повинна виконуватися послідовно. Якщо у вашому процесі є велика частина, яку неможливо паралелізувати, то незалежно від кількості ядер, які ви вкладаєте, ви врешті-решт зустрінете жорсткий ліміт.

У розробці агента ця послідовна частина — це здатність до судження.

Запуск 8 агентів не прискорить ваш час прийняття рішень. Він лише збільшить чергу на обробку.

Це дуже давній факт у галузі інженерії продуктивності, але багато людей все ще здивовані ним: оптимізація неутилізованих частин не підвищує загальну пропускну здатність. Ви просто накопичуєте більше незавершених завдань перед узьким місцем.

Агент оптимізує ту частину, яка і так не була обмеженням. Справжнім обмеженням є етап огляду, а пропускна здатність всієї системи дорівнює саме пропускній здатності цього етапу.

Налагодження податків — це структурний розрив між продуктивністю агента та тим, що ви фактично можете об’єднати. Він виникає, коли ви залучаєте однопотоковий ресурс для керування паралельною системою.

Жорстке тримання не вирішує структурних обмежень

На тій круглій таблиці я сказав: я ніколи раніше не відчував, що мої інструменти такі ефективні, але я ніколи раніше не був так втомлений.

Обидва ці відчуття повністю справжні, і вони походять з однієї причини.

Ця втома має дуже конкретне походження: це відчуття постійного навантаження послідовного процесора на 100% без будь-якого запасу.

Кожен раз, коли ви звертаєте увагу на агента, що вийшов за межі вашої уваги, ви сплачуєте витрати на переключення контексту. Ви повинні очистити свій розум і знову завантажити інший контекст з нуля.

Це можна зробити за мікросекунди на процесорі, але архітектори все одно намагаються уникати частого переключення. А вам знадобиться кілька хвилин, і ви ніколи не зможете ідеально відновити контекст.

5 агентів — це не однакова робота, повторена 5 разів. Це п’ять запусків із нуля з перезавантаженням контексту плюс фоновий процес «мозку», який постійно стурбований тим, якого агента вам зараз слід перевірити.

Ви не можете вирішити структурне обмеження, працюючи важче. Цей податок завжди потрібно сплатити.

Якщо ви намагаєтесь триматися за своє, вона в кінцевому підсумку з’явиться іншим способом: або огляди коду стають все поверховішими, або ви потрапляєте у стан «когнітивної здачі» — бо формувати власні судження надто витратно за увагою, і ви просто приймаєте код, написаний агентом.

Або сплатіть цей податок добровільно, або дозвольте йому повільно знищити ваше розуміння своєї системи в темряві.

Дизайнуйте свою увагу, як систему дизайну

Тож ви повинні ставитися до своєї уваги як до обмеженого послідовного ресурсу.

Ви не створюєте розподілену систему, повністю ігноруючи обмеження. Тож надайте таку ж повагу своєму мозку.

Ось кілька методів, які справді працюють для мене:

Розширюйте команду агентів за здатністю до рев’ю, а не за здатністю до інтерфейсу.

Добре спроектована система з паралельним виконанням використовує механізм зворотного тиску, щоб уникнути нескінченного зростання черги. Виробник повинен зменшити швидкість, щоб відповідати здатності споживача до обробки.

Кількість ваших агентів — це виробники, а ваша здатність до перевірки — споживачі. Правильна кількість паралельних агентів — це кількість, яку ви можете серйозно перевірити. Для більшості людей це зазвичай дуже низьке однозначне число.

Звичайно, інструменти ШІ з радістю дозволять вам запустити 20 агентів, але це лише функція інтерфейсу, що не означає, що ви справді здатні ними керувати.

Класифікувати завдання.

Коли Річард запитав мене, як обробити цю справу, я згадав цей метод. Я розділю завдання на дві купи.

Перша група — це відносно незалежні завдання, які я готовий передати агенту, що працює в хмарному бекенді. Ці завдання можуть виконуватися асинхронно, і зазвичай мені потрібно лише один раз перевірити їх на останньому етапі.

Друга група — це складні завдання, де сама робота полягає у прийнятті рішень. Наприклад, дивний баг або проектування архітектури.

Найбільша помилка — це спроба паралелізувати завдання другого типу. Паралельна обробка кількох складних завдань не збільшить ваш вихід, а лише призведе до постійної боротьби за цей замок, в результаті чого всі результати стануть гіршими.

Пакетний огляд.

Кожен переключення контексту коштує вам дуже дорого. Сісти й одночасно перевірити результати 4 агентів набагато дешевше, ніж спочатку подивитися на один, зробити щось інше, а потім знову розпочинати перегляд іншого.

Дайте агенту довший повід. Дайте роботі трохи накопичитися, а потім обробляйте її пакетами.

Використовуйте цей замок лише для перевірки.

Не витрачайте свій розум на речі, які машина може перевірити самостійно. Нехай Agent пише тести, які пройдуть, або генерує скріншоти.

Дозвольте їм самим довести ті 80% нудних, але перевірюваних частин. Тоді вашої обмеженої уваги вистачить лише на 20%, які справді вимагають людського судження.

Захистіть свій серійний час.

Потік вимагає вашого найкращого часу, а не фрагментів часу, що залишилися між кількома перевірками агента.

Іноді найвищий leverage — це повна зупинка хореографії: вимкнути комп’ютер, наповнений агентами, і зосередитися лише на одному питанні, не відпускаючи цього замка протягом усього процесу.

Організація — це не справжня робота. Це лише накладні витрати, пов’язані з роботою.

Ажа зазначила, що архітектурні навички зараз стали найбільш терміновою компетенцією: вам потрібно знати, які завдання підходять для агента, а які для нього надто великі.

Я хочу додати ще один момент: ви також є компонентом цієї системи. Ваша увага має відому, дуже низьку послідовну пропускну здатність. Система або поважає це число, або обходить його, тихо знижуючи ваші стандарти.

Зайнятість не означає високу продуктивність

Це дуже важливо, оскільки цей тип невдач майже непомітний для вас самих.

20 запущених агентів надають відчуття «вибуху продуктивності». Панель повна, усе рухається. Але це відчуття вже не має нічого спільного з реальним об’єднанням якісного коду до основної гілки.

Ви можете бути надзвичайно зайняті, але майже не отримувати реальних результатів. З внутрішнього досвіду це майже однаково.

Ciera згадала дослідження Маргарет-Анн Сторі про борг. Ми обговорили технічний борг, а також когнітивний борг.

Без оплати організаційного податку ви одночасно накопичуєте ці дві заборгованості.

Ти об’єднав те, чого не читав уважно. Твоя розумова модель кодового бази повністю застаріла. Ці проблеми сьогодні не з’являться на панелі інструментів. Вони проявляться, коли виникне аварія у виробничому середовищі — тоді ти дивишся на систему і раптово усвідомлюєш, що вже не знаєш, як вона працює.

Отже, справжній висновок: запуск агента — це не здатність. Будь-хто може запустити 20.

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

Цей ресурс — це ваша увага.

Дизайнуйте його так, як будь-який критичний компонент, від якого залежить виробниче середовище.

Відмова від відповідальності: Інформація на цій сторінці може бути отримана від третіх осіб і не обов'язково відображає погляди або думки KuCoin. Цей контент надається лише для загального інформування, без будь-яких запевнень або гарантій, а також не може розглядатися як фінансова або інвестиційна порада. KuCoin не несе відповідальності за будь-які помилки або упущення, а також за будь-які результати, отримані в результаті використання цієї інформації. Інвестиції в цифрові активи можуть бути ризикованими. Будь ласка, ретельно оцініть ризики продукту та свою толерантність до ризику, виходячи з ваших власних фінансових обставин. Для отримання додаткової інформації, будь ласка, зверніться до наших Умов використання та Розкриття інформації про ризики.