ByteCoding

基础 列表和元组都是可以放置任意数据类型的有序集合 - 绝大多数编程语言，集合的数据类型必须一致 12l = [1, 2, 'hello', 'world']t = ('json', 22) 列表是动态的（mutable），而元组是静态的（immutable） 123456l = [1, 2, 3, 4] # mutablel[3] = 40print(l) # [1, 2, 3, 40]t = (1, 2, 3, 4) # immutable# t[3] = 40 # TypeError: 'tuple' object does not support item assignment 为元组追加新元素，只能新建元组 123t1 = (1, 2, 3, 4)t2 = t1 + (5,)print(t2) # (1, 2, 3, 4, 5) 为列表追加新元素，可以直接追加到列表末尾 123l = [1, 2, 3, 4]l.append(5)print(l) # [1, 2, 3, 4, 5...

向量检索 信息片段之间的连接能力有限 RAG 在跨越多个信息片段以获取综合见解时表现不足 当要回答一个复杂问题时，必须要通过共享属性在不同信息之间建立联系 RAG 无法有效捕捉这些关系 限制了 RAG 在处理需要多跳推理或整合多源数据的复杂查询时的能力 归纳总结能力不足 在处理大型数据集或长文档时，RAG 难以有效地归纳和总结复杂的语义概念 RAG 在需要全面理解和总结复杂语义信息的场景中表现不佳 GraphRAG 利用 LLM 生成的知识图谱来改进 RAG 的检索部分 GraphRAG 利用结构化的实体和关系信息，使得检索过程更加精准和全面 GraphRAG 在处理多跳问题和复杂文档分析时表现出色 GraphRAG 在处理复杂信息处理任务时，显著提升问答性能，提供比 RAG 更为准确和全面的答案 GraphRAG 通过知识图谱有效地连接不同的信息片段 不仅能够提供准确答案，还能展示答案之间的内在联系，提供更丰富和有价值的结果 GraphRAG 先利用知识图谱，关联查询的实体和关系从与知识图谱实体直接相关的文档中检索片段，提供一个更全面、指标化、高信息密度的总结 主...

演进 Naive RAG -> Advanced RAG -> Modular RAG 三个范式之间具有继承与发展的关系 Advanced RAG 是 Modular RAG 的一种特例形式 Naive RAG 是 Advanced RAG 的基础特例 RAG 技术不断演进，以适应更复杂的任务和场景需求 Naive RAG Naive RAG 是最基础的形式，依赖核心的索引和检索策略来增强生成模型的输出 Naive RAG 适用于一些基础任务和产品 MVP 阶段 Advanced RAG 通过增加检索前、检索中以及检索后的优化策略，提高检索的准确性和生成的关联性 - 适用于复杂任务 Advanced RAG 通过优化检索前、检索中、检索后的各个环节 在索引质量、检索效果以及生成内容的上下文相关性方面都取得显著提升 检索前 通过索引、分块、查询优化和内容向量化等技术手段，提高检索内容的精确性和生成内容的相关性 滑动窗口 overlap 经典的 Chunking 技术，通过在相邻的 Chunk 之间创建重叠区域，确保关键信息不会因简单的 Chunking 而丢失 在 ...

RAG 检索优化数据清洗和预处理 在 RAG 索引流程中，文档解析之后，文档切块之前，进行数据清洗和预处理 减少脏数据和噪音，提升文本的整体质量和信息密度 手段：清除冗余信息、统一格式、处理异常字符等 处理冗余的模板内容 消除文档中的额外空白和格式不一致 去除文档脚注、页眉页脚、版权信息 查询扩写 在 RAG 系统的检索步骤中，用户的查询会转换为向量后进行检索 单个向量查询只能覆盖向量空间中一个有限区域 如果查询中的嵌入向量未能包含所有关键信息，则可能检索到不相关的 Chunk 单点查询的局限性 - 限制系统在庞大文档库中的搜索范围，导致错失与查询语义相关的内容 查询扩写 通过 LLM 从原始查询语句生成多个语义相关的查询，可以覆盖向量空间中的不同区域 提高检索的全面性和准确性 扩写后的查询在被嵌入后，能够击中不同的语义区域 确保系统能够从更广泛的文档中检索到与用户需求相关的有用信息 通过查询扩写，原始问题被分解为多个子查询 每个子查询独立检索相关文档并生成相应的结果 系统将所有子查询的检索结果进行合并和重新排序 能够有效扩展用户的查询意图，确保在复杂信息库中进行更全面的文...

RAG 生成流程 经过 RAG 索引流程（外部知识的解析和向量化）和 RAG 检索流程（语义相似性的匹配及混合检索），进入到 RAG 生成流程 在 RAG 生成流程中，需要组合指令，即携带查询问题及检索到的相关信息输入的 LLM，由 LLM 理解并生成最终的回复 RAG 的本质是通过 LLM 提供外部知识来增强其理解和回答领域问题的能力 LLM 在 RAG 系统中起到了大脑的作用 在面对复杂且多样化的 RAG 任务时，LLM 的性能直接决定了系统的整体效果 提示词工程是生成流程中的另一个关键环节 通过有效的指令的设计和组合，可以帮助 LLM 更好地理解输入内容，从而生成更加精确和相关的回答 精心设计的问题提示词，往往能提升生成效果 LLM发展 RAG 目前更关注通用大模型 原理 Google 于 2017 年发布论文 Attention Is All You Need，引入了 Transformer 模型 Transformer 模型是深度学习领域的一个突破性架构，LLM 的成功得益于对 Transformer 模型的应用 与传统的 RNN（循环神经网络） 相比，Transform...

向量检索 当前主流的 RAG 检索方式主要采用向量检索，通过语义相似度来匹配 Chunk 向量检索并非万能，在某些场景下无法替代传统关键词检索的优势 当需要精准搜索的时候，向量检索的准确性就往往不如关键词检索 当用户输入的问题非常简短，语义匹配的效果可能不尽理想 关键词检索的适用场景 精确匹配 少量字符的匹配 - 不适合用向量检索 低频词汇的匹配 混合检索 结合关键词检索和语义匹配的优势 在 RAG 检索场景中，首要目标是确保最相关的结果能够出现在候选列表中 向量检索和关键词检索各具优势，混合检索通过结合多种检索技术，弥补各自不足，提供一种更加全面的搜索方案 重排序技术在检索系统中扮演着至关重要的角色 即使检索算法已经能够捕捉到所有相关的结果，重排序过程依然不可或缺 确保最符合用户意图和查询语义的结果优先展示，提升用户的搜索体验和结果的准确性 在多个数据集和多个检索任务中，混合检索和重排序的组合均取得了最佳表现 融合检索 / 多路召回 https://python.langchain.com/v0.2/api_reference/community/r...

Embedding Vector Store概述 在 AI 时代，文字、图像、语音、视频等多模态数据的复杂性显著增加 多模态数据具有非结构化和多维特征 向量表示能够有效表示语义和捕捉潜在的语义关系 促使向量数据库成为存储、检索和分析高维向量的关键工具 Qdrant / Milvus 优势 SQL vs NoSQL 传统数据库通常分为关系型（SQL）数据库和非关系型（NoSQL）数据库 存储复杂、非结构化或半结构化信息的需求，主要依赖于 NoSQL 的能力 Store Desc Note Key-Value 用于简单的数据存储，通过 Key 来快速访问数据 精准定位信息 Document 用于存储文档结构的数据，如 JSON 格式 复杂的结构化信息 Graph 用于表示和存储复杂的关系数据，常用于社交网络、推荐等场景 复杂的关系数据 Vector 用于存储和检索基于向量表示的数据，用于 AI 模型的高维度和复杂的嵌入向量 语义最相关的数据 向量数据库的核心在于能够基于向量之间的相似性，能够快速、精确地定位和检索数据 向量数据库不仅为嵌入向量提供了...

Knowledge Graph 知识图谱也称为语义网络，表示现实世界实体的网络，并说明它们之间的关系 信息通常存储在图形数据库中，并以图形结构直观呈现 知识图谱由三部分组成 - 节点 + 边 + 标签 Why 降噪 + 提召 + 提准 传统 RAG 中的 Chunking 方式会召回一些噪音的 Chunk 引入 KG，可以通过实体层级特征来增强相关性 传统 RAG 中的 Chunk 之间是彼此孤立的，缺乏关联，在跨文档回答任务上表现不太好 引入 KG，增强 Chunk 之间的关联，并提升召回的相关性 假设已有 KG 数据存在，可以将 KG 作为一路召回信息源，补充上下文信息 Chunk 之间形成的 KG，可以提供 Graph 视角的 Embedding，来补充召回特征 构建一个高质量、灵活更新、计算简单的大规模图谱的代价很高 - RAG 会很慢 https://hub.baai.ac.cn/view/30017 https://hub.baai.ac.cn/view/33147 https://hub.baai.ac.cn/view/33390 https://hub.baa...

Fine-tuning vs RAG 核心诉求 - 实时更新知识库，不需要模型去深度探讨问题，使用已有知识经验去解答问题 Fine-tuning RAG 知识整合 直接把数据融入到模型参数 存储在外部知识库 知识更新 每次更新内容都需要重新训练模型，更新成本高 只需要在外部知识库插入记录，更新成本低 响应速度 很快，直接给出回答 现在外部知识库进行检索，然后再生成 实时更新 很难做到实时更新 外部知识库可以实时更新 人为干预 只能通过 Prompt 干预 可以通过外部知识库的语料和 Prompt 控制 领域定制 可以针对特定领域进行深度定制 依赖通用模型能力 适合使用 Fine-tuning 的场景 特定场景下的高一致性和定制化 数据量充足且稳定 训练 - 拥有高质量的对话原始数据 微调 - 基于现有对话数据做对话助手 强个性化需求 文言文的理解和输出 - 需要使用大量文言文语料微调后，才能满足需求 高速响应 Fine-tuning 能够直接输出有效内容，而 RAG 需要先检索再生成 LLM LLM 针对输入是有长度限制的，计量单位为 To...

概述 Chunking Documents 经过解析后，通过 Chunking 将信息内容划分为适当大小的 Chunks - 能够高效处理和精准检索 Chunk 的本质在于依据一定的逻辑和语义原则，将长文本拆解为更小的单元 Chunking 有多种策略，各有侧重，选择适合特定场景的 Chunking 策略，有助于提升 RAG 召回率 Embedding Embedding Model 负责将文本数据映射到高维向量空间，将输入的文档片段转换为对应的嵌入向量 嵌入向量捕捉了文本的语义信息，并存储到向量库中，以便于后续检索 Query 同样通过 Embedding Model 的处理生成 Query 的嵌入向量，在向量库中通过向量检索匹配最相似的文档片段 根据不同的场景，评估并选择最优的 Embedding Model，以确保 RAG 的检索性能符合要求 Chunking影响 Documents 包含丰富的上下文信息和复杂的语义结构 通过 Chunking，模型可以更有效地提取关键信息，并减少不相关内容的干扰 Chunking 的目标 确保每个片段在保留核心语义的同时，具备相对独立的语...