Роль PO/ BA в проектах із синтетичними даними для навчання моделей AI
- Olga Stelmakh
- 24 години тому
- Читати 6 хв
Хочу поділитись враженнями від роботи на проєктах, де роблять SDG (Syntetic Data Generation) дані для навчання AI. З мого досвіду роль PO/ BA тут настільки змінена, що класичні підходи до написання вимог кардинально інші. На таких проєктах роль PO присутня і визначенні скоупу, вимог, АС, але самий підхід зовсім інший.
Чому SDG використовуються?
В класичному варіанті SDG треба тоді, коли реальних даних немає або вони обмежені і їх дуже складно дістати. Наприклад, перевірка LIDAR на машинах, коли людина вискакує на дорогу. Чи розпізнавання замаскованих танків для дронів. В першому випадку негуманно :) В іншому випадку дуже мало реальних даних.
Що робить PO/ BA у SDG-проєктах?
У традиційних продуктах бізнес-аналітик працює з функціями, сценаріями користувача та стабільними acceptance criteria, а у проєктах із синтетичними даними він працює з гіпотезами, візуальними параметрами, варіативністю сцен, логікою лейблінгу та аналітикою якості розпізнавання. У звичайній software-розробці бізнес-аналітик формує скоуп навколо функціональності: що саме система має робити, які екрани показувати, як поводитися у відповідь на дії користувача. У проєктах із синтетичними даними ця логіка змінюється, тому що об’єктом роботи стає не бізнес-функція як така, а візуальний контент, який має навчити модель краще розпізнавати певні класи об’єктів або сценарії. Ближче до розробки ігор, де не вимоги, а сценарії.
Наприклад, якщо стоїть задача покращити розпізнавання замаскованих танків для кращого попадання, то основна складність полягає не в тому, щоб “запрограмувати функцію”, а в тому, щоб визначити:
які саме візуальні сценарії потрібно змоделювати;
яких варіацій середовища бракує;
як виглядає об’єкт у різних умовах;
як змінюються ракурси, освітлення, перекриття, фон і ступінь видимості;
як саме ці сцени мають бути розмічені;
і головне — чи дає згенерований контент реальне покращення якості розпізнавання
Скоуп у таких проєктах — це не просто список вимог, а візуальна рамка. Фактично, команда проходить кілька послідовних рівнів роботи:
створення базової сцени - головного обєкта;
побудова середовища, у якому ці об’єкти існують;
моделювання типових і нетипових сцен;
додавання варіативності;
визначення правил лейблінгу [ідентифікатор що треба вчити для AI];
валідація на моделі;
корекція скоупу за результатами розпізнавання.
Тобто, скоуп ніколи не є остаточним на старті. Він еволюціонує разом із результатами тестування. Спочатку команда може побудувати базові сцени: ландшафт, типові траєкторії руху, стандартні ракурси камери, базові погодні або світлові умови. Далі з’являється новий рівень складності: часткове перекриття, різні типи фону, зміна масштабу, складна освітленість, нічні сцени, об’єкти в русі, втрата чітких контурів, дрібні деталі, візуальний шум.
Саме тому бізнес-аналітик у таких проєктах працює не тільки з описом “що треба зробити”, а й із рамкою “яку візуальну реальність нам потрібно створити, щоб модель навчилася бачити те, що сьогодні не бачить”. На своїх проєктах це досягалося методом проб і помилок.
Чому User Stories та Acceptance Criteria стають складнішими?
Класичні user stories у таких проєктах працюють лише частково. Їх можна сформулювати, але вони будуть менш функціональними і значно більш описовими. Наприклад, user story може звучати так: команда хоче отримати набір сцен, у яких цільовий об’єкт рухається через різні типи місцевості, частково перекривається природними елементами, спостерігається з верхнього ракурсу та представлений у кількох візуальних варіаціях.
Формально це вже user story, але вона не несе того рівня однозначності, який ми зазвичай очікуємо в класичній бізнес-аналітиці. Причина в тому, що головна цінність тут не в самій сцені, а в її впливі на поведінку моделі.
Acceptance criteria також перестають бути суто бінарними. Їх неможливо звести лише до перевірки «працює/не працює”. Вони стають гібридними і включають одразу кілька рівнів:
візуальний рівень — сцена відповідає потрібному оточенню, ракурсу, умовам освітлення, рівню варіативності;
структурний рівень — усі необхідні об’єкти присутні, мають потрібні параметри та правильно організовані;
рівень лейблінгу — об’єкти розмічені відповідно до правил, анотації послідовні;
аналітичний рівень — використання нового синтетичного датасету дає покращення або принаймні помітний вплив на метрики моделі в цільовому сценарії;
дослідницький рівень — команда отримує достатньо сигналів, щоб зрозуміти, що саме потрібно змінювати далі.
Таким чином, acceptance criteria у таких проєктах — це не тільки вимоги до контенту, а й вимоги до корисності цього контенту для навчання.
Валідація як центральна частина роботи
Одна з головних челенджів таких проєктів полягає в тому, що створення датасету не є фінальною точкою. Насправді це лише початок циклу перевірки.
Команда генерує перший датасет, передає його в роботу Data Science-команді, після чого модель навчається або донавчається на нових даних. Далі результати аналізуються через метрики якості: precision, recall, false positive, false negative, confusion matrix, поведінка на окремих класах, стабільність розпізнавання за складних умов.
І саме тут роль PO/BA стає особливо цікавою. Треба не просто “зібрати вимоги”, треба зрозуміти "чого":
де модель плутає класи;
які сцени виявилися надто ідеальними;
яких візуальних варіацій не вистачає;
чи проблема в самій сцені, у співвідношенні класів, у лейблінгу чи в дисбалансі датасету;
чи потрібно додати більше реалістичних дефектів, більше шуму, більше складних фонів або інші типи освітлення.
Наприклад, модель може добре працювати на великих об’єктах, але значно гірше — на дрібних деталях. Або вона може впевнено розпізнавати об’єкт удень, але втрачати якість у сутінках, вночі або на низькоконтрастних сценах. У такому випадку бізнес-аналітик не просто документує проблему, а допомагає перетворити її на новий обсяг робіт: нові сцени, нові варіації, нові правила генерації, нові критерії оцінки.
Баланс між синтетичними та реальними даними
Ще одна складність полягає в тому, що синтетичні дані рідко працюють найкраще у відриві від реальних. На практиці найбільшу цінність зазвичай дає саме змішування синтетичних і реальних даних. Де реальні дані вчать "як має бути", а синтетичні "що шукати". Але це одразу створює новий пласт на подумати.
Потрібно зрозуміти:
яка пропорція синтетичних і реальних даних є оптимальною;
як змінюється поведінка моделі при різних міксах;
чи не починає модель занадто орієнтуватися на більш частотний клас;
чи не знецінюються рідкісні або дефектні стани;
чи не стає синтетичний контент надто “чистим” порівняно з реальністю.
Якщо в датасеті переважають цілі об’єкти, модель може почати сприймати дефектні стани як шум. Якщо ж, навпаки, акцент зміщений занадто сильно на дефекти, модель може втратити якість на нормальних станах. Якщо синтетичні сцени надто ідеальні, модель чудово вчиться на них, але погано переносить знання на реальні умови.
Саме тому значна частина роботи в таких проєктах — це investigation: пошук правильної пропорції, правильного набору сцен, правильного рівня реалістичності, правильного обсягу аугментацій і правильного набору цільових класів. Тут PO треба навчитись думати як AI. Робота буде полягати в пошуку логіки експериментів, фіксуванні гіпотез, структуруванні висновків та перетворенні результатів Data Science на зрозумілі бізнесові рішення.
Комунікація між стейкходерами окремий челендж. Я постійно спілкуюсь з
бізнес-стейкхолдерами, які формулюють проблему, але не розуміють контексту чи думають AI всесильний;
доменними експертами, які пояснюють, як виглядають реальні об’єкти, дефекти чи сценарії;
3D-artists, які будують візуальні сцени;
ML/Data Science-командою, яка навчає моделі та аналізує результат;
спеціалістами з анотації та лейблінгу;
девопсами, які забезчепують зберігання і передачу гігібайтів - терабайтів інформації;
Челендж по організації створенню відео
Треба розуміти і нарізати вимоги таким чином, щоб кілька 3D-artists могли робити одну сцену. Хтось робить кущі, хтось будинки, а хтось маскування танка. Всі сторі мають плюс-мінус однаковий текст, тільки фото різні всередині, як приклад. Плюс треба враховувати можливість перевикористання об'єктів між проєктами, яка збільшує швидкість розробки.
Чому Kanban часто працює краще за класичний Scrum
Планування в таких проєктах теж має свою специфіку. Хоча окремі блоки робіт можуть бути заплановані наперед, загалом проєкт рідко рухається лінійно. Дуже багато залежить від результатів проміжної перевірки: що саме модель не розпізнала, де з’явилися false positives, де є провали по recall, які сцени не дали очікуваного ефекту.
Через це backlog часто виглядає не як набір стабільних фіч, а як живий список гіпотез, уточнень, доопрацювань та дослідницьких задач. Саме тому Kanban-підхід часто виявляється більш природним, ніж жорсткий спринтовий ритм. Команда постійно реагує на нові інсайти, додає нові елементи, змінює пріоритети, переоцінює корисність окремих сцен чи датасетів.
У такому середовищі Product Owner та Business Analyst відповідають не стільки за “закриття фіч”, скільки за логіку потоку роботи: що потрібно перевірити далі, де є найбільший ризик, який експеримент має найвищу цінність, і як не втратити зв’язок між бізнес-ціллю та численними технічними і візуальними ітераціями.
Висновок
Проєкти із SDG для навчання AI-моделей змінюють класичне уявлення про роль Product Owner та Business Analyst. Тут недостатньо просто описати вимоги, погодити user stories і передати їх у розробку. Потрібно працювати зі складною системою взаємозалежностей між бізнес-ціллю, візуальним контентом, правилами анотації, результатами навчання та безперервною дослідницькою валідацією.
У таких проєктах BA/PO стають не лише носіями процесу, а й модераторами сенсу. Вони допомагають перетворити нечіткий запит “модель має краще бачити складні об’єкти” у керований процес: від визначення сцен і варіативності до аналізу метрик, переформування скоупу і прийняття рішень на основі результатів.
Новини та статті з бізнес-аналізу:
