RAG 上线只是起点：生产环境长期维护难题的拆解清单
打开任意一篇 RAG 教程，内容大多止步于"跑通"：数据加载、分块、嵌入、入库、检索、生成，运气好再加上混合检索和重排序。至于系统上线三个月、六个月后会发生什么，很少有人说得清楚。而现实是，RAG 系统与静态软件不同，它会持续与不断演变的数据、模型和用户期望交互------这是 ApX《RAG系统维护 | 长期难题》一文的核心论点：初始部署通常只是漫长运行周期的起点。
本文换一个少被写的视角，把"部署之后"的问题逐项拆开：每项给出它的成因、可执行的维护动作、适用范围与局限。文章对照 Datawhale all-in-rag 教程的章节结构（其第四部分"生成与评估"包含第六章"RAG系统评估"，覆盖评估方法论与工具），补上"从跑通到养得住"之间那段空白。
一、知识库漂移：语料不是一次性资产
知识库是 RAG 系统的核心，但文档集合、数据库或网页内容很少是静态的------新信息不断产生，旧数据过时，相关性也在转移。ApX 的资料给出了一个很实在的成本视角：如果每月重新嵌入整个 10TB 知识库需要 24 小时的 GPU 时间，这就是一项可预测的运营开销，应计入总拥有成本（TCO）。
可决策的维护项：
- 分层更新策略：不必全量重建索引。区分"高频变更区"（如政策、价格、产品文档）和"稳定区"（如历史归档），前者走增量嵌入与增量入库，后者按季度或年度批量刷新。
- 过期内容下线机制：很多团队只管"加文档"，不管"删文档"。旧版本文档留在库里，检索阶段仍会被召回，直接污染答案。建议给文档加版本字段或生效日期，检索时过滤。
- 把重嵌入成本写进预算：换嵌入模型意味着全量重嵌入，这不是技术决策而是财务决策。选型时就要把未来的重嵌入成本算进去。
适用范围与局限：增量更新适合文档天然带时间戳的场景；对于语义高度纠缠的语料（如维基式互相引用的内容），局部更新可能导致索引内部一致性变差，需要定期全量校验。ApX 资料中"漂移随时间推移拉大用户意图与输出之间的差距"这一提醒，适用于所有知识库------问题不在于漂移会不会发生，而在于你能不能察觉。
二、模型退化与漂移：两个模型，两套风险
RAG 至少依赖两类机器学习模型：检索用的嵌入模型和生成用的 LLM。两者都会随时间发生某种形式的漂移。嵌入模型的漂移尤其隐蔽：供应商悄悄更新了模型权重或 API 版本，你的新查询向量和旧索引向量就处在不同的语义空间里，检索质量无声下滑------没有报错，只有召回率慢慢变差。
可决策的维护项：
- 锁定模型版本：嵌入模型和 LLM 都显式固定版本号，不使用"latest"。升级是显式的、有回滚方案的变更。
- 建立金标准查询集：维护一组固定的查询---期望结果对，每次模型或索引变更前后跑一遍，对比检索命中情况和答案质量。这是察觉漂移最便宜的手段。
- 变更隔离测试：换嵌入模型必须重嵌入整个库，且新旧索引要能并行比对一段时间。
适用范围与局限：金标准集适合查询模式相对稳定的内部系统；用户查询分布变化快的 ToC 场景，还需要结合线上采样来更新评估集，否则金标准本身也会过时。
三、依赖网扩张：组件各自发版
ApX 的资料指出，生产 RAG 系统很少是单一系统，而是相互关联的组件生态：框架、向量数据库、嵌入服务、LLM 服务、文档解析器......这些依赖中的每一个都有自己的发布周期、潜在的 API 变更、安全漏洞和性能特征。
可决策的维护项：
- 依赖锁版本 + 升级窗口：像对待普通后端服务一样对待 RAG 依赖。升级前在隔离环境跑完整评估，不追新版本。
- 关键路径去耦合：嵌入和生成尽量通过自建抽象层调用，供应商 API 变更时只改适配层。
- 关注安全通告：向量数据库和文档解析器（尤其是处理不可信 PDF 的组件）是容易被忽视的攻击面。
局限：完全冻结依赖会在安全补丁上出问题，可行的折中是"安全补丁随升、功能升级走评估流程"。
四、评估指标随规模失效
IBM 的《RAG 问题仍然存在。以下是 5 种解决方法》从修补角度列出了多种方案，例如把 Text2SQL 用于聚合类查询------SQL 内置聚合函数、处理容量远大于大模型上下文窗口，将"去年发票总额是多少"这类查询转成 SQL 经数据库计算后再交给模型做自然语言处理。这类方案的选择本身说明：没有一劳永逸的架构，问题会随数据和规模演变。
这与 ApX 的观察一致：随着系统成熟、使用模式演变，启动时建立的指标和监控策略可能不足；对 1,000 用户和 10,000 文档有效的方法，在 100,000 用户和 1,000 万文档的负载下可能力不从心。此外用户期望也在变------他们会发现新的应用场景，或要求更高的复杂程度。
可决策的维护项：
- 指标分层：启动期看端到端准确率，成熟期要看检索命中率、答案忠实度、延迟分位数、单位查询成本各自的趋势，而不是单一指标。
- 按查询类型路由：聚合统计类问题走 Text2SQL，事实类走向量检索，关系类可考虑 GraphRAG。IBM 资料提到，微软研究院 2024 年提出的 GraphRAG 用知识图谱（节点为实体、边为关系）处理关联识别问题，适合"复杂病史"这类多实体多关系的查询；但 Nirmal 也指出其局限------数据量增长时图谱渲染难度显著增加，映射数十万个节点远比几十个复杂。所以图结构化方案要评估语料规模再上。
- 定期重跑评估：Datawhale all-in-rag 教程第六章把"评估方法论"与"评估工具、常用指标"单列成章，说明评估不是一次性验收动作；生产环境应把它变成周期性任务。
局限：自动化评估指标（如基于另一个 LLM 的评分）本身有噪声，趋势比绝对值更可信；评估集需要随业务演进人工维护，这部分工作量常被低估。
五、文档与知识转移：最软也最致命的一环
ApX 资料把最后一条归为"技术性不那么强但同样重要的难题"：维护全面的文档，并确保团队成员变动时的知识转移。原文说得直接------一个只有一两个人了解的 RAG 系统是脆弱的。
可决策的维护项：
- 把决策写下来：为什么选这个分块策略、为什么锁定这个嵌入版本、金标准集怎么用------这些"为什么"比代码本身更容易随人员流动丢失。
- 评估集与监控面板即文档：一个能跑的金标准查询集和一张趋势面板，是新人理解系统行为最快的入口。
- 至少两人懂系统：RAG 系统横跨数据、检索、模型三层，单人维护意味着任何一层出问题都是单点故障。
结语
把五项排一下优先级：如果只能先做一件事，做金标准查询集------它是知识库漂移、模型漂移、依赖升级三项风险共同的探测器。其余各项再按语料变更频率和团队规模逐步补齐。RAG 的"从跑通到养得住"，本质上是从一次性的工程交付，转向一套持续运行的数据与模型运维流程。这个视角在现有教程里篇幅很少，但恰恰是生产环境里花时间最多的部分。
参考资料：ApX《RAG系统维护 | 长期难题》、IBM《RAG 问题仍然存在。以下是 5 种解决方法》、Datawhale all-in-rag 教程（GitHub 仓库及其第六章"RAG系统评估"）。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。