Векторні бази даних

Угода, яку ви насправді укладаєте

Модель ембедингів перетворює шматок тексту, зображення чи товар на список чисел — зазвичай від кількох сотень до кількох тисяч — розміщених так, що речі, які людина назвала б схожими, опиняються поруч. Щойно зміст стає координатами, «знайти повʼязані документи» перетворюється на «знайти найближчі точки» — задачу геометрії з довгою історією й однією незручною властивістю: розвʼязати її точно означає виміряти відстань до кожної наявної точки. На десяти тисячах обʼєктів це миттєво. На пʼятдесяти мільйонах це вже не запит, а пакетна задача.

Тому кожна векторна база на масштабі відмовляється від точності. Вона будує індекс, що дозволяє пошуку відвідати кількасот перспективних кандидатів замість пʼятдесяти мільйонів, і мириться з тим, що справді ближчий обʼєкт іноді лишається невідвіданим. Частку справжніх найближчих сусідів, яку пошук насправді повертає, називають повнотою (recall), і найважливіше, що варто зрозуміти про ці системи: повнота — це регулятор. Підкрутіть його вгору — і ви відвідуєте більше кандидатів за більшу затримку й більше CPU; вниз — і дістаєте швидку відповідь, яка тихо щось пропускає.

Одна деталь підводить людей раніше, ніж усе решта починає важити: метрика відстані має бути тією, під яку тренували модель ембедингів. Косинусна подібність порівнює напрямок і ігнорує довжину; скалярний добуток винагороджує і довші вектори, і співнапрямлені; евклідова відстань міряє пряму лінію між точками. Візьміть скалярний добуток на векторах, які модель очікує нормалізованими, — і популярні обʼєкти домінуватимуть у кожному результаті з причин, що не мають стосунку до релевантності. Дивіться картку моделі, беріть названу нею метрику й нормалізуйте, якщо вона так каже.

Родини індексів — і чого коштує кожна

Кожен продукт на ринку реалізує якусь підмножину чотирьох ідей, зазвичай під власними назвами. Знати ідеї, а не бренди, — саме це дозволяє чесно читати бенчмарк, бо бенчмарк, що порівнює два продукти, майже завжди порівнює дві конфігурації індексу.

• Flat — без індексу

  Порівняти з усім. 100% повноти, лінійна вартість, без побудови й без параметрів. Правильний вибір до кількох сотень тисяч векторів — і базовий рівень, проти якого міряють решту індексів.

• IVF — інвертовані списки

  Один раз кластеризувати простір, потім шукати лише в кількох найближчих кластерах. Регулятор — nprobe. Дешевий у побудові й у памʼяті, псується, коли дані відходять від кластеризації, на якій його збудовано.

• HNSW — навігований граф

  Шари звʼязків: розріджені згори для довгих стрибків і щільні знизу для точності. Найкраща повнота на мілісекунду в загальному вжитку й типовий вибір майже всюди. Регулятор — efSearch; сам граф коштує відчутної памʼяті понад вектори.

• Квантизація — PQ та інші

  Не структура пошуку, а стиснення: зберігати наближення кожного вектора, часто у 4–32 рази менше. Кладеться під IVF чи HNSW, коли памʼять є звʼязувальним обмеженням, — ціною ще трохи повноти.

Арифметику памʼяті варто зробити на папері до того, як щось обирати, бо саме вона зазвичай вирішує. Вектор на 1536 вимірів у 32-бітних числах — це 6144 байти. Мільйон таких — близько 6 ГБ самих лише векторів, а граф HNSW над ними додає ще приблизно 20–40% на звʼязки, тобто 8 ГБ до корисного навантаження, реплік і запасу. Десять мільйонів — це машина, що коштує справжніх грошей щомісяця. Два рухи різко це зменшують: узяти модель ембедингів із меншою розмірністю, якщо на ваших даних вона працює порівнянно, і зберігати вектори як 8-бітні цілі там, де втрата повноти прийнятна, — це рівно вчетверо менше.

Фільтрація — там, де індекс воює з вами

Майже кожен реальний запит має причеплену умову: лише цей робочий простір, лише опубліковані документи, лише в наявності, лише цією мовою, не видалені. У реляційній базі це нічим не примітно. Тут це найскладніше на сторінці, бо індекс збудовано над геометрією всієї колекції й він нічого не знає про вашу умову. Є три способи їх помирити, і кожен ламається по-своєму.

Практичне правило — робити межі з високою вибірковістю структурними, а не фільтром. Якщо кожен запит обмежений одним тенантом, робочим простором чи мовою, дайте кожному власну колекцію або партицію — і проблема зникає: ви шукаєте в малому індексі, а не фільтруєте великий. Лишайте фільтри для умов, що справді змінюються від запиту до запиту, а будь-який фільтр, що вибирає менше кількох відсотків колекції, вважайте сигналом, що дані від початку варто було розділити.

Записи, видалення й міграція, яку ніхто не планує

Векторні індекси збудовані для читання. Графовий індекс може приймати вставки під час обслуговування, але кожна вставка додає звʼязки до наявної структури, і граф, який увібрав мільйони вставок, вимірювано гірший за ті самі дані, проіндексовані з нуля, — повнота повзе вниз без жодної помилки. З видаленнями гірше: більшість рушіїв позначає запис як вилучений замість того, щоб полагодити граф, тож видалений вектор і далі займає памʼять і далі обходиться, а колекція з великим оборотом поволі наповнюється надгробками. І те, і те лікується періодичною перебудовою — експлуатаційною задачею, яку хтось має мати за свою й планувати.

• Наповнюйте пакетно, а не по одному вставленню: побудувати індекс один раз над усім набором і швидше, і краще звʼязано.
• Вважайте видалення запитом, який буде вшанований у результатах негайно, а в памʼяті — пізніше, і перевірте, що саме гарантує ваш рушій.
• Плануйте перебудови за оборотом, а не за календарем: колекція, де замінено 20% записів, дозріла — байдуже, яке число.
• Тримайте вихідний текст і метадані у своїй основній базі, а векторне сховище — як похідний індекс, який можна знести й відбудувати.
• Зберігайте назву й версію моделі ембедингів на кожному записі, бо одного дня в колекції одночасно опиняться два покоління.

Чи потрібна вам окрема база взагалі

Чесний вибір за замовчуванням для більшості продуктів — розширення в базі, яку ви вже тримаєте. Postgres із pgvector підтримує ті самі родини індексів, дає транзакції, зʼєднання й одну історію бекапів і дозволяє фільтру бути звичайним WHERE, який обчислює планувальник, обізнаний з іншими вашими колонками. Цього перестає вистачати на масштабі, до якого більшість проєктів ніколи не доходить, — приблизно тоді, коли вектори перестають комфортно вміщатися в памʼять поряд із рештою роботи бази або коли потрібен шардований, незалежно масштабований пошук із репліками на колекцію.

І остання річ, що рятує проєкти: векторний пошук не завжди найкращий. Він сильний на перефразуванні й слабкий на точних токенах — артикулах, кодах помилок, іменах, рідкісних абревіатурах, — саме на тих запитах, де користувачі чекають буквального збігу й найменш поблажливі. Поєднання лексичного індексу з векторним і злиття двох списків результатів надійно перемагає кожен окремо — і це часто найдешевше доступне покращення якості. Якщо ваша оцінка показує, що векторний індекс програє звичайному пошуку за ключовими словами на ваших власних запитах, — вірте оцінці. Як проводити цю оцінку, належить сторінці про RAG, що володіє якістю пошуку як вимірюваною властивістю.

Антипатерни, які варто назвати

• Реліз без жодного виміру повноти: ніхто не відрізнить проблему налаштувань від проблеми моделі.
• Пост-фільтр по вибірковій умові — і порожній результат, поданий як «пошук зламався».
• Метрика відстані, що не відповідає моделі ембедингів, — дає правдоподібну на вигляд нісенітницю.
• Векторне сховище як єдина копія тексту: перебудова означає відновлення даних, яких у вас уже немає.
• Окремий кластер заради двохсот тисяч векторів, де колонка в наявній базі була б і швидшою в запитах, і безкоштовною в експлуатації.
• Багатотенантність, забезпечена фільтром, а не межею: одна забута умова — це розкриття даних.

Коли це застосовувати

Пов’язані сторінки

• РозробкаRAG-архітектураRetrieval-augmented generation (RAG) — це спосіб змусити модель відповідати про дані, на яких її не навчали: спершу знайти доречні фрагменти, покласти їх у промпт і вимагати, щоб відповідь походила саме з них. Тому RAG — це пошукова система з мовною моделлю на кінці, і тому майже кожна хибна відповідь є збоєм пошуку, а не генерації. На цій сторінці — обидва конвеєри, як вимірювати пошук окремо, і проблема прав доступу, що перетворює демо на інцидент.
• РозробкаNoSQLNoSQL — це парасолькова назва, яка окреслює чотири різні види баз даних через те, чим вони не є, — і саме тому вибір так часто роблять погано. Спільне в них корисніше за те, чого їм бракує: дані розміщуються на вузлі за ключем, який ви обираєте, тож саме цей ключ вирішує, які запити дешеві, які дорогі, а які неможливі. На цій сторінці — чотири сімейства, до чого насправді зобовʼязує ключ партиціювання, що означає «зрештою узгоджено» для ваших користувачів і коли реляційна база досі є правильною відповіддю.
• ІнфраструктураML-пайплайниML-пайплайн — це автоматизований шлях від сирих даних до моделі, яку можна розгорнути. Натренована модель — це артефакт збірки, а не код. Вона постає з чотирьох входів — даних, тренувального коду, конфігурації та середовища, — і лише один із них лежить у вашому репозиторії. Саме тому клонування репозиторію й запуск скрипта дає вам іншу модель. Пайплайн існує, щоб усі чотири були записані, повторювані й доступні для перевірки. На цій сторінці — стадії та чому вони окремі, чому дані ламаються тихо, а код гучно, що таке skew, який робить чудову офлайн-модель марною онлайн, і коли ноутбука справді достатньо.