Dayward AI

Interview Bank

328 questions total; 1 shown with current filters.

Tag
126 more tags
#agent-loop2#api-design2#chunking2#cost-tradeoff2#debugging2#distributed-systems2#error-handling2#hybrid-search2#llm-as-judge2#multi-agent2#multi-hop2#oauth2#operations2#pipeline-design2#prompt-caching2#rag2#recall2#retrospective2#retry2#scheduling2#sse2#tool-permissions2#trade-offs2#access-control1#agentic-rag1#agents-sdk1#analytics1#architecture-review1#behavioral1#budget-control1#caching1#cancellation1#checkpointing1#circuit-breaker1#citation-verification1#client1#client-integration1#coding-agent1#compaction1#compliance1#concurrency1#confused-deputy1#context-engineering1#contextual-retrieval1#copyright1#correctness1#customer-support1#data-quality1#database1#deployment1#distribution1#embedding-migration1#error-propagation1#escalation1#evidence1#faithfulness1#fallback1#feedback-loop1#fencing-token1#filter-pushdown1#filtering1#framework-design1#graph-rag1#guardrails1#handoff1#image-generation1#integration1#iterative-scan1#json-parsing1#labeling1#latency1#latency-budget1#least-privilege1#long-context1#long-session1#long-term-memory1#mcp1#message-bus1#methodology1#model-migration1#multi-tenancy1#notifications1#ocr1#offline-testing1#project-storytelling1#protocol-versions1#quality1#query-rewriting1#rate-limiting1#reconnect1#refusal1#replay1#reproducibility1#rerank1#resume1#retrieval1#risk-assessment1#rollout1#routing1#runtime1#safety1#scaling1#self-introduction1#split-brain1#state-management1#state-persistence1#statelessness1#stdio-transport1#storytelling1#subagent1#subagents1#subscriptions1#test-strategy1#thresholds1#timezone1#token-accounting1#tool-design1#tool-schema1#tools1#trust-boundary1#ux1#verification1#versioning1#workflow-design1#workflow-engine1#zero-downtime1

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

D2 The Script Agent: Turning a Single Sentence Into Structured Data — Character Cards, Scenes, and Shots

  • In a generator-plus-reviewer loop, how do you define convergence so it does not burn budget indefinitely?生成加评审这种双角色循环,收敛条件该怎么定才不会一直烧钱?
    Common in ChinaCommon overseasDeep dive#agent-loop#cost-control

    How to reason about it · think before answering

    1. This screens whether you have ever made such a loop actually terminate. Answering only set a max round count scores nothing — that prevents an infinite loop, it is not convergence design. The signal is naming three exits plus how the reviewer itself is built.
    2. Start with the reviewer: it should not be one model but two layers. Machine-checkable defects (missing fields, out-of-range numbers, length limits, invalid references) go to code; only the judgment calls go to the model. This decides score stability — a pure-model reviewer can swing by ten-plus points on the same draft, and then convergence is meaningless.
    3. Then the three exits: stop on threshold (the threshold means good enough, not perfect — chasing the last few points costs far more than it returns); stop at the round cap, handing back the highest-scoring draft rather than the last one, because review scores fluctuate; and escalate to a human once only judgment-call issues remain, since a model reviewing and revising itself just circles.
    4. Also cover the scoring weights: hard defects should dominate, say seventy percent, with the model's soft score at thirty. Otherwise one flattering model review outweighs five real field errors and the loop declares success on round one.
    5. Conclusion and cost: all three exits need parameters, and parameters need empirical tuning. Too high a threshold burns every round; too low ships an unusable draft. Plot the score curve before shipping and confirm it rises monotonically.
    6. Likely follow-up: how do you know it is improving rather than oscillating? Track the hard-defect count — it is deterministic, while the score jitters. If hard defects do not fall, the writer is not acting on feedback, and the fix is feedback granularity: tag each issue with a category so the model knows which class to repair.

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

    1. 这题在考「你有没有让这种循环真的停下来过」。只答「设一个最大轮数」拿不到分,那只是防死循环,不是收敛设计。区分度在于你能不能说出三个出口以及评审本身该怎么构造。
    2. 先拆评审:评审不该是一个模型,而是两层——能被程序判定的硬伤用代码查(字段缺失、数值越界、长度超限、引用不合法),程序判不了的软伤才交给模型。这一步决定了分数稳不稳定:全交给模型,同一份稿子两次评分能差十几分,循环就没有收敛可言。
    3. 再说三个出口:达标就停(阈值是「够用」不是「完美」,追最后几分成本远高于收益);到轮数上限就停,而且要交出历史最高分那一稿而不是最后一稿,因为评审有波动;剩下的问题全是软伤时转人工,因为让模型自己评自己改只会原地打转。
    4. 还要说计分方式:硬伤应该占大头(比如七成),软分占小头。否则模型一句好评就能盖过五条实打实的字段问题,循环会在第一轮就假装达标。
    5. 结论加代价:三个出口都需要参数,而参数必须实测调。阈值高了轮数用满,低了稿子不能看;上限大了烧钱,小了永远差一口气。上线前要把分数曲线画出来看它是不是单调上升。
    6. 可预期的追问:怎么知道循环真的在变好而不是在抖动?看硬伤条数,它是确定性的;分数会抖,硬伤条数不会。硬伤降不下去就说明写手根本没在按意见改,问题出在意见的粒度上——意见要带分类标签,模型才知道该改哪一类。

    Key points

    • Split the reviewer: code judges hard defects, the model judges only judgment calls — otherwise scores are unstable and nothing converges
    • Three exits: stop on threshold, stop at the round cap returning the best draft, escalate to a human when only soft issues remain
    • Weight hard defects heavily so a flattering model review cannot mask real field errors
    • Tag each review issue with a category so the writer repairs one class at a time
    • Measure convergence by hard-defect count, not score — the score jitters, the count does not

    答题要点

    • 评审分两层:硬伤用代码判,软伤才交给模型,否则分数不稳定、循环无从收敛
    • 三个出口:达标就停、到轮数上限交历史最高分那一稿、只剩软伤时转人工
    • 计分让硬伤占大头,避免模型一句好评盖过实打实的字段问题
    • 评语必须带分类标签,写手才能只改那一类,改稿才是收敛的
    • 观测收敛看硬伤条数而不是分数,分数会抖、硬伤条数是确定的