标签: #knowledge-graph
关于 GPU、LLM、MLOps、Kubernetes 以及心态的文章 · 4 篇
知识图谱工具与框架地图 — 什么时候该选什么
图数据库、RDF 与本体栈、图 RAG 框架，在过去两年里爆发式增长。链接清单已经太多，所以本文换一种做法，画一张带着诚实观点的地图。每个类别都讲清楚：拿它做什么、两三个代表性工具，以及「什么时候该选什么」— 嵌入式(Kùzu) vs 服务器(Neo4j)、形式化的 OWL/RDF vs 实用的属性图、自己搭的抽取流水线 vs Microsoft GraphRAG 那种自带电池的流水线。以及最重要的一个问题：什么时候压根就不该用图(向量
2026-07-15 · 15 分钟阅读 #tools#knowledge-graph#graph-rag#ontology#frameworks从文档到知识图谱 — 一条诚实的构建流水线
「从文档里抽出知识图谱」在演示里看起来就是一次 LLM 调用。但把客户的文档真正变成一张可查询的图，是一条六段式的流水线，而成本与痛苦的大部分不在抽取，而在实体解析。本文诚实地梳理：为什么要先定好模式(本体)、基于 LLM 的模式约束抽取(LangChain 的 LLMGraphTransformer、LlamaIndex 的 Simple/Schema/Dynamic 抽取器、Microsoft GraphRAG 的索引流水线)与传统
2026-07-15 · 15 分钟阅读 #knowledge-graph#ai#llm#data-engineeringGraph RAG 是什么 — 向量 RAG 卡壳的地方，以及它值回成本的那一刻
RAG 的标准配方(分块 → 嵌入 → 检索前 k 个)在答案完整落在某一个片段里时很好用，但在多跳问题、以及贯穿整个语料库的全局「意义建构」问题上会结构性地卡住。Microsoft 的 GraphRAG 正是瞄准这两处盲区 — 用 LLM 从语料库里抽取知识图谱，用 Leiden 算法找出社区并预先生成摘要。此后，全局问题用社区摘要的映射-归约来回答，局部问题则用以实体为中心的图探索来回答。本文梳理了向量 RAG 卡住的地方、Grap
2026-07-15 · 14 分钟阅读 #rag#graph-rag#knowledge-graph#ai#llm把客户的领域变成模型 — 从通用语言到本体
客户企业的领域知识，通常不在文档里，而是作为隐性知识存在于人的头脑中。Forward Deployed Engineer 的核心工作之一，就是把这些散落的隐性知识，变成整个团队都能共享的显式模型。本文自下而上地攀爬这道阶梯 — 从最廉价、最有价值的第一步，即 DDD 的通用语言出发，用限界上下文处理同一个单词的冲突，再用实体·值对象·聚合为名词建模。接着把人们经常混为一谈的三个词 — 分类法、本体、知识图谱 — 一一切分，并把形式栈(R
2026-07-15 · 18 分钟阅读 #ontology#knowledge-graph#domain-driven-design#architecture#forward-deployed-engineer