逐日AI

面试题库

共 328 题,当前筛选 2 题。

标签
还有 362 个标签
#api-design9#coding-agent9#distributed-systems8#multi-agent8#rag8#chunking7#debugging7#pipeline-design7#structured-output7#agent-loop6#mcp6#operations6#prompt-injection6#sse6#tool-calling6#tool-design6#context5#context-engineering5#deployment5#embeddings5#hybrid-search5#message-bus5#scheduling5#system-prompt5#agentic-rag4#behavioral4#client4#concurrency4#consistency4#framework-design4#ingestion4#prompt-engineering4#rate-limiting4#retrieval4#routing4#trade-offs4#abstention3#agents-sdk3#caching3#communication3#context-window3#cost-control3#data-quality3#failure-modes3#image-generation3#interview-prep3#langgraph3#latency3#llm-as-judge3#llm-basics3#long-context3#model-migration3#model-routing3#orchestration3#ordering3#progressive-disclosure3#prompt-basics3#prompt-caching3#protocol3#provider-abstraction3#ranking3#recall3#redis-streams3#responses-api3#resume3#retry3#runtime3#scalability3#skills3#state-management3#statelessness3#subagents3#timeline3#versioning3#workflow-engine3#access-control2#agent-design2#async-task2#auth2#checkpointing2#citation-verification2#citations2#claude-md2#code-review2#compaction2#context-rot2#contextual-retrieval2#cost-tradeoff2#data-modeling2#database2#distribution2#fallback2#ffmpeg2#golden-set2#grounding2#interview-process2#long-term-memory2#media-pipeline2#memory2#multi-hop2#multi-tenancy2#oauth2#prioritization2#project-storytelling2#prompt-techniques2#query-rewriting2#react2#refusal2#reproducibility2#rerank2#retrieval-quality2#retrospective2#scripts2#sharding2#state-machine2#tool-permissions2#tooling2#tools2#tracing2#transport2#ux2#vector-database2#verification2#workflow2#agent-basics1#agent-quality1#agent-sdk1#agents-md1#altitude1#analytics1#approvals1#architecture-review1#async1#atomicity1#attention-budget1#av-sync1#backoff1#bi-encoder1#bm251#budget-control1#build-vs-buy1#cancellation1#candidate-selection1#capacity-planning1#career1#chain-of-thought1#ci1#circuit-breaker1#claude-code1#cli-design1#client-integration1#cloud1#compliance1#compression1#configuration1#confused-deputy1#consistent-hashing1#content-hash1#content-safety1#context-assembly1#context-compression1#context-management1#copyright1#coreference1#correctness1#cost-accounting1#cost-analysis1#cost-optimization1#cross-encoder1#cross-model1#customer-support1#dag1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#docker1#documentation1#embedding-migration1#encoding1#engineering-judgement1#engineering-tradeoffs1#error-propagation1#escalation1#eval1#event-driven1#evidence1#failure-analysis1#fairness1#faithfulness1#fan-out1#feedback-loop1#fencing-token1#few-shot1#filter-pushdown1#filtering1#fine-tuning1#forking1#four-elements1#framework-selection1#frontend1#global-market1#graph-rag1#guardrails1#hallucination1#handoff1#handoffs1#headless1#hnsw1#hooks1#human-in-the-loop1#hybrid1#hyde1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#integration1#intent-routing1#interrupt-merge1#invalidation1#isolation1#iterative-scan1#ivfflat1#json-parsing1#json-schema1#just-in-time1#jwt1#knowledge-organization1#labeling1#latency-budget1#lease1#least-privilege1#llm-output-quality1#long-session1#loop-guard1#maintenance1#mcp-basics1#mental-model1#messages-api1#metadata1#methodology1#metrics1#migration1#mobile1#model-selection1#moderation1#modularity1#multi-turn1#multimodal1#nodejs1#normalisation1#notifications1#ocr1#offline-testing1#openai1#overlap1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#primitives1#priority-queue1#proactive-messaging1#product-engineering1#production-readiness1#prompt1#prompt-assembly1#prompt-bloat1#prompt-design1#prompt-limits1#prompt-surface1#prompt-template1#prompt-versioning1#prompting1#protocol-versions1#quality1#quality-check1#quantization1#query-transformation1#quiet-hours1#rag-basics1#rank-fusion1#reasoning1#reconnect1#redis1#reflection1#replay1#reporting1#retrieval-failure1#retrieval-metrics1#retry-semantics1#retry-strategy1#review1#risk-assessment1#rollback1#rollout1#rrf1#safety1#sampling1#sandbox1#sandboxing1#scaling1#schema-design1#schema-validation1#scoping1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#self-reflection1#server-design1#service-architecture1#session-management1#sessions1#similarity1#skill-authoring1#skill-description1#skill-design1#spec1#split-brain1#stakeholder-communication1#star1#state-persistence1#stateless1#stdio-transport1#stopping-criteria1#storytelling1#subagent1#subscriptions1#subtitles1#task-graph1#team-governance1#test-set1#test-strategy1#testing1#thresholds1#timezone1#token-accounting1#token-budget1#tool-budget1#tool-execution1#tool-naming1#tool-schema1#trust-boundary1#tuning1#validation1#vector-index1#workflow-design1#xml-tags1#zero-downtime1

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

D5 配音、字幕与音轨:多角色语音、时间轴对齐与字幕文件

  • 语音时长和画面时长对不上,你会调哪一边?为什么?When the synthesized speech and the shot duration disagree, which side do you adjust, and why?
    国内高频海外高频进阶#timeline#tts#pipeline-design

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

    1. 这题只答「调画面」拿不到分,题眼在「为什么」——面试官要的是让步理由,以及你有没有意识到这个选择会决定整条流水线的排列顺序。
    2. 先给判断依据:哪一边的失真观众察觉得到。台词被切掉、或者被加速到语气变形,观众立刻听得出来;一镜比原计划长零点八秒,观众感觉不到。所以让步的是画面。
    3. 由这条判断反推流水线顺序:画面先按计划时长生成,语音合成完之后由真实时长回写镜头时长,剪辑台再去补足画面。为什么不倒过来先合成语音再按语音时长生成视频?因为视频接口的时长是有限档位的,你没法要求它精确生成 6.34 秒。
    4. 补一条不能省的工程细节:写进时间轴的必须是从落盘文件量出来的真实时长,不能是字数估算。估算误差是逐句累加的,第一句差两百毫秒,第十句就差两秒,成片上表现为字幕跟画面赛跑。
    5. 再说例外,这是加分项:如果这一镜的画面本身有强节奏(比如卡点、转场、动作衔接),画面就不能被随意拉长,这时候要回头改剧本把台词写短,而不是硬拉画面。所以被顶长的镜头应该被标记出来交给人复核,而不是程序默默改掉。
    6. 可以预期的追问:那不能微调语速吗?可以,但语速是有代价的——语速改变会同时改变音质与情绪表现,而且它会反过来再改一次时长,等于把一个单向流程变成了循环。留一点余量的做法是给留白参数一个可调区间,先动留白再动语速。

    How to reason about it · think before answering

    1. Answering 'stretch the shot' alone scores nothing; the hinge is 'why'. They want the reasoning for which side yields, and whether you see that this choice fixes the order of the whole pipeline.
    2. State the criterion: which distortion does the audience notice? Clipped or sped-up dialogue is audible immediately; a shot running 0.8 seconds long is not. So the picture yields.
    3. Derive the pipeline order from that: generate video at the planned duration, synthesize speech, write the measured duration back onto the shot, and let the editor pad the picture. Why not synthesize first and generate video to fit? Because video APIs expose discrete duration options — you cannot ask for exactly 6.34 seconds.
    4. Add the engineering detail that cannot be skipped: the timeline must use durations measured from the rendered files, never character-count estimates. Estimation error accumulates line by line, and by the tenth line the subtitles visibly race the picture.
    5. Then the exception, which earns points: if a shot has intrinsic rhythm — a beat cut, a transition, an action match — the picture cannot simply be stretched, and the right fix is a shorter line in the script. That is why stretched shots should be flagged for human review rather than silently rewritten.
    6. Expect the follow-up: can't you just nudge the speaking rate? You can, but it costs you — rate changes affect timbre and delivery, and they change duration again, turning a one-way flow into a loop. Make the lead-in and tail padding adjustable and spend that budget before touching the rate.

    答题要点

    • 调画面:台词被切或被加速观众立刻察觉,镜头长零点几秒观众感觉不到
    • 由此定下流水线顺序:画面按计划时长生成,语音合成后回写真实时长,剪辑台补足画面
    • 不能倒过来按语音时长生成视频,因为视频接口的时长只有有限档位
    • 时间轴必须用落盘文件量出的真实时长,字数估算的误差会逐句累加
    • 画面有强节奏的镜头是例外,这类冲突应标记出来交人复核而不是程序默默改掉

    Key points

    • Stretch the picture: clipped or sped-up dialogue is instantly audible, while a fraction of a second of extra shot length is not
    • That fixes the pipeline order: generate video at planned duration, synthesize speech, write measured duration back, pad in the edit
    • You cannot invert it and generate video to match speech, because video APIs only expose discrete durations
    • The timeline must use durations measured from rendered files; character-count estimates accumulate error line by line
    • Shots with intrinsic rhythm are the exception, so flag stretched shots for human review instead of silently rewriting them
  • 多角色配音里,怎么保证同一个角色跨集用的是同一个声音?In a multi-character pipeline, how do you guarantee the same character keeps the same voice across episodes?
    国内高频海外高频基础#tts#consistency#provider-abstraction

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

    1. 这题看着像配音问题,其实考的是状态该存在哪里。答「配置里写死」不算错,但只答到这一层看不出工程判断。
    2. 先说清楚风险来自哪:声音是角色身份的一部分,观众对它的敏感度不低于脸。跨集不一致的典型成因有三个——每集独立跑一次流程、音色靠临时映射或随机挑选、以及某次为了改一句台词的语气顺手改了这个角色的全局参数。
    3. 解法是把音色归档而不是归代码:角色档案里带一个音色字段,配音环节只读不写。这样一致性由档案保证,跟哪一集、哪一次运行、谁跑的都无关。这跟角色形象靠基准图归档是同一套思路。
    4. 但只存音色标识还不够,跨集听感一致还依赖另外两项:基调情绪与语速。同一个音色用两种语速念,听起来像两个人的状态。所以档案里要一起存这三项,单条台词只允许覆盖情绪,不允许覆盖语速。
    5. 再补一层防御:把音色标识连同模型名一起记进产物元数据。厂商下线或重命名一个音色是会发生的,你要能查出「第二季为什么听起来不一样」,而不是只能凭记忆猜。
    6. 可以预期的追问:如果厂商真的下线了那个音色怎么办?答案是把音色选择也做成 provider 抽象的一部分:档案里存的是角色的音色角色定位,映射到具体厂商音色的表放在适配层,换厂商或补映射时不动档案。

    How to reason about it · think before answering

    1. This looks like a voice question but is really about where state lives. 'Hardcode it in config' is not wrong, but stopping there shows no engineering judgment.
    2. Name the risk first: voice is part of a character's identity, and audiences are about as sensitive to it as to a face. Inconsistency across episodes has three usual causes — running each episode as an independent pipeline, picking voices from an ad-hoc or random mapping, and someone tweaking a character's global parameters while fixing the delivery of one line.
    3. The fix is to file the voice in the character record rather than in code: the record carries a voice id, and the dubbing step only reads it. Consistency then holds regardless of episode, run or operator — the same pattern as pinning appearance to a base reference image.
    4. Storing the voice id alone is not enough. Perceived sameness also depends on the baseline emotion and the speaking rate; the same voice at two different rates sounds like a different state of a person. Keep all three in the record, and allow per-line overrides of emotion only, never of rate.
    5. Add a defensive layer: record the voice id together with the model name in the artifact metadata. Vendors do retire and rename voices, and you want to be able to answer 'why does season two sound different' from data rather than memory.
    6. Expect the follow-up: what if the vendor retires that voice? Make voice selection part of the provider abstraction — the record stores the character's voice archetype, and the mapping to a concrete vendor voice lives in the adapter, so swapping vendors never touches the character records.

    答题要点

    • 把音色存进角色档案,配音环节只读不写,一致性与集数、运行次数、操作人无关
    • 档案里要同时存音色标识、基调情绪与语速;单条台词只允许覆盖情绪,不允许覆盖语速
    • 把音色标识与模型名一起写进产物元数据,便于回答「为什么这一季听起来不一样」
    • 跨集不一致的典型成因是每集独立跑、临时映射、以及改一句台词时顺手改了全局参数
    • 音色选择应纳入 provider 抽象:档案存角色的音色定位,具体厂商音色的映射放在适配层

    Key points

    • Store the voice in the character record and have the dubbing step read it only, so consistency is independent of episode, run or operator
    • Keep voice id, baseline emotion and speaking rate together; allow per-line emotion overrides but never rate overrides
    • Write the voice id and model name into artifact metadata so you can explain why a later season sounds different
    • Typical causes of drift are per-episode independent runs, ad-hoc mappings, and global tweaks made while fixing one line
    • Fold voice selection into the provider abstraction: records hold the archetype, the adapter maps it to a concrete vendor voice