夜雨聆风编辑：浮世Talk
在 Databricks，成千上万的客户构建生产工作负载，把自由文本映射到 10 万+ 标签的归一化分类法。几个常见用例包括：
生物医学实体链接。 临床病历和研究论文里提到的疾病、药物和操作，必须匹配到统一医学语言系统（UMLS）中的某个概念——那是一个包含数千个生物医学概念标识符的词表。 供应商归一化。 为了分析支出模式，金融公司会把 "SBUX #4471 SEATTLE WA"这样的原始交易字符串，对齐到一个 10 万+ 商户的集合上。公司归一化。 企业跨不同内部系统去重客户记录，把公司描述匹配到一个 10 万+ 公司的集合。
每个用例都定义了一大套标签，也叫「分类法（taxonomy）」，每条输入都要映射到其中一个或多个标签。客户通常从这几个维度评估他们的生产方案：
质量： 产出足够准确、能驱动下游决策的分类结果。 成本： 保持每篇文档的分类成本低，尤其在规模化时。 吞吐： 在合理时间内处理大型工作流，量级往往在数十万篇文档。
同时满足这三点，正是大型分类法分类的难处所在，我们也把研究和构建这类解法作为 Databricks 的优先事项。
为什么现有方法都不够用
历史上，组织处理大型分类法分类靠的是自定义正则规则、关键词匹配和有监督机器学习分类器。然而这些方法在几个维度上都有短板：
脆弱的模式匹配。 正则和关键词规则依赖精确匹配，因此在真实数据不可预测的格式面前很容易崩。像 YipitData 这样的公司需要不断更新正则模式来应对边缘情况和分类法变更，而在数千标签的规模下这很难维护。
稀疏且偏斜的标注真值。 真实标签分布是长尾的：少数标签覆盖了大部分文档，而数千个标签极少出现。大多数客户并没有覆盖分类法中每个标签的真值文档，这让有监督分类器难以训练。分类器学不会「训练数据里没有的标签」，而类别不平衡又会导致分类器过度预测常见标签、欠预测稀有标签。
分类法漂移。 为了适配新业务用例、提升分类质量，标签及其描述不断被新增、退役和改写。每出一个新分类法版本，正则模式就要更新、分类器就要重训并重新部署。
近来，我们看到越来越多客户用大语言模型（LLM）做分类。有了 LLM，客户不再需要训练模型或维护脆弱的正则。然而在数十万标签的规模下，LLM 很难把整个分类法塞进上下文窗口并对其进行推理。当单条 prompt 里塞进数千个候选时，模型还会开始幻觉，返回根本不存在于分类法里的标签。而把整个分类法为数十万篇文档反复传给前沿模型，即便利用了 prompt 缓存，在规模化时依然昂贵。
我们如何处理大标签分类
我们评估了三种不同方法，来为大型分类法找到成本与质量的最佳平衡。
方法一：向量检索
我们测试的第一种方法，是用向量检索为输入召回最佳标签。我们用 Qwen3-Embedding-8B 模型（截至 2026 年 7 月排名靠前的开源权重嵌入模型）把每个标签（连同其描述，若有）和输入文档都嵌入。然后用一个同时权衡语义与词法相似度的混合分数，给每个标签对文档的相关性打分。
语义分数由文档嵌入与标签嵌入的余弦相似度计算得出；余弦相似度越高，意味着标签在含义上与文档越贴近，哪怕文字并不完全一致。词法分数用 BM25 算法计算，它按每个共享词项在标签集合中的逆文档频率来加权——所以像 "use" 这种出现在数千标签里的通用动词权重很低，而 "ETL" 这种稀有词元权重很高。
每种检索方法各返回自己的一份有序标签列表。我们用 Reciprocal Rank Fusion（倒数排名融合）合并这两份列表，按每个标签在各列表中的位置为其打分。我们取前 k（k 在 1、5、10、20、50、100、200 上扫描）以找到平均准确率最好的取值，并用排名第一的标签作为预测。
在数十万标签的规模下，把分类法嵌入一次并构建内存索引，比创建一个托管的向量检索索引更划算。嵌入 10 万标签大约占用 1.6 GB 存储（按 Qwen3-8B 4096 维 float32 嵌入估算），用 Databricks AI Query 函数嵌入大约需 1–3 分钟。然后在工作负载开始时，我们在内存中创建一个向量检索实例，摄入这些已持久化的嵌入，并在整个工作负载期间用这个索引服务所有文档。你可以在这个教程 notebook 里找到我们向量检索实现的示例代码。
方法二：向量检索 + AI Classify
我们测试的第二种方法，是把向量检索方法与 Databricks 的 AI Classify 函数结合成一个两步工作流。AI Classify 是一个 Databricks AI 函数，它接收一篇文档和一份「标签→描述」的映射，返回最匹配的标签或标签集合。AI Classify 函数用一组技术手段来处理大文档和大分类法，同时保持分类质量。
AI Classify 函数可以用 SQL 这样调用：
SELECT ai_classify(
'Spins up isolated Postgres instances in under 500ms with separated compute and storage.',
'{
"Neon": "Serverless Postgres for developers and AI agents",
"Panther": "AI SOC platform for threat detection and SIEM workflows"
}'
) AS prediction;
我们构建一个两步工作流：用方法一里描述的同一套向量检索，为每篇文档挑出最相似的 k 个标签短名单，然后只把这份短名单传给 AI Classify。我们把 k 调到「准确率不再提升」的最小值，并把 AI Classify 的结果作为预测。
方法三：直接调用前沿模型
最后一种方法，直接用输入文档和标签列表（含描述，若有）调用一个前沿 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 这类旗舰模型，每 token 成本要贵三到十倍，通常超出「每天跑数千篇文档分类工作流」的客户预算。
当分类法超出模型的上下文长度时，我们裁剪标签列表以塞进上下文窗口。我们在每篇文档的多次调用间保持传入一致的分类法，以利用 prompt 缓存。
我们如何评测
我们在三个数据集上对每种方法做基准测试，它们覆盖了上文提到的最常见客户用例。除非特别说明，标签均连同其描述一起嵌入：
Transactions（10 万标签，200 篇评测文档）： 基于 Crunchbase 前 10 万公司名合成生成的交易字符串。 Companies（10 万标签，200 篇评测文档）： 公司描述映射到与 Transactions 相同的 Crunchbase 公司名目录。标签仅为名称。 MedMentions（3.5 万标签，200 篇评测文档）： 来自 MedMentions 语料的生物医学提及链接到 UMLS 概念标识符。
每个数据集都按准确率评分：预测标签与真值标签匹配的文档占比。对所有直接前沿模型调用，我们都启用了模型供应商的 prompt 缓存选项。
结果
我们把准确率对每篇文档成本作图（在三个数据集上取平均）。成本包含文档嵌入和 LLM token（已应用供应商 prompt 缓存折扣）。我们排除了分类法嵌入这一「不随工作负载规模变化的一次性成本」。
在所有数据集上，AI Classify 工作流的得分都高于任何一个直接前沿模型：平均准确率 0.81，对比次优选项 Gemini 3.5 Flash 的 0.76，而每篇文档成本只有其百分之一。平均而言，当我们从向量检索里挑出前 20 个标签短名单传给 AI Classify 函数时，AI Classify 工作流的质量最佳。
仅用向量检索比 AI Classify 工作流还便宜近百倍，因为只需嵌入文档，排序的 CPU 成本可忽略不计。然而即便调好了 k，它的得分仍比 AI Classify 工作流低 20 多个点。
对于最大的分类法，直接前沿调用无法把完整标签集塞进模型的上下文窗口。在 MedMentions 上，只有 GPT-5.6 Luna 靠其 100 万 token 上下文装下了整个分类法；分词之后，没有别的模型能把标签集塞进各自的上限。到了这一步，团队可以选择评估批处理、多步和 agentic 策略来管理上下文——这些正是我们团队已经构建并持续打磨进 AI Classify 函数的能力。
结论
在覆盖 3.5 万到 10 万标签的三个基准上，把向量检索与 Databricks AI Classify 函数结合的 AI Classify 工作流，给出了成本与质量的最佳平衡。它以约百分之一的每篇文档成本，超过了最强的直接前沿模型 Gemini 3.5 Flash 达 5 个点。当分类法变化时，退役的标签可以移除、新标签可以在工作流开始时嵌入并摄入，无需重训或重新部署。
对于面对这种规模分类的团队，用 AI Classify 加向量检索搭一个工作流是个很好的起点。这份分步教程会带你在 Databricks 上走完整个工作流，从嵌入标签集到选择 k。
