-
~180
учасників
-
2
заняття
-
2
місяці
З чим прийшли
Запит прийшов від L&D і звучав чесно: компанія хоче бути більшою меншими зусиллями і навчити колег вбудовувати ШІ в щоденні задачі.
Аудиторія — розробники, девопси, QA-інженери, фронтенд і бекенд. Люди, які вміють читати документацію і не потребують пояснень, що таке API. Тому програму довелось будувати не від "що таке ШІ", а від того, де саме модель ламається і чому.
Що сказали в залі
У нас, як будь-якого бізнесу, в якийсь момент з AI наступило бажання, що ми хочемо бути більшими, але меншими зусиллями, і хочемо навчати наших колег долучати AI в щоденні задачі.
Друга частина болю була структурною: інфраструктурні команди й дизайн не встигали закривати запити. Або чекати півроку, або шукати інший шлях.
Що робили
-
01
Промпт-інжиніринг: види, налаштування, типові провали
-
02
Поглиблене заняття: промпт- і контекст-інжиніринг, більше прикладів і посилань на дослідження
-
03
Бонусний урок: деградація моделі від розміру контексту, структурований вивід через JSON і машину станів
Що лишилось у роботі
Команда отримала не набір лайфхаків, а розуміння, чому довгий контекст псує відповідь і як тримати вивід у передбачуваній формі. Для інженерної аудиторії це важливіше за будь-який список інструментів.
Межі й обмеження
Контекстне вікно виявилось головним обмеженням, з яким інженери стикаються щодня: що довший діалог, то помітніше падає якість відповіді, і жодна техніка промптингу цього не компенсує.
Структурований вивід через JSON працює не завжди — модель лишається стохастичною, і на однакових параметрах той самий запит дає різні відповіді. Тому будь-яке рішення на її основі потребує перевірки на виході, а не тільки на вході.
Куди далі
Якщо задача схожа — ось із чого почати.
Розберемо запит за 15 хвилин
Безкоштовний дзвінок, на якому розпитую про задачі й кажу, що зробив би — буває, що задача закривається без мене.
