LLM 분류 오류 줄이기: 계층적 분류로 검색 의도·콘텐츠를 나누는 실전 패턴

AI에게 추상적인 개념을 직접 분류시키면 판단이 일관되지 않아 오분류가 늘어나요. 대신 구체적인 카테고리는 AI가 판단하게 하고, 추상적인 상위 개념으로의 매핑은 코드가 결정적으로 처리하면 오분류를 크게 줄일 수 있어요. 이건 GEO 콘텐츠 파이프라인에서 검색 의도를 분류할 때뿐 아니라, AI로 무언가를 분류해야 하는 모든 작업에 적용되는 설계 원칙이에요.

콘텐츠 전략의 기반은 검색 의도를 정확히 파악하는 데서 시작해요. 잘못된 분류는 잘못된 콘텐츠를 만들게 하고, 키워드 리서치의 효과를 반감시켜요. 문제는 "이 키워드를 인지/탐색/결정/실행 단계 중 하나로 분류해줘"처럼 직관적으로 보이는 지시가 실제로는 AI에게 매우 어려운 일이라는 점이에요.

왜 직접 분류시키면 실패할까

퍼널 단계 같은 프레임워크를 AI에게 그대로 던지면 일관성 없는 판단이 나와요.

왜 이런 일이 생길까요. 퍼널 단계는 마케터가 만든 추상적 프레임워크예요. "탐색 단계"가 정확히 어디서 시작하고 끝나는지는 사람마다도, 모델마다도 해석이 달라요.

핵심 인사이트는 이거예요. 모델은 구체적이고 관찰 가능한 것을 잘 판단하고, 추상적이고 해석이 필요한 것을 잘 못 판단해요.

• "이 키워드에 가격 관련 단어가 있나?" → 관찰 가능해서 쉬움
• "이 키워드는 구매 여정의 어느 단계인가?" → 해석이 필요해서 어려움

계층적 분류의 2단계 구조

이 문제를 푸는 방법은 판단을 두 단계로 쪼개는 거예요. 복잡한 작업을 모듈 단위로 분해하면 정확도가 올라간다는 건 프롬프트 엔지니어링 연구에서도 반복적으로 확인된 결과예요^[1].

Step 1: 모델이 판단 (구체적 카테고리)

  "가격" → qualify    "vs" → compare    "방법" → action
  "뭐야" → concept    "추천" → recommend  "오류" → solve

  → 모델은 관찰 가능한 신호만 판단하면 됨

              (결정적 코드)

Step 2: 코드가 매핑 (추상적 상위 개념)

  concept   → 인지
  recommend → 탐색
  compare   → 탐색
  qualify   → 결정
  action    → 실행
  solve     → 실행

핵심은 이거예요. 모델에게는 쉬운 일(구체적 카테고리 판단)만 시키고, 어려운 일(추상적 매핑)은 코드가 담당해요.

설계 원칙 4가지

원칙 1: 상호 배타적인 최상위 카테고리

카테고리 간 경계가 명확해야 해요. "recommend"와 "compare"는 개념적으로 비슷하지만, "추천해줘" 같은 표현과 "vs" 같은 표현으로 신호 기반 구분이 가능해요.

원칙 2: Many-to-One 매핑으로 에러를 무해하게 만들기

이게 이 패턴의 핵심이에요.

모델이 recommend와 compare를 헷갈렸다고 가정하면:

  "X 추천해줘" → 모델: compare (오분류)
                    ↓
               코드 매핑: 탐색  ← 어차피 같은 결과

  "X 추천해줘" → 모델: recommend (정분류)
                    ↓
               코드 매핑: 탐색  ← 동일한 결과

recommend와 compare가 둘 다 "탐색" 단계로 매핑되기 때문에, 모델이 둘을 혼동해도 최종 결과는 같아요. 모든 오분류를 막는 건 불가능하지만, 유사한 카테고리를 같은 상위 그룹에 매핑하면 오분류가 발생해도 최종 결과에는 영향이 없는 구조를 만들 수 있어요.

원칙 3: 확신도 기반 폴백

모델이 카테고리를 판단할 때 확신도가 낮으면 기본값으로 폴백하는 안전장치를 둬요. 애매한 케이스를 억지로 하나의 카테고리에 강제로 밀어 넣는 것보다, 낮은 확신도를 표시하고 안전한 기본값으로 처리하는 게 전체 시스템의 안정성을 높여요.

원칙 4: 코드 매핑은 항상 결정적이어야 한다

코드 매핑은 같은 입력에 항상 같은 출력을 줘야 해요. 모델의 비결정적인 특성을 코드의 결정적인 특성으로 보완하는 구조가 이 패턴의 본질이에요.

실전 적용: Before / After

Before (추상 개념을 직접 분류)

After (구체적 카테고리 → 코드 매핑)

검색 의도 분류를 넘어선 활용

계층적 분류는 검색 의도 분류에만 쓰이는 패턴이 아니에요. AI로 무언가를 카테고리화해야 하는 작업이라면 대부분 같은 구조를 적용할 수 있어요.

콘텐츠 주제 태깅: "이 글의 대주제가 뭔가"를 직접 물으면 모델마다 판단이 갈리기 쉬워요. 대신 "이 글에 가격 관련 언급이 있는가", "비교 표가 있는가", "단계별 절차가 있는가"처럼 관찰 가능한 특징을 먼저 판단시키고, 그 조합으로 주제를 코드가 결정하면 훨씬 안정적이에요.

문의·티켓 분류: 고객 문의를 "긴급/일반/낮음"처럼 추상적인 우선순위로 바로 분류시키면 기준이 흔들려요. 대신 "환불 언급이 있는가", "서비스 중단 언급이 있는가"처럼 구체적 신호를 먼저 분류하고, 신호 조합에 따라 우선순위를 코드가 결정하는 방식이 훨씬 일관돼요.

경쟁사 콘텐츠 분류: 경쟁사의 콘텐츠를 "공격적/방어적" 같은 추상적 톤으로 분류하기보다, "가격을 직접 언급하는가", "우리 브랜드명을 언급하는가" 같은 구체적 신호를 먼저 잡아내고 상위 톤을 코드로 매핑하면 재현성이 높아져요.

세 사례 모두 패턴은 같아요. 사람이 보기에도 애매한 추상적 판단을 모델에게 그대로 넘기지 않고, 그 판단을 구성하는 관찰 가능한 조각으로 쪼갠 뒤 조합은 코드가 담당하는 것이에요.

GEO 관점: 퍼널 커버리지 균형

분류가 특정 카테고리(주로 개념 설명형)에 쏠리면 인지 단계 콘텐츠만 과잉 생산되고, 탐색·결정·실행 단계 질문에서 AI 인용 기회를 놓쳐요^[3]. 계층적 분류로 카테고리를 정밀하게 나누면, 어떤 단계 콘텐츠가 부족한지 데이터로 확인하고 균형 있게 채울 수 있어요. 이건 콘텐츠가 검색 의도와 정확히 맞아야 한다는 원칙과도 이어져요^[2].

3단계 이상은 언제 필요할까

대부분의 경우 2단계(구체적 카테고리 → 추상적 상위 개념)로 충분하지만, 카테고리 수가 아주 많거나 도메인이 복잡한 경우엔 3단계 구조를 고려할 수 있어요. 예를 들어 "구체적 신호 판단 → 중간 카테고리 → 최종 퍼널 단계"처럼 한 단계를 더 끼워 넣는 방식이에요.

다만 3단계 이상으로 넘어갈 때는 주의할 점이 있어요. 매핑 테이블이 두 개로 늘어나면 관리 부담도 함께 늘어나고, 각 단계에서 발생하는 오류가 다음 단계로 누적될 위험도 커져요. 복잡한 추론 작업을 더 단순한 하위 문제로 분해하는 접근 자체는 효과적이지만^[1], 분해 단계가 많아질수록 각 단계의 정확도를 개별적으로 관리해야 하는 비용도 커진다는 걸 감안해야 해요.

그래서 3단계 이상을 고려하기 전에 먼저 확인할 것은 "2단계로 처리했을 때 실제로 어떤 오분류가 남는가"예요. 남은 오분류가 소수의 특정 카테고리에 집중돼 있다면, 전체를 3단계로 확장하기보다 그 카테고리 하나만 세분화하는 게 더 효율적인 경우가 많아요.

오분류를 줄이는 실전 팁

1. 카테고리 수는 6개 안팎이 스윗스팟이에요. 너무 적으면 구분이 뭉뚱그려지고, 너무 많으면 모델이 경계를 혼동하기 시작해요.
2. 모델에게 어려운 판단을 시키지 말고 쉬운 판단만 시키세요. "구매 여정의 어느 단계인가"는 전문가도 의견이 갈리는 추상적 판단이에요. "가격 관련 단어가 있는가" 같은 관찰 가능한 판단만 시키세요.
3. Many-to-One 매핑은 에러를 0으로 만드는 게 아니라 무해하게 만들어요. 유사 카테고리끼리 같은 상위 그룹에 매핑하면 오분류가 발생해도 최종 결과에 영향이 없는 구조가 돼요.
4. 매핑 테이블은 한 곳에서만 관리하세요. 매핑 로직이 여러 곳에 흩어지면 불일치가 생겨요.
5. 테스트 데이터를 체계적으로 관리하세요. 실제 키워드로 정답 셋을 만들고, 변경이 있을 때마다 정확도를 측정해야 해요. 분류가 콘텐츠 파이프라인의 상류에 있기 때문에, 여기서의 정확도가 전체 품질을 결정해요.

계층적 분류는 결국 "모델이 잘하는 일과 못하는 일을 정확히 나누는" 설계 감각이에요. AI에게 모든 판단을 맡기려는 유혹을 참고, 쉬운 판단만 맡긴 뒤 나머지는 결정적인 코드로 처리하면 훨씬 안정적인 시스템을 만들 수 있어요.

이 글과 이어지는 내용은 llms.txt는 순위 버튼이 아닌 AI 에이전트를 위한 안내판이에요, AI 쇼핑 에이전트에 상품이 추천되려면: 상품 정보 구조화 가이드, GEO 데이터 AI 에이전트 설계 원칙: 구조화 도구 호출, 되돌릴 수 없는 작업 막기에서 볼 수 있어요.