最近在帮团队面试大模型方向的候选人发现一个挺有意思的现象很多同学简历上写满了Agent、RAG、LangChain这些热门技术栈但一问到具体实现细节就暴露出对底层逻辑理解不够深入的问题。比如有位候选人说做过RAG系统我问他“为什么有时候检索到的文档片段明明包含答案但大模型还是回答不准确”他支支吾吾半天最后说可能是模型不够好。其实问题很可能出在文档分块策略上——如果分块时把标题信息和正文切开了模型就失去了理解上下文的锚点。这让我意识到单纯知道技术名词是不够的关键是要理解每个技术解决的是什么问题以及在什么场景下适用。今天我就结合面试中常见的100个高频问题把这些热门技术拆开来讲清楚。1. 先搞明白RAG它真正解决的是信息实时性和准确性问题RAG检索增强生成这两年特别火但很多人对它有个误解以为只是“先检索再生成”的简单拼接。实际上RAG的核心价值在于弥补了大模型的两个固有缺陷知识截止日期和幻觉问题。1.1 为什么你的RAG系统效果不稳定可能是分块策略出了问题文档分块是RAG系统中最容易被忽视但至关重要的环节。我见过太多项目因为分块策略不当而导致效果大打折扣。关键决策点什么时候该保留标题信息需要保留标题的情况技术文档、API参考、法律条文等结构严谨的内容。标题提供了关键的上下文信息比如“参数说明”、“返回值”、“注意事项”这些标题能帮助模型更好地理解后续内容。可以舍弃标题的情况叙事性内容、连续对话记录等。这时候标题信息可能反而会干扰语义连贯性。实际操作中我一般会采用混合策略。比如对技术文档我会在嵌入时把章节标题作为元数据保留但在分块时确保每个块都包含完整的语义单元。具体实现可以这样# 示例分块策略 def chunk_with_context(text, chunk_size500, overlap50): # 先按段落分割 paragraphs text.split(\n\n) chunks [] current_chunk for para in paragraphs: if len(current_chunk para) chunk_size: # 保存当前块保留重叠部分 if current_chunk: chunks.append(current_chunk) current_chunk current_chunk[-overlap:] para else: chunks.append(para) else: current_chunk para return chunks1.2 嵌入模型选择为什么MiniLM12在某些场景下比大型模型更合适最近有候选人提到用LlamaIndex MiniLM12实现RAG的方案这其实是个很务实的选择。虽然MiniLM12参数量不大但在特定场景下有独特优势计算资源友好在边缘设备或资源受限环境中MiniLM12的轻量级特性让它成为首选领域适配性好如果业务场景相对垂直用小型模型在领域数据上微调效果可能超过通用大模型响应速度快对于实时性要求高的问答系统推理速度是关键指标不过要注意的是选择嵌入模型时要考虑语义粒度的匹配。如果你的文档都是技术性很强的内容可能需要更专业的嵌入模型。1.3 RAG系统落地的四个检查点从原型到生产环境RAG系统需要经过严格的验证。我总结了一个四步检查法检索质量检查手动验证top-k检索结果的相关性确保检索模块工作正常生成质量检查检查模型是否在检索结果的基础上进行生成而不是依赖内部知识边界情况处理测试当检索不到相关内容时系统是如实回答“不知道”还是胡编乱造性能压力测试模拟高并发场景检查响应时间和资源消耗很多团队只做到第一步就匆忙上线结果在实际使用中遇到各种问题。2. LangChain和LangGraph从工具链到工作流引擎的演进LangChain刚出现时很多人把它当成又一个AI工具库。但它的真正价值在于提供了一套完整的AI应用开发范式。2.1 LangChain解决了什么实际问题在没有LangChain之前开发一个AI应用需要自己处理很多底层细节提示词模板管理、模型调用封装、记忆机制实现、工具调用协调等。LangChain把这些通用能力抽象成了可复用的组件。核心价值体现在三个方面标准化提供了统一的接口规范不同模型、不同工具可以用相同的方式调用模块化每个功能都是独立的组件可以按需组合使用可扩展性自定义工具、记忆后端等都很容易集成进来但LangChain也有它的局限性——它更适合线性流程对于复杂的多步骤、有状态的工作流支持不够友好。这就引出了LangGraph。2.2 LangGraph和LangChain的区别从链条到图结构的思维转变这是面试中经常被混淆的概念。简单来说LangChain是“链式思维”LangGraph是“图状思维”。LangChain的ChainA - B - C 的线性流程适合顺序执行的任务LangGraph的Graph支持分支、循环、并行等复杂逻辑适合有状态的工作流比如开发一个客服机器人用LangChain可以很好地处理单轮对话但如果需要根据用户意图跳转到不同处理模块或者维护多轮对话状态LangGraph就更加合适。# LangGraph的典型使用模式 from langgraph import StateGraph, Node def classify_intent(state): # 意图分类节点 return {intent: technical_support} def handle_technical(state): # 技术支持处理节点 return {response: 技术解决方案} def handle_sales(state): # 销售咨询处理节点 return {response: 产品介绍} # 构建图结构 graph StateGraph() graph.add_node(classify, classify_intent) graph.add_node(tech, handle_technical) graph.add_node(sales, handle_sales) # 根据意图决定路由 graph.add_conditional_edges(classify, lambda state: state[intent], {technical_support: tech, sales_inquiry: sales} )2.3 Checkpoint机制为什么它对生产环境如此重要LangChain中的Checkpoint是个容易被忽视但很实用的功能。它本质上是一种状态持久化机制让应用能够在中断后恢复执行。适用场景包括长时间运行的任务比如文档处理、数据分析等耗时操作容错恢复当进程意外终止时可以从最近检查点继续调试分析可以回放执行过程定位问题所在在生产环境中我建议对关键业务流程都添加Checkpoint支持这能显著提高系统的可靠性。3. Agent开发从单一工具到自主决策的跨越Agent可能是目前大模型领域最热门也最容易被误解的概念。很多人把任何调用工具的AI都称为Agent但实际上真正的Agent应该具备自主决策能力。3.1 Agent框架选型从简单到复杂的演进路径现在市面上的Agent框架很多从轻量级的自定义实现到功能完整的平台级方案。选择时要考虑实际需求简单任务用LangChain的Agent就足够学习成本低复杂工作流考虑LangGraph或专业Agent框架生产环境需要关注稳定性、监控、容错等工程化需求最近遇到的“error: reply session initialization conflicted for agent:main:main”这种错误通常是因为多个Agent实例冲突导致的。在架构设计时就要考虑实例管理和隔离策略。3.2 Agent技能设计如何让AI学会使用工具给Agent添加技能不是简单的API封装需要考虑工具使用的上下文和决策逻辑。技能设计的三个层次基础工具层封装单个工具的功能提供清晰的输入输出规范决策逻辑层定义什么时候使用什么工具以及如何处理工具返回结果错误处理层制定工具调用失败时的备用方案和恢复策略我见过很多Agent项目失败不是因为工具不够多而是缺乏清晰的决策逻辑。Agent在复杂场景下容易陷入“工具循环”——不停地尝试各种工具但解决不了实际问题。3.3 实际项目中的Agent开发经验在真正的业务场景中开发Agent有几个关键点需要特别注意明确边界清晰定义Agent的职责范围避免过度设计渐进复杂从简单任务开始逐步增加复杂度监控反馈建立完善的日志和监控体系持续优化决策逻辑人工介入设计人工审核和干预机制确保关键决策的准确性最近在做的客服Agent项目我们就采用了“人机协作”模式——简单问题自动处理复杂问题转人工人工处理结果再反馈给Agent学习。这种模式在实践中效果很好。4. CodeBuddy和WorkBuddy腾讯的代码助手生态CodeBuddy是腾讯推出的代码助手和WorkBuddy共同构成开发工具生态。虽然市面上类似产品很多但CodeBuddy在特定场景下有独特优势。4.1 CodeBuddy的核心能力定位从使用经验来看CodeBuddy更适合企业级开发环境特别是在腾讯云生态集成方面表现突出云服务集成天然支持腾讯云各种服务的代码生成和调试团队协作在项目上下文共享和代码规范统一方面做得很好安全合规对企业级的安全要求和合规性有更好的支持不过要注意的是不同模型版本之间确实存在差异。即使是同样的Claude模型因为提示词工程和上下文管理的差异实际效果也可能不同。4.2 第三方API接入实践CodeBuddy支持接入第三方API这是扩展其能力的重要方式。接入时需要考虑几个关键问题认证安全如何安全地管理API密钥和访问令牌错误处理第三方服务不可用时的降级方案性能优化异步调用和缓存策略的设计成本控制API调用次数和费用的监控管理在实际项目中我一般会设计一个统一的API网关层来管理所有第三方集成这样既保证了安全性也便于维护。4.3 与WorkBuddy的协同使用WorkBuddy更偏向项目管理和团队协作与CodeBuddy形成互补。合理的做法是CodeBuddy专注代码开发、调试、优化等技术工作WorkBuddy处理任务分配、进度跟踪、文档管理等协作事务两个工具通过项目上下文进行关联为开发团队提供端到端的支持。5. LLM微调从通用到专用的关键一步微调是大模型落地过程中必不可少的一环但很多人对微调的理解还停留在表面。5.1 数据标注手动还是自动这是微调项目中最常见的争论。我的经验是结合使用各取所长。手动标注的优势质量可控准确率高适合小规模、高质量的核心数据集能够处理复杂和边缘情况自动标注的价值规模大成本低适合生成初步训练数据可以通过迭代逐步提升质量在实际项目中我通常采用“自动生成人工校验”的模式。先用LLM生成大量标注数据再由领域专家进行审核修正。这样既保证了效率又确保了质量。5.2 微调策略选择全参数微调vs高效微调根据任务需求和资源情况需要选择合适的微调策略全参数微调效果最好但资源消耗大适合关键任务场景LoRA等高效微调资源友好适合快速迭代和实验Adapter微调模块化程度高便于管理多个专项模型对于大多数业务场景我建议从高效微调开始验证效果后再决定是否需要进行全参数微调。5.3 微调项目的实战经验经历过多个微调项目后我总结了一些实用经验数据质量大于数量1000条高质量数据比10000条噪声数据更有效验证集设计要合理要覆盖真实的业务场景而不仅仅是分布内的数据迭代要快采用小步快跑的方式快速验证假设和调整方向监控要持续上线后要继续监控模型表现及时发现数据分布变化微调不是一劳永逸的而是需要持续优化的过程。6. 技术选型框架如何为你的项目选择合适的技术栈面对这么多技术选项如何做出合理的选择我总结了一个四维评估框架6.1 需求匹配度评估首先明确业务需求的核心特征实时性要求是否需要低延迟响应RAG通常比微调更实时准确性要求对错误的容忍度如何关键业务可能需要微调人工审核复杂度级别简单问答还是复杂推理Agent适合处理复杂任务数据敏感性是否需要本地部署某些场景下需要私有化方案6.2 团队能力评估技术选型必须考虑团队现状技术储备团队对相关技术的熟悉程度运维能力是否有能力维护复杂系统学习成本新技术的上手难度和时间成本资源投入可用的人力、计算资源、时间预算6.3 成本效益分析从投入产出比角度考虑直接成本API调用费用、计算资源消耗、人力成本间接成本维护成本、风险成本、机会成本预期收益效率提升、质量改善、业务价值6.4 长期可维护性技术决策要有长远眼光社区生态技术的活跃度和社区支持情况版本稳定性API和功能的稳定性如何扩展性是否容易适应未来的需求变化迁移成本如果需要更换技术栈成本有多高7. 面试准备建议如何展现真实的技术深度最后给正在准备大模型方向面试的同学一些实用建议。7.1 项目经验表述要有层次不要简单罗列技术栈要讲清楚问题背景为什么要做这个项目解决了什么实际问题技术选型为什么选择这些技术考虑过哪些替代方案实现细节遇到的具体挑战和解决方案是什么效果评估如何衡量项目成功有哪些量化指标复盘反思如果重做一次会有什么不同的做法7.2 技术理解要深入底层避免停留在表面概念要展示深度思考原理理解不仅知道怎么用还要知道为什么这样设计优劣分析清楚技术的适用场景和局限性实践洞察有实际使用中的体会和发现趋势判断对技术发展方向有自己的看法7.3 解决问题的能力要具体面试官更关心你如何解决实际问题分析思路面对问题的第一反应和分析框架方法选择为什么用A方法而不是B方法实施过程具体的操作步骤和调整优化结果验证如何确认问题真正得到解决大模型技术还在快速发展中面试官更看重的是学习能力和解决问题的思路而不仅仅是当前掌握了多少技术点。保持好奇心持续学习在实践中积累真实经验——这才是最重要的竞争力。