문서 분류를 10만 개 이상의 레이블로 확장하기

Databricks 전반에서 수천 명의 고객이 자유 형식의 텍스트를 10만 개 이상의 레이블로 구성된 표준화된 분류 체계에 매핑하는 프로덕션 워크로드를 구축하고 있습니다. 몇 가지 일반적인 사용 사례는 다음과 같습니다:

• 생의학 개체 연결. 임상 기록 및 연구 논문에는 수천 개의 생의학 개념 식별자가 포함된 어휘집인 Unified Medical Language System의 개념과 매칭되어야 하는 질병, 약물, 처치 등이 언급됩니다.
• 공급업체 표준화. 지출 패턴을 분석하기 위해 금융 회사는 "SBUX #4471 SEATTLE WA"와 같은 원시 거래 문자열을 10만 개 이상의 가맹점 세트를 기준으로 표준화합니다.
• 기업 표준화. 기업은 회사 설명을 10만 개 이상의 기업 세트와 매칭하여 서로 다른 내부 시스템 간의 고객 레코드 중복을 제거합니다.

이러한 각 사용 사례는 *분류 체계(taxonomy)*라고도 하는 대규모 레이블 세트를 정의하며, 모든 입력은 해당 레이블 중 하나 이상에 매핑되어야 합니다. 고객은 일반적으로 다음과 같은 기준을 바탕으로 프로덕션 솔루션을 평가합니다:

1. 품질: 후속 의사 결정을 이끌어낼 수 있을 만큼 정확한 분류 결과를 생성합니다.
2. 비용: 특히 대규모 작업에서 문서당 분류 비용을 낮게 유지합니다.
3. 처리량: 대개 수십만 건에 달하는 대규모 워크플로우를 합리적인 시간 내에 처리합니다.

이 세 가지 요구사항을 모두 충족하는 것은 프로덕션 환경에서 대규모 분류 체계 분류를 어렵게 만들며, Databricks에서는 이에 대한 솔루션을 연구하고 구축하는 데 우선순위를 두고 있습니다.

기존 접근 방식이 한계를 보이는 이유

과거에는 기업들이 맞춤형 정규식(regex) 규칙, 키워드 매칭, 지도 학습 머신러닝 분류기에 의존하여 대규모 분류 체계 분류를 처리했습니다. 하지만 이러한 접근 방식은 몇 가지 측면에서 한계가 있습니다:

취약한 패턴 매칭. 정규식 및 키워드 규칙은 정확한 매칭에 의존하므로, 실제 데이터의 예측 불가능한 형식에 쉽게 무너집니다. YipitData와 같은 기업들은 예외 사례(edge case)와 분류 체계 변경에 대응하기 위해 정규식 패턴을 지속적으로 업데이트해야 했으며, 이는 수천 개의 레이블 규모에서는 유지 관리하기가 어렵습니다.

희소하고 편향된 그라운드 트루스. 실제 레이블 분포는 롱테일(long-tailed) 형태를 띱니다. 소수의 레이블이 대부분의 문서를 차지하는 반면, 수천 개의 레이블은 거의 나타나지 않습니다. 대부분의 고객은 분류 체계의 모든 레이블에 대한 그라운드 트루스 문서가 부족하여 지도 학습 분류기를 학습시키기가 어렵습니다. 분류기는 학습 데이터에 포함되지 않은 레이블을 분류하는 방법을 배울 수 없으며, 클래스 불균형으로 인해 자주 등장하는 레이블은 과잉 예측하고 드물게 등장하는 레이블은 과소 예측하게 됩니다.

분류 체계 변화(Taxonomy drift). 새로운 비즈니스 사용 사례를 반영하고 분류 품질을 개선하기 위해 레이블과 그 설명이 끊임없이 추가, 폐기 및 수정됩니다. 분류 체계의 새 버전이 출시될 때마다 정규식 패턴을 업데이트해야 하고 분류기를 재학습시켜 배포해야 합니다.

최근에는 분류 작업을 위해 대규모 언어 모델(LLM)을 사용하는 고객이 늘고 있습니다. LLM을 사용하면 더 이상 모델을 학습시키거나 취약한 정규식 패턴을 유지 관리할 필요가 없습니다. 그러나 수십만 개의 레이블 규모에서는 LLM이 컨텍스트 창(context window) 내에 분류 체계를 모두 담아 추론하는 데 어려움을 겪습니다. 단일 프롬프트에 수천 개의 후보가 들어가면 모델에 환각(hallucination) 현상이 발생하여 분류 체계에 존재하지도 않는 레이블을 반환하기 시작합니다. 또한 프롬프트 캐싱을 활용하더라도 수십만 건의 문서에 대한 전체 분류 체계를 프론티어 모델에 전달하는 것은 대규모 작업 시 비용 부담이 큽니다.

대규모 레이블 분류에 접근하는 방법

대규모 분류 체계에서 비용과 품질의 최적의 균형을 찾기 위해 세 가지 서로 다른 방법을 평가합니다:

방법 1: 벡터 검색

첫 번째로 테스트한 방법은 벡터 검색을 사용하여 주어진 입력에 가장 적합한 레이블을 검색하는 것입니다. 2026년 7월 기준 상위권에 랭크된 오픈 가중치 임베딩 모델인 Qwen3-Embedding-8B 모델을 사용하여 모든 레이블(설명이 있는 경우 설명 포함)과 입력 문서를 임베딩합니다. 그런 다음 의미론적 유사성과 어휘적 유사성을 모두 가중하는 하이브리드 점수로 문서에 대한 각 레이블의 관련성을 평가합니다.

의미론적 점수는 문서와 레이블 임베딩 간의 코사인 유사도를 계산하여 결정됩니다. 코사인 유사도가 높을수록 텍스트가 정확히 일치하지 않더라도 레이블이 문서와 의미상 밀접하게 일치함을 뜻합니다. 어휘적 점수는 BM25 알고리즘으로 계산되며, 이 알고리즘은 공유된 각 단어에 레이블 세트 전체에서의 역문서 빈도(inverse document frequency)에 따른 가중치를 부여합니다. 따라서 수천 개의 레이블에 등장하는 "use"와 같은 일반적인 동사는 낮은 가중치를 받는 반면, "ETL"과 같은 희귀한 토큰은 높은 가중치를 받습니다.

각 검색 방법은 자체적으로 순위가 매겨진 레이블 목록을 반환합니다. 저희는 각 목록에서의 위치에 따라 각 레이블의 점수를 매기는 상호 순위 융합(Reciprocal Rank Fusion)을 사용하여 두 목록을 병합합니다. 상위 k개를 선택하고, k를 1, 5, 10, 20, 50, 100, 200으로 스윕(sweep)하여 가장 좋은 평균 정확도를 보이는 값을 찾은 다음, 가장 높은 순위의 레이블을 예측값으로 사용합니다.

수십만 개의 레이블 규모에서는 분류 체계를 한 번 임베딩하고 인메모리 인덱스를 구축하는 것이 호스팅된 벡터 검색 인덱스를 생성하는 것보다 비용 효율적입니다. Qwen3-8B 4096차원 float32 임베딩을 가정할 때 10만 개의 레이블을 임베딩하는 데 약 1.6 GB의 스토리지가 사용되며, Databricks AI Query 함수를 사용하면 임베딩하는 데 약 1~3분이 소요됩니다. 그런 다음 워크로드 시작 시 메모리에 벡터 검색 인스턴스를 생성하고, 저장된 임베딩을 가져온 후, 워크로드가 실행되는 동안 모든 문서에 이 인덱스를 사용합니다. 이 튜토리얼 노트북에서 벡터 검색 구현을 위한 예제 코드를 확인할 수 있습니다.

방법 2: 벡터 검색 + AI Classify

두 번째로 테스트한 방법은 벡터 검색 접근 방식과 Databricks AI Classify 함수를 결합한 2단계 워크플로우입니다. AI Classify는 문서와 레이블-설명 매핑 정보를 입력받아 가장 잘 일치하는 레이블 또는 레이블 세트를 반환하는 Databricks AI 함수입니다. AI Classify 함수는 분류 품질을 유지하면서 대규모 문서와 분류 체계를 관리하기 위해 다양한 기술을 조합하여 사용합니다.

AI Classify 함수는 다음과 같이 SQL로 실행할 수 있습니다:

방법 1에서 설명한 것과 동일한 벡터 검색을 사용하여 문서당 가장 유사한 k개의 레이블을 후보군(shortlist)으로 압축한 다음, 이 후보군만 AI Classify에 전달하는 2단계 워크플로우를 만듭니다. 정확도 향상이 멈추는 가장 작은 값으로 k를 조정하고, AI Classify의 결과를 예측값으로 채택합니다.

방법 3: 프론티어 모델 직접 호출

마지막으로 테스트한 방법은 프론티어 LLM을 직접 호출하여 입력 문서와 레이블 목록(설명이 있는 경우 설명 포함)을 전달한 다음, 모델이 올바른 레이블을 반환하도록 유도하는 것입니다. 테스트에 사용된 모델은 GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash, Claude Sonnet 5로, 고객의 일반적인 프로덕션 분류 예산 범위 내에서 활용할 수 있는 최신 모델들입니다. Claude Opus 4.8, Claude Fable 5, GPT-5.6 Sol과 같은 플래그십 모델은 토큰당 비용이 3~10배 더 많이 들기 때문에, 매일 수천 개의 문서를 분류하는 워크플로우를 실행하는 고객에게는 대개 예산을 초과하게 됩니다.

분류 체계가 모델의 컨텍스트 길이를 초과하는 경우, 컨텍스트 창에 맞게 레이블 목록을 잘라냅니다. 프롬프트 캐싱을 활용하기 위해 각 문서에 대한 호출 전반에 걸쳐 분류 체계를 일관되게 전달합니다.

평가 방법

위에서 언급한 가장 일반적인 고객 사용 사례를 다루는 세 가지 데이터 세트에서 각 방법을 벤치마킹합니다. 별도의 언급이 없는 한 레이블은 설명과 함께 임베딩됩니다:

• Transactions (레이블 10만 개, 평가 문서 200개): Crunchbase의 상위 10만 개 기업 이름을 기반으로 합성 생성된 거래 문자열입니다.
• Companies (레이블 10만 개, 평가 문서 200개): Transactions와 동일한 Crunchbase 기업 이름 카탈로그에 매핑된 기업 설명입니다. 레이블은 이름으로만 구성됩니다.
• MedMentions (35k개 레이블, 200개 평가 문서): MedMentions 말뭉치(corpus)의 Unified Medical Language System 개념 식별자에 연결되는 생의학적 언급(mention) 링크입니다.

각 데이터 세트는 정확도(예측된 레이블이 실제 정답(ground truth) 레이블과 일치하는 문서의 비율)를 기준으로 점수가 매겨집니다. 모든 직접적인 프런티어 모델 호출에 대해 모델 제공업체의 프롬프트 캐싱 옵션을 활성화합니다.

결과

각 접근 방식에 대해 3개 데이터 세트의 평균을 낸 문서당 비용 대비 정확도를 그래프로 나타냅니다. 비용에는 문서 임베딩과 제공업체 프롬프트 캐싱 할인이 적용된 LLM 토큰이 포함됩니다. 워크로드 크기에 따라 확장되지 않는 일회성 비용인 분류 체계(taxonomy) 임베딩은 제외합니다("대규모 레이블 분류에 접근하는 방법"에서 벡터 검색 구성에 대한 스토리지 추정치 참조).

모든 데이터 세트에서 AI Classify Workflow는 문서당 비용이 100분의 1에 불과하면서도 평균 정확도 0.81을 기록하여, 차선책인 Gemini 3.5 Flash의 0.76에 비해 모든 직접 프런티어 모델보다 높은 점수를 받았습니다. AI Classify Workflow의 품질은 평균적으로 벡터 검색에서 상위 20개 레이블을 후보로 선정하여 AI Classify 함수에 전달할 때 가장 높습니다.

벡터 검색만 사용하는 것은 문서만 임베딩하면 되고 순위 지정의 CPU 비용이 미미하기 때문에 AI Classify Workflow보다 거의 100배 더 저렴합니다. 하지만 k를 튜닝한 후에도 AI Classify Workflow보다 20점 이상 낮은 점수를 기록했습니다.

가장 큰 분류 체계의 경우, 직접 프런티어 호출은 모델의 컨텍스트 창에 전체 레이블 세트를 맞출 수 없습니다. MedMentions에서는 GPT-5.6 Luna만이 1M 토큰 컨텍스트 내에 전체 분류 체계를 수용할 수 있었으며, 토큰화 이후에는 다른 어떤 모델도 제한 범위 내에 레이블 세트를 맞출 수 없었습니다. 이 시점에서 팀은 컨텍스트를 관리하기 위해 배치, 다단계 및 에이전트(agentic) 전략을 평가하도록 선택할 수 있으며, 이는 저희 팀이 구축하고 AI Classify 함수에서 계속 개선하고 있는 기능입니다.

결론

35,000개에서 100,000개 레이블에 이르는 3가지 벤치마크에서 벡터 검색과 Databricks AI Classify 함수를 결합한 AI Classify 워크플로가 비용과 품질의 가장 좋은 균형을 보여주었습니다. 가장 강력한 직접 프런티어 모델인 Gemini 3.5 Flash보다 약 100분의 1의 문서당 비용으로 5점 더 높은 점수를 기록했습니다. 분류 체계가 변경되면 재학습이나 재배포 없이 워크플로 시작 시 사용되지 않는 레이블을 제거하고 새 레이블을 임베딩 및 수집(ingest)할 수 있습니다.

이러한 규모의 분류 작업에 직면한 팀에게는 AI Classify 및 벡터 검색을 사용하여 워크플로를 만드는 것이 좋은 출발점입니다. 이 단계별 튜토리얼에서는 레이블 세트 임베딩부터 K 선택에 이르기까지 Databricks에서의 전체 워크플로를 안내합니다.

AI Classify 워크플로 사용해 보기

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)