Основи Prompt Engineering: Практичний глосарій

Prompt engineering — це практика написання вхідного тексту, який змушує мовну модель видавати той результат, який вам потрібен. Це знаходиться десь між написанням тексту та налагодженням: ви не пишете код у традиційному сенсі, але ви тестуєте гіпотези про те, як модель інтерпретує інструкції, та ітеруєте, коли вона помиляється.

Що насправді таке prompt

Prompt — це все, що ви надсилаєте модель перед тим, як вона генерує відповідь — інструкції, контекст, приклади та саме питання або завдання. Більшість сучасних моделей чату поділяють це на ролі: системне повідомлення (встановлює поведінку та обмеження), повідомлення користувача (саме завдання) та іноді повідомлення асистента (попередні повороти або приклади). Якщо ви використовуєте API на кшталт OpenAI або Anthropic, ви встановите їх явно в коді. Якщо ви використовуєте інтерфейс чату, системний prompt часто приховується або встановлюється один раз на початку розмови.

Чому одне й те саме питання отримує різні відповіді

Мовні моделі передбачають наступний токен на основі всього, що було перед ним, включаючи вашу фразування, порядок слів і навіть пунктуацію. Запитайте "Поясни рекурсію" — отримаєте звичайну підручникову відповідь. Запитайте "Поясни рекурсію молодому розробнику, який розуміє цикли, але не рекурсію, використовуючи один приклад на Python з базовим випадком і рекурсивним випадком" — отримаєте щось набагато корисніше. Специфічність вашого введення безпосередньо впливає на специфічність результату. Це головне усвідомлення для початківців: модель не читає ваші думки, вона розпізнає закономірності за вашими словами.

Основні методи, які варто вивчити спочатку

Zero-shot prompting означає прямий запит без прикладів: "Напиши regex, що підходить під номери телефонів США." Це добре працює для звичайних, чітко визначених завдань.

Few-shot prompting означає надання моделі одного чи більше прикладів шаблону введення/виведення, який вам потрібен, перед тим як просити її продовжити шаблон. Якщо ви хочете, щоб модель класифікувала квитки підтримки за категоріями, показ їй трьох позначених прикладів спочатку дасть більш послідовні результати, ніж просто описання категорій прозою.

Chain-of-thought prompting просить модель міркувати крок за кроком перед тим як дати остаточну відповідь, часто буквально додаючи "think step by step" або просячи її показати свою роботу. Це допомагає з математикою, логікою та багатокроковими завданнями, хоча це також збільшує використання токенів і довжину відповіді.

Role prompting призначає моделі персону — "Ти старший інженер з безпеки, який переглядає цей код на вразливості" — що може змінити тон, лексику та тип деталей, які вона пріоритизує. Це не надає моделі нових можливостей, але якорює стиль її результату.

Структура важливіша за кмітливість

Початківці часто припускають, що prompt engineering — це про пошук чарівної фрази. На практиці структура перемагає кмітливість майже завжди. Розбийте ваш prompt на чіткі частини: контекст, завдання, обмеження та формат. Наприклад:

Контекст: Ви переглядаєте додаток Python Flask для аудиту безпеки.
Завдання: Визначте ризики SQL injection у коді нижче.
Обмеження: Позначте тільки проблеми в маршрутах /login та /search.
Формат: Поверніть нумерований список з номером рядка та однією реченням пояснення.

Такий явний формат зменшує двозначність і полегшує парсування результатів програмно, якщо ви ланцюжете prompts разом у скрипті.

Звичайні помилки на початку

Часто допускається помилка — невизначеність, замаскована під стислість — запитання "зроби це краще" без визначення того, що означає "краще" (швидше? зрозуміліше? безпечніше?). Інша помилка — закидання одного prompt у п'ять не пов'язаних завдань, що зазвичай видає поверхневі відповіді на всі п'ять замість солідної відповіді на одне. Початківці також забувають, що моделі не мають пам'яті між окремими викликами API, якщо ви явно не передаєте назад історію попередньої розмови, що спіткає людей при побудові чегось із станом.

Тестування та ітерація як інженер

Третуйте prompts як код, який ви версіонуєте та тестуєте, а не як одноразовий текст, який ви викидаєте. Ведіть журнал варіацій prompt та їх результатів, особливо для всього, що ви повторно використовуватимете в production, наприклад бот служби підтримки клієнтів або асистент перегляду коду. Невеликі змі́ни формулювання — "summarize" проти "summarize in exactly three bullet points" — можуть дати значущо різні результати, і єдиний спосіб дізнатися, що працює для вашого випадку — це запустити порівняння самостійно замість припущення.

Де це вписується в розробку реальних речей

Як тільки prompts стають надійними, наступний крок зазвичай — програмне використання: виклик API з налаштованими параметрами temperature та max_tokens для вашого завдання, додавання логіки повторних спроб для неправильно сформованих результатів та валідація відповідей перед тим як вони потрапляють до користувача. Це там, де prompt engineering починає накладатися на звичайну дисципліну програмного інженерування, і це хорошої точка для переходу від експериментування в вікні чату до написання реальних скриптів.

Якщо ви хочете йти далі, перегляньте сегменти Korra Studio про роботу з LLM APIs у Python та про розробку невеликих AI-powered інструментів з нуля.