面试题库
共 328 题,当前筛选 3 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#evaluation15#chunking6#cost6#embeddings5#agentic-rag4#architecture4#hybrid-search4#ingestion4#abstention3#data-quality3#access-control2#citation-verification2
还有 92 个标签收起标签
#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#index-routing1#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:从检索到可信回答
D3 文档进来这一关:PDF 与 HTML 解析、表格与扫描件、清洗规则和必须留下的元数据
一份 PDF 解析出来的文字顺序是乱的,你会怎么排查和修复?The text extracted from a PDF comes out in the wrong order. How do you diagnose and fix it?
国内高频海外高频进阶#pdf-parsing#ingestion#data-quality分析过程 · 先想清楚再作答
- 这题在考你有没有真的动手解析过 PDF。区分度在第一句:能不能说出「PDF 里根本没有阅读顺序」这个前提。答不出这句的人,后面只会说「换个库试试」。
- 先给排查顺序:把抽出来的文本片段连同页码、坐标、字号一起打印出来,别只看拼好的字符串。乱序的原因几乎都藏在坐标里,看纯文本永远看不出来。
- 然后按现象分三类。左右两栏一行一行地交替,是多栏没识别;同一段话被拆成很多短片段且 y 值有回跳,是内容流按绘制顺序写的;文字整体没问题但夹着重复出现的短句,那不是乱序,是页眉页脚没剔。
- 修法对应着来:多栏就重建阅读顺序——把每页文字块的左边界排序找最大空隙当分栏线,再按「栏号、y 从大到小、x 从小到大」重排;页眉页脚按固定的 y 值带切掉,并打印剔除条数确认没误伤。
- 补一条能证明你在生产里干过的话:修完要有可回归的判据,不能靠肉眼。用乱序疑似度——顺着排好的顺序走一遍,统计「同栏内往回跳」和「从右栏跳回左栏」的比例,它不需要标准答案,可以挂进流水线天天跑。
- 可预期的追问:多栏识别错了怎么办?回答分两头——把分栏判定做保守(空隙不够宽、或者一侧内容占比太低就按单栏处理),并且让断言在双栏被误判成单栏时同样会报警,宁可漏修也不要悄悄改错。
How to reason about it · think before answering
- This checks whether you have actually parsed a PDF yourself. The first sentence is the differentiator: a PDF has no reading order at all, only drawing instructions with coordinates.
- Start with the diagnostic step: dump the extracted fragments together with page, x, y and font size instead of looking at the concatenated string. The cause is always in the coordinates.
- Then classify the symptom. Lines alternating between left and right means multi-column layout was not detected. Fragments with y jumping backwards means the content stream was written in drawing order. Clean text sprinkled with a repeated short line is not disorder at all, it is a header or footer that was never stripped.
- Match the fix to the symptom. For columns, rebuild the order: sort the left edges of the fragments on each page, take the widest gap as the column boundary, then sort by column, then y descending, then x ascending. For headers and footers, cut fixed bands at the top and bottom and print how many fragments you dropped so you can confirm you did not cut into the body.
- Add the production-grade part: the fix needs a regression signal, not an eyeball check. Compute an out-of-order score by walking the sorted fragments and counting backward jumps within a column plus right-to-left column jumps. It needs no ground truth, so it can run on every ingest.
- Expected follow-up: what if column detection is wrong? Keep the detector conservative, treating a narrow gap or a lopsided split as single column, and make sure the assertion still fires when a two-column page is misread as one. Missing a fix is better than silently corrupting the order.
答题要点
- 前提先说清:PDF 只存「在某页某坐标画某段文字」,段落和阅读顺序都是解析时推出来的。
- 排查时把片段连同页码、坐标、字号一起打印,纯文本看不出乱序的原因。
- 三种典型成因:多栏没识别、内容流按绘制顺序写、页眉页脚没剔除。
- 多栏的修法是找最大 x 空隙定分栏线,再按「栏号、y 降序、x 升序」重排。
- 修完要有不依赖标准答案的回归指标,比如乱序疑似度,能挂进摄取流水线。
Key points
- State the premise: a PDF stores only drawing instructions, so paragraphs and reading order are inferred, not read.
- Debug by dumping fragments with page, coordinates and font size; plain text hides the cause.
- Three common causes: undetected multi-column layout, content stream written in drawing order, and headers or footers left in.
- Fix columns by finding the widest gap between left edges and sorting by column, then y descending, then x ascending.
- Add a ground-truth-free regression metric such as an out-of-order score so the fix stays fixed.
扫描件走光学字符识别之后错字率不低,这些噪声会怎样影响检索和生成?怎么缓解?OCR output from scanned documents carries a non-trivial error rate. How does that noise propagate into retrieval and generation, and how do you mitigate it?
国内高频海外高频深入#ocr#data-quality#hybrid-search分析过程 · 先想清楚再作答
- 这题考的是你会不会顺着链条推传导,而不是背「OCR 会有错字」这句废话。判据是有没有分别说清「检索侧怎么错」和「生成侧怎么错」——它们的失效方式完全不同。
- 先说检索侧。中文 OCR 的错主要是形近字,「已」认成「己」、「板」认成「版」。关键词检索是字面匹配,一个字错了这个词就查不到;更隐蔽的是二元组分词会连带毁掉相邻两个词元,一个错字影响的其实是两处。这一路的表现是召回悄悄掉下去,而且不报错。
- 再说生成侧。错字进了上下文,模型往往能读懂大意,但一旦是关键实体(人名、型号、金额、日期)出错,它会照着错的答,而且答得很自信。更麻烦的是引用校验也会跟着失效——原文本身就是错的,校验通过了也没意义。
- 缓解按三层说。入口层:先用空文本比例这类断言判断这份 PDF 有没有文本层,有就别走 OCR;真要走,保留原图链接以便人工复核。
- 检索层:靠混合检索兜底,向量一路对个别错字不敏感,能补上关键词一路的失手,这是 D9 那套东西在这里的具体价值。生成层:把低置信度的页面标出来,让模型在引用它们时明确提示「该材料来自扫描件,可能有识别误差」。
- 可预期的追问:能不能自动纠错?可以但要克制——用词典或模型做后处理会修好一批,也会「修」坏一批原本正确的专有名词。稳妥的做法是只对置信度低的片段做纠错,并且保留原文以便回退。
How to reason about it · think before answering
- This tests whether you can trace propagation rather than recite that OCR makes mistakes. The differentiator is separating how retrieval fails from how generation fails, because the two failure modes are entirely different.
- Retrieval first. Chinese OCR errors are mostly visually similar characters. Keyword search is literal, so one wrong character makes the term unmatchable, and bigram tokenisation makes it worse because a single wrong character corrupts two adjacent tokens. Recall drops quietly and nothing raises an error.
- Generation second. The model usually reads through minor noise, but when the corrupted token is a key entity such as a name, a model number, an amount or a date, it answers confidently with the wrong value. Citation checking degrades too: verifying against a source that is itself wrong proves nothing.
- Mitigate in three layers. At ingest, use an empty-text assertion to decide whether the PDF even needs OCR, and keep a link to the original image so a human can verify.
- At retrieval, hybrid search absorbs some of the damage because dense retrieval is less sensitive to a single wrong character than literal matching. At generation, mark low-confidence pages so the answer can state that the source came from a scan and may contain recognition errors.
- Expected follow-up: can you auto-correct? Yes, but carefully. Dictionary or model based post-processing fixes some errors and breaks correct proper nouns. Restrict correction to low-confidence spans and keep the raw text so you can fall back.
答题要点
- 检索侧:形近字让字面匹配直接查不到,二元组分词还会让一个错字毁掉相邻两个词元,表现是召回悄悄下降且不报错。
- 生成侧:模型能读懂大意,但关键实体出错时会自信地答错,引用校验也失去意义。
- 入口层缓解:先判断有没有文本层再决定要不要 OCR,并保留原图链接供人工复核。
- 检索层缓解:混合检索里的向量一路对个别错字不敏感,能兜住关键词一路的失手。
- 生成层缓解:标出低置信度来源,让回答显式提示可能存在识别误差;自动纠错只对低置信片段做并保留原文。
Key points
- Retrieval: visually similar characters break literal matching, and bigram tokenisation lets one bad character corrupt two tokens, so recall drops silently.
- Generation: the model reads through general noise but confidently repeats corrupted entities, and citation verification against a corrupted source proves nothing.
- At ingest: check for a text layer before running OCR at all, and keep the source image for human verification.
- At retrieval: hybrid search helps because dense retrieval tolerates a single wrong character better than literal matching.
- At generation: flag low-confidence sources in the answer, and restrict auto-correction to low-confidence spans while keeping the raw text.
为什么说解析质量决定了检索质量的上限?举一个具体的传导链条。Why is parsing quality the ceiling on retrieval quality? Walk through one concrete chain of propagation.
国内高频海外高频基础#ingestion#data-quality#failure-analysis分析过程 · 先想清楚再作答
- 这是一道送分题,但很多人答成口号。判据只有一个:有没有给出一条能落到具体现象上的链条,而不是重复一遍「垃圾进垃圾出」。
- 先说清位置:解析在切块、建索引、检索、组装、生成这五环之前,是第零环。它的错误会被后面每一环放大,而且后面每一环都无法察觉——它们只是在忠实地处理一段已经错了的文字。
- 给一条具体链条:一张套餐配额表在 PDF 里丢了一列分隔符,抽出来串了行;切块照着错误的边界切,「专业版」和隔壁那一栏的值被切进同一块;索引把错误的词对记进倒排表;用户问「专业版存储配额多少」,这一块分数很高被排到第一;模型只依据给定材料回答,于是给出一个错误但带着正确引用编号的答案。
- 点破最要命的一句:这条链上没有任何一环会报错,回答甚至是带出处的,看起来比平时更可信。所以解析的错误不能靠事后发现,只能靠入口处的断言拦。
- 反过来说明「上限」二字:后面所有优化——向量、混合检索、重排、查询改写——优化的都是「从候选里挑得更准」。材料本身错了,挑得再准也是错的,所以它们的天花板由解析封死。
- 可预期的追问:那怎么证明是解析的锅?答案接回 D1 那条习惯——排查从右往左看,把检索出来的原文打印出来自己读一遍,如果原文本身就是串行的,那就不用再往生成侧查了。
How to reason about it · think before answering
- This is a giveaway question that many people answer with a slogan. The only test is whether you produce a chain that lands on a concrete symptom instead of repeating garbage in, garbage out.
- Place it first: parsing sits before chunking, indexing, retrieval, context assembly and generation. Its errors are amplified by every later stage, and none of those stages can detect the problem because each is faithfully processing text that is already wrong.
- Give the chain: a pricing table in a PDF loses one column separator and comes out with cells shifted. Chunking splits on those wrong boundaries, so a plan name ends up next to the neighbouring column value. The index records the wrong term pairing. A user asks about that plan's storage quota, the corrupted chunk scores highest, and the model, faithfully answering only from the provided material, returns a wrong answer carrying a correct-looking citation.
- Name the nastiest part: nothing on that chain raises an error, and the answer even comes with a source, so it looks more trustworthy than usual. Parsing errors cannot be caught after the fact, only by assertions at ingest.
- Explain the word ceiling: every later optimisation, dense retrieval, hybrid search, reranking, query rewriting, improves how well you pick from the candidates. If the material itself is wrong, picking better still returns something wrong, so parsing caps all of them.
- Expected follow-up: how do you prove parsing is at fault? Reuse the habit from day one. Diagnose right to left and print the retrieved passages verbatim. If the source text is already scrambled, there is no point looking at the generation side.
答题要点
- 解析是五个环节之前的第零环,它的错误会被后面每一环放大,而后面每一环都察觉不到。
- 具体链条:表格串行 → 切块按错误边界切 → 倒排表记进错误词对 → 检索把它排第一 → 模型据此给出带引用的错误答案。
- 最危险的是全程零报错,且答案带着出处,看起来比平时更可信。
- 后面所有优化解决的是「挑得更准」,材料本身错了就都无效,所以上限由解析封死。
- 定位方法是排查从右往左:先把检索到的原文打印出来读一遍,原文错了就不必再查生成侧。
Key points
- Parsing is stage zero, before the five-stage pipeline; its errors are amplified downstream and invisible to every later stage.
- Concrete chain: a shifted table, chunking on wrong boundaries, wrong term pairs in the index, that chunk ranked first, and a wrong answer delivered with a citation.
- The dangerous part is that nothing errors out and the answer carries a source, so it looks more credible than usual.
- Later techniques only improve selection from candidates; if the material is wrong, better selection still returns something wrong.
- Diagnose right to left: print the retrieved passages first, and if the source text is already broken, stop looking at the generation side.