Знания — обзор

Знания — это то, что агент знает о конкретном бизнесе: каталог магазина, его правила, документация и 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.
• Миссия и рынок — почему каталог-как-знания и есть коммерческий ключ.