Від нечіткого до точного: вдосконалення одного запиту за три ретельні кроки

Більшість слабких результатів від ШІ походять не від самої слабкої моделі, а від запиту, який змушує модель припускати відповідь. Найшвидший спосіб це побачити — взяти один запит та поступово його покращувати, спостерігаючи, як кожна зміна усуває елементи випадковості. Нижче одне повсякденне завдання проходить через три версії, і в кінці ви отримаєте шаблон, який дозволить перетворювати власні часто використовувані запити на такі, чиї результати потребують мінімальної або зовсім жодної корекції.

Завдання протягом усього процесу: скласти пост у LinkedIn з оголошенням про оновлення продукту.

Етап один: запит у тому вигляді, як його зазвичай пишуть

Перша версія — це та, яку надсилає майже кожен.

Write a LinkedIn post about our new feature launch.

Тут немає нічого неправильного, але майже нічого не вказано. Немає ролі, яку має виконувати модель, немає опису функції, немає цільової аудиторії, немає тону та формату. Єдині позначки — це „пост у LinkedIn“ та „випуск функції“, тому модель заповнює кожну прогалину своїми найбезпечнішими, найзагальнішими стандартними параметрами. Результатом є витончений корпоративний текст, який може оголосити про будь-який продукт.

Другий етап: надання фактів

Друга версія повідомляє моделі про те, що насправді сталось.

Write a LinkedIn post about our new feature launch. We just added dark mode to our app, and users have been asking for it for months. Keep it casual.

Це справжнє покращення. Тепер модель знає, що йдеться про режим темного кольору, і що користувачі давно цього хотіли, а формулювання „зберегти неформальний стиль“ допомагає уникнути вигляду прес-релізу. Проте все ще бракує чітко визначеного автора, обмежень щодо формату та чіткої мети, окрім простого „написати пост“. Тому модель все ще мусить вирішувати, наскільки довгим має бути текст, чи додати заклик до дії та в якому стилі його написати.

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

Третій етап: додавання ролі, мети, формату та обмежень

У фінальній версії запит розділяється на дві частини. Спочатку вказується роль, яка визначає стиль тексту:

Act as a founder writing a personal, low-key LinkedIn update, not a marketing announcement.

Далі йде структурований опис, який включає контекст, мету, формат та чітко визначені виключення. Він позначений як звичайний текст, а не YAML; розміщення кожної позначки на окремому рядку полегшує аналіз розділів.

Context: We just shipped dark mode after users requested it for months. This is a small update, not a major launch, so it shouldn't be hyped up.Objective: Announce the update in a way that feels like a genuine update from a builder, not corporate copy, and invite people to try it and share feedback.Format: Under 100 words. No emojis. End with a direct, casual question rather than a call to action button.Constraints: Do not use the words "excited," "thrilled," or "game-changer." Do not use hashtags.

Перевага полягає не просто у тому, що запит став довшим. Кожна неоднозначність, яка залишилася після другого етапу, тепер усунута: модель знає, хто говорить, якого тону слід уникати, обмеження щодо кількості слів, як завершувати текст та які слова та хештеги заборонені. Коли майже немає чого здогадуватися, майже немає можливостей припуститися помилки.

Особливу увагу зверніть на негативні обмеження. Вказівка заборонених слів, таких як „збуджений“ чи „гейм-чейнджер“, часто є найефективнішим способом усунути кліше, які роблять створений текст впізнаваним, оскільки це безпосередньо впливає на найімовірніші стандартні параметри моделі.

Чому другий крок має більше значення, ніж перший

Перехід від першого до другого етапу додав контекст. Перехід від другого до третього етапу додав структуру: роль, чіткий формат та обмеження щодо того, чого слід уникати. Другий крок зазвичай має більший вплив, ніж очікують люди, оскільки ці два елементи виконують різні функції. Контекст повідомляє моделі, що є правдою. Структура показує їй, як має виглядати хороший результат.

Ця різниця також впливає на те, куди спрямовані ваші зусилля. За допомогою запиту другого етапу ви зазвичай коригуєте форму результату після його отримання: скорочуєте довжину, видаляєте зайві елементи, переписуєте кінець. За допомогою запиту третього етапу ви заздалегідь описуєте бажану форму, тож редагування майже не потрібне. Якщо ви хочете більш детальну шаблон для систем виробництва, перегляньте наш семишаровий фреймворк для запитів до LLM.

Є один момент, про який варто пам’ятати: не кожен запит заслуговує на повну обробку. Для тимчасових запитань достатньо другого етапу. Структурована версія є корисною для запитів, які ви використовуєте багаторазово, ділитеся з командою чи на які покладаєтесь для тексту, призначеного для широкої аудиторії.

Застосуйте цю схему до ваших власних запитів

Виберіть запит, який ви надсилаєте регулярно, такий, який можете майже запам’ятати, та повторіть цю вправу:

• Спочатку додайте контекст: факти, які модель не може дізнатися сама.
• Додайте роль, яка визначає голос чи точку зору.
• Вкажіть формат: довжину, структуру та те, як має закінчуватися результат.
• Додайте один-два чіткі виключення: слова, стилі чи елементи, які потрібно пропустити.

Зазвичай перші два варіанти все ще потребують редагування, тоді як третій вже майже готовий.

Ключові висновки

• Простий запит змушує модель заповнювати прогалини загальноприйнятими значеннями за замовчуванням.
• Контекст підвищує точність, але не визначає, що означає „добре виконано“.
• Роль, завдання, формат та обмеження перетворюють запит на специфікацію.
• Негативні обмеження — це дешевий та ефективний спосіб усунення кліше.
• Інвестуйте у структуру для запитів, які ви використовуєте багаторазово; тримайте спонтанні запитання простими.