RAG 检索完整流程解析：从 Query 预处理到 LLM 生成答案

RAG 检索完整流程解析从 Query 预处理到 LLM 生成答案RAG 检索整体流程RAGRetrieval-Augmented Generation检索增强生成的核心思想是在大语言模型生成答案之前先从外部知识库中检索相关信息再让 LLM 基于这些资料生成答案。一个完整的 RAG 在线检索流程如下整个过程可以分为理解用户问题将问题转换为可搜索向量从知识库快速召回候选内容对候选内容重新排序构建 LLM 上下文生成最终答案第一阶段Query 预处理Query Processing1. 为什么需要 Query 预处理用户输入的问题通常不是一个适合检索的 Query。例如用户那个登录问题怎么解决这个问题存在缺少上下文口语化严重关键词不足直接搜索那个登录问题怎么解决很难找到准确资料。因此在进入检索前需要先对 Query 进行处理。2. Query 预处理主要方法Query 预处理主要包含Query Rewrite查询改写HyDE假设文档嵌入Query Expansion查询扩展指代消解(1) Query Rewrite查询改写Query Rewrite 的目标将用户的问题转换成更适合搜索的表达。例如用户Go里面P是什么改写Go GMP调度模型中的P(Processer)有什么作用改写后的 Query包含专业术语语义更加明确更容易匹配知识库流程用户问题 ↓ LLM分析 ↓ 生成优化Query ↓ 进入检索(2) 指代消解在多轮对话中用户经常使用它这个那个上面的刚才那个例如对话用户 Go中的channel是什么 AI channel用于goroutine之间通信。 用户 它为什么会阻塞其中它 channel需要转换Go channel为什么会阻塞否则它为什么会阻塞无法进行有效检索。实现方式结合Conversation History LLM Rewrite生成完整 Query。(3) HyDEHypothetical Document EmbeddingsHyDE 的核心思想不直接搜索用户问题而是让 LLM 先生成一个假设答案再使用这个答案进行检索。普通方式用户问题 ↓ Embedding ↓ 向量搜索HyDE例如用户什么是GMP中的PLLM生成GMP中的P表示Processor 负责管理goroutine执行和调度资源。然后使用这个答案生成向量。优势因为假设答案包含更多专业词GMP Processor goroutine scheduler所以更容易匹配知识库。缺点如果生成答案错误会影响检索方向。(4) Query Expansion查询扩展一个问题可能有多种表达方式。例如用户Go如何实现任务队列扩展Go worker pool实现 goroutine任务调度 channel任务队列 生产者消费者模型然后多个 Query 一起检索。目的提高召回率。第二阶段Query Embedding向量化经过 Query 处理后需要将文本转换成向量。因为计算机无法直接理解Go GMP中的P是什么需要通过 Embedding 模型文本 ↓ Embedding模型 ↓ 向量例如Go GMP中的P ↓ [0.124, 0.532, 0.821, ...]这个向量代表文本的语义信息。之后使用这个向量和知识库中的向量计算相似度。第三阶段向量检索 BM25 多路召回Retrieval这一阶段目标快速找到可能相关的候选文档。通常采用1. Dense Retrieval向量检索基于 Embedding。例如用户Go调度里面P有什么作用数据库GMP模型中的Processor负责调度goroutine虽然关键词不同作用 负责但是语义相似。2. Sparse RetrievalBM25BM25 是关键词检索算法。例如搜索0x80072f78BM25 可以精准匹配错误码。优势适合专业名词API名称错误码产品编号为什么需要 Hybrid Retrieval单独使用一种方式都有缺点。向量检索优点理解语义缺点专有名词可能不准BM25优点精确匹配关键词缺点不理解语义所以生产环境通常例如用户docker错误0x80072f78BM25找到错误码0x80072f78向量找到Docker网络连接失败原因两者结合效果更好。第四阶段Rerank 精排为什么需要 Rerank理解了第三步的粗排召回你会发现一个自然的问题Top-20 的结果里不可能条条都相关肯定混了一些干扰项进去。Rerank 就是为了解决这个问题的。向量检索是「粗排」召回的 Top-K比如 20 条里可能混入相关度不高的干扰片段。Rerank 模型Cross-Encoder 结构会把用户问题和每个候选片段拼在一起输入深度理解它们之间的语义匹配程度重新打分排序。最终只保留 Top-3 到 Top-5 的高质量片段把噪音过滤掉。你可能会问为什么不直接用 Rerank 模型来检索还要先粗排再精排因为 Rerank 是 Cross-Encoder结构需要把查询和每个候选拼在一起过模型计算量比向量检索大得多。如果拿它对百万条数据逐一算分延迟完全不可接受。所以工程上采用「粗排筛到几十条精排再从几十条里挑最好的几条」这种两阶段策略兼顾速度和质量。Rerank 整体耗时通常在几百毫秒以内对用户体感影响不大但检索质量的提升非常明显。第五阶段Prompt 拼接Prompt Assembly经过 Rerank 后得到最相关的几个chunk然后构建 Prompt。例如promptf 你是一个专业助手请根据以下参考资料回答用户的问题。 如果参考资料中没有相关信息请回答「根据现有资料无法回答」不要自行猜测。 参考资料 [1]{chunk_1}[2]{chunk_2}[3]{chunk_3}用户问题{user_query}这个过程就是 Context Building。第六阶段LLM生成答案 溯源最后LLM 根据用户问题 检索资料 系统提示词生成答案。流程Prompt ↓ LLM ↓ 回答 引用来源例如回答Go GMP模型中的P表示Processor 负责连接M和G并管理goroutine运行。 来源Go scheduler文档十、完整耗时分析根据图片中的数据阶段耗时Query预处理100~300msQuery Embedding20~50ms检索召回50~150msRerank100~200msPrompt拼接10~30msLLM生成2~10s可以看到真正耗时最大的通常不是检索而是LLM生成阶段十二、总结RAG 检索并不是简单的用户问题 ↓ Embedding ↓ 向量数据库一个完整的 RAG 检索系统Query预处理 ↓ Embedding向量化 ↓ Hybrid Retrieval召回 ↓ Rerank精排 ↓ Prompt构建 ↓ LLM生成答案其中模块作用Query Rewrite让问题更适合搜索HyDE利用假设答案增强语义Query Expansion提高召回范围Embedding文本向量化BM25关键词匹配Vector Search语义匹配Rerank提高准确率Prompt Assembly提供上下文LLM生成最终答案这就是现代 RAG 系统中一次完整的在线检索流程。