商汤科技 大模型开发 二面

1、自我介绍

2、讲一下你做过的一个最有代表性的项目

3、RAG 里 chunk 怎么切,为什么这是个关键点

chunk 切分会直接影响召回质量和最终回答质量。因为向量检索不是按整篇文档检,而是按切分后的片段检。如果切得太长,一个 chunk 里会混入很多无关信息,虽然语义覆盖大,但相似度不一定集中,模型拿到后也不容易抓住重点。如果切得太短,单个 chunk 虽然很纯,但上下文不完整,容易导致召回回来的内容缺少关键信息。

实际做的时候一般会根据文档类型来定。像制度文档、说明文档,可以按标题、段落、语义边界切;如果是 FAQ 或问答对,本身就天然适合按条切。通常还会设置 overlap,避免一个关键信息刚好被切断。除了长度本身,还会补充标题、来源、章节名这些元信息,这些信息很多时候对召回也很有帮助。

4、检索效果不好,一般怎么排查

我一般会把问题拆成几层。先看是不是 query 本身的问题,比如用户表达口语化、缩写太多、错别字多,或者问题本身就不清楚。然后看知识库侧,确认目标答案所在文档有没有被正确清洗、切分和入库。再往下看 embedding 模型是不是适合这个领域,因为通用模型在垂直领域不一定稳定。

如果文档和 query 都没问题,再看召回是不是命中了正确 chunk。如果 Recall@K 很低,那是召回问题,可能要改 embedding、混合检索或者 query 改写。如果召回到了但排得靠后,那是 rerank 问题。如果检索结果明明没问题,但最终答案还是不对,那就要看 prompt 和上下文构造,可能是文档拼接太乱、噪声太多,或者模型没有被足够约束。

5、Embedding 模型和 Rerank 模型分别解决什么问题

Embedding 模型主要解决的是粗召回问题,它把 query 和文档映射到同一个向量空间里,通过向量相似度快速找出语义上接近的候选文档。它的优势是快,适合从大规模语料里先筛出一批可能相关的内容,但它做的是相对粗粒度的相似性判断。

Rerank 模型解决的是精排问题。它通常把 query 和候选文档一起输入模型,让模型做更细粒度的相关性判断,所以排序精度更高。代价是更慢,不适合对全库直接跑。一般做法都是 embedding 先召回 topK,再用 rerank 把最相关的文档排到前面。两者不是替代关系,而是配合关系。

6、你怎么理解模型幻觉,实际项目里怎么降低

幻觉本质上是模型生成了看似合理但实际上没有依据、甚至不正确的内容。它在开放问答、知识缺失、上下文不足或者 prompt 约束弱的时候特别容易出现。很多时候模型并不是“知道但说错了”,而是根本没有足够证据,只是在基于语言统计规律继续生成。

实际项目里降低幻觉一般会从几个方向做。第一是接入 RAG,让模型基于检索到的证据来回答。第二是加强 prompt 约束,比如明确要求“只基于资料回答,资料不足就说不知道”。第三是做结果后校验,尤其在结构化场景里可以校验字段是否合法。第四是做拒答机制,不是所有问题都必须回答。第五是通过评测集专门测忠实性和事实性,而不是只看回答流不流畅。

7、SFT、DPO、RLHF 的区别

SFT 是监督微调,本质上是让模型学习示范答案,训练目标通常是最大化正确答案序列的概率。它实现简单、稳定,是大模型对齐最基础的一步。很多模型先经过预训练,再经过 SFT,就已经具备比较好的指令跟随能力。

DPO 和 RLHF 更偏偏好对齐。RLHF 一般流程更长,先收集偏好数据,再训练奖励模型,然后用 PPO 这类强化学习方法去优化策略模型。它理论上更灵活,但工程复杂、训练不稳定因素也多。DPO 则是直接利用偏好数据去优化,不需要单独训练 value model,也不需要在线 rollout 那么重的流程,整体实现更简洁。现在很多场景会优先选择 SFT + DPO 这种路线。

8、你做模型评测的时候,一般怎么设计评测集

评测集首先要覆盖真实场景,而不是只做一些过

剩余60%内容,订阅专栏后可继续查看/也可单篇购买

AI-Agent面试实战专栏 文章被收录于专栏

本专栏聚焦 AI-Agent 面试高频考点,内容来自真实面试与项目实践。系统覆盖大模型基础、Prompt工程、RAG、Agent架构、工具调用、多Agent协作、记忆机制、评测、安全与部署优化等核心模块。以“原理+场景+实战”为主线,提供高频题解析、标准答题思路与工程落地方法,帮助你高效查漏补缺.

全部评论

相关推荐

先交代个人bg:26届北大计算机硕士,后端开发,已拿MiniMax转正Offer。闲来刷牛客发现了MiniMax的话题,也来凑个热闹,分享几点真实体验。关于技术成长:新人也能啃硬骨头入职第二周,mentor给我派了个活:海螺AI的流式输出在高峰期有延迟抖动,目标是P99延迟再降50ms。说实话当时有点懵,心想这不应该是他们干的活么?结果mentor直接拉我看Grafana大盘,拆解M2.5模型推理架构,让我自己找切入点。那一周基本在读代码、看论文、和infra团队过方案。后来我提了个想法:在网关层加自适应批处理策略,根据实时流量动态调整batch大小。mentor看完说思路可行,直接让我写代码上线试试。最后优化上线,高峰期P99延迟降了60ms。怎么说呢,工作确实很硬核,之前实习的时候这种活儿大概率轮不到新人碰。这边倒好,只要方案有数据支撑,没人会因为你是实习生就拦着。关于mentor:教的是怎么思考问题记得有次遇到状态同步的坑,mentor没直接给答案,而是从分布式系统的一致性模型开始推,让我自己琢磨结论。他的原话:不只是会写代码,要成为能设计系统的人。听起来比较简单,但对于校招生来说并没有这些意识,很多时候需要有这样的引路人指引方向,这可能比敲2000行代码都管用。团队里学习氛围也很好,算法专家、infra大牛都有,中午吃饭聊的都是最新论文、模型边界。这种环境待三个月,比自己闷头学一年来得快。关于地理位置还有个挺实际的,公司在海淀区蓟门一号,骑车十分钟到公司。中午甚至能溜回学校吃顿饭,下午再骑回来写代码。对于还在学校想找实习的同学来说,这种通勤体验确实香。大概就分享这么多吧,如果说对MiniMax观望的学弟学妹总结的话,我觉得是这样,如果你想找个地方写写CRUD混个实习经历,那这边可能不太合适,但如果你想碰点真东西、做的东西真能上线跑、愿意被推着往前走,这里确实是个还不错的选择。
MiniMax成长空间 42人发布
点赞 评论 收藏
分享
评论
1
7
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务