Недавно мы разбирались, как писать код с Cursor. Знать про настройку LLM необходимо всем, кто профессионально использует нейросети в своей работе. Предлагаем перевод еще одной статьи Романа Иманкулова. Автор исследовал GitHub Copilot, чтобы разобраться в составлении инструкций по кодированию и, таким образом, повлиять на предложения, которые генерирует Copilot.
В одном из своих проектов я использую соглашение об именовании моделей: у каждого их типа свой суффикс. Подклассы моделей наследуются из базовых классов. Вот было бы здорово каким-то образом сообщить LLM’ке о существующих соглашениях, чтобы та сразу предлагала более точный код!
Похоже, что Copilot наблюдает за работой и в своих предположениях исходит из более широкого контекста — то есть не ограничивается редактируемым файлом. Разработчики Copilot сами подтверждают это, хотя и не указывают явно, что же именно попадает в тот самый контекст. Подробнее с дискуссией можно ознакомиться в статье GitHub Copilot Context Discussion.
Один из примеров техники, которую мы используем сегодня — поиск соответствующего кода в соседних файлах (при этом под «соседними файлами» понимаются вкладки, открытые в редакторе). Представьте, что у вас открыты два файла: в одном определяется класс, в другом — модульные тесты для него. Просматривая оба файла, LLM получает больше контекста, лучше понимает соответствующий код, выдает более качественные предложения.
Итак, идея эксперимента — создать для Copilot четкие рекомендации по кодированию и посмотреть, сможет ли тот им следовать.
Я разработал несколько довольно подробных инструкций о том, как писать модели для одной и той же сущности, но с учетом предназначения: апстрим, базы данных или API. Чтобы убедиться, что мои рекомендации учитываются, я пошел на маленькую хитрость: в качестве маркера включил необычный элемент для добавления в docstring — ROMAN LOVELY [TYPE] MODEL.
Правила именования моделей.
Протестированная версия: GitHub Copilot 1.4.5.4049 на PyCharm (19 декабря 2023 г.).
Итак. Ниже — что работает, а что нет.
Создавать инструкции по кодированию в Markdown (README. Md, guidelines. Md и тому подобные), после чего открывать их в соседней с кодом вкладке. Нет, к сожалению, в качестве контекста Copilot принимает только код.
Интегрировать инструкции в строковую константу Python, после чего импортировать ее в файле с кодом. Нет, Copilot не пытается анализировать код и следовать импортам — это было бы слишком.
То же, что и в предыдущем случае, но оставлять такой файл открытым в соседней вкладке. Да, строки и docstring модулей работают (я решил придерживаться docstring).
Ниже — как выглядят предложения Copilot. На скриншотах видно, что открыто две вкладки. Первая, readme.py, как раз и содержит рекомендации по кодированию, сохраненные в docstrings модуля Python.
Предложение модели API.
Предложение модели базы данных.
Предложение модели Upstream.
Пара примечаний к скриншотам
- Иногда приходится явно указывать имя файла в первой строке кода, чтобы помочь Copilot выбрать правильный набор инструкций.
- При создании модели базы данных, несмотря на четкое соблюдение инструкций, Copilot не добавил маркерную строку.
Ничего удивительного в этом нет. Хорошо известно, как сложно заставить LLM точно следовать инструкциям. Как правило, чем больше контекст — тем выше вероятность того, что модель что-то забудет.
Наблюдения
- Количество открытых вкладок влияет на качество исполнения рекомендаций — точные инструкции readme разбавляются нерелевантным контекстом из других файлов. Для рассмотренного метода закрытие ненужных вкладок в IDE — существенная помощь нейросети в генерации лучших предложений.
- Если открытых вкладок слишком много, не исключено, что Copilot берет в контекст только часть из них (причем даже не целиком). В таком случае инструкции будут разбавлены настолько, что полностью исчезнут из контекста. Единственный способ сохранять их работоспособность — закрывать ненужные вкладки.
Автор: oneastok
