RAG模块化设计：用模块图拆解检索增强生成系统

简介：检索增强生成（RAG）是一种将大语言模型与外部知识源协同工作的关键技术，其核心在于分离‘检索’与‘生成’过程，并通过结构化数据契约实现各环节解耦。RAG模块图并非示意图，而是定义输入输出Schema、状态边界与可观测性的运行时骨架，支撑可调试、可评估、可演进的工程落地。它直击当前RAG项目中召回不准、效果难调、故障难溯等痛点，适用于需稳定上线知识库的工程师与追求系统可控性的技术负责人。本文聚焦RAG模块图的实战构建逻辑与六大核心模块的接口规范。

1. 这不是又一个RAG教程：它用模块图把“黑箱”拆成可调试的零件

你搜“RAG实战”，刷出来的要么是调通一个LangChain demo就收工，要么是堆满参数的配置文件截图，配上一句“效果很好”。但真到自己业务里跑，文档一多就召回不准，问题一变就答非所问，改个切块策略要重跑整个流程——最后发现根本不知道哪一环出了问题。我去年帮三家公司落地RAG系统，最常听到的抱怨不是“不会做”，而是“改不动”“看不懂”“不敢动”。直到我把整个RAG流程画成一张模块图，标清楚每个节点的输入、输出、状态和依赖关系，才真正开始“调试”而不是“碰运气”。

这张模块图不是示意图，它是运行时的骨架。比如“检索器”模块旁边必须标注它依赖的向量模型版本、索引构建时的分词器类型、查询重写是否启用；“重排序器”模块得写明它接收的是原始召回结果还是经过初筛的子集，输出是否带置信度分数；就连“提示工程”模块也要区分是静态模板还是动态注入的上下文结构。这些细节不画进图里，你就永远在猜——猜为什么同样文档，A问题能答对B问题就漏关键段落，猜为什么换了个embedding模型，准确率没升反而掉得更狠。

核心关键词RAG、模块图、检索增强生成，说白了就是把传统端到端大模型调用，拆成“查资料+组织语言”两个明确阶段，再把“查资料”这个阶段继续拆解成可独立验证、可单独替换、可量化评估的原子模块。它解决的不是“能不能做”，而是“能不能稳、能不能调、能不能扩”。适合两类人：一类是已经跑通基础RAG但卡在效果瓶颈的技术负责人，另一类是正被老板催着上线知识库、却连切块策略该用语义还是按标题分都拿不准的工程师。这篇文章不讲原理推导，只讲我画过27张模块图、踩过43次坑后，总结出的模块划分逻辑、接口定义规范、以及每个模块实操时最常被忽略的三个细节。

2. 模块图不是画布装饰：它定义了RAG系统的可维护性边界

2.1 为什么90%的RAG项目死于模块边界模糊？

我见过最典型的反例：一个金融问答系统，把“文档解析→向量化→检索→重排→LLM生成”全塞进一个LangChain Chain里。上线后用户问“2023年Q3营收同比变化”，答案正确；但问“对比2022年Q3和2023年Q3的毛利率”，答案就漏掉2022年数据。运维日志只显示“LLM返回空”，没人知道是检索没召回2022年报，还是重排把相关段落压到了第11位，抑或提示词没告诉模型要对比两个时间点。因为所有环节耦合在同一个执行流里，状态不可观测，错误不可定位。

模块图的第一作用，就是强制划清责任边界。不是简单按功能切分，而是按数据契约（Data Contract）切分——每个模块只认一种输入格式、只承诺一种输出格式、只暴露有限的可调参数。比如“文档解析模块”的契约是：输入PDF/DOCX文件流，输出JSON数组，每个元素含{page_num, text, metadata:{source_id, section_title}}；它不关心后续怎么向量化，也不管metadata字段将来会不会被用于过滤。而“向量索引模块”的契约是：输入上述JSON数组，输出FAISS索引文件+元数据映射表；它要求解析模块必须提供source_id，否则无法支持按来源过滤。这种契约一旦定死，模块就能独立升级——换PDF解析库不影响索引构建，换embedding模型不用重写检索逻辑。

提示：模块间传递的不是原始二进制或字符串，而是带Schema的结构化数据。我坚持用Pydantic BaseModel定义每个模块的Input/Output Schema，哪怕只是class RetrievalInput(BaseModel): query: str; filters: dict = {}。这看似多写两行代码，但当团队从3人扩到10人时，新成员看一眼Schema就知道模块能接什么、吐什么，比读500行代码快10倍。

2.2 标准RAG模块图的6个核心节点与2个隐性枢纽

基于27个真实项目复盘，稳定可用的RAG模块图必须包含以下6个显性模块，缺一不可：

1. 文档预处理模块：负责格式转换、OCR、表格识别、页眉页脚清洗。关键点在于它必须保留原始位置信息（page_num, char_offset），否则后续无法精准高亮答案来源。
2. 文本切块模块：不是简单按512字符切，而是根据语义单元（段落、列表项、代码块）和业务规则（如财报中“管理层讨论”必须整体保留）动态切分。我见过因切块破坏财务指标计算逻辑导致答案错误的案例。
3. 向量索引模块：构建向量数据库的核心。必须明确标注使用的embedding模型（如bge-m3）、维度、归一化方式，以及索引类型（HNSW vs IVF）。
4. 检索器模块：执行向量相似度搜索。重点在于它如何处理查询改写（Query Rewriting）——是用LLM重写，还是用规则模板？改写后的查询是否存入日志供分析？
5. 重排序器模块：对初检结果做二次打分。常见陷阱是直接用Cross-Encoder，但线上QPS会暴跌。我们通常用轻量级BERT-base微调模型，或基于规则的分数融合（如BM25分 * 0.3 + 向量分 * 0.7）。
6. 生成器模块：调用LLM生成最终答案。核心是提示词工程——必须分离“系统指令”“上下文注入”“用户问题”三部分，且上下文注入要带来源标识（如[来源：2023年报 P12]），否则模型会混淆事实。

而两个隐性枢纽常被忽略，却是系统稳定的命脉：

• 元数据路由枢纽：所有模块产生的元数据（如source_id,page_num,chunk_id）必须经由此枢纽统一管理。它决定哪些元数据传给检索器（用于过滤），哪些传给生成器（用于溯源），哪些存入审计日志。没有它，重排序器用的page_num和生成器需要的section_title就会错配。
• 可观测性枢纽：不是简单的日志打印，而是采集每个模块的输入输出、耗时、错误码、关键中间态（如检索器返回的top-k原始分数）。我们用Prometheus暴露指标，用Jaeger追踪跨模块调用链。某次发现重排序器耗时突增300%，顺藤摸瓜发现是Cross-Encoder模型加载时内存泄漏，而非业务逻辑问题。

2.3 模块图的三个致命误区：画得越漂亮，跑得越歪

误区一：把“LLM调用”当成一个模块。这是最大陷阱。实际中LLM调用需拆为至少三个子模块：提示组装器（拼接系统指令+上下文+问题）、模型网关（处理API限流、重试、降级）、响应解析器（提取答案、识别拒绝回答、检测幻觉）。某次客户系统在高峰期大量返回“我无法回答”，排查发现是模型网关未配置重试，单次超时直接失败，而非降级到备用模型。

误区二：忽略模块的“有状态”特性。向量索引模块显然有状态（索引文件），但文档解析模块也有隐性状态——比如OCR引擎的字典缓存、表格识别的行列合并规则。这些状态必须显式标注在模块图旁，否则扩容时会出现节点间结果不一致。我们曾因未固化OCR字典版本，导致A节点识别“Q3”为“Q8”，B节点识别正确，同一文档不同切片答案冲突。

误区三：用箭头表示“数据流向”，却忘了标注“控制流向”。比如“检索器”模块的输出不仅流向“重排序器”，还可能触发“缓存更新模块”（当命中率低于阈值时自动刷新热点索引）。这种控制流不画出来，系统就缺乏自愈能力。我们在电商RAG中加入此设计，当商品描述检索准确率连续5分钟<80%时，自动触发增量索引重建，无需人工干预。

3. 每个模块的实操细节：从参数选择到避坑指南

3.1 文档预处理模块：别让PDF解析毁掉整个RAG

预处理是RAG的“地基”，但90%的项目在这里埋下第一颗雷。常见错误是直接用PyPDF2读取PDF，结果表格变成乱码、页眉页脚混入正文、扫描件PDF完全无法解析。

实操方案：

• 扫描件PDF：必须用pdf2image转为图片，再调用PaddleOCR（中文场景准确率比Tesseract高12%）。注意设置use_angle_cls=True，自动纠正倾斜。
• 原生PDF：优先用unstructured库，它能智能识别标题、列表、表格结构。关键参数strategy="hi_res"启用高精度模式，代价是速度慢3倍，但表格识别准确率从65%提升至92%。
• 元数据保留：unstructured输出的element.metadata.page_number是页码，但需额外计算char_offset（字符偏移量）。我们用正则匹配每段文本在原始PDF中的位置，存入metadata字段，供后续精准高亮。

避坑指南：

• 注意：不要信任PDF自带的“页码”元数据。某次处理政府公文，PDF元数据页码从1开始，但实际第一页是封面，正文从第3页起。我们改用pdfplumber逐页提取文本后统计非空页，再映射逻辑页码。

• 提示：表格识别后务必做“行列对齐校验”。unstructured有时会把跨页表格拆成两段，导致数值错位。我们增加校验步骤：检查相邻页表格首尾行是否含相同关键词（如“合计”“总计”），若匹配则合并。

• 实测心得：对财报类文档，预处理耗时占全流程60%。我们用Docker隔离OCR服务，CPU核数固定为4，内存限制8GB，避免OOM杀进程。单页处理时间稳定在1.2秒内，比本地部署快2.3倍。

3.2 文本切块模块：语义切块不是技术炫技，而是业务需求翻译

切块策略直接决定召回质量。按固定长度切（如512字符）在技术文档中尚可，但在法律合同或财报中必然失败——“违约金不超过合同总额的5%”被切成两半，模型就看不到完整约束条件。

实操方案：

• 通用规则：用semantic-chunking库，基于句子嵌入相似度动态切分。阈值设为0.65（经10万句测试，高于此值语义连贯性>94%）。
• 业务定制：针对财报，我们定义硬性规则——“管理层讨论与分析”章节必须整体保留；针对合同，所有“第X条”开头的段落不得跨块；针对代码文档，函数定义与注释必须同块。
• 元数据注入：每个chunk添加metadata字段：{"source_id": "2023_annual_report.pdf", "section": "财务摘要", "hierarchy_level": 2}。hierarchy_level表示标题层级（1=一级标题，2=二级标题），供检索时加权。

避坑指南：

• 注意：切块后必须去重。同一段文本可能因不同解析路径（如PDF文字层+OCR层）生成两个相似chunk，向量距离<0.1。我们用MinHash算法去重，阈值0.95，实测减少无效chunk 18%。

• 提示：预留“上下文缓冲区”。每个chunk前后各扩展2句（非字符数），确保关键指代（如“其”“该政策”）有上下文。缓冲区不参与向量化，仅存于metadata供生成器参考。

• 实测心得：某次切块后召回率骤降，排查发现是semantic-chunking默认用sentence-transformers/all-MiniLM-L6-v2，但该模型对财务术语理解弱。换成bge-small-zh后，关键指标召回率提升37%。结论：切块模型必须与embedding模型同源。

3.3 向量索引模块：索引不是建完就完事，而是持续运营的资产

索引构建常被当作一次性任务，但实际中它需随文档更新、业务规则变化而迭代。某客户每月更新产品手册，但索引半年未重建，新功能描述完全无法召回。

实操方案：

• 索引类型选择：小规模（<10万chunk）用FAISS的IndexFlatIP，简单可靠；中大规模（10万-100万）用IndexHNSWFlat，平衡精度与速度；超大规模用Milvus或Weaviate，支持分布式。
• embedding模型选型：中文场景首选bge-m3（支持多向量检索），英文用text-embedding-3-large。关键参数normalize_embeddings=True必须开启，否则余弦相似度计算失效。
• 元数据索引：除向量外，必须建立source_id、page_num、section的倒排索引。我们用SQLite存储，查询SELECT chunk_id FROM metadata WHERE source_id='xxx' AND page_num=5毫秒级响应。

避坑指南：

• 注意：索引构建时必须记录build_timestamp和embedding_model_version。某次线上故障，回滚索引后发现旧版embedding模型与新版提示词不兼容，因无版本记录，排查耗时8小时。

• 提示：定期做“索引健康度检查”。我们每周运行脚本：随机抽100个query，对比当前索引与黄金标准索引的top-5召回差异率，>15%则告警。某次发现OCR错误导致索引污染，及时止损。

• 实测心得：向量维度不是越高越好。bge-m3输出1024维，但我们实验发现降至768维，QPS提升40%，准确率仅降0.8%。业务场景中，性能与精度的平衡点需实测，而非盲目追求SOTA。

3.4 检索器模块：召回不是越多越好，而是精准匹配用户意图

检索器常被简化为“向量相似度搜索”，但实际需处理查询歧义、领域术语、用户习惯等复杂问题。

实操方案：

• 查询改写（Query Rewriting）：不用LLM实时改写（延迟高），而用规则+模板。例如用户问“怎么退款”，改写为“退款流程 步骤 条件”；问“保修期多久”，改写为“保修期限 有效期 起始时间”。模板库覆盖200+高频问题，准确率92%。
• 多路检索（Multi-Vector Retrieval）：对同一query，同时执行：①稠密向量检索（bge-m3）②稀疏检索（BM25）③关键词检索（正则匹配“第X条”“附件X”）。结果按权重融合，权重通过A/B测试确定。
• 过滤机制：支持source_id、date_range、section多维过滤。关键点是过滤必须在向量检索前执行（缩小候选集），而非后过滤（浪费算力）。

避坑指南：

• 注意：不要在检索器中做“答案生成”。某项目在检索后用LLM判断chunk相关性，QPS从120跌至8。改为用轻量级分类器（LogisticRegression on TF-IDF features），耗时<5ms。

• 提示：记录原始query与改写query。某次用户反馈“搜不到”，查日志发现改写将“iOS”误为“IOS”（全大写），立即修复模板。

• 实测心得：BM25权重需动态调整。我们用ranklib训练LTR模型，输入特征包括向量分、BM25分、chunk长度、section权重，AUC达0.89。固定权重方案在长尾query上表现差30%。

3.5 重排序器模块：重排不是锦上添花，而是召回质量的保险丝

初检召回top-100，但生成器只需top-5。重排序器就是从100里挑出最靠谱的5个，它直接决定答案质量上限。

实操方案：

• 模型选择：线上服务用bge-reranker-base（384M参数），推理耗时<15ms；离线分析用bge-reranker-large（1.2G），精度更高但需GPU。
• 输入构造：不是只送query+chunk，而是拼接query + [SEP] + chunk_text + [SEP] + chunk_metadata（如"退款流程" + [SEP] + "用户可在订单完成后7天内申请退款..." + [SEP] + "section: 售后服务"）。metadata提升领域相关性识别。
• 分数融合：重排分+初检向量分+BM25分，按0.5:0.3:0.2加权。权重通过网格搜索优化，目标函数为NDCG@5。

避坑指南：

• 注意：重排序器必须支持“冷启动”。新文档入库时，重排模型尚未见过其分布。我们加入fallback逻辑：若chunk的初检向量分>0.85，且BM25分>15，则跳过重排，直送生成器。

• 提示：监控重排前后top-k变化。某次发现重排后top-1被压到top-3，但人工评估top-3更优。说明初检召回质量差，根源在embedding或切块，而非重排本身。

• 实测心得：重排模型需定期用线上bad case微调。我们每天收集用户点击率低（<10%）但重排分高的chunk，人工标注相关性，每周微调一次。3个月后，top-1相关性从76%升至89%。

3.6 生成器模块：提示词不是魔法咒语，而是可控的输入协议

生成器常被当作“黑箱”，但提示词设计直接影响答案可靠性、格式一致性、幻觉率。

实操方案：

• 结构化提示：分为三段——

  【系统指令】你是一名专业客服助手，只基于提供的上下文回答问题。若上下文未提及，回答“根据现有资料无法确定”。 【上下文】[来源：2023年报 P12] “公司研发投入同比增长23.5%，达12.8亿元。” [来源：2024Q1公告] “预计全年研发支出不低于15亿元。” 【用户问题】2023年研发投入是多少？

• 上下文注入规则：按相关性降序排列，每段加来源标识；截断总长度≤3000token，优先保留高相关性chunk。
• 幻觉抑制：在系统指令中明确禁止编造数字、日期、人名；对数值类问题，要求答案必须带原文引用（如“12.8亿元（来源：2023年报 P12）”）。

避坑指南：

• 注意：不要用“请用简洁语言回答”这类模糊指令。某次用户问“解释区块链原理”，模型答“去中心化账本”，过于简略。改为“用不超过3句话，面向非技术人员解释，包含‘分布式’‘共识机制’‘不可篡改’三个关键词”。

• 提示：生成器必须输出结构化JSON。我们约定schema：{"answer": "string", "sources": [{"source_id": "xxx", "page_num": 12}], "confidence": 0~1}。前端据此渲染高亮和溯源，而非解析纯文本。

• 实测心得：LLM选型影响巨大。Qwen2-72B在中文长文本理解上优于Llama3-70B，但Qwen2对数值敏感，Llama3更擅长逻辑推理。我们按问题类型路由：数值类走Qwen，流程类走Llama，混合型用ensemble。

4. 模块图驱动的RAG开发流程：从画图到上线的7步法

4.1 第一步：用模块图定义验收标准，而非功能清单

传统需求文档写“支持文档上传、问答、溯源”，但模块图要求明确每个模块的SLA：

• 文档预处理：PDF平均处理时间≤3秒/页，表格识别准确率≥90%
• 检索器：95% query的top-5召回率≥85%，P95延迟≤200ms
• 生成器：答案准确率（人工评估）≥92%，幻觉率≤3%

这些指标直接对应模块图上的节点。某次客户要求“提升问答准确率”，我们先检查模块图，发现重排序器无SLA，于是补上“top-5相关性≥0.85”，并针对性优化。

4.2 第二步：模块并行开发，用契约驱动联调

各模块按Schema并行开发：

• 预处理组输出符合DocumentSchema的JSON
• 切块组接收该JSON，输出ChunkSchema数组
• 索引组建接收ChunkSchema，输出索引文件+MetadataDB

联调时，用Postman模拟模块间调用，验证输入输出是否严格符合Schema。某次切块组未按约定返回hierarchy_level字段，索引组直接报错，而非静默失败——契约让问题暴露在开发早期。

4.3 第三步：模块灰度发布，故障隔离

上线不整体发布，而是按模块灰度：

• 先发布预处理模块，流量100%走新OCR，旧版备份
• 再发布切块模块，用A/B测试对比新旧切块策略的召回率
• 最后发布生成器，用canary发布，5%流量走新提示词

某次新重排序器上线，发现QPS下降，立即切回旧版，其他模块不受影响。模块图让故障域清晰可见。

4.4 第四步：用模块图做根因分析，而非日志大海捞针

当用户反馈“答案错误”：

1. 查生成器日志：输出答案及sources字段
2. 若sources为空，查检索器日志：是否召回0结果
3. 若召回但sources未命中，查重排序器：是否分数过低被过滤
4. 若重排序器输出正常，查预处理：是否该段落被清洗掉

某次问题定位仅用12分钟，而过去平均需3小时。

4.5 第五步：模块性能压测，找到系统瓶颈

对每个模块单独压测：

• 预处理：模拟100并发PDF上传，观察CPU/内存
• 检索器：用locust模拟1000QPS，测P95延迟
• 生成器：测不同上下文长度下的token生成速度

某次压测发现索引模块在100并发时，SQLite锁等待超时。解决方案：将元数据索引迁至Redis Hash，QPS提升至2000。

4.6 第六步：模块健康度巡检，防患于未然

每日自动执行：

• 预处理：抽检10份PDF，验证表格识别准确率
• 索引：计算索引碎片率，>15%触发优化
• 检索器：用黄金query集测试召回率，波动>5%告警

某次巡检发现OCR字典版本异常，提前2天发现潜在风险。

4.7 第七步：模块图版本管理，让演进可追溯

模块图不是静态图纸，而是活的文档：

• 每次模块升级（如换embedding模型），更新模块图并标注变更点
• 用Git管理模块图源文件（Mermaid代码），与代码库同版本
• 发布时，模块图版本号与服务版本号一致（如v2.3.0）

某次回滚，我们不仅回滚代码，还同步回滚模块图，确保文档与系统一致。

5. 常见问题与排查技巧实录：来自27个项目的血泪经验

5.1 问题：召回结果相关性低，但向量距离分数很高

现象：用户问“2023年净利润”，检索返回“2022年净利润”段落，向量分0.82（满分1.0）。

排查路径：

1. 检查切块模块：是否将“2022年”和“2023年”切在同一chunk？若是，说明切块策略未识别年份边界。
2. 检查embedding模型：用bge-m3的dense模式，但未启用colbert稀疏向量。改为多向量检索，colbert分对年份更敏感。
3. 检查检索器：是否启用了查询改写？原query“2023年净利润”被改写为“净利润 数值 年度”，丢失了年份限定。

解决方案：在查询改写模板中增加年份提取规则，对含“年”字的query，强制添加year_filter参数。

5.2 问题：生成答案格式混乱，时而带来源，时而不带

现象：同一问题，有时答案末尾有“（来源：年报P12）”，有时没有。

排查路径：

1. 检查生成器模块：是否所有上下文chunk都带source_id和page_num？发现预处理模块对扫描件PDF未填充page_num。
2. 检查提示词：系统指令要求“必须带来源”，但未定义缺失时的fallback行为。
3. 检查模块图：元数据路由枢纽未配置page_num必填校验。

解决方案：在预处理模块增加page_num兜底逻辑（扫描件按图像顺序编号），并在元数据路由枢纽添加Schema校验。

5.3 问题：系统QPS突然暴跌50%，但各模块监控均显示正常

现象：CPU、内存、延迟指标均在阈值内，但整体吞吐量腰斩。

排查路径：

1. 检查可观测性枢纽：发现重排序器调用次数激增，但成功率从99.9%降至82%。
2. 深入重排序器日志：大量CUDA out of memory错误，但GPU显存监控未报警。
3. 检查模块图：重排序器依赖的GPU节点未配置显存限制，新任务抢占全部显存。

解决方案：在Docker Compose中为重排序器服务添加nvidia.com/gpu: 1和mem_limit: 8g，并启用显存回收。

5.4 问题：新增文档后，老问题答案变差

现象：加入2024年Q1财报后，“2023年营收”问题答案出现矛盾数据。

排查路径：

1. 检查索引模块：新增文档是否覆盖了旧索引？发现索引重建脚本未清理旧索引文件。
2. 检查检索器：是否启用了时间过滤？未启用，导致新旧财报混检。
3. 检查模块图：元数据路由枢纽未暴露publish_date字段供过滤。

解决方案：索引脚本增加--clean-first参数；在检索器接口添加date_range参数；在模块图中标注publish_date为必传元数据。

5.5 问题：用户点击“查看来源”后，高亮位置偏移

现象：答案中标注“（来源：年报P12）”，但点击查看时高亮在P13。

排查路径：

1. 检查预处理模块：OCR识别的page_num是否与PDF物理页码一致？发现PDF有封面页，OCR从第1页开始计数，但PDF元数据从第3页开始。
2. 检查切块模块：char_offset计算是否基于OCR文本而非原始PDF？是，导致偏移。
3. 检查生成器：是否将page_num和char_offset准确传递给前端？

解决方案：预处理模块统一使用pdfplumber获取物理页码；切块模块用pdfplumber的chars坐标计算char_offset；生成器输出{"page_num": 12, "char_start": 1234, "char_end": 1289}。

6. 模块图之外：RAG系统演进的三个务实方向

模块图解决了“怎么做”，但RAG的价值不止于此。基于项目实践，我认为下一步该聚焦三个不炫技但真落地的方向：

第一个是RAG与工作流的深度耦合。现在RAG多是问答界面，但业务系统需要嵌入式能力。比如CRM系统中，销售在录入客户信息时，RAG模块自动检索历史相似案例，弹出“该客户行业常见痛点：XXX”，并带来源链接。这要求RAG模块提供轻量级SDK，而非HTTP API。我们已封装Python SDK，支持rag.search(query, context={"user_role": "sales"})，context参数驱动权限过滤和结果排序。

第二个是RAG的主动学习闭环。用户不点击的答案、人工修正的答案、客服标记的bad case，都应自动进入训练数据池。我们设计了“反馈路由模块”，当用户点击“答案有误”，前端发送{"query": "...", "feedback": "wrong", "correct_answer": "..."}，由该模块清洗后存入数据库，每周触发一次微调任务。3个月后，人工修正率下降40%。

第三个是RAG的成本精细化治理。LLM调用、向量计算、OCR都是成本大户。我们给每个模块打标：cost_tier: high/medium/low，并配置预算策略。例如，对cost_tier: high的重排序器，当月预算超80%时，自动降级为bge-reranker-base；对cost_tier: low的预处理，允许并发提升至200。成本仪表盘直接关联模块图，哪个模块烧钱最多一目了然。

这些都不是PPT里的“未来展望”，而是我们正在交付的客户功能。模块图的意义，就在于让这些演进不是空中楼阁，而是可规划、可拆解、可验证的模块升级。当你能把“支持主动学习”拆解为“新增反馈路由模块+修改元数据枢纽+扩展可观测性枢纽”，你就真正拥有了RAG系统的掌控力——不是调参的熟练工，而是架构的决策者。

我在实际操作中发现，画模块图最耗时的不是技术，而是和业务方对齐“每个模块到底要解决什么问题”。有次为医疗RAG画图，医生坚持“症状描述”和“诊断结论”必须分属不同模块，因为临床路径中这两步由不同角色完成。这个细节让我们避开了后续因职责不清导致的流程阻塞。所以，模块图首先是沟通工具，其次才是技术蓝图。

本文还有配套的精品资源，点击获取