Machine Unlearning: Практичний робочий процес видалення даних з AI

Якщо хтось просить вас видалити його дані з AI-системи, видалення одного рядка з бази даних — це не вся робота. Machine unlearning може зменшити або перенаправити реакцію моделі на конкретні навчальні приклади, але він автоматично не очищає решту стека: векторні індекси, fine-tuned адаптери, кешовані промпти, чекпоїнти, репліки, резервні копії та експорти. NIST визначає machine unlearning як вибіркове видалення впливу конкретних навчальних точок із навченої моделі й прямо зазначає, що ефективні наближені методи можуть не вимагати повного перенавчання з нуля. Це вужче, ніж твердження «вся система забула ці дані». NIST

Для більшості команд практична відповідь має кілька рівнів. Спочатку простежте, куди потрапили дані. Потім припиніть їх повторне використання. Далі видаліть або обмежте похідні артефакти. І лише після цього вирішуйте, чи потребують ваги моделі перенавчання або наближеного unlearning. У Google's 2023 Machine Unlearning Challenge використано саме таке орієнтоване на модель формулювання: модель після unlearning має бути складною для відрізнення від моделі, перенавченої без forget set, водночас зберігаючи продуктивність на retain set. Google Research

Зміст

Що насправді означає machine unlearning

Machine unlearning — це операція на рівні моделі. Йдеться про зменшення впливу вибраних даних на поведінку навченої моделі. Це може означати точне перенавчання на retain set або наближений метод, який прагне отримати достатньо близький результат без повної вартості перенавчання. NIST використовує обидві ідеї у своєму глосарії, а сторінка Google's challenge визначає еталонний стандарт як схожість із моделлю, перенавченою з нуля без забутих прикладів. NIST Google Research

Це визначення важливе, оскільки AI-системи рідко обмежуються вагами моделі. Production-стек зазвичай містить:

Видалення лише на одному з цих рівнів усе одно може залишити дані доступними десь іще. На практиці «видалити ці дані з AI» — це спочатку проблема lineage, а вже потім проблема редагування моделі.

Чому звичайного процесу видалення недостатньо

Багато AI-продуктів ніколи не навчалися на даних, які їх просять видалити. Вони лише отримували їх під час inference. У такому разі потрібно видалити вихідні записи, похідні embeddings, кеші та шляхи доступу. Machine unlearning не має значення, оскільки ваги моделі ніколи не змінювалися.

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

Саме тому «кнопка видалення» — неправильна ментальна модель. Правильна модель — це видалення в заданому обсязі плюс докази.

Практичний робочий процес із семи кроків

1. Визначте обсяг запиту та призупиніть повторне використання

Почніть із точних ідентифікаторів: ID користувача, hash файлу, ID документів, назви vector collections, ID навчальних batch або посилання на тікети. Потім припиніть нове повторне використання. Призупиніть ingestion, retraining, export jobs або syncs, які могли б відтворити ті самі дані під час очищення.

Якщо запит пов’язаний із приватністю, тримайте юридичне формулювання вузьким. Стаття 17 GDPR створює право на стирання за визначених обставин, але не вказує, до якого технічного рівня звертатися спочатку. У висновку European Data Protection Board від 18 грудня 2024 року щодо AI-моделей також зазначено, що моделі, навчені на персональних даних, не в усіх випадках можна вважати анонімними. Зберігайте явний процес видалення, а не припускайте, що модель перебуває поза межами scope. EUR-Lex EDPB

2. Простежте lineage, перш ніж щось видаляти

Відобразіть повний шлях:

3. Видаліть або обмежте вихідні та похідні артефакти

Тепер очистьте все, що можна очистити детерміновано:

У публічному AnythingLLM issue повідомлялося, що embeddings видалених документів нібито залишалися доступними для retrieval в одному налаштуванні на базі Weaviate. Один issue — це анекдотичний доказ, а не висновок щодо всієї платформи. Проте він показує, чому кожен процес видалення потребує negative retrieval test для ID документів, характерних фраз і перефразувань.

4. Визначте, чи змінилися ваги моделі взагалі

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

Google's 2023 challenge визначає мету на рівні моделі: модель після unlearning має нагадувати модель, перенавчену без забутих прикладів, водночас зберігаючи корисну поведінку, набуту з решти даних. Google Research

5. Створіть evaluation sets до зміни ваг

Вам потрібні щонайменше три зрізи:

*Підпис: Робота з видалення починається з data lineage і похідних артефактів. Model unlearning починається лише після того, як ви доведете, чи були зачеплені ваги.*

6. Тестуйте forgetting і збережену корисність разом

Найновіші дослідження чітко показують компроміс.

Стаття *Behavioral Audit of Machine Unlearning Has a Privacy Cost* стверджує, що для опуклих моделей black-box behavioral audit не може одночасно виявляти недостатній unlearning і не розкривати чесному, але допитливому аудитору інформацію про належність до retain set. Автори також наводять емпіричні докази того, що ця напруга зберігається в неопуклих налаштуваннях. Це означає, що один чистий показник аудиту — не те саме, що універсальний доказ безпечного forgetting. arXiv

Audit framework від Google Research від 10 червня 2026 року підходить до проблеми з іншого боку. Він пропонує Regularized f-Divergence Kernel Tests, щоб зробити auditing чутливішим і надійніше контролювати false positives для різних розмірів вибірки. Результат є статистичним тестом, а не доказом повного видалення. Google Research

PrivUn розділяє три рівні відновлення: direct retrieval, in-context recovery і restoration through fine-tuning. Використовуйте рівні, які відповідають вашому доступу до моделі. Відмова на оригінальний prompt може пройти першу перевірку, тоді як сильніший шлях відновлення все ще може розкрити цільові дані.

7. Виведіть застарілі артефакти з експлуатації та збережіть докази

Після роботи на рівні моделі видаліть або ізолюйте застарілі replicas, checkpoints, adapters і caches. Потім збережіть пакет доказів:

Саме ці докази перетворюють процес видалення на те, що можуть перевірити support, security, legal та engineering.

Що насправді підтверджують найновіші дослідження unlearning

Три нещодавні статті тут корисні, але вони підтверджують різні твердження.

Behavioral audits не є безкоштовними

Стаття про behavioral auditing від червня 2026 року є найсильнішим застереженням проти перебільшених тверджень. Її основний результат не полягає в тому, що «unlearning неможливий». Результат вужчий і корисніший: за умов нечесного власника та чесного, але допитливого аудитора behavioral audit може створити компроміс між приватністю та аудитом. Якщо ваша compliance-історія спирається лише на black-box probing, ви можете розкрити інформацію про retained data, намагаючись перевірити forgetting. arXiv

Цільове редагування може працювати на вибраних benchmark

*ZeroUnlearn* дає оптимістичніший результат. Він переосмислює machine unlearning як проблему model editing, повідомляє про сильні результати benchmark на Llama-3.2, Llama-3.1 і Qwen-3 та стверджує, що його closed-form few-shot update утримує крок SVD нижче 0.3 секунди на MCF і ZsRE, тоді як end-to-end editing зростає приблизно від 0.04 години для 10 samples до 3.35–3.82 години для 1000 samples, із загальною пам’яттю близько 14.9–17.4 GB. Ці числа важливі, оскільки показують, що наближений unlearning не обов’язково надто дорогий для тестування. arXiv

Але обмеження важливіші за заголовковий результат. Стаття оцінює вибрані open models і benchmark datasets, такі як MCF, ZsRE та адаптовану single-hop версію MQUAKE. Вона також використовує targeted layer selection, щоб не пошкодити загальні можливості. Це доказ перспективного видалення фактів у масштабі benchmark, а не доказ того, що production-система повністю стерла кожну копію чутливої інформації. arXiv

Постійне видалення все ще слабке в multimodal системах

*ICU-Bench* є противагою, що протвережує. Benchmark містить 1,000 privacy-sensitive profiles із медичних звітів і трудових договорів, 9,500 зображень, 16,000 question-answer pairs і 100 послідовних forget tasks. Висновок простий: сучасні multimodal unlearning methods мають труднощі в continual settings і не можуть одночасно зберегти якість forgetting, retained utility та стабільність довгих послідовностей. Якщо ваш продукт отримує повторні запити на видалення з часом, цю статтю варто прочитати до того, як обіцяти чисту автоматизацію. arXiv

Разом ці статті підтверджують практичну позицію:

Що обіцяти користувачам і зацікавленим сторонам

Обіцяйте менше. Перевіряйте більше.

Добре формулювання звучить так:

Погане формулювання звучить так:

Якщо вам потрібне коротке правило, використовуйте це: machine unlearning — це один рівень у ширшому робочому процесі видалення даних з AI.

FAQ

Чи змушує видалення рядка з vector database LLM забути дані?

Ні. Воно може зупинити retrieval path, який повторно вводить дані, і для RAG-систем це часто є правильним першим виправленням. Але якщо той самий вміст використовувався для fine-tuning, continual training або persistent model memory, саме видалення рядка з vector store не змінює ваги.

Чи може machine unlearning довести, що моїх даних більше немає в жодній копії моделі?

Сам по собі — ні. Найновіші дослідження auditing показують, що black-box audits мають обмеження, а production-системи часто містять caches, adapters, checkpoints, replicas і backups поза поверхнею моделі, яку перевіряють. Вам потрібні докази на рівні системи, а не лише показник на рівні моделі. arXiv Google Research

Перевірка тверджень

Джерела