MiniRAG · RAG 与知识检索

从香港大学走出的小模型 RAG 新范式

大语言模型（LLM）配合 RAG（检索增强生成）已成为构建 AI 应用的主流架构。然而，当你想把这些技术部署到手机、边缘设备或本地机器上时，问题就来了：GPT-4o、Claude 这类大模型太"重"了，根本跑不动。

香港大学（HKUDS）研究团队推出的 MiniRAG，正是为解决这一矛盾而生的——它专门针对**小语言模型（SLM，1B~8B 参数）**优化，让轻量级模型也能高效使用 RAG，同时仅需传统方案 25% 的存储空间。

MiniRAG Logo

图1：MiniRAG 项目标识

背景：为什么小模型做 RAG 这么难？

现有 RAG 框架（如 GraphRAG、LightRAG）普遍依赖大模型的语义理解能力来完成两个核心任务：

实体抽取：从文本中识别关键实体（人名、地名、概念等）
关系推理：判断实体之间的关联

当换成 Phi-3.5-mini（3.8B）、Qwen2.5-3B 这类小模型时，它们的语义理解能力不足——实体抽取质量断崖式下降，关系推理更是漏洞百出，导致 RAG 检索结果的相关性大幅降低。GraphRAG 甚至直接"崩溃"（生成无效响应）。

研究团队在 LiHua-World 真实评测集上验证了这一点：NaiveRAG 配合 Phi-3.5-mini 准确率仅 41.22%，LightRAG 更是跌到 39.81%。

核心创新：异构图索引 + 拓扑增强检索

MiniRAG 的设计哲学是"化繁为简"——不要求模型有强大的语义理解，而是利用图结构的拓扑信息来弥补小模型的能力不足。

创新一：语义感知的异构图索引

MiniRAG 不再要求模型从文本中提取高质量语义实体，而是将**文本块（text chunk）与命名实体（named entity）**融合到同一异构图结构中。

MiniRAG Framework

图2：MiniRAG 框架图

具体来说：

文本块作为中心节点，保留原始文档的局部上下文
命名实体作为辅助节点，通过简单规则（正则/NER）即可抽取，不依赖大模型
两类节点通过语义边和共现边相连，形成统一拓扑

这种设计让小模型不再需要"读懂"整段话，只需在图上做拓扑探索就能找到相关知识。

创新二：轻量级拓扑增强检索

MiniRAG 实现了三种检索模式：

模式	说明	适用场景
Naive	纯向量相似度检索	简单事实问答
Local	从相关实体出发，探索邻居节点	实体相关问题
Global	广度优先遍历，聚合全图	多跳推理、总结
Hybrid	融合向量检索 + 拓扑探索	复杂问题（推荐默认使用）

关键在于：图拓扑结构提供了超出语义之外的关联信息。即使小模型对某句话的语义理解有偏差，只要图结构正确，就能通过拓扑关系找到正确答案。

性能对比：MiniRAG 如何超越大模型方案

研究团队在两个基准数据集上进行了系统评测：

LiHua-World（设备端场景）

模型	NaiveRAG	LightRAG	MiniRAG
Phi-3.5-mini-instruct	41.22%	39.81%	53.29%
GLM-Edge-1.5B	42.79%	35.74%	52.51%
Qwen2.5-3B-Instruct	43.73%	39.18%	48.75%
MiniCPM3-4B	43.42%	35.42%	51.25%
gpt-4o-mini	46.55%	56.90%	54.08%

在 SLM 场景下，MiniRAG 以绝对优势领先所有竞品，提升幅度达 +10% 以上。即使是 gpt-4o-mini，MiniRAG 也以 54.08% vs 56.90% 的微弱差距紧随其后，而存储空间仅需 25%。

MultiHop-RAG（多跳推理）

模型	NaiveRAG	LightRAG	MiniRAG
Phi-3.5-mini-instruct	42.72%	27.03%	49.96%
GLM-Edge-1.5B	44.44%	/	51.41%
gpt-4o-mini	53.60%	64.91%	68.43%

在多跳推理场景下，MiniRAG 甚至超越了 LightRAG（GPT-4o-mini 场景 68.43% vs 64.91%）。

技术架构：多后端支持 + 插件化存储

MiniRAG 的代码架构高度模块化，核心层与存储层完全解耦：

MiniRAG 核心
├── minirag.py          # 主入口，定义 MiniRAG 类
├── base.py             # 存储抽象基类（KV/Vector/Graph）
├── llm.py              # LLM 调用封装（Ollama/OpenAI/LLoLLMs）
├── operate.py          # 核心操作：分块、抽取、检索
├── prompt.py           # 提示词模板
├── utils.py            # 工具函数（Embedding、logger）
├── kg/                 # 存储实现
│   ├── networkx_impl.py    # NetworkX 图存储
│   ├── nano_vector_db_impl.py  # NanoVectorDB
│   ├── json_kv_impl.py     # JSON KV
│   ├── neo4j_impl.py      # Neo4j 支持
│   ├── postgres_impl.py   # PostgreSQL+pgvector
│   └── ...（共支持 15+ 种存储后端）
└── api/                # FastAPI 服务层
    ├── minirag_server.py  # REST API 服务
    ├── static/            # Web UI（HTML/JS）
    └── minirag/api/requirements.txt

支持的存储后端（存储层插件化，通过 STORAGES 字典动态加载）：

类型	支持的后端
KV存储	JSON, Redis, MongoDB, Oracle, Neo4j, TiDB, PostgreSQL
向量存储	NanoVectorDB, Chroma, Milvus, Weaviate, PGVector
图存储	NetworkX, Neo4j, Oracle, Redis, MongoDB, TiDB, PostgreSQL, AGE, Gremlin

LLM 后端：Ollama（本地，推荐）、OpenAI（含 Azure OpenAI）、LLoLLMs

Embedding：BGE-M3（推荐）、nomic-embed-text 等 Ollama 支持的模型

上手体验：三种方式快速部署

方式一：pip 一键安装（最简）

pip install lightrag-hku

配合 Ollama（需提前安装并拉取模型）：

ollama pull mistral-nemo:latest
ollama pull bge-m3:latest
python -c "from minirag import MiniRAG; ..."

方式二：API 服务 + Web UI（推荐生产使用）

pip install "lightrag-hku[api]"
minirag-server  # 默认端口 9621

服务启动后：

Swagger 文档：http://localhost:9621/docs
Web UI：http://localhost:9621（基于 FastAPI + Static Files）
Ollama 兼容接口：POST /api/chat（可对接 Open WebUI）

方式三：Docker Compose 一键部署

git clone https://github.com/HKUDS/MiniRAG.git
cd MiniRAG
docker-compose up -d

容器默认暴露端口 9621，配置通过 .env 文件注入。

硬件需求：无 GPU 依赖，CPU 即可运行（SLM 模型推荐 4GB+ RAM），完整评测推荐配 GPU。

局限与思考

MiniRAG 并非银弹，存在以下局限：

检索质量依赖图索引质量：如果实体抽取（即使是简单 NER）失败，图结构会反映这一错误
多模态支持缺失：当前版本仅支持文本，不支持图片、PDF 内嵌图片等
评测基准有限：目前主要在 LiHua-World 和 MultiHop-RAG 上验证，其他领域（医疗、法律）的能力尚未充分评估
增量更新机制：文档更新后的图索引增量维护尚未提供，需要全量重建

行业意义

MiniRAG 的出现标志着 RAG 技术从"大模型专属"向"普惠化"演进的一个重要节点。

从趋势来看：

端侧 AI 推理需求爆发：随着端侧芯片算力提升，将 SLM + 轻量 RAG 部署到手机、汽车、IoT 设备是确定性方向
成本压力驱动架构创新：云端调用 GPT-4o 的成本远高于本地运行 Qwen2.5-3B，MiniRAG 在部分场景提供了"够用且省钱"的替代方案
图检索的价值重估：GraphRAG 沉寂一段时间后，MiniRAG 以"轻量化"思路重新激活了这一方向

论文已中选 ACL 2026，是目前小模型 RAG 方向最有影响力的工作之一。

数据来源：MiniRAG GitHub · arXiv:2501.06713

从香港大学走出的小模型 RAG 新范式

MiniRAG Logo

图1：MiniRAG 项目标识

背景：为什么小模型做 RAG 这么难？

现有 RAG 框架（如 GraphRAG、LightRAG）普遍依赖大模型的语义理解能力来完成两个核心任务：

实体抽取：从文本中识别关键实体（人名、地名、概念等）
关系推理：判断实体之间的关联

研究团队在 LiHua-World 真实评测集上验证了这一点：NaiveRAG 配合 Phi-3.5-mini 准确率仅 41.22%，LightRAG 更是跌到 39.81%。

核心创新：异构图索引 + 拓扑增强检索

MiniRAG 的设计哲学是"化繁为简"——不要求模型有强大的语义理解，而是利用图结构的拓扑信息来弥补小模型的能力不足。

创新一：语义感知的异构图索引

MiniRAG 不再要求模型从文本中提取高质量语义实体，而是将**文本块（text chunk）与命名实体（named entity）**融合到同一异构图结构中。

MiniRAG Framework

图2：MiniRAG 框架图

具体来说：

文本块作为中心节点，保留原始文档的局部上下文
命名实体作为辅助节点，通过简单规则（正则/NER）即可抽取，不依赖大模型
两类节点通过语义边和共现边相连，形成统一拓扑

这种设计让小模型不再需要"读懂"整段话，只需在图上做拓扑探索就能找到相关知识。

创新二：轻量级拓扑增强检索

MiniRAG 实现了三种检索模式：

模式	说明	适用场景
Naive	纯向量相似度检索	简单事实问答
Local	从相关实体出发，探索邻居节点	实体相关问题
Global	广度优先遍历，聚合全图	多跳推理、总结
Hybrid	融合向量检索 + 拓扑探索	复杂问题（推荐默认使用）

性能对比：MiniRAG 如何超越大模型方案

研究团队在两个基准数据集上进行了系统评测：

LiHua-World（设备端场景）

模型	NaiveRAG	LightRAG	MiniRAG
Phi-3.5-mini-instruct	41.22%	39.81%	53.29%
GLM-Edge-1.5B	42.79%	35.74%	52.51%
Qwen2.5-3B-Instruct	43.73%	39.18%	48.75%
MiniCPM3-4B	43.42%	35.42%	51.25%
gpt-4o-mini	46.55%	56.90%	54.08%

MultiHop-RAG（多跳推理）

模型	NaiveRAG	LightRAG	MiniRAG
Phi-3.5-mini-instruct	42.72%	27.03%	49.96%
GLM-Edge-1.5B	44.44%	/	51.41%
gpt-4o-mini	53.60%	64.91%	68.43%

在多跳推理场景下，MiniRAG 甚至超越了 LightRAG（GPT-4o-mini 场景 68.43% vs 64.91%）。

技术架构：多后端支持 + 插件化存储

MiniRAG 的代码架构高度模块化，核心层与存储层完全解耦：

MiniRAG 核心
├── minirag.py          # 主入口，定义 MiniRAG 类
├── base.py             # 存储抽象基类（KV/Vector/Graph）
├── llm.py              # LLM 调用封装（Ollama/OpenAI/LLoLLMs）
├── operate.py          # 核心操作：分块、抽取、检索
├── prompt.py           # 提示词模板
├── utils.py            # 工具函数（Embedding、logger）
├── kg/                 # 存储实现
│   ├── networkx_impl.py    # NetworkX 图存储
│   ├── nano_vector_db_impl.py  # NanoVectorDB
│   ├── json_kv_impl.py     # JSON KV
│   ├── neo4j_impl.py      # Neo4j 支持
│   ├── postgres_impl.py   # PostgreSQL+pgvector
│   └── ...（共支持 15+ 种存储后端）
└── api/                # FastAPI 服务层
    ├── minirag_server.py  # REST API 服务
    ├── static/            # Web UI（HTML/JS）
    └── minirag/api/requirements.txt

支持的存储后端（存储层插件化，通过 STORAGES 字典动态加载）：

类型	支持的后端
KV存储	JSON, Redis, MongoDB, Oracle, Neo4j, TiDB, PostgreSQL
向量存储	NanoVectorDB, Chroma, Milvus, Weaviate, PGVector
图存储	NetworkX, Neo4j, Oracle, Redis, MongoDB, TiDB, PostgreSQL, AGE, Gremlin

LLM 后端：Ollama（本地，推荐）、OpenAI（含 Azure OpenAI）、LLoLLMs

Embedding：BGE-M3（推荐）、nomic-embed-text 等 Ollama 支持的模型

上手体验：三种方式快速部署

方式一：pip 一键安装（最简）

pip install lightrag-hku

配合 Ollama（需提前安装并拉取模型）：

ollama pull mistral-nemo:latest
ollama pull bge-m3:latest
python -c "from minirag import MiniRAG; ..."

方式二：API 服务 + Web UI（推荐生产使用）

pip install "lightrag-hku[api]"
minirag-server  # 默认端口 9621

服务启动后：

Swagger 文档：http://localhost:9621/docs
Web UI：http://localhost:9621（基于 FastAPI + Static Files）
Ollama 兼容接口：POST /api/chat（可对接 Open WebUI）

方式三：Docker Compose 一键部署

git clone https://github.com/HKUDS/MiniRAG.git
cd MiniRAG
docker-compose up -d

容器默认暴露端口 9621，配置通过 .env 文件注入。

硬件需求：无 GPU 依赖，CPU 即可运行（SLM 模型推荐 4GB+ RAM），完整评测推荐配 GPU。

局限与思考

MiniRAG 并非银弹，存在以下局限：

检索质量依赖图索引质量：如果实体抽取（即使是简单 NER）失败，图结构会反映这一错误
多模态支持缺失：当前版本仅支持文本，不支持图片、PDF 内嵌图片等
评测基准有限：目前主要在 LiHua-World 和 MultiHop-RAG 上验证，其他领域（医疗、法律）的能力尚未充分评估
增量更新机制：文档更新后的图索引增量维护尚未提供，需要全量重建

行业意义

MiniRAG 的出现标志着 RAG 技术从"大模型专属"向"普惠化"演进的一个重要节点。

从趋势来看：

端侧 AI 推理需求爆发：随着端侧芯片算力提升，将 SLM + 轻量 RAG 部署到手机、汽车、IoT 设备是确定性方向
成本压力驱动架构创新：云端调用 GPT-4o 的成本远高于本地运行 Qwen2.5-3B，MiniRAG 在部分场景提供了"够用且省钱"的替代方案
图检索的价值重估：GraphRAG 沉寂一段时间后，MiniRAG 以"轻量化"思路重新激活了这一方向

论文已中选 ACL 2026，是目前小模型 RAG 方向最有影响力的工作之一。

数据来源：MiniRAG GitHub · arXiv:2501.06713