Модель Claude від Anthropic стикається з технічними викликами у генерації коду та надійності агентів

Anthropic зіткнулася з кількома технічними викликами щодо моделей Claude. Генерація коду зменшила гнучкість через обмеження, пов’язані з вбудовуванням водяних знаків; адаптивний механізм мислення Sonnet 5 дозволяє одній і тій самій моделі регулювати різні обчислювальні витрати, розмито розмежовуючи межі можливостей продуктів; хоча контекст у 1 млн токенів здається достатнім, у довгих сесіях агента модель фактично може ефективно використовувати лише приблизно 20–30%, після чого виникає плутанина стану та пропуски; під час стиснення контексту важко визначити, яка інформація залишається актуальною, тимчасові припущення можуть бути неправильно перетворені на факти; після того як агент активно змінює середовище, модель починає аналізувати нові помилки, які вона ж і створила, а не вихідну проблему. У статті зазначається, що надійність довгих агентів все більше залежить від чіткості стану, перевірності дій та можливості відкату помилок, а не від простої однокрокової продуктивності моделі.

Автор статті, джерело: Leiphone

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

Anthropic останнім часом трохи має такий відтінок.

Ці дні в X було опубліковано пост, який зібрав разом кілька типових скарг на Claude за цей період: текст і код почали позначати машинно-читаними мітками, реальний досвід з Sonnet 5 не відповідає шуму навколо оновлень моделі, Fable 5 продавався дорожче, але важко відчути, де саме він кращий за Opus 5; крім того, був ще більш виразний коментар: контекст Fable 5 використовується лише приблизно на 20%–30%, після чого його здатності починають падати.

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

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

Отже, останні проблеми Anthropic, можливо, не є просто «погіршенням моделі». Більш того, після того як Claude став набагато сильнішим, генерація, обчислення, контекст і виконання Agent почали починати заважати один одному.

01

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

Папер: https://arxiv.org/pdf/2301.10226

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

Код містить багато низькоентропійних місць. Після оголошення змінної подальші посилання майже завжди використовують те саме ім’я; поля JSON, лапки та дужки підлягають строгим структурним обмеженням; параметри функцій повинні відповідати інтерфейсу; у шляхах, регулярних виразах, SQL та командних оболонках зміна одного токена може безпосередньо змінити поведінку.

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

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

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

Anthropic не розкрила, як саме змінюються текстові токени Claude, тому неможливо безпосередньо приписати зміни якості Claude Code конкретному алгоритму водяного знаку.

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

02

Зміни, запроваджені адаптивним мисленням Sonnet 5, — це не просто те, що модель думає трохи довше.

Раніше, коли мова йшла про Sonnet, Opus, Fable, було легко сприймати їх як кілька фіксованих точок здібностей. Тепер із додаванням effort один і той самий модель може опинятися в різних інтервалах обчислень під час тестування, і сам моделювання вже не може повністю відображати, скільки ресурсів було витрачено на один запит.

Посилання для довідки: https://platform.claude.com/docs/en/build-with-claude/effort

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

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

Посилання для довідки: https://platform.claude.com/docs/en/build-with-claude/effort

Тому effort регулює не просто довжину міркувань, а обсяг пошуку, дозволений для однієї задачі Agent. Це безпосередньо змінює шарову структуру моделі Anthropic.

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

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

Посилання для довідки: https://www.anthropic.com/news/claude-opus-5

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

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

03

Бачачи 1M контексту, легко сприйняти його як величезну робочу пам’ять, тому коли Claude починає пропускати, повторювати або втрачати стан уже при використанні лише 200K або 300K токенів, це здається дуже нелогічним.

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

Посилання для довідки: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

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

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

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

Посилання для довідки: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

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

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

04

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

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

Посилання для довідки: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

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

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

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

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

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

Посилання для довідки: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

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

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

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

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

Посилання для довідки: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Якщо він може визначити, що «ці нові помилки виникли після попередніх змін», він може відкатитися та повторно перевірити початкові припущення; якщо ця причинно-наслідкова зв’язок не встановлена, нові помилки можуть продовжувати сприйматися як окремі проблеми, які виправляються одна за одною.

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

Git diff може повідомити моделі, які зміни відбулися недавно, тести можуть перевірити, чи було порушено певну поведінку, checkpoint і rollback можуть обмежити поширення помилок, а незалежний evaluator може надати додаткову перевірку окрім власного пояснення моделі.

Суть цих компонентів полягає у наданні агенту здатності до замкненого циклу виправлення помилок.

Посилання для довідки: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

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

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

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

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

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

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

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