小伙伴投稿一面在5.10 二面在5.15 HR面在5.17, 211本+韩硕1. 自我介绍答案：我主要做大模型应用、RAG、Agent 编排、向量检索、Prompt 工程、模型微调和后端工程化相关方向。之前做过一个 跨境商家合规审核与风险问答平台，面向国际电商平台里的商品合规、商家风控、客服质检和运营审核场景。这个系统接入了商品标题、商品详情、平台规则、违规案例、审核工单、商家申诉记录和多语言政策文档。用户可以问“这个商品为什么被判定为高风险”“某类商品在欧盟站点能不能上架”“这条申诉该怎么回复”，系统会先做 query 重写和意图识别，再通过混合检索召回规则和案例，最后由大模型生成带引用的审...

1. 自我介绍2. 什么是 RAG？它和普通大模型问答有什么区别？答案：RAG 是 Retrieval-Augmented Generation，也就是检索增强生成。它不是让大模型完全依赖参数记忆回答问题，而是在生成答案前，先从外部知识库里检索相关资料，再把检索结果作为上下文交给大模型生成答案。普通大模型问答依赖模型训练时学到的知识，容易出现知识过期、幻觉、无法引用来源等问题。RAG 的优势是可以接入企业私有知识、实时文档和业务数据库，并且答案可以追溯到原始证据。它更适合企业内部知识问答、客服、运维、法规、医疗、金融等知识更新频繁且要求可追溯的场景。 def rag_pipeline(quer...

1. 自我介绍2. 为什么要通过微调模型来做代码生成？为什么不用纯 prompt 或 spec coding？答案：纯 prompt 和 spec coding 确实可以提升模型在单次任务上的表现，但它们更多是推理时约束，解决的是“让模型按要求做事”的问题。微调解决的是模型行为分布的问题，比如固定代码风格、内部框架 API 使用习惯、异常处理模式、日志规范、单测模板、目录结构约定，这些如果全部靠 prompt 塞进去，成本很高，也容易在长任务里被稀释。在缺陷修复 Agent 里，我选择微调不是为了让模型记住业务代码，而是让它学习稳定的工程动作：先读测试，再定位调用链，再改最小范围，再补回归测试...

1. 介绍下自己的优缺点2. 你的 Agent 主要是用来解决什么问题的？这个 Agent 主要解决跨境电商运营中“数据分散、决策链路长、人工分析慢”的问题。传统运营需要分别看广告后台、商品后台、库存系统、用户评论、竞品价格和售后工单，再人工判断问题原因。Agent 的目标是把这些数据源通过工具封装起来，让模型按任务目标自动规划查询步骤，并生成有证据支撑的运营建议。比如用户问“为什么这款蓝牙耳机最近销量下滑”，Agent 不会直接回答，而是会拆成几个子任务：查曝光和点击是否下降，查转化率是否下降，查广告 ROI 是否异常，查库存是否断货，查评论是否出现集中差评，查竞品是否降价。最后根据证据判断...

5.16 三面结束 我看粉丝投稿的4.21 一面的 二面过完5.11. 自我介绍2. 怎么理解深度学习损失函数中的最大似然估计 MLE？答案：最大似然估计的目标是找到一组模型参数，让观测到的数据在当前模型下出现的概率最大。深度学习里的分类任务通常把模型输出看成条件概率分布 p(y|x; θ)，训练时希望真实类别的概率越大越好。实际优化时通常不会直接最大化似然，而是最大化对数似然，或者等价地最小化负对数似然。交叉熵损失本质上就是负对数似然。比如多分类中，真实标签是第 y 类，模型对这一类预测概率是 p_y，loss 就是 -log(p_y)。预测越自信且正确，loss 越小；预测越错，loss ...

1. 自我介绍2. 智能合同审阅平台里为什么要同时使用向量检索和全文检索？单一检索方式为什么不够？答案：在合同审阅场景里，用户的问题或者待审条款通常不是简单关键词匹配，而是存在大量语义相近但表达不同的内容，比如“提前解除合同”“单方终止协议”“无责解约”语义接近，但关键词并不完全一致。如果只用全文检索，比如 Elasticsearch 的 BM25，优点是关键词匹配精确、可解释性强，对合同编号、金额、日期、公司名称、条款标题这类结构化或半结构化字段效果很好。但它对同义表达、语义改写、隐含风险点的召回能力较弱。如果只用向量检索，优点是语义召回能力强，但是容易召回一些语义相似但法律含义不完全一致的...

估计后面2 3个月只有社招的面经了, 粉丝群的春招和暑期的小伙伴分享的差不多了1. 自我介绍2. Java 中 final、finally、finalize 的区别答案：final 是关键字，可以修饰类、方法和变量。修饰类表示不能被继承，修饰方法表示不能被重写，修饰变量表示引用或值不能再次赋值。需要注意的是，final 修饰对象引用时，只是引用不能变，对象内部状态仍然可能改变。finally 是异常处理结构的一部分，通常用于释放资源。无论 try 中是否发生异常，只要 JVM 没有直接退出，finally 通常都会执行。比如关闭连接、释放锁、清理临时文件。finalize 是 Object 类...

这个是5.11发的offer了,HR面和二面隔了10多天1. 自我介绍2. RAG 有没有解决大模型胡说八道的问题答案：RAG 只能缓解幻觉，不能彻底解决幻觉。RAG 的作用是把外部知识、业务文档、历史记录和实时数据作为上下文提供给模型，让模型减少依赖参数记忆。但如果召回错了、召回不全、chunk 切分不合理、rerank 排错、prompt 没约束好，模型仍然会基于错误证据生成错误答案。所以线上 RAG 不能只做“检索 + 拼 prompt + 生成”。必须做证据约束。比如在园区运维场景里，模型说“冷却塔水泵异常导致能耗升高”，就必须引用对应的告警记录、传感器曲线或历史工单。如果没有证据，只...

1. 自我介绍2. 介绍你的实习项目，你做了哪些事情以及你的思考3. 升级之后 tool 调用准确率提升了多少，怎么衡量答案：tool 调用准确率不能只看模型有没有调用工具，而要看调用的工具是否正确、参数是否正确、调用顺序是否正确、结果是否被正确使用。我们会把一次工具调用拆成几个指标：工具选择准确率、参数填充准确率、无效调用率、重复调用率、最终任务成功率。比如升级前模型经常把“查询保单责任”和“查询历史理赔”混淆，或者漏传 policyId。后来通过工具分域、意图路由、参数 schema 校验和少量高质量样例，工具选择准确率从大概 82% 提升到 92% 左右，关键参数完整率从 88% 提升到...

1. 自我介绍2. 如何在工程上实现兜底机制？具体到代码层面怎么做？答案：兜底机制不能只写一句“失败后重试”，要按失败类型分层。模型层可能超时、限流、返回格式错误；检索层可能无结果、召回低相关；工具层可能参数错误、权限失败、下游服务不可用；生成层可能答案无引用或不符合 schema。不同错误要有不同兜底，不能统一重跑。工程上我一般会做三层兜底：第一层是重试，比如超时、临时网络错误可以指数退避重试；第二层是降级，比如大模型失败就切小模型，rerank 失败就用召回分数排序；第三层是安全返回，比如证据不足就拒答，工具失败就返回部分结果和失败原因。对于有副作用的工具，不能盲目重试，必须加幂等 key...

1. 自我介绍2. RAG 的检索索引怎么设计？答案：RAG 的检索索引不能只建一个向量字段就结束。实际系统里，我会把索引分成语义索引、关键词索引、结构化索引和权限索引。语义索引用来处理自然语言问题，关键词索引用来处理规则编号、商品编码、报关术语、单据字段名这类精确匹配，结构化索引用来按国家、业务类型、规则版本、生效时间过滤，权限索引用来保证用户只能查自己有权限的数据。文档入库时也要保留足够元数据，比如 doc_id、chunk_id、parent_id、section_path、doc_type、country、effective_date、version、tenant_id。如果没有这些字...

这个是4.30的面经 我一直没来得及整理1. 自我介绍，包括个人背景、经历，以及 AI 大模型如何融入学习和实践2. 使用 AI Coding 工具时遇到过什么问题，怎么解决答案：AI Coding 最大的问题不是不会写代码，而是它容易写出“看起来能跑但不符合项目约束”的代码。比如它会新增不必要的抽象层、改动无关文件、吞异常、遗漏权限校验、把敏感字段打进日志，或者生成一个和团队代码风格完全不同的实现。我的做法是先给它明确上下文和边界，不让它自由发挥。比如只允许修改指定文件，不允许改接口签名，不允许新增依赖，不允许修改数据库 schema。生成代码后，我会先看 diff，再跑测试，再重点 rev...

1. 自我介绍2. 详细讲一下你的实习经历，你具体负责哪些工作3. 限量出包是什么逻辑，5 万条候选线索只出 3 万条怎么判断高价值用户答案：限量出包本质是一个带约束的排序和筛选问题。不能简单按分数从高到低取前 3 万，因为业务里还有很多约束，比如销售每天承接能力、行业配额、城市覆盖、客户冷却期、黑名单、重复企业、近期已触达、历史投诉、企业规模、潜在金额等。我会先做硬过滤，再做评分排序，最后做配额调整。硬过滤去掉无权限、黑名单、近期已触达、关键信息缺失的线索；评分层综合行为分、画像分、意图分、转化概率分；配额层保证行业、区域和销售组之间不会极端倾斜。最终不是单纯 topN，而是 “topN +...

1. 自我介绍2. 你在项目里主要负责哪一块，核心难点是什么3. 意图识别具体怎么做，哪些意图是你们自己定义的答案：意图不是模型自己随便生成的，而是业务先定义好可执行的意图集合。比如在商家经营诊断里，会定义订单转化分析、差评归因、客服质检、活动效果复盘、规则咨询、商品套餐优化、竞品对比、经营日报生成这些意图。每个意图都对应明确的输入、需要的工具和输出格式。实现上会用规则加模型混合。像门店 ID、活动 ID、订单号这种强结构化字段先用规则抽取；再用模型做意图分类和槽位补全。模型输出不能直接信任，要校验意图是否在白名单内、槽位是否合法、是否缺关键参数。如果缺门店或时间范围，就进入追问，而不是直接查...