Контекст#
Стандартні хмарні рішення для видалення персональних даних — AWS Comprehend і Azure AI Language — показують 14% і 37% точності на українських текстах.
Причина проста: обидва сервіси не мають ні навчальних даних з кирилицею, ні підтримки транслітерації за українськими правилами, ні розуміння специфічних ідентифікаторів — РНОКПП, ЄДРПОУ, серій паспортів. AWS Comprehend навчений переважно на англійських текстах з латиницею, Azure AI Language має базову підтримку кирилиці для російської мови, але не розуміє українську специфіку. Обидва сервіси не враховують історичні зміни у транслітерації: до 2010 року діяла одна система, після постанови КМУ №55 — інша. Volodimir став Volodymyr, Irina — Iryna, але старі документи залишились з попередньою транслітерацією. Хмарні сервіси також не розуміють формати українських ідентифікаторів: РНОКПП з 10 цифр, ЄДРПОУ з 8 цифр, серії паспортів типу АА №123456. Для них це просто числа без контексту.
Завдання: побудувати модель, яка працює з реальними українськими даними — кирилицею, транслітерацією (сучасною і до 2010 року), змішаними текстами, юридичними особами і медичними записами. Модель повинна розпізнавати ПІБ у кирилиці та латиниці, телефони у різних форматах (+380, 380, 0), email з українськими доменами, адреси з скороченнями вул., пров., бул., фінансові дані IBAN та номери карток, документи паспорт, РНОКПП, ЄДРПОУ, медичні записи з діагнозами та препаратами, юридичні особи з ПІБ директорів. Критично: модель повинна працювати на CPU без GPU, мати інференс до 100ms, бути детерміністичною для compliance.
Моя Роль#
Я працював як CTO і технічний лід команди з двох інтернів.
60% — Менеджмент і архітектура
Визначав технічну стратегію: вибір підходу knowledge distillation від OpenAI замість навчання з нуля, архітектуру пайплайну, пріоритети розробки. Ставив задачі інтернам, ревʼювив код і результати тренувань, приймав архітектурні рішення. Відповідав за те, щоб команда рухалась у правильному напрямку і не витрачала час на хибні підходи. Планував спринти, розподіляв задачі між інтернами, проводив щоденні стендапи, ревʼювив pull requests, аналізував метрики тренування, приймав рішення про зміну гіперпараметрів. Вибирав між різними підходами: fine-tuning vs training from scratch, RoBERTa vs BERT vs DistilBERT, knowledge distillation vs manual annotation. Кожне рішення обґрунтовував метриками і часом розробки.
30% — Hands-on
Особисто відповідав за MLOps інфраструктуру і деплой у продакшн. Налаштовував середовище тренування, CI/CD для моделей, моніторинг і інференс у проді. Також особисто розробляв правила транслітерації — критична частина, яку інтерни не могли зробити самостійно. Налаштовував Docker контейнери для тренування і інференсу, писав скрипти для версіонування моделей, інтегрував Weights & Biases для трекінгу експериментів, розгортав FastAPI для production API, налаштовував моніторинг латентності і throughput. Правила транслітерації розробляв особисто: аналізував постанову КМУ №55, порівнював з попередніми стандартами, тестував на реальних прикладах з витоків даних, валідував на edge cases.
10% — Менторинг
Пояснював інтернам принципи fine-tuning трансформерів, code review, розбір помилок у тренуванні. Навчав як читати метрики loss і accuracy, як інтерпретувати confusion matrix, як дебажити overfitting і underfitting, як оптимізувати гіперпараметри learning rate, batch size, epochs. Показував як працювати з PyTorch, як використовувати Hugging Face Transformers, як писати custom datasets і dataloaders, як профілювати код для оптимізації швидкості.
Технічне Рішення#
Knowledge distillation від OpenAI
Замість ручної розмітки всього датасету — використали OpenAI як "вчителя" для генерації розмічених прикладів. Це прискорило підготовку навчальних даних і підвищило якість розмітки порівняно з ручним процесом.
Датасет — реальні витоки
Модель навчалась на реальному датасеті витоків українських персональних даних. Це критично: синтетичні дані не відображають реальну варіативність — помилки у іменах, нестандартні формати телефонів, змішані кирилично-латинські тексти.
Правила транслітерації по роках
Окремий компонент для обробки транслітерації. Правила різняться до і після 2010 року (постанова КМУ №55): Volodimir/Volodymyr, Irina/Iryna, Tkachenko/Tkachenko — модель розпізнає обидва варіанти. Це розроблено особисто мною.
RoBERTa fine-tuned на PyTorch
Базова архітектура — roberta-base, fine-tuning для NER задачі з класами: Person, PhoneNumber, Location, SocialMedia, DocumentID.
MLOps і деплой — особисто
Інфраструктура тренування, версіонування моделей, деплой API у продакшн — моя відповідальність від початку до кінця.
Результати Бенчмарку#
Тестував на власному датасеті з 10 категорій, 64 PII-сутності — кирилиця, транслітерація, змішані тексти, фінансові дані, медичні записи, юридичні особи.
| Категорія | Точність |
|---|---|
| ПІБ кирилицею | 100% |
| Транслітерація сучасна (post-2010) | 100% |
| Транслітерація стара (pre-2010) | 100% |
| Телефони + email | 90% |
| Складний змішаний текст | 90% |
| Фінансові дані (IBAN, картки) | 80% |
| Юридичні особи + директор | 80% |
| Медичні дані | 80% |
| Документи (паспорт, РНОКПП) | 86% |
| Адреси | 67% |
Загальна точність: ~76–87%
Порівняння з конкурентами на українських даних
| Інструмент | Точність |
|---|---|
| AWS Comprehend | 14% |
| Azure AI Language | 37% |
| PII Removal (наша модель) | 76–87% |
Результат: +105% до Azure, +450% до AWS на українських текстах.
Що Відомо Про Прогалини#
Boundary clipping
Модель обрізає краї токенів на початку і кінці сутностей. Проявляється у коротких текстах без контексту. У PDF-тесті з довшими фрагментами проблема зменшується: контекст допомагає.
Адреси (67%)
Назви вулиць без слова "вул." пропускаються. Потребує окремого класу і додаткових прикладів.
ЄДРПОУ і номери паспортів
За ЗУ "Про захист персональних даних" паспортні дані фізособи є персональними. ЄДРПОУ — публічний реєстр держави. Модель поки не розрізняє ці два класи явно — наступна ітерація.
При фіксі boundary clipping і розширенні класифікатора для документів — модель виходить на 90%+.
Що Далі#
- →Фікс boundary clipping через донавчання на граничних кейсах
- →Окремий клас для DocumentID з підтипами: паспорт, РНОКПП, ЄДРПОУ, ІПН
- →Розширення датасету для адрес — без явних маркерів типу "вул."
- →Підтримка PDF з кирилицею без втрати encoding (поточний артефакт nnn)
Стек#
Python
Основна мова
PyTorch
ML framework
RoBERTa
Transformer model
Knowledge Distillation
Оптимізація моделі
OpenAI API
Генерація даних
FastAPI
API framework
Docker
Контейнеризація
MLOps
Deployment
FAQ#
Чому не використали готові рішення AWS або Azure?
AWS Comprehend показує 14% точності на українських текстах, Azure AI Language — 37%. Обидва не мають навчальних даних з кирилицею і не розуміють українські ідентифікатори РНОКПП, ЄДРПОУ. Наша модель досягає 76-87% точності завдяки навчанню на реальних витоках українських даних з підтримкою кирилиці, транслітерації за правилами до і після 2010 року, розпізнаванням специфічних форматів документів та ідентифікаторів. Хмарні сервіси не можуть обробляти змішані кирилично-латинські тексти, не розуміють варіативність українських імен у транслітерації та не враховують особливості форматування персональних даних у локальних документах і базах даних. Додатково, хмарні рішення мають обмеження по приватності даних: передача персональних даних на зовнішні сервери може порушувати GDPR та українське законодавство про захист персональних даних.
Чому RoBERTa, а не GPT?
RoBERTa — спеціалізована модель для NER задач з швидким інференсом 50-100ms на CPU. GPT — генеративна модель, яка потребує більше ресурсів і менш передбачувана для класифікації. Для production PII removal потрібна швидкість і точність, а не генерація тексту. RoBERTa навчена на masked language modeling, що робить її ідеальною для розуміння контексту і класифікації токенів. Вона споживає менше памʼяті, працює швидше на CPU без GPU, має детерміністичний output для кожного input, що критично для compliance і аудиту. GPT потребує GPU для прийнятної швидкості, має варіативний output навіть з temperature=0, споживає у 3-5 разів більше памʼяті. Для задач класифікації і NER RoBERTa показує кращі результати при менших витратах ресурсів.
Що таке knowledge distillation від OpenAI?
Замість ручної розмітки тисяч прикладів ми використали OpenAI як вчителя для генерації розмічених даних. Це прискорило підготовку датасету і підвищило якість розмітки порівняно з ручним процесом. Процес виглядає так: беремо неразмічений текст з реальних витоків, передаємо в OpenAI API з промптом для розпізнавання PII, отримуємо розмічені сутності, валідуємо результат, додаємо в тренувальний датасет. Це дозволило створити понад 10000 розмічених прикладів за тиждень замість місяців ручної роботи. Якість розмітки вища за ручну, бо OpenAI розуміє контекст краще за людину-аннотатора без спеціалізації. Підхід knowledge distillation дозволяє отримати компактну модель з якістю близькою до великої teacher моделі, але з набагато меншими вимогами до ресурсів.
Чому модель навчалась на реальних витоках даних?
Синтетичні дані не відображають реальну варіативність: помилки у іменах, нестандартні формати телефонів, змішані кирилично-латинські тексти. Реальні витоки дають модель розуміння того, як виглядають дані в продакшені. У реальних даних зустрічаються опечатки в іменах, неповні адреси, телефони без кодів країн, email з помилками, змішані формати дат, транслітерація за різними стандартами, застарілі формати документів. Синтетичні датасети генерують ідеальні приклади, які не готують модель до реального світу. Навчання на витоках дає модель стійкість до шуму, розуміння контексту і здатність розпізнавати PII навіть у некоректно відформатованих текстах. Це критично для роботи з legacy системами та базами даних з неконсистентним форматуванням даних та складною структурою.
Що з boundary clipping?
Модель іноді обрізає краї токенів на початку і кінці сутностей. Це проявляється у коротких текстах без контексту. Фікс — донавчання на граничних кейсах. У довших текстах PDF проблема менш помітна. Причина в токенізації: RoBERTa розбиває текст на subword tokens, і якщо сутність починається або закінчується на рідкісний subword, модель може пропустити його. Наприклад, Ткаченко може токенізуватись як Тка-чен-ко, і модель може пропустити Тка або ко. Рішення: розширити тренувальний датасет прикладами з граничними токенами, додати augmentation з обрізанням контексту, використати CRF layer для врахування залежностей між токенами. Також планується експеримент з різними токенізаторами для кращої обробки українських слів та морфології української мови.