Simon Willison的博客攒了1,856个标签,多到没法一次性喂给大模型去做"从这堆标签里选一个"的匹配题。这不是个例,任何标签体系做大了都会撞上同一堵墙:候选项一多,要么超出上下文窗口,要么模型选得心不在焉。工程师Doug Turnbull给出的解法有点反直觉——不是想办法把标签表塞进prompt,而是干脆让模型别管真实标签库长什么样,先自己瞎编一个像样的分类,编完再拿向量检索去现实世界里捞最接近的那个。
具体怎么做
Turnbull的prompt里只给了分类格式的示例,比如"家具/客厅家具/茶几",却完全不提供真实标签清单。模型看到一句查询,比如"brown coffee table",就凭着格式感自己编一条听起来合理的分类路径。这条编出来的路径本身没用,但可以拿去做向量嵌入,和语料库里已有的1,856个真实标签逐一比相似度,取最近的几个当结果。
这套路数,学术圈早有先例
模型"幻觉"在这里居然成了优点,原因不复杂:分类的本质不是精确匹配,是语义相似度打分,那就没必要死磕关键词对齐。检索增强生成(RAG)领域有个已经被反复验证的方法叫HyDE——先让模型编一份假想答案文档,再拿这份编造的文本去做嵌入检索,而不是直接检索用户那句短查询。逻辑几乎是一回事:用生成能力造一个语义锚点,再靠向量相似度做软匹配。
不完全一样的地方也得说清楚:HyDE解决的是查询太短、语义信息不够,检索效果差;Turnbull要解决的是候选标签太多,塞不进context窗口。起点问题不同,用的却是同一招——先生成,再检索,不再指望模型直接对着候选列表做选择题。这不算原创发明,更像是把一个成熟思路搬到了新场景里重新用了一遍。
巧妙归巧妙,账还没人算过
问题在于,这篇博客给出的只是一个点子和一段示例prompt,没有任何效果数据。准确率多少、召回率多少、和"直接把标签表分块喂给模型"比谁更好,一概没有。检索了一圈公开信息,也没找到任何第三方跑过的实验或生产案例——这事目前只存在于工程师的博客和直觉里。
- 风险.模型编的分类如果和语料库里的真实概念差得太远,向量检索会捞回一堆不相干的标签,长尾、专业领域尤其容易出这种偏差。
还有一笔没算的账:给整个语料库做embedding、维护一套向量索引,本身也要花计算和存储成本。这笔成本和直接把标签表分块喂给模型比,谁更划算,Turnbull没给答案,Willison转发时也没追问。
让模型胡说,前提是有人替它兜底核对——这个兜底,眼下全靠猜。
谁用得上,接下来看什么
这招对标签体系庞大到没法一次塞进prompt的场景最有吸引力:个人博客的自由标签系统、电商平台的多级类目树、企业知识库和RAG系统的元数据标注,都是潜在用户。Turnbull自己举的例子就是家具电商品类,场景很具体。
值得盯着的,是接下来会不会有人拿真实语料跑一组对比实验,把"先幻觉再检索"和"分块喂标签表"放在同一个数据集上比准确率。没有这组数字之前,这个技巧还只是一个漂亮的假设,不是一套可以放心上生产的方案。