lora

오픈챗 이름 및 설명 글로 유해성 판단하는 모델 개발하기 (새 탭에서 열림)

LINE AI Services Lab은 오픈챗 이름과 설명을 바탕으로 징계 수위와 사유를 예측하는 자동 모니터링 모델을 개발했다. 기존 모델의 적용 범위를 넓히기 위해 데이터를 정제하고, 안전성 모더레이션에 특화된 2B 규모의 Granite Guardian 3.1 2B를 LoRA로 학습했다. 최종적으로 자연어 단일 토큰과 토큰별 확률을 활용해 실시간 운영에 적합한 분류 구조를 구현했다. ## 오픈챗 모니터링의 목적 - 오픈챗은 생성되거나 이름·설명 글이 수정될 때마다 운영 정책 위반 여부를 검수해야 한다. - LINE은 글로벌 서비스로 생성·수정되는 오픈챗이 많아, 사람의 수동 검수만으로는 대응하기 어렵다. - 기존 모니터링 모델은 여러 국가에서 효과를 보였지만, 국가별로 세분화된 판단 기준이 필요한 경우에는 자동 검수가 제한됐다. - 이번 프로젝트의 목표는 자동 검수 적용 국가와 범위를 확대하고, 기존 적용 국가의 정확도도 높이는 것이었다. ## 중복 데이터와 불일치 라벨 정제 - 현재 가이드라인과 일치하도록 해당 가이드라인이 적용된 기간의 수동 검수 데이터만 학습에 사용했다. - 동일한 오픈챗 이름과 설명에 서로 다른 징계 결과가 부여된 사례를 하나의 최종 라벨로 통합했다. - 징계 코드 처리 기준: - 가장 높은 수위의 징계가 2회 이상이면 해당 징계를 최종 라벨로 선택한다. - 최고 수위 징계가 한 번만 나타나면 노이즈일 가능성을 고려해 두 번째로 높은 수위의 징계를 선택한다. - 징계 사유 처리 기준: - 동일 그룹에서 가장 많이 등장한 사유를 우선한다. - 빈도가 같으면 전체 데이터에서 더 드문 사유를 선택한다. - 이는 희귀한 사유가 해당 데이터를 더 구체적으로 설명할 수 있다는 TF-IDF의 발상에서 착안했다. ## Granite Guardian 3.1 2B 선정 - 사전 학습 모델은 다음 조건으로 검토했다. - 디코더 기반 모델 - 안전성 모더레이션 과제로 튜닝된 모델 - 약 2B 규모 - 상업적 활용이 가능한 Apache 라이선스 - 실시간으로 대량의 오픈챗을 처리해야 하므로, 대형 모델보다 추론 비용과 응답 속도가 낮은 모델이 필요했다. - Granite Guardian은 입력이 유해한지에 대해 `Yes` 또는 `No` 토큰을 생성하는 방식으로 안전성을 판별한다. - 특정 후보 토큰의 생성 확률을 비교하므로 출력 형식이 흔들리지 않고, 확률을 신뢰도로 활용해 운영 임계값을 조정하기 쉽다. ## 징계 코드와 사유를 함께 예측하는 학습 구조 - 오픈챗 검수는 단순한 유해·무해 이진 분류가 아니다. - 유해성의 정도에 따라 징계 수위가 달라진다. - 징계 사유도 함께 예측하고 안내해야 한다. - 이를 위해 모델 응답을 다음과 같은 구조로 정의했다. ```text Action:{징계 코드 토큰} Reason:{징계 사유 토큰} ``` - Cross Entropy Loss를 사용하되, 전체 프롬프트가 아니라 모델의 응답 영역에 대해서만 손실을 계산했다. - 입력 문장을 복사하는 능력보다 징계 코드와 사유를 정확히 예측하는 능력이 중요하기 때문이다. - 전체 파라미터 대신 LoRA를 적용했다. - 기존 모델 파라미터는 고정한다. - 학습해야 할 변화량을 작은 행렬 두 개의 곱으로 근사한다. - 업데이트 파라미터와 메모리 사용량을 줄이면서 사전 학습 능력을 유지한다. ## 자연어 단일 토큰을 활용한 추론 - 실제 징계 코드와 사유 코드는 알파벳·숫자 조합이라 토크나이저에 의해 여러 토큰으로 분할될 수 있다. - 여러 토큰으로 나뉘면 각 코드의 생성 확률을 직접 비교하기 어렵다. - 따라서 코드와 사유를 의미 있는 자연어 표현으로 매핑하고, 각각 하나의 토큰으로 표현되도록 구성했다. - 자연어 토큰은 임의의 코드값보다 모델이 의미를 학습하기에도 유리할 것으로 판단했다. ## 단계별 확률 계산과 KV 캐싱 - 첫 번째 단계에서 모델의 마지막 출력 로짓 중 징계 코드 토큰에 해당하는 값만 추출한다. - 해당 값에 softmax를 적용해 코드별 확률을 계산하고, 가장 높은 확률의 징계 코드를 선택한다. - 이후 선택된 코드와 `Reason:` 프롬프트를 모델에 추가 입력해 징계 사유를 예측한다. - 징계 사유 역시 사유 토큰 후보의 확률만 비교해 최종 결과를 선택한다. - 두 번째 단계에서는 첫 번째 추론의 `past_key_values`를 재사용하는 KV 캐싱을 적용해 반복적인 계산을 줄였다. ## 실용적인 결론 이 사례는 대규모 생성 모델을 그대로 사용하는 대신, 작은 안전성 특화 디코더 모델에 구조화된 출력 형식과 LoRA를 결합해 실시간 콘텐츠 모니터링에 맞춘 접근이다. 운영 환경에서는 단순 정확도뿐 아니라 라벨 품질, 토큰별 신뢰도, 임계값별 검수량과 오탐·미탐 비용을 함께 평가하는 것이 중요하다.

Ensemble AI 출신 인재들과 함께 Cloudflare AI 팀을 확장하기 (새 탭에서 열림)

Cloudflare는 Ensemble AI의 핵심 인력을 영입해 AI 인프라와 추론 효율성 분야를 강화한다. 목표는 대규모·멀티모달 모델을 더 작고 빠르며 저렴하게 실행해, 개발자가 전 세계에서 AI 애플리케이션을 안정적으로 배포하도록 돕는 것이다. 이를 위해 모델 구조 개선, 메모리·연산량 감소, GPU 활용률 향상에 집중한다. ### Ensemble AI의 모델 효율화 기술 - Ensemble AI는 2023년 설립 이후 대규모 모델의 메모리, 연산량, 배포 비용을 줄이는 기술을 개발해왔다. - 단순한 양자화나 하드웨어 최적화가 아니라, 신경망의 구조 자체를 더 작고 효율적으로 만드는 접근을 취한다. - **NdLinear**는 트랜스포머의 표준 선형 계층을 대체하는 기술이다. - 다차원 활성값을 평탄화하지 않고 직접 처리한다. - 어텐션 헤드, 채널, 공간 차원 등 데이터의 의미 있는 구조를 보존한다. - 이를 통해 파라미터 수와 계산량을 줄인다. - **NdLinear-LoRA**는 대규모 모델을 파인튜닝할 때 학습해야 하는 파라미터 수를 줄이는 방식이다. - 양자화, 벡터 양자화와 결합하면 모델의 메모리 사용량과 실행 비용을 더욱 낮출 수 있다. ### Cloudflare Workers AI의 추론 효율 개선 - Workers AI는 Cloudflare의 글로벌 네트워크에서 서버리스 GPU 기반 추론을 제공한다. - AI 애플리케이션이 확산될수록 모델 추론 비용은 확장성을 결정하는 핵심 요소가 된다. - 모델 크기, 메모리 사용량, 처리량, GPU 활용률을 개선하면 개발자의 비용 부담을 줄이고 더 많은 AI 서비스를 운영할 수 있다. - 대상 워크로드는 텍스트 생성뿐 아니라 다음 영역으로 확대되고 있다. - AI 에이전트 - 멀티모달 모델 - 개인화 - 파인튜닝 - 검색 결합 생성(RAG) - 강화학습 - Cloudflare는 기존의 추론 엔진 **Infire**, 텐서 압축 기술 **Unweight**, 대규모 언어 모델 실행 플랫폼을 기반으로 효율화 작업을 강화한다. ### 글로벌 AI 인프라와 모델 압축의 결합 - 개발자는 이제 모델에 접근하는 것만으로는 충분하지 않으며, 모델을 저렴하고 안정적으로 사용자 가까이에서 실행할 인프라가 필요하다. - Cloudflare의 글로벌 네트워크와 서버리스 플랫폼은 AI 실행 환경을 애플리케이션이 이미 배포된 위치에 가깝게 제공할 수 있는 기반이 된다. - Ensemble AI의 모델 압축·효율적 아키텍처 기술을 결합하면 다음 효과를 기대할 수 있다. - 낮은 추론 비용 - 빠른 응답 속도 - 향상된 GPU 활용률 - 대규모 배포의 운영 복잡성 감소 - 다양한 모델 크기와 파인튜닝 방식에 대한 실험 용이성 ### 향후 목표 - Cloudflare는 강력한 AI 모델을 전 세계 규모로 실행하면서도 추론 경제성을 개선하는 것을 목표로 한다. - 새 팀은 대규모 언어 모델과 고급 AI 아키텍처의 서빙 비용을 낮추고, 효율적인 모델 실행과 확장 가능한 배포 방식을 발전시킬 예정이다. - 궁극적으로 개발자가 비용과 운영 부담에 막히지 않고 AI 애플리케이션을 구축·배포할 수 있는 플랫폼을 제공하려는 전략이다. 실용적으로는 AI 서비스를 설계할 때 모델 성능만 비교하기보다 파라미터 수, 메모리 사용량, GPU 활용률, 추론 지연시간, 글로벌 배포 비용을 함께 평가해야 한다. Cloudflare의 방향은 이러한 운영 비용을 모델 구조와 인프라 양쪽에서 동시에 줄이려는 접근으로 볼 수 있다.