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

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

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

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

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

Добра структура документів — інвестиція. Заголовки, смислові блоки й метадані водночас допомагають людині, моделі в контексті й майбутньому пошуку. Ембединги й агенти надбудовуються над тим самим джерелом істини.

LLM не дорівнює базі знань

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

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

Варто тримати в голові чотири різні механізми:

Текст, токени й два види ембедингів

Токенізатор: рядок ще не зміст

Модель не отримує символи Unicode як людина. Спочатку токенізатор ріже рядок на шматки зі свого словника й замінює кожен шматок номером.

"Привіт, як справи?"
        ↓
Tokenizer
        ↓
["Привіт", ",", " як", " справи", "?"]
        ↓
[18432, 11, 927, 4812, 30]

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

Звідси три практичні наслідки. Вікно контексту рахують у токенах, не в словах. Ціна багатьох API теж від токенів. Нарізка документів «по 500 слів» погано стикується з тим, як модель потім побачить той самий текст.

Шар ембедингів усередині моделі

Номер токена сам по собі для нейромережі непотрібний. Його пропускають через таблицю ембедингів: кожній позиції словника відповідає вектор фіксованої довжини.

token ID
   ↓
embedding
   ↓
[0.12, -0.73, 0.44, ...]

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

Ембединги документів для пошуку

Друге значення з’являється в RAG. Окрему модель (часто меншу й іншу) просять згорнути фрагмент тексту в один вектор. Схожі за змістом абзаци мають лежати близько, навіть якщо не повторюють ті самі слова.

chunk
  ↓
embedding model
  ↓
[0.12, -0.03, 0.88, ...]

Плутанина починається, коли обидва сенси називають одним словом. Внутрішні ембединги токенів живуть усередині LLM і змінюються від шару до шару завдяки увазі. Ембединги документів живуть в індексі пошуку й порівнюються з вектором запитання. Корпоративний погляд на смисловий пошук, гібрид із точними ідентифікаторами й права доступу — у чому ембединги змінили пошук.

Як модель обробляє контекст і генерує відповідь

Механізм уваги на простому прикладі

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

кожен токен
   ↓
враховує інші токени контексту
   ↓
отримує більш інформоване представлення

Це ідея механізму уваги (self-attention): не словник синонімів, а зважений обмін інформацією всередині вікна. Математику тут можна не розгортати. Достатньо пам’ятати, що зміст токена залежить від сусідів і що далеко за межами вікна модель цих сусідів не бачить.

Практичний розбір маленького Transformer з навчанням на вузькому корпусі — в історії про модель на 6,4 млн параметрів. Для інженера застосунку важливіший висновок: якість відповіді впирається в те, що потрапило в послідовність, а не в магічне «розуміння файлів».

Один блок моделі — не «перекладач у цифри»

Спрощено один блок виглядає так:

Input
 ↓
Self-Attention
 ↓
Normalization
 ↓
Feed Forward Network
 ↓
Normalization
 ↓
Output

Модель — стос таких блоків. Поширена помилка: «Transformer перекладає текст у цифри». Ланцюжок інший:

1. токенізатор перетворює текст на ідентифікатори;
2. шар ембедингів перетворює ідентифікатори на вектори;
3. Transformer обробляє ці представлення в контексті;
4. вихідна голова рахує розподіл імовірностей наступного токена.

Цифри з’являються на кроці 2. Transformer працює вже з представленнями.

Авторегресія: токен за токеном

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

Я хочу випити
        ↓
воду 0.61
каву 0.18
чай  0.11
...
        ↓
воду

Я хочу випити воду
        ↓
зараз 0.31
і     0.27
...

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

Навчання змінює ваги, контекст — ні

Звідки береться «знання» в параметрах

Спрощена навчальна задача: за префіксом передбачити продовження.

"Париж — столиця ___"
             ↓
          "Франції"

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

Донавчання додатково підкручує ваги під формат, стиль або вузьку задачу. RAG цього не робить. Зведення рівнів — попереднє навчання, контрольоване донавчання, LoRA, інструменти — в уже згаданій мапі навчання. Тут потрібен один рядок:

Вікно контексту

У моделі скінченне вікно. У нього зазвичай намагаються вмістити системну інструкцію, історію діалогу, запитання, знайдені фрагменти й результати інструментів.

System instructions
+
Conversation
+
User question
+
Retrieved documents
+
Tool results
        ↓
       LLM

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

Роль моделі як інтерфейсу до знань, а не як корпоративної пам’яті, розібрана в чому з’явилися LLM.

Навіщо потрібен RAG

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

10 000 000 tokens документації
              ↓
           retrieval
              ↓
       5–20 релевантних chunks
              ↓
             LLM

RAG (Retrieval-Augmented Generation) — генерація, підсилена пошуком: знайти зовнішню інформацію, додати її в контекст, відповісти з опорою на знайдене. Це не «розумна модель, яка пам’ятає вікі». Це конвеєр із пошуку й генерації.

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

Документи як джерело істини

Фізично база знань для прототипу і для багатьох команд — звичайні файли.

knowledge/
├── README.md
├── python/
│   ├── functions.md
│   ├── objects.md
│   └── classes.md
├── ai/
│   ├── llm.md
│   ├── embeddings.md
│   └── rag.md
└── programming/
    └── algorithms.md

RAG не вимагає секретного формату. Підручник, внутрішні інструкції, цей блог, навички агента в SKILL.md — усе це може бути первинним джерелом. Зручність Markdown у тому, що його читає людина, його версіонує Git, із нього збирають сайт, і той самий текст можна нарізати для пошуку.

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

# Python Functions

    ## Definition
    ...
    ## Arguments
    ...
    ## Mutable arguments
    ...
    ## Common mistakes
    ...
    ## Related concepts
    - references
    - mutability
    - objects

Одне джерело істини може живити і сайт, і індекс:

                Markdown
                    │
          source of truth
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
        Website            RAG index
                              │
                     ┌────────┴────────┐
                     ↓                 ↓
                keyword search    embeddings
                                       ↓
                                  vector DB

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

Нарізка документів і метадані

Документ цілком рідко годиться і як одиниця пошуку, і як одиниця контексту. Його ріжуть на фрагменти.

document
   ↓
chunk 1
chunk 2
chunk 3
...

Погана нарізка рве думку посередині:

...can be modified after
creation. This means that when a list is...

Краще різати по смисловій межі й тягнути заголовок із собою:

    ## Mutable objects

Lists can be modified after creation...

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

Метадані дозволяють поєднувати зміст із фільтрами:

---
title: Змінні та незмінні об’єкти
topic: python
level: intermediate
concepts:
  - mutability
  - references
  - functions
---

Або в індексі:

{
  "source": "chapter-03.md",
  "section": "Mutable arguments",
  "topic": "python",
  "level": "intermediate"
}

Семантичний пошук знаходить близький зміст. Фільтри відсікають чужий розділ, рівень або джерело. Для точних імен API одного змісту замало. Експериментальний погляд на розбиття зі збереженням структури — в експериментах із нарізкою для RAG.

Пошук: вектори, гібрид і повторне ранжування

Пошук за близькістю векторів

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

Запитання:
"Чому функція може змінити список?"
             ↓
       embedding model
             ↓
        query vector
             ↓
       similarity search
             ↓
chunk A → 0.94
chunk B → 0.91
chunk C → 0.87
chunk D → 0.31

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

Векторна база — не сам RAG

Векторна база зберігає приблизно ідентифікатор, текст, вектор і метадані.

{
  "id": 1837,
  "text": "Lists are mutable...",
  "embedding": [0.12, -0.73, 0.44],
  "metadata": {
    "topic": "python",
    "section": "mutable objects",
    "source": "python.md"
  }
}

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

Гібридний пошук і повторне ранжування

Семантика погано ловить точні імена функцій, коди помилок, номери версій і рідкісні терміни. Їх краще шукати словами (класичний повнотекстовий пошук, BM25) і перетинати з векторною видачею, плюс фільтри за метаданими.

keyword search / BM25
        +
semantic search
        +
metadata filtering
        ↓
better retrieval

У продакшені часто не віддають моделі одразу «топ-5 із десяти тисяч». Спочатку дешевий пошук набирає десятки кандидатів, потім окрема модель повторно оцінює пару «запитання + фрагмент» і залишає найкращі.

10000 documents
       ↓
vector / hybrid search
       ↓
50 candidates
       ↓
reranker
       ↓
5 best chunks
       ↓
LLM

Як змішувати BM25 і вектори — в гібридному пошуку з reciprocal-rank fusion. Як тримати переранжування в бюджеті затримки й вартості — в переранжуванні в промисловому RAG.

Знайдене все одно лишається текстом у промпті:

SYSTEM:
Ти відповідаєш на запитання з Python.

CONTEXT:
Lists are mutable objects...
A function receives a reference to the list...

QUESTION:
Чому функція може змінити список?

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

Від файлового прототипу до агента

Простий пошук без векторної бази

Перший робочий контур може бути нудним і від того корисним:

Markdown
 ↓
INDEX.md
 ↓
metadata
 ↓
keyword / структурний пошук
 ↓
relevant chunks
 ↓
LLM

Зміст, пошук за словами, фільтр за topic у YAML, кілька файлів цілком у контекст, якщо база маленька. Так перевіряють якість вихідників до вибору Qdrant. RAG ≠ векторна база.

Навички як операційне знання

В агентах для розробки «база знань» часто виглядає як навичка: інструкція, процедури, приклади, інколи інструменти.

Skill
├── instructions
├── knowledge
├── procedures
├── tools
└── examples

На диску це знову Markdown:

skills/
├── SKILL.md
├── concepts/
│   ├── embeddings.md
│   ├── chunking.md
│   └── retrieval.md
├── procedures/
│   └── build-rag.md
└── examples/
    └── example.md

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

Інструменти й цикл агента

RAG дає знання. Інструменти дають дії: пошук, файлова система, база, калькулятор, HTTP API.

LLM
 ↓
вирішує, що потрібно зробити
 ↓
Tool
 ├── search
 ├── database
 ├── filesystem
 ├── calculator
 └── API
 ↓
результат
 ↓
LLM

Агент зв’язує міркування, пошук і інструменти в цикл. Це наступний шар оркестрації, а не «ще один індекс». Має сенс вмикати його, коли одного проходу пошуку не вистачає: треба зіставити нотатки релізу, код помилки й інструкцію. Для короткого довідкового запитання зайвий цикл лише збільшить затримку.

Поетапна еволюція

Має сенс рости шарами, а не починати з «платформи».

Етап 1 — Markdown. Тека knowledge/ з INDEX.md, поняттями, настановами й прикладами.

Етап 2 — смислові фрагменти. Заголовки, блоки, YAML, зв’язки між поняттями.

Етап 3 — простий пошук. Зміст, слова, фільтри за полями.

Етап 4 — ембединги. Фрагменти → модель ембедингів → наприклад embeddings.json.

Етап 5 — векторний пошук. З’являється база або розширення СУБД.

Етап 6 — гібрид і повторне ранжування. Слова + зміст + метадані + переранжування.

Етап 7 — агент. Інструменти й право моделі обирати наступну дію.

Кожен етап залишає попереднє джерело істини на місці. Змінюється спосіб знаходити, не спосіб зберігати зміст.

Часті помилки

Змішувати навчання і RAG: «заллємо PDF у донавчання, і модель запам’ятає регламент». Регламент зміниться в п’ятницю, ваги — ні.

Вважати Transformer «перекладачем тексту у вектори пошуку». Пошукові ембединги — окрема модель і окремий індекс.

Нарізати документи за числом символів без заголовків і зв’язків. Потім дивуватися, що модель цитує обрубок.

Ставити знак рівності між RAG і Qdrant. Без корпусу, нарізки, промпту й перевірки якості індекс непотрібний.

Покладатися лише на семантику там, де потрібні ім’я функції й номер версії.

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

Плутати агента з пошуком. Кілька викликів інструментів не створять відсутню сторінку в базі знань.

Чотири поняття, які варто повісити над монітором:

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

LLM уже «знає» мою документацію після навчання?

Ні. Вона знає статистику публічного й навчального корпусу на дату відсічки. Ваші внутрішні файли вона бачить лише якщо ви передали їх у контекст або знайшли через RAG.

Чи потрібна векторна база, щоб зробити RAG?

Ні. RAG — це пошук плюс генерація. Для маленької бази на Markdown досить змісту й пошуку за словами. Векторний індекс з’являється, коли семантична близькість і обсяг цього вимагають.

Чим ембединг токена відрізняється від ембедингу документа?

Перший — внутрішній вектор ідентифікатора в LLM, вхід для уваги. Другий — згортка фрагмента для пошуку схожого змісту. Їх рахують різні компоненти системи.

Чому семантичний пошук не знаходить ім’я функції?

Бо рідкісний ідентифікатор слабко пов’язаний зі «змістом абзацу» в просторі ембедингів. Для імен, кодів помилок і версій потрібен пошук за словами або гібрид.

Чи можна замінити RAG донавчанням на тих самих файлах?

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

Що класти в контекст: файл цілком чи фрагменти?

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

Навіщо повторне ранжування, якщо векторний пошук уже повернув топ-5?

Перший пошук оптимізований на швидкість і повноту кандидатів, не на тонку відповідність запитанню. Переранжування перечитує пару «запитання + текст» і часто піднімає потрібний абзац, який був на 12-му місці.

Чим навичка агента відрізняється від статті в базі знань?

Стаття відповідає «що це». Навичка відповідає «як робити в цьому репозиторії»: кроки, заборони, формат виходу, інструменти. Обидві можуть бути Markdown. Навичка ближча до процедури, стаття — до довідки.

Коли підключати агента з інструментами?

Коли одного пошуку мало: треба відкрити файл, викликати API, зіставити кілька джерел. Для запитання «який порт слухає сервіс» досить RAG або навіть одного фрагмента.

Чому модель вигадує, хоча RAG підключено?

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

Що почитати далі

Ця стаття — мапа механіки. Сусідні матеріали розбирають окремі шари глибше.

Архітектурний вибір «ваги чи зовнішні знання» — як навчають LLM. Навіщо моделі бути інтерфейсом, а не пам’яттю підприємства — чому з’явилися LLM і чому підприємствам потрібен RAG. Смисловий пошук у корпоративному контурі — чому ембединги важливі. Як довести конвеєр до продакшену — промислова інженерія RAG. Нарізка, гібрид і переранжування — експерименти з розбиттям, гібридний пошук, переранжування.

Висновок

Сучасна система ШІ — не «розумна модель», а кілька незалежних шарів: токенізація, представлення, Transformer, вікно контексту, база знань, пошук, інструменти й оркестрація. Добра база на Markdown може бути повноцінним джерелом істини. Ембединги, векторна база й переранжування не замінюють її: вони допомагають знаходити потрібне зі зростанням системи.

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