Шар за шаром: створення справжнього каналу отримання даних RAG для штучних інтелектуальних агентів

Заміна агента для пошуку іграшок на справжню систему RAG — це гарна нагода сповільнитися та поетапно виконувати роботу. У багатоагентній корпоративній платформі RetrievalAgent спочатку працював на навмисно простій локальній реалізації. Цього вистачило для підтвердження архітектури, але для продакшн-використання потрібні справжні документи, ембеддинги, векторне зберігання та семантичний пошук. Цільовий процес передбачає обробку документів через їхнє завантаження, розділення на частини та створення ембеддингів у ChromaDB, а потім — семантичний пошук, роботу RetrievalAgent та функціонування всієї платформи.

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

Компоненти системи RAG

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

Source Documents
       ↓
Document Ingestion
       ↓
    Chunking
       ↓
   Embeddings
       ↓
 Vector Storage
       ↓
Semantic Search
       ↓
Retrieved Context
       ↓
Retrieval Agent

Можливо одночасне створення кожного компонента, але це ускладнює визначення причин несправностей. Якщо якість отримання даних погана, у чому проблема? Це може бути обробка документів, розділення на частини, створення ембеддингів, зберігання векторів, логіка запитів, метадані чи інтеграція з агентом. Визначення чіткої відповідальності, контракту та меж тестування для кожного рівня допомагає належним чином відповісти на ці запитання. Робочий ритм полягає у створенні, тестуванні, впровадженні та перевірці в CI, підтримці стабільної роботи, а потім продовженні роботи.

Почніть з контракту даних

Перш ніж використовувати ембеддинги чи ChromaDB, першим кроком є створення контракту даних. У потоці обробки необхідно розрізняти два поняття: SourceDocument та DocumentChunk.

SourceDocument — це початкове джерело знань до його розділення. Це може бути файл PDF, DOCX або TXT, внутрішня документація, фінансові звіти, корпоративні правила, технічні посібники чи контент бази знань. Його концептуальна структура виглядає так:

SourceDocument
 ├── document_id
 ├── content
 ├── source
 └── metadata

Кожен оригінальний документ отримує таким чином стабільну ідентичність усередині архітектури пошуку.

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

DocumentChunk
 ├── chunk_id
 ├── document_id
 ├── content
 ├── source
 ├── chunk_index
 └── metadata

Відношення між ними є один-до-багатьох:

SourceDocument
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Chunk 0       Chunk 1      Chunk 2
          │            │            │
          └────────────┼────────────┘
                       ↓
                 Same document_id
                  + source metadata

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

Чому принцип відстежуваності вбудований з самого початку

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

Original Document
       ↓
SourceDocument
       ↓
DocumentChunk
       ↓
Embedding
       ↓
Vector Record
       ↓
Semantic Search
       ↓
RetrievedDocument
       ↓
Original Source

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

Тестування контрактів

Після визначення моделей автоматизовані тести охоплюють як SourceDocument, так і DocumentChunk. Вони перевіряють, чи правильно створюються моделі, та чи ключові поля функціонують так, як очікується, включаючи ідентифікатори документів, деталі джерела, вміст та індекси частин.

Це може здатися незначною віхою, проте ці моделі ляжуть в основу всього процесу отримання даних:

Document Models
      ↓
   Chunking
      ↓
  Embeddings
      ↓
   ChromaDB
      ↓
  Retrieval
      ↓
    Agents

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

Ще одним свідомим рішенням було збереження цього етапу без зовнішніх залежностей. Тут не відбувається жодних запитів до OpenAI чи ChromaDB, а тести перевіряють лише умови контрактів документа. Таким чином швидка система CI залишається детерміністичною.

Code Change
     ↓
Local Fast Tests
     ↓
Commit
     ↓
Push to GitHub
     ↓
GitHub Actions
     ↓
Clean CI Environment
     ↓
Fast Unit Tests
     ↓
CI PASSED ✅

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

Повний план розвитку

Контракт для документів — це лише перший шар. Ось вся потрібна архітектура:

Enterprise Documents
        │
        ▼
     Ingestion
        │
        ▼
      Chunking
        │
        ▼
     Embeddings
        │
        ▼
     ChromaDB
   Vector Storage
        │
        ▼
 Semantic Retrieval
        │
        ▼
 Retrieved Context
        │
        ▼
  RetrievalAgent
        │
        ▼
Multi-Agent Platform

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

Далі йде чанкінг

Наступним компонентом є Chunking Service, який перетворює SourceDocument на кілька об’єктів DocumentChunk.

SourceDocument
      │
      ▼
ChunkingService
      │
      ├── DocumentChunk 0
      ├── DocumentChunk 1
      ├── DocumentChunk 2
      └── DocumentChunk N

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

Ембеддинги та зберігання

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

DocumentChunk
      ↓
Embedding Service
      ↓
Embedding Model
      ↓
Vector Representation

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

DocumentChunk
      ↓
EmbeddingService
      ↓
Embedding Provider
      ↓
Vector

Заміна моделі ембеддингу пізніше майже не вплине на решту архітектури RAG.

Після створення ембеддингів вони зберігаються у постійному векторному сховищі. Для локальної розробки постійний клієнт ChromaDB може зберігати індексовані дані між перезапусками додатку.

DocumentChunk
      +
Embedding
      +
Metadata
      ↓
   ChromaDB
      ↓
Persistent Vector Collection

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

Vector Record
 ├── chunk_id
 ├── embedding
 ├── content
 ├── document_id
 ├── source
 ├── chunk_index
 └── metadata

Це дозволяє процесу пошуку повертати змістовний контекст документа, а не лише схожі вектори.

Запитування

Після наповнення бази даних система може здійснювати семантичний пошук. Шлях запиту є таким:

User Query
    ↓
Query Embedding
    ↓
ChromaDB Similarity Search
    ↓
Top-K Relevant Chunks
    ↓
Scores + Metadata
    ↓
Retrieved Context

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

Поновлення з’єднання агента

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

AgentRequest
     ↓
RetrievalAgent
     ↓
RetrievalService
     ↓
Relevant Documents
     ↓
Structured RetrievalResult

За лаштунками RetrievalService реалізація стає значно складнішою:

RetrievalService
      ↓
Query Embedding
      ↓
ChromaDB
      ↓
Semantic Search
      ↓
Ranking
      ↓
Retrieved Context

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

Початковий агент працював із локальними даними, а архітектура виглядала приблизно так:

RetrievalAgent
      ↓
RetrievalService
      ↓
Local Documents

Тепер реалізація може розвиватися у бік чогось багатшого:

RetrievalAgent
      ↓
RetrievalService
      ↓
Semantic Retrieval
      ↓
ChromaDB
      ↓
Embedded Enterprise Documents

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

Інтеграція з платформою

Конвеєр RAG існує не сам по собі. Його мета — забезпечувати ґрунтовні корпоративні знання для більшої багатоагентної системи.

User
                          │
                          ▼
                    Supervisor Agent
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                    Execution Plan
                          │
                          ▼
                     Agent Registry
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
       RetrievalAgent  ResearchAgent AnalysisAgent
             │
             ▼
      RetrievalService
             │
             ▼
         RAG Pipeline
             │
             ▼
      Relevant Context
             │
             ▼
       Downstream Agents

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

Один урок варто підкреслити: RAG — це не просто „додайте векторну базу даних“. Ефективна архітектура пошуку вимагає багатьох рішень:

• Укладання контрактів на документи та їх надходження
• Розділення на частини та створення ембеддингів
• Зберігання векторів та метаданих
• Семантичний пошук та ранжування
• Відстежуваність джерел
• Інтеграція агентів
• Тестування та можливості моніторингу

Векторна база даних — це лише один компонент у значно більшій системі пошуку.

Навмисно повторюваний патерн

Інженерний цикл для досягнення цієї мети навмисно є повторюваним:

Build One Layer
      ↓
Add Unit Tests
      ↓
Run Fast Suite
      ↓
Push to GitHub
      ↓
CI Validates
      ↓
Keep Green
      ↓
Build Next Layer

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

Перший етап справжнього процесу завершено: контракти SourceDocument та DocumentChunk, тести для обох моделей та успішна швидка перевірка в рамках CI. Далі йде план розвитку:

1. Document Contract             ✅ COMPLETE
          ↓
2. Chunking Service              ← NEXT
          ↓
3. Embedding Service
          ↓
4. ChromaDB Integration
          ↓
5. Semantic Retrieval
          ↓
6. RetrievalAgent Integration
          ↓
7. End-to-End RAG Pipeline

Кожен шар реалізується та тестується окремо перед тим, як переходити далі.

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

Перший агент для пошуку показав, що архітектура агентів функціонує. Тепер метою є заміна його тимчасового механізму пошуку на справжню інфраструктуру, перехід від локального пошуку до системи обробки документів, розділення на частини, створення ембеддингів, зберігання векторів, семантичного пошуку та, нарешті, агента з підтримкою RAG. Оскільки агент залежить від абстракції сервісу, а не безпосередньо від ChromaDB, усе це можливо без необхідності перепроєктування платформи для кількох агентів.

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

Створюється можливість пошуку інформації, яка є частиною корпоративної багатоагентної платформи, а не одноразової демонстрації технології RAG. У цій системі Супервайзер координує процеси, Реєстр визначає наявні можливості, спеціалізовані агенти виконують завдання, технологія RAG забезпечує обґрунтовані знання, тести захищають правильну роботу системи, інструменти CI контролюють кожну зміну, а механізми спостережливості відстежують роботу у продакшені. Метод завжди однаковий: створюється новий шар, він тестується, впроваджується, підтримується стабільна робота інструментів CI, після чого починається розробка наступного шару.