本文介绍了LightRAG，一个简单快速的检索增强生成系统，旨在解决企业知识库问答、研发文档助手等场景中的痛点。LightRAG结合了块检索和实体-关系知识图谱，支持全局理解与局部证据结合，并提供从核心库到Server（WebUI/API）的完整落地路径。文章详细讲解了LightRAG的应用场景、快速上手路线、安装部署、核心功能及多模态支持，并提供了与Langfuse和RAGAS的集成方案，适合希望在大模型领域实践的小白和程序员参考学习。

当你做过企业知识库问答、研发文档助手、合规检索、甚至客服机器人，你大概率遇到过这些痛点：

  • 文档一多，向量检索“只看局部”，问全局问题就答不全；
  • 纯GraphRAG又容易重、慢、门槛高；
  • 工程上存储后端五花八门，部署配置让人头大；
  • 线上要可观测、可评估、可迭代，但多数RAG项目把这些当“后话”。

LightRAG的定位非常明确：Simple and Fast Retrieval-Augmented Generation。它把传统RAG的“块检索”与“实体—关系知识图谱”结合起来，用更结构化的方式支持“全局理解 + 局部证据”，并提供从核心库到Server（WebUI/API）的完整落地路径。

LightRAG Diagram

一张图看懂：LightRAG到底在做什么？

LightRAG在索引阶段不仅切chunk、做embedding，还会让LLM完成实体-关系抽取，形成知识图谱；查询阶段则支持多种mode，把“图谱检索”和“向量检索”按场景组合，最后再由LLM生成回答。

下面两张流程图（来自LearnOpenCV的教程资源）非常直观：

Figure 1: LightRAG Indexing Flowchart - Img Caption : Source

Figure 2: LightRAG Retrieval and Querying Flowchart - Img Caption : Source

适合哪些应用场景？（建议直接对号入座）

1）企业知识库：既要“证据”，也要“全局梳理”

比如问“这套制度的核心原则是什么、有哪些例外、和哪些部门流程相关？”这类问题不是单段chunk能回答的。LightRAG的global / mix类模式更面向全局关联与关系网络表达。

2）法律/合规/制度类：跨条款、跨文档的关联追问

LightRAG支持引用（citation）：插入时传入file_path，有利于追溯来源，增强可审计性。

3）研发文档/架构知识：实体关系天然存在

组件、模块、依赖、版本、接口，这些都适合沉到“实体-关系”层，而不是只靠向量相似度碰运气。

4）多知识库隔离：一个系统里跑多套知识域

LightRAG提供workspace做隔离：同一套服务、不同工作空间，隔离“Book内容”和“HR Policies”这类共存需求。

快速上手：两条路线，一个核心原则

LightRAG分为两块：

  • LightRAG Core：Python库，更偏嵌入式/研究/自定义集成
  • LightRAG Server：提供WebUI + API，并且目标是提供Ollama兼容接口，方便Open WebUI等工具把它当“聊天模型”接入

文档中也明确建议：如果要集成进你的业务系统，更推荐用LightRAG Server提供的REST API。

安装与部署：Server（WebUI/API）怎么跑起来？

方式A：直接从PyPI安装（推荐）

### Install LightRAG Server as tool using uv (recommended)uv tool install "lightrag-hku[api]"### Build front-end artifactscd lightrag_webuibun install --frozen-lockfilebun run buildcd ..# Setup env filecp env.example .env  # Update the .env with your LLM and embedding configurations# Launch the serverlightrag-server

方式B：从源码安装

git clone https://github.com/HKUDS/LightRAG.gitcd LightRAGuv sync --extra apisource .venv/bin/activatecd lightrag_webuibun install --frozen-lockfilebun run buildcd ..cp env.example .envlightrag-server

方式C：Docker Compose一键拉起

git clone https://github.com/HKUDS/LightRAG.gitcd LightRAGcp env.example .envdocker compose up

用“交互式向导”生成.env：适合不想手改配置的人

LightRAG在近期更新里加入了setup wizard，你可以用make目标一步步生成.env（以及必要时生成docker-compose.final.yml）：

make env-base           # Required first step: LLM, embedding, rerankermake env-storage        # Optional: storage backends and database servicesmake env-server         # Optional: server port, auth, and SSLmake env-security-check # Optional: audit the current .env for security risks

这对“本地用Docker部署embedding/rerank/storage后端”的流程尤其友好。

Core最小可用示例：初始化、插入、查询（关键点别漏）

LightRAG Core里有一个很容易踩的坑：必须显式初始化存储。也就是创建实例后必须调用：

await rag.initialize_storages()

官方示例（精简核心逻辑如下）：

import osimport asynciofrom lightrag import LightRAG, QueryParamfrom lightrag.llm.openai import gpt_4o_mini_complete, openai_embedfrom lightrag.utils import setup_loggersetup_logger("lightrag", level="INFO")WORKING_DIR = "./rag_storage"ifnot os.path.exists(WORKING_DIR):    os.mkdir(WORKING_DIR)asyncdef initialize_rag():    rag = LightRAG(        working_dir=WORKING_DIR,        embedding_func=openai_embed,        llm_model_func=gpt_4o_mini_complete,    )    await rag.initialize_storages()    return ragasyncdef main():    rag = await initialize_rag()    await rag.ainsert("Your text")    print(      await rag.aquery(          "What are the top themes in this story?",          param=QueryParam(mode="hybrid")      )    )    await rag.finalize_storages()if __name__ == "__main__":    asyncio.run(main())

这段代码也说明了三件事：
1）数据会落到working_dir里；2）你通过注入embedding与LLM函数来适配不同模型；3）查询用QueryParam控制模式。

QueryParam：用“模式”把检索策略切清楚

LightRAG的QueryParam里，最重要的就是mode：

  • local：偏上下文依赖、局部信息
  • global：偏全局知识
  • hybrid：结合local与global
  • naive：基础检索方式
  • mix：集成知识图谱与向量检索
  • bypass：定义存在于类型里（文档未展开解释）

此外还有几个很实用的开关：

  • only_need_context=True：只要召回内容，不生成答案（用于调试/评估）
  • only_need_prompt=True：只要最终prompt（用于排查提示构造）
  • stream=True：流式输出
  • chunk_top_k / top_k：控制召回规模
  • enable_rerank=True：启用rerank（默认开启，有配置reranker时更有效）
  • user_prompt：只影响LLM生成，不参与检索（避免“检索+输出加工”绑在一起导致检索变差）

举个user_prompt的原生示例（让LLM把结果画成mermaid）：

query_param = QueryParam(    mode="hybrid",    user_prompt="For diagrams, use mermaid format with English/Pinyin node names and Chinese display labels",)response = rag.query(    "Please draw a character relationship diagram for Scrooge",    param=query_param)print(response)

模型与栈要求：LightRAG为什么强调“大模型+长上下文”？

文档明确指出：LightRAG对LLM能力要求高于传统RAG，因为索引阶段要做实体关系抽取。

  • LLM建议：≥32B参数；上下文≥32KB（推荐64KB）
  • 索引阶段不建议使用推理模型（原文：not recommended to choose reasoning models during indexing stage）
  • 查询阶段建议用能力更强的模型（高质量回答更稳）
  • Embedding：建议主流多语模型，如BAAI/bge-m3、text-embedding-3-large
  • 重要提醒：embedding模型要在索引前确定；换embedding需要清理原有向量表/数据目录（尤其PG类后端）

LLM/Embedding怎么“注入”？三种常见做法

1）OpenAI-like API（包括自定义base_url的服务）

文档提供了通过openai_complete_if_cache和openai_embed.func对接的方式，并强调：

被@wrap_embedding_func_with_attrs装饰过的EmbeddingFunc不能再二次嵌套包装

2）Hugging Face模型

示例里通过transformers加载tokenizer与model，然后把embedding封装到EmbeddingFunc(...)里。

3）Ollama

支持Ollama的LLM与embedding，并且专门讲了如何把上下文窗口从默认8k提升到32k：

  • 修改Modelfile里PARAMETER num_ctx 32768
  • 或通过llm_model_kwargs={"options": {"num_ctx": 32768}}配置

数据怎么存？LightRAG的“四类存储”是工程落地关键

LightRAG把存储拆成四类（这点很工程化）：

  • KV_STORAGE：缓存、chunk、文档信息
  • VECTOR_STORAGE：实体/关系/chunk向量
  • GRAPH_STORAGE：实体关系图
  • DOC_STATUS_STORAGE：索引状态

并提供多种实现组合——从本地Json/NetworkX/NanoVector到生产级Neo4j、PostgreSQL、Milvus、OpenSearch等。

其中一个近期重要更新是：OpenSearch作为统一后端，能覆盖四类存储（KV/Vector/Graph/DocStatus）。

生产建议：Neo4j、PostgreSQL、OpenSearch怎么选？

文档里给了非常明确的倾向性信息：

  • Neo4j：在生产环境中性能更优（对比PostgreSQL + AGE插件）
  • PostgreSQL：可做一站式（KV + pgvector + AGE图），版本建议16.6+
  • OpenSearch：统一后端，支持k-NN向量与图遍历（有SQL插件PPL时可server-side BFS）

如果你想“少折腾、统一运维”，OpenSearch和PostgreSQL是一种方向；如果你图谱查询/遍历性能要求更高，文档更推荐Neo4j。

知识图谱可维护：不止能抽取，还能“改、删、合并”

LightRAG提供了完整的KG管理能力：

  • create_entity / edit_entity（支持重命名并迁移关系）
  • create_relation / edit_relation
  • 删除：按实体删、按关系删、按文档ID删（会做智能清理与增量重建）
  • 合并实体：merge_entities(...)，可自定义合并策略（description拼接、source_id去重等）

这意味着它不是“抽完就死”的一次性图，而是可以持续演化的知识底座。

多模态：通过RAG-Anything接入PDF图片表格公式

LightRAG通过与RAG-Anything集成，扩展到多模态文档处理：

  • 支持PDF/Office/图片等
  • 解析图像、表格、公式
  • 多模态知识图谱与跨模态关系抽取
  • 仍然回到LightRAG的RAG管线里使用

可观测与评估：Langfuse + RAGAS

  • Langfuse：提供对OpenAI兼容调用的自动Tracing（提示与响应链路、token、延迟、成本等）
  • RAGAS：提供基于RAGAS的评估脚本，并且API更新为“返回检索到的contexts”，方便做context precision等指标

效果对比：在不同领域问“高层次问题”，LightRAG整体胜率更高

文档给出了总体对比表，评估维度是：Comprehensiveness、Diversity、Empowerment以及Overall；在Agriculture/CS/Legal/Mix等集合上，LightRAG对比NaiveRAG、RQ-RAG、HyDE、GraphRAG，多数指标上取得更高比例（表格原文已给出）。

同类项目推荐（最后也给你一张“生态地图”）

除了LightRAG本体，仓库列出了同生态的三个方向型项目（各有所长）：

1）RAG-Anything（Multimodal RAG）
主打“一体化多模态RAG”，面向文本、图片、表格、公式等混合内容的解析与检索增强；适合你要做“读PDF与复杂文档”的知识库。

2）VideoRAG（Extreme Long-Context Video RAG）
面向“超长上下文视频理解”的RAG系统；当你的知识来源是会议录像、课程视频、长视频资料库时，视频切分+检索+生成是独立难题，它走的是这个方向。

3）MiniRAG（Extremely Simple RAG）
强调“小模型让RAG更简单”；当你希望降低模型成本、追求更轻量的RAG原型或边缘部署思路，可以关注这个分支路线。

参考地址：

  • • https://github.com/HKUDS/LightRAG

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

https://img-blog.csdnimg.cn/img_convert/05840567e2912bcdcdda7b15cba33d93.jpeg

在这里插入图片描述

为什么要学习大模型？

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

在这里插入图片描述

在这里插入图片描述

大模型入门到实战全套学习大礼包

1、大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

img

2、大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

在这里插入图片描述

3、AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

img

4、大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

img

5、大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

img

适用人群

在这里插入图片描述

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么？
  • 大模型是怎样获得「智能」的？
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例：向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范
  • …
第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示（Embeddings）
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署
  • …
第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2：手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建
  • …
第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身：基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例：如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案
  • …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

https://img-blog.csdnimg.cn/img_convert/05840567e2912bcdcdda7b15cba33d93.jpeg

# 学习 # 人工智能 # 架构 # RAG
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

项目介绍 MATLAB实现基于蟑螂算法（CSA）进行无人机三维路径规划的详细项目实例（含模型描述及部分示例代码） 专栏近期有大量优惠 还请多多点一下关注 加油 谢谢 你的鼓励是我前行的动力 谢谢支持

avatar AtomGit开源社区

《向诸葛亮借智慧》在AI转型管理上的应用价值分析

赵玉平教授在《向诸葛亮借智慧》一书中，从管理学和心理学角度出发，运用人力资源管理和组织行为学的知识，对诸葛亮的一生进行了深入解读

avatar AtomGit开源社区

2026年山东大学软件学院创新项目实训博客（一）

本阶段完成了从产品设计到可运行前端骨架的落地，核心是在信息架构、技术栈与分层规范上做出一组与当前阶段匹配的选择。统一 SPA + 双布局壳：同一套路由下区分桌面与移动，全局 AI 挂在布局层，避免对话入口被弱化。：在开发效率与一期复杂度之间折中，并遵循一期暂缓重型数据获取库的约定。分层与协作约定：页面拼装、业务进 feature、请求进服务层，降低后续并行开发与联调冲突。认证与 HTTP 占位：先

avatar AtomGit开源社区