Як створювати «розумні» програми за допомогою AI

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привіт, мене звати Елі Брагінський. Розповім трохи про себе: випускник Оксфорда, магістр програмної інженерії, захистив дисертацію. Працював над AI понад 7 років.

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

Deep Learning та NLP кардинально змінили сучасне суспільство. Завдання, які раніше робили люди, тепер можуть бути виконані штучним інтелектом швидше, дешевше та, в багатьох випадках, ефективніше. Популярними прикладами є чат-боти, функції класифікації токсичності (наприклад, у соціальних мережах) та спаму, коротке узагальнення історії/ статті тощо.

Одним із різновидів моделей NLP, які привернули особливу увагу в останні роки, є Foundation Models — великі базисні моделі deep learning. Вони навчені й треновані на величезній кількості нерозмічених даних (зазвичай за допомогою самонавчання). В результаті утворилася модель, яка може бути адаптована до широкого спектра наступних завдань.

З моменту впровадження Foundation Models у 2018 році відбулася значна трансформація процесу побудови систем штучного інтелекту.

Визначення завдання

Тепер, коли ми знаємо, що таке Foundation Models, подивимося, як ми можемо вирішити умовну проблему за допомогою цієї моделі. Далі я розберу конкретний приклад усім нам знайомої ситуації із застосуванням AI-технологій.

Припустимо, що ви є керівником, та ваш насичений день зайнятий вирішенням завдань зі списку справ. Викреслювати кожен виконаний пункт з переліку справ дуже приємно, чи не так? Однак додавати кожне наступне завдання вручну та розставляти пріоритети задачам навряд чи приносить таке ж задоволення.

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

Звучить захоплююче? Це той випадок, коли Foundation Models стають справжнім порятунком!

Але перш ніж ми підемо далі та заглибимося в найдрібніші деталі рішення, було б непогано зрозуміти, як воно взагалі працює. Щоб сформувати це як завдання для нашої моделі, потрібно зрозуміти формат, у якому необхідно надати дані.

Ми зробимо таким чином:

  1. Спочатку опишемо завдання: пам’ятайте, що базові моделі можуть вирішувати різноманітні проблеми, тому потрібно чітко сформулювати, що нам потрібно.
  2. Опишемо групу прикладів: хоча Foundation Models можуть досить добре працювати на різних завданнях без будь-яких заданих прикладів (також відомих як Zero-shot навчання), їх ефективність при встановленні Zero-shot іноді знижується. Все ж буде краще, якщо ми опишемо набір зразків (пар «завдання-результат») для моделі, у якої вона буде вчитися. Майте на увазі, що під час створення прикладів буде краще, якщо ви перерахуєте непередбачені випадки та неоднозначні приклади, щоб отримати точніший результат.
  3. Будемо використовувати модель для виведення unseen завдань (з якими вона ще не стикалася), у цьому випадку — нагадування.

Тепер ви можете поставити запитання, що саме означають поняття Task та Output? У цьому випадку Task — це оперативний запит, який задається з метою отримати бажаний показник. Output — безпосередньо результат.

Крок 1. Визначення тексту запиту

Тепер, коли ми знаємо, як саме вирішуватимемо завдання, поринемо в деталі та з’ясуємо, що мається на увазі під командою Prompt (індивідуальне завдання та відповідний до нього результат).

По-перше, визначимося з постановкою проблеми на початку запиту.

Зверніть увагу на те, як у нашому випадку чітко сформульована проблема. Тепер перейдемо до визначення запиту для нашої моделі.

Вище можна побачити, що два запити чітко позначені як Task та Output. Це зроблено для того, щоб модель розуміла, який формат нам потрібний та як виводити інформацію.

Задаємо ще два запити (загалом 4 наразі).

Ви повинні були помітити, що ми прописали результат у вигляді файлу JSON (або словника, оскільки ми працюємо з Python). Це для того, щоб у нас надалі не було проблем у коді програми.

Як бачите, запити були поділені за допомогою «======». Такий знак використовується для того, щоб модель розуміла, що існує декілька запитів (усі вони різні та не є частиною загального запиту).

Тепер протестуємо нашу модель, щоб побачити, чи працює вона так, як ми очікуємо, чи ні.

Крок 2. Генерація результату для unseen завдання (з яким програма ще не стикалася)

Почнемо з генерування результату для unseen завдання.

Вище ви можете бачити, що ми щойно поставили завдання у запиті та залишили порожній рядок з назвою Output. Модель завершить виведення результату.

Тепер натиснемо Submit та випробуємо нашу Foundation Model.

Це було класно! Модель добре класифікувала потрібний результат. А тепер подивимося, чи буде вона працювати з іншим введенням запиту.

Таким чином, з’ясувалося, що модель не була впевнена, що робити, коли ми поставили завдання інакше. Вона класифікувала ремонт велосипедів як частину бакалії та думає, що пріоритет має бути середнім (насправді — високим чи терміновим!).

Є багато способів вирішити цю проблему. Наприклад, ми можемо додати більше ясності до нашої початкової інструкції або ввести додаткові запити, які охоплюють непередбачені випадки.

Крок З. Додавання вдосконалень у нашу модель

Тепер додамо деякі покращення, щоб наша модель видавала результати правильніше.

Перший крок, який ми зробимо, — чітко пропишемо категорії при постановці завдання, як показано на малюнку вище. Так завдання стане зрозумілішим для моделі. Буде ясніше, які можливі категорії та пріоритети існують.

Про всяк випадок додамо ще одне вдосконалення.

Ми вказали, що модель має видати результат Unknown, коли не розуміє, до якої категорії належить завдання. Ви також можете змінити назву, наприклад, на Misc.

Тепер, коли ми додали вищезазначені покращення, запустимо та подивимося, як буде поводитись модель з тим самим прикладом, що ми пробували раніше.

Як бачите, все працює чудово. Категорія класифікована як Hobbies, пріоритет Urgent. Вдосконалення подіяли!

Крок 4. Примушуємо модель працювати з нашим To-Do додатком

Тепер, коли наша модель стала видавати гарні результати, поговоримо про те, як можна змусити її працювати з нашим To-Do додатком.

Нижче ви бачите, як можна використати Cerebrate SDK для того ж завдання, яке ми розглядали раніше. Чому ми робимо це за допомогою SDK зараз? Тому що наш To-Do додаток не може отримати результат із Playground, де ми проводили тестування.

Зверніть увагу: мета цієї статті полягає не в розробці To-Do додатку, а в тому, щоб показати, наскільки легко можна отримати користь від Foundation Model Cerebrate.ai за допомогою SDK та її інтеграції у ваш продукт. Отже, будь-який код, який ми розглядаємо, варто сприймати як абстрактний приклад.

По-перше, ми імпортуємо, ініціалізуємо зразок SDK Cerebrate та визначаємо наші завдання та пріоритети.

Тепер задаємо наші приклади та нові завдання, для яких необхідно отримати припущення.

І, нарешті, ми використовуємо метод .predict(). Робимо припущення, перетворюємо їх у словник (оскільки модель повертає рядкове виведення) та потім поміщаємо їх у базу даних.

Тут у функції Add_new_todo, Task — завдання (з переліку new todo у цьому випадку), Todo — припущення від Cerebrate SDK, а db — база даних.

Отже, підсумковий код від початку і до кінця виглядатиме приблизно так:

Майбутні вдосконалення

Модель працює добре з нашими unseen даними, навіть з тими, які є непередбаченими випадками. Але, як ви бачите, вона була налаштована для вирішення цього завдання на відносно низькому рівні (на основі лише 5 зразків у нашому випадку).

Однак модель має великий потенціал. Ми можемо підвищити її ефективність шляхом додавання запитів-прикладів та ще чіткішого формулювання проблеми.

Про Cerebrate

Cerebrate — це проста у використанні сервісна платформа, яка дозволяє розробникам вирішувати завдання за лічені хвилини. З таким помічником немає потреби створювати величезні набори даних або витрачати тижні на навчання моделей. Просто опишіть завдання та наведіть кілька прикладів, а Cerebrate подбає про все інше.

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якщо на цей текст дивитися як на фундамент до завдання яке треба вирішити, то ось що прийшло мені на думку:
1. Створюємо глобальні словники категорій, приорітетів, тасків
2. Накопичуємо інформацію про частоти використання користувачами категорій та приоритетів. Найчастіші будуть більш правдивими.
категорія — пріоритет, таск — категорія
3. А тут треба, щоб спрацював камертон — таска, яку щойно назвали у клубі, схопила б найчастіш використовувану категорію та найчастіше використовуваний пріоритет. Приліпилася до неї і вийшла у output з усім цим.
4. Зворотній зв язок. Якщо програма помилилася, вона повинна трохи поспілкуватись із користувачем, щоб визначити ступінь його освідченності та нову предметну область — тобто що за категорія, що за пріорітет для ції не звичайної таск (та інше оточення). Звісно — це створить у наших словниках нові записи. Таке опитування просто складе суму частот із наданої користувачем інформації і якщо вона більш менш схожа на звичайну у нас і правда — нове відкриття. Інакше — це користувач помилився.
Я так ціну криптовалюти розпізнаю у браузері.

гарно б, щоб не зробили Скайнет та Термінаторів :)

Тепер ви можете поставити запитання, що саме означають поняття Task та Output? У цьому випадку Task — це оперативний запит, який задається з метою отримати бажаний показник. Output — безпосередньо результат.

Ось тут я зламався, до цього статті Task та Output не згадується.

P.S. Перечитай ще раз: статтю дуже важко сприймати.

Підписатись на коментарі