Українська інженерка та керівниця напряму Data Warehouse Олена Кузнецова поділилася своїм методом взаємодії з великими мовними моделями. Замість використання єдиного розлогого промпту з директивами, вона розробляє своєрідну архітектуру, що складається з окремих модулів. У цій системі директиви, контекст, автоматизовані процеси та функції ШІ-агентів зберігаються ізольовано і активуються залежно від потреби.
Залишити коментар
Українська інженерка та керівниця напряму Data Warehouse Олена Кузнецова поділилася своїм методом взаємодії з великими мовними моделями. Замість використання єдиного розлогого промпту з директивами, вона розробляє своєрідну архітектуру, що складається з окремих модулів. У цій системі директиви, контекст, автоматизовані процеси та функції ШІ-агентів зберігаються ізольовано і активуються залежно від потреби.
Цим підходом інженерка поділилася на платформі LinkedIn.
За її словами, спочатку вона почала розділяти очевидні групи вказівок. Наприклад, правила для написання SQL-запитів можуть бути винесені в окремий файл та завантажені лише тоді, коли модель працює з SQL. Згодом інженерка розробила більш комплексну систему, що складається з декількох категорій блоків.
«Замість того, щоб вбудовувати в агента чи скіл безліч директив для всіх можливих сценаріїв, я спочатку почала розділяти їх за логічними напрямками: «Ось ці правила написання SQL-запитів, винесемо їх в окремий файл і будемо завантажувати динамічно», — пояснює Кузнецова.
До її «архітектури промптів» входять такі елементи:
- Директиви — чіткі вказівки для моделі щодо дозволених та заборонених дій.
- Контекст проєкту — інформація про структуру проєкту, функціонування його компонентів та місцезнаходження даних.
- Контекст завдання — опис поставленої мети та причин її досягнення. Зазвичай це докладно сформульоване завдання в Jira, але для масштабних завдань інженерка створює окремий промпт.
- Автоматизації — модулі для виконання конкретних повторюваних операцій. Наприклад, для генерації документації до нової таблиці та її розміщення у внутрішній базі знань.
- Оркестратори — інструкції, що визначають, які ШІ-агенти мають бути задіяні та як координувати їхню спільну роботу. Зокрема, вона використовує оркестратори для виявлення низькоякісного коду, створеного за допомогою ШІ, який сама модель не завжди може ідентифікувати.
- Агенти — готові робочі послідовності з правилами прийняття рішень та завантаженням необхідних директив та модулів.
- Сфера застосування (Скоуп) — правила поведінки моделі. Вони визначають ступінь суворості виконання інструкцій, можливість прояву ініціативи, необхідність перевірки результатів та рівень деталізації пояснень для користувача.
- Голоси — тон і «особистість» агента. Помітна зміна стилю відповіді може свідчити про втрату моделлю частини контексту або відхилення від очікуваної поведінки.
Серед власних режимів інженерка згадує scope-beer — буквально «розробник під пивом». Вона активує його, коли не певна власних рішень і прагне, щоб агент більш ретельно перевіряв її роботу та надавав детальну підтримку.
За словами Кузенцової, промпти в такій системі все більше нагадують принципи SOLID — підходи до розподілу програмного забезпечення на окремі компоненти з чітко визначеними функціями.
«Це неймовірно захопливо: створювати ідеальний інструмент, який розуміє, що я маю на увазі, коли кажу: «друже, просто зроби добре», — ділиться інженерка.
У коментарях Кузнецову запитали, як саме вона динамічно завантажує додаткові інструкції, враховуючи відсутність окремої кнопки чи спеціального механізму для цього в Claude. За її словами, достатньо звичайним текстом сформулювати умову та вказати агенту шлях до відповідного файлу: наприклад, «Якщо працюєш з модулем X, прочитай claude/shared/prompt.md».
Подібним чином можна пояснити моделі, в яких ситуаціях слід запускати додаткових агентів. Claude іноді самостійно виявляє та активує скіли на основі їхніх описів, але це не завжди ефективно. Тому інженерка рекомендує за потреби прямо вказувати потрібний інструмент у промпті.
Раніше видання dev.ua повідомляло про дослідження конфігураційних файлів для кодувальних ШІ-агентів. Воно показало, що надмірна кількість постійно активних інструкцій може призвести до перевантаження контексту моделі. Дослідники рекомендували виносити рідко використовувані правила та навички в окремі файли, які агент завантажуватиме лише за необхідності.
Source: dev.ua
