Настраиваем контекст Copilot: что работает, а что нет

Недавно мы разбирались, как писать код с Cursor. Знать про настройку LLM необходимо всем, кто профессионально использует нейросети в своей работе. Предлагаем перевод еще одной статьи Романа Иманкулова. Автор исследовал GitHub Copilot, чтобы разобраться в составлении инструкций по кодированию и, таким образом, повлиять на предложения, которые генерирует Copilot.

В одном из своих проектов я использую соглашение об именовании моделей: у каждого их типа свой суффикс. Подклассы моделей наследуются из базовых классов. Вот было бы здорово каким-то образом сообщить LLM’ке о существующих соглашениях, чтобы та сразу предлагала более точный код!

Похоже, что Copilot наблюдает за работой и в своих предположениях исходит из более широкого контекста — то есть не ограничивается редактируемым файлом. Разработчики Copilot сами подтверждают это, хотя и не указывают явно, что же именно попадает в тот самый контекст. Подробнее с дискуссией можно ознакомиться в статье GitHub Copilot Context Discussion ^[1].

Один из примеров техники, которую мы используем сегодня — поиск соответствующего кода в соседних файлах (при этом под «соседними файлами» понимаются вкладки, открытые в редакторе). Представьте, что у вас открыты два файла: в одном определяется класс, в другом — модульные тесты для него. Просматривая оба файла, 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 берет в контекст только часть из них (причем даже не целиком). В таком случае инструкции будут разбавлены настолько, что полностью исчезнут из контекста. Единственный способ сохранять их работоспособность — закрывать ненужные вкладки.