本文深度解析了百度AI Agent开发岗一面面试的18个问题，涵盖了代码Agent工程落地全链路拷打和大模型底层核心原理拷打两大模块。文章通过逐题考点拆解、核心踩坑点复盘、校招满分精简回答等形式，详细阐述了提示词模板设计、Agent架构选型、任务拆分、上下文构建、单测生成与质量评估、mock使用场景、幻觉问题解决等关键知识点。同时，文章还强调了工程化落地能力和底层原理理解的重要性，帮助读者更好地备战AI Agent岗位的面试。

面试全程实录（40 分钟高压拷打，全程无缓冲）

面试官：你好，我是百度智能体研发团队的面试官，先简单做个自我介绍，重点讲一下你简历里的代码Agent项目。

候选人：好的面试官，我是XX大学26届硕士，有两段AI Agent开发实习经历，核心做的是代码理解与单测生成智能体项目，基于ReAct框架实现，能对接代码库、实现代码语义理解、自动生成单测代码，提升研发效率，用了GPT-4o作为底座，配合RAG做代码库检索，提示词做了多轮优化。

面试官：行，那我们先拷打这个项目。先讲一下，你这个项目的提示词模板是怎么设计和迭代的？

候选人：就是先写基础的角色设定，加任务要求，然后看生成效果不好，就改改提示词，多加点要求。

面试官：那你怎么判断一个模板是真的更好了？有没有量化的评估标准？

候选人：…看生成的代码能不能跑通，人工看一下写的对不对。

面试官：只有人工判断？没有体系化的迭代和评估流程？

候选人：…对，主要是人工看效果。

面试官：你们的Agent是单Agent还是多Agent？为什么这么设计？有没有考虑过另一种方案？

候选人：是单Agent，因为场景比较简单，单Agent就能搞定，没考虑过多Agent的方案。

面试官：那Agent的任务是怎么拆分的？拆分粒度是怎么决定的？

候选人：就是让大模型自己拆分，按代码的函数粒度拆，粒度没怎么特意定，看模型自己输出。

面试官：上下文是怎么构建的？你们怎么避免上下文过长或者信息污染？

候选人：就是把代码、提示词、生成的内容拼到一起，过长了就截断，只保留最近的内容。

面试官：如果上下文窗口不够，你优先保留哪些信息？为什么？

候选人：优先保留提示词和最新的代码，因为这些最重要。

面试官：就这些？没有优先级排序的逻辑？

候选人：…没有。

面试官：你们做代码理解的时候，AST、调用关系这些信息是怎么用起来的？

候选人：…AST就是解析了一下代码结构，没怎么深度用，调用关系也没做处理。

面试官：那单测生成里，哪些代码其实不适合生成单测？你们是怎么识别并过滤的？

候选人：…没做过滤，所有函数都让模型生成单测。

面试官：覆盖率高但测试质量很差，这种情况你见过吗？你们是怎么解决的？

候选人：见过，但是没什么好的解决办法，只能改提示词让模型好好写。

面试官：mock在单测里什么时候是必须的？什么时候反而会带来问题？

候选人：…有外部依赖的时候要mock，其他的不太清楚。

面试官：如果一个函数依赖数据库和RPC，你怎么让模型生成的单测还能稳定运行？

候选人：让模型mock掉这些依赖，具体怎么实现没深入做过。

面试官：你们怎么评估生成单测的质量？除了覆盖率，还有哪些指标？

候选人：主要看覆盖率，还有能不能编译通过、跑通，其他指标没考虑过。

面试官：行，项目拷打先到这，问点基础原理。LLM的输入到底是什么？模型真正看到的是什么？

候选人：就是我们输入的文本，模型看到的是token。

面试官：token之后呢？模型真正处理的是什么？

候选人：…不太清楚了。

面试官：self attention的核心作用是什么？为什么要拆成QKV？为什么attention可以建模长距离关系？

候选人：self attention就是计算token之间的相关性，拆QKV是为了计算注意力，能捕捉长距离的依赖。

面试官：为什么需要multi-head？为什么attention可以看成动态加权？

候选人：multi-head能捕捉不同维度的信息，动态加权就是给不同token加不同权重。

面试官：同一个token的Q、K、V为什么不一样？

候选人：…因为用了不同的权重矩阵？具体为什么不太清楚。

面试官：attention复杂度很高，如果上下文特别长，你会怎么优化？

候选人：截断上下文，其他的优化方法没了解过。

面试官：最后一个问题，模型产生幻觉的时候，一般是什么原因？工程上有什么办法降低？

候选人：原因是模型训练数据不够，工程上改提示词，加RAG检索。

面试官：还有吗？

候选人：…暂时想不到了。

面试官：行，我的问题问完了，你有什么要问我的吗？

候选人：想问一下，这个岗位对校招同学的核心要求是什么？

面试官：第一，工程化落地能力，你做的项目，要能讲清每一个环节的设计逻辑、迭代方法、评估标准，不是只会让大模型生成内容；第二，底层原理要吃透，不管是Agent架构，还是大模型的底层实现，不能只停留在会用的层面；第三，解决问题的能力，面对业务痛点，要有体系化的解决方案，而不是只会改提示词。

候选人：好的，谢谢面试官。

（面试结束2天后，收到感谢信）

逐题深度拆解｜考点+踩坑点+校招满分精简回答

这18道题，完全贴合百度代码Agent开发岗的招聘要求，分为两大模块：代码Agent工程落地全链路拷打、大模型底层核心原理拷打，每一题我都给你拆解清楚，面试直接复用。

一、代码Agent工程落地全链路拷打｜面试凉掉的核心重灾区

这部分是整场面试的核心，也是90%同学凉掉的原因：做了代码Agent项目，但讲不清每一个环节的设计逻辑、迭代方法、评估标准，只会依赖大模型生成内容，没有工程化的思考和落地能力，这也是大厂代码Agent岗最看重的核心能力。

1. 提示词模板是怎么设计和迭代的？你怎么判断一个模板是真的更好了？

核心考点：考察提示词工程的体系化能力，区分“瞎改提示词”和“有章法的提示词迭代”，这是Agent落地最基础的能力。

核心踩坑点：只说“看效果改提示词、人工判断好坏”，讲不清设计框架、迭代流程、量化评估标准，被判定为没有体系化的工程能力。

满分精简回答：

我的提示词模板是基于CRISPE提示词框架设计的，核心分为6个固定模块：角色设定、背景信息、指令任务、输入输出格式、约束规则、Few-Shot示例，保证模板的结构完整、逻辑清晰。
模板的迭代，我采用的是**“问题定位→变量控制→AB测试→量化评估”**的闭环流程：
1.先汇总bad case，定位是角色设定不清晰、约束规则缺失、还是示例不匹配导致的效果问题；
2.采用变量控制法，每次只修改模板里的一个模块，避免多个变量同时改动导致无法定位效果变化的原因；
3.搭建固定的测试集，做AB测试，保证迭代效果的可复现性；
4.通过量化指标评估模板是否真的更优，而非纯人工判断。
核心评估指标分为4个维度，优先级从高到低：
1.功能达标率：生成的单测代码是否符合核心要求，比如是否覆盖了核心逻辑、是否正确处理了边界条件，这是最核心的指标；
2.可执行通过率：生成的代码能否正常编译、无语法错误、单测能正常运行，不出现编译报错；
3.格式合规率：是否严格遵循了预设的输出格式，不出现多余的文本、格式错误，减少后续的代码解析成本；
4.执行效率：生成的单测代码执行时长、token消耗，在效果达标的前提下，降低冗余内容和token消耗。
迭代后，模板的功能达标率从最初的55%提升到了90%以上，格式合规率达到了98%。

2. 你们的Agent是单Agent还是多Agent？为什么这么设计？有没有考虑过另一种方案？

核心考点：考察你对Agent架构的选型思考能力，看你是随便选个架构，还是基于业务场景做的合理选型。

核心踩坑点：只说“场景简单用了单Agent”，讲不清选型依据，也没考虑过其他方案，被判定为对Agent架构没有深度思考。

满分精简回答：

我们的代码Agent项目，V1.0版本采用的是单Agent架构，V2.0版本迭代为了多Agent协同架构，选型完全是基于业务场景的痛点和需求决定的。
一、V1.0单Agent架构的选型原因
项目初期，核心需求是实现“单函数输入→单测代码生成”的简单场景，链路短、逻辑单一，单Agent完全能满足需求。
优势：架构简单、开发迭代速度快、链路延迟低、维护成本低，适合MVP验证和简单场景；
劣势：复杂场景下能力不足，比如全量代码库的单测生成、多文件依赖的代码理解，单Agent容易出现逻辑混乱、上下文溢出、任务遗漏的问题。
二、V2.0多Agent架构的选型原因
随着项目迭代，我们需要支持全项目代码库的批量单测生成、复杂依赖的代码理解、单测质量校验与优化，单Agent已经无法满足需求，所以迭代为了多Agent架构，拆分了4个职责明确的子Agent：
1.代码解析Agent：负责解析代码库的AST、函数调用关系、依赖关系、类结构，提取核心代码信息，过滤无效代码；
2.单测生成Agent：专注于单测代码生成，基于解析后的代码信息，生成符合规范的单测代码；
3.单测校验Agent：负责校验生成的单测代码，检查语法错误、覆盖率、边界条件覆盖、mock合理性，输出优化建议；
4.单测优化Agent：基于校验建议，优化单测代码，修复问题，提升单测质量。
四个子Agent通过工作流串联，各司其职，比单Agent的效果提升非常明显，单测功能达标率从70%提升到了92%。
我们在选型前，完整评估了两种方案的优缺点、适配场景、开发成本和维护成本，最终基于业务的发展阶段和需求，做了对应的架构选型，而非盲目选择多Agent架构。

3. Agent任务是怎么拆分的？拆分粒度是怎么决定的？

核心考点：考察Agent规划能力的落地设计，这是复杂任务型Agent的核心能力，区分demo和工业级落地的关键。

核心踩坑点：只说“让大模型自己拆分”，讲不清拆分逻辑、粒度控制规则，没有工程化的设计。

满分精简回答：

我们的Agent任务拆分，采用的是**“人工预设规则+大模型动态拆分+边界校验”**的三级方案，而非完全让大模型自由拆分，保证拆分的合理性、可执行性，避免任务遗漏、粒度过粗/过细的问题。
一、核心拆分逻辑
针对代码单测生成的场景，我们遵循**“高内聚、低耦合、可独立执行、可结果校验”**的四大拆分原则，核心拆分逻辑：
1.顶层拆分：以代码文件为第一拆分维度，一个代码文件拆分为一个独立的大任务，避免跨文件的依赖混乱；
2.中层拆分：在单个文件内，以类/模块为第二拆分维度，一个独立的类拆分为一个子任务；
3.底层拆分：在单个类内，以函数/方法为最小执行单元，一个独立的函数拆分为最小执行子任务，保证每个子任务都能独立执行、独立校验结果。
二、拆分粒度的决定规则
拆分粒度不是固定的，我们通过3个核心维度动态决定，避免两个极端：粒度过粗导致大模型无法处理、上下文溢出；粒度过细导致任务碎片化、执行效率低、上下文断裂。
1.代码复杂度维度：通过圈复杂度、代码行数、依赖数量，判断代码的复杂度。复杂度高的函数，单独作为一个子任务；复杂度极低的工具函数，可合并为一个子任务，避免任务碎片化；
2.上下文依赖维度：强依赖的函数/类，合并为一个子任务，保证大模型能拿到完整的依赖信息，避免上下文断裂；无依赖的独立函数，拆分为独立子任务，降低单个任务的复杂度；
3.大模型上下文窗口维度：保证单个子任务的代码内容+提示词+输出内容，总token数不超过模型上下文窗口的50%，预留足够的生成空间，避免上下文溢出。

4. 上下文是怎么构建的？你们怎么避免上下文过长或者信息污染？

核心考点：考察Agent上下文管理的工程化能力，这是长任务Agent落地的核心痛点，也是面试高频考点。

核心踩坑点：只说“把内容拼到一起，过长就截断”，讲不清上下文构建的逻辑、信息过滤和污染规避方案。

满分精简回答：

我们的上下文构建，采用的是**“分层构建、按需注入、动态过滤、权限分级”**的方案，同时通过多维度的信息管控，避免上下文过长和信息污染。
一、上下文的分层构建逻辑
我们把上下文分为4个固定层级，按优先级从高到低排列，每次推理前，按层级动态拼接注入：
1.系统核心层：固定的系统提示词、角色设定、核心规则、输出格式要求，永远放在上下文最顶部，不会被截断和过滤；
2.任务核心信息层：当前任务的核心目标、核心代码内容、核心依赖信息、约束条件，是当前任务必须的核心信息；
3.历史执行上下文层：当前任务的历史执行步骤、工具调用结果、已生成的内容，按时间倒序排列；
4.辅助参考信息层：相关的代码规范、单测编写规范、同类示例，非必须的辅助信息。
二、避免上下文过长和信息污染的核心方案
1.按需注入，而非全量注入：不是把所有代码、所有信息都塞进上下文，而是基于当前子任务，只注入和当前任务强相关的代码、依赖信息，无关信息完全不注入，从源头减少上下文长度和无效信息；
2.信息分级过滤，避免无效信息注入：对所有要注入的信息做分级，核心信息必须注入，辅助信息只在需要的时候注入，无效信息直接过滤。比如代码里的注释、空行、无效的get/set方法，直接过滤掉，只保留核心业务逻辑代码，既减少token占用，也避免无效信息导致的信息污染；
3.历史上下文摘要压缩：对历史执行上下文，每完成3个步骤，就做一次增量摘要，只保留核心执行结果和关键信息，替代完整的历史内容，大幅降低上下文长度，同时避免无关的历史内容污染当前的生成逻辑；
4.滑动窗口+核心信息置顶：对必须保留的完整历史对话，采用动态滑动窗口，只保留最近3轮的完整内容；同时把任务核心目标、核心规则固定置顶，永远不会被截断，避免模型忘记核心任务，出现逻辑偏离；
5.严格的格式约束，避免无效内容注入：通过提示词约束和后置过滤，严格限制大模型的输出格式，避免生成多余的闲聊内容、无效解释，只保留核心的代码和必要的说明，减少无效内容对后续上下文的污染。

5. 如果上下文窗口不够，你优先保留哪些信息？为什么？

核心考点：考察你对Agent任务执行的核心逻辑理解，看你能不能抓住任务执行的核心矛盾，做出合理的优先级决策。

核心踩坑点：只说“保留提示词和最新代码”，讲不清优先级排序的逻辑和背后的原因。

满分精简回答：

如果上下文窗口不足，我会按照**“任务不偏离→结果可执行→逻辑可回溯”**的核心原则，按以下优先级保留信息，优先级从高到低，同时保证保留的总内容不超过窗口上限的70%，预留足够的生成空间。
1.第一优先级：系统核心提示词与任务核心目标
这是任务执行的根本，必须100%完整保留，永远放在上下文最顶部。如果这部分信息缺失，模型会直接忘记角色设定、输出规则、核心任务目标，出现严重的逻辑偏离、幻觉、格式错误，哪怕生成的内容再多，也是无效的。
2.第二优先级：当前子任务的核心输入与强依赖信息
也就是当前需要处理的核心代码、函数逻辑、强依赖的代码片段，这是当前任务的处理对象，必须完整保留。没有这部分信息，模型就失去了处理的目标，无法生成符合要求的内容，这是任务执行的基础。
3.第三优先级：当前任务最近2轮的完整执行结果与工具返回内容
优先保留最近的、和当前步骤强相关的执行结果，尤其是工具调用的返回内容、代码执行的报错信息。因为Agent的执行是链路式的，下一步的执行依赖上一步的结果，保留最近的完整执行结果，能保证执行链路的连贯性，避免模型重复执行、逻辑断裂。
4.第四优先级：历史执行链路的核心摘要
更早的历史执行内容，不会保留完整文本，只保留增量摘要后的核心结论、关键决策、已完成的任务节点。既让模型知道整体的执行进度和历史关键信息，避免重复工作，又大幅降低了token占用，同时过滤掉了历史的无效信息，避免信息污染。
5.最低优先级：辅助参考信息、非强依赖的代码片段、更早的完整历史内容
这部分信息在窗口不足时，会优先舍弃。因为这些信息只是辅助优化效果，不是任务执行的必须内容，舍弃后只会影响生成效果的上限，不会影响任务的核心执行和结果的可用性。

6. 你们做代码理解的时候，AST、调用关系这些信息是怎么用起来的？

核心考点：考察你对代码理解场景的深度落地能力，看你是只会把代码文本丢给大模型，还是能通过代码解析技术，真正提升代码理解的效果，这是代码Agent的核心竞争力。

核心踩坑点：只说“解析了AST”，讲不清具体的使用场景和落地方法，被判定为对代码理解场景没有深度落地。

满分精简回答：

在代码理解场景中，AST（抽象语法树）和函数调用关系，是我们提升代码理解准确率、降低大模型幻觉、减少上下文占用的核心工具，我们主要在5个核心场景深度使用，完全不是只做简单解析。
1.精准代码分块与核心信息提取
通过AST解析，我们能精准识别代码里的类、方法、函数、变量定义、注释，精准拆分代码块，而非简单的按行数分块。同时能自动过滤掉无效的空行、注释、重复代码、无业务逻辑的工具方法，只提取核心业务逻辑代码，注入大模型上下文，既减少了token占用，又避免了无效信息导致的理解偏差和信息污染。
2.依赖关系与调用链路梳理
通过AST解析和静态代码分析，我们能构建完整的函数调用关系图、类继承关系、依赖导入关系。在处理某个函数的单测生成时，能精准提取这个函数的直接依赖、间接依赖、调用链路，只把强相关的依赖代码注入上下文，而非把整个文件、整个项目的代码都塞进去，既解决了上下文过长的问题，又让大模型能完整理解函数的执行逻辑和依赖关系，生成的单测更贴合实际业务场景。
3.代码复杂度与核心逻辑识别
通过AST，我们能计算代码的圈复杂度、分支数量、边界条件数量，精准识别代码的核心逻辑分支、异常处理分支、边界条件。在单测生成时，我们会把这些信息作为强制要求，注入提示词，让大模型必须覆盖这些核心分支和边界条件，从规则上保证单测的质量，解决了“覆盖率高但测试质量差”的问题。
4.代码语义匹配与RAG检索增强
我们会把解析后的AST结构、函数名、参数、返回值、注释，生成结构化的文本，再做embedding存入向量库。用户查询相关代码时，我们不仅做文本语义匹配，还会做AST结构匹配、函数签名匹配，大幅提升代码检索的准确率，让大模型能拿到更精准的参考代码，提升代码理解和生成的效果。
5.生成结果的校验与纠错
大模型生成单测代码后，我们会先通过AST解析生成的代码，检查语法是否正确、是否有语法错误、是否正确调用了目标函数、mock的依赖是否符合原代码的调用关系，提前过滤掉有语法错误、逻辑错误的代码，减少人工校验成本，同时把校验结果反馈给大模型，做自动优化修正。

7. 单测生成里，哪些代码其实不适合生成单测？你们是怎么识别并过滤的？

核心考点：考察你对单测生成业务场景的深度理解，看你有没有真实的落地经验，而非只会让大模型无脑生成单测。

核心踩坑点：说不出不适合生成单测的代码类型，也没有对应的识别过滤方案，被判定为没有真实的工业级落地经验。

满分精简回答：

在单测生成的落地场景中，不是所有代码都适合生成单测，强行生成不仅会导致单测质量极低，还会浪费大量的算力和token，甚至会引入无效的测试用例，影响研发效率。我们总结了6类不适合生成单测的代码，同时做了对应的自动识别和过滤方案。
一、不适合生成单测的代码类型与识别方案
1.无业务逻辑的胶水代码/纯工具代码
比如简单的get/set方法、DTO/POJO实体类、常量定义类、无逻辑的参数转发方法，这类代码没有核心业务逻辑，生成单测没有任何业务价值，反而会增加维护成本。
识别方案：通过AST解析，判断代码的圈复杂度是否为0、是否没有分支逻辑、是否没有业务计算和处理逻辑，自动识别并过滤。
2.强依赖外部环境的集成测试类代码
比如直接操作数据库的DAO层代码、直接调用第三方RPC接口的服务代码、直接操作中间件的代码，这类代码的运行强依赖外部环境，属于集成测试的范畴，不适合用单元测试来覆盖，强行生成会导致单测无法稳定运行，必须大量mock，反而失去了单测的意义。
识别方案：通过AST解析和依赖分析，识别代码中是否有数据库操作、RPC调用、中间件操作的相关依赖和方法调用，自动标记为集成测试代码，过滤掉单测生成范围。
3.频繁变动的临时代码/测试代码
比如临时的调试代码、业务上线前的临时兼容代码、测试用的demo代码，这类代码生命周期短、频繁变动，生成单测的维护成本极高，刚生成完代码就可能变更了，没有长期价值。
识别方案：通过代码注释、git提交记录、代码所在的包路径（比如test包、temp包），自动识别并过滤。
4.极度复杂的底层框架代码/算法代码
比如底层的加密算法、分布式框架的核心调度代码、高性能计算代码，这类代码逻辑极度复杂，对单测的精度、边界条件覆盖要求极高，大模型很难完全理解其核心逻辑和边界条件，生成的单测质量极差，甚至会出现错误的测试用例，反而会掩盖代码bug。
识别方案：通过圈复杂度计算、代码行数、分支数量，识别超高复杂度的代码，标记为人工编写单测范围，自动过滤。
5.已经废弃/即将下线的代码
比如标记了@Deprecated的废弃方法、已经下线的业务相关代码，这类代码后续会被删除，生成单测没有任何价值。
识别方案：通过AST解析代码中的废弃注解、注释中的废弃标记，自动识别并过滤。
6.UI相关的渲染代码/前端交互代码
比如前端的页面渲染代码、UI组件代码，这类代码的效果强依赖UI渲染环境，单元测试很难覆盖其核心效果，更适合用E2E自动化测试，不适合生成单元测试。
识别方案：通过代码的语言类型、文件后缀、依赖的UI框架，自动识别并过滤。
二、整体过滤流程
单测生成前，我们会先对目标代码做全量的静态扫描和AST解析，通过上述规则自动识别并过滤不适合生成单测的代码，只对符合要求的业务逻辑代码生成单测，既保证了单测的业务价值，又提升了生成效率，避免了无效的资源消耗。

8. 覆盖率高但测试质量很差，这种情况你见过吗？你们是怎么解决的？

核心考点：考察你对单测生成核心痛点的理解和解决能力，这是工业级代码Agent落地必须解决的问题，也是面试高频拷打点。

核心踩坑点：只说“改提示词让模型好好写”，讲不清问题的根因和体系化的解决方案，被判定为没有解决真实业务痛点的能力。

满分精简回答：

这个问题是单测生成场景最核心的痛点，我们在项目初期就频繁遇到，很多生成的单测行覆盖率能达到90%以上，但完全没有覆盖核心业务逻辑和边界条件，只是为了覆盖行数而写，甚至出现了“空断言、无效断言、硬编码绕过逻辑”的问题，看似覆盖率很高，实则完全没有测试效果，无法发现代码bug。
我们先定位了这个问题的核心根因，主要有3点：
1.大模型只关注“覆盖代码行”，不理解代码的核心业务逻辑和测试重点；
2.没有给大模型明确的单测质量标准和校验规则，只要求覆盖率；
3.没有后置的质量校验环节，无法识别低质量的单测，也无法做自动优化。
针对这些根因，我们做了体系化的解决方案，从“事前约束、事中控制、事后校验优化”三个环节，彻底解决这个问题：
一、事前约束：明确单测质量标准，从源头引导模型
1.在提示词中，明确要求单测必须**“以业务逻辑为核心，优先覆盖核心分支、边界条件、异常处理场景”**，而非优先覆盖代码行数，同时明确了单测的编写规范，禁止空断言、无效断言、硬编码绕过逻辑的行为；
2.通过AST解析，提前提取代码的核心业务分支、边界条件、异常处理分支、圈复杂度高的逻辑块，作为强制覆盖要求，注入提示词，要求大模型必须为这些场景设计对应的测试用例，从规则上保证单测的核心测试重点；
3.加入高质量的Few-Shot示例，展示“高覆盖率+高质量”的单测写法，和“高覆盖率低质量”的反面案例，让大模型明确好坏标准。
二、事中控制：分步骤生成，避免为了覆盖率凑行数
我们把单测生成从“一步生成”，改成了“测试用例设计→单测代码生成”的两步流程：
第一步，先让大模型基于代码逻辑，设计测试用例，明确每个测试用例的测试场景、输入、预期输出，重点覆盖核心业务逻辑和边界条件，我们先校验测试用例的合理性，过滤掉无效的测试用例；
第二步，基于校验通过的测试用例，生成对应的单测代码，避免大模型为了凑覆盖率，无脑生成无效的测试用例。
三、事后校验与优化：自动化质量校验+闭环优化
1.多维度质量自动化校验：单测生成后，我们不仅看行覆盖率，还新增了4个核心质量指标：分支覆盖率、条件覆盖率、MC/DC覆盖率、核心场景覆盖率，只有这些指标都达标，才认为单测质量合格；同时通过AST解析，自动识别空断言、无效断言、硬编码等低质量问题，标记不合格的单测；
2.自动优化闭环：对校验不合格的单测，我们会把质量问题、覆盖率缺口、核心场景遗漏点，反馈给大模型，让它自动优化修正单测代码，最多重试2次，形成完整的优化闭环；
3.bad case持续迭代：把低质量的单测案例，持续加入到提示词的反面案例中，同时优化提示词和校验规则，持续提升单测的质量。
通过这套方案，我们在保证单测行覆盖率80%以上的同时，分支覆盖率从原来的40%提升到了85%以上，核心业务场景覆盖率达到了90%，彻底解决了“高覆盖率低质量”的问题。

9. mock在单测里什么时候是必须的？什么时候反而会带来问题？

核心考点：考察你对单测编写的专业理解，区分“只会让模型加mock”和“真正懂单测设计的工程师”，这是代码Agent岗必问的考点。

核心踩坑点：只说“有外部依赖的时候要mock”，讲不清mock的适用边界和负面影响，对单测设计的理解不到位。

满分精简回答：

mock的核心本质，是对测试范围外的依赖对象，创建一个模拟的对象，隔离外部依赖，让单测能专注于被测代码的核心逻辑，稳定、可重复地执行。它不是万能的，有明确的适用场景和负面场景，用错了反而会导致单测完全失去意义。
一、mock必须使用的场景
1.被测代码强依赖不可控的外部系统/服务
比如被测代码依赖第三方RPC接口、数据库、缓存、消息中间件、外部API，这些外部依赖的环境不稳定、数据不可控，甚至测试环境无法访问，必须用mock模拟这些依赖的行为，才能让单测在本地稳定、可重复地执行，不受外部环境影响。
2.被测代码依赖的对象构建成本极高、速度极慢
比如被测代码依赖一个复杂的基类、需要几十个参数才能构建的对象、初始化需要很长时间的组件，直接构建真实对象会导致单测执行效率极低、编写成本极高，用mock可以快速模拟对象的行为，大幅降低单测的编写和执行成本。
3.被测代码的异常分支、边界场景，真实依赖很难触发
比如被测代码里的网络异常、数据库超时、RPC调用失败的异常处理逻辑，用真实依赖很难触发这些场景，无法覆盖对应的分支。用mock可以轻松模拟这些异常场景，验证代码的异常处理逻辑是否正确，提升单测的分支覆盖率。
4.被测代码依赖的模块还未开发完成，需要并行开发测试
比如在项目开发中，被测代码依赖的下游模块还在开发中，我们可以通过mock模拟下游模块的接口行为，提前完成被测代码的开发和单测编写，实现并行开发，提升研发效率。
二、mock会带来问题、应该避免使用的场景
1.被测代码的核心业务逻辑、核心依赖，不应该mock
如果mock了被测代码的核心逻辑、核心计算模块，单测就变成了测试mock对象，而不是被测代码本身，哪怕单测跑通了，也无法验证真实代码的逻辑是否正确，完全失去了单测的意义。比如一个订单金额计算的核心函数，不能mock里面的金额计算逻辑，只能mock非核心的外部依赖。
2.简单的、无外部依赖的工具类/纯函数，不应该mock
比如日期处理、字符串处理、数学计算这类纯函数，本身没有外部依赖，执行速度快、逻辑稳定，直接使用真实对象即可，mock反而会增加单测的编写成本，还可能因为mock的行为和真实函数不一致，导致单测出现误判。
3.可以通过测试替身、内存版本替代的依赖，优先不用mock
比如数据库依赖，优先使用H2等内存数据库，而非mock DAO层；比如Redis依赖，优先使用本地内存版的Redis模拟，而非mock Redis操作。用真实的轻量版本替代，比mock更能验证代码的真实逻辑，mock会导致和真实运行环境的行为不一致，出现“单测全过，线上全崩”的问题。
4.跨模块的集成测试场景，不应该大量mock
集成测试的核心目标，是验证多个模块之间的协同工作是否正常，大量mock会导致集成测试失去意义，无法发现模块之间的接口兼容、调用链路的问题。
5.频繁变动的接口/逻辑，不应该mock
如果被mock的接口、逻辑频繁变动，mock的行为需要跟着同步修改，会导致单测的维护成本极高，很容易出现mock的行为和真实接口不一致，导致单测误判，反而增加了工作量。

10. 如果一个函数依赖数据库和RPC，你怎么让模型生成的单测还能稳定运行？

核心考点：考察你解决单测生成真实落地痛点的能力，是工业级代码Agent必须解决的问题，面试高频考点。

核心踩坑点：只说“让模型mock掉依赖”，讲不清完整的落地方案，无法保证单测的稳定运行。

满分精简回答：

对于依赖数据库和RPC的函数，要让模型生成的单测能稳定运行，核心原则是**“隔离外部依赖、统一mock规范、前置依赖信息注入、后置执行校验”**，通过体系化的方案，让大模型生成符合规范、可稳定执行的单测，而非只让模型随便mock。
完整的落地方案分为4个核心环节：
一、前置依赖解析与信息提取，给模型充足的上下文
大模型生成的mock不符合要求、单测无法运行，最核心的原因是模型不知道依赖的接口定义、入参出参、返回格式，只能瞎编mock。所以在生成单测前，我们会先做完整的依赖解析，提取核心信息，注入上下文：
1.RPC依赖解析：通过接口定义文件（比如protobuf、jar包），解析出RPC接口的全限定名、方法名、入参出参结构、返回值类型、异常类型，提取完整的接口定义；
2.数据库依赖解析：通过DAO层代码、Mybatis的Mapper文件、数据库表结构，解析出数据库操作的方法、对应的表结构、SQL操作类型、返回值类型；
3.依赖调用链路解析：通过AST静态分析，明确被测函数中，在什么逻辑分支、什么场景下，会调用这些RPC和数据库方法，以及对返回值的处理逻辑，明确mock的场景和返回值要求。
我们会把这些解析后的结构化信息，完整注入提示词，让大模型完全掌握依赖的完整定义，从源头避免瞎编mock的问题。
二、明确mock规范与框架约束，统一生成标准
我们会在提示词中，明确指定单测使用的mock框架（比如Java的Mockito、Python的unittest.mock），同时制定严格的mock规范，让大模型严格遵循，避免生成不规范、无法运行的mock代码：
1.mock的生命周期规范：明确要求在@BeforeEach/setUp方法中初始化mock对象，注入到被测类中，在@AfterEach/tearDown方法中重置mock对象，避免单测之间的相互影响；
2.mock行为规范：明确要求“什么时候调用、返回什么值”的精准匹配，比如when(service.method(param)).thenReturn(result)，必须和被测代码中的调用参数、场景匹配；同时要求针对正常场景、异常场景，分别mock对应的返回值和异常；
3.禁止过度mock：明确要求只mock数据库和RPC的外部依赖，不能mock被测函数的内部方法、核心业务逻辑，保证单测的有效性；
4.可执行性规范：mock的返回值必须符合接口的出参结构，不能出现类型不匹配、结构不一致的问题，保证代码能正常编译运行。
三、分场景引导生成，覆盖完整的测试场景
我们会引导大模型，针对不同的测试场景，生成对应的mock逻辑，保证单测既能稳定运行，又能覆盖核心逻辑：
1.正常业务场景：mock数据库和RPC接口的正常返回值，和被测代码的业务逻辑匹配，验证核心流程的正确性；
2.边界值场景：mock空返回值、临界值返回结果，验证代码的边界处理逻辑；
3.异常处理场景：mock数据库超时、RPC调用失败、抛出异常的场景，验证代码的异常处理逻辑是否正确；
4.分支逻辑场景：针对被测代码的不同分支，mock对应的返回值，触发对应的分支逻辑，保证分支覆盖率。
四、后置编译校验与自动修复，保证单测可稳定运行
1.单测代码生成后，我们不会直接交付，而是会做两层校验和自动修复，保证单测能稳定运行：
2.静态编译校验：通过编译器、静态代码检查工具，检查单测代码的语法是否正确、mock框架的使用是否规范、类型是否匹配，有没有编译错误，有问题则把错误信息反馈给大模型，自动修复；
3.mock行为校验：通过AST解析，检查mock的方法、参数、返回值，是否和真实的接口定义一致，是否和被测代码的调用链路匹配，避免mock的行为和真实调用不一致，导致单测无法运行；
4.本地 dry run 执行：在本地测试环境中，执行生成的单测，检查是否能正常初始化、无运行时异常、mock是否生效，执行失败则把报错信息反馈给大模型，自动优化修复。
通过这套方案，我们生成的依赖数据库和RPC的单测，编译通过率达到了98%，单测稳定执行通过率达到了92%以上。

11. 你们怎么评估生成单测的质量？除了覆盖率，还有哪些指标？

核心考点：考察你对单测质量的体系化评估能力，区分“只看覆盖率”和“懂单测质量体系”的工程师，这是大厂非常看重的能力。

核心踩坑点：只说“看覆盖率、能不能跑通”，讲不出其他的评估指标，没有体系化的评估思维。

满分精简回答：

我们对生成单测的质量评估，搭建了一套**“可执行性→有效性→可维护性→业务价值”**的四层评估体系，覆盖率只是其中一个基础指标，还有10个核心评估指标，全面衡量单测的质量。
一、基础层：可执行性指标（单测的基础门槛）
这是单测质量的最低要求，不达标则单测完全无效。
1.编译通过率：生成的单测代码能否正常编译，无语法错误、类型错误、依赖缺失，这是最基础的指标；
2.稳定执行通过率：单测能否在本地环境稳定、无报错地执行完成，不出现运行时异常、环境依赖问题，且多次执行的结果一致，无 flaky test（抖动测试）；
3.mock规范符合率：mock的使用是否符合规范，是否只mock了外部依赖，没有mock被测核心逻辑，mock的行为和真实接口一致。
二、核心层：有效性指标（单测的核心价值）
这是单测质量的核心，决定了单测能不能真正发现代码bug，覆盖率只是这个维度的基础指标。
1.多维度覆盖率指标：除了最基础的行覆盖率，我们更看重3个更高要求的覆盖率指标：
2.分支覆盖率：是否覆盖了代码的所有if/else、switch等分支逻辑；
3.条件覆盖率：是否覆盖了每个布尔表达式的true/false所有情况；
4.核心业务场景覆盖率：是否覆盖了代码的核心业务流程、边界条件、异常处理场景，这是最核心的指标，比代码覆盖率更重要。
5.bug检出率：这是衡量单测有效性的黄金指标。我们会通过变异测试，在被测代码中注入人工bug（比如修改运算符、边界条件、逻辑分支），看生成的单测能否发现这些bug，能检出的bug占比越高，单测的有效性越强；
6.断言有效性：检查单测是否有明确、有效的断言，禁止空断言、恒真断言、和业务逻辑无关的无效断言，统计有效断言的占比，避免“为了跑通而写单测”的问题。
三、工程层：可维护性指标（单测的长期价值）
这决定了生成的单测能否在项目中长期使用，而不是一次性的无效代码。
1.代码规范符合率：单测代码是否符合团队的编码规范，命名是否清晰、注释是否完整、结构是否合理，有没有冗余代码；
2.可维护性评分：通过圈复杂度、代码重复率、方法行数等指标，计算单测代码的可维护性评分，避免生成过于复杂、难以维护的单测代码；
3.场景可读性：单测的测试场景是否清晰，通过方法名、注释能明确看出每个单测的测试场景、预期结果，后续代码变更时，能快速修改和维护。
四、业务层：业务价值指标（单测的最终意义）
1.业务逻辑匹配度：单测的测试场景是否和真实的业务场景匹配，是否覆盖了线上的核心使用流程，能否真正预防线上业务bug；
2.研发提效效果：生成的单测能否替代人工编写，降低人工编写单测的时间成本，同时在代码回归、变更评审中，真正帮助研发发现问题，提升研发效率和代码质量。

二、大模型底层核心原理拷打｜大厂AI岗的入场门槛

这部分是大厂AI岗面试的必考题，哪怕你做的是工程化落地，也必须吃透大模型的底层原理，不能只停留在调用API的层面，这是区分API调用工程师和AI工程师的核心标准。

12. LLM的输入到底是什么？模型真正看到的是什么？

核心考点：考察你对LLM数据处理全流程的基础理解，是大模型原理最基础的问题，答不上来直接会被判定为基础不牢。

核心踩坑点：只说“模型看到的是token”，讲不清完整的输入处理流程，对token之后的处理一无所知。

满分精简回答：

我们给LLM输入的自然语言文本，会经过完整的预处理流程，最终模型真正处理和“看到”的，是高维的词嵌入向量（Token Embedding）+ 位置编码（Positional Encoding），完整的输入处理流程分为4步：
1.文本归一化与预处理
首先会对输入的文本做预处理，包括大小写转换、特殊字符处理、空格规范化、中英文分词预处理等，把原始文本处理成符合模型要求的标准化文本。
2.分词（Tokenization）
用模型对应的分词器（Tokenizer），把预处理后的文本，拆分成模型词表中对应的最小单元Token，比如英文的子词、中文的字/词，然后把每个Token映射成词表中对应的整数ID，也就是Token ID序列。这一步，我们输入的文本就变成了一串连续的整数ID，这是模型能处理的基础格式。
3.词嵌入（Token Embedding）
模型会通过嵌入层（Embedding Layer），把每个Token ID，映射成一个固定维度的高维稠密向量，也就是词嵌入向量。这个向量里编码了Token的语义信息、语法信息，语义越相似的Token，对应的向量在高维空间中的距离越近。这一步，整数ID序列就变成了模型能做数学计算的向量序列，这是模型真正“看到”的核心基础数据。
4.位置编码（Positional Encoding）
Transformer模型本身无法捕捉文本的顺序信息，所以会给每个Token的嵌入向量，加上对应的位置编码，编码这个Token在文本中的位置信息。最终输入到Transformer编码器中的，是词嵌入向量+位置编码的融合向量，模型会基于这个融合向量，做后续的注意力计算和特征提取。
简单总结：我们输入的是自然语言文本，模型经过预处理、分词、嵌入、位置编码后，真正处理的是融合了语义信息和位置信息的高维向量序列，而非原始的文本或单纯的Token ID。

13. self attention的核心作用是什么？为什么要拆成QKV？为什么attention可以建模长距离关系？

核心考点：Transformer的核心原理，LLM面试必考题，没有之一，必须吃透。

核心踩坑点：只说“计算token相关性”，讲不清核心作用、QKV的设计意义、长距离建模的原理，对底层原理理解不到位。

满分精简回答：

一、self attention的核心作用
self attention（自注意力机制）是Transformer的核心，它的核心作用是：让模型在处理文本序列中的每个Token时，能动态关注到序列中所有其他Token的信息，根据不同Token与当前Token的语义相关性，给不同Token分配不同的权重，从而捕捉文本序列中长距离的语义依赖、上下文关联关系，同时保留序列的全局信息。
简单来说，就是让模型在理解每个词的时候，能结合整个句子、整个文本的上下文，知道每个词在当前语境下的真实含义，解决了RNN/LSTM无法很好捕捉长距离依赖、并行计算能力差的问题。
二、为什么要拆成QKV？
self attention拆成Query（Q，查询）、Key（K，键）、Value（V，值）三个独立的向量，核心是为了实现灵活、可学习的注意力权重计算，同时让注意力计算具备完整的“查询-匹配-取值”的逻辑，更贴合信息检索的直觉，同时提升模型的表达能力，具体原因有3点：
1.实现了可学习的相关性匹配逻辑
Q是当前Token的“查询向量”，代表当前Token想要关注什么信息；K是序列中每个Token的“键向量”，代表这个Token包含了什么信息；通过计算Q和K的相似度，就能得到当前Token对其他每个Token的注意力权重，这个计算过程中的Q/K权重矩阵是可学习的，模型能学到不同场景下的语义匹配逻辑，比直接用原始嵌入向量计算相似度，表达能力强得多。
2.解耦了“相关性匹配”和“信息提取”
Q和K负责计算注意力权重，也就是判断“该关注谁、该给多少权重”；V负责存储每个Token的核心信息，根据计算出的注意力权重，加权求和得到最终的注意力输出。两者解耦后，模型可以独立学习“怎么匹配相关性”和“怎么提取有效信息”，大幅提升了模型的灵活性和表达能力。如果不拆分QKV，直接用嵌入向量做相似度计算和加权，模型的学习能力会受到极大限制。
3.为multi-head attention提供了基础
拆分QKV后，模型可以很方便地把QKV映射到多个不同的子空间，实现多头注意力，让每个头关注不同维度、不同类型的语义依赖，比如语法依赖、长距离语义依赖、指代关系等，进一步提升模型的表达能力。
三、为什么attention可以建模长距离关系？
attention能很好地建模长距离关系，核心原因有2点：
1.序列中任意两个Token之间的路径长度是固定的O(1)
在RNN/LSTM中，要捕捉序列中第1个Token和第1000个Token的依赖关系，需要经过999步的序列传递，信息会在传递过程中不断衰减、丢失，很难捕捉长距离依赖；而在self attention中，序列中任意两个Token，都可以直接计算注意力权重，建立直接的依赖关系，中间不需要经过任何中间步骤，路径长度永远是1，信息不会因为距离变长而衰减，不管两个Token隔得多远，都能直接捕捉到它们的语义依赖。
2.可以动态学习长距离的语义关联权重
attention机制可以通过可学习的QKV矩阵，学习到长距离Token之间的语义相关性，给真正相关的长距离Token分配高权重，给无关的Token分配低权重，哪怕两个Token隔得很远，只要语义相关，就能建立强依赖关系。同时，注意力权重是动态的，会根据上下文语境变化，能适配不同语境下的长距离依赖关系，比固定的卷积、滑动窗口的方式，灵活性和建模能力强得多。

14. 为什么需要multi-head？为什么attention可以看成动态加权？

核心考点：深挖self attention的设计原理，看你对底层逻辑的理解深度，面试高频追问点。

核心踩坑点：只说“多头能捕捉更多信息”，讲不清核心原因，也说不明白动态加权的本质。

满分精简回答：

一、为什么需要multi-head attention（多头注意力）？
多头注意力的核心，是把QKV通过不同的线性投影矩阵，映射到多个相互独立的子空间，在每个子空间中分别计算自注意力，最后把多个头的结果拼接起来，得到最终的注意力输出。
之所以需要多头注意力，核心原因有3点：
1.让模型能同时捕捉不同类型、不同维度的语义依赖
自然语言中，一个Token和其他Token的依赖关系是多维度的，比如语法依赖（主谓宾）、语义依赖（同义词、指代关系）、长距离依赖、局部依赖等。单头注意力只能学习到一种加权模式，很难同时捕捉这么多不同类型的依赖；而多头注意力中，每个注意力头可以独立学习不同类型的依赖关系，比如有的头关注局部的语法结构，有的头关注长距离的语义指代，有的头关注实体之间的关联，最终拼接起来，模型能捕捉到更丰富、更全面的上下文信息，表达能力大幅提升。
2.提升模型的特征表达能力与鲁棒性
多头注意力把特征空间拆分成多个子空间，每个头学习不同的特征表示，相当于做了特征的集成学习，比单头注意力的特征表达能力更强。同时，多个头的结果相互补充，能降低单头注意力学习偏差带来的影响，提升模型的鲁棒性。
3.优化模型的计算与并行效率
多头注意力会把原始的高维向量，拆分成多个低维的子向量，每个头在低维子空间计算注意力，总计算量和单头注意力基本一致，但是可以并行计算每个头的注意力，计算效率更高，同时还能获得更强的表达能力。
二、为什么attention可以看成动态加权？
attention的本质，就是对序列中所有Token的Value向量，根据当前Token与每个Token的语义相关性，动态计算权重，然后做加权求和，得到最终的输出，所以它完全可以看成一个动态加权的过程，核心体现在2点：
1.权重是动态计算的，而非固定的
传统的卷积、全连接层，权重是模型训练完成后就固定的，不管输入什么内容，权重都不会变；而attention的权重，是根据输入的上下文动态计算的，输入的文本变了、上下文语境变了，当前Token对其他Token的注意力权重就会完全变化。
比如“我把苹果吃了”和“我用苹果电脑写代码”，这两句话里的“苹果”，对其他Token的注意力权重是完全不同的，模型会根据上下文动态调整权重，关注真正相关的信息。
2.加权的核心是“按需分配权重，聚焦相关信息”
attention的最终输出，是序列中所有Token的Value向量，乘以对应的注意力权重，加权求和得到的。权重的大小，代表了模型对这个Token的关注程度，语义越相关，权重越高，对输出的影响越大；语义无关，权重越低，对输出的影响越小。这个过程，就是模型根据当前的查询需求，动态给不同的信息分配不同的权重，聚焦核心相关信息，过滤无关信息，完全符合动态加权的核心逻辑。

15. 同一个token的Q、K、V为什么不一样？

核心考点：深挖QKV设计的底层逻辑，看你是不是真的理解了QKV的本质，面试高频“灵魂拷问”。

核心踩坑点：只说“因为用了不同的权重矩阵”，讲不清背后的设计原因和本质意义。

满分精简回答：

同一个Token的Q、K、V不一样，核心原因是Q、K、V在注意力计算中承担着完全不同的职责和角色，需要通过不同的线性投影矩阵，映射到不同的语义子空间，学习到不同的特征表示，才能完成“查询-匹配-取值”的完整注意力逻辑，如果三者完全一样，注意力机制的表达能力会被极大限制，甚至失去核心作用。
具体来说，三者的核心职责完全不同，需要学习的特征也完全不同：
1.Query（Q，查询向量）：核心职责是“主动查询”，代表当前Token“想要关注什么信息”
Q是当前Token的特征表示，它的目标是去和序列中所有Token的K做匹配，计算相似度，得到注意力权重。所以Q需要学习的是“当前Token需要什么样的上下文信息”的特征，它的优化目标是更好地匹配到相关的K。
2.Key（K，键向量）：核心职责是“被匹配”，代表当前Token“包含了什么信息”
K是每个Token的特征表示，它的目标是被Q匹配，告诉Q“我这里有没有你需要的信息”。所以K需要学习的是“当前Token能提供什么上下文信息”的特征，它的优化目标是让相关的Q能精准匹配到自己，无关的Q匹配不到。
3.Value（V，值向量）：核心职责是“提供信息”，代表当前Token“真正要传递的核心内容”
V是每个Token的核心信息载体，注意力权重计算完成后，最终是对V做加权求和，得到注意力的输出。所以V需要学习的是“当前Token的核心语义信息、需要传递给其他Token的内容”，它的优化目标是更好地编码Token的核心语义，为最终的输出提供有效信息。
举个通俗的例子：我们去图书馆查资料，Q就是我们的“查询问题”，K是每本书的“目录/索引”，V是书里的“具体内容”。我们的查询问题、书的目录、书的内容，三者完全是不同的东西，承担的职责也完全不同，不可能是一样的。
如果同一个Token的Q、K、V完全一样，就会出现两个核心问题：
1.模型的表达能力极大受限：三者职责不同，需要学习的特征完全不同，用同一个向量无法同时满足三个不同的优化目标，模型无法学习到灵活的注意力匹配逻辑；
2.注意力计算退化成了固定的相似度计算：没有了可学习的QKV投影矩阵，注意力权重就变成了原始嵌入向量的固定相似度，模型无法根据任务和语境，动态学习不同的注意力模式，失去了自注意力机制的核心优势。

16. attention复杂度很高，如果上下文特别长，你会怎么优化？

核心考点：考察你对长上下文大模型优化的理解，是当前大模型领域的热点，也是面试高频考点。

核心踩坑点：只说“截断上下文”，讲不清体系化的优化方案，对长上下文优化一无所知。

满分精简回答：

标准的full attention（全注意力）的时间和空间复杂度是O(n²)，n是上下文长度，当上下文特别长的时候，复杂度会呈平方级增长，计算量和显存占用会急剧上升，成为性能瓶颈。针对长上下文的attention优化，工业界和学术界有非常多成熟的方案，我会从算法层面优化、工程层面优化、架构层面优化三个维度，做体系化的优化，而非简单的截断上下文。
一、算法层面：优化注意力计算模式，降低复杂度
这是长上下文优化的核心，核心思路是避免全量的token-to-token注意力计算，在尽量不损失效果的前提下，降低注意力的计算量，主流方案有4类：
1.稀疏注意力（Sparse Attention）
放弃全注意力的全局计算，只让每个Token关注有限的相关Token，把复杂度降到O(n)。主流的实现有：
1)滑动窗口注意力：每个Token只关注前后固定窗口内的Token，比如GPT-4o用的就是滑动窗口注意力，适合绝大多数的自然语言场景，因为文本的语义依赖大多是局部的；
2)膨胀窗口注意力：在滑动窗口的基础上，加入膨胀步长，让Token能同时关注局部和一定步长的长距离Token，兼顾局部和长距离依赖；
3)全局+局部注意力：设置少量的全局Token（比如开头的系统提示词、关键的标题Token），所有Token都能关注全局Token，同时每个Token关注局部窗口内的Token，兼顾全局信息和计算效率，代表模型：Longformer。
2.线性注意力（Linear Attention）
通过数学公式的变换，把attention的softmax计算，转化成核函数的线性计算，把复杂度从O(n²)降到O(n)，代表方案有RWKV、Linformer、Performer。比如RWKV通过RNN的形式，实现了和Transformer相当的效果，同时复杂度是线性的，非常适合超长上下文场景。
3.分块注意力（Blockwise Attention）
把长上下文序列，拆分成多个固定大小的块，先在块内做注意力计算，再做块间的信息交互，避免全局的平方级计算。代表方案有：Transformer-XL的段级循环机制、GPT-3的分块注意力、Mamba的结构化状态空间模型，能很好地处理超长上下文，同时保留块间的语义依赖。
4.检索增强注意力
针对超长上下文，不把所有内容都输入模型做注意力计算，而是先通过RAG检索，只召回和当前query强相关的上下文片段，只对这些相关片段做注意力计算，从源头减少上下文长度，这是工业界落地最常用、性价比最高的方案。
二、工程层面：优化计算与显存占用，提升长上下文执行效率
1.KV缓存复用与优化
推理时，对历史Token的KV缓存做复用，不需要每一轮都重新计算所有Token的KV，大幅降低重复计算量；同时针对超长上下文，对KV缓存做量化、分页存储、CPU-GPU内存交换，降低显存占用，代表方案：vLLM的PagedAttention。
2.算子融合与计算优化
用FlashAttention、FlashDecoding等优化后的注意力算子，把注意力计算的多个步骤融合成一个算子，减少GPU的显存读写开销，同时利用GPU的张量核心做并行计算，大幅提升长上下文注意力的计算速度，降低显存占用，这是目前工业界推理部署的标配优化。
3.模型量化
对模型的权重、KV缓存做4位/8位量化，在几乎不损失效果的前提下，大幅降低显存占用，让单卡能支持更长的上下文，同时提升计算速度。
三、架构层面：从根本上解决长上下文的复杂度问题
放弃传统的Transformer全注意力架构，采用更适合长上下文的模型架构，比如基于状态空间模型的Mamba、基于RNN的RWKV，这些架构的复杂度都是O(n)，上下文长度提升时，计算量和显存占用线性增长，能轻松支持百万级的超长上下文，是未来长上下文大模型的核心发展方向。

17. 模型产生幻觉的时候，一般是什么原因？工程上有什么办法降低？

核心考点：大模型落地最核心的痛点，面试必考题，考察你对大模型幻觉的根因理解和工程化解决能力。

核心踩坑点：只说“训练数据不够，加RAG”，讲不清根因和体系化的工程解决方案。

满分精简回答：

大模型幻觉，指的是模型生成的内容，看起来通顺合理，但和事实不符、编造信息、逻辑矛盾，这是大模型落地最核心的痛点。幻觉的产生，不是单一原因导致的，而是模型训练、数据、推理、任务场景等多个环节共同作用的结果，工程上也有对应的体系化解决方案。
一、模型产生幻觉的核心原因
1.训练数据层面的根因
1)训练数据质量不足：训练数据中存在错误、矛盾、虚假的信息，模型学习到了错误的知识，生成时就会出现幻觉；
2)训练数据覆盖不足：模型没有学习到对应的领域知识、最新的信息，面对未知的问题时，会基于已有的知识编造内容，也就是“一本正经地胡说八道”；
3)训练数据的重复、偏见、噪声，也会导致模型学习到错误的关联关系，生成幻觉内容。
2.模型架构与训练层面的根因
1)大模型的训练目标是“下一个token预测”，核心是生成通顺连贯的文本，而非保证事实的准确性，模型会优先生成符合语言规律的内容，而非符合事实的内容；
2)模型的参数量、上下文窗口有限，无法记住所有的训练知识，面对超出知识范围的问题时，会出现“知识遗忘”，进而编造内容；
3)对齐训练不足，SFT、RLHF阶段没有充分优化模型的事实性，模型没有学会“不知道就拒绝回答，而非编造内容”。
3.推理与提示词层面的根因
1)提示词设计不合理，没有给模型明确的约束、事实依据，引导模型编造内容；
2)上下文过长、信息污染，模型无法精准捕捉核心事实信息，基于错误的上下文理解生成内容；
3)推理时的采样参数设置不合理，比如temperature过高、top_p过大，会导致模型的生成随机性变强，更容易出现幻觉。
4.任务场景层面的根因
1)长上下文、多步推理、复杂知识问答的场景，模型更容易出现逻辑错误、事实编造；
2)专业垂直领域的任务，模型缺乏对应的领域知识，幻觉率会大幅升高。
二、工程上降低幻觉的核心方案
我们在工程落地中，采用的是**“事前约束、事中增强、事后校验”**的全链路方案，能大幅降低模型的幻觉率。
1.事前约束：从提示词和生成规则上，从源头减少幻觉
1)优化提示词设计，给模型明确的规则：“只能基于提供的参考信息回答，不知道的内容直接拒绝回答，禁止编造信息、虚假引用”，同时加入Few-Shot示例，引导模型输出真实、准确的内容；
2)约束模型的输出格式，要求模型必须标注回答内容的信息来源、引用片段，强制模型基于事实信息回答；
3)优化推理采样参数，降低temperature（通常设置在0.1-0.3）、top_p，减少生成的随机性，避免模型编造内容。
2.事中增强：通过检索增强与知识注入，给模型提供事实依据
1)接入RAG检索增强生成，用户提问时，先召回权威的、最新的相关知识，注入模型上下文，让模型基于真实的参考信息生成回答，这是工业界降低幻觉最有效、最常用的方案；
2)针对垂直领域场景，做领域知识的微调、RAG专项优化，补充模型的领域知识，减少领域内的幻觉；
3)采用思维链（CoT）、思维树（ToT）等推理优化方法，引导模型分步推理、自我校验，减少推理过程中的逻辑幻觉。
3.事后校验：通过多轮校验与纠错，过滤掉幻觉内容
1)采用Self-Check、Self-Consistency等自校验方案，让模型多次生成回答，交叉验证内容的一致性，过滤掉不一致的编造内容；
2)搭建事实性校验模块，把模型生成的内容，和参考的权威知识做对比，校验内容的事实准确性，标记出和事实不符的幻觉内容，让模型重新生成；
3)针对代码生成、数据计算等场景，通过代码执行、公式计算，校验生成内容的正确性，过滤掉错误的、编造的内容。
4.长期优化：基于用户反馈的闭环优化
1)收集用户的反馈、bad case，标注幻觉内容，持续优化提示词、RAG检索策略、校验规则；
2)把幻觉bad case加入SFT微调数据集，做模型的对齐优化，让模型学会避免编造内容，从模型层面降低幻觉率。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

为什么要学习大模型？

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

大模型入门到实战全套学习大礼包

1、大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

---

2、大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

3、AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

4、大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

5、大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

适用人群

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】