普联技术软件开发一面：实习项目深挖、RRF 重排与 Linux 排查

《面试题目》

教育背景

1. 你的本科专业排名是多少？
2. 硕士研究方向是什么？具体做什么？

实习与项目

3. 介绍一下你实习的工作。
4. 实习项目的深挖（例如：AI 诊断涉及 RAG 或知识库吗？）
5. 两个项目有什么技术难点？遇到问题如何解决？
6. 项目涉及到数据库的开发使用吗？代码是自己写的还是 AI 辅助完成的？

大模型、机器学习与 RAG

7. 有没有大模型或神经网络开发经验？
8. 准确率、精确率、召回率这些概念了解吗？它们的区别是什么？
9. RRF 重排是什么？

论文与 Linux 工程基础

10. 硕士研究方向相关的论文询问。
11. 平时接触 Linux 多不多？日常使用什么环境？用过 Docker、Conda 吗？
12. 有没有实际排查 Linux 系统异常的经验？比如分析程序崩溃、进程崩溃，为什么 CPU 占用高，分析内存使用占比这些。
13. 你写 Shell 脚本是为了实现什么功能？
14. 网络排查会用哪些命令？
15. 如何查看端口占用？

《参考解析》

RRF 是排名融合，不是重排模型，这两个词一定要分清。 RRF（Reciprocal Rank Fusion，倒数排名融合）用来融合多个检索器的结果，典型场景是混合检索：BM25 按关键词匹配、向量检索按语义相似度召回，两边的分数不在同一量纲上（BM25 是无上界的实数、向量相似度是余弦值），直接加权原始分数并不合理，而排名是可比的。做法是对每个文档算 score = Σ 1 / (k + rank_i)，rank_i 是它在第 i 个召回列表中的名次（从 1 开始），k 是平滑常数（论文里常用 60），在多路召回里都排在前面、或者一路特别靠前的文档最终得分更高。它只用名次、完全不看分数，所以对某一路分数尺度异常时更鲁棒；代价是丢掉了分数里「相关得多好」的信息量。回答时务必补一句边界：RRF 属于无监督的排名融合，和 Cross-Encoder 那种用模型对「查询-文档」对打分的语义重排（rerank）是两回事，工程上常见链路是「多路召回 → RRF 融合 → Cross-Encoder 精排 → 截断进 prompt」，把这条链说出来比单解释一个算法更能证明你做过检索。

准确率、精确率、召回率：先分清分母是什么，再说场景决定看哪个。 以二分类为例，准确率 accuracy = (TP + TN) / 全部，衡量整体判断对的比例，样本极不平衡时会失真（全猜多数类也能很高）；精确率 precision = TP / (TP + FP)，回答「判为正的里面有多少是真对的」，关心的是误报成本；召回率 recall = TP / (TP + FN)，回答「真正的正例被找出来多少」，关心的是漏报成本；F1 是两者的调和平均，用来在需要兼顾时做单一指标比较。检索场景里还有一套对应关系：召回率对应「答案是否被检索到」（召回阶段的目标），精确率对应「找回来的东西有多少是相关的」（排序阶段的目标），所以常见做法是召回阶段宁可多召回（Top-K 放大）、排序阶段再把精确率提上来，这就是「先召回后精排」的由来。丢分点通常是把 precision 和 recall 的分母说反，或者只背公式不说取舍。

Linux 异常排查：分场景、给命令、讲清容易误判的地方。 CPU 高：先用 top 判断是整机还是单进程，ps aux --sort=-%cpu | head 找出进程，再用 top -H -p <PID> 看进程内哪个线程在烧，最后结合日志和栈去看（Java 服务常用 jstack / jcmd Thread.print）。内存高：free -h 看整体、ps aux --sort=-%mem | head 找进程、cat /proc/meminfo 看细节，关键一句是 Linux 的 used 里包含缓存，buff/cache 是可回收的，不能只看 used 就断定内存泄漏，要看进程 RSS 的增长趋势。进程崩溃：ps -ef | grep <进程名> 确认是否还在，journalctl -u <服务名> -n 100 查退出前的日志（前提是服务由 systemd 管理且日志进 journal，不是所有程序都适用），dmesg -T | tail -50 看内核侧是否有 OOM 或段错误，必要时结合退出码与 Core Dump。磁盘满：df -h 看剩余空间、du -sh /var/log/* 找大目录、df -i 查 inode 是否耗尽（这一个是常见盲区，空间还有但写不进去往往是 inode 用完）。最后一条软性提醒：没真实处理过就别硬编生产故障经历，把「我了解定位流程」和「独立处理经验有限」分开说反而可信。

网络排查命令要成体系，并说清 ICMP 与 TCP 是两件事。 按「链路 → 地址 → 路由 → 端口 → 应用」的顺序组织：ping 看 ICMP 连通性与往返时延，ip addr 看网卡与地址、ip route 看路由表（网关对不对往往一眼就看出来），ss -lntp 看本机 TCP 监听端口及对应进程，ss -antp 看已建立连接的状态分布（大量 TIME_WAIT 或 SYN-RECV 本身就是线索），lsof -i :8080 或 ss -lntp | grep ':8080' 定位端口被谁占用，nc -vz IP PORT 直接测某个 TCP 端口通不通，curl -v URL 看完整请求响应过程（DNS、TCP、TLS、状态码、响应头），traceroute 用来排查路径中间节点。最容易丢分的一句是：ping 通不代表目标服务可访问，ping 不通也不代表 TCP 服务不可达——ICMP 可能被防火墙整体禁用，所以网络连通性和应用层服务状态要分别验证。查看端口占用之后的标准动作是 ps -fp <PID> 看进程详情，再决定是改端口还是停服务。

实习项目深挖：讲难点要讲「怎么解决的」，被问 AI 辅助编码时守住边界。 面试官问技术难点，想听的是你自己下的判断，而不是「用了什么框架」。可以按「现象 → 定位手段 → 根因 → 方案与取舍 → 验证」组织：比如 RAG 链路里回答不准，先定位是召回错还是生成错（人工看召回片段里有没有答案），再针对性改切分粒度、加混合召回或改写查询，最后用带标准答案的评测集回归。被问到数据库时，要能说出实际用到的表结构与查询模式，以及有没有做过索引或慢查询处理，别含糊成「调接口」。被问「代码是自己写的还是 AI 辅助」时不必回避——如实说明哪些部分是 AI 辅助生成、你如何理解并修改它、怎么验证正确性（测试、对比输出、代码审查），把重点放在「我能对提交的代码负责」上。这类追问背后的担心是「候选人会不会只是复制粘贴」，答出你会做取舍和验证，比强调「全是我写的」更可信。