靖安科技全栈开发三面

《面试题目》

1. 请先简短介绍一下你自己
2. 这个研究院是一个什么性质？是企业吗？
3. 它是港中大下面的？也对外招聘实习生？
4. 是跟哪家无人机公司合作的？公司叫什么名字？
5. 你具体参与的是一个什么平台（空域协同指挥平台）？详细说一下
6. 你们用的是一个什么样的仿真平台？
7. 做的是一个什么？用什么做的（技术栈）？
8. 你负责的这块，你详细展开介绍一下
9. 「视角范围内」，就是我拖动浏览器（3D 相机）的那个范围吧？
10. 你说的那个「摄像头」是一个什么样的东西？
11. 假设需求就是 10 万架无人机要在同一视野内全部渲染出来，你觉得该怎么做？
12. 详细展开说一下
13. 是要对每个轨迹点都做（空间索引）吗？
14. 做了这个优化，就能支持 10 万+ 了？
15. 算法冲突（冲突校验）这一块你有参与吗？
16. 所以你主要做的就是渲染这块？
17. 在这边实习了多久？
18. 当时你为什么想去这边实习？
19. 那后来为什么不考虑一直留在那边实习？
20. 那段实习的经历也详细介绍一下
21. 你们整个系统其实就是采集工厂产线上各个传感器的数据、订单数据？要解决的问题是什么？
22. 之前没有你们这套系统吗？
23. 所以你们是把所有数据集中到一起、打通了？
24. 你有没有了解最新的……类似「动态本体、动态操作体」这种东西？
25. 你做的这个项目里，你觉得最难的点在什么？
26. 你这个准确率是从 58% 到 92%？
27. 你这个测评集有多大？
28. 上千个历史 query？都是人工标注过的吗？
29. 你没有做过消融实验吗？
30. 切片优化（可以讲一下）
31. 你们向量化原来用的是什么（模型）？
32. 那这块是没变的，你基本上做的就是切片的优化，还有一个（query 优化）？
33. 你觉得这几部分（切片 / 召回 / 重排）分别的贡献占比有多大？
34. 你们这套上了之后，有没有做过 bad case 的抽检？都是些什么模块的？
35. 你们整个（检索）这一块为什么不用（别的）切分方式？
36. 它（BGE-M3）和普通 BGE 有什么区别？
37. 你们这个 top k 取多少？
38. 线上 QPS 你整个这个系统有多大？
39. 如果 QPS 扛不住，你觉得怎么办？
40. 你们目前是没做（限流、缓存）的是吧？
41. 你那个文档切片那一块，你里面有些什么不一样的切片（策略）？
42. 举个例子：设备型号这类精确查询，如果切片切得不好、召回很差，该怎么处理？
43. 你们整个运维的 Agent 用的是一个什么样的（框架 / 范式）？
44. 你调的工具都是些什么工具？
45. 有没有碰到过模型调用工具的时候，参数幻觉、瞎编（参数）？怎么处理？
46. 你们这里面有做一些记忆（机制）是吧？多轮对话记忆怎么做的？
47. 长期记忆里面有做那种「记忆分析 / 记忆更新」吗？
48. 场景：一个用户昨天在处理一台故障设备，今天来问「我昨天那台坏掉的设备现在怎么样了」，你这个能实现吗？
49. 你的长期记忆是只要超出几十轮对话以外的，就全部存到长期记忆里面去？
50. 那你整个上下文的摘要压缩是怎么做的？
51. 你简历上写的「故障诊断从 15 分钟缩短到 1 分钟」，这个指标是怎么测的？
52. 你们有没有碰到过这种情况：模型给出的建议是错的？
53. 实际运维时要去修这台机器，模型给了一个错误的诊断 / 建议，怎么办？

《参考解析》

十万架无人机同屏渲染：先砍数量，再砍像素，最后才谈画质。 渲染十万个对象的核心矛盾不在 GPU 算三角形，而在 CPU 提交十万次 draw call 和遍历十万个对象。正常顺序是：① 视锥剔除 + 空间索引——把无人机按位置放进四叉树 / 八叉树 / 网格（网格更简单，动态对象更新成本低），只对相机可见范围内的对象做后续处理；② 实例化渲染——同型号无人机共享一份几何，用 InstancedMesh 一次 draw call 画完一批，差异（位置、朝向、自发光状态）走实例属性；③ 层级细节（LOD）——远处的无人机退化成点精灵或 1～2 个三角形，甚至只画一个 billboard；④ GPU 端算位置——轨迹插值放进顶点着色器（传时间戳和轨迹采样点，GPU 自己算当前时刻位置），避免每帧在 JS 里更新十万个矩阵；⑤ 真到极限了再上 离屏合成/降频更新（远处小目标按 30Hz 而非 60Hz 更新）。注意「空间索引」解决的是「哪些要画」，实例化解决的是「怎么少画几次」，两者不互相替代，面试时要把这两层分开讲。

RAG 的切片优化为什么能带来 58%→92% 的提升，以及怎么讲清归因。 切片是检索链路里最上游、也最容易被低估的一环：切得太碎会丢上下文（模型拿到半句话答不出），切得太粗会让向量被多个主题平均掉（召回噪声大）。常见做法是语义 / 结构感知切片——按标题层级、段落、表格边界切，配合重叠窗口；对表格和参数列表这类结构化内容不要按字数硬切。至于贡献占比（切片 / 召回 / 重排各占多少），诚实的答法是承认没法干净归因：应说明做过哪些消融（比如只换切片、只加重排），并指出指标提升往往是「切片修好了，重排才有东西可排」的依赖关系；如果有消融数据就给数字，没有就明确说没有——面试官问的是你有没有实验意识，不是要一个精确的百分比。

BGE-M3 与普通 BGE 的区别，以及 top-k 怎么定。 BGE-M3 的三个卖点是 Multi-Linguality（多语言）、Multi-Granularity（支持到 8192 token 的长文本）、Multi-Functionality（同一个模型同时出 dense、sparse/lexical、colbert 多向量三种表示，可以做混合检索再融合）。普通 BGE（如 bge-large-zh）是纯 dense 的双塔句向量，输入通常限 512 token，长文档必须切。选它是因为长切片不用二次截断，且可以 dense + 稀疏融合，对「设备型号」这类精确 token 更友好。top-k 没有标准答案：一般召回阶段 k 取大（20～100）保证不漏，重排后再截到 3～8 喂给模型；要结合上下文窗口、延迟预算和评测集上的 recall@k / nDCG 定，并且说明你是怎么调的。

精确查询（设备型号）召回差怎么办——不要只靠向量。 型号、编号、错误码这类查询，语义向量天然弱势（「A1234」和「B5678」在向量空间几乎一样近），正确解法是混合检索：一路 dense 走向量相似度，一路稀疏（BM25 / BGE-M3 的 lexical 权重 / n-gram）走字面匹配，两路用 RRF 或加权分数融合；再对识别出的实体做结构化过滤（元数据里带 device_model，直接 where 过滤）或精确匹配加分。切片层面则要保证型号所在的整行 / 整段是完整切片，不要把型号和它的参数切散。上线后靠 bad case 抽检回补这类查询进评测集。

Agent 的工具参数幻觉与可靠性兜底。 参数幻觉的典型形态是：工具名对、JSON 结构对，但参数值凭空编（编一个不存在的设备 ID、错误的时间范围）。做法分三层：① Schema 强约束——工具参数用严格的 JSON Schema / Pydantic / Zod 校验，类型、枚举、格式（日期、ID 正则）在服务端拦住，不合法直接返回结构化错误让模型重试；② 先查后填——把「拿到 device_id」做成独立工具（按名称搜索设备），模型必须先调用它拿到真实 ID，禁止自己编 ID；③ 结果侧兜底——工具有效性校验（查不到就明确返回「未找到」而不是空结果），对写操作加二次确认或人工确认闸，失败重试设上限（比如 2 次）后回落成「请你提供 XX 信息」。日志里要记录「模型原始参数 / 校验后参数 / 是否被拒」，否则没法定位是模型问题还是工具问题。

长期记忆与上下文压缩：分层存、按需取，不要「超出 N 轮就丢进长期记忆」。 更靠谱的结构是：工作记忆（当前会话的完整消息，按 token 预算滚动截断或摘要）+ 情景记忆（发生过的事件 / 任务，落库并带时间、设备、结论等结构化字段）+ 语义记忆（从多次交互中提炼的稳定偏好或事实）。写长期记忆的触发点不该是「轮数」，而应是信息价值判断（是否出现了新的实体、结论、未完成的待办），通常由一次独立的 LLM 抽取完成，并做去重 / 冲突消解（同一设备的新状态覆盖旧状态，而不是并列堆积）。取的时候用检索（按当前 query + 实体过滤）而不是全量塞回上下文。所以「昨天那台坏掉的设备现在怎么样了」这种问题的解法是：从 query 里抽实体（设备），去情景记忆按设备 ID + 最近时间检索，拿回状态和结论；能不能答对，取决于当时有没有把「我处理了哪台设备、结论是什么」结构化写下来——如果只存了一段对话摘要，是检索不出来的。

「15 分钟缩短到 1 分钟」这类指标要能说清口径。 面试官问这个是在验真：指标是端到端还是单环节？15 分钟是人工排查的均值还是某个 case 的耗时？分母是多少次样本？是压测环境还是真实线上？有没有对照组？能不能复现？靠谱答法是给出口径 + 样本量 + 测量方式（比如「线上工单系统里 200 条已完成工单，从提交到给出诊断结论的中位耗时，改造前后各取一个月」），并主动说明哪些因素是混淆的（设备类型不同、故障分布不同）。答不上口径，比不给数字更伤——面试官会直接判定这个数字是编的。