◈ DB 选型参考

AI选型

不替你做决定，也不假装智能：选一个提示词模板，场景已按通用推荐值预填好，一键跳转到你自己的 ChatGPT、Grok 或 Claude 账号里生成对比。

用法

1

选一个提示词模板

上面可以直接多库 PK（2-4 款）；下面 12 个模板分三组：通用选型 4 个、OLAP 选型 5 个、AI 数据库选型 3 个。顶栏的「对比」托盘选好库后，提示词里的候选库会自动填入已选产品。

2

场景已预填，可直接用

每个模板的场景都已按通用推荐值填好：不改可直接点按钮出结果；按你的实际情况改一改，结果会更准；删掉某一行，AI 会针对该项向你提问。

3

一键跳转外部 AI

点 ChatGPT / Grok / Claude，提示词会自动填入新对话的输入框；若未自动填入，用"复制提示词"按钮手动粘贴。

为什么这样更中立？推理发生在你自己的 AI 账号里：本站不经手你的业务信息，也不替你预设答案。每份模板都写死了几条纪律——结论标注证据等级、严格区分"查证为无"与"未找到证据"、不做综合总分与排名；信息不足时不许编造，必须先交互式逐题提问（一次只问一个问题，每题给出带字母编号的选项，你只需回复字母即可作答），而且不同模板问的方向不一样（去 O 问 Oracle 强依赖、向量库问召回率与延迟、诊断类先问诊再下结论）；候选库横跨不同领域时不许硬对比，先确认你的真实诉求。但请注意：AI 的回答仍需对照本站档案交叉验证，模型也会一本正经地编造。
多库 PK 通用选型 OLAP 选型 AI 数据库选型

多库 PK

选 2-4 款数据库，一键生成多库对比提示词，直接发给 AI。顶部选了对比库后，这里会自动使用已选库（下拉框会被禁用）；没选时用下面的下拉框，默认已选中 OceanBase 和 TiDB。

VS

通用选型

覆盖 OLTP 与通用场景的选型：多候选库全面对比、去 O 迁移、读扩展架构、KV 与文档库。

通用选型对比

适用：第一次选型，或在 2-4 个候选库之间做一次全面对比。

你是一名中立的数据库架构顾问，不代表任何厂商。请基于公开资料，帮我做一次数据库选型对比。

【我的业务场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 业务类型与读写特征：电商下单，读写比约 7:3，写操作以事务型订单创建为主
- 数据规模与增速：当前 2TB，年增约 50%
- 峰值负载：写 2 万 TPS，读 20 万 QPS
- 团队规模与运维能力：3 名 DBA，可接受自建
- 部署环境：公有云（华东地域为主），满足国内合规要求
- 预算约束：license 成本敏感，人力成本同样敏感
- 否决项：必须支持同城多可用区高可用；等保三级为加分项而非硬性要求
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【候选数据库】{{CANDIDATES}}

【输出要求】
1. 按这 47 个维度逐项对比：静态加密 / TDE、TLS / 传输加密、审计、认证与权限、备份恢复、可观测性、连接模型、事务与隔离级别、复制与一致性、扩展方式、兼容性、许可证与商业模式、中文资料丰富度、性能与延迟特征、合规与认证、成熟度与社区生态、标杆用户、生态工具链、云托管与 Serverless、数据接入与摄入、外部数据访问、CDC 与下游同步、TTL 与数据生命周期管理、在线 DDL 与 Schema 演进、多租户与资源隔离、跨地域多活、高可用架构与 RTO/RPO、行级安全与数据脱敏、JSON 与半结构化能力、全文检索能力、存储效率与压缩、开源协议与厂商锁定风险、查询优化器与计划稳定性、参数调优与自治能力、静默数据损坏防护、存储过程/触发器/过程语言、约束与数据完整性、分析 SQL 完备性、被遗忘权与数据擦除、数据血缘与目录集成、存算分离 vs 存算一体、多模能力、FinOps 成本可观测性、驱动与多语言生态、物化视图、支持跨云、热点数据更新能力。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证。严格区分"查证为无"和"未找到证据"，不要把没查到的写成不支持。
3. 每款候选库给出：最适合的场景、最可能踩的三个坑（从机制层面解释，并说明在什么负载或故障下会触发）。
4. 不做综合总分、不排名，只给带条件的判断，格式为"如果……那么……"。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：业务类型与读写特征、数据规模与年增速、峰值负载形态（QPS/并发/热点）、团队运维能力与值班体系、部署环境与合规要求、预算范围与一票否决项），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。
6. 用中文回答。

去 O 迁移评估

适用：从 Oracle 迁出，评估目标库的真实兼容代价与迁移风险。

你是一名中立的数据库架构顾问。请帮我评估"去 O"迁移（从 Oracle 迁出）的可行性与真实成本。

【现状】（以下已按典型去 O 场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- Oracle 版本与部署：19c，两节点 RAC
- 强依赖特性：PL/SQL 存储过程包、分区表、DBLINK（计划逐步下线）
- 数据量与停机窗口：5TB，要求停机小于 4 小时
- 性能基线：核心交易峰值 8000 TPS，慢查询主要集中在报表类 SQL
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【候选目标库】{{CANDIDATES}}

【输出要求】
1. 兼容性逐项核对：区分"语法能跑"和"语义等价"，这是两回事，必须分开写。每项标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证。
2. 迁移风险清单，按三档输出：一定会改的代码、可能要改的代码、必须做 POC 才能确认的项。
3. 给出数据校验策略（全量加增量对账思路）与回滚方案要点。
4. 不做综合评分。仅在用户删掉【现状】中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：Oracle 版本与部署形态（单机/RAC/ADG）、强依赖特性清单（PL/SQL、DBLINK、分区、物化视图、AQ、VPD/OLS）、数据总量与停机窗口、性能基线关键指标、回退预案要求），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

读扩展架构选型

适用：一写多读架构，读压力大，需要搞清复制延迟与代理行为的真实边界。

你是一名中立的数据库架构顾问。请帮我设计"一写多读"的读扩展架构，并对比候选方案。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 写负载：主库峰值写 1 万 TPS，写放大不明显
- 读负载：读 30 万 QPS，读写比约 30:1
- 一致性要求：核心读可接受 1 秒内旧数据；分布式事务非刚需
- 可用性要求：主库故障时 RTO 小于 5 分钟，RPO 接近 0
- 候选方案：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 对比各方案的：复制延迟的真实量级与放大的条件、代理或中间件在故障与事务中的行为（连接闪断、事务粘性）、只读节点的成本构成、写天花板在哪里。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 给出 2-3 种架构组合建议，说明各自的取舍与翻车点，不做综合评分和排名。
4. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：写负载与峰值写入量、读/写比例、读一致性容忍度（能否接受秒级延迟）、RTO/RPO 目标、现有代理/中间件与连接池形态），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

KV / 文档库选型

适用：在 Redis、MongoDB、DynamoDB、Cassandra 等之间按访问模式选型。

你是一名中立的数据库架构顾问。请帮我做 KV / 文档数据库选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 访问模式：高频点查为主，辅以计数器和会话存储
- 数据结构：以简单 KV 和哈希为主，少量 JSON 文档
- 规模与性能：key 量级 10 亿，峰值 50 万 QPS，P99 延迟要求 5ms
- 一致性与持久化：宕机可接受秒级数据丢失；不需要多副本强一致
- 运维方式：倾向云托管，Serverless 可接受
- 候选库：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按访问模式逐项对比候选库的匹配度，指出"能用但别扭"的地方。
2. 重点对比：持久化与故障恢复的真实行为、大 key 与热 key 下的表现、集群扩缩容时的数据搬迁代价、托管服务的计费边界。
3. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证。
4. 只给带条件的判断，不做综合评分与排名；仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：访问模式（点查/范围扫描/聚合占比）、一致性与事务需求（单文档原子 vs 多文档事务）、数据模型偏好（文档/KV/宽列）、运维偏好（托管 vs 自建）），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析。用中文回答。

OLAP 选型

OLAP 不是一种数据库，而是一类负载；选型前先对号入座。下面按业务形态分成五个子领域：离线数仓（T+1 批量）、实时数仓（秒级~分钟级）、交互式 BI 与即席查询（亚秒、高并发）、湖仓一体（开放格式、存算分离）、嵌入式分析（单机零运维）。同一款产品在不同子领域里可能是神器也可能是灾难——先选子领域，再选产品。

离线数据仓库

适用：T+1 或小时级批量 ETL，大扫描聚合为主的离线分析。

你是一名中立的数据架构顾问。请帮我做离线数据仓库（OLAP 批处理）选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 数据规模与增量：总量 200TB，日增 2TB
- ETL 窗口：每天凌晨 4 小时内必须跑完
- 查询特征：大表扫描聚合为主，偶发多表 JOIN；并发查询数约 20
- 数据更新需求：需要按天 UPDATE/DELETE 修正数据，每日一次
- 团队与运维：数据团队 8 人，可接受自建与调优
- 部署与成本：公有云；计算成本比存储更敏感
- 候选：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按这些维度逐项对比：写入吞吐与 ETL 友好度、列存压缩与向量化扫描性能、大 JOIN 与复杂 SQL 能力、并发查询能力、数据更新与删除机制、运维复杂度（扩缩容、版本升级）、弹性扩展与存算分离、成本模型（存储与计算的计费边界）。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每款候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释，如后台合并的写入放大、物化视图的刷新代价，并说明触发条件）。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：数据规模与年增速、ETL/调度现状与 T+1 时效要求、查询复杂度（宽表关联层数）与并发数、SQL 方言依赖（Hive/Spark SQL 等）），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

实时数仓

适用：秒级~分钟级延迟，流式写入、实时大屏、高并发查询。

你是一名中立的数据架构顾问。请帮我做实时数仓选型（秒级~分钟级延迟）。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 数据源与写入：Kafka，峰值每秒写入 50 万条
- 端到端延迟 SLA：95% 的数据 1 分钟内可查
- 查询模式：实时大屏聚合为主，辅以高并发点查和明细下钻
- 语义要求：需要精确去重，exactly-once 非强需求
- 运维与成本约束：运维人力 2-3 人，倾向云托管，成本敏感
- 候选：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按这些维度逐项对比：流式写入吞吐与延迟、去重与 exactly-once 语义的实现代价、实时 JOIN 能力、高并发查询下的稳定性、预聚合与物化视图、扩缩容与版本升级的运维成本、故障恢复（副本重建速度）。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每款候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释，如写入放大的触发条件、副本同步延迟的放大路径）。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：实时性要求（秒级/分钟级）、写入吞吐（每秒行数）与数据源、查询并发与复杂度、exactly-once 语义要求），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

交互式 BI 与即席查询

适用：分析师即席查询、BI 报表，要求亚秒响应、高并发。

你是一名中立的数据架构顾问。请帮我做交互式 BI 与即席查询引擎选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 用户规模与并发：200 名分析师，峰值并发查询 100
- 延迟要求：P95 在 2 秒内返回
- 数据量级与查询复杂度：多维下钻为主，每日约 30% 的查询会钻取明细
- BI 工具：Superset 为主，少量 Tableau
- 权限需求：需要行级权限，列级权限暂不需要
- 候选：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按这些维度逐项对比：亚秒查询能力、高并发下的排队与资源隔离、BI 工具兼容性（SQL 方言、连接协议）、语义层与行列级权限、查询加速手段（缓存、预聚合）、运维复杂度与成本模型。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每款候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释，如高并发下查询排队的触发条件、BI 生成 SQL 的方言坑）。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：并发用户/查询数、查询模式（固定报表 vs 即席探索占比）、数据新鲜度要求、现有 BI 工具），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

湖仓一体

适用：已有数据湖，想统一批流、开放表格式、存算分离。

你是一名中立的数据架构顾问。请帮我做湖仓一体架构选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 数据湖现状：对象存储，总量约 300TB
- 表格式倾向：尚未确定，倾向 Iceberg
- 计算引擎：Spark 跑批处理，Trino 跑即席查询
- 事务需求：需要 ACID 与 schema evolution，time travel 为加分项
- 流批一体需求：希望同一份数据同时服务离线与实时，但可分阶段落地
- 候选组合：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按这些维度逐项对比：表格式能力（ACID、schema evolution、分区演进、time travel）、引擎生态与兼容性、元数据服务（catalog）选型、小文件问题与 compaction 代价、存算分离下的真实成本、流批一体的成熟度（区分"能跑"和"生产可用"）。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每组候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释，如小文件放大的触发条件、compaction 的资源争抢）。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：现有湖存储与表格式（Iceberg/Hudi/Delta）、批流一体需求、数据治理与权限要求、对存算分离运维的接受度），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

嵌入式与单机分析

适用：笔记本/单机/边缘的零运维分析，数据量 GB 到数 TB。

你是一名中立的数据架构顾问。请帮我做嵌入式与单机 OLAP 选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 运行环境：单机服务器（64 核 / 256GB 内存）
- 数据量级：几百 GB，未来 2 年可能到 2TB
- 语言生态：Python/Arrow 为刚需
- 写入特征：单并发批量写入，每日一次
- 运维要求：要求零运维，嵌入应用分发
- 候选：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按这些维度逐项对比：单机扫描性能天花板、内存管理与溢出行为、Python/Arrow 生态集成度、并发写入限制、文件格式与外部数据互操作、从单机扩展到集群的迁移路径。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每款候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释），以及"出现什么信号就必须换成集群架构"的判断线。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：数据规模上限、部署形态（嵌入进程/单机服务/桌面应用）、查询语言偏好（SQL/Python）、与现有系统的集成方式），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

AI 数据库选型

AI 数据库是一个衍生新领域，不等于给老数据库贴 AI 标签：它有自己独立的评价维度——向量索引算法与召回率、标量过滤加向量混合检索、十亿级扩展、embedding 流水线。下面三个模板分别覆盖：RAG 场景的向量库选型、专用向量库 vs 通用库 AI 扩展（如 PG、OceanBase、ES 的向量能力）的取舍线、混合检索与召回质量的深水区诊断。

RAG 向量库选型

适用：RAG 知识库，在专用向量库与通用库 AI 扩展之间做选择。

你是一名中立的 AI 基础设施顾问。请帮我做 RAG 场景的向量数据库选型。

【我的场景】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 向量规模：5000 万条，维度 1024
- embedding 模型：bge-m3，已固定
- 查询负载：峰值 2000 QPS，P99 延迟要求 100ms
- 过滤需求：需要标量过滤（按租户、时间、标签过滤后再做向量检索）
- 数据更新：每日新增约 1%，删除量小
- 部署方式：倾向云托管
- 候选：{{CANDIDATES}}
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 按 AI 数据库自己的维度对比（不要套用 OLTP 的维度）：向量索引算法（HNSW/IVF/DiskANN）与召回率-延迟权衡、标量过滤加向量混合检索（注意 pre-filtering 与 post-filtering 的正确性陷阱）、十亿级扩展（分片与分布式）、实时写入与删除的代价、embedding 流水线（切分与向量化谁来做、模型集成方式）、与现有技术栈的协同、成本模型。
2. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
3. 每款候选给出：甜蜜点、最可能踩的三个坑（从机制层面解释，如 HNSW 参数调优空间、过滤导致召回率塌陷的条件）。
4. 不做综合总分、不排名，只给"如果……那么……"的条件判断。
5. 仅在用户删掉场景中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：向量规模与维度、召回率硬要求、标量过滤+向量混合检索需求、数据更新频率、P99 延迟要求），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

专用向量库 vs 通用库 AI 扩展

适用：已有 PG/OceanBase/ES，想判断要不要引入专用向量库。

你是一名中立的 AI 基础设施顾问。请帮我判断：RAG 场景下，继续用现有通用数据库的 AI 扩展，还是引入专用向量数据库？

【我的现状】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 现有数据库：{{CANDIDATES}}
- 向量规模与增长预期：当前 2000 万条，维度 1024，未来一年预计增长到 1 亿
- 当前痛点：召回率不达标（Top10 召回率约 85%），过滤查询写起来别扭
- 团队对引入新组件的接受度：可以接受，但希望运维负担可控
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 对比通用库 AI 扩展与专用向量库（Milvus、Qdrant、Weaviate）在五个方面的差异：索引算法丰富度、规模天花板、混合检索能力、运维负担、生态集成。
2. 给出明确的取舍线：什么规模与什么信号出现之前，通用库的 AI 扩展够用；出现哪些信号，就必须迁到专用向量库。
3. 如果建议迁移，给出迁移代价评估（数据迁移、双写、回滚方案）。
4. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；严格区分"查证为无"与"未找到证据"。
5. 不做综合总分、不排名；仅在用户删掉【我的现状】中的某一行或标注"未知"导致信息不足以下结论时，才主动向我提问：用交互式选择题逐题提问（提问时优先覆盖：现有数据库与已用 AI 扩展、RAG 规模预期（向量数/增速）、团队学习意愿、是否接受多一套运维体系），一次只问一个关键问题，每个问题给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一题；不要一次把所有问题都列出来。所有关键问题问完后，再开始分析，不要编造。用中文回答。

混合检索与召回质量

适用：RAG 检索质量不达标，需要深水区诊断与调优。

你是一名中立的 AI 基础设施顾问，专长检索质量调优。我的 RAG 检索质量不达标，请帮我做混合检索与召回质量的深水区诊断。

【我的现状】（以下已按通用推荐场景填好：不改可直接用，按你的实际情况修改会更准；删掉某一行或标注"未知"，AI 会针对该项向你提问确认）
- 当前方案：单一向量检索
- 症状：召回率低（Top10 召回率约 80%），相关文档排不上
- 数据特征：中英文混合，长文档，结构化字段多（租户、时间、标签）
（说明：将以上默认场景视为我已确认的场景，直接开始分析；仅对我删掉或标注"未知"的行再提问。）

【输出要求】
1. 给出诊断框架：先判断是 embedding 模型问题、索引参数问题、切分策略问题，还是过滤写法问题，并说明每种的判别方法。
2. 对比混合检索策略：多路召回（向量加全文加稀疏）与结果融合（RRF 这类方法）、重排（rerank）模型的取舍与代价。
3. 给出离线评测方法：如何构建评测集、用什么指标（召回率、MRR、nDCG）验证优化真的有效。
4. 说明 GraphRAG 这类方案在什么条件下值得上、什么条件下是过度设计。
5. 每个关键结论标注证据等级：官方文档、厂商口径、社区实测、社区共识、待验证；不确定的明确说不知道，不要编造。
6. 若用户删掉【我的现状】中的行或标注"未知"，像医生问诊一样先向我提问：交互式逐题进行，一次只问一个关键症状，每个症状给出 3-4 个带字母编号的选项（A/B/C/D，外加 E. 其他，请说明），我只需回复字母即可作答；等我回答后再问下一个，所有关键症状问完后，再开始诊断。不要一次把所有问题都列出来，也不要编造。问诊时优先覆盖：召回不达标的具体症状（查全/查准/排序哪个环节）、向量规模与索引类型、标量过滤复杂度、查询模式（TopK 取值）、已尝试过的优化手段。用中文回答。

本站内置 AI 功能

直接在本站内对话的 AI 顾问仍在规划中（当前状态：待接入）。它必须满足：真实大模型调用、每条建议引用本站档案并原样携带证据等级、不确定就明说不知道、不替你做决定、回答可审计。在那之前，请用上面的模板与你自己的 AI 账号完成选型分析。