Veil-PII-Ko-Lite — 경량 한국어 PII 모델 개발 리포트

이 글은 CPU만으로 돌릴 수 있는 경량 한국어 PII(개인정보) 탐지 모델 Veil-PII-Ko-Lite를 개발한 과정과 결과를 정리한 리포트입니다.

1. 개발 동기

#

• 매 프로젝트마다 폐쇄망 환경에서의 PII 모델 적용은 필수 요소. But 아쉬운 한국어 PII 성능
• 폐쇄망에서 GPU 없이 가볍게 구동할 수 있는 PII 모델 필요
• 다양한 한국어 PII Category에 대한 탐지 기능 필요
• 좋은 PII 성능을 보이는 것으로 알려진 모델들을 후보군으로 두고 탐색

결론적으로 “경량 · 한국어 강함 · 카테고리 넓음 · 라이선스 부담 없음” 네 조건을 동시에 만족하는 공개 모델이 없어 직접 개발하기로 하였습니다.

2. 개발 목표

#

3. Backbone 선택

#

작은 크기 및 한국어를 지원하는 PII backbone 모델 5종을 비교분석하였습니다.

후보 5종을 같은 데이터(2종 - KDPII, BCCard val 데이터), 같은 하이퍼파라미터로 2 epoch로 학습하여 비교하였습니다.

최종 판단 기준은 F1 Score 기준 정확도 및 모델의 크기를 가장 중요한 요소로 두어 평가하였고, 최종적으로 ‘ko-electra-base-v3’ 모델을 최종 backbone 모델로 선택하였습니다.

백본에 대해 PII 탐지(라벨을 인식할 수 있도록)가 가능하도록 동일 조건으로 fine-tuning 진행했고, train loss는 동일하게 떨어졌습니다.
다만, validation set에 대해서는 아래와 같이 Ko-Electra-base-v3 모델이 가장 좋은 성능을 보였습니다.

4. 학습 데이터

#

학습셋 구성 (행 수, full 셋 기준 · 총 128k)

막대 길이 = 행 수 비례. 학습 시 반복 가중 ×2를 쓴 출처(BCCard)는 epoch당 실효 256k 행.

4-1. BCCard/privacy-filter-openpii-masking (CC-BY-4.0) - 약 72,400행

#

• 데이터 설명
  • 아래 세 가지 출처의 데이터에 대한 통합본으로 확인
    • openpii-1.5m-ko/none 26,268행 (ai4privacy 영문 데이터의 한국어 번역본)
    • openpii-1.5m-ko/perturbation 16,268행 (위 데이터를 한국 포맷으로 변경, 생성한 데이터)
    • domain/synthesis 11,170행 (BC카드 자체 합성데이터)

<데이터 샘플>

• 원문 : 연락을 위해 jimin3292@webmail.example.net 또는 공오일 일일구 공육육육 로 문의해 주세요.

• 정답 : EMAIL jimin3292@webmail.example.net · PHONE 공오일 일일구 공육육육

• 수집 사유

  • 한국어 PII Category 29개의 라벨을 기준으로, 공개된 가장 큰 데이터이며, 비교 대상(BCCard 모델)과 같은 분포로 학습 후 평가해야 BCCard validation 비교가 공정해지기에, 해당 데이터를 사용하게 되었습니다.

• 데이터 품질 검수

  • 학습 이전에, 데이터 품질이 적합한지에 대한 전수 검사를 실시
  • 탐지된 문제점
    • 주민번호·전화·카드·면허·여권·사업자번호 등 21종 포맷 검증기로 행 단위 감사(정규표현식)를 수행했으며, 세 하위 출처 중 openpii-1.5m-ko (ai4privacy 번역본 21k)는 35% 행이 불량이었음
      • 운전면허 라벨의 61%가 0W4SB7XAR4 같은 랜덤 대문자열
      • 이름의 13%가 선임Blattnig 같은 혼합 문자.
      • 한국 포맷으로 변경 전 데이터라, 당연한 결과로 보이며 BC Card에서 해당 데이터를 왜 학습에 포함했는지 이유는 모르겠으나, 해당 데이터 포함 시 모델 성능이 하락하는 것을 확인하였고 포맷검증기에서 확인된 문제 데이터는 모두 제거함.
    • BCCard 모델 Description에서 언급된, 스스로 약하다고 밝힌 ACCOUNT_NUMBER·ZIPCODE·PORT의 원인이 “랜덤 문자열 = 식별자” 데이터를 제거하지 않고 학습한 결과로 예상.
    • 처리: 불량 행을 제외한 clean 셋과 전체 full 셋을 모두 만들어 절제 실험으로 비교했음(6절).

<불량 데이터 예시>

• 정상 : DRIVER_LICENSE = 11-23-456789-01
• 불량 : DRIVER_LICENSE = 0W4SB7XAR4

4-2. KDPII (고려대, CC-BY-4.0) — 약 40,000개 문장 · 3,664 대화

#

• 데이터 설명
  • 실제 구어체 대화 기반의 유일한 한국어 PII 실데이터입니다.

<데이터 샘플>

• 원문 : 나 캐나다에서 태어나서 5년 전 17살에 한국 왔어.

• 정답 : LCP_COUNTRY 캐나다 · QT_AGE 17살 · LC_ADDRESS 한국 → 매핑 후: ADDRESS 한국 (라벨에서 LCP_COUNTRY와 같은 국가 개념은 잡을 필요없는 데이터이기에 학습데이터에서 제거했음)

• 수집 사유

  • 공식 train/valid/test 분할이 있어 외부 비교 기준이 되며, 문장 평균 25자로 짧은 데이터로 구성되어 있습니다.

• 처리

  • 33개의 KDPII category 중 키·몸무게·혈액형·종교 등 우리 모델에서 탐지하지 않는 카테고리들은 비 라벨로 처리하고 우리 모델에서 탐지하는 16개의 라벨로 매핑. 카드·계좌 스팬에 붙은 은행명은 숫자 구간만 남기도록 정규화하여 BCCard 데이터셋의 포맷과 일치시킴.

4-3. 합성 데이터 (자체) — 26,500행

#

• 데이터 설명
  • 위 수집한 데이터에서 미비된 라벨에 대한 데이터는 gpt-5.4 모델을 활용하여 생성하여 채웠습니다.
  • 데이터는 원본에서 빈칸을 맞추는(PII를 맞추는 위의 데이터들과 같은 형식) 데이터와 빈

<데이터 샘플>

• 원문 : 연규도우 과장님 고객님, 문의하신 4918-5036-****-3258 카드 승인번호 55276357 건은 등록 계좌 587918-37-599711 로 1995.07.15 환불됩니다. 요금제 5G 프리미어 80입니다.

• 정답 : PERSON 연규도우 · CARD_NUMBER 4918-5036-****-3258 · TRANSACTION_APPROVAL_ID 55276357 · ACCOUNT_NUMBER 587918-37-599711 · DATE 1995.07.15 (뒤의 “요금제 5G 프리미어 80"은 삽입된 hard-negative)

• 수집 사유

  • 공개 데이터에 없는 라벨(차량번호·가입번호·단말 S/N)과 부족한 도메인(금융·통신·보험 상담문)을 보강하고, 주문번호·상품코드·금액 같은 hard-negative를 정답과 같은 빈도로 넣어 “숫자면 다 잡는” 과탐을 억제하는 효과를 주었습니다.

• 방식

  • BC Card에 잘못된 포맷의 데이터가 들어가서 데이터 품질을 떨어뜨렸던 사례를 참고하여, LLM이 아래와 같은 원문을 생성하되, 원문 내에 들어가는 pii 카테고리 데이터에 대해서는 로직 기반으로 채우도록 하여, 환각으로 인한 잘못된 label 데이터가 포함되는 사례를 방지하였습니다.

• LLM생성 : {PERSON} 고객님, 문의하신 {CARD_NUMBER} 카드 승인번호 {TRANSACTION_APPROVAL_ID} 건은 등록 계좌 {ACCOUNT_NUMBER} 로 {DATE} 환불됩니다.

• 위 category별 삽입되는 데이터는 프로그래미틱하게 생성 반영

5. 학습

#

5-1. 학습방식 → Full Fine-Tuning

#

• Ko-Electra-base-v3 백본 모델의 경우, 기존 transformer encoder에 이진판별(토큰 간 동일여부)이 가능한 헤더가 붙어있었습니다. (768 → 1). 해당 헤더 부분을 PII category 분류 목적에 맞게, 768 → 129dim의 헤더로 변경하였습니다.
• 그리고, 가중치 업데이트는 전체 모델 architecture에서 기본적으로 Embedding layer, Encoder layer를 학습합니다. (헤더만 학습하는 게 아니라, 전체 레이어에 대해 기울기 계산을 진행하여 백본 전체를 갱신함!!)
• 그리고 위에서 언급한 토큰 분류헤더에 대해, 각 토큰별로 총 129개 라벨에 대한 확률값을 예측하는 형태로 학습을 진행하였습니다.
  • 라벨이 129개인 이유는, 총 32개의 카테고리 라벨이 있고, 각 라벨별로 ‘시작 B(Begin)’, ‘중간 I(Inside)’, ‘끝 E(End)’, ‘단일 S(그냥 혼자서 하나의 엔티티를 가지는 경우, Single)’ 총 4가지 정보로 분류되고, 마지막으로 엔티티가 아님에 해당하는 라벨까지 더해서, 32 x 4 + 1 = 129개의 예측해야 할 라벨이 발생합니다.
• 다만, 모델의 output이 129개 라벨에 대한 토큰별 확률값이고, 각 토큰별 129개의 확률값 중 제일 높은 확률의 라벨을 고르는 방식(argmax)을 선택할 경우, 토큰의 시작-중간-끝 요렇게 문법(?)에 맞게 배치되어야 하는데, 단순 높은 확률값으로만 채택할 경우, 단일 토큰의 예측라벨이 IBBS…BBI, 뭐 이런 식으로 말도 안 되는 토큰 배치가 발생할 수 있습니다.
• 이에, Viterbi 알고리즘을 적용하여, 앞단의 토큰의 라벨이 예측되었을 때, 뒷 토큰의 경우 그 자리에 올 수 있는 라벨 중에서 가장 높은 확률을 가진 라벨을 채택하는 방식으로 보정하여 분류하였습니다.
• Tuning Params
  • Loss Function : nn.CrossEntropyLoss
  • Label Smoothing : 0.05 (v1~v3a) → 0 (v3b·v4)
  • Optimizer : AdamW
    • weight decay : 0.01
    • dropout : 0.1
  • learning rate : 3e-5 → 5e-5 (v3b·v4)
  • warmup : 10%
  • epoch : 5→6
  • Loss 제외 토큰 반영(ignore_index=-100 처리)
    • padding, [CLS], [SEP] 토큰은 학습 제외

5-2. 학습과정

#

버전별 데이터셋

버전별 의도 및 결과

6. 학습 결과

#

exact-match span F1 · 같은 스코어러 · 같은 디코더

6-0. Veil-PII-Ko-Lite 모델 제공 32개 Label

#

Veil-PII-Ko-Lite 모델 제공 32개 Label 목록

#

6-1. 모델별 F1-Score

#

• FrameByFrame의 경우, 벤치를 측정하지 않은 이유는, 해당 모델이 9개 카테고리밖에 지원하지 않아, 직접적 비교가 힘들어, 제외 처리함.

“PII의 경우, 오답의 리스크가 크기 때문에, Recall 및 Precision도 중요하며, 제공하는 카테고리가 많아졌기 때문에 카테고리별 스코어도 확인할 필요가 있었습니다.”

6-2. 각 모델별 전체 라벨에 대한 Recall Score

#

1) KDPII test set 기준 Recall (라벨 17개 보유)

#

2) BCCard-val-ko set 기준 Recall (라벨 29개 보유)

#

3) 자체 합성 데이터 set 기준 Recall (라벨 32개 보유)

#

6-3. 각 모델별 전체 라벨에 대한 Precision Score

#

1) KDPII test set 기준 Precision (라벨 17개 보유)

#

2) BCCard-val-ko set 기준 Precision (라벨 29개 보유)

#

3) 자체 합성 데이터 set 기준 Precision (라벨 32개 보유)

#

6-4. 양자화 및 Latency

#

• Dynamic INT8로 양자화를 진행한 경우, 모델크기는 113까지 감소했으나, activation까지 양자화(정수)되면서 recall이 대폭 하락했습니다. 원인은 129개 라벨의 1,2등의 prediction score가 매우 근소한 차이라, 성능하락이 컸습니다.
• 이에, weight는 int8로 양자화하고, activation은 fp32를 유지하여 성능은 유지하고, 모델크기는 143MB로 축소했습니다.

6-5. 종합 비교

#

7. 최종 결과 분석

#

7-1. 최종 결과

#

• CPU 환경에서 운용이 가능한 110M의 작은 PII 모델 확보
• 1.4B에 달하는 모델 대비 더 많은 Category를 지원(32개)
• 경쟁 모델 대비 작은 크기(10배)로 더 높은 탐지 성능 확보

7-2. 매우 작은 모델로도 높은 성능을 낼 수 있었던 이유

#

• PII detection 시, 비교모델(bccard)의 경우 autoregressive하게 생성하여 output을 도출하는 방식인데, veil 모델의 경우, 각 토큰에 PII 라벨을 찍는 token classification 방식으로 탐지합니다. 즉, veil에서 필요한 출력은 {start, end, label}로 단순하나, 비교모델은 문장을 생성한 뒤, 원문에 다시 맞추는 alignment 과정이 필요한데, 이 부분에서 mask token 길이가 원문과 다르거나, 조사, 공백, 어순이 틀어지는 현상으로 인해 낮은 성능을 보일 수밖에 없습니다.
• openpii-1.5m-ko 데이터 전수검사를 통해 약 30%가량의 불량데이터를 검출하여 제거하여, 학습 노이즈를 최소화
• 실제 대화체에 개인정보가 포함되는 형태의 학습데이터를 대거 추가하여, 구어체의 긴 문장이 포함된 벤치에서도 높은 성능을 보임.
• 합성데이터를 LLM으로 형태만 맞추어 무작위 생성하지 않고, 각 데이터별 포맷 규칙(프로그래미틱하게 작성)하에 작성하여 최대한 리얼월드 데이터와 유사하게 생성하고, 할루시네이션 가능성을 차단하였습니다.
  • 예) Luhn 알고리즘 활용하여, 실제 카드번호와 동일한 형태로 생성 → ISO/IEC 7812 — 앞 6자리 BIN(발급사) + 계좌번호 + 마지막 체크디지트

7-3. 추후 보완사항

#

• 새롭게 추가된 카테고리 중, S/N 기기단말번호 또는 가입번호와 같은 회사마다/도메인마다 정형화된 포맷이 아니라, 예측이 어려운 부분에 대해서도 학습에 추가했으나, 실제로 예측하지 못하는 케이스가 더러 발생했다.
• 비정형 타입의 카테고리의 경우, 전후 맥락 및 토큰의 위치정보 등을 통해 최대한 예측했으나, 아래 실제 테스트 결과와 같이 아직 탐지하지 못하는 케이스들이 확인되었고, 전체 카테고리의 탐지성능을 균일하게 끌어올리는 것이 추후 과제로 보여진다. (물론 실제 고객 환경에 적용 시, 해당 문제가 발생할 경우 모델단이 아닌 presidio를 통한 후처리를 통해 domain specific한 부분들은 어느 정도 처리가 가능하긴 함)
• 마지막으로, 실제 기업 내부 프로덕션에 올려서 실 데이터 기반으로 검증이 필요함.

8. 사용방법

#

1. HuggingFace
   • https://huggingface.co/1T/veil-pii-ko-lite
2. DockerHub → 모델만 담아 패키징한 이미지와 presidio 내에 모델을 담아 패키징한 이미지를 아래 dockerhub에 올려두었습니다.
   • https://hub.docker.com/repository/docker/zzang9680/veil-pii/tags
3. PlayGround
   • https://20-249-59-7.sslip.io/
   • 직접 여러 모델과 비교해서 실행해보실 수 있게 플레이그라운드를 호스팅해두었습니다.
   • 해당 플레이그라운드에서는 아래 4개 모델의 PII 성능을 비교 확인하실 수 있게 구성해두었습니다.
     1. Veil-PII-Ko-Lite (우리 모델)
     2. MoAI-Privacy-Filter (BCCard 모델)
     3. FrameByFrame
     4. Azure AI Language PII