在线教育AI助教这个岗位我从投简历到三面结束前后拉扯了快三周。复盘下来整场面试的主线非常清晰围绕一个AI助教系统微服务怎么拆、RAG智能问答怎么做、两者怎么融合落地。这篇文章把我被问到的高频问题、当时的回答思路、以及事后反思的正确答案都拆开讲重点放在微服务与RAG融合这条线上——这是整场面试的核心战场也是做同类AI问答项目的同学最该提前想明白的地方。如果你也在准备类似的架构岗或AI应用岗这篇实录值得你花十分钟过一遍。1. 投递这个岗位之前我复盘了哪些东西1.1 在线教育AI助教场景到底考什么在线教育里的AI助教和通用领域的聊天机器人完全是两码事。它有三个鲜明的业务特征知识域封闭只能回答课程体系内的内容、回答可靠性要求高不能误人子弟尤其涉及例题、错题解析时、访问有明显的波峰波谷开课季、考试周流量暴涨平时相对平缓。这三个特征直接决定了面试题的方向。知识域封闭意味着必须引入RAG把课程资料、讲义、题库作为知识来源而不是单纯靠大模型的参数记忆可靠性要求高意味着检索质量、引用溯源、兜底策略都是必考题流量波峰波谷则意味着微服务架构里的弹性伸缩、限流降级一定会被反复盘问。我准备阶段就把这三个特征写在笔记最前面后面所有知识点都围绕它们展开。另外还有一个容易被忽视的点在线教育行业通常有多机构、多课程的租户概念不同机构共用一套系统但数据必须隔离。这个点面试官后面确实问了而且问得很细我差点答崩。1.2 微服务与RAG两条技术线的交叉点很多人把微服务和RAG当成两条独立的技术线准备这是错误的。在AI助教场景里两者的交叉点非常具体RAG的完整链路需要哪些服务协作这些服务之间如何通信、如何治理。我的理解是一次完整的AI助教问答上游是网关和鉴权服务中间是对话服务负责会话管理、提示词组装、检索服务负责召回、重排服务负责精排、知识库服务负责文档管理和向量化、下游还有大模型网关统一管理LLM调用、日志与评估服务。这已经是一个至少六七个微服务协作的分布式系统了。所以面试官真正想看到的不是你会不会调一个LangChain而是你能不能把一个RAG链路拆成可治理的微服务并且说清楚每个服务的职责边界、数据流向、失败场景。我准备的架构图就是按照这个逻辑画的面试时直接手绘讲解效果明显比空谈概念要好。1.3 我的准备清单具体准备时我列了一份自查清单每项都能展开讲三分钟以上才算过关微服务拆分边界按业务域还是按技术层拆课程域、用户域、问答域怎么划分服务通信同步Feign调用和异步MQ事件各自用在什么场景为什么不能全用同步检索质量向量检索、关键词检索、混合检索的适用场景rerank要不要上知识库管理文档切分策略、向量化流程、更新机制、多租户隔离方案。可靠性兜底大模型超时怎么办、检索为空怎么办、答案无法溯源怎么办。治理手段限流、熔断、降级在AI场景下的特殊考虑流式接口的限流和普通接口不一样。这份清单帮我扛住了绝大多数追问。后面遇到没准备过的问题也能通过往清单上靠来稳住节奏。2. 一面开场AI助教的整体技术方案被盘问2.1 一句话讲清AI助教的完整请求链路一面开场面试官没有寒暄直接抛了一个开放式问题你给我讲讲一个学生打开网页问AI助教这道题怎么做从请求发出到回答展示整个系统里发生了什么这个问题看着基础其实是整个面试的定调题。答得好后面节奏都在你手里答不好面试官会默认你对系统整体性缺乏认知。我当时的回答分四层第一层是接入层请求先到API网关做鉴权、限流、灰度路由然后转发到对话服务。第二层是业务层对话服务拿到用户ID和问题先查会话上下文Redis再组装基础Prompt同时调用检索服务。第三层是检索层检索服务先从知识库服务查询该用户所属课程的可用知识库范围然后执行混合检索把候选片段交给重排服务精排返回最相关的3到5个chunk。第四层是生成层对话服务把用户问题、上下文、检索片段拼成最终Prompt通过大模型网关调用LLM以SSE流式返回给前端。我把每一步的耗时预估也说了检索占500到800毫秒大模型生成是流式的首字延迟大概1到2秒整体体感可以接受。面试官听完点了点头紧接着就抛出了下一个问题。2.2 面试官追问检索服务是一个独立的微服务吗“你刚才说检索服务是独立的那它和对话服务之间到底是什么关系是每次问答都同步调一次吗”这是典型的边界考察题表面问服务关系实际问的是你是不是真的理解RAG流程里的依赖方向。我的答案是检索服务和对话服务确实拆开了但不是每次都必须调用。对话服务内部有一个路由判断先做意图识别和问题分类。如果学生问的是闲聊类问题比如你好谢谢直接走大模型生成不进检索如果问题是课程相关内容才走RAG链路。这个路由判断本身是对话服务里的一个轻量逻辑不需要单独拆服务。至于同步还是异步我的观点是检索必须同步调用。原因很简单生成答案时需要检索片段作为上下文这是即时的、强依赖的不可能靠异步消磨。对话服务调检索服务用的是带超时控制的Feign调用超时设为800毫秒超了就降级为纯大模型回答并提示当前检索暂不可用。这个降级方案面试官觉得务实没有在这个点上继续纠缠。2.3 画架构图时被挑战的边界面试官让我在白板上画整体架构图。我画完之后他指着知识库服务问了一个我准备过但没想到会在一面就问的问题“知识库服务是RAG体系里的还是微服务治理体系里的它的注册发现、配置管理怎么处理”这个问题就是在考微服务和RAG融合的边界。我的回答是知识库服务本质上是领域服务属于微服务治理体系只是它的上游是检索服务而不是直接面向前端。它必须注册到Nacos注册中心走统一的配置中心同样要接链路追踪。它和其他服务的区别在于它内部多了一套向量化的管道——文档上传后要做切片、Embedding、写入向量库这部分不归对话服务管。面试官对这个回答的反馈比较积极他补充了一句很多人把知识库服务画在RAG框里和微服务体系剥离开后面做监控、做治理的时候就会非常痛苦。这一点我记了下来后面三面时果然用上了。3. 深入RAG检索质量、知识库与hit rate的连环追问3.1 切分策略为什么固定窗口切分不够用一面通过后二面基本是纯技术深挖开场就是RAG的经典难点——文档切分。你的知识库里有一本300页的教材PDF你会怎么把它切成chunk面试官问得直截了当。我先说了基础方案按固定字符数切比如每512个字符切一块重叠128字符。然后主动指出了这个方案的问题固定窗口会把一个完整的知识点拦腰切断比如一个二次函数的顶点式推导过程可能被切成两半检索时只召回后半段答案自然缺头少尾。我的改进方案是结构感知切分。针对PDF和Word讲义先按标题层级章、节、小节建立文档结构树再以结构节点为边界切分每个chunk控制在800字以内跨章节的简介段落允许适当超长。对于题目类内容按题目解析的完整语义块切分保证一个例题不被拆散。实践下来这种方式对hit rate的提升非常明显我们内部从0.62提到了0.74左右。3.2 混合检索向量召回和关键词召回为什么都要第二个深挖点是检索召回。你刚才说用了混合检索为什么不能只靠向量面试官这句话明显带着引导性质他期待的不是教科书答案而是真实场景里的坑。我的回答从各自的失效场景切入。纯向量检索的问题在于Embedding模型对专业术语、人名、公式符号的语义理解不可靠。比如学生问洛必达法则求极限向量检索可能召回一堆关于极限但没提洛必达的片段而纯关键词检索的问题在于匹配不到同义表达学生问导数怎么求知识库里写的是微分计算字面完全不重叠。所以我的方案是ES的BM25关键词检索和向量检索并行执行两组结果先按各自分数取top20再合并去重送进重排模型。这个方案的工程成本不高——ES本来就要承担结构化查询向量库用Milvus或者pgvector都行关键是合并逻辑按场景调权重。教育场景里学生提问偏口语化同义改写多向量权重要高一些大概0.6关键词0.4。3.3 重排、context压缩与hit rate的真实数据提到hit rate面试官立刻追了一句你刚说提升到了0.74这个指标怎么算的提升之后对最终答案质量有什么可感知的变化hit rate的定义我先说清楚在评测集里正确答案对应的知识片段是否出现在检索返回的前N个结果中出现在top5记为命中命中数除以总问题数就是hit rate。我们内部还拆了一个更严格的指标叫MRR平均倒数排名因为hit rate只看在不在top5不关心排在第几位MRR能体现排序质量。提升hit rate之后答案质量的提升是连锁的。我用一个案例说明学生问动能定理和动量定理的区别优化前检索经常只召回动能定理的片段生成的答案只讲了一半优化后能稳定召回两者的对比段落生成答案是完整的。面试官对这个可感知的变化很满意——技术指标最终要落到用户体验上这是AI应用岗面试不变的逻辑。3.4 RAG瓶颈与幻觉面试官故意挖的坑二面后半段面试官抛了一个开放性的难题你现在这套RAG最大的瓶颈在哪里如果有一天用户反馈AI助教在胡说八道你第一反应排查什么这个问题有两个层面我先答瓶颈再答排查。瓶颈分三层第一层是检索召回的天花板Embedding模型决定了语义理解上限这不是调参能解决的第二层是上下文窗口与知识的矛盾课程知识量可能是几十万chunk不可能全塞进Prompt必须靠检索裁切裁切就必然有信息损失第三层是评测体系的滞后线上真实问题和离线评测集分布不一致指标好不代表线上稳。排查胡说八道的思路我给了标准的三段式先定位是检索环节丢了正确片段还是生成环节没有遵守指令。查检索看日志里recall的片段ID和分数如果正确片段根本不在结果里问题在检索侧如果片段在结果里但答案没引用问题在Prompt约束——比如没有强制只依据给定资料回答。这两者的排查路径完全不同不能一上来就调Prompt。面试官就是这个问题的意图显然是想看排查体系性。3.5 知识库能否存图片一个被热搜带偏的话题面试过程中有个细节值得一提——热门搜索里RAG知识库能存储图片吗这类问题其实很常见我当时也真被问到了类似的变体讲义里的图表、公式截图你们怎么处理我的实践结论是知识库主存储文本图片走双轨制。公式用LaTeX转成文本后入库这是最可靠的路径对于图表类图片OCR提取图中文字生成文本描述和图片文件一起挂到同一个chunk的元数据里。检索阶段只匹配文本内容返回答案时把关联的图片URL一并给前端展示。纯以图搜图的向量检索目前在教育场景收益不大而且工程成本高不建议初期就做。这个回答实际上是向面试官传递一个信号我分得清技术炫技和业务价值这在做行业AI应用时比技术本身更值钱。4. 微服务架构的实战验证拆分、通信与治理4.1 从一个单体系统开始拆分边界到底怎么定三面是系统设计轮面试官给了一个具体场景假设现在你们公司已经有一个能跑通的AI助教单体应用用户量起来了让你牵头做微服务拆分你从哪里下手我给的答案是先按变更频率和团队边界拆不按技术栈拆。这个原则听起来抽象落到场景里就很好理解对话服务的Prompt模板和路由策略每周都在改课程服务的章节结构一个月改一次知识库服务的文档处理管道只在接新课件时变它们的变更频率差异太大混在一个进程里互相牵制。具体拆成四个域用户与权限域账号、课程订阅、鉴权、课程内容域章节、讲义、题库、问答域会话、Prompt、检索编排、生成、知识库域文档上传、切片、向量化、索引管理。问答域和知识库域是RAG融合的核心也是我后面重点展开的部分。面试官在这个点上问了一个很实际的问题拆分之后哪个服务最容易变成性能瓶颈我毫不犹豫答知识库服务——因为它既是同步链路检索侧实时查索引又是异步链路文档上传后做Embedding的汇聚点而且向量化的耗时通常比普通业务接口长得多一旦管道阻塞新课件的知识就迟迟上不了线。4.2 同步与异步哪条链路必须同步哪条必须异步三面开始后面试官直接把问题往深了逼你讲一下这个系统里哪些调用必须同步哪些应该异步原则是什么我梳理了三类场景。第一类必须同步对话服务调检索服务因为一次响应内就要拿到片段去组装Prompt这是硬依赖只能同步加超时保护。第二类必须异步文档上传后的切片和Embedding流程因为处理耗时可能从几秒到几十秒不可能让用户上传完课件就干等我用的方案是上传接口只落库和发消息消费者服务拉取后处理完成后更新索引状态。第三类允许二选一但建议异步日志埋点和评估采样虽然同步也能扛住但避免影响主链路统一走MQ。面试官还追问了事务边界文档上传落库和发MQ消息你怎么保证不丢消息我用了本地消息表的方案上传接口在本地事务里同时写文档表和消息表由定时任务扫消息表投递给MQ投递成功才标记状态。这个方案牺牲了一点实时性换来了可靠性面试官认可这种取舍。4.3 限流、熔断与降级在大模型场景下的特殊考量这是我实战中踩过坑、准备得最充分的一个模块。面试官问你们对接大模型怎么防止外面流量把大模型调用打爆跟普通接口限流有什么不同不同点在于流式接口的限流不能简单看QPS。大模型接口的消耗跟token数强相关一个长文档问答的请求可能消耗几千token而一个短闲聊只有几百。所以我用的限流维度是并发连接数每分钟聚合token预算的双重限制。网关层面限并发比如单租户最多同时5个流式请求大模型网关层面限token聚合速率超出部分排队或快速失败。熔断的触发条件也要按大模型的特点调整。普通的熔断看错误率和超时比例但在大模型场景还要看平均首字延迟——如果连续多个请求首字延迟超过8秒说明上游LLM已经过载这时候即使没有报错也应该触发熔断降级为纯检索模式或返回兜底话术。这个点让面试官明显来了兴趣他还追问了怎么设置阈值我说是结合历史P99延迟动态调整的并给了一个静态初始值错误率15%或首字延迟超过8秒的请求占比30%。4.4 分布式事务课程更新后知识库不同步怎么破你们有分布式事务的需求吗面试官问这个问题的语境是我刚才提到了课程服务和知识库服务是两个域而课程上新必然触发知识库更新。我的回答是这个场景不适合用分布式事务硬扛应该用最终一致性。课程服务更新章节后发一个课程内容变更事件知识库服务监听事件后把对应文档标记为待处理然后走异步重新切分和Embedding完成后更新版本号。在这期间检索结果会带一个知识版本字段如果知识版本过期对话服务可以在答案下方显示该内容可能基于旧版讲义。这里有个实操细节不要全量重新向量化要按变更粒度做增量更新。课程服务在事件里带上具体变更了哪些章节的章节ID知识库服务只处理这些章节关联的chunk批量删除旧向量、批量写入新向量单次异步任务耗时能控制在分钟级。如果依赖全量重建几十个章节的课程跑一次要半小时完全没法用。5. 在线教育场景特有的边界与追问5.1 多租户隔离从数据到检索再到Prompt的三层隔离三面最后半小时面试官回到了业务本身你们的知识库是多个机构共用的学生问问题的时候怎么保证他只搜到自己课程的知识这个问题回答的关键在于隔离必须贯穿全链路少一层都有信息泄露风险。我的方案分三层数据层知识库表结构里每个文档、每个chunk都带tenant_id和course_id向量化写入时这两列同步写入向量库的标量字段检索层查询向量时用filter条件强制限定tenant_id和course_id不是先全库搜再过滤而是索引层面就限定范围生成层Prompt里明确注入当前用户的课程上下文例如你是XX课程助教只能使用该课程材料回答。面试官追问了一个更刁钻的角度向量化的Embedding模型是共享的不同学科的文档语义会不会互相干扰我的回答是共享模型问题不大但建议按学科方向微调或至少准备领域特定的Embedding模型数学讲义和语文讲义的向量空间如果差异太大共享模型会损失精度。稳妥做法是先用通用模型上线积累一定语料后再用课程语料做领域适配。5.2 流式输出在微服务链路里的工程细节AI助教几乎必然是流式输出这个点面试官没有跳过从对话服务到大模型网关再到前端SSE怎么穿过微服务链路我强调了一个关键原则流式链路里不能随便加同步的中间层。对话服务调大模型网关必须以流式方式透传不能等全部生成完再返回否则首字延迟和用户体验直接崩掉。大模型网关到对话服务用WebFlux或响应式WebClient对话服务再以SSE格式转发给前端。这里有个容易被忽视的工程坑网关层对SSE的超时设置和缓冲设置。普通的HTTP网关默认会缓冲响应体SSE必须关闭缓冲并且调大read超时否则前端会收到一次性吐出的完整内容、或者连接被中断。我当时补了一句我们内部把网关的超时从默认3秒调到了60秒并且给SSE接口单独配了路由规则面试官点头表示这就是实战过的人才知道的细节。5.3 评估与上线AI助教的答案质量怎么验收最后一个业务追问是你怎么知道AI助教上线后回答的是好的除了功能测试你怎么评估质量这个问题我答了三层。第一层是离线评估集从真实用户问题里抽出有代表性的2000条标注好标准答案和对应知识片段每次迭代跑一遍算hit rate、MRR和答案相关性打分。第二层是线上抽样按1%比例采样线上问答日志由运营团队每周做人工打分评分维度包括有用性、引用准确性、安全合规。第三层是用户反馈闭环每条回答末尾附有帮助/没帮助按钮负反馈样本进回流每周归因一次分析是检索问题还是生成问题。我当时特意强调了一个自己的经验离线指标和线上体验经常不一致最典型的就是hit rate高了但用户体感没变。这是因为检索排第一的片段相关但Prompt里塞的片段顺序不对模型忽略了关键信息。所以评估时一定要同时看检索质量和生成质量不能只看前者的指标就发版。这个反思让面试官觉得我有闭环思维。6. 复盘总结哪些回答出彩哪些问题我答砸了6.1 面试官真正想考察的底层能力三面结束之后我花了一晚上复盘整场面试。最大的体悟是这类微服务RAG融合的岗位面试技术深挖只是表象核心考察的是三件事。第一是系统思维能力。你能不能把一次AI问答拆成一条可治理的分布式调用链而不是停留在调大模型API的层面。围绕这一点所有关于链路拆分、超时设置、流式处理的追问都是在验证同样的能力。第二是工程取舍能力。典型表现是为什么检索要同步、文档处理要异步为什么不用分布式事务而用最终一致性面试官想听的不是标准答案而是你权衡利弊的过程。第三是业务敏感度。在线教育的知识可靠性和多租户隔离要求决定了你不能把通用AI套壳直接搬来用。6.2 我翻车的地方和补救思路复盘时我记下了两个回答得不够好的点写在这里给大家当反面教材。第一个是二维面时被问Embedding模型你怎么选我当时只说了用开源的通用模型没有讲清楚选型维度。事后想明白正确答法是先看语种适配中文为主还是中英混合、再看领域覆盖数学公式、编程代码的语义是否理解、最后看向量维度与检索性能的权衡。第二个是三面画架构图时我把链路追踪比如SkyWalking或Zipkin放在了可选组件里面试官提醒了一句AI调用链路的耗时分析比普通接口更重要我立刻补上了检索耗时、LLM耗时、首字延迟都是trace里必须打点的关键维度——这个点虽然圆回来了但第一反应还是暴露了对可观测性重视不足。6.3 如果你也要面类似的岗位根据这次面试的体验我给准备类似岗位的同学三个建议。第一别把时间花在背八股上把用户一次提问的完整链路画到能闭眼讲出来的程度这个能力比背一百个微服务知识点都管用。第二准备一个真实的指标优化案例不用多高大上哪怕只是把hit rate从0.6提升到0.7也要能把优化前后、数据变化、用户体感对应上。第三想清楚AI场景和传统微服务的差异点流式限流、token预算、降级策略、可观测性这些是区分调包侠和真架构师的地方。面试结果最终是过了但拿到offer只是开始。这套系统的真实挑战——知识库持续演进、大模型版本迭代、检索质量的持续优化——都要在线上的流量里慢慢磨。我做这个项目最大的感受是微服务和RAG相结合的架构不是把两个技术名词拼在一起而是在两者之间找到一条能落地、能治理、能评估的中间路径。希望这篇实录能帮你少走一段弯路。