尧图网页设计 
DB-GPT MS-RAG 多源检索增强生成框架深度解析:索引 ETL 流水线、Agentic RAG 检索循环与实战指南【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT本文以 DB-GPT 的 MS-RAG(Multi-Source Enhanced Retrieval-Augmented Generation,多源增强检索增强生成)框架参考文档为主体,完整讲解其索引 对话两阶段架构、七类索引的 ETL 流水线、agentic RAG 对话循环、知识源/存储类型选型与切分参数配置,并结合dbgpt-core与dbgpt-ext源码印证关键实现。读完后,你将理解 DB-GPT 知识库对话一次切分、多索引复用、agent 多轮检索的设计原理,并能在 Web UI 与 Python API 两个层面落地一套带引用的 RAG 问答系统。一、什么是 MS-RAG:从基础 RAG 到多源 agentic RAG大语言模型(LLM)虽然强大,但只能基于训练数据回答。当用户需要最新或领域专属信息——比如内部文档、自建数据库、最新报告——单靠 LLM 就不够了。检索增强生成(RAG)通过从外部知识源检索相关信息、作为上下文喂给 LLM 再生成回答来填补这一缺口,确保回答基于真实数据而非记忆中的模式。DB-GPT 实现的多源 RAG(MS-RAG)框架远超基础文档问答:它支持多种知识源(文档、URL、数据库、知识图谱、git 仓库)、多种索引策略,并与 DB-GPT 的 agent 和工作流生态深度集成。知识库对话由agentic RAG循环完成——agent 可以改写问题、多次检索、融合并重排结果、产出带引用的回答——而不是单次检索-生成。如果想先建立为什么层面的直觉,建议先读仓库中的两篇设计文档:知识库索引原理——一篇文档如何变得可被检索:结构索引 / 知识图谱索引(含代码图谱) / 向量索引 / 关键词索引;Agentic RAG 对话原理——一个问题如何通过 agent 驱动的检索循环变成带引用的回答。二、架构总览:索引与对话两个阶段MS-RAG 的整体运行分为两个相互解耦的阶段:索引(文档同步时执行) 对话(聊天时执行) ───────────────────── ────────────────────── 知识源 → 切分 → 索引 用户问题 │ │ 一次切分, ▼ 多种索引: Agentic RAG 循环 • 向量 • 关键词 (改写问题 → 检索,可能多轮 • 知识图谱(三元组、 → 融合 重排 → 拼 prompt) • 文档-段落、Markdown 标题、 │ • 代码 AST) ▼ LLM 生成带引用的回答索引与对话解耦:索引在文档同步时执行一次,对话时只检索,不重新索引。这意味着索引阶段的成本(尤其是 LLM 三元组抽取、摘要生成)只发生一次,而高频的对话请求只承受轻量检索开销——从源码结构看,这也是为什么 DB-GPT 把加载封装为 Assembler 的persist()方法、把检索封装为独立的as_retriever()方法的原因,见 BaseAssembler 基类。2.1 索引流水线:一条 ETL 流水线喂给所有索引构建索引是一条ETL流水线——一次抽取 一次切分喂给所有启用的索引;只有各索引自己的转换和加载不同。抽取 Extract 转换 Transform 加载 Load ───────────── ────────────────────── ─────────────────────── Knowledge.load() → ChunkManager.split() → 持久化进索引存储 解析数据源 → 各索引自己的转换: · EmbeddingAssembler → 向量库 原始文本 · embedding (向量) · BM25Assembler → Elasticsearch · 分词 (关键词/BM25) · graph store RepoGraphBuilder · 三元组 / 标题 / → 图存储 / 代码图谱 代码 AST (知识图谱) · SummaryAssembler → 向量库 · 摘要 (summary) · DBSchemaAssembler → 向量库 附上元数据(标题路径、 chunk_id …)供检索/引用四个阶段的职责如下:抽取(Extract)——KnowledgeFactory把每个数据源(文件/URL/文本/git 仓库)路由到对应的Knowledge实现,解析成原始文本(Knowledge.load())。在 KnowledgeFactory.create 中可以看到,它按KnowledgeType分派:DOCUMENT 走文件扩展名路由、URL 走URLKnowledge、TEXT 走StringKnowledge;扩展名到具体Knowledge子类的匹配由 _select_document_knowledge 完成,所有已注册的实现(如 PDF、Markdown、Excel)集中在 dbgpt_ext/rag/knowledge 目录下。转换(Transform)——ChunkManager.split()按策略(大小/页/段落/分隔符/Markdown 标题)切分;每个索引再各自转换——embedding、BM25 分词、LLM 三元组/标题/代码 AST 抽取、摘要、schema embedding——并附上元数据(Header1…Header6、chunk_id…),后续检索和引用都靠它。加载(Load)—— 按索引的驱动器把转换结果持久化进索引存储:向量/关键词/摘要/schema 索引分别由EmbeddingAssembler/BM25Assembler/SummaryAssembler/DBSchemaAssembler写入(见 assembler 目录);知识图谱与代码图谱由图存储(aload_document)RepoGraphBuilder构建(见 repo_graph_builder.py)。结构索引不加载——它在检索时按本阶段写入的HeaderN元数据重建。检索与生成—— 即下文的 agentic RAG 对话。2.2 统一的 ETL 骨架:BaseAssemblerBaseAssembler定义了统一的抽取 → 转换 → 加载骨架,各索引插入各自的转换加载。一次抽取 一次切分喂给所有启用的索引——只有转换加载随索引不同而不同:Knowledge.load() → ChunkManager.split() → Assembler.persist() → Assembler.as_retriever() # 抽取 # 转换 # 加载 # 检索(对话时)从 BaseAssembler 源码 可以看到这一骨架的落地:构造函数内先建好ChunkManager,随后load_knowledge()依次执行knowledge.load()(抽取)与self._chunk_manager.split(documents)(切分),并在 tracer 中记录chunk_parameters等元数据;子类只需实现两个抽象方法persist()(加载)与as_retriever()(检索器工厂)。以向量索引为例,EmbeddingAssembler.persist 将 chunks 批量写入向量库,as_retriever()则返回一个绑定top_k与检索策略的EmbeddingRetriever。索引转换加载驱动(实现)索引存储向量chunk → embeddingEmbeddingAssembler.persist()向量库(Chroma、Milvus …)关键词chunk → BM25 分词BM25Assembler.persist()Elasticsearch知识图谱chunk → LLM 三元组 文档/标题/代码 AST 图图存储aload_documentRepoGraphBuilderTuGraph / Neo4j / Memgraph摘要chunk → LLM 摘要 → embeddingSummaryAssembler.persist()向量库库表 schemaschema → embeddingDBSchemaAssembler.persist()向量库代码图谱代码 → tree-sitter ASTRepoGraphBuilder→CodeGraphStore代码图谱表结构(无——检索时才建)检索时按HeaderN元数据建DocTreeIndex—各 assembler 是向量/关键词/摘要/schema 索引的加载阶段驱动器;知识图谱与代码图谱分别由图存储和RepoGraphBuilder构建。它们消费的都是抽取转换阶段产出的同一批 chunk——所以切分质量是所有索引的共同地基。三、索引体系:一次切分,七种索引形态DB-GPT 通过index_methods(字符串列表)按知识空间选择要建哪些索引。三种索引方法是持久化的;结构索引和代码图谱是叠加在它们之上的两种形态。所有索引都作用在同一批 chunk上,所以切分质量决定检索质量。索引index_methods值同步时建?能给你什么向量VectorStore是embedding 余弦的语义相似度排序关键词FullText是精确词 / BM25 命中知识图谱KnowledgeGraph是对实体、文档结构、标题、代码做图遍历结构(检索时建树)否,查询时按 chunk 的HeaderN元数据重建Markdown 标题树 / 父子章节导航代码图谱(叠加在KnowledgeGraph;也用于GIT_REPO空间)是代码文件 AST,产出function/class节点 defines边知识图谱索引不是一张图,而是一组图:LLM 抽取的三元组图、文档-段落结构图、Markdown 标题层级图,以及(代码/git 仓库场景下的)代码 AST 图。它们共用一条构建链路。细节与代码图谱的 tree-sitter 解析见知识库索引原理。四、对话:Agentic RAG 检索循环用户在知识库上提问时,DB-GPT不是单次检索-生成,而是由agent驱动循环:问题 │ ▼ 问题改写 / 多问题 ◄── LLM 扩展问题以提升召回 │ ▼ 检索(向量 关键词 图谱,可能多轮) ◄── 可迭代:检索 → 判断 → 再检索 │ ▼ 融合 重排 │ ▼ 拼上下文,生成带引用的回答正是这个 agentic 循环——多步检索、问题改写、结果融合重排、引用——让 DB-GPT 能回答单次 RAG 应付不了的复杂或多部分问题。完整流程见 Agentic RAG 对话原理。4.1 检索策略可在知识库设置里配置检索模式:策略描述所需后端Semantic基于 embedding 的向量相似度检索向量库Keyword基于 BM25 的关键词匹配ElasticsearchHybrid向量 关键词,用 RRF(倒数排名融合)合并向量库 ElasticsearchTree在 Markdown 标题层级上的树结构检索向量库这些模式在源码中由 RetrieverStrategy 枚举 统一定义,包含EMBEDDING/SEMANTIC/GRAPH/Tree/KEYWORD/HYBRID六种取值,是各检索器(向量、BM25、图谱、文档树)统一挂载的策略标识;图谱子策略与文档树检索的实现在 dbgpt_ext/rag/retriever 目录(如bm25.py、doc_tree.py、graph_retriever/)。4.2 查询增强:问题改写与重排除原始检索外,agentic 循环还提供高级查询处理:问题改写(Query Rewrite)—— 用 LLM 把原问题扩展/改写成多个检索问题以提升召回,并判断是否需要再检索一轮。改写能力由 rewrite 算子 与 rewrite 检索器 承载。重排(Reranking)—— 检索后,用 reranker 重打分、重排结果再进 prompt,提升精度。重排的统一抽象是 Ranker 基类,工作流侧则由 RerankOperator 作为 MapOperator 接入 AWEL DAG。支持的重排器重排器类型描述CrossEncoderRanker本地sentence-transformers CrossEncoder 模型QwenRerankEmbeddings本地经 transformers 的 Qwen3-RerankerOpenAPIRerankEmbeddingsAPI兼容 OpenAI 风格 rerank APIRRFRanker算法倒数排名融合,合并多源结果DefaultRanker算法按分数简单排序从源码可以确认两类实现的分工:算法型排序器(DefaultRanker、RRFRanker、CrossEncoderRanker、RerankEmbeddingsRanker等)集中在 retriever/rerank.py;模型型重排 embedding(CrossEncoderRerankEmbeddings、QwenRerankEmbeddings、OpenAPIRerankEmbeddings及其衍生实现)集中在 embedding/rerank.py,并通过RerankEmbeddingFactory统一部署。五、知识源:从 PDF 到 Git 仓库DB-GPT 支持从多种类型的源加载知识。Web UI 上传时可选数据源类型:5.1 数据源类型类型描述例子Document上传各种格式文件PDF、Word、Excel、CSV、Markdown、PowerPoint、TXT、HTML、JSON、ZIPURL抓取并索引网页内容任意可访问 HTTP/HTTPS URLText直接输入原始文本在 UI 里粘贴文本Yuque从语雀导入语雀文档链接Git Repo克隆代码仓库并索引为代码图谱GitHub/GitLab 仓库 URL5.2 支持的文档格式格式扩展名Knowledge 类PDF.pdfPDFKnowledgeCSV.csvCSVKnowledgeMarkdown.mdMarkdownKnowledgeWord (docx).docxDocxKnowledgeWord (旧版).docWord97DocKnowledgeExcel.xlsxExcelKnowledgePowerPoint.pptxPPTXKnowledge纯文本.txtTXTKnowledgeHTML.htmlHTMLKnowledgeJSON.jsonJSONKnowledge代码.py .java .js .ts .go .rs .c .cpp …CodeFileKnowledge(用 tree-sitter 解析进代码图谱)表中每个Knowledge类都能在 dbgpt_ext/rag/knowledge 目录找到对应实现文件(如pdf.py、markdown.py、code_file.py、git_repo.py、url.py、string.py),工厂通过遍历Knowledge.__subclasses()并按document_type()返回的扩展名做路由,因此新增格式只需新增一个Knowledge子类。六、存储类型与后端选型创建知识库时选择用哪些索引存储——可多选,互补:存储类型index_methods描述最适合Vector StoreVectorStore存 embedding 做语义相似度检索通用文档问答Knowledge GraphKnowledgeGraph构建图谱族(LLM 三元组 文档/标题/代码结构)做关系型检索实体关系复杂、含代码或结构化文档的领域知识Full TextFullText全文/BM25 索引做关键词检索精确词匹配、关键词搜索6.1 向量库后端后端描述安装 extraChromaDB默认嵌入式向量库,零配置storage_chromadbMilvus生产级分布式向量库storage_milvusPGVectorPostgreSQL 的向量扩展storage_pgvectorValkey内存型高性能向量库,HNSW/FLAT 索引storage_valkeyWeaviate云原生向量检索引擎storage_weaviateElasticsearch全文 向量混合检索storage_elasticsearchOceanBase云原生分布式数据库storage_oceanbase6.2 知识图谱后端后端描述TuGraph蚂蚁集团的高性能图数据库Neo4j流行的开源图数据库Memgraph内存型图数据库,低延迟6.3 全文后端后端描述Elasticsearch行业标准全文检索引擎OpenSearchAWS 的搜索与分析套件七、Embedding 模型DB-GPT 支持多种把文本转向量的 embedding 模型:7.1 本地模型模型类描述HuggingFaceHuggingFaceEmbeddings通用 HuggingFace 模型BGE 系列HuggingFaceBgeEmbeddingsBAAI BGE,支持 instruction(中英)InstructorHuggingFaceInstructEmbeddings指令跟随型 embedding7.2 远程 API 模型提供方类描述OpenAI 兼容OpenAPIEmbeddings任意 OpenAI 兼容 embedding APIJinaJinaEmbeddingsJina AI embedding 服务OllamaOllamaEmbeddings本地 Ollama embedding 服务通义(阿里云)TongyiEmbeddings阿里云 DashScope千帆(百度)QianfanEmbeddings百度文心SiliconFlowSiliconFlowEmbeddingsSiliconFlow embedding 服务远程 API 类(如JinaEmbeddings、OllamaEmbeddings、TongyiEmbeddings等)位于 dbgpt_ext/rag/embeddings 目录;本地 HuggingFace 系列与模型工厂位于 dbgpt/rag/embedding(含embedding_factory.py)。选择模型时注意:同一知识空间内切分参数、embedding 模型一旦确定并写入索引,更换模型通常意味着重建索引。八、知识图谱 RAG:一组图而非一张图启用KnowledgeGraph索引方法时,DB-GPT 构建的是一组图,而非单张图。它们共用一条构建链路,都支持沿边检索:LLM 三元组图—— 用 LLM 从每个 chunk 抽取(主语, 谓词, 宾语)三元组,以实体 -边- 实体形式 upsert 进图存储(TuGraph、Neo4j 或 Memgraph)。每条边记得来自哪个 chunk,所以答案仍可溯源。文档-段落图——document → chunk → chunk(include/next边)的结构骨架,让检索能从实体跳到包含它的 chunk 和文档。(启用社区汇总变体时,还会做社区检测并用 LLM 总结每个社区,见 community_summarizer.py。)Markdown 标题图—— 对.md文件建file → H1 → H2 → H3(contains)层级。这是结构索引的图版本。代码图谱—— 对代码文件和GIT_REPO空间,用tree-sitter解析(Python/Java/JavaScript/TypeScript/Go/Rust/C/C),产出function/class/method/interface/struct… 节点和file → defines → node边。这让apply_anthropic_cache_control定义在哪?这类代码级问题能精确命中。tree-sitter 相关工具见 tree_sitter_utils.py。retriever 还支持CALLS/INHERITS/IMPLEMENTS边,但当前代码图谱 builder只产出contains和defines。调用链/继承遍历只有在别的 builder 产出过这些边时才有结果。完整细节与该 caveat 见知识库索引原理。8.1 图检索子策略检索时GraphRetriever组合使用多种子策略(实现在 graph_retriever 目录):关键词—— 按抽取的关键词匹配图节点向量—— 对图节点 embedding 做语义相似度文本(Text2GQL)—— 用 LLM 把自然语言转成图查询语言文档—— 通过文档-图关联检索九、切分策略与参数切分是 RAG 质量的关键——它是所有索引的共同地基。DB-GPT 支持多种切分策略:策略Splitter描述按大小RecursiveCharacterTextSplitter按字符数切,可配大小和重叠(默认 512 / 50)按页PageTextSplitter按页边界切(适合 PDF)按段落ParagraphTextSplitter按段落边界切按分隔符SeparatorTextSplitter按自定义分隔符切按 Markdown 标题MarkdownHeaderTextSplitter按标题层级切,保留标题路径(结构索引和标题图都用它)9.1 切分参数参数描述默认chunk_size每个 chunk 最大字符数512chunk_overlap相邻 chunk 重叠字符数50topk每次检索取的 chunk 数5recall_score相关度阈值0recall_type召回策略(TopK)TopKmodel使用的 embedding 模型取决于配置这些默认值与 ChunkParameters 模型 的源码定义一致:chunk_size默认 512、chunk_overlap默认 50、separator默认\n,此外还支持chunk_strategy(切分策略名)、text_splitter(直接指定 splitter 实例)、splitter_type(langchain/llama-index/user_define三档,默认user_define)与enable_merge(是否按 chunk_size 合并碎块)等源码级参数,用于在 AWEL 工作流中精细控制切分行为。切分器本体位于 dbgpt/rag/text_splitter(text_splitter.py、code_splitter.py),并有对应单测 test_splitters.py。实践建议:对含大量精确术语(错误码、API 名)的文档,把chunk_size调小并适当增大chunk_overlap,避免关键信息被切断;对 Markdown 规范文档,优先使用按 Markdown 标题切分,HeaderN元数据会同时喂给结构索引与标题图,收益最大;因为所有索引共享同一批 chunk,切分参数变更需要重建全部启用的索引。十、使用方式10.1 创建知识库(Web UI)第 1 步 —— 打开知识管理在侧边栏进入Knowledge。第 2 步 —— 创建并配置点击Create新建知识库。选择要启用的索引方法(Vector Store / Knowledge Graph / Full Text,可组合)。选择Embedding 模型并配置切分参数。第 3 步 —— 上传数据选择数据源类型并上传内容。支持 Document(PDF、Word、Excel、CSV 等)、URL、Text、Yuque、Git Repo。第 4 步 —— 配置切分选择切分策略并设置参数(见 9.1 切分参数 的默认值表)。第 5 步 —— 配置检索策略(可选)可配置检索策略。DB-GPT 支持 Semantic / Keyword / Hybrid / Tree 等多种模式,按场景在知识库设置里选择。第 6 步 —— 与知识库对话进入Chat,点聊天输入栏的知识库图标,下拉选中你的知识库,开始提问。对话即走前述 agentic RAG 循环:问题改写 → 多轮检索 → 融合重排 → 带引用回答。10.2 编程使用(Python API)以下示例按 EmbeddingAssembler 实际签名 编写,完整复现抽取 → 转换 → 加载 → 检索链路:from dbgpt.rag import Chunk # Chunk/Document 由 dbgpt.rag 统一导出 from dbgpt_ext.rag.assembler import EmbeddingAssembler from dbgpt_ext.rag.knowledge import KnowledgeFactory # 抽取:按文件扩展名路由到具体 Knowledge 实现,解析成原始文本 knowledge KnowledgeFactory.create(datasourceyour_document.pdf) # 转换 加载:切分、embedding,并准备写入向量索引 # 异步构建可改用 await EmbeddingAssembler.aload_from_knowledge(...) assembler EmbeddingAssembler.load_from_knowledge( knowledgeknowledge, index_storeyour_vector_store, # IndexStoreBase 实例(Chroma/Milvus/…) embeddingsyour_embedding_model, # Embeddings 实例 ) chunk_ids assembler.persist() # 加载:批量写入向量库,返回 chunk id 列表 # 检索(对话时):向量索引回答相似度查询 retriever assembler.as_retriever(top_k5) chunks retriever.retrieve(What is the main topic?)要点说明:KnowledgeFactory.create()的入参是datasource(文件路径、URL 或文本),配合knowledge_type决定走文档/URL/文本分支,见 factory.py;persist()支持max_chunks_once_load、max_threads参数控制批量写入节奏,异步版本apersist()还支持按file_id归属;想要 BM25/摘要/DB schema 索引,只需把EmbeddingAssembler换成 assembler 目录 下的BM25Assembler/SummaryAssembler/DBSchemaAssembler,抽取与切分流程完全复用。仓库还提供了可直接运行的端到端示例,覆盖向量 RAG、混合检索、重写增强、图谱 RAG、评估等场景,位于 examples/rag 目录(如embedding_rag_example.py、rewrite_rag_example.py、graph_rag_example.py、bm25_retriever_example.py、retriever_evaluation_example.py),可对照本文各节理解每一环节。十一、小结与延伸阅读MS-RAG 的设计可以浓缩为三句话:一次抽取、一次切分,喂给所有索引——BaseAssembler的 ETL 骨架保证向量、关键词、图谱、摘要、schema 索引消费同一批 chunk,切分质量是共同地基;索引与对话解耦—— 同步时构建持久索引,对话时只做轻量检索,重计算(三元组抽取、摘要)只发生一次;对话是 agentic 循环而非单次 RAG—— 问题改写、多轮检索、RRF 融合与 reranker 重排,让复杂多部分问题也能得到带引用的回答。主题链接索引原理(结构 / 知识图谱 / 代码图谱 / 向量 / 关键词)知识库索引原理agentic RAG 对话原理Agentic RAG 对话原理Graph RAG 应用配置Graph RAG核心 RAG 模块源码dbgpt/rag扩展实现(Assembler/Knowledge/检索器)dbgpt_ext/ragRAG 运行示例脚本examples/rag【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DB-GPT MS-RAG 多源检索增强生成框架深度解析:索引 ETL 流水线、Agentic RAG 检索循环与实战指南
DB-GPT MS-RAG 多源检索增强生成框架深度解析:索引 ETL 流水线、Agentic RAG 检索循环与实战指南【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT本文以 DB-GPT 的 MS-RAG(Multi-Source Enhanced Retrieval-Augmented Generation,多源增强检索增强生成)框架参考文档为主体,完整讲解其索引 对话两阶段架构、七类索引的 ETL 流水线、agentic RAG 对话循环、知识源/存储类型选型与切分参数配置,并结合dbgpt-core与dbgpt-ext源码印证关键实现。读完后,你将理解 DB-GPT 知识库对话一次切分、多索引复用、agent 多轮检索的设计原理,并能在 Web UI 与 Python API 两个层面落地一套带引用的 RAG 问答系统。一、什么是 MS-RAG:从基础 RAG 到多源 agentic RAG大语言模型(LLM)虽然强大,但只能基于训练数据回答。当用户需要最新或领域专属信息——比如内部文档、自建数据库、最新报告——单靠 LLM 就不够了。检索增强生成(RAG)通过从外部知识源检索相关信息、作为上下文喂给 LLM 再生成回答来填补这一缺口,确保回答基于真实数据而非记忆中的模式。DB-GPT 实现的多源 RAG(MS-RAG)框架远超基础文档问答:它支持多种知识源(文档、URL、数据库、知识图谱、git 仓库)、多种索引策略,并与 DB-GPT 的 agent 和工作流生态深度集成。知识库对话由agentic RAG循环完成——agent 可以改写问题、多次检索、融合并重排结果、产出带引用的回答——而不是单次检索-生成。如果想先建立为什么层面的直觉,建议先读仓库中的两篇设计文档:知识库索引原理——一篇文档如何变得可被检索:结构索引 / 知识图谱索引(含代码图谱) / 向量索引 / 关键词索引;Agentic RAG 对话原理——一个问题如何通过 agent 驱动的检索循环变成带引用的回答。二、架构总览:索引与对话两个阶段MS-RAG 的整体运行分为两个相互解耦的阶段:索引(文档同步时执行) 对话(聊天时执行) ───────────────────── ────────────────────── 知识源 → 切分 → 索引 用户问题 │ │ 一次切分, ▼ 多种索引: Agentic RAG 循环 • 向量 • 关键词 (改写问题 → 检索,可能多轮 • 知识图谱(三元组、 → 融合 重排 → 拼 prompt) • 文档-段落、Markdown 标题、 │ • 代码 AST) ▼ LLM 生成带引用的回答索引与对话解耦:索引在文档同步时执行一次,对话时只检索,不重新索引。这意味着索引阶段的成本(尤其是 LLM 三元组抽取、摘要生成)只发生一次,而高频的对话请求只承受轻量检索开销——从源码结构看,这也是为什么 DB-GPT 把加载封装为 Assembler 的persist()方法、把检索封装为独立的as_retriever()方法的原因,见 BaseAssembler 基类。2.1 索引流水线:一条 ETL 流水线喂给所有索引构建索引是一条ETL流水线——一次抽取 一次切分喂给所有启用的索引;只有各索引自己的转换和加载不同。抽取 Extract 转换 Transform 加载 Load ───────────── ────────────────────── ─────────────────────── Knowledge.load() → ChunkManager.split() → 持久化进索引存储 解析数据源 → 各索引自己的转换: · EmbeddingAssembler → 向量库 原始文本 · embedding (向量) · BM25Assembler → Elasticsearch · 分词 (关键词/BM25) · graph store RepoGraphBuilder · 三元组 / 标题 / → 图存储 / 代码图谱 代码 AST (知识图谱) · SummaryAssembler → 向量库 · 摘要 (summary) · DBSchemaAssembler → 向量库 附上元数据(标题路径、 chunk_id …)供检索/引用四个阶段的职责如下:抽取(Extract)——KnowledgeFactory把每个数据源(文件/URL/文本/git 仓库)路由到对应的Knowledge实现,解析成原始文本(Knowledge.load())。在 KnowledgeFactory.create 中可以看到,它按KnowledgeType分派:DOCUMENT 走文件扩展名路由、URL 走URLKnowledge、TEXT 走StringKnowledge;扩展名到具体Knowledge子类的匹配由 _select_document_knowledge 完成,所有已注册的实现(如 PDF、Markdown、Excel)集中在 dbgpt_ext/rag/knowledge 目录下。转换(Transform)——ChunkManager.split()按策略(大小/页/段落/分隔符/Markdown 标题)切分;每个索引再各自转换——embedding、BM25 分词、LLM 三元组/标题/代码 AST 抽取、摘要、schema embedding——并附上元数据(Header1…Header6、chunk_id…),后续检索和引用都靠它。加载(Load)—— 按索引的驱动器把转换结果持久化进索引存储:向量/关键词/摘要/schema 索引分别由EmbeddingAssembler/BM25Assembler/SummaryAssembler/DBSchemaAssembler写入(见 assembler 目录);知识图谱与代码图谱由图存储(aload_document)RepoGraphBuilder构建(见 repo_graph_builder.py)。结构索引不加载——它在检索时按本阶段写入的HeaderN元数据重建。检索与生成—— 即下文的 agentic RAG 对话。2.2 统一的 ETL 骨架:BaseAssemblerBaseAssembler定义了统一的抽取 → 转换 → 加载骨架,各索引插入各自的转换加载。一次抽取 一次切分喂给所有启用的索引——只有转换加载随索引不同而不同:Knowledge.load() → ChunkManager.split() → Assembler.persist() → Assembler.as_retriever() # 抽取 # 转换 # 加载 # 检索(对话时)从 BaseAssembler 源码 可以看到这一骨架的落地:构造函数内先建好ChunkManager,随后load_knowledge()依次执行knowledge.load()(抽取)与self._chunk_manager.split(documents)(切分),并在 tracer 中记录chunk_parameters等元数据;子类只需实现两个抽象方法persist()(加载)与as_retriever()(检索器工厂)。以向量索引为例,EmbeddingAssembler.persist 将 chunks 批量写入向量库,as_retriever()则返回一个绑定top_k与检索策略的EmbeddingRetriever。索引转换加载驱动(实现)索引存储向量chunk → embeddingEmbeddingAssembler.persist()向量库(Chroma、Milvus …)关键词chunk → BM25 分词BM25Assembler.persist()Elasticsearch知识图谱chunk → LLM 三元组 文档/标题/代码 AST 图图存储aload_documentRepoGraphBuilderTuGraph / Neo4j / Memgraph摘要chunk → LLM 摘要 → embeddingSummaryAssembler.persist()向量库库表 schemaschema → embeddingDBSchemaAssembler.persist()向量库代码图谱代码 → tree-sitter ASTRepoGraphBuilder→CodeGraphStore代码图谱表结构(无——检索时才建)检索时按HeaderN元数据建DocTreeIndex—各 assembler 是向量/关键词/摘要/schema 索引的加载阶段驱动器;知识图谱与代码图谱分别由图存储和RepoGraphBuilder构建。它们消费的都是抽取转换阶段产出的同一批 chunk——所以切分质量是所有索引的共同地基。三、索引体系:一次切分,七种索引形态DB-GPT 通过index_methods(字符串列表)按知识空间选择要建哪些索引。三种索引方法是持久化的;结构索引和代码图谱是叠加在它们之上的两种形态。所有索引都作用在同一批 chunk上,所以切分质量决定检索质量。索引index_methods值同步时建?能给你什么向量VectorStore是embedding 余弦的语义相似度排序关键词FullText是精确词 / BM25 命中知识图谱KnowledgeGraph是对实体、文档结构、标题、代码做图遍历结构(检索时建树)否,查询时按 chunk 的HeaderN元数据重建Markdown 标题树 / 父子章节导航代码图谱(叠加在KnowledgeGraph;也用于GIT_REPO空间)是代码文件 AST,产出function/class节点 defines边知识图谱索引不是一张图,而是一组图:LLM 抽取的三元组图、文档-段落结构图、Markdown 标题层级图,以及(代码/git 仓库场景下的)代码 AST 图。它们共用一条构建链路。细节与代码图谱的 tree-sitter 解析见知识库索引原理。四、对话:Agentic RAG 检索循环用户在知识库上提问时,DB-GPT不是单次检索-生成,而是由agent驱动循环:问题 │ ▼ 问题改写 / 多问题 ◄── LLM 扩展问题以提升召回 │ ▼ 检索(向量 关键词 图谱,可能多轮) ◄── 可迭代:检索 → 判断 → 再检索 │ ▼ 融合 重排 │ ▼ 拼上下文,生成带引用的回答正是这个 agentic 循环——多步检索、问题改写、结果融合重排、引用——让 DB-GPT 能回答单次 RAG 应付不了的复杂或多部分问题。完整流程见 Agentic RAG 对话原理。4.1 检索策略可在知识库设置里配置检索模式:策略描述所需后端Semantic基于 embedding 的向量相似度检索向量库Keyword基于 BM25 的关键词匹配ElasticsearchHybrid向量 关键词,用 RRF(倒数排名融合)合并向量库 ElasticsearchTree在 Markdown 标题层级上的树结构检索向量库这些模式在源码中由 RetrieverStrategy 枚举 统一定义,包含EMBEDDING/SEMANTIC/GRAPH/Tree/KEYWORD/HYBRID六种取值,是各检索器(向量、BM25、图谱、文档树)统一挂载的策略标识;图谱子策略与文档树检索的实现在 dbgpt_ext/rag/retriever 目录(如bm25.py、doc_tree.py、graph_retriever/)。4.2 查询增强:问题改写与重排除原始检索外,agentic 循环还提供高级查询处理:问题改写(Query Rewrite)—— 用 LLM 把原问题扩展/改写成多个检索问题以提升召回,并判断是否需要再检索一轮。改写能力由 rewrite 算子 与 rewrite 检索器 承载。重排(Reranking)—— 检索后,用 reranker 重打分、重排结果再进 prompt,提升精度。重排的统一抽象是 Ranker 基类,工作流侧则由 RerankOperator 作为 MapOperator 接入 AWEL DAG。支持的重排器重排器类型描述CrossEncoderRanker本地sentence-transformers CrossEncoder 模型QwenRerankEmbeddings本地经 transformers 的 Qwen3-RerankerOpenAPIRerankEmbeddingsAPI兼容 OpenAI 风格 rerank APIRRFRanker算法倒数排名融合,合并多源结果DefaultRanker算法按分数简单排序从源码可以确认两类实现的分工:算法型排序器(DefaultRanker、RRFRanker、CrossEncoderRanker、RerankEmbeddingsRanker等)集中在 retriever/rerank.py;模型型重排 embedding(CrossEncoderRerankEmbeddings、QwenRerankEmbeddings、OpenAPIRerankEmbeddings及其衍生实现)集中在 embedding/rerank.py,并通过RerankEmbeddingFactory统一部署。五、知识源:从 PDF 到 Git 仓库DB-GPT 支持从多种类型的源加载知识。Web UI 上传时可选数据源类型:5.1 数据源类型类型描述例子Document上传各种格式文件PDF、Word、Excel、CSV、Markdown、PowerPoint、TXT、HTML、JSON、ZIPURL抓取并索引网页内容任意可访问 HTTP/HTTPS URLText直接输入原始文本在 UI 里粘贴文本Yuque从语雀导入语雀文档链接Git Repo克隆代码仓库并索引为代码图谱GitHub/GitLab 仓库 URL5.2 支持的文档格式格式扩展名Knowledge 类PDF.pdfPDFKnowledgeCSV.csvCSVKnowledgeMarkdown.mdMarkdownKnowledgeWord (docx).docxDocxKnowledgeWord (旧版).docWord97DocKnowledgeExcel.xlsxExcelKnowledgePowerPoint.pptxPPTXKnowledge纯文本.txtTXTKnowledgeHTML.htmlHTMLKnowledgeJSON.jsonJSONKnowledge代码.py .java .js .ts .go .rs .c .cpp …CodeFileKnowledge(用 tree-sitter 解析进代码图谱)表中每个Knowledge类都能在 dbgpt_ext/rag/knowledge 目录找到对应实现文件(如pdf.py、markdown.py、code_file.py、git_repo.py、url.py、string.py),工厂通过遍历Knowledge.__subclasses()并按document_type()返回的扩展名做路由,因此新增格式只需新增一个Knowledge子类。六、存储类型与后端选型创建知识库时选择用哪些索引存储——可多选,互补:存储类型index_methods描述最适合Vector StoreVectorStore存 embedding 做语义相似度检索通用文档问答Knowledge GraphKnowledgeGraph构建图谱族(LLM 三元组 文档/标题/代码结构)做关系型检索实体关系复杂、含代码或结构化文档的领域知识Full TextFullText全文/BM25 索引做关键词检索精确词匹配、关键词搜索6.1 向量库后端后端描述安装 extraChromaDB默认嵌入式向量库,零配置storage_chromadbMilvus生产级分布式向量库storage_milvusPGVectorPostgreSQL 的向量扩展storage_pgvectorValkey内存型高性能向量库,HNSW/FLAT 索引storage_valkeyWeaviate云原生向量检索引擎storage_weaviateElasticsearch全文 向量混合检索storage_elasticsearchOceanBase云原生分布式数据库storage_oceanbase6.2 知识图谱后端后端描述TuGraph蚂蚁集团的高性能图数据库Neo4j流行的开源图数据库Memgraph内存型图数据库,低延迟6.3 全文后端后端描述Elasticsearch行业标准全文检索引擎OpenSearchAWS 的搜索与分析套件七、Embedding 模型DB-GPT 支持多种把文本转向量的 embedding 模型:7.1 本地模型模型类描述HuggingFaceHuggingFaceEmbeddings通用 HuggingFace 模型BGE 系列HuggingFaceBgeEmbeddingsBAAI BGE,支持 instruction(中英)InstructorHuggingFaceInstructEmbeddings指令跟随型 embedding7.2 远程 API 模型提供方类描述OpenAI 兼容OpenAPIEmbeddings任意 OpenAI 兼容 embedding APIJinaJinaEmbeddingsJina AI embedding 服务OllamaOllamaEmbeddings本地 Ollama embedding 服务通义(阿里云)TongyiEmbeddings阿里云 DashScope千帆(百度)QianfanEmbeddings百度文心SiliconFlowSiliconFlowEmbeddingsSiliconFlow embedding 服务远程 API 类(如JinaEmbeddings、OllamaEmbeddings、TongyiEmbeddings等)位于 dbgpt_ext/rag/embeddings 目录;本地 HuggingFace 系列与模型工厂位于 dbgpt/rag/embedding(含embedding_factory.py)。选择模型时注意:同一知识空间内切分参数、embedding 模型一旦确定并写入索引,更换模型通常意味着重建索引。八、知识图谱 RAG:一组图而非一张图启用KnowledgeGraph索引方法时,DB-GPT 构建的是一组图,而非单张图。它们共用一条构建链路,都支持沿边检索:LLM 三元组图—— 用 LLM 从每个 chunk 抽取(主语, 谓词, 宾语)三元组,以实体 -边- 实体形式 upsert 进图存储(TuGraph、Neo4j 或 Memgraph)。每条边记得来自哪个 chunk,所以答案仍可溯源。文档-段落图——document → chunk → chunk(include/next边)的结构骨架,让检索能从实体跳到包含它的 chunk 和文档。(启用社区汇总变体时,还会做社区检测并用 LLM 总结每个社区,见 community_summarizer.py。)Markdown 标题图—— 对.md文件建file → H1 → H2 → H3(contains)层级。这是结构索引的图版本。代码图谱—— 对代码文件和GIT_REPO空间,用tree-sitter解析(Python/Java/JavaScript/TypeScript/Go/Rust/C/C),产出function/class/method/interface/struct… 节点和file → defines → node边。这让apply_anthropic_cache_control定义在哪?这类代码级问题能精确命中。tree-sitter 相关工具见 tree_sitter_utils.py。retriever 还支持CALLS/INHERITS/IMPLEMENTS边,但当前代码图谱 builder只产出contains和defines。调用链/继承遍历只有在别的 builder 产出过这些边时才有结果。完整细节与该 caveat 见知识库索引原理。8.1 图检索子策略检索时GraphRetriever组合使用多种子策略(实现在 graph_retriever 目录):关键词—— 按抽取的关键词匹配图节点向量—— 对图节点 embedding 做语义相似度文本(Text2GQL)—— 用 LLM 把自然语言转成图查询语言文档—— 通过文档-图关联检索九、切分策略与参数切分是 RAG 质量的关键——它是所有索引的共同地基。DB-GPT 支持多种切分策略:策略Splitter描述按大小RecursiveCharacterTextSplitter按字符数切,可配大小和重叠(默认 512 / 50)按页PageTextSplitter按页边界切(适合 PDF)按段落ParagraphTextSplitter按段落边界切按分隔符SeparatorTextSplitter按自定义分隔符切按 Markdown 标题MarkdownHeaderTextSplitter按标题层级切,保留标题路径(结构索引和标题图都用它)9.1 切分参数参数描述默认chunk_size每个 chunk 最大字符数512chunk_overlap相邻 chunk 重叠字符数50topk每次检索取的 chunk 数5recall_score相关度阈值0recall_type召回策略(TopK)TopKmodel使用的 embedding 模型取决于配置这些默认值与 ChunkParameters 模型 的源码定义一致:chunk_size默认 512、chunk_overlap默认 50、separator默认\n,此外还支持chunk_strategy(切分策略名)、text_splitter(直接指定 splitter 实例)、splitter_type(langchain/llama-index/user_define三档,默认user_define)与enable_merge(是否按 chunk_size 合并碎块)等源码级参数,用于在 AWEL 工作流中精细控制切分行为。切分器本体位于 dbgpt/rag/text_splitter(text_splitter.py、code_splitter.py),并有对应单测 test_splitters.py。实践建议:对含大量精确术语(错误码、API 名)的文档,把chunk_size调小并适当增大chunk_overlap,避免关键信息被切断;对 Markdown 规范文档,优先使用按 Markdown 标题切分,HeaderN元数据会同时喂给结构索引与标题图,收益最大;因为所有索引共享同一批 chunk,切分参数变更需要重建全部启用的索引。十、使用方式10.1 创建知识库(Web UI)第 1 步 —— 打开知识管理在侧边栏进入Knowledge。第 2 步 —— 创建并配置点击Create新建知识库。选择要启用的索引方法(Vector Store / Knowledge Graph / Full Text,可组合)。选择Embedding 模型并配置切分参数。第 3 步 —— 上传数据选择数据源类型并上传内容。支持 Document(PDF、Word、Excel、CSV 等)、URL、Text、Yuque、Git Repo。第 4 步 —— 配置切分选择切分策略并设置参数(见 9.1 切分参数 的默认值表)。第 5 步 —— 配置检索策略(可选)可配置检索策略。DB-GPT 支持 Semantic / Keyword / Hybrid / Tree 等多种模式,按场景在知识库设置里选择。第 6 步 —— 与知识库对话进入Chat,点聊天输入栏的知识库图标,下拉选中你的知识库,开始提问。对话即走前述 agentic RAG 循环:问题改写 → 多轮检索 → 融合重排 → 带引用回答。10.2 编程使用(Python API)以下示例按 EmbeddingAssembler 实际签名 编写,完整复现抽取 → 转换 → 加载 → 检索链路:from dbgpt.rag import Chunk # Chunk/Document 由 dbgpt.rag 统一导出 from dbgpt_ext.rag.assembler import EmbeddingAssembler from dbgpt_ext.rag.knowledge import KnowledgeFactory # 抽取:按文件扩展名路由到具体 Knowledge 实现,解析成原始文本 knowledge KnowledgeFactory.create(datasourceyour_document.pdf) # 转换 加载:切分、embedding,并准备写入向量索引 # 异步构建可改用 await EmbeddingAssembler.aload_from_knowledge(...) assembler EmbeddingAssembler.load_from_knowledge( knowledgeknowledge, index_storeyour_vector_store, # IndexStoreBase 实例(Chroma/Milvus/…) embeddingsyour_embedding_model, # Embeddings 实例 ) chunk_ids assembler.persist() # 加载:批量写入向量库,返回 chunk id 列表 # 检索(对话时):向量索引回答相似度查询 retriever assembler.as_retriever(top_k5) chunks retriever.retrieve(What is the main topic?)要点说明:KnowledgeFactory.create()的入参是datasource(文件路径、URL 或文本),配合knowledge_type决定走文档/URL/文本分支,见 factory.py;persist()支持max_chunks_once_load、max_threads参数控制批量写入节奏,异步版本apersist()还支持按file_id归属;想要 BM25/摘要/DB schema 索引,只需把EmbeddingAssembler换成 assembler 目录 下的BM25Assembler/SummaryAssembler/DBSchemaAssembler,抽取与切分流程完全复用。仓库还提供了可直接运行的端到端示例,覆盖向量 RAG、混合检索、重写增强、图谱 RAG、评估等场景,位于 examples/rag 目录(如embedding_rag_example.py、rewrite_rag_example.py、graph_rag_example.py、bm25_retriever_example.py、retriever_evaluation_example.py),可对照本文各节理解每一环节。十一、小结与延伸阅读MS-RAG 的设计可以浓缩为三句话:一次抽取、一次切分,喂给所有索引——BaseAssembler的 ETL 骨架保证向量、关键词、图谱、摘要、schema 索引消费同一批 chunk,切分质量是共同地基;索引与对话解耦—— 同步时构建持久索引,对话时只做轻量检索,重计算(三元组抽取、摘要)只发生一次;对话是 agentic 循环而非单次 RAG—— 问题改写、多轮检索、RRF 融合与 reranker 重排,让复杂多部分问题也能得到带引用的回答。主题链接索引原理(结构 / 知识图谱 / 代码图谱 / 向量 / 关键词)知识库索引原理agentic RAG 对话原理Agentic RAG 对话原理Graph RAG 应用配置Graph RAG核心 RAG 模块源码dbgpt/rag扩展实现(Assembler/Knowledge/检索器)dbgpt_ext/ragRAG 运行示例脚本examples/rag【免费下载链接】DB-GPTopen-source agentic AI data assistant for the next generation of AI Data products.项目地址: https://gitcode.com/GitHub_Trending/db/DB-GPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考