Векторна база даних відповідає на одне питання, дуже швидко
Дайте їй список чисел, і вона поверне збережені списки, найближчі до нього. Це весь інтерфейс.
Ці списки, це ембеддинги. Модель ембеддингів перетворює уривок, опис товару чи зображення на кілька сотень або кілька тисяч чисел, розташованих так, що схожі значення опиняються поруч, і що таке ембеддинги в ШІ розповідає, як саме. Векторна база даних, це місце, де ці списки живуть, коли їх багато. Вона зберігає кожен з ID та метаданими, будує над ними індекс і відповідає на пошук найближчих сусідів: "ось вектор запиту, дай мені десять найближчих."
Складна частина, це слово швидко. Порівняння запиту з мільйоном збережених векторів по 1536 чисел кожен, це 1,5 мільярда множень, і робити це на кожне натискання клавіші не масштабується. Тому векторні бази даних використовують наближені індекси найближчих сусідів, найпоширеніший з яких, HNSW, графова структура зі статті Малкова і Яшуніна 2016 року, яка перевіряє кілька сотень кандидатів замість усього мільйона і майже завжди повертає правильну відповідь. Це "майже" і є компромісом: трохи повноти заради тисячократного прискорення.
Ваша існуюча база даних збігається за словами; векторна база даних збігається за змістом
Реляційна база даних знаходить рядки, значення яких збігаються: WHERE customer_id = 4127. Повнотекстовий індекс знаходить документи, що містять слова: refund AND policy. Векторна база даних знаходить елементи, чий зміст близький: запит "як мені повернути гроші" повертає уривок під назвою "Повернення та відшкодування", навіть якщо ці два тексти не мають спільних слів.
| Реляційна база даних | Повнотекстовий пошук | Векторна база даних | |
|---|---|---|---|
| Питання | Які рядки збігаються з цим значенням? | Які документи містять ці слова? | Які елементи означають щось близьке до цього? |
| Індекс | B-дерево на стовпцях | Інвертований індекс на термінах | Граф або кластеризація над векторами (HNSW, IVF) |
| Точний? | Так | Так | Зазвичай наближений |
| Добре справляється з | ID, датами, сумами, з'єднаннями | Іменами, кодами, точними фразами | Синонімами, перефразуванням, кросмовністю, зображеннями |
| Погано справляється з | Змістом | Змістом | Точними рядками, підрахунком, фільтрацією за значенням |
| Приклади | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
Останній рядок показує, наскільки розмита ця категорія. pgvector додає векторні стовпці та індекс HNSW до звичайного Postgres, а Elasticsearch має векторне поле з версії 7.0 у 2019 році і пошук HNSW з версії 8.0 у 2022 році. "Векторна база даних", це часто можливість всередині бази даних, яку ви вже використовуєте, а не новий продукт, і окремі продукти конкурують за масштабом та операційною якістю, а не за тим, що вміють щось, чого не вміє Postgres.
Чат з документами, це векторний пошук з моделлю на кінці
Retrieval-augmented generation, про яку розповідає що таке RAG, має крок пошуку і крок написання. Векторна база даних, це крок пошуку.
- Розбийте кожен документ на уривки по кілька сотень до тисячі токенів.
- Створіть ембеддинги для кожного уривка і збережіть вектори разом із текстом уривка та його джерелом у векторній базі даних.
- Коли надходить питання, створіть для нього ембеддинг і попросіть базу даних знайти найближчі уривки.
- Передайте ці уривки мовній моделі разом із питанням, і нехай вона напише відповідь.
Кроки 1 і 2 відбуваються один раз, коли документи додаються. Кроки 3 і 4 відбуваються на кожне питання. Мовна модель ніколи не бачить всю колекцію; вона бачить п'ять чи десять уривків, обраних базою даних. Тому відповідь буде якісною настільки, наскільки якісним був пошук: якщо найближчий вектор, це не той уривок, модель впевнено відповість не на те питання, що що таке галюцинація ШІ класифікує як промах пошуку, а не вигадку.
Коли вона потрібна, а коли краще надіслати весь файл
Рішення залежить від розміру. Модель може розглядати одразу лише своє контекстне вікно, і кожен токен у ньому оплачується на кожному ході. Векторна база даних існує для того, щоб показувати моделі лише релевантний фрагмент. Для одного документа, який вміщується цілком, пошук, це крок, який можна пропустити; для колекції, яка не вміщується, це єдиний варіант.
Порахуємо ціну обох підходів для звіту на 300 000 токенів, кілька сотень сторінок, з десятьма питаннями, кожне з яких отримує п'ять уривків по 1000 токенів. Надсилання всього файлу щоразу, це 3 мільйони вхідних токенів. Отримання п'яти уривків по 1000 токенів на питання, це 50 000. За прайсовими ставками на вхід з індексу вартості моделей ШІ, отриманого з OpenRouter 2026-08-20, різниця становить 60 разів на кожній моделі. Кешування промптів, там, де провайдер його пропонує, тарифікує повторне читання того самого файлу за десяту чи половину прайсової ціни, що звужує різницю приблизно до 6-30 разів. Пошук усе одно виграє, але меншою мірою.
Підхід з цілим файлом дає щось за ці гроші, коли файл вписується в бюджет: контракт на 60 сторінок, приблизно 40 000 токенів, дозволяє моделі відповідати на питання, що потребують усього документа одразу, наприклад "чи суперечить щось тут пункту 14", на яке пошук відповісти не може, бо він ніколи не бачить пункт 14 і суперечність в одній вибірці. Звідси випливає правило: один документ або кілька, надсилайте цілком; бібліотеку, пропускайте через векторну базу даних. Між цими крайнощами розбивайте завантаження за темами, щоб модель отримала саме той розділ, який їй потрібен.
Whizi надсилає сам текст, до 40 000 токенів на хід
Whizi не використовує векторну базу даних для вашого чату. Коли ви прикріплюєте файл, завантаження документів витягує текст і надсилає його моделі як текст промпту, до фіксованого бюджету в 40 000 токенів на хід; довше завантаження обрізається, з тостом і позначкою в повідомленні про це. Файли проєктів працюють так само: функція проєктів закріплює до 10 файлів і на кожне повідомлення заново вбудовує їхній текст у промпт, з обмеженням у 32 000 символів на файл і 120 000 на весь блок проєкту.
Обмеження, це межа цього підходу. Закріплений файл понад 32 000 символів обрізається, вкладення понад бюджет у 40 000 токенів на хід обрізається, а проєкт, це папка, а не бібліотека з пошуком. Компроміс свідомий: для контракту чи статті, що вписується в бюджет ходу, наявність тексту цілком краще за його пошук, і перевірка, що справді важлива, прохання до моделі процитувати уривок, який вона використала, працює саме тому, що уривок є в наявності. Для тисячі документів, векторна база даних, це правильний інструмент, а чат-застосунок, це неправильний.
З цього механізму випливають дві звички. Назвіть файл у своєму питанні, коли прикріплено кілька, бо інакше модель обирає мовчки. І перед тим, як діяти за будь-якою відповіддю, просіть цитату. Система пошуку може повернути не той уривок; система з цілим файлом може відповісти з пам'яті замість файлу. Цитата ловить обидва випадки.
- Надсилайте один документ цілком; тримайте колекцію за векторною базою даних
- Розбивайте довге завантаження за темами, щоб модель отримала розділ, потрібний для питання
- Просіть модель процитувати уривок, який вона використала, перш ніж покладатися на відповідь
- Використовуйте звичайний текстовий пошук для ID, кодів і точних фраз; векторний пошук збігається за змістом, а не символами
- Ставтеся до промаху пошуку як до проблеми пошуку: перестворіть ембеддинги кращою моделлю або меншими уривками, перш ніж звинувачувати модель, що пише
Поширені запитання
Що таке векторна база даних простими словами?
Сховище для списків чисел, які модель ШІ використовує для представлення змісту, створене, щоб швидко знаходити найближчі збіги. Ви даєте їй ембеддинг питання, і вона повертає ембеддинги, а разом з ними і текст за ними, що мають схожий зміст. Це пошукова половина чату з документами, коли колекція завелика, щоб надіслати її цілком.
Чи потрібна мені векторна база даних, щоб використовувати ШІ зі своїми документами?
Лише якщо документи не вміщуються в контекстне вікно моделі. Один звіт чи контракт можна надіслати моделі цілком, саме так Whizi працює з вкладеннями і закріпленими файлами проєкту. Бібліотека з тисяч документів потребує пошуку, а пошук потребує векторного індексу, чи то в окремому продукті, чи в розширенні Postgres на кшталт pgvector.
Яка різниця між векторною базою даних і звичайною базою даних?
Звичайна база даних збігається за значеннями: цей ID, ця дата, це точне слово. Векторна база даних збігається за змістом, повертаючи збережені елементи, чиї ембеддинги найближчі до запиту. Зазвичай вона наближена, використовує індекс на кшталт HNSW, який перевіряє кілька сотень кандидатів замість кожного елемента, і погано справляється з точним збігом, з яким добре справляється звичайна база даних.
Які векторні бази даних використовують найчастіше?
Pinecone, Weaviate, Qdrant, Milvus і Chroma, це поширені окремі продукти, а pgvector додає ту саму можливість до Postgres. Elasticsearch і OpenSearch також мають векторний пошук. Вибір зазвичай операційний, про масштаб і хостинг, бо всі вони реалізують ту саму ідею наближеного пошуку найближчих сусідів.
Скільки економить пошук порівняно з надсиланням усього файлу?
Десять питань до звіту на 300 000 токенів коштують $6.00 на Claude Sonnet 5, якщо файл надсилається на кожному ході, і $0.10, якщо натомість отримуються п'ять уривків по 1000 токенів, за прайсовими ставками OpenRouter, отриманими 2026-08-20. На GPT-5.6 Luna та сама пара, це $0.60 проти $0.01. Співвідношення 60 разів для кожної моделі, бо обидва підходи платять за ту саму ставку за токен.
