RAG-система собирается из восьми частей: подготовка документов, разбивка их на куски, индекс для поиска, сам поиск, сборка запроса для модели, модель, проверка ответа и обновление базы. Верный ответ получается только тогда, когда сработали все восемь, а любое слабое звено даёт уверенный ответ по неверным данным — и со стороны это выглядит как «нейросеть глупая», хотя сломалось что-то одно.
Ниже — что даёт каждая часть, как она отказывает на практике и что про неё спрашивать у подрядчика. Сама идея подхода разобрана отдельно — что такое RAG и зачем он нужен; здесь только устройство.
Суть: почему это цепочка, а не «подключить нейросеть» #
Заказчик видит одну строку ввода и ответ в ней. Поэтому и смета читается странно: за что платить, если модель написана кем-то другим и берётся в аренду.
Платят не за модель. Модель — самая дешёвая и заменяемая часть цепочки: её меняют за день, не трогая остальное. Деньги уходят на то, что до неё и после неё: разобрать документы, нарезать их так, чтобы смысл не рвался, настроить поиск, проверить ответ и договориться, кто всё это обновляет через полгода. В предложении подрядчика сразу видно, какие части пропущены, — обычно подготовка документов и обновление базы, то есть ровно те, где нет ничего технически интересного.
Разбор по частям #
Подготовка документов: что попадает в базу #
Первый шаг не технический, а управленческий: кто-то решает, что регламент от марта действует, а январский отменён и в базу не идёт. Пока это не решено, собирать нечего; какие материалы нужны и в каком виде — в статье про базу знаний.
Как ломается. Устаревший документ — самый частый и самый дорогой отказ. Система не отличает действующий приказ от отменённого: если в базе оба, ответ пойдёт по тому, который лучше подошёл к формулировке. Сотрудник увидит ссылку на документ и сделает по отменённому порядку.
Что спросить у подрядчика. Как помечается, что документ больше не действует, и что происходит с его копией внутри системы.
Разбивка на куски: где режем текст #
Целиком документы в модель не отправляют: в запрос влезает ограниченный объём текста. Поэтому база хранит не файлы, а куски по несколько абзацев — чтобы в ответ попал нужный раздел, а не весь регламент.
Как ломается. Кусок разорван посередине таблицы. Тарифы разрезаны между строкой «Москва» и её ценой: цена в куске есть, а к какому городу относится — не видно, и модель приписывает её не тому региону.
Что спросить. Как режутся таблицы и документы с вложенными пунктами и попадает ли в каждый кусок заголовок раздела, из которого он взят.
Индекс: как куски становятся находимыми #
Каждый кусок заранее переводится в набор чисел, запрос сотрудника — так же, и система сравнивает числа, а не слова: «можно ли уйти в отпуск в декабре» находит пункт про перенос отпуска, где слова «декабрь» нет. Подробнее — в статье про векторную базу и поиск по смыслу. Рядом живёт словесный индекс — для номеров и артикулов.
Как ломается. Индекс отстал от базы: документ загрузили, а посчитать не успели или сервис перевода текста в числа отдавал ошибку. Отказ тихий — ошибок нет, ответы приходят, просто часть документов для системы не существует.
Что спросить. Как видно, что проиндексировано не всё, и что происходит с индексом при смене модели векторизации.
Поиск: как из тысячи кусков выбираются пять #
Поиск возвращает несколько самых подходящих кусков. Это единственное место, где решается, какие документы попадут в ответ: чего он не нашёл, того для модели нет.
Как ломается. Поиск нашёл не то — по двум противоположным причинам. Смысловой промахивается на точных обозначениях: артикул или номер договора для него набор символов без смысла. Словесный промахивается на омонимах: «отпуск» найдётся и в регламенте отпуска товара со склада, и в правилах отпусков сотрудников. Поэтому ищут двумя способами. Второй отказ — нашёл верно, но мало: порядок в регламенте, суммы в приложении, а в ответ попал только регламент.
Что спросить. Ищет ли система по точным номерам и артикулам и сколько кусков уходит в модель на один ответ.
Сборка запроса: что именно уходит в модель #
Найденные куски, вопрос, история диалога и инструкция складываются в один текст. Инструкция — это правила: отвечать только по приложенным документам, ставить ссылку на источник, при нехватке данных передавать вопрос человеку.
Как ломается. В запрос кладут тридцать кусков «на всякий случай»: модель теряет середину и отвечает по первому подходящему, а цена ответа растёт. Мягкая инструкция даёт другой эффект — модель дополняет ответ общими знаниями из интернета, и в рассказе про компанию появляется чужая практика.
Что спросить. Можно ли по конкретному ответу посмотреть, какие куски нашлись и что ушло в модель. Без такого журнала разбор ошибки — гадание.
Модель: кто формулирует ответ #
Модель здесь не источник знаний, а переводчик: берёт куски документов и собирает из них связный ответ. Знания живут в базе, поэтому смена модели не исправит плохую базу.
Как ломается. Модель ответила мимо: пересказала соседний пункт, смешала два условия, добавила обобщение, которого в документе нет. Отказ попроще — провайдер не ответил или упёрся в лимит; для сотрудника это то же самое: он спросил и не получил ответа.
Что спросить. Что происходит, когда модель недоступна, и можно ли сменить модель, не пересобирая базу.
Проверка ответа: последний барьер #
Готовый ответ сверяется с кусками, на которых он построен: есть ли в них названные цифры и существует ли упомянутая ссылка. Это защита от случая, когда текст звучит уверенно и содержит неправду, — почему модели выдумывают разобрано отдельно.
Как ломается. Чаще всего проверки просто нет: ответ уходит как есть. Бывает и перегиб — проверка нашла одну неверную ссылку и выбросила весь ответ, человек вместо девяти верных строк видит «не нашёл информации».
Что спросить. Что система делает с ответом, не прошедшим проверку: выбрасывает, правит или помечает сомнительное место.
Обновление базы: часть, которую забывают в смете #
Документы меняются каждый месяц. Если изменения никто не переносит в базу, система превращается в архив: отвечает уверенно и по прошлогоднему порядку.
Как ломается. База не обновляется. Отказ мягкий и дорогой: ассистент работает, ошибки появляются редко и по важным вопросам. Хватает одного неверного ответа про деньги, чтобы отдел вернулся к «спрошу у Иры», — а доверие возвращать дороже, чем строить его в первый раз.
Что спросить. Кто обновляет базу, по какому событию — вручную, по расписанию или автоматически из источника — и сколько это стоит в месяц.
Как понять, какая часть сломалась #
Разбор начинается со ссылки на документ в ответе: без неё любой неверный ответ выглядит одинаково.
- Ссылка ведёт на верный документ, ответ в нём есть, а ответ неверный. Виновата сборка запроса или модель: кусок пришёл, но пересказан неточно.
- Ссылка ведёт не на тот документ. Виноват поиск, а если нужный документ не находится ни по одному вопросу — индекс.
- Документ тот, но устарел. Виновата подготовка или обновление, техника тут ни при чём.
- Система отвечает «не нашёл», хотя документ есть. Либо поиск не дотянулся до формулировки, либо ответ не прошёл проверку и был выброшен.
Ссылка на источник — не вежливость, а инструмент обслуживания: система без ссылок не ремонтируется.
Как это устроено у нас #
Поиск гибридный. По смыслу и по словам одновременно, результаты сводятся вместе. Это закрывает и омонимы, и точные артикулы с номерами приказов.
Модель выбирается цепочкой. GigaChat, YandexGPT, зарубежная модель через ProxyAPI, модель внутри сети компании: не ответила одна — запрос уходит дальше.
Проверка фактов стоит перед выдачей. Выдуманная ссылка правится, а не выбрасывает весь ответ. Чего нет в документах, ассистент передаёт человеку.
В каждом ответе ссылка на документ-источник. Сотрудник видит, откуда взят ответ, и ошибку заметно сразу.
Данные остаются в России. Серверы в России, персональные данные обезличиваются до отправки в модель. Если документы не должны покидать сеть компании — модель разворачивается внутри неё.
Обновление прописано заранее. Базу обновляем мы по договору сопровождения или сотрудник заказчика — тогда учим его на внедрении. Варианта, при котором база обновляется сама, не бывает.
Порядок работ, сроки и состав этапов — на странице услуги корпоративная база знаний.
Сколько стоит и от чего зависит #
Цены на 23 октября 2026 года.
| Что | Сколько и за какой срок |
|---|---|
| Аудит: карта документов, с какого отдела начать, оценка срока и цены | Бесплатно, 30 минут |
| Пилот: один отдел, до 300 документов, 1–2 источника, проверка на 40 вопросах | от 150 000 ₽, 3–4 недели |
| Внедрение: несколько отделов, права доступа, автообновление, 1С, Битрикс24, Диадок | от 500 000 ₽, 6–10 недель |
| Сопровождение: обновление базы, контроль ответов, отчёт по вопросам | от 40 000 ₽ в месяц |
| Платформа по подписке: базу собираем мы | от 7 000 ₽ в месяц плюс настройка от 15 000 ₽, запуск 3–10 дней |
Цена зависит не от количества страниц, а от четырёх вещей: сколько источников нужно подключить, нужны ли права доступа (один отдел видит всё, разные отделы — разное), есть ли интеграции с 1С, Битрикс24 и Диадоком, и кто обновляет базу после запуска. Сами документы на срок влияют меньше, чем ожидается: пятьдесят документов одного отдела уже дают работающий пилот.
Платформа по подписке — вариант для тех, кому проект велик. Там те же части цепочки, но без интеграций с учётными системами и прав доступа по отделам.
Где это не работает #
Нет документов. Если порядок живёт в головах двух сотрудников и нигде не записан, собирать нечего. Начинать придётся с описания правил, и это работа компании, а не подрядчика. Техника тут не помогает.
Нужно не найти, а посчитать или сделать. «Сколько у нас на складе артикула 4417», «оформи заявку на отпуск» — это запрос в учётную систему и действие в ней, а не поиск по документам. Для такого нужна система, которая не только ищет, — про это статья про RAG-агента.
Сканы плохого качества и рукописное. Распознавание даёт текст с ошибками, а ошибка в цифре внутри базы опаснее отсутствия документа. Такие документы приходится вводить руками или оставлять за пределами базы.
Решения с юридическим весом. Ассистент показывает, что написано в документе, и ссылку на него. Решение принимает человек: ответ системы не является заключением юриста или бухгалтера.
Мало вопросов. Если в отдел приходит десять однотипных вопросов в неделю, дешевле написать страницу с ответами. Система начинает экономить время там, где вопросов много и они повторяются в разных формулировках.
Гарантий точности в процентах мы не даём — цифра без описания выборки ничего не значит. Вместо неё на пилоте заранее фиксируются 40 реальных вопросов отдела, и результат проверяется по ним: видно, на какие система отвечает, а какие уходят человеку.
Частые вопросы #
Можно ли собрать RAG-систему самим? #
Демонстрацию — да, за несколько дней: готовых библиотек много, и первый ответ по своим документам получается быстро. Разница между демонстрацией и рабочей системой — в остальных частях цепочки: права доступа, обновление базы, проверка ответов, журнал найденного и разбор вопросов без ответа. Именно на них уходит основное время внедрения.
Какая часть самая дорогая? #
Подготовка документов и обновление базы, то есть первая и последняя. Модель — самая дешёвая часть, её аренда считается копейками за ответ. Если в смете основная сумма стоит напротив подключения модели, стоит спросить, кто и за какие деньги разбирает документы.
Обязательно ли нужна векторная база? #
Для поиска по смыслу — да, именно она позволяет находить ответ в формулировках, не совпадающих с текстом документа. Но одной её мало: точные номера, артикулы и фамилии находит словесный поиск. Рабочее решение использует оба способа одновременно.
Что будет, если модель у провайдера отключат или подорожает? #
Знания живут в базе, а не в модели, поэтому модель заменяется без пересборки базы. У нас для этого есть цепочка из четырёх уровней: если первая модель не ответила, запрос идёт дальше. Это стоит проверить у любого подрядчика — вопрос «что будет, если модель станет недоступна» обычно хорошо показывает, как устроена система.
Как часто нужно обновлять базу? #
По событию, а не по календарю: поменялся документ — поменялось в базе в тот же день. Плюс раз в месяц разбор вопросов, на которые система не нашла ответа: оттуда видно, чего в базе не хватает. Полчаса такого разбора дают больше, чем любые настройки поиска.
Чем RAG-система отличается от поиска по документам, который уже есть? #
Обычный поиск возвращает список файлов, в которых встречается слово, и дальше сотрудник читает сам. RAG-система возвращает ответ на вопрос и ссылку на документ, из которого он взят. Разница заметнее всего там, где ответ собирается из двух-трёх документов: поиск отдаст все три, ассистент соберёт из них один ответ.
Устройство RAG-системы стоит знать не ради самой техники, а ради одного практического умения: по неверному ответу понимать, какая часть цепочки отказала, и спрашивать подрядчика про неё. Восемь частей — восемь вопросов до подписания договора, и половина из них не про модель.
