Реалізація векторного пошуку для AI-базі знань у мобільному додатку
Векторний пошук знаходить семантично схожі документи, а не просто збіги за ключовими словами. Запит «як відновити доступ» знайде статтю «скидання пароля», навіть якщо слово «відновити» у ній не зустрічається. Це основа будь-якого AI-пошуку по базі знань.
Як працює на рівні кода
Кожен текстовий фрагмент перетворюється у вектор—масив чисел (1536 або 3072 значень для OpenAI, 768 для локальних моделей). Семантично схожі тексти дають близькі вектори. Пошук—це пошук найближчих векторів до запиту (Approximate Nearest Neighbor, ANN).
На практиці для мобільного додатку це означає:
- Користувач вводить запит
- Клієнт відправляє запит на бекенд
- Бекенд створює еквалайзір запиту через API (OpenAI, Cohere) або локальну модель
- Векторна БД повертає топ-K найближчих чанків
- Результати передаються у LLM або повертаються прямо
Весь пайплайн до кроку 4 займає 50–300 мс—цілком прийнятно для мобільного 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-мірні вектори достатної якості для пошуку по корпоративній документації.
Відображення результатів пошуку на мобільному
Кожен результат містить: витяг тексту, назву документа/раздела, оцінку схожості, дату оновлення. На мобільному показуємо:
- Оцінка як візуальний індикатор релевантності (три точки/бар, не число—число нічого не говорить користувачу)
- Хлібні крошки джерела: «Руководство користувача → Установка → iOS»
- Підсвітлення збіжних слів (навіть при семантичному пошуку—слова все рівно часто пересікаються)
- Кнопка «Відкрити повний документ»
Етапи та сроки
Інвентаризація та нормалізація бази знань → вибір моделі еквалайзирів → настройка векторної БД та індексів → розробка ingestion pipeline → пошуковой API з фільтрацією → мобільний UI пошуку з результатами → тестування якості (precision@K, recall@K) → ітерація.
Векторний пошук по корпусу до 50 тисяч документів з pgvector—2–4 тижні. З кастомною моделлю еквалайзирів, reranking та мультиязичністю—5–8 тижнів.