面试题库
共 328 题,当前筛选 1 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#trade-offs1#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#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#vector-database1#vector-index1#zero-downtime1
14 天 RAG:从检索到可信回答
D5 向量索引与库选型:HNSW 与倒排文件、量化省内存、带过滤的查询与多租户隔离
什么时候应该把向量搬出 PostgreSQL?给出可量化的触发条件,也说说不该搬的理由。When should you move your vectors out of PostgreSQL into a dedicated vector database? Give measurable triggers, and also make the case for staying.
国内高频海外高频进阶#vector-database#architecture#trade-offs分析过程 · 先想清楚再作答
- 这题考的是工程判断,不是技术偏好。开口就说「专用向量库更专业」的人会被追问到答不上来;面试官想看的是你有没有把迁移成本算进去。
- 先给默认立场并给出理由:第一版留在 PostgreSQL,因为事务、备份、时间点恢复、权限、跟业务表 JOIN 和现成的运维工具全是白送的。多一个数据库就多一份同步、一份一致性问题、一份值班负担,这些成本很少被写进选型文档。
- 然后给四条可量化的触发线:数据量(判据不是行数而是索引还塞不塞得进内存)、写入频率(分钟级流式更新会让聚类失真、让图持续膨胀)、过滤复杂度(十几个属性的任意组合让部分索引和分区都排列组合不过来)、团队运维能力(没人愿意长期照看第二个数据库,前三条再成立也别搬)。
- 第三条要展开一点,因为它最常是真正的原因:专用向量库把过滤做进了索引结构本身,而不是扫完索引再筛,所以在复杂过滤下天然占优。把这一点说出来,说明你理解的是机制而不是口碑。
- 还要主动给一条常被忽略的替代路径:很多「向量检索不够用」的问题,真正的解法是混合检索加重排,而不是换数据库。先把关键词一路加回来、把重排接上,再决定要不要搬——顺序搞反了会白搬一次。
- 可预期的追问:真要搬怎么迁?答分三步——先双写并在影子流量上比对两边的召回与延迟,再把读流量按比例切过去,最后才停掉旧路径。中间任何一步指标不达标就停下,这比一次性切换安全得多。
How to reason about it · think before answering
- This tests engineering judgement, not tooling preference. Opening with 'dedicated vector databases are better' invites follow-ups you cannot answer.
- State the default position and justify it: keep the first version in PostgreSQL, because transactions, backups, point-in-time recovery, permissions, joins with business tables and the tooling your team already knows all come free. A second datastore adds synchronisation, a consistency surface and an on-call burden that selection documents rarely price in.
- Then give four measurable triggers: data volume (the test is whether the index still fits in memory, not the raw row count), write frequency (minute-level streaming updates distort clusters and inflate graphs), filter complexity (arbitrary combinations of a dozen attributes defeat both partial indexes and partitioning), and operational capacity.
- Expand on filter complexity, because it is most often the real reason: dedicated vector databases push filtering into the index structure instead of applying it after the scan, which is a mechanical advantage rather than a reputational one.
- Volunteer the alternative people skip: many 'vector search is not good enough' problems are actually solved by hybrid retrieval plus re-ranking, not by a new database. Add the keyword path and a re-ranker first, then decide.
- Expected follow-up: how would you migrate? Dual-write, compare recall and latency on shadow traffic, shift read traffic gradually, and only then retire the old path. Stop at any step where the metrics regress.
答题要点
- 默认留在 PostgreSQL:事务、备份、恢复、权限、JOIN 和现成运维都是白送的,多一个库就多一份同步与值班成本。
- 触发线一是数据量,判据是索引还塞不塞得进内存,而不是行数本身。
- 触发线二是写入频率,分钟级流式更新会让聚类失真、让图持续膨胀。
- 触发线三是过滤复杂度,专用库把过滤做进索引结构,复杂过滤下有机制上的优势。
- 触发线四反过来看:没有长期运维第二个数据库的人手,前三条成立也不该搬;很多问题的真正解法是混合检索加重排。
Key points
- Default to staying in PostgreSQL: transactions, backups, recovery, permissions, joins and familiar tooling are free, and a second store adds sync and on-call cost.
- Trigger one is data volume, measured by whether the index still fits in memory rather than by row count.
- Trigger two is write frequency: minute-level streaming updates distort clusters and inflate graphs.
- Trigger three is filter complexity: dedicated stores push filtering into the index structure, a mechanical advantage under complex predicates.
- Trigger four cuts the other way: without people to run a second database, do not move even if the first three hold. Often hybrid retrieval plus re-ranking is the real fix.