Внедрение начинается не с выбора модели и не с векторной базы, а с документов. В девяти случаях из десяти дело в одном из трёх: нужного документа нет вовсе, он устарел или редакций три и они противоречат друг другу. Пока это не разобрано, любая сборка выдаёт правдоподобные и неверные ответы, и виновата в них будет не модель.
RAG расшифровывается как генерация с дополненной выборкой. Что такое RAG и как он устроен внутри, разобрано отдельно; здесь речь о другом - что нужно сделать на своей стороне до того, как звать подрядчика, сколько это занимает, во что обходится и что ломается после запуска.
С чего начать: одна задача и один источник
Начинать стоит с одного вопроса, который сотрудники задают чаще всего. Обзор всех процессов компании и наведение порядка в общем диске подождут: и то и другое можно делать бесконечно, ни разу не приблизившись к работающей системе.
Три вопроса до старта:
Чей это вопрос. Кто именно спрашивает: менеджеры по продажам про условия договора, бухгалтерия про порядок оформления, новички про регламенты. У разных отделов разные документы, и объединять их в одну сборку на старте не нужно.
Как на него отвечают сейчас. Идут в вики, пишут в чат, дёргают конкретного человека. Если ответ живёт в голове одного сотрудника, документа для системы просто нет, и его придётся сначала написать.
Сколько раз в неделю его задают. Вопрос, который возникает дважды в месяц, автоматизировать бессмысленно. Тот, на который руководитель отдела отвечает по десять раз в день, окупает работу за пару месяцев.
Все три ответа даёт компания, а не подрядчик, и это самая дешёвая часть проекта. Первую неделю я обычно ничего не автоматизирую, а смотрю, как процесс работает сейчас: где документ ищут, что находят и почему переспрашивают. Обычный бизнес-анализ до всякой техники экономит больше денег, чем любая настройка модели потом.
Что нужно от документов компании
Здесь проект либо идёт, либо встаёт. Шесть типовых источников, в каком виде они обычно лежат и что с ними надо сделать до старта.
| Источник | В каком виде обычно | Что с этим не так | Что сделать до старта |
|---|---|---|---|
| Вики, регламенты, инструкции | Страницы в Confluence, Notion или на диске | Две-три редакции одного регламента, никто не помнит, какая действует | Назначить владельца раздела и пометить действующую редакцию |
| Договоры и приложения | PDF, часто сканы и фотографии | Текста в файле нет, есть картинка страницы | Отобрать те, что нужны для выбранной задачи, остальные не трогать |
| Переписка и чаты | Telegram, почта, комментарии в задачах | Ответ есть, но вперемешку с обсуждением и без даты действия | Вынести повторяющиеся ответы в отдельный документ |
| Таблицы и выгрузки | Excel, Google Sheets | Смысл в шапке и в соседней вкладке, для системы это набор чисел | Описать словами, что означают колонки и когда таблица обновляется |
| Данные в 1С и CRM | Записи в системе, не документы | Меняются ежедневно, вчерашняя копия уже неверна | Решить, нужен ли доступ к системе вместо документов |
| Документы с персональными данными | Договоры с физлицами, кадровые файлы, база клиентов | Попадают в общую выборку вместе со всем остальным | Отделить до загрузки и договориться, кто их видит |
Где документы лежат сейчас
Диск, почта, вики, чаты, 1С, CRM. Первый честный ответ на вопрос «где у вас документы» почти всегда звучит как «везде». Это нормально и не мешает старту: для пилота нужны не все документы, а десяток по одной задаче.
Мешает другое - когда ни один источник не считается главным. Ценность появляется в тот момент, когда система читает один источник правды, а не десять вкладок. Если по одному вопросу есть регламент на диске и другой ответ в чате, система найдёт оба и выберет наугад.
В каком они виде
Текстовые файлы и страницы вики читаются сразу. Сканы и фотографии договоров, таблицы со смыслом в шапке, презентации, куски ответов в переписке требуют отдельной работы до всякой сборки. Иногда эта работа сопоставима по объёму со всем остальным проектом, и узнать об этом лучше на второй неделе, а не на пятой.
Обещать себе лишнего тут не стоит. Распознавание сканов работает прилично на печатных документах и заметно хуже на кривых фотографиях с печатями и рукописными правками. Разбор того, как это устроено технически, лежит в хабе кластера, а не здесь.
Актуальность и противоречия
Две редакции регламента, приказ, отменивший инструкцию, но лежащий в другой папке, и устный ответ «спросите Олю, она в курсе». Для человека это нормальная рабочая среда: он знает, кому верить. Система не знает.
Пока у документа не назван владелец, ответ будет правдоподобным и неверным. Владелец - это конкретный человек, который отвечает на вопрос «эта редакция действует?». Не отдел и не «мы все», а фамилия. Документ без такого человека в выборку не берётся.
Кто имеет право это видеть
Зарплаты, договоры, персональные данные клиентов, кадровые документы. Разделение прав доступа проектируется до загрузки, а не прикручивается после: если данные попали в общую выборку, разделять их придётся заново с нуля.
На старте достаточно ответить, кто из сотрудников какие документы вправе видеть сегодня, до всякого ИИ. Обычно оказывается, что внятного ответа нет и в текущем виде. Это отдельная работа, и делать её всё равно придётся. Требования 152-ФЗ, закрытый контур и хранение данных внутри периметра разобраны на странице о безопасности.
Порядок работы и сроки
С моей стороны работа идёт пятью шагами:
- Разбор задачи. Тот самый вопрос, кто его задаёт и как на него отвечают сейчас.
- Отбор документов. Не всё, что есть, а то, что нужно для ответа на выбранный класс вопросов.
- Сборка на ограниченной выборке. Десятки документов, а не тысячи.
- Замер на реальных вопросах сотрудников. Список собирается заранее, из чата и почты, а не придумывается под демонстрацию.
- Расширение. Новые источники добавляются по одному, после каждого замер повторяется.
Пилот на одной задаче занимает 2-4 недели. Дальше срок зависит от числа источников и от того, сколько документов пришлось приводить в порядок: два источника в приличном виде идут быстрее десяти в разном. Полный цикл с интеграциями и правами доступа - это уже внедрение под ключ, и планировать его до результатов пилота я не берусь.
Рыночные ориентиры по срокам и суммам вместе с моими - в таблице ниже.
| Этап | Срок | Сумма | Источник |
|---|---|---|---|
| Пилот на одной задаче | 2-4 недели | от 150 000 ₽, фиксированная цена | za-ai.ru, 2026 |
| Внедрение под ключ | зависит от числа источников | от 450 000 ₽ | za-ai.ru, 2026 |
| Сопровождение | ежемесячно | от 50 000 ₽ в месяц | za-ai.ru, 2026 |
| RAG-бот на рынке | 3-8 недель | 150 000-200 000 ₽ | рыночная оценка, 2026 |
| RAG-система у студии | 6 недель | от 600 000 ₽ | code9.studio, 2026 |
| Кастомная разработка | 4-10 недель | 250 000-500 000 ₽ плюс поддержка 20 000-30 000 ₽ в месяц | sostav.ru, 2026 |
Порядок цены
Прайса на такие работы не бывает, бывает порядок величин и понятные причины, от которых он зависит. Мои суммы в 2026 году: пилот от 150 000 ₽ фиксированной ценой на одну задачу, внедрение под ключ от 450 000 ₽, сопровождение от 50 000 ₽ в месяц. Пилот засчитывается в стоимость внедрения целиком, если внедрение начинается по его итогам и по той же задаче. Полный расчёт со всеми условиями зачёта - на странице о том, сколько стоит внедрение.
Смещают цену три вещи: состояние документов, число источников и требования к доступам. Сканы вместо текста, шесть систем вместо одной и раздельные права для четырёх отделов - каждый пункт добавляет недели, а не проценты.
На лендингах обычно молчат ещё об одной строке. Первый год эксплуатации прибавляет 30-50% к стоимости разработки. Цифра рыночная, но с тем, что я вижу, она сходится: вызовы модели, хостинг, разбор очереди ошибок и чистка документов после того, как регламенты в очередной раз поменялись. Посчитать бюджет проекта без этой строки - значит заложить неприятный разговор на седьмой месяц.
Как понять, что качество достаточное
Метрика не «точность модели», а доля вопросов, на которые система дала ответ со ссылкой на документ и человек с этим ответом согласился. Считается вручную, на списке из полусотни реальных вопросов, и занимает один день.
Важен и второй показатель - доля вопросов, на которые система честно отказалась отвечать. Отказ здесь штатное поведение, а не сбой. Ошибка проектирования начинается там, где сначала спрашивают «что скажет модель», и не спрашивают «должна ли она вообще отвечать на этот вопрос».
Порог приёмки формулируется одной фразой. Если проверять ответы дольше, чем читать документы самому, проект не состоялся. Этот критерий понятен и заказчику, и сотруднику, которому дальше с системой работать.
Проверять надо на своих вопросах и на своих документах. Демонстрационный набор проходит всегда: его для того и собирали. Отдельно стоит посмотреть, что происходит, когда система не находит ответа и когда документ противоречит сам себе.
Что ломается после запуска
Типовой путь выглядит так: подключили всё, что подключается, свалили документы в векторную базу и надеемся. Ломается быстро, и вот на чём.
База зарастает мусором. Без регулярной чистки в выборке копятся черновики, дубли и отменённые документы. Через полгода система отвечает уверенно и неправильно, а найти источник ошибки труднее, чем в первый день.
Правила устаревают. Инструкции, написанные против выдумок модели, через год работают вхолостую и мешают: их писали под другую модель и другие документы. Пересматривать их надо так же, как регламенты.
Ответ системы становится источником для следующего ответа. Если сводку, которую собрала система, кто-то сохранил в вики, она вернётся обратно в выборку уже как документ компании. Один неточный пересказ таким способом превращается в правду за пару месяцев.
Никто не отвечает за содержание. Автоматизация бизнес-процессов не отменяет владельца результата. Кто-то должен читать, что система отвечает, и обновлять документы, когда меняется процесс. Это отдельный разговор, и он ведётся на странице про корпоративную базу знаний: там про то, кто держит её актуальной и что получает сотрудник.
Есть и пятое, стратегическое. Смысловой слой - то, как компания описывает саму себя, свои документы и правила, - должен принадлежать компании, а не тому вендору, у кого в этом квартале удобнее интерфейс. Платформы меняются, описание процессов остаётся, и его стоит держать в своём виде и на своей стороне.
Кому RAG не нужен
Четыре признака, при которых я отговариваю.
Ответ живёт в одной инструкции. Если все вопросы закрываются одним документом на пятнадцать страниц, хватит обычного поиска и закреплённого сообщения в чате.
Документов десяток. Дешевле их прочитать. Сборка окупается там, где источников сотни и они постоянно обновляются.
Данные меняются ежедневно. Остатки на складе, статусы заказов, текущие цены - это не документы, здесь нужен доступ к системе, а не поиск по выгрузке. Вчерашняя копия хуже, чем её отсутствие.
Вопрос требует действия, а не ответа. «Оформи возврат» - это не поиск по документам, это интеграция с системой, и решается она иначе.
Пятый признак назову жёстче. Если задачу закрывает простое правило, языковая модель здесь лишняя. Я видел сборку на большой языковой модели, которая проверяла наличие символа @ в адресе почты. Одна строка кода делала то же самое бесплатно и без ошибок.
Частые вопросы
С чего начинать, если документы в беспорядке?
С одной задачи и десятка документов, а не с наведения порядка во всей компании. Порядок в общем диске можно наводить год и не начать проект. Рабочий вариант обратный: выбрали вопрос, который задают чаще всего, собрали документы, которые на него отвечают, привели в порядок только их. Дальше порядок расползается сам, потому что становится видно, где он окупается.
Сколько времени занимает внедрение?
Пилот на одной задаче - 2-4 недели, включая замер качества. Дальше срок зависит от числа источников и состояния документов. Рыночные ориентиры для сравнения: 3-8 недель на бота по документам, 6 недель на систему у студии (code9.studio, 2026), 4-10 недель на кастомную разработку (sostav.ru, 2026). Сроки, которые называют до разбора документов, стоит считать оптимистичными по определению.
Можно ли обойтись без подрядчика?
Можно, и разборы, как это делают руками, лежат в открытом доступе. Собрать работающий прототип на своих документах реально за выходные. Останавливается DIY-сборка обычно в четырёх местах: права доступа по отделам, обновление документов без ручной перезагрузки всего, разбор случаев, где система ответила неправильно, и эксплуатация после того, как энтузиаст ушёл в отпуск. Главная сложность не в сборке, а в том, что чинить нечем, когда не понимаешь, что происходит внутри.
Данные не уйдут наружу?
Контур закрывается на этапе проектирования: документы хранятся на вашей стороне, права доступа повторяют те, что уже действуют в компании, персональные данные отделяются до загрузки. Конкретика по хранению, моделям внутри периметра и требованиям закона о персональных данных разобрана на странице о безопасности, ссылка на неё выше. Здесь только короткий ответ: да, это решаемо, и решать надо до старта, а не после.
Что будет, если система ответит неправильно?
Ответ всегда идёт со ссылкой на документ и на конкретное место в нём. Поэтому ошибку видно сразу: сотрудник открывает источник и понимает, что там написано другое. Проверить такой ответ дешевле, чем искать документ самому. Отказ отвечать при этом штатное поведение: «в документах ответа нет» - правильный ответ, а не сбой.
Сколько это стоит в эксплуатации, а не при запуске?
Порядок расходов первого года - плюс 30-50% к стоимости разработки; это рыночная цифра, но с моей практикой она сходится. Складывается из вызовов модели, хостинга, разбора очереди ошибок и чистки документов. Моё сопровождение - от 50 000 ₽ в месяц в 2026 году, разбивка на странице цен. Считать эксплуатацию надо до подписания договора на разработку: после она превращается в неприятный сюрприз.
Что дальше
Проверить, стоит ли овчинка выделки, можно за один разговор. Тридцать минут: смотрим на конкретный вопрос, который у вас задают чаще всего, на то, в каком виде лежат документы для ответа на него, и я говорю, где это окупится, а где дешевле обойтись без ИИ.
Написать можно в Telegram или на почту hi@za-ai.ru.