企业官网建设流程全解析

最近不少朋友在准备大模型和RAG方向的面试，私信问我有没有系统性的整理。我把自己这两年从准备、面试到复盘的内容重新梳理了一遍，沉淀出一份相对完整的面经，覆盖技术栈、项目深挖、手撕代码、系统设计和高频问题，希望能帮你少走点弯路。

先说下我自己的情况：非科班转码两年，做过搜推广后端，后来切到大模型应用方向，主要做RAG（检索增强生成）相关的落地项目。面过大厂中厂，也面过初创公司，拿过offer也挂过简历，踩过的坑不少。这篇内容我不想按教科书的方式来写，而是站在实际面试的角度，把面试官真正关心的东西掰开揉碎了讲清楚。不管你是刚入门想转岗，还是已经做了一段时间想查漏补缺，这份面经都值得收藏。

1. 大模型RAG岗位面试到底在考什么

1.1 岗位需求背后的真实逻辑

很多同学把大模型面试理解为“背八股”，以为把Attention、Transformer、LORA背一遍就完事，结果一到现场就懵。实际上面试官考察的重点很明确：你能不能把一个业务问题转化成一个可落地的大模型解决方案，并且对其中涉及的工程细节有切实的认知。

以RAG岗位为例，表面考的是“检索增强生成”，但深层考的是三件事：第一，你理不理解LLM的局限性，比如幻觉、知识截止、长上下文成本高等，这会直接决定你什么时候该用RAG而不是硬调Prompt；第二，你懂不懂非结构化数据的处理链路，从文档解析、切分、向量化到召回重排，每一步可能遇到什么问题；第三，你有没有工程sense，比如召回效果怎么评估、检索延迟怎么优化、线上Bad Case怎么迭代。

所以面试官经常会从一个很细节的点切入，然后逐步放大。比如先问“你用的embedding模型是什么”，接着问“为什么选它而不选别的”，再问“这个模型的向量维度对你后续存储和召回有什么影响”，到最后可能变成“如果在低资源环境下你怎么做向量检索”。这一串问题背后，考的就是你有没有真正做过、想过，而不是会用现成框架。

1.2. 不同阶段岗位侧重点差异

要根据自己的职级准备，别用同一套模板打天下。

• 初级岗位（1-3年）：重点问基础知识和项目经验，比如Transformer结构、RAG基本流程、Prompt工程、向量数据库基本使用，也会考察代码能力，手写一个简单的RAG调用链很常见。
• 中级岗位（3-5年）：重点问架构设计和优化策略，比如如何设计一个高可用的RAG服务、如何做混合检索、如何评估RAG效果、如何降低幻觉、如何做记忆机制、长文档RAG如何处理等。
• 高级岗位（5年以上）：重点问方案选型和业务判断，比如“为什么要做RAG而不是微调”“多模态场景下RAG怎么演进”“如何衡量大模型应用ROI”等，更看重系统思考和全局视角。

说实话，我面下来最大的感受是：你不需要每个细节都精通，但一定要有一条完整且自洽的技术链路经验。如果你只做过PDF解析+向量检索+调LLM，那就把这条链路做到极致，能讲清楚每一步的输入输出、风险点和优化空间。面试官更愿意看到你对自己做过的系统有深刻理解，而不是背了十个框架的名字却说不清细节。

1.3 面试官视角：一条隐藏的能力自查清单

我后来和一位大模型团队的技术负责人聊过，他说面试大模型应用岗时，心里其实有一份“无字清单”：

• 对LLM基础机制的掌握程度：如果不清楚tokenization、生成策略、上下文窗口、注意力机制，项目很难有优化空间。
• 对数据工程的敏感度：懂不懂清洗、去重、SFT数据构建、评测集构建，这些恰恰是RAG落地质量的根基。
• 对评估体系的认知：有没有自己的评估方法，是只看主观感受还是建立了自动化评测链路。
• 对成本与延迟的把握：是否知道API调用成本、向量化吞吐、GPU资源占用，能不能在方案设计中给出参数级别的估算。

这份清单其实就是大模型应用工程师能力模型的具体化。面试时如果你能在这几个维度上主动输出内容，面试官会对你高看一眼，因为大部分人都在等面试官问一句答一句，很少有候选人能主动展示完整闭环的。

2. 核心知识点拆解：从原理到实战

2.1 Transformer与Attention：别只会背公式

大模型面试几乎必问Transformer，RAG本身也是基于LLM的，所以这块逃不掉。但面试官并不满足于你背出Attention公式，而是希望你理解这个公式背后的why。

我习惯用“查字典”类比来解释Attention：你要生成一个词，不能只看上一个词，得看输入序列里哪些词和当前词有关。Q（查询）是你想要找什么，K（键）是每个词能提供什么索引，V（值）是每个词实际的内容信息。Q和K的点积除以根号d就是算相关性，再用Softmax归一化成权重，最后把V加权求和。

面试官如果追问“为什么除以根号d”，你要能解释深层原因：当维度d增大时，点积的方差会变大，导致Softmax的梯度区域饱和，除以根号d是为了把点积分布拉回方差为1，保证训练稳定性。

还有几个高频变体问题：

• “多头注意力为什么有效？”——相当于多个子空间学习不同关系模式，有的头关注局部词序，有的头关注长距离依赖，类似多个专家各管一摊。
• “自回归生成时怎么避免看到未来token？”——通过Mask矩阵把未来的位置置为负无穷，比如因果掩码（Causal Mask）。
• “位置编码为什么重要？”——Attention本身是Permutation Equivariant的，不带位置信息，所以需要绝对或者相对位置编码，RoPE现在是大模型主流选择，因为它在Attention阶段就能融入相对位置关系，外推能力也更好。

2.2 RAG全流程关键细节

RAG不只是“检索”加“生成”，它是一个完整的数据和推理管道。面试时你要能画出整体流程图，并讲清楚每个环节的权衡。

一个标准的RAG流程是：文档加载 -> 文档切分（Chunking） -> 向量化（Embedding） -> 向量存储（Vector DB） -> 查询改写/检索（Retrieval） -> 重排（Rerank） -> 生成（LLM） -> 输出后处理（引用溯源等）。

每个环节都会出细节题：

• 文档切分：怎么定Chunk大小？固定长度还是语义切分？重叠窗口怎么设？如果是PDF和表格怎么办？
• Embedding选型：BGE、M3E、OpenAI的text-embedding-3等等，怎么根据语言、领域、维度、成本选择？
• 向量数据库：Milvus、Weaviate、Qdrant、Chroma、pgvector，它们之间的区别是什么？HNSW参数（M、efConstruction、efSearch）怎么调？为什么用HNSW而不是暴力检索？
• 召回策略：为什么不能只用纯向量检索？BM25关键词召回什么时候更有优势？混合检索的分数融合怎么做？
• 重排的必要性：第一路召回可能返回100条，但直接扔给LLM不仅浪费Token而且引入噪声，用Rerank模型精排到Top 5，效果提升明显。

我当时面试讲自己做过的一个项目，就是专门抠了“切分”这个点。有一段很长的技术文档，固定512字符切分会导致表格断裂、代码块被拆开，后来改成按Markdown块级结构结合固定大小窗口的混合切分，并给每个切分块打上文档级元信息。就这么一个改进，让最终问答的准确率提升了十几个百分点。这个例子经常被我拿来当“我懂工程细节”的佐证。

2.3 评估RAG效果：指标与评测集建设

评估是RAG面试最能拉开差距的地方。很多人做过RAG，但问他“效果怎么评估”，只会说“人工看几个例子”。这恰恰是面试官最敏感的信号。

RAG评估要分维度：

• 检索评估：Recall@K、Precision@K、MRR（平均倒数排名）、NDCG（归一化折损累计增益）。这些指标不需要死记硬背含义，但你要能说清楚一个实际场景：比如我们要看召回Top20里有没有正确答案，用Recall@20，再看正确答案是不是排在前面，用MRR或NDCG。
• 生成评估：忠实度（Faithfulness）、答案相关性（Answer Relevance）、上下文相关性（Context Relevance）。业界常用RAGAS框架，它把评估拆成这几个维度，通过合成数据和LLM-as-Judge来打分子。
• 评测集构建：不要只用十几条手工数据就开跑。基于业务日志挖掘真实用户问题，再根据文档生成参考答案，构造正反例。我记得自己搭过一个半自动评测流水线：先通过LLM从文档中生成候选问答对，再用规则+人工抽检过滤，最后形成包含500条问题的评测集，每轮改动后全量回归。
• A/B测试与线上监控：光离线评测不够，线上要有反馈闭环。比如用户是否采纳答案、是否点击引用来源、是否存在“对不起，我无法回答”等拒答信号，都要埋点收集。

如果面试官问你“怎么判断一个改动是正优化”，你可以说：离线指标提升是必要条件，但不是充分条件，还必须结合线上Bad Case比例、平均首响延迟、Token消耗成本一起看。

2.4 幻觉抑制与上下文工程

RAG的核心目标之一就是降低幻觉。面试官会问：“RAG真的能完全消除幻觉吗？”答案是“不能，但可以大幅降低概率”。你要能列出几种方案：

• 在Prompt中强调“仅根据提供的上下文回答，不要编造”，并且要求不确定时明确说不知道。
• 对检索结果做相关性阈值过滤，如果Top1向量距离太大就直接拒答。
• 加入忠实性后验校验，生成答案后让LLM自己判定每个句子是否有文档支撑，或者用NLI模型对“答案-上下文”做蕴含判断。
• 允许答案附带引用编号，比如“根据文档[1][3]……”，这样即使出错也能溯源。

其中一个比较有实战价值的思路就是“失败落点分析”：把错误答案分几类——检索没召回、召回了但排得太后、模型没有利用检索片段、模型外推了片段之外的知识。每次分析一个Bad Case都要明确它属于哪一类，然后再针对性地改切分、改重排或者改Prompt。这种思维方式能让你在面试时表现得很务实。

3. 面试实战问答实录

这一节我整理了几个我在面试中遇到的问题，以及我认为有价值的回答思路。这些问题并不完全是标准答案，关键是背后的思考路径。

3.1 “如果用户问题包含专有名词缩写怎么办？”

这个问题的核心是查询预处理和改写。你不应该只说“用规则替换”，而要展开成一个可落地的方案：

第一步，维护一个业务实体词表，和文档标题/关键词做匹配，把“OCR”扩展成“光学字符识别”，把“LLM”扩展成“大语言模型”。

第二步，如果扩展后检索效果仍不理想，可以走一个小模型生成查询改写候选，比如基于SLM微调，或者直接让LLM根据对话历史改写当前问题，补全缺失指代。

第三步，做多路召回，把“原query”“改写query”“扩展query”分别检索，然后合并结果再重排。

这是一个典型的RAG query处理示例，体现的是“我能识别问题并独立设计解决方案”的工程能力。

3.2 “你的Embedding模型是怎么选的？”

这个问题听起来简单，但答得好的不多。我一般这么说：

先明确约束条件：数据是中文为主还是中英混合？领域是通用还是垂类（如医疗、法律）？向量存储和查询预算大概多少？线上推理机器是CPU还是GPU？

• 中文通用场景，我常用BGE系列（如BGE-large-zh），在中文语义相似度评测上表现稳定。
• 需要兼顾英文和代码，会考虑多语言模型如M3E或BGE-M3。
• 如果不想自己维护模型服务，走OpenAI embedding，但要关注维度、限流和成本。

选型之后我会做离线评测：拿自己评测集里的问题，分别用几个候选模型生成向量，计算召回指标，再看看维度对整个存储和延迟的影响。面试官对“参考公开榜单 + 自建评测集验证”这个组合非常认可。

3.3 “向量数据库怎么选型？”

不要一上来就背组件特性，而是先搞清楚自己的场景。如果业务规模是千万级向量以下、并发量不大，直接选轻量的Qdrant或Chroma，甚至用pgvector配合PostgreSQL，省了运维成本。如果是亿级向量、高并发、高可用，再上Milvus或专门的云向量数据库。

HNSW是个高频考点。你至少要说清楚：

• HNSW相当于一个多层导航小世界图，检索可以近似log复杂度。
• 参数M控制每个节点的最大邻居数，越大召回越高但内存和构建时间也越大；efConstruction控制建图质量；efSearch控制查询时的候选集大小，越大召回越高但延迟越大。
• 索引类型选择上，如果数据量不大，更推荐暴力检索或者IVF，反而简单稳定；数据量大了再上HNSW。

3.4 “RAG与长文本微调怎么选？”

很多面试官会故意制造二选一的局面。回答思路是“不选，而是组合”。当文档库巨长（比如几百页说明书），直接把全文塞进上下文既费Token也可能超限；但微调不可能覆盖所有动态更新的文档。所以RAG是默认首选。但RAG如果效果不理想，可以考虑：

• 精简PDF并抽取关键信息，只保留章节标题、表格、结论部分。
• 对高频问题做Few-shot示例的Prompt缓存，而不是全文塞入。
• 针对特定场景做轻量微调（如LoRA），专门提升生成风格和指令遵循能力，而不是记忆知识。

这样按层把问题拆开，面试官会觉得你有架构判断力。

4. 高频手撕题与系统设计题复盘

4.1 手写一个简易RAG调用链

不少面试会让你现场写一段代码，核心不是考察你用了什么库，而是考察你的代码组织能力和边界处理。

我现场一般会写这样一段示例：

def simple_rag(question, index, docs, llm_api): # 1. query向量化 q_vec = embed([question]) # 2. 检索top-k hit_ids = index.search(q_vec, k=5) # 3. 拼上下文 context = "\n\n".join(docs[i].text for i in hit_ids[:3]) # 4. 生成 prompt = f"请根据以下上下文回答问题。\n上下文：\n{context}\n问题：{question}\n如果上下文没有相关内容，请回答'我没有在资料中找到答案'。" return llm_api(prompt)

然后补充问自己几个问题：如果命中结果为空怎么处理？如果同一份文档被重复切分怎么去重？如果用户一次问多轮对话是否要拼接历史？这些边界说清楚，代码题正确率不高也没关系。

4.2 如何设计一个高可用的线上RAG服务？

系统设计题不要直接画一个大框，而是从需求出发拆解。我会按照“接入层 -> 预处理管道 -> 检索层 -> 排序层 -> 生成层 -> 反馈层”分层讲。

• 接入层：处理QPS、限流、认证、异常兜底。
• 预处理管道：文档上传触发的异步解析与切分、Embedding批量计算，用消息队列削峰。
• 检索层：多路召回（向量+BM25），加缓存降低热点query开销，缓存key可以包含归一化后的query和TopN结果。
• 排序层：Rerank放到独立GPU服务，控制超时和并发。
• 生成层：LLM调用的并发、重试、熔断、流式返回、上下文长度控制。
• 反馈层：记录用户点击、点赞、复制等行为，形成闭环迭代数据集。

再提一句成本优化：向量召回可以提前把索引加载到内存，避免IO；Embedding模型部署可以用ONNX或TensorRT加速；LLM调用如果按Token计费，尽量用缓存和摘要压缩。

衡量标准也别漏掉，比如端到端P95延迟有没有控制在2秒内、检索命中率有没有95%以上、故障时能否降级为“普通LLM对话”模式。

4.3 候选集与评测：手把手讲清一个具体Case

这道题我遇到的概率很高。面试官给一个具体场景：假设你有一个法律问答机器人，用户问“交通事故对方全责，我该如何索赔”，如何从头到尾设计方案并评估效果？

回答：

先确认数据源：法规条款、判例文书、律所FAQ。解析时用结构化模板抽取“法条编号”“适用情形”“赔偿标准”。切分尽量避免把一条完整法条切断，可以用语义切分和规则切分结合。

再说检索：问题“对方全责”提到“责任认定”，可以用BM25匹配“交通事故责任认定书”，再用向量召回“损害赔偿计算方式”“保险理赔流程”。多路合并后重排，取Top3。

生成时Prompt要求“逐条引用法条原文，不得自行解释”。输出后校验引用是否存在，并给“AI生成仅供参考”的免责声明。

评估方面，先构建100条真实用户问题，请法律专家标注参考答案和引用依据。离线看Recall@5和忠实度，线上监测答案收藏率和投诉率。这样做下来，整个方案的完整度会很高，面试官很难不认可。

5. 经验教训与避坑指南

5.1 简历与项目包装的真实陷阱

很多面试挂在简历阶段，因为你写的项目很可能被面试官识破是“抄的Demo”。比如简历上写“利用LangChain搭建客服机器人”，但连LangChain的Agent工具调用机制都说不清，这比不写还危险。

写项目请参考这个思路：每个项目必须有“业务背景 + 技术选型 + 我的核心贡献 + 效果量化”。

我曾经把自己一个改造切分策略的项目写成：

业务背景：知识库中包含大量Markdown表格，固定窗口切分后表格被截断，问答时上下文缺列，效果差。

技术选型：采用“Markdown结构感知切分 + 2048字符窗口 + 128字符重叠”的混合方案，对表格按行和列分块并保留表头元信息。

核心贡献：独立完成切分逻辑重构、离线评测集建设，对比固定切分，表格问答的准确率由62%提升到83%。

效果量化：用户对答案引用点击率提升21%，人工干预率降低15%。

这样写出来的项目，面试官第一印象就是“这人是真的在解决问题，而不是在跑流程”。

5.2 面试中常见的“致命回答”

• “这个功能我直接调API实现的。”——等于告诉面试官你没思考过内部逻辑。哪怕你真的只是调API，也要补充一句“我知道这个API的原理是……”。
• “我试了很多方法，反正最后跑通了。”——等于没有分析和对比。要说出尝试了哪些方法，基于什么标准选择了最终方案。
• “向量效果不好我就加数据。”——没有诊断过程，纯靠堆数据。
• “Prompt调了十条终于满意了。”——没有提到如何评估、如何泛化。

建议面试前做一两次模拟面试，让别人专门攻击你的盲区。你会发现很多自己以为很熟的东西，被追问到第二层就卡住了，这就是面试准备的隐藏价值。

5.3 简历外“软实力”的准备

除了技术本身，还要准备几个软性问题：

凭什么认为这个岗位适合你？你想做RAG还是微调？能不能接受脏活累活，比如数据标注、Bad Case分析？

这些问题没有标准答案，但面试官在判断你的长期稳定性和自驱力。你可以准备一个真实例子，说明你为了解决某个线上问题“推动过跨团队协作”或“主动补充了缺失的评测数据”。具体、可信、不夸张，就够了。

5.4 关于“背题”的正确打开方式

我不是让你别背题，而是让你别傻背。把高频题整理成“问题 -> 思路 -> 关键词 -> 例子”四栏表，然后用口语复述一遍，每道题控制在3分钟内。复述时要有画面感，就像在给同事讲方案，而不是在背书。

我自己的做法是：把每道高频题写成一张卡片，正面写问题，背面画几个关键词和一张草图，然后随机抽卡片直接开讲。等到面试时，你已经形成了条件反射式的叙事结构，紧张感会小很多。

6. 面试后的复盘与offer选择建议

6.1 如何做好面试复盘

面试结束后，趁记忆还热，立刻记录下来：

• 面试官问了哪些问题？哪个问题没答好？
• 哪个问题回答后面试官追问了？说明你的回答有信息增量。
• 哪道题是你完全没准备到方向的？
• 面试官的整体状态，是详细追问还是频繁打断？频繁打断可能你跑题了，详细追问说明你对某个点有勾住他的地方。

定期把复盘笔记整理成一份“面试错题本”，下次之前把错题过一遍。很多问题其实都是换着场景重复出现，积累多了，你自然就有答案库了。

6.2 谈offer与岗位判断的实操心得

我见过太多只问薪资、不关心业务方向的人，入职三个月就后悔。真正合适的判断维度有三层：

第一层，业务判断。公司/团队的RAG场景是不是核心业务？有没有真实流量和数据？如果只是做一个内部Demo，你很难获得成长。

第二层，技术栈判断。团队有没有做底层优化？还是纯粹套壳调API？这对你未来一年能积累什么非常关键。如果团队连Embedding模型都不打算自研，你的角色可能就是一个API编排者，长期来看竞争力受限。

第三层，成长空间判断。有没有负责独立模块的机会？面试你的Leader本身对RAG的理解深不深？能不能在方向上给你有效的指导？

薪资方面，不要只盯总包，还要参考工作时长、成长速度、跳槽溢价能力。大厂稳定性强但可能螺丝钉，小厂灵活但可能什么都要你干，没有绝对好坏。

结合我个人经验，我想分享一个很多人容易忽略的细节：面试中展示自己“会提问”很重要。当面试官介绍完团队业务后，你可以追问“你们目前RAG的召回率大概多少”“你们怎么处理多轮对话中的指代消解”“有没有把评测自动化”，这些问题表明你在思考实际落地中的难点，而不是简单的候选人。

最后再聊点实在的

大模型和RAG方向的面试变化很快，今天热门的工具和方法，可能过半年就被新的取代。所以你有两件事要长期坚持：第一，不要停止写代码，保持至少一个活跃的个人项目；第二，不要停止记录，把你对某个技术点的理解写成文章或笔记，这不仅帮你理清思路，也让你在面试时表达更自然。

我自己每次面试前都会做一次“一天速成冲刺”：把简历里的项目重新讲一遍，把RAG流程画一遍，把高频手撕题默写一遍。这三件事做完，面试时心里就踏实很多。

技术岗面试本质上是一场信任建立，面试官要相信你能在一个模糊的问题中找出路径，并且真的能落地。多拿offer的人往往不是知识量最大的，而是表达最准确的。希望这份面经能帮你把碎片化的努力串成一个体系，然后在自己心仪的岗位面前，从容发挥。