当前位置：首页 > news >正文

LightRAG核心原理和数据流

news 2025/7/1 22:02:38

LightRAG核心原理和数据流动

文章目录

LightRAG核心原理和数据流动
前言
1 原理
2 索引构建流程
- 2.1 全流程概览
- 2.2 实体及关系抽取
3 搜索
- 3.1 naive search
- 3.2 kg search
- 3.2.1 local search
- 3.2.2 global search
- 3.2.3 hybrid search
4 在线服务
总结

前言

介绍：lightRAG其实就是微软Graph的简化版本，将社区、社区宅摘要这些环节做了去除，这种去除是好的，不会太重，对于知识更新也更快；应用场景都很类似，一个是local search，一个是global search，一个是hybrid search

lightRAG对应的是lowlevelsearch(主要关注检索特定的实体以及它们相关的属性或关系。这个层次的查询以细节为导向，旨在提取图中特定节点或边的精确信息，所以取的是related text_units, topk entities results, related relations),
high level search（涉及更广泛的主题和总体概念。这个层次的查询聚合多个相关实体和关系的信息，提供对更高层次概念和总结的洞察，而不是具体细节，所以取的是related text units, topk relations results, related entities reusults）。前者以实体为中心，后者一关系为中心。也顺便看下为了做GraphRAG，需要做的依赖；

论文：https://arxiv.org/pdf/2410.05779
Github: https://github.com/HKUDS/LightRAG
💫💫💫
跑通以下流程的源代码已经开源啦，详情：https://github.com/hquzhuguofeng/LLM-RoadMap/tree/main/07-RAG
💫💫💫

1 原理

在这里插入图片描述

LightRAG的优势
引入图结构
使用图结构来索引文本数据，节点代表实体，边代表实体间的关系，可以更好地捕捉和表示复杂的依赖关系，有利于上下文的连贯性与丰富性
综合信息检索
从所有文档中提取相互依赖的实体的完整上下文，相对于传统的RAG，可能只关注于Chunk后的局部文本，缺乏全局综合信息
双层检索系统
结合低层次(具体实体和属性)和高层次(广泛主题和概念)的检索策略，满足不同类型的查询需求，其中低级检索重点关注特定实体及其关系的准确信息，高级检索则包含了广泛的主题信息
增量更新算法
当新数据到来时，系统会增量式地更新知识图谱，无需重复构建整个索引，提高了数据处理的效率
实体和关系提取
利用大型语言模型识别文本中的实体和关系，生成键值对，优化检索过程
增强检索效率
相对于GraphRAG以社区遍历的方法，LghtRAG专注于实体和关系的检索，进而减少开销，提高基于图结出的知识检索效率，以显著减少响应时间

2 索引构建流程

2.1 全流程概览

1. Validate ids if provided or generate MD5 hash IDs
2. Remove duplicate contents
Reconstruct contents with unique content hash IDs
3. Generate document initial status
构建字典
{
    "status": DocStatus.PENDING,
    "content": content_data["content"], 正文内容
    "content_summary": get_content_summary(content_data["content"]), 正文的前50个字
    "content_length": len(content_data["content"]), 正文的长度
    "created_at": datetime.now().isoformat(),
    "updated_at": datetime.now().isoformat(),
    "file_path": content_data[
        "file_path"
    ],  # Store file path in document status
}
4.Filter out already processed documents
5.Store status document
JsonDocStatusStorage.upsert 文档解析

然后进入函数解析核心流程/LightRAG-main/lightrag/lightrag.py/async def ainsert

await self.apipeline_process_enqueue_documents(
split_by_character, split_by_character_only
)
是一个异步函数，用于处理文档队列，将文档内容分割成块，并对每个块进行实体和关系提取，最后更新文档的状态。该函数的主要目标是确保文档处理的高效性和可靠性，同时支持并发处理和错误恢复。

核心流程

初始化和锁获取
获取管道状态和锁：函数首先从共享存储中获取管道状态（pipeline_status）和锁（pipeline_status_lock），以确保线程安全。
-检查是否已有进程在处理：通过锁机制检查是否有其他进程正在处理文档队列。如果已有进程在处理，当前函数会设置一个请求标志（request_pending），并立即返回，避免重复处理。
获取待处理文档
获取文档状态：从文档状态管理器（self.doc_status）中获取以下三类文档：
处理中（PROCESSING）：正在处理但可能未完成的文档。
失败（FAILED）：处理失败的文档。
待处理（PENDING）：尚未开始处理的文档。
合并文档：将上述三类文档合并到一个字典 to_process_docs 中，以便后续统一处理。
检查是否有文档需要处理
如果 to_process_docs 为空，说明没有文档需要处理，函数直接返回并记录日志。
如果有文档需要处理，更新管道状态为“忙碌”（busy: True），并记录当前任务的开始时间、文档数量、批次数量等信息。
文档批次处理
分批处理：将 to_process_docs 中的文档按 self.max_parallel_insert 的大小分成多个批次。
日志记录：记录当前批次的处理信息，包括文档总数和批次数量。
单文档处理
定义 process_document 异步函数：该函数负责处理单个文档，包括以下步骤：
内容分割：将文档内容分割成块（chunks），每个块生成唯一的 ID。
并发更新：并发执行以下任务：
- 更新文档状态为“处理中”（PROCESSING）。
- 将块存储到向量数据库（chunks_vdb）。
- 提取实体和关系图（_process_entity_relation_graph）。
- 存储完整文档内容（full_docs）。
- 存储文本块（text_chunks）。
- 如果处理成功，将文档状态更新为“已处理”（PROCESSED）；
- 如果处理失败，记录错误信息并将状态更新为“失败”（FAILED）。
批次循环处理
遍历批次：对每个批次的文档进行处理。
并发任务：为批次中的每个文档创建 process_document 任务，并并发执行。
状态更新：在每个批次处理前后更新管道状态，包括当前批次编号、最新消息等。
处理额外请求
检查是否有待处理请求：在完成当前批次处理后，检查是否有新的待处理请求（通过 request_pending 标志）。
继续处理：如果有新的请求，重新获取待处理文档并继续处理，直到没有新的请求为止。
最终状态清理
释放锁：无论处理是否成功，最后都会释放锁，并将管道状态更新为“不忙碌”（busy: False）。
日志记录：记录处理完成的日志信息。

文档处理的核心函数 process_document：

Generate chunks from document

{'tokens': 1200, 
'content': '正文具体内容', 
'chunk_order_index': 0, 
'full_doc_id': 'doc-8eedee302b21a3daf29696d5639b5f72', 
'file_path': 'unknown_source'
}

2.将数据存到向量数据库中，调用的是

LightRAG-main/lightrag/kg/nano_vector_db_impl.py 
class NanoVectorDBStorage(BaseVectorStorage):
	...
    async def upsert(self, data: dict[str, dict[str, Any]]) -> None:

2.2 实体及关系抽取

相比graphrag、nano, lightrag支持自定义实体抽取的类型
组装以下指令工程：

entity_extraction_examples 实体抽取例子
entity_extraction 实体抽取指令
entity_continue_extraction 实体继续抽取指令
entity_if_loop_extraction 判断实体是否抽取齐全

实体抽取提示词模板

'---Goal---\nGiven a text document that is potentially relevant to this activity and a list of entity types, identify all entities of those types from the text and all relationships among the identified entities.\nUse Chinese as output language.\n\n---Steps---\n1. Identify all entities. For each identified entity, extract the following information:\n- entity_name: Name of the entity, use same language as input text. If English, capitalized the name.\n- entity_type: One t the content-level key words as ("content_keywords"<|><high_level_keywords>)\n\n4. Return output in Chinese as a single list of all the entities and relationships identified in steps 1 and 2. Use **##** as the list delimiter.\n\n5. When finished, output <|COMPLETE|>\n\n######################\n---Examples---\n######################\nExample changes in <|>9)##\n("content_keywords"<|>"athletics, sprinting, record-breaking, sports technology, competition")<|COMPLETE|>\n#############################\n\n#############################\n---Real Data---\n######################\nEntity_types: [organization,person,geo,event,category]\nText:各区、各有关部门（单位）防御雷电灾害职责\t73\n第一章总则\n1.1 编制目的xxxxx灾救灾重要论述精 神xxx市气象灾熟现］、预 报xxxxxxxxx命财产损失。:'

没个chunk抽取后的结果进行解析：

识别的关系

{
	'src_id': '深x预案', 
	'tgt_id': '台风', 
	'weight': 9.0, 
	'description': '该预案专门用于应对台风气象灾害', 
	'keywords': '应对、预防', 
	'source_id': 'chunk-01262f5a710556e2384e0a62fbdd0042', 
	'file_path': 'unknown_source'
}

识别的实体

{
	'entity_name': '深x部', 
	'entity_type': 'organization', 
	'description': '深x市负责统一领导和指挥x监测预警、应急处置及次生衍生灾害工作的常设机构', 
	'source_id': 'chunk-01262f5a710556e2384e0a62fbdd0042', 
	'file_path': 'unknown_source'
}

使用 entity_extract_max_gleaning 机制进行文本块的再次复查，避免遗漏的实体
使用到的指令工程，翻译成中文

上次提取中遗漏了许多实体和关系。
—记住步骤—

识别所有实体。对于每个识别出的实体，提取以下信息：
- entity_name：实体的名称，使用与输入文本相同的语言。如果是英文，则首字母大写。
- entity_type：以下类型之一：[组织, 人物, 地理, 事件, 类别]
- entity_description：实体属性和活动的全面描述
将每个实体格式化为：("entity"<|><entity_name><|><entity_type><|><entity_description>
从步骤1中识别出的实体中，找到所有明确相关的（source_entity, target_entity）对。
对于每对相关实体，提取以下信息：
- source_entity：步骤1中识别的源实体名称
- target_entity：步骤1中识别的目标实体名称
- relationship_description：解释为什么认为源实体和目标实体之间存在关系
- relationship_strength：一个表示源实体和目标实体之间关系强度的数值分数
- relationship_keywords：一个或多个高层次关键词，总结关系的整体性质，重点关注概念或主题而非具体细节
将每对关系格式化为：("relationship"<|><source_entity><|><target_entity><|><relationship_description><|><relationship_keywords><|><relationship_strength>)
识别总结整个文本主要概念、主题或话题的高层次关键词。这些关键词应捕捉文档中存在的总体思想。
将内容级关键词格式化为：("content_keywords"<|><high_level_keywords>)
将步骤1和2中识别的所有实体和关系以简体中文形式返回，并用 ## 作为列表分隔符。
完成后，输出 <|COMPLETE|>
—输出—
请在下方使用相同的格式添加内容：

实体的合并和graphrag同样的逻辑：

实体节点
实体描述，使用合并，超过500token，重新大模型生成一遍
段落ID
文件路径

其中将

边的合并和graphrag同样的逻辑：

边的权重求和
边的描述，使用合并，超过500token，重新大模型生成一遍
关键词，构建成list
文件名
段落ID

然后插入到VDB中，其中将边的描述构建成embedding

3 搜索

工程中默认启动handle_cache机制，只要之前问过同样的问题，即从缓存中直接取对应的答案

3.1 naive search

传统的rag. 召回回来的chunk进行字数截断的处理

def truncate_list_by_token_size(
    list_data: list[Any], key: Callable[[Any], str], max_token_size: int
) -> list[int]:
    """Truncate a list of data by token size"""
    if max_token_size <= 0:
        return []
    tokens = 0
    for i, data in enumerate(list_data):
        tokens += len(encode_string_by_tiktoken(key(data)))
        if tokens > max_token_size:
            return list_data[:i]
    return list_data

如果有历史对话，则进行最近N轮的提取，并处理掉相关无效的字符

3.2 kg search

local,global,hybrid 三种默认使用的是kg_query

Handle cache if needed - add cache type for keywords 优先使用缓存数据
Build the examples 提示词模板中增加样例和回复的语言
Process conversation history 处理历史对话数据
Build the keyword-extraction prompt 构建关键词提取的指令工程
Call the LLM for keyword extraction 通过LLM提取关键词
Parse out JSON from the LLM response 将LLM的结果转化为json格式数据
Cache only the processed keywords with cache type 将提取的内容存下来，其实内容是和用户的输入关联起来的
进入_build_query_context中进行分支

相比graphrag，只是单纯抽取query中的实体，lightrag中增加抽取实体的层级

---角色---
你是一个乐于助人的助手，负责识别用户查询以及对话历史记录中的高级关键词和低级关键词。
---目标---
根据给定的查询和对话历史记录，列出高级关键词和低级关键词。高级关键词侧重于总体概念或主题，而低级关键词侧重于特定的实体、细节或具体术语。
---说明---
- 在提取关键词时，要同时考虑当前查询和相关的对话历史记录。
- 以 JSON 格式输出关键词，它将由 JSON 解析器进行解析，输出中不要添加任何额外内容。
- JSON 应该有两个键：
  - “high_level_keywords” 用于总体概念或主题。
  - “low_level_keywords” 用于特定实体或细节。
######################
---示例---
######################
示例 1：
查询：“How does international trade influence global economic stability?”（国际贸易如何影响全球经济稳定？）
################
输出：
{
  "high_level_keywords": ["International trade", "Global economic stability", "Economic impact"],
  "low_level_keywords": ["Trade agreements", "Tariffs", "Currency exchange", "Imports", "Exports"]
}
#############################
#############################
---真实数据---
######################
对话历史记录：
当前查询：市气x部的成员单位有哪些?
######################
输出应该是人类可读的文本，而不是 Unicode 字符。保持与查询相同的语言。
输出：

当前输出为：

{
  "high_level_keywords": ["气象xx部", "应急xx系", "成员单位"],
  "low_level_keywords": ["气x局", "应xxx局", "自然xxxx局", "水x局", "公x局", "消xx队", "交xx局", "卫x委"]
}'

3.2.1 local search

if query_param.mode == "local":
   entities_context, relations_context, text_units_context = await _get_node_data(
       ll_keywords,
       knowledge_graph_inst,
       entities_vdb,
       text_chunks_db,
       query_param,
)

输入：query中提取的所有关键字、图数据、实体向量、文本片段、
输出：实体对应的上下文、关系对应的上下文、文本片段对应的上下文

检索的输入：所有关键字拼接起来的query
根据召回回来的实体，从图数据库中召回所有的实体和对应的边的数量
然后使用实体找到最相关的文本片段
- 获取所有节点对应的文本片段text_units
- 获取节点对应的所有边edges
- 获取所有结点的一跳结点all_one_hop_nodes，构建成一个字典表all_one_hop_text_units_lookup，key是一跳结点名称，value是结点对应内容
- 通过query找到的所有文本片段和对应的边，构建成一个字典表
- 核心是：用户的问题中提取的实体，对应的文本片段进行去重all_text_units_lookup，相当于找到了对应的文本片段results；
- 如果该文本块中实体有边（即有关系），链接到的实体在一跳的实体表中all_one_hop_text_units_lookup，A中的文本片段c_id也在一跳结点对应的文本中，说明当前的文本块a和这个实体关系关系密切，对应relation_counts加一。
简单来说，核心是我用问题找到的文本块，用问题找到的边和文本块的关系用于排序
构建实体表
构建关系表
构建文本集合
最后组装成CSV格式数据

3.2.2 global search

entities_context, relations_context, text_units_context = await _get_edge_data(
      hl_keywords,
      knowledge_graph_inst,
      relationships_vdb,
      text_chunks_db,
      query_param,
)

输入：高level关键字、图谱数据、关系向量数据、文本块数据
输出：实体上下文、关系上下文、文本块上下文

检索的输入：所有关键字拼接起来的query
根据召回回来的实体，从图数据库中召回所有对应的边和对应边的度
然后使用边找到最相关的文本片段
- 获取所有边的rank和度进行排序
- 然后截断
- 根据边的数据找到最相关的实体use_entities
- 根据边的数据找到相关的文本片段use_text_units
最后组装成CSV格式数据

3.2.3 hybrid search

ll_data, hl_data = await asyncio.gather(
      _get_node_data(
          ll_keywords,
          knowledge_graph_inst,
          entities_vdb,
          text_chunks_db,
          query_param,
      ),
      _get_edge_data(
          hl_keywords,
          knowledge_graph_inst,
          relationships_vdb,
          text_chunks_db,
          query_param,
      ),
  )

合并local search和global search的结果

混合搜索提示词

**---角色---**

你是一位乐于助人的助手，负责根据下方提供的数据源回答用户关于数据源的查询。

**---目标---**

基于数据源生成简洁的回答，并遵循响应规则，同时考虑对话历史和当前查询。数据源包含两部分：知识图谱（Knowledge Graph, KG）和文档片段（Document Chunks, DC）。总结提供的数据源中的所有信息，并结合与数据源相关的通用知识。**不要包含数据源未提供的信息**。

在处理带有时间戳的信息时：
1. 每条信息（包括关系和内容）都有一个“created_at”时间戳，表示我们获取该知识的时间。
2. 当遇到冲突的信息时，需同时考虑内容/关系和时间戳。
3. **不要自动优先选择最近的信息**，而是根据上下文进行判断。
4. 对于时间特定的查询，优先考虑内容中的时间信息，然后再考虑创建时间戳。

**---对话历史---**
{history}

**---数据源---**

1. 来自知识图谱（Knowledge Graph, KG）：
{kg_context}

2. 来自文档片段（Document Chunks, DC）：
{vector_context}

**---响应规则---**

- **目标格式和长度**：{response_type}
- 使用适当的Markdown格式和部分标题。
- 请用与用户问题相同的语言回答。
- 确保回答与对话历史保持连贯性。
- 将答案按部分组织，每个部分聚焦于回答的一个主要观点或方面。
- 使用清晰且描述性的部分标题，反映内容。
- 在结尾的“参考文献”部分列出最多5个最重要的参考来源。明确标注每个来源是来自知识图谱（KG）还是向量数据（DC），并包括文件路径（如果有的话），格式如下：[KG/DC] 来源内容（文件：file_path）
- 如果不知道答案，请直接说明。**不要编造任何内容**。
- **不要包含数据源未提供的信息**。

4 在线服务

方式一：可以参考启动：LightRAG-main/examples/lightrag_api_openai_compatible_demo.py
方式二：使用官方脚本启动后端服务

# 使用 openai 运行 lightrag，llm 使用 GPT-4o-mini，嵌入使用 text-embedding-3-small
# 在 .env 或 config.ini 中配置：
# LLM_BINDING=openai
# LLM_MODEL=GPT-4o-mini
# EMBEDDING_BINDING=openai
# EMBEDDING_MODEL=text-embedding-3-small
lightrag-server

# 使用认证密钥
lightrag-server --key my-key

其中参数如下：
LightRAG FastAPI Server 参数说明（含中文翻译）

usage: lightrag-server [-h] [--host HOST] [--port PORT] [--working-dir WORKING_DIR] [--input-dir INPUT_DIR] [--timeout TIMEOUT] [--max-async MAX_ASYNC] [--max-tokens MAX_TOKENS] [--log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL}]
                       [--verbose] [--key KEY] [--ssl] [--ssl-certfile SSL_CERTFILE] [--ssl-keyfile SSL_KEYFILE] [--history-turns HISTORY_TURNS] [--top-k TOP_K] [--cosine-threshold COSINE_THRESHOLD]
                       [--simulated-model-name SIMULATED_MODEL_NAME] [--namespace-prefix NAMESPACE_PREFIX] [--auto-scan-at-startup] [--workers WORKERS] [--llm-binding {lollms,ollama,openai,openai-ollama,azure_openai}]
                       [--embedding-binding {lollms,ollama,openai,azure_openai}]

LightRAG FastAPI Server，支持独立的工作目录和输入目录

可选参数：

参数	英文说明	中文翻译
`-h, --help`	show this help message and exit	显示此帮助信息并退出
`--host HOST`	Server host (default: from env or 0.0.0.0)	服务器主机（默认：从环境变量获取或为0.0.0.0）
`--port PORT`	Server port (default: from env or 9621)	服务器端口（默认：从环境变量获取或为9621）
`--working-dir WORKING_DIR`	Working directory for RAG storage (default: from env or ./rag_storage)	RAG存储的工作目录（默认：从环境变量获取或为`./rag_storage`）
`--input-dir INPUT_DIR`	Directory containing input documents (default: from env or ./inputs)	包含输入文档的目录（默认：从环境变量获取或为`./inputs`）
`--timeout TIMEOUT`	Timeout in seconds (useful when using slow AI). Use None for infinite timeout	超时时间（秒）。对于慢速AI很有用。使用`None`表示无限超时
`--max-async MAX_ASYNC`	Maximum async operations (default: from env or 4)	最大异步操作数（默认：从环境变量获取或为4）
`--max-tokens MAX_TOKENS`	Maximum token size (default: from env or 32768)	最大令牌大小（默认：从环境变量获取或为32768）
`--log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL}`	Logging level (default: from env or INFO)	日志级别（默认：从环境变量获取或为`INFO`）
`--verbose`	Enable verbose debug output(only valid for DEBUG log-level)	启用详细调试输出（仅在`DEBUG`日志级别下有效）
`--key KEY`	API key for authentication. This protects lightrag server against unauthorized access	用于身份验证的API密钥。此选项可保护LightRAG服务器免受未授权访问
`--ssl`	Enable HTTPS (default: from env or False)	启用HTTPS（默认：从环境变量获取或为`False`）
`--ssl-certfile SSL_CERTFILE`	Path to SSL certificate file (required if --ssl is enabled)	SSL证书文件路径（如果启用了`--ssl`，则为必需）
`--ssl-keyfile SSL_KEYFILE`	Path to SSL private key file (required if --ssl is enabled)	SSL私钥文件路径（如果启用了`--ssl`，则为必需）
`--history-turns HISTORY_TURNS`	Number of conversation history turns to include (default: from env or 3)	包含的对话历史轮数（默认：从环境变量获取或为3）
`--top-k TOP_K`	Number of most similar results to return (default: from env or 60)	返回的最相似结果数量（默认：从环境变量获取或为60）
`--cosine-threshold COSINE_THRESHOLD`	Cosine similarity threshold (default: from env or 0.4)	余弦相似度阈值（默认：从环境变量获取或为0.4）
`--simulated-model-name SIMULATED_MODEL_NAME`	Number of conversation history turns to include (default: from env or 3)	包含的对话历史轮数（默认：从环境变量获取或为3）
`--namespace-prefix NAMESPACE_PREFIX`	Prefix of the namespace	命名空间前缀
`--auto-scan-at-startup`	Enable automatic scanning when the program starts	在程序启动时启用自动扫描
`--workers WORKERS`	Number of worker processes (default: from env or 1)	工作进程数量（默认：从环境变量获取或为1）
`--llm-binding {lollms,ollama,openai,openai-ollama,azure_openai}`	LLM binding type (default: from env or ollama)	LLM绑定类型（默认：从环境变量获取或为`ollama`）
`--embedding-binding {lollms,ollama,openai,azure_openai}`	Embedding binding type (default: from env or ollama)	Embedding绑定类型（默认：从环境变量获取或为`ollama`）

启动命令设置为：

lightrag-server --host 0.0.0.0 --port 1890 --working-dir ./rag_storage

Flask app跳转：

1、
/workspace/guofeng/LightRAG-main/lightrag/api/routers/query_routes.py +179
@router.post("/query/stream", dependencies=[Depends(combined_auth)])
	param = request.to_query_params(True)
    response = await rag.aquery(request.query, param=param)

2、
/workspace/guofeng/LightRAG-main/lightrag/lightrag.py +1331
async def aquery(
        self,
        query: str,
        param: QueryParam = QueryParam(),
        system_prompt: str | None = None,
    ) -> str | AsyncIterator[str]:
    跳转到 "local", "global", "hybrid","naive","mix"

3、
/workspace/guofeng/LightRAG-main/lightrag/api/lightrag_server.py +201
async def openai_alike_model_complete(
        prompt,
        system_prompt=None,
        history_messages=None,
        keyword_extraction=False,
        **kwargs,
    ) -> str:
	openai_complete_if_cache()
lightrag中构建知识图谱同样也是调用openai_complete_if_cache, 都没有打开streaming模式

环境配置如下：

### This is sample file of .env

### Server Configuration
HOST=127.0.0.1
PORT=1892
# WORKERS=1
# NAMESPACE_PREFIX=lightrag  # separating data from difference Lightrag instances
# MAX_GRAPH_NODES=1000       # Max nodes return from grap retrieval
# CORS_ORIGINS=http://localhost:3000,http://localhost:8080

### Optional SSL Configuration
# SSL=true
# SSL_CERTFILE=/path/to/cert.pem
# SSL_KEYFILE=/path/to/key.pem

### Directory Configuration
WORKING_DIR=/workspace/guofeng/LightRAG-main/rag_storage
INPUT_DIR=/workspace/guofeng/LightRAG-main/dickens

### Ollama Emulating Model Tag
# OLLAMA_EMULATING_MODEL_TAG=latest

### Logging level
LOG_LEVEL=DEBUG
VERBOSE=true
# LOG_DIR=/path/to/log/directory  # Log file directory path, defaults to current working directory
# LOG_MAX_BYTES=10485760          # Log file max size in bytes, defaults to 10MB
# LOG_BACKUP_COUNT=5              # Number of backup files to keep, defaults to 5

### Settings for RAG generation stream mode
STREAM=true

### Settings for RAG query
# HISTORY_TURNS=3
# COSINE_THRESHOLD=0.2
# TOP_K=60
# MAX_TOKEN_TEXT_CHUNK=4000
# MAX_TOKEN_RELATION_DESC=4000
# MAX_TOKEN_ENTITY_DESC=4000

### Settings for document indexing
ENABLE_LLM_CACHE_FOR_EXTRACT=true    # Enable LLM cache for entity extraction
SUMMARY_LANGUAGE=Chinese
CHUNK_SIZE=1200
CHUNK_OVERLAP_SIZE=100
MAX_TOKEN_SUMMARY=500                # Max tokens for entity or relations summary
# MAX_PARALLEL_INSERT=2                # Number of parallel processing documents in one patch

# EMBEDDING_BATCH_NUM=32               # num of chunks send to Embedding in one request
# EMBEDDING_FUNC_MAX_ASYNC=16          # Max concurrency requests for Embedding
# MAX_EMBED_TOKENS=8192

### LLM Configuration (Use valid host. For local services installed with docker, you can use host.docker.internal)
TIMEOUT=150                            # Time out in seconds for LLM, None for infinite timeout
TEMPERATURE=0.5
MAX_ASYNC=4                            # Max concurrency requests of LLM
MAX_TOKENS=32768                       # Max tokens send to LLM (less than context size of the model)

# LLM_BINDING=ollama
# LLM_MODEL=mistral-nemo:latest
# LLM_BINDING_API_KEY=your_api_key
### Ollama example
# LLM_BINDING_HOST=http://localhost:11434
### OpenAI alike example
LLM_BINDING=openai
LLM_MODEL=QwQ-32B
LLM_BINDING_HOST=http://localhost:1891/v1
LLM_BINDING_API_KEY="EMPTY"
OPENAI_API_KEY="EMPTY"
### lollms example
# LLM_BINDING=lollms
# LLM_MODEL=mistral-nemo:latest
# LLM_BINDING_HOST=http://localhost:9600
# LLM_BINDING_API_KEY=your_api_key

### Embedding Configuration (Use valid host. For local services installed with docker, you can use host.docker.internal)
EMBEDDING_MODEL=BCE-embedding-base_v1
EMBEDDING_DIM=768
# EMBEDDING_BINDING_API_KEY=your_api_key
### ollama example
# EMBEDDING_BINDING=ollama
# EMBEDDING_BINDING_HOST=http://172.17.136.62:9997
### OpenAI alike example
EMBEDDING_BINDING=openai
EMBEDDING_BINDING_HOST=http://172.17.136.62:9997
### Lollms example
# EMBEDDING_BINDING=lollms
# EMBEDDING_BINDING_HOST=http://localhost:9600

### Optional for Azure (LLM_BINDING_HOST, LLM_BINDING_API_KEY take priority)
# AZURE_OPENAI_API_VERSION=2024-08-01-preview
# AZURE_OPENAI_DEPLOYMENT=gpt-4o
# AZURE_OPENAI_API_KEY=your_api_key
# AZURE_OPENAI_ENDPOINT=https://myendpoint.openai.azure.com

# AZURE_EMBEDDING_DEPLOYMENT=text-embedding-3-large
# AZURE_EMBEDDING_API_VERSION=2023-05-15

### Data storage selection
LIGHTRAG_KV_STORAGE=JsonKVStorage
LIGHTRAG_VECTOR_STORAGE=NanoVectorDBStorage
LIGHTRAG_GRAPH_STORAGE=NetworkXStorage
LIGHTRAG_DOC_STATUS_STORAGE=JsonDocStatusStorage

### Oracle Database Configuration
ORACLE_DSN=localhost:1521/XEPDB1
ORACLE_USER=your_username
ORACLE_PASSWORD='1234567'
ORACLE_CONFIG_DIR=/path/to/oracle/config
#ORACLE_WALLET_LOCATION=/path/to/wallet  # optional
#ORACLE_WALLET_PASSWORD='your_password'  # optional
#ORACLE_WORKSPACE=default  # separating all data from difference Lightrag instances(deprecated, use NAMESPACE_PREFIX in future)

### TiDB Configuration
TIDB_HOST=localhost
TIDB_PORT=4000
TIDB_USER=your_username
TIDB_PASSWORD='1234567'
TIDB_DATABASE=your_database
#TIDB_WORKSPACE=default  # separating all data from difference Lightrag instances(deprecated, use NAMESPACE_PREFIX in future)

### PostgreSQL Configuration
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_USER=your_username
POSTGRES_PASSWORD='1234567'
POSTGRES_DATABASE=your_database
#POSTGRES_WORKSPACE=default  # separating all data from difference Lightrag instances(deprecated, use NAMESPACE_PREFIX in future)

### Independent AGM Configuration(not for AMG embedded in PostreSQL)
AGE_POSTGRES_DB=
AGE_POSTGRES_USER=
AGE_POSTGRES_PASSWORD=
AGE_POSTGRES_HOST=
# AGE_POSTGRES_PORT=8529

# AGE Graph Name(apply to PostgreSQL and independent AGM)
# AGE_GRAPH_NAME=lightrag  # deprecated, use NAME_SPACE_PREFIX instead

### Neo4j Configuration
NEO4J_URI=neo4j+s://xxxxxxxx.databases.neo4j.io
NEO4J_USERNAME=neo4j
NEO4J_PASSWORD='1234567'

### MongoDB Configuration
MONGO_URI=mongodb://root:root@localhost:27017/
MONGO_DATABASE=LightRAG
MONGODB_GRAPH=false # deprecated (keep for backward compatibility)

### Milvus Configuration
MILVUS_URI=http://localhost:19530
MILVUS_DB_NAME=lightrag
# MILVUS_USER=root
# MILVUS_PASSWORD=your_password
# MILVUS_TOKEN=your_token

### Qdrant
QDRANT_URL=http://localhost:16333
# QDRANT_API_KEY=your-api-key

### Redis
REDIS_URI=redis://localhost:6379

### For JWT Auth
AUTH_ACCOUNTS='admin:admin123,user1:pass456'     # username:password,username:password
TOKEN_SECRET=guofengapi    # JWT key
TOKEN_EXPIRE_HOURS=4                             # expire duration

### API-Key to access LightRAG Server API
# LIGHTRAG_API_KEY=your-secure-api-key-here
# WHITELIST_PATHS=/health,/api/*

根据《明朝那些事儿》构建的知识图谱如下：
在这里插入图片描述

总结

搜索方式	描述	适用场景
朴素搜索 (Naive)	直接根据查询关键词进行搜索，不考虑实体间的关系。	适用于简单、直接的查询，不需要深入理解实体间的关系。
局部搜索 (Local)	在实体及其直接相邻的实体之间进行搜索，考虑实体间的直接关系。	适用于需要理解实体间直接关系的查询，但不需要全局视角。
全局搜索 (Global)	在整个知识图谱中进行搜索，考虑实体间的全局关系。	适用于需要全局视角，理解实体间复杂关系的查询。
混合搜索 (Hybrid)	结合局部搜索和全局搜索的优点，既考虑实体间的直接关系，也考虑全局关系。	适用于需要全面理解实体间关系的查询，适用于大多数场景。