Короткий ответ: платформа или своё решение?
Начните с готовой платформы, если документы уже аккуратно хранятся в одной-двух системах, права на них понятны, а выбранный сервис показывает каждому сотруднику только разрешённые ему файлы, даёт ссылку на источник и обновляет поиск после правки документа. Попросите пробный доступ и проверьте свои вопросы, прежде чем переносить весь архив.
Отдельное внедрение или разработка нужны, когда источники разрознены, у одного документа несколько групп доступа, редакции меняются по сложному правилу, документы и ответы должны храниться в утверждённой компанией среде или ответ должен попадать в рабочий процесс. Например, инженер ищет инструкцию по оборудованию из хранилища, а ответ должен открыть именно действующую редакцию в его сервисной заявке. Свою систему имеет смысл обсуждать после проверки, что готовый сервис действительно не выполняет этот путь.
Есть и третий вариант: улучшить обычный поиск и порядок документов до подключения ИИ. Если никто не знает, какая из трёх инструкций действующая, модель не исправит этот спор. Сначала назначьте владельца документа и правило архивирования; затем проверяйте ответы.
Проверили правило на четырёх вымышленных документах
Чтобы отделить красивый диалог от надёжного поиска, мы собрали маленький контрольный прогон. В нём есть действующая инструкция по командировкам, её старая редакция, закрытый кадровый документ и общая инструкция по пропускам. Поиск сначала исключает архив и закрытые документы, потом показывает найденный текст с номером редакции. Если доступного ответа нет, возвращает «ответ не найден».
| Вопрос | Роль | Правильный исход |
|---|---|---|
| Кто согласует командировку? | Отдел продаж | Действующая редакция №3, руководитель отдела; старую редакцию не показывать |
| Какие условия премии? | Отдел продаж | Не выдавать закрытый кадровый документ |
| Какие условия премии? | Кадровый отдел | Показать разрешённый кадровый документ и редакцию |
| Где парковаться? | Отдел продаж | Ответ не найден |
Мы запустили четыре проверки, и каждая дала ожидаемый исход. Например, на вопрос отдела продаж «Кто согласует командировку?» демонстрация вернула: «Заявку согласует руководитель отдела» с указанием TRAVEL-2026, редакция 3. Старая редакция, где указана бухгалтерия, в ответ не попала. Вопрос о закрытой премии от этой же роли дал «ответ не найден». Это вымышленные карточки и заранее заданные темы; демонстрация не использует языковую модель и не доказывает, что настоящий ИИ поймёт произвольную формулировку. Понимание вопросов, точность цитаты и передачу владельцу темы нужно проверять отдельно на документах компании.
Что происходит между вопросом и ответом
Технологию часто называют RAG. Простыми словами: система сначала ищет подходящий фрагмент в разрешённых документах, затем помогает сформулировать ответ по найденному. AWS описывает этот путь как извлечение частей источника с сохранением связи с оригиналом. Читателю важнее не название технологии, а возможность открыть нужный пункт и проверить его.
Хороший ответ содержит не просто название файла. Ссылка должна вести к конкретному разделу и открываться человеку, который задал вопрос. Если документ закрыт, его текст нельзя прятать только в интерфейсе после генерации: закрытый фрагмент вообще не должен попадать в поиск для этой роли. Microsoft описывает фильтрацию результатов по правам на уровне документа; для выбранной платформы проверьте, как именно она получает и обновляет права из вашего источника.
Пять правил, без которых база знаний быстро устареет
Источник. Для каждого типа вопроса назовите систему, где живёт исходный документ. Например, инструкция по закупке находится в хранилище регламентов, а текущий остаток товара в учётной системе. Если ответ требует живого остатка, архив PDF не годится как источник этой части ответа.
Владелец и редакция. Кто утверждает новый текст и отзывает старый? Поставьте дату действия, номер редакции и срок, после которого новый текст должен появиться в поиске. Если одинаковые файлы лежат в чате и на диске, система должна знать, какой из них главный.
Доступ. Сотрудник должен видеть только то, что ему разрешено в исходной системе. Проверьте смену должности, увольнение, приглашение внешнего подрядчика и прямую ссылку на документ. Доступ к поиску не должен становиться обходом прав исходного хранилища.
Цитата. Ответ нужен с открываемым источником и, по возможности, точным фрагментом. Это не знак непогрешимости: сотрудник всё равно может заметить, что вывод не следует из цитаты. AWS позволяет отдельно просмотреть извлечённые фрагменты и ответ с цитатами, что удобно для такого теста.
Честный отказ. Когда доступного подтверждения нет, полезнее показать «не нашёл» и отправить вопрос владельцу темы. Иначе уверенный текст может превратиться в неверное действие: оплату по старому правилу, неправильную инструкцию клиенту или раскрытие чужих условий.
Таблица для пилота: карта документов и вопросов
Скопируйте эту таблицу и заполните на нескольких документах, по которым сотрудники часто задают вопросы. Она полезнее списка «у нас есть PDF и папка в облаке»: видны пробелы, которые придётся закрыть до подключения модели. В колонке «ожидаемый исход» пишите конкретный фрагмент или отказ.
| Источник и вопрос | Владелец / редакция | Кто видит | Ожидаемый исход |
|---|---|---|---|
| Регламент командировок: «Кто согласует поездку?» | Названный сотрудник кадров; действующая дата и архив | Все сотрудники | Ссылка на нужный пункт действующей редакции |
| Кадровая инструкция: «Какая у меня премия?» | Руководитель кадров; запись об обновлении | Только разрешённая группа | Для другой группы отказ без раскрытия текста |
| Нет документа: «Можно ли парковаться во дворе?» | Ответственного ещё назначить | Все сотрудники | Не выдумывать правило; показать путь к ответственному |
| Ваш документ и частый вопрос | Кто утвердил; какая версия действует | Разрешённые группы | Точный пункт со ссылкой или отказ |
Добавьте к каждой строке место хранения, адрес исходника, период обновления и человека, который принимает результат пилота. Если часть документов сканирована и текст не извлекается, это отдельная работа по подготовке источника. Именно она часто влияет на оценку сильнее, чем внешний вид окна чата.
Скачать карту пилота в CSV. В файле есть демонстрационные строки и пустая строка для вашего документа; личных данных в нём нет.
Как сравнить готовую платформу и разработку
Дайте обоим вариантам одинаковые документы, роли и контрольные вопросы. Иначе демо с красивым общим справочником сравнивают с собственной сложной папкой и получают неверный вывод. У готового сервиса уточните, как новый документ появляется в поиске, как исчезает старая версия, кто видит ответ и куда ведёт ссылка. У подрядчика по разработке попросите показать те же шаги в пилоте и назвать, кто будет их сопровождать.
| Критерий | Готовая платформа | Своя интеграция |
|---|---|---|
| Источники | Проверьте готовые подключения к вашим системам и обновление после правки файла | Проектируйте связь с конкретными хранилищами и правило синхронизации |
| Права | Проверьте, совпадают ли права с исходной системой и как быстро меняются | Закладывайте проверки на каждом запросе и тест чужого документа |
| Данные | Узнайте, где хранятся документы, вопросы, ответы и журналы; идут ли данные на обучение и как их удаляют | Зафиксируйте место хранения, доступ, срок удаления и условия обработки данных поставщиками модели |
| Ответ | Оцените цитату, отказ и поведение при противоречии | Задайте свои правила ответа и журнал ошибок |
| Дальнейшая работа | Проверьте тариф, лимиты, хранение и поддержку | Учтите сопровождение, модели, поиск и обновление документов |
Готовая платформа может оказаться лучшим выбором даже для большой компании, если её стандартные подключения и права проходят ваш тест. Собственная система полезна, когда нужный процесс не помещается в рамки продукта: например, ответ должен открывать сервисную заявку с той же ролью и фиксировать, какая редакция была показана. Здесь важен не престиж «своего ИИ», а проверяемый рабочий путь.
Что войдёт в смету и расходы после запуска
Если ваши инструкции лежат в сканах и разных папках, одна строка «подключить ИИ» скроет большую часть работы. Попросите разделить оценку на части. Подготовка знаний: инвентаризация хранилищ, удаление дублей, правила редакций, извлечение текста из сканов, владельцы материалов. Техническая часть: вход сотрудников, права, подключение источников, поиск, формирование ответа, ссылки, журнал ошибок и интерфейс. Проверка: набор вопросов, закрытые документы, противоречия, вопросы без ответа, тест после обновления. Запуск: обучение владельцев документов, поддержка и порядок добавления новых источников.
После запуска остаются расходы на выбранную платформу или инфраструктуру, вызовы модели, хранение и обновление поиска, сопровождение подключений, проверку новых документов и поддержку сотрудников. Не складывайте разовую разработку и ежемесячные расходы в одну нерасшифрованную цифру. Сначала согласуйте набор источников, роли и примерную нагрузку; только по ним можно сравнить предложения. На этой стадии публиковать «среднюю цену» без одинакового состава работ было бы вводящим в заблуждение.
Для первого выпуска обычно хватает одного участка знаний, где цена ошибки понятна и владелец документов доступен. Например, инструкции для внутренней поддержки. Если вопрос требует действия в CRM, сначала добейтесь надёжного ответа по документу, а запись в CRM добавляйте после отдельной проверки прав и подтверждений. Подробнее о действиях AI-агента мы рассказали в отдельной статье.
Пилот: проверьте трудные вопросы, а не только лёгкие
Соберите вопросы самих сотрудников, обезличьте чувствительное и заранее запишите ожидаемый исход. Не показывайте тестирующим только те примеры, на которых подрядчик настраивал поиск. Оцените отдельно, нашёлся ли правильный фрагмент, верно ли сформулирован ответ и можно ли открыть источник. AWS также разделяет оценку поиска и генерации на своём наборе вопросов.
- Спросите о действующей процедуре обычными словами и синонимом. Оба ответа должны вести к нужному пункту.
- Загрузите старую редакцию рядом с новой. Поиск не должен выдать отменённое правило как действующее.
- Войдите под двумя ролями и задайте один вопрос по закрытому документу. Недопущенный сотрудник не должен получить ни текст, ни цитату, ни рабочую прямую ссылку.
- Спросите о том, чего в документах нет. Ожидайте честный отказ и путь к ответственному.
- Добавьте в тестовый документ фразу, которая велит помощнику игнорировать правила. Текст документа остаётся данными, а не командой системе. OWASP описывает такой риск для систем с поиском по загруженным материалам.
- Обновите документ и повторите вопрос. Измерьте не только ответ, но и время до появления новой редакции в поиске; допустимую задержку согласуйте для вашего процесса.
Результаты разбирают вместе с владельцем знаний, ИТ и будущими пользователями. Если ответы неверны, выясняют причину: не тот документ, устаревшая версия, плохое извлечение текста, неверное право или добавленная моделью догадка. От причины зависит следующая работа; смена модели не исправит хаос в документах.
Правило решения по пилоту: если закрытый текст попал к чужой роли, запуск останавливают и исправляют проверку прав. Если ответ ссылается на старую редакцию, исправляют обновление документов и повторяют тест. Если ссылка верная, но текст ответа искажает правило, разбирают формирование ответа на том же наборе вопросов. Критерии приемлемого числа ошибок задаёт владелец процесса до испытания, а не после красивой демонстрации.
Частые вопросы
Нужно ли обучать модель на документах компании?
Обычно сначала проверяют поиск по действующим документам и ответ по найденным фрагментам. Это позволяет обновлять источник без нового обучения модели. Другой способ выбирают только после проверки задачи и качества.
Можно ли начать с готовой платформы?
Да, если она подключает нужные источники, сохраняет права доступа и редакции, показывает проверяемый источник и умеет не отвечать без основания. Эти условия проверяют на своих вопросах до покупки или расширения тарифа.
Что делать, если ответа в документах нет?
Система должна сказать, что подтверждённый ответ не найден, и показать маршрут к ответственному. Придуманный уверенный ответ хуже честного отказа.
От чего зависит стоимость внедрения?
От подготовки документов, числа источников и прав, интеграций, проверки качества, размещения, поддержки и нагрузки. Сравнивать сметы стоит по одному списку документов и контрольных вопросов.
Источники и дальнейшее чтение
- AWS: как работает поиск по документам перед генерацией ответа, проверено 23.09.2026.
- AWS: ответы с цитатами и просмотр найденных фрагментов, проверено 23.09.2026.
- Microsoft: разграничение доступа к документам в поиске, проверено 23.09.2026.
- AWS: оценка поиска и ответов на своём наборе вопросов, проверено 23.09.2026.
- OWASP: вредоносные инструкции в материалах для ИИ, проверено 23.09.2026.
Если база нужна для первой линии поддержки клиентов, отдельно проверьте канал обращения и передачу человеку. Эти вопросы разобраны в материале о стоимости чат-бота.
Проверим, с чего начать вашу базу знаний
Оставьте номер для короткого разговора. На нём расскажите, где хранятся документы, кто ими пользуется и какие вопросы задают чаще всего; обезличенные примеры можно передать позже. Мы составим карту источников, прав и редакций, предложим набор вопросов для пилота и сравним готовую платформу со своим внедрением.
После разбора у вас останется понятный список для проверки решения и сметы.