什么是RAG 检索增强生成？它解决了大模型的哪些问题?
RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合了信息检索和内容生成的 AI 技术架构。简单来说，就是让 AI 在回答问题之前先去查资料，基于查到的真实信息来生成答案，而不是完全依赖训练时学到的知识。
RAG 的核心工作方式是"先检索，再生成"。当用户提出问题时，系统首先从知识库中检索相关文档，然后把这些文档作为上下文提供给大模型，引导模型基于这些真实材料生成回答。这就像考试时可以翻书查资料，而不是纯靠记忆答题。
RAG 主要解决了大模型的三大痛点。第一是知识时效性问题，大模型的知识来自训练数据，往往存在时间滞后，而 RAG 可以实时获取最新信息。第二是幻觉问题，大模型有时会编造不存在的信息，RAG 通过提供真实文档作为依据，能显著减少胡编乱造。第三是知识边界问题，大模型无法访问私有数据或专业领域知识，RAG 可以连接企业内部文档、专业资料等外部知识源。
RAG的完整工作流程是怎样的？核心步骤有哪些？
RAG 的完整工作流程可以分为离线准备和在线查询两个阶段，包含四个核心步骤。
离线准备阶段（知识库构建）：
第一步是文档收集和切割。把各种格式的文档（PDF、Word、网页等）加载进来，然后切割成小块（chunk）。切割很重要，因为一次性处理整个文档效果不好，切成小块更便于精准检索。一般每块 500-1000 字符比较合适。
第二步是向量转换和存储。用 Embedding 模型把每个文档块转换成向量（一串数字），然后存入向量数据库。向量能够表示文本的语义，语义相近的文本向量也相近。这样就把文档从人类能读懂的文字变成了计算机能计算的数字。
在线查询阶段（问答生成）：
第三步是查询和检索。用户提出问题，系统同样用 Embedding 模型把问题转成向量，然后在向量数据库中搜索最相似的文档块。这个过程叫相似度检索，通常返回 Top-K 个最相关的文档。
第四步是增强和生成。把检索到的文档跟用户问题组合起来，构造一个完整的 Prompt，发给大模型。模型看到这些参考资料后，就能基于真实信息生成答案，而不是凭空想象。
RAG 中的 Embedding 向量化是什么？如何工作的?
Embedding（嵌入或向量化）是把文本转换成数字向量的技术，是 RAG 系统的核心基础。简单理解，就是给每段文字分配一个"身份证号"，这个号码是一串数字（向量），能代表文字的含义。
Embedding 的工作原理是通过深度学习模型，把文本映射到高维向量空间。比如一段话可能被转换成一个 1536 维的向量，也就是 1536 个数字组成的数组。神奇的地方在于，语义相近的文本，它们的向量在空间中的距离也很近。比如"猫"和"小猫"的向量会很接近，而"猫"和"汽车"的向量就离得很远。
在 RAG 系统中，Embedding 承担着关键角色。离线阶段，所有文档块都要经过 Embedding 模型转换成向量存储。在线阶段，用户的问题也要转成向量。然后通过计算问题向量和文档向量的相似度，就能找出最相关的文档。这个过程比传统的关键词匹配更智能，因为它理解语义，而不只是匹配字面。
python
from openai import OpenAI
client = OpenAI()
# 文本转向量
text = "RAG 是检索增强生成技术"
response = client.embeddings.create(
model="text-embedding-ada-002",
input=text
)
vector = response.data[0].embedding
# 得到一个 1536 维的向量，如：[0.023, -0.015, 0.041, ...]
print(f"向量维度：{len(vector)}")RAG为什么需要向量数据库？它和传统数据库有什么区别?
RAG 需要向量数据库的核心原因是高效的相似度检索。向量数据库专门为存储和搜索高维向量设计，能快速找到跟查询向量最相似的向量，这正是 RAG 检索环节需要的能力。
传统数据库（如 MySQL、MongoDB）擅长精确匹配查询，比如查找"ID=123"的记录、"名字='张三'"的用户。但它们不擅长相似度搜索，无法高效地找出"跟这个向量最相似的 10 个向量"。虽然传统数据库也能存储向量，但在海量数据上做相似度计算会非常慢。
向量数据库的核心优势在于专门的索引结构。它使用 HNSW、IVF 等索引算法，能在千万甚至亿级向量中快速找到最相近的。传统数据库要遍历所有记录计算距离，O(n) 的复杂度。向量数据库通过索引，复杂度能降到 O(log n) 甚至更低。这就是为什么在 RAG 中必须用向量数据库。
RAG 和模型微调Fine-tuning 有什么区别？如何选择?
RAG 和 Fine-tuning 是两种让 AI 获取特定知识的不同路径，核心区别在于知识的存储方式和获取方式。
RAG 把知识存在外部知识库中，AI 需要时去查询。就像学生考试可以翻书，书是外部的，随时可以更新。RAG 不需要改变模型本身，只需要维护好知识库就行。实施快、成本低、更新灵活是 RAG 的最大优势。
Fine-tuning 是通过训练让模型"记住"知识，知识被编码进模型参数里。就像学生把知识背下来，成为内在能力的一部分。微调需要准备训练数据、投入计算资源、等待训练完成。实施周期长、成本高，但一旦训练好，响应速度快，而且能改变模型的行为风格。
选择建议：
如果你的知识经常更新（如新闻资讯、政策文件、产品手册），选 RAG。更新知识库比重新训练模型容易太多。如果你需要改变模型的输出风格、语气或行为模式（如企业客服的特定话术），选 Fine-tuning。如果预算和时间有限，选 RAG。如果对响应速度要求极高且知识相对固定，可以考虑 Fine-tuning。
实际项目中，两者经常结合使用。用 Fine-tuning 让模型学会特定领域的表达方式和基础知识，用 RAG 提供具体的、实时的信息。比如企业客服机器人，微调模型让它说话像客服人员，同时用 RAG 从产品文档中检索准确信息。这种组合能发挥各自优势。
RAG 中如何计算文本相似度？常见算法有哪些?
RAG 中的文本相似度计算是通过比较向量之间的距离或角度来实现的。文本已经被 Embedding 模型转换成了向量，相似度计算就变成了纯数学问题。
最常用的是余弦相似度（Cosine Similarity）。它计算两个向量之间的夹角，角度越小，相似度越高。余弦相似度的值在 -1 到 1 之间，1 表示完全相同，0 表示无关，-1 表示完全相反。余弦相似度的优点是不受向量长度影响，只看方向，这在文本相似度计算中很合适。
第二常用的是欧氏距离（Euclidean Distance）。它计算两个向量在空间中的直线距离，距离越小越相似。欧氏距离的问题是受向量长度影响，在高维空间中可能不够稳定，所以在 RAG 中用得相对少一些。
还有点积（Dot Product），它就是把两个向量对应位置的数字相乘再求和。点积越大，相似度越高。如果向量都是归一化的（长度为 1），点积和余弦相似度其实是等价的。很多向量数据库会在存储时就把向量归一化，这样用点积计算更快。
RAG系统中为什么要进行文档切割？有哪些切割策略？
RAG 系统需要文档切割的原因主要有三个。
第一是模型的上下文窗口限制。大模型一次能处理的文本长度有限，比如 4K、8K、16K token。一份完整文档可能有几万甚至几十万字，根本塞不进模型。必须切成小块，只把相关的几块传给模型。
第二是检索精度的需要。如果不切割，检索的粒度就是整篇文档。用户问一个具体问题，系统返回一整篇长文档，里面大部分内容都不相关。切成小块后，能更精准地找到包含答案的那几段，提高信息密度。
第三是向量表示的质量。一个向量要表示的内容越多，信息越复杂，向量就越难准确表达。切成小块后，每个向量只需要表达一小段内容的语义，表达更准确，检索效果也更好。
常见的切割策略有几种。按字符数切割是最简单的，比如每 500 字符一块。按段落切割，以自然段为单位，保持内容完整性。按句子切割，不破坏句子结构。更智能的是按语义切割，AI 分析内容后在语义完整的地方切分。不同类型的文档适合不同的策略。
RAG 检索中的Top-K是什么意思？K值如何确定?
Top-K 是指从所有候选文档中选出相似度最高的 K 个文档。比如 Top-5 就是返回最相关的 5 个文档块，Top-10 就是返回最相关的 10 个。K 值决定了给大模型提供多少参考资料。
K 值的设置需要平衡信息完整性和噪音控制。K 太小，比如只返回 1-2 个文档，可能信息不够完整，无法充分回答问题。K 太大，比如返回几十个文档，会包含很多不相关的内容，不仅浪费 token，还可能干扰模型判断，反而降低答案质量。
一般情况下，K 值设置在 3-10 之间比较合适。具体多少要看场景。如果问题比较简单，答案集中在少数几段，K=3 或 5 就够了。如果问题复杂，需要综合多方面信息，K 可以设到 8 或 10。如果文档切得比较细，每块信息量小，K 可以大一点。如果切得比较粗，每块信息量大，K 可以小一点。
K 值还要考虑模型的上下文窗口。假设模型窗口是 4K token，问题占 100 token，如果每个文档块平均 300 token，那 K 最多也就 10 左右，再多就塞不下了。所以 K 值跟文档块大小、模型窗口大小都有关系，要综合考虑。
如何为 RAG 系统选择合适的 Embedding 模型?（被问到类似的问题）
选择 Embedding 模型要考虑四个核心因素：语言支持、效果质量、成本和维度。
语言支持是首要考虑的。如果做中文 RAG，必须选对中文友好的模型。OpenAI 的 text-embedding-ada-002 和 text-embedding-3 系列对中文支持不错，国产模型如阿里云的 text-embedding-v4、智谱的 embedding-3、百度的 bge 系列专门针对中文优化，效果通常更好。如果是多语言场景，要选跨语言能力强的模型。
效果质量直接影响检索准确性。可以用 MTEB（Massive Text Embedding Benchmark）等基准测试的排名作为参考，但最好用自己的数据测试。准备一批典型问题和对应答案，看不同模型的检索召回率和准确率。有时候排名靠前的模型在你的场景不一定最好，要实测。
成本包括调用费用和响应时间。商业 API 如 OpenAI、阿里云都按调用次数或 token 数收费。如果数据量大、调用频繁，成本会很可观。开源模型如 bge、text2vec 可以自己部署，初期投入大但长期成本低。还要考虑响应时间，影响用户体验。
向量维度是个权衡点。维度越高，表达能力越强，但存储和计算成本也越高。OpenAI ada-002 是 1536 维，bge-large 是 1024 维，bge-base 是 768 维，bge-small 是 384 维。如果数据量不是特别大、对效果要求不是特别高，可以选维度低一点的模型降低成本。
RAG 系统如何处理PDF、Word、Markdown 等不同格式文档?
RAG 系统处理不同格式文档需要专门的文档加载器（Document Loader），把各种格式转换成统一的文本格式，然后再进行后续的切割和向量化。
PDF 文档是最常见也最麻烦的。PDF 有两种类型：文字型和扫描型。文字型 PDF 可以直接提取文本，用 PyPDF2、pdfplumber 等库就行。扫描型 PDF 本质是图片，需要先 OCR（光学字符识别）转成文字，可以用 Tesseract、PaddleOCR 等工具。PDF 的难点在于保留格式和结构，比如表格、多栏排版，提取时容易乱。
Word 文档相对简单，用 python-docx 库可以直接读取 .docx 格式。老的 .doc 格式需要 win32com 或者先转成 docx。Word 的优点是结构清晰，段落、标题、表格都有明确标记，提取相对准确。
Markdown 文档最简单，就是纯文本，直接读取就行。而且 Markdown 的标题层级结构很清晰，可以很方便地按标题切割文档。很多技术文档都是 Markdown 格式，处理起来非常友好。
HTML 网页需要解析 HTML 结构，提取正文内容。BeautifulSoup、trafilatura 等库可以帮助清理 HTML 标签，提取干净的文本。难点是区分正文和广告、导航等无关内容，需要一定的清洗逻辑。
RAG 中文档切割的 chunk_size 和 overlap 应该如何设置?
chunk_size（块大小）和 chunk_overlap（重叠大小）是文档切割的两个核心参数，它们直接影响 RAG 系统的检索效果和成本。
chunk_size 决定每个文档块包含多少字符。常见的设置范围是 500-2000 字符。设置 500-800 字符适合信息密度高、结构清晰的文档，比如技术文档、FAQ。设置 1000-1500 字符适合大多数场景，是个稳妥的选择。设置 1500-2000 字符适合需要更多上下文的内容，比如故事叙述、学术论文。
chunk_overlap 决定相邻块之间重叠多少字符，目的是避免关键信息被切在边界上。通常设置为 chunk_size 的 10%-20%。如果 chunk_size=1000，overlap 设置 100-200 比较合适。overlap 太小，起不到保护边界信息的作用。overlap 太大，会造成大量冗余，增加存储和检索成本。
典型的推荐配置是 chunk_size=1000, overlap=200。这个配置对大多数中文文档都适用，如果效果不理想再根据实际情况调整。英文文档可以稍微调大一些，因为英文表达通常比中文更长。
如何构建和使用向量索引？HNSW和IVF有什么区别?
向量索引是向量数据库提升检索速度的关键技术。没有索引，检索需要遍历所有向量计算相似度，复杂度 O(n)。有了索引，复杂度可以降到 O(log n) 甚至更低，速度提升几个数量级。
构建索引的基本流程是：先把向量数据导入数据库，然后选择索引类型和参数，数据库会根据向量分布构建索引结构。索引构建完成后，检索时数据库会利用索引快速定位相似向量，而不是暴力搜索。索引需要一定的构建时间和存储空间，但换来的是查询速度的大幅提升。
HNSW（Hierarchical Navigable Small World）是当前最流行的索引方法。它构建了一个分层的图结构，每层是一个小世界网络。检索时从最顶层开始，快速缩小范围，然后逐层向下，最终在底层精确搜索。HNSW 的优点是检索速度快、准确率高，缺点是构建索引较慢、占用内存较多。适合检索频率高、对准确率要求高的场景。
IVF（Inverted File Index）先把向量聚类成多个区域，检索时先找到最可能的几个区域，然后只在这些区域内搜索。IVF 的优点是构建快、内存占用小，缺点是准确率稍低，因为目标向量可能不在被选中的区域。适合超大规模数据、对准确率要求不是特别高的场景。
什么是RAG 混合检索？如何实现向量检索和关键词检索结合?
RAG 混合检索（Hybrid Search）是指同时使用向量检索和关键词检索，然后合并结果，取两者之长。
向量检索擅长语义理解，能找到意思相近但用词不同的内容。比如用户问"如何购买"，向量检索能找到"怎么买"、"购买方法"这些语义相关的文档。但向量检索对精确匹配不敏感，查"iPhone 15"可能也返回"iPhone 14"的结果。
关键词检索擅长精确匹配，用 BM25 等算法根据词频和逆文档频率打分。查"iPhone 15"就只返回包含这个词的文档，不会混淆。但关键词检索不理解语义，查"购买"找不到"买"，查"汽车"找不到"车"。
混合检索的工作流程是：同一个查询，分别执行向量检索和关键词检索，各得到一批候选文档。然后合并两批结果，去重，重新排序。合并策略可以简单地按排名加权，也可以用专门的融合算法，如 Reciprocal Rank Fusion（RRF）。
RAG检索时相似度阈值如何设置？设置不当有什么影响?
相似度阈值是过滤检索结果的最低标准，只有相似度达到或超过阈值的文档才会被采用。阈值通常设置在 0.6-0.8 之间，具体值要根据实际数据和需求调整。
阈值设置过高（如 0.9 以上）会导致召回率低。很多相关但不是完全匹配的文档被过滤掉，系统经常检索不到足够的参考资料，模型只能基于有限信息甚至没有信息回答，答案质量下降。用户会感觉系统"什么都不知道"。
阈值设置过低（如 0.4 以下）会导致精确率低。大量不相关或弱相关的文档被纳入，给模型提供了很多噪音。模型要从一堆杂乱信息中提取有用的，容易被干扰，生成的答案可能偏离主题或包含错误信息。而且低阈值会让检索返回更多文档，增加 token 消耗和成本。
合理的阈值设置要通过实验确定。准备一批测试问题，尝试不同的阈值（如 0.5、0.6、0.7、0.8），评估每个阈值下的召回率和答案质量，找到最佳平衡点。一般来说，0.7 是个不错的起点，然后根据实际效果微调。
阈值也可以动态调整。如果检索到的文档数量太少（比如少于 2 个），可以自动降低阈值再试一次，确保有足够的参考资料。如果检索到太多文档（比如超过 10 个），可以提高阈值或者只取分数最高的前几个，控制噪音。
RAG系统如何利用元数据过滤提升检索精度？
元数据（Metadata）是文档的附加信息，比如文档类型、创建日期、作者、部门、标签等。在 RAG 系统中，元数据过滤是指在向量检索的基础上，增加元数据条件限制，让检索结果更精准。
元数据过滤的工作方式是组合查询。用户提问时，除了语义检索，还可以指定元数据条件。比如"查找 2024 年的技术文档"，系统会在向量检索的同时，只返回 year=2024 且 type=技术文档的结果。这样能大幅减少不相关文档，提高精确率。
常见的元数据包括时间维度（创建日期、更新日期），分类维度（文档类型、部门、产品线），内容维度（作者、语言、标签），权限维度（公开/私有、访问级别）。设计元数据时要考虑实际检索需求，不是越多越好，要实用。
元数据的提取可以是自动或手动。文件名、创建时间、格式等可以自动提取。文档类型、主题标签等可能需要人工标注或 AI 辅助提取。提取质量直接影响过滤效果，要做好质量控制。
RAG中如何设计Prompt来有效利用检索到的文档?
RAG 中的 Prompt 设计要让大模型明确知道：这些是参考资料，要基于这些资料回答，不要编造。一个好的 RAG Prompt 通常包含三部分：系统指令、检索文档、用户问题。
系统指令部分要明确告诉模型角色和行为准则。比如"你是一个知识助手，请基于提供的文档回答问题。如果文档中没有相关信息，请明确说明，不要编造答案。"这样的指令能减少幻觉，让模型老实回答。
检索文档部分要有清晰的格式和边界。用分隔符（如 ###、--- 或 XML 标签）把文档括起来，让模型清楚哪部分是参考资料。可以给每个文档编号，方便模型引用。如果文档有标题或来源，也要包含进去，这些信息有助于模型理解和引用。
用户问题部分要放在最后，直接明了。有时候还可以加一些引导，比如"请结合上述文档回答：{问题}"、"请引用文档中的具体内容回答：{问题}"。这种引导能让模型更好地利用文档。
如何处理RAG检索不到相关文档的情况?
RAG 检索不到相关文档是常见情况，要设计合理的降级策略，而不是让系统"卡住"或返回错误信息。
第一种策略是诚实告知。当相似度最高的文档都低于阈值，说明知识库中确实没有相关信息。这时候应该明确告诉用户"抱歉，我在知识库中没有找到相关信息"。不要让模型凭空编造答案，这会导致幻觉问题。诚实虽然不够智能，但至少不会误导用户。
第二种策略是查询改写重试。用户的问法可能不够准确或完整，导致检索失败。可以用 AI 改写查询，换个角度或补充信息后重新检索。比如用户问"它怎么用"，改写成"该产品的使用方法"，可能就能检索到了。通常可以尝试 1-2 次改写，避免无限重试。
第三种策略是降低阈值扩大范围。如果设置阈值 0.7 没找到，可以降到 0.6 或 0.5 再试一次，可能能找到弱相关的文档。虽然不是完美匹配，但总比完全没有信息好。当然要在 Prompt 中说明"找到的可能只是部分相关的信息"。
第四种策略是提供替代方案。告诉用户"没找到相关信息，但您可以尝试..."，给出一些建议的搜索词或相关主题。或者提供人工服务入口，让用户联系客服。这种主动引导比简单说"不知道"用户体验更好。
RAG系统如何标注信息来源和提供引用？
RAG 系统标注信息来源是为了增加答案可信度，让用户能核查信息的准确性。实现引用主要通过三个环节：元数据保存、Prompt 引导、前端展示。
元数据保存阶段，在向量化文档时，要保存文档的来源信息。包括文件名、URL、页码、章节、作者、日期等。这些元数据跟向量一起存储，检索时会连同文档内容一起返回。元数据越详细，引用就越准确。
Prompt 引导阶段，在构造 Prompt 时要明确要求模型标注来源。比如"请在使用文档信息时，用 [文档1] 这样的方式标注"或"请在答案末尾列出参考来源"。还要在 Prompt 中把文档编号或标题清楚地标出来，方便模型引用。
前端展示阶段，要把引用转换成用户友好的形式。可以在答案中高亮引用标记，点击后显示原文。可以在答案下方列出所有引用的文档，提供查看全文的链接。可以用脚注或气泡的方式展示引用。好的展示方式让用户方便核查又不影响阅读。
RAG中如何实现向量数据库的增量更新？
增量更新是指只处理新增和变化的文档，而不是每次都重新处理整个知识库。这对于大规模文档库至关重要，能大幅节省时间和成本。
实现增量更新需要文档版本管理。给每个文档分配唯一 ID，记录它的版本号或最后修改时间。系统定期扫描文档库，比对每个文档的当前状态和数据库中的记录。如果是新文档，就添加。如果是修改过的文档，就更新。如果文档被删除，就从数据库中移除。
新增文档的处理最简单：加载 → 切割 → 向量化 → 存入数据库。要注意的是给文档分配 ID，记录元数据，确保能跟源文件关联起来。
修改文档的处理稍复杂：先根据文档 ID 删除数据库中的旧记录（包括所有向量 chunks），然后按新增文档的流程重新处理。有些系统支持更智能的更新，只更新变化的部分，但实现复杂，通常整个文档重新处理更简单可靠。
删除文档时要清理干净，不只是标记删除，要真正从向量数据库中移除所有相关记录，避免脏数据影响检索。要记录删除日志，以防误删需要恢复。
如何为RAG 项目选择向量数据库？Milvus、Pinecone、Chroma 怎么选?
选择向量数据库要考虑数据规模、性能需求、部署方式、成本预算四个核心因素。
Chroma 是最适合入门和小型项目的选择。它是轻量级的，可以嵌入式运行，不需要单独部署服务，几行代码就能跑起来。适合学习 RAG、做原型验证、个人项目。数据量在十万级以下用 Chroma 很合适。缺点是性能和扩展性有限，不适合生产环境的大规模应用。
Pinecone 是托管式云服务，开箱即用，不需要自己运维。性能好、稳定性高，支持分布式，能处理亿级数据。特别适合不想自己搭建基础设施的团队，或者初创公司想快速上线产品。缺点是付费的，而且数据存在第三方，有些企业可能不接受。如果预算充足且对运维能力要求不高，Pinecone 是很好的选择。
Milvus 是开源的专业向量数据库，功能强大，支持分布式部署，能处理十亿级甚至更大规模的数据。适合对性能要求高、数据量大、需要私有化部署的项目。国内很多大厂在用 Milvus。缺点是需要自己部署和运维，对技术团队有一定要求。如果是中大型企业、对数据安全要求高，Milvus 是优选。
还有一些其他选择。PGVector 是 PostgreSQL 的向量扩展，如果项目已经在用 PostgreSQL，加个扩展就能用，不需要单独的向量数据库。Weaviate 也是开源的，功能跟 Milvus 类似。Qdrant 用 Rust 写的，性能也不错。可以根据团队技术栈和偏好选择。
RAG 中的查询重写Query Rewriting 是什么？如何优化检索效果?
查询重写（Query Rewriting）是 RAG 优化的重要技术，通过改写用户的原始问题来提升检索效果。核心思想是用户的提问可能不够清晰、完整或准确，导致检索效果不佳，通过 AI 重写查询，能显著提高检索的召回率和精确率。
查询重写主要解决几类问题。第一是指代不明，用户说"它怎么用"，这个"它"是什么？需要结合上下文补充完整。第二是表述不准确，用户可能用口语化或模糊的描述，需要转换成更规范的表达。第三是信息不完整，用户问题太简略，需要补充关键信息。第四是多个意图混杂，一个问题包含多个子问题，需要拆分成多个查询。
实现查询重写通常用大模型。设计一个专门的 Prompt，让模型分析用户问题，生成改写后的查询。改写策略可以是单次改写，也可以是生成多个改写版本。单次改写简单直接，多次改写能从不同角度检索，提高覆盖面。
RAG为什么需要重排序Reranking？如何实现?
重排序（Reranking）是在初次检索之后，用更精确的模型对候选文档重新打分排序，目的是提高最终给大模型的文档质量。简单说就是"粗筛 + 精排"两阶段策略。
为什么需要重排序？因为初次检索通常是在海量文档中快速召回，追求召回率，可能会引入一些不够相关的文档。比如用向量检索 Top-20，这 20 个文档相关程度不一样，如果直接全部给模型，会有噪音干扰。重排序用更精确的方法重新评分，选出最相关的 Top-5，质量更有保证。
重排序模型跟 Embedding 模型不同。Embedding 模型要快速处理海量文档，做的是单塔编码，query 和 document 分别编码。重排序模型可以用双塔或交叉编码，把 query 和 document 一起送入模型，能捕捉更细致的相关性，但速度慢，所以只在候选集上使用。
实现重排序的典型流程是：第一阶段用向量检索召回 Top-20 或 Top-50，第二阶段用重排序模型对这些候选重新打分，选出分数最高的 Top-5 给大模型。这种两阶段策略既保证了召回，又提高了精确率。
重排序流程：
如何评估RAG系统的效果？检索和生成分别看哪些指标?
评估 RAG 系统要分别看检索环节和生成环节，因为两个环节的评估方法和指标不同。
检索环节的评估指标：
召回率（Recall）是最重要的指标，指相关文档中有多少被检索到了。比如知识库中有 10 个跟问题相关的文档，检索到了 7 个，召回率就是 70%。召回率越高越好，但要避免过度召回引入噪音。
精确率（Precision）指检索结果中有多少是真正相关的。比如返回了 10 个文档，其中 8 个相关，精确率就是 80%。精确率越高，噪音越少，但过分追求精确率可能漏掉一些相关文档。
MRR（Mean Reciprocal Rank，平均倒数排名）关注相关文档的排名。如果第一个结果就相关，MRR=1。如果第二个才相关，MRR=0.5。MRR 越高，说明相关文档排名越靠前，用户更容易找到。
生成环节的评估指标：
事实准确性是核心，答案中的陈述是否正确、是否基于文档。可以人工评估，也可以用另一个大模型对比答案和文档来自动评分。
答案完整性指是否充分回答了问题，有没有遗漏关键信息。不完整的答案即使部分正确，用户体验也不好。
上下文相关性指答案是否真的基于检索到的文档，还是模型自己编的。可以检查答案中的信息是否能在文档中找到对应。
引用准确性指答案标注的来源是否正确。如果说信息来自文档A，要验证文档A中确实有这个信息。
如何减少RAG系统的幻觉问题？有哪些实用方法?
虽然 RAG 本身就是为了减少幻觉而设计的，但不能完全消除。减少 RAG 系统的幻觉需要在多个环节采取措施。
首先是 Prompt 层面的约束。在系统提示词中明确要求"只基于提供的文档回答"、"如果文档中没有相关信息，明确说不知道，不要编造"、"必须能在文档中找到依据"。这些强约束能让模型更谨慎，遇到不确定的信息不会强行生成。
其次是提高检索质量。如果检索到的文档本身就不相关或质量不高，模型也容易产生幻觉。通过优化检索策略、使用重排序、设置合理的相似度阈值，确保给模型的都是高质量参考资料。检索是源头，源头质量好，幻觉自然少。
第三是要求标注来源。在 Prompt 中要求模型标明每条信息的出处，如"根据文档2，..."。这种要求会让模型更注重文档依据，不太敢随意发挥。而且标注来源方便人工核查，能快速发现幻觉内容。
第四是降低 temperature 参数。temperature 控制生成的随机性，值越低输出越确定。对于 RAG 这种事实性任务，建议设置 temperature=0 或接近 0，让模型选择最可能的输出，减少创造性发挥。虽然可能显得机械，但准确性更重要。
第五是使用验证机制。生成答案后，用另一个模型验证答案是否跟文档一致。或者设计规则检查，如答案中的数字、日期、人名是否在文档中出现。发现不一致的可以标记为"待核实"或重新生成。
RAG系统在生产环境中如何优化性能和降低成本?
RAG 系统的性能优化和成本控制需要在多个环节综合施策，没有银弹，要系统性地优化。
性能优化方面：
检索速度的优化最关键。使用高效的向量索引（如 HNSW），合理配置索引参数平衡速度和准确率。对高频查询做缓存，相同或相似的问题直接返回缓存结果。使用 GPU 加速向量计算，特别是批量检索场景。合理分片和分布式部署，水平扩展提升吞吐量。
Embedding 环节的优化也重要。文档向量化是离线的，可以用好一点的模型。查询向量化是实时的，要用快速的模型或做缓存。批量向量化比单条向量化效率高很多，文档入库时要批量处理。如果用自部署模型，可以用模型服务化和连接池提升并发能力。
生成环节可以用流式输出提升感知速度。虽然总时间不变，但用户能实时看到内容生成，体验更好。还可以异步处理非关键路径，比如日志记录、统计分析，不要阻塞主流程。
成本控制方面：
Token 消耗是最大的成本。通过文档压缩和筛选，只给模型最相关的内容，减少 Prompt 长度。使用更便宜的模型处理简单查询，复杂查询才用昂贵的模型。缓存高频查询结果，减少重复调用。设置调用额度和限流，避免异常情况导致成本失控。
Embedding 成本的控制可以用开源模型自部署。虽然初期投入大，但长期成本低。如果数据量大、调用频繁，自部署通常更划算。也可以用混合策略，离线处理用自部署，实时查询用商业 API，发挥各自优势。
向量存储成本可以通过降维和压缩优化。选择维度适中的 Embedding 模型，384 维可能比 1536 维效果略差，但存储成本低很多。使用向量量化（PQ）技术压缩向量，能节省 70%-90% 的存储空间。当然这些优化都会有一定的精度损失，要权衡。