后端开发者转大模型岗面试到底在考什么这是近一年我被问到最多的问题。很多人的误区是以为大模型面试就是背概念把 Transformer、Attention、PPO 背得滚瓜烂熟就能过关。但真正到了面试现场你会发现面试官问的是“你的 RAG 项目里混合检索的权重怎么调的”“Agent 的规划模块报错时你会怎么排查”“LoRA 微调后模型变笨了怎么办”这类工程问题。如果你正准备后端转大模型、AI 应用开发岗或者正在准备秋招这篇文章会给你一张完整的面试知识地图。我会把 RAG、Agent、微调、提示词、向量库、LLM 部署这六大方向拆开讲清楚每个方向的核心考点、答题逻辑和常见的追问方式。这不仅是知识清单更是一套“面试答题方法论”。全文核心判断大模型应用开发岗面试考的不是你懂多少模型原理而是你能不能把模型、数据、检索、推理这些东西串成一个可落地的系统方案。你需要的是工程化思维而不只是算法基础。1. 大模型应用开发岗位到底在考什么先给一个整体判断大模型应用开发岗的面试和传统后端面试、算法工程师面试都不一样。传统后端面试考的是你用 Java 或 Go 写系统MySQL、Redis、消息队列这些中间件要熟算法工程师面试考的是模型原理、论文复现、训练调参。而大模型应用开发岗恰好卡在两者中间你既要懂模型怎么用也要懂系统怎么搭还要懂数据怎么处理。从面试官的角度看一名合格的大模型应用开发工程师需要具备四个维度能力第一层模型应用能力。会调用 API会写 Prompt会处理模型的输入输出。这是最基础的几乎每个岗位都要求。第二层框架与工具链能力。熟悉 LangChain、LlamaIndex、Dify、FastAPI 这类开发框架知道在什么场景用哪个框架能快速搭建一个原型系统。第三层工程化能力。这不只是写代码还包括向量数据库的选型与调优、服务的部署与监控、并发请求的处理、成本的控制。很多后端转行的候选人这一层是有优势的但需要把经验映射到大模型场景。第四层算法理解能力。不需要你会从零训练一个大模型但要理解 RAG 的原理、LoRA 微调的机制、Attention 的基本概念至少能和算法团队对话。面试的典型流程通常是自我介绍 → 项目深挖 → 基础知识问答 → 手写代码或系统设计 → 反问环节。其中“项目深挖”是大头面试官会揪着你简历上写的项目不断追问直到问出你的知识边界。所以不要只背概念一定要准备一个能打的完整项目。没有项目面试官很难相信你真的理解这些技术。2. RAG面试必考但很多人只背了概念RAGRetrieval-Augmented Generation检索增强生成是大模型应用开发面试中出现频率最高的考点没有之一。2.1 RAG 到底解决什么问题先说结论RAG 是为了解决大模型“不知道”和“记不住”的问题。大模型的知识来自训练数据它的知识截止日期是固定的而且对私有数据、实时数据完全不知情。你问它“我们公司最新的退款政策是什么”它如果没在训练数据里见过就只能瞎编。RAG 的思路很直接在模型生成回答之前先从外部知识库中检索出相关片段把这些片段拼接进 Prompt让模型基于这些材料回答。这和人的工作方式很像。你写一份报告时不会全靠记忆而是先查资料再基于资料组织语言。RAG 就是这个“查资料”环节的自动化。2.2 面试官会怎么问 RAG基础题通常是什么是 RAG它和微调有什么区别RAG 的完整流程是什么怎么解决检索结果不准确的问题为什么 RAG 会生成幻觉内容进阶题则更深入你的知识库里有 10 万份文档怎么设计索引结构用户的问题很多口语化表达和文档里的专业术语匹配不上怎么处理多轮对话场景下怎么让 RAG 理解当前的上下文检索结果和用户问题完全无关问题出在哪一环2.3 回答 RAG 问题的正确逻辑面试官真正想听的不是教科书定义而是你的理解深度。一个完整的 RAG 回答应该包含四段式第一段说清楚 RAG 解决什么问题。大模型的训练数据是静态的但业务知识是动态的RAG 让模型可以借助外部知识回答问题。第二段画出 RAG 的完整链路。文档加载 → 文本切分 → 向量化 → 存入向量库 → 用户查询 → 查询向量化 → 相似度检索 → 重排序 → 拼接 Prompt → 模型生成。每一步都要能展开讲。第三段说出每个环节的坑。切分策略怎么选、向量维度怎么定、混合检索怎么配、重排序模型怎么选这些都是体现经验的地方。第四段说明 RAG 的边界。RAG 不是万能的它不能解决模型推理能力不足的问题也不能完全消除幻觉因为它本质上还是让模型“基于给定材料做归纳”。2.4 RAG 实战一个最小可跑通的流程为了让你在面试中能讲出细节这里给一个 RAG 的最小实现思路。# 文件路径rag_demo.py # 这是一个极简 RAG 流程用于理解核心逻辑生产环境请使用正式框架 from sentence_transformers import SentenceTransformer # 1. 加载文档并切分 documents [文档片段1大模型面试需要掌握RAG、Agent、微调等知识, 文档片段2向量数据库用于存储文本的向量表示, 文档片段3LoRA是一种高效微调方法只训练低秩矩阵] # 2. 加载嵌入模型 embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 3. 文档向量化 doc_embeddings embedder.encode(documents) # 4. 模拟用户查询 query 大模型面试要掌握哪些技术 query_embedding embedder.encode([query])[0] # 5. 计算相似度并取Top-K import numpy as np scores [] for i, doc_emb in enumerate(doc_embeddings): sim np.dot(query_embedding, doc_emb) / ( np.linalg.norm(query_embedding) * np.linalg.norm(doc_emb) ) scores.append((i, sim)) scores.sort(keylambda x: x[1], reverseTrue) top_k scores[:2] # 6. 拼接Prompt并生成这里省略实际调用LLM的代码 context \n.join([documents[idx] for idx, _ in top_k]) prompt f请基于以下资料回答问题\n{context}\n\n问题{query} print(prompt)这段代码虽然简单但它体现了 RAG 的核心链路加载 → 切分 → 向量化 → 检索 → 拼接。面试时能画出这个流程并且能指出每一步的优化空间就已经超越了大部分候选人。2.5 面试加分点切块策略RAG 里最容易被追问、也最体现经验的是文本切块。切块切大了一个块里塞了太多无关信息检索出来的是“半对”的内容模型就会混淆切块切小了语义不完整检索经常漏掉关键信息。实际项目里的常见策略固定大小切块overlap 设 10%-15%适合通用文档。按 Markdown 标题结构切块保留文档的层级关系适合技术文档。按句子或段落切块保留语义完整性适合知识库类文档。父子分块父块做上下文子块做检索兼顾精度和上下文长度。面试时能说出“切块策略直接决定 RAG 的上限”并且能结合具体业务场景选策略面试官就会认为你踩过坑。3. Agent从“问答”到“做事”的跨越如果说 RAG 解决的是“让模型知道”Agent 解决的是“让模型做到”。这也是面试中的高频方向。3.1 Agent 到底在做什么Agent 的核心不再是一个问题答完就结束而是让大模型充当“大脑”去规划任务、调用工具、执行动作最终完成一个复杂目标。举个例子。普通大模型应用是用户问“帮我查一下北京到上海的机票”模型回答“对不起我无法查询实时信息”。Agent 应用是用户说“帮我订一张下周三北京到上海的机票预算 1500 以内”Agent 会调用航班查询工具获取航班列表。按价格筛选出 1500 以内的航班。调用预订工具提交订单。向用户确认预订结果。这个过程中模型本身并不知道怎么订票但它知道要“先查再筛再订”并且知道每一步该调用哪个工具。3.2 面试中的常见问题Agent 的面试题通常围绕这几个方向什么是 Agent它和普通的大模型应用有什么区别Agent 的幻觉问题怎么解决比如模型调用了错误的工具、传了错误的参数。多步任务中中间一步出错怎么恢复你是如何设计工具的工具的描述对 Agent 的行为有什么影响Agent 的执行效率太低每次决策都要调用一次大模型怎么优化3.3 一个容易踩坑的细节工具描述很多人在实践 Agent 时都遇到过这个问题Agent 明明有正确的工具但它就是不用或者用错。答案往往出在工具描述上。大模型是通过工具的描述来理解“这个工具是干什么的、什么时候该用”的。如果工具描述写得太模糊比如“查询用户信息”模型的判断空间就很大如果写清楚“用户在即将过期时调用此接口需要传入用户ID”模型就能更准确地决策。面试时主动说出这个细节会显得你真的做过 Agent 开发而不只是看过文档。3.4 Agent 开发框架选择目前比较主流的 Agent 开发框架包括 LangChain、LangGraph、AutoGen、MetaGPT以及 Dify 这类低代码平台。面试时被问“你用的什么框架”时不要只说框架名。更好的答法是对比框架的适用场景说清楚你选择某个框架的原因。比如 LangChain 生态丰富上手快适合快速原型LangGraph 更强调图的编排适合复杂的、需要有环的任务流AutoGen 更偏向多 Agent 会话协作Dify 适合不想写太多代码的团队快速搭建应用。这些框架不是互相替代的关系而是应对不同复杂度需求的选择。4. 微调比“会跑通”更重要的是“知道什么时候不该用”微调是另一个高频考点但面试中大多数候选人的问题不是“不懂微调”而是“把微调当作万能的解药”。4.1 微调不是把模型变得更强而是把模型变得“更懂你”如果你问面试官“模型回答质量不高应该微调吗”好的回答应该是“先看是哪里质量不高。”大模型回答不好常见原因有几类Prompt 写得不清晰模型没理解任务。缺少相关领域知识模型确实不知道。输出格式不对模型没按要求的格式返回。推理能力不足复杂任务模型怎么也做不对。其中Prompt 问题用提示词解决知识缺失用 RAG 或继续预训练解决格式问题用少量样本的 few-shot 或微调解决推理能力不足则需要换更大模型或更专业的训练手段。微调的真正适用场景是让模型适应特定任务的“行为模式”和“表达风格”。比如内部客服系统要求语气专业、回答格式固定、必须引用工单编号这种情况微调比反复写 Prompt 更稳定。4.2 LoRA 为什么是面试重点面试中聊微调LoRALow-Rank Adaptation几乎是必问的。原因很实际全参数微调需要很大的 GPU 显存多数团队没有这个资源LoRA 只训练插入的低秩矩阵显存占用小、训练速度快而且可以做到“一个底座模型多套 LoRA 适配多业务”。LoRA 的核心原理可以用一句话解释冻结预训练模型的权重只在模型的关键层旁边插入两个低秩矩阵训练时只更新这两个矩阵推理时将低秩矩阵的增量合并回原始权重。面试中回答 LoRA 时如果能提到以下两个细节会明显加分一是低秩矩阵的秩 r 影响模型的学习能力和参数量。r 设置太小模型学不到足够的信息r 设置太大训练参数变多优势减弱。一般是 8 到 64 之间调试。二是 LoRA 和 Base Model 是“加法”关系。这意味着你可以用一份基础模型叠加不同的 LoRA 适配器来服务不同任务。线上切换 LoRA 比切换整个模型更轻量。4.3 微调面试答题框架面试中完整回答微调问题可以按这个框架走先判断要不要微调。列出为什么不建议动不动就微调成本高、周期长、效果不一定好。优先尝试提示词和 RAG。选微调方法。说明全参数微调和参数高效微调的区别给出选择 LoRA/QLoRA 的理由。准备数据集。说明数据清洗、格式构造、任务指令设计、质量控制这是实际项目中最耗时的一步。训练与验证。说明训练如何做、验证集如何拆分、如何评估微调效果。上线与回滚。微调后的模型要和小模型做 A/B 对比要有回滚方案。这里特别提醒面试官追问“你的数据哪来的”“数据质量怎么保证”时才是真正区分做过和没做过的人。5. 提示词工程看似送分实际最容易扣分提示词工程在大模型面试里常常被轻视但它其实是一个拉开差距的考点。5.1 为什么提示词工程如此重要原因很简单当前大模型的能力发挥很大程度取决于你怎么跟它对话。同样一个模型用不同的 Prompt回答质量可以差一个量级。面试中这一部分的考察方式通常有两种一种是让你现场写一个 Prompt 来解决某个任务另一种是挑一个你写过的 Prompt问为什么这么写。5.2 写 Prompt 的底层逻辑写高质量 Prompt核心不是“套模板”而是理解以下几个方面第一明确角色和上下文。告诉模型“你是一个 Python 后端开发专家”“你正在帮助用户排查一个 FastAPI 部署问题”能显著提升回答的专业度。第二明确任务目标和约束条件。不只是说“写一段代码”而是说“请用 Python 实现一个函数输入为字符串列表输出为去重后的列表要求保持原有顺序”。第三给出示例比描述规则更有效。模型对 few-shot 示例的理解能力远强于抽象规则尤其是输出格式受限的场景。第四分解复杂任务。把一个复杂任务拆成多步分多次调用模型比一次请求做所有事更可靠。5.3 指令遵循与格式控制在 AI 应用开发的真实项目中提示词工程最大的价值是“让模型的输出稳定可控”。你在对接业务系统时需要的是 JSON 结构体的输出而不是一大段散文。# 文件路径prompt_example.py # 输出格式控制的 Prompt 示例 prompt 请从用户评价中提取以下信息并以 JSON 格式返回 { sentiment: positive/neutral/negative, keywords: [关键词1, 关键词2], summary: 一句话摘要 } 用户评价{user_review} # 实际调用时在代码中强校验 JSON 格式 import json response llm_call(prompt.format(user_review这家店的菜品非常美味服务也很周到)) try: result json.loads(response) except json.JSONDecodeError: # 兜底逻辑如果模型输出格式非法进行重试或截取 result fallback_parse(response)面试中谈提示词工程最重要的是传达一个观念提示词工程是可控的工程行为不是靠运气调出来的玄学。你要有系统性的分析和评价方法。6. 向量库从选型到实践面试官想听的是“你真的用过”几乎每个 RAG 或 Agent 项目都会用到向量数据库。这个考点的特殊性在于它既考你对数据库的理解又考你对嵌入模型和相似度检索的理解。6.1 为什么需要向量库常规数据库是精确匹配适合格式化的数据而大模型应用需要语义检索比如“新能源汽车的电池寿命”和“电动车电池能用几年”是同一个意思但字符串匹配对不上。向量库的核心工作是把文本、图片等数据通过嵌入模型转换成高维向量再通过向量相似度计算找到语义相近的内容。6.2 候选向量库怎么选面试中常见的对话是面试官“你的项目里向量库用的什么” 候选人“用的 Chroma。” 面试官“为什么用 Chroma如果数据量到 1000 万条你会怎么选”这个追问的意图很明显面试官想知道你有没有容量评估和架构设计意识。不同向量库的适用场景FAISSMeta 开源的向量检索库不是完整的数据库但性能强适合集成到现有系统。Chroma轻量级本地开发首选适合原型验证。Milvus分布式架构支持海量数据和高并发适合生产环境。QdrantRust 实现性能好支持过滤和 payload 存储。PostgreSQL pgvector适合已有 PostgreSQL 的团队减少基础设施成本。回答选型问题时不要只说一个库名字而是给出选型维度数据量级、QPS 要求、是否已有基础设施、是否需要实时更新、团队维护成本。6.3 向量检索的常见坑第一个坑嵌入模型和查询文本不匹配。中文场景如果用的还是面向英文优化的嵌入模型检索效果会很差。BGEBAAI General Embedding、M3E 这类中文嵌入模型才是更稳妥的选择。第二个坑向量维度越大越好不是。维度越高存储成本越高检索速度越慢而且可能引入噪声。常见的中文嵌入模型输出是 768 维或 1024 维。第三个坑忽略混合检索的价值。纯向量检索在专有名词、ID 检索、精确匹配场景下效果并不好。生产环境常用“稠密向量 稀疏向量如 BM25”的混合检索方案再用 RRFReciprocal Rank Fusion倒数排名融合或重排序模型把两类结果合并排序。这个细节在大模型面试中非常有区分度因为大多数人只讲了向量检索没讲过“混合检索和结果融合”。7. LLM 部署从跑通到服务化的关键一跃大模型应用开发不只是写业务逻辑还要懂模型怎么部署、怎么服务化。这一部分对后端转行的候选人反而有优势。7.1 本地部署 vs 调用 API面试里首先会遇到的问题你的项目里模型是调 API 还是本地部署如果调 API面试官会问为什么不用本地部署成本怎么算延迟多少如果外部 API 不可用怎么办如果本地部署面试官会问用了什么量化方案显存占用多少并发能力如何实际业务中决策维度是数据安全要求高必须私有化。调用量大API 费用太高本地部署更划算。有离线或内网部署需求。需要对模型做微调或定制API 不方便。这个问题的答案没有标准对错关键是你能否说清楚权衡逻辑。7.2 常用的部署推理方案本地部署大模型目前的主流方案是 llama.cpp 配合 GGUF 量化模型也可以用 vLLM 这类推理加速框架。llama.cpp 的特点是纯 C/C 实现没有 Python 依赖支持 CPU 推理也支持 GPU 加速。它把模型量化成 GGUF 格式比如 Q4_K_M模型文件小很多消费级显卡也能跑。vLLM 的优势则是吞吐量高通过 PagedAttention 技术提高显存利用率适合高并发的 API 服务场景。一个常见的部署架构是# 文件路径deploy_llm.sh # 使用 llama.cpp 启动一个 OpenAI 兼容的 API 服务 ./llama-server \ -m /models/qwen2-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 8192 \ --n-gpu-layers 999启动后你的应用代码可以像调用 OpenAI API 一样访问这个本地服务。7.3 面试中的部署高频追问GGUF 量化是什么不同量化级别的区别显存不够怎么办并发请求一多就 OOM怎么优化模型推理延迟太高怎么优化API 网关、限流、缓存怎么设计这些问题对后端转行的候选人比较友好可以直接复用后端知识但你要能映射到大模型场景。8. 面试答题方法论怎么组织你的答案前面聊了六大方向的知识点最后这部分我想重点讲讲“怎么答”。因为面试官听到的答案常常不是知识问题而是表达问题。8.1 先给结论再给细节很多候选人回答问题喜欢从背景开始铺垫讲到一半面试官已经失去耐心。更好的方式是“金字塔结构”先抛出核心结论再用具体细节展开。面试官问“RAG 和微调怎么选”不要先说一堆背景。直接答“RAG 解决的是知识更新和私有知识引入的问题微调解决的是行为风格适应的问题。如果只是想让模型知道一些新知识优先 RAG如果想让模型以特定风格和格式完成任务考虑微调。”然后展开。8.2 用项目经历回答问题几乎每个面试题都可以落到项目上。面试官问“切块策略怎么定”不要泛泛而谈理论而是说“我之前有个知识库项目文档是 Markdown 格式的我按标题层级切块并给每块加了父文档的标题作为上下文检索效果比固定长度切块提升了大约 15%”。这个回答的含金量远高于背教科书。因为面试官能感知到你是真的遇到问题、真的做过取舍。8.3 敢于说“不知道”并且给出解决思路大模型面试中面试官经常故意追问到你不会为止。这不是刁难而是在测试你面对未知问题的反应。此时最错误的回答是强行编一个答案或者沉默不语。更好的回答是“这个问题我没有深入实践过。但按照我的理解它可能和 XX 有关。如果是我的项目我会先通过 XX 方式验证这个猜想。”这个框架很实用的原因在于它承认了知识边界但展示了你的问题解决思路。9. 高频考点清单与学习路径建议最后给一份可直接用于自测的考点清单。建议按下面的顺序逐个确认哪些已经能流畅回答哪些还需要补。9.1 高频考点自测清单RAG 方向能画出 RAG 完整流程图。能说出切块策略的三种方式和适用场景。能解释混合检索和重排序。能给出降低幻觉的三种方法。能说出 RAG 与微调、长上下文的区别和联系。Agent 方向能解释 ReAct 模式。能说清楚工具描述、工具参数对 Agent 效果的影响。能描述一个多步 Agent 任务的完整执行流程。能说出 Agent 出错时的排查思路。能说出 Agent 框架选型的依据。微调方向能解释 LoRA 原理。能判断什么场景该用微调什么场景不该用。能描述数据准备的基本流程。能说清楚微调评估与回归测试的方法。提示词方向能用结构化 Prompt 解决一个具体任务。能说明少样本学习和思维链的适用场景。能设计输出格式强约束的 Prompt。向量库方向能对比至少三种向量库。能解释 embedding 和向量相似度。能描述索引构建和更新策略。部署方向能说清楚 GGUF 量化的含义。能描述一次完整的本地部署流程。能给出推理性能优化的基本思路。9.2 简历项目建议如果你的简历上还缺一个大模型项目建议做一个“知识库问答系统”起步。这个项目不复杂但覆盖了 RAG、向量库、LLM 部署、FastAPI 接口开发是面试性价比最高的项目类型。项目结构可以是这样llm-rag-project/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── rag/ │ │ ├── loader.py # 文档加载 │ │ ├── splitter.py # 文本切分 │ │ ├── embedder.py # 向量化 │ │ └── retriever.py # 检索与重排序 │ ├── config.py # 配置管理 │ └── models.py # 数据模型 ├── data/ # 知识库文档 ├── tests/ # 测试用例 └── requirements.txt当你能把这个项目的每个模块都讲清楚并且能回答每个模块的“为什么这样设计”你面对大模型应用开发岗的面试就已经有了足够的底气。10. 写在最后面试是工程能力的映射回到开头的问题后端开发者转大模型岗面试到底在考什么我的答案是考你能否把大模型从“玩具”变成“工具”。面试官想看到的是一个能判断“这个需求该用 RAG 还是微调”“这个功能该调 API 还是本地部署”“这个问题是出在检索还是生成”的工程师。过去一年大模型应用开发的面试题正在快速变化。越来越多的面试官不再问“Transformer 的 Attention 机制是怎样的”而是问“你的知识库答案经常重复你会怎么排查”。前者是算法基础后者是工程能力。这篇文章把六大方向的核心考点和答题框架都拆开了。如果你能对着考点清单逐个搞清楚再配合一个完整的项目实践秋招也好、跳槽也好都会比大多数人更有竞争力。如果你正在准备面试建议先收藏这份清单然后从最简单的“用 FastAPI 搭一个调用大模型 API 的服务”开始动手。面试不是背出来的是做出来的。
后端转大模型岗面试指南：六大核心考点与工程化思维解析
后端开发者转大模型岗面试到底在考什么这是近一年我被问到最多的问题。很多人的误区是以为大模型面试就是背概念把 Transformer、Attention、PPO 背得滚瓜烂熟就能过关。但真正到了面试现场你会发现面试官问的是“你的 RAG 项目里混合检索的权重怎么调的”“Agent 的规划模块报错时你会怎么排查”“LoRA 微调后模型变笨了怎么办”这类工程问题。如果你正准备后端转大模型、AI 应用开发岗或者正在准备秋招这篇文章会给你一张完整的面试知识地图。我会把 RAG、Agent、微调、提示词、向量库、LLM 部署这六大方向拆开讲清楚每个方向的核心考点、答题逻辑和常见的追问方式。这不仅是知识清单更是一套“面试答题方法论”。全文核心判断大模型应用开发岗面试考的不是你懂多少模型原理而是你能不能把模型、数据、检索、推理这些东西串成一个可落地的系统方案。你需要的是工程化思维而不只是算法基础。1. 大模型应用开发岗位到底在考什么先给一个整体判断大模型应用开发岗的面试和传统后端面试、算法工程师面试都不一样。传统后端面试考的是你用 Java 或 Go 写系统MySQL、Redis、消息队列这些中间件要熟算法工程师面试考的是模型原理、论文复现、训练调参。而大模型应用开发岗恰好卡在两者中间你既要懂模型怎么用也要懂系统怎么搭还要懂数据怎么处理。从面试官的角度看一名合格的大模型应用开发工程师需要具备四个维度能力第一层模型应用能力。会调用 API会写 Prompt会处理模型的输入输出。这是最基础的几乎每个岗位都要求。第二层框架与工具链能力。熟悉 LangChain、LlamaIndex、Dify、FastAPI 这类开发框架知道在什么场景用哪个框架能快速搭建一个原型系统。第三层工程化能力。这不只是写代码还包括向量数据库的选型与调优、服务的部署与监控、并发请求的处理、成本的控制。很多后端转行的候选人这一层是有优势的但需要把经验映射到大模型场景。第四层算法理解能力。不需要你会从零训练一个大模型但要理解 RAG 的原理、LoRA 微调的机制、Attention 的基本概念至少能和算法团队对话。面试的典型流程通常是自我介绍 → 项目深挖 → 基础知识问答 → 手写代码或系统设计 → 反问环节。其中“项目深挖”是大头面试官会揪着你简历上写的项目不断追问直到问出你的知识边界。所以不要只背概念一定要准备一个能打的完整项目。没有项目面试官很难相信你真的理解这些技术。2. RAG面试必考但很多人只背了概念RAGRetrieval-Augmented Generation检索增强生成是大模型应用开发面试中出现频率最高的考点没有之一。2.1 RAG 到底解决什么问题先说结论RAG 是为了解决大模型“不知道”和“记不住”的问题。大模型的知识来自训练数据它的知识截止日期是固定的而且对私有数据、实时数据完全不知情。你问它“我们公司最新的退款政策是什么”它如果没在训练数据里见过就只能瞎编。RAG 的思路很直接在模型生成回答之前先从外部知识库中检索出相关片段把这些片段拼接进 Prompt让模型基于这些材料回答。这和人的工作方式很像。你写一份报告时不会全靠记忆而是先查资料再基于资料组织语言。RAG 就是这个“查资料”环节的自动化。2.2 面试官会怎么问 RAG基础题通常是什么是 RAG它和微调有什么区别RAG 的完整流程是什么怎么解决检索结果不准确的问题为什么 RAG 会生成幻觉内容进阶题则更深入你的知识库里有 10 万份文档怎么设计索引结构用户的问题很多口语化表达和文档里的专业术语匹配不上怎么处理多轮对话场景下怎么让 RAG 理解当前的上下文检索结果和用户问题完全无关问题出在哪一环2.3 回答 RAG 问题的正确逻辑面试官真正想听的不是教科书定义而是你的理解深度。一个完整的 RAG 回答应该包含四段式第一段说清楚 RAG 解决什么问题。大模型的训练数据是静态的但业务知识是动态的RAG 让模型可以借助外部知识回答问题。第二段画出 RAG 的完整链路。文档加载 → 文本切分 → 向量化 → 存入向量库 → 用户查询 → 查询向量化 → 相似度检索 → 重排序 → 拼接 Prompt → 模型生成。每一步都要能展开讲。第三段说出每个环节的坑。切分策略怎么选、向量维度怎么定、混合检索怎么配、重排序模型怎么选这些都是体现经验的地方。第四段说明 RAG 的边界。RAG 不是万能的它不能解决模型推理能力不足的问题也不能完全消除幻觉因为它本质上还是让模型“基于给定材料做归纳”。2.4 RAG 实战一个最小可跑通的流程为了让你在面试中能讲出细节这里给一个 RAG 的最小实现思路。# 文件路径rag_demo.py # 这是一个极简 RAG 流程用于理解核心逻辑生产环境请使用正式框架 from sentence_transformers import SentenceTransformer # 1. 加载文档并切分 documents [文档片段1大模型面试需要掌握RAG、Agent、微调等知识, 文档片段2向量数据库用于存储文本的向量表示, 文档片段3LoRA是一种高效微调方法只训练低秩矩阵] # 2. 加载嵌入模型 embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 3. 文档向量化 doc_embeddings embedder.encode(documents) # 4. 模拟用户查询 query 大模型面试要掌握哪些技术 query_embedding embedder.encode([query])[0] # 5. 计算相似度并取Top-K import numpy as np scores [] for i, doc_emb in enumerate(doc_embeddings): sim np.dot(query_embedding, doc_emb) / ( np.linalg.norm(query_embedding) * np.linalg.norm(doc_emb) ) scores.append((i, sim)) scores.sort(keylambda x: x[1], reverseTrue) top_k scores[:2] # 6. 拼接Prompt并生成这里省略实际调用LLM的代码 context \n.join([documents[idx] for idx, _ in top_k]) prompt f请基于以下资料回答问题\n{context}\n\n问题{query} print(prompt)这段代码虽然简单但它体现了 RAG 的核心链路加载 → 切分 → 向量化 → 检索 → 拼接。面试时能画出这个流程并且能指出每一步的优化空间就已经超越了大部分候选人。2.5 面试加分点切块策略RAG 里最容易被追问、也最体现经验的是文本切块。切块切大了一个块里塞了太多无关信息检索出来的是“半对”的内容模型就会混淆切块切小了语义不完整检索经常漏掉关键信息。实际项目里的常见策略固定大小切块overlap 设 10%-15%适合通用文档。按 Markdown 标题结构切块保留文档的层级关系适合技术文档。按句子或段落切块保留语义完整性适合知识库类文档。父子分块父块做上下文子块做检索兼顾精度和上下文长度。面试时能说出“切块策略直接决定 RAG 的上限”并且能结合具体业务场景选策略面试官就会认为你踩过坑。3. Agent从“问答”到“做事”的跨越如果说 RAG 解决的是“让模型知道”Agent 解决的是“让模型做到”。这也是面试中的高频方向。3.1 Agent 到底在做什么Agent 的核心不再是一个问题答完就结束而是让大模型充当“大脑”去规划任务、调用工具、执行动作最终完成一个复杂目标。举个例子。普通大模型应用是用户问“帮我查一下北京到上海的机票”模型回答“对不起我无法查询实时信息”。Agent 应用是用户说“帮我订一张下周三北京到上海的机票预算 1500 以内”Agent 会调用航班查询工具获取航班列表。按价格筛选出 1500 以内的航班。调用预订工具提交订单。向用户确认预订结果。这个过程中模型本身并不知道怎么订票但它知道要“先查再筛再订”并且知道每一步该调用哪个工具。3.2 面试中的常见问题Agent 的面试题通常围绕这几个方向什么是 Agent它和普通的大模型应用有什么区别Agent 的幻觉问题怎么解决比如模型调用了错误的工具、传了错误的参数。多步任务中中间一步出错怎么恢复你是如何设计工具的工具的描述对 Agent 的行为有什么影响Agent 的执行效率太低每次决策都要调用一次大模型怎么优化3.3 一个容易踩坑的细节工具描述很多人在实践 Agent 时都遇到过这个问题Agent 明明有正确的工具但它就是不用或者用错。答案往往出在工具描述上。大模型是通过工具的描述来理解“这个工具是干什么的、什么时候该用”的。如果工具描述写得太模糊比如“查询用户信息”模型的判断空间就很大如果写清楚“用户在即将过期时调用此接口需要传入用户ID”模型就能更准确地决策。面试时主动说出这个细节会显得你真的做过 Agent 开发而不只是看过文档。3.4 Agent 开发框架选择目前比较主流的 Agent 开发框架包括 LangChain、LangGraph、AutoGen、MetaGPT以及 Dify 这类低代码平台。面试时被问“你用的什么框架”时不要只说框架名。更好的答法是对比框架的适用场景说清楚你选择某个框架的原因。比如 LangChain 生态丰富上手快适合快速原型LangGraph 更强调图的编排适合复杂的、需要有环的任务流AutoGen 更偏向多 Agent 会话协作Dify 适合不想写太多代码的团队快速搭建应用。这些框架不是互相替代的关系而是应对不同复杂度需求的选择。4. 微调比“会跑通”更重要的是“知道什么时候不该用”微调是另一个高频考点但面试中大多数候选人的问题不是“不懂微调”而是“把微调当作万能的解药”。4.1 微调不是把模型变得更强而是把模型变得“更懂你”如果你问面试官“模型回答质量不高应该微调吗”好的回答应该是“先看是哪里质量不高。”大模型回答不好常见原因有几类Prompt 写得不清晰模型没理解任务。缺少相关领域知识模型确实不知道。输出格式不对模型没按要求的格式返回。推理能力不足复杂任务模型怎么也做不对。其中Prompt 问题用提示词解决知识缺失用 RAG 或继续预训练解决格式问题用少量样本的 few-shot 或微调解决推理能力不足则需要换更大模型或更专业的训练手段。微调的真正适用场景是让模型适应特定任务的“行为模式”和“表达风格”。比如内部客服系统要求语气专业、回答格式固定、必须引用工单编号这种情况微调比反复写 Prompt 更稳定。4.2 LoRA 为什么是面试重点面试中聊微调LoRALow-Rank Adaptation几乎是必问的。原因很实际全参数微调需要很大的 GPU 显存多数团队没有这个资源LoRA 只训练插入的低秩矩阵显存占用小、训练速度快而且可以做到“一个底座模型多套 LoRA 适配多业务”。LoRA 的核心原理可以用一句话解释冻结预训练模型的权重只在模型的关键层旁边插入两个低秩矩阵训练时只更新这两个矩阵推理时将低秩矩阵的增量合并回原始权重。面试中回答 LoRA 时如果能提到以下两个细节会明显加分一是低秩矩阵的秩 r 影响模型的学习能力和参数量。r 设置太小模型学不到足够的信息r 设置太大训练参数变多优势减弱。一般是 8 到 64 之间调试。二是 LoRA 和 Base Model 是“加法”关系。这意味着你可以用一份基础模型叠加不同的 LoRA 适配器来服务不同任务。线上切换 LoRA 比切换整个模型更轻量。4.3 微调面试答题框架面试中完整回答微调问题可以按这个框架走先判断要不要微调。列出为什么不建议动不动就微调成本高、周期长、效果不一定好。优先尝试提示词和 RAG。选微调方法。说明全参数微调和参数高效微调的区别给出选择 LoRA/QLoRA 的理由。准备数据集。说明数据清洗、格式构造、任务指令设计、质量控制这是实际项目中最耗时的一步。训练与验证。说明训练如何做、验证集如何拆分、如何评估微调效果。上线与回滚。微调后的模型要和小模型做 A/B 对比要有回滚方案。这里特别提醒面试官追问“你的数据哪来的”“数据质量怎么保证”时才是真正区分做过和没做过的人。5. 提示词工程看似送分实际最容易扣分提示词工程在大模型面试里常常被轻视但它其实是一个拉开差距的考点。5.1 为什么提示词工程如此重要原因很简单当前大模型的能力发挥很大程度取决于你怎么跟它对话。同样一个模型用不同的 Prompt回答质量可以差一个量级。面试中这一部分的考察方式通常有两种一种是让你现场写一个 Prompt 来解决某个任务另一种是挑一个你写过的 Prompt问为什么这么写。5.2 写 Prompt 的底层逻辑写高质量 Prompt核心不是“套模板”而是理解以下几个方面第一明确角色和上下文。告诉模型“你是一个 Python 后端开发专家”“你正在帮助用户排查一个 FastAPI 部署问题”能显著提升回答的专业度。第二明确任务目标和约束条件。不只是说“写一段代码”而是说“请用 Python 实现一个函数输入为字符串列表输出为去重后的列表要求保持原有顺序”。第三给出示例比描述规则更有效。模型对 few-shot 示例的理解能力远强于抽象规则尤其是输出格式受限的场景。第四分解复杂任务。把一个复杂任务拆成多步分多次调用模型比一次请求做所有事更可靠。5.3 指令遵循与格式控制在 AI 应用开发的真实项目中提示词工程最大的价值是“让模型的输出稳定可控”。你在对接业务系统时需要的是 JSON 结构体的输出而不是一大段散文。# 文件路径prompt_example.py # 输出格式控制的 Prompt 示例 prompt 请从用户评价中提取以下信息并以 JSON 格式返回 { sentiment: positive/neutral/negative, keywords: [关键词1, 关键词2], summary: 一句话摘要 } 用户评价{user_review} # 实际调用时在代码中强校验 JSON 格式 import json response llm_call(prompt.format(user_review这家店的菜品非常美味服务也很周到)) try: result json.loads(response) except json.JSONDecodeError: # 兜底逻辑如果模型输出格式非法进行重试或截取 result fallback_parse(response)面试中谈提示词工程最重要的是传达一个观念提示词工程是可控的工程行为不是靠运气调出来的玄学。你要有系统性的分析和评价方法。6. 向量库从选型到实践面试官想听的是“你真的用过”几乎每个 RAG 或 Agent 项目都会用到向量数据库。这个考点的特殊性在于它既考你对数据库的理解又考你对嵌入模型和相似度检索的理解。6.1 为什么需要向量库常规数据库是精确匹配适合格式化的数据而大模型应用需要语义检索比如“新能源汽车的电池寿命”和“电动车电池能用几年”是同一个意思但字符串匹配对不上。向量库的核心工作是把文本、图片等数据通过嵌入模型转换成高维向量再通过向量相似度计算找到语义相近的内容。6.2 候选向量库怎么选面试中常见的对话是面试官“你的项目里向量库用的什么” 候选人“用的 Chroma。” 面试官“为什么用 Chroma如果数据量到 1000 万条你会怎么选”这个追问的意图很明显面试官想知道你有没有容量评估和架构设计意识。不同向量库的适用场景FAISSMeta 开源的向量检索库不是完整的数据库但性能强适合集成到现有系统。Chroma轻量级本地开发首选适合原型验证。Milvus分布式架构支持海量数据和高并发适合生产环境。QdrantRust 实现性能好支持过滤和 payload 存储。PostgreSQL pgvector适合已有 PostgreSQL 的团队减少基础设施成本。回答选型问题时不要只说一个库名字而是给出选型维度数据量级、QPS 要求、是否已有基础设施、是否需要实时更新、团队维护成本。6.3 向量检索的常见坑第一个坑嵌入模型和查询文本不匹配。中文场景如果用的还是面向英文优化的嵌入模型检索效果会很差。BGEBAAI General Embedding、M3E 这类中文嵌入模型才是更稳妥的选择。第二个坑向量维度越大越好不是。维度越高存储成本越高检索速度越慢而且可能引入噪声。常见的中文嵌入模型输出是 768 维或 1024 维。第三个坑忽略混合检索的价值。纯向量检索在专有名词、ID 检索、精确匹配场景下效果并不好。生产环境常用“稠密向量 稀疏向量如 BM25”的混合检索方案再用 RRFReciprocal Rank Fusion倒数排名融合或重排序模型把两类结果合并排序。这个细节在大模型面试中非常有区分度因为大多数人只讲了向量检索没讲过“混合检索和结果融合”。7. LLM 部署从跑通到服务化的关键一跃大模型应用开发不只是写业务逻辑还要懂模型怎么部署、怎么服务化。这一部分对后端转行的候选人反而有优势。7.1 本地部署 vs 调用 API面试里首先会遇到的问题你的项目里模型是调 API 还是本地部署如果调 API面试官会问为什么不用本地部署成本怎么算延迟多少如果外部 API 不可用怎么办如果本地部署面试官会问用了什么量化方案显存占用多少并发能力如何实际业务中决策维度是数据安全要求高必须私有化。调用量大API 费用太高本地部署更划算。有离线或内网部署需求。需要对模型做微调或定制API 不方便。这个问题的答案没有标准对错关键是你能否说清楚权衡逻辑。7.2 常用的部署推理方案本地部署大模型目前的主流方案是 llama.cpp 配合 GGUF 量化模型也可以用 vLLM 这类推理加速框架。llama.cpp 的特点是纯 C/C 实现没有 Python 依赖支持 CPU 推理也支持 GPU 加速。它把模型量化成 GGUF 格式比如 Q4_K_M模型文件小很多消费级显卡也能跑。vLLM 的优势则是吞吐量高通过 PagedAttention 技术提高显存利用率适合高并发的 API 服务场景。一个常见的部署架构是# 文件路径deploy_llm.sh # 使用 llama.cpp 启动一个 OpenAI 兼容的 API 服务 ./llama-server \ -m /models/qwen2-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 8192 \ --n-gpu-layers 999启动后你的应用代码可以像调用 OpenAI API 一样访问这个本地服务。7.3 面试中的部署高频追问GGUF 量化是什么不同量化级别的区别显存不够怎么办并发请求一多就 OOM怎么优化模型推理延迟太高怎么优化API 网关、限流、缓存怎么设计这些问题对后端转行的候选人比较友好可以直接复用后端知识但你要能映射到大模型场景。8. 面试答题方法论怎么组织你的答案前面聊了六大方向的知识点最后这部分我想重点讲讲“怎么答”。因为面试官听到的答案常常不是知识问题而是表达问题。8.1 先给结论再给细节很多候选人回答问题喜欢从背景开始铺垫讲到一半面试官已经失去耐心。更好的方式是“金字塔结构”先抛出核心结论再用具体细节展开。面试官问“RAG 和微调怎么选”不要先说一堆背景。直接答“RAG 解决的是知识更新和私有知识引入的问题微调解决的是行为风格适应的问题。如果只是想让模型知道一些新知识优先 RAG如果想让模型以特定风格和格式完成任务考虑微调。”然后展开。8.2 用项目经历回答问题几乎每个面试题都可以落到项目上。面试官问“切块策略怎么定”不要泛泛而谈理论而是说“我之前有个知识库项目文档是 Markdown 格式的我按标题层级切块并给每块加了父文档的标题作为上下文检索效果比固定长度切块提升了大约 15%”。这个回答的含金量远高于背教科书。因为面试官能感知到你是真的遇到问题、真的做过取舍。8.3 敢于说“不知道”并且给出解决思路大模型面试中面试官经常故意追问到你不会为止。这不是刁难而是在测试你面对未知问题的反应。此时最错误的回答是强行编一个答案或者沉默不语。更好的回答是“这个问题我没有深入实践过。但按照我的理解它可能和 XX 有关。如果是我的项目我会先通过 XX 方式验证这个猜想。”这个框架很实用的原因在于它承认了知识边界但展示了你的问题解决思路。9. 高频考点清单与学习路径建议最后给一份可直接用于自测的考点清单。建议按下面的顺序逐个确认哪些已经能流畅回答哪些还需要补。9.1 高频考点自测清单RAG 方向能画出 RAG 完整流程图。能说出切块策略的三种方式和适用场景。能解释混合检索和重排序。能给出降低幻觉的三种方法。能说出 RAG 与微调、长上下文的区别和联系。Agent 方向能解释 ReAct 模式。能说清楚工具描述、工具参数对 Agent 效果的影响。能描述一个多步 Agent 任务的完整执行流程。能说出 Agent 出错时的排查思路。能说出 Agent 框架选型的依据。微调方向能解释 LoRA 原理。能判断什么场景该用微调什么场景不该用。能描述数据准备的基本流程。能说清楚微调评估与回归测试的方法。提示词方向能用结构化 Prompt 解决一个具体任务。能说明少样本学习和思维链的适用场景。能设计输出格式强约束的 Prompt。向量库方向能对比至少三种向量库。能解释 embedding 和向量相似度。能描述索引构建和更新策略。部署方向能说清楚 GGUF 量化的含义。能描述一次完整的本地部署流程。能给出推理性能优化的基本思路。9.2 简历项目建议如果你的简历上还缺一个大模型项目建议做一个“知识库问答系统”起步。这个项目不复杂但覆盖了 RAG、向量库、LLM 部署、FastAPI 接口开发是面试性价比最高的项目类型。项目结构可以是这样llm-rag-project/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── rag/ │ │ ├── loader.py # 文档加载 │ │ ├── splitter.py # 文本切分 │ │ ├── embedder.py # 向量化 │ │ └── retriever.py # 检索与重排序 │ ├── config.py # 配置管理 │ └── models.py # 数据模型 ├── data/ # 知识库文档 ├── tests/ # 测试用例 └── requirements.txt当你能把这个项目的每个模块都讲清楚并且能回答每个模块的“为什么这样设计”你面对大模型应用开发岗的面试就已经有了足够的底气。10. 写在最后面试是工程能力的映射回到开头的问题后端开发者转大模型岗面试到底在考什么我的答案是考你能否把大模型从“玩具”变成“工具”。面试官想看到的是一个能判断“这个需求该用 RAG 还是微调”“这个功能该调 API 还是本地部署”“这个问题是出在检索还是生成”的工程师。过去一年大模型应用开发的面试题正在快速变化。越来越多的面试官不再问“Transformer 的 Attention 机制是怎样的”而是问“你的知识库答案经常重复你会怎么排查”。前者是算法基础后者是工程能力。这篇文章把六大方向的核心考点和答题框架都拆开了。如果你能对着考点清单逐个搞清楚再配合一个完整的项目实践秋招也好、跳槽也好都会比大多数人更有竞争力。如果你正在准备面试建议先收藏这份清单然后从最简单的“用 FastAPI 搭一个调用大模型 API 的服务”开始动手。面试不是背出来的是做出来的。
