本文以软件工程和AI系统架构视角深入解析知识库、RAG、向量数据库、图数据库、知识图谱及GraphRAG等核心概念。内容涵盖各术语定义、知识加工成AI可检索知识的流程、向量生成与数据库检索原理、图数据库存储查询方式、知识图谱构建方法以及RAG和GraphRAG的协作机制和技术组件选择。适合熟悉传统数据库和软件开发但缺乏大模型知识库实际工程经验的学习者建议收藏后系统学习。我们从软件工程和 AI 系统架构的角度把知识库、RAG、向量数据库、图数据库、知识图谱、GraphRAG 这几个概念完整梳理一遍。我会假设你熟悉传统的数据库、SQL 和软件开发但没有接触过大模型知识库的实际工程实现。我们不仅解释概念还要弄清楚它们各自是什么英文全称是什么解决什么问题。一段 Word、PDF 文档是怎么被加工成 AI 可以检索的知识的。向量是怎么生成的向量数据库到底保存了什么怎样搜索。图数据库保存什么、如何查询知识图谱又是如何构建出来的。RAG 和 GraphRAG 从用户提问到大模型回答代码和组件是怎么协作的。真正开发一个知识库系统需要哪些技术组件什么情况下选择哪一种架构。一、先把这些英文术语搞清楚这是理解后面所有技术的基础。中文名称英文名称及缩写本质是什么知识库Knowledge BaseKB一套知识的存储、组织与使用体系大语言模型Large Language ModelLLM能理解和生成自然语言的 AI 模型检索增强生成Retrieval-Augmented GenerationRAG一种结合外部知识检索与大模型生成的技术架构向量数据库Vector DatabaseVector DB专门支持向量存储和相似性检索的数据库图数据库Graph DatabaseGraph DB以节点、边等图结构管理和查询数据的数据库知识图谱Knowledge GraphKG用实体及其关系组织知识的结构化表示图检索增强生成Graph Retrieval-Augmented GenerationGraphRAG在 RAG 中利用图结构进行知识检索与组织的一类方法向量嵌入Embedding / Vector Embedding把文本等对象转换成能够进行数学运算的向量表示嵌入模型Embedding Model负责生成向量的模型语义搜索Semantic Search按照内容含义而不只是字面关键词进行搜索重排序Reranking对初步检索到的结果重新评估相关性并排序混合检索Hybrid Search结合关键词、向量等多种检索方式其中有个非常重要的区别知识库是系统或知识集合RAG 是技术架构向量数据库和图数据库是存储查询组件知识图谱是知识的组织形式GraphRAG 则是一类利用图结构增强检索生成的方法。它们不处在同一个技术层级。你可以把它们理解成软件系统里面的不同角色有的是整个应用有的是实现方案有的是底层基础设施。二、先看它们之间的整体关系典型 AI 知识库系统架构概念示意知识图谱不必使用图数据库存储GraphRAG 也不一定需要独立的图数据库。图中展示的是一种常见组合而非唯一架构。这里你只需要先记住一个关系RAG 是大框架向量检索 RAG 和 GraphRAG 是不同的实现思路它们既可以分别使用也可以混合使用。接下来我们先从最基础的知识库开始一层一层拆到具体的工程实现。三、Knowledge Base知识库到底是什么先说知识库因为这是最大的概念。知识库Knowledge BaseKB并不是 AI 时代才出现的东西。传统的软件帮助中心、FAQFrequently Asked Questions常见问题、技术文档库、百科网站本质上都可以算知识库。传统知识库通常是文档 → 数据库或搜索引擎 → 用户搜索 → 返回文档AI 知识库可以变成文档 → 知识加工与索引 → 检索相关知识 → 大模型理解和组织 → 返回自然语言答案例如把一百份产品说明书放进知识库。用户问“设备指示灯一直闪红色怎么办”传统搜索一般返回几篇可能包含“指示灯”“红色”的说明文档。AI 知识库则可能直接回答“根据设备说明书第 12 页红灯连续闪烁表示设备过热需要停止运行并检查散热条件。”但这里有个容易产生误解的地方知识库不是把一百份 Word 直接交给大模型让模型全部记住。工程实现通常会先加工这些文档建立可以高效查询的索引。用户提问时只找出相关的一小部分内容交给大模型回答。当然也可以通过模型微调让模型学习特定领域的知识但微调Fine-tuning与基于外部知识检索的 RAG 是不同路线。两者也能够组合。四、Embedding为什么文本能够变成数字这是理解向量数据库的关键。1. 什么叫向量数学上的向量可以简单理解成一组有顺序的数字。例如A [0.2, 0.8, 0.1] B [0.3, 0.7, 0.2] C [0.9, 0.1, 0.8]上面是三个三维向量。如果只有三个维度我们还可以想象成三维空间中的三个点。但真正的文本 Embedding 模型可能输出 384、768、1024、1536 等不同维度的向量具体取决于模型。例如一句话被编码成原文 我买的手机坏了怎么退货Embedding 模型处理后[0.012, -0.183, 0.275, ..., 0.091]假设输出维度为 768这是一个示意数值并不是真实模型计算结果。你可能会问一句中文为什么能变成 768 个数字这些数字分别表示什么2. Embedding 模型是怎么工作的Embedding Model嵌入模型通常是一个经过训练的神经网络。它不是按照简单的字典把“手机”转换成 001、“退货”转换成 002。真实过程要复杂得多。这里的 Token简单说是模型处理文本的基本单位。它不一定等于一个字或一个单词也可能是词的一部分。训练过程中模型会学习如何把语义相关的内容映射到向量空间中较接近的位置。例如“怎么申请退款”“购买商品后如何办理退货”两句话虽然用词不一样但语义比较相近经过合适的 Embedding 模型编码后向量通常也比较接近。不过不能把每一个维度机械地理解成一个固定的词义标签比如第一维代表手机、第二维代表退款。实际模型学习到的是分布式的特征表示通常无法直接逐维解释。3. 向量之间怎么判断相似常见方法是余弦相似度Cosine Similarity。公式是简单理解就是比较两个向量的方向有多接近。对于非零向量余弦相似度的数学范围为 -1 到 1。余弦相似度的直观理解用二维方向演示余弦相似度非真实文本向量。此外还有Euclidean Distance欧氏距离衡量空间中的直线距离。Dot Product点积或内积用于衡量向量的相关性。Cosine Distance余弦距离常见定义为 1 减去余弦相似度。不同 Embedding 模型对相似度指标的适配方式可能不同不是所有模型都适合统一使用一个算法。还有一点很重要相似度不是正确率。两句话的余弦相似度很高不代表它们表达的事实相同。比如“设备已启动”和“设备未启动”包含大量相同词语向量仍有可能接近。五、Vector Database向量数据库内部究竟保存了什么这里用熟悉的数据库表来理解。假设有一本产品使用手册我们先把它分成多个小段再逐段生成向量。数据库中的逻辑结构可能是chunk_idcontent文本片段embedding向量source001设备开机时需要按住电源键……[0.12, 0.36, …]manual.pdf002红色指示灯闪烁表示过热……[0.23, 0.18, …]manual.pdf003设备恢复出厂设置的方法……[0.74, 0.51, …]manual.pdf其中embedding字段不是普通的 VARCHAR而是向量数据类型或数据库内部定义的向量结构。实际工程上还经常保存document_id、chunk_id、page_no、title、text、embedding、metadata、version这里有两个重要知识点。1. 文本切块ChunkingChunk 是“块、片段”的意思Chunking 就是把长文档切分成较小的文本块。为什么要切因为一本几十万字的手册不能每次都原样交给模型搜索和回答。把整个文档编码为一个向量也容易丢失局部细节。因此可能采用原始文档 | |-- Chunk 1产品功能介绍 |-- Chunk 2设备安装步骤 |-- Chunk 3设备开机流程 |-- Chunk 4指示灯故障说明 |-- Chunk 5恢复出厂设置工程上常使用 Token 数控制切块大小例如每块 500 Token 左右或者按自然段、标题、章节切分。还可能设置 Overlap重叠让相邻块共享一部分文字避免关键内容恰好被切断。但切块也不是越小越好切得太小上下文被破坏切得太大相关内容不够集中还增加检索与模型处理成本。对于 PDF还要考虑表格跨页、标题层级、图片和扫描件等问题。很多知识库实际效果不好并不是大模型不行而是前面的文档解析和切块就已经把知识处理坏了。2. 向量数据库为什么检索速度快假设有一千万条文本向量。最直接的办法是把用户问题也变成向量逐一计算它和一千万个向量的距离再排序取前十条。理论上能做但计算量很大。于是出现了 ANNANN Approximate Nearest Neighbor近似最近邻搜索。这里的“近似”指为了提升速度允许在一定程度上牺牲召回精度并不意味着生成的答案一定是近似或错误的。一个很常见的索引算法是 HNSWHNSW Hierarchical Navigable Small World分层可导航小世界图。它的思想可以理解为建立多层向量导航网络先在稀疏的高层快速定位再逐渐进入更密集的底层寻找附近的向量。你可以把它想象成从全国地图找到城市 → 从城市找到街区 → 从街区找到目标附近的位置。HNSW 并不是唯一选择但在向量数据库中非常常见。Weaviate和 pgvector 的官方技术文档都提供了 HNSW 索引的实现或支持。这里还有一个特别容易混淆的地方HNSW 虽然也使用“图”结构但它不是知识图谱。HNSW 图里的边表示向量搜索时建立的邻近导航连接。知识图谱里的边表示有具体业务含义的关系例如“张三出演电影 A”。两种图的含义完全不同。3. 从 SQL 角度理解向量检索假设使用 PostgreSQL 加 pgvector 扩展。下面是一段简化的教学示例CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE kb_chunks ( id BIGINT PRIMARY KEY, content TEXT, embedding VECTOR(3) );-------------------INSERT INTO kb_chunks VALUES (1, 设备开机说明, [0.1,0.2,0.3]), (2, 设备故障说明, [0.2,0.3,0.4]), (3, 设备维护说明, [0.8,0.1,0.2]); -------------------------CREATE INDEX idx_kb_embedding ON kb_chunks USING hnsw (embedding vector_cosine_ops); --------------------SELECT id, content, embedding [0.2,0.2,0.3] AS distance FROM kb_chunks ORDER BY embedding [0.2,0.2,0.3] LIMIT 2;---------------------------这里VECTOR(3)三维向量类型真实项目按模型输出维度设置。hnsw向量索引类型。pgvector 的余弦距离运算符。LIMIT 2返回距离最近的两条记录也就是 Top-K 检索中的 K2。pgvector 官方文档提供了这些 SQL 运算符和索引语法。注意示例中的三个向量是手动填写的教学数据。实际工程中不会让程序员手工写向量而是调用 Embedding 模型批量生成。六、RAG从上传文档到 AI 回答完整发生了什么现在就可以真正理解 RAG 了。RAG Retrieval-Augmented Generation。拆开看三个单词Retrieval检索从外部知识源寻找相关信息。Augmented增强给模型补充检索到的上下文。Generation生成让语言模型根据问题和上下文产生回答。RAG 本身不是某个数据库产品也不是某个大模型。它是一种组织整个问答过程的架构。在工程实现上通常可以拆成两条相对独立的处理链路。第一条离线知识加工链路Indexing Pipeline这条链路可以在用户提问前预先执行也可以在文档新增、修改后增量执行。并不是每问一次问题都要重新解析所有文档、计算全部向量。第二条在线问答链路Query Pipeline用户提问“设备出现红灯闪烁怎么办”真正体现 RAG 原理的是第 5 步。例如程序把这些内容拼接成发给大模型的 Prompt系统指令 请根据提供的参考资料回答。 资料没有说明的内容不要自行编造。 回答时注明资料来源。 参考资料 [文档1 - 第12页] 红色指示灯连续闪烁表示设备温度过高。 应停止运行并检查散热情况。 用户问题 设备出现红灯闪烁怎么办大模型这时就不需要凭训练时记住的知识去猜而是有了明确的外部参考资料。不过RAG 只能降低无依据回答的风险不能完全消除幻觉Hallucination。如果检索结果本来就错了模型仍可能生成错误答案。RAG 最关键的几个工程认识第一RAG 不等于向量检索。RAG 完全可以使用全文搜索引擎、SQL 数据库、API、图数据库等检索知识不是必须有向量数据库。第二RAG 不需要重新训练大模型。常规 RAG 的知识更新主要发生在外部数据与索引层。新增文档后重新解析、切块、向量化并更新索引即可。第三Embedding 模型和 LLM 是两个不同角色。Embedding 模型负责把文本编码成向量LLM 负责生成回答。它们可以是不同模型也可以来自同一个模型体系但职责不同。第四向量检索不应该完全代替关键词检索。例如查询具体错误码ERR-4098、零件编号ABX-734精确词匹配往往更有价值。因此实际工程常用 Hybrid Search混合检索结合 BM25 等关键词检索算法和向量检索再用 Reranker重排序模型重新排序。七、Graph Database图数据库到底是怎么存储数据的现在进入另一个技术体系——图数据库。Graph Database简称 Graph DB。比较有代表性的产品包括 Neo4j、NebulaGraph等。先说一个核心区别传统关系型数据库擅长存储实体的属性以及通过表和关联字段表达关系。图数据库则把实体之间的关系作为一等公民直接用节点和边来表示。1. 图数据库有三个核心概念Node节点用来表示对象。例如人物、电影、城市、产品、事件等。Relationship / Edge关系或边用来表示两个节点之间的联系。例如演员 — 出演 → 电影导演 — 执导 → 电影Property属性用于描述节点或者关系。例如电影节点可以包含名称、上映年份等属性出演关系可以包含角色名称。我们用一个完全虚构的电影世界举例。电影人物关系图示意图只表示虚构的电影、演员及导演关系。如果使用关系型数据库可能设计为PERSON 人员表 MOVIE Neo4j 使用的主要查询语言叫 Cypher。 它和 SQL 一样属于声明式查询语言你描述需要匹配的关系模式数据库执行相应的查询。 例如查询出演了《星海远航》的演员 MATCH (p:Person)-[:ACTED_IN]-(m:Movie) WHERE m.title 星海远航 RETURN p.name;查询出演《星海远航》的演员还出演过哪些电影以及那些电影的导演MATCH (p:Person)-[:ACTED_IN]-(m1:Movie) WHERE m1.title 星海远航 MATCH (p)-[:ACTED_IN]-(m2:Movie) MATCH (d:Person)-[:DIRECTED]-(m2) WHERE m2 m1 RETURN p.name AS actor, m2.title AS other_movie, d.name AS director;这个 SQL 风格的MATCH图模式查询就是 Cypher 的典型特点。我们在做什么实际上就是顺着图中的关系走电影 A ← 演员 → 电影 B ← 导演这样的操作叫做 Traversal图遍历。跨越多个关系进行查询可以叫 Multi-hop Query多跳查询。不过这并不意味着图数据库总比关系型数据库快。对于简单查询、规整的表结构、聚合统计关系型数据库往往完全够用。图数据库的优势主要体现在关系网络复杂、需要频繁进行路径查询或多跳遍历时。八、Knowledge Graph知识图谱与图数据库为什么不是一回事这个地方需要区分两个层面。知识图谱Knowledge Graph是一种对知识进行建模和组织的方式。图数据库Graph Database是能够存储、管理和查询图数据的数据库系统。例如我们设计了一个电影知识图谱定义Person人物。Movie电影。ACTED_IN出演关系。DIRECTED执导关系。然后把真实或虚构的电影信息转换成节点和关系。这个过程称为 Knowledge Graph Construction知识图谱构建。工程上通常包括几个步骤。这里还有几个工程术语NER Named Entity Recognition命名实体识别。Entity Linking 实体链接或实体对齐识别不同文本提到的是否是同一对象。Relation Extraction 关系抽取从文本中识别实体之间的关系。Schema 模式定义规定哪些类型的实体、属性与关系是允许的。知识图谱可以通过程序规则、NLPNatural Language Processing自然语言处理模型或者 LLM 从文档中抽取但自动抽取会出错。例如“张明否认自己出演了电影 A。”如果模型没有正确理解“否认”错误抽取为张明 → 出演 → 电影 A那么知识图谱就已经产生了错误事实。所以一个可靠的知识图谱系统还需要保存来源、置信度、时间信息必要时进行人工校验和实体融合。图谱数据最终可以存储在 Neo4j也可以用关系型数据库、RDF 三元组存储等技术来管理不一定非要图数据库。九、GraphRAG它比普通 RAG 多做了什么到这里我们已经分别理解了 RAG 和知识图谱。GraphRAG 就比较好理解了。它不是完全推翻 RAG而是在检索和组织知识的过程中引入了图结构的能力。我们还是用电影例子。假设有两份文档文档 A《星海远航》由林辰执导苏遥担任主演。文档 B苏遥还出演了《月球来客》该片导演为何川。用户提问“《星海远航》的主演还出演了哪部电影那部电影的导演是谁”普通向量 RAG 可能怎么处理首先把整句话向量化搜索相似文本。由于文档 A 包含“星海远航”可能被检索出来。但文档 B 没有提到“星海远航”如果检索策略不够好文档 B 就可能被遗漏。这样模型只知道苏遥出演《星海远航》却没有其他电影的信息。当然普通 RAG 也可以通过扩大召回范围、查询改写、多次检索等手段解决这个问题。并不是说只有 GraphRAG 才能回答。GraphRAG 可能怎么处理GraphRAG 可以先识别电影实体《星海远航》然后沿着关系图查询然后把查到的相关关系和文档原文交给 LLM让它生成自然语言答案。你会发现GraphRAG 并不是让模型凭空具有某种神奇的推理能力而是利用已构建的关系网络更有针对性地发现和组织检索证据。十、微软的 GraphRAG还有一种更深入的做法这里需要专门讲一下因为很多文章一提 GraphRAG就在讲微软的开源项目。微软 GraphRAG 项目中的一种典型实现不只是“图数据库 RAG”。它更强调从大量非结构化文档中抽取图结构再通过图社区和预生成的摘要支持局部或全局知识查询。其标准索引流程可以概括成微软官方的索引架构包括实体关系抽取、社区检测、社区报告生成和 Embedding 等环节。默认实现的部分结构化输出使用 Parquet 文件保存向量数据进入配置的向量存储。这里多了一个很有意思的技术Community Detection社区检测。社区检测是什么假设知识图谱里有十万个实体和几十万条关系。其中一批实体主要与太空电影相关另一批与音乐电影相关还有一批与动漫作品相关。社区检测算法会根据图中的连接情况识别出关系较紧密的节点群体。图社区聚类概念示意社区是根据图连接结构识别的节点集合并不一定天然对应人工划分的主题。构建好社区后可以让大模型对不同社区的知识生成摘要。例如社区 A 主要讨论太空题材电影。社区 B 主要讨论音乐题材电影。社区 C 主要讨论电影制作人员之间的合作关系。这些描述是模型根据社区内容生成的概括不是社区检测算法直接理解出来的语义。微软 GraphRAG 的几种查询方式查询方式英文主要用途局部搜索Local Search围绕特定实体查找邻居、关系、关联文本全局搜索Global Search结合社区摘要回答跨文档的总体问题基础搜索Basic Search基于传统文本向量检索DRIFT 搜索Dynamic Reasoning and Inference with Flexible Traversal结合局部实体搜索与更广泛的社区信息例如提问“《星海远航》的主演是谁”适合 Local Search。如果问“这批电影资料整体反映了哪些主要题材和创作趋势”就可能适合 Global Search。微软的全局搜索方法会基于社区报告生成中间结果再汇总形成最终回答采用类似 Map-Reduce 的处理思路。不过GraphRAG 的图谱抽取、社区划分、摘要生成会增加索引构建的模型调用量与维护成本。文档规模很小、问题很简单时完全没必要一上来就采用这种复杂架构。十一、工程实践真正开发一个 RAG 系统需要多少组件现在假设你要自己开发一个最基础的智能知识问答应用。前端是一个网页用户可以上传文档并提问。我建议先不要上 GraphRAG只做最基础的 RAG这样技术链路最容易理解。推荐的入门技术组合模块可以采用的技术职责后端接口Python FastAPI提供上传文档、问答 API文档解析PyMuPDF、python-docx提取 PDF、Word 中的内容文本切块Python 代码或文本切分组件将文档分成 Chunk向量模型BGE、其他 Embedding 模型或模型 API生成向量向量存储PostgreSQL pgvector保存向量并支持相似性查询大语言模型本地或云端 LLM生成自然语言回答前端Vue、React 等提供上传和聊天界面这并不是唯一组合。Milvus、Qdrant 等专用向量数据库也可以替代 pgvector。真正上线时还需要文档版本管理、失败重试、引用来源、日志监控、权限过滤、检索效果评估等工程能力。那么升级 GraphRAG 需要加什么主要增加三个部分图谱构建模块抽取实体、关系完成实体融合。图结构存储与检索模块管理实体、边、图查询。检索编排模块结合用户问题决定用向量检索、图检索还是两者混合。还有一个值得注意的工程事实图数据库和向量数据库不一定要分别部署。部分图数据库已经支持向量索引部分应用也会把实体关系和向量存储组合在同一个数据平台中。因此设计系统时应该先确定检索能力和数据模型再决定物理上需要几个数据库。十二、这些架构到底该怎么选择把前面所有概念放到实际工程决策中可以得到这样一张表。需求场景优先考虑原因几十份 FAQ、简单帮助文档问答关键词搜索或简单 RAG需求简单不必过度设计几千份 PDF、Word 智能问答向量 RAG 关键词检索主要任务是寻找相关文档证据产品说明、错误码、型号精确查询混合检索 RAG同时需要语义和精确匹配人物关系、关系路径、复杂关联查询图数据库或知识图谱更关注确定的实体关系跨多个文档追踪实体之间的联系GraphRAG需要结合文字内容与图关系对大规模文档进行主题归纳、总体分析社区摘要类 GraphRAG 或分层摘要 RAG需要整合大量分散信息这里并不存在一个绝对最先进、能够替代所有架构的方案。GraphRAG 不一定比普通 RAG 好向量数据库也不是比关系型数据库更先进。决定技术架构的是你要解决的查询问题。十三、再补充几个经常一起出现的英文技术词这些词在看开源项目、架构图和技术文档时会经常遇到。术语英文或全称含义TokenToken模型处理文本的基本单位ChunkChunk文档切分后的文本块ChunkingChunking文档切块操作Top-KTop K Results返回排名最靠前的 K 条结果ANNApproximate Nearest Neighbor近似最近邻检索HNSWHierarchical Navigable Small World分层可导航小世界向量索引算法NERNamed Entity Recognition命名实体识别NLPNatural Language Processing自然语言处理PromptPrompt提供给模型的输入指令及上下文Context WindowContext Window模型单次可处理的上下文范围RerankerReranker重排序模型或组件RecallRecall召回率衡量相关内容被找回的程度BM25Best Matching 25常见展开一种经典的词项相关性排序算法GroundingGrounding将模型回答建立在外部证据或指定信息之上HallucinationHallucination大模型生成缺乏依据或不符合事实的内容IndexingIndexing建立可检索索引的过程PipelinePipeline由一系列处理步骤组成的流水线十四、动手实践建议顺序第一阶段只研究 Embedding 与向量检索找十条文本用一个 Embedding 模型生成向量保存到 pgvector通过 SQL 查询最相似的文本。目标看懂向量到底是什么为什么它能检索语义。2.第二阶段做一个最简单的 RAG让程序读取一个 PDF切块、向量化、入库最后调用 LLM 回答问题。目标搞清楚文档处理链路与问答链路。3.第三阶段学习 Neo4j 和 Cypher用电影与演员的数据手动创建十几个节点和关系写一些两跳、三跳的关系查询。目标真正理解图数据库与关系型数据库在查询模式上的区别。4.第四阶段尝试图谱抽取与 GraphRAG使用 LLM 从几篇文章中抽取实体与关系将图关系和原始文档关联起来比较向量 RAG 与图检索 RAG 的回答效果。目标理解 GraphRAG 为什么会出现哪些问题真正需要它。相关的官方技术资料可以从 pgvector、Neo4j 图数据库入门、Microsoft GraphRAG三个项目开始看。最后再把这些概念压缩成一个工程视角Embedding 负责将语义转换为可计算的向量向量数据库负责寻找语义上接近的内容知识图谱负责表达事实关系图数据库负责存储和查询这些图结构RAG 负责把检索结果交给大语言模型生成答案GraphRAG 则利用图结构帮助 RAG 更好地发现、组织和整合相关知识。如果只记住一个最核心的概念我认为应该是RAG 的技术核心不是某个数据库而是如何把用户的问题转换成有效的检索操作再把准确、相关、足够完整的外部知识送进大模型的上下文。向量检索、图检索、关键词检索、重排序甚至 SQL 查询本质上都是为了更好地完成其中的“找到知识”这个任务。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取 
长河君 · 2026/10/14 3:24:48 · 阅读 1.2k 收藏这份9000字知识库指南：从零理解RAG、向量数据库到GraphRAG，小白程序员必看！
本文以软件工程和AI系统架构视角深入解析知识库、RAG、向量数据库、图数据库、知识图谱及GraphRAG等核心概念。内容涵盖各术语定义、知识加工成AI可检索知识的流程、向量生成与数据库检索原理、图数据库存储查询方式、知识图谱构建方法以及RAG和GraphRAG的协作机制和技术组件选择。适合熟悉传统数据库和软件开发但缺乏大模型知识库实际工程经验的学习者建议收藏后系统学习。我们从软件工程和 AI 系统架构的角度把知识库、RAG、向量数据库、图数据库、知识图谱、GraphRAG 这几个概念完整梳理一遍。我会假设你熟悉传统的数据库、SQL 和软件开发但没有接触过大模型知识库的实际工程实现。我们不仅解释概念还要弄清楚它们各自是什么英文全称是什么解决什么问题。一段 Word、PDF 文档是怎么被加工成 AI 可以检索的知识的。向量是怎么生成的向量数据库到底保存了什么怎样搜索。图数据库保存什么、如何查询知识图谱又是如何构建出来的。RAG 和 GraphRAG 从用户提问到大模型回答代码和组件是怎么协作的。真正开发一个知识库系统需要哪些技术组件什么情况下选择哪一种架构。一、先把这些英文术语搞清楚这是理解后面所有技术的基础。中文名称英文名称及缩写本质是什么知识库Knowledge BaseKB一套知识的存储、组织与使用体系大语言模型Large Language ModelLLM能理解和生成自然语言的 AI 模型检索增强生成Retrieval-Augmented GenerationRAG一种结合外部知识检索与大模型生成的技术架构向量数据库Vector DatabaseVector DB专门支持向量存储和相似性检索的数据库图数据库Graph DatabaseGraph DB以节点、边等图结构管理和查询数据的数据库知识图谱Knowledge GraphKG用实体及其关系组织知识的结构化表示图检索增强生成Graph Retrieval-Augmented GenerationGraphRAG在 RAG 中利用图结构进行知识检索与组织的一类方法向量嵌入Embedding / Vector Embedding把文本等对象转换成能够进行数学运算的向量表示嵌入模型Embedding Model负责生成向量的模型语义搜索Semantic Search按照内容含义而不只是字面关键词进行搜索重排序Reranking对初步检索到的结果重新评估相关性并排序混合检索Hybrid Search结合关键词、向量等多种检索方式其中有个非常重要的区别知识库是系统或知识集合RAG 是技术架构向量数据库和图数据库是存储查询组件知识图谱是知识的组织形式GraphRAG 则是一类利用图结构增强检索生成的方法。它们不处在同一个技术层级。你可以把它们理解成软件系统里面的不同角色有的是整个应用有的是实现方案有的是底层基础设施。二、先看它们之间的整体关系典型 AI 知识库系统架构概念示意知识图谱不必使用图数据库存储GraphRAG 也不一定需要独立的图数据库。图中展示的是一种常见组合而非唯一架构。这里你只需要先记住一个关系RAG 是大框架向量检索 RAG 和 GraphRAG 是不同的实现思路它们既可以分别使用也可以混合使用。接下来我们先从最基础的知识库开始一层一层拆到具体的工程实现。三、Knowledge Base知识库到底是什么先说知识库因为这是最大的概念。知识库Knowledge BaseKB并不是 AI 时代才出现的东西。传统的软件帮助中心、FAQFrequently Asked Questions常见问题、技术文档库、百科网站本质上都可以算知识库。传统知识库通常是文档 → 数据库或搜索引擎 → 用户搜索 → 返回文档AI 知识库可以变成文档 → 知识加工与索引 → 检索相关知识 → 大模型理解和组织 → 返回自然语言答案例如把一百份产品说明书放进知识库。用户问“设备指示灯一直闪红色怎么办”传统搜索一般返回几篇可能包含“指示灯”“红色”的说明文档。AI 知识库则可能直接回答“根据设备说明书第 12 页红灯连续闪烁表示设备过热需要停止运行并检查散热条件。”但这里有个容易产生误解的地方知识库不是把一百份 Word 直接交给大模型让模型全部记住。工程实现通常会先加工这些文档建立可以高效查询的索引。用户提问时只找出相关的一小部分内容交给大模型回答。当然也可以通过模型微调让模型学习特定领域的知识但微调Fine-tuning与基于外部知识检索的 RAG 是不同路线。两者也能够组合。四、Embedding为什么文本能够变成数字这是理解向量数据库的关键。1. 什么叫向量数学上的向量可以简单理解成一组有顺序的数字。例如A [0.2, 0.8, 0.1] B [0.3, 0.7, 0.2] C [0.9, 0.1, 0.8]上面是三个三维向量。如果只有三个维度我们还可以想象成三维空间中的三个点。但真正的文本 Embedding 模型可能输出 384、768、1024、1536 等不同维度的向量具体取决于模型。例如一句话被编码成原文 我买的手机坏了怎么退货Embedding 模型处理后[0.012, -0.183, 0.275, ..., 0.091]假设输出维度为 768这是一个示意数值并不是真实模型计算结果。你可能会问一句中文为什么能变成 768 个数字这些数字分别表示什么2. Embedding 模型是怎么工作的Embedding Model嵌入模型通常是一个经过训练的神经网络。它不是按照简单的字典把“手机”转换成 001、“退货”转换成 002。真实过程要复杂得多。这里的 Token简单说是模型处理文本的基本单位。它不一定等于一个字或一个单词也可能是词的一部分。训练过程中模型会学习如何把语义相关的内容映射到向量空间中较接近的位置。例如“怎么申请退款”“购买商品后如何办理退货”两句话虽然用词不一样但语义比较相近经过合适的 Embedding 模型编码后向量通常也比较接近。不过不能把每一个维度机械地理解成一个固定的词义标签比如第一维代表手机、第二维代表退款。实际模型学习到的是分布式的特征表示通常无法直接逐维解释。3. 向量之间怎么判断相似常见方法是余弦相似度Cosine Similarity。公式是简单理解就是比较两个向量的方向有多接近。对于非零向量余弦相似度的数学范围为 -1 到 1。余弦相似度的直观理解用二维方向演示余弦相似度非真实文本向量。此外还有Euclidean Distance欧氏距离衡量空间中的直线距离。Dot Product点积或内积用于衡量向量的相关性。Cosine Distance余弦距离常见定义为 1 减去余弦相似度。不同 Embedding 模型对相似度指标的适配方式可能不同不是所有模型都适合统一使用一个算法。还有一点很重要相似度不是正确率。两句话的余弦相似度很高不代表它们表达的事实相同。比如“设备已启动”和“设备未启动”包含大量相同词语向量仍有可能接近。五、Vector Database向量数据库内部究竟保存了什么这里用熟悉的数据库表来理解。假设有一本产品使用手册我们先把它分成多个小段再逐段生成向量。数据库中的逻辑结构可能是chunk_idcontent文本片段embedding向量source001设备开机时需要按住电源键……[0.12, 0.36, …]manual.pdf002红色指示灯闪烁表示过热……[0.23, 0.18, …]manual.pdf003设备恢复出厂设置的方法……[0.74, 0.51, …]manual.pdf其中embedding字段不是普通的 VARCHAR而是向量数据类型或数据库内部定义的向量结构。实际工程上还经常保存document_id、chunk_id、page_no、title、text、embedding、metadata、version这里有两个重要知识点。1. 文本切块ChunkingChunk 是“块、片段”的意思Chunking 就是把长文档切分成较小的文本块。为什么要切因为一本几十万字的手册不能每次都原样交给模型搜索和回答。把整个文档编码为一个向量也容易丢失局部细节。因此可能采用原始文档 | |-- Chunk 1产品功能介绍 |-- Chunk 2设备安装步骤 |-- Chunk 3设备开机流程 |-- Chunk 4指示灯故障说明 |-- Chunk 5恢复出厂设置工程上常使用 Token 数控制切块大小例如每块 500 Token 左右或者按自然段、标题、章节切分。还可能设置 Overlap重叠让相邻块共享一部分文字避免关键内容恰好被切断。但切块也不是越小越好切得太小上下文被破坏切得太大相关内容不够集中还增加检索与模型处理成本。对于 PDF还要考虑表格跨页、标题层级、图片和扫描件等问题。很多知识库实际效果不好并不是大模型不行而是前面的文档解析和切块就已经把知识处理坏了。2. 向量数据库为什么检索速度快假设有一千万条文本向量。最直接的办法是把用户问题也变成向量逐一计算它和一千万个向量的距离再排序取前十条。理论上能做但计算量很大。于是出现了 ANNANN Approximate Nearest Neighbor近似最近邻搜索。这里的“近似”指为了提升速度允许在一定程度上牺牲召回精度并不意味着生成的答案一定是近似或错误的。一个很常见的索引算法是 HNSWHNSW Hierarchical Navigable Small World分层可导航小世界图。它的思想可以理解为建立多层向量导航网络先在稀疏的高层快速定位再逐渐进入更密集的底层寻找附近的向量。你可以把它想象成从全国地图找到城市 → 从城市找到街区 → 从街区找到目标附近的位置。HNSW 并不是唯一选择但在向量数据库中非常常见。Weaviate和 pgvector 的官方技术文档都提供了 HNSW 索引的实现或支持。这里还有一个特别容易混淆的地方HNSW 虽然也使用“图”结构但它不是知识图谱。HNSW 图里的边表示向量搜索时建立的邻近导航连接。知识图谱里的边表示有具体业务含义的关系例如“张三出演电影 A”。两种图的含义完全不同。3. 从 SQL 角度理解向量检索假设使用 PostgreSQL 加 pgvector 扩展。下面是一段简化的教学示例CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE kb_chunks ( id BIGINT PRIMARY KEY, content TEXT, embedding VECTOR(3) );-------------------INSERT INTO kb_chunks VALUES (1, 设备开机说明, [0.1,0.2,0.3]), (2, 设备故障说明, [0.2,0.3,0.4]), (3, 设备维护说明, [0.8,0.1,0.2]); -------------------------CREATE INDEX idx_kb_embedding ON kb_chunks USING hnsw (embedding vector_cosine_ops); --------------------SELECT id, content, embedding [0.2,0.2,0.3] AS distance FROM kb_chunks ORDER BY embedding [0.2,0.2,0.3] LIMIT 2;---------------------------这里VECTOR(3)三维向量类型真实项目按模型输出维度设置。hnsw向量索引类型。pgvector 的余弦距离运算符。LIMIT 2返回距离最近的两条记录也就是 Top-K 检索中的 K2。pgvector 官方文档提供了这些 SQL 运算符和索引语法。注意示例中的三个向量是手动填写的教学数据。实际工程中不会让程序员手工写向量而是调用 Embedding 模型批量生成。六、RAG从上传文档到 AI 回答完整发生了什么现在就可以真正理解 RAG 了。RAG Retrieval-Augmented Generation。拆开看三个单词Retrieval检索从外部知识源寻找相关信息。Augmented增强给模型补充检索到的上下文。Generation生成让语言模型根据问题和上下文产生回答。RAG 本身不是某个数据库产品也不是某个大模型。它是一种组织整个问答过程的架构。在工程实现上通常可以拆成两条相对独立的处理链路。第一条离线知识加工链路Indexing Pipeline这条链路可以在用户提问前预先执行也可以在文档新增、修改后增量执行。并不是每问一次问题都要重新解析所有文档、计算全部向量。第二条在线问答链路Query Pipeline用户提问“设备出现红灯闪烁怎么办”真正体现 RAG 原理的是第 5 步。例如程序把这些内容拼接成发给大模型的 Prompt系统指令 请根据提供的参考资料回答。 资料没有说明的内容不要自行编造。 回答时注明资料来源。 参考资料 [文档1 - 第12页] 红色指示灯连续闪烁表示设备温度过高。 应停止运行并检查散热情况。 用户问题 设备出现红灯闪烁怎么办大模型这时就不需要凭训练时记住的知识去猜而是有了明确的外部参考资料。不过RAG 只能降低无依据回答的风险不能完全消除幻觉Hallucination。如果检索结果本来就错了模型仍可能生成错误答案。RAG 最关键的几个工程认识第一RAG 不等于向量检索。RAG 完全可以使用全文搜索引擎、SQL 数据库、API、图数据库等检索知识不是必须有向量数据库。第二RAG 不需要重新训练大模型。常规 RAG 的知识更新主要发生在外部数据与索引层。新增文档后重新解析、切块、向量化并更新索引即可。第三Embedding 模型和 LLM 是两个不同角色。Embedding 模型负责把文本编码成向量LLM 负责生成回答。它们可以是不同模型也可以来自同一个模型体系但职责不同。第四向量检索不应该完全代替关键词检索。例如查询具体错误码ERR-4098、零件编号ABX-734精确词匹配往往更有价值。因此实际工程常用 Hybrid Search混合检索结合 BM25 等关键词检索算法和向量检索再用 Reranker重排序模型重新排序。七、Graph Database图数据库到底是怎么存储数据的现在进入另一个技术体系——图数据库。Graph Database简称 Graph DB。比较有代表性的产品包括 Neo4j、NebulaGraph等。先说一个核心区别传统关系型数据库擅长存储实体的属性以及通过表和关联字段表达关系。图数据库则把实体之间的关系作为一等公民直接用节点和边来表示。1. 图数据库有三个核心概念Node节点用来表示对象。例如人物、电影、城市、产品、事件等。Relationship / Edge关系或边用来表示两个节点之间的联系。例如演员 — 出演 → 电影导演 — 执导 → 电影Property属性用于描述节点或者关系。例如电影节点可以包含名称、上映年份等属性出演关系可以包含角色名称。我们用一个完全虚构的电影世界举例。电影人物关系图示意图只表示虚构的电影、演员及导演关系。如果使用关系型数据库可能设计为PERSON 人员表 MOVIE Neo4j 使用的主要查询语言叫 Cypher。 它和 SQL 一样属于声明式查询语言你描述需要匹配的关系模式数据库执行相应的查询。 例如查询出演了《星海远航》的演员 MATCH (p:Person)-[:ACTED_IN]-(m:Movie) WHERE m.title 星海远航 RETURN p.name;查询出演《星海远航》的演员还出演过哪些电影以及那些电影的导演MATCH (p:Person)-[:ACTED_IN]-(m1:Movie) WHERE m1.title 星海远航 MATCH (p)-[:ACTED_IN]-(m2:Movie) MATCH (d:Person)-[:DIRECTED]-(m2) WHERE m2 m1 RETURN p.name AS actor, m2.title AS other_movie, d.name AS director;这个 SQL 风格的MATCH图模式查询就是 Cypher 的典型特点。我们在做什么实际上就是顺着图中的关系走电影 A ← 演员 → 电影 B ← 导演这样的操作叫做 Traversal图遍历。跨越多个关系进行查询可以叫 Multi-hop Query多跳查询。不过这并不意味着图数据库总比关系型数据库快。对于简单查询、规整的表结构、聚合统计关系型数据库往往完全够用。图数据库的优势主要体现在关系网络复杂、需要频繁进行路径查询或多跳遍历时。八、Knowledge Graph知识图谱与图数据库为什么不是一回事这个地方需要区分两个层面。知识图谱Knowledge Graph是一种对知识进行建模和组织的方式。图数据库Graph Database是能够存储、管理和查询图数据的数据库系统。例如我们设计了一个电影知识图谱定义Person人物。Movie电影。ACTED_IN出演关系。DIRECTED执导关系。然后把真实或虚构的电影信息转换成节点和关系。这个过程称为 Knowledge Graph Construction知识图谱构建。工程上通常包括几个步骤。这里还有几个工程术语NER Named Entity Recognition命名实体识别。Entity Linking 实体链接或实体对齐识别不同文本提到的是否是同一对象。Relation Extraction 关系抽取从文本中识别实体之间的关系。Schema 模式定义规定哪些类型的实体、属性与关系是允许的。知识图谱可以通过程序规则、NLPNatural Language Processing自然语言处理模型或者 LLM 从文档中抽取但自动抽取会出错。例如“张明否认自己出演了电影 A。”如果模型没有正确理解“否认”错误抽取为张明 → 出演 → 电影 A那么知识图谱就已经产生了错误事实。所以一个可靠的知识图谱系统还需要保存来源、置信度、时间信息必要时进行人工校验和实体融合。图谱数据最终可以存储在 Neo4j也可以用关系型数据库、RDF 三元组存储等技术来管理不一定非要图数据库。九、GraphRAG它比普通 RAG 多做了什么到这里我们已经分别理解了 RAG 和知识图谱。GraphRAG 就比较好理解了。它不是完全推翻 RAG而是在检索和组织知识的过程中引入了图结构的能力。我们还是用电影例子。假设有两份文档文档 A《星海远航》由林辰执导苏遥担任主演。文档 B苏遥还出演了《月球来客》该片导演为何川。用户提问“《星海远航》的主演还出演了哪部电影那部电影的导演是谁”普通向量 RAG 可能怎么处理首先把整句话向量化搜索相似文本。由于文档 A 包含“星海远航”可能被检索出来。但文档 B 没有提到“星海远航”如果检索策略不够好文档 B 就可能被遗漏。这样模型只知道苏遥出演《星海远航》却没有其他电影的信息。当然普通 RAG 也可以通过扩大召回范围、查询改写、多次检索等手段解决这个问题。并不是说只有 GraphRAG 才能回答。GraphRAG 可能怎么处理GraphRAG 可以先识别电影实体《星海远航》然后沿着关系图查询然后把查到的相关关系和文档原文交给 LLM让它生成自然语言答案。你会发现GraphRAG 并不是让模型凭空具有某种神奇的推理能力而是利用已构建的关系网络更有针对性地发现和组织检索证据。十、微软的 GraphRAG还有一种更深入的做法这里需要专门讲一下因为很多文章一提 GraphRAG就在讲微软的开源项目。微软 GraphRAG 项目中的一种典型实现不只是“图数据库 RAG”。它更强调从大量非结构化文档中抽取图结构再通过图社区和预生成的摘要支持局部或全局知识查询。其标准索引流程可以概括成微软官方的索引架构包括实体关系抽取、社区检测、社区报告生成和 Embedding 等环节。默认实现的部分结构化输出使用 Parquet 文件保存向量数据进入配置的向量存储。这里多了一个很有意思的技术Community Detection社区检测。社区检测是什么假设知识图谱里有十万个实体和几十万条关系。其中一批实体主要与太空电影相关另一批与音乐电影相关还有一批与动漫作品相关。社区检测算法会根据图中的连接情况识别出关系较紧密的节点群体。图社区聚类概念示意社区是根据图连接结构识别的节点集合并不一定天然对应人工划分的主题。构建好社区后可以让大模型对不同社区的知识生成摘要。例如社区 A 主要讨论太空题材电影。社区 B 主要讨论音乐题材电影。社区 C 主要讨论电影制作人员之间的合作关系。这些描述是模型根据社区内容生成的概括不是社区检测算法直接理解出来的语义。微软 GraphRAG 的几种查询方式查询方式英文主要用途局部搜索Local Search围绕特定实体查找邻居、关系、关联文本全局搜索Global Search结合社区摘要回答跨文档的总体问题基础搜索Basic Search基于传统文本向量检索DRIFT 搜索Dynamic Reasoning and Inference with Flexible Traversal结合局部实体搜索与更广泛的社区信息例如提问“《星海远航》的主演是谁”适合 Local Search。如果问“这批电影资料整体反映了哪些主要题材和创作趋势”就可能适合 Global Search。微软的全局搜索方法会基于社区报告生成中间结果再汇总形成最终回答采用类似 Map-Reduce 的处理思路。不过GraphRAG 的图谱抽取、社区划分、摘要生成会增加索引构建的模型调用量与维护成本。文档规模很小、问题很简单时完全没必要一上来就采用这种复杂架构。十一、工程实践真正开发一个 RAG 系统需要多少组件现在假设你要自己开发一个最基础的智能知识问答应用。前端是一个网页用户可以上传文档并提问。我建议先不要上 GraphRAG只做最基础的 RAG这样技术链路最容易理解。推荐的入门技术组合模块可以采用的技术职责后端接口Python FastAPI提供上传文档、问答 API文档解析PyMuPDF、python-docx提取 PDF、Word 中的内容文本切块Python 代码或文本切分组件将文档分成 Chunk向量模型BGE、其他 Embedding 模型或模型 API生成向量向量存储PostgreSQL pgvector保存向量并支持相似性查询大语言模型本地或云端 LLM生成自然语言回答前端Vue、React 等提供上传和聊天界面这并不是唯一组合。Milvus、Qdrant 等专用向量数据库也可以替代 pgvector。真正上线时还需要文档版本管理、失败重试、引用来源、日志监控、权限过滤、检索效果评估等工程能力。那么升级 GraphRAG 需要加什么主要增加三个部分图谱构建模块抽取实体、关系完成实体融合。图结构存储与检索模块管理实体、边、图查询。检索编排模块结合用户问题决定用向量检索、图检索还是两者混合。还有一个值得注意的工程事实图数据库和向量数据库不一定要分别部署。部分图数据库已经支持向量索引部分应用也会把实体关系和向量存储组合在同一个数据平台中。因此设计系统时应该先确定检索能力和数据模型再决定物理上需要几个数据库。十二、这些架构到底该怎么选择把前面所有概念放到实际工程决策中可以得到这样一张表。需求场景优先考虑原因几十份 FAQ、简单帮助文档问答关键词搜索或简单 RAG需求简单不必过度设计几千份 PDF、Word 智能问答向量 RAG 关键词检索主要任务是寻找相关文档证据产品说明、错误码、型号精确查询混合检索 RAG同时需要语义和精确匹配人物关系、关系路径、复杂关联查询图数据库或知识图谱更关注确定的实体关系跨多个文档追踪实体之间的联系GraphRAG需要结合文字内容与图关系对大规模文档进行主题归纳、总体分析社区摘要类 GraphRAG 或分层摘要 RAG需要整合大量分散信息这里并不存在一个绝对最先进、能够替代所有架构的方案。GraphRAG 不一定比普通 RAG 好向量数据库也不是比关系型数据库更先进。决定技术架构的是你要解决的查询问题。十三、再补充几个经常一起出现的英文技术词这些词在看开源项目、架构图和技术文档时会经常遇到。术语英文或全称含义TokenToken模型处理文本的基本单位ChunkChunk文档切分后的文本块ChunkingChunking文档切块操作Top-KTop K Results返回排名最靠前的 K 条结果ANNApproximate Nearest Neighbor近似最近邻检索HNSWHierarchical Navigable Small World分层可导航小世界向量索引算法NERNamed Entity Recognition命名实体识别NLPNatural Language Processing自然语言处理PromptPrompt提供给模型的输入指令及上下文Context WindowContext Window模型单次可处理的上下文范围RerankerReranker重排序模型或组件RecallRecall召回率衡量相关内容被找回的程度BM25Best Matching 25常见展开一种经典的词项相关性排序算法GroundingGrounding将模型回答建立在外部证据或指定信息之上HallucinationHallucination大模型生成缺乏依据或不符合事实的内容IndexingIndexing建立可检索索引的过程PipelinePipeline由一系列处理步骤组成的流水线十四、动手实践建议顺序第一阶段只研究 Embedding 与向量检索找十条文本用一个 Embedding 模型生成向量保存到 pgvector通过 SQL 查询最相似的文本。目标看懂向量到底是什么为什么它能检索语义。2.第二阶段做一个最简单的 RAG让程序读取一个 PDF切块、向量化、入库最后调用 LLM 回答问题。目标搞清楚文档处理链路与问答链路。3.第三阶段学习 Neo4j 和 Cypher用电影与演员的数据手动创建十几个节点和关系写一些两跳、三跳的关系查询。目标真正理解图数据库与关系型数据库在查询模式上的区别。4.第四阶段尝试图谱抽取与 GraphRAG使用 LLM 从几篇文章中抽取实体与关系将图关系和原始文档关联起来比较向量 RAG 与图检索 RAG 的回答效果。目标理解 GraphRAG 为什么会出现哪些问题真正需要它。相关的官方技术资料可以从 pgvector、Neo4j 图数据库入门、Microsoft GraphRAG三个项目开始看。最后再把这些概念压缩成一个工程视角Embedding 负责将语义转换为可计算的向量向量数据库负责寻找语义上接近的内容知识图谱负责表达事实关系图数据库负责存储和查询这些图结构RAG 负责把检索结果交给大语言模型生成答案GraphRAG 则利用图结构帮助 RAG 更好地发现、组织和整合相关知识。如果只记住一个最核心的概念我认为应该是RAG 的技术核心不是某个数据库而是如何把用户的问题转换成有效的检索操作再把准确、相关、足够完整的外部知识送进大模型的上下文。向量检索、图检索、关键词检索、重排序甚至 SQL 查询本质上都是为了更好地完成其中的“找到知识”这个任务。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取