万字详解面试题库

RAG是Retrieval-Augmented Generation的缩写，中文叫检索增强生成。它解决的是大模型知识局限和幻觉问题。

大模型的知识来自训练数据，有截止日期，无法获取最新信息。同时模型会一本正经地胡说八道，生成看似合理但实际错误的内容。

RAG的思路是在生成答案之前，先从外部知识库中检索相关信息，把检索到的内容作为上下文传给模型，让模型基于这些事实来生成答案。这样既扩展了模型的知识边界，又提高了答案的准确性和可溯源性。

RAG是目前大模型落地应用的主流方案，特别适合企业知识库问答、客服、文档分析等场景。

RAG流程分为索引阶段和查询阶段。

索引阶段：
1. 把文档切分成适当大小的片段
2. 通过Embedding模型把片段转换成向量
3. 把向量存储到向量数据库中，同时保存原始文本作为元数据

查询阶段：
1. 把用户问题转换成向量
2. 在向量数据库中做相似度搜索，召回最相关的几个文档片段
3. 把用户问题和检索到的片段一起拼成Prompt传给大模型，让模型生成答案

整个流程的关键在于检索的准确率和召回率，如果检索不到相关内容或者检索到不相关的内容，都会影响最终答案质量。

Embedding模型选型要考虑四个因素：

1. 语言支持 - 中文场景要用中文模型比如BGE、M3E、Text2Vec，英文场景选择更多比如OpenAI的text-embedding-ada-002、sentence-transformers系列。

2. 向量维度 - 维度越高表达能力越强但存储和计算成本也越高，常见有384维、768维、1024维、1536维等。

3. 上下文长度 - 模型能处理的最大文本长度，要覆盖文档片段的大小，常见有512、1024、2048、8192等。

4. 性能指标 - 关注在标准评测集上的MRR、NDCG、Recall@K等指标。

实际选型要在效果和成本之间权衡，一般先用开源模型验证效果，效果不达标再考虑商用API。

向量数据库选型要考虑规模、性能、成本等因素：

Faiss - Facebook开源的向量检索库，适合小规模本地部署，支持多种索引算法，但不支持分布式和持久化。

Milvus - 专门的向量数据库，支持分布式部署、多种索引类型、混合查询，适合大规模生产环境。

Pinecone - 托管服务，开箱即用但成本较高，适合快速验证。

Weaviate - 支持向量搜索和语义搜索，有GraphQL接口，功能丰富但学习成本较高。

pgvector - PostgreSQL的向量扩展，适合已有PG基础设施的场景，可以复用现有的运维能力。

Elasticsearch - 也支持向量搜索，适合需要同时做关键词搜索和向量搜索的场景。

选型要根据数据规模、查询QPS、团队技术栈综合考虑。

提高检索准确率可以从查询优化、索引优化、重排序三个层面入手：

查询优化：
• 查询扩展 - 用LLM把用户问题改写成多个同义表达增加命中概率
• 查询分解 - 把复杂问题拆成多个子问题分别检索
• HyDE技术 - 用LLM生成假设答案再检索相似文档

索引优化：
• 文档切分策略优化 - 按语义边界切分而不是固定长度
• 元数据增强 - 给文档打上标签、分类、时间等元数据支持过滤检索
• 摘要索引 - 存储文档摘要用于粗排，原始文本用于精排

重排序：
用更精确的模型对召回结果二次排序，比如用Cross-Encoder计算问题和文档的相关性分数，或者用LLM判断文档是否包含答案。

多种技术组合使用可以显著提升检索效果。

多轮对话中用户的问题往往依赖上下文，单独检索当前问题可能找不到相关信息。解决方案有几种：

历史拼接 - 把多轮对话历史拼在一起作为查询，但会引入噪声且可能超出长度限制。

查询重写 - 用LLM把当前问题结合历史改写成独立完整的问题，然后再检索。

历史摘要 - 维护一个对话摘要作为上下文，既保留关键信息又控制长度。

独立检索 - 分别检索历史问题和当前问题的相关文档，合并去重后传给模型。

实际应用中查询重写效果较好，可以用专门的模型或者Prompt工程实现。要注意的是改写本身也有成本，需要在效果和开销之间权衡。

上下文压缩是解决检索结果过长导致超出模型上下文限制或者干扰模型注意力的问题。直接把所有检索到的文档片段拼进Prompt可能太长，而且包含很多无关信息。

压缩方法：

Map-Reduce - 把长文档分段处理，每段分别与问题做相关性判断，只保留相关部分。

Refine - 迭代精炼，先用部分文档生成初步答案，再逐步引入其他文档完善答案。

相关性过滤 - 用轻量级模型计算每个片段与问题的相关性分数，只保留高分片段。

LLM压缩 - 用模型提取关键信息生成摘要。

实际应用中通常组合使用，先用轻量级方法粗筛，再用LLM精筛，既保证效果又控制成本。

RAG系统评估要分别评估检索和生成两个阶段。

检索阶段评估指标：
• Recall@K - 前K个结果中相关文档的比例
• MRR - 第一个相关文档的排名倒数
• NDCG - 考虑排序位置的加权指标

生成阶段评估指标：
• 答案相关性 - 答案是否切题
• 答案忠实度 - 答案是否基于检索内容而不是胡编
• 答案完整性 - 是否覆盖了问题的所有方面

评估方法：
• 手工标注构建测试集
• 用LLM作为评判员自动打分
• 端到端的人工评估

实际落地要建立持续评估机制，定期抽样检查效果，收集用户反馈，形成数据闭环不断优化。

RAG和知识图谱结合可以互补优势。RAG擅长处理非结构化文本，知识图谱擅长处理结构化关系。

结合方式：

图谱增强检索 - 先用知识图谱做实体链接和关系推理，扩展查询语义，再用RAG检索相关文档。

结构化RAG - 把知识图谱作为检索源之一，直接检索图谱中的三元组作为上下文。

混合推理 - 让模型同时参考文本片段和知识图谱，结合两者生成答案。

比如回答公司相关问题，可以从图谱获取股权关系、高管信息，从文本获取新闻报道、财报分析。

实现上可以用GraphRAG等框架，或者自己构建Pipeline。结合的关键在于实体识别和链接的准确性，以及图谱的覆盖度和质量。

知识冲突是指检索到的多个文档片段包含相互矛盾的信息。处理冲突有几种策略：

置信度排序 - 根据文档来源的权威性、时效性、相关性给不同片段赋权重，优先采信高权重来源。

时效性优先 - 对于时效敏感的问题，优先使用最新文档。

多源验证 - 要求多个独立来源都支持才采信。

不确定性表达 - 让模型在答案中说明存在不同说法，而不是强行给出唯一答案。

冲突检测 - 用LLM判断检索结果是否存在矛盾，如果存在矛盾可以进一步追问用户澄清，或者把矛盾点都列出来让用户判断。

实际应用中冲突处理要结合业务场景，有些场景要求给出确定答案，有些场景可以保留不确定性。

RAG性能优化可以从索引、检索、生成三个环节入手：

索引优化：
• 选择合适的向量索引算法，HNSW适合查询多，IVF适合更新多
• 索引分片 - 大数据量时分片存储提高并发
• 量化压缩 - 用PQ等方法压缩向量减少存储和传输开销

检索优化：
• 缓存热门查询结果
• 预过滤 - 先用元数据过滤缩小检索范围
• 并行检索 - 同时检索多个查询变种

生成优化：
• 流式输出提升用户体验
• 模型蒸馏用小模型替代大模型
• Prompt压缩只保留最相关的上下文

实际优化要用profiling工具定位瓶颈，避免盲目优化。通常检索是瓶颈，优先优化向量索引和检索策略。

企业落地RAG面临数据、技术、运营三方面挑战：

数据挑战：
• 文档质量参差不齐，需要清洗和标准化
• 权限控制 - 不同用户能访问的知识范围不同
• 数据更新 - 知识库内容频繁变动需要及时同步

技术挑战：
• 与现有系统集成，比如对接企业微信、钉钉、OA等
• 高可用部署 - 满足企业级SLA要求
• 安全合规 - 数据不出域、敏感信息脱敏等

运营挑战：
• 效果持续优化，建立反馈闭环
• 成本控制 - 平衡效果和开销
• 用户培训 - 让员工习惯使用

解决这些挑战需要产品、技术、运营的紧密配合，不能单纯追求技术指标，要关注实际业务价值。

RAG是Retrieval-Augmented Generation的缩写，中文叫检索增强生成。它是一种把信息检索和文本生成结合起来的技术框架。

核心思想：
在让大模型生成答案之前，先从外部知识库中检索相关信息，把检索到的内容作为上下文提供给模型，让模型基于这些事实来生成答案。

这样做有两个好处：
1. 扩展知识边界 - 模型可以获取训练数据之外的信息，特别是企业私有知识和最新信息
2. 提高准确性和可溯源性 - 模型基于检索到的真实内容生成，减少了幻觉，而且可以给出信息来源

基本流程：
• 索引阶段 - 把文档切分、向量化、存储到向量数据库
• 查询阶段 - 把用户问题向量化、检索相关文档、拼接Prompt、生成答案

RAG是目前大模型落地应用的主流方案，特别适合企业知识库问答、智能客服、文档分析等场景。

文档分块大小和topK参数的选择要通过实验确定，没有固定标准。

分块大小的考虑因素：
• 太小会丢失上下文信息，比如一个段落被切成多块，每块单独看都语义不完整
• 太大会降低检索精度，一个块包含太多内容，只有一小部分相关，会干扰模型注意力
• 通常几百个Token比较合适，比如256到512之间
• 还要考虑文档结构，按段落或章节边界切分比固定长度切分效果更好

topK参数的选择：
• 要权衡召回率和成本，K太小可能漏掉相关信息，K太大会增加噪声和成本
• 通常先设置一个较大的值比如10到20，然后通过实验找到最优值
• 评估方法是用测试集测试不同K值的Recall和Precision，找到平衡点
• 实际应用中还可以动态调整，对于复杂问题增大K值，简单问题减小K值

Agentic RAG是把AI Agent和RAG结合起来的进阶方案。

与传统RAG的区别：
传统RAG是一次性检索然后生成答案，Agentic RAG则是让Agent自主决定检索策略，可以多次检索、动态调整查询、甚至主动验证信息。

具体实现方式：
• 查询重写 - Agent分析用户问题，生成多个检索查询从不同角度收集信息
• 多步检索 - 第一轮检索后分析结果，发现信息不足就生成新的查询继续检索，直到收集到足够信息
• 信息验证 - Agent对检索到的信息进行交叉验证，发现矛盾时进一步检索澄清
• 主动追问 - 当问题不清晰时，Agent主动向用户提问澄清需求

优势与代价：
优势是能够处理更复杂的查询，比如需要多跳推理的问题，或者需要综合多个来源信息的问题。代价是延迟增加、成本上升，适合对答案质量要求高、可以承受一定延迟的场景。

混合RAG是指同时结合多种检索方式的RAG方案。

常见组合：
• 向量检索 + 关键词检索 - 向量检索擅长语义匹配，关键词检索擅长精确匹配，两者结合可以兼顾模糊查询和精确查询
• 稀疏向量 + 稠密向量 - 稀疏向量基于词频适合关键词匹配，稠密向量基于语义适合概念匹配
• 内部知识库 + 外部搜索引擎 - 内部知识库检索企业私有文档，外部搜索引擎获取互联网公开信息
• 多模态检索 - 同时检索文本、图片、表格等不同模态的内容

好处：
互补各种检索方式的优势，提高召回率和准确率。比如用户搜索产品型号，向量检索可能找不到精确匹配，关键词检索可以精确命中。

实现方式：
可以用RRF倒数排名融合等方法合并不同检索方式的结果。

文档更新处理是RAG系统的运维重点。

全量重建 - 最简单的方式，文档更新后重新切分、向量化、构建索引，适合更新频率低的场景。

增量更新 - 更高效的方式，只处理变更的文档：
• 文档版本管理 - 给每个文档打版本标签，更新时识别变更的文档
• 增量索引 - 新文档直接添加到索引，删除的文档从索引中移除，修改的文档先删除旧版本再添加新版本
• 索引分区 - 按时间或类别分区，更新时只重建受影响的分区

更新策略：
• 实时更新 - 文档变更立即触发索引更新，适合对实时性要求高的场景
• 定时更新 - 比如每小时或每天批量更新一次，适合更新频率适中的场景

还要考虑更新期间的查询服务不中断，通常采用双索引切换或者索引版本管理来实现平滑过渡。

选择Milvus作为向量数据库主要基于以下考虑：

1. 专为向量设计 - Milvus是专门为向量检索打造的数据库，支持多种向量索引类型如HNSW、IVF_FLAT、IVF_SQ8等，能根据数据规模和查询特点灵活选择。

2. 分布式架构 - 支持水平扩展，可以处理十亿级别的向量数据，适合企业级生产环境的高并发查询需求。

3. 混合查询能力 - 除了向量相似度搜索，还支持标量过滤，可以结合元数据条件进行精确过滤，比如按时间范围、文档类型等筛选后再做向量检索。

4. 生态完善 - 提供Python、Java、Go等多种语言的SDK，与LangChain、LlamaIndex等主流框架有良好集成，开发成本低。

5. 云原生支持 - 支持Kubernetes部署，有完善的监控和运维工具，符合现代云原生架构要求。

相比Faiss这种单机库，Milvus更适合生产环境；相比Pinecone这种托管服务，Milvus可以私有化部署，数据安全可控。

召回和重排是RAG检索流程中两个不同的阶段，各自承担不同职责：

召回阶段（Retrieval）：
• 目标是从海量文档中快速筛选出可能相关的候选集
• 追求高召回率，宁可错杀不可放过，确保相关文档被包含
• 通常使用向量相似度搜索，计算Query和文档向量的余弦相似度
• 速度快但精度相对较低，一般召回几十到几百个结果

重排阶段（Reranking）：
• 目标是对召回的候选集进行精确排序，找出最相关的文档
• 追求高准确率，确保排在前面的都是真正相关的
• 通常使用Cross-Encoder等更精确的模型，直接计算Query和文档的交互相关性
• 速度较慢但精度高，一般只处理Top K个候选

为什么分两阶段：
如果直接用Cross-Encoder对所有文档打分，计算量太大无法接受。先用向量检索快速召回候选，再用重排模型精确排序，是效率和效果的平衡。

Embedding中文叫嵌入或向量表示，是将高维离散数据映射到低维连续向量空间的技术。

核心概念：
• 把文本、图片、音频等非结构化数据转换成固定维度的数值向量
• 向量中的每个维度代表某种语义特征
• 语义相似的内容在向量空间中距离更近

在RAG中的作用：
• 文档向量化 - 把知识库文档转换成向量存储
• 查询向量化 - 把用户问题转换成向量
• 相似度计算 - 通过向量距离计算语义相似度

常用模型：
• 中文：BGE、M3E、Text2Vec
• 英文：OpenAI text-embedding、sentence-transformers

相似度度量：
通常使用余弦相似度或欧氏距离，余弦相似度关注向量方向，对长度不敏感，更适合文本语义匹配。

RAG召回阶段常用的相似度算法主要有以下几种：

1. 余弦相似度（Cosine Similarity）
• 计算两个向量夹角的余弦值
• 值域[-1, 1]，1表示完全相同方向，-1表示相反方向
• 优点：对向量长度不敏感，只关注方向，适合文本语义匹配
• 缺点：无法区分向量大小差异

2. 欧氏距离（Euclidean Distance）
• 计算向量空间中的直线距离
• 距离越小表示越相似
• 优点：直观，计算简单
• 缺点：受向量长度影响，需要归一化处理

3. 点积（Dot Product）
• 直接计算向量对应元素相乘再求和
• 优点：计算最快，适合大规模检索
• 缺点：同时受方向和长度影响

实际应用：
向量数据库通常使用余弦相似度作为默认度量，因为它对文本语义匹配效果最好。在使用前需要确保Embedding向量已经归一化，这样点积就等价于余弦相似度，可以加速计算。

避免幻觉是RAG系统的核心挑战，需要多管齐下：

1. RAG增强
• 让模型基于检索到的真实内容生成，而不是依赖训练记忆
• 这是最根本的防幻觉手段

2. Prompt约束
• 明确要求模型基于提供的上下文回答
• 禁止编造，不确定就说不确定
• 添加"如果你不确定，请回答我不知道"等约束

3. 事实校验
• 对关键事实用外部工具验证，比如搜索、数据库查询
• 用规则或模型检测可能的幻觉内容

4. 引用溯源
• 要求模型给出信息来源，便于核查
• 实现方式是在Prompt中要求标注引用文档编号

5. 置信度评估
• 让模型评估答案置信度，低置信度时提示用户
• 或者设置阈值，低于阈值时转人工

6. 多模型验证
• 用多个模型独立回答，对比一致性
• 不一致时标记为高风险

幻觉无法完全避免，但可以通过技术手段大幅降低，关键是让模型有自知之明，不确定时不强行回答。