Чи траплялося вам знайти запит, який добре працював, але раптом переставав давати результат?
Чи доводилося вам знову й знову латати системний запит, намагаючись покращити результати, але зрештою виявляти, що нічого не працює?
Можливо, навчання системного запиту — саме те, що вам потрібно.
Навчання системного запиту (SPL) — новий напрям, що викликає дедалі більший інтерес у спільноті ШІ. У травні його широко популяризував Андрей Карпатий у X.
Навчання системного запиту долає обмеження негнучких і вразливих систем ШІ, що покладаються на статичні системні запити або громіздкі схеми донавчання. Це ще один спосіб забезпечити безперервне навчання систем ШІ.
Перш ніж заглибитися в тему, стисло розгляньмо основи складання запитів.
Розробляючи агента або спеціалізовану модель, спершу потрібно створити два ключові компоненти:
Системний запит
Запит користувача
Системні запити визначають основні правила поведінки моделі. У спеціалізованих рішеннях на основі ШІ вони часто починаються приблизно так:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
Натомість запити користувачів зазвичай містять запитання користувача та іншу доречну інформацію, як-от часовий пояс і вподобання. Запит користувача може мати такий вигляд:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
Після випуску нових моделей провідними лабораторіями ШІ витоки системних запитів стали звичним явищем: користувачі застосовують джейлбрейк до чатботів, щоб розкрити їхні приховані інструкції. Нині популярний репозиторій GitHub збирає чимало таких системних запитів в одному місці. Вони розкривають «секретний складник», який лабораторії ШІ роками вдосконалювали, щоб спрямовувати модель до належної поведінки. Наприклад, нещодавно оприлюднений системний запит GPT-5 (розкритий у ChatGPT) містить близько 6000 слів. Це показує, скільки знань і настанов потрібно закодувати, щоб сформувати поведінку системи.
Такі докладні системні запити зазвичай охоплюють кілька ключових напрямів, зокрема:
Інструкції з пошуку
Визначення інструментів
Уподобання користувача
Інструкції з цитування
Швидкі виправлення відомих проблем
На практиці розробники спеціалізованих систем ШІ вручну й поетапно виправляють системні запити під час тестування та вдосконалення застосунків, здебільшого керуючись оцінюваннями.
До інших способів керувати поведінкою моделі належать:
Тактика складання запитів, зокрема генерація з доповненням через пошук (RAG), яка контролює вміст, що надається моделі
Донавчання (безпосередня зміна базових ваг моделі)
А що, як існує інший спосіб впливати на поведінку моделі? Уявіть систему, яка динамічно навчається й удосконалює власний системний запит, використовуючи раніше згенеровані міркування, плани та стратегії. Для оцінювання результатів вона могла б спиратися як на відгуки користувачів, так і на оцінки за методом LLM як суддя.
Розгляньмо постійну бізнес-проблему, яку ви хочете автоматизувати за допомогою агентної системи. Для ефективних рішень потрібні можливості міркування, що виходять за межі базової автоматизації робочих процесів. У таких випадках до системи ШІ необхідно додати компонент генерування планів. Завдяки цьому система може по-різному працювати з кількома агентами залежно від завдання. Окремі кроки можуть містити інструкції щодо залучення інших агентів для виконання підзавдань або використання інструментів.
Примітка: інструмент агента — це будь-яка зовнішня функція, API або ресурс, до якого агент ШІ може звернутися, щоб вийти за межі роботи з текстом і виконати реальні дії.
Можна «закласти» в системний запит моделі план із логічною послідовністю людських дій, хоча LLM зазвичай потребують конкретніших настанов щодо використання інструментів, форматування результатів та інших вимог. Іноді оптимальна стратегія неочевидна або ж проблема давно не переглядалася, оскільки раніше її вважали розв’язаною. Саме тут стає в пригоді навчання системного запиту (SPL).
SPL поетапно вдосконалює системний запит, додаючи до нього раніше згенеровані стратегії. У міру появи нових проблем система поступово накопичує знання й стає надійнішою. Уявіть це як створення посібника з розв’язання проблем у вашій галузі.
SPL поступово додає до системного запиту висновки з відгуків користувачів. У міру розвитку системи ви можете виявляти повторювані проблеми й узагальнювати їх у принципи вищого рівня.
Докладніше розгляньмо цей процес крок за кроком:
Почніть із запиту користувача, у якому систему просять виконати конкретне завдання.
Якщо система розв’язує лише одну проблему, можна застосувати «жадібний» підхід і вибирати стратегії з найвищими оцінками за попередні запуски. Або ж можна заохотити пошук нових підходів, формуючи вибірку з розподілу, який надає перевагу високо оціненим стратегіям, але час від часу включає й стратегії з нижчими оцінками. Це особливо корисно, коли ви лише починаєте збирати стратегії.
Для систем, призначених для роботи з різними типами проблем, варто додати рівень класифікації або використати вбудовування й косинусну подібність — ті самі методи, які зазвичай застосовують у RAG, — щоб визначати доречні підходи. Це допомагає вибирати стратегії, що відповідають конкретній проблемі, наприклад стратегії для завдань із програмування.
Примітка: вбудовування разом із косинусною подібністю дають змогу виміряти, наскільки тісно пов’язані два фрагменти інформації. Так легше зіставляти документи, запити чи ідеї, навіть якщо вони сформульовані по-різному.
Приклад початкового спрощеного сховища стратегій для розв’язання задач із програмування.
Примітка: наведені тут «початкові стратегії» мають ілюстративний характер. У реальних сценаріях програмування ми вдосконалили б їх додатково. Для вузькоспеціалізованих бізнес-проблем із часом довелося б збирати додаткові відомості.
Generation_id (зворотний порядок) | Тема | Оцінка | Strategy_text | Пояснення |
|---|---|---|---|---|
4 | програмування | 1 | Зрозумійте проблему, обмеження та крайові випадки. Розробіть алгоритм із відповідними структурами даних. Перевірте план на прикладах та інваріантах. Напишіть чистий і зрозумілий код. Удоскональте результат за допомогою рефакторингу, оптимізації та остаточного форматування. Використання інструментів: застосовуючи інструмент, стисло поясніть, навіщо він був потрібен. | Поєднує найсильніші елементи трьох наведених нижче стратегій. |
3 | програмування | 1 | Зрозумійте проблему, обмеження та крайові випадки. Розробіть алгоритм із відповідними структурами даних. Перевірте план на прикладах та інваріантах. Напишіть чистий і зрозумілий код. Удоскональте результат за допомогою рефакторингу, оптимізації та остаточного форматування. | Більш збалансована стратегія, але в ній немає вказівок щодо використання інструментів. |
2 | програмування | -1 | Зрозумійте проблему, обмеження та крайові випадки. Розробіть алгоритм із відповідними даними. Напишіть чистий і зрозумілий код. Використання інструментів: звертаючись до інструмента, стисло поясніть, чому ви його використали. | Краща стратегія, у якій згадано використання інструментів, але її ще можна вдосконалити. |
1 | програмування | -1 | Побіжно ознайомтеся з проблемою. Розв’яжіть проблему. Створіть мінімальний набір тестів. Надішліть будь-який код, який запускається. | Згадує тести, але загалом це слабка стратегія. |
3. Сформувавши вибірку з N стратегій, додайте їх до системного запиту. Так генерування плану спирається на попередні експертні відгуки, а модель не створює плани майже без настанов. Заохочуйте модель «мислити нестандартно» й за потреби додавати кроки, а не просто дослівно копіювати приклади стратегій.
4. Використовуючи динамічно створений системний запит, згенеруйте нову стратегію опрацювання запиту користувача. У результаті цього процесу мають з’явитися додаткові завдання, що покращать кінцевий результат. Мета — творчий підхід: поєднайте найсильніші елементи попередніх стратегій, об’єднайте схожі кроки й за потреби додайте нові корисні кроки.
Примітка: пам’ятайте, що температура — це параметр, який можна змінювати для отримання різноманітніших і менш детермінованих результатів, що корисно для творчих завдань. За ненульової температури кожен згенерований план може відрізнятися.
5. Отримавши результат моделі, оцініть його за допомогою людини або LLM-судді відповідно до конкретних критеріїв, що визначають якісне розв’язання вашої проблеми. Для згаданого раніше прикладу з дозвіллям у Португалії критерії оцінювання можуть бути такими:
Лаконічність (відповідь обсягом не більше одного речення)
Доречність запропонованого заняття
Точність визначення місця
6. На основі цієї оцінки скористайтеся іншою моделлю, щоб удосконалити стратегію. Необов’язковий цикл зворотного зв’язку може враховувати внесок людини й підтримувати спільне вдосконалення. Збережіть удосконалену стратегію у своїй базі даних із належними метаданими для відстеження версій і змін.
То навіщо докладати стільки зусиль? Можна було б перевіряти результати вручну й відповідно коригувати системний запит. Однак потужні моделі міркування здатні вдосконалювати стратегії, використовуючи як контекст результату, так і відгуки людей. Люди легко помічають недоліки простих підходів, але виявляти їх у складних системах, що охоплюють ширше коло проблем, важко й виснажливо.
LLM часто потребують докладних інструкцій і додаткових кроків, щоб зібрати контекстні знання, які люди природно застосовують під час розв’язання проблеми. Кількість потрібних завдань може стрімко зростати, коли система розширюється для роботи з ширшим колом проблем. Наприклад, людина, розв’язуючи задачу з програмування, може інтуїтивно розуміти навколишню кодову базу, тоді як LLM спершу доведеться «прочитати» кілька файлів.
Коли це допомагає: уявіть, що ви керуєте командою підтримки клієнтів, а агент ШІ виконує первинне сортування звернень. Згодом SPL може виявити спосіб категоризації, якого ваша команда не розглядала, і зменшити частку звернень, що потребують ескалації.
Коли це не допомагає: якщо робочі процеси вже визначені нормативними вимогами чи правилами, як у фінансовій звітності, користь SPL може бути незначною, адже творчість стає ризиком, а не перевагою.
Коли це допомагає: у сферах із великим обсягом досліджень, як-от ринкова аналітика чи продуктова стратегія, ви можете співпрацювати із ШІ: удосконалювати його плани, збагачувати результати й зберігати ці покращення для майбутнього використання. Кожна взаємодія підвищує ефективність системи.
Коли це не допомагає: якщо ваша команда переважно використовує ШІ для простих робочих процесів із мінімальним втручанням людини, наприклад обробки рахунків, витрати на співпрацю можуть переважити користь.
Коли це допомагає: припустімо, ви виходите на ринок нового регіону, і ШІ раптом має опрацьовувати запити щодо місцевих податків. SPL дає змогу швидко додавати нові правила та евристики щойно вони з’являються, запобігаючи повторенню помилок.
Коли це не допомагає: якщо ваше середовище статичне, наприклад ви перетворюєте стенограми нарад на стандартизовані підсумки, постійна адаптація майже не дає користі.
Теоретично все це звучить перспективно, але впровадження SPL пов’язане з реальними труднощами. Нижче розглянемо деякі з основних:
На ранніх етапах генерування стратегій поступ часто зупиняється: нові результати не розвивають попередні напрацювання, і прогрес сповільнюється. Зазвичай це спричиняють дві основні проблеми:
Рішення: заздалегідь закодуйте всі доступні бізнес-знання, щоб система мала достатньо інформації для роботи.
Рішення: створіть детальну шкалу, що оцінює кілька аспектів відповіді, як-от точність, зрозумілість і доречність, та налаштуйте вибірку відповідно до цих сигналів.
Якщо система генерує сотні стратегій, але отримує замало відгуків, щоб відрізнити хороші від поганих, керувати вибіркою швидко стає надто складно. Рішення — відсівання.
Удосконалюючи сховище стратегій, ураховуйте:
Термін використання: вилучайте стратегії, коли минає визначений строк або кількість поколінь.
Оцінка: використовуйте свою шкалу оцінювання, щоб відфільтровувати стратегії зі стабільно низькими показниками. Поєднання цього підходу з обмеженням терміну використання дає змогу зберігати лише ті методи, які з часом доводять свою цінність.
Оцінювання за допомогою LLM: періодично перевіряйте стратегії, щоб виявляти ті, які більше не дають унікальних ідей, адже їхні корисні елементи, імовірно, уже ввійшли до новіших версій.
Рішення: ставтеся до бази даних стратегій як до живої системи: регулярно відсіюйте зайве, щоб залишалися лише актуальні й цінні знання.
Навчання системного запиту досі перебуває на ранньому етапі розвитку, але його потенціал величезний. Компанії, що покладаються лише на статичні запити або нескінченне донавчання, зіткнуться зі знайомими обмеженнями: крихкими системами, зростанням витрат і марнуванням зусиль. SPL дає змогу вирватися із цього кола, створюючи системи, що з часом удосконалюються й кодують принципи вищого рівня замість окремих виправлень.
SPL досі розвивається, але напрям уже зрозумілий: системи, здатні навчатися на власному досвіді, випереджатимуть ті, що цього не вміють. Саме час експериментувати: починайте з малого, фіксуйте висновки й закладайте основу для систем ШІ, які вдосконалюються з кожною взаємодією.