蚂蚁网商银行 - AI 中台基础平台
面试基本信息
- 日期: 2025-12-22
- 岗位描述
- 负责基础架构方向大模型应用场景的探索落地,以及相关 AI 平台系统的架构设计与开发,利用 RAG / Agent 等技术提升技术研发效能;
- 负责大模型性能分析和进行调优,识别和解决瓶颈问题,包括不限模型微调训练和模型评测等,提升模型效果和推理速度;
- 负责日常业务、产品以及关联技术方沟通协同,快速理解业务问题并转化技术方案,保障平台产品能力交付,并形成技术能力持续沉淀;
- 学习跟踪业界大模型在效能领域的最新进展,并探索大模型在技术风险 / 研发效能方向的机会点和提升改进落地效果;
- 面试时长: 40 分钟
面试复盘
面试流程整体考察过往项目、AI 应用经验、日常 AI 中的使用经验等。面试官希望的候选人画像为: 深耕 Java、积累技术深度而非广度、反哺业务团队、对 AI 和前沿探索有相对较深的实践和研究。
01 简历工作项目
1.1 你们现在大语言模型是自研、私有化部署,还是直接调用外部 API?为什么?
公司内部中台私有化部署的开源大模型,有经过微调,主要考虑数据隐私和定制化需求。
1.2 LLM 生成的结果你们是如何做校验/反幻觉的?
我们没有试图从模型层彻底解决幻觉,据我了解中台部门没有对基座大模型进行过度的微调,一方面微调和后训练会影响模型的泛化能力,另一方面也会增加模型的不可控性。这些工程上可以进行控制和兜底的逻辑就放在各个业务部门来调整。
- Prompt 强约束
- 基于提示词的强约束,明确限定只能基于输入事实生成。
- 禁止编造未提供的信息,返回体中必须以 JSON 格式输出带有参考来源的结果。
- 不涉及隐私、政策、合规层面的敏感内容。这部分还是由固定模板来拼接。
- 后端规则校验
- 把生成结果中的商品 / 类目
- 与用户真实历史设计过 的 1 级和 2 级类目所构造的倒排索引进行匹配
- 质量模型打分
- 使用基于文本质量打分的小模型 BERT 架构
- 对可读性、营销风格做评分
- 失败回退
- 校验不通过 → 回退到模板消息
1.3 你提到 “基于规则的生成结果验证”,规则是如何设计的?数据事实来源是什么?
1.4 在 LLM 生成链路中,哪些环节是你们自己负责,哪些是中台或第三方提供的?
- 自研负责环节
- Prompt 工程、Query 改写、结果校验、业务逻辑适配、用户反馈的埋点上报。
- 中台提供环节
- 基座大模型的调用能力、数据中台提供的针对单个用户的历史行为数据。
- 数据中台对历史行为数据 进行清洗、入库、压缩、统一格式和控制 token 规模。
02 RAG
RAG 基础理解
2.1 你如何理解 RAG?它解决的核心问题是什么?
检索增强生成(Retrieval-Augmented Generation)是一种将 “信息检索” 与 “大模型生成” 结合的技术,通过在生成前从外部知识库检索相关信息,将其作为上下文输入给大模型,辅助生成更准确、有依据的回答。
核心解决问题
- 大模型幻觉问题:解决模型 “一本正经说假话” 的痛点,让回答有权威数据支撑。
- 知识时效性问题:无需重新训练大模型,通过更新知识库即可让模型掌握最新信息(如政策变动、产品更新)。
- 知识专业性问题:针对垂直领域(如法律、医疗),通过检索专业知识库,让通用大模型具备专业回答能力。
| 维度 | RAG | 微调 |
|---|---|---|
| 成本 | 低(无需大算力训练,仅需维护知识库) | 高(需大量标注数据 + GPU 算力) |
| 时效性 | 强(知识库实时更新,立即 生效) | 弱(微调周期长,无法快速响应知识变化) |
| 灵活性 | 高(支持多来源知识库,可快速切换) | 低(微调后模型固化,改造成本高) |
| 适用场景 | 知识密集型、时效性强的场景(如客服、知识库问答) | 特定任务优化(如特定格式生成、风格迁移) |
RAG 是性价比更高的
知识注入方案,只有当 RAG 效果无法满足需求(如需要模型深度掌握特定任务范式)时,才考虑微调。