快手效果营销实习一面：意图路由、模型容错与业务校验
本场面试题
- 两层意图识别怎样分工，什么时候值得拆层？
- 意图阈值和模型相关度分数怎样验证？
- 为什么两次简单调用有时比一次复杂调用更快？
- 意图节点应记录哪些可执行信息？
- 意图节点用 Redis 缓存时，怎样选择结构并处理一致性？
- 把查询向量化前置，与跨请求缓存有什么区别？
- RAG 检索中的哪些工作可以并行？
- Rerank 在召回后做什么，怎样验证收益？
- 多子问题召回的结果为什么还要去重？
- 模型调用的三态熔断怎样与备用模型配合？
- 多轮检索为什么需要指代消解？
- 会话摘要保存什么，怎样触发并更新？
- 可重入锁为什么需要持有者与重入计数？
- 怎样用责任链组织优惠券业务校验？
- 到期消息延迟或积压时，怎样保证优惠券过期正确？
面经与参考答法
快手效果营销实习一面：意图路由、模型容错与业务校验
原帖自述为快手效果营销方向日常实习一面，时长约 54 分钟，发表于 2026 年 8 月；正式职位、面试日期及实际系统配置未披露。本页围绕 RAG 路由、缓存、容错和后端校验整理技术追问，不把教学方案写成当事人的项目实现。
面试经历为个人自述，未经企业独立确认。以下短答及示例为编辑教学整理，不代表当事人的现场回答、项目配置或实验结果。
（1）两层意图识别怎样分工，什么时候值得拆层？
可以先识别任务大类，再在较小的候选集合内选择细分动作；这是教学设计示例，原帖没有给出两层的真实职责。拆层应减少候选混淆、支持不同策略或更明确地处理未知意图，同时保留澄清和退出分支。若层级错误会阻断正确下游，或单层已经满足质量和预算，就应比较合并方案，不能把层数更多当作效果更好。
（2）意图阈值和模型相关度分数怎样验证？
模型自报分数不能直接当成校准后的概率。先定义误路由与漏路由的代价，用带未知类、歧义和困难样本的标注集比较阈值、拒绝与澄清策略；固定模型、提示和输出结构，再观察重复运行及分布变化。结构化输出可以限制格式，不能保证分数稳定或判断正确，阈值需要用真实误差重新校准。
（3）为什么两次简单调用有时比一次复杂调用更快？
只有实测才能成立。较短提示、小候选空间或较小模型可能缩短每次推理，但额外网络往返、排队和重复上下文也会增加耗时。先画出依赖链，分别测各阶段及端到端分布，在相同负载、输出长度和质量条件下比较；若第二次调用依赖第一次结果，就不能把它们算作并行收益。
（4）意图节点应记录哪些可执行信息？
先定义路由节点能选择什么下游以及谁有权使用它。教学上可记录稳定节点 ID、候选动作或索引、必要参数、权限条件和配置版本，并验证必填字段与未知分支。标签文字与执行标识应分开，缓存和运行轨迹须能指向同一配置版本；这些是设计建议，原帖没有公开真实节点 Schema。
（5）意图节点用 Redis 缓存时，怎样选择结构并处理一致性？
按实际访问方式决定：整对象读取可存序列化值，字段级访问可考虑 Hash，不能仅凭“意图节点”推断实现。先明确配置或数据库是权威来源，再用版本、失效通知、TTL 和校验减少旧值传播；并发回填、通知丢失和旧请求覆盖也要处理。TTL 或一次删除不能保证跨层强一致，权限变化更不能只等自然过期。
（6）把查询向量化前置，与跨请求缓存有什么区别？
若多个下游分支使用完全相同的查询及 Embedding 配置，可以先计算一次并在本请求内复用，避免重复工作。跨请求缓存还须设计包含规范化输入、模型版本、预处理及相关数据边界的键，并处理失效、隐私和容量。改写后的子问题可能需要不同向量，不能把“前置一次”套到语义不同的输入；原帖未说明其采用哪种复用边界。
（7）RAG 检索中的哪些工作可以并行？
先确定已授权的索引与过滤边界，再在该范围内并行没有真实数据依赖的分支，例如同一已确定查询上的不同索引召回；需要前一步输出的改写、向量化、检索或重排仍要等待对应输入。给并行分支共同 Deadline、并发上限与失败策略，并在汇总后复核结果范围、去重和排序。比较端到端尾延迟与质量，避免仅减少串行步骤却压垮下游。
（8）Rerank 在召回后做什么，怎样验证收益？
先召回候选，再让重排器联合比较查询与候选片段，选择适量证据进入上下文。重排无法找回没有召回的材料，分数也不等于事实正确概率。使用同一查询—证据测试集，对比排序质量、最终回答和时延成本，并记录截断、权限过滤及模型版本；原帖没有给出重排模型或实现。
（9）多子问题召回的结果为什么还要去重？
多个查询可能返回同一片段、同文不同切块或近似转载，直接拼接会浪费上下文并夸大证据数量。先用稳定文档与片段标识处理精确重复，再在保留出处、版本和权限的前提下处理近重复。相似主题不等于重复事实，去重过度可能丢掉例外或冲突证据，需用测试集检查覆盖。
（10）模型调用的三态熔断怎样与备用模型配合？
Closed 正常调用并观察失败，Open 暂时阻断持续故障的依赖，Half-open 允许有限探测，依据结果决定恢复或继续熔断。备用模型要满足同一任务的上下文、工具、输出格式、模态和数据策略要求，并共享剩余超时与成本预算。切换前检查已发生的副作用；主调用失败不代表可以安全重做全部动作。
（11）多轮检索为什么需要指代消解？
“它”“上一项”等表达依赖历史，直接送去检索可能缺失实体或条件。改写应利用有权限的对话上下文补齐明确指代，同时保留否定、时间与版本限制；不能把模型猜测写成用户事实。若存在多个可能对象，先澄清。保留原问与改写结果，分别评估检索和最终回答，避免改写看似通顺却改变需求。
（12）会话摘要保存什么，怎样触发并更新？
摘要优先保留当前目标、已确认事实、约束、未完成事项和可回取的原文引用，而不是只保存对话大意。可按 Token 预算、阶段完成或历史增长触发，但阈值要依据任务验证。异步生成的摘要应携带覆盖范围和版本，写入前核对是否已过时；原始记录、否定条件与授权范围不能因压缩丢失。
（13）可重入锁为什么需要持有者与重入计数？
同一执行线程已持锁时，再次进入受同一锁保护的调用链可以增加重入计数，避免把自己阻塞；其他线程仍须等待。解锁要核对持有者并对应减少计数，计数归零才真正释放。可重入不意味着公平、不会死锁或可以跨异步线程随意继承，使用时仍需明确锁对象、临界区和异常释放规则。
（14）怎样用责任链组织优惠券业务校验？
把可独立说明的规则组织成有顺序的处理器，并明确是命中一个处理器就结束，还是所有校验通过才继续。教学示例可先检查输入，再检查资格和有效期；节点名称与顺序需要真实业务规则决定，原帖没有披露其配置。失败结果要稳定、可观测，校验尽量不产生副作用；实际领取或核销仍要用事务、条件更新与幂等保护并发。
（15）到期消息延迟或积压时，怎样保证优惠券过期正确？
到期时间与权威业务状态决定能否使用优惠券，消息只是触发状态维护的途径。使用时按可信时间检查 expireAt，并用条件更新或事务防止过期后核销；到期任务应幂等，可用补偿扫描修复漏处理。积压时先分辨生产速率、消费耗时和失败重试，限制无效重试并扩容或降级，不能把“消息准时到达”当作正确性的唯一前提。