从RAG到微服务：在线教育AI助教系统面试实战全解析

1. 面试开场这个AI助教项目到底想解决什么问题先交代一下背景。去年我面试某在线教育公司的高级后端岗位技术面一共四轮其中一轮完全是围绕项目展开的深挖。面试官是AI平台组的负责人上来第一句话不是让我自我介绍而是直接抛了个场景“我们准备给录播课和直播课配一个AI助教学生可以随时提问要求答案必须基于课程内容本身不能瞎编。你如果是这个系统的负责人第一步会做什么”这个问题看似开放其实考察的是你对“在线教育AI助教”这个场景的理解深度。我当时的切入点选择了先定义问题边界而不是急着聊技术选型。原因很简单如果你连“学生问的是什么类型的问题”、“答案来源在哪里”、“多高的准确率算达标”都没想清楚后面无论选微服务还是RAG都是空中楼阁。在线教育平台的提问场景大致分三类。第一类是课程知识类比如“傅里叶变换的物理意义是什么”、“这题为什么选C”这类问题答案就藏在课件、讲义、题库里。第二类是教务规则类比如“退课截止时间是什么时候”、“补考怎么申请”这类信息通常在官网FAQ和管理后台。第三类是通用闲聊类比如“帮我写个情书”、“推荐一本小说”这类问题跟课程毫不相关。面试官想要的AI助教显然只负责前两类第三类要么转人工要么礼貌拒绝否则AI就成了聊天机器人偏离了“助教”的定位。这个定义的直接后果是答案必须可追溯、可验证、基于私有知识库——这恰恰是RAG检索增强生成的主场。同时这个AI助教并不是一个独立孤岛它要嵌入到已有的课程系统、订单系统、用户系统里这就绕不开微服务的协作问题。换句话说面试官真正想考察的是你能否把一个大模型能力体面地塞进一套复杂的分布式系统里同时保证回答质量、响应速度和运维可控。我当时的回答分三步第一步梳理出知识库的来源和类型也就是课件、题库、公告、FAQ四大类第二步设计RAG问答链路让答案必须引用知识库片段引用不了就如实说不知道第三步把助教能力拆成独立的服务以微服务的形式对接现有业务系统。面试官听完点点头然后开始层层追问。以下内容就是我结合这次面试以及后续复盘整理出来的完整思路涵盖微服务拆分、RAG问答链路、性能优化、以及面试中的高频追问希望能给正在准备相关内容面试的同行一些参考。2. 微服务拆分AI助教的服务边界到底切在哪2.1 先厘清一个误区AI能力不等于一个服务很多人一听到“AI助教”下意识就觉得应该做一个“AI助教服务”把所有逻辑都塞进去。这是典型的单体思维。我问你学生提问后系统要先做权限校验判断这个学生有没有购买这门课然后要做课程映射把提问关联到具体课程和章节接着要调RAG链路检索知识库最后要拼装Prompt调大模型接口。如果全塞在一个服务里这个服务同时承担了业务逻辑、检索逻辑、模型调用逻辑三者的升级频率和故障半径完全不同。试想一下大模型供应商升级模型需要重新发布Prompt模板课件更新需要刷新向量索引课程购买状态变化需要调整权限规则——这三件事如果耦合在一个服务里每次改动都要全量回归出问题都得一起重启。所以拆分的第一原则是按变更频率和故障边界划分而不是按“功能名字”划分。我给出的拆分方案是四个服务。第一个是助教网关服务负责会话管理、权限校验、提问前置校验、限流熔断它是整个AI助教能力的统一入口。第二个是知识库RAG服务负责文档解析、向量化、检索、重排它只处理“给定问题返回相关片段”这一件事。第三个是问答编排服务负责把用户问题加工成Prompt、调用大模型、做后置校验、整理引用来源这是业务逻辑的核心。第四个是课程上下文服务负责拉取学生当前学习的课程、章节、最近观看进度把这些动态信息拼进Prompt里让回答更有针对性。面试官问了句“四个服务是不是太多了有些功能合并行不行”我当时没有妥协而是解释了这么拆的原因。RAG服务和编排服务恰恰最容易被人合并但这两者的性能特征完全相反RAG是IO密集型大量时间花在向量检索和数据库查询上编排服务是外部依赖密集型大部分时间在等大模型返回。合并之后一旦大模型接口超时RAG的检索线程池也会被连带拖垮故障直接扩散。拆开之后至少可以保证即使大模型服务抖动检索链路依然健康知识库更新也不受影响。2.2 服务间通信选型同步接口还是异步消息在线教育场景有一个特殊矛盾学生提问在情绪上期望秒回但大模型生成内容至少需要几秒。如果做成完全同步的请求-响应模式前端一直转圈用户体验很差而且HTTP连接长时间占用也会浪费网关资源。如果做成纯异步又会让学生觉得没人搭理。我当时的选型是提问入口走同步接口前端拿到“已受理”的回执真正的问答过程异步执行结果通过WebSocket或者轮询推送给学生。这种模式在业内叫“异步任务状态查询”既不阻塞提问请求又能优雅地处理长耗时推理。这里有个容易被忽略的细节异步任务的消息体里该放什么。很多人图省事只放一个userId和question等消费端再去查上下文结果消费端不仅要查课程上下文还要回查用户权限链路被拉得很长。我的习惯是消息体里直接带上完整的上下文信息——用户ID、课程ID、章节ID、问题文本、提问时间戳甚至带一个traceId。消费端拿到消息就能直接开始RAG检索和Prompt编排不需要再回查业务库整个链路的延迟和失败率都会降下来。2.3 数据一致性一个容易被追问的埋点面试官问到“课程下架了但学生之前收藏的提问记录还在你怎么处理”的时候其实是在考察分布式事务意识。助教问答记录、课程状态、知识库版本之间存在天然的不一致窗口学生提问时引用了某一版课件的片段但第二天课件更新了历史记录里引用的内容可能已经不存在了。我的方案是问答记录表里不存引用文本本身而是存知识库片段ID、文档版本号、以及引用片段的快照文本。这样即使课件后续改版历史对话依然能完整还原当时的回答依据。这个设计说白了就是“快照隔离”回答结果一旦生成就和当时的证据绑定不允许事后漂移。面试中对这种细节的考量其实能拉开候选人的差距。3. RAG问答链路从文档入库到答案生成3.1 离线知识库管线课件不是拿来就能用的面试官的问题很直接“你的RAG知识库数据从哪来怎么处理的”这个问题背后隐藏着大量实操坑。课件最常见的格式是PPT、PDF、Word但PDF在在线教育里往往是灾难——很多PDF是从PPT直接导出的没有文本层复制出来全是乱码还有些课件里嵌了大量图片架构图和公式截图纯文本提取后会丢失大量信息。我设计的离线管线分五个环节格式解析、内容清洗、结构化切分、向量化入库、元数据标注。格式解析阶段PDF优先用支持OCR的方案处理先探测是否有文字层没有文字层就自动走OCR识别。PPT则按页解析保留每页的标题层级关系这样切分的时候可以依据标题边界而不是粗暴按固定长度切。Word文档要注意处理页眉页脚和目录信息这些内容会严重干扰切分质量。内容清洗阶段要去掉导航文字、版权页、重复的页眉信息还要处理乱码。一个非常隐蔽的坑是某些课件里含有日期、页码、讲师姓名等高频重复词如果不做清洗检索时会出现“问题不相关但片段分数很高”的异常结果。切分策略我采用了“固定窗口重叠”的方式。以300个token为块大小50个token为重叠窗口。为什么要重叠因为如果一个知识点刚好被从中间切断两边的语义都不完整检索召回时很难命中完整信息。重叠窗口相当于给图片加了边框确保关键信息要么完整落在前一块要么完整落在后一块。块太大召回精度低块太小上下文不足300/50这个比例是我在多个文档集上试出来的折中方案。3.2 混合检索与重排向量检索不是万能的只做向量检索在在线教育知识库场景下会翻车原因很简单课件里的专业术语太多而且很多学生提问用的是口语化表达。比如课件里写的是“拉格朗日中值定理”学生问的是“那个中间点的定理叫什么来着”——这个提问和原文本在字面上几乎无重叠但语义向量能拉近两者的距离。反过来也有问题。“导数”这个词在高等数学课程里和金融课程里含义完全不同纯靠向量会混淆学科边界。所以我的方案是向量检索语义召回关键词检索字面召回并行两者结果合并后统一送进重排模型。重排环节用交叉编码器对候选片段逐条打分分值高的才进入最终结果集。这里给一个参数上的参考向量检索召回Top 50关键词检索召回Top 30两者合并去重后送重排重排只保留Top 5作为上下文喂给大模型。关键词检索别用太复杂的实现因为课件文本千奇百怪简单的分词加上BM25足够解决80%的问题。面试官很自然会问“你的向量化模型用的什么”我说了Embedding模型的名称后他追问了一句“你们有做过领域微调吗”这个问题其实是个分水岭。我当时实话实说通用Embedding在专业课件上效果够用但如果有条件可以准备一批课程领域的问答对用对比学习对Embedding做增量微调。如果资源有限一个更省事的技巧是在索引侧做同义词扩展把“定理”和“公式”、“推论”这类近义词通过词典映射扩充后一起检索也能明显提升召回率。3.3 RAG知识库能不能存图片一个必须正面回答的问题面试官问了热搜上经常出现的那个问题“你的RAG知识库能存图片吗”这个问题其实是个陷阱——如果你回答“不能”说明你没处理过真实课件如果你回答“能把图一起喂给视觉模型”说明你不懂成本控制。真实情况是RAG知识库的核心存储对象是文本块和向量图片不能直接作为检索单元。但课件的图片信息又不能完全丢弃尤其是数学公式的推导截图、流程图、数据表格这些往往是考试重点。我的处理方式分为三层。第一层含文字的图片比如PPT里的截图、扫描版题的题干通过OCR提取文字后把文字作为检索内容图片本身作为展示素材存储检索命中后一并返回图片URL。第二层架构图和流程图OCR提取不出有效文字这种情况下要么人工编写图片的语义描述一份课件正常控制在200字以内要么调用多模态模型生成图片摘要摘要文本参与向量化检索。第三层公式和代码类内容采用Latex和代码文本化存储避免识别误差。所以准确的回答是RAG知识库的检索索引存文本和向量图片以“元数据关联语义描述”的形式被间接检索。学生看到的答案里可以带图但图不是被“检索”出来的而是命中文本片段后关联出来的。这个思路既保住了检索效率又不丢失课件里的多模态信息。3.4 在线问答编排把检索结果变成一段好的回答检索到的Top 5片段不等于答案。编排服务要做的是把用户的提问、课程上下文、检索片段一起塞进Prompt模板让大模型基于这些材料生成回答。我分享一个经过多轮调试的Prompt模板骨架实际项目中会按业务细化你是在线教育平台《{课程名}》的AI助教当前学生正在学习第{章节名}。 请只基于以下【知识片段】回答问题不要使用片段之外的知识。 如果片段不足以回答请明确回复“当前课程资料中未找到相关信息”。 【知识片段】 {片段1} {片段2} ... {片段5} 学生提问{question} 要求 1. 答案中涉及观点的部分必须在句末标注引用片段编号如[1][3]。 2. 如果学生问题是闲聊或与课程无关请礼貌表示无法回答。 3. 回答请控制在200字以内但不要丢失关键推导步骤。为什么要把课程名和章节名写进Prompt因为很多人做RAG只注重检索片段忽略了“系统身份”的加持。带上课程上下文之后大模型的输出会更加贴合教学语气——比如学生问“这个公式怎么推”如果上下文里显示当前章节是微分方程大模型的回答方向就会自动聚拢到微分方程的推导路径而不是泛泛展开。面试官紧接着追问“如果检索到的知识片段本身有冲突怎么办”这是个非常实际的问题。不同版本的课件对同一概念可能给出不同的定义或者往年试题和今年教材答案不一致。我的做法是在编排层加一个冲突检测当Top 5片段的主题聚类超过两个且观点方向不一致时优先信任版本新、来源权威的片段——比如教材优先于PPT最新年份优先于历史年份——同时答案中明确提示“不同资料对此存在不同表述”。这个设计在真实场景中非常加分因为它体现了你对答案质量的敬畏而不是无脑拼接。4. 性能与稳定性课堂高峰期的系统扛得住吗4.1 缓存层设计同样的题别让模型答两遍在线教育的流量高峰非常集中晚上8点到10点是直播课高峰期考前一周是提问暴雨期。同一道题可能在短时间内被成百上千个学生提问如果每次提问都走完整的RAG链路和大模型推理成本根本压不住。我的方案是三层缓存。第一层结果缓存对“问题文本归一化后的哈希值”做缓存同样的题目在有效期内直接返回历史答案。这个方案的关键在于文本归一化——需要去掉标点、统一大小写、去除语气词如“请问”、“老师那个”才能让“老师这道题怎么做”和“这道题怎么做”命中同一个缓存键。第二层检索缓存如果问题本身是新的但检索出的Top 5片段和最近某次查询高度重合直接复用检索结果省去重复向量计算。第三层片段级缓存高频片段的向量预先加载在本地内存不走向量数据库网络请求。缓存TTL怎么定结果缓存我设了7天因为课程知识在一段时间内是稳定的检索缓存只设10分钟因为知识库可能随时更新片段缓存常驻内存但通过版本号控制失效。面试官很吃这套分层设计因为它展示了你对不同缓存维度的颗粒度把控能力。4.2 限流与降级大模型抖动时不能拖垮主站大模型是外部依赖不是自建服务——这句话一定要在面试中说清楚。外部依赖就要按供应链的思路管理。我设计了三级降级路径大模型服务不可用则降级为直接返回检索到的Top 1片段原文保证学生至少能看到知识点RAG服务不可用则走关键词检索兜底只返回相关课件原文不做总结两者都不可用则返回引导语让学生转人工或稍后再试。限流策略上按请求路径分别限流。网关层按用户限流每个用户每分钟最多提问10次问答编排层按大模型供应商的配额限流设置令牌桶检索层按QPS限流保护向量数据库。之前有人质疑过限流对用户体验的影响我的答复是宁可让学生排队等3秒也不能让请求洪峰把系统打挂。在线教育的峰值流量是窗口期性质的熬过晚上的高峰整个系统就恢复正常了。4.3 可观测性回答质量问题怎么监控回答质量不是纯技术指标但技术手段可以辅助观测。我给系统加了几个关键指标检索命中率Top 1片段的相关性评分高于阈值的比例、答案引用覆盖率答案中有引用标注的比例、兜底触发率触发“未找到信息”的比例、大模型调用延迟P99、整体链路P95。最实用的一个指标是“无引用回答占比”。如果这个值突然升高说明大模型开始自由发挥了答案脱离知识库约束。这是RAG系统最常见的漂移信号。面试官听完这个指标之后明显态度好了不少因为多数候选人只会聊“我用了LangChain接了个向量库”很少有人真的考虑过在运行态监测回答纪律。线上监控方案用Prometheus采集指标Grafana做大盘配合日志平台的trace查询。每个问答请求都带traceId链路从网关到编排到大模型到向量库全部贯穿出问题时能够一键定位到具体卡点。5. 面试高频追问实录与复盘避坑5.1 面试官常问的五个刁钻问题以下是我在这次面试和以往面试中整理的高频追问每个都有完整的回答思路。第一个“如果你的知识库更新了旧答案缓存怎么处理”这里考察缓存一致性的理解。思路是知识库更新后更新操作会向Redis发一条版本失效消息所有依赖旧版本片段的缓存项整体失效同时预热新版本的高频问答对。处理时要注意顺序——先切读新版本索引再清理旧缓存否则会有短时间的不一致。第二个“学生对答案不满意这个反馈闭环怎么做”思路是前端加“踩一下”按钮被踩的问答对会回流到标注池由教研老师人工复核。复核结果进入两条路径路径A是答案本身有问题直接修正知识库片段路径B是检索不到合适内容则补充切分成新的知识片段重新入库。这个闭环虽然朴素但它是RAG系统持续改善的生命线。第三个“大模型生成的答案有误导信息你觉得根因是什么”不能只答“模型幻觉”。要有归因分析可能是切分粒度问题导致片段上下文不足可能是检索召回错误导致喂错了材料也可能是Prompt里没有约束“知识库外不许回答”。我当时的回答是三层归因——检索层、上下文层、指令层每一层都有对应的缓解手段。第四个“向量数据库怎么选型你对比过哪些”这是个开放式问题但要显示出真实对比过。我从运维成本、检索性能、过滤能力、生态兼容几个维度横向比较了几种主流的向量数据库方案最终给出结论在线教育场景数据量在千万级以内自建开源方案完全够用商业产品在数据量极大或需要高级过滤时有优势但带来了额外成本性价比不高。第五个“如果学生异地跨时区提问延迟要求有变化吗”这个问题考察全球化意识。思路是如果服务部署在单一地域跨地域的链路延迟是大头。方案是在不同区域部署检索实例向量数据做区域化副本同步大模型调用走区域就近接入。在线教育海外业务逐渐起量后这个问题就成了必备考量。5.2 复盘我踩过的坑和经验教训面试前我花了两个晚上整理项目复盘笔记有几个坑值得单独拿出来说。最让我印象深刻的是切分粒度的教训。有个知识点的内容横跨了5页PPT如果按页切分每个片段都只是这个知识点的一小段检索时单看哪个片段都不完整大模型回答出来必然残缺。当时为了应付上线匆忙切分策略做得粗糙后续被教研团队反馈“AI回答的知识点讲一半就断了”。后来我把PPT的父子标题关系利用起来跨页合并同主题内容这个现象才彻底消失。这个坑建议所有做RAG的同行都记一下切分之前一定要看文档结构纯按字数是懒人做法。另一个教训和Prompt有关。早期我设计的Prompt里写着“请尽量回答”结果大模型在检索不到知识时也硬凑内容几乎每5条回答里就有1条在胡编。后来把所有措辞全部收紧成否定约束——“不要使用片段之外的知识”、“无法回答时明确说不知道”——幻觉比例立刻下降了不止一个量级。这件事让我印象很深跟大模型沟通正向引导永远不如反向约束好用。第三个经验是面试表达方式上的。回答技术问题时答案的结构感非常重要。我习惯用“先说结论再讲关键细节最后提一嘴踩坑”的结构即“逻辑亮点体验”三段式。面试官问RAG处理流程时直接列五个环节显然没有记忆点但先抛出“PDF在在线教育课件里非常容易没有文本层OCR是避不开的”这个引子再展开管线效果就截然不同。面试本质上是一场信息密度的博弈你要把最有冲击力的信息尽量前置。5.3 这个项目的下一步扩展面试尾声面试官问了对未来的想法我把扩展思路讲得很务实第一增加基于课程图谱的引导式学习路径推荐学生提问后不仅给答案还告诉你该看哪几节前置课第二接入语音问答场景学生对着手机说题目ASR后走同样的RAG链路这对体育类课程操作演示的问答很有价值第三把“幻视”从模型层扩展到评测层制作标准测试集每次上线前自动跑评准确率、引用覆盖率、无引用比例等核心指标防止更新回归。这类扩展思路不需要落地实施但要让面试官看到你对技术方向的理解是系统性的而不是项目做完就结束了。面试官最怕雇来的人是“需求机器”你要让他看到你具备定义问题、规划演进的架构能力。5.4 最终的一点个人体会这次面试的整个过程让我更深刻地理解了一件事面试官真正想确认的是你是否真的理解RAG和微服务这两个技术栈在业务场景中的成败关键。RAG的关键是检索能不能找回正确的信息、找回后大模型能不能被约束在知识边界内微服务的关键是服务之间的故障隔离和协作效率。这两者融合起来的难点在于你需要同时具备知识工程、分布式系统、模型应用三方面的敏感度缺一不可。如果你也在准备类似的岗位面试我给的建议简单直接不要光看框架文档一定要亲手把课件从PDF变成知识库、再从知识库变成一条带引用的回答完整走一遍全链路。只有踩过“PDF提取出乱码”、“向量检索名次不对”、“大模型无视引用强行输出”这些坑之后你在面试时才能说出真正有细节感的回答——那些真实的东西在任何标准答案里都找不到。