Model-agnostic PII detection with LLMs

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 재학습 없이 탐지 항목과 모델을 바꾸는 LLM 기반 PII 탐지기를 소개하고, 5개 공개 데이터셋에서 OpenAI PrivacyFilter를 포함한 총 9개 탐지기를 비교하는 평가 방법을 설명하지만 제공된 원문에는 성능 결과가 없다.

📌 핵심 요약

• 정제하지 않은 텍스트로 모델을 미세 조정하면 이름·주소·연락처 등 개인식별정보(PII)를 암기하고 재출력할 수 있으며, 기존 토큰 분류 모델은 학습 때 고정된 탐지 범주를 확장하려면 재학습이 필요하다.
• pii-detector는 탐지 범주를 프롬프트로 정의하고 Inferencer 인터페이스로 모델을 연결해, Amazon Bedrock 또는 자체 호스팅 모델에서 재학습 없이 탐지 항목과 백엔드를 변경하도록 설계됐다.
• 기본 프롬프트는 15개 엔터티 범주를 정의하며, 모델이 반환한 JSON의 유형과 원문 값을 바탕으로 후처리가 문자 위치를 계산하고 중복을 제거한다. 유사한 라벨은 정규화하고 매핑할 수 없는 라벨은 UNK로 남긴다.
• Amazon Bedrock 실행에는 Python 3.11 이상, Boto3, AWS 자격 증명과 선택 모델의 접근 권한이 필요하다. 관리형 경로는 사용 토큰에 과금되며, 자체 호스팅 경로의 인프라 종료는 사용자가 맡는다.
• 평가는 8개 언어의 5개 공개 데이터셋에 포함된 49,365개 레코드와 222,114개 핵심 정답 구간을 사용한다. 총 9개 탐지기를 대상으로 12개 공통 엔터티 분류와 시작·끝 위치 및 라벨의 완전 일치를 적용하지만, 원문이 평가 설명 도중 끊겨 실제 성능 수치는 확인할 수 없다.

🧩 주요 포인트

1. 프롬프트 기반 탐지 범주와 Inferencer의 분리 → 도메인별 PII 정의와 모델 선택을 독립적으로 바꾸고, 정확도·지연 시간·비용 및 배포 제약에 맞춰 조정할 수 있다.
2. 문자 위치 계산과 라벨 정규화를 후처리로 분담 → LLM의 위치 출력 및 라벨 변형 문제를 보완하고, UNK를 통해 매핑 실패를 드러낸다.
3. 개 공통 엔터티 분류와 완전 일치 기준 → 서로 다른 탐지기의 비교 기준을 맞추지만, 제공된 원문만으로는 OpenAI PrivacyFilter 대비 성능 우위를 판단할 수 없다.

🧠 상세 정리

1. 미세 조정 데이터에 숨어 있는 PII와 기존 방식의 한계

원문은 실제 텍스트로 모델을 미세 조정할 때 학습 자료에 포함된 개인식별정보(PII)가 암기되고, 이를 드러내려는 의도가 없는 프롬프트에서도 재출력될 수 있다는 문제에서 출발한다. 이름, 집 주소, 이메일, 전화번호, 국가 식별번호와 사회보장번호, 은행 계좌, 생년월일 등이 고객 지원 기록이나 인사 자료, 채팅 로그의 자유 텍스트에 섞여 있다는 설명이다. 이런 정보는 정돈된 입력 필드에만 존재하지 않으며, 사전에 정한 스키마가 예상하지 못한 다국어 형식으로 나타난다. 기존 양방향 토큰 분류 모델은 학습 시점에 고정된 PII 유형을 토큰마다 부여하므로, 직원 ID나 암호화폐 지갑 주소 같은 도메인별 식별자를 추가하려면 다시 라벨을 붙이고 재학습해야 한다. 원문은 이러한 범주 확장의 부담과 특정 모델·배포에 대한 종속성을 LLM 기반 접근의 출발점으로 제시한다.

2. 지시문과 모델을 분리하는 탐지기 설계

제안된 탐지기는 LLM을 교체 가능한 구성 요소로 취급하고, 탐지할 엔터티와 기대 출력 형식을 입력 텍스트를 감싸는 지시문으로 전달한다. 탐지 로직은 지시문과 얇은 파싱 계층에 두고, 모델 호출은 메시지 목록을 받아 응답 텍스트를 돌려주는 Inferencer 인터페이스로 통일한다. 패키지는 Amazon Bedrock 어댑터를 제공하며, 같은 인터페이스를 구현하면 자체 GPU 인프라에서 제공하는 OSS-GPT 20B 같은 공개 모델도 연결할 수 있다고 설명한다. 이는 Amazon Bedrock에 접근할 수 없는 보안 환경이나 망 분리 환경까지 포괄하려는 설계다. 모델은 정확도·지연 시간·비용을 결정하고 엔터티 집합은 무엇을 PII로 볼지 결정하므로, 두 요소를 독립적으로 선택하고 탐지 범주는 재학습이나 재배포 없이 지시문 수정으로 바꾸는 것이 핵심이다.

3. 15개 범주를 정의하는 프롬프트와 JSON 출력

탐지 스키마의 중심은 pii_detector/templates.py에 있는 하나의 시스템 프롬프트 템플릿이며, 15개 엔터티 범주와 각 범주의 한 줄 정의를 담는다. 여기에 탐지 대상으로 표시하지 말아야 할 항목 목록, 선택적으로 넣는 소수의 예시, 그리고 입력 텍스트가 함께 구성된다. 범주 정의 자체가 텍스트이므로 필요한 도메인 식별자를 추가하거나 불필요한 범주를 제거하는 작업은 지시문의 한 줄 수정으로 설명된다. 모델의 역할은 원문에서 PII 구간을 찾아 스키마의 유형을 붙이고, 각 항목에 pii_entity_type과 원문 그대로의 pii_entity_value를 넣은 JSON 목록을 반환하는 것이다. 원문은 LLM이 문자 위치를 신뢰성 있게 생성하지 못한다는 이유로 위치 출력을 요구하지 않으며, 예시에 등장하는 주소와 이메일도 유형 및 문자열 값만 반환한 뒤 위치는 후처리에 맡긴다.

4. 모델 응답을 실제 위치가 있는 탐지 결과로 변환

모델 호출에는 입력 메시지와 출력 텍스트만을 규정한 작은 인터페이스를 사용하며, 제공되는 pii_detector/bedrock_inferencer.py는 Amazon Bedrock Converse API를 감싼 어댑터다. 이후 pii_detector/detector.py의 후처리는 응답 텍스트를 탐지 항목별 사전의 목록으로 파싱하고, PII가 없는 레코드는 빈 목록으로 표현한다. 모델이 위치 대신 문자열 값을 반환하므로 각 값을 원문에서 정규 표현식으로 찾아 문자 오프셋을 계산하며, 전체 처리에서는 중복 제거도 수행한다고 설명한다. 또한 DATE를 DATES 대신 내놓거나 EMAIL을 CONTACT_INFO 대신 내놓는 유사 라벨을 형태적 규칙과 사전에 정한 별칭 표로 프롬프트의 어휘에 맞춘다. 어떤 단계로도 매핑할 수 없는 라벨은 억지로 기존 범주에 넣지 않고 UNK로 표시해, 실제로 잘못 생성된 라벨이 결과에서 드러나도록 한다.

5. Amazon Bedrock 실행을 위한 준비와 설치

실행 예제는 sample-llm-pii-detection 저장소에서 제공하는 pii-detector 패키지를 기반으로 하며, 저장소를 복제하고 루트 디렉터리에서 작업한다고 가정한다. 준비 사항은 Python 3.11 이상, Amazon Bedrock Converse API를 호출할 수 있는 AWS 계정과 자격 증명, 선택한 모델의 접근 권한이며 런타임 의존성은 Boto3 하나다. 가상 환경을 만든 뒤 Boto3를 설치하고 PYTHONPATH를 현재 디렉터리로 지정해 pii_detector 모듈을 불러올 수 있게 한다. 자격 증명은 표준 AWS 자격 증명 체인을 따르며 AWS_PROFILE과 AWS_REGION을 설정하는 예제가 제공되고, 원문은 장기 정적 키보다 IAM 역할이나 SSO 프로필 사용을 권장한다. 모델 가용성과 접근 권한은 선택한 AWS 리전에 맞춰 확인해야 하며, 포함된 examples.detect는 자격 증명이나 모델 접근이 없으면 안내와 함께 즉시 실패하도록 구성됐다고 설명한다.

6. 자체 텍스트 탐지와 실행 후 자원 정리

자체 텍스트를 처리할 때는 BedrockInferencer에 모델 ID와 리전을 전달하고, 이를 PiiDetector로 감싼 뒤 문자열을 입력하는 순서로 호출한다. 예제는 us-east-1의 openai.gpt-oss-20b-1:0을 사용하며, 이메일과 전화번호 등이 포함된 문장에서 유형·값·시작 및 끝 문자 위치를 가진 구간 목록을 반환해 후속 가림 처리에 전달할 수 있게 한다. 모델 ID에는 Amazon Bedrock Converse 모델 ID나 추론 프로필 ID를 사용할 수 있고, amazon.nova-lite-v1:0 또는 mistral.mistral-large-3-675b-instruct 같은 모델로 한 줄만 바꿔 연결할 수 있다고 설명한다. Amazon Bedrock은 완전 관리형 서버리스 서비스이므로 관리하거나 철거할 서버가 없고, 사용한 토큰에 대해서만 비용을 지불한다. 정리 단계에서는 가상 환경을 비활성화하고 더 필요하지 않으면 모델 접근을 해제하며, 자체 호스팅 백엔드는 탐지기가 인프라를 관리하지 않으므로 사용자가 호스트를 종료해야 한다.

7. 5개 공개 데이터셋과 다국어 평가 범위

평가는 Hugging Face의 공개 PII 데이터셋 5개에서 각각 약 10,000개 행을 추출해 구성하며, 합계는 49,365개 레코드와 222,114개 핵심 정답 구간이다. 언어는 독일어·영어·스페인어·프랑스어·힌디어·이탈리아어·네덜란드어·텔루구어의 8개이며, 다국어 합성 프로필부터 영어 인사·금융·고객 서비스 문서까지 포함한다. ai4privacy_500k는 9,947개 레코드와 23,822개 핵심 정답 구간을, ai4privacy는 9,936개 레코드와 70,720개 구간을 제공한다. gretel은 9,991개 레코드와 41,967개 구간, isotonic은 9,498개 레코드와 21,674개 구간, nemotron은 9,993개 레코드와 63,931개 구간으로 구성된다. 원문은 성별·조직 범주, 15개 이상의 추가 도메인 범주, 30개 이상의 원시 엔터티 범주처럼 데이터셋마다 다른 특성이 있어 이 집계가 다양한 조건을 시험한다고 설명한다.

8. 완전 일치 평가와 공통 분류 체계의 역할

제안된 접근은 OpenAI PrivacyFilter를 포함한 다른 8개 LLM 기반 탐지기와 함께 총 9개 탐지기를 동일한 정답에 대조하는 방식으로 평가된다. 예측 구간은 시작 위치·끝 위치·라벨이 정답과 정확히 일치해야 매칭되며, 원문은 이를 IoU = 1.0으로 표현하고 정밀도·재현율·F1을 평가 지표로 제시한다. 다만 탐지기와 데이터셋이 PRIVATE_NAMES와 NAME, street_address와 street처럼 서로 다른 라벨 어휘를 사용하므로 그대로 비교하기 어렵다는 문제가 있다. 이를 해결하기 위해 탐지기 출력과 데이터셋 정답의 모든 원시 라벨을 12개 공통 엔터티로 이루어진 하나의 표준 분류 체계에 매핑한다. 제공된 원문은 그다음 탐지기별 채점 범위를 설명하던 문장 중간에서 끝나므로, 세부 적용 조건과 실제 성능 결과는 확인할 수 없으며 특정 모델이나 탐지기의 우위를 결론 내릴 근거도 제시되지 않았다.

🧾 핵심 주장 / 시사점

• 이 접근의 핵심은 PII 정의를 학습된 고정 범주에서 수정 가능한 지시문으로 옮기는 데 있으며, 탐지 범주 변경과 모델 교체를 분리해 도메인 적응의 부담을 줄이려는 설계다.
• 모델에 정확한 문자열 추출을 맡기고 위치 계산과 라벨 정규화를 후처리에 맡기는 역할 분담이 중요하다. UNK는 매핑 실패를 숨기지 않지만, 이것만으로 탐지 정확도가 보장되지는 않는다.
• 다양한 데이터셋과 공통 분류 체계는 비교의 기반을 제공하지만 성능 결과를 대신하지 않는다. 제공된 자료로 판단할 수 있는 범위는 구현 방식과 평가 설계까지다.

✅ 액션 아이템

• 도메인별 PII 정의에 맞춰 프롬프트 기반 탐지 범주의 추가·제거 필요성을 검토한다.
• 정확도·지연 시간·비용 및 배포 제약을 기준으로 Amazon Bedrock과 자체 호스팅 모델의 적합성을 비교한다.
• OpenAI PrivacyFilter 대비 성능을 판단하기 전에 누락된 실제 성능 수치와 12개 공통 엔터티 분류의 평가 적용 범위를 확인한다.

❓ 열린 질문

• 도메인별 PII 정의를 반영하려면 기본 15개 엔터티 범주에서 무엇을 추가하거나 제거해야 하는가?
• Amazon Bedrock과 자체 호스팅 모델 중 정확도·지연 시간·비용 및 배포 제약에 더 적합한 선택은 무엇인가?
• 12개 공통 엔터티 분류와 완전 일치 기준에서 제안된 탐지기와 OpenAI PrivacyFilter의 실제 성능 차이는 어떠한가?