LLM 분류기를 특징 추출기로 재활용해 확률 보정 문제를 우회한다

LLM에게 "이 텍스트가 아이러니인가"라고 물어 라벨을 받아 쓰는 방식은 결과가 의외로 쓸 만하다. 문제는 그다음이다. 확률이 아니라 딱 떨어지는 라벨이 돌아오고, 임계값을 조정해 정밀도와 재현율을 맞바꾸려 해도 손잡을 곳이 없다. 이 글은 그 답답함의 원인을 "LLM을 분류기로 쓰고 있기 때문"으로 규정하고, LLM의 판정을 특징(feature) 하나로 취급해 기존 머신러닝 파이프라인에 넣는 방법을 제안한다.

구체적으로 지적되는 결함은 세 가지다. 첫째, 보정(calibration)이 없다. 토큰 로그 확률을 받아도 그것이 실제 확률과 맞는다고 볼 근거가 없고, 모델에게 신뢰도를 물어봐도 마찬가지다. 둘째, 구조화된 데이터를 프롬프트에 붙여 넣어도 모델이 실제로 그 정보를 썼는지 알 수 없다. 셋째, LLM에 내재한 사전확률이 우리 데이터 분포와 어긋날 수 있다. 양성 클래스가 드문 모집단인지, 농축된 모집단인지 모델은 알지 못하며, 그 맥락을 알려줘도 판정에 제대로 반영됐는지 확인할 길이 없다.

제안하는 구조는 단순하다. LLM 판정을 하나의 입력 변수로 두고 로지스틱 회귀를 얹는다. p(y=1|x) = σ(α + β·LLM(x)) 형태다. β를 무한대로 보내면 사실상 기존 LLM 분류기로 되돌아가지만, 그건 합리적인 파라미터 선택이 아니다. 학습 데이터로 α와 β를 추정하면 결과는 결국 LLM이 1이라고 한 표본 중 실제 양성 비율, 0이라고 한 표본 중 실제 양성 비율이라는 두 개의 경험적 확률로 수렴한다.

이렇게만 해도 원했던 성질 대부분이 되살아난다. 출력이 확률이므로 보정이 되고, 운영 임계값을 골라 정밀도와 재현율을 조절할 수 있다. 다른 공변량을 얼마든지 추가할 수 있고, 학습 데이터의 기준선에 맞춰 적응하며, 예제에 가중치를 줘 다른 분포를 겨냥할 수도 있다. LLM 판정 자체의 의미를 해석하는 문제는 남지만, 그 판정이 최종 결정에 어떻게 기여하는지는 훨씬 분명해진다.

글은 SemEval 2018 Task 3 데이터셋으로 예시를 든다. 전문가가 아이러니 라벨을 붙인 트윗 4618건(학습 3834건, 테스트 784건)이다. gemini-3.1-flash-lite에 아이러니 여부와 짧은 근거를 JSON 스키마로 요구하는 프롬프트를 배치로 돌렸다. 원샷 치고는 놀라운 성능이지만 Brier 점수는 나쁘다. 무작위 추측만 해도 0.25가 나오는 지표다. 로지스틱 회귀를 씌우면 보정은 얻지만, 순서 자체는 바뀌지 않으므로 F1 점수는 그대로다.

배경에는 LLM이 애초에 분류기로 설계된 물건이 아니라는 인식이 깔려 있다. 그래서 성능이 아쉬울 때 할 수 있는 일이 프롬프트 문구를 만지는 것뿐인데, 이는 조언은 넘치고 확실한 지침은 드문 작업이다. 머신러닝 관점에서 모델을 개선하는 정공법은 데이터를 늘리고, 특징을 다듬고, 아키텍처를 바꾸는 것이다.

실무적으로 달라지는 지점은 명확하다. LLM 판정을 특징으로 다루면 그 특징이 항상 양성을 이끌어야 한다고 믿을 때 경험적으로 검증하고 디버깅할 수 있다. 특징 자체를 별도 타깃으로 삼아 그 분류기를 개선하는 재귀적 접근도 가능하다. 모델의 잔차를 보며 프롬프트 문구를 고치는 대신 어떤 특징을 더 넣을지 고민할 수 있다. 판정 토큰의 로그 확률을 특징으로 쓰거나, 여러 번 실행하거나, 하위 판정(subverdict)을 추가로 요청하는 방법도 있다. 분류기 아키텍처는 완전히 교체 가능해서 로지스틱 회귀가 싫으면 xgboost나 신경망, 심지어 LLM이 구현한 규칙 기반 시스템을 써도 된다.

대가는 있다. 학습 데이터가 필요하다는 점이다. 학습 없이 바로 쓰는 것이 LLM 분류기의 매력이었는데, 이 패러다임에서는 그 매력이 사라진다. 다만 성능을 정량화하려면 어차피 테스트셋이 필요하니, 학습용으로 조금 더 모으는 부담은 생각보다 크지 않다는 것이 글쓴이의 주장이다. LLM 판정 자체를 해석하는 문제도 완전히 해결되지는 않는다.