Как дать LLM ваши знания: RAG, llm-wiki, граф, дообучение

01.07.2026 Базовая модель знает то, что было в её обучающем корпусе на момент тренировки. Она не знает вашего регламента отгрузки, истории конкретной сделки, схемы вашей 1С и того, что вы поменяли в продукте на прошлой неделе. Рациональный ЛПР задаёт первый вопрос так: как дать модели эти знания, чтобы это не превратилось в дорогой чёрный ящик.

llm-wiki - на «как структурировать знание заранее».

Граф знаний - на «как связать знание для многошаговых вопросов».

Дообучение - на «как вшить знание и поведение в веса модели».

Это разные слои, и их регулярно ставят в один ряд как конкурентов, хотя половина из них спокойно работает вместе. Эта статья - карта. Пять подходов с честными плюсами и минусами,

Знание заранее компилируется в связный набор коротких markdown-представлений: корневой README отвечает на вопрос «какой файл открыть первым»

Обычный RAG отвечает на локальные вопросы: ответ лежит в одном-двух фрагментах, их находишь - и готово.

Но есть класс вопросов, на которых поиск по сходству буксует структурно. «Как связаны вот этот контракт, вот этот инцидент и вот это решение совета?»

Если ваши вопросы в основном локальные («найди пункт в этом договоре»

), граф - избыточная инженерия: обычный RAG дешевле и достаточно. Граф окупается, когда ценность именно в связях и в многошаговых обходах.

Все предыдущие подходы оставляют модель замороженной и меняют то, что ей подают на вход.

Дообучение (fine-tuning) меняет саму модель: на ваших данных корректируются её веса, и нужное знание или поведение становится частью модели.

Низкая задержка и экономия контекста: не надо на каждый вызов вставлять справку в промпт; для сценариев с высоким объёмом вызовов, где стоимость контекста доминирует, это меняет экономику.

Стиль и поведение: дообучение хорошо вшивает не столько факты, сколько манеру - формат ответа, тон, специфичный для домена способ рассуждать; эту сторону RAG не закрывает.

И честные минусы, которые делают дообучение плохим дефолтом для «просто дать модели наши документы».

Знание замораживается: вшитый факт устаревает вместе с моделью - поменялась цена, регламент, версия документа - придётся переучивать; RAG в этом месте просто переиндексирует. Нужен качественный датасет: дообучение учится на том, что вы дали, грязные данные дают грязное поведение, а чистого размеченного датасета у большинства команд нет, и его сборка часто дороже самой задачи.

Дорого и долго учить, тяжело обновить один факт, есть риск забывания и переобучения, а аудировать «почему модель так ответила»

Самый простой способ упомянуть последним - потому что он часто и есть правильный, когда знание маленькое. In-context - это положить знание прямо в промпт: вставить регламент, пример, справочную таблицу текстом перед вопросом.

Никакой инфраструктуры, никакого хранилища, никакого обучения.

Для небольшого стабильного знания под конкретную задачу это самый дешёвый по усилиям вариант.

Растёт объём - упираетесь в лимит окна и в стоимость.

Как только знание перестаёт помещаться комфортно или начинает повторяться в каждом вызове, пора смотреть на RAG (извлекать только нужное) или на дообучение (вшить, чтобы не возить).

, что снимает ложный выбор: часто правильный ответ - оба слоя.

Дообучить небольшую модель под домен и поведение, а свежие факты подавать через RAG или держать в llm-wiki - тогда модель «умеет» нужное и одновременно не устаревает на каждом изменении документа. KT.Team собирает такой контур малой ai-native командой за короткие итерации, а не большим интеграторским проектом: разбираем свойства вашего знания, считаем экономику под конфигурацию и отдаём отчуждаемый результат - open-source-first стек, который вы забираете себе, без vendor lock-in.

Про экономику говорим прямо и не врём цифрами: стоимость токенов разных моделей и сравнение по бюджету - в отдельном блоге-источнике цифр; конкретные суммы за токены живут там, а не размазаны по статьям.

Для собственного контура (on-prem, своё железо) экономику определяет утилизация GPU, а не цена токена: простаивающее железо удорожает контур, высокая утилизация - наоборот; счёт зависит от конфигурации и считается в калькуляторе, а не по выдуманной сумме за «сервер в год».

Путаница начинается там, где их выстраивают в один ряд как соперников; ясность - там, где видишь, что они про разные вещи и часто работают вместе.

Практический ориентир остаётся тем же, что и в любой инженерии: не платить за сложность, которая не нужна.

Маленькое стабильное знание - in-context.

Большой меняющийся корпус с аудитом - RAG.

Подключение данных к модели на уровне инструментов - через MCP.

Если задача не «выбрать слой», а быстро поднять у руководителей рабочую интуицию и первый прототип агента - отдельный формат AI Agent Sprint для руководителей.

Соседние статьи кластера: Дообучение моделей: короткий гайд - если внизу дерева вы попали в «дообучение»; Линза Карпатого: понимание против исполнения - чем «модель понимает» отличается от «модель исполняет» и почему это меняет выбор слоя.