面试题库

14 天用 Agent 搭一条 AI 短剧生产线

D4 从分镜到镜头：图生视频、异步任务轮询与失败重试

• 生成类接口返回失败，你怎么判断该不该重试？重试几次之后该做什么？When a generation API returns a failure, how do you decide whether to retry, and what happens after the retries run out?

  国内高频海外高频深入#error-handling#retry#cost

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

  1. 这题的题眼是「判断」。按状态码首位数字一刀切是最常见的错误答案，因为生成类接口的业务错误码往往和 HTTP 状态码不在一个层面上——很多厂商的失败是 HTTP 200 加一个响应体里的业务码。
  2. 给一条可复用的判据，比背错误码表有用：问三个问题——等一等会不会好、改输入会不会好、还是必须叫人来。三个问题对应三种处置：退避重试、修请求、立刻告警。
  3. 落到具体：限流和服务端故障属于第一类，程序自己扛；参数无效与内容审核属于第二类，重试一万次都是同一个错，而且会挤占限流额度让真正该重试的排不上号；鉴权失败与余额不足属于第三类，重试只会延迟告警。
  4. 然后单独处理超时，这是最能体现经验的一条：超时不是失败，是状态未知，对方队列里那个任务可能还在跑甚至已经成了。所以超时之后不能直接重提，要先按幂等键查一遍已有产物。
  5. 重试用尽之后要做三件事，缺一不可：把这一条标成失败并记下最后一次的错误码与请求参数、继续跑批次里剩下的任务不要中断、把失败清单汇总成一次可读的告警而不是每条发一次。
  6. 可以预期的追问：重试次数怎么定？按单价定。单价越高，允许的重试次数越少，而且高单价的失败更应该先送人复核再决定要不要重做。

  How to reason about it · think before answering

  1. The hinge is 'decide'. Bucketing by the leading digit of the HTTP status is the classic wrong answer, because generation APIs often return HTTP 200 with a business error code in the body.
  2. Give a reusable test instead of reciting a code table: ask three questions — will waiting help, will changing the input help, or does a human have to step in? They map onto three dispositions: back off and retry, fix the request, alert immediately.
  3. Concretely: rate limits and server errors are the first bucket and the program handles them; invalid parameters and content moderation are the second, where retrying repeats the same error and burns rate-limit budget that genuinely retryable tasks needed; auth failure and insufficient balance are the third, where retrying only delays the alert.
  4. Handle timeout separately — this is the line that signals experience. A timeout is unknown, not failed: the job may still be running, or may have finished. So never resubmit blindly; look up the idempotency key for an existing artifact first.
  5. When retries are exhausted, do three things: mark the item failed with the last error code and the exact request parameters, keep processing the rest of the batch instead of aborting it, and aggregate the failures into one readable alert rather than one per item.
  6. Expect the follow-up: how many retries? Scale it by unit price. The more expensive the call, the fewer automatic retries, and expensive failures should go to a human for review before being redone.

  答题要点

  • 不要按状态码首位一刀切，生成类接口的业务错误码常常藏在 HTTP 200 的响应体里
  • 判据是三个问题：等一等会不会好、改输入会不会好、还是必须叫人来，分别对应退避重试、修请求、立刻告警
  • 限流与服务端故障可重试；参数无效与内容审核重试无用且会挤占限流额度；鉴权失败与余额不足必须告警
  • 超时是状态未知不是失败，重试前先按幂等键查一遍已有产物，否则会重复计费
  • 重试用尽后：标记失败并留下错误码与请求参数、不中断整批、把失败汇总成一次可读告警；重试次数按单价定

  Key points

  • Do not bucket by the leading HTTP digit; generation APIs often hide the business error code inside an HTTP 200 body
  • Use three questions — will waiting help, will changing the input help, or is a human required — mapping to back off, fix the request, alert
  • Rate limits and server errors are retryable; invalid parameters and moderation blocks are not and waste rate-limit budget; auth and balance failures need an alert
  • A timeout is unknown rather than failed: check the idempotency key for an existing artifact before resubmitting, or you pay twice
  • When retries run out, mark the item failed with its error code and request parameters, keep the batch running, and aggregate failures into one alert; scale retry counts by unit price

D9 并发与配额：多集同时开机，还不能把厂商额度打爆

• 收到限流响应之后，除了退避重试还该做什么？Beyond backing off and retrying, what else should happen when you get rate limited?

  国内高频海外高频深入#rate-limiting#error-handling#retry

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

  1. 这题在考你有没有真在生产里被限流打过。只答「指数退避加抖动」是标准答案的前半段，面试官等的是后半段。
  2. 先把限流摆正位置：它不是错误，是信号。它告诉你此刻的发送速率超过了厂商愿意接受的速率。既然是信号，就该有反馈动作，而不只是重试。
  3. 第一个动作是主动降速：把令牌桶罚一档，接下来一两个窗口只发一半令牌。不降速的话，退避结束后你会用同样的速度再撞一次，重试次数越多越糟。
  4. 第二个动作是别在退避里占着执行流。正确做法是把任务重新入队并记一个「不早于」时间戳，槽位立刻还回去给别的任务。
  5. 第三个动作是分类：限流和服务端错误可以重试，鉴权失败、余额不足、参数错误、内容审核不通过一次都不该重试——重试只会让你在一分钟里把同一个错误犯五遍，还白占配额。MiniMax 这边 1002 是限流、1039 是 TPM 维度的限流，1004 鉴权、1008 余额、2013 参数、1026 和 1027 是内容审核。
  6. 第四个动作是把限流次数记进指标。撞得多说明闸门配小了或者配大了，这个数字是你回头调参数的唯一依据。
  7. 可预期的追问是「退避上限怎么定」。定在业务能等的时间上，超过就转降级：换更小的分辨率、更短的时长，或者干脆排到下一批。

  How to reason about it · think before answering

  1. This question separates people who have actually been throttled in production. Exponential backoff with jitter is only the first half of the answer.
  2. Frame it correctly: throttling is a signal, not an error. It says your current send rate exceeds what the vendor will accept right now, so it deserves a feedback action, not just a retry.
  3. Action one is to slow down on purpose: penalize the bucket so the next window or two issues half the tokens. Without that, you finish the backoff and hit the same wall at the same speed.
  4. Action two is to not hold an execution slot while waiting. Requeue the job with a not-before timestamp and hand the slot back immediately.
  5. Action three is classification. Throttling and server errors are retryable; auth failure, insufficient balance, invalid parameters and content-policy rejections are not, and retrying them just repeats one mistake five times while consuming quota. At MiniMax, 1002 is rate limiting and 1039 is the token-per-minute variant, while 1004 is auth, 1008 is balance, 2013 is bad parameters and 1026 or 1027 are content rejections.
  6. Action four is to record throttle counts as a metric. That number is the only evidence you have when you later retune the gate.
  7. Expected follow-up: how to cap the backoff. Cap it at what the business can wait for, then degrade instead of retrying: smaller resolution, shorter duration, or push the job into the next batch.

  答题要点

  • 把限流当信号：退避的同时给令牌桶降档，接下来的窗口只发一半令牌。
  • 退避期间把任务重新入队并记一个不早于时间戳，工作槽立刻还回去。
  • 退避要带抖动，否则同时被限的任务会同时醒来再撞一次。
  • 严格区分可重试与不可重试：鉴权、余额、参数、内容审核一次都不重试。
  • 把限流次数记成指标，它是回头调闸门参数的唯一依据；退避到上限就转降级而不是继续重试。

  Key points

  • Treat throttling as a signal: back off and also penalize the bucket so the next window issues fewer tokens.
  • Requeue with a not-before timestamp instead of sleeping inside the worker slot.
  • Add jitter, or everything throttled together wakes together and collides again.
  • Separate retryable from non-retryable: auth, balance, bad parameters and content rejections get zero retries.
  • Emit a throttle counter as a metric, and switch to degradation once backoff hits its ceiling.