DB-GPT KBQA 常见问题排查Embedding 模型部署、向量库切换与知识库管理库排错实战【免费下载链接】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 仓库的 KBQA FAQ 文档系统梳理知识库问答KBQA, Knowledge Base Question Answering落地过程中的五类高频问题Embedding 模型text2vec-large-chinese找不到的下载与放置方式、通过VECTOR_STORE_TYPE切换向量数据库含 OceanBase 的完整接入流程、大模型输出“非法字符”的调参手段、knowledge_space表缺列导致的建库报错修复以及 MySQL 模式下 KBQA 系统库的初始化。读完后你可以独立完成 KBQA 知识库问答环境从 Embedding 模型到向量存储的全链路部署与故障排查。1. KBQA 的存储底座为什么这五类问题总是一起出现DB-GPT 的 KBQA 应用由三部分组成Embedding 模型负责把知识库文档切片和检索 query 转成向量。仓库默认 Embedding 配置为text2vec即中文模型text2vec-large-chinese向量数据库负责向量的存储与近邻检索默认 Chroma可切换 Milvus、Weaviate、OceanBase 等知识库管理库存放知识库space、文档file、切片chunk等元数据默认 SQLite生产环境建议 MySQL。三者任一配置不当都会导致 KBQA 不可用这正是 FAQ 中五个问题反复出现的根源。下文逐一展开并给出对应的源码证据。2. 问题一text2vec-large-chinese not found——Embedding 模型缺失2.1 现象与原理如果启动服务或首次导入知识库时报错text2vec-large-chinese not found说明默认 Embedding 模型权重未就位。从源码结构看model_config.py 将text2vec这一 Embedding 类型映射到固定路径text2vec: os.path.join(MODEL_PATH, text2vec-large-chinese),即模型必须位于models/text2vec-large-chinese目录下。同时全局配置 中 Embedding 默认值就是text2vecself.EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text2vec)只要不显式通过EMBEDDING_MODEL环境变量指定其他 Embedding 模型就必须先准备好该模型权重。2.2 解决步骤该模型仓库基于 Git LFS 存储因此第一步必须先安装git-lfs否则 clone 下来的只是指针文件而非真实权重# CentOS yum install git-lfs # Ubuntu apt-get install git-lfs -y # macOS brew install git-lfs然后在项目根目录的models下拉取模型cd models git lfs clone https://huggingface.co/GanymedeNil/text2vec-large-chinese完成后目录结构应为models/text2vec-large-chinese/包含model.safetensors、vocab.txt等权重与配置文件。重启服务即可正常加载。提示如果不方便使用本地模型也可以通过EMBEDDING_MODEL环境变量切换为其他可在线调用的 Embedding 实现仓库文档 RAG 模块说明 中有 Embedding 相关章节可供参考。3. 问题二如何切换向量数据库类型VECTOR_STORE_TYPE3.1 配置入口.env中的 VECTOR STORE SETTINGS修改项目根目录的.env文件中的VECTOR_STORE_TYPE即可切换向量库。FAQ 给出的配置块如下#*******************************************************************# #** VECTOR STORE SETTINGS **# #*******************************************************************# VECTOR_STORE_TYPEChroma #MILVUS_URL127.0.0.1 #MILVUS_PORT19530 #MILVUS_USERNAME #MILVUS_PASSWORD #MILVUS_SECURE #WEAVIATE_URLhttps://kt-region-m8hcy0wc.weaviate.network各变量的默认值可以在 全局配置解析处 得到印证self.VECTOR_STORE_TYPE os.getenv(VECTOR_STORE_TYPE, Chroma) self.MILVUS_URL os.getenv(MILVUS_URL, 127.0.0.1) self.MILVUS_PORT os.getenv(MILVUS_PORT, 19530) self.MILVUS_USERNAME os.getenv(MILVUS_USERNAME, None) self.MILVUS_PASSWORD os.getenv(MILVUS_PASSWORD, None)也就是说不设置时默认 Chroma若设置VECTOR_STORE_TYPEMilvus则必须同时给出MILVUS_URL与MILVUS_PORT默认127.0.0.1:19530需要鉴权时再补MILVUS_USERNAME/MILVUS_PASSWORD。3.2 当前支持的向量库清单文档与源码的对照FAQ 原文指出 DB-GPT 支持Chroma默认、Milvus要求 2.1 以上、Weaviate、Valkey、OceanBase五类向量库。而从当前仓库的存储路由实现看可选项已经更多storage/init.py 中的_select_rag_storage按名称分发到对应实现def _select_rag_storage(name: str) - Tuple[Type, Type]: if name Chroma: return _import_chroma() elif name Milvus: return _import_milvus() elif name Weaviate: return _import_weaviate() elif name PGVector: return _import_pgvector() elif name OceanBase: return _import_oceanbase() elif name ElasticSearch: return _import_elastic() elif name Qdrant: return _import_qdrant() elif name Valkey: return _import_valkey() ... else: raise AttributeError(fCould not find: {name})对应的具体实现位于 vector_store 目录包括chroma_store.py、milvus_store.py、weaviate_store.py、oceanbase_store.py、valkey_store.py、pgvector_store.py、qdrant_store.py、elastic_store.py。可以推断实际可用的向量库以上述路由表为准FAQ 列举的是撰写当时支持的核心五类且若名称无法匹配会直接抛出AttributeError这有助于快速定位“配置拼写错误”类问题。需要说明的是切换VECTOR_STORE_TYPE后已存在 Chroma 中的向量数据不会自动迁移生产环境切换建议重建知识库索引。3.3 OceanBase 向量库的完整接入流程FAQ 对 OceanBase 给出了四步接入法这里完整继承并结合源码补充说明第 1 步用 Docker 启动 OceanBase 社区版容器docker run --nameob433 -e MODEslim -p 2881:2881 -d quay.io/oceanbase/oceanbase-ce:4.3.3.0-100000142024101215-e MODEslim使用精简模式启动2881是 OB 服务端口。第 2 步安装 Python 客户端 pyobvectorpip install --upgrade --quiet pyobvector第 3 步验证连通性并设置向量内存占比from pyobvector import ObVecClient tmp_client ObVecClient() tmp_client.perform_raw_text_sql( ALTER SYSTEM ob_vector_memory_limit_percentage 30 )这条ALTER SYSTEM语句把 OB 用于向量索引的内存占比设为 30%向量检索依赖内存中的索引该参数直接影响查询性能。第 4 步在.env中配置连接参数VECTOR_STORE_TYPEOceanBase OB_HOST127.0.0.1 OB_PORT2881 OB_USERroottest OB_DATABASEtest ## Optional # OB_PASSWORD ## Optional: If {OB_ENABLE_NORMALIZE_VECTOR} is set, the vector stored in OceanBase is normalized. # OB_ENABLE_NORMALIZE_VECTORTrue这些变量在 config.py 中的解析逻辑 中可以得到逐一对应# OceanBase Configuration self.OB_HOST os.getenv(OB_HOST, 127.0.0.1) self.OB_PORT int(os.getenv(OB_PORT, 2881)) self.OB_USER os.getenv(OB_USER, root) self.OB_PASSWORD os.getenv(OB_PASSWORD, ) self.OB_DATABASE os.getenv(OB_DATABASE, test) self.OB_ENABLE_NORMALIZE_VECTOR bool( os.getenv(OB_ENABLE_NORMALIZE_VECTOR, ) )OB_ENABLE_NORMALIZE_VECTORTrue表示入库向量会先做归一化适用于以余弦相似度为主的检索场景。如需自行集成其他向量库可以参考仓库中文档目录下的 RAG/向量存储相关文档 以及 vector_store 实现目录 中任一现有实现作为模板。4. 问题三vicuna-13b 回答出现“非法字符”当使用 vicuna-13b 等模型时KBQA 回答中偶尔会混入大量乱码或非法 tokenFAQ 原文配有截图此处从略。FAQ 给出的处置方式是调小KNOWLEDGE_SEARCH_TOP_SIZE或KNOWLEDGE_CHUNK_SIZE然后重启服务。这两个参数控制进入 LLM 上下文的知识内容量默认值定义在 config.pyself.KNOWLEDGE_CHUNK_SIZE int(os.getenv(KNOWLEDGE_CHUNK_SIZE, 100)) ... self.KNOWLEDGE_SEARCH_TOP_SIZE int(os.getenv(KNOWLEDGE_SEARCH_TOP_SIZE, 5))KNOWLEDGE_SEARCH_TOP_SIZE每次检索返回的 top-k 切片数默认 5KNOWLEDGE_CHUNK_SIZE文档切片的 token 粒度默认 100。它们被 knowledge/service.py 在文档入库与知识检索两个环节直接消费chunk_sizeCFG.KNOWLEDGE_CHUNK_SIZE, ... topk: CFG.KNOWLEDGE_SEARCH_TOP_SIZE, chunk_size: CFG.KNOWLEDGE_CHUNK_SIZE,从源码结构看两者共同决定了拼装给大模型的 knowledge context 的总长度。参数量级过大时上下文容易超出模型的有效窗口导致模型“幻觉”输出乱码因此适当调小例如KNOWLEDGE_SEARCH_TOP_SIZE2~3是稳妥的缓解手段。修改.env后必须重启 dbgpt 服务使配置生效。5. 问题四space add error——knowledge_space.context列缺失5.1 现象在管理库使用 MySQL 时创建知识库space报如下错误(pymysql.err.OperationalError) (1054, Unknown column knowledge_space.context in field list)原因是旧版本建库的knowledge_space表缺少context扩展参数上下文字段而当前代码的 ORM 模型已包含该列。5.2 修复步骤FAQ 原文四步法停止 dbgpt 服务Ctrl C关闭 dbgpt_server登录 MySQLmysql -h127.0.0.1 -uroot -p {your_password}对knowledge_management库执行 DDL 补列use knowledge_management; ALTER TABLE knowledge_space ADD COLUMN context TEXT COMMENT arguments context;重启 dbgpt servespace add即可恢复正常。该操作的本质是一次存量管理库的 schema 升级。当前仓库的 assets/schema/upgrade 目录 下按版本v0_5_1、v0_6_0、v0_8_2 等保留了历次升级 SQL说明 DB-GPT 的管理库 schema 随版本演进需要定期对齐升级前建议通读对应版本的升级脚本。6. 问题五MySQL 模式下如何初始化 KBQA 系统库KBQA 的元数据知识库、文档、切片默认存 SQLite若要用 MySQL 承载需要先建出 KBQA 系统库的表结构。FAQ 给出的命令为$ mysql -h127.0.0.1 -uroot -p{your_password} ./assets/schema/knowledge_management.sql需要向读者说明一个版本差异当前仓库快照的 assets/schema 目录下可见dbgpt.sql、code_graph_tables.sql以及按版本组织的upgrade/目录但 FAQ 引用的knowledge_management.sql这一独立历史脚本已不单独存在其建表内容已并入主库脚本与版本升级脚本体系。因此在当前版本部署时更可靠的做法是参考 assets/schema/dbgpt.sql 与upgrade/下对应版本的升级脚本确认knowledge_space、knowledge_file、knowledge_space_file、knowledge_space_chunk等 KBQA 核心表均已存在且字段齐全在.env/ 应用配置中将知识库管理库指向 MySQL 连接用户、库名与 FAQ 中的knowledge_management保持一致启动服务验证space add等接口正常。这样既遵循了 FAQ 的“先建 schema、后起服务”的顺序又适配了当前仓库的脚本组织方式。7. 关键配置速查表环境变量默认值作用源码位置EMBEDDING_MODELtext2vecEmbedding 模型类型决定加载哪个权重config.pyVECTOR_STORE_TYPEChroma向量库类型Chroma/Milvus/Weaviate/OceanBase/Valkey/PGVector/ElasticSearch/Qdrant 等config.pyMILVUS_URL/MILVUS_PORT127.0.0.1/19530Milvus 连接地址config.pyOB_HOST/OB_PORT/OB_USER/OB_DATABASE127.0.0.1/2881/root/testOceanBase 连接参数config.pyOB_ENABLE_NORMALIZE_VECTOR空关闭是否对入库向量做归一化config.pyKNOWLEDGE_SEARCH_TOP_SIZE5检索返回的 top-k 切片数config.pyKNOWLEDGE_CHUNK_SIZE100文档切片粒度tokenconfig.py8. 小结模型找不到确认git-lfs已安装并正确拉取text2vec-large-chinese到models/目录对应 model_config.py 中的路径约定换向量库改VECTOR_STORE_TYPE并配齐对应连接参数可用类型以_select_rag_storage路由表为准OceanBase 需按 FAQ 四步法启动容器、装pyobvector、设向量内存占比、写.env输出乱码调小KNOWLEDGE_SEARCH_TOP_SIZE/KNOWLEDGE_CHUNK_SIZE后重启服务建库报缺列按 FAQ 的ALTER TABLE knowledge_space ADD COLUMN context TEXT补列MySQL 系统库先建 schema 再起服务注意当前仓库脚本组织与 FAQ 历史版本的差异。以上排查路径全部可以在 KBQA FAQ 原文 中找到一一对应的操作步骤配合仓库内源码即可快速定位 KBQA 部署中的绝大多数问题。【免费下载链接】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 KBQA 常见问题排查：Embedding 模型部署、向量库切换与知识库管理库排错实战
DB-GPT KBQA 常见问题排查Embedding 模型部署、向量库切换与知识库管理库排错实战【免费下载链接】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 仓库的 KBQA FAQ 文档系统梳理知识库问答KBQA, Knowledge Base Question Answering落地过程中的五类高频问题Embedding 模型text2vec-large-chinese找不到的下载与放置方式、通过VECTOR_STORE_TYPE切换向量数据库含 OceanBase 的完整接入流程、大模型输出“非法字符”的调参手段、knowledge_space表缺列导致的建库报错修复以及 MySQL 模式下 KBQA 系统库的初始化。读完后你可以独立完成 KBQA 知识库问答环境从 Embedding 模型到向量存储的全链路部署与故障排查。1. KBQA 的存储底座为什么这五类问题总是一起出现DB-GPT 的 KBQA 应用由三部分组成Embedding 模型负责把知识库文档切片和检索 query 转成向量。仓库默认 Embedding 配置为text2vec即中文模型text2vec-large-chinese向量数据库负责向量的存储与近邻检索默认 Chroma可切换 Milvus、Weaviate、OceanBase 等知识库管理库存放知识库space、文档file、切片chunk等元数据默认 SQLite生产环境建议 MySQL。三者任一配置不当都会导致 KBQA 不可用这正是 FAQ 中五个问题反复出现的根源。下文逐一展开并给出对应的源码证据。2. 问题一text2vec-large-chinese not found——Embedding 模型缺失2.1 现象与原理如果启动服务或首次导入知识库时报错text2vec-large-chinese not found说明默认 Embedding 模型权重未就位。从源码结构看model_config.py 将text2vec这一 Embedding 类型映射到固定路径text2vec: os.path.join(MODEL_PATH, text2vec-large-chinese),即模型必须位于models/text2vec-large-chinese目录下。同时全局配置 中 Embedding 默认值就是text2vecself.EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text2vec)只要不显式通过EMBEDDING_MODEL环境变量指定其他 Embedding 模型就必须先准备好该模型权重。2.2 解决步骤该模型仓库基于 Git LFS 存储因此第一步必须先安装git-lfs否则 clone 下来的只是指针文件而非真实权重# CentOS yum install git-lfs # Ubuntu apt-get install git-lfs -y # macOS brew install git-lfs然后在项目根目录的models下拉取模型cd models git lfs clone https://huggingface.co/GanymedeNil/text2vec-large-chinese完成后目录结构应为models/text2vec-large-chinese/包含model.safetensors、vocab.txt等权重与配置文件。重启服务即可正常加载。提示如果不方便使用本地模型也可以通过EMBEDDING_MODEL环境变量切换为其他可在线调用的 Embedding 实现仓库文档 RAG 模块说明 中有 Embedding 相关章节可供参考。3. 问题二如何切换向量数据库类型VECTOR_STORE_TYPE3.1 配置入口.env中的 VECTOR STORE SETTINGS修改项目根目录的.env文件中的VECTOR_STORE_TYPE即可切换向量库。FAQ 给出的配置块如下#*******************************************************************# #** VECTOR STORE SETTINGS **# #*******************************************************************# VECTOR_STORE_TYPEChroma #MILVUS_URL127.0.0.1 #MILVUS_PORT19530 #MILVUS_USERNAME #MILVUS_PASSWORD #MILVUS_SECURE #WEAVIATE_URLhttps://kt-region-m8hcy0wc.weaviate.network各变量的默认值可以在 全局配置解析处 得到印证self.VECTOR_STORE_TYPE os.getenv(VECTOR_STORE_TYPE, Chroma) self.MILVUS_URL os.getenv(MILVUS_URL, 127.0.0.1) self.MILVUS_PORT os.getenv(MILVUS_PORT, 19530) self.MILVUS_USERNAME os.getenv(MILVUS_USERNAME, None) self.MILVUS_PASSWORD os.getenv(MILVUS_PASSWORD, None)也就是说不设置时默认 Chroma若设置VECTOR_STORE_TYPEMilvus则必须同时给出MILVUS_URL与MILVUS_PORT默认127.0.0.1:19530需要鉴权时再补MILVUS_USERNAME/MILVUS_PASSWORD。3.2 当前支持的向量库清单文档与源码的对照FAQ 原文指出 DB-GPT 支持Chroma默认、Milvus要求 2.1 以上、Weaviate、Valkey、OceanBase五类向量库。而从当前仓库的存储路由实现看可选项已经更多storage/init.py 中的_select_rag_storage按名称分发到对应实现def _select_rag_storage(name: str) - Tuple[Type, Type]: if name Chroma: return _import_chroma() elif name Milvus: return _import_milvus() elif name Weaviate: return _import_weaviate() elif name PGVector: return _import_pgvector() elif name OceanBase: return _import_oceanbase() elif name ElasticSearch: return _import_elastic() elif name Qdrant: return _import_qdrant() elif name Valkey: return _import_valkey() ... else: raise AttributeError(fCould not find: {name})对应的具体实现位于 vector_store 目录包括chroma_store.py、milvus_store.py、weaviate_store.py、oceanbase_store.py、valkey_store.py、pgvector_store.py、qdrant_store.py、elastic_store.py。可以推断实际可用的向量库以上述路由表为准FAQ 列举的是撰写当时支持的核心五类且若名称无法匹配会直接抛出AttributeError这有助于快速定位“配置拼写错误”类问题。需要说明的是切换VECTOR_STORE_TYPE后已存在 Chroma 中的向量数据不会自动迁移生产环境切换建议重建知识库索引。3.3 OceanBase 向量库的完整接入流程FAQ 对 OceanBase 给出了四步接入法这里完整继承并结合源码补充说明第 1 步用 Docker 启动 OceanBase 社区版容器docker run --nameob433 -e MODEslim -p 2881:2881 -d quay.io/oceanbase/oceanbase-ce:4.3.3.0-100000142024101215-e MODEslim使用精简模式启动2881是 OB 服务端口。第 2 步安装 Python 客户端 pyobvectorpip install --upgrade --quiet pyobvector第 3 步验证连通性并设置向量内存占比from pyobvector import ObVecClient tmp_client ObVecClient() tmp_client.perform_raw_text_sql( ALTER SYSTEM ob_vector_memory_limit_percentage 30 )这条ALTER SYSTEM语句把 OB 用于向量索引的内存占比设为 30%向量检索依赖内存中的索引该参数直接影响查询性能。第 4 步在.env中配置连接参数VECTOR_STORE_TYPEOceanBase OB_HOST127.0.0.1 OB_PORT2881 OB_USERroottest OB_DATABASEtest ## Optional # OB_PASSWORD ## Optional: If {OB_ENABLE_NORMALIZE_VECTOR} is set, the vector stored in OceanBase is normalized. # OB_ENABLE_NORMALIZE_VECTORTrue这些变量在 config.py 中的解析逻辑 中可以得到逐一对应# OceanBase Configuration self.OB_HOST os.getenv(OB_HOST, 127.0.0.1) self.OB_PORT int(os.getenv(OB_PORT, 2881)) self.OB_USER os.getenv(OB_USER, root) self.OB_PASSWORD os.getenv(OB_PASSWORD, ) self.OB_DATABASE os.getenv(OB_DATABASE, test) self.OB_ENABLE_NORMALIZE_VECTOR bool( os.getenv(OB_ENABLE_NORMALIZE_VECTOR, ) )OB_ENABLE_NORMALIZE_VECTORTrue表示入库向量会先做归一化适用于以余弦相似度为主的检索场景。如需自行集成其他向量库可以参考仓库中文档目录下的 RAG/向量存储相关文档 以及 vector_store 实现目录 中任一现有实现作为模板。4. 问题三vicuna-13b 回答出现“非法字符”当使用 vicuna-13b 等模型时KBQA 回答中偶尔会混入大量乱码或非法 tokenFAQ 原文配有截图此处从略。FAQ 给出的处置方式是调小KNOWLEDGE_SEARCH_TOP_SIZE或KNOWLEDGE_CHUNK_SIZE然后重启服务。这两个参数控制进入 LLM 上下文的知识内容量默认值定义在 config.pyself.KNOWLEDGE_CHUNK_SIZE int(os.getenv(KNOWLEDGE_CHUNK_SIZE, 100)) ... self.KNOWLEDGE_SEARCH_TOP_SIZE int(os.getenv(KNOWLEDGE_SEARCH_TOP_SIZE, 5))KNOWLEDGE_SEARCH_TOP_SIZE每次检索返回的 top-k 切片数默认 5KNOWLEDGE_CHUNK_SIZE文档切片的 token 粒度默认 100。它们被 knowledge/service.py 在文档入库与知识检索两个环节直接消费chunk_sizeCFG.KNOWLEDGE_CHUNK_SIZE, ... topk: CFG.KNOWLEDGE_SEARCH_TOP_SIZE, chunk_size: CFG.KNOWLEDGE_CHUNK_SIZE,从源码结构看两者共同决定了拼装给大模型的 knowledge context 的总长度。参数量级过大时上下文容易超出模型的有效窗口导致模型“幻觉”输出乱码因此适当调小例如KNOWLEDGE_SEARCH_TOP_SIZE2~3是稳妥的缓解手段。修改.env后必须重启 dbgpt 服务使配置生效。5. 问题四space add error——knowledge_space.context列缺失5.1 现象在管理库使用 MySQL 时创建知识库space报如下错误(pymysql.err.OperationalError) (1054, Unknown column knowledge_space.context in field list)原因是旧版本建库的knowledge_space表缺少context扩展参数上下文字段而当前代码的 ORM 模型已包含该列。5.2 修复步骤FAQ 原文四步法停止 dbgpt 服务Ctrl C关闭 dbgpt_server登录 MySQLmysql -h127.0.0.1 -uroot -p {your_password}对knowledge_management库执行 DDL 补列use knowledge_management; ALTER TABLE knowledge_space ADD COLUMN context TEXT COMMENT arguments context;重启 dbgpt servespace add即可恢复正常。该操作的本质是一次存量管理库的 schema 升级。当前仓库的 assets/schema/upgrade 目录 下按版本v0_5_1、v0_6_0、v0_8_2 等保留了历次升级 SQL说明 DB-GPT 的管理库 schema 随版本演进需要定期对齐升级前建议通读对应版本的升级脚本。6. 问题五MySQL 模式下如何初始化 KBQA 系统库KBQA 的元数据知识库、文档、切片默认存 SQLite若要用 MySQL 承载需要先建出 KBQA 系统库的表结构。FAQ 给出的命令为$ mysql -h127.0.0.1 -uroot -p{your_password} ./assets/schema/knowledge_management.sql需要向读者说明一个版本差异当前仓库快照的 assets/schema 目录下可见dbgpt.sql、code_graph_tables.sql以及按版本组织的upgrade/目录但 FAQ 引用的knowledge_management.sql这一独立历史脚本已不单独存在其建表内容已并入主库脚本与版本升级脚本体系。因此在当前版本部署时更可靠的做法是参考 assets/schema/dbgpt.sql 与upgrade/下对应版本的升级脚本确认knowledge_space、knowledge_file、knowledge_space_file、knowledge_space_chunk等 KBQA 核心表均已存在且字段齐全在.env/ 应用配置中将知识库管理库指向 MySQL 连接用户、库名与 FAQ 中的knowledge_management保持一致启动服务验证space add等接口正常。这样既遵循了 FAQ 的“先建 schema、后起服务”的顺序又适配了当前仓库的脚本组织方式。7. 关键配置速查表环境变量默认值作用源码位置EMBEDDING_MODELtext2vecEmbedding 模型类型决定加载哪个权重config.pyVECTOR_STORE_TYPEChroma向量库类型Chroma/Milvus/Weaviate/OceanBase/Valkey/PGVector/ElasticSearch/Qdrant 等config.pyMILVUS_URL/MILVUS_PORT127.0.0.1/19530Milvus 连接地址config.pyOB_HOST/OB_PORT/OB_USER/OB_DATABASE127.0.0.1/2881/root/testOceanBase 连接参数config.pyOB_ENABLE_NORMALIZE_VECTOR空关闭是否对入库向量做归一化config.pyKNOWLEDGE_SEARCH_TOP_SIZE5检索返回的 top-k 切片数config.pyKNOWLEDGE_CHUNK_SIZE100文档切片粒度tokenconfig.py8. 小结模型找不到确认git-lfs已安装并正确拉取text2vec-large-chinese到models/目录对应 model_config.py 中的路径约定换向量库改VECTOR_STORE_TYPE并配齐对应连接参数可用类型以_select_rag_storage路由表为准OceanBase 需按 FAQ 四步法启动容器、装pyobvector、设向量内存占比、写.env输出乱码调小KNOWLEDGE_SEARCH_TOP_SIZE/KNOWLEDGE_CHUNK_SIZE后重启服务建库报缺列按 FAQ 的ALTER TABLE knowledge_space ADD COLUMN context TEXT补列MySQL 系统库先建 schema 再起服务注意当前仓库脚本组织与 FAQ 历史版本的差异。以上排查路径全部可以在 KBQA FAQ 原文 中找到一一对应的操作步骤配合仓库内源码即可快速定位 KBQA 部署中的绝大多数问题。【免费下载链接】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），仅供参考