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

Базовая модель знает то, что было в её обучающем корпусе на момент тренировки.

Она не знает вашего регламента отгрузки, истории конкретной сделки, схемы вашей 1С и того, что вы поменяли в продукте на прошлой неделе.

Рациональный ЛПР задаёт первый вопрос так: как дать модели эти знания, чтобы это не превратилось в дорогой чёрный ящик.

Этот вопрос чаще всего сводят к одному слову — RAG.

Само сужение и есть источник путаницы. RAG отвечает на «как извлекать знание в момент запроса». llm-wiki — на «как структурировать знание заранее».

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

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

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

Пять подходов с честными плюсами и минусами,

RAG (retrieval-augmented generation) работает так.

Корпус заранее режут на фрагменты (чанки) и превращают каждый в вектор — числовое представление смысла.

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

Модель отвечает, опираясь на эту подобранную справку, и может сослаться на источник.

Главный практический плюс, который чаще всего и есть настоящая причина брать RAG, — минимизация токенов.

Вместо того чтобы запихивать весь корпус на сто тысяч страниц в каждый запрос (что упрётся в лимит окна и в стоимость), вы тащите только релевантный срез под конкретный вопрос.

Корпус может быть огромным — в контекст летит несколько фрагментов.

Остальные сильные стороны вытекают из этого.

Мгновенное обновление: поменялся документ — переиндексировали его, и ответы идут по новой версии, веса модели трогать не надо. Масштаб: корпус растёт независимо от модели, вы работаете срезом на каждый запрос. Аудируемость: ответ можно привязать к источнику — видно, откуда взялся факт; для регламентов, договоров и комплаенса это часто решающий аргумент.

Узкое место называется честно: качество ретрива.

Если поиск вытащил не те чанки, модель уверенно ответит по неверной справке. RAG слаб на «глобальных» вопросах вида «какие сквозные темы во всех протоколах за год» — там, где ответ не лежит в нескольких соседних фрагментах, а размазан по всему корпусу. И это инфраструктура: векторное хранилище, индексация, пайплайн обновления.

Как устроен RAG в деталях и как мы его собираем — на странице инструмента RAG.

Если в данных есть персональные данные и работа идёт под 152-ФЗ, между источником и моделью ставится обезличивание — это уровень LLM Gateway.

Это про то, как знание написано до того, как его кто-то начнёт искать.

Идея простая и старая, как хорошая инженерная документация.

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

Агент не ищет случайные фрагменты на каждый вопрос — он читает карту проекта и сводки, как читал бы её новый сотрудник: сверху вниз, от оглавления к детали.

Отсюда принцип «No RAG» в продукте Sloy: для структурированной корпоративной памяти — «что сейчас с проектом», какие решения приняты, кто за что отвечает — чтение карты надёжнее и объяснимее, чем выуживание чанков по сходству.

Это не «RAG это плохо», а выбор инструмента под слой; почему для этого слоя работает «No RAG» — на странице Sloy.

Слои совмещаются: RAG поверх хорошо структурированного llm-wiki извлекает из порядка, а не из хаоса. О том, как переносимый контекст оформляется в AGENTS.md, skills и через MCP, — в наших AI-принципах.

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

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

Ответа нет ни в одном отдельном чанке — он собирается из связей между многими фрагментами.

Поиск по сходству вытащит несколько похожих кусков, но не увидит структуру, которая их соединяет.

Из корпуса заранее извлекаются сущности (люди, проекты, документы, события), связи между ними и сообщества — кластеры плотно связанных сущностей.

Знание становится не списком фрагментов, а сетью узлов и рёбер.

На вопрос система отвечает не одним поиском, а обходом графа: идёт по связям, собирает релевантное сообщество, использует его саммари.

Глобальные и многошаговые вопросы: там, где ответ — это путь через несколько сущностей, граф проходит этот путь явно. Объяснимость: виден сам путь рассуждения — какие узлы и связи привели к ответу; это не «модель так решила», а трассируемая цепочка.

Сводки сообществ: на вопрос «что в целом» система отвечает по саммари кластеров, а не по случайной выборке чанков.

Цена честная: граф дороже строить. Сущности, связи и сообщества обычно выделяет сама LLM, проходя по корпусу, — это вычислительная работа до того, как задан первый вопрос.

Если ваши вопросы в основном локальные («найди пункт в этом договоре»), граф — избыточная инженерия: обычный RAG дешевле и достаточно.

Граф окупается, когда ценность именно в связях и в многошаговых обходах.

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

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

Что это открывает. Локально, офлайн, на простом железе: маленькая дообученная модель может работать на скромном GPU, на edge-устройстве, в air-gap-контуре без интернета — знание уже внутри, внешний поиск не нужен.

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

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

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

Нужен качественный датасет: дообучение учится на том, что вы дали, грязные данные дают грязное поведение, а чистого размеченного датасета у большинства команд нет, и его сборка часто дороже самой задачи.

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

Это карта, а не учебник по дообучению.

Канонический разбор — когда оно действительно оправдано, как готовить датасет, чем отличается LoRA от полного тюнинга — в отдельной статье Дообучение моделей: короткий гайд.

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

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

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

Граница тоже простая: токены и окно. In-context жжёт токены на каждый вызов — знание едет в контекст каждый раз заново.

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

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

У рационального ЛПР вопрос не «что технологичнее», а «где граница, после которой стоит платить за более сложный контур».

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

Облако с RAG или llm-wiki достаточно, когда знание часто меняется, нужны ссылки и аудит, корпус большой, а чистого датасета для обучения нет (у большинства команд его и нет).

Дообучение оправдано, когда нужны приватность и air-gap, офлайн и edge, когда объём вызовов высок и доминирует стоимость контекста или когда стабильный узкий домен требует закрепить специфичное поведение. И

Один вопрос — пять разных ответов, и они не конкуренты, а слои. RAG отвечает на «как извлекать», llm-wiki — на «как структурировать», граф — на «как связать», дообучение — на «как вшить», in-context — «когда можно просто вставить».

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

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

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

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

Стабильный домен с офлайном и приватностью — дообучение. А когда хочется «всё сразу» — почти всегда правильный ответ это два слоя, а не один на всё.

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

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

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