Чи довірили б ви алгоритму рішення на кілька мільйонів доларів? За даними JLL, частка інвесторів, власників та орендодавців, які запустили пілотні проєкти зі штучним інтелектом у сфері нерухомості, за два роки зросла з менш ніж 5% до 88%. Для консервативного ринку, який роками спирався на таблиці й особистий досвід фахівців, довірити ШІ процеси, пов'язані із серйозними фінансовими ризиками, залишається завданням із зірочкою: нейромережі можуть помилятися.
Українська розробниця Анастасія Періг уже понад два роки працює над тим, щоб програма знаходила помилки в документах до того, як їх помітить людина, і водночас оцінювала ймовірність власних неточностей. Її інженерні рішення компанія Northspyre зараз використовує в інструменті, який автоматично перевіряє дані про угоду та підказує, де в них може приховуватися ризик.
Проблему довіри до висновків ШІ під час аналізу даних, пов'язаних із високими ризиками, розробниця досліджує у своїй науковій монографії, а також розвиває цю тему як членкиня журі хакатону AITEX Tech for Good, оцінюючи проєкти у сфері медичних технологій. Поговорили з нею про те, як ШІ допомагає знаходити помилки в даних і прогнозувати значні фінансові ризики під час укладання угод із нерухомістю.
Анастасіє, останніми роками ви розвиваєте технології для оцінювання девелоперських проєктів і брали участь у створенні системи автоматичного пошуку ризиків у документах. Вивчаючи процеси оцінювання, які раніше виконували вручну, які помилки ви зустрічали найчастіше?
Зазвичай ішлося про десяток дрібних невідповідностей, які накопичувалися з часом: бюджет – в одній таблиці, строки – в іншій, листування з підрядниками – у пошті когось одного. Людині рано чи пізно набридає перераховувати те саме вручну, і тоді губиться рядок або вводиться не та цифра. Проблема в тому, що така дрібниця може виявитися вже після підписання угоди – і тоді її ціна буде зовсім іншою.
Проєктуючи систему перевірки даних, ви напевно бачили, до яких наслідків призводять помилки. Наскільки дорого вони можуть коштувати?
По-різному, але під час оцінювання девелоперських проєктів це рідко буває дрібницею: той самий відсоток похибки, помножений на бюджет у десятки мільйонів, – це вже не одруківка, а зовсім інша економіка всього проєкту.
Ціна помилки була вам знайома й раніше: протягом трьох років ви відповідали за точність звітів і зручність підтримки систем обробки даних у міжнародній ІТ-компанії DataArt. Як цей досвід допоміг вам інакше поглянути на завдання оцінювання угод?
Я добре знала, наскільки дорого коштує навіть невелика помилка у вихідній інформації: якщо вона потрапляла у звіти, то потім поширювалася на десятки документів, а знайти її було вкрай складно. Тому з часом я перестала сприймати перевірку як останній етап процесу й почала проєктувати системи так, щоб вони запобігали помилкам ще на етапі обробки даних. Цей підхід я перенесла й у роботу над інструментом оцінювання угод. Замість того щоб розраховувати лише на ручну перевірку результатів, ми заклали в алгоритм автоматичну валідацію даних і контрольні перевірки на ключових етапах розрахунку. Це дало змогу виявляти невідповідності одразу, а не тоді, коли оцінка вже була готова. Такий підхід зробив систему значно надійнішою та знизив ризик людської помилки.
У вас є окрема наукова робота на цю тему — монографія "Інтегрована методика підвищення ефективності моніторингу вебзастосунків: предиктивна аналітика для скорочення помилок і прискорення діагностики". Що саме в запропонованій вами методиці на той момент не було загальноприйнятою практикою та чи застосовуєте ви ті самі принципи на практиці — наприклад, у роботі над інструментом оцінювання угод?
До цього системи моніторингу переважно реагували на збій уже після того, як він ставався. Я запропонувала методику — у роботі я називаю її IPAM, — яка на основі історичних даних визначає патерни, що зазвичай передують збою, і попереджає про нього заздалегідь. У цьому й полягає основна ідея: змістити момент втручання з "після" на "до". І так, я використовую той самий принцип на практиці: якщо алгоритм навчений розпізнавати поєднання цифр або формулювань, які зазвичай передують проблемному проєкту, — скажімо, занижений кошторис на конкретний етап будівництва, — він здатний позначити це ще до того, як людина дочитає документ до кінця.
У сфері ШІ гучних заяв майже завжди більше, ніж рішень, які витримують перевірку. Оцінюючи десятки проєктів у сфері медичних технологій як членкиня журі хакатону AITEX Tech for Good, чи багато ви бачили проєктів, які, умовно кажучи, видавали готову відповідь без пояснень, звідки вона взялася?
Таких проєктів, у яких зовні все мало переконливий вигляд, я бачила доволі багато: акуратний інтерфейс і впевнений висновок – проєкт перспективний, ризик низький. Але варто було запитати, на яких даних навчена модель і як часто вона помиляється на тестовій вибірці, – і розмова швидко заходила у глухий кут. У когось таких цифр узагалі не було, у когось вони були, але команда вирішила не виносити їх у презентацію: "помиляється у 30% випадків" звучить набагато менш ефектно, ніж "штучний інтелект оцінює ризики". Зрештою журі найчастіше високо оцінювало саме готовність пояснити, де модель працює погано і чому, – це переважувало будь-який красивий висновок.
Чи довірили б ви самі алгоритму рішення щодо дорогої угоди або остаточне слово все одно має залишатися за людиною?
Остаточне слово я б залишила за людиною. Рішення на кілька мільйонів доларів має ухвалюватися з розумінням того, чому його прийнято, а не лише на підставі цифри на екрані. Водночас я готова довіряти алгоритму майже так само, як собі, – якщо він показує, на яких даних ґрунтується висновок і наскільки він у ньому впевнений, а не видає готову відповідь без пояснень. Він часто помічає те, що людина могла б пропустити через утому наприкінці тривалого робочого дня, – те саме, з чого ми почали розмову. Але підпис під угодою має ставити той, хто відповідає за наслідки. Поки алгоритм не навчиться нести цю відповідальність, остаточне рішення залишається за нами.
1 
65