面试题库
共 328 题,当前筛选 1 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#index-routing1#evaluation15#chunking6#cost6#embeddings5#agentic-rag4#architecture4#hybrid-search4#ingestion4#abstention3#data-quality3#access-control2
还有 92 个标签收起标签
#citation-verification2#contextual-retrieval2#cost-tradeoff2#debugging2#failure-modes2#golden-set2#long-context2#multi-hop2#observability2#query-rewriting2#ranking2#recall2#refusal2#retrospective2#system-design2#api-design1#bi-encoder1#bm251#caching1#citations1#content-hash1#context-assembly1#coreference1#cost-optimization1#cross-encoder1#dimensions1#embedding-migration1#engineering-judgement1#error-propagation1#evidence1#failure-analysis1#faithfulness1#fallback1#filter-pushdown1#filtering1#fine-tuning1#graph-rag1#grounding1#hallucination1#hnsw1#hyde1#incremental-sync1#index-maintenance1#indexing1#information-retrieval1#intent-routing1#invalidation1#iterative-scan1#ivfflat1#latency1#latency-budget1#llm-as-judge1#metadata1#model-selection1#modularity1#multi-tenancy1#multi-turn1#normalisation1#ocr1#ordering1#overlap1#parent-child1#pdf-parsing1#prioritization1#production-readiness1#prompt-caching1#prompt-engineering1#prompting1#quantization1#query-transformation1#rag1#rag-basics1#rank-fusion1#reliability1#rerank1#retrieval1#retrieval-failure1#retrieval-metrics1#retrieval-quality1#risk-assessment1#rollout1#scaling1#self-reflection1#similarity1#stakeholder-communication1#streaming1#thresholds1#tool-design1#trade-offs1#vector-database1#vector-index1#zero-downtime1
14 天 RAG:从检索到可信回答
D11 高级索引:父子文档、摘要索引、上下文检索,以及树状聚合与图检索的取舍
同一份语料建了三套索引,检索时你怎么决定走哪一套?You have built three different indexes over the same corpus. How do you decide which one a query goes to?
国内高频海外高频进阶#index-routing#evaluation#architecture分析过程 · 先想清楚再作答
- 这题是送分还是丢分,取决于你有没有先反问一句『真的需要三套吗』。上来就答路由策略的人,默认了一个没被验证的前提。
- 第一步是承认多数情况下答案是『都不走,走默认那套』。我们在 30 篇语料上把五种索引结构各测一遍,**召回率全部停在 93.8%,没有一种跑赢基线**;唯一动了的是 nDCG@10(块头把它从 0.6438 抬到 0.7218),而两段式的摘要索引还掉到了 87.5%。每种结构补的都是一个特定短板,你没有那个短板时它只带来成本。
- 第二步才是路由,而判据不是『哪套准』——那是离线评估该回答的问题,不是运行时能知道的。运行时能拿到的只有**问题的形状**:细节型(答案落在某一段)、概括型(要全库的一个概括)、多跳型(要跨实体串联)。按形状分流,正好对应块级索引、树状聚合索引、图索引。
- 实现上就是一个轻量意图分类器,跟前一天的意图路由是同一套东西,不必再造一个。分类结果作为元数据带进请求,方便事后拿评估集回看分错了多少。
- 兜底策略要说清楚:分类错了**回落到默认那一套**,不要并行全查一遍再融合。并行看着稳,实际上把延迟和成本按索引套数翻倍,而多出来的那两路大概率一条都进不了上下文预算。
- 可预期的追问是『怎么知道分类器分对了』。答案是把路由决策记进日志,定期拿标准答案集回放:对每个问题分别走三套索引,看分类器选的那套是不是指标最好的那套。这是一个能持续跑的离线作业,不需要人工标注。
How to reason about it · think before answering
- Whether this is an easy point or a lost one depends on whether you first ask 'do we actually need three?'. Jumping straight to routing accepts an unverified premise.
- Step one is admitting the answer is usually 'none of them — use the default'. Across 30 documents we measured five index structures and every one landed at 93.8% recall, none beating the baseline. The only metric that moved was nDCG@10, which headers lifted from 0.6438 to 0.7218, while the two-stage summary index fell to 87.5%. Each structure patches one specific weakness; without that weakness it is pure overhead.
- Step two is routing, and the criterion is not 'which index is more accurate' — that is an offline evaluation question, not something you know at request time. What you do have at request time is the shape of the question: detail-seeking, summarizing, or entity-chaining. Those map onto the chunk index, the tree-summary index and the graph index.
- Implementation is a lightweight intent classifier — the same one from the previous day's intent routing, no need to invent another. Carry the decision as request metadata so you can replay it later.
- Spell out the fallback: on a misclassification, fall back to the default index rather than fanning out across all three and fusing. Fan-out looks safe but multiplies latency and cost by the number of indexes, and the extra routes usually never make it into the context budget anyway.
- Expect 'how do you know the classifier is right'. Log every routing decision and replay the golden set periodically: run each question through all three indexes and check whether the classifier picked the best-scoring one. It is a standing offline job that needs no human labelling.
答题要点
- 先反问是否真需要三套:实测五种索引结构召回率全部持平在 93.8%,没有对应短板就是纯成本。
- 运行时的判据是问题的形状——细节型、概括型、多跳型,分别对应块级、树状摘要、图索引。
- 复用前一天的意图路由做分类,把路由决策记进请求元数据。
- 分类错了回落到默认索引,不要并行全查再融合——延迟和成本按套数翻倍。
- 用标准答案集定期回放,检验分类器选的那套是不是指标最好的那套。
Key points
- First challenge the premise: all five index structures landed at the same 93.8% recall in our measurement, so an index without a matching weakness is pure cost.
- At request time the usable signal is question shape — detail, summary, or entity-chaining — mapping to chunk, tree-summary and graph indexes.
- Reuse the previous day's intent router for classification and record the routing decision as request metadata.
- Fall back to the default index on misclassification instead of fanning out and fusing, which multiplies latency and cost.
- Replay the golden set periodically to check whether the classifier picks the best-scoring index.