graphrag

阶段一-图数据库基础与PropertyGraph模型在深入图数据库的技术细节之前，必须首先厘清一个常见的概念混淆：知识图谱 ≠ 图数据库。知识图谱是一种知识组织与表示方式，它关注的是如何将现实世界中错综复杂的实体及其之间的关系结构化地表达出来；而图数据库是一种数据存储与查询引擎，它为知识图谱的落地提供了底层的技术支撑。换言之，知识图谱是"要表达什么"，图数据库是"怎么存储和查询"。

阶段二-Cypher查询语言详解Cypher是一种声明式图查询语言（Declarative Graph Query Language），最初由Neo4j团队设计，后来逐步演变为开放标准openCypher。其最显著的特点是采用"ASCII艺术"（ASCII Art）语法风格——用简单的键盘符号组合来直观地描绘图的结构，使得查询语句本身就像一幅微缩的图谱。

知识的外挂：分块、Embedding、Rerank、GraphRAG 与多路融合 —— RAG 检索增强六脉RAG 是大模型接入外部知识的核心架构。本文从文档分块 Chunking、向量化 Embedding、检索 Rerank、GraphRAG 图谱增强、多路召回与融合、生产级 RAG 流水线六个切口，给出源码级实现与企业级 RAG 决策框架。

干掉幻觉实战：如何构建企业级知识图谱增强 RAG本文约 7200 字，读完大约需要 18 分钟如果你在生产环境部署过 RAG 系统，一定踩过这样的坑：

GraphRAG vs 传统向量RAG：Spring AI实战对比传统向量RAG找答案快，但多跳推理弱。GraphRAG能理清实体关系，但构建成本高。什么时候用什么？看完这篇你就清楚了。

GraphRAG 层级聚类中的“孤儿社区“：为什么有些 Community 没有 PARENT_OF 边在使用 GraphRAG 构建知识图谱后，查询某个 community 节点时发现它没有任何 PARENT_OF 关系——既没有父级，也没有子级。但图中明明存在大量 PARENT_OF 边。为什么这个 community 被"遗忘"了？

GraphRAG 深度解析：从原理到实战GraphRAG 是微软开源的图检索增强生成框架，核心是以知识图谱为核心存储与检索单元，用实体 - 关系（节点 - 边）结构替代传统 RAG 的文本块，实现多跳推理、可解释检索与精准上下文合成，解决复杂场景下传统 RAG 的痛点。

Neo4j 超详细入门Neo4j 是全球最主流、原生高性能属性图数据库，专门存储节点 - 关系 - 属性的图结构数据，是 GraphRAG、知识图谱、多跳推理系统的标准底层存储底座。

Graph Retrieval-Augmented Generation: A Survey近年来，检索增强生成（RAG）技术在无需重新训练的情况下，成功解决了大语言模型（LLM）面临的诸多难题。通过调用外部知识库，RAG 能够优化大语言模型的输出结果，有效缓解模型幻觉、领域专业知识匮乏以及信息过时等问题。

企业什么时候应采用 GraphRAG，什么时候普通 RAG 已足够？企业在建设知识问答、智能搜索或 AI 助手时，常见的问题并不只是模型能力不足，而是没有区分不同类型的知识处理需求。并非所有场景都需要 GraphRAG，也并非普通 RAG 可以覆盖全部企业问题。二者适用的前提、处理的对象以及能够解决的问题，本质上并不相同。

第十三章：RAG知识库开发之【GraphRAG 从基础到实战】随着大语言模型（LLM）的快速发展，检索增强生成（RAG）已成为解决模型“幻觉”、引入外部知识的核心技术，广泛应用于智能问答、知识库构建、智能运维等场景。传统基于向量的 RAG（Vector RAG）虽能实现语义检索，但存在知识碎片化、缺乏逻辑关联、多跳推理能力弱等痛点，难以满足复杂场景下的精准检索与推理需求。

GraphRAG【部署 01】Linux环境安装部署GraphRAG并使用Ollama本地大模型话不多说，先上 GitHub 文档地址：https://microsoft.github.io/graphrag/get_started/，本次在 Linux 环境下进行一次安装测试，环境说明：

GraphRAG 和 RAG 的区别：企业知识问答什么时候该升级到 GraphRAG摘要：GraphRAG 不是“更贵的 RAG”，而是面向复杂关系、多跳推理、全局总结和答案可追溯场景的一种增强路线。对企业来说，是否需要 GraphRAG，关键不在于追热点，而在于你的知识是否存在跨文档关联、权限约束、解释要求和复杂业务链路。

深度解析检索增强三核心：普通RAG、GraphRAG与NL2SQL在大模型应用落地过程中，“幻觉”“知识过时”“无法对接业务数据”是三大核心痛点——大模型虽具备强大的自然语言理解与生成能力，但自身知识库固定（无法实时更新）、缺乏逻辑推理能力（尤其多跳关系）、无法直接操作结构化数据（如数据库）。而检索增强技术（Retrieval-Augmented Generation, RAG），正是解决这些痛点的关键方案。

Java后端的Ai之路

【RAG技术】- RAG系统调优手段之GraphRAG（全局视野）摘要：你是否遇到过 AI 在面对“这篇文章的主旨是什么？”或者“19 世纪的艺术运动如何影响了 20 世纪？”这类宏观问题时显得力不从心？传统的 Naive RAG 往往只关注局部片段，而 GraphRAG 通过构建知识图谱和社区摘要，为 AI 开启了“上帝视角”。本文将带你深度拆解 GraphRAG 的原理、流程及进阶方案，更有 Python 代码实战，让你一文掌握这项前沿技术！

中杯可乐多加冰

RAG 深度实践系列（三）：RAG 技术演变与核心架构的深度剖析检索增强生成（RAG）技术的发展史，是一部不断挑战大型语言模型（LLM）局限性、追求系统级智能的演进史。RAG 的演变并非简单的功能叠加，而是对“如何高效、可靠地将外部知识融入 LLM 推理过程”这一核心问题的持续探索。我们可以将 RAG 的演进脉络划分为四个清晰的阶段：Naive RAG 确立基本范式，Advanced RAG 聚焦精细化优化，Modular RAG 追求架构灵活性，最终 Agentic RAG 实现自主决策与智能化。

LangGraph：让AI学会“回头是岸”的智能体架构在大模型应用开发的早期，我们像工厂老板一样，把AI当作一条高效但死板的流水线：输入进来，经过A、B、C几个固定工位，最后吐出结果。这种DAG（有向无环图）模式确实快，可一旦任务复杂一点，比如需要反复试错、中途查资料、甚至“我刚才说错了”，这套系统就直接宕机。LangChain早期的Chain设计正是如此——线性、脆弱、没有“后悔药”。

北京地铁1号线

1.3 元数据（Metadata）管理在RAG中，元数据是“关于数据块的数据”。它不仅仅是附加信息，而是实现精准检索、可信溯源和高效过滤的关键。

从 Louvain 到 Leiden：保证社区连通性的社区检测算法研究解读因为有 GraphRAG 的需求，其中涉及到了社区检测，因此也稍微看看这一领域中常用的 Louvain 算法和 Leiden 算法。本文内容主要是对论文 From Louvain to Leiden: guaranteeing well-connected communities 的简单分析解读，其中所提到的实验数据也是来源于此论文。

讲透知识图谱Neo4j在构建Agent时到底怎么用（二）在构建面向真实业务场景的智能 Agent 时，我们很快会发现：仅靠大语言模型（LLM）和向量检索（RAG）远远不够。LLM 擅长生成流畅自然的语言，却缺乏对业务规则的精确把握；RAG 能从海量文档中召回相关信息，但无法处理需要多跳推理或结构化判断的问题。当用户问出“我是科技城的，家里空调坏了找谁？”这类问题时，系统若仅依赖关键词匹配或语义相似度，极易给出错误甚至自相矛盾的答案。