이런 기능은 몇 년 전에 이미 구현해봤고, 그 결과 몇 가지가 분명했음 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 위치 정보를 다 확보하게 됨
방금 문서에 써봤는데 false positive가 많아서 쓰기 꽤 어려워 보임
100줄 정도 되는 markdown 문서를 넣었더니 matter는 frontmatter의 일부인데 조직으로 보고, end는 frontend의 일부인데 역시 조직으로 보고, MCP도 조직으로 분류했음 Following the discussion in , blahblah처럼 문법적으로도 말이 안 되는 결과가 많았음
딱 10년 전 NLP 시절로 돌아간 느낌이고, 그 분야에선 spaCy가 참 좋은 프로젝트였다고 다시 느끼게 됨
이런 류의 모델은 거의 대부분 순진하고 기초적이라는 걸 분명히 해야 함 Hi, this is Bob. 같은 단일하고 중립적인 메시지 하나라면 대체로 충분하겠지만, 데이터가 쌓이기 시작하면 신원 유출 위험을 전부 고려한 PII redaction 도구는 나는 아직 못 봤음
그런데 기업들이 이런 걸 쓰고도 데이터가 익명화됐다고 믿는 순간 문제가 커짐. 그건 익명화가 아님
그래도 데이터를 바로 공개하거나 공유하는 게 아니라 moderation, human eval, model training 같은 중간 처리 단계에 쓰는 경우엔 이런 필터링이 꽤 유용할 수 있음
예시가 대부분 regex로도 쉽게 잡을 수 있는 것들이라 조금 아쉽지만, 오픈된 로컬 모델로 나온 건 반가움
내 고객들에겐 개인 이메일이나 전화번호가 웹사이트에 올라가지 않도록 정규식으로 막고 있음
그래도 추가적인 안심을 위해 이런 모델을 함께 돌리는 건 괜찮아 보임
서버에 GPU는 없지만, 한 번에 2k 토큰 이하라면 CPU-only inference로도 감당 가능한 가벼운 모델이길 바람
링크를 클릭하면 OpenAI 사이트의 기계번역 버전으로 리다이렉트되는데, 의미가 완전히 망가져 있음 redacted를 폴란드어의 redagować로 옮겼는데, 그건 익명화가 아니라 텍스트를 편집·다듬는다는 뜻에 가까움
이번 공개는 반가움
규제 산업이 아니어도 이런 모델과 관행을 갖춰둘 이유는 많고, 이론상으론 EU AI Act 때문에도 일부는 필요해짐
나는 https://grepture.com에 특화된 NER 모델로 redaction과 rehydration을 넣어뒀기 때문에, 이것도 파이프라인에 추가할 생각임
선택적으로 hot path에 두고 LLM에 요청이 닿기 전후를 실제로 만질 수 있게 하면, compliance나 직접 사용자 입력을 받는 시나리오에서 꽤 유용함
Hacker News 의견들
PII 정제는 UX를 유지하려면 클라이언트에서 다시 되돌려야 함. 예를 들어 이름이 John인데
[NAME]으로 가려진 상태로 모델이Hi [NAME]이라고 답하면, 사용자에게 보여주기 전에Hi John으로 복원해야 함결국 사용자가 상호작용하는 계층에 역치환 메커니즘이 필요함
또 가려진 PII 데이터는 대부분의 목적에서 거의 쓸모가 없음. 모델은 어느 정도 실제 데이터가 있어야 작동하는데, PII로 분류되는 항목이 워낙 많아서 단순 채팅은 괜찮아도 사용자가 LLM과 복잡하게 상호작용해야 하는 경우엔 난도가 크게 올라감. 아예 아무것도 못 하거나 hallucination이 생길 수도 있음
그래서 플랫폼 차원에선 지원하지만, 이런 한계 때문에 실제로는 잘 쓰이지 않음
현실적인 방법은 보안 위험이 큰 일부 PII만 제거하고, PII를 최대한 빨리 폐기하는 신뢰 가능한 모델을 쓰는 편이라고 봄. 그러려면 시스템 설계도 꽤 달라져야 함
모델 기반 탐지와 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로 후학습해 만들었다고 밝힘
원문을 필터에 통과시켜 span을 얻고, 그 span을 다시 원문에 매핑하면 결국 PII 위치 정보를 다 확보하게 됨
내가 시험한 용도에선 꽤 잘 동작했음
OpenAI 모델이 충분히 작아 보여서, 내 도구에 이것도 붙여볼까 생각 중임
100줄 정도 되는 markdown 문서를 넣었더니
matter는 frontmatter의 일부인데 조직으로 보고,end는 frontend의 일부인데 역시 조직으로 보고,MCP도 조직으로 분류했음Following the discussion in , blahblah처럼 문법적으로도 말이 안 되는 결과가 많았음딱 10년 전 NLP 시절로 돌아간 느낌이고, 그 분야에선 spaCy가 참 좋은 프로젝트였다고 다시 느끼게 됨
Hi, this is Bob.같은 단일하고 중립적인 메시지 하나라면 대체로 충분하겠지만, 데이터가 쌓이기 시작하면 신원 유출 위험을 전부 고려한 PII redaction 도구는 나는 아직 못 봤음그런데 기업들이 이런 걸 쓰고도 데이터가 익명화됐다고 믿는 순간 문제가 커짐. 그건 익명화가 아님
그래도 데이터를 바로 공개하거나 공유하는 게 아니라 moderation, human eval, model training 같은 중간 처리 단계에 쓰는 경우엔 이런 필터링이 꽤 유용할 수 있음
그래도 추가적인 안심을 위해 이런 모델을 함께 돌리는 건 괜찮아 보임
서버에 GPU는 없지만, 한 번에 2k 토큰 이하라면 CPU-only inference로도 감당 가능한 가벼운 모델이길 바람
redacted를 폴란드어의 redagować로 옮겼는데, 그건 익명화가 아니라 텍스트를 편집·다듬는다는 뜻에 가까움규제 산업이 아니어도 이런 모델과 관행을 갖춰둘 이유는 많고, 이론상으론 EU AI Act 때문에도 일부는 필요해짐
나는 https://grepture.com에 특화된 NER 모델로 redaction과 rehydration을 넣어뒀기 때문에, 이것도 파이프라인에 추가할 생각임
선택적으로 hot path에 두고 LLM에 요청이 닿기 전후를 실제로 만질 수 있게 하면, compliance나 직접 사용자 입력을 받는 시나리오에서 꽤 유용함