检索增强生成(Retrieval-Augmented Generation, RAG)
RAG 是一种让语言模型获得训练时未见过的知识的方法——而无需重新训练模型。
Embeddings
Vector Search
Semantic Retrieval
在 Sandbox 中实时运行
什么是 RAG?
检索增强生成的字面意思正是如此:我们不再仅仅依赖模型的内部知识,而是首先从外部知识库中检索 与用户问题相关的文档,然后将这些文档作为附加上下文与原始问题一起提供给模型,使其能够基于这些内容 生成答案。
为什么需要 RAG?
- 减少幻觉 — 答案基于真实文档,而不仅仅是模型的参数化记忆
- 知识保持最新 — 无需重新微调,只需将新文档添加到知识库即可
- 专有知识 — 通用模型可以回答有关你组织私有数据(它在通用训练中从未见过)的问题
- 可溯源 — 你可以展示每个答案的确切来源
RAG 管道
分块与嵌入(Chunking & Embedding)
大型文档首先会被拆分成更小的片段(Chunk),使每个片段足够聚焦,并能容纳进上下文窗口中。 随后,每个片段通过一个嵌入(Embedding)模型转换为一个数值向量(语义表示);含义相近的文本,其向量也彼此接近。
向量数据库(Vector DB)
这些向量存储在一个针对"最近邻搜索"(Nearest Neighbor Search)进行了优化的向量数据库中。 一旦用户的查询也被转换为向量,数据库便可以在数百万份文档中,于几毫秒内找到最接近的匹配项。
混合搜索(Hybrid Search)与重排序
单纯的向量搜索并不总是最佳选择:对于诸如型号名称或产品代码(例如 SKU-4471)这样的精确词语,
传统的关键词搜索(BM25)通常比语义搜索更精确,因为向量是针对"概念相似性"而非精确匹配进行优化的。
- 混合搜索(Hybrid Search) — 同时获取向量搜索和关键词搜索的结果,并通过一个加权公式将两者结合;这种组合通常比单独使用任何一种方式都能提高准确性。
- 重排序(Re-ranking) — 一个可选的第二阶段:在初步检索出 N 个结果(例如 50 篇文档)之后,一个更小、更精确的模型(Cross-Encoder)会对这些结果重新打分,以确保只有排名最靠前的 K 个结果(例如 4 篇文档)真正被提供给主语言模型。这一步比向量搜索更慢,因此它只在缩小后的集合上运行,而不是整个数据库。
代码示例:一个简单的管道
def answer_with_rag(question, vector_db, llm):
query_vector = embed(question)
top_chunks = vector_db.similarity_search(query_vector, k=4)
context = "\n\n".join(chunk.text for chunk in top_chunks)
prompt = f"请根据以下文本回答问题:\n\n{context}\n\n问题:{question}"
return llm.generate(prompt)
局限性
- 答案质量完全依赖于检索质量;如果找不到相关文档,模型要么猜测,要么给出错误答案
- 简单的 RAG 每次只执行一次搜索;对于多步骤问题并不够用——这正是 Agentic RAG 诞生的原因
常见问题
RAG 会取代微调(Fine-tuning)吗?
通常不是取代,而是互补。RAG 非常适合"新鲜且易变"的知识;而微调更适合改变模型的风格或行为。
RAG 与代理型商务有什么关系?
购物智能体可以使用 RAG 对产品目录进行语义搜索——这正是 UCP 中 search_offers 能力背后所做的事情。