逐日AI

面试题库

共 328 题,当前筛选 2 题。

标签
还有 126 个标签
#agent-loop2#api-design2#chunking2#cost-tradeoff2#debugging2#distributed-systems2#error-handling2#hybrid-search2#llm-as-judge2#multi-agent2#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#cost-control1#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

14 天 RAG:从检索到可信回答

D11 高级索引:父子文档、摘要索引、上下文检索,以及树状聚合与图检索的取舍

  • 什么样的问题必须上图检索?给一个该上的具体例子和一个不该上的例子。What kind of question actually requires graph retrieval? Give one concrete case where it is justified and one where it is not.
    国内高频海外高频深入#graph-rag#multi-hop#cost

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

    1. 这题在考你会不会为了用而用。只要答案里出现『多跳问题就要上图检索』,面试官基本就知道你没落地过——多跳只是必要条件,远不是充分条件。
    2. 判据要落在一个可观察的现象上:**答案的第二篇文档和查询之间,有没有字面或语义上的重合**。有重合,普通的混合检索就能捞到它,多跳是假的;完全没有重合,只能靠一条关系边走过去,这才是图检索的领地。
    3. 该上的例子:问『生产库主备切换必须谁书面审批、这个人叫什么』。一篇写着须平台组组长审批,另一篇写着平台组组长是某人。第二篇跟查询一个词都不重合,我们在五种索引结构下测了一遍,它在 20 条候选池里一次都没出现过——换切法、加块头、父子回填全都无效。
    4. 不该上的例子:问『扩容要走哪个流程、最晚提前几个工作日提单』。同样跨两篇文档,但两篇都跟查询有明显字面重合,混合检索把它们分别排在第 2 名,一次检索就凑齐了。为它建图是拿几倍成本买一个已经解决的问题。
    5. 然后说代价,这一段决定了你像不像做过:建图不止一次抽取调用,实体要消歧、关系要去重、文档更新时受影响的子图要重算,还要多维护一套图存储和一套更新链路。
    6. 可预期的追问是『不上图检索还有什么办法』。答案是把多跳交给 Agentic 检索:让模型先查出中间实体,再拿这个实体发起第二次检索。它的一次性成本几乎为零,代价换成了每次查询的延迟与调用次数——先试这条,试不通再考虑建图。

    How to reason about it · think before answering

    1. This one tests whether you reach for tools you don't need. If the answer is 'multi-hop questions need a graph', the interviewer knows you haven't shipped one — multi-hop is necessary, nowhere near sufficient.
    2. Anchor the criterion on something observable: does the second required document share any lexical or semantic overlap with the query? If it does, ordinary hybrid retrieval will surface it and the hop is illusory. If it shares nothing, only a relation edge gets you there — that is graph territory.
    3. Justified case: 'who must sign off on a production failover, and what is that person's name?' One doc says the platform lead must approve; another says who the platform lead is. The second shares not one term with the query. Across all five index structures we tested, it never once appeared in a 20-item candidate pool — rechunking, headers and parent backfill all failed.
    4. Unjustified case: 'which process covers a capacity change, and how many working days ahead must the ticket be filed?' Also two documents, but both overlap the query lexically; hybrid retrieval ranked them second each, and one pass collected both. Building a graph for this buys a solved problem at several times the cost.
    5. Then state the cost, which is what makes the answer sound operational: graph building is not one extraction call. Entities need disambiguation, relations need dedup, updates force recomputing affected subgraphs, and you now run a graph store and its update pipeline.
    6. Expect 'what else could you do instead'. Hand multi-hop to agentic retrieval: let the model retrieve the intermediate entity first, then issue a second query with it. Near-zero build cost, paid back in latency and call count per query. Try that before you build a graph.

    答题要点

    • 判据不是『是不是多跳』,而是『第二篇文档跟查询有没有字面或语义重合』——没有重合才轮得到图检索。
    • 该上:审批人那类问题,中间实体是唯一的桥,第二篇文档在候选池里一次都不出现。
    • 不该上:两篇都跟查询有重合的多跳题,混合检索一次就能凑齐。
    • 建图的真实成本是实体消歧、关系去重、增量重算和一套额外的图存储,不是一次抽取调用。
    • 先试 Agentic 检索的两次查询,走不通再考虑建图。

    Key points

    • The test is not 'is it multi-hop' but 'does the second document overlap the query at all' — only zero overlap earns a graph.
    • Justified: the approver question, where an intermediate entity is the only bridge and the second doc never enters the candidate pool.
    • Not justified: a multi-hop question whose documents both overlap the query — hybrid retrieval collects them in one pass.
    • Real graph cost is entity disambiguation, relation dedup, incremental subgraph recomputation and a whole extra store — not a single extraction call.
    • Try two-pass agentic retrieval first; build the graph only when that fails.

D12 Agentic RAG:把检索做成工具,让模型自己决定查不查、查几次、要不要推翻重来

  • 多跳检索里第一跳查错了,后面全跟着错。你会怎么设计容错?In multi-hop retrieval a wrong first hop poisons every hop after it. How would you design for that?
    国内高频海外高频深入#multi-hop#error-propagation#agentic-rag

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

    1. 这题考的是错误传播意识。只答「加个重试」是不够的——重试只在「同一条路走不通」时有用,而多跳的问题是走上了错误的路还越走越远。
    2. 先把两类失败分开,这是整题的骨架:一类是根本没捞到(答案文档在候选池里一次都没出现,放宽门槛毫无用处,只能靠新的查询词重查,也就是多跳),一类是捞到了却被自己的过滤器扔了(排在第二名但没过准入门槛,这一类跳多少跳都没用,只能降级放宽门槛重判)。判据是要素覆盖率加答案槽位:覆盖率低是方向错了走放宽,覆盖率高但槽位空是只查到半路走多跳。判错类型,容错就完全用反了。
    3. 然后给具体机制。判断下一跳查什么,不能凭模型自由发挥,要有可解释的判据:从最贴题的那一句里挑出问题没提过、且在别的文档里也出现过的具体名词当作桥接短语。「问题没提过」保证它是新信息,「别的文档里也有」保证真的有下一跳可跳——只在这一篇里出现的短语,查了只会把同一篇再捞回来。
    4. 结论层面,容错有三层:不要丢掉上一跳的材料(第二跳查错了,第一跳的证据还在);每一跳独立记录轨迹,事后能定位是哪一跳歪的;追不动时主动认输,把「材料不足」交给生成侧的拒答,而不是硬凑一个答案。
    5. 有一个非常容易被忽略的坑,说出来会加分:跳成功了,命中却没变。第二跳确实把目标文档检索回来了,但如果把两跳的候选混在一起按名次装上下文,第一跳的材料字面重合度更高,会把预算占满,目标文档根本挤不进去。上下文预算必须按跳轮转分配——多跳的收益是在这一步兑现的,不是在检索那一步。
    6. 可预期的追问是「怎么知道第一跳错了」。答案是靠自评的结构化输出,而不是靠最终答案对不对;等到答案错了再回头找,链路已经断了三跳,定位成本高得多。

    How to reason about it · think before answering

    1. This is about error propagation. 'Add a retry' is not enough - retries help when one path fails, but the multi-hop problem is walking confidently down the wrong path.
    2. Separate two failure kinds first, because the fixes are opposite. Either the answer document never entered the candidate pool - no amount of loosening helps, only a new query term does, which is the multi-hop path - or it was retrieved and then dropped by your own admission threshold, where extra hops are useless and only relaxing the gate recovers it. Coverage plus the answer slot tells them apart: low coverage means wrong direction (broaden), high coverage with an empty slot means halfway there (hop).
    3. Then give the mechanism. Do not let the model freestyle the next query: pick a bridge phrase from the sentence that best matches the question - a concrete noun the question never mentioned that also appears in another document. 'Not in the question' makes it new information; 'appears elsewhere' guarantees there is somewhere to hop to.
    4. Fault tolerance has three layers: keep the earlier hop's material, so a bad second hop does not destroy the evidence you already had; trace each hop separately so you can locate where it went wrong; and surrender explicitly when there is no lead left, handing 'insufficient evidence' to the generation-side refusal.
    5. The overlooked trap is worth points: the hop succeeds but the metric does not move. The second hop really did retrieve the target document, yet if you merge both hops' candidates and pack by score, the first hop's higher lexical overlap fills the budget and the target never enters the context. Allocate the context budget round-robin across hops - that is where multi-hop gains are actually realized.
    6. Expected follow-up: how do you know the first hop was wrong? From the structured self-assessment, not from the final answer. By the time the answer is wrong the chain is three hops deep and much more expensive to debug.

    答题要点

    • 先分类:根本没捞到只能靠多跳换查询词,捞到了被门槛扔了只能靠降级放宽,两者修法相反。
    • 下一跳的查询用桥接短语:问题没提过、且别的文档里也出现过的具体名词。
    • 保留上一跳的材料,第二跳失败时第一跳的证据仍在。
    • 每一跳独立记轨迹,能定位是哪一跳歪的。
    • 上下文预算按跳轮转分配,否则跳成功了命中也不会变。
    • 追不动时主动认输,把材料不足交给生成侧拒答,不硬凑答案。

    Key points

    • Classify first: never retrieved needs a new query term (a hop); retrieved-then-filtered needs a relaxed gate. The fixes are opposite.
    • Derive the next query from a bridge phrase - a concrete noun absent from the question that also appears in another document.
    • Keep the previous hop's material so a failed hop does not discard existing evidence.
    • Trace every hop separately so you can pinpoint which one drifted.
    • Allocate context budget round-robin across hops, or a successful hop still fails to change the metric.
    • Surrender explicitly when no lead remains and hand it to the generation-side refusal.