RAG文档切分最佳实践：企业级方案+主流策略+生产落地

前言在检索增强生成RAG系统中文档切分Chunking是决定检索精度、生成质量与系统性能的核心前置环节——好的切分能让RAG“找得准、答得对”反之则会导致检索召回率低、生成内容断章取义或幻觉。结合2025-2026年最新技术趋势、大厂公开分享阿里、微软、字节等系统梳理文档切分的核心方法、主流新策略以及生产环境中的最佳实践附代码模板助力开发者快速落地高可用RAG系统。重点补充2026年最新的切分策略如LGMGC、多模态切分解决开发者“切分参数怎么设、策略怎么选、坑怎么避”的核心痛点。一、基础版3种核心切分方法先明确3种基础切分方法的生产落地细节——很多开发者踩坑的核心原因是只懂理论不懂参数调优。1. 窗口切分滑动窗口切分 Sliding Window Chunking最基础且易落地的切分方式核心是“固定窗口重叠步长”保护跨块上下文关联是处理长文本如日志、报告的基础策略。生产级实现核心参数主流配置为chunk_size512~1500 tokensoverlap10%~20%根据文本密度调整比如微软在Semantic Kernel中处理航空协议文档时采用chunk_size1000-1500 tokensoverlap20%确保跨段落语义连贯。Overlap机制深化进阶策略10%~20% overlap为通用基准但实际生产中需结合文本特性动态调整避免“固定重叠”导致的冗余或上下文断裂以下是进阶方案1动态重叠策略根据文本“语义密度”自适应调整重叠长度。语义密度高的段落如专业术语密集的医疗、法律文本、技术文档重叠长度提升至25%~30%避免拆分专业表述如医疗术语、法律条款语义密度低的段落如叙事性文本、新闻报道重叠长度降低至5%~10%减少存储冗余。例如阿里在医疗RAG中对药品说明书的专业术语段落设置overlap30%对患者须知的叙事段落设置overlap8%兼顾语义完整与存储效率。2Sentence Window Retrieval句子窗口检索当前主流的Overlap替代方案核心逻辑是“检索小块、返回大块”无需设置传统重叠既避免冗余又能保证上下文完整性。具体实现的是将文本切分为细粒度句子级小块100~200 tokens检索时匹配细粒度小块返回时关联该小块所在的粗粒度父块500~750 tokens相当于动态“关联上下文”。该方法与LGMGC的“父子块”思想高度契合微软在Semantic Kernel中已将其与LGMGC结合检索精度提升15%存储成本降低20%。from transformers import GPT2Tokenizer def sliding_window_chunk(text, chunk_size1000, overlap200): # 用真实tokenizer计算长度生产级必做避免字符数与token数偏差 tokenizer GPT2Tokenizer.from_pretrained(gpt2) tokens tokenizer.encode(text, add_special_tokensFalse) chunks [] step chunk_size - overlap # 避免最后一块过短不足chunk_size的50%则合并到上一块 for i in range(0, len(tokens), step): end min(i chunk_size, len(tokens)) # 合并过短块 if end - i chunk_size * 0.5 and i ! 0: chunks[-1] chunks[-1] tokens[i:end] else: chunks.append(tokens[i:end]) # 解码回文本 return [tokenizer.decode(chunk, skip_special_tokensTrue) for chunk in chunks]1、采用滑动窗口切分处理航空政策文档设置chunk_size1000-1500 tokensoverlap20%配合Qdrant向量数据库的分片策略提升多文档检索效率2、将overlap调整为10%减少存储冗余同时保证日志上下文连贯。优缺点与适用场景优点实现简单、性能损耗低保护跨块上下文检索时召回率稳定缺点无法识别自然语义边界可能拆分完整语义单元重叠部分增加存储成本。适用场景技术文档、法律条文、日志、长段落学术论文等上下文依赖强的文本。2. 递归切分Recursive Chunking当前工业界最通用的切分策略LangChain默认实现按“从粗到细”的分隔符优先级递归分割优先保留自然语义边界段落、句子平衡语义完整性与块大小控制是大厂“兜底首选”策略。生产级实现核心优化大厂会根据文本类型定制分隔符优先级而非使用默认值比如处理Markdown文档时优先按标题分割再按段落、句子分割避免破坏文档结构。from langchain.text_splitter import RecursiveCharacterTextSplitter def recursive_chunk_optimized(text, text_typemarkdown): # 按文本类型定制分隔符大厂核心优化点 if text_type markdown: separators [\n## , \n### , \n\n, \n, . , ! , ? , , ] elif text_type plain: separators [\n\n, \n, . , ! , ? , , ] elif text_type code: separators [\n\n, \ndef , \nclass , \nif , \nfor , , ] splitter RecursiveCharacterTextSplitter( separatorsseparators, chunk_size750, # 大厂主流中间值适配大多数LLM上下文窗口 chunk_overlap75, # 10% overlap平衡冗余与连贯 length_functionlambda x: len(x.split()) # 按单词数估算token数落地高效 ) return splitter.split_text(text)1、针对不同文档类型新闻、技术文档、代码定制分隔符比如代码文档优先按函数、类分割确保代码逻辑完整2、将递归切分与结构识别结合先按标题层级拆分再对过长章节递归切分保留文档固有逻辑。优缺点与适用场景优点通用性极强平衡语义完整性与块大小适配90%以上的文本类型无需复杂调参缺点对极度格式化文本如复杂表格效果一般递归过程有轻微计算开销。适用场景通用文本、新闻报道、博客文章、代码文档等结构不均的内容。3. 语义切分Semantic Chunking2025-2026年主流进阶策略基于语义相似度识别边界确保每个块都是完整语义单元能显著提升RAG生成质量是大厂处理知识库、FAQ、客服日志的核心策略。生产级实现核心优化采用轻量化嵌入模型降低成本、动态阈值适配不同文本结合元数据注入提升检索相关性——大厂普遍使用BGE-small、all-MiniLM等轻量化模型避免使用大模型嵌入导致的性能瓶颈。from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity import numpy as np def semantic_chunk_production(text, max_tokens500, threshold0.65): # 大厂首选轻量化嵌入模型兼顾速度与效果 model SentenceTransformer(BAAI/bge-small-en-v1.5) # 按句子拆分保留基础语义单元 sentences [s.strip() for s in text.split(. ) if s.strip()] if not sentences: return [text] # 生成嵌入向量批量处理提升效率 embeddings model.encode(sentences, batch_size32, show_progress_barFalse) chunks [] current_chunk [sentences[0]] for i in range(1, len(sentences)): # 计算相邻句子相似度 similarity cosine_similarity([embeddings[i-1]], [embeddings[i]])[0][0] # 动态调整阈值句子越短阈值越低避免过度拆分 current_threshold threshold if len(sentences[i]) 50 else threshold - 0.1 # 控制块大小避免超标 if similarity current_threshold or len(. .join(current_chunk [sentences[i]])) max_tokens: chunks.append(. .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append(. .join(current_chunk)) # 注入元数据大厂必做提升检索精度 return [{chunk: chunk, length: len(chunk.split())} for chunk in chunks]1、采用语义切分处理用户对话日志结合BGE-small嵌入模型将阈值设为0.65确保每个chunk对应一个完整的用户意图客服回复检索相关性提升30%以上2、将语义切分与上下文增强结合为每个chunk注入段落标题元数据方便后续检索重排序。优缺点与适用场景优点语义完整性强减少“断章取义”提升RAG生成质量适配高价值知识库缺点计算成本高于基础策略需调优阈值和模型参数。适用场景知识库、FAQ文档、产品说明书、客服对话记录、学术论文等语义独立的内容。4. 特殊数据类型切分1API文档切分核心逻辑API文档如Swagger、OpenAPI规范无需按文本长度切分而是提取每个接口的核心信息接口名称、请求方式、参数说明、返回值、异常提示转化为标准化自然语言描述每个接口作为一个独立chunk注入元数据接口路径、所属模块。将Swagger文档解析为JSON提取接口关键信息转化为“接口名称XXX请求方式XXX参数XXX功能描述XXX”的统一格式每个接口作为一个chunk检索时能精准匹配接口相关查询。2数据库Schema切分核心逻辑数据库Schema表结构、字段说明、关联关系无需切分采用“NL2Text自然语言转文本”转化策略将表结构转化为自然语言描述结合表间关联关系生成结构化语义文本整体作为一个或多个大chunk按表分组。将MySQL Schema转化为“表名XXX用途XXX字段XXX类型XXX说明XXX关联表XXX关联字段XXX”的文本格式按业务模块分组生成chunk配合关键词检索用户可通过自然语言如“查询用户表的手机号字段类型”精准检索Schema信息。3纯结构化数据切分核心逻辑纯结构化数据如CSV、Excel表格无需传统切分优先采用“行级语义合并”或“表级语义汇总”。例如电商订单数据表格可按“订单ID用户ID”分组将同一订单的多行列数据合并为一个语义chunk简单统计表格可将表格整体转化为自然语言描述含表头、核心数据趋势作为单个chunk避免行级切分导致的语义碎片化。二、2025-2026年主流最新切分策略企业级首选以下策略均为2025年后出现、经大厂验证有效的最新方案重点解决“语义完整与粒度灵活”“多模态文档切分”“异构文档适配”等核心痛点是当前生产环境的首选进阶策略。1. LGMGC切分Logits-Guided Multi-Granular Chunker2026年最新融合策略由论文提出融合Small2big思想与语义切分解决“语义完整与粒度灵活”的核心矛盾目前已被微软、阿里等大厂引入生产环境是抽取式问答类RAG的最优解之一。核心原理分两步实现① 用轻量化LLM的Logits信息预测EOS标记的概率切出语义完整的“父块”② 将父块拆分为多粒度“子块”检索时用子块精准定位生成时用父块完整上下文兼顾精度与连贯性。生产级实现from transformers import AutoModelForCausalLM, AutoTokenizer import torch def lgmgc_chunk(text, parent_chunk_size800, child_chunk_size400, model_nameLlama-3-8B-Instruct): # 步骤1初始化轻量化LLM本地部署降低成本 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16, device_mapauto) # 步骤2生成语义完整的父块Logits引导 tokens tokenizer.encode(text, add_special_tokensFalse, return_tensorspt).to(model.device) parent_chunks [] start 0 while start len(tokens[0]): end min(start parent_chunk_size, len(tokens[0])) # 截取当前窗口添加提示判断语义完整性 window_tokens torch.cat([tokens[0][start:end], tokenizer.encode(请判断上一句是否语义完整, add_special_tokensFalse)], dim0) outputs model(window_tokens.unsqueeze(0), return_dictTrue) # 提取EOS标记的概率概率越高语义越完整 eos_token_id tokenizer.eos_token_id eos_prob torch.softmax(outputs.logits[0, -2, :], dim0)[eos_token_id].item() # 概率0.8视为语义完整分割父块 if eos_prob 0.8 or end len(tokens[0]): parent_chunk tokenizer.decode(tokens[0][start:end], skip_special_tokensTrue) parent_chunks.append(parent_chunk) start end else: end 50 # 未完整扩展窗口 # 步骤3拆分多粒度子块递归切分兜底 child_chunks [] splitter RecursiveCharacterTextSplitter(chunk_sizechild_chunk_size, chunk_overlap50) for parent in parent_chunks: children splitter.split_text(parent) child_chunks.append({parent: parent, children: children}) return child_chunks1、采用LGMGC策略使用8位量化的Llama3-8b模型父块size800 tokens子块size400 tokens相比传统语义切分检索DCGk提升18%问答F1分数提升12%且部署成本仅为大模型分块的1/52、将LGMGC与实体识别结合确保医疗术语语义完整避免拆分专业表述。2. 结构感知切分Structure-Aware Chunking处理结构化文档Markdown、PDF、Word的核心策略完全基于文档固有结构标题、章节、表格、代码块切分保留原始逻辑层次解决“结构化文档切分后逻辑混乱”的痛点目前阿里、字节均已大规模应用。生产级实现核心优化解析文档格式提取标题层级、表格、代码块等结构单独处理特殊元素避免拆分表格、代码等完整单元——阿里在AI搜索开放平台中先将PDF解析为Markdown再按结构切分确保表格、公式的完整性。import markdown from markdown.extensions.toc import TocExtension from unstructured.partition.pdf import partition_pdf def structure_aware_chunk(file_path, file_typepdf): # 步骤1解析文档提取结构信息 if file_type pdf: # 解析PDF保留表格、代码块结构 elements partition_pdf(file_path, strategyhi_res, extract_imagesFalse) text \n.join([str(el) for el in elements if el.category Text or el.category Table]) elif file_type markdown: with open(file_path, r, encodingutf-8) as f: text f.read() # 步骤2提取标题层级Markdown/PDF解析后 md markdown.Markdown(extensions[TocExtension()]) md.convert(text) toc md.toc_tokens if hasattr(md, toc_tokens) else [] # 步骤3按标题层级切分保留结构 chunks [] current_section {title: 引言, content: , level: 1} for token in toc: level token[level] title token[name] # 提取当前标题下的内容生产中需结合文档解析库精准提取 content text[text.find(title):text.find(toc[toc.index(token)1][name]) if toc.index(token)1 len(toc) else len(text)] # 对过长内容用递归切分兜底 splitter RecursiveCharacterTextSplitter(chunk_size600, chunk_overlap60) content_chunks splitter.split_text(content) for chunk in content_chunks: chunks.append({ title: title, level: level, content: chunk, source: file_path }) return chunks1、采用“PDF→Markdown→结构切分”的流程将表格单独作为一个chunk避免拆分表格行导致的语义残缺检索时能精准召回表格中的数据信息2、对Markdown的标题层级进行分级切分将### 标题下的内容作为子chunk关联父标题元数据提升检索时的上下文定位能力。3. 多模态文档切分Multimodal Chunking2025年后大厂重点布局的策略针对图文混合PDF、表格、图片等多模态文档将文本、表格、图片分别切分保留多模态语义关联解决“多模态文档切分后信息丢失”的痛点目前微软、阿里均已落地应用。核心逻辑1. 文本部分采用结构感知切分保留标题、段落逻辑2. 表格部分将整个表格或单个子表格作为独立chunk转换为Markdown格式注入表格标题元数据3. 图片部分用多模态模型如Gemini、通义千问-VL提取图片描述与相邻文本合并为一个chunk确保图文语义连贯。例如处理图文混合的机场手册时将图片中的登机流程、设备示意图用多模态模型提取描述与相邻的文本说明合并为一个chunk检索时能同时召回文本和图片相关信息生成答案更完整在电商RAG中将商品详情页的图文内容切分图片描述与商品参数文本关联用户查询“商品尺寸”时能同时召回参数表格和尺寸示意图相关chunk。4. 代理切分Agent-Based Chunking2026年最新自适应策略由LLM作为“智能代理”自动分析文档类型、结构复杂度推荐最优切分策略和参数无需人工调参适配异构文档集合如同时处理新闻、代码、PDF。核心逻辑1. LLM代理分析文档输入文档片段LLM判断文档类型文本/代码/PDF、结构复杂度是否有标题/表格2. 推荐切分策略如代码文档推荐“AST语法切分”PDF推荐“结构感知切分”3. 执行切分并验证LLM验证chunk语义完整性不合格则调整参数重新切分。例如内置Agent切分模块用户上传异构文档集合后Agent自动匹配切分策略对代码文档用AST语法切分按函数、类分割对新闻用递归切分对PDF用结构感知切分相比人工配置策略检索召回率提升25%部署效率提升60%将Agent切分与工具链结合自动调用不同的切分工具适配多类型文档。三、生产级最佳实践1. 核心参数调优通用配置chunk_size和overlap是核心参数不同场景配置不同文档类型推荐策略chunk_sizetokensoverlaptokens通用文本新闻、博客递归切分500~75050~7510%技术文档/学术论文结构感知层次化切分父块1000~1500子块300~500父块100~150子块50~75知识库/FAQ语义切分LGMGC300~50030~5010%长文档书籍、报告LGMGC层次化切分父块800~1000子块400~500父块80~100子块40~50多模态文档图文/PDF多模态切分结构感知文本500~750表格单独作为chunk50~75API文档接口级语义提取300~500单接口0无需重叠数据库SchemaNL2Text转化表级分组500~1000单表0无需重叠2. 切分策略决策树你的业务场景推荐策略理由通用QA、文档问答如企业知识库问答递归切分 语义增强平衡成本与效果适配大多数文本类型无需复杂调参检索与生成效果稳定是大厂通用兜底方案。长文摘要、法律/医疗文档处理LGMGC / 层次化切分此类场景需保留长距离依赖和完整语义单元避免专业术语、法律条款拆分LGMGC的父子块思想可兼顾精准检索与完整上下文。代码检索、日志分析AST / 语法感知切分必须遵循代码的语法树结构、日志的时间/事件逻辑不能随意切断函数、类或日志上下文AST切分可保证逻辑完整性。电商、多模态搜索图文/表格混合多模态切分 图结构需要将图片、表格与文本建立语义关联多模态切分可避免图文信息丢失图结构可提升跨模态检索的相关性。API检索、数据库Schema查询NL2Text转化 接口/表级分组此类数据无需传统切分转化为自然语言描述后可提升检索易用性按接口/表分组可避免语义混淆适配自然语言查询场景。3. 向量数据库的配合策略文档切分与向量数据库的索引策略强相关合理搭配可显著提升RAG检索性能1Hybrid Search混合检索若向量数据库支持关键词向量混合检索如Elasticsearch、Weaviate、Qdrant切分时可更侧重语义完整性无需过度追求细粒度切分。因为关键词检索可弥补“切分过细导致的精确匹配不足”向量检索负责语义匹配二者结合可提升检索召回率和精度。2Parent-Child Indexing父子文档索引若使用LGMGC、Sentence Window Retrieval等父子块策略向量数据库需支持父子文档索引如Elasticsearch的Join datatype、Weaviate的Reference关系将子块与父块建立关联检索时匹配子块返回时关联父块上下文实现“精准定位完整上下文”。4. 工具选型避免重复造轮子优先使用大厂验证过的工具以下是生产级工具选型推荐基础切分工具LangChain递归、滑动窗口、语义切分大厂首选、LlamaIndex层次化切分、结构感知切分多模态切分工具UnstructuredIO解析PDF、图片提取结构、Microsoft Semantic Kernel多模态切分Agent集成嵌入模型BAAI/bge-small-en-v1.5轻量化、高效、all-MiniLM-L6-v2通用、适配多语言大厂均优先使用轻量化模型代码切分工具Tree-Sitter解析代码AST按函数、类切分字节、微软首选特殊数据处理工具Swagger ParserAPI文档解析、SQLAlchemy数据库Schema提取、LangChain NL2SQL结构化数据转自然语言。5. 避坑要点1. 避免“一刀切”不要用统一参数处理所有文档比如代码文档用大chunk_size会导致逻辑混乱FAQ用小chunk_size会导致语义碎片化2. 表格切分避坑不要按行切分表格需将整个表格或子表格作为独立chunk转换为Markdown格式保留表头信息否则会导致检索时无法理解表格语义3. 嵌入模型避坑不要使用大模型如GPT-4做嵌入优先用轻量化模型降低部署成本和延迟大厂生产环境中嵌入延迟需控制在100ms以内4. 元数据必加每个chunk需注入元数据标题、来源、层级否则检索时无法定位上下文阿里、微软均要求元数据完整性5. 避免过度重叠overlap超过20%会增加存储成本和检索冗余低于10%会导致上下文断裂10%~20%为最优区间6. 特殊数据避坑API、Schema等特殊数据不要按传统文本切分优先采用NL2Text转化策略避免切分导致的语义混乱7. 数据库配合避坑使用父子块策略时需确认向量数据库支持父子索引否则无法实现“检索小块、返回大块”的效果影响生成质量。6. 落地案例文档解析将PDF、Word、API文档、数据库Schema等不同格式文档分类解析API文档用Swagger Parser提取接口信息Schema用SQLAlchemy提取表结构格式转化将API文档、Schema转化为标准化自然语言描述PDF解析为Markdown保留原始结构初步切分按文档类型匹配策略如API用接口级切分、PDF用结构感知切分生成粗粒度父块1000~1500 tokens精细切分对过长的父块用递归切分兜底生成子块300~500 tokens语义密度高的段落采用动态重叠25%~30%特殊处理表格单独作为chunk图片用多模态模型提取描述与相邻文本合并元数据注入为每个chunk添加标题、层级、来源、创建时间等元数据验证优化用LLM代理验证chunk语义完整性不合格则调整参数重新切分向量入库将chunk生成嵌入向量存入Milvus向量数据库采用Hybrid Search策略关联父子块索引针对LGMGC策略用于检索重排序。四、切分效果的评估指标生产环境中切分效果需通过量化指标评估避免“凭经验判断”以下是主流的3个核心评估指标附量化方法和生产级标准1. 检索召回率 (Recallk)核心定义衡量切分后的chunk能否被正确检索到即“相关chunk被检索到的比例”k表示检索返回的top-k个结果是评估切分效果的核心指标。量化方法Recallk 检索到的相关chunk数量 / 所有相关chunk数量× 100%生产标准Recall5 ≥ 90%、Recall10 ≥ 95%若低于该标准需调整切分粒度如细化切分、增加重叠或优化检索策略。2. 上下文相关性 (Context Relevance)核心定义衡量检索到的chunk是否包含回答问题所需的完整上下文避免因切分导致的信息丢失直接影响RAG生成质量。量化方法采用LLM打分如Llama3-8B输入“问题检索到的chunk”让LLM对上下文完整性打分1~5分取多个样本的平均分≥4分为合格生产标准上下文相关性平均分 ≥ 4.2分若分数过低需调整切分策略如采用LGMGC、Sentence Window Retrieval避免拆分完整语义单元。3. 噪声比率核心定义衡量切分过程中是否引入过多重叠冗余信息或无关内容噪声比率越低切分质量越高可有效降低存储成本和检索干扰避免检索时返回无关chunk。量化方法噪声比率 冗余/无关chunk数量 重叠部分重复token数/总token数 / 2 × 100%其中冗余/无关chunk指不包含任何有效语义、仅为重叠内容或无关信息的chunk重叠部分重复token数需剔除合理重叠10%~20%区间内的重叠。生产标准噪声比率 ≤ 8%若超过该标准需优化切分策略如调整重叠比例、采用动态重叠、剔除无关内容。例如针对日志切分场景将固定overlap从20%调整为动态重叠5%~10%后噪声比率从12%降至6%存储成本降低30%在多模态文档切分中通过过滤图片无关描述、优化表格切分逻辑将噪声比率从10%降至7%检索速度提升25%。评估指标总结生产环境中需结合三个核心指标协同评估切分效果不可单一依赖某一个指标Recallk保障“能检索到”上下文相关性保障“检索到的有用”噪声比率保障“检索到的不冗余”。三者协同优化才能实现切分效果的最优化。实践中通常会建立“指标联动优化”机制若Recallk不达标优先细化切分粒度、增加合理重叠若上下文相关性不达标优先采用LGMGC、Sentence Window Retrieval等保留完整语义的策略若噪声比率超标优先调整重叠比例、剔除无关内容。同时会结合业务场景动态调整指标阈值例如医疗、法律等高精度场景会提高上下文相关性标准≥4.5分适当放宽噪声比率≤10%而日志分析、通用检索等场景会优先控制噪声比率≤6%确保检索效率。五、总结文档切分作为RAG系统的“第一道门槛”其质量直接决定了RAG的检索精度和生成效果。本文结合2025-2026年大厂最新实践系统梳理了基础切分方法、进阶策略、特殊数据处理、评估指标、生产落地技巧核心结论如下1. 策略选择无“最优策略”只有“最适配场景”可通过切分策略决策树快速匹配业务场景通用场景优先递归切分语义增强高精度场景优先LGMGC/层次化切分多模态场景优先多模态切分图结构2. 落地关键参数调优需贴合文档类型避免“一刀切”同时重视元数据注入和向量数据库配合Hybrid Search和Parent-Child Indexing可显著提升检索性能3. 效果保障通过Recallk、上下文相关性、噪声比率三个核心指标量化评估结合LLM代理验证实现切分效果的持续优化4. 特殊处理API文档、数据库Schema等特殊数据无需传统切分优先采用NL2Text转化策略适配RAG检索需求。展望未来文档切分将向“全自动化、语义自适应”方向发展Agent切分将成为异构文档集合的首选方案结合大模型的语义理解能力实现无需人工调参的端到端切分多模态切分将进一步融合跨模态语义关联实现文本、图片、表格、代码的统一切分与检索同时切分策略与向量数据库、LLM模型的联动将更加紧密形成“切分-检索-生成”的闭环优化助力RAG系统向更高精度、更高效率、更低成本的方向落地。