В мобильной разработке нередко возникает ситуация: пользователь вводит запрос "как восстановить доступ", а система возвращает пустой экран. Обычный поиск по подстроке не справляется с синонимами, опечатками и разными формулировками. Векторный поиск решает эту проблему: он находит семантически похожие документы, а не точные совпадения. "восстановить доступ" → "сброс пароля" → нужная статья находится за миллисекунды. За 5+ лет мы внедрили такой поиск в 20+ проектах для iOS и Android, и теперь делимся практическим опытом.
Согласно документации pgvector, семантический поиск может быть реализован с помощью индексов HNSW и IVFFlat, обеспечивающих высокую скорость даже на миллионах векторов.
Как работает векторный поиск на уровне кода
Каждый текстовый фрагмент превращается в вектор — массив чисел размерностью 384, 768 или 1536 (зависит от модели). Семантически близкие тексты имеют близкие векторы. Поиск — это нахождение ближайших векторов к запросу (Approximate Nearest Neighbor, ANN).
На практике pipeline выглядит так:
- Пользователь вводит запрос в мобильном приложении.
- Клиент отправляет запрос на бэкенд.
- Бэкенд генерирует эмбеддинг через API (OpenAI, Cohere) или локальную модель.
- Векторная БД возвращает топ-K ближайших чанков.
- Результаты передаются в LLM для суммаризации или возвращаются напрямую.
Весь pipeline до шага 4 занимает 50–300 мс — вполне приемлемо для mobile UX. Для сравнения: pgvector в среднем выдаёт результат за 100 мс, что в 3 раза быстрее, чем Pinecone с тем же HNSW-индексом на наборе из 500 000 документов.
Почему pgvector лучше для мобильных проектов?
pgvector — расширение PostgreSQL, которое добавляет поддержку векторных индексов. Если у вас уже PostgreSQL, это нулевая дополнительная инфраструктура. Мы используем его в 80% проектов, где объём документов не превышает 1 млн. Таблица ниже показывает сравнение популярных решений:
| Параметр | pgvector | Pinecone | Qdrant |
|---|---|---|---|
| Задержка (p50) | 50–150 мс | 20–50 мс | 30–80 мс |
| Максимальный объём | 10M+ (сложнее) | 100M+ | 100M+ |
| Стоимость на 1M векторов | $0 (входит в Postgres) | ~$70/мес | $25/мес (self-host) |
| Фильтрация по метаданным | ✅ (после ANN) | ✅ (настраиваемая) | ✅ (настраиваемая) |
| Офлайн-режим | ✅ | ❌ | ❌ |
pgvector поддерживает HNSW и IVFFlat индексы. HNSW даёт лучшую точность и скорость поиска, но требует больше памяти при построении. Для базы знаний до 500 000 документов HNSW хорош из коробки.
-- Создание HNSW-индекса для cosine distance 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. Для нормализованных векторов можно использовать inner product (<#>), но <=> работает без нормализации.
Как генерировать эмбеддинги на мобильном устройстве?
Есть два подхода: серверный и клиентский. Серверный предпочтительнее для большинства приложений — модели эмбеддингов весят 80–500 МБ, локальный вывод расходует батарею, а API-ключи не торчат из APK. Исключение — полностью офлайн-сценарий, например, корпоративное приложение для работы без интернета. На iOS используем Core ML (конвертация через coremltools), на Android — ONNX Runtime. Пример: all-MiniLM-L6-v2 в ONNX весит ~22 МБ и выдаёт 384-мерные векторы, достаточные для поиска по документации.
Ниже приведено сравнение популярных моделей эмбеддингов для мобильного использования:
| Модель | Размерность | Размер на диске | Качество (MTEB) |
|---|---|---|---|
| all-MiniLM-L6-v2 | 384 | 22 МБ | 56.3 |
| BGE-small-en | 384 | 33 МБ | 58.9 |
| intfloat/e5-base-v2 | 768 | 113 МБ | 61.3 |
Как настроить параметры индекса HNSW?
Параметр `ef_search` регулирует количество просматриваемых узлов во время поиска: чем выше, тем точнее, но медленнее. `ef_construction` влияет на качество построения индекса. Рекомендуемые значения: ef_search = 40–100 для баланса, ef_construction = 200–400 для больших наборов.Фильтрация по метаданным — подводные камни
Векторный поиск без фильтров ищет по всему индексу. Если нужно ограничить область поиска (например, только документы по продукту X на русском языке), добавляйте фильтры:
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, который мы настраиваем при необходимости.
Что входит в реализацию
- Аудит существующей базы знаний: структура, объём, типы контента.
- Выбор модели эмбеддингов и размерности (384/768/1536) под ваш сценарий.
- Настройка pgvector: создание индексов, оптимизация
ef_searchиef_construction. - Разработка ingestion pipeline — автоматическое чанкование и векторизация документов.
- API для поиска с поддержкой фильтрации, пагинации и сортировки.
- Интеграция мобильного UI (поисковая строка, результаты, хлебные крошки).
- Тестирование качества: precision@K, recall@K, A/B-тесты.
- Оптимизация для офлайн-режима при необходимости.
- Документация и передача исходного кода.
Сроки и как начать
Векторный поиск по корпусу до 50 тысяч документов с pgvector — 2–4 недели. С кастомной моделью эмбеддингов, reranking и мультиязычностью — 5–8 недель. Стоимость рассчитывается индивидуально после анализа вашей базы знаний.
Наши инженеры сертифицированы по iOS и Android, гарантируем качество результатов. Получите экспресс-оценку проекта за 2 дня — свяжитесь с нами для консультации. Закажите детальный аудит текущей базы знаний, чтобы выявить узкие места.