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