Doris、StarRocks 的向量检索能力能替代专用向量库吗？
面试怎么回答
Doris、StarRocks 做向量检索的优势是少一套系统、复用运维权限，向量和结构化数据在一起，一条 SQL 就能做相似度检索加过滤加关联，特别适合相似商品分析、相似人群圈选这类向量加分析的需求。不足要按版本具体验证：高并发低延迟的在线检索不是 OLAP 的强项，索引类型和过滤效率、频繁更新的维护代价、上亿规模的表现、功能成熟度都要看。决定时先明确规模、QPS、延迟、过滤和更新频率，用自己的数据压测召回、P99、写入延迟以及对其他分析查询的影响，共用集群要做资源隔离。一般规模中等、并发不高、和结构化数据结合紧的用 OLAP 引擎，大规模高并发的在线 RAG 用专用向量库，也可以混合使用。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Doris、StarRocks 这些 OLAP 引擎的新版本陆续加入了向量索引和向量检索函数。团队已经有一套 Doris 集群，有人提议：「直接用 Doris 做 RAG 的向量检索，不用再引入向量数据库了。」面试官问这题，想看你怎么评估「在现有系统上加能力」和「引入专门系统」的取舍。
OLAP 引擎做向量检索的优势
- 少一套系统：运维、权限、监控、数据同步都复用现有的；
- 向量和结构化数据在一起：一条 SQL 里既能做向量相似度检索，又能按租户、时间、类别过滤，还能和业务表关联；
- 适合分析型的向量使用：比如找出和某个商品最相似的商品再做销量分析、用户画像向量的相似人群圈选，这类「向量 + 分析」的需求，OLAP 引擎反而更合适；
- 团队熟悉：SQL 接口，学习成本低。
可能的不足
需要结合你用的版本具体验证：
- 在线检索的延迟和并发：OLAP 引擎为分析查询设计，高并发低延迟的点查不是它最擅长的，RAG 在线检索的 QPS 和 P99 要实测；
- 索引能力：支持的索引类型、参数调优、量化、过滤和向量检索结合的效率；
- 实时写入和更新：频繁更新删除时索引的维护代价、写入后多久可检索；
- 规模：上亿向量时的内存和性能表现；
- 功能成熟度：作为较新的功能，稳定性和生态（和 RAG 框架的集成）还在发展。
怎么决定
- 明确需求：向量规模、在线检索的 QPS 和延迟要求、过滤条件、更新频率；
- 用自己的数据压测：召回率、P99 延迟、带过滤的性能、写入延迟，同时观察对集群上其他分析查询的影响；
- 资源隔离：如果和分析查询共用集群，在线检索可能被大查询拖慢，需要资源组隔离甚至单独的集群；
- 混合方案：分析型的向量需求放在 OLAP 引擎，高并发的在线 RAG 检索放在专用向量库。
一般的结论
- 规模中等、并发不高、和结构化数据结合紧密的场景：用现有的 OLAP 引擎是很好的选择；
- 大规模、高并发、低延迟的在线检索：专用向量库更稳妥；
- 不要因为「少一套系统」而忽略压测，也不要因为「专业」而过早引入新系统。