
LinkingMem — Graph-native RAG Engine
LinkingMem 是一个图原生 RAG 引擎,运行在 Memgraph 和 Python 堆栈(例如 LlamaIndex 和 Agno)上,以实现基于知识图谱的检索和基于事实的 LLM 回答。
https://hub.docker.com/repository/docker/khapu2906/linkingmem/general?ref=producthunt&utm_source=aipure

产品信息
更新于:2026年07月06日
什么是 LinkingMem — Graph-native RAG Engine
LinkingMem — 图原生 RAG 引擎是一个开源的 GenAI 检索系统,围绕属性图数据库设计,使用 Memgraph 作为实体和关系的核心存储。它不将数据仅视为向量索引中的块,而是强调图结构(节点、边和遍历)来为检索增强生成(RAG)构建更丰富的上下文。在实践中,它通常与 Docker 一起运行图层(Memgraph),并与集成流行 LLM/RAG 工具(如 LlamaIndex 和 Agno)的 Python 环境配对,以协调摄取、检索和生成。
LinkingMem — Graph-native RAG Engine 的主要功能
LinkingMem — 图原生RAG引擎被定位为一个检索增强生成上下文层,它将语义检索与知识图谱结构相结合,以提高答案质量,特别是对于纯向量RAG难以处理的、关系密集型和“全局性”问题。根据收集到的资料,它与现代GraphRAG模式保持一致:从文档中提取实体/关系到图谱中,支持图遍历以进行多跳检索,并将其与向量/全文搜索配对,以便应用程序可以将LLM响应基于非结构化段落和显式关系。
图原生检索(GraphRAG风格): 构建和查询实体和关系的知识图谱,以支持多跳推理和超越平面块相似度的关系感知检索。
混合搜索(向量 + 全文 + 图遍历): 结合语义向量相似度、关键词/BM25风格的全文检索和图遍历,以提高不同查询类型的召回率和准确性。
实体-关系提取管道: 使用LLM辅助提取将文档转换为结构化节点/边,从而实现“X与Y之间有什么联系?”等查询和更好的上下文组装。
RAG + 知识图谱的双重存储: 将基于嵌入的语义存储(例如,pgvector/向量数据库)与属性图数据库(例如,Neo4j/Memgraph类系统)配对,以实现互补检索。
Docker友好部署: 设计为使用容器(在GraphRAG/RAG引擎中常见)作为自托管堆栈运行,简化了本地评估和生产部署。
操作可观测性挂钩(RAG指标模式): 与更广泛的GraphRAG生态系统模式相匹配,跟踪检索/LLM延迟、令牌使用量和实体/关系计数,以监控质量和成本。
LinkingMem — Graph-native RAG Engine 的使用场景
具有关系推理能力的企业知识助手: 使用图遍历和有根据的引用,回答需要连接策略、系统、团队和项目(例如,“系统A如何依赖服务B?”)的内部问题。
技术文档和DevOps故障排除: 链接事件、运行手册、服务和依赖项,以支持多跳查询(例如,连接Docker/Kubernetes组件、部署步骤和故障模式)。
合规性、风险和审计可追溯性: 将控制、证据、所有者和要求建模为图谱,以快速检索支持文档并解释答案是如何通过链接工件得出的。
研究和文献情报: 从论文中提取实体(方法、数据集、发现)和关系(基于、比较),以实现主题/全局问题和以关系为中心的探索。
客户支持和产品问题分类: 连接工单、已知问题、组件和修复方案,以便助手不仅可以检索相似案例,还可以检索依赖链和根本原因关系。
优点
通过图遍历和显式实体链接,比仅使用向量的RAG更好地处理关系密集型和多跳问题。
混合检索(图 + 向量 + 全文)提高了各种查询风格(关键词、语义和连接性查询)的鲁棒性。
自托管/容器友好的架构符合常见的企业部署和数据治理需求。
缺点
图谱构建需要可靠的实体/关系提取,这可能会增加LLM成本/延迟,并且如果未进行调整,可能会引入噪声边。
与简单的向量数据库相比,操作双系统(图数据库 + 向量/全文存储)增加了基础设施和维护的复杂性。
质量取决于模式/本体选择和持续的维护;弱模式会降低图原生检索的优势。
如何使用 LinkingMem — Graph-native RAG Engine
1) 准备先决条件: 在您的机器上安装 Docker(Docker Engine / Docker Desktop)。确保您已准备好 LLM 提供商(例如 OpenAI API 密钥),如果堆栈需要,并确认主机上所需的端口是空闲的。
2) 拉取 LinkingMem Docker 镜像: 从官方 Docker Hub 列表拉取镜像:docker pull khapu2906/linkingmem:latest(或您打算使用的特定标签)。
3) 创建工作目录和环境文件: 创建一个项目文件夹并添加一个 .env 文件用于配置(API 密钥、数据库连接字符串、模型设置)。如果项目提供了 env.sample,请将其复制到 .env 并填写诸如 OPENAI_API_KEY 和任何图/向量存储端点的值。
4) 使用 Docker 启动所需的后端服务(图/向量/全文): 如果您的 LinkingMem 设置依赖于外部存储(常见的 GraphRAG 模式),请通过 Docker Compose 或 docker run 启动它们。典型的堆栈包括图数据库(例如 Memgraph/Neo4j),以及可选的向量/全文组件。将所有服务保持在同一个 Docker 网络上,以便 LinkingMem 可以通过容器名称访问它们。
5) 使用您的配置运行 LinkingMem 容器: 运行容器并挂载您的 .env(或传递环境变量)。示例模式:docker run -d --name linkingmem --env-file /path/to/.env -p <HOST_PORT>:<CONTAINER_PORT> khapu2906/linkingmem:latest。选择一个空闲的主机端口。
6) (可选)如果需要,更改服务端口: 如果您通过 docker-compose 部署,请更新 docker-compose.yml 中的端口映射(例如,将 80:80 更改为 <YOUR_SERVING_PORT>:80)。更改配置后,重新启动/重新创建容器以使更改生效。
7) 初始化应用程序(首次设置): 如果堆栈公开了初始化 UI/端点(RAG 仪表板中常见),请打开提供的 URL(例如 http://localhost:<HOST_PORT>/install 或文档中说明的初始化路由)并完成初始化(管理员用户、工作区、连接器)。
8) 摄取文档/构建图原生索引: 上传或注册您的数据源(文件、URL、存储库)。运行摄取管道以将实体/关系提取到知识图中,并计算块的嵌入。这通常会创建:(a) 图节点/边,(b) 块嵌入,以及 (c) 用于语义检索的向量索引。
9) 启用 GraphRAG 检索模式: 配置检索以使用图遍历 + 向量相似性(GraphRAG)。在许多 GraphRAG 系统中,查询流程是:自然语言问题 -> LLM 生成结构化图查询(例如 Cypher) -> 图执行 -> 结果与向量命中融合 -> LLM 合成最终答案。
10) 运行查询(GraphRAG + RAG): 使用 UI 或 API 提问。验证响应是否包含来自检索到的图子图和/或 top-k 块的基于事实的上下文。对于全局问题(语料库中的主题),优先选择 GraphRAG 风格的摘要,而不是简单的仅向量检索。
11) 调整检索和排名: 调整参数,例如 top-k 向量命中、图遍历深度、混合融合(BM25 + 向量 + 图)和重新排名。许多 RAG 引擎支持多种召回策略,并结合融合重新排名以提高答案质量。
12) 运行和维护: 使用 Docker 卷为您的数据库和索引持久化数据。更改环境变量、端口映射或核心配置时,请重新启动/重新创建容器。如果指标可用,请监控延迟和使用情况(检索/LLM 延迟、令牌使用、实体/关系计数)。
LinkingMem — Graph-native RAG Engine 常见问题
点击解析状态栏旁边的红色叉号,然后重新启动解析过程,查看问题是否仍然存在。如果问题依然存在,并且您的部署是本地的,则解析过程很可能是由于内存不足而被终止——尝试通过提高 docker/.env 中 MEM_LIMIT 的值来增加内存分配。











