RAG 处理流程
下面是处理流程图
关键问题解释(嵌入模型不一致):
-
知识库编码阶段:
- 文档块使用
嵌入模型A
编码后存入向量数据库 - 例如:
text-embedding-ada-002
或bge-small
- 文档块使用
-
查询阶段:
- 用户Query可能被
问答模型的嵌入模块B
编码(如GPT的tokenizer) - 这时会出现嵌入空间不一致问题 → 检索质量下降
- 用户Query可能被
解决方案:
各模型职责说明:
组件 | 作用 | 典型模型示例 |
---|---|---|
嵌入模型 | 将文本转换为向量 | text-embedding-ada-002, bge-base |
检索器 | 计算向量相似度 | FAISS, Annoy |
重排序模型 | 精细化结果排序 | cohere-rerank, bge-reranker |
问答模型 | 生成最终答案 | GPT-4, LLaMA-2 |
处理时机总结:
- 预处理阶段:知识库文档 → 嵌入模型 → 向量存储
- 查询阶段:
- 用户输入 → (可选)独立嵌入模型 → 检索
- 原始结果 → (可选)重排序模型 → 精排
- 排序后文档 + 问题 → 问答模型 → 生成答案
这种设计下,确保检索和生成阶段使用兼容的嵌入表示是关键,通常建议知识库编码和查询编码使用同款嵌入模型。
在RAG(Retrieval-Augmented Generation)流程中,问答模型生成答案时的输入是原始文本形式的用户问题(Query)和检索到的文档片段(原始文本)
问答模型的输入组成(文本形式):
-
用户原始问题:
- 直接保留用户输入的文本(例如:“量子纠缠的原理是什么?”)。
-
检索到的文档片段:
- 从向量数据库返回的是原始文本段落(如:“量子纠缠是指…<知识库原文>”),而不是向量。
- 向量仅用于检索阶段,检索完成后即丢弃,后续不参与生成。
-
可能的模板格式化:
- 通常会将问题和文档组合成提示词(Prompt),例如:
请根据以下信息回答问题: 文档1: <检索结果1的文本> 文档2: <检索结果2的文本> 问题: <用户原始问题>
- 通常会将问题和文档组合成提示词(Prompt),例如:
完整流程对比(检索阶段 vs. 生成阶段):
关键点总结:
- 向量只用一次:仅在检索阶段计算相似度,之后丢弃。
- 问答模型的输入是纯文本:包括原始Query和检索到的文档文本。
- 两类模型完全解耦:
- 嵌入模型:负责检索阶段的向量表示(独立训练)。
- 问答模型:负责文本生成(如GPT系列),不关心检索用的向量。
类比解释:
- 检索阶段:像用ISBN号(向量)在图书馆找书,找到后ISBN就没用了。
- 生成阶段:直接阅读书中的文本内容(原始文本)来回答问题。