SWE-bench: Чи можуть мовні моделі вирішувати реальні проблеми GitHub?

Стаття CodeAct навів переконливі аргументи на користь Python як правильного формату дій для агентів LLM. Але вибір правильного формату дій — це лише половина проблеми. Ви також повинні продемонструвати, що агенти можуть справлятися зі складністю завдань реального світу, а не лише з підготовленими бенчмарками. SWE-bench (arXiv:2310.06770), опублікований Карлосом Хіменесом, Джоном Янгом, Александром Веттігом, Шунью Яо, Кексіном Пеєм, Офіром Прессом та Картіком Нарасімханом із Прінстона та представлений на ICLR 2024, — це стаття, яка змусила галузь безпосередньо зіткнутися з цією прогалиною.

Стаття

"SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" створює бенчмарк із 2294 завдань, взятих із реальних об'єднаних pull-запитів у 12 популярних репозиторіях Python — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy та xarray. Кожне завдання надає моделі знімок кодової бази та опис проблеми в GitHub; модель повинна створити патч, який змусить визначений набір раніше провалених тестів пройти, не ламаючи існуючі тести. Бенчмарк було побудовано шляхом аналізу близько 90 000 PR, відфільтровуючи ті, що одночасно вирішували пов'язану проблему та додавали нові тести, а потім перевіряючи переходи між успішним і невдалим виконанням. Така дисциплінована побудова дозволяє уникнути типової проблеми бенчмарків — неоднозначної істини, якою легко маніпулювати.

Ключові ідеї

• Claude 2, модель із найкращими показниками на момент публікації, вирішує лише 1,96% проблем за допомогою розрідженого пошуку BM25 — реалістичного сценарію розгортання, де модель повинна самостійно знайти відповідні файли.
• При використанні "oracle" пошуку (коли моделі надаються саме ті файли, які їй потрібні) показник Claude 2 покращується до 4,80%, що підтверджує: вузьким місцем є частково пошук, але в основному — редагування. Навіть з ідеальним контекстом рівень успіху залишається нижче 5%.
• GPT-4 вирішує 0,00% проблем із пошуком BM25 (оцінювався на 25% вибірці з міркувань бюджету) і 1,74% з "oracle". Падіння від "oracle" до BM25 для Claude 2 є критичним; для GPT-4 воно повне.
• Згенеровані патчі систематично занадто короткі: успішні патчі Claude 2 у середньому мають 19,6 рядків, порівняно з 74,5 рядками в еталонних людських патчах. Моделі знаходять прості локальні виправлення; люди пишуть комплексні рішення, що охоплюють кілька файлів.
• Більше контексту фактично шкодить. BM25 при 50 тисячах токенів знаходить більше "oracle" файлів, ніж при 13 тисячах, проте рівень вирішення завдань часто падає. Ефект "lost in the middle" (загублений посередині) — коли моделі ігнорують релевантні докази, заховані в довгих контекстах — є реальною і задокументованою причиною невдач.
• SWE-Llama 13b, донавчена на контекстах "oracle", досягає 4,00% з "oracle", але лише 0,70% з BM25. Навчання на ідеальному контексті створює крихких агентів, які виходять із ладу при реалістичному пошуку.

Що підтверджується, а що ні

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

Результати витримали перевірку часом. SWE-bench був опублікований у жовтні 2023 року і швидко став де-факто стандартом оцінки для агентів кодування. Початковий базовий рівень 1,96% є справді інформативним, а не спеціально підібраним. SWE-agent, опублікований у 2024 році спорідненою групою, підняв планку до 12,47% шляхом редизайну інтерфейсу агент-комп'ютер — це 6-кратне покращення, яке саме по собі підтверджує, наскільки багато можливостей не врахував початковий базовий варіант.

Дві речі, з якими стаття справляється гірше: По-перше, бенчмарк орієнтований лише на Python. Це практична необхідність, але це створює реальний ризик перенавчання під конвенції Python. По-друге, стаття пропонує лише базові варіанти з генерацією, доповненою пошуком (RAG), і явно залишає підходи на основі агентів для майбутніх робіт. Це відтермінування було доречним у 2023 році, але означає, що сама стаття не дає сигналу про те, які архітектури агентів допомагають.

Налаштування "oracle" також є слабшою верхньою межею, ніж здається. Надання ідеального контексту файлу не вирішує проблему локалізації коду всередині цих файлів і не допомагає з багатофайловими міркуваннями про взаємодію між модулями. 4,8% успіху Claude 2 в режимі "oracle" означає, що навіть із потрібними файлами в контексті модель зазнає невдачі у 95% випадків. Проблема не в першу чергу в пошуку.

Чому це важливо для фінансового AI

Beancount — це проект на Python, розміщений на GitHub. Агент запису для Beancount — це, по суті, агент, якому потрібно виконувати завдання у стилі SWE-bench: маючи файл леджера та інструкцію ("додай цю транзакцію", "виправ цю розбіжність у балансі"), створити редагування, яке проходить bean-check, не порушуючи існуючі твердження (assertions).

Невдача пошуку є прямою аналогією до проблеми локалізації в леджері. Коли користувач каже "виправ завищення витрат на офісне приладдя у 3-му кварталі", агент повинен спочатку знайти відповідні записи у файлі, який може містити тисячі рядків — це те саме завдання локалізації файлу, де BM25 зазнає невдачі у 40–50% випадків SWE-bench. Деградація "lost in the middle" однаково стосується довгих файлів .beancount, де записи з ранніми датами мають таку ж імовірність бути проігнорованими.

Асиметрія довжини патча є практичним попередженням. Моделі виправляють помилки занадто вузько. У бухгалтерському обліку це перетворюється на виправлення одного запису при пропуску кореспондуючого запису або оновлення рядка витрат при залишенні застарілого поточного балансу. Продуктовому агенту Beancount потрібен шар валідації — bean-check, перевірка балансу або явний етап звірки (reconciliation) — який змушує агента бачити повний наслідок свого редагування, а не лише його локальну правдоподібність.

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

Що читати далі

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — пряме продовження; перехід від 1,96% до 12,47% шляхом редизайну інтерфейсу взаємодії агента з комп'ютером. Принципи проектування навігації файлами та пошуку коду безпосередньо застосовні до інструментарію агентів Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — прибирає складність агентів і показує, що простий конвеєр локалізації та виправлення без додаткових надбудов може бути конкурентоспроможним; корисна противага підходам з важкими інтерфейсами.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — вирішує проблему довгого контексту за допомогою багаторівневого керування пам'яттю; безпосередньо релевантно для агентів, які повинні опрацьовувати багаторічні леджери Beancount.