> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 基于LLM的检索和推荐
- URL: https://www.hubwiz.com/blog/llm-powered-retrieval-and-recommendation/
- Published: 2025-12-06T22:27:33.000Z
- Updated: 2025-12-06T22:27:33.000Z
- Description: 在过去的一年里，我一直探索如何将LLM用作检索和推荐代理，并整理了这篇博客文章作为该主题的简单介绍。
- Author: admin
- Tags: APPLICATION, LLM, #Import 2026-10-14 14:41

在过去的一年里，我一直探索如何将LLM用作**检索和推荐代理**，并整理了这篇博客文章作为该主题的简单介绍。我的目标是保持清晰易懂，因此即使你没有技术背景，也不必担心——这篇文章也是为你而写的。

我努力以最简单的方式解释核心概念，使用来自不同研究论文的直观例子。

## 1、什么是检索以及为什么它很重要？

检索是从大型集合中找到并返回最相关项的过程，给定一个查询。这个集合可以是互联网上的所有网页、图书馆中的书籍，或者在线商店中的产品。

例子无处不在：Google会在你的搜索查询后从数十亿页中显示相关URL，YouTube和Spotify会从庞大的目录中为你提取你可能喜欢的视频或歌曲，而Amazon或Instacart会返回与你输入的搜索栏或今天可能购买的内容最匹配的产品。

检索是**搜索和推荐**引擎的第一阶段。检索引擎通常返回几十或几百个物品，这些物品是从数百万甚至数十亿个产品中选出的，然后排序器决定最终呈现给用户的顺序。

当用户搜索某样东西时，相关物品会被检索出来，然后进行排序再显示。在推荐系统中，搜索不会显式发生，但过程是相同的：基于用户的过去历史，我们检索与用户最相关的物品，然后排序器对检索结果进行排序。

## 2、检索方法的简要回顾（LLM之前）

传统上，检索引擎主要依赖于**关键词匹配**或**向量相似性**。

**稀疏检索（基于关键词，深度学习时代之前）：**

- **示例：** BM25, TF-IDF
- **工作原理：** 找到与查询共享最多单词的文档。
- **优点：** 非常快速，不需要训练，而且易于解释。
- **缺点：** 缺乏语义理解，难以处理同义词。
- **示例：** 例如，如果你搜索“如何制作可颂”，系统可能会完全错过一个名为“在家制作糕点”的文档——尽管可颂是一种糕点。这是因为查询和标题不共享任何单词。

**密集检索（基于向量，深度学习）：**

- **示例：** DPR, ANCE, ColBERT
- **工作原理：** 神经编码器将查询和文档嵌入到同一向量空间中，通过相似性搜索进行检索。如图2所示，通常有两个塔（编码器）。一个塔学习查询的嵌入，另一个塔学习文档的嵌入，使得相关对具有更高的点积分数。
- **优点：** 超过精确关键词的语义意义；更好地处理同义词和改写。
- **缺点：** 需要为每个文档存储密集向量，这会消耗大量的内存。此外，如果你更新编码器（塔），你需要重新构建整个索引，这成本很高。此外，随着查询和文档变长，基于嵌入的检索系统的性能往往会下降。

![](https://www.hubwiz.com/blog/content/images/2025/12/image-68.png)

图2\. 一个两塔密集检索架构的例子

## 3、生成式信息检索

新方法是**生成式信息检索（GenIR）**。不再依赖关键词或向量相似性，而是直接使用LLM生成相关项目的标题或标识符（DocIDs）。想法很简单：将用户查询或资料（购买历史、过去互动等）输入模型，然后指示它输出最相关的前k个项目。在访问完整项目语料库的情况下，LLM可以直接检索最相关的项目。

### 3.1 LLM作为推荐代理

![](https://www.hubwiz.com/blog/content/images/2025/12/image-69.png)

图3\. 使用LLM作为推荐者的不同方式

在推荐系统中，总是在检索之后有一个或多个**排序步骤**。使用LLM时也是如此。在推荐系统中使用LLM有几种方式：

- **LLM用于检索 + 单独的排序器：** LLM检索候选项目，而单独的排序器（也可以是LLM）根据相关性对它们进行排序。
- **LLM用于检索和排序：** 一个单一的LLM检索项目并直接对其进行排序，统一两个步骤。这种端到端的方法是新兴的研究趋势，旨在简化推荐流程。

使用LLM进行项目推荐的一个例子如图4所示，用户的过去购买历史被作为列表提供给LLM，然后模型被要求预测下一个项目。这样，**LLM直接输出最可能购买的下一个产品**。为了使模型更熟悉完整的项目目录，微调步骤通常是很有帮助的。

![](https://www.hubwiz.com/blog/content/images/2025/12/image-70.png)

图4\. 一个基于LLM的推荐代理的示例提示，根据用户的购买历史建议产品

### 3.2 语义ID vs 标题

除了生成完整的文档或产品标题，LLM还可以使用**语义ID**进行检索。这些是由数字（或标记）组合而成的结构化标识符，其中序列的每一部分编码项目的特定属性。

例如，一个包含3个数字的产品目录的DocID：

- 第一个数字可能表示类别（鞋子），
- 第二个表示品牌（Nike），
- 第三个表示颜色（橙色）。

这些ID不是随机分配的——它们通常由项目语义嵌入（例如，从预训练文本编码器如Sentence-BERT或T5）量化而来。诸如 [Residual Quantized Variational Autoencoders (RQ-VAE)](https://arxiv.org/abs/2203.01941?ref=hubwiz.com) 或产品量化的方法将每个项目的嵌入映射到离散代码的元组，形成其语义ID。

这种分层结构使语义ID紧凑、一致，并且比长自由文本标题更容易让模型生成。然而，要有效地使用它们，LLM通常需要在预训练期间或通过后续监督微调来学习这些ID，以便它了解查询与正确ID序列之间的映射。

![](https://www.hubwiz.com/blog/content/images/2025/12/image-71.png)

*图5.*

语义ID有一个**注意事项**：目录中的新项目必须首先分配ID，除非模型被更新或用这些ID进行微调，否则它可能无法检索它们。相比之下，标题更具灵活性，因为LLM通常可以推广到未见过的文本。

### 3.3 处理大型项目语料库和幻觉

为了让LLM输出我们语料库中的项目，它要么需要在训练期间看到它们，要么我们必须在提示中提供完整的列表。

如果需要微调，这意味着我们不能直接使用LLM——我们需要在自己的数据上对其进行训练，这需要额外的努力。即使跳过微调，仍然存在上下文限制的问题。一些模型现在支持百万token提示，但将整个目录塞入上下文并不实际。即使这样做，模型仍可能产生幻觉并输出不存在的项目。

解决方案是**受限解码（Constrained Decoding）**。通过在每个生成步骤中限制输出空间，我们可以确保模型只能生成对应真实项目标题（或DocIDs）的有效序列。一种常见的方法是使用一个**前缀树（trie）**，建立在目录上。例如，在鞋店目录中，树确保模型只生成有效的商品标题，如“Nike跑步鞋”或“Adidas凉鞋”，而不是随机或虚构的名称。

可以把受限解码想象成**把模型放在轨道上**：它可以沿着不同的方向前进，但只能沿着你已经铺设的轨道前进。

![](https://www.hubwiz.com/blog/content/images/2025/12/image-72.png)

图6\. 建立在鞋店目录上的前缀树示例。为了简化起见，我们在这里考虑每个词作为一个token。

### 3.4 综合起来

总之，我们可以向LLM提供用户的查询和/或资料，并让它仅从受限输出空间中生成有效的项目标题。这样，检索保持高效，并且牢固地扎根于实际目录中。

此外，许多研究工作表明，**进一步微调LLM**可以显著提升性能。这通常涉及创建（查询，相关项目）的训练对，并应用监督微调，使模型更可靠地学习检索行为。

是的，但是：

- **并不总是替代品：** 这样想：如果你只是输入“多伦多今天的天气”，传统的搜索引擎就足够了。但如果你写了一个较长、复杂的请求，比如“给我看看一些适合家庭活动的两天多伦多旅行地点，靠近湖泊”，这就是GenIR真正发挥作用的地方。
- **模型大小很重要：** 更大的模型，如GPT-5，通常可以在复杂任务上击败传统的检索和推荐系统。但较小的模型——比如一个1B参数的LLaMA——不会自动优于经过良好调整的传统方法。
- **微调有帮助：** 在查询-文档对上进行训练可以显著提高检索准确性。**实用技巧：** 使用强大的LLM（在你的评估中表现良好的）生成标签，然后将知识蒸馏到一个更小、更便宜的模型中用于生产。

## 4、思考

将LLM用作检索和推荐引擎仍然是一个新兴且快速增长的研究领域，但已经显示出强劲的结果。例如，Bevilacqua等人开发的SEAL生成检索器在各种KILT任务中优于许多双编码器基线，而Rajput等人开发的TIGER框架在Amazon Beauty数据集上的NDCG@5上实现了高达29%的提升。

几家主要公司——包括**Netflix、Google**和**Meta**——正在积极探索生成检索和统一检索-排序方法。最近的研究（如本文提到的研究）表明，这些方法通常优于其他检索和推荐系统，同时在处理复杂查询和推荐任务方面更加灵活。

我们还处于这一转变的早期阶段，但很明显，检索正从关键词和嵌入转向LLM驱动的生成。我们在研究中看到的想法现在正在生产环境中进行测试，这使现在成为你开始尝试GenIR的最佳时机。

---

原文链接：[LLMs as Retrieval and Recommendation Engines — Part 1](https://medium.com/@moeinh77/llms-as-retrieval-and-recommendation-engines-part-1-43ceecb8e79b?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处