Як перевіряти, що модель ШІ «мислить правильно»: досвід Дмитра Кияшко

​ChatGPT видає відповідь за секунду. Але чи він її знає, чи просто вгадав? Для звичайного користувача різниці немає. Для бізнесу, який будує продукт на ШІ, ця різниця може коштувати сотні мільйонів доларів.

ChatGPT видає відповідь за секунду. Але чи він її знає, чи просто вгадав? Для звичайного користувача різниці немає. Для бізнесу, який будує продукт на ШІ, ця різниця може коштувати сотні мільйонів доларів.

Дмитро Кияшко, Software Developer in Test, який уже понад 8 років працює в ІТ, займається саме цим: перевіряє, як ШІ-системи «думають». Не що вони відповідають, а чому саме так. І якщо логіка хибна, блокує реліз, навіть коли результат виглядає правильним.

Окрім роботи з моделями, Дмитро постійно працює з людьми. Уже понад чотири роки він відповідає за команду з п'яти інженерів: розподіл завдань, рев'ю, планування, вирішення технічних проблем. Майже шість років займається наймом і менторством — провів сотні технічних співбесід, виростив кількох джуніорів до позицій Senior і Tech Lead. Частина з них зараз самі будують команди.

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

Правильна відповідь — ще не гарантія

«Якщо зосереджуватися виключно на валідації фінальної відповіді, легко пропустити критичні помилки», — пояснює Дмитро. — «Модель може просто вгадати або згенерувати галюцинацію, яка випадково збіглася з потрібним результатом. Тому для нас пріоритетним є аналіз того, як саме модель дійшла до свого висновку».

Цей підхід сформувався практичним шляхом — через багато циклів спроб і помилок. Під час роботи над ШІ-агентом, який аналізував метрики рекламних кампаній, команда зіткнулася з тим, що точність моделі була близько 50%. Це змусило копати глибше.

«Ми почали додавати розширене логування та використовувати traces, щоб покроково відстежувати, як модель приходить до кожного рішення. З часом стало зрозуміло, що детальне логування є критично важливим — воно дає змогу бачити все: які дані модель отримала, як їх опрацювала, з якими історичними показниками порівнювала, які інструменти викликала та чому».

Якщо модель видає неправильну відповідь, можна точно визначити, на якому етапі було допущено помилку. У підсумку — вища точність і агент, який не викидає сюрпризів.

Модель вгадала. І що далі?

Дмитро працює з Xenoss — tech-компанією з рейтингу Inc. 5000, де допомагає будувати тестування для агентних ШІ-систем. Стандарти жорсткі.

У такому середовищі стандарти жорсткі. Команда тримає планку на рівні 88–90% точності. Якщо під час тестування нових інструкцій або функціоналу цей показник падає нижче 80%, реліз відкладається.

Одна правильна відповідь, за словами Дмитра, ще нічого не доводить. Тому команда може заблокувати реліз — навіть коли конкретний результат виглядає ідеально.

У таких випадках команда повертається до покращення інструкцій, розширення тестового набору даних, уточнення логіки або доопрацювання окремих компонентів. Лише коли модель стабільно відновлює потрібний рівень точності на різних типах тестів, можна рухатися далі.

Чому стандартне тестування не працює

Класичний софт детермінований: однакові вхідні дані завжди дають однаковий результат. Тому легко створити юніт-тести, інтеграційні тести, чітко визначити очікувані результати і досягти майже 100% покриття. З ШІ ситуація інша.

«Якість відповіді сильно залежить від контексту: навіть незначна зміна формулювання або даних може призвести до зовсім іншого результату. Поведінку моделі неможливо повністю описати — простір можливих відповідей практично нескінченний, тому традиційні тести покривають лише вузькі кейси й не дають повної картини якості», — каже Дмитро.

Тож для ШІ працюють інші підходи: великі тестові набори даних, стрес-тести, аналіз логіки міркувань, метрики якості, порівняння з продакшн-версією та глибинне логування.

На що дивиться експерт

Коли Дмитро оцінює ШІ-продукт, перше, на що звертає увагу — надійність поведінки моделі.

Головне для нього — зрозуміти: система справді стабільна, чи їй просто пощастило з формулюванням запиту. Далі він перевіряє чіткість інструкцій і системного промпту, коректність ходу думок — як саме модель дійшла до відповіді. І обов'язково — яке логування додане.

Що він бачить, а інші ні

«Зазвичай інженери перевіряють зміни на невеликих тестових наборах. Я використовую значно більші та різноманітні набори даних, що дозволяє ідентифікувати помилки навіть у граничних випадках».

Пояснити це бізнесу — вже інша історія.

Іноді бізнес прагне випустити зміни якнайшвидше, створюючи тиск на інженерну команду. Через це на проєкті й з'явилися жорсткі метрики для оцінки ШІ. Якщо результати показують падіння ефективності порівняно з продакшн-версією, реліз відкладається — незалежно від тиску.

На своєму проєкті Дмитро відповідає за ухвалення рішення, чи можна випускати нову версію продукту. Завдяки прозорому процесу конфліктів не виникає.

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

Що буває без такого тестування

Якщо ШІ-продукт виходить без глибокого тестування, ризики серйозні — як для продукту, так і для бізнесу.

«Якщо ШІ-агент ухвалює рішення на основі неправильної логіки, він може видати хибну пораду, злити чужі дані або згенерувати текст, за який компанія потім відповідатиме в суді. Особливо, якщо ми говоримо про банківську або медичну сфери — наслідки можуть бути дуже плачевні», — попереджає Дмитро.

У світі вже є реальні приклади.

Zillow у 2021 році використовував ШІ-модель для автоматичного прогнозування цін на житло. Модель почала систематично переоцінювати об'єкти. Результат: компанія втратила понад 500 мільйонів доларів і скоротила близько 25% персоналу.

Посібник, якого не існує

Зараз Дмитро працює над інженерним гайдом з оцінювання ШІ-систем.

Коли він почав розбиратися, як тестувати моделі та ШІ-агентів, швидко зрозумів: жодного цілісного посібника просто не існує. Інформація розпорошена між науковими статтями, блогами, конференціями, внутрішніми напрацюваннями компаній — її доводиться видобувати з десятків різних джерел.

Ринок ШІ-продуктів росте шалено, а єдиного посібника досі немає. Тому він вирішив написати такий сам. У ньому буде детально описано, як побудувати власну систему оцінювання, як формувати тестові набори даних, працювати з аналізом логіки, проводити стрес-тести, логувати поведінку моделі та оцінювати її стабільність.

«Це буде не теорія, а робочий інструмент, заснований на реальному досвіді», — додає Дмитро. — «Я включаю конкретні кейси, помилки, з якими ми стикалися, та рішення, які реально спрацювали».

Після публікації інженерні команди отримають в одному місці всі ключові принципи, методики та практики для якісного оцінювання ШІ. Речі, які зараз роблять одиниці, зможуть робити звичайні інженери. Принаймні, менше продуктів виходитиме на ринок із точністю 50% і сподіванням на краще замість тестування.Через кілька років тестування ШІ стане такою ж обов'язковою дисципліною, як QA у класичній розробці, — каже Дмитро. Питання лише в тому, скільки компаній встигнуть набити шишки до того, як це зрозуміють

Анастасiя Югова спеціально для Діалог.UA