§ P41 — BI-тренды · AI-аналитика

RAG на корпоративной базе знаний: почему демки умирают в проде

Retrieval · Чанкинг · Цитаты · РФ-контур

«Сделаем AI-ассистента, который знает всё про компанию» — звучит на каждой второй встрече по цифровизации. Собрать демо на выходных реально. Довести до прода, где им пользуются и ему доверяют, — совсем другая история. Разбираем RAG без хайпа: как устроен, где ломается и что меняет российский контур 2026.

Сценарий знакомый: сотрудник спрашивает бота «какой лимит командировочных по новому регламенту?» — и получает точный ответ со ссылкой на пункт документа, а не пересказ из интернета. За этим стоит RAG — Retrieval-Augmented Generation, генерация с опорой на поиск. Подход, на котором сегодня держится почти вся корпоративная AI-аналитика по документам.

Технология не новая и принципиально несложная. Сложно другое — заставить её работать на тысячах реальных документов так, чтобы ответам можно было верить. Именно здесь обрывается путь большинства пилотов.

Что такое RAG простыми словами

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

Грубая аналогия — экзамен с открытой книгой. Студент (модель) не зубрит весь учебник наизусть. Ему дают найти нужную страницу и ответить по ней. Качество ответа зависит не столько от студента, сколько от того, ту ли страницу нашли.

Ключевая мысль всей статьи: в RAG качество ответа определяется качеством поиска, а не «умом» нейросети. Подали в контекст правильный фрагмент — будет точный ответ с цитатой. Подали мусор — модель уверенно перескажет мусор.

Почему RAG, а не дообучение или просто чат-бот

У задачи «ассистент по документам» три пути, и два из них — тупиковые для большинства компаний:

Сырой чат-бот без ваших данных. Не знает внутренних регламентов в принципе. На вопрос про вашу политику скидок сочинит правдоподобную выдумку.
Дообучение (fine-tuning) на документах. Дорого, требует переобучения при каждом изменении регламента, не даёт ссылок на источник и всё равно склонно путать факты. Для базы знаний, которая меняется еженедельно, — мимо.
RAG. Обновляется добавлением документа в индекс, а не переобучением. Даёт цитаты — ответ можно проверить. Дешевле и быстрее внедряется.

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

Как это устроено: пайплайн по шагам

Под капотом — конвейер из двух частей. Сначала однократная подготовка, потом — обработка каждого вопроса.

Парсинг и чанкинг. Документы (PDF, DOCX, вики, письма) разбирают на текст и режут на куски — чанки. От того, как нарезать, зависит почти всё.
Эмбеддинги. Каждый чанк превращают в вектор — числовое представление смысла. Похожие по смыслу куски оказываются рядом в векторном пространстве.
Векторное хранилище. Векторы складывают в специальную базу (pgvector, Qdrant, Weaviate и подобные) для быстрого поиска по близости.
Поиск + реранкинг. На вопрос находят ближайшие чанки, затем отдельная модель-реранкер переупорядочивает их по релевантности — это резко поднимает качество.
Генерация с цитатами. Найденные фрагменты подают модели вместе с вопросом и инструкцией «отвечай только по этим источникам и ставь ссылки».

Почему 95% демок разваливаются в проде

Демо на десяти PDF и проде на десяти тысячах документов — разные задачи. Вот где чаще всего рвётся:

Наивный чанкинг. Документ режут по N символов — и таблица разрывается пополам, пункт регламента отделяется от условия. Поиск находит кусок без контекста, ответ выходит кривой.
Нет реранкинга. Векторный поиск возвращает «похожее», но не всегда «правильное». Без переупорядочивания в контекст попадает не тот фрагмент.
Нет оценки качества. Систему выкатывают без набора эталонных вопросов и метрик. «Вроде отвечает» — это не приёмка. Без eval вы не знаете, врёт бот в 2% случаев или в 40%.
Галлюцинированные цитаты. Модель ссылается на пункт, которого в источнике нет. Без проверки, что цитата реально содержится во фрагменте, доверие к системе рушится после первого такого случая.
Протухший индекс. Регламент обновили, а индекс — нет. Бот уверенно отвечает по прошлогодней версии.
Сканы и таблицы. Половина корпоративных документов — сканы и сложные таблицы. Без нормального парсинга (OCR, разбор структуры) они просто не попадают в поиск.
Игнор прав доступа. Бот показывает рядовому сотруднику кусок документа «для топ-менеджмента». Права на документы должны соблюдаться на этапе поиска, а не «потом».

Типичная картина на старте: пилот собрали за неделю, на демо он бодро отвечает на заранее заготовленные вопросы. В бой выпустили — и через день жалобы: «бот сослался на отменённый приказ», «не нашёл то, что лежит в первом же файле». Разбор почти всегда упирается в три вещи — чанкинг рвал таблицы, индекс не обновлялся, и никто не собрал набор вопросов, чтобы измерить, насколько часто бот ошибается. Это не проблема нейросети. Это проблема инженерии вокруг неё.

Российская специфика 2026

В РФ-контуре к общим граблям добавляются свои условия:

Закрытый контур. Корпоративные документы редко разрешено гонять через зарубежные облака. На практике это on-prem или российское облако: локальные модели и эмбеддинги, развёрнутые в своём периметре.
Локализация качества. Англоязычные эмбеддинги хуже ловят смысл русского текста, особенно юридического и отраслевого. Нужны модели, заточенные под русский, иначе поиск промахивается.
Российские модели. GigaChat, YandexGPT и открытые локальные модели закрывают генерацию без выхода за периметр. Выбор — это компромисс между качеством, стоимостью и требованиями безопасности.
152-ФЗ и режим тайны. Персональные данные и коммерческая тайна в документах диктуют, где физически живёт индекс и кто к нему имеет доступ.

RAG и структурированные данные: не путать задачи

Частая ошибка — пытаться ответить через RAG на вопрос про цифры: «какая выручка по югу за квартал?». RAG работает с неструктурированным текстом — регламентами, договорами, перепиской, вики. Числа живут в другом месте — в базах и BI-модели.

Граница простая. «Что написано в политике скидок?» — это RAG по документам. «Сколько мы дали скидок за март?» — это запрос к семантическому слою и BI. Путать их — значит получать выдуманные цифры из текста и недостающий контекст из таблиц.

Зрелое решение совмещает оба контура: RAG отвечает по документам, а на вопросы про показатели маршрутизирует запрос в семантическую модель. Почему числам нужен именно семантический слой, а не сырая база — разбираем в статье «Семантический слой: фундамент, без которого AI-аналитика врёт».

С чего начать, чтобы не попасть в те самые 95%

Узкий домен. Не «вся база знаний компании», а один понятный участок: HR-регламенты или техдокументация. На нём проще отладить качество.
Набор эталонных вопросов. 50–100 реальных вопросов с правильными ответами и источниками — это ваша приёмка. Без него RAG не запускают.
Метрики. Хотя бы две — нашли ли нужный документ (recall) и отвечает ли модель строго по нему, без отсебятины (faithfulness).
Права и обновление с первого дня. Кто что видит и как часто переиндексируется база — это не «потом», а часть архитектуры.

RAG — не магия и не модная игрушка. Это инженерная задача про качество поиска, чистоту документов и честную оценку. Компании, у которых уже есть порядок в данных — налаженные интеграции и хранилище, — проходят этот путь быстрее: у них меньше хаоса на входе. С хаоса всё и начинается, и им же всё заканчивается, если за инженерию не взяться всерьёз.