宇视科技一面：埋点外发协议、导入并发与「AI 助手怎么实现」连环追问

《面试题目》

1. 自我介绍。
2. 项目介绍。
3. 你做了埋点外发，用的是什么协议？每次发的数据量是多少？是私有协议吗？有什么国标吗？
4. 你做的导入功能具体是什么？流程说一下，导出的并发量大概是多少？用的什么协议，每个请求的数据多大？
5. 导入功能的并发量这么高，是怎么处理的？
6. 你做了一些 AI 功能，这个 AI 助手的具体作用是什么？
7. 这个助手是怎么实现的？
8. 你提到的 Skill，是网络上现成的还是自己写的？里面的具体流程是怎样的？
9. 如果对话很多导致后面准确率太低，你会怎么做？
10. 如果对话中出现矛盾，你会怎么做？

《参考解析》

埋点外发这题，面试官在验证「这是你做的还是你抄的」。 需要同时答出四层：协议（HTTP 批量上报还是 MQTT/自定义 TCP，为什么这么选）、数据量（单条多大、一次批量多少条、峰值 QPS 与带宽估算）、可靠性（失败重试与退避、本地磁盘缓冲、断网续传、去重 id）、合规（是否涉及国标或行业标准，比如视频类设备常见的 GB/T 28181、ONVIF，或者日志类走 Syslog）。如果确实是私有协议，就明说「私有」并解释为什么不用现成方案（报文头开销、设备端资源受限、需要携带厂商自定义字段），不要硬编一个国标号——面试官很可能就是做这一行的。

导入并发高怎么处理，答「分层削峰 + 背压」。 入口层限流（按用户/租户令牌桶、单文件大小与行数上限）；接入后立刻异步化——文件落对象存储，写一条任务记录，返回 taskId，由后台 worker 消费，避免 HTTP 线程被长任务占满；worker 侧按批读取（流式解析，不要一次性读进内存）、批量写库（INSERT ... ON DUPLICATE KEY UPDATE 或 COPY）、失败行单独落表供用户下载；进度通过轮询或 SSE 反馈。要说明背压怎么做：队列有界、满了拒绝并给出明确错误，而不是无限堆积把内存打爆。导出的并发量要给出真实数字（比如「单机 4 个 worker，每个 worker 一次处理 5000 行，导出峰值 20 个并发任务」），含糊其辞会被继续追问。

AI 助手的实现，讲清「检索、编排、兜底」三段就够专业。 编排层决定一次请求走哪些步骤（意图识别 → 工具调用/检索 → 生成 → 校验），检索层负责把业务数据、文档、历史工单找出来并裁剪进上下文，兜底层处理工具失败、超时与模型输出不合规。Skill 如果是自己写的，要说清楚它的结构：触发条件、输入参数、执行步骤、失败处理、输出格式——本质上是一段可复用的提示词 + 工具组合，写死的部分是流程，留给模型的是判断。如果是现成的，就说明你怎么改的、改了什么，别把开源的东西说成自研。

「对话变长准确率下降」和「对话里出现矛盾」是两道工程题，不是模型题。 长对话掉准确率的根因通常是上下文里噪声变多、关键信息被淹没、以及模型对早期内容的注意力衰减。可用手段：滚动摘要（把旧对话压成结构化要点而不是原文）、按需检索（把历史存起来，需要时再取相关片段）、显式维护一个「已确认事实」的状态槽（用户的目标、约束、已排除的方案），每轮都把它固定放进上下文、放在靠前或靠后的高注意力位置。矛盾处理则要做「冲突检测 + 主动澄清」：当新信息与状态槽冲突时，不要默默覆盖，而是明确指出来问用户「你刚才说的是 A，现在提到 B，以哪个为准」，并记录这次冲突；对模型自己前后不一致的输出，用一次自检（让模型对照状态槽复核）或规则校验兜住。