RAG

pax大约 43 分钟

RAG

切分、嵌入、检索、重排和知识库。

029 · 中 · 请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？有哪些优势？

来源：Hello-Agents Extra01

RAG (Retrieval-Augmented Generation) 的工作原理是一种“先检索，后生成”的模式，它将信息检索（Information Retrieval）与文本生成（Text Generation）相结合，来增强大型语言模型（LLM）的能力。

工作流程如下：

检索（Retrieve）： 当用户提出一个问题时，RAG系统首先不会直接将问题发送给LLM。相反，它会把用户的问题作为一个查询（Query），在一个外部的知识库（通常是向量数据库）中进行搜索，找出与问题最相关的几段信息（documents/chunks）。
增强（Augment）： 系统会将检索到的这些相关信息与用户的原始问题拼接在一起，形成一个内容更丰富、信息量更大的增强提示（Augmented Prompt）。
生成（Generate）： 最后，将这个增强后的提示喂给LLM。LLM会基于其自身的知识和我们提供的上下文信息，生成一个更准确、更具事实性的回答。

RAG主要解决了LLM的以下核心问题：

知识的静态性与过时性： LLM的知识被“冻结”在其训练数据截止的那个时间点。RAG通过连接一个可以随时更新的外部知识库，使得LLM能够获取和利用最新的信息，解决了知识过时的问题。
幻觉（Hallucination）： LLM在回答其知识范围外或不确定的问题时，倾向于捏造事实。RAG通过提供具体的、相关的上下文，将LLM的回答“锚定”在这些事实依据上，显著降低了幻觉的产生。
缺乏专业领域知识与私有知识： 对LLM进行微调来注入特定领域的知识成本高昂且效果有限。RAG可以轻松地将模型与任何私有数据集（如公司内部文档、个人笔记）连接起来，使其成为一个领域专家。

与微调（Fine-tuning）相比，RAG的优势：

知识更新成本低： 更新知识只需在数据库中添加或修改文档，无需重新训练昂贵的LLM。而微调则需要重新进行训练。
可追溯性与可解释性： RAG可以清晰地展示出答案是基于哪些源文档生成的，用户可以点击查看来源进行事实核查。微调则像一个“黑盒”，无法知道知识的具体来源。
降低幻觉： RAG通过提供事实依据，让回答有据可循。微调虽然能注入知识，但模型仍可能在不确定时产生幻觉。
高效费比： 对于注入事实性知识的场景，RAG的开发和维护成本远低于微调。
个性化： 可以为每个用户或每个请求动态地接入不同的知识源，实现高度的个性化服务。

030 · 中 · 一个完整的 RAG 流水线包含哪些关键步骤？请从数据准备到最终生成，详细描述整个过程。

来源：Hello-Agents Extra01

一个完整的RAG流水线可以分为两个主要阶段：离线的数据准备（索引）阶段 和 在线的查询（推理）阶段。

阶段一：数据准备 / 索引流水线 (Offline / Indexing Pipeline)
这个阶段的目标是构建一个可供检索的知识库，它通常是一次性或周期性执行的。

数据加载（Load）： 从各种数据源加载原始文档。数据源可以是PDF文件、Word文档、网页、Notion数据库、Confluence页面、数据库表格等。
文本切块（Split / Chunk）： 将加载进来的长文档切割成更小的、语义完整的文本块（chunks）。这一步至关重要，因为后续的检索和生成都是以这些小块为单位的。
嵌入（Embed）： 使用一个预训练的文本嵌入模型（Embedding Model，如BERT, BGE, M3E等），将每一个文本块转换成一个高维的数字向量（vector）。这个向量捕捉了文本块的语义信息。
存储（Store）： 将每个文本块的内容及其对应的嵌入向量存储到一个专门的数据库中，最常见的就是向量数据库（Vector Database），如FAISS, ChromaDB, Pinecone等。数据库会为这些向量建立索引，以便进行高效的相似度搜索。

阶段二：查询 / 推理流水线 (Online / Inference Pipeline)
这个阶段是当用户提出问题时实时执行的。

用户提问（User Query）： 系统接收用户输入的自然语言问题。
查询嵌入（Embed Query）： 使用与步骤三中完全相同的嵌入模型，将用户的提问也转换成一个查询向量。
向量检索（Retrieve）： 将这个查询向量与向量数据库中存储的所有文本块向量进行相似度计算（通常是余弦相似度或点积）。系统会找出与查询向量最相似的Top-K个文本块向量，并将它们对应的原始文本块内容检索出来。
（可选）重排序（Re-rank）： 为了进一步提升检索质量，可以引入一个重排序模型。它会对初步检索出的Top-K个文本块进行更精细的打分和排序，选出与问题真正最相关的Top-N个（N < K）。
增强与生成（Augment & Generate）：

将重排序后最优的N个文本块内容，与用户的原始问题一起，按照一个预设的模板（Prompt Template）组合成一个增强提示。
将这个增强提示发送给LLM，由LLM基于提供的上下文和自身知识，生成最终的、流畅的、有根据的回答。

031 · 中 · 在构建知识库时，文本切块策略至关重要。你会如何选择合适的切块大小和重叠长度？这背后有什么权衡？

来源：Hello-Agents Extra01

文本切块（Chunking）是RAG流程中最关键且最需要经验的步骤之一，它直接影响检索的召回率和精确度，进而影响最终生成答案的质量。选择合适的切块大小（Chunk Size）和重叠长度（Overlap）需要在多个因素之间进行权衡。

如何选择合适的切块大小（Chunk Size）？

依据嵌入模型的能力： 嵌入模型有其输入的最大Token数限制。切块大小应小于这个限制。同时，很多嵌入模型在处理中等长度（如256-512个token）的文本时效果最好，过长或过短都可能导致语义表征质量下降。
依据数据的类型和结构：

对于结构化的、段落分明的文档（如论文、报告），可以采用语义切块，即按段落、标题或句子来切分，这样能最大程度地保留语义完整性。
对于非结构化的长文本，则更多地依赖固定长度切块。
对于代码，应该按函数或类来切块，而不是简单地按行数。

依据预期的查询类型： 如果用户的问题通常很具体，需要精确定位到某一句话，那么较小的切块（如句子级别）可能更有效。如果用户的问题很宽泛，需要综合多个段落的信息，那么较大的切块会更好。

如何选择合适的重叠长度（Overlap）？

重叠长度的作用是防止语义信息在切块边界被硬生生地切断。例如，一个重要的概念可能在一句话的结尾被提出，而在下一句话的开头进行解释。如果没有重叠，这句话就会被分割到两个独立的块中，破坏其完整性。

一个常见的经验法则是设置重叠长度为切块大小的10%-20%。例如，对于1024个token的切块，可以设置128或256个token的重叠。
重叠并非越大越好，过大的重叠会增加数据冗余和存储成本。

背后的权衡（Trade-offs）：

大块（Large Chunks） vs. 小块（Small Chunks）：
大块的优点： 包含更丰富的上下文，有助于回答需要广泛背景知识的复杂问题。
大块的缺点：
1. 噪声增加： 可能会包含大量与用户查询不直接相关的信息，稀释了关键信息的“信噪比”。
2. 检索精度下降： 嵌入向量代表的是整个大块的平均语义，可能无法精确匹配非常具体的问题。
3. 成本更高： 送入LLM的上下文更长，API调用成本更高。
4. “大海捞针”问题： 容易触发LLM的“Lost in the Middle”问题。
小块的优点： 信息密度高，与具体问题的相关性强，检索更精确。
小块的缺点：
1. 上下文不足： 单个小块可能不包含回答问题所需的全部信息，需要检索并拼接多个小块才能形成完整答案。
2. 语义割裂： 容易将原本连续的上下文信息切断。

总结：
切块策略没有唯一的“最佳”方案。实践中，通常会从一个合理的基线（如chunk_size=512, overlap=64）开始，然后通过评估检索质量，针对具体的文档类型和查询场景进行迭代优化。有时甚至会采用多尺度切块的策略，即同时索引不同大小的块，以应对不同粒度的查询。

032 · 中 · 如何选择一个合适的嵌入模型？评估一个 Embedding 模型的好坏有哪些指标？

来源：Hello-Agents Extra01

选择合适的嵌入模型（Embedding Model）是决定RAG系统检索效果的基石。一个好的嵌入模型应该能够将语义相近的文本映射到向量空间中相近的位置。

如何选择合适的嵌入模型？

参考公开排行榜（Leaderboards）：

MTEB (Massive Text Embedding Benchmark) 是目前最权威、最全面的嵌入模型评测基准。它涵盖了多种任务和语言，是选择模型的首要参考。可以直接查看MTEB排行榜，选择在 检索（Retrieval） 任务上得分高的模型。
C-MTEB是专门针对中文的排行榜。

考虑具体应用场景：

领域特异性： 如果你的知识库是某个专业领域（如医疗、法律、金融），可以考虑使用在该领域数据上预训练或微调过的嵌入模型，它们通常比通用模型表现更好。
语言支持： 确保模型支持你的业务所涉及的语言，特别是对于多语言场景。
模型大小与速度： 模型越大通常效果越好，但推理速度也越慢，成本越高。需要在效果和性能之间做出权衡。对于需要低延迟的实时应用，可能需要选择一个更小的模型。

私有模型 vs. 开源模型：

私有模型（如OpenAI的Ada系列）： 优点是性能强大，使用方便。缺点是数据需要通过API传输，存在隐私风险，且成本较高。
开源模型（如BGE, M3E, Jina-embeddings等）： 优点是可本地部署，数据安全可控，成本低，且有大量高质量模型可供选择。缺点是需要自己进行部署和维护。

评估Embedding模型好坏的指标：
评估指标主要来自MTEB基准，可以分为几大类：

检索（Retrieval）： 这是对RAG最重要的评估任务。

nDCG@k (Normalized Discounted Cumulative Gain): 综合衡量了检索结果的相关性和排名。是检索任务中最核心和最全面的指标。
Recall@k: 衡量在前k个结果中，召回了多少比例的相关文档。
MRR (Mean Reciprocal Rank): 衡量第一个相关文档出现在第几位。适用于那些只需要找到一个正确答案的场景。

语义文本相似度（Semantic Textual Similarity, STS）：

指标： Spearman或Pearson相关系数。
评估方式： 衡量模型计算出的向量余弦相似度，与人类判断的两句话的语义相似度分数之间的相关性。一个好的模型，其相似度计算结果应该与人类的直觉高度一致。

分类（Classification）：

指标： 准确率（Accuracy）。
评估方式： 将文本嵌入向量作为特征，训练一个简单的逻辑回归分类器，看其在文本分类任务上的表现。这衡量了嵌入向量作为“特征”的质量。

聚类（Clustering）：

指标： V-measure。
评估方式： 看模型生成的嵌入向量能否在无监督的情况下，将语义相似的文本自然地聚集在一起。

033 · 中 · 除了基础的向量检索，你还知道哪些可以提升 RAG 检索质量的技术？

来源：Hello-Agents Extra01

基础的向量检索（Dense Retrieval）虽然有效，但在处理复杂查询和多样化文档时往往会遇到瓶颈。为了提升检索质量，学术界和工业界发展出了许多先进的技术，主要可以分为增强检索器和优化查询两大类。

一、增强检索器（Improving the Retriever）

混合搜索（Hybrid Search）：

技术： 将 稀疏检索（Sparse Retrieval） 和 密集检索（Dense Retrieval） 相结合。
- 稀疏检索（如BM25）： 基于关键词匹配，对于包含特定术语、缩写、ID的查询非常有效。
- 密集检索（向量搜索）： 基于语义相似度，擅长理解长尾、口语化的查询。
优势： 兼顾了关键词精确匹配和语义模糊匹配的能力，效果通常远超单一检索方法。

重排序（Re-ranking）：

技术： 采用一个 两阶段（two-stage） 的检索流程。
1. 召回（Recall）： 先用一个快速但相对粗糙的方法（如向量搜索或混合搜索）从海量文档中召回一个较大的候选集（例如Top 50）。
2. 重排（Re-rank）： 再使用一个更强大、更复杂的模型（通常是Cross-Encoder）对这个小候选集进行精细化的重排序，选出最终的Top-N（例如Top 5）作为上下文。
优势： Cross-Encoder可以直接比较查询和文档的文本，捕捉更细粒度的相关性，精度远高于单纯的向量相似度，极大地提升了最终上下文的质量。

二、优化查询（Improving the Query）

查询扩展与转换（Query Expansion & Transformation）：

技术： 不直接使用用户的原始查询进行检索，而是先用LLM对查询进行“加工”。
方法：
- 多查询检索（Multi-Query Retrieval）： 让LLM针对原始问题，从不同角度生成多个不同的查询，然后对所有查询的检索结果进行合并。
- HyDE（Hypothetical Document Embeddings）： 让LLM先针对问题生成一个“假设性”的答案，然后用这个假设性答案的嵌入去检索，因为答案的文本和目标文档的文本在形式上更相似。
- 子问题查询（Sub-Querying）： 对于复杂问题，先将其分解成多个简单的子问题，分别检索，再汇总结果。

三、优化索引结构（Improving the Index）

小块引用大块（Small-to-Large Chunking）：

技术： 在索引时，将文档切成小的、用于检索的“摘要块”（Summary Chunks），但每个小块都保留对它所属的、更大的“父块”（Parent Chunk）的引用。
流程： 检索时，用查询匹配小块以获得高精度，但最终送给LLM的是包含更丰富上下文的父块。
优势： 兼顾了小块检索的精确性和大块上下文的完整性。

图索引（Graph Indexing）：

技术： 除了向量索引，还用LLM提取文档中的实体和关系，构建一个知识图谱。
流程： 检索时，可以先在图谱中进行结构化查询，找到相关的实体和子图，再结合向量检索进行补充。
优势： 对于需要进行多跳推理、理解实体关系的查询非常有效。

034 · 难 · 请解释“Lost in the Middle”问题。它描述了 RAG 中的什么现象？有什么方法可以缓解这个问题？

来源：Hello-Agents Extra01

“Lost in the Middle” 是指大型语言模型（LLM）在处理一个长上下文（long context）时，倾向于更好地回忆和利用位于上下文开头和结尾的信息，而忽略或遗忘位于中间部分的信息的一种现象。这个发现在斯坦福大学的一篇名为《Lost in the Middle: How Language Models Use Long Contexts》的论文中被系统性地揭示。

在RAG中的现象：
这个现象对RAG系统有直接且重要的影响。在RAG的生成阶段，我们通常会将检索到的Top-K个文档块与用户的原始问题拼接起来，形成一个长长的prompt。例如：
[原始问题] + [文档1] + [文档2] + [文档3] + ... + [文档K]

如果LLM存在“Lost in the Middle”的问题，那么：

文档1 和 文档K 的内容会得到LLM的充分关注。
而位于中间的文档2、文档3...等，即使它们包含了回答问题的关键信息，也有很大概率被LLM忽略，导致最终生成的答案信息不完整或不准确。
这会使得我们精心设计的检索环节（如重排序）的效果大打折扣，因为即使我们把最相关的文档排在了前面，只要它不是第一个或最后一个，就可能被“遗忘”。

缓解方法：

文档重排序（Document Re-ordering）：

核心思想： 不再按照检索分数的顺序简单地拼接文档，而是有策略地放置它们。
具体做法： 在将检索到的K个文档送入LLM之前，进行一次重排序。将最相关的文档放置在上下文的开头和结尾，而将次要相关的文档放在中间。这样可以确保关键信息处于LLM的“注意力甜点区”。

减少检索的文档数量（Reduce the Number of Retrieved Documents）：

核心思想： 与其送入大量可能包含噪声的文档，不如只送入少数几个最关键的文档。
具体做法： 严格控制Top-K中的K值，例如只取Top-3或Top-5。这需要前端的检索和重排序步骤有更高的精度，确保召回的文档质量足够高。

指令化提示（Instruct the Model）：

核心思想： 在prompt中明确指示模型要关注所有提供的上下文。
具体做法： 在prompt的末尾加入类似这样的指令：“请确保你的回答完全基于以上提供的所有上下文信息，不要忽略任何一份文档。” 虽然这不能完全解决问题，但在一定程度上可以引导模型的注意力。

对LLM进行微调（Fine-tune the LLM）：

核心思想： 训练LLM更好地处理长上下文。
具体做法： 构建一个特定的微调数据集，其中的任务要求模型必须利用位于上下文中间部分的信息才能正确回答。通过这种方式，可以“强迫”模型学会不忽略中间内容。这是最根本但成本也最高的解决方案。

035 · 中 · 如何全面地评估一个 RAG 系统的性能？请分别从检索和生成两个阶段提出评估指标。

来源：Hello-Agents Extra01

全面地评估一个RAG系统，必须将其拆分为检索阶段和生成阶段两个独立但又相互关联的部分进行评估，因为最终答案的质量是这两个阶段共同作用的结果。一个好的评估框架应该同时包含客观的、自动化的指标和主观的、人工的评估。

第一阶段：检索性能评估 (Retrieval Evaluation)
这个阶段的目标是评估我们的检索器（Retriever）能否“找得对、找得全”。评估需要一个包含（问题，相关文档ID）的标注数据集。

核心指标：

上下文精确率 (Context Precision): 衡量检索到的文档中有多少是真正与问题相关的。它反映了检索结果的信噪比。
上下文召回率 (Context Recall): 衡量所有相关的文档中，有多少被我们的检索器成功找回来了。它反映了信息查找的全面性。

其他常用排名指标：

Hit Rate: 检索到的文档中是否至少包含一个相关文档。这是一个基础的“及格线”指标。
MRR (Mean Reciprocal Rank): 第一个相关文档排名的倒数的平均值。它衡量找到第一个正确答案的速度。
nDCG@k (Normalized Discounted Cumulative Gain): 最全面和常用的指标之一，它同时考虑了检索结果的相关性等级和它们在结果列表中的排名。

第二阶段：生成性能评估 (Generation Evaluation)
这个阶段的目标是评估LLM在给定上下文后，能否生成“忠实、准确、有用”的答案。

核心指标（通常需要LLM-as-a-Judge或人工评估）：

忠实度/可溯源性 (Faithfulness / Groundedness):
- 评估问题： 生成的答案是否完全基于所提供的上下文？是否存在捏造或幻觉？
- 评估方法： 将生成的答案与上下文进行对比，检查答案中的每一句话是否都能在上下文中找到依据。
答案相关性 (Answer Relevancy):
- 评估问题： 生成的答案是否直接、清晰地回答了用户的原始问题？
- 评估方法： 评估答案与用户问题的匹配程度，看是否存在答非所问的情况。
答案正确性 (Answer Correctness):
- 评估问题： 答案中的信息是否事实准确？（这是一个更严格的指标，因为有时即使忠于原文，原文也可能是错的）
- 评估方法： 与一个“黄金标准”答案（Ground Truth）进行比较，或由领域专家进行事实核查。

自动化评估框架：
像 RAGAS, ARES, TruLens 这样的开源框架，它们使用LLM-as-a-Judge的思想，将上述的Faithfulness, Relevancy等指标自动化计算出来，极大地提高了评估效率。例如，RAGAS会生成问题、答案，并自动检查答案是否忠实于上下文。

036 · 难 · 在什么场景下，你会选择使用图数据库或知识图谱来增强或替代传统的向量数据库检索？

来源：Hello-Agents Extra01

我会选择使用图数据库或知识图谱（Knowledge Graph, KG）来增强或替代传统向量数据库，主要是在处理高度关联、结构化的数据以及需要进行复杂关系推理的场景下。

向量数据库擅长的是语义相似度的模糊匹配，而知识图谱擅长的是实体与关系的精确查询。

核心应用场景：

需要多跳推理（Multi-hop Reasoning）的复杂问题：

场景描述： 当用户的问题无法通过单个文档或事实来回答，而需要沿着实体之间的关系链进行多次“跳转”才能找到答案时。
举例：
- “Llama 2 的作者所在的公司的CEO是谁？”
  - 这是一个三跳查询：Llama 2 -> 作者 -> Meta -> CEO
- “和我正在处理的这个客户（A公司）在同一个行业、并且使用了我们产品B的成功案例有哪些？”
  - A公司 -> 所属行业 -> 同行业的其他公司 -> 使用了产品B的公司
为什么用KG： 这类问题用向量检索几乎无法完成，但对于知识图谱来说，就是几次简单的图遍历查询。

当数据本身具有强结构和关联性时：

场景描述： 数据中包含大量的实体（人、公司、产品、地点）和它们之间明确的关系（雇佣、投资、拥有、位于）。
举例： 金融领域的公司股权结构、欺诈检测中的资金流动网络、医疗领域的药物-基因-疾病关系网络、供应链管理。
为什么用KG： 将这些数据建成知识图谱，可以最大化地利用其结构信息。例如，可以快速找到一个公司的所有子公司，或者发现两个看似无关的人之间的隐藏联系。

需要提供高度可解释性的答案时：

场景描述： 在一些严肃的应用（如金融风控、医疗诊断）中，不仅需要给出答案，还需要清晰地解释答案是如何得出的。
举例： “为什么将这个交易标记为高风险？” -> “因为交易方A是B公司的子公司，而B公司在一个月前被列入了制裁名单。”
为什么用KG： 知识图谱的查询路径本身就是一种非常直观、可解释的证据链。

增强或替代？
在大多数情况下，知识图谱和向量数据库是互补增强的关系，而非完全替代。一个常见的先进RAG模式是：

混合检索： 首先用LLM分析用户问题。
如果问题涉及复杂关系，则先查询知识图谱，找到核心的实体和事实。
然后，将这些从图谱中检索到的结构化信息，作为上下文，或者用来构建更精确的查询，再去向量数据库中检索相关的非结构化文本，以获得更详细的解释和背景。
最后，将两方面的信息汇总给LLM生成答案。

037 · 难 · 传统的 RAG 流程是“先检索后生成”，你是否了解一些更复杂的 RAG 范式，比如在生成过程中进行多次检索或自适应检索？

来源：Hello-Agents Extra01

是的，传统的“先检索后生成”（Retrieve-then-Read）范式虽然经典，但比较刻板。为了应对更复杂的问题和提升答案质量，研究界已经提出了多种更动态、更智能的RAG范式。

1. 迭代式检索 (Iterative Retrieval) - 例如 Self-RAG, Corrective-RAG

核心思想： 将RAG从一个单向的流水线，变成一个循环、自我修正的过程。
工作流程：

首次检索与生成： 像传统RAG一样，进行检索并生成一个初步的答案。
反思与评估（Reflection）： LLM会对初步生成的答案和检索到的上下文进行“反思”。它会评估：当前的信息是否足够支撑答案？答案是否还有不确定或缺失的部分？
二次检索： 如果认为信息不足，LLM会主动生成一个新的、更具针对性的查询，进行新一轮的检索。例如，如果初步答案是“A公司的CEO是张三”，模型可能会反思“这个信息是否最新？”，然后生成一个新的查询“A公司2025年的CEO是谁？”
整合与精炼： LLM会整合新旧检索到的所有信息，生成一个更完善、更准确的最终答案。

2. 自适应检索 (Adaptive Retrieval) - 例如 FLARE, Self-Ask

核心思想： 不在生成前一次性检索所有信息，而是在生成过程中“按需”检索，实现“即时”（just-in-time）的信息获取。
工作流程：

开始生成： LLM根据问题开始直接生成答案。
预测不确定性： 它会一边生成，一边预测接下来的内容。当它预测到即将生成一个事实性信息（如人名、日期、地点），但对此不确定（表现为下一个词的概率分布很平坦）时，它会暂停生成。
主动提问与检索： 在暂停处，LLM会插入一个特殊的占位符（如 [SEARCH]），并主动提出一个需要查询的问题（例如，“法国的首都是哪里？”）。
获取信息并继续： 系统执行这个查询，将检索到的答案（“巴黎”）填入，然后LLM基于这个新信息继续向下生成。

优势： 这种方法非常高效，只在需要时才进行检索，避免了预先检索大量无关信息。

3. 多源数据RAG (Multi-Source RAG)

核心思想： 让Agent能够智能地从多种不同类型的数据源中进行检索和整合。
工作流程： Agent首先对问题进行分解，判断回答这个问题需要哪些信息。然后，它可能会决定：
从向量数据库中检索相关的非结构化文档。
从知识图谱中查询结构化的实体关系。
调用SQL数据库来获取精确的统计数据。
甚至调用搜索引擎API来获取实时信息。
最后，Agent会将从不同来源获取的所有信息进行综合，生成一个全面的答案。这本质上是一种Agent驱动的RAG。

038 · 难 · RAG 系统在实际部署中可能面临哪些挑战？

来源：Hello-Agents Extra01

将一个RAG原型系统部署到生产环境中，会面临一系列从数据到模型、再到工程和运维的实际挑战。

数据处理与维护的复杂性 (Data Pipeline Complexity):

分块策略的泛化性： 一个在PDF上效果很好的分块策略，可能在处理HTML或JSON数据时效果很差。为异构数据源设计和维护一套鲁棒的分块策略非常困难。
知识库的实时更新： 如何高效地保持向量索引与源数据的同步？当源文档被修改或删除时，需要有可靠的机制来更新或废弃对应的向量，这涉及到复杂的ETL（Extract, Transform, Load）流程。

性能瓶颈：延迟与成本 (Performance Bottlenecks: Latency & Cost):

延迟： RAG的“检索+生成”两步天然比直接调用LLM要慢。在实时交互场景下，检索和LLM生成的延迟都必须被极致优化。
成本：
- 计算成本： 大规模文档的嵌入、向量数据库的运行、LLM的API调用，都是持续的成本支出。
- 存储成本： 向量索引本身会占用大量的存储空间，尤其是高维度的嵌入。

端到端的评估与监控 (End-to-End Evaluation & Monitoring):

评估困难： 在生产环境中，很难有带标准答案的数据集。如何有效地评估线上RAG系统的表现（如检索质量、答案忠实度）是一个巨大挑战。
性能衰退监控： 如何发现并诊断问题？是检索模块的性能下降了（例如，因为数据分布变化），还是生成模块开始产生更多幻觉？需要建立一套完善的监控和报警系统。

处理“无答案”和“上下文外”问题 (Handling "No Answer" and "Out-of-Context" Questions):

挑战： 当知识库中不包含用户所提问题的答案时，系统很容易会基于不相关的检索结果强行生成一个错误的、具有误导性的答案。
解决方案： 系统需要具备判断检索结果相关性的能力。如果判断所有检索到的内容都与问题无关，它应该拒绝回答或明确告知用户“根据现有资料无法回答此问题”，而不是胡乱作答。

安全与隐私 (Security & Privacy):

访问控制： 在企业环境中，不同的用户对不同的文档有不同的访问权限。RAG系统必须能够集成这套权限体系，确保用户只能检索到他们有权查看的文档内容。
提示注入： 恶意用户可能会在查询中嵌入恶意指令，或者被索引的文档本身可能包含恶意内容，这些都可能用来攻击或操纵RAG系统。

039 · 中 · 了解搜索系统吗？和RAG有什么区别？

来源：Hello-Agents Extra01

是的，我了解搜索系统。搜索系统和RAG系统关系紧密，但它们的目标和最终产出有本质的区别。可以说，RAG系统是构建在搜索系统之上的一个更高级的应用。

搜索系统 (Search System) - 例如 Google Search, Elasticsearch

核心目标： 信息检索（Information Retrieval）。它的任务是，根据用户的查询，从一个大规模的文档集合中，找到并返回一个排序好的文档列表（a ranked list of documents）。
最终产出： “源”。它提供的是“可能包含答案的原材料”，用户需要自己去点击链接、阅读文档、并从中自己总结出答案。
核心技术： 索引技术（如倒排索引）、排序算法（如BM25, PageRank, TF-IDF）、查询理解和扩展。

RAG系统 (Retrieval-Augmented Generation System)

核心目标： 问题回答（Question Answering）。它的任务是，根据用户的查询，直接提供一个精准的、对话式的、综合性的自然语言答案。
最终产出： “答案”。它利用检索到的“源”作为事实依据，但最终交付的是一个经过综合、提炼和总结后的成品。
核心技术： 它包含了一个搜索系统作为其“检索”模块，但更关键的是，它增加了一个大型语言模型（LLM）作为其“生成/合成”模块。

最关键的区别：

特征	搜索系统	RAG系统
任务	找文档 (Find Documents)	给答案 (Give Answers)
输出	文档列表 (List of sources)	自然语言答案 (Synthesized answer)
用户角色	用户是主动的，需要自己阅读和总结	用户是被动的，直接获得成品答案
核心组件	索引器 + 排序器	[索引器 + 排序器] + 生成器(LLM)

一个简单的比喻：

搜索系统就像一个图书馆的图书管理员。你问他“新加坡的历史”，他会告诉你：“关于这个主题，3楼A区的第5、6、8本书，还有4楼C区的期刊都很有用，你自己去看看吧。”
RAG系统就像一个历史学专家。你问他同样的问题，他会去图书馆查阅那些书籍和期刊，然后直接告诉你：“新加坡的历史可以概括为以下几个关键时期......，这些信息主要参考了《新加坡史》和《近代东南亚》这几本书。”

040 · 中 · 知道或者使用过哪些开源RAG框架比如Ragflow？如何选择合适场景？

来源：Hello-Agents Extra01

是的，我了解并关注着多个开源RAG框架和平台。除了最广为人知的、作为基础工具库的 LangChain 和 LlamaIndex 之外，还涌现出了一批更专注于提供端到端RAG解决方案的平台，其中 RAGFlow 就是一个很有代表性的例子。其他类似的框架还包括 Haystack, DSPy 等。

对RAGFlow的理解：
RAGFlow与LangChain/LlamaIndex这类“代码库”形态的框架不同，它更像一个 “开箱即用”的、对业务人员更友好的RAG应用平台。它的特点是：

自动化与可视化： RAGFlow试图将RAG流水线中许多复杂的、需要编码和经验调优的步骤自动化。例如，它提供了基于深度学习的、“智能”的文本分块方法，而不是让用户手动设置chunk_size。它通常还提供一个GUI界面，让用户可以方便地上传文档、测试效果、查看引用来源。
端到端整合： 它提供了一个相对完整的解决方案，从数据接入、处理、索引到最终的应用接口，都整合在一个系统里。
为非专家设计： 它的目标用户不仅是开发者，也包括了希望快速搭建和验证RAG应用的业务分析师或产品经理。

如何选择合适场景？

选择哪个框架主要取决于项目的需求、团队的技能和对定制化的要求。

选择 LangChain / LlamaIndex 的场景：

高度定制化需求： 当你需要对RAG流水线的每一个环节（例如，自定义分块逻辑、实现复杂的混合检索策略、集成公司内部的特定工具）进行深度控制和定制时。
作为底层库集成： 当你不是要构建一个独立的RAG应用，而是想把RAG能力作为一部分，嵌入到一个更大的、复杂的软件系统中时。
开发者为核心的团队： 当你的团队主要是由熟悉Python和AI开发的工程师组成，他们乐于从零开始、灵活地构建和优化系统。
一句话总结： 选择它们是为了“灵活性”和“控制力”。

选择 RAGFlow / Haystack 这类平台的场景：

快速原型验证（Rapid Prototyping）： 当你想在几天内快速搭建一个高质量的RAG原型，来验证一个业务想法的可行性时。
追求最佳实践（Best Practices Out-of-the-Box）： 当你希望直接利用领域内已经验证过的最佳实践（如先进的分块和索引技术），而不是自己去重新实现和调试时。
技术团队规模有限或业务人员主导： 当团队希望更多地关注业务逻辑，而不是底层AI技术的复杂实现时。
一句话总结： 选择它们是为了“效率”和“易用性”。

我的选择策略：
在项目初期，如果需要快速看到效果，我会考虑使用RAGFlow这样的平台来搭建一个基线（Baseline）。在验证了业务价值后，如果发现平台的标准化流程无法满足我们更深度的性能优化或业务逻辑定制需求，我可能会考虑使用LangChain或LlamaIndex，将RAGFlow中验证过的有效模块，用代码进行更精细化的重构和实现。

041 · 中 · 为什么采用多路检索而不是单一向量检索？

来源：ai-agent-interview-guide

向量检索吃语义，吃不了精确编号。工单号这类字符串在纯 embedding 里经常召不回。

三路一起走，每路 top_k=20：

通道	引擎	擅长
语义	Milvus	概念问题
关键词	Elasticsearch BM25	编号、代码、精确词
关系	Neo4j	「谁负责哪个项目」

融合用 RRF：score = Σ 1/(k + rank_i)，k=60。只看排名，不看各路分数的量纲。意图路由决定优先开哪一路：含编号走关键词，概念走向量，实体关系开图谱。

源笔记的结果：Precision@5 从 72% 到 89%，Recall@20 从 65% 到 93%，编号类命中从 30% 到 98%。

042 · 中 · 为什么选择 Milvus 而不是其他向量数据库？

来源：ai-agent-interview-guide

先排除不适合企业内网的选项。FAISS 是单机库，没有分布式和高可用。Chroma 偏轻量。Pinecone 全托管，数据要出域，合规过不了。

剩下 Milvus、Qdrant、Weaviate。面试按四件事比：千万级 QPS、计算存储是否分离、索引种类、能不能做标量过滤加向量搜索。Milvus 支持 IVF_FLAT、IVF_SQ8、HNSW、DiskANN，2.x 能做「按部门过滤再语义搜」，也有 LangChain / LlamaIndex 集成，并且是 LF AI & Data 毕业项目。

源笔记在约 200 万文档上的 POC：Milvus P99 约 45 毫秒、召回 98.2%、内存约 16GB；Qdrant P99 约 62 毫秒、召回 97.8%、内存约 14GB。选 Milvus 是因为延迟和水平扩展，不是因为内存最小。线上从 200 万长到 800 万，三节点，P99 维持在 50 毫秒以内。

043 · 中 · 如何处理长文档？上下文窗口不够怎么办？

来源：ai-agent-interview-guide

不要把整份文档塞进窗口。按任务选切法。

分块先按章节和段落，目标大约 512 token，允许上下浮动约 20%，相邻块重叠约 10%，避免句子被切断。递归分隔符从空行到换行再到句号。

总结类用 Map-Reduce：每块先摘要，再把摘要合起来。要扫细节（例如找出所有风险点）用 Refine：带着上一步结论读下一块。实时问答只取 rerank 后的 top 5。

源笔记称可以处理大约 50 万字；Map-Reduce 相对人工总结约 88%；实时问答的检索加生成压在 3 秒内。长文的失败通常是切坏了，不是模型窗口数字不够。

选型先排除单机的 FAISS、偏轻量的 Chroma，以及数据必须出域的 Pinecone。Milvus、Qdrant、Weaviate 里，Milvus 的点是千万级 QPS、计算和存储分离、IVF / HNSW / DiskANN 都能选，以及标量过滤加向量搜索。大约 200 万文档的对照：Milvus P99 约 45 毫秒、召回 98.2%；Qdrant P99 约 62 毫秒、召回 97.8%。选它是为了延迟和扩容，不是为了内存最小。

分块质量直接决定召回。

默认是递归字符分块。分隔符从粗到细：空行、换行、句号、逗号、空格。chunk_size 约 512 token，重叠约 50 token。

高质量场景改语义分块：先给句子做 embedding，相邻句余弦相似度低于约 0.7 就切开，保证一块里是一件事。

结构不能切碎：Markdown 按标题层级，代码按函数或类，表格整表成块并带上上下文描述。

每块要带文档 ID、标题、章节路径、页码、位置，检索时才能按文档过滤。策略要用自建评估集比命中率，不能凭长度好看。源笔记里语义分块比固定长度高约 12 个点，技术文档上结构化分块高约 18 个点。

045 · 中 · 文档解析支持哪些格式？表格和图片怎么处理？

来源：ai-agent-interview-guide

格式	工具	要保住的结构
PDF	PyMuPDF + pdfplumber	正文、表格、图片分区
Word	python-docx	标题层级
Excel	openpyxl	每个 sheet 分开
PPT	python-pptx	按页
HTML	BeautifulSoup	去掉标签、留下层级
Markdown	markdown-it	标题层级

小表（大约 10×10 以内）转成 Markdown，整表一块。大表写成「行列、列名、自然语言摘要」。合并单元格交给版面检测，不要按纯文本切。表格块附上所在章节标题和前后段落。

图片里的字用 PaddleOCR。流程图、架构图用多模态模型写成描述，描述进向量库，原图 URL 留着溯源。解析器改动要用固定的标准解析集回归，再加人工抽检。源笔记覆盖约 98% 企业文档，表格提取约 91%，OCR 约 94%。

046 · 中 · 重排序是怎么做的？用什么模型？

来源：ai-agent-interview-guide

多路检索回来大约 30 到 60 条，向量分和 BM25 分都还太粗，要 cross-encoder 看 query 和 chunk 的配对。

候选里 BGE-Reranker-v2-M3 被选中：中英都强，大约 568MB，能本地部署。Cohere Rerank 效果好但多一次 API、多一截延迟和费用。ms-marco MiniLM 英文行、中文不行。

流程：去重、打分、取 top 5。去重用 MinHash，相似度高于约 0.9 当重复。分数大约 ≥ 0.7 直接用，0.4 到 0.7 当补充，低于 0.4 丢掉。全部低于 0.4 就明确说知识库里没有，不要硬答。

GPU 上 batch 约 40 条，大约 120 毫秒。极低延迟的路径可以跳过 rerank，用召回换时间。源笔记 Precision@5 从 78% 到 92%，NDCG@5 从 0.72 到 0.89。

047 · 中 · RRF 融合排序的公式是什么？权重怎么调？

来源：ai-agent-interview-guide

RRF(d) = Σ 1 / (k + rank_i(d))。rank 从 1 起，k 默认 60。文档在某路没出现，那一路就不贡献分。

不用原始分数加权，是因为余弦相似度在 0 到 1，BM25 的范围不固定，加在一起没有意义。RRF 只看名次。k 越大，名次差距越被抹平；k 越小，第一名优势越大。60 是常用起点。

加权形式是 Σ w_i / (k + rank_i)。默认权重：向量 0.6、关键词 0.3、图谱 0.1。在标注集（源笔记约 500 条）上网格搜索，目标 NDCG@5。加权比等权大约高 3.2 个点，比纯向量的 Precision@5 大约高 17 个点。

048 · 中 · 嵌入模型用什么？维度多少？怎么选的？

来源：ai-agent-interview-guide

模型	维度	取舍
BGE-M3	1024	中文和跨语言强，可本地部署，最终选择
text-embedding-3-large	3072	效果好，API，维度大
BGE-large-zh	1024	中文强，多语言弱于 M3
m3e-large	1024	中文可用，排名靠后
Cohere embed-v3	1024	API，数据出域

内部大约 300 条中文 query-doc 上，BGE-M3 的 Recall@10 约 94.3%，比 text-embedding-3-large 高约 2.1 个点。它同时有稠密、稀疏和 ColBERT 多向量。1024 维大约 4KB 一条，800 万条约 32GB。

推理用 ONNX，T4 上单条约 15 毫秒，1000 条 batch 约 3 秒。新文档增量算，不全量重嵌。本地部署是为了数据和延迟，不是为了排行榜名次。

049 · 中 · 知识图谱是怎么构建和使用的？

来源：ai-agent-interview-guide

向量回答不了「张三负责哪些项目」。图谱补的是关系，不是再做一路语义搜索。

构建：LLM 抽实体和关系，schema 先定死。节点如人、产品、部门、项目、文档；关系如管理、属于、依赖、撰写、相关。写入 Neo4j。置信度低于约 0.8 进人工队列，避免错边污染查询。

查询：意图判断要不要走图谱，再生成 Cypher，例如某人经 MANAGES 连到项目。结果和向量结果一起融合后送给模型。不要让模型对着全图自由发挥。

源笔记的规模大约 5 万实体、12 万关系。关系类准确率从纯向量约 45% 到约 87%。

050 · 中 · Embedding 计算是怎么优化的？

来源：ai-agent-interview-guide

全量是吞吐问题，增量是变更检测问题。

batch_size 大约 256，数据用加载器提前准备，不让 GPU 等 CPU。文档用 MD5 判断变没变，只重算变更块，新增实时入库，不做全量重建。多卡数据并行，4 张 T4 大约 3.6 倍吞吐。存储紧张时可以用 PCA 从 1024 维降到 512，召回大约只掉 1.2%，存储少一半。这是可选的，不是默认。

源笔记 800 万块从大约 48 小时到 12 小时；日常 1000 篇新增小于 30 秒；GPU 大约 80% 以上。

051 · 中 · 检索结果不准确怎么办？

来源：ai-agent-interview-guide

先定位断在哪一环，再改参数。

用户反馈 → 复现 query → 看召回列表。关键句被切断，改分块。语义嵌入不行，换或评估 embedding。top_k 太小，先放大再靠 rerank 收回。源文档错，清洗。用户说得很口语，做 query 重写。

重写把「这个东西怎么退」收成「退货退款流程」。也可以把一个模糊问拆成多个子查询再融合。HyDE 是让模型先写一段假设答案，用这段的向量去搜，专业术语场景往往比用原句 embedding 好。召回后再做精排，并把命中块的相邻块补上。

每周把「不满意」追回检索环节，评估集要更新。源笔记重写大约加 15 个点准确率，HyDE 在术语查询大约加 22 个点。

052 · 中 · 知识库数据不一致怎么处理？

来源：ai-agent-interview-guide

三类：过时、互相矛盾、写错。

每块带创建和更新时间，排序给新文档更高权重。超过约一年标成可能过时，回答里可以带出来。多块相关时用 NLI 看是否矛盾；矛盾则优先新文档，并说明存在不同说法，不要悄悄选一句。

每周自动看链接和格式，每月抽大约 50 份人工核。用户点「回答错误」进审核，结果回写知识库。源笔记过时误导大约降 70%，矛盾检测覆盖约 80%。检索分数高不代表内容还对。

053 · 中 · RAG 和微调怎么选？

来源：ai-agent-interview-guide

	RAG	微调
知识更新	改库，不用再训	要重新训
引用	天然有来源	知识在权重里，难追溯
训练成本	不需要训模型	要数据和 GPU
延迟	多一次检索	推理路径不变
改风格和格式	做不到，只是多给材料	可以内化
数据少	仍然可用	少于大约 1000 条通常不够
失败模式	检索不到就答不出	灾难性遗忘、知识过期

知识经常变、必须溯源，用 RAG。要改说话方式、领域格式或模型本身不会的行为，用微调。常见做法是两者叠：LoRA 让模型守格式、说行话，事实仍从检索来。微调解决不了知识库昨天更新的那一页。

054 · 中 · Embedding 模型是怎么训练的？对比学习怎么做？

来源：ai-agent-interview-guide

目标是相似文本靠近、不相似文本远离。正样本是问题-答案、标题-正文这类配对。负样本是不相关文本。

InfoNCE：L = -log( exp(sim(q, k+)/τ) / Σ exp(sim(q, k_i)/τ) )。sim 是余弦，τ 是温度，分母里的 k_i 包括同 batch 的其他样本。温度低，分布更尖，难负样本更被强调。

同 batch 负样本便宜，但往往太容易。硬负样本是语义近、答案却不对的文档，挖掘它们对效果影响很大。数据来自点击日志、蕴含句对、人工相似句，也可以回译和同义替换。

BGE 这一路是先 RetroMAE 预训练，再用大规模对比学习和硬负样本微调，并加上指令，让模型知道查询前面的「检索相关段落」是什么意思。没有指令时，查询和文档的向量空间容易错位。

055 · 中 · 向量索引的原理是什么？HNSW 怎么工作？

来源：ai-agent-interview-guide

精确搜索是 O(n)，数据一大就不能每次全扫。ANN 用一点召回换速度。

索引	思路	何时用
Flat	暴力	小数据、要 100% 召回
IVF	先聚类，只搜近的桶	数据大、内存还够
HNSW	多层可导航小世界图	要高召回和低延迟
DiskANN	图主要在磁盘	内存放不下

HNSW 底层有全部点，往上每一层点数按指数变少。插入时随机决定最高出现在哪一层，每一层连大约 M 个近邻。查询从顶层入口贪心走向目标，再下一层，到底层扩大搜索。efConstruction 是建图时看多宽，ef 是查询时看多宽。M 和 ef 上去，召回和内存、延迟一起上去。

优点是召回可以到 99% 附近，查询大约对数级，能增量插入。缺点是图本身占内存，建图慢。