LightRAG 论文笔记
前言
首先 AI 我不熟，所以理解很可能是有误的。但我读论文/学知识的的原则是，要有明确的理解，这个理解可以是不完全，有偏差，甚至是错误的，这样方便我去修正和验证，如果没有，就没办法改进和收敛。类似假设，长期来看，假设的可被证否性比正确性更重要。
问题
LLM 训练是根据已有的数据进行训练，训练完成后，数据就是固定的了，所谓的 cutoff。这个时候，用户可以通过增加 context，让 LLM 基于 context 回答。
但很多时候，用户没有办法提供具体的 context，比如查找公司内部的流程。所以需要我们把这些 context 存起来，当用户输入问题时，找到相应的 context，再由 LLM 回答。即所谓的 RAG。
那这里面的问题有 3 个
- 存储这些信息
- 查找到相关信息
- 给 LLM 提供 context
LightRAG 的亮点是，在提供给 LLM 的 context 里加入了关系 (relationship),即 High-Level，帮助 LLM 更好的回答我们的问题。
下面通过这 3 个问题，介绍 LightRAG 的大体实现。
LightRAG 实现
关键思想是在 context 中加入关系信息，通过结构化的知识图谱提供更准确的上下文，从而提高 LLM 回答质量。
存储 (graph-based text indexing)
大致上是，得到文本后，让 LLM 分析，得到结构化的数据 (Entities 和 Relationships),之后把这些数据存到数据库里，方便用户提问的时候提取这些信息。
文本输入会先被分成块 (相关方法 chunking_by_token_size,分出来的块有重叠，似乎是 LLM 处理中的常见做法),交给 LLM 进行信息提取 (相关方法 _process_entity_relation_graph -> extract_entities)。
信息提取使用 PROMPTS["entity_extraction"] prompt，主要提取实体名称、类型、描述等，然后识别所有实体之间的关系，给出关系关键词、关系描述等。
存储方面 LightRAG 采用双存储架构：
- 知识图谱数据库:存储实体和关系的结构化信息，支持图遍历查询
- 向量数据库:分别存储实体和关系的向量表示，支持语义搜索
整体流程图 (Cursor 根据代码生成，流程图链接)
查找相关信息
用户输入查询后，会通过 LLM 提取出 keywords，包括：
- high-level: 总体概念或主题 (overarching concepts or themes)
- low-level: 具体的实体或细节
对应方法是 get_keywords_from_query。
之后根据查询模式：
- Global 模式:high-level keywords 用来调用 _get_edge_data，在关系向量数据库中搜索相关关系
- Local 模式:low-level keywords 用来调用 _get_node_data，在实体向量数据库中搜索相关实体
系统还会进行重要性排序 (基于节点度数) 和 token 预算管理。
整体流程图 (Cursor 根据代码生成，流程图链接)
给 LLM 提供 context
得到相关数据之后，LightRAG 会根据 context，对话记录等生成 prompt 发给 llm 得到答案，具体的 prompt 在 PROMPTS[“rag_response”]。
其他
LightRAG 是用 LLM 来评价回答的质量的，不清楚这个是不是业界常见做法。我关注 evaluation 的一个原因是，AI 需要进行调优，评估标准的方法也可以用来调优。有明确答案的数据，可以直接验证，这种需要”主观”判断的，用 LLM 来做蛮有趣的。另外一个原因是，可以通过 evaluation 推导出论文的适用范围甚至是局限性。LightRAG 在其实验的对象表现的很优秀，但当我们把它使用到更多、更复杂的场景下，可能需要一些改进。
论文地址:https://arxiv.org/abs/2410.05779
总结
RAG 也可以理解为”智能搜索 + 上下文理解”。LightRAG 通过 LLM 构建结构化数据，查询时再让 LLM 分析问题提取关键词，然后在多个数据库中检索相关信息，最后将这些信息作为 context 提供给 LLM 生成答案。整个流程中 LLM 的质量会同时影响知识提取和问题理解两个方面，所以模型选择也很重要。