逐日AI

面试题库

共 328 题,当前筛选 1 题。

标签
还有 136 个标签
#api-design6#operations6#sse6#deployment5#message-bus5#tool-calling5#agent-loop4#behavioral4#error-handling4#evaluation4#framework-design4#mcp4#routing4#concurrency3#context-engineering3#interview-prep3#langgraph3#llm-basics3#model-routing3#orchestration3#prompt-injection3#protocol3#redis-streams3#scalability3#scheduling3#agent-design2#auth2#checkpointing2#communication2#cost-control2#database2#debugging2#interview-process2#latency2#long-term-memory2#memory2#ordering2#prompt-engineering2#rate-limiting2#react2#resume2#retrieval2#sharding2#state-machine2#state-management2#tool-design2#tool-permissions2#trade-offs2#ux2#agent-basics1#agent-quality1#async1#atomicity1#cancellation1#capacity-planning1#career1#compression1#configuration1#consistent-hashing1#context1#context-compression1#context-management1#correctness1#customer-support1#data-modeling1#deliberate-practice1#docker1#documentation1#engineering-tradeoffs1#escalation1#event-driven1#fallback1#fan-out1#fencing-token1#forking1#framework-selection1#frontend1#global-market1#hybrid-search1#interrupt-merge1#isolation1#json-parsing1#jwt1#knowledge-organization1#lease1#least-privilege1#llm-as-judge1#loop-guard1#mobile1#multi-tenancy1#nodejs1#performance1#persistence1#pgvector1#portfolio1#prioritization1#proactive-messaging1#product-engineering1#project-storytelling1#prompt1#provider-abstraction1#quiet-hours1#ranking1#recall1#reconnect1#redis1#reflection1#replay1#reporting1#rerank1#retrieval-quality1#retry1#retry-semantics1#rrf1#sampling1#sandboxing1#schema-design1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#service-architecture1#session-management1#split-brain1#star1#stateless1#storytelling1#structured-output1#system-prompt1#testing1#timezone1#tool-execution1#tools1#tracing1#transport1#vector-database1

30 天从前端工程师到 Agent 工程师

D12 长期记忆:pgvector、embedding、chunking、memory_search 工具

  • chunking 的切分策略会怎么影响检索效果?切多大合适?How does the chunking strategy affect retrieval quality, and how do you pick a chunk size?
    国内高频海外高频进阶#chunking#rag#retrieval-quality

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

    1. 题眼在「怎么影响」。只回答一个数字(比如「切 500 字」)会被追着问为什么,所以要先把两个方向的失效模式讲出来,数字才有落点。
    2. 切太碎的失效模式:单张卡片脱离上下文。「他说要 42 码」检索命中了也没用,代词失去指代,模型拿到一句悬空的话反而更容易编。
    3. 切太整的失效模式更反直觉,也是这题真正的区分点:一块横跨三个主题时,它的向量是这几个主题的平均值,结果对哪个 query 都不太像,命中率反而下降。**块越大信息越全,却越难被检索到**——能说出这句话基本就过了。
    4. 然后给可操作的口径:目标 400 字符、相邻块重叠 80 字符,并优先在句号、换行这类自然边界收尾。重叠的作用要说清楚——一句关键的话被切口劈开时,两块各拿半句,重叠保证它至少在其中一块里是完整的。
    5. 补上代价,这是工程视角:重叠 80 除以 400 等于 20% 的存储放大,向量也跟着多一份;内容高度重叠的两块可能一起被检索出来,白占返回名额,所以要按内容去重。
    6. 可以预期的追问:怎么验证切分策略好不好?答案是准备一批 query 与标注好的期望命中,量召回率和 top-k 命中率,改切分参数后重跑对比——切分是可以被度量的,不该靠感觉调。第二个追问是「对话数据要不要原样切」,答不要:先让模型抽成陈述句再切,否则大量寒暄句会把向量拉平。

    How to reason about it · think before answering

    1. The hinge is 'how does it affect'. Naming a number alone invites a why, so describe both failure modes first and let the number follow.
    2. Too small: a chunk loses its context. 'He wants size 42' retrieves fine but resolves to nothing — pronouns dangle and the model is more likely to fabricate.
    3. Too large is the counter-intuitive half and the real discriminator: a chunk spanning three topics gets a vector that averages them, so it looks only vaguely like any query and recall drops. Bigger chunks carry more information yet are harder to retrieve.
    4. Give an operational default: target 400 characters with 80 characters of overlap, ending on natural boundaries such as sentence stops or newlines. Explain the overlap — when a key sentence lands on a cut, each side holds half of it, and the overlap guarantees at least one chunk holds it whole.
    5. Add the costs: 80 over 400 is 20% storage amplification plus an extra vector per duplicated span, and near-duplicate chunks can both surface and waste result slots, so deduplicate by content before returning.
    6. Expect: how do you validate a chunking strategy? Build a query set with labelled expected hits and measure recall and top-k hit rate, then re-run after changing parameters — chunking is measurable, not a matter of taste. Second follow-up: should raw dialogue be chunked as-is? No — have the model distil it into standalone statements first, or filler turns flatten the vectors.

    答题要点

    • 切太碎:单块脱离上下文,代词失去指代,命中了也用不上
    • 切太整:一块横跨多个主题,向量被平均,对任何 query 都不够像,命中率反而下降
    • 可操作口径:目标 400 字符、重叠 80 字符,优先在句号或换行这类自然边界收尾
    • 重叠的作用是保证被切口劈开的句子至少在一块里完整;代价是约 20% 的存储放大和可能的重复命中
    • 别直接切对话原文,先抽成陈述句;切分效果要用标注好的 query 集测召回率,而不是凭感觉

    Key points

    • Too small: chunks lose context, pronouns dangle, and a hit is useless
    • Too large: one chunk spans several topics, its vector averages them, and recall drops for every query
    • Working default: target 400 characters with 80 characters of overlap, cutting on sentence or newline boundaries
    • Overlap keeps a split sentence whole in at least one chunk, at roughly 20% storage amplification plus possible duplicate hits
    • Distil dialogue into standalone statements before chunking, and validate with a labelled query set measuring recall