逐日AI

面试题库

共 328 题,当前筛选 2 题。

标签
还有 361 个标签
#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#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#llm-basics2#long-term-memory2#media-pipeline2#memory2#multi-hop2#multi-tenancy2#oauth2#prioritization2#project-storytelling2#query-rewriting2#react2#refusal2#reproducibility2#rerank2#retrieval-quality2#retrospective2#scripts2#sharding2#state-machine2#tool-permissions2#tooling2#tools2#tracing2#transport2#tts2#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#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

5 天提示词工程零基础

D2 few-shot、思维链、分步与自检;什么时候这些都不管用

  • few-shot 为什么有效?示例给多了会出什么问题?你怎么决定给几个?Why does few-shot prompting work, what goes wrong when you give too many examples, and how do you decide how many to include?
    国内高频海外高频基础#few-shot#prompt-techniques

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

    1. 这题在筛「有没有把示例当成格式与边界的信号,而不是当成让模型变聪明的魔法」。答成「示例越多模型越懂」会暴露没在生产里调过提示词。
    2. 拆法:先答原理——模型在补全,示例直接展示了「下文该长什么样」,比文字描述格式和边界规则更不容易被误读;示例是最强的格式信号。
    3. 再答代价:每个示例都占上下文与费用;示例过多会让模型过拟合示例的表面特征(长度、措辞、顺序),还会把示例里无意带进去的偏见放大,比如四个示例里三个是 bug,它就更倾向判 bug。
    4. 结论:数量由「要覆盖几种类型」决定而不是越多越好,通常两到五个,每个覆盖一种不同的情况,并且至少一个是边界样本。
    5. 可预期的追问:示例的顺序有影响吗?有,多数模型对最后一个示例更敏感,所以把最像目标输入的放最后;另一个追问是示例和说明冲突时模型听谁的,答案是多半听示例,所以示例必须与格式栏逐字一致。

    How to reason about it · think before answering

    1. The screen is whether you treat examples as signals for format and boundaries rather than as magic that makes the model smarter. 'More examples, better model' reads as untested.
    2. Mechanism first: the model completes text, and examples show the continuation directly, which is harder to misread than prose describing a format or an edge rule. Examples are the strongest format signal.
    3. Then the cost: each example consumes context and money; too many cause overfitting to surface features such as length, wording and order, and amplify accidental bias — three bug examples out of four nudges everything toward bug.
    4. Conclusion: the count follows the number of distinct cases you need to cover, typically two to five, each a different case, with at least one boundary sample.
    5. Follow-ups: does order matter? Yes, models weight the last example more, so place the one closest to the target input last. And if examples contradict the instructions, the model usually follows the examples, so they must match the format spec exactly.

    答题要点

    • 示例直接展示下文该长什么样,比文字描述格式和边界规则更不容易被误读
    • 示例过多的代价:占上下文与费用、过拟合表面特征、放大示例里的类别偏见
    • 数量按「要覆盖几种不同情况」定,通常两到五个,至少一个边界样本
    • 顺序有影响,最像目标输入的放最后;示例与说明冲突时模型多半听示例

    Key points

    • Examples show the continuation directly, which beats prose for conveying format and edge rules
    • Too many examples cost context and money, overfit surface features, and amplify class bias
    • Pick the count by how many distinct cases need coverage, typically two to five with one boundary case
    • Order matters — put the closest match last; when examples and instructions conflict the model follows the examples
  • 思维链在什么任务上提升明显,在什么任务上是浪费?它和「分步」有什么区别?Where does chain-of-thought prompting help most, where is it a waste, and how does it differ from splitting a task into steps?
    国内高频海外高频进阶#chain-of-thought#prompt-techniques

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

    1. 题眼在「浪费」和「区别」。只会说「让模型先思考再回答效果更好」的候选人没有算过账,面试官想听的是你什么时候会主动不用它。
    2. 拆法:思维链的价值来自「中间结果可以校验下一步」,所以它在多步推理、算术、需要排除干扰项的判断上提升明显;在单步判断(分类、抽取、格式转换)上几乎没有增益,只有更慢更贵更长的输出。
    3. 区别:思维链是一次调用内让模型写出中间过程,输出预算还是同一份;分步是拆成多次调用,每步有独立的预算、独立的格式、并且后一步可以拿前一步的输出做输入。任务是「想得不够细」用思维链,任务是「一次装不下」用分步。
    4. 结论:先问任务是否需要多步推理,不需要就不用;需要的话再问一次输出装不装得下,装得下用思维链,装不下拆步。
    5. 追问:推理类模型内置了思考过程,还要写思维链吗?多数情况不用再写「一步步想」,但仍要指定最终答案的格式与位置,否则解析会很痛苦;另一个追问是思维链的内容能不能信,答案是它是「看起来合理的过程」而非真实的内部计算,只能当辅助校验不能当证据。

    How to reason about it · think before answering

    1. The discriminators are 'waste' and 'difference'. Anyone can say thinking first helps; the interviewer wants to hear when you deliberately skip it.
    2. Its value comes from intermediate results checking the next step, so it shines on multi-step reasoning, arithmetic and judgments with distractors; on single-step tasks such as classification, extraction or format conversion it adds latency, cost and length with little gain.
    3. Difference: chain-of-thought keeps everything in one call and one output budget; splitting uses several calls, each with its own budget and format, and later steps can consume earlier outputs. Use CoT when the model thinks too shallowly, split when one answer cannot hold the work.
    4. Conclusion: ask whether the task needs multi-step reasoning at all; if yes, ask whether one output can hold it — CoT if so, split if not.
    5. Follow-ups: with reasoning models that think internally, do you still write 'think step by step'? Usually no, but you still pin the answer format and position. And can you trust the written reasoning? It is a plausible narrative, not the actual computation — use it as a check, not as proof.

    答题要点

    • 思维链的价值是中间结果校验下一步,多步推理与算术上提升明显,单步判断上是浪费
    • 代价是更长的输出、更高的延迟与费用,所以不需要推理的任务要主动不用
    • 与分步的区别:思维链是一次调用内写过程,输出预算不变;分步是多次调用,每步独立预算且可传递输出
    • 推理模型内置思考后一般不必再写「一步步想」,但仍要指定答案格式与位置

    Key points

    • CoT helps because intermediate results check the next step; strong on multi-step reasoning and arithmetic, wasted on single-step judgments
    • Cost is longer output, higher latency and spend, so skip it when no reasoning is needed
    • Versus splitting: CoT stays in one call with one budget; splitting uses multiple calls with independent budgets that can chain outputs
    • With reasoning models you rarely need 'think step by step' but still pin the answer format and location