ПостЧому агент тупить при вирішенні бажинок?

Чому агент тупить при вирішенні бажинок? Тобі, як зазвичай, прилітає баг. Закидаєш агенту опис проблеми, стектрейс, тести, лінк на issue і купу додаткової інфи. І чомусь одну бажинку він фіксить одразу, а на дуже схожій проблемі ловить затуп. І інформація начебто однакова, і проблеми схожі, але працює через раз 👉 Вийшло дослідження «How Do LLMs Read Bug Reports?» - хлопці полізли подивитись, куди модель спрямовує attention (увагу), коли сама генерує готовий патч на баг. Це називається APR (Automated Program Repair) Attention - це механізм всередині моделі, за допомогою якого вона на кожному кроці вирішує, які токени з усього твого промпту брати до уваги, а які майже ігнорити. Технічно - для кожного токена рахуються ваги до всіх інших токенів, і на виході зважена сума. Тобто модель не читає промпт рівномірно, вона щоразу вирішує, що в ньому важливе, а що не дуже Дослідники по черзі прибирали частини bug report і перевіряли, наскільки через це змінюється згенерований патч. Якщо після видалення фрагмента патч сильно змінювався - значить, ця інформація суттєво впливала на рішення моделі. А тепер згадай, що лежить у звичайному bug report - змінні оточення, версії бібліотек, номери білда, купа технічної інфи. Для моделі це такі ж токени, і туди теж може піти увага 🎯 Суть дослідження: Взяли 319 багів на python і java зі SWE-bench Verified і Multi-SWE-bench. Для кожного простежили, як attention розподіляється по секціях bug report, і порівняли вдалі фікси з невдалими і дійшли такого висновку: successful repairs are characterized by diffused attention across multiple diagnostic components such as bug descriptions, stacktraces, and test cases, while failures often exhibit over-localized attention toward metadata such as version information Тобто: ✅ вдалий фікс - увага розподілена між кількома релевантними компонентами: опис + стектрейс + тести і модель може втримати в фокусі всю картнику ❌ провальний - увага залипає на чомусь вузькому, найчастіше на метаданих (типу версії бібліотек). Фактично модель чіпляється за другорядну деталь і спрямовує всю увагу туди Під час дослідження модель залипла на посиланні на зовнішній PR, до якого не мала доступу, і проігнорувала згадку TypeError, яка фактично вказувала на те, як зробити фікс Ще цікаво, хоча і очевидно, що чим сильніше attention моделі збігається з тим, що самі розробники вважають головною проблемою через яку виник баг - тим вищий шанс, що фікс спрацює Що з цим робити 📍 Не вивалюйте моделі все однією купою. Структуруйте дані: спочатку головне - опис, потім стектрейс, потім тест 📍 Не давайте агенту лінки, бо якщо він не може реально відкрити issue або PR, посилання може стати ще одним відволікаючим токеном. Краще вставити релевантний фрагмент прямо в контекст 📍 Метадані винесіть в окремий блок і залишайте лише тоді, коли версія або оточення справді можуть пояснювати баг 👉 Якщо агент затупив, перший інстинкт - докинути ще контексту, але на практиці спочатку спробуй навпаки - прибери шум і дай один точний приклад чи напрямок p.s. окрема кайфова тема - Iron Law: працює дуже добре, але це вже на окремий пост Youtube | Instagram