Знання — огляд

Знання — це те, що агент знає про конкретний бізнес: каталог магазину, його правила, документація та FAQ, перетворені на запитуваний корпус, з якого агент дістає інформацію під час роботи. Це третя опора агента — поруч із мозком (міркування, в api) та руками (worker).

Ця сторінка — концептуальний вхід: для чого · яку технологію використовуємо · як масштабується. Деталі рівня рушія — у LightRAG.

Для чого потрібні знання

Місія — ШІ-агент для кожного магазину (спершу OpenCart). Агент корисний магазину лише тоді, коли справді знає цей магазин: кожен товар, ціну, категорію, правило доставки й повернення. Ці знання завеликі й заспецифічні для системного промпта, і вони постійно змінюються. Тому кожен агент має власну базу знань.

• Заземлення відповідей. Retrieval-augmented generation: агент відповідає на основі реальних фактів магазину, а не вигадує. «Чи є це в розмірі M дешевше €40?» — відповідається з каталогу, а не винаходиться.
• Каталог — ключова база. Для e-commerce основна база знань — це каталог товарів (синхронізується з магазину: OpenCart API через конектори агента), плюс правила, інструкції та документи підтримки.
• На кожного тенанта, на кожного агента. У кожної команди/магазину свої ізольовані знання; один агент ніколи не бачить даних іншого магазину.

Знання ≠ пам'ять

Два різні сховища, які часто плутають:

	Знання	Пам'ять (agent/memory)
Що зберігає	Курований доменний корпус — каталог, документи, правила	Епізодичні / діалогові факти про співрозмовника
Розмір	Великий (тисячі → мільйони чанків)	Маленький, на користувача
Джерело	Завантажені документи	Накопичується з розмов
Видобуток	Багаторежимний graph-RAG (нижче)	Пошук / пригадування
Де живе	Окремий сервіс LightRAG, доступ через MCP	Власне сховище агента

Знання — це бібліотека; пам'ять — щоденник. Ця сторінка лише про бібліотеку.

Яку технологію використовуємо

Знання = LightRAG (HKUDS), узятий з нуля (greenfield) і запущений як окремий сервіс, до якого агент звертається через MCP — знання не вшиті в мозок, вони підключувані.

LightRAG — це рушій graph-RAG: він розбиває документи на чанки, за допомогою LLM видобуває сутності та зв'язки у граф знань і обслуговує по ньому багаторежимний видобуток.

Чому graph-RAG, а не звичайний векторний пошук:

• Звичайний векторний RAG знаходить найближчі чанки — чудово для «який термін повернення?», але слабко для запитань через увесь каталог («які бренди в нас із безкоштовною доставкою?»).
• Граф фіксує зв'язки — товар ↔ категорія ↔ бренд ↔ правило — тому агент може відповідати на тематичні / глобальні запитання, а не лише на пошук найближчих сусідів.

Як це вбудовано в архітектуру:

Елемент	Роль
Сервіс LightRAG (Python)	Володіє завантаженням, графом і видобутком. Працює на Hetzner k8s.
Слайс agent/knowledge (NestJS, L5)	Тонкий шлюз: CRUD баз, подача документів, проксіювання видобутку. ingestion/query/graph згортаються всередині LightRAG, а не як наші під-слайси.
MCP	Як дістаються знання — шлюз виставляє видобуток як @Tool, тому це підключувана здатність, яку викликають мозок і worker через MCP, а не частина мозку.
Postgres (pgvector + Apache AGE)	Один бекенд під KV + вектор + граф. Self-hosted на Hetzner (managed Postgres блокує AGE). Уже перевірено в Ranch.

Режими видобутку (LightRAG): naive (чистий вектор), local (навколо сутностей), global (навколо тем/зв'язків), hybrid (обидва). Агент обирає режим під запитання; дешеві запитання йдуть дешевим шляхом.

І шлях без індексу — RLM. LightRAG відповідає з індексу, збудованого заздалегідь; RLM відповідає по сирих даних без інгестії, рекурсивно переглядаючи їх і платячи в момент запиту. Правило: питатимуть багато разів → індексуй; разове питання чи свіже завантаження → RLM.

Доступ через MCP — і мозком, і worker'ом

Увесь доступ до знань іде через MCP. agent/knowledge виставляє видобуток як MCP-@Tool через setup/mcp, а api хостить ендпоінт. agent/knowledge — єдине, що звертається до LightRAG напряму; будь-який споживач ходить через MCP.

Оскільки це MCP-інструмент, одну й ту саму базу можуть запитувати два клієнти — не лише мозок:

Клієнт	Коли запитує	Як
Мозок (orchestrator в api)	у ході LLM-циклу, щоб заземлити відповідь	викликає MCP-інструмент у процесі
Worker (руки)	під час задачі, щоб дістати факти каталогу під час багатокрокової роботи	викликає той самий MCP-ендпоінт зі своїм короткоживучим токеном сесії — без заходу через мозок

Обидва б'ють в один і той самий ендпоінт з однаковою ізоляцією workspace (виведена з автентифікованого агента/команди), тож worker ніколи не дотягнеться до бази іншого тенанта. Це модель pluggable-over-MCP: мозок лишається маленьким, а будь-який авторизований клієнт — мозок чи worker — підключається до здатності знань однаково.

Навіщо взагалі окремий сервіс: LightRAG — Python, а api — NestJS. Замість переписування graph-RAG ми запускаємо бібліотеку в серверному режимі й тримаємо agent/knowledge тонким проксі. Див. LightRAG — деплой, референс Ranch та будову пулу.

Як це масштабується

Масштабування знань на тисячі магазинів тримається на трьох ідеях.

1. Мультитенантність через workspaces — природний шардинг

1 workspace = 1 база знань. Параметр workspace у LightRAG дає логічну ізоляцію всередині спільного сховища; сервіс тримає пул екземплярів LightRAG за ключем workspace (лінива ініціалізація

• витіснення за простоєм) над одним бекендом.

Саме це робить «тисячі магазинів» посильними: це не один гігантський граф, а багато дрібних графів на магазин. База кожного магазину лишається маленькою та швидкою; система масштабується за кількістю баз, що шардиться природно. Безпека: agent/knowledge виводить workspace з автентифікованої команди/бази — клієнт ніколи не передає свій workspace (порожній/підмінений workspace = витік між тенантами).

2. Стіна — це завантаження, а не зберігання

Дорога частина graph-RAG — індексація: видобуток сутностей і зв'язків LLM на кожен чанк. На мільйонах файлів це велика вартість у токенах і багато часу — це властивість підходу, а не питання тюнінгу. Тому завантаження побудоване як конвеєр, а не запит:

• Асинхронно / через чергу в runtime/task (BullMQ) — ніколи не inline на шляху API.
• Інкрементально — переіндексувати лише змінене (дельти каталогу), а не всю базу.
• З лімітом швидкості та бюджетом токенів — обмежена витрата LLM на базу.
• Доступний дешевий шлях — пропонувати naive vector-RAG і використовувати граф лише там, де він окупається.

3. Бекенд за формою навантаження

Бекенд сховища йде за формою навантаження, а не за єдиним дефолтом:

Форма навантаження	Бекенд
Багато дрібних баз (випадок e-commerce — тисячі магазинів)	Єдиний Postgres (pgvector + AGE) — дані застосунку + KV + вектор + граф в одній БД
Мільйони чанків в одній базі	pgvector напружується (~кілька M), AGE не перевірений на такому розмірі → Neo4j + виділена векторна БД (Qdrant / Milvus)

WARNING

LightRAG молодий (2024). Проженіть бенчмарк на цільовому масштабі до вибору бекенда і зафіксуйте версію — схема зберігання змінюється між релізами.

Дивіться також

• LightRAG — рушій: деплой, бекенд сховища, пул workspace, референс Ranch.
• RLM — шлях без індексу: разові питання, холодний старт бази знань.
• Агент — склад — де knowledge у групі агента і як він доступний через MCP.
• Модель рантайму — як видобуток вписується в хід.
• Інфра — ресурси — сервіс LightRAG та його Postgres на Hetzner.
• Місія та ринок — чому каталог-як-знання і є комерційний ключ.