Skip to content

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

✨ Learn with Quiz
|

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

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

누구에게는 해당 없는가

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

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

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

정리

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

원문과 관련 글

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

The Technique of Hallucinating Instead of Classifying, and How to Validate It — Why a Fake Label Beats the Raw Query

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Don't classify, hallucinate, the item number is 49249523, and as of 2026-08-15 it stood at 212 points with 82 comments. The link points to a post by softwaredoug.

What the technique is

The setup is common. You have to place products or documents into a fixed taxonomy, but the taxonomy has hundreds of entries, so it does not fit in a prompt and it runs into schema size limits on structured outputs.

The usual response is constrained decoding — preventing the model from producing anything outside the valid list. But when the list is large, the list itself is the cost and the limit.

What the post proposes runs the other way: do not constrain the model, just let it invent. The procedure is three steps.

  1. Ask a small, cheap model to write freely what this item's classification would be. It does not matter if the path does not exist in the real taxonomy.
  2. Embed both the invented string and all the real taxonomy entries.
  3. Take the dot product and pick the closest real entry.

The example given is concrete. For a query, the model invents a path like Furniture / Living Room / Tables / Coffee, which resolves to the real taxonomy's Furniture / Living Room Furniture / Coffee Tables & End Tables / Coffee Tables. The post states that every real classification was embedded with MiniLM and matched by dot product.

The post connects the idea to the same family as generating hypothetical documents to improve matching in retrieval.

Why it can work

The benefit the post emphasizes is cost: a small model suffices, and it sidesteps schema size limits.

But there is a more interesting question. Is going through an invented string better than simply embedding the raw query? If there is no gain, the technique has only added a step.

The explanation for that is embedding asymmetry. The raw query is a short product description. The target, though, is a hierarchical path string. Even when the two mean the same thing, the shape of the sentence is different, and distance in an embedding space is influenced by that shape as well as by meaning.

Ask a model to invent a classification and its output naturally becomes a string that looks like a classification. The invented result therefore lands in the same shaped region as the target, which favors nearest-neighbor search. This is the same principle that makes hypothetical documents work in retrieval: turn the question into the shape of a document, then compare it against documents.

Put plainly, what this technique transfers is not knowledge but form. The threads on embedding models and retrieval quality are in debugging RAG retrieval quality and state-of-the-art text embedding models.

What the comments raised

The post reports no measured results — it reads as a conceptual writeup — and the comments went straight at that.

The sharpest comment named the assumption the technique rests on: is it not presupposing that the invented classification will be more selective with respect to the real schema than the query itself? That question tests the asymmetry logic above head-on, and only measurement answers it.

Another asked whether an A/B test was run, and along with it whether classification returned correctly into the known categories, and whether errors from the model's invention and from the embedding search compounded. Those two questions define exactly the experiment you must run before adopting this.

And two cheaper alternatives came up.

  • Retrieve then classify: embed the query, compare against the real taxonomy entries, and put only the few closest into the prompt for a small model to choose from. It solves the schema size problem directly while removing a generation step.
  • Structured output walking down the hierarchy: decide at the top level, then at each level below. More round trips, but fewer options per step.

One comment also shared a procedure for when no taxonomy exists at all: embed everything, cluster, sample from each cluster, and have the model name that cluster — with the caveat that it is sensitive to thresholds. Another noted doing something similar with word embeddings ten years ago.

How to validate it

If you are considering this technique, what to measure before adoption is clear. The experiment the comments demanded is the design.

Example: minimum comparison experiment
Shared setup - 500 to 1,000 human-labeled items

  Option A (baseline)    : embed the query as-is -> nearest classification
  Option B (proposed)    : query -> model invents a classification -> embed -> nearest
  Option C (alternative) : embed query -> top 10 candidates into prompt -> model picks

Values to record
  - accuracy (top 1, top 3)
  - cost and latency per item
  - in Option B, how far the invented string sat from the real taxonomy

Option A is the crux of this experiment. Measure B without A and you cannot tell whether the technique contributed anything. That comparison is exactly what the post does not answer.

And to see error compounding, split Option B's failures into two groups: cases where the invented classification was itself wrong, and cases where the invention was plausible but the embedding attached it to the wrong entry. If the first dominates, fix the generation prompt; if the second does, fix the embedding model or how the entries are represented. Without that split, overall accuracy tells you nothing about where to work.

Who this does not apply to

If your taxonomy has a few dozen entries or fewer, you do not need this. Putting the list in the prompt is more accurate, cheaper, and easier to debug. This technique exists for when the list is too large to include.

It also does not suit classification where accuracy is a regulatory requirement. Where misclassification is expensive — tax codes, medical codes — routing through a plausible intermediate artifact is itself an audit finding. Deterministic rules and human review remain the answer there.

In environments where the taxonomy changes frequently it is actually favorable, since only the embeddings need recomputing and no prompt has to be edited. Conversely, if the taxonomy is fixed and you have enough labeled data, training a dedicated classifier may be cheaper and faster than all of this.

Summary

The value of this technique is not in the provocative framing about the model making things up but in the observation underneath it: in embedding search, the shape of what you say matters as much as what you say, and you can insert one intermediate artifact to align that shape with the target. But the post did not measure the gain, so this is not yet a validated method — it is a hypothesis worth validating. If you adopt it, start by measuring it beside the baseline of simply embedding the raw query.

The explanation of asymmetry and the comparison experiment design are my own, built on the post and the comments.