Проблему детально описав засновник і CEO стартапу SpaceCell Пітер Боуер, пише InfoWorld.
За його спостереженнями, модель Opus має тенденцію використовувати плутану або вигадану термінологію, що створює купу зайвої роботи, особливо під час генерації документації.
Він зазначив: «Незважаючи на чіткі та неодноразові вказівки уникати певних термінів, модель продовжує їх вставляти. Це змушує робити додаткові проходи для очищення тексту, зокрема через дешевші Sonnet або Haiku, щоб привести документацію до адекватного стану. Такі повторні запити збільшують витрати на токени майже вдвічі».
Скарга Боуера на GitHub зібрала сотні підтверджень від інших розробників, а аналогічні обговорення на Reddit щодо незв’язності мови в Opus збирають безліч реакцій.
Для корпоративних інженерних команд це створює суттєві операційні ризики. Головний аналітик Avasant Абхішек Сатапаті підкреслює: «Постійні цикли виправлень з’їдають продуктивність, коли розробники витрачають забагато часу на перевірку та коригування відповідей ШІ. Це повністю нівелює економію часу від використання кодинг-асистентів».
Senior SRE у Broadcom Адваіт Пател додає, що нечіткий текст безпосередньо впливає на якість ранбуків, архітектурних записів (ADR) та опису інцидентів. За його словами: «Ранбук, написаний важкою для сприйняття мовою, стає критичною проблемою під час реального інциденту, коли команді потрібно миттєво зрозуміти ситуацію та діяти. Крім того, роздуті або заплутані описи пулл-реквестів інженери зазвичай читають неуважно, через що легко пропустити важливі деталі або потенційні баги».
Плутані відповіді моделі призводять і до прихованих фінансових витрат. Chief Revenue Officer компанії Kanerika Бхупендра Чопра зазначає, що ціна, яку компанії платять за інструмент, не відображає реальної вартості отримання робочого результату: «Якщо розробникам доводиться робити декілька підходів для переписування відповідей або перенаправляти їх в іншу модель, ці дії стають частиною загальної вартості завдання, включаючи час роботи інженера». При цьому Адваіт Пател зауважує, що більшість компаній навіть не помічають цих витрат, оскільки вони «заховані в один загальний рядок рахунку за використання кодинг-агента».
Така ситуація створює прямі ризики для самої Anthropic, адже змінити кодинг-асистента сьогодні відносно легко. Як зазначає Пател: «Зміна базової моделі не вимагає міграції коду чи репозиторіїв, тому бар’єр для переходу дуже низький. Лояльність користувачів — це єдине, що утримує їх від переходу на рішення конкурентів, а постійне роздратування через погану читабельність тексту швидко цю лояльність знищує».
Поки Anthropic утримується від офіційних коментарів, розробники шукають тимчасові рішення. Пітер Боуер закликає компанію налаштувати дефолтний стиль моделі так, щоб він відповідав «технічній документації або якісній відповіді на Stack Overflow — лаконічному, прямому та стверджувальному». У свою чергу, Адваіт Пател радить не просто просити модель бути стислою, а прописувати чіткі правила в конфігурації проекту з забороною конкретних формулювань.
Втім, звичайних промптів для системного вирішення проблеми замало, оскільки поведінка моделей постійно змінюється. Адваіт Пател підсумовує: «Поведінка моделі — це рухома ціль. Оновлення версії може змінити стиль відповідей без жодного сповіщення у вашому пайплайні. Тімлідам та CIO варто зафіксувати версії моделей для критичних процесів, створити власний тестовий набір реальних тасок для перевірки щоразу при зміні моделей, відстежувати відсоток переробок і не дозволяти кожній команді вигадувати власні недокументовані костилі в промптах».
/
Мовні збої в топових моделях Anthropic Opus можуть непомітно виснажувати бюджети та знижувати продуктивність розробників. Штучний інтелект для написання коду покликаний прискорювати розробку, проте специфічні проблеми з генерацією тексту змушують інженерів витрачати додатковий час, промпти й токени на виправлення відповідей. У деяких випадках розробникам навіть доводиться проганяти згенерований вміст через дешевші моделі, аби зробити його придатним для використання.
