检索引擎负责保存索引并执行向量、关键词或混合检索。默认 PostgreSQL 部署使用 ParadeDB 镜像提供 pgvector 和 BM25，可与业务数据共用数据库。需要独立扩容或复用现有基础设施时，可选择其他后端。 选择后端时，结合部署依赖、容量和数据隔离要求： 切换引擎需要重建索引。知识库绑定的向量存储在创建后不可修改，应在建库前确定实例。 检索设置将召回、融合等参数分组展示。RRF 使用各路结果的排名融合向量和关键词检索，可调整平滑参数及两路权重。建议用同一组有代表性的问题比较结果，再决定是否保存；提高某一路权重不等于提高模型回答准确率。 只有一路结果时不执行双路 RRF。参数含义与默认值见下文 RRF 加权融合 。 多模态 Embedding 与图片召回 ​ 支持图片输入的向量模型可将文本和图片编码到同一空间。知识库默认不开启图片向量，需要同时配置多模态与「图片向量检索」；已有文档需重新解析，扫描 PDF 页不生成图片向量。画廊只展示已有图片，不依赖此开关。详情见 知识库图片配置 。 命中图片可交给支持图片输入的重排模型评估，视觉对话模型能直接看到保留的命中原图；纯文本模型使用描述等文本信息。原图向量与描述/OCR 文本索引分别管理，关闭开关停止图片向量召回，不自动删除已有向量。 说明：无论引擎自身是否提供"混合检索"，WeKnora 的混合始终是 上层统一的 RRF 融合 （ knowledgebase_search_fusion.go ）——向量与关键词各自独立检索，按 rank 加权合并（见 混合检索打分与归一化 ），因此各引擎只需分别提供两类单模检索。 核心开关（ .env.example C1 节、 docker-compose.yml ）： 除环境变量（env store，进程级全局）外，还可在管理端为租户创建 VectorStore 记录（DB store）并绑定到具体 KB——同一引擎类型可接多套集群实例，检索时按 KB 绑定自动路由并做租户属主校验（ 检索时的引擎选择 ）。 分层架构：Repository → KVHybridRetrieveEngine → Composite → Registry ​ 每个后端实现 interfaces.RetrieveEngineRepository （ EngineType() / Support() / Save / BatchSave / Retrieve / DeleteBy* / CopyIndices / BatchUpdateChunkEnabledStatus / BatchUpdateChunkTagID / EstimateStorageSize ）。其上依次是： KVHybridRetrieveEngine （ retriever/keywords_vector_hybrid_indexer.go ）：把 Repository 包装成 RetrieveEngineService ，负责在 Index 时按支持的检索类型计算 embedding 并写入； CompositeRetrieveEngine （ retriever/composite.go ）：组合模式。 Retrieve 按每个 RetrieveParams.RetrieverType （ vector / keywords ）路由到第一个支持该类型的引擎并发执行； Index / Delete / CopyIndices 等写操作广播到所有成员引擎； RetrieveEngineRegistry （ retriever/registry.go ）：双索引注册表—— byEngineType （ RETRIEVE_DRIVER 环境变量驱动的"env store"，每类型仅一个）与 byStoreID （数据库 VectorStore 表驱动的实例级注册，同一引擎类型可注册多实例，如两个 ES 集群）。 启动时某个向量存储恰好不可用（后端还没起来、网络抖动），它就不会进入 byStoreID ；此后所有绑定该 store 的知识库检索、甚至删除知识库都会一直失败。注册表因此支持 按需重建 ： GetOrLoadByStoreID 命中不到时，用注入的 VectorStoreRepository + EngineFactory 现场构建引擎并注册；仓库或工厂任一为 nil 时退化为普通查找； 单次构建有 EngineBuildTimeout （10s）上限， singleflight 把并发请求合并成一次构建； 构建失败进入 rebuildCooldown （30s）冷却，避免后端持续不可用时每个请求都白等一个完整超时； 用 storeGen 代际计数防止竞态：构建开始前采样，只有代际没变才发布结果，因此构建期间发生的注册或删除不会被旧结果覆盖。 删除知识库时若引擎尚未就绪，也会走这条重建路径重试，而不是直接判失败。 引擎注册：initRetrieveEngineRegistry ​ internal/container/container.go 。启动时解析 RETRIEVE_DRIVER （逗号分隔），逐驱动构建客户端并 registry.Register(retriever.NewKVHybridRetrieveEngine(repo, engineType)) ；单个驱动初始化失败只记日志不阻断启动。随后 loadDBStoresIntoRegistry 从 vector_stores 表加载租户自建的向量存储实例，经 createEngineServiceFromStore （ engine_factory.go ）构建引擎后 RegisterWithStoreID 注册。 检索入口 HybridSearch （ knowledgebase_search.go ）按 KB 的绑定关系选择引擎： resolveStoreGroups 把参与检索的 KB 按 (VectorStoreID, 属主租户) 分组； 每组调用 retriever.CreateRetrieveEngineForKB （ factory.go ）： KB 未绑定 store（ VectorStoreID 为空，当前默认）→ 走租户的 GetRetrieverEngines() ：租户配置了 RetrieverEngines.Engines 则用之，否则 GetDefaultRetrieverEngines() 按 RETRIEVE_DRIVER 环境变量生成（ internal/types/tenant.go ）； KB 绑定了 store → 先 ownership.StoreOwnedBy 校验租户属主（防跨租户探测，失败返回 ErrVectorStoreForbidden ），再 registry.GetByStoreID 取实例（未注册返回 ErrVectorStoreNotFound ），包装为单成员 Composite； KB 未绑定 store（ VectorStoreID 为空，当前默认）→ 走租户的 GetRetrieverEngines() ：租户配置了 RetrieverEngines.Engines 则用之，否则 GetDefaultRetrieverEngines() 按 RETRIEVE_DRIVER 环境变量生成（ internal/types/tenant.go ）； KB 绑定了 store → 先 ownership.StoreOwnedBy 校验租户属主（防跨租户探测，失败返回 ErrVectorStoreForbidden ），再 registry.GetByStoreID 取实例（未注册返回 ErrVectorStoreNotFound ），包装为单成员 Composite； buildRetrievalParams 按引擎 SupportRetriever 能力与 KB 类型生成向量/关键词两类 RetrieveParams （FAQ 库只走 FAQ 向量索引，文档库走默认向量索引 + 关键词索引）； 多组时 retrieveFromStores errgroup 并发 fan-out（上限 4 组、每组超时 MULTI_STORE_RETRIEVE_TIMEOUT_SEC 默认 30s），结果跨引擎类型时做分数归一化。 引擎类型常量见 internal/types/retriever.go ： postgres 、 elasticsearch 、 opensearch 、 qdrant 、 milvus 、 weaviate 、 doris 、 sqlite 、 tencent_vectordb （另有 infinity 、 elasticfaiss 为遗留枚举，无可部署实现）。除特别注明外，所有引擎的 Support() 均返回 [keywords, vector] 两类。 PostgreSQL（pgvector + ParadeDB）— 默认引擎 ​ internal/application/repository/retriever/postgres/repository.go 。数据与业务库同库（ embeddings 表，GORM 管理）。 向量检索 ：pgvector halfvec （半精度，2 字节/维）。 embedding 列不定维，HNSW 索引建在表达式 (embedding::halfvec(dim)) halfvec_cosine_ops 上—— ORDER BY 表达式必须与索引表达式完全一致 （两侧显式 cast），否则退化为顺序扫描（源码注释引 pgvector issue #702 / #835 ）。查询用子查询先取 expandedTopK （TopK*2，夹在 [100,200]，避免大 LIMIT 拖垮 HNSW）个候选算 distance = embedding <=> query ，再按 distance <= 1-threshold 过滤， score = 1 - distance 。事务内 SET LOCAL hnsw.ef_search （≥40）与 SET LOCAL hnsw.iterative_scan = strict_order （pgvector ≥ 0.8，选择性过滤下持续补召回），老版本 GUC 不存在时自动降级重试。 关键词检索 ： pg_search BM25—— content ||| query （任意 token 匹配）。首次关键词查询探测评分函数，优先使用 paradedb.score(anyelement) -> real ，兼容部分 PolarDB 实例的 pgsearch.score(anyelement) -> real ；仅缓存成功结果，探测失败可重试。缓存按检索仓库实例隔离，纯向量查询不触发探测。 兼容边界 ：评分函数适配不会安装扩展、创建包装函数或修改数据库结构；仍须预先具备兼容的 pg_search 、 ||| 操作符及有效 BM25 索引。不代表所有 PolarDB 版本均受支持；没有匹配评分函数时，关键词检索返回明确错误。 过滤 ： knowledge_base_id / knowledge_id / tag_id IN 过滤（AND 语义）， is_enabled 为 NULL 或 true。 建索引 ： BatchSave + ON CONFLICT DO NOTHING ；删除按 chunk/source/knowledge ID 物理删除。 SQLite（FTS5 + sqlite-vec）— 轻量单机 ​ internal/application/repository/retriever/sqlite/repository.go 。零外部依赖的全内嵌方案。 向量检索 ： sqlite-vec 扩展（cgo bindings）， 每个维度一张 vec0 虚表 ： CREATE VIRTUAL TABLE ... USING vec0(embedding float[dim] distance_metric=cosine) ；查询 WHERE v.embedding MATCH ? （序列化查询向量） ORDER BY v.distance ， score = 1 - distance 。启动时 ensureExistingVecTables 按已有数据维度补建虚表。 关键词检索 ：FTS5 contentless 表 lite_embeddings_fts ，写入时手动 bigram 分词 （对中文友好），查询经 sanitizeFTS5Query 同样 bigram 化后 MATCH 。 过滤 ：知识库、文档、标签和启停条件作用于 lite_embeddings 主表。向量路径使用 v.rowid IN (SELECT ... FROM lite_embeddings filtered WHERE ...) ，在 top-k 选择前完成过滤。若先取全局 top-k 再过滤，范围内的有效匹配可能无法召回； 错误传播 ：任一检索路径失败即返回错误，避免上层将失败误判为检索成功但无匹配； 阈值 ：向量阈值为 0 时视为不过滤，而不是把所有结果都滤掉。 适合桌面版 / 开发环境 / 极小规模部署。 Elasticsearch v8 ​ internal/application/repository/retriever/elasticsearch/v8/repository.go 。typed client，单索引（ ELASTICSEARCH_INDEX ，默认 WeKnora ），文档含 dense_vector embedding 字段。 向量检索 ： script_score 查询，脚本 Math.max(cosineSimilarity(params.query_vector, 'embedding'), 0.0) ，threshold 过滤在应用侧。Lucene 拒绝负的最终分数，未截断时只要有一个向量与查询方向相反，整个检索请求就会返回 400；截断到 0 后值域为 [0,1]，这类文档排在最后，也会被任何正阈值过滤掉。 关键词检索 ： match 查询 content 字段（BM25）。 过滤 ：bool filter（KB/knowledge/tag ID terms； is_enabled 用 must_not 反向匹配，历史无该字段的数据视为启用）；启动时探测 mapping 决定 ID 字段是否需要 .keyword 后缀。 建索引 ：Bulk API 批量写入，空向量拒绝。 Elasticsearch v7 — 仅关键词 ​ internal/application/repository/retriever/elasticsearch/v7/repository.go 。注意： Support() 只返回 [keywords] ——v7 驱动在 WeKnora 中仅作为 BM25 关键词引擎注册（代码中保留了 script_score cosineSimilarity 的向量查询构造，但能力声明不含 vector，Composite 不会把向量请求路由给它）。需向量检索时应搭配其他驱动（如 RETRIEVE_DRIVER=postgres,elasticsearch_v7 ）或升级 v8。 internal/application/repository/retriever/opensearch/ （多文件拆分： repository.go 、 retrieve.go 、 query.go 、 mapping.go 、 crud.go 等）。 版本门禁 probeVersion ：拒绝 ES 发行版与 OS 1.x / 2.0-2.3（Lucene HNSW 预览版）；2.4-2.10 警告接受；2.11+ / 3.x 干净接受（主测 3.3.2）。 probeKNNPlugin 要求所有节点装有 opensearch-knn 插件。 向量检索 ：k-NN 插件 knn 查询（ query.go buildKNNQuery ）；k-NN 的 COSINESIMIL space type 返回 (1+cosine)/2 。驱动把阈值换算成 min_score = (1+threshold)/2 下推，返回时再换回 cosine 相似度（ 2*score-1 ），与其他引擎同一尺度。 关键词检索 ： match content（BM25）。混合不走 OS 原生 hybrid pipeline，统一交给上层 RRF 融合（ query.go 注释明示）。 建索引 ： mapping.go 声明式 mapping（ knn_vector 字段带 method/engine 参数），启动时校验 mapping 指纹，漂移报 ErrConfigInvalid ；别名管理 + copy.go 支持 reindex；索引创建/重建事件经 AuditSink 写审计日志。

配置含 OPENSEARCH_INSECURE_SKIP_VERIFY 与 SSRF 安全传输层（ transport.go ）。 internal/application/repository/retriever/qdrant/repository.go 。gRPC 客户端（默认端口 6334）。 集合管理 ： 每维度一个 collection ： {QDRANT_COLLECTION|weknora_embeddings}_{dim} ，Distance=Cosine；payload 字段（kb_id/knowledge_id/chunk_id/tag_id 等）建 keyword 索引，content 建 多语言 tokenizer 的全文索引 。 向量检索 ： Query API，score 为归一化向量点积（≈cosine，IR embedding 下 [0,1]），threshold 由 score_threshold 下推。 关键词检索 ： tokenizeQuery 本地分词后对每个 token 构造 MatchText(content, token) 的 should（OR）过滤 ，用 Scroll 遍历所有匹配维度的 collection 取回；无 BM25 打分（命中即回，分数由上层 RRF 的 rank 决定）。 过滤 ： getBaseFilter 用 MatchKeywords 精确过滤 KB/knowledge/tag/is_enabled。 写入与删除 ：字符串 payload 中的非法 UTF-8 与 NUL 字符在写入前清理；删除时对应维度的 collection 尚不存在（首次写入前先删旧向量，或 Qdrant 被清空后）按"无可删"处理，不再阻断随后的写入；启停与标签批量更新逐 collection 执行，任一失败都会返回错误，而不是只记日志。 配置： QDRANT_HOST / QDRANT_PORT / QDRANT_API_KEY / QDRANT_USE_TLS 。 internal/application/repository/retriever/milvus/repository.go 。 集合管理 ：每维度一个 collection（ {MILVUS_COLLECTION|weknora_embeddings}_{dim} ）。schema 含稠密向量 embedding （HNSW 索引，M=16 efConstruction=128，metric 由 MILVUS_METRIC_TYPE 决定：IP 默认 / COSINE / L2）与稀疏向量 content_sparse —— 通过 内建 BM25 Function （ entity.FunctionTypeBM25 ）由 content 自动生成，配 AutoIndex(BM25) 。新建 Collection 的 content 使用 Milvus 多语言分析器：英文 english 、中文 chinese （内置 Jieba）、未知语言 default （ICU），并以 language 字段选择分析器。 向量检索 ： Search + WithANNSField(embedding) 。IP / COSINE 直接返回 cosine 相似度；L2 返回平方欧氏距离，驱动换算成 1 - d/2 ，阈值换算成搜索半径 2(1 - threshold) 。 关键词检索 ：对 content_sparse 做 BM25 稀疏向量检索（Milvus 2.5+ 原生全文检索），查询时根据问题文本的语言传入 analyzer_name 。返回 Milvus 给出的真实 BM25 分数；跨多个维度 collection 检索时先按分数合并排序，再截取 TopK。 过滤 ： filter.go 构造布尔表达式（kb/knowledge/tag/is_enabled）。 启停同步 ： BatchUpdateChunkEnabledStatus 逐 collection 更新，失败用 errors.Join 聚合后 返回错误 而不是只打 warn——主库里已停用的分块绝不能因为索引更新静默失败而继续可被检索到。 配置： MILVUS_ADDRESS / MILVUS_USERNAME / MILVUS_PASSWORD / MILVUS_DB_NAME / MILVUS_METRIC_TYPE （改后需重建 collection）。旧 Collection 的 schema 不能直接改成多语言分析器；可运行 go run ./cmd/milvus-migrate --source <旧前缀> --target <新前缀> 复用已有稠密向量并沿用源 Collection 的 metric，确认检索正常后把 MILVUS_COLLECTION 改为新前缀。 internal/application/repository/retriever/weaviate/repository.go 。HTTP + gRPC 双通道。 类管理 ：动态创建 Class（ WEAVIATE_COLLECTION 解析），支持 ReplicationConfig / ShardingConfig。 向量检索 ：GraphQL nearVector + certainty 阈值下推；certainty = (2-distance)/2 = (1+cos)/2 。驱动下推 (1+threshold)/2 ，返回时换回 cosine 相似度（ 2*certainty-1 ），与其他引擎同一尺度。 关键词检索 ：GraphQL BM25 查询（ Bm25ArgBuilder ）。 过滤 ：GraphQL where 过滤 KB/knowledge/tag/is_enabled。 配置： WEAVIATE_HOST / WEAVIATE_GRPC_ADDRESS / WEAVIATE_SCHEME / WEAVIATE_AUTH_ENABLED + WEAVIATE_API_KEY 。 Apache Doris（4.1+） ​ internal/application/repository/retriever/doris/ （ repository.go 699 行 + schema.go + structs.go ）。MySQL 协议连 FE（9030），HTTP（8030）走 Stream Load（SSRF 安全客户端）。 建表 ：每维度一张表（前缀 DORIS_TABLE_PREFIX|weknora_embeddings ）， schema.go 生成 DDL：ANN 索引 HNSW + inner_product （写入/查询前对向量单位化，等价 cosine）；content 列建 inverted 倒排索引并声明 chinese parser （无需应用侧分词）。DDL 后轮询 ANN 索引就绪。 兼容模式 DORIS_COMPAT_MODE ： auto （探测）/ inner_product_duplicate （DUPLICATE KEY 表 + inner_product_approximate ）/ legacy （ 1 - cosine_distance_approximate ）；建表后不可互换。 向量检索 ： inner_product_approximate(embedding, query) （单位化后即 cosine）或 legacy 公式，SQL LIMIT TopK。 关键词检索 ： content MATCH_ANY ? 走倒排索引。 写入 ：DUPLICATE KEY 表按 id 显式 delete + insert 保持替换语义；enabled/tag 更新经 Stream Load partial update。 配置： DORIS_ADDR / DORIS_HTTP_PORT / DORIS_DATABASE / DORIS_USERNAME / DORIS_PASSWORD / DORIS_TABLE_PREFIX / DORIS_COMPAT_MODE 。 internal/application/repository/retriever/tencentvectordb/repository.go 。RpcClient，EventualConsistency，10s 超时。 集合管理 ：每维度一个 collection（ {TENCENT_VECTORDB_COLLECTION|weknora_embeddings}_{dim} ），索引三件套：稠密向量 HNSW+COSINE（M=16, efConstruction=200）、 稀疏向量 SPARSE_INVERTED+IP （服务端 BM25）、标量 FILTER 索引（id 主键 + content/source/chunk/knowledge/kb/tag 过滤字段）。 向量检索 ：Search COSINE，SDK 值域 [-1,1]（IR embedding 实际 [0,1]）。 关键词检索 ：本地 encoder.SparseEncoder （BM25）把查询编码为稀疏向量，对 sparse_vector 字段做稀疏检索，遍历匹配维度的所有 collection。 配置： TENCENT_VECTORDB_ADDR / TENCENT_VECTORDB_USERNAME / TENCENT_VECTORDB_API_KEY / TENCENT_VECTORDB_DATABASE / TENCENT_VECTORDB_COLLECTION 。三项核心配置缺一则跳过注册。 Neo4j — 图谱检索（不在 Registry 体系内） ​ internal/application/repository/retriever/neo4j/repository.go 实现的是 RetrieveGraphRepository （ SearchNode(ctx, NameSpace, entities) ），不是向量/关键词引擎：按 NameSpace{KnowledgeBase, Knowledge} 检索实体节点与关系，服务于 chat pipeline 的 ENTITY_SEARCH 阶段（GraphRAG）。由 NEO4J_ENABLE=true + NEO4J_URI / NEO4J_USERNAME / NEO4J_PASSWORD 启用。单次查询最多从 200 个种子实体展开、最多返回 2000 行，详见 知识图谱 。 Embedding 维度管理 ​ WeKnora 允许不同 KB 使用不同 embedding 模型（维度各异），各引擎的维度隔离策略： 查询向量生成后会与模型配置的维度比对。不一致时（如模型服务更换了输出维度）直接返回错误码 2201，详情包含模型名、期望维度与实际维度，提示检查 Embedding 模型配置并重建索引；不会继续发往向量库后得到含糊的失败或空结果。 检索侧的一致性由 validateSameEmbeddingModel （ knowledgebase_search_shared.go ）保证：一次多库检索中的所有 KB 必须共享同一 embedding 模型身份（ model.Name + BaseURL ，跨租户可等价），否则拒绝——避免跨向量空间的分数不可比。查询向量按模型身份分组只计算一次（ ResolveEmbeddingModelKeys + GetQueryEmbedding ），随 params.QueryEmbedding 传播到所有 store 组，杜绝重复 embedding API 调用。 跨引擎向量分归一化（EngineAwareNormalizer） ​ 所有驱动返回的向量分都是 cosine 相似度 ，向量阈值也按 cosine 相似度解释；引擎原生尺度不同时由驱动自己换算： internal/application/service/retriever/normalizer.go 在多 store fan-out 且结果跨引擎类型时（ hasMixedEngineTypes ）再对向量分做一次 clamp01，兜住理论上的负 cosine 与 NaN/Inf；未知引擎同样 clamp01，并每请求打一次 WARN。 关键词（BM25）分数在这一步不归一化 ——其值域无上界，压缩会坍缩长尾；融合阶段再按各自列表处理（见下）。 clamp01 同时消化 NaN/Inf，保护下游排序的严格弱序不变量。 knowledgebase_search_fusion.go 。向量与关键词两路都有结果时： 每个 RetrieveResult （不同引擎、store 组、文档/FAQ 参数各是一个列表） 单独 按分数排名，chunk 取它在各列表中的最好名次。各列表按 goroutine 完成顺序拼接，拼接后的下标没有意义——否则后到列表的第 1 名会被当成第 N+1 名； 分数除以理论最大值，两路都排第一的 chunk 得 1，只在一路排第一的得该路权重占比（缺省 0.7 / 0.3）。未归一化的 RRF 最高约 0.016，与单路检索的 cosine（约 0.5–0.9）混排时会被整体压到后面，复合打分的基础分项和 MMR 的相关性项也失去作用； rrfK 、 vectorWeight 、 keywordWeight 来自租户 RetrievalConfig （ GetEffectiveRRFK / GetEffectiveRRFWeights 提供缺省）； 单路结果时不走 RRF， deduplicateByScore 保留每 chunk 最高分。只有向量结果时保持 cosine 相似度；只有关键词结果时，每个列表按自己的最高分折算到 [0,1]（不同引擎的 BM25 不可比），保持相对顺序，避免无上界的 BM25 分数让后续复合打分饱和。检索 trace 中仍记录原始 BM25 分数。 三条路径的输出都在 [0,1]，所以不同检索调用（按文档/标签的 target、不同 embedding 模型分组、FAQ 与文档调用）的结果可以放在一起排序。 融合之后的复合打分（rerank 模型分 0.6 + 检索基础分 0.3 + 来源权重 0.1、MMR、FAQ/Wiki 加权）发生在 chat pipeline 的 CHUNK_RERANK 阶段，见 检索问答流程的重排阶段 。 ParadeDB 存量库升级 ：保留数据卷、扩展 SQL 升级与恢复。 OpenSearch 本地联调 ​ 确认版本和 opensearch-knn 插件。默认端口为 9200，修改过 OPENSEARCH_PORT 时同步调整地址。此 profile 关闭安全插件，仅用于隔离的本地测试；可选 Dashboards 使用 --profile opensearch-ui up -d opensearch-dashboards 启动。 宿主机后端在 .env 中设置并重新启动： 也可通过管理界面/API 注册 engine_type: opensearch 的存储， connection_config.addr 使用该地址。容器内后端要使用可达的服务地址；生产连接另需 TLS、认证和按实际目标配置的 SSRF 规则。配置方式见 基础设施 API 。 单节点副本限制 ：当前驱动默认 1 个副本， index_config.number_of_replicas: 0 也会回退为 1（ opensearch/config.go 的零值处理）。因此不能用填写 0 来保证集群变为 Green。主分片正常、副本无法分配时可呈 Yellow；结合 /_cluster/health 和 /_cat/shards?v 检查具体原因，再验证实际读写。 创建测试知识库并绑定该存储，上传少量文档，等待解析完成后验证向量与关键词检索。检查 /_cat/indices?v 与 /_cat/aliases?v ，再验证修改、停用、重新启用和删除条目的检索结果；若测试知识库复制，还应检查目标库内容。索引按需创建，不应要求保存存储配置时就出现全部索引。 结束后仅停止本次使用的服务，保留开发数据：