Два ШІ-агенти можуть редагувати один і той самий файл, обидва отримують підтвердження «success», проте виживає лише один із їхніх змін. У простому тесті з п'ятьма паралельними агентами чотири з п'яти записів зникли без жодної помилки чи запису в логах — це класична аномалія втраченого оновлення (lost-update anomaly), яка марнує токени, сплачені за зниклу роботу.
Чому це важливо
Коли ШІ-агент записує результат, базовий сервіс стягує плату за кожен згенерований токен. Якщо запис буде тихо перезаписано, провайдер все одно виставить рахунок за обчислення, які створили відкинутий результат. У багатоагентних конвеєрах — роях агентів, паралельних працівниках з очищення даних або будь-яких системах, де кілька ботів спільно використовують файл плану або scratchpad — ці приховані втрати можуть перетворитися на значний витік коштів. Аномалія також загрожує цілісності даних: наступні кроки можуть діяти на основі неповної або застарілої інформації, що призводить до каскадних помилок.
Як виникає аномалія
Першопричиною є стан гонитви (race condition):
- Два (або більше) агенти зчитують ту саму версію ресурсу, наприклад, JSON-файл плану.
- Кожен виконує власні міркування або трансформацію на основі цього знімка (snapshot).
- Обидва агенти виконують операцію запису назад у спільне сховище.
- Система сховища приймає другий запис, перезаписуючи перший без будь-якого виявлення конфлікту.
- Обидва агенти отримують «ACK», що підтверджує успішність запису, хоча перший внесок було втрачено.
Підтвердження системи сховища доводить лише те, що запис відбувся; воно не гарантує, що запис був безпечним відносно інших паралельних оновлень. Журнал лише для додавання (append-only log), який часто пропонують як засіб захисту, поводиться так само: він фіксує факт запису, але не запобігає тому, щоб пізніші записи не затерли попередні.
Що робить механізм compare-and-set
Механізм compare-and-set (CAS) додає перевірку версії перед тим, як запис буде прийнято:
- Read (Зчитування): Агент отримує поточний номер версії (або хеш) файлу.
- Compute (Обчислення): Агент виконує свою роботу, створюючи нову версію файлу.
- Write (Запис): Агент надсилає новий вміст разом із версією, яку він зчитав спочатку.
- Validate (Валідація): Рівень сховища порівнює надану версію з поточною. Якщо вони відрізняються, запис відхиляється; в іншому випадку він виконується і версія інкрементується.
Якщо версія змінилася, агент розуміє, що його дані застаріли, і повинен повторити весь цикл — зчитування, обчислення, запис — використовуючи свіжу версію. Це перетворює невидиме перезаписування на явну помилку, яку можна залогувати, повторити та врахувати.
Ціна безпеки
Механізм CAS не є безкоштовним. У тій самій симуляції з п'ятьма агентами:
| Сценарій | Спроб запису | Успішних внесків | Вартість у токенах |
|---|---|---|---|
| Без CAS | 5 | 1 | 5 одиниць |
| З CAS | 5 | 5 (після повторів) | 9 одиниць |
Механізм додає додаткові цикли зчитування-обчислення-запису для агентів, які стикаються з конфліктом версій, що збільшує витрати токенів. Компроміс очевидний: без механізму ви тихо втрачаєте дані; з механізмом ви платите помірну надбавку, але отримуєте видимість кожного конфлікту.
Наскільки часто трапляється ця помилка?
Навіть за участі лише двох агентів тест показав 75% ймовірність того, що один із записів буде втрачено. При п'яти агентах рівень втрат наближався до 100%. Ці цифри свідчать про те, що припущення «зазвичай усе гаразд» є небезпечним для будь-якого багатоагентного робочого процесу виробничого рівня.
Контраргумент: коли можна пропустити перевірку
Якщо система використовує одного агента на ресурс або забезпечує сувору серіалізацію на вищому рівні, додаткові перевірки CAS можуть бути непотрібними. Однак розрахунок ризиків має включати приховану вартість повторного виконання невдалої роботи та потенційний вплив відсутніх даних на наступні етапи.
На що звернути увагу далі
- Підтримка інструментарію: Шукайте API сховищ, які надають номери версій або ETag і підтримують атомарні операції CAS «з коробки».
- Метрики: Налаштуйте інструментарій ваших агентів так, щоб вони фіксували, як часто запис відхиляється через невідповідність версій. Зростання частоти конфліктів сигналізує про необхідність масштабування ресурсів або перепроектування робочого процесу.
- Стратегії повторних спроб: Проста експоненціальна затримка (exponential back-off) працює добре, але пам'ятайте, що повторні спроби збільшують споживання токенів. Балансуйте ліміти повторів із допустимим рівнем втрати даних.
- Гібридні підходи: Деякі команди поєднують журнал лише для додавання (append-only log) для можливості аудиту з механізмом CAS для забезпечення узгодженості, гарантуючи як запис того, що сталося, так і захист від перезаписування.
Висновок
Аномалії втраченого оновлення перетворюють AI-пайплайни, керовані токенами, на чорні діри, що призводять до втрати коштів. Механізм версіонування типу compare-and-set додає незначні витрати токенів, проте перетворює приховану втрату даних на видиму подію, яку можна повторити. У будь-якій системі, де кілька агентів мають спільний стан — бази даних, файли планів або scratchpads — впровадження перевірки версії перед записом є найдешевшою страховкою від прихованих витрат і порушення робочих процесів.