LLM 분류는 결국 피처 엔지니어링이다

Who Should Read

LLM 프롬프트로 분류 작업을 돌리는데 확률 보정과 임계값 조절이 안 돼 고민인 백엔드 개발자

Core Mechanics

• LLM 분류기는 확률을 믿기 어렵다
  • LLM 판정은 대개 하드 라벨(Ironic/Not 같은 확정 답)이다.
  • 토큰 로그확률이나 자기 확신도는 보정(calibration)됐다고 믿을 근거가 없다.
  • 그래서 정밀도와 재현율을 원칙적으로 맞바꾸기 어렵다
• 정형 데이터를 LLM이 쓴다는 보장이 없다
  • 프롬프트에 정형 데이터를 붙여도 LLM이 반드시 쓰는 건 아니다.
  • 양성 비율 같은 우리 데이터의 기준선도 LLM은 모른다
• LLM 판정 위에 로지스틱 회귀를 얹는다
  • LLM 판정 하나를 피처로 두고 학습 데이터로 계수를 추정한다.
  • 판정이 두 가지뿐이면 판정별 실제 양성 비율이 곧 확률이 된다
• 확률이 나오면 임계값을 고를 수 있다
  • 다른 변수도 회귀에 그냥 추가할 수 있다.
  • 모델 구조도 xgboost나 신경망으로 바꿔 끼울 수 있다
• 성능을 올리는 길이 프롬프트 문구 수정만은 아니다
  • 오분류 사례를 보고 문구를 고치는 대신 피처를 더 뽑는다.
  • 하위 판정 질문, 판정 토큰 로그확률, 여러 번 실행한 결과를 피처로 쓸 수 있다

Community Reactions

• 프롬프트를 자동 생성하는 루프를 제안한 의견
  • 비싼 LLM이 프롬프트를 만들고 싼 LLM이 분류해 그 결과로 작은 ML 모델을 학습하자는 의견이다.
  • 모델이 가장 많이 틀린 예시로 프롬프트를 다시 만들어 피처를 추가하며 반복하자고 한다.
• LLM 판정을 피처로 쓰는 방식이 잘 됐다는 경험
  • LLM-as-a-judge 작업에서 LLM 결정을 기존 ML 모델의 피처로 넣어 최종 결정을 내렸더니 잘 동작했다는 경험이다.
• 메가프롬프트와의 비교가 빠졌다는 반론
  • 속성 목록을 프롬프트에 넣고 추론 후 답하게 하는 방식과 비교해야 한다는 의견이다.
  • 그쪽이 로지스틱 분류기에 꽤 근접하고 분포 밖에서 더 잘 일반화할 것 같다는 의견이다.
• 이진 질문이 낫다는 팁
  • 다중 분류 대신 이진 질문을 쓰면 답의 일관성을 파이프라인 검증 신호로 쓸 수 있었다는 경험이다.
• 로그확률이 의도를 반영하지 않을 수 있다는 지적
  • 구조화 출력이 허용 토큰만 남기면 확률이 원래 모델의 가중치와 다를 수 있다는 의견이다.
  • 추론이 판정보다 먼저라 결정이 이미 끝난 뒤라는 점도 지적한다.

How to Apply

• 지금 쓰는 LLM 분류기에 로지스틱 회귀 얹기
  • 라벨 있는 검증 데이터에 LLM 판정을 돌려 판정별 실제 양성 비율을 구하라.
  • 그 비율을 확률로 쓰고 Brier 점수를 이전과 비교하라
• 오분류 사례로 하위 질문 피처 만들기
  • 틀린 사례 10개를 읽고 공통 특징을 예/아니오 질문으로 바꿔라.
  • 질문들을 구조화 출력의 bool 필드로 한 번에 뽑아라
• 정형·규칙 피처를 같은 회귀에 합치기
  • 길이, URL 유무, 느낌표 수 같은 계산 가능한 값을 LLM 피처 옆에 넣어라.
  • 판정만, +LLM 피처, +규칙 피처 세 모델의 F1을 나란히 비교하라
• 임계값을 비즈니스 기준으로 정하기
  • 확률이 나오면 정밀도와 재현율 곡선을 그려라.
  • 오탐 비용에 맞는 지점에서 임계값을 골라라

Try It

# Claude나 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 코드 없이 피처 설계만 시험)

너는 분류 피처 설계자다. 아래 분류 작업에서 LLM이 한 번에 뽑을 수 있는 예/아니오 피처 질문을 만들어라.

작업: {{분류 작업 설명}}

현재 LLM이 틀린 사례:
{{오분류 사례 5~10개와 정답}}

지시:
1. 오분류 사례의 공통 특징을 3줄로 요약해라.
2. 판정과 별개로 답할 수 있는 bool 피처 질문 10개를 만들어라.
3. 각 질문마다 pydantic Field 설명 문장을 써라.
4. 질문들이 서로 겹치는지 점검해라.

이어서 해 볼 것: 만든 질문으로 검증 데이터를 돌려 판정만 쓴 경우와 F1, Brier를 비교해 보라.

Terminology

관련 논문

• The Judge Can Debias Itself: LLM-as-a-Judge가 스스로 편향을 고치게 하는 법

  심사 프롬프트에 편향 경고를 넣거나 스스로 비판시켰더니 21개 중 20개 조합에서 정확도가 올랐다

• 미국 노동시간의 90%는 AI 벤치마크가 제대로 다루지 못하는 일이다

  벤치마크 29개를 직업 과제에 매핑했더니 노동시간 90%가 커버 밖

• Postgres 19, AI 코드 리뷰가 버그를 너무 많이 찾아 출시 연기

  LLM 코드 리뷰가 버그를 쏟아내 Postgres 19가 11월로 밀리고 기능 8~10개가 빠졌다

• StarSkirmish Bench v0.2: LLM이 1시간 만에 짜는 StarCraft 봇 대결

  LLM에게 1시간 동안 StarCraft 봇을 짜게 했더니 GPT-6 Astra가 1위

• 그럴듯한 설명 하나면 멀티모달 LLM 심사위원도 속는다 (JUPE 벤치마크)

  정답은 그대로 두고 설명만 붙였더니 MLLM 심사위원의 오답 거절률이 12.7~13.8%p 떨어졌다

• 신경망은 이미 깔끔하다: polysemanticity의 원인 재해석

  뉴런을 직접 들여다봤더니 대부분 한 가지 역할이 있었다는 주장

• Linus Torvalds의 첫 LLM 보조 패치 시리즈

  Linus가 LLM으로 folio 조회 패치 10개를 만들어 read() 벤치가 10배 빨라졌다

Related Resources

• https://minimallysufficient.com/posts/llm-classification-is-feature-extraction/
• https://softwaredoug.com/blog/2025/01/21/llm-judge-decision-