OpenAI Privacy Filter 소개
(openai.com)- 비정형 텍스트에서 개인식별정보를 탐지하고 마스킹하는 오픈웨이트 모델로, 로컬 실행을 통해 필터링 전 데이터가 장치를 벗어나지 않게 할 수 있음
- 양방향 토큰 분류와 span decoding을 결합해 입력을 한 번에 라벨링하고, 최대 128,000토큰 문맥에서 PII span을 빠르게 복원하도록 설계됨
- 전화번호나 이메일 형식에 의존하는 규칙 기반 방식과 달리, 언어·문맥 인식을 바탕으로 공개 정보와 마스킹이 필요한 정보를 더 잘 구분함
- 공개 데이터와 합성 데이터를 함께 사용해 학습했고, PII-Masking-300k에서 F1 96%, 보정 버전에서 F1 97.43% 를 기록했으며 소량 데이터로도 도메인 적응 성능이 54%에서 96%로 올라감
- 익명화 도구나 컴플라이언스 인증 대체물은 아니며, 고민감 영역에서는 사람 검토와 도메인별 평가, 추가 미세조정이 여전히 중요함
제품 개요와 배포 방식
- 개인식별정보 탐지·가림에 특화된 오픈웨이트 모델로, 텍스트에서 PII를 찾아 마스킹하거나 삭제할 수 있음
- 로컬 실행을 지원해 필터링 전 데이터가 장치를 벗어나지 않게 할 수 있고, 서버로 보내 비식별화할 때보다 노출 위험을 줄일 수 있음
- 긴 입력을 빠르게 처리하도록 설계됐으며, 한 번의 패스로 가림 여부를 결정할 수 있음
- 개발자는 자체 환경에서 실행하고, 자체 사용 사례에 맞게 미세조정해 학습·인덱싱·로깅·검토 파이프라인에 더 강한 프라이버시 보호를 넣을 수 있음
- Hugging Face와 GitHub에서 Apache 2.0 라이선스로 공개됐고, 실험·커스터마이징·상용 배포까지 염두에 둠
기존 방식과 다른 점
- 전통적인 PII 탐지 도구는 전화번호나 이메일 주소 같은 형식에 대한 결정적 규칙에 의존하는 경우가 많음
- 이런 방식은 좁은 범위에서는 잘 동작할 수 있지만, 더 미묘한 개인정보를 놓치기 쉽고 문맥 처리에도 약함
- Privacy Filter는 더 깊은 언어·문맥 인식을 바탕으로 비정형 텍스트에서 더 넓은 범위의 PII를 탐지할 수 있음
- 공개 정보라서 보존해야 할 정보와, 개인과 연결돼 마스킹하거나 삭제해야 할 정보를 더 잘 구분하도록 설계됨
- 기존 수준을 넘어 프라이버시 기준을 끌어올리려는 목적 아래 개발됐고, 내부 프라이버시 보존 워크플로에도 미세조정 버전을 쓰고 있음
모델 구조와 탐지 범위
- 양방향 토큰 분류 모델에 span decoding을 결합한 구조를 사용함
- 자기회귀 사전학습 체크포인트에서 시작한 뒤, 고정된 프라이버시 라벨 체계 위의 토큰 분류기로 적응시킴
- 텍스트를 토큰별로 생성하지 않고 입력 시퀀스를 한 번에 라벨링한 뒤, 제약된 Viterbi 절차로 일관된 span을 복원함
- 이 구조 덕분에 모든 토큰을 단일 forward pass로 라벨링하는 고속·고효율 특성을 보임
- 주변 문맥을 활용해 PII span을 판별할 수 있고, 공개 모델은 최대 128,000 토큰 문맥을 지원함
- 운영 환경에 맞춰 재현율과 정밀도 사이의 균형점을 조정할 수 있음
- 공개된 모델은 전체 1.5B 파라미터를 가지며, 활성 파라미터는 50M임
- 예측 범주는
private_person,private_address,private_email,private_phone,private_url,private_date,account_number,secret의 8개임 account_number는 신용카드 번호와 은행 계좌번호를 포함한 다양한 계정 번호를 가리는 데 쓰이고,secret은 비밀번호와 API 키 같은 항목을 다룸- 라벨은 BIOES span 태그로 디코딩돼 더 깔끔하고 일관된 마스킹 경계를 만듦
학습 과정과 평가 결과
- 프라이버시 taxonomy를 먼저 만들고, 모델이 탐지해야 할 span 유형을 정의함
- 개인 식별자, 연락처 정보, 주소, 비공개 날짜, 신용·은행 정보를 포함한 여러 계정 번호, API 키와 비밀번호 같은 secret을 포함함
- 사전학습 언어 모델의 language modeling head를 token-classification head로 교체한 뒤, 지도학습 분류 목표로 후속 학습함
- 공개 데이터와 합성 데이터를 섞어 학습해 현실적인 텍스트와 까다로운 프라이버시 패턴을 함께 포착하도록 구성함
- 공개 데이터에서 라벨이 불완전한 부분은 모델 보조 주석과 검토로 커버리지를 높임
- 합성 예시는 형식, 문맥, 프라이버시 하위 유형 전반의 다양성을 늘리는 데 쓰임
- 추론 시에는 토큰 단위 예측을 제약된 시퀀스 디코딩으로 일관된 span으로 변환함
- 표준 벤치마크와 더 어려운 문맥 민감 사례를 겨냥한 추가 합성·채팅형 평가를 함께 수행함
- PII-Masking-300k에서 F1 96%, 정밀도 94.04%, 재현율 98.04%를 기록함
- 검토 과정에서 확인한 데이터셋 주석 문제를 반영한 보정 버전에서는 F1 97.43%, 정밀도 96.79%, 재현율 98.08%를 기록함
- 소량 데이터만으로도 도메인 적응이 빠르게 이뤄졌고, 평가한 도메인 적응 벤치마크에서 F1이 54%에서 96% 로 올라감
- 모델 카드에는 코드베이스의 secret 탐지와 다국어·적대적·문맥 의존 예시에 대한 스트레스 테스트도 담김
한계와 사용 시 주의점
- 익명화 도구도 아니고, 컴플라이언스 인증도 아니며, 고위험 환경에서 정책 검토를 대체하지도 않음
- 프라이버시 중심 설계 전체 시스템의 한 구성요소로 놓임
- 동작 특성은 학습에 사용한 라벨 taxonomy와 판단 경계의 영향을 받음
- 조직마다 원하는 탐지·마스킹 정책이 다를 수 있어, 도메인 내 평가나 추가 미세조정이 필요할 수 있음
- 학습 분포와 다른 언어, 문자 체계, 이름 규칙, 도메인에서는 성능이 달라질 수 있음
- 드문 식별자나 애매한 개인 참조를 놓칠 수 있고, 특히 짧은 시퀀스처럼 문맥이 제한될 때 과도하게 또는 부족하게 가릴 수 있음
- 법률·의료·금융 같은 고민감 영역에서는 사람 검토와 도메인별 평가, 미세조정이 여전히 중요함
공개 의도와 향후 방향
- 프라이버시 보호는 연구, 제품 설계, 평가, 배포 전반에 걸친 지속적 과제로 다뤄짐
- 좁게 정의된 현실 과업에서 frontier 수준 성능을 내는 작고 효율적인 모델의 중요성을 반영함
- 프라이버시 보존 인프라는 더 쉽게 점검하고, 실행하고, 적응시키고, 개선할 수 있어야 한다는 목표 아래 공개됨
- 모델이 세계에 대해 학습하되 개인의 사적 정보는 학습하지 않도록 돕는 도구로 놓임
- 이번 프리뷰 공개는 연구·프라이버시 커뮤니티의 피드백을 받아 성능을 더 개선하기 위한 단계이기도 함
Hacker News 의견들
- 이런 기능은 몇 년 전에 이미 구현해봤고, 그 결과 몇 가지가 분명했음
PII 정제는 UX를 유지하려면 클라이언트에서 다시 되돌려야 함. 예를 들어 이름이 John인데[NAME]으로 가려진 상태로 모델이Hi [NAME]이라고 답하면, 사용자에게 보여주기 전에Hi John으로 복원해야 함
결국 사용자가 상호작용하는 계층에 역치환 메커니즘이 필요함
또 가려진 PII 데이터는 대부분의 목적에서 거의 쓸모가 없음. 모델은 어느 정도 실제 데이터가 있어야 작동하는데, PII로 분류되는 항목이 워낙 많아서 단순 채팅은 괜찮아도 사용자가 LLM과 복잡하게 상호작용해야 하는 경우엔 난도가 크게 올라감. 아예 아무것도 못 하거나 hallucination이 생길 수도 있음
그래서 플랫폼 차원에선 지원하지만, 이런 한계 때문에 실제로는 잘 쓰이지 않음
현실적인 방법은 보안 위험이 큰 일부 PII만 제거하고, PII를 최대한 빨리 폐기하는 신뢰 가능한 모델을 쓰는 편이라고 봄. 그러려면 시스템 설계도 꽤 달라져야 함 - https://github.com/KevinXuxuxu/anon_proxy를 만들고 있음. LLM 제공자 앞에 두는 익명화 프록시 비슷한 도구임
모델 기반 탐지와 regex PII detection을 함께 쓰고, API 요청과 응답에서 치환과 복원을 양방향으로 처리함. 탐지 모델을 로컬에서 호스팅하면 PII가 로컬 환경 밖으로 나가지 않음
법률, 세금, 이민 같은 민감한 문서를 다룰 때 특히 유용했음- 이 방식의 좋은 점은 어떤 모델이든 붙일 수 있다는 데 있음
다만 대화의 전체 맥락 자체는 여전히 모델과 운영자가 볼 수 있음
그래서 나는 Moxie의 Confer처럼 https://confer.to/ 전체를 암호화해서 최종 사용자 외엔 평문을 못 보게 하는 접근이 더 마음에 듦 - 응답 쪽 복원 처리를 어떻게 하는지 궁금함
문서를 입력에서 가렸다면 LLM 출력도 가려진 내용일 텐데, 그 다음엔 어떻게 이어가는지 모르겠음
- 이 방식의 좋은 점은 어떤 모델이든 붙일 수 있다는 데 있음
- 이번 릴리스엔 기술적으로 흥미로운 부분이 꽤 있음
Privacy Filter는 양방향 token-classification model에 span decoding을 붙인 형태이고, autoregressive 사전학습 체크포인트에서 시작해 고정된 privacy label taxonomy 위의 토큰 분류기로 적응시켰다고 함
텍스트를 토큰별로 생성하는 대신 입력 시퀀스를 한 번에 라벨링하고, constrained Viterbi 절차로 일관된 span을 복호화함
공개된 모델은 총 1.5B 파라미터에 활성 파라미터는 50M이라고 함
또 사전학습 언어모델의 LM head를 token-classification head로 바꾸고, 지도학습 분류 objective로 후학습해 만들었다고 밝힘- 그러면 이걸 다른 PII 탐지 수단에 의존하지 않고 비정형 텍스트에서 민감정보 위치를 찾는 데도 쓸 수 있어 보임
원문을 필터에 통과시켜 span을 얻고, 그 span을 다시 원문에 매핑하면 결국 PII 위치 정보를 다 확보하게 됨
- 그러면 이걸 다른 PII 탐지 수단에 의존하지 않고 비정형 텍스트에서 민감정보 위치를 찾는 데도 쓸 수 있어 보임
- OpenAI만큼 똑똑하진 않지만, 브라우저에서 BERT 기반 NER로 일부 PII를 가리는 https://tools.nicklothian.com/webner/index.html를 만들었음
내가 시험한 용도에선 꽤 잘 동작했음
OpenAI 모델이 충분히 작아 보여서, 내 도구에 이것도 붙여볼까 생각 중임- 방금 문서에 써봤는데 false positive가 많아서 쓰기 꽤 어려워 보임
100줄 정도 되는 markdown 문서를 넣었더니matter는 frontmatter의 일부인데 조직으로 보고,end는 frontend의 일부인데 역시 조직으로 보고,MCP도 조직으로 분류했음
Following the discussion in , blahblah처럼 문법적으로도 말이 안 되는 결과가 많았음
딱 10년 전 NLP 시절로 돌아간 느낌이고, 그 분야에선 spaCy가 참 좋은 프로젝트였다고 다시 느끼게 됨
- 방금 문서에 써봤는데 false positive가 많아서 쓰기 꽤 어려워 보임
- 이런 류의 모델은 거의 대부분 순진하고 기초적이라는 걸 분명히 해야 함
Hi, this is Bob.같은 단일하고 중립적인 메시지 하나라면 대체로 충분하겠지만, 데이터가 쌓이기 시작하면 신원 유출 위험을 전부 고려한 PII redaction 도구는 나는 아직 못 봤음
그런데 기업들이 이런 걸 쓰고도 데이터가 익명화됐다고 믿는 순간 문제가 커짐. 그건 익명화가 아님
그래도 데이터를 바로 공개하거나 공유하는 게 아니라 moderation, human eval, model training 같은 중간 처리 단계에 쓰는 경우엔 이런 필터링이 꽤 유용할 수 있음 - 예시가 대부분 regex로도 쉽게 잡을 수 있는 것들이라 조금 아쉽지만, 오픈된 로컬 모델로 나온 건 반가움
- 내 고객들에겐 개인 이메일이나 전화번호가 웹사이트에 올라가지 않도록 정규식으로 막고 있음
그래도 추가적인 안심을 위해 이런 모델을 함께 돌리는 건 괜찮아 보임
서버에 GPU는 없지만, 한 번에 2k 토큰 이하라면 CPU-only inference로도 감당 가능한 가벼운 모델이길 바람
- 내 고객들에겐 개인 이메일이나 전화번호가 웹사이트에 올라가지 않도록 정규식으로 막고 있음
- 링크를 클릭하면 OpenAI 사이트의 기계번역 버전으로 리다이렉트되는데, 의미가 완전히 망가져 있음
redacted를 폴란드어의 redagować로 옮겼는데, 그건 익명화가 아니라 텍스트를 편집·다듬는다는 뜻에 가까움 - 이게 regex와 모델을 섞는 Presidio와 비교해 어떨지 궁금함: https://microsoft.github.io/presidio/
- 이 모델을 Presidio 안에 넣어서 쓸 수도 있지 않을까 싶음
- https://peyeeye.ai가 이 스레드에서 다들 말하는 문제를 말 그대로 전부 해결한다고 봄
- 남의 데이터를 허락도 없이 긁어간 회사가 만드는 프라이버시 도구라니, 아이러니가 너무 큼
- 이번 공개는 반가움
규제 산업이 아니어도 이런 모델과 관행을 갖춰둘 이유는 많고, 이론상으론 EU AI Act 때문에도 일부는 필요해짐
나는 https://grepture.com에 특화된 NER 모델로 redaction과 rehydration을 넣어뒀기 때문에, 이것도 파이프라인에 추가할 생각임
선택적으로 hot path에 두고 LLM에 요청이 닿기 전후를 실제로 만질 수 있게 하면, compliance나 직접 사용자 입력을 받는 시나리오에서 꽤 유용함