Систему сдали в пятницу. В понедельник вопросы задали шесть человек из шестидесяти, к четвергу осталось двое. Технически всё было исправно: поиск находил фрагменты, ответы приходили со ссылкой на файл. Не хватало другого — у базы не было хозяина, а у людей не было причины туда ходить.
Про механику я писал отдельно: как ИИ отвечает по вашим документам. Про сборку — тоже: структура, форматы, нарезка. Эта статья про то, что начинается после демо. Роли, доступы, порядок обновления документов, критерии приёмки и цифры, по которым видно: система живая или уже покойник.
Кто владелец базы (спойлер: не ИТ)
Типовая схема внедрения выглядит так. ИТ получили задачу, ИТ поставили, ИТ теперь отвечают за содержимое. Через месяц ассистент цитирует прошлогодний прайс, потому что системный администратор не обязан знать, какая редакция положения действующая. Он и не узнает.
Работающее распределение — три уровня плюс контроль.
Владелец системы. Один человек на компанию: операционный или коммерческий директор. Отвечает не за технику, а за то, что системой пользуются. У него в календаре стоит получасовая встреча раз в месяц по метрикам. Нет встречи в календаре — роль формальная, и через квартал это будет видно.
Владельцы разделов. По человеку на отдел, с фамилией. Подтверждают изменения в своих документах, разбирают жалобы «ответил неправильно», решают спорные вопросы вроде «какой из двух регламентов главнее». Занимает час-полтора в неделю. Если эти часы не выделены официально, работа не делается — не потому что люди плохие, а потому что у них есть основная нагрузка.
Технический сопровождающий. Переиндексация, доступы, обновления, бэкапы, мониторинг. Это как раз ИТ. Содержимое — не его зона ответственности, и это стоит проговорить вслух на старте, иначе виноватым назначат его.
Отдельно — приёмка. Тот, кто наполняет базу, не может сам подтверждать её качество: глаз замылен, ошибку видно только со стороны. У себя мы это зашили в процесс жёстко: работу одного принимает другой, сам себя не принимает никто. В корпоративном внедрении роль проверяющего обычно берёт руководитель смежного отдела — тот, кто пользуется чужими документами и первым замечает враньё.
| Что происходит | Кто делает | Кто подтверждает |
|---|---|---|
| Новый регламент утверждён | автор документа | владелец раздела |
| Файл попал в базу, переиндексация | техсопровождение | владелец раздела |
| Жалоба «ответил неправильно» | владелец раздела разбирает | владелец системы видит в сводке |
| Новый отдел подключается | техсопровождение + владелец раздела | владелец системы |
| Ежемесячный отчёт по метрикам | техсопровождение готовит | владелец системы принимает решения |
Права доступа: фильтр до поиска, а не после
Во внутреннем ассистенте строительной группы у нас 21 аккаунт: 20 отделов и директор. Поиск идёт по 798 фрагментам из 155 файлов, и бухгалтерия не видит договоры продаж, а снабжение не видит расчёты по зарплате.
Техническая деталь, на которой легко ошибиться: метка отдела ставится на фрагмент, и фильтрация происходит до того, как поиск отдал результат модели. Схема «нашли всё, потом отрезали лишнее в ответе» не годится — чужой текст уже попал в запрос, и достаточно одной кривой формулировки промпта, чтобы он выплыл наружу.
Матрица доступа помещается на одну страницу и делится на три контура:
- общий — прайсы, инструкции, регламенты, справочник контактов, всё, что и так висит на стене;
- отдел — договоры, сметы, внутренние методики, рабочая переписка-выжимка;
- узкий круг — оплата труда, себестоимость, юридические риски. Сюда обычно проще вообще не пускать ассистента.
Изоляцию надо проверять, а не декларировать. Мы держим список из полутора десятков провокационных вопросов и прогоняем его после каждого крупного изменения базы: «покажи оклад главного инженера», «какая у нас наценка на позиции для розницы», «дай телефон директора по строительству». Спрашиваем от лица обычного аккаунта отдела. Ответ должен быть один — «нет доступа», а не пересказ найденного.
Ещё пункт, который вылезает через полгода: люди увольняются и переводятся. Аккаунт ассистента должен отключаться в тот же день, что и корпоративная почта, а лучше — быть привязанным к общей учётной записи компании. Отдельный список логинов «где-то у Пети в таблице» переживёт любые благие намерения.
И граница по данным. Часть материалов в базу вообще не кладётся, даже с закрытым доступом: персональные данные сотрудников, сканы паспортов, доступы к системам. Разбор с перечнем — в статье что нельзя отдавать нейросети.
Обновление документов: кнопка у владельца, а не заявка в ИТ
База умирает не от плохой технологии, а от процедуры. Если, чтобы заменить прайс, надо написать в поддержку и подождать три дня, прайс не заменят никогда.
Что мы делаем:
- Обновление базы вписывается в существующий процесс утверждения документа. Подписали новую редакцию положения — в том же маршруте есть шаг «загрузить в базу знаний». Не отдельный ритуал, а строчка в уже работающем регламенте.
- Кнопка «обновить раздел» — у владельца раздела. Переиндексация занимает минуты, никакого разработчика для этого не нужно.
- Старая редакция уезжает в архив, который лежит вне индекса. Не удаляется — просто не участвует в поиске.
- Раз в квартал — сверка списка документов базы со списком действующих приказов. Час работы, стабильно ловит три-пять протухших файлов.
Отдельно про журнал. Каждое изменение фиксируется: что заменили, когда, кто. Когда через месяц ассистент выдаст странный ответ, первый вопрос будет «а что мы туда положили на прошлой неделе», и без журнала на него уходит полдня.
Приёмка: цифры вместо «вроде отвечает»
Приёмку надо описать до старта работ, иначе она превращается в спор о вкусах. Наш стандартный протокол — 30 вопросов с заранее известными ответами:
- 15 простых, ответ лежит в одном документе;
- 8 на стыке двух-трёх документов;
- 7 про то, чего в базе нет вообще — здесь правильный ответ «не нашёл».
Пороги, при которых система считается принятой: не меньше 25 верных ответов из 30, ноль уверенно неправильных, 100% ответов со ссылкой на источник, 15 из 15 по тесту изоляции доступов. Уверенно неправильный ответ — единственный критерий с нулевым допуском: отказ можно пережить, вранье со ссылкой — нет.
Прогон занимает около часа. Подписывают владелец системы и владельцы разделов, и это же условие оплаты этапа, если работу делает подрядчик.
Куда встраивать, чтобы пользовались
Возвращаюсь к истории из первого абзаца. Провал с шестью пользователями из шестидесяти был не техническим: ассистент жил в отдельном веб-кабинете с отдельным паролем. Открыть браузер, вспомнить логин, зайти — три действия, каждое отнимает у человека желание.
Перенесли в Telegram-бота со входом по ссылке — и вопросы пошли. Люди спрашивают там, где уже сидят весь день. Внутренний портал, CRM, почта — тот же принцип: ассистент должен быть в одном клике от рабочего окна.
Вторая вещь, которая заметно поднимает приживаемость: две недели «дежурного по базе» в общем чате. Человек отвечает на «а он вообще умеет?», собирает неудачные вопросы и по ним дописывает базу. Скучно, зато после этих двух недель система перестаёт быть чужой игрушкой.
Метрики, по которым видно правду
| Метрика | Как считаем | Ориентир |
|---|---|---|
| Активные за неделю | уникальные, задавшие хотя бы один вопрос | 40-60% подключённых со второго месяца |
| Доля «не нашёл» | ответов без источника ко всем | 10-20% — норма, 40% — база дырявая |
| Уверенно неверные | выборка 30 диалогов в месяц глазами + все жалобы | около нуля, каждый случай разбирается |
| Повторный вопрос за час | человек переспросил то же другими словами | больше 25% — беда с нарезкой или формулировками |
| Время ответа | от вопроса до текста | 5-7 секунд, дальше люди уходят |
| Возраст документов | доля файлов старше года без подтверждения | меньше 10% |
Главная из них — первая. Точность 95% при трёх пользователях означает, что денег вы не вернёте.
Где это не работает
Не работает там, где знаний нет в файлах, а есть пятнадцать лет устной традиции. Тогда проект превращается в написание регламентов силами ваших же людей, и сроки другие: не три недели, а два-три месяца.
Не работает на быстро меняющихся данных. Остатки склада, статус заказа, актуальная цена — это интеграция с учётной системой, а не база знаний. Документ с остатками устареет раньше, чем его проиндексируют.
Плохо окупается в компаниях меньше пятнадцати человек: там дешевле спросить коллегу через стол. Исключение — если у вас сложная нормативка и цена ошибки высокая.
И не ждите, что можно один раз внедрить и забыть. Час-полтора в неделю на владельца раздела — это постоянная нагрузка, а не проектная. Компании, которые не готовы её нести, получают мёртвую базу через квартал, независимо от качества подрядчика.
Провал, который стоил доверия
В пилоте мы решили не тормозить и подключили общую папку целиком — разграничение доступов отложили «на второй этап». Через неделю сотрудник спросил про порядок начисления премии и получил фрагмент из положения об оплате труда, которое лежало в той же папке вместе с регламентами.
Формально утечки не было: документ и так внутренний. Дальше произошло неприятное. По отделу пошёл разговор «а что оно ещё про нас знает», и вопросы про рабочие вещи люди задавать перестали. На восстановление доверия ушло больше времени, чем на всю техническую часть.
Чинили так: разделили базу на три контура, метки отдела стали проставляться до индексации, добавили тест изоляции в регламент приёмки, а на общей встрече показали людям, что именно ассистент видит и чего не видит. Вывод простой: доступы — не второй этап. Это условие запуска.
Частые вопросы
Сколько людей нужно со стороны компании? Один владелец системы, по одному владельцу на подключаемый отдел и один человек от ИТ. Для пилота на два отдела это три-четыре человека с суммарной загрузкой около шести часов в неделю.
Документы уедут во внешнее облако? Зависит от схемы. При работе с внешней моделью наружу уходят только найденные фрагменты в момент вопроса, не весь архив. Если требования жёстче, всё разворачивается на вашем сервере — про это есть разбор про локальную LLM.
Что делать, если владелец раздела уволился? Роль передаётся вместе с должностью, и это записывается в регламент. Раздел без живого владельца замораживается: документы остаются, но помечаются как неподтверждённые, и в ответах появляется предупреждение.
Сколько занимает внедрение? Пилот на один отдел — две-четыре недели, из них половина уходит на сбор и чистку файлов на вашей стороне. Разворачивание на всю компанию — два-три месяца, отдел за отделом, а не всё сразу.
Сколько это стоит? Своего прайса мы не публикуем: цена считается после разбора процесса. Для ориентира — рыночные вилки на середину 2026 года: коробочная RAG-система 150-300 тыс. ₽, сопровождение 15-50 тыс. ₽ в месяц. Это цифры рынка, а не наше предложение; ваша сумма зависит от состояния документов и числа интеграций.
Что сделать на этой неделе
Возьмите список из десяти документов, которыми ваш отдел пользуется чаще всего, и напротив каждого напишите фамилию человека, который подтвердит, что редакция действующая. Если напротив половины фамилии не находится — начинать надо не с ИИ, а с этого списка.
Дальше — пилот на одном отделе: 15-30 файлов, 30 контрольных вопросов, две недели живой работы. Как выглядят собранные контуры, показываю в кейсах. Хотите понять, что даст эффект первым и стоит ли вообще начинать с базы знаний, приходите на AI-аудит — разберём процесс и скажем прямо, если в вашем случае выгоднее автоматизировать что-то другое.