第14题RAG 的数据处理流程是什么一句话回答RAGRetrieval-Augmented Generation检索增强生成的完整数据流程可以分成四部分离线数据准备 → 在线检索与生成 → 数据更新与权限管理 → 分层评测。一个典型的生产级流程可以表示为数据源接入 → 解析与清洗 → Chunking → 元数据与 ACL → Embedding → 建立检索索引 → Query 处理 → 召回 → 融合 / Reranking → Context 组装 → LLM 生成与引用 → 评测与日志 → 数据更新和删除同步1. 数据源接入第一步先确定知识从哪里来例如PDF、Word、MarkdownWiki、网页数据库Git 仓库产品文档安全知识库企业内部知识平台。这一阶段需要保存来源信息例如document_idsourcetitleauthorcreated_atupdated_atversion这些字段后续会用于过滤、引用、更新和问题定位。2. 文档解析与清洗不同来源需要转换成统一的可处理文本结构。例如 PDF 需要处理标题正文表格页码章节OCR 内容。清洗过程通常包括删除重复内容去除页眉页脚处理乱码统一编码保留标题层级修复不合理换行识别代码块、表格等特殊结构。这里有一个重要原则清洗时尽量保留原始文档结构和来源位置。后面生成引用时需要知道某个 Chunk 来自哪份文档 → 哪一章节 → 哪一页 → 哪个版本3. Chunking文档切分整篇长文档通常无法直接作为一个检索单元因此需要切成多个 Chunk。可以表示为D→{c1,c2,…,cn} D \rightarrow \{c_1,c_2,\ldots,c_n\}D→{c1,c2,…,cn}其中每个cic_ici是一个可独立检索的文本块。常见切分方式包括固定 Token 长度按段落切分按标题和章节切分语义切分滑动窗口切分。例如第3章 → 第3.1节 → 段落 → Chunk通常比简单地每 500 个字符硬切更容易保持语义完整。Chunk 太大时一个向量可能包含多个主题检索精度会下降。Chunk 太小时上下文可能被切断。因此 Chunk Size 和 Overlap 都需要通过实验选择。Microsoft Azure AI Search 的 RAG 文档也把 Chunking 作为内容准备的重要步骤尤其用于满足 Embedding 和 LLM 的 Token 长度约束。4. 给 Chunk 添加 Metadata 和 ACL每个 Chunk 除了正文还应该带有 Metadata。例如{chunk_id:doc12_sec3_chunk4,document_id:doc12,title:RAG System Design,section:3.2 Retrieval,page:16,version:2026-08-01,source:internal_wiki,acl:[security_team]}Metadata 可以支持按时间过滤按文档类型过滤按产品过滤按项目过滤按用户权限过滤回答来源引用。对于企业 RAGACLAccess Control List尤其重要。用户查询时检索结果应限制在该用户具有访问权限的文档范围内。例如R(q,u){d∣d∈Retrieve(q), Permission(u,d)1} R(q,u) \{d\mid d\in Retrieve(q),\ Permission(u,d)1\}R(q,u){d∣d∈Retrieve(q),Permission(u,d)1}这样可以防止模型通过 RAG 检索到用户本来无权访问的内部文档。5. Embedding 与建立索引然后将每个 Chunk 转换成向量eifembedding(ci) e_if_{\text{embedding}}(c_i)eifembedding(ci)得到ei∈Rd e_i\in\mathbb{R}^{d}ei∈Rd随后保存到 Vector Index 中。同时通常还会保留原始文本索引。因此一个生产系统可能同时存在Dense Vector Index用于语义检索Sparse / BM25 Index用于关键词检索Metadata Index用于过滤。原始 RAG 工作使用的是稠密向量检索。生产系统可以进一步使用 Hybrid Search。6. 用户 Query 处理用户输入q qq进入检索系统前可以进行Query normalization拼写修正Query rewritingQuery expansion意图识别Metadata filter 提取多查询生成。例如用户问PyTorch 2.6 为什么模型加载失败可以转换成PyTorch 2.6 model loading failure serialization weights_only同时提取version 2.6提高后续召回效果。简单任务可以直接使用原始 Query无需增加这些步骤。7. Retrieval候选文档召回最基本的做法是eqfembedding(q) e_qf_{\text{embedding}}(q)eqfembedding(q)然后计算 Query 与 Chunk 的向量相似度score(q,ci)sim(eq,ei) score(q,c_i)sim(e_q,e_i)score(q,ci)sim(eq,ei)取得 Top-KCKTopK(score(q,ci)) C_K\operatorname{TopK}(score(q,c_i))CKTopK(score(q,ci))生产系统常见三种方案Dense Retrieval使用 Embedding 语义相似度。适合同义表达语义相关问题用户问题与文档措辞不同的情况。Sparse Retrieval / BM25依赖关键词匹配。适合产品名称API 名称CVE 编号错误码精确术语。Hybrid Search同时执行BM25 Vector Search然后使用 RRF 等方法融合结果。对于代码、安全、技术文档等存在大量精确实体的场景Hybrid Search 通常值得重点测试。8. Reranking候选结果重排第一阶段 Retriever 追求快速召回因此可以先取Top-50然后使用更精确的模型对这 50 个 Chunk 重新排序sifreranker(q,ci) s_if_{\text{reranker}}(q,c_i)sifreranker(q,ci)最终保留Top-5典型流程Retriever → Top-50 → Reranker → Top-5Bi-encoder 更适合大规模初始召回。Cross-encoder 可以同时读取 Query 和 Document计算成本较高因此更适合对较少候选进行精排。Reranking 属于增强步骤可以根据质量和延迟预算决定是否使用。9. Context Assembly上下文组装得到最终 Chunk 后需要组成 Prompt Context。这里需要处理Chunk 顺序重复内容Token Budget来源标记相邻 Chunk 合并文档之间的冲突长上下文截断。例如[Source 1] Document: PyTorch 2.6 Release Notes Section: Serialization ... [Source 2] Document: torch.load Documentation ...然后把这些 Context 与用户问题一起交给 LLM。10. LLM 生成与来源引用最终yLLM(q,C) y LLM(q,C)yLLM(q,C)其中CCC是检索得到的 Context。Prompt 中通常需要明确要求依据提供的 Context 回答无证据时明确说明对事实声明标记来源不使用无来源内容补全关键事实。RAG 的重要价值之一就是让生成结果能够追溯到外部知识来源。因此最终答案最好保留answer → chunk_id → document_id → source/version这一条证据链。11. RAG 怎么评测RAG 需要分层评测。第一层Retrieval Evaluation评估有没有把正确资料找出来。常见指标RecallKPrecisionKMRRNDCG。例如 RecallKRecallKTop-K 中召回的相关文档数全部相关文档数 RecallK \frac{\text{Top-K 中召回的相关文档数}} {\text{全部相关文档数}}RecallK全部相关文档数Top-K中召回的相关文档数如果 Retrieval 已经没有召回正确证据后面的 Generator 很难生成可靠答案。第二层Generation Evaluation检索正确以后再评价 LLM 有没有正确使用这些证据。可以评估CorrectnessRelevanceGroundedness / FaithfulnessCompletenessCitation Correctness。其中 Groundedness 关注最终回答中的事实是否能够由检索 Context 支持。第三层End-to-End Evaluation最终还需要从真实用户任务评价整个系统例如Answer Accuracy任务完成率延迟Token Cost检索成本用户满意度无答案时的拒答能力。因此不能只观察一个 RecallK就判断整个 RAG 系统有效。12. 数据更新和删除怎么处理生产系统中的知识库会持续变化。当原始文档修改时需要检测变化 → 找到受影响的 Chunk → 重新解析 → 重新 Embedding → 更新 Index当文档删除时也必须同步删除对应的ChunkVectorMetadata检索记录。否则可能发生原文已经删除RAG 仍然召回旧知识。因此建议为 Chunk 保存document_idchunk_idversionupdated_atcontent_hash回答日志也可以记录query → retrieved chunk → document version → final answer这样能够定位某个回答当时使用了哪一个知识版本。最终完整流程可以把完整 RAG 数据链路总结成数据源 ↓ 解析与清洗 ↓ Chunking ↓ Metadata / ACL ↓ Embedding ↓ Vector / BM25 Index ↓ 用户 Query ↓ Query Processing ↓ Dense / Sparse / Hybrid Retrieval ↓ Reranking ↓ Context Assembly ↓ LLM Generation ↓ Citation ↓ Retrieval Generation End-to-End Evaluation ↓ Update / Delete / Version Management面试时可以压缩成下面这段我会把 RAG 的数据处理分成离线和在线两条链路。离线阶段先接入 PDF、Wiki、数据库等知识源完成解析、清洗和结构化 Chunking。每个 Chunk 保存来源、章节、版本和 ACL 等 Metadata然后计算 Embedding并建立向量索引对于代码、错误码等精确匹配较多的场景还可以同时建立 BM25 索引。在线阶段用户 Query 经过必要的 Query Rewrite 和 Metadata Filter 后进行检索。可以使用 Dense Retrieval也可以使用 BM25 与向量检索组成 Hybrid Search。召回候选后再用 Reranker 精排将最终几个 Chunk 按 Token Budget 组装成 Context交给 LLM 生成答案并保留来源引用。评测需要分层进行。检索层看 RecallK、MRR 等指标生成层看 Correctness、Groundedness 和 Citation最后再评价端到端准确率、延迟和成本。生产环境还需要处理权限、文档更新和删除同步。每个 Chunk 最好绑定 document ID、版本和时间戳使索引内容和最终回答都能够追溯到具体知识版本。来源Lewis et al.Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.Microsoft Azure AI Search — Retrieval-Augmented Generation Overview.Microsoft Azure AI Search — Chunk Documents for Vector Search.Microsoft Azure AI Search — Document-Level Access Control.Microsoft Azure Architecture Center — RAG Information-Retrieval Evaluation.Microsoft Azure Architecture Center — RAG LLM End-to-End Evaluation.Elastic Documentation — Hybrid Search.Elastic Documentation — Ranking and Reranking.
