文档 / RAG

检索增强生成(Retrieval-Augmented Generation, RAG)

RAG 是一种让语言模型获得训练时未见过的知识的方法——而无需重新训练模型。

Embeddings Vector Search Semantic Retrieval
在 Sandbox 中实时运行

什么是 RAG?

检索增强生成的字面意思正是如此:我们不再仅仅依赖模型的内部知识,而是首先从外部知识库中检索 与用户问题相关的文档,然后将这些文档作为附加上下文与原始问题一起提供给模型,使其能够基于这些内容 生成答案。

为什么需要 RAG?

  • 减少幻觉 — 答案基于真实文档,而不仅仅是模型的参数化记忆
  • 知识保持最新 — 无需重新微调,只需将新文档添加到知识库即可
  • 专有知识 — 通用模型可以回答有关你组织私有数据(它在通用训练中从未见过)的问题
  • 可溯源 — 你可以展示每个答案的确切来源

RAG 管道

Documents Chunking + Embedding Vector DB User Query Query Embedding Semantic Search Relevant Docs Top-K LLM Final Answer

分块与嵌入(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 对产品目录进行语义搜索——这正是 UCPsearch_offers 能力背后所做的事情。