离线阶段把知识库“整理好”，在线阶段把用户问题“查准、排好、拼稳、答得有依据”。RAG 的难点不在“把向量库接上”，而在每一步是否能持续稳定地把正确证据送到模型面前。
一、为什么不能只说“检索 + 生成”？
很多人第一次理解 RAG，会把它简化成两步：用户提问，系统去知识库里查几段资料，再把资料交给大模型回答。这个理解没错，但只停留在最粗的轮廓。
真正的在线 RAG 链路要处理的问题要复杂得多：用户的问题可能口语化、带指代、带上下文；向量检索可能召回相似但无答案的片段；关键词检索能命中专有名词但不懂语义；Rerank 能提纯结果但会增加延迟；Prompt 拼得不好，大模型依然可能脱离资料乱答。
所以，一个成熟的 RAG 在线流程，通常不是“检索 -> 生成”两步，而是“改写 -> 向量化 -> 多路召回 -> 融合 -> 精排 -> 组装 -> 生成 -> 溯源 -> 评估”的工程链路。
二、完整在线流程总览
当用户输入一个问题后，系统最好不要马上把原问题送进向量库。更稳妥的做法是先把问题变成“适合检索”的形式，再通过多种召回方式找候选证据，然后用精排模型筛掉噪音，最后把证据、问题和约束指令组装成 Prompt，交给大模型生成带引用的答案。
Query 预处理：补全上下文、消除指代、改写成独立检索句。
Query Embedding：用和建库一致的 Embedding 模型把问题转成向量。
多路召回：向量检索、BM25、元数据过滤等多通道并行找候选片段。
结果融合：用 RRF 等方式把不同通道的排名合成统一候选集。
Rerank 精排：用 Cross-Encoder 或 reranker 模型重新打分，保留最有用证据。
Prompt 组装：按证据编号、Token 预算、拒答规则、引用格式构造输入。
答案生成与溯源：基于证据作答，并给出来源引用，必要时做后处理校验。
三、第一步：Query 预处理，让问题变得“可检索”
用户输入的原始问题，往往不是一个干净的检索句。比如“上次那个方案有没有风险”“这个怎么收费”“为啥又扣钱了”，人能看懂，是因为人有上下文和常识；但向量库只看到一串文本，它不知道“那个”“这个”“又”指的是什么。
Query Rewrite 的目标不是润色文字，而是提高检索命中率。常见做法包括：
独立问题改写：把多轮对话里的省略和指代补全，让问题脱离上下文也能理解。
HyDE：让模型先生成一段“假设答案”，再用假设答案去检索，因为答案和真实资料的表达往往更接近。
多角度扩写：把同一个问题改写成多个表述，分别检索后合并结果，提高召回覆盖面。
意图拆分：如果用户同时问“查资料 + 写回复 + 生成方案”，应拆成多个子任务，不要用一个 Query 硬搜。
注意：Query Rewrite 不是越多越好。改写过度可能改变用户原意，所以工程上常保留原始 Query，并记录 rewrite_version，方便回放和评估。
代码示例：一个简单的 Query Rewrite 约束模板
rewrite_prompt=f""" 你是 RAG 检索问题改写器。 请把用户问题改写成适合知识库检索的独立问题。 要求：1. 不改变用户原意；2. 补全多轮对话里的指代；3. 保留产品名、版本号、时间、地区等关键约束；4. 如果问题已经清楚，直接原样返回；5. 输出 JSON，不要输出解释。 对话上下文：{chat_history}用户问题：{user_query}输出格式：{{"rewritten_query":"...","need_rewrite":true,"reason":"..."}}"""四、第二步：Query Embedding，必须和建库模型保持一致
Query 改写完成后，需要把文本转成向量，然后才能去向量数据库里做相似度搜索。这里最容易踩的坑是：在线查询用的 Embedding 模型，必须和离线建库时用的 Embedding 模型一致。
原因很简单：不同模型的向量维度、训练目标、向量空间分布都不同。用模型 A 建库，再用模型 B 查询，就像拿两套不同坐标系算距离，结果没有意义。换 Embedding 模型，通常意味着需要重建索引。
五、第三步：多路召回，向量检索和关键词检索各有分工
很多线上 RAG 系统不会只做向量检索。向量检索擅长找语义相近的内容，比如“退款”和“退费”；但它对产品型号、订单号、错误码、专有名词、精确短语不一定稳定。BM25 或全文检索正好能弥补这一点。
典型的多路召回包括三类：
向量检索：捕获语义相似，适合问法多变、同义表达丰富的场景。
BM25 / 全文检索：捕获精确词、术语、编号、产品名、代码符号。
元数据过滤：按权限、租户、产品线、版本、时间范围、文档状态先过滤候选范围。
RRF 融合：为什么不能直接把分数相加？
向量检索的分数可能是 cosine similarity，BM25 的分数是另一套统计分数，两个分数没有天然可比性。RRF（Reciprocal Rank Fusion）不直接比较分数，而是比较“排名位置”：一个片段如果在多个通道里都排得靠前，它最终得分就更高。
from collectionsimportdefaultdict def rrf_fusion(result_lists,k=60):""" result_lists: 多个召回通道的结果列表，例如：[[doc_a, doc_b, doc_c],[doc_b, doc_d, doc_a]]返回：按 RRF 得分排序后的文档""" scores=defaultdict(float)forresultsinresult_lists:forrank, doc_idinenumerate(results,start=1): scores[doc_id]+=1.0/(k + rank)returnsorted(scores.items(),key=lambda x: x[1],reverse=True)六、第四步：Rerank 精排，从“召回一堆”到“只留可用证据”
多路召回解决的是“不要漏掉可能相关的片段”，但召回越多，噪音也越多。Rerank 的作用，就是对候选片段重新排序，把真正能回答问题的片段排到前面。
常见做法是两阶段：先用向量检索和 BM25 快速召回 Top-20 到 Top-50，再用 Rerank 模型对这些候选进行深度匹配，最终只保留 Top-3 到 Top-5 进入 Prompt。
Rerank 的关键价值是“降噪”。它不是替代召回，而是补上召回之后的质量控制。没有 Rerank，Top-K 里混入噪音，模型就可能被错误片段带偏。
七、第五步：Prompt 组装，让模型基于证据回答
精排后的片段不能简单拼在一起就丢给模型。Prompt 组装要同时考虑四件事：证据顺序、Token 预算、引用格式和拒答规则。
一个可用的 RAG Prompt，至少应该明确告诉模型：只能基于资料回答；资料不足时要拒答；关键结论要带引用；不要把参考资料里没有的信息编出来。
def build_rag_prompt(question, contexts): evidence=[]fori, ctxinenumerate(contexts,start=1): evidence.append(f"[{i}] 来源：{ctx['source']} "f"片段：{ctx['text']}")returnf""" 你是一个严谨的知识库问答助手。 请只根据【参考资料】回答用户问题。 如果资料不足，请回答“根据现有资料无法回答”。 关键结论后面必须标注引用编号，例如[1][2]。 【参考资料】{chr(10).join(evidence)}【用户问题】{question}【回答】""".strip()八、第六步：生成答案与溯源，可信度来自可回查
大模型拿到 Prompt 后，基于参考资料生成答案。到这里，用户看到了结果，但工程上还没结束。真正可上线的 RAG 系统，最好能让用户看到答案来自哪篇文档、哪个 chunk、哪一页、哪一段。
溯源有三个好处：第一，用户可以验证答案；第二，运营和研发可以定位错误；第三，当模型误读资料时，可以通过源文档快速判断问题出在检索、Prompt 还是生成。
九、在线 RAG 的延迟优化：不要只盯向量库
在线链路里，向量检索通常不是最慢的环节。真正影响用户体感的，往往是 Rerank 和大模型生成。工程上可以通过缓存、并行召回、精排限流和流式生成降低等待感。
缓存高频 Query 的改写结果、召回结果和最终答案。
向量检索和 BM25 并行执行，避免串行叠加延迟。
Rerank 限制候选数量，超过阈值先粗筛。
生成阶段使用流式返回，让用户尽快看到首 token。
对低置信度检索结果直接拒答或转人工，而不是强行生成。
十、常见失败点：RAG 调优要先定位环节
RAG 出错时，不能一上来就换模型。你需要先判断问题出在哪一段：是不是 Query 改写改错了？是不是召回没找回来？是不是 Rerank 把正确片段排掉了？是不是 Prompt 太长、噪音太多？还是生成阶段没有遵守引用约束？
十一、生产级在线架构：可观测、可回放、可评测
如果只是 Demo，把所有逻辑写在一个 Python 函数里也能跑。但生产环境需要把每一层拆清楚：入口层、Query 层、检索层、排序层、生成层和治理层。每次请求都要有 query_id，每个 chunk 都要有 chunk_id / doc_id，每个阶段都要记录耗时和分数。
建议至少记录这些字段：
query_id：一次问答请求的唯一编号，用于链路追踪。
raw_query / rewritten_query：保留原问题和改写结果，方便回放。
retrieval_results：各召回通道的候选片段、分数、排名。
rerank_scores：精排得分和最终入 Prompt 的片段。
prompt_tokens / completion_tokens：评估成本和延迟。
citations：答案中的引用与 chunk_id 的映射关系。
十二、如何评估在线流程：拆开看，不只看答案
评估 RAG 不应该只看最终答案像不像。更有效的方法是组件级评估：召回阶段看有没有找回答案片段，排序阶段看正确片段是否排在前面，生成阶段看是否忠于证据。
一套实用的离线评测集，最好包含“用户问题、标准答案、标准证据片段”。这样你每次调整改写、召回、Rerank、Chunk 粒度时，都能用同一批问题做回归测试，而不是凭感觉判断效果。
十三、面试回答模板
如果面试官问：“用户输入一个问题后，RAG 系统是怎样工作的？”可以这样回答：
我会把 RAG 在线流程拆成六步。第一步做 Query 预处理，把口语化、多轮指代问题改写成独立检索句；第二步用和建库一致的 Embedding 模型把 Query 向量化；第三步做多路召回，通常会并行跑向量检索、BM25 和元数据过滤；第四步用 Rerank 精排，从候选片段里筛出最有用的 Top-N；第五步把证据、引用编号、拒答规则和用户问题组装成 Prompt；第六步由大模型基于证据生成答案，并标注来源，方便用户回查。线上还会记录每一步耗时、召回结果、精排分数和引用映射，用于评估和排障。
