Надайте вашому LLM доступ до ваших даних без налаштування. RAG заповнює розрив між універсальними мовними моделями та знаннями, специфічними для домену.

Ви хочете створити AI-асистента, який відповідає на запитання щодо документів вашої організації — контрактів, політик, баз знань, документації продуктів, медичних записів. Налаштування LLM на ваших даних є дорогим, повільним і створює модель, яка заморожена на момент навчання. Вам потрібна архітектура, де LLM може отримувати доступ до актуальної, специфічної для домену інформації під час запиту, цитувати свої джерела та уникати вигадування фактів, яких немає у ваших документах. RAG (Retrieval-Augmented Generation) — це шлях до цього.
Explore more design patterns and system architectures
Наші архітектори можуть допомогти вам проектувати та будувати системи, використовуючи цей шаблон для ваших конкретних вимог.
Зв'яжіться з намиRAG доповнює генерацію LLM контекстом, отриманим з бази знань. Під час запиту система перетворює запитання користувача на векторне представлення, шукає семантично схожі фрагменти документів у векторній базі даних і включає найбільш релевантні фрагменти як контекст у запит LLM. Це закріплює відповідь моделі на реальних документах, дозволяє цитувати джерела та підтримує оновлюваність бази знань без повторного навчання. Продукційний RAG pipeline обробляє інгестіон (парсинг, розбиття, векторизація), пошук (векторний пошук, повторне ранжування, гібридний пошук) і генерацію (конструкція запиту, стрімінг, захисні механізми).
Архітектура має два пайплайни. Інгестіонний пайплайн обробляє документи через парсинг (PDF, DOCX, HTML екстракція), розбиття (семантичне або фіксованого розміру з перекриттям), векторизацію (через модель векторизації) та зберігання (векторна база даних + сховище документів). Запитний пайплайн бере запитання користувача, генерує вектор запиту, отримує кандидатні фрагменти з векторної бази даних, повторно ранжує їх за релевантністю, конструює запит з топовими фрагментами як контекст і стрімить відповідь LLM з цитуванням джерел.
text-embedding-3-large, Cohere embed-v4 або альтернативи з відкритим кодом (BGE, E5). Пакетна обробка для інгестіону, обробка одного запиту для пошуку| Шар | Технології |
|---|---|
| Парсинг документів | Unstructured, Apache Tika, LlamaParse, Docling, кастомний OCR (Tesseract, AWS Textract) |
| Векторизація | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Векторна база даних | Milvus, Pinecone, Qdrant, Weaviate, pgvector (для малих масштабів) |
| Пошук за ключовими словами | Elasticsearch, OpenSearch, PostgreSQL full-text search |
| Повторне ранжування | Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank |
| LLM | Claude (через AI Gateway), GPT-4, Gemini — незалежний від постачальника через AI SDK |
| Оркестрація | LangChain, LlamaIndex, або кастомний пайплайн (MW перевага для продукції) |
| Використовувати коли | Уникати коли |
|---|---|
| Користувачам потрібні відповіді, засновані на специфічних документах вашої організації | База знань < 50 сторінок — просто вставте її в системний запит |
| Документи часто оновлюються, і AI потрібна актуальна інформація | Вам потрібно, щоб модель навчилася новій навичці/поведінці, а не отримала доступ до нових фактів (налаштуйте замість цього) |
| Цитування джерел і аудит є вимогами (юридичні, відповідність, охорона здоров'я) | Запитання є чисто розмовними і не вимагають фактичного обґрунтування |
| Кілька груп користувачів потребують доступу до різних підмножин документів (RAG з фільтрацією дозволів) | Ви створюєте інструмент для творчого письма, де фактична точність не є метою |
MW будує RAG пайплайни від якості пошуку до LLM запиту — ми оцінюємо точність пошуку перед тим, як торкатися LLM запиту. Система RAG з посереднім пошуком і чудовим LLM видає впевнені, але неправильні відповіді. Наш стандартний пайплайн включає оцінювальну рамку пошуку: набір тестових запитів з відомими релевантними документами, виміряними за MRR@5 і NDCG@10. Ми ітеруємо над розбиттям, моделлю векторизації та повторним ранжуванням, доки метрики пошуку не досягнуть цільових порогів, перед оптимізацією генерації. Ми створили системи RAG для юридичного огляду документів, медичних баз знань і багатомовної підтримки клієнтів — і загальний урок полягає в тому, що якість пошуку становить 80% якості відповіді.
Пошук ембедингів легкий при 10K векторів. При 100M векторів із затримкою P99 менше 100 мс це проблема інфраструктури — і саме її вирішує цей шаблон.
MicrocosmWorks реалізує вирішення конфліктів у конвеєрах RAG за допомогою ранжування за авторитетністю джерела, зважування за новизною на основі часових міток та оцінки достовірності, яка оцінює, наскільки сильно кожен витягнутий уривок підтверджує своє твердження. Коли витягуються суперечливі уривки, наш конвеєр представляє відповідь з найвищим авторитетом, прозоро відображаючи розбіжності та посилання на джерела, щоб користувачі могли приймати обґрунтовані рішення. Ми також створюємо цикли зворотного зв'язку, де експерти в предметній області можуть позначати неправильні рішення, що покращує ранжування вилучення з часом.
MicrocosmWorks використовує контентно-орієнтоване фрагментування, яке застосовує різні стратегії на основі структури документа — семантичне розбиття абзаців для прози, фрагментування на рівні рядків або розділів для таблиць із збереженням контексту заголовків, та фрагментування на рівні функцій для коду з прикріпленими операторами import. Ми збагачуємо кожен фрагмент метаданими, включаючи назву документа, ієрархію розділів та тип вмісту, щоб на етапі Retrieval можна було застосовувати оцінку, специфічну для типу. Цей підхід постійно перевершує наївне фрагментування фіксованого розміру на 25-40% за показниками релевантності Retrieval у наших клієнтських проєктах.
MicrocosmWorks створює оціночні фреймворки, які тестують RAG-пайплайни за трьома вимірами: релевантність вибірки (чи знаходяться правильні фрагменти), достовірність відповіді (чи дійсно згенерована відповідь відображає отриманий контент) та повнота відповіді (чи повністю вона відповідає на запитання). Ми створюємо золоті тестові набори з доменними експертами, які включають запити з відомими відповідями, суперечливі граничні випадки та питання, що вимагають синтезу з декількох документів. Ця оцінка запускається автоматично в CI/CD, тому кожна зміна пайплайну порівнюється з базовими метриками якості перед розгортанням.
MicrocosmWorks обирає векторні бази даних на основі вашого масштабу, шаблону запитів та операційних вимог — Pinecone для керованої простоти, Weaviate для гібридного пошуку за ключовими словами та векторами, pgvector для команд, які вже інвестували в PostgreSQL, а Qdrant для високопродуктивних розгортань на власних серверах. При масштабах до 10 мільйонів векторів більшість варіантів забезпечують затримку менше 100 мс, але відмінності стають значними при сотнях мільйонів векторів, де тип індексу, квантування та стратегія шардування мають величезне значення. Ми проводимо бенчмаркінг ваших фактичних розмірностей вбудовувань та шаблонів запитів, порівнюючи їх з відібраними варіантами під час нашої фази архітектурного проектування.
MicrocosmWorks створює інкрементальні ingestion pipelines, які відстежують зміни в сховищах вихідних документів, re-chunk та re-embed лише змінені розділи, та оновлюють vector store без необхідності повного reindex. Ми впроваджуємо document fingerprinting, який виявляє зміни вмісту на рівні розділів, тому редагування одного абзацу не призводить до повторної обробки всього 200-сторінкового документа. Для клієнтів з real-time freshness requirements, ми додаємо live retrieval layer, який безпосередньо запитує вихідну систему на наявність нещодавно змінених документів і об'єднує ці результати з vector search hits.