GLiClass: 라벨을 함께 읽는 문장 분류

문의 분류나 문서 라우팅을 만드는 개발자는 후보 라벨이 늘수록 정확도와 응답 시간이 어떻게 바뀌는지 확인해야 한다. GLiClass는 문장과 후보 라벨들을 한 번에 인코딩해 문장·라벨 쌍을 각각 처리하는 비용을 줄이려 한다. 이 글에서는 그 계산 방식과 논문이 보고한 처리량을 살펴보고 빠른 분류와 정확한 분류를 구분한다.

기준 자료는 Ihor Stepanov를 포함한 여섯 저자의 GLiClass: Generalist Lightweight Model for Sequence Classification Tasks(arXiv v1, 2025년 8월 11일)이다. 논문의 모델 이름에 붙은 v3.0은 모델 릴리스 표기이고 논문 판본 v1과 다른 번호다.

라벨 128개를 128번 읽는 비용

설명용으로 고객 문의 하나를 만든다고 하자.

문장: 결제가 두 번 되었고, 아직 상품도 받지 못했습니다.
후보: 결제 오류 / 배송 지연 / 계정 문제
정답으로 의도한 라벨: 결제 오류, 배송 지연

여러 문제가 동시에 담겼으므로 복수 라벨이 자연스럽다. 실제 모델 출력은 아니며 예제의 정답을 이렇게 정한 것이다.

문장·라벨 쌍을 입력받는 cross-encoder는 (문의, 결제 오류), (문의, 배송 지연), (문의, 계정 문제)를 각각 처리한다. 묶어서 배치 실행할 수 있어도 계산할 쌍의 수는 라벨 수와 함께 늘어난다. 문장과 라벨의 관계를 자세히 읽는 대가다.

각 문장과 라벨을 별도로 임베딩하는 방식은 라벨 벡터를 미리 계산할 수 있다. 다만 문의를 읽는 단계에서 이번 후보 라벨들의 의미가 함께 들어오지는 않는다. GLiClass의 주된 uni-encoder 구조는 이 사이에서 문장과 모든 라벨을 하나의 입력으로 묶는다.

구간 추출을 문장 분류로 바꾼다

GLiNER가 원문 속 구간과 개체 유형을 맞춘다면 GLiClass는 문장 전체의 표현과 분류 라벨 표현을 맞춘다. 라벨 앞에 특별 토큰 <<LABEL>>을 놓고 문장과 함께 양방향 인코더에 입력한다. 라벨과 라벨, 라벨과 문장 사이의 정보를 함께 읽을 수 있다.

인코더의 출력에서 문장 표현과 각 라벨 표현을 모은 뒤 문장·라벨 점수를 계산한다. 한 라벨을 고르는 과제에는 softmax를, 복수 라벨 과제에는 라벨별 sigmoid를 쓸 수 있다(GLiClass의 구조).

동일 입력에서 두 라벨을 선택할 수 있는 구조와 배송 지연이 실제로 맞다는 판단은 별개다. 위 문의는 배송이 늦었다는 정보가 충분한지부터 애매하다. 라벨 정의가 모호하면 한 번에 읽는 구조만으로 정답 기준을 해결할 수 없다.

후보 라벨을 바꾸면 공동 입력도 바뀐다. 따라서 기존 라벨의 표현과 점수도 달라질 수 있다. 이는 각 라벨을 독립 처리한 점수를 단순히 모으는 방식과 다른 운영 조건이다.

줄인 것은 반복 계산이고, 늘어난 것은 공동 입력이다

계산의 교환을 간단히 써 보면 장점과 한계가 같이 보인다. 문장의 토큰 수를 T, 라벨 수를 C, 라벨 하나의 평균 토큰 수를 L이라고 하자. 쌍별 방식은 길이가 대략 T + L인 입력을 C개 처리하고 공동 방식은 길이가 대략 T + C × L인 입력 하나를 처리한다. 특별 토큰은 생략한 설명이다. 문장을 반복해서 인코딩하는 계산은 줄지만 라벨이 늘어 공동 입력이 길어지는 비용은 남는다.

일반적인 밀집 self-attention의 위치 쌍 계산만 비교하면 전자는 대략 C × (T + L)², 후자는 (T + C × L)²에 비례한다. 이는 실제 모델의 전체 연산량이나 측정 지연을 계산한 식은 아니다. 출력층·메모리 이동·배치·구현 차이가 빠져 있다. 다만 “forward pass가 한 번이므로 라벨 수와 무관하다”는 해석이 왜 성립하지 않는지는 보여 준다. 짧은 라벨을 많이 붙여 문장 재처리를 줄이는 경우와 긴 라벨 설명이 입력을 대부분 차지하는 경우는 다른 선택이다.

공동 인코딩에는 계산 외의 교환도 있다. softmax는 후보가 늘면 분모가 바뀌지만 GLiClass에서는 그 이전의 문장·라벨 표현도 함께 바뀔 수 있다. sigmoid를 쓰더라도 표현의 의존성은 남는다. 라벨별 확률을 독립적인 고정 속성처럼 캐시하거나 서로 다른 후보 목록의 점수를 그대로 비교하기 어려운 이유다. 이 글에서 모델 출력을 관찰한 결과가 아니라 구조에서 따라오는 적용 조건이다.

한 번의 추론도 입력 길이의 영향을 받는다

논문은 NVIDIA A6000 GPU 한 장, 배치 크기 1에서 추론 속도를 측정했다. 라벨 수는 1·2·4·8·16·32·64·128개, 입력 텍스트 길이는 64·256·512토큰이며 각 조합에서 10회 forward pass를 실행했다고 설명한다. 아래는 저자가 보고한 속도 표에서 라벨 수 세 열과 모델 세 행을 추린 것이다. 숫자는 초당 처리한 예제 수이고 높을수록 빠르다.

출처는 라벨 수별 처리량 비교다. 원 표는 텍스트 길이별 값을 따로 제공하지 않는다. 이 표를 특정 길이 요청의 지연이나 서비스 전체 처리량으로 읽을 수는 없다. 모델 다운로드, 요청 대기, 네트워크까지 포함한 운영 측정도 아니다.

라벨이 1개에서 128개로 늘 때 edge 모델의 처리량은 약 20.4% 줄고 위 cross-encoder의 처리량은 약 98.1% 줄어든다. 이 비율은 표에서 직접 계산했다. 반대로 라벨 1개 조건에서는 cross-encoder가 large 모델보다 빠르다. 라벨 수와 모델 크기를 고정하지 않고 “GLiClass가 더 빠르다”고만 말하면 이 차이를 놓친다.

large의 처리량이 라벨 수에 따라 단조롭게 줄지 않는 점도 보인다. 논문의 짧은 측정과 집계 표만으로 변동 원인을 단정할 수 없다. 엄밀한 지연 기준이 필요한 서비스라면 반복 횟수, 워밍업, 입력 길이와 분포를 정하고 직접 측정해야 한다.

속도와 분류 품질은 다른 표로 읽는다

더 작은 모델은 빠르지만 같은 품질을 내지는 않는다. 다음은 저자가 보고한 zero-shot 분류 F1 중 세 데이터셋을 추린 것이다. F1은 0–1 범위이며 높을수록 좋다. 실제 서비스에서 정답 데이터를 만들지 않고도 이 점수가 나온다는 보장은 없다.

GLiClass 결과와 cross-encoder 결과의 대응하는 행을 옮겼다. 이 cross-encoder는 앞 속도 표의 base 모델과도 다른 large 모델이다. zero-shot은 목표 데이터셋의 라벨별 예제로 추가 학습하지 않는 평가 조건을 뜻하며 모델 자체는 분류 데이터로 훈련되어 있다.

Financial PhraseBank에서는 GLiClass large가 앞서지만 SST-2와 AG News에서는 이 cross-encoder가 앞선다. 전체 평균을 바로 대조하지 않은 이유도 있다. 원문 두 표의 데이터셋 목록이 동일하지 않아 각 표의 평균만으로 같은 과제 묶음의 우위를 계산하기 어렵다.

논문은 라벨당 8개 예제를 사용하는 few-shot 결과도 따로 보고한다. 라벨별 예제로 적응한 결과를 zero-shot과 섞으면 입력 설명만으로 얻은 효과와 추가 정답 데이터의 효과를 구분하기 어려워진다.

라벨을 늘릴수록 정의와 입력 예산을 같이 본다

공동 인코딩은 라벨·문장 사이의 상호작용을 가능하게 한다. 대신 모든 라벨 설명과 문장이 입력 예산을 함께 사용한다. 논문의 훈련 최대 길이는 1024토큰이다. 라벨이 길거나 매우 많으면 일부 내용을 자르거나 나눠 처리해야 하고 그렇게 바뀐 입력의 품질도 다시 확인해야 한다.

저자들은 많은 라벨에 비해 문장이 짧을 때 표현이 약해지는 현상을 다루려고 추가 학습 자료와 attention 조정을 사용했다. 이 자료에서는 길이별 텍스트에 참·거짓 후보 라벨을 생성하고 라벨 밀도도 바꾼다. 공동 입력 안에서 문장 정보가 약해지는 조건을 학습에 넣으려는 시도다. 강화학습을 이용한 중간 학습과 논리·NLI 자료를 이용한 후속 학습도 결합한다. GLiClass 학습 과정

이 설계는 관찰한 실패 조건을 겨냥한다는 점에서 타당하지만 결과표는 여러 장치를 합친 모델을 평가한다. 같은 자료와 예산에서 공동 인코딩만 바꾼 비교, 추가 자료나 강화학습만 제거한 비교가 있어야 각 개선의 원인을 분리할 수 있다. 따라서 이 리뷰에서는 라벨 수에 따른 처리량의 유지가 이 구조의 가장 명확한 근거라고 평가한다. 특정 학습 장치가 논리적 이해를 높였다는 설명이나 모든 분류 과제의 품질 우위는 현재 표보다 강한 주장이다.

문의 라우팅에 적용한다면 우선 실제 라벨 정의와 애매한 문의의 정답 기준을 정하자. 이후 동일한 평가 문의에서 후보를 8개·32개·128개로 늘려 품질과 지연을 함께 재면 된다. 관련 없는 라벨을 추가했을 때 기존 라벨의 선택이 바뀌는지, 복수 라벨을 하나로 강제했을 때 어느 문제를 놓치는지까지 확인하면 공동 인코딩의 이득과 비용을 더 구체적으로 판단할 수 있다.

원문

• Ihor Stepanov, Mykhailo Shtopko, Dmytro Vodianytskyi, Oleksandr Lukashov, Alexander Yavorskyi, Mykyta Yaroshenko. GLiClass: Generalist Lightweight Model for Sequence Classification Tasks. arXiv v1, 2025년 8월 11일, PDF.