Сліпа пляма архітектора RAG: розглядання векторних баз даних як чорних ящиків

Ми повторюємо помилку баз даних 1990-х років. І це коштуватиме комусь аварійним простоєм.

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

Механізм відмови простий. HNSW — Hierarchical Navigable Small World, стандартний алгоритм у векторних базах — добре працює до 100K документів. Пошук швидкий і точний. Команди його пускають. При 1M документів recall крутіший падати. При 10M ви витягуєте документи, які не мають ніякого стосунку до запиту. Ваша LLM будує відповідь на сміттєвому контексті і звучить впевнено.

Найбільш небезпечне: ваш моніторинг це не ловить. Latency залишається зеленою. Без помилок, без винятків. Система виглядає здоровою. Вона просто повертає невірні результати.

Я спостерігав одну команду. Три тижні витратили на це. Їхня RAG система галюцинувала. Мали чудову інструментацію: latency, throughput, вартість. Але ніхто не вимірював, чи насправді пошук працює. Коли нарешті почали — LLM judge проти ground truth — побачили: recall впав з 0.82 до 0.54 за шість місяців. Latency той же. Релевантність вдвічі менше.

Це не проблема векторної бази. Це архітектура. Команди пропустили ту проектну роботу, яка зробила реляційні бази функціональними.

Коли реляційні бази стали виробничою інфраструктурою, команди навчилися індексувати, стежити за здоров'ям індексів, розуміти запити. Вимірювали, чи працюють індекси. Ці практики зникли з embeddings. Раптом векторний пошук став математикою, не інфраструктурою.

HNSW деградує, тому що embedding простір щільніє. Ієрархія, яка працювала коли документи були розпорошені, стає менш ефективною. Можна збільшити ef_search, але вартість гостра: ef=160 в 3 рази повільніше за ef=40. Команди не налаштовують. Приймають як є.

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

RAG у масштабі потребує того ж. Команди, які поставляють надійний RAG, не використовують чисту векторну схожість. Спочатку звужують пошук фільтрами метаданих — тип документа, домен, дата. Потім векторний пошук на меншому наборі. Деякі комбінують keyword search із семантичним. Розділяють вектори за доменом. Сприймають базу як інфраструктуру, яка потребує дизайну.

Сама по собі векторна база не масштабується. Це не відмова технології. Це те, що всі системи з одним індексом зрештою мають. Але ви повинні це знати заздалегідь.

Зараз команди розгортають векторні бази ніби вони розв'язаний алгоритм. Шість місяців потім якість пошуку ненадійна. Вони здивовані, тому що це ніколи не вимірювали. Це сліпа пляма.

Джерела

• HNSW at Scale: Why Your RAG System Gets Worse as the Vector Database Grows (Towards Data Science, 2025)
• RAG, or Retrieval Augmented Generation: Revolutionizing AI in 2025 (Glean, 2025)
• Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers (arXiv, 2025)
• Building Hierarchical Agentic RAG Systems: Multi-Modal Reasoning with Autonomous Error Recovery (InfoQ, 2025)
• Mitigating Hallucination in Large Language Models (LLMs): An Application-Oriented Survey on RAG, Reasoning, and Agentic Systems (arXiv, 2025)