面试题库
共 328 题,当前筛选 2 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#embeddings2#architecture8#cost4#multi-agent4#agent-skills3#context3#evaluation3#llm-basics3#pipeline-design3#security3#system-design3#tool-design3
还有 125 个标签收起标签
#abstention2#agent-loop2#behavioral2#claude-md2#coding-agent2#consistency2#context-engineering2#context-window2#distributed-systems2#framework-design2#interview-prep2#interview-process2#mcp2#memory2#observability2#orchestration2#prompt-engineering2#provider-abstraction2#rag2#resume2#scalability2#scheduling2#skills2#sse2#streaming2#structured-output2#tool-calling2#agent-basics1#agent-design1#agent-sdk1#agentic-rag1#agents-md1#api-design1#async-task1#auth1#backoff1#bi-encoder1#build-vs-buy1#career1#chunking1#communication1#concurrency1#configuration1#consistent-hashing1#content-safety1#context-assembly1#context-management1#coreference1#cost-accounting1#cost-analysis1#cross-encoder1#data-quality1#encoding1#failure-analysis1#fairness1#few-shot1#ffmpeg1#fine-tuning1#frontend1#global-market1#golden-set1#hooks1#human-in-the-loop1#hybrid-search1#image-generation1#ingestion1#json-schema1#jwt1#langgraph1#long-context1#long-term-memory1#maintenance1#mcp-basics1#media-pipeline1#mental-model1#message-bus1#messages-api1#migration1#model-routing1#moderation1#modularity1#multi-turn1#normalisation1#openai1#operations1#ordering1#overlap1#primitives1#prioritization1#priority-queue1#proactive-messaging1#product-engineering1#project-storytelling1#prompt1#prompt-basics1#prompt-bloat1#prompt-design1#prompt-injection1#prompt-surface1#prompt-techniques1#prompting1#protocol1#query-rewriting1#rag-basics1#rate-limiting1#redis-streams1#reliability1#responses-api1#retrieval1#routing1#sampling1#schema-validation1#scripts1#server-design1#sharding1#similarity1#skill-design1#stakeholder-communication1#star1#state-machine1#system-prompt1#test-set1#token-budget1#tts1#workflow-engine1
14 天 RAG:从检索到可信回答
D2 embedding 与向量检索:相似度、维度与模型选型,把文本存进 pgvector
余弦相似度和内积什么时候等价?如果向量没有归一化,用内积排序会出什么问题?When are cosine similarity and inner product equivalent? What goes wrong if you rank by inner product on vectors that are not normalised?
国内高频海外高频基础#embeddings#similarity#normalisation分析过程 · 先想清楚再作答
- 这题是送分题,但区分度藏在后半句。只答「归一化之后两者等价」的人很多,面试官真正想听的是「没归一化会怎么坏」,因为那是线上真的会发生的事。
- 先把定义摆出来:余弦相似度等于内积除以两个向量模长的乘积。模长都是 1 时除数就是 1,所以余弦相似度就是内积——这一句话就是等价的全部理由,不需要额外的假设。
- 再说没归一化的后果:内积里混着「方向有多一致」和「向量有多长」两层信息。文本越长,模型输出的向量模长往往越大,于是排序会系统性地偏向长文档——这跟 BM25 里 b 参数要压的是同一个毛病,只是换了个地方冒出来。
- 点出这类 bug 的性质:它不报错。程序照常跑、结果照常出,只是名次悄悄偏了,你要跑一轮离线评估才可能发现。所以工程上的做法是在 embedding 的出口统一归一化一次,而不是靠每个调用点自觉。
- 补一句欧氏距离:向量都归一化之后,欧氏距离的平方等于 2 减去 2 倍内积,也就是余弦距离的单调函数,三种距离排出来的名次完全一致。这一句能说明你理解的是关系而不是三条并列的规则。
- 可预期的追问:那 pgvector 里该用哪个运算符?答案是既然已经归一化,`<=>`(余弦距离)和 `<#>`(负内积)名次一样,选 `<=>` 的理由是可读性和「就算哪天有人漏了归一化也不至于错」。
How to reason about it · think before answering
- This starts as a giveaway, but the second half is where candidates separate. Many can say 'they are equivalent after normalisation'; few can describe what breaks without it.
- State the definition: cosine similarity is the inner product divided by the product of the two magnitudes. When both magnitudes are 1, the divisor is 1 and cosine reduces to the inner product. That is the whole argument.
- Then the failure mode: an un-normalised inner product mixes 'how aligned' with 'how long'. Longer texts tend to produce larger-magnitude vectors, so ranking drifts systematically toward long documents, the same bias BM25's b parameter exists to counter.
- Stress that this bug is silent. Nothing throws, results still look plausible, and only an offline evaluation reveals the drift. Hence the engineering rule: normalise once at the embedding boundary, never at each call site.
- Add Euclidean distance for completeness: on normalised vectors, squared L2 equals 2 minus twice the inner product, a monotone function of cosine distance, so all three metrics produce the same ranking.
- Expected follow-up: which pgvector operator should you use? Since the vectors are normalised, `<=>` and `<#>` rank identically; prefer `<=>` for readability and because it stays correct if someone later forgets to normalise.
答题要点
- 余弦相似度 = 内积 / 两个模长之积,模长为 1 时除数为 1,两者等价。
- 没归一化时内积混入模长信息,长文档的向量模长普遍更大,排序会系统性偏向长文档。
- 这类错误不报错,只能靠离线评估发现,所以要在 embed 出口统一归一化。
- 归一化之后欧氏距离与余弦距离互为单调函数,三种运算符名次一致。
- pgvector 里对应 `<->`(L2)、`<#>`(负内积)、`<=>`(余弦距离)三个运算符。
Key points
- Cosine equals inner product divided by both magnitudes; with unit magnitudes the divisor is 1, so they coincide.
- Without normalisation the inner product carries magnitude, and longer documents usually have larger magnitudes, biasing the ranking.
- The failure is silent, so normalise once at the embedding boundary and verify with offline evaluation.
- On normalised vectors L2 and cosine are monotonically related, so all operators rank the same.
- In pgvector the operators are `<->` for L2, `<#>` for negative inner product and `<=>` for cosine distance.
D7 第一周综合:把六天的零件装成一个可一键启动的检索问答服务并复盘
你会怎么划分一个检索增强生成系统的模块边界?其中哪一层最应该做成可替换的,为什么?How would you draw the module boundaries of a RAG system, and which layer most needs to be swappable? Why?
国内高频海外高频基础#architecture#modularity#embeddings分析过程 · 先想清楚再作答
- 这题考的是你有没有真的维护过这类系统。只按「解析、切块、检索、生成」复述一遍流程图,面试官会判定你只搭过 demo——流程图人人都会画,切口画在哪才是经验。
- 给一条可复用的判据再往下推:切口应该落在「将来最可能被整个换掉」的地方,而不是按代码量或者功能名称均分。
- 用它过一遍:embedding 一年会换好几次,换一次库里所有向量作废、必须全量重算,所以它必须是接口;存储可能从 PostgreSQL 换成专用向量库,而且摄取和查询都要通过它,所以它是两条链路的唯一交界;切块策略在调优期天天改,所以它必须是配置项而不是硬编码。
- 结论:最该做成可替换的是 embedding 那一层,理由不是「设计模式」,而是「换模型这件事真的会发生,且发生时代价极高」。
- 顺手点出抽象的代价:每多一层间接就多一次跳转和一份心智负担,所以判据是「那件事会不会真的发生」,不会发生的别抽象。
- 可预期的追问:那生成模型要不要也抽象?答案是要,但优先级低——换生成模型不需要重算任何存量数据,回滚也便宜,所以它是配置项而不是一层接口。
How to reason about it · think before answering
- This question separates people who have maintained such a system from people who have only built a demo. Reciting the pipeline diagram is not an answer; where you cut it is.
- Offer a reusable criterion first: cut where a layer is most likely to be replaced wholesale, not by lines of code or by tidy functional names.
- Apply it. Embedding models change several times a year, and each change invalidates every stored vector, so that layer must be an interface. Storage may move from PostgreSQL to a dedicated vector database, and both ingestion and query talk through it, so it is the single shared boundary. Chunking changes daily during tuning, so it belongs in config, not in code.
- Conclusion: the embedding layer is the one that must be swappable, because the swap is both likely and expensive, not because interfaces are good style.
- Name the cost of abstraction too: every indirection is one more hop while debugging, so the test is whether the change will actually happen.
- Expected follow-up: should the generation model be abstracted as well? Yes, but at lower priority, because swapping it does not force recomputation of stored data and rollback is cheap. It is a config value, not a layer.
答题要点
- 先给判据:切口落在最可能被整体替换的那一层,不按代码量或功能名称均分。
- embedding 是最该抽象的一层:换模型意味着存量向量全部作废、必须全量重算,代价高且真的会发生。
- 存储层是摄取与查询唯一的交界,接口要先定下来再谈两边实现。
- 切块与检索路数做成配置项,因为它们在调优期改动最频繁,改一次不该动代码。
- 抽象有成本,判据是那件事会不会真的发生;不会发生的抽象就是过度设计。
Key points
- Lead with the criterion: cut where a layer is most likely to be replaced wholesale.
- The embedding layer is the one to abstract: swapping models invalidates every stored vector and forces a full recompute.
- Storage is the single boundary shared by ingestion and query, so define its interface before either implementation.
- Chunking and retrieval routes belong in configuration because they change most often during tuning.
- Abstraction costs indirection, so only abstract changes that will actually happen.