Skip to content

필사 모드: 분류하지 말고 지어내라는 기법과 그 검증 — 가짜 레이블이 원본 질의보다 나은 이유

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Don't classify, hallucinate, 아이템 번호는 49249523이고 2026-08-15 기준 212점에 댓글 82개입니다. 링크는 softwaredoug의 글입니다.

기법의 내용

문제 설정은 흔합니다. 상품이나 문서를 정해진 분류 체계에 넣어야 하는데, 그 체계가 수백 개 항목이라 프롬프트에 다 넣기 어렵고, 구조화된 출력의 스키마 크기 제한에도 걸립니다.

일반적인 대응은 제약 디코딩입니다. 모델이 유효한 목록 밖으로 나가지 못하게 막는 것입니다. 그런데 목록이 크면 그 목록 자체가 비용이고 제한입니다.

원문이 제안하는 것은 반대 방향입니다. 모델을 제약하지 말고 그냥 지어내게 두는 것입니다. 절차는 셋입니다.

  1. 작고 싼 모델에게 이 항목의 분류가 무엇일지 자유롭게 쓰게 합니다. 실제 체계에 없는 경로가 나와도 상관없습니다.
  2. 지어낸 문자열과 실제 분류 항목들을 모두 임베딩합니다.
  3. 내적으로 가장 가까운 실제 항목을 고릅니다.

원문이 든 예는 구체적입니다. 어떤 질의에 대해 모델이 Furniture / Living Room / Tables / Coffee 같은 경로를 지어내고, 그것이 실제 체계의 Furniture / Living Room Furniture / Coffee Tables & End Tables / Coffee Tables로 해결됩니다. 원문은 실제 분류 항목 전체를 MiniLM으로 임베딩해 두고 내적으로 붙였다고 밝히고 있습니다.

원문은 이 발상이 검색에서 가상 문서를 만들어 매칭을 돕는 기법과 같은 갈래라고 연결합니다.

왜 동작할 수 있는가

원문이 강조하는 이점은 비용입니다. 작은 모델로도 되고 스키마 크기 제한을 우회할 수 있다는 것입니다.

그런데 더 흥미로운 질문은 따로 있습니다. 지어낸 문자열을 거치는 것이 원본 질의를 그냥 임베딩하는 것보다 나은가입니다. 만약 나은 점이 없다면 이 기법은 단계만 늘린 것입니다.

여기에 대한 설명이 임베딩 비대칭성입니다. 원본 질의는 짧은 상품 표현입니다. 그런데 목표인 분류 항목은 계층 경로 형태의 문자열입니다. 둘은 같은 것을 가리켜도 문장의 모양이 다릅니다. 임베딩 공간에서 거리는 의미뿐 아니라 이 모양에도 영향을 받습니다.

모델에게 분류를 지어내라고 시키면 출력은 자연히 분류처럼 생긴 문자열이 됩니다. 즉 지어낸 결과는 목표와 같은 모양의 공간에 놓입니다. 그래서 최근접 탐색이 유리해집니다. 이것이 검색에서 가상 문서를 만드는 기법이 통하는 원리와 같습니다. 질문을 문서 모양으로 바꿔서 문서들과 비교하는 것입니다.

정리하면 이 기법이 옮기는 것은 지식이 아니라 형식입니다. 임베딩 모델과 검색 품질에 대한 갈래는 RAG 검색 품질 디버깅최신 텍스트 임베딩 모델에 정리해 두었습니다.

댓글이 지적한 것들

원문에는 측정 결과가 없습니다. 개념 설명에 가깝고, 댓글은 정확히 그 지점을 파고들었습니다.

가장 날카로운 댓글은 이 기법이 전제하고 있는 것을 짚었습니다. 지어낸 분류가 실제 체계에 대해 원본 질의보다 더 선별적일 것이라고 가정하고 있는 것 아니냐는 물음이었습니다. 이것은 위에서 설명한 비대칭성 논리를 정면으로 시험하는 질문이고, 답은 측정으로만 나옵니다.

다른 댓글은 A/B 검증을 했는지 물으면서, 알고 있는 분류로 제대로 되돌아왔는지 그리고 모델의 환각과 임베딩 검색의 오류가 겹쳐서 누적되지는 않았는지를 함께 물었습니다. 이 두 질문이 이 기법을 도입할 때 반드시 해야 할 실험을 그대로 정의합니다.

그리고 더 싼 대안이 두 개 나왔습니다.

  • 후보 축소 후 분류: 질의를 임베딩해서 실제 분류 항목들과 비교하고, 가까운 것 몇 개만 프롬프트에 담아 작은 모델에게 고르게 하는 방식입니다. 스키마 크기 문제를 직접 해결하면서 생성 단계가 하나 줄어듭니다.
  • 계층을 따라 내려가는 구조화 출력: 최상위에서 한 번, 그 하위에서 한 번씩 정하며 내려가는 방식입니다. 호출 수는 늘지만 각 단계의 선택지가 적습니다.

또 한 댓글은 분류 체계가 아예 없을 때의 절차를 공유했습니다. 전체를 임베딩해 군집을 만들고, 각 군집에서 표본을 뽑아 모델에게 그 군집의 이름을 짓게 하는 방식이며, 임계값에 민감하다는 단서를 달았습니다. 10년 전에 단어 임베딩으로 비슷한 일을 했다는 댓글도 있었습니다.

어떻게 검증하나

이 기법을 검토한다면 도입 전에 재야 할 것이 분명합니다. 댓글이 요구한 실험이 그대로 설계가 됩니다.

예시: 최소 비교 실험
공통 준비 - 사람이 라벨링한 항목 500~1,000건

  A안 (기준)  : 질의를 그대로 임베딩 → 최근접 분류
  B안 (제안)  : 질의 → 모델이 분류를 지어냄 → 임베딩 → 최근접 분류
  C안 (대안)  : 질의를 임베딩 → 상위 10개 후보만 프롬프트 → 모델이 선택

기록할 값
  - 정확도 (상위 1개, 상위 3개)
  - 항목당 비용과 지연 시간
  - B안에서 지어낸 문자열이 실제 체계와 얼마나 떨어져 있었는지

A안이 이 실험의 핵심입니다. A안을 빼놓고 B안만 재면 이 기법이 기여했는지 알 수 없습니다. 원문이 답하지 않은 것도 정확히 이 비교입니다.

그리고 오류 누적을 보려면 B안에서 틀린 건들을 두 갈래로 나눠 봐야 합니다. 지어낸 분류 자체가 엉뚱했던 경우와, 지어낸 분류는 그럴듯했는데 임베딩이 엉뚱한 항목에 붙인 경우입니다. 전자가 많으면 생성 프롬프트를 고치고, 후자가 많으면 임베딩 모델이나 항목 표현을 고쳐야 합니다. 이 구분 없이 전체 정확도만 보면 어디를 손대야 할지 알 수 없습니다.

누구에게는 해당 없는가

분류 항목이 수십 개 이하라면 이 기법은 필요 없습니다. 그냥 목록을 프롬프트에 넣는 것이 더 정확하고 더 싸며 디버깅도 쉽습니다. 이 기법의 존재 이유는 항목 수가 커서 목록을 넣을 수 없을 때입니다.

정확도가 규정 요건인 분류에도 맞지 않습니다. 세무 코드나 의료 코드처럼 오분류의 대가가 큰 곳에서는 그럴듯한 중간 산출물을 거치는 구조 자체가 감사 대상이 됩니다. 그런 곳에서는 결정론적 규칙과 사람 검토가 여전히 답입니다.

분류 체계가 자주 바뀌는 환경에서는 오히려 유리합니다. 임베딩 쪽만 다시 계산하면 되고 프롬프트를 고칠 필요가 없기 때문입니다. 반대로 체계가 고정되어 있고 학습 데이터가 충분하다면, 전용 분류기를 학습시키는 것이 이 모든 것보다 싸고 빠를 수 있습니다.

정리

이 기법의 값어치는 모델이 지어낸다는 자극적인 표현이 아니라 그 아래 있는 관찰에 있습니다. 임베딩 검색에서는 무엇을 말하는지만큼 어떤 모양으로 말하는지가 중요하고, 중간 산출물을 하나 끼워 그 모양을 목표와 맞출 수 있다는 것입니다. 다만 원문은 그 이득을 재지 않았고, 그래서 이 기법은 아직 검증된 방법이 아니라 검증할 가치가 있는 가설입니다. 도입한다면 원본 질의를 그냥 임베딩하는 기준선과 나란히 재는 것에서 시작해야 합니다.

원문과 관련 글

비대칭성에 대한 설명과 비교 실험 설계는 원문과 댓글에서 확인한 내용을 바탕으로 제가 정리한 것입니다.

현재 단락 (1/43)

Hacker News API로 확인한 항목입니다. 제목은 `Don't classify, hallucinate`, 아이템 번호는 49249523이고 2026-08-15 기준 212점...

작성 글자: 0원문 글자: 3,732작성 단락: 0/43