我们从软件工程和 AI 系统架构的角度，把知识库、RAG、向量数据库、图数据库、知识图谱、GraphRAG 这几个概念完整梳理一遍。

我会假设你熟悉传统的数据库、SQL 和软件开发，但没有接触过大模型知识库的实际工程实现。

我们不仅解释概念，还要弄清楚：

• 它们各自是什么，英文全称是什么，解决什么问题。
• 一段 Word、PDF 文档是怎么被加工成 AI 可以检索的知识的。
• 向量是怎么生成的，向量数据库到底保存了什么，怎样搜索。
• 图数据库保存什么、如何查询，知识图谱又是如何构建出来的。
• RAG 和 GraphRAG 从用户提问到大模型回答，代码和组件是怎么协作的。
• 真正开发一个知识库系统，需要哪些技术组件，什么情况下选择哪一种架构。

一、先把这些英文术语搞清楚

这是理解后面所有技术的基础。

中文名称	英文名称及缩写	本质是什么
知识库	Knowledge Base，KB	一套知识的存储、组织与使用体系
大语言模型	Large Language Model，LLM	能理解和生成自然语言的 AI 模型
检索增强生成	Retrieval-Augmented Generation，RAG	一种结合外部知识检索与大模型生成的技术架构
向量数据库	Vector Database，Vector DB	专门支持向量存储和相似性检索的数据库
图数据库	Graph Database，Graph DB	以节点、边等图结构管理和查询数据的数据库
知识图谱	Knowledge Graph，KG	用实体及其关系组织知识的结构化表示
图检索增强生成	Graph Retrieval-Augmented Generation，GraphRAG	在 RAG 中利用图结构进行知识检索与组织的一类方法
向量嵌入	Embedding / Vector Embedding	把文本等对象转换成能够进行数学运算的向量表示
嵌入模型	Embedding Model	负责生成向量的模型
语义搜索	Semantic Search	按照内容含义，而不只是字面关键词进行搜索
重排序	Reranking	对初步检索到的结果重新评估相关性并排序
混合检索	Hybrid Search	结合关键词、向量等多种检索方式

其中有个非常重要的区别：

知识库是系统或知识集合，RAG 是技术架构，向量数据库和图数据库是存储查询组件，知识图谱是知识的组织形式，GraphRAG 则是一类利用图结构增强检索生成的方法。

它们不处在同一个技术层级。

你可以把它们理解成软件系统里面的不同角色：有的是整个应用，有的是实现方案，有的是底层基础设施。

二、先看它们之间的整体关系

典型 AI 知识库系统架构（概念示意）

知识图谱不必使用图数据库存储；GraphRAG 也不一定需要独立的图数据库。图中展示的是一种常见组合，而非唯一架构。

这里你只需要先记住一个关系：

RAG 是大框架，向量检索 RAG 和 GraphRAG 是不同的实现思路；它们既可以分别使用，也可以混合使用。

接下来我们先从最基础的知识库开始，一层一层拆到具体的工程实现。

三、Knowledge Base：知识库到底是什么？

先说知识库，因为这是最大的概念。

知识库（Knowledge Base，KB）并不是 AI 时代才出现的东西。传统的软件帮助中心、FAQ（Frequently 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 等不同维度的向量，具体取决于模型。

例如，一句话被编码成：

原文："我买的手机坏了，怎么退货？"
``````plaintext
Embedding 模型处理后：
``````plaintext
[0.012, -0.183, 0.275, ..., 0.091]
``````plaintext
假设输出维度为 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_id	content（文本片段）	embedding（向量）	source
001	设备开机时需要按住电源键……	[0.12, 0.36, …]	manual.pdf
002	红色指示灯闪烁表示过热……	[0.23, 0.18, …]	manual.pdf
003	设备恢复出厂设置的方法……	[0.74, 0.51, …]	manual.pdf

其中 embedding字段不是普通的 VARCHAR，而是向量数据类型或数据库内部定义的向量结构。

实际工程上还经常保存：

document_id、chunk_id、page_no、title、text、embedding、metadata、version

这里有两个重要知识点。

1. 文本切块：Chunking

Chunk 是“块、片段”的意思，Chunking 就是把长文档切分成较小的文本块。

为什么要切？

因为一本几十万字的手册，不能每次都原样交给模型搜索和回答。把整个文档编码为一个向量，也容易丢失局部细节。

因此可能采用：

原始文档    |    |-- Chunk 1：产品功能介绍    |-- Chunk 2：设备安装步骤    |-- Chunk 3：设备开机流程    |-- Chunk 4：指示灯故障说明    |-- Chunk 5：恢复出厂设置

工程上常使用 Token 数控制切块大小，例如每块 500 Token 左右，或者按自然段、标题、章节切分。

还可能设置 Overlap（重叠），让相邻块共享一部分文字，避免关键内容恰好被切断。

但切块也不是越小越好：

切得太小，上下文被破坏；切得太大，相关内容不够集中，还增加检索与模型处理成本。

对于 PDF，还要考虑表格跨页、标题层级、图片和扫描件等问题。很多知识库实际效果不好，并不是大模型不行，而是前面的文档解析和切块就已经把知识处理坏了。

2. 向量数据库为什么检索速度快？

假设有一千万条文本向量。

最直接的办法，是把用户问题也变成向量，逐一计算它和一千万个向量的距离，再排序取前十条。

理论上能做，但计算量很大。

于是出现了 ANN：

ANN = Approximate Nearest Neighbor，近似最近邻搜索。

这里的“近似”指为了提升速度，允许在一定程度上牺牲召回精度，并不意味着生成的答案一定是近似或错误的。

一个很常见的索引算法是 HNSW：

HNSW = 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));
``````plaintext
-------------------
``````plaintext
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]');-------------------------
``````plaintext
CREATE INDEX idx_kb_embeddingON kb_chunksUSING hnsw (embedding vector_cosine_ops);--------------------
``````plaintext
SELECT id,       content,       embedding <=> '[0.2,0.2,0.3]' AS distanceFROM kb_chunksORDER BY embedding <=> '[0.2,0.2,0.3]'LIMIT 2;
``````plaintext
---------------------------

这里：

• VECTOR(3)：三维向量类型，真实项目按模型输出维度设置。
• hnsw：向量索引类型。
• <=>：pgvector 的余弦距离运算符。
• LIMIT 2：返回距离最近的两条记录，也就是 Top-K 检索中的 K=2。

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 电影表ACTOR_MOVIE 演员电影关联表DIRECTOR_MOVIE 导演电影关联表

在图数据库里，可以直接表达成：

(苏遥)-[:ACTED_IN]->(星海远航)(苏遥)-[:ACTED_IN]->(月球来客)(林辰)-[:DIRECTED]->(星海远航)(何川)-[:DIRECTED]->(月球来客)

这样一种写法已经非常接近图数据库实际使用的查询语言。

2. 图数据库如何查询？

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 <> m1RETURN 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 = 模式定义，规定哪些类型的实体、属性与关系是允许的。

知识图谱可以通过程序规则、NLP（Natural 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 需要加什么？

主要增加三个部分：

1. 图谱构建模块：抽取实体、关系，完成实体融合。
2. 图结构存储与检索模块：管理实体、边、图查询。
3. 检索编排模块：结合用户问题，决定用向量检索、图检索还是两者混合。

还有一个值得注意的工程事实：图数据库和向量数据库不一定要分别部署。部分图数据库已经支持向量索引，部分应用也会把实体关系和向量存储组合在同一个数据平台中。

因此，设计系统时应该先确定检索能力和数据模型，再决定物理上需要几个数据库。

十二、这些架构到底该怎么选择？

把前面所有概念放到实际工程决策中，可以得到这样一张表。

需求场景	优先考虑	原因
几十份 FAQ、简单帮助文档问答	关键词搜索或简单 RAG	需求简单，不必过度设计
几千份 PDF、Word 智能问答	向量 RAG + 关键词检索	主要任务是寻找相关文档证据
产品说明、错误码、型号精确查询	混合检索 RAG	同时需要语义和精确匹配
人物关系、关系路径、复杂关联查询	图数据库或知识图谱	更关注确定的实体关系
跨多个文档追踪实体之间的联系	GraphRAG	需要结合文字内容与图关系
对大规模文档进行主题归纳、总体分析	社区摘要类 GraphRAG 或分层摘要 RAG	需要整合大量分散信息

这里并不存在一个绝对最先进、能够替代所有架构的方案。

GraphRAG 不一定比普通 RAG 好，向量数据库也不是比关系型数据库更先进。决定技术架构的，是你要解决的查询问题。

十三、再补充几个经常一起出现的英文技术词

这些词在看开源项目、架构图和技术文档时会经常遇到。

术语	英文或全称	含义
Token	Token	模型处理文本的基本单位
Chunk	Chunk	文档切分后的文本块
Chunking	Chunking	文档切块操作
Top-K	Top K Results	返回排名最靠前的 K 条结果
ANN	Approximate Nearest Neighbor	近似最近邻检索
HNSW	Hierarchical Navigable Small World	分层可导航小世界向量索引算法
NER	Named Entity Recognition	命名实体识别
NLP	Natural Language Processing	自然语言处理
Prompt	Prompt	提供给模型的输入指令及上下文
Context Window	Context Window	模型单次可处理的上下文范围
Reranker	Reranker	重排序模型或组件
Recall	Recall	召回率，衡量相关内容被找回的程度
BM25	Best Matching 25（常见展开）	一种经典的词项相关性排序算法
Grounding	Grounding	将模型回答建立在外部证据或指定信息之上
Hallucination	Hallucination	大模型生成缺乏依据或不符合事实的内容
Indexing	Indexing	建立可检索索引的过程
Pipeline	Pipeline	由一系列处理步骤组成的流水线

十四、动手实践，建议顺序

1. 第一阶段：只研究 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大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】