Qdrant把向量数据库门槛砍到0：3分钟跑通语义搜索

去年一个做电商推荐的朋友跟我吐槽，说他们团队为了上线"相似商品推荐"，光买向量数据库的云服务就烧了2万多，结果QPS（每秒查询数）上来就卡死。我让他试试本地部署开源方案，他回了一句："Rust写的？我们没人会啊。"

现在Qdrant直接甩出来一个免费API层，Docker一行命令拉起，REST和gRPC双协议支持。换句话说，你不需要懂Rust，不需要调集群，甚至不需要写SQL——JSON拍过去就能查。

384维向量：为什么是这个数字？

Qdrant默认的向量维度是384，这不是拍脑袋定的。目前主流的小型嵌入模型（embedding model），比如sentence-transformers的all-MiniLM-L6-v2，输出维度正好是384。用Cosine（余弦相似度）作为距离度量，意味着它默认帮你做好了语义相似度的数学基础。

创建集合的代码很直白：PUT请求到/collections/products，body里指定向量大小和距离算法。没有schema迁移，没有索引重建的噩梦。对比某些需要提前定义字段类型的方案，这更像是在说"你先存，后面再管"。

payload（载荷）机制是Qdrant被低估的设计。它允许你在向量旁边直接塞结构化数据——价格、分类、库存状态。查询时可以同时做向量相似度排序和精确过滤，比如"找和'降噪耳机'语义相近、但价格不超过100美元的商品"。这在传统数据库里需要两趟查询，在这里一趟搞定。

推荐系统的隐藏API：正负样本都喂进去

语义搜索是向量数据库的基操，但Qdrant的recommend接口有点意思。它接受positive（用户喜欢的商品ID）和negative（不喜欢的ID）两组参数，自动学习用户的偏好向量。这比协同过滤轻量，比纯内容推荐精准，而且实时生效——不需要离线训练模型。

代码里的例子很典型：用户喜欢ID 1和5，讨厌ID 3，系统在audio分类里召回10个结果。这套机制可以直接用在"猜你喜欢"或者个性化排序，不需要额外搭一套推荐引擎。

过滤语法支持must、should、must_not三种布尔组合，嵌套层级没有硬性限制。对于做过Elasticsearch的人来说，这语法很眼熟，但向量搜索的延迟是毫秒级，不是秒级。

Rust写的，但开发者不用碰Rust

官方强调"Written in Rust, optimized for billion-scale"，但整个使用过程你只会接触到JavaScript/Python客户端和REST接口。Rust在这里是性能背书，不是学习门槛。单机版号称能扛十亿级向量，对于90%的AI应用来说，这天花板够高了。

gRPC接口的存在是为了高频场景。如果你在做实时推荐或者流式搜索，REST的JSON序列化会成为瓶颈，切到gRPC能省掉不少CPU。但大部分场景下，REST够用了——curl就能调试，Postman就能测试。

免费版的功能边界很清晰：单机部署、社区支持、核心功能全开放。付费的云托管版主要是省掉运维和扩容的麻烦。对于想验证AI搜索原型的团队，这个免费层足够跑完MVP（最小可行产品）。

有个细节值得注意：Qdrant的scroll接口支持分页遍历全量数据，这在需要批量导出或者离线分析时很实用。很多向量数据库只优化了近似搜索，全表扫描是性能黑洞，但Qdrant把这个场景也考虑进去了。

现在回到开头那个朋友的问题。如果他当时知道这套方案，2万块够他雇一个实习生跑三个月的A/B测试。向量数据库的选型从来不只是技术问题，更是成本结构的问题——尤其是在AI应用还没找到PMF（产品市场契合点）的早期阶段。

你现在的语义搜索方案，部署到生产环境花了多少行配置？