别做分类，让LLM去“幻觉”
Don't classify, hallucinate!
用LLM做产品分类早已是老生常谈，但强制模型输出符合系统规范的法律词汇往往成本高昂且受限。与其费力构建庞大的结构化输出Schema，不如换个思路：让廉价的“笨”模型自由发挥，为查询生成看似荒谬的“幻觉”分类。例如，面对“棕色咖啡桌”的查询，让模型编造出“Furniture / Living Room / Tables / Coffee”这样的假路径。随后，利用MiniLM等嵌入模型，将这些虚构路径与真实的Wayfair分类体系进行向量匹配，即可精准定位到标准类别。这种方法不仅避开了API的上下文限制，还能在大规模场景下显著降低推理成本，让分类任务变得既便宜又高效。
与其费力约束LLM的输出，不如让它去发明一些看似荒谬却合理的虚构分类，再通过向量匹配将其映射回真实的词汇体系。
- pu_pe
这招挺妙。不过，你为什么不把查询语句嵌入（embed），然后跟各类别的嵌入向量做对比，再把跟查询最接近的类别放进提示词里，交给一个小模型处理呢？
- Majromax
> 在 Notebook 里，我计算了每个真实 Wayfair 分类的 MiniLM 嵌入向量。接着，我计算了 LLM 生成的那个虚构的、假设性的嵌入向量。然后，我把这个虚构嵌入向量和真实嵌入向量做点积，找出最相似的那个。结果：[正确答案]
这难道不是在预设“幻觉”出来的分类会比查询语句本身更贴合真实架构吗？<E(搜索查询), E(架构)> 的点积结果会是什么？
即便这太模糊，小模型也能胜任重排序（reranker）的工作：返回前 N 个匹配的真实类别，然后让模型进行上下文排序。
- amitpoonia19xyz
这基本上就是 HyDE（Hypothetical Document Embeddings，假设文档嵌入）吧？我之前试过这种方法，效果有限。
- ipsod
就在这个星期，我尝试用类似的方法整理一个充满糟糕“氛围代码”（vibe-coded）的代码库。我用 Gemini Flash 3.6 以类似的方式对每个函数/方法进行分类，为每个方法生成几个合理的分类（每个方法一个 Agent）。
结果发现用处不大——我做了个对比，直接让一个大一点的 Agent 用更直接的方式来做整理，效果反而更好。
不过，我发现 Flash 3.6 High 在这个任务上比 Luna xhigh 快 9 倍以上，而且结果非常相似。
- piterrro
我建议这样做：基于查询在向量库中检索 10 个最接近的类别，把它们喂给 LLM，在提示词里让它输出一个 0-9 的单个数字，代表最合适的选择编号。用纯文本提示，别用 JSON 去增加 token 数量。
搞定，你这就大幅降低了输出成本。
另外，你也可以尝试用重排序模型（reranker）替代 LLM，或者在重排序后取前 3 个结果再喂给 LLM，以此来降低输入 token 成本。