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 заявки (PR) в 12 популярни хранилища на Python — astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy и xarray. Всеки случай представя на модела моментна снимка на кодовата база и описание на проблем в GitHub; моделът трябва да генерира корекция (patch), която да накара определен набор от предварително неуспешни тестове да преминат успешно, без да нарушава съществуващите тестове. Бенчмаркът е конструиран чрез проучване на ~90 000 PR, филтриране за тези, които едновременно решават свързан проблем и добавят нови тестове, и след това верифициране на преходите между успех и неуспех на база изпълнение. Тази дисциплинирана конструкция избягва типичния за бенчмарковете проблем с неясна или лесна за манипулиране истина.

Ключови идеи

• Claude 2, моделът с най-добри резултати при публикуването, разрешава само 1,96% от проблемите при използване на BM25 рядко извличане — реалистичната среда за внедряване, в която моделът трябва сам да намери съответните файлове.
• При „оракулско“ извличане (oracle retrieval) — където на модела се предоставят точно файловете, които са му нужни — Claude 2 се подобрява до 4,80%, потвърждавайки, че тясното място е отчасти извличането, но главно редактирането: дори с перфектен контекст, степента на успех остава под 5%.
• GPT-4 разрешава 0,00% от проблемите с BM25 извличане (оценен върху 25% подмножество поради бюджетни причини) и 1,74% с оракулско. Спадът от оракул към BM25 за Claude 2 е сериозен; за GPT-4 той е пълен.
• Генерираните корекции са систематично твърде кратки: успешните корекции на Claude 2 са средно 19,6 реда, срещу 74,5 реда за еталонните човешки корекции. Моделите откриват прости локални решения; хората пишат изчерпателни решения, обхващащи множество файлове.
• Повече контекст всъщност вреди. BM25 при 50 000 токена извлича повече от оракулските файлове, отколкото при 13 000 токена, но въпреки това нивата на решаване често спадат. Ефектът „изгубени в средата“ — модели, игнориращи релевантни доказателства, заровени в дълги контексти — е реален и документиран режим на отказ тук.
• SWE-Llama 13b, фино настроен върху контексти с оракулско извличане, постига 4,00% с оракул, но само 0,70% с BM25. Обучението върху перфектен контекст създава крехки агенти, които се провалят при реалистично извличане.

Какво издържа проверката и какво не

Конструкцията на бенчмарка е строга. Оценката, базирана на изпълнение — тестовете действително се стартират и преминават или не — е правилната основа за задачи по редактиране на код. Тя е обективна, автоматизируема и трудна за манипулиране. Решението да се изискват преходи от неуспех към успех (а не просто успешно прилагане на корекцията) е особено важно: то предотвратява тривиално правилни корекции като празни операции (no-ops) или изтривания.

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

Две неща, с които документът не се справя добре: Първо, бенчмаркът е само за Python. Това е практическа необходимост, но създава реален риск от прекомерно адаптиране (overfitting) към конвенциите на Python. Второ, документът предлага само базови линии за извличане, допълнено с генериране (RAG), и изрично оставя за бъдеща работа подходите, базирани на агенти. Това отлагане беше подходящо през 2023 г., но означава, че самият документ не дава сигнал кои агентни архитектури помагат.

„Оракулската“ настройка също е по-слаба горна граница, отколкото изглежда. Предоставянето на перфектен контекст от файлове не решава локализирането на кода в тези файлове и не помага при разсъжденията върху множество файлове за взаимодействията между модулите. Резултатът от 4,8% за Claude 2 с оракул означава, че дори с правилните файлове в контекста, моделът се проваля в 95% от случаите. Проблемът не е основно в извличането.

Защо това е важно за финансовия ИИ

Beancount е Python проект, хостван в GitHub. Агент за запис (write-back) за Beancount по същество е агент, който трябва да изпълнява задачи в стил SWE-bench: даден счетоводен файл и инструкция („добави тази транзакция“, „коригирай това несъответствие в баланса“), той трябва да създаде редакция, която преминава bean-check, без да нарушава съществуващите твърдения (assertions).

Провалът при извличането е пряко аналогичен на проблема с локализацията в счетоводната книга. Когато потребителят каже „коригирай надценката в офис консумативите за третото тримесечие“, агентът трябва първо да намери съответните записи във файл, който може да съдържа хиляди редове — същата задача за локализация на файлове, при която BM25 се проваля в 40–50% от случаите в SWE-bench. Деградацията „изгубени в средата“ се прилага еднакво и за дълги .beancount файлове, където по-старите записи е също толкова вероятно да бъдат игнорирани.

Асиметрията в дължината на корекциите е практическо предупреждение. Моделите правят корекции твърде тясно. В счетоводството това се превежда като коригиране на един запис, докато се пропуска съответстващият насрещен запис, или актуализиране на разходен ред, докато текущият баланс остава остарял. Един производствен Beancount агент се нуждае от слой за валидиране — bean-check, твърдения за баланс или изрична стъпка за равнение (reconciliation pass) — който принуждава агента да види пълните последици от своята редакция, а не само нейната локална правдоподобност.

Разликата между оракул и 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 регистри.