公司岗位题库

快手 后端开发面经

32 道题 30 个标签 34 条出现记录

后端开发工程师相关题目

RAG 为什么要引入父子索引,如何兼顾小粒度召回和大粒度上下文回填?

这题考的是 RAG 检索粒度设计:小 chunk 更容易被向量或关键词召回命中,但单独放进上下文时可能缺少标题、章节、定义、前提和表格上下文;父子索引用子块做高精度召回,用父文档或父章节做证据回填,从而兼顾召回命中率、答案可读性和上下文预算。

RAG 检索中为什么要混合 BM25 和向量召回,融合权重或比例如何设置和评估?

这题考 sparse+dense hybrid retrieval 的工程判断:BM25 擅长精确词项、专名、数字、错误码和短查询,向量召回擅长语义相近、同义表达和自然语言问题。融合比例不是拍脑袋固定值,而要根据 query 类型、离线指标、线上反馈、延迟成本和 badcase 分布动态调优。

同题还出现在 1 个公司岗位

生产级 RAG 的数据解析与入库流水线如何设计,如何处理 PDF、DOCX、表格、图片和多格式文档?

生产级 RAG 的数据解析与入库流水线应从文件接入、格式识别、内容解析、结构保留、规范化切分、embedding、索引落库、权限和质量监控全链路设计。PDF、DOCX、表格、图片、Markdown、TXT 和富文本的解析策略不同:PDF 要区分数字文本和扫描件,DOCX 要保留标题层级和表格,表格要理解 sheet、表头和单元格关系,图片要 OCR 或生成视觉描述,多格式文档要保留统一的 document、section、chunk 和 asset 元数据。入库侧要支持幂等、版本、增量更新、失败重试、死信队列、ACL 过滤、向量库和关键词索引协同,以及可回溯的解析证据。

RAG 中既然向量检索已经计算相似度,为什么还需要 Cross-Encoder 重排?

这道题考察 RAG 检索链路中双塔向量召回和 Cross-Encoder 重排的职责边界。好的回答要说明向量检索适合在大规模语料上做低成本粗召回,但它把 query 和文档分别编码,主要比较全局语义相似度,难以精细判断短语匹配、否定关系、字段约束、时效和答案可用性。Cross-Encoder 把 query 与候选片段一起输入模型,可以做 token 级交互和上下文相关判断,因此通常用于小候选集精排。回答还应覆盖成本、延迟、候选规模、失败模式、评估指标和何时不需要重排。

向量数据库检索到语义相关但时间过久的历史信息时,RAG 系统应如何判断能否使用?

这道题考察 RAG 系统面对“语义相关但时间过久”的向量检索结果时,如何把相关性判断升级为证据可用性判断。回答要说明不能只看 embedding 分数,而要结合问题的时效敏感度、文档时间戳、版本、生效范围、来源权威性、与新证据的冲突情况和业务风险来决定使用、降权、补检、拒答或提示不确定。好的方案还要覆盖元数据过滤、时间衰减、动态检索、冲突检测、评估指标和上线监控。