오픈챗 이름 및 설명 글로 유해성 판단하는 모델 개발하기

LINE Plus가 오픈챗 플랫폼에서 유해한 채팅방 이름·설명 글을 자동 감지하기 위한 AI 모델 개발 과정을 공유했다. IBM Research의 Granite Guardian 3.1 2B를 기반으로 LoRA 파인튜닝을 적용하고, 2단계 순차 예측과 신뢰도 임곗값을 도입해 기존 모델 대비 F1 스코어를 모든 지역에서 큰 폭으로 개선했다.

핵심 포인트

기존 오픈챗 모니터링 모델이 일부 국가에서 세분화된 판단 기준을 충족하지 못해 새 모델 개발이 필요했다
과거 수동 검수 데이터의 라벨 불일치를 TF-IDF 개념을 적용해 정제했다
디코더 기반 2B 규모의 Granite Guardian 3.1 2B를 선택해 실시간 추론 비용과 속도 효율성을 확보했다
LoRA를 적용해 전체 파라미터 대신 소형 행렬의 곱으로 근사하여 학습 파라미터와 메모리 사용량을 줄였다
징계 코드·사유를 2단계로 순차 예측하고 신뢰도 임곗값을 적용해 자동 처리 정밀도 기준을 충족했다

상세 정리

문제 정의: LINE 오픈챗은 전 세계에서 매일 대량 생성·수정되어 수동 검수가 불가능하며, 기존 모델은 국가별 세분화된 기준을 충족하지 못했다
데이터 정제 — 라벨 불일치 해소: 동일 오픈챗에 서로 다른 징계 결과가 부여된 사례를 처리하기 위해 라벨 결정 규칙을 설계했다 (최고 수위 2회 이상이면 그 징계 선택, 1회만이면 노이즈로 제외, 나머지는 2번째 수위 보수적 선택)
TF-IDF 적용: 징계 사유가 다를 경우 빈도 높은 것을 우선하되, 빈도가 같으면 전체 데이터에서 더 희귀한 사유를 선택하는 TF-IDF 개념을 적용했다
모델 선정 기준: 디코더 기반, 안전성 모더레이션 파인튜닝 완료, 2B 규모(추론 비용·속도), Apache 라이선스 네 가지를 충족하는 Granite Guardian 3.1 2B를 최종 선택했다
Granite Guardian 특징: "입력이 유해한가?"에 "Yes"/"No" 토큰 생성 확률로 판단해 예측 불가능한 긴 응답 문제를 피하고 신뢰도 점수를 자연스럽게 활용한다
학습 구조: 기본 Granite Guardian 구조를 수정해 징계 코드(수위 단계)와 징계 사유를 동시에 예측하도록 설계하고, Cross Entropy Loss를 모델 응답 부분에만 적용했다
LoRA 최적화: 전체 파라미터를 업데이트하는 대신 작은 행렬의 곱으로 근사(Low-Rank Adaptation)해 학습 파라미터와 메모리 사용량을 크게 줄였다
추론 — 2단계 순차 예측: 징계 코드 후보 토큰의 로짓을 소프트맥스로 확률 변환하여 최고 확률 코드를 선택한 뒤, 해당 코드에 대한 징계 사유를 생성한다
KV 캐싱·자연어 토큰 매핑: KV 캐싱으로 이전 토큰의 키-밸류값을 재사용해 중복 계산을 제거하고, 임의의 알파벳-숫자 코드를 의미 있는 자연어 토큰으로 매핑해 학습 효율성을 높였다
임곗값 도입: 신뢰도 임곗값 미만인 예측은 수동 검수로 전환하여 자동 처리의 정밀도를 확보했다 — 임곗값 미적용 시 정밀도 기준 미충족으로 자동 처리가 불가능했다
성능: 정상 클래스 F1이 A·B·C 국가 전 지역에서 기존 모델 대비 큰 폭 개선, NG 클래스 F1도 모든 지역에서 상당히 개선, 온라인 평가에서도 실제 운영 환경 성능 확인
향후 계획: 학습 데이터 품질 기반 가중치 설정, 자동 처리 미통과 데이터를 더 큰 모델로 재추론하는 모델 캐스케이딩 적용 예정

왜 읽나LLM 기반 텍스트 안전성 분류 시스템을 실제 서비스에 도입하는 ML 엔지니어에게 데이터 정제부터 추론 최적화까지 전 과정의 실전 레퍼런스.

LINE Engineering 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

오픈챗 이름 및 설명 글로 유해성 판단하는 모델 개발하기

이 글과 비슷한

몇 주에서 하루로: Airbnb의 LLM 평가 속도 개선기

MATCH란 무엇인가

[AI 해커톤 후기] AI 시대의 해커톤과 인간의 역할: AI의 계획과 사람의 전략