В чём смысл

Промпт-инжиниринг – новое направление в сетевом бизнесе, которое уже постепенно заполняет web-пространство. Что это и почему теперь так актуально? Прежде всего стоит уточнить, что под данным названием заключается вполне банальная задача: грамотное составление ТЗ нейросети. Например, не так важно, чего вы хотите, как то, чего вы хотите конкретно. Человек, который не разбирается в архитектуре своего проекта, не сможет составить ТЗ для внедрения новых функций. Значит, ключевым условием является знание мелких аспектов своей деятельности (то, что ещё обычно называют профессионализмом). Но какие ещё важные моменты стоит учитывать при работе с нейросетью?

В своём блоге уже рассказывал о том, как правильно заниматься масштабированием IT-продукта через работу с нейросетью. Но через время было решено, что на моей страничке должно быть опубликовано небольшое пособие именно по промпт-инжинирингу, поскольку использовать нейросети для решения небольших или рутинных задач начал достаточно давно, вероятно, с самого их появления, потому знаю мелкие моментики, не имеющие, на мой субъективный взгляд, достаточной огласки в сети.

Для начала стоит разобраться с тем, что именно такое нейросеть, так как для большинства пользователей ИИ – это некоторая шайтан-машина, которая якобы знает всё. Объясню крайне поверхностно и простым языком, но так, чтобы было понятно даже тому, кто к сфере IT не прикасался за жизнь: нейросеть – это очень хороший парсер (от слова «parsing» – анализ, разбор), учащийся/разбирающий огромные массивы данных с целью запоминания порядка идущих в них символов. Например, если в 10 загруженных в нейросеть статьях сказано, что «2 + 2 = 4», то нейросеть запомнит данную комбинацию и будет выдавать после «2 + 2» цифру «4».

Нейросеть сама по себе не понимает абстрактного смысла данных символов, лишь считает, какой порядок наиболее вероятен для дальнейшего формирования ответа на пользовательский запрос. «Под капотом» она строит статистические модели ради выявления закономерностей.

Человек за свою историю написал огромное множество всего, причём в современных реалиях доступ к информации присутствует у практически всех жителей планеты: классическая литература и книги, переведённые с иностранных языков, технические разборы, мануалы, пособия и справочники, учебники и энциклопедии, сборники, в конце концов – интернет-статьи. В общем, что загрузить в данную машину у человечества было сполна. Главной проблемой остаётся невозможность убрать из загруженных массивов, в частности из-за их объёмов, такую мелкую деталь, как... человеческий фактор! Мелкую, но к тому же чрезвычайно значительную в контексте точности предоставляющейся на выходе информации. Суть в том, что среди всех этих данных нейросеть может путаться, порою выдавать какую-то чушь, и без зоркого глаза специалиста отсортировать машинные рекомендации по степени нужности, важности, полезности и в принципе верности, не представляется возможным.

Вы скажете: так пусть другая нейросеть сама проверит эти массивы! Спешу огорчить: какая? Нейросеть учится на человеческих знаниях, а человеческие знания и субъективное видение всегда шли чуть ли не вперемешку, ведь иначе и не могло быть. Абсолютно чистой информации, эдакого эталонного знания, полноценно отделённого от человеческого восприятия, быть не может по определению (так как человеческий разум не может выстраивать абстрактные модели вне собственного восприятия).

Поняв, что нейросеть не всегда выдаёт то, что нужно, люди придумали промпт-инжиниринг. Слоган таков: да, данные неидеальны, но они есть – как тогда сформировать такой запрос, чтобы доля полезной и важной информации в ответе ИИ перевешивала долю нерабочих и бесполезных? Давайте разбираться.

Установление роли и правил

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

Допустим, установление роли. Вы можете сказать странным образом: «Ты программист!». Но это будет бесполезно, ведь если ваш запрос состоит в том, чтобы сгенерировать варианты решения задачи, подразумевающей написание кода, она и так и так будет осознавать необходимость вступления в роль «Программиста» – чтобы написать код для решения соответствующей задачи! В таком случае следует погрузить ИИ в детали: «Ты программист, который занимается добавлением функции X в проект Y с такой-то целью». Тогда нейросеть будет понимать общую картину. Я не говорю раскрывать публичной модели всю структуру проекта, лишь о надобности небольшого погружения её в контекст выполняемой задачи, чтобы она привязала варианты к имеющемуся контексту и не выходила за его рамки.

Например, вместо «Ты программист, и тебе нужно... (описание задачи)» можно написать «Ты – разработчик веб-приложения, (далее краткое описание проекта), и тебе необходимо представить 3-4 варианта решения задачи... (описание задачи)». Во втором случае роль определяется явно, есть конкретика и небольшое погружение в контекст.

Теперь про правила. Недостаточно сказать нейросети, что она должна делать – нужно сказать ей, чего она делать точно не должна. В каждом проекте со сложной внутренней архитектурой есть определённый набор методов, которыми не стоило бы пользоваться в том или ином случае. Например, если сохранение данных идёт в файл «Settings», то не совсем понятна необходимость наличия для какого-то отдельного элемента глобальной переменной в Автозагрузке. Нужно не просто погрузить ИИ в часть контекста (разумную часть), но и объяснить, почему те или иные методы решения не подойдут точно, дабы та отыскала альтернативы.

И самое важное, что многие упускают – формат ответа. Суть в том, что нейросети надо объяснить, в каком именно формате вам нужен ответ. Если нужна таблица – запросите таблицу. Если нужно лишь показать примеры, как и где можно исправить код для решения той или иной задачи – сказать об этом прямо и чётко. Так машина будет понимать, что от неё хотят, и не станет тратить ресурсы на бесполезные задачи (например, на формирование целостного кода, когда вам нужно только пояснить некоторые аспекты и перебрать различные решения).

В общем, цепочка выглядит так: погружаем ИИ немного в контекст проекта (здесь можно обойтись и просто общими фразами), потом задаём ей правила и рамки, в которых она должна работать, а после объясняем, какой именно формат ответа на выходе вы от неё ожидаете. Только в таком случае вы получите наиболее подходящий результат. Но здесь есть моментик: данный результат стоит перепроверить, где-то править, а в целом рекомендуется запросить от ИИ не одно, а сразу несколько решений для сравнения таковых.

В общем-то, стоит вести диалог: уточнять, переспрашивать, может даже работать сразу из нескольких окон поочерёдно, чтобы иметь полное представление. Разумеется, в случае чего нужно требовать от нейросети правок, хотя зачастую всё равно при внедрении в проект придётся самостоятельно его местами редактировать. Также можно предложить нейросети объяснить логику рассуждений, как она пришла к тем или иным выводам, опять же ради более полного понимания процессов, что будет критически важно в долгосрочной перспективе.

Также можно ограничить количество символов на выходе, либо же потребовать от нейросети ответа в одном либо двух абзацах, если вам нужно быстрое понимание без особого погружения (например, вы внезапно забыли за что отвечает участок кода, и такое бывает). Конечно же указать на специфику проекта (допустим, версию ПО), но то и так понятно. В общем, возможностей множество, и если вкратце – пишите чётко, понятно и по делу.

Отсутствие неопределённых объектов

А здесь самая жаркая тема. Если то было введение, то это – то, что отличает эту статью от миллионов других. Казалось бы, тема животрепещущая, но никто её так и не разобрал. Плохо, а надо было бы. Суть в том, что люди почему-то забывают, что нейросеть – робот, а не человек, и не имеет собственного профессионального видения, абстрактного мышления, личного понимания вещей. Проще говоря да – нейросеть воспринимает всё буквально, так, как написано, и никак иначе. Что ввели, то и вывела.

Здесь кроется главная проблема. Если написать в запросе «сделай это, переделай то», либо как-то иначе использовать, назовём это, неопределённые объекты (этот, тот, это, то), то получится на выходе, чаще всего, неведомый бред. Потому что под «этим» и «тем» может скрываться вообще всё, что угодно, упомянутое вами ранее, а не имея личностного опыта ИИ никак не сможет догадаться, что конкретно нужно на выходе.

Поэтому предлагаю следующую схему: вместо того, чтобы объяснять нейросети порядок в один абзац, что неминуемо приведёт вас к использованию так называемых неопределённых объектов, следует формировать запрос в виде последовательности. То есть буквально числами: 1. задача первая, 2. задача вторая, N. задача N, т.д. Таким образом нейросеть будет понимать: А. последовательность, Б. объекты, с которыми следует взаимодействовать, поскольку они будут строго определены.

Ну и разумеется всегда строго определяйте объекты. Нейросеть не осудит вас за то, что вы слишком много раз повторили его название. Это тот самый случай, когда вместо неопределённого «его», «того», следует использовать конкретный идентификатор.

Но конкретика спасает и от обратной ситуации. Суть в том, что как раз из-за статистических закономерностей ИИ может и додумать! Проблема одна: додумает она так, что ошибок станет только больше. Потому необходимо учитывать: нейросеть читает запрос буквально, но порою может додумывать то, что не имело должной конкретики от пользователя. Потому конкретизируем, составляем запросы под машину.

Небольшой юмористический пример. Увидел пост, где описывалось, «Стоит ли подходить знакомиться с девушкой с кольцом». Автор явно давно не перепроверяет, что именно ему выдаёт нейросеть и слепо публикует всё подряд. Суть в том, что явно подразумевалось, что кольцо должно быть у девушки – то есть статья должна была поведать, почему не стоит подходить знакомиться с помолвленными девушками, и то объективно.

Вот только нейросеть поняла это иначе и написала статью о том, стоит ли подходить знакомиться к девушке с кольцом у себя – причём, в руках, в виде подарка. Разумеется, получился абсурд, но нейросеть зашла дальше и начала описывать, с каким конкретно кольцом точно не стоит подходить к женщине, а какое кольцо на мужчине – только подчеркнёт его статус и серьёзность намерений! Сюр высмеяли в комментариях. Не знаю, было ли это специально задумано, но подозреваю, что всё-таки нет и это был классический и, главное, показательный кейс очень и очень плохого промпт-инжиниринга.

Вывод

Я самолично видел ситуацию, когда плохое написание промпта убивало проекты или делало их менее привлекательными. Было две команды, обе делали образовательный сайт, обе использовали ИИ, но в одной был человек, понимающий в составлении запросов и масштабировании в целом, а во второй – такого специалиста попросту не было. Вторая команда выкатила сырой продукт, менее яркий и с гораздо меньшим функционалом, тогда как первая команда представила чудесный сайт с огромным количеством возможностей, красивым дизайном и уникальными фишками.

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

Полагаю, есть смысл заострить внимание на слове «консультативную». Порою нейросеть не стоит слушать абсолютно, она должна быть помощником программиста (либо любого другого специалиста), а не наоборот, и любую предоставленную информацию очень важно перепроверять, благо доступ к информации никогда ещё не был таким простым и удобным, как сейчас.