ИИ агенту не нужен манифест. Требуется четкая и однозначная спецификация. Далее описано, как ее правильно написать.

Недавно мы переписали системный промпт для ИИ секретаря. Предыдущая версия состояла из 450 строк, имела красивую структуру и содержала тщательно продуманные правила — однако она занимала так много контекстного окна, что у ИИ агента оставалось меньше возможностей слушать звонящего! Поэтому, чтобы избежать подобных проблем, в этом блоге — сейчас Часть 1, а затем последует Часть 2 — рассказывается, как перестать писать поэзию и начать писать инструкции. Так что читайте далее, чтобы узнать больше!

Ошибка, которую совершают все сначала

Подобная ошибка не является уникальной. Почти каждый клиент 3CX, впервые редактирующий системный промпт, совершает ту же ошибку: промпт воспринимается как политический документ, юридический контракт или, что еще хуже, как творческое задание.

Ловушка заключается в следующем: поскольку промпты пишутся на английском языке, часто забывается, что это написание кода. Пишутся абзацы. Добавляются прилагательные. Даются определения терминам, которые модель уже понимает. Одно и то же указание повторяется пять раз, потому что кажущется важным.

Модель не читает прозу так, как это делает человек. Каждое слово в промпте стоит контекста, внимания и, зачастую, согласованности. Длинный промпт не означает более тщательный. Как правило, он оказывается хуже.

Данное руководство содержит выводы, полученные при переписывании собственного промпта. Если вы редактируете системный промпт ИИ агента 3CX, прочтите этот текст перед сохранением.

Ловушка английского языка

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

Ниже приведен фрагмент из старой версии нашего собственного промпта:

“The caller’s reason is required before handoff, but it must not be used to identify, narrow, rank, disambiguate, replace, or override the requested destination.”
(“Причина звонка обязательна перед передачей, но её нельзя использовать для идентификации, уточнения, ранжирования, устранения неоднозначности, замены или переопределения запрошенного направления.”)

Безусловно, это предложение грамматически правильное, хорошо продуманное, но почти невозможное для последовательного выполнения моделью во время реального звонка. В нем присутствуют шесть близких синонимов. Два придаточных предложения. Отрицание, обернутое вокруг требования. В результате, к третьему повороту разговора модель интерпретирует его иначе, чем при первом.

В итоге оно превратилось в следующее:

“Do not use information search to decide who should receive a call.”
(“Не используйте поиск информации, чтобы решать, кто должен принять звонок.”)

Одно предложение. Одна инструкция. Ноль двусмысленности. Аналогичное поведение.

Правило первое промпт-инжиниринга: английский язык — это интерфейс, а не жанр. По-прежнему пишутся инструкции. Короткие, декларативные, проверяемые. Соответственно, если предложение читается как фрагмент из документа с условиями обслуживания, его необходимо удалить и попробовать снова.

Перестаньте определять термины для модели

В старом промпте содержалась следующая жемчужина:

“A handoff is any permitted next step executed via one of the actions listed below.”
(“Передача — это любой разрешённый следующий шаг, выполняемый через одно из перечисленных ниже действий.”)

На самом деле, модель знает, что такое передача. Также известно значение слов “transfer”, “voicemail” и “email”. Определять повседневные термины для модели — это привычка, заимствованная из технического письма для людей. В промпте это лишь сжигает токены и создает поверхность для неверной интерпретации моделью.

То же самое относится к церемониальным заголовкам разделов. В старом промпте было:

  • Mandatory Enforcement (Обязательное исполнение)
  • Priority Order (Приоритетный порядок)
  • Base Schema (Базовая схема)
  • Action Selection Rules (Правила выбора действий)

Они читаются так, словно взяты из RFC. При этом они не добавляют никакого поведения. В новом промпте используются такие заголовки, как Style, Routing, Hostility (Стиль, Маршрутизация, Враждебность) — короткие метки, описывающие суть раздела, а не то, насколько серьезно он звучит.

Правило второе: если строка не меняет действий модели, ее следует удалить.

Указывайте один раз

Одна из худших патологий в длинных промптах — появление одного и того же правила в четырех местах. В старой версии фраза “do not hand off if the destination is ambiguous” появлялась с небольшими вариациями в:

  • Destination Ambiguity Rule (Правило неоднозначности направления)
  • Handoff Action Gate (Условие передачи)
  • Directory Rules (Правила каталога)
  • Confidential Output Contract (Контракт конфиденциального вывода)

Каждое повторение немного отличалось. Везде использовались слегка разные формулировки. Человек, читая их, видит четыре версии одной и той же идеи и понимает суть. Модель же, читая их, видит четыре правила — и если они не идеально совпадают, приходится выбирать. Иногда на третьем звонке за день выбор оказывается иным, чем на первом.

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

Прекратите нагромождать запреты

Следует обратить внимание на следующее:

“Do not pick the first result, best result, available result, or most relevant result.”
(“Не выбирай первый результат, лучший результат, доступный результат или наиболее релевантный результат.”)

По сути, это четыре негативные инструкции там, где было бы достаточно одной позитивной. На самом деле это правило означает следующее:

“If lookup returns multiple matches, ask the caller to clarify.”
(“Если поиск возвращает несколько совпадений, попросите звонящего уточнить.”)

Позитивные инструкции указывают модели требуемые действия. Негативные инструкции сообщают, чего следует избегать. В результате остается открытым вопрос о заменяющих действиях — и модель самостоятельно изобретает ответ.

Правило четвертое: предпочтение отдается позитивным инструкциям. Использование “do not” допускается только в тех случаях, когда позитивного эквивалента не существует.

Следите за противоречиями

Это является незаметной угрозой. В старом промпте содержались два раздела, которые при совместном прочтении были непоследовательными:

  • Routing by Reason: когда звонящий называет причину, выполняется обращение к адресной книге для определения места назначения.
  • Routing by Requested Destination: когда звонящий спрашивает сотрудника или отдел, причина для маршрутизации не используется.

Оба утверждения верны. Оба разумны. Однако, будучи выстроенными в длинном промпте с перекрывающимися примерами и усиливающими подправилами, возникает путаница относительно того, какое из них применимо — и эта путаница проявляется в виде непоследовательного поведения, которое клиенту никогда не удается воспроизвести по требованию.

Рекомендуется использовать OpenAI Tokenizer, чтобы увидеть, как модель фактически разбивает промпт на токены. Затем перечитайте промпт так, будто вы ничего не знаете о своём бизнесе: по порядку, без контекста. Если два правила могут правдоподобно применяться к одной ситуации и вести к разным действиям — у вас есть противоречие, даже если вы можете объяснить, почему они формально не конфликтуют.

Правило пятое: промпт считается последовательным, когда никакие два правила не могут одновременно применяться и противоречить друг другу. А не тогда, когда вы можете логически обосновать разницу.

В ближайшие дни будет опубликована Часть 2 этой серии, где будет более подробно рассмотрено, что модель может и чего не может делать. А также дадим советы начинающим инженерам промптов и многое другое. Следите за обновлениями!

Присоединяйтесь к обсуждению

Присоединяйтесь к обсуждению 3CX на специальных форумах для партнеров или клиентов. Подписывайтесь на страницы в X и LinkedIn, чтобы оставаться в курсе последних новостей и релизов функций.