一个 RAG Demo 往往只有几步上传文件切成 Chunk写进向量库然后在同一个接口里提问并生成答案。本机演示时这样很直观。可一旦真的有用户上传文档问题就出现了。复杂 PDF 解析可能持续很久某一页 OCR 失败部分 Chunk 已经写入用户却不知道任务进行到哪一步。与此同时在线问答要求尽快返回不能被后台解析占满资源。入库和问答使用不同资源面对不同失败追求的目标也不同。这就是 RAG 系统设计面试最常问的一类题一个可上线的 RAG 系统应该怎样拆离线入库、在线问答、数据存储、权限、降级和监控怎样形成闭环只画“文档、向量库、大模型”三格图通常接不住后续追问一份文档只解析了一半怎样恢复用户权限应该在哪一层生效向量服务或 Rerank 超时系统怎样降级线上答案错了怎样定位证据在哪一步丢失先把这道题答到 30 秒面试时可以先这样说我会把 RAG 拆成离线入库和在线问答两条链路。离线链路负责文件保存、格式路由、解析、清洗、Chunk、Embedding、批量入库、校验和版本发布每一步有任务状态与可恢复边界。在线链路从身份和租户范围开始完成 Query 处理、权限过滤、关键词与向量召回、融合、Rerank、证据门槛、上下文构建和流式生成。关系库存用户、文档版本和任务状态检索引擎存 Chunk 与向量原文件进入对象存储。失败时按模块重试或降级并用 Trace 串联问题、候选、模型和引用再把线上 bad case 加回评测集。画架构图之前先用五个问题检查设计离线与在线是否分开任务能否恢复数据职责是否清楚失败时如何收口线上错误能否回到测试集。为什么离线入库和在线问答不能混在一起离线入库追求的是完整、可恢复和可追踪。它要面对文件格式差异、OCR、表格、跨页内容、Chunk、Embedding 和批量写入。失败后需要知道停在哪一步能不能从中间继续已经写入的数据是否需要清理。在线问答追求的是低延迟、权限正确和证据可靠。它要在一次请求里完成 Query 理解、过滤、检索、排序和生成。用户已经在等待任何排队和重试都会直接影响首字响应。如果两条链路运行在同一个同步接口里上传一份复杂文档可能占用应用进程在线问答跟着变慢。解析失败也只能返回一个模糊错误无法继续处理。应用内部也要分层。以 FastAPI 为例入口注册不同路由router 负责接收请求和返回响应service 负责组织文件解析、检索和聊天流程database 模块负责知识库、会话与任务状态等持久化操作。HTTP 层、业务流程和数据访问各自有边界出错时才能知道该在哪一层重试或终止。离线入库与在线问答的目标差异离线链路优先保证完整和可恢复在线链路优先保证边界正确、低延迟和可降级。两条链路可以共享文档 ID、知识库 ID、Chunk Schema 和模型配置却应该有独立的任务队列、资源配额和监控指标。资源隔离不只是把代码放进两个目录。离线解析会消耗 CPU、内存、磁盘和模型调用在线问答则对排队和首字等待敏感。如果两类任务共用同一个无边界线程池集中上传文档时在线请求可能拿不到连接和执行槽。即使服务进程还活着用户体验也会持续下降。因此可上线设计要为两条链路分别设置并发入口和队列边界。离线任务超过处理能力时可以排队并向用户展示可理解的处理状态在线请求则应有更明确的超时和降级策略。这里不需要先承诺固定并发数必须先根据真实文件类型、模型服务和请求结构压测。还要考虑背压。上游持续接收上传解析速度却跟不上时系统不能无限创建后台任务。可以限制同一租户的待处理数量、暂缓接收新任务或把任务标记为等待资源。无论选哪种方式都要让状态可见不能接口返回“成功”以后把压力藏进一个不断增长的队列。资源配额也不能绕过业务边界。一个租户集中上传大文件不应把其他租户的在线问答全部拖慢。任务优先级、租户配额和取消能力属于运行策略具体值需要压测决定但“离线压力不能无限侵占在线资源”应当在架构阶段就明确。离线入库应该怎样拆一条清楚的入库链路可以分成九步。第一步上传校验。检查身份、知识库权限、文件类型、大小和重复提交。第二步保存原文件。先把原始内容写入稳定存储再创建文档记录和处理任务。第三步格式路由。PDF、Word、PPT、纯文本和扫描页进入各自解析器。第四步结构解析。提取文本、表格、图片、标题、页码和位置。第五步清洗与 Chunk。过滤无用内容保留语义边界和来源 metadata。第六步计算 Embedding。模型与维度要记录版本避免以后混用不同向量空间。第七步批量写入检索引擎。每个 Chunk 使用稳定 ID收集逐项错误。第八步完整性校验。核对预期 Chunk 数、实际写入数、失败页和索引状态。第九步发布文档版本。只有校验通过的新版本才对在线查询可见。文档从上传到版本发布的离线任务链解析成功不等于入库完成只有写入、校验和发布全部完成在线链路才应看到新版本。批量写入 Elasticsearch 时每个 Chunk 应带稳定的业务id写入时映射成 ES_id批量操作结束后还要逐项收集错误。稳定 ID 能帮助识别同一条内容但完整幂等还要回答重复上传怎样识别旧版本 Chunk 何时删除新旧版本切换是否会出现半成品重试是否会重复写入发布失败能否回滚。更稳的设计是把“处理版本”和“当前发布版本”分开。新版本在后台写完并校验再通过具备原子或幂等边界的状态切换对外发布失败时旧版本继续服务。这样即使一次写入只完成部分 Chunk半成品也不会进入在线检索。这次状态切换至少要守住四个不变量。第一同一个文档对在线检索只能有一个明确的当前版本。新版本没有通过校验以前查询仍然读取旧版本。第二新版本的 Chunk、向量和来源 metadata 必须属于同一处理版本。不能文字已经更新向量仍来自旧模型引用位置又指向另一份文件。第三发布动作完成后检索过滤、缓存和引用都要能够识别新版本。只切换数据库状态却没有处理旧缓存用户仍可能看到旧内容。第四清理旧版本不能早于发布确认。新版本切换失败时旧版本要继续服务切换成功后也可以保留一段可回滚窗口再按数据策略清理。具体保留周期需要结合存储成本和业务要求确定这里不能编一个统一天数。这些不变量比“是否使用某种消息队列”更重要。基础设施可以更换但半成品不可见、版本内数据一致、发布后依赖同步、失败时旧版本可用这四件事至少要在可控环境中覆盖关键失败路径确认异常行为符合预期。每个任务阶段要记录输入版本、开始与结束时间、输出数量、错误类型和重试次数。确定性错误比如不支持的格式或字段映射错误不应该反复重试暂时性网络超时才适合有限重试。文档任务需要怎样的状态机只有“处理中”和“已完成”两个状态很难描述真实入库过程。一份文档可以经历已接收、等待解析、解析中、等待向量化、写入中、校验中、待发布、已发布、失败和已停用。状态不一定使用这些名字但必须能回答当前停在哪一步、哪些产物已经生成、下一次从哪里继续。状态变化要由完成对应工作的服务写入不能在接口收到请求后就提前标成成功。每次变化记录任务 ID、文档版本、执行者、错误和时间重复回调时使用幂等条件避免状态倒退。失败也需要分类。可重试失败包括暂时网络错误、上游限流和短暂服务不可用。不可重试失败包括格式不支持、文件损坏、权限不足和 Schema 无法解析。前者进入有限重试队列后者直接等待人工处理或用户修正。取消任务时要清理尚未发布的临时 Chunk 和缓存但不能误删当前正在服务的旧版本。发布动作最好只切换一个明确的“当前版本”指针而不是边写边让在线流量读取。任务恢复还要验证依赖版本。解析完成后系统升级了 Embedding 模型恢复时不能直接把旧解析任务接到不兼容索引必须根据任务记录决定继续、重算还是废弃。状态机的价值不是多几个枚举值而是把恢复、重试、取消和发布变成可以验证的行为。没有它后台任务一旦中断团队只能靠查日志和手工删数据收尾。对用户而言状态还要转换成可理解的进度。对外状态应展示正在解析、等待校验或处理失败并说明能否重试而不是暴露内部服务名和堆栈。内部状态足够精细外部表达足够清楚两者通过稳定映射连接。在线问答链路应该怎样走在线请求的第一步不是 Embedding而是身份与范围。服务端从登录状态得到用户和租户确定可访问的知识库、文档和版本。权限条件要进入检索请求内部不能先搜全库再由前端隐藏不该看的结果。接下来才是 Query 处理。单轮问题可以直接进入检索多轮问题可能需要从历史中补全实体。无论是否改写都要保留原问题以便回退和审计。然后并行执行关键词与向量召回。一条完整的调用链可以这样拆get_filters把知识库 ID、文档 ID 和可用状态转成搜索条件get_vector生成向量表达式search组合文本与向量候选外层retrieval再完成重排、阈值筛选、分页和结果组装。这样拆的价值不是函数名好看而是权限、向量化、召回和后处理都有可记录、可测试的输入输出。检索结果不是最终答案。系统还要判断证据是否充分控制上下文数量保留来源再把问题与证据交给模型。模型生成后通过流式响应返回答案和引用。在线链路的每一步都应该在同一个 Trace 下留下输入与输出。出现错答时能够看到原 Query、改写 Query、权限过滤、候选原文、各类分数、最终上下文、模型版本和引用映射。数据应该分别放在哪里不同数据有不同访问方式不适合全部塞进向量库。关系数据库适合保存用户、租户、知识库、文档元数据、版本、任务状态和权限关系。这些数据需要明确约束、事务和按字段查询。对象存储或受控文件系统适合保存原始 PDF、PPT、图片和解析产物。原文件是重新解析和引用回跳的基础。检索引擎负责 Chunk 内容、分词字段、向量、来源 metadata 和可过滤字段。关键词、向量和结构化过滤都围绕它展开。缓存保存可重新计算、允许失效的数据比如 Query Embedding 或特定范围内的检索结果。缓存不是事实主存清空后系统仍然要能正常工作。日志与追踪系统保存处理过程和诊断数据但要控制敏感内容和访问权限。RAG 各类数据的存储职责矩阵原文件、业务状态、检索内容、缓存和 Trace 的生命周期不同不能因为都与 RAG 有关就放在同一套存储里。所有存储之间需要稳定 ID 关联。文档版本改变时检索 Chunk、引用、缓存和评测样本才能知道自己对应哪一版资料。稳定 ID 解决关联问题Schema 与模型版本解决兼容问题。Chunk 记录至少要能够追溯知识库、文档、文档版本、片段位置和处理版本。Embedding 模型或维度变化时不能把新向量直接写进旧索引并假设它们仍然可比较。更稳的做法是建立新处理版本或新索引完成重算和校验后再发布。解析器升级同样可能改变标题层级、表格结构和 Chunk 边界。即使原文件没有变化Chunk ID、证据位置和评测标注也可能失效。任务记录要保留解析版本与切分版本评测集则需要知道证据对应哪一版内容。Schema 变更要有兼容窗口。在线服务升级后如果只认识新字段而旧版本文档仍在服务查询就可能失败。可以让读取逻辑在过渡期兼容两版或先完成数据迁移再切换应用。选择哪一种取决于数据量和变更风险但不能让应用代码、索引和任务状态各自独立升级。版本字段不是为了让日志更完整而是为了支持三个具体动作判断任务能否从中间恢复判断缓存与引用是否已经过期判断一份失败结果能否在相同数据条件下复现。失败和降级应该怎样设计系统投入运行时失败不会只发生在大模型。Query 改写可能选错实体。可以回退原问题或者向用户澄清。Embedding 服务可能超时。如果系统同时有关键词路线可以在明确标记降级的情况下只使用 BM25但要重新应用证据门槛。向量检索可能失败。不能把空候选直接交给模型让模型凭自身知识回答内部资料问题。Rerank 可能超时。可以使用融合后的初排结果但要记录本次未经过精排并检查候选是否仍满足最低质量。模型服务可能限流或中断。系统可以返回已检索到的原文或者明确提示稍后重试不能伪造完整答案。引用核验失败时高风险事实应该删除、降级或拒答。这些降级动作要在响应和日志中可见。否则团队只看到“接口成功”不知道用户拿到的是完整链路结果还是某种备选结果。重试也必须有边界。网络抖动、临时限流适合有限重试并配合退避。格式不支持、权限不足、Schema 错误属于确定性问题重复执行只会制造更多日志和压力。写操作还要带幂等 ID。客户端超时后重复提交系统应能识别同一个任务而不是生成两份文档和两套 Chunk。四个 bad case系统设计最容易漏什么第一种文档显示“已完成”其实只写入了一部分解析得到一批 Chunk批量写入时某些项失败任务状态仍被直接改成完成。应核对预期数量、成功数量和逐项错误校验通过后才能发布。失败版本不进入在线搜索。第二种先搜全库再在前端隐藏后端检索已经拿到了其他租户内容即使前端不显示这些内容仍可能进入 Rerank、Prompt 或日志。权限必须在检索过滤里生效缓存键也要包含租户和知识库范围。第三种向量服务失败后直接让模型回答模型返回一段通顺答案接口状态还是成功用户无法知道它没有使用知识库。降级应该明确选择可用检索路线证据不足就拒答并在结果中标记本次链路状态。第四种只监控接口存活不监控答案服务没有报错延迟也正常但正确证据长期召回不到用户持续得到错误答案。系统指标和质量指标必须同时存在。固定回归集、线上 bad case 和引用检查负责发现“稳定地答错”。第五种发布新版本后缓存仍返回旧内容检索已经指向新文档答案缓存却没有版本信息用户继续看到旧规定。文档发布要触发缓存失效或把知识库与文档版本纳入缓存键。性能组件不能脱离数据生命周期。监控怎样覆盖系统和答案系统层要观察任务积压、解析失败、批量写入错误、各阶段延迟、模型 TTFT、超时、错误率、连接池、队列和资源使用。质量层要观察正确证据召回、第一条正确证据排名、无答案错误、引用是否支持陈述以及用户反馈。Trace 连接两层。每次请求使用一个 Trace ID从网关一路串到 Query 处理、过滤、检索、重排、Prompt、模型和引用。线上出现错误答案时可以先确认允许范围再看正确证据是否进入候选之后检查它有没有被截断最后检查模型怎样使用原文。如果正确证据根本没找到bad case 进入解析或检索回归集。如果证据已经在前面模型仍然错答则进入生成和引用回归集。可上线 RAG 的监控与反馈闭环线上 Trace 负责定位bad case 回归负责防止复发评测集再验证下一次改动是否真的有效。这才叫闭环。监控不是只画一张资源仪表盘而是让线上错误能够回到可执行测试。怎么验收一个“可上线”版本功能验收覆盖文档上传、解析、版本发布、检索、拒答、引用和多轮问答。故障验收主动注入解析失败、部分写入、检索超时、Rerank 超时、模型限流和客户端断线检查任务状态、降级行为和资源释放。权限验收准备不同用户和知识库确认检索候选、缓存、日志和引用都不会越界。性能验收分别测试离线任务吞吐与在线 TTFT观察稳定并发、突发流量和冷启动不使用没有压测依据的容量承诺。质量验收运行固定评测集比较 RecallK、MRR、无答案控制和引用正确性并按问题类型查看失败。恢复验收检查任务中断后能否从正确阶段继续新版本失败时旧版本是否仍然服务重试是否重复写入。所有验收都要绑定代码、模型、知识库和 Schema 版本。没有版本结果以后无法复现。验收记录还要能回答“失败以后系统留下了什么”。一次故障注入结束后应检查临时 Chunk 是否可识别任务有没有错误地进入已发布旧版本是否仍可查询重试是否创建了重复任务缓存与引用有没有指向不存在的版本。只看接口最终恢复不检查遗留状态下一次故障可能从这些脏数据继续放大。上线判断也不应该只有一个总开关。某个文档解析器暂时不支持复杂表格可以明确限制支持范围某个降级路线无法保证多段证据就应在证据不足时拒答。把边界写清楚并经过测试比为了“功能齐全”让所有输入都返回一个看似成功的答案更可靠。面试官继续追问怎么接为什么不用一套数据库保存所有内容用户权限、任务状态需要结构化约束原文件需要稳定保存Chunk 需要文本与向量检索缓存需要快速失效。访问方式和生命周期不同拆开更容易保证职责与恢复。文档更新时怎样避免半成品被搜索到新版本先在后台解析、写入并校验只有通过后才切换当前发布版本。失败时保持旧版本可用同时记录失败任务。向量服务挂了是否可以只用 BM25可以作为明确降级但需要重新检查证据门槛和适用问题。不能假设单路一定能覆盖所有 Query也不能隐藏本次降级状态。权限为什么不能在前端过滤因为未授权内容已经进入后端候选、排序、Prompt 或缓存。权限必须在数据访问和检索条件中生效前端只负责展示。怎么证明系统能扛住多少流量用与真实请求结构接近的压测报告硬件、数据规模、并发、TTFT、P95、P99、错误率和质量变化。没有压测记录时只能说明扩展设计不能承诺容量数字。最后把答案完整说一遍面试收尾时把“双链路、数据职责、失败闭环”连成一个完整系统我会把 RAG 拆成离线入库和在线问答两条链路。离线侧从上传、格式路由、解析、清洗、Chunk、Embedding、批量写入、完整性校验到版本发布每一步都有任务状态和可恢复边界。新版本只有校验通过后才对外可见失败时旧版本继续服务。在线侧先做身份和知识库范围校验再进行 Query 处理、过滤、关键词与向量召回、融合、Rerank、证据门槛、上下文构建和流式生成。数据职责也会拆开。关系库存用户、权限、文档版本和任务状态对象存储保存原文件检索引擎保存 Chunk、向量和来源 metadata缓存只保存可重建数据并带租户与版本。失败时按模块有限重试或降级证据不足就拒答不能在检索失败后让模型凭自身知识冒充正常结果。每次请求用 Trace 串联原 Query、改写、过滤、候选、分数、最终上下文、模型版本和引用。系统监控看任务、延迟和错误质量监控看 Recall、无答案和引用线上 bad case 再进入回归集。这样才能让功能、权限、恢复、性能和答案质量一起形成闭环。这道题真正考察的不是你能不能背出一串基础设施名字。一套可上线架构的底线是系统边界清楚失败时不留下半成品或越权数据线上一次错答能够被定位、复现并沉淀为后续回归样本。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】