@shivam74689: 第62天 — 成为AI工程师 今天我开始构建一个企业知识图谱智能RAG系统，并意识到…

X AI KOLs Timeline 新闻
knowledge-graph rag retrieval enterprise-ai ai-engineering vector-search bm25

摘要

作者描述了构建企业知识图谱智能RAG系统的历程，结合了语义检索、BM25词汇搜索和知识图谱遍历，强调生产级AI需要多种检索策略。

Day 62 — 成为AI工程师 今天我开始构建一个企业知识图谱智能RAG系统，并意识到检索远不止是搜索嵌入向量。 在那之前，我以为RAG主要就是将文档分块、创建嵌入向量、存储向量，并检索最相似的分块。 在从头构建了多个检索管道后，我意识到生产级AI系统通过多种方式检索知识，因为没有一种单一的检索方法能胜任所有任务。 最大的教训： 企业AI是关于结合不同形式的知识，而不是依赖单一的检索策略。 我正在构建的系统旨在回答组织内部知识的问题——合同、政策、支持工单、PDF、HTML页面、Markdown文件、CSV等。 而不是仅依赖向量搜索，它结合了三种不同的检索方法： • 使用向量嵌入的语义检索。 • 使用BM25的词汇检索。 • 用于关系推理的知识图谱遍历。 最终，一个智能代理将决定对于每个查询，哪种检索策略——或策略组合——是最佳的。 我首先构建的是文档摄取管道。 我没有依赖框架提供的文档加载器，而是从头实现了整个管道。 我创建了一个通用的Document模型来标准化进入系统的每个文件，无论其格式如何。 然后我为以下格式构建了加载器： • PDF • Markdown • HTML • CSV 一个加载器工厂自动选择正确的加载器，而目录加载器则递归扫描整个知识库，将所有内容转换为统一的文档集合。 很快一个教训变得非常明显： 元数据与文档本身同等重要。 现在每个文档都携带诸如源文件、页码和行索引等信息。 这些元数据后续将用于引用、图谱构建和可解释的检索。 接下来是分块。 起初，分块看起来像是一个简单的预处理步骤。 结果它成了整个管道中最重要的部分之一。 糟糕的分块导致糟糕的检索。 糟糕的检索导致糟糕的答案。 我构建了可配置的分块大小，带有重叠上下文和唯一分块ID，这样每个分块都能保持与原始文档的连接。 这些分块现在成为整个系统其余部分使用的基本单元。 然后我实现了语义检索。 使用BAAI/bge-small-en-v1.5嵌入模型以及自定义的Qdrant向量存储，我创建了一个可复用的管道，为每个分块生成嵌入并在向量数据库上执行相似性搜索。 将嵌入模型与向量数据库分离教会了我一个重要的软件工程原则： 单一职责使每个组件都可替换。 如果我以后更换嵌入模型或迁移到另一个向量数据库，系统的其余部分无需改动。 在语义搜索之后，我使用BM25构建了关键词检索。 与嵌入不同，BM25没有理解语义的能力。 它只理解词汇。 最初这听起来像是一个限制。 然而，这反而成了它最大的优势之一。 BM25擅长检索嵌入经常遗漏的内容： • 错误代码 • 合同ID • 产品名称 • 工单编号 • 技术标识符 这些精确匹配在企业知识库中非常常见。 下一步是结合两个检索系统。 我实现了互惠排名融合（RRF），它合并排名，而不是尝试比较完全不同的评分系统。 RRF不是问哪个分数更大，而是奖励那些在多种检索方法中始终出现在结果前列的文档。 这成为了我的混合检索器，结合了语义理解与精确关键词匹配。 然后是彻底改变我对检索看法的部分。 知识图谱。 与向量存储不同，图存储不按相似性组织信息。 它们按关系组织信息。 我为以下内容构建了结构化模型： • 实体 • 关系 • 图文档 为了在引入LLM提取器之前验证存储管道，我创建了一个临时的虚拟提取器，它将大写单词识别为实体并生成占位关系。 尽管简单，但它让我验证了整个图摄取过程。 然后我实现了一个Neo4j图存储，它创建： • 分块节点 • 实体节点 • MENTIONS关系 • 实体到实体的关系 使用Neo4j的MERGE操作来防止重复节点。 我无法完全测试该图，因为我的Neo4j服务器没有运行。 但应用程序报错是连接错误——而不是代码错误——这确认了实现本身是正常的。 一个概念彻底改变了我对企业检索的理解。 向量存储和图存储不是竞争对手。 它们解决完全不同的问题。 向量存储回答： “哪些信息看起来相似？” 图存储回答： “这些信息是如何连接的？” 这种差异使得图遍历对于跨人员、公司、产品、合同、供应商或组织结构的多人推理特别有价值。 另一个重要的认识是现代AI系统中数据库的角色。 高级AI代理很少依赖单一数据库。 相反，它们通常结合： • 用于语义知识的向量数据库。 • 用于关系推理的图数据库。 • 用于结构化业务数据的SQL数据库。 每一种都贡献了不同类型的理解。 它们共同创造出比任何单一数据库都强大得多的AI系统。 今天最大的收获： 构建生产级RAG系统不再仅仅是检索相似文档。 而是将语义理解、精确关键词匹配和结构化关系推理结合成一个检索系统，该系统能在生成答案之前从多个角度收集证据。 今天的工作打下了基础。 接下来，我将用LLM驱动的实体和关系提取管道替换虚拟提取器，构建图遍历检索，最后将向量搜索、BM25和知识图谱推理结合成一个真正的智能RAG系统，能够进行多人推理并提供完全引用的答案。 每一天，AI工程都感觉越来越不像构建模型，而更像设计智能系统。 #AIEngineering #AgenticAI #RAG #KnowledgeGraph #Neo4j #BM25 #VectorSearch #EnterpriseAI #LLM #GenerativeAI #SoftwareEngineering #BuildingInPublic
查看原文
查看缓存全文

缓存时间: 2026/07/28 16:28

第62天 — 成为AI工程师

今天我开始构建一个企业知识图谱Agentic RAG系统，并意识到检索远不止是搜索嵌入向量那么简单。

在此之前，我以为RAG主要是对文档进行分块、创建嵌入向量、存储向量并检索最相似的分块。

当我从零开始构建多个检索流水线后，我意识到生产级AI系统实际上通过多种方式检索知识，因为没有任何单一检索方法能做好所有事情。

最大的教训：

企业级AI的关键在于组合不同形式的知识，而不是依赖单一的检索策略。

我正在构建的系统旨在回答组织内部知识库中的问题——包括合同、政策、工单、PDF、HTML页面、Markdown文件、CSV等。

它不依赖单一的向量搜索，而是结合了三种不同的检索方法：

• 使用向量嵌入的语义检索。 • 使用BM25的词法检索。 • 用于关系推理的知识图谱遍历。

最终，一个智能代理将决定针对每个查询采用哪种检索策略——或策略组合。

我首先构建的是文档摄取流水线。

我没有依赖框架提供的文档加载器，而是从头实现了整个流水线。

我创建了一个通用的文档模型，用于标准化进入系统的每个文件，无论其格式如何。

然后我为以下格式构建了加载器：

• PDF • Markdown • HTML • CSV

一个加载器工厂会自动选择正确的加载器，而目录加载器则递归扫描整个知识库，将所有内容转换为统一的文档集合。

一个教训很快就变得显而易见：

元数据与文档本身同样重要。

现在每个文档都携带诸如源文件、页码和行索引等信息。

这些元数据将在后续支持引用、图构建和可解释检索。

接下来是分块。

起初，分块看起来只是一个简单的预处理步骤。

但它最终成为整个流水线中最重要的部分之一。

糟糕的分块导致糟糕的检索。

糟糕的检索导致糟糕的答案。

我构建了可配置的分块大小，包含重叠的上下文和唯一的分块ID，以确保每个分块都能追溯到原始文档。

这些分块现在成为系统其余部分使用的基本单元。

然后我实现了语义检索。

使用BAAI/bge-small-en-v1.5嵌入模型和一个自定义的Qdrant向量存储，我创建了一个可复用的流水线，将每个分块嵌入并对向量数据库执行相似性搜索。

将嵌入模型与向量数据库分离教会了我一个重要的软件工程原则：

单一职责使每个组件都可替换。

如果我将来更换嵌入模型或迁移到另一个向量数据库，系统的其余部分无需改动。

在语义搜索之后，我使用BM25构建了关键词检索。

与嵌入向量不同，BM25不理解语义。

它只理解单词。

起初这听起来像是一个限制。

但实际上这成了它最大的优势之一。

BM25在检索嵌入向量经常错过的东西方面表现出色：

• 错误代码 • 合同ID • 产品名称 • 工单编号 • 技术标识符

这些精确匹配在企业知识库中非常常见。

下一步是结合两种检索系统。

我实现了倒数排序融合（RRF），它合并排名而不是试图比较完全不同的评分系统。

RRF不关心哪个分数更大，它只奖励那些在多种检索方法中始终出现在接近顶部位置的文档。

这成了我的混合检索器，结合了语义理解和精确关键词匹配。

然后到了彻底改变我对检索看法的部分。

知识图谱。

与向量存储不同，图存储不通过相似性组织信息。

它们通过关系组织信息。

我为以下内容构建了结构化模型：

• 实体 • 关系 • 图文档

为了在引入LLM提取器之前验证存储流水线，我创建了一个临时的虚拟提取器，它将大写单词识别为实体并生成占位关系。

虽然简单，但它让我能够验证整个图摄取过程。

然后我实现了一个Neo4j图存储，创建了：

• 分块节点 • 实体节点 • MENTIONS关系 • 实体到实体的关系

使用Neo4j的MERGE操作来防止重复节点。

我无法完全测试图，因为我的Neo4j服务器没有运行。

但应用程序因连接错误而失败——而不是代码错误——这证实了实现本身是正确的。

有一个概念彻底改变了我对企业检索的理解。

向量存储和图存储不是竞争对手。

它们解决完全不同的问题。

向量存储回答：

“什么信息看起来很相似？”

图存储回答：

“这些信息之间是如何连接的？”

这种差异使图遍历对于跨人员、公司、产品、合同、供应商或组织结构的多次跳跃推理尤其有价值。

另一个重要的认识是数据库在现代AI系统中的作用。

高级AI代理很少依赖单一数据库。

相反，它们通常结合：

• 用于语义知识的向量数据库。 • 用于关系推理的图数据库。 • 用于结构化业务数据的SQL数据库。

每种数据库贡献了不同类型的理解。

它们结合在一起，创造了比任何单一数据库都强大得多的AI系统。

今天最大的收获：

构建生产级RAG系统不再仅仅是检索相似的文档。

而是将语义理解、精确关键词匹配和结构化关系推理结合到一个检索系统中，在生成答案之前从多个角度收集证据。

今天的工作奠定了基础。

接下来，我将用LLM驱动的实体和关系提取流水线替换虚拟提取器，构建图遍历检索，并最终将向量搜索、BM25和知识图谱推理结合成一个真正的Agentic RAG系统，该系统能够进行多次跳跃推理并生成完整引用的答案。

每一天，AI工程都感觉越来越不像构建模型，而更像是设计智能系统。

#AIEngineering #AgenticAI #RAG #KnowledgeGraph #Neo4j #BM25 #VectorSearch #EnterpriseAI #LLM #GenerativeAI #SoftwareEngineering #BuildingInPublic

相似文章

AgenticRAG：面向企业知识库的代理检索

arXiv cs.AI

本文介绍了 AgenticRAG，这是一个来自微软的框架，通过为大型语言模型（LLM）配备迭代搜索、文档导航和分析工具，增强了企业知识库的检索能力。它在多个基准测试中展示了相比标准 RAG 流水线在召回率和事实准确性方面的显著提升。