Presidio е мощен. Това също е 3-седмичен проект за настройка. Ето управляваната алтернатива.
Microsoft Presidio е добре проектирана, мощна рамка за откриване и анонимизиране на PII. Освен това, според консенсуса на общността, това е значителна инженерна инвестиция за внедряване в производството.
GitHub Издание #237 („Синтактични грешки при използване на анализатора като пакет на Python“) представлява категория проблеми, с които се сблъскват дори опитни разработчици на Python: конфликти в средата, грешки при зареждане на модела и проблеми с конфигурацията на API, които изискват дни на отстраняване на грешки преди първото успешно анонимизиране.
Доказателството на общността
Хранилището Presidio GitHub има хиляди звезди — силен сигнал за интерес и приемане. Списъкът с отворени проблеми разказва различна история за триенето при внедряване:
Проблеми с конфигурацията на средата: Несъвместимост на версията на Python, конфликти на версията на модела spaCy, грешки по време на изпълнение на ONNX и грешки при инсталация, специфични за платформата. Тези проблеми засягат опитни разработчици, които следват точно документацията.
Неуспешно зареждане на модела: Моделите spaCy са изтеглени успешно, но не успяват да се заредят в определени среди (контейнерни среди, конфигурации с ограничена памет, някои облачни доставчици). Отстраняването на грешки изисква разбиране на вътрешните функции за управление на модела на spaCy.
Грешки на производствения API: Presidio API работи в процес на разработка, но се проваля при производствено натоварване поради проблеми с нишките, натиск на паметта от NLP модели или разлики в конфигурацията между разработката и производството.
Сложност на интеграцията: Блогът Ploomber на Presidio документира сложността на архитектурата: множество микроуслуги (анализатор, анонимизатор, опционално редактор на изображения), координация между тях и допълнителни разходи за сериализиране на данни на комуникационния модел между услугите.
Калъфът от плат Microsoft
Собствената документация на Microsoft Fabric за използване на Presidio с PySpark демонстрира разликата между „наличен“ и „работещ“:
Публикацията в блога, озаглавена „Поверителност чрез дизайн: Откриване и анонимизиране на PII с PySpark на Microsoft Fabric“, изрично отбелязва, че използването на Presidio в този контекст „изисква управление на външни зависимости и персонализирана логика“. За потребителите на Fabric, които са избрали управлявана облачна платформа специално, за да избегнат управлението на инфраструктурата, необходимостта да управляват външни зависимости отново въвежда сложността, която са се опитвали да избегнат.
Необходимите стъпки за интегриране на PySpark + Presidio:
- Инсталирайте presidio-analyzer и presidio-anonymizer в преносими компютри Fabric
- Изтеглете spaCy модели в средата Fabric
- Напишете PySpark UDF обвивки за Presidio функции (пакетната обработка изисква UDF модели)
- Справете се със сериализацията на модела spaCy за разпределено изпълнение (моделите не могат да бъдат наивно споделяни между работници на Spark)
- Конфигурирайте откриването на език за многоезични набори от данни
Всяка от тези стъпки има документирани режими на отказ. Екипите, които избират Presidio за обработка на PySpark, рутинно прекарват 1-2 седмици в тази интеграция, преди да обработят първия си документ.
Алтернативата „Управляван опит“.
Моделът на управляваната услуга обръща предизвикателството за настройка на Presidio:
Presidio самостоятелно хостван път:
- Инсталирайте Docker
- Конфигурирайте docker-compose.yml
- Изтеглете spaCy модели
- Отстраняване на грешки в мрежата на контейнера
- Конфигурирайте крайните точки на API
- Откриване на тестов обект
- Отстраняване на фалшиви положителни и отрицателни грешки
- Внедрете персонализирани разпознаватели за нестандартни обекти
- Добавяне на журнал за проверка
- Конфигурирайте за производствено натоварване
Време до първия анонимизиран документ: 3-21 дни в зависимост от средата и изискванията.
Управляван сервизен път:
- Създайте акаунт
- Качете документ или извикайте API
Време до първия анонимизиран документ: 12 минути.
Същата способност за откриване (Presidio двигател + подобрение на XLM-RoBERTa), предоставена чрез инфраструктура, управлявана от някой друг.
Където управляваните и самостоятелно хостваните се разминават
Управляваната услуга не е подходяща за всеки случай на употреба. Конкретни сценарии, при които самостоятелно хостваният Presidio остава правилният избор:
Обучение по персонализиран модел: Ако вашият случай на употреба изисква обучение на нови NER модели за специфични за индустрията субекти (патентовани имена на лекарства, вътрешни кодове на продукти, изискващи откриване на ML, а не съпоставяне на шаблони), самостоятелно хостваното ви дава инфраструктурата за обучение на модела.
Дълбока тръбопроводна интеграция: Обработката на Spark, при която откриването на PII трябва да се изпълнява в рамките на изпълнителя на Spark (а не като външно извикване на API), изисква самостоятелно хостване. API за управлявана услуга добавя мрежови двупосочни разходи, неподходящи за вградена обработка на Spark.
**Пълен контрол на инфраструктурата: ** Някои позиции за сигурност забраняват всякакви външни зависимости на API в тръбопроводите за обработка на данни. Настолното приложение (офлайн) е управляваната алтернатива тук; самостоятелно хостван Presidio е чистата самостоятелна опция.
За 90%+ от случаите на използване, които са обработка на документи, интегрирани с API работни потоци или инструменти за съответствие — управляваната услуга елиминира инфраструктурния проект.
Пътят за безплатна оценка на ниво
Безплатното ниво на управляваната услуга предоставя 200 токена на месец — достатъчно за стартиране на реални документи за оценка чрез двигателя за откриване без ангажимент или кредитна карта.
За екипи, обмислящи Presidio срещу управлявана услуга:
Седмица 1: Конфигуриране на самостоятелно хостван Presidio в процес на разработка. Оценете сложността на производствената конфигурация.
Ден 1, паралелен: Създайте акаунт за управлявана услуга. Изпълнете същите документи за оценка чрез управлявания API. Сравнете резултатите.
Критерии за вземане на решение:
- Управляваната услуга открива ли типовете обекти, от които се нуждаете? (285+ обекта спрямо ~40 по подразбиране на Presidio)
- Точността на откриване приемлива ли е за вашия случай на употреба?
- Дизайнът на API отговаря ли на вашия модел на интеграция?
- Ценовият модел подходящ ли е за вашия обем?
Ако отговорите са да: управляваната услуга елиминира инфраструктурния проект. Ако не: конкретните пропуски, които идентифицирате (персонализирани ML модели, изпълнение на Spark, пълна изолация) са истински причини за самостоятелно хостване.
Заключение
3-седмичният график за настройка на Presidio не е провал на документацията или проекта. Това е точно отражение на това какво изисква внедряването на NLP инфраструктура от производствен клас. Инженерните предизвикателства са реални и разрешими — просто изискват време и опит.
За екипи, където анонимизирането на PII е изискване за съответствие, а не основно инженерно предизвикателство, алтернативата на управляваната услуга предоставя еквивалентна способност за откриване без инфраструктурния проект. 12-минутният път от създаването на акаунт до първия анонимизиран документ прави разходите за оценка минимални.
Източници: