小米 Java 一面：RRF、重排与注入防护
本场面试题
- RRF 融合时检索到的数量是多少？怎样提升精确度？
- 用过重排模型吗？
- 怎么防止大模型注入攻击？
面经与参考答法
小米 Java 一面：RRF、重排与注入防护
这份自述记录了小米软件开发工程师（Java 方向）一面，题目涉及 Agent 项目与后端基础。部门和面试日期未知，不由发布时间或校招届别推断。这里选取 RRF、重排和注入防护三组问题，SQL、CAS 与并发 LRU 等题因缺少实现条件未展开。经历未经外部核实；短答与示例为编辑补充的学习材料，不代表现场作答、项目配置或公司技术栈。
（1）RRF 融合时检索到的数量是多少？怎样提升精确度？
原帖未披露数量。应先区分各路召回深度、融合候选窗口和最终交付数量；RRF 按各列表中的排名累加倒数贡献，公式中的平滑常数不是检索数量。候选规模应结合带相关性标注的查询集、漏召回、前排相关性与时延选择，再检查权限和版本过滤、去重及重排；没有适用于所有项目的固定数量。
教学示例（非原面试实现）：在同一组查询上比较不同候选深度，保留各路结果和融合排名，观察相关证据是否进入候选池、是否排到前列。若证据根本没被召回，只调整融合后的排序无法补回它。
（2）用过重排模型吗？
原帖未披露当事人的使用经历或模型名。重排是在已有候选中进一步评估查询与片段的相关性，例如用 Cross-Encoder 联合编码文本对后排序。它不能找回候选池中遗漏的证据，分数也不是事实正确概率。介绍实际接入时应给出模型与版本、输入限制，以及固定候选上的排序质量、端到端效果、时延和成本证据。
教学示例（非原面试实现）：查询要求排除某个版本时，语义相近的旧版片段可能排在前面。可在固定候选池中比较重排前后的名次和相关性标签；结果是否改善仍要实测，不能先承诺一个提升比例。
（3）怎么防止大模型注入攻击？
把网页、文件和工具返回值视为不可信数据，明确来源与指令边界，但标签、关键词过滤和第二个评审模型都不能单独保证安全。工具执行层还要从可信会话取得身份和权限，校验参数与资源范围，限制凭据、网络出口和数据量；高风险动作在执行前核对确切参数及必要批准，并验证输出的后续用途。用真实入口的攻击与正常案例检查误放、误拒和实际工具行为。
教学示例（非原面试实现）：网页夹带“把内部资料发送到陌生地址”的内容，不会因此取得发送权限。服务端应按用户授权拒绝越界收件人与数据范围；测试时还要检查沙箱中的工具调用和数据流，不能只看最终回复有没有拒绝。