向量数据库——移动 AI 搜图，分类的新助手

前言

在移动应用领域，图像搜索功能传统上受到移动设备计算能力的限制。计算图像之间的相似度------尤其是在大型图片集合中------一直是一个资源密集型过程，常导致性能瓶颈、电池消耗和用户体验下降。

本文探讨了PicQuery应用如何通过实现向量数据库方法来革新移动端图像搜索，替代传统的相似度计算。我们将研究这种方法的实际工程挑战、实现细节和性能优势。

移动端图像相似度计算的挑战

移动设备上的传统图像相似度计算方法通常包括：

成对比较：计算每对图像之间的相似度分数，导致O(n²)复杂度
内存处理：计算过程中在内存中保存大量嵌入向量
顺序处理：由于移动硬件限制导致并行化能力有限
批处理：在后台任务中执行计算，通常会有明显延迟

随着用户照片库的增长，这些方法变得越来越低效。对于仅1,000张图像的集合，可能需要近百万次比较才能识别相似照片，这在中低端手机上可能是灾难级别的。

向量数据库：移动端友好的解决方案

向量数据库通过提供高维向量的优化存储和检索，提供了一种引人注目的替代方案。在PicQuery的实现中，我们利用ObjectBox的向量数据库功能显著提高了搜索性能。

实现的关键组件

1. 使用HNSW索引的向量表示

我们实现的核心是 ObjectBoxEmbedding 模型：

kotlin 复制代码

@Entity
data class ObjectBoxEmbedding(
    @Id
    var id: Long = 0,

    @Index
    val photoId: Long,

    @Index
    val albumId: Long,

    @HnswIndex(
        dimensions = 512,
        distanceType = VectorDistanceType.COSINE
    )
    val data: FloatArray
) : Serializable

这里的关键注解是@HnswIndex，它为向量数据创建了层次导航小世界(HNSW)图索引。这种索引结构使得近似最近邻搜索的复杂度从线性扫描降低到对数级别。

2. 高效的向量搜索实现

搜索功能在ObjectBoxEmbeddingDao中实现：

kotlin 复制代码

fun searchNearestVectors(
    queryVector: FloatArray,
    topK: Int = 10,
    similarityThreshold: Float = 0.7f,
    albumIds: List<Long>? = null
): List<ObjectWithScore<ObjectBoxEmbedding>> {
    val query = embeddingBox
        .query()
        .nearestNeighbors(ObjectBoxEmbedding_.data, queryVector, topK)
        .build()

    val results = query.findWithScores().filter { result ->
        val cosineSimilarity = 1.0 - result.score
        cosineSimilarity > similarityThreshold
    }
    
    return results
}

这种实现利用了数据库内置的最近邻搜索功能，这些功能针对移动性能进行了优化。

工程挑战与解决方案

1. 嵌入向量生成与存储

主要挑战之一是高效地为潜在的数千张图像生成和存储嵌入向量。解决方案包括：

批处理：分批处理图像以避免内存问题
增量更新：只为新增或修改的图像生成嵌入向量
持久化存储：立即持久化嵌入向量以避免数据丢失

kotlin 复制代码

suspend fun saveBitmapsToEmbedding(
    items: List<PhotoBitmap?>,
    imageEncoder: ImageEncoder,
    embeddingRepository: EmbeddingRepository,
    embeddingObjectRepository: ObjectBoxEmbeddingRepository
) {
    coroutineScope {
        val embeddings = imageEncoder.encodeBatch(items.map { it!!.bitmap })
        embeddings.forEachIndexed { index, feat ->
            embeddingObjectRepository.update(
                ObjectBoxEmbedding(
                    photoId = items[index]!!.photo.id,
                    albumId = items[index]!!.photo.albumID,
                    data = feat
                )
            )
        }
    }
}

2. 针对不同用例的查询优化

不同的搜索场景需要不同的查询策略：

文本到图像搜索：将文本查询转换为嵌入向量
图像到图像搜索：直接使用图像的嵌入向量
特定相册搜索：将搜索限制在特定相册中

我们的实现通过灵活的查询参数适应这些场景：

kotlin 复制代码

private suspend fun searchWithVectorV2(
    range: List<Album>,
    textFeat: FloatArray
): MutableList<Pair<Long, Double>> = withContext(dispatcher) {
    val albumIds = if (range.isEmpty() || isSearchAll.value) {
        null
    } else {
        range.map { it.id }
    }

    val searchResults = objectBoxEmbeddingRepository.searchNearestVectors(
        queryVector = textFeat,
        topK = resultCount.value,
        similarityThreshold = matchThreshold.value,
        albumIds = albumIds
    )
    
    return@withContext searchResults.map { it.get().photoId to it.score }.toMutableList()
}

3. 基于相似度的照片分组

除了简单搜索外，pickQuery 还实现了基于相似度的照片分组：

kotlin 复制代码

private fun unionFindSimilarityGroups(
    photos: List<SimilarityNode>,
    similarityThreshold: Float = 0.95f
): List<List<SimilarityNode>> {
    val embeddings = embeddingRepository.getByPhotoIds(photos.map { it.photoId }.toLongArray())
    val unionFind = UnionFind(photos.size)

    for (i in photos.indices) {
        for (j in i + 1 until photos.size) {
            val similarity = calculateSimilarity(
                embeddings[i].data.toFloatArray(),
                embeddings[j].data.toFloatArray()
            )

            if (similarity >= similarityThreshold.toDouble()) {
                unionFind.union(i, j)
            }
        }
    }

    return unionFind.getGroups().map { group ->
        group.map { index ->
            photos[index]
        }
    }
}

这种方法使用并查集算法高效地对相似照片进行分组，时间复杂度大约为 O²，在初次加载的时候会比较消耗设备资源。

向量数据库的性能优势

向量数据库方法带来了几项显著的性能改进：

1. 搜索速度

传统的相似度搜索对于大型照片集合可能需要数秒甚至数分钟。使用向量数据库实现，搜索结果通常在毫秒级返回，提供近乎即时的用户体验。

2. 内存效率

通过将向量存储和搜索转移到数据库，应用程序的内存占用显著减少。这在内存限制严格的移动设备上尤为重要。

3. 电池消耗

优化的搜索算法减少了CPU使用率，降低了电池消耗------这是移动应用的关键因素。

4. 可扩展性

HNSW索引方法的扩展是对数级而非线性级，这意味着即使用户的照片集合增长到数万张图像，搜索性能仍然出色。

移动开发者的实施考虑

如果您考虑在移动应用中实施类似方法，以下是一些实用考虑因素：

1. 选择合适的向量数据库

虽然我们使用ObjectBox进行实现，但移动平台上有几种选择：

ObjectBox：轻量级，针对移动设备优化，内置向量搜索
带向量扩展的SQLite：更广泛可用但可能优化程度较低
自定义实现：可能提供更多控制但需要大量开发工作

2. 优化嵌入向量生成

生成嵌入向量计算成本高昂。考虑：

转移到后台服务
使用专为移动设备设计的轻量级模型
实施渐进增强（先生成低质量嵌入向量，然后改进）

3. 平衡精度和性能

更高维度的嵌入向量通常提供更好的相似度匹配，但消耗更多存储和处理能力。对于我们的实现，项目使用 clip 模型，他只有 512 一维向量在准确性和性能之间取得了良好平衡。

4. 实现缓存策略

即使使用高效的向量数据库，缓存频繁访问的结果也可以进一步提高性能：

kotlin 复制代码

private val _cachedSimilarityGroups = Collections.synchronizedList(mutableListOf<List<SimilarityNode>>())
private var isFullyLoaded = false
private val cacheLock = Any()

fun getSimilarityGroupByIndex(index: Int): List<SimilarityNode>? {
    synchronized(cacheLock) {
        if (!isFullyLoaded) return null

        return if (index in _cachedSimilarityGroups.indices) {
            _cachedSimilarityGroups[index]
        } else {
            null
        }
    }
}

结论

从传统相似度计算到向量数据库的转变代表了移动图像搜索技术的重大进步。通过利用优化的数据结构和搜索算法，PicQuery证明了复杂的图像搜索功能可以在移动设备上高效实现。

这种方法不仅改善了性能指标，还实现了以前在移动平台上不切实际的全新用户体验。随着向量数据库技术的不断成熟，我们可以期待移动领域出现更多创新应用。

对于开发图像密集型移动应用的开发者来说，向量数据库为相似度搜索的长期挑战提供了一个引人注目的解决方案。本文分享的实际实现细节为将这些技术集成到您自己的应用中提供了起点，有可能彻底改变用户在移动设备上与视觉内容的交互方式。