Машинне навчання — асистент для виявлення російського ІПСО

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Вітаю! Я Тарас Устиянович, Lead Software Engineer в EPAM Ukraine, а також молодий дослідник та аспірант технічної кафедри в Національному університеті «Львівська політехніка». Разом з Оленою Хомуляк, Software Engineer в EPAM Ukraine, ми поділимось нашим досвідом у реалізації рішень для аналітики та виявлення проросійської пропаганди, взаємодії з держструктурами, налагодженні контактів з іноземними партнерами та викликами, з якими ми стикнулись.

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

Враховуючи цю передумову, ідентифікація контенту, який містить викривлення інформації з метою здійснення технологій впливу, є важливим завданням. І, разом з цим, складним, бо середовище в якому формуються і проводяться інформаційно-психологічні операції (ІПСО) — неймовірно динамічне, і навіть людина з розвиненими навичками критичного мислення може запросто потрапити у цю пастку. Чи є з неї вихід? Чи здатні технології допомогти для розв’язання цієї проблеми? Це ми зараз зʼясуємо.

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

Передісторія

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

До і після 24 лютого 2022 року у мене була змога спостерігати за нагнітанням в інфопросторі. Це було доволі очевидно: чинився деструктивний психологічний вплив, для протидії якому можна ефективно використати технічні засоби.

Враховуючи мій бекґраунд у real-time-моніторингу та машинному навчанні, я вирішив зібрати дані з популярних російських соцмереж. Мене цікавив аналіз публікацій, реакції користувачів, динаміки поширення інформації, яка повʼязана з російською агресією проти України. Як науковець, я вважав, що ці дані будуть цінним артефактом для дослідження про дезінформацію в контексті війни у міжнародних наукових виданнях, публікація конференцій тощо. І не помилився.

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

Набір даних на Kaggle

Паралельно ми з науковим керівником зробили наступне:

• залили оновлену версію набору даних на IEEE;
• надіслали листи в провідні університети Європи та Північної Америки з пропозицією наукової співпраці із дослідниками з України.

Обидві дії виявились результативними. Так почалась моя колаборація із дослідниками з Технічного університету Мюнхена (Німеччина) та Університету Альберти (Канада). Серед них були й ті, хто співпрацював зі спільнотою журналістських розслідувань Bellingcat і реалізував кілька успішних кейсів.

Тоді ж виникло питання: де зберігати та опрацьовувати поточні та свіжі дані, які будуть йти потоком? Оскільки в EPAM Ukraine наша команда займалась, власне, real-time-моніторингом та observability, я вирішив звернути увагу на добре знайомий для мене та моїх колег продукт — Splunk Enterprise. Його перевагою є не лише технічний та developer-friendly набір функцій, але й наявність Splunk Academic Research License, яка дозволяє щоденно індексувати до 10GB даних протягом одного року з можливістю продовження. Отримання цієї ліцензії відбулось досить швидко: протягом кількох днів я одержав підтвердження і розпочав процес встановлення програми та онбордингу даних.

Додатково, з метою self-development та навчання, я долучив колег з компетенції, які були готові допомогти з аналізом та генерацією ідей для використання набору даних.

На початках ми з колегами займались дослідною аналітикою даних (проведення базових агрегацій, сумаризацій, обчислення описової статистики), що дозволило знаходити найбільш популярні дописи за кількістю вподобайок, поширень, коментарів тощо, а також за допомогою регулярних виразів витягувати хештеги. Крім того, ми використовували різноманітні застосунки та надбудови з Splunkbase, які вже мали готові інформаційні панелі з візуалізаціями. Приклад застосування одного з них зображено нижче.

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

На певному етапі ми зрозуміли, що простої аналітики недостатньо і є необхідність у використанні ML/NLP для більш просунутого аналізу, зокрема:

• сумаризації тексту;
• фільтрації документів для виявлення релевантних публікацій, які стосуються саме війни в Україні;
• категоризація/класифікація/кластеризація;
• named entity extraction & entity linking;
• семантичний та сентимент аналіз.

Відповідно, я почав процес дослідження того, які NLP-техніки підійдуть, щоб ефективно і з мінімальними витратами ресурсів проаналізувати текстову інформацію. Після консультацій з колегами та технічними експертами-партнерами, ми вирішили застосувати моделювання тематик або topic modeling.

Це спосіб навчання моделі без вчителя (unsupervised learning), де визначаються ключові теми текстового набору даних, опісля кожному документу присвоюється приналежність до хоча б однієї з них. Відмінність від кластеризації полягає у тому, що під час моделювання тематик один документ належить до однієї та більше тем, тоді як у випадку з останнім, один документ може належати лише до одного кластера.

LDA та BERTopic — це провідні алгоритми для виконання поставленої задачі.

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

BERTopic — state-of-the-art (SOTA) алгоритм, який базується на NLP-трансформерах та TF-IDF. Для навчання алгоритму немає потреби вказувати значної кількості гіперпараметрів — BERTopic зробить все замість вас. Останнє дозволяє економити час для розробників, разом з цим забирає частку контролю та explainability здобутих результатів. Вагомою перевагою є інтеграція з OpenAI, що дає змогу сумаризувати текст за тематиками.

Власне, застосування методів моделювання тематик дало нам змогу:

• дізнатись про ключові теми обговорень у проросійських публікаціях;
• проаналізувати ключові слова та побудувати загальне розуміння кожної з тем;
• віднайти й здійснити фільтрацію (не)релевантних тематик та документів.

Ми задовільнились здобутими початковими результатами та максимально зосередились на вдосконаленні нашого topic modeling use-case, що у майбутньому привело до якісного автоматизованого рішення.

Моделювання тематик під час дослідницької фази проєкту

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

Проте, не так все гладко, як очікувалось. Ми зіткнулись з викликами та обмеженнями:

• визначення topic survival time (скільки часу тематика «живе» в обговореннях). Комунікаційний процес є динамічним: сьогодні актуальна одна тема, завтра інша. Модель, яка навчена на даних певних тематик, не зможе ефективно визначати невідомі для неї інші тематики через місяць, пів року чи рік.
• автоматичний підбір оптимальних гіперпараметрів для навчання та перенавчання моделі;
• валідація та оцінювання надійності та ефективності моделі;
• трансформація та візуалізація даних для їх представлення у Splunk Enterprise.

Відповідність цим пунктам вище дозволила б нам реалізувати автоматизоване рішення, яке гарантуватиме надійність у категоризації текстових даних. Для цього Splunk Enterprise став нашим найкращим другом, ми почали використовувати цю платформу не лише для аналізу та обчислення статистики текстових даних, але й для моніторингу циклу machine learning operations (MLOps). Нам стали в пригоді різноманітні MLOps опенсорс-інструменти, які ми використовували для логування та трекінгу експериментів.

Загальна архітектура нашого рішення в межах дослідницького проєкту зображена на діаграмі нижче:

• Collection layer репрезентує збір даних;
• Data operations робота з даними через Python, трансформація, генерація фіч, застосування моделей машинного навчання;
• Real-time monitoring відображає індексування та візуалізацію даних з використанням складових екосистеми Splunk.

Архітектура реалізованого рішення

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

Нижче показано приклади реалізованих інформаційних панелей, які дозволяють визначати topic survival time; оптимізувати гіперпараметери під час навчання моделі залежно від отриманих метрик; знаходити тематики, які є надмірно загальні або надто одноманітні.

Inference Results дашборд

MLFlow Experiments дашборд

Дашборд MLFlow Runs

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

Вихід на клієнтів

Як тільки наше Splunk-based-рішення із використанням засобів ШІ/ML задовольняло потреби базового моніторингу, ми поділились розробкою із широкою аудиторією колег всередині компанії. Далі нам запропонували взяти участь у внутрішньому хакатоні, який проходив в EPAM. Ще на початкових фазах роботи над рішенням, ми з командою задумувались про його реальне застосування для боротьби з дезінформацією та аналізом контенту. І ось цей шанс з’явився!

Саме на хакатоні рішення почало давати тріщини від очікування технічних експертів та потенційних клієнтів. Ми зрозуміли, що дослідницький проєкт — це одне, а production-ready-продукт для реального користувача з набором очікувань та обмежень — це інше.

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

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

Аналіз очікувань від співпраці

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

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

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

Варто почати з останнього, адже ми прийшли на хакатон вже з певним рішенням, але оскільки проєкт був не зовсім customer-focused, то однією із головних задач було сформулювати problem statement для наших клієнтів і донести цінність та користь продукту. Як виявилось, ми не були унікальними на ринку, декілька схожих рішень вже існували.

Перші зустрічі з клієнтом можна назвати успішними, позаяк ми змогли порозумітись щодо спільного бачення кінцевого продукту. Ми співпрацювали не лише із самим клієнтом, а також із розробниками з його сторони. Також ми мали підтримку ментора з хакатону, тому спільно працювали над збором вимог та потреб. Наше розуміння потреб клієнта удосконалювалось з кожною зустріччю і складалося у чітку візію кінцевого production-ready-продукту.

Важливо було зрозуміти наших кінцевих користувачів. Для цього ми створили два варіанти user personas. Перша персона є розробником, який працює безпосередньо з продуктом, використовуючи розроблені моделі машинного навчання для обробки тексту. За потреби ця персона може змінювати код, створювати додаткові інформаційні панелі та самостійно (пере)навчати модель. Друга персона — це аналітик даних та/або фахівець, який працює над пошуком закономірностей, аналізом оброблених даних та робить висновки на їх основі.

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

• плавна інтеграція з наявними системами;
• удосконалене управління даними;
• недорогий інструмент для автоматизації процесів та підтримки прийняття рішень;
• можливість діяти проактивно проти зростання цифрових загроз.

Після визначення персони користувача, ми створили Value Proposition map для забезпечення відповідності потреб клієнта запропонованому рішенню. В основному, наші клієнти шукали доступний, швидкий та ефективний інструмент для виявлення маніпулятивного контенту та обробки великої кількості інформації. Таким чином, нашою метою було надати їм відкритий та адаптивний інструмент для автоматизованого моделювання тематик.

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

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

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

Від research до production

Коли очікування та вимоги клієнтів, а також рекомендації технічних експертів стали зрозумілі, ми з командою обрали рух в такому напрямку:

• відмовитись від Splunk Enterprise: клієнт самостійно може для себе вирішити, де зберігати та візуалізувати дані;
• використовувати рішення, які є безкоштовні та мають відкритий початковий код;
• автоматизувати ML-частину розробки.

На момент нашого «просвітлення», хакатон доходив до завершення, тож ми спільно з усіма залученими сторонами прийняли рішення продовжувати співпрацю надалі та не обмежувати себе часовими рамками. Почали надходити свіжі запити, ідеї та пропозиції для вдосконалення. Разом з ними, досі невирішені технічні задачі в індустрії загалом, усвідомлення обмеженості NLP-можливостей української мови, тому нам з командою випала нагода взяти на себе роль лідерів та першопрохідців у автоматизованому виявленні проросійської дезінформації, пропаганди та ІПСО.

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

Готову функціональність після модифікації ми запакували у Dockerfile, і нашим рішенням вже можна було користуватися. Все, що потрібно зробити користувачу, — це вказати шлях до навчального набору даних та збудувати Docker-контейнер. Моделі навчаються автоматично із логуванням гіперпараметрів та метрик, а оптимальна модель зберігається. Опісля відбувається розгортання навченої моделі як scoring endpoint. Візуальне представлення згенерованих результатів доступне на окремій кінцевій точці (приклад графіка наведено нижче).

Приклад візуалізації змодельованих тематик. Тут використано текстові дані звітів Інституту вивчення війни

Важливим для нас було також використання навчання з вчителем (supervised learning) для класифікації контенту як проросійського, нейтрального чи проукраїнського. Ця «подорож» очікувано виявилась складнішою, ніж попередня. Перш за все, нам потрібні такі інгредієнти:

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

Виглядає все наче просто та зрозуміло, проте за цих всім ховається безліч підводних каменів та нюансів:

• інформація змінюється дуже динамічно: навчання моделі на даних 2022 року не гарантуватиме надійності у реаліях інфопростору 2023 або 2024 років;
• клієнти жодними даними з нами не діляться, тому покладатись слід виключно на власні ресурси та зусилля;
• займатись fine-tuning-трансформерів дорого і немає гарантії, що це принесе бажаний результат.

Отож, ми з командою вирішили спробувати. Нам пощастило (лише здалось, що пощастило) отримати вже розмічений групою волонтерів набір даних новин та публікацій, які стосувались російської агресії та були зібрані за період січень-травень 2022 року. Контент датасету був розділений на проросійський або проукраїнський. Команда Data Scientists взялась експериментувати для початку з Doc2Vec, Word2Vec та класичними алгоритмами машинного навчання (XGBoost, Random Forest, Naïve Bayes). Результати не були задовільні. Точність позначок була нижче 75%.

Розбираємось у причинах:

1. Doc2Vec, Word2Vec не здатні цілком охопити контекст повідомлення. Це доволі обмежені алгоритми.
2. Набір даних є двомовним, що ускладнює завдання. Більшість проросійських дописів є російською мовою; проукраїнські можуть бути як українською, так і російською. На той момент було небагато проросійських дописів саме українською мовою. Класифікатор, стикнувшись із текстом українською мовою, був на 99% переконаний, що це проукраїнський контент. Проте, це не завжди виявлялося так.
3. Текст був різноманітної довжини: від 1-2 речень до декількох параграфів із детальним оглядом певних подій. Також, це був мікс різноманітних стилів тексту.
4. А де мітка «нейтральний контент»? Такий теж існує і здатність його класифікувати є дуже важливою! Якщо ми опрацьовуємо потік даних в режимі реального часу, дуже ймовірно, що будуть повідомлення, які й не мають стосунку до війни в Україні.

Врахувавши вищеописані проблеми, ми почали збирати власний датасет з джерел, які репрезентували різноманітні погляди на війну рф проти України. Під час вибору джерел ми враховували:

• наскільки пересічні українці схильні споживати російський контент;
• частоту публікації;
• якої позиції тримається ЗМІ чи майданчик.

Також, важливим є список інфотерористів в Telegram від Центру протидії дезінформації та так званий білий список медіа від Інституту масової інформації.

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

Щоб переконатись у відповідності набору даних для виконання задач машинного навчання, ми побудували простий ML-класифікатор. Проте на цей раз використали більш потужну утиліту — fastText для векторизації та XGBoost для класифікації. Здобуті результати приємно вражали: 0.97 AUC на 0.95 AUC та навчальному та тестовому наборах даних.

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

Ми вирішили скористатись можливостями zero-shot classification із використанням великих мовних моделей. Після ретельного аналізу обрали на той момент GPT-3.5 від OpenAI. Ми сформували prompt і запустили розмітку близько 300 000 записів. На це все пішло понад тиждень, витрати становили менш як $150. Якби використовували GPT-4, то сума була б в десятки разів вищою. Ця LLM-based-розмітка принесла команді такі значення для кожного повідомлення: сентимент; геополітичне спрямування або її відсутність; наявність дискримінаційних патернів.

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

Було дуже цікаво поглянути на результати сентимент-аналізу зібраних текстових даних за джерелом походження. Чому результати сентимент аналізу цікаві? Ми зможемо проаналізувати як сентимент повідомлень в інфопросторі корелює з реальними подіями на полі бою. Переходимо до результатів:

1. Загалом, більшість повідомлень і публікацій у зібраному наборі даних мають негативний сентимент. Це очевидно, оскільки війна за своєю природою є деструктивною.
2. GPT-3.5 класифікував повідомлення з інфоресурсів на три класи: позитивні, негативні, нейтральні. Пізніше, ми з командою проаналізували, як сентимент цих повідомлень, визначених GPT-3.5, змінювався з часом. Відповідно, у першій половині 2022 року сентимент був більш позитивним, ніж у другій половині 2022, а також на початку 2023. Перед літом 2023 (очікуваний контрнаступ) сентимент знову був більш позитивний.

На графіку ми бачимо числа, а не сентимент безпосередньо, тому що позитивний — це 1, нейтральний — 0, а негативний — −1. Для кожного повідомлення ми здійснили таку конвертацію, агрегували та порахували.

Сентимент обчислений з використанням GPT-3.5 за спрямуванням джерела інформації

Як тільки мітки були готові, наступним завданням було здійснити файн-тюнінг мовної моделі, яка б могла точно визначати спрямування тексту. Це можна було би досить просто реалізувати, проте я запропонував ускладнити задачу та натомість розробити багатозадачну (multi-task) модель, здатну прогнозувати одразу всі залежні змінні: сентимент, спрямування, наявність дискримінації, та спрямування ймовірного джерела походження інформації.

Доцільно зазначити, що multi-task learning має й певні недоліки й труднощі у реалізації, зокрема:

• потрібно модифікувати архітектуру нейронної мережі, зокрема додавати output heads, змінювати конфігурації мовної моделі та логіку обчислення функції втрат (loss function);
• навчання такої моделі займе більше часу ніж під час single-task learning, і, відповідно, потребуватиме більше ресурсів;
• точність та ефективність такої моделі буде нижчою.

Окремо слід звернути увагу на функцію втрат (loss function). У нашій архітектурі вона обчислювалась для кожної змінної окремо, проте її було потрібно повернути як єдине значення. Відповідно, ми поставили для кожної змінної окремий ваговий коефіцієнт її важливості під час обчислення функції.

Наступним кроком був підбір мовної моделі. Важливо, щоб вона була multi-lingual, оскільки оперуємо щонайменше двома мовами. Також, ми враховували її відповідності для задач класифікації. Серед ключових кандидатів:

• XLM-RoBERTa;
• MBERT;
• DistilBERT (дистильована версія mBERT);
• mDeBERTa;
• Mt5.

Процес файн-тюнінгу здійснювався в AzureML. Для обчислень обрано віртуальні машини, які працюють на основі NVIDIA Tesla V100 GPUs.

Також довелось погратися з сумісністю Python-бібліотек. Можливо, комусь це буде корисно. Ми використовували transfomers==4.38.0 та PyTorch==1.11.0. Fine-tuning-модель навчалась з використанням класів TrainingArguments та Trainer, які належать до transfomers. Попри правильно встановлені аргументи, ми отримували такий error message: ValueError: prefetch_factor option could only be specified in multiprocessing.let num_workers > 0 to enable multiprocessing. Потративши кілька годин на дослідження проблеми, стало зрозуміло, що найкраще рішення — відкатити transfomers до версії 4.36.*. Після цього все запрацювало.

Fine-tuning здійснювався у 10 epochs. Результати були задовільні. Модель дуже добре себе показала у прогнозуванні геополітичного спрямування повідомлення та спрямування ймовірного джерела походження (точність понад 95%). Дещо гірше з сентиментом (~80%). Щодо наявності дискримінаційних патернів результати теж були хороші (~92%), проте ця змінна була незбалансована та обʼєктивно оцінити результат виявилось важко (для більшої валідності результатів, пропонується обчислювати weighted accuracy).

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

Висновки

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

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

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

Є складність у виявленні ІПСО та пропаганди, дискримінаційних патернів у сучасних реаліях російської агресії проти України. Ми часто стикаємось з ситуацією, коли є повідомлення з 10 речень, девʼять з них — це обʼєктивний опис фактів, а десяте — маніпуляція. Відповідно, модель повинна вміти вловити контекст повідомлення і цілісно врахувати наявність деструктивного контенту. Великі мовні моделі можуть тут бути корисними.

Повернемось до сентименту: більшість рішень для сентимент-аналізу заточені під комерцію та products review. Я не чув про інноваційні рішення, які здатні ефективно визначати сентимент повідомлень у контексті війни та збройного конфлікту. Також потрібно враховувати entity-level sentiment: для якої категорії повідомлення негативне, а для якої позитивне чи нейтральне? Без врахування цих аспектів обʼєктивну картину буде важко отримати. Саме тому ми й розробили multi-task-модель, щоб прогнозувати геополітичне спрямування + сентимент та інші релевантні змінні. Разом з цим, точність прогнозування сентименту залишається такою, яка бажає кращого.

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

Це не таємниця, що у волонтерській дільності (як і в будь-якій іншій) важливою є системність — присвячувати певну кількість годин на день або тиждень для цієї ініціативи та працювати. Якщо ви один раз в місяць починаєте щось робити на кілька годин і повертаєтесь знову через місяць, далеко не зайдете, будьмо обʼєктивні. Роботи для вдосконалення і перспектив — багато. Важливо вміти їх бачити й get your hands dirty. Здобутий результат точно того вартує, і наші рішення є підтвердженням.

Нещодавно чув про школяра, який розробив для ЗСУ «чоботи-павуки», які можуть захистити військових від травм під час вибуху протипіхотних мін. Це є черговим підтвердженням, що долучитись до боротьби проти російської агресії може кожен з нас. Головне — бажання та ресурси.