有没有人把向量数据库用在RAG以外的场景？感觉有点大材小用了

图片去重这块我试过，感知哈希对旋转和裁剪过的图基本就废了，向量特征至少能扛住轻微变换，做头像查重比传统方案稳多了。日志异常检测也有人拿向量DB聚类相似堆栈，但问题是要先把日志embedding化，这块的模型调起来比RAG更费劲。其实我觉得向量DB最适合的场景反而是推荐系统里的相似内容召回，比协同过滤好解释，也够快，不过这块资料确实少，可能都藏着当核心竞争力了。

图片去重这个场景还真能用，但别指望它比pHash快，向量检索胜在能捕捉语义相似度，比如两张不同角度但同一只猫的头像，pHash就挂了。我之前拿CLIP抽特征灌进Milvus做商品图去重，召回率确实高，但延迟比pHash高一个量级，得看业务能不能忍。日志异常那块也有人搞过，本质就是用embedding做聚类，不过数据量不大的话Faiss甚至sklearn就够，不一定非上向量DB。

图片去重我试过，向量比pHash准多了，尤其裁剪压缩后。日志聚类也有人在用，效果还行。

图片去重确实能用向量库，但得配合好的embedding模型，感知哈希快多了。日志聚类我试过，效果还行，就是得先调好异常阈值。

这个思路不错，收藏了。

有没有更详细的教程推荐？

头像去重那个思路没毛病，感知哈希对裁剪、加水印这种变体容易翻车，换成embedding余弦相似度确实稳不少，阈值调好了误判率低很多。日志异常检测也有人搞过，把错误日志embedding后聚类，新来的日志算距离找最近邻，比正则匹配灵活多了。不过说实话向量库在这些场景里就是个带索引的近似最近邻检索器，别被RAG那套叙事框住，GPU该用就用。

头像去重那个思路没问题，感知哈希对裁剪、加水印这种变换其实挺脆的，换成CLIP或者DINOv2提embedding再走向量检索，召回率和鲁棒性都会好不少，Milvus里建个HNSW索引几百万级头像完全扛得住。日志异常检测也有人这么干，把错误日志模板化之后embedding聚类，新来的日志算距离找最近邻，比规则匹配灵活，但坑在于日志分布漂移快，索引得频繁重建，不然邻居全是过时的。我自己的经验是向量库最被低估的其实是“模糊匹配”类需求，比如商品标题归一化、地址去重、用户行为序列相似召回，这些跟LLM一点关系没有。GPU白买不至于，embedding模型推理才是吃卡大头，向量库本身查起来很轻。倒是提醒一句，图片去重别只卡一个阈值，最好加一层精排或者人工复核，不然误杀用户头像挺尴尬的。