інструменти кодування штучного інтелекту, такі як ChatGPT, є загрозливими, і Stack Overflow знову звільняється! Однак Прінстон і Чикаго виявили, що GPT-4 має 0% роздільної здатності для реальних проблем GitHub.
Stack Overflow, вже створений ChatGPT!
Оскільки програмісти стікалися до ChatGPT і Github Copilot, Stack Overflow сьогодні довелося оголосити про звільнення понад 100 співробітників, що становить майже 1/3 кількості співробітників.
Отже, інструменти кодування штучного інтелекту, такі як ChatGPT, справді підірвуть усю індустрію?
Але нещодавнє дослідження, проведене в Прінстоні та Чикаго, показало, що LLM не так просто зробити як фермеру коду.
Паперова адреса:
З огляду на 2294 реальні проблеми GitHub, коефіцієнт проходження GPT-4, який вирішує випадкові задачі GitHub, виявився 0%!
Навіть найкраща модель, Claude 2, вирішує лише 1,96% з них.
Чи можуть програмісти втратити роботу через ChatGPT? Відповідь – абсолютно ні на даний момент.
Адаптуватися або загинути
Як улюблений сайт кожного розробника з підтримкою коду у світі, Stack Overflow і раніше добре працював, спровокувавши сплеск найму минулого року, подвоївши штат компанії до 540 осіб.
Однак все змінилося після того, як OpenAI випустила ChatGPT у листопаді минулого року.
Допомога, яку надають чат-боти зі штучним інтелектом, є більш конкретною, ніж повідомлення на форумі 5 років тому. За допомогою LLM розробники можуть миттєво виправити точний код, пропозиції щодо оптимізації та опис того, що робить кожен рядок коду.
Хоча LLM не надає 100% надійних відповідей, унікальна здатність негайно перевіряти код, просто протестувавши його в інтегрованому середовищі розробки, робить написання коду ідеальним варіантом використання ChatGPT.
Як наслідок, трафік Stack Overflow значно скоротився, а інструменти програмування штучного інтелекту, такі як ChatGPT і Github Copilot на основі GPT-4, стали новими місцями для фермерів коду.
Сьогодні генеральний директор Прашант Чандрасекар оголосив, що Stack Overflow звільнила понад сотню співробітників, або 28% своєї робочої сили.
Генеральний директор пояснює звільнення тим, що Stack Overflow намагається вийти на шлях прибутковості під макроекономічним тиском і продовжує впроваджувати продуктові інновації.
** Переправитися через річку і знести міст? **
Найбільша іронія впливу ChatGPT на Stack Overflow полягає в тому, що потужність великої мовної моделі походить значною мірою від скрейпінгу таких сайтів, як Stack Overflow.
Що станеться, якщо великі мовні моделі спустошать ці дані, нічого не давши натомість, і якщо всі джерела даних будуть витіснені з бізнесу?
Зараз у багатьох технологічних компаній вже нависла проблема: чим менше програмістів, тим менше буде штучних даних.
Як навчати нові моделі штучного інтелекту без актуальних даних?
Хочете використовувати наші дані? Візьми гроші**
Stack Overflow, звичайно ж, не може всидіти на місці, він вибрав два способи порятунку -
Один з них полягає в розробці власного інструменту кодування штучного інтелекту OverflowAI, а інший – у пошуку партнерства безпосередньо з технологічними компаніями, такими як OpenAI, які використовують дані Stack Overflow для побудови моделей штучного інтелекту.
OpenAI розробляє елементи керування веб-сканерами для ChatGPT, щоб дані з таких сайтів, як Stack Overflow, не можна було сканувати.
Генеральний директор сказав, що Stack Overflow висунув свою позицію: той, хто хоче використовувати наші дані для навчання LLM, платить.
Керівники компаній вважають, що такі сайти, як Stack Overflow, мають вирішальне значення для розробки великих мовних моделей, і для того, щоб розвиватися, їх потрібно навчати новим знанням.
Прашант Чандрасекар, генеральний директор Stack Overflow
LLM хоче отримати фармер коду, ще рано
Отже, чи дійсно великі мовні моделі можуть приймати фермерів коду?
Команди з Прінстона та Чикаго зрозуміли, що це не так просто!
В останній статті дослідники пропонують новий фреймворк, SWE-bench, для оцінки здатності великих моделей вирішувати 2294 реальні проблеми на GitHub.
З'ясувалося, що провідні великі моделі, такі як GPT-4 і Claude 2, мали менше 5% здатності вирішувати реальні проблеми.
Якщо бути більш точним, GPT-4 може вирішувати випадкові проблеми GitHub з коефіцієнтом проходження 0%, тоді як найкраща модель, Claude 2, може вирішити лише 1,96% з них.
Більше того, при використанні BM-25 для отримання відповідних файлів коду для кожної проблеми, лише 23% патчів, написаних Claude 2, були дійсними (готовими до репозиторію), і лише ~1% фактично вирішували проблему.
Крім того, продуктивність різних моделей у вирішенні завдань з 12 популярними бібліотеками Python також різниться.
Модель GPT-4 досягла такого результату, що дійсно дивно, адже багато хто вже давно розцінює її як «зброю програмування».
Але щоб чітко побачити справжню силу штучного інтелекту, не варто забивати і хвилюватися.
Деякі користувачі мережі заявили, що це найкраща відповідь на питання про те, "чи є фермери коду безробітними через програмування".
Нарешті хтось зробив реальний набір даних для кодової моделі, і Hum був лише інтерв'ю LLM leetcode. Ми всі знаємо, що це неправильна міра для інженерів-людей. Менше 4% звучить правильно, оскільки великі моделі все ще далекі від повної автономності.
Отже, чи дійсно це стосується результатів SWE-bench в оцінці можливостей великих моделей?
SWE-bench: Призначений для кодування моделей
У цьому дослідженні автори виявили, що багато поточних тестів для вимірювання здатності кодування великих моделей стали насиченими і не можуть виміряти справжню силу великих моделей.
Наприклад, у Human задача виклику занадто проста, і LLM потребує лише кількох рядків коду для вирішення окремої задачі.
Однак в реальності програмна інженерія не така проста.
Щоб виправити помилку, може знадобитися переглянути величезну бібліотеку ресурсів, зрозуміти взаємозв'язки між функціями в різних файлах або знайти невелику помилку в складному коді.
Надихнувшись цим, дослідники з Прінстона і Чикаго представили SWE-bench.
SWE-bench отримує екземпляри завдань зі справжнього репозиторію Python, підключаючи проблеми GitHub і рішення запитів на злиття для вирішення пов'язаних тестів.
Як показано на зображенні, завданням моделі, зазвичай звітом про помилку або запитом на функцію, є вирішення проблеми, пов'язаної з репозиторієм GitHub.
Кожне завдання вимагає генерації патча та опису змін, які будуть застосовані до існуючої кодової бази.
Потім використовуйте тестовий фреймворк репозиторію SWE-bench для оцінки модифікованої кодової бази.
Щоб знайти якісні приклади масштабних завдань, дослідники пройшли три етапи скринінгу:
**Етап 1: Підбір складу та пошук даних. **
Запити на злиття (PR) були вперше зібрані з 12 популярних репозиторіїв Python з відкритим вихідним кодом на GitHub, згенерувавши загалом близько 90 000 PR.
Дослідники зосередилися на популярних репозиторіях, оскільки вони, як правило, краще підтримуються, мають чіткі вказівки для учасників і краще покриття тестів. Кожен PR має пов'язану кодову базу, тобто стан репозиторію до злиття PR.
**Фаза 2: Фільтрація на основі атрибутів. **
Завдання-кандидат створюється шляхом вибору об'єднаного PR, який відповідає наступним критеріям: (1) вирішує проблему GitHub; (2) Змінено тестовий файл репозиторію, що вказує на те, що користувач, швидше за все, вніс тести, щоб перевірити, чи вирішено проблему.
**Фаза 3: Фільтрація на основі виконання. **
До кожного завдання кандидата застосовується тестовий зміст ПР, а також відповідні результати тестування до і після іншого змісту ПР.
Дослідник відсіває екземпляри завдань, які не мають хоча б одного тесту, і статус цих тестів змінюється з «не склав» (далі – «не пройшов тест»). Крім того, відфільтровуються екземпляри, які спричиняють помилки встановлення або експлуатації.
На цих етапах відбору початкові 90 000 PR відбираються на 2 294 екземпляри завдань, які складають SWE-bench.
Остаточна класифікація цих екземплярів завдань у різних репозиторіях показана на рисунку 3 нижче, де таблиця є основною особливістю екземплярів завдань SWE-bench.
Дослідники наголошують, що ці кодові бази великі, містять тисячі файлів, і що довідкові запити на пул часто змінюють кілька файлів одночасно.
SWE-bench має ряд переваг перед існуючими бенчмарками програмування LM.
Вони включають реальні налаштування з проблемами та рішеннями, надісланими користувачами, різноманітні вхідні дані з унікальними питаннями коду з 12 репозиторіїв, надійну структуру оцінювання на основі виконання та можливість постійно оновлювати тести новими екземплярами з мінімальним втручанням людини.
Завдання LLM: редагувати базу коду, розв'язувати задачі
Дослідник дасть великій моделі текстовий опис проблеми, а також повну кодову базу.
Завдання великої моделі полягає в редагуванні кодової бази для вирішення проблеми.
На практиці дослідники представляють зміни у вигляді файлів патчів, які вказують, які рядки в кодовій базі потрібно змінити, щоб вирішити проблему.
Як оцінити, чи є рішення, дане LLM, хорошим чи ні?
Дослідники використовують патчі Unix, застосовують згенеровані патчі до кодової бази, а потім виконують модульні та системні тести, пов'язані з екземплярами завдань.
Якщо патч успішно застосований, і всі ці тести пройдені, схема, рекомендована LLM, може вважатися такою, що успішно вирішила проблему.
Показник базового рівня, який є відсотком вирішених екземплярів завдань.
Побудова унікального набору даних для SWE-bench
Традиційні бенчмарки НЛП зазвичай включають лише короткі послідовності входів і виходів і враховують деякі «штучні» проблеми, створені спеціально для бенчмарків.
На противагу цьому, щоб побудувати SWE-bench, дослідники впровадили унікальні властивості в набір даних.
Наприклад, використовуються реальні завдання програмної інженерії.
Оскільки кожен екземпляр задачі в SWE-bench містить велику і складну базу коду і опис пов'язаної з нею проблеми, рішення SWE-bench вимагає складних навичок і знань досвідчених інженерів-програмістів, які часто не оцінюються в традиційних бенчмарках генерації коду.
Більше того, процес збору може бути легко застосований до будь-якого репозиторію Python на GitHub практично без втручання людини.
В результаті, дослідники можуть розширити SWE-bench, надаючи нові екземпляри завдань і оцінювати мовну модель для проблем, створених після дати навчання, гарантуючи, що навчальний корпус не містить рішення.
Крім того, дослідники гарантують різні довгі входи в бенчмарк, надійну оцінку, міжконтекстне редагування коду, широкий спектр рішень тощо.
Тонке налаштування SWE-Llama
Далі настав час оцінити ефективність відкритих і пропрієтарних моделей в рамках SWE-bench.
Однак дослідники виявили, що готові моделі тонкого налаштування CodeLlama не можуть слідувати детальним інструкціям для генерації редагувань коду в усій бібліотеці, часто виводячи відповіді-заповнювачі або нерелевантний код.
Щоб оцінити можливості цих моделей, дослідники провели контрольоване тонке налаштування (SFT) на моделі CodeLlama-Python з 7 мільярдами параметрів і моделі CodeLlama-Python з 13 мільярдами параметрів.
Отримана модель являє собою спеціалізований редактор репозиторію, який працює на обладнанні споживчого класу і вирішує проблеми GitHub.
### Великі моделі зазнають невдачі
Далі дослідники оцінили GPT-3.5, GPT-4, Cluade 2 та тонко налаштовані моделі.
Виявилося, що всі моделі вийшли з ладу - жодна з них не вирішила всі, крім найпростіших завдань.
Наприклад, Claude 2 і GPT-4 можуть вирішити лише 4,8% і 1,7% завдань відповідно.
Після використання ретривера BM25 продуктивність Claude 2 знизилася ще більше до 1,96%.
**Різні бібліотеки мають різний рівень складності. **
Якщо розбити продуктивність за репозиторієм, то можна побачити, що всі моделі демонструють схожі тенденції в різних бібліотеках.
Тим не менш, проблеми, які вирішуються кожною моделлю, не обов'язково сильно перетинаються. Наприклад, в установці оракула Claude 2 і SWE-Llama 13b працюють порівняно, вирішуючи 110 і 91 екземпляр на модель відповідно.
**Складність залежить від довжини контексту. **
Моделі можуть бути попередньо навчені на довгих послідовностях коду, але зазвичай вимагають генерації однієї функції за раз і надають фреймворк з обмеженим контекстом для визначення проблеми.
Як було показано, ви можете побачити, що продуктивність Claude 2 значно погіршується зі збільшенням загальної довжини контексту, що також можна спостерігати в інших моделях.
Навіть якщо збільшення максимального розміру контексту BM25 покращить відкликання відносно файлів Oracle, продуктивність все одно знизиться, оскільки модель просто не зможе знайти проблемний код у величезному тезаурусі.
**Складність не залежить від дати вирішення проблеми. **
У таблиці 7 наведено результати моделі за датою для ПР, створених до або після 2023 року в налаштуваннях пошуку «оракул».
Для більшості моделей, за винятком GPT-4, різниця в продуктивності до або після цієї дати невелика.
Крім того, дослідження показало, що тонке налаштування моделі чутливе до змін у розподілі контексту, і простіше згенерувати патч, ніж цілий файл. А великі моделі, як правило, виробляють коротші та простіші правки.
LLM не замінює програмістів, але може прискорити робочі процеси
Деякі користувачі мережі покладають надії та сподівання на майбутнє "універсальної моделі".
Правильно, ось що я кажу. Універсальна модель недостатньо хороша, щоб мати достатньо широку довжину контексту, щоб писати код самостійно, за винятком відносно коротких фрагментів коду.
Але я думаю, що це лише питання часу. Я можу передбачити, що в найближчому майбутньому універсальна LLM зі спеціальною підготовкою стане дуже професійною моделлю.
Хоча великі моделі не замінять програмістів, вони можуть прискорити свої робочі процеси. Те, що раніше займало команду з 10 осіб, тепер може потребувати лише 4 осіб. Це вивільняє ресурси для інших завдань, підготовлених компанією.
Замість того, щоб звільняти співробітників, щоб заощадити гроші, дозвольте розробникам досягати великих результатів із шаленою швидкістю!
Ресурси:
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Великі моделі не можуть бути фермерами коду! Несподіване відкриття Прінстона: GPT-4 має 0 успішних у вирішенні проблем програмування GitHub
Джерело статті: Shin Ji Yuan
Stack Overflow, вже створений ChatGPT!
Оскільки програмісти стікалися до ChatGPT і Github Copilot, Stack Overflow сьогодні довелося оголосити про звільнення понад 100 співробітників, що становить майже 1/3 кількості співробітників.
Але нещодавнє дослідження, проведене в Прінстоні та Чикаго, показало, що LLM не так просто зробити як фермеру коду.
З огляду на 2294 реальні проблеми GitHub, коефіцієнт проходження GPT-4, який вирішує випадкові задачі GitHub, виявився 0%!
Навіть найкраща модель, Claude 2, вирішує лише 1,96% з них.
Адаптуватися або загинути
Як улюблений сайт кожного розробника з підтримкою коду у світі, Stack Overflow і раніше добре працював, спровокувавши сплеск найму минулого року, подвоївши штат компанії до 540 осіб.
Однак все змінилося після того, як OpenAI випустила ChatGPT у листопаді минулого року.
Хоча LLM не надає 100% надійних відповідей, унікальна здатність негайно перевіряти код, просто протестувавши його в інтегрованому середовищі розробки, робить написання коду ідеальним варіантом використання ChatGPT.
Як наслідок, трафік Stack Overflow значно скоротився, а інструменти програмування штучного інтелекту, такі як ChatGPT і Github Copilot на основі GPT-4, стали новими місцями для фермерів коду.
Сьогодні генеральний директор Прашант Чандрасекар оголосив, що Stack Overflow звільнила понад сотню співробітників, або 28% своєї робочої сили.
** Переправитися через річку і знести міст? **
Найбільша іронія впливу ChatGPT на Stack Overflow полягає в тому, що потужність великої мовної моделі походить значною мірою від скрейпінгу таких сайтів, як Stack Overflow.
Що станеться, якщо великі мовні моделі спустошать ці дані, нічого не давши натомість, і якщо всі джерела даних будуть витіснені з бізнесу?
Зараз у багатьох технологічних компаній вже нависла проблема: чим менше програмістів, тим менше буде штучних даних.
Як навчати нові моделі штучного інтелекту без актуальних даних?
Хочете використовувати наші дані? Візьми гроші**
Stack Overflow, звичайно ж, не може всидіти на місці, він вибрав два способи порятунку -
Один з них полягає в розробці власного інструменту кодування штучного інтелекту OverflowAI, а інший – у пошуку партнерства безпосередньо з технологічними компаніями, такими як OpenAI, які використовують дані Stack Overflow для побудови моделей штучного інтелекту.
Генеральний директор сказав, що Stack Overflow висунув свою позицію: той, хто хоче використовувати наші дані для навчання LLM, платить.
Керівники компаній вважають, що такі сайти, як Stack Overflow, мають вирішальне значення для розробки великих мовних моделей, і для того, щоб розвиватися, їх потрібно навчати новим знанням.
LLM хоче отримати фармер коду, ще рано
Отже, чи дійсно великі мовні моделі можуть приймати фермерів коду?
Команди з Прінстона та Чикаго зрозуміли, що це не так просто!
З'ясувалося, що провідні великі моделі, такі як GPT-4 і Claude 2, мали менше 5% здатності вирішувати реальні проблеми.
Якщо бути більш точним, GPT-4 може вирішувати випадкові проблеми GitHub з коефіцієнтом проходження 0%, тоді як найкраща модель, Claude 2, може вирішити лише 1,96% з них.
Крім того, продуктивність різних моделей у вирішенні завдань з 12 популярними бібліотеками Python також різниться.
Але щоб чітко побачити справжню силу штучного інтелекту, не варто забивати і хвилюватися.
SWE-bench: Призначений для кодування моделей
У цьому дослідженні автори виявили, що багато поточних тестів для вимірювання здатності кодування великих моделей стали насиченими і не можуть виміряти справжню силу великих моделей.
Наприклад, у Human задача виклику занадто проста, і LLM потребує лише кількох рядків коду для вирішення окремої задачі.
Однак в реальності програмна інженерія не така проста.
Надихнувшись цим, дослідники з Прінстона і Чикаго представили SWE-bench.
SWE-bench отримує екземпляри завдань зі справжнього репозиторію Python, підключаючи проблеми GitHub і рішення запитів на злиття для вирішення пов'язаних тестів.
Як показано на зображенні, завданням моделі, зазвичай звітом про помилку або запитом на функцію, є вирішення проблеми, пов'язаної з репозиторієм GitHub.
Кожне завдання вимагає генерації патча та опису змін, які будуть застосовані до існуючої кодової бази.
Потім використовуйте тестовий фреймворк репозиторію SWE-bench для оцінки модифікованої кодової бази.
Запити на злиття (PR) були вперше зібрані з 12 популярних репозиторіїв Python з відкритим вихідним кодом на GitHub, згенерувавши загалом близько 90 000 PR.
Дослідники зосередилися на популярних репозиторіях, оскільки вони, як правило, краще підтримуються, мають чіткі вказівки для учасників і краще покриття тестів. Кожен PR має пов'язану кодову базу, тобто стан репозиторію до злиття PR.
**Фаза 2: Фільтрація на основі атрибутів. **
Завдання-кандидат створюється шляхом вибору об'єднаного PR, який відповідає наступним критеріям: (1) вирішує проблему GitHub; (2) Змінено тестовий файл репозиторію, що вказує на те, що користувач, швидше за все, вніс тести, щоб перевірити, чи вирішено проблему.
**Фаза 3: Фільтрація на основі виконання. **
До кожного завдання кандидата застосовується тестовий зміст ПР, а також відповідні результати тестування до і після іншого змісту ПР.
Дослідник відсіває екземпляри завдань, які не мають хоча б одного тесту, і статус цих тестів змінюється з «не склав» (далі – «не пройшов тест»). Крім того, відфільтровуються екземпляри, які спричиняють помилки встановлення або експлуатації.
На цих етапах відбору початкові 90 000 PR відбираються на 2 294 екземпляри завдань, які складають SWE-bench.
Остаточна класифікація цих екземплярів завдань у різних репозиторіях показана на рисунку 3 нижче, де таблиця є основною особливістю екземплярів завдань SWE-bench.
Дослідники наголошують, що ці кодові бази великі, містять тисячі файлів, і що довідкові запити на пул часто змінюють кілька файлів одночасно.
SWE-bench має ряд переваг перед існуючими бенчмарками програмування LM.
Вони включають реальні налаштування з проблемами та рішеннями, надісланими користувачами, різноманітні вхідні дані з унікальними питаннями коду з 12 репозиторіїв, надійну структуру оцінювання на основі виконання та можливість постійно оновлювати тести новими екземплярами з мінімальним втручанням людини.
Завдання LLM: редагувати базу коду, розв'язувати задачі
Дослідник дасть великій моделі текстовий опис проблеми, а також повну кодову базу.
Завдання великої моделі полягає в редагуванні кодової бази для вирішення проблеми.
На практиці дослідники представляють зміни у вигляді файлів патчів, які вказують, які рядки в кодовій базі потрібно змінити, щоб вирішити проблему.
Дослідники використовують патчі Unix, застосовують згенеровані патчі до кодової бази, а потім виконують модульні та системні тести, пов'язані з екземплярами завдань.
Показник базового рівня, який є відсотком вирішених екземплярів завдань.
Побудова унікального набору даних для SWE-bench
Традиційні бенчмарки НЛП зазвичай включають лише короткі послідовності входів і виходів і враховують деякі «штучні» проблеми, створені спеціально для бенчмарків.
На противагу цьому, щоб побудувати SWE-bench, дослідники впровадили унікальні властивості в набір даних.
Наприклад, використовуються реальні завдання програмної інженерії.
Більше того, процес збору може бути легко застосований до будь-якого репозиторію Python на GitHub практично без втручання людини.
В результаті, дослідники можуть розширити SWE-bench, надаючи нові екземпляри завдань і оцінювати мовну модель для проблем, створених після дати навчання, гарантуючи, що навчальний корпус не містить рішення.
Крім того, дослідники гарантують різні довгі входи в бенчмарк, надійну оцінку, міжконтекстне редагування коду, широкий спектр рішень тощо.
Тонке налаштування SWE-Llama
Далі настав час оцінити ефективність відкритих і пропрієтарних моделей в рамках SWE-bench.
Однак дослідники виявили, що готові моделі тонкого налаштування CodeLlama не можуть слідувати детальним інструкціям для генерації редагувань коду в усій бібліотеці, часто виводячи відповіді-заповнювачі або нерелевантний код.
Щоб оцінити можливості цих моделей, дослідники провели контрольоване тонке налаштування (SFT) на моделі CodeLlama-Python з 7 мільярдами параметрів і моделі CodeLlama-Python з 13 мільярдами параметрів.
Отримана модель являє собою спеціалізований редактор репозиторію, який працює на обладнанні споживчого класу і вирішує проблеми GitHub.
Далі дослідники оцінили GPT-3.5, GPT-4, Cluade 2 та тонко налаштовані моделі.
Виявилося, що всі моделі вийшли з ладу - жодна з них не вирішила всі, крім найпростіших завдань.
Наприклад, Claude 2 і GPT-4 можуть вирішити лише 4,8% і 1,7% завдань відповідно.
Після використання ретривера BM25 продуктивність Claude 2 знизилася ще більше до 1,96%.
**Різні бібліотеки мають різний рівень складності. **
Якщо розбити продуктивність за репозиторієм, то можна побачити, що всі моделі демонструють схожі тенденції в різних бібліотеках.
Тим не менш, проблеми, які вирішуються кожною моделлю, не обов'язково сильно перетинаються. Наприклад, в установці оракула Claude 2 і SWE-Llama 13b працюють порівняно, вирішуючи 110 і 91 екземпляр на модель відповідно.
**Складність залежить від довжини контексту. **
Моделі можуть бути попередньо навчені на довгих послідовностях коду, але зазвичай вимагають генерації однієї функції за раз і надають фреймворк з обмеженим контекстом для визначення проблеми.
Як було показано, ви можете побачити, що продуктивність Claude 2 значно погіршується зі збільшенням загальної довжини контексту, що також можна спостерігати в інших моделях.
Навіть якщо збільшення максимального розміру контексту BM25 покращить відкликання відносно файлів Oracle, продуктивність все одно знизиться, оскільки модель просто не зможе знайти проблемний код у величезному тезаурусі.
У таблиці 7 наведено результати моделі за датою для ПР, створених до або після 2023 року в налаштуваннях пошуку «оракул».
Для більшості моделей, за винятком GPT-4, різниця в продуктивності до або після цієї дати невелика.
LLM не замінює програмістів, але може прискорити робочі процеси
Деякі користувачі мережі покладають надії та сподівання на майбутнє "універсальної моделі".
Правильно, ось що я кажу. Універсальна модель недостатньо хороша, щоб мати достатньо широку довжину контексту, щоб писати код самостійно, за винятком відносно коротких фрагментів коду.
Але я думаю, що це лише питання часу. Я можу передбачити, що в найближчому майбутньому універсальна LLM зі спеціальною підготовкою стане дуже професійною моделлю.
Замість того, щоб звільняти співробітників, щоб заощадити гроші, дозвольте розробникам досягати великих результатів із шаленою швидкістю!