Крізь хвилі. Як вижити в епоху ШІ.

Тепер, коли попередню версію нового інтерфейсу musdb нарешті випущено, з’явився час написати й про інші аспекти роботи museum-digital. Про більш звичні труднощі. А саме: про нові, ще масштабніші хвилі AI-скраперів і ботів, які з липня цього року знову почали створювати проблеми для наших сервісів.

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

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

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

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

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

Через десять років після формалізації принципів FAIR нарешті з’явився хтось, хто повторно використовує наші дані у величезних масштабах. Здавалося б, варто радіти. На жаль, усі наші попередні уявлення про те, як саме відбуватиметься таке повторне використання, виявилися хибними.

Радіти AI-скраперам?

AI-скрапери, які засипають вебсервіси, а особливо великі й давно усталені інфраструктури, величезною кількістю запитів, стали постійною проблемою приблизно два роки тому. Минулого року museum-digital зіткнувся з першою великою хвилею AI-скраперів. Про це ми писали в попередніх дописах (1, 2, 3).

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

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

Але принципи залишаються принципами.

Не можна заперечувати, що кінцевою метою AI-скрапінгу все-таки є повторне використання. Хоча скрапери використовують HTML замість API, які ми з любов’ю для них створили, вони взаємодіють із нашими сервісами у найбільш доступний для них спосіб.

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

У museum-digital ми сприйняли нові запити як можливість удосконалити наше програмне забезпечення. Якщо воно витримує навалу тисяч ботів за секунду, можна впевнено сказати, що воно пройшло перевірку в бойових умовах і є стабільним. Водночас удосконалення нашого програмного забезпечення для публікації даних означало й відмову від функцій, які споживали надто багато ресурсів. Минулого року ми прибрали більшість загальнодоступних можливостей генерування PDF на сервері, а API IIIF перенесли до окремої конфігурації, розрахованої на те, що вона може вийти з ладу, не порушуючи роботу решти наших сервісів. Ми покращили обробку пошукових запитів і запровадили обмеження частоти запитів, тобто кількості запитів, які одна IP-адреса може виконати протягом певного часу.

Нова хвиля AI-скраперів, що почалася в липні, ще масштабніша за минулорічну. Цих удосконалень виявилося недостатньо, щоб забезпечити стабільну роботу нашого основного сервера, на якому розміщені робочі бази даних.

Від кожного за його можливостями: скидання навантаження

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

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

• Скрапери переходять за посиланнями на сторінках пошуку, особливо у фасетному пошуку, і зрештою комбінують дедалі більше параметрів. Малоймовірно, що людина шукатиме об’єкти, які «пов’язані з Берліном, і пов’язані з Німеччиною, і пов’язані з установою X, але не пов’язані з установою Y, а також пов’язані з періодом між 1990 і 2000 роками». Для автоматизованого скрапера це цілком нормальна поведінка.
• Якщо опубліковану сторінку об’єкта оновлено, автоматично зберігається знімок її поточного стану, щоб забезпечити доступ до архівної версії сторінки на певний момент часу. Передусім це потрібно дослідникам, щоб вони могли посилатися на конкретний стан сторінки. У повсякденній роботі архівні сторінки майже не використовуються. Вони також виключені з індексації пошуковими системами. Однак постійне створення нових знімків призводить до появи великої кількості посилань та окремих сторінок, які скрапери можуть сканувати без жодної користі для будь-кого.

Обидві функції справді корисні, але погано масштабуються.

Тому ми запровадили скидання навантаження (load shedding). Щоразу, коли виконується пошук або відкривається архівна сторінка, система перевіряє поточне навантаження на сервер. Якщо воно перевищує певний поріг, сервер не виконує складні пошукові запити, причому залежно від рівня навантаження пошук може бути обмежений щонайменше трьома параметрами, або не завантажує архівну сторінку. Натомість користувач бачить попередження про те, що відповідна дія наразі недоступна, а сервер надсилає спеціальний код помилки HTTP. Якщо одна й та сама IP-адреса двічі спричиняє надсилання цього коду, її на певний час блокують.

На момент написання цієї статті за два місяці ми таким чином заблокували загалом 131 014 530 IP-адрес, з яких 5 802 771 заблоковано зараз.

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

На жаль, цей підхід працює на рівні блокування цілих IP-адрес. Оскільки «резидентські проксі», які раніше ми просто називали ботнетами, що заражають домашні роутери, стають дедалі серйознішою проблемою, цілком можливо, що звичайні користувачі, які справді зацікавлені в museum-digital, самі того не знаючи, також розміщують у себе вдома AI-скрапер. Боюся, я вже зіткнувся з таким випадком: одна колега без жодної очевидної причини не могла отримати доступ до museum-digital зі своєї домашньої мережі. В іншому цей підхід виявився напрочуд ефективним: кількість запитів майже не зменшилася, але наші сервіси тепер загалом працюють стабільно.

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

Гра з цифрами: стратегія журналювання

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

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

Справедливість і FAIRність

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

І знову ж таки, нам поки що не довелося модернізувати обладнання та платити за це, хоча зрештою це, можливо, все-таки буде потрібно. Та й з інших причин це може бути цілком розумним рішенням.

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

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

(Зображення до допису згенеровано за допомогою Anima Base v1)