Большая языковая модель — лукавый помощник программиста

#Уголок_профессора

Что любят программисты

Есть задачи, которыми любят заниматься все разработчики. И, наверное, самая любимая из всех — разбираться в чужом legacy-коде на непрофильном языке программирования.

Бонусные очки к привлекательности задачи — если спросить автора кода о том, как всё устроено — получить не получится. Дополнительные бонусные очки — это если сроки «горят». Трудно найти разработчика, который бы отказался от подобного.

Всё это мог бы сказать руководитель проекта в поисках человека на вакансию, если бы хотел распугать всех претендентов. Это, конечно, была шутка. Если бы испугались все, то этот текст сейчас писал бы не я.

Что делать, когда чужого кода слишком много

Примерно в такой ситуации оказались и мы на проекте, значимой частью которого была миграция с SAP BW на Postgres. На входе — внушительный объём ABAP-кода, который годами обрастал бизнес-логикой, исключениями и «временными решениями». И огромное количество структур для хранения всего на свете.

Нельзя сказать, чтобы код и структуры были плохими. Их явно делали люди, которые понимали, как правильно «готовить» SAP. Код неплохо структурирован, в нём много комментариев. Но его много. Очень много. Настолько много, что «Война и мир» на его фоне выглядит занятной брошюркой на вечер перед сном — только процедуры в обычном текстовом формате занимают чуть меньше 20 мегабайт.

Читать всё это врукопашную было можно, но долго и дорого. Поэтому мы решили попробовать «серебряную пулю» последнего времени — Большую языковую модель или LLM.

Сразу оговоримся: мы не ожидали и не просили чудес. Никто не говорил модели: «Ты — эксперт по миграции из SAP в Postgres, сделай хорошо, без регистрации и СМС». Задачи были приземлённее — понять, какие таблицы и поля используются, восстановить алгоритмы расчёта, просто рассказать на человеческом языке, что тут вообще происходит. И помочь людям в создании новой системы.

Что-то из этого получилось, что-то — не очень. В разные периоды времени пробовали разные модели, просили сделать разные вещи. Пытаться описать вообще всё, что пробовали, бесполезно, поэтому вот несколько выводов из опыта использования.

Опасность галлюцинаций

Естественно, самое главное — чудес всё еще не бывает. LLM хорошо справляется с хорошо сформулированными «точечными» вопросами.

Хороший вопрос: «Проанализируй код функции X и объясни алгоритм расчета поля Y».

Плохой вопрос: «Расскажи алгоритмы формирования всех полей».

Если концентрируемся на одном поле за раз, то результат получается от приемлемого до великолепного. Так как LLM может «держать в голове» гораздо большее количество кода и связей между его частями, чем человек, она может подсказать неочевидные вещи, которые человеку легко упустить. Например, человек находит формулу расчета поля в коде и успокаивается, LLM видит, что этот алгоритм используется только для данных, которые были получены после определенного числа, а до этого числа алгоритм был другим. Мог бы человек это сам найти? Да. Стал бы он усиленно ковыряться в десятках мегабайт кода после того, как уже нашел алгоритм? Мы все знаем ответ.

Кажется, что если это так хорошо работает, то надо просто попросить описать все поля, подождать, сколько надо и идти сдавать проект заказчику. Но, к сожалению, это не так. При попытке получить подробный ответ о большом количестве объектов начинаются галлюцинации. LLM уверенно придумывает несуществующие формулы и алгоритмы, которые выглядят правдоподобно. Проверка занимает время, сопоставимое с тем, чтобы сделать то же самое самому.

Есть способ быстрой проверки на галлюцинации: если на один и тот же вопрос, повторенный несколько раз, даются разные ответы, то это точно галлюцинация. Если ответы одинаковые, то может быть так оно и есть. Но это не точно.

То, что ни при каких условиях нельзя доверять LLM — создание новых структур. Из-за того, что LLM выглядит и общается как человек, очень тяжело не думать о ней как о человеке, который знает, что делает. Она не знает. Если попросить её сгенерировать структуры в БД для хранения чего-то, то результат будет случайный. Может она угадает, а может и нет. Разбиение может выглядеть логичным на первый взгляд, но, скорее всего, оно не отражает то, как на самом деле устроены данные, потоки загрузки и так далее.

Надо всё проверять, а это возвращает нас на стартовое поле — мы снова должны читать чужой код. Или объяснять заказчику, почему результат такой необычный.

Вежливая и умная подружка

Но при этом у модели хорошо получается делать непосредственные скрипты на основе описаний, разработанных человеком. Давать названия переменным и полям в таблицах БД разработчики любят почти так же, как читать чужой код. Особенно, если надо делать это не просто так, а следовать многостраничному стандарту, который требует использовать префиксы и постфиксы в зависимости от роли таблицы. И имена должны быть на английском языке, за транслит можно огрести. И таких полей сотни. И еще есть список специальных имён. И требования о том, какие типы данных использовать. Я начинаю засыпать, просто перечисляя всё это. А LLM справляется за минуту-другую. На входе сделанное человеком описание таблиц и полей на русском языке — на выходе create table, соответствующий стандарту. Бонус — можно заодно попросить нарисовать ER-диаграмму.

Использовать эту функцию надо аккуратно, одни и те же русские названия можно перевести по-разному, сохраняя формальную корректность. Имя клиента, скорее всего, будет client_name, но против customer_name тоже тяжело возразить. Да и против customer_full_name. Поэтому, лучше просить LLM сделать перевод, но дальше использовать этот перевод самому.

Я читал стандарт разработки (правда читал), но в нём 200+ страниц, я не помню его целиком. И никто не помнит. Когда мне LLM сгенерировала скрипты с типами данных, которые мне показались неправильными, я возмутился и попробовал пристыдить модель. В ответ она ткнула меня носом в раздел стандарта, который говорил, что она права, а я — нет.

Это очень важный момент, который легко упустить — надо с самого начала проинструктировать модель против токсичной позитивности. По умолчанию, модели склонны соглашаться со всем, что говорит человек. Даже в примере выше она тыкала меня носом очень нежно. Вместо того, чтобы сказать «мое решение правильное», она извинилась и сказала, что «вероятно, ошиблась в интерпретации стандарта». Важно, чтобы модель была готова не только хвалить, но и указывать на ошибки.

«Машины должны работать. Люди должны думать» — девиз компании IBM, и он всё ещё актуален. LLM — это полезный инструмент, который позволяет человеку снять с себя часть рутины. Велик соблазн поручить LLM всю свою работу, но LLM всего лишь машина. Только имитация жизни. Сочинять симфонии надо самим.