Переклад: Чому великі мовні моделі насправді не можуть створювати програмне забезпечення Автор: Конрад Ірвін Одна річ, на яку я витрачаю багато часу, — це інтерв'ю з інженерами-програмістами. Це, очевидно, складне завдання, і я не смію сказати, що у мене є якісь хитрощі; Але це дало мені час подумати про те, що робить ефективний інженер-програміст. Основний цикл програмної інженерії Коли ви подивитеся на справжнього знавця, то побачите, що він завжди виконує такі дії в циклі: * Побудувати ментальну модель потреб. * Напишіть (сподіваюся?!) ) коду, що реалізує вимоги. * Побудуйте ментальну модель того, як насправді поводиться ваш код. * Знайдіть різницю між ними, а потім оновіть код (або вимогу). Існує багато способів виконання цих кроків, але найцікавіше в ефективних інженерів — це їхня здатність будувати та підтримувати чіткі ментальні моделі. Як працюють великі мовні моделі? Справедливості заради варто сказати, що великі мовні моделі досить добре справляються з написанням коду. Вони також добре справляються з оновленням коду, коли ви вказуєте на проблему. Вони також можуть робити все те, що робив би справжній інженер: читати код, писати і запускати тести, додавати логи і (імовірно) використовувати налагоджувач. Але чого вони не можуть зробити, так це зберегти чітку ментальну модель. Великі мовні моделі потраплять в нескінченну плутанину: вони будуть вважати, що код, який вони пишуть, дійсно придатний для використання; Коли тест не вдається, вони можуть лише здогадуватися, чи це фіксований код виправлення, чи виправлений тест; Коли вони розчаровуються, вони просто вирізають все і починають спочатку. Це повна протилежність тому, що я очікував би від інженера. Інженери-програмісти тестують під час роботи. Коли тест не вдається, вони можуть використовувати свою ментальну модель, щоб вирішити, чи виправляти код або тест, або зібрати більше інформації, перш ніж прийняти рішення. Коли вони відчувають розчарування, то можуть попросити про допомогу, спілкуючись з людьми. Хоча вони іноді видаляють все і починають спочатку, це вибір, який робиться після більш чіткого розуміння проблеми. Але це буде незабаром, чи не так? Чи зміниться це в міру того, як моделі стануть більш функціональними? Пе́вно?? Але я думаю, що це вимагає кардинальної зміни в способі побудови та оптимізації моделей. Для програмної інженерії потрібні моделі, які є чимось більшим, ніж просто генерація коду. Коли людина стикається з проблемою, вона здатна тимчасово відкласти весь контекст і зосередитися на вирішенні поставленої проблеми, а потім повернутися до великої проблеми. Вони також можуть перемикатися між загальною картиною та мікродеталями, тимчасово ігноруючи деталі, щоб зосередитися на цілому, і копатися в частинах, коли це необхідно. Ми не стаємо більш продуктивними, просто запихаючи більше слів у наше «контекстне вікно», це тільки зведе нас з розуму. Незважаючи на те, що ми можемо працювати з великою кількістю контексту, ми знаємо, що ці генеративні моделі в даний час мають кілька серйозних проблем, які безпосередньо впливають на їх здатність підтримувати чіткі ментальні моделі: * Контекстуальне упущення: моделі не вміють виявляти пропущену контекстуальну інформацію. * Упередження нещодавності: вони схильні до сильного упередження нещодавності під час роботи з контекстними вікнами. * Галюцинації: вони часто «фантазують» про деталі, яких не повинно бути. Ці проблеми можуть бути непереборними, і дослідники працюють над тим, щоб додати пам'ять до моделей, щоб вони могли розвивати ті ж навички мислення, що і ми. Але, на жаль, поки що вони (вийшовши за межі певного рівня складності) не можуть толком зрозуміти, що сталося насправді. Вони не можуть створювати програмне забезпечення, тому що не можуть підтримувати дві схожі «ментальні моделі» одночасно, з'ясовувати відмінності та вирішувати, оновлювати код чи оновлювати вимоги. І що тепер? Очевидно, що великі мовні моделі корисні для інженерів-програмістів. Вони швидко генерують код і чудово інтегрують вимоги та документацію. Для деяких завдань цього достатньо: вимоги досить зрозумілі, завдання досить прості, щоб їх можна було вирішити за одну ніч. З огляду на це, для будь-якого завдання певної складності вони не можуть підтримувати достатній контекст достатньо точно, щоб виконати ітерацію, щоб нарешті отримати життєздатне рішення. Як інженер-програміст, ви все одно несете відповідальність за те, щоб вимоги були чіткими, а код дійсно виконував те, про що він заявляє. У Zed ми віримо в майбутнє, де люди та агенти штучного інтелекту зможуть створювати програмне забезпечення разом. Тим не менш, ми твердо впевнені (принаймні поки що), що ви є водієм за кермом, і що великі мовні моделі – це лише ще один інструмент у вас під рукою.