2026.09.28-西安小厂AI应用一面面经与复盘
最后更新：
这场面了一个多小时，有点长，这里直接看我自己没答好的地方
做项目的过程中遇到的最难的事是什么
这里一时间有点懵，因为之前被问到都是解决了什么问题，至于这个难度对比真的没有比较过哪个比较难
想了一下开始讲自己在RAG构建的过程中遇到的证据找回覆盖不足以及无答案结果非空的问题，但是讲了一段之后突然想起来这个问题还在解决的过程中，一时间就不敢接着讲了
之前做的HardSeat和BeamDrop记忆有点模糊了，于是想了一下居然开始讲在Multi-Agent Arena部署构建的时候配置镜像源的问题，因为当时确实搞了挺久的
现在再重新想一下，其实可以说Multi-Agent Arena在部署过程中发现后端容器正常，但是无法访问本机8000端口，也就是端口发布失效，通过查看iptables规则发现没有8000端口相关的转换规则，推测可能外部到Docker后端容器的路径在此处被拦截，检查防火墙设置无异常，已经设置内核转发，最后发现是Compose配置了internal: true导致容器隔离外部网络
Tool-Call为什么要组裁剪
这里当时有点忘记这个概念了，其实很简单，就是让工具被调用的记录和工具调用产生的结果记录捆绑在一起，不论是滑动窗口裁剪或者说Compact压缩都不要让它们孤立出来
目的就是为了保证上下文的完整性，这两个记录单独拿出来都缺少了意义
RAG 召回指标与海量数据扩容问题
当时面试官问我为什么选择Recall@5而不是Recall@10，我回答的是基于当前语料较少，综合量级进行评估，为了减少噪声选择的Top-5
随后追问如果有百万量级的数据，又应该怎么选取K值做召回，我回答做固定上下限，然后用相似度匹配设定阈值
显然是答崩了
首先看第一个问题，为什么选Top-5，Top-K的选择本质上是召回率和上下文噪声以及Token成本之间的权衡
如果做比较标准的回答，那么就是在当时的特定语料下，单问题涉及的知识点相对比较集中，显示当K=5的时候Recall就已经达到了87.5%，再继续增加K值会有边际效应递减以及引入噪声、Token成本上升等问题
接着下面的问题，这个确实从来没接触过啊，整理一下，大概是分成多级的检索架构
- 首先第一阶段通过结构化的硬过滤，在数据库层面将粉丝量、国家、平台这些结构化字段过滤掉，大幅减少候选集规模
- 然后第二阶段尝试做多路召回，比如说这边通过BM25进行稀疏检索，进行精准词匹配，召回得到一个列表；然后另一边通过ANN向量检索进行相似最近邻查找(不要用KNN精确查找)；最后通过RRF算法进行融合
- 第三阶段，交叉编码器进行精排，使用专门的Rerank模型将Query和候选的Profile拼接，输入交叉编码器来计算深度的语义相关度，进一步收拢
- 最后第四阶段，设计动态阈值和上下文压缩，设置一个绝对相似度阈值，比如说Rerank分数低于多少的直接截断
首先ANN，即Approximate Nearest Neighbor，近似最近邻，设计的目的就是牺牲微小的精度，来换取极致的查询速度，也就是找到足够近的向量而非死磕绝对最近的向量
具体实现上有基于图构建的HNSW，有基于聚类的IVF，有基于量化压缩的PQ，看了一眼这里面任意一个算法都硬到可以单开一篇文章了，所以这里先不拓展了，总之ANN就是典型的牺牲精度换效率的例子
然后交叉编码器就是Rerank的一个实现方式，前面粗排求的是快，能够在海量数据范围内快速地筛出候选集，然后为了后续让LLM真正能够精确回答问题，需要的是准，这就涉及到了Rerank，也即重新去计算候选集内的相关性评分，剔除噪声
普通的双编码器就是传统的Query经过Query模型生成一个向量，Document经过一个Doc模型生成另一个向量，然后两者之间比较余弦相似度，这样很快，但是粗糙，两段信息之间缺乏交换
于是交叉编码器就将Query和Document拼在一起送进Transformer，让模型的Self-Attention机制逐字逐句地去比对Query里的每个Token和Document里的每个Token，这样就显著提升了精度，缺点是慢了
业务场景：从3小时到30分钟
面试官询问：运营每天花3小时筛选达人，老板想要提速到30分钟，怎么做
这里有点没匹配上AI应用工程师这个角色，第一反应是数据库层面做初筛，然后再丢给运营
后续面试官提醒，然后才补充说的使用大小模型两阶段筛选做pipeline
项目周五上线但是有重度Bug怎么办
没经历过，乱答一通，标准化应该是这样
优先评估Bug影响力，若是P0级Bug，设计兜底降级方案，比如降级开关、切回旧逻辑、功能熔断，并立即给出风险评估和降级方案汇报上级
评论
评论会在审核后展示