逐日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#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#prompt-techniques2#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 天上下文工程

D4 长时程会话:压缩、笔记与记忆文件、子代理隔离与交接摘要

  • 什么时候该压缩上下文,什么时候该直接换一个更大的窗口?When should you compact the context, and when should you just move to a larger context window?
    国内高频海外高频进阶#compaction#context-rot

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

    1. 这题在考你有没有把窗口当容量、把注意力当预算。只回答「窗口不够就压缩」的人漏掉了一半——很多时候窗口还很空,但已经该压了。
    2. 怎么拆:先把两个问题分开。窗口不够是容量问题,换大窗口确实能解决;但换大窗口解决不了上下文腐烂——上下文越长模型准确回忆的能力越差,这是一条缓坡,标称窗口大不等于在那个长度上表现稳定。所以「装得下」和「用得好」是两件事。
    3. 给判据:看两个指标而不是一个。窗口占用率高就该压(容量问题);占用率不高但有效信息占比很低,也该压(注意力问题)——后者最容易被忽略,因为看起来毫无压力。
    4. 再给顺序上的结论:压缩不是第一手段。先清掉旧的工具结果(不用调模型、确定、可逆),不够再摘要历史。反过来做的人很多,因为摘要听起来更高级,但摘要要多花一次调用、要承担丢信息的风险,而它治的往往不是大头。
    5. 可预期的追问:那什么时候压缩也不够?当状态是渐进积累的账本而不是可总结的结论时——比如精确计数、地图、长期计划。这类东西要写到窗口外面的文件里,不能靠摘要保住。

    How to reason about it · think before answering

    1. This checks whether you treat the window as capacity and attention as a budget. Answering only that you compact when it does not fit misses half the cases, since plenty of sessions should be compacted while the window is still mostly empty.
    2. Separate the two problems. Not fitting is capacity, and a bigger window fixes it. But a bigger window does not fix context rot: recall degrades as context grows, on a gradient, so a large nominal window is not a promise of stable behavior at that length. Fitting and being used well are different.
    3. Give the test: watch two signals, not one. High window occupancy means compact for capacity. Low occupancy with a low share of actually-useful tokens also means compact, for attention. The second is the one people miss because nothing looks urgent.
    4. Then order the tactics. Compaction is not the first move. Clear stale tool results first, since that needs no model call, is deterministic, and is reversible. Only then summarize history. Doing it the other way costs an extra call and risks losing information while usually treating the smaller bucket.
    5. Expect the follow-up: when is compaction itself not enough? When the state is an accumulating ledger rather than a summarizable conclusion, such as exact tallies, maps, or a long-term plan. Those belong in files outside the window.

    答题要点

    • 窗口不够是容量问题,换大窗口能解决;上下文腐烂是注意力问题,换大窗口解决不了。
    • 两个触发信号:窗口占用率高,或占用率不高但有效信息占比很低。
    • 顺序上先清旧工具结果(不调模型、确定、可逆),不够再摘要历史。
    • 如果状态是渐进积累的账本(计数、地图、长期计划),压缩救不了,要写到窗口外的文件里。

    Key points

    • Not fitting is capacity and a larger window solves it; context rot is attention and a larger window does not.
    • Two triggers: high window occupancy, or low occupancy with a low share of useful tokens.
    • Clear stale tool results first (no model call, deterministic, reversible), then summarize history.
    • If the state is an accumulating ledger such as tallies, maps, or a plan, use external files instead of compaction.
  • 压缩最容易丢什么?你怎么验证一次压缩没有丢掉关键信息?What does compaction lose most easily, and how do you verify that a given compaction kept what mattered?
    国内高频海外高频深入#compaction#verification

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

    1. 这题的区分度全在后半句。谈「要保留重要信息」是空话,面试官想听的是一个可执行的验证机制,以及你有没有真的被它拦下来过。
    2. 怎么拆:先说清压缩为什么比裁剪危险。裁剪动结构,删掉一个字段你知道删了什么、也能取回来;压缩动语言,丢掉了什么是模型决定的,而且丢完不留任何标识。
    3. 点出最脆弱的两类内容:一是最近几轮正在进行的事,一折叠就失去指代对象,模型下一句就会问你说的是哪一单;二是形式上不像结论的硬性要求,比如用户提出的时间点、情绪化诉求、口头承诺——它们在语言上不重要,在业务上是全部。还有一类是标识符,摘要很容易把订单号写成「相关订单」。
    4. 结论给验证机制:预置一组「压缩后必须还能找到」的关键事实,每次压完逐条核对,不通过就拒绝这次压缩或调大保留轮数。三条配套措施是:保留最近若干轮原文、在摘要提示词里让硬性要求单独成段、明确要求逐字保留标识符。
    5. 可预期的追问:你被这个检查拦下来过吗?给一个具体例子最有力,比如把保留轮数从 6 调到 1 时压缩率从 68% 涨到 87%,但「用户要求周五 18:00 前答复」这条直接消失——因为它只活在最近几轮原文里,而且它不像一条结论。

    How to reason about it · think before answering

    1. The signal is entirely in the second half. Saying you keep the important parts is empty; interviewers want an executable verification step and evidence it has actually caught something.
    2. Explain why compaction is riskier than trimming. Trimming changes structure: you know which field you removed and you can fetch it back. Compaction changes language: what got dropped is the model's choice, and nothing marks the loss.
    3. Name the fragile categories. First, whatever is currently in flight in the last few turns, which loses its referent the moment it is folded. Second, hard requirements that do not look like conclusions, such as user-stated deadlines, emotional demands, or verbal commitments. Third, identifiers, which summaries happily rewrite from an order number into the relevant order.
    4. Conclusion: preset a list of facts that must remain findable after compaction and check them every time, rejecting the compaction or widening the verbatim window on failure. Support it with three measures: keep recent turns verbatim, give hard requirements their own section in the summary prompt, and demand verbatim preservation of identifiers.
    5. Expect the follow-up asking whether it ever caught you. A concrete case lands best: dropping the verbatim window from six turns to one raised the compression ratio from 68 to 87 percent but silently deleted a user's stated Friday deadline, because it lived only in recent turns and did not read like a conclusion.

    答题要点

    • 压缩比裁剪危险:裁剪动结构可回溯,压缩动语言且丢失无标识。
    • 最容易丢的三类:最近几轮正在进行的事、不像结论的硬性要求、标识符。
    • 验证机制:预置一组必须存活的关键事实,每次压完逐条核对,不通过就不采纳这次压缩。
    • 配套三招:保留最近若干轮原文、硬性要求在摘要里单独成段、要求逐字保留标识符。

    Key points

    • Compaction is riskier than trimming: structure is recoverable, language loss is silent.
    • Three fragile categories: what is in flight in recent turns, hard requirements that do not look like conclusions, and identifiers.
    • Verification: preset facts that must survive and check each one after every compaction, rejecting it on failure.
    • Support with a verbatim recent window, a dedicated section for hard requirements, and explicit verbatim preservation of identifiers.