Інженерія запитів: керування ШІ без додаткової налаштуваності

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

Два способи керування моделлю

Тонке налаштування та інжиніринг запитів прагнуть до однієї мети — корисної поведінки моделі — але за протилежними методами.

Тонке налаштування змінює ваги моделі. Використання запитів не торкається ваг, а натомість надає більш чіткі інструкції та контекст, щоб модель могла точніше застосовувати те, що вже знає. Моделі на кшталт систем класу GPT поглинають настільки обширний текст, що багато їхніх можливостей вже існують у прихованому вигляді; запити часто допомагають розблокувати саме потрібну частину цих можливостей. Практичний наслідок — швидкість: команди можуть протестувати зміни в поведінці моделі протягом кількох хвилин, замість того щоб чекати на процес тонкого налаштування.

from openai import OpenAI

client = OpenAI()response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a helpful sentiment classifier. Respond with only 'positive' or 'negative'."},
        {"role": "user", "content": "I loved this movie"}
    ]
)print(response.choices[0].message.content)

Zero-shot vs Few-shot Prompting

Одним із ранніх етапів проектування є вирішення, скільки прикладів, якщо взагалі, показувати перед виконанням справжнього завдання.

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

prompt = """
Classify the sentiment of each review as positive or negative.

Review: "Absolutely fantastic, exceeded expectations!"
Sentiment: positiveReview: "Complete waste of money, broke in a week."
Sentiment: negativeReview: "I loved this movie"
Sentiment:
"""response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": prompt}]
)print(response.choices[0].message.content)

Структура хорошого запиту

Визначення чіткої ролі встановлює тон та погляд на справу. Конкретна інструкція усуває неоднозначності щодо очікуваного результату. Розділення контексту чи вхідних даних від інструкцій допомагає моделі розрізняти їх. Чіткі правила форматування — наприклад, JSON із іменованими ключами — роблять відповіді легшими для обробки, ніж сподівання на послідовний вільний текст. Кілька добре підібраних прикладів можуть ще більше уточнити поведінку моделі при виконанні незвичайних завдань.

Техніки формулювання запитів, які варто знати

Для складніших завдань виділяються кілька підходів:

• Запитування з послідовним мисленням — просите модель обґрунтовувати крок за кроком перед наданням остаточної відповіді; це часто допомагає при розв’язанні математичних задач та багатоетапної логіки.
• Запитування з визначенням ролі — призначте персону („Ви є старшим аудитором безпеки“), щоб сформувати глибину та стиль відповіді.
• Обмеження формату вихідних даних — запитуйте JSON або XML, якщо інша система має обробляти відповідь.

Самоконсистентність — генеруйте кілька варіантів відповідей на одне й те саме запитання та обирайте найпоширеніший результат у разі різниці відповідей.

Коли запитання недостатні

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

До чого це призводить

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

Наступна прогалина — пошук за змістом замість ключових слів, а потім використання отриманого тексту для генерації — належить до сфери ембеддингів та генерації з підсиленням через пошук (RAG).