С приходом генеративных текстовых моделей, таких как ChatGPT, мир разработки программного обеспечения сталкивается с новыми вызовами и возможностями. В этой статье мы рассматриваем семь основных рекомендаций для создания библиотек и фреймворков, которые максимально облегчат взаимодействие пользователей ваших продуктов с генеративными моделями и улучшат качество генерируемого кода. Применение этих рекомендаций поможет разработчикам адаптироваться к новому миру, где генеративные модели уже становятся неотъемлемой частью процесса разработки.
-
Соблюдать обратную совместимость Вообще это был хороший совет и без chat gpt, но теперь он актуален вдвойне. Если раньше в вашей библиотеке для указания того что хэндлеру надо обрабатывать функцию асихронно использовали декоратор @handle_async, а теперь вы решили просто передавать аргумент async=True, то будте готовы что ChatGPT с большой долей вероятности не прочтет ваши Release notes, а продолжит отвечать "по старому", опираясь на большое число использований на github и ответов на SO. Таким образом начальная проработка архитектуры библиотеки становится значительно более важной задачей, так как в будущем, нарушать обратную совместимость будет все сложнее и сложнее.
Использовать очевидный нейминг. Если в вашей нише есть несколько решений, постарайтесь сделать так, что бы нейминг как минимум основных методов и классов был одинаковым, так как ChatGPT сложно понять использование какой именно библиотеки разработчик от него ждет. Например, если есть общепринятый стандарт - model.get_feature_importance() для получения важности фич в некоторой модели, постарайтесь не городить огород из model.features.importance() или model.feature_importances_ (пример CatBoost XGBost), может быть архитектурно такая структура данных и является более правильной, но тогда вы столкнетесь с тем, что Copilot будет выдавать неверный код, аналитикам, которые используют ваши решения.
Сделайте документацию более примероориентированной Очень подробно расписывать какие сущности есть в вашей библиотеки, что они делают и как взаимодействуют между собой, может быть очень полезно для опытных разработчиков, но нейросетям проще просмотреть тысячи примеров использования кода, что бы давать релевантные ответы
-
Добавьте тайпхинтинги Может для обычных программистов, указать что user_id во все методы вашей библиотеки нужно передовать как строку (как int/как объект UserID/как число с floating point)) где-то в начале документации было бы норм, но нейронкам, таким как Copilot итп(которые анализируют всю вашу среду разработки) будет намного проще разобраться с кодом, если вы явно укажите user_id: str . Разумеется это актуально только для нестроготипизированных языков)
Больше текста, меньше картинок Нейросети на данном этапе развития не особо могут разбираться с картинками, поэтому в документации следует сделать опору на текст. Схемы и графики вставлять тоже можно, но сделайте так, что бы текст из них можно было копировать (то есть их нужно рисовать средствами HTML+CSS, а не вставлять картинки из фотошопа)
Обширный getting started Если вы разрабатываете довольно нисшевое решение, и понимаете что крупные модели не смогут впитать в себя умение им пользоваться, сделайте подробный копифрендли getting started, что бы перед задаванием вопросов его можно было бы скормить нейросети самому. Новые текстовые модели (например Claude-instant-100k) могут воспринимать до 100к токенов (~100к слов) за запрос (для примера ВСЕ произведения, написанные А.С. Пушкиным содержат ~900к слов), так что ваш getting started модель спокойно скушает и сможет отвечать на некоторые вопросы разработчиков.
-
Документация на английском языке Вроде сейчас это уже норма, даже если вы пишете какой-то локальный продукт (например библиотеку для визуализации карт мос. метро), но все равно регулярно натыкаюсь на неанглийскую документацию. Модели намного охотнее кушают английский текст и тратя намного меньше токенов, и генерируют намного более релевантные ответы. К тому же английский язык очень хорошо подходит для написания технических текстов, благодаря прямому порядку слов, отсутствию падежей и родов.
Интересно ваше мнение по этому вопросу, насколько важно делать "GPT-ориентированные интерфейсы?