1000道算法工程师面试题（大模型）—— 第七部分

**文章摘要：RAG系统架构包含查询处理、检索、重排、生成四个关键环节，重点涉及查询改写、多模态chunk策略、跨模态检索和Prompt设计。向量检索技术中IVF适合大规模索引平衡速度与精度，HNSW适用于低延迟高召回场景，评估指标包括recall@K、延迟和吞吐量。多模态RAG需统一embedding空间，采用图文/音视频融合chunk，并配合多模态LLM生成答案，核心挑战在于跨模态对齐与检索效

快撑死的鱼

380人浏览 · 2025-11-19 21:29:01

快撑死的鱼 · 2025-11-19 21:29:01 发布

1000道大模型算法工程师面试题汇总（1-35部分 · 将持续更细）

96、介绍一下 RAG 的基本架构和信息流：query → 检索 → 重排 → 生成，各环节的关键点是什么？

答案：

一个典型的 RAG（Retrieval-Augmented Generation）管线可以画成这样：

用户 Query →（改写）→ 检索 → 重排 → 构造 Prompt → LLM 生成 →（可选后处理）

大致环节：

Query 处理（Query Understanding / Reformulation）
- 对原始 query 做：
  - 规范化（去噪、分句、去 HTML 等）；
  - 可选：query 扩展或改写（让检索更鲁棒，比如用一个小模型做重写）。
- 文本转 embedding（如果用向量检索），通常用与文档同一套 encoder。([arXiv][1])
检索（Retrieval）
- 向量检索 / 关键词检索 / 混合检索：
  - 向量检索：用 Milvus / FAISS / Weaviate / Pinecone 等；
  - 关键词检索：BM25 / ES / Azure Search 等；
  - 混合：把两者结果合并。
- 关键点：
  - chunk 策略：文档如何切块（长度、重叠、按段落/标题）；
  - 选择相似度度量（cosine / L2 / 内积）；
  - topK 选多少（通常 10–50 之间，再交给重排）。([Microsoft Learn][2])
重排（Rerank）
- 用更强的、通常是 cross-encoder 的模型，对初始检索的候选进行精排序：
  - 输入：(query, 文档片段)，输出相关性分数；
  - 只对 topK（比如 10–50）做重排，计算量可接受；
  - 常见：bge-reranker、Cohere rerank、各家自研 rerank 模型。([pinecone.io][3])
- 关键点：
  - 大幅提高相关性，减少无关噪声输给 LLM；
  - 控制重排 latency（通常几十毫秒量级）。
生成（Generation）
- 将 topN（通常 3–10）段文档组装进 prompt：
  - 加 citation / 来源标记；
  - 按相似度排序或按文档结构分区。
- 让 LLM 在指令中明确：
  - 必须基于给定文档回答；
  - 不知道就说不知道；
  - 尽量给出引用。
- 关键点：
  - 上下文长度管理：截断策略、信息压缩（如再摘要）；
  - prompt 模板设计：系统指令 + 文档 + 问题 + 输出格式。
可选后处理
- 结构化抽取（从回答中提取字段）；
- 额外验证（fact checking）；
- 答案重排序、置信度打分。

97、在 Milvus / FAISS / Weaviate / Pinecone 等向量数据库中，常用的索引类型（IVF、HNSW 等）及其适用场景是什么？

答案：

常见近似最近邻（ANN）索引主要几类：倒排（IVF / IVF+PQ）、图（HNSW）、暴力（Flat） 等。

Flat / Brute-force
- 全量扫描，精确最近邻；
- 优点：实现简单，准确率 100%，tail latency 稳定；
- 缺点：数据量一大就慢；
- 适用：
  - 小数据集（几万级）；
  - 离线批处理评估；
  - 精度要求极高且数据不大。([Milvus][4])
IVF（Inverted File）系列
- 思路：K-means 等聚类，把向量分到若干“桶”（centroid）；
- 查询时先找到离 query 最近的几个 centroid，然后只在对应桶内做精细搜索；
- 变种：
  - IVF_FLAT：桶内仍用原始向量；
  - IVF_PQ：桶内向量再用 Product Quantization 压缩；
  - IVF_SQ8 等量化版本。([Milvus][5])
- 适用：
  - 大规模库（百万～亿级）；
  - 需要在速度、内存、精度之间折中；
  - 对延迟有要求、可以接受少量 recall 损失的在线 RAG。
HNSW（Hierarchical Navigable Small World）图索引
- 图结构索引，构建多层小世界图；
- 查询时在高层快速跳跃、逐层向下，最终在底层精细搜索；
- 优点：
  - 检索速度非常快，且 recall 很高；
  - tail latency 比 IVF 更好；
- 缺点：
  - 内存占用较大；
  - 构建索引耗时长，参数多（M、efConstruction、efSearch 等）。([Milvus][4])
- 适用：
  - 在线检索、对 latency 和 recall 要求都很高；
  - 有足够内存/显存。
其他（PQ / OPQ / DiskANN 等）
- PQ / OPQ：侧重向量压缩以节省内存；
- DiskANN / SSD-based index：把部分向量放磁盘，适合超大规模但 latency 要求相对宽松的场景。([Milvus][4])

不同库里的支持概览（高层理解）：

Milvus：支持 IVF_FLAT、IVF_SQ8、IVF_PQ、HNSW、DiskANN 等，文档里有详细选型建议。([Milvus][5])
FAISS：提供最丰富的组合（Flat, IVF, HNSW, PQ, OPQ…）；
Weaviate / Pinecone：底层也常用 HNSW、IVF 等，但对用户更多是“托管黑盒 + 参数化”方式。

98、你会如何评估一个向量检索系统的效果与性能？常用的指标有哪些（例如 recall@K、latency 等）？

答案：

可以从 检索质量 和 系统性能 两个维度评估。

检索质量指标：
- Recall@K
  - 在有“真值邻居”的数据集上，统计 topK 中包含 ground-truth 的比例；
  - 评估 ANN 相对精确最近邻的损失。
- nDCG@K / MRR
  - 如果有相关性评分（多级相关），用 nDCG、MRR 等指标更精细衡量排名质量；
- RAG 端到端指标
  - 看最终回答质量（人工标注 / LLM judge）；
  - 不只看检索本身，还看对 LLM 输出的贡献。([arXiv][1])
性能指标：
- Latency（延迟）
  - p50 / p90 / p95 / p99；
  - 检索阶段的延迟通常要控制在几十毫秒级，否则整体 RAG 延迟会不可接受。
- Throughput（吞吐）
  - QPS：每秒查询数；
  - 在并发压力下 latency 是否恶化。
- 内存/存储占用
  - 索引构建后，索引本身占用多少内存；
  - 不同索引类型（IVF/HNSW/PQ）对内存的 trade-off。([Milvus][6])
评估方法：
- 离线评估：
  - 用公开基准（如 ann-benchmarks）或自建标注数据集；
  - 先用精确搜索（Flat）算出 gold neighbors，然后评估 ANN 索引的 recall@K；
  - 扫索引参数（nlist, nprobe, efSearch 等）找出“质量–延迟–内存”的 Pareto 前沿。
- 在线/灰度评估：
  - 在真实查询流量上 A/B 测试不同索引配置；
  - 比较：
    - 下游 RAG 回答的用户满意度；
    - 搜索延迟；
    - 资源消耗。

99、在构建图文/语音/视频多模态大模型 RAG 系统时，你会如何设计 embedding 与检索管线？

答案：

多模态 RAG 的核心问题是：不同模态如何统一检索？ 典型设计思路：

统一 / 对齐的多模态 embedding 模型：
- 使用支持多模态的 encoder：
  - 图文：CLIP 系列、Qwen-VL encoder、LLaVA 的 vision encoder 等；
  - 语音：可用 Whisper encoder + 文本 encoder 映射到统一空间；
  - 视频：对每帧 / clip 提取视觉 embedding，再聚合。
- 理想是：文本 query 与图像/音频/视频都在同一向量空间对比，实现 cross-modal retrieval。
文档切分与多模态片段（chunk）设计：
- 图文：
  - 以“文本 + 对应图片/图表”作为一个 chunk；
  - embedding 时可以：
    - 文本 encoder + vision encoder，然后 concat / 加权平均；
    - 或直接用多模态 encoder 输入 image+text。
- 语音 / 视频：
  - 先转录（ASR）得到文本；
  - 同时保留音频/视频片段的时间戳；
  - embedding 既可以只用文本，也可以将声学/视觉特征融合进 embedding。
索引与检索：
- 选择向量 DB（Milvus / FAISS / 等）建索引；
- 向量字段存的是“多模态融合向量”，同时存额外的 metadata：
  - 文本内容、图片 URL、时间戳、视频片段位置等。
- 查询时：
  - 文本 query → embedding；
  - （可选）图像 query / 语音 query → embedding（同一空间），实现 image-to-text / speech-to-text 检索。
重排与融合：
- 对检索到的多模态片段：
  - 用更强的多模态 cross-encoder 做重排；
  - 重排时同时看文本和图像/视频缩略图特征。
- 对结果进行多模态-aware 的过滤（如根据图像类别、时长等 metadata）。
生成阶段（多模态 LLM）：
- 对于 Qwen-VL / LLaVA 之类模型：
  - 直接把相关图片/视频帧 + 文本喂给模型；
  - prompt 中要说明图像/片段与问题的关系（如“图1”、“第10–20秒视频片段”）。
- 对纯文本 LLM：
  - 可以只用文本内容回答；
  - 对多模态信息做 textual grounding（比如给出图像描述），但能力会弱一些。
工程要点：
- 存储层：原始媒体存对象存储，向量 DB 存 embedding+metadata；
- 延迟控制：多模态 encoder 通常较重，可以做：
  - 离线预编码文档侧 embedding；
  - 在线 query 尽量只跑一次 encoder（避免多轮嵌入）。

100、请对比 Qwen-VL、LLaVA 等多模态大模型的特点，并分享一次你在实际部署与优化中的经验。

答案：

先对比两个代表性多模态模型，然后给一个可讲的部署/优化“故事模板”。

Qwen-VL 系列：

由阿里云提出的多模态大模型（Vision-Language Model），是 Qwen 系列的视觉版。([arXiv][7])
特点：
1. 能力丰富：
  - 图片理解、检测、文字阅读（OCR）、grounding（框选区域）等；
  - 新版本（如 Qwen2.5-VL / Qwen3-VL）支持多图片、视频理解。([阿里云][8])
2. 对中文、多语种友好：
  - 基座 Qwen 在中文表现强，多模态版继承了这一点；
3. 支持输出 bounding box 等结构化信息：
  - 适合做 UI 分析、文档解析、视觉定位等；
4. 生态完善：
  - 有官方文档、SDK、云上服务（Model Studio），部署相对简单。([阿里云][8])

LLaVA 系列：

LLaVA（Large Language and Vision Assistant），典型的“视觉 encoder + LLM + 轻量 projector”的开源多模态模型。([llava-vl.github.io][9])
特点：
1. 研究圈开源先驱：
  - 早期就提出“visual instruction tuning”的范式；
  - 训练了大量 GPT-4 生成的多模态指令数据。
2. 架构清晰，容易修改：
  - Vision encoder（多为 CLIP/ViT）+ Vicuna 等 LLM + 投影层；
  - 易于替换底座 LLM 或 vision encoder。
3. 开源权重广泛流传：
  - 多种参数规模（7B/13B/34B 等），社区有很多微调版本；
  - 对研究 / 原型开发很友好。([llava-vl.github.io][9])

简单对比：

语言能力：
- Qwen-VL 在中文、多语种上通常更强；
- LLaVA 初版偏英文，社区也有中文增强版。
视觉能力：
- Qwen-VL 原生支持细粒度视觉理解（检测、OCR、grounding）能力更强；
- LLaVA 主要在“看图聊天、问答、描述”方面表现优异。
工程生态：
- Qwen-VL 有云服务、商用支持，更适合集成到阿里云生态；
- LLaVA 在开源/研究社区使用非常广，定制性更高。

“部署与优化”实践经验模板（你可以代入自己的细节）：

场景：为一个内部“图文知识助手”做多模态问答：用户上传截图/报表/网页截屏，模型回答与图片相关的问题。

模型选择：
- 初期对比了 LLaVA-1.5-13B 和 Qwen-VL-Chat 系列：
  - 针对中文界面、表格截图、PDF 截图进行对比；
  - Qwen-VL 在中文 UI/文本识别与区域定位上表现更好；
  - 最终选择 Qwen-VL 作为主力模型。
部署方式：
- 使用官方提供的 Qwen-VL 推理代码，在多 GPU 服务器上部署；
- 对模型权重做 INT8 量化，减小显存占用；
- 上层统一暴露一个 HTTP / gRPC 接口，兼容现有业务网关。
性能瓶颈 & 优化：
- 初始版本的问题：
  - 单图推理延迟较高（> 1.5s），并发稍高时尾部延迟明显；
  - 大量请求是小图片/简单表格，没必要用同样大 batch。
- 优化措施：
  1. 按场景分路由：
    - 对简单 OCR/结构化抽取场景，先用轻量 OCR 模型处理；
    - 只有需要“复杂理解/推理”时才走 Qwen-VL；
  2. batching + 并发控制：
    - 对相近大小图像请求进行小 batch 合并；
    - 控制单实例最大并发，避免显存抖动；
  3. 图像预处理：
    - 对超大分辨率图像先做下采样（保证关键信息不丢）；
    - 在前端限制上传分辨率上限。
  4. 缓存与结果重用：
    - 对重复图片（hash 一下）做结果缓存；
    - 高频文档页面先离线解析成结构化结果，再用文本 RAG 回答。
效果与收获：
- 在典型 1080p 截图上，p95 延迟从 2s 降到约 800–900ms；
- 用户提问命中率明显提高，特别是表格类问题（Qwen-VL 对读表能力较强）；
- 系统可以平稳支撑数百并发的内部使用场景。

1000道大模型算法工程师面试题汇总（1-35部分 · 将持续更细）

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

2025年9款AI写论文神器实测：查重率低+原创度高，毕业论文轻松搞定！

2048 AI社区

【技术干货】大模型微调vs从零训练：从理论到实践的完整指南，建议收藏！

2048 AI社区

运动规划OMPL库使用，RRTstar路径规划应用代码C++（AI辅助写的）

特性RRT*采样区域全局随机椭圆区域（基于当前最优解）收敛速度较慢✅更快路径质量渐进最优✅更快逼近最优实现复杂度简单中等（需维护启发式采样）是否需要初始解❌ 否✅ 是（首次为全空间，之后缩小）🔍 原理：Informed RRT* 使用—— 只在“有可能找到更好解”的椭球区域内采样，避免无效探索。编译运行，比较两种算法性能导出数据进行分析或发表论文扩展到高维空间（如机械臂）、加入动力学约束等加入实