Реализация векторного поиска для AI-базы знаний в мобильном приложении
Векторный поиск находит семантически похожие документы, а не просто совпадения по ключевым словам. Запрос «как восстановить доступ» найдёт статью «сброс пароля», даже если слово «восстановить» в ней не встречается. Это основа любого AI-поиска по базе знаний.
Как работает на уровне кода
Каждый текстовый фрагмент превращается в вектор — массив чисел (1536 или 3072 значений для OpenAI, 768 для локальных моделей). Семантически похожие тексты дают близкие векторы. Поиск — это нахождение ближайших векторов к запросу (Approximate Nearest Neighbor, ANN).
На практике для мобильного приложения это означает:
- Пользователь вводит запрос
- Клиент отправляет запрос на бэкенд
- Бэкенд создаёт эмбеддинг запроса через API (OpenAI, Cohere) или локальную модель
- Векторная БД возвращает топ-K ближайших чанков
- Результаты передаются в LLM или возвращаются напрямую
Весь pipeline до шага 4 занимает 50–300 мс — вполне приемлемо для mobile UX.
Векторные индексы: что выбрать
pgvector — расширение для PostgreSQL. Если у вас уже PostgreSQL, это нулевая дополнительная инфраструктура. Поддерживает HNSW и IVFFlat индексы.
-- HNSW-индекс для быстрого ANN-поиска
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Поиск топ-5 ближайших
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;
<=> — cosine distance в pgvector. Для нормализованных векторов cosine distance эквивалента inner product (<#>), но <=> работает без нормализации.
Выбор индекса:
- IVFFlat — быстро создаётся, меньше памяти, чуть менее точный
- HNSW — лучшая точность, быстрый поиск, больше памяти при построении
Для базы до 1 млн документов pgvector с HNSW справляется без проблем. При 10+ млн — рассматривайте Pinecone, Weaviate, Qdrant.
Фильтрация по метаданным
Векторный поиск без фильтров ищет по всему индексу. Если нужно искать только по документам конкретного продукта, отдела или языка — добавляйте фильтрацию.
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
WHERE
language = 'ru'
AND category = 'installation'
AND updated_at > NOW() - INTERVAL '1 year'
ORDER BY embedding <=> $1
LIMIT 10;
Важно: pgvector выполняет фильтр ПОСЛЕ векторного поиска при использовании HNSW/IVFFlat. Для высокоселективных фильтров (отбирают < 10% строк) это приводит к плохим результатам — нужно либо строить отдельные индексы для каждого подмножества, либо использовать partitioned HNSW.
Эмбеддинги на клиенте vs на сервере
Генерировать эмбеддинг запроса можно на клиенте (локальная ML-модель) или на сервере. Для мобильного приложения серверный вариант предпочтительнее: модели эмбеддингов весят 80–500 МБ, локальный вывод требует ресурсов, а API-ключ не торчит из APK.
Исключение — полностью офлайн-сценарий. Тогда используем Core ML на iOS (конвертация модели через coremltools) или ONNX Runtime на Android. Пример: all-MiniLM-L6-v2 в ONNX весит ~22 МБ и выдаёт 384-мерные векторы достаточного качества для поиска по корпоративной документации.
Отображение результатов поиска на мобильном
Каждый результат содержит: отрывок текста, название документа/раздела, score схожести, дату обновления. На мобильном отображаем:
- Score как визуальный индикатор релевантности (три точки/бар, не число — число ничего не говорит пользователю)
- Хлебные крошки источника: «Руководство пользователя → Установка → iOS»
- Подсветка совпадающих слов (даже при семантическом поиске — слова всё равно часто пересекаются)
- Кнопка «Открыть полный документ»
Этапы и сроки
Инвентаризация и нормализация базы знаний → выбор модели эмбеддингов → настройка векторной БД и индексов → разработка ingestion pipeline → поисковый API с фильтрацией → мобильный UI поиска с результатами → тестирование качества (precision@K, recall@K) → итерация.
Векторный поиск по корпусу до 50 тысяч документов с pgvector — 2–4 недели. С кастомной моделью эмбеддингов, reranking и мультиязычностью — 5–8 недель.