RAG
大语言模型RAG的流程：
大语言模型RAG的流程：
加载文档 >> Embedding >> 存储到向量库中
用户提出问题 >> 大模型写Query >> 从向量库中匹配并返回内容 >> 结合用户内容和返回的向量库中的原文回答
分块策略
对于一个文档，它想必是很长的，同时不能一口气全部塞给AI，那么可以通过把它构建为知识库，由AI检索，那么常见的Embedding模型，它的最大Token输出长度为8096 Token，那么一篇长文想必无法完整容纳下整篇文章的长度，那么所以说我们需要把它进行分块。
分块的目标是把大型非结构化的数据切分成更小、更有意义、独立单元的过程
RAG分块也有相应的策略，否则可能会对结果造成一些影响
如果说三个不同的主题ABC，以水果的颜色为例，如果A是苹果，它是红色的。B是猕猴桃，是绿色的。C是葡萄，是紫色的。如果我把ABC放在同一个块里，那么经过RAG池化，最后平均出的向量会导致它最后出来的结果，既不红，也不绿，也不紫，被稀释干净了。如果这个时候，在检索召回的时候，把它召回进来，还容易受到无关内容的影响，上下文也被稀释
固定大小分块
这个比较好理解，中间它会设置一些重叠的内容，来缓解直接切分可能导致的语义的断裂。
语义分块
首先把一整段大的文章分成一小句或者一小段的形式，然后直接把它embedding转化为向量，然后从上到下一个一个计算相邻的余弦相似度。如果余弦相似度比较高（>阈值），那么说明它们之间关联比较大，就可以把它合并成一个块，直到这个块和下一个块余弦相似度比较低，那么就可以分开，开始一个新的分块 缺点：显著下降这个阈值很难调整，因为它可能需要根据不同的数据集和文档进行实验调整，没有固定的一个标准
递归分块
- 提供预设的分隔符列表 如 段落 换行符 句号 等，这个分隔符列表有一个优先级，首先按照最高的分隔（先让每一块比较大，保留比较多的信息内容）
- 设定一个预设值，如果超出这个预设值，就把这一块继续切割，按照下一优先级继续切分，直到达到最小优先级使所有块的大小都符合要求
基于文档结构分块
缺点：适用性有限，这个方法严重依赖文档是否有清晰规范的结构，同时，不同章节可能长度差距比较大，导致有些块过大，超出模型上下文窗口，或者某些块过小导致信息量不足（可以尝试结合递归分块来缓解）
基于大语言模型分块
LLM几乎在所有自然语言处理任务上都取得了SOTA表现，所以说也可以尝试用LLM来做分块这个事情
可以直接通过提示词引导，将一篇长文分割成多个语义上独立内聚的段落
在实际应用中可以尝试把多个策略结合起来，优先可以尝试递归分块。如果结构良好，可以尝试根据结构的分块来控制大小。
前沿不同其他RAG策略
无需嵌入向量式方案
主要依靠大语言模型，把文档结构化解析为一棵树。
- 先通读全文，然后拆分为顶级章节。对于足够长可以进一步拆分的章节，再次发送给模型以获取子章节，来生成一个多级的树形结构。短章节就保持为叶子节点。
- 从叶子节点到根节点遍历树结构，每个子节点得到一个简短的原始文本摘要。 向上遍历，父节点得到所有子节点的文本摘要，然后继续总结，然后根节点会得到整个文档的摘要
- 查询时可以直接从根节点开始，展示所有子节点的摘要，并询问应该进入哪一个，然后一步一步移动，直到达到叶子节点，并且返回检索到的这个上下文，提供给LLM
Graph RAG：知识图谱增强
增强实体关系和多跳推理
工程实践策略
上面就是语义检索，当然还有传统的关键词检索，就比如传统的Semantic Search，我们在应用中会同时运用关键词检索加语义检索，混合使用
同时我们可以在小的细节上进行一些优化，比如大模型检索需要query，我们可以尝试多次query的改写
包括在不同的应用场景下，会采用不同的组合式的解决方案，而不是只用一个。我们需要结合具体的场景来判断如何提出恰当的解决方案
下面给出一些常见的场景例子
| 问题（使用场景） | 简单示例 | 解决方案（对应检索方法，可以先不看） |
|---|---|---|
| 无法匹配精确的单词或数字 | 查询“显示错误代码 P0420 的公告”，结果却返回了一堆排气系统的通用文档，却没有真正包含 P0420 的页面。 | 使用关键词搜索进行精确匹配，或采用混合检索（Keyword + Vector），确保能够命中具体代码。 |
| 行业术语或缩写容易混淆 | 用户搜索 Freon，而文档全部使用 refrigerant（制冷剂），结果正确的 HVAC 文档没有被检索出来。 | 为关键词搜索增加同义词词典，或者采用混合检索，同时利用关键词和语义信息。 |
| 大量重复内容占据搜索结果 | 同一份产品说明书有十几份副本，占满了 Top-K，导致其他更有价值的文档无法进入结果。 | 在向量搜索基础上加入 MMR（最大边际相关性） 或去重（Dedup），再结合混合检索，让具有不同关键词的文档也有机会进入结果。 |
| 内容相关，但没有真正回答问题 | 用户问“Model X 是什么时候发布的？”，返回的却是一篇产品对比文章，其中根本没有发布日期。 | 采用两阶段混合检索：先利用向量搜索召回候选文档，再通过关键词搜索、关系数据库过滤或重排序（Rerank）提高准确率。 |
| 无法理解实体之间的关系 | 查询“谁向 Alice 的经理汇报工作？”，需要组织架构关系，而普通向量搜索无法推理这种关系。 | 在向量搜索之外，引入知识图谱或关系数据库（SQL）查询能力。 |
| 检索结果容易过时 | 昨天商品价格刚刚调整，但嵌入向量尚未更新，因此仍然返回旧价格。 | 将实时数据保存在**关系数据库（SQL）**中，并结合实时数据库查询与向量检索共同完成回答。 |
| 一词多义导致语义理解错误 | 查询“Mouse care guide”，结果返回的是电脑鼠标使用手册，而不是宠物老鼠饲养指南。 | 利用关键词过滤类别信息，或采用混合检索，提高相关主题词的权重。 |
| 可能泄露受限内容 | 向量检索把 HR 的保密记录返回给了没有权限的用户。 | 对向量索引实施访问控制（ACL），并结合关键词过滤或基于权限的数据库查询进行二次过滤。 |
在RAG后，我们可以尝试关注指标：召回率（=系统中实际找到的内容 / 知识库所有相关的内容）
重排序
检索到相关的文档后，可能排列顺序会有一些问题。 使用初步的检索时，为了迅速，虽然能够找到相关的内容，但是打分不一定准确，所以需要重排序来解决这个问题
（因为重排序是一个精准但慢的过程，所以我们对用Embedding筛选过的内容再重新进行排序，能产生更好的效果）
反向链接（0）
还没有笔记链接到这里。在 Obsidian 里用 [[笔记名]] 引用它，这里就会出现，关系图谱上也会多出一条连线。