Інфраструктура RAG: побудова продуктивних систем генерації з доповненням на основі пошуку

Оновлено 8 грудня 2025 року

Оновлення за грудень 2025 року: Впровадження RAG прискорюється як корпоративний варіант використання LLM №1. Архітектури GraphRAG та агентного RAG набирають популярності для складних міркувань. Ринок векторних баз даних консолідується навколо Pinecone, Weaviate, Milvus та Qdrant. Voyage-3-large перевершує вбудовування OpenAI та Cohere на 9-20%. Семантичне чанкування покращує повноту пошуку до 9% порівняно з підходами фіксованого розміру. Виробничі виклики зміщуються від прототипів до масштабу — дрейф вбудовувань, мультиорендність та вимоги до затримки менше 50 мс стимулюють інвестиції в інфраструктуру.

Harvey AI обслуговує 97% юридичних фірм Am Law 100, використовуючи генерацію з доповненням на основі пошуку для обґрунтування юридичних досліджень реальною судовою практикою, а не галюцинованими цитатами.¹ Anthropic, OpenAI та Google рекомендують RAG як основний метод підключення великих мовних моделей до пропрієтарних корпоративних даних. Проте розрив між працюючим прототипом RAG та продуктивною інфраструктурою вимірюється місяцями інженерних зусиль. Організації виявляють, що векторні бази даних, конвеєри вбудовувань, стратегії чанкування та оптимізація пошуку кожна представляє окремі інфраструктурні виклики, які множаться при масштабуванні. Побудова систем RAG, які обробляють мільйони документів, обслуговують тисячі одночасних користувачів та підтримують затримку менше секунди, вимагає архітектурних рішень, які мало хто передбачає на етапі перевірки концепції.

Базова архітектура, яку вимагає кожна продуктивна система RAG

Системи RAG поєднують дві фундаментальні можливості: отримання релевантного контексту з бази знань та генерацію відповідей, обґрунтованих цим контекстом. Архітектура розбивається на п'ять окремих компонентів, кожен з яких має специфічні інфраструктурні вимоги.

Конвеєри прийому документів обробляють потік від необроблених документів до індексованих вбудовувань. Продуктивні системи обробляють PDF, HTML, документи Word, повідомлення Slack та записи баз даних через парсери, специфічні для кожного формату. Конвеєри прийому повинні відстежувати версії документів, обробляти інкрементальні оновлення та підтримувати метадані для фільтрації. Типові корпоративні розгортання обробляють від 100 000 до 10 мільйонів документів під час початкового завантаження, з щоденними інкрементальними завантаженнями від 1 000 до 50 000 нових документів.²

Системи чанкування розділяють документи на сегменти, зручні для пошуку. Чанкування фіксованого розміру працює для однорідного контенту, як-от новинні статті, тоді як семантичне чанкування зберігає межі змісту для складних документів.³ Більшість продуктивних систем використовують рекурсивне чанкування з 400-512 токенами та 10-20% перекриттям, досягаючи 85-90% повноти в бенчмарк-тестах.⁴ Вибір стратегії чанкування стає напівпостійним — зміна підходів пізніше вимагає повторного вбудовування всього корпусу.

Інфраструктура вбудовувань перетворює текстові чанки на щільні векторні представлення. Організації обирають між керованими API (OpenAI, Cohere, Voyage AI) та моделями власного хостингу. Генерація вбудовувань створює найбільш змінну структуру витрат у системах RAG, з цінами від $0,02 до $0,18 за мільйон токенів залежно від вибору моделі.⁵ Пакетна обробка паралелізує генерацію вбудовувань на вузлах GPU для початкових завантажень, тоді як потокові конвеєри обробляють інкрементальні оновлення.

Векторні бази даних зберігають та отримують вбудовування, використовуючи алгоритми приблизного найближчого сусіда. Чотири домінуючі варіанти — Pinecone, Weaviate, Milvus та Qdrant — обслуговують різні операційні профілі. Pinecone пропонує повністю керований сервіс без операційних витрат, Weaviate забезпечує гібридний пошук з можливостями графа знань, Milvus обробляє розгортання мільярдного масштабу, а Qdrant відзначається складною фільтрацією метаданих.⁶ Вимоги до сховища масштабуються з розмірністю вбудовувань та кількістю документів; корпус з 10 мільйонів документів з 1024-вимірними вбудовуваннями вимагає приблизно 40 ГБ векторного сховища.

Оркестрація пошуку та генерації пов'язує компоненти разом, зазвичай використовуючи фреймворки на кшталт LangChain, LlamaIndex або власні реалізації. Оркестрація обробляє обробку запитів, пошук, перера́нжування, побудову промптів та генерацію відповідей. Продуктивні системи впроваджують шари кешування, резервні стратегії та інструментарій спостережуваності на кожному етапі.

Вибір векторної бази даних визначає операційну складність

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

Pinecone домінує в сегменті керованих сервісів, повністю обробляючи інфраструктуру за своїм API. Команди розгортають продуктивні системи за години, а не тижні, з автоматичним масштабуванням, мультирегіональною реплікацією та відповідністю SOC 2 за замовчуванням. Pinecone підтримує до 40 КБ метаданих на вектор, що дозволяє багату фільтрацію без зовнішніх систем. Компроміс передбачає вищу вартість за запит та зменшений контроль над оптимізацією інфраструктури. Організації з передбачуваними навантаженнями часто вважають Pinecone економічно ефективним; ті, хто має дуже змінний трафік або вимоги екстремального масштабу, зазвичай мігрують на альтернативи.⁷

Weaviate поєднує гнучкість open-source зі зручністю керованого сервісу через Weaviate Cloud. Система поєднує векторний пошук з можливостями графа знань, дозволяючи гібридні запити, які фільтрують за структурованими даними, одночасно ранжуючи за семантичною подібністю. Модульна архітектура Weaviate підтримує кілька моделей вбудовувань одночасно, що корисно для організацій, які експериментують з різними підходами. Розгортання Docker та Kubernetes вимагає помірного операційного досвіду, що робить Weaviate популярним серед команд з деяким інфраструктурним потенціалом.⁸

Milvus (та його керований аналог Zilliz Cloud) націлений на розгортання мільярдного масштабу з продуктивністю як головною метою проектування. Milvus лідирує в бенчмарках за сирою затримкою, досягаючи часу запиту менше 10 мс на індексах з мільярдом векторів завдяки прискоренню GPU та передовим алгоритмам індексування.⁹ Архітектура розділяє обчислення та сховище, дозволяючи незалежне масштабування кожного рівня. Експлуатація Milvus вимагає значного досвіду в інженерії даних — команди без спеціалізованого інфраструктурного персоналу часто стикаються з труднощами в управлінні кластером та налаштуванні продуктивності.

Qdrant швидко набув популярності для вимог складної фільтрації. Побудований на Rust, Qdrant виконує фільтрацію корисного навантаження безпосередньо в алгоритмі пошуку, а не як постобробку, забезпечуючи вищу продуктивність для фільтрованих запитів.¹⁰ Компактний ресурсний відбиток робить Qdrant популярним для чутливих до витрат розгортань, тоді як його чіткий дизайн API прискорює швидкість розробки. Самостійно розгорнуті системи працюють гладко на скромній інфраструктурі, хоча корпоративні функції вимагають комерційного ліцензування.

Критерії вибору повинні насамперед враховувати операційну спроможність. Команди, яким потрібно нуль операційних витрат, обирають Pinecone або Weaviate Cloud. Організації з можливостями SRE, комфортними зі stateful робочими навантаженнями Kubernetes, отримують економію та контроль від самостійно розгорнутих Milvus, Qdrant або Weaviate. Вимоги відповідності іноді виключають варіанти — Pinecone та Weaviate Cloud пропонують відповідність SOC 2 та HIPAA, тоді як вимоги локального розгортання потребують self-hosted рішень.

Вибір моделі вбудовувань впливає як на вартість, так і на якість пошуку

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

Voyage AI лідирує в бенчмарках MTEB, при цьому voyage-3-large перевершує OpenAI text-embedding-3-large на 9,74% та Cohere embed-v3-english на 20,71% в оцінених доменах.¹¹ Voyage AI підтримує контекстні вікна на 32K токенів (порівняно з 8K для OpenAI та 512 для старіших моделей Cohere), дозволяючи обробку довших документів без чанкування. 1024-вимірні вбудовування коштують $0,06 за мільйон токенів — у 2,2 рази дешевше, ніж OpenAI, та в 1,6 рази дешевше, ніж Cohere — при цьому вимагаючи в 3 рази менше векторного сховища, ніж 3072-вимірні вбудовування OpenAI.

OpenAI text-embedding-3-large пропонує найбільш перевірений варіант для продуктивних розгортань. Модель підтримує налаштовувані вихідні розмірності від 256 до 3072, дозволяючи компроміси вартості та сховища. За $0,13 за мільйон токенів OpenAI знаходиться посередині цінового спектра, забезпечуючи надійний час безвідмовної роботи та обширну документацію. Організації, які вже використовують API виведення OpenAI, часто стандартизують на їхніх вбудовуваннях для операційної простоти.

Cohere embed-v4 досяг найвищого балу MTEB (65,2) станом на листопад 2025 року, оптимізований спеціально для пошуку та отримання, а не для вбудовування загального призначення.¹² Вбудовування Cohere природно поєднуються з ререйнкером Cohere для двоетапних конвеєрів пошуку. Модель відзначається в мультимовних застосунках, підтримуючи понад 100 мов з сильним крослінгвальним пошуком.

Альтернативи з відкритим кодом, включаючи моделі BGE, E5 та GTE, дозволяють вбудовування власного хостингу в масштабі. Організації, що обробляють мільярди документів, часто розгортають ці моделі на внутрішній GPU-інфраструктурі для усунення витрат за токен. Самостійний хостинг вимагає управління оновленнями моделей, планування потужності та оптимізації виведення — компроміси, які мають сенс лише при значному масштабі.

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

Стратегії чанкування визначають точність пошуку

Чанкування документів створює атомарні одиниці, які система пошуку шукає. Вибір стратегії чанкування є одним з найбільш значущих інфраструктурних рішень, з потенційною варіацією повноти до 9% між найкращим та найгіршим підходами.¹³

Чанкування фіксованого розміру розділяє документи за заздалегідь визначеною кількістю токенів незалежно від структури контенту. Підхід добре працює для однорідних корпусів — новинних статей, описів продуктів або стандартизованих документів. Реалізація вимагає мінімальної складності, роблячи чанкування фіксованого розміру природною відправною точкою для прототипів. Більшість продуктивних систем використовують чанки з 400-512 токенами та перекриттями 50-100 токенів, балансуючи гранулярність пошуку з збереженням контексту.

Семантичне чанкування ділить документи на значущих межах — розривах абзаців, заголовках розділів або тематичних зсувах — зберігаючи зв'язні ідеї в кожному чанку. Реалізація використовує вбудовування речень для виявлення семантичних меж, розділяючи, коли подібність між сусідніми реченнями падає нижче порогу. Семантичне чанкування покращує повноту до 9% для наративного контенту, такого як документація, FAQ та розмовні дані.¹⁴ Підхід вимагає більше обчислень під час прийому та ретельного налаштування порогів подібності.

Рекурсивне чанкування застосовує ієрархічні правила розділення, спочатку намагаючись великі розділення (розриви розділів), потім поступово менші (розриви абзаців, розриви речень), поки чанки не досягнуть цільового розміру. RecursiveCharacterTextSplitter LangChain реалізує цей патерн, досягаючи сильної продуктивності для різних типів документів без налаштування під конкретний корпус. Рекурсивне чанкування балансує простоту реалізації з якістю пошуку, роблячи його рекомендацією за замовчуванням для нових систем.

Чанкування на рівні сторінки виникло з бенчмарків NVIDIA, що показали 0,648 точності з найнижчою дисперсією серед типів документів.¹⁵ Для структурованих документів, таких як звіти та статті, трактування кожної сторінки як чанку зберігає просторові зв'язки та перехресні посилання. Підходи на рівні сторінки погано працюють для документів без чітких меж сторінок (HTML, чат-логи, код), але відзначаються для корпусів з переважанням PDF.

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

[Контент скорочено для перекладу]