Ключові висновки

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

Наближений пошук найближчих сусідів — явний компроміс повноти, затримки й пам’яті. HNSW, інвертований файл (IVF), квантування й дискові графи на кшталт DiskANN розв’язують одну задачу різною ціною. Число з чужого порівняльного тесту без ваших фільтрів і моделі векторів нічого не доводить.

Фільтр за правами й орендарем — частина запиту до індексу, а не постобробка. Якщо система спочатку дістає «схожі» фрагменти, а тоді відкидає заборонені, заборонений текст уже міг потрапити в трасу, кеш і контекст моделі.

PostgreSQL із розширенням pgvector — чесна перша промислова точка. Він виграє, коли вектори живуть поруч із транзакційними даними, обсяг ще вкладається в передбачуваний бюджет пам’яті, а команда не хоче другого операційного контуру. Він програє, коли з’являються мільйони векторів із жорстким 95-м процентилем, щільні фільтри, квантування й дисковий індекс як норма, а не дослід.

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

Видалення — такий самий контракт, як вставка. М’яка позначка, відкладене стискання й «забутий» ідентифікатор у графі — типові причини, чому відкликаний документ далі спливає у відповідях.

Що таке векторна база vs реляційна vs пошуковий рушій

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

Це різні фізичні операції. Пошук найближчих сусідів у сотнях чи тисячах вимірів не зводиться до дерева за одним стовпцем і не зводиться до інвертованого списку термів. Тому з’являються окремі структури: граф зв’язків, список груп (інвертований файл), квантовані коди, дискові сторінки графа.

На практиці три шари часто співіснують, а не замінюють один одного.

flowchart LR
  app[Застосунок] --> q[Запит]
  q --> v[Вектор запиту]
  q --> f[Фільтри прав і атрибутів]
  v --> idx[Векторний індекс]
  f --> idx
  q --> lex[Лексичний індекс]
  f --> lex
  idx --> ids[Ідентифікатори кандидатів]
  lex --> ids
  ids --> canon[Канонічні фрагменти]

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

Окрема векторна база виправдана як сервіс індексу, коли:

• кількість векторів і частота запитів вимагають спеціалізованого наближеного пошуку;
• фільтри за орендарем і корисним навантаженням мають виконуватися всередині пошуку, а не після нього;
• потрібна незалежна масштабованість читання й запису відносно транзакційного ядра;
• команда готова супроводжувати другий контур: резервні копії, спостереження, переіндексацію, квоти пам’яті.

Вона не виправдана, якщо задача — «покласти PDF у базу й запитати LLM». У такій постановці ламається не вибір рушія, а межа відповідальності: хто володіє оригіналом, хто рахує вектори, хто прибирає застаріле.

Корпоративний контур, у якому векторний індекс — один сервіс серед підготовки, лексики, повторного ранжування й генерації, описано в архітектурі промислового RAG. Тут лишаємося на межі «як улаштований індекс і що він обіцяє».

Вектори і метрики

Векторне представлення (інколи кажуть «ембеддинг») — це числовий образ фрагмента або запиту. Модель відображає текст у простір фіксованої розмірності. Близькість у цьому просторі корелює зі змістовою близькістю на тому розподілі, на якому модель училася — і не гарантує користі для вашого корпусу. Навіщо взагалі потрібні векторні представлення і де в них межа — у матеріалі «Чому векторні представлення змінили корпоративний пошук». Тут важливі лише наслідки для зберігання.

Індекс зобов’язаний знати три речі й не змішувати їх мовчки:

1. Розмірність. Вектор довжини 384 не можна покласти в індекс, зібраний під 1024, «дописавши нулі».
2. Метрику. Косинус, скалярний добуток і евклідова відстань (L2) — різні порядки. Модель, яку вчили під косинус, не можна без перевірки ганяти в індексі з L2.
3. Версію моделі. Навіть дві моделі з однаковою розмірністю й «косинусом» дають несумісні простори.

Нормовані вектори роблять косинус і скалярний добуток практично взаємозамінними; ненормовані — ні. Якщо постачальник каже «використовуйте скалярний добуток», перевірте, чи нормує він виходи сам. Помилка метрики виглядає як «пошук раптом подурнішав» після зміни клієнта, а не як падіння сервісу.

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

Наближений пошук найближчих сусідів: HNSW, IVF, квантування, DiskANN — повнота vs затримка vs пам’ять

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

Граф HNSW

HNSW (Hierarchical Navigable Small World) будує багатошаровий граф: на верхніх шарах — довгі «траси», на нижньому — щільні зв’язки найближчих точок. Пошук спускається з грубого шару до точного. Параметри, які команда реально крутить:

• M — кількість зв’язків у вузла. Більше M — вища повнота й витрата пам’яті, повільніша вставка.
• efConstruction — ширина пошуку під час побудови. Вища — якісніший граф, довше будується індекс.
• efSearch (або аналоги) — ширина пошуку під час запиту. Це ваш основний важіль «повнота проти затримки» без перебудови.

Сильні сторони: висока повнота за доброго підбору, стабільна затримка на «простих» запитах без жорстких фільтрів, передбачувана поведінка на середніх обсягах. Слабкі: граф любить оперативну пам’ять; вставки у великий граф дорожчі, ніж у кластерний індекс; жорсткі фільтри ламають зв’язність — пошук іде ребрами подібності, а не предикатом «цей орендар».

Пам’ять грубо складається з самих векторів плюс списку сусідів. Для мільйонів точок із float32 і немаленьким M рахунок іде на десятки гігабайтів ще до корисного навантаження. Саме тому з’являються квантування й дискові варіанти, а не «ще один сервер побільше».

Інвертований файл (IVF) і родичі

IVF (інколи IVFFlat) спочатку розбиває простір на групи — зазвичай методом k-середніх. В індексі зберігаються центри груп і списки векторів усередині. Запит дивиться не всі групи, а nprobe найближчих до вектора запиту. Параметри:

• nlist — кількість груп. Замало — довгі списки й слабке відсікання. Забагато — шумова кластеризація й ризик промахнутися повз потрібну групу.
• nprobe — скільки груп дивитися в запиті. Це прямий важіль повноти й затримки.

Сильні сторони: менше накладних витрат графа, простіше зрозуміти «ми дивимося 8 із 1024 груп», легше поєднувати з квантуванням кодів усередині групи. Слабкі: повнота чутлива до якості кластеризації; після великого потоку вставок розподіл груп застаріває; за перекосу даних частина груп роздувається.

IVF часто обирають, коли векторів багато, пам’ять обмежена, а команда готова калібрувати nprobe на своєму наборі, а не копіювати чужі числа.

Квантування

Квантування стискає вектор: 8-бітне скалярне, добуток підпросторів (PQ), двійкові коди. Мета — вмістити індекс у пам’ять або пришвидшити порівняння за рахунок роботи з кодами, а не з float32. Ціна — втрата розрізнення близьких точок. На практиці квантування майже завжди комбінують із повторним ранжуванням короткого списку повними векторами: спочатку грубий прохід по кодах, потім уточнення.

Помилка експлуатації — увімкнути максимальне стискання, бо «в таблиці написано економію в 16 разів», і дивуватися падінню повноти на прикордонних запитах. Стискайте те, що вимірюєте. Зберігайте повний вектор окремо, якщо збираєтеся уточнювати; інакше економія пам’яті з’їдає якість на останній милі.

Дискові графи: DiskANN і сусіди

Коли вектори й граф не вміщаються в оперативну пам’ять, з’являються індекси, розраховані на твердотілий накопичувач: DiskANN (граф Vamana і сторінкове пакування), дискові режими в Milvus і Qdrant, різні схеми «гарячий граф у пам’яті, вектори на диску». Ідея одна: зменшити випадкові читання, тримати в пам’яті навігаційний каркас, ходити на диск за векторами й сусідами пакетами.

Це не «безкоштовна нескінченна ємність». Затримка починає залежати від черги диска, фрагментації й кешу сторінок. Пікова повнота на холодному кеші й на прогрітому — різні числа. Навантажувальний тест зобов’язаний включати прогрів і частку унікальних запитів, інакше ви виміряєте кеш операційної системи, а не індекс.

Як обирати структуру

Не починайте з назви алгоритму. Зафіксуйте:

• обсяг і зростання кількості векторів на рік;
• допустиму оперативну пам’ять на копію;
• цільові 95-й і 99-й процентилі на запиті з бойовими фільтрами;
• частку оновлень (вставка, заміна, видалення) відносно читання;
• чи потрібен жорсткий фільтр «один орендар із десятків тисяч».

Грубі орієнтири, не закони: до сотень тисяч векторів точний або простий HNSW часто достатній; мільйони в пам’яті — HNSW плюс квантування або IVF; десятки мільйонів і обмеження пам’яті — дисковий граф або зовнішній сервіс, який це вміє. Будь-який орієнтир б’ється об ваші фільтри: індекс без предиката й індекс із tenant_id = X — різні системи.

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

Фільтри, багатоорендність, гібрид на боці сховища

Змістова близькість без предиката — лабораторний режим. У промисловій експлуатації майже кожен запит несе обмеження: орендар, роль, мова, тип документа, строк дії, «лише затверджене», «не чернетка». Питання не в тому, чи є фільтри, а в тому, на якому етапі їх застосовують.

Предфільтр, постфільтр і пошук з урахуванням предиката

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

Предфільтр: спочатку звузити множину ідентифікаторів, потім шукати серед них. На вузькій множині це може бути точний перебір. На широкій — окремий індекс за атрибутами плюс векторний прохід.

Пошук з урахуванням предиката: рушій використовує індекс за корисним навантаженням (значеннями атрибутів) під час обходу графа або груп, щоб не ходити в завідомо заборонені вузли й не втрачати повноту. Саме це продають Qdrant (індекси корисного навантаження), Weaviate (фільтри в запиті), пізні версії pgvector (ітеративні сканування), плагіни k-найближчих в OpenSearch і Elasticsearch. Якість реалізації різна: у графа зв’язність побудована за подібністю, а не за орендарем, тому «фільтр на льоту» — окрема інженерна задача, а не галочка в документації.

Правило безпеки: заборонений фрагмент не повинен потрапляти в кандидатський список застосунку. Перевірка прав — детермінований предикат довіреної сторони, а не інструкція моделі.

Ізоляція орендарів

Три робочі моделі:

1. Колекція (індекс) на орендаря. Жорстка ізоляція, прості фільтри, дорогий операційний хвіст: тисячі маленьких індексів, нерівномірне навантаження, складніші квоти. Виправдано за сильних вимог до ізоляції даних і рідкісної кількості великих орендарів.
2. Спільний індекс плюс обов’язковий предикат tenant_id. Дешевше супроводжувати, небезпечніше помилитися в запиті. Потрібні індекси за атрибутом, заборона запитів без предиката на рівні API, аудит.
3. Сегментація (фізичний поділ) за орендарем або групою. Компроміс: менше колекцій, ніж орендарів, краща локальність, складніше ребалансування.

«Галасливий сусід» — не метафора: гарячий орендар забиває чергу побудови графа й кеш сторінок. Квоти запису, окремі пули запитів і спостережуваність за ключем орендаря потрібні з першого промислового клієнта, а не після інциденту.

Видалення на вимогу суб’єкта даних має доходити до вектора, корисного навантаження й усіх копій, а не лише до канонічного файла. Інакше індекс стає тіньовою копією персональних відомостей.

Гібрид на боці сховища

Гібридний пошук — спільне використання лексичного й векторного сигналів. Частина продуктів уміє це всередині одного запиту: розріджені вектори й щільні в Qdrant, гібридний запит у Weaviate, tsvector поруч із pgvector у PostgreSQL, лексика плюс k-найближчі в OpenSearch/Elasticsearch. Злиття рангів, зокрема reciprocal-rank fusion, докладно розібрано в матеріалі про гібридний пошук. Тут важлива межа шару зберігання.

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

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

Карта продуктів: pgvector, Qdrant, Weaviate, Pinecone, Milvus, Chroma, k-найближчі в OpenSearch/Elasticsearch

Карта нижче — не рейтинг і не заміна навантажувального тесту. Вона відповідає на запитання «яку операційну модель ви купуєте». Клієнтські бібліотеки на Python, пакування й сюрпризи шляху з ноутбука в сервіс розібрані окремо: п’ять Python-бібліотек векторних баз.

Як читати таблицю. Якщо у вас уже є зрілий кластер OpenSearch і запити здебільшого лексичні, додавати вузький векторний канал туди часто дешевше, ніж піднімати Milvus. Якщо транзакційна правда вже в PostgreSQL, а пошук за змістом — функція одного продукту, pgvector зменшує кількість систем. Якщо фільтри за корисним навантаженням і гібрид із розрідженими векторами — щоденне навантаження, Qdrant або Weaviate ближчі до задачі, ніж «ще один стовпець в OLTP». Якщо команда з трьох людей не хоче супроводжувати індекс, керований сервіс знімає нічні чергування й додає рахунок і залежність від мережі.

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

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

Експлуатація: версія моделі векторів, переіндексація, видалення, вартість

Промислова експлуатація шару індексу починається після того, як «вставка працює на стенді». Чотири сюжети ламають системи частіше, ніж вибір HNSW проти IVF.

Версія моделі як частина схеми

Кожна точка має нести model_id (ім’я, ревізія, розмірність, метрика). Пошук зобов’язаний вказувати ту саму версію, якою пораховано запит. Дві моделі в одній колекції без розділення — тихе псування простору: повнота падає, а моніторинг «сервіс живий» зелений.

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

Практичний прийом: ідентифікатор фрагмента незмінний, а векторні проєкції версій живуть поруч (vec_v3, vec_v4) або в паралельних колекціях. Застосунок обирає проєкцію явно. Відкат — зміна вказівника, а не нічна перезбірка «назад у невідомість».

Переіндексація

Повна перебудова потрібна при зміні моделі, метрики, алгоритму індексу, схеми атрибутів, правил поділу (останнє — уже межа з конвеєром RAG). Часткова — при псуванні сегмента, після масового видалення, коли квантування або групи IVF перекосилися.

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

Ідемпотентність завантажувача важливіша за швидкість: той самий документ тієї самої версії не повинен плодити дублікати з різними внутрішніми id. Дублікати крадуть слоти в top_k і створюють хибне відчуття повноти.

Видалення і право бути забутим

Три рівні, які плутають:

1. Сховати з видачі — фільтр «не показувати». Швидко, але вектор і текст лишаються.
2. Логічне видалення — позначка, виключення з пошуку, відкладене фізичне вичищення. Граф HNSW може довго тримати «надгробки»; повнота й затримка деградують, доки не пройде стискання.
3. Фізичне видалення — запис зникла з диска й із копій. Потрібне для персональних даних і грубих помилок завантаження.

Контракт видалення включає: канонічне сховище, усі проєкції векторів, кеші, резервні копії (з політикою, а не з магією «одразу скрізь»), журнали, які самі по собі можуть містити фрагмент. Якщо юридичний строк «стерти за 30 днів», індекс із відкладеним стисканням через 45 днів — порушення процесу, а не дрібниця рушія.

Перевіряйте видалення так само, як вставку: контрольним запитом, який має стати порожнім.

Вартість

Рахунок векторного шару рідко дорівнює рядку в хмарному прайсі. Складайте:

• оперативну пам’ять копій (часто головна стаття для HNSW без квантування);
• диск і кількість операцій вводу-виводу, якщо індекс дисковий;
• CPU на побудову й на квантування;
• перерахунок векторів при зміні моделі (часто дорожчий за зберігання);
• мережу до керованого сервісу й одиниці тарифікації там;
• людський час на другий контур спостереження й резервного копіювання.

Дешевий керований індекс за дорогого перерахунку векторів — хибна економія. Дорогий самостійний хостинг за рідкісних запитів і малого обсягу — теж. Рахуйте вартість успішного пошуку (запит, що повернув потрібний фрагмент у межах затримки), а не вартість гігабайта в порожнечі.

Спостережуваність мінімуму: затримка за процентилями з розбиттям «з фільтром / без», повнота на контрольній вибірці після кожної зміни індексу, черга вставок, частка видалень, розмір графа або груп, помилки незбігу розмірності, запити без tenant_id, якщо такий предикат обов’язковий.

Коли вистачає PostgreSQL і коли потрібна окрема база

PostgreSQL із розширенням pgvector закриває напрочуд великий клас промислових задач: внутрішній помічник на десятках чи сотнях тисяч фрагментів, вектори поруч із сутностями домену, транзакційна вставка «рядок бізнесу + вектор», знайомий резервний контур, SQL-предикати, які юристи й аудитори розуміють без нової мови запитів. Свіжі версії додали HNSW, ітеративні сканування за фільтрів і щільніші типи зберігання. Це вже не «іграшкове розширення 2023 року».

Окрема база потрібна, коли складається кілька сигналів, а не коли маркетинговий слайд обіцяє «мільярди векторів».

Рішення ухвалюйте навантажувальним тестом на копії бойового розподілу: ті самі фільтри, та сама частка порожніх предикатів, той самий розмір корисного навантаження, та сама частка вставок. Синтетичний «мільйон випадкових векторів без фільтра» хвалить граф і обманює планувальника потужності.

Міграція з pgvector не зобов’язана бути драмою. Часто лишають PostgreSQL системою істини й прав, а векторний сервіс забирає лише проєкцію для пошуку. Подвійний запис на час звірки повноти дешевший, ніж «переїзд усіх документів у нову базу», якій документи не потрібні.

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

Типові помилки

Зберігати оригінали лише у векторній базі. Індекс починає жити своїм життям: модуль розбору оновили, а «істина» у корисному навантаженні застаріла. Канон — окремо, проєкція — окремо.

Шукати без предиката доступу, фільтрувати в застосунку. Це дірка й джерело порожньої видачі. Предикат має бути частиною запиту до індексу й частиною контракту API.

Змішати моделі векторних представлень. Тихе провалля якості. Версія моделі — обов’язкове поле й обов’язковий параметр пошуку.

Копіювати параметри M, efSearch, nlist зі статті. Чужі числа зняті на чужій розмірності, чужій метриці й без ваших фільтрів. Калібруйте на контрольній вибірці.

Увімкнути максимальне квантування без повторного ранжування повними векторами. Економія пам’яті на папері, втрата розрізнення на прикордонних запитах.

Вважати Chroma в контейнері «базою продакшену». Зручний цикл розробки не замінює резервне копіювання, ізоляцію орендарів і план зростання. Шлях із ноутбука ламається на пакуванні клієнта частіше, ніж на алгоритмі сусідів — про це саме огляд Python-бібліотек.

Не мати шляху видалення. Відкликаний регламент, помилково завантажений договір, вимога суб’єкта даних — без фізичного контуру індекс пам’ятає зайве.

Оцінювати рушій запитами без фільтрів. Ви оберете переможця лабораторного режиму й програєте в перший же день із tenant_id.

Плутати затримку індексу із затримкою RAG. Мережа до моделі, повторне ранжування й збирання контексту часто дорожчі за пошук. Оптимізуйте за трасою, а не за одним мікротестом сусідів.

Рости копіюванням колекцій вручну. Без маніфесту версій за пів року ніхто не знає, який індекс обслуговує який продукт.

Часті запитання

Подальше читання

• Векторні бази даних — короткий розділ-вступ: навіщо індекс у корпоративному ШІ і як він пов’язаний із правами доступу.
• Чому векторні представлення змінили корпоративний пошук — сенс векторних представлень, межі змістової близькості, гібрид із точним пошуком.
• Промислова інженерія RAG — весь конвеєр: корпус, поділ, пошук, повторне ранжування, оцінювання. Цей матеріал — лише шар зберігання.
• Архітектура промислового RAG — платформена схема, у якій векторний індекс — один сервіс серед інших.
• Гібридний пошук із BM25, векторами і reciprocal-rank fusion — як зливати лексичний і векторний канали.
• Експерименти з поділом документів — як фрагмент, який ви кладете в індекс, впливає на обидва канали пошуку.
• Python-бібліотеки векторних баз — пакування клієнтів, стабільність API і шлях із ноутбука, а не порівняльний тест сусідів.

Висновок

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

PostgreSQL із розширенням pgvector лишається чесною промисловою точкою старту, доки обсяг, фільтри й затримка живуть в одному операційному контурі з транзакційними даними. Окремий продукт — Qdrant, Weaviate, Pinecone, Milvus або векторний контур в OpenSearch/Elasticsearch — виправданий, коли цей контур починає брехати за процентилями, пам’яттю чи ізоляцією, а не коли так красивіше на схемі.

Алгоритм сусідів обирають після того, як зрозумілий запит: який предикат, яка повнота, який бюджет пам’яті, який ритм оновлень. Без цих чотирьох чисел порівняльний тест чужого блогу — розвага. З ними шар індексу стає нудною, супроводжуваною частиною платформи — і перестає бути місцем, куди звалюють «усю RAG-магію».

У лабораторному сенсі Stuzhuk Lab це той самий принцип, що й для решти платформи: спочатку доводять, що потрібний фрагмент знаходиться і має право бути знайденим, і лише потім сперечаються про формулювання відповіді моделі.