RAG 系统工程化：让“能回答”变成“可运行”

一个演示型 RAG 往往只有上传、切块、向量化和对话四步。真正运行在企业环境后，还会遇到模型服务并发、文件失败重试、索引增量更新、上下文限制、权限隔离和版本回滚。工程化的目标不是把系统做复杂，而是让它在异常存在时仍然可预期。

服务边界要清晰

文件处理、检索、对话生成和管理后台应解耦。解析任务放到异步 Worker，模型推理服务通过稳定 API 暴露，知识库服务负责权限与索引，前端只展示状态和结果。这样某一类重任务堆积时，不会拖垮所有用户请求。

容量来自测量而非估算

要持续记录每类文件的解析时间、每页 token 数、嵌入吞吐、检索延迟、模型首 token 与完整回答延迟。并发数不能只看显卡利用率，还要观察队列长度、显存峰值和超时比例。基准测试应使用接近生产的长短混合请求，而不是只测一句“你好”。

每一层都要可降级

模型服务不可用时，可返回检索证据而不生成结论；重排序超时时，回退到基础混合检索；解析失败时，保留原文件并允许重试或人工导入。失败信息应面向运维和用户分别表达：前者需要错误码与日志关联，后者需要清楚的下一步。

把评测和观测接进发布流程

每次调整切分、模型、提示词或检索参数，都应跑固定问题集，比较证据命中率、答案质量与延迟。线上还要收集无答案率、引用点击率、用户纠错和失败任务分布。没有这些反馈，系统优化只能依赖直觉。

RAG 的工程质量体现在用户看不见的地方：它能处理慢文件、解释错误、保留证据，并在组件偶尔失效时保持基本服务。