Escalar a classificação de documentos para mais de 100 mil rótulos

No Databricks, milhares de clientes criam cargas de trabalho de produção que mapeiam textos livres para taxonomias normalizadas de mais de 100 mil rótulos. Alguns casos de uso comuns incluem:

• Vinculação de entidades biomédicas. Prontuários clínicos e artigos de pesquisa mencionam doenças, medicamentos e procedimentos que devem ser correspondidos a um conceito no Unified Medical Language System, um vocabulário com milhares de identificadores de conceitos biomédicos.
• Normalização de fornecedores. Para analisar padrões de gastos, as empresas financeiras normalizam strings de transações brutas como "SBUX #4471 SEATTLE WA" em relação a um conjunto de mais de 100 mil comerciantes.
• Normalização de empresas. As empresas deduplicam registros de clientes em diferentes sistemas internos ao corresponder descrições de empresas a um conjunto de mais de 100 mil empresas.

Cada um desses casos de uso define um grande conjunto de rótulos, também chamado de taxonomia, e cada entrada deve ser mapeada para um ou mais de seus rótulos. Geralmente, os clientes avaliam suas soluções de produção com base nestes critérios:

1. Qualidade: Gerar classificações precisas o suficiente para direcionar decisões subsequentes.
2. Custo: Manter o custo de classificação por documento baixo, especialmente em escala.
3. Vazão: Processar grandes fluxos de trabalho, geralmente na ordem de centenas de milhares de documentos, dentro de um prazo razoável.

Atender a todos os três requisitos torna difícil a classificação de grandes taxonomias em produção, e priorizamos a pesquisa e a criação de soluções para isso no Databricks.

Por que as abordagens existentes não são suficientes

Historicamente, as organizações abordavam a classificação de grandes taxonomias dependendo de regras regex personalizadas, correspondência de palavras-chave e classificadores supervisionados de aprendizado de máquina. No entanto, essas abordagens deixam a desejar em alguns aspectos:

Correspondência de padrões frágil. As regras de regex e palavras-chave dependem de correspondências exatas, por isso falham com formatações imprevisíveis de dados reais. Empresas como a YipitData precisavam atualizar continuamente seus padrões de regex para lidar com casos extremos e mudanças de taxonomia, que são difíceis de manter na escala de milhares de rótulos.

Dados de referência (ground truth) esparsos e distorcidos. As distribuições reais de rótulos têm cauda longa: um pequeno grupo de rótulos cobre a maioria dos documentos, enquanto milhares aparecem raramente. A maioria dos clientes não tem documentos de referência (ground truth) para cada rótulo em sua taxonomia, o que dificulta o treinamento de classificadores supervisionados. Um classificador não consegue aprender a classificar rótulos que não estão incluídos nos dados de treinamento, e o desequilíbrio de classes faz com que os classificadores superestimem os rótulos frequentemente representados e subestimem os rótulos raros.

Desvio de taxonomia. Rótulos e suas descrições são constantemente adicionados, descontinuados e reescritos para atender a novos casos de uso de negócios e melhorar a qualidade da classificação. A cada nova versão da taxonomia, os padrões de regex precisam ser atualizados e os classificadores precisam ser retreinados e implantados.

Recentemente, vimos mais clientes usarem grandes modelos de linguagem (LLMs) para classificação. Com as LLMs, os clientes não precisam mais treinar modelos ou manter padrões de regex frágeis. No entanto, na escala de centenas de milhares de rótulos, as LLMs têm dificuldade para acomodar e raciocinar sobre a taxonomia dentro de sua janela de contexto. Com milhares de candidatos em um único prompt, os modelos também começam a alucinar, retornando rótulos que sequer existem na taxonomia. Enviar toda a taxonomia de centenas de milhares de documentos para um modelo de fronteira também é caro em escala, mesmo aproveitando o cache de prompt.

Como abordamos a classificação com muitos rótulos

Avaliamos três métodos diferentes para encontrar o melhor equilíbrio entre custo e qualidade para grandes taxonomias:

Método 1: Busca vetorial

O primeiro método que testamos usa busca vetorial para recuperar o melhor rótulo com base na entrada. Geramos embeddings para cada rótulo, com sua descrição quando presente, e para o documento de entrada usando o modelo Qwen3-Embedding-8B, um modelo de embedding de pesos abertos de ponta em julho de 2026. Em seguida, pontuamos a relevância de cada rótulo para o documento com uma pontuação híbrida que pondera a similaridade semântica e lexical.

A pontuação semântica é determinada pelo cálculo da similaridade de cosseno entre os embeddings do documento e do rótulo; uma similaridade de cosseno mais alta significa que o rótulo corresponde de perto ao significado do documento, mesmo que o texto não seja idêntico. A pontuação lexical é calculada com o algoritmo BM25, que pondera cada termo compartilhado por sua frequência inversa de documento em todo o conjunto de rótulos. Assim, um verbo genérico como "use" que ocorre em milhares de rótulos recebe um peso baixo, enquanto um token raro como "ETL" recebe um peso alto.

Cada método de busca retorna sua própria lista classificada de rótulos. Mesclamos as duas listas com Reciprocal Rank Fusion, que pontua cada rótulo por sua posição em cada lista. Selecionamos os top k, variando k entre 1, 5, 10, 20, 50, 100 e 200 para encontrar o valor com a melhor precisão média, e usamos o rótulo mais bem classificado como a previsão.

Na escala de centenas de milhares de rótulos, gerar os embeddings da taxonomia uma vez e criar um índice em memória é mais econômico do que criar um índice de busca vetorial hospedado. Gerar embeddings para 100 mil rótulos consome cerca de 1,6 GB de armazenamento, assumindo embeddings float32 de 4096 dimensões do Qwen3-8B, e leva aproximadamente de 1 a 3 minutos usando a função Databricks AI Query. Em seguida, no início de uma carga de trabalho, criamos uma instância de busca vetorial em memória, ingerimos os embeddings persistidos e usamos o índice para todos os documentos durante a execução da carga de trabalho. Você pode encontrar um exemplo de código para nossa implementação de busca vetorial neste notebook de tutorial.

Método 2: Busca vetorial + AI Classify

O segundo método que testamos é um fluxo de trabalho de duas etapas que combina a abordagem de busca vetorial e a função Databricks AI Classify. A AI Classify é uma função de IA do Databricks que recebe um documento e um mapeamento de rótulos para descrições e retorna o rótulo ou conjunto de rótulos com a melhor correspondência. A função AI Classify usa uma combinação de técnicas para gerenciar grandes documentos e taxonomias, mantendo a qualidade da classificação.

A função AI Classify pode ser executada com SQL da seguinte forma:

Criamos um fluxo de trabalho de duas etapas usando a mesma recuperação de busca vetorial descrita no método 1 para selecionar os k rótulos mais semelhantes por documento e, em seguida, passamos apenas essa lista de finalistas para a AI Classify. Ajustamos k para o menor valor onde a precisão para de melhorar e usamos o resultado da AI Classify como a previsão.

Método 3: Chamada direta de modelo de fronteira

O último método que testamos chama uma LLM de fronteira diretamente com o documento de entrada e a lista de rótulos, incluindo descrições quando presentes, e solicita que o modelo retorne o rótulo correto. Os modelos testados são GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash e Claude Sonnet 5 — os modelos mais recentes ao alcance dos orçamentos típicos de classificação de produção de nossos clientes. Modelos de ponta como Claude Opus 4.8, Claude Fable 5 e GPT-5.6 Sol custam de três a dez vezes mais por token e geralmente estão fora do orçamento de clientes que executam fluxos de trabalho de classificação com milhares de documentos por dia.

Quando a taxonomia excede o comprimento de contexto de um modelo, cortamos a lista de rótulos para caber na janela de contexto. Passamos a taxonomia de forma consistente entre as chamadas para cada documento para aproveitar o cache de prompt.

Como avaliamos

Avaliamos cada método em três conjuntos de dados que cobrem os casos de uso mais comuns dos clientes mencionados acima. Os embeddings dos rótulos são gerados com suas descrições, a menos que indicado o contrário:

• Transações (100 mil rótulos, 200 documentos de avaliação): strings de transações geradas sinteticamente com base nos 100 mil principais nomes de empresas do Crunchbase.
• Empresas (100 mil rótulos, 200 documentos de avaliação): descrições de empresas mapeadas para o mesmo catálogo de nomes de empresas do Crunchbase que as Transações. Os rótulos são apenas nomes.
• MedMentions (35 mil rótulos, 200 documentos de avaliação): vinculação de menções biomédicas a identificadores de conceitos do Unified Medical Language System do corpus MedMentions.

Cada conjunto de dados é avaliado pela acurácia: a fração de documentos cujo rótulo previsto corresponde ao rótulo de referência (ground truth). Ativamos a opção de cache de prompt do provedor de modelo para todas as chamadas diretas de modelos de fronteira.

Resultados

Traçamos a acurácia em relação ao custo por documento, calculando a média dos três conjuntos de dados para cada abordagem. O custo inclui o embedding do documento e os tokens de LLM com os descontos de cache de prompt do provedor aplicados. Excluímos o embedding de taxonomia, um custo único que não escala com o tamanho da carga de trabalho (consulte as estimativas de armazenamento para nossa configuração de busca vetorial em "Como abordamos a classificação de rótulos grandes").

Em todos os conjuntos de dados, o AI Classify Workflow pontua acima de qualquer modelo de fronteira direto, com uma acurácia média de 0,81 contra 0,76 da próxima melhor opção, o Gemini 3.5 Flash, a um centésimo do custo por documento. A qualidade do AI Classify Workflow, em média, é melhor quando selecionamos os vinte principais rótulos da busca vetorial para passar para a função AI Classify.

A busca vetorial por si só é quase cem vezes mais barata que o AI Classify Workflow, pois apenas o documento precisa de embedding e o custo de CPU para o ranqueamento é insignificante. No entanto, mesmo após ajustar o k, ela pontua mais de vinte pontos abaixo do AI Classify Workflow.

Para as maiores taxonomias, a chamada direta ao modelo de fronteira não consegue acomodar todo o conjunto de rótulos na janela de contexto do modelo. No MedMentions, apenas o GPT-5.6 Luna manteve toda a taxonomia dentro de seu contexto de 1 milhão de tokens; após a tokenização, nenhum outro modelo conseguiu ajustar o conjunto de rótulos dentro de seu limite. Nesse ponto, as equipes podem optar por avaliar estratégias em lote, de várias etapas e de agentes para gerenciar o contexto — recursos que nossa equipe desenvolveu e continua a aprimorar na função AI Classify.

Conclusão

Em três benchmarks que abrangem de 35.000 a 100.000 rótulos, o fluxo de trabalho AI Classify, que combina busca vetorial e a função Databricks AI Classify, ofereceu o melhor equilíbrio entre custo e qualidade. Ele supera o modelo de fronteira direto mais forte, o Gemini 3.5 Flash, em cinco pontos, a aproximadamente um centésimo do custo por documento. Quando a taxonomia muda, os rótulos obsoletos podem ser removidos e novos rótulos podem ter seus embeddings gerados e ser ingeridos no início do fluxo de trabalho, sem necessidade de retreinamento ou nova implantação.

Para equipes que enfrentam classificação nessa escala, criar um fluxo de trabalho com o AI Classify e a busca vetorial é um excelente ponto de partida. Este tutorial passo a passo orienta você por todo o fluxo de trabalho no Databricks, desde a geração de embeddings do conjunto de rótulos até a seleção de K.

Experimente o AI Classify Workflow

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original