Escalar la clasificación de documentos a más de 100 000 etiquetas

En Databricks, miles de clientes crean cargas de trabajo de producción que asignan texto libre a taxonomías normalizadas de más de 100 000 etiquetas. Algunos casos de uso comunes incluyen:

• Vinculación de entidades biomédicas. Las notas clínicas y los artículos de investigación mencionan enfermedades, medicamentos y procedimientos que deben asociarse con un concepto en el Unified Medical Language System, un vocabulario con miles de identificadores de conceptos biomédicos.
• Normalización de proveedores. Para analizar los patrones de gasto, las empresas financieras normalizan cadenas de transacciones sin procesar como "SBUX #4471 SEATTLE WA" frente a un conjunto de más de 100 000 comerciantes.
• Normalización de empresas. Las empresas desduplican los registros de clientes en diferentes sistemas internos al hacer coincidir las descripciones de las empresas con un conjunto de más de 100 000 empresas.

Cada de estos casos de uso define un gran conjunto de etiquetas, también llamado taxonomía, y cada entrada debe asignarse a una o más de sus etiquetas. Por lo general, los clientes evalúan su solución de producción en función de estos criterios:

1. Calidad: Producir clasificaciones que sean lo suficientemente precisas como para guiar las decisiones posteriores.
2. Costo: Mantener bajo el costo de clasificación por documento, especialmente a escala.
3. Rendimiento: Procesar grandes flujos de trabajo, a menudo del orden de cientos de miles de documentos, en un plazo de tiempo razonable.

Cumplir con estos tres requisitos dificulta la clasificación de taxonomías grandes en producción, y en Databricks priorizamos la investigación y la creación de soluciones para ellos.

Por qué los enfoques existentes se quedan cortos

Históricamente, las organizaciones abordaban la clasificación de taxonomías grandes recurriendo a reglas regex personalizadas, coincidencia de palabras clave y clasificadores de aprendizaje automático supervisado. Sin embargo, estos enfoques se quedan cortos en varios aspectos:

Coincidencia de patrones frágil. Las reglas de regex y palabras clave dependen de coincidencias exactas, por lo que fallan ante formatos impredecibles de datos de la vida real. Empresas como YipitData necesitaban actualizar continuamente sus patrones de regex para abordar casos extremos y cambios en la taxonomía, los cuales son difíciles de mantener a una escala de miles de etiquetas.

Verdad fundamental dispersa y sesgada. Las distribuciones de etiquetas reales son de cola larga: un puñado de etiquetas cubre la mayoría de los documentos, mientras que miles aparecen rara vez. La mayoría de los clientes carecen de documentos de verdad fundamental para cada etiqueta de su taxonomía, lo que dificulta el entrenamiento de los clasificadores supervisados. Un clasificador no puede aprender a clasificar etiquetas que no están incluidas en los datos de entrenamiento, y el desequilibrio de clases hace que los clasificadores predigan en exceso las etiquetas representadas habitualmente y no predigan lo suficiente las etiquetas poco comunes.

Deriva de la taxonomía. Las etiquetas y sus descripciones se agregan, retiran y reescriben constantemente para responder a nuevos casos de uso empresarial y mejorar la calidad de la clasificación. Con cada nueva versión de la taxonomía, es necesario actualizar los patrones de regex, así como volver a entrenar e implementar los clasificadores.

Recientemente, hemos visto que más clientes utilizan modelos de lenguaje grande (LLM) para la clasificación. Con los LLM, los clientes ya no necesitan entrenar modelos ni mantener patrones de regex frágiles. Sin embargo, a una escala de cientos de miles de etiquetas, los LLM tienen dificultades para adaptarse y razonar sobre la taxonomía dentro de su ventana de contexto. Con miles de candidatos en un solo prompt, los modelos también comienzan a alucinar, devolviendo etiquetas que ni siquiera existen en la taxonomía. Pasar toda la taxonomía de cientos de miles de documentos a un modelo de frontera también es costoso a escala, incluso cuando se aprovecha el almacenamiento en caché de prompts.

Cómo abordamos la clasificación con un gran número de etiquetas

Evaluamos tres métodos diferentes para encontrar el mejor equilibrio entre costo y calidad para taxonomías grandes:

Método 1: Búsqueda vectorial

El primer método que probamos consiste en utilizar la búsqueda vectorial para recuperar la mejor etiqueta dada la entrada. Generamos incrustaciones para cada etiqueta, con su descripción cuando está presente, y para el documento de entrada utilizando el modelo Qwen3-Embedding-8B, un modelo de incrustación de pesos abiertos de primer nivel a fecha de julio de 2026. A continuación, evaluamos la relevancia de cada etiqueta con respecto al documento mediante una puntuación híbrida que pondera la similitud tanto semántica como léxica.

La puntuación semántica se determina calculando la similitud del coseno entre las incrustaciones del documento y de la etiqueta; una mayor similitud del coseno significa que la etiqueta coincide estrechamente con el documento en cuanto a significado, incluso si el texto no coincide exactamente. La puntuación léxica se calcula con el algoritmo BM25, que pondera cada término compartido por su frecuencia inversa de documento en todo el conjunto de etiquetas, de modo que un verbo genérico como "use" que aparece en miles de etiquetas recibe un peso bajo, mientras que un token poco común como "ETL" recibe uno alto.

Cada método de búsqueda devuelve su propia lista clasificada de etiquetas. Fusionamos las dos listas con Reciprocal Rank Fusion, que puntúa cada etiqueta según su posición en cada lista. Tomamos las mejores k, variando k entre 1, 5, 10, 20, 50, 100 y 200 para encontrar el valor con la mejor precisión promedio, y utilizamos la etiqueta mejor clasificada como predicción.

A una escala de cientos de miles de etiquetas, generar las incrustaciones de la taxonomía una sola vez y crear un índice en memoria es más rentable que crear un índice de búsqueda vectorial alojado. La incrustación de 100 000 etiquetas utiliza aproximadamente 1.6 GB de almacenamiento, asumiendo incrustaciones float32 de 4096 dimensiones de Qwen3-8B, y tarda aproximadamente de 1 a 3 minutos en generarse utilizando la función AI Query de Databricks. Luego, al inicio de una carga de trabajo, creamos una instancia de búsqueda vectorial en memoria, ingerimos las incrustaciones persistidas y utilizamos el índice para todos los documentos durante la carga de trabajo. Puede encontrar código de ejemplo para nuestra implementación de búsqueda vectorial en este cuaderno de tutoriales.

Método 2: Búsqueda vectorial + AI Classify

El segundo método que probamos es un flujo de trabajo de dos pasos que combina el enfoque de búsqueda vectorial y la función AI Classify de Databricks. AI Classify es una función de IA de Databricks que toma un documento y un mapa de etiquetas con sus descripciones, y devuelve la etiqueta o el conjunto de etiquetas que mejor coinciden. La función AI Classify utiliza una combinación de técnicas para gestionar documentos y taxonomías de gran tamaño, manteniendo al mismo tiempo la calidad de la clasificación.

La función AI Classify se puede ejecutar con SQL de la siguiente manera:

Creamos un flujo de trabajo de dos pasos utilizando la misma recuperación de búsqueda vectorial descrita en el método 1 para preseleccionar las k etiquetas más similares por documento, y luego pasamos únicamente esa lista de preselección a AI Classify. Ajustamos k al valor más pequeño en el que la precisión deja de mejorar y tomamos el resultado de AI Classify como predicción.

Método 3: Llamada directa al modelo de frontera

El último método que probamos llama directamente a un LLM de frontera con el documento de entrada y la lista de etiquetas, incluidas las descripciones cuando están presentes, y luego le pide al modelo que devuelva la etiqueta correcta. Los modelos probados son GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash y Claude Sonnet 5, los últimos modelos al alcance de los presupuestos de clasificación de producción habituales de nuestros clientes. Los modelos insignia como Claude Opus 4.8, Claude Fable 5 y GPT-5.6 Sol cuestan de tres a diez veces más por token y, por lo general, están fuera del presupuesto de los clientes que ejecutan flujos de trabajo de clasificación con miles de documentos al día.

Cuando la taxonomía supera la longitud de contexto de un modelo, recortamos la lista de etiquetas para que quepa en la ventana de contexto. Pasamos la taxonomía de manera uniforme en todas las llamadas de cada documento para aprovechar el almacenamiento en caché de prompts.

Cómo evaluamos

Evaluamos el rendimiento de cada método en tres conjuntos de datos que cubren los casos de uso más comunes de los clientes mencionados anteriormente. Se generan incrustaciones para las etiquetas junto con sus descripciones, a menos que se indique lo contrario:

• Transacciones (100 000 etiquetas, 200 documentos de evaluación): cadenas de transacciones generadas sintéticamente basadas en los nombres de las 100 000 empresas principales de Crunchbase.
• Empresas (100 000 etiquetas, 200 documentos de evaluación): descripciones de empresas asignadas al mismo catálogo de nombres de empresas de Crunchbase que Transacciones. Las etiquetas son únicamente nombres.
• MedMentions (35 000 etiquetas, 200 documentos de evaluación): vinculación de menciones biomédicas a identificadores de conceptos del Unified Medical Language System del corpus MedMentions.

Cada conjunto de datos se evalúa según su exactitud: la proporción de documentos cuya etiqueta predicha coincide con la etiqueta real (ground truth). Habilitamos la opción de almacenamiento en caché de prompts del proveedor del modelo para todas las llamadas directas a modelos de frontera.

Resultados

Representamos gráficamente la exactitud frente al costo por documento, promediado entre los tres conjuntos de datos, para cada enfoque. El costo incluye el embedding del documento y los tokens de LLM con los descuentos de almacenamiento en caché de prompts del proveedor aplicados. Excluimos el embedding de taxonomía, un costo único que no escala con el tamaño de la carga de trabajo (consulte las estimaciones de almacenamiento para nuestra configuración de búsqueda vectorial en "Cómo abordamos la clasificación de etiquetas grandes").

En todos los conjuntos de datos, el flujo de trabajo AI Classify obtiene una puntuación superior a la de cualquier modelo de frontera directo, con una exactitud promedio de 0.81 frente a 0.76 de la siguiente mejor opción, Gemini 3.5 Flash, a una centésima parte del costo por documento. La calidad del flujo de trabajo AI Classify, en promedio, es óptima cuando seleccionamos las veinte mejores etiquetas de la búsqueda vectorial para pasarlas a la función AI Classify.

La búsqueda vectorial por sí sola es casi cien veces más barata que el flujo de trabajo AI Classify, ya que solo es necesario generar el embedding del documento y el costo de CPU de la clasificación es insignificante. Sin embargo, incluso después de ajustar k, su puntuación se sitúa más de veinte puntos por debajo del flujo de trabajo AI Classify.

Para las taxonomías más grandes, la llamada directa al modelo de frontera no puede albergar el conjunto completo de etiquetas en la ventana de contexto del modelo. En MedMentions, solo GPT-5.6 Luna mantuvo la taxonomía completa dentro de su contexto de 1M de tokens; después de la tokenización, ningún otro modelo pudo albergar el conjunto de etiquetas dentro de su límite. En este punto, los equipos pueden optar por evaluar estrategias por lotes (batch), de varios pasos y de agentes para gestionar el contexto, capacidades que nuestro equipo ha desarrollado y sigue perfeccionando en la función AI Classify.

Conclusión

En tres pruebas de rendimiento (benchmarks) que abarcan de 35 000 a 100 000 etiquetas, el flujo de trabajo AI Classify, que combina la búsqueda vectorial y la función AI Classify de Databricks, ofreció el mejor equilibrio entre costo y calidad. Supera al modelo de frontera directo más sólido, Gemini 3.5 Flash, por cinco puntos a aproximadamente una centésima parte del costo por documento. Cuando la taxonomía cambia, las etiquetas retiradas se pueden eliminar y las nuevas etiquetas se pueden generar como embeddings e ingestar al inicio del flujo de trabajo, sin necesidad de reentrenamiento ni de volver a realizar el despliegue.

Para los equipos que se enfrentan a la clasificación a esta escala, crear un flujo de trabajo con AI Classify y búsqueda vectorial es un excelente punto de partida. Este tutorial paso a paso recorre todo el flujo de trabajo en Databricks, desde la generación de embeddings del conjunto de etiquetas hasta la selección de K.

Probar el flujo de trabajo AI Classify

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original