# RAG пояснено: походження і основи

Коли-небудь шукали "подорожене керівництво" і нічого не знайшли, навіть якщо є стаття про "виставлення у виробництво"? RAG (Retrival- Augmented Generation) вирішує це за допомогою розуміння значення, а не лише ключових слів. Ця серія показує вам, як виникає RAG, як вона працює під каптуром і як будувати системи виробництва. Від семантичного пошуку до AI- A& з applicationsall з прикладами роботи C #.

<datetime class="hidden">2025-11-22T09:00</datetime>

<!-- category -- AI, RAG, Machine Learning, Semantic Search, LLM, AI-Article -->
# Вступ

**Навігація:** Це перша частина серії "ПАГ" (Retrieval-Augaled Generation):

- **Частина 1: Походження та основи РАГ** (Ця стаття) Що це за вбудовування, чому вони мають значення?
- [Частина 2: Архітектура і внутрішні властивості RAG](/blog/rag-architecture) - Розпакування, перевірка, векторні бази даних
- [Частина 3: ПСГ на практиці](/blog/rag-practical-applications) - Будівельна повна система РАГ.
- [Частина 4а: Реалізація ONNX і Qdrant](/blog/semantic-search-with-onnx-and-qdrant) - Дружня з ЦП база семантики
- [Частина 4b: Семантичний пошук в дії](/blog/semantic-search-in-action) - Типагед, гібридні елементи пошуку і компоненти інтерфейсу користувача.
- [Частина 5: Гібридний пошук і автоматичне інексування](/blog/rag-hybrid-search-and-indexing) - Шаблони інтеграції виробництва
- [Частина 6: GraphRAG](/blog/graphrag-knowledge-graphs-for-rag) - Графіки знань для розуміння рівня корпусу

RAG (Retrival-Augmented Generation) було розроблено для того, щоб зробити AI розумніше ♫ LLM доступ до інформації, якою вони не були навчені. Але ось що цікаво: технологія відкриває можливості далеко за межами ШІ chatbots.

**Подвійна природа.** RAG може допомогти клієнтам (кращого пошуку, точніших відповідей з посиланнями) або використати їх (рекомендації щодо маніпуляції, приховування негативних відгуків, трансплантації контенту). Різниця полягає не в технології, а в семантичному пошуку, що допомагає користувачам знайти те, що їм насправді потрібно?

**Ось вам правда про РСГ:** Звучить лячно. Вбудовування векторів? Моделі перетворення? Кешів KV? Але, як і у всьому іншому програмному забезпеченні, йдеться лише про розуміння того, як це працює. Вам не потрібно знати математику за архітектурою трансформатора більше, ніж вам потрібно зрозуміти збір для написання C#.

**RAG у три кроки:**

1. Перетворювати текст на числа (ембрідд)
2. Знайти подібні числа (пошук вектора)
3. Використовувати те, що ви знайшли (плоди або подачу для LLM)

Решта - це реалізація деталей.

У цій серії статей показано, як будувати системи RAG з кодом, що працює на C#. Без ручної обробки. Без припущень. Тільки елементи і спосіб їх розташування.

**Чого ви навчитеся з цієї серії статей:**

- **Частина 1 (ця стаття)**: Як з'явився РСГ і чому це важливо
- **Частина 2**: Повна технічна архітектура і внутрішні елементи LLM
- **Частина 3**: Будувати справжні системи з прикладами коду

Пізніше я також покажу вам, як будувати цілі системи RAP, зокрема:

- [Дружній до ЦП семантичний пошук з вбудовуваннями ONX](/blog/semantic-search-with-onnx-and-qdrant) (частина 4)
- [Власні векторні бази даних з Qdrant](/blog/semantic-search-with-onnx-and-qdrant) (частина 4)
- [Пошук і автоматичне індексування Гібридів](/blog/rag-hybrid-search-and-indexing) (частина 5)

[TOC]

# Що таке РАГ?

**Покоління, отримане за умови отримання:** Знайдіть відповідну інформацію і скористайтеся нею.

```mermaid
flowchart LR
    A[User Question] --> B[Retrieve Relevant Info]
    B --> C[Retrieved Documents/Context]
    C --> D[Generate Response]
    A --> D
    D --> E[Grounded, Accurate Answer]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px
```

**Без RAG:** Користувач запитує → LLM здогадається з пам' яті → може галюцинувати

**З RAG:** Користувач запитує → Знайти відповідні документи → Відповіді LLM за допомогою цих документів → на основі

```csharp
// Without RAG: Hope the LLM knows
var answer = await llm.GenerateAsync("How do I deploy Docker?");
// Risk: Might make up outdated or wrong steps

// With RAG: Give it the docs
var relevantDocs = await vectorSearch.FindSimilar("How do I deploy Docker?");
var context = string.Join("\n", relevantDocs.Select(d => d.Text));
var answer = await llm.GenerateAsync($"Context: {context}\n\nQuestion: How do I deploy Docker?");
// Result: Answer based on YOUR actual Docker deployment docs
```

**Прозорість ключа:** Відокремлювати сховище знань (пошук) від логіки (LM). Оновити ваші документи, пошук залишиться поточним. Не потрібно повторення.

# Звідки походить РАГ?

Розуміння цієї історії допомагає вам зрозуміти, чому RAG сконструйований так, як він є, і які проблеми він вирішує.

## Традиційний пошук (до 2010- х)

**Пошук за ключовими словами:**

- **TF- IDF**: частота терміну × обернена частота документа - звичайні слова мають менше значення
- **BM25**: Пробілістичний рейтинг - все ще є базовим рядком пошуку за ключовими словами
- **Невиразне збігання**:
  - **Soundex**: Фонетичний алгоритм (" Smith " відповідає " Smythe ")
  - **Відстань до Lvenshtein**: Змінити відстань (кількість вставок/ deletations/ substritutions)
  - **Н- ГрамсCity in Quebec Canada**: Послідовності символів/ слів для часткового пошуку

**Проблема:** Відповідні *символи*, не *означає*Пошук "матиме оркестрування" і ви не знайдете "Дукер Рурм," якщо не побачите точних слів. Вони могли працювати з помилками, але не семантичними.

## Відповідь на початкове запитання (2010- ті)

**Watson (IBM, 2011):**

- Об' єднане отримання з основами правил
- Виграв Jeopardy! але потрібен величезний ручний інженер знань
- Залежно від ключового слова, все ще сильно покладатися на відповідність

**Читання прикладів розуміння:**

- Можна видобути відповіді з наданих уривків
- Але спершу треба було дати їм правильний прохід.
- Без семантичних пошуків, щоб знайти цей уривок

## Революція глибокого навчання (2017+)

**Перетворення (2017):** "[Увага - це все, що вам потрібно](https://arxiv.org/abs/1706.03762)"

- Нервові мережі, які можуть розуміти контекст
- Основа для всього, що буде далі

**BERT (2008):**

- Контекстне розуміння мови
- "Bank" означає різні речі в "річному банку" проти "відсмоктувачі"
- Може генерувати вбудовування, яке засвоєне значення

**GPT- 2/ 3 (209/2020):**

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

**Відображення вектора за дзижчею:**

- Текст → істотні числа у високовимірному просторі
- Подібне значення → сусідні вектори
- Це уможливило семантичний пошук

**BART (Facebook AI, жовтень 2019):**

- Двонапрямний і авторегресивний трансформатор Майка Льюїса та ін.
- Комбінований кодувальник схожий на BERT з кодувальником у стилі GPT
- Автокодувальник Denoising тренується за допомогою пошкодженого тексту, а потім відбудовує його
- Чудово для завдань створення текстових текстів і розуміння
- Сталася основою RAG

**M2M- 100 (Facebook AI, жовтень 2020 року):**

- Перша багато-багато- багато- багато- багато- багато- багато- багато- багато- багато- багато модель перекладу
- Прямий переклад між 100 мовами без англійського повороту
- 2200 напрямків мови (10x більше, ніж попередні моделі)
- Показані трансформатори могли впоратися з масивними перехресними завданнями.

**Приклад реального світу:** Мій [Інструмент для перекладу нейронних машин](https://github.com/scottgal/mostlyucid-nmt) Використовуйте BART як модель зворотного перекладу, якщо основні послуги недоступні, показуючи, як ці моделі трансформаторів стали практичними будівельними блоками для виробничих систем.

## Народження сучасного РАГ (травень 2020 року)

Похмура газета " (англ.).[Покоління, присвячене отриманню завдань NLP для інтеграції знань](https://arxiv.org/abs/2005.11401)" Патрік Льюїс et al. (Дослідження Facebook AI) формально представив РАГ, будуючи прямо на BART:

**Що вони об'єднали:**

- Динамічне отримання проходу (DPR) - вивчені векторні представлення, а не ключові слова
- Генератор BART - модель seq2seq 2019
- Архітектура від початку до кінця - отримання і створення разом

**Результати:** RAG-системи вийшли з ладу набагато більші моделі у завданнях, що впливають на пізнання, і водночас були ефективнішими та актуальнішими. Ви могли б оновити базу знань без повторного тренування моделі.

## Чому RAG вилучив (2023-Premission)

ChatGPT, GPT- 4 та Клод зробили RAG важливим:

1. **Проблема з галюцинацією** Реактивні відповіді в реальних документах.
2. **Обрізання знань** - LLMs тренированы на 2021 данных не знают о 2024 событиях. RAG использует наши документы.
3. **Особисті дані** - ЛЛМС не может получить доступ к внутренним документам вашей компании.
4. **Вартість** - Fine- tuning LLM є дорогим ($10K- 100K+). RAG є дешевою (розмір + вбудовування).
5. **З' єднання з поясненням** - RAG може посилатися на джерела, роблячи його придатним для перевірки і достовірним.

**Сьогодні (2024-25):** RAG - це фактичний стандарт для систем штучного інтелекту виробництва, які потребують точності та перевірки.

# Як працює RAG: великий малюнок

Перед тим, як зануритися глибоко в технічні деталі (які ми розглянемо у частині 2), давайте зрозуміємо робочий процес високого рівня.

## Три фази

Система RAG працює у трьох фазах:

### Індексування фази 1: (налаштовування одного часу)

```mermaid
flowchart LR
    A[Your Documents] --> B[Split into Chunks]
    B --> C[Generate Embeddings]
    C --> D[Store in Vector DB]

    style C stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px
```

**Що відбувається:**

1. Візьміть вашу базу знань (дописи, дописи блогів, підручники)
2. Розділити на потрібні шматки (абзаци, розділи)
3. Перетворити кожен шматок на векторне вбудовування (масив чисел)
4. Зберігати вектори у базі даних, оптимізовані для пошуку подібності

**Концепція ключа:** Подібні значення утворюють подібні вектори, так що " місткість докера " і "вміщаюча платформа" стають ближчими разом у векторному просторі.

### Фаза 2: отримання (кожен запит)

```mermaid
flowchart LR
    A[User Question] --> B[Generate Query Embedding]
    B --> C[Search Vector DB]
    C --> D[Top K Most Similar Chunks]

    style B stroke:#f9f,stroke-width:2px
    style C stroke:#bbf,stroke-width:2px
```

**Що відбувається:**

1. Питання, яке задає користувач
2. Перетворити питання на вектор (те саме, що використовується для індексування)
3. Знайти найбільш подібні вектори у базі даних
4. Повертає верхні частини K, які відповідають одна одній (зазвичай, 3- 10)

**Чому це працює:** "Як я можу розкривати контейнери?" (запит) семантично подібний до шматків про докерів, навіть якщо вони відрізняються.

### Покоління фази 3: (кожен запит)

```mermaid
flowchart TB
    A[User Question] --> B[Build Prompt]
    C[Retrieved Context] --> B
    B --> D[LLM]
    D --> E[Generated Answer with Citations]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px
```

**Що відбувається:**

1. Задати питання користувача
2. Отримати отримані фрагменти контексту
3. Побудувати запрошення: "Задано цей контекст..., відповісти на це питання...
4. Відіслати у LLM для створення
5. LLM дає відповідь, яку засновано у вказаному контексті

**Магія:** LLM не може галюцинувати факти, яких немає в контексті. Він може лише синтезувати і пояснювати те, що надано.

## Простий приклад

Давайте прослідкуємо запит через систему:

**Запит користувача:** "Як я буду користуватися Docker Compose?"

**Крок 1 - Отримання:**

```
Query embedding: [0.234, -0.891, 0.567, ...]

Search vector DB for similar embeddings...

Retrieved chunks:
1. "Docker Compose is a tool for defining multi-container applications..." (similarity: 0.92)
2. "To use Docker Compose, create a docker-compose.yml file..." (similarity: 0.87)
3. "The docker-compose up command starts all services..." (similarity: 0.83)
```

**Крок 2 - Створення:**

```
Prompt to LLM:
"Context:
[1] Docker Compose is a tool for defining multi-container applications...
[2] To use Docker Compose, create a docker-compose.yml file...
[3] The docker-compose up command starts all services...

Question: How do I use Docker Compose?

Answer (use the context above):"

LLM Response:
"To use Docker Compose [1], start by creating a docker-compose.yml file [2] that
defines your services. Then run 'docker-compose up' to start all services [3]..."
```

**Результат:** Точна відповідь з неявними посиланнями з вашої документації.

# RAG проти. Інші підходи

Щоб зрозуміти, коли використовувати RAG (і якщо ні), потрібно порівняти його з варіантами.

## RAG проти Fine- Tuning

Дівка-ТунхіллCity in Hawaii USA (optional, probably does not need a translation)
|--------|-----|-------------|
| **Оновлення знань** ♪  (просто оновлює базу знань) * * * 
| **Вартість** ♫  далі (сторінка + Вбудовування) } Висока (час тренування GPU)
| **Точність** дріт у виходах з джерел ♪Can chopucinate}
| **Налаштування** Перед нами - центральна модель.
| **З' єднання з поясненням** ♪GAGE (скан = джерельні джерела)} − низ (чорний квадратик) ♪
| **Найкраще для** }Мід-інтентивні/медіативна адаптація}

**Коли використовувати Коротке налаштування:**

- Вам потрібна модель, щоб вивчити специфічність **стиль** або **формат**
- У вас великий, чистий набір даних
- Вам потрібна модель для внутрішньої структури **шаблони**, не факти
- Приклад: записування GPT, як Шекспір.

**При використанні RAG:**

- Вам потрібно **фактична точність** з цитатами
- Часті зміни на основі ваших знань
- У вас є приватні/патентовані дані
- Вартість і простота мають значення
- Приклад: підтримка клієнта chatbot (документи моєї компанії змінюють щотижня)

**Можете об'єднати обох?** Так! Умовне налаштування стилю, RAG з фактами.

## RAG проти. Довгі контекстні вікна

У сучасних LLM можна бачити величезні контекстні вікна (GPT- 4: 128K жетонів, Claw: 200K- маркерів). Чому б просто не викинути всі ваші документи у контекст?

**Проблеми з довгим контекстом:**

1. **Вартість**: Балки початку з позначками - 10- 100 для кожного запиту додається швидко
2. **Затримка**: Обробка 100K елементів потребує часу
3. **Загублені в середині**: LLM намагається використовувати інформацію в середині довгих контекстів
4. **Яскравість**: Релевантна інформація похована під шумом.
5. **Практичні обмеження**: Ви не можете вмістити всі документи компанії в контекст

**Коли довгий контекст має сенс:**

- Один великий документ (наприклад, аналіз контракту)
- Все має відношення (не потрібно фільтрувати)
- Вартість - це не справа.
- Низька гучність запиту

**Коли RAG має сенс:**

- Велика база знань (мільйони документів)
- Потрібно знайти відповідну підмножину
- Висока гучність запиту (ціну вартість)
- Оновлення знань у режимі реального часу

**Найкраща вправа:** Скористайтеся RAG для вибору найвідповіднішого вмісту, а потім скористайтеся довгостроковим контекстом для цієї підмножини.

## RAG проти Asking з прикладами

Вибір декількох результатів (наведення прикладів з командного рядка) є простим базовим рядком.

**Запит прикладу:**

```
Examples:
Q: What is Docker?
A: Docker is a containerization platform...

Q: How does Kubernetes work?
A: Kubernetes orchestrates containers...

Q: What is my new question?
A: [LLM generates answer]
```

**Обмеження:**

- Обмежено тим, що вписується в контекстне вікно
- Ручне визначення прикладів
- Не масштабується до великих основ знань
- Без семантичних пошуків - вам слід обрати приклади вручну

**Покращення RAG:**

- Автоматично шукати найкращі приклади (за допомогою пошуку подібності)
- Масштабує до необмежених прикладів (лише верхній K відісланий до LLM)
- Пристосовує до запиту (різні запити отримують різні приклади)

Ви можете думати про РАГ як про "автоматизовану незначну кількість збігів на шкалі."

## Hybrid Search: RAG + Традиційний пошук

Ви можете комбінувати RAG з традиційним повнотекстовим пошуком за допомогою Reciprocal Rank Fusion (RRF).

**Чому гібрид?**

- **Семантичний пошук**: Great for концептуальний збіг ("Правила помилки" шукає "диспетчерська адміністрація")
- **Пошук ключових слів**: Чудово для точних термінів (" Docker Compose "), " Entity Framework ")
- **Гібридstar name**: Найкращий з обох світів

```csharp
public async Task<List<SearchResult>> HybridSearchAsync(string query)
{
    // Run both searches in parallel
    var semanticTask = SemanticSearchAsync(query, limit: 20);
    var keywordTask = KeywordSearchAsync(query, limit: 20);

    await Task.WhenAll(semanticTask, keywordTask);

    var semanticResults = await semanticTask;
    var keywordResults = await keywordTask;

    // Combine using Reciprocal Rank Fusion
    return ApplyRRF(semanticResults, keywordResults);
}

private List<SearchResult> ApplyRRF(
    List<SearchResult> list1,
    List<SearchResult> list2,
    int k = 60)
{
    var scores = new Dictionary<string, double>();

    // Score from first list
    for (int i = 0; i < list1.Count; i++)
    {
        var id = list1[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Score from second list
    for (int i = 0; i < list2.Count; i++)
    {
        var id = list2[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Merge and sort by combined score
    var allResults = list1.Concat(list2)
        .GroupBy(r => r.Id)
        .Select(g => g.First())
        .OrderByDescending(r => scores[r.Id])
        .ToList();

    return allResults;
}
```

# Чому це важливо?

Тепер, коли ви розумієте, що таке РАГ, звідки він походить, і як він співвідноситься з альтернативами, ось чому це важливо:

**1. демократизація комп' ютерного гравця**

- Тобі не потрібен бюджет на суму $100К.
- Вам не потрібна команда інженерів ML
- Будь- який розробник може будувати системи RAG з існуючими інструментами

**Практична точність**

- Галюцинація - це # 1 проблема з LLM в виробництві
- RAG розв'язує цю проблему шляхом створення відповідей у реальних документах
- Цитування роблять його придатним для перевірки і достовірним

**3. Завжди вгору- на- Date**

- Традиційний комп' ютер: потяг один раз, знання заморожено
- RAG: оновіть ваші документи, оновлення знань миттєво
- Критична для швидкого пересування (технологічних, новинних, регулювань)

**4) Конфіденційність і контроль**

- Ваші дані залишаються у вашій інфраструктурі
- Можна запускати повністю локально (локальні вбудовування + локальний LLM + локальний вектор DB)
- Не надіслано жодних даних для OpenAI або інших постачальників даних у мережі

**5. Коштовний рівень**

- Зберігання дешеве (пенні на ГБ)
- Вбудовування є дешевим (полом у відсотках на 1000 документів)
- Набагато дешевше за дрібні або довгі контекстні вікна

**6. Універсальні програми**

- Семантичний пошук (не потрібен LLM!)
- Система Q&A з цитатамиName
- Рекомендація вмісту
- Помічники запису
- Керування знаннями
- Допоміжні засоби документації
- Помічники досліджень

# Заключення: від історії до впровадження

Ми дослідили еволюцію РАГ:

- **До 2010- х**: Пошук за ключовими словами (символи, без значення)
- **2010- й@ item: inlistbox**: Читання розуміння (потрібне для правильного проходу)
- **2017-2020**: Перетворення і вбудовування (означає → вектори)
- **2020**: Сучасне RAG (з' єднання + створення)
- **2023- пред' єм@ item: inlistbox**: Стандартний стандарт виробництва (талуляція + вартість + конфіденційність)

**Ключові думки з частини 1:**

- Розсіювання RAG **зберігання знань** (версія ДБ) з **логічне міркування** (LLM)
- Вона розв'язує галюцинаційну проблему, ґрунтуючи відповіді на реальних документах.
- Він дешевший і гнучкіший, ніж дрібний.
- Це працює краще, ніж довгий контекст для великих джерел знань.
- По суті, це "автомативна невелика кількість пострілів в масштабі"

**Психічна модель трьох кроків:**

1. Перетворювати текст на числа (ембрідд)
2. Знайти подібні числа (пошук вектора)
3. Використовувати те, що ви знайшли (show або flow to LLM)

Все інше оптимізоване.

# Продовжити до частини 2: архітектура і внутрішні властивості

Тепер ви розумієте **що** RAG - це, **чому** це має значення, і **where** Але як він працює під капотом?

Вхід **[Частина 2: Архітектура і внутрішні властивості RAG](/blog/rag-architecture)**Ми занурюємось глибоко в технічні деталі.

**Повнофункціональний канал RUG:**

- Фаза 1. Індексування тексту, стратегія видобування шматків, створення вбудовування, зберігання векторів)
- Фаза 2: отримання (випадкові вбудовування, дані подібності, перевищення)
- Покоління фази 3: (побудова промпта, параметри LLM, кінцева обробка)

**Внутрішні елементи LLM:**

- Що таке маркери і чому вони важливі для РАГ
- Кеш KV: Як LLM запам' ятовувати контекст
- Контекстні вікна і стратегії керування ключами
- Оптимізація RAG для ефективності та вартості ключа

**Технічні занурення:**

- Векторні бази даних і алгоритми пошуку подібностей
- Вмонтовані моделі та нормалізація
- Розшифрування стратегій, що зберігають контекст
- Практичні приклади коду у C#

**[Продовжити до частини 2: архітектура і внутрішні властивості →](/blog/rag-architecture)**

Після другої частини Ви будете готові до створення реальних систем, вирішення спільних викликів, та дослідження таких складних технологій, як HyDE, мультиquery RAG, і контекстуального стиснення.

## Ресурси

**Фундаментальні папери:**

- [Покоління, присвячене отриманню завдань NLP для інтеграції знань](https://arxiv.org/abs/2005.11401) - Оригінальний папір RAG
- [Одержимий шлях для відповіді на питання з відкритим доменом](https://arxiv.org/abs/2004.04906) DPR (ретривна база)
- [Увага - це все, що вам потрібно](https://arxiv.org/abs/1706.03762) - Трансформатори (основа осередку)

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

- [Як працює небіблійний переклад](/blog/how-neural-machine-translation-works) - Розуміння моделей ШІ за вбудовуваннями

**Далі у цій серії:**

- [Частина 2: Архітектура і внутрішні властивості RAG](/blog/rag-architecture) - Технічні глибоководні пірнання.
- [Частина 3: ПСГ на практиці](/blog/rag-practical-applications) - Будівництво реальних систем.

**[Продовжити до частини 2 →](/blog/rag-architecture)**