У мобільній розробці нерідко виникає ситуація: користувач вводить запит "як відновити доступ", а система повертає порожній екран. Звичайний пошук за підрядком не справляється із синонімами, помилками та різними формулюваннями. Векторний пошук вирішує цю проблему: він знаходить семантично схожі документи, а не точні збіги. "відновити доступ" → "скидання пароля" → потрібна стаття знаходиться за мілісекунди. За 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 = 'uk' 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 дні — зв'яжіться з нами для консультації. Замовте детальний аудит поточної бази знань, щоб виявити вузькі місця.