Interview Bank

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

D4 From Shot to Footage: Image-to-Video, Polling Async Tasks, and Retrying Failures

• How do you choose a polling interval, and why is a fixed interval a bad default?轮询间隔怎么定？为什么不能一直用固定间隔死等？

  Common in ChinaCommon overseasBasic#async-task#backoff

  How to reason about it · think before answering

  1. This looks like a giveaway, but it has three layers and only the first one is obvious. They want to know whether you have actually written this loop.
  2. Layer one is cost: a task queued for five minutes polled every second is three hundred wasted requests. The query endpoint has its own rate limit, so you can throttle yourself and then misread 'rate limited' in the logs as a generation problem.
  3. Layer two is capping the backoff: multiply without a cap and you end up polling every few minutes, sleeping long after the task finished. Pick the cap from what extra wait a user tolerates — usually in the ten-to-twenty-second range.
  4. Layer three is where people actually get it wrong: the timeout check belongs before the sleep, and the test is whether sleeping would cross the deadline. Sleeping first means overshooting the budget by a full interval, which at a twenty-second backoff is twenty wasted seconds.
  5. Mention ordering too: check terminal states before the timeout. Discarding a task that just succeeded on the final poll means paying for an artifact you then throw away.
  6. Expect the follow-up: how do you pick the initial interval? From the typical duration of this class of task, a bit above a tenth of it; and the very first poll can be delayed slightly, since a just-submitted task is almost never done.

  分析过程 · 先想清楚再作答

  1. 这是一道送分题，但它有三个层次，只答出第一层拿不到高分。面试官想看的是你有没有真的写过这个循环。
  2. 第一层是成本：一个排队五分钟的任务，用一秒的固定间隔就是三百次无效请求。查询接口自己也有速率限制，你很可能自己把自己打到限流，然后在日志里看到「生成失败：限流」，还以为是生成接口的问题。
  3. 第二层是退避要封顶：只乘不封顶的话，退到后面已经是几分钟查一次，任务早就好了你还在睡。上限的选法是「用户能忍受的额外等待」，一般十几到二十秒。
  4. 第三层最容易写错，也是这题真正的区分点：超时判断必须放在睡觉之前，判据是「睡下去会不会越过截止时间」。先睡再判会让你在预算之外多睡整整一轮，退避到二十秒时就是白等二十秒。
  5. 另外提一条顺序：先判终态再判超时。任务恰好在最后一次查询里成功却被当成超时扔掉，等于付了钱还丢了产物。
  6. 可以预期的追问：起步间隔怎么定？按这类任务的典型耗时定，比典型耗时的十分之一略大即可；再往细说就是首次查询可以稍微延后一点，因为刚提交的任务几乎不可能立刻完成。

  Key points

  • A fixed interval is either too tight, wasting requests and throttling yourself, or too loose, adding dead time after completion
  • Use exponential backoff starting near a tenth of the task's typical duration
  • Cap the backoff, choosing the cap from the extra wait a user will tolerate
  • Check the timeout before sleeping, testing whether the sleep would cross the deadline, or you overshoot the budget by a full interval
  • Check terminal states before the timeout so a task that just succeeded is not discarded

  答题要点

  • 固定间隔要么太密造成大量无效请求并把自己打到限流，要么太疏让完成后的等待过长
  • 用指数退避：从接近典型耗时十分之一的间隔起步，每轮乘一个系数
  • 退避必须封顶，上限按用户能忍受的额外等待来定
  • 超时判断放在 sleep 之前，判据是「睡完会不会越过截止时间」，否则会在预算之外多睡一轮
  • 先判终态再判超时，避免把最后一次查询里刚成功的任务误杀