当前位置：首页 > news >正文

后端转大模型岗面试指南：六大核心考点与工程化思维解析

news 2026/8/30 13:48:05

后端开发者转大模型岗，面试到底在考什么？这是近一年我被问到最多的问题。很多人的误区是：以为大模型面试就是背概念，把 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：面试必考，但很多人只背了概念

RAG（Retrieval-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：向量数据库用于存储文本的向量表示", "文档片段3：LoRA是一种高效微调方法，只训练低秩矩阵"] # 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(key=lambda x: x[1], reverse=True) 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 为什么是面试重点

面试中聊微调，LoRA（Low-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 万条，你会怎么选？”

这个追问的意图很明显：面试官想知道你有没有容量评估和架构设计意识。

不同向量库的适用场景：

FAISS：Meta 开源的向量检索库，不是完整的数据库，但性能强，适合集成到现有系统。
Chroma：轻量级，本地开发首选，适合原型验证。
Milvus：分布式架构，支持海量数据和高并发，适合生产环境。
Qdrant：Rust 实现，性能好，支持过滤和 payload 存储。
PostgreSQL + pgvector：适合已有 PostgreSQL 的团队，减少基础设施成本。

回答选型问题时，不要只说一个库名字，而是给出选型维度：数据量级、QPS 要求、是否已有基础设施、是否需要实时更新、团队维护成本。

6.3 向量检索的常见坑

第一个坑：嵌入模型和查询文本不匹配。中文场景如果用的还是面向英文优化的嵌入模型，检索效果会很差。BGE（BAAI General Embedding）、M3E 这类中文嵌入模型才是更稳妥的选择。

第二个坑：向量维度越大越好？不是。维度越高，存储成本越高，检索速度越慢，而且可能引入噪声。常见的中文嵌入模型输出是 768 维或 1024 维。

第三个坑：忽略混合检索的价值。纯向量检索在专有名词、ID 检索、精确匹配场景下效果并不好。生产环境常用“稠密向量 + 稀疏向量（如 BM25）”的混合检索方案，再用 RRF（Reciprocal 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

当你能把这个项目的每个模块都讲清楚，并且能回答每个模块的“为什么这样设计”，你面对大模型应用开发岗的面试，就已经有了足够的底气。