考察点
这道题出自华为 AI Agent 产品经理岗二面,场景限定得很死:专业领域、RAG、检索超过 2 秒。面试官不是想听「让用户等」或「不等」的二选一答案,而是想看你能不能把这 2 秒拆开——延迟到底花在哪个环节、用户在等待中失去的是什么、流式返回的内容会不会反而误导用户。华为这类 To B/政企背景的 Agent 岗,格外看重候选人对「专业场景下错误答案的代价」有没有体感。追问一般会往三个方向走:检索慢本身怎么治本、流式先吐的内容被后续检索结果推翻怎么办、你会用什么指标来证明方案有效。
参考答案
先把这 2 秒拆开,别急着回答等不等
拿到这道题我的第一反应是:检索耗时超过 2 秒,这本身就不正常,得先搞清楚钱花在哪了。一条标准的 RAG 链路,query 改写和向量召回通常几百毫秒内能搞定,如果整体破 2 秒,大概率出在三个地方:知识库规模上来之后索引没优化、多路召回串行执行,或者 Rerank 模型对过大的候选集逐条打分。所以我的完整答案是:体验层面用流式和状态透明把等待感消化掉,但同步要把检索慢当成一个独立的技术债立项去修——体验方案是止痛片,不是治疗方案。如果面试官只允许二选一,我选「先返回部分内容」,但会马上补一句:返回什么、怎么返回,比返不返回重要得多。
专业场景不能先吐答案,要先吐「进度」
这里有个关键判断:专业领域问答和闲聊不一样,答案强依赖检索结果,模型在拿到检索内容之前就开始生成,等于逼着它幻觉。所以流式策略不能是「先让模型自由发挥,检索到了再修正」,而是分阶段的结构化流式:第一阶段,几百毫秒内先返回检索中的状态信息,比如「正在检索 XX 知识库,已找到 5 篇相关文档」,这一步几乎零成本,但能把用户的焦虑从「它是不是卡死了」转化成「它在干活」;第二阶段,检索和 Rerank 完成后,流式吐正文,正文里带引用角标;第三阶段,正文结束后补引用列表和置信提示。实测下来,同样 2.5 秒的总耗时,有阶段状态提示的满意度比干等转圈高得多——用户怕的不是等,是不知道在等什么。这里还有一个容易被忽略的细节:阶段提示的文案必须是真状态,不是安慰动画。如果「已找到 5 篇文档」是写死的假数据,用户多遇到几次就会发现规律,信任瞬间归零,还不如一个老实的转圈。状态信息要从检索服务真实透传,这就要求检索链路把中间结果作为事件流暴露出来,是产品和工程要一起定的接口约定。
快慢路径分层,别让所有问题都走完整链路
不是所有专业问题都需要 2 秒的检索。我的做法是把 query 分层:高频标准问题(占流量可能三到四成)走缓存,命中预计算答案直接返回,控制在 500 毫秒内;确定性高的事实类问题走「轻检索」——减少召回路数、Rerank 只对 Top10 而不是 Top100 打分,压到 1 秒左右;真正复杂的多文档综合问题才走完整链路,并且明确告知用户「这个问题需要综合分析,预计 X 秒」。分层的前提是有一个靠谱的 query 分类器,这个分类器本身可以用小模型做,成本很低。分层之后 P95 延迟往往能砍掉一半,而回答质量几乎不受影响,因为复杂问题的用户本来就有更高的心理等待预期。
兜底和指标怎么定
体验层面还要有最后一道防线:设定总超时预算(比如 8 秒),超时就走降级——要么返回「已检索到的部分资料+明确说明不完整」,要么给出转人工/留言入口,绝不能让请求无限挂着。指标上我重点看三个:TTFT(首 token 时间,直接决定用户「感觉快不快」,我的内部门槛是 800 毫秒)、P95/P99 端到端延迟(防长尾)、以及「等待中途退出率」——用户在看到状态提示后仍然关掉的比率,这个指标比延迟本身更能反映体验优化的真实效果。
可能的追问
- 检索慢怎么治本? 答:按瓶颈对症下药——索引侧做分区索引和向量量化压缩;召回侧把多路召回从串行改并行;Rerank 侧缩小候选集、换更小的排序模型;再加一层面向高频问题的结果缓存。治理后目标是把 P95 压回 1 秒内,缓存命中部分压到 300 毫秒内。
- 先返回的状态信息后来被检索结果「打脸」怎么办? 答:所以第一阶段只暴露「过程」不暴露「结论」——说「找到 5 篇文档」是安全的,说「初步判断是 XX」是危险的。如果实在要先给草稿,必须带显著的「正在核实」标识,且最终版本有出入时主动 diff 提示,专业场景宁可少给不能给错。
- 你怎么证明分层方案有效? 答:灰度发布,对照组和实验组对比 TTFT、P95 延迟、中途退出率和回答采纳率(用户是否采纳/点赞/不追问)。预期是延迟指标明显下降而采纳率不降;如果采纳率掉了,说明快路径分流分错了,回头调分类器。