Українка трансформувала промпти в архітектуру, щоб LLM не перевантажувались інструкціями

Українська розробниця та Data Warehouse Lead Олена Кузнецова запропонувала новий підхід до роботи з великими мовними моделями (LLM). Замість створення одного великого запиту (промпту) з безліччю інструкцій, вона розробила систему, яка нагадує програмну архітектуру. У цій системі правила, контекст, автоматизації та ролі ШІ-агентів зберігаються окремо і підвантажуються лише за необхідності.

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

«Замість того, щоб “запаювати” в агента чи скіл безліч інструкцій на всі випадки життя, я почала розділяти їх за очевидними векторами: “ось це правила написання SQL-запитів, винесемо їх в окремий файл і завантажуватимемо динамічно”», — пояснює Кузнецова.

Її система “архітектури промптів” включає такі компоненти:

Правила — прямі вказівки моделі щодо того, що вона повинна робити, а чого уникати.
Контекст проєкту — інформація про структуру проєкту, функціонування його модулів та розташування даних.
Контекст задачі — опис мети та обсягу завдання. Зазвичай це детально сформульоване завдання з Jira, але для великих проєктів розробниця створює окремий промпт.
Автоматизації — спеціальні інструменти (скіли) для виконання повторюваних дій, наприклад, для генерації документації до нової таблиці та її публікації у внутрішній базі знань.
Оркестратори — інструкції, які визначають, яких ШІ-агентів потрібно викликати та як координувати їхню спільну роботу. Наприклад, вони використовуються для виявлення неякісного коду, створеного ШІ, який сама модель може не помітити.
Агенти — готові сценарії роботи, які містять правила прийняття рішень та механізми підвантаження необхідних інструкцій і скілів.
Скоуп (Scope) — правила поведінки моделі, що визначають, наскільки суворо вона повинна дотримуватися інструкцій, чи може проявляти ініціативу, чи має перевіряти свою роботу та наскільки детально пояснювати свої дії користувачу.
Голоси — визначення тону та “особистості” агента. Зміна стилю відповіді може свідчити про втрату контексту або відхилення від очікуваної роботи моделі.

Серед власних режимів роботи розробниця згадує “scope-beer”, який вона активує, коли не впевнена у своїх рішеннях. У цьому режимі агент ретельніше перевіряє її роботу та надає більш детальні пояснення.

За словами Кузнецової, промпти в такій системі все більше нагадують принципи SOLID у програмуванні, коли проєкт розбивається на окремі компоненти з чітко визначеними функціями.

«Це неймовірно захопливо: будувати ідеальний інструмент, який розуміє, що я маю на увазі, коли кажу: “зай, просто зроби гарно”», — ділиться розробниця.

На запитання про механізм динамічного підвантаження додаткових інструкцій, оскільки в Claude немає спеціальної кнопки для цього, Кузнецова пояснила, що достатньо просто вказати умову звичайним текстом і надати агенту шлях до потрібного файлу. Наприклад: «Якщо працюєш із модулем X, прочитай claude/shared/prompt.md».

Аналогічно можна пояснити моделі, коли потрібно запускати додаткових агентів. Хоча Claude іноді самостійно знаходить і викликає потрібні скіли за їхнім описом, це не завжди працює. Тому розробниця радить прямо називати потрібний інструмент у промпті, якщо це необхідно.

Раніше видання dev.ua повідомляло про дослідження конфігураційних файлів для кодувальних ШІ-агентів. Воно показало, що надмірна кількість постійно завантажених інструкцій може перевантажувати контекст моделі. Рідко необхідні правила та навички дослідники рекомендували виносити в окремі файли, які агент підвантажуватиме лише за потреби.